Spcnet.it

2026-08-18 13:29:09

Il filesystem /proc su Linux: la guida completa per il troubleshooting da sistemista

Ogni sistemista Linux, prima o poi, si trova davanti a una domanda che top o free non riescono a risolvere del tutto: perché questo processo consuma tanta memoria? Perché una porta risulta occupata ma netstat non mostra nulla? Perché un servizio continua a scrivere su un file che, in teoria, è stato cancellato? La risposta, quasi sempre, si trova in un posto che molti amministratori conoscono solo superficialmente: /proc.

/proc non è una directory come le altre. È un filesystem virtuale, di tipo procfs, generato e mantenuto interamente dal kernel in memoria: non un singolo byte dei suoi contenuti risiede su disco. È, di fatto, una finestra live sullo stato interno del kernel, esposta attraverso strumenti che ogni sistemista già conosce: cat, grep, awk. Comandi come free, ps, top e iostat non fanno altro che leggere e formattare i dati che /proc mette a disposizione: imparare a leggerlo direttamente significa avere accesso alle stesse informazioni, ma senza filtri, e con la possibilità di combinarle in modi che nessun tool preconfezionato offre.

La struttura: due mondi in una directory

/proc contiene sostanzialmente due categorie di contenuti. Da un lato le directory numerate, una per ogni processo in esecuzione (/proc/1234/, dove 1234 è il PID), che espongono lo stato specifico di quel processo. Dall’altro i file di sistema globali, come /proc/meminfo o /proc/cpuinfo, che riflettono lo stato del kernel nel suo complesso, indipendentemente da quale processo li legga.

I file di sistema che contano davvero

/proc/cpuinfo e /proc/stat

/proc/cpuinfo elenca i core logici della CPU con modello, velocità di clock, dimensione della cache e i flag di supporto per estensioni come vmx (virtualizzazione hardware), aes e avx2. Un one-liner molto usato per contare le CPU logiche disponibili è:

grep -c '^processor' /proc/cpuinfo

/proc/stat, invece, espone i contatori di tempo CPU aggregati e per singolo core, suddivisi in colonne: user, nice, system, idle, iowait, irq, softirq. Su un server sotto carico I/O-intensivo, tenere d’occhio la colonna iowait nel tempo è spesso più diagnostico di qualunque dashboard grafica, perché permette di isolare il momento esatto in cui la CPU comincia ad attendere lo storage invece di lavorare.

/proc/meminfo: oltre a “free”

/proc/meminfo è la fonte dati grezza dietro al comando free, ma contiene molti più campi di quelli che free mostra normalmente. Due meritano attenzione particolare: MemAvailable, che indica la memoria realmente disponibile per nuovi processi tenendo conto della cache riclamabile (a differenza di MemFree, che è quasi sempre un numero fuorviante), e Dirty, che riporta quanta memoria contiene dati modificati ancora in attesa di essere scritti su disco — un valore che cresce pericolosamente su sistemi con storage lento e scritture intense.

Per un monitoraggio in tempo reale della pressione di memoria, questo comando è estremamente utile in fase di troubleshooting:

watch -n1 'grep -E "MemAvailable|Dirty|Writeback|SwapFree" /proc/meminfo'

/proc/diskstats, /proc/loadavg, /proc/net/

/proc/diskstats fornisce le statistiche I/O per dispositivo — letture, scritture, settori trasferiti, tempo speso in operazioni — ed è la fonte dietro iostat. /proc/loadavg espone le tre celebri medie di carico a 1, 5 e 15 minuti, mentre /proc/uptime riporta i secondi trascorsi dal boot e il tempo cumulativo di inattività della CPU.

La sottodirectory /proc/net/ merita un capitolo a sé: /proc/net/dev contiene i contatori di byte e pacchetti per ogni interfaccia di rete, /proc/net/tcp e tcp6 elencano tutte le connessioni TCP attive in formato esadecimale, /proc/net/sockstat riassume l’utilizzo dei socket a livello di sistema, e /proc/net/snmp espone contatori SNMP utili per individuare retransmit e fallimenti di connessione anomali.

Il mondo per-processo: /proc/PID/

Qui si trova la parte più preziosa per il debugging quotidiano. Alcuni file chiave:

