- About us
- Code of Conduct
- Google SoC
- Recent posts
- Security Workshops
First, we will investigate our observation of non-deterministic behavior of malicious web servers. Repeated interaction with a malicious web server did not consistently yield malicious behavior. Analysis of MPack/ IcePack exploitation kits allows us to - at least partially - explain this behavior.
Figure 3 - MPack Administrative Interface
MPack can be configured via the $BlockDuplicates option to only deliver an attack to a user it hasn't seen before. If this “IP tracking functionality” is enabled, MPack exectutes the CheckAddUser function shown in Figure 5 . The user's IP address with the browser identifier are hashed (line 08) and stored in the MPack database (mysql or txt file) (lines 48-49 and 23-25). Upon repeated visits by the user with the same IP address and browser identifier, the hash is once again generated and checked for existence in the MPack database (lines 15 and 29, 30, 41-42). If it is found, an “unhappy” emoticon is displayed and no attack is delivered (line 17 and 44). (Similar functionality exist in IcePack .)
The CheckAddUser function explains why certain URLs are malicious and then permanently go dormant. However, this would not explain URLs that exhibit malicious behavior, temporarily go dormant (maybe one or two requests), but then exhibit malicious behavior once again; this is a pattern we observed in our study. To explain this observation, we turn to an additional attack technique of Fast-Flux networks, which we more extensively describe in our Know Your Enemy: Fast-Flux Service Networks paper. Fast-Flux networks are networks computer systems with public DNS records that are constantly changing. If a malicious URL is part of such a network, it might resolve to actual different physical machines, which will only have access to their local IP tracking database. If a client honeypot accesses the same URL repeatedly, it might actually interact with several physical machines that each trigger initially, but then permanently go dormant. From the client honeypot's view, however, it appears as if it is sporadically attacked.
Figure 4 - CheckAddUser Function