Operation Epic Fury: independent OSINT analysis of a dual-platform campaign

Preamble: the second article that wasn't supposed to exist

Good morning. You're here — presumably — because you're looking for a technical write-up, threat intelligence analysis, maybe a deep-dive into Middle Eastern C2 infrastructure. And that's exactly what you'll find. The preamble is necessary not for my narrative gratification, but because context explains methodology, and methodology explains how we ended up with findings that a dozen of the world's most acclaimed vendors — Unit 42, CloudSEK, CrowdStrike, and friends — had missed. I'm asking you to tolerate three paragraphs of a person talking about themselves. It's worth it.

Those who know me, or had the persistence — and spare time — to unlock the bio via the CTF hidden somewhere on this site, know about my academic background in Political and Social Sciences. A discipline that prepares one admirably for forming authoritative opinions on geopolitical matters to which one has no direct access — which, on reflection, doesn't distinguish me much from the average Italian television commentator. The substantive difference is that in the meantime I learned to use nmap.

My intent, in all its innocent naivety, was as follows: analyze the known infrastructure, verify which services went down during the events of February 28, 2026, observe how the civilian population adapted to the stringent decisions that had reduced an entire nation's connectivity to 1-4% of normal. A light article. Six hours maximum. A couple of commands. A few screenshots. Done. (This is the moment when anyone who has worked in information security for more than six months stops believing me.)

# Murphy's Law — Formulation for Technical Environments
# Rev. 2026 — validity: always

if articolo == "veloce" and topic in ["geopolitica", "infosec", "entrambi"]:
    ore_stimate  = 6
    ore_reali    = ore_stimate * 2   # per session
    sessioni     = 2                 # because obviously
    esito        = "semplice"        # ASSERTION ERROR

# the rabbit hole always has one more floor below.
# the floor below hosts a C2 no vendor knows about.
# you did the right thing opening the terminal.

Twelve hours. Two days. The light article had transformed — through what my former professors would have described as eterogenesi dei fini (unintended consequences of intentional actions) — into an investigation with original findings: a second C2 server invisible to all vendors (0/94 on VirusTotal), a Windows payload that had evaded CrowdStrike Falcon for four years, an eight-month infrastructure timeline no report had reconstructed. Nothing I had planned. Everything I couldn't not publish.

The truth, for those who want it: when there are things to uncover on the network, it's more irresistible than honey to a bear. No editorial planning holds. No time-boxing works. There's only the open terminal, crt.sh, and the next question that makes you forget the previous one. Which, at the end of the day, is the only honest definition of research.

[01] The night of February 28

In the night between February 27 and 28, 2026, Iranian internet connectivity collapses. NetBlocks and BeyondTrust data show a drop to 1-4% of normal traffic — an almost total digital blackout. In the following hours, the Iranian Electronic Operations Room is activated, coordinating approximately 60 pro-Iranian hacktivist groups in response to the joint US-Israel military operation known as Operation Epic Fury / Operation Roaring Lion.

In the middle of the digital chaos, someone sent an SMS. Israeli civilians received a message with a link to download RedAlert — the legitimate Israeli rocket alert app developed by Elad Nava. The link pointed to a fake version. Those who installed it handed over SMS, contacts, and GPS location. It was the beginning of a smishing campaign documented in the following days by Unit 42, CloudSEK, and Cloudflare Cloudforce One with accurate and complete technical analyses of the Android component. The public reports focused on the APK. We looked elsewhere.

[02] What the vendors already knew

Credit to the public reports must be given without ambiguity. Unit 42 (March 4), CloudSEK (March 3), and Cloudflare Cloudforce One reconstructed the Android chain with precision. Which makes it all the more significant that nobody looked further.

The publicly documented Android chain: SMS smishing → download fake RedAlert (com.red.alertx) → APK installer with com.android.vending signature spoofing → stage 2 DEX loaded in memory (DebugProbesKt.dex) → collection of SMS/GPS/contacts → upload to api[.]ra-backup[.]com/analytics/submit.php. Backend: Cloudflare + AWS us-east-1. Initial distribution vector: shirideitch[.]com, an Israeli website from 2017 almost certainly unknowingly compromised — not attacker infrastructure.

This is already documented. What follows is not.

[03] Methodology

Setup: Kali Linux VM, proxychains+Tor for network queries, VirusTotal (free tier), FOFA, crt.sh, nmap, openssl. Starting point: Unit 42's public IOCs — IP 216.45.58[.]148 and domain api[.]ra-backup[.]com. Approach: systematic infrastructure pivot. I used only free, public tools. Anyone can verify what I found.

# Live check — 15 March 2026, 10:00 CET
$ proxychains curl -sk https://api.ra-backup.com/ -o /dev/null \
    -w "C2#1 HTTP: %{http_code} | Size: %{size_download}"
