A phishing attachment recently caught by a client's e-mail security filter weighed in at 2,589 kB — far larger than the few tens of kilobytes a self-contained HTML credential-harvesting page normally requires. That size difference is the whole story, and it points to a technique aimed squarely at the AI and NLP-based content scanners now built into many e-mail security products. (Source: Isc)

Here is the mechanism. The attacker builds a working phishing page — in this case a SharePoint-themed credential form of roughly 11 kB — and then appends a massive block of filler after the closing </html> tag. The filler sits inside a single HTML comment containing a little over 430,000 copies of the letter "X." Because it lives in a comment placed after the payload, it changes nothing about how the page renders or behaves when a victim opens it.

The entire file is then wrapped in trivial obfuscation: every character is stored as a \uXXXX escape and passed to unescape() inside a document.write() call. That encoding stores each character as six bytes, so the padding is inflated twice — first by the comment itself, then by the escaping. The block of "X"s ends up accounting for roughly 97% of the file.

The point is not to hide the malicious code. The point is to drown it out. A growing number of e-mail products score message content with NLP models or hand it to an LLM, and this is where the bulk matters:

• Verdict dilution — when the genuinely malicious portion is a tiny fraction of a large, low-information whole, an averaged or probability-based classifier score can fall below the threshold at which the message would be blocked.
• Budget exhaustion — the sheer volume of data (and, for an LLM, the token count) can push processing past a scanner's per-message time or size budget, causing it to cut analysis short or skip it entirely.

For your organization, the practical concern is that a message can clear automated content analysis and still land a functional credential-harvesting page in a user's inbox. The attachment looks benign to the model precisely because most of it means nothing at all.

Attack Chain: From Attachment to Credential Theft

The attack begins before the phishing message ever reaches an inbox. The sender built a message by hand rather than routing it through a normal mail server, and the header artifacts give that away: an empty envelope sender (MAIL FROM:<>), no Date header at all, and an X-Priority value of 0 that falls outside the 1-to-5 range Microsoft defines. Because there was no envelope domain, SPF evaluation fell back to the HELO/EHLO identity and ended up checking postmaster@[10.88.0.3] — an RFC 1918 internal address presented by a host actually running on public IP 35.195.254.112 in Google Cloud. No DKIM signature was present, so DMARC failed.

For a receiving mail system, that combination is a strong signal the message was generated by a simple script talking directly to the target's mail server. In practice, a homemade sender like this skips the infrastructure that would normally leave a clean authentication trail, which is exactly what a low-effort credential-harvesting run wants.

Step two is the delivery vehicle. The message posed as a Microsoft Teams notification about a SharePoint document, with a file attached directly. The attachment name — <company>_Pending_Approvals#<digits>.xls.html — carries a double extension that reads as a spreadsheet but is actually HTML. That naming trick matters because a user scanning for a familiar .xls file may not register the trailing .html, and HTML attachments open directly in the browser rather than in a sandboxed Office viewer.

Step three is the payload's own obfuscation layer, which sits underneath the padding block covered earlier. The entire page was stored as a long string of \uXXXX escapes and reconstructed at runtime:

The whole page was passed to

document.write(unescape("\u003c\u0021\u0044\u004f..."))

— the browser decodes the escaped string and writes a live HTML document into the page on the fly.

This is a defense-evasion pattern that maps to MITRE ATT&CK T1027 (Obfuscated Files or Information). A static scanner reading the raw file sees only encoded characters and a single document.write call; the actual <form>, field labels, and submission endpoint never appear in cleartext until a browser executes the JavaScript. For your email gateway, that means the malicious markup a content classifier would key on is not visible at the moment of scanning.

Step four is execution on the endpoint. Once opened, the decoded page renders as a SharePoint-themed credential form. It tries to pull the target organization's logo through the Clearbit logo API to look convincing, though that lookup failed and a placeholder rendered instead — the free Clearbit API was shut down at the end of 2025, a sign the page was assembled from older borrowed or LLM-generated code.

Step five is exfiltration. Any credentials the victim types are sent via an HTTP POST to Formspark, a legitimate form-handling service the attacker abused as a collection point. Routing stolen data through a real SaaS endpoint means the outbound request looks like ordinary web traffic rather than a connection to attacker-owned infrastructure, which complicates network-level detection.

The page also included a routine that intercepts the developer-tools and view-source keyboard shortcuts — a common, low-sophistication anti-analysis touch (MITRE T1622, Debugger Evasion) meant to slow down anyone inspecting the code manually.

Put together, the chain is deliberately simple: an unauthenticated message, an HTML attachment disguised as a spreadsheet, runtime-decoded markup, a cloned login form, and credential capture through a trusted third-party form service. Harvested credentials give an attacker legitimate access to email and SharePoint content, which is difficult to distinguish from normal user activity after the fact.

Business Impact: Detection Gaps and Credential Compromise

The core business problem here is simple: the security control you paid for may have looked at this message, judged it safe, and delivered it to an employee's inbox. If your e-mail filtering depends on AI or NLP-based content scoring — the kind now built into Microsoft Defender for Office 365, Proofpoint, and Mimecast — a message padded to dilute or time out that scoring can slip through with a clean verdict. That clean verdict is the risk. It tells your team the message was checked and cleared.

Consider what actually reached the user in this case: a SharePoint-themed credential-harvesting page that submitted anything typed into it to a Formspark form endpoint the attacker was misusing as a collection point. The page targeted Microsoft account credentials. If an employee entered them, the attacker now holds a working username and password for your Microsoft 365 tenant.

Stolen credentials matter because they turn an outsider into an insider. An attacker logging in with valid credentials looks like a normal user to most monitoring, which is exactly why credential-based intrusions are hard to spot and slow to contain. From a single mailbox login, common next steps include:

• Lateral movement — using the compromised account to reach SharePoint document libraries, Teams channels, and shared mailboxes the user could access.
• Business e-mail compromise — reading and sending mail from a trusted internal account to redirect invoices or request wire transfers.
• Data exfiltration — pulling customer records, contracts, and internal documents that the account had legitimate permission to view.
• Ransomware staging — using the foothold to escalate access and deploy encryption across connected systems.

Each of those carries a cost you can put on a spreadsheet. A redirected wire has to be covered. Exposed customer or health records can trigger breach-notification obligations under regulations like GDPR or HIPAA, which means legal review, notification letters, and regulator engagement regardless of whether money was stolen. Recovery from encryption or account cleanup means downtime and staff hours you had not budgeted for.

The uncomfortable part is where this leaves organizations that invested heavily in AI-driven detection. If you replaced or de-emphasized older signature and reputation checks on the assumption that content-aware scoring would catch what mattered, this technique targets exactly that assumption. The padding does not disguise the malicious page — it drowns it in low-information filler so the averaged verdict falls below the block threshold, or so the scanner runs past its per-message time budget and releases the message rather than delay delivery.

There is a false-confidence problem baked into this. A model-based scanner that returns "clean" produces the same green result whether it read the whole message carefully or gave up on it under a time limit. Your team cannot tell those two outcomes apart from the delivered mail, so a message that was effectively skipped looks identical to one that passed genuine inspection.

Details in this sample also point to a low-effort, reusable kit rather than a targeted campaign. The page tried to pull your organization's logo through the Clearbit logo API, which was shut down at the end of 2025 — so the lookup failed and a generic placeholder showed instead. That is a sign the code was borrowed, aged, or machine-generated, which matters because cheap, repeatable kits get sent in volume. The technique that lands one credential set from your staff will be pointed at everyone else too.

Detection and Immediate Response Actions

Start with your e-mail gateway logs, because the fastest way to find out whether this technique has already reached your users is to search stored attachments for the padding signature. Look for HTML files whose size is disproportionate to their rendered content, and grep decoded MIME payloads for long runs of a single repeated character sitting after a closing </html> tag or inside an HTML comment. The double extension is another cheap filter — flag any attachment matching a pattern like *.xls.html or *.pdf.html, since a legitimate spreadsheet does not arrive wrapped in HTML.

Following the NIST Cybersecurity Framework, here is how to move from that first check to a durable defense.

On the Identify side, inventory which of your inbound controls actually score message content with a per-message time or size budget. That budget is the property this padding targets, so knowing whether your gateway cuts analysis short on large attachments tells you exactly where the exposure sits.

For Detect, tune your filtering to treat the structure itself as suspicious rather than waiting for a content verdict:

• Flag or sandbox HTML attachments that contain a single <!-- comment holding a large, low-entropy block — an entropy check catches a wall of identical bytes trivially.
• Alert on HTML attachments where the JavaScript body is a single unescape() or document.write() call wrapping a long \uXXXX sequence.
• Watch outbound traffic for credential POSTs to third-party form handlers such as Formspark, which this page abused as a collection point.

Because the payload here is credential theft rather than code execution, your highest-value Detect signal is authentication behavior, not endpoint process trees. Query your identity logs for logins from unfamiliar locations or impossible-travel patterns against accounts that received the message. In environments Capstone manages, Adlumin monitors authentication patterns across managed environments and surfaces the anomalous sign-ins that follow a successful harvest, so a stolen SharePoint-themed credential does not quietly turn into inbox access.

For Protect, focus this week on shrinking what a single stolen password can do:

• Require multi-factor authentication on all Microsoft 365 and SharePoint access, so a harvested password alone does not grant a session.
• Force re-authentication and revoke active sessions for any account confirmed to have submitted credentials to the page.
• Rewrite or strip HTML attachments at the gateway where your organization has no business reason to receive them.

The business point of MFA here is specific to this attack: the page collected only a username and password, so an account without a second factor is fully compromised the moment a user submits, while an account with MFA is not.

Under Respond, treat every user who received the attachment as potentially exposed until you confirm otherwise. Pull the recipient list from gateway logs, reset passwords for anyone who opened the file, and check sent-items and mailbox rules on those accounts, since credential theft frequently precedes internal phishing from the compromised mailbox.

For Recover, feed what you found back into detection. Add the padding structure, the \uXXXX-encoded body, and the form-handler destination to your blocklists and detection rules, and pair signature matching with behavioral scoring that judges an attachment on structure rather than averaged content confidence. A control that weights a verdict by the ratio of meaningful content to filler is the one that this padding is built to defeat, so the durable fix is to stop scoring on volume and start scoring on structure.

Validating AI-Based Email Security Against Evasion Techniques

The single most important action is to stop assuming your AI-based email gateway catches obfuscation it was never tested against. The comment-stuffing sample described here delivered a clean verdict precisely because the scanner's content assessment was diluted or timed out — and unless you have tested your own gateway against this structure, you do not actually know how it responds.

Start by asking your vendor a direct question: what are their detection rates for HTML attachments padded with high-volume comment blocks after the closing tag? Most vendors publish aggregate catch rates but not per-technique numbers. Put the request in writing and ask specifically about the "payload first, filler second" pattern and about how their scanner behaves when a message exceeds its per-message time or token budget. If the answer is that oversized content gets released rather than delayed, you have found a gap you can close with layering.

Next, test with real-world samples rather than trusting marketing claims. Following the NIST Cybersecurity Framework in order, the work breaks down like this.

Identify. Inventory which of your email controls perform NLP or LLM-based content scoring, and confirm whether that scoring is your primary verdict or one signal among several. A single AI model that produces the final block/allow decision is your weakest point — that is the design the comment-stuffing technique targets.

Protect. Submit a reconstructed sample — an 11 kB credential page followed by a large repeated-character comment, wrapped in the same unescape()/document.write() layer — to an internal sandbox or a controlled VirusTotal upload. Watch whether the file is scored on its full content or truncated. Then layer detection that does not depend on AI at all:

• YARA rules that match long runs of a single repeated character inside an HTML comment, or a comment block sitting after </html>. This catches the structure regardless of what character the author uses next time.
• Rules that flag document.write(unescape( containing large \uXXXX-encoded blocks, since the six-bytes-per-character encoding is what inflated this file past 2.5 MB.
• Size-to-rendered-content ratio checks, which flag an HTML file whose decoded functional portion is a tiny fraction of the whole.

Detect. Enable aggressive sandbox detonation for any attachment carrying embedded HTML structure, especially double extensions and files that decode to markup. Detonation observes actual behavior — the POST to a form-handling service, the dynamic logo lookup, the keyboard-shortcut interception routine — none of which a content classifier scores and none of which padding can dilute.

Against any reasonably capable model, a solid block of a single repeated character would be a blunt instrument at best, since it is trivially recognizable as padding.

That is the encouraging part: the technique is crude. A signature or entropy check that specifically looks for it will fire reliably, which is exactly why you do not want AI scoring to be the only thing standing between this attachment and an inbox.

Respond and recover. When your YARA or sandbox layer catches a comment-stuffed sample the AI gateway passed, treat that as a tuning signal, not a one-off. Feed the sample back to your vendor, ask for a rule update, and re-test. SentinelOne inspects the file as it lands on the endpoint across managed environments, catching the credential page and its POST behavior even when the gateway released the message — a second independent verdict that does not share the gateway's blind spot.

No single AI model catches every obfuscation variant, and the next sample will not use the same filler character. Independent detection layers — signatures, sandboxing, endpoint inspection — are what turn a missed gateway verdict into a caught one.

What to Do If Compromise Is Suspected

The moment you confirm an employee opened <company>_Pending_Approvals#<digits>.xls.html and entered credentials, treat those credentials as attacker-controlled and disable the account immediately. Because the form posted to a third-party data collector, you have no way to know when the attacker will use what they captured, so speed matters more than certainty.

Work through the following in the order below, and keep the timeline: this was a credential-harvesting page, not a dropper, so identity containment comes before endpoint forensics.

Contain and preserve evidence

• Isolate the endpoint that opened the attachment from the network — pull it from the LAN and disable Wi-Fi, but do not power it off. This preserves volatile evidence while stopping any outbound session.
• Capture memory before disk. Take a live memory image with a tool like Volatility-compatible acquisition (WinPMem, DumpIt) so browser session tokens and any in-memory artifacts survive, then take a full disk image for offline analysis.
• Preserve the raw e-mail and its decoded attachment as evidence, along with the gateway verdict, so your investigation and any later legal review have the original sample.

Reset identity and force re-authentication

Reset the password for every user who opened the attachment, then revoke active sessions — a password reset alone does not kill a session where the attacker already holds a valid token. In Microsoft 365, revoke sign-in sessions and require re-authentication across all devices.

Because the page harvested credentials rather than dropping malware, the attacker's most likely next step is an interactive login as your user — which is why session revocation, not just a password change, is the action that actually closes the door.

Adlumin ITDR monitors authentication behavior across managed environments and flags the anomalous logins that follow a credential-harvesting compromise — impossible-travel sign-ins, new device registrations, and MFA prompts from unfamiliar locations — before the attacker establishes a foothold.

Hunt for account abuse and lateral movement

Assume the attacker logged in and look for what they did with the access. In Exchange and Microsoft 365, review inbox rules, forwarding, and delegate changes on the affected mailbox and any account it can reach:

• Enumerate mailbox permissions and delegate access: Get-Mailbox -ResultSize Unlimited | Get-MailboxPermission, and check for recently added delegates.
• Pull inbox and transport rules that auto-forward or auto-delete mail — a common trick to hide replies to attacker-sent messages: Get-InboxRule -Mailbox <user>.
• Review the unified audit log for New-InboxRule, Set-Mailbox forwarding changes, and consent grants to unfamiliar applications.

On the isolated endpoint and any host the account touched, check for persistence and lateral movement: unusual RDP logins in the security event log, new scheduled tasks (schtasks /query /fo LIST /v), and registry run keys (HKCU\Software\Microsoft\Windows\CurrentVersion\Run). None of these fit a pure credential-phish, so anything you find suggests the intrusion went further than one form submission.

Notify and record

Within the first hour, notify your incident response lead, legal, and compliance teams so any breach-notification clock and reporting obligations start on time. Document each action with a timestamp — the containment steps, the accounts reset, the sessions revoked — because that record is what regulators and cyber insurers ask for.

Once the immediate account is secured, expand the search to every recipient of the same campaign. The double-extension filename and the outsized HTML attachment give you a query to run across your gateway; treat any other user who opened it as a second compromised identity and repeat the containment steps for each one.

The Essential Takeaway: Layered Defense Over AI Alone

The lesson from this single phishing sample is broader than the sample itself: an AI or NLP-based content scanner can be diluted or timed out by data that carries no meaning at all. The attacker did not need to write cleverer malicious code — they simply buried a functional credential form under a mass of filler and let the scanner's own scoring math work against it.

That points to a structural limit worth understanding. Any single detection method that assigns one averaged verdict to a whole message can be pushed off balance by controlling the ratio of meaningful to meaningless content. A model that scores content probabilistically is only as reliable as its assumption that the message it sees is representative — and padding breaks that assumption cheaply.

So the takeaway is not that AI-based email filtering is a poor investment. It catches a large volume of routine phishing that older signature-based methods miss, and it belongs in your stack. The takeaway is that it cannot be the only thing standing between a crafted attachment and an employee's inbox.

What you actually depend on becomes clear when you ask a plain question about your own environment:

• If the content scanner returns a clean verdict, does anything else examine the attachment — a sandbox that detonates the file, or a check that flags a double extension like .xls.html?
• If a credential form does render for a user, does MFA limit what a captured password is worth?
• Would a trained employee recognize a SharePoint prompt that arrived with no legitimate context?

The single most useful action is to confirm you have independent detection that does not share the same failure mode as your content scoring. Where the answer to any of the questions above is no, that is where the padding technique described here would have room to work.