The Devil, Eight Million Emails, and a Whole Lot of Milk

Background

A partner onboarded a small client (25 endpoints) to Huntress on 2026-05-15 18:48 UTC. By the early hours of the next morning, the SOC was looking at a critical detection on one of the endpoints.

Most of the incidents we write up involve customers who have already had the Huntress agent installed on their endpoints for months. This buys us a head start. We get time to set a baseline, to collect logs, and, most importantly, to learn the context of the customer’s specific environment: which accounts sign in from where, which hosts talk to which, and what an ordinary day on the network looks like. Deploy EDR into a healthy network, and the agent (and analysts) can watch the attacker arrive and better understand  the things that do not belong.

Because we were installed mid-incident, this onboarding gave us none of that. The credentials were already stolen, the tooling was already staged, and the only question left was how fast we could untangle an intrusion in a network we had known for only nine hours.

A logon we already had a name for

The first alert Huntress got was not subtle. At 2026-05-16 03:38:53 UTC, the Huntress agent raised a critical, expedited detection. The detection indicated an authentication (surfaced from a Windows Security audit log entry—Microsoft-Windows-Security-Auditing Event ID 4624, which indicates successful logons). The interesting field on an authentication event is usually the source IP. Here, it was both the source IP and the hostname. The RDP client had announced itself as DESKTOP-[REDACTED], a workstation name Huntress had seen before in unrelated partner intrusions. The source IP, 212.93.152[.]37, geolocates to Romania. Hold that thought, it comes back.

Figure 1: The first signal, 03:38:53 UTC. A critical, expedited authentication detection involving source IP 212.93.152[.]37. 

The host itself is a Remote Desktop (RD) Session Host server (also known as a terminal server), a Windows Server that hosts multiple users' remote desktop sessions simultaneously.  It also hosted a public Microsoft IIS RDWeb Access portal (the web login page for remote desktop access), and it ran the RD Gateway role (essentially a middleman between the internet and internal terminal servers). One box, exposed straight to the internet, authenticating domain users with a username and a password. External threat intelligence saw the same thing from the outside: a public RDWeb portal answering on port 443. That portal was the front door, and the actor had the password. 

Four keys to the same lock

The host's IIS logs showed how the operator got on in the first place. RDWeb Access runs on IIS; its logs capture every portal visit, login attempt, and app launch request, making them invaluable when we were investigating this incident. This terminal server published its RDWeb Access portal directly to the internet, and, in a typical internet fashion, it was being abused by anything and everything. Over the four days the logs covered, the portal answered 657,521 requests from 8,673 distinct IP addresses, and more than 206,000 of those were HTTP POST requests to the login page from 8,197 separate sources. That is what an exposed RDWeb portal looks like from outside: a login form under constant automated attack from every direction at once. One source alone, 87.251.64[.]134, threw roughly 48,000 requests at it; 10 hosts in 88.210.63[.]0/24 added another 84,000 between them.

Out of 206,444 login POSTs, exactly four returned 302 instead of 200, and on this portal, that gap is the whole game. A failed RDWeb forms login re-renders the page with a 200; a success redirects with a 302. Four redirects, four keys that turned, every one of them in the same lock: the single domain account published on the box. Drop the moment the partner onboarded the customer into the same timeline, and the four successes tell a better story than "the attacker logged in."

Three addresses, four logins, and they are not one set of hands. Two of them plainly are. 80.94.95[.]37 and 212.93.152[.]37 behaved the same deliberate way: each loaded the portal's stylesheet and images like a real browser, signed in with the fully domain-qualified username ([DOMAIN]\[user]), pulled the published .rdp file, and went on through the RD Gateway to open a session on the box. Both are Romanian. The first is a hosting address in Timisoara known across multiple external threat intelligence feeds to be abused; the second, the line the hands-on work ran on, is a clean residential fixed-line with no abuse history identified. Read together, they are the ordinary shape of a single operation: early access from a burnable hosting IP, then the real work from a quiet residential line no blocklist has flagged.

