ClickFix to BEC in 24 Hours: Tragic Quadrant | Huntress

1. Executive summary

Huntress has published a walkthrough of a ClickFix chain that moves from a poisoned search result to full business email compromise in roughly 24 hours, using a fictional finance employee ("Doris Stewart") to illustrate the sequence. The chain has three stages: a sponsored search result that leads to an attacker-built custom GPT, a fake verification page that instructs the victim to paste a command into Terminal, and theft of a Microsoft 365 session cookie that is replayed to reach the victim's mailbox without a password or MFA prompt. No CVSS scores, CVE identifiers or CISA KEV entries are present in the source material, and no named threat actor is attributed, so this advisory carries no vulnerability severity rating and no confirmed attribution. The relevance to EMEA financial services is the identity and payment-control gap it exposes: a stolen session cookie bypasses MFA entirely, and the resulting mailbox rule hides the invoice thread from the victim while the attacker redirects payment to a new routing number. The source is a single vendor blog with a fictional scenario; treat the technical pattern as credible and the specific details as illustrative rather than observed.

2. Regulatory framing

No DORA Art. 24, 28, 29 or 30 trigger is present: the source does not describe resilience testing, an ICT third-party provider, concentration risk, or a contractual arrangement. No UK NIS 2018 trigger is present on the facts given.

3. Technical analysis & attack chain

The source is a single Huntress blog post describing a fictional scenario, presented by Principal Product Researcher Truman Kain. The steps below are the sequence as described. They are not corroborated by a second source and no atomic indicators are published.

1. The victim searches Google for "ChatGPT" and clicks a sponsored result. The result leads to an attacker-built custom GPT rather than the legitimate service. The source states there are no obvious tells that the custom GPT is malicious.
2. The custom GPT reports a service issue and redirects the victim to a fake verification page.
3. The fake page instructs the victim to press Command+Space, paste a command into Terminal, and press Enter. This is the ClickFix step: the victim runs the attacker's command on their own machine.
4. The attacker's script retrieves cookies from the machine and identifies the victim's Microsoft session cookie, the token that keeps the user logged in to Outlook without re-entering a password or MFA code.
5. The attacker loads the stolen cookie into a fresh browser using a free extension and refreshes the page. The session is already authenticated, so no password and no MFA prompt are required. The attacker is now in the victim's mailbox with full control.
6. Inside the mailbox, the attacker finds an invoice awaiting approval.
7. The attacker creates an inbox rule named ".." so that it is easily overlooked, and sets it to archive any message containing the invoice number.
8. The attacker replies to Treasury as the victim, asking them to send the payment to a new routing number.
9. The attacker deletes the sent message and empties the trash. The victim never sees the reply, the rule, or the deleted items.

The whole sequence runs in about 24 hours. The source notes the attack did not require significant time, money, or technical skill.

Endpoint tell. The source states the initial access appears on the endpoint as a Mac shell running curl output with the attacker's IP address Base64-encoded inside it, matching the command the victim pasted into Terminal. That pattern is worth flagging as suspicious until proven otherwise. The source does not give the command string, the IP address, or the Base64 payload, so no detection rule can be built from it.

Identity tells. The source lists three: two browsers active in one session, two different operating systems tied to the same login, and traffic routed through (the source text is truncated at this point; the third tell is incomplete in the material provided). These are behavioural signals, not atomic indicators.

Confidence caveats. The scenario is fictional and single-sourced. The custom GPT, the fake verification page, the cookie-stealing script, the browser extension used for cookie replay, and the inbox rule are all described at a conceptual level. No file names, hashes, domains, IP addresses, command strings, or extension names are published. The claim that the attacker used "a free extension" to drop the cookie into a fresh browser is stated without naming the extension. The claim that the attacker's IP address was Base64-encoded in the curl output is stated without the value. Treat the pattern as the actionable content and the specifics as illustrative.

4. Mitigation & containment

P1 (within 24 hours)

• Hunt for the endpoint pattern the source describes: a Mac shell process running curl with a Base64-encoded string in the command line. On macOS, review shell history (~/.zsh_history, ~/.bash_history) and EDR process telemetry for curl invocations launched from Terminal with encoded arguments. The source does not provide the exact command, so this is a behavioural hunt, not a signature match.
• Hunt for the identity pattern: the same M365 account showing two browsers active in one session, two different operating systems tied to the same login, and traffic routed through an unexpected path. Where your identity provider or conditional access logs expose user agent and device signals, alert on concurrent sessions from mismatched OS or browser combinations.
• Audit M365 mailbox rules for the specific artefact named in the source: a rule named ".." and any rule that archives messages matching an invoice number or similar payment-related string. Remove rules that match this pattern and preserve them as evidence before deletion.
• Review outbound mail from finance and treasury-adjacent accounts for replies that redirect payment to a new routing number, and check the Sent Items and Deleted Items of any account where such a reply is suspected. The attacker in this scenario deleted the sent message and emptied the trash, so absence of a sent item is not evidence of absence.

