Teams cambia volto: Microsoft introduce nuovi blocchi contro malware e phishing

Microsoft ha avviato un ampio rafforzamento delle misure di sicurezza di Microsoft Teams, introducendo nuovi controlli su file, collegamenti web e sistemi di rilevamento automatico delle minacce. Gli aggiornamenti, annunciati attraverso i bollettini ufficiali della Microsoft 365 Roadmap, mirano a ridurre i rischi legati amalware, phishing e falsi positivi all’interno delle comunicazioni aziendali.

Il completamento del rollout globale è previsto entro la fine di novembre 2025, mentre l’attivazione automatica di alcune impostazioni, inizialmente pianificata per il 2025, è stata rinviata all’inizio del 2026.

Stop ai file potenzialmente pericolosi nelle chat

Uno degli interventi principali riguarda il blocco dei messaggi che contengono tipologie di file considerate potenzialmente “weaponizzabili”, come gli eseguibili. La misura è stata annunciata nel bollettino Microsoft 365 Roadmap ID 499892, aggiornato al 17 novembre 2025.

A partire dalla disponibilità generale, Microsoft Teams impedirà la condivisione di questi file all’interno di chat e canali, riducendo il rischio di attacchi veicolati tramite allegati. La protezione interessa Teams su Windows, macOS, Web e dispositivi mobili iOS e Android.

La disponibilità generale inizierà il 3 novembre 2025 e si concluderà entro la fine del mese. In questa fase, l’opzione “Analizza i messaggi per i tipi di file non consentiti” sarà impostata su ON per impostazione predefinita, a condizione che almeno uno dei partecipanti alla conversazione abbia la protezione attiva.

Gli amministratori possono gestire o modificare questa impostazione dal Centro di amministrazione di Teams, nella sezione delle impostazioni di messaggistica, oppure tramite PowerShell. Le configurazioni già salvate durante il rilascio mirato – avviato a inizio settembre 2025 e completato entro metà mese – resteranno valide anche dopo il passaggio alla disponibilità generale.

Microsoft ha inoltre confermato che l’attivazione automatica predefinita per tutte le organizzazioni, inizialmente prevista per il 2025, è stata posticipata all’inizio del 2026.

Gli utenti potranno segnalare i falsi positivi

Un secondo aggiornamento, descritto nel bollettino Microsoft 365 Roadmap ID 501202 (aggiornato al 17 novembre 2025), introduce in Microsoft Teams la possibilità per gli utenti di segnalare messaggi erroneamente identificati come minacce alla sicurezza.

La funzione consente di fornire feedback sui falsi positivi generati dai sistemi di protezione, contribuendo a migliorare la precisione dei meccanismi di rilevamento. È disponibile per le organizzazioni che utilizzano Microsoft Defender per Office 365 Piano 2 o Microsoft Defender XDR e richiede l’abilitazione sia nel Centro di amministrazione di Teams sia nel portale Microsoft Defender.

La funzionalità è supportata su tutte le principali piattaforme di Teams: Windows, macOS, Web, iOS e Android. Il rilascio mirato globale è iniziato a inizio settembre 2025 e si è concluso entro metà mese, mentre la disponibilità generale è prevista tra l’inizio e la fine di novembre 2025.

Anche in questo caso, Microsoft ha rinviato all’inizio del 2026 l’attivazione predefinita dell’opzione “Segnala rilevamenti di sicurezza errati”, annunciando che una comunicazione separata fornirà i dettagli sul nuovo calendario.

Avvisi automatici per link dannosi e tentativi di phishing

Il terzo aggiornamento riguarda la protezione contro gli URL malevoli condivisi in chat e canali di Teams. La funzionalità, descritta nel bollettino Microsoft 365 Roadmap ID 499893, aggiornato al 17 novembre 2025, introduce un sistema di rilevamento in grado di avvisare gli utenti quando un collegamento viene identificato come potenzialmente pericoloso.

L’obiettivo è ridurre il rischio di phishing, aiutando gli utenti a prendere decisioni più consapevoli prima di interagire con link sospetti. Anche questa protezione è disponibile su Teams per desktop, web e dispositivi mobili.

Durante il rilascio mirato globale, avviato a inizio settembre 2025 e concluso entro metà mese, la funzione risulta disattivata per impostazione predefinita. Con la disponibilità generale, prevista da inizio novembre e in conclusione entro la fine di novembre 2025, la protezione sarà attiva di default, salvo diversa configurazione da parte degli amministratori.

Come per gli altri interventi, Microsoft ha comunicato che l’attivazione automatica definitiva per tutte le organizzazioni è stata rinviata all’inizio del 2026, con ulteriori dettagli che verranno forniti attraverso un bollettino dedicato.

L'articolo Teams cambia volto: Microsoft introduce nuovi blocchi contro malware e phishing proviene da Red Hot Cyber.

Piergiorgio Perotto, L’inventore del P101, Spiega il Perché l’Italia è Destinata ad Essere Un Perenne Follower

Pier Giorgio Perotto (per chi non conosce questo nome), è stato un pioniere italiano dell’elettronica, che negli anni 60 quando lavorava presso la Olivetti, guidò il team di progettazione che costruì il Programma 101 (o P101), il primo computer desktop della storia.

Il P101 (chiamata anche Perottina), venne lanciato alla Fiera mondiale di New York del 1964, e venne utilizzato anche dalla NASA per pianificare e calcolare le orbite dei programmi spaziali, compresa la missione Apollo 11 che portò l’uomo sulla luna. Per chi volesse approfondire la storia del Programma 101, potete vedere il video sul canale YouTube di Red Hot Cyber.

Ma quello di cui parleremo oggi, è un pezzo tratto dal libro Programma 101 scritto da Perotto, che ci racconta una storia appassionante, scritta negli anni 2000.

Sebbene siano passati molti anni da quando Perotto scrisse questo libro, all’interno ritroviamo una sintesi di passaggi interessanti ed attuali sul perché l’Italia sia un paese di innovatori disarmati che faticano ad emergere a causa dalla poca lungimiranza di un paese che predilige la logica dell’imitazione, con la propensione a voler essere un perenne “follower” della tecnologia di oltre oceano, piuttosto che “influencer” della scena geopolitica internazionale.

La strategia non serve

E’ possibile realizzare un nuovo rivoluzionario prodotto elettronico in un’azienda che non ne vuole assolutamente sapere e, anzi, fa sua una strategia di rifiuto dell’elettronica e di persistenza a oltranza nella tradizionale tecnologia meccanica? In Italia è possibile, ed è successo all’Olivetti negli anni ’60.

Il prodotto di cui parliamo è il personal computer, anzi, (se vogliamo usare il lessico di allora),il computer personale, altrimenti detto Perottina: questi almeno erano i neologismi coniati per l’occasione ad uso esterno e interno all’azienda. Le ragioni per le quali vale la pena di ricordare il caso dell’invenzione del PC non sono solo quella di riaffermare una priorità mondiale italiana o di ripercorrere un lamentevole amarcord, ma piuttosto di trarne insegnamenti per capire e affrontare i problemi attuali della scarsa capacità innovativa del nostro paese, una limitazione cruciale, che persiste e che condizionerà il nostro sviluppo prossimo venturo.
Una foto del team del programma 101, dove in basso a sinistra è presente Piergiorgio Perotto
L’Italia non è, oggi come ieri, affetta solo da una specie di idiosincrasia o di horror vacui per quanto concerne la ricerca (per la quale, come è noto, siamo agli ultimi posti tra i paesi industrializzati, come rapporto tra investimenti e PIL), ma soprattutto da una cultura industriale che aborre l’idea di correre i rischi connessi all’apertura di nuovi settori.

Disgraziatamente, siamo oggi in un periodo storico nel quale si stanno costruendo i fondamenti della società dell’informazione nel mondo e l’apertura di nuovi settori è proprio l’evento più tipico e maggiormente portatore di rivoluzionarie innovazioni. Ma in Italia gli innovatori, come profeti disarmati, continuano ad avere vita grama e, soprattutto nelle grandi aziende, la cultura dominante è quella dell’imitazione pedissequa delle mode d’oltreoceano e della rinuncia. Congenitamente, l’imprenditoria italiana è affetta da una sindrome che la porta a privilegiare la strategia del follower, una forma di sciovinismo alla rovescia.

Un caso paradigmatico

Le vicende accadute in Olivetti trent’anni fa sono paradigmatiche, e vale quindi la pena di riassumerle. Lo scenario è quello del 1961. La Olivetti è ancora traumatizzata per la improvvisa scomparsa di Adriano e all’orizzonte si profilano i sintomi di una recessione economica con la quale si sta chiudendo il decennio del miracolo economico.

L’azienda è impegnata in due avventure, entrambe volute da Adriano: lo sviluppo della Divisione Elettronica per progettare e produrre computer e la ‘digestione’ della Underwood, l’azienda americana da poco acquisita per conquistare il mercato nordamericano. Ma nessuna delle due operazioni era condivisa dall’establishment dell’azienda, abituato ai profitti derivati dal grande successo mondiale della Divisumma 24, calcolatrice uscita dalla magica matita di Natale Capellaro (un geniale operaio, scoperto da Adriano e da questi nominato direttore generale).

Mentre, però, l’acquisizione della Underwood era bene o male accettata (anche se a posteriori si rivelò un’operazione disastrosa) in quanto conforme a una certa normale politica di espansione commerciale nei settori tradizionali dell’azienda, quello che non andava giù ai conservatori era l’avventura dell’elettronica, vista come un settore pericoloso e incerto. Si dice che l’idea di progettare computer provenisse da Enrico Fermi e venisse formulata in occasione di una sua visita in Italia nel 1949, nel corso della quale incontrò Adriano.

Ma io credo che l’Olivetti si innamorò dell’idea perché intravide nell’informatica un ruolo di scienza regolatrice e creatrice di un superiore ordine estetico in un campo immateriale come quello dell’informazione, così come l’urbanistica e l’architettura lo sono nel progetto delle città. Ma Adriano Olivetti era un isolato, che invece di godere dell’appoggio e della stima dell’establishment industriale se ne tirò addosso l’ostilità e la diffidenza.

Il risultato fu che, alla sua morte, l’operazione elettronica dell’Olivetti entrò in una crisi che non saprei definire se più ideologica o finanziaria, crisi che colpì d’altra parte l’intera azienda. Io ebbi la ventura di essere testimone diretto della drammatica vicenda, che si concluse nel 1964 con l’infausta rinuncia e la cessione dell’intero settore elettronico alla General Electric, in quanto feci parte dei ricercatori reclutati per il laboratorio di ricerche elettroniche di Pisa, il primo insediamento dedicato a questa nuova tecnologia.

La cessione della divisione elettronica Olivetti maturò – in tragica e assurda coincidenza con l’avvio della rivoluzione microelettronica mondiale – per la precisa determinazione dei poteri forti della finanza e dell’industria nazionale ad uccidere l’iniziativa, nella totale indifferenza delle forze politiche.

Innovare dietro le quinte

Ricordo perfettamente una dichiarazione del professor Valletta (presidente della Fiat e ispiratore del gruppo di intervento che all’inizio del 1964 prese le redini dell’Olivetti) a proposito della crisi:

“La società di Ivrea è strutturalmente solida e potrà superare senza grandi difficoltà il momento critico. Sul suo futuro pende però una minaccia, un neo da estirpare: l’essersi inserita nel settore elettronico, per il quale occorrono investimenti che nessuna azienda italiana può affrontare”.

Non ci volle molto a capire, quando il nuovo management si insediò ai comandi, quale sarebbe stata la sorte dell’elettronica. Non fu detto nulla di ufficiale, ma la strategia fu quella di un rilancio generale di tutti i prodotti meccanici; e la cosa fu pensata in grande stile, organizzando una presentazione alla mostra internazionale dei prodotti per l’ufficio, nell’ottobre del 1965 a New York.

Nel frattempo la divisione elettronica venne silenziosamente ceduta alla General Electric. Fu detto che l’operazione e la conseguente collaborazione con la G.E. sarebbe servita a riversare sull’Olivetti i frutti dei grandi laboratori di ricerca americani, che l’elettronica Olivetti non moriva e che in futuro ne avrebbe tratto dei giovamenti; ma tutti si resero conto che si trattava di una mistificazione.

E più di tutti me ne resi conto io stesso che, avendo partecipato alle trattative e lavorando nei laboratori elettronici ceduti agli americani (dei quali potei saggiare l’arroganza e le loro intenzioni esclusivamente commerciali), ebbi l’occasione di conoscere le vere motivazioni dell’operazione. Per questo ebbi la malaugurata idea, da giovane ingenuo, di contestare la cessione, ottenendo il risultato di essere dagli americani restituito all’Olivetti, con la preghiera di togliermi di torno.

Molti pensano con riverenza alla strategia come a una nobile attività nella quale si decidono le sorti future di una azienda. Nel caso specifico, le sorti dell’Olivetti furono decise dalla non strategia! Mi spiego meglio. Il mio rientro in Olivetti dopo la cacciata mi consentì di dedicarmi a una di quelle attività di studio che le aziende portano avanti di solito nella più completa indifferenza: si trattava di esplorare la possibilità futura di costruire con tecnologie elettroniche prodotti per l’ufficio.

La cosa sembrava allora tanto più inverosimile e improbabile in quanto negli anni ’60 esistevano solo grandi calcolatori, operanti in centri di calcolo ben lontani dal mondo degli uffici, e nessuna persona ragionevole pensava che si potessero fare delle macchine elettroniche di costo e dimensioni tali da stare sulla scrivania di un singolo individuo. Venni quindi confinato con qualche collaboratore in un piccolo laboratorio di Milano, in territorio ormai della G.E., perché se agli americani ero inviso, il clima ad Ivrea, tempio della meccanica, non era molto migliore.

Ma questa volta il gruppo di intervento, che aveva puntato tutto sul rilancio della meccanica, fu davvero sfortunato, perché una piccola grande idea germogliò inaspettatamente nel mio laboratorio: quella del computer personale (anticipando di ben dieci anni i P.C. introdotti in America!). Non voglio qui raccontare le drammatiche vicende che portarono a questo risultato (e rimando al libro di cui questo articolo costituisce una sintesi). Ma l’imbarazzo e l’indifferenza con cui il nuovo management accolse la notizia dell’imprevista epifania emersa dalle stive dell’azienda ebbero almeno il merito diportare a una timida ma positiva decisione: quella di esporre la nuova macchina, come puro modello dimostrativo, in una saletta riservata della mostra newyorkese. Quello che non fece la strategia, lo fece il complesso di colpa legato alla cessione dell’elettronica e la voglia di far vedere che la Olivetti, in fondo, sì, qualcosa di esplorativo con l’elettronica, pur non credendoci, faceva ancora.

Quello che successe alla fiera fu però straordinario e sconvolgente: il pubblico americano capì perfettamente quello che il management dell’azienda non aveva capito, ossia il valore rivoluzionario della “Programma 101”; trattò con assoluta indifferenza i prodotti meccanici esposti in pompa magna e si assiepò nella saletta per vedere quello che il nuovo prodotto era in grado di fare. La stampa, specializzata e non, segnò con i suoi articoli entusiastici il successo di una presentazione e di un evento non voluto. In pratica, il nuovo computer fu letteralmente risucchiato dal mercato: si può dire che non fu venduto, fu solo comprato!

Questo caso insegna che…

Quale insegnamento trarre per i nostri giorni?

La New Economy che sta nascendo nel mondo attorno alla rete delle reti consente oggi agli innovatori di creare aziende basate solo sulla forza di un’idea. Nel 1965 questo non era possibile, ma attraverso il web le soglie da superare per creare un nuovo business si sono ora drasticamente abbassate. Abbiamo addirittura singoli individui che si permettono di sfidare i giganti mondiali dell’informatica (vedi il caso dello studente finlandese Linus Tordvald, che sfida la Microsoft col suo sistema operativo Linux). E ho anche l’impressione che oggi gli inventori possano non solo non morire poveri, ma addirittura scalare le classifiche mondiali dei super-ricchi.

Un altro insegnamento che si può trarre dal “caso” della “Programma 101” (caso poi realmente usato nei corsi Mba di Harward) è quello della gestione delle discontinuità, che rappresenta situazioni sempre più frequenti nella società contemporanea.

Sono finiti i tempi nei quali il futuro poteva essere estrapolato dalle vicende del passato. Nel campo delle tecnologie, ma anche nel mondo delle applicazioni, le innovazioni rappresentano, in genere, rotture col passato: le nuove tecnologie operano come tecnologie killer di quelle tradizionali e costituiscono la base di nuovi paradigmi; e le aziende che le sanno sfruttare raramente si ritrovano tra quelle leader delle vecchie.

Infatti, la leadership dell’Olivetti nella meccanica dei calcolatori e delle macchine per scrivere aveva attenuato o spento la capacità di intuire e sentire i segnali deboli premonitori della imminente rivoluzione microelettronica che avrebbe di lì a poco trasformato il mondo.

Se il piccolo gruppo di riottosi progettisti della “Programma 101” non avesse avuto la forza e il coraggio di affermare coi fatti le potenzialità delle nuove tecnologie (per farsi poi artefice della grande mutazione dell’azienda, dalla meccanica all’elettronica), l‘azienda avrebbe fatto negli anni ’60 la stessa fine di tanti nomi prestigiosi nel settore del calcolo e degli altri prodotti per ufficio, scomparsi e non più risorti.

