Within the first two installments of this series, we identified the key to successful incident preparation starts with making sure a solid incident triage process is in place, centralized analysis documentation is created, and the incident communication cadence has been solidified. This, in conjunction with a well-oiled rapid triage Windows artifact processing plan, allows analysts to simultaneously process new artifacts while seamlessly analyzing the resultant output. If you missed Part 1 or Part 2 of the series, you can catch up on them here.

In Part 3 of this series, we will take a look at a non-exhaustive list of network analysis goals, pivot into the processing of acquired incident network data, and explore the various tools that are available to assist with carving network logs or provide additional telemetry to aid in the investigation.

Network Analysis Processing Steps

OK, now how about the network side of the house? How can this additional analysis be streamlined to complement the complex volume of Windows system analyses outlined above?

Organization network telemetry and logging verbosity will vary significantly, so the focus should be on identifying where this network data resides and how much log retention the analyst will have to work with. The next considerations to factor in will be whether it makes more sense to ingest network raw log output into a local SIEM or to manually parse the raw log data.

During these processing steps, the goal should be to identify suspicious activity surrounding the following areas:

• C2 communication
• Attacker tool or malware download
• Outbound tunneling
• Data exfiltration

Note: This is not a full list to focus on but should be used to build from, which will provide guidance surrounding network log analysis goals and objectives.

The following steps should be followed for the analyst to reference to achieve rapid triage of network tool output. As stated above, network analysis can be performed in parallel with the system analysis so the analyst can keep their investigation moving forward without stalling their forward momentum and waiting for each step to finish.

Below, I will outline the logging sources that are typically called upon to uncover network layer treasures and identify parsing options available.

Note: An analyst may not have any network indicators to pivot from initially, so this step may be a bit of a grind to find that sparkling IOC in the mountain of network log output.

Firewall Log Processing

Firewall logs will most likely be the only network logs an analyst will have to work with. This network security device should provide all necessary network layer visibility (protocol, port, and source/destination IP addresses), since all traffic inbound and outbound of an organization should traverse through this device.

When dealing with raw firewall logs, a local VM built as a SIEM can alleviate a lot of the manual efforts of raw log parsing. An analyst can take the raw logs and import them, which will provide the benefit of visual telemetry and the ability to use query analytic capabilities to quickly carve through the large volume of log data.

Two of the most common solutions to use in this scenario are:

• Splunk
• ELK stack

If the need arises to manually parse raw firewall logs, Sift, a grep-like tool, comes in handy. This can be used to quickly search for IOCs across raw logs.

DNS Log Processing

The domain name service (DNS) translates domain names to IP addresses. These logs are critical during network analysis. Since many public websites or domains resolve to a single virtually hosted IP address, it becomes extremely important to be able to analyze logs that contain the actual URL/URI that have been requested.

DNS logs will generally provide the following information:

• Queried domain name
• Source IP address
• Record requested
• Request flag

If Windows DNS logs are available, an analyst can follow the steps within the Windows Event Log Processing section. PowerShell may be required to take care of some of the additional parsing requirements of the DNS log, though.

If dealing with *nix-based DNS logs, an analyst can follow the steps outlined in the Firewall Log Processing section.

Proxy/Web Filter Log Processing

A proxy server acts as a gateway between a user and the websites they may browse and has the ability to filter these requests based on deployed firewall and web filtering policies.

Web filtering is a technology that inspects user web-based traffic and can prevent the viewing of certain URLs or websites by blocking the browser from loading pages from these sites.

Note: Both technologies will contain data similar to that contained in DNS logs, but not all organizations have these particular technologies deployed.

If dealing with raw proxy/web filtering logs, an analyst can follow the steps outlined in the Firewall Log Processing section.

In some cases, organizations may have a cloud-based web filtering solution deployed. An analyst will need to request access to the tool. If this is the case, an analyst will have additional visual telemetry to drill into.

NetFlow Log Processing

Ah, the glory of having the benefit of NetFlow data! NetFlow is a network protocol system that collects active IP network traffic as it flows into or out of an interface. The NetFlow data is then analyzed to create a picture of network traffic flow and volume. NetFlow data provides a significant amount of detailed network telemetry, which will provide a great deal more information than standard firewall logs. It is rare to have this available during an incident, so jump for joy if you are so fortunate.

NetFlow network telemetry provides the following critical information:

• Packets in/out
• Interface
• Protocol
• Port
• Application
• Source/destination IP addresses

The analysis of these logs will follow the same process explained in the firewall log processing section.

PCAP Processing

OK, so you thought NetFlow was the unicorn of network telemetry to come across—well, think again. Packet capture (PCAP), a goldmine of data, is the lowest-level output of network telemetry. Unfortunately, due to the data storage requirements, it is one of the hardest network artifacts to maintain.

If an analyst is fortunate enough to have PCAPs available, there are a number of excellent tools that can be utilized to automate the parsing of the imported PCAP files.

For general viewing and parsing, the following tools can be used:

• Wireshark is the de facto GUI tool to filter and gain visibility into a PCAP file.
• TShark is the command line equivalent tool to Wireshark.

Brim can be used to add some flavor to Zeek processing without using a standard implementation of Zeek. Brim provides Zeek-formatted output and a very robust query language to carve through the PCAP, but it also provides the capability to pivot into Wireshark, if the need arises.

To add some automated processing of imported PCAPs, the following tools can be used to provide additional security alerting and visual telemetry. These will require specific local VMs to be built.

• Arkime
• Security Onion

Tool References

Network Analysis Tools

• Arkime
• Network Miner
• Brim
• Wireshark
• TShark
• Security Onion

Local SIEM Tools

• Splunk
• ELK

Series Conclusion

Incident Response rapid triage is a crucial component of any effective Incident Response plan. By quickly identifying and prioritizing threats, it allows an organization to respond rapidly and effectively, minimizing damage and downtime.

The key to successful triage is having the right tools and processes in place. Whether it's automated tools that can quickly sift through vast amounts of data or a well-defined Incident Response playbook that outlines clear steps to take in different scenarios, having a solid triage strategy can make all the difference.

Of course, no amount of planning can fully prepare you for every incident, but having a strong foundation in place can help you respond more confidently and efficiently.

In the end, it's not a matter of if an incident will occur, but when. And when that time comes, hopefully this Incident Response Rapid Triage Pocketbook will be a trusted resource. So keep calm, stay alert, and commence with the DFIR warrior mindset!

@H3dTr1p