216.152.151[.]168 is the odd one out, and the timing is what gives it away. It is a flagged US data-centre host, and it was not a browser. It called itself Go-http-client/2.0 (and, on some requests, a bare Mozilla/5.0 string with no engine behind it) and it lowercased the portal paths the way scripted tooling does, rather than following the mixed-case links a browser is actually served. It submitted the bare username with no domain. It ground at the login form in GET/POST pairs from May 14th onward; 127 failed POSTs, until one at 21:51:16 on May 15th finally returned 302. Then, strangely, after finding the password, it did absolutely nothing and went straight back to guessing:

21:51:16  POST  login.aspx  302  <- one success (bare username, Go-http-client/2.0)

21:53:36  POST  login.aspx  200  <- straight back to guessing

22:18:15  POST  login.aspx  200

22:26:40  POST  login.aspx  200

This carried on into May 16th; the bot never pulled the .rdp, never reached the gateway, and never appeared anywhere in the host's Windows event logs.

Now line that single success up against the rest of the timeline. The operator had already been signing in and pulling the published desktop since 02:12 that morning, and had been doing so from another address two days before that. We tie the two Romanian addresses to one operator on tradecraft rather than geography: each loads the portal like a real browser, signs in with the same fully domain-qualified username, pulls the same published .rdp file, and carries on through the gateway into a session on the box. By the time the bot scratched out its 302 at 21:51, the people running this intrusion had already held a working session on the box, on and off, across the previous two days. An operation that already owns the host does not also spend two days brute-forcing the front door to rediscover a password they're already busy using. The infrastructure, the client, the lowercased paths, the bare username and, above all, the timing point one way, so we assessed 216.152.151[.]168 as a separate, opportunistic credential brute-forcer - the sort that proves a login and sells or lists it, that happened onto the same weak password and never came back to spend it. From here, the address we follow is 212.93.152[.]37; the bot is somebody else's story, and a measure of how little this one credential was worth keeping.

That leaves the last row in the Table 1 timeline, the 03:36 reconnect. In the table, we already called it a reconnect, and that one word is doing the real work: a reconnect means the session it rejoined was opened earlier, before we were on the box at all. We did not want that resting on a single log line, so we confirmed it against every channel that recorded the event.

The Security log was no help. This terminal server had almost no auditing enabled, 2 logon events across the entire log, and zero event IDs indicating process creation (4688). On a normal day, that is an annoyance. During an intrusion, it means the first log you reach for has nothing to say. However, the Terminal Services operational logs did, so we parsed them with Chainsaw. Lined up, the 03:36 sequence reads cleanly:

Each channel catches a different stage of the same connection: the portal logs a fresh re-authentication, the gateway opens the tunnel, RD authentication succeeds, and the Local Session Manager resolves what it actually was. That last event settles it: Event 25 is a reconnection, not a new logon. The operator did not start a session at 03:36; they rejoined session 16, a desktop left sitting disconnected, waiting for them. People do not leave disconnected RDP sessions lying around on a server they logged into for the first time that minute.

The devil's workshop

With the Security log a dead end, the rest of the picture came from the Terminal Services operational logs and the files left on disk. That is where the incident stops being an access story and becomes a phishing story. The staging directory sat on the compromised user's desktop, in a folder the actor had named dam pe uk puterniiicccc, Romanian slang roughly meaning "we hit the UK hard."

Figure 2: Contents of the staging directory on the terminal server. 

As seen in Figure 2 above, the mailer (gm.exe) and all six recipient lists (milk (1) to (6)) share a single last-modified time of 2026-05-15 02:15 UTC, hours before the customer was onboarded; only the project file, dracii.mmp, was modified later, at 2026-05-16 03:28 UTC, the morning the reconnect was detected. This indicates that the threat actor had been in long enough during an earlier session to build the kit and leave it sitting on the desktop; the operator came back that morning presumably to run the campaign.

Opened up, the folder holds three things:

