Publii è un CMS statico open source che permette di creare siti web veloci, sicuri e orientati alla privacy senza database o server complessi

🔗 Leggi il post completo

AuraScan aiuta gli utenti Arch Linux a individuare pacchetti sospetti, analizzare aggiornamenti e prevenire problemi prima dell'installazione.

🔗 Leggi il post completo

Docking è un dock open source per Linux ricco di funzionalità, compatibile con X11 e Wayland e dotato di oltre 60 applet integrate

🔗 Leggi il post completo

Visor è un nuovo boot manager UEFI open source leggero, veloce e moderno con supporto a Secure Boot, snapshot Btrfs e rilevamento automatico.

🔗 Leggi il post completo

KDE Plasma 6.8 è in arrivo e porta con sé un bagaglio di novità pensate sia per chi lavora in remoto sia per gli utenti desktop più esigenti.

🔗 Leggi il post completo

Un server Alibaba Cloud lasciato aperto per errore ha smascherato un intero cluster di cyberspionaggio China-nexus: intrusioni attive contro un ospedale vietnamita, il Ministero degli Esteri malese, decine di istituti universitari di Hong Kong e persino un pacchetto di spear-phishing indirizzato al Congresso dell’Honduras. Group-IB lo chiama JadeProx, e la sua tradecraft ruota attorno a un loader Windows mai documentato prima, il TriBack Loader, distribuito anche tramite un finto installer di Claude.

Un errore operativo che vale un intero dossier

A metà aprile 2026 i ricercatori di Group-IB hanno individuato, nella regione Singapore di Alibaba Cloud, un server di staging esposto senza alcuna autenticazione. Al momento della pubblicazione del report, il 23 luglio 2026, il server era già stato smantellato, ma la sua cronologia bash, i pacchetti di phishing, gli strumenti post-exploitation e i path dei webshell hanno permesso di ricostruire in dettaglio un’operazione attiva su tre continenti diversi.

Gli obiettivi identificati sono eterogenei ma coerenti con un mandato di raccolta informativa ad ampio spettro tipico degli operatori legati alla Cina: il sistema di imaging medicale (PACS, Picture Archiving and Communications System) di un ospedale pubblico vietnamita, da cui transitano radiografie, TAC e risonanze dei pazienti; il Ministero degli Esteri della Malesia, violato con webshell e strumenti di tunneling; l’infrastruttura universitaria di Hong Kong, colpita con una scansione massiva; e un pacchetto di spear-phishing con decoy finanziario indirizzato al Congresso Nazionale dell’Honduras. Gli operatori sono arrivati al server dell’ospedale vietnamita attraverso webshell piazzate su un’interfaccia di gestione Java esposta su Internet.

TriBack Loader: un unico loader, quattro varianti

Al centro della tradecraft c’è un loader Windows che Group-IB battezza TriBack Loader, mai documentato in precedenza. Compare in quattro catene di infezione, tutte costruite attorno al DLL sideloading: un eseguibile legittimo firmato viene abbinato a una DLL malevola e a un payload cifrato in formato .dat o .log.

La DLL inverte i byte del payload, li decifra con XOR a chiave rotante, ed esegue lo shellcode tramite chiamate Win32 che gli EDR monitorano meno rispetto alla classica CreateThread. Le quattro varianti si differenziano proprio nella chiamata finale usata per l’esecuzione: due si affidano a InitOnceExecuteOnce e a un callback TimerQueue, una terza sfrutta EtwpCreateEtwThread, una routine non documentata di ntdll per la creazione di thread. Anche il binario firmato ospite cambia da variante a variante. Per i ricercatori, la ripetizione sistematica della stessa sequenza di API suggerisce l’esistenza di un builder automatizzato per la generazione del loader.

Due varianti distribuiscono AdaptixC2, framework open source di post-exploitation già osservato in altre campagne ransomware. Una terza variante, particolarmente insidiosa, si maschera da software Claude: usa DonutLoader per eseguire Beagle, una backdoor documentata per la prima volta da Sophos. La quarta variante resta un mistero: il file cifrato che ne conteneva il payload non è mai stato recuperato.

L’esca perfetta: un finto Claude con MSI malevolo

Uno degli aspetti più rilevanti per un pubblico di professionisti è la campagna di impersonificazione del software Anthropic. Il dominio claude-pro[.]com, registrato il 28 marzo 2026, ha distribuito un installer MSI malevolo che, superato un prompt UAC, posizionava la catena di sideloading nella cartella di avvio di Windows per garantirsi la persistenza. La backdoor Beagle consegnata da questa variante comunicava con license[.]claude-pro[.]com come infrastruttura di comando e controllo.

Sophos, lavorando a partire dal sito fasullo, dalla sua infrastruttura di hosting e dai campioni di malware raccolti, ha rilevato la stessa chiave XOR riutilizzata in build risalenti a febbraio 2026, ma ha specificato che una chiave condivisa non basta da sola a confermare un singolo attore dietro tutte le campagne: nell’ecosistema China-nexus gli strumenti circolano liberamente tra gruppi diversi. Lo stesso approccio prudente vale per Group-IB, che raggruppa le intrusioni asiatiche sotto l’etichetta JadeProx senza attribuirle in modo definitivo a un gruppo APT già catalogato.

Se la valutazione di Sophos è corretta e il sito fasullo faceva parte di una campagna di malvertising attiva, l’esposizione va ben oltre ministeri e ospedali: raggiunge chiunque, nel mondo, stesse semplicemente cercando di scaricare Claude.

Vulnerabilità vecchie di anni per colpire infrastrutture nuove

Sul fronte dello scanning contro l’istruzione di Hong Kong, gli operatori hanno lanciato Nuclei con template a severità critica contro una lista di 14.653 URL legati al settore educativo, individuando 13 vulnerabilità uniche. Il report non specifica quanti tentativi di sfruttamento successivi abbiano avuto successo, ma indica quattro CVE specifiche tentate contro singoli host, tutte con punteggio CVSS 9.8: CVE-2018-11511 (ASUSTOR ADM), CVE-2021-24139 (plugin WordPress 10Web Photo Gallery), CVE-2021-31755 (router Tenda AC11) e CVE-2021-32305 (WebSVN).

Il dettaglio interessante per i difensori è che la falla su Tenda AC11 è nel catalogo KEV (Known Exploited Vulnerabilities) di CISA dal 3 novembre 2021, con una scadenza di remediation federale spirata appena due settimane dopo. In altre parole: la parte “artigianale” e sofisticata di questa operazione — loader custom, sideloading, ETW abuse — si appoggia a un ingresso iniziale banale, fatto di CVE pubbliche e non patchate da anni. L’ingegneria del loader conta poco se la porta d’ingresso resta aperta dal 2021.

Cosa monitorare

Group-IB e i ricercatori coinvolti raccomandano di concentrare il rilevamento sulla catena di sideloading piuttosto che sui singoli indicatori di rete, dato che nomi file e host firmati cambiano a ogni build:

• Segnalare binari vendor firmati eseguiti da directory scrivibili dall’utente, temporanee o dalla cartella Startup, specialmente in presenza di file .dat o .log cifrati nella stessa cartella.
• Cercare copie sospette di hostfxr.dll, avk.dll o MpClient.dll, insieme a cartelle annidate del tipo _CL_###### e allo script ~del.vbs.bat.
• Bloccare o investigare i domini del cluster: claude-pro[.]com, license[.]claude-pro[.]com, sylverixstrategy[.]com, gouvvbo[.]top, vertextrust-advisors[.]com, e tre domini civetta che imitano vendor di sicurezza condividendo lo stesso IP — update-trellix[.]com, update-crowdstrike[.]com, update-sentinelone[.]com.
• Dare priorità alle applicazioni Java esposte su Internet, quindi a qualsiasi sistema pubblico con una falla non patchata di severità 9.8, incluse le quattro citate.

Indicatori di compromissione

Domini:
claude-pro[.]com (registrato 28/03/2026)
license[.]claude-pro[.]com
sylverixstrategy[.]com
gouvvbo[.]top
vertextrust-advisors[.]com
update-trellix[.]com
update-crowdstrike[.]com
update-sentinelone[.]com

Infrastruttura di staging:
43.106.71[.]28:8000

CVE sfruttate (CVSS 9.8):
CVE-2018-11511 - ASUSTOR ADM
CVE-2021-24139 - 10Web Photo Gallery (WordPress)
CVE-2021-31755 - Tenda AC11 (KEV CISA dal 03/11/2021)
CVE-2021-32305 - WebSVN

Artefatti su disco:
hostfxr.dll / avk.dll / MpClient.dll (copie sospette)
_CL_###### (cartelle annidate)
~del.vbs.bat

Malware associato:
TriBack Loader (loader custom, DLL sideloading)
AdaptixC2 (post-exploitation open source)
DonutLoader -> Beagle backdoor

FireDragon 13 rinnova completamente il browser con una nuova base di codice, più privacy, migliori prestazioni e nuove opzioni di configurazione.

🔗 Leggi il post completo

Rox è un nuovo lettore musicale open source in Rust ispirato a Foobar2000, progettato per gestire grandi librerie locali con prestazioni elevate.
Stai leggendo Rox il player musicale in Rust che raccoglie l’eredità di Foobar2000, un articolo del blog Linux Easy. Non riprodurlo altrove senza permesso.

🔗 Leggi il post completo

Il team di Garuda Linux ha ufficialmente pubblicato FireDragon v13, una riscrittura completa del suo browser basato su Firefox, orientato alla privacy e con un nuovo codice sorgente. In passato, FireDragon si basava su...

🔗 Leggi il post completo

FreeCAD 1.1.3 corregge importanti vulnerabilità di sicurezza e numerosi bug. Aggiornamento consigliato per tutti gli utenti.Stai leggendo FreeCAD 1.1.3 risolve vulnerabilità critiche e migliora stabilità e prestazioni, un articolo del blog Linux Easy. Non riprodurlo altrove senza permesso.

🔗 Leggi il post completo

Auto-cpufreq è un’applicazione libera e open source che ottimizza automaticamente la velocità e il consumo energetico della CPU sui sistemi GNU/Linux con un focus particolare sui portatili. Il suo obiettivo principale è superare i limiti di strumenti tradizionali...

🔗 Leggi il post completo

Anche se controllare quanto e quale codice sia generato dall'AI risulta certamente un'impresa ardua, quella di Codeberg è una scelta in profonda controtendenza rispetto ai colossi come GitHub e GitLab, che promuovono l'utilizzo incondizionato dell'AI.
Codeberg dice no a questo tipo di progetti, e dimostra di volersi chiamare fuori da questo gioco promozionale.

🔗 Leggi il post completo

Chi amministra server Linux prima o poi si trova a dover rispondere a una domanda apparentemente semplice: “cosa è realmente esposto su questa macchina, e su questa rete?” La risposta corretta non arriva mai da un elenco di regole firewall letto a memoria, ma da una verifica attiva. Nmap (Network Mapper) resta lo strumento di riferimento per questo tipo di verifica: open source, nato nel 1997, ancora oggi il punto di partenza per audit di sicurezza, mappatura di reti e troubleshooting di connettività.

In questo articolo vediamo un percorso pratico per usare nmap in scenari reali di amministrazione sistemi: dalla discovery degli host alla scansione delle porte, fino agli script NSE per individuare vulnerabilità e configurazioni deboli.

Nota importante: esegui scansioni solo su reti e host di tua proprietà o per cui hai autorizzazione esplicita. La scansione non autorizzata può costituire reato in molte giurisdizioni, Italia compresa (accesso abusivo a sistema informatico, art. 615-ter c.p.).

Installazione

Nmap è disponibile nei repository di tutte le distribuzioni principali:

# Debian/Ubuntu
sudo apt install nmap

# Fedora/RHEL/CentOS
sudo dnf install nmap

# Arch/Manjaro
sudo pacman -S nmap

# Verifica
nmap --version

Host discovery: chi è vivo sulla rete

Il primo passo in qualsiasi audit è capire quali host rispondono. Per questo si usa la scansione “ping”, che salta completamente il controllo delle porte:

nmap -sn 192.168.1.0/24

Scansione delle porte

Una volta identificati gli host attivi, il passo successivo è capire quali servizi espongono. Senza opzioni, nmap scansiona le 1.000 porte TCP più comuni e non richiede privilegi root:

nmap 192.168.1.10

sudo nmap -sS 192.168.1.10

sudo nmap -sS -p- 192.168.1.10   # tutte le 65.535 porte
sudo nmap -p 22,80,443,3306 192.168.1.10   # porte specifiche
sudo nmap -p 1-1024 192.168.1.10   # un intervallo

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

Version detection e OS fingerprinting

Sapere che la porta 22 è aperta è utile. Sapere che dietro c’è OpenSSH 8.9p1 lo è molto di più, soprattutto per intercettare versioni obsolete durante un audit di sicurezza:

sudo nmap -sV 192.168.1.10

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

Per un’ipotesi sul sistema operativo, tramite fingerprinting dello stack TCP/IP, serve almeno una porta aperta e una chiusa:

sudo nmap -O 192.168.1.10

Per un quadro completo in un colpo solo (OS detection, version detection, script scanning e traceroute) c’è la scansione aggressiva:

sudo nmap -A 192.168.1.10

Nmap Scripting Engine (NSE): oltre il semplice port scan

La vera potenza di nmap emerge con NSE, il motore di scripting che esegue controlli automatizzati sugli host scoperti: dalla ricerca di vulnerabilità note alla verifica di configurazioni deboli. Gli script risiedono in /usr/share/nmap/scripts/ e sono organizzati in categorie (default, auth, vuln, discovery, intrusive, safe).

# Vulnerabilità note (categoria più invasiva, usarla con criterio)
sudo nmap --script=vuln 192.168.1.10

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

# Header HTTP (spesso rivelano versioni software o debug info)
sudo nmap --script=http-headers -p 80,443 192.168.1.10

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

Output e automazione

Per qualsiasi verifica che vada oltre il controllo estemporaneo, conviene salvare i risultati:

sudo nmap -sV 192.168.1.0/24 -oA scan_results

Combinazioni utili nel lavoro quotidiano

# Solo porte effettivamente aperte, timing aggressivo su rete affidabile
sudo nmap -sS -T4 --open 192.168.1.10

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

# Verifica che MySQL non sia esposto inutilmente
sudo nmap -p 3306 --open 192.168.1.0/24

# Discovery + version scan solo sugli host realmente attivi
sudo nmap -sn 192.168.1.0/24 -oG - | grep "Up" | awk '{print $2}' | sudo nmap -sV -iL -

Nmap ha inoltre sei template di timing, da T0 (paranoico, lentissimo) a T5 (aggressivo): T3 è il default bilanciato, T4 va bene su reti locali affidabili, mentre su VPN o collegamenti lenti conviene scendere a T2 per evitare falsi negativi dovuti a pacchetti persi.

Porte filtrate: un segnale, non un fastidio

Nmap distingue tre stati: open, closed e filtered. Quest’ultimo indica che un firewall o un packet filter sta bloccando silenziosamente la sonda. Se compaiono molte porte filtrate su un server che non ti aspetti sia protetto da firewall, vale la pena indagare: potrebbe essere ufw, firewalld, un ruleset nftables o un security group del provider cloud. In ogni caso, è un’indicazione da non ignorare, e lo stesso principio vale per i probe di version detection e OS fingerprinting, che un firewall può alterare o azzerare.

Conclusione

Nmap non si impara in un pomeriggio, ma i comandi visti coprono la maggior parte del lavoro quotidiano di un sistemista: discovery degli host, scansione delle porte, identificazione di servizi e versioni, script NSE per approfondire, e output strutturato per automazione o revisione successiva. La sequenza tipica è semplice: si parte con -sn per la discovery, si aggiunge -sV quando servono i dettagli sui servizi, e si porta NSE in campo quando serve scavare più a fondo. Timing prudente in produzione, aggressivo nel proprio lab: è una distinzione che vale la pena interiorizzare prima di lanciare la prima scansione su un ambiente che non si controlla del tutto.

Fonte originale: Hayden James, “nmap on Linux: Guide to Network Scanning and Discovery”, LinuxBlog.io.

Il process manager sbagliato è spesso il vero collo di bottiglia di PHP

Quando un’applicazione PHP inizia a rallentare sotto traffico reale, la prima cosa che si tende a ottimizzare è il codice: query più efficienti, cache applicativa, opcache. Tutte cose giuste, ma c’è un parametro a monte che viene sistematicamente sottovalutato e che, su un server con traffico costante, può pesare quanto tutto il resto messo insieme: il process manager (PM) di PHP-FPM.

La quasi totalità delle installazioni lascia pm impostato su dynamic, il valore di default, oppure viene consigliato di passare a ondemand quando la memoria disponibile è scarsa. Per un server che riceve traffico costante e prevedibile, però, esiste una terza opzione quasi sempre trascurata: pm = static. In questo articolo vediamo perché, come calcolare i parametri corretti e in quali scenari conviene davvero.

Le tre modalità del process manager

PHP-FPM gestisce un pool di processi worker che eseguono lo script PHP per ogni richiesta. Il parametro pm nel file di configurazione del pool decide come questi worker vengono creati e distrutti nel tempo:

• dynamic: il numero di processi figli varia dinamicamente in base a pm.max_children, pm.start_servers, pm.min_spare_servers e pm.max_spare_servers. All’avvio del servizio vengono lanciati pm.start_servers worker, poi il pool si espande e si contrae seguendo il carico.
• ondemand: i processi vengono avviati solo quando arriva una richiesta, invece di essere già pronti all’avvio del servizio come accade con dynamic. Ottimo per il risparmio di memoria, meno per la latenza sul primo hit.
• static: il numero di processi figli è fisso, determinato unicamente da pm.max_children. Nessuna logica di scaling: i worker vengono creati all’avvio e restano attivi.

La documentazione ufficiale di PHP elenca tutte le direttive globali di php-fpm.conf, ma la scelta tra queste tre modalità è più una questione di architettura del server che di singola direttiva.

Un parallelo utile: il governor della CPU

Chiunque abbia mai armeggiato con le impostazioni di risparmio energetico della CPU (CPUFreq governor, presenti sia su *nix che su Windows) riconoscerà lo stesso identico compromesso:

• ondemand: scala la frequenza dinamicamente in base al carico corrente, saltando rapidamente alla frequenza massima per poi scendere durante i periodi di inattività.
• conservative: scala la frequenza in modo più graduale rispetto a ondemand.
• performance: mantiene sempre la CPU alla frequenza massima.

Il compromesso è lo stesso che si ritrova in PHP-FPM: un’impostazione privilegia la reattività immediata, le altre il risparmio di risorse durante i periodi di inattività. Con il governor performance, i core mantengono la frequenza massima invece di scalare verso il basso in idle: è un boost di prestazioni relativamente sicuro, il cui costo dipende quasi solo dai limiti termici della CPU. Lo stesso principio, applicato ai processi PHP-FPM invece che ai cicli di clock, è ciò che rende pm = static efficace su un server sotto carico costante.

Usare pm static per il massimo delle prestazioni

L’impostazione pm = static dipende fortemente dalla memoria libera disponibile sul server. Se la memoria è scarsa, ondemand o dynamic restano scelte più sicure. Se invece la memoria è disponibile, static elimina gran parte dell’overhead di gestione del pool impostando il numero di worker al massimo che il server può sostenere.

In pratica, pm.max_children con static va calcolato come il numero massimo di processi PHP-FPM che possono girare senza generare pressione sulla memoria disponibile o sulla cache del sistema, e senza saturare le CPU con una coda di operazioni PHP-FPM in attesa.

Un caso reale: un server con 32 GB di RAM installata, pm = static e pm.max_children = 100, usa un massimo di circa 10 GB. Anche con circa 200 utenti attivi negli ultimi 60 secondi (dato preso da Google Analytics), circa il 70% dei worker PHP-FPM resta idle. Questo è precisamente il punto: PHP-FPM lavora sempre alla capacità massima configurata, indipendentemente dal traffico istantaneo, e i worker idle restano pronti a rispondere immediatamente ai picchi di traffico invece di dover attendere che il process manager ne generi di nuovi (e poi li termini dopo che pm.process_idle_timeout scade).

Calcolare pm.max_children, non indovinarlo

Il passaggio più importante, spesso saltato, è misurare invece di stimare a occhio. Prima si misura la dimensione media residente (RSS) di un worker PHP-FPM sotto carico reale:

ps --no-headers -o rss -C php-fpm | awk '{ sum += $1; n++ } END { print sum/n/1024 " MB" }'

Da qui si procede per iterazioni: si testa sotto carico reale e si affina il valore osservando uso di memoria, utilizzo CPU e tempi di risposta. Con pm = static, poiché i worker restano già residenti in memoria, i picchi di traffico si traducono in picchi di carico e CPU molto più contenuti, e le medie restano più stabili nel tempo.

Per monitorare i processi attivi in tempo reale si può usare top filtrato per utente:

top -bn1 | grep php-fpm

Quando usare ondemand e dynamic invece di static

Con pm = dynamic capita spesso di incontrare un warning simile a questo nei log:

WARNING: [pool xxxx] seems busy (you may need to increase pm.start_servers,
or pm.min/max_spare_servers), spawning 32 children, there are 4 idle,
and 59 total children

dynamic e soprattutto ondemand restano invece la scelta giusta in scenari con molti pool PHP-FPM distinti sullo stesso server, ad esempio hosting condiviso con centinaia di account cPanel o siti diversi ciascuno con il proprio pool. In un ambiente con 100+ pool e 200+ domini, dove la maggior parte dei siti riceve pochissimo traffico, static o dynamic sprecherebbero enormi quantità di memoria su worker perennemente idle: ondemand chiude i worker inattivi liberando memoria, motivo per cui è diventato il default in ambienti come cPanel.

Un cenno ai container

Lo stesso ragionamento va adattato quando PHP-FPM gira dentro un container con risorse limitate (ad esempio 0.5 vCPU e 1 GB di RAM) e la scalabilità è orizzontale, tramite orchestrazione (Docker Swarm, Kubernetes). In questi contesti pm.static resta spesso l’unica scelta sensata a livello di singolo container, ma la decisione su quando far partire un nuovo container non può basarsi solo su CPU e memoria: va monitorato anche il numero di processi PHP-FPM attivi rispetto a pm.max_children. Se il pool ha 50 worker configurati e 40 sono già occupati, è il momento di avviare un nuovo container, indipendentemente da quanto CPU e RAM stiano effettivamente segnalando in quel momento. Questo richiede di esporre lo stato di php-fpm status al sistema di autoscaling, valutato a intervalli brevi.

Conclusione

Superata una certa soglia di traffico costante, ondemand e dynamic introducono un overhead di gestione dei processi che una configurazione static ben calcolata elimina alla radice. La regola pratica è semplice da enunciare ma richiede disciplina nell’applicarla: non indovinare pm.max_children, misurarlo a partire dal consumo medio di RSS dei worker sotto carico reale, lasciare margine per OS, web server e database, e poi affinare osservando le metriche reali. Su un server dedicato o una VM con traffico prevedibile, il guadagno in stabilità di CPU e tempi di risposta è concreto. Su hosting condiviso con centinaia di pool a bassissimo traffico, ondemand resta la scelta più razionale. Conoscere il proprio sistema, prima ancora del proprio codice PHP, è ciò che fa la differenza.

Fonte: PHP-FPM tuning: Using ‘pm static’ for max performance, LinuxBlog.io (Hayden James)

Oppo ha diffuso il primo teaser ufficiale di A7 Pro Max, nuovo capitolo della serie A7 che punta tutto sull’autonomia: a bordo debutta infatti una batteria da 10.000 mAh, la più capiente mai montata su uno smartphone del marchio.

Batteria record e ricarica rapida da 80W

Il teaser conferma la batteria da 10.000 mAh abbinata alla ricarica rapida da 80W. Nonostante la capacità fuori dal comune, Oppo dichiara uno spessore di soli 8,47 mm e un peso di 226 grammi: valori piuttosto contenuti per un dispositivo che solitamente, con batterie di queste dimensioni, tende a diventare ingombrante e pesante.

