Network Excavation: Going Beyond What Your Existing Tools Can Tell You
By Joel Esler, VP of Threat Research
Netography Fusion’s unique ability to combine on-premises traffic flow via NetFlow and sFlow, as well as flow traffic from each of the major cloud providers such as Amazon Web Services (AWS), Google Cloud Platform (GCP), Oracle Cloud, and others, provides the unparalleled ability to hunt through data quickly and efficiently. Need to observe and secure how your traffic is flowing between cloud providers? Done. How about traffic between your on-prem infrastructure and the cloud? Done. How about traffic between either one of them and the internet? Done. Simple hunting in data, as powered by our easy-to-use Netography Query Language (NQL) is a powerful tool in any security or network practitioner’s arsenal.
In this blog post I’m going to show you a couple of recent techniques that our Threat Research Team uses to identify malicious traffic on a network and use that information to develop new strategies and Netography Detection Modules (NDM) for customers, as well as alerting customers to issues found on their network so they can take immediate action.
The Netography Threat Research Team was formed with automation, proactive research, and machine learning in mind. We ask ourselves, “How can we develop new detections and proactively defend customers without having to dedicate hundreds of people and hours of resources to each individual threat?” \ I have worked on those teams in my former roles, and I have seen how that sausage is made. While I have seen the effectiveness of those teams, we wanted to reimagine and drive a more effective approach for an increasingly encrypted world.
Our recent addition of context labels enables both our team and customers the ability to visualize their traffic in ways they have never seen before. Let me provide a couple of recent examples where this has proven to be a powerful capability.
Context Labels in Action
Following the rollout of our context label feature, a customer immediately enabled this functionality to pull information from their AWS infrastructure. Enabling this functionality allows the Netography Fusion portal to pull information from AWS, such as CPU, OS, region, instance type, and many other features. In this example however, the customer makes extensive use of aptly named security groups: Production, Staging, Development, “Elastic Search”, and so on. Providing the easy capability to stop thinking about visualizing and securing things in terms of “IPs”. Soon after the customer turned this feature on, our Threat Research Team was able to write simple NQL queries that enabled the customer to alert on traffic that should not have been flowing between their production environment and their development environment. Being unable to see this traffic within their cloud before Netography was leaving this customer blind.
While the NQLwas specific to the customer environment’s security group name, it was no more complex than a simple query:
label.ip.securitygroup == production && label.ip.securitygroup == development
Context labels are valuable tools to be able to isolate traffic. Have a machine that is connecting outbound when it shouldn’t? External IPs connecting to your elastic cluster when they shouldn’t? These are things that traditional solutions, such as intrusion detection systems (IDS) and endpoint technologies, would not be able to highlight. This is non-malicious traffic by nature, so an IDS would not alert on it; it’s simply traffic that shouldn’t exist in the first place.
Spelunking in Data
Identification of applications, operating systems, and services, and even finding open ports is easily achievable through monitoring traffic with Netography. Nearly any product that uses a cloud-based service can be identified through “beacons”, or regular communication with their cloud component. A super easy example is: looking for Apple devices on specific ports that communicate with the 17.0.0.0/8 block of IPs, for example. A more specific use case in threat hunting would be looking for traffic that shouldn’t exist. Traffic that wouldn’t be identified as malicious by standard network control devices (such as an IPS or Antivirus), but shouldn’t exist at all. For example, network and endpoint devices doing things they shouldn’t do as part of their normal behavior. Why is that server running a service on a non-standard port? Why are IPs on the internet communicating with that service?
Here is a quick example query for using the power of visibility into your network traffic:
`((protocol == tcp || protocol == udp) && srcport < 1024 && dstport < 1024 && !(srcport == 0 || dstport == 0 || srcport == 123 || dstport == 123 || (srcport == 67 && dstport == 68) || (srcport == 68 && dstport == 67) || (srcport == 67 && dstport == 67) || srcport == 137 || dstport == 137 || srcport == 138 || dstport == 138 || (srcport == 53 || dstport == 53) || (srcport == 514 || dstport == 514)))`
This NQL statement is looking for traffic that originates from below port 1024 to other machines below port 1024, excluding common things like DHCP, Netbios type traffic, syslog, DNS,, and NTP. While this will still show things on the network like SunRPC calls, in our experience it has highlighted some very interesting traffic that shouldn’t exist that existing legacy technologies wouldn’t highlight. Customers have reported that Netography surfaced several unauthorized VPN connections from both mobile and desktop endpoints. While a VPN can secure traffic crossing the internet, using a non-corporate VPN on your corporate network moves beyond just a policy violation and into “malicious threat” territory.
Conclusion
Need to verify if your security groups in your cloud environments are set up correctly? Need to see if your database is communicating with IPs that it shouldn’t? Do you need to be alerted automatically if situations like these occur? With the extremely flexible nature of NQL and our NDMs, nearly anything is possible when securing your Atomized Network with Netography.