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.
- Setting up a keylogger using either software (driver/user-mode hooks) or hardware (wire-tapping). This is the generic approach.
- Grabbing the user information before it gets processed. This is non-generic, Web site-specific approach.
The Clampi gang decided to go with the second method and created another module named “LOGGEREXT” (which obviously stands for ‘Logger Extended’).
After reverse-engineering, guessing, and correlating elements with what we found out when analyzing the LOGGER module, we were able to figure out the data file’s file format. Here’s an entry:
offset=498, id=35, flags=83, count=1
type=3, len=17, crc=C1008A17
As for the LOGGER module, each entry contains one or more URL’s CRC and length, as well as a type. HTML blocks may follow, containing the original HTML code and what it should be replaced with. The example above has two HTML entries: they indicate that the tags </body> or </BODY> should be replaced by a <script> stub, followed by the closing </body> for coherence.
This replacement will occur when the user browses a URL whose type 3 length and CRC are 17 and 0xC1008A17, respectively. Note that using type 3 CRCs means any part of the URL’s top section can be matched. The preceding “.” is not required.
Let’s examine the injected code carefully:
- It retrieves the “idPassPhrase” element, if found. It creates a hidden HTML <input> tag, names it “idPassPhrase_2”, and then attaches it to the DOM.
- It does the same thing for the “Password” element.
- It then calls the original doEncryption(), saved in the global variable doEncryption2.
When the data is sent to the server, the POST (or GET) fields will include two additional fields, ‘idPassPhrase_2’ and ‘Password_2’, containing the passphrase and password before encryption. Et voila!
The current data file that LOGGEREXT uses contains exactly 78 entries. It’s worth noting that only 25% of them have HTML replacement stubs, which is fairly strange.
One last thing to mention: the list appears to be old, as some URLs contained in the HTML stubs have outdated version numbers. For instance, for a well-known UK bank, a (partial) match is done on the "PC_7_1_5L9_cam10To30Form" substring. We found the page that’s intended to be hooked, but it now contains the value "PC_7_2_5PF_cam10To30Form".
The next blog will discuss the two remaining modules. Stay tuned!