DEV Community: relayshieldadmin

Verifying AI Agents Before They Transact: RelayShield's TAP Verifier

relayshieldadmin — Fri, 09 Oct 2026 13:53:20 +0000

Visa's Trusted Agent Protocol (TAP) gives AI agents a way to prove who they are when they show up to transact. An agent presents a signed credential, the merchant verifies it, and the transaction proceeds. The protocol is sound. The problem is on the merchant side: verifying that credential correctly takes real work, and most merchants are not set up to do it.

The verification gap

When an agent arrives with a TAP credential, the merchant has to:

Parse the RFC 9421 HTTP Message Signature covering the request.
Fetch the agent's public key from Visa's JWKS endpoint and confirm the key is current and legitimate.
Validate the signature against that key.
Check the agent's identity against known threat intelligence. A valid signature proves the credential was issued, not that the agent behind it is trustworthy.
Confirm the agent's stated intent matches what it is actually trying to do. An agent that claims to be shopping but starts probing for data exfiltration is a different risk than its credential suggests.

Step 4 and step 5 are where most implementations stop. Signature verification is necessary but not sufficient. A compromised or repurposed agent can carry a perfectly valid signature.

What we built

RelayShield's TAP verifier is a merchant-side endpoint that runs the full check in one call:

RFC 9421 signature verification. The verifier reconstructs the signature base from the request components and validates it against the presented key material.
Visa JWKS validation. Agent public keys are fetched from Visa's JWKS endpoint and matched before any signature check runs. Stale or unknown keys are rejected.
TI corpus screening. The agent's identity indicators are screened against RelayShield's threat intelligence corpus (687K+ indicators drawn from monitored criminal marketplaces). An agent whose infrastructure overlaps with known malicious operations gets flagged, valid signature or not.
Intent-mismatch detection. The verifier compares the agent's declared intent in the TAP credential against the actual request pattern. A shopping agent that starts behaving like a data collector triggers a mismatch flag.

The endpoint is live:

POST https://api.relayshield.net/v1/tap/verify

Send the TAP credential and request context; you get back a verdict with the signature status, the JWKS key match, any TI hits, and the intent assessment.

Honest status

The verifier is live and the core path works, but two verifications are still in progress and we want to be upfront about them:

Signed Visa JWKS test with real Visa keys. The JWKS fetching and key-matching logic is implemented and tested against fixtures. The end-to-end test against Visa's live JWKS with production keys is still owed.
Intent-mismatch live production test. The mismatch detection is merged and unit-tested, but it has not yet been exercised against live production traffic.

One implementation note: Visa's live JWKS uses RSA keys. If you are building your own verifier, plan for RSA signature verification, not just Ed25519.

Why this matters now

Agentic commerce is moving from demos to real money movement. Visa, Mastercard, and others are shipping the rails. Every one of those rails assumes the merchant can verify the agent on the other end. Most merchants cannot, and the gap between "the protocol exists" and "the verification is actually running" is where fraud will concentrate.

A merchant-side verifier closes that gap without asking the merchant to become a cryptography shop or a threat intelligence operation. One API call, one verdict, with the evidence attached.

Try it

API access and documentation are at api.relayshield.net/developers. The TAP verifier is part of the standard API surface, so existing API keys work.

Originally published at RelayShield Security Intelligence.

ChainDrop Had Valid Provenance. That Was Not Enough.

relayshieldadmin — Tue, 06 Oct 2026 18:23:51 +0000

ChainDrop Had Valid Provenance. That Was Not Enough.

Attackers hijacked the GitHub account behind the keyv library to ship poisoned npm releases. The releases carried valid provenance, signed by GitHub Actions. Once installed, the payload raided machines for cloud and registry tokens, then spread worm-like to other maintainers. Four hundred packages. Two billion installs.

The signature was real. The signer was compromised.

Provenance answers the wrong question

Provenance tells you who signed a package. It does not tell you whether the signer should be trusted right now. When a maintainer's GitHub account is hijacked, every subsequent release carries a valid signature from a compromised source. The cryptography is working exactly as designed. The trust assumption underneath it is broken.

This is not a new pattern. It is the same mechanics behind every supply-chain attack: the signing infrastructure is intact, the human behind it is not.

Two places to stop it

Before the commit: rsscan.

ChainDrop's payload steals cloud tokens, registry tokens, and GitHub PATs from infected machines, then uses them to spread. If the worm tries to exfiltrate those tokens through a git commit, a pre-commit hook that scans for credentials stops it cold.

RSSCAN is our free, local pre-commit hook. It detects 49 credential patterns (AWS keys, GitHub PATs, Stripe secrets, private keys, LLM provider keys) and blocks the commit before the secret enters git history. No account, no API key, no network call. Your source code never leaves the machine.

A CI check only sees the secret after push. By then it is in history and has to be rotated. The pre-commit hook is the point.

After the publish: package reputation.

For consumers of npm packages, the question is different: is this version safe to install? Valid provenance does not answer it. Threat intelligence does.

A package reputation check compares the package name and version against known-malicious indicators: versions published from hijacked accounts, packages with sudden maintainer changes, typosquat variants. The signature says who published it. The reputation check says whether you should trust them today.

