[This is a Guest Diary by Alex Sanders, an ISC intern as part of the SANS.edu BACS program]

Introduction

As an offensive security professional, it is often part of my job to stand up infrastructure that is intentionally malicious and must be exposed to the internet. Examples of this could include Evilginx, Cobalt Strike, or proprietary offensive infrastructure. One of the problems with this however, is the need to remain undetected while conducting an operation. In the modern era, there are numerous companies launching automated scans against the entire internet to try and identify malicious infrastructure as quickly and accurately as possible. Some of these sensors have reached my infrastructure within moments of its exposure to the internet. In the case of a phishing campaign where a user has clicked a link to visit your malicious site, this will cause your domain to present an alarming screen to an end-user such as the one below:

To prevent your infrastructure from being marked as malicious or added to an IOC list, you can always utilize a blacklist and block all traffic from these sensors. Therein lies the problem; what do you block? Some organizations, such as Microsoft, will publish lists of their infrastructure and their roles, which is included in popular guides for protecting offensive tooling such as Evilginx. However, most organizations that curate threat intelligence don’t do this as it gives attackers an easy win. Luckily for us, some of these organizations will include information about themselves within their network traffic so that administrators and analysts don’t waste time trying to discern these sensors from malicious traffic. One such example that has been observed is GCore Labs. While reviewing non-standard user-agent strings in web requests to my honeypot, I found that between November 9th, 2024 at 02:56:19.089 and November 16th, 2024 at 08:49:46.871 10 different addresses scanned for a web-root “/” directory 1,056 times, with the peak of this activity occurring on November 11th.

Each request contained a string within the user-agent header labeled “GCore Labs Cyberthreat Research”.

Performing a google search for “GCore Labs Cyberthreat Research” results in a knowledge article for threat hunting from GCore Labs. Further review of the results shows a listing for this user-agent on a site called Udger. This organization has not only seen similar traffic, but provides useful information such as whether traffic with this user-agent is currently active, and all observed origin IP addresses.

Identifying Non-Standard User-Agent Strings

Let’s start with getting a list of unique user-agents from our web honeypot logs with:
 `cat /srv/db/webhoneypot-*.json | jq .headers | jq '.["user-agent"]' | sort -u >> user-agents`
From here, we could analyze this data several ways, however I’ve chosen to pick strings from common user-agents and, using egrep, exclude lines matching those strings using:
 `egrep -v '^"(curl|Mozilla|Wget|python-requests|Opera|Hello|firefox|Mozila)/' user-agents`

This results in a much easier to parse list of strings. Most of these, while odd, are still legitimate user-agents. However, in this particular dataset, we can see that the honeypot has been scanned by Palo Alto’s Expanse sensors. Though this Expanse is used to identify Palo Alto customer threat surface, and therefore not useful for our intended purpose, this demonstrates how one could identify any self-reporting threat intelligence sensors.

Operating With Collected Data

As your team identifies scanners and their associated IP addresses, this information can be stored in a private repository and leveraged as part of build scripts for your red team infrastructure. One could either block requests entirely using iptables, or perform a specific action when scanned by an IP in the list such as serving up a dummy-page or a redirect.

[1] https://endpoints.office.com/endpoints/worldwide?clientrequestid=b10c5ed1-bad1-445f-b386-b919946339a7
[2] https://github.com/aalex954/evilginx2-TTPs#ip-blacklist
[3] https://gcore.com/learning/cyberthreat-hunting/
[4] https://udger.com/about-us
[5] https://www.sans.edu/cyber-security-programs/bachelors-degree/

-----------
Guy Bruneau IPSS Inc.
My Handler Page
Twitter: GuyBruneau
gbruneau at isc dot sans dot edu