$ proxychains curl -sk https://167.160.187.43/ -o /dev/null \
    -w "C2#2 HTTP: %{http_code} | Size: %{size_download}"

C2#1 HTTP: 404 | Size: 315
C2#2 HTTPS (443): 404 | Size: 315

# 15 March 2026, 16 days after the operation. Both alive.

Finding #1 — The C2 wasn't born on February 28

First elementary question: when was the C2 registered? The answer is in Certificate Transparency logs — a public archive of all TLS certificates ever issued, searchable at crt.sh.

# Query CT logs
$ curl -s "https://crt.sh/?q=api.ra-backup.com&output=json" \
    | python3 -m json.tool | grep -E "not_before|common_name"

5 certificates total in 8 months — 4 automatic renewals — mean 5 documented moments someone kept the server alive. The first certificate is from June 23, 2025 — 8 months before the February 28 operation. The domain's SOA serial as Unix timestamp independently confirms the same date: 1750691767 → June 23, 2025 UTC. It wasn't responding to the attack. It was waiting.

Finding #2 — The second C2 nobody knows about

The JARM fingerprint is a TLS signature that identifies a server stack — version, cipher suite, order — uniquely enough to enable clustering of related infrastructure. I calculated the JARM of api[.]ra-backup[.]com and queried FOFA with that fingerprint to find other servers with the same configuration.

# JARM pivot on FOFA
# JARM: 21d14d00021d21d00042d43d00041dd0fae37a26d202d4ca73c3c7b57c5a55
$ fofa query: jarm="21d14d00021d21d00042d43d..."

# Result: 167.160.187.43
$ echo | /usr/bin/openssl s_client \
    -connect 167.160.187.43:443 \
    -servername 9732.5486311.xyz 2>/dev/null \
    | /usr/bin/openssl x509 -noout -issuer -subject -dates

issuer=C=US, O=Let's Encrypt, CN=R12
subject=CN=9732.5486311.xyz
notBefore=Mar  5 17:31:58 2026 GMT
notAfter=Jun  3 17:31:57 2026 GMT

The secondary C2's TLS certificate has notBefore on March 5, 2026 — 5 days after the operation. While the primary C2 was already in Unit 42 and CloudSEK reports, the operator was actively renewing the backup certificate. They weren't dismantling the infrastructure. They were maintaining it.

Finding #3 — Forensic proof: same operator

Two C2 servers. Same JARM, same Apache version, same PHP, same registrar, same hosting AS. But do they really belong to the same operation? There is more direct proof.

# MD5 body test — same moment, two C2s
$ proxychains curl -sk https://api.ra-backup.com/ | md5sum
$ proxychains curl -sk https://167.160.187.43/   | md5sum

