Starting on Mon, 5 august 2013, 06:57:30 Fox-IT’s monitoring service detected a redirect occurring initially on conrad.nl but later on many other websites. The way the site was compromised means thousands of websites are redirecting, in total 3 web hosters seem to have been affected by the DNS server compromise:
- Digitalus
- VDX
- Webstekker
All sites using the DNS servers from these companies will have been affected. The official response given by Digitalus was that someone modified the DRS from SIDN with external name servers. This means that any DNS requests made to them would end up at the malicious DNS servers. The only problem now is that the DNS zones have a TTL (Time to live) of 24 hours. This means that most ISP would have this incorrect data in their caches for at least this length of time. After being contacted they fixed the issue and most public name servers now respond with the correct data. How the intruders got access to the DRS remains unknown until Digitalus or SIDN disclose more information, they are is still investigating the issue (source).
Every website that was being requested responded with a blank “Under construction” page with an iframe on it. The iframe was a host running the Blackhole Exploit Kit. While initially we assumed conrad.nl was compromised we found out that the DNS servers were giving back responses with the same IP every time: 178.33.22.5
The nameserver responses for conrad.nl as an example:
;; ANSWER SECTION: conrad.nl. 300 IN NS ns1.dn-s.nl. conrad.nl. 300 IN NS ns2.dn-s.nl. ;; ADDITIONAL SECTION: ns1.dn-s.nl. 7200 IN A 85.158.251.251 ns2.dn-s.nl. 7200 IN A 83.96.142.70
Analysis of the attack
When vising the page on IP 178.33.22.5 the following response was given:
The host cona.com at the time was responding with 199.233.237.211. This hosted the exploit kit named Blackhole. The kit targetted the client with a PDF exploit (3/45 on VT) and a Java exploit (3/46 on VT).
Looking at URL data it looks as follows:
"GET http://www.conrad.nl/ HTTP/1.1" - - "-" "Mozilla/5.0 (Windows NT 5.1; rv:21.0) Gecko/20100101 Firefox/21.0" "GET http://cona.com/removal/stops-followed-forces.php HTTP/1.1" - - "http://www.conrad.nl/" "Mozilla/5.0 (Windows NT 5.1; rv:21.0) Gecko/20100101 Firefox/21.0" "GET http://cona.com/removal/stops-followed-forces.php?xsbmHaOUDWN=RcezQhYNSbrYT&BOZRScKNhz=QoMIfWkfOPj HTTP/1.1" - - "-" "Mozilla/4.0 (Windows XP 5.1) Java/1.6.0_32" "GET http://cona.com/removal/stops-followed-forces.php?If=3030562f53&We=2i2j55302f2h322g2e52&i=2d&FE=V&ma=p HTTP/1.1" - - "-" "Mozilla/4.0 (Windows XP 5.1) Java/1.6.0_32" "GET http://www.champagnekopen.nl/wp-content/uploads/2013/07/tr2.jpg HTTP/1.1" - - "-" "Internet"
The first request is to conrad.nl which responded with the malicious IP. This is followed by a request to the Blackhole exploit kit landing page via the initial iframe. After the script on the landing page is executed it does a request to (in this example) retrieve a JAR file to exploit the vulnerable java version. When the Java has been exploit it does a final request to the exploit kit retrieving the initial payload. Moments after downloading this the initial payload downloads a secondary payload which contains the Tor powered malware, note the sudden change of useragent to “Internet”.
The malware dropped communicates using the Tor network to various command and control servers, hashes for the files seen being dropped by the exploit kit:
d758fd8cfb80a458a43770037ec82aac
1af107152eda9cc870c639a5b1c3c466
The initial binary dropped from the exploit kit contacts the following two domains to download a 2nd stage payload:
http://champagnekopen.nl/wp-content/uploads/2013/07/tr2.jpg http://panningendeavor.net/tr2.jpg
Cleanup
The old instructions previously stated in this post might not work for updated versions of the malware, we are advising HitmanPro.Kickstart to clean up your PC.
Lennart Haagsma & Yonathan Klijnsma, Security Specialists at Fox-IT
Rob, while we have a pretty good idea and can speculate on what happened, it is not our place to report on that, it is up to the affected parties to come forward and disclose information about the incident.
Nice that you investigated the malware, but I think it would be more appropriate to make
a detailed analysis of how this could happen in the first place (the modification of DRS I mean).
Is it really true that access to DRS is authenticated only by username and password?
Is that considered acceptable given the importance of the .nl zone?
Was the attack made using stolen password, guessed password, etc?
That is of more importance than the malware issue.