DEV Community: relayshieldadmin

The PAP Verifier Is Live: Merchant-Side Verification for Agentic Commerce

relayshieldadmin — Fri, 16 Oct 2026 14:36:54 +0000

The PAP Verifier Is Live: Merchant-Side Verification for Agentic Commerce

Last week, Sierra and Meta published draft 0.1 of the Personal Agent Protocol. This week, BBVA became the first European bank to join the effort. Thirty-five design partners are at the table, including OpenAI, Visa, Mastercard, and PayPal. The protocol is moving fast.

PAP answers a real question: how does a person's AI agent work with a business on their behalf? The business publishes a discovery document at /.well-known/poppy.json. The agent reads it, opens a session, and the customer signs in through OAuth. One session spans the business's APIs, website, and agent.

But there is a gap the spec does not fill. When the agent shows up with a session token, who verifies it on the merchant's side?

That is what we built.

Two levels of verification

Agentic commerce needs verification at two levels, and they are not the same.

Network level (TAP). When the payment runs on Visa's card network, the network is in the loop. Visa's Trusted Agent Protocol defines how the agent's credentials get checked. Our TAP verifier, live since October 7, independently validates the agent's signature and screens the counterparty against our threat corpus.

Merchant level (PAP). When the business runs its own checkout through Stripe, Shopify, or Meta, there is no card network in the loop. The merchant is on its own. The agent presents a PAP session token, and the business has to decide whether to trust it.

Most agent transactions will live at this second level. The card network verifies the payment. The merchant verifies the business relationship. Both need an independent check.

What the PAP verifier does

Our PAP verifier is live now at POST /v1/pap/verify. One API call, and it checks:

Session token validity. The PAP session token is a JWT signed by the business's OAuth issuer. We fetch the issuer's keys and verify the signature, expiry, and audience.
DPoP proof. PAP binds tokens to a key the agent holds, using DPoP. We validate the proof: signature, method and URL binding, and freshness. A stolen token alone does not pass.
poppy.json discovery. We fetch the business's published /.well-known/poppy.json and validate it against draft 0.1: protocol version, organization identity, OAuth issuer, and scope declarations. If the discovery document does not match the token's claims, that is a finding.
Replay protection. Every token carries a unique ID. We record it, so a replayed token gets rejected.
Counterparty screening. The agent's identity and the business's domain are screened against 700K+ threat indicators from 125 monitored marketplaces and 9M+ corpus citations.

The response is a verdict: verified or not, with reasons. No ambiguous middle.

Why this matters now

The early adopters are already publishing. Tilopay, Emora Health, and Rent Our Bins have live poppy.json files. None of the big launch partners publish one yet, which means the window is open: the businesses moving first are the ones defining what "good" looks like.

A merchant that accepts agent traffic without verifying it is trusting the agent to describe itself honestly. That is not a posture. Verification is the posture.

RelayShield is now the verification layer for agentic commerce at both levels: TAP for the network, PAP for the merchant. Flat monthly pricing, pay per verification if you prefer. The endpoint is live today.

Originally published at blog.relayshield.net on October 16, 2026.

Your MCP Server Is the Attack Surface Now

relayshieldadmin — Thu, 15 Oct 2026 17:40:56 +0000

Your MCP Server Is the Attack Surface Now

October 2026 has been the worst month yet for Model Context Protocol security. Not because attackers discovered something new, but because they keep rediscovering the same flaws in server after server.

Here is what happened in the last two weeks alone.

The CVEs

Langflow RCE (CVE-2026-105697, CVSS 9.9). Disclosed October 5. Langflow executed the command field from MCP server configs with no allowlist, wrapped in bash -c. Any authenticated user could run arbitrary OS commands on the host. A public proof of concept is available. Fixed in 1.9.0 and 1.10.3.

Official fetch server SSRF (CVE-2026-104120, CVSS 7.3). Published October 2. The fetch_url tool in the official modelcontextprotocol/mcp-server-fetch package allowed server-side request forgery through the url argument. Remotely triggerable. This is the reference implementation shipping the vulnerability.

Unauthenticated debugger (CVE-2026-107824, CVSS 9.3). Published October 9. The x64dbg MCP server exposed every debugger tool over HTTP with no authentication, listening on all interfaces by default. Any network client could attach to processes, read and write memory, and write arbitrary files.

Python SDK credential theft (September 29, CVSS 7.5). The official MCP Python SDK sent client secrets, authorization codes, and PKCE proof keys to attacker-controlled token endpoints. Reported by Cycode. Client secrets are long-lived, so the blast radius extends well past the patch in 1.30.0 and 2.2.0.

The pattern nobody is fixing

Independent researcher Syed Anas Mohiuddin spent five months finding the same SSRF flaw across Google, JPMorgan Chase, Weaviate, Rapid7, a French government directorate, and an Indonesian city government. Five US federal AI servers, including one logging veterans' SSNs in unredacted error responses, were still unpatched six weeks after disclosure.

His conclusion is blunt: the MCP specification has no normative security requirements, and its implicit-trust model means independent teams keep rediscovering the same vulnerability class.

The numbers back him up. The MCPTox benchmark tested 20 LLM agents against 45 real MCP servers and measured attack success rates up to 72.8 percent. More capable models were more vulnerable, not less. Koi Security found the first real-world malicious MCP server in September 2025: fifteen clean releases of the postmark-mcp package, then a quiet update that BCC'd every agent-sent email to an attacker.

MCP has crossed 97 million installs. The registry is approaching 2,000 entries. The attack surface is growing faster than anyone's ability to audit it by hand.

What actually helps

Static rules do not keep up. Every one of the CVEs above was a novel instance of a known class in a new codebase. What catches them is screening tool calls and responses against live threat intelligence: known-bad indicators, phishing-kit fingerprints, scam-associated infrastructure, and neighbor servers with dirty reputations.

That is what the RelayShield MCP Proxy Firewall does. It sits between your agents and their MCP servers, screens every tool call and every response, and blocks or flags what matches the corpus. The pre-deployment scanner is free and catches misconfigurations before you ship. The runtime proxy is $49 a month.

Your MCP server is the attack surface now. Screen it like one.

Introducing the MCP Proxy Firewall: Stop Poisoned Neighbors Before They Poison You

relayshieldadmin — Tue, 13 Oct 2026 14:11:26 +0000

Introducing the MCP Proxy Firewall: Stop Poisoned Neighbors Before They Poison You

The Model Context Protocol (MCP) has become the standard for connecting AI agents to tools and data sources. But as adoption grows, so does the attack surface.

We built the MCP Proxy Firewall to secure the MCP ecosystem.

The Problem: Poisoned Neighbors

MCP servers are the new attack surface. When your agent connects to a third-party MCP server, you're trusting that server with your agent's capabilities. A single compromised server can:

Inject hidden instructions into tool responses (prompt injection)
Exfiltrate credentials to attacker-controlled domains
Serve phishing kit fingerprints disguised as legitimate widgets
Leak unredacted PII (SSNs, credit cards, bulk emails)
Abuse OAuth flows to steal tokens via malicious redirect URIs
Perform SSRF attacks to access internal infrastructure

The CVEs prove this isn't theoretical:

argocd-mcp shipped with no authentication, allowing unauthenticated access to deployments (CVE-2026-82456 pattern)
Rill had an OAuth flow that let attackers skip consent entirely
Multiple MCP servers have been found with prompt injection in tool descriptions

The OpenClaw incident brought this home. In the ClawHavoc attack, over 800 malicious skills were uploaded to OpenClaw's marketplace, triggering 1,142 security advisories. With 135,000+ exposed instances, the blast radius was enormous. OpenClaw uses MCP via the mcporter bridge, which means every one of those poisoned skills was a potential MCP attack vector. This wasn't a hypothetical. It was a marketplace-scale compromise of the exact ecosystem we're securing.

The Solution: Two Layers of Defense

Layer 1: Pre-Deployment Scanner (Free)

Before you connect your agent to an MCP server, scan it. Our pre-deployment scanner checks tool definitions for:

Prompt injection phrases: "ignore previous instructions", "you must now", "act as", system prompt overrides
Instruction hijacking: Tool descriptions that tell agents to behave differently
Exfiltration instructions: Descriptions telling agents to send data to external URLs
Dangerous capabilities: Shell execution, file deletion, arbitrary code execution
Credential harvesting: Input schemas requesting passwords, API keys, tokens
Unauthenticated access: Servers with no auth (the argocd-mcp pattern)

The scanner is free. Use it before every new MCP connection.

Layer 2: Runtime Proxy Firewall

Deploy as a reverse proxy between your agent and MCP servers. Every tool call and result is screened in real time:

SSRF Protection:

Blocks internal URLs (localhost, 169.254.169.254, 10.x, 192.168.x)
Validates redirect chains (max 3 hops, no protocol downgrade)
Stops DNS rebinding attacks
Deep document validation extracts and validates embedded URLs

OAuth Tampering Detection:

Flags suspicious scopes (long_lived_access_token, admin, *)
Blocks evil domains mimicking identity providers
Validates redirect URIs against allowlists

PII Protection:

Detects unredacted SSNs, credit cards, bulk emails in responses
Flags for review instead of blocking (fail-open with alert)

Threat Intelligence:

Matches responses against known phishing kit fingerprints
Screens URLs against 700K+ threat indicators
Checks wallet addresses for scam associations

Auditability:

Every decision is cryptographically signed
Full verdict history with cause codes
Confidence scores on every detection

Who This Is For

Enterprises: If your teams are building AI agents that connect to third-party MCP servers, you need runtime protection. The Proxy Firewall deploys as a transparent reverse proxy. No agent code changes required. Every decision is signed and auditable for compliance.

MSPs (Managed Service Providers): You manage MCP infrastructure for multiple clients. The Proxy Firewall gives you a single screening chokepoint. Deploy once, protect all your clients. The pre-deployment scanner lets you vet new MCP servers before onboarding them. White-label options available. If you're an MSP securing agentic workflows for clients, we want to talk.

Developers: The pre-deployment scanner is free. Integrate it into your CI/CD pipeline. Scan every MCP server before your agent connects.

Pricing

Cloud: $49/month flat, unlimited scans

The pre-deployment scanner is free forever. Scan before you connect.

Get Started

Documentation: [docs URL]
API: https://api.relayshield.net/developers
GitHub: https://github.com/nzdsf2-gif/relayshield

Why We Built This

We run RelayShield's threat intelligence operation, monitoring 125 Telegram marketplaces with 700K+ indicators. We see the phishing kits, the stolen credentials, the scam infrastructure.

When MCP emerged, we saw the same patterns forming. The protocol is powerful, but the security model assumes trusted servers. That assumption is already breaking.

The MCP Proxy Firewall is our answer: defense in depth for the agentic era.

RelayShield provides threat intelligence for the agentic economy. Our free MCP server offers scam checks for URLs, wallets, emails, and breach exposure with no signup required.

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.