• /proc/PID/cmdline — il comando esatto con cui il processo è stato lanciato, con gli argomenti delimitati da byte null.
• /proc/PID/status — un riepilogo leggibile con UID, GID, utilizzo di memoria e numero di thread. Il campo VmRSS indica la memoria residente effettivamente occupata, mentre VmSwap segnala se (e quanto) il processo è finito in swap.
• /proc/PID/fd/ — una directory di symlink, uno per ogni file descriptor aperto dal processo. È la base dati su cui si appoggia lsof. Contare i descrittori aperti è semplice: ls /proc/12345/fd | wc -l.
• /proc/PID/io — la contabilità I/O del processo, con read_bytes e write_bytes che riflettono i dati effettivamente passati al layer di storage.
• /proc/PID/maps e /proc/PID/smaps — le regioni di memoria mappate dal processo (codice, stack, heap, librerie condivise). smaps va oltre e fornisce, per ogni regione, i dettagli su RSS, PSS e swap.
• /proc/PID/environ — le variabili d’ambiente al momento del lancio, anch’esse delimitate da byte null.
• /proc/PID/cwd e /proc/PID/exe — symlink rispettivamente alla directory di lavoro corrente e all’eseguibile su disco. Sono fondamentali per identificare binari che sono stati cancellati o sostituiti mentre il processo era ancora in esecuzione (un classico segnale da cercare dopo un aggiornamento di sicurezza mal gestito).
• /proc/PID/oom_score e oom_score_adj — il punteggio che l’OOM killer del kernel usa per decidere quale processo terminare per primo in caso di esaurimento memoria. oom_score_adj, con un range da -1000 a 1000, permette di proteggere o “sacrificare” volontariamente un processo specifico.

Due scorciatoie tornano utili spesso: /proc/self/ punta sempre al processo che sta effettuando la lettura, mentre /proc/$$/ punta alla shell corrente all’interno di uno script.

Casi pratici di troubleshooting

Trovare quale processo ha in ascolto una determinata porta (qui la porta 443/0x01BB su IPv6), senza usare ss o lsof:

inode=$(awk '$2 ~ /:01BB$/ {print $10; exit}' /proc/net/tcp6)
ls -l /proc/*/fd/ 2>/dev/null | grep "socket:[$inode]"

Individuare processi che tengono aperti file già cancellati — una causa classica di dischi che risultano pieni pur senza file visibili, perché lo spazio non viene liberato finché il file descriptor resta aperto:

find /proc/*/fd -ls 2>/dev/null | grep '(deleted)'

Ispezionare i contatori di interrupt per CPU, utile per diagnosticare squilibri di IRQ affinity su macchine multi-core:

cat /proc/interrupts | head -20

/proc/sys e il tuning via sysctl

Sotto /proc/sys/ si trovano i file scrivibili che espongono i tunable del kernel — la stessa interfaccia usata da sysctl. Ad esempio, per modificare a caldo la propensione del kernel allo swap:

echo 10 | sudo tee /proc/sys/vm/swappiness

Tra i tunable più comuni: vm.swappiness (0-200, propensione allo swap), net.ipv4.ip_forward (abilitazione dell’IP forwarding), net.core.somaxconn (backlog massimo per i socket in ascolto) e fs.file-max (limite di file descriptor a livello di sistema). Ricordiamo che le modifiche fatte così sono volatili: per renderle permanenti serve intervenire su /etc/sysctl.conf o su un file in /etc/sysctl.d/.

/proc dentro i container

Un punto che genera spesso confusione: /proc è namespace-aware. Dentro un container Docker, la directory mostra il namespace PID del container, non quello dell’host — il PID 1 visto dall’interno è l’entrypoint del container, non l’init dell’host. Attenzione però: campi come quelli di /proc/meminfo o /proc/stat spesso riflettono ancora i totali dell’host e non i limiti imposti dai cgroup al container, un dettaglio che ha tratto in inganno più di un tool di monitoring scritto ingenuamente.

/proc contro /sys: quando usare cosa

/sys (sysfs) è il filesystem virtuale complementare a /proc, ma orientato al modello dei dispositivi del kernel: driver, bus, block device, gestione dell’energia. Un esempio tipico è /sys/devices/system/cpu/cpu0/cpufreq/, che espone i parametri di scaling della frequenza per singolo core. La regola pratica: /proc per processi e stato del kernel a livello di sistema, /sys per configurazione e stato dei dispositivi hardware.

Conclusione

Conoscere /proc non è un esercizio accademico: è uno degli strumenti diagnostici più potenti a disposizione di un sistemista Linux, proprio perché sta sotto ogni tool di monitoring che si finisce per usare quotidianamente. Quando top, free o netstat non bastano — o semplicemente non sono installati sulla macchina compromessa o minimale su cui ci si trova a lavorare — sapere leggere direttamente /proc/meminfo, /proc/PID/status o /proc/net/tcp fa la differenza tra un troubleshooting rapido e ore perse a indovinare. Vale la pena tenere a portata di mano, come riferimento minimo, i file /proc/meminfo, /proc/cpuinfo, /proc/stat, /proc/net/dev e la struttura di /proc/PID/: coprono la stragrande maggioranza dei casi reali di debugging su sistemi in produzione.

Fonte originale: A Guide to Linux /proc Filesystem, LinuxBlog.io

A Guide to Linux /proc Filesystem | LinuxBlog.io

The /proc filesystem is a live window into the Linux kernel: process state, memory layout, CPU counters, network stats, and writable kernel tunables, all accessible with nothing but cat and grep.

^{Hayden James (LinuxBlog.io)}

Spcnet.it

2026-08-18 13:29:06

Crittografia post-quantistica: perché il threat modeling non può più aspettare (con esempi in .NET 10)

C’è una minaccia alla crittografia moderna che non richiede un computer quantistico funzionante oggi per essere reale oggi: si chiama “harvest now, decrypt later” (raccogli ora, decifra dopo). Un attaccante con risorse sufficienti — uno stato-nazione, tipicamente — può intercettare e archiviare traffico cifrato con RSA o ECC adesso, per poi decifrarlo tra qualche anno, quando computer quantistici sufficientemente potenti saranno disponibili. Per dati con un ciclo di vita lungo — segreti industriali, cartelle cliniche, comunicazioni diplomatiche, chiavi di firma di lungo periodo — la finestra di esposizione è già aperta, anche se il computer quantistico “rompi-RSA” non esiste ancora.

È in questo contesto che Microsoft ha recentemente pubblicato una guida al threat modeling applicato specificamente alla migrazione verso la crittografia post-quantistica (PQC), invitando organizzazioni e team di sviluppo a non aspettare la disponibilità degli algoritmi per cominciare a muoversi.

Perché serve il threat modeling, e non solo un elenco di algoritmi

Il problema centrale che Microsoft evidenzia non è tecnico in senso stretto, è organizzativo: la maggior parte delle aziende non ha un inventario completo di dove e come viene usata la crittografia nei propri sistemi. Certificati TLS, librerie di firma incorporate in applicazioni legacy, hardware embedded con chiavi hard-coded, protocolli proprietari che usano RSA “perché si è sempre fatto così” — sono tutte dipendenze crittografiche nascoste che un aggiornamento generico non intercetta.

Il threat modeling applicato alla PQC serve esattamente a questo: mappare asset, flussi di dati, confini di fiducia (trust boundary) e controlli di sicurezza esistenti per far emergere queste dipendenze prima che diventino un problema urgente sotto pressione regolatoria o, peggio, sotto attacco. Concretamente, significa rispondere a domande come: quali sistemi cifrano dati che devono restare confidenziali per più di 5-10 anni? Quali certificati di firma del codice hanno una validità che si estende oltre il 2030? Quali protocolli interni non supportano l’agilità crittografica, cioè non permettono di sostituire un algoritmo senza riscrivere l’applicazione?

Gli algoritmi: da NIST a nomi che iniziano a essere familiari

Dopo anni di standardizzazione, il NIST ha pubblicato tre standard che è ormai il momento di conoscere, perché stanno entrando nei prodotti che usiamo quotidianamente:

• ML-KEM (Module-Lattice Key Encapsulation Mechanism, FIPS 203) — sostituisce lo scambio di chiavi basato su RSA o curve ellittiche (ECDH). È l’algoritmo che entra in gioco nell’handshake TLS per stabilire un segreto condiviso.
• ML-DSA (Module-Lattice Digital Signature Algorithm, FIPS 204) — l’algoritmo di firma digitale post-quantistico, pensato come sostituto di RSA e ECDSA per firmare certificati, codice e messaggi.
• SLH-DSA (Stateless Hash-Based Digital Signature Algorithm, FIPS 205) — un algoritmo di firma alternativo, basato su funzioni hash anziché su reticoli, pensato come backup conservativo nel caso in cui in futuro emergano debolezze crittanalitiche nei problemi su reticolo.

