Estensioni Malevole: Software Extensions (T1176)

Nella simulazione red team di T1176, l'obiettivo è dimostrare come un'estensione apparentemente innocua possa fornire persistenza browser-side e canali di esfiltrazione difficili da rilevare. Il target primario resta Chromium/Edge/Firefox, seguito da IDE come Visual Studio Code che espone un'API di estensioni potente e poco monitorata.

Per un lab controllato su Chrome, la struttura minima di un'estensione persistente richiede un manifest.json con permission elevate ("permissions": ["tabs", "cookies", "storage", "<all_urls>"]) e un service worker (Manifest V3) che gestisce eventi in background. Il caricamento in modalità sviluppatore avviene navigando a chrome://extensions/, abilitando Developer mode e usando Load unpacked. Per il deployment enterprise-simulato si sfruttano le policy di gruppo:

reg add "HKLM\Software\Policies\Google\Chrome\ExtensionInstallForcelist" /v 1 /t REG_SZ /d ";" /f

Questa chiave forza l'installazione silente al prossimo avvio del browser, senza notifica utente. Su macOS l'equivalente passa per configuration profile plist distribuiti via MDM.

Per VS Code, un'estensione malevola può essere packagizzata con vsce (open source, npm install -g @vscode/vsce) e installata via code --install-extension pacchetto.vsix. L'API vscode.workspace consente accesso a tutti i file aperti, mentre child_process in un contesto Node.js permette esecuzione arbitraria — un vettore di supply chain particolarmente rilevante dato che sviluppatori spesso operano con accesso a repository sensibili e chiavi cloud.

Per la ricerca offensiva su estensioni Chrome esistenti, strumenti come CRXcavator (gratuito, servizio web) e Chrome-Extension-Downloader (open source) permettono di estrarre e analizzare pacchetti CRX per identificare permission eccessive o pattern sospetti in codice legittimo che potrebbe essere abusato.

Catene d'attacco tipiche in un engagement:

• Fase 1: consegna via phishing con link a un finto marketplace o typosquat di un'estensione popolare
• Fase 2: installazione tramite social engineering ("abilita la modalità sviluppatore per usare questo tool") oppure, se si ha già accesso admin, via GPO/registry
• Fase 3: il service worker stabilisce connessioni verso C2 usando fetch() — traffico che appare originare dal browser legittimo e attraversa proxy aziendali senza attriti
• Fase 4: esfiltrazione di cookie di sessione (chrome.cookies.getAll) per session hijacking di applicazioni SaaS

Per lab isolati, BeEF (open source) offre moduli utili per comprendere il modello di attacco browser-based, mentre estensioni di ricerca come quelle documentate nei repository accademici mostrano tecniche di offuscamento e attivazione ritardata utili per esercitazioni di detection engineering.

La detection di T1176 ruota attorno a tre pilastri: l'installazione dell'estensione, il comportamento anomalo del processo host e il traffico di rete anomalo che ne deriva. L'analitica DET0092 di MITRE fornisce tre viste sistema-specifiche che vale la pena tradurre in regole operative.

Su Windows (analitica AN0251), le fonti primarie sono WinEventLog:Security e Sysmon. Le chiavi di registro da monitorare per Chrome sono sotto HKCU\Software\Google\Chrome\PreferenceMACs e HKLM\Software\Policies\Google\Chrome\ExtensionInstallForcelist; per Edge il path parallelo è HKLM\Software\Policies\Microsoft\Edge\ExtensionInstallForcelist. Un alert ad alta priorità dovrebbe scattare quando Sysmon EventID 13 (Registry value set) modifica queste chiavi al di fuori di finestre di deployment autorizzate. Per VS Code, il file %USERPROFILE%\.vscode\extensions\extensions.json cambia a ogni installazione — monitorarlo via Sysmon EventID 11 (FileCreate) permette di correlare install spontanei con attività utente.

Un secondo layer riguarda la relazione parent-child: quando chrome.exe o code.exe generano processi figli inaspettati come powershell.exe, cmd.exe o node.exe con command line lunghe, si è probabilmente di fronte a un'estensione che invoca esecuzione nativa. Il Sysmon EventID 1 filtrato per ParentImage uguale al browser e Image diverso dai renderer legittimi è una regola ad alto valore.

Su macOS (AN0252), il unified log traccia l'uso del comando profiles per installare configuration profiles associati a estensioni forzate. Query utili via log show --predicate 'subsystem == "com.apple.ManagedClient"' evidenziano deployment MDM anomali. Il path ~/Library/Application Support/Google/Chrome/Default/Extensions/ va inventariato periodicamente e confrontato con una baseline approvata.

Su Linux (AN0253), auditd con regole su ~/.config/google-chrome/Default/Extensions/ e ~/.vscode/extensions/ cattura scritture da parte di processi non-browser — un classico segnale di installazione manuale via curl | unzip. La correlazione con NSM/Zeek per beacon HTTP verso domini appena registrati chiude il loop detection.

Riguardo ai falsi positivi, il rumore principale viene da aggiornamenti automatici legittimi delle estensioni (che modificano le stesse chiavi di registro), da tool di sviluppo che installano plugin frequentemente e da soluzioni MDM aziendali. Il tuning consigliato prevede allowlist per extension ID approvati, finestre temporali di manutenzione escluse dagli alert e correlazione obbligatoria con almeno un secondo indicatore (traffico C2, spawn di processo anomalo) prima dell'escalation. La mitigazione M1038 (Execution Prevention) implementata via allow/deny list nelle policy browser riduce drasticamente il volume di eventi da triage.

L'analisi forense di T1176 richiede la ricostruzione di tre elementi: quando l'estensione è stata installata, chi o cosa l'ha installata e quale attività ha svolto durante la sua vita utile sul sistema.

Su Windows, per Chrome il punto di partenza è la directory %LOCALAPPDATA%\Google\Chrome\User Data\Default\Extensions\<extension-id>\<version>\. Ogni sottocartella contiene il manifest.json con permission dichiarate, gli script e le risorse. Il timestamp NTFS $STANDARD_INFORMATION e $FILE_NAME (estraibili con MFTECmd di Eric Zimmerman, open source) permette di datare l'installazione. Il file %LOCALAPPDATA%\Google\Chrome\User Data\Default\Preferences è un JSON che elenca tutte le estensioni installate con install_time (formato WebKit timestamp), from_webstore boolean e path. Parsarlo con jq o script Python rivela immediatamente estensioni caricate manualmente (from_webstore: false) — un forte indicatore di installazione ostile.

Per Edge il path parallelo è sotto %LOCALAPPDATA%\Microsoft\Edge\User Data\. Per Firefox le estensioni risiedono in %APPDATA%\Mozilla\Firefox\Profiles\<profile>\extensions\ con metadata in extensions.json.

Le chiavi di registro costituiscono la seconda fonte: HKCU\Software\Google\Chrome\PreferenceMACs\Default\extensions.settings contiene MAC di integrità per ogni extension ID. Un dump con RegRipper (open source) o Registry Explorer (gratuito) di questi hive, correlato con il LastWrite timestamp, fornisce la timeline di modifiche. Per estensioni deployate via policy, HKLM\SOFTWARE\Policies\Google\Chrome\ExtensionInstallForcelist mostra install ID insieme all'URL di update — se l'URL punta a un server non-Google, l'evidenza di compromissione è forte.

Su Linux, gli artefatti risiedono in ~/.config/google-chrome/Default/Extensions/ con lo stesso layout Windows. I log auditd — se configurati per monitorare quella directory — registrano syscall open e write con PID e comm del processo installer. Il file ~/.mozilla/firefox/<profile>/addons.json è l'equivalente Mozilla.

Su macOS, oltre alle directory in ~/Library/Application Support/, i configuration profiles installati risiedono in /Library/Managed Preferences/ e /var/db/ConfigurationProfiles/. Il comando profiles list (nativo macOS) elenca i profili attivi; artefatti nel unified log con predicati su com.apple.ManagedClient datano l'installazione.

La timeline ideale correla: (1) timestamp di creazione della directory extension, (2) evento di installazione nei log applicativi, (3) primo processo figlio anomalo generato dal browser, (4) prima connessione di rete verso infrastruttura esterna post-installazione, (5) accessi a file sensibili o dump di credential store. Tool come Plaso/log2timeline (open source) integrano queste fonti in un supertimeline unificato. L'analisi statica del payload dell'estensione — codice JavaScript spesso offuscato — richiede deobfuscator come JS-beautify (open source) e sandbox come any.run (freemium) per il comportamento dinamico dei service worker.

Il dataset MITRE per T1176 non associa formalmente gruppi APT, software o campagne specifiche a questa tecnica. Questa assenza di attribuzione strutturata riflette una realtà operativa importante per l'analisi di threat intelligence: le estensioni malevole sono un vettore prevalentemente crimeware e supply chain, meno frequentemente associato a operazioni state-sponsored di alto profilo nella tassonomia ATT&CK.

Sul piano dei pattern osservabili, la tecnica si manifesta principalmente in tre contesti che il team di threat intel dovrebbe tracciare autonomamente attraverso feed OSINT e report vendor. Il primo contesto è il furto di credenziali browser-based rivolto a utenti finali, tipico di operazioni info-stealer dove l'estensione intercetta form di login, cookie di sessione e dati di autofill. Il secondo è la compromissione supply chain di estensioni popolari, dove attori acquisiscono estensioni legittime con base utenti consolidata e vi iniettano codice malevolo tramite un aggiornamento silente — un pattern che ha colpito ripetutamente il Chrome Web Store negli ultimi anni. Il terzo contesto riguarda estensioni per IDE come VS Code, un vettore emergente che colpisce sviluppatori e mira a token cloud, chiavi SSH e accesso a repository privati.

Per la priorità di monitoring, i target ad alto valore sono organizzazioni con forte esposizione a SaaS (fintech, healthcare, tech), team di sviluppo con accesso a infrastruttura cloud e ambienti dove il BYOD o la separazione debole tra browser personale e aziendale amplifica la superficie d'attacco. Il modello di trust dei marketplace ufficiali va considerato compromesso by default: un'estensione con milioni di installazioni non è automaticamente sicura, come dimostrato da episodi ricorrenti di ownership transfer malevoli.

I TTP correlati da tracciare in congiunzione con T1176 includono T1539 (Steal Web Session Cookie), T1552 (Unsecured Credentials) e le tecniche di TA0010 (Exfiltration) via canali web-based. Un'estensione ostile raramente opera isolata: fa parte di catene che culminano in account takeover di applicazioni SaaS critiche.

Per arricchire la threat intelligence interna si consiglia di seguire i Chrome Web Store transparency reports e i bollettini di sicurezza dei vendor browser, sottoscrivere feed che tracciano rimozioni di estensioni malevole (come i report periodici di ricercatori indipendenti su LinkedIn e blog aziendali di security firm), e mantenere un inventario aggiornato delle estensioni approvate confrontato periodicamente con feed di CRXcavator per changes nel risk score. La costruzione di detection rule basate su extension ID noti come malevoli (via block list distribuite tramite policy browser) rappresenta la contromisura di intelligence-to-action più efficace, integrata con la mitigazione M1033 che limita l'installazione lato client.

MITRE ATT&CK: Tecnica T1176 (Software Extensions), Tattica TA0003 (Persistence). Mitigazioni M1017, M1033, M1038, M1047, M1051. Detection DET0092 con analitiche AN0251 (Windows), AN0252 (macOS), AN0253 (Linux). Tool citati: Sysmon, MFTECmd, RegRipper, Registry Explorer, Plaso/log2timeline, auditd, Zeek, CRXcavator, vsce, BeEF, any.run, JS-beautify. Alcuni dettagli su comandi, path forensi e workflow operativi derivano da conoscenza professionale di cybersecurity applicata al framework MITRE ATT&CK.