Basics of Windows Incident Response

For most people, including me, it is difficult to determine just what is “normal” when looking for signs of a compromised host. As someone who has done multiple CCDC’s as a blue teamer, I can say that this is easily one of the biggest struggles since it affects incident response as well as identifying a compromise.

I recently watched a webinar from Black Hills Info Sec that covered the basics of live Windows IR from the SANS 504 course. I recommend watching it, you can find it on YouTube HERE.

Obligatory thank you to BHIS and SANS.

Overview

Some of the most reliable tools for basic IR are built into Windows and Linux. This post will cover mostly Windows IR and definitely is nothing in depth but will get you started in the right direction. Windows has an extremely powerful tool named WMIC. WMIC stands for Windows Management Instrumentation Command-Line. It is extremely useful for IR as well as penetration tests. Between WMIC, netstat and tasklist, you likely have enough to notice some of the telltale signs that you have an infected host.

The biggest thing about these tools is recognizing what is not normal. The best way to do that is to become familiar with the output of the tools. Look at the associated DLLs for common processes like svchost so that you can determine whether or not it’s actually a malicious executable or that the associated DLLs are legitimate. Of course, there are numerous ways around this from an attacker’s standpoint but you get the idea.

SANS Instructor Mark Bagget developed a fairly neat tool that spawns a backdoor and quizzes you to find some information about that backdoor using some of the tools I go over.

You can download that tool HERE.

I have a walk through for the tool below, it is very straight forward but is a good introduction to Windows IR.

Most of the commands used to determine the answers to the questions can be found on the SANS IR Cheat Sheet.

Linux IR Cheat Sheet

Windows IR Cheat Sheet

Log Review Cheat Sheet

Windows IR Commands:

Event Logs

Event logs can be a great source of information, that is if you know what you are looking for. I would prefer querying it for known bad indicators versus looking at 25,000 logs that really don’t tell us anything useful. Luckily, there is an easy way to look for specific logs.

Wevtutil enables us to retrieve information from event logs via the Windows command line, which is pretty awesome. You can do all this stuff from a remote machine and supply the command line with credentials as well.

For more reading on Wevtutil, check out:

https://www.petri.com/command-line-event-log

https://technet.microsoft.com/en-us/library/cc732848(v=ws.11).aspx

Some of the logs that might be useful to use are Security logs that indicate user account changes or additions, failed user login attempts, or service status changes.

This command will query the Security logs for event ID 4720 (User Account Creation)

wevtutil qe security /q:”*[System[(EventID=4720)]]” /c:5 /f:text /rd:true

qe: What logs to query, here you would place system for system logs etc.

/q: Specifies the query. The only thing you really need to change in here is the EventID, just replace it for the one you want. You can use truth operators in here as well as query specific alert levels. Check out that link above for more information on that.

/c: specifies the number of events to display. (If you place nothing here, it will find all matching events)

/f: Specifies the output type, by default it uses XML which can be difficult to read.

/rd: This takes True or False. Set this to true in order to see the newest logs first.

Netstat

netstat is an awesome tool that comes with Windows and Linux. It allows you to display active TCP connections, listening ports and a whole bunch of other stats including what Process ID the connection is associated with.

This command will display all active TCP connections as well as listening TCP and UDP ports. You would want to run this to determine if this host is connecting to any strange locations, or if your host has something listening that shouldn’t be.

netstat -anob

-a: Displays all active TCP connections and the TCP and UDP ports on which the computer is listening.

-n: Displays active TCP connections, however, addresses and port numbers are expressed numerically and no attempt is made to determine names.

-o: Displays active TCP connections and includes the process ID (PID) for each connection.

-b: This will display the PID’s actual filename and requires elevation.

Tasklist

tasklist displays a list of applications and services with their Process ID. It is very useful for determining what process is associated with a PID. For example, if you notice a strange connection in the netstat output, you can determine the process with this tool.

This command will display the associated task as well as the associated DLL’s.

tasklist /m /fi “pid eq <Insert Process ID here w/out the brackets>”

/m: Displays the associating modules.

/fi: Allows you to use truth statements to refine your command.

Net

net commands have a variety of uses. The net family has multiple siblings. All of them are helpful in identifying system information as well as active network activity.

These commands display open sessions with your host.

net session

net use

Some other commands include:

net user

net view

net user USERNAME

WMIC

WMIC is an extremely useful tool for all sorts of IT folks. Having WMIC in your toolkit can immensely speed up the process of determining system information in IR, pen tests and system administration. There are some neat scripts out there that will gather a bunch of system data through WMIC for post-exploitation and enumeration as well. The link to the script is at FuzzySecurity’s write up on Windows privilege escalation.

http://www.fuzzysecurity.com/tutorials/16.html

This command will display the name and parent process ID of a given process ID. This would be the next step after determining which process is performing strange network activity. The parent process will be the process that spawned the suspicious process.

wmic process get name,processid,parentprocessid|find “<Insert PID here without the brackets>”

You can then follow up with running the same command with the parent process ID to determine the name of the parent process.

You can also determine the command used to run the process.

wmic process where processid=”PID without the quotes” get commandline

To determine startup tasks.

wmic startup get caption,command

To kill a process:

wmic process where name=”nc.exe” delete

Some other useful commands to know:

To verify firewall state

netsh firewall show state

To view scheduled tasks

schtasks /query /fo LIST /v

View running Windows services

net start

SANS 504 Incident Response Quiz

You probably want to shut your firewall off for this quiz since it will run a harmless backdoor on your host.

Begin by running the executable from an elevated command prompt.

You can use the netstat -anob to determine what is listening in which port. Typically, powershell.exe should not be listening on a random port so this should raise a red flag.

Since we used the b switch with netstat, we determined the PID as well as the listening port.

To find the parent process, we can use WMIC. We can run it twice to find the name of the parent process, we can see that our quiz executable is the parent process.

This part will be easiest done with netcat. You can find the windows pre-compiled version all over the place if you don’t have it. If you don’t know how to use netcat, check out the SANS cheat sheet or some tutorials on it, it is an extremely useful tool.

https://www.sans.org/security-resources/sec560/netcat_cheat_sheet_v1.pdf

As you can see, when we connected to that port, this flag was returned to us.

Now things get a little more tricky since we have to use tasklist to determine malicious processes running. As you can see, I determined powershell.exe was running even though I definitely did not spawn it.

Now in order to determine the command line, we can use the wmic commandline option.

Since it is Base64 decoded, you can use your favorite decoder to find the flag.

And.. That’s all! As you can see, it is very simple but it does get you somewhat familiar with some of the built in tools that can help with determining a compromised host.

If you have any questions or comments, feel free to send me an email at admin(at)jordan potti . com or reach me on twitter. @ok_bye_now