Digital Organizer Given Modern Upgrade


The media in this post is not displayed to visitors. To view it, please log in.

Remember digital organizers? They were like the lower-spec version of a PDA that couldn’t really do much more than store a few phone numbers and calendar entries. [TundraLegendZ] recently grabbed such a device from 1995 and set about transforming it into something a little more capable.

The device in question is a Casio Business Organizer Scheduling System SF-5580. The original guts have been replaced , though, with the power of a Raspberry Pi Zero. The single-board computer is hooked up to a small color LCD screen with a resolution of 480 x 800, which is tucked neatly into the spot where the original display lived. There’s also a Raspberry Pi Pico on board, which is charged with interfacing all 82 keys of the original keyboard. Power is courtesy of a 6000 mAh battery which should last a good few hours on a single charge. Hearing the buzzer hacked is fun, too. It’s more mobile phone ringtone than outright chiptune, but we still enjoyed listening to the results. Screencaps of the software show just what this setup can do with better hardware and a nicer screen than 1995 could provide. Future work is planned to give the build more capabilities with a HackRF upgrade.

We’re not convinced anyone ever got much use out of these diminutive digital organizers, but a great many were sold in the 1990s.


hackaday.com/2026/05/18/digita…

Prolog Via Pokémon


The media in this post is not displayed to visitors. To view it, please log in.

Like many people who read Hackaday, we are fairly fluent in a number of computer languages, but we have to admit it is easier to pick up languages that look like they group with things like Fortran. Sure, modern languages have all sorts of features, but the idea that you have a text file that executes in some order, variables, statements, and so on runs through most popular languages, but not all of them. Lisp and its variants are a different way of looking at things. And then there’s Prolog. [Alexander Petros] has an interesting way of explaining Prolog as a Pokémon game.

Prolog was “the next big thing” when AI meant expert systems. It is more of a specialized database where you define facts and rules that the computer can infer answers to queries. For example, if the facts say that Paul and Anna both have Mary as a parent, and a rule says that people with the same parent are siblings, then a query asking whether Paul and Anna are siblings will indicate that they are.

How does this relate to Pokémon? The classic card game pits teams of different characters against each other, and each has particular traits and moves. Prolog is well-suited to expressing situations like this, where there are many facts and rules about how they relate to one another.

In the example, characters like Bulbasaur and Squirtle are known to be pokemon. Each character can have one or more types (e.g., Bulbasaur is both a grass and poison type). Then, rules can define things like the types of moves and traits each character has. The way Prolog works, you can provide a variable as part of a query and get lists of matches, much like a database.

We didn’t see [Alex] mention the cut operator, and many people do not like to use it. There are probably other parts of Prolog left out, too, like backtracking. However, this is as good a place to start as any, and the example is exactly the sort of problem that Prolog is good at.

If you really prefer C, you can mix C and Prolog. We can’t imagine how it worked, but there was even a computer with a Prolog operating system.


hackaday.com/2026/05/18/prolog…

Cybersecurity & cyberwarfare ha ricondiviso questo.

The media in this post is not displayed to visitors. To view it, please go to the original post.

New, by me: CISA Admin Leaked AWS GovCloud Keys on GitHub

Until this past weekend, a contractor for the Cybersecurity & Infrastructure Security Agency (CISA) maintained a public GitHub repository that exposed credentials to several highly privileged AWS GovCloud accounts and a large number of internal CISA systems. Security experts said the public archive included files detailing how CISA builds, tests and deploys software internally, and that it represents one of the most egregious government data leaks in recent history.

krebsonsecurity.com/2026/05/ci…

Electroplating 3D Prints Without Requiring a Big Vat


The media in this post is not displayed to visitors. To view it, please log in.

Electroplating 3D prints is a good way to get a pretty nice coating on even a basic PLA part, but generally you’re expected to dunk the entire part into a big vat with electrolyte after coating it with the requisite conductive paint layer. This is great for small parts, like a ring you’d put on a finger, but gets rather silly when it’s a much larger part, such as the one in [Hendrik]’s recent video. Out of curiosity he tried to see whether rotating the part through a much smaller vat would still get you an even coating, or not.

Perhaps ironically this process required building a custom vat out of acrylic, as well as an entire rig to hold up the part and gently rotate it. This highlights the main disadvantage of this approach, in that unless you’re doing a small production run or otherwise get to re-use the rig a lot it’s a lot of extra effort.

That said, the rotation is controlled by an ESP32 and a stepper motor along with a requisite stepper driver, with the most exotic part being the whole custom PCB and enclosure, all of which can be used repeatedly. With all of that tested and confirmed working, the part to be plated was sanded, sprayed with conductive paint and hooked up to the rotating rig for an overnight run.

Following that the part’s new copper coating was polished before more layers of electroplating were applied to get the desired two different colors from different metals. Along the way no issues were found with this method of rotating electroplating, so if you regularly struggle with oversized parts to electroplate, this would seem to be a viable method.

youtube.com/embed/B2_lCMJ-_Uk?…


hackaday.com/2026/05/18/electr…

Cybersecurity & cyberwarfare ha ricondiviso questo.

Scuola, la scelta obbligata dei manuali digitali. Un risparmio apparente che penalizza la didattica

Il passaggio al libro digitale ha costi e impatti didattici. Oltre agli studi che dimostrano i vantaggi dello studio su carta, i device sono spesso anche una fonte di distrazione. Il tutto, mentre si vieta l’uso dei telefoni a scuola

editorialedomani.it/fatti/scuo…

@scuola

Unknown parent

mastodon - Collegamento all'originale

Comandante Virgola

@mrphelz @sposadelvento @macfranc @giacomo
amica prof di matematica: il libro costa dieci sacchi, ed è sempre lo stesso da anni (così i ragazzi possono comprarlo usato) : cambiano solo le pagine degli esercizi (la Matematica ancora non è cambiata 🤭) e basta solo sfogliare un po' per trovare gli stessi esercizi anche a pagine diverse. Certo i rappresentanti delle case editrici vengono tutti gli anni con nuove edizioni, più care ovviamente, ma le copie campione finiscono in biblioteca per le cessioni in uso gratuito ai non abbienti
in reply to YetoLake

The media in this post is not displayed to visitors. To view it, please go to the original post.

devi ringraziare @Godai71 che mi ha segnalato il tuo post 😅

A questo proposito, ricordati in futuro di aggiungere l'hashtag #mastoaiuto che è fatto espressamente per mastodon, ma che può essere utilizzato per tutti gli utenti mastodon che hanno bisogno di supporto.

Inoltre puoi utilizzare anche i gruppi tematici italiani come @fediverso@feddit.it (su feddit.it) o @fediverso@diggita.com (su diggita.com) o @forum (per gli utenti Friendica)

Se non sai cosa sono i gruppi: ⬇️

informapirata.it/2025/02/03/i-…


I Gruppi del Fediverso: un modo per incontrare altri utenti Mastodon, Friendica o Pixelfed in base ai loro interessi

Il Fediverso è un luogo fatto soprattutto di interazioni sociali ma rispetto ai social commerciali non è facilissimo trovare utenti che condividano i nostri stessi interessi. Ecco come giocarsi la carta dei “Gruppi”

informapirata.it/2025/02/03/i-…

#Calabria #Campania #comunità #Fediverso #Friendica #gruppi #Lemmy #Mastodon

informapirata.it/2025/02/03/i-…


Voltmeter Clock Has The Time Dialled In


The media in this post is not displayed to visitors. To view it, please log in.

You could make a clock with three hands spinning about nested central shafts. If you did that, we probably wouldn’t publish it on Hackaday unless you really found a way to make it interesting. Make a clock out of voltmeters, however, and that usually catches our eye. [lcamtuf] has done just that.

The heart of the build is an AVR128DB28 microcontroller, an 8-bit microcontroller that is still currently in production. It runs at 8MHz, and drives a series of three Baomain 65C5 voltmeters to display hours, minutes, and seconds. Each has a custom printed face with the correct number of 13 or 61 divisions as needed. The voltmeters are driven by a continuous stream of 1-bit pulses with a software-controlled duty cycle determining exactly how far the needle moves. Yes, it’s using simple pulse width modulation, coded by hand by [lcamtuf] to do the job. All the components are wrapped up in a beautiful wooden case, with delicately kerf-bent panels to create the attractive curved lines.

We’ve featured similar builds before, too. As it turns out, hackers just really love clocks and old-school dials. Video after the break, which is worth watching for the rollover behaviour alone.

player.vimeo.com/video/1192897…


hackaday.com/2026/05/18/voltme…

reshared this

Cybersecurity & cyberwarfare ha ricondiviso questo.

The media in this post is not displayed to visitors. To view it, please go to the original post.

CVE-2026-42897: vulnerabilità critica XSS in Exchange Server OWA — mitigazione di emergenza disponibile
#tech
spcnet.it/cve-2026-42897-vulne…
@informatica


CVE-2026-42897: vulnerabilità critica XSS in Exchange Server OWA — mitigazione di emergenza disponibile


Cos’è la vulnerabilità CVE-2026-42897


Il 14 maggio 2026 Microsoft ha divulgato pubblicamente una vulnerabilità critica nei propri server Exchange on-premises, tracciata come CVE-2026-42897. La falla, classificata come Cross-Site Scripting (XSS), risiede nel componente Outlook Web Access (OWA) e permette a un attaccante di eseguire codice JavaScript arbitrario nel browser della vittima senza richiedere alcuna interazione complessa: è sufficiente che l’utente apra una email appositamente confezionata direttamente dalla webmail.

La vulnerabilità è già sfruttata attivamente in the wild: la CISA (Cybersecurity and Infrastructure Security Agency) degli Stati Uniti l’ha aggiunta al proprio catalogo di vulnerabilità note e sfruttate (Known Exploited Vulnerabilities) con scadenza obbligatoria di remediation al 29 maggio 2026 per le agenzie federali americane. Il rischio per le organizzazioni private è ugualmente elevato.

Versioni di Exchange Server interessate


La vulnerabilità colpisce esclusivamente i server Exchange installati on-premises. In particolare:

  • Exchange Server 2016
  • Exchange Server 2019
  • Exchange Server Subscription Edition (SE)

Exchange Online non è interessato: le organizzazioni che utilizzano esclusivamente il servizio cloud Microsoft 365 non devono intraprendere alcuna azione. Il rischio è confinato a chi gestisce ancora infrastrutture Exchange on-premises, scenario ancora comune in contesti enterprise con requisiti di compliance, residenza del dato o integrazione con sistemi legacy.

Come funziona l’attacco


Il vettore di attacco è particolarmente insidioso perché non richiede configurazioni particolari lato vittima: l’attaccante invia una email con contenuto HTML appositamente costruito. Quando il destinatario apre il messaggio tramite OWA, il payload JavaScript viene eseguito nel contesto del browser dell’utente, con accesso alla sessione OWA attiva.

Le conseguenze possibili includono:

  • Furto del cookie di sessione e hijacking dell’account
  • Esecuzione di azioni per conto dell’utente (invio email, accesso a cartelle, lettura di allegati)
  • Lateral movement verso altri sistemi integrati con Exchange (es. Active Directory, SharePoint)
  • Esfiltrazione di dati sensibili contenuti nelle caselle di posta

In un ambiente enterprise, un attacco XSS riuscito contro OWA può essere il punto di ingresso per una compromissione ben più ampia, specialmente se la webmail è accessibile dall’esterno o da reti non completamente fidate.

Mitigazioni disponibili: come intervenire subito


Microsoft ha rilasciato mitigazioni di emergenza in attesa di una patch definitiva. Esistono due percorsi principali:

1. Exchange Emergency Mitigation Service (EM Service)


Il metodo preferito è affidarsi all’Exchange Emergency Mitigation Service, che applica automaticamente una configurazione di URL Rewrite sul server IIS per neutralizzare il vettore di attacco. Il servizio EM è abilitato per default nelle installazioni supportate di Exchange Server. Se non è stato disabilitato manualmente, la mitigazione potrebbe già essere attiva.

Per verificare lo stato della mitigazione, Microsoft raccomanda di eseguire il tool Exchange Health Checker:

# Scarica ed esegui Exchange Health Checker in una Exchange Management Shell elevata
. .\HealthChecker.ps1
Invoke-HealthChecker


Il report generato indica chiaramente se la mitigazione M2 per CVE-2026-42897 è stata applicata con successo.

2. Exchange On-Premises Mitigation Tool (EOMT) per ambienti air-gap


Per i server Exchange non connessi a internet o in ambienti con restrizioni di rete, Microsoft ha reso disponibile una procedura di mitigazione manuale tramite lo strumento EOMT (Exchange On-Premises Mitigation Tool):

# Download da: https://aka.ms/UnifiedEOMT
# Eseguire da una Exchange Management Shell con privilegi elevati

.\EOMTv2.ps1 -ExchangeVersion 2019


Dopo l’applicazione, è fondamentale verificare che le regole di URL Rewrite siano state create correttamente e che il servizio IIS sia stato riavviato.

Impatto sulle funzionalità di OWA dopo la mitigazione


L’applicazione della mitigazione introduce alcune limitazioni funzionali che gli amministratori devono comunicare agli utenti:

  • Immagini inline nelle email: potrebbero non essere visualizzate correttamente nel pannello di lettura di OWA. La soluzione alternativa è inviare le immagini come allegati o usare il client Outlook desktop.
  • Stampa del calendario da OWA: la funzione potrebbe non operare. Gli utenti possono utilizzare screenshot o Outlook desktop come workaround.
  • OWA Light (interfaccia legacy): già deprecata, potrebbe smettere di funzionare completamente. Non è una perdita significativa per la maggior parte delle organizzazioni.

Queste limitazioni sono accettabili rispetto al rischio rappresentato dalla vulnerabilità non mitigata.

Patch definitiva: cosa aspettarsi


Microsoft sta lavorando a un aggiornamento di sicurezza permanente. Un dettaglio importante per chi gestisce Exchange 2016 e 2019: le patch ufficiali saranno rilasciate solo per i clienti commerciali iscritti al programma ESU (Extended Security Update). Exchange 2016 ha raggiunto la fine del supporto mainstream nell’ottobre 2025, e Exchange 2019 raggiungerà la stessa condizione nell’ottobre 2025. Le organizzazioni che non hanno sottoscritto l’ESU si troveranno senza patch definitiva e dovranno affidarsi esclusivamente alla mitigazione di emergenza, con un rischio residuo crescente nel tempo.

Questo scenario rafforza l’urgenza di pianificare una migrazione verso Exchange Server SE o Exchange Online per chi è ancora su versioni precedenti.

Checklist di risposta per gli amministratori


Se gestisci un’infrastruttura Exchange on-premises, ecco le azioni da completare nell’ordine:

  1. Verifica la versione di Exchange in uso: apri la Exchange Management Shell e lancia Get-ExchangeServer | Select Name,AdminDisplayVersion
  2. Controlla se il servizio EM è attivo: Get-Service MSExchangeMitigation
  3. Esegui Exchange Health Checker per verificare l’applicazione della mitigazione M2
  4. Se l’EM Service è disabilitato o il server è air-gapped, applica EOMT manualmente
  5. Comunica agli utenti le limitazioni temporanee di OWA
  6. Monitora il blog ufficiale di Exchange (techcommunity.microsoft.com) per il rilascio della patch definitiva
  7. Valuta l’iscrizione al programma ESU se stai usando Exchange 2016 o 2019


Conclusione


CVE-2026-42897 è un esempio concreto di come le infrastrutture on-premises legacy rimangano vettori di attacco critici anche in ambienti enterprise ben gestiti. La buona notizia è che Microsoft ha reagito rapidamente con mitigazioni di emergenza e ha reso la verifica dello stato accessibile tramite strumenti già noti come Exchange Health Checker. La cattiva notizia è che chi non ha ancora pianificato l’uscita da Exchange 2016/2019 si trova in una posizione sempre più rischiosa, non solo per questa vulnerabilità ma per tutte quelle future che non riceveranno patch ufficiali.

Applicare la mitigazione adesso, verificarne l’efficacia e pianificare la migrazione al più presto sono le tre priorità concrete da portare all’attenzione del management tecnico questa settimana.


Fonte: Microsoft Warns Exchange Server Flaw Lets Attackers Execute Code via OWA Emails – Petri IT Knowledgebase | Microsoft Tech Community – Addressing Exchange Server May 2026 vulnerability


Cybersecurity & cyberwarfare ha ricondiviso questo.

The media in this post is not displayed to visitors. To view it, please go to the original post.

I colli di bottiglia nascosti nei microservizi in produzione: diagnostica e soluzioni pratiche
#tech
spcnet.it/i-colli-di-bottiglia…
@informatica


I colli di bottiglia nascosti nei microservizi in produzione: diagnostica e soluzioni pratiche


Il problema che non si vede finché è troppo tardi


C’è un pattern ricorrente nelle architetture a microservizi: tutto funziona in modo impeccabile per mesi, i test automatici sono verdi, il monitoraggio non mostra allarmi rilevanti, e il team è soddisfatto della solidità del sistema. Poi, spesso durante un picco di traffico ordinario o un evento previsto, qualcosa si inceppa. La latenza schizza verso l’alto, le code si allungano, i timeout si moltiplicano. Il problema non è stato causato dall’evento in sé — era già lì, nascosto sotto la superficie.

Questo articolo analizza i colli di bottiglia più insidiosi che affliggono i microservizi in produzione: quelli che non emergono nei test di carico standard e che vengono spesso diagnosticati troppo tardi.

1. Esaurimento del connection pool al database


Il problema del connection pool è forse il più comune e il meno visibile fino al momento critico. In un’architettura a microservizi, ogni istanza di ogni servizio apre e gestisce il proprio pool di connessioni al database. Il calcolo è semplice: se hai 10 microservizi con 5 istanze ciascuno e ogni istanza mantiene un pool di 10 connessioni, stai occupando 500 connessioni sul database. Scala orizzontalmente per gestire un picco di traffico, e quelle connessioni raddoppiano in pochi minuti.

La maggior parte dei database relazionali ha un limite fisico di connessioni concorrenti. PostgreSQL, per esempio, ha un default di 100 connessioni per il parametro max_connections. Superato il limite, nuove richieste di connessione falliscono con errori che spesso vengono nascosti da retry automatici, mascherando il problema effettivo fino a quando il sistema non collassa.

Come diagnosticarlo

-- PostgreSQL: connessioni attive per applicazione
SELECT application_name, count(*), state
FROM pg_stat_activity
GROUP BY application_name, state
ORDER BY count DESC;

-- Verifica il limite configurato
SHOW max_connections;


Come risolverlo


La soluzione più efficace per scenari ad alta concorrenza è l’uso di un connection pooler esterno come PgBouncer. PgBouncer opera in modalità transaction pooling: riusa le connessioni al database tra più client, riducendo drasticamente il numero di connessioni fisiche necessarie indipendentemente dal numero di istanze dei servizi.

# pgbouncer.ini — configurazione essenziale
[databases]
mydb = host=pg-primary port=5432 dbname=mydb

[pgbouncer]
pool_mode = transaction
max_client_conn = 1000
default_pool_size = 20
reserve_pool_size = 5


In .NET, assicurati che il pool di connessioni Npgsql sia configurato in modo coerente con i limiti imposti da PgBouncer:
// Connection string con pool sizing esplicito
"Host=pgbouncer-host;Database=mydb;Username=app;Password=...;
 Maximum Pool Size=10;Minimum Pool Size=2;Connection Idle Lifetime=300"


2. Thread pool starvation nelle chiamate sincrone


Il thread pool starvation è un problema particolarmente subdolo nelle applicazioni ASP.NET Core o nelle applicazioni Spring Boot che mischiano codice asincrono e sincrono. Quando un thread del pool viene bloccato in attesa di un’operazione I/O (una query al database, una chiamata HTTP a un servizio dipendente, una lettura da file), quel thread non è disponibile per elaborare nuove richieste. Se questo accade su scala, il thread pool si esaurisce e le nuove richieste rimangono in coda indefinitamente.

Il sintomo tipico è una degradazione progressiva delle performance durante i picchi: il throughput crolla, i tempi di risposta salgono in modo apparentemente inspiegabile, ma il database e la CPU risultano ancora sotto carico normale.

Pattern da evitare in .NET

// ❌ SBAGLIATO: blocca un thread del pool
public IActionResult GetData()
{
    var result = _service.GetDataAsync().Result; // .Result blocca il thread
    return Ok(result);
}

// ❌ Altrettanto problematico
public IActionResult GetData()
{
    var result = _service.GetDataAsync().GetAwaiter().GetResult();
    return Ok(result);
}

// ✅ CORRETTO: il thread viene restituito al pool durante l'attesa
public async Task<IActionResult> GetData()
{
    var result = await _service.GetDataAsync();
    return Ok(result);
}


Come diagnosticare il thread pool starvation


In .NET, puoi monitorare lo stato del thread pool a runtime:

ThreadPool.GetAvailableThreads(out int workerThreads, out int completionPortThreads);
ThreadPool.GetMaxThreads(out int maxWorker, out int maxCompletionPort);

// Se workerThreads è vicino a 0 con carico moderato, sei in starvation
Console.WriteLine($"Available: {workerThreads}/{maxWorker}");


Strumenti come dotnet-counters offrono un monitoraggio continuo in produzione senza impatto significativo:
dotnet-counters monitor --counters System.Runtime[threadpool-thread-count,threadpool-queue-length] -p <PID>


3. Cascading failures per dipendenze lente o non responsive


In un’architettura a microservizi, ogni servizio dipende da altri servizi. Questa catena di dipendenze è la fonte di uno dei problemi più difficili da gestire in produzione: il cascading failure. Se il Servizio B risponde lentamente, il Servizio A che lo chiama accumula richieste in attesa. I thread del pool di A vengono occupati in attesa di B, la latenza di A aumenta, il Servizio C che dipende da A inizia a ricevere timeout, e nel giro di pochi minuti l’intera catena collassa.

La soluzione consolidata è il pattern Circuit Breaker, che interrompe temporaneamente le chiamate verso un servizio degradato e restituisce immediatamente un errore (o una risposta di fallback), permettendo al sistema di degradare in modo controllato invece di collassare a cascata.

Implementazione con Polly in .NET

// Configurazione circuit breaker con Polly v8
var circuitBreakerPolicy = new ResiliencePipelineBuilder()
    .AddCircuitBreaker(new CircuitBreakerStrategyOptions
    {
        FailureRatio = 0.5,              // Apre dopo il 50% di fallimenti
        SamplingDuration = TimeSpan.FromSeconds(10),
        MinimumThroughput = 10,          // Minimo 10 richieste nel campione
        BreakDuration = TimeSpan.FromSeconds(30), // Attende 30s prima di riprovare
        OnOpened = args =>
        {
            _logger.LogWarning("Circuit breaker aperto per {Service}", serviceName);
            return default;
        }
    })
    .AddTimeout(TimeSpan.FromSeconds(3)) // Timeout esplicito su ogni chiamata
    .Build();

// Uso
var result = await circuitBreakerPolicy.ExecuteAsync(async token =>
    await _httpClient.GetFromJsonAsync<OrderDto>("/api/orders/123", token),
    cancellationToken);


4. Mancanza di backpressure nei flussi di messaggi


I sistemi basati su message broker (Kafka, RabbitMQ, Azure Service Bus) introducono un’ulteriore classe di colli di bottiglia: quando il ritmo di produzione dei messaggi supera la capacità di elaborazione dei consumer, le code crescono indefinitamente. Questo può portare a latenza crescente nell’elaborazione, out-of-memory degli broker, e scenari in cui messaggi vengono elaborati con ore o giorni di ritardo rispetto alla loro produzione.

La soluzione è implementare la backpressure: i consumer controllano attivamente il ritmo di ricezione in base alla propria capacità di elaborazione. In Kafka, questo si gestisce configurando correttamente il numero di partizioni, il numero di consumer nel consumer group, e i parametri max.poll.records e fetch.max.bytes.

// Esempio: consumer con controllo esplicito del concurrency via MassTransit
services.AddMassTransit(x =>
{
    x.UsingRabbitMq((ctx, cfg) =>
    {
        cfg.ReceiveEndpoint("orders-queue", e =>
        {
            e.PrefetchCount = 10;        // Non prelevare più di 10 messaggi alla volta
            e.ConcurrentMessageLimit = 5; // Elabora al massimo 5 messaggi in parallelo
            e.ConfigureConsumer<OrderConsumer>(ctx);
        });
    });
});


5. N+1 queries non rilevate in produzione


Il problema delle N+1 queries è ben noto in teoria ma sorprendentemente comune in produzione, soprattutto dopo refactoring o l’aggiunta di nuove funzionalità. L’ORM carica una lista di entità (1 query), poi per ogni entità carica lazy una relazione (N query). In sviluppo, con 10 elementi nel database, il problema è invisibile. In produzione, con 10.000 elementi, si traducono in 10.001 query per ogni richiesta.

// ❌ N+1: per ogni ordine viene eseguita una query separata per i prodotti
var orders = await _context.Orders.ToListAsync();
foreach (var order in orders)
{
    // Lazy load: ogni accesso a order.Products genera una nuova query
    var productNames = order.Products.Select(p => p.Name);
}

// ✅ Eager loading: una sola query con JOIN
var orders = await _context.Orders
    .Include(o => o.Products)
    .ToListAsync();


Per rilevare le N+1 in produzione, abilita il logging delle query EF Core in ambiente di staging con soglia di warning per query lente:
// Program.cs
builder.Services.AddDbContext<AppDbContext>(options =>
    options.UseSqlServer(connectionString)
           .LogTo(Console.WriteLine, LogLevel.Information)
           .EnableSensitiveDataLogging(false) // Mai in produzione
           .ConfigureWarnings(w => w.Throw(RelationalEventId.MultipleCollectionIncludeWarning)));


Monitoraggio proattivo: gli indicatori chiave


Rilevare questi problemi prima che diventino incidenti richiede un set di metriche mirate. Oltre alle metriche standard (CPU, RAM, latenza), monitora attivamente:

  • Connessioni attive al database per istanza e per servizio
  • Thread pool queue length: una coda crescente anche sotto carico moderato è un segnale di allarme
  • Circuit breaker state changes: ogni apertura di un circuit breaker è un evento da tracciare e analizzare
  • Message lag sulle code Kafka/RabbitMQ: il ritardo tra produzione e consumo
  • Slow queries: percentuale di query che superano una soglia prefissata (es. 500ms)

Strumenti come Prometheus + Grafana con i rispettivi exporter per PostgreSQL, RabbitMQ e .NET (via prometheus-net) permettono di costruire dashboard specifiche per questi pattern senza dipendere esclusivamente dai log.

Conclusione


I colli di bottiglia nascosti nei microservizi hanno una caratteristica comune: emergono sotto carico, in condizioni che i test standard non replicano fedelmente. Connection pool esauriti, thread in starvation, cascading failures, code in crescita incontrollata e N+1 queries sono problemi architetturali che richiedono attenzione già in fase di design, non solo quando il sistema è già in produzione e sotto stress.

Identificare preventivamente questi pattern, configurare correttamente i pool e i circuit breaker, e costruire un layer di osservabilità specifico per questi indicatori è l’investimento tecnico con il miglior ritorno in termini di stabilità per qualsiasi sistema distribuito di dimensioni non banali.


Fonte: The Hidden Bottlenecks That Break Microservices in Production – DZone


Cybersecurity & cyberwarfare ha ricondiviso questo.

📺 NCSC’s Ollie Whitehouse on surviving the "bugpocalypse"

risky.biz/video/ncscs-ollie-wh…

reshared this

Cybersecurity & cyberwarfare ha ricondiviso questo.

New: NYC Health and Hospitals says a data breach earlier this year affects 1.8 million people. Hackers stole personal info, medical data, government-issued IDs, Social Security numbers — and *biometrics*, including fingerprints and palm scans.

Already one of the largest healthcare breaches of 2026.

techcrunch.com/2026/05/18/nyc-…

reshared this

Cybersecurity & cyberwarfare ha ricondiviso questo.

#Grafana confirms #GitHub token breach cybercrime group claims the attack
securityaffairs.com/192347/cyb…
#securityaffairs #hacking

Long-Range Night Vision with an Infrared Laser


The media in this post is not displayed to visitors. To view it, please log in.

A 3D-printed telescope with an infrared laser on the side is pointed out the window of a building at night.

Most consumer-grade night vision devices are basically a standard camera without the usual filter to block near infrared (NIR) light, which are then paired with a NIR light source that’s not visible to the human eye. Unlike the passive night vision provided by a photomultiplier tube, these can’t resolve objects beyond the beam of their illumination source. On the other hand, if, as [Project 326] did, you use an infrared laser to illuminate the scene, you can still get a very long range out of these devices.

[Project 326]’s device consists of a previously-built reflecting telescope focusing a distant scene in to a webcam with the infrared filter removed, with the infrared laser illuminating the scene. Finding a suitable laser took some effort: the first option, a secondhand fiber-coupled industrial laser, was accidentally over-volted and destroyed during testing. The second had a fiber output which proved extremely hard to terminate, and a third laser couldn’t be collimated correctly. The final laser was a Vertical-Cavity Surface-Emitting Laser (VSEL) diode array element driven at about two Watts and collimated by a small lens.

This illumination setup is safe at a long range, but only at a long range. The laser was strong enough to burn cardboard at close range, but out at about 500 meters, the beam had spread until it was less than a hundredth of the standard safety limit. To make sure that nothing else would get in the way of the beam, it was shone down from the top of a tall building. Testing with a power meter also showed that at a long range, the beam was weaker than expected. It turned out that the wavelength used (940 nm) is attenuated by water vapor, to the point that up to 70% of the beam’s strength was lost before reaching the target. Despite this, and despite a rather linear beam profile, a somewhat dark image was still visible at 650 meters.

If you’re looking for a somewhat more versatile long-range night vision device, check out one based on a photomultiplier tube. Another approach is to use a very high-sensitivity camera.

youtube.com/embed/hhS44J2Wpo8?…

Thanks to [Keith Olson] for the tip!


hackaday.com/2026/05/18/long-r…

Cybersecurity & cyberwarfare ha ricondiviso questo.

The media in this post is not displayed to visitors. To view it, please go to the original post.

The media in this post is not displayed to visitors. To view it, please go to the original post.

UAT-8616: il gruppo d’élite sfrutta il sesto zero-day Cisco SD-WAN e prende di mira governi europei e asiatici
#CyberSecurity
insicurezzadigitale.com/uat-86…


UAT-8616: il gruppo d’élite sfrutta il sesto zero-day Cisco SD-WAN e prende di mira governi europei e asiatici


Un threat actor di altissimo livello, tracciato da Cisco Talos come UAT-8616, sta sfruttando attivamente una vulnerabilità critica nei controller Cisco Catalyst SD-WAN — la sesta zero-day sfruttata su questa piattaforma nel solo 2026. Con un CVSS di 10.0, la falla consente a un attaccante non autenticato di ottenere privilegi amministrativi completi su dispositivi SD-WAN esposti su internet, prendendo di mira settori governativi, diplomatici e della difesa in Europa e Asia Centrale.

La Sesta Zero-Day in Sei Mesi: CVE-2026-20182


Il 15 maggio 2026, la CISA (Cybersecurity and Infrastructure Security Agency) ha aggiunto CVE-2026-20182 al suo catalogo di vulnerabilità attivamente sfruttate (KEV — Known Exploited Vulnerabilities), imponendo alle agenzie federali civili statunitensi di applicare la patch entro il 17 maggio. La vulnerabilità risiede nel processo di handshake del controllo peering via protocollo DTLS sulla porta 12346 del Cisco Catalyst SD-WAN Controller e Manager.

In termini pratici, un attaccante remoto e non autenticato può autenticarsi come peer interno ad alto privilegio, bypassando completamente l’autenticazione e acquisendo controllo amministrativo sull’appliance bersaglio. Il punteggio massimo CVSS (10.0) riflette la semplicità di sfruttamento combinata alla gravità dell’impatto: nessuna credenziale, nessuna interazione utente richiesta.

Il Profilo di UAT-8616: Un Attore Sofisticato con Radici Profonde


Cisco Talos ha tracciato questa campagna sotto la denominazione UAT-8616, classificandolo con alta confidenza come un “highly sophisticated cyber threat actor”. Sebbene Talos non abbia ancora rilasciato un’attribuzione definitiva a uno stato-nazione specifico, diversi elementi indicativi emergono dall’analisi:

  • Longevità operativa: le prime tracce di attività malevola risalgono al 2023, almeno tre anni prima della divulgazione pubblica — segnale che il gruppo operava con una zero-day tenuta segreta per molto tempo.
  • Sovrapposizione con ORB network: l’infrastruttura di UAT-8616 si sovrappone a reti di relay operazionali (Operational Relay Boxes) precedentemente associate a operazioni di cyber-spionaggio di attori China-nexus, secondo quanto documentato da Mandiant/Google.
  • Target geopoliticamente selettivi: il profilo dei bersagli — governo, diplomazia, difesa in Europa e Asia Centrale — è coerente con operazioni di intelligence offensiva state-sponsored.
  • Connessione con endpoint Gamaredon (Aqua Blizzard): la CISA ha segnalato sovrapposizioni con endpoint già compromessi da Gamaredon, il gruppo russo legato all’FSB che storicamente prende di mira organizzazioni ucraine e dell’Europa orientale.


Anatomia dell’Attacco: Dal Bypass all’Esfiltrazione


Le tecniche post-compromissione documentate da Talos rivelano un playbook operativo sofisticato, progettato tanto per la persistenza quanto per l’evasione forense:

  • SSH key injection: aggiunta di chiavi SSH nei file authorized_keys per garantire accesso permanente anche dopo il reboot o il cambio di credenziali.
  • Escalation a root via CVE-2022-20775: sfruttamento di una tecnica di downgrade della versione software per scalare i privilegi fino a root.
  • Manipolazione NETCONF: modifica delle configurazioni di rete tramite il protocollo NETCONF per alterare il traffico o creare tunnel nascosti.
  • Creazione di account malevoli: creazione di utenti backdoor per accesso persistente.
  • Anti-forensics sistematico: cancellazione di log da syslog, wtmp, lastlog, bash_history e cli-history per coprire le tracce dell’intrusione.


Un Pattern Preoccupante: Sei Zero-Day in Sei Mesi


CVE-2026-20182 non è un caso isolato. Come documenta SecurityWeek, si tratta della sesta vulnerabilità zero-day sfruttata attivamente sulle piattaforme Cisco SD-WAN nel corso del 2026, un dato che solleva interrogativi profondi sulla sicurezza dell’infrastruttura di rete enterprise. Gli SD-WAN sono sistemi critici che gestiscono il traffico di rete tra sedi aziendali distribuite, data center e cloud — la loro compromissione offre all’attaccante una visibilità strategica sull’intera architettura di rete della vittima.

La tendenza è chiara: i dispositivi di rete edge — firewall, VPN concentrator, SD-WAN controller — sono diventati il principale vettore di accesso iniziale per i gruppi APT più sofisticati al mondo. A differenza degli endpoint tradizionali, questi dispositivi raramente eseguono soluzioni EDR e spesso hanno cicli di aggiornamento lenti nelle organizzazioni.

Implicazioni Geopolitiche e per i Difensori


Il targeting di settori governativi e della difesa in Europa e Asia Centrale suggerisce una campagna di cyber-spionaggio strategico. Le sovrapposizioni infrastrutturali con attori Russia-linked come Gamaredon/Aqua Blizzard complicano ulteriormente l’attribuzione, un fenomeno sempre più comune nelle operazioni moderne dove la condivisione di infrastrutture (ORB network) oscura deliberatamente le responsabilità.

Per i team di sicurezza, le priorità immediate sono chiare:

  • Patching urgente: applicare immediatamente le patch Cisco per CVE-2026-20182 su tutti i Catalyst SD-WAN Controller e Manager esposti.
  • Audit delle authorized_keys: verificare l’integrità dei file SSH authorized_keys su tutti i sistemi SD-WAN.
  • Revisione account: identificare e rimuovere eventuali account non autorizzati creati sui sistemi.
  • Log integrity check: data la tendenza del gruppo a cancellare i log, implementare forwarding immediato su SIEM centralizzato.
  • Network segmentation review: limitare l’accesso amministrativo ai controller SD-WAN tramite reti di gestione dedicate e isolate.


CVE e Riferimenti Tecnici

CVE-2026-20182 — Cisco Catalyst SD-WAN Controller / Manager
CVSS Score: 10.0 (Critico)
Tipo: Authentication Bypass
Vettore: DTLS porta 12346 (handshake peering)
Impatto: Accesso amministrativo non autenticato

CVE correlati campagna UAT-8616:
- CVE-2026-20127 (zero-day precedente, sfruttato da febbraio 2026)
- CVE-2022-20775 (privilege escalation, usato per escalation a root)

Indicatori di Compromissione (comportamentali):
- SSH keys non autorizzate in authorized_keys
- Account di sistema inattesi
- Assenza di voci nei log syslog/wtmp/lastlog (log wiping)
- Configurazioni NETCONF alterate
- Traffico anomalo su porta DTLS 12346

Fonti: Cisco Talos, CISA KEV, SecurityWeek, Help Net Security, Tenable, Dark Reading

Cybersecurity & cyberwarfare ha ricondiviso questo.

The media in this post is not displayed to visitors. To view it, please go to the original post.

The media in this post is not displayed to visitors. To view it, please go to the original post.

Mini Shai-Hulud: TeamPCP compromette 160+ pacchetti npm e PyPI in un supply chain attack che ha colpito TanStack, Mistral AI e OpenAI
#CyberSecurity
insicurezzadigitale.com/mini-s…


Mini Shai-Hulud: TeamPCP compromette 160+ pacchetti npm e PyPI in un supply chain attack che ha colpito TanStack, Mistral AI e OpenAI


Tra il 11 e il 14 maggio 2026, un attore di minacce tracciato come TeamPCP ha sferrato uno dei supply chain attack più sofisticati mai documentati nell’ecosistema open source: oltre 160 pacchetti npm e 2 pacchetti PyPI compromessi, tra cui componenti del popolare framework TanStack, librerie di Mistral AI e UiPath, e il fondamentale pacchetto node-ipc con 822.000 download settimanali. L’operazione, ribattezzata “Mini Shai-Hulud” dai ricercatori di Wiz, ha colpito le pipeline di sviluppo di migliaia di organizzazioni — inclusi due dipendenti di OpenAI — e ha dimostrato come un singolo punto debole nelle GitHub Actions possa trasformarsi in una bomba a orologeria lungo tutta la catena del software.

L’innesco: tre vulnerabilità GitHub Actions in sequenza


Il vettore iniziale dell’attacco non è stato una vulnerabilità nei pacchetti stessi, ma nell’infrastruttura CI/CD che li gestisce. TeamPCP ha sfruttato una catena di tre vulnerabilità nelle GitHub Actions, secondo quanto ricostruito dai ricercatori di Wiz e Orca Security. L’attaccante ha creato un fork del repository TanStack/router, ha aperto una pull request che ha innescato un workflow pull_request_target — una tipologia di workflow che, a differenza di pull_request, viene eseguita con i permessi completi del repository originale anche per PR da fork esterni — e ha avvelenato la cache pnpm di GitHub Actions con un payload malevolo.

Una volta avvelenata la cache, il malware si è auto-propagato: ogni volta che il workflow legittimo veniva eseguito, invece di scaricare le dipendenze originali recuperava le versioni compromesse dalla cache infetta. Questo meccanismo di auto-propagazione — il “worm” di Mini Shai-Hulud — ha permesso la compromissione a cascata di tutti i namespace associati al progetto.

I 373 pacchetti compromessi: la portata dell’operazione


La scala dell’attacco è stata eccezionale. In totale, 373 versioni malevole sono state pubblicate su npm, distribuite su 169 nomi di pacchetti distinti. I namespace colpiti includono @tanstack (83 voci: router, start, devtools e adapter packages), @uipath (66 voci), @squawk (87 voci), @mistralai, @tallyui, @beproduct e numerosi pacchetti non con scope. Su PyPI, i pacchetti colpiti sono stati guardrails-ai 0.10.1 e mistralai 2.4.6.

La natura cross-namespace dell’attacco è significativa: le organizzazioni che utilizzavano librerie di vendor diversi (UiPath per l’automazione, Mistral AI per i modelli LLM, TanStack per il routing frontend) erano tutte vulnerabili nello stesso intervallo temporale, senza che esistesse un singolo punto di allerta evidente.

node-ipc: il payload più insidioso


Parallelamente alla compromissione via GitHub Actions, TeamPCP ha eseguito un attacco separato ma correlato contro node-ipc, un pacchetto fondamentale di Node.js per la comunicazione inter-processo con oltre 10 milioni di download settimanali. Tre versioni malevole (9.1.6, 9.2.3 e 12.0.1) sono state pubblicate il 14 maggio 2026 tramite un account maintainer compromesso attraverso una tecnica di account takeover mirata.

L’attaccante aveva re-registrato il dominio atlantis-software.net — scaduto il 10 gennaio 2025 — il 7 maggio 2026 tramite Namecheap, e aveva utilizzato la procedura standard di reset password di npm per ottenere i permessi di pubblicazione senza che il maintainer originale venisse avvisato. Le versioni malevole contenevano un payload da 80 KB, fortemente offuscato, che veniva iniettato come IIFE (Immediately Invoked Function Expression) alla fine del file node-ipc.cjs.

Cosa rubava il malware: 90+ categorie di credenziali


Una volta caricato tramite require('node-ipc'), il payload eseguiva silenziosamente un harvesting massiccio di credenziali: chiavi AWS, Azure e GCP, chiavi SSH private, token Kubernetes, configurazioni GitHub CLI, impostazioni di Claude AI e dell’IDE Kiro, stati Terraform, password di database, cronologia della shell e molto altro — oltre 90 categorie di segreti in totale. I dati venivano compressi in un archivio gzip e esfiltrati verso un server controllato dagli attaccanti che si mascherava da infrastruttura Azure.

Prima di procedere, il payload effettuava un fingerprint SHA-256 dell’ambiente, confrontandolo con un hash hardcoded assemblato da otto frammenti offuscati presenti nel codice — presumibilmente per evitare l’esecuzione in sandbox di analisi. Le versioni malevole sono rimaste attive sul registry per circa due ore prima del rilevamento e della rimozione da parte di npm. Qualsiasi progetto che abbia eseguito npm install o aggiornato automaticamente le dipendenze in quella finestra temporale deve essere considerato potenzialmente compromesso.

OpenAI e Mistral AI tra le vittime: le implicazioni sistemiche


OpenAI ha confermato che due dispositivi di dipendenti nel suo ambiente aziendale sono stati compromessi nell’attacco. L’azienda ha ingaggiato una società di incident response, ha ruotato i certificati di firma del codice per le applicazioni macOS e ha dichiarato di non aver trovato evidenze di accesso a dati utente, sistemi di produzione o proprietà intellettuale. Mistral AI ha visto le sue librerie ufficiali compromise, sollevando preoccupazioni immediate tra gli sviluppatori che le utilizzano per integrare capacità AI nei loro applicativi.

Il fatto che TeamPCP abbia preso di mira specificamente pacchetti di aziende AI leader — Mistral AI, e indirettamente OpenAI attraverso i suoi sviluppatori — non è casuale: i developer che lavorano con questi strumenti hanno tipicamente accesso a chiavi API di alto valore, ambienti cloud critici e codice sorgente sensibile. I repo di Mistral AI rubati sono stati successivamente messi in vendita da TeamPCP, confermando la doppia finalità dell’operazione: furto di credenziali e esfiltrazione di proprietà intellettuale.

Difendersi dalla nuova generazione di supply chain attack


L’attacco di Mini Shai-Hulud rappresenta una nuova classe di minaccia per la quale molte organizzazioni non sono ancora attrezzate. La compromissione non avviene attraverso vulnerabilità nel codice stesso, ma nell’infrastruttura di distribuzione. Alcune misure pratiche per i difensori includono il pinning delle versioni esatte dei pacchetti (evitando range semver come ^1.2.3 o ~1.2.3), l’utilizzo di un lockfile verificato e mantenuto nel controllo versione, l’auditing regolare delle dipendenze con strumenti come npm audit o Snyk, e la verifica dell’integrità dei pacchetti tramite hash SHA-512 dove disponibili.

Sul fronte CI/CD, è fondamentale limitare i permessi dei workflow GitHub Actions, evitare l’uso di pull_request_target con checkout del codice della PR, e implementare cache poisoning prevention attraverso la verifica dell’integrità della cache. Le organizzazioni che hanno eseguito build tra il 11 e il 14 maggio 2026 utilizzando i namespace colpiti dovrebbero effettuare una revisione completa dei secret esposti.

Indicatori di Compromissione (IoC)

# Mini Shai-Hulud / TeamPCP Supply Chain Attack - Maggio 2026
# Fonti: Wiz, Orca Security, Snyk, StepSecurity

# Pacchetti npm malevoli (esempi principali)
node-ipc: 9.1.6, 9.2.3, 12.0.1
@tanstack/router: versioni pubblicate 11-14 maggio 2026
@mistralai/mistralai: 2.4.6 (correlato)

# Pacchetti PyPI malevoli
guardrails-ai==0.10.1
mistralai==2.4.6

# Account maintainer compromesso (node-ipc)
npm user: atiertant (a.tiertant@atlantis-software.net)
Dominio re-registrato: atlantis-software.net (7 maggio 2026)

# Tecniche MITRE ATT&CK
T1195.001 - Supply Chain Compromise: Compromise Software Dependencies
T1059.007 - Command and Scripting Interpreter: JavaScript
T1552.001 - Unsecured Credentials: Credentials in Files
T1041     - Exfiltration Over C2 Channel (verso infrastruttura Azure-like)

# Indicatori comportamentali
- Processi Node.js che effettuano richieste HTTP inattese post-installazione
- Archivi gzip creati in directory temporanee durante npm install
- Chiamate a endpoint Azure non riconosciuti da processi build

# Verifica hash (node-ipc versioni legittime)
SHA-256 v9.1.5 legittima: verificare su https://registry.npmjs.org/node-ipc/9.1.5

Fonti: Wiz Blog, Orca Security, The Hacker News, BleepingComputer, OpenAI Blog

How To Make Steel That Breathes


The media in this post is not displayed to visitors. To view it, please log in.

There are plenty of porous materials out there that we’re all readily familiar with. Fabrics and wood are great examples, allowing liquids or gases to pass through to a certain degree—a property which is useful or problematic depending on the application.

Metals, however, are not something we would readily consider to be porous. They are solid, unyielding, and impermeable. However, with the right techniques, it is possible to produce so-called “breathable” steel, which has particularly interesting applications in the molding industry.

Breathe Into Me And Make Me Real


Imagine you’re making tooling for an injection molding operation. You’re using steel, of course, because you need a hard, resilient material that can deal with the high temperatures and pressures involved. It’s tough, and readily able to be machined into the desired geometry for your application. Of course, it doesn’t let liquid or gas pass, since it’s a solid impermeable material. This means that when you inject your mold full of hot plastic, you need to find somewhere for the air inside to go. Otherwise, the gas in the mold will end up dissolved in the molten plastic, causing voids, surface imperfections, and other irregularities. Chasing away gas porosity defects in finished parts is one of the major jobs of casting engineers the world over, an endless battle against the forces of heat transfer and fluid mechanics.

Traditionally, this is deal by designing a mold with exhaust ports or vacuum hookups to allow the air to vent out as needed. This takes a great deal of work to get right, particularly when it comes to getting your defect rates as low as possible in mass production. If your gas can’t vent fast enough, or if there are areas where it gets trapped, you end up with defects, and you have to go back to the drawing board.

Breathable mold steel attempts to solve this problem by venting gas through the tooling itself. It allows the creation of a steel mold that is full of tiny little pores that allow air to pass through, while still acting largely impermeable to the molten plastic being molded.

View this post on Instagram


Breathable mold steel is quite something to behold, behaving quite unlike a normal steel part in this regard.

As you might imagine, it’s quite difficult to make a steel mold with complex geometry that also has lots of tiny contiguous holes that allow gases to pass through. It is possible, however, by using some tricky additive manufacturing techniques.
By mixing a foaming agent into powder metal for selective laser melting (SLM) printing, it’s possible to generate interconnected micrometer-scale pores in steel that allow it to ‘breathe’. The pores are generated by the gas released during the heat-based decomposition of the foaming agent. Credit: research paper
As outlined in one research paper, it’s possible to produce breathable steel via selective laser melting (SLM) 3D printing techniques. This involves using a high-powered laser to fuse metal powder together, layer by layer, to produce a final part. Combining a foaming agent with the metal powder enables the creation of 3D-printed metal parts with incredibly fine interconnected pores.

The pores need to be particularly small, on the order of 80 micrometers or less, such that they allow gas in the mold to pass freely while blocking the flow of the larger polymer molecules of the injected plastic.

Chromium nitride is one foaming agent typically used, for the fact that the Cr and N released during its decomposition both lend beneficial properties to the steel of the finished product. The foaming agent is mixed in with the steel powder, and melts along with it as the part is being produced. The breakdown of the foaming agent releases gas bubbles which creates pores in the steel part as it is produced in a relatively predictable manner.
Microscope images of breathable steel samples produced with 3% CrNx and 5% CrNx foaming agent, respectively. Credit: research paper
The level of porosity can be controlled by the amount of foaming agent mixed in to the steel powder, as well as the laser settings. Lower melt pool temperatures caused by faster scanning speeds or lower laser powers tend to favor more porous structures, due to the fluid mechanics involved and how the cooler liquid steel flows into existing pores.

There have been earlier attempts to vent molds with special breathable steel inserts in the past. These consist of premade rectangular inserts or round bars which have been made with so-called “ventilated steel” like PM-35. This material is made by sintering steel powders together in such a way to create a porosity of 20-30%. However, this process isn’t always great for advanced geometry that one might find in a injection mold. Thus, the creation of breathable rods and bars that can be used as an insert in a larger mold, acting as a localized vent. It’s a useful technique, but comes with more constraints on mold and part geometry than being able to simply create the whole mold itself out of breathable steel.
Micro-CT images of a breathable steel sample. Credit: research paper
There are other powder metal techniques that allow the production of more complex vented parts, but they can be expensive and difficult to execute well down to smaller pore sizes, especially compared to the simplicity of SLM printing with an additional foaming agent. The 3D-printing based process has also proven to have more admirable mechanical properties compared to products like PM-35 steel in some cases, with impressive compressive strength as well as hardness and corrosion resistance.

Breathable steel is probably not something you’ll come across in your everyday life unless you happen to work in particular manufacturing fields. Still, if you have the expensive 3D printing hardware on hand to work with metal powders, and you really want to make a complex metal part that’s also porous, this is a great way to go. You could probably use it to make some very weird magic tricks at the very least. Ultimately, it just goes to show that modern material processing techniques can upend everything we think we know about a common material like steel. It’s amazing what can be done!


hackaday.com/2026/05/18/how-to…

The media in this post is not displayed to visitors. To view it, please log in.

Mini Shai-Hulud: TeamPCP compromette 160+ pacchetti npm e PyPI in un supply chain attack che ha colpito TanStack, Mistral AI e OpenAI


@Informatica (Italy e non Italy)
Tra il 11 e il 14 maggio 2026, il gruppo TeamPCP ha compromesso oltre 160 pacchetti npm e 2 PyPI in un supply chain attack di nuova generazione


Mini Shai-Hulud: TeamPCP compromette 160+ pacchetti npm e PyPI in un supply chain attack che ha colpito TanStack, Mistral AI e OpenAI


Tra il 11 e il 14 maggio 2026, un attore di minacce tracciato come TeamPCP ha sferrato uno dei supply chain attack più sofisticati mai documentati nell’ecosistema open source: oltre 160 pacchetti npm e 2 pacchetti PyPI compromessi, tra cui componenti del popolare framework TanStack, librerie di Mistral AI e UiPath, e il fondamentale pacchetto node-ipc con 822.000 download settimanali. L’operazione, ribattezzata “Mini Shai-Hulud” dai ricercatori di Wiz, ha colpito le pipeline di sviluppo di migliaia di organizzazioni — inclusi due dipendenti di OpenAI — e ha dimostrato come un singolo punto debole nelle GitHub Actions possa trasformarsi in una bomba a orologeria lungo tutta la catena del software.

L’innesco: tre vulnerabilità GitHub Actions in sequenza


Il vettore iniziale dell’attacco non è stato una vulnerabilità nei pacchetti stessi, ma nell’infrastruttura CI/CD che li gestisce. TeamPCP ha sfruttato una catena di tre vulnerabilità nelle GitHub Actions, secondo quanto ricostruito dai ricercatori di Wiz e Orca Security. L’attaccante ha creato un fork del repository TanStack/router, ha aperto una pull request che ha innescato un workflow pull_request_target — una tipologia di workflow che, a differenza di pull_request, viene eseguita con i permessi completi del repository originale anche per PR da fork esterni — e ha avvelenato la cache pnpm di GitHub Actions con un payload malevolo.

Una volta avvelenata la cache, il malware si è auto-propagato: ogni volta che il workflow legittimo veniva eseguito, invece di scaricare le dipendenze originali recuperava le versioni compromesse dalla cache infetta. Questo meccanismo di auto-propagazione — il “worm” di Mini Shai-Hulud — ha permesso la compromissione a cascata di tutti i namespace associati al progetto.

I 373 pacchetti compromessi: la portata dell’operazione


La scala dell’attacco è stata eccezionale. In totale, 373 versioni malevole sono state pubblicate su npm, distribuite su 169 nomi di pacchetti distinti. I namespace colpiti includono @tanstack (83 voci: router, start, devtools e adapter packages), @uipath (66 voci), @squawk (87 voci), @mistralai, @tallyui, @beproduct e numerosi pacchetti non con scope. Su PyPI, i pacchetti colpiti sono stati guardrails-ai 0.10.1 e mistralai 2.4.6.

La natura cross-namespace dell’attacco è significativa: le organizzazioni che utilizzavano librerie di vendor diversi (UiPath per l’automazione, Mistral AI per i modelli LLM, TanStack per il routing frontend) erano tutte vulnerabili nello stesso intervallo temporale, senza che esistesse un singolo punto di allerta evidente.

node-ipc: il payload più insidioso


Parallelamente alla compromissione via GitHub Actions, TeamPCP ha eseguito un attacco separato ma correlato contro node-ipc, un pacchetto fondamentale di Node.js per la comunicazione inter-processo con oltre 10 milioni di download settimanali. Tre versioni malevole (9.1.6, 9.2.3 e 12.0.1) sono state pubblicate il 14 maggio 2026 tramite un account maintainer compromesso attraverso una tecnica di account takeover mirata.

L’attaccante aveva re-registrato il dominio atlantis-software.net — scaduto il 10 gennaio 2025 — il 7 maggio 2026 tramite Namecheap, e aveva utilizzato la procedura standard di reset password di npm per ottenere i permessi di pubblicazione senza che il maintainer originale venisse avvisato. Le versioni malevole contenevano un payload da 80 KB, fortemente offuscato, che veniva iniettato come IIFE (Immediately Invoked Function Expression) alla fine del file node-ipc.cjs.

Cosa rubava il malware: 90+ categorie di credenziali


Una volta caricato tramite require('node-ipc'), il payload eseguiva silenziosamente un harvesting massiccio di credenziali: chiavi AWS, Azure e GCP, chiavi SSH private, token Kubernetes, configurazioni GitHub CLI, impostazioni di Claude AI e dell’IDE Kiro, stati Terraform, password di database, cronologia della shell e molto altro — oltre 90 categorie di segreti in totale. I dati venivano compressi in un archivio gzip e esfiltrati verso un server controllato dagli attaccanti che si mascherava da infrastruttura Azure.

Prima di procedere, il payload effettuava un fingerprint SHA-256 dell’ambiente, confrontandolo con un hash hardcoded assemblato da otto frammenti offuscati presenti nel codice — presumibilmente per evitare l’esecuzione in sandbox di analisi. Le versioni malevole sono rimaste attive sul registry per circa due ore prima del rilevamento e della rimozione da parte di npm. Qualsiasi progetto che abbia eseguito npm install o aggiornato automaticamente le dipendenze in quella finestra temporale deve essere considerato potenzialmente compromesso.

OpenAI e Mistral AI tra le vittime: le implicazioni sistemiche


OpenAI ha confermato che due dispositivi di dipendenti nel suo ambiente aziendale sono stati compromessi nell’attacco. L’azienda ha ingaggiato una società di incident response, ha ruotato i certificati di firma del codice per le applicazioni macOS e ha dichiarato di non aver trovato evidenze di accesso a dati utente, sistemi di produzione o proprietà intellettuale. Mistral AI ha visto le sue librerie ufficiali compromise, sollevando preoccupazioni immediate tra gli sviluppatori che le utilizzano per integrare capacità AI nei loro applicativi.

Il fatto che TeamPCP abbia preso di mira specificamente pacchetti di aziende AI leader — Mistral AI, e indirettamente OpenAI attraverso i suoi sviluppatori — non è casuale: i developer che lavorano con questi strumenti hanno tipicamente accesso a chiavi API di alto valore, ambienti cloud critici e codice sorgente sensibile. I repo di Mistral AI rubati sono stati successivamente messi in vendita da TeamPCP, confermando la doppia finalità dell’operazione: furto di credenziali e esfiltrazione di proprietà intellettuale.

Difendersi dalla nuova generazione di supply chain attack


L’attacco di Mini Shai-Hulud rappresenta una nuova classe di minaccia per la quale molte organizzazioni non sono ancora attrezzate. La compromissione non avviene attraverso vulnerabilità nel codice stesso, ma nell’infrastruttura di distribuzione. Alcune misure pratiche per i difensori includono il pinning delle versioni esatte dei pacchetti (evitando range semver come ^1.2.3 o ~1.2.3), l’utilizzo di un lockfile verificato e mantenuto nel controllo versione, l’auditing regolare delle dipendenze con strumenti come npm audit o Snyk, e la verifica dell’integrità dei pacchetti tramite hash SHA-512 dove disponibili.

Sul fronte CI/CD, è fondamentale limitare i permessi dei workflow GitHub Actions, evitare l’uso di pull_request_target con checkout del codice della PR, e implementare cache poisoning prevention attraverso la verifica dell’integrità della cache. Le organizzazioni che hanno eseguito build tra il 11 e il 14 maggio 2026 utilizzando i namespace colpiti dovrebbero effettuare una revisione completa dei secret esposti.

Indicatori di Compromissione (IoC)

# Mini Shai-Hulud / TeamPCP Supply Chain Attack - Maggio 2026
# Fonti: Wiz, Orca Security, Snyk, StepSecurity

# Pacchetti npm malevoli (esempi principali)
node-ipc: 9.1.6, 9.2.3, 12.0.1
@tanstack/router: versioni pubblicate 11-14 maggio 2026
@mistralai/mistralai: 2.4.6 (correlato)

# Pacchetti PyPI malevoli
guardrails-ai==0.10.1
mistralai==2.4.6

# Account maintainer compromesso (node-ipc)
npm user: atiertant (a.tiertant@atlantis-software.net)
Dominio re-registrato: atlantis-software.net (7 maggio 2026)

# Tecniche MITRE ATT&CK
T1195.001 - Supply Chain Compromise: Compromise Software Dependencies
T1059.007 - Command and Scripting Interpreter: JavaScript
T1552.001 - Unsecured Credentials: Credentials in Files
T1041     - Exfiltration Over C2 Channel (verso infrastruttura Azure-like)

# Indicatori comportamentali
- Processi Node.js che effettuano richieste HTTP inattese post-installazione
- Archivi gzip creati in directory temporanee durante npm install
- Chiamate a endpoint Azure non riconosciuti da processi build

# Verifica hash (node-ipc versioni legittime)
SHA-256 v9.1.5 legittima: verificare su https://registry.npmjs.org/node-ipc/9.1.5

Fonti: Wiz Blog, Orca Security, The Hacker News, BleepingComputer, OpenAI Blog

The media in this post is not displayed to visitors. To view it, please log in.

UAT-8616: il gruppo d’élite sfrutta il sesto zero-day Cisco SD-WAN e prende di mira governi europei e asiatici


@Informatica (Italy e non Italy)
Un threat actor altamente sofisticato, UAT-8616, sfrutta CVE-2026-20182 — vulnerabilità critica CVSS 10.0 nel Cisco Catalyst SD-WAN — per compromettere organizzazioni governative, diplomatiche e


UAT-8616: il gruppo d’élite sfrutta il sesto zero-day Cisco SD-WAN e prende di mira governi europei e asiatici


Un threat actor di altissimo livello, tracciato da Cisco Talos come UAT-8616, sta sfruttando attivamente una vulnerabilità critica nei controller Cisco Catalyst SD-WAN — la sesta zero-day sfruttata su questa piattaforma nel solo 2026. Con un CVSS di 10.0, la falla consente a un attaccante non autenticato di ottenere privilegi amministrativi completi su dispositivi SD-WAN esposti su internet, prendendo di mira settori governativi, diplomatici e della difesa in Europa e Asia Centrale.

La Sesta Zero-Day in Sei Mesi: CVE-2026-20182


Il 15 maggio 2026, la CISA (Cybersecurity and Infrastructure Security Agency) ha aggiunto CVE-2026-20182 al suo catalogo di vulnerabilità attivamente sfruttate (KEV — Known Exploited Vulnerabilities), imponendo alle agenzie federali civili statunitensi di applicare la patch entro il 17 maggio. La vulnerabilità risiede nel processo di handshake del controllo peering via protocollo DTLS sulla porta 12346 del Cisco Catalyst SD-WAN Controller e Manager.

In termini pratici, un attaccante remoto e non autenticato può autenticarsi come peer interno ad alto privilegio, bypassando completamente l’autenticazione e acquisendo controllo amministrativo sull’appliance bersaglio. Il punteggio massimo CVSS (10.0) riflette la semplicità di sfruttamento combinata alla gravità dell’impatto: nessuna credenziale, nessuna interazione utente richiesta.

Il Profilo di UAT-8616: Un Attore Sofisticato con Radici Profonde


Cisco Talos ha tracciato questa campagna sotto la denominazione UAT-8616, classificandolo con alta confidenza come un “highly sophisticated cyber threat actor”. Sebbene Talos non abbia ancora rilasciato un’attribuzione definitiva a uno stato-nazione specifico, diversi elementi indicativi emergono dall’analisi:

  • Longevità operativa: le prime tracce di attività malevola risalgono al 2023, almeno tre anni prima della divulgazione pubblica — segnale che il gruppo operava con una zero-day tenuta segreta per molto tempo.
  • Sovrapposizione con ORB network: l’infrastruttura di UAT-8616 si sovrappone a reti di relay operazionali (Operational Relay Boxes) precedentemente associate a operazioni di cyber-spionaggio di attori China-nexus, secondo quanto documentato da Mandiant/Google.
  • Target geopoliticamente selettivi: il profilo dei bersagli — governo, diplomazia, difesa in Europa e Asia Centrale — è coerente con operazioni di intelligence offensiva state-sponsored.
  • Connessione con endpoint Gamaredon (Aqua Blizzard): la CISA ha segnalato sovrapposizioni con endpoint già compromessi da Gamaredon, il gruppo russo legato all’FSB che storicamente prende di mira organizzazioni ucraine e dell’Europa orientale.


