SANS ISC: Wipe the drive! Stealthy Malware Persistence Mechanism - Part 1 - SANS Internet Storm Center

• SANS Site Network
  • Current Site
  • Internet Storm Center
  • Other SANS Sites Help
  • Graduate Degree Programs
  • Security Training
  • Security Certification
  • Security Awareness Training
  • Penetration Testing
  • Industrial Control Systems
  • Cyber Defense Foundations
  • DFIR
  • Software Security
  • Government OnSite Training

SANS ISC InfoSec Forums

At Shmoocon 2013 Jake Williams (@MalwareJake) and I gave a presentation entitled “Wipe the Drive”.   The point of the presentation was that you should always wipe the drive and reinstall the OS after a confirmed malware infection.     We all know wiping the drive is the safest move but there are business pressures to simply remove the known malware and move on.    Also, because we are security professionals there is often an expectation that we are able to remove all the malware.    But, in my and Jake’s opinion, relying on a “clean scan” from antivirus products isn’t the best approach.  The time and effort required to accurately analyze the capabilities of malware and conduct forensic analysis to determine if those capabilities were used is usually not in the cards.     There is always an element of risk management, but whenever you possibly can, just wipe the drive.    To illustrate the point we began developing a list of ways that malware or an active attacker on your computer can make small configuration changes to you machine.   The changes create a mis-configuration that makes the target exploitable or set events in motion that will cause the target to automatically get re-compromised in the future.   There are a very large number of changes and misconfigurations that attackers can make but our talk focused around eight of them.   The only criteria for these techniques is that they launch a process in an unusual way and ideally they don’t have any processes running (so you can avoid detection by memory forensics).   I will discuss a few of the methods we came up with and how you might detect these changes.   First let’s talk about file extension hijacking.

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.   Here we see the associate for .TXT files mapped to “txtfile”.  

Further down in the HKEY_CLASSES_ROOT hive we find the entry for “txtfile” where the applications that are used to “open” and “print” are defined.   Here you can see that NOTEPAD.EXE is the application that will launch when the OS tries to OPEN a txt file.  

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.   During the initial infection the attacker makes this change and leaves his NOTPAD.EXE behind.    You remove the initial attack vector and do memory forensics to find nothing running on the host.   Sometime later, after memory of the incident fades the administrator checks his logs by clicking on a .TXT file.   It launches NOTPAD.EXE which in turn launches NOTEPAD.EXE and reinfects the machine.  
In an alternate version of this attack a new file extension is created such as .WTD.   When the attacker is ready to reinfect you they send in email with a .WTD extension.   When it is opened on the victim’s machine they are reinfected.   
I am sure some of you will say, “but NOTPAD.EXE will be detected by AV”.     Perhaps, but remember the point of these is to evade memory forensics.   For the most part, evading antivirus software is trivial.'

Detection:
How do you detect this?  Well, baseline the contents of your HKEY_CLASSES_ROOT registry key and then periodically check its current state against that baseline.   Investigate any changes to see what executes when you click on the file extensions that have changed.  We all know it is dangerous to click links on the internet.   Unfortunately links on your computer aren’t any safer once an attacker has had a chance to change where they go.   

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.     

Detection:
This one is easier to find.  The BITSADMIN tool also lets you view scheduled downloads.  You can get a list of scheduled task with the command “BITSADMIN /LIST”

Here you can see there is a job called “getsome” that is currently scheduled on this machine.   "BITSADMIN /LISTFILES <jobname>" takes a scheduled job as a parameter and returns a list of URLs the job is scheduled to download.  For example, here we see that job “getsome” is scheduled to download from the url HTTP://attackerssite.com/malware.exe  and it will save the file as c: empmalware.exe.

But how does the malware execute after it is downloaded?    BITS will allow you to schedule a command to execute after a successful download to notify you that the job is finished.   The intention is that you can execute a program and have it send you an email or fire an alert in a network monitoring system.  Let’s check the notification program on this program with BITSADMIN /GETNOTIFYCMDLINE <jobname>.  To use it provide the job name as an argument like this:

Here you can see that after the malware is successfully downloaded to c: empmalware.exe the BITS service will launch c: empmalware.exe “to notify the administrator”.

SUMMARY:
Add checking the BITSADMIN queue to your incident response checklist.   If you find something scheduled don’t rely on simply deleting the job.   In a moderately complex operating system there are an infinite number of places to hide.    I'll talk about more of these types of techniques during my upcoming handler shifts.   When you have malware on your machine,  just wipe the drive.   

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