(in)sicurezza digitale

2026-06-26 17:03:48

macOS.Gaslight: backdoor nordcoreana in Rust che inganna i tool AI degli analisti di sicurezza

Il panorama delle minacce avanzate ha appena acquisito una dimensione inedita e preoccupante: un malware nordcoreano progettato specificamente per manipolare i tool di analisi basati su intelligenza artificiale, non per sfuggire ai sandbox tradizionali. macOS.Gaslight, scoperto e analizzato dai ricercatori di SentinelOne Labs, introduce una tecnica mai vista in natura: la prompt injection direttamente nel binario, indirizzata ai pipeline di triage assistiti da LLM che oggi affiancano il lavoro degli analisti di sicurezza.

Il contesto: l’escalation del malware DPRK per macOS

La Corea del Nord ha sviluppato negli anni una capacità offensiva su macOS di tutto rispetto, tipicamente orientata al furto di criptovalute e all’infiltrazione di aziende nel settore tecnologico e finanziario. I gruppi Lazarus, BlueNoroff e i loro cluster affiliati hanno già firmato strumenti come RustBucket, KANDYKORN e ObjCShellz. macOS.Gaslight si inserisce in questa filiera, ma aggiunge un elemento evolutivo significativo: la consapevolezza che i moderni workflow di analisi del malware si appoggiano sempre più a strumenti di triage automatizzato basati su LLM, e la volontà di sfruttare proprio questa dipendenza come vettore di evasione.

La tecnica centrale: prompt injection contro l’analista, non contro il sandbox

La caratteristica distintiva di macOS.Gaslight è un payload da 3,5 KB embedded direttamente nel binario: un blob in formato Markdown contenente 38 messaggi di sistema fasulli, delimitati da token {{DATA}}. Questa struttura imita deliberatamente lo scaffold di un harness LLM per il triage del malware, rendendo indistinguibile il confine tra dati campione non attendibili e istruzioni attendibili del sistema.

I messaggi fabricati simulano scenari di errore critici: scadenza del token, kill per esaurimento della memoria (OOM), esaurimento dello spazio su disco, ripetuti fallimenti operativi, avvisi di vulnerabilità da injection e flag da analisi statica. L’obiettivo, secondo SentinelOne, è far dubitare l’agente LLM della propria sessione di analisi, portandolo ad abortire o rifiutare l’esame del campione.

«La sua caratteristica più notevole è una cascata di messaggi di sistema fabbricati, progettata per far dubitare un agente di triage assistito da LLM della propria sessione. Attacca la percezione dell’agente, non il sandbox in cui opera.»
Phil Stokes, SentinelOne Labs

Architettura tecnica del malware

Linguaggio e firma: il binario è scritto in Rust, compilato per l’architettura macOS aarch64 (Apple Silicon). È firmato in modalità ad hoc e porta l’identificatore endpoint-macos-aarch64-5555494492fc075f441637fb9d894913dde3a2ea. Il campione era stato caricato su VirusTotal il 22 maggio 2026, prima che un aggiornamento di Apple XProtect lo intercettasse basandosi puramente sull’hash.

Persistenza: il malware installa un LaunchAgent nel profilo utente, usando il label com.apple.system.services.activity nel file .plist, volutamente progettato per mimetizzarsi tra i processi di sistema legittimi di Apple. Per ottenere il percorso assoluto di se stesso da inserire nell’array ProgramArguments, il binario risolve a runtime la propria posizione tramite __NSGetExecutablePath.

Comando e controllo: l’implant utilizza il Telegram Bot API come canale C2, entrando in un ciclo di polling con getUpdates che permette all’operatore di inviare istruzioni tramite una shell interattiva e ricevere i risultati. Una scelta operativa che sfrutta la legittimità del traffico Telegram per eludere blocchi di rete basati su reputazione dei dominio. Il malware si auto-censura eliminando il proprio token Telegram dall’output runtime, impedendo a chiunque catturi log o crash di recuperarlo.

Modulo infostealer: incorporato nel binario è presente uno script Python da 6,6 KB codificato in Base64 che funge da suite di raccolta informazioni. Raccoglie: cronologia dei comandi del terminale, lista delle applicazioni installate, snapshot dei processi in esecuzione, profilo hardware e software del sistema, il database Keychain di macOS e credenziali salvate nei browser Chrome, Brave, Firefox e Safari. I dati raccolti vengono compressi in un archivio ZIP (temp/collected_data.zip) e caricati su Telegram.

Due righe per i difensori

macOS.Gaslight segna un punto di svolta: per la prima volta in natura si documenta l’uso della prompt injection come tecnica di evasione nei confronti dei pipeline di analisi automatizzata del malware. Non è più sufficiente affidarsi esclusivamente all’AI-assisted triage per la classificazione di campioni sospetti; i team di sicurezza devono implementare approcci a difesa in profondità che combinino analisi statica tradizionale, sandbox comportamentali e revisione umana.

Per quanto riguarda la detection su endpoint macOS, è consigliabile monitorare creazioni di LaunchAgent con label che imitano naming convention Apple (com.apple.*), connessioni uscenti verso l’API di Telegram (api.telegram.org) da processi non familiari, accessi al database Keychain da processi non autorizzati, e la creazione di archivi ZIP in directory temporanee non standard.

Indicatori di compromissione (IoC)

# Identificatore binario
endpoint-macos-aarch64-5555494492fc075f441637fb9d894913dde3a2ea
# Persistenza LaunchAgent
Label: com.apple.system.services.activity
Path: ~/Library/LaunchAgents/com.apple.system.services.activity.plist
# File creato durante esfiltrazione
temp/collected_data.zip
# Traffico di rete C2
api.telegram.org (polling via getUpdates)
# Caratteristiche binario
Arch: macOS aarch64 (Apple Silicon)
Linguaggio: Rust
Firma: ad hoc signed

L’analisi completa con ulteriori indicatori tecnici è disponibile nel report originale di SentinelOne Labs. La scoperta rafforza la necessità di trattare qualsiasi output di analisi AI di campioni sconosciuti con un livello aggiuntivo di scetticismo, verificando manualmente le conclusioni quando i tool automatizzati segnalano errori di sessione o fallimenti operativi insoliti durante il triage.

Spcnet.it

2026-06-26 11:12:08

Authentication Laundering e TonRAT: come il malware Node.js prende di mira il settore hospitality

Microsoft Threat Intelligence ha recentemente portato alla luce una campagna di attacco multi-stadio particolarmente sofisticata, attiva dall’aprile 2026 contro l’industria dell’ospitalità in Europa e Asia. Il vettore principale è il phishing, ma la tecnica di evasione usata — ribattezzata dagli analisti “authentication laundering” — rappresenta un salto di qualità rispetto ai metodi tradizionali.

Cos’è l’Authentication Laundering

Il termine prende spunto dal concetto di “money laundering”: come si riciclano fondi illeciti attraverso canali legittimi, gli attaccanti “riciclano” URL malevoli attraverso servizi reputati come Calendly e i redirect di Google. In pratica, il link inserito nell’email di phishing non punta direttamente al payload, ma a una pagina Calendly o a un redirect Google che a sua volta reindirizza alla risorsa malevola.

