Notes from the Field. Using Proxy Logs to Detect Suspicious Activity – Interview with Aaron Hambleton.

The job of a Proxy is to provide a gateway between the users and the internet. A good quality, well configured Proxy assists in keeping users and the internal network protected from the nefarious content published and accessible on the internet.

‘If you’re like most people, you probably associate proxy servers with unblocking Netflix content from other countries or staying a bit more secure on an open WiFi network. The reality, however, is that proxy servers do much more — and are especially vital for businesses.’ – RJ Prego (CMSWire)

All network traffic flowing out of the network should be passing through a Proxy, and the logs typically provide a rich repository of meta data. This inherently makes Proxy logs a great resource for Threat Hunting.

What Data Can Proxy Logs Give You?

Proxy logs contain a lot of valuable data which can be used for detecting suspicious activity. Listed below are some examples of what data can be extracted from the logs, and this list is just the start.

Detecting Suspicious Network Traffic with Proxy Logs. Real-Life Example

SecurityHQ’s team of security experts routinely hunt for suspicious and potentially malicious activity in our customer networks. During a recent investigation, Aaron Hambleton, one of SecurityHQ’s Security Monitoring and Incident Response Leads, identified an unapproved third-party management application installed on a Domain Controller routinely beaconing to a suspicious URL.

Aaron leads a 24/7 Security Operation Centre in the Middle East. With 10+ years of experience in cyber security, he has worked in Financial Services, Retail, Insurance, Government, and Telecommunication industries as a security consultant and incident response analyst.

Aaron is a GIAC certified Defence Analyst with extensive knowledge in Security Blue Teaming, Incident Response, Cyber Security Operations, Cloud Security, and Cyber Security consultancy in an advisory capacity.

Aaron, can you provide some context and analysis of what happened in this example?

Aaron: “Well, to start the analysis, I extracted the proxy logs from SIEM. For me, raw data is much easier to manipulate and pivot with. Once I had the logs I wanted to check for any anomalies like strange User Agents, request methods, and potentially suspicious file download requests.

I will typically focus on the least common events first and then pivot when I find something interesting.

In this case, I observed that a single Domain Controller was having frequent outbound connections to a suspicious URL with a PowerShell UserAgent. This isn’t normal behaviour and given the criticality of the server and the fact that this behaviour was observed on no other servers, I decided to dig further.

Here you can see the detected Powershell UserAgent initiating the outbound network traffic.”

What did you do next?

Aaron: ‘Next, I focused on the Domain Controller itself. I wanted to get an idea of what was happening on this server. Using an Endpoint Detection & Response (EDR) tool I was able to analyse all PowerShell processes on the Domain Controller which were having outbound network connections towards the IP identified in the Proxy logs. My analysis revealed that PowerShell was being used to call and execute a script in order to initiate the connection.”

The command line parameters for script execution are shown below. (Sections in black redacted for confidentiality).

What did you do with this information?

Aaron: “Once I had identified the script being used to initiate the outbound connections, I was able to download a copy of it from the server and review the code contained inside. Reviewing scripts and code is an important step in investigating suspicious activity, it really helps as an analyst to understand what a script is attempting to execute”

Below is a code snippet taken from the script

For those less proficient in coding, what is noticeable about this?

Aaron: “After reviewing the script, I noticed that there was a URL defined in a variable named $WebCheck. The URL contains a path to a .txt file. When the script executes, it uses the Invoke-WebRequest PowerShell ‘cmdlet’ to download the file from the URL defined in the $WebCheck variable.

In this particular case, it transpired that I had discovered a third-party administration tool on a Domain Controller which was not part of the organisations approved software list. We often refer to these tools as a Potentially Unwanted Program or PUP for short.

Adversaries have previously demonstrated that they will target third party administration and management tools. In this example there was a real risk that the genuine file being downloaded by the script could have been replaced with a malicious binary or script, paving the way for a potentially devastating attack.”

Why are these called ‘Potentially Unwanted Program’? Surely, elements that flag up as potentially unwanted are all either unwanted or malicious?     

Aaron: “Good question. Potentially Unwanted Programs (PUPs) are not malware. ‘The main difference is that you give consent to download the PUP, even though you might not know about it if you didn’t read the agreements or installation process thoroughly.’ (McAfee)

Some PUPs can contain spyware including keyloggers, and other software to gather your information. Even if the PUP doesn’t have any malicious content, they can slow down a device by consuming disk space on a device and it can weaken a device’s security, making it more vulnerable to malware.”

What do you suggest to organizations wanting to avoid such an event?

Aaron: “Having strict controls in place surrounding software installation on endpoints and servers is the first step in preventing these unwanted applications making their way into an organisation. There are a few basic steps an organisation can take to prevent this:

1. Use AppLocker or a similar product to stop unauthorized applications running within the environment. With AppLocker you can create rules to allow or deny applications from running based on unique identities of files and to specify which users or groups can run those applications.
2. Restrict the permissions of users to prevent them installing software without following the correct process.
3. Ensure that you have comprehensive endpoint security software which can detect PUPs and remove them remotely.

Thank you, Aaron.

If you have a question or would like to try our Managed Detection and Response service, contact us here.