upx

The JadePuffer autonomous AI agent has upgraded with custom malware called EncForge that focuses on encrypting AI assets, such as training datasets, vector databases, and model checkpoints. JadePuffer was disclosed earlier this month as an agentic threat actor (ATA) capable of running autonomously through the stages of a ransomware attack, from initial access to data encryption. Cloud security company Sysdig says that the AI agent adapted to technical difficulties in real time and optimized the intrusion mechanism to find the correct fix in less than a minute. Latest attack In a report today, Sysdig says that the attacker returned to the previously breached Langflow instance vulnerable to CVE-2025-3248 with the Go-based EncForge ransomware "built specifically for AI and machine learning (ML) infrastructure." "The binary targets approximately 180 file extensions, with a deliberately broad sweep of the modern AI/ML stack, including model checkpoints, vector databases, training datasets, and embedding indices in nearly every current format," Sysdig says. After gaining access and searching for cloud credentials, API tokens, and reachable internal services, the threat actor discovered an exposed Docker socket that provided root-level control. When the initial attempt to download the ransomware payload failed, the operator iteratively developed and deployed six Python scripts over just five minutes, with the final one (deploy.py v2) solving the delivery issues. “deploy.py v2 is the completed payload: a fully autonomous pipeline that discovers the target PID, copies ENCFORGE across the namespace boundary via procfs, runs a try-mode scan, launches the live encryption pass, and then counts .locked files to verify execution,” Sysdig explained. EncForce ransomware The Go-based binary (lockd) is packed using the Ultimate Packer for eXecutables (UPX) that targets 180 file extensions, including: AI model checkpoints Hugging Face SafeTensors files PyTorch and TensorFlow models GGUF and GGML weights FAISS vector indexes Training datasets, including Parquet, Arrow, TFRecord, NumPy, and DuckDB formats Its command-line help also uses LoRA adapters and legacy GGML files as examples of additional targets, which Sysdig sees as evidence that the ransomware was deliberately built for AI environments rather than a generic file encryptor. EncForce uses the AES-256 algorithm in counter mode to encrypt files in a hybrid scheme, where the symmetric key is secured with an RSA-2048 public key. To improve performance, the malware encrypts only selected portions of each file rather than the entire contents. Encrypted files are appended with the .locked extension, and a ransom note is dropped to notify the victim of the attack, stating that a unique identifier has been assigned. The researchers found no evidence that JadePuffer exfiltrated any data during the intrusion, and EncForge itself does not appear to include a data-stealing mechanism. Analysis of the Linux variant revealed the presence of Windows anti-recovery functions such as shadow copy deletion and boot recovery disabling. A macOS version, although hinted in the code, remains unconfirmed. Sysdig comments that encryption of model weights, training datasets, and vector indexes could cost organizations weeks or even months of training and fine-tuning, with financial damages estimated between $75,000 and $500,000 per model, depending on its size and purpose. Defense suggestions include applying available security updates, most notably Langflow version 1.3.0 or later, restricting Docket socket access, running Langflow containers as non-root, and applying filesystem-level access controls to model weight directories. Overall prevention scores can hide what happens after initial access. Once attackers are using valid credentials, prevention drops sharply. The Blue Report 2026 measures defenses technique by technique across 338 million simulations run in customer production environments. Get the report

A zero-day vulnerability in Dell’s RecoverPoint for Virtual Machines product has been exploited by a China-linked cyberespionage group since at least mid-2024, Google’s Threat Intelligence Group (GTIG) and Mandiant reported on Tuesday. Exploitation of the vulnerability identified as CVE-2026-22769 has been attributed by GTIG and Mandiant to a threat actor tracked as UNC6201. The hackers exploited the flaw for lateral movement, persistence, and malware deployment. Dell RecoverPoint for Virtual Machines, part of the vendor’s data protection offering, provides resilience and disaster recovery functionality for VMware VMs. According to Dell’s advisory for CVE-2026-22769, the vulnerability is a hardcoded credential issue affecting RecoverPoint for Virtual Machines versions prior to 6.0.3.1 HF1. The tech giant has advised users to update their installations to the patched version as soon as possible. “[CVE-2026-22769] is considered critical as an unauthenticated remote attacker with knowledge of the hardcoded credential could potentially exploit this vulnerability leading to unauthorized access to the underlying operating system and root-level persistence,” Dell said. This appears to be the first public mention of the threat group UNC6201, but Google pointed out that it has found links to UNC5221, a China-nexus APT known for dwelling in compromised networks for hundreds of days to obtain valuable information. Google previously detailed UNC5221’s use of the BrickStorm malware. In a September 2025 report the company noted that the threat group may have used some of the stolen information to identify zero-day vulnerabilities in enterprise technologies. It’s unclear if CVE-2026-22769 may be one of those zero-days. In its new report, Google revealed that the newly documented group, UNC6201, had also used the BrickStorm malware, but in September 2025 it started replacing it with a new piece of malware named GrimBolt. GrimBolt is a backdoor developed in C# that is compiled using native ahead-of-time (AOT) compilation and packed with UPX, which makes it more difficult to analyze. The malware provides remote shell capabilities. “It’s unclear if the threat actor’s replacement of BrickStorm with GrimBolt was part of a pre-planned life cycle iteration by the threat actor or a reaction to incident response efforts led by Mandiant and other industry partners,” GTIG and Mandiant said. Both GrimBolt and BrickStorm were deployed on systems running Dell RecoverPoint for Virtual Machines. The initial access method has yet to be confirmed, but one likely vector is edge appliances. In addition to GrimBolt and BrickStorm, the attacks exploiting CVE-2026-22769 involved the deployment of a web shell named SlayStyle. Google researchers also discovered that UNC6201 created ‘ghost NICs’ on VMs. After carrying out their malicious activities, the threat actors deleted the NICs, making the attack stealthier and more difficult to investigate. Mandiant CTO Charles Carmakal noted in a LinkedIn post that “nation-state threat actors continue targeting systems that don’t commonly support EDR solutions, which makes it very hard for victim organizations to know they are compromised and significantly prolongs intrusion dwell times.” GTIG and Mandiant have made available indicators of compromise (IoCs) to help defenders detect potential attacks. Related: China Revives Tianfu Cup Hacking Contest Under Increased Secrecy Related: Notepad++ Supply Chain Hack Conducted by China via Hosting Provider

Questo articolo è il primo di una serie dedicata all’analisi malware, un percorso dedicato che possa permetterti di apprendere le basi di questa disciplina. In questo primo articolo, ci concentriamo sull’analisi statica di base di un file ELF a 64 bit. ELF (Executable and Linkable Format) è il formato standard per i programmi eseguibili su Linux, l’equivalente di un file .exe su Windows. Questo genere di file contiene il codice macchina del programma e le istruzioni per il sistema operativo su come caricarlo in memoria ed eseguirlo correttamente. Oltre ai programmi, il formato ELF è usato anche per le librerie condivise (.so) e i file oggetto (.o). L’obiettivo in questa fase non è il reversing completo né l’esecuzione del campione, ma imparare a ricavare rapidamente indicatori utili (metadata, segmenti, entropia, stringhe e informazioni riguardo il packing) senza eseguire il binario. L’analisi statica di base consiste nell’esaminare il file eseguibile senza visualizzarne direttamente le istruzioni. Questo tipo di analisi può confermare se un file è malevolo, fornire informazioni sulla sua funzionalità e, talvolta, permettere di ricavare semplici firme di rete (network signatures: nome di dominio, IP, porte, URL). L’analisi statica di base è semplice da eseguire e può essere molto rapida, ma risulta poco efficace contro malware sofisticati e può tralasciare comportamenti importanti. “everything is open source if you can reverse engineer” Step Fondamentali dell’Analisi Statica di Base Nelle prossime sezioni verranno descritte le procedure metodologiche per ispezionare il file malevolo a riposo (ovvero, senza eseguirlo), un processo cruciale per ottenere una prima, fondamentale comprensione della sua struttura e dei suoi intenti. Di seguito un sunto per punti di quello che andremo a vedere: Analisi preliminare del File tramite Hash Malware impacchettato e offuscato e analisi dell’Entropia Analisi dell’Entropia con binwalk Analisi delle funzioni importate con Radare2 Analisi del malware con il comando file Analisi del malware con il comando readelf Analisi preliminare del File tramite Hash L’hashing è un metodo comune utilizzato per identificare in modo univoco un malware. Il software malevolo viene elaborato da un programma di hashing, che produce un hash unico capace di identificare quel malware, una sorta di impronta digitale. La funzione di hash MD5 (Message-Digest Algorithm 5) è stata a lungo la più utilizzata nell’analisi dei malware, ma oggi è considerata obsoleta e insicura. Al suo posto si preferiscono algoritmi più moderni e affidabili come SHA-256 (Secure Hash Algorithm 256-bit), anche se SHA-1 può ancora comparire in alcuni contesti legacy o di compatibilità. sha256sum malware.elf5eb69f3b46a0df45f5e4f2c0beede4a86f9aace3870dd8db28bc6521e69f363b malware.elf L’hash del file permette di ricercare informazioni correlate al malware online, in particolare su piattaforme specializzate come VirusTotal. Malware impacchettato e offuscato e analisi dell’Entropia Gli autori di malware spesso usano packing o offuscamento per rendere i loro file più difficili da rilevare o analizzare. I programmi offuscati sono quelli il cui codice sorgente o binario è stato deliberatamente reso illeggibile e difficile da analizzare, pur mantenendo la sua funzionalità originale. I programmi impacchettati (packed) sono un sottoinsieme dei programmi offuscati in cui il programma malevolo è compresso o criptato e quindi non può essere analizzato direttamente. Entrambe le tecniche limiteranno fortemente i tentativi di analisi statica del malware. I programmi legittimi contengono quasi sempre molte stringhe (testo leggibile). Il malware che è impacchettato o offuscato contiene poche stringhe intelleggibili. Se, cercando le stringhe in un programma con strings, si scopre che ne ha soltanto poche intelleggibili, è probabile che sia offuscato o impacchettato, il che suggerisce che potrebbe essere malevolo. Probabilmente si dovrà ricorrere a tecniche oltre l’analisi statica per investigare più a fondo. strings malware_packed.elf | grep UPXUPX! nXH,) OQ lfF&(b LNqm Il comando strings estrae e mostra le sequenze di caratteri stampabili (testo leggibile) da qualsiasi file, ma è usato principalmente sui binari. Permette di trovare rapidamente testo, come messaggi di errore o percorsi di file, all’interno di file non testuali senza doverne analizzare la struttura. In questo caso il comando strings ha rivelato esclusivamente stringhe intellegibili relative al packer UPX. Una volta accertato che il file è stato compresso con UPX, si può procedere alla decompressione (unpacking) tramite il seguente comando: upx -d malware_packed.elf Analisi dell’Entropia con binwalk Binwalk è un’utility usata per analizzare, estrarre e “smontare” file binari. È particolarmente efficace con le immagini firmware (il software che fa funzionare dispositivi come router, telecamere, etc.). La funzione di analisi dell’entropia di Binwalk è cruciale per identificare rapidamente le aree “interessanti” di un file. binwalk -E malware_packed.elf Analizzando un altro campione di malware ELF compresso (packed), si notano subito due indicatori. Primo, il comando strings, come si è potuto già vedere, rivela quasi esclusivamente stringhe intellegibili relative al packer UPX. Secondo, l’analisi dell’entropia con binwalk -E mostra un valore uniformemente elevato, un’ulteriore conferma che il file è stato offuscato tramite compressione. Un valore di entropia elevato, infatti, implica un alto grado di caos e casualità nei dati. In altri casi, l’analisi dell’entropia con Binwalk potrebbe non produrre risultati significativi. Ad esempio, potrebbe non rilevare alcuna variazione utile oppure potrebbe evidenziare picchi di entropia elevata solo in aree molto limitate dell’eseguibile. Nel caso del malware che stiamo analizzando, il cui hash sha256 abbiamo calcolato all’inizio, non abbiamo informazioni sull’Entropia, perché il file eseguibile ha dimensioni troppo ridotte. Analisi delle funzioni importate con Radare2 Radare2 (spesso abbreviato in r2) è un framework completo e open source per il reverse engineering e l’analisi di file binari. Non è un singolo strumento, ma una suite di potenti utility a riga di comando che possono essere usate insieme per disassemblare, analizzare, modificare e sfruttare qualsiasi tipo di file binario, come eseguibili, librerie, firmware e malware. r2 ./file_da_andalizzare afl (Analyze Function List) Il comando afl elenca tutte le funzioni che Radare2 è riuscito a identificare all’interno del file binario che si sta analizzando, comprese le funzioni importate. È uno dei primi comandi da eseguire per ottenere una mappa generale del programma e decidere da dove iniziare l’analisi. [0x00001100]> afl 0x000010a0 1 10 sym.imp.putchar 0x000010b0 1 10 sym.imp.puts 0x000010c0 1 10 sym.imp.__stack_chk_fail 0x000010d0 1 10 sym.imp.printf 0x000010e0 1 10 sym.imp.strcspn 0x000010f0 1 10 sym.imp.fgets 0x00001100 1 37 entry0 Se l’output di Radare2 fosse simile a questo si potrebbero trarre alcune ipotesi iniziali sul comportamento del programma: Gestione dell’Input/Output: La presenza di funzioni come fgets (per leggere stringhe), strcspn (per l’analisi delle stringhe) e printf/puts (per stampare a schermo) suggerisce che il programma interagisce con l’utente tramite input e output testuale. Comportamento Locale: Un dato fondamentale è l’assenza di funzioni importate relative a operazioni di rete (es. socket, connect), accesso al file system (es. fopen) o gestione di altri processi. Questo indica fortemente che le sue azioni sono confinate all’ambiente locale. L’analisi statica suggerisce che il programma potrebbe essere un semplice interprete di comandi o un software che richiede l’inserimento di dati, come una password o una flag (es. un crackme o un CTF). Sebbene non emergano attività palesemente sospette, non è possibile escludere una natura malevola senza un’analisi più approfondita, come quella dinamica o l’analisi del codice disassemblato, per comprendere la logica interna del programma. r2 ./malware.elf[0x00400078]> afl 0x00400078 1 31 entry0 Nel caso del malware che stiamo analizzando, l’analisi iniziale con Radare2, tramite il comando afl, non rivela alcuna funzione di libreria importata, mostrando unicamente il punto d’ingresso (entry0). Questa assenza è un forte indicatore che l’eseguibile è stato compilato staticamente. Invece di fare affidamento su librerie esterne (es. libc), il compilatore ha incluso tutto il codice macchina necessario direttamente all’interno del file. Di conseguenza, funzioni standard come printf, socket o connect non appaiono come funzioni importate ma come parte integrante del codice del malware stesso, rendendo l’analisi iniziale più complessa. Analisi del malware con il comando file file malware.elfmalware.elf: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, no section header Il comando file determina il tipo di un file analizzandone il contenuto anziché l’estensione. Esegue una serie di test, come la ricerca di “magic number” (sequenze di byte identificative), per riconoscere il formato. Restituisce una breve descrizione del tipo di file, ad esempio JPEG image data o ASCII text. Il malware che stiamo analizzando è un ELF a 64 bit minimale, privo della Section Header Table (SHT) (tipico di alcuni malware offuscati per ostacolare l’analisi statica e i tool come readelf/objdump). Questo non impedisce l’esecuzione del file: il loader del kernel si basa sulla Program Header Table (PHT) per mappare i segmenti in memoria; il fatto che sia linkato staticamente e con permessi RWE (vedere sezione readelf) indica che è stato costruito per essere autosufficiente, senza dipendenze, e magari pronto per eseguire codice decrittato/iniettato dinamicamente. Analisi del malware con il comando readelf Il comando readelf è uno strumento specializzato che analizza e visualizza informazioni estremamente dettagliate sulla struttura dei file in formato ELF (eseguibili e librerie su Linux). Si concentra sulla visualizzazione precisa di ogni componente dello standard ELF, come le intestazioni (headers), le sezioni e le informazioni sul linking dinamico. -l (–program-headers) Mostra la program header table, ovvero i segmenti che dicono al sistema operativo come caricare il file in memoria. readelf -l malware.elfFile elf di tipo EXEC (file eseguibile) Entry point 0x400078 There is 1 program header, starting at offset 64 Intestazioni di programma: Tipo Offset IndirVirt IndirFis DimFile DimMem Flag Allin LOAD 0x0000000000000000 0x0000000000400000 0x0000000000400000 0x0000000000000115 0x00000000000001b2 RWE 0x100 -h (–file-header) Mostra l’ELF header: formato (32/64 bit), endianness, versione, tipo (EXEC/DSO/REL), architettura, entry point, offset delle table, flags ecc. Utile per capire a colpo d’occhio che tipo di ELF stai analizzando. readelf -h malware.elf Intestazione ELF: Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 Classe: ELF64 Dati: complemento a 2, little endian Version: 1 (current) SO/ABI: UNIX - System V Versione ABI: 0 Tipo: EXEC (file eseguibile) Macchina: Advanced Micro Devices X86-64 Versione: 0x1 Indirizzo punto d'ingresso: 0x400078 Inizio intestazioni di programma 64 (byte nel file) Inizio intestazioni di sezione: 0 (byte nel file) Flag: 0x0 Size of this header: 64 (bytes) Size of program headers: 56 (bytes) Number of program headers: 1 Size of section headers: 0 (bytes) Number of section headers: 0 Section header string table index: 0 Analisi dei risultati di readelf Ricapitolando per punti quanto abbiamo osservato finora: Il binario è un ELF64 eseguibile per x86-64, entrypoint 0x400078. Non contiene Section Header Table (size section headers = 0), tipico dei malware minimali o offuscati/packed. Program header singolo con flags RWE (read-write-exec), cioè tutta la memoria caricata è leggibile, scrivibile ed eseguibile. Statically linked, quindi non dipende da librerie esterne. Le evidenze raccolte suggeriscono che il malware possa agire come stager o dropper: la sua struttura minimale e autosufficiente (dimensioni ridotte, 227 bytes, compilazione statica), l’uso di tecniche di anti-analisi come l’assenza di section headers per ostacolare il reverse engineering, e soprattutto la presenza di un segmento di memoria con permessi di Lettura, Scrittura ed Esecuzione (RWE). Quest’ultima caratteristica, in particolare, è un forte indicatore di un codice progettato per auto-modificarsi, caricando e avviando un payload successivo. Conclusioni In questo articolo abbiamo esplorato le fasi fondamentali dell’analisi statica di base, dimostrando come, attraverso una serie di strumenti essenziali (sha256sum, strings, binwalk, radare2, file e readelf), sia possibile costruire un profilo iniziale di un malware ELF sconosciuto. Abbiamo imparato a identificare il file, a rilevarne eventuali tecniche di offuscamento come il packing, e ad analizzarne la struttura per raccogliere indicatori cruciali, come la compilazione statica, l’assenza di section headers e la presenza di segmenti di memoria con permessi RWE. Sebbene questa analisi ci abbia permesso di formulare un’ipotesi solida sulla natura del campione, probabilmente uno stager o dropper, essa si ferma alla superficie, senza svelare la logica esatta del suo codice. Per comprendere appieno le sue azioni, è necessario fare un passo avanti. Nel prossimo articolo, ci addentreremo nell’analisi statica avanzata, immergendoci nello studio del codice disassemblato per decifrare le istruzioni macchina e svelare le reali intenzioni del malware. Autore HCF: hacker artist, reverse engineer, battle programmer e malware & cybersecurity analyst. blog: spaghetti-hacker.blogfree.net Halt and Catch Fire, indicato con la sigla mnemonica di HCF, è un’istruzione fittizia del linguaggio assembly, intesa prevalentemente come uno scherzo, che è stata usata per definire istruzioni solitamente non documentate che portano la CPU in uno stato da cui può essere fatta uscire solo con un reset; solitamente con la sigla HCF si descrive una o più istruzioni non documentate presenti in molte architetture e utilizzate per poter effettuare agevolmente particolari test durante lo sviluppo dei prodotti, ma che non sono da utilizzarsi nella normale operatività.

ToolShell: rilevato sfruttamento in rete di vulnerabilità in SharePoint Alert AL01/250721/CSIRT-ITA Sintesi Microsoft ha rilasciato aggiornamenti di sicurezza per 2 vulnerabilità che interessano il prodotto SharePoint, nota piattaforma di collaborazione e gestione file. Nel dettaglio, la CVE-2025-53770 risulta sfruttata attivamente in rete: causata dalla deserializzazione di dati non attendibili, consente a un attaccante remoto non autenticato di eseguire codice arbitrario sulle istanze target. Note: un Proof of Concept (PoC) per lo sfruttamento della CVE-2025-53770 risulta disponibile in rete. Tipologia Authentication Bypass Remote Code Execution Spoofing Descrizione e potenziali impatti Microsoft ha recentemente individuato lo sfruttamento in rete di una vulnerabilità con gravità “critica”, identificata tramite la CVE‑2025‑53770 con score CVSS v3.x pari a 9.8, di tipo “Remote Code Execution”, che interessa il prodotto SharePoint Server. Tale vulnerabilità è causata da una deserializzazione di dati non attendibili all’interno del framework ASP.NET, che SharePoint utilizza per la gestione dei propri contenuti e delle componenti dell’interfaccia utente. L’attacco, che non richiede autenticazione, viene condotto tramite richieste HTTP di tipo POST opportunamente predisposte verso la risorsa: /_layouts/15/ToolPane.aspx?DisplayMode=Edit pagina utilizzata per visualizzare e modificare le Web Part, componenti modulari di SharePoint. Tale risorsa utilizza un campo nascosto chiamato __VIEWSTATE, utilizzato per mantenere lo stato della pagina tra le varie richieste HTTP mediante la serializzazione di oggetti .NET. Qualora tali dati non siano adeguatamente firmati o validati, un attaccante può sottomettere un payload malevolo che, una volta deserializzato dal server, consente l’esecuzione di codice arbitrario sul sistema interessato. Prodotti e/o versioni affette Microsoft SharePoint Server Subscription Edition Microsoft SharePoint Server 2019 Microsoft SharePoint Server 2016 Azioni di mitigazione In linea con le dichiarazioni del vendor, si raccomanda di aggiornare i prodotti vulnerabili seguendo le indicazioni dei bollettini di sicurezza riportati nella sezione Riferimenti. In aggiunta il si raccomanda di: monitorare e bloccare richieste POST verso ToolPane.aspx contenenti valori anomali nel campo __VIEWSTATE; verificare che il meccanismo di sicurezza AMSI (Antimalware Scan Interface) sia attivo; procedere con la rotazione delle machine keys di ASP.NET; riavviare IIS in tutti i server SharePoint tramite iisreset.exe. Infine, si raccomanda di valutare la verifica e l’implementazione - sui propri apparati di sicurezza - degli Indicatori di Compromissione (IoC)[1] forniti da Microsoft e dal CISA e di quelli riportati nell'apposita sezione e in allegato. Azioni di rilevamento A scopo di rilevazione proattiva di potenziali compromissioni relative a Microsoft SharePoint, si condivide la seguente regola YARA di terze parti, pubblicata dal repository open source signature-base di Florian Roth: ed una seconda regola Yara sviluppata dallo CSIRT Italia: rule webshell_toolshell1 { meta: uuid = "1d6e3973-ac25-42db-a70e-d50d28dd5782" author = "CSIRT Italia - Agenzia per la Cybersicurezza Nazionale (ACN)" description = "Detection of a webshell deployed during a Toolshell attack aimed at extracting machine keys" reference = "https://www.acn.gov.it/portale/w/toolshell-rilevato-sfruttamento-in-rete-di-vulnerabilita-in-sharepoint" version = "1" // Defines whether the rule applies only to memory scans or can be used for both memory and disk scans: // - true: The rule applies only to memory scans, i.e. running processes. // - false: The rule can be used for both memory and disk scans. memory_only = false // : should never trigger a false positive and be of high relevance // : trigger on threats of high relevance that have to be reviewed manually (rare false positives) // and : indicate suspicious activity // : have informative character and are used to identify a broad characteristic of a sample (i.e. "UPX packed", "written in Golang", etc.) severity = "high" // The TLP (Traffic Light Protocol) level of the rule, indicating the sensitivity of the information: // - : there is no limit on disclosure, recipients can spread this to the world. // - : recipients can spread this within their community // - : recipients can only spread this on a need-to-know basis within their organization and its clients // - : recipients can only spread this on a need-to-know to the organization only // - : for the eyes and ears of individual recipients only, no further disclosure tlp = "clear" // The Permissible Actions Protocol (PAP) was designed to indicate how the received information can be used: // - : no restrictions in using this information // - : active actions allowed. Recipients may use this rule to information to block incoming/outgoing traffic from/to the target or specifically configure honeypots to interact with the target // - : passive cross check. Recipients may use this rule for conducting online checks, like using services provided by third parties (e.g. Virus Total), or set up a monitoring honeypot // - : Non-detectable actions only. Recipients may not use this rule on the network. Only passive actions on logs/files/, that are not detectable from the outside pap = "clear" strings: $webshell1 = "ValidationKey" ascii xor $webshell2 = "Validation" ascii xor $webshell3 = "DecryptionKey" ascii xor $webshell4 = "Decryption" ascii xor $webshell5 = "CompatibilityMode" ascii xor $webshell6 = "CODEPAGE=\"65001\"" ascii xor $webshell7 = "MachineKeySection" ascii xor $webshell8 = "System.Web.Configuration" ascii xor $webshell9 = "System.Reflection" ascii xor $webshell10 = "GetApplicationConfig" ascii xor $asp1 = "CODEPAGE" ascii $asp2 = " $HOME_NET [80,443] ( msg:"CSIRT ITALIA - Detects exploit attempt leveraging the ToolShell attack chain to target SharePoint"; reference:url,https://www.acn.gov.it/portale/w/toolshell-rilevato-sfruttamento-in-rete-di-vulnerabilita-in-sharepoint; classtype:web-application-attack; priority:1; service:http; flow:to_server,established; http_method; content:"POST",fast_pattern,nocase; http_uri:path; content:"_layouts",fast_pattern,nocase; content:"ToolPane.aspx",fast_pattern,nocase; pcre:"/(?:\/_layouts/1(?:[2456])/ToolPane.aspx\/?)/i"; http_header:field referer; content:"_layouts",fast_pattern,nocase; content:"SignOut.aspx",fast_pattern,nocase; pcre:"/(?:\/_layouts\/(?:1[2456]\/)?SignOut\.aspx)/i"; http_uri:query; pcre:"/DisplayMode\=Edit/i"; pcre:"/a\=\/ToolPane\.aspx/i"; http_client_body; content:"MSOtlPn_Uri",nocase; content:"MSOtlPn_DWP",nocase; sid:3330002; rev:2; ) NB: Si raccomanda di validare e testare preventivamente la regola in ambienti controllati, in particolare per le installazioni basate su Snort 3, assicurandosi che il SID utilizzato non sia già impiegato da altre firme. [1] Per definizione, non tutti gli indicatori di compromissione sono malevoli. Questo CSIRT non ha alcuna responsabilità per l'attuazione di eventuali azioni proattive (es. inserimento degli IoC in blocklist) relative agli indicatori forniti. Le informazioni contenute in questo documento rappresentano la migliore comprensione della minaccia al momento del rilascio. Di seguito sono riportate le sole CVE relative alle vulnerabilità con gravità “alta”: Data pubblicazione 21/07/25 ore 09:36 Data Ultimo Aggiornamento 30/07/25 ore 10:52