Destinazione Stelle

2026-05-26 07:08:25

Planck è stato un satellite europeo, operativo tra il 2009 e il 2013, con l’obiettivo di misurare la radiazione cosmica di fondo e migliorare la nostra conoscenza sulle origini e l’evoluzione dell’universo. Era equipaggiato con due sofisticati strumenti: il Low Frequency Instrument (LFI) e l'High Frequency Instrument (HFI). Oltre a partecipare alla costruzione del satellite, l'Italia è stata responsabile dell’LFI, con il ruolo di Principal Investigator affidato a Nazzareno Mandolesi dell’INAF-IASF di Bologna, ma ha partecipato anche alla realizzazione dell'HFI. Per entrambi gli strumenti, gli scienziati italiani sono stati fortemente coinvolti nell’attività scientifica legata alla missione, che ha realizzato la più accurata e dettagliata mappatura dell'intera volta celeste alle frequenze delle microonde mai ottenuta fino a quel momento.

Per misurare le infinitesimali variazioni di temperatura della radiazione cosmica di fondo, pari a pochi milionesimi di grado, i due strumenti dovevano essere mantenuti a temperature eccezionalmente basse. Questo obiettivo è stato raggiunto con una complessa catena di raffreddamento a stadi successivi. I due strumenti lavoravano a temperature diverse ed erano inseriti uno dentro l'altro.

Per prima cosa era necessario isolare gli strumenti dalla parte “calda” del satellite, il modulo di servizio orientato verso il sole. Questo obiettivo è stato ottenuto con un sistema di scudi termici molto ingegnoso ed eccezionalmente efficiente chiamato “V-grooves”: lo stesso principio poi adottato dal telescopio James Webb. In questo modo si è riusciti a portare la temperatura del payload a 50 Kelvin, circa -223 °C, una temperatura già molto bassa ma non ancora sufficiente.

Lo strumento LFI veniva poi portato a circa 20 Kelvin (-253 °C) con un particolare refrigeratore a idrogeno che aveva la caratteristica di non usare alcuna parte meccanica in movimento, eliminando così qualsiasi vibrazione che potesse disturbare le misurazioni scientifiche.

Lo strumento HFI veniva invece raffreddato con tre stadi successivi, l’ultimo dei quali sfruttava il principio della “diluzione d’elio”: questo stadio faceva miscelare continuamente due isotopi rari dell'elio, l'elio-3 e l'elio-4, con un processo endotermico, capace di assorbire calore, un po’ come l'evaporazione di un liquido, e di sottrarre le ultime frazioni di microwatt, per arrivare a una temperatura di un decimo di Kelvin (-273,05 °C). La temperatura "naturale" della radiazione cosmica di fondo è di circa 2,7 K (-270,45 °C), quindi lo strumento HFI era molto più freddo dell’ambiente circostante: un risultato possibile soltanto grazie a sistemi di raffreddamento attivi.

All’epoca lo strumento HFI era l’oggetto più freddo noto nello spazio, nonché il più freddo oggetto artificiale, ma in seguito questo record è stato superato. Attualmente l’esperimento della NASA Cold Atom Lab (CAL), a bordo della Stazione Spaziale Internazionale, è in grado di arrivare a temperature dell'ordine di poche decine di picokelvin, cioè meno di un decimiliardesimo di Kelvin.

@astronomia

♲ @destinazione_stelle@poliversity.it:

Quiz del lunedì. A che temperatura operava lo strumento HFI del satellite europeo Planck?
Appuntamento a domani per la discussione delle risposte, non suggerite e non cercate su internet!

#QuizTime
@astronomia

Spcnet.it

2026-05-26 16:59:19

Retry Storm nelle architetture distribuite: quando la resilienza diventa il problema

Le architetture distribuite moderne sono progettate per la resilienza. Aggiungiamo retry per i fallimenti transitori, replica per la durabilità, autoscaling per l’elasticità, circuit breaker per l’isolamento. Ogni meccanismo, preso singolarmente, migliora la disponibilità. Ma sotto stress, la loro interazione può abbattere l’intero sistema.

La maggior parte delle interruzioni enterprise non è causata dall’assenza di fault tolerance. È causata da meccanismi di fault tolerance non delimitati che reagiscono simultaneamente. Questo articolo analizza il fenomeno del retry storm e mostra come progettare sistemi con bounded reliability.

1. Retry Storm: quando la resilienza moltiplica il traffico

I retry sono progettati per proteggere dai fallimenti temporanei. Ma i retry moltiplicano il carico. Ecco un esempio semplificato della logica di retry che si trova comunemente nei sistemi di integrazione tra servizi:

import time
import random

def downstream_service():
    latency = random.choice([0.1, 0.2, 0.8])
    time.sleep(latency)
    if latency > 0.7:
        raise TimeoutError("Slow response")
    return "OK"

def call_with_retries(max_attempts=3):
    for attempt in range(max_attempts):
        try:
            return downstream_service()
        except TimeoutError:
            print(f"Retry {attempt+1}")
    raise Exception("Failed after retries")

In condizioni normali questa logica funziona correttamente. Ma sotto carico elevato si innesca una spirale:

1. La latenza aumenta
2. Scattano i timeout
3. Ogni richiesta viene ritentata fino a 3 volte
4. Il traffico verso il backend triplica
5. Il backend rallenta ulteriormente
6. Aumentano i retry

In un’architettura a livelli tipica — Gateway → Experience API → Process API → System API → Database — se ogni livello gestisce i retry in modo indipendente, l’amplificazione del carico diventa moltiplicativa, non additiva. Un singolo rallentamento del database può abbattere tre livelli API a cascata in pochi minuti.

Il pattern Bounded Retry (sicuro per la produzione)

La soluzione non è eliminare i retry, ma delimitarli e renderli consapevoli del carico di sistema:

def call_with_bounded_retries(max_attempts=2, system_load=0.5):
    # Fail-fast quando il sistema è sotto stress
    if system_load > 0.75:
        return None

    for attempt in range(max_attempts):
        try:
            return downstream_service()
        except TimeoutError:
            # Exponential backoff con jitter
            backoff = 0.2 * (2 ** attempt)
            time.sleep(backoff + random.uniform(0, 0.1))
    return None

Le differenze chiave rispetto alla versione base:

• Ceiling sui retry: massimo 2 tentativi invece di 3
• Exponential backoff: aumenta il tempo di attesa ad ogni tentativo
• Jitter: aggiunge variabilità casuale per evitare wave di retry sincronizzate
• Load-aware circuit: disabilita i retry completamente quando il sistema è sovraccarico

2. Fan-out della replica e collasso della coordinazione

La replica sincrona migliora la durabilità dei dati. Ma ogni write si moltiplica per il numero di repliche, aumentando il costo di coordinazione:

def write_to_replicas(data, replicas=3):
    for _ in range(replicas):
        time.sleep(0.2)  # Simula latenza di replica

Sotto traffico elevato, il lag delle repliche cresce, i client iniziano a ritentare le scritture, e il carico effettivo di write raddoppia. In sistemi di elaborazione aziendale (ordini, fatturazione, riconciliazione) questo pattern causa un collasso del throughput non perché i dati vadano persi, ma perché la coordinazione sopraffà il sistema.

La soluzione è la durabilità stratificata: non tutte le scritture richiedono le stesse garanzie. Le transazioni critiche usano replica completa; log ed eventi non critici ne richiedono meno. La reliability deve essere proporzionata, non massimizzata ciecamente.

3. Loop di feedback dell’autoscaling

L’autoscaling reagisce alle metriche di traffico. Ma se queste metriche sono gonfiate dai retry, il sistema escala in risposta a traffico artificiale:

def autoscale_safe(request_rate, sustained_load):
    # Scala su domanda sostenuta, non su spike da retry
    if sustained_load and request_rate > 120:
        print("Scaling up — domanda organica confermata")

Segnali più affidabili su cui basare l’autoscaling:

• Domanda sostenuta (non spike improvvisi)
• Tendenze nella distribuzione della latenza (P95, P99)
• RPS organiche (esclusi i retry)
• Velocità di crescita delle code

4. Il problema reale: le reazioni correlate

Retry, replica e autoscaling reagiscono ciascuno a segnali diversi. Ma sotto stress, reagiscono tutti allo stesso segnale di degradazione. Questa correlazione crea il fallimento a cascata.

Scenario reale — payment reconciliation service:

1. La latenza dell’ERP sale a 700ms
2. Il servizio Billing va in timeout a 500ms
3. Billing ritenta 3 volte
4. La Process API ritenta l’orchestrazione
5. Il Gateway ritenta la richiesta client
6. L’autoscaling reagisce allo spike
7. Il lag di replica del database aumenta
8. La Dead Letter Queue inizia a riempirsi

In pochi minuti, un rallentamento minore diventa un’interruzione di piattaforma. La causa principale: reazione non delimitata.

5. Pattern di Bounded Reliability per sistemi API

Retry Budget

Il carico effettivo è: Carico Effettivo = RPS in ingresso × Numero Retry. Con 1.000 RPS e 3 retry, il backend riceve 3.000 richieste. Impostare un budget massimo di retry per richiesta e per servizio è non negoziabile in produzione.

Classificazione degli Errori

Non tutti gli errori sono retriable. Una tassonomia chiara:

Tipo di Errore	Retry?	Azione
CONNECTIVITY	Sì	Bounded retry
TIMEOUT	Sì	Backoff esponenziale
VALIDATION (4xx)	No	Fail fast
AUTH (401/403)	No	Alert immediato

I retry ciechi su errori di validazione o autenticazione sono debito architetturale.

Idempotency obbligatoria

I retry senza idempotency causano corruzione dei dati. Il transaction ID deve essere deterministic, non generato casualmente ad ogni tentativo:

# ❌ Non sicuro: genera un nuovo ID ad ogni retry
transaction_id = uuid()

# ✅ Sicuro: riusa l'ID dalla richiesta originale
transaction_id = payload.get("transaction_id") or request.headers["correlation-id"]

Dead Letter Queue con Osservabilità

Tracciare le seguenti metriche come segnali di early warning:

• Percentuale di retry sul totale delle richieste
• Frequenza dei timeout per endpoint
• Velocità di crescita della DLQ
• Shift nella distribuzione P95 della latenza

Conclusione

Le retry storm non iniziano con un fallimento catastrofico. Iniziano con un piccolo aumento di latenza, qualche timeout, una manciata di retry. Poi i meccanismi di fault tolerance reagiscono insieme — e la loro interazione non controllata trasforma un disagio minore in un’interruzione totale.

La resilienza nelle architetture distribuite non significa aggiungere più safety net. Significa controllare come quei safety net si comportano sotto stress. Delimita i retry. Classifica i fallimenti. Forza l’idempotency. Scala su domanda organica. Monitora i loop di feedback prima che si avvitino.

La differenza tra una piattaforma resiliente e un fallimento a cascata sta quasi sempre nella risposta a una sola domanda: i tuoi meccanismi di reliability sono controllati o sono illimitati?

Fonte: How Retry Storms Crash API-Led Systems: Bounded Reliability Patterns — DZone

How Retry Storms Crash API-Led Systems

Unbounded retries and autoscaling can turn minor latency into cascading outages. API reliability must be bounded and load-aware to prevent retry storms.

^{Manjeera Chanda (dzone.com)}

Spcnet.it

2026-05-26 16:59:55

nmap su Linux: guida completa alla scansione e discovery di rete

nmap è uno degli strumenti più potenti e longevi nell’arsenale di qualsiasi sistemista Linux. Nato nel 1997, è oggi uno standard de facto per l’audit di rete, la verifica della superficie d’attacco esposta e il troubleshooting di connettività. Questa guida copre i comandi e le tecniche che un sysadmin usa davvero in produzione: niente teoria astratta, solo esempi concreti.

Nota legale: scansionate solo reti e host di vostra proprietà o per cui avete un’autorizzazione esplicita. La scansione non autorizzata può essere illegale nella vostra giurisdizione.

Installazione di nmap

nmap è disponibile nei repository di tutte le principali distribuzioni Linux:

# Debian / Ubuntu
sudo apt install nmap

# Fedora / RHEL / CentOS
sudo dnf install nmap

# Arch / Manjaro
sudo pacman -S nmap

Verificate l’installazione con:

nmap --version

Dovreste vedere qualcosa come Nmap version 7.94 o superiore. Le funzionalità più avanzate (SYN scan, OS detection) richiedono privilegi root.

Host Discovery: chi è attivo sulla rete?

Il primo passo in qualsiasi audit è capire quali host sono raggiungibili. Il ping scan usa il flag -sn, che dice a nmap di non eseguire scansioni delle porte:

nmap -sn 192.168.1.0/24

Su una LAN locale nmap usa ARP discovery, più veloce e capace di trovare dispositivi che ignorano il ping ICMP. L’output tipico è:

Nmap scan report for 192.168.1.1
Host is up (0.0011s latency).
MAC Address: A4:3E:51:XX:XX:XX (Ubiquiti Networks)

Nmap scan report for 192.168.1.10
Host is up (0.00032s latency).
MAC Address: DC:A6:32:XX:XX:XX (Raspberry Pi Trading)

È un inventario rapido: ottimo dopo aver aggiunto un nuovo dispositivo e non ricordarsi quale IP ha ottenuto dal DHCP.

Scansione delle Porte

Scansione di default

Senza flag aggiuntivi, nmap scansiona le 1.000 porte TCP più comuni. Non richiede root, ma i risultati sono meno dettagliati:

nmap 192.168.1.10

SYN Scan (Stealth Scan)

La SYN scan è la modalità default quando si esegue nmap come root. Invia un pacchetto SYN senza completare il three-way handshake TCP: più veloce e meno visibile nei log applicativi:

sudo nmap -sS 192.168.1.10

Scansione di tutte le 65.535 porte

Le 1.000 porte di default possono mancare servizi su porte non standard — MySQL su 33060, SSH spostato su 2222:

sudo nmap -sS -p- 192.168.1.10

Porte specifiche o range

# Porte specifiche
sudo nmap -p 22,80,443,3306 192.168.1.10

# Range di porte
sudo nmap -p 1-1024 192.168.1.10

UDP Scanning

L’UDP è spesso dimenticato. DNS (porta 53), SNMP (161) e NTP (123) girano su UDP e sono vettori comuni di attacco e misconfiguration:

sudo nmap -sU -p 53,161,123 192.168.1.1

Rilevamento di Servizi e Versioni

Il flag -sV esegue probe sulle porte aperte per determinare servizio e versione. È il primo scan da eseguire su un server sconosciuto:

sudo nmap -sV 192.168.1.10

Output esempio:

PORT     STATE SERVICE VERSION
22/tcp   open  ssh     OpenSSH 8.9p1 Ubuntu 3ubuntu0.6
80/tcp   open  http    nginx 1.24.0
3306/tcp open  mysql   MySQL 8.0.35

Rivela immediatamente con cosa si ha a che fare e può evidenziare software obsoleto — un win immediato per la sicurezza.

Rilevamento del Sistema Operativo

nmap può fare ipotesi sull’OS basandosi sul fingerprinting del TCP/IP stack:

sudo nmap -O 192.168.1.10

Output:

OS details: Linux 5.15 - 5.19, Linux 6.1
Network Distance: 1 hop

Non è sempre preciso su VM o dispositivi con stack TCP personalizzati, ma fornisce un segnale utile per distinguere server Linux da macchine Windows o embedded su un segmento di rete.

Aggressive Scan: tutto in uno

Il flag -A abilita OS detection, version detection, script scanning e traceroute in un colpo solo:

sudo nmap -A 192.168.1.10

Genera molto traffico e richiede tempo. Non usatelo su reti di produzione senza motivo, ma per un audit completo di un singolo host è estremamente comodo.

Nmap Scripting Engine (NSE)

L’NSE è ciò che distingue nmap da un semplice port scanner. Permette di eseguire script contro host e servizi scoperti. Gli script si trovano in /usr/share/nmap/scripts/ e coprono vulnerability detection, enumerazione di servizi e molto altro.

Verifiche pratiche

# Categoria default
sudo nmap --script=default 192.168.1.10

# Scansione vulnerabilità (più invasivo - usare deliberatamente)
sudo nmap --script=vuln 192.168.1.10

# FTP anonimo abilitato?
sudo nmap --script=ftp-anon -p 21 192.168.1.10

# Header HTTP esposti (versioni server, debug info)
sudo nmap --script=http-headers -p 80,443 192.168.1.10

# Open SMTP relay?
sudo nmap --script=smtp-open-relay -p 25 192.168.1.20

L’HTTP headers scan è sorprendentemente utile: è frequente trovare server che espongono header con versione del software e informazioni di debug che avrebbero dovuto essere rimosse.

Per elencare tutti gli script disponibili per un servizio:

ls /usr/share/nmap/scripts/ | grep -i ssh

Formati di Output

Per qualunque cosa oltre un controllo rapido, salvare l’output è fondamentale:

# Output normale su file
sudo nmap -sV 192.168.1.0/24 -oN scan_results.txt

# XML (utile per automazione e import in altri tool)
sudo nmap -sV 192.168.1.0/24 -oX scan_results.xml

# Formato grepable
sudo nmap -sV 192.168.1.0/24 -oG scan_results.gnmap

# Tutti i formati in una volta sola
sudo nmap -sV 192.168.1.0/24 -oA scan_results

Il flag -oA crea tutti e tre i file con il prefisso specificato. L’output XML si presta bene al parsing automatizzato.

Timing e Velocità

nmap dispone di sei template di timing, da T0 (lentissimo) a T5 (aggressivo). Il default è T3. Per la maggior parte delle scansioni su reti locali affidabili:

sudo nmap -sS -T4 192.168.1.0/24

Su VPN o connessioni lente, scendere a T2 evita falsi negativi causati da pacchetti persi.

Combinazioni Pratiche per Sysadmin

Questi sono i comandi che si usano davvero nel lavoro quotidiano:

# Porte aperte su un host (solo quelle definitivamente aperte)
sudo nmap -sS -T4 --open 192.168.1.10

# Trovare tutti i server SSH su una subnet
sudo nmap -p 22 --open -sV 192.168.1.0/24

# MySQL esposto sulla rete? (non dovrebbe mai esserlo)
sudo nmap -p 3306 --open 192.168.1.0/24

# Host discovery + version scan concatenati (solo host attivi)
sudo nmap -sn 192.168.1.0/24 -oG - | grep "Up" | awk '{print $2}' | sudo nmap -sV -iL -

L’ultimo comando è particolarmente potente: esegue prima un ping scan, filtra gli host attivi, poi esegue la version scan solo su di loro. Ideale per subnet grandi.

Gestione dei Target e Firewall

# Range di IP
nmap 192.168.1.1-50

# Host da file (uno per riga)
nmap -iL hosts.txt

# Escludere host dalla scansione
nmap 192.168.1.0/24 --exclude 192.168.1.1,192.168.1.5

nmap distingue tre stati delle porte: open, closed e filtered. Una porta filtered indica che un firewall sta bloccando i probe. Se vedete molte porte filtered su un server di vostra proprietà senza aspettarvelo, investigate: potrebbe essere ufw, firewalld, regole nftables o un security group del cloud provider.

Conclusione

Host discovery, port scanning, version detection, NSE scripts e salvataggio dell’output sono le fondamenta di nmap. Iniziate con -sn per la discovery, aggiungete -sV quando servono i dettagli sui servizi, portate gli script NSE quando volete approfondire. Mantenete il timing conservativo sulle reti di produzione e aggressivo nel vostro lab.

Se state verificando le regole firewall, nmap è tra i migliori strumenti per controllare che ciò che pensate sia bloccato lo sia davvero.

Fonte originale: nmap on Linux: Guide to Network Scanning and Discovery — LinuxBlog.io

nmap on Linux: Guide to Network Scanning and Discovery | LinuxBlog.io

A practical guide to nmap on Linux covering host discovery, port and service scanning, OS detection, NSE scripts, output formats, and real-world command combinations sysadmins actually use.

^{Hayden James (LinuxBlog.io)}

(in)sicurezza digitale

2026-05-26 16:57:29

Void Dokkaebi evolve InvisibleFerret: il malware nordcoreano ora usa Cython per sfuggire agli antivirus

Void Dokkaebi, il gruppo APT nordcoreano tracciato anche come Famous Chollima, ha completato una significativa evoluzione del proprio arsenale offensivo: il malware infostealer InvisibleFerret è stato ricompilato da Python a Cython, trasformando script leggibili in binari nativi che sfuggono alla quasi totalità dei meccanismi di rilevamento basati sull’analisi del codice sorgente. La ricerca pubblicata da Trend Micro a maggio 2026 rivela una campagna di spionaggio industriale di proporzioni allarmanti che colpisce sviluppatori software con accesso a wallet di criptovalute e infrastrutture CI/CD.

Profilo del gruppo: chi è Void Dokkaebi

Void Dokkaebi, denominato anche Famous Chollima nell’ecosistema di threat intelligence di CrowdStrike, è un intrusion set allineato agli interessi della Repubblica Popolare Democratica di Corea (RPDC). Il gruppo si distingue da altre unità cyber nordcoreane come Lazarus Group per la specializzazione quasi esclusiva nel targeting di sviluppatori software, ingegneri DevOps e professionisti del settore Web3 che detengono chiavi di firma, credenziali di wallet e accesso privilegiato a pipeline di continuous integration e deployment.

La sua tattica operativa preferita è quella del “fake job interview”: gli operatori si spacciano per recruiter di aziende crypto o AI rinominate, contattano le vittime su piattaforme come LinkedIn o GitHub, e le convincono a clonare ed eseguire repository di codice come parte di una presunta prova tecnica per un colloquio. Il codice in apparenza innocuo nasconde i payload malevoli.

La campagna del 2026: infrastruttura blockchain e repository compromessi

L’analisi condotta a marzo-maggio 2026 ha rivelato la portata impressionante dell’infrastruttura malevola costruita dal gruppo. I ricercatori hanno identificato:

• Oltre 750 repository GitHub infetti, molti appartenenti a organizzazioni legittime come DataStax e Neutralinojs, che presentano marcatori di infezione nei workflow CI/CD
• Più di 500 configurazioni di task Visual Studio Code modificate per eseguire payload al momento dell’apertura del progetto
• 101 istanze dello strumento di commit tampering utilizzato per iniettare codice malevolo nei repository

L’elemento più innovativo della campagna 2026 è l’utilizzo di infrastruttura blockchain per la distribuzione dei payload. Void Dokkaebi sfrutta Tron, Aptos e Binance Smart Chain come staging server per i malware, rendendo gli indicatori di compromissione praticamente immuni ai tradizionali meccanismi di takedown. Aggiornare un riferimento su blockchain equivale a cambiare il payload consegnato a tutte le vittime già infette, senza modificare un singolo byte nei repository.

L’evoluzione tecnica: da Python a Cython

Il cuore dell’aggiornamento analizzato da Trend Micro riguarda InvisibleFerret, il modulo infostealer centrale nell’arsenale di Void Dokkaebi. Precedentemente distribuito come script Python in chiaro — facilmente analizzabili e rilevabili da sistemi YARA e EDR — il malware è stato interamente ricompilato tramite Cython.

Cython è un compilatore che traduce codice Python in sorgente C/C++ e poi in binari nativi. Il risultato pratico è che InvisibleFerret viene ora distribuito come file .pyd su Windows (Python extension DLL) e come librerie condivise .so su macOS. Entrambi i formati sono binari compilati: non contengono stringhe leggibili, non sono interpretabili senza reverse engineering specializzato, e bypassano le regole di detection tradizionalmente scritte per identificare script Python sospetti.

Le capacità del malware rimangono invariate rispetto alle versioni precedenti:

• Apertura di backdoor per accesso remoto persistente
• Furto di credenziali dai principali browser (Chrome, Firefox, Edge)
• Monitoraggio degli appunti di sistema (clipboard hijacking per intercettare indirizzi di wallet)
• Keylogging per catturare password e seed phrase
• Esfiltrazione diretta da wallet di criptovalute locali
• Ricognizione dell’ambiente: processi in esecuzione, file system, variabili d’ambiente

Toolset correlato: BeaverTail, OtterCookie, OmniStealer

InvisibleFerret non opera mai isolatamente. Il gruppo lo utilizza in combinazione con altri malware della stessa famiglia operativa. BeaverTail è il dropper JavaScript iniziale che viene eseguito durante il “test tecnico”, il quale successivamente scarica e installa InvisibleFerret. OtterCookie è un ulteriore stealer focalizzato sui browser e sui file di configurazione. OmniStealer amplia la superficie di furto a client di posta e applicazioni VPN. Tutti questi componenti possono essere aggiornati dinamicamente tramite i reference blockchain, garantendo al gruppo una flessibilità operativa senza precedenti.

Indicatori di compromissione (IoC)

# File IOC - InvisibleFerret Cython (maggio 2026)
# Estensioni malevole su Windows
*.pyd  (file Python extension DLL con firma digitale assente o anomala)
# Estensioni malevole su macOS
*.so   (librerie condivise caricate da processi Python non standard)
# Pattern comportamentale
Processo Python che carica estensioni .pyd/.so non firmate da directory temp
Connessioni in uscita verso endpoint Tron/Aptos/BSC non previsti dall'applicazione
Lettura anomala del keychain macOS o del credential manager Windows
Accessi al filesystem wallet: ~/.bitcoin, ~/.ethereum, ~/.solana
# Infrastruttura C2 (blockchain-staged)
TRC20 address utilizzati come dead drop resolver su Tron network
Transazioni su Aptos con payload codificati nei campi memo

Due righe per i difensori

La migrazione a Cython rende obsolete le regole YARA basate su stringhe Python. I team di sicurezza devono aggiornare la propria postura difensiva su più livelli. A livello di endpoint, occorre implementare controlli di integrità sulle estensioni Python caricate dinamicamente e monitorare processi Python che importano moduli non presenti nell’ambiente di sviluppo ufficiale. A livello di rete, è essenziale bloccare o monitorare le connessioni verso endpoint RPC di reti blockchain non autorizzate (Tron API: api.trongrid.io, Aptos: fullnode.aptoslabs.com). A livello procedurale, le organizzazioni dovrebbero verificare l’identità dei recruiter prima di clonare ed eseguire qualsiasi repository fornito esternamente, e condurre i test tecnici in ambienti isolati (sandbox o VM senza credenziali di produzione). Gli sviluppatori che lavorano su progetti Web3 o che detengono wallet crypto devono essere considerati target ad alto rischio e ricevere formazione specifica sul riconoscimento di queste campagne di ingegneria sociale.