Proactive Threat Detection Seek and ye shall find, otherwise: compromise
Objectives Learn (very little) about who I am Understand the attack lifecycle Understand how host-based forensic artifacts can be used to detect threats and augment network analysis Review a few case studies Interrogate me (be kind) Do all that in one hour or less.
Introduction (/me) 15 years as a systems administrator and network engineer 5 years at Mandiant Investigation and remediation lead Researcher focusing on native exploitation of Windows frameworks (WMI, WSH, PowerShell) Presentations delivered at MIRCon, CanSecWest, SANS DFIR USA, SANS DFIR Europe Educator (internal and external) Internal coursework includes proactive threat detection, creating and using indicators of compromise, and various investigative techniques I tweet at people sometimes (@_devonkerr_)
The attacker lifecycle Learn how your prey behaves
Host-based Forensic Artifacts Index Tracking on Windows
Note To help manage the volume of material, this section is broken up by the type of source of evidence: Filesystem Registry Event logs Process memory The general value of each artifact has been indicated during each phase of an intrusion Please be aware that these are not always true Value is represented by color saturation rich colors are good, light colors are bad
Filesystem Initial Compromise Establish Foothold Escalate Privileges Internal Recon Move Laterally Maintain Persistence Complete Mission Prefetch INDX files NTFS Change Journal JOB files BAT files Enterprise AV logfiles Common Staging Folders LNK files WMI CIM Repo
Registry Initial Compromise Establish Foothold Escalate Privileges Internal Recon Move Laterally Maintain Persistence Complete Mission AppCompatCac he Amcache MUICache Service keys Run/RunOnce keys LSA Secrets Shellbags MRU keys UserAssist
Event logs Initial Compromise Establish Foothold Escalate Privileges Internal Recon Move Laterally Maintain Persistence Complete Mission EID 592/4688 (Process tracking) EID 601/4697 (Service creation) EID 7035 7036 (Service start/stop) EID 540/4624 (NTLM Logon) EID 552/4648 (KERBEROS/Explicit) EID 21/23/24/1149 528/529/4624/4625( Terminal Services) EID 602/4698 (scheduled task creation) EID 556/7036 (ntdsutil/vssadmin) Enterprise AV (various EIDs)
Process Memory Initial Compromise Establish Foothold Escalate Privileges Internal Recon Move Laterally Maintain Persistence Complete Mission Import hashing/analysis Unsigned binaries/drivers Conhost/csrss strings Injected processes Network Connections DNS Cache Mutexes Process path anomalies Svchost.exe artifacts
How to use this information
Develop a plan of action Often, a compromise is detected during one of the intrusion phases. Using these tables, an investigator could prioritize which artifacts to collect. Here s a for-instance: your organization receives a notification from law enforcement. The notification tells you that on May 15, 2015 approximately 25GB of multipart WinRAR archives were stolen from a webserver in the DMZ. The naming convention resembles aa[1-87].jpg. What can we collect that helps with the data theft portion of an intrusion: Prefetch Shimcache Amcache INDX records Common staging folders NTFS change journal
All phases: Shimcache/amcache, process tracking Assume compromise Instead of waiting for a compromise to occur, what are the highest value artifacts we can collect and which phases will they be relevant? Initial Compromise: AV logs Establish a Foothold: Services keys, run keys Escalate Privileges: Prefetch, AV logs, LSA secrets registry key, events related to VSS Internal Recon: Prefetch, BAT files Move Laterally: JOB files, events related to logons/rdp/scheduled tasks Maintain Persistence: NTFS change journal, services keys, run keys, events related to services Complete the Mission: Prefetch, common staging folders, NTFS change journal, INDX records
Practical Examples I caught a fish this big
Scenario-driven examples All information was obtained from nonclassified environments. Note that each artifact in the presented examples was collected using an endpoint agent, however it would be relatively trivial to collect these using PowerShell, WMI, batch scripts, or other open source solutions. Using prefetch to identify credential harvesting Finding malware with Windows Services analysis Finding PlugX with import functions Similarly, each artifact can be parsed using a wide variety of open source tools the intent is to demonstrate the value of these artifacts without promoting a collection or analysis framework.
Example: Prefetch
Overview of Prefetch Helps answer what application previously ran? and when? File system artifact located in C:\Windows\Prefetch\ path and hash filename, same filename in different directories will result in different prefetch filenames Disabled on servers (default) Records the binaries loaded within ~10 seconds of execution Up to 128 on Win7, up to 1024 on Win8
Prefetch naming convention C:\WINDOWS\calc.exe C:\WINDOWS\Prefetch\CALC.EXE-1701A124.pf C:\WINDOWS\system32 \calc.exe C:\WINDOWS\Prefetch\CALC.EXE-77FDF17F.pf
Valuable Prefetch metadata The $SIA creation timestamp typically indicates the first run time The last modified timestamp typically indicates the most recent run time Other metadata includes The # of times executed The list of files accessed within 10 seconds of execution The last run time
Prefetch scenario: password dumping Scope: all prefetch files from Windows systems in a 10K node environment The average volume of prefetch was ~34MB per system Parsed out, this resulted in ~8600 accessed file references Searched accessedfiles lists for common archive utilities, found WinRAR to be quite rare (employees favored 7zip) Immediately identified 3 systems where WinRAR was used 1 false positive 2 valid systems, one which showed us the following:
Struck gold in AccessedFiles
Some options for Prefetch analysis Review all prefetch files for [1-3] character filenames (ex. aaa.exe ) Review all prefetch files for suspicious filenames (ex. rar.exe ) Review all prefetch files for administrative tool names (ex. ntdsutil.exe ) Review accessedfiles for suspicious filenames (ex. wceaux.dll ) Review accessedfiles for suspicious file extensions (ex..part.rar ) Review accessedfiles for suspicious directory names (ex. RECYCLE.BIN ) Frequency analysis of prefetch files and the distribution of accessedfiles filenames
Example: Windows Services
Overview of a Windows Service Windows Services are configured in the registry Can be started either automatically or manually May load a standalone binary using the ImagePath value An executable file ImagePath can execute a ServiceDLL as well
Windows Service metadata Windows Services are configured under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ Let s look at a valid Windows service: RasMan, the Remote Access Service Manager ServiceName: RasMan DisplayName: Remote Access Connection Manager Description: Manages dial-up and virtual private network (VPN) connections from this computer to the Internet or other remote networks. If this service is disabled, any services that explicitly depend on it will fail to start. ImagePath: ServiceDLL: %systemroot%\system32\svchost.exe k netsvcs %systemroot%\system32\rasmans.dll
Windows Services scenario: malware Scope: all Windows Services metadata from systems in a 47K node environment The average size of a Service registry key is a few KB, in this environment ~14KB average Parsed out, this resulted in almost 50M rows of metadata (less than 4GB uncompressed) Automatically enriched the data: hashing each ImagePath and ServiceDLL binary, verifying digital signatures, checking NSRLs, etc. Next, we checked for service executables in unusual directories or valid names but unexpected ServiceDLLs Identified 119 interesting services ~50% false positives (curse you unsigned printers!) 38 systems with non-targeted malware, 17 systems with 2 targeted backdoor variants Here s one of those examples:
Anatomy of an evil Service key ServiceName: DisplayName: Description: ImagePath: ServiceDLL: NCRperfmon NCR SelfServ Platform Remote Monitor n/a %systemroot%\system32\ncrperfmon.exe n/a
Some options for Services analysis Review all ServiceDLL and ImagePath binaries Determine if signed, if so determine if the signature can be verified Review hashes of all executables, compare to a trusted NSRL Determine if binaries are running out of unusual directories Review the Service name and description compare against Microsoft published service information Examine frequency of occurrence does the service appear on more than 15% of systems? Are there outliers with a different ServiceDLL hash, signing status, or path? Look at ImagePath binaries do you see any instance of svchost.exe outside of system32?
Example: Binary Analysis
Overview of function imports An import is a DLL loaded by an executable which contains some functionality A program s capabilities can be tied to one or more imports Note that a capability, like keylogging, can be achieved through a few different collections of imports in most cases Upon execution, Windows examines the PE data and loads the executable into memory During this process it also loads any import DLLs into memory and maps all the necessary functions those DLLs support
Useful binary metadata The import name: this is the name of a DLL In some cases the DLL will exist on disk, in other cases the DLL will be unpacked from a binary and loaded into memory The import size: the size of the DLL The function name: this is the name of the function stored within the imported DLL which the executable will use Combinations of functions can make very reliable indicators
Something known: PlugX attributes PlugX (KORPLUG) has a fairly unique combination of import and functions Filesize: 4096 bytes Imported DLL: msvcrt.dll, a valid library which provides programs with C/C++ functions Imported functions (all must be present): Malloc: Memset: Strcat: allocates memory sets the content of allocated memory appends data
PlugX identified in process imports Scope: PE info from every binary in an environment of about 17K Windows systems (metadata only) The average size of metadata was ~22MB per system Using information known (previous slide) We searched for all files which imported msvcrt.dll We excluded results which did not import malloc, memset, and strcat Quickly identified 9 systems where PlugX was present 0 false positives
Some options for binary analysis Look at function imports which map to common malicious capabilities such as reverse shell, keylogging, memory injection, and network tunneling Look at binaries with a valid MZ executable header, but which have unusual file extensions Examine how binaries are packed like UPX and Themida - or compiled using less common compilers like Py2exe/PyInstaller Examine directories for multiple files with the same root name, but different extension (ex. abc.dll, abc.hlp, abc.exe ) Look for DLLs outside of system32 and which are not listed in the KnownDLLs registry key
Questions?
Next steps: Contact information: Twitter: @_devonkerr_ Email: devon.kerr@mandiant.com Complete similar presentations for OSX, Linux, and network analysis Develop outline for proactive threat collection and analysis curriculum