In the Black Hat Asia 2025 NOC, Shaun staffed the morning shifts, and Aditya the afternoon shifts as usual. Unlike the earlier years, both hunters had plenty of rabbit holes to down into leading to a place of “involved joy” for both.
Activities involving malware what would be blocked on a corporate network must be allowed, within the confines of Black Hat Code of Conduct.
Fishing With Malware: Who Caught the Fish?
It all started with unusual network activity originating from a device in a lab class. Doesn’t it always?
“Look beyond the endpoint.”
A saying that comes to life daily at Black Hat
That said, a device was found connecting to a website flagged as suspicious by threat intelligence systems. Next, this website was being accessed via a direct IP address which is quite unusual. And to top it all off, the device exchanged credentials in clear text.
Sounds like your typical phishing incident, and it raised our hunters’ eyebrows. The initial hypothesis was that a device had been compromised in a phishing attack. Given the nature of the traffic — bi-directional communication with a known suspicious website — this seemed like a classic case of a phishing exploit. We utilized Cisco XDR to correlate these detections into an incident and visualize the connections involved.
As is evident from the screenshot below, a detection from Corelight OpenNDR for possible phishing kicked this off. Further investigation revealed similar traffic patterns from other devices within the conference hall, this time on General Wi-Fi network as well.
The destination for all of them, 139.59.108.141, had been marked with a suspicious disposition by alphaMountain.ai threat intelligence.
Thanks to the automation implemented to query Umbrella Identities, the device’s location was quickly confirmed to be within the Advanced Malware Traffic Analysis class. The hunters’ used this function every single time to such effect that it was decided to automate this workflow to be run and response obtained for every incident so that the hunters’ have this data ready at hand as the first step while investigating the incident.
Next step, our threat hunters as expected dived into Cisco Splunk Cloud to investigate the logs for any additional context. This investigation revealed important insights such as the traffic from the device being in clear text, allowing the payload to be extracted. This discovery was key because it revealed that this was not a typical phishing attack but part of a training exercise.
Additionally, it was discovered several other devices from the same subnet were also communicating with the same suspicious destination. These devices exhibited nearly identical traffic patterns, further supporting the theory that this was part of a lab exercise.
The variation in the traffic volume from the different devices suggested that various students were at different stages of the lab.
Lessons Learned: The Lost Last Part of PICERL
Being able to adjust what is presented to an analyst on the fly is one of the most fun parts of working events. In many organizations, “lessons learned” from an incident or cluster of events are reviewed much later if at all, and recommendations enacted even later.
In the Black Hat event environment, we are consistently looking for improvements and trying new things; to test the limits of the tools we have on hand.
At Black Hat our mandate is to maintain a permissive environment, which results in a very tough job in determining actual malicious activity. Because there is so much activity, time is at a premium. Anything to reduce the noise and reduce the amount of time in triage is of benefit.
Repeated activity was seen, such as UPNP traffic causing false positives. Fine, easy to spot but still it clogs up the work queue, as each event was at first creating a single incident.
Noise such as this causes frustration and that in turn can cause errors of judgement in the analyst. Therefore, sharpening the analysts’ tools is of premium importance.
The entire BH team is always open to suggestions for improvement to the processes and automation routines that we run on XDR.
One of these was to place the Corelight NDR event payload directly into the description of an event entry in XDR.
This simple change provided the details needed directly in the XDR dashboard, without any pivot into other tools, shortening the triage process.
The above example shows activity in the Business Hall from demonstrator booths. It is clear to see what appears to be repeated beaconing of a vendor device and was therefore easy and quick to close. Previously this required pivoting to the Splunk search to query for the event(s) and if the information was not apparent, then again pivot to the submitting platform. Here is the review of lesson learned, and the application of recommendations, considered my process of investigation and automated those two steps.
Again, In the following example shows interesting traffic which looks like external scanning using ZDI tools.
Through having the payload form Corelight present in the event sequence in the XDR “Analyst workbench”, I was able to see: /autodiscover/autodiscover.json, which is commonly used by Microsoft Exchange servers to provide autodiscovery information to clients like Outlook.
The presence of this path suggested a probing for Exchange services.
- @zdi/Powershell Query Param — @zdi may refer to the Zero Day Initiative, a known vulnerability research program. This could indicate a test probe from a researcher, or a scan that mimics or checks for vulnerable Exchange endpoints.
- User-Agent: zgrab/0.x — zgrab is an open-source, application-layer scanner, often used for internet-wide surveys (e.g., by researchers or threat actors).
The tool is likely part of the ZMap ecosystem, which more than likely means that it is someone performing scanning or reconnaissance operation on the Public IP for the event, making it worthy to continue monitoring.
The Event Name was “WEB APPLICATION ATTACK” not very descriptive but with our fine tuning by providing the detail directly in the incident findings, the information was quite literally at my fingertips.
Scareware, Video Streaming, and Whatnot
On 2nd April, one of the devices on the network reached out to a website flagged as “Phishing” by Umbrella.
At first, it was suspected that the queries were related to a training class because of the timing of the domain activity. For example, some of the domains were registered as recently as a month ago, with Umbrella showing activity beginning only on April 1st, coinciding with the start of the conference.
But if that were the case, we would expect to see many other attendees making the same requests from the training Wi-Fi SSID. This was not the case — in fact, across the event only a total of five IPs making these DNS queries and/or web connections were seen, and only one of those was connected to the training SSID. One of those five devices was that of an Informa sales employee. A NOC leader contacted them, and they acknowledged accidentally clicking on a suspicious link.
Christian Clasen expanded the search beyond the “Phishing” category and found heaps of searches for domains in a short window of time for questionable categories of adware, malware and adult sites.
On this device, this was followed by a detour to a pirated video streaming website (potentially an accidental click). This website then kicked off a chain of pops-up to various websites across the board including over 700 DNS queries to adult sites. We used Secure Malware Analytics to review the website, without getting infected ourselves.
Considering this potential chain of actions on that device, the same observable was detonated in Splunk Attack Analyzer for dynamic interaction and analysis. The report for the video streaming site shows the site reputation being questionable along with indicators for phish kits and crypto payments present.
So, back to the question: Are these all connected? Looking at the various instances of such spurious DNS queries, Christian collated such websites queried and the IPs they were hosted at. DNS queries to:
- adherencemineralgravely[.]com
- cannonkit[.]com
- cessationhamster[.]com
- pl24999848[.]profitablecpmrate[.]com
- pl24999853[.]profitablecpmrate[.]com
- playsnourishbag[.]com
- resurrectionincomplete[.]com
- settlementstandingdread[.]com
- wearychallengeraise[.]com
- alarmenvious[.]com
- congratulationswhine[.]com
- markshospitalitymoist[.]com
- nannyirrationalacquainted[.]com
- pl24999984[.]profitablecpmrate[.]com
- pl25876700[.]effectiveratecpm[.]com
- quickerapparently[.]com
- suspectplainrevulsion[.]com
Which resolved to common infrastructure IPs:
- 172[.]240[.]108[.]68
- 172[.]240[.]108[.]84
- 172[.]240[.]127[.]234
- 192[.]243[.]59[.]13
- 192[.]243[.]59[.]20
- 192[.]243[.]61[.]225
- 192[.]243[.]61[.]227
- 172[.]240[.]108[.]76
- 172[.]240[.]253[.]132
- 192[.]243[.]59[.]12
Which are known to be associated with the ApateWeb scareware/adware campaign. The nameservers for these domains are:
- ns1.publicdnsservice[.]com
- ns2.publicdnsservice[.]com
- ns3.publicdnsservice[.]com
- ns4.publicdnsservice[.]com
Which are authoritative for hundreds of known malvertising domains:
Given that one affected person acknowledged that they had clicked on a suspicious link, resulting in one of the events, we believe that these are unrelated to training and in fact unrelated to each other. A Unit42 blog can be referenced for the list of IOCs related to this campaign. Unit42’s post notes, “The impact of this campaign on internet users could be large, since several hundred attacker-controlled websites have remained in Tranco’s top 1 million website ranking list.” Well, that is a true positive in the SOC here.
Trufflehunter Monero Mining Attacks
Authored by: Ryan MacLennan
As part of doing some additional testing and providing better efficacy for our XDR product, we deployed a proof-of-value Firepower Threat Defense (FTD) and Firepower Management Center (FMC). It was receiving the same SPAN traffic that our sensor received for XDR Analytics, but it is providing a completely different set of capabilities, those being the Intrusion Detection capabilities.
Below we can see multiple triggers, from a single host, on the FTD about a Trufflehunter Snort signature. The requests are going out to multiple external IP addresses using the same destination port.
This was interesting because it looks as if this user on the network was attempting to attack these external servers. The question was, what is trufflehunter, are these servers malicious, is the attack on purpose, or is it legitimate traffic here at Black Hat for a training session or demo?
Taking one of the IP addresses in the list, I entered it into VirusTotal and it returned that it was not malicious. But it did return multiple subdomains related to that IP. Taking the top-level domain of those subdomains, we can do a further search using Umbrella.
Umbrella Investigate says this domain is a low risk and freeware/shareware. At this point we can say that Command and Control is not in play. So why are we seeing hits to this random IP/domain?
Taking the domain for this investigation and popping it into Splunk Attack Analyzer (SAA), we can explore the site. Basically, the owner of this domain is an avid explorer of knowledge and loves to tinker with tech, the main domain was used to host their blog. The many subdomains they had listed were for the different services they host for themselves on their site. They had an email service, Grafana, admin login and many other services hosted here. They even had an about section so you could get to know the owner better. For the privacy of the domain owner, I will omit their website and other information.
Now that we know this IP and domain are most likely not malicious, the question remained of why they were being targeted. Looking at their IP address in Shodan, it listed their IP as having port 18010 open.
Looking at a few other IPs that were being targeted, they all had that same port open. So, what is that port used for and what CVE is the Snort signature referencing?
We see below that the trufflehunter signature is related to CVE-2018-3972. It is a vulnerability that allows code execution if a specific version of the Epee library is used on the host. In this case, the vulnerable library is commonly used in the Monero mining application.
Doing a search on google showed that port 18080 is commonly used for Monero peer-to-peer connections in a mining pool. But that is based off the AI summary. Can we truly trust that?
In the Google results, we find the official Monero docs and they certainly do say to open port 18080 to the world if you want to be a part of a mining pool.
We can see that there were attempts to get into these services, but they were not successful as there were no responses back to the attacker? How is an attacker able to find servers around the world to perform these attacks on?
The answer is fairly simple. In Shodan, you can search for IPs with port 18080 open. The attacker can then curate their list and perform attacks, hoping some will hit. They probably have it automated, so there is less work for them in this process. How can we, as defenders and the everyday person, prevent ourselves from showing up on a list like this?
If you are hosting your own services and need to open ports to the internet, you should try to limit your exposure as much as possible.
To alleviate this type of fingerprinting/scanning you should block Shodan scanners (if you can). They have a distributed system, and IPs change all the time. You can block scanning activities in general if you have a firewall, but there is no guarantee that it will prevent everything.
If you have an application, you developed or are hosting, there are other options like fail2ban, security groups in the cloud, or iptables that can be used to block these types of scans. These options can allow you to block all traffic to the service except from the IPs you want to access it.
Alternatives to opening the port to the Internet would be to setup up tunnels from one site to another or use a service that doesn’t expose the port but allows remote access to it via a subdomain.
Want to learn more about what we saw at Black Hat Asia 2025? Check out our main blog post — Black Hat Asia 2025: Innovation in the SOC — and our other Black Hat 2025 content.
Acknowledgements
Thank you to the Cisco NOC team:
- Cisco Security: Christian Clasen, Shaun Coulter, Aditya Raghavan, Justin Murphy, Ivan Berlinson, and Ryan Maclennan
- Meraki Systems Manager: Paul Fidler, with Connor Loughlin supporting
- ThousandEyes: Shimei Cridlig and Patrick Yong
- Additional Support and Expertise: Tony Iaconbelli and Adi Sankar
(especially Mark Overholser and Eldon Koyle), Arista Networks (especially Jonathan Smith), MyRepublic and the entire Black Hat / Informa Tech staff (especially Grifter ‘Neil Wyler’, Bart Stump, Steve Fink, James Pope, Michael Spicer, Jess Jung and Steve Oldenbourg).
About Black Hat
Black Hat is the cybersecurity industry’s most established and in-depth security event series. Founded in 1997, these annual, multi-day events provide attendees with the latest in cybersecurity research, development, and trends. Driven by the needs of the community, Black Hat events showcase content directly from the community through Briefings presentations, Trainings courses, Summits, and more. As the event series where all career levels and academic disciplines convene to collaborate, network, and discuss the cybersecurity topics that matter most to them, attendees can find Black Hat events in the United States, Canada, Europe, Middle East and Africa, and Asia.
For more information, please visit the Black Hat website.
We’d love to hear what you think! Ask a question, comment below, and stay connected with Cisco Security on social media.
Cisco Security Social Channels