The trust layer is intelligence, not signatures

ChainDrop validates a thesis we have been building on: in a supply-chain attack, the cryptography is the last thing to fail. The maintainer's account, the CI runner, the publishing token, those go first.

The defense is not a better signature. It is knowing, at install time and at commit time, whether the source is compromised.

Signatures prove origin. Intelligence proves trustworthiness. You need both.

RSSCAN is free and open source: github.com/relayshield/rsscan. For API-based supply-chain screening, see api.relayshield.net/developers.

Scam-Kit Fingerprinting API: Turn Any Phishing Link Into a Matchable Kit Identity

relayshieldadmin — Mon, 05 Oct 2026 14:05:33 +0000

Every phishing wave reuses the same kits. Tycoon 2FA, Evilginx, Sneaky 2FA, Darcula: built once, deployed thousands of times. Only per-victim nonces and rotated credentials change between sightings.

RelayShield's scam-kit fingerprinting API turns one suspicious link into a stable kit identity: a deterministic kit_<sha256> fingerprint ID, identical for the same kit across sightings.

What the fingerprint captures

POST /v1/payg/scamkit-fingerprint

Records what the kit's server actually does:

Up to 5 redirect hops recorded
Response headers, including kit tells like X-Evilginx
TLS facts for the kit host: version, cipher, issuer, SANs, certificate age
Up to 2 bounded secondary fetches, each hashed and recorded

Honesty rule: we never compute JA3/JA4 locally. Those fingerprint the TLS client (our fetcher), not the kit server.

Secrets and tokens are stripped before hashing, so kits differing only in rotated credentials fingerprint identically. Families resolve against 20 approved names; anything else stays suggested until a human approves it. No-hit always says "no flags found", never "safe".

Pricing

$0.50  fingerprint  (/v1/payg/scamkit-fingerprint)
$0.10  match        (/v1/payg/scamkit-match)
$5.50  campaign scan, up to 25 indicators

Backed by the same corpus: 123 monitored Telegram marketplaces, 661K+ indicators, 8.4M+ citations.

Full post: https://blog.relayshield.net/scam-kit-fingerprinting-api

Mastercard knows it was an agent. Here's how you know which one.

relayshieldadmin — Mon, 05 Oct 2026 14:05:12 +0000

On September 30, Mastercard added trust and intelligence services to Agent Pay, its agentic payments program. The first service, now testing with U.S. issuers, is a probability score that estimates whether a transaction was initiated by an AI agent, so banks can approve legitimate agent-led purchases instead of declining them out of caution.

This is a real milestone: the card networks now treat agent-initiated commerce as a first-class category. But the score says an agent was probably involved. It does not say which agent, whether that agent has a history worth trusting, or whether the merchant on the other side is legitimate.

Which agent: verifiable identity

An agent that can spend money needs an identity that can be checked, not just asserted. Our TAP verifier checks agent identity claims the way the web already checks servers: HTTP message signatures (RFC 9421), Ed25519 keys resolved through JWKS, and a reputation record accumulated under the agent's key ID.

Is the other side dirty: composite scoring

Identity answers which agent. It does not answer whether the merchant, the link, or the wallet on the other side is legitimate. That is a corpus problem.

POST /v1/composite-check

Takes a URL, a wallet address, an email, or any combination, and returns one risk score from 0 to 100. Every signal is cross-correlated against our threat-intelligence corpus: 123 monitored Telegram marketplaces, 661K+ indicators, 8.4M+ citations. When the corpus has seen an indicator, the response says so. When it has not, it says nothing is known, which is not the same as clean.

We also fingerprint the kits behind phishing pages: deterministic kit_<sha256> IDs for phishing and smishing kits, live in production.

Both halves

Mastercard's score keeps legitimate agents from being declined. The relying party's problem is the mirror image: knowing which agent is asking, whether it has earned trust, and whether the counterparty is legitimate. The agent economy needs both halves.

Full post: https://blog.relayshield.net/mastercard-agent-pay-trust

Fake Ledger Ads Are Draining Wallets — and Every Link in the Chain Looks Legitimate

relayshieldadmin — Fri, 02 Oct 2026 17:32:14 +0000

Originally published on the RelayShield blog.

A phishing campaign targeting Ledger hardware wallet users has been running since at least August 2026, and it is notable for what it doesn't do: it doesn't use suspicious lookalike domains, misspelled brands, or obvious red flags. According to a full technical analysis published September 25 by Zscaler ThreatLabz (detection name HTML.Phish.Ledger), the attackers run fraudulent Google Ads impersonating Ledger, then route victims through a chain built entirely on trusted cloud platforms.

The redirect chain works like this. The sponsored ad appears in Google search results for Ledger-related queries, displaying "google.com" as its destination — a trust signal inherited from what Zscaler describes as a long-standing, verified advertiser account registered in Germany, assessed as likely compromised rather than created for fraud. Clicking sends the victim to a Google Cloud Storage bucket, then to a Vercel-hosted intermediate whose subdomain rotates every 15–20 minutes, and finally to a Google Sites page whose visible URL belongs to Google itself. The phishing interface is embedded in an iframe served from the Vercel origin. Because every hop sits on a reputable domain, URL-reputation and brand-protection filters that look for directly registered lookalike domains never fire.

The phishing page itself is a careful replica of Ledger's device-setup workflow. It asks the victim to pick a device type, plays simulated progress messages ("Connecting your Ledger," "Initializing Firmware Update"), confirms device ownership — and then asks for the 24-word Secret Recovery Phrase. To make typing feel authentic, it fetches the full 2,048-word BIP-39 English wordlist and implements live autocomplete as the victim types, mirroring Ledger's genuine tooling. After the first submission, a fake "Invalid seed. Please re-enter your recovery phrase carefully" error harvests a second, corroborating entry. Throughout the flow, the page monitors keypresses, touch, and mouse movement and loads an invisible hCaptcha widget at submission time — not to stop victims, but to fingerprint and filter out automated security scanners, extending the infrastructure's lifespan against takedowns. Captured phrases are POSTed to the attacker-controlled Vercel backend.

With the recovery phrase in hand, the attacker can restore the wallet in any compatible software and drain all associated funds — no physical access to the victim's Ledger required. No software vulnerability is involved; this is pure social engineering layered over abused legitimate platforms.

How RelayShield's bots catch this

This is exactly the kind of threat the RelayShield Telegram and WhatsApp bots are built to check. Before interacting with any setup, verification, or update flow that reached you through an ad, a search result, or a forwarded message, send the link to the bot:

The bot resolves the full redirect chain — including the multi-hop GCS → Vercel → Google Sites pattern used here — and checks each hop against the threat-intel corpus.
A screenshot of the "device verification" page run through /scan gets checked for phishing markers, including the classic seed-phrase-in-browser request.
The URL gets an immediate verdict before anything is typed into it.

The corpus flags the pattern even when the visible domain is google.com or vercel.app, because the check follows the actual redirect chain and the backend behavior, not just the domain in the address bar.

One takeaway

Never enter your Ledger Secret Recovery Phrase (or any hardware wallet seed phrase) into a website, browser flow, or "verification" page — it should only ever be entered on the physical device itself. Do firmware updates and setup only in the official Ledger Live app downloaded from ledger.com, which you navigate to directly rather than through sponsored search results.

Sources: Zscaler ThreatLabz, "Threat Actors Use Google Ads To Target Ledger Users" (full analysis Sept 25, 2026); Threadlinqs TL-2026-2673 (High severity, active); campaign publicly flagged by Zscaler in late August 2026, active since at least August 2026.

Why our Cortex XSOAR pack never says a domain is safe

relayshieldadmin — Fri, 02 Oct 2026 14:12:33 +0000

If you run Cortex XSOAR, XSIAM or the Cortex platform, the pack is in the Marketplace now. Search
for RelayShield in your own tenant's Marketplace tab, or read the
integration reference first.
You can see what the intelligence looks like before configuring anything: forward a suspicious email
to checkemail@relayshield.net and you get a verdict back.

The post below covers what the pack does and one design decision you will have an opinion about.

An agent that reads a repository's setup instructions, connects to an MCP server, or follows a
tool's README is extending trust to whatever domain, package or command those instructions name.
Nothing else in the Cortex XSOAR content marketplace looks at that trust before the agent acts on
it. RelayShield does, and as of this release a SOC or MSSP running Cortex XSOAR, XSIAM or the
Cortex platform can pull that intelligence straight into an incident without building anything.

What nothing else in the marketplace runs

Three commands answer questions specific to the agentic attack surface, not the general reputation
questions every other feed already covers:

relayshield-mcp-registry-risk assesses an MCP server URL or package name for typosquat, supply-chain or registry risk before an agent connects to it. This is the same logic behind our agent-bait screening, exposed as a command a SOC can run against anything an agent is about to be pointed at.
relayshield-cert-expiry checks a domain's TLS certificate expiry risk, which matters for the same reason: a certificate quietly expiring on infrastructure an agent depends on is an outage an automated system will not notice on its own.
relayshield-supply-chain checks up to ten vendor domains or emails in one call for combined breach and infostealer risk, sized for the shape a vendor-risk review actually comes in.

The part that costs nothing to adopt: it's the format your playbooks already speak

The pack also implements the generic domain, ip and email reputation commands. That is the
part that matters operationally as much as the agentic-specific commands do: any enrichment
playbook already calling those three commands picks up RelayShield the moment the integration is
enabled and a reliability weight is set. No rewiring, no new playbook logic, no waiting for a
custom integration to be written and reviewed. domain checks phishing-lookalike and typosquat
risk; email checks breach exposure and active stolen-session risk, the thing a password reset
does not fix; ip checks reputation against malicious and suspicious votes.

One design decision inside that mapping is worth knowing before you configure it: a clean result
from any of these commands sets DBotScore to Unknown (0), never Good (1). "No known finding" means
nothing was flagged in the sources RelayShield queried, which is a narrower claim than
verified-safe, and a reputation integration that conflates the two is telling an analyst something
it does not actually know.

RelayShield verdict	DBotScore
CRITICAL	3 (Bad)
HIGH	3 (Bad)
MEDIUM	2 (Suspicious)
LOW	2 (Suspicious)
No known finding	0 (Unknown)

Where the intelligence comes from

RelayShield's corpus is collected continuously from monitored criminal Telegram marketplaces,
infostealer log dumps, and authoritative public indicator feeds: 123 monitored channels and 8.3
million citations as of this release. The first two categories are the ones a standard TAXII feed
subscription does not reach, and they are the reason a RelayShield hit on an indicator is worth
pulling into the incident rather than filed alongside everything else. We quote specific, measured
figures like these when they are current and worth knowing; what we do not do is lean on a single
aggregate corpus headline, since most of any threat-intel vendor's total volume is ingested public
feeds a SOC already has through other packs, and the number that actually matters is what is in it
that those feeds are not.

Setup

Category: Data Enrichment & Threat Intelligence. Requires Cortex XSOAR 6.8.0 or later, and it also
ships for Cortex XSIAM and the Cortex platform. Configuration takes a Server URL (defaults to
api.relayshield.net) and a RelayShield API key. Get a free-tier key at
api.relayshield.net/developers, then
follow the full integration reference
for every command's inputs and context outputs.

Free checks that need no key at all, if you want to see a verdict before configuring anything:
forward a suspicious email to
checkemail@relayshield.net, or paste a link or a wallet
address into the checker in Telegram.

HEAVYGRAM: The Spyware That Runs on Telegram

relayshieldadmin — Tue, 29 Sep 2026 17:15:58 +0000

Originally published on the RelayShield blog.

On September 15, three agencies — the FBI, the U.K.'s National Cyber Security Center, and the Netherlands' AIVD — published a joint advisory about a Windows malware family controlled entirely through the Telegram messaging app. The FBI calls it HEAVYGRAM; the NCSC calls it CHOSEN BRICK. The FBI attributes it to Iran's Ministry of Intelligence and Security, and dates the wider campaign to the autumn of 2023. It has been used against people in the U.K., the U.S., and the Netherlands since at least 2025.

The targets are mainly Iranian dissidents, journalists, and activists — but the FBI warns that anyone Iran considers of interest could be a target. Stolen personal details have appeared on pro-Iranian leak sites, and in March the U.S. Justice Department seized four such sites that posted stolen data and called for the killing of dissidents and journalists.

How it works

Every stage of the attack runs through messaging. It begins with a message: the operators pose as someone the target knows, or as tech support for a messaging app, and build trust before sending a file that looks like a legitimate program. Reported disguises include the AI video app Pictory, the password manager KeePass, Telegram itself, RunwayML, Norton Antivirus, Adobe Flash Player — in some cases even files dressed up to look like MRI scan results. The operators usually start on the victim's work computer, and move to a personal device if that fails.

Opening the file shows a convincing fake screen while the malware installs in the background. A second stage then connects the computer to a Telegram bot that the operators use to control it and collect stolen data. Each infected computer gets its own Telegram bot, keeping victims' data separate.

To survive a restart, the malware adds itself to a Windows "Run" registry key — reported names include SMQDService and winappx — and tells Microsoft Defender to skip the folders where it hides. Then it waits for commands. The capabilities are broad: list running programs, take screenshots, switch on the microphone, copy Telegram and WhatsApp data out of the browser, steal saved passwords and email addresses, download more malware, delete files. At least one version can wipe the computer entirely.

Exfiltrated data leaves through the victim's Telegram bot and through cloud storage services such as Vultr and Storj. Newer versions route Telegram traffic through proxy servers to make the command-and-control harder to spot.

Why this matters for Telegram watchers

This campaign is a reminder of something RelayShield's monitoring exists for: the same platform that carries scams and phishing lures also serves as infrastructure for targeted operations. Malicious Telegram bots and the domains tied to them are exactly the kind of infrastructure our bots watch across monitored Telegram marketplaces and our threat-intel corpus, and the indicators in advisories like this one — registry names, mutex markers, network destinations — are the artifacts a corpus is built to track. When a campaign like this is confirmed, the IOCs feed the same free check tools our readers already use: run an unfamiliar download link, domain, or crypto wallet through the free checks before trusting it.

One concrete takeaway

Do not open files sent through messages — not from strangers, and not from contacts who were recently "hacked" without a good reason. Download software only from official websites and app stores, and if an app asks you to install something from a chat, treat that as the attack. HEAVYGRAM's entire first stage depended on one click on one file in one message. Every operator in this business knows that, which is why they keep sending them.

Sources: joint advisory published September 15 by the FBI, U.K. NCSC, and Dutch AIVD; FBI updated analysis of HEAVYGRAM; reporting via The Hacker News, September 2026. No incident details in this post beyond what those sources document.

Your Laptop Is the Supply Chain: What the MemTensor Worm Teaches Maintainers

relayshieldadmin — Mon, 28 Sep 2026 12:06:17 +0000

Originally published at RelayShield Blog.

On September 23, Aikido disclosed a Go-based worm it tracks as supplychain.local, published into the MemTensor packages on npm and PyPI after a threat actor seized their release access. The worm skips install-time hooks and fires on ordinary use, harvesting GitHub, npm, PyPI, AWS, Slack, and Stripe credentials from the environment. Then it weaponizes your own publish rights: direct npm and PyPI publishing with the stolen credentials, plus a GitHub Action template that re-triggers on every push.

Read that again. The worm doesn't attack your users. It turns you into the distributor.

The maintainer is the malware

This is the part that should keep you up at night. The MemTensor worm didn't exploit a vulnerability in the package code. It exploited the maintainer's laptop. Once it had their credentials, it published malicious versions as them, signed, trusted, and automatically pulled by every downstream user.

Your CI pipeline? It runs after push. By the time Snyk or GitHub Advanced Security flags the malicious package, the GitHub Action is already in your repo, re-triggering on every push, and the compromised version is already on npm.

The only checkpoint that runs before the damage leaves your machine is the pre-commit hook.

Count who can publish your dependencies

Here's the question nobody asks until it's too late: how many accounts can publish into your dependency tree?

When we built rsscan, we added rsscan --deps for exactly this reason. It counts the accounts with publish rights across your npm dependencies: the blast radius if any one of those maintainers gets compromised like MemTensor did.

rsscan --deps

If that number surprises you, that's the point.

The pre-commit hook is the point

rsscan blocks commits that introduce API keys, tokens, and machine credentials. It detects 31 credential patterns: AWS IAM keys, GitHub PATs, Stripe secrets, Slack tokens, private keys, LLM provider keys, and it runs entirely on your machine. No account, no API key, no network call. Your source code never leaves the host.

Why pre-commit and not CI? Because a CI check only sees the secret after a push. By then it's in git history and has to be rotated even if you delete the commit. The pre-commit hook runs before the commit enters history.

# .pre-commit-config.yaml
repos:
  - repo: https://github.com/relayshield/rsscan
    rev: v0.2.0
    hooks:
      - id: rsscan

pre-commit install

That's the whole setup. Nothing to configure, nothing to sign up for.

What MemTensor changes

The MemTensor worm proves three things:

Your publish credentials are the target. Not your code, not your users: your ability to ship.
Post-push detection is too late. The malicious GitHub Action executes on push. Scanning after the fact is forensics, not prevention.
The supply chain is your laptop. Every credential on your machine is a potential distribution channel.

Run rsscan --deps. See how many people can publish into your dependencies. Then put the pre-commit hook in place so the next worm doesn't use your credentials to ship its malware.

rsscan is free and open source. Get it on GitHub. No account, no API key, no network calls. Your code never leaves your machine.

The Side Door: Run RelayShield's Free Scam Checks Inside Your Own Muse

relayshieldadmin — Fri, 25 Sep 2026 20:37:31 +0000

The Side Door: Run RelayShield's Free Scam Checks Inside Your Own Muse

RelayShield's scamchecker connector is now LIVE in Meta's system. Submissions are being onboarded. But you don't have to wait for the queue — Muse lets you create custom connectors right now, and RelayShield's core checks are keyless. Paste one setup prompt and your own Muse can screen suspicious links, crypto wallets, and email addresses on demand.

How it works

Point your custom connector at RelayShield's live OpenAPI document:

https://api.relayshield.net/openapi.json

Three checks need no API key at all:

Link check (POST /v1/link-check) — run any suspicious URL against RelayShield's threat-intel corpus: 7.8M+ citations across 494K+ indicators, drawn from 115 monitored Telegram marketplaces where phishing kits and scam tooling are bought and sold.
Wallet risk (POST /v1/wallet-risk) — screen a crypto wallet address before you send funds to it.
Email check (POST /v1/email-check) — vet an unfamiliar sender address before you engage.

One more check takes a free key: the breach check, which ships with 100 free calls — enough to sweep your own addresses and see what's exposed.

The wording matters

RelayShield never tells you a link is "safe." A check with no hits returns "no flags found" — with the caveat that a clean result means the corpus has nothing on it today, not that the link is trustworthy. That discipline carries through the connector: verdicts are evidence-based, never reassuring.

One setup prompt

Copy, paste, done:

Add a custom connector using the OpenAPI spec at https://api.relayshield.net/openapi.json. Expose link-check, wallet-risk, and email-check (all keyless) plus breach-check (I'll supply a key when I want it). When I ask you to check something suspicious, call the right endpoint and report the verdict plainly. Never say "safe" — say "no flags found" when there are no hits.

Why a side door at all

The official connector goes through Meta's review and onboarding waves. The custom-connector route hits the same free endpoints and the same corpus, today. And every check deep-links back to RelayShield's Telegram miniApp (t.me/relayshield_bot/idcheck) for the full interactive workup — watching a link, rescanning it later, digging into the evidence behind a verdict.

RelayShield monitors 115 Telegram marketplaces for phishing kits, scam tooling, and threat indicators. Try the free checks at t.me/relayshield_bot.

The "Boss Scam": When the Message from Your CEO Isn't Your CEO

relayshieldadmin — Fri, 25 Sep 2026 15:47:23 +0000

In August 2026, India's Indian Cyber Crime Coordination Centre (I4C) warned about a rapidly emerging fraud targeting company directors, CFOs, chartered accountants, and finance teams. They call it the "Boss Scam" — and it marks a significant shift in how messaging-app fraud works.

The old CEO impersonation scam was crude: a fraudster created a fake account, slapped your boss's name and profile photo on it, and asked you to approve an urgent payment. It worked often enough to be a problem, but there was usually something off — a new number, slightly wrong spelling, a request that didn't quite fit the company's process.

The new version skips the impersonation entirely. The attackers try to take over the real account.

It begins with a file. It may arrive disguised as a "Statement of Account," an RBI notice, an MCA filing, or income-tax correspondence — the kind of thing a finance team would open without thinking twice. The malicious ZIP contains Windows executables and DLL files. Once opened, the malware can compromise the computer and hijack an active WhatsApp Web session.

That is the part that matters. The fraudster no longer needs to convincingly pretend to be your boss. They can attempt to take over the account your employees already trust — and the trust is what does the work.

The fraud then moves laterally. From the compromised executive's account, the attackers can forward the same malicious file to colleagues, who open it precisely because it came from someone they know. In the final stage, criminals use the genuine or impersonated CEO identity to instruct finance employees to make urgent payments to mule accounts.

The scale is already serious. I4C said it had alerted more than 58,000 potential victims through the SMS header "I4CMHA-G" in the preceding 30 days, and that more than 10,000 people had been protected from the campaign through intervention.

Why this pattern is worth watching closely

What makes the Boss Scam different from most messaging-app fraud is that the lure is not the message — it is the attachment. The attack chain has three links: a trusted-looking business file, a compromised session, and a trusted identity used for lateral spread and payment fraud. Phishing kits and stealer tooling of exactly this kind are routinely advertised in the Telegram marketplaces RelayShield monitors (113 marketplaces tracked), and RelayShield's TI corpus — 7.8M+ citations across 494K+ indicators — follows how these lures evolve, so the patterns behind campaigns like this are visible before they reach your inbox.

RelayShield's WhatsApp bot applies the same principle at the point of contact. It is built around one simple idea: the message arriving from a familiar name is the wrong place to make a trust decision.

One defensive takeaway

