The civil alert platform MahsaAlert is a crisis alert and mapping platform created by Iranians outside the country to provide information about protests, arrests, and human rights violations in Iran. With the start of the conflict between the United States and Israel and the Islamic Republic of Iran, this platform began issuing alerts in wartime conditions in order to help protect civilians from the collateral damage and secondary harms of the war.
Last week, the MahsaAlert platform effectively went offline without actually being hacked or having its server compromised. According to Raznet’s investigation, an individual or group created a real Windows malware sample (a RAT, or Remote Access Trojan) and embedded the domain mahsaalert.com in it as the command-and-control (C2) server address. They then uploaded the malware sample to malware analysis platforms such as VirusTotal.
As a result, when security engines and sandboxes executed this malware, they observed that the program attempted to connect to that domain. Consequently, many cybersecurity companies and threat-intelligence databases flagged the domain as malware infrastructure. These labels quickly spread across the global threat-intelligence ecosystem, and firewalls, security services, and even some DNS resolvers began blocking the domain.
Services of this kind can become targets of disruption operations because of their role in information dissemination. The method used in this case is an example of an indirect attack: instead of attacking the server or penetrating the system, the attacker attempted to exploit the automated mechanisms of the cybersecurity industry to damage the domain’s reputation so that users and networks would block access to it.
The purpose of the report is essentially to warn about a structural weakness in the global threat-intelligence system: many systems declare domains malicious solely based on data correlation (for example, that a piece of malware connects to a domain), while an actual verification of whether that server truly behaves like a malware command-and-control server is not always carried out.
The main point of the report is that this incident occurred without any real intrusion into the server, and was made possible solely through domain reputation poisoning.
In the following section, you can read the technical analysis of this investigation and how the attacker carried out the operation:
Technical Writeup
How a Trojan (Almost) Killed our Domain Without Touching the Server
In February 2026, mahsaalert.com got blacklisted by CrowdStrike, Palo Alto, Fortinet, Spamhaus, and dozens of other threat intelligence vendors. The domain was flagged as a command-and-control server for a Windows trojan. Enterprise firewalls worldwide started blocking it. Cloudflare even flagged our domain as phishing, and stopped resolving it from 1.1.1.2 and 1.1.1.3 resolvers.
Here's the thing: the server was never compromised. Not even close.
Someone built a real piece of malware, hardcoded mahsaalert.com as its C2 address, and uploaded it to VirusTotal. That's it. That's the whole attack. The threat intel ecosystem did the rest automatically.
MahsaAlert is a civil alerts and crisis mapping platform developed by diaspora Iranians for at risk users inside Iran. It sends alerts about protests, arrests, and human rights violations. The kind of thing certain governments would love to see disappear from the internet. And this attack nearly accomplished exactly that, without a single packet of malicious traffic ever originating from the server.
The Malware Is Real
Let me be clear about something: the malware itself is not a joke. It's a fully functional Windows RAT called explorer.exe, detected by 52 out of 72 antivirus engines on VirusTotal.
SHA256: eb56f800c2437a736be9deb2d8d5bbb0518396da642110664dba1df19250a67a
It's a PE64 binary, UPX-packed, with a multi-stage kill chain. It drops secondary payloads (firstact.exe, oflove.exe, a fake svchost.exe), runs reconnaissance commands (ipconfig, arp -a, wmic), steals Chrome browser data, takes screenshots with randomized filenames, sets a registry Run key called SystemUpdateHelper for persistence, and beacons out to its C2 over encrypted HTTPS.
This is not someone's homework project. The malware has sandbox evasion (IsDebuggerPresent, GetTickCount timing checks), rotates through a database of 188+ User-Agent strings to blend in with legitimate traffic, and encodes its encrypted payload as a base64url path in the GET request URL. Sophisticated enough to fool automated analysis, dumb enough to leak metadata from its own UA database (some User-Agent strings end with artifacts like \\\\x22,47,Common from the internal list format).
The C2 communication works by encoding 169 bytes of encrypted data into the URL path of HTTPS GET requests to mahsaalert.com. Every single beacon hits the same path. It's a static heartbeat, not dynamic exfiltration. The malware also tries POST requests using Go-http-client/1.1 as the User-Agent, presumably for uploading stolen data.
What the Server Actually Did
Nothing. The server did absolutely nothing with these requests.
MahsaAlert is a static single-page application behind Cloudflare. When the malware's beacon hit the server, the web server matched the unknown path against its fallback routing and served index.html. 1,461 bytes of a normal landing page. Every time. For every beacon.
We observed 199 GET beacon requests and 10 POST attempts in a single 24-hour window (February 16-17, 2026). The POSTs all got a 405 Method Not Allowed because the web server doesn't accept POST on static routes. There was no C2 logic, no special handlers, no hidden endpoints. It was just serving a website.
The irony here is thick: the server's response to every C2 beacon was literally "here's our homepage about human rights in Iran."
How the Reputation Poisoning Works
This is where it gets interesting. And infuriating.
The attacker didn't need to compromise the server. They didn't need access to anything. They just needed to understand how the threat intelligence ecosystem works, and then abuse it.
Step one: build real malware. Not a dummy file, not a harmless test binary. A genuine, dangerous trojan that will trigger every AV engine on the planet.
Step two: hardcode the target domain as the C2 callback address.
Step three: upload to VirusTotal. Maybe run it in a few sandboxes for good measure.
Step four: wait.
The automated pipeline kicks in immediately. VirusTotal shares samples with its partners. Sandboxes execute the binary and observe it making HTTPS connections to mahsaalert.com. The sandbox reports get syndicated. CrowdStrike's Falcon sees the association. Palo Alto's WildFire correlates it. Fortinet flags the domain. Spamhaus picks it up. Within 48 hours, mahsaalert.com is labeled "C2 infrastructure" across the global threat intelligence ecosystem.
No human ever looked at this and asked: "Wait, does this server actually respond like a C2?" Nobody checked if the domain was serving legitimate content. Nobody noticed that the "C2 server" was returning the same static HTML page for every request. The system runs on correlation, not verification.
The malware is real. The C2 domain is fake. And no automated system in the threat intelligence pipeline can tell the difference.
The Asymmetry Problem
Here's the math that keeps me up at night.
The attacker probably spent about 8 hours total: writing the malware, testing it against AV engines, uploading it. Maybe a day if they were being careful.
Getting delisted from every threat feed? That takes 3 to 6 months. Minimum. There's no "global retraction" button. You contact CrowdStrike, and they have their own process. You contact Palo Alto, different process. Fortinet, different again. Spamhaus has its own timeline. Some vendors require you to create accounts on their portals before you can even file a dispute. Others need you to submit evidence in specific formats.
Meanwhile, every enterprise firewall subscribed to these feeds is blocking your domain. Your users can't reach you. The platform that exists specifically to help people in danger goes dark.
We made a pragmatic decision: migrate to a new domain. mahsaalert.com now serves a redirect page. The platform lives at mahsaalert.app. It's faster than fighting the delisting war, but it's also a concession. The attacker won that round.
The Attribution
Both mahsaalert.com and mahsaalert.dev were hardcoded in the binary. That requires knowing both domains exist, which means the attacker did their homework on MahsaAlert's infrastructure.
The target is an Iranian activist platform. The attack method is designed to disrupt without leaving forensic evidence of a direct hack. The malware shows professional-grade tradecraft: encrypted C2, UA rotation, sandbox evasion, multi-stage deployment. This isn't a script kiddie.
I'm calling it: medium-high confidence that this is a state-sponsored or state-adjacent operation. The profile fits known patterns of Iranian government-linked actors targeting diaspora activism platforms.
We Triple-Checked the Server
Before concluding "reputation poisoning," we had to rule out actual compromise. We ran forensics across every layer.
Host level: no rootkits, no rogue kernel modules, no suspicious cron jobs, no unexpected SUID binaries, no shell history showing attacker commands. Everything pointed to normal admin activity.
Network level: no outbound connections to any known C2 infrastructure. Nothing phoning home. We checked against all known react2shell (CVE-2025-55182) C2 IPs just to be thorough. Clean.
Application level: all containers traced back to legitimate sources. No rogue services, no hidden routes, no webshells. The front-end is a static build served by a vanilla web server. CVE-2025-55182 (React2Shell) doesn't apply either, since that requires React Server Components running server-side. Not our architecture.
The server was clean. The only evidence of anything unusual was the C2 beacon traffic arriving from the outside, which is exactly what the attacker wanted the threat intel systems to see.
The C2 Traffic Up Close
Looking at the actual beacon traffic in our access logs is almost comical in hindsight.
Every 5-15 minutes (average 7.2 minutes), a request comes in with a 225-character base64url-encoded path. Same path every time. The User-Agent is different on every request: Chrome on Windows, Safari on macOS, Firefox on Linux, Konqueror on OpenBSD, Chrome on an Android vivo phone. The rotation is impressively thorough but also obviously synthetic. No real user switches from Konqueror on OpenBSD to Chrome on a vivo phone every 5 minutes.
The 10 POST requests were even more telling. They all came within a single second, using Go-http-client/1.1 as the User-Agent. No rotation, no pretense. This was the malware trying to upload stolen data, and the server bounced every request with a 405.
What Needs to Change
This attack exposed a fundamental flaw in how the threat intelligence ecosystem works. Here's what's broken:
EDRs and threat feeds flag domains based on behavioral correlation. Malware talks to domain X, therefore domain X is malicious. There's no ground-truth verification. Nobody checks whether the "C2 server" is actually serving C2 responses or just returning a static website.
Sandbox confirmation bias makes it worse. Once 2-3 vendors flag a domain, others treat those flags as corroborating evidence rather than independent data points. The flag count becomes self-reinforcing. "52 vendors detect the malware" somehow becomes "the C2 domain is definitely malicious," even though all 52 vendors are looking at the same sample and the same behavioral data.
The syndication is entirely one-way. A domain gets flagged globally in 48 hours. Getting unflagged takes months of manual vendor-by-vendor disputes. There's no "global retraction" mechanism, no standard for propagating false-positive corrections at the same speed as initial attribution.
The threat intelligence ecosystem has a global publish button but no global retract button. That's a design flaw, and it's being exploited.
This isn't hypothetical. It's happening right now to a platform that helps Iranian activists stay informed about threats to their safety. And there's nothing structurally preventing it from happening to any other legitimate domain.
Sandboxes should check whether a "C2 domain" actually responds like a C2. Does it serve different content based on the request? Does it have any kind of interactive handler? Or is it just returning the same index.html to every request? That distinction matters.
Threat intel feeds need false-positive propagation paths that are as fast as initial attribution. If a domain is incorrectly flagged, the correction should syndicate at the same speed as the original flag. Right now, flagging is automated and retraction is manual. That asymmetry is the vulnerability.
What We've Done
We migrated to mahsaalert.app and implemented hardening: beacon pattern blocking at the WAF level, rules to drop suspicious long-path requests, proper client IP forwarding through the proxy chain, and monitoring for new malware samples targeting the new domain.
We documented the attack in detail, not just for our own reference, but because this technique should be on the radar of every civil society platform, every security vendor, and every organization that relies on automated threat intelligence.
We're pursuing vendor delisting for mahsaalert.com in parallel, not because we plan to use it again, but because leaving it flagged validates the attack. And we're applying to Cloudflare's Project Galileo to establish formal civil-society protection for the new domain.
The old domain now serves a redirect page. It's a tombstone.
The Bigger Picture
Reputation poisoning isn't new as a concept, but using the threat intelligence ecosystem itself as the weapon is an evolution worth paying attention to. The attacker didn't need a zero-day. They didn't need network access. They didn't need to social-engineer anyone. They just needed to understand how automated threat classification works, and then feed it a real threat with a spoofed address.
For platforms serving at-risk communities, this is an existential threat vector. Your domain can be killed without your server ever being touched. The remediation timeline is measured in months. And the attacker can do it again to your next domain with the same amount of effort.
The fix isn't just technical. It's structural. The threat intelligence industry needs to build retraction mechanisms as robust as their detection mechanisms. Until that happens, domain reputation poisoning will remain one of the cheapest, most effective ways to silence a website.
IOCs
Primary Sample: eb56f800c2437a736be9deb2d8d5bbb0518396da642110664dba1df19250a67a (explorer.exe, 110.02 KB, PE64, UPX packed)
Related
Samples: e3f3af7b15db63a6c2ec4cb9a639947c75088d348f92c2a91a495ecbc71fbed7a806713485776243b7fdcbc88ed828415c3df240619d80d94ff276f550c303ec
Network:
C2 Domain: mahsaalert.com (victim, not attacker infrastructure) C2 IPs: 172.67.171.2, 104.21.79.191 (Cloudflare edges) POST User-Agent: Go-http-client/1.1
Host
Artifacts: %USERPROFILE%\\\\Desktop\\\\explorer.exe%APPDATA%\\\\svchost.exe%TEMP%\\\\firstact.exe%TEMP%\\\\oflove.exe
Registry: HKCU\\\\...\\\\Run\\\\SystemUpdateHelper
Beacon Detection:
GET /[A-Za-z0-9_-]{50,}\\\\s+HTTP
POST / HTTP/1\\\\.1.*Go-http-clientJA3
Fingerprints:
a0e9f5d64349fb13191bc781f81f42e198eaec8c8ef8baab245d0b65f788be913c4eb72b882d4d1442c67ce73f1292a9
VirusTotal: Behavior Report