As we know, the recent Operation Aurora has been making waves due to a highly organized attack targeting companies such as Google, Adobe and other high profile companies. A security breach due to a vulnerability in Microsoft’s Internet Explorer, CVE-2010-0249, caused remote code execution leading to download of malware on compromised systems.

At McAfee Labs, researchers have been working around the clock across regions to delve deeper into the inner workings of this attack in an effort to educate and assist customers in its mitigation. In this blog we discuss the communication protocol being utilized by Aurora which depicts how organized and technical this attack is.

We also discuss the backdoor components of Aurora which would allow the hackers to take complete control of the victim’s machine. The backdoor components, which were dropped in the system by Roarur.dr after the successful exploitation by Exploit-Comele, are composed of several variants of Roarur.dll.

All samples used highly obfuscated code, with small pieces of code connected via jumps and calls, and separated by NOPs:

One thing in common between these DLL variants is the protocol used to communicate with the command & control server. Let’s take a look at how this protocol works.

After the initialization of the malware DLL, a connection is made to the command and control (C&C) server. The connection is made on port 443 which is usually used by the HTTPS protocol, encrypted with SSL. During analysis, we noticed that the employed protocol on this port was not the standard SSL protocol, but a custom encrypted protocol.

The backdoor client initiates the protocol by issuing a packet which always has the same first 20 bytes:

[ ff ff ff ff ff ff 00 00 fe ff ff ff ff ff ff ff ff ff 88 ff ]

After the initiator handshake, the protocol uses a 20 byte packet as header for all communication that follows. All data sent from client to server is encoded with a logical NOT, and all data received from server is XOR encoded with 0xCC. So the first reply from server would be:

[ CC CC CC CC CD CC CC CC CD CC CC CC CC CC CC CC XX XX XX XX ]

(where XX can represent any byte)

The handshake is followed by information gathering. The backdoor gathers the following information from the victim’s machine and sends it back to the server:

• Content of HARDWARE\DESCRIPTION\System\CentralProcessor\MHz registry key
• Service pack name
• Machine name
• OS Version

At the time the operation was made public by Google, the control servers were offline, hence we don’t have access to the actual communication. However after understanding the protocol and the expected commands at the client end, we were able to set up a fake environment allowing us to initiate commands to the client. In this way we were able to force the malware to behave in a way we requested.

Based on this, we found that the structure of the header is the following:

Commands can have any value between 0×02 and 0×14, which gives the hacker 18 possible commands. But these commands can be extended by the use of the parameters, which change the behavior of the command executed:

One interesting note on the protocol is the fact that each client uses a different encryption key to obfuscate the data sent to server. It makes a call to GetTickCount() to generate a random encryption key which is sent as part of the header in the outgoing packet. This key is used to encrypt the data between client and server afterwards. Indeed an interesting approach.

The “extra data” part of the packet can contain any information the hacker wants. Based on the commands executed, this could be which drives/files the user has on the system, information to install a new service, or even a file to drop on the system.

The transmission of this extra data is made in two steps:

• The backdoor receive the header, decrypts it with XOR 0xCC and gets the command
• The command is executed
• Based on the command, if there is extra data to receive, get the extra data size and check if the encryption key is the same as the one sent before
• Apply a XOR 0xCC decryption to the Extra Data.
• Decrypt with given encryption key

We believe this is how the file Acelpvc.dll was dropped on the system. This is another backdoor component which can be installed as a service and receive two parameters: IP and port.

Acelpvc.dll, once loaded, opens a connection on this server:port using the same encrypted protocol. This way, the hackers could make the victim’s computer connect to another server and guarantee his access to the system even if his connection is cut.

As you can see this attack involved very advanced methods with several pieces of malware working in concert to give the attackers full control of the infected system, at the same time it attempts to disguise itself as a common connection to a secure website. This way the attackers were able to covertly gather all the information they wanted without being discovered.

Hopefully this brief will provide users with a good basic understanding of the custom backdoor protocol used during Operation Aurora. Stay tuned for more information on Aurora as McAfee dissects it 

Update Jan 19, 2010 (product coverage update)
McAfee Network Security Platform: The UDS release of January 19 contains the signature “UDS-BACKDOOR: Operation Aurora Channel Detected” to detect this backdoor.