When malware actors want to enter the business, they can choose markets where their profit is almost guaranteed to be worth the effort – according to past results. The malware does not need to be high profile, just careful selection of the audience and the right market can be enough.
This “stay-low-aim-high” approach is what the Check Point Research team saw in our recent Android malware research. We encountered an Android Trojan named FakeCalls, a malware that can masquerade as one of more than 20 financial applications and imitate phone conversations with bank or financial service employees – this attack is called voice phishing. FakeCalls malware targeted the SouthKorean market and possesses the functionality of a Swiss army knife, of being able not only to conduct its primary aim but also to extract private data from the victim’s device.
Voice phishing attacks have a long history in the South Korean market. According to the report published on the South Korean government website, financial losses due to voice phishing constituted approximately 600 million USD in 2020, with the number of victims reaching as many as 170,000 people in the period from 2016 to 2020.
We discovered more than 2500 samples of the FakeCalls malware that used a variety of combinations of mimicked financial organizations and implemented anti-analysis (also called evasions) techniques. The malware developers paid special attention to the protection of their malware, using several unique evasions that we had not previously seen in the wild.
In our report, we describe all of the encountered anti-analysis techniques and show how to mitigate them, dive into the key details of the malware functionality and explain how to stay protected from this and similar threats.
Before we get to the technical details, let’s discuss how voice phishing works in the example of FakeCalls malware.
The idea behind voice phishing is to trick the victim into thinking that there is a real bank employee on the other side of the call. As the victim thinks that the application in use is an internet-banking application (or payment system application) of a real financial institution, there is no reason to be suspicious of an offer to apply for a loan with a lower interest rate – which is fake, of course. At this step, the malware actors can lay the necessary groundwork to understand how to approach the victim in the best way possible.
At the point where conversation actually happens, the phone number belonging to the malware operators, unknown to the victim, is replaced by a real bank number. Therefore, the victim is under the impression that the conversation is made with a real bank and its real employee. Once the trust is established, the victim is tricked into “confirming” the credit card details in the hope of qualifying for the (fake) loan.
This is the principal scheme of the attack:
Image 1 – The key steps of a voice phishing attack.
Targeted financial institutions are selected from amongst the largest and most prominent ones in the banking sector: strong repay capacity ratings as evaluated by the South Korean government and major world agencies, with billions of South Korean Won (KWR) revenue (equal to millions of the United States dollar (USD). Mimicking applications from such companies increases the chances of attracting suitable victims.
When victims install the FakeCalls malware, they have no reason to suspect that some hidden catches are present in the “trustworthy” internet-banking application from a solid organization.
At step 2 of voice phishing attack, instead of a phone conversation with a malware operator, a pre-recorded audio-track can be played imitating instructions from the bank. Several different tracks are embedded into different malware samples corresponding to different financial organizations.
One way or another, malware operators get the private financial data of the victim which means that the aim of attack is achieved successfully.
In this section we describe the anti-analysis techniques as well as the process of dropping the final payload and the details of FakeCalls’ network communication.
There are three unique anti-analysis techniques encountered in different malware samples that we did not observe previously in the wild. We took the following malware sample and analyzed all three evasions we encountered inside:
If you try loading such a sample into analysis tools, they fail, as shown on this JEB Pro example:
Image 2 – FakeCalls failed to load in JEB Pro.
Let’s dissect and mitigate each of the anti-analysis techniques one by one, to finally be able to load and analyze the malicious payload.
The first evasion is called “Multi-Disk.” We clearly understand that APK cannot be split into multi-disk archives, so we check this information in the APK by analyzing the ZIP header data.
The necessary entry is the central directory file header. The end of this record EOCD contains information about disk count.
End of central directory signature = 0x06054b50
Number of this disk (or 0xffff for ZIP64)
Disk where central directory starts (or 0xffff for ZIP64)
Number of central directory records on this disk (or 0xffff for ZIP64)
Total number of central directory records (or 0xffff for ZIP64)
Size of central directory (bytes) (or 0xffffffff for ZIP64)
Offset of start of central directory, relative to start of archive (or 0xffffffff for ZIP64)
Comment length (n)
EOCD marks the end of ZIP so the needed byte sequence can be found at the end of the file:
Image 3 – Selected sequence at the end of the file.
The processed struct looks like this:
Image 4 – Values of the structure fields.
Based on the very large values in the disk number fields, we understand that malware developers edited these fields and entries. This means that the disk numbers should be set to 0, and the disk entries to the value equal to the directory entries: 1075.
The second evasion goes by the name “AndroidManifest.” The AndroidManifest file must start with specific magic numbers 0x00080003 but our file starts from 0x00080000.
Image 5 – Magic number at the beginning of the AndroidManifest file.
Besides the magic number, the file contains other things that break the decoding process.
Image 6 – Values of the fields in the STRINGCHUNK structure.
The value of the scStylePoolOffset field points from the actual AndroidManifest file. Based on the scStyleCount field, we see that file shouldn’t contain “styles”, and the value of this field should be 0x00000000. The next thing we look at is scStringCount. The value here looks normal, except for the moment when string analysis occurs. The image below informs us that the offset of the last string is pointing out of the file.
Image 7 – Wrong last string offset in the array.
We see that the string “theme” is wrongly interpreted as an offset value in the last element of the array, number 87. This means that the value of the scStringCount should be less by 1, i.e., set to 86.
The third and the final evasion is called simply “Files.” This technique is related to the files inside the APK.
Image 8 – Files inside the APK.
Developers added a large number of files inside nested directories to the asset folder. As a result, the length of the file name and path is over 300 characters.
Image 9 – Length of the file name (selected in the screenshot).
These files break the logic of tools that cannot remap file locations and may fail during APK decompilation. However, after all the previous fixes, such files can be manually removed from the APK as they are not required anymore.
In the end, the resulting APK file can be processed inside typical analysis tools.
Image 10 – FakeCalls successfully loaded in JEB Pro.
Inside the malware
FakeCalls payload is not launched at once. Instead, the dropper is used as an intermediate step.
The malware registers BroadcastReciever for the application installation events. This receiver launches the dropped APK later in the process.
Image 11 – Implementation of the BroadcastReciever responsible for launching dropped APK.
Then malware shows a button to click to start the payload installation.
Image 12 – Button saying “Click Install Setup” in Korean.
The APK is located inside the asset folder and is copied during the process of loading the view components.
Image 13 – Code responsible for copying the APK.
When the payload is successfully dropped, the malware launches the application with the configuration that it gets during the runtime.
Image 14 – Setting up the parameters when launching the application.
The command processing method has a command called “stream”:
Image 15 – Option in the code enabling capture of live streams.
The corresponding method starts an audio or video service, or stops them, depending on the “state” variable value received from the C&C server.
Image 16 – Code to capture live streams.
Upon the creation of video service, the RtspCamera2 object is initialized by setting the authorization details and audio/video configuration (bitrate, fps, noise cancellation, etc.).
Image 17 – Initialization of RtspCamera2 object.
Then the malware selects the front camera and starts streaming to C&C server which will be stopped after 5 minutes.
Image 18 – Code lunching live streaming to C&C server.
FakeCalls may receive a command from C&C server to switch the camera during the live streaming.
The malware developers implemented several ways to keep their real Command-and-Control (C&C) servers hidden: reading the data via dead drop resolvers in Google Drive or using an arbitrary Web server. Dead Drop Resolver is a technique when malicious content is stored on legitimate web services. Inside malicious domains and IP addresses are hidden to disguise the communication with real C&C servers. We have identified more than 100 unique IP addresses by processing the data from dead drop resolvers.
The first variant is reading the configuration via Google Drive: the malware contains an encrypted string with a link to Google Drive where the file is stored.
Image 19 – Link to Google Drive inside the FakeCalls malware.
The name of the file is encrypted with AES.
Image 20 – The code to get the encrypted file name from Google Drive.
After reading the file name, FakeCalls decrypts it with a hardcoded AES key and gets the real C&C configuration:
The first element is a new server address, the second one is the address of a stream server used for live streams capture, and the last one is a link to a new dead drop resolver.
The malware decrypts all the data pieces and stores them for future use:
Image 22 – The code for decrypting the information received from the server.
Check Point’s Harmony Mobile Prevents malware from infiltrating mobile devices by detecting and blocking the download of malicious apps in real-time. Harmony Mobile’s unique network security infrastructure – On-device Network Protection – allows you to stay ahead of emerging threats by extending Check Point’s industry-leading network security technologies to mobile devices.
Threat Emulation Protections
In the FakeCalls malware case, the developers decided not to leave any aspect of their operations to chance. They selected a profitable voice phishing market in South Korea where past results proved to bring tremendous value for cybercrime operators, harvesting approximately 600 million USD from unsuspecting victims in 2020. The coverage of 170,000 victims in the period of 5 years from 2016 to 2020 only added fuel to the mix.
But the story did not stop there. The malware developers took special care with the technical aspects of their creation as well implementing several unique and effective anti-analysis techniques. In addition, they devised mechanisms for disguised resolution of the Command-and-Control servers behind the operations.
This case shows the utmost importance of researching malware that is active in just a single country out of almost 200 in the world. The tricks and approaches used in this particular malware can be re-used in other applications targeting other markets around the globe. There is no physical distance in a digital sphere, the information spreads rapidly and we must react quickly in an ever-changing malware landscape.
The Check Point Research team stays vigilant and ready to adapt to the upcoming challenges.
The list of hashes below is not excessive by any means: