This first installment focuses on phishing email generation—specifically, how threat actors are leveraging artificial intelligence to evade detection at scale.

From Spintax to AI: The Evolution of Email Obfuscation

The concept of automated email variation isn’t new. Years ago, while investigating a Royal Ransomware campaign, I observed affiliates using a rudimentary spintax generator—a GUI tool adapted from the world of blackhat SEO. The operator would select non-critical words in their phishing template and provide alternative options. The tool would randomly replace these words in each outgoing message, creating sufficient variation to evade signature-based detection.

The results were predictable: roughly half the emails read like plausible English, while the other half emerged as barely coherent word salad. Anyone who has spent significant time analyzing spam has undoubtedly encountered these spintax-generated messages, though many analysts may not have recognized them as such.

Spintax represented the floor, not the ceiling. Today, as generative AI reshapes how we create content online, the barrier to entry for sophisticated email obfuscation has collapsed. Modern threat actors use AI to generate variations in words, fonts, spacing, and coloring that appear nearly identical to the human eye but produce wildly different HTML representations—each one a unique fingerprint that evades pattern-matching filters.

More significantly, we’re witnessing a fundamental shift in the threat landscape: away from locally-run scripts and toward API-based Obfuscation-as-a-Service platforms. These services democratize advanced evasion techniques, placing enterprise-grade capabilities in the hands of relatively unsophisticated operators.

Enter HTMLMIX (sometimes stylized as HTM|MIX), a tool that exemplifies this new paradigm. What follows is a technical examination of this platform: its capabilities, its reputation among established threat actors, how it operates at scale, and what defenders need to know to counter the next wave of AI-obfuscated phishing.

HTMLMIX’s Obfuscation Toolkit: From Basic HTML Tricks to AI-Powered Content

To understand what makes HTMLMIX effective, let’s examine how it processes two common scenarios: a straightforward invoice scam and a Microsoft 365 credential harvesting attempt.

Example 1: Invoice Fraud

Example 2: Microsoft 365 Credential Phishing

Now let’s examine what HTMLMIX does to these templates.

Traditional HTML Obfuscation Techniques

HTMLMIX automates several HTML manipulation tactics that have existed for years but previously required manual implementation:

• Trusted domain injection: Sprinkling links to legitimate sites (Google, Microsoft, major news outlets) throughout the email to improve sender reputation scores

• Invisible character insertion: Adding zero-width spaces, non-breaking spaces, and other invisible Unicode characters that alter the text’s digital signature without affecting visual appearance

• HTML structure mangling: Inserting unnecessary tags, randomizing font variations, introducing subtle color changes, swapping semantically equivalent tags, and renaming CSS classes—all producing HTML that looks identical when rendered but appears completely different to signature-based detection systems

When we apply these techniques to our invoice example, the visual output remains nearly identical—perhaps some minor whitespace differences if you scrutinize closely. However, the underlying HTML expands from a few hundred bytes to over 21KB of obfuscated code, with each instance unique enough to evade pattern matching.

Interestingly, some of these older obfuscation tactics now actually increase detection rates. Modern machine learning-based filters have been trained to recognize the signatures of excessive HTML manipulation, meaning blind application of every available technique can backfire. HTMLMIX’s “auto mode” attempts to balance evasion with plausibility, though with mixed results.

Algorithmic Obfuscation Methods

Beyond familiar HTML tricks, HTMLMIX incorporates more sophisticated algorithmic techniques:

• Image pixelation as HTML: Converting images into HTML structures composed of colored div blocks, creating visually identical images from completely different code

• Tabular randomization: Fragmenting text into table cells with randomized word counts per cell, breaking up the linguistic patterns that content-based filters analyze

• CSS class extraction: Programmatically extracting inline styles, generating unique CSS class names, and applying these classes to elements—creating functionally identical styling from technically unique code

These techniques represent an evolution beyond simple find-and-replace operations. They algorithmically restructure the email’s technical composition while preserving its visual and functional presentation.

AI-Powered Features

Where HTMLMIX truly distinguishes itself is in its AI integration. The platform offers four AI-powered capabilities:

1. Regional Trending Words

The tool can inject trending terms from selected geographic regions, potentially improving deliverability by making emails appear more current and contextually relevant.

2. AI-Generated Synonyms

This feature tackles the same problem as spintax but with dramatically improved results. We tested it on our invoice example with a creativity setting of 0.6 (on a scale from conservative to creative).

Here are three variations it generated:

The improvement over spintax is substantial. Each version forms coherent, realistic sentences rather than word salad. The tone shifts slightly between variations—a careful reader might detect the inconsistency—but casual recipients would likely find nothing suspicious about any individual message.

3. AI-Generated Preview Text

The tool can generate varied preview text (the snippet visible in email clients before opening), ensuring that even this metadata differs across messages.

4. Automated Email Thread Fabrication

Perhaps the most ambitious AI feature, added to HTMLMIX in October 2025, attempts to generate realistic email conversation chains. In business email compromise (BEC) attacks, sophisticated threat actors often hijack legitimate email threads, then inject fraudulent payment requests. We also observe completely fabricated threads, though these typically look obviously fake.

Testing this feature on our invoice example produced mixed results. The generated conversation flow made logical sense—emails about confirming an invoice, following up on payment, and discussing timeline concerns.

However, all the participants used personal email addresses (@gmail.com, @icloud.com), which should immediately raise red flags in a B2B payment context.

When we tested the feature on the Microsoft 365 phishing email, it generated a completely unrelated conversation thread about quarterly sales reports, demonstrating the AI’s current limitations in maintaining contextual relevance.

Real-World Output: Before and After Obfuscation

To see these techniques working in concert, we processed a basic phishing template through HTMLMIX’s auto mode, which applies a balanced selection of obfuscation techniques.

The “before” shows clean, minimal HTML—a simple email alert about a Google Workspace storage limit with a header, body text, and call-to-action button. Standard structure, straightforward code.

The “after” reveals what modern obfuscation looks like: the HTML has been shredded into fragments, restructured with nested divs and spans, injected with randomized CSS classes, and padded with invisible characters. The visual presentation remains virtually identical, but the underlying code has been transformed into something unrecognizable to signature-based detection systems.

This transformation happens in seconds via API, enabling threat actors to generate thousands of unique variants from a single template.

Masking Malicious Links with Trusted Domains

Obfuscating email content addresses only half the detection challenge. Attackers must also obscure the destinations of their links, since URL reputation checking remains one of the most effective anti-phishing controls.

HTMLMIX offers an optional upsell called “Trust Redirects” that leverages cloud infrastructure from trusted providers. The concept is straightforward: a link pointing to an Amazon S3 bucket or Microsoft Azure endpoint is far less likely to be blocked than a link to a newly-registered suspicious domain.

The service charges $20 per redirect, with the first test redirect free. For an additional fee, operators can purchase a “Personal Server” that increases their balance to $200+ and adds AWS keys for $10 per redirect instead of $20, lowering the per-campaign cost for high-volume operators.

The interface allows attackers to specify the destination URL, customize the page title (e.g., “Loading your Behind the Surface account”), choose the URL format (virtual-hosted vs. path-based), select parameter formatting (query vs. hash), and optionally append the .html extension.

Of course, this approach involves inherent tradeoffs. Amazon and Microsoft actively respond to abuse reports, meaning these redirects have limited lifespans—hours or days rather than weeks. But for time-sensitive campaigns targeting specific organizations, the temporary legitimacy can be worth the cost. The attacker simply needs the link to survive long enough for targets to click, not indefinitely.

Why Threat Actors Love HTMLMIX

Like many dark web services, HTMLMIX wraps itself in disclaimers about “legitimate,” “research,” and “educational” purposes. The interface prominently displays warnings that users are “solely responsible” for ensuring compliance with applicable laws and that the service “categorically forbids” the use of the platform for illegal purposes, including fraud, malware distribution, and spam.

These disclaimers are, of course, meaningless. HTMLMIX is exclusively advertised on underground forums and can only be purchased using cryptocurrency—operational security measures that belie any pretense of legitimate use.

What reveals the service’s true purpose is the enthusiastic feedback from established threat actors in underground communities.

One endorsement comes from a moderator of XSS, a top-tier hacking forum, who is recognized as a filter bypass expert with activity dating back to 2012. When another user requests advice on phishing obfuscation, he replies simply: “There’s a service called htmlmix that’s way ahead in this area.”

Another testimonial comes from an established vendor on multiple top-tier forums:

The pattern continues across multiple underground communities. Lesser-known operators echo similar sentiments:

This isn’t theoretical threat intelligence. These are real operators, some moving hundreds of thousands of phishing emails weekly, providing unprompted testimonials about a tool that measurably improves their success rates.

From GUI to API: Scaling Phishing Campaigns

The threat posed by HTMLMIX extends beyond its technical capabilities. What makes it particularly dangerous is its scalability.

Individual phishers might use the web interface to manually process templates, but sophisticated operators integrate HTMLMIX directly into their attack infrastructure via API. This transforms obfuscation from a manual bottleneck into an automated pipeline component.

The typical workflow looks like this:

• Template preparation: The attacker creates a base phishing template with placeholder variables for personalization

• API integration: The template is submitted to HTMLMIX’s API endpoint with specified obfuscation parameters

• Variant generation: HTMLMIX returns multiple unique HTML variants, each with different obfuscation applied

• Email platform integration: These variants are fed into commodity SMTP services or compromised email accounts for distribution

• Redirect chaining: Links are processed through the Trust Redirects service or similar URL laundering platforms

• Campaign execution: Thousands of unique emails are distributed, each technically distinct despite originating from a single template

The API documentation shows standard bearer token authentication and straightforward error handling. Rate limits exist (the API can be exhausted with heavy use), though the specific quota limits are not publicly disclosed.

HTMLMIX’s obfuscation service integrates directly with complementary attack infrastructure. The API can integrate with traditional email delivery methods, and the tool also has a partnership with a novel delivery system that will be the topic of an upcoming analysis.

Defending Against AI-Powered Obfuscation

HTMLMIX is just one tool among many, but it provides a clear view into where the threat landscape is heading. The question isn’t whether AI will transform phishing; it already has. The question is whether defenses will evolve quickly enough to keep pace.

What we’re witnessing is the early stage of AI-powered social engineering. The AI-powered features may currently feel somewhat gimmicky—e.g., the synonym generator produces inconsistent tone, and the thread fabrication creates contextual mismatches. But these capabilities will improve. Language models are advancing rapidly, and tools like HTMLMIX will integrate better models as they become available.

The phishing emails of 2026 will be more convincing than those of 2025, which are already more convincing than those of 2024. This trajectory demands that defenders move beyond reactive controls toward adaptive systems that can recognize novel evasion techniques.

Organizations that maintain security postures designed for yesterday’s threats will find themselves increasingly exposed. Defending against AI-powered phishing requires AI-powered defenses, coupled with fundamental security practices that remain effective regardless of technical sophistication.

I was analyzing a phishing kit last week when I noticed something in the HTML that shouldn't have been there: a hidden form field with no visible counterpart. Other parts of the code tracked mouse movements, keyboard presses, and clicks to verify human behavior. But buried at the bottom was a hidden input field programmatically added to the form, invisible to users, with the field name "website":

// Hidden honeypot field for bots
const honeypot = document.createElement('input');
honeypot.type = 'text';
honeypot.name = 'website';
honeypot.style.display = 'none';
form.appendChild(honeypot);