Il risultato è che i gateway email sicuri (SEG) vedono un dominio affidabile nel corpo del messaggio e lasciano passare il messaggio. La destinazione finale, quella pericolosa, viene raggiunta solo dopo che l’utente ha già cliccato. Questo approccio bypassa efficacemente:

• Reputazione URL in tempo reale
• Sandboxing statico dei link
• Filtri basati su domain reputation

La catena di attacco passo per passo

Fase 1 – Il lure

Le email di phishing sono costruite per sembrare comunicazioni legittime da parte di ospiti: reclami fotografici su condizioni delle camere, richieste di prenotazione, o segnalazioni su oggetti smarriti. Tutte contengono un link che sfrutta l’authentication laundering descritto sopra. L’obiettivo è persuadere il personale dell’hotel — tipicamente non tecnico — ad aprire un archivio ZIP allegato o scaricato.

Fase 2 – Lo ZIP con shortcut fasulli

Il file ZIP contiene shortcut (.lnk) mascherati da immagini. Quando l’utente fa doppio clic sul presunto file JPG, in realtà esegue uno script PowerShell heavily obfuscated che dà il via alla catena di infezione.

# Esempio semplificato di obfuscation tipica nei dropper PowerShell
$encoded = "JABzAD0AIgBoAHQAdABwAHMAOi..."
[System.Text.Encoding]::Unicode.GetString([Convert]::FromBase64String($encoded)) | IEX

Gli script evolvono attraverso multiple iterazioni per evitare le signature statiche degli antivirus: ogni stage decodifica il successivo in memoria prima di eseguirlo.

Fase 3 – Deployment di TonRAT (Implant Node.js)

Il payload finale è TonRAT, un Remote Access Trojan scritto in Node.js. La scelta di Node.js è deliberata: viene eseguito da directory user-space (es. %APPDATA%), senza richiedere privilegi elevati, e sfrutta un runtime legittimo — il processo node.exe — che non desta sospetti ai controlli superficiali.

TonRAT dispone di capacità avanzate:

• Modifica delle esclusioni di Microsoft Defender: aggiunge i propri processi temporanei alla lista delle esclusioni per operare indisturbato.
• Compilazione .NET dinamica: genera ed esegue codice .NET in memoria per estendere le proprie capacità senza toccare il disco.
• Download di componenti aggiuntivi: se un componente viene rimosso da un prodotto di sicurezza, l’implant si riconnette al C2 e lo riscarica automaticamente.

Fase 4 – Persistenza duale nel Registro

La persistenza viene garantita attraverso un meccanismo a doppio strato nel registro di Windows:

HKCU\Software\Microsoft\Windows\CurrentVersion\Run
HKCU\Software\Microsoft\Windows\CurrentVersion\RunOnce

Sia il componente Node.js principale che i payload secondari in ProgramData hanno proprie entry con percorsi randomizzati. Se la sicurezza rimuove uno dei due, l’altro sopravvive e provvede a ripristinare il componente eliminato.

Come difendersi: Indicatori e Contromisure

Monitoraggio comportamentale

Il punto critico da monitorare è l’esecuzione di node.exe da directory non standard. In un ambiente aziendale, Node.js non dovrebbe mai girare da %APPDATA%, %TEMP% o %LOCALAPPDATA%. Un alert su questo pattern è altamente indicativo.

# Query per trovare processi node.exe in esecuzione da directory sospette (PowerShell)
Get-CimInstance Win32_Process -Filter "Name = node.exe" |
  Select-Object ProcessId, CommandLine, @{
    Name=Path; Expression={$_.ExecutablePath}
  } |
  Where-Object { $_.Path -notlike "*\Program Files*" -and $_.Path -notlike "*\nodejs*" }

Audit delle Registry Run Keys

Verificare regolarmente la presenza di entry con nomi randomizzati (tipicamente 8-12 caratteri alfanumerici) nelle chiavi di autorun:

# Controllo chiavi Run e RunOnce per tutti gli utenti del sistema
$keys = @(
  "HKLM:\Software\Microsoft\Windows\CurrentVersion\Run",
  "HKLM:\Software\Microsoft\Windows\CurrentVersion\RunOnce",
  "HKCU:\Software\Microsoft\Windows\CurrentVersion\Run",
  "HKCU:\Software\Microsoft\Windows\CurrentVersion\RunOnce"
)
foreach ($key in $keys) {
  Write-Host "`n[$key]"
  Get-ItemProperty -Path $key -ErrorAction SilentlyContinue |
    Select-Object -Property * -ExcludeProperty PS*
}

Politiche di restrizione PowerShell

Abilitare la modalità Constrained Language di PowerShell e configurare le AMSI-based logging per catturare gli script decodificati prima dell’esecuzione:

# Abilitare la trascrizione di PowerShell (via GPO o direttamente)
Set-ItemProperty -Path "HKLM:\Software\Policies\Microsoft\Windows\PowerShell\Transcription" `
  -Name "EnableTranscripting" -Value 1 -Force
Set-ItemProperty -Path "HKLM:\Software\Policies\Microsoft\Windows\PowerShell\Transcription" `
  -Name "OutputDirectory" -Value "C:\PSLogs" -Force

Formazione del personale

Poiché il vettore iniziale è sociale, la formazione rimane fondamentale. Il personale dell’ospitalità deve essere addestrato a:

• Non aprire allegati ZIP da email sconosciute, anche se contengono presunte foto di ospiti
• Verificare il dominio reale di un link passando il mouse sopra prima di cliccare
• Segnalare immediatamente comportamenti anomali dei propri dispositivi

La campagna TonRAT esemplifica l’evoluzione delle minacce verso un’evasione sempre più raffinata. L’authentication laundering rende inefficaci i controlli perimetrali basati sulla reputazione dei domini, spostando il punto di difesa verso il rilevamento comportamentale. Per i sysadmin, il takeaway principale è chiaro: non basta bloccare URL malevoli — occorre monitorare ciò che accade dopo il click, dentro i sistemi.

Fonte: 4sysops.com | Analisi tecnica originale: Microsoft Threat Intelligence

Hospitality industry targeted by persistent Node.js malware via photo-themed phishing – 4sysops

Microsoft Threat Intelligence has uncovered a multi-stage cyberattack campaign targeting the hospitality industry in Europe and Asia since April 2026. The threa

^{IT News (4sysops)}

Spcnet.it

2026-06-26 11:05:20

Gestire Microsoft Defender Antivirus con PowerShell: cmdlet pratici per sysadmin

Microsoft Defender Antivirus è il componente di sicurezza integrato in Windows 10, Windows 11 e Windows Server 2016 e successivi. Spesso gestito tramite interfaccia grafica o Group Policy, offre però un set completo di cmdlet PowerShell che permettono una gestione programmatica potente, particolarmente utile in ambienti server headless, pipeline di automazione e script di provisioning.

In questo articolo esploriamo i cmdlet principali, con esempi pratici di utilizzo per la gestione quotidiana da parte di amministratori di sistema.

Prerequisiti e Accesso

I cmdlet di Defender sono disponibili per impostazione predefinita su Windows 10/11 e Windows Server 2016+. Per usarli è necessario aprire PowerShell come amministratore.

# Verifica che il modulo Defender sia disponibile
Get-Module -ListAvailable -Name Defender

# Per visualizzare la documentazione completa di qualsiasi cmdlet
Get-Help <cmdlet> -Online

Nota importante: le modifiche apportate via PowerShell agiscono sulle impostazioni locali del dispositivo. Politiche distribuite tramite Microsoft Intune, Group Policy o Configuration Manager possono sovrascriverle. Pianificare di conseguenza nelle architetture gestite centralmente.

Verificare lo Stato della Protezione

Il punto di partenza è sempre capire in che stato si trova il sistema.

# Stato complessivo di Defender Antivirus
Get-MpComputerStatus

# Output selettivo: solo i campi più rilevanti
Get-MpComputerStatus | Select-Object `
  AntivirusEnabled, `
  RealTimeProtectionEnabled, `
  BehaviorMonitorEnabled, `
  IoavProtectionEnabled, `
  NISEnabled, `
  QuickScanAge, `
  FullScanAge, `
  AntivirusSignatureLastUpdated, `
  AntivirusSignatureVersion

QuickScanAge e FullScanAge indicano da quanti giorni non viene eseguita una scansione rapida o completa. Un valore molto alto può indicare un problema di pianificazione. AntivirusSignatureLastUpdated è critico: firme obsolete riducono drasticamente l’efficacia della protezione.

Configurare le Preferenze con Set-MpPreference

Set-MpPreference è il cmdlet centrale per la configurazione. Permette di intervenire su centinaia di parametri.

Protezione in Tempo Reale

# Abilitare la protezione in tempo reale (default: abilitata)
Set-MpPreference -DisableRealtimeMonitoring $false

# Abilitare il monitoraggio comportamentale
Set-MpPreference -DisableBehaviorMonitoring $false

# Abilitare la protezione cloud-delivered (MAPS)
Set-MpPreference -MAPSReporting Advanced
Set-MpPreference -SubmitSamplesConsent SendAllSamples

Gestire le Esclusioni

Le esclusioni sono necessarie in ambienti dove certi processi o directory generano falsi positivi, ma vanno gestite con attenzione: sono uno dei vettori sfruttati dagli attaccanti (come visto nel caso TonRAT).

# Aggiungere un percorso alle esclusioni
Add-MpPreference -ExclusionPath "C:\AppData\MyApp\cache"

# Aggiungere un processo alle esclusioni
Add-MpPreference -ExclusionProcess "msbuild.exe"

# Aggiungere un’estensione file alle esclusioni
Add-MpPreference -ExclusionExtension ".log"

# Verificare le esclusioni configurate
Get-MpPreference | Select-Object ExclusionPath, ExclusionProcess, ExclusionExtension

# Rimuovere una singola esclusione
Remove-MpPreference -ExclusionPath "C:\AppData\MyApp\cache"

Best practice: documentare ogni esclusione con il motivo tecnico e revisionarle periodicamente. Un’esclusione dimenticata è una superficie di attacco aperta.

Pianificazione delle Scansioni

# Impostare una scansione rapida giornaliera alle 03:00
Set-MpPreference -ScanScheduleDay Everyday
Set-MpPreference -ScanScheduleTime 03:00:00

# Impostare una scansione completa settimanale alla domenica alle 02:00
Set-MpPreference -ScanParameters FullScan
Set-MpPreference -ScanScheduleDay Sunday
Set-MpPreference -ScanScheduleTime 02:00:00

# Abilitare la scansione dei file email e degli archivi compressi
Set-MpPreference -DisableEmailScanning $false
Set-MpPreference -DisableArchiveScanning $false

Aggiornare le Definizioni Antivirus

# Aggiornare le signature immediatamente
Update-MpSignature

# Aggiornare da un percorso UNC condiviso (es. WSUS o share locale)
Update-MpSignature -UpdateSource InternalDefinitionUpdateServer

# Verificare la versione corrente delle signature
(Get-MpComputerStatus).AntivirusSignatureVersion
(Get-MpComputerStatus).AntivirusSignatureLastUpdated

In ambienti con dispositivi offline o in reti segmentate, la distribuzione delle signature tramite share UNC o WSUS è essenziale. Update-MpSignature supporta diversi source: MicrosoftUpdateServer, MMPC, InternalDefinitionUpdateServer, FileShares.

Avviare Scansioni Manuali

# Scansione rapida
Start-MpScan -ScanType QuickScan

# Scansione completa
Start-MpScan -ScanType FullScan

# Scansione di un percorso specifico (custom scan)
Start-MpScan -ScanType CustomScan -ScanPath "D:\Downloads"

# Avviare in modo asincrono (non blocca la shell)
Start-MpScan -ScanType QuickScan -AsJob

Rilevare e Gestire le Minacce

# Visualizzare le minacce rilevate attualmente attive
Get-MpThreat

# Visualizzare lo storico delle rilevazioni (incluse quelle già gestite)
Get-MpThreatDetection

# Output dettagliato di una singola minaccia per ID
Get-MpThreat | Where-Object { $_.ThreatID -eq 12345 } | Format-List *

# Rimuovere tutte le minacce attive in quarantena
Remove-MpThreat

Performance Analyzer: Individuare i Colli di Bottiglia

Se Defender causa rallentamenti, il Performance Analyzer integrato aiuta a identificare quali file, processi o estensioni impattano maggiormente sui tempi di scansione:

# Avviare la raccolta dati per 60 secondi
New-MpPerformanceRecording -RecordTo "C:\Temp\DefenderPerf.etl"

# Analizzare i risultati: top 10 file più lenti da scansionare
Get-MpPerformanceReport -Path "C:\Temp\DefenderPerf.etl" `
  -TopFiles 10 `
  -TopScansPerFile 5 `
  -TopProcessesPerFile 5

Automazione: Script di Audit Difensivo

Uno script di audit rapido da eseguire periodicamente su ogni macchina o tramite PSRemoting su più host:

function Get-DefenderAudit {
  $status = Get-MpComputerStatus
  $prefs  = Get-MpPreference

  [PSCustomObject]@{
    ComputerName            = $env:COMPUTERNAME
    AVEnabled               = $status.AntivirusEnabled
    RealTimeProtection      = $status.RealTimeProtectionEnabled
    SignatureAge_Days       = ((Get-Date) - $status.AntivirusSignatureLastUpdated).Days
    SignatureVersion        = $status.AntivirusSignatureVersion
    LastQuickScan_Days      = $status.QuickScanAge
    LastFullScan_Days       = $status.FullScanAge
    ExclusionPathCount      = @($prefs.ExclusionPath).Count
    ExclusionProcessCount   = @($prefs.ExclusionProcess).Count
    CloudProtection         = $prefs.MAPSReporting
  }
}

# Esecuzione locale
Get-DefenderAudit | Format-List

# Esecuzione remota su più host
$servers = @("SRV01", "SRV02", "SRV03")
Invoke-Command -ComputerName $servers -ScriptBlock ${Function:Get-DefenderAudit} |
  Sort-Object SignatureAge_Days -Descending |
  Format-Table -AutoSize

Conclusione

I cmdlet PowerShell di Microsoft Defender Antivirus offrono un controllo granulare e scriptabile su ogni aspetto della protezione, rendendoli uno strumento fondamentale per i sysadmin che gestiscono flotte di macchine Windows. Integrarli in pipeline di provisioning, script di audit periodici e runbook di incident response è una pratica che migliora significativamente la postura di sicurezza senza dipendere da interfacce grafiche.

Ricorda: le modifiche via PowerShell sono locali e possono essere sovrascritte da GPO o Intune. In ambienti gestiti centralmente, usa PowerShell per audit e diagnostica, e riserva la configurazione permanente agli strumenti di management centralizzato.

Fonte: 4sysops.com | Documentazione ufficiale: Microsoft Learn

Managing Microsoft Defender Antivirus through PowerShell cmdlets – 4sysops

Microsoft Defender Antivirus provides a robust set of PowerShell cmdlets for managing security features on Windows 10, Windows 11, and Windows Server 2016 or la

^{IT News (4sysops)}

(in)sicurezza digitale

2026-06-25 14:00:03

Kit AiTM contro AWS: Datadog svela una campagna di phishing che bypassa l’MFA in tempo reale

Si parla di:
Toggle

Tra il 16 e il 19 giugno 2026, i ricercatori di Datadog Security Research hanno osservato una campagna di phishing altamente sofisticata contro la console AWS. Non si tratta del classico furto di credenziali: il kit implementa tecniche adversary-in-the-middle (AiTM) che permettono di catturare i codici MFA in tempo reale, bypassando email, SMS e app di autenticazione TOTP. Un’analisi tecnica dettagliata pubblicata il 24 giugno svela l’architettura del kit, gli IoC e le tecniche di delivery utilizzate.

La campagna: tre domini in 48 ore

La campagna si è concretizzata con la registrazione di tre domini in una finestra di soli due giorni, tutti attraverso il registrar NICENIC INTERNATIONAL GROUP CO., LIMITED e ospitati su infrastruttura Cloudflare. I domini impersonavano con fedeltà la pagina di login della console AWS:

• us-west-login[.]com (registrato il 18 giugno 2026) — con sottodomini aws.us-west-login[.]com e aws-central.us-west-login[.]com
• us-east-prod[.]com (registrato il 17 giugno 2026) — con sottodominio aws.us-east-prod[.]com
• loginportal-aws[.]com (registrato il 16 giugno 2026)

In parallelo, sono stati identificati altri tre domini che impersonavano SendGrid, registrati nello stesso arco temporale attraverso lo stesso registrar. La doppia infrastruttura — AWS e SendGrid — suggerisce che gli attaccanti abbiano progettato un sistema integrato: SendGrid per la consegna delle email di phishing, i cloni AWS per la raccolta delle credenziali.

Come funziona il kit: AiTM in tempo reale

La caratteristica più pericolosa di questo kit non è la clonazione della pagina login, ma la capacità di intercettare e ritrasmettere il secondo fattore di autenticazione in tempo reale. Il flusso si articola in più fasi:

1. Validazione del target prima del rendering: quando la vittima accede alla pagina di phishing, il kit legge il parametro URL input_24 contenente un blob base64 cifrato. Il server decodifica l’indirizzo email della vittima e lo imposta come cookie. Solo se l’email è valida e registrata come target, la pagina viene effettivamente renderizzata — una misura anti-sandbox che rende inutile l’analisi automatica senza una email vittima valida.

// Logica di validazione dell'indirizzo vittima
let e = new URLSearchParams(window.location.search).get(`input_24`);
(e ? fetch(`/api/check`, {
  method: `POST`,
  body: JSON.stringify({ encrypted: e }),
  credentials: `include`
}) : Promise.resolve({ ok: !1 }))
.then(e => e.ok ? e.json() : null)
.then(() => fetch(`/api/me`, { credentials: `include` }))
.then(e => e.json())
.then(e => t(e.email || null))

2. Furto delle credenziali primarie: la pagina clonata raccoglie username e password tramite i form di login AWS (sia account root che IAM) e li invia a /api/login. Il server, agendo come proxy verso la vera console AWS, ottiene in risposta quale tipo di MFA è configurato sull’account.

3. Intercettazione dell’MFA in real-time: il kit presenta alla vittima la challenge MFA corrispondente al secondo fattore configurato — /email, /sms, o /gauth per le app TOTP. Il codice inserito viene intercettato e ritrasmesso immediatamente al server AWS legittimo, completando l’autenticazione prima che il codice scada.

Delivery: phishing mirato via SendGrid e Nimbu

Il 19 giugno 2026 è apparso su VirusTotal un batch file che funge da artefatto di validazione dell’infrastruttura. Il file contiene la struttura di un’email di phishing che impersona il supporto AWS, citando un ticket di supporto fasullo su presunto throttling della banda. La consegna avviene tramite piattaforme email legittime come SendGrid e Nimbu, scelta tattica che permette di passare i controlli SPF/DKIM/DMARC e bypassare i filtri antispam aziendali.

L’uso del parametro input_24 per la validazione dell’email suggerisce inoltre che si tratti di una campagna di spear phishing mirato piuttosto che mass phishing: ogni link contiene l’email cifrata della specifica vittima, rendendo impossibile l’accesso alla pagina di phishing senza il link personalizzato.

TTPs e mapping MITRE ATT&CK

• T1566.002 — Spearphishing Link: link personalizzati con email cifrata per targeting preciso
• T1111 — MFA Interception: cattura in real-time di email OTP, SMS e codici TOTP
• T1056.001 — Keylogging: raccolta di username, password e codici di verifica prima del forwarding
• T1583.001 — Acquire Infrastructure: Domains: tre domini registrati nello stesso arco di 48 ore
• T1133 — External Remote Services: targeting dell’accesso alla console AWS

Indicatori di compromissione (IoC)

# Domini AWS phishing
us-west-login[.]com
aws.us-west-login[.]com
aws-central.us-west-login[.]com
us-east-prod[.]com
aws.us-east-prod[.]com
loginportal-aws[.]com

# Registrar comune
NICENIC INTERNATIONAL GROUP CO., LIMITED

# Infrastruttura di hosting
Cloudflare (tutti i domini)

# Endpoint API del kit
/api/check   - validazione email vittima
/api/me      - recupero email da cookie
/api/login   - furto credenziali e identificazione MFA
/email       - challenge MFA via email
/sms         - challenge MFA via SMS
/gauth       - challenge MFA via TOTP

# Parametro URL di targeting
input_24 (blob base64 cifrato contenente email vittima)

Come rilevare l’attacco

Datadog consiglia le seguenti azioni di hunting per chi sospetti di essere stato targetizzato:

• DNS hunting: verificare la presenza nei log DNS di query verso i domini elencati negli IoC, inclusi i sottodomini
• CloudTrail monitoring: controllare eventi ConsoleLogin da IP inusuali o da località geografiche anomale, soprattutto a ridosso delle date di campagna (16-19 giugno 2026)
• Email gateway review: cercare email provenienti da SendGrid o Nimbu che contengano link con il parametro input_24 nell’URL
• Credential review: se si sospetta compromissione, revocare immediatamente le sessioni AWS attive, ruotare le credenziali e abilitare notifiche di accesso non familiare

La sofisticazione di questo kit — targeting selettivo, bypass MFA in real-time, uso di infrastrutture email legittime — lo colloca in una categoria diversa rispetto al phishing di massa. Le organizzazioni che utilizzano AWS in ambienti enterprise dovrebbero trattare questa campagna come un rischio attivo, non come una minaccia teorica.

(in)sicurezza digitale

2026-06-24 17:24:58

Skill AI malevola raggiunge 26.000 agenti: la tecnica del mutable link che inganna tutti gli scanner di sicurezza

I ricercatori di AIR hanno costruito una skill AI fasulla, l’hanno caricata su un marketplace e promossa via Instagram, e l’hanno vista raggiungere 26.000 agenti — inclusi account aziendali — senza che un singolo scanner di sicurezza la rilevasse come pericolosa. L’arma? Un link esterno modificabile dopo il superamento dei controlli.

Il problema che nessuno vuole ammettere: i marketplace di skill AI sono fondamentalmente insicuri

Nel giro di pochi mesi, le “skill” per agenti AI sono diventate il nuovo npm: pacchetti di codice che estendono le capacità degli assistenti AI, installabili con un click, fidandosi di valutazioni, stelle GitHub e reputazione open source. E come npm nel 2018, stanno diventando un vettore di attacco privilegiato.

Il team di ricerca AIR ha deciso di quantificare il problema invece di teorizzarlo. Ha costruito una skill malevola, l’ha caricata su un marketplace di agenti, e ha tracciato la sua diffusione. Il risultato è al tempo stesso prevedibile e allarmante: 26.000 agenti installanti, inclusi account riconducibili a organizzazioni aziendali, e zero rilevamenti da parte degli scanner di sicurezza testati.

La tecnica: il mutable link come cieco spot nelle pipeline di vetting

Il cuore tecnico dell’attacco è una tecnica elegante che sfrutta un’assunzione implicita nei sistemi di vetting delle skill: che il codice analizzato al momento della scansione sia lo stesso codice che verrà eseguito dopo l’installazione.

La skill creata da AIR conteneva un riferimento a un link esterno — non il payload direttamente, ma un URL che punta a un file remoto caricato al momento dell’esecuzione. Durante la fase di scansione, quel link puntava a codice benigno. Dopo che la skill aveva superato tutti i controlli e veniva distribuita agli agenti, il contenuto del link remoto poteva essere sostituito con payload arbitrari.

# Schema semplificato della tecnica mutable link
# Fase 1 - durante la scansione di sicurezza:
skill.execute() → fetch(external_link) → returns: benign_code.py → PASS
# Fase 2 - dopo approvazione e distribuzione:
skill.execute() → fetch(external_link) → returns: malicious_payload.py → EXEC
# Il contenuto di external_link è controllato dall'attaccante
# e può essere modificato in qualsiasi momento dopo il vetting

AIR ha mantenuto il payload effettivo completamente innocuo — raccogliendo solo l’indirizzo email dell’utente — per rispettare l’etica della ricerca. Ma la dimostrazione è cristallina: la stessa tecnica avrebbe potuto distribuire qualsiasi payload: infostealer, accesso remoto, exfiltration di credenziali API, manipolazione delle risposte del modello LLM.

Nessuno dei segnali di fiducia ha funzionato

Quello che rende questo esperimento particolarmente significativo non è la tecnica in sé — varianti del “mutable dependency” attack sono note nell’ecosistema npm e PyPI — ma il fatto che nessuno dei meccanismi su cui gli utenti si affidano per valutare la sicurezza di una skill abbia funzionato:

• Scanner automatici di sicurezza: tutti i tool testati da AIR hanno classificato la skill come sicura. L’analisi statica del codice non può rilevare comportamenti che dipendono da contenuto remoto mutabile.
• Stelle GitHub e reputazione open source: indicatori di popolarità, non di sicurezza. La skill aveva un repository pubblico con codice apparentemente innocuo.
• Revisione manuale del codice sorgente: la skill era tecnicamente open source — ma il punto è che il codice rilevante non è nel repository, è sul server remoto.
• Provenienza del publisher: un account creato ad hoc senza storia precedente ha comunque raggiunto 26.000 installazioni.

Il contesto: 2026 è l’anno zero della sicurezza agentica

Questa ricerca arriva in un momento di crescente preoccupazione per la sicurezza dei marketplace di skill per agenti AI. A gennaio 2026, la campagna ClawHavoc aveva sistematicamente compromesso oltre 1.184 skill nel marketplace ClawHub di OpenClaw — circa una su cinque — con infostealer che raccoglievano chiavi API LLM, chiavi SSH private, password salvate nel browser e dati di wallet crittografici.

Il pattern si ripete con caratteristiche comuni: gli attacchi sfruttano la fiducia implicita che gli utenti ripongono nei marketplace ufficiali, l’assenza di standard di sicurezza stringenti per la pubblicazione delle skill, e la difficoltà strutturale di ispezionare comportamenti dinamici con tool di analisi statica.

Il problema è aggravato dalle caratteristiche peculiari degli agenti AI rispetto ai software tradizionali. Una skill malevola installata su un agente non è solo malware che gira su un host: è codice che opera con i permessi dell’agente, ha accesso ai contesti delle conversazioni, può esfiltrare prompt e risposte, manipolare le istruzioni che l’agente riceve e potenzialmente propagarsi attraverso le funzioni di collaborazione tra agenti.

Vettore di distribuzione: Instagram come canale di diffusione

Un dettaglio operativo significativo dell’esperimento AIR è il canale di distribuzione utilizzato: oltre alla pubblicazione sul marketplace, la skill è stata promossa tramite annunci Instagram. Questo rivela come gli attori malintenzionati non si limitino ai canali tecnici per diffondere skill pericolose — le piattaforme social diventano un amplificatore efficace per raggiungere utenti che cercano funzionalità specifiche per i loro agenti.

La combinazione marketplace + social advertising è particolarmente efficace perché mima esattamente come vengono promosse le skill legittime: sviluppatori e piccoli vendor usano i social per aumentare la visibilità dei propri strumenti. Non c’è un segnale d’allarme visibile per l’utente finale.

Due righe per i difensori: cosa fare adesso

La ricerca AIR lascia i team di sicurezza con un problema concreto: come valutare la sicurezza delle skill AI installate in ambiente aziendale quando gli strumenti attuali non sono adeguati?

• Inventario delle skill installate: avere visibilità su quali skill sono attive negli agenti AI aziendali è il prerequisito minimo. Molte organizzazioni non hanno ancora questo controllo di base.
• Policy di approvazione centralizzata: analogamente ai criteri di approvazione per le estensioni browser o i plugin IDE, le skill AI dovrebbero essere soggette a un processo di vetting prima dell’uso in contesti aziendali.
• Sandbox per l’esecuzione delle skill: isolare l’esecuzione delle skill in ambienti sandboxed può limitare il raggio d’azione di una skill compromessa, impedendole di accedere a credenziali, file system o rete aziendale.
• Monitoraggio delle connessioni in uscita: le skill che stabiliscono connessioni HTTP verso URL esterni non strettamente necessari alla loro funzione dichiarata dovrebbero generare alert nel sistema di monitoraggio.
• Diffidare del dynamic loading: skill che caricano codice da URL remoti dovrebbero essere trattate con la stessa cautela con cui si trattano i loader malware nel contesto tradizionale.

Il nodo irrisolto: chi è responsabile della sicurezza dei marketplace?

La ricerca AIR apre una questione di governance che l’industria non ha ancora risolto: chi è responsabile della sicurezza in un marketplace di skill AI? I marketplace stessi hanno incentivi a crescere rapidamente e a ridurre le frizioni per i publisher. I vendor di agenti AI scaricano spesso la responsabilità sugli utenti finali. I publisher di skill, se malintenzionati, ovviamente non si auto-regolano.

Il risultato è un ecosistema in cui 26.000 agenti — inclusi probabilmente molti in contesti aziendali — possono essere raggiunti da codice arbitrario, e nessuno ha strumenti adeguati per rilevarlo prima che accada. Un problema familiare a chiunque abbia vissuto l’evoluzione della sicurezza dell’ecosistema npm o PyPI — con la differenza che gli agenti AI operano con privilegi e accessi molto più estesi di una libreria Node.js.

securityaffairs

2026-06-23 23:03:03

#Samsung #KNOX #Kernel UAF Exposes Millions of #Galaxy Devices
securityaffairs.com/194090/sec…
#securityaffairs #hacking

Samsung KNOX Kernel UAF Exposes Millions of Galaxy Devices

Samsung’s KNOX flaw (CVE-2026-20971) is a kernel UAF in PROCA/FIVE that can enable corruption via a race; Samsung patched it in Jan 2026.

^{Pierluigi Paganini (Security Affairs)}

(in)sicurezza digitale

2026-06-23 13:55:01

VBScript via WhatsApp: documenti aziendali falsi installano ManageEngine RMM in campagna globale con tracce cinesi

Si parla di:
Toggle

Kaspersky ha documentato una campagna malware attiva in 11 Paesi che utilizza WhatsApp come vettore di distribuzione iniziale. Allegati VBScript pesantemente offuscati, camuffati da documenti aziendali, avviano una catena di infezione multi-stadio che termina con l’installazione silenziosa di ManageEngine Endpoint Central — un software RMM legittimo riconfigurato per dare agli attaccanti accesso remoto persistente. L’infrastruttura mostra sovrapposizioni con campagne Gh0st RAT e ValleyRAT, suggerendo con bassa confidenza un operatore di lingua cinese.

WhatsApp come vettore: la scelta tattica

La scelta di WhatsApp come canale di distribuzione è tutt’altro che casuale. A differenza della posta elettronica, WhatsApp non dispone di gateway di sicurezza aziendali, filtri antimalware inline, o sandbox automatici per gli allegati. I file vengono recapitati direttamente al dispositivo della vittima, bypassando la maggior parte delle difese perimetrali tradizionali. Inoltre, i messaggi arrivano da account WhatsApp precedentemente compromessi — non da numeri sconosciuti — il che aumenta notevolmente la probabilità che la vittima apra l’allegato, fidandosi del mittente apparente.

I file vengono distribuiti come archivi ZIP con nomi volutamente credibili in più lingue: “Financial Reports.vbs”, “Account Statement.vbs”, ma anche varianti in portoghese, francese, tedesco e malese, a riflettere la portata geografica dell’operazione.

La catena di infezione: quattro stadi verso il controllo remoto

Una volta che la vittima apre il file VBScript su Windows, si attiva una sequenza di infezione articolata in quattro fasi.

Stage 1 — VBScript offuscato: il file VBS è pesantemente offuscato per eludere il rilevamento statico. All’esecuzione, contatta l’infrastruttura dell’attaccante e scarica due script aggiuntivi.

Stage 2 — UAC bypass: uno degli script scaricati disabilita le protezioni User Account Control (UAC) attraverso modifiche al registro di sistema di Windows, eliminando i prompt di sicurezza per le operazioni successive.

Stage 3 — Download del payload: viene scaricato un archivio ZIP contenente un deployment preconfigurato di ManageEngine Endpoint Central, comprensivo di installer MSI (UEMSAgent.msi), certificati, file di configurazione e script di installazione.

Stage 4 — Installazione silenziosa: il launcher setup1.vbs esegue l’installazione silenziosa dell’agente tramite msiexec.exe. L’agente viene registrato sull’infrastruttura di controllo dell’attaccante, fornendo accesso remoto completo al sistema della vittima: esecuzione di comandi, trasferimento file, accesso alla shell, e molto altro.

--- CATENA DI INFEZIONE ---

[WhatsApp] → ZIP archive
    └── Financial_Reports.vbs (offuscato)
          ├── Stage 2: Download script → UAC bypass via Registry
          │     HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
          │     ConsentPromptBehaviorAdmin = 0 / EnableLUA = 0
          └── Stage 3: Download ZIP (ManageEngine Endpoint Central)
                └── UEMSAgent.msi
                └── setup1.vbs → msiexec.exe /quiet /norestart
                └── Certificati e config preconfigurati
                      └── Registrazione su C2 attaccante

L’abuso degli strumenti RMM legittimi: una tecnica consolidata

L’utilizzo di ManageEngine Endpoint Central come payload finale è una scelta deliberata e strategica. I software RMM legittimi come ManageEngine, AnyDesk, TeamViewer o Atera presentano vantaggi significativi per gli attaccanti: sono firmati digitalmente da vendor riconosciuti, vengono spesso esclusi dalle soluzioni antimalware per evitare falsi positivi operativi, sono difficilmente distinguibili da usi legittimi in ambienti enterprise, e forniscono funzionalità complete di gestione remota. La CISA americana ha già avvertito in passato dell’abuso di strumenti RMM da parte di attori state-sponsored e cybercriminali.

Attribuzione: tracce verso la Cina, confidenza bassa

I ricercatori di Kaspersky hanno identificato sovrapposizioni infrastrutturali con campagne precedenti attribuite a ValleyRAT e Gh0st RAT, due famiglie di malware storicamente associate ad attori di lingua cinese. In particolare, l’indirizzo IP 202.61.160.201 è apparso sia nell’infrastruttura di questa campagna sia in precedenti operazioni Gh0st RAT/ValleyRAT. Nonostante queste sovrapposizioni, Kaspersky mantiene una bassa confidenza nell’attribuzione, in quanto la riutilizzazione di infrastruttura non implica necessariamente la stessa organizzazione — una tecnica che alcune operazioni usano deliberatamente per depistare le attribuzioni.

Distribuzione geografica: Malaysia epicentro, portata globale

Le vittime osservate sono distribuite in 11 Paesi e territori: Malaysia (circa l’80% dei casi), Brasile, India, Messico, Singapore, Regno Unito, Spagna, Taiwan, Australia, Russia e Vietnam. La concentrazione in Malaysia suggerisce che questa possa essere la regione target primaria, con gli altri Paesi colpiti da una distribuzione più opportunistica o da campagne parallele adattate linguisticamente.

Due righe per i difensori

