Investigating Snort Logs in Incident Response

The cyber security industry is filled with many great options for intrusion detection and prevention solutions for your perimeter. However, there are only a small number of tried-and-true platforms that have become ubiquitous and used as a foundation for other newer platforms. One of the most prominent open-source solutions is Snort. With Snort installed in the environment at the perimeter, a security team can not only forensically see what took place on the network, but also see how it happened. For the purpose of this article, we are going to focus on Snort for intrusion detection analysis. We will be walking through common scenarios that the incident response team will have to investigate from time to time.

Preparing Your Environment

The most important step you can take when using Snort to perform forensics and incident response is to make sure you have at least one instance of Snort capturing full packets in binary mode and saving them in a dedicated location for future analysis if needed. It's also a good idea to have backups of this binary data. Once you have the data stored in binary mode, you can use a tool like Ethereal or WireShark to read the packet captures and save the data that you want to a new file. This may be the contents of an FTP session or the installation of a rootkit, or some other type of important data for analysis.

There are two other keywords that can be used within Snort rules to collect specific data, which aside from sending it to your chosen SIEM or SOAR, should be saved it to a secondary location depending on use cases of interest to your organization and team:

logto:filename

Events that trigger rules with this keyword will be written to a separate file noted below.

Session:printable

Events that trigger rules with this keyword will output all ASCII characters of a connection for example, an HTTP, FTP, or Telnet session to a human readable file.

Data Exfiltration is still an extremely problematic part of data breaches organizations deal with, and still today, protocols such as FTP are still heavily used and leveraged by threat actors to exfiltrate the data out of the organization to their own servers. So, if you are unsure of where to start looking, begin logging and storing FTP and Telnet session data for potential signs of an intrusion.

Also, it is best to have both the binary packet captures as well as the human readable ASCII files for validation and verification purposes.

Incident Response Considerations

Forensics may be performed as part of a larger incident-handling process or part of your honeypot/honeynet analysis. When it is being performed as part of the incident-handling process, it is important to have well-established processes and procedures that are closely followed. More details on incident handling and interacting with law enforcement can be found in the recipes "Snort and Investigations," "Snort as Legal Evidence in the U.S.," and "Snort as Legal Evidence in the U.K." This is important as privacy laws and cyber security reporting laws are rapidly evolving globally.

When dealing with system forensics, you may encounter challenges where attacker tools and programs were deleted from the system. If the attack was remote, the network forensics logs will have a capture of the files being transferred to the target machine and any commands that were given over the network. This is a great fallback method or part of the incident response process in regard to including network analysis to determine the full scope of the breach. Many seasoned responders leverage Ethereal as a tool to follow TCP streams to reconstruct network traffic. An important benefit of network forensics data is that it serves as a backup in a case when the investigation team is unable to recover any evidence from a target machine..

Summary

As we have discussed in previous articles, the key is visibility at each layer. Ensuring your team is collecting the right logs at each layer of your environment can help immensely reduce the dwell time threat actors may have in your environment. While organizations are moving to the cloud and the traditional perimeter is not quite clear, cloud providers such as Microsoft and Google and Amazon have versions of Snort that can be deployed, and those logs should be monitored and used as part of your security team’s overall correlation and analysis.

Stay tuned with our publications as we will continue to explore this topic.


Investigating Snort Logs in Incident Response The cyber security industry is filled with many great options for intrusion detection and prevention solutions for your perimeter. However, there are only a small number of tried-and-true platforms that have become ubiquitous and used as a foundation for other newer platforms. One of the most prominent open-source solutions is Snort. With Snort installed in the environment at the perimeter, a security team can not only forensically see what took place on the network, but also see how it happened. For the purpose of this article, we are going to focus on Snort for intrusion detection analysis. We will be walking through common scenarios that the incident response team will have to investigate from time to time. Preparing Your Environment The most important step you can take when using Snort to perform forensics and incident response is to make sure you have at least one instance of Snort capturing full packets in binary mode and saving them in a dedicated location for future analysis if needed. It's also a good idea to have backups of this binary data. Once you have the data stored in binary mode, you can use a tool like Ethereal or WireShark to read the packet captures and save the data that you want to a new file. This may be the contents of an FTP session or the installation of a rootkit, or some other type of important data for analysis. There are two other keywords that can be used within Snort rules to collect specific data, which aside from sending it to your chosen SIEM or SOAR, should be saved it to a secondary location depending on use cases of interest to your organization and team: logto:filename Events that trigger rules with this keyword will be written to a separate file noted below. Session:printable Events that trigger rules with this keyword will output all ASCII characters of a connection for example, an HTTP, FTP, or Telnet session to a human readable file. Data Exfiltration is still an extremely problematic part of data breaches organizations deal with, and still today, protocols such as FTP are still heavily used and leveraged by threat actors to exfiltrate the data out of the organization to their own servers. So, if you are unsure of where to start looking, begin logging and storing FTP and Telnet session data for potential signs of an intrusion. Also, it is best to have both the binary packet captures as well as the human readable ASCII files for validation and verification purposes. Incident Response Considerations Forensics may be performed as part of a larger incident-handling process or part of your honeypot/honeynet analysis. When it is being performed as part of the incident-handling process, it is important to have well-established processes and procedures that are closely followed. More details on incident handling and interacting with law enforcement can be found in the recipes "Snort and Investigations," "Snort as Legal Evidence in the U.S.," and "Snort as Legal Evidence in the U.K." This is important as privacy laws and cyber security reporting laws are rapidly evolving globally. When dealing with system forensics, you may encounter challenges where attacker tools and programs were deleted from the system. If the attack was remote, the network forensics logs will have a capture of the files being transferred to the target machine and any commands that were given over the network. This is a great fallback method or part of the incident response process in regard to including network analysis to determine the full scope of the breach. Many seasoned responders leverage Ethereal as a tool to follow TCP streams to reconstruct network traffic. An important benefit of network forensics data is that it serves as a backup in a case when the investigation team is unable to recover any evidence from a target machine.. Summary As we have discussed in previous articles, the key is visibility at each layer. Ensuring your team is collecting the right logs at each layer of your environment can help immensely reduce the dwell time threat actors may have in your environment. While organizations are moving to the cloud and the traditional perimeter is not quite clear, cloud providers such as Microsoft and Google and Amazon have versions of Snort that can be deployed, and those logs should be monitored and used as part of your security team’s overall correlation and analysis. Stay tuned with our publications as we will continue to explore this topic.