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:

http://isc.sans.edu/diary/Wipe+the+drive+Stealthy+Malware+Persistence+Mechanism+-+Part+1/15394
http://isc.sans.edu/diary/Wipe+the+drive+Stealthy+Malware+Persistence+-+Part+2/15406
http://isc.sans.edu/diary/Wipe+the+drive!++Stealthy+Malware+Persistence+-+Part+3/15448

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.        
Detection:
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.

http://msdn.microsoft.com/en-us/library/windows/desktop/aa379402%28v=vs.85%29.aspx

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. 

Detection:

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"

Summary:
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! 

http://www.sans.org/event/sansfire-2013/course/python-for-pen-testers

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:

http://www.sans.org/vlive/details/for610-mar-2013-jake-williams

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

http://www.sans.org/event/dfir-summit-2013/course/reverse-engineering-malware-malware-analysis-tools-techniques