Il design svelato per la prima volta

Il teaser mostra anche il design del retro, caratterizzato da un modulo fotocamere rettangolare leggermente rialzato, con sensore principale a sinistra e flash LED a destra. Sul lato destro trovano posto i tasti di accensione e volume. Il comparto fotografico dovrebbe includere una fotocamera principale da 50 megapixel affiancata da un sensore ausiliario da 2 megapixel, mentre la fotocamera frontale monterebbe anch’essa un sensore da 50 megapixel, a conferma dell’attenzione riposta sui selfie.

Display OLED e Snapdragon 4 Gen 5 tra le indiscrezioni

Secondo i rumor circolati finora, A7 Pro Max monterà un pannello OLED da 6,78 pollici con risoluzione 1,5K e refresh rate a 120Hz, oltre al sensore di impronte digitali sotto lo schermo. Il software dovrebbe basarsi su ColorOS 16 con Android 16, mentre da Geekbench emerge la possibile presenza di un processore Snapdragon 4 Gen 5, affiancato fino a 12GB di RAM e 512GB di storage.

• Batteria da 10.000 mAh con ricarica a 80W
• Spessore di 8,47 mm e peso di 226 grammi
• Display OLED 6,78″ a 120Hz, risoluzione 1,5K
• Possibile Snapdragon 4 Gen 5 con ColorOS 16 su Android 16

Con questo teaser, la presentazione ufficiale di Oppo A7 Pro Max appare ormai imminente. Resta da capire se l’autonomia record si tradurrà in un reale vantaggio nell’uso quotidiano, ma le premesse per un modello dedicato a chi cerca il massimo della durata sembrano esserci tutte.

Honor ha annunciato che il suo atteso Honor Robot Phone debutterà ufficialmente il 12 agosto 2026. Il dispositivo si distingue per un sistema fotografico del tutto inedito, basato su un braccio robotico abbinato a un gimbal a tre assi, sviluppato in collaborazione con Arri, storico marchio delle cineprese professionali.

Una data attesa dopo mesi di anteprime

Il Robot Phone è stato mostrato al CES 2026, al MWC 2026 e persino al Festival di Cannes, guadagnandosi grande attenzione ben prima del lancio ufficiale. Il dispositivo ha fatto parlare di sé anche durante i festeggiamenti seguiti alla finale dei Mondiali FIFA 2026, quando il calciatore della nazionale spagnola Eric García è stato immortalato mentre lo utilizzava. Honor ha già aperto i preordini in Cina e ora ha fissato la data di presentazione ufficiale al 12 agosto.

Il braccio robotico segue automaticamente il soggetto

La caratteristica più originale è il gimbal a tre assi montato su un braccio robotico sul retro dello smartphone: è l’intera unità fotocamera a muoversi fisicamente, garantendo una stabilizzazione superiore e angolazioni di ripresa altrimenti impossibili su un telefono. A questo si aggiunge la funzione “AI Object Tracking”: basta un doppio tocco sul soggetto inquadrato perché il sistema lo segua automaticamente, mantenendolo sempre al centro della scena.

Specifiche da flagship, con Snapdragon 8 Elite Gen 5

Le indiscrezioni parlano di un Qualcomm Snapdragon 8 Elite Gen 5 sotto la scocca, abbinato a un display da 6,3-6,4 pollici con risoluzione 1,5K. Il comparto fotografico sarebbe di livello assoluto: fotocamera principale sul gimbal da 200 megapixel, ultra-grandangolare da 50 megapixel e teleobiettivo periscopico, anch’esso da 200 megapixel. La batteria dovrebbe attestarsi intorno ai 6.000 mAh.

• Gimbal a tre assi su braccio robotico, sviluppato con Arri
• AI Object Tracking per l’inseguimento automatico del soggetto
• Possibile Snapdragon 8 Elite Gen 5 e display 1,5K da 6,3-6,4″
• Tripla fotocamera con due sensori da 200MP

In un mercato dove l’intelligenza artificiale è ormai il terreno di scontro principale tra i produttori, Honor prova a differenziarsi puntando su hardware fotografico radicalmente diverso. Manca ormai pochissimo alla presentazione ufficiale, quando sapremo anche il prezzo.

Poco ha svelato data di lancio e caratteristiche principali del nuovo Poco M8 Power, il modello che punta tutto sull’autonomia. Il telefono arriverà con una batteria da 8.000 mAh e, novità per la fascia di prezzo, un display AMOLED al posto del classico LCD.

Debutto il 4 agosto, autonomia fino a tre giorni

Poco M8 Power debutterà ufficialmente il 4 agosto in India, dove sarà venduto tramite Flipkart. Il teaser diffuso dall’azienda conferma la batteria da 8.000 mAh, che secondo Poco garantisce fino a tre giorni di utilizzo con una sola carica: un dato pensato per chi mette l’autonomia al primo posto tra le priorità di acquisto.

Finalmente un pannello AMOLED

La novità più interessante riguarda il display: Poco ha confermato l’adozione di un pannello AMOLED, che promette colori più vivaci e neri più profondi rispetto ai display LCD montati finora su modelli simili. Non sono ancora stati diffusi dettagli su dimensioni, risoluzione e frequenza di aggiornamento. Sul fronte estetico, il teaser mostra anche una colorazione arancione, con un modulo fotocamere posteriore ben visibile: sensore principale e flash LED a sinistra, mentre a destra trovano posto il microfono e le scritte “50MP AI Camera” e il logo Poco.

Un possibile rebrand di Redmi Note 17

Secondo diverse indiscrezioni, Poco M8 Power potrebbe essere una versione rimarchiata del Redmi Note 17, già commercializzato in Cina. Nel frattempo si rincorrono anche le voci su un altro modello in arrivo, il Poco X8 5G: dopo alcune indiscrezioni su una possibile cancellazione, i rumor più recenti lo descrivono come una versione più economica del Poco X8 Pro, basata sul Redmi Note 17 Pro 5G.

• Batteria da 8.000 mAh, fino a 3 giorni di autonomia dichiarata
• Display AMOLED al posto dell’LCD
• Fotocamera principale da 50MP con IA
• Debutto in India il 4 agosto su Flipkart

Restano da confermare chipset, potenza di ricarica e prezzo, dettagli che Poco dovrebbe svelare in occasione della presentazione ufficiale del 4 agosto.

Xiaomi ha pubblicato il consueto report settimanale sui bug di HyperOS, elencando le correzioni già rilasciate per diversi smartphone e tablet della gamma. Gli aggiornamenti stanno arrivando in via prioritaria sulle build destinate alla Cina, con l’estensione alla versione globale prevista nelle prossime settimane.

Numerose correzioni per Xiaomi 17 e Xiaomi 15

Il report riguarda principalmente le build della serie HyperOS 3.0.3xx e interessa un ampio numero di dispositivi. Tra le correzioni più significative figurano il ritardo nell’apertura del pannello notifiche su Xiaomi 17 Ultra, il problema delle foto dinamiche mostrate come immagini statiche sul display posteriore di Xiaomi 17 Pro, e un crash nella funzione di rimborso dell’app Wallet su Xiaomi 17 Max.

Corretti anche problemi su fotocamera e aggiornamenti

Anche i modelli meno recenti hanno ricevuto attenzione: su Xiaomi 15 Ultra è stato risolto un bug che faceva sparire i pulsanti nella parte superiore dell’app fotocamera, mentre su Xiaomi 15 è stato corretto un problema che impediva il corretto completamento degli aggiornamenti di sistema. Xiaomi 14 Pro ha invece ricevuto la correzione di una notifica di aggiornamento di “Xiaomi Super Island” che non spariva dallo store delle app, mentre su Xiaomi Pad 8 Pro è stato risolto un crash improvviso dell’app di lettura Duokan Reader.

Alcuni problemi restano sotto indagine

Non tutto è stato risolto: Xiaomi conferma di essere ancora al lavoro su alcuni bug, come il mancato salvataggio nella galleria dell’effetto Leica Instant su alcune foto scattate con Xiaomi 17 Ultra, il malfunzionamento della messa a fuoco automatica su alcune unità di Xiaomi 15 Pro, e un’indicazione errata del livello di batteria su Redmi K90 Pro Max.

• Xiaomi 17 Ultra: corretto il ritardo di apertura del pannello notifiche
• Xiaomi 17 Pro: risolto il bug delle foto dinamiche sul display posteriore
• Xiaomi 15 Ultra: sistemata la scomparsa dei pulsanti in fotocamera
• Xiaomi 15: risolto il blocco degli aggiornamenti di sistema
• Ancora in corso: effetto Leica Instant, autofocus su 15 Pro, batteria su Redmi K90 Pro Max

Xiaomi ha confermato che le correzioni elencate arriveranno progressivamente anche sulla versione globale di HyperOS, oltre che su altri modelli non citati esplicitamente ma affetti dagli stessi problemi. Il ciclo di aggiornamenti resta piuttosto rapido, segno di un’attenzione costante al feedback degli utenti.

Diversi possessori di Xiaomi 15T Pro segnalano un fastidioso problema: in alcune circostanze il telefono non riceve le chiamate in arrivo. Le segnalazioni, partite dal forum giapponese Kakaku.com, sono state confermate da report simili in ambito internazionale, con diversi utenti che indicano un possibile legame con l’aggiornamento a HyperOS 3.

Il telefono risulta irraggiungibile durante la connessione Wi-Fi

Le segnalazioni arrivano da utenti che utilizzano la versione SIM-free di Xiaomi 15T Pro. Secondo quanto riportato, negli ultimi mesi le chiamate in entrata non risultano più raggiungibili con una certa frequenza, al punto che chi chiama sente il telefono come irraggiungibile. In alcuni test, il dispositivo risultava effettivamente fuori copertura al momento della chiamata, senza che arrivasse nemmeno l’SMS di notifica della chiamata persa, salvo poi ricevere in blocco tutte le notifiche non appena l’utente effettuava una chiamata in uscita.

Il dual SIM non sembra la causa

Inizialmente si è pensato a un problema legato alla configurazione dual SIM, ma anche utilizzando una sola scheda il problema non si è risolto, così come rimuovere le restrizioni sulla batteria per l’app telefono non ha portato benefici. Alcuni test hanno suggerito un legame con il Wi-Fi: disattivandolo, le chiamate tornano a essere ricevute regolarmente, il che fa pensare a un problema specifico della connessione dati Wi-Fi in combinazione con la rete cellulare.

Segnalazioni anche su Reddit, nessuna risposta ufficiale

Il problema non sembra confinato al mercato giapponese: su Reddit diversi utenti internazionali riportano lo stesso malfunzionamento, senza però trovare soluzione nonostante numerosi tentativi.

• Riavvio del dispositivo
• Reset delle impostazioni di rete
• Attivazione e disattivazione della modalità aereo
• Passaggio dal 5G al solo LTE
• Modifica delle impostazioni VoLTE e VoWiFi
• Sostituzione dell’app telefono con quella di Google

Diversi utenti collegano la comparsa del problema all’aggiornamento a HyperOS 3, ma al momento Xiaomi non ha fornito alcuna comunicazione ufficiale, limitandosi a dichiarare, tramite l’assistenza, di non essere a conoscenza di casi analoghi. Trattandosi di una funzione basilare come la ricezione delle chiamate, ci si aspetta un intervento rapido da parte dell’azienda, che al momento non ha ancora indicato una data per un eventuale aggiornamento correttivo.

Un confronto tra i punteggi Geekbench di tre flagship con lo stesso Snapdragon 8 Elite Gen 5 ha prodotto un risultato sorprendente: passando dal vecchio Geekbench 6 al nuovo Geekbench 7, Sony Xperia 1 VIII scavalca sia Xiaomi 17 Ultra sia Oppo, ribaltando completamente la classifica.

Il ribaltone tra Geekbench 6 e Geekbench 7

Confrontando i punteggi mediani dei tre modelli, tutti equipaggiati con lo stesso chip Qualcomm, emerge un quadro molto diverso a seconda del test. Su Geekbench 6, Xperia 1 VIII si fermava al terzo posto con 3.360/9.385 punti (single/multi-core), dietro a Xiaomi 17 Ultra (3.541/10.443) e Oppo CPH2841 (3.493/10.225). Su Geekbench 7, che introduce carichi di lavoro più pesanti e prolungati, la classifica si ribalta: Xperia 1 VIII sale al primo posto con 2.790/9.037 punti, mentre Xiaomi scende a 2.018/8.523 e Oppo crolla a 1.749/7.793.

Il sospetto: tarature “furbe” pensate solo per i benchmark

Il vero elemento interessante non è il calo dei punteggi in sé, comune a tutti e tre i modelli, ma la sua entità: mentre Xiaomi e Oppo perdono terreno in modo drastico, Xperia 1 VIII mantiene un calo molto più contenuto. Da tempo si sospetta che alcuni produttori cinesi rilevino l’avvio delle app di benchmark e spingano temporaneamente il clock della CPU oltre i limiti normali, ignorando temperatura e consumi, per ottenere punteggi elevati nei test brevi come Geekbench 6.

Geekbench 7 misura la resistenza, non solo la potenza di picco

Geekbench 7 introduce carichi legati a inferenza IA ed elaborazione parallela intensiva, che allungano i tempi di test e sottopongono il processore a un carico sostenuto. In questo scenario, i modelli con boost aggressivi incorrono più facilmente nel thermal throttling, il calo di prestazioni dovuto al surriscaldamento, mentre Xperia 1 VIII, storicamente più conservativo nella gestione del clock, riesce a mantenere prestazioni più stabili nel tempo.

• Stesso Snapdragon 8 Elite Gen 5 su tutti e tre i modelli
• Geekbench 6: Xiaomi e Oppo davanti, Xperia terzo
• Geekbench 7: Xperia 1 VIII primo, cali drastici per le rivali cinesi
• Il sospetto: boost aggressivi solo quando viene rilevato un benchmark

Se le tarature “su misura per i benchmark” diventeranno sempre più difficili da sfruttare, sarà la capacità di mantenere prestazioni stabili nel tempo, più che il picco istantaneo, a determinare il reale valore di uno smartphone.

Il flagship Sony Xperia 1 VIII ha debuttato al secondo posto nelle classifiche di vendita di giugno 2026 sia di Docomo sia di au, due dei principali operatori giapponesi. In entrambi i casi il primo posto resta saldamente nelle mani di iPhone 17, ma tra gli smartphone Android è proprio Xperia 1 VIII a guidare la classifica, un risultato notevole per un modello di fascia altissima.

Primo tra gli Android, nonostante il prezzo elevato

Secondo i dati pubblicati da ITmedia, Xperia 1 VIII, lanciato l’11 giugno, ha raggiunto la seconda posizione nelle classifiche di vendita sia di Docomo sia di au in appena una ventina di giorni dal lancio. Un risultato di rilievo considerando che il dispositivo viene venduto a circa 270.000 yen su entrambi gli operatori: è comunque il modello Android più venduto su entrambe le reti nel periodo considerato.

Nel frattempo, la serie Google Pixel 10a, fino a poco prima abituale protagonista delle prime posizioni, è scesa all’ottavo e nono posto su Docomo e al quarto posto su au: un cambiamento significativo negli equilibri di un mercato che negli ultimi tempi era dominato dai modelli di fascia media.

Un flagship costoso ai vertici è una rarità

Negli ultimi anni, complice anche una regolamentazione più severa sugli sconti concessi dagli operatori giapponesi, le prime posizioni delle classifiche di vendita Android erano quasi sempre occupate da modelli di fascia media o entry-level, oppure da varianti più accessibili come la serie Pixel a. Vedere una flagship da 270.000 yen conquistare il primo posto tra gli Android su entrambi i principali operatori è quindi un evento piuttosto raro negli ultimi tempi.

Fotocamere e dotazione “alla Sony” tra i punti di forza

Xperia 1 VIII monta uno Snapdragon 8 Elite Gen 5 e un comparto fotografico con tre sensori da circa 48 megapixel su grandangolare, ultra-grandangolare e teleobiettivo, quest’ultimo migliorato grazie a un sensore più grande per le prestazioni in condizioni di scarsa luminosità. Il telefono introduce inoltre un nuovo “assistente fotocamera IA” e mantiene alcune caratteristiche tipiche del marchio, come il tasto scatto dedicato, il jack per cuffie da 3,5mm e il supporto a schede microSD fino a 2TB. A completare il pacchetto, quattro aggiornamenti del sistema operativo e sei anni di aggiornamenti di sicurezza.

• Secondo posto assoluto sia su Docomo sia su au a giugno 2026
• Primo tra gli Android su entrambi gli operatori, nonostante il prezzo di circa 270.000 yen
• Pixel 10a in calo, dal podio alle posizioni medio-basse
• Snapdragon 8 Elite Gen 5, tripla fotocamera da 48MP e 6 anni di supporto sicurezza

Resta da vedere se Xperia 1 VIII riuscirà a mantenere questo slancio nei prossimi mesi, anche perché luglio porterà in classifica anche altri modelli come AQUOS R11 e arrows We3. Per ora, però, il segnale di un cambiamento negli equilibri del mercato Android giapponese è piuttosto chiaro.

Il futuro Samsung Galaxy S27, atteso all’inizio del 2027, potrebbe arrivare sul mercato con un aumento di prezzo superiore al solito. A pesare sono sia il rincaro della memoria, spinto dal boom della domanda legata all’intelligenza artificiale, sia la decisione di Qualcomm di alzare il prezzo dei chip Snapdragon.

Memoria più cara, e ora anche Qualcomm alza i prezzi

La crescente domanda di memoria per i data center dedicati all’intelligenza artificiale ha fatto impennare i prezzi della DRAM in tutto il 2026, tanto che sia Google (con la serie Pixel 11) sia Apple hanno già rivisto o lasciato intendere revisioni di prezzo su alcuni prodotti. A complicare ulteriormente il quadro è arrivata la notizia che Qualcomm avrebbe comunicato ai principali clienti un aumento a doppia cifra percentuale sui prezzi dei chipset per le spedizioni successive al primo settembre, giustificato dall’aumento dei costi dei componenti e della produzione.

Lo Snapdragon 8 Elite Gen 6 Pro potrebbe superare i 300 dollari

Il Galaxy S27 Ultra dovrebbe montare lo Snapdragon 8 Elite Gen 6 Pro, chip che si prevedeva già più costoso della generazione precedente ancora prima dell’annuncio del rincaro. Con l’aumento comunicato da Qualcomm, alcune stime indicano che il costo per singolo chip potrebbe superare i 300 dollari (circa 48.600 yen, cambio 1 dollaro = 162 yen). Trattandosi di uno dei componenti più costosi dell’intero smartphone, per i produttori non sarà semplice assorbire l’aumento senza ripercuotersi sul prezzo finale.

Un doppio rincaro difficile da assorbire

L’attuale Galaxy S26 Ultra parte da 1.299,99 dollari, ma il prossimo modello dovrà fare i conti con un aumento combinato di memoria e SoC. Già Galaxy Z Fold 8 e Galaxy Z Flip 8 hanno visto un rincaro di circa 100 dollari rispetto alla generazione precedente, e non sarebbe una sorpresa se Galaxy S27 Ultra seguisse una traiettoria simile o persino più marcata, trattandosi del modello di punta con il processore più potente, la memoria maggiore e il comparto fotografico più sofisticato della gamma.

Più spazio per gli Exynos, ma non tutti sono d’accordo

Una delle poche leve a disposizione di Samsung per contenere i costi è l’utilizzo dei propri chip Exynos. Già oggi, nella serie Galaxy S26, solo la variante Ultra monta Snapdragon a livello globale, mentre i modelli standard e Plus utilizzano l’Exynos 2600. Se i prezzi Qualcomm continuassero a salire, la quota di modelli con Exynos nella serie Galaxy S27 potrebbe crescere ulteriormente, anche se una parte consistente degli utenti continua a preferire le prestazioni e l’efficienza energetica offerte da Snapdragon.

• Prezzi della memoria in aumento per la domanda legata all’IA
• Qualcomm annuncia un rincaro a doppia cifra sui chip Snapdragon
• Snapdragon 8 Elite Gen 6 Pro potrebbe superare i 300 dollari a chip
• Possibile aumento della quota di modelli Galaxy con Exynos

Il rincaro di Qualcomm non riguarda solo Samsung: anche Xiaomi, OnePlus, Motorola, ASUS e Sony, tutti clienti Snapdragon, potrebbero risentirne. Con la carenza di semiconduttori legata alla domanda di IA destinata a proseguire, il 2027 si preannuncia un anno complicato sul fronte prezzi per l’intero comparto degli smartphone Android di fascia alta.

Secondo un’indiscrezione, il futuro Snapdragon 8 Elite Gen 6 Pro di Qualcomm introdurrà una nuova tecnologia basata sull’intelligenza artificiale per migliorare il frame rate nei videogiochi. La funzione, però, sarebbe riservata alla sola variante “Pro” del chip, e i giochi compatibili potrebbero essere pochi, almeno all’inizio.

AI Frame Fusion: upscaling e generazione di frame via IA

La nuova tecnologia, chiamata “AI Frame Fusion”, si ispira concettualmente a soluzioni già note nel mondo PC come il DLSS e il Frame Generation di Nvidia. L’obiettivo è ridurre il carico di rendering pur mantenendo un frame rate elevato, sfruttando l’intelligenza artificiale per migliorare la qualità dell’immagine e generare fotogrammi intermedi.

Secondo le indiscrezioni, la funzione lavorerebbe in due modalità principali. La prima è un upscaling che porta un rendering nativo a 1080p a una qualità paragonabile al 1440p, sfruttando vettori di movimento, informazioni di profondità e i fotogrammi precedenti. La seconda è una generazione di frame vera e propria, in cui l’IA crea un fotogramma intermedio a partire da due fotogrammi consecutivi, aumentando gli fps percepiti senza sovraccaricare la GPU.

Hardware dedicato solo sulla variante Pro

Il punto chiave è che questa funzione non sarebbe disponibile sullo Snapdragon 8 Elite Gen 6 “normale”. Secondo i leak, la GPU Adreno 850 della variante Pro integrerebbe due unità di calcolo dedicate chiamate “Matrix ALU”, indispensabili per far funzionare l’AI Frame Fusion. Senza questo hardware specifico, la versione standard del chip non potrebbe replicare la stessa funzione. Si vocifera inoltre di un possibile supporto alla memoria LPDDR6 sulla variante Pro, segno che Qualcomm vuole differenziare ancora di più i due modelli.

Il vero banco di prova: quanti giochi Android la supporteranno

Tecnicamente la proposta è interessante, ma il mercato dei giochi Android AAA che richiedono upscaling avanzato o generazione di frame resta ancora limitato. Le cose potrebbero cambiare se emulatori come Winlator o GameHub, usati per far girare titoli Windows su Android, integrassero il supporto ad AI Frame Fusion, ampliando di fatto la platea di giochi compatibili anche ai titoli PC emulati.

• AI Frame Fusion: upscaling da 1080p a qualità 1440p
• Generazione di fotogrammi intermedi via IA
• Disponibile solo su Snapdragon 8 Elite Gen 6 Pro, grazie a due unità Matrix ALU dedicate
• Possibile supporto alla memoria LPDDR6

Qualcomm porta ormai da anni nuove tecnologie dedicate al gaming, non sempre sfruttate appieno per la scarsità di titoli compatibili. Se l’azienda riuscirà a coinvolgere sviluppatori di emulatori e motori di gioco, l’AI Frame Fusion potrebbe davvero avvicinare l’esperienza di gioco su Android a quella delle GPU per PC.

Faugus Launcher 2.0 porta GTK4, AppImage, supporto GOG Galaxy e tante novità per avviare giochi Windows e Linux con ProtonStai leggendo Faugus Launcher 2.0 migliora il gaming su Linux con GTK4, AppImage e supporto GOG Galaxy, un articolo del blog Linux Easy. Non riprodurlo altrove senza permesso.

🔗 Leggi il post completo

YTSage, il downloader moderno per YouTube su Linux con supporto a video, audio, sottotitoli, playlist e guida completa all'installazione.
Stai leggendo YTSage il downloader YouTube con interfaccia grafica intuitiva, un articolo del blog Linux Easy. Non riprodurlo altrove senza permesso.

🔗 Leggi il post completo

Lumalarm è una sveglia per Linux che riattiva automaticamente il PC dalla sospensione e offre funzioni avanzate per evitare di riaddormentarsi.Stai leggendo Lumalarm la sveglia intelligente che riattiva automaticamente il PC, un articolo del blog Linux Easy. Non riprodurlo altrove senza permesso.

🔗 Leggi il post completo

MusicGrabber è una piattaforma self-hosted per scaricare musica da più fonti, organizzare la libreria e automatizzare playlist e artisti preferitiStai leggendo MusicGrabber: il servizio self-hosted che automatizza il download e l’organizzazione della musica, un articolo del blog Linux Easy. Non riprodurlo altrove senza permesso.

🔗 Leggi il post completo

Ogni settimana, il mondo del software libero e open source ci offre una moltitudine di aggiornamenti e nuove versioni di software. Anche se non tutti sono di grande rilevanza, molti di questi possono risultare...

🔗 Leggi il post completo

Wine (Wine Is Not an Emulator) è un progetto storico nato negli anni ’90 con l’obiettivo di permettere l’esecuzione di applicazioni e videogiochi sviluppati per Microsoft Windows all’interno di sistemi operativi come GNU/Linux, macOS...

🔗 Leggi il post completo

On Air è un widget per KDE Plasma 6 che porta radio online, podcast, registrazioni e streaming avanzato in un'unica interfaccia modernaStai leggendo On Air porta radio, podcast e streaming avanzato su KDE, un articolo del blog Linux Easy. Non riprodurlo altrove senza permesso.

🔗 Leggi il post completo

Migliaia di email di conferma iscrizione e newsletter che intasano la casella di posta in pochi minuti, seguite — puntuale come un copione — da un messaggio Teams di un fantomatico “IT Support” pronto ad aiutare. È la sequenza che eSentire’s Threat Response Unit (TRU) ha documentato in una campagna di luglio 2026 contro un’azienda del settore software, attribuita al broker di accessi iniziali UNC6692. Il bersaglio finale non è un semplice furto di credenziali: è l’installazione di Edgecution, un’estensione malevola per Microsoft Edge capace di evadere la sandbox del browser e prendere il controllo dell’host sottostante.

UNC6692 non è un nome nuovo per chi segue il crimine informatico organizzato: Google Cloud/Mandiant lo ha già descritto come un initial access broker (IAB) che prepara il terreno per gruppi ransomware, tra cui la syndicate nota come Payouts King. La catena osservata da eSentire — email bombing, impersonificazione IT via Teams, Quick Assist e una suite di malware modulare battezzata “SNOW” — è la stessa tradecraft già segnalata da Google e da The Hacker News nei mesi scorsi, ma il report più recente aggiunge dettagli tecnici granulari sull’ultimo anello della catena, l’estensione Edgecution, e sui suoi indicatori di compromissione.

Fase 1: sommergere la vittima di email per giustificare una chiamata

L’attacco si apre con una tecnica ormai da manuale ma sempre efficace: l’email bombing. Iscrivendo l’indirizzo della vittima a migliaia di newsletter e servizi di conferma automatica, gli attaccanti saturano la casella di posta in pochi minuti. L’obiettivo non è nascondere altro traffico, ma costruire un pretesto plausibile: un dipendente sommerso da email è più propenso ad accettare senza troppe domande il contatto di un “supporto IT” che offre di risolvere il problema.

Subito dopo il bombing, gli attaccanti contattano la vittima su Microsoft Teams impersonando l’identità “IT Support | Corporate IT Service (Internal)”. La scelta del canale non è casuale: Teams è percepito come un ambiente aziendale “fidato” rispetto alla posta elettronica, il che abbassa ulteriormente la soglia di sospetto della vittima nel momento cruciale.

Fase 2: Quick Assist come porta d’accesso hands-on

Il finto tecnico guida la vittima a lanciare Quick Assist, lo strumento di assistenza remota integrato in Windows, dando agli attaccanti accesso interattivo alla macchina. Da quel momento sono loro a dirigere l’infezione: portano la vittima su un sito di phishing ospitato su Amazon S3 e progettato per imitare una pagina Office 365. La pagina utilizza i primi due pulsanti per far scaricare alla vittima AutoHotkey e uno script stager, mentre un modulo di login raccoglie in chiaro la password Office 365 non appena viene premuto “invio”. Un dettaglio curioso della catena: lo script analizza persino gli appunti (clipboard) della vittima con un’espressione regolare, alla ricerca di un codice di riferimento fornito verbalmente durante la finta sessione di supporto — un ulteriore livello di “autenticazione sociale” della truffa.

Edgecution: un’estensione Edge che rompe il sandbox del browser

Il payload finale, Edgecution, combina un’estensione malevola per Microsoft Edge con un native messaging host in Python. È proprio questa combinazione a permettere all’estensione — normalmente confinata alla sandbox del browser — di comunicare con un processo nativo sul sistema operativo e, di fatto, evadere i limiti imposti dal browser stesso. Una volta installata, Edgecution è in grado di monitorare in tempo reale i siti web visitati dalla vittima, catturare le credenziali Office 365 inserite, scrivere file arbitrari sul disco, enumerare i processi in esecuzione ed eseguire comandi shell, Python o PowerShell a piacimento — di fatto un accesso remoto completo mascherato da componente del browser.

Lo stager scaricato dal sito S3 arriva come archivio ZIP protetto da password, estratto tramite tar.exe in una sottocartella nascosta dentro %LOCALAPPDATA%\Microsoft\Edge\User Data. Tutte le stringhe presenti nello stager e nel native messaging host sono offuscate con XOR e decodificate solo a runtime, un accorgimento pensato per rallentare l’analisi statica. Per la persistenza, il malware scrive voci di registro sotto la chiave NativeMessagingHosts di Microsoft Edge e crea — eseguendolo immediatamente — un’attività pianificata configurata per rilanciare Edge con l’estensione caricata a ogni accesso.

Un IAB al servizio del ransomware

Il quadro attributivo colloca UNC6692 non come gruppo ransomware in sé, ma come specialista dell’accesso iniziale che poi rivende o passa il testimone a operazioni di estorsione più ampie, in particolare Payouts King. È un modello di business ormai consolidato nell’ecosistema del cybercrime: separare chi entra da chi cifra e negozia il riscatto permette a entrambe le parti di specializzarsi e di essere più difficili da tracciare come un’unica organizzazione. Vista in quest’ottica, la sofisticazione dell’ingegneria sociale di UNC6692 — pretesto costruito ad arte, canale Teams “aziendale”, Quick Assist, verifica via clipboard — non è fine a se stessa: è l’investimento necessario per garantirsi l’accesso di alta qualità che un cliente ransomware è disposto a pagare.

Due righe per i difensori

Per i team blue team, la catena UNC6692 offre diversi punti di intercettazione prima che si arrivi a Edgecution. Il primo è comportamentale: un’ondata improvvisa di iscrizioni a newsletter verso una singola casella dovrebbe generare un alert automatico, così come un contatto Teams esterno o appena creato che si presenta come “IT Support” — Microsoft Teams consente di etichettare gli account esterni, e questa etichetta va monitorata, non ignorata dagli utenti. Il secondo punto di controllo è tecnico: le policy aziendali dovrebbero limitare l’uso di Quick Assist ai soli casi avviati dall’help desk interno tramite ticket, bloccandolo o quantomeno alertando su ogni sessione avviata da un utente su richiesta esterna. Sul fronte endpoint, vale la pena monitorare la creazione di voci sotto HKLM\SOFTWARE\Microsoft\Edge\NativeMessagingHosts e la creazione di scheduled task che rilanciano msedge.exe con parametri di estensione custom, oltre a restringere via policy quali estensioni Edge possono essere installate al di fuori dello store ufficiale.

Va sottolineato che, secondo eSentire, l’archivio ZIP di Edgecution viene ricostruito da byte “spogliati” dell’header standard, un dettaglio che rende la sua individuazione tramite semplice controllo di firma file inefficace: servono euristiche comportamentali o EDR capaci di ispezionare i native messaging host registrati, non solo le estensioni installate nel browser.

Indicatori di compromissione

[Infrastruttura C2 Edgecution - domini CloudFront]
d385m5skczp5q5.cloudfront[.]net
d7xpwoah6gdv2.cloudfront[.]net
(+ 5 domini CloudFront aggiuntivi identificati da eSentire TRU)
[URL di delivery phishing/payload - Amazon S3]
hxxps://app7040.s3.us-east-1.amazonaws[.]com/patch.html
hxxps://app5805.s3.us-east-1.amazonaws[.]com/js/patch3265343.a
(+ 3 URL aggiuntivi identificati da eSentire TRU)
[Hash SHA-256 - artefatti sito phishing e payload]
232bca658c585627830623fcdce56647dc291666b25c901ee56212681198067a
e88c196a86c74ea0e53dfe77c93f577cb441ee590756cf7f3284522a2d6a6be5
da1cf68c9dc1cebcebf8ec7d1cf99ac9c0291db7b21bf279b9cad24c7a49948c
[Comandi osservati in fase di deployment]
tar.exe -xf ".zip" -C "%LOCALAPPDATA%\Microsoft\Edge\User Data\test1" --passphrase ""
cmd.exe /c python --version 2>&1
cmd /c start /min ... & del
[Account Microsoft Teams usati per l'impersonificazione IT]
Identità display: "IT Support | Corporate IT Service (Internal)"
(indirizzi email specifici omessi dalla fonte originale)
[Persistenza]
Chiave di registro: HKLM\SOFTWARE\Microsoft\Edge\NativeMessagingHosts\
Meccanismo: Scheduled Task creato ed eseguito immediatamente per rilanciare Microsoft Edge con l'estensione caricata

Per tre giorni, tra il 9 e il 13 luglio 2026, un server ospitato a Hong Kong ha lasciato aperte al mondo intero tre directory contenenti l’intera cassetta degli attrezzi di un’operazione contro il Ministero delle Finanze thailandese. Dentro, oltre 580 file e 470 MB di exploit, webshell e credenziali rubate, i ricercatori di Hunt.io e il giornalista Bob Diachenko hanno trovato qualcosa di nuovo: i log di un agente IA autonomo, Hermes, lasciato libero di enumerare host, scalare privilegi e frugare tra i file di un ministero senza che nessun essere umano ne supervisionasse i comandi in tempo reale.

Non è la prima volta che un attore offensivo delega lavoro di routine a un modello linguistico: negli ultimi mesi si sono già visti agenti IA usati in intrusioni ransomware e cloud, e persino in operazioni di spionaggio attribuite ad attori legati alla Cina. Ma il caso thailandese, documentato da Hunt.io in un report pubblicato il 25 luglio, è tra i primi a mostrare un’agente IA che opera davvero “senza supervisione” — in modalità YOLO, senza prompt di conferma — contro un obiettivo governativo, mentre un impianto Go inedito, ribattezzato dall’operatore stesso “Hades”, veniva preparato per garantire la persistenza sui sistemi compromessi.

Un server in Hong Kong, tre directory aperte

L’infrastruttura ruota attorno all’indirizzo 43.246.208[.]207, allocato da AS132883 (TOPIDC, Hong Kong). Non è un server anonimo qualsiasi: Hunt.io lo classifica ad alto rischio perché in passato ha ospitato un controller ShadowPad, e al momento dell’analisi serviva anche un server C2 VShell sulla porta 21083. Un solo dominio, redhatupdating432.dnsrd[.]com, risolveva verso l’host, ma la sua presenza precede l’attività osservata, che i ricercatori collocano tra fine giugno e i primi di luglio 2026.

Sul server sono state trovate tre directory aperte in rapida successione: il 9 luglio (145 file, tra cui exploit per diverse CVE, script per attacchi alle caselle di posta del ministero e i primi log di Hermes), il 10 luglio (62 eseguibili Go compilati per Windows e Linux, incluso l’impianto Hades) e una terza il 13 luglio. Un pivot sui certificati TLS — tutti con Common Name “www” ma organizzazioni emittenti rotanti come “Web Services” o “Cloud Platform”, uniti dalla stessa impronta JA4X — ha permesso di collegare altri due host alla stessa infrastruttura: uno in Malesia (118.107.222[.]232) e un secondo a Hong Kong (202.181.27[.]115), quest’ultimo usato come nodo C2 secondario per Hades.

Hermes: l’agente che ha fatto il lavoro sporco

Hermes è un agente IA open source pubblicato a febbraio 2026, capace di funzionare come demone persistente con memoria tra sessioni, e ha da tempo superato le 140.000 stelle su GitHub, diventando uno dei framework agentici più diffusi. Tra le sue modalità operative c’è “YOLO”, che elimina le richieste di conferma umana prima di eseguire comandi potenzialmente pericolosi — esattamente l’impostazione che l’operatore ha scelto di attivare.

Nella directory hermes-results recuperata il 9 luglio, Hunt.io ha trovato cinque file di log (schema call_00_[ID].txt) che documentano l’agente al lavoro: una prima scansione LinPEAS per la valutazione dell’escalation di privilegi, una seconda esecuzione LinPEAS per l’enumerazione dei servizi, una ricerca di binari SUID/SGID, un’enumerazione di container e file system (con numerosi errori di broken pipe, segno che l’agente produceva più output di quanto il server riuscisse a gestire) e, infine, una ricerca ricorsiva nella web root collegata all’ufficio del Segretario Permanente del ministero, dove ha esposto documenti Office, moduli di valutazione del personale e archivi risalenti al 2012.

Lo script LinPEAS fornito all’agente era stato personalizzato per verificare tre CVE Linux del 2026: CVE-2026-43503 (“DirtyClone”), CVE-2026-31431 (“Copy Fail”, nel modulo algif_aead) e CVE-2026-43284/CVE-2026-43500 (“Dirty Frag”), tutte vulnerabilità locali di privilege escalation nel kernel Linux. Un file di configurazione recuperato mostra inoltre l’indirizzo IP del client SSH usato per operare l’agente, 103.97.0[.]57 (AS133073, Hong Kong), un quarto nodo dell’infrastruttura dell’attaccante.

Il pannello web di Hermes espone un fingerprint HTTP riconoscibile — header Server: HermesWebUI, realm Basic-auth “Hermes WebUI” — che ha permesso a Hunt.io di censire i pannelli esposti in rete: quasi 5.900 eventi nell’ultimo mese. Un secondo pivot sul percorso predicibile /hermes-results/call_*.txt ha restituito 575 directory con output dell’agente pubblicamente accessibili senza autenticazione, un’indicazione che l’uso “disattento” di questi agenti da parte di altri operatori è tutt’altro che isolato.

Hades: l’impianto che tiene il terreno

Se Hermes ha fatto l’enumerazione, il lavoro di persistenza è affidato a Hades, un impianto Go inedito individuato nella directory del 10 luglio insieme a 62 binari compilati per Windows (PE) e Linux (ELF), molti dei quali mascherati da processi di sistema legittimi — ctfmon, csrss, conhost, MicrosoftEdgeUpdate su Windows; kworker, multipathd, accounts-daemon su Linux. Alcuni file, come hades_linux_amd64 e hades_windows_amd64, portano invece il nome del progetto e sembrano fungere da template.

L’analisi statica e dinamica dei due campioni recuperati (uno per piattaforma) conferma che condividono lo stesso codebase. Tra le funzionalità di sicurezza operativa integrate: un kill-date configurabile (variabile d’ambiente HADES_KILLDATE) e un orario di lavoro programmato, che tiene il beacon “addormentato” fuori da una finestra oraria configurata per ridurre le probabilità di essere rilevato. Sul lato tecniche, il malware usa process hollowing su svchost.exe per il caricamento riflessivo del PE, persistenza via chiave di registro Run e task pianificati su Windows (cron su Linux), comunicazione HTTPS su percorsi URI camuffati da asset statici, e include capacità di screenshot basate su GDI. Il nome — nella mitologia greca Hermes accompagna le anime nell’Ade — è probabilmente una scelta non casuale dell’operatore.

Il bersaglio: Hadoop, Hive e credenziali di posta

Gli script e i file di configurazione recuperati fanno riferimento a sistemi del Ministero delle Finanze per nome host e indirizzo interno: un pannello amministrativo web, un cluster big-data Apache Hadoop e la relativa piattaforma di gestione Ambari, tutti su IP non instradabili — un livello di conoscenza della topologia interna che suggerisce una fase di ricognizione precedente non documentata nei file recuperati. Tra gli artefatti anche una web shell PHP camuffata da file di cache di sistema, tunnel HTTP suo5, e script Perl/Python per attacchi di password spraying contro l’infrastruttura di posta ministeriale con wordlist mirate. File di cookie jar mostrano inoltre token di sessione e CSRF sottratti da un pannello amministrativo e da una piattaforma di document management interna.

Cookie di sessione attivi, webshell distribuite e accesso alla rete interna indicano che l’operatore è riuscito a compromettere più sistemi all’interno della rete del MOF. Il vettore di accesso iniziale, tuttavia, resta sconosciuto: non è emerso dai documenti analizzati. Hunt.io e Diachenko hanno notificato il CERT nazionale thailandese e la National Cyber Security Agency (NCSA) il 15 luglio, ricevendo conferma di presa in carico lo stesso giorno; la pubblicazione della ricerca è stata trattenuta per la consueta finestra di disclosure di 7 giorni. Al momento della scrittura il ministero non ha confermato la violazione.

Due righe per i difensori

Il dato tecnico più interessante non è la singola vulnerabilità sfruttata, ma la combinazione: un agente IA che coordina l’enumerazione e la scoperta di privilege escalation, un impianto cross-platform con opsec dedicata che tiene l’accesso, e tooling scritto su misura per un bersaglio specifico. Per i team di sicurezza, Hunt.io suggerisce interventi molto concreti: rivedere la modalità di autenticazione di HiveServer2 (il default NONE accetta qualunque credenziale via SASL PLAIN), applicare la blocklist delle UDF Hive, effettuare audit ricorsivi delle web root alla ricerca di file PHP con nomi “a punto” che imitano cache di sistema, aggiornare sudo alla 1.9.5p2 e verificare la presenza di CVE-2021-4034 (PwnKit), disabilitare WebDAV su eventuali istanze IIS 6.0 residue, e soprattutto allertare su connessioni in uscita da processi web server verso porte interne come 10000 o 50070 — un web server che raggiunge un nodo Hadoop è di per sé un segnale forte.

Più in generale, il caso conferma una tendenza che i team di threat intelligence osservano da mesi: gli agenti IA “agentic” stanno diventando un moltiplicatore di forza per operatori anche non particolarmente sofisticati, capaci di automatizzare fasi di post-exploitation che un tempo richiedevano ore di lavoro manuale. E, come dimostra la scoperta di 575 directory /hermes-results/ esposte pubblicamente, la fretta con cui questi strumenti vengono dispiegati genera essa stessa nuove superfici di esposizione per chi li usa.

Indicatori di compromissione

[Infrastruttura di rete]
43.246.208[.]207   - AS132883 TOPIDC, Hong Kong - server con directory aperte (9/10/13 luglio)
103.97.0[.]57      - AS133073 HK Kwaifong Group, Hong Kong - client SSH verso il server di staging
118.107.222[.]232  - AS55720 The Gigabit, Malaysia - overlap certificato TLS 'www'
202.181.27[.]115   - AS134196 Converged Communications, Hong Kong - overlap certificato TLS 'www'
redhatupdating432.dnsrd[.]com - dominio storicamente risolto verso 43.246.208[.]207
[Hash SHA-256]
linux_amd64 (VShell stage 1, Linux):      0f8c905aa25c86f85454acb7e77bf5c50220c2a82e5b69a33741e55c8a85f2fc
windows_amd64.exe (VShell stage 1, Win):  a9447ae174f4aa54f760b7d7cc985c1a970f31e151d3ff66fac247f99ba1b509
linux_amd64 (VShell stage 2, Linux):      ec7e9ab43a0cc65d29f0b84a93ba88c43d01fed3dec5c968525dc73c03cbfda2
windows_amd64.exe (VShell stage 2, Win):  b65b7ede835ebba36294d52d7780065523340ee09bb8b209ef2dc495e53dfd53
multipathd_04d0 (Hades, Linux):           d252ee7b348b7e43e432d8fb154465838f5cd5fb564905323460e6f0a0c7d1e2
dwm_33b7.exe (Hades, Windows):            c74010aa82e8164c8d4ca9e073ec6b9a762e53db67498b22f5ccaef3a82853f
[Configurazione Hades]
User-Agent:    Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36
Check-in:      /assets/app.min.js
Tasking:       /assets/vendor.js
Result upload: /assets/main.js
Env var:       HADES_KILLDATE (kill-date operativo)
[CVE sfruttate per privilege escalation nello script LinPEAS custom]
CVE-2026-43503 (DirtyClone) - LPE kernel Linux
CVE-2026-31431 (Copy Fail, modulo algif_aead) - LPE kernel Linux
CVE-2026-43284 / CVE-2026-43500 (Dirty Frag) - LPE via page-cache write
CVE-2021-3156 (sudo heap overflow) e CVE-2021-4034 (PwnKit) - exploit staged sul server
[Fingerprint per rilevare pannelli Hermes esposti]
Header: Server: HermesWebUI
Basic-auth realm: "Hermes WebUI"
Percorso output: /hermes-results/call_*.txt
Porta osservata sul server di staging: 8878

C’è un momento in cui un’operazione di ransomware smette di essere un pugno di script e diventa un’azienda vera e propria, con reparti, scadenze e un pannello di controllo. Per il gruppo Funky Mantis, noto anche come DevMan, quel momento è arrivato tra la fine del 2025 e il gennaio 2026, quando la sua infrastruttura di attacco si è trasformata in una piattaforma centralizzata capace di gestire più operazioni contemporaneamente, con tanto di CRM interno per tracciare vittime, curatori e pagamenti attesi. A ricostruirlo sono stati gli analisti di Catalyst/Prodaft, che hanno esaminato due versioni del pannello web del gruppo e trovato indizi che l’infrastruttura sia stata usata in almeno un attacco reale.

Da toolkit a piattaforma “as-a-service”

Funky Mantis opera secondo il modello ormai classico del ransomware-as-a-service: gli amministratori mantengono un’infrastruttura chiusa a cui gli affiliati accedono per ottenere accesso a reti già compromesse, generare versioni del malware, negoziare con le vittime e monitorare i pagamenti. Quello che distingue questa gang è la maturità del tooling gestionale. La prima versione del pannello, osservata a fine 2025, offriva già funzioni per creare varianti del malware, una sezione finanziaria, una chat diretta con le vittime e supporto tecnico per gli affiliati in difficoltà.

A gennaio 2026 è comparsa una seconda versione, con un sistema di contabilità molto più sofisticato: gli operatori possono creare team, assegnare partecipanti a specifici bersagli, tracciare lo stato di ogni attacco, le scadenze di pagamento e l’incasso atteso per ciascuna vittima. È, di fatto, un CRM per l’estorsione, che permette di coordinare più campagne parallele da un’unica cabina di regia — la stessa logica organizzativa di una software house legittima, applicata alla gestione degli attacchi ransomware su scala.

Cosa rivelano le chat interne

I ricercatori hanno avuto accesso a messaggi privati scambiati tra i partecipanti al programma, che mostrano l’organizzazione interna del gruppo: gli amministratori distribuiscono l’accesso a reti compromesse in diversi paesi, assegnano “curatori” (curator) che supervisionano gli affiliati e impongono scadenze strette, spesso di pochi giorni, per portare a termine l’attacco. Nelle conversazioni ricorrono riferimenti a organizzazioni del settore sanitario, infrastrutture critiche, ambito commerciale ed enti governativi. È interessante notare che, in alcuni casi, gli affiliati si limitano a dichiarare un attacco riuscito senza che i ricercatori abbiano potuto confermarne l’effettivo esito — un promemoria che, nell’ecosistema RaaS, la vanteria fa parte del modello di business quanto il cifrario stesso.

Il cifrario: ChaCha20-Poly1305 e la caccia ai sistemi medicali

Sul piano tecnico, gli analisti hanno esaminato la variante Windows del cifrario. Il programma verifica i privilegi di amministratore, tenta di disattivare le protezioni native di Windows, arresta servizi specifici, elimina le shadow copy di sistema per impedire il ripristino, enumera le risorse di rete raggiungibili e cifra i file sia sui dischi locali sia sugli storage connessi. Al termine dell’esecuzione rilascia una nota di riscatto e, in alcune configurazioni, può autoeliminare il proprio eseguibile per ostacolare l’analisi forense successiva.

La cifratura utilizza l’algoritmo ChaCha20-Poly1305 e aggiunge ai file colpiti l’estensione .devman21 — dettaglio che conferma il legame con l’alias DevMan con cui il gruppo è tracciato in altre fonti. Il malware è chiaramente orientato all’ambiente corporate: tra i bersagli figurano documenti, database, backup, macchine virtuali, codice sorgente e, soprattutto, file collegati a sistemi medicali. Gli operatori promuovono separatamente attacchi contro infrastrutture critiche e offrono funzionalità dedicate per colpire sistemi di controllo industriale, segnalando un’ambizione che va oltre la crittografia opportunistica di file server aziendali.

Un punto resta però non confermato: se il gruppo eserciti davvero double extortion con esfiltrazione dei dati. Il servizio pubblicizza questa capacità nei materiali promozionali rivolti agli affiliati, ma gli analisti non hanno trovato né strumenti di exfiltration né tracce concrete di trasferimento file verso l’esterno. È possibile che si tratti, almeno in parte, di una promessa commerciale non ancora del tutto implementata — un dettaglio che i difensori non dovrebbero comunque dare per scontato in fase di risposta all’incidente.

Come rilevarlo: TTP invece di hash

Il consiglio più utile che arriva dalla ricerca di Catalyst Prodaft riguarda l’approccio alla detection. Data la velocità con cui varianti e hash del cifrario possono cambiare tra un affiliato e l’altro, gli analisti raccomandano di non basare il rilevamento su file isolati o firme statiche, ma sulla sequenza di azioni tipica di un attacco in preparazione. Tra gli indicatori comportamentali da monitorare: accessi remoti anomali, uso successivo di account con privilegi elevati, attività insolita su condivisioni SMB, modifiche alle Group Policy, disattivazione di meccanismi di protezione endpoint e cancellazione di meccanismi di recupero come le shadow copy. Questo approccio “TTP-first” consente di intercettare la fase di preparazione dell’attacco prima ancora che il cifrario venga effettivamente distribuito, quando le opzioni di risposta sono ancora molte.

Per i team di sicurezza che operano in ambito sanitario o industriale, il caso Funky Mantis è un altro segnale che il ransomware-as-a-service sta convergendo verso modelli operativi sempre più simili a normali strumenti SaaS di project management — il che, paradossalmente, li rende anche più prevedibili da un punto di vista comportamentale, se si sa dove guardare.

Indicatori di compromissione

Gruppo: Funky Mantis (alias DevMan)
Modello: Ransomware-as-a-Service (RaaS) con pannello CRM per affiliati

Estensione file cifrati: .devman21
Algoritmo di cifratura: ChaCha20-Poly1305

Comportamenti osservati (Windows):
- Verifica privilegi amministrativi
- Tentativo di disattivazione delle protezioni Windows native
- Arresto di servizi specifici prima della cifratura
- Cancellazione delle shadow copy di sistema (inibizione del recovery)
- Enumerazione risorse di rete/condivisioni SMB
- Cifratura di dischi locali e storage connessi
- Possibile autoeliminazione del binario a fine esecuzione

Settori target: sanità (sistemi medicali), infrastrutture critiche/ICS,
ambito commerciale, enti governativi

Indicatori comportamentali da monitorare (TTP-first, non solo hash):
- Accesso remoto anomalo seguito da uso di account privilegiati
- Attività insolita su SMB / enumerazione di condivisioni di rete
- Modifiche alle Group Policy
- Disattivazione di strumenti di protezione endpoint
- Cancellazione di shadow copy o altri meccanismi di recupero dati

Fonte primaria: Catalyst Prodaft, "Funky Mantis platform: coordination and locker analysis"

Ubuntu Touch è una versione mobile del sistema operativo Ubuntu, sviluppata e mantenuta dalla comunità UBports. Il progetto nacque inizialmente all’interno di Canonical, con l’obiettivo ambizioso di creare una vera convergenza tra smartphone e...

🔗 Leggi il post completo

Debian discute una proposta per vietare o regolamentare i contributi realizzati con strumenti di intelligenza artificiale nei progetti ufficiali.Stai leggendo Debian apre il dibattito sull’intelligenza artificiale: vietare o regolamentare i contributi?, un articolo del blog Linux Easy. Non riprodurlo altrove senza permesso.

🔗 Leggi il post completo

ArDali WebMedia unisce browser Chromium, strumenti multimediali avanzati, gestione password e audio professionale in un'unica applicazione.Stai leggendo ArDali WebMedia riunisce browser Chromium, audio professionale e strumenti multimediali, un articolo del blog Linux Easy. Non riprodurlo altrove senza permesso.

🔗 Leggi il post completo

Perché ogni server esposto a Internet ha bisogno di Fail2ban

Basta controllare i log di autenticazione di un qualunque server Linux raggiungibile da Internet per rendersi conto di un fatto scomodo: nel giro di poche ore compaiono centinaia di tentativi di accesso falliti su SSH, pannelli web o form di login. Non è un attacco mirato: sono scanner automatici che perlustrano di continuo intere sottoreti, alla ricerca di credenziali deboli o servizi mal configurati. Ignorare questo rumore di fondo non è un’opzione, ma bloccare manualmente ogni IP sospetto è impraticabile.

Fail2ban risolve il problema analizzando i log in tempo reale e bannando automaticamente, tramite il firewall, gli indirizzi IP che superano una soglia di tentativi falliti in una finestra temporale configurabile. È uno strumento maturo, leggero, presente nei repository di tutte le principali distribuzioni, ma la configurazione di default lascia molto sul tavolo: un bantime di 10 minuti, tanto per fare un esempio, è quasi inutile contro un attaccante automatizzato che può semplicemente aspettare e riprovare.

In questa guida vediamo come installare, configurare e soprattutto tunare Fail2ban per ottenere una protezione reale, con particolare attenzione agli scenari più comuni su un server di produzione: SSH, Nginx, firewall moderni basati su nftables e persistenza dei ban tra un reboot e l’altro.

I tre concetti chiave: filter, jail, action

Prima di mettere mano alla configurazione conviene avere chiaro il modello concettuale di Fail2ban, perché tutta la configurazione ruota attorno a tre elementi:

• Filter: un insieme di espressioni regolari che individuano le righe di log corrispondenti a un tentativo di accesso fallito.
• Jail: combina un filtro con il percorso del log da monitorare, le soglie di attivazione e l’azione da eseguire al superamento della soglia.
• Action: cosa succede quando la soglia viene superata. Nella maggior parte dei casi è una regola firewall, ma può includere anche l’invio di una notifica via email.

Fail2ban include già filtri e jail pronti per decine di servizi (SSH, Apache, Nginx, Postfix, Dovecot…). Nella pratica quotidiana ci si limita ad abilitare le jail utili e a regolare qualche parametro.

Installazione

Fail2ban è disponibile nei repository ufficiali di tutte le distribuzioni principali.

Debian/Ubuntu:

sudo apt update
sudo apt install fail2ban

sudo dnf install fail2ban

sudo pacman -S fail2ban

sudo systemctl enable --now fail2ban
sudo systemctl status fail2ban

Configurare Fail2ban nel modo corretto

Un errore comune è modificare direttamente /etc/fail2ban/jail.conf: questo file viene sovrascritto a ogni aggiornamento del pacchetto, con conseguente perdita delle personalizzazioni. L’approccio corretto è creare un file dedicato dentro jail.d/:

sudo nano /etc/fail2ban/jail.d/custom.conf

sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

La sezione [DEFAULT]

Nella sezione [DEFAULT] si impostano i valori applicati a tutte le jail, salvo override specifico:

[DEFAULT]
bantime  = 1h
findtime = 10m
maxretry = 5
ignoreip = 127.0.0.1/8 ::1

• bantime: durata del ban. Il default (spesso 10 minuti) è troppo permissivo: 1 ora è un buon punto di partenza, e per attaccanti persistenti si può salire a 24h o 1w. Il valore -1 produce un ban permanente, da usare con cautela.
• findtime: la finestra temporale in cui vengono contati i fallimenti.
• maxretry: numero di tentativi falliti prima del ban. 5 è ragionevole per SSH, si può scendere a 3 per una postura più aggressiva.
• ignoreip: gli IP che non verranno mai bannati. È fondamentale aggiungere qui il proprio IP prima di abilitare qualsiasi jail: restare fuori dal proprio server per un ban accidentale è un classico errore da evitare.

Se il server ha un indirizzo IPv6 pubblico, va incluso anche quello: alcuni filtri più datati intercettano solo IPv4, quindi conviene verificare che le jail catturino correttamente entrambi i protocolli.

La jail SSH

È la jail più importante per la maggior parte dei server. In jail.local o in un nuovo file /etc/fail2ban/jail.d/sshd.conf:

[sshd]
enabled  = true
port     = ssh
logpath  = %(sshd_log)s
backend  = %(sshd_backend)s
maxretry = 3
bantime  = 1h

sudo fail2ban-client reload

Jail per Nginx

I server web attirano un tipo diverso di abuso: scanner di URL 404, bruteforcer su form di login, bot che generano richieste inutili.

[nginx-http-auth]
enabled  = true
logpath  = %(nginx_error_log)s
maxretry = 3

[nginx-limit-req]
enabled  = true
logpath  = %(nginx_error_log)s
maxretry = 10

Verificare jail e ban attivi

Il comando fail2ban-client è lo strumento principale per monitorare la situazione. Elenco delle jail attive:

sudo fail2ban-client status

sudo fail2ban-client status sshd

sudo fail2ban-client set sshd banip 203.0.113.99
sudo fail2ban-client set sshd unbanip 203.0.113.99

Ban incrementali con la jail recidive

Una delle funzionalità meno conosciute ma più efficaci di Fail2ban è la jail recidive, che monitora il log interno di Fail2ban stesso e applica ban molto più lunghi agli IP che, dopo la scadenza di un primo ban, tornano a fare bruteforcing.

[recidive]
enabled  = true
logpath  = /var/log/fail2ban.log
action   = %(action_mwl)s
bantime  = 1w
findtime = 1d
maxretry = 5

Testare i filtri prima di attivarli

Prima di abilitare una jail, conviene verificare che il regex del filtro corrisponda davvero alle righe di log presenti sul sistema:

sudo fail2ban-regex /var/log/auth.log /etc/fail2ban/filter.d/sshd.conf

# /etc/fail2ban/filter.d/myapp-auth.conf
[Definition]
failregex = ^<HOST> .* "POST /login" 401
ignoreregex =

nftables, firewalld e persistenza dei ban

Su Debian 12+ e Ubuntu 22.04+, nftables è il backend firewall di default. L’azione di ban predefinita di Fail2ban usa ancora iptables, che nella maggior parte delle installazioni funziona tramite il layer di compatibilità iptables-nft. Se invece si usa nftables puro, l’azione va impostata esplicitamente:

banaction = nftables-multiport
banaction_allports = nftables-allports

banaction = firewallcmd-rich-rules
banaction_allports = firewallcmd-allports

dbfile = /var/lib/fail2ban/fail2ban.sqlite3
dbpurgeage = 7d

Una configurazione di partenza completa

Ecco un file /etc/fail2ban/jail.d/custom.conf che copre i casi d’uso più comuni su un server Linux tipico, da usare come punto di partenza:

[DEFAULT]
bantime  = 2h
findtime = 10m
maxretry = 5
ignoreip = 127.0.0.1/8 ::1
dbfile = /var/lib/fail2ban/fail2ban.sqlite3
dbpurgeage = 7d

[sshd]
enabled  = true
port     = ssh
logpath  = %(sshd_log)s
backend  = %(sshd_backend)s
maxretry = 3
bantime  = 6h

[nginx-http-auth]
enabled  = true
logpath  = %(nginx_error_log)s
maxretry = 4

[nginx-limit-req]
enabled  = true
logpath  = %(nginx_error_log)s
maxretry = 10

[recidive]
enabled  = true
logpath  = /var/log/fail2ban.log
bantime  = 1w
findtime = 1d
maxretry = 5

sudo fail2ban-client reload
sudo fail2ban-client status

Cosa Fail2ban non risolve

Fail2ban è uno strumento reattivo, non preventivo: banna un IP solo dopo che ha già effettuato diversi tentativi. Non copre, da solo, alcuni scenari:

• attacchi bruteforce distribuiti su migliaia di IP diversi, ciascuno con uno o due tentativi soltanto;
• exploit zero-day che non generano righe di log riconoscibili;
• attacchi a livello applicativo che non producono un fallimento di autenticazione tracciabile.

Per una protezione a più livelli, Fail2ban va affiancato all’autenticazione SSH tramite chiavi (disabilitando del tutto l’autenticazione via password), a un firewall configurato correttamente e a una revisione periodica dei log. Un’attenzione particolare va riservata ai server dietro Cloudflare o un altro reverse proxy: senza ripristinare l’IP originale del visitatore (tramite mod_remoteip su Apache o real_ip_module su Nginx), Fail2ban finirebbe per bannare gli IP del proxy stesso invece degli attaccanti reali.

Comandi da tenere sempre a portata di mano

• sudo fail2ban-client status — elenco di tutte le jail attive
• sudo fail2ban-client status sshd — stato dettagliato di una jail
• sudo fail2ban-client set sshd banip 1.2.3.4 — ban manuale di un IP
• sudo fail2ban-client set sshd unbanip 1.2.3.4 — rimozione manuale di un ban
• sudo fail2ban-client reload — ricarica la configurazione dopo una modifica
• sudo fail2ban-regex /var/log/auth.log /etc/fail2ban/filter.d/sshd.conf — test di un filtro
• sudo tail -f /var/log/fail2ban.log — monitoraggio dei ban in tempo reale

Conclusione

Fail2ban resta uno degli strumenti che meritano un posto fisso su ogni server Linux esposto a Internet: l’installazione richiede pochi minuti e già con una configurazione minima riduce in modo drastico il rumore generato da scanner SSH e probe automatizzati sui servizi web. La differenza reale, però, la fanno tre accorgimenti spesso trascurati: impostare un bantime ragionevole (il default di 10 minuti è quasi inutile), aggiungere sempre il proprio IP a ignoreip prima di abilitare le jail, e attivare la jail recidive per penalizzare chi insiste. Da soli, questi tre passaggi fanno la differenza tra un’installazione di default e una protezione che funziona davvero.

Fonte: Fail2ban on Linux: Protect Your Server from Brute-Force Attacks, LinuxBlog.io

Un malware che usa il calendario di Outlook come dead-drop

A metà luglio 2026 il team di Threat Intelligence di Group-IB ha pubblicato un’analisi tecnica su HOLLOWGRAPH, un impianto malevolo che ribalta un’assunzione su cui molte architetture di sicurezza si basano ancora: se il traffico esce verso graph.microsoft.com con un token valido, allora è “legittimo”. HOLLOWGRAPH dimostra che non è più così, e lo fa in un modo che vale la pena capire in dettaglio anche per chi non si occupa di threat intelligence, perché le tecniche di evasione che usa (abuso di API cloud fidate, DNS tunneling, cifratura ibrida) sono ormai pattern ricorrenti e replicabili.

Il malware è attribuito con alta confidenza al framework di backdoor modulare Cavern, già collegato ad attività di cyberspionaggio riconducibili all’area di influenza iraniana (con sovrapposizioni tecniche, seppur a bassa confidenza, con il gruppo Lyceum). La campagna osservata ha colpito in modo mirato organizzazioni israeliane: 12 sistemi compromessi identificati, di cui solo 3 attivamente in comunicazione con l’attaccante al momento dell’analisi — un profilo operativo selettivo, non opportunistico.

Il calendario come canale C2 bidirezionale

L’idea centrale di HOLLOWGRAPH è semplice da spiegare e proprio per questo efficace: invece di contattare un server C2 sotto il controllo dell’attaccante, il malware autentica una mailbox Microsoft 365 compromessa tramite Microsoft Graph API e usa il calendario di quella mailbox come dead-drop bidirezionale.

Il malware supporta solo due comandi:

• get — cerca eventi del calendario con oggetto Event ID: <taskID>, programmati per il 13 maggio 2050 (una data lontana nel futuro, scelta per non comparire mai nella vista “prossimi eventi” del proprietario della mailbox), scarica gli allegati e li decifra con la chiave privata RSA incorporata nel binario.
• send — cifra i dati da esfiltrare, crea un nuovo evento con la stessa data fittizia, carica i dati come allegati File{n}.txt e rinomina l’oggetto dell’evento con un tag riconoscibile dall’operatore (schema Boss{..}ID{..}).

Le chiamate Graph coinvolte sono quelle che qualunque applicazione legittima con permessi calendario userebbe normalmente:

GET /users/{mailbox}/calendarView
    ?startDateTime=2050-05-13T22:00:00
    &endDateTime=2050-05-13T23:00:00
    &$filter=contains(subject,'Event ID: ')

POST /users/{mailbox}/calendar/events
POST /users/{mailbox}/events/{event-id}/attachments
PATCH /users/{mailbox}/events/{event-id}

Cifratura ibrida e rinnovo credenziali via DNS tunneling

Ogni payload scambiato tramite il calendario è protetto con uno schema ibrido RSA-OAEP + AES-256-GCM, con due coppie di chiavi RSA distinte per le due direzioni (tasking in ingresso ed esfiltrazione in uscita), così che comandi e dati rubati restino crittograficamente indipendenti l’uno dall’altro anche in caso di compromissione parziale.

Il secondo canale, separato, serve a rinnovare le credenziali Microsoft Entra ID (tenant ID, client ID, client secret, indirizzo della mailbox) necessarie per autenticarsi a Graph. Qui HOLLOWGRAPH usa DNS tunneling su record AAAA verso un dominio controllato dall’attaccante (cloudlanecdn[.]com):

LENGTH query:  {random}.{taskID}.{fieldIndex}.p.cloudlanecdn.com
DATA   query:  {random}.{taskID}.{fieldIndex}.{offset}.q.cloudlanecdn.com

Perché elude i controlli tradizionali

Tre fattori rendono HOLLOWGRAPH difficile da individuare con gli strumenti perimetrali classici:

• Il traffico C2 viaggia interamente su infrastruttura Microsoft fidata (Graph API), quindi non compare in nessuna blocklist di reputazione IP o dominio.
• Non c’è mai una connessione diretta a un server dell’attaccante per il tasking o l’esfiltrazione: solo il canale di rinnovo credenziali tocca un dominio esterno, e lo fa via DNS, spesso meno ispezionato del traffico HTTPS.
• Gli eventi di calendario datati 2050 sono progettati per restare invisibili all’utente reale della mailbox, che normalmente non scorre trent’anni avanti nel proprio calendario.

Cosa può fare concretamente un team di sicurezza

Le raccomandazioni di Group-IB si traducono in azioni piuttosto precise per chi gestisce ambienti Microsoft 365 / Entra ID:

Caccia agli indicatori noti. Bloccare o mettere in allerta su richieste verso cloudlanecdn[.]com e cercare sugli endpoint il file logAzure.txt.

Monitoraggio Graph API e audit di calendario. Con Microsoft Sentinel o Defender Advanced Hunting è possibile costruire una query che cerchi eventi di calendario creati da un’applicazione (non da un utente interattivo) con oggetto sospetto o data anomala:

CloudAppEvents
| where Application == "Microsoft Exchange Online"
| where ActionType in ("New item created.", "New-CalendarItem")
| extend AppId = tostring(RawEventData.ClientAppId)
| where isnotempty(AppId)
| extend Subject = tostring(RawEventData.ItemSubject)
| where Subject matches regex @"Event ID: |Boss\{.*\}ID\{.*\}"
| project Timestamp, AccountDisplayName, AppId, Subject, RawEventData

DnsEvents
| where QueryType == "AAAA"
| extend RootDomain = strcat(split(Name, ".")[-2], ".", split(Name, ".")[-1])
| summarize QueryCount = count(), DistinctSubdomains = dcount(Name) by Computer, RootDomain
| where QueryCount > 200 and DistinctSubdomains > 100
| order by QueryCount desc

Conclusione

HOLLOWGRAPH non introduce tecniche crittografiche nuove né exploit in Microsoft Graph: il suo valore per l’attaccante sta tutto nel mimetismo. Per i team che gestiscono tenant Microsoft 365, il takeaway pratico non è “bloccare Graph API” — impossibile in qualunque organizzazione moderna — ma spostare parte della detection dal perimetro di rete alla telemetria applicativa: audit log di Exchange Online, anomalie nei permessi delle app registrate, e DNS analytics capace di guardare oltre i soliti record A/TXT. È un promemoria che vale la pena avere in mente ogni volta che si progetta un controllo di sicurezza basato solo sulla reputazione del dominio di destinazione.

Fonte: Group-IB Threat Intelligence, “HOLLOWGRAPH: Turning Microsoft 365 Calendars into Covert Command-and-Control Channels” e Petri IT Knowledgebase.

Un report internazionale ha acceso i riflettori su una possibile uscita di Nothing da diversi mercati, Giappone compreso. L’azienda britannica ha però smentito la notizia, pur confermando una riorganizzazione interna con tagli al personale.

Il report: addio a oltre 12 mercati

Secondo il sito indiano Digit.in, Nothing starebbe valutando il ritiro da più di 12 mercati, tra cui:

• Giappone
• alcune aree dell’Europa
• alcune aree del Medio Oriente

Il report parla anche di un taglio del personale che potrebbe coinvolgere circa il 40% dei dipendenti totali, con ridimensionamenti previsti pure nei team di ricerca e sviluppo di Cina e Londra.

Nothing: “È una fake news”

Di fronte a queste indiscrezioni, Nothing ha definito il report una fake news, negando qualsiasi piano di ritiro dai mercati citati. L’azienda ha però ammesso di essere impegnata in una riorganizzazione interna che comporta alcuni tagli al personale, senza confermare né la portata né i mercati coinvolti. Al momento non esiste alcun annuncio ufficiale relativo alla cessazione delle vendite in Giappone o altrove.

Vendite in rallentamento per gli ultimi modelli

Il report solleva dubbi anche sull’andamento commerciale dei prodotti più recenti. Secondo quanto riportato, il Nothing Phone (4b), lanciato questo mese, avrebbe venduto finora circa 20.000 unità, mentre la serie Nothing Phone (4a), uscita a marzo, si fermerebbe a circa 150.000 unità a livello globale, un dato che potrebbe però non includere l’India, il mercato di riferimento del brand, e quindi risultare più alto in realtà.

Per confronto, nel 2025 Nothing avrebbe spedito circa 2 milioni di dispositivi complessivi: se i numeri più recenti fossero confermati, indicherebbero un rallentamento della crescita rispetto all’anno precedente.

Il Giappone, mercato storicamente presidiato

Nothing ha sempre mostrato un approccio piuttosto aggressivo verso il mercato giapponese, tradizionalmente ostico per i brand non locali. Un’eventuale uscita rappresenterebbe quindi un cambio di strategia rilevante. Per ora, però, si tratta di un report smentito dall’azienda stessa: resta da vedere se nelle prossime settimane arriveranno comunicazioni ufficiali più dettagliate sulla riorganizzazione in corso e sulle reali intenzioni del brand nei mercati citati.