Sans Study Flashcards
1
Q
Keyword
A
Description
2
Q
PsExec
A
> New PsExec service installations are run each time PsExec is used.
When started as a service, it is obvious to view malicious use, as you will see it being run by a user account rather than SYSTEM or LOCAL SERVICE accounts.
Service name is PSEXESVC on remote system.
Malicious PsExec usage is also typically encoded, such as when deployed via MetaSploit. You can also look for strange service names.
Also see Per-User Service (2.100)
3
Q
Scheduled Task
A
> Logged in Microsoft-Windows-Task Scheduler/Operational log. Not tracked by default and can be enabled via group policy, the wevutil command-line tool, or the GUI Task Scheduler application.
Scheduled task logging in the Security log requires Object access auditing to be enabled.
Tasks can be scheduled remotely, but the logs do not differentiate. To find remote tasks you must look for Type 3 (network) logon occuring near task creation.
Logged in Security logs and Microsoft-Windows-Task Scheduler/Operational log. Security logs will provide more detail info like trigger info, account name, and full path.
When a task is created, a config (or .job) file is deposited into %SystemRoot%\System32|Tasks or %SystemRoot%\SysWOW64 for 32-bit code (which is rare). You can use these to identfy the account and system name used to schedule the task. Not on XP/Win2003, the .job file is written in binary.
4
Q
make_token
A
Part of Cobalt Strike and used to create a new logon session using a stolen auth token.
5
Q
pth
A
Part of Cobalt Strike and used to create a new logon session using pass the hash.
6
Q
Explicit Credentials
A
> Logged as EID 4624 Logon Type 9 and EID 4648 “Explicit Credentials” events: Use crdentials not logged in memory (new creds) to impersonate another user to access a resource or service on a network.
These events (runas) are typically recorded on the origionating system instead of the target. This allows us to determine where a user was heading.
You can determine whether a 4648 event was logged on the origional system or a target system by looking at the “Target Server” information: If localhost, it is inbound, if includes IP address, it is outbound.
Can also capture outbound RDP sessions on the source system if network level authentication is enabled. This will include: current logged-on user name, alternate user name, destination host name/IP, process name.
7
Q
Admin$
A
Network share containing network administration tools such as software patches (this is a legacy way to patch systems).
8
Q
IPC$
A
Inter-Process Communication connection: This share must be authenticated to facilitate communication between two devices on a network. Includes account name, SID, domain, and Logon ID, as well as source IP and port. IPC$ shares cannot be used to move files, it is simply an auth mechanism.
9
Q
Event log explorer
A
See Tools tab
10
Q
Account enumeration
A
> TAs commonly deploy tools belonging to attack frameworks like Empire and PowerSploit to enumerate sensitive accounts and groups in an enterprise. Windows have introduced a new series of EID to track this activity.
This is enabled at the GPO level using the “Audit Security Group Management” and “Audit User Account Management” audits.
Although these events can be noisy, you should look out for PowerShell, WMI, or netuse via cmd.exe, as these are not common in an enterprise environment. Services like mmc.exe, services.exe, taskhostw.exe, explorer.exe and VSSSVC.exe are common.
11
Q
Enumeration (see account enumeration)
A
12
Q
Pass-the-hash attack
A
> Rely on NTLM logons
Often appear as EID 4624 Type 3 network logon events.
Allows Tas to perform SMB-based actions like mapping shares, executing code with PsExec (this relies on SMB).
Although most modern environment are set up to block this, attackers can modify the LocalAccount TokenFilterPolicy with a one-liner to re-enable the capability.
13
Q
Logon error codes
A
14
Q
Kerberos
A
Kerberos works by a user supplying credentials to the authentication server (often the domain controller). If correct, a Tiget Granting Ticket (TGT) is issued to the user for a period of time. This is like a passport. To access resources on another system, such as a server, a “Service Ticket” is requested.
> If the auth fails, an EID 4771 will be written to the authentication servers logs. This will include date/time, hostname, client IP address, username, Error Code (see Logon error codes).
15
Q
Ticket Granting Ticket
A
Part of the Kerberos authentication process. A user granted a TGT when authenticated correctly to an auth server like a domain controller.
16
Q
Service Ticket
A
Part of the Kerberos authentication process. A user granted a Service Ticket when authenticated correctly to a networked resource.
17
Q
NTLM Auth
A
Although less common than Kerberos, NTLM logons do still occur. For example, local account will record logons as NTLM. Pass-the-hash attacks also rely on NTLM (which will record EID 4776).
18
Q
Logon Events (as oposed to account logon events)
A
Login/Logoff activity happening on the actual system being logged into. Stored locally. Note that for local accounts where the auth is happening via the local SAM database, you will see account logon and logon events. This can indicate rouge accounts, as it is rare in an enterprise environment.
19
Q
Account Logon Events (as opposed to logon events)
A
Third-party authentication of credentials provided during that logon session. For example, users that need to authenticate via a Domain Controller. Note that before a user can authenticate, their credentials need to be validated by the domain controller using either NTLM or Kerberos. These events are stored on the domain controller. The one exception is local account auth, where an account logon is generated for a local only account (see Logon Events).
20
Q
RDP logs (Security + Custom)
A
> Source: TerminalServices-RDPClient: EID 1024,1102
Source: Security logs: EID 4648 (if NLA enabled and alternate creds used)
Destination: Security 4624 Type 3,7,10 & 4778/4779
Destination: Remote Desktop Services-RDPCoreTS: EID 98,131
Destination: TerminalServices-RemoteConnectionManager: EID 1149
TerminalServices-LocalSession Manager: EID 21,22,25,41
21
Q
RDP Use in EID
A
EID 4624 (Logon Types 3,7,10) are the best indicators of RDP usage. You should also cross reference the RDPCoreTS and TerminalServices-RdpClient logs. EID 131 in RDPCoreTS and EID 1024/1102 in the TerminalServices-RdpClient log record outbound RDP connections and include destination hostname and IP.
22
Q
Account creation
A
Local admins can create local accounts and domain admins can create domain-wide accounts. EID 4720 logs date, time, computer, account used to create.
23
Q
Built-In Accounts
A
System: This used to be the primary non-user related account prior to Windows 2003. The accounts below were added to provide additional layers of security.
> Local Service: Used for services that do not require network access. Cannot authenticate with network resources.
> Network Service: Similar to local service but with slightly higher privileges, which allow it to impersonate standard computer accounts and authenticate over the network. Assigned for processes or services that require network access.
> <Hostname>$: The computer account provides the means for the computer to be authenticated when communicating with Active Directory and accessing network and domain resources. The account is named according to the system name.
> DWM / UMFD: Related to the Windows Manager (DWM) and driver activity (UMFD), but little used.
> Anonymous Logon:</Hostname>
24
Q
Brute force attacks
A
> Typically indicated by failure codes C0000064 for unknown users and C000006A for bad passwords
25
Logon ID
> Each account session is assigned a unique Logon ID at the time of logon. These can be used to determine Session time, process tracking, object access events, and more granular views of user activit, like screen locking an unlocking.
26
Session Time
> Logon Ids can be used to correlate session time, but not that some session types, like SMB, will not work this way.
27
Linked Logon IDs
> Ties the session to the Logon ID of any other authentication events. For exampl, they can link non-admin session to high privilege sessions when both are related.
28
Logon Codes
> 2: Logon via console (keyboard, server KVM, or virtual client)
> 3: Network logon (SMB and some RDP connections such as those using Network Level Authentication)
> 4: Batch Logon - Often used by Scheduled Tasks
> 5: Windows Service Logon
> 7: Credentials used to lock or unlock screen: RDP session reconnect
> 8: Network logon sending credentials in cleartext
> 9: Different credentials used than logged on user - RusAs/netonly
> 10: Remote interactive logon (Remote Desktop Protocol)
> 11: Cached credentials used to log on
> 12: Cached Remote Interactive (similar to Type 10)
> 13: Cached unlock (similar to Type 7)
29
PSReadline
Default module designed to log the last 40,96 commands types I PowerShell console. Output stored in ConsoleHost_history.txt. Only commands that ar types are logged. No timestamps available. Only recorded during interactive sessions explicity using the PowerShell console.
30
ConsoleHost_history.txt
Output of PSReadline PowerShell logging.
31
Transcription logs (PowerShell)
Display the contents of the Powershell terminal including inputs and outputs. This is unlike script block logging, which would only capture the script run.
32
CyberChef
Two features are most important: this tool is capable of running a local instance of the web app. You can also use the "Magic" decoder, which attempts to intuit the correct recipe for decoding input.
33
AMSI
See Antimalware scanning interface
34
Anti-Malware Scanning Interface
Can audit code at the point of execution in order to defeat obfuscated powershell codes.
35
Revoke-Obfuscation
uses feature extraction and character frequency analysis to identify strange looking scripts in PowerShell logs. You can run this against PowerShell/Operation logs.
36
PowerShell: Commonly abused keywords
37
cradle
Fileless, memory-less malicious scripts downloaded from the internet.
38
PowerShell: Stealth Syntax
39
PowerShell version 2 downgrade attack
This is done to circumvent logging. V2 has much less logging enabled. Look for EID 400 in Windows PowerShell.evtx. Also look for powershell-Version 2 command in command-line auditing. It is recommended to remove V2 from your environment.
40
PowerShell logs: Script block logs
See Script block logs
41
PowerShell: Module logs (see PowerShell logs)
> Module logging focuses on PowerShell pipeline execution. Almost every command uses several modules or cmdlets and EID 4103 events can include variables, commands, interim output, and even some deobfuscation.
42
PowerShell Logs
> Script block logs can caputre the full command or contents of a script, who executed it, and when it occurred. These are recorded in Microsoft-Windows-PowerShell/Operational. EID 4104 records the Script block contents, but only the first time it was executed.
> Although script block logging is not enabled by default, suspicious scripts will still get logged in Microsof-Windows-PowerShell/Operational.
> You can also review EID 400 and 800 in the Windows Powershell.evtx log.
> Lastly, you should review WinRM logs in Microsoft-Windows-WinRM/Operational for EID 6, 91, 168. WinRM is the primary protocol for PowerShell remoting.
> A strong Powershell audit policy should include Module Loggong, PowerShell Script Block Logging, and PowerShell Transcription.
43
Script block logs (see PowerShell logs)
> Audits are recorded as event log entries in Microsoft-Windows-PowerShell/Operational
> This happens regardless of whether PowerShell was executed from a command shell, the integrated scripting environment, or via custom hosting of PowerShell components.
> Script block logs record the code blocks executed, including dynamically generated script contents, but typically no output. Windows will label events as EID 4104 Warning events. in Powershell/Operational logging.
44
Module Logs (see PowerShell: Module logs)
45
Powershell Version 5 (and 6 and 7)
PowerShell "Core" versions 6 and 7 are rewrites of PowerShell using the .NET Core, allowing the tool to be used across all operating systems. However, these versions are intended to coexists with PowerShell version 5 and not be rplacements. They are installed in seperate locations, have seperate group policy parameters, and have seperate logs. Note that you need to turn on script block logging for all versions independently, but the logs will all come to Microsoft-Windows-PowerShellCore/Operational
46
Active Script event consumer for WMI persistence
scrcons
47
Scrcons
Active Script event consumer for WMI persistence
48
Command Lined Event Consumer for WMI
wbemcons.dll
49
wbemcons.dll
Command line event consumer for WMI persistence
50
Windows Management Instrumentation: Persistence
> To set up WMI persistence you need three discreet steps:
> 1. An event filter must be created describing a trigger to detect
> 2. An event consumer is added with a script and/or executable to run (typically CommandLine or Active Script consumers, PowerShell commands, or scripts/exe). Scrcons is the ActiveScript consumer and wbemcons.dll is the command line event consumer.
> 3. The event and consumer are tied together via a binding and the persistence tool is loaded into the WMI repository.
> To review this activity, you would rely on the WMI-Activity/Operational log: EID 5861 for new consumers (exe's, PowerShell, or VBScript), EID 5857 to track loaded DLLs, EID 5858 for WMI query errors. You can of course also rely on command line auditing.
> You can also run searches for PowerShell, eval, .vbs, .ps1, and ActiveXObject.
51
Windows Management Instrumentation (WMI): Logging/Auditing
> Command line auditing in Security or Sysmon logging makes discovering WMI usage trivial. However, without it investigating WMI use is very difficult.
> You would see wmic.exe running on a system.
> You may be able to rely on command line auditing from an EDR tool.
> You may see evidence in WMI auditing: WMI-Activity/Operational. However, this won't include the command line.
52
Windows Management Instrumentation (WMI): Lateral Movement
> wmic process call create: this command can be used to execute code on a remote system. It is essentially a stealthy version of PsExec.
> NetEnum/NetAdd commands can also be used to duplicate tokens of logged in users.
53
Windows Management Instrumentation (WMI): PrivEsc
> The most common tool for WMI PrivEsc is "PowerUp.ps1". This leverages WMI to query 20 common misconfigurations that can be used to elevate privs.
> These queries hunt for all service paths that have a space, highly privileged processes, unquoted service paths set to auto-start with the service binary not present under a Windows folder.
54
Windows Management Instrumentation (WMI): Reconnaissance
55
Windows Management Instrumentation (WMI): Overview
> WMI is Microsoft's implementation of the WBEM standard and is used to help the administration of large enterprise environments.
> WMIC.exe is the traditional portal for executing WMI commands, but this has largely been deprecated in favor of PowerShell, which has native WMI support. As such, much of your findings will be found in command line auditing or powershell logging.
> It is largely memory only, uses trusted signed binaries, and on the network side, it uses all standard DCOM/PSRemoting traffic, that is sometimes encrypted.
56
Process Tracking Events
> EID 4688 (start) and 4689 (stop) in Security logs.
57
PowerShell Tracking
> With Server 2012R2, Microsoft released a new group policy setting to enable recording of full command lines in process reporting: Computer Configuration > Policies > Administrative Templates > System > Audit Process Creation.
> This audit requires process creation auditing to be enabled. While this can be voluminous, it can be helpful on critical systems.
> Note that EID 4688 now includes the Process name, in addition to the Process ID, which was legacy.
58
Command Line Tracking (see PowerShell tracking / PsExec)
59
Microsoft Defender Logs
> Microsoft-Windows-Windows Defender\4Operational.evtx is the primary logs for Defender alerts. It can often provide 6 months of alerting. Use Event IDs 1116-1119 to capture malware detection events, actions taken on those events, and any failures while taking actions.
> Microsoft Protection Log (MPLog) found at C:\ProgramData\Microsoft\Windows Defender\Scans\History\Service\DetectionHistory can also fill in alerting gaps as a supplement to the primary logs.
> Don't forget to check the quarentine folder, which may still contain the malicious files (maldump to extract). This can be found at C:\ProgramData\Microsoft\Windows Defender\Quarentine
60
Microsoft Protection Log (see Microsoft Defender Logs)
> MPLog files are primarily used for diagnostic and troubleshooting purposes. They are in text form and can be opened and viewed using a txt editor. There can be multiple log files, named according to their creation time, but it is rare to see data going back further than a month.
> They should be used as a supplment to the primary Windows Defender log. For example, you can sometimes pull SHA1 hashes using this data. They can also be used to uncover renamed files, as the "Origional filename" is sometimes written.
> The "tainted" flag is used to track files that have been injected.
> You can also use the MPLog to track running processes at a point in time, as this is one of the only places this information is audited.
> Again, the data can be overwhelming, so it is to be used as a supplment when IOCs are preferably already known. "detection", "tainted" or SDN Query" are common bad terms.
61
Malware exectuion (evidence)
> Because Process Execution tracking is left disabled in most environments, we rely on System and Application logs heavily.
> In particular, you are looking for Critical, Error, and Warning events. The best ones are the security tooling alerts that get logged or evidence of system crashes or reboots.
> EID 1000 and 1002 report application errors and hands in Windows Error Reporting logs (WER).
62
Vulnerabilities: Lateral Movement
Vulnerabilities in Windows can be used for lateral movement. But these vulnerabilities are rare. Much more common are vulnerabilities in custom applications, which are difficult to patch. SANs groups remote access tools like Peterpreter and Cobalt Strike Beacon into these cateogires, as they circumvent the standard authentication process.
63
Vulnerabilities: Malware based lateral movement
> Detecting malware-based lateral movement can be a challenge.
> Pay attention to system crashes recorded in event logs
> Use threat intelligence to track signatures
> Use signatures built into EDR solutions.
> Analyse running processes and system memory.
64
Malware lateral movement (See vulnerabilities)
65
Application Deployment Software: Controls
> Limit and monitor accounts that have access to patch management or deployment tools
> Create unique accounts for this purpose
> Control patch management cycle times closely to facilitate malicious activity
> Creation and monitoring of test systems to collect and log package deployment.
> Note that their may be multiple deployment softwares across network segments, so it is important to make these changes for each one.
66
PowerShell: Lateral Movement and Remote Execution
> Remote powershell uses the WinRM protocol to scale tasks. However, note that remote PowerShell needs to be enabled.
> The most common comands are Invoke-Command and Enter-PSSession. The later provides an encrypted interactive shell to the remote system similar to SSH.
> On the source system, look for powershell.exe in common application execution artifacts. You can also look at Microsoft-Windows-PowerShell/Operational and Microsoft-WinRM/Operational logs. You can also look at ConsoleHost_history.txt on anything later than PowerShell version 5, as it records the last 4096 commands typed. Lastly look for Windows Remote Management (WS-Management) service enabled in environments that dont use it.
> On the destination system, look for wsmprovhost.exe following a Type 3 network logon. Then is enabled, Microsoft-Windows-PwerShell/Operational logs capture PowerShell script contents.
67
Windows Management Instrumentation: Lateral Movement
> WMI is a flexible remote and local management infrastructure that leverages PowerShell to execute commands. The most common is "process call create", which gives adversaries similar function to PsExec while leaving fewer artifacts. WMI commands are typically not encrypted unless used over WinRM (using PowerShell for example).
> On the source system wmic.exe is the only useful artifact (see ShimCache, AmCache, and PreFetch), but command line auditing is required to understand what was run.
> On the destination system, you are primarily looking for auth events tied to wmiprvse.exe, which is the core process used for remote wmic actions. But your key resource is the Microsoft-Windows-WMI-Activity/Operational log, which can help identify WMI event consumers. Also evidence of mofcomp.exe or .mof files are strong as they are used ti implement event consumers.
68
Scheduled Tasks: Source and Remote System Artifacts
See page 126 for evidence in Event Logs, Registry, and File System.
69
Remote Services (see Windows Commands)
> Evidence of sc.exe on source system can be seen via application execution artifacts (ShimCache, BAM/DAM, AmCache, Prefetch).
> Evidence on Destination system exists in event logs: 4624 Type 3, 4697 service installation and related SYSTEM service logs like 7034.
> Registry: CurrentControlSet\Services\ for new service, ShimCache and AmCache hive for malicious exe's.
> File system: malicious service executable or service DLL in file creation or Prefetch file of malicious executable.
70
Windows Remote Management
>If enabled on a system, WinRM can be used like PsExec to run remote commands. It can also be turned on by attackers to move laterally. Uses winrs, which starts the winrshost.exe.
> Microsoft-Windows-WinRM/Operational log tracks Win?RM connections, which is the primary protocol for PowerShell remoting. This is avaialble on both source and destination systems and records the destination hostname, IP, current logged-on user (Event ID 6) and the source session creation (EID 91) and the authenticating user account (EID 168).
71
Windows Remote Shell (winrs)
See Windows Remote Management
72
Powershell
> PowerShell commands or cmdlets are based on the .NET Framework objects, which means the objects carry multiple aspects or properties of the command.
> Commands based on the verb-noun naming scheme with the noun being the object or class of objects to do something.
> There are 150 prebuilt aliases that allow Windows commnds to be compatible with PS commands (you can use the Get-Alias command to find them).
PS Output are objects passed to other cmdlets via a pipe ( | ).
> Provider: PowerShell abstracts collections of items into containers called providers. These can be file volumes, the registry, Active Directory and so on.
> See Remote PowerShell (1.96)
73
Windows commands (see Remote Services)
Numerous Windows commands have remote execution functionlity.
> Create and start a remote service: sc \\host create [service], sc \\host start [service]
> Remote scheduled task: at \\host 13:00 ".exe", schtask /CREATE /TN [task]
> Remote registries: The Remote Registry service (reg.exe) can be run
> WinRM: If enabled Windows Remote Management can be used to run a windows remote shell (winrs) session on a remote host.
74
PsExec: Destination System Artifacts
> Steps: user authenticates to destination system, named pipes are set up, the ADMIN$ share is mountsed, and PSEXESVC.exe is copies and run.
> Event logs: 4624 Type 3 (and Type 2 if alternate creds used = user profile created), 4672, 5140 (admin$ share used), 7045 (service installation).
> Registry: (new service) SYSTEM\CurrentControlSet\Services\PSEXESVC, (Shimcache) psexesvc.exe, (Amcache.hve (psexesvc.exe.
> File system: (prefetch) C:\Windows\Prefetch\psexesvc.exe, psexesvc.exe places in ADMIN$ by default, as well as other .exe pushed by the service, (user profile) profile created, unless -e flag used.
> Named pipes: used by IPC$ to establish system to system communication.
75
PsExec: Source System Artifacts
> Look for PSEXEC.EXE on the source system in Prefetch, ShimCache, BAM/DAM, and Amcache.
> Registry key (first run time): NTUSER\Software\SysInternals\PsExec\EulaAccepted
> Explicit creds used: EID 4648 "runas" event created.
> Command line auditing
> PSEXEC.EXE (or renamed binary) in running processes or memory).
76
Admin Shares: Destination System Artifacts
> 4624 Type 3 logons and 5140 share access events. Rebuild SMB sessions using network monitoring.
77
Admin Shares
> Default shared resources designed to allow administrative programs access to the entire file system. The most commonly abused are the drive volume shares (like C$), the Admin$ share giving access to the Windows folder, and the IPC$ share commonly used by named pipes.
> Note that Domain Admin prvileges are now required for access to admin shares.
78
Lateral movement: Admin shares
See Admin shares
79
Admin Shares: Source System Artifacts
> Command line auditing and the use of commands like "net use".
> Registry: NTUSER\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2 (shows list of systems connected to by user)
80
MountPoints2
Registry key for admin shares (see Admin Shares)
81
RDP: Disable
> Active Directory setting "Deny log on through Remote Desktop Services" can be easily set on high valued accoutns.
> At the host level, RDP service can be disabled and the Windows firewall can be set to deny inbound RDP connections in parts of the network where RDP isnt required.
82
TerminalServices-RDPClient/Operational log
> Used to track RDP use on the source system, which is rare in Windows OS.
> You can also view the NTUSER\Softare\Microsoft\Terminal Server Client\Servers registry key for info from a source system. RegRipper plugin "rdphint" parses this data.
83
Microsoft-Windows-TerminalServices-RDPClient/Operational log
(see TerminalServices-RDPClient)
> TerminalServices-RDPClient/Operational log
> NTUSER\Software\Microsoft\Terminal Server Client\Servers registry key
> Jump List: mstsc.exe = RDP client
> Default.rdp in User Profile.
> RDP Bitmap Cache (bmc-tools.py to parse)
> Application logs for VNC tools or RMM tools like AnyDesk (C:\ProgramFiles\*)
84
RDP: Source System Logs
85
mstsc.exe (see RDP: Source System logs)
RDP Client in Jump List
86
Default.rdp (See RDP: Source System Logs)
User profile file indicating RDP use
87
Map files (see EvtxECmd)
The standardised fileds that are available for use in maps include:
> UserName:
> RemoteHost
> ExecutableInfo: Used for things like process command line, scheduled task, info from service install.
> PayloadData1-6:
88
EvtxECmd
> Tool used to analyse Windows Event Logs.
> True value is ability to filter, normalise, and merge logs at scale from lots of different systems.
> It can be run on a live system or a collection of logs and used Xpath map files to synchronise output from lots of event types. Xpath allows us to identify specific parts of XML output. The Map file contains the values of the event type to extract using Xpath filter notation.
> It can also analyse Volume Shadow Copies (VSS) when run on live systems.
89
Local Security Authority Subsystem Service (LSASS)
90
Log Clearing
> Local administrators, domain administrators, and the local SYSTEM account all have the privileges to clear event logs (admin privs required).
> This will generate a ID 1102 event in the Security logs. ID 104 will be generated when any other log is cleared. Clearing from both the Command Line and GUI are captured.
> Only writable by LSASS (see Local Security Authority Subsystem). Log clearing is all or nothing.
91
Event Log Clearing (See log clearing)
92
Per-User Service
Beginning with Windows 10, Windows is now starting and stopping unique instances of services for each user logon. These services are named by adding a Locally Unique Identifier (LUID) to end of the service name. This makes the Security log much more voluminious. As such, it is important to rely on the System log more for malicious services.
93
Invoke-Command
> PowerShell command to push tasks and scripts to remote systems.
94
WS-Management (WSMAN)
> Transfer protocol used for Windows Remote Management (PowerShell remoting). Uses SOAP, XML, and HTTP listeners to pass through packet inspection devices.
95
Powershell Authentication
> Authentication occurs over Kerberos via a Type 3 non-interactive logon.
> Sessions are non-interactive so password hashes are not cached
> Uses nondelegated authentication tokens that can't be stolen.
> In cases where scripts require access to third-systems, you can use CredSSP, which is essentially single sign-on. Credential hashes and tokens are stored on the system in these cases.
96
PowerShell Remote
> Windows Remote Management service is used to launch PowerShell remotely. Its enabled by default all the way back to Server 2012.
> WS-Management (WSMAN) is the transfer protoco, which then passes traffic to remote devices using SOAP, XML, or HTTP listeners. The remote host then launches wsmprovhost.exe.
> The data is encrypted in transit and Kerberos is used for authentication, so password caches are not hashed. Tokens are also non-delegated so cannot be used elsewhere.
> Enter-PSSession provides an interactive remote schell. However, unlike RDP or PSExec, credentials are not cached on the remote system.
> The Invoke-Command cmdlet is used to send remote tasks to systems without creating an interactive session. This means credentials are not cached. You can copy a script to a remote host using the -FilePath option or the -ScriptBlock parameter. You can also run these scripts on a list of machines efficiently, as the processing is done on the remote host, as opposed to WMI, which does this locally.
> CredSSP enabled "dual-hop" authentication, which allows scripts on a host to access a third system. However, you want to avoid this, as this means creds can be stolen. For example, you would need this if a script needed access to a network share.
>
97
KAPE
> Designed to collect "target" files, which identify specific artifacts to be collected in a "triage" image. Targets can be grouped into meta-files to be used for different forensic case types.
> Sample cmd line: kape.exe --tsource F --target !SANS_Triage --tdest C:\temp\Output
> tsource: drive letter to search (C, D:, or F:\.)
> target: target config to run without the extension (--tlist switch lists targets).
> tdest: directory where files should be copied to. Can be a regular directory or a UNC path.
> tvss: Find, mount, and search all available Volume Shadow Copies on --tsource.
> vhdx or vhd: Creates a VHDX virtual hard drive from the contents of --tdest.
98
Velociraptor Overview
> Allows for the ability to query for IOCs and hunt for intrusions across thousands of hosts. You can then locate and retrieve files, perform additional analysis with built-in searches, and even launch an interactive shell to the clietn if necessary.
> The majority of client-server deployments involve a single server, whcih can handle as many as 10,000 clinets. However, this can be scaled if needed by doing things like including a reverse proxy server to manage the encryption task, or using multiple servers to handle the front end client connection tasks while sharing backend storage.
> Relies on Velociraptor Query Language (VQL). Can be used for one time collections or for continual collections of data.
> It can also be used to launch third-party triage tools like KAPE.
> All that is needed is a single excutable file and a config file.
99
Velociraptor artifacts
> Allows analysts to quickly store and execute VQL queries.
> For example, Windows.System.Pslist artifact searches for running processes by name.
100
Velociraptor hunts
> Scheduled queries that are active by default for 7 days. Any clients that match the selection criteria specified when the hunt was created will run the job once they come online. They will not run when an agent is offline.
> Details pane on the screen will show information about each hunt, such as artifact name (multiple can be run in the same hunt), and any parameters specified by the analyst for the artifacts. Also includes client count and options to download findings.
> Additional filtering of results can be done in the Notebook tab by editing the default VQL query.
101
Velociraptor analysis
> There is a Results tab built into the Velo UI. It provides a default view of all collected data and a "transformation" button that allows sorting and filtering.
> The Results tab is only available for flows displayed on a specific client's Collected Artifacts page, whereas the "Notebook" tab is available on both the Hunt Manager page and the per-client Collected Artifacts page.
> The "Notebook" tab can be changed by editing a VQL defining what results are shown. For example, the "LIMIT 50" statement can be removed. You can also edit the "SELECT*" statement to display columns of interest.
> While you can export to CSV, note that some columns include nested JSON, so dont display well in this format.
> You can also export to Splunk or Elastic. This is typically required when deployments get large, as managing client communication and queries can get overly burdensome.
102
Velociraptor: Common queries
103
Velociraptor: Common built-in artifacts
104
Local admin account: protections
> They cannot write to C$ and Admin$ shares and cannot use some remote management tools like schtasks, at, or WMI (if WinRM is enabled, WMI/PowerShell will still work using a local admin account). These protections do not apply to the built-in admin account (RID 500).
105
User Account Control (UAC)
> Because Windows XP was a security low point, Vista/Windows 7/Server 2008R2 introduced User Access Control (UAC), which restricted certain applications to user-level permissions by default (web surfing and file opening for example). Note that it does not include process isolation.
106
Managed service accounts
> Released with Server 2008R2 and are one of the few mitigations available to combat some Kerberos ticket attacks.
> It provides frequent password changes (30 days by default) and long and complex passwords for service accounts with domain account rights.
> Group managed service accounts is the upgrade to managed service accounts. It was released with Windows 8.
107
Group managed service accounts
> See managed service accounts
108
Credential attack mitigations
> Windows Vista/Windows 7:
> User Account Contro (UAC), managed service accounts/group managed service accounts.
> Windows 8.1:
> CredSSP and other single sign on credentials like TsPkg and Wdigest are no longer cached in memory by default (limits ability of Mimikatz to recover plaintext creds from these sources).
> A new security group added to facilitate restricting local admin accounts from network or remote interactive logons (breaks pass-the-hash attacks, mounting remote shares, remote WMI, PsExec, and remote scheduled tasks using local admin accounts).
> Protected processes introduced that can only load signed code and can only be attached to other protected processes (LSASS added to this list, although Mimikatz gets around this and protection is off by default).
> Remote Desktop can now be executed using the "/restrictedAdmin" switch, ensuring that credentials and tickets are not pushed to target systems during interactive RDP sessions (this can be forced for accoutns using GPO). This feature was suceeded by Remote Credential Guard in Windows 10+ and disabled by default, as it opened up RDP sessions to pass-th-has attacks.
> Domain protected user group: designed to protect high-value (privileged) accounts, as members cannot authenticate via weak NTLM, CredSSP, or Digest authentication defeating some Mimikatz and pass-the-hash attacks. Creds are not cached on systems and tokens cannot be delegated. NT hashes are also not cached on remote servers. Kerberos ticket life reduced to four hours and RC$ ticket encryption is denied.
> Windows 10 and 11
> Credential guard added to isolate hashes and tickets using a security boundary enforced by machine virtualisation.
> Remote Credential Guard is an update to Restricted Admin and protects any account (not just admin) during RDP sessions.
> Device Guard is a new version of application control that locks down systems to prevent untrusted code from running on a system.
> Windows 11 inherited the improvements introduced in Windows 10 with no substantive changes.
109
Protected User Group
See domain protected user group.
110
Domain Protected User Group
> Feature of Windows 8 to protect against credential attacks. Designed to protect high-value (privileged) accounts, as members cannot authenticate via weak NTLM, CredSSP, or Digest authentication defeating some Mimikatz and pass-the-hash attacks.
> Creds are not cached on systems and tokens cannot be delegated. NT hashes are also not cached on remote servers.
> Kerberos ticket life reduced to four hours and RC$ ticket encryption is denied.
111
Proteted process
> Protected processes introduced that can only load signed code and can only be attached to other protected processes (LSASS added to this list, although Mimikatz gets around this and protection is off by default).
112
Remote credential guard
Ensures that credentials and tickets are not pushed to target systems during RDP sessions to protect against credential theft. Update to Restricted Admin and protects any accoutn (not just admin) during an RDP session.
113
Credential Guard
Feature that isolates hashes and tickets using a security boundary enforced by machine virtualization.
114
Restricted Admin
Feature that protected against credential stealing during remote sessions by ensuring that creentials and tokens are not available on remote systems. Replaced by Remote Credential Guard.
115
NT hash
See password hashes
116
LM hash
See password hashes
117
Cleartext passwrods
These are typically stored in memory and can be extracted and decrypted. Some of these are the result of single sign-on like TsPkg and Wdigest, while another LiveSSP is derived from the new Windows "Live" cloud accounts. Mimikatz was the first to exploit this but Windows Credential Editor (WCE) can still be used.
118
Pass-the-hash attack
> Allows an attacker to authenticate using a stolen account hash without ever knowing the cleartext password. Tools used to achieve this include Metasploit PsExec module, WCE, SMBshell. Pass the hash is limited to NTLM authentication and takes advantage of the fact that only the hash is necessary to respond to an NTLM challenge-response protocol. While most authentications use Kerberos, NTLM is still almost always available.
> Mimikatz replaced the "pth" command with functionality called "overpass the hash". However, Metasploit keeps true to the origional implementation.
119
Password hashes (defending against attacks)
> The most common are LM (deprected) and NT hashes.
> Local account password hashes are available in the SAM registry hive and domain account hashes are present in memory during interactive sessions.
> To exploit these features, attackers can extract hashes from LSASS in memory, dump the LSASS process for offline attacks, and extract local account hashes from the SAM hive in memory or on disk (note this all requires admin privileges).
> A domain user account must interactively log on to a system for its hash to be present in memory and the hashes are only available while the user is logged on (unless applications or processes are still using them after logging off).
> Because hashes are only present during interactive sessions, avoiding console logons, RDP, and runas will ensure hashes are not at risk (if an RDP session is disconnected but not closed, the hash can persist). Ensuring RDP sessions time out via GPO can also help.
> Restricted Administrator accounts (do not make hashes available on remote system), Domain Protected User security groups (cannot auth vi NTLM, WDigest, or SSP and do not cache creds), Protected Processes (only execute signed code), Credential Guard (uses hypervisor to move domain creds, tickets, and hashes from LSASS into an isolated process (LSAIso), Remote Credential Guard (do not make hashes available on remote system), Restricted Admin accounts, Local Administrator Password Solution (LAPS)(don't share local admin creds).
>
120
Cached credentials
> Interactive logons at the console, via RDP, and using runas, cache hash and ticket credentials on the target system. They should not be used for highly privileged accounts.
> Powershell remoting is a much more secure option, as is enabling new Windows 10+ protections like Remote Credential Guard.
> Adding an explicit username and password (similar to runas) on the PsExec command line makes the difference.
121
Local Administrator Password Solution (LAPS)
LAPS centralises security and the management of local admin accounts within Active directory. Hashses are less useful when they cannot be used elsewhere.
122
Token
> A token contains security context and privileges for an account. Special tokens named impersonate and delegate, facilitate access control and single sign on. Impersonate tokens allow local security context shifts and the more powerful delegate tokens facilitate authentication even across network resources. Later mostly present during interactive logons.
> A user with the SeImpersonate privilege (or with the admin or SYSTEM privs) can extract the token and reuse it to add users or manage group membership and map remote admi shares or running PsExec (delegate tokens only).
> Commonly used to elevate from local admin to domain admin.
> Tokens are present when an account is logged in. Also available when RDP is not properly terminated.
> Mimikatz command "token::elevate /domainadmin" command can be used to identify domain admin privileges, retrieve them, and load them into process memory so the higher-level privileges can be used.
123
Impersonate token
Local admin token for local resources (see token)
124
Delegate token
Allows access to network resources (see token)
125
Cached credentials
> Windows caches the last ten logon hashes by default (this was increased to 25 on Windows Server 2008).
> Creds are stored here so a workstation doesn’t need to communicate with a DC in an offline state.
> Cached creds are stored in the Security registry hive in the SECURITY\Cache key. Admin (or System) privileges are required to access the saved hashes, which are in mscash2 format for modern Windows operating systems.
> Since data is kept in the registry, these hashes persist through a reboot.
> Because Mscash2 hashes are encrypted, they cannot be used in a pth attack. They are also secured better than NT hashes, including a hash salt of the username to defeat pre-computation attacks.
> Brute forcing these can be accoumplished, but this process is slow, particularly with a strong password policy.
> Creddump can be used to collect these hashes.
126
Cached credentials: mitigations
> Reduce the default number of cached logons in the registry key SOFTWARE\Microsoft\Windows NT\Current Version\Winlogon\. By default, Windows workstations cahce the last 10, some servers cache the last 25. It is reecommended that this be 4 or less. Note that the cachedlogonscount value is not only for user accounts but also for service accounts and computer account logons. So be careful.
> Password complexity and length drastically reduce likelihood of cracking.
127
LSA Secret
> LSA Secreate key in the Windows registry stores passwrods for services that need to run autonomously using a domain account, rather than a local account.
> Stored in encrypted form in the Security hive registry key SECURITY/Policy/Secrets.
> Each secret has its own key and parent key within SECURITY/Policy which is used to decode "secrets"
> Dumping tools also require access to the System hive to access a final decryption key.
> Administrator privileges are require to access these keys.
> Once dumped all passwords are in cleartext.
> Nishang framework used to exploit LSA secrets (Get-LsaSecret script). It requires a 32-bit PowerShell console.
128
LSA Secret: Mitigations
> Ensure low-trust systems do not have services or scheduled tasks present that require high privileged, non-built-in accounts.
> Managed Service Accoutns were released with Server 2008R2. It provides frequent password changes and complexity for service accounts. Group Managed Services Accounts is the latest iteration.
129
Ticket Granting Ticket (Kerberos)
> Issued Kerberos tickets are valid for 10 hours by default. Attackers can use tickets to impersonate privileged users, evade the authentication process, and reduce logging of their efforts.
> Mimikatz' "kerberos::ptt" command can be used to import a ticket.
130
Kerberos attacks
131
Pass the ticket (Kerberos)
> Kerberos attack in which an attacker uses a stolen TGT ticket to authenticate using that account's credentials. Tickets can also be imported into other systmes, allowing a user "transplant" without requiring any knowledge of the user hash or password.
132
Prefetch: First Execution
Creation date of .pf file (~-10 seconds)
133
Prefetch: Last Executed
Last modification date of .pf file (~-10 seconds) + also in the .pf file as last time entry
134
PECmd.exe
Tool to parse and audit Prefetch files
135
Prefetch: registry key 1
SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management EnablePrefetcher
136
Prefetch: registry key 2
SYSTEM\CurrentControlSet\Services\SysMain Start
137
SuperFetch
Prefetch: stored in files name Ag*.db (AgAppLaunch.db)
138
Prefetch: Definition
OS loads data/code into memory (prefetch directory) before needed.
139
Prefetch: directory
Contains 128 .pf files on Windows 7 and before. 1024 files on Windows 8 and above.
140
Prefetch: .pf file
Prefetch file. Captures 8 execution times = 9 run times when added to file system creation time.
141
Prefetch: cache manager
Prefetch: Records files and directories for .pf prefetch files.
142
Prefetch: file name / hash
Combination of .exe file name, a dash, and a hexadecimal representation of a hash of the file's path.
143
Security Logs Objects
> Account Logon
> Account Mgmt
> Directory Service
> Logon Events
> Object Access
> Policy Change
> Privilege Use
> Process Tracking
> System Events
144
Security Logs Overview
> Only the Local Security Authorit Subsystem Service (LSASS) can interact with the Security log
> Only admins can review, export, or clear the log
> There is currently no known method to manipulate the log effectively.
145
Event Logs: Three primary types
> Security: Records events based on auditing criteria included in local or group policies.
> System: Records events logged by the OS or its components.
> Application: Records events logged by applications.
146
Event Logs: Location (Vista and before)
%systemroot%\System32\config
147
Event Logs: Location (post-Vista)
%systemroot%\System32\winevt\logs
148
Event Logs: Custom Location (Registry)
> HKLM\SYSTEM\CurrentControlSet\Services\EventLog\Application
> HKLM\SYSTEM\CurrentControlSet\Services\EventLog\System
> HKLM\SYSTEM\CurrentControlSet\Services\EventLog\Security
149
Event Logs: Max Capacity/Log Rolling
When the max size of a log is reached, you can:
> Overwrite events as needed (Default)
> Archive the log when full; do not overwrite events ("Archive-Security-")
> Do not overwrite events (error messages generated to indicate full event log), requires manual clearing.
150
appcompatprocessor.py
Toolset deisgned to perform hunting of ShimCache and Amcache artifacts placingthe result in a SQLite database.
151
Amcache_DriverBinaries
Output from AmcacheParser containing information from the InventoryDriverBinaries key
152
Amcache_ProgramEntries
Contains data from the InventoryApplication key. Contains metadata on installed applications.
153
Amcache_UnassociatedFileEntries
File in InventoryApplicationFile key detailing information on executables present on the system that have not been installed as part of an installation package.
154
AmcacheParser.exe
Tool to parse Amcache data.
155
InventoryDriverBinaries
Amcache: Contain information relating to loaded drivers
156
InventoryApplicationFile
Amcache registry hive containing list of applications
157
InventoryApplication
Amcache registry hive containing a list of "installed" applications, so contains a subset of InventoryApplicationFile
158
Amcache: Evidence of Execution
Does not confirm execution, as AmCache also tracks .exe and .dll that were copied as part of application execution and .exe present in one of the directories scanned by the Microsoft Compatibility Appraiser scheduled task.
159
Amcache
Amcache tracks installed applications, programs executed, drivers loaded among others. It provides full path info, file size, publisher metadata, loaded drivers, SHA1 hash, and timestamps. Iportant keys are InventoryApplication, InventoryApplicationFile and InventoryDriverBinaries.
160
AppCompatCacheParser.exe
Used to parse an offline SYSTEM hive or to collect data on a live system (Windows 7 and above).
161
ShimCache: Application Compatability Cache
Designed to detect and remediate program compatibility challenges when a program launches. Different compatability modes are called "shims".
162
ShimCache: Location Windows 7+
Memory: SYSTEM\CurrentControlSet\Control\SessionManager\AppCompatCache\AppCompatCache
163
ShimCache: Location Windows XP
Memory: SYSTEM\CurrentControlSet\Control\SessionManager\AppCompatibility\AppCompatCache
164
Malware execution (WER Report)
Windows Error Logs (WER) are stored as files named Report.wer and are written in plain text or XML format. Of notes, they can include the SHA1 hash of a file, although note that there is a file size limitation, so the Report.wer won't catch very large files.
They can be present in multiple different "WER" folders including:
> C:\ProgramData\Microsoft\Windows\WER
> %User Profile%\AppData\Local\Microsoft\Windows\WER (also check Default, Public, and ALL Users profiles)
165
Overpass the hash (Kerberos)
> A user hash can be used to request a TGT ticket. Because the attack employs Kerberos instead of NTLM, it can work even when pass the hash mitigations are in place (like limiting NTLM).
166
Kerberoasting
> Any domain user can request a ticket from the Domain Controller for any domain service. The ticket returned for such a request has a non-salted password hash for the account that runs that service. A user can request this hash and then crack the password offline, limiting any evidence of brute force. This is valuable, as service accounts can have high privileges.
167
Golden Ticket
> Golden tickets can be created for any account. They do not expire and persist through password changes. They are frequently used to create persistent domain administrator TGTs.
> To achieve this, an attacker must have admin creds on the domain controller. They can then extract the hash for the krbtgt account, which is the account used to create tickets. This can be extracted from memory or via the theft of the NTDS.DIT AD database. The ticket is then created offline.
168
Skeleton Key
> Once an attacker has access to the DC, a tool like Mimikatz can patch LSASS to enable a backdoor password for any valid domain user. A user's actual password can still be used to authenticate, but accounts will also authenticate with the "skeleton key" even after a user changes their password.
169
DCSynch
> Because DCs frequently communicate with one another using the MS-DRSR protocol, attackers can abuse this service to send "sync" requests to a legitimate DC, using this protocol, for the password hash (and hash history) of an account of their choosing.
> This attack requires access to privileged accounts in the Admin, Domain Admin, and Domain Controllers groups.
> This attack can be done remotely without having to interactively log into the DC. You can even request the KRBTGT ticket required to create Golden Tickets.
170
DCShadow
> DCShadow uses the MS-DRSR (Directory Replication Service Remote Protocol) used in DCSynch attacks to inject data into the AD infrastructure to maintain persistence or setup advanced attacks.
171
Silver Ticket
> By dumping a computer account hash from memory, an attacker can create a "Silver Ticket" for that system. In this attack, an attacker forges a service ticket using a dumped computer account hash and can usually impersonate any user for that system, including domain admin.
> Having a computer's NT hash means you can make a service ticket with any user/group memberships you want for that computer. You can be anyone up to and including Domain Admin.
> Authentication does not require access to the Domain Controller, so is excellent from a persistence perspective.
> Computer account passwords tend to be changed less than user account passwords.
172
Kerberos attacks: mitigations
> Ticket attacks are the most difficult to prevent, as attacks abuse legitimate elements of the Kerberos workflow. Tickets can also remain valid through password changes and since tickets are generated after MFA is employed, this control is bypassed.
> Credential Guard in Windows 10+ uses virtual machine isolation to prevent access to a user's hashes and tickets.
> The Domain Protected Users security group that debued in Windows 8.1 can prevent attacks like overpass the hash since it eliminates the abilty to use the legacy RC4 encryption scheme. Tickets also have a shorter lifespan by default (4 hours). However, the users ticket must still be present in memory, so ticket attacks cannot be completely prevented.
> Remote Credential Guard and Restricted Admin means that tickets are not passed during remote interactive sessions like RDP. Thus, tickets for high-value accounts cannot be stolen from remote systems when these options are available.
> However, these protections are not effective against service account abuse. For example, an attacker can use a user account to request a service account ticket from a DC. Any domain user can request a ticket from the DC for any domain service. These tickets contain password hashes that can be cracked (Kerberoasting).
> Attackers hunt for services running under Admin or Domain Admin privileges.
> The only mitigation here is to use long complex passwords that are difficult to crack and to change service account passwords regularly. Managed Service Accounts will automatically cahnge service account passwords every 30 days and uses complex passwords.
> To prevent Golden Ticket attacks, regularly rotate these tickets. These attacks can be identified by looking for invalid accounts being used in the enterprise.
173
Kerberos attacks: mitigations
174
NTDS.DIT
> Account hashes in this file are in NT format (and possibly LM for older systems). Hashes for each account's password history are also present.
> The NTDS.DIT database is in Extensible Storage Enginer (ESE) format and is stored in the %SystemRoom%\NTDS folder. The location can be changed and this is recorded in the HKLM\SYSTEM\CurrentControlSet\Services|NTDS\Parameters folder.
> Because the folder is locked, extracting the file requires using built in tools like ntdsutil, loading a driver or tool that gives raw access to the disk (evading Windows API protections) or using the built-in Volume Shadow Copy service. Admin privileges on the DC are required for these.
> The Volume Shadow Copy technique is the easiest. If there are no VS copies, one can be created. Note that that SAM and SYSTEM registry hives must also be extracted to facilitate decrypting the data.
> Once offline, tools like Impackets secretsdump.py can be run. This provides NT hashes for every account which can then be cracked or used in pass-the-hash attacks.
175
Bloodhound
> Because Bloodhound can identify users, groups, and where those users currently have sessions, it presents a step-by-step path of where to dump credentials and where to laterally move next.
> Bloodhound uses LDAP requests, so many near-simultaneous LDAP sessions can be indicative. However, the latest version Sharphound use cached LDAP conections, limiting the footprint.
> Similar tools include GoFetch and DeathStar.
176
IR process
1. Preparation
2. Identification and Scoping
3. Containment/Intelligence Development
4. Eradication\Remediation
5. Recovery
6. Lessons Learned/Threat Intel Consumption
177
Eradication and Remediation
> Block malicious IP addresses
> Blackhole malicious domain names
> Rebuild compromised systems
> Coordinate with cloud and service providers
> Enterprise-wide password changes
> Implementation validation
178
Recovery
> Improve Enterprise Authentication Model
> Enhanced Network Visibility
> Establish comprehensive Patch management program
> Enforce change management program
> Centralised logging (SIEM)
> Enhance password portal
> Establish security awareness training program
> Network redesign
179
Whack-a-mole
180
Active defense and containment actions
These can include decoy datasets, corrupting data, preventing data exfiltration or lateral movement, employing kill switches on the network, full-packet caputre monitoring of adversary-controlled systems and network segments, host-based monitors and key loggers.
181
Failed remediation
Threat actor reenters and environment after remediation occurs.
182
Remediation controls
> Disconnect the network from the internet
> Implement strict network segmentation not allowing specific subnets to communicate with each other.
> Block IP addresses and domain names for known C2 channels
Remove all infected systems that maintained active or previous active malware on the host
> Remove all systems identified as compromised
> Restrict access to known compromised accounts.
> Restrict access to domain admin accounts.
> Remediation validation.
183
Reactive organisation
One that doesn’t threat hunt proactively, but waits for an incident notification to come in before doing DFIR.
184
Hunt Team
> Team Lead
> Endpoint / host / cloud analyst
> Network analysts
> Reverse engineering malware specialist
> DevOps tool development resource.
> Cyber threat intelligence capability is key: Where to look, what to look for, likelihood of attack.
> Right mindset: Dont be afraid to move on: Dont go down rabbit holes: Know the difference between normal and abnormal.
> Right tempo: Make sure the team doesnt burn out.
> Management need to buy in.
185
Attack Cycle
> Initial Compromise:
> Low priv lateral movement:
> High priv lateral movement: From cred collection to asset discovery. Longest length of time, as creds are usually compromised early.
> Asset access and exfiltration:
186
Kill Chain
187
Indicators: Three types
> Atomic: Indicators of malicious activity on their own (C2 channels, Ip addresses, email addresses, FQDNs).
> Computed: Computed IOCs like hashes, decoded data, ID signatures.
> Behavioural: Combination of indicators.
> The further down this list you get, the close to the adversary you are getting.
188
ATT&CK: Adversarial Tactics, Techniques, and Common Knowledge
A model and framework for describing the actions an adversary may take while operating within an enterprise network.
> Recon
> Resource development
> Initial access
> Execution
> Persistence
> PrivEsc
> Defense Evasion
> Cred access
> Discovery
> Lateral movement
> Collection
> Command and Control
> Exfil
> Impact
189
Indicator of Compromise
There are two types of IOCs: host-based and network-based. STIX language seeks to standardize IOC reporting. See also YARA rules and OpenIOC. Both are IOC schemas. Tools like MISP and CRITS can be used for managing IOCs.
190
STIX Language (see IOCs)
IOC reporting language
191
OpenIOC (see IOCs)
Origionally designed by Mandiant to codify intelligence.
192
YARA (see IOCs)
> With YARA, you can create descritions of malware families based on text or binary patterns (signatures). It is the most widely used schema. The goal of a YARA rule is to create a signature that is specific enough to cut out FPs but broad enough to still match different variants of the same malware sample.
> Origionally designed by Virus Total to classify malware samples. Can be run on Linux, Mac, and Windows.
> Many YARA rules are strings based, but more sophisticated rules can be created using regular expressions, wildcards, conditions, and modules, such as pe header components from the PE structures.
> It takes a single YARA rule file as input and scans a collection of files for signature matches (including the ability to search recursively).
> There is no capability to point the rules file at a collection of signatures. If using multiple signatures, they must all be appended into the same signature file or referenced as part of an "index" files.
> A YARA rules file can be compiled using the yarac64.exe compilation tool and then referenced using the "-C" option on the YARA command line.
193
Malware Paradox
Malware can hide, but it must run. This means that execution artifacts will be generated, which can be reviewed by an analyst. It also means that malware typically requires a persistence mechanisms.
194
Intrusion Methodology Roadmap
1. Threat Hunting and Assessment: Broad threat hunting across environment.
2. Triage Collection and Analysis: More specific threat hunting of individual machines
3. Deep Dive Forensics: Deep analysis of machines.
195
Malware Detection Types: Three kinds
1. Systems with Active Malware
2. Systems with Dormant Malware (Not active or cleaned up by TA)
3. Systems without tools or malware (living off the land)
196
Threat Hunting in IR
197
Digital certificate
Legitimate software will be signed by a trusted certification authority. This will identify the origional code author. Once issued, the developer can use their private key to digitally sign the code, providing attribution. These cert authorities require that developers provide identifiaction. Most also requires a Dun and Bradstreet Rating (or a DUNS number). However, threat actors can and do steal private keys from developers through places like GitHub repositories.
198
Code signing (see digital cert)
199
DUNS number (see digital cert)
Dun and Bradstreet number
200
Certificate Revocation List (CRL)
A list of stolen certificates used to sign malware (see digital cert).
201
Signed malware
A very small amount of malware is signed (between 1-4%). Higher amoung nation-state malware. Although signing the malware can help the software stay hiden, the downside is that should a threat hunter discover a fraudlent cert, this then becomes a valuable IOC that can be used across the estate. It may also burn malware being used by the threat actor across other targets, as stolen certs are limited.
202
Userinit key
> Winlogon (user logon) executed userinit.exe from the Userinit key followed by explorer.exe. However, a TA can place a malicious binary here that is run on user logon as persistence tool.
203
AutoStart Persistence
There are several "autoruns" locations in Windows. These are also known as AutoStart Extension Points (ASEPs). Most of the common ASEP locations are in the registry, which are executed on user logon. The most popular include:
> NTUSER.DAT\Software\Microsoft\Windows\CurrentVersion\Run
> NTUSER.DAT\Software\Microsoft\Windows\CurrentVersion\Runonce
> Software\Microsoft\Windows\CurrentVersion\Runonce
> Software\Microsoft\Windows\CurrentVersion\policies\Explorer\Run
> Software\Microsoft\Windows\CurrentVersion\Run
The Userint key is also less common, but equally effective. This value would typically only contain userint.exe, but threat actors are known to include additional values which are executed at boot:
> SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Userint
A final location is in the file system. Again, these execute on user logon:
> %AppData%\Roaming\Microsoft\Windows\Start Menu\Programs\Startup
204
ASEP (AutoStart Extension Points)
See AutoStart Persistence
205
Windows Services (also see Service)
> Services are desighned to run applications in the background without user input. Many services, such as DHCP Client and Windows Event Log, are designed to run at boot.
> Services can be implemented as standalone .exe or loaded as DLLs.
> To conserve resources, many DLLs are grouped and run under svchost.exe instances.
> Service and driver configs are stored in the registry at: HKLM\SYSTEM\CurrentControlSet\Services
> Each service has a start type value configured to start at boot, by manual intervention, or on trigger events such as obtaining an IP address or hardware device connection.
> Start values of 0x02 (Automatic) and 0x00 (boot start of device driver) can provide persistence.
>
206
svchost.exe
> Used to group together services used on system start up (see Windows service and service).
207
Service (also see Windows service)
> Windows services are designed to run applications in the background without user interaction.
> Many services are required to run on botting, including the DHCP client, Windows Event Log, Server and Workstation services.
> They are loaded either as standalone .exe or loaded as DLLs.
> Many services are grouped together and run under svchost.exe, which is why it is common to see many svchost instances running.
> Service and driver configs are stored in HKLM\SYSTEM\CurrentControlSet\Services (also include service name, display name, path to exe file, start value, privs, dependencies, and more).
> This includes start triggers, such as on boot or on trigger events, such as hardware devices connections orobtaining an IP address. 0x02 (Automatic) and 0x00 (Boot on start of a device driver) are common in persistence.
> With admin privs, it is easy to use the sc command to create a service that aut-loads a malicious DLL or EXE. TAs can also replace unused services to blend in. For example, TAs can replace the rarely used RIP Listener Service (IPRIP). Lastly, TAs can use service recovery mode to input a malicious service to start up when a system crashes.
208
Service recovery mode
> If a threat actor can reliably crash a service, they can then replace the service with a malicious binary. The service recovery mode will then launch the malicious binary on crash.
209
sc command
> Command to create a services that starts on boot.
210
Service replacement
> Instance in which a threat actro replaces a service that is disabled or unneeded and replaces the existing binary with a malicious one.
211
Job file (see Scheduled tasks: persistence)
> File created when at.exe command is used to schedule a task.
> Lists job files sequentially in Windows\Tasks and Windows\System32\Tasks folders (at1.job).
212
schtasks.exe (see scheduled task: persistence)
> Tool used to schedule tasks. Upgrade from at.exe. Allows more fine control over tasks, such as trigger when user logs on.
> Logged in Tash Scheduler Operational logs.
> Example: schtasks.exe /create /sc daily /tn winsvchost /tr c:\temp\winsvchost.exe /st 22:00
> Can schedule a task on a remote system (artifacts on remote system)
213
at.exe (see Scheduled task: persistence)
> Command used to schedule a task. Use recorded in at*.job files ans Schdlgu.txt (Win XP).
> Can schedule a task on a remote system (artifacts on remote system).
214
Scheduled Tasks: Persistence
> Scheduled tasks are stored in the \Windows\Tasks and Windows\System32\Tasks folders. The files are stored as .job files and stored sequentially starting with "at1.job" and record details about the task.
> In Windows XP, task informatino stored in Windows\Schedlgu.txt log.
> Tasks can be scheduled either via schtasks.exe or via at.exe jobs. Hence the at1.job lexicon. For example, at.exe 22:01:00 c:\temp\winsvchost.exe schedules that task.
> schtasks.exe is more versatile as it allows a user to configure a tasks in different ways, such as when to run it.
> both at.exe and schtasks.exe allow for the scheduling of tasks on remote machines. This can allow attackers to spread malware, execute batch scripts, and perform actions like credential dumping.
> Most artifacts for remote tasks are present on the destination not the source.
> Commonly used even by advanced attackers. For example, the SUNSPOT malware using in th SolarWinds attacks was seen running as a scheduled task.
215
Search order hijacking
> When an .exe runs in Windows, it is not required to hardcode the location of any DLLs. Instead a search order is used to find the right DLLs, which starts will DLLs that sit next to the .exe file. The exception to this rule is for DLLs present in the KnownDLLs Registry key, which hardcodes a small number of DLL locations.
> As a result, if a TA can find an executable that is not located in the System32 folder and loads a DLL not present in the KnownDLLs registry key, they can place a malicious DLL in the same folder as the target exe and trump the search order. This ensures their bad code is run whenever the target .exe is run. (SANS use ntshrui.dll as an example).
216
Phantom DLL hijacking
> Attacks can also replace DLLs that are very older and may no longer be in use. As such, an attacker can place a malicious DLL with the same name in a higher up position in the search order. When the exe is run, this malicious DLL is then run.
> fxsst.dll (Fax Service) DLL in the System32 folder is a good example of this.
217
DLL side-loading
> This attack uses the windows side-by side (SxS) DLL loading mechanism to introduce an "updated" version of a DLL.
> SxS is a legitimate Windows feature that is used by many applications to prevent problems that arise due to updated and duplicate versions of DDLs.
> The best way to identify these attacks is to identify an exe file with new DLLs accoumpanying it.
218
DLL Hijacking: mitigations
> There are very few mitigations against this kind of attack. "DLL rules" can be applied via AppLocker/Device Guard to limit from where DLLs can be loaded. But this is only viable for very locked down systems.
219
Relative path DLL hijacking
> Here you just copy a file from the Windows or System32 folder to a new directory. You then add the DLL files and execute the .exe. Write permissions are required for the Windows and System32 folders.
> To identify this attack, you would typically see a system executable running from a strange location. These DLLs will also be unsigned.
220
DLL Hijacking: Types/Overview
> DLL Search Order Hijacks
> Phantom DLL Hijacking
> DLL Side-Loading
> Relative Path DLL Hijacking
> DLL Hijacking: Forensics
221
Forwarded functions (see DLL Hijacking)
> In DLL hijacking attacks, threat actors still need to proxy the legitimate function of a malicious DLL to the legit DLL. As such, it is weird to see two identically named DLL's forwarding functions to each other. This can be indicative of DLL Hijacking.
222
DLL hijacking: forensics
> Nearly all DLL hijacks require placing a new DLL or exe onto the file system. This is valuable, as most DLLs are old. So look for a legit .exe associated with a strange DLL in the same location.
> In memory, you can also look for code running from strange locations, by looking for processes that should not be running, or those loading DLLs from strnage locations. DLLs in C:\ProgramData is weird for example.
> Note the most common DLLs are already running in memory, so the hijacked ones tend to be more obscure.
> Hijacked DLLs will also perform strange functions, such as reaching out over a network, creating named pipes, or injecting code into other processes.
223
MOF file
> Contains details of WMI Event Filter, Event Consumer, and binding.
224
Persistence: WMI Event Consumer
> WMI provides the ability to monitor for specic events and when triggered, alert event consumers that can then do things like run scipts and execute code.
> Admin privileges are necessary to configure WMI Event Consumers. WMI consumers run with SYSTEM privileges.
>WMI persistence steps: 1) event filter created describing trigger (trigger condition) 2) event consumer added with a script or executable 3) event and consumer are tied together via a bindings and the persistence mechanism is loaded.
> These steps are often written inside a managed object format (MOF) file which is installed using mofcomp.exe. To be more stealthy, attackers often usePowerShell and Set-WmiInstance or CreateInstance.
> Event filters: immediately on registration, specific times, existence of file or folder, services starting or stopping, a specific user authenticated, etc.
> Get-WmiObject used to identify malicious WMI. Commands are on the right.
> Pro-tip: Filter for event consumers including powershell.exe.
> Two most common event consumers: CommandlineEvent consumers (allows filtering for executabled) and ActiveScript event consumers (allows for basic scripts).
225
Persistence
> Scheduled Tasks
> Dll Hijacking
> WMI Event Consumers
> Autostart locations
> Service creation and service failure recovery
> Local group policy, MS Office add-in, BIOS Flashing
> More than 80% are Autoruns and Service creation.
226
CommandLineEventConsumers
A type of WMI event consumer (see Persistence WMI Event Consumer). Allows the payload of an event filter (trigger) to be an executable.
227
ActiveScriptEventConsumers
A type of WMI event consumer (see Persistence WMI Event consumer). Uses a path to a script on disk or simple script text. Visual Basic or Jscript are the two supported scripting languages for these types fo consumers. You will not see powershell scripts in these types of consumers.
228
Kansa
> Kansa uses PowerShell remoting to run user-contributed modules across hosts in an enterprise to collect data.
> Kansa can query domain controllers to build lists of hosts.
> Error handling written to a cnetral file.
> Can run on 32 systems at a time.
> Output written to a user specified file.
> A module.conf file is used to tell the tool what modules to run and in what order. This is stored in the modules folder. Collections of volatile network, memory, and prefetch data should be targeted first by moving the module to the top of the list.
> Two prerequisites: 1) WinRM enabled 2) local admin on the remote host required.
> .\Modules folder contains plugins, .\Analysis folder contains PowerShell scripts for carrying out basic analysis (many rely on logparser.exe).
> Will not collect and identify rootkits, as it uses Windows API to collect data.
229
module.conf
> Configuration file used by Kansa to prioritise module collections.
> Contains the name and relative location of each script to be run.
> # used to comment a module out of the .conf file.
> Prefetch, DNScache, and ARP info is highly volatile so should be collected first.
230
Living off the land (windows commands)
> Use of legitimate Windows binaries to carry out malicious activity
> LOLBASE (Living off the land binaries and scripts): Project collecting LOL techniques.
> Common examples: Bitsadminexe and certutil.exe (file download), rundll32.exe (execute code in DLLs),
231
PowerShell
> A scripting language and an interactive command interface
> Based on .NET framework objects, which means the objects carry multiple aspects or properties of the command.
> Provides access to WMI.
232
Pushbin argument
> Used to push a third-party tool to a remote system using Kansa.
> Needs a Directive in front of the binary. For example, # BINDEP .\Modules\bin\Autorunsc.exe
233
EDR & memory
> EDR can be used for both detection and incident response allowing IR teams to go back in time to hunt for evil.
> EDR tools have the capability to carry out analysis and event tracing in memory, as they have kernel-level access.
> This includes: process usage, Windows API usage, archived command line data, tracking new process handles and execution tracing, analysing suspicious thread creation and memory allocation, identifying common DLL injection and rootkit hooking techniques, host-based network activity such as DNS cache, sockets, ARP.
> Important to note that EDR tools only collect about 30 events a minute, which is very very limited compared to all events happening on a host.
> Summary: EDR is good at identifying real-time actions, but it is not a replacement for traditinal forensic tools, as these tell a deeper story.
234
Memory & EDR
See EDR & memory
235
Memory acquisition
> Capture Raw Memory + Page File.
> Acquisition tools loads a system driver to gain raw access to memory and then dumps the entire contents of memory into a raw file (note this may trigger AV protections)
> In 64-bit Windows OS, all loaded device drivers must be digitally signed.
> Regardless of the tool used to dump the memory, any tool will be able to analyse it. WinPMEM is a favorite, as it supports both 32 and 64-bit architecture.
> Although RAM can be dumped from a live system, you can find copies of RAM.
> Kernel-mode dump files (crash dump files) can store memory dumps, although they are rarely complete (look for MEMORY.DMP in the SystemRoot folder in C:\Windows. Also look in SYSTEM\CurrentControlSet\Control\CrashControl
> hiberfil.sys is created when a system transitions to sleep mode and contains a complete copy.
> pagefile.sys and swapfile.sys. Contains working set of memory for suspended modern applications that have been swapped to disk. Pagefile found at SYSTEM\CurrentControlSet\Control\Session Manager\Memory Mangement.
> Taking memory dumps from servers requires loaded drivers to be signed by Windows Hardware Quality Labs (WHQL).
> Virtual machines: VMware .vmem, .vmss, and .vmsn files store full memory images for VMs.
236
WinPMEM
> Memory collection tool that supports 32 and 64 bit architecture.
237
hiberfil.sys
> File created when a system transitions from sleep mode into power save mode. Typically when lid closes.
> Located in the root of the system drive (typically C:).
> Means you have two images to analyse: one live and one hibernation file.
> They are compressed, so you need memory analysis tools to read them: imagecopy from Vol or Hibernation Recon from Arsenal.
> Data is zeroed when machine is restarted (post Win8+). However, hiberfil.sys is impacted by "Power States" like "Modern Standby", "Hybrid Sleep", and "Fast Startup". This has increased prevalance of Hiberfil in modern Windows OS.
238
crash dump file
> Look for MEMORY.DMP files in the SystemRoote folder. Complete memory dumps are rare.
239
pagefile.sys
> Not a complete copy of RAM. Found at SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management.
240
swapfile.sys
> Holds working set of memory for suspended Modern applications. Not a complete copy of RAM.
241
Windows Hardware Quality Labs
> All loaded drivers used for memory collection must be digitally signed by Windows Hardware Quality Labs.
242
Memory acquisition (challenges)
> Data is a snapshot, things change quickly.
> Because you are dealing with more than just files and folders, establishing context is difficult.
> The data is not in an easily extracted format.
> Acquiring the data changes the data.
243
Kernel Debugger Datablock (KDBG)
> The data structure whose pointers can be followed to find the process list for the system.
> Can be found using two different methods: Find the Kernel Processor Control Region (KPCR), which has a pointer or using well known signatures.
> This then leads to the PsActiveProcessHead pointer, which leads to the EPROCESS block.
> Encrypted in newer Windows builds, so need to use KdCopyDataBlock to derive decryption key.
244
Kernel Processor Control Region (KPCR)
> See Kernel Debugger Datablock (KDBG)
245
Kernel modules
> Code used to extend the functionality of a system.
> Device drivers are the most common.
246
Memory structures
> Executive Process (EPROCESS) blocks
> Process Environemnt Blocks (PEB): Loaded DLLs
> Virtual Address Descriptors (VAD) Tree: Memory sections belonging to a process.
> Kernel modules: drivers.
247
Smallest unit of execution
> Thread
248
Volatility 2 vs Volatility 3
> New API and better developer tools
> Prioritises performance, which is imprtant for large memory images.
> Scalable to multiple memory images
> Better support for WoW64 analysis
> Code emulation
> Vol 3 missing key legacy plugins.
249
Microsoft Build number (profile for Vol 2)
> Required for Volatility 2 to locate Symbol table. Build is put into Profile option in command line.
> Can find in About Your PC.
> Can also find using kdbgscan, which searches the memory image for matches of known KDBGHeader signatures. Note the KDBG structure is encrypted in newer Windows OS, so KdCopyDataBlock must be used.
> This is not an issue in Vol 3, as it has functionality to perform symbol table look ups. However, this does mean that you need internet access.
> A symbol table is a data structure that provides a template for how memory objects are defined and where important information resides to better understand source code.
> You can also guess the Build number and run Volatility plugins. If pslist, psscan give bogus process names and no processes, you know you're wrong.
250
Symbol table (memory/volatility profile)
> A symbol table is a data structure that provides a template for how memory objects are defined and where important information resides to better understand source code, including the KDBG. This information changes as Windows releases major system updates.
> Volatility 3 automatically scans for these tables.
> This information is key when trying to find the build number -- the KDBG -- and ultimately process blocks.
251
KdCopyDataBlock
> Because the KDBG structure is encrypted in newer Windows builds, in order to find the decryption key you need to search for this function.
252
KDBGHeader (build profile)
> KDBGHeader signatures are used to determine the Windows OS for different systems, allowing analysts to identify the correct build number and in turn, allowing them to identify where memory objects are stored.
253
kdbgscan
> Volatility plugin used to scan for KDBGHeaders to inform correct build profile to use when analysing a memory image. Note that it can return multiple profiles, so need to test using multiple plugins.
254
Malware detection methods
> Signature, contradiction, and heurisitc/behavioural
255
Process block (EPROCESS block)
> Processes are like files in a file system. They tell us what was running on a system.
> Some are allocated (currently in use) and some are unallocated (waiting to be overwritten).
> Process images are tracked in Executive Process Blocks (EPROCESS blocks). Although note that the images only contain the first 14 bytes of the name.
> The Kernel uses a double-linked list to track processes. Only allocated processes are captured here. When a process exits it is unlinked and discarded.
> If there are zero threads or an exited timestamp, then a process is exited.
> Sometimes threads are running but a process is exited. Causes a situation where exited process is flagged as running.
> See 3.28 for list of metadata captured in EPROCESS block.
> Volatility plugins that walk the double link list include list in their name. Those that link services together on the list include scan.
> See Rouge process identification
256
EPROCESS block
> See Process block
257
Rouge process identification
> Suspicious names
> Suspicious paths (Temp directory
> Suspicious parent processes (those with services.exe should be spawned at boot where as explorer.exe spawned after logon).
> Suspicious command line: For example, the Process Environment Block (PEB) tracks the full command line used to run a .exe. You can check whether the executable matches its image name.
> Suspicious start time: Was a system process started on user logon. Weird.
> Security identifiers: Was a system process started by a user?
258
PsList
> This plugin works by finding the EPROCESS list in the Kernel, following the double linked list, and parsing information about each process. Provides the binary name (ImageFileName), parent process (PPID) and time started (CreateTime).
> Rootkits can unlink malicious processes from the linked list, rendering them invisible to this tool.
259
PsScan
> Scanning plugins do not follow the normal set of procedures to identify objects, such as following the double linked list. Rather, they scan all of memory looking for markers of specific objects (process blocks), similar to performing a data carve on disk.
> Has the ability to identify terminated processes within the "unallocated" part of memory, as well as find processes hiding due to kernel manipulations seen with rootkit techniques.
> Much slower than PsList.
> If ExitTime field is populated, it indicates you are looking at a terminated process. However, this field isnt reliable, so look for processes with zero threads or handles. Note that there are some processes in the EPROCESS list with threads that have been exited.
260
PsTree
> Volatility pluging that reads the EPROCESS doubly linked list in the kernel and outputs the results as a process tree.
> Only has the capability to visualise active processes, unless terminated processes are still present in the EPROCESS list.
261
Orphan process
> An ophan process is a child process without a parent. It is rare that a parent process would exit before its child processes are complete.
> Malware loaders will often exit after they have deployed their payloads, which will still be running as a child process. It is also seen during code injection, where a process is created to inject code into a child.
> Look for entries with only one * in pstree.
262
Persistence and Lateral movement processes (memory threads/child processes)
> Code in Windows is executed as threads (ex: services.exe - svchost.exe - taskhostw.exe).
> Services are the most common ways code is executed in Windows, so you see many child processes for services.exe.
> Task: services.exe - svchost.exe - taskhostw.exe (C:Windows\system32\svchost.exe -k netsvcs -p -s Schedule). Note that Executables running as a scheduled task will show up under svchost.exe, not taskhostw.exe
> Registry Run Keys: explorer.exe (designed to run during user logon).
> PsExec: services.exe - psexesvc.exe (this is the sysinternals version and may not be the same for things like Cobalt Strike's psexec tool).
> WMI: services.exe - svchost.exe - wmiprvse.exe - powershell.exe - conhost.exe (command line event consumer), wmiprvse.exe - powershell.exe - scrcons.exe (activescript event consumer). Look for spawning cmd.exe.
> PowerShell: wsmprovhost.exe indicates remote use while powershell.exe indicates local use (explorer.exe will be parent in local case or svchost.exe if admin account was used). If powershell.exe is spawning from a Microsoft winword.exe, could indicate Macro abuse.
263
Memory Baseliner
> Tool that can baseline a single memory image or an entire collection of images via a process called "stacking".
> Can perform baseline comparisons for four types of objects in memory: processes and associated DLLs (-proc), drivers (-prv), and Windows services (-svc).
> Provide a baseline image using -b parameter and suspect image using -i argument. --showknown argument shows objects in both baseline and memory image (KNOWN + UNKNOWN).
> Import hashes are calculated for drivers present in memory and are calculated using the names and order of API functions imported by the driver. It is a reliable way to identify different EXE/DLL driver variants or a malicious driver trying to blend in. If an entry does not have an imphash, it indicates the tool was not able to extract a complete copy of the file, often caused by paging. An imphash can be used for stricter matching using the --imphash option.
> KNOWN indicates the item was present in the baseline. IMAGE/BASELINE Fo O is frequency of occurance.
> Least frequency of occurance is particularly helpful when stacking multiple images, as malware shows up pretty clearly when looking at non compromised systems.
> To stack use the -d [image folder] to run tool against directory of images.
> When analysing, pay attention to drivers outside of the normal directories: Windows\System32\Drivers and Window\System32.
264
Process Objects
> There can be thousands of Memory objects. Use the --pid argument to narrow down and look for process command lines, DLL file paths, account SID, and handles where necessary.
>Project Objects: DLLs, Handles (file handles, directory handles, registry handles, mutex or semaphore handles, event handles, named pipes), threads, memory sections, sockets.
> This is the run below the EPROCESS block in memory that describes objects requires by a process.
265
Dynamically Linked Libraries (DLLs)
> Define the capabilities of a process. For example, if a process needs to communicate via HTTP, it will load the wininet.dll case.
266
Handles
> A pointer to a resource or a connection between a process and an object. They include:
> File handles: Which items in the file system or which I/O devices are being accessed by a process. These are most helpful for investigators.
> Directory handles: Directory handles are known lists within the kernel that allow the process to find kernel objects such as KnownDLLs, BaseNamedObjects, Callbacks, Device, and Drivers.
> Registry handles: registry keys the process is reading or writing to.
> Mutex or Semaphore handles: Called "mutants", these objects control or limit access to a resource.
> Event handles: A way for process threads to communicate.
> Named pipes: See Named pipes.
> Handles are not a good place to start for analysis. There are also numerous unnamed handles.
267
Threads
> A thread is the smallest unit of execution in memory. It is a sequence of intrusctions within a process that can be executed indpeendently by a computers processor (CPU).
> Threads with the same process share the memory of a process, such as the pogram's code, data, heap. Each thread has its own private stack to store local variables, functino call information and execution state. This keeps a thread specific path seperate.
> Threads also handle inter-process communication, such as when conhost.exe is spawned from cmd.exe, which is spawned from explorer.exe. n this context, threads allocate memory and resources for cmd.exe when its started from explorer.exe. Threads listen for users clicking Run for cmd.exe, threads process commandd line inputs, etc, etc.
268
Page files (memory section)
> Every process has a collection of virtual memory pages where DLLs and files are loaded and code and data stored. The Virtual Address Descriptor tree (VAD) maintains a list of these assigned memory sections.
> A memory page is a fixed size (typically 4KB), so multiple pages will be assigned for processes and objects.
> Page table entries track the location of pages (are they in virtual or physica memory; are they in physical RAM or on disk) and their protection status.
> When not in use, these page files are paged to disk and stored in the pagefile.sys file.
> Without context, the pagefile.sys file - which sits on disk - is largely a collection of random data that once existed in RAM. Thus, strings searching can be the most helpful tool here.
> As such, including this file as part of MemProcFS or Volatility 3 usage can generate more useful data (it doesn't work in Volatility 2).
> The benefits include: better file extraction, better injected code recovery, better scanning of memory objects (network connections and registry data), and better scanning of page hiding techniques. You see less extraction errors for processes, DLLs and drivers. The odds of detecting and getting good copies of malware improve as more memory locations are available for scanning and recovery.
> This data is housed in both the pagefile.sys and swapfile.sys.
> Include -pagefile0 pagefile.sys at end of MemProcFS command line. Include --single-swap-locations=pagefile.sys at the end of Volatility 3 comand lines.
269
Sockets
> These are network connection endpoints. Every network socket is assigned to a specific process allowing us to trace back suspicious network activity.
270
Virtual Address Descriptor (VAD) tree
> A VAD is a data structure used by OS to track which part of a process's virtual memory space are allocated, their sizes, and their permissions. It is a high level overview showing which virtual pages belong to which objects.
> Contains a list of virtual memory pages for a process. These pages describe the collection of DLLs and files that are loaded in Heaps and Stacks, as well as code that is needed (memory objects).
> Does not map to physical memory. Solely used to manage virtual memory.
> Most important values in VAD: Location of memory object in memory, path to executable on disk, permissions (origional), and VAD Type (private shareable image).
> The process VAD tree is located in the Kernel, making it much more difficult to manipulate than the Process Environment Block, which is located in the user-accessible (userland) part of process memory. You need a rootkit to change permissions in the Kernel. However, Direct Kernel Object Manipulation (DKOM) attacks have been proposed to unlink and hid memory locations tracked by the VAD.
> The VAD tree also tracks page permissions and has the unique property of only storing the origional page permissions. This makes it perfect for comparisons against the Process Environment Block.
271
DllList
> The Process Environment Block (PEB) tracks DLLs loaded for each process. It also stores the command line (plus parameters) required to launch a process. Although this needs to be extracted using windows.cmdline Volatility plugin.
> Note that this will miss reflective DLL injection, as the PEB only captures DLLs loaded via the Windows API. It also misses 32-bit (WoW64) processes (use ldrmodules or malfind for these). You need to use ldrmodules to capture this information, as it compares the PEB with information pulled from the VAD list. ldrmodules will also include the full MappedPath and memory base address.
> Note that you need the PEB for the full process image name, as the EPROCESS block only lists the first 14 bytes.
> Two important options for DllList: --pid is used to limit process objects to a specific process; --dump option used to extract DLLs for individual analysis. --single-swaplocations can take a pagefile.sys file as input.
> The base address provided is the memory location within the process address space and is not a virtual or physical memory address.
> the LoadTime indicates when the DLL was loaded into the process, which can be valuable when identifying DLLs added to a process after runtime.
272
Process Environment Block (PEB)
> The Process Environment Block (PEB) tracks DLLs loaded for each process. It also stores the command line (plus parameters) required to launch a process. Although this needs to be extracted using windows.cmdline Volatility plugin.
> The PEB contains three double linked lists traking DLLs. InLoadOrderModule List, InInitializationOrderModule List, InMemoryOrderModule List. In most cases, these all contain the same data.
> It is commonly targeted, as it is stored in the user accessible part of process memory (userland) making it easy to modify (assuming you already have the required Administrator privileges to inject code). Ie. You dont need a rootkit.
> Memory locations can be unlinked from the list to hide them from Task Manager or PowerShell commands. Alternatively, some malware will attempt to add itself to the list to pretend like they have been loaded via the Windows API.
> Note that this will miss reflective DLL injection, as the PEB only captures DLLs loaded via the Windows API. It also misses 32-bit (WoW64) processes (use ldrmodules or malfind for these). In these cases, you need to consult the VAD tree, which also tracks memory pages and loaded DLLs.
> Note that you need the PEB for the full process image name, as the EPROCESS block only lists the first 14 bytes.
> Use DllList or ldrmodules to analyse relationship between PEB, VAD, and PTE which provide the three views of every process entry.
273
cmdline
> Volatility tool to extract command line information from the Process Environment Block (PEB) for each process.
> Hunt for strange executable names, unusual execution folders, incorrect arugments on well known executables.
> For example, look for abnormal command lines associated with svchostexe.
> HuntEvil poster can be a big help here.
> Because you are looking at the PEB, information from exited processes is not available. While you can use psscan to grab some data, you wont find the full path of the process, as this is resident in the PEB.
274
Sacrificial Process
> They work by spawning child processes to run dangerous code. Even though the parent process is killed, the child process is able to run.
> This makes it easy to run 32-bit of 64-bit payloads, provides an easy and safe place to inject code, makes passing code to other processes or systems easy, and facilitates cleanup since the attack can be segmented and processes killed as they complete.
> It is easy to spot, as you will see lots of the same process loading (rundll.exe, svchost.exe, etc) under PowerShell or WmiPrvSE and only last several seconds.
> For example, rundll.exe is used to load DLLs. If there are no process arguments in windows.cmdline Volatility output, that is weird as rundll.exe is specificall used to load DLLs, so you should see them there.
> Cobalt Strike regulalry uses rundll.exe as a sacrificial process. Run dll with also connect to the internet. But this is easy to change to something like svchost.exe.
> Use windows.cmdline to analyse the sacrificial process.
275
GetSids
> A token is a collection of security identifiers (SIDs) that describe user permissions and user groups.
> Most system processes use well-known system accounts and security identifirs to perform their tasks.
> For example, lsass.exe uses Local System, Administrators, Everyone, Authenticated Users, and System Mandatory Level.
> The first SID in the list is the primary token, with the remaining token being group membership.
> User SIDs are assigned to processes that start under a user context, which would never be the case for core system processes like lsass.exe.
> Every process executed on behalf of an authenticated user uses the same token for a session.
> windows.GetSIDs volatility plugin attempts to query in-memory registry hives to match account SIDs to their account names. If this fails, the analyst can just query the SAM of SOFTWARE registry hives.
> GetSIDs also identifies the SID used to run processes.
> Note that the SID for the local admin account is 544 and the domain admin account is 512.
> Note that running the whoami /all command from a command promt gives the logged in users SIDs, groups, and privileges.
276
Token (memory: process token)
> A token is a collection of security identifiers (SIDs) that describe user permissions and user groups.
> Tokens contain the user account SID, SIDs for every group that the user is a member, and a list of privileges and ACLs related to the user account.
> Most system processes use well-known system accounts and security identifirs to perform their tasks.
> For example, lsass.exe uses Local System, Administrators, Everyone, Authenticated Users, and System Mandatory Level.
> The first SID in the list is the primary token, with the remaining token being group membership.
> User SIDs are assigned to processes that start under a user context, which would never be the case for core system processes like lsass.exe.
> Every process executed on behalf of an authenticated user uses the same token for a session.
> See Security Identifiers (SID) index entry
277
Security Identifiers (SID)
> Security identifiers (SIDs) are unique identifiers assigned to objects by Windows systems and DCs using a token.
> SIDs will be unique within a Windows instance and domain SIDs will be unique throughout the enterprise.
> Each running process is assigned an access token that contains the user account SID, SIDs for every group that the user is a member (including the primary group), and a list of privileges and ACLs related to the user account (see token: memory).
> Most importantly, the SID tells you what user account spawned a process.
> The three most popular sides used for Processes are LocalSystem, LocalService, and Network Service.
> S: The string that follows is a SID
> 1: Revision level
> 5: Identifier Authority (NT Authority), which is most comon. World Authority (1) and Creator Authority (3).
> Followed by unique domain identifier (long string unique to the domain) and Relative identifier (RID)(short string unique to the user).
> SID + RID is the value used by Windows to reference a particular accoutn.
278
Relative Identifier (RID)
See Security Identifiers (SID)
279
Handles (Volatility plugin)
> This will print a list of handles opened by all processes. As such, it is important to use the --pid argument to narrow down the output to a specific process.
> Output to a CSV using the -r csv argument is helpful.
> File and registry handles are useful and a good place to start, as it is not unusual to find a pointer to a file the process is reading or writing to. It can be weird to see a DLL file here, as these are typically stored in the PEB, which is viewed via dlllist.
> Mutants and named pipes can also be helpful to audit.
280
Named pipes
> Named pipes are a handle that provide communication functionality between processes on computers (IPC: interprocess communication). They provide a similar functionality to opening a network socket and communicating over SMB with less overhead and less chance of someone noticing something wrong while running "netstat".
> Named pipes are named variably, but some tools use similar naming:
> PsExec: \Device\NamedPipe\psexecsvc---stdout
> Cobalt Strike: MSSE-####-server, msagent_##, status_##, postex_ssh_####, \\.\pipe\######(7-10 random characters), postex_####
> Named pipes can be found by filtering on the "File" output of the "handles" volatility plugin.
281
Mutants
> Mutants are a type of handle also called "mutexes" . They are a memory object that controls or limit access to memory resources.
> For example, they can enforce a rule starting that only one process can access an object (driver/file/etc).
> Malware use mutants to mark compromised systems to prevent a reinfection. These are also called kill switches.
> When running the handles Volatility plug-in, look for the Mutant file Type and the name of the Mutant, which can be cross-referenced against threat intel.
> It is best to use mutants after finding malware, as they can be used to query for malware across an environment.
282
Network artifacts (memory)
Things to look for when analysing network connections:
1) Suspicious ports: what ports are active (is the process owning the SMB port different than System, which is default).
2) Suspicious connections:Directionality is key (foreign ports low, local ports high: System - high to high). Do you see reserved or well known ports, which usually indicates inbound connections. Focus on both UDP and TCP. Do you see a system process like svchost.exe communicating with an HTTP port 80? That would be weird. DNS tunneling over port 53 is common. Focus on creation time of network ports.
3) Suspicious process: Should a process even connect to a network at all? You may be able to recover old network sockets out of memory even if they are old.
283
netstat (Volatility 3)(Link-list based)
> Volatility 3 plugin that finds the tcpip.sys driver in memory and parses the structures present in its UdpCompartmentSet, TcpCompartmentSet, and TCP Endpoint partition table list. This gives information into network activity present when the image was acquired.
> Volatility 2 uses the "Connections" plug in to retrieve this data. It also finds the tcip.sys driver and walks the TCP connections single-linked list.
284
netscan (Volatility 3)(scanning of memory)
> Volatility 3 plugin. Instead of finding and parsing memory structures (like netstat), this Volatility plugin carves data from non-paged pool memory, looking for signatures for well known network objects.
> For example, it looks for TcpE for a TCP endpoint, TcpL for a TCP listener, and UdpA for a UDP endpoint.
> This provides more information than netstat, including old network objects and structures purposefully unlinked by malware trying to hide. The ability to find old network connections is a powerful tool.
> Netscan can be used in Volatility 2 for all systems post Windows XP. In Volatility 2, this plugin combines both socket and TCP connection data.
> For pre-Windows XP systems, connscan plugin must be used in Volatility 2. This is very similar to netscan, but the socketsand sockscan plugins must be used to enumerate network sockets. The first walks the sockets single-linked list and the second scans memory.
285
connections plugin (Volatility 2)
> See netstat (Volatility 3)
286
connscan plugin (Volatility 2)
> See netscan (Volatility 3)
287
sockets and sockscan plugin (Volatility 2)
> See netscan (Volatility 3)
288
UdpCompartmentSet
> See netstat (Volatility 3)
289
TcpCompartmentSet
> See netstat (Volatility 3)
290
TCP Enpoint partition table
> See netstat (Volatility 3)
291
tcpip.sys driver
> See netstat (Volatility 3)
292
MemProcFS (Intro)
> Memory images are mounted as a virtual file system.
> Auto-profile detection using Microsoft dynamic symbols table lookups (for best results use with internet access).
> Can decompress compresses memory sections in Windows 10 and 11 and supports pagefile reading.
> Folders are used to collect artifacts of specific types and each artifact is represented as a file.
> Mount point defaults to M:but can be changed with "-mount". This is required when using Linux.
> You can then use whatever tool you want to analyse: YARA, grep, or string selection.
> findeveil, ntfs, timeline are key plugins.
293
MemProcFS Processes
> PID: M:\PID
> Name: M:\name
> Process Tree: M:\sys\proc\proc.txt (similar to PsTree)
> CSV: M:\forensic\csv\process.csv
> See Tools/MemProcFS/Processes
294
MemProcFS Objects
> Found under M:\name
> win-cmdline.txt: full process command line from the PEB
> token folder: What SIDS (account context) the process ran with.
> handles folder: list of process handles
> modules folder: information on loaded DLLs and the image binary (.exe file). You can also view the pefile.dll file, which attempts to piece together the origional DLL file from memory.
> findevil: Code injection
> memmap: VAD Tree
295
MemProcFS Network Artifacts
> Found under M:\sys\net
> netstat.txt provides traditional view of network activity.
> netstat-v.txt adds full path information for processes.
> CSV: M:\forensic\csv\net.csv
296
Code Injection
> Instead of starting a new process, malware can have an existing legitimate process run the evil code for it.
> This has multiple benefits:
1) allows the malicious code to inherit access to that process's memory sections and permissions.
2) is camoflage
3) Allows malcious code to migrate from say a browser to a more persistent process, such as svchost.exe
4) Is better at evading AV and application controls
5) Relied on by rootkits.
> Two primary kinds of code injection: DLL injection and process hollowing (see DLL Injection and Process Hollowing index)
> Note: All code injection leave behind code in memory pages marked as "executable".
297
Process hollowing
> A legitimate system process is created but in a suspended (not running state). This means the process image EXE is not backed with a file on disk.
> The origional executable is deallocated (unmapped) and the start address is changed to point to a different location hosting malicious code.
> In short, the DLL is present in the PEB but there is no mappedpath in the VAD (no map to disk). This is contrary to code injection, where there is no mappedpath and no evidence of the DLL in the PEB.
> The process is then started, executing the malicious code. However, the image name, path, and command lines remain unchanged. In this way, an attacker can retain DLLs, handles, data, from the origional process.
> This is easy to spot in ldrmodules Volatility plugin. Look for DLLs that are present in the PEB but have no MappedPath.
> For example, lsass.exe can be unmapped so that new code could take its place. This would show up as True in the InLoad and InMem lists with no mappedpath in ldrmodules. Beause this takes place in memory, there is no corresponding file on disk representing the new contents of the process executable.
298
Code injection detection
> All injected processes must get malicious code running. As such, all forms of injection start from memory pages with "executable" privileges, such as image mapped memory and manipulated private memory.
> DLLs introduced using Windows loader (API): To detect, review unusual process objects like loaded DLLs and file handles using Volatility/MemProc plugins (DllList, ldrmodules, or Object plugins: cmdline, handles, SIDs, etc.).
> For example, analyse ldrmodules output for strange mapped paths, including Temp (not System32 or ProgramData).
> Unusual executable memory locations: Some code injection attacks bypass the Windows loader (API)(reflective injection). However, they will still leave behind IOCs. For example, in memory pages marked as executable. So you can use malfind to look for code not loaded via legitimate API calls and search memory for executable pages containing code. See reflective injection and malfind
> If a DLL is not present in any of the three PEB lists and not mapped to disk, this is a sign of reflective code injection and should prompt you to analyse malfind output for evidence of code in the pages marked as executable.
> Kernel and userland process inconsistencies: To manipulate memory locations to not look unusual, attackers change memory page permissions after initial allocation, change pointers to execute different code (process hollowing), patch (change) previously loaded code. So you should hunt for these.
> Tools (Volatility): ldrmodules to hunt for unusual memory locations and unlinked DLLs. Malfind for signature detections for reflective injection and hollowing. Hollowfind and threadmap are Volatility 2 only tools. The first compares information in the PEB to the VAD and the second uses threads, which are harder to manipulate.
> Tools (MemProc): findevil
> Tools (Live analysis): Moneta is a usermode memory scanner hunting for process injection and Hollows Hunter is a usermode scanner using pe-sieve implant detection.
299
Process hollowing detection
> See process hollowing
300
DLL injection detection
> See code injection detection
301
DLL load-order hijacking (code injection)
302
Side-loading (code injection)
303
Reflective injection
> Definition: A form of code injection in which an attacker is able to run code in a remote process without using the Windows API Loader (LoadLibrary). By excluding LoadLibrary, the code is not registered in any of the standard in-memory lists (PEB lists) and is thus hidden from many security auditing tools (DllList).
> Because an attacker doesn't need to load code from disk (Windows API loader requires the code to be on disk), the attacker can use memory-only code, including code downloaded from the internet. This reduces the scannable footprint available to security tooling.
> Metasploit and Cobalt strike are known to use reflective attacks for their Beacon backdoors. The PowerSploit and Empire PowerShell attack frameworks also implemented reflective injection as a primary attack vector.
> Hunting: (see malfind index entry)
> Memory section with "execute" permissions: To hunt for evidence of reflective injection, first hunt for memory sections with a protection (permissions) value of "page_Execute_ReadWrite". This permission means an attacker can both write and execute code from the memory section.
> Memory section not backed by on-disk file: You can also hunt for whether a DLL is loaded from disk. It will show up in the VAD and not the PEB if so. Look for non-disk locations in the MappedPath not System32, ProgramData, WinSxS.
> Memory section contains code: A memory section should not be marked as executable if there is no code there. So the next check is t hunt fgor Portable Executable or shellcode headers ("MZ").
304
Hooking
> See Rootkit hooking entry
305
Rootkits (Hooking)(Overview)
> Used for hooking and unlinking. A much less common attack, but one that is difficult to spot, as OS employs numerous hooks during BAU activity.
> A simple way to think about hooking is a code detour. A malicious process or driver redirects the logical code flow in order to manipulate user input or output.
> Userland: The simplist rootkits exist in userland, where users and applications interact. One example includes the redirection (or hooking) of import address table (IAT) pointers of running processes and directly patching (manipulating) loaded code in memory to redirect execution paths. While these attacks are less likely to crash the system, they are easy to detect using AV software.
> Kernel: Kernel rootkits can subvert everything running within the operating system. Modification of critical system tables like the IDT, SSDT, and IRP can redirect execution of kernel level functions and DKOM attacks can unlink objects from legitimate lists. PatchGuard and Driver Signature Enforcement have limited these attacks. Bring Your Own Vulnerable Driver is the most popular rootkit and is used to bypass Driver Signature Enforcement that mandates all software in the Kernel is signed.
> Bootkits: These attacks are run in a malicious hypervisor. However, TPM and secure boot technologies prevent many of these attacks.
> Firmware & Hardware: These are the most recent types of rootkits. They are rare, system dependent, and lean on more traditional rootkit techniques like driver loading to setup the final version.
306
ldrmodules
> Volatility plugin to detect unusual memory locations and unlinked DLLs, both common occurences with more advanced malware.
> While similar to DllList, ldrmodules pulls information from both the PEB (InLoad, InInit, and InMem lists) and VAD (mappedpath and base address). This includes information in the process DLL linked lists (PEB) and all image mapped memory executable areas in the VAD tree.
> If all PEB lists are True, it generally means a Windows API was used to load the DLL. There will also be a mapped location on disk, as all Windows API functions must reside on disk. If you don't see a mapped path, then the DLL was likely not loaded from disk. Similarly, if you see a mappedpath and False in the three lists, then this would mean the DLL is not present in the PEB. These are signs of DLL injection.
> When threat hunting, look for DLLs that are not present in any of the three PEB lists, as well as DLLs that arent in the System32, ProgramFiles, or WinSxS folders. For example, look for files in Temp folders.
> Note, the process image binary (the .exe) wil never appear in the InInitializedOrder InInit list column, as these are no initialized in the same way as DLLs.
> Common false positives: some special files are mapped into memory (VAD) but are not DDLs/EXE including .fon, .mui, .winmd, and .msstyles. They are not represented in the PEB as they are not loaded DLLs. Additionally, some legitimate mapped DLLs may have been unloaded or not yet used (loaded), so will not show up in the PEB.
307
malfind
> Definition: Malfind is a Volatility scanner looking for signatures of reflective injection (non Windows API code injection) and process hollowing (code injection). These include, unusual memory sections (such as those in private memory with executable permissions, those not mapped to VAD, and those containing code), irregular processes (such as those not in the EPROCESS list, those with unexepcted parents, and unexpected users), and memory sections that have been manipulated (such as PEB modification, code in a VAD tree memory section that isnt in PEB, and image pages that have been patched).
> The fact that a file is not mapped to disk is implicit in malfind output, so is not identified directly on screen.
> Malfind uses the PEB, VAD, and PTE (ground truth) and compares memory pages across the three.
> The tool does display the first 64 bytes of the memory section in hex and assembly code, making it easy to identify the "MZ" header for a Portable Executable or whether data appears to be shellcode (x64 or x86 assembly).
>PE Header: Use "| grep -B1 MZ" to hunt through the malfind output for entries with portable executable (PE) code present.
> x86 function prologue: When looking for assembly code, identify using the PUSH EBP; MOB EBP; ESP function prologue in malfind, which denotes the set up of a function in 32-bit assembly language.
>x64 function prologue: push rbp; push rbx; push rsi; push rdi; push r12; push r13; push r14; push r15. denotes the set up of a function in 64-bit processors or OS.
> False Positives: When there are lots of zeros in the hex of malfind output, it is generally a false positive.
> Evasion: To bypass malfine, TAs can "pad" the hex input to make sure malfind doesnt show it, as well as clear the PE header after loading. They can also alocate memory initially as READWRITE then change it later to EXECUTE_READ (the VAD tree only stores permissions when memory is allocated). Malware can also link and unlink from the PEB aquarade as a different process name and file path. TA's can also overwrite the contents of a legit DLL using patching or module stomping.
> Discovery (Advanced): To identify these more advanced forms of injection, use the --dump argument and then scan the output using strings, antivirus scans, IOC searches, and YARA scans.
> You can then dump these sections of memory using the --dump option.
308
hollowfind
> A Volatility2 (not in Volatility 3) plugin that compares information stored in the process environment block to the process's virtual address descriptor, which is a collection of memory objects for a particular process.
> Also looks for unusual memory section permissions similar to malfind.
309
threadmap
> A Volatility to only plugin that uses threads as a primary information source to hunt for memory object manipulations, primarily in a hunt for code injection.
310
ptemalfind
> Uses information from kernel-based page tables (SSDT) to identify "ground truth" of executable locations and permissions. Designed to hunt for process hollowing techniques.
311
Moneta
> A live memory scanner used to detect advanced code injection attacks using techniques like comparing processes in memory with the corresponding mapped files on disk and checking digital signatures.
312
HollowsHunter
> A live memory scanner used to detect advanced code injection attacks using techniques like comparing processes in memory with the corresponding mapped files on disk and checking digital signatures.
313
Page_Execute_ReadWrite
> Suspicious protection (permissions) value for a memory section. This is dangerous because both write and execute permissions are present. This means a threat actor can abuse the section to write and execute malicious code, bypassing the Windows API restrictions requiring DLLs to be present on disk.
314
Portable Executable header (PE Header)
> When running the malfind tool to check for reflective code injection, the tool will output the file header. If 4d 5a 90 00, then this is the MZ header for a portable executable indicating code is running.
315
x86 function prologue in assembly
> When analysing malfind output, in files not mapped to a file on disk with write/execute privileges, look for te PUSH EBP; MOV EBP; ESP function, which denotes the set up of a function in 32-bit assembly language. This is analgous to the portable executable (PE) header 45 5a 90 00 MZ.
316
x64 function prologue in assembly
> When analysing malfind output, in files not mapped to a file on disk with write/execute privileges, look for the x64 function prologue, which denotes the set up of a function - often shellcode - in 64-bit assembly language. This is: push rbp; push rbx; push rsi; push rdi; push r12; push r13; push r14; push r15. This is analgous to the portable executable (PE) header 45 5a 90 00 MZ. You can also look for the ASCII representation of the prologue: UVWATAUAVAWH.
317
ASCII function prologue
> When analysing malfind output, in files not mapped to a file on disk with write/execute privileges, look for the ASCII function prologue, which denotes the set up of a function - often shellcode - in ASCII assembly language. This is UVWATAUAVAWH. This is analgous to the portable executable (PE) header 45 5a 90 00 MZ.
318
Process memory:
> Process memory can be thought of a sections that contain code and sections that contain data owned by the process. It is composed of three primary categories:
> Private memory: Not mapped anywhere outside of the process. Typically includes application data, the process heap, and the process stack. Allocated with the VirtualAlloc Windows API function. Most memory pages in private memory have READWRITE privileges. You should not find EXECUTABLE privileges here or EXE or DLL files. If you do, it can be indicative of process hollowing.
> Shareable Memory: Also known as mapped memory, this part of process memory is designated for mapping all or part of shared files for use by the process.While data here can be shared, its not required. This is useful for inter-process communication or when multiple processes need to access the same data, such as a configuration file or a shared cache. Shared memory helps optimize system performance by avoiding redundant copies of data and reducing memory usage overall. Regularly contains .dat and .mui files. Most permissions for pages here are READONLY. Files mapped (loaded) from files on disk.
> Image Mapped Memory: When a program is executed, it exe file is mapped into memory as part of the process's address space. DLLs that ar used by the application are also loaded, and they can be shared among multiple processes. So Image Mapped Memory is intended for memory-mapped files and loaded DLLs, EXEs, and drivers. The permissions of pages here are regularly EXECUTE_WRITECOPY and EXECUTE_READ. But should never be EXECUTE_READWRITE. Files regularly mapped (loaded) from files on disk. While technically a shareable cateogry of memory, it takes on a different area. VAD Type: VAD ImageMap.
> Process memory: Houses the process environment block (PEB) and is easily manipulated.
> Kernel memory: Houses memory pools, the VAD tree, and page tables.
319
Kernel memory
> See process memory
320
Heap
> The heap is a region of process memory used for dynamic memory allocation where variables are allocated and freed in an arbitrary order, typically managed by the programmer or an automatic memory manager. It grows and shrinks at runtime as objects are created and destroyed, making it flexible but susceptible to fragmentation.
321
Stack
> The stack is a contiguous block of memory that stores function frames, local variables, and controls the execution order through a last-in-first-out (LIFO) method. It is automatically managed by the operating system as functions enter and exit, ensuring that each function call has its own stack space for execution, which simplifies memory management but limits flexibility compared to the heap.
322
findevil (MemProcFS)
> MemProcFS plugin used to analyse process memory for suspicious activity
> Not enabled by default and needs the -forensic plugin to function (" -forensic 1")
> A text report is generated in M:\forensic\findevil.txt
> Process irregularities include:
> PROC_NOLINK: A process that doesnt exist in the EPROCESS double linked list (process termination, or unlinked process).
> PROC_PARENT: Deviations from the commonly expected parents of system processes.
> PROC_USER: Processes named as system components running with the wrong account tokens.
> Memory page irregularities include:
> PE_INJECT: Memory section with a PE Header (MZ) not present in image mapped memory.
> NOIMAGE_RWX: Memory section with RWX permissions outside of image mapped memory.
> NOIMAGE_RX: Memory section with RW permissions outside of image mapped memory.
> PRIVATE_RWX: Memory sections with RWX permissions in private memory.
> PRIVATE_RX: Memory sections with RX permissions in private memory.
> See 3.123 for flags describing the memory page type.
323
Procee Environment Block Masquerading
> Technique used by attackers to change the command line and executable path in the PEB to spoof a different name or location for the loaded code.
324
Page Table Entry (PTE)
> A Page Table Entry is an entry in a page table that maps a single virtual memory page to a physical memory page (ie. indicates if the page is stored on disk). Each page in virtual memory has a corresponding PTE.
> Tracks the location (RAM or disk), permissions (current), page modifications, and presence/absense of a page in physical memory (has it been paged out).
> PTEs reside in the Kernel, so are difficult to manipulate. As such, they are the ground truth for memory allocations and can be used to identify gaps in a VAD tree. However, note that the NtProtectVirtualMemory Kernel function has been used to manipulate permissions in PTEs. For example, TAs can change the permissions to RW to copy code to a memory location and then switch the permissions to RX to excute it.
> When a process requests memory, the OS updates the VAD table to reflect the virtual address range allocated. When the process tries to access this new virtual memory, the OS checks PTEs to map that virtual memory to actual physical memory, which allows the process to run (virtual memory doesnt exist). If physical RAM is full, PTEs allow pages to be swapped to disk for retrieval later.
325
PTE
> See Page Table Entry
326
SSDT
> The kernel uses the System Service Descriptor Table (SSDT) as a lookup table for system functions, which bridge applications and the kernal. When a user-mode API (Windows API) makes a call, the SSDT interprets this and then triggers the correct kernel-mode functions (NtDeleteValueKey, NtOpenKey).
> ntdll.dll is the user-mode DLL that manages the relationship between userland and the kernel. When an app calls a user-mode Windows API (like CreateFile), ntdll.dll provides the native kernel-mode functions (like ZwCreateFile that translate the user calls into system calls the kernel understands. ntdll.dll is called by kernel32.dll.
> When abused, an SSDT hook patches/manipulates one of these SSDT pointers to redirect kernel-mode functions to a location the rootkits controls. Because it runs in the kernel, it is a global or system-wide hook, meaning every running application will be affected. This is commonly used to hide registry keys (often to hid persistence mechanisms), hide processes and threads from security applications, and facilitate code injection.
> The risk here is that changes to the Kernel can lead to system crashes, as Kernel Patch Protection (or PatchGuard) will crash teh system on 64-bit operating systems when anomalous changes are identified in the SSDT, IDT, or other critical Kernel components.
> When using the SSDT Volatility plugin, it is key to filter out all instructions in either the system kernel (ntoskrnl.exe) or the GUI driver (win32k.sys). As these are typical and any malicious entries would differ. There are edge cases where a system loaded a different kernel (ntkrnlpa.exe or ntkrnlmp.exe) instead of ntoskrnl.exe, so watch out.
> To do this use egrep -v '(ntoskrnl\.exe | win32k\.sys)'
327
System Service Descriptor Table (SSDT)
> See SSDT
328
PatchGuard
> Windows internal security tool that crashes a system if it detects changes to the SSDT, IDT, or other critical Kernel components.
> Components like Driver Signature Enforcement prevent TAs from running unsigned drivers in the Kernel.
> Defeats SSDT attacks, DKOM attacks (see Direct Kernel Object Manipulation).
> See SSDT index entry
329
Direct Kernel Object Manipulation
> A rootkit technique that allows malware to make changes to kernel objects directly within memory. The changes don't get written to disk making it difficult for security tools to detect.
> Popular attacks include unlinking processes and drivers from their standard kernel lists.
> For example, DKOM can be used to unlink a process from the EPROCESS list, even though it will continue to run.
> You can defeat this using Volatility PsScan, which doesnt solely rely on the EPROCESS list like pslist.exe, tasklist.exe, or Volatility's PsList plugin.
> Again, PatchGuardand Driver Signature Enforcement largely defeats this attack.
330
psxview
> A Volatility plugin that uses cross-view analysis to help analysts visually identify anomolies between various plugins, including: pslist, psscan, thrdproc, pspcid, csrss, session, and deskthrd.
> psxview will display a "False" if a process is not present in any of these plugins and a "True" if it is.
> Be careful, processes like System, smss.exe, and csrss.exe will all show a "False" in this list, as they are run too early in the boot cycle. Processes run before smss.exe will not show in session or deskthrd. The "-R" option does its best to filter out FPs from a known list. This will mark an item as "Okay".
> Note, a process that shows up in psscan but nowhere else is a classic example of a terminated process, so may be a FP.
331
apihooks
> Because userland hooks are accoumplished in user mode, their effects are not global. However, they can hide better, as they are more likely to be accoumplished by legitimate applications and their effects are not global
> Import Address Table (IAT) hooks require changes to the address location in a processes IAT.
> Inline/trampoline hooks are similar to IAT hooks in that they both intercept process function calls. However, inline hooks modify the functions themselves, rather than the process import address table.
> There are a number of legitimate hooks in the IAT which are listed to the right.
> Hunting:
> Process: this is the process that is calling the Windows API.
> Function: This is the function associated with the Windows API call. When analysing, look for no file name in the this row (ex: USER32.DLL!GetClipboardData at 0x77d6fcb2). 0x77d6fcb2 is the name of the DLL in this case, indicating it doesnt exist/not written to disk.
> Hooking module: Look for "unknown", which indicating its jumping to a memory section that is not mapped (backed with a file on disk).
332
Import Address Table (IAT)
> The IAT lives in user mode, inside a running executable (DLL or EXE) loaded into memory.
> The IAT maps a program's calls to Windows API functions to their actual memory address.
> When your EXE is compiled, it lists the functions it needs from other DLLs and the IAT gets filled in by the Windows API loader with the real memory addresses of those functions when the program starts.
> It links user-mode code to user-mode DLL libraries.
333
Driver Signature Enforcement
> Requires all software running in the Kernel to be digitally signed.
> To evade, Tas can force system into test signing mode, steal legitimate code signing certificates, and find and abuse a vulnerable driver (most common: see bring your own driver)
334
Bring Your Own Vulnerable Driver Attacks
> Takes advantage of flaws in existing signed drivers to bypass the Driver Signature Enforcement security protection, which mandates that all software running in the Kernel is signed.
> This is the most popular rootkit technique.
> Attacks commonly use a flawed driver to load a second evil and unsigned driver.
> Common goals: gain kernel access to support rootkits hooks, remove security and EDR products, advanced code injection, UEFI firmware rootkits (disabling EDR and security tools, as seen with RobinHood, and further hooks and/or injection to hide processes, files, registry keys, and network connections).
> In the case of BYOVD, multiple drivers will be loaded and present on the system.
> Services are the most common means to load drivers and leave behind memory, event logs, and registry artifacts.
> Turla, Slingshot, Winnti, Trickbot, CosmicStrand malware all use vulnerable drivers from MSI, Gigabyte, Virtual Box, Slysoft AnyDVD, Avast amoung others.
> LOLDrivers is the resource for BYOVD research. It has identified 320+ vulnerable drivers and can be used during an investigation to check names and hashes of drivers you might find loaded in memory, files newly created on a system, or drivers referenced in event logs. The database is freely available, making it easy to integrate into tool performing automated checks and threat hunting. There are pre-built Sysmon configurations, Sigma rules for SIEM integration, and YARA signatures. The Elastic YARA signatures in MemProcFS include over 100 signatures for vulnerable drivers.
335
modscan
> Volatility plugin that scans memory for any instances of pool tags associated with memory pages containing drivers (can identify old or unlinked dirvers in memory pages), their size, and location.
> Scans memory image to find loaded, unloaded, and unlinked kernel modules (drivers).
> Compare the modscan output with web search enginers, drivers loaded on a similar system, or the Vanilla Windows Reference Project. You can also dump the drivers and scan them with IOCs or antivirus.
> Not that if a driver is not present in a linked list of actively loaded modules (either because of hiding techniques or being unloaded), the modules pluging wont pick it up. You have to rely on modscan.
336
modules
> Volatility plugin that provides the contents of the linked list identifying currently loaded drivers (also referenced as modules), their size, and location.
> Walks the linked list to identify kernel drivers loaded.
> If a driver has been unhooked or unlinked, it will not show up here.
337
hardware device drivers
> Drivers provide the OS with a means to extend its functionality. Hardware device drivers allow users to interact with hardware-like disks, wireless network cards, and printers to name a few.
> Malware can use drivers to introduce code into the kernel and take control of systems.
338
Drivers (modules)
> See hardware device drivers
339
Import Hashes (imphash)
> Import hashes are calculated for drivers present in memory and are calculated using the names and order of API functions imported by the driver. It is a reliable way to identify different EXE/DLL driver variants or a malicious driver trying to blend in. If an entry does not have an imphash, it indicates the tool was not able to extract a complete copy of the file, often caused by paging. An imphash can be used for stricter matching using the --imphash option.
> Used in the Memory Baseliner tool.
340
File extraction (MemProcFS)
> Because MemProc stores data in an NTFS file structure, file extraction is easy. All you need to know is the correct location of the files you are targeting. See Tools index.
> Objects in MemProcFS are largely read only. However, if you ever have difficulty opening a file, just copy it to a local folder and try again.
> The pefile.dll is the closest representation of file in Portable Executable (PE) format. However, note that files always change as they are loaded from memory into disk, so it will not be a bit for bit match. This file exists under the modules folder of the process it belongs to.
> Note that if your process is not under the M:\name or M:\pid folder, it may be exited. The MemProcFS configuration folder has an option to force building of folders for exited processes, although this is not done by default because data can be missing or corrupted. Changing the value to "1" in the file M:\config\config_process_show_terminated.txt will make these available.
> Because the System process is the first process started upon boot. As such, kernel code, including most drivers, runs under its umbrella. Each of the driver folders will be a corresponding pefile.dll representing the driver contents (some graphics drivers are present under the CSRSS.exe process.
341
MemProcFS (File Extraction)
> Because MemProc stores data in an NTFS file structure, file extraction is easy. All you need to know is the correct location of the files you are targeting. See Tools index.
> Objects in MemProcFS are largely read only. However, if you ever have difficulty opening a file, just copy it to a local folder and try again.
> The pefile.dll is the closest representation of file in Portable Executable (PE) format. However, note that files always change as they are loaded from memory into disk, so it will not be a bit for bit match. This file exists under the modules folder of the process it belongs to.
> Note that if your process is not under the M:\name or M:\pid folder, it may be exited. The MemProcFS configuration folder has an option to force building of folders for exited processes, although this is not done by default because data can be missing or corrupted. Changing the value to "1" in the file M:\config\config_process_show_terminated.txt will make these available.
> Because the System process is the first process started upon boot. As such, kernel code, including most drivers, runs under its umbrella. Each of the driver folders will be a corresponding pefile.dll representing the driver contents (some graphics drivers are present under the CSRSS.exe process.
342
File extraction (Volatility 2/3)
> There is no guarentee an object will be kept in memory. It is common for all or part of objects to be pagd out of RAM, causing extraaction to fail or provide only partial data. Adding the page file to your analysis can greatly help with this.
> In Volatility 3, dumping capabilities have been moved to the standard plugins using the --dump option.
> Remember to use the profile=[profile] for Vol2 plugins.
> Executable Extraction:
> For example, the windows.pslist plugin facilitates extracting suspicious processes from memory images.
> You can also use the --pid option to dump files from processes (seperated by a space).
> Use PsScan to dump files from processes not in pslink (unlinked or exited).
> The equivilent plugin in Volatility 2 is procdump, which allows extraction by PID (-p), memory offset (-o) or regular expression (-n name_regex).
> DLL Extraction:
> The windows.dlllist plugin is used to dump DLLs in Vol3. Good to limit to specific processes using --pid option.
> The equivilent in Volatility 2 was dll dump, which allowed extraction by PID (-p), base offset (-b offset, or regular expressions (-r name_regex).
> It is not unusual to extract many duplicates here, as DLLs are shared across processes.
> Driver Extraction
> Windows.modules --dump will dump all of the kernel drivers in memory image, so providing a -o output folder is important.
> windows.modscan should be used if you are hunting for unlinked or unloaded drivers.
> Moddump is the Vol2 equivilent, which allowed extraction by base offset (-b offset) or regular expression name (-r name_regex).
343
Process memory extraction
> Generally speaking, process memory (see Process Memory index entry) is compromised of memory section that contain code and sections that contain data owned by the process.
> Process Code: Process code is a close approximation of the origional executable. You can pull this code using windows.pslist.pslist or MemProcFS using the M:\[process]\modules[executable] folder.
> Process Data: This represents many more sections. the windows.memmap --dump plugin iterates through the process VAD tree and extracts all memory resident in pages into a file (this is similar to memdump in Vol2). This contains both code and data. Although it is large, it can be used for string searching and signature scanning. In MemProcFS, this data can be found in M:\name\[process name]\memory.vmem (represents all process space, so can be unweildy) and M:\name\[process name]\minidump.dmp (this contains stack, heap, executable, and loaded DLLs, but will be missing many private memory locations).
> MemProcFS data can be large and unweildy, so best to use Volatility.
344
Strings
> Linux tool capable of extracting English ASCII and Unicode strings from data streams. Use the -t d option to get the exact byte offsite (location) of the stringin question. The byte offset will be the number listed at the beginning, followed by the string.
> Standard practice is to run the tool twice, once for Unicode strings (with the -e 1 option) and once for ASCII strings.
> You can then grep through a strings file using the grep tool in Linux (use the -f option to greg against a file containing a list of expressions. Capitalisation matters in Linux (-i tells it to ignore caps).
> Note that if running against an image of Windows 10+, compression is common. So consider running winmem_decompress.py first.
345
bstrings.exe
> Both Windows and Linux tool that is similar to "strings". It differs in that it can extract both unicode and ASCII code at the same time and also perform initial searches. You can also search with a file of many search terms or with regular expressions.
> Note that if running against an image of Windows 10+, compression is common. So consider running winmem_decompress.py first.
346
winmem_decompress.py
> In Windows 10+ OS, compression of memory is common. This is a tool used to decompress a memory image. While the output of the tool can not then be analysed by Volatility or MemProc, you can run strings searches across it.
> For example, you can run winmem_decompress.py, then run page_brute.py YARA scanner on the pagefile.sys file. This would be much less effective against a compressed image.
347
swapfile.sys
> Similar to pagefile.sys used by Universal Windows Platform applications.
> Include -pagefile1 swapfile.sys at the end of a MemProc command line to include this file in analysis.
348
Cached files (memory)
> The Windows OS caches many files in memory including items that are frequently in use and hence should be in memory to improve file system efficiency.
> This includes registry hives, prefetch files, the MFT, memory mapped files like EXE and DLL, and virtually any type of file that happens to have been recently loaded into memory like Word and PDF docs or log files.
> Cache items are tracked via in-memory data structures named File_Objects. Processes maintain pointers to File_Object data structures via their process handle table and VAD tree.
> MemProcFS stores these files under the M\name\[process name]\files folder.
> In this folder, there are sub-folders for handles (process handles pointing to File_Objects), modules (.exe, .dll, .sys (drivers)), and vads (file reconstruction using VAD tree information).
> Volatility:
> windows.dumpfiles is designed to extract cached versions of files using File_Object data structures. This is voluminousl.
> windows.filescan is specialised tool used to hunt for File_Object signatures in memory (you can also use windows.dump files, but the output is voluminous).
> dumpfiles will not recover closed or manipulated file objects. It will also not recover NTFS special files like $MFT or $LogFile. Use filescan for this.
> If you find something interesting, use the windows.dumpfile plugin to recover the data using the --virtaddr argument and the memory offset provided by filescan.
349
File_Object
> The Windows OS caches many files in memory including items that are frequently in use and hence should be in memory to improve file system efficiency.
> This includes registry hives, prefetch files, the MFT, memory mapped files like EXE and DLL, and virtually any type of file that happens to have been recently loaded into memory like Word and PDF docs or log files.
> Cache items are tracked via in-memory data structures named File_Objects. Processes maintain pointers to File_Object data structures via their process handle table and VAD tree.
> MemProcFS stores these files under the M\name\[process name]\files folder.
> In this folder, there are sub-folders for handles (process handles pointing to File_Objects), modules (.exe, .dll, .sys (drivers)), and vads (file reconstruction using VAD tree information).
> Volatility:
> windows.dumpfiles is designed to extract cached versions of files using File_Object data structures. This is voluminousl.
> windows.filescan is specialised tool used to hunt for File_Object signatures in memory (you can also use windows.dump files, but the output is voluminous).
> dumpfiles will not recover closed or manipulated file objects. It will also not recover NTFS special files like $MFT or $LogFile. Use filescan for this.
> If you find something interesting, use the windows.dumpfile plugin to recover the data using the --virtaddr argument and the memory offset provided by filescan.
350
Malware discovery
> Sigcheck: validates digital signatures
> YARA: search for string and header based signatures.
> maldump: extract data from AV quarentine.
> capa: Malware identifications based on signatures.
351
Sigcheck
> A Sysinternals tool designed to check code signing characteristics of an executable file.
> Using the -u and -s options, an analyst can dump a recursive list of unsigned binaries for analysis.
> The majority of malware in the wild is not signed.
> TAs have resorted to using stolen certificates to sign malware. However, these certs are both easy to identify, and when identified, can be used to scan across the estate for compromised devices.
> Sigcheck can perform hash lookups with VirusTotal, file entropy can be calculated, and file hashes generates. Sigcheck can also dump certificate stores to identify any root certificates present not explicityly trusted by Microsoft.
> Entropy measures predictability of bytes and can largely be thought of as a test for how much randomness is in data. File entropy can help identify files containing large amounts of comprssed or encrypted data.
> Windows executables have a low amount of Entropy. Compressed zip files or encrypted files have a high amount of entropy.
> Sigcheck can measure entropy using the -a option and the Shannon's Entropy value. This measures entropy on a scale of 0-8. An empty file wold score a 0, text files around a 4, and executables between 4.5 and 6. Shellcode has entropy between 7.2 and .74 and then compresed or encrypted files at an 8.
> The tool "ent" in Linux can perform this calculation.
352
Entropy
> Entropy measures predictability of bytes and can largely be thought of as a test for how much randomness is in data. File entropy can help identify files containing large amounts of comprssed or encrypted data.
> Windows executables have a low amount of Entropy. Compressed zip files or encrypted files have a high amount of entropy.
> Sigcheck can measure entropy using the -a option and the Shannon's Entropy value. This measures entropy on a scale of 0-8. An empty file wold score a 0, text files around a 4, and executables between 4.5 and 6. Shellcode has entropy between 7.2 and 7.4 and then compresed or encrypted files at an 8 (evasive malware 6-8).
> The tool "ent" in Linux can perform this calculation.
353
maldump
> Files quarentined by AV are designed to be rendered unusable and difficult to access. With proper permissions you might be able to use the AV software on live systems to recover files, but this becomes difficult if you only have a copy of the drive or folder.
> If the AV vendor is one of those listed below, you can use maldump to test a mounted image for the existence of a quarentined file and then collect data from that file, including file size, file hash. You can then extract a copy of that file.
> Note that KAPE doesnt usually collect these files. But the default settings can be easily modified. This is not a problem with full disk images.
> Avast AV, Avira AV, Eset NOD32, FortiClient, G Data, Kaspersky for Windows Server, Malwarebytes, Microsoft Defender.
> maldump is written in python and is designed to be pointed to the root folder of a file system where it iterates through known vendor folder locations looking for the existence of quarentined files.
> Either a KAPE collection or a triage image will work. Just a directory with quarentined files won't and will need to be placed into a fake folder structure.
> maldump can provide two sets of information: metadata (-m) and file dumps (-q). If you want both, select the "all" option (-a). The "list" option (-l) provides a simple view of discovered quarentined files. All timestamps are in UTC.
354
capa
> The FireEye FLARE team released the open-source capa project to lower the bar for malware investigations.
> The tool provides information by disassembling code, looking for well-known patterns, and then describing what those patterns indicate in plain language.
> The FLARE team have seeded capa with hundred of crowdsourced patterns (rules) and researchers have added more. Amoung others, these can look for File Headers, API calls, Strings and constants, and disassembly features.
> These rules match common malware actions like communication, host interaction, persistence, anti-analysis, etc. ATT&CK technique mapping included.
> Designed to be run against a single file of interest. Can be run with no options and create a full output or run with verbose options to identify exactly where matches were found in the code.
> By default, capa will assume you are analysing an executable (-f pe). But it can also analyse shellcode in 32-bit format (-f sc32) or 64-bit format (-f sc64).
> The output will have the "Capability" listed next to the category of the rule it matched (NAMESPACE). Above this will be the ATT&CK technique and the Malware Behaviour Catalog (MMBC).
> It is important to pair this information with other data sources, as malware does have a lot of seemingly suspicious code that is totally normal.
355
Timeline analysis
> Three core area of focus (Windows forensic trinity): filesystem metadata, windows artifact data, Windows registry information.
> Two methods to create a timeline: Sleuthkit tool fls or newer MFTECmd. This is quick, as it only extracts metadata from the filesystem like name, path, timestamps, and file size. Plaso/log2timeline.py Supertimeline is much slower, but includes operating system artifacts, logs, browser activity, and specialised artifacts like the Registry.
> Process: determine timeline scope, narrow pivot points, determine best process for timeline creation, filter timeline, analyze timeline.
356
Registry
> The Windows Registry is a hierarchical database that stores configuration settings, options, and system information for the operating system, installed applications, and hardware devices.
> It acts as a centeral repository for low-level system and software configurations, such as user preferences, device drivers, services, and security settings.
> It is organised into hives and consists of keys, subkeys, and values. These are stored in files on disk typically located in C:\Windows\System32\config\SYSTEM (for example)
> It operates at the software/configuration layer above the file system.
> It is stored in the same disk partition as the NTFS, which tracks changes to the files in the MFT, and stores the data itself.
357
NTFS
> The NTFS is the file system used by Windows to organise, store, and manage files and directories on storage devices like hard drives or SSDs.
> It handles physcial and logical structure of data on disk, including file storage, permissions, metadata, and features like encryption and compression.
> The NTFS uses the MFT to track all files and directories storing metadata and pointers to the actual data on disk.
> The OS interacts with NTFS via the file system driver to read/write files, manage directories, and enforce access control.
358
Pivot point
> This is a relevant point (file, time, or artifact) found in the timeline that can be examined to determine what happened before and after that instance. Many refer to it as a "Temporal Proximity".
> You can use time of incident (AV alert, 3rd party notification), network activity (bad url's accessed, bad DNS requests), process activity (DLL injection or running process), name of a file, user account, TA activity (lateral movement, anti-forensics).
359
Temporal Proximity
> This is a relevant point (file, time, or artifact) found in the timeline that can be examined to determine what happened before and after that instance. Many refer to it as a "Temporal Proximity".
> A single artifact may not make sense on its own, but in context, it takes on a whole new meaning.
> You can use time of incident (AV alert, 3rd party notification), network activity (bad url's accessed, bad DNS requests), process activity (DLL injection or running process), name of a file, user account, TA activity (lateral movement, anti-forensics).
360
Artifact temporal proximity
> This is a relevant point (file, time, or artifact) found in the timeline that can be examined to determine what happened before and after that instance. Many refer to it as a "Temporal Proximity".
> A single artifact may not make sense on its own, but in context, it takes on a whole new meaning.
> You can use time of incident (AV alert, 3rd party notification), network activity (bad url's accessed, bad DNS requests), process activity (DLL injection or running process), name of a file, user account, TA activity (lateral movement, anti-forensics).
361
Filesystem timeline
> Parsed data: The filesystem timeline collects data from all the files and directories in a volume. This includes both allocated and unallocated metadata structures. The latter provides knowledge of deleted and orphan files within a filesystem.
> Tools: MFTECmd.exe and Sleuthkit fls (See index entries).
> Times collected: Every filesystem uses different timestamps. The most common record data modification (m-modification), data access (a-access), metadata change time (c-change), and file creation (b-birth).
> The biggest advantage of a filesystem timeline is their ability to be created across multiple filesystem types including NTFS, FAT12/16/32, EXT2/3/4, ISO9660-CDROM, HFS+, UFS1&2.
> Filesystem Timeline format:
> The "body file" format of the filesystem timeline has up to eight columns.
> The MACB column is the most important (see NTFS timestamps). Important: You only have the last time for each of these timestamps marked in the body file. You do not have historical timestamp information.
> File size can be helpful when trying to match files with the same size or when looking for very large files like archives or encrypted volumns.
> The Meta column is the metadata address for the data structure where the data was sourced. In NTFS, this represents the $MFT record. In the case of Linux, this would represent the inode number.
> The file name column contains full path information for the file. Any currently unallocated file will have (deleted) appended to this column value.
> The Permissions, UID, and GID columns contain security and ownership information. Because Windows does not represent permissions and ownership in this way, this is only relevant for Linux systems.
362
NTFS timestamps
> NTFS stores four significant filesystem times for file and directories. Last modification time (M), last access time (A), last modification of the MFT record (C), and file creation time (B).
> Changes to the Change timestamp occur when a file is renamed, the file size changes, security permissions update, or file ownership changes.
> File Access times are not trustworthy so shouldnt be used.
> Analysts should prioritise the modified (M) and created (B) timestamps.
> When a file is created (B), all four timestamps are set to the time of creation.
> File modifications need to read the data, change the data, and update the file size (this changes M,A, and C).
> A file rename and a local file move only affect the metadata of a file, so only C time is changed.
> Because Windows doesn't have a deletion time, no timestamps are updated when a file is deleted.
> When the CLI is used to copy or move a file, the modified times are inherited from the origional file. This means that a file can have a modified time earlier than the created time (when the file was moved). For example, when SMB (and net use command) is used to copy a file to a remote system, the timestamps will stay the same, including the modified timestamp.
> Created and Modified timestamps did not change between Windows 10 and 11. Access times and Metadata change times did. Consult the chart on 4.37 for details.
> NTFS filesystem stores time values in UTC, so they are not effected by changes in time zone or daylight savings. This is not always the case with other filesystems. FAT filesystems store time values based on the local time of the computer.
> The time format used by NTFS is a 64-bit FILETIME data structure storing timestamps as the number of hundreds of nanoseconds since 12:00 Jan 1, 1601 UTC.
> Exceptions: Microsoft Office updates access times even when these are turned off in the registry, malware and anti-forensic tools can change timestamps, archiving software backdates the modification time of unzipped files to the time the dates were previously when the archive was created (looking like a file copy), the scanning of security software can update time stamps (meaning access timestamps can change).
363
Timestamps
> See NTFS timestamps
364
MFTECmd.exe
> Tool used to extract and visualise data from $MFT files, filesystem journals, and several other NTFS system files.
> To create filesystem timeline, you use MFTECmd.exe to extract data into timeline (bodyfile) format. The mactime tool is then used to make this data human readable. However, you can also output the data to a CSV file as well.
> fls is designed to extract metadata information using an image of a filesystem volume (the entire C: drive), while MFTECmd uses just the $MFT file for the C: drive allowing timeline creation when an image is not available.
> fls can parse many more filesystems, whereas MFTECmd supports only NTFS.
365
fls
> Open source Sleuth kit tool used by a vast number of tool suites to parse file systems. It is designed to extract filename and metadata information for files. This allows interaction with a forensic image as though it were a normal filesystem and data collection from the filename layer.
> By providing the -m option, we can tell the tool to output this information in the common "bodyfile" timeline format, which is the first step for timeline creation.
> This collects three different types of data:
> Allocated files: normal active files one would see when performing a directory listing.
> Deleted files: unallocated files whose name structures still exist. The metadata of deleted files can still contain full path information and details such as times and permissions.
> Orphan files: data from unallocated metadata structures where the parent folder information no longer exists. A file with a specific name and set of timestamps once existed in the filesystem, but do not know in what folder it was present.
> fls is designed to extract metadata information using an image of a filesystem volume (the entire C: drive), while MFTECmd uses just the $MFT file for the C: drive allowing timeline creation when an image is not available.
> fls can parse many more filesystems, whereas MFTECmd supports only NTFS. In Linux, it takes the inode value of a directory, processes the contents, and displays the filenames in the diretory (including deleted items).
> Use mactime to make body file "human readable".
366
mactime
> Mactime makes take bodyfile data generated by MFTECmd.exe and fls and parses it to make it human readable.
> At a minimum, you need to provide the tool with the -b option, which is the location of the body file.
> Mactime will attempt to convert your timestamps to your local forensic workstation time by default. To prevent this time conversion, use "-z UTC" to keep timestamps in their native UTC format.
> You can also provide with a date range to limit your result set.
367
Plaso/log2timeline
> log2timeline is the main single-machine frontend to the Plaso backend. L2t is the tool used to extract events from a group of files, mount point, or an image and save the results to a Plaso file for processing.
> Its power is its ability to collect data from disparate sources and parse it using common toolkits.
> When run against a collection of files in a directory, recursion is automatic, evaluating all files through all subdirectories.
> pinfo is a plaso storage file containing information about how and whne the collection took place. It may also contain information from any preprocessing stages that were employed. pinfo is a simple tool designed to print out this information from a storage database.
> psort is the post-processing tool used to filter, sort, and process the plaso storage file. It is used for all post-processing filtering, sorting, and tagging of the storage file, which is not in human readable format.
> Registry hives (winreg parser): L2T has excelled in parsing registry hives,including file and folder access data (Shellbags, RecentDocs, Open/SaveMRU) and file execution data (appcompatcache, userassist, runmru, and others).
> Webhistory (webhist parser):
> Mactime (mactime parser): This plugin converts traditional bodyfile timeline output into a plaso database format file. This allows tools that default to the mactime format (such as the timeliner Volatility plugin) to be imported directly into a Plaso database (log2timeline.py --parsers "mactime" out.plaso bodyfile).
368
log2timeline/Plaso
> log2timeline is the main single-machine frontend to the Plaso backend. L2t is the tool used to extract events from a group of files, mount point, or an image and save the results to a Plaso file for processing.
> Its power is its ability to collect data from disparate sources and parse it using common toolkits.
> When run against a collection of files in a directory, recursion is automatic, evaluating all files through all subdirectories.
> pinfo.py is a plaso storage file containing information about how and whne the collection took place. It may also contain information from any preprocessing stages that were employed. pinfo is a simple tool designed to print out this information from a storage database.
> psort.py is the post-processing tool used to filter, sort, and process the plaso storage file. It is used for all post-processing filtering, sorting, and tagging of the storage file, which is not in human readable format.
> Registry hives (winreg parser): L2T has excelled in parsing registry hives,including file and folder access data (Shellbags, RecentDocs, Open/SaveMRU) and file execution data (appcompatcache, userassist, runmru, and others).
> Webhistory (webhist parser):
> Mactime (mactime parser): This plugin converts traditional bodyfile timeline output into a plaso database format file. This allows tools that default to the mactime format (such as the timeliner Volatility plugin) to be imported directly into a Plaso database (log2timeline.py --parsers "mactime" out.plaso [bodyfile]).
369
pinfo.py
> pinfo is a plaso (log2timeline) storage file containing information about how and when the collection took place. It may also contain information from any preprocessing stages that were employed. pinfo is a simple tool designed to print out this information from a storage database.
> Contains data about what was parsed, when the parsing took place, any preprocessor information, and the plugins/parsers/filter files used to extract data, errrs and storage container metadata.
> pinfo.py out.plaso. (-v) for verbose information.
370
psort.py
> psort.py is the post-processing tool used to filter, sort, and process the plaso (log2timeline) storage file. It is used for all post-processing filtering, sorting, and tagging of the storage file, which is not in human readable format.
> The raw output of a log2timeline export is a SQL database containing serialized event objects, metadata, tags, reports, and various other extracted or derived information. psort is the tool that is used to read these files. Most importantly, it removes duplicate entries, which is very helpful when including Volume Shadow copies and backup registry hives.
> The minimum number of inputs needed for this utility to run is the path to a Plaso storage file and an output file (-w). Given this, the utility will return all events from the storage file and use UTC as the default time zone to output events.
> psort uses UTC as its default timezone when outputting events. This can be controlled using the "--output-time-zone" parameter (psort.py --output-time-zone list).
> Time slice: You can grab a time slice 5 minutes before and 5 minutes after.
> The default output format is "dynamic" which is a CSV format with a slimmed down number of fields. This is generally refered to as a l2csv format (see page 4.87 for field information.
371
log2timeline usage (see log2timeline/plaso)
> To use log2timeline, you require two options: specifying a storage file and specifying the source of data to parse.
> The storage file is a database file that hold normalized parsed data resulting from log2timeline analysis of artifacts. This is typically a new file created as a result of running log2timeline, but its also possible to re-run log2timeline against additional data to add events to an existing database file.
> The source of data to parse is a directory of files, a mount point, or an image file containing artifact files from the subject system. log2timeline can be run against nearly any data source (when processing an image file, it is recommended to parse the raw risk rather than a mounted image).
> You can limit the files collected, and speed up processing, by using "parsers", which means only artifacts relevant to chosen parsers will be analysed. You can also use "filter files" containing a list of specific files to find and parse and triage images to cut down on processing time (see Parsers index).
> Although the timezone does not need specifying, it is best practice to always specify it using the --timezone option. Note this is the timezone of the computer being investigated (not the desicred output time zone).
> If an image or mounted device is used as the source, log2timeline typically runs a preprocessor that collects the time zone information automatically. Note log2timeline defaults to UTC and always stores UTC artifacts in UTC (--timezone list outputs a list of timezones).
> When run against a collection of files, including a triage image, the time zone should be included.
> review the "setupapi" parsing results for local time adjustments. It stores times in local times.
372
Parsers (log2timeline)
> You can run log2timeline against a full image, which will extract all timestamps and artifacts. Filtering and analysis are then accoumplished on the full data set ater collection. This "kitchen sink" approach is slow and can take 12 - 24 hours.
> Alternatively, you can use "parsers" for timeline creation. Only artifacts relevant to the chosen parsers will be analysed and output. These collections only take 5-30 minutes, but you do run the risk of missing certain artifacts.
> (--parsers PARSER_LIST) to see the full list of parsers.
> Log2timeline provides severa "preset" parser lists in the distribution. The "win7 parser is relevant for all Windows systems from Vista and above (not XP). Both "win7" and "winXP" reference "win_gen", which are consistent across all windows versions.
> In addition you can use "Filter Files" which contain a list of specific files to find and parse (see Filter files index).
> Lastly, you can run log2timeline on a triage collection rather than a full disk image.
373
Filter Files (log2timeline)
> Filter files limit the amount of data log2timeline needs to collect by defining the paths to files and paths that should be parsed, ignoring the rest.
> This allows log2timeline to skip irrelevant files in a filesystem.
> There are two supported formats for the filter file: text-based and YAML-based.
> Text based format contains a single line for each file path with each part of the path seperated by a forward slash. Entries can use regular expressions or wildcards. "Path expansion variables" extracted from Plaso preprocessing modules are also allowed (ex: {systemroot}).
> Example: /Users|Documents and Settings)/.+/NTUSER.DAT = a file within the folder Users or Documents and Settings followed by any subfolder which includes a file specifically named NTUSER.DAT.
> Example: {systemroot}/winevt/Logs/.+evtx = all EVTX files stored under the winevt\Logs path in the root directory.
> YAML-based filters: The difference here is that YAML-based filters supports exclusion rules. This means rules can be created to define not only what to include, but also what not to include.
374
Triage collection (recommended artifacts
> Memory, Registry hives and backups, LNK files, Jump Lists, Prefetch, Event Logs and Windows Logs, Browser Data, Master File Table, Log Files and Journal Log, Pagefile and Hibernation Files.
375
l2csv format
> The default output format for psort.py is "dynamic" which is a CSV format with a slimmed down number of fields. This is generally refered to as a l2csv format (see page 4.87 for field/column information). Recommended fields include: date, time, MACB, sourcetype, type, short, desc, filename, inode, extra
376