// Check if honeypot was filled (by bots)
form.addEventListener('submit', function() {
if (honeypot.value !== '') {
emailError.textContent = 'Security check failed.';
emailError.style.display = 'block';
return false;
}
}

It wasn't part of the UI. The victim would never see it. So, why was it there? Because it wasn't designed to catch victims. It was designed to catch us.

The Invisible Tripwire

As a Cyber Threat Hunter, I analyze dozens of phishing sites per month. Most are either sloppy cut-and-paste jobs or subscription Phishing-as-a-Service kits. But this campaign was a little different. The landing page looked boring enough: a clean, corporate-styled prompt asking the user to "Verify your email address" before proceeding:

As expected, the contents of this field were sent on to the Adversary-in-the-Middle kit, in order to pre-file the email field on the credential request. But when I inspected the DOM, I found a discrepancy between what was rendered and what existed in the code.

Okay, this honeypot field technique isn’t actually new, and in fact, it has a legitimate pedigree. Web developers have used honeypot fields since the early 2000s to protect contact forms and registration pages. The logic is elegant: humans can’t see the hidden field, so they leave it empty. Spam bots parse the HTML, see an input called “website”, and dutifully fill it with a URL. Any submission with data in the honeypot gets silently discarded.

It’s a brilliant, passive defense. No CAPTCHA friction or user annoyance, just a quiet trap to catch automated abuse. And we see here how phishing operators have copied it, line for line, to catch us.

Here’s how it works in their context: Rudimentary security scanners parse raw HTML. When they encounter an input field, their programming compels them to fill it to test for vulnerabilities or trigger a submit action:

• Hidden field empty? Likely human, proceed to AitM proxy kit

• Hidden field has data? Likely bot, display an error message
  

The Engine Under the Hood: Traffic Cloaking

The honeypot is just one of the entry-level filters. Behind it sits a massive backend industry called Traffic Cloaking. Originally developed to both stop as well as perpetrate ad fraud, now weaponized for phishing. The sophisticated services cost $1000 per month and fingerprint every visitor in milliseconds. That’s not script kiddie money; that’s infrastructure investment. They’re checking:

Behavioral biometrics: Mouse activity, typing rhythm. Humans are messy; bots are linear and instant.

Device fingerprinting: Does navigator.webdriver return true? Does the WebGL renderer identify as “Google SwiftShader” (headless Chrome) instead of actual hardware?

IP reputation: Residential ISP or a security vendor’s datacenter?

Poisoning the Well

Here’s where it gets devious. When phishing kits detect bots, scanners, and researchers, they don’t just block you. They serve a “Safe Page”:

Why? To poison threat intelligence feeds.

When a security vendor’s crawler lands on that blog, it categorizes the domain as, for example, “Retail” or “Technology/Benign.” That classification propagates to firewalls, URL filters, and blocklists, so the domain gets whitelisted. By the time a real victim clicks the link and sees the actual phishing page, the security tools have already stamped it safe.

I’ve watched domains stay active for weeks or even months using this technique. Without cloaking, most phishing sites get burned promptly.

The Mirror World: Defense Becomes Offense

It always makes me grin when I see that attackers often aren’t inventing new techniques, but they’re just copying ours.

Legitimate sites use honeypots to keep spam out of their databases, while phishing sites use honeypots to keep scanners out of their infrastructure. Same code, flipped context.

This pattern repeats everywhere:

CAPTCHA, originally designed to defend websites, now appears on at least 90% of phishing sites I analyze. Dual purpose:

Technical: Stops automated crawlers from reaching the phishing content.

Psychological: Builds trust. When victims see a Cloudflare Turnstile or Google reCAPTCHA, they think, “This site has security checks. It must be legitimate.”

What’s Behind the Curtain

Why work so hard to hide? Because what’s protected is valuable: real-time Adversary-in-the-Middle attacks that steal session cookies, not passwords. The kit acts as a live proxy, relaying credentials and 2FA codes to the actual service. When the real site issues a session cookie, the attacker snaps it up. No password needed, no 2FA bypass required. Just grab the token from the cookie, and you’re in. Search the inbox for monetizable content, like an invoice to replicate, and then burn it by sending out the next wave of phishing emails. That’s worth protecting with counter-intelligence.

How to Fight Back

1. Scan Like a Victim, Not a Server

Cloaking systems blacklist datacenter IPs instantly. In our hunt program, we route analysis traffic through residential and mobile proxies and mimic real hardware/software fingerprints, so we see what targets see. Be aware, though, that sometimes that means the page gets blocked by an ISP security appliance or DNS filtering.

2. Hunt for Negative Space

The honeypot I found was invisible to the eye but obvious as soon as I looked at the code (although, to be fair, this is because this landing page didn’t use any obfuscation). If feasible, update your detection rules to flag hidden form inputs on login pages.

3. Stop Teaching Users That CAPTCHAs Mean Safety

We spent years training users that a padlock icon and a CAPTCHA are good signs, and attackers know this. By now, attackers use CAPTCHA and SSL more than legitimate sites do.

Update your security awareness programs: A CAPTCHA on an unexpected link is not a safety feature. At best, it’s a gate designed to keep automated defenses out, and at worst it’s a ClickFix-style attack. If you have to solve a puzzle just to view a “shared internal document,” you’re walking into a trap.

The Arms Race Continues

Front-end honeypots on phishing sites are just one facet of a broader shift I’ve watched play out over the last few years: attackers treating their campaigns like legitimate SaaS products: optimizing uptime, managing bot traffic, A/B testing landing pages.

CleanTraffic: A typical traffic-cloaking portal to thwart detection of malicious sites.

We’re up against engineering teams with product roadmaps and customer support channels. The fix isn’t another poster about “hover over the link” or a longer PowerPoint about misspellings. It’s a mindset shift in which we stop treating phishing as a side quest. Attackers have already stolen our honeypots, our CAPTCHA, and our playbooks. The only real question now is whether we’re willing to steal something back from them: their discipline. If we can teach our defense teams to apply the science and art of analysis as effectively as attackers do, then the next time hidden code shows up in a phishing kit, it won’t be their tripwire. It’ll be ours.

Today we publish the first public findings on MrJayOTP, an operational “OTP bot” that turns phone calls into a high-velocity tool for harvesting one-time passcodes, all packaged in a SaaS solution with slick marketing. We’re also publishing an audio sample so defenders can hear how this works. This post walks through what we observed, why it matters, and what security teams should do now.

What is MrJayOTP?

At a high level, MrJayOTP is a voice-first social-engineering platform packaged as a subscription-based service. It provides a single, integrated workflow for running scripted voice calls, compromising one-time passcodes in real time, and surfacing those codes to attackers who can then complete an authentication or transaction.

An attacker begins a process, such as account takeover or a money transfer, and hits an MFA request. Attack foiled, right? No. They send the target with the name of the service over to MrJayOTP, and with one click, the bot makes a phone call and obtains the MFA from the victim via social engineering.

The components of this attack aren’t new. The attacker could attempt to impersonate the bank themselves. Or they could grab some code off of GitHub, hook it into a compromised corporate 3CX phone switch (PBX), hook it into a voice generator AI, and run it on a local machine. In fact, the current iteration of MrJayOTP itself is at least number four in a product line from this developer dating back to 2021. But by packaging all of the needed components into a SaaS product, the barrier to entry for fraud becomes that much lower.

Several characteristics make the product noteworthy:

• Voice-based man-in-the-middle (MiTM): The platform’s primary vector is a phone call that targets the human step in multi-factor authentication. It is not malware, it is not a network interception tool, and it is not a browser prompt. Instead, it persuades the target — via audio — to reveal or enter a code.

• OTP-agnostic capture: Captured codes may be delivered via SMS, generated by an authenticator app, or come from any other source. The platform exploits the human act of reading or entering the code rather than breaking the authentication algorithm.

• Real-time DTMF/read-back capture: The system captures target keystrokes and read-back codes during the call and displays them immediately on the attacker’s screen, enabling real-time use.

• Turnkey workflow and scale: MrJayOTP bundles caller-ID spoofing, multilingual synthetic voices, a growing list of pre-built modes (banks, brokerages, carriers, exchanges, payment gateways, cloud services, etc.), customizable scripts, and automation. That integration lowers the operational skill bar and enables higher-volume campaigns.

Why this is dangerous

Security teams are staring to understand that OTP is a weaker MFA factor. Platforms like MrJayOTP change the risk calculus in several important ways:

• Caller-ID spoofing, paired with authoritative scripts and a sense of urgency, can make a call sound legitimate.

• Human-centered bypass: The attack bypasses authentication by targeting a person. Even authenticator app codes and platform-based prompts are vulnerable if the target reads them aloud or types them on the phone keypad.

• Scale and efficiency: By combining multiple features into one panel, the platform enables less sophisticated operators to execute high-volume attacks that previously required more skill and tool-chaining.
  

Defenders’ checklist

The following mitigations are practical and intentionally high-level.

• Move to phishing-resistant MFA where feasible. Promote FIDO2/security keys and platform-bound asymmetric credentials over SMS or other OTP-based systems.

• Monitor call and authentication telemetry together. Correlate unusual call patterns with authentication attempts — e.g., a spike in inbound calls that precede high-value auth attempts, or abnormal DTMF activity.

• Harden call-center and customer workflows. Train agents to avoid asking for OTPs, implement escalation paths for suspicious requests, and require out-of-band verification for high-value changes.

• Improve user awareness. Educate users and team members on how this type of attack works. Click below to listen to a recording of a MrJayOTP bot request targeting John’s PayPal account.

Back-end notes:

Telegram as a telemetry channel: During analysis we observed that the platform streams metadata — including target phone numbers and the services being impersonated — to a Telegram channel under admin control. This stream functions as a real-time activity log: it shows which numbers are being targeted and what brand or service the operator is portraying during each call.

Azure AI: The bot hooks into Azure AI to generate the speech:

Upstream services: The bot relies on an upstream provider for routing voice calls. Below is a screenshot from the developer’s device making payment for a route via cryptocurrency:

We can use that data to see payment flow. The upstream provider sends those payments to a Binance wallet:

History: MrJayOTP has undergone a few iterations dating back to 2021:

Closing thoughts

Tools like MrJayOTP demonstrate a progression toward automation and AI on the social side of fraud. The controls that once worked at low scale can become brittle when paired with scripted persuasion and real-time capture. The best defenses combine phishing-resistant authentication, telemetry-driven detections, and ongoing user awareness training.

We’ve recently uncovered CleanTraffic; a new filtering service being used to conceal malicious links from security tools.

🔍 How it works:

When someone clicks a protected link in a phishing email, CleanTraffic uses behavioral analytics like mouse movement to distinguish bots from real users:

Real users are funneled into the phishing flow.

Bots and scanners are routed to harmless decoy pages.

This traffic filtering keeps malicious content off the radar. The platform even includes campaign analytics, much like legitimate marketing tools.📊

As major CDN providers tighten abuse controls, threat actors are turning to such alternatives. Understanding these systems is key to tracking phishing operators who outsmart automated detections.

Have you encountered similar tradecraft in your investigations? Share your thoughts below! 🧠

#Cybersecurity #Phishing #ThreatIntelligence #Cybercrime

Subscribe now