Hey folks,
This is another quick post. On Wednesday, we made some significant improvements to our “External IP Lookup” service rules.
Many of these newly added rules were sourced directly from Sigma. If you’re not familiar, sigma is somewhere between Suricata for IDS logs, and a Rosetta Stone for applying those rules as search queries for a variety of different SIEMs. This is the rule took a closer look at. While we had coverage for most of these Domains and/or TLS SNI, most doesn’t mean all. So we fixed that on Wednesday. But why does this matter?
Significance
So, why should you care about this class of information rule in the ET INFO category? Because looks can be deceiving, and these rules can serve as a warning that malicious activity is about to, or actively taking place. I briefly mentioned them in a webinar
I did with OISF earlier this year.
External IP Lookup services, as the name implies, usually is a web service that can be as simple as just returning a single plaintext line with the client’s public IPv4 (or sometimes, IPv6), or could include geolocation data, ISP information, latitude and longitude, browser information, etc. Compare eth0.me to something like, ifconfig.io. Both of these are external IP lookup services.
These services in and of themselves aren’t inherently malicous, but they are harbingers of malicious activity, or at a minimum something that might constitute an invasion of privacy.
Where and Why These Services are Used
In common cases, a user might need to know their public IP because they want to share data with friends, play an online game together, etc. In other cases, these services might be a part of “telemetry” gathered from installed software that can be used to track what users are utilizing a service or software application, and where they are from, for tracking usage metrics. But we also see plenty of cases where connections to these services are the first steps of a malware infection chain.
Why are the bad guys interested in this data? In some cases, threat actors may wish to avoid infecting hosts from specific regions. This is called geofencing. In other cases, connections to these services are used as a very basic anti-forensics check, making sure the infected host has internet access. If the service returns a valid response, then the malware continues execution. If not, execution is halted. And yet, in other cases, the malware developers just want to know where a host is located, and its public IP address.
This information is then communicated back to the Command and Control, somehow. Maybe through direct HTTP/HTTPS/TCP/UDP connections, Maybe via an uploaded zip file like with common information stealers, or popular messenger services like Discord, Telegram, etc.
So, we’ve created rules for a wide number of these services, keeping in mind that they are frequently used with a wide variety of malware families. Because in some cases, if we do not have rules for a particular malware family, or creating detection for certain malware families would prove to be very difficult or impossible, seeing these alerts gives analysts a fighting chance to detect a malware campaign very early on, especially if the given external IP lookup service is not typically used in that network. When that’s the case, further investigation is recommended into the events leading up to the alert triggering, as well as activity after the lookup as occurred.
Where do I look for these rules?
These rules are in the ET INFO category. Using your favorite rule management tools (Or… grep, I just use grep), consider searching for “External IP Lookup” in the msg field. The vast majority of these rules are DNS driven, as well as TLS SNI driven and come with all of the strengths and weaknesses these detections have, but they are still very valuable for threat hunting.
We need you
Is there an External IP Lookup service that isn’t covered in the ET ruleset? Consider dropping us a line here to let us know.
As always, happy hunting,
-Tony Robinson