Detecting Outbound connections Pt. 3 – Microsoft IPs & Private IPs

At this point you’re still excited about logging any outbound connections made by your endpoints, specially knowing exactly “what” made those connections (.exe, .dlls, .tmp, etc..) because of Sysmon. Now that you have some threat intelligence added to your external IP addresses you also feel more comfortable about detecting known bad IPs in a timely manner; however, what about those NOT known? we still need to keep our eyes open for any external connections and review them.

Windows Systems = Chatty/Noisy systems

As you go through the tuning phase for Sysmon and adding fancy advanced filters you’ll realize that the Windows Operating system is very chatty in terms of outbound connections to Microsoft IP addresses. As soon as you launch Word, Excel, Skype, etc.. You will often see a callback to one of their IP addresses which can get very chatty in your log collector. This will make it a bit more challenging when reviewing your “outbound connection logs” as 30% of your endpoint network traffic will be contacting a Microsoft or AWS IP address. This will take up quite a bit of time in your daily routine and soon you’ll either get too lazy, or overwhelmed.

What do we do?

You could say: Easy! just exclude those processes (Winword.exe, excel.exe, AcroRd32.exe, etc..) from Sysmon and don’t log them, which would reduce the amount of overall logs; however, I think it’s always best to LOG everything and filter later as needed in our Splunk,ELK,Graylog,SIEM dashboards, or better using our Log parser such as Logstash.

A better approach:

First, let’s note exactly what we want to accomplish and then come up with a solution:

• Log all outbound connections from our endpoint processes: We are already doing this via Sysmon)
• Allow an easier way to filter out Microsoft IP addresses: We will be creating a “IPDestination: Microsoft” field to allow filtering using Logstash.

Considerations:

• Microsoft IP addresses will still be available for review. (Malware tends to contact Microsoft or Google (8.8.8.8) IP addresses to test outside connectivity)

Before we move on to the actual steps, let’s discuss one of the Logstash plugins we will be using called CIDR. The CIDR filter is for checking IP addresses in events against a list of network blocks that might contain it.
Multiple addresses can be checked against multiple networks, any match succeeds. Upon success additional tags and/or fields can be added to the event.

As far as Microft IP addresses, a quick googling led me to the following sites [1] Microsoft Public IP Space and [2] MS Azure Datacenter IP ranges. These are the public addresses that Microsoft owns and will provide with most IP ranges for their IP space. Review them and verify for yourself before copying/pasting them (A good resource to test with is who.is )

After you feel confident with verifying the IP addresses, let’s move on!

Actual steps:

1. Install the CIDR Logstash Plugin
2. Add Logstash configuration for Microsoft IP addresses
3. Additional Actions

1. CIDR Plugin Installation

Navigate to /usr/share/logstash and run the translate plugin install

cd /usr/share/logstash/
bin/logstash-plugin install logstash-filter-cidr

you should see a “Installation successful” message if it was downloaded successfully.

2. Add Logstash configuration

Navigate to your logstash configuration which should be in located /etc/logstash/conf.d and edit your current configuration (My logstash configuration is called winlogbeat.conf ). For this use-case I am using my sysmon network outbound connections; however, you can always use your ASAs, or other firewall logs.

nano /etc/logstash/conf.d/winlogbeat.conf

filter {
  if "winlogbeat" in [tags] and [log_name] == "Microsoft-Windows-Sysmon/Operational" and [task] == "Network connection detected (rule: NetworkConnect)" {
cidr {
    add_field => { "IPDestination" => "Microsoft" }
    address => [ "%{[event_data][DestinationIp]}" ]
    network => [ "13.104.0.0/14",
"13.64.0.0/11",
"13.96.0.0/13" ]
 }
}
}

For the example above, I added 3 IP subnets (13.104.0.0./14, and 13.64.0.0/11, and 13.96.0.0/13); however, you can add as many as you’d like (here’s the full configuration text file)

Save your configuration changes (CTRL + O)

Lastly, restart Logstash:

service logstash restart

What did we do? We are using the CIDR plugin to add a new field called [IPDestination] if the [event_data][DestinationIp] IP value matches our CIDR IP range list. If our applications are making a callback to any Microsoft IP or IP range we added in this list, then a new field called IPDestination with the value of “Microsoft” will be created.

As new events get generated, you should now be able to filter your records by the new field name “IPDestination: Microsoft” and get an idea of the amount of outbound connections made and which processes make those connections.

Here’s a good example of an unexpected executable calling out.
C:\Windows\SysWOW64\SearchProtocolHost.exe

If you look online, you’ll find articles similar to this one explaining what the purpose of this process is and why it connects outbound. Once you realize that these are “normal” outbound connections, then you may “filter out” (image below)  by this field name and focus on Non-Microsoft IP addresses. You’ll be surprised how much cleaner your results will be, and hopefully you won’t find any interesting C&C outbound connections.

3. Additional Actions

At this point, you were able to add most Microsoft and known IP ranges that you want to exclude in your searches. As I mentioned before, Malware does attempt to connect to Microsoft IPs and public DNS services such as Google’s initially; however, if you want to keep your logs leaner and save more disk space, then you may drop all of these connection logs by adding the following filtering rule. (Repeat step 2 and add this below the CIDR configuration)

#Drops Microsoft IPs
filter {
  if "winlogbeat" in [tags] and [IPDestination] == "Microsoft" {
  drop { }
}
}

This will drop any log containing the field name “IPDestination: Microsoft“.

As I mentioned before, I wouldn’t recommend this, but if you have valid use case then go for it.

Additional Use case: Private Network (Private IP addresses)

As you will come to realize, most of your endpoint connections will be internal (DNS, LDAP, KERBEROS, etc..) and will add a bit more noise when trying to identify malicious outbound IP addresses.With this in mind, we may also use the CIDR filter to filter out your Private network connections.

Repeat step # 2, and add the following:

cidr {
    add_field => { "IPDestination" => "Private" }
    address => [ "%{[event_data][DestinationIp]}" ]
    network => [ "192.168.0.0/16", "10.0.0.0/8", "172.16.0.0/12"]
  }
}
}

At this point this is self explanatory, and I hope you find this useful as it does help to identify external outbound traffic easily, specially when using tools such as Splunk or ELK.

I would also highly suggest NOT to drop this traffic as you will be blind to lateral movement and other internal attacks that might happen if your network is already compromised.

Final Notes:

• You may add other use cases (Vendor IP addresses, etc) and create CIDR notations based on this.
• Cloud services such as AWS and other Load balancer services will not be friendly. For this, leverage your Layer 7 firewall or web-filter to correctly identify the destination services.
• GeoIP + Known CIDR Filtering + Threat Intel = Greatly assists with spotting unknown connections.

I’ll continue with this series once I finalize my thought process. Any questions feel free to send them over via twitter.

For now Read Part 2

Thank you.