Mi auguro, infine, che la storia della “Programma 101” contribuisca a motivare tanti giovani dotati di capacità creative ad osare e a rischiare, senza lasciarsi condizionare dai benpensanti del momento, che nel nostro paese in troppi casi sono portatori di quella cultura della rinuncia e della pavidità, che fa correre il rischio al nostro sistema-nazionale di restare escluso dall’affascinante compito di edificare la società del ventunesimo secolo.

Vorrei anche che questo articolo, e il libro di cui costituisce una sintesi siano percepiti come un omaggio alla figura di Adriano Olivetti, imprenditore illuminato e incompreso che precursore dei tempi.

E’ passato molto tempo da quando Perotto scrisse questo libro, ma molte cose sembrano ancora attuali. Anche Adriano Olivetti disse:

“L’Italia procede ancora nel compromesso, nei vecchi sistemi del trasformismo politico, del potere burocratico, delle grandi promesse, dei grandi piani e delle modeste realizzazioni.”

Ma speriamo nel futuro, che tutto questo cambi in fretta.

L'articolo Piergiorgio Perotto, L’inventore del P101, Spiega il Perché l’Italia è Destinata ad Essere Un Perenne Follower proviene da Red Hot Cyber.

Net-SNMP nel mirino: un bug critico espone milioni di infrastrutture di rete a DoS

Una vulnerabilità critica è stata scoperta nella suite software Net-SNMP, diffusamente impiegata a livello globale per la gestione e il monitoraggio delle reti. La falla, catalogata come CVE-2025-68615, ha un punteggio CVSS di 9,8, valore prossimo al massimo, il che indica un rischio elevato per le organizzazioni che usano il servizio snmptrapd.

La vulnerabilità è stata scoperta dal ricercatore di sicurezza buddurid, in collaborazione con la Trend Micro Zero Day Initiative (ZDI). La vulnerabilità , un classico buffer overflow, consente a un aggressore di bloccare il demone, e potenzialmente causare ulteriori danni, semplicemente inviando un pacchetto appositamente creato.

Ricordiamo che Net-SNMP è un componente fondamentale dell’amministrazione di rete, che supporta un’ampia gamma di protocolli (SNMP v1, v2c, v3, AgentX) e modalità di trasporto (IPv4, IPv6, socket Unix). È la spina dorsale del monitoraggio di server, router e switch da parte di molte organizzazioni.

I responsabili della manutenzione di Net-SNMP hanno rilasciato versioni patchate per risolvere il problema. Si consiglia vivamente agli utenti di aggiornare immediatamente le proprie installazioni a:

• Net-SNMP 5.9.5
• Net-SNMP 5.10.pre2

Secondo l’avviso emesso, la falla è innescata da un “pacchetto appositamente creato”. Quando il demone tenta di elaborare questo input dannoso, innesca un buffer overflow. Sebbene l’avviso indichi esplicitamente che ciò causa il “crash del demone”, con conseguente Denial of Service (DoS), un punteggio CVSS di 9,8 suggerisce in genere la possibilità di conseguenze più gravi, come l’esecuzione di codice remoto (RCE), se l’overflow viene abilmente sfruttato.

“Non esiste alcuna mitigazione disponibile se non quella di garantire che le porte verso snmptrapd siano opportunamente protette da firewall”, afferma il rapporto. La vulnerabilità risiede specificatamente nel demone snmptrapd, il componente responsabile della ricezione e dell’elaborazione dei messaggi trap SNMP (avvisi inviati dai dispositivi di rete).

Se il listener snmptrapd è esposto a Internet, è vulnerabile ad attacchi da qualsiasi parte del mondo.

Si consiglia agli amministratori di assicurarsi che la porta UDP 162, utilizzata di default per le trap SNMP, sia protetta con rigore dai firewall e accessibile esclusivamente da indirizzi IP affidabili e interni, destinati alla gestione.

L'articolo Net-SNMP nel mirino: un bug critico espone milioni di infrastrutture di rete a DoS proviene da Red Hot Cyber.

Evasive Panda APT poisons DNS requests to deliver MgBot

Introduction

The Evasive Panda APT group (also known as Bronze Highland, Daggerfly, and StormBamboo) has been active since 2012, targeting multiple industries with sophisticated, evolving tactics. Our latest research (June 2025) reveals that the attackers conducted highly-targeted campaigns, which started in November 2022 and ran until November 2024.

The group mainly performed adversary-in-the-middle (AitM) attacks on specific victims. These included techniques such as dropping loaders into specific locations and storing encrypted parts of the malware on attacker-controlled servers, which were resolved as a response to specific website DNS requests. Notably, the attackers have developed a new loader that evades detection when infecting its targets, and even employed hybrid encryption practices to complicate analysis and make implants unique to each victim.

Furthermore, the group has developed an injector that allows them to execute their MgBot implant in memory by injecting it into legitimate processes. It resides in the memory space of a decade-old signed executable by using DLL sideloading and enables them to maintain a stealthy presence in compromised systems for extended periods.

Additional information about this threat, including indicators of compromise, is available to customers of the Kaspersky Intelligence Reporting Service. Contact: intelreports@kaspersky.com.

Technical details

Initial infection vector

The threat actor commonly uses lures that are disguised as new updates to known third-party applications or popular system applications trusted by hundreds of users over the years.

In this campaign, the attackers used an executable disguised as an update package for SohuVA, which is a streaming app developed by Sohu Inc., a Chinese internet company. The malicious package, named sohuva_update_10.2.29.1-lup-s-tp.exe, clearly impersonates a real SohuVA update to deliver malware from the following resource, as indicated by our telemetry:
p2p.hd.sohu.com[.]cn/foxd/gz?f…
There is a possibility that the attackers used a DNS poisoning attack to alter the DNS response of p2p.hd.sohu.com[.]cn to an attacker-controlled server’s IP address, while the genuine update module of the SohuVA application tries to update its binaries located in appdata\roaming\shapp\7.0.18.0\package. Although we were unable to verify this at the time of analysis, we can make an educated guess, given that it is still unknown what triggered the update mechanism.

Furthermore, our analysis of the infection process has identified several additional campaigns pursued by the same group. For example, they utilized a fake updater for the iQIYI Video application, a popular platform for streaming Asian media content similar to SohuVA. This fake updater was dropped into the application’s installation folder and executed by the legitimate service qiyiservice.exe. Upon execution, the fake updater initiated malicious activity on the victim’s system, and we have identified that the same method is used for IObit Smart Defrag and Tencent QQ applications.

The initial loader was developed in C++ using the Windows Template Library (WTL). Its code bears a strong resemblance to Wizard97Test, a WTL sample application hosted on Microsoft’s GitHub. The attackers appear to have embedded malicious code within this project to effectively conceal their malicious intentions.

The loader first decrypts the encrypted configuration buffer by employing an XOR-based decryption algorithm:
for ( index = 0; index < v6; index = (index + 1) )
{
if ( index >= 5156 )
break;
mw_configindex ^= (&mw_deflated_config + (index & 3));
}
After decryption, it decompresses the LZMA-compressed buffer into the allocated buffer, and all of the configuration is exposed, including several components:

• Malware installation path: %ProgramData%\Microsoft\MF
• Resource domain: http://www.dictionary.com/
• Resource URI: image?id=115832434703699686&product=dict-homepage.png
• MgBot encrypted configuration

The malware also checks the name of the logged-in user in the system and performs actions accordingly. If the username is SYSTEM, the malware copies itself with a different name by appending the ext.exe suffix inside the current working directory. Then it uses the ShellExecuteW API to execute the newly created version. Notably, all relevant strings in the malware, such as SYSTEM and ext.exe, are encrypted, and the loader decrypts them with a specific XOR algorithm.

Decryption routine of encrypted strings

If the username is not SYSTEM, the malware first copies explorer.exe into %TEMP%, naming the instance as tmpX.tmp (where X is an incremented decimal number), and then deletes the original file. The purpose of this activity is unclear, but it consumes high system resources. Next, the loader decrypts the kernel32.dll and VirtualProtect strings to retrieve their base addresses by calling the GetProcAddress API. Afterwards, it uses a single-byte XOR key to decrypt the shellcode, which is 9556 bytes long, and stores it at the same address in the .data section. Since the .data section does not have execute permission, the malware uses the VirtualProtect API to set the permission for the section. This allows for the decrypted shellcode to be executed without alerting security products by allocating new memory blocks. Before executing the shellcode, the malware prepares a 16-byte-long parameter structure that contains several items, with the most important one being the address of the encrypted MgBot configuration buffer.

Multi-stage shellcode execution

As mentioned above, the loader follows a unique delivery scheme, which includes at least two stages of payload. The shellcode employs a hashing algorithm known as PJW to resolve Windows APIs at runtime in a stealthy manner.
unsigned int calc_PJWHash(_BYTE *a1)
{
unsigned int v2;
v2 = 0;
while ( *a1 )
{
v2 = *a1++ + 16 * v2;
if ( (v2 & 0xF0000000) != 0 )
v2 = ~(v2 & 0xF0000000) & (v2 ^ ((v2 & 0xF0000000) >> 24));
}
return v2;
}
The shellcode first searches for a specific DAT file in the malware’s primary installation directory. If it is found, the shellcode decrypts it using the CryptUnprotectData API, a Windows API that decrypts protected data into allocated heap memory, and ensures that the data can only be decrypted on the particular machine by design. After decryption, the shellcode deletes the file to avoid leaving any traces of the valuable part of the attack chain.

If, however, the DAT file is not present, the shellcode initiates the next-stage shellcode installation process. It involves retrieving encrypted data from a web source that is actually an attacker-controlled server, by employing a DNS poisoning attack. Our telemetry shows that the attackers successfully obtained the encrypted second-stage shellcode, disguised as a PNG file, from the legitimate website dictionary[.]com. However, upon further investigation, it was discovered that the IP address associated with dictionary[.]com had been manipulated through a DNS poisoning technique. As a result, victims’ systems were resolving the website to different attacker-controlled IP addresses depending on the victims’ geographical location and internet service provider.

To retrieve the second-stage shellcode, the first-stage shellcode uses the RtlGetVersion API to obtain the current Windows version number and then appends a predefined string to the HTTP header:
sec-ch-ua-platform: windows %d.%d.%d.%d.%d.%d
This implies that the attackers needed to be able to examine request headers and respond accordingly. We suspect that the attackers’ collection of the Windows version number and its inclusion in the request headers served a specific purpose, likely allowing them to target specific operating system versions and even tailor their payload to different operating systems. Given that the Evasive Panda threat actor has been known to use distinct implants for Windows (MgBot) and macOS (Macma) in previous campaigns, it is likely that the malware uses the retrieved OS version string to determine which implant to deploy. This enables the threat actor to adapt their attack to the victim’s specific operating system by assessing results on the server side.

Downloading a payload from the web resource

From this point on, the first-stage shellcode proceeds to decrypt the retrieved payload with a XOR decryption algorithm:
key = *(mw_decryptedDataFromDatFile + 92);
index = 0;
if ( sz_shellcode )
{
mw_decryptedDataFromDatFile_1 = Heap;
do
{
*(index + mw_decryptedDataFromDatFile_1) ^= *(&key + (index & 3));
++index;
}
while ( index < sz_shellcode );
}
The shellcode uses a 4-byte XOR key, consistent with the one used in previous stages, to decrypt the new shellcode stored in the DAT file. It then creates a structure for the decrypted second-stage shellcode, similar to the first stage, including a partially decrypted configuration buffer and other relevant details.

Next, the shellcode resolves the VirtualProtect API to change the protection flag of the new shellcode buffer, allowing it to be executed with PAGE_EXECUTE_READWRITE permissions. The second-stage shellcode is then executed, with the structure passed as an argument. After the shellcode has finished running, its return value is checked to see if it matches 0x9980. Depending on the outcome, the shellcode will either terminate its own process or return control to the caller.

Although we were unable to retrieve the second-stage payload from the attackers’ web server during our analysis, we were able to capture and examine the next stage of the malware, which was to be executed afterwards. Our analysis suggests that the attackers may have used the CryptProtectData API during the execution of the second shellcode to encrypt the entire shellcode and store it as a DAT file in the malware’s main installation directory. This implies that the malware writes an encrypted DAT file to disk using the CryptProtectData API, which can then be decrypted and executed by the first-stage shellcode. Furthermore, it appears that the attacker attempted to generate a unique encrypted second shellcode file for each victim, which we believe is another technique used to evade detection and defense mechanisms in the attack chain.

Secondary loader

We identified a secondary loader, named libpython2.4.dll, which was disguised as a legitimate Windows library and used by the Evasive Panda group to achieve a stealthier loading mechanism. Notably, this malicious DLL loader relies on a legitimate, signed executable named evteng.exe (MD5: 1c36452c2dad8da95d460bee3bea365e), which is an older version of python.exe. This executable is a Python wrapper that normally imports the libpython2.4.dll library and calls the Py_Main function.

The secondary loader retrieves the full path of the current module (libpython2.4.dll) and writes it to a file named status.dat, located in C:\ProgramData\Microsoft\eHome, but only if a file with the same name does not already exist in that directory. We believe with a low-to-medium level of confidence that this action is intended to allow the attacker to potentially update the secondary loader in the future. This suggests that the attacker may be planning for future modifications or upgrades to the malware.

The malware proceeds to decrypt the next stage by reading the entire contents of C:\ProgramData\Microsoft\eHome\perf.dat. This file contains the previously downloaded and XOR-decrypted data from the attacker-controlled server, which was obtained through the DNS poisoning technique as described above. Notably, the implant downloads the payload several times and moves it between folders by renaming it. It appears that the attacker used a complex process to obtain this stage from a resource, where it was initially XOR-encrypted. The attacker then decrypted this stage with XOR and subsequently encrypted and saved it to perf.dat using a custom hybrid of Microsoft’s Data Protection Application Programming Interface (DPAPI) and the RC5 algorithm.

General overview of storing payload on disk by using hybrid encryption

This custom encryption algorithm works as follows. The RC5 encryption key is itself encrypted using Microsoft’s DPAPI and stored in the first 16 bytes of perf.dat. The RC5-encrypted payload is then appended to the file, following the encrypted key. To decrypt the payload, the process is reversed: the encrypted RC5 key is first decrypted with DPAPI, and then used to decrypt the remaining contents of perf.dat, which contains the next-stage payload.

The attacker uses this approach to ensure that a crucial part of the attack chain is secured, and the encrypted data can only be decrypted on the specific system where the encryption was initially performed. This is because the DPAPI functions used to secure the RC5 key tie the decryption process to the individual system, making it difficult for the encrypted data to be accessed or decrypted elsewhere. This makes it more challenging for defenders to intercept and analyze the malicious payload.

After completing the decryption process, the secondary loader initiates the runtime injection method, which likely involves the use of a custom runtime DLL injector for the decrypted data. The injector first calls the DLL entry point and then searches for a specific export function named preload. Although we were unable to determine which encrypted module was decrypted and executed in memory due to a lack of available data on the attacker-controlled server, our telemetry reveals that an MgBot variant is injected into the legitimate svchost.exe process after the secondary loader is executed. Fortunately, this allowed us to analyze these implants further and gain additional insights into the attack, as well as reveal that the encrypted initial configuration was passed through the infection chain, ultimately leading to the execution of MgBot. The configuration file was decrypted with a single-byte XOR key, 0x58, and this would lead to the full exposure of the configuration.

Our analysis suggests that the configuration includes a campaign name, hardcoded C2 server IP addresses, and unknown bytes that may serve as encryption or decryption keys, although our confidence in this assessment is limited. Interestingly, some of the C2 server addresses have been in use for multiple years, indicating a potential long-term operation.

Decryption of the configuration in the injected MgBot implant

Victims

Our telemetry has detected victims in Türkiye, China, and India, with some systems remaining compromised for over a year. The attackers have shown remarkable persistence, sustaining the campaign for two years (from November 2022 to November 2024) according to our telemetry, which indicates a substantial investment of resources and dedication to the operation.

Attribution

The techniques, tactics, and procedures (TTPs) employed in this compromise indicate with high confidence that the Evasive Panda threat actor is responsible for the attack. Despite the development of a new loader, which has been added to their arsenal, the decade-old MgBot implant was still identified in the final stage of the attack with new elements in its configuration. Consistent with previous research conducted by several vendors in the industry, the Evasive Panda threat actor is known to commonly utilize various techniques, such as supply-chain compromise, Adversary-in-the-Middle attacks, and watering-hole attacks, which enable them to distribute their payloads without raising suspicion.

Conclusion

The Evasive Panda threat actor has once again showcased its advanced capabilities, evading security measures with new techniques and tools while maintaining long-term persistence in targeted systems. Our investigation suggests that the attackers are continually improving their tactics, and it is likely that other ongoing campaigns exist. The introduction of new loaders may precede further updates to their arsenal.

As for the AitM attack, we do not have any reliable sources on how the threat actor delivers the initial loader, and the process of poisoning DNS responses for legitimate websites, such as dictionary[.]com, is still unknown. However, we are considering two possible scenarios based on prior research and the characteristics of the threat actor: either the ISPs used by the victims were selectively targeted, and some kind of network implant was installed on edge devices, or one of the network devices of the victims — most likely a router or firewall appliance — was targeted for this purpose. However, it is difficult to make a precise statement, as this campaign requires further attention in terms of forensic investigation, both on the ISPs and the victims.

The configuration file’s numerous C2 server IP addresses indicate a deliberate effort to maintain control over infected systems running the MgBot implant. By using multiple C2 servers, the attacker aims to ensure prolonged persistence and prevents loss of control over compromised systems, suggesting a strategic approach to sustaining their operations.

Indicators of compromise

File Hashes
c340195696d13642ecf20fbe75461bed sohuva_update_10.2.29.1-lup-s-tp.exe
7973e0694ab6545a044a49ff101d412a libpython2.4.dll
9e72410d61eaa4f24e0719b34d7cad19 (MgBot implant)

File Paths
C:\ProgramData\Microsoft\MF
C:\ProgramData\Microsoft\eHome\status.dat
C:\ProgramData\Microsoft\eHome\perf.dat

URLs and IPs
60.28.124[.]21 (MgBot C2)
123.139.57[.]103 (MgBot C2)
140.205.220[.]98 (MgBot C2)
112.80.248[.]27 (MgBot C2)
116.213.178[.]11 (MgBot C2)
60.29.226[.]181 (MgBot C2)
58.68.255[.]45 (MgBot C2)
61.135.185[.]29 (MgBot C2)
103.27.110[.]232 (MgBot C2)
117.121.133[.]33 (MgBot C2)
139.84.170[.]230 (MgBot C2)
103.96.130[.]107 (AitM C2)
158.247.214[.]28 (AitM C2)
106.126.3[.]78 (AitM C2)
106.126.3[.]56 (AitM C2)

securelist.com/evasive-panda-a…

UA: Динаміка втрат рашистів у війні проти України з 24 лютого 2022 року
index.minfin.com.ua/ua/russian…

EN: The dynamics of #ruscist losses in the war against Ukraine since February 24, 2022
index.minfin.com.ua/en/russian…

RU: Динамика потерь рашистов в войне против Украины с 24 февраля 2022 года
index.minfin.com.ua/russian-in…

Una Backdoor nel codice NVIDIA. 3 bug da 9.8 affliggono i sistemi di sviluppo di AI e robotica

Quando si parla di sicurezza informatica, non si può mai essere troppo prudenti.

Inoltre quando si parla di backdoor (o di presunte tali), la domanda che segue è: chi l’ha inserita? Era per scopo di manutenzione o per altri secondi fini? Ma gli Stati Uniti non parlavano di Backdoor nei prodotti cinesi inserite al loro interno? Ma ora che gli USA hanno sbloccato l’utilizzo di tecnologia NVIDIA verso la Cina?

Tante domande, tanti dubbi che si mischiano tra tecnologie a geopolitica.

Ma in sostanza, NVIDIA, il colosso delle GPU, ha appena rilasciato un aggiornamento di sicurezza urgente per il suo software Isaac Launchable Tre vulnerabilità critiche, tutte con un punteggio CVSS 9,8, minacciavano di compromettere la sicurezza dei sistemi interessati, e solo un aggiornamento può risolvere il problema.

Il colosso delle GPU ha rivelato tre distinte falle : CVE-2025-33222, CVE-2025-33223 e CVE-2025-33224, che segnalano un pericolo per gli ambienti di sviluppo robotico e di intelligenza artificiale.

Secondo il l’avviso rilasciato da NVIDIA “Isaac Launchable contiene una vulnerabilità che potrebbe consentire a un aggressore di sfruttare un problema di credenziali hard-coded”.

Le vulnerabilità interessano tutte le versioni del software precedenti alla nuova versione 1.1, esponendo gli utenti a rischi che vanno dall’esecuzione di codice in modalità remota alla manomissione dei dati.

Una falla di sicurezza estremamente critica, identificata come CVE-2025-33222, è costituita da un errore di sicurezza classico ma dalle conseguenze pesanti: l’utilizzo di credenziali codificate hardcoded. Un aggressore può sfruttare questa vulnerabilità per superare completamente il sistema di autenticazione, grazie a credenziali che sono state direttamente inserite nel codice del software. “Uno sfruttamento riuscito di questa vulnerabilità potrebbe portare all’esecuzione di codice, all’escalation dei privilegi, al diniego del servizio e alla manomissione dei dati”.

Gli utenti che utilizzano versioni precedenti alla 1.1 sono vulnerabili e dovrebbero effettuare immediatamente l’aggiornamento alla versione 1.1 per colmare queste lacune critiche nella sicurezza.

Le restanti due vulnerabilità, CVE-2025-33223 e CVE-2025-33224, derivano da una gestione impropria dei privilegi. Queste falle consentono a un aggressore di attivare esecuzioni con permessi superiori a quelli di cui avrebbe bisogno.

Vista l’entità “Critica” e la vasta estensione dei possibili danni, è vivamente consigliato da NVIDIA che tutti gli utenti installino la patch al più presto. Su tutte le piattaforme, le vulnerabilità sono relative a Isaac Launchable.

Come la falla nelle credenziali hard-coded , questi problemi possono portare alla compromissione completa del sistema. Le potenziali conseguenze sono ampie e includono “esecuzione di codice, escalation dei privilegi, negazione del servizio, divulgazione di informazioni e manomissione dei dati”.

L'articolo Una Backdoor nel codice NVIDIA. 3 bug da 9.8 affliggono i sistemi di sviluppo di AI e robotica proviene da Red Hot Cyber.

Bohdan Krotevych, #Ukraine lieutenant colonel , Chief of Staff of the Defense of Mariupol posted this:

I have reviewed the article “The Bear in the Baltics: Reassessing the Russian Threat in Estonia,” published by the European Council on Foreign Relations. Its authors, Jennifer Kavanagh and Jeremy Shapiro, conclude that #Russia is currently incapable of carrying out a successful armed attack against #Estonia and that the level of threat is exaggerated.

This is precisely where the core problem of this analysis begins.

The entire argument is built on theoretical models, force-balance calculations, and deterrence concepts, while completely ignoring the decisive factor of modern warfare: accumulated combat experience under real battlefield conditions.

Today, only two states in the world possess actual experience in conducting high-intensity interstate war — Ukraine and Russia. All others, including Estonia and the vast majority of #NATO members, rely on exercises, staff simulations, and doctrinal assumptions that have not been tested in full-scale combat.

Estonia, despite its high level of preparation, lacks practical experience in:

• conducting operations under conditions of sustained enemy artillery dominance and high fire density;

• operating forces in an environment of persistent surveillance and strike capability enabled by tactical and operational-level UAVs;

• maintaining logistics and command-and-control resilience under systematic fire strikes against rear infrastructure;

• executing defensive operations and maneuver while continuously absorbing losses, degradation of units, and uninterrupted fire pressure;

• adapting tactics, force organization, and command systems in real time, rather than after a completed training cycle.

This is not a criticism of the Estonian Defence Forces. It is a statement of fact: combat experience cannot be substituted by doctrines, exercises, or alliance membership.

A separate and particularly dangerous error in the article is the emphasis on Russia’s “exhaustion” through personnel losses.

Russia is structurally insensitive to human losses as a constraint on warfare. Its military-political system is historically designed to:

• sustain mass mobilization; • accept extremely high casualties as permissible; • substitute quality with quantity through forced rotation and replacement.

Those who treat manpower losses as a decisive deterrent factor for Russia project Western assumptions onto an adversary to whom they do not apply — and this is precisely how wars are lost.

The greatest damage done by this article is that it fosters a false sense of strategic confidence. It reassures decision-makers that Russia is “not ready,” “not capable,” or “will not dare.” This same logic underpinned strategic failures in both 2014 and 2022.

The most dangerous assumption made by the authors is that war is the outcome of a rational cost-benefit calculation. In reality, Russia wages war according to a logic of political inevitability, imperial revisionism, and a willingness to accept virtually any cost.

Russia will attack — this is not a question of capability, but of timing and conditions.

And the longer European decision-making centers rely on such reassuring, detached analyses, the more severe the shock will be when reality disproves them.

Source: x.com/BohdanKrotevych/status/2…

I’ve just spotted an interesting disinformation I suspect it targeted at European farmers, claiming that “huge multinational corporations” have just purchased 17 million hectares of arable land in #Ukraine - that has first appeared in 2024 but now was unfrozen and recycled, likely due to the wave of #Mercosur protests. The idea is simple - “if you can’t compete with Mercosur, Ukraine will be even worse”.

This 17m has drawn my attention because it’s easy to check. As it comes out, in the whole story the only true data is the number “17”.

Since 2024 Ukraine liberalised farming land purchases allowing large agricultural companies to buy and lease land, which was previously restricted.[^1] But it still must Ukrainian companies owned by citizens of Ukraine. And companies did… moderately.

Since 2024 there were in total 17’000 hectares of farming land purchased in the whole country. If you wonder how much that is, it’s a square 13x13 km. Because any farmer would laugh their eyes out on such “scare” (they know how much a hectare is), the authors of the fake had to modesty adjust it 1000x up.

More importantly, what is even more important is the land leases which accounted for 70’000 hectares in the whole country, including regions adjacent to the war zone, which boosted income of local communities impacted by the war. The liberalisation had none of the predicted negative impacts (“they will buy us all!”) and had all the positive impacts the farmers expected.

As an added bonus, #Monsanto does not exist since 2018, which should be the first red flag. This story had been already debunked by EUvsDisinfo in 2024[^2] but even they missed this bit :)

[^1]: kyivpost.com/post/37156

[^2]: euvsdisinfo.eu/report/ukraines…

Exploring Modern SID Chip Substitutes

The SIDKick Pico installed on a breadboard. (Credit: Ben Eater)
Despite the Commodore 64 having been out of production for probably longer than many Hackaday readers have been alive, its SID audio chip remains a very popular subject of both retrocomputing and modern projects. Consequently a range of substitutes have been developed over the decades, all of which seek to produce the audio quality of one or more variants of the SID. This raises the question of which of these to pick when at first glance they seem so similar. Fret not, for [Ben Eater] did an entire video on comparing some modern SID substitutes and his thoughts on them.

First is the SIDKick Pico, which as the name suggests uses a Raspberry Pi Pico board for its Cortex-M0+ MCU. This contrasts with the other option featured in the video, in the form of the STM32F410-based ARMSID.

While the SIDKick Pico looks good on paper, it comes with a number of different configurations, some with an additional DAC, which can be confusing. Because of how it is stacked together with the custom PCB on which the Pi Pico is mounted, it’s also pretty wide and tall, likely leading to fitment issues. It also doesn’t work as a drop-in solution by default, requiring soldering to use the SID’s normal output pins. Unfortunately this led to intense distortion in [Ben]’s testing leading him to give up on this.

Meanwhile the ARMSID is about as boring as drop-in replacements get. After [Ben] got the ARMSID out of its packaging, noted that it is sized basically identical to the original SID and inserted it into the breadboard, it then proceeded to fire right up with zero issues.

It’s clear that the SIDKick Pico comes with a lot of features and such, making it great for tinkering. However, if all you want is a SID-shaped IC that sounds like a genuine SID chip, then the ARMSID is a very solid choice.

Thanks to [Mark Stevens] for the tip.

youtube.com/embed/nooPmXxO6K0?…

hackaday.com/2025/12/23/explor…

Мои старенькие tws'ки всё чаще сбоят, и я задумался об полноразмерных наушниках. До этого ни одних не было.

Полистал какие-то [статьи](habr.com/ru/articles/427997/). Кодеки, помехи, заикания… Слишком утомительно. Взять чисто проводные, что ли? Правда, множество чисто проводных наушников не пересекается с множеством наушников с активным шумоподавлением, если я с фильтрами не напутал…