Treat every urgent payment instruction arriving by message as unverified — even when it comes from the real account of someone you know. Confirm it through a separate channel (a phone call, a walk down the hall, the company's normal approval flow) before money moves. And if an "invoice" or "statement" file arrives unexpectedly by message, run any links it contains through a scam check first — RelayShield's free link and email checks exist exactly for this. Accounts get hijacked; process doesn't.

Sources: ET Edge Insights roundup of I4C/MHA warnings, "The anatomy of digital deception: 2026's top 5 cyber frauds" (published ~Sep 24, 2026), citing I4C's August 2026 Boss Scam warning. Figures: 58,000+ potential victims intimated via SMS header "I4CMHA-G" in 30 days; 10,000+ protected through intervention.

The EDR was dead before the theft started

relayshieldadmin — Mon, 21 Sep 2026 16:49:41 +0000

Before the argument, something you can run. Rapuncel arrived through GitHub repositories impersonating real projects, so this screens a repository URL before you trust it, against Google Safe Browsing, a criminal indicator corpus and domain age:

curl -sS -X POST https://api.relayshield.net/v1/link-check \
  -H "Content-Type: application/json" \
  -d '{"url":"https://github.com/some-repo-you-are-about-to-trust"}'

No key, no card, no signup. It is capped per source IP rather than billed, and it will never tell you something is safe: the ceiling on a clean answer is "nothing known against it".

On 17 September 2026, LastPass's Threat Intelligence, Mitigation and Escalation team
published joint research with Delphos Labs on an infostealer they track as Rapuncel.
Everything factual below comes from
their report
and from BleepingComputer's write-up of it.
We did not find this campaign and we are not claiming to have.

One detail in it is worth more attention than it is getting.

Before Rapuncel steals anything, it loads a kernel driver that carries a hardcoded list of
145 antivirus and EDR products, and terminates them. The driver is signed through
Microsoft's Windows Hardware Compatibility Publisher chain. It ships as nvfsflt64.sys,
presenting itself as an NVIDIA file system filter; researchers identified it as a renamed
CcProtect.sys from a commercial encryption product.

So the order of operations is: disable the detection layer, then steal.

What that order means

Almost every control most organisations own is a detection control. It observes, it
correlates, it alerts. All of them share one unexamined assumption: that they are
running when the thing they detect happens.

A kill list of 145 products is that assumption being attacked directly and at scale. It is
not evasion in the usual sense, where malware tries to look boring enough to slip past. It
is the security stack being switched off first, with a signature Windows trusts.

And once it is off, the question "did we detect it?" has a fixed answer, and the answer is
no. Not because the product was bad. Because it was not running.

What is left is the only signal that survives the endpoint: the stolen material turning
up somewhere else.

What Rapuncel takes, and why the list matters

Per the same research, once the protections are down the stealer collects credentials from
more than 25 browsers, data from around 30 cryptocurrency wallets, session
credentials for Discord, Steam and Telegram, the contents of Windows Credential Manager,
and screenshots.

Read that list again for what it is not. It is not mostly passwords.

Session credentials for three messaging and gaming platforms.
Browser data, which in practice means cookies as much as saved logins.
Wallet data, which is not a credential you rotate at all.

This is the distinction we keep coming back to, because it decides whether a response
works. A password reset invalidates a password. It does not invalidate a session. An
attacker holding a live session cookie does not need to log in, so there is nothing for a
new password to stop, and no MFA prompt to satisfy either, because the session already
satisfied it.

The same is true one step further out. Rotating a key does not revoke a token. Changing a
seed phrase is not a thing you can do.

How it arrives, which is the ordinary part

Victims search for software, follow a result to a GitHub repository impersonating the real
project, and download from it. The campaign impersonated at least 40 brands, including
LastPass Authenticator itself, and the researchers date it to at least 13 August 2026. The
downloads are ZIP archives inflated to as much as 148 MB, which is large enough to fall
outside some scanning limits.

The installer is a renamed copy of vsdbg.exe, Microsoft's Visual Studio debugger, with a
malicious vsdbg.dll dropped beside it, so the attacker's code executes inside a signed
Microsoft process.

There is no exploit in that chain. A person searched, trusted a repository that looked
right, and ran it.

What we do about it, and what we do not

We are not an EDR and we would not have stopped this. A signed kernel driver
terminating 145 security products is not something an API answers. Any vendor telling you
otherwise this week is selling you something.

What we work on is the half that is still observable after the endpoint stops reporting:
whether the material that left is now in circulation.

POST /v1/metered/infostealer answers whether an email address appears in infostealer log dumps. Not whether it was in a breach years ago, which is a different and much older question, but whether a machine belonging to that person was logging keystrokes and hoovering browser stores.
POST /v1/metered/session-risk answers the question a password reset does not: whether a live session was taken.
POST /v1/wallet-risk and POST /v1/link-check are open, with no key, no card and no signup, capped per source IP rather than billed. The link check is the one that would have been useful in front of the download.

And in the consumer product, the response for this specific shape is /sweep: close the
forwarding rules, revoke the sessions, remove the rogue recovery options, and only then
reset the password. Doing it in the other order leaves an attacker inside an account whose
password has just been helpfully changed for them.

The uncomfortable part

We collect from criminal marketplaces and infostealer log dumps, which means what we see is
the output of campaigns like this one after they have already worked. We are not early to
the infection. We are early to the consequence, which is a smaller claim and a true one.

We do not quote a corpus headline, here or anywhere. Most of any vendor's total is ingested
public feeds you already have, and the number that matters is what is in it that you could
not find elsewhere. Ask us that instead.

If you want the short version

The detection layer was off before the theft began, by design, with a Microsoft signature.
Plan for the case where your detection did not fire, because that case is now a product
feature of the malware. The plan is: know what left, revoke sessions before rotating
passwords, and treat a wallet as unrecoverable rather than rotatable.

Free checks, no account: forward a suspicious email to
checkemail@relayshield.net, or paste a link or a wallet
address into the checker in Telegram.

The API is at
api.relayshield.net/developers.

A file read is a credential theft. CVE-2026-85706 and what is in those files.

relayshieldadmin — Wed, 16 Sep 2026 18:37:53 +0000

If you want the check before the argument, it is two commands and it runs
entirely on your own machine:

pip install rsscan
rsscan

Bare rsscan reads git diff --cached -U0 and matches 49 credential patterns
locally. No account, no API key, and no network call on the scanning path. For
CI, rsscan --rev-range origin/main...HEAD scans a commit range instead, which
is strictly a backstop: by the time CI runs, the secret is already in history.

It also would not have saved you from this CVE, and the post below says so in
its own voice, because the half that actually hurts here is the server's own
config rather than anything a pre-commit hook has ever seen.

GitLab patched a critical path traversal in its repository commits API last Thursday, and
attackers were already using it. The reporting is Mathew J. Schwartz at BankInfoSecurity
(piece here),
built on a watchTowr advisory,
a Rapid7 alert,
and GitLab's own patch release.
CISA added it to the Known Exploited Vulnerabilities catalogue on Friday. Everything below rests on
their work, and if you self-host GitLab the patch matters more than the rest of this post.

The short version: an unauthenticated attacker can read arbitrary files off a self-hosted GitLab
server. CVSS 10.0. Patched in 19.3.2, 19.2.6 and 19.1.8. GitLab.com is already patched and
Dedicated customers need do nothing.

The score is about the read. The damage is about what it reads.

A 10.0 describes the mechanism: no authentication, remote, full read. It does not describe the
outcome, and the outcome is the part worth planning around. watchTowr put it precisely: the
vulnerability lets an attacker "read local files and configs to obtain credentials, secrets and
sensitive information."

That is the whole game. Nobody exfiltrates a GitLab server because they want your Ruby source.
They want the things that let them come back later without a CVE. A file read is a credential
theft with an extra step, and the extra step is the one that expires when you patch. The
credentials do not expire when you patch.

So the question that decides how bad last week was for you is not "was I vulnerable". It is
what was readable.

What is readable on a GitLab box

Two categories, and they fail differently.

The server's own configuration. The database password, the secret key base, the SMTP
credentials, the object storage keys, CI/CD variables. This is the application's own state. It is
not in your repositories and no pre-commit hook has ever touched it. If you were exposed, treat
all of it as public and rotate it, in the order below.

Whatever your developers committed. This is the other half and it is the half you control
before the next bug rather than after it. Every credential that was ever committed to a repository
on that server was readable by the same request. Not just the ones in HEAD: a commits API is, by
construction, a way to read history, and a secret deleted in a later commit is still sitting in an
earlier one.

The second category is where the blast radius gets strange. A GitLab token in a repository is not
one credential. A runner token executes CI. A deploy token writes to packages and containers. A
Kubernetes agent token reaches the cluster. An OAuth application secret impersonates your login
provider to every app that trusts it. One readable file can be lateral movement into three systems
that have nothing to do with GitLab.

The honest scope of a pre-commit hook

We make a pre-commit secret scanner called rsscan, and this is exactly the kind of moment where a
vendor tells you their tool would have saved you. It would not have, and the distinction is worth
being precise about because it decides what you should actually do on Monday.

rsscan cannot help with the first category at all. It reads git diff --cached, your own staged
change, on your own machine, before the commit exists. It has no view of gitlab.rb, no view of
secrets.yml, no view of the CI variables in the database. A tool that runs on a laptop cannot
defend a server's config, and anyone telling you otherwise is selling you something.

What it does is make the second category smaller. A credential that never reaches a commit is
not in the history that the next file-read bug walks. That is not glamorous and it is not a
mitigation for CVE-2026-85706, which is already out. It is the thing that determines how much the
next one costs you, and there is always a next one: this same release carried seventeen other
fixes, including an insecure deserialization flaw at 9.9 that GitLab says could expose Advanced
Search configuration and credentials to an authenticated Duo Chat user.

Stating that plainly is the point. A control that reduces future blast radius is worth having.
It is not an incident response plan.

The question to put to your own secret scanner

A detector reports what it has a pattern for, and "clean" and "we have never looked for this" are
the same output on the screen. So the question worth putting to whatever scanner you run, this
week specifically, is not how many patterns it carries. It is whether it carries the ones for the
platform you have just had to patch. That takes ten minutes to settle: generate a dummy token of
each shape, run them through, and see which ones come back named.

RelayShield covers eight GitLab credential formats, in all three of the places they have to agree,
with the token classes taken from gitleaks' own rule source rather than from a documentation page:
personal access tokens in both the classic and the newer routable format, deploy, runner, OAuth
application, Kubernetes agent, pipeline trigger and CI job tokens. The routable format has to be
tested first, because the classic pattern matches the first twenty characters of a routable token
and would otherwise report the wrong type with the wrong remediation.

The other half: it has already left

Patching closes the door. It does not tell you whether anything walked out first, and that is a
different question with a different answer.

Credentials stolen from an exploited server do not sit still. They get tested, traded and posted,
and the places they get posted are observable. We collect indicators continuously from monitored
criminal Telegram marketplaces, infostealer log dumps and public indicator feeds, which is how you
answer "has this specific thing surfaced" rather than "was I theoretically exposed". For a
credential you know was readable, that is a more useful question than any scan of your own estate.

What to do, in this order

The order matters more than the list, and getting it backwards is a real and common mistake.

1. Patch or remove public access. 19.3.2, 19.2.6 or 19.1.8. GitLab warns the updates include
database migrations, so single-node installations will have downtime and multi-node deployments
should use the zero-downtime procedure. If you cannot patch in the next few hours, take the
instance off the public internet instead. Rapid7 recommends treating this as an emergency change
outside normal patch cycles, and CISA set a federal deadline of Monday.

2. Hunt before you assume you were fine. Rapid7 is explicit that you should look for signs of
compromise even after updating. watchTowr named the specific thing to grep for: HTTP POST requests
to /api/v4/projects/{id}/repository/commits/ URIs containing file.path parameters. Do that
before you conclude anything, because the alternative is concluding it from the absence of
evidence you never went looking for.

3. Rotate, and only now. This is the step people get out of order. Rotating credentials on a
server that is still readable hands the attacker the new ones and costs you the rotation. Patch,
then hunt, then rotate, starting with anything that grants access somewhere else: runner tokens,
deploy tokens, agent tokens, OAuth application secrets, then the server's own database and object
storage credentials.

4. Then make the next one smaller. Get secret scanning in front of the commit rather than after
it, and check that it covers the platforms you actually run. That is the only step on this list
that is about the next bug rather than this one, which is why it is last and why it is the one
that will still be paying off in a year.

The pre-commit hook is pip install rsscan, it runs offline on your staged diff, and it is free.
The corpus lookup for "has this already surfaced" is
POST /v1/breach-check at
api.relayshield.net/developers.
Neither will ever tell you something is safe. The ceiling is "nothing known against it", and the
response says so itself, because on the day a file-read bug is being exploited in the wild an
absence of evidence is the one thing nobody should be selling as reassurance.