- About us
- Code of Conduct
- Google SoC
- Recent posts
- Security Workshops
In our previous KYE study, we observed that malicious web pages usually do not host the attack code directly. Rather, the attack code is being imported onto the “front-end” page (for example, via iframes), or the user is redirected to the attack code, as shown in Figure 6 . IcePack and MPack confirm that this is common practice as it explicitly supports this structure in the statistics the tool collects. Every front-end page sends information about itself to the exploit server via the HTTP Referrer header, which is then recorded by the IcePack and MPack tool and visible on the statistics page as shown in Figure 3 and Figure 5 . The attacker, as a result, can determine which front-end pages drive the most traffic to the exploit server and, equipped with this information, “marketing campaigns” or specific hacking attempts can be focused to effectively increase the attack success rate.
Usually the administrators of these front-end pages are not even aware that they are hosting code that includes or redirects to malicious content. These front-end servers might have fallen to victim to an attack themselves in which the attacker modifies the pages or, more covertly, performs man-in-the-middle attacks, such as ARP spoofing , to include the malicious content. In the case of ARP spoofing, the administrator of the web page cannot find any direct evidence of malicious pages on the web site, but users are attacked nevertheless. Tools that allow an attacker to perform automated ARP spoofing, such as HTool and zxarps , have been reported to be bundled with the MPack web exploitation kits, although we ourselves did not obtain a copy of such a tool.
Figure 5 - Administrative Interface - Referer [sic] Stats
Figure 6 - Redirect to Exploit Server
Knowledge about these exploit servers is of high value. SANS Internet Storm Center identified a MPack attack in the middle of 2007 that showed 10,000 referral domains ,. This means that 10,000 web pages pointed to one exploit server. That is a high number. A live MPack server we found on the web (http://www.cordon.ru/mp/admin.php), “only” listed 504 referer URLs. A security administrator that is able to identify these servers will be able to greatly reduce the risk of infection by simply blacklisting these central exploit servers, effectively defusing risk of infection of the many front-end web pages that users potentially could come across.
Identification of these servers is simple. Since the exploitation kits consists of various PHP pages that host specific content, one can easily find exploit servers using a low interaction client honeypot, such as HoneyC . We performed such a search on several thousand known malicious URLs (sourced from stopbadware.org and mvps.org ). For each URL, we checked for the existence of an admin.PHP page (the page to the administative console of MPack v0.94), as well as the specific string “All activity is being monitored", which can be found on these PHP pages. We were able to identify several MPack servers as shown in Table 2 . Note that a search of this type was performed within a few hours on an average desktop PC using our low interaction client honeypot, HoneyC. The Snort signature used, which can also be used in the Snort Intrusion Detection System, is shown in Figure 8 .
Figure 7 - Snort Signatue MPack 0.94
Search engine queries can also be used. Apparently a simple query that checks for `intitle: “Web Attacker Control”` used to result in several WebAttacker stats pages on Google .In October 2007, however, Google doesn't return any results; and Live Search only returns one defunct instance of WebAttacker. Since search engines adhere to robots' directives and do not index standalone pages, the coverage is likely to be low and a low interaction client honeypot would be the preferred method of identifying a exploit server.
|Hosts MPack (password protected stats page)|
Table 2 - Identified MPack Hosts