# Chosen Brick Shows Why a Familiar Message Needs a Second Channel

> Iran-linked operators used researched conversations and convincing files to put spyware on Windows computers. The useful defence starts before the download, with a separate-channel check that preserves both the message and the device.

- **Author:** Kubilay Tunca
- **Published:** 2026-09-16
- **Category:** For Experts
- **Tags:** Privacy, Surveillance, Phishing, Digital Safety
- **Canonical URL:** https://cyber-security-in-plain-english.com/post/experts/news/chosen-brick-familiar-message-second-channel

---

A message arrives from someone you know. They remember the conference where you met, ask about work you are actually doing, and refer to a person both of you trust. Nothing in the first exchange asks for a password. Nothing looks urgent. The conversation earns its way into your ordinary life.

Days later, the sender shares a file. It may look like a video tool, a password manager, a Telegram utility, or even an MRI scan. They ask you to open it on a Windows computer. If your work laptop blocks the file, they suggest trying your personal machine instead.

That sequence sits at the centre of a spyware campaign described on September 15, 2026 by the UK National Cyber Security Centre, the US Federal Bureau of Investigation, and the Netherlands' General Intelligence and Security Service. The agencies call the malware family CHOSEN BRICK. [Their joint advisory says Iranian state cyber actors used it against dissidents, activists, journalists, and others perceived as threats to the Iranian government](https://www.ncsc.gov.uk/sites/default/files/2026-09/Advisory-Iranian-Cyber-Targeting-of-Dissidents-Activists-and-journalists.pdf). Once installed, it can take screenshots, record through the microphone, steal messages and email, download more malware, and delete data.

The name of the malware will change. The more durable lesson is about trust. A familiar account, a plausible story, and a long conversation can all be parts of the delivery system. If your work exposes you or your sources to a state adversary, the question before opening a file is simple: did the person I trust send this, and can I prove that through a different route?

## What the agencies found, and what they did not prove

