Massive Phishing Campaign Impersonates Boots via Hijacked Terminal Server

In the highly dynamic and interconnected cyber threat landscape, the traditional dividing lines between ransomware threat actors and commercial fraud operations are rapidly breaking down. Historically, attackers who compromised enterprise Remote Desktop Services (RDS) environments sought immediate monetization through lateral movement, active directory domain compromises, or mass ransomware deployment. However, a masterclass in infrastructure hijacking has recently been exposed by cybersecurity researchers, uncovering a highly organized, large-scale phishing campaign targeting nearly nine million UK consumers by impersonating the prominent UK health, beauty, and pharmacy retailer, Boots.

Rather than relying on conventional, short-lived phishing landing pages and bulk-sending servers—which are rapidly flagged and blocklisted by automated security filters—the threat actors utilized a sophisticated dual-hijacking methodology. They compromised a small UK-based business’s terminal server to use as an active staging ground for email distribution, while simultaneously compromising a trusted government domain in South America to host their malicious credential and payment-harvesting storefront. The result was a highly effective, reputation-jacking campaign that exploited the clean IP space of an unwitting small business and the inherent authority of a public sector entity.

Inside the Phishing Campaign: Brute Force and Session Hijacking

The initial phase of the intrusion highlights the danger of exposing administrative portals to the public internet without robust authentication controls. The victim organization, a small UK-based business operating only 25 endpoints, was running a Remote Desktop Session Host server (commonly referred to as a terminal server) with its RDWeb Access portal left completely exposed to the open web. This server became the focal point of a massive, distributed brute-force and credential-stuffing assault.

According to an analysis of the server’s Internet Information Services (IIS) logs, the threat actors executed a relentless dictionary attack over a sustained four-day window. The sheer volume of the assault was immense:

• Total Brute-Force Volume: Over 206,000 HTTP POST authentication requests targeting the RDWeb portal.
• Source Infrastructure: More than 8,000 unique IP addresses were used to distribute the origin of the requests and evade automated IP-based rate-limiting controls.
• Primary Attacking IPs: A single IP address, 87.251.64[.]134, single-handedly fired approximately 48,000 requests. Additionally, a subnet of ten compromised hosts residing within the 88.210.63[.]0/24 range contributed another 84,000 requests.
• Success Rate: Out of the massive pool of 206,444 login POST attempts, exactly four requests returned an HTTP 302 Redirect status code rather than the standard HTTP 200 OK failure page. This 302 redirect signaled successful form authentication.

Unfortunately for the victims, all four successful redirections mapped to a single compromised Active Directory domain account that had been published to the RDP box. The threat actors had successfully gained their foothold.

Reconstructing the Attack Timeline

The security incident took a decisive turn on May 15, 2026, when the business onboarded an Endpoint Detection and Response (EDR) agent mid-incident. Because the EDR agent was installed after the initial credential-stuffing phase, security analysts did not have baseline telemetry of the initial breach. However, within hours of installation, a critical alert fired at 03:38:53 UTC on May 16, 2026, flagging a successful Remote Desktop Protocol (RDP) login originating from a Romanian IP address: 212.93.152[.]37.

While the attacker had cleared the Windows Security Event Log (Event ID 4624) to cover their tracks, analysts bypasses this defense by correlating separate operational log channels. By reconstructing the login flow across four distinct operational sources—the IIS logs, the Remote Desktop Gateway logs, the TS-RemoteConnectionManager logs, and the TS-LocalSessionManager logs—analysts discovered a critical operational reality:

At 03:36:28 UTC, the LocalSessionManager log registered Event ID 25, indicating a “Reconnection to an existing session” (specifically Session 16) rather than a brand-new user logon. This established that the threat actors had accessed the box during an earlier session, set up their entire phishing infrastructure, disconnected to remain idle, and returned on the morning of May 16 to execute the campaign.

The Devil’s Workshop: Repurposing the Terminal Server

Once inside the terminal server, the threat actors did not behave like standard cybercriminals. They did not deploy ransomware, establish persistence via sophisticated backdoors, or exfiltrate sensitive corporate databases. Instead, they repurposed the high-compute Windows environment as a massive, direct-to-destination bulk email staging area.

On the desktop of the compromised domain user, analysts recovered a staging directory brazenly named dam pe uk puterniiicccc, a Romanian slang phrase translating to “we hit the UK hard”. Within this directory lay the core engine of their campaign:

• Gammadyne Mailer (gm.exe): A legitimate, commercially signed bulk email marketing application. Because the executable was a legitimate, digitally signed commercial tool, standard signature-based antivirus and endpoint protection tools failed to flag its presence as malicious.
• The Project File (dracii.mmp): The Gammadyne configuration file, explicitly named “dracii” (which translates to “the devils” in Romanian). This project file contained the complete layout of the campaign, including merge fields, payload URLs, and delivery instructions.
• The Target Databases: Six distinct text files labeled sequentially from milk (1).txt to milk (6).txt. Together, these lists contained a combined total of 8,894,920 unique target email addresses. Detailed analysis of the lists revealed a broad, international database of consumer accounts spanning Gmail, Hotmail, Yahoo, and regional UK mail domains.
• Linguistic Artifacts: A filtered subset file in the directory was labeled fara gmail (Romanian for “without Gmail”), indicating the attackers had systematically culled certain providers to segment their targets or evade Google’s strict spam detection mechanisms.