# Session 14/03/2026:
cf33489d12cfb906849443c6181e84c2  -   (C2 #1)
cf33489d12cfb906849443c6181e84c2  -   (C2 #2)

# Session 15/03/2026 (confirmed):
6099d135f27f40de20a556e4c93613d9  -   (C2 #1)
6099d135f27f40de20a556e4c93613d9  -   (C2 #2)

The HTTP 404 body is dynamic — it changes between sessions, likely including a server-side timestamp. But it is always byte-identical across both C2 servers at the same time. This is not default Apache configuration. This is not coincidence. It is the same PHP code deployed by the same script by the same operator.

Finding #4 — Dual architecture

The campaign uses two infrastructures with radically different levels of operational care. The Android vector was protected by Cloudflare + AWS us-east-1 — scalable, anonymized, resilient. By March 15 the AWS backend (44.208.242[.]141, 44.200.176[.]254) was offline: takedown confirmed after Unit 42/CloudSEK reports. The Windows vector was directly exposed on a HostPapa in Virginia, no proxy, no protection. Different architectures reflect different investment levels: mobile was the primary vector. Windows was secondary — or in test phase at the time of the operation.

Finding #5 — LotAccess: not malware, a borrowed suit

What is LotAccessUI.EXE really? PE metadata, copyright strings, internal strings give a precise answer: it is the original enterprise VPN client of AppEx Networks Co., Ltd., a Chinese company (PE copyright 2006-2009), compiled on October 26, 2016, present on VirusTotal since 2017. Legitimate software. They didn't write malware from scratch. They took a 2016 Chinese enterprise VPN client, injected three capabilities — RDTSC anti-VM, custom mutex, registry C2 write — and delivered it to users. Elegant in its simplicity.

File "152" (download.js) is the original AppEx Networks update module, unmodified by the attackers. It connects to Akamai CDN — legitimate Microsoft/enterprise infrastructure. Its presence doesn't add malicious functionality: it adds cover. Network traffic generated by the binary is indistinguishable from that of a real enterprise VPN.

Three versions identified, all with the same PE resources: v1 (SHA256: 7d43d7f6..., first VT submission 2025-12-16, 4/65 detections) — v2 (uploaded 2026-03-08, 6/72) — v3 (SHA256: 6209a952..., 13/72). Active development for at least 10 weeks before the operation.

Finding #6 — The trojanization mechanism

The mechanism is confirmed by the VT Behavior tab. The malware writes C2 IPs to the Windows registry under the original AppEx Networks keys. The AppEx binary reads those keys, populates cloudvpn.cfg, and uses the value as %s in the API string /cgi-bin/d_device_action.py?SSLServer=%s. C2 traffic is legitimate AppEx VPN traffic on the wire.

# VT Behavior → Registry Keys Set (sandbox, 15/03/2026)
# Note: placeholder values in VM — see Finding #7 for the explanation

HKCU\Software\AppEx Networks\LotAccess\firstServer  = "123456 123456"
HKCU\Software\AppEx Networks\LotAccess\secondServer = "123456 123456"

# On physical hardware (expected):
# firstServer  = "216.45.58.148"
# secondServer = "167.160.187.43"

The 123456 123456 values in sandbox are not a bug — they are the third distinct proof of RDTSC anti-VM in action. The malware writes placeholders because the anti-VM check has already detected virtualization and blocked the real IP resolution phase. The mechanism works: the registry is written, the config is created, but with dummy data that will never lead to any C2.

Finding #7 — RDTSC and CrowdStrike's silence

The technique is the CPU instruction RDTSC (Read Time-Stamp Counter, T1497.003): the malware measures CPU cycles before and after an operation. In virtualized environments the count is anomalous — the hypervisor introduces detectable latencies. If the delta exceeds the threshold, the malware injects registry placeholders instead of real IPs and never contacts the C2. The C2 was not protected by proxies or anonymization: it was protected by anti-VM. The operator trusted that technique — and was right for four years.

Finding #8 — Second APK and Arid Viper convergence

Part A — umgdn / com.net.alerts (undisclosed)

A second Android APK exists in the same campaign, not documented in any public report. Package com.net.alerts, filename umgdn, size 11.45 MB — significantly larger than RedAlert. Tencent classifies it explicitly as A.privacy.SpyRedAlert. Compiled on June 24, 2025 — 24 hours after C2 registration (June 23, 2025). Infrastructure and payload were being built in parallel.

VT Behavior shows a POST to https://api.pushy.me/register with 200 OK response (2026-03-01 13:40:13 GMT). Pushy.me is a legitimate push notification service used as a resilient secondary C2 channel: it survives the takedown of the primary backend. Even after api[.]ra-backup[.]com went offline, the operator retains a push channel to all infected devices.

Part B — Arid Viper 2023 convergence

In the Arid Viper VT Graph (APT-C-23 / Desert Falcon, October 2023, 630 nodes) two elements identical to this campaign appear: redalert.me as a cover mechanism (same legitimate app used to show real alerts to victims) and api.pushy.me as a push channel. In 2023 Arid Viper used Firebase as push C2 (documented by SentinelOne — SpyC23 report). In 2026 the Epic Fury campaign uses Pushy.me. Same tactic, evolved technology. The attack template 'fake Israeli rocket alert app + push C2' predates Operation Epic Fury by at least two years.

[12] Reconstructed operational timeline

No public report has reconstructed this timeline in its entirety. The source is the aggregation of CT logs, VT timestamps, and FOFA.

Both C2 servers are still live as of the publication date of this article (March 17, 2026).

[13] Abuse reports

The following abuse reports were submitted on March 15, 2026 (~16:30 CET):

[14] Defender Takeaway — IOC, YARA, Sigma

IOC — Indicators of compromise

# IPs (defanged for publication)
216.45.58[.]148       # primary Windows C2 — HostPapa AS36352 Ashburn VA
167.160.187[.]43      # backup Windows C2 — RackNerd AS36352 Toronto CA — 0/94 VT

# Domains
api[.]ra-backup[.]com  # primary Android + Windows C2 (offline post-takedown)
9732[.]5486311[.]xyz   # backup Windows C2 — 0/94 VT

# SHA256
6209a9524e97ee8ac5fb05668f2be9a18a455870bb8cf6022049ee8f458c12d6  # LotAccessUI.EXE v3
7d43d7f6c743912b74273901494ed18451aa2824130d9d405da250a9fe3aad0d  # LotAccessUI.EXE v1
83651b0589665b112687f0858bfe2832ca317ba75e700c91ac34025ee6578b72  # RedAlert APK stage 1
0cba66e78ddaeecfdd462c8cb39e443d083dc58c609b0edc73e8101e59ca91e8  # umgdn APK stage 2 (undisclosed)

# LotAccess v3 forensic hashes
MD5:       58dad3a41691265128c751d133d5525f
Imphash:   d89625bf08b621847b3ab97338a84dda   # pivot PE family
JARM:      21d14d00021d21d00042d43d00041dd0fae37a26d202d4ca73c3c7b57c5a55

# Windows artifacts
Mutex:   tqvpn-gui-keep-one-instance                         # zero false positives
RegKey:  HKCU\Software\AppEx Networks\LotAccess\firstServer
RegKey:  HKCU\Software\AppEx Networks\LotAccess\secondServer
Path:    %TEMP%\EB93A6\cloudvpn.cfg
Path:    %TEMP%\EB93A6\ca.crt
Task:    Microsoft-Windows-DiskDiagnosticDataCollector        # if it points to %TEMP%

# Android packages
com.red.alertx   # RedAlert fake stage 1
com.net.alerts   # umgdn stage 2 (undisclosed)

YARA — Main rule

/*
    Rule: IranianAPT_LotAccess_EXE_2026
    Author: Paolo Costanzo - paolocostanzo.github.io
    TLP: WHITE | License: MIT
    Reference: paolocostanzo.github.io/operation-epic-fury-cyber-war-iran/
*/

rule IranianAPT_LotAccess_EXE_2026 {
    meta:
        description  = "LotAccess trojanized AppEx VPN — Operation Epic Fury 2026"
        author       = "Paolo Costanzo - paolocostanzo.github.io"
        date         = "2026-03-15"
        tlp          = "WHITE"
        hash_v3      = "6209a9524e97ee8ac5fb05668f2be9a18a455870bb8cf6022049ee8f458c12d6"
        mitre_attack = "T1071.001, T1497.003, T1053.005, T1036.007, T1112, T1059.007"
        confidence   = "HIGH"

    strings:
        $mutex      = "tqvpn-gui-keep-one-instance" ascii wide
        $c2_primary = "216.45.58.148"               ascii wide
        $c2_backup  = "167.160.187.43"               ascii wide
        $c2_host    = "api.ra-backup.com"            ascii wide
        $cfg        = "cloudvpn.cfg"                 ascii wide
        $appex_api  = "/cgi-bin/d_device_action.py?ButtonDownSSLFile" ascii wide

    condition:
        uint16(0) == 0x5A4D      // MZ header
        and filesize < 5MB
        and (
            $mutex
            or ($c2_primary and $cfg)
            or ($c2_backup  and $cfg)
            or ($appex_api  and ($c2_primary or $c2_backup))
        )
}

The mutex tqvpn-gui-keep-one-instance is the cleanest detection indicator — zero false positives, specific to the trojanized AppEx Networks binary.

Sigma — Detection rules

Full YARA rules (3), Sigma (6), and machine-readable IOCs available on GitHub: github.com/paolocostanzo/operation-epic-fury-rules — TLP:WHITE, MIT license.

MITRE ATT&CK

[15] Sources and references

Cited vendor reports

• Unit 42 / Palo Alto Networks — "Iranian APT Targets Israeli Civilians with Fake Rocket Alert App", 4 marzo 2026
• CloudSEK ThreatIntel — "RedAlert Trojan: Iranian APT Abusing Rocket Alert App to Target Israelis", 3 marzo 2026
• Cloudflare Cloudforce One — Threat Intelligence blog: Operation Epic Fury Android campaign, 4 marzo 2026
• ClearSky Cyber Security — Analisi APK RedAlert falso, marzo 2026
• Trellix Advanced Research Center — Tracking Iranian hacktivist operations, marzo 2026
• Sophos X-Ops — Threat activity update, marzo 2026
• NetBlocks — Iran internet connectivity data, 28 febbraio 2026 (netblocks.org)
• BeyondTrust — Infrastructure and threat advisory, febbraio–marzo 2026
• Hunt.io — Infrastructure correlation: AS36352 + NameCheap MuddyWater pattern
• SentinelOne SentinelLabs — "SpyC23: Android Surveillance Toolset" — Arid Viper / APT-C-23 TTP context

Verifiable technical data (direct links)

• crt.sh — Certificate Transparency: api.ra-backup.com — CT history from June 23, 2025 (SOA serial 1750691767)
• VirusTotal — LotAccessUI.EXE v3 — SHA256: 6209a952...8c12d6 — 13/72
• VirusTotal — LotAccessUI.EXE v1 — SHA256: 7d43d7f6...aad0d — first submission 2025-12-16 — 4/65
• VirusTotal — RedAlert fake APK — SHA256: 83651b05...78b72 — com.red.alertx
• VirusTotal — umgdn APK — SHA256: 0cba66e7...a91e8 — com.net.alerts (UNDISCLOSED as of 15/03/2026)
• GitHub — YARA rules, Sigma rules, IOC CSV — TLP:WHITE, MIT license — everything verifiable

Vendor report links above are verified at the official provider URL at time of publication (March 17, 2026). VirusTotal and crt.sh links are deterministic and permanent.