Sul fronte delle raccomandazioni pratiche, Microsoft insiste su un punto spesso sottovalutato: la migrazione a TLS 1.3 è il prerequisito, non un dettaglio. TLS 1.2 non supporta i meccanismi ibridi necessari per introdurre ML-KEM accanto agli algoritmi classici, e restare su TLS 1.2 significa restare bloccati fuori dalla transizione PQC anche quando gli algoritmi saranno pronti. In parallelo, si consiglia di alzare l’asticella anche sulla crittografia simmetrica e sulle funzioni hash, adottando AES-256 e SHA-384 come standard, per mantenere margini di sicurezza adeguati anche in scenari quantistici (dove alcuni attacchi, come Grover, dimezzano di fatto la sicurezza effettiva degli algoritmi simmetrici).

La timeline che Microsoft si è data per la transizione dei propri prodotti e servizi critici è il 2029 — una data che vale la pena tenere a mente come riferimento di settore, anche per pianificare le proprie migrazioni interne con lo stesso ordine di grandezza.

Cosa c’è già oggi: le API disponibili

La parte più interessante per chi scrive codice è che la PQC non è più solo teoria da paper accademico: le API sono già disponibili e generalmente disponibili (GA) sulle piattaforme Microsoft.

Windows: CNG

Su Windows, il supporto arriva a livello di CNG (Cryptography API: Next Generation), con identificatori di algoritmo dedicati per ML-KEM e ML-DSA utilizzabili tramite le funzioni BCryptGenerateKeyPair e le relative API di key exchange e firma. Il supporto nativo è arrivato a partire da Windows 11 con gli aggiornamenti di novembre 2025: chi gestisce flotte Windows dovrebbe verificare di essere allineato con le patch più recenti prima di pianificare qualunque test.

.NET 10: MLKem e MLDsa in System.Security.Cryptography

Per chi sviluppa in C#, la notizia più concreta è l’arrivo delle classi MLKem e MLDsa direttamente in System.Security.Cryptography con .NET 10. Ecco un esempio minimo di key encapsulation:

using System.Security.Cryptography;

if (!MLKem.IsSupported)
{
    Console.WriteLine("ML-KEM non è supportato su questa piattaforma");
    return;
}

MLKemAlgorithm alg = MLKemAlgorithm.MLKem768;

using (MLKem privateKey = MLKem.GenerateKey(alg))
using (MLKem publicKey = MLKem.ImportEncapsulationKey(
    alg, privateKey.ExportEncapsulationKey()))
{
    publicKey.Encapsulate(out byte[] ciphertext, out byte[] sharedSecret1);
    byte[] sharedSecret2 = privateKey.Decapsulate(ciphertext);

    bool match = sharedSecret1.AsSpan().SequenceEqual(sharedSecret2);
    Console.WriteLine($"I segreti condivisi coincidono: {match}");
}

E un esempio di firma con ML-DSA:

MLDsaAlgorithm alg = MLDsaAlgorithm.MLDsa65;

using (MLDsa key = MLDsa.GenerateKey(alg))
{
    byte[] data = "Messaggio da firmare"u8.ToArray();
    byte[] signature = new byte[alg.SignatureSizeInBytes];

    key.SignData(data, signature);
    bool verified = key.VerifyData(data, signature);

    Console.WriteLine($"Firma verificata: {verified}");
}

Entrambe le famiglie di algoritmi sono disponibili in più varianti — MLKem512, MLKem768, MLKem1024 per il key encapsulation, e MLDsa44, MLDsa65, MLDsa87 per la firma — con un compromesso crescente tra sicurezza e dimensione delle chiavi. Ad esempio, per MLDsa65 la chiave pubblica occupa 1952 byte, quella privata 4032 byte e la firma 3309 byte: numeri sensibilmente più grandi rispetto a ECDSA, un dettaglio da tenere presente quando si progettano protocolli o formati di messaggio con vincoli di banda o storage.

Un paio di note pratiche per chi vuole sperimentare da subito: su Linux serve OpenSSL 3.5 o superiore, mentre chi è ancora su .NET Standard 2.0 può accedere alle stesse API tramite il pacchetto NuGet Microsoft.Bcl.Cryptography. Per il supporto lato TLS 1.3, certificati basati su ML-DSA e SLH-DSA funzionano già in scenari di autenticazione quando sia il sistema operativo sia la controparte della connessione supportano i nuovi algoritmi — un altro motivo per cui la coordinazione tra client e server nella transizione non è opzionale.

Da dove cominciare, in pratica

Per un team che affronta questo tema per la prima volta, un percorso ragionevole è: primo, effettuare un inventario reale di certificati, librerie crittografiche e protocolli in uso, distinguendo per criticità e durata di vita dei dati protetti; secondo, verificare che l’infrastruttura TLS sia già su 1.3 ovunque possibile, perché è il prerequisito tecnico per tutto il resto; terzo, iniziare a sperimentare le nuove API — su .NET 10 il costo di ingresso è basso, si tratta di poche righe di codice — in ambienti non di produzione, per capire l’impatto su dimensioni di chiavi, firme e tempi di calcolo prima che diventi un requisito con scadenza stretta.

La crittografia post-quantistica non è ancora un’emergenza operativa per la maggior parte delle organizzazioni, ma il messaggio di Microsoft è chiaro: il momento di mappare le proprie dipendenze crittografiche e cominciare a testare gli algoritmi è adesso, non quando arriverà l’obbligo normativo o il primo incidente.

Fonte originale: Microsoft Urges Threat Modeling to Prepare for Post-Quantum Cryptography Migration, Petri IT Knowledgebase

Microsoft Details Steps for Post-Quantum Cryptography Adoption

Microsoft is encouraging organizations to use threat modeling to prepare for post-quantum cryptography migration.

^{Rabia Noureen (Petri IT Knowledgebase)}

(in)sicurezza digitale

2026-08-18 13:13:37

DragonDoll: lo spyware Android che si finge un aggiornamento Chrome e legge Telegram, WhatsApp e Signal in 26 Paesi

Si parla di:
Toggle

Una pagina che imita alla perfezione la schermata di aggiornamento di Google Chrome, un dropper che scarica il payload reale solo dopo, e un abuso sistematico dei servizi di accessibilità Android per leggere in tempo reale le chat di Telegram, WhatsApp e Signal senza mai toccare la loro crittografia end-to-end. È DragonDoll, lo spyware commerciale che il Positive Technologies Expert Security Center (PT ESC) ha tracciato in almeno 26 Paesi, Russia inclusa, con circa 150 campioni caricati in appena due mesi su un repository GitHub pubblico.

Un finto aggiornamento, un dropper vero

La catena d’infezione comincia con un APK che si spaccia per “Chrome.apk” e adotta la tecnica dei tampered headers per ostacolare gli strumenti di analisi statica. Una volta installato, il file mostra una pagina-esca che riproduce fedelmente il branding di un aggiornamento ufficiale di Google Chrome, convincendo l’utente a proseguire con l’installazione. Solo a questo punto il dropper scarica ed esegue il payload reale, denominato internamente K3iwv7VF.apk, decifrato con AES-256-GCM tramite implementazione nativa (libreria compilata in C/C++, non in Java/Kotlin), un’ulteriore misura anti-analisi rispetto ai più comuni spyware Android scritti interamente in linguaggio gestito.

Il vero motore: l’abuso dell’AccessibilityService

DragonDoll non sfrutta exploit del kernel o vulnerabilità 0-day: si affida quasi interamente all’AccessibilityService di Android, l’API pensata per rendere il sistema operativo utilizzabile da persone con disabilità visive. Una volta ottenuto il permesso — spesso concesso dalla vittima stessa, ingannata dalla schermata di richiesta mascherata da parte del sistema — lo spyware può:

• Intercettare tap, gesture e input da tastiera in tempo reale su qualsiasi app in primo piano.
• Leggere il contenuto delle notifiche, incluse quelle di Telegram (liste chat, contatti, testo dei messaggi e timestamp) man mano che arrivano, senza dover violare la cifratura del protocollo.
• Monitorare visivamente lo schermo durante l’uso di WhatsApp e Signal, catturando ciò che compare a video anche quando l’app stessa è protetta da crittografia end-to-end.
• Iniettare overlay fasulli sopra app bancarie per sottrarre credenziali (banking overlay injection), una tecnica presa in prestito dai trojan bancari Android più maturi.
• Raccogliere contatti, SMS, log delle chiamate, screenshot, stato di batteria/Wi-Fi/USB/SIM, IMEI e la lista completa delle app installate.

