In a nutshell, Clampi is an Infostealer threat. Its executable can be seen as a host for separate modules, containing the real payloads of the threat. These modules are heavily protected from reverse-engineering as well. The functionalities range from banking-site password stealing, to local credential gathering, to a SOCKS proxy. The communication with Clampi’s command & control servers, the “Gates”, uses HTTP and is encrypted. Clampi...
Clampi goes to unusual measures to bypass the local firewall on the compromised computer, such as the Windows Firewall. Usually, such firewalls allow only specific programs to communicate using specific ports and protocols. For instance, your browser would be allowed to use outbound TCP port 80.
As we’ve previously discussed, Clampi needs to communicate with a “Gate” gateway server in order to get its orders and send information. Any firewall would block the program if it tried to connect to the outside world. Bypassing this can be done in many ways, the most common one in the malware world being to add an entry in the Windows registry, added the program to the trusted file list.
The Clampi gang decided to inject their networking code into Internet Explorer, which is granted Web access by any standard firewall configuration out there. Fair enough—that’s another approach, but not a new one. Yet you’ve seen these guys don’t do...
Today, we’ll discuss the two remaining Clampi modules used for replication and traffic relay capabilities. The SOCKS module is very straight-forward—it’s a SOCKS proxy server. Normal SOCKS proxy servers act as a connection relays and are used for many purposes, such as connection filtering, passing traffic through firewalls, or to maintain anonymity.
The server’s code is injected into an instance of Internet Explorer. It then listens for incoming connections on a random TCP port above 5000. The SOCKS module is activated in response to a control server’s command. The client then sends the port it’s listening on for inbound connections to the proxy server:
In the above example, the SOCKS server will be listening to port 38329 (which is 0x95B9 in hexadecimal base).
This chapter in our Clampi saga brings us back to the malware’s logging facility. As we saw before, one of Clampi’s modules, codenamed LOGGER, is responsible for logging outgoing information going to a determined list of URLs – stored in a data file as CRCs.
One problem arises with banking sites that preprocess the user’s personal information before sending it over HTTPS—it’s done using client-side JavaScript. For instance, a hash of the input PIN number could be sent instead of the PIN number itself. This mechanism adds an extra layer of security, preventing malware from sniffing network traffic at one end of the SSL tunnel. But still, it’s only covering one end. It’s more secure than no encryption, but still not great. At least two methods exist to get around this:
Let’s continue our Trojan.Clampi blog series by discussing three more modules downloaded and executed by Clampi. These modules share the common goal of gathering information, private or not, contained on the compromised computer. They don’t intercept network traffic like the Logger module does (described in my previous blog).
The PROT module
This module gathers private information from several sources, including Protected Storage (PStore), which contains user credentials stored by Internet Explorer or Outlook for instance. Interestingly, it also sets specific registry values in order to facilitate the creation of new entries in the PStore.
For instance, it sets the following registry entires:
As mentioned in our previous blog entry, most of the Trojan.Clampi features reside in separate modules that are sent by a remote server in response to clients’ queries. In this part of this blog series, we’ll have a look at one of the modules used by the malware to steal login credentials mostly from banking Web sites.
This module is codenamed LOGGER by the threat. After decryption, the beginning of the module’s raw data looks like this (compressed):
To avoid downloading the module each time Clampi runs, it is stored in the registry (in an encrypted form) in a value named “Mxx”, where “xx” is a zero-based number...
Trojan.Clampi is one of the hottest malware around, and as such, received a fair amount of media coverage, as well as technical reports describing some of its functionalities. As part of our ongoing blog series, we will be discussing interesting and rarely presented aspects of Clampi. Today, we’ll introduce an important aspect of Clampi: the network communication.
First of all, if you’re not familiar with this malware already, Clampi is a Trojan horse whose main purpose is to steal private information: user passwords, login credentials, software licenses, credit card numbers, bank account information, etc. Note that Clampi’s operations are performed by helper modules, downloaded by the main executable, and stored in the Windows registry.
Once the threat is installed on a computer, it connects to one of the gateway servers listed in the registry value “GatesList...
The latest variants of Peacomm, detected as Trojan.Peacomm.C (or proactively, as the usual Trojan.Packed.13), have introduced some interesting changes in the way they infect a machine.
As was written in a previous blog entry ,Peacomm spam entices users to visit a Web page containing a link to afile applet.exe. This Web page also embeds an obfuscated JavaScriptroutine that tries to exploit a Windows Media Player vulnerability, incase the user decided – very wisely – not to download and run the socalled “Secure Login Applet”. If the vulnerability is exploitedsuccessfully, a small file will be downloaded on the compromisedmachine, which will in turn download applet.exe. Both files aredetected as Trojan.Packed.13...
Trojan.Packed.13,or TP13 as we call it internally, is associated with some of the mostwidespread malware in 2007. Though its heuristic detection may beobscure, its related threats are now well-known: Trojan.Mespam,Trojan.Galapoper, and more importantly, the infamous Trojan.Peacommfamily of P2P malware.
Simply put, it consists of a set of heuristics to detect Trojansprotected with an unknown packer. We didn’t have a name, so we gave itthe number 13… Bad luck, perhaps, either for us or its authors.
This packer has several features that differentiate it from others.It is widespread, very frequently updated, and uses originalanti-emulation tricks to fool anti-virus software detections (such asdummy loops calling obscure Windows APIs). The packer is not publiclyavailable and we analyze it indirectly through threats that use it.Malicious files are usually repacked...
