Cosa sapevano tutti: campagna iraniana, fake RedAlert APK, smishing contro civili israeliani post-28 febbraio 2026. Documentato da Unit 42, CloudSEK, Cloudflare Cloudforce One entro 5 giorni.
Quello che nessuno aveva trovato:
- Payload Windows inedito: LotAccessUI.EXE, client VPN cinese del 2016 trojanizzato. CrowdStrike Falcon: CLEAN. 59/72 vendor VirusTotal: silenzio.
- Secondo C2 con 0/94 VT: 167.160.187[.]43 / 9732.5486311[.]xyz — nessun sistema di reputazione lo conosce. Nessun report ne parla.
- Infrastruttura attiva da giugno 2025 — 8 mesi prima dell'operazione. Non è una risposta improvvisata.
- Entrambi i C2 Windows ancora live al 15 marzo 2026 (16 giorni dopo l'operazione), nonostante i report pubblici.
- Secondo APK Android (com.net.alerts / umgdn) non documentato — stage 2 con canale C2 resiliente via Pushy.me.
- Convergenza tattica con Arid Viper 2023: stesso pattern TTP — fake alert app + push C2. Documentato qui per la prima volta.
Perché nessun sandbox lo aveva visto: RDTSC anti-VM (T1497.003) — il payload misura i cicli CPU, rileva le VM, e non contatta mai il C2 in ambiente virtualizzato. Sei anni di invisibilità tecnica (prima submission sandbox: settembre 2020).
Strumenti: VirusTotal (free tier), FOFA, crt.sh, nmap, openssl. Nessun accesso privilegiato. Tutto riproducibile.
Premessa: il secondo articolo che non sarebbe dovuto essere
Quello che segue è un'analisi tecnica di infrastruttura malware su fonti pubblicamente disponibili. Il contesto geopolitico è citato esclusivamente come cornice temporale — per stabilire il quando, non il chi ha ragione. L'autore non si schiera. Se sei venuto qui per la propaganda, troverai soltanto curl, nmap e crt.sh. Il che, in effetti, è infinitamente più interessante.
Buongiorno Signori. Vi trovate qui — presumibilmente — perché cercate un write-up tecnico, qualche analisi di threat intelligence, forse un deep-dive su infrastrutture C2 di matrice mediorientale. Ed è esattamente quello che trovate. La premessa è necessaria non per mio diletto narrativo, ma perché il contesto spiega la metodologia, e la metodologia spiega come si sia arrivati a finding che una dozzina di vendor tra i più blasonati del pianeta — Unit 42, CloudSEK, CrowdStrike, e amici — non avevano trovato. Vi chiedo di tollerare tre paragrafi di persona che parla di sé. Ne vale la pena.
Chi mi conosce, o ha avuto la sufficiente pertinacia — e il tempo libero — da sbloccare la bio tramite il CTF nascosto da qualche parte su questo sito, è al corrente del mio trascorso accademico in Scienze Politiche e Sociali. Una disciplina che prepara ottimamente alla costruzione di opinioni autorevoli su questioni geopolitiche alle quali non si ha accesso diretto — il che, a ben vedere, non mi distingue granché dalla media dei commentatori televisivi italiani. La differenza sostanziale è che nel frattempo ho imparato a usare nmap.
Il mio intento, in tutta la sua innocente velleità, era il seguente: analizzare l'infrastruttura nota, verificare quali servizi fossero andati down durante gli eventi del 28 febbraio 2026, osservare come la popolazione civile si fosse adeguata alle stringenti — eufemismo di servizio — decisioni che avevano ridotto la connettività di una nazione intera all'1-4% del normale. Un articolo agile. Sei ore al massimo. Un paio di comandi. Qualche screenshot. Fine. (Questo è il momento in cui chi lavora in sicurezza informatica da più di sei mesi smette di credermi.)
# Legge di Murphy — Formulazione per Ambienti Tecnici # Rev. 2026 — validità: sempre if articolo == "veloce" and topic in ["geopolitica", "infosec", "entrambi"]: ore_stimate = 6 ore_reali = ore_stimate * 2 # per sessione sessioni = 2 # perché ovviamente esito = "semplice" # ASSERTION ERROR # il rabbit hole ha sempre un piano di sotto. # il piano di sotto ospita un C2 che nessun vendor conosce. # hai fatto bene ad aprire il terminale.
Dodici ore. Due giorni. L'articolo leggero si era trasformato — per eterogenesi dei fini, come avrebbero commentato i miei ex professori con quella soddisfazione di chi usa il latino per descrivere situazioni che si potrebbero spiegare in tre parole — in un'indagine con finding inediti: un secondo server C2 invisibile a tutti i vendor (0/94 su VirusTotal), un payload Windows che eludeva sandbox e antivirus dal 2020 senza che nessuno lo sapesse, una timeline infrastrutturale di otto mesi che nessun report aveva ricostruito. Niente di quello che avevo pianificato. Tutto quello che non potevo non pubblicare.
La verità, per chi la vuole: quando di mezzo ci sono informazioni da scovare sulla rete, è più irresistibile del miele per un orso. Non c'è pianificazione editoriale che regga. Non c'è time-boxing che funzioni. C'è solo il terminale aperto, crt.sh, e la domanda successiva che ti fa dimenticare quella precedente. Il che, in fondo, è l'unica definizione onesta di ricerca.
[01] La notte del 28 febbraio
Nella notte tra il 27 e il 28 febbraio 2026, la connettività internet iraniana collassa. I dati NetBlocks e BeyondTrust mostrano un calo all'1-4% del traffico normale — un blackout digitale quasi totale. Nelle ore successive, la Electronic Operations Room iraniana viene attivata, coordinando circa 60 gruppi hacktivisti filo-iraniani in risposta all'operazione militare congiunta USA-Israele denominata Operation Epic Fury / Operation Roaring Lion.
Nel mezzo del caos digitale, qualcuno ha mandato un SMS. Ai civili israeliani arriva un messaggio con un link per scaricare RedAlert — l'app israeliana legittima di allerta razzi sviluppata da Elad Nava. Il link punta a una versione fake. Chi la installa consegna SMS, rubrica e posizione GPS. È l'inizio di una campagna smishing documentata nei giorni successivi da Unit 42, CloudSEK e Cloudflare Cloudforce One con analisi tecniche accurate e complete sulla parte Android. I report pubblici si sono concentrati sull'APK. Noi abbiamo guardato altrove.
[02] Cosa sapevano già i vendor
Il merito dei report pubblici va riconosciuto senza ambiguità. Unit 42 (4 marzo), CloudSEK (3 marzo) e Cloudflare Cloudforce One hanno ricostruito la catena Android con precisione. Il che rende ancora più significativo il fatto che nessuno abbia guardato oltre.
La catena Android documentata pubblicamente: SMS smishing → download fake RedAlert (com.red.alertx) → installer APK con signature spoofing com.android.vending → stage 2 DEX caricato in memoria (DebugProbesKt.dex) → raccolta SMS/GPS/contatti → upload a api[.]ra-backup[.]com/analytics/submit.php. Backend: Cloudflare + AWS us-east-1. Vettore di distribuzione iniziale: shirideitch[.]com, sito israeliano del 2017 quasi certamente compromesso inconsapevolmente — non infrastruttura attacker.
| Fonte | Data | Android | Windows | C2 sec. |
|---|---|---|---|---|
| CloudSEK | 03/03 | ✓ | ✗ | ✗ |
| Unit 42 | 04/03 | ✓ | ✗ | ✗ |
| Cloudflare CF1 | 04/03 | ✓ | ✗ | ✗ |
| ClearSky / Trellix / Sophos | Mar 2026 | ✓ | ✗ | ✗ |
| Questa ricerca | 17/03 | ✓ | ✓ | ✓ |
Questo è già documentato. Quello che segue non lo è.
[03] Metodologia
Setup: Kali Linux in VM, proxychains+Tor per le query di rete, VirusTotal (piano gratuito), FOFA, crt.sh, nmap, openssl. Punto di partenza: gli IOC pubblici di Unit 42 — l'IP 216.45.58[.]148 e il dominio api[.]ra-backup[.]com. Approccio: pivot sistematico sull'infrastruttura. Ho usato solo strumenti pubblici e gratuiti. Chiunque può verificare quello che ho trovato.
# Verifica live — 15 marzo 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 marzo 2026, 16 giorni dopo l'operazione. Entrambi vivi.
Finding #1 — Il C2 non è nato il 28 febbraio
Prima domanda elementare: quando è stato registrato il C2? La risposta è nei Certificate Transparency logs — archivio pubblico di tutti i certificati TLS emessi, consultabile su 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"
| Data emissione | Evento | Significato |
|---|---|---|
| 2025-06-23 | 1° cert Let's Encrypt | Server vivo dal primo giorno |
| 2025-08-23 | Rinnovo #1 | Vivo dopo 2 mesi |
| 2025-10-22 | Rinnovo #2 | Vivo dopo 4 mesi |
| 2025-12-22 | Rinnovo #3 | Vivo dopo 6 mesi |
| 2026-02-20 | Rinnovo finale | −8 giorni pre-operazione |
5 rinnovi automatici significano 5 volte in cui qualcuno ha tenuto vivo il server. Il primo certificato è del 23 giugno 2025 — 8 mesi prima dell'operazione del 28 febbraio. Il SOA serial del dominio come Unix timestamp conferma la stessa data indipendentemente: 1750691767 → 23 giugno 2025 UTC. Non stava rispondendo all'attacco. Stava aspettando.
Finding #2 — Il secondo C2 che nessuno sa
Il JARM fingerprint è una firma TLS che identifica uno stack server — versione, cipher suite, ordine — in modo sufficientemente univoco da permettere il clustering di infrastrutture correlate. Ho calcolato il JARM di api[.]ra-backup[.]com e ho interrogato FOFA con quel fingerprint per trovare altri server con la stessa configurazione.
# JARM pivot su FOFA # JARM: 21d14d00021d21d00042d43d00041dd0fae37a26d202d4ca73c3c7b57c5a55 $ fofa query: jarm="21d14d00021d21d00042d43d..." # Risultato: 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
167.160.187[.]43 / 9732.5486311[.]xyz: zero rilevamenti VT, zero pulse OTX, zero segnalazioni AbuseIPDB. Un server C2 di backup completamente sconosciuto a tutti i sistemi di reputazione IP. L'ultima analisi VT: luglio 2025 — otto mesi prima. Nessuno lo stava guardando. Nessun report ne parla.
Il certificato TLS del C2 secondario ha notBefore il 5 marzo 2026 — 5 giorni dopo l'operazione. Mentre il C2 primario era già nei report di Unit 42 e CloudSEK, l'operatore stava rinnovando attivamente il certificato del backup. Non stavano smantellando l'infrastruttura. La stavano mantenendo.
Finding #3 — Prova forense: stesso operatore
Due C2. Stesso JARM, stessa versione Apache, stesso PHP, stesso registrar, stesso hosting AS. Ma sono davvero della stessa operazione? Esiste una prova più diretta.
# Test MD5 body — stesso momento, due C2 $ proxychains curl -sk https://api.ra-backup.com/ | md5sum $ proxychains curl -sk https://167.160.187.43/ | md5sum # Sessione 14/03/2026: cf33489d12cfb906849443c6181e84c2 - (C2 #1) cf33489d12cfb906849443c6181e84c2 - (C2 #2) # Sessione 15/03/2026 (confermato): 6099d135f27f40de20a556e4c93613d9 - (C2 #1) 6099d135f27f40de20a556e4c93613d9 - (C2 #2)
Il body HTTP 404 è dinamico — cambia tra sessioni, probabilmente include un timestamp server-side. Ma è sempre identico al byte tra i due C2 nello stesso momento. Non è configurazione Apache di default. Non è coincidenza. È lo stesso codice PHP deployato dallo stesso script dallo stesso operatore.
| Caratteristica | C2 #1 (216.45.58[.]148) | C2 #2 (167.160.187[.]43) |
|---|---|---|
| Apache | 2.4.52 (Ubuntu) | 2.4.52 (Ubuntu) |
| PHP | 8.2.8 | 8.2.8 |
| JARM | identico | |
| Content-Length 404 | 315 B | 315 B |
| Registrar | NameCheap | NameCheap |
| Privacy | Withheld for Privacy ehf | Withheld for Privacy ehf |
| Hosting AS | AS36352 HostPapa — Ashburn VA | AS36352 RackNerd — Toronto CA |
| CORS header | Access-Control-Allow-Origin: * | |
| TLS notBefore | 2026-02-20 (−8 gg) | 2026-03-05 (+5 gg) |
Finding #4 — Architettura duale
La campagna usa due infrastrutture con livelli di cura operativa radicalmente diversi. Il vettore Android era protetto da Cloudflare + AWS us-east-1 — scalabile, anonimizzato, resiliente. Al 15 marzo il backend AWS (44.208.242[.]141, 44.200.176[.]254) risulta offline: takedown confermato post-report Unit 42/CloudSEK. Il vettore Windows era esposto direttamente — C2 primario su HostPapa Ashburn, Virginia (AS36352), C2 secondario su RackNerd Toronto, Canada (stesso AS36352/ColocCrossing) — nessun proxy, nessuna protezione. Architetture diverse riflettono livelli di investimento diversi: il mobile era il vettore primario. Il Windows era secondario — o in fase di test al momento dell'operazione.
Finding #5 — LotAccess: non un malware, un abito preso in prestito
Cos'è davvero LotAccessUI.EXE? PE metadata, copyright, stringhe interne danno una risposta precisa: è il client VPN enterprise originale di AppEx Networks Co., Ltd., azienda cinese attiva tra il 2006 e il 2009, compilato il 26 ottobre 2016, presente su VirusTotal dal 2017. Software legittimo. Non hanno scritto malware da zero. Hanno preso un client VPN enterprise cinese del 2016, ci hanno iniettato tre funzionalità — anti-VM RDTSC, mutex custom, scrittura registry per il C2 — e lo hanno consegnato agli utenti. Elegante nella sua semplicità.
| Livello | File | Dim. | Funzione |
|---|---|---|---|
| 1 | LotAccessUI.EXE | 1.19 MB | Loader PE — estrae risorse, contatta C2 |
| 2 | cloudvpn.cfg | 190 B | Config INI — IP del C2 scritto a runtime |
| 3 | file "152" (download.js) | 113 KB | Modulo aggiornamento AppEx originale — legittimo |
| CA | ca.crt | ~1.4 KB | CA cinese TianQin_VPNCA_Center |
Il file "152" (download.js) è il modulo di aggiornamento AppEx Networks originale, non modificato dagli attaccanti. Si connette ad Akamai CDN — infrastruttura Microsoft/enterprise legittima. La sua presenza non aggiunge funzionalità malevole: aggiunge copertura. Il traffico di rete generato dal binario è indistinguibile da quello di una VPN enterprise reale.
Tre versioni identificate, tutte con le stesse PE resources: v1 (SHA256: 7d43d7f6..., prima submission VT 2025-12-16, 4/65 detection) — v2 (caricato 2026-03-08, 6/72) — v3 (SHA256: 6209a952..., 13/72). Sviluppo attivo per almeno 10 settimane prima dell'operazione.
Finding #6 — Il meccanismo di trojanizzazione
Il meccanismo è confermato dal tab VT Behavior. Il malware scrive gli IP del C2 nel registry Windows sotto le chiavi originali AppEx Networks. Il binary AppEx legge quelle chiavi, popola cloudvpn.cfg, e usa il valore come %s nell'API string /cgi-bin/d_device_action.py?SSLServer=%s. Il traffico C2 è traffico VPN AppEx legittimo sul wire.
# VT Behavior → Registry Keys Set (sandbox, 15/03/2026) # Nota: valori placeholder in VM — vedi Finding #7 per spiegazione HKCU\Software\AppEx Networks\LotAccess\firstServer = "123456 123456" HKCU\Software\AppEx Networks\LotAccess\secondServer = "123456 123456" # Su hardware fisico (atteso): # firstServer = "216.45.58.148" # secondServer = "167.160.187.43"
I valori 123456 123456 in sandbox non sono un bug — sono la terza prova distinta dell'anti-VM RDTSC in azione. Il malware scrive i placeholder perché il check anti-VM ha già rilevato la virtualizzazione e bloccato la fase di risoluzione degli IP reali. Il meccanismo funziona: il registry viene scritto, il config viene creato, ma con dati fasulli che non porteranno mai a nessun C2.
Finding #7 — RDTSC e il silenzio di CrowdStrike
CrowdStrike Falcon (2022): CLEAN. 59/72 vendor VirusTotal: silenzio. Hybrid Analysis (febbraio 2022): Network Analysis = zero attività, zero DNS, zero connessioni. Threat Score: 92/100 — ma solo su euristiche comportamentali, mai il C2. Dal 2020 a oggi, nessun sandbox pubblico ha mai catturato una connessione C2 di LotAccess. Mai.
La tecnica è l'istruzione CPU RDTSC (Read Time-Stamp Counter, T1497.003): il malware misura i cicli CPU prima e dopo un'operazione. In ambienti virtualizzati il conteggio è anomalo — l'hypervisor introduce latenze rilevabili. Se il delta supera la soglia, il malware inietta placeholder nel registry invece degli IP reali e non contatta il C2. Il C2 non era protetto da proxy o anonimizzazione: era protetto dall'anti-VM. L'operatore si fidava di quella tecnica — e aveva ragione per quattro anni.
Finding #8 — Secondo APK e convergenza Arid Viper
Parte A — umgdn / com.net.alerts (inedito)
Esiste un secondo APK Android nella stessa campagna, non documentato in nessun report pubblico. Package com.net.alerts, nome file umgdn, dimensione 11.45 MB — notevolmente più grande di RedAlert. Tencent lo classifica esplicitamente come A.privacy.SpyRedAlert. Compilato il 24 giugno 2025 — 24 ore dopo la registrazione del C2 (23 giugno 2025). L'infrastruttura e il payload venivano costruiti in parallelo.
Il VT Behavior mostra una POST a https://api.pushy.me/register con risposta 200 OK (01/03/2026 13:40:13 GMT). Pushy.me è un servizio legittimo di push notification usato come canale C2 secondario resiliente: sopravvive al takedown del backend principale. Anche dopo che api[.]ra-backup[.]com è andato offline, l'operatore mantiene un canale di push verso tutti i dispositivi infetti.
Parte B — Convergenza Arid Viper 2023
Nel VT Graph di Arid Viper (APT-C-23 / Desert Falcon, ottobre 2023, 630 nodi) si trovano due elementi identici a questa campagna: redalert.me come meccanismo di copertura (stessa app legittima usata per mostrare alert reali alle vittime) e api.pushy.me come canale push. Nel 2023 Arid Viper usava Firebase come C2 push (documentato da SentinelOne — SpyC23 report). Nel 2026 la campagna Epic Fury usa Pushy.me. Stessa tattica, tecnologia evoluta. Il template di attacco "fake app allerta razzi israeliana + push C2" precede l'Operation Epic Fury di almeno due anni.
La convergenza tattica è documentata e reale. Non implica necessariamente stessa autorialità o coordinazione diretta: o c'è condivisione di know-how tra gruppi, o la tattica è talmente efficace che più attori l'hanno sviluppata indipendentemente. La correlazione infrastrutturale con MuddyWater/MOIS è documentata da Hunt.io (pattern AS36352 + NameCheap). L'attribuzione definitiva richiede evidenza ulteriore.
[12] Timeline operativa ricostruita
Nessun report pubblico ha ricostruito questa timeline nella sua completezza. La fonte è l'aggregazione di CT logs, VT timestamps e FOFA.
| Data | Evento |
|---|---|
| 2016-10-26 | LotAccessUI.EXE compilato da AppEx Networks — software VPN legittimo |
| 2025-06-23 | Registrazione api[.]ra-backup[.]com + 1° cert Let's Encrypt emesso stesso giorno |
| 2025-06-24 | Compilazione umgdn/com.net.alerts — 24h dopo il C2 |
| 2025-07-08 | Registrazione 9732[.]5486311[.]xyz — C2 secondario |
| 2025-08-23 / 2025-10-22 / 2025-12-22 | Rinnovi automatici cert C2#1 (×3) |
| 2025-11 / 2025-12 | Payload .exe in test — 3 mesi pre-op |
| 2025-12-16 | LotAccess v1 su VT — 10 settimane pre-op |
| 2026-02-20 | Rinnovo finale cert C2#1 — −8 giorni |
| 2026-02-28 | OPERATION EPIC FURY — distribuzione APK via smishing |
| 2026-03-03/04 | CloudSEK + Unit 42 — report APK Android |
| 2026-03-05 | Cert C2#2 rinnovato — +5 giorni post-op |
| 2026-03-08 | Backend AWS offline. LotAccess v2+v3 su VT. |
| 2026-03-15 | Live test: entrambi i C2 Windows ancora attivi — 16 giorni post-op |
Entrambi i C2 sono ancora live alla data di pubblicazione di questo articolo (17 marzo 2026).
[13] Segnalazioni abuse
Le seguenti segnalazioni abuse sono state inviate il 15 marzo 2026 (~16:30 CET):
| Destinatario | Oggetto | Status |
|---|---|---|
| AbuseIPDB | AbuseIPDB — entrambi gli IP | Inviato 15/03 |
| HostPapa | net-abuse-global@hostpapa.com | Inviato 15/03 |
| Namecheap | Form abuse — entrambi i domini | Inviato 15/03 |
[14] Defender Takeaway — IOC, YARA, Sigma
IOC — Indicatori di compromissione
# IPs (defangati per pubblicazione) 216.45.58[.]148 # C2 Windows primario — HostPapa AS36352 Ashburn VA 167.160.187[.]43 # C2 Windows backup — RackNerd AS36352 Toronto CA — 0/94 VT # Domains api[.]ra-backup[.]com # C2 Android + Windows primario (offline post-takedown) 9732[.]5486311[.]xyz # C2 Windows backup — 0/94 VT # SHA256 6209a9524e97ee8ac5fb05668f2be9a18a455870bb8cf6022049ee8f458c12d6 # LotAccessUI.EXE v3 7d43d7f6c743912b74273901494ed18451aa2824130d9d405da250a9fe3aad0d # LotAccessUI.EXE v1 83651b0589665b112687f0858bfe2832ca317ba75e700c91ac34025ee6578b72 # RedAlert APK stage 1 0cba66e78ddaeecfdd462c8cb39e443d083dc58c609b0edc73e8101e59ca91e8 # umgdn APK stage 2 (inedito) # Hash forensi LotAccess v3 MD5: 58dad3a41691265128c751d133d5525f Imphash: d89625bf08b621847b3ab97338a84dda # pivot PE family JARM: 21d14d00021d21d00042d43d00041dd0fae37a26d202d4ca73c3c7b57c5a55 # Windows artifacts Mutex: tqvpn-gui-keep-one-instance # zero falsi positivi 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 # se punta a %TEMP% # Android packages com.red.alertx # RedAlert fake stage 1 com.net.alerts # umgdn stage 2 (inedito)
YARA — Regola principale
/* 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)) ) }
Il mutex tqvpn-gui-keep-one-instance è il detection indicator più pulito — zero falsi positivi, specifico al binary AppEx Networks trojanizzato.
Sigma — Regole di detection
| Regola | Livello | Categoria | Note |
|---|---|---|---|
iranian_apt_lotaccess_c2_network | CRITICAL | network_connection | Solo HW fisico |
iranian_apt_lotaccess_payload_extraction | HIGH | file_event | Prima indicazione |
iranian_apt_lotaccess_registry_c2 | HIGH | registry_set | Valori reali su HW fisico |
iranian_apt_lotaccess_scheduled_task | HIGH | process_creation | Leggere filtro FP |
iranian_apt_lotaccess_wscript_child | MEDIUM | process_creation | Sperimentale |
iranian_apt_redalert_android_c2 | CRITICAL | proxy | Zero FP attesi |
Regole YARA complete (3), Sigma (6) e IOC machine-readable disponibili su GitHub: github.com/paolocostanzo/operation-epic-fury-rules — TLP:WHITE, MIT license.
MITRE ATT&CK
| Tecnica | Tattica | Descrizione |
|---|---|---|
| T1497.003 | Defense Evasion | RDTSC — evasione sandbox |
| T1071.001 | Command & Control | AppEx VPN API come C2 |
| T1112 | Defense Evasion | Registry modification |
| T1053.005 | Persistence | Scheduled Task masquerade |
| T1036.007 | Defense Evasion | Masquerade task name |
| T1059.007 | Execution | JS via WScript.exe (AppEx update module) |
| T1583.001 | Resource Development | Infrastruttura 8 mesi pre-op |
[15] Fonti e riferimenti
Report vendor citati
- 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
Dati tecnici verificabili
- crt.sh — Certificate Transparency: api.ra-backup.com — storico CT dal 23 giugno 2025 (SOA serial 1750691767)
-
VirusTotal — LotAccessUI.EXE v3
— SHA256:
6209a952...8c12d6— 13/72 -
VirusTotal — LotAccessUI.EXE v1
— SHA256:
7d43d7f6...aad0d— prima 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 al 15/03/2026) - GitHub — YARA rules, Sigma rules, IOC CSV — TLP:WHITE, MIT license — tutto verificabile
I link ai report vendor sopra indicati sono verificati all'URL ufficiale dei rispettivi provider al momento della pubblicazione (17 marzo 2026). I link VirusTotal e crt.sh sono deterministici e permanenti.