• gm.exe: Gammadyne Mailer, a long-running commercial Windows bulk email application. This explains why no antivirus alert ever fired. Gammadyne is not malware. It is a legitimate, signed, commercially sold mailing tool. Microsoft Defender on this host had logged plenty of detections over its lifetime, including a keygen flagged as Trojan:Win32/Occamy.C, a network scanner caught as HackTool:Win32/Netscanner in September 2025, a Cryptinject sample in April 2026, but every one of them predated this incident by weeks or months, and not one of them was the mailer. The box had been a mess for a long time; the mailer walked straight past Defender because there was nothing for a signature engine to catch.

• dracii.mmp: the Gammadyne project file. Dracii is Romanian for "the devils." The project file contains the entire campaign configuration, and parsing it returned thesender, the lures, the payload link, and the delivery method in a single shot.

• Six text files, milk (1).txt through milk (6).txt.

Figure 3: The operator-side working folder reconstructed from the recipient-list paths stored in dracii.mmp. 

The project file gave us more than the campaign. Because dracii.mmp had been carried across from the operator's own machine, its file mappings came with it, and they pointed straight back at that machine. The recipient-list paths referenced a working folder, C:\Users\Administrator\Desktop\ta\, and Figure 3 shows the seven lists the project drew from it. The folder names do most of the talking: one is devoted to HMRC, the UK tax office (the spelling mistake is the actor's), and the other pairs UK targets with the Solana cryptocurrency. The file names underneath are routine list management. A list named fara gmail ("without gmail" in Romanian) has had Gmail addresses filtered out, and the split files are a single larger list cut into three numbered parts. The same file showed how the mail was meant to move, and that this was not the operator's first terminal server. It was set for direct delivery with 666 send threads (the devil theme runs all the way down to the thread count), no DKIM or DomainKeys signing, batches of 50, and no throttling, a configuration built to empty the lists as fast as the host could open sockets. Its log, alarm, and incoming-mail paths still pointed to UNC shares on a different compromised RDS domain, \\[REDACTED].local\RDS\RDSRedirections\...\Crack\gm.log, a previous victim's box, the project had simply been carried from. The project's own creation date says the same: Gammadyne stamped it 2025-07-18, almost ten months before this customer was onboarded, so the copy re-saved onto this desktop was one the operator had been moving from host to host since the previous summer. This kit travels.

Put together, that is enough to widen the assessment past the campaign we actually caught. The kit staged on this desktop impersonated Boots, the UK pharmacy chain, with a fake customer-satisfaction survey as the lure (the campaign itself gets its own section below), but nothing in the operator's working folder says Boots specialist. Lists do not get curated around HMRC unless there is a tax-themed lure to send to them, and a folder pairing UK targets with the Solana cryptocurrency exists for the same reason. From what we reconstructed, this is one operator working a rotation of UK-facing themes, retail, tax and cryptocurrency, and the Boots set was simply the job loaded the morning we were watching. The filtered fara gmail copy and the numbered split files are the filing system of a working spammer, not a one-off scam, and a project file that had already lived on at least one other victim's terminal server says the rotation had been running since at least the previous year. The Romanian project name, the Romanian folder name, the Romanian list names, and a Romanian source IP all point in the same direction.

A whole lot of milk

The "milk" files are where the post gets its name, and the joke is the attacker's, not ours. The spammer is “milking” the lead lists, distribution lists, and the raw recipient sets for clicks. We found six of these files in total, and they are not small:

Sampling these showed a broad international consumer spread, Gmail, Hotmail, Yahoo, a lot of regional domains, exactly the kind of bulk list that gets bought and resold rather than collected. Eight million and change of other people's inboxes, staged on a customer’s terminal server, ready to go. 

Boots, a free gift, and a survey you should not take

The dracii.mmp project file laid out the campaign. The mail was sent as Boots <hello[@]boots[.]com>, impersonating the UK pharmacy and retail chain. The body offered a "Free Gift from Boots", an "exclusive Boots beauty sample pack", a discount voucher and early access to promotions, in exchange for completing a short customer-satisfaction survey, with personalisation tokens that dropped each recipient's address into the greeting and a random reference number into the subject. The Subject field itself held just one line, stuffed with tokens:

[[-Now-]] Share Your Feedback & Receive a Free Gift from Boots (@bootsUK)Your opinion matters—claim your thank-you gift! | Customer satisfaction survey  E-mail:[[-Email-]] NO:[[random_digits(7)]]-[[random_digits(5)]]

The double-bracket tokens are Gammadyne merge fields, filled in per message at send time: [[-Now-]] becomes the current date, [[-Email-]] drops the recipient's own address into their subject line, and the two [[random_digits]] tokens manufacture a fake reference number, unique for each of the 8.9 million recipients. The same trick ran in the greeting, which opened "Dear Valued Customer, [[-Email-]]". The effect is that no two recipients receive identical subjects, which reads as personalisation to the victim and evades any basic anti-phishing filter trying to cluster identical messages.

Seven more subject lines never made it that far. They were pasted into the project's Headers field, which holds technical mail headers, so the mailer had nowhere to use them. They are leftover drafts: one numbered block, each entry a subject and a matching preview (the snippet an inbox shows beside the subject line). The token-stuffed line above is what shipped. These seven stayed behind in the config:

1.

Subject: Your opinion = a gift 🎁

Preview: Complete our September 2025 survey and receive a special thank-you gift.

2.

Subject: Quick surveyspecial thank-you

Preview: Your insights help us improve—take a few minutes to share your feedback.

3.

Subject: We'd love your feedback

Preview: We value your opinion. A short surveya thoughtful reward.

4.

Subject: A few minutes for a reward

Preview: Your voice matters. Tell us how we're doing and enjoy a gift on us.

5.

Subject: Tell us what you think

Preview: Help shape the future of [Your Company]. Survey inside + thank-you gift.

6.

Subject: Your voice matters

Preview: It only takes a few minutes to share your thoughts and claim your gift.

7.

Subject: Survey inside + thank-you gift

Preview: Your feedback guides us—thank you for helping us serve you better.

Two of those lines shipped garbled; that is the file's doing, not the actor's typing. Gammadyne stored the block as three Base64-encoded chunks, and both breaks fall exactly where the encoder split the text: one midway through subject two, one midway through preview three, a character swallowed at each seam. The lures around them carry em dashes intact in the same positions ("improve—take", "guides us—thank"), so the missing character at each seam was almost certainly a dash. The block also went in exactly as it was written, never read back: preview five still holds an unfilled "[Your Company]" placeholder, and preview one offers a survey dated September 2025, months stale by the time the campaign was staged. One paste, no proofread.

There was one more piece of theatre. The HTML body of the email was wrapped in a cosmetic PGP block. PGP (Pretty Good Privacy) is a long-standing standard for signing and encrypting email: a real PGP signature is generated with the sender's private key, and the recipient's mail client checks it to prove who sent the message and that nothing was altered in transit. This email had the costume, but not the cryptography: a -----BEGIN PGP SIGNED MESSAGE----- header and Hash: SHA512 above the content, and a full -----BEGIN PGP SIGNATURE----- stanza below it, base64 and all, pasted into the body as styled text. None of it does anything in an HTML email; no client would ever verify it. It is decoration, there to make a consumer "free gift" message look signed and official to anyone who scrolls that far. The configuration supplies the punchline: the mailer was not set up to sign anything for real, no DKIM, no DomainKeys, so the only signature anywhere in this campaign was the fake one in the body.

Every subject variation led to the same place: a link styled as [Start Survey] pointing to hxxps://ipelc.gob[.]bo/boots_store/.

The payload lived on a Bolivian government website

That payload domain is the part of this incident worth slowing down for. ipelc.gob[.]bo is not attacker infrastructure in the usual sense. The gob.bo namespace is Bolivia's government top-level domain, administered by ADSIB, the state agency for the development of the information society, out of La Paz. IPELC itself is the Instituto Plurinacional de Estudio de Lenguas y Culturas, a real Bolivian government institute for the study of the country's languages and cultures. Its actual website is exactly what you would expect: official notices, dictionaries, and grammar references.