Per mitigare questa minaccia è necessario agire su più livelli. A livello di endpoint, occorre bloccare l’esecuzione di file .VBS, .VBE, .JS e .WSF da parte di utenti non amministratori tramite Group Policy (Software Restriction Policies o AppLocker). È altresì importante monitorare le modifiche alle chiavi di registro relative a UAC (ConsentPromptBehaviorAdmin, EnableLUA) come segnale di compromissione. Sul fronte delle applicazioni, è necessario implementare una whitelist dei software RMM autorizzati e bloccare l’installazione silenziosa di agenti non approvati tramite msiexec. Gli utenti, infine, vanno sensibilizzati a non aprire allegati ricevuti via WhatsApp — specialmente file .ZIP con estensioni .VBS — anche quando provengono da contatti noti, poiché gli account WhatsApp dei mittenti potrebbero essere compromessi.

--- INDICATORI DI COMPROMISSIONE (IoC) ---

IP infrastruttura:
  202.61.160.201  (overlap con Gh0st RAT / ValleyRAT)

File sospetti:
  Financial Reports.vbs
  Account Statement.vbs
  setup1.vbs
  UEMSAgent.msi  (ManageEngine Endpoint Central preconfigurato)

Chiavi di registro modificate (UAC bypass):
  HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\ConsentPromptBehaviorAdmin
  HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\EnableLUA

Processo sospetto:
  msiexec.exe /quiet /norestart [lanciato da VBScript]

Paesi colpiti: Malaysia (80%), Brasile, India, Messico, Singapore,
               UK, Spagna, Taiwan, Australia, Russia, Vietnam

Fonte: Kaspersky Securelist, giugno 2026

(in)sicurezza digitale

2026-06-22 16:57:54

AryStinger: la botnet che trasforma router D-Link in armi silenziose per attacchi globali

I ricercatori di XLab (Qianxin) hanno scoperto AryStinger, una botnet precedentemente sconosciuta che ha compromesso oltre 4.000 router obsoleti in tutto il mondo, trasformandoli in proxy silenziosi al servizio di attori malevoli. A differenza delle classiche botnet DDoS, AryStinger è progettata per il ricognizione e il supporto alle intrusioni — un’infrastruttura invisibile concepita per penetrare reti aziendali e governative.

Scoperta e timeline dell’operazione

Il 12 marzo 2026, il sistema di threat awareness di XLab ha rilevato l’indirizzo IP 107.150.106.14 che diffondeva un campione ELF con zero detection su VirusTotal, sfruttando due vulnerabilità datate: CVE-2013-3307 e CVE-2016-5681. Il campione, implementato in C, prendeva di mira router D-Link DIR-850L e DIR-818LW — dispositivi giunti a fine vita, privi di patch e ancora ampiamente diffusi in ambito SOHO.

Il 26 aprile è comparso un secondo campione correlato, questa volta scritto in Go e rivolto a dispositivi NAS, sfruttando CVE-2025-11837. Il percorso nel codice sorgente del campione Go rivela il nome del progetto interno: Ary-Attack — un dettaglio che ha consentito ai ricercatori di attribuire le due famiglie alla stessa operazione.

Architettura e capacità operative

AryStinger converte i dispositivi infetti in “executor” telecomandati, capaci di eseguire un insieme ricco di operazioni su richiesta del C2:

• Scansione di rete: port scanning, identificazione dei servizi, enumerazione di sottodomini — attività tipiche della fase di ricognizione pre-intrusione.
• Proxying e tunneling: il device infetto instrada traffico malevolo verso destinazioni terze, mascherando l’origine reale dell’attaccante.
• Esecuzione di comandi arbitrari sul sistema.
• Modifiche DNS: la botnet può alterare le configurazioni DNS del router per intercettare il traffico web degli utenti connessi.
• Payload multi-linguaggio: supporta l’iniezione di payload scritti in Go, Java e Python, garantendo flessibilità operativa.
• Canali di accesso persistente via dropbear (SSH) o gs-netcat.

Le comunicazioni con il server di comando e controllo avvengono via HTTP/HTTPS, con traffico serializzato tramite Protobuf e cifrato con XOR — una scelta che garantisce compattezza e una certa difficoltà nell’ispezione del traffico.

Distribuzione geografica e target

La telemetria di Qianxin mostra che la distribuzione delle infezioni è geograficamente concentrata: Corea del Sud (48,5%), Cina (31,8%), Svezia (6,4%), Malesia (3,5%) e Singapore (2,5%). La forte prevalenza asiatica suggerisce che il deployment iniziale sia stato mirato su mercati dove i router D-Link di fascia bassa hanno avuto larga diffusione e dove la sostituzione dei dispositivi a fine vita avviene con ritardi.

Il targeting di NAS oltre ai router nella seconda fase dell’operazione indica un’evoluzione verso dispositivi con maggiore capacità di elaborazione e connettività persistente — ideali per operazioni di lunga durata che richiedono stabilità dell’infrastruttura proxy.

Perché AryStinger è diversa dalle botnet tradizionali

La distinzione fondamentale di AryStinger rispetto a botnet come Mirai o AISURU è l’obiettivo operativo: non DDoS né mining di criptovalute, bensì la costruzione di un’infrastruttura di intrusione distribuita. I dispositivi compromessi diventano nodi di una rete di proxy residenziali che conferiscono agli attaccanti un’anonimizzazione difficile da penetrare: il traffico malevolo emerge da indirizzi IP domestici o di piccola impresa, superando spesso i blocchi basati su reputazione IP.

Questo modello operativo è tipico di gruppi APT che necessitano di infrastrutture di staging durante la fase di ricognizione e di pivoting nelle reti bersaglio. La capacità di modificare le configurazioni DNS aggiunge una dimensione ulteriore: chi usa un router infetto espone tutte le proprie comunicazioni a potenziale intercettazione.

Indicatori di compromissione (IoC)

# IP di spreading iniziale
107.150.106.14
# Dominio C2 autenticazione
eixfi.ajb8.com  (/auth endpoint)
# CVE sfruttate
CVE-2013-3307   (D-Link DIR-850L - autenticazione bypassata)
CVE-2016-5681   (D-Link DIR-818LW - esecuzione remota di codice)
CVE-2025-11837  (dispositivi NAS - variante Go)
# Processi sospetti da verificare sul dispositivo
syswapd0h
syswapd0w
# Percorso da verificare
/tmp/bin/  (presenza di campioni malware)
# Nome progetto interno (da path nel codice Go)
Ary-Attack

Due righe per i difensori

Per chi gestisce reti con dispositivi edge, le azioni prioritarie sono: sostituire immediatamente i router D-Link DIR-850L e DIR-818LW con modelli supportati e aggiornati; applicare gli aggiornamenti firmware più recenti su tutti i dispositivi di rete perimetrali; modificare le credenziali amministrative di default; disabilitare le interfacce di gestione remota se non strettamente necessarie. A livello di monitoraggio, è opportuno inserire il dominio eixfi.ajb8.com e l’IP 107.150.106.14 nelle blocklist e verificare nei log di rete la presenza di connessioni Protobuf verso host sconosciuti su porte non standard.

La scoperta di AryStinger conferma una tendenza consolidata: i dispositivi IoT e i router SOHO a fine vita restano un vettore di attacco privilegiato per costruire infrastrutture di intrusione persistenti e difficili da attribuire. La prossima botnet potrebbe già essere nascosta nel router del vostro operatore ISP locale.

Spcnet.it

2026-06-22 17:03:03

Troubleshooting su Linux: il metodo sistematico in 4 passi che risolve il 99% degli errori

