Wipe the drive! Stealthy Malware Persistence - Part 4

Published: 2013-03-22
Last Updated: 2013-03-22 02:10:52 UTC
by Mark Baggett (Version: 1)
5 comment(s)

This is my fourth post in a series called “Wipe the Drive – Malware persistence techniques” .  The goal is to demonstrate obscure configuration changes that malware or an attacker on your computer can leave behind to allow them to reinfect your machine.    We will pick up the conversation with techniques #7 and #8.   If you missed the first six techniques you can read about those here:


TECHNIQUE  #7  - Winlogon Events
Most versions of Windows will allow an application inside a DLL to register events that are triggered by WinLogon.   Once that occurs he application will be launched when ever that event occurs.    One of those events is the “shutdown” event.   By registering the shutdown event a, malicious DLL will be given a chance to execute every time the machine shuts down.    During the shutdown process, the malware will be given a chance to execute commands on the target host.    This allows the malware to lie dormant during the incident response process.  When the machine is shutdown the malware is loaded into memory.  Then it downloads the primary malware and reinfects the machine.   This can make your incident response and containment phases very difficult.     For memory forensics to see this malware reinfecting your machine you would have to capture memory during the shutdown process.    That is not typically how memory captures are done.        
To check to see if any malware has registered for login events check the following registry key:
HKEY_LOCAL_MACHINESoftwareMicrosoftWindows NTCurrentVersionWinlogonNotify

If the subkey doesn't exist you are in good shape.   If a subkey with any name exists and it has a "shutdown" value then the dll in the "DLLName" key will be launched during the shutdown process.   Check that DLL to see what it does.   You should expect that it does very little beyond loading another payload from somewhere else on the hard drive.   Here is an example of a registry key registering scard32.dll or shutdown events.


Technique #8 -  Wipe the DOMAIN?  Fun with Scheduled Tasks
This last technique is pretty simple, but it illustrates an important point.    Throughout this series I’ve been saying that if an attacker owns your computer then wipe the computer.   But what happens when the attacker owns your domain admin accounts?   Do you need to wipe the domain?   Talk about downtime and expenses!  I don’t know if I am ready to say wipe the domain, but this technique is one of many that should give systems administrators reason to pause and make sure they understand exactly what the attackers did on their network.  
As you probably know scheduled tasks allows you to schedule events that will occur on a predefined date and time.    You may also know that you can schedule events based upon events in the event log.    You can get very specific about the types of events that will trigger the execution of code.   Microsoft supports limited XPATH filtering on scheduled tasks that allows you to peer into the data element of an event.  (http://blogs.technet.com/b/askds/archive/2011/09/26/advanced-xml- filtering-in-the-windows-event-viewer.aspx)    This enables some interesting scenarios.
Imagine that an attacker creates a schedule task on one of your domain controllers that is monitoring for a failed logins by the account that is associated with your Backup Software’s Service account.   Normaly, that password is hardcoded on servers across your enterprise and no one uses that password interactively.   That means under normal circomstances it never has a failed login.   But an attacker with domain admin has created a task on your domain controller that will create a new domain admin account when that backup account has a failed login.    Months later, they connect to a public RDP server or Outlook Web Mail server and enter the backup account’s username and an incorrect password.   The scheduled task fires and the back dorr domain admin account is created.   
This is only one of many evil things an attacker could do on your domain.  Group policies are complex and offer a creative attacker many places to hide.    So do you wipe the domain?    I think the right answer is to have a vigilant monitoring and instruction detection system in place.   Have incident response plans that will mitigate the threat before they get domain admin. 


Event based tasks are plentiful on the typical machine.   This is to the attackers advantage.  Distinguishing good from evil is much easier if you have a baseline of what is supposed to be on your machine.   You can capture a baseline of the currently scheduled event based tasks with the following command.

schtasks /query  /FO CSV /V  | findstr /i "when an event occurs"

Some people are of the opinion that people who “wipe the drive” when they are infected with malware lack the technical expertise and knowledge that is required to remove the malware.      I’d argue that the opposite is true.   It is the difference between unconscious incompetence and conscious incompetence.  There, I said it.   I am incompetent when it comes to finding everywhere malware could have hidden on a machine.     Given enough time and energy I MIGHT find it all, but is that good enough?   If that isn’t good enough then do as I do and just wipe the drive.

Special thanks to Jake Williams (Twitter @malwarejake).  Jake presented these concepts with me at Shmoocon last month.  Jake is an extremely talented malware researcher.   That video is now online and can be viewed here: http://www.youtube.com/watch?v=R16DmDMvPeI

Follow me on twitter : @MarkBaggett 

Here is an AWESOME DEAL on some SANS training.   Join Justin Searle and I for SANS new SEC573 Python for Penetration Testers course at SANSFire June 17-21.   It is a BETA so the course is 50% off!   Sign up today! 


There are two opprotunities to join Jake Williams for FOR610 Reverse Engineering Malware.  Join him on vLive with Lenny Zeltser or at the Digital Forensics & Incident Response Summit in Austin.

vLive with Jake and Lenny begins March 28th, 2013:


Jake at DFIR Austin Texas July 11-15, 2013:


Keywords: malware
5 comment(s)


For years I have been a wipe-the-drive advocate. I explain to my users in a non-technical, but rather biblical way (we are in the so-called bible belt of the US), that is there is sin in the machine, the only solution is for it to have a born again experience! ;-)
There is are significant economic reasons to wipe the drive of infected machines most of the time. You can usually rebuild/reimage the machine faster than you can clean malware off of it. And it is the safest path too if employees visit clients a lot. For small businesses they just do not have the resources, time or money, to horse around with an infected machine.
We always said, "nuke from high orbit", perhaps from Kevin Liston. Sadly, the anonymous folks stole that with their high orbit ion cannon.

The compromised domain controller scenario makes me shiver. In theory, you'd wipe your ADS and every computer connected to the domain.
While I agree for the most part with "wipe the drive", let me play Devil's Advocate for a minute.

I think it's a risk management decision. You could list several things that malware could do to persist on your system beyond just the workstation drive itself: user data files (every piece of data that a user has rights to anywhere on your network may be infected somehow... wipe your file servers?), your MBR may be infected, your BIOS may be infected, your options roms may be infected (maybe reflash every piece of code on your computer, firmware and hardware).

Also some organizations are geographically spread out with limited front-line support staff for instance, and there is also the issue of downtime for the end-user.

I guess my point is that it's really a risk management decision based on the risk appettite of your business, a threat/risk assesment of what happened on your network, your typical "threats" (for instance, I have little to no IP on my network, so nation state espionage is of little concern, but cyber crime is-which significantly impacts our threat/risk assessments and security stance.)

In the past, I have "cleaned" malware from a computer over reimaging when I was fairly confident that the malware could be identified (ie. it was a "simple" fake AV, no admin rights, nothing further found in packet captures, etc...). I have also advised/urged reimaging in other situations when I was not confident of being able to clean the system.

Of course, I have many layers of defense, prevention and detection in my network, not to mention tons of logging, full packet captures, stream captures, honeypots, etc...

Thanks for this series -- we have some clients who insist on trying to remove malware instead of reimaging. At one place, we finally convinced them to start reimaging, and here is what they did: To minimize user inconvenience, they copied the user's local profile off the box, reimaged, and then copied the profile back so the user's bookmarks, etc. wouldn't be lost. Of course, where do you think this malware (like so many types of malware) had its binaries AND the "run" key that made it persistent?

Diary Archives