Live Examination
Last updated
Last updated
To examine a live system, investigate running processes using PowerShell's Get-Process cmdlet. Running it without arguments displays information on active processes.
When you run Get-Process, it returns an object with both visible and hidden data. To access more information, you can use the pipe (|) to send the output to Select-Object, which allows you to display additional fields or all data using the asterisk (*) wildcard.
With PowerShell, cmdlets like Get-Process are useful but limited; they don't provide details such as the parent process ID or command line parameters, which are crucial for incident response. To access this information, you can use Get-CimInstance, which leverages the Windows Management Instrumentation (WMI) framework. By querying the Win32_Process class, you can retrieve detailed process information, including the process ID, name, and command line parameters.
We can combine Get-Process with Get-CimInstance to obtain more details about a process. For example, we can use Get-Process to find the process ID for LSASS, then use Get-CimInstance to check for any unusual child processes linked to LSASS, which can indicate a security compromise.
TIP: Get-Process uses Id but Get-CimInstance uses ProcessId to refer to the same information.
Is it a new or unrecognized process?
Is the name random-looking?
Is it running from a non-standard path?
Is the parent suspicious?
Is the parent-child relationship suspicious?
Is it tied to suspicious activity?
Base64 encoded command-line options?
Pay close attention to any running processes that have base64-encoded command-line options, especially PowerShell. Many attackers and malware authors use PowerShell's -EncodedCommand option to specify the content of a script to run at the command line. This way there are no extraneous .ps1 files left in the file system. Note that not every PowerShell script that uses -EncodedCommand is malicious, but they are worthy of further investigation.
For live Windows examination, checking current network usage is key. This involves identifying listening processes for inbound attacker connections or outbound connections to a C2 server. The PowerShell Get-NetTCPConnection cmdlet provides details on listening ports, established connections, and other network statuses, helping to investigate both inbound and outbound connections.
You can use Get-NetTCPConnection to filter connections by state (e.g., listening) and pipe it to Select-Object for specific details.
The challenge with Get-NetTCPConnection is that it shows the process ID but not the process name. However, you can use Get-Process -Id processid to find the process name. Alternatively, you can combine both tasks into a single PowerShell command using a hash table with the @{} syntax.
Port 445 is listening on all interfaces: "::" for IPv6 and "0.0.0.0" for IPv4. The RemotePort is 0 because it doesn't apply to listening entries.
A service is listening on TCP port 9001, but it's restricted to the local IP address 127.0.0.1, meaning it's only accessible from the local system and not from any external systems.
Similar to identifying suspicious processes, there is no perfect list of suspicion indicators for identifying suspicious network traffic. With that in mind, here are some common things to consider:
Any unusual network activity by a process, like Notepad connecting to port 80 multiple times or a service making repeated outbound connections, which could also be an automatic update service.
Abnormal network activity for the environment, such as high activity during off-hours, long HTTP/HTTPS sessions, and frequent small outbound communications (beaconing).
Unique indicators for specific techniques include lateral movement over SMB, which involves connections to SMB ports (TCP/UDP 135-139 and 445) on internal systems.
Traffic to or from known malicious hosts, identified through threat intelligence or suspicious processes and connections.
Another live examination task is to check Windows services, which are background tasks managed by the services.exe process and can be set to start automatically. Attackers often use these services for persistence to maintain access after a reboot. Use the PowerShell Get-Service cmdlet to view all running services or specify a service name for details.
Get-Service doesn't show all details, like the program's path. To get this, use Get-CimInstance -ClassName Win32_Service for more service information.
PowerShell can query the Windows registry like a file system, treating top-level keys (e.g., HKEY_LOCAL_MACHINE, HKEY_CURRENT_USER) as drives, similar to how folders and drive letters are organized.
To navigate registry keys, use Get-ChildItem (or dir) to list contents, or Set-Location (or cd) to change to a registry key location and list items from there.
During live examination, check local user accounts, as attackers may create new ones or add them to the Administrators group. Use the PowerShell cmdlet Get-LocalUser to list accounts, and pipeline it with Where-Object to filter by attributes, such as showing only enabled accounts with the $True variable.
Similarly, the Get-LocalGroup will display all local groups on the Windows host. The Get- LocalGroupMember cmdlet will display the members of the specified group.
A common Windows investigation task is examining scheduled tasks, which run at set intervals, specific times, or after certain events, like login failures. Attackers may use scheduled tasks for persistence, often giving them unusual names or disguising them with legitimate software names to blend into the system.
The Get-ScheduledTask cmdlet doesn't show full details like the executed command or its arguments. To get these, use Export-ScheduledTask to export the task in XML format. For information on the last run time of a task, use Get-ScheduledTaskInfo to check the LastRunTime, NextRunTime, and LastTaskResult properties.
You can use the Get-WinEvent cmdlet in PowerShell to examine Windows Event Logs. It replaces the older Get-EventLog cmdlet. By specifying an event log name, Get-WinEvent displays a summary of events, and with filtering, you can narrow down the analysis to specific date ranges or log resources.
Get-WinEvent allows filtering by Event Log name using -LogName, and specific events can be displayed with Where-Object. While both Where-Object and FilterHashtable can be used, FilterHashtable is generally faster.
In these examples we investigate the System and the Security Event Logs, but Windows records a lot of detail in other Event Logs as well. We can run Get-WinEvent -Listlog * | Select LogName, RecordCount to get a list of all Event Logs on the system and the number of records in each log.
During live examinations, the vast amount of data, such as services, processes, scheduled tasks, and network connections, can be overwhelming. Differential analysis helps by comparing the current system to a baseline configuration (like the original gold image) to narrow down the investigation.
In this example, we use Get-Service to collect a list of services, saving the output to baseline-services-20220325.txt. During an investigation, we run the same command and save it to services-liveinvestigation.txt. Then, we load both files into PowerShell objects $baseline and $current using Get-Content, and compare them with Compare-Object, using -ReferenceObject for the baseline and -DifferenceObject for the investigation data.
The output of Compare-Object lets us quickly identify configuration changes between the gold image and the system under investigation.
Conduct a ping sweep:
Conduct a por t scan:
Fetch a file via HTTP (wget in PowerShell):
Find all files with a par ticular name:
Get a listing of all installed Microsoft Hotfixes:
Navigate the Windows registry:
List programs set to start automatically in the registry:
List processes
Get-Process
wmic.exe process
Network connections
Get-NetTCPConnection
netstat.exe -nao
List services
Get-Service
sc.exe query
Registry access
Get-ChildItem
reg.exe
List users
Get-LocalUser
net.exe user
List groups
Get-LocalGroup
net.exe localgroup
List scheduled tasks
Get-ScheduledTask
schtasks.exe
Access Event Logs
Get-WinEvent
wevtutil.exe
Identify differences
Compare-Object
fc.exe
It's OK to continue using legacy commands to get the information you need to complete your analysis! When invoking legacy commands, specify .exe at the end of the command to avoid using PowerShell aliases with the same name.
The Sysinternals tools are excellent (and free!):
Process Explorer: Incredibly detailed information for running processes.
Process Monitor: Shows file system, registry, network, and process information in real time.
TCPView: Maps listening and active TCP and UDP activity to the associated applications.
Autoruns: Displays a comprehensive list of Autostart Extensibility Points (ASEP).
Sysmon: Collects detailed event information for system monitoring and analysis.
Procdump: CLI tool to capture memory for a running process for analysis.
Identify the PowerShell commands that will allow you to examine various aspects of a system and nd signs of a possible compromise. Make sure to include commands that will:
Show what programs are running
Show listening ports
Show what accounts exist on the system
Show what groups exist, and which accounts are in each group
Show what network shares are available
Identify registry keys associated with Auto Start Extensibility
Identify interesting files
Let's look at the running processes by invoking the Get-Process command, as shown here.
Handles : A count of handles (open les, sockets, and pipe resources)
NPM(K) : The amount of non-paged memory the process is using in kilobytes
PM(K) : The amount of paged memory the process is using in kilobytes
WS(K) : The process working set size (the total amount of memory allocated to a process) in kilobytes
CPU(s) : The amount of processor time that the process has used on all processors, in seconds
Id : The unique identier for a process so that the system can reference it by the numeric value, also known as a PID
ProcessName : The process name, often the executable name
We can also get more information about the process than the default columns displayed.
In this command, we requested only three specific fields; Path, Name, and Id (process ID) instead of all properties as in the previous Get-Process command, making it more manageable to view.
We can use Where-Object to filter Get-Process output for potential IOCs, such as processes running from temporary directories, which is often a sign of malicious activity rather than normal system use.
In this output we've identied a suspicious process: calcache . It's possible the process could be legitimate though, so let's continue our analysis to investigate other factors as well
In the previous section, we explored running processes; now we will examine the network listeners and connections on this host.
The command output is too broad to view easily. Let's use a technique similar to what we used with Get-Process to show only the LocalAddress, LocalPort, State, and OwningProcess fields.
Several processes are listening for connections on the local system. One process is listening on all interfaces (local address 0.0.0.0) and is using an uncommon Windows port number: 4444.
The process ID for TCP port 4444 is 4380. We know the process ID, but not the process name. We can return to the Get-Process command to display the process details for this process ID.
The calcache process is back and listening on TCP port 4444. Let's terminate it.
We still need to figure out how the attacker started the suspicious process. Let's keep examining autostart locations in the Windows registry.
A common way to start a process automatically is by adding a registry value to the Windows Run or RunOnce keys, known as Autostart Extensibility Points (ASEPs). These keys initiate processes when the system boots or a user logs in. Windows supports several ASEP registry keys, with four being particularly common:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunOnce
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunOnce
Using PowerShell, we can use the Get-ChildItem command to enumerate registry keys, and the Get-ItemProperty command to enumerate registry values in a specic key.
In this output we see the Name column, which will be registry keys, and the Property column, which will be registry values in the top-level keys for the HKEY_CURRENT_USER hive (abbreviated HKCU ).
The output shows no registry values in the RunOnce keys, but both HKLM and HKCU Run keys have values. The HKLM Run key includes two programs (SecurityHealth and VMware User Process) with associated property values.
For the HKCU Run command we see an entry for Calcache, which corresponds to the Calcache process we identified earlier.
Let's remove the Calcache value from the Run key using Remove-ItemProperty.
Next, let's remove the calcache.exe program as shown here.
The analysis is progressing well, but attackers have multiple ways to deploy malware. We need to establish a baseline for comparison to assess the current environment.
There are three baseline files for services, scheduled tasks, and local users are stored in the C:\Tools\LiveInvestigation\baseline folder. Let’s review them.
These three files are generated with the following commands.
Let’s use the same commands to get the current services, scheduled tasks, and local users.
Next, we'll compare the newly-generated output to the baseline information.
The Compare-Object output shows a new service, Dynamics. While it might be suspicious like the Calcache process, we need to further investigate to determine if it's malicious.
Let’s repeat this process, using differential analysis to evaluate the local users on the system.
We can see the added username is dynamics.
We've used differential analysis to compare the system configuration to the baseline. Now, let's check for another way an attacker might maintain persistent access: a scheduled task.
Scheduled tasks are jobs that run on Windows at a specic time and with a specic frequency.
Now we can see that the added scheduled task is Microsoft eDynamics.
So far we’ve found signs of malicious behavior, but let’s keep investigating the scheduled tasks. Use the Export-ScheduledTask command to examine them in detail.
Look at the closing element labeled Actions . Here we see that the scheduled task launches a command C:\WINDOWS\dynamics.exe , and it uses the sc.exe (Service Control) utility to start the service whenever this task is executed on the host.
By analyzing the scheduled task, and through dierential analysis, we identied several components of this malicious software:
A service named dynamics (dierential analysis).
A process named dynamics (scheduled task detail).
A program named C:\WINDOWS\dynamics.exe (scheduled task detail)
A scheduled task named Microsoft eDynamics (dierential analysis).
A local user account named dynamics (differential analysis)
Let's clean up the system, starting with the service.
Next, stop the Dynamics process.
Next, remove the dynamics.exe directory from the C:\Windows directory.
The service has been stopped; now let’s remove it.
Next, remove the scheduled task, using Unregister-ScheduledTask.
Finally, remove the local user using Remove-LocalUser.
1) What TCP port is the backdoor listening on?
Now we've a baseline of the listening TCP ports.
Let's get the current listening TCP ports, save them to a file, load both files into variables, and compare to find differences.
The Compare-Object output shows a single line of difference. 1572 is the new listening TCP port.
Answer: 1027
2) What is the process ID number of the backdoor?
We have the listening TCP port, but not the process ID. Let's use Get-NetTCPConnection to find it.
Answer: 3248
3) What is the parent process ID number of the backdoor?
Answer: 6544
4) What is the flag shown when you connect to the backdoor?
Answer: TheFlagisBack582474434
5) What TCP port is the backdoor listening on now?
The backdoor is listening on a different TCP port now. Since we know the process ID, we can get the tcp port number.
Answer: 1029
6) Stop the backdoor process using PowerShell.
7) What is the process ID number of the backdoor?
We are asked to identify the process ID of a new backdoor. The clue here is that the new backdoor is a PowerShell-based process.
The output shows both the backdoor session and the analysis PowerShell session. To distinguish them, let's rerun the command and include a pipeline to get the process ID and start time.
The PowerShell process with the latest start time is the backdoor.
8) What is the flag contained in the script executed by the backdoor?
Next we need to decode the Base64 value seen on the command line following -enc.
Answer: Sasquatch8632479206
9) We are finally asked to kill the backdoor process.
