Looking for an educational microcontroller board to get you or a loved one into electronics? Consider the tinyCore – a small and nifty hexagon-shaped ESP32 board by [MR. INDUSTRIES], simplified for learning yet featureful enough to offer plenty of growth, and fully open.

The tinyCore board’s hexagonal shape makes it more flexible for building wearables than the vaguely rectangular boards we’re used to, and it’s got a good few onboard gadgets. Apart from already expected WiFi, BLE, and GPIOs, you get battery management, a 6DoF IMU (LSM6DSOX) in the center of the board, a micro SD card slot for all your data needs, and two QWIIC connectors. As such, you could easily turn it into, say, a smartwatch, a motion-sensitive tracker, or a controller for a small robot – there’s even a few sample projects for you to try.

You can buy one, or assemble a few yourself thanks to the open-source-ness – and, to us, the biggest factor is the [MR.INDUSTRIES] community, with documentation, examples, and people learning with this board and sharing what they make. Want a device with a big display that similarly wields a library of examples and a community? Perhaps check out the Cheap Yellow Display hacks!

youtube.com/embed/3Nd6zynJclk?…

We thank [Keith Olson] for sharing this with us!

hackaday.com/2025/12/11/tinyco…

Un nuovo allarme arriva dal sottobosco del cybercrime arriva poche ore fa. A segnalarlo l’azienda ParagonSec, società specializzata nel monitoraggio delle attività delle cyber gang e dei marketplace clandestini, che ha riportato la comparsa su un forum underground di un presunto database contenente oltre 700.000 record appartenenti ad un Registro Professionale Italiano non meglio precisato.

L’annuncio, pubblicato da un utente che si firma gtaviispeak, descrive la disponibilità di una “fresh db” contenente una quantità impressionante di informazioni sensibili di un database ad oggi sconosciuto che contiene dati personali estremamente dettagliati.

Disclaimer: Questo rapporto include screenshot e/o testo tratti da fonti pubblicamente accessibili. Le informazioni fornite hanno esclusivamente finalità di intelligence sulle minacce e di sensibilizzazione sui rischi di cybersecurity. Red Hot Cyber condanna qualsiasi accesso non autorizzato, diffusione impropria o utilizzo illecito di tali dati. Al momento, non è possibile verificare in modo indipendente l’autenticità delle informazioni riportate, poiché l’organizzazione coinvolta non ha ancora rilasciato un comunicato ufficiale sul proprio sito web. Di conseguenza, questo articolo deve essere considerato esclusivamente a scopo informativo e di intelligence.
Print Screen fornito da Paragon Sec a Red Hot Cyber

Il contenuto del database: un rischio elevatissimo

Secondo quanto riportato nel post, il database includerebbe una lunga lista di campi, tra cui:

• Dati anagrafici completi: nome, cognome, sesso, luogo di nascita, data di nascita
• Codice fiscale
• Email e numeri telefonici (fissi e cellulari)
• Password (non è noto di quale sito siano riferite)
• Dati lavorativi: ente di lavoro, ruolo, categoria professionale
• Indirizzi di residenza e domicilio
• CAP, provincia, comune
• Eventuali informazioni di gruppo e stato professionale
• Dati amministrativi di registrazione
• Indirizzo IP associato all’utente

La presenza di password in chiaro (o comunque disponibili nel dump) aumenta notevolmente il rischio di compromissioni successive, soprattutto se gli utenti riutilizzano le stesse credenziali su altri servizi.

La vendita avviene su Telegram

Il venditore invita gli interessati a contattarlo tramite un canale Telegram dedicato, una prassi ormai consolidata nelle dinamiche di vendita di database sottratti illegalmente. Nel post è presente anche un link a un presunto sample del dataset, finalizzato a dimostrare l’autenticità del materiale.

Una minaccia concreta per cittadini e aziende

Se confermato, questo leak rappresenta un rischio significativo per:

• Frodi fiscali grazie alla disponibilità del codice fiscale
• Phishing altamente mirato (spear phishing) basato su dati personali e professionali
• Furti d’identità attraverso combinazioni di dati anagrafici, contatti e credenziali
• Attacchi contro enti pubblici o professionali, sfruttando i dati lavorativi e l’email associata

Il livello di dettaglio dei campi elencati suggerisce che si tratti di un database istituzionale o comunque proveniente da una piattaforma amministrativa con dati certificati.

Sebbene un utente del forum abbia precisato che gli account non sarebbero ‘fresh’, ciò incide ben poco: informazioni come dati anagrafici, codice fiscale e recapiti non cambiano nel tempo. Di conseguenza, il materiale resta estremamente sensibile e può essere sfruttato con facilità per diverse tipologie di frodi.

Le fughe di dati provenienti da enti pubblici e registri professionali stanno aumentando in tutta Europa. I cybercriminali puntano sempre più su database certificati e ufficiali, poiché consentono attacchi più credibili e redditizi.

L'articolo 700.000 record di un Registro Professionale Italiano in vendita nel Dark Web proviene da Red Hot Cyber.

Gli specialisti di Securonix hanno scoperto una campagna malware multilivello volta a installare segretamente lo strumento di accesso remoto NetSupport RAT. L’attacco si sviluppa attraverso una serie di fasi accuratamente nascoste, ciascuna progettata per garantire la massima discrezione e lasciare tracce minime sul dispositivo compromesso.

Il download iniziale del codice dannoso inizia con un file JavaScript iniettato nei siti web hackerati. Questo script ha una struttura complessa e una logica nascosta che si attiva solo quando vengono soddisfatte determinate condizioni.

È in grado di rilevare il tipo di dispositivo dell’utente e anche di registrare se è la prima volta che visita la pagina, consentendogli di eseguire azioni dannose una sola volta per dispositivo. Se le condizioni sono soddisfatte, lo script inietta un frame invisibile nella pagina o carica la fase successiva: un’applicazione HTML.

La seconda fase, riportano i ricercatori, prevede l’avvio di un file HTA, un’applicazione nascosta eseguita tramite lo strumento nativo di Windows mshta.exe. Estrae lo script PowerShell crittografato, lo decrittografa utilizzando un processo a più fasi e lo esegue direttamente in memoria. Ciò garantisce che tutte le attività dannose si verifichino senza creare file persistenti, ostacolando significativamente il rilevamento da parte del software antivirus.

Il passaggio finale prevede il download e l’installazione del NetSupport RAT. Per farlo, uno script di PowerShell scarica l’archivio, lo decomprime in una directory poco visibile e avvia il file eseguibile tramite un wrapper JScript. Per mantenerne la presenza nel sistema, viene creato un collegamento nella cartella di avvio, camuffato da componente di Windows Update. Questo approccio consente agli aggressori di mantenere l’accesso anche dopo il riavvio del dispositivo.

NetSupport RAT è uno strumento di amministrazione remota inizialmente legittimo, utilizzato attivamente dagli aggressori per attività di spionaggio, furto di dati e controllo remoto. Durante questa campagna, ottiene il pieno controllo del sistema infetto, intercettando l’input da tastiera, gestendo i file, eseguendo comandi e utilizzando funzioni proxy per navigare all’interno della rete.

Gli esperti stimano che l’infrastruttura dannosa sia costantemente sottoposta a manutenzione e aggiornamento e che la sua architettura indichi l’elevata competenza degli sviluppatori. L’attacco prende di mira gli utenti dei sistemi aziendali e si diffonde attraverso siti web falsi e reindirizzamenti nascosti. Nonostante l’elevato livello di sofisticazione, non è stato ancora possibile stabilire l’esatta affiliazione degli operatori con alcun gruppo criminale informatico noto.

La campagna rilevata evidenzia l’importanza di bloccare l’esecuzione di script non firmati, rafforzare il controllo sul comportamento dei processi di sistema, monitorare le directory di avvio e analizzare le attività di rete sospette. Si raccomanda particolare attenzione nel limitare l’uso di mshta.exe e nel monitorare i tentativi di download di file nelle cartelle %TEMP% e ProgramData.

L'articolo NetSupport RAT: il malware invisibile che gli antivirus non possono fermare proviene da Red Hot Cyber.

Marco Perduca al Teatro Off/Off per “Diritto a stare bene”

Marco Perduca, coordinatore delle iniziative dell’Associazione Luca Coscioni sulla ricerca e l’uso terapeutico delle sostanze psichedeliche parteciperà alla celebrazione del raggiungimento delle 72.000 firme raccolte a sostegno della campagna nazionale “Diritto a Stare Bene”

Teatro Off/Off, Via Giulia 20 – Roma
Sabato 13 dicembre 2025
Ore 16:00 – 19:00

La proposta di legge di iniziativa popolare mira all’istituzione di un servizio nazionale pubblico di psicologia, accessibile, gratuito e integrato nel Servizio Sanitario Nazionale.

Insieme a lui interverranno Maria Teresa Bellucci (viceministra del Lavoro e delle Politiche Sociali), Maura Latini (Presidente Coop Italia), Francesco Maesano (coordinatore nazionale Diritto a stare bene), Michela Marzano (filosofa e docente universitaria),Linda Laura Sabbadini (statistica e pioniera negli studi di genere),Maria Antonietta Gulino (Presidente CNOP) e Parlamentari di diversi schieramenti.

A seguire, dalle ore 20:00, la festa continuerà al Campomagnetico (Vicolo delle Grotte 3) con un talk show targato Mentifricio e DJ set.

L'articolo Marco Perduca al Teatro Off/Off per “Diritto a stare bene” proviene da Associazione Luca Coscioni.

Il nuovo Piano Nazionale di Governo delle Liste d’Attesa viene presentato come la risposta sistemica ai ritardi nell’erogazione di visite ed esami, con l’obiettivo dichiarato di garantire maggiore trasparenza, tempi certi e tutele per gli utenti. Tuttavia, dentro questo impianto che ambisce alla modernizzazione del sistema, continua a persistere un vuoto enorme: quello dei servizi sociosanitari. RSA, interventi per la disabilità, residenzialità psichiatrica, centri diurni e assistenza domiciliare integrata restano completamente fuori dal perimetro del Piano, nonostante siano prestazioni riconosciute come Livelli Essenziali di Assistenza e finanziate dal Fondo sanitario nazionale. Non compaiono nelle tabelle dei tempi massimi, non sono associate a percorsi di tutela, e non esistono per esse standard nazionali di pubblicità delle graduatorie o di presa in carico entro tempi determinati. L’effetto è immediato: per migliaia di persone, l’attesa non ha limiti né garanzie.

Ne deriva un Paese a due velocità. Per una prestazione diagnostica, il cittadino può invocare tempi precisi e un quadro normativo che ne tutela il diritto; per un posto in RSA, per l’ingresso in una struttura per persone con disabilità grave o per avviare un percorso di cura residenziale in ambito psichiatrico, la stessa persona si ritrova relegata in un limbo amministrativo senza scadenze. Accade così che individui che hanno già superato la valutazione UVM/UVG, ai quali è stato riconosciuto un bisogno sanitario e approvato un progetto assistenziale personalizzato, rimangano per mesi – spesso anni – con la sola etichetta di “collocato in graduatoria”, espressione che nasconde la totale assenza di un termine entro cui la prestazione deve essere garantita. È una distorsione che amplifica le differenze territoriali e che si pone in evidente contrasto con il principio di uguaglianza e con il diritto alla salute sancito dalla Costituzione. È incomprensibile che una prestazione sanitaria tradizionale debba essere erogata entro limiti certi, mentre una prestazione sociosanitaria, pur definita essenziale, sia lasciata oscillare tra disponibilità di posti, bilanci regionali e scelte amministrative mutevoli. Un’anomalia normativa e culturale che ricade proprio su chi è più fragile e sulle famiglie già gravate da responsabilità di cura.

In un contesto così carente, il cittadino è costretto a farsi carico di azioni di tutela. La prima è l’accesso agli atti: chiedere formalmente contezza della propria posizione, dei punteggi utilizzati per la valutazione, delle regole di priorità e dello storico degli scorrimenti. Obbligare l’amministrazione a mostrare i dati riduce lo spazio per arbitri e inerzie. Fondamentale anche richiedere aggiornamenti periodici, sempre per iscritto, sulla situazione della graduatoria e sui posti effettivamente disponibili. Quando l’attesa supera ogni ragionevolezza o il bisogno è particolarmente urgente, diventa necessario presentare una diffida formalizzata, richiamando il carattere essenziale delle prestazioni sociosanitarie, l’obbligo di assicurare i LEA e la giurisprudenza che tutela il nucleo incomprimibile del diritto alla salute. Nei casi più gravi, soprattutto quando la mancata presa in carico produce un danno diretto alla persona o alla famiglia, è possibile valutare il ricorso al giudice amministrativo o civile per ottenere l’attuazione del progetto individuale o la prestazione in deroga*. Non si tratta della via preferibile, ma spesso è l’unica che interrompe lo stallo istituzionale.

Non dovrebbe essere così. Un sistema sanitario “ambulatorialecentrico” che ignora le persone con bisogni complessi e di lunga durata rinuncia alla propria funzione pubblica più fondamentale. Finché il PNGLA continuerà a lasciare fuori l’integrazione sociosanitaria, il diritto alla salute resterà solido solo per le esigenze “semplici”, mentre diventerà incerto e contrattabile per chi necessita di percorsi assistenziali continuativi. Portare i servizi sociosanitari dentro il PNGLA non è mero tecnicismo amministrativo: è una scelta politica, culturale e civile. È il passo che ancora manca per superare la distanza storica tra sanità e sociale, per realizzare davvero l’integrazione sociosanitaria e per ridurre diseguaglianze che oggi gravano soprattutto sulle persone con cronicità, disabilità e non autosufficienza. Un sistema moderno non può più permettersi di relegare il bisogno più fragile ai margini della programmazione nazionale.

*Consiglio di Stato nella sent. n. 1 del 2020:

“[…] Ritiene il Collegio che una volta individuate le necessità dei disabili tramite il Piano individualizzato, l’attuazione del dovere di rendere il servizio comporti l’attivazione dei poteri -doveri di elaborare tempestivamente le proposte relative all’individuazione delle risorse necessarie a coprire il fabbisogno e, comunque, l’attivazione di ogni possibile soluzione organizzativa. […]…”

L'articolo Le prestazioni sociosanitarie e le liste d’attesa: l’assenza ingiustificabile dal PNGLA proviene da Associazione Luca Coscioni.

Post-exploitation frameworks

Threat actors frequently employ post-exploitation frameworks in cyberattacks to maintain control over compromised hosts and move laterally within the organization’s network. While they once favored closed-source frameworks, such as Cobalt Strike and Brute Ratel C4, open-source projects like Mythic, Sliver, and Havoc have surged in popularity in recent years. Malicious actors are also quick to adopt relatively new frameworks, such as Adaptix C2.

Analysis of popular frameworks revealed that their development focuses heavily on evading detection by antivirus and EDR solutions, often at the expense of stealth against systems that analyze network traffic. While obfuscating an agent’s network activity is inherently challenging, agents must inevitably communicate with their command-and-control servers. Consequently, an agent’s presence in the system and its malicious actions can be detected with the help of various network-based intrusion detection systems (IDS) and, of course, Network Detection and Response (NDR) solutions.

This article examines methods for detecting the Mythic framework within an infrastructure by analyzing network traffic. This framework has gained significant traction among various threat actors, including Mythic Likho (Arcane Wolf) и GOFFEE (Paper Werewolf), and continues to be used in APT and other attacks.

The Mythic framework

Mythic C2 is a multi-user command and control (C&C, or C2) platform designed for managing malicious agents during complex cyberattacks. Mythic is built on a Docker container architecture, with its core components – the server, agents, and transport modules – written in Python. This architecture allows operators to add new agents, communication channels, and custom modifications on the fly.

Since Mythic is a versatile tool for the attacker, from the defender’s perspective, its use can align with multiple stages of the Unified Kill Chain, as well as a large number of tactics, techniques, and procedures in the MITRE ATT&CK® framework.

• Pivoting is a tactic where the attacker uses an already compromised system as a pivot point to gain access to other systems within the network. In this way, they gradually expand their presence within the organization’s infrastructure, bypassing firewalls, network segmentation, and other security controls.
• Collection (TA0009) is a tactic focused on gathering and aggregating information of value to the attacker: files, credentials, screenshots, and system logs. In the context of network operations, collection is often performed locally on compromised hosts, with data then packaged for transfer. Tools like Mythic automate the discovery and selection of data sought by the adversary.
• Exfiltration (TA0010) is the process of moving collected information out of the secured network via legitimate or covert channels, such as HTTP(s), DNS, or SMB, etc. Attackers may use resident agents or intermediate relays (pivot hosts) to conceal the exfiltration source and route.
• Command and Control (TA0011) encompasses the mechanisms for establishing and maintaining a communication channel between the operator and compromised hosts to transmit commands and receive status updates. This includes direct connections, relaying through pivot hosts, and the use of covert protocols. Frameworks like Mythic provide advanced C2 capabilities, such as scheduled command execution, tunneling, and multi-channel communication, which complicate the detection and blocking of their activity.

This article focuses exclusively on the Command and Control (TA0011) tactic, whose techniques can be effectively detected within the network traffic of Mythic agents.

Detecting Mythic agent activity in network traffic

At the time of writing, Mythic supports data transfer over HTTP/S, WebSocket, TCP, SMB, DNS, and MQTT. The platform also boasts over a dozen different agents, written in Go, Python, and C#, designed for Windows, macOS, and Linux.

Mythic employs two primary architectures for its command network:

• In this model, agents communicate with adjacent agents forming a chain of connections which eventually leads to a node communicating directly with the Mythic C2 server. For this purpose, agents utilize TCP and SMB.
• In this model, agents communicate directly with the C2 server via HTTP/S, WebSocket, MQTT, or DNS.

P2P communication

Mythic provides pivoting capabilities via named SMB pipes and TCP sockets. To detect Mythic agent activity in P2P mode, we will examine their network traffic and create corresponding Suricata detection rules (signatures).

P2P communication via SMB

When managing agents via the SMB protocol, a named pipe is used by default for communication, with its name matching the agent’s UUID.

Although this parameter can be changed, it serves as a reliable indicator and can be easily described with a regular expression. Example:
[a-z0-9]{8}\-[a-z0-9]{4}\-[a-z0-9]{4}\-[a-z0-9]{4}\-[a-z0-9]{12}

For SMB communication, agents encode and encrypt data according to the pattern: base64(UUID+AES256(JSON)). This data is then split into blocks and transmitted over the network. The screenshot below illustrates what a network session for establishing a connection between agents looks like in Wireshark.

Commands and their responses are packaged within the MythicMessage data structure. This structure contains three header fields, as well as the commands themselves or the corresponding responses:

• Total size (4 bytes)
• Number of data blocks (4 bytes)
• Current block number (4 bytes)
• Base64-encoded data

The screenshot below shows an example of SMB communication between agents.

The agent (10.63.101.164) sends a command to another agent in the MythicMessage format. The first three Write Requests transmit the total message size, total number of blocks, and current block number. The fourth request transmits the Base64-encoded data. This is followed by a sequence of Read Requests, which are also transmitted in the MythicMessage format.

Below are the data transmitted in the fourth field of the MythicMessage structure.

The content is encoded in Base64. Upon decoding, the structure of the transmitted information becomes visible: it begins with the UUID of the infected host, followed by a data block encrypted using AES-256.

The fact that the data starts with a UUID string can be leveraged to create a signature-based detection rule that searches network packets for the identifier pattern.

To search for packets containing a UUID, the following signature can be applied. It uses specific request types and protocol flags as filters (Command: Ioctl (11), Function: FSCTL_PIPE_WAIT (0x00110018)), followed by a check to see if the pipe name matches the UUID pattern.
alert tcp any any -> any [139, 445] (msg: "Trojan.Mythic.SMB.C&C"; flow: to_server, established; content: "|fe|SMB"; offset: 4; depth: 4; content: "|0b 00|"; distance: 8; within: 2; content: "|18 00 11 00|"; distance: 48; within: 12; pcre: "/\x48\x00\x00\x00[\x00-\xFF]{2}([a-z0-9]\x00){8}\-\x00([a-z0-9]\x00){4}\-\x00([a-z0-9]\x00){4}\-\x00([a-z0-9]\x00){4}\-\x00([a-z0-9]\x00){12}$/R"; threshold: type both, track by_src, count 1, seconds 60; reference: url, github.com/MythicC2Profiles/sm… classtype: ndr1; sid: 9000101; rev: 1;)
Agent activity can also be detected by analyzing data transmitted in SMB WriteRequest packets with the protocol flag Command: Write (9) and a distinct packet structure where the BlobOffset and BlobLen fields are set to zero. If the Data field is Base64-encoded and, after decoding, begins with a UUID-formatted string, this indicates a command-and-control channel.
alert tcp any any -> any [139, 445] (msg: "Trojan.Mythic.SMB.C&C"; flow: to_server, established; dsize: > 360; content: "|fe|SMB"; offset: 4; depth: 4; content: "|09 00|"; distance: 8; within: 2; content: "|00 00 00 00 00 00 00 00 00 00 00 00|"; distance: 86; within: 12; base64_decode: bytes 64, offset 0, relative; base64_data; pcre: "/^[a-z0-9]{8}\-[a-z0-9]{4}\-[a-z0-9]{4}\-[a-z0-9]{4}\-[a-z0-9]{12}/"; threshold: type both, track by_src, count 1, seconds 60; reference: url, github.com/MythicC2Profiles/sm… classtype: ndr1; sid: 9000102; rev: 1;)
Below is the KATA NDR user interface displaying an alert about detecting a Mythic agent operating in P2P mode over SMB. In this instance, the first rule – which checks the request type, protocol flags, and the UUID pattern – was triggered.

It should be noted that these signatures have a limitation. If the SMBv3 protocol with encryption enabled is used, Mythic agent activity cannot be detected with signature-based methods. A possible alternative is behavioral analysis. However, in this context, it suffers from low accuracy and a high false-positive rate. The SMB protocol is widely used by organizations for various legitimate purposes, making it difficult to isolate behavioral patterns that definitively indicate malicious activity.

P2P communication via TCP

Mythic also supports P2P communications via TCP. The connection initialization process appears in network traffic as follows:

As with SMB, the MythicMessage structure is used for transmitting and receiving data. First, the data length (4 bytes) is sent as a big-endian DWORD in a separate packet. Subsequent packets transmit the number of data blocks, the current block number, and the data itself. However, unlike SMB packets, the value of the current block number field is always 0x00000000, due to TCP’s built-in packet fragmentation support.

The data encoding scheme is also analogous to what we observed with SMB and appears as follows: base64(UUID+AES256(JSON)). Below is an example of a network packet containing Mythic data.

The decoded data appears as follows:

Similar to communication via SMB, signature-based detection rules can be created for TCP traffic to identify Mythic agent activity by searching for packets containing UUID-formatted strings. Below are two Suricata detection rules. The first rule is a utility rule. It does not generate security alerts but instead tags the TCP session with an internal flag, which is then checked by another rule. The second rule verifies the flag and applies filters to confirm that the current packet is being analyzed at the beginning of a network session. It then decodes the Base64 data and searches the resulting content for a UUID-formatted string.
alert tcp any any -> any any (msg: "Trojan.Mythic.TCP.C&C"; flow: from_server, established; dsize: 4; stream_size: server, <, 6; stream_size: client, <, 3; content: "|00 00|"; depth: 2; pcre: "/^\x00\x00[\x00-\x5C]{1}[\x00-\xFF]{1}$/"; flowbits: set, mythic_tcp_p2p_msg_len; flowbits: noalert; threshold: type both, track by_src, count 1, seconds 60; reference: url, github.com/MythicC2Profiles/tc… classtype: ndr1; sid: 9000103; rev: 1;)

alert tcp any any -> any any (msg: "Trojan.Mythic.TCP.C&C"; flow: from_server, established; dsize: > 300; stream_size: server, <, 6000; stream_size: client, <, 6000; flowbits: isset, mythic_tcp_p2p_msg_len; content: "|00 00 00|"; depth: 3; content: "|00 00 00 00|"; distance: 1; within: 4; base64_decode: bytes 64, offset 0, relative; base64_data; pcre: "/^[a-z0-9]{8}\-[a-z0-9]{4}\-[a-z0-9]{4}\-[a-z0-9]{4}\-[a-z0-9]{12}/"; threshold: type both, track by_src, count 1, seconds 60; reference: url, github.com/MythicC2Profiles/tc… classtype: ndr1; sid: 9000104; rev: 1;)
Below is the NDR interface displaying an example of the two rules detecting a Mythic agent operating in P2P mode over TCP.

Egress transport modules

Covert Egress communication

For stealthy operations, Mythic allows agents to be managed through popular services. This makes its activity less conspicuous within network traffic. Mythic includes transport modules based on the following services:

• Discord
• GitHub
• Slack

Of these, only the first two remain relevant at the time of writing. Communication via Slack (the Slack C2 Profile transport module) is no longer supported by the developers and is considered deprecated, so we will not examine it further.

The Discord C2 Profile transport module

The use of the Discord service as a mediator for C2 communication within the Mythic framework has been gaining popularity recently. In this scenario, agent traffic is indistinguishable from normal Discord activity, with commands and their execution results masquerading as messages and file attachments. Communication with the server occurs over HTTPS and is encrypted with TLS. Therefore, detecting Mythic traffic requires decrypting this.

Analyzing decrypted TLS traffic

Let’s assume we are using an NDR platform in conjunction with a network traffic decryption (TLS inspection) system to detect suspicious network activity. In this case, we operate under the assumption that we can decrypt all TLS traffic. Let’s examine possible detection rules for that scenario.

Agent and server communication occurs via Discord API calls to send messages to a specific channel. Communication between the agent and Mythic uses the MythicMessageWrapper structure, which contains the following fields:

• message: the transmitted data
• sender_id: a GUID generated by the agent, included in every message
• to_server: a direction flag – a message intended for the server or the agent
• id: not used
• final: not used

Of particular interest to us is the message field, which contains the transmitted data encoded in Base64. The MythicMessageWrapper message is transmitted in plaintext, making it accessible to anyone with read permissions for messages on the Discord server.

Below is an example of data transmission via messages in a Discord channel.

To establish a connection, the agent authenticates to the Discord server via the API call /api/v10/gateway/bot. We observe the following data in the network traffic:

After successful initialization, the agent gains the ability to receive and respond to commands. To create a message in the channel, the agent makes a POST request to the API endpoint /channels/<channel.id>/messages. The network traffic for this call is shown in the screenshot below.

After decoding the Base64, the content of the message field appears as follows:

A structure characteristic of a UUID is visible at the beginning of the packet.

After processing the message, the agent deletes it from the channel via a DELETE request to the API endpoint /channels/{channel.id}/messages/{message.id}.

Below is a Suricata rule that detects the agent’s Discord-based communication activity. It checks the API activity for creating HTTP messages for the presence of Base64-encoded data containing the agent’s UUID.
alert tcp any any -> any any (msg: "Trojan.Mythic.HTTP.C&C"; flow: to_server, established; content: "POST"; http_method; content: "/api/"; http_uri; content: "/channels/"; distance: 0; http_uri; pcre: "/\/messages$/U"; content: "|7b 22|content|22|"; depth: 20; http_client_body; content: "|22|sender_id"; depth: 1500; http_client_body; pcre: "/\x22sender_id\x5c\x22\x3a\x5c\x22[a-z0-9]{8}\-[a-z0-9]{4}\-[a-z0-9]{4}\-[a-z0-9]{4}\-[a-z0-9]{12}/"; threshold: type both, track by_src, count 1, seconds 60; reference: url, github.com/MythicC2Profiles/di… classtype: ndr1; sid: 9000105; rev: 1;)
Below is the NDR user interface displaying an example of detecting the activity of the Discord C2 Profile transport module for a Mythic agent within decrypted HTTP traffic.

Analyzing encrypted TLS traffic

If Discord usage is permitted on the network and there is no capability to decrypt traffic, it becomes nearly impossible to detect agent activity. In this scenario, behavioral analysis of requests to the Discord server may prove useful. Below is network traffic showing frequent TLS connections to the Discord server, which could indicate commands being sent to an agent.

In this case, we can use a Suricata rule to detect the frequent TLS sessions with Discord servers:
alert tcp any any -> any any (msg: "NetTool.PossibleMythicDiscordEgress.TLS.C&C"; flow: to_server, established; tls_sni; content: "discord.com"; nocase; threshold: type both, track by_src, count 4, seconds 420; reference: url, github.com/MythicC2Profiles/di… classtype: ndr3; sid: 9000106; rev: 1;)
Another method for detecting these communications involves tracking multiple DNS queries to the discord.com domain.

The following rule can be applied to detect these:
alert udp any any -> any 53 (msg: "NetTool.PossibleMythicDiscordEgress.DNS.C&C"; content: "|01 00 00 01 00 00 00 00 00 00|"; depth: 10; offset: 2; content: "|07|discord|03|com|00|"; nocase; distance: 0; threshold: type both, track by_src, count 4, seconds 60; reference: url, github.com/MythicC2Profiles/di… classtype: ndr3; sid: 9000107; rev: 1;)
Below is the NDR user interface showing an example of a custom rule in operation, detecting the activity of the Discord C2 Profile transport module for a Mythic agent within encrypted traffic based on characteristic DNS queries.

The proposed rule options have low accuracy and can generate a high number of false positives. Therefore, they must be adapted to the specific characteristics of the infrastructure in which they will run. Threshold and count parameters, which control the triggering frequency and time window, require tuning.

GitHub C2 Profile transport module

GitHub’s popularity has made it an attractive choice as a mediator for managing Mythic agents. The core concept is the same as in other covert Egress communication transport modules. Communication with GitHub utilizes HTTPS. Successful operation requires an account on the target platform and the ability to communicate via API calls. The transport module utilizes the GitHub API to send comments to pre-created Issues and to commit files to a branch within a repository controlled by the attackers. In this model, the agent interacts only with GitHub: it creates and reads comments, uploads files, and manages branches. It does not communicate with any other servers. The communication algorithm via GitHub is as follows:

1. The agent posts a comment (check-in) to a designated Issue on GitHub, intended for agents to report their results.
2. The Mythic server validates the comment, deletes it, and posts a reply in an issue designated for server use.
3. The agent creates a branch with a name matching its UUID and writes a get_tasking file to it (performs a push request).
4. The Mythic server reads the file and writes a response file to the same branch.
5. The agent reads the response file, deletes the branch, pauses, and repeats the cycle.

Analyzing decrypted TLS traffic

Let’s consider an approach to detecting agent activity when traffic decryption is possible.

Agent communication with the server utilizes API calls to GitHub. The payload is encoded in Base64 and published in plaintext; therefore, anyone who can view the repository or analyze the traffic contents can decode it.

Analysis of agent communication revealed that the most useful traffic for creating detection rules is associated with publishing check-in comments, creating a branch, and publishing a file.

During the check-in phase, the agent posts a comment to register a new agent and establish communication.

The transmitted data is encoded in Base64 and contains the agent’s UUID and the portion of the message encrypted using AES-256.

This allows for a signature that detects UUID-formatted substrings within GitHub comment creation requests.
alert tcp any any -> any any (msg: "Trojan.Mythic.HTTP.C&C"; flow: to_server, established; content: "POST"; http_method; content: "api.github.com"; http_host; content: "/repos/"; depth: 8; http_uri; pcre: "/\/comments$/U"; content: "|22|body|22|"; depth: 8; http_client_body; base64_decode: bytes 300, offset 2, relative; base64_data; pcre: "/^[a-z0-9]{8}\-[a-z0-9]{4}\-[a-z0-9]{4}\-[a-z0-9]{4}\-[a-z0-9]{12}/"; threshold: type both, track by_src, count 1, seconds 60; reference: url, github.com/MythicC2Profiles/gi… classtype: ndr1; sid: 9000108; rev: 1;)
Another stage suitable for detection is when the agent creates a separate branch with its UUID as the name. All subsequent relevant communication with the server will occur within this branch. Here is an example of a branch creation request:

Therefore, we can create a detection rule to identify UUID-formatted strings within branch creation requests.
alert tcp any any -> any any (msg: "Trojan.Mythic.HTTP.C&C"; flow: to_server, established; content: "POST"; http_method; content: "api.github.com"; http_host; content: "/repos/"; depth: 100; http_uri; content: "/git/refs"; distance: 0; http_uri; content: "|22|ref|22 3a|"; depth: 10; http_client_body; content: "refs/heads/"; distance: 0; within: 50; http_client_body; pcre: "/refs\/heads\/[a-z0-9]{8}\-[a-z0-9]{4}\-[a-z0-9]{4}\-[a-z0-9]{4}\-[a-z0-9]{12}\x22/"; threshold: type both, track by_src, count 1, seconds 60; reference: url, github.com/MythicC2Profiles/gi… classtype: ndr1; sid: 9000109; rev: 1;)
After creating the branch, the agent writes a file to it (sends a push request), which contains Base64-encoded data.

Therefore, we can create a rule to trigger on file publication requests to a branch whose name matches the UUID pattern.
alert tcp any any -> any any (msg: "Trojan.Mythic.HTTP.C&C"; flow: to_server, established; content: "PUT"; http_method; content: "api.github.com"; http_host; content: "/repos/"; depth:8; http_uri; content: "/contents/"; distance: 0; http_uri; content: "|22|content|22|"; depth: 100; http_client_body; pcre: "/\x22message\x22\x3a\x22[a-z0-9]{8}\-[a-z0-9]{4}\-[a-z0-9]{4}\-[a-z0-9]{4}\-[a-z0-9]{12}\x22/"; threshold: type both, track by_src, count 1, seconds 60; reference: url, github.com/MythicC2Profiles/gi… classtype: ndr1; sid: 9000110; rev: 1;)
The screenshot below shows how the NDR solution logs all suspicious communications using the GitHub API and subsequently identifies the Mythic agent’s activity. The result is an alert with the verdict Trojan.Mythic.HTTP.C&C.

Analyzing encrypted TLS traffic

Communication with GitHub occurs over HTTPS; therefore, in the absence of traffic decryption capability, signature-based methods for detecting agent activity cannot be applied. Let’s consider a behavioral agent activity detection approach.

For instance, it is possible to detect connections to GitHub servers that are atypical in frequency and purpose, originating from network segments where this activity is not expected. The screenshot below shows an example of an agent’s multiple TLS sessions. The traffic reflects the execution of several commands, as well as idle time, manifested as constant polling of the server while awaiting new tasks.

Multiple TLS sessions with the GitHub service from uncharacteristic network segments can be detected using the rule presented below:
alert tcp any any -> any any (msg:"NetTool.PossibleMythicGitHubEgress.TLS.C&C"; flow: to_server, established; tls_sni; content: "api.github.com"; nocase; threshold: type both, track by_src, count 4, seconds 60; reference: url, github.com/MythicC2Profiles/gi… classtype: ndr3; sid: 9000111; rev: 1;)

Additionally, multiple DNS queries to the service can be logged in the traffic.

This activity is detected with the help of the following rule:
alert udp any any -> any 53 (msg: "NetTool.PossibleMythicGitHubEgress.DNS.C&C"; content: "|01 00 00 01 00 00 00 00 00 00|"; depth: 10; offset: 2; content: "|03|api|06|github|03|com|00|"; nocase; distance: 0; threshold: type both, track by_src, count 12, seconds 180; reference: url, github.com/MythicC2Profiles/gi… classtype: ndr3; sid: 9000112; rev: 1;)
The screenshot below shows the NDR interface with an example of the first rule in action, detecting traces of the GitHub profile activity for a Mythic agent within encrypted TLS traffic.

The suggested rule options can produce false positives, so to improve their effectiveness, they must be adapted to the specific characteristics of the infrastructure in which they will run. The parameters of the threshold keyword – specifically the count and seconds values, which control the number of events required to generate an alert and the time window for their occurrence in NDR – must be configured.

Direct Egress communication

The Egress communication model allows agents to interact directly with the C2 server via the following protocols:

• HTTP(S)
• WebSocket
• MQTT
• DNS

The first two protocols are the most prevalent. The DNS-based transport module is still under development, and the module based on MQTT sees little use among operators. We will not examine them within the scope of this article.

Communication via HTTP

HTTP is the most common protocol for building a Mythic agent control network. The HTTP transport container acts as a proxy between the agents and the Mythic server. It allows data to be transmitted in both plaintext and encrypted form. Crucially, the metadata is not encrypted, which enables the creation of signature-based detection rules.

Below is an example of unencrypted Mythic network traffic over HTTP. During a GET request, data encoded in Base64 is passed in the value of the query parameter.

After decoding, the agent’s UUID – generated according to a specific pattern – becomes visible. This identifier is followed by a JSON object containing the key parameters of the host, collected by the agent.

If data encryption is applied, the network traffic for agent communication appears as shown in the screenshot below.

After decrypting the traffic and decoding from Base64, the communication data reveals the familiar structure: UUID+AES256(JSON).

Therefore, to create a detection signature for this case, we can also rely on the presence of a UUID within the Base64-encoded data in POST requests.
alert tcp any any -> any any (msg: "Trojan.Mythic.HTTP.C&C"; flow: to_server, established; content: "POST"; http_method; content: "|0D 0A 0D 0A|"; base64_decode: bytes 80, offset 0, relative; base64_data; content: "-"; offset: 8; depth: 1; content: "-"; distance: 4; within: 1; content: "-"; distance: 4; within: 1; content: "-"; distance: 4; within: 1; pcre: "/[0-9a-fA-F]{8}\-[0-9a-fA-F]{4}\-[0-9a-fA-F]{4}\-[0-9a-fA-F]{4}\-[0-9a-fA-F]{12}/"; threshold: type both, track by_src, count 1, seconds 180; reference: md5, 6ef89ccee639b4df42eaf273af8b5ffd; classtype: trojan1; sid: 9000113; rev: 2;)
The screenshot below shows how the NDR platform detects agent communication with the server over HTTP, generating an alert with the name Trojan.Mythic.HTTP.C&C.

Communication via HTTPS

Mythic agents can communicate with the server via HTTPS using the corresponding transport module. In this case, data is encrypted with TLS and is not amenable to signature-based analysis. However, the activity of Mythic agents can be detected if they use the default SSL certificate. Below is an example of network traffic from a Mythic agent with such a certificate.

For this purpose, the following signature is applied:
alert tcp any any -> any any (msg: "Trojan.Mythic.HTTPS.C&C"; flow: established, from_server, no_stream; content: "|16 03|"; content: "|0B|"; distance: 3; within: 1; content: "Mythic C2"; distance: 0; reference: url, github.com/its-a-feature/Mythi… classtype: ndr1; sid: 9000114; rev: 1;)

WebSocket

The WebSocket protocol enables full-duplex communication between a client and a remote host. Mythic can utilize it for agent management.

The process of agent communication with the server via WebSocket is as follows:

1. The agent sends a request to the WebSocket container to change the protocol for the HTTP(S) connection.
2. The agent and the WebSocket container switch to WebSocket to send and receive messages.
3. The agent sends a message to the WebSocket container requesting tasks from the Mythic container.
4. The WebSocket container forwards the request to the Mythic container.
5. The Mythic container returns the tasks to the WebSocket container.
6. The WebSocket container forwards these tasks to the agent.

It is worth mentioning that in this communication model, both the WebSocket container and the Mythic container reside on the Mythic server. Below is a screenshot of the initial agent connection to the server.

An analysis of the TCP session shows that the actual data is transmitted in the data field in Base64 encoding.

Decoding reveals the familiar data structure: UUID+AES256(JSON).

Therefore, we can use an approach similar to those discussed above to detect agent activity. The signature should rely on the UUID string at the beginning of the data field. The rule first verifies that the session data matches the data:base64 format, then decodes the data field and searches for a string matching the UUID pattern.
alert tcp any any -> any any (msg: "Trojan.Mythic.WebSocket.C&C"; flow: established, from_server; content: "|7B 22|data|22 3a 22|"; depth: 14; pcre: "/^[0-9a-zA-Z\/\+]+[=]{0,2}\x22\x7D\x0A$/R"; content: "|7B 22|data|22 3a 22|"; depth: 14; base64_decode: bytes 48, offset 0, relative; base64_data; pcre: "/^[a-z0-9]{8}\-[a-z0-9]{4}\-[a-z0-9]{4}\-[a-z0-9]{4}\-[a-z0-9]{12}/i"; threshold: type both, track by_src, count 1, seconds 30; reference: url, github.com/MythicAgents/; classtype: ndr1; sid: 9000115; rev: 2;)
Below is the Trojan.Mythic.WebSocket.C&C signature triggering on Mythic agent communication over WebSocket.

Takeaways

The Mythic post-exploitation framework continues to gain popularity and evolve rapidly. New agents are emerging, designed for covert persistence within target infrastructures. Despite this evolution, the various implementations of network communication in Mythic share many common characteristics that remain largely consistent over time. This consistency enables IDS/NDR solutions to effectively detect the framework’s agent activity through network traffic analysis.

Mythic supports a wide array of agent management options utilizing several network protocols. Our analysis of agent communications across these protocols revealed that agent activity can be detected by searching for specific data patterns within network traffic. The primary detection criterion involves tracking UUID strings in specific positions within Base64-encoded transmitted data. However, while the general approach to detecting agent activity is similar across protocols, each requires protocol-specific filters. Consequently, creating a single, universal signature for detecting Mythic agents in network traffic is challenging; individual detection rules must be crafted for each protocol. This article has provided signatures that are included in Kaspersky NDR.

Kaspersky NDR is designed to identify current threats within network infrastructures. It enables the detection of all popular post-exploitation frameworks based on their characteristic traffic patterns. Since the network components of these frameworks change infrequently, employing an NDR solution ensures high effectiveness in agent discovery.

Kaspersky verdicts in Kaspersky solutions (Kaspersky Anti-Targeted Attack with NDR module and Kaspersky NGFW)

Trojan.Mythic.SMB.C&C
Trojan.Mythic.TCP.C&C
Trojan.Mythic.HTTP.C&C
Trojan.Mythic.TLS.C&C
Trojan.Mythic.WebSocket.C&C

securelist.com/detecting-mythi…

What has the EDRi network been up to over the past few weeks? Find out the latest digital rights news in our bi-weekly newsletter. In this edition: 2025 might be almost over, but we aren’t done fighting for digital rights

The post EDRi-gram, 11 December 2025 appeared first on European Digital Rights (EDRi).

The European Ombudsman has found that the Commission disregarded important transparency rules while preparing the Europol Regulation, which is a part of the legislation to "counter migrant smuggling". The inquiry concluded that the Commission didn't provide enough evidence to justify the claims of "urgency" to bypass their own 'Better Regulation' rules, and skipping public consultations, thorough impact assessments and evidence gathering.

The post Migrant smuggling laws: European Commission found in breach of transparency rules appeared first on European Digital Rights (EDRi).

EDRi affiliate Danes je nov dan launched a multi-faceted campaign in response to a government proposal that would allow the Slovene Intelligence and Security Agency (SOVA) to use invasive spyware and mass surveillance tools under the guise of “national security”. By combining a satirical online tool with targeted advocacy towards lawmakers, their efforts helped generate critical pressure needed to stop the legislation from being adopted.

The post How Danes je nov dan helped stop dangerous spyware in Slovenia appeared first on European Digital Rights (EDRi).

This article highlights evidence-based alternatives that strengthen child safety while safeguarding encryption and fundamental rights. It calls for better enforcement, more targeted tools, and meaningful support for child protection services rather than broad surveillance measures.

The post Moving past ‘Chat Control’ to solutions that truly protect kids and privacy appeared first on European Digital Rights (EDRi).