I’d like to continue the discussion on stealthy malware persistence techniques that I began Wednesday and provide two more techniques.   The goal is to show that there are many unusual and often overlooked ways to cause processes to execute.  This will provide incident responders with ammunition to take what they already know is the right course of action after a malware infection or compromise by an attacker and wipe the drive.  So lets talk about technique #3 and #4.   If you missed the first two methods for malware persistence, you can read about those here:

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

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:

http://isc.sans.edu/diary/Help+eliminate+unquoted+path+vulnerabilities/14464

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.

Detection:
Look at directory structures on your operating system.   Do directory names have spaces in them?  If so look for an executable in that directory that shares the name of the directory up until the space.   For example:
Look for c:program.exe if you have  c:Program Files
Look for a c:Document.exe if you have c:Documents and Settings
Look for C:Users<username>Local.exe if you have  c:Users<username>Local Settings   
And so on.

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.

You can also check this information with the “SC QFAILURE <servicename>” command like this:

Notice that this service it is set to execute commands that create a new administrative backdoor if the service fails.   So the question becomes how does the attacker cause the service to fail?    Well, how about a DoS?    MS12-020 is a DoS that will cause the RDP terminal service to crash.   Many organizations still have not patched this and have RDP services exposed to the internet.    DoS patches are "Low priority" and "important" but they are never critical.  After all, its just a DoS.   But malware on your machine can stage an action and turn that DoS into future command execution.    Alternatively, the attacker could have the primary malware replace files or reconfigure the system so that a legitimate service becomes dependent upon the primary malware.   For example, they attacker may inject a copy of his code into a DLL that the service depends upon.   Then when the victim updates their AV and scans the host to remove the primary malware they inadvertently break the service.   Sometime later when the service must restart it triggers the secondary malware.  
Detection:
Check all the COMMAND_LINE options on your services to see what commands are set to fire when a service fails.  This little for loop will show you that information for all your services.

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

Summary: 

Add checking for c:program.exe and other strange executables to you incident response checklist.   Also add checking for service failure recovery processes to your list.  Wiping the drive is a costly endeavor.   It can cost you time and it can cost you some political skin as you convince business leaders to endure additional downtime.   Any political hit for wiping the drive is smaller than the hit you’ll take if the machine is still infected.  Just wipe the drive.   Still not convinced?   I have a few more parts to this series to go.    This is only the tip of the ice berg.

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