Per app meno “prioritarie” come Viber, il malware si limita a una raccolta più semplice dei dati visibili a schermo, segno di uno sviluppo modulare e mirato piuttosto che di un tool generico riadattato.

Una campagna globale, con targeting linguistico chirurgico

PT ESC ha individuato la campagna per la prima volta nella primavera 2026, durante l’analisi di attacchi contro utenti in Arabia Saudita, per poi scoprire un’infrastruttura di distribuzione molto più ampia: oltre 26 Paesi colpiti, tra cui Russia, Cina, Corea del Sud e diversi Stati dell’area MENA, con il malware localizzato in 34 lingue di interfaccia. Tra il 6 marzo e il 6 maggio 2026 sono stati caricati circa 150 campioni unici su un account GitHub (kesmanta24, registrato con l’indirizzo kesmantes52@outlook.com), arrivati almeno alle versioni 9.3 e 9.4 — un ritmo di sviluppo che tradisce un progetto attivamente mantenuto e monetizzato, non un esperimento estemporaneo.

L’infrastruttura di comando e controllo si appoggia al dominio channelzones[.]co, ospitato su hosting russo, con canali di comunicazione bidirezionale basati su Socket.IO e autenticazione tramite OkHttp3; la cifratura del traffico combina AES-256-CBC e RSA OAEP in uno schema ibrido. La distribuzione iniziale avviene tramite domini civetta come datewithmealways[.]site, datewithmealways[.]online e digitaladstracking[.]com, pensati per superare filtri di reputazione e ingannare l’utente con nomi apparentemente innocui o a tema dating/advertising.

Perché conta: il mercato in espansione dello spyware commerciale Android

DragonDoll si inserisce in un trend che i ricercatori osservano da tempo: la proliferazione di famiglie spyware Android vendute o distribuite su scala industriale, capaci di aggirare la crittografia end-to-end di app come Signal e WhatsApp non attaccando il protocollo, ma il dispositivo stesso attraverso funzioni di sistema legittime come l’accessibilità. È lo stesso principio dietro altre famiglie recenti individuate mascherate da versioni “clonate” di Telegram e Signal distribuite anche tramite store ufficiali, un problema che ha spinto più volte Google a rafforzare i controlli su Play Protect senza però eliminare il rischio quando l’installazione avviene tramite sideloading da pagine web esterne, come nel caso di DragonDoll.

La presenza della Russia tra i Paesi bersaglio, insieme a un’infrastruttura C2 ospitata proprio su hosting russo, è un dettaglio che PT ESC segnala senza sciogliere del tutto l’ambiguità sull’attribuzione: non è chiaro se si tratti di un operatore locale che colpisce anche il proprio mercato interno, di un tool venduto a più clienti con targeting indipendente, o di un’operazione di sorveglianza mirata mascherata da campagna commerciale opportunistica.

Come proteggersi

• Non installare mai aggiornamenti di Chrome (o di qualsiasi altra app) da pagine web esterne al Google Play Store: gli aggiornamenti legittimi non vengono mai proposti così.
• Verificare periodicamente in Impostazioni → Accessibilità quali app hanno permessi attivi e revocarli per tutto ciò che non sia uno strumento di assistenza riconosciuto.
• Diffidare di APK scaricati da domini a tema dating, advertising o “aggiornamento urgente”, tipici vettori di distribuzione di questa famiglia.
• Su dispositivi aziendali o ad alto rischio, disabilitare il sideloading e imporre policy MDM che blocchino l’installazione da fonti sconosciute.
• Monitorare traffico di rete verso i domini e l’infrastruttura elencati di seguito come indicatori di compromissione.

Indicatori di compromissione

# Infrastruttura C2 e distribuzione
channelzones[.]co                 (C2 primario, hosting russo, canale Socket.IO)
datewithmealways[.]site           (dominio di distribuzione)
datewithmealways[.]online         (dominio di distribuzione)
digitaladstracking[.]com          (dominio di distribuzione)

# Account di sviluppo
GitHub user: kesmanta24
Email associata: kesmantes52@outlook.com
Periodo attivita': 6 marzo - 6 maggio 2026 (~150 campioni, versioni 9.3-9.4)

# Nomi file osservati
Chrome.apk        (dropper iniziale, tampered headers)
K3iwv7VF.apk       (payload finale, AES-256-GCM nativo)