The September advisory describes a targeted operation rather than a mass email campaign. The operators research a person, approach them through messaging services such as WhatsApp or Telegram, and pose as a known contact or as technical support. They build rapport before asking the target to open anything. [The NCSC says the bait has included files made to resemble Pictory, RunwayML, Norton Antivirus, Telegram, Adobe Flash Player, KeePass, and MRI results](https://www.ncsc.gov.uk/sites/default/files/2026-09/Advisory-Iranian-Cyber-Targeting-of-Dissidents-Activists-and-journalists.pdf).

The FBI's own technical report gives the campaign a longer observed history. [It says investigators obtained samples connected to Iranian Ministry of Intelligence and Security actors and dates versions of the Windows malware to the autumn of 2023](https://www.fbi.gov/file-repository/government-of-iran-cyberactors-deploy-telegram-c2-to-push-malware-to-identified-targets.pdf). The joint advisory says CHOSEN BRICK has targeted people around the world from at least 2025. Those dates describe different scopes, so the earlier FBI date does not necessarily contradict the later one. It does show why a victim should not use the publication date as the beginning of the exposure window.

Independent newsrooms reported the same government disclosure while keeping the attribution attached to the agencies. [Reuters reported on September 15 that Britain, the United States, and the Netherlands had issued coordinated warnings about Iran-linked spyware](https://www.reuters.com/world/uk-us-netherlands-issue-advisory-iran-spyware-2026-09-15/). [The Register separately reviewed the advisory and reported that all observed CHOSEN BRICK infections described there involved Windows](https://www.theregister.com/security/2026/09/15/iranian-spies-hit-windows-machines-with-chosen-brick-data-stealing-malware/5296646). Public reporting does not give outsiders the underlying case files, victim count, or every sample used for attribution. The careful statement is that three national agencies attribute the campaign to Iranian state actors, while the public technical material supports the malware behaviour and delivery pattern they describe.

Several limits matter. The advisory does not say that every unexpected Telegram message is part of this operation. It does not claim that CHOSEN BRICK infects a computer merely because a message appears. In the observed chain, a person is persuaded to download and open a malicious Windows file. The agencies also say they have not observed automated movement from one computer to others on the same network, though the malware can download additional programs that could add that ability.

That restraint changes the response. You do not need to abandon every messaging app or treat every contact as an enemy. You need a rule for a narrow, high-consequence moment: when a conversation crosses from words into code, move the verification somewhere the sender cannot control through the same compromised account.

## The conversation is part of the exploit

A generic phishing email often gives itself away. The greeting is wrong. The request arrives without context. The sender wants action before you can think. Targeted social engineering works differently because the operator has time and a specific person in mind.

The CHOSEN BRICK advisory says the actors use prior research to tailor their approach. They may know your contacts, your work, and the organisations around you. A reference to a real colleague therefore proves very little. Public biographies, event programmes, social posts, leaked address books, and earlier account compromises can supply enough detail to imitate familiarity.

Imagine a reporter who covered an Iranian opposition group. A Telegram contact appears to be a researcher introduced at a conference six months earlier. The account comments accurately on a published article, asks two harmless questions, and returns a week later with what it calls an interview recording. The file carries a familiar icon. The story is internally consistent because the attacker built it from real pieces.

The dangerous step comes after the trust has already formed. The operator asks the target to run a program. According to the advisory, some victims first received the request on a work device. When workplace controls blocked the delivery or made detection more likely, the operator tried to move the file to a personal computer. That suggestion sounds practical: perhaps the company laptop is simply too restricted. In reality, it removes the machine from the organisation's monitoring, application controls, and incident-response team.

This is why “be careful with suspicious messages” is weak advice. The message may have earned a place among ordinary messages before it becomes suspicious. A useful rule must survive a convincing conversation. Files that can run code deserve an independent check even when the sender feels familiar, patient, and informed.

The check can be brief. Call the person on a number you already had. Ask them through a second established account. Use a newsroom directory, an editor, or a mutual contact whose details did not come from the current conversation. Do not ask the questionable account to recommend the verification route. If the same operator controls both the claim and the proof, you have performed a ceremony, not a check.

## Telegram carried commands, but Telegram was not the whole attack

The campaign's use of Telegram can invite the wrong conclusion. CHOSEN BRICK connects to Telegram bots after infection, and operators use those bots to send commands to individual victim machines. The FBI describes bidirectional communication between compromised computers and `api.telegram.org`. The joint advisory says each observed victim used a separate bot identifier, which reduced the chance that discovery of one infection would expose the rest.

That arrangement gives malicious traffic ordinary company. A network connection to a popular service can blend into legitimate use, especially in an organisation where Telegram is common. The malware also used cloud storage and proxy services for moving data or obscuring traffic. A single domain name in a log is therefore a clue that needs context, not a verdict.

Blocking Telegram would address only one route used by this family. It would do little about the human relationship that delivered the file, and a later version could move its command traffic elsewhere. The stronger controls sit closer to the harmful effects: prevent unapproved programs from running, keep security tools active, record changes to antivirus exclusions, and alert when an ordinary user account creates an unexpected program that starts at login.

The same distinction matters for personal practice. Moving a sensitive conversation from one mainstream messenger to another does not repair a Windows computer that already runs hostile code. End-to-end encryption protects a message while it travels between devices. Malware on an endpoint can wait until the message appears on screen, copy the browser's stored data, take a screenshot, or record the room through the microphone.

Encryption still matters. It blocks network observers and service providers from reading protected content under the conditions the tool promises. Yet the endpoint remains where encrypted words become readable to you. CHOSEN BRICK attacks that moment. The Anonymity Playbook returns to this seam repeatedly because secure transport cannot rescue a device that has joined the other side.

A targeted person should keep the categories separate. Messenger security governs the path between devices. Account security governs who can log in as you. Device security governs what can see and do things after login. An attacker only needs one useful opening. Your response has to identify which layer failed before choosing the repair.

## What one opened file can expose

The September advisory lists a wide set of commands. CHOSEN BRICK can enumerate running programs and system details, capture the screen, activate the microphone, copy Telegram and WhatsApp browser data, steal email, retrieve more malware, delete files, and wipe the computer. The FBI says one related component recorded screen and audio while Zoom was active. These are observed or analysed capabilities, though the public documents do not claim that every function ran against every victim.

For a journalist or activist, the first loss may belong to someone else. A screenshot can reveal a source's name in a notification. Browser data can expose a conversation history. Email can reveal travel plans, draft reporting, lawyers, relatives, or people who merely asked a question. Microphone access can capture a meeting that never touched the infected computer except through the room around it.

The agencies say screen capture was commonly observed and could help operators map contacts, location, and daily routine. They also say personal details from some previous victims appeared on pro-Iranian leak sites. The FBI connects parts of the campaign to hack-and-leak activity, where stolen material may be selected, manipulated, or published for political and reputational effect. [Al Jazeera's report on the September warning quotes the FBI's assessment that the operation supported intelligence collection, data leaks, and reputational harm](https://www.aljazeera.com/news/2026/9/15/western-intelligence-warns-of-iranian-cyber-threats-targeting-dissidents).

That changes incident response. Cleaning the laptop may stop future collection, but it cannot pull back a contact list already copied or a screenshot already published. The affected person may need technical containment, source protection, legal advice, physical-safety planning, and careful communication with people whose details appeared on the device. A password reset handles only a small part of that work.

The location of the reset matters too. Changing passwords on the suspected computer can hand the new credentials to the same malware. Use a separate device that you have reason to trust. Start with the accounts that can reset other accounts, especially primary email, password managers, and mobile-provider access. Review active sessions and recovery details as well as passwords, because a stolen session may survive a password change.

Do not rush to warn every contact from the suspect machine. That message may reveal your response to the operator or give the malware another set of words to capture. Work out a communication route with your editor, security team, lawyer, or specialist support. For a high-risk target, the order of actions is part of the safety plan.

## Personal devices are inside the threat model

Workplaces often draw the security boundary around equipment they own. That makes sense for administration, but it does not match the operator's view. The advisory describes attempts to move delivery from a protected work computer to a personal device when the first route failed. The human target stayed the same while the defensive boundary disappeared.

A newsroom can have excellent laptop monitoring and still leave a reporter alone with the machine used for family email. A civil-society group can require hardware security keys for organisational accounts while staff discuss travel through personal messaging profiles. Contractors, volunteers, and relatives may sit outside formal support even though their devices contain routes to the same people and plans.

Bringing personal devices into the threat model does not require an employer to seize control of them. That can create privacy, labour, and trust problems of its own. It requires an explicit support path. High-risk staff should know whom to call, whether the organisation can arrange confidential device examination, what costs it will cover, and how personal information found during an investigation will be handled.

The joint advisory recommends that organisations circulate the warning to people likely to be targeted and support checks of personal devices as well as corporate ones. That advice is unusually important. A staff email saying “do not open suspicious files” transfers responsibility to the person while withholding the help needed when a plausible file has already been opened.

Good support starts before the incident. Give people a number or account they can reach without the suspect device. Decide who can approve temporary equipment. Keep a short paper record of emergency contacts. Practise moving one sensitive conversation to a clean route. These measures feel mundane beside malware analysis, which is exactly why they tend to work under stress.

There is an honest limit. A spare laptop kept in the same routine, signed into the same accounts, and used for ordinary browsing will slowly become another ordinary laptop. Separation has a maintenance cost. The device must receive updates, its purpose must stay narrow, and the person using it needs a workable way to transfer approved material without rebuilding the original bridge.

## A practical response if you opened the file

If you remember opening a file that fits this pattern, preserve your options before chasing filenames from the advisory. Names such as `KeePass.exe` or `winappx.exe` can be copied by unrelated software or changed by the operator. The FBI explicitly warns that isolated indicators should be judged in the context of the whole system. A clean search for one filename does not clear the device.

The sequence below is designed for someone whose contacts or physical safety could be affected. It favours containment and qualified help over improvised cleanup. An ordinary home user with no connection to the described target groups should still take an unexpected executable seriously, but the state-threat response is deliberately more cautious.

1. **Move the conversation to a separate trusted device.** Stop using the suspected Windows computer for sensitive messages, password changes, travel planning, or warnings to contacts. Use a device that did not receive or open the file, and avoid copying material from the suspect computer unless an investigator tells you how.

2. **Contact specialist help before deleting evidence.** Your organisation's security team may be able to preserve logs and examine the machine. Independent journalists, activists, and human-rights defenders can contact the [Access Now Digital Security Helpline, which provides round-the-clock technical help to at-risk civil-society groups and individuals](https://www.accessnow.org/help/). If personal safety is at stake, involve the appropriate legal and physical-security support as well.

3. **Record what happened from memory.** On clean paper or the trusted device, note the account that contacted you, dates, platform, story used, filename, where it was downloaded, and whether the sender pushed you from a work machine to a personal one. Do not reopen the file to improve the notes. A rough timeline helps an investigator look in the right places.

4. **Preserve the suspicious message and file without circulating them.** Do not forward the executable to colleagues for a second opinion. That creates more possible victims and may strip useful context. Keep the device powered and isolated according to the responder's advice; shutting it down, wiping it, or running aggressive cleanup tools can destroy volatile or forensic evidence.

5. **Protect accounts from the clean device.** Change the password for primary email and other recovery accounts, review active sessions, remove unknown recovery methods, and enable phishing-resistant multi-factor authentication where available. Prioritise accounts visible on the infected computer. Assume screenshots and browser-stored sessions may have exposed more than typed passwords.

6. **Plan contact notifications with the responder.** Identify people whose names, messages, locations, or plans were accessible. Tell them through a route that does not depend on the suspect device or account. Give concrete facts and actions without forwarding the original bait or making claims the investigation has not established.

7. **Rebuild only after evidence and scope are handled.** An antivirus scan can contribute evidence, but a green result cannot prove absence. For a confirmed state-linked implant, reinstalling the operating system from trusted media or replacing the device may be the soundest route. Restore documents cautiously, reinstall software from official sources, and avoid restoring unknown executables or a full system image that may carry the problem back.

In the United Kingdom, the NCSC asks people to report significant incidents through its reporting service. In the United States, the advisory directs victims to the FBI Internet Crime Complaint Center. In the Netherlands, it directs people who suspect or confirm compromise to the AIVD or local law enforcement. Reporting may help connect one case to a wider campaign, but it should complement immediate safety and technical support rather than delay them.

## Build a rule that still works when the message is convincing

Prevention advice often assumes that a malicious file will look malicious. The observed lures in this campaign were chosen to fit the target. A fake password manager could arrive during a real security discussion. False MRI results could exploit a genuine health concern. The visual screen shown after opening could continue the story while malware ran behind it.

A durable rule should focus on behaviour rather than appearance. Software comes from the vendor's official site or the device's app store, reached independently. A contact who sends an unexpected program, archive, shortcut, or document that asks to enable code gets verified through a second route. A request to move from a managed work computer to a personal one triggers a stop and a call to support.

File extensions deserve attention, though they cannot carry the whole defence. Windows may hide known extensions, and a document icon can belong to an executable. Showing full extensions helps a person see that `scan-results.pdf.exe` ends in `.exe`, but a correctly named malicious document or signed program can still cause harm. Application allowlisting and managed installation policies take the final decision away from the heat of the conversation.

Security warnings also need institutional backing. The joint advisory says the malware may add Microsoft Defender exclusions. Organisations should monitor changes to those exclusions and to login-startup locations, including the current user's Windows Run registry key. They should retain endpoint, DNS, and web-proxy records long enough to investigate the period before the warning arrived. Traffic to Telegram, cloud storage, or proxy providers needs context because legitimate programs use those services too.

Training should rehearse the exact social pressure. Ask a colleague to imagine a known contact who has spent a week building rapport, then sends a file needed for tomorrow's work. The desired response is not “spot the fake logo.” It is “verify executable files somewhere else, and call us if the sender asks you to bypass the work device.” That sentence can survive a better logo.

A high-risk team can go further by agreeing on verification habits with close contacts. A pre-arranged voice call, a known number, or a question grounded in shared private context can help, provided the answer is not stored in the same compromised account. No single challenge phrase should become a permanent master key. The goal is to create friction and a second observation, not to invent a secret that never changes.

## The second channel buys time

CHOSEN BRICK succeeded through a seam between social trust and machine authority. The operator learned enough to sound familiar. The file looked connected to the conversation. Windows then treated the opened program as code allowed to act for the logged-in user.

You cannot make every message provably authentic. Accounts get stolen, people reuse channels, and a patient operator can learn a great deal. You can reserve a second channel for the moment a conversation asks your device to cross a dangerous boundary. That check forces the attacker to control more than one account, survive a live call, or abandon the delivery.

The technique has limits. A compromised phone may undermine a second message sent from the same device. A coerced contact may pass a voice check. Deepfake audio can make an unfamiliar voice sound plausible. High-risk verification therefore works best when it combines an independently sourced route, context the current account did not supply, and a policy that blocks unknown code even if the human check fails.

That is still a meaningful increase in cost. Targeted surveillance thrives on a smooth handoff from believable words to executable code. Break the handoff. Keep the message, the proof, and the device from becoming one unexamined chain.

For practical security and privacy guidance without a daily panic cycle, join the newsletter. It is one email per month.

## Sources

- [UK National Cyber Security Centre, FBI, and AIVD: Advisory on Iranian Cyber Targeting of Dissidents, Activists and Journalists](https://www.ncsc.gov.uk/sites/default/files/2026-09/Advisory-Iranian-Cyber-Targeting-of-Dissidents-Activists-and-journalists.pdf), accessed 2026-09-16
- [UK National Cyber Security Centre: UK and allies expose spyware used by Iranian state actors](https://www.ncsc.gov.uk/news/uk-allies-expose-spyware-iranian-state-actors-target-dissidents-activists-journalists), accessed 2026-09-16
- [Federal Bureau of Investigation: Government of Iran Cyber Actors Deploy Telegram C2 to Push Malware to Identified Targets](https://www.fbi.gov/file-repository/government-of-iran-cyberactors-deploy-telegram-c2-to-push-malware-to-identified-targets.pdf), accessed 2026-09-16
- [Reuters: UK, US and Netherlands issue advisory on Iran spyware](https://www.reuters.com/world/uk-us-netherlands-issue-advisory-iran-spyware-2026-09-15/), accessed 2026-09-16
- [The Register: Iranian spies hit Windows machines with Chosen Brick data-stealing malware](https://www.theregister.com/security/2026/09/15/iranian-spies-hit-windows-machines-with-chosen-brick-data-stealing-malware/5296646), accessed 2026-09-16
- [Al Jazeera: UK, US, Netherlands warn of Iranian spyware targeting dissidents](https://www.aljazeera.com/news/2026/9/15/western-intelligence-warns-of-iranian-cyber-threats-targeting-dissidents), accessed 2026-09-16
- [Access Now: Digital Security Helpline](https://www.accessnow.org/help/), accessed 2026-09-16

---

## About the author

Kubilay Tunca — Senior Full Stack Developer and Author. Founded Cyber Security in Plain English to translate complex security concepts into clear, practical advice, and writes the accompanying books on security, privacy, secure development, and AI systems.

## Books by this author

- **The Digital Fortress** — Your Everyday Guide to a Safer Digital Life. A warm, plain-English guide for people with real lives and finite patience. Learn the handful of habits that genuinely protect your money, accounts, and family, and get honest permission to ignore the rest. [Amazon](https://buy.cyber-security-in-plain-english.com/digital-fortress) · [Details](https://cyber-security-in-plain-english.com/books/the-digital-fortress)
- **The Anonymity Playbook** — Digital Survival for Whistleblowers, Journalists, Activists, and Everyone Else. A practitioner’s field manual for journalists protecting sources, whistleblowers, and activists. It explains how the surveillance actually works, what each technique costs you, and exactly where it fails. [Amazon](https://buy.cyber-security-in-plain-english.com/anonymity-playbook) · [Details](https://cyber-security-in-plain-english.com/books/the-anonymity-playbook)
- **Secure Software Development** — Practical patterns for building secure software. A hands-on security guide for developers and IT professionals who ship real software. Build, deploy, and maintain secure systems without slowing down or drowning in theory. [Amazon](https://buy.cyber-security-in-plain-english.com/secure-software-development) · [Details](https://cyber-security-in-plain-english.com/books/secure-software-development)
- **The Secure Harness** — Shipping Production Code with AI Coding Agents. A calm, practical guide to letting agents do useful work inside boundaries you set, enforce, and audit. Ships with 15 copy-pasteable artifacts: hook scripts, permission configs, release gates, and MCP templates. [Amazon](https://buy.cyber-security-in-plain-english.com/secure-harness) · [Details](https://cyber-security-in-plain-english.com/books/the-secure-harness)
- **The AI Native Engineer** — Build, Evaluate, and Ship AI Systems That Work in Production. Sixteen hands-on chapters, one real product. Grow it from a single model call into a retrieved, tool-using, observable, production-grade system, with evaluation treated as a habit from the first feature. [Amazon](https://buy.cyber-security-in-plain-english.com/ai-native-engineer) · [Details](https://cyber-security-in-plain-english.com/books/the-ai-native-engineer)

Full catalogue with contents and intended audience: https://cyber-security-in-plain-english.com/books

_As an Amazon Associate I earn from qualifying purchases. Buying through these links costs you nothing extra and helps pay for the blog._