I just read a great article by Mark Baggett (@MarkBaggett) on the ISC Diary called Wipe the drive! Stealthy Malware Persistence Mechanism – Part 1 and Wipe the drive! Stealthy Malware Persistence – Part 2. This was from his presentation at Shmoocom 2013. He shows 4 different methods how malware can stick around even after it’s been “cleaned” by anti-malware products. I completely agree with his advice: always “Wipe the Drive”. It’s the only sure fire way to clean the system, but what if you can’t for some reason? Maybe it’s a traveling employee or an executive at a conference. Wiping and re-imaging is a costly procedure in most enterprises.
What if you had Bit9 installed? How would these 4 situations play out? Let’s go through them. Bit 9 can be run in three protection modes: Monitor-only with Advanced Treat Indicators (ATIs), Block & Ask, and Block. If you are running endpoints in Monitor-only mode with ATIs, you would get an alert on your Bit9 console for these actions. This alert could be acted upon within Bit9 or from your SIEM. For the other two modes, I’ll explain how each of these would be blocked, since that’s how most of our customers use Bit9.
TECHNIQUE #1 – File Associations Hijacking
What happens when you click on a .TXT file? The operating system checks the HKEY_CLASSES_ROOT hive for the associated extension to see what program it should launch. …
What if the attacker or his malware changes this association? Instead of launching notepad it tells the OS to launch NOTPAD.EXE. NOTPAD.EXE is wrapper around the real NOTEPAD.EXE but it also contains a malicious payload.
This is pretty straightforward. NOTPAD.EXE would be blocked because it isn’t trusted. No matter how you tricked the user into running it, Bit9 is protecting you. When you get the block alert, it’s time to wipe the drive, but only when get around to it… after all, you are protected by Bit9.
TECHNIQUE #2 BITS BACKDOOR
BITS is the Background Intelligent Transfer System. This service is used by your operating system to download patches from Microsoft or your local WSUS server. But this service can also be used to schedule the download of an attacker’s malware to reinfect your system. Once the attacker or his malware are on on your machine he execute BITSADMIN to schedule the download of http://attackersite.com/malware.exe. He schedules the job to only retry the URL once a day and automatically execute the program after it is successfully downloaded. The attacker doesn’t put anything at that URL today. Instead, he simply waits for you to finish your incident handling process and look the other way. You can scan the machine with 100 different virus scanners. Today there is no file on your system to detect. You can do memory forensics all day. Sorry, there is nothing running today. Today it is just a simple configuration change to the OS. Then when he is ready he places malware.exe on his site. Your machine dutifully downloads the new malware and executes it.
Again, this is a very easy use case. malware.exe wouldn’t be allowed to run. When you get the block alert, it’s time to wipe the drive, but only when get around to it. Bit9′s got you covered until then.
TECHNIQUE #3 – Program.exe
When Jake and I were preparing for the Shmoocon talk that we gave on this subject, I suggested we include this technique in our presentation. Jake disagreed because this thing has been around since the year 2000 and I quickly relented and agreed with him. At the time we both thought that this technique is pretty lame and we shouldn’t have to worry about a THIRTEEN YEAR OLD vulnerability. Instead I decided to do a post on the ISC to talk about the technique and see what response we got. The response for you, our awesome supporters, was incredible. ISC readers documented several dozen of these attacks in critical systems common to most corporate desktop images. You made Jake a believer (he had a vulnerable OEM application you found on his laptop). The response was such that I am now convinced that an attacker can use this technique and have a great deal of confidence that his malware will be launched. As a matter of fact, it will probably be launched by something that has system permissions. I won’t repeat the full details of the technique here since I already covered it on the ISC. You can check out this article if you missed it:
This is the scenario. Malware or an attacker is on your machine. He has administrative or Power User access. The attacker drops a file called “program.exe” on the root of your C drive. “program.exe” is a small application that reads the command line parameters that were used to call it. It launches the real program you had intended to call and then executes its malicious payload. Simple but effective.
This one is interesting. When you install the Bit9 agent, it locally approves all files on the system. Then you setup a chain of trust. If you have program.exe on old machines or existing gold images, Bit9 will trust it.
I would advise following the link above and understanding this issue. It’s worth it to review gold images a bit closer when putting them in your trust based architecture in Bit9. When doing this review, it’s a great use case for using cloud based reputation using Bit9′s Software Reputation Service (SRS). If you have any questionable files on your image, run them through SRS. Find out what the world thinks about them. Another bit of advice for vetting gold images: review unsigned code! You can even detonate files in a FireEye MAS, if you have one.
If you do find any malware like this program.exe, globally ban it in Bit9 (and delete it from your gold image)! This will instantly protect all existing computers running the Bit9 agent. Global Bans even work on Bit9 agents running in Monitor-only mode. No need to wipe every drive immediately when you are protected with Bit9.
Technique #4 - Service Failure Recovery Startups
You can configure Windows services with an automatic recovery action. The defined action will be taken when the service crashes unexpectedly. You can see these on the recovery tab for a service using services.msc. Here you see this service first tries to restart the service, then it will …. ummm… whats that?? .. RUN A PROGRAM. Hmm.
This use case is also straightforward. The malware has tricked the user, even tricked the system, but it hasn’t been tricked by Bit9. Blocked, again.
I hope this helps shine the light on the amazing power of software whitelisting. It changes the game in end-point protection. You don’t have to go running after every trick in the book that may trick a user. You only have vet the software you trust, and you don’t have to wipe the drive immediately when an infection occurs. Bit9 gives you the freedom to have endpoint protected while you wipe the drive at your convenience.
Filed under: Bit9