- 188.8.131.52 – innovatemyschool.com – Compromised website
- 184.108.40.206 – add.smartpettags.org – Rig-V EK
- Cerber checkin UDP traffic via port 6892:
- 220.127.116.11 – btc.blockr.io – Bitcoin block explorer
- 18.104.22.168 – avsxrcoq2q5fgrw2.4vona2.top
- 22.214.171.124 – avsxrcoq2q5fgrw2.17rmvr.top – Cerber Decryptor site
- 126.96.36.199 – avsxrcoq2q5fgrw2.wiaikl.top – Cerber Decryptor site
- 188.8.131.52 – avsxrcoq2q5fgrw2.onion.to – Cerber Decryptor site
Sample of Cerber UDP Checkin Traffic (2 of the 4 subnets):
File name: RigV Exploit Kit Landing Page.html
File name: RigV Flash Exploit.swf
File name: MXj6sFosp
File name: rad97CAA.tmp.exe, rad89D21.tmp, rad2C8A6.tmp
The infection begins with the familiar pseudoDarkleech code being found on the compromised website:
In the picture above you can see that the iframe tag contains the malicious URL. Note: in the “Traffic” section above you can also see that I refreshed the compromised web page four times. This resulted in me getting four different URLs.
The first three times I refreshed the web page I got a full infection chain all delivering the same payload (file names are different but the hashes were all the same).
The URL shown in the compromised site image comes from the 4th attempt (circled in pink in the Traffic image), which failed. To be clear I will be using the first infection chain (circled in red in the Traffic image) throughout the rest of this blog post.
In a typical EK infection chain the user would visit the compromised site and the URL contained within the injected script would generate a GET request which would return the encoded landing page.
However, this was the first time that I’ve ever seen an infection chain use a GET for fingerprinting and then a POST to return the landing page. Below is the GET request generated by the URL in the iframe, as well as the response from the server:
Normally the server would return an encoded landing page, however, this time the server returned a page which is meant to fingerprint the system. For the sake of our own clarity we are calling it the “fingerprinting page” but it basically is performing the function of a gate.
Below is the entire code returned by the server (comments added by my friend, pseudonym “elf”):
There are a lot of checks shown above but as you can see it boils down to if the User-Agent string is IE and if it is the NormalURL (the landing page) is requested via the POST method. In other words, if you’re not a bot and not using IE then it would give you a benign page. If you’re a bot then you get a 404 page. On the other hand, if you’re not a bot and are using IE then you get the landing page.
Below is the TCP stream showing the POST method being used for the request and the response from the server containing the landing page (partial image):
And here is the decoded landing page (provided by my friend “elf”):
At the bottom of the image shown above you can see the URLs for the Flash exploit and Cerber ransomware payload.
Here are partial images of the Flash exploit and payload being requested and returned:
The payload is downloaded by a small script that is dropped in %Temp%:
We then see the .exe’s (rad97CAA.tmp.exe, rad89D21.tmp.exe, rad2C8A6.tmp.exe) dropping in %Temp% after each refresh of the browser:
Also interesting to note that one of the folders is being named (partially) by my GUID.
After the host is successfully infected the Cerber ransom note is displayed on the desktop via a bitmap image and there are .hta ransom note files dropped in various locations:
Here is an image of the .hta ransomware Cerber instructions file:
My suggestion would be to block the EK IP and or sub-domain. Updated IDS rules can also help to detect Cerber’s UDP checkin traffic. Unfortunately my IDS did not detect the traffic:
Until next time!