W32.Xpaj.B is a File Infector with a Vengeance

We have recently come across a new wave of W32.Xpaj.B samples. We first met this complex file infector virus in 2009, and since then the threat has been operating and mounting an ad-clicking scam in order to generate revenue.

After a few months of rest, the threat seems to be back.
 

Figure 1. Increase in activity of W32.Xpaj.B in the wild, the spike is from January 22, 2012

It also appears to contain new weapons in its arsenal as the threat can now also perform the following actions:

This is not entirely unexpected: kernel mode code was already present in the old version of the W32.Xpaj virus, but it was inactive. In October 2011, I gave a presentation at the Virus Bulletin conference about the analysis of this file infector virus wherein I pointed out how the threat contains code that can potentially run in kernel mode. I also suggested the possibility that future versions of the virus may shift to kernel mode.
 

Figure 2. Inactive kernel mode code from the old W32.Xpaj.B variant

It is now about six months later and the malware authors have not disappointed us!

We should clarify two points:

  • no 64-bit executable or .dll has been observed to be infected
  • no 32-bit or 64-bit driver has been observed to be infected

Even if the virus targets 64-bit Windows computers, the infection seems to be limited to 32-bit executable modules only. The same goes for the drivers: the old version of the virus did not infect kernel mode drivers, nor does the new one. Therefore, the kernel mode code is not the result of infected drivers, but it is only loaded through the infected MBR, both in 32-bit and 64-bit Windows.
 

Figure 3. The presence of the virus compressed entry in the kernel memory in the top right (which contains an executable), and in the bottom you can see a hook on the kernel API NtWriteFile (this test was performed in 64-bit Windows XP)

These are only the results of a preliminary analysis, investigation is still ongoing to fully understand the new functionality of this variant.

Interesting patient zero of the pandemic

The sample we analyzed is the one that was described in BitDefender’s blog (md5: d5c12fcfeebbe63f74026601cd7f39b2). It turned out to be a pretty interesting sample: normally we receive files that are legitimate executables (or executables of any kind) that have been infected by W32.Xpaj.B. In this case though, the sample is not an infected executable, but it seems to be an executable that was created specifically to contain only the W32.Xpaj.B infector code. The difference with normal W32.Xpaj.B infections is pretty obvious:

This sample Normal W32.Xpaj.B infected sample
  1. The viral body is buried under a layer of PECompact 2 packer
  2. The viral body begins with a small loader
  3. The .exe file contains only the virus body and some fake data and strings
  1. The viral body is in the outer layers of an executable
  2. The viral body begins with a stack-based virtual machine
  3. The .exe file contains the virus body and the original executable code and data

 
So, in short: this .exe file was manually crafted in order to contain the virus body, as well as some fake strings and data that mimic some legitimate executable files. A loader was then added to the entry point of the .exe file in order to decrypt and load the virus body (and this loader is different from the one you would normally see in an infected sample). Finally, the .exe file has been packed with PeCompact 2.

Could this just be the structure of the new variant? No. Besides the fact that there is no original executable code or data aside from the virus body, once run, this sample does generate normal W32.Xpaj.B infections. This sample is one of a kind. In fact, we believe that this could be the “patient zero” of the new infection: the sample that was manually created and spread by the malware authors themselves.

Wolf changes its coat, but not its ways

The whole behavior of the virus seems to be the same as the old one: when run, it contacts the domain nort[REMOVED].com, which at the moment resolves to an IP address located in the Virgin Islands. The network communication seems to be similar to the old variant.
 

Figure 4. HTTP POST request of an old sample (top) versus one from the new sample (bottom)

The data is encrypted, the URL pages and parameter names look like randomized strings, the data begins with a string indicating a randomly name file, etc.

It is likely that the purpose of the virus is still the same: an ad-clicking money-making scam. Investigation is ongoing.

Google’s ‘Engineer Doe’ Known for Wi-Fi Hacking Tool

The Google engineer who built its Wi-Fi sniffing software has been identified. Photo: Sign Language/Flickr

The author of a software program credited with bringing war-driving to the masses was Google’s Engineer Doe, the author of the company’s controversial Street View Wi-Fi logging program, according to a report in The New York Times.

The Google engineer who built the software, identified until now only as “Engineer Doe,” is Marius Milner, the Times said, citing an unnamed former state investigator working on a Street View inquiry.

The practice of driving around cities and logging open wireless access points is known as war-driving, and that’s essentially what Google ended up doing with its Street View program. In the early days of Wi-Fi, it was a way to find open connections that could be used to get online for free.

Milner, a software engineer with Google since 2003, is well known within the wireless-hacking community, according to Brad Haines, an independent security consultant known as RenderMan who has spoken on wireless hacking.

In an audit made public in 2010, Google called its Wi-Fi logging software Gstumbler. In retrospect, that should have been a tip-off.

