Breaking Dridex Malware With Excel Macro Password Exploit

March 20, 2015 by Rick Osgood 17 Comments

[Ronnie] recently posted a new chapter in his adventures in malware deconstruction. This time the culprit was an infected Excel spreadsheet file. The .xls file was attached to a phishing email claiming to be related to a tax rebate. With tax season in full swing, this type of phishing message would be likely to be opened by an inexperienced user.

[Ronnie] saved the file to a virtual machine to prevent his real workstation from getting infected. He then opened it up in Excel and noticed that it immediately attempted to run macros. A macro is essentially visual basic scripting that runs inside of the spreadsheet file. You can use it for simple automation, cell formatting, or do even more complicated tasks like reach out to external websites and pull information. This malware focused on the latter.

[Ronnie] used the alt + F11 shortcut to view the macros. Unfortunately the attackers had password protected them. [Ronnie] wouldn’t be able to view the macro code without knowing the password. Luckily, he learned of a surprisingly simple trick to completely bypass the macro password. He opened up the .xls file in Notepad++ and located three keys; CMG, DPB, and G. [Ronnie] then created and saved a new blank .xls document and password protected the macros with his own password. He opened up this new file in Notepad++ as well, and located those same three keys. He copied the keys from the new file into the old one, and saved the old file. This effectively changed the password of the malware file to the new one he had set for his new file. This is a nifty trick that apparently only works on the older .xls formats, not the newer .xlsx format.

After loading the macros, [Ronnie] quickly noticed that most of the code was obfuscated to make it difficult to analyze. There were, however, three named modules that reference possible sandbox evasion techniques. The malware first invokes these functions to detect the presence of a virtual machine or other type of sandbox. If it detects nothing, then the rest of the malware program is decoded and executed. [Ronnie] removed these checks and then executed the macro to verify that his change had worked.

The next step was to try to view the decoded instructions. The decoded gibberish was saved to a variable. The simplest way for [Ronnie] to view the contents of the variable was to have the program create a pop-up box that displayed the contents of that variable. After making this change and running the program again, he was able to see exactly what the malware was doing. The code actually invoked Powershell, downloaded a file from the Internet, and then extracted and executed that file. In the full write-up, [Ronnie] goes even further by downloading and analyzing the executable.

Decoding ZeuS Malware Disguised As A .DOC

March 6, 2015 by Rick Osgood 30 Comments

[Ronnie] recently posted about his adventures in decoding malware. One of his users reported a phishy email, which did indeed turn out to contain a nasty attachment. The process that [Ronnie] followed in order to figure out what this malware was trying to do is quite fascinating and worth the full read.

[Ronnie] started out by downloading the .doc attachment in a virtual machine. This would isolate any potential damage to a junk system that could be restored easily. When he tried to open the .doc file, he was presented with an error stating that he did not have either enough memory or disk space to proceed. With 45GB of free space and 2GB of RAM, this should not have been an issue. Something was definitely wrong.

The next step was to open the .doc file in Notepad++ for analysis. [Ronnie] quickly noticed that the file was actually a .rtf disguised as a .doc. [Ronnie] scanned through large chunks of data in an attempt to guess what the malware was trying to do. He noticed that one data chunk ended with the bytes “FF” and D9″, which are also found as the ending two bytes of .gif files.

[Ronnie] copied this data into a new document and removed all new line and return characters. He then converted the hex to ASCII, revealing some more signs that this was actually image data. He saved this file as a .gif and opened it up for viewing. It was a 79KB image of a 3D rendered house. He also found another chunk of data that was the same picture, but 3MB in size. Strange to say the least.

After finding a few other weird bits of data, [Ronnie] finally started to see more interesting sections. First he noticed some strings with mixed up capital and lowercase letters, a tactic sometimes used to avoid antivirus signatures. A bit lower he found a section of data that was about the size of typical shellcode. He decoded this data and found what he was looking for. The shellcode contained a readable URL. The URL pointed to a malicious .exe file that happened to still be available online.

Of course [Ronnie] downloaded the .exe and monitored it to see how it acted. He found that it set a run key in the registry to ensure that it would persist later on. The malware installed itself to the user’s appdata folder and also reached out repeatedly to an IP address known to be affiliated with ZeuS malware. It was a lot of obfuscation, but it was still no match for an experienced malware detective.

Lenovo Shipped PC’s With Spyware That Breaks HTTPS

February 19, 2015 by Rick Osgood 91 Comments

If you’ve ever purchased a new computer then you are probably familiar with the barrage of bloatware that comes pre-installed. Usually there are system tools, antivirus software trials, and a whole bunch of other things that most of us never wanted in the first place. Well now we can add Superfish spyware to the list.

You may wonder what makes this case so special. A lot of PC’s come with software pre-installed that collect usage statistics for the manufacturer. Superfish is a somewhat extreme case of this. The software actually installs a self-signed root HTTPS certificate. Then, the software uses its own certificates for every single HTTPS session the user opens. If you visit your online banking portal for example, you won’t actually get the certificate from your bank. Instead, you’ll receive a certificate signed by Superfish. Your PC will trust it, because it already has the root certificate installed. This is essentially a man in the middle attack performed by software installed by Lenovo. Superfish uses this ability to do things to your encrypted connection including collecting data, and injecting ads.

As if that wasn’t bad enough, their certificate is actually using a deprecated SHA-1 certificate that uses 1024-bit RSA encryption. This level of encryption is weak and susceptible to attack. In fact, it was reported that [Rob Graham], CEO of Errata Security has already cracked the certificate and revealed the private key. With the private key known to the public, an attacker can easily spoof any HTTPS certificate and systems that are infected with Superfish will just trust it. The user will have no idea that they are visiting a fake phishing website.

