Tips to prep for digital forensics on Windows networks

Know what data you need to collect and how you will collect it before a security incident occurs on your Windows network.

forensics threat hunter cyber security thumbprint
Getty Images

The phone rings. You answer it and the rattled voice on the other end says, “We think there has been a breach.” What is your first thought about what to do?

A recent joint advisory issued by Australia, Canada, New Zealand, the United Kingdom and the United States highlights technical approaches to uncovering malicious activity and includes best-practice mitigation steps. The advisory’s goal is to help organizations improve incident response. That starts with the collection of relevant data: event logs, browser history files, evidence of listening ports, historical dates of when file folders and files were created, and so on.

I’d take a step back and ensure you have logging set up properly before an incident occurs. Install Sysmon on all relevant systems to log events to identify malicious or anomalous activity and understand how intruders and malware operate on your network. Then export these log files to your SIEM (security information and event management).

Back up infected systems

You do not want to examine a system while it’s in use as this may taint the evidence on the system. Make a backup of the system to examine the data on the image, rather than doing an investigation on a live system. Use tools such as FTK Imager to take a forensic backup of the computer to investigate and retain the original system for preserving evidence.

If you are doing analysis because you suspect something happened on a system and are not sure if a system has been compromised, tools such as PsLogList allows you to you dump the contents of an event log on the local or a remote computer. Sigcheck allows you to check the file version number, timestamp information, and digital signature details, including certificate chains. ListDLLs reports the DLLs loaded into processes. Finally, Handle allows you to see what program has a particular file or directory open.

Data to collect after an attack

You should gather the following information from the system:

  • Running processes: Yse C:\> tasklist /NH | sort to prepare a list of processes.
  • Running services: Use net start > output.txt.
  • Parent-child process trees: Use Process Explorer to prepare this list.
  • Integrity hash of background executables: Use Sigcheck to review the integrity of the files.
  • Installed applications: Wse wmic product get /format:csv > Software_%Computername%.csv
  • Local and domain users: Use net users username
  • Unusual authentications: You might need to review various authentications to determine what is unusual.
  • Non-standard formatted usernames
  • Listening ports and associated services: Use netstat -an |find /i "listening".
  • Domain Name System (DNS) resolution settings and static routes: Use ipconfig /displaydns.
  • Established and recent network connections: Use netstat -f.
  • Run key and other autorun persistence: Use autoruns to investigate.
  • Scheduled tasks: Use schtasks /query /v /fo LIST.
  • Artifacts of execution (Prefetch and Shimcache): Review these via the registry hive.
  • Event logs: Use tools such Nirsoft’s event log tool.
  • Anti-virus detections

You might also use Eric Zimmerman’s forensic tools found on GitHub. Additional artifacts that you may need to investigate include:

  • UserAssist displays a table of programs executed on a Windows machine complete with running count and last execution date and time.
  • Shimcache tracks metadata such as the full file path, last modified date, and file size but contains only the information prior to the system’s last startup, as current entries are stored only in memory.
  • hve is a registry file that stores the information of executed applications.
  • Prefetch files are great artifacts for forensic investigators trying to analyze applications that have been run on a system.
  • USN Journal is used to determine whether any change is occurred in a specific file by applications.
  • MFT contains filesystem information such as modified, accessed and created dates and file size.

The importance of keeping log data intact

Too often organizations destroy information before incident responders can protect and recover data. You want to get systems back online and business back on track, but then you lose the forensic evidence you need to determine who the attacker was and how they entered the system. Using commands such as ping, nslookup or browsing may alert the attacker that they have been detected. Blocking the attacker at the firewall may work for a short time. Attackers can easily pivot to another attack location.

Keeping log files intact is a key requirement in investigation. Often an attacker will delete log files to hide their tracks. Have an alert sent to you if a log file is suddenly deleted as it’s not a normal activity and often is a sign that an attacker is on the system. Store log files offsite where the attacker can’t gain access and erase the evidence. If you run a Windows network, install a free installation of Splunk to test out an SIEM tool if you do not already have one in your environment. If you use Office 365 or Microsoft 365, you can extract the logs using PowerShell.

Using the same network or even examining the live machine will often taint the evidence and will indicate to the attacker that you have determined the machine was attacked. You may wish to have first responders that are connected to a vlan or better yet on their own network such as a cellular network.

If you remove an infection and do not investigate how the attacker gained access to the system, you will leave your network vulnerable to more attacks. Restoring the system from a backup when you don’t understand the root cause of the attack puts the system back into the same vulnerable condition that enabled the attack. If your firm does not have an onsite investigation team, ensure that you have access to someone who has the expertise. Ask your cyber insurance carrier what resources they provide to you in the event of an attack.

Copyright © 2020 IDG Communications, Inc.

Microsoft's very bad year for security: A timeline