Back in the early 2000s, Milner wrote NetStumbler, a Windows tool that could be used to pinpoint wireless networks. Netstumbler was the first relatively easy-to-use Windows war-driving tool. “You still needed a very specific [wireless] card but it had a nice GUI (graphical user interface),” Haines says. “It was that iterative step of making it more accessibile to people.”

What got Google into trouble, though, was its practice of indiscriminately logging wireless packets with its Street View cars between up until 2010. Google recorded any data traveling on unsecured wireless networks at the moment the car drove by, which included full e-mails and passwords.

Ironically, Milner’s NetStumbler software wasn’t up to the task of war driving at Google-scale. It simply didn’t do the packet sniffing Google needed to grab information. So instead Google and Milner based the Street View system on a more powerful Linux program, called Kismet, that could.

Google needed more powerful software to log the unique identifiers of routers — even ones with faint signals — to help it build its geolocation services. Doing so does not require logging the contents of the packets.

Street View engineers intentionally stored the content on Milner’s hunch that it could be useful to know what websites people were visiting. That’s what attracted the attention of government authorities, including the United States’ Federal Communications Commission and the Department of Justice and the Federal Trade Commission. Data privacy authorities in France, Germany and South Korea, among others, also investigated the company.

The FTC, the FCC and the DoJ all cleared Google of violating federal wiretap laws with the program, though the FCC did fine Google $25,000 for impeding its investigation.

Google has said that it didn’t know exactly what was being logged by the Street View cars until two years ago, when German authorities asked for details. Google immediately said the packet logging was a mistake. However, the FCC document makes it clear that Milner informed his superiors about the data he wanted to collect and that someone should talk to Google’s privacy lawyers about it beforehand. That conversation never happened and the project manager told the FCC that he did not read the design document.

Milner’s lawyer declined to comment.

A “LNK” to the Past

Contributor: Fred Gutierrez

Cybercriminals have continuously evolved their methods throughout the years to avoid detection and arousing the suspicion of the users they are targeting. In the case of targeted attacks, the lure is a critical piece of the puzzle, as cybercriminals need to be sure they can get the attention of their target so they can convince them to run malicious PDFs or DOC files.

We have been monitoring malicious emails which use Tibetan protests and self-immolations as its lure. The emails contain a RAR file with photographs supposedly taken from the protests.

Once the targeted user extracts the files onto their computer, they will notice only three files in the extracted directory. These are JPG files, or so they might think. In actuality, the files presented to users are .lnk files, which are shortcuts:
 

Figure 1. LNK files seen when the RAR is extracted
 

The files have been carefully named in order to trick the user into believing they are JPG files. By default extensions are hidden, so the actual .lnk extensions are not observed by the user.
 

Figure 2. Show hidden files reveals additional files are present
 

In addition to the hidden extensions there are hidden files in the same folder. When we enable hidden files to be viewed, we see there are some legitimate JPG files present, as well as a thumbs.db file. Thumbs.db is a file normally used by Windows to store thumbnails of images in the directory. However, this thumbs.db was not generated by Windows—it is malicious—as it was purposely included in this archive by the attackers.
 

Figure 3. Contents of the LNK file shows it executes thumbs.db and the associated JPG file
 

When we examine one of the .lnk files in the folder, we see it calls the Windows Command Prompt to execute the start command. This command is passed the thumbs.db file along with the corresponding image (in this case, IMG_3915.jpg) as its parameters. Therefore, when the user double clicks on the .lnk file, they expect an image to appear, and it does, as they are presented with an actual image from a Tibetan protest. However, the thumbs.db binary (detected as Trojan.Dropper) is also executed, which drops multiple files onto the compromised computer.

The files dropped vary. One of the files drops an executable called iexplore.exe into the Application Data\Active folder. It also drops a .lnk file into the Startup folder pointing to the location of the malicious iexplore.exe (detected as Trojan Horse). Another file is a .dll file (detected as Backdoor.Trojan) that opens a back door. It attempts to collect computer information, such as the OS version, CPU, memory, and user name.

It should be noted we have not seen the malicious thumbs.db file being used in other targeted attacks. This is a deviation from the norm, as many of the attacks we see through email tend to rely on malicious DOC and PDF files to exploit a vulnerability.

This is just one example of how cybercriminals are experimenting with new ways of social engineering. It won’t be the last.

Google Releases Chrome 18.0.1025.168

Google has released Chrome 18.0.1025.168 for Linux, Macintosh, Windows, and Google Chrome Frame to address multiple vulnerabilities. These vulnerabilities may allow an attacker to execute arbitrary code or cause a denial-of-service condition.

US-CERT encourages users and administrators to review the Google Chrome Releases blog entry and update to Chrome 18.0.1025.168.

This product is provided subject to this Notification and this Privacy & Use policy.