P2 (within 72 hours)

• Revoke active sessions and refresh tokens for any account confirmed or suspected of cookie theft. A password reset alone does not invalidate a stolen session cookie; the session must be revoked at the identity provider.
• Enforce token binding or continuous access evaluation where your identity platform supports it, so that a cookie replayed from a different device or network is rejected.
• Restrict or monitor browser extension installation on managed endpoints. The source does not name the extension used, so this is a policy control rather than a blocklist.
• Confirm that payment change requests, particularly routing number changes, require out-of-band verification with the requester through a channel other than email. The source's scenario succeeds because the reply came from the victim's own authenticated mailbox.

P3 (within 7 days)

• Add the endpoint and identity behaviours above to standing detection content, since the source provides no atomic indicators to block.
• Review whether your M365 mailbox rule alerting covers rules created by a session that has not re-authenticated, and whether rule names that consist of punctuation are surfaced.
• Test the incident response path for a cookie-theft-to-BEC scenario end to end, including the identity, endpoint and payment-control teams, so that the 24-hour window in the source is not the response window.

The source gives no vendor fix, patch, or version to apply. There is no CVE and no software vulnerability in this item.

5. Indicators of compromise

No atomic indicators of compromise are available in the source material. The source describes behaviours and a scenario but publishes no hashes, domains, IP addresses, file names, command strings, or extension names.

Behavioural indicators

No copyable indicator block is provided because the source contains no machine-pivotable atomic indicators.

6. Detection

The source contains no file hashes, no distinctive malware strings, no command-line flags, no mutex names, no scheduled-task or service names, no file paths, and no registry keys. The only named artefact is an inbox rule named "..", which is a mailbox configuration value rather than a file or process artefact, and the endpoint behaviour is described generically as "a Mac shell running curl output with the attacker's IP address Base64-encoded inside it" without the command string.

A YARA rule cannot be written from this material: there are no strings that are artefacts of the threat itself. Writing a rule that matches on "ClickFix", "ChatGPT", "Tragic Quadrant", or the vendor name would detect reporting about the threat, not the threat.

A Sigma rule is possible for the mailbox rule creation behaviour, using the rule name given in the source. This is a behavioural detection, not a signature, and it will only fire where mailbox rule creation is logged.

title: Suspicious M365 Inbox Rule Named With Punctuation Only
id: 8f3c2a1e-4b7d-4e9a-9c1f-2d6e8a0b5c74
status: experimental
description: Detects creation of an M365 inbox rule whose name consists only of punctuation, as described in the Huntress ClickFix-to-BEC scenario where the rule was named ".." to avoid notice.
author: Adverse Trace
date: 2026-10-14
references:

  - https://www.huntress.com/blog/clickfix-bec-tragic-quadrant-doris
logsource:
  product: m365
  service: exchange
detection:
  selection:
    Operation:

      - 'New-InboxRule'
      - 'Set-InboxRule'
    Parameters|contains: 'Name'
  filter_punctuation_name:
    Parameters|re: 'Name["'':\s]+[.\-_=+*#@!?]{1,10}["'']'
  condition: selection and filter_punctuation_name
falsepositives:

  - Users who name rules with punctuation for personal organisation
level: medium

This rule is a starting point and will need tuning against your tenant's logging format. The source does not provide the exact audit event schema, so the field names above should be verified against your M365 audit log export before deployment.

7. Sources

• Huntress, "ClickFix to BEC in 24 Hours: Tragic Quadrant | Doris", https://www.huntress.com/blog/clickfix-bec-tragic-quadrant-doris, published 2026-10-13.

This is the only source provided. All technical detail in this advisory derives from it. No second source corroborates the scenario, and the scenario itself is fictional.

8. Adverse Trace position

We assess this as a medium-severity identity and payment-control risk rather than a vulnerability, because the chain requires no software flaw and no exploit: it relies on a user pasting a command into Terminal and on a stolen session cookie that bypasses MFA by design. The source is a single vendor blog describing a fictional scenario, so we treat the pattern as credible and the specifics as illustrative; we have not assigned a CVSS score, a CVE, or a CISA KEV status because none exist for this item, and we have not named an actor because the source names none. For EMEA financial services clients, the exposure is concentrated in two places: session cookie theft defeating MFA on M365, and payment change requests that can be authorised from a compromised but authenticated mailbox. We will monitor for a second source that publishes atomic indicators, for the truncated identity tell in the Huntress post, and for any named browser extension used in the cookie-replay step. Clients who want to test their exposure to this pattern should start with the P1 mailbox rule audit and the session revocation capability, since those two controls break the chain at the points the source identifies.

Read the original source →

Published via PulseTrace — Adverse Trace threat intelligence.