Nel contesto della lunga battaglia della Cina contro le frodi transfrontaliere , le autorità hanno emesso un verdetto in uno dei casi più eclatanti degli ultimi anni.

Riguarda una rete criminale su larga scala operante nel Myanmar settentrionale e collegata a quattro clan, soprannominati le “Quattro Grandi Famiglie” dai media cinesi. Il tribunale ha riconosciuto colpevoli 39 persone, 16 delle quali sono state condannate a morte, altre 11 all’ergastolo e le restanti a pene detentive comprese tra i 5 e i 24 anni.

Tra le persone giustiziate figurano figure chiave coinvolte nella creazione e nel controllo delle cosiddette fabbriche di frodi nelle telecomunicazioni.

L’indagine è iniziata nell’estate del 2023 in seguito a un tragico incidente avvenuto nella “Villa della Tigre Nascosta“, un enorme centro di frodi situato al confine tra Myanmar e Cina. Questa enclave recintata comprendeva hotel, centri commerciali ed edifici adibiti a centri per frodare i cittadini tramite Internet e telefono.

La struttura era sorvegliata da un esercito privato composto da circa duemila persone. Nell’ottobre di quell’anno, alcuni prigionieri impiegati come operatori di call center fraudolenti tentarono di fuggire. I soldati aprirono il fuoco sulla folla, uccidendo almeno sessanta persone. Rapporti non confermati suggeriscono che tra le vittime potrebbero esserci agenti delle forze dell’ordine cinesi sotto copertura impegnati in operazioni sotto copertura.

Questo incidente segnò una svolta. Già a novembre, il Ministero degli Interni cinese aveva annunciato una ricompensa per la cattura dei leader del gruppo. Nel giro di pochi giorni, quattro dei leader furono arrestati.

Ne è seguita un’operazione di cooperazione internazionale su larga scala: con la partecipazione del Ministero degli Affari Esteri del Myanmar, la Cina ha ottenuto l’estradizione di dieci boss della mafia, tra cui membri di tre clan.

Ognuna di queste famiglie controllava il proprio settore, dalle infrastrutture di telecomunicazione e dai casinò alla logistica e al riciclaggio di denaro. In alcuni casi, i sospettati erano legati al traffico di organi e di droga.

Successivamente, nel dicembre 2024, la Procura Suprema del Popolo cinese incriminò formalmente 39 membri di uno dei tre clan. I documenti del caso descrivevano dettagliatamente metodi brutali di controllo del “personale”: a molti prigionieri veniva offerto di comprare la libertà se non avessero raggiunto la quota giornaliera di vittime truffate.

Una delle vittime ha raccontato di essere stata picchiata con tubi d’acciaio per aver tentato di fuggire e di aver ucciso il suo compagno. La leadership del gruppo era ormai passata alla nipote del fondatore, dopo che il capo della famiglia si era sparato durante un tentativo di arresto da parte delle forze di sicurezza cinesi.

Secondo il Ministero degli Interni cinese, più di 53.000 presunti truffatori online sono stati rimpatriati dal Myanmar settentrionale durante l’operazione condotta dal 2023 alla fine del 2024.

L’efficace collaborazione tra le autorità dei due Paesi ha inferto un duro colpo all’infrastruttura ombra della criminalità informatica transfrontaliera , che la Cina combatte da anni.

L'articolo 11 condanne a morte per frode online. La Cina da un duro colpo alla criminalità informatica proviene da il blog della sicurezza informatica.

Il 3 ottobre 2025, su un noto forum del dark web è stato pubblicato un thread, da un utente identificato come KaruHunters. Nel post sostiene di aver compromesso i sistemi di Huawei Technologies Co., Ltd. e rivendica la messa in vendita di dati.

Attualmente, non possiamo confermare l’autenticità della notizia, poiché l’organizzazione non ha ancora pubblicato un comunicato ufficiale sul proprio sito web in merito all’incidente. Le informazioni riportate provengono da fonti pubbliche accessibili su siti underground, pertanto vanno interpretate come una fonte di intelligence e non come una conferma definitiva.

Secondo quanto dichiarato, la presunta violazione avrebbe permesso l’accesso al “source code” e “internal tools” dell’azienda. L’autore, è inoltre disponibile alla vendita del materiale o alla negoziazione privata con un prezzo di ingresso pari a 1.000 dollari. Non vengono forniti dettagli tecnici pubblici sulla modalità d’attacco o sulla natura specifica dei file sottratti. Ma, la disponibilità del codice sorgente suggerisce un’intrusione mirata ai sistemi di sviluppo o repository interni.

Il fatto che l’attore menzioni “tools interni” lascia intendere che l’accesso sia andato oltre un semplice dump di credenziali, indicando un livello di intrusione potenzialmente profondo.

Secondo i canali istituzionali di Huawei, al momento non ci sono evidenze pubbliche che confermino la veridicità della violazione. Secondo prassi CTI e giornalistica, in assenza di campioni verificabili o nota ufficiale, il caso resta “da confermare” e va maneggiato con prudenza.

Analisi del “Tree” allegato

L’analisi del file elenco allegato “Tree” (paste.txt), fa evincere che i contenuti elencati appartengono all’ecosistema TeX/CWEB e alla distribuzione TeX Live, includendo progetti open‑source come dvisvgm, brotli, woff2, potrace e una struttura di installazione “install‑tl‑20251003”.paste.txt
Secondo questa evidenza, non emergono namespace, pipeline o domini interni che permettano di inferire una fuga di proprietà intellettuale riconducibile a Huawei.paste.txt

L’attore citato

Consultando i feed OSINT, KaruHunters è presente nei tracciamenti come attore orientato alla monetizzazione di presunti data‑leak tramite vendite riservate e rilascio di indizi limitati.
Secondo le stesse fonti, l’attribuzione rimane indicativa in assenza di riscontri forensi indipendenti o conferme ufficiali.

Conclusione

Fino a una conferma ufficiale, il presunto Huawei Breach resta un caso da monitorare, ma non verificato. Se confermato, l’incidente potrebbe avere un impatto significativo in diversi ambiti:

• Rischio IP leakage: esposizione di codice sorgente e strumenti interni può facilitare exploit mirati.
• Reputazione aziendale: ulteriore pressione su Huawei, già spesso sotto scrutinio per questioni di sicurezza.
• Implicazioni geopolitiche: data la natura strategica dell’azienda, una compromissione potrebbe avere conseguenze anche a livello statale.

Le organizzazioni del settore dovrebbero mantenere un alto livello di allerta, aggiornare sistemi di monitoraggio su forum underground e verificare eventuali correlazioni con precedenti campagne attribuite a gruppi noti.

RHC monitorerà l’evoluzione della vicenda in modo da pubblicare ulteriori news sul blog, qualora ci fossero novità sostanziali. Qualora ci siano persone informate sui fatti che volessero fornire informazioni in modo anonimo possono utilizzare la mail crittografata del whistleblower.

L'articolo Huawei, presunta vendita di dati sul dark web proviene da il blog della sicurezza informatica.

Nel Regno Unito, hanno iniziato a testare un modo insolito per riscaldare le case: utilizzare mini data center alimentati da Raspberry Pi.

Il progetto è implementato da UK Power Networks nell’ambito del programma SHIELD (Smart Heat and Intelligent Energy in Low-Income Areas).

UK Power Networks gestisce la rete elettrica e le sottostazioni nel sud-est dell’Inghilterra ed è responsabile dell'”ultimo miglio” della fornitura di energia ai consumatori. Il programma SHIELD prevede l’installazione di pannelli solari e batterie nelle abitazioni e, in alcuni casi, la sostituzione delle caldaie a gas con i sistemi di elaborazione dati compatti HeatHub.

HeatHub è sviluppato e gestito da Thermify. Ogni unità contiene un cluster di 500 moduli di elaborazione Raspberry Pi Compute Module 4 o Compute Module 5, completamente immersi nell’olio. Il calore di scarto viene utilizzato per riscaldare gli ambienti e l’acqua calda, trasformando l’unità in un’alternativa intelligente alle caldaie a gas.

Il dispositivo si connette a una connessione Internet dedicata, così gli utenti non devono preoccuparsi di consumare la larghezza di banda della propria connessione domestica.

Secondo UKPN, il progetto pilota coinvolge Power Circle Projects, l’associazione per l’edilizia popolare Eastlight Community Homes e Essex Community Energy. L’esperimento testa anche una nuova “tariffa sociale” per il riscaldamento: le famiglie pagheranno una quota fissa di 5,60 sterline al mese (circa 7,50 dollari). Gli organizzatori stimano che il programma potrebbe ridurre le bollette energetiche del 20-40%.

“I risultati del progetto pilota sono molto incoraggianti”, ha affermato Charlie Edgar, rappresentante di Eastlight Community Homes. “Vediamo il potenziale per fornire alle famiglie un riscaldamento affidabile, prevedibile e conveniente, senza lo stress di bollette in aumento”.

Nella prima fase, SHIELD sta raccogliendo dati per ampliare il progetto: UKPN spera di installare 100.000 sistemi all’anno entro il 2030.

Iniziative simili sono già emerse nel Regno Unito. Ad esempio, Heata, un’azienda co-fondata da British Gas, offre una soluzione per l’installazione di server su caldaie domestiche, sfruttando i carichi di lavoro di elaborazione dati di partner come il provider cloud Civo. Un’altra azienda, Deep Green, utilizza mini data center per riscaldare aziende e piscine pubbliche, trasformando l’elaborazione dati in una fonte di calore.

L'articolo E’ possibile riscaldare una casa con i Raspberry Pi? Nel Regno Unito la risposta è si proviene da il blog della sicurezza informatica.

Pubblichiamo la traduzione del post pubblicato da Patrick Breyer oggi 6 ottobre Con una mossa drastica dell’ultimo minuto, il Ministero Federale dell’Interno, guidato dalla CSU, sta tentando di costringere il Ministero Federale della Giustizia (SPD) ad approvare il controverso chatcontrol UE entro martedì (7 ottobre) . Con il sostegno tedesco, si otterrebbe per la prima volta una maggioranza…

Source

IT'S MONDAY, AND THIS IS DIGITAL POLITICS. I'm Mark Scott, and I have many feelings about Sora, OpenAI's new AI-generated social media platform. Many of which are encapsulated by this video by Casey Neistat. #FreeTheSlop.

— The world's largest platforms have failed to respond to the highest level of global conflict since World War II.

— The semiconductor wars between China and the United States are creating a massive barrier between the world's two largest economies.

— China's DeepSeek performs significantly worse than its US counterparts on a series of benchmark tests.

Let's get started:

digitalpolitics.co/newsletter0…

DLL hijacking is a common technique in which attackers replace a library called by a legitimate process with a malicious one. It is used by both creators of mass-impact malware, like stealers and banking Trojans, and by APT and cybercrime groups behind targeted attacks. In recent years, the number of DLL hijacking attacks has grown significantly.

Trend in the number of DLL hijacking attacks. 2023 data is taken as 100% (download)

We have observed this technique and its variations, like DLL sideloading, in targeted attacks on organizations in Russia, Africa, South Korea, and other countries and regions. Lumma, one of 2025’s most active stealers, uses this method for distribution. Threat actors trying to profit from popular applications, such as DeepSeek, also resort to DLL hijacking.

Detecting a DLL substitution attack is not easy because the library executes within the trusted address space of a legitimate process. So, to a security solution, this activity may look like a trusted process. Directing excessive attention to trusted processes can compromise overall system performance, so you have to strike a delicate balance between a sufficient level of security and sufficient convenience.

Detecting DLL hijacking with a machine-learning model

Artificial intelligence can help where simple detection algorithms fall short. Kaspersky has been using machine learning for 20 years to identify malicious activity at various stages. The AI expertise center researches the capabilities of different models in threat detection, then trains and implements them. Our colleagues at the threat intelligence center approached us with a question of whether machine learning could be used to detect DLL hijacking, and more importantly, whether it would help improve detection accuracy.

Preparation

To determine if we could train a model to distinguish between malicious and legitimate library loads, we first needed to define a set of features highly indicative of DLL hijacking. We identified the following key features:

• Wrong library location. Many standard libraries reside in standard directories, while a malicious DLL is often found in an unusual location, such as the same folder as the executable that calls it.
• Wrong executable location. Attackers often save executables in non-standard paths, like temporary directories or user folders, instead of %Program Files%.
• Renamed executable. To avoid detection, attackers frequently save legitimate applications under arbitrary names.
• Library size has changed, and it is no longer signed.
• Modified library structure.

Training sample and labeling

For the training sample, we used dynamic library load data provided by our internal automatic processing systems, which handle millions of files every day, and anonymized telemetry, such as that voluntarily provided by Kaspersky users through Kaspersky Security Network.

The training sample was labeled in three iterations. Initially, we could not automatically pull event labeling from our analysts that indicated whether an event was a DLL hijacking attack. So, we used data from our databases containing only file reputation, and labeled the rest of the data manually. We labeled as DLL hijacking those library-call events where the process was definitively legitimate but the DLL was definitively malicious. However, this labeling was not enough because some processes, like “svchost”, are designed mainly to load various libraries. As a result, the model we trained on this data had a high rate of false positives and was not practical for real-world use.

In the next iteration, we additionally filtered malicious libraries by family, keeping only those which were known to exhibit DLL-hijacking behavior. The model trained on this refined data showed significantly better accuracy and essentially confirmed our hypothesis that we could use machine learning to detect this type of attacks.

At this stage, our training dataset had tens of millions of objects. This included about 20 million clean files and around 50,000 definitively malicious ones.

We then trained subsequent models on the results of their predecessors, which had been verified and further labeled by analysts. This process significantly increased the efficiency of our training.

Loading DLLs: what does normal look like?

So, we had a labeled sample with a large number of library loading events from various processes. How can we describe a “clean” library? Using a process name + library name combination does not account for renamed processes. Besides, a legitimate user, not just an attacker, can rename a process. If we used the process hash instead of the name, we would solve the renaming problem, but then every version of the same library would be treated as a separate library. We ultimately settled on using a library name + process signature combination. While this approach considers all identically named libraries from a single vendor as one, it generally produces a more or less realistic picture.

To describe safe library loading events, we used a set of counters that included information about the processes (the frequency of a specific process name for a file with a given hash, the frequency of a specific file path for a file with that hash, and so on), information about the libraries (the frequency of a specific path for that library, the percentage of legitimate launches, and so on), and event properties (that is, whether the library is in the same directory as the file that calls it).

The result was a system with multiple aggregates (sets of counters and keys) that could describe an input event. These aggregates can contain a single key (e.g., a DLL’s hash sum) or multiple keys (e.g., a process’s hash sum + process signature). Based on these aggregates, we can derive a set of features that describe the library loading event. The diagram below provides examples of how these features are derived:

Feature extraction from aggregates

Loading DLLs: how to describe hijacking

Certain feature combinations (dependencies) strongly indicate DLL hijacking. These can be simple dependencies. For some processes, the clean library they call always resides in a separate folder, while the malicious one is most often placed in the process folder.

Other dependencies can be more complex and require several conditions to be met. For example, a process renaming itself does not, on its own, indicate DLL hijacking. However, if the new name appears in the data stream for the first time, and the library is located on a non-standard path, it is highly likely to be malicious.

Model evolution

Within this project, we trained several generations of models. The primary goal of the first generation was to show that machine learning could at all be applied to detecting DLL hijacking. When training this model, we used the broadest possible interpretation of the term.

The model’s workflow was as simple as possible:

1. We took a data stream and extracted a frequency description for selected sets of keys.
2. We took the same data stream from a different time period and obtained a set of features.
3. We used type 1 labeling, where events in which a legitimate process loaded a malicious library from a specified set of families were marked as DLL hijacking.
4. We trained the model on the resulting data.

First-generation model diagram

The second-generation model was trained on data that had been processed by the first-generation model and verified by analysts (labeling type 2). Consequently, the labeling was more precise than during the training of the first model. Additionally, we added more features to describe the library structure and slightly complicated the workflow for describing library loads.

Second-generation model diagram

Based on the results from this second-generation model, we were able to identify several common types of false positives. For example, the training sample included potentially unwanted applications. These can, in certain contexts, exhibit behavior similar to DLL hijacking, but they are not malicious and rarely belong to this attack type.

We fixed these errors in the third-generation model. First, with the help of analysts, we flagged the potentially unwanted applications in the training sample so the model would not detect them. Second, in this new version, we used an expanded labeling that included useful detections from both the first and second generations. Additionally, we expanded the feature description through one-hot encoding — a technique for converting categorical features into a binary format — for certain fields. Also, since the volume of events processed by the model increased over time, this version added normalization of all features based on the data flow size.

Third-generation model diagram

Comparison of the models

To evaluate the evolution of our models, we applied them to a test data set none of them had worked with before. The graph below shows the ratio of true positive to false positive verdicts for each model.

Trends in true positives and false positives from the first-, second-, and third-generation models

As the models evolved, the percentage of true positives grew. While the first-generation model achieved a relatively good result (0.6 or higher) only with a very high false positive rate (10^⁻³ or more), the second-generation model reached this at 10^⁻⁵. The third-generation model, at the same low false positive rate, produced 0.8 true positives, which is considered a good result.

Evaluating the models on the data stream at a fixed score shows that the absolute number of new events labeled as DLL Hijacking increased from one generation to the next. That said, evaluating the models by their false verdict rate also helps track progress: the first model has a fairly high error rate, while the second and third generations have significantly lower ones.

False positives rate among model outputs, July 2024 – August 2025 (download)

Practical application of the models

All three model generations are used in our internal systems to detect likely cases of DLL hijacking within telemetry data streams. We receive 6.5 million security events daily, linked to 800,000 unique files. Aggregates are built from this sample at a specified interval, enriched, and then fed into the models. The output data is then ranked by model and by the probability of DLL hijacking assigned to the event, and then sent to our analysts. For instance, if the third-generation model flags an event as DLL hijacking with high confidence, it should be investigated first, whereas a less definitive verdict from the first-generation model can be checked last.

Simultaneously, the models are tested on a separate data stream they have not seen before. This is done to assess their effectiveness over time, as a model’s detection performance can degrade. The graph below shows that the percentage of correct detections varies slightly over time, but on average, the models detect 70–80% of DLL hijacking cases.

DLL hijacking detection trends for all three models, October 2024 – September 2025 (download)

Additionally, we recently deployed a DLL hijacking detection model into the Kaspersky SIEM, but first we tested the model in the Kaspersky MDR service. During the pilot phase, the model helped to detect and prevent a number of DLL hijacking incidents in our clients’ systems. We have written a separate article about how the machine learning model for detecting targeted attacks involving DLL hijacking works in Kaspersky SIEM and the incidents it has identified.

Conclusion

Based on the training and application of the three generations of models, the experiment to detect DLL hijacking using machine learning was a success. We were able to develop a model that distinguishes events resembling DLL hijacking from other events, and refined it to a state suitable for practical use, not only in our internal systems but also in commercial products. Currently, the models operate in the cloud, scanning hundreds of thousands of unique files per month and detecting thousands of files used in DLL hijacking attacks each month. They regularly identify previously unknown variations of these attacks. The results from the models are sent to analysts who verify them and create new detection rules based on their findings.

securelist.com/building-ml-mod…