As everybody has said and repeated, on April, 1st 2009, the latest variant of the Conficker worm will begin to generate domain names to try to connect to and retrieve a potentially malicious payload.

We saw that the new update mechanism is now based on the generation of 50000 domain names per day, among which 500 will be contacted to try to download an update. Statistically, this corresponds to updating 1% of the infected machines by registering a unique domain name. Would the authors be willing to reduce their botnet to 1% of its size?

Not at all! The obfuscated functions in the worm are used by an impressive Peer-to-peer communication mechanism, allowing Conficker to communicate with its peers to propagate an update. The small percentage of machines that have downloaded an update through the domain names could communicate it to all other machines in (relative) discretion.

This mechanism, previously studied by the SRI, is based on several threads managing communications with other peers, including two threads dealing with UDP communications and two threads for TCP communications. Observation of UDP packets sent through the Internet gives the impression of a pair of randomly generated IP and port, and it would be interesting to find a link between the address and the port, in order to have an effective detection of the P2P traffic of the worm.

Once we have traced the different threads, we always encounter the same function to generate the different ports, based on the IP address of the infected machine and a parameter that we will determine later.

This large cryptographic-looking block is present twice in the function. The first block only takes into account the host's IP address (in the eax register on the previous screenshot), and generate a first pair of TCP / UDP ports in esi and esi+4. They only depends on the IP address. Before entering the second block, we note that the register eax is xored by the first argument of our generation function.

The second block is nearly identical to the first, and results in the generation of a new pair of TCP / UDP ports in esi+8 and esi+C.

The argument passed to our function is the result of the function called just before. Studying it shows that its result is in edx in the following screenshot:

eax contains the timestamp of the current date. We note that the value 0x54600 is subtracted from our timestamp, which is the number of seconds in 4 days. The timestamp is then multiplied by 0x6EF5DE4D then edx is shifted by 12 bits to the right. These two operations are in fact a compiler optimisation to perform a division by the value 604800, which corresponds to the number of seconds in a week. Our parameter is identified, it is the number of weeks since the 1st January 1970!

Now that this information is available, it is possible to create a tool taking an IP address and a date as parameters to determine pairs of TCP and UDP ports used by the peer-to-peer mechanism at that date and for this address.

lexsi:~/conficker$ ./conficker_ports 192.168.111.2 05 02 2009
Used UDP ports : 45804 / 35543
Used TCP ports : 17116 / 62114

lexsi:~/conficker$ nmap 192.168.111.2 -P0 -p 1-65535
Interesting ports on 192.168.111.2:
PORT      STATE SERVICE
135/tcp   open  msrpc
139/tcp   open  netbios-ssn
445/tcp   open  microsoft-ds
17116/tcp open  unknown
62114/tcp open  unknown

This enables us to determine if unidentified traffic is due to Conficker or not, ensuring that the IP address and port are in accordance with the algorithm. Better yet, it is possible to scan the network, looking for TCP ports opened by the worm, which be very wise one day before the beginning of Conficker's update!

Note that publishers of rogue security software begin to use the buzz around conficker to distribute false removal products.