Update Sept. 9 @ 3pm ET
What you're about to read is something that all endpoint detection and response (EDR) companies perform as a byproduct of investigating threats. Because these services are designed to monitor for and detect threats, EDR systems by nature need the capability to monitor system activity, as is outlined in our product documentation, Privacy Policy, and Terms of Service.
On the heels of questions around how and why Huntress released this information, we wanted to clarify several important aspects of our investigation. We have an obligation to 1) research and respond to security threats and investigate malware and 2) educate the broader community about those threats. These dual objectives played into our decision to develop and publish this blog post.
When we first came across the host mentioned in this blog, it was because we were first responding to numerous alerts that were related to malware executing on it. Part of this process involves our SOC team closely investigating signals and collecting artifacts related to EDR telemetry on the host. It was only upon further investigation into this telemetry that we observed signals indicating malicious behavior. By this point, we also found that the unique machine name used by the individual was the same as one that we had tracked in several incidents prior to them installing the agent.
At this point, we determined that the host that had installed the Huntress agent was, in fact, malicious. We wanted to serve the broader community by sharing what we learned about the tradecraft that the threat actor was using in this incident. In deciding what information to publish about this investigation, we carefully considered several factors, like strictly upholding our privacy obligations, as well as disseminating EDR telemetry that specifically reflected threats and behavior that could help defenders.
Overall, this investigation is a result of what we strive to do best: transparency, education, and wrecking hackers. Read on to learn more.
------------------------
Here at Huntress, we love exposing adversary tradecraft, and we also love when threat actors make blunders. So imagine our delight when a threat actor installed Huntress onto their operating machine—after finding us via one of our advertising campaigns and starting a trial— giving us a sprawling inside look at how they’re using AI to build workflows, searching for tools like Evilginx, and more.
------------------------
We all know that security products are often downloaded by attackers for “evaluation,” but often we can only guess as to how they decided to target a particular technology, or the actions taken while trying out such software. We recently had the pleasure of getting a front seat view into what one attacker did, simply because they installed our agent and let us collect information directly from them. Here, we will cover this strange tale.
Like most good stories, this one starts in the middle and works its way back and forth. Let’s start with how this person of interest got our attention. One of the tricks of the trade to get people interested in your products is through advertising. As such, we run ads to help lead potential customers to our products. An adverse effect here might be garnering some “unwanted” attention as well. Such is the setting for the beginning of this adventure: it all started with a nicely placed Google ad.
The attacker tripped across our ad while researching another security solution. We confirmed this is how they found us by examining their Google Chrome browser history. An example of how this may have appeared to them in the moment may be seen in Figure 1.
It appears that the attacker became interested in Huntress while simultaneously trying out Bitdefender. After hitting our comparison page, they could hardly contain themselves and started a trial immediately. We are able to follow their journey through their Chrome history, as seen in Figure 2 below.
It’s no secret that threat actors may install security products for research purposes or even for legitimate use—and in fact, the adversary was interested in other security products in addition to Bitdefender and Huntress. We found evidence that they had bought a Malwarebytes subscription (including the Malwarebytes browser guard extension).
We knew this was an adversary, rather than a legitimate user, based on several telling clues. The standout red flag was that the unique machine name used by the individual was the same as one that we had tracked in several incidents prior to them installing the agent. Further investigation revealed other clues, such as the threat actor’s browser history, which appeared to show them trying to actively target organizations, craft phishing messages, find and access running instances of Evilginx, and more. We also have our suspicions that the operating machine where Huntress was installed is being used as a jump box by multiple threat actors—but we don’t have solid evidence to draw firm conclusions at this time.
Huntress analysts went to work evaluating the outstanding indicators of compromise found on the adversary’s host and how they related to data found within authentications to identities at Huntress. Retroactive hunts disclosed a further 20 identities which were compromised; many of which had been accessed by the adversary prior to Huntress’ deployment against the identity, whose activity was limited to refreshing session tokens to maintain access.
Overall, analysis of the adversary’s primary operating infrastructure, hosted on Autonomous System (AS) “12651980 CANADA INC.” (now known as VIRTUO) disclosed a pattern of access of over 2471 unique identities spanning the last two weeks– many of which were preemptively caught by additional detection capabilities such as malicious mail rule creation, or session token theft.
The intelligence gathered by the above has resulted in detections of high confidence against the adversary’s infrastructure; and equipped our systems and analysts to respond to these incidents in significantly less time and with extreme confidence in malice, eliminating adversarial attempts to evade our detections.
All in all, we were able to see the threat actor’s specific day-to-day activities—from their methodologies to the specific types of organizations (and even individuals) they were interested in. We also saw them begin to tinker with tools and search for tutorials, attempting to learn more. For instance, after installing the Huntress agent, the threat actor took steps to better understand Autoruns.
Overall, over the course of three months we saw an evolution in terms of how the threat actor refined their processes, incorporated AI into their workflows, and targeted different organizations and vertical markets, as outlined in Figure 5 below.
Below are some of the specific methodologies that we saw.
The Chrome browser history gave a first-hand look at how the adversary is using AI tools to increase the operational efficiency of their workflows. While there have previously been many reports on how cybercriminals are using AI (based on indicators in phishing messages or landing page content), this is the first time that we have a close-up view of a threat actor embedding AI into their operations in order to automate—and speed up—their workflow.
On May 25, the threat actor signed up for Make.com, which is legitimate workflow automation software, before researching the platform’s Telegram Bot integration feature as a way to launch automated processes (as seen in Figure 6 below). The threat actor then poked around several FAQ sites to better understand how Telegram Bot APIs work and how to set up webhooks.
Over time, the threat actor started to get a better grasp of how they could use Make.com for specific workflows, and their browser history shows them starting to rely more heavily on the platform. By the time June 29 rolled around, the threat actor had fully developed their workflow with Make. As seen in Figure 8, the threat actor would first identify the organization of interest (typically after receiving a “tip” from Telegram) before using Google Translate to translate or craft messages related to these organizations. While we don’t have detailed insight into how the threat actor was using Make for these specific workflows, we can see that it was part of the process to automate specific functions.
Figure 8: Threat actor starts to rely on automated workflows
The threat actor also appeared to be interested in other AI tools to help with data generation and writing. We saw multiple Google searches for “free ai no signup” and for “csv generator ai.” We also saw the threat actor using Toolbaz AI, which is a writing assistant; the CSV spreadsheet generator feature of DocsBot AI, which is an AI chatbot tool; and the AI data generator feature of Explo AI, which is an embedded analytics tool.
We saw evidence of the threat actor searching for running instances of the Evilginx man-in-the-middle attack framework using Censys, and then attempting to access those instances.
In addition to Evilginx, we also found evidence of multiple installed tools on the threat actor’s system—or, in some cases, an interest in tools based on the threat actor browser history. These tools included recon and attack tool GraphSpy, open source tool Bloodhound, the TeamFiltration framework used for enumeration and exfiltration, and more.
The Chrome browser history also revealed visits by the threat actor to multiple residential proxy webpages, including LunaProxy and Nstbrowser (which bills itself as an anti-detect browser and supports the use of residential proxies). The threat actor visited the pricing plan page for LunaProxy, researched specific products, and looked up quick start guides throughout May, June, and July. Residential proxy services have become increasingly popular with threat actors as a way to route their traffic through residential IP addresses, allowing them to obscure malicious activity, like avoiding suspicious login alerts while using compromised credentials.
The Chrome browser history entries also gave us a close view of the attacker’s reconnaissance methods. The threat actor spent a lot of time researching companies across different sectors, from specific banks to “top real estate companies in the US” (also looking up “real estate agents in California”).
The threat actor didn’t just search for individual companies—they also looked at all parts of the ecosystem surrounding organizations of interest, from their customer bases to associated third-party companies across the supply chain. For example, the threat actor appeared to start targeting software companies in early July, searching for these types of companies via Google Search and using database marketing tools like ReadyContacts and InfoClutch to scope out how many customers they had and their market share.
The threat actor also used the BuiltWith platform, which lets users identify and analyze the technology stacks used by websites. On July 8, browser entries show the attacker conducting an extensive level of research on a prominent ecommerce vendor for managing payments and subscriptions, including a list of its customers, contacts, and market share. The threat actor then used BuiltWith to search for the websites relying on that vendor, before navigating to the BuiltWith sign up page, presumably to access that list.
The threat actor conducted a fair amount of research into tools used to scrape Telegram group data, including looking at scraper tools like Apify, the Axiom Chrome extension, and the RapidAPI platform (Figure 13).
The threat actor used Google Translate extensively, and Chrome browser shows them first visiting bank websites, and then using the translation platform, likely to assist in crafting phishing-related messages, as seen in Figure 14.
The attacker often used urlscan to get information about various websites. Tips appear to have come in via Telegram using the getUpdates method.
There were several entries in the browser history that showed use of Google Translate to translate messages from Portuguese to English alongside browsing banks in Brazil, then evidence of crafting messages later on in their history.
We also saw the threat actor express interest in STYX Market, a dark web forum that’s been around since 2023, and was recently called a “rising star for stealer logs, stolen creds, and laundering services” by researchers. After doing some initial research on STYX—as well as other Telegram chat groups and channels—they decided to check out the site for themselves, registering for an account before perusing the catalog of VoIP accounts, stealer logs, SIM cards, and more.
Rarely do you ever get the chance to actually shoulder surf a real threat actor. We had such an opportunity when they installed our agent. It starts out mundane enough. We don’t know what they must have dreamed about after ending their shift at 2am UTC the previous night, but as mentioned earlier, you can see them start a trial, download the agent, and install it.
The most interesting activity for the start of their day on July 9, 2025 was browsing to urlscan.io to inspect login.incipientcroop[.]com. Shortly after, they logged into Make.com and began working on a project called Voltage_Office356bot (notice the typo).
There is evidence that the threat actor had access to cookie data for two different individuals, and accessed them via Notepad++. They proceeded to open the first file:
C:\Program Files\Notepad++\notepad++.exe C:\Users\Administrator\Downloads\Telegram
Desktop\Cookies_[victim1]@[redacted1][.].com.json
Then they started looking around to see what they can find, with a Google search for “email osint”.
Next, they opened the second cookie file:
C:\Program Files\Notepad++\notepad++.exe C:\Users\Administrator\Downloads\Telegram
Desktop\Cookies_[victim2]@[redacted2][.].com.json
They then started up Nstbrowser.exe and LunaProxy:
C:\Program Files\Nstbrowser\Nstbrowser.exe
C:\Program Files (x86)\LunaProxy_cata\socks5\LunaProxyDivert.exe SOCK5 [snip]
They browsed to an article titled Say Hello to your new cache flow by Synacktiv covering WHFB and Entra ID, followed by a Google search for “whfb prt”, which landed them on the website of a well-known researcher, Dirk-Jan Mollema.
They checked their IP address after this:
C:\Windows\system32\curl.exe ipinfo[.]io
And then checked their IP address again:
C:\Windows\system32\curl.exe ipinfo[.]io
They then tried to use a tool called ROADtools Token eXchange (roadtx):
C:\Users\Administrator\AppData\Local\Programs\Python\Python313\Scripts\roadtx.exe prtauth -r msgraph -c msteams
And then erroneously tried to run the same tool (as an executable) via Python:
C:\Users\Administrator\AppData\Local\Programs\Python\Python313\python.exe C:\Users\Administrator\AppData\Local\Programs\Python\Python313\Scripts\roadtx.exe prtauth -r msgraph -c msteams
Then ran it again:
C:\Users\Administrator\AppData\Local\Programs\Python\Python313\Scripts\roadtx.exe describe
And then tried to run it again, erroneously, using Python:
C:\Users\Administrator\AppData\Local\Programs\Python\Python313\python.exe C:\Users\Administrator\AppData\Local\Programs\Python\Python313\Scripts\roadtx.exe describe
They seemed to be having trouble. At this point they browsed to Dirk-jan Mollema’s post on Phishing for Microsoft Entra primary refresh tokens.
While there, they gained some new inspiration, and discovered a handy little script that could make their life easier:
At this point they went back to their Voltage_Office356bot project before running this new script they’ve downloaded.
They started trying to run the Python script:
C:\Users\Administrator\AppData\Local\Programs\Python\Python313\python.exe main.py -f roadtx.prt --wfb
They checked the usage again:
C:\Users\Administrator\AppData\Local\Programs\Python\Python313\python.exe main.py --wfb
C:\Users\Administrator\AppData\Local\Programs\Python\Python313\python.exe main.py -h
Then, they started to run it against the original victim whose cookie file we saw earlier:
C:\Users\Administrator\AppData\Local\Programs\Python\Python313\python.exe main.py --wfb -u [victim2]@[redacted2][.]com
They returned to the first victim’s cookie file:
C:\Program Files\Notepad++\notepad++.exe C:\Users\Administrator\Downloads\Telegram
Desktop\Cookies_[victim1]@[redacted1][.].com.json
This is where our EDR data drops off, as they may have become aware of us and uninstalled the agent.
The attacker’s browser history gives us an unprecedented level of insight into their everyday activity, searches, workflows, research, and more. The browser history shows the threat actor working intensively almost every day between the period of May 29, 2025 through July 9, 2025.
On many of these days, the browser entries were seen across most hours of the day, logging 12 to 14 hours. But there was some variation, as seen in Figure 29, above: on several days, the threat actor worked as little as one to two hours.
When we hone in on a few of the days when the most hours were put in, we can see some of the things that piqued the attacker’s interest in those days. We analyzed the urls to see what businesses, or categories they might have fallen into, and then looked to see how many times the attacker visited these sites.
We can see a few trends. During these days, the attacker spent a lot of time researching various banking entities and bank personnel. To further expand on some of the graph labels:
Attack infra: Malicious websites or servers set up by an attacker (maybe not this one) hosting frameworks like Evilginx and other known tools.
Banking: Various banking websites
Browser extension: Various browser extensions like ad blockers, etc. installed by the attacker to protect themselves.
Corporate & Business: Various business websites not housed under a different category.
Crypto: Various cryptocurrency and blockchain websites.
Cybersecurity: Various cybersecurity vendor websites. The attacker often signed up for trials at various vendors to test things.
Government & military: Various official government or military websites.
News, media & information: Various news websites like CNN etc. The attacker often read articles related to various breaches.
OSS: Open source projects, often housed at github or gitlab.
Recon: Activities where the attacker was using Censys, Urlscan, Google, etc., to do reconnaissance for a particular target.
Research: When the attacker was researching a particular vulnerability, tool, or attack.
Sandbox: The attacker often seemed interested in various types of malware that were on VirusTotal, Joe’s Sandbox, and other online sandboxes.
Social media: Various telegram, X, and other social media posts read by the attacker.
Software: Various legitimate software, like 7zip.
Telecommunications: A telecommunication website, like Verizon.
Web & IT infrastructure: Various online hosting services, like Mega, Amazon AWS, and Azure.
We can see that from May 29 to June 1, 2025, the attacker was mostly looking at various banking websites. Digging further into their activities, you see them researching various banks, reading about Telegram Bots, then downloading a blueprint from Make.
The next day, it seems that the attacker spent a little more time researching various attack infrastructure, in addition to focusing on banks, and similar activities seen previously.
On May 31, 2025 and June 1, 2025, the attacker switched their focus back to mostly researching banking websites.
The other interesting thing was that the attacker was mostly focused on banks and sites that were in Nigeria during this time period, even looking for things like:
“No. 1 regulated crypto exchange in Nigeria.”
“top crypto companies nigeria”
“Best Crypto Exchanges in Nigeria”
“Top Cryptocurrency Companies in Nigeria”
While we don’t know where the attacker is based, the machine they had installed our agent upon appeared to be based in the United States, on the West Coast, based on the machine’s internal time zone and IP address.
It seems that the attacker had spent quite some time looking at our various capabilities after they had started a trial with us. Figure 36 above shows just how much more time they spent interacting with the Huntress website, and particularly the account dashboard once they had started the trial.
This incident gave us in-depth information about the day-to-day activities of a threat actor, from the tools they were interested in to the ways they conducted research and approached different aspects of attacks.
Upon confirming that the machine name was one used by an adversary, we decided to release these details because they give an invaluable understanding into the mindset and behaviors of threat actors behind attacks. For other defenders, we hope that this information can help add context around the ways that threat actors conduct research and launch attacks at the backend—and the different types of organizations, tools, and platforms that interest them.
Get insider access to Huntress tradecraft, killer events, and the freshest blog updates.
