This article explores incident response investigations using proxy logs to uncover security gaps in email filtering.
As part of the ongoing series, we have been discussing the value and criticality of ensuring the correct logging and visibility is available within an organization. This way, if and when an incident occurs, the incident response team can utilize the logs to identify what happened and how. In the last installment, we discussed investigating a suspicious email, whether it is a phishing email, business email compromise, or otherwise.
Despite the advances in technology, many government organisations and organizations, including financial services, insurances, manufacturing, health and many others still struggle with their email filtering and security solutions. One of the primary gaps those in incident response come across is the lack of logging available to determine if someone clicked on an email or visited a link sent via email. The good news is that despite the gap in email logging, the incident response team has different options to try and pivot and determine whether or not a user did click on a link and potentially how many across the organization may have clicked.
The main caveat is, unless users that work remotely are configured to have their traffic flow through a corporate VPN (virtual private network) or have an agent deployed on their endpoint that captures traffic to the internet, then investigators may only be able to capture users on the company network.
Having said that, the initial data source for this investigation if the email security solution does not have the data needed, then security teams should investigate the proxy servers, which acts as a gateway in a corporate environment and processes internet requests outside the company. What can these logs show us either via a SIEM or in raw format? Once you have the logs in hand, what you look for are the user agent, request methods, and especially when it comes to email, suspicious file downloads. User agents are like the web browsers people use to browse the internet such as Firefox, Chrome, Internet Edge, etc.
Focusing on outliers from normal browsing traffic can help you quickly identify anomalies such as GET PowerShell requests from external websites.
Once the above information is gathered, the incident response team can determine how many users have been impacted by reviewing the logs, and then move into a containment phase where they isolate the compromised machines and scan them for malware, as well as remediate any infections that are found.
In the next articles of this series, we will focus on other components of the security stack and how they interact to help incident response teams identify the full scope of an issue and how to remediate it.