Iranian state spyware ‘CHOSEN BRICK’: what it does and what to do
The NCSC, FBI and AIVD have exposed Iranian spyware — CHOSEN BRICK — used to surveil dissidents, activists and journalists. What the campaign does, who is really at risk, and the practical steps that protect the people targeted and the organisations around them.
On 15 September 2026 the National Cyber Security Centre, together with the US Federal Bureau of Investigation and the Netherlands' General Intelligence and Security Service (AIVD), published a joint advisory about a piece of Iranian state spyware. The NCSC tracks it as CHOSEN BRICK; the FBI calls the same family HEAVYGRAM and attributes it to Iran's Ministry of Intelligence and Security. It has been used since at least 2025 — the FBI's investigation traces related activity to 2023 — to spy on dissidents, activists and journalists around the world, including in the UK.
This is not a campaign against corporate networks for money. It is surveillance in the service of repression, and the people at the sharp end are individuals rather than institutions. But it reaches organisations all the same, because the people being targeted have employers, editors, universities and community groups behind them — and because the attackers deliberately step from a work device onto a personal one when the work device proves too well defended. That crossover is the reason this advisory deserves the attention of anyone responsible for the safety of at-risk staff, not just the individuals themselves.
Here is what the campaign does, who is genuinely at risk, and the practical steps that make a difference — for the people targeted and for the organisations around them.
What CHOSEN BRICK is, in plain terms
CHOSEN BRICK is spyware that runs on Windows. Once it is on a device it can quietly do most of what a person does at their keyboard: take screenshots, list running programs, read files, copy the contents of web browsers — including saved passwords from Chrome — and lift local data from Telegram and WhatsApp. It can extract a full Outlook mailbox, attachments and all. It can switch on the microphone and record. It can download further tools, run commands, delete files and, in at least one analysed sample, wipe the machine entirely.
The malware reports back through a Telegram bot, with a separate bot identity for each victim so that one discovery does not unravel the wider operation. Stolen files leave the device through that bot and through commodity cloud storage services. Newer versions route their traffic through proxies to make the Telegram connection harder to spot in network logs.
The technical detail matters less than the effect. The purpose of this tool is to build a complete picture of a person: who they talk to, what they say, where they are and what they look like at their desk. The NCSC is direct about why. Iran, it assesses, almost certainly uses this kind of activity to support the repression of people it sees as a threat to the regime. In some cases those operations have extended, in the physical world, to plots to harm individuals abroad. The personal details of earlier victims have surfaced on pro-Iranian leak sites, which turns a data theft into a genuine safety risk. Paul Chichester, the NCSC's Director of Operations, said the campaign shows how Iran "ruthlessly uses digital surveillance" to pursue its critics.
How the attack actually unfolds
The striking thing about this campaign is how little of it is technical. The break-in is a conversation.
The actors begin on the messaging apps their targets already use — WhatsApp, Telegram, sometimes Instagram — posing as someone the target knows, or as technical support from the platform itself. They have done their homework first, so the approach fits: a name the target recognises, a subject they care about, a plausible reason to get in touch. They build rapport over days before anything is asked of the target at all.
Then comes the file. It is dressed to match the conversation — an installer for a real application such as Pictory, RunwayML, Norton Antivirus, KeePass or Telegram, or in some cases a document made to look like a set of MRI scan results. When the target opens it, they see exactly the screen they expect: the installer, the report, the login. In the background, out of sight, the real payload installs itself and hands control of the device to the operator.
One detail in the advisory is worth dwelling on, because it is the part that turns a personal threat into an organisational one. The actors often make their first approach against the target's work device. If that fails — if the corporate laptop is well managed and the file will not run, or the risk of being caught looks high — they simply ask the target to open the file on their own phone or laptop instead. The personal device has none of the employer's protections, and the campaign steps neatly around every control the organisation has put in place. An employer that has secured its estate but never considered its people's personal devices has secured only half of the problem.
To survive a restart, the malware writes itself into a per-user registry key that runs programs at login and needs no administrator rights. It adds itself to Microsoft Defender's exclusion list so the built-in antivirus looks the other way. In one sample the loader was even signed with a legitimate code-signing certificate — since revoked — to look more trustworthy. None of this is exotic. It is competent, patient tradecraft aimed at people, not clever exploitation of software flaws.
Who is actually at risk — and who should care
It is worth being plain, because this is a topic where alarm helps no one. Most organisations are not the target of this campaign, and most people will never encounter it. The people in the crosshairs are specific: dissidents, activists and journalists connected to Iran, opposition figures and members of diaspora communities, and others the Iranian state regards as enemies.
But that list maps onto real workplaces. Newsrooms and freelance journalists. Human-rights and advocacy organisations. Universities with researchers, students and visiting academics from the region. Charities and community groups serving the diaspora. Any employer with staff who fit the profile — and who may not even realise they fit it — has people who could be approached, and a duty of care that now clearly extends to their digital safety and, by the pivot described above, sometimes to their personal devices.
If that is you, the useful response is not fear. It is to treat the risk as real for the few people it applies to, talk to them plainly, and put a small number of sensible controls in place. If it is not you, the same controls are good practice against the far more common phishing and account-takeover attacks that every organisation faces, so nothing here is wasted effort.
What to do about it
The single most effective defence, the advisory notes, is awareness: a target who recognises the social-engineering pattern will not open the file, and nothing that follows can happen. Everything else is there to catch the cases where awareness fails.
For individuals who may be at risk. Do not install software sent to you through a message or a link, however well the conversation has gone — go to the official website or app store and download it yourself. Keep your phone and computer updated automatically. Keep antivirus switched on and current. And do not click past a SmartScreen or antivirus warning to open a download; those warnings exist for exactly this moment. The NCSC also runs dedicated support for high-risk individuals, including free protective services, and if you believe you are being targeted by a foreign state the government's transnational repression guidance sets out what to do.
For the organisations around them. The advisory's recommendations for administrators are, reassuringly, the ordinary foundations of a well-run estate rather than anything special:
- Phishing-resistant multi-factor authentication on every account that will take it, so that stolen passwords — and this malware steals passwords — cannot be reused.
- Managed devices with application allowlisting and antivirus, so an unexpected installer cannot simply run.
- Email scanning and security from your provider, switched on and configured.
- Endpoint and network monitoring, so that the behaviours described above — a new autostart entry, a Defender exclusion appearing, a browser's password store being copied, traffic to services your business does not use — are seen rather than missed.
- A hunt through your logs for the indicators the agencies published, which we summarise below.
That last point is where continuous monitoring earns its place. CHOSEN BRICK is quiet by design, but it is not invisible: it touches the registry, changes an antivirus setting, and reaches out to a small set of external services. Someone watching for that pattern will catch it; a device left to its own devices will not. This is the everyday work of a managed SOC — not dramatic, mostly the patient correlation of small signals into an early warning. If you are weighing up whether that capability belongs in-house or as a service, our guide to what a managed SOC does and what it costs covers the ground, and the questions to ask a SOC provider checklist is a free, no-sign-up way to test whoever you are talking to.
Indicators to hunt for
The joint advisory publishes indicators of compromise so defenders can look for them. If your team monitors DNS or web-proxy logs, connections to the following services — where they are not part of your normal business — are worth investigating:
api[.]telegram[.]orgbackblazeb2[.]comvultrobjects[.]comstorjshare[.]ioiproyal[.]comlightningproxies[.]net
The last two are residential-proxy services; the rest are legitimate platforms the malware abuses, so their presence is a prompt to look closer, not proof of compromise on its own. On an individual Windows machine, the persistence lives in the registry. Someone comfortable doing so can list what runs at login with a single read-only command:
reg query HKCU\Software\Microsoft\Windows\CurrentVersion\Run
Entries the agencies have tied to this malware include values named SMQDService and winappx, though the advisory is explicit that names and paths change between victims, so an unfamiliar entry matters more than a specific one. If anything here looks wrong, do not try to clean it up alone — preserve the device and get help, because on a genuinely targeted individual the forensic trail and the person's safety both matter.
Detecting it with Wazuh
The indicators above are a good first pass, but domains and filenames change between victims — the actor said as much, and the advisories are explicit that names are not reliable on their own. The detections that last are the ones keyed on what the malware has to do: write itself into the Run key so it survives a reboot, switch off Microsoft Defender so it is not caught, stage its files in a handful of predictable folders, and reach out to cloud stores and proxies to send stolen data home. Each of those is a behaviour, not a string, and behaviours are what a SOC should alert on.
We run Wazuh in our own SOC, so here is a starting rule pack that turns those behaviours into alerts. It expects Sysmon forwarded to Wazuh with registry, file-creation, network and DNS logging switched on — a mainstream Sysmon configuration covers all of it — and the base Sysmon rule IDs shown are the Wazuh defaults. Renumber the rules to suit your own scheme, run them through wazuh-logtest, and tune the two or three noted below before you rely on them.
<!--
CHOSEN BRICK / HEAVYGRAM - Iranian state spyware (Iran MOIS)
Wazuh detection rules derived from the NCSC / FBI / AIVD joint advisory, 15 September 2026.
UK Cyber Defence - https://www.cyber-defence.io
Data sources: Sysmon forwarded to Wazuh, with registry (event 12/13), file-create (11),
network (3) and DNS (22) logging enabled. A mainstream Sysmon config (e.g. Olaf Hartong's
or SwiftOnSecurity's) covers all of these. Base Sysmon rule IDs referenced below are the
Wazuh defaults (61603 event 1, 61605 event 3, 61613 event 11, 61614 event 12, 61615 event 13,
61644 event 22) - confirm them against your own ruleset.
Before deploying: renumber the rule IDs to fit your scheme, run these through
/var/ossec/bin/wazuh-logtest, and tune the rules flagged below. Then restart the manager.
-->
<group name="sysmon,windows,chosen_brick,heavygram,iran_mois,">
<!-- Persistence: a Run-key value pointing at a staging directory the malware uses (T1547.001) -->
<rule id="100811" level="12">
<if_sid>61615</if_sid>
<field name="win.eventdata.targetObject" type="pcre2">(?i)\\CurrentVersion\\Run\\</field>
<field name="win.eventdata.details" type="pcre2">(?i)(\\ProgramData\\|\\AppData\\Roaming\\|MicrosoftDistribution|SMQDServicePackages)</field>
<description>CHOSEN BRICK: autostart Run-key value set to run an executable from a staging directory (persistence).</description>
<mitre><id>T1547.001</id></mitre>
<group>chosen_brick_persistence,chosen_brick_host,</group>
</rule>
<!-- Persistence: Run-key value names previously tied to this malware (T1547.001) -->
<rule id="100812" level="13">
<if_sid>61615</if_sid>
<field name="win.eventdata.targetObject" type="pcre2">(?i)\\CurrentVersion\\Run\\(SMQDService|winappx)$</field>
<description>CHOSEN BRICK: Run-key value name associated with this malware family (SMQDService / winappx).</description>
<mitre><id>T1547.001</id></mitre>
<group>chosen_brick_persistence,chosen_brick_host,</group>
</rule>
<!-- Defence evasion: adding a Microsoft Defender exclusion from the command line (T1562.001) -->
<!-- TUNE: legitimate administrators and some EDR installers also do this. Allowlist known-good callers. -->
<rule id="100813" level="13">
<if_sid>61603</if_sid>
<field name="win.eventdata.commandLine" type="pcre2">(?i)Add-MpPreference.{0,120}-Exclusion(Path|Extension|Process)</field>
<description>CHOSEN BRICK: Microsoft Defender exclusion added via the command line (antivirus tampering).</description>
<mitre><id>T1562.001</id><id>T1685</id></mitre>
<group>chosen_brick_tamper,chosen_brick_host,</group>
</rule>
<!-- Defence evasion: a Defender exclusion written straight to the registry (catches non-CLI methods) -->
<rule id="100814" level="12">
<if_sid>61614,61615</if_sid>
<field name="win.eventdata.targetObject" type="pcre2">(?i)\\Microsoft\\Windows Defender\\Exclusions\\</field>
<description>CHOSEN BRICK: Microsoft Defender exclusion written to the registry (antivirus tampering).</description>
<mitre><id>T1562.001</id></mitre>
<group>chosen_brick_tamper,chosen_brick_host,</group>
</rule>
<!-- Execution from a directory this family stages itself in (T1036) -->
<rule id="100815" level="12">
<if_sid>61603</if_sid>
<field name="win.eventdata.image" type="pcre2">(?i)(\\ProgramData\\(SMQDServicePackages|MicrosoftDistribution\\sysmain|Drivers\\Whatsapp|Drivers\\MicDriver|ssh-cache-default|ZlibDate)\\|\\Users\\All Users\\MicrosoftDistribution\\|C:\\Windows \\SysWOW64\\)</field>
<description>CHOSEN BRICK: process executed from a known malware staging directory.</description>
<mitre><id>T1036</id></mitre>
<group>chosen_brick_exec,chosen_brick_host,</group>
</rule>
<!-- A file written into one of those directories (T1105) -->
<rule id="100816" level="12">
<if_sid>61613</if_sid>
<field name="win.eventdata.targetFilename" type="pcre2">(?i)(\\ProgramData\\(SMQDServicePackages|MicrosoftDistribution\\sysmain|Drivers\\Whatsapp|Drivers\\MicDriver|ssh-cache-default|ZlibDate)\\|\\Users\\All Users\\MicrosoftDistribution\\|C:\\Windows \\SysWOW64\\)</field>
<description>CHOSEN BRICK: file created in a known malware staging directory.</description>
<mitre><id>T1105</id></mitre>
<group>chosen_brick_exec,chosen_brick_host,</group>
</rule>
<!-- Exfiltration / C2: DNS lookup of a cloud object store or residential proxy the actor uses -->
<rule id="100817" level="11">
<if_sid>61644</if_sid>
<field name="win.eventdata.queryName" type="pcre2">(?i)(^|\.)(backblazeb2\.com|vultrobjects\.com|storjshare\.io|iproyal\.com|lightningproxies\.net)$</field>
<description>CHOSEN BRICK: DNS lookup of a cloud store / proxy service used for exfiltration.</description>
<mitre><id>T1567.002</id><id>T1090.002</id></mitre>
<group>chosen_brick_c2,</group>
</rule>
<!-- Same infrastructure seen as an outbound connection (Sysmon event 3) -->
<rule id="100818" level="11">
<if_sid>61605</if_sid>
<field name="win.eventdata.destinationHostname" type="pcre2">(?i)(^|\.)(backblazeb2\.com|vultrobjects\.com|storjshare\.io|iproyal\.com|lightningproxies\.net)$</field>
<description>CHOSEN BRICK: outbound connection to a cloud store / proxy service used for exfiltration.</description>
<mitre><id>T1567.002</id></mitre>
<group>chosen_brick_c2,</group>
</rule>
<!-- Telegram bot command-and-control. TUNE: raise the level where Telegram is not used for business. -->
<rule id="100819" level="6">
<if_sid>61644</if_sid>
<field name="win.eventdata.queryName" type="pcre2">(?i)(^|\.)api\.telegram\.org$</field>
<description>CHOSEN BRICK: DNS lookup of api.telegram.org (Telegram bot C2) - review if Telegram is not used here.</description>
<mitre><id>T1102.002</id></mitre>
<group>chosen_brick_c2,</group>
</rule>
<!-- Discovery: enumerating startup programs with wmic (the malware's GetStartupApp command) -->
<rule id="100820" level="6">
<if_sid>61603</if_sid>
<field name="win.eventdata.commandLine" type="pcre2">(?i)wmic\s+startup\s+get</field>
<description>CHOSEN BRICK: enumeration of startup programs via wmic.</description>
<mitre><id>T1057</id></mitre>
<group>chosen_brick_discovery,</group>
</rule>
<!-- Correlation: two or more strong host signals (persistence, Defender tampering, staged execution) on one host -->
<!-- if_matched_group needs frequency >= 2; a single control changing is common, two together is not. -->
<rule id="100825" level="14" frequency="2" timeframe="900">
<if_matched_group>chosen_brick_host</if_matched_group>
<same_location />
<description>CHOSEN BRICK: two or more high-confidence host indicators (persistence, Defender tampering or execution from a staging path) on the same host within 15 minutes.</description>
<mitre><id>T1547.001</id><id>T1562.001</id></mitre>
<group>chosen_brick_correlation,</group>
</rule>
</group>
What each rule is looking for:
| Rule | Catches | Technique |
|---|---|---|
| 100811 / 100812 | A Run-key value pointing at a staging folder, or one of the known value names | T1547.001 |
| 100813 / 100814 | A Microsoft Defender exclusion being added, by command line or registry | T1562.001 |
| 100815 / 100816 | A process running from, or a file written into, one of the malware's staging folders | T1036 / T1105 |
| 100817 / 100818 | Contact with the cloud stores and proxy services used to exfiltrate data | T1567.002 |
| 100819 | A Telegram bot channel (api.telegram.org) — the command-and-control path | T1102.002 |
| 100820 | Startup programs being enumerated with wmic | T1057 |
| 100825 | Two or more strong host signals (persistence, Defender tampering, staged execution) on one host in 15 minutes | correlation |
Three of these need a moment's tuning for your estate. Legitimate administrators and some security tools also add Defender exclusions, so allowlist the callers you expect before rule 100813 is trusted. Rule 100819 sits deliberately low because plenty of organisations use Telegram for good reasons; raise its level where you do not. And the Run-key rule will see legitimate software installs, which is why the correlation rule (100825) matters — a single control changing is ordinary, but two of these strong signals landing on one machine within a few minutes is the pattern that should get someone out of their chair. That correlation is the everyday work of a managed SOC, and it is exactly the sort of low-noise, high-confidence detection we build and maintain for the organisations we watch.
Where to report it
Reporting is what lets the agencies see the shape of a campaign and warn the next person. In the UK, report significant incidents to the NCSC at report.ncsc.gov.uk, which is monitored around the clock. In the US, the FBI takes reports through its Internet Crime Complaint Center, and has published a fuller technical analysis of the malware. In the Netherlands, the AIVD or local police are the route.
A calm word to finish
State surveillance of journalists and dissidents is a serious thing, and it would be easy to write about it in a way that frightens people who are not at risk while doing nothing for those who are. The more useful position is the practical one. For the handful of people any given organisation employs who might genuinely be targeted, this is real, and it warrants a plain conversation and a little care — including about the personal devices the attackers deliberately reach for. For everyone else, the same handful of controls — phishing-resistant MFA, managed and monitored devices, a habit of downloading software only from source — quietly defends against this and against the far more common attacks that arrive every week.
If you employ people who could be in this category and you are not sure your controls extend to them, that is a conversation worth having rather than worrying about. We are happy to have it — talk to us, and we will give you a straight answer about what, if anything, you need to change. You can also read more of our work on state-linked threat actors, including a profile of the Iranian group Charming Kitten (APT35).
Written by
Founder and Head of Threat Disruption
Founder of UK Cyber Defence. Former Global CISO for a FTSE 100 gaming company and for Microsoft Europe; founded Hedgehog Security in 2009.
Next step
Want this looked at in your own estate?
Thirty minutes with an analyst, not a salesperson. We will tell you whether it matters to you and what to do first.
Related insights
How Alert Fatigue Destroys Security Teams — and How Managed SOC Solves It
The modern SOC is drowning. Industry research consistently reports that organisations receive thousands of security alerts per day, that the majority are false positives, and that analysts are leaving the profession faster than the industry can replace them. Alert fatigue is not a minor inconvenience — it is a structural vulnerability that attackers actively exploit. When every alert looks the same, none of them look important. This article examines the mechanics of alert fatigue, its quantifiable cost to organisations, and the specific practices a well-engineered managed SOC deploys to break the cycle — because the solution is not working harder, but building a fundamentally different operational model.
Pro-Russian Cyber Activity: Hybrid Threats and the UK Response
An insights article assessing pro-Russian cyber activity with a situational briefing on hybrid threats to UK-aligned institutions. Includes a side-by-side comparison of key threat groups including KillNet, NoName057(16), and XakNet.
How SOC as a Service Supports FCA, DORA and NIS2 Compliance
The regulatory environment for cyber security has undergone a fundamental shift. The FCA's PS21/3 operational resilience framework is now fully enforceable, DORA has been in effect since January 2025, and NIS2 transposition is reshaping obligations across the EU — with the UK's own Cyber Security and Resilience Bill following close behind. For organisations navigating these overlapping requirements, a well-structured SOC as a Service engagement is no longer a convenience. It is a compliance enabler. This article maps the specific requirements of each framework to the capabilities a modern managed SOC should deliver.