Technical Evasion and Direct-to-MX Delivery

The configuration details parsed from the dracii.mmp project file revealed why this specific phishing campaign was so technically dangerous to standard secure email gateways (SEGs). The threat actors engineered their campaign to utilize Direct-to-MX (Mail Exchange) delivery.

Normally, corporate email transmission involves relaying. An email client hands a message to its local outbound mail server (such as Office 365 or Google Workspace), which then connects to the recipient’s inbound mail server on the sender’s behalf. Direct-to-MX delivery cuts the middleman out entirely. The Gammadyne Mailer application acted as its own Mail Transfer Agent (MTA). For every one of the nearly nine million targets, the software performed its own real-time DNS MX record lookup and established a direct outbound TCP connection on Port 25 straight to the recipient’s mail gateway.

This tactic offered several structural advantages for the cybercriminals:

1. There was no corporate email provider account or outbound mail relay to be throttled, capped, or shut down for violating terms of service.
2. The massive flow of outbound mail originated from the clean, unblocked IP address space of the compromised UK small business.
3. The victim business’s IP address bore the ultimate cost of blocklisting, leaving the attackers’ own operational infrastructure completely insulated.

Furthermore, to empty the massive recipient databases before security analysts or automated network monitoring systems could react, Gammadyne Mailer was configured to initiate 666 concurrent sending threads executing in rapid batches of 50, with absolutely no outbound throttling, DKIM, or DomainKeys signing. The thread count of 666 was a deliberate, dark nod to the project file name “the devils”.

To prevent spam filters from clustering and blocking identical messages, the attackers used Gammadyne’s native dynamic merge fields to enforce a high level of personalization:

The subject line was structured with variable tokens: Dear Valued Customer, [[-Email-]] - [[-Now-]] - [[random_digits]]. As a result, every outbound email contained a unique combination of the recipient’s own email address, the exact date, and a randomized, multi-digit transactional reference code. Because no two messages appeared identical to automated security scanners, the campaign bypassed standard reputation-based heuristic analysis.

The Social Engineering Bait and Bolivian Gov Infrastructure

The human element of the scam relied on a highly enticing retail lure. Targeting consumers during a period of high economic sensitivity, the email promised a free “Boots Beauty Sample Pack” valued at over £50. To claim the prize, victims were urged to click a link to complete a brief customer satisfaction survey.

Once a victim clicked the link, they were redirected to a remarkably realistic, spoofed Boots storefront designed to harvest both identity and financial data. The page systematically collected:

• Full Name
• Primary Email Address
• Date of Birth
• Mobile Phone Number
• Physical Home Address

At the final stage of the funnel, the victim was prompted to pay a minor £1.50 “delivery fee” to ship their free beauty pack. This step redirected them to a payment card gateway specifically designed to harvest credit and debit card numbers, expiration dates, and CVV security codes.

Exploiting Government Domain Authority

The most alarming defensive evasion tactic in this campaign was the hosting of the phishing kit. Instead of purchasing look-alike domains or using free web hosting, the threat actors compromised the legitimate, official website of Bolivia’s Instituto Plurinacional de Estudio de Lenguas y Culturas (IPELC), hosted at ipelc.gob[.]bo.

Under the compromised government site, the actors created a hidden subdirectory: /boots_store/. Hosting the fraudulent storefront on a legitimate .gov or .gob government domain provided the campaign with instant credibility. Most automated URL analysis engines, secure web gateways, and endpoint reputation filters treat official public-sector domains as inherently safe. This allowed the scammers to easily bypass corporate web-filtering policies and secure email gateway controls, ensuring maximum deliverability and victim conversion.

Threat Actor Profile and Strategic Mitigation

The tradecraft, linguistic fingerprints, and digital footprints recovered from the terminal server heavily point to an organized, Romanian-speaking cybercriminal operator. The persistent use of Romanian language file names (such as “dracii” and “fara gmail”) combined with the slang naming of the staging folder (“we hit the UK hard” written as dam pe uk puterniiicccc) and the originating IP address in Romania (212.93.152[.]37) strongly suggest Eastern European attribution.

Furthermore, structural indicators inside the recovered dracii.mmp project file exposed a wider campaign trail. The project’s active logging and alarm paths still pointed to UNC network shares on an entirely different, previously compromised Active Directory domain: \\[REDACTED].local\RDS\RDSRedirections\... \Crack\gm.log. This reveals that the threat actor operates a highly efficient “phishing-as-a-service” or mass-spam pipeline, systematically rotating through a catalog of hijacked Remote Desktop environments.

Historically, this threat group has targeted UK consumers since at least July 2025. Rather than limiting themselves to retail brands, they rotate their social engineering lures between three high-yield verticals:

• Retail Scams: Large-scale consumer brands such as Boots.
• Government Scams: