NCSC, FBI and AIVD Named Iran's CHOSEN BRICK Yesterday. Its Twelve Hashes Have Been in Our Index Since March 26 Under the FBI's Name. Then We Checked the File We Actually Serve. Zero of Twelve.

Patrick Duggan · Sep 16, 2026 · 5 min read

Yesterday the UK's National Cyber Security Centre, the FBI and the Netherlands' AIVD published a joint advisory on a Windows malware family they call CHOSEN BRICK. It is Iranian, it is aimed at dissidents, activists and journalists in the UK, the US, the Netherlands and elsewhere, it has been running since at least 2025, and the personal details of some of its victims have already turned up on pro-Iranian leak sites. That last sentence is the one that matters; the rest of this post is about receipts.

What it is

The chain is social engineering first and malware second. The operator builds rapport on WhatsApp or Telegram, posing as someone the target has reason to trust, and then delivers a file that matches the story: a fake Pictory or RunwayML installer, a fake Norton, a fake Telegram, a fake KeePass, an MRI scan result. The payload persists through the HKCU Run key, registers a mutex so it doesn't run twice, and talks to a Telegram bot for command and control, with a different bot per victim, sometimes behind an HTTPS or SOCKS5 proxy from a commercial reseller. Exfiltration goes out through Telegram and through ordinary cloud object stores. Once in, it enumerates processes, captures the screen, records the microphone, reads browser-stored chat data, steals email, drops second-stage payloads, and can wipe the machine. There is no automated lateral movement. It is built for one person's laptop.

The advisory publishes no hashes and no attacker IP addresses, because there are none worth publishing: every victim gets a fresh bot. What it does publish is host detection content, two Run-key values, SMQDService pointing at smdqservice.exe and winappx pointing at winappx.exe, two mutexes, a deployment directory with a space in the path, and six domains to watch for in DNS and proxy logs. Those six are api.telegram.org, Backblaze B2, Vultr object storage, Storj, and two proxy resellers. They are legitimate services. Under the rule we run, compromised or abused infrastructure is a victim and never goes in a blocklist, so none of those six will ever appear in our domains.csv, and if a feed you pay for puts them there, you should ask why.

Both timestamps

Here is the part where we would normally say "in our feed since." Let's do it properly.

On March 20, 2026, FBI FLASH-20260320-001 published twelve MD5 hashes of MOIS malware using Telegram bots as command and control. The lure filenames were KeePass.exe, Pictory_premium_ver9.0.4.exe, Telegram_Authenticator.exe, WhatssApp.exe with the typo. The implants were MicDriver, RuntimeSSH, MsCache, and two exfiltration components named smqdservice.exe and winappx.exe. We wrote them up on March 26 in the middle of the Handala work, ingested all twelve under the source name fbi-flash, and noted in that post that three GitHub repositories had carried the hashes before we did. We were fourth. We said so.

The September 15 advisory names the family, describes the same lures, the same two exfiltration implants, the same Telegram-bot C2, and the same targeting of the same people. It does not cite the March FLASH. Putting the two side by side is the correlation event: CHOSEN BRICK is the malware in FBI FLASH-20260320-001, and the Handala toolkit and the "Iranian state cyber actors" of yesterday's advisory share an exfiltration binary by name. That is our contribution. The hashes are the FBI's. The name is NCSC's. The connection is ours, and it is a connection, not a lead.

Today the twelve records got the family name attached. Source field unchanged, references to the advisory added, read back twelve of twelve.

Timeline from the March 20 FLASH to the September 15 advisory, and a table of what the advisory offers: six legitimate domains never blocklisted, twelve hashes in the index but not in the served CSV, two mutexes and two registry values as host detection, no attacker IPs.

Then we checked the file we serve

A write is not done until it is read back, and a record in an index is not a record in a feed until the file a defender downloads contains it. So after the update landed we pulled hashes.csv and searched it for the twelve.

Zero of twelve.

The hashes.csv route selects documents by a type field. We said here, when this was first published, that it accepted only four spellings — sha256, md5, sha1 and hash — and that the FBI FLASH records, ingested in March as hash-md5, therefore never matched. The conclusion was right and the reason was wrong, and we found out by deploying the fix and measuring it. Correction follows.

Correction, 2026-09-21. Three separate places in the feed code each kept their own list of hash spellings. The one that builds hashes.csv already accepted seven, including filehash-sha256 and filehash-md5; it was the STIX bundle and one other endpoint that took only four. So the sentence above was accurate about the code in general and inaccurate about this file in particular. We unified all three onto one list of ten spellings and shipped it, which raised the documents the file can draw from by a factor of nearly three, from 30,230 to 85,676.

That deploy made the file smaller. It went from 62,500 rows to 21,081, and the endpoint's own header still reported X-Feed-Complete: true. The wider filter had tripped a second defect sitting underneath the first: the routine that pages through the corpus stops early when the last record on a page is older than the ninety-day window, on the assumption that a descending sort by timestamp runs in one direction across pages. In this corpus it does not. Measured on the database directly: page one ends 2026-09-07, page two ends 2026-02-08, and page three starts again at 2026-08-05, back inside the window. For six months the data happened to be orderly enough that the shortcut never fired. Widening the filter made it dense enough that it fired on page two and threw away two thirds of the feed while calling itself complete.

So the twelve FLASH hashes are still not in the file, and the real reason is the third one: they were ingested on 2026-03-26, and this file serves a rolling ninety-day window. They aged out in June. A type filter hid them from three endpoints; a recency window hides them from this one; and a truncation bug hid two thirds of everything else. Three defects, one symptom, and the only instrument that found any of them was downloading the file and counting.

Every post of ours that said "the hashes are in the feed" was describing the index. The artifact disagreed, and nobody curled it. That is the same shape as the edge sensor we fixed on Monday, which logged SUCCESS hourly for twenty-nine days while writing timestamps in the wrong unit. A green that nobody diffed against the thing it claims.

What a defender should do with this

If you run Windows fleets that dissidents, journalists or exiled activists use, and that describes a lot of newsrooms and NGOs, query the HKCU Run key for the two value names, alert on the two mutexes, and treat unexpected api.telegram.org, Backblaze, Vultr and Storj traffic from a workstation as a question, not a block. Train the humans, because the first stage is a conversation, not an exploit. And if you pull our hashes.csv, know that until the fix ships it is missing the twelve FBI hashes and about eleven thousand others above our own confidence floor. We would rather you read that here than discover it from a compromise.

Was this useful? Rate this post. The widget is at the bottom of the page, and we read every response.

How do AI models see YOUR brand?

AIPM has audited 250+ domains. 15 seconds. Free while still in beta.

Audit your site now → aipmsec.com

Was this useful? Thirty seconds, no cookies, no tracking, no third parties, your address hashed and never stored. If the box below does not load, the same question lives at https://analytics.dugganusa.com/nps.html?post=ncsc-fbi-and-aivd-named-iran-s-chosen-brick-yesterday-its-twelve-hashes-have-been-in-our-index-sin