This is my third post in a series called “Wipe the Drive – Stealthy Malware Persistence” .  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.     Hopefully this will give you a few more arrows in your quiver during the next incident when you say “we need to wipe the drive” and they say “don’t waste my time”.  We will pick up the conversation with techniques number five and six.   If you missed the first four 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

TECHNIQUE  #4  - Service Triggers based on ETW
Everyone knows to check for strange services running on your computer.  If the service is running then the malware will be in memory during a forensic examination.     So simply installing a service doesn’t really seem like a stealthy way to leave malware behind.    But when you combine it with Event Tracing for Windows (ETW) triggers they can be very stealthy.
Windows Event Trace Providers generate a wealth of information about what is happening on your computer.    They are similar to events that show up in your event logs, but they don’t show up in your event logs.   You can turn on logging to see what types of events are being generated from a given provider.   This can be used for good :

http://isc.sans.edu/diary/Diagnosing+Malware+with+Resource+Monitor/13735

Or it can be used for evil (well.. penetration testing isn’t evil, but you get the point):

http://pauldotcom.com/2012/07/post-exploitation-recon-with-e.html

The events generated by event providers can be used to create “service triggers”.   The triggers in turn start and stop services when predetermined events occur on the machine.    So services containing malware can start and stop in very interesting scenarios.    For example, attacker’s malware can lie dormant until a given DNS host name is resolved by the WinInet provider.   When the attacker is ready to 0wn you they simply cause your host to resolve that hostname using a link to a webpage an image tag in an HTML document.     Or the attacker could make the malware network aware so that it is running when connected to your domain but disabled when you unplug it from the network.    Another interesting scenario would be to have the malware lie dormant until an event is registered indicating that a given wireless access point is in range.    When the attacker wants to start his malware service he brings a laptop beaconing that wireless SSID within wireless range to activate it.

Detection:
You can query the triggers on a given service by running “sc qtriggerinfo <service name>”.   Here you can see the trigger for the Windows Usermode Driver Framework service.   It has a custom trigger event that fires based on some event tracing for windows provider.   The sequence of bytes defined below in the “DATA” element must be present in the event to activate the trigger.    

 
However, determining good from evil isn’t that easy.   Check out the trigger above.  Is that a good trigger configuration?  Is that the right data string?  Who knows?  In this case it is a default installation of Windows 7 so I hope it is good.    The easy way to know if is right is to have a known good baseline of what your computer is supposed to look like and then detect changes.   Do you want a baseline of triggers used on your systems?  Here is a little for loop that will print all the services on your machine.

for /F "tokens=1,2 delims=:" %x in ('sc query ^| find "SERVICE_NAME"') do @echo %y & @sc qtriggerinfo %y

Technique #5 -  Attach a debugger with ImageFileExecutionOptions

The operating system can be configured to automatically start a debugger every time a given application is launched.   To set this up you simply create a registry key and windows will take care of the rest.   So if I want to launch calculator every time someone tries to run notepad.exe it is one simple registry key.   Give this a try.   Use the following reg command to create a debugger key for notepad.exe.

reg add "HKLMSOFTWAREMicrosoftWindows NTCurrentVersionImage File Execution Options otepad.exe" /v Debugger /t REG_SZ /d c:Windowssystem32calc.exe

That’s it!  Now when you try to launch notepad calculator is launched instead.    Notepad never even starts.   Only calc.exe is run.   Notepad would start if calc.exe was an actual debugger.  Users might notice the wrong processes running.   The attacker can solve this by putting debugger functionality into their code.  Or after the malware starts it can delete the Debugger key and relaunch the original process so it starts normally.

While this is a cool trick, by itself it doesn’t solve the attacker’s immediate problem.   They want to lie dormant until incident response is finished.  To do that they can attach the debugger to any infrequently run programs, such as the defrag process.   On a server they might connect the debugger to Internet Explorer or another process that isn’t used very often.      Then the attacker just sits back and waits for you to retrigger the infection of your machine.

Detection:

If you see a “Debugger” option under anything in the "Image File Execution Options" registry key you investigate that debugger.    Here we can see the debugger attached to notepad.exe using the “reg query” command:

To delete the debugger you can use the following command.

reg delete "HKLMSOFTWAREMicrosoftWindows NTCurrentVersionImage File Execution Options otepad.exe”

Summary:  Once a compromise has occurred finding all of the things the attacker could have done to your machine is usually more time consuming than just wiping the drive.   Just wipe the drive.   Still not convinced?   I have a one part in this series to go.   

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 (Twitter @malwarejake ) 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