Figure 4: The webpage for ipelc.gob[.]bo, which threat actors compromised.

Figure 5: Registry WHOIS for the namespace. gob.bo is run by ADSIB, the Bolivian state information-society agency in La Paz, served by anycast nameservers (including NS.DNS.BR and NS2.NIC.FR).


The actor had broken into this government site and planted their phishing kit in a /boots_store/ subdirectory. This is a deliberate, and depressingly effective, choice. A freshly registered boots-rewards-uk[.]xyz trips domain age heuristics, reputation scoring, and blocklists on day one. A path on a long-lived, legitimate, government-owned domain inherits all of that domain's trust. It is older than any blocklist, it resolves cleanly, it carries a .gob.bo that looks official, and it sails through filters that would have killed a throwaway domain instantly. Compromising someone else's trusted site is cheaper for the attacker than building their own.

The kit on it was a full clone of the Boots storefront, and the funnel was built to harvest, not to sell:

Figure 6: The cloned Boots storefront and "customer satisfaction survey" modal, served from ipelc.gob[.]bo/boots_store/, offering a free gift from a fake sponsor, "Skinny Tan."


Figure 7: The "thank you for your feedback, redeem your gift" step, reached after a couple of throwaway survey questions, with the fake sponsor attached.



Figure 8: The "Secure Checkout / Your details" step, harvesting full name, email, date of birth, phone and home address for a £0.00 order. The payment step behind it is where card details would go.

The end goal here is the personal and financial data. The survey is the warm-up, the "free gift" is the bait, and the "secure checkout" delivery form is the catch: full name, email, date of birth, phone number and home address, gift-wrapped by the victim, with a payment step waiting behind it for card details. 

Take this survey, and the only thing you receive is an identity-theft starter pack. 

Direct to the world's mail servers

It is worth being clear about why the kit was sitting on the customer's desktop in the first place. This was not persistence, or ransomware. The actor had no interest in keeping a quiet foothold to slip back in later. Gammadyne runs locally and reaches out to recipient mail servers itself, so the mailer, the project file and all six milk lists had to live on the box that would do the sending. The thing the actor actually wanted was the host's clean, unflagged outbound IP and its bandwidth. Every one of the 8.9 million messages would leave from the customer's IP address, not the operator's, and once those messages started landing on spam blocklists, it was the customer's reputation that would be flagged and blocked. Staging on the desktop bought the operator a disposable IP to send from, not a foothold to come back to.

This now raises the question that the partner cared about most. Was the customer's own mail infrastructure being used to send this? If a compromised tenant relays a few million spam messages, that tenant's domain ends up on blocklists and legitimate mail stops being delivered for weeks. The blast radius is the whole business’s comms to clients and customers, well beyond the one box.

The event logs answered it directly, and for the partner, the answer was a small relief: the mailer never touched the customer's mail tenant. dracii.mmp had it set for direct delivery.

Normally, sending mail involves relaying. Your mail client hands the message to your own provider's outbound server, a Microsoft 365 or Google tenant, say, and that server does the rest. It looks up the recipient domain's MX (Mail Exchange) records, the DNS entries that name the servers responsible for receiving a domain's mail, connects to one of them, and delivers the message on your behalf. The receiving end sees the mail arrive from the provider's IP, carrying the provider's sending reputation. Direct-to-MX delivery cuts the provider out of that chain. The sending software becomes its own mail transfer agent: for every recipient, it does the MX lookup itself and opens a connection straight to the recipient's mail server on TCP port 25, with nothing in between. That is exactly how gm.exe was set up: no smart host or relay, 666 threads at a time in batches of 50. For a spammer, it is the obvious choice. There is no provider account to get throttled or shut down, no sending limits to trip, and, most usefully, the mail leaves directly from the compromised host's own IP, so it is the victim's address that wears the blocklisting rather than anything belonging to the attacker. It is the same logic that left the campaign with no real DKIM signing anywhere: with no relay to authenticate to, the only "signature" on this mail was the fake PGP block pasted into the body.

