We have discussed several real world examples captured in the wild. Now let’s take a closer, more detailed look at an incident. In this case, we deliberately infected a honeypot system with a fast-flux agent. The system was contained in a controlled Honeywall environment. The malware we used was called weby.exe and had the MD5 hash 70978572bc5c4fecb9d759611b27a762 . The binary was executed in a sandbox environment with a Honeywall gateway providing data control and data capture capabilities. Post-infection analysis of the captured system and network data identified the following activity:

1. First, the system resolved the domain name This is most likely a basic Internet connectivity check. The malware component needs to first determine that it has access to the Internet and DNS is resolving.

2. The malware binary then registers with its owner. This is performed by connecting to a virtual web host with an HTTP GET request and a URL query string that contains information about the infected host. This is not a Command and Control (C&C) channel, instead it is nothing more than an announcement to the malware administrator that another victim system has been successfully infected. The HTTP GET request was submitted with the following form (query string named variable values are omitted). The complete HTTP GET request is shown in Appendix C, where we show a full example of a registration request by a flux-agent. &user= &status= &version= &build= &uptime=

3. The fast-flux registration server (mothership) response to the announcement/registration step is “Added Successfully!” This we perceive to mean that the infected system has been successfully added to the fast-flux service network. A new victim is standing by for malicious duty.

4. The next step is for the infected system to obtain a configuration file by hourly polling of a settings file on a remote web server. This is where the flux agent learns details including what ports to bind and where the mothership is located and which incoming traffic will be redirected upstream to the mothership. In this case, the fast-flux agent submits a HTTP GET request to another virtual web host that only happens to share the same IP as used by the registration interface.

For which the server responds with what appears to be a consistent 197 byte binary/encoded configuration response. We are still attempting to reverse engineer complete details of this session. For full packet payload of the binary/encoded configuration response, please refer to Appendix D.

5. Finally the system downloads a suspiciously named DLL plugin_ddos.dll, whose naming might suggest to some that it is a denial of service component. For more information on this session, refer to Appendix E.