Security Weekly 16-20/6/25
Un po' di OSINT spinta, la nuova funzione Administrator Protection di Windows11, Tesla exploit e il solito FunFact
📬 Ben ritrovato caro cyber User con il nostro aggiornamento settimanale sul mondo cyber. Oggi partiamo subito con tre tool interessanti se ti occupi di OSINT e malware analysis.
🔹 PyRIT (Python Risk Identification Tool)
Repository: Azure/PyRIT
Categoria: Automazione Red Teaming / Threat Modeling
Cos'è
PyRIT (Python Risk Identification Tool) è uno strumento sviluppato da Microsoft/Azure per automatizzare la generazione di scenari di minaccia (Threat Scenarios) utilizzando un modello basato su Large Language Models (LLM). Il suo scopo è supportare il processo di Threat Modeling in contesti DevSecOps, generando automaticamente potenziali minacce in fase di design di un sistema.
A cosa serve
Automatizzare l'identificazione delle minacce durante lo sviluppo software.
Integrare threat modeling nei workflow CI/CD.
Fornire scenari di attacco realistici per i team di sicurezza e sviluppo.
Come si usa
Installazione
Richiede Python 3.9+:
git clone https://github.com/Azure/PyRIT
cd PyRIT
pip install -r requirements.txtConfigurazione
Crea un fileconfig.yamlspecificando i dettagli dell'applicazione e il provider LLM (OpenAI, Azure OpenAI, ecc.).Esempio:
app_name: MyApp
description: "Applicazione web che gestisce dati finanziari"
llm_provider: openai
openai_key: sk-...
model: gpt-4Esecuzione
Esegui PyRIT per generare gli scenari:
python main.py --config config.yamlOutput
Verranno generati file JSON e Markdown con i threat scenarios categorizzati secondo STRIDE (Spoofing, Tampering, etc.).
🔹 wtfis
Repository: pirxthepilot/wtfis
Categoria: OSINT / Domain & IP Intelligence
Cos'è
wtfis è un tool CLI scritto in Go che permette di raccogliere informazioni OSINT su domini o indirizzi IP, utilizzando fonti pubbliche gratuite come ipwhois.io, VirusTotal, Shodan, Host.io e altri.
A cosa serve
Raccogliere informazioni su asset sospetti (domini, IP).
Utilizzato per attività di reconnaissance, threat hunting e analisi incidenti.
Integra dati da più fonti in un output leggibile.
Come si usa
Installazione
È possibile installarlo viago install:
go install github.com/pirxthepilot/wtfis@latestOppure scaricare il binario dalla sezione Releases del repository.
Configurazione
Crea un file.envnella home directory:
WTFIS_VIRUSTOTAL_API_KEY=...
WTFIS_SHODAN_API_KEY=...
WTFIS_IPWHOIS_API_KEY=...Esempi d'uso
Informazioni su un dominio:
wtfis example.comInformazioni su un IP:
wtfis 8.8.8.8Modalità JSON:
wtfis example.com --jsonL'output include dettagli come ASN, paese, WHOIS, DNS records, Shodan services, VirusTotal score, ecc.
🔹 minusone
Repository: airbus-cert/minusone
Categoria: DFIR / Malware Analysis
Cos'è
minusone è uno strumento sviluppato da Airbus CERT per analizzare dump di memoria (minidump) di processi sospetti, con particolare attenzione alla detection di payload fileless e injection in-memory.
A cosa serve
Analizzare minidump (ad es. estratti da LSASS).
Rilevare payload iniettati o shellcode presenti in memoria.
Strumento utile per analisi forense post-compromissione.
Come si usa
Installazione
Richiede Python 3.10+:
git clone https://github.com/airbus-cert/minusone
cd minusone
pip install -r requirements.txtInput
È necessario un file minidump (.dmp) da analizzare. È possibile ottenerlo con strumenti comeprocdumpocomsvcs.dll.Esecuzione
python minusone.py -f lsass.dmpOutput
L’output mostra:Moduli legittimi e anomali caricati in memoria.
Blocchi sospetti (shellcode, reflective DLL, memory regions senza backing file).
Indicatori di compromissione.
Esempio di output:
[!] Suspicious memory region found at 0x7ff8a2000000
- Size: 0x20000
- No mapped file
- Entropy: 7.9Andiamo avanti con un articolo interessante che ci spiega la Administrator Protection introdotta con Windows 11.
🔐 Windows 11 “Administrator Protection”: cosa cambia davvero
Il blog di SpecterOps del 18 giugno 2025, a firma di Adam Chester, descrive con dovizia di dettagli la nuova funzionalità di Administrator Protection che Microsoft introdurrà su Windows 11, andando oltre la semplice UAC e offrendo uno sguardo pragmatico sulle implicazioni per offensive tooling e attori Red Team.
Cosa è “Administrator Protection”
Shadow Admin account: il sistema crea un account amministrativo separato, con prefisso
admin_, distinto dall’account utente originale. Il token elevato non è più un token filtrato, ma relativo a questo account shadow.Fine dei backdoor UAC: Microsoft elimina del tutto le auto-elevazioni di programmi e COM, inclusi exploit noti, per rendere più visibile ogni prompt di elevazione all’utente.
In pratica, ogni operazione che richiede privilegi elevati passa obbligatoriamente per l’account shadow, con conseguente aumento dei prompt. La scelta è consapevole e mira a una migliore separazione tra token utente e token amministrativo.
Questa scelta comporta un importante mutamento nel modello di minaccia (threat model). L’intero meccanismo si fonda su una separazione più netta e strutturale tra i privilegi utente e quelli amministrativi, rendendo più difficile l’escalation involontaria o implicita. Non è più possibile affidarsi alle classiche tecniche di token stealing, poiché l’utente non dispone più, nemmeno in forma latente, di un token amministrativo. Ogni accesso elevato è ora esplicito e tracciabile, anche grazie a un sistema di prompt più frequente ma ottimizzato, che privilegia la chiarezza rispetto alla silenziosa auto-elevazione vista in molte versioni precedenti di Windows.
Sul fronte della compatibilità, Microsoft sembra aver previsto una transizione graduale e ragionata. L’ambiente di esecuzione shadow conserva profili separati, documenti e persino chiavi di registro dedicati, mantenendo però un legame visibile e gestibile tramite l’attributo ShadowAccountBackLink presente nel SAM. Le applicazioni moderne dovrebbero comportarsi senza interruzioni, ma le implicazioni a livello di profilazione dell’utente e gestione del contesto d’esecuzione non sono trascurabili, soprattutto in ambienti aziendali complessi dove automazioni, script e privilegi vengono orchestrati su larga scala.
L’effetto sulle tecniche offensive è immediato: la gran parte delle vecchie strategie di bypass UAC basate su COM auto-elevanti, task scheduler o meccanismi di backdoor tramite binary hijacking risultano ora inefficaci. Chi tenta di accedere ai privilegi amministrativi attraverso il furto o l’iniezione di token si troverà davanti a un contesto svuotato di valore. Il token amministrativo non è semplicemente “filtrato”, non esiste proprio nello spazio utente fino a che non avviene una vera elevazione tramite l’account shadow.
Non mancano tuttavia margini di ricerca offensiva. Le interfacce tra il token shadow e il sistema principale, così come il flusso che gestisce la transizione tra i due contesti, rappresentano nuovi possibili vettori di attacco. Strumenti avanzati dovranno necessariamente adattarsi a questa nuova logica, esplorando eventuali vulnerabilità nei meccanismi di creazione e autenticazione dei token just-in-time, nei processi legati a Windows Hello o nelle interazioni di basso livello con il kernel.
Per i Blue Team, si apre invece una fase più favorevole in termini di visibilità. Ogni richiesta di elevazione è tracciata, il contesto shadow è più facile da isolare, e l’intero sistema produce una superficie d’analisi più strutturata, in cui ogni anomalia può essere indagata nel contesto giusto. Resta però il tema dell’operatività: la convivenza tra due contesti utente porta inevitabilmente a un aumento della complessità nei flussi quotidiani, e richiederà un aggiornamento di policy, strumenti e procedure interne.
In definitiva, Administrator Protection rappresenta un cambio di paradigma per la gestione dei privilegi su Windows. Non si tratta solo di un hardening superficiale, ma di una trasformazione profonda nel modo in cui l’identità amministrativa viene gestita. Se da un lato ciò complica la vita agli attori offensivi, dall’altro impone una revisione dei flussi di gestione e dei tool difensivi e di auditing. È una mossa che, se ben gestita, può contribuire significativamente alla riduzione della superficie di attacco – ma che chiede anche, da parte degli operatori di sicurezza, un impegno concreto nell’adeguarsi a un nuovo equilibrio.
🔌 Hacking del Tesla Wall Connector via protocollo sulla presa di carica
Synacktiv, durante la competizione Pwn2Own Automotive del gennaio 2025, ha rivelato una superficie di attacco sorprendente: è possibile sfruttare la presa di ricarica del Tesla Wall Connector per installare firmware malevoli. L’attacco ha origine dalla scoperta che il caricatore supporta l’aggiornamento firmware via il protocollo che viaggia sull’interfaccia di ricarica stessa, un comportamento non documentato e finora sconosciuto.
Il protocollo nascosto su CP/PP
In un caricatore domestico EV, i segnali Control Pilot (CP) e Proximity Pilot (PP) servono rispettivamente a negoziare il livello di corrente e verificare che il cavo sia presente. Laddove la maggior parte dei caricabatterie rimane passivo su questi segnali, Tesla introducendo un layer digitalizzato su CP quando rileva una vettura, utilizza inaspettatamente un CAN in singola linea (SW-CAN). È su questo canale che passa un protocollo proprietario, ignoto finora, capace di gestire query avanzate incluso l’aggiornamento firmware.
Reverse‐engineering e exploit
Synacktiv ha approcciato il problema estraendo il firmware del modulo AW-CU300 (Cortex-M4) e ricostruendo un parser Python:
import struct
data = open("WC3_...prodsigned.bin","rb").read()
# header e TLV parsing...
print("Good magic" if data.startswith(b"SBFH") else "Bad magic")Una volta isolato il segmento contenente il codice ARM, è emerso il fatto che non vi è alcun controllo di downgrade o firma firmware nel bootloader, lasciando quindi aperta la possibilità di flashare versioni vulnerabili.
Il team ha individuato una dropbear‑style TCP shell di debug attiva sulle versioni di firmware iniziali (~0.8.58), accessibile tramite comandi UDS. È stato dimostrato che portando il firmware a quella versione, si poteva recuperare SSID e PSK Wi‑Fi e accedere al caricatore via rete.
Simulatore di auto e infrastruttura d’attacco
Per pilotare il Wall Connector come se fosse una Tesla collegata, è stato costruito un piccolo simulator hardware. Una Raspberry Pi gestiva relè per imitare la negoziazione PP/CP, mentre un dongle USB‑CAN è stato modificato da CAN a SW‑CAN usando il transceiver NCV7356. Il tutto è stato confezionato in un box con la spina di carica integrata, con automazione Python basata su python-can e udsoncan.
Questa infrastruttura permetteva di dialogare in modalità UDS e attivare la procedura di downgrade e shell sulla rete AP Wi‑Fi generata dal caricatore.
Buffer overflow e RCE
Il cuore dell’exploit è un overflow nel dispatcher UDS, che sovrascriveva la tabella pointer‐to‐handler, permettendo l’esecuzione arbitraria. Non vi era alcuna protezione memoria (tutte le regioni RWX), quindi veniva richiamato direttamente lo shellcode in memoria. Il team ha descritto con precisione il layout della struttura dati e come manipolare il buffer per guadagnare esecuzione completamente arbitraria.
Implicazioni e contromisure
Questo attacco sottolinea quanto sia rischioso esporre firmware update via canali non autenticati. Tesla ha già rilasciato una “security ratchet” e disabilitato le funzionalità più vulnerabili, ma dispositivi non aggiornati sono esposti.
Per la difesa è fondamentale:
Monitorare il traffico SW‑CAN/CAN‑PLC sulla presa CP.
Bloccare aggiornamenti firmware su cattiva autenticazione o downgrade.
Scansionare e aggiornare in remoto i Wall Connector, soprattutto quelli con Wi‑Fi abilitato.
Synacktiv ha svelato un vero attacco “weaponizing the cable”: dalla presa di ricarica, spina nel fianco dell’IoT domestico EV. Un exploit che coniuga reverse‑engineering di firmware, costruzione hardware ad-hoc e logica di exploit avanzata in un unico flusso, dimostrando una falla di design critica. È una prova di quanto le superfici OT/IoT possano offrire nuovi vettori di compromissione e richiedere approcci difensivi su più livelli dai vendor.
😋FunFact: immagazzinare un’intera immagine dentro i record DNS!
Asher Falcon ha realizzato un esperimento che sembra uscito da Black Mirror: ha convertito un file JPEG in testo esadecimale, suddiviso in blocchi da 2 048 caratteri e salvato ciascun blocco in record DNS TXT (dnsimg-1.domain, dnsimg-2.domain, etc.). Tramite dig e uno script Python ha ricostruito i record, concatenato i blocchi e ricreando l’immagine originale—un proof‑of‑concept che funziona davvero. Lo script mostra come interrogare dnsimg-count.domain, capire quanti blocchi scaricare, e poi ricostituire l’immagine tramite bytes.fromhex(...).
La curiosità è esplosa su Reddit e X/Twitter, con commenti come:
“hosting payloads inside TXT records … è una TTP nota”
e l’esperimento è stato accolto con sincero stupore nella community r/netsec.(reddit.com).
👉 Ma meglio dare un’occhiata alla pagina del progetto, con codice completo e visual demo:
https://asherfalcon.com/blog/posts/2.
Anche quest'oggi abbiamo concluso, ti ringrazio per il tempo e l'attenzione che mi hai dedicato, augurandoti buon fine settimana, ti rimando al mio blog e alla prossima settimana per un nuovo appuntamento con NINAsec.
Il network
Con questo piccolo schema riepilogo in breve i punti di riferimento che alimento con i miei contenuti, su diversi fronti, quasi quotidianamente.
Ransomfeed.it - piattaforma di monitoraggio ransomware, realtime;
inSicurezzaDigitale.com - blog di sicurezza informatica con approfondimenti tematici;
SecureBulletin.com - news internazionali su cyber security, analisi e frodi;
Spcnet.it - notizie geek;
ilGlobale.it - note politiche e di economia, di rilevanza internazionale;
Ziobudda.org - notizie Linux, open source e software libero, segnalabili e commentabili (socialnews).
NewsDF - il raccoglitore di tutto questo, con un suo feed RSS generale, per non perdere niente di quello che pubblico.