Squid Proxy with SOF-ELK Part 2 Analysis

Firstly, I’m happy to report that I received a SANS SEC530 Red Challenge Coin for submitting a blog post that builds upon the SEC530 course subject matter for Squid Proxy with SOF-ELK Part 1. Thank you very much Justin Henderson and Ismael Valenzuela for the coin.

Analysis

In this post I wanted to go a little deeper into how to analyse Squid logs collected in SOF-ELK and develop some potential security use cases. 

In Part 1 we configured Squid to use OpenDNS Home edition to block access to sites that were undesirable such as Gambling site and sites known to serve Malware. We also configured Kibana to show meaningful block codes rather than just the IP address that OpenDNS redirected them to when a user visited a blocked site. From the users perspective they will see a blocked message from OpenDNS like this:

On SOF-ELK we can see the details of the block browsing as shown here:

We can use the block type to create a visualisation to examine which type of block is prevalent by user:

This shows that Andy has been blocked going to two different known phishing sites and Content blocking based on categories such as Gambling and Social Media is working as configured. If there were any this visualisation would also show a different graph for each of the OpenDNS Block Types

• Domain List Block Page
• Command and Control Callback Block Page
• Content Category Block Page
• Malware Block Page
• Phishing Block Page
• Suspicious Response Block Page
• Security Integrations Block Page

This is useful for understanding user behaviour and could help determine the presence of malware on users computer. 

As we set up unauthenticated access rules for software updates we can view the utilisation of those rules in Kibana showing which systems have been updating regularly against which update sources.

acl ubuntu dstdomain .ubuntu.com .draios.com .mongodb.org .dockerproject.org osquery-packages.s3.amazonaws.com pkg.osquery.io ppa.launchpad.net .docker.com
acl ubuntu_servers src "/etc/squid/ubuntu_servers.txt"
http_access allow ubuntu_servers ubuntu

acl windows dstdomain .windowsupdate.com .microsoft.com .digicert.com .verisign.com .adobe.com .s-msn.com .live.com .msftncsi.com
acl windows_hosts src "/etc/squid/windows_hosts.txt"
http_access allow windows_hosts windows

Other browsing activity that is Denied because the user is not authenticated is shown as TCP_DENIED in the Cache_Result field as shown here. These messages show the cache_user field as containing a ‘-‘ . Some of these are normal as the browser will attempt to load some content prior to requesting the user authenticates. 

User Agent Profiling

The user agent string is used to identify the browser so that content can be rendered appropriately for different browsers, however, it can be used to identify activity from malware and attackers. 

Looking first at the diversity of user agent using a simple data table in Kibana shows the full range of user agents observed. It’s worth having a look at the lower numbers, the more unusual of them as these may show faked user agents that standout against the backdrop of normal activity. 

This shows unauthenticated denied attempts to access domains broken down by user agent string. While there is nothing unusual shown it could be useful to identify a specific user agent that is attempting to connect to a domain without explicit authentication having taken place. 

In this view we can see user agent strings and the stacked-bar shows various destinations third-level domains destinations. General browsing stands out as multi-coloured bars and single-use user agents show up as solid colours. This can be useful for spotting unusual activity particularly at low volumes. 

Windows PowerShell

Using a browser to access the internet requires the user to authenticate and this is the same for using PowerShell at the command line. Requiring explicit authentication can stop malware from connecting to C2 and thus reduce the chances of any further harm occurring. Finding these using Kibana will allow Incident Responders to triage compromised hosts. 

As can be seen here an attempt to use PowerShell to access the web fails with an ‘unauthorised’ message directing the user to authenticate before it would be allowed.

The Squid proxy log shows these attempts to access www.google.com as TCP_DENIED without a cache_user and without any user agent string. 

We can authenticate on the command line to allow access via PowerShell:

$Creds=Get-Credential
$proxy = New-Object System.Net.WebProxy
$proxy.Address = [uri]"http://squid:3128"
$proxy.Credentials = $Creds
[System.Net.WebRequest]::DefaultWebProxy = $proxy
Invoke-WebRequest -Uri "https://www.google.com"

Once PowerShell has authenticated it can make connections out via the proxy. If we look at this simple example of connecting to google.com it shows up in Kibana with a user agent string Mozilla/5.0 (Windows NT; Windows NT 6.3; en-GB) WindowsPowerShell/4.0 and the cache_user is shown (heathcliffe).

As attackers commonly use PowerShell to establish an outbound connection for C2 or to transfer data the requirement for explicit authentication means this becomes more difficult to achieve and easier to identify it in SOF-ELK. It should be noted that it is possible to change the User Agent string:

[Microsoft.PowerShell.Commands.PSUserAgent].GetProperties() | Select-Object Name, @{n='UserAgent';e={ [Microsoft.PowerShell.Commands.PSUserAgent]::$($_.Name) }}
$userAgent = [Microsoft.PowerShell.Commands.PSUserAgent]::Chrome
Invoke-WebRequest http://blog.infosecmatters.net -UserAgent $userAgent 

 

IP address instead of hostname

One way that a user might try to bypass the content filtering is to find the IP address of the web site that is blocked and enter that directly into the browser. That’s why one of the enrichments I added to the logstash input is set ip_host to true when the dst_host is an IP address. This allows us to examine any proxy connections that attempt to bypass the content filtering in place from OpenDNS.