Since this discovery was made, Lenovo has released a statement saying that Superfish was installed on some systems that shipped between September and December of 2014. They claim that server-side interactions have been disabled since January, which disables Superfish. They have no plans to pre-load Superfish on any new systems.

BadUSB Means We’re All Screwed

October 5, 2014 by Mike Szczys 138 Comments

Does anyone else get the feeling that the frequency of rather horrible vulnerabilities coming to light is accelerating? Off the top of our head, there’s Heartbleed, Shellshock, and now this one. The BadUSB exploit attack stems from the “invisible” microcontroller in most USB devices.

We first heard about it when we were attending DEFCON in August. The exploit had been announced the same week at Blackhat but there wasn’t much information out yet. Now the talk has been posted and there’s a well-explained overview article at Big Mess o’ Wires.

Here’s how this one goes: all USB devices rely on a microcontroller to handle the peripheral-side of USB communications. The computer doesn’t care which microcontroller, nor does it have a way of knowing even if it wanted to. The uC is “invisible” in this situation, it’s the interface and data flowing through it that the computer cares about. BadUSB is an attack that adds malicious functionality to this microcontroller. To the computer it’s a perfectly normal and functional USB device, while all the bad stuff is happening on the peripheral’s controller where the computer can’t see it.

How deeply do you think about plugging each and every USB device? Check out what happens at 19:20 into the video below. The USB device enumerates and very quickly sets up a spoofed Ethernet connection. You can still load a webpage via WiFi but the fake connection is forwarding packets to a second server.

Once discovered, you can wipe the computer and this will stop happening; until you plug the same device again and reinfect. Worse yet, because the controller is invisible to the computer there’s almost no way to scan for infected devices. If you are smart enough to suspect BadUSB, how long will it take you to figure out if its your mouse, your keyboard, a thumb drive, a webcam, your scanner… you get the point.

Continue reading “BadUSB Means We’re All Screwed” →

Blackhat: IOS Device Charger Exploit Installs And Activates Malware

August 1, 2013 by Mike Szczys 31 Comments

ios-charger-malware

A team of researchers from Georgia Tech unveiled their findings yesterday at the Blackhat conference. Their topic is a power charger exploit that installs malware on iOS devices. Who would have thought that there’d be a security hole associated with the charging port on a device? Oh wait, after seeing hotel room locks exploited through their power jack this is an avenue that should be examined with all device security.

The demonstration used a charger and an BeagleBoard. Plugging in the charger is not enough to trigger the exploit, the user must unlock the screen while charging for it to go into action. But once that’s done the game is over. Their demo removes the Facebook app and replaces it with an infected impostor while leaving the icon in the same place on your home screen. They notified Apple of their findings and a patch will roll out with iOS7. So when would you plug your device into an untrusted charger? Their research includes a photo from an airport where an iPad is connected to the USB port of a public charging station.

The summary on the Blackhat site has download icons for the white paper and presentation slides. At the time of writing we had a hard time getting them to download but succeeded after several tries.

Mac Malware Uses Right To Left Character Exploit

July 22, 2013 by Mike Szczys 50 Comments

right-to-left-character-malware-attack

Check out this jumbled confirmation window. At first glance the message appears to contain a bunch of gibberish, but it can actually be read if you start at the right side and read each character moving left. The text displays like this because it is prefixed by a special Right-to-Left override Unicode character. The technique is being used in malware to obscure the actual extension of the file being launched. Notice that when written backwards your eye can still pick out the string “pdf” which may be enough to trick the uninitiated into approving the launch of the file.

This confirmation screen is launched when clicking on a piece of malware found in the wild a little over a week ago. If you do choose to run it, a decoy PDF file is opened in order not to arouse suspicion. But at the same time the program — which is signed with an Apple Developer ID — is installing itself in the home directory and making a cron job to launch at each boot. Sneaky!

Apple Laptop Batteries Vulnerable To Firmware Hack

July 23, 2011 by Mike Nathan 45 Comments

dead_and_busted_macbook_batteries

When you think about hacking laptops, it’s highly unlikely that you would ever consider the battery as a viable attack vector. Security researcher [Charlie Miller] however, has been hard at work showing just how big a vulnerability they can be.

As we have been discussing recently, the care and feeding of many batteries, big and small, is handled by some sort of microcontroller. [Charlie] found that a 2009 update issued by Apple to fix some lingering MacBook power issues used one of two passwords to write data to the battery controllers. From what he has seen, it seems these same passwords have been used on all batteries manufactured since that time as well. Using this data, he was subsequently able to gain access to the chips, allowing him to remotely brick the batteries, falsify data sent to the OS, and completely replace the stock firmware with that of his own.

He says that it would be possible for an attacker to inject malware into the battery itself, which would covertly re-infect the machine, despite all traditional removal attempts. Of course, replacing the battery would rectify the issue in these situations, but he says that it would likely be the last thing anyone would suspect as the source of infection. While using the battery to proliferate malware or cause irreversible damage to the computer would take quite a bit of work, [Charlie] claims that either scenario is completely plausible.

He plans on presenting his research at this year’s Black Hat security conference in August, but in the meantime he has created a utility that generates a completely random password for your Mac’s battery. He says that he has already contacted Apple to in order to help them construct a permanent fix for the issue, so an official patch may be available in the near future.

[Thanks, Sergio]