# Paesi colpiti (parziale)
Arabia Saudita, Russia, Cina, Corea del Sud, area MENA (26+ Paesi totali)
Localizzazione: 34 lingue di interfaccia

# Cifratura
Dropper -> payload: AES-256-GCM (nativo)
C2: AES-256-CBC + RSA OAEP (ibrido), autenticazione OkHttp3, canale Socket.IO

Fonte primaria: Positive Technologies Expert Security Center (PT ESC). Dettagli tecnici e IoC aggiornati al momento della pubblicazione; per l’elenco completo di hash e domini si rimanda al report integrale dei ricercatori.

netzpolitik.org

2026-08-18 09:14:54

Würde die AfD ein Bundesland regieren, hätte sie eine Reihe von Möglichkeiten, den Sicherheitsapparat in ihrem Sinne neu auszurichten. Doch Demokrat*innen stehen dem nicht hilflos gegenüber. Wir haben mit dem Rechtswissenschaftler Markus Thiel darüber gesprochen, welche Gefahren eine potenzielle Machtübernahme birgt und was man dagegen tun kann. netzpolitik.org/2026/polizei-u…

Was bei einer Machtübernahme durch Rechtsextreme droht

^{Anna Biselli (netzpolitik.org)}

netzpolitik.org

2026-08-17 14:22:54

„Direkt aus dem Roman 1984“: Das neue Polizeigesetz von Schleswig-Holstein soll eines der härtesten Deutschlands werden. Die Gruppe @freiheitsfoo analysiert es in einem 22seitigen Gutachten. Ihr Ergebnis: Der Entwurf ist eine Bedrohung für die Demokratie. netzpolitik.org/2026/polizeige…

„Direkt aus dem Roman 1984“

Das neue Polizeigesetz von Schleswig-Holstein soll eines der härtesten Deutschlands werden. Die Gruppe Freiheitsfoo analysiert es in einem 22seitigen Gutachten. Ihr Ergebnis: Der Entwurf ist eine Bedrohung für die Demokratie.

^{Martin Schwarzbeck (netzpolitik.org)}

(in)sicurezza digitale

2026-08-17 13:56:30

CVSS 10 senza PoC pubblico: la corsa contro il tempo sulla falla critica di SAP Commerce Cloud

Si parla di:
Toggle

SAP ha rilasciato la patch l’11 agosto. Tre giorni dopo, gli honeypot dell’azienda di threat intelligence Defused hanno registrato i primi tentativi di sfruttamento. Nessun proof-of-concept pubblico, nessun writeup tecnico in circolazione: qualcuno ha fatto reverse engineering della patch – o conosceva già la falla – più in fretta di quanto la community difensiva riuscisse a reagire. La vulnerabilità, CVE-2026-58231, ha un CVSS di 10.0: il massimo possibile, per una piattaforma usata da alcuni dei più grandi retailer al mondo.

La falla: un client di autenticazione dimenticato

CVE-2026-58231 risiede nell’estensione Data Hub Adapter di SAP Commerce Cloud, la piattaforma e-commerce nota fino a pochi anni fa come SAP Hybris. Secondo l’advisory ufficiale, controlli di autorizzazione insufficienti e una validazione dell’input carente permettono a un attaccante non autenticato di “abusare di un client di autenticazione predefinito” e sottoporre input appositamente costruiti al sistema. Il risultato è esecuzione di codice arbitraria in remoto (RCE), raggiungibile con complessità di attacco bassa e senza alcuna credenziale: la combinazione che giustifica il punteggio massimo di gravità.

SAP Commerce Cloud non è un prodotto di nicchia: è l’infrastruttura e-commerce dietro cataloghi, checkout e gestione ordini di catene retail, produttori e distributori a livello globale. Una RCE non autenticata su questo layer significa accesso diretto a dati di pagamento, anagrafiche clienti e, potenzialmente, un punto di ingresso verso i sistemi ERP interni a cui Commerce Cloud è tipicamente integrato.

Tre giorni: dalla patch al primo probe

La finestra temporale è ciò che rende questo caso degno di nota. SAP ha pubblicato la correzione l’11 agosto 2026 tramite la security note 3771065. Il 14 agosto, Defused ha osservato sui propri sensori i primi tentativi di exploitation, comunicandolo pubblicamente su X. Shadowserver Foundation, che traccia costantemente l’esposizione internet di SAP Commerce Cloud tramite fingerprinting, segnala oltre 4.200 indirizzi IP con firma compatibile con la piattaforma – la superficie di attacco potenziale su cui gli scanner automatizzati si stanno già muovendo.

Tre giorni sono un tempo sufficiente per un diffing accurato della patch (confrontando i binari o i sorgenti pre e post correzione per isolare il codice modificato e dedurre la vulnerabilità), ma insolitamente rapido per la complessità tipica delle applicazioni enterprise Java di SAP. Onapsis, società specializzata nella sicurezza degli ambienti SAP, non esclude che gli attaccanti stiano semplicemente testando in massa endpoint esposti sperando di trovare installazioni non ancora patchate, un pattern comune subito dopo il rilascio di patch critiche per software enterprise molto diffuso.

Il precedente che preoccupa i difensori

SAP Commerce Cloud e le altre piattaforme della galassia SAP non sono nuove a questo tipo di attenzione. Nel maggio 2025, la vulnerabilità gemella CVE-2025-31324 in SAP NetWeaver Visual Composer fu sfruttata da almeno un cluster di attività riconducibile a operazioni di cyberspionaggio cinesi per compromettere oltre 580 sistemi critici a livello globale, secondo l’analisi di EclecticIQ, prima che gruppi ransomware si aggiungessero alla caccia agli endpoint non patchati. Lo schema si ripete con regolarità: le vulnerabilità critiche nei sistemi SAP attirano prima attori sofisticati orientati all’intelligence, interessati all’accesso silenzioso a dati finanziari e di supply chain, e solo in un secondo momento la criminalità informatica opportunistica in cerca di un punto d’appoggio da rivendere o da usare per il deployment di ransomware.

Per ora non ci sono attribuzioni pubbliche legate ai probe osservati su CVE-2026-58231: i dati disponibili derivano da honeypot e da telemetria di scansione, non da un’intrusione confermata con post-exploitation osservata. Ma la storia recente di SAP suggerisce che la finestra tra probe automatizzati e sfruttamento mirato da parte di attori più sofisticati tende a essere breve.

Cosa devono fare i team di sicurezza

• Applicare immediatamente la security note SAP 3771065, aggiornando ai livelli di patch corretti per Commerce Cloud
• Dove l’aggiornamento immediato non è possibile, ricompilare e ridistribuire la versione corretta appena disponibile una finestra di manutenzione
• Come mitigazione temporanea, configurare un IP Filter Set per limitare l’accesso all’endpoint del Data Hub Adapter alle sole reti fidate
• Verificare nei log applicativi richieste anomale dirette agli endpoint di Data Hub Adapter nei giorni successivi all’11 agosto
• Monitorare gli avvisi di Shadowserver e della propria threat intelligence per indicatori di scansione mirata verso il proprio range IP
• Trattare qualsiasi istanza Commerce Cloud esposta a Internet e non patchata come potenzialmente già compromessa, avviando attività di hunting sui sistemi integrati (ERP, data warehouse, gateway di pagamento)

Il messaggio per chi gestisce ambienti SAP è lo stesso che si ripete a ogni ciclo di patch critiche in software enterprise molto esposto: il tempo tra il rilascio di una correzione e la sua trasformazione in arma da parte degli attaccanti si sta comprimendo, e in questo caso specifico non c’è stato nemmeno bisogno di un proof-of-concept pubblico per accorciarlo ulteriormente.

Dettagli tecnici

# Vulnerabilità
CVE-2026-58231
CVSS 3.1: 10.0 (Critico)
Componente: SAP Commerce Cloud - estensione Data Hub Adapter
Tipo: Autorizzazione impropria + input validation carente -> RCE non autenticata

# Timeline
2026-08-11  Rilascio patch (SAP Security Note 3771065)
2026-08-14  Primi tentativi di exploitation osservati (Defused, honeypot)
2026-08-17  Oltre 4.200 IP con fingerprint SAP Commerce Cloud tracciati da Shadowserver

# Mitigazione
- Applicare Security Note 3771065
- IP Filter Set sull'endpoint Data Hub Adapter come workaround temporaneo

# Precedente correlato
CVE-2025-31324 - SAP NetWeaver Visual Composer, sfruttata da cluster
di cyberspionaggio cinesi su 580+ sistemi critici (maggio 2025)

Fonti: The Hacker News, BleepingComputer, SecurityAffairs, GBHackers, Onapsis, Shadowserver Foundation, EclecticIQ.