The host's telemetry showed precisely that. Once isolation had dropped a default-deny filter in front of the box, the Windows Filtering Platform logged every connection the filter killed (Event 5157), and in a single 104-second flurry, gm.exe threw 29,954 outbound connections at port25, spread across 1,641 distinct mail servers.

Two things fall out of that. First, the relay risk sits with the terminal server's outbound IP, not the partner's mail tenant, which narrows the cleanup considerably; the partner's own mail domain and tenant reputation were never the ones doing the sending. Second, a caveat about what the block log can and cannot show. The mailer had been running before we cut the host off, 666 threads grinding through the milk lists, and Event 5157 only starts logging once isolation drops the default-deny filter in front of the box. From 03:47:03, that filter killed every connection gm.exe opened, 29,954 of them in 104 seconds, none of them clearing the host. What it could not do was claw back whatever had already gone out in the window before it went live, and on a server this lightly audited, we cannot put a number on that. What we can say is that isolation caught the campaign mid-send and shut it down where it stood.

The filter was working in both directions at once. While it killed gm.exe's outbound SMTP, it was also dropping the actor's inbound attempts to reconnect from 212.93.152[.]37, along with the steady background hammering from the same brute-force sources we had watched batter the RDWeb portal for days, 87.251.64[.]134 and the 88.210.63[.]0/24 range among them. The door was shut from both sides at the same moment.

So what did Huntress do?

The signals stacked up quickly. A critical, expedited detection at 03:38:53 UTC: involving a previously seen bad workstation DESKTOP-[REDACTED], authenticating over RDP with a valid domain credential. Then, at 03:41:46 UTC, a second signal of the same workstation name reached the domain controller. The SOC triaged it as a high-severity incident and did not wait it out.

Analysts immediately:

• Mass-isolated all 25 endpoints in the organisation.

• Flagged the compromised account and the terminal server to the partner so the stolen credentials could be reset at the domain controller.

Isolating the whole network, rather than just the terminal server, came down to one thing: there was no multi-factor authentication (MFA) anywhere in front of it. The actor already held one working domain credential; the portal logs showed that the same credential had been validated from multiple addresses, including an unrelated brute-forcing bot, and it had been reused through an internet-facing portal for more than a day. Any of the other 24 endpoints could be reached with that same password, or with a second one we had not seen yet. Rather than wait to confirm, we pulled every device off the network so no compromised account could authenticate while we worked up a detailed report.

By the time we had the partner on the phone, the mailer was walled off mid-send, the RDP session was severed, every reconnect from the Romanian address was being dropped, and the domain controller had nothing on it but three credential checks that never went anywhere. Huntress SOC analysts also provided a full report of immediate remediations for the partner to follow to bring their environment back online as soon as possible.

The site serving that payload was a victim, too. ipelc.gob[.]bo belongs to a genuine Bolivian state institute, and the actor was running the phishing kit on it without the institute's knowledge. Huntress notified Bolivia's national CSIRT, the Centro de Gestión de Incidentes Informáticos (CGII), which operates under the state ICT agency AGETIC, that the domain had been compromised and was serving a Boots-branded kit from /boots_store/. We reported what we had and took no further action on a system that was not ours to touch. Remediation is theirs to make. 

Conclusion

Strip away the Boots branding and the Bolivian government domain, and this is an old story told with current tools. An internet-facing remote-access portal, a valid set of credentials, no second-factor authentication, and an attacker who logs in and gets to work. The password was not even held closely: by the time our actor was reconnecting on May 16th, the portal had already validated that same credential for an unrelated brute-force bot and for another address days earlier. What the actor did once inside (run a legitimate bulk-mailer against nine million addresses) is almost mundane. The cleverness was all in the staging: a tool that no antivirus will flag, sent directly to Mail Exchange (MX) so it does not need the victim's own mail server, pointing to a payload parked on a hijacked government site that no reputation engine will block.

Indicators of Compromise (IoCs)

Network indicators

File hashes (SHA256)

Host and campaign artifacts