Chi lavora con Linux da anni conosce bene quella sensazione: un errore inaspettato blocca il server, un servizio smette di rispondere, un sistema che ieri funzionava perfettamente oggi presenta comportamenti anomali. La differenza tra un amministratore di sistema esperto e uno alle prime armi non sta tanto nella conoscenza enciclopedica dei comandi, quanto nell’adozione di un metodo sistematico di analisi.

In questo articolo descriviamo un approccio in quattro passi che consente di affrontare con metodo qualsiasi errore su Linux, riducendo drasticamente i tempi di risoluzione e gli errori per tentativi.

Il principio fondamentale: metodo prima di tutto

Il troubleshooting efficace non è una questione di fortuna o di esperienza accumulata a caso. È una disciplina che richiede di rallentare, osservare e procedere un passo alla volta. La tentazione più comune è quella di applicare subito la prima soluzione trovata online, modificando più variabili contemporaneamente. Questo approccio porta quasi sempre a peggiorare la situazione o, nella migliore delle ipotesi, a non capire quale modifica ha effettivamente risolto il problema.

Passo 1: raccogliere indizi e definire il problema con precisione

Il punto di partenza è una definizione precisa del problema. “Il server non funziona” è inutile ai fini diagnostici. “Il web server restituisce un 503 su /api/users dopo il deploy delle 14:30″ è un punto di partenza solido.

Le domande da porsi immediatamente sono:

• Quando si è manifestato il problema per la prima volta?
• Cosa è cambiato recentemente? (aggiornamento pacchetti, modifica configurazione, riavvio)
• Il problema è riproducibile? In quali condizioni?
• Qual è esattamente il messaggio di errore?

Un consiglio pratico spesso sottovalutato: se un’applicazione non si avvia correttamente, chiudete l’interfaccia grafica e lanciatela da terminale. La maggior parte delle applicazioni stampa i messaggi di errore sullo standard output o standard error, fornendo clue preziosi che l’interfaccia nasconde.

Catturate sempre l’output esatto dell’errore. Un kernel panic al boot, un prompt GRUB rescue, o un messaggio “device not found” contengono già le informazioni necessarie per risolvere il problema.

Passo 2: analizzare lo stato del sistema e i log

Con il problema definito, è il momento di esaminare lo stato corrente del sistema. Questa fase si divide in due parti: lo stato delle risorse e l’analisi dei log.

Stato delle risorse

Verificate se CPU, memoria, disco e rete sono in condizioni normali:

# CPU e memoria
top
htop

# Spazio disco
df -h
du -sh /var/log/* | sort -rh | head -20

# Rete
ip a
ip route
ping -c 4 8.8.8.8


Analisi dei log

Linux mette a disposizione strumenti potenti per l’analisi dei log. Con systemd, il comando principale è journalctl:

# Log del boot corrente con dettagli errori
journalctl -xb

# Log di un servizio specifico (es. nginx)
journalctl -u nginx --since "1 hour ago"

# Seguire i log in tempo reale
journalctl -f

# Filtrare solo gli errori
journalctl -p err -b


Per i sistemi che usano ancora i log tradizionali:

# Syslog generale
grep -i error /var/log/syslog | tail -50

# Log kernel
dmesg | grep -i "error\|fail\|warn" | tail -30

# Ricerca per intervallo temporale
journalctl --since "2026-06-22 14:00" --until "2026-06-22 15:00"


Non è necessario comprendere ogni singola riga dei log. L’obiettivo è identificare parole chiave come error, failed, segfault, permission denied, o il nome del servizio problematico nelle righe temporalmente vicine all’evento.

Passo 3: formulare ipotesi e testare una variabile alla volta

Con i dati raccolti nei passi precedenti, è il momento dell’analisi. Basandosi sui sintomi, sui cambiamenti recenti e sui log, si formula un’ipotesi sulla causa del problema.

Alcune regole pratiche:

• Un segmentation fault → sospettare corruzione della memoria o libreria incompatibile
• “Permission denied” → verificare permessi file, SELinux/AppArmor, ACL
• “Device not found” al boot → UUID del disco modificato dopo aggiornamento o sostituzione
• Servizio che crasha dopo un aggiornamento → provare il rollback del pacchetto

La regola d’oro è modificare una variabile alla volta. Se sospettate che un aggiornamento del pacchetto abbia causato il problema, fate il downgrade su un sistema di test prima di applicarlo in produzione. Questo permette di isolare la causa con certezza.

# Rollback di un pacchetto su Debian/Ubuntu
apt-cache showpkg nginx
apt-get install nginx=1.24.0-2

# Su RHEL/Rocky Linux
dnf downgrade nginx

# Verificare i file di configurazione con sintassi check
nginx -t
systemd-analyze verify /etc/systemd/system/myservice.service


La ricerca online è un validissimo alleato: incollare il messaggio di errore esatto in un motore di ricerca, nella documentazione ufficiale della distro, o in un AI assistant porta quasi sempre a soluzioni già documentate.

Passo 4: applicare la correzione e documentare

Una volta identificata la causa, applicare la correzione in modo controllato. Per le modifiche più invasive (sostituzione hardware, rebuild dell’initramfs, cambio configurazione kernel), è fondamentale:

• Eseguire uno snapshot del sistema prima di procedere
• Procedere un passo alla volta
• Verificare dopo ogni modifica che il problema sia risolto e che nulla si sia rotto

Il passo finale, spesso trascurato, è la documentazione. Annotare cosa è andato storto, quali log hanno fornito i clue decisivi, e come è stato risolto il problema. Un ticket nel sistema di ticketing, un post nel blog interno, o anche una semplice nota in un file di testo possono fare la differenza quando lo stesso problema si ripresenterà tra sei mesi.

Strumenti essenziali da padroneggiare

Per mettere in pratica questo metodo in modo efficace, vale la pena avere familiarità con questi strumenti:

# Monitoraggio risorse
htop, btop, atop, glances

# Analisi disco e I/O
iotop, iostat, lsblk, blkid, smartctl -a /dev/sda

# Rete
ss -tlnp, netstat -tlnp, tcpdump, traceroute, mtr

# File di sistema
strace -p , lsof -i, inotifywait

# Analisi log avanzata
grep, awk, sed, logwatch, fail2ban-client status

Conclusione

Il troubleshooting su Linux non è magia: è l’applicazione di un metodo. Raccogliere i dati, analizzare i log, formulare ipotesi e testarle una alla volta, applicare la correzione e documentare. Quattro passi che, se seguiti con disciplina, permettono di affrontare con sicurezza qualsiasi problema, dai più banali ai più complessi.

La vera competenza si costruisce nel tempo, attraverso l’accumulo di esperienze documentate. Ogni errore risolto correttamente è una voce nel vostro archivio personale di soluzioni.

---

Fonte originale: Linux Troubleshooting: These 4 Steps Will Fix 99% of Errors – LinuxBlog.io

Linux Troubleshooting: These 4 Steps Will Fix 99% of Errors | LinuxBlog.io

I’ll admit, I hesitated a bit before writing this post. The whole point of this linuxblog.io and linuxcommunity.io forum is to bring together like-minded

^{Hayden James (LinuxBlog.io)}