Anatomia dell’Attacco: Dal Bypass all’Esfiltrazione


Le tecniche post-compromissione documentate da Talos rivelano un playbook operativo sofisticato, progettato tanto per la persistenza quanto per l’evasione forense:

  • SSH key injection: aggiunta di chiavi SSH nei file authorized_keys per garantire accesso permanente anche dopo il reboot o il cambio di credenziali.
  • Escalation a root via CVE-2022-20775: sfruttamento di una tecnica di downgrade della versione software per scalare i privilegi fino a root.
  • Manipolazione NETCONF: modifica delle configurazioni di rete tramite il protocollo NETCONF per alterare il traffico o creare tunnel nascosti.
  • Creazione di account malevoli: creazione di utenti backdoor per accesso persistente.
  • Anti-forensics sistematico: cancellazione di log da syslog, wtmp, lastlog, bash_history e cli-history per coprire le tracce dell’intrusione.


Un Pattern Preoccupante: Sei Zero-Day in Sei Mesi


CVE-2026-20182 non è un caso isolato. Come documenta SecurityWeek, si tratta della sesta vulnerabilità zero-day sfruttata attivamente sulle piattaforme Cisco SD-WAN nel corso del 2026, un dato che solleva interrogativi profondi sulla sicurezza dell’infrastruttura di rete enterprise. Gli SD-WAN sono sistemi critici che gestiscono il traffico di rete tra sedi aziendali distribuite, data center e cloud — la loro compromissione offre all’attaccante una visibilità strategica sull’intera architettura di rete della vittima.

La tendenza è chiara: i dispositivi di rete edge — firewall, VPN concentrator, SD-WAN controller — sono diventati il principale vettore di accesso iniziale per i gruppi APT più sofisticati al mondo. A differenza degli endpoint tradizionali, questi dispositivi raramente eseguono soluzioni EDR e spesso hanno cicli di aggiornamento lenti nelle organizzazioni.

Implicazioni Geopolitiche e per i Difensori


Il targeting di settori governativi e della difesa in Europa e Asia Centrale suggerisce una campagna di cyber-spionaggio strategico. Le sovrapposizioni infrastrutturali con attori Russia-linked come Gamaredon/Aqua Blizzard complicano ulteriormente l’attribuzione, un fenomeno sempre più comune nelle operazioni moderne dove la condivisione di infrastrutture (ORB network) oscura deliberatamente le responsabilità.

Per i team di sicurezza, le priorità immediate sono chiare:

  • Patching urgente: applicare immediatamente le patch Cisco per CVE-2026-20182 su tutti i Catalyst SD-WAN Controller e Manager esposti.
  • Audit delle authorized_keys: verificare l’integrità dei file SSH authorized_keys su tutti i sistemi SD-WAN.
  • Revisione account: identificare e rimuovere eventuali account non autorizzati creati sui sistemi.
  • Log integrity check: data la tendenza del gruppo a cancellare i log, implementare forwarding immediato su SIEM centralizzato.
  • Network segmentation review: limitare l’accesso amministrativo ai controller SD-WAN tramite reti di gestione dedicate e isolate.


CVE e Riferimenti Tecnici

CVE-2026-20182 — Cisco Catalyst SD-WAN Controller / Manager
CVSS Score: 10.0 (Critico)
Tipo: Authentication Bypass
Vettore: DTLS porta 12346 (handshake peering)
Impatto: Accesso amministrativo non autenticato

CVE correlati campagna UAT-8616:
- CVE-2026-20127 (zero-day precedente, sfruttato da febbraio 2026)
- CVE-2022-20775 (privilege escalation, usato per escalation a root)

Indicatori di Compromissione (comportamentali):
- SSH keys non autorizzate in authorized_keys
- Account di sistema inattesi
- Assenza di voci nei log syslog/wtmp/lastlog (log wiping)
- Configurazioni NETCONF alterate
- Traffico anomalo su porta DTLS 12346

Fonti: Cisco Talos, CISA KEV, SecurityWeek, Help Net Security, Tenable, Dark Reading

Cybersecurity & cyberwarfare ha ricondiviso questo.

Oggi è la #GiornataInternazionaledeiMusei.
Tema di questo 2026: Musei che uniscono un mondo diviso.

Mi ci ritrovo, e parecchio.
Il mio primo museo l'ho avuto in casa, la libreria di papà, libri sparsi su 2 piani, locandine, mostri di cera, una biblioteca che era una piccola Wunderkammer.

Il secondo è stato, nemmeno a dirlo, l'amore della mia vita: gli #Uffizi, un amore cominciato al Salone dei 500 in Palazzo Vecchio, proprio di fronte all'ufficio di mamma.
La strada che porta da Piazza della Signoria al museo è tutta dritta, sfocia sul Lungarno De' Medici, uno dei migliori dopo il Lungarno Serristori; il Piazzale degli Uffizi ospita anche uno storico mimo che interpreta Dante e la sua agonia - ragalategli un obolo e un sorriso, merita!

Se devo misurare il gradimento dei musei sul mio "museometro", posso spostare il cuoricino anche sul Grand Egyptian Museum del Cairo, uno spettacolo di cultura da fare gola a Fantomius!

L'ultimo, in ordine di tempo, è il Piccolo Museo del Purgatorio a Roma (di quello ne ho parlato in uno speciale di RdF).

In mezzo, parecchi altri.
Anche di questi, prima o poi, scriverò.

Small Engine Gets DIY EFI Upgrade


The media in this post is not displayed to visitors. To view it, please log in.

Small internal combustion engines usually keep things simple, relying on carburetors to handle metering the correct amount of fuel and air. Recently, [Carlos Takeshita] decided his small engine could use an upgrade in the form of electronic fuel injection (EFI).

The build began with a Predator 212, a popular gasoline engine from Harbor Freight. [Carlos] set about kitting it out with a missing tooth trigger wheel to measure the crankshaft position with a hall effect sensor. The engine also scored a custom-built aluminium fuel cell, complete with a high-pressure fuel pump and regulator suitable for driving the solitary fuel injector installed in the custom intake manifold. A Teensy 4.0 is charged with monitoring a manifold air pressure (MAP) sensor and the crank position, and choosing when and how long to fire the injector to dose the engine with the correct amount of fuel. Files are on GitHub for those eager to dive deeper.

It can be quite a job to convert an engine to run with electronic fuel injection, but you’re certain to learn a lot during the install and tuning process. We’ve featured similar builds many times over the years.

youtube.com/embed/ApN0I983zUQ?…


hackaday.com/2026/05/18/small-…

Cybersecurity & cyberwarfare ha ricondiviso questo.

The media in this post is not displayed to visitors. To view it, please go to the original post.

The media in this post is not displayed to visitors. To view it, please go to the original post.

Kazuar si evolve: Secret Blizzard (Turla) trasforma il suo backdoor storico in una botnet P2P modulare invisibile
#CyberSecurity
insicurezzadigitale.com/kazuar…


Kazuar si evolve: Secret Blizzard (Turla) trasforma il suo backdoor storico in una botnet P2P modulare invisibile


Si parla di:
Toggle

Il gruppo russo Secret Blizzard, operativo per conto dell’FSB (Federal Security Service) russo e meglio conosciuto come Turla, ha trasformato il proprio storico malware Kazuar in una botnet peer-to-peer modulare, progettata per mantenere accessi persistenti e praticamente invisibili nelle reti governative. La rivelazione arriva da Microsoft Security, che il 14 maggio 2026 ha pubblicato un’analisi approfondita dell’architettura del malware — descrivendo quello che è a tutti gli effetti un salto evolutivo nella sofisticazione operativa di uno dei gruppi APT più longevi al mondo.

Da backdoor tradizionale a ecosistema P2P


Kazuar è attivo almeno dal 2017 ed è stato impiegato in decine di campagne di cyberspionaggio contro governi, ambasciate e organizzazioni della difesa in Europa, Asia Centrale e Ucraina. La versione analizzata da Microsoft nel 2026 rappresenta però un cambio di paradigma: il malware non è più un semplice backdoor controllato centralmente, ma un ecosistema distribuito composto da tre moduli distinti che collaborano per garantire resilienza, persistenza e stealth.

La riorganizzazione è eloquente: non ogni macchina compromessa comunica con il server di comando e controllo (C2). Invece, un unico nodo “leader” — eletto dinamicamente dal modulo Kernel tra i sistemi infetti presenti nella stessa rete o segmento di rete — assume il ruolo di proxy verso l’infrastruttura esterna. Gli altri nodi entrano in modalità “silent”, eliminando quasi completamente il traffico verso l’esterno e riducendo drasticamente la superficie di rilevamento per i team di incident response.

Architettura modulare: Kernel, Bridge e Worker


Microsoft descrive tre componenti fondamentali della nuova architettura Kazuar:

  • Modulo Kernel: È il coordinatore centrale. Gestisce i task, controlla gli altri moduli, elegge il nodo leader e orchestra le comunicazioni e il flusso di dati attraverso la botnet.
  • Modulo Bridge: Agisce come proxy tra il nodo leader Kernel e il server C2 remoto. Filtra e instrada il traffico, permettendo ulteriore separazione tra i sistemi compromessi e l’infrastruttura degli attaccanti.
  • Modulo Worker: È il componente operativo. Registra i tasti premuti (keylogging), aggancia gli eventi Windows, traccia i task, raccoglie informazioni di sistema, listing di file e dettagli MAPI — incluse caselle email di Exchange.

Questa separazione funzionale non è casuale: in caso di rilevamento di un Worker, i nodi Kernel restano inalterati e possono continuare a operare silenziosamente. L’architettura è progettata per sopravvivere a rimozioni parziali.

150 parametri di configurazione: granularità operativa senza precedenti


Uno degli aspetti più rilevanti della nuova versione è il sistema di configurazione esteso: Kazuar supporta ora più di 150 parametri che gli operatori possono personalizzare per ogni campagna o vittima specifica. Questi parametri controllano metodi di esecuzione e persistenza (scheduled task, servizi Windows, chiavi di registro), bypass di AMSI e ETW, timing dell’esfiltrazione e dimensione dei chunk di dati, process injection e tecniche di lateral movement, e protocolli di comunicazione multipli: HTTP, WebSocket ed Exchange Web Services (EWS).

L’uso di EWS per mascherare le comunicazioni C2 nel traffico legittimo di Exchange è particolarmente insidioso: in ambienti enterprise dove Exchange Server è ubiquo, questo canale risulta quasi impossibile da distinguere dal traffico normale senza ispezione profonda dei payload.

Targeting: governi, ambasciate e settore difesa in Europa e Ucraina


Secret Blizzard (alias Turla, Uroburos, Venomous Bear) è noto per campagne di spionaggio ad altissimo valore strategico. Le vittime documentate includono ministeri degli esteri, ambasciate diplomatiche, dipartimenti della difesa e organizzazioni governative in Europa Orientale, Asia Centrale e — con intensità crescente — Ucraina nel contesto del conflitto in corso.

L’evoluzione di Kazuar verso un’architettura P2P suggerisce che il gruppo abbia tratto lezione dalle operazioni di takedown condotte negli ultimi anni contro infrastrutture di malware centralizzate. La distribuzione del controllo rende un’eventuale disruption dell’infrastruttura C2 molto meno efficace: rimuovere il server C2 non smantella la botnet, poiché il leader può essere eletto nuovamente tra i nodi sopravvissuti.

Due righe per i difensori


Microsoft raccomanda di concentrare il rilevamento su indicatori comportamentali piuttosto che su signature statiche. I team di sicurezza dovrebbero monitorare attività IPC insolite tra processi non correlati, rilevare pattern di elezione del leader nella rete interna tramite comunicazioni laterali anomale, identificare esfiltrazione dati staged e frammentata con timing irregolare, e controllare accessi anomali a EWS da processi non di posta elettronica. Dato il targeting storico di Secret Blizzard su entità diplomatiche e governative europee, le organizzazioni in questi settori dovrebbero considerare una revisione urgente dei log di rete e degli endpoint.

Indicatori di Compromissione (IoC)

# Kazuar - Secret Blizzard (Turla) - Maggio 2026
# Fonte: Microsoft Security Blog, 14 maggio 2026

# Tecniche MITRE ATT&CK associate
T1574.001 - DLL Search Order Hijacking
T1055     - Process Injection
T1071.001 - Application Layer Protocol: Web Protocols (HTTP/WebSocket)
T1071.003 - Application Layer Protocol: Mail Protocols (EWS)
T1030     - Data Transfer Size Limits (staged exfiltration)
T1053.005 - Scheduled Task/Job (persistence)
T1562.001 - Impair Defenses: Disable/Modify Tools (AMSI/ETW bypass)

# Comportamenti anomali da monitorare
- Comunicazioni IPC anomale tra processi non correlati
- Accessi Exchange Web Services (EWS) da processi non di posta
- Traffico P2P laterale interno su porte non standard
- Esfiltrazione dati in chunk temporizzati verso IP non categorizzati
- Moduli .NET iniettati in processi di sistema legittimi

# Referenza completa IoC
https://www.microsoft.com/en-us/security/blog/2026/05/14/kazuar-anatomy-of-a-nation-state-botnet/

Fonti: Microsoft Security Blog, BleepingComputer, The Hacker News

The media in this post is not displayed to visitors. To view it, please log in.

Kazuar si evolve: Secret Blizzard (Turla) trasforma il suo backdoor storico in una botnet P2P modulare invisibile


@Informatica (Italy e non Italy)
Il gruppo russo Secret Blizzard (Turla/FSB) ha trasformato il malware Kazuar in una botnet peer-to-peer con tre moduli distinti (Kernel, Bridge, Worker) e 150 parametri di configurazione. La


Kazuar si evolve: Secret Blizzard (Turla) trasforma il suo backdoor storico in una botnet P2P modulare invisibile


Si parla di:
Toggle

Il gruppo russo Secret Blizzard, operativo per conto dell’FSB (Federal Security Service) russo e meglio conosciuto come Turla, ha trasformato il proprio storico malware Kazuar in una botnet peer-to-peer modulare, progettata per mantenere accessi persistenti e praticamente invisibili nelle reti governative. La rivelazione arriva da Microsoft Security, che il 14 maggio 2026 ha pubblicato un’analisi approfondita dell’architettura del malware — descrivendo quello che è a tutti gli effetti un salto evolutivo nella sofisticazione operativa di uno dei gruppi APT più longevi al mondo.

Da backdoor tradizionale a ecosistema P2P


Kazuar è attivo almeno dal 2017 ed è stato impiegato in decine di campagne di cyberspionaggio contro governi, ambasciate e organizzazioni della difesa in Europa, Asia Centrale e Ucraina. La versione analizzata da Microsoft nel 2026 rappresenta però un cambio di paradigma: il malware non è più un semplice backdoor controllato centralmente, ma un ecosistema distribuito composto da tre moduli distinti che collaborano per garantire resilienza, persistenza e stealth.

La riorganizzazione è eloquente: non ogni macchina compromessa comunica con il server di comando e controllo (C2). Invece, un unico nodo “leader” — eletto dinamicamente dal modulo Kernel tra i sistemi infetti presenti nella stessa rete o segmento di rete — assume il ruolo di proxy verso l’infrastruttura esterna. Gli altri nodi entrano in modalità “silent”, eliminando quasi completamente il traffico verso l’esterno e riducendo drasticamente la superficie di rilevamento per i team di incident response.

Architettura modulare: Kernel, Bridge e Worker


Microsoft descrive tre componenti fondamentali della nuova architettura Kazuar:

  • Modulo Kernel: È il coordinatore centrale. Gestisce i task, controlla gli altri moduli, elegge il nodo leader e orchestra le comunicazioni e il flusso di dati attraverso la botnet.
  • Modulo Bridge: Agisce come proxy tra il nodo leader Kernel e il server C2 remoto. Filtra e instrada il traffico, permettendo ulteriore separazione tra i sistemi compromessi e l’infrastruttura degli attaccanti.
  • Modulo Worker: È il componente operativo. Registra i tasti premuti (keylogging), aggancia gli eventi Windows, traccia i task, raccoglie informazioni di sistema, listing di file e dettagli MAPI — incluse caselle email di Exchange.

Questa separazione funzionale non è casuale: in caso di rilevamento di un Worker, i nodi Kernel restano inalterati e possono continuare a operare silenziosamente. L’architettura è progettata per sopravvivere a rimozioni parziali.

150 parametri di configurazione: granularità operativa senza precedenti


Uno degli aspetti più rilevanti della nuova versione è il sistema di configurazione esteso: Kazuar supporta ora più di 150 parametri che gli operatori possono personalizzare per ogni campagna o vittima specifica. Questi parametri controllano metodi di esecuzione e persistenza (scheduled task, servizi Windows, chiavi di registro), bypass di AMSI e ETW, timing dell’esfiltrazione e dimensione dei chunk di dati, process injection e tecniche di lateral movement, e protocolli di comunicazione multipli: HTTP, WebSocket ed Exchange Web Services (EWS).

L’uso di EWS per mascherare le comunicazioni C2 nel traffico legittimo di Exchange è particolarmente insidioso: in ambienti enterprise dove Exchange Server è ubiquo, questo canale risulta quasi impossibile da distinguere dal traffico normale senza ispezione profonda dei payload.

Targeting: governi, ambasciate e settore difesa in Europa e Ucraina


Secret Blizzard (alias Turla, Uroburos, Venomous Bear) è noto per campagne di spionaggio ad altissimo valore strategico. Le vittime documentate includono ministeri degli esteri, ambasciate diplomatiche, dipartimenti della difesa e organizzazioni governative in Europa Orientale, Asia Centrale e — con intensità crescente — Ucraina nel contesto del conflitto in corso.

L’evoluzione di Kazuar verso un’architettura P2P suggerisce che il gruppo abbia tratto lezione dalle operazioni di takedown condotte negli ultimi anni contro infrastrutture di malware centralizzate. La distribuzione del controllo rende un’eventuale disruption dell’infrastruttura C2 molto meno efficace: rimuovere il server C2 non smantella la botnet, poiché il leader può essere eletto nuovamente tra i nodi sopravvissuti.

Due righe per i difensori


Microsoft raccomanda di concentrare il rilevamento su indicatori comportamentali piuttosto che su signature statiche. I team di sicurezza dovrebbero monitorare attività IPC insolite tra processi non correlati, rilevare pattern di elezione del leader nella rete interna tramite comunicazioni laterali anomale, identificare esfiltrazione dati staged e frammentata con timing irregolare, e controllare accessi anomali a EWS da processi non di posta elettronica. Dato il targeting storico di Secret Blizzard su entità diplomatiche e governative europee, le organizzazioni in questi settori dovrebbero considerare una revisione urgente dei log di rete e degli endpoint.

Indicatori di Compromissione (IoC)

# Kazuar - Secret Blizzard (Turla) - Maggio 2026
# Fonte: Microsoft Security Blog, 14 maggio 2026

# Tecniche MITRE ATT&CK associate
T1574.001 - DLL Search Order Hijacking
T1055     - Process Injection
T1071.001 - Application Layer Protocol: Web Protocols (HTTP/WebSocket)
T1071.003 - Application Layer Protocol: Mail Protocols (EWS)
T1030     - Data Transfer Size Limits (staged exfiltration)
T1053.005 - Scheduled Task/Job (persistence)
T1562.001 - Impair Defenses: Disable/Modify Tools (AMSI/ETW bypass)

# Comportamenti anomali da monitorare
- Comunicazioni IPC anomale tra processi non correlati
- Accessi Exchange Web Services (EWS) da processi non di posta
- Traffico P2P laterale interno su porte non standard
- Esfiltrazione dati in chunk temporizzati verso IP non categorizzati
- Moduli .NET iniettati in processi di sistema legittimi

# Referenza completa IoC
https://www.microsoft.com/en-us/security/blog/2026/05/14/kazuar-anatomy-of-a-nation-state-botnet/

Fonti: Microsoft Security Blog, BleepingComputer, The Hacker News

Cybersecurity & cyberwarfare ha ricondiviso questo.

The media in this post is not displayed to visitors. To view it, please go to the original post.

Someone sent me these pics from the Epsilon party at @offensivecon in Berlin.

Nice trolling on Trenchant's zero-day thief Peter Williams and on us with the now classic "Sun, Seafood, and Spyware" tagline. Thanks for reading!

This Week in Security: Android Exposes ADB, ShinyHunters Get Paid, Robot Dogs, and More


The media in this post is not displayed to visitors. To view it, please log in.

Google has patched an Android ADB bug in the May security patch set. If you have a Pixel phone you should already have the patches, and most other major manufacturers should be close behind. Unfortunately, the biggest risk from this patch will be to the vendors who are also the least likely to release timely – or any – security updates.

ADB, the Android Debug Bridge, is the main tool for installing apps during development and debugging apps while they’re running. It can also be used to side-load apps from a PC. While most normal users are unlikely to ever enable it, developers typically do and some power users might when jailbreaking a device or setting parameters not exposed in the Android UI. Debugging can be done locally via USB, or optionally over the network. To protect the device, the user must unlock the Android device and authorize each new debug agent.

Covered by Risky.Biz, a bug introduced in 2020, and present in every Android release since, allowed bypassing authorization entirely if network debugging was enabled and at least one connection had been made to the ADB service in the past. This happens because ADB compares the certificate of the incoming debug connection with the list of saved certificates. If the certificate type does not match — for instance supplying an Ed25519 certificate instead of a RSA certificate — ADB has been incorrectly handling the error code, and allowing the connection.

In most programming languages, false is considered zero, and true is considered anything not zero. The certificate API returns a 1 for a valid match, a zero for an invalid match, and a negative-one for a type mismatch. Negative one is not zero, so when treated as a boolean value, it becomes true.

To exploit the bug, ADB must be enabled in wireless mode, and there must be at least one trusted device in the ADB configuration. For the average user this is an unlikely combination, but for developers, the time to update is now.

Mythos Finds a Curl Bug


Daniel Stenberg of Curl posts about recent interactions with the Mythos AI model finding vulnerabilities – or rather a singular vulnerability – in Curl. Curl, and the companion library libcurl, run in an estimated 20 billion instances, so any security issue could be critical.

After some confusion about access to the model, five vulnerabilities found were ultimately condensed to a single new vulnerability. Classified as “not particularly dangerous”, the issue will be assigned a CVE and be fixed in an upcoming patch.

Daniel’s post contains a wealth of additional information and commentary about the experience with Mythos. The lack of findings from Mythos may be more a reflection on the maturity of the Curl codebase than anything else; the Curl code is an excellent example of the impact of continual auditing, by all types of tools.

XBow Finds an Exim Bug


XBow has found a vulnerability in Exim using AI tooling. Exim is an open-source message transport agent (MTA, or email server to most of us) like Postfix and Sendmail. Classified as CVE-2026-45185, it has a 9.8 CVE score (out of 10), allowing arbitrary code execution without authentication.

The bug is one of the “use after free” class of mistakes: after allocating memory, using it for some task, then releasing the memory (freeing it), Exim forgets the memory has been freed and continues to use it. In this case, memory allocated as part of a TLS encrypted connection is freed when the TLS connection is ended, but the handler for incoming email data may still write to the now-destroyed buffer, which in turn allows corruption of the memory management system inside Exim and, ultimately, running arbitrary code.

Arbitrary code execution vulnerabilities are typically just as bad as they sound – the ability to run arbitrary code is essentially the ability to run anything on the system, including running system commands as if logged in. Combined with the recent collection of local privilege escalation vulnerabilities like CopyFail (and more on this later), unauthenticated code execution is a short path to full root control of the system.

The Internet indexer Shodan currently shows 2.5 million installs of Exim globally. If you run Exim anywhere, hopefully you’ve already updated – and update immediately if not!

CopyFail Three-quel


It’s the three-quel nobody wanted; being named “CopyFail 3.0” and “Fragnesia”, another vulnerability that is extremely similar to those used in CopyFail and DirtyFrag has been found and patches have begun on the Linux kernel. Like the previous bugs, this one lies in the Linux kernel handling of IPSec ESP encryption, and allows modifying the in-memory page cache used for accelerating disk IO.

Fortunately, because this uses the same kernel modules as previous vulnerabilities, any system with the mitigations for DirtyFrag in place — essentially disabling IPSec functionality — should not be impacted, however any system patched for DirtyFrag with the IPSec kernel modules available will need to be patched again!

It’s Patch Tuesday!


It’s Microsoft Patch Tuesday again! Brian Krebs has the roundup, calling out three patches in particular that allow privilege escalation to admin or system, and one remote code execution bug in the Microsoft DHCP client.

If you’re a Microsoft user, or run IT in a Microsoft shop, you already know the balancing act – update immediately because of the security implications, or wait and see if this set of patches breaks basic functionality again?

More Windows 0-Days


It seems like it wouldn’t be a Patch Tuesday without additional drama – the author behind previous Windows zero-day exploits the past two months follows up this month with two more, seemingly still upset with the Microsoft security teams responses.

The YellowKey vulnerability consists of nothing more than specifically named files on a USB stick. When booted in recovery mode, the files trigger a Windows 11 recovery image to launch a shell with Bitlocker disk encryption turned off. It’s unclear if this functionality is a deliberate backdoor or some sort of debug functionality accidentally left in the builds, but it is extremely odd.

GreenPlasma is a privilege escalation vulnerability, allowing elevation to system level privileges, which would give access to the system credentials database, among other bad results. Similar issues were patched in this months Patch Tuesday set, but not this one.

Criminals Use Tools for Crime


Google is trying to hype what is claimed to be the first use of AI to write an exploit caught in the wild. This seems extremely unlikely given the past year or more of development on the AI front.

Treating news as boring is never fun, but it seems unsurprising that criminals are going to use the tools available to continue being criminals. This feels like less of a revelation than a continuation of obvious trends: groups who have not been able to develop in-house tooling have always purchased tools, stolen tooling from other groups, or used commoditized exploits, easily as far back as the Anonymous “Low Orbit Ion Canon” tool in 2005 to allow recruitment and participation by less technical users.

Attack and exploit code doesn’t need to worry about the technical debt or repeatability challenges of AI generated code, and it seems obvious that attackers will minimize their own effort whenever possible.

Malware and Residential Proxies


Bitsight Research published a paper on the relationships between malware infections and residential proxy networks.

Proxy networks act similarly to a VPN, taking traffic from one source and tunneling it to appear to come from a different source. Made up of typically unwitting home users, residential proxy networks are often resold as cheap commercial VPN services. (Not all commercial VPN providers are equal, while some are completely legitimate, many are not.) Proxy networks can also be leveraged to allow attackers to operate inside a different country, obfuscating the true attack location or bypassing login restrictions or alerts to detect if a user has an impossible location or travel pattern. Proxy networks are also often involved in advertisement click fraud, appearing as an army of normal home users who are really interested in click on ads, and are also used to pivot into the internal home network, where devices are often completely unprotected.

Bitsight tracked over 53 million IPs acting as residential proxy devices over a two-month period, split between several proxy network brokers reselling access, typically with over eight million nodes available daily, with strong ties between malware infections and remote access proxy tool installation.

FCC Extends Router Deadline


The FCC has announced it is extending the initial timeline for foreign-made routers. Previously the FCC had declared that not only would nearly all new consumer router hardware be banned from FCC certification, it would no longer be allowed to receive software updates as of early 2027.

Possibly noticing the conflict in the stated goal of increased security while prohibiting security patches, the deadline has been extended for consumer routers and drones to receive software updates until 2029.

SMS Spammers Arrested


You might rightly assume that most SMS spam comes from compromised phones or Internet-connected SMS bridges, but TechCrunch reports on the arrest of three men in Toronto for operating a mobile SMS-spamming cell tower.

The spammers ran the spoofed cell tower in the back of a car while driving around the city. Once a phone connected to the false tower, the tower bombarded it with SMS messages with phishing lures for credential and banking theft.

Operating a fake cell tower is extremely illegal in almost all countries, in no small part because it actively interferes with emergency services such as E911. Police estimate that over a million SMS messages were sent by the trio since November, 2025.

Robot Dog Malware


A paper in IEEE Spectrum from November, 2025 covers discoveries of a potentially wormable vulnerability in the Unitree robotics platform used for canine and humanoid robots. Unitree robots are sometimes used as security or even military devices.

This week, Benn Jordan published a YouTube video exploring some of the vulnerabilities in his personal robots, referencing the GitHub of the original researchers.

Multiple vulnerabilities have been found in the robotics platform that allow overriding the safety mechanisms of the robots, as well as running arbitrary code on the robot, scanning for WiFi and Bluetooth devices, and mechanisms the robots use to communicate with various servers, some in foreign countries.

The research suggests that at least one vulnerability – the ability to gain root on the device from an unauthenticated Bluetooth Low-Energy connection – could be turned into a worm, where one infected robot could use the on-board Bluetooth to infect other nearby devices.

Benn Jordan has previously been influential in the public outcry against monitoring platforms like Flock, so highlighting vulnerabilities in a platform used by police, private security, and military seems a reasonable continuation.

TCLBANKER Trojan


A WhatsApp based worm is targeting users of banking, crypto, and fintech services. The TCLBANKER malware hijacks WhatsApp web and Outlook email accounts to spread a zip file which uses a legitimate signed Logitech tool but injects the payload into the install process.

Once infected, the user is presented with a series of falsified UI screens, including fake system updates, which hides the actual activity of the infection and tricks the user into clicking on hidden elements of the true UI to authorize actions.

The TCLBANKER worm attempts to hide from analysis by downloading encrypted payloads keyed to a hash of the environment. If analysis tools like a debugger are installed, the payload will not decrypt.

ShinyHunters Get Paid


Last week, the group known as ShinyHunters made news by compromising the Canvas educational platform and threatening to leak the personal data and messages of millions of students. The attack culminated with ransom notes taking over the portals of hundreds of schools, and the Canvas platform being shut down “for maintenance” during finals week for many schools.

This week, it appears the ransom was paid, with ShinyHunters promising to destroy the stolen data.

Paying ransom is a hot-button issue: nobody wants to see the ransomware model continue as a profitable venture, but it is tough to argue that millions of students with no voice in the choice of educational platforms should have their data released.

Token Stealer Doesn’t Want to Leave


Trojaned packages continue to be a problem for NPM and other ecosystems, as automated supply chain infections continue to infect high-profile projects.

This time, the TanStack application framework used for developing web applications was compromised by a supply chain worm, “Mini Shai Halud”, a variant of the Dune-themed “Shai Halud” worm infecting packages since March.

The worm spreads via NPM and PyPi and infects packages, developer systems, and GitHub actions, targeting service keys for package repos, cloud resources, AI platforms, and GitHub. The worm also installs services on infected developer systems to capture future service tokens when they are added, and further investigation by the TanStack team uncovered additional services which monitor the stolen credentials and attempt to wipe infected systems using rm -rf / if the stolen credentials are revoked.

Prescription Drug Ransomware


A ransomware attack has hit West Pharmaceutical in Pennsylvania, USA, with filings indicating the attack disrupted the company globally.

West Pharmaceuticals manufacturers packaging for drugs and healthcare items, so a global shutdown of manufacturing and shipping could have a much longer impact on drug availability.

[Editor’s note: Sorry this one runs late! Hackaday Europe was on and it slipped through the cracks. The next installment of This Week in Security will be hitting the pages on Friday as usual.]


hackaday.com/2026/05/18/this-w…

Cybersecurity & cyberwarfare ha ricondiviso questo.

#ShinyHunters hack 7-Eleven: franchisee data and Salesforce records exposed
securityaffairs.com/192336/dat…
#securityaffairs #hacking
Cybersecurity & cyberwarfare ha ricondiviso questo.

Public #Amazon bucket leaks sensitive guest data from Japanese hotel platform #Tabiq
securityaffairs.com/192302/dat…
#securityaffairs #hacking

MiniPlasma: la patch del 2020 su Windows che non c’è mai stata o è sparita


@Informatica (Italy e non Italy)
Una vulnerabilità Windows corretta nel 2020 potrebbe non essere mai stata davvero risolta. Con MiniPlasma, il ricercatore Chaotic Eclipse dimostra che il vecchio PoC di Google Project Zero funziona ancora su sistemi Windows 11 aggiornati. Il caso evidenzia i

The media in this post is not displayed to visitors. To view it, please log in.

IT threat evolution in Q1 2026. Mobile statistics
IT threat evolution in Q1 2026. Non-mobile statistics

In the third quarter of 2025, we updated the methodology for calculating statistical indicators based on the Kaspersky Security Network. These changes affected all sections of the report except for the statistics on installation packages, which remained unchanged.

To illustrate the differences between the reporting periods, we have also recalculated data for the previous quarters. Consequently, these figures may significantly differ from the previously published ones. However, subsequent reports will employ this new methodology, enabling precise comparisons with the data presented in this post.

The Kaspersky Security Network (KSN) is a global network for analyzing anonymized threat information, voluntarily shared by users of Kaspersky solutions. The statistics in this report are based on KSN data unless explicitly stated otherwise.

The quarter in numbers


According to Kaspersky Security Network, in Q1 2026:

  • More than 2.67 million attacks utilizing malware, adware, or unwanted mobile software were prevented.
  • The Trojan-Banker category was the prevalent mobile malware threat with a 10.86% share of total detections.
  • More than 306,000 malicious installation packages were discovered, including:
    • 162,275 packages related to mobile banking Trojans;
    • 439 packages related to mobile ransomware Trojans.



Quarterly highlights


The number of malware, adware, or unwanted software attacks on mobile devices decreased to 2,676,328 in Q1, down from 3,239,244 in the previous quarter.

Attacks on users of Kaspersky mobile solutions, Q3 2024 — Q1 2026 (download)

The overall drop in attack volume stems primarily from a reduction in adware and RiskTool detections. Nonetheless, this trend does not equate to a lower risk for mobile users. As shown later in this report, the number of unique users targeted by these threats remained relatively stable.

In Q1, Synthient researchers identified a link between the notorious Kimwolf botnet and the IPIDEA proxy network. This network was later taken down in cooperation with GTIG.

In early 2026, we discovered several apps on Google Play and the App Store that contained a new version of the SparkCat crypto stealer.

The Trojan code, meticulously concealed, was embedded into the infected Android apps. The obfuscated malicious Rust library was decrypted using a Dalvik-like virtual machine custom-built by the attackers. The iOS version of the malware also underwent several changes; specifically, the attackers began leveraging Apple’s proprietary Vision framework for optical character recognition (OCR).

Mobile threat statistics


The number of Android malware samples saw a slight increase compared to Q4 2025, reaching a total of 306,070.

Detected malicious and potentially unwanted installation packages, Q1 2025 — Q1 2026 (download)

The detected installation packages were distributed by type as follows:

Detected mobile apps by type, Q4 2025* — Q1 2026 (download)

* Data for the previous quarter may differ slightly from previously published figures due to certain verdicts being retrospectively revised.

Threat actors once again ramped up the production of new banking Trojans; as a result, this category overtook all others in volume, accounting for more than half of all installation packages.

Share* of users attacked by the given type of malicious or potentially unwanted app out of all targeted users of Kaspersky mobile products, Q4 2025 — Q1 2026 (download)

* The total percentage may exceed 100% if the same users encountered multiple attack types.

Following the surge in banking Trojan installation packages, the number of associated attacks also rose, causing Trojan-Banker apps to climb one spot in terms of their share of targeted users. Mamont variants emerged as the most prevalent banking Trojans, accounting for 73.5% of detections, with the rest of the users encountering Faketoken, Rewardsteal, Creduz, and other families.

Yet banking Trojans were still outpaced by adware and RiskTool-type unwanted apps when measured by the total number of affected users. Despite a decrease in their share of installation packages, these two app types retained their positions as the top two threats by attack volume. The most common adware detections involved HiddenAd (44.9%) and MobiDash (38.1%), while most frequently seen RiskTool apps were Revpn (67%) and SpyLoan (20.5%).

TOP 20 most frequently detected types of mobile malware


Note that the malware rankings below exclude riskware or potentially unwanted software, such as RiskTool or adware.

Verdict%* Q4 2025%* Q1 2026Difference in p.p.Change in ranking
Backdoor.AndroidOS.Triada.ag2.627.09+4.48+10
DangerousObject.Multi.Generic.6.755.84-0.92-1
DangerousObject.AndroidOS.GenericML.3.525.51+1.99+6
Trojan-Banker.AndroidOS.Mamont.jo0.005.28+5.28
Trojan.AndroidOS.Fakemoney.v5.403.44-1.96-1
Trojan-Downloader.AndroidOS.Keenadu.l0.003.35+3.35
Trojan-Banker.AndroidOS.Mamont.jx0.003.09+3.09
Backdoor.AndroidOS.Triada.z4.873.08-1.79-2
Trojan.AndroidOS.Triada.fe5.012.98-2.02-4
Backdoor.AndroidOS.Keenadu.a2.072.73+0.66+6
Trojan-Banker.AndroidOS.Mamont.jg0.342.37+2.03
Trojan.AndroidOS.Triada.hf2.152.23+0.07+3
Trojan.AndroidOS.Boogr.gsh2.352.15-0.200
Trojan.AndroidOS.Triada.ii5.682.07-3.60-11
Backdoor.AndroidOS.Triada.ae1.911.76-0.16+3
Backdoor.AndroidOS.Triada.ab1.791.72-0.08+3
Trojan.AndroidOS.Triada.gn2.381.58-0.80-5
Trojan-Banker.AndroidOS.Mamont.gg1.561.50-0.06+2
Trojan.AndroidOS.Triada.ga1.481.50+0.01+4
Backdoor.AndroidOS.Triada.ad0.531.40+0.87+44

* Unique users who encountered this malware as a percentage of all attacked users of Kaspersky mobile solutions.

The pre-installed Triada.ag backdoor rose to the top spot; it is similar to the older Triada.z version we documented previously. Because the same variant was pre-installed across a wide range of devices, the total number of affected users is aggregated. Consequently, Triada outpaced even Mamont, as users encountered a variety of Mamont variants, causing the share of that banking Trojan to spread across multiple rows. Other pre-installed Triada variants (Triada.z, Triada.ae, Triada.ab, and Triada.ad) also made the rankings. Furthermore, we observed increasing activity from the Keenadu.a backdoor, while diverse variants of the embedded Triada Trojan remained in the rankings.

Mobile banking Trojans


Q1 2026 saw a characteristic rise in mobile banking Trojan activity, with the number of packages totaling 162,275, a 50% increase compared to the prior quarter.

Number of installation packages for mobile banking Trojans detected by Kaspersky, Q1 2025 — Q1 2026 (download)

We saw a similar growth in the previous quarter, with banking Trojan volumes rising by 50% during that period as well. Various Mamont variants accounted for the absolute majority of packages and represented nearly every entry in the rankings of most frequent banking Trojans by affected user count.

TOP 10 mobile bankers

Verdict%* Q4 2025%* Q1 2026Difference in p.p.Change in ranking
Trojan-Banker.AndroidOS.Mamont.jo0.0015.75+15.75
Trojan-Banker.AndroidOS.Mamont.jx0.009.22+9.22
Trojan-Banker.AndroidOS.Mamont.jg1.477.08+5.61+24
Trojan-Banker.AndroidOS.Mamont.gg6.794.48-2.32-3
Trojan-Banker.AndroidOS.Mamont.ks0.003.98+3.98
Trojan-Banker.AndroidOS.Agent.ws6.033.78-2.25-2
Trojan-Banker.AndroidOS.Mamont.hl4.303.27-1.03+1
Trojan-Banker.AndroidOS.Mamont.iv6.003.08-2.92-3
Trojan-Banker.AndroidOS.Mamont.jb3.933.07-0.86+1
Trojan-Banker.AndroidOS.Mamont.jv0.002.79+2.79

* Unique users who encountered this malware as a percentage of all users of Kaspersky mobile security solutions who encountered banking threats.


securelist.com/malware-report-…

IT threat evolution in Q1 2026. Non-mobile statistics


The media in this post is not displayed to visitors. To view it, please log in.

IT threat evolution in Q1 2026. Non-mobile statistics
IT threat evolution in Q1 2026. Mobile statistics

The statistics in this report are based on detection verdicts returned by Kaspersky products unless otherwise stated. The information was provided by Kaspersky users who consented to sharing statistical data.

Quarterly figures


In Q1 2026:

  • Kaspersky products blocked more than 343 million attacks that originated with various online resources.
  • Web Anti-Virus responded to 50 million unique links.
  • File Anti-Virus blocked nearly 15 million malicious and potentially unwanted objects.
  • 2938 new ransomware variants were detected.
  • More than 77,000 users experienced ransomware attacks.
  • 14% of all ransomware victims whose data was published on threat actors’ data leak sites (DLS) were victims of Clop.
  • More than 260,000 users were targeted by miners.


Ransomware

Quarterly trends and highlights

Law enforcement success


In January 2026, it was reported that the FBI had seized the domains of the RAMP cybercrime forum, a major platform used extensively by ransomware developers to advertise their RaaS programs and to recruit affiliates. There has been no official statement from the FBI, nor is it clear if RAMP servers were seized. In a post on an external website, a RAMP moderator mentioned law enforcement agencies gaining control over the forum. The takedown disrupted a key element of the RaaS ecosystem, creating ripple effects for ransomware operators, affiliates, and initial access brokers.

A man suspected of links to the Phobos group was apprehended in Poland. He was charged with the creation, acquisition, and distribution of software designed for unlawfully obtaining information, including data that facilitates unauthorized access to information stored within a computer system.

In March, a Phobos ransomware administrator pleaded guilty to the creation and distribution of the Trojan, which had been used in international attacks dating back to at least November 2020.

In March, the U.S. Department of Justice charged a man who had acted as a negotiator for ransomware groups. The company he worked for specializes in cyberincident investigations. The prosecution alleges the suspect colluded with the BlackCat threat actor to share privileged insights into the ongoing progress of negotiations. Additionally, the suspect is alleged to have had a prior direct role in BlackCat attacks, serving as an affiliate for the RaaS operation.

In a separate development this March, a U.S. court sentenced an initial access broker associated with the Yanluowang ransomware group to 81 months of imprisonment. According to the U.S. Department of Justice, the convict facilitated dozens of ransomware attacks across the United States, resulting in over $9 million in actual loss and more than $24 million in intended loss.

Vulnerabilities and attacks


The Interlock group has been heavily exploiting the CVE-2026-20131 zero-day vulnerability in Cisco Secure FMC firewall management software since at least January 26, 2026. The vulnerability enabled arbitrary Java code execution with root privileges on the affected device. This campaign demonstrates the ongoing reliance on zero-day vulnerabilities for initial access, a focus on network appliances as high-value entry points, and the rapid weaponization of new vulnerabilities within the ransomware ecosystem.

The most prolific groups


This section highlights the most prolific ransomware gangs by number of victims added to each group’s DLS. This quarter, the Clop ransomware (14.42%) returned to the top of the rankings, displacing Qilin (12.34%), which had held the leading position in the previous reporting period. Following closely is a new threat actor, The Gentlemen (9.25%). Emerging no later than July 2025, the group had already surpassed the activity levels of mainstays such as Akira (7.25%) and INC Ransom (6.13%).

Number of each group’s victims according to its DLS as a percentage of all groups’ victims published on all the DLSs under review during the reporting period (download)

Number of new variants


In Q1 2026, Kaspersky solutions detected six new ransomware families and 2938 new modifications. Volumes have returned to Q3 2025 levels following a surge in Q4 2025.

Number of new ransomware modifications, Q1 2025 — Q1 2026 (download)

Number of users attacked by ransomware Trojans


Throughout Q1, our solutions protected 77,319 unique users from ransomware. Ransomware activity was highest in March, with 35,056 unique users encountering such attacks during the month.

Number of unique users attacked by ransomware Trojans, Q1 2026 (download)

Attack geography

TOP 10 countries and territories attacked by ransomware Trojans
Country/territory*%**
1Pakistan0.79
2South Korea0.64
3China0.52
4Tajikistan0.40
5Libya0.38
6Turkmenistan0.36
7Iraq0.35
8Bangladesh0.33
9Rwanda0.30
10Cameroon0.28

* Excluded are countries and territories with relatively few (under 50,000) Kaspersky users.
** Unique users whose computers were attacked by ransomware Trojans as a percentage of all unique users of Kaspersky products in the country/territory.

TOP 10 most common families of ransomware Trojans

NameVerdict%*
1(generic verdict)Trojan-Ransom.Win32.Gen33.90
2(generic verdict)Trojan-Ransom.Win32.Crypren6.38
3WannaCryTrojan-Ransom.Win32.Wanna5.87
4(generic verdict)Trojan-Ransom.Win32.Encoder4.68
5(generic verdict)Trojan-Ransom.Win32.Agent3.80
6LockBitTrojan-Ransom.Win32.Lockbit2.80
7(generic verdict)Trojan-Ransom.Win32.Phny1.99
8(generic verdict)Trojan-Ransom.MSIL.Agent1.96
9(generic verdict)Trojan-Ransom.Python.Agent1.93
10(generic verdict)Trojan-Ransom.Win32.Crypmod1.89

* Unique Kaspersky users attacked by the specific ransomware Trojan family as a percentage of all unique users attacked by this type of threat.

Miners

Number of new variants


In Q1 2026, Kaspersky solutions detected 3485 new modifications of miners.

Number of new miner modifications, Q1 2026 (download)

Number of users attacked by miners


In Q1, we detected attacks using miner programs on the computers of 260,588 unique Kaspersky users worldwide.

Number of unique users attacked by miners, Q1 2026 (download)

Attack geography

TOP 10 countries and territories attacked by miners
Country/territory*%**
1Senegal3.19
2Turkmenistan3.06
3Mali2.63
4Tanzania1.62
5Bangladesh1.06
6Ethiopia0.95
7Panama0.88
8Afghanistan0.79
9Kazakhstan0.77
10Bolivia0.75

* Excluded are countries and territories with relatively few (under 50,000) Kaspersky users.
** Unique users whose computers were attacked by miners as a percentage of all unique users of Kaspersky products in the country/territory.

Attacks on macOS


In Q1 2026, Google uncovered a new cryptocurrency theft campaign. The scammers directed victims to a fraudulent video call, prompting them to execute malicious scripts under the guise of technical support fixes for connection problems.

In March, researchers with GTIG and iVerify reported the discovery of an in-the-wild exploit chain targeting both iOS and macOS devices. The exploit kit was apparently marketed on the dark web, providing threat actors with a suite of spyware capabilities alongside specialized cryptocurrency exfiltration modules. The exploit was delivered via drive-by downloads when victims visited various compromised websites. Our analysis confirmed that the toolkit included an updated version of a component previously identified in the Operation Triangulation attack chain.

Devices running macOS were similarly impacted by the high-profile supply chain attack targeting the Axios npm package, a widely used HTTP client for JavaScript. The installation of the infected package led to the deployment of a backdoor on macOS devices.

TOP 20 threats to macOS

Unique users* who encountered this malware as a percentage of all attacked users of Kaspersky security solutions for macOS (download)

* Data for the previous quarter may differ slightly from previously published data due to some verdicts being retrospectively revised.

The share of PasivRobber spyware attacks is beginning to decline, giving way to more traditional adware and Monitor-class software capable of tracking user activity. The popular Amos stealer also maintains its presence within the TOP 20.

Geography of threats to macOS

TOP 10 countries and territories by share of attacked users
Country/territory%* Q4 2025%* Q1 2026
China1.281.97
France1.181.07
Brazil1.130.98
Mexico0.720.52
Germany0.710.45
The Netherlands0.620.75
Hong Kong0.490.53
India0.420.48
Russian Federation0.340.37
Thailand0.240.27

* Unique users who encountered threats to macOS as a percentage of all unique Kaspersky users in the country/territory.

IoT threat statistics


This section presents statistics on attacks targeting Kaspersky IoT honeypots. The geographic data on attack sources is based on the IP addresses of attacking devices.

In Q1 2026, the share of devices attacking Kaspersky honeypots via the SSH protocol saw a significant increase compared to the previous reporting period.

Distribution of attacked services by number of unique IP addresses of attacking devices (download)

The distribution of attacks between Telnet and SSH maintained the ratio observed in Q4 2025.

Distribution of attackers’ sessions in Kaspersky honeypots (download)

TOP 10 threats delivered to IoT devices

Share of each threat delivered to an infected device as a result of a successful attack, out of the total number of threats delivered (download)

The primary shifts in the IoT threat distribution are linked to the activity of various Mirai botnet variants, although members of this family continue to account for the majority of the list. Furthermore, a new variant, Mirai.kl, surfaced in the rankings. We also observed a significant decline in NyaDrop botnet activity during Q1.

Attacks on IoT honeypots


The United States, the Netherlands, and Germany accounted for the highest proportions of SSH-based attacks during this period.

Country/territoryQ4 2025Q1 2026
United States16.10%23.74%
The Netherlands15.78%17.57%
Germany12.07%10.34%
Panama7.72%6.34%
India5.32%6.05%
Romania4.05%5.82%
Australia1.62%4.61%
Vietnam4.21%3.50%
Russian Federation3.79%2.35%
Sweden2.25%2.09%

China continues to account for the largest proportion of Telnet attacks, though there was a marked increase in activity originating from Pakistan.

Country/territoryQ4 2025Q1 2026
China53.64%39.54%
Pakistan14.27%27.31%
Russian Federation8.20%8.25%
Indonesia8.58%6.71%
India4.85%4.66%
Brazil0.06%3.30%
Argentina0.02%2.51%
Nigeria1.22%1.38%
Thailand0.01%0.55%
Sweden0.54%0.55%

Attacks via web resources


The statistics in this section are based on detection verdicts by Web Anti-Virus, which protects users when suspicious objects are downloaded from malicious or infected web pages. These malicious pages are purposefully created by cybercriminals. Websites that host user-generated content, such as message boards, as well as compromised legitimate sites, can become infected.

TOP 10 countries and territories that served as sources of web-based attacks


The following statistics show the distribution by country/territory of the sources of internet attacks blocked by Kaspersky products on user computers (web pages redirecting to exploits, sites containing exploits and other malicious programs, botnet C&C centers, and so on). One or more web-based attacks could originate from each unique host.

To determine the geographic source of web attacks, we matched the domain name with the real IP address where the domain is hosted, then identified the geographic location of that IP address (GeoIP).

In Q1 2026, Kaspersky solutions blocked 343,823,407 attacks launched from internet resources worldwide. Web Anti-Virus was triggered by 49,983,611 unique URLs.

Web-based attacks by country/territory, Q1 2026 (download)

Countries and territories where users faced the greatest risk of online infection


To assess the risk of malware infection via the internet for users’ computers in different countries and territories, we calculated the share of Kaspersky users in each location on whose computers Web Anti-Virus was triggered during the reporting period. The resulting data provides an indication of the aggressiveness of the environment in which computers operate in different countries and territories.

This ranked list includes only attacks by malicious objects classified as Malware. Our calculations leave out Web Anti-Virus detections of potentially dangerous or unwanted programs, such as RiskTool or adware.

Country/territory*%**
1Venezuela9.33
2Hungary8.16
3Italy7.58
4Tajikistan7.48
5India7.21
6Greece7.13
7Portugal7.10
8France7.05
9Belgium6.83
10Slovakia6.80
11Vietnam6.62
12Bosnia and Herzegovina6.57
13Canada6.56
14Serbia6.50
15Tunisia6.36
16Qatar6.01
17Spain5.95
18Germany5.95
19Sri Lanka5.89
20Brazil5.88

* Excluded are countries and territories with relatively few (under 10,000) Kaspersky users.
** Unique users targeted by web-based Malware attacks as a percentage of all unique users of Kaspersky products in the country/territory.

On average during the quarter, 4.73% of users’ computers worldwide were subjected to at least one Malware web attack.

Local threats


Statistics on local infections of user computers are an important indicator. They include objects that penetrated the target computer by infecting files or removable media, or initially made their way onto the computer in non-open form. Examples of the latter are programs in complex installers and encrypted files.

Data in this section is based on analyzing statistics produced by anti-virus scans of files on the hard drive at the moment they were created or accessed, and the results of scanning removable storage media. The statistics are based on detection verdicts from the On-Access Scan (OAS) and On-Demand Scan (ODS) modules of File Anti-Virus and include detections of malicious programs located on user computers or removable media connected to the computers, such as flash drives, camera memory cards, phones, or external hard drives.

In Q1 2026, our File Anti-Virus detected 15,831,319 malicious and potentially unwanted objects.

Countries and territories where users faced the highest risk of local infection


For each country and territory, we calculated the percentage of Kaspersky users whose computers had the File Anti-Virus triggered at least once during the reporting period. This statistic reflects the level of personal computer infection in different countries and territories around the world.

Note that this ranked list includes only attacks by malicious objects classified as Malware. Our calculations leave out File Anti-Virus detections of potentially dangerous or unwanted programs, such as RiskTool or adware.

Country/territory*%**
1Turkmenistan47.96
2Tajikistan31.48
3Cuba31.03
4Yemen29.59
5Afghanistan28.47
6Burundi26.93
7Uzbekistan24.81
8Syria23.08
9Nicaragua21.97
10Cameroon21.60
11China21.09
12Mozambique21.02
13Algeria20.64
14Democratic Republic of the Congo20.63
15Bangladesh20.44
16Mali20.35
17Republic of the Congo20.23
18Madagascar20.00
19Belarus19.78
20Tanzania19.52

* Excluded are countries and territories with relatively few (under 10,000) Kaspersky users.
** Unique users on whose computers local Malware threats were blocked, as a percentage of all unique users of Kaspersky products in the country/territory.

On average worldwide, Malware local threats were detected at least once on 11.55% of users’ computers during Q1.

Russia scored 11.92% in these rankings.


securelist.com/malware-report-…

Warning from the UK: how not to create digital policy


The media in this post is not displayed to visitors. To view it, please log in.

Warning from the UK: how not to create digital policy
IT'S MONDAY, AND THIS IS DIGITAL POLITICS. I'm Mark Scott, and you find me filing this dispatch via dodgy wifi on the way to Brussels. If you're in town, I'll be at the CPDP conference most of the week. Let's grab coffee.

— The United Kingdom is again engulfed in political infighting. The country's tech ambitions are equally on life support.

— In the wake of the recent China-United States summit, Middle Power countries are using their unique digital industrial policy skills to navigate the new geopolitical reality.

— The world's leading artificial intelligence firms are massively subsiziding their models to win market share. That is unsustainable.

Let's get started:



digitalpolitics.co/newsletter0…

Running a VPN Gateway on an ESP32


The media in this post is not displayed to visitors. To view it, please log in.

A black screen with green text is shown. The green text logs events from a VPN gateway.

If you need a VPN gateway to access your home network, the fastest and most cost-effective way is probably by using a Raspberry Pi Zero. But in [Samir Makwana]’s view, an ESP32-S3 is just as capable for moderate use, and in some respects even superior.

This was possible thanks to the MicroLink project, which is a full implementation of a Tailscale client for the ESP32 family. In some ways the ESP32 worked better than a Raspberry Pi: it boots in two seconds rather than thirty, draws 0.5 Watts rather than 1.5, and there’s no chance of it failing due to a corrupted SD card. Compared to a Raspberry Pi, however, which can be set up as a Tailscale client in a few minutes, this took several hours to get running. The biggest issue was making sure that there was enough memory available for TLS handshakes, which was solved by enabling the ESP32’s PSRAM.

Once the VPN client is running, the ESP32 can be used as an SSH jump machine to access other devices on the home network, without needing to expose those machines to the open Internet. The ESP32 also hosts an HTTP server which can send a wake-on-LAN magic packet to another device on the local network, letting unused devices sleep without impairing their availability.

The ESP32 doesn’t provide much bandwidth — streaming video would cause issues — but it works well enough for lightweight applications. If you’re wanting to stream video from an ESP32, though, it is technically possible.


hackaday.com/2026/05/18/runnin…

Cybersecurity & cyberwarfare ha ricondiviso questo.

Salute mentale, il caso italiano
@psicologia
psichiatria.it/salute-mentale-…
Salute mentale, il caso italiano Quei pazienti persi dai radar L’82,2 per cento di loro smette di frequentare le strutture senza un accordo con i medici […]
Cybersecurity & cyberwarfare ha ricondiviso questo.

The Queen Is Dead Volume 205 – Absu, Enduser, Lesotho, Putred

Absu, Enduser, Lesotho e Putred: caos rituale e metal

Absu, Enduser, Lesotho e Putred: quattro dischi tra black/death rituale, breakcore inquieta, post metal catartico e death romeno marcio. Nessuna posa.

iyezine.com/absu-enduser-lesot…

Cybersecurity & cyberwarfare ha ricondiviso questo.

Signal apre i test pubblici della verifica automatica delle chiavi


Con la beta 8.11 di Signal per Android arriva in test pubblico la verifica automatica delle chiavi crittografiche basata su key transparency. Ecco come funziona e quali sono i limiti.
The media in this post is not displayed to visitors. To view it, please go to the original post.

Verificare che una conversazione su Signal sia davvero cifrata end-to-end con la persona giusta finora ha richiesto un confronto manuale: incontrarsi di persona, confrontare i 60 numeri del safety number, oppure scansionare il QR code attraverso un canale alternativo fidato. Una procedura corretta in teoria, ma che non sempre è facile o si ha voglia di eseguire sul serio. Con la beta 8.11 di Signal per Android, in distribuzione in queste ore, lo stesso controllo inizia a essere automatico.

La funzione si chiama automatic key verification e si basa sulla key transparency, un meccanismo crittografico in sviluppo presso Signal da diverso tempo. Per provarla basta aprire il profilo di un contatto, toccare “View Safety Number” e premere il pulsante “Verify automatically”: se la verifica va a buon fine compare un segno verde con la dicitura “Encryption verified”.

Come funziona la key transparency


Il post di Signal che annuncia la feature si limita a dire che la verifica automatica è “un sistema di controlli continui effettuati da più parti, l’utente, l’interlocutore e auditor indipendenti di terze parti”. Non spiega in dettaglio cosa succede dietro le quinte. Per capire il funzionamento del sistema bisogna guardare al codice pubblicato da Signal su GitHub e alla bozza IETF di riferimento, scritta tra gli altri da un ingegnere di Signal.

Per cifrare i messaggi end-to-end, Signal deve associare a ciascun utente una chiave pubblica. Storicamente queste associazioni sono custodite sui server di Signal e fornite ai client quando serve. Il limite di questo approccio è noto: un server compromesso, o sotto pressione legale, potrebbe in teoria fornire una chiave diversa da quella reale e rendere possibile un attacco con un terzo interposto. L’app già oggi notifica all’utente i cambi di safety number, ma per capire se un cambio è legittimo, ad esempio una reinstallazione, oppure è un attacco, bisognava confrontare manualmente il numero con la controparte.

La key transparency interviene su questo punto. Dalla documentazione tecnica risulta che Signal continua a custodire le stesse informazioni di prima, ma in una struttura che non permette modifiche silenziose: ogni cambio di chiave viene aggiunto a un elenco in cui si possono solo accodare nuove voci, mai cancellare o riscrivere quelle vecchie. È come un libro contabile in cui ogni pagina è legata matematicamente a quelle precedenti, quindi strappare una pagina o riscriverla lascerebbe una traccia evidente.

A controllare che Signal non bari servono soggetti esterni, chiamati auditor. Signal ha pubblicato su GitHub il codice di un auditor di riferimento e Trail of Bits, società di sicurezza nota nel settore, ha pubblicato una propria implementazione indipendente. L’idea descritta nelle specifiche è che soggetti terzi possano scaricare in continuazione gli aggiornamenti del registro e accorgersi se i server di Signal provassero ad alterarlo o a mostrarne versioni diverse a utenti diversi.

Dal codice pubblico e dalla bozza IETF risulta che il registro non è una rubrica aperta consultabile da chiunque: la sua struttura è progettata in modo che gli auditor possano verificarne la correttezza matematica senza vedere in chiaro quali numeri sono iscritti e con quali chiavi. Chi conosce già un numero specifico può chiedere al server quale chiave gli è associata, come succede oggi quando si aggiunge un contatto a Signal, ma scaricare l’elenco completo degli iscritti non è possibile.

L’app esegue inoltre verifiche per conto proprio: controlla che la chiave del contatto sia effettivamente presente nel registro e che il registro stesso sia rimasto coerente nel tempo. Tutte queste verifiche insieme, secondo Signal, offrono la stessa garanzia di un confronto manuale del safety number, senza richiedere alcuna azione all’utente.

I limiti, e cosa succede quando non funziona


La verifica automatica non è disponibile in tutti i casi. Funziona soltanto se il client conosce il numero di telefono dell’altra parte, condizione che si verifica se la chat è stata iniziata tramite la funzione “Trova per numero”, se il contatto è in rubrica ed è raggiungibile per numero, oppure se l’interlocutore ha scelto di rendere il proprio numero visibile a tutti (l’impostazione predefinita lo nasconde a chiunque).

Anche quando funziona, può smettere di farlo per ragioni del tutto normali, come il cambio di numero della controparte. In quei casi, ricorda Signal, si torna al vecchio safety number da confrontare attraverso un canale alternativo fidato. La verifica automatica si affianca quindi al safety number manuale, non lo sostituisce del tutto.

Quando arriva in versione stabile


Per il momento la novità è confermata nel canale beta di Android. Sviluppo della key transparency è in corso da diverso tempo anche su iOS e Desktop, e la feature dovrebbe arrivare in test pubblico anche su quelle piattaforme nelle prossime settimane, anche se le release notes ufficiali delle rispettive beta in distribuzione non la menzionano esplicitamente. Signal chiede di segnalare nel forum eventuali casi in cui la verifica non risulta disponibile pur ricorrendo una delle tre condizioni descritte. Le beta servono proprio a questo prima del rilascio generale.

SOURCE:// community.signalusers.org
SOURCE:// community.signalusers.org
SOURCE:// github.com

Cybersecurity & cyberwarfare ha ricondiviso questo.

The media in this post is not displayed to visitors. To view it, please go to the original post.

CVE-2025-14177: Malicious JPEG Files Expose PHP Heap Memory — Critical Flaws in getimagesize() and iptcembed() Patched
#CyberSecurity
securebulletin.com/cve-2025-14…
Cybersecurity & cyberwarfare ha ricondiviso questo.

The media in this post is not displayed to visitors. To view it, please go to the original post.

First Public macOS Kernel Exploit on Apple M5 Bypasses Hardware Memory Protection — Developed in Just Five Days With AI Assistance
#CyberSecurity
securebulletin.com/first-publi…
Cybersecurity & cyberwarfare ha ricondiviso questo.

The media in this post is not displayed to visitors. To view it, please go to the original post.

Grafana Labs Security Breach: Hackers Steal GitHub Token, Download Private Codebase, and Demand Ransom
#CyberSecurity
securebulletin.com/grafana-lab…