выложили исходный код реестра военнообязанных

для доступа к onion-ресурсу используйте браузер Tor
micordd7k5zvuzz5lvmybxkj42zuzj…

вот так, например, выглядят SQL-запросы т.н. «бескомпроматного» удаления данных о «нужных людях» в модуле ЕКС, о котором мы ранее рассказывали вместе с журналистами Важных историй
micordd7k5zvuzz5lvmybxkj42zuzj…

более 300 параметров о 25 миллионах гражданах хранятся в едином реестре воинского учета
micordd7k5zvuzz5lvmybxkj42zuzj…

код, который выполняется, когда на сайте реестра повесток вы скачиваете выписку со своими данными:
micordd7k5zvuzz5lvmybxkj42zuzj…

спасибо всем, кто поддерживает Идите лесом!

The HoneyMyte APT evolves with a kernel-mode rootkit and a ToneShell backdoor

Overview of the attacks

In mid-2025, we identified a malicious driver file on computer systems in Asia. The driver file is signed with an old, stolen, or leaked digital certificate and registers as a mini-filter driver on infected machines. Its end-goal is to inject a backdoor Trojan into the system processes and provide protection for malicious files, user-mode processes, and registry keys.

Our analysis indicates that the final payload injected by the driver is a new sample of the ToneShell backdoor, which connects to the attacker’s servers and provides a reverse shell, along with other capabilities. The ToneShell backdoor is a tool known to be used exclusively by the HoneyMyte (aka Mustang Panda or Bronze President) APT actor and is often used in cyberespionage campaigns targeting government organizations, particularly in Southeast and East Asia.

The command-and-control servers for the ToneShell backdoor used in this campaign were registered in September 2024 via NameCheap services, and we suspect the attacks themselves to have begun in February 2025. We’ve observed through our telemetry that the new ToneShell backdoor is frequently employed in cyberespionage campaigns against government organizations in Southeast and East Asia, with Myanmar and Thailand being the most heavily targeted.

Notably, nearly all affected victims had previously been infected with other HoneyMyte tools, including the ToneDisk USB worm, PlugX, and older variants of ToneShell. Although the initial access vector remains unclear, it’s suspected that the threat actor leveraged previously compromised machines to deploy the malicious driver.

Compromised digital certificate

The driver file is signed with a digital certificate from Guangzhou Kingteller Technology Co., Ltd., with a serial number of 08 01 CC 11 EB 4D 1D 33 1E 3D 54 0C 55 A4 9F 7F. The certificate was valid from August 2012 until 2015.

We found multiple other malicious files signed with the same certificate which didn’t show any connections to the attacks described in this article. Therefore, we believe that other threat actors have been using it to sign their malicious tools as well. The following image shows the details of the certificate.

Technical details of the malicious driver

The filename used for the driver on the victim’s machine is ProjectConfiguration.sys. The registry key created for the driver’s service uses the same name, ProjectConfiguration.

The malicious driver contains two user-mode shellcodes, which are embedded into the .data section of the driver’s binary file. The shellcodes are executed as separate user-mode threads. The rootkit functionality protects both the driver’s own module and the user-mode processes into which the backdoor code is injected, preventing access by any process on the system.

API resolution

To obfuscate the actual behavior of the driver module, the attackers used dynamic resolution of the required API addresses from hash values.

The malicious driver first retrieves the base address of the ntoskrnl.exe and fltmgr.sys by calling ZwQuerySystemInformation with the SystemInformationClass set to SYSTEM_MODULE_INFORMATION. It then iterates through this system information and searches for the desired DLLs by name, noting the ImageBaseAddress of each.

Once the base addresses of the libraries are obtained, the driver uses a simple hashing algorithm to dynamically resolve the required API addresses from ntoskrnl.exe and fltmgr.sys.

The hashing algorithm is shown below. The two variants of the seed value provided in the comment are used in the shellcodes and the final payload of the attack.

Protection of the driver file

The malicious driver registers itself with the Filter Manager using FltRegisterFilter and sets up a pre-operation callback. This callback inspects I/O requests for IRP_MJ_SET_INFORMATION and triggers a malicious handler when certain FileInformationClass values are detected. The handler then checks whether the targeted file object is associated with the driver; if it is, it forces the operation to fail by setting IOStatus to STATUS_ACCESS_DENIED. The relevant FileInformationClass values include:

• FileRenameInformation
• FileDispositionInformation
• FileRenameInformationBypassAccessCheck
• FileDispositionInformationEx
• FileRenameInformationEx
• FileRenameInformationExBypassAccessCheck

These classes correspond to file-delete and file-rename operations. By monitoring them, the driver prevents itself from being removed or renamed – actions that security tools might attempt when trying to quarantine it.

Protection of registry keys

The driver also builds a global list of registry paths and parameter names that it intends to protect. This list contains the following entries:

• ProjectConfiguration
  
• ProjectConfiguration\Instances
  
• ProjectConfiguration Instance

To guard these keys, the malware sets up a RegistryCallback routine, registering it through CmRegisterCallbackEx. To do so, it must assign itself an altitude value. Microsoft governs altitude assignments for mini-filters, grouping them into Load Order categories with predefined altitude ranges. A filter driver with a low numerical altitude is loaded into the I/O stack below filters with higher altitudes. The malware uses a hardcoded starting point of 330024 and creates altitude strings in the format 330024.%l, where %l ranges from 0 to 10,000.

The malware then begins attempting to register the callback using the first generated altitude. If the registration fails with STATUS_FLT_INSTANCE_ALTITUDE_COLLISION, meaning the altitude is already taken, it increments the value and retries. It repeats this process until it successfully finds an unused altitude.

The callback monitors four specific registry operations. Whenever one of these operations targets a key from its protected list, it responds with 0xC0000022 (STATUS_ACCESS_DENIED), blocking the action. The monitored operations are:

• RegNtPreCreateKey
  
• RegNtPreOpenKey
  
• RegNtPreCreateKeyEx
  
• RegNtPreOpenKeyEx

Microsoft designates the 320000–329999 altitude range for the FSFilter Anti-Virus Load Order Group. The malware’s chosen altitude exceeds this range. Since filters with lower altitudes sit deeper in the I/O stack, the malicious driver intercepts file operations before legitimate low-altitude filters like antivirus components, allowing it to circumvent security checks.

Finally, the malware tampers with the altitude assigned to WdFilter, a key Microsoft Defender driver. It locates the registry entry containing the driver’s altitude and changes it to 0, effectively preventing WdFilter from being loaded into the I/O stack.

Protection of user-mode processes

The malware sets up a list intended to hold protected process IDs (PIDs). It begins with 32 empty slots, which are filled as needed during execution. A status flag is also initialized and set to 1 to indicate that the list starts out empty.

Next, the malware uses ObRegisterCallbacks to register two callbacks that intercept process-related operations. These callbacks apply to both OB_OPERATION_HANDLE_CREATE and OB_OPERATION_HANDLE_DUPLICATE, and both use a malicious pre-operation routine.

This routine checks whether the process involved in the operation has a PID that appears in the protected list. If so, it sets the DesiredAccess field in the OperationInformation structure to 0, effectively denying any access to the process.

The malware also registers a callback routine by calling PsSetCreateProcessNotifyRoutine. These callbacks are triggered during every process creation and deletion on the system. This malware’s callback routine checks whether the parent process ID (PPID) of a process being deleted exists in the protected list; if it does, the malware removes that PPID from the list. This eventually removes the rootkit protection from a process with an injected backdoor, once the backdoor has fulfilled its responsibilities.

Payload injection

The driver delivers two user-mode payloads.

The first payload spawns an svchost process and injects a small delay-inducing shellcode. The PID of this new svchost instance is written to a file for later use.

The second payload is the final component – the ToneShell backdoor – and is later injected into that same svchost process.

Injection workflow:

The malicious driver searches for a high-privilege target process by iterating through PIDs and checking whether each process exists and runs under SeLocalSystemSid. Once it finds one, it customizes the first payload using random event names, file names, and padding bytes, then creates a named event and injects the payload by attaching its current thread to the process, allocating memory, and launching a new thread.

After injection, it waits for the payload to signal the event, reads the PID of the newly created svchost process from the generated file, and adds it to its protected process list. It then similarly customizes the second payload (ToneShell) using random event name and random padding bytes, then creates a named event and injects the payload by attaching to the process, allocating memory, and launching a new thread.

Once the ToneShell backdoor finishes execution, it signals the event. The malware then removes the svchost PID from the protected list, waits 10 seconds, and attempts to terminate the process.

ToneShell backdoor

The final stage of the attack deploys ToneShell, a backdoor previously linked to operations by the HoneyMyte APT group and discussed in earlier reporting (see Malpedia and MITRE). Notably, this is the first time we’ve seen ToneShell delivered through a kernel-mode loader, giving it protection from user-mode monitoring and benefiting from the rootkit capabilities of the driver that hides its activity from security tools.

Earlier ToneShell variants generated a 16-byte GUID using CoCreateGuid and stored it as a host identifier. In contrast, this version checks for a file named C:\ProgramData\MicrosoftOneDrive.tlb, validating a 4-byte marker inside it. If the file is absent or the marker is invalid, the backdoor derives a new pseudo-random 4-byte identifier using system-specific values (computer name, tick count, and PRNG), then creates the file and writes the marker. This becomes the unique ID for the infected host.

The samples we have analyzed contact two command-and-control servers:

• avocadomechanism[.]com
  
• potherbreference[.]com

ToneShell communicates with its C2 over raw TCP on port 443 while disguising traffic using fake TLS headers. This version imitates the first bytes of a TLS 1.3 record (0x17 0x03 0x04) instead of the TLS 1.2 pattern used previously. After this three-byte marker, each packet contains a size field and an encrypted payload.

Packet layout:

• Header (3 bytes): Fake TLS marker
• Size (2 bytes): Payload length
• Payload: Encrypted with a rolling XOR key

The backdoor supports a set of remote operations, including file upload/download, remote shell functionality, and session control. The command set includes:

Conclusion

We assess with high confidence that the activity described in this report is linked to the HoneyMyte threat actor. This conclusion is supported by the use of the ToneShell backdoor as the final-stage payload, as well as the presence of additional tools long associated with HoneyMyte – such as PlugX, and the ToneDisk USB worm – on the impacted systems.

HoneyMyte’s 2025 operations show a noticeable evolution toward using kernel-mode injectors to deploy ToneShell, improving both stealth and resilience. In this campaign, we observed a new ToneShell variant delivered through a kernel-mode driver that carries and injects the backdoor directly from its embedded payload. To further conceal its activity, the driver first deploys a small user-mode component that handles the final injection step. It also uses multiple obfuscation techniques, callback routines, and notification mechanisms to hide its API usage and track process and registry activity, ultimately strengthening the backdoor’s defenses.

Because the shellcode executes entirely in memory, memory forensics becomes essential for uncovering and analyzing this intrusion. Detecting the injected shellcode is a key indicator of ToneShell’s presence on compromised hosts.

Recommendations

To protect themselves against this threat, organizations should:

• Implement robust network security measures, such as firewalls and intrusion detection systems.
• Use advanced threat detection tools, such as endpoint detection and response (EDR) solutions.
• Provide regular security awareness training to employees.
• Conduct regular security audits and vulnerability assessments to identify and remediate potential vulnerabilities.
• Consider implementing a security information and event management (SIEM) system to monitor and analyze security-related data.

By following these recommendations, organizations can reduce their risk of being compromised by the HoneyMyte APT group and other similar threats.

Indicators of Compromise

More indicators of compromise, as well as any updates to these, are available to the customers of our APT intelligence reporting service. If you are interested, please contact intelreports@kaspersky.com.

36f121046192b7cac3e4bec491e8f1b5 AppvVStram_.sys
fe091e41ba6450bcf6a61a2023fe6c83 AppvVStram_.sys
abe44ad128f765c14d895ee1c8bad777 ProjectConfiguration.sys
avocadomechanism[.]com ToneShell C2
potherbreference[.]com ToneShell C2

securelist.com/honeymyte-kerne…

39C3: Hardware, and the Hard Bit

The 39th annual Chaos Communication Congress (39C3) is underway, and it kicked off with a talk that will resonate deeply with folks in the Hackaday universe. [Kliment] gave an impassioned invitation for everyone to start making hardware based on his experience both in the industry and in giving an intro-to-surface-mount workshop to maybe thousands of hackers over the years.

His main points are that the old “hardware is hard” cliche is overdone. Of course, working on a complicated high-reliability medical device isn’t child’s play, but that’s not where you start off. And getting started in hardware design and hobby-scale manufacture has never been easier or cheaper, and the open-source tooling gives you a foot in the door.

He tells the story of an attendee at a workshop who said “I kept waiting for the hard part to come, but then I was finished.” Starting off with the right small-scale projects, learning a few techniques, and ramping up skills built on skills is the way to go. ([Kliment] is a big proponent of hand-placed hot-plate reflow soldering, and we concur.)

This is the talk that you want to show to your software friends who are hardware-curious. It’s also a plea for more experimentation, more prototyping, more hacking, and simply more people in the hardware / DIY electronics scene. Here at Hackaday, it’s maybe preaching to the choir, but sometimes it’s just nice to hear saying it all out loud.

hackaday.com/2025/12/29/39c3-h…

WebKit sotto attacco: un bug matematico può mandare in crash milioni di iPhone

Un nuovo rapporto descrive in dettaglio una vulnerabilità critica scoperta da Joseph Goydish, un ricercatore di sicurezza, nel motore WebKit di Apple. Questa falla di sicurezza, se sfruttata insieme ad altri exploit, potrebbe consentire agli aggressori di eseguire codice arbitrario sui più recenti dispositivi iOS.

Il difetto, identificato come un pericoloso bug di integer overflow in iOS 26.2, potrebbe anche permettere agli aggressori di bloccare i browser. La scoperta evidenzia la presenza di questo bug e il suo potenziale impatto sulla sicurezza dei dispositivi.

La vulnerabilità deriva da un classico errore software: un overflow di interi. Secondo il rapporto, il problema si verifica durante il calcolo dei limiti di memoria per le operazioni ArrayBuffer, TypedArray e WebAssembly.

La falla di sicurezza interessa il motore JavaScriptCore (JSC), elemento centrale di Safari e di tutti i browser di terze parti su iOS. Gli hacker potrebbero sfruttare tale vulnerabilità, che rappresenta una “primitiva deterministica”, per condurre attacchi più pericolosi, nonostante le misure di difesa integrate da Apple siano al momento efficaci.

“La vulnerabilità è dovuta a un overflow di interi durante il calcolo degli offset di memoria per le operazioni TypedArray e DataView”, spiega l’analisi.

La vulnerabilità è stata confermata su iOS 26.2 (Build 23C55) in esecuzione su un iPhone 14 Pro Max. Il rapporto suggerisce che l’impatto è probabilmente più ampio e potrebbe interessare:

• Tutte le versioni di iOS 26.x
• macOS Sequoia 15.x
• Tutti i browser iOS di terze parti (poiché devono utilizzare il motore WKWebView).

Goydish ha fornito una Proof of Concept (PoC) che dimostra la falla utilizzando solo poche righe di JavaScript. Creando un buffer DataView e impostando un valore Uint32 specifico, il codice forza il wrap-around a 32 bit, innescando il crash.

Per ora, gli utenti sono protetti da Gigacage, il meccanismo di partizionamento di sicurezza di WebKit . Quando l’overflow tenta di accedere alla memoria al di fuori della partizione consentita da 16 GB, Gigacage rileva la violazione e termina immediatamente il processo WebContent.

Quando il sistema moltiplica un indice per la dimensione di un elemento, il risultato può “aggirarsi attorno al limite dei 32 bit”. Questo errore matematico confonde il sistema, consentendo a un aggressore di richiedere un indirizzo di memoria che tecnicamente supera il controllo iniziale ma punta a una posizione ben al di fuori della zona sicura.

Sebbene ciò impedisca l’esecuzione immediata di codice dannoso, provoca un Denial of Service (DoS) persistente, che causa l’arresto anomalo immediato del browser o delle visualizzazioni web incorporate.

Tuttavia, il rapporto avverte che questa rete di sicurezza non è invincibile. “Se Gigacage venisse bypassato o il suo indirizzo di base venisse trapelato, questa vulnerabilità abilita la corruzione relativa della memoria”, consentendo agli aggressori di manipolare gli oggetti adiacenti al buffer in overflow.

Nel peggiore dei casi, ciò potrebbe portare all’esecuzione di codice remoto (RCE) tramite “Vtable Hijacking”, in cui gli aggressori danneggiano i puntatori di funzione virtuali per assumere il controllo del puntatore di istruzioni del dispositivo.

“Attualmente, Gigacage impedisce lo sfruttamento terminando il processo prima che si verifichi un danneggiamento della memoria”, conclude il rapporto, ma la presenza di un difetto logico così fondamentale serve da duro promemoria della fragile matematica alla base della moderna sicurezza web.

L'articolo WebKit sotto attacco: un bug matematico può mandare in crash milioni di iPhone proviene da Red Hot Cyber.

Login Microsoft 365 falsi, JavaScript offuscato e Cloudflare: anatomia di un phishing avanzato

Questo articolo analizza una recente e sofisticata campagna di phishing che sfrutta la tecnica Browser-in-the-Browser (BitB) per rubare credenziali, in particolare quelle di servizi come Microsoft 365. L’attacco BitB si distingue per la sua capacità di generare una falsa finestra di login che imita in modo iper-realistico un browser ufficiale, ingannando l’utente e inducendolo a inserire i dati in una schermata apparentemente legittima.

L’analisi tecnica rivela che la pericolosità di questa campagna risiede non solo nell’inganno visivo, ma anche in una complessa architettura di occultamento e anti-analisi. L’attacco è preceduto da una landing page di verifica che implementa una pipeline di decodifica JavaScript a più stadi per offuscare il payload finale, filtrare bot e sistemi di sicurezza automatizzati, e contrastare l’analisi forense.

Questo meccanismo di difesa multi-livello permette all’attacco di eludere i rilevamenti iniziali da parte degli endpoint di sicurezza e di raggiungere l’obiettivo in modo più efficace.

Vengono infine sottolineate alcune misure difensive, come la verifica costante della barra degli indirizzi reale e l’adozione dell’autenticazione a più fattori.

Come funziona l’attacco BitB

La pagina malevola genera una finestra che imita perfettamente Microsoft Edge, mostrando persino un URL autentico come login.microsoftonline.com.

In realtà, si tratta di un semplice elemento grafico spostabile all’interno della pagina, mentre la barra degli indirizzi reale del browser punta a un dominio sconosciuto.

L’utente, convinto di trovarsi su un sito legittimo, viene invitato a “Sign in with Microsoft” per accedere a un documento. Inserendo le credenziali, queste finiscono direttamente nelle mani degli attaccanti.

Breve analisi

Catena di attacco:

Behance

II vettore di attacco iniziale è un’email di phishing che induce la vittima a scaricare un file malevolo (o una presunta risorsa) tramite un link che reindirizza a un portale legittimo, come Behance (behance.net/).

A sua volta viene chiesto di aprire un link per scaricare un documento.

Landing 1

Prima che la vera pagina venga visualizzata, ne viene mostrata una intermedia che viene usata nel contesto di attività malevole o campagne di phishing per diversi scopi, il più importante dei quali è l’anti-analisi e l’occultamento del contenuto finale sospetto, come l’analisi su Virus Total.

L’analisi della landing page tramite VirusTotal aveva rilevato solo un endpoint come sospetto. Successivamente, in un’analisi successiva, il numero di endpoint che hanno segnalato la pagina come sospetta è salito a tre.

Nel loader iniziale infatti è presente un codice JavaScript che implementa una pipeline di decodifica a quattro passaggi per offuscare e recuperare dati sensibili, utilizzato per nascondere stringhe, URL o frammenti HTML.

Questo file viene avviato prima di presentare la pagina sospetta perché agisce come un gate di sicurezza multilivello, vengono usare queste misure per:

• filtrare i bot: se è un bot o un sistema di sicurezza automatizzato, viene reindirizzato e non vede la pagina di phishing. Questo serve a evitare che la pagina venga contrassegnata come “sospetta” da servizi come Google Safe Browsing.
• nasconde il payload: il codice della minaccia finale (il “payload”) è offuscato e non è immediatamente visibile nel codice sorgente iniziale.
• mitigare le possibili analisi: le misure anti-debugging rendono estremamente difficile per un ricercatore di sicurezza analizzare la minaccia, in quanto il codice cerca attivamente di rilevare e bloccare gli strumenti di analisi.

Questo è un frammento di codice del loader offuscato. Inaspettatamente sono inseriti anche i commenti sul codice su tutte le operazioni eseguite, per cui è subito di facile lettura.

Un’analisi approfondita della risoluzione DNS e alla chiamata http rivela che il dominio malevolo è attestato dietro l’infrastruttura di Cloudflare, che agisce come un proxy inverso (Reverse Proxy). Questa configurazione non è casuale: l’attaccante sfrutta deliberatamente strumenti nati per la protezione e l’ottimizzazione dei dati per garantirsi un anonimato strategico.

Attraverso questo ‘scudo’, l’attore malevolo riesce a nascondere l’indirizzo IP reale del server di origine, eludere i controlli di sicurezza perimetrale basati su reputazione IP e massimizzare la vita utile della campagna di phishing.

Landing 2

Una volta risolto il “puzzle” viene usato un nuovo passaggio intermedio con caratteristiche analoghe al precedente.

Target

Quest’ultimo con un ulteriore redirect porta alla pagina progettata per simulare una richiesta di autenticazione Microsoft per poter accedere a un documento..

Anche in questa pagina è presente del contenuto offuscato. Inoltre sfruttando il fingerprinting del sistema operativo aggiungendo classi CSS specifiche (.browser-window.edge.dark o .browser-window.safari) al falso browser per farlo apparire esattamente come la finestra del browser dell’utente.

Cliccato il bottone per autenticarsi con Microsoft, viene fatta partire in background una nuova chiamata http per recuperare il contenuto di un form di Microsoft.

Quindi successivamente viene simulato apertura di finto browser sull’area della pagina (nel nostro caso Microsoft Edge), che visualizza il login di Microsoft con tanto di url “autentico”.

Questa tecnica come accennato è nota come Browser-in-the-Browser (BITB) Attack.

Un kit per capire la tecnica

Lo sviluppatore mr.d0x ha pubblicato su GitHub, a scopo didattico, il kit “BitB Attack”, che consente di creare moduli di accesso di phishing basati su Single Sign-On estremamente realistici.
Link: github.com/lucthienphong1120/B…

Conclusioni

Come emerso dall’analisi, la vera insidia si cela nella complessa architettura di occultamento che precede l’attacco finale.

La presenza di una sofisticata sequenza di decodifica JavaScript, unita alle pagine di verifica e alle misure anti-analisi e anti-bot, dimostra un elevato livello di preparazione da parte degli attaccanti.

Queste precauzioni non solo nascondono il payload dalle scansioni automatiche di sicurezza (come quelle di VirusTotal), ma rendono anche estremamente difficile per gli analisti di sicurezza decifrare e bloccare la minaccia in tempo.

L’attacco finale BitB infine induce a un l’inganno visivo per via della creazione di una falsa finestra di browser tramite elementi grafici per rubare le credenziali.

La pubblicazione di strumenti didattici come il kit “BitB Attack” da parte di mr.d0x, sebbene a scopo di ricerca, sottolinea la facilità con cui questa tecnica può essere replicata, rendendo la minaccia accessibile a un ampio spettro di malintenzionati.

Per difendersi efficacemente è necessario prestare sempre attenzione alle mail di spam, verificare sempre URL Reale e in questi casi avere l’autenticazione MFA attiva.

L'articolo Login Microsoft 365 falsi, JavaScript offuscato e Cloudflare: anatomia di un phishing avanzato proviene da Red Hot Cyber.