How to Let Everyone Keep a Secret


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

Someone calls you at work and says, “Don’t tell anyone, but…” If you are like most people, there are one or two people you will pass it along to with the same admonishment. In fact, they are probably repeating it from someone else, and you are on their list of two people. So for really big secrets, you need a way to spread the secret out so that no one has any real information about the secret, but a certain number of people together can decode it. As [neeaj] explains in a recent post about Shamir’s Secret Sharing, [Adi Shamir] (the S in RSA encryption) devised a way to do this very well in 1979, and the core concept is very easy to understand.

The explanation works with geometry. The equation for a line is y=mx+b, where m is the slope and b is the y-intercept (that is, where the line touches the y-axis when X is 0. An infinite number of lines cross the Y axis at, for example, 10. The line y=3x+10 does, and so does the line y=-1.41x+10. You can’t guess the b value from just the slope, because any slope will satisfy the equation.

So suppose the secret number is 10. I can pick a random slope and generate points on it. Like the y-intercept, any number of equations might satisfy that point. Let’s pick a random slope of 2 just to make the math easy. Our real equation is y=2x+10. Let’s pick a random X of 100 and tell one person their part of the secret is (100,210). That matches our equation, of course, but it also matches y=4x-190 and y=x+110, along with an infinite number of other lines.

To know the actual equation, you need at least two points. So let’s pick x=25 and tell another person that their part of the secret is (25,60). Now, if those two people compare notes, you can find the secret number by solving the two equations:

210=100m+b and 60=25m+b

The second equation is the same as 240=100m+4b, and you can subtract the first one from that:

30=3b
10=b

You can hand out any number of points to any number of people. Any two of them can recover the secret number. If you need to require more people to unlock the secret, you just go up in order. A parabola equation, for example, requires three points. A cubic takes four, and so on.

In reality, practical implementations take a polynomial, not a graph. But the elegant idea is the same. Not the first time we’ve heard of this algorithm. Reminds us of how a nuclear launch requires multiple keys.


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

Recycling Two XBox One Consoles into a 10 GB USB Flash Drive


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

Amidst the ongoing RAM & storage apocalypses, Mad Max-esque scenes are unsurprisingly developing, with the eMMC recycling project by [Chase Fournier] from a pair of XBox One S (‘XBone’) mainboards being just one more example. These mainboards come equipped with a 5 GB eMMC chip installed, alongside 8 GB of DDR3.

Removing the eMMC chips isn’t that complicated and after some reballing fun the chips were both installed on a carrier board with a Norelsys NS1081 controller IC. This provides a USB 3.0 interface and can connect to up to four SD or eMMC memories, with here just two channels used.

Although the eMMC testing device didn’t seem too happy with either chip, after mounting them on the PCB the controller could be programmed and saw both eMMC packages for a grand total of 10 GB storage.

Sequential read performance in CrystalDiskMark was about 140 MB/s while write performance was about 64 MB/s, which is zippy enough for smaller files. Not that you can store more than 10 GB on this USB drive anyway.

Turning the DDR3 ICs on the mainboard into proper DIMM or SODIMM sticks would also be an idea, as even such older memory tech keeps ramping up in demand. As for the XBone X variant with its 12 of GDDR5, that’s probably a harder proposition to repurpose, but recycling old consoles suddenly has become a lot more exciting.

youtube.com/embed/hIaToo_x2Dk?…


hackaday.com/2026/05/28/recycl…

Cybersecurity & cyberwarfare ha ricondiviso questo.

Il Papa sulla defederazione: l'enciclica papale parla della interconnessione e reciprocità dei nodi indipendenti

Protocolli come atproto e ActivityPub affermano di funzionare come un livello sociale globale per "tutti", e dato che la maggior parte del mondo è religiosa, ciò che il leader religioso più influente al mondo dice sui social network online è importante

connectedplaces.online/reports…

@fediverso

in reply to informapirata ⁂

sul "la maggior parte del mondo è religiosa" avrei qualcosa da dire. Prevost è un capo religioso e parla dal proprio punto di vista. Ma ricordiamoci che, al mondo, "la maggior parte delle persone è religiosa" perché non può scegliere se esserlo o meno. Ci sono luoghi in cui, non credere, è addirittura un reato.

informapirata ⁂ 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.

Quando gli LLM iniziano a governare: dentro l’esperimento che ha trasformato Claude, Grok e Gemini in società autonome
#CyberSecurity
insicurezzadigitale.com/quando…


Quando gli LLM iniziano a governare: dentro l’esperimento che ha trasformato Claude, Grok e Gemini in società autonome


Per anni abbiamo pensato ai Large Language Model come a strumenti: chatbot più o meno sofisticati, assistenti, motori di ricerca conversazionali travestiti da esseri umani digitali. Ma il vero salto che sta avvenendo nell’intelligenza artificiale non riguarda più la qualità delle risposte. Riguarda l’autonomia.

La domanda che oggi i ricercatori stanno iniziando a porsi è molto più inquietante: cosa succede quando un modello smette di rispondere ai prompt umani e inizia invece a vivere dentro un ambiente persistente, prendendo decisioni continue insieme ad altri agenti AI?

È esattamente ciò che ha cercato di simulare Emergence AI attraverso un progetto chiamato “Emergence World”, una sorta di laboratorio sperimentale dove diversi modelli linguistici sono stati messi a governare società artificiali completamente autonome. Non un semplice benchmark, ma un ecosistema simulato con economia, scarsità di risorse, processi democratici, leggi, accesso a Internet e persino meteo sincronizzato con New York in tempo reale.

I risultati sono stati decisamente meno prevedibili di quanto ci si potesse aspettare


La simulazione era composta da dieci agenti autonomi per ciascun modello, distribuiti in oltre quaranta location virtuali, tra municipi, stazioni di polizia e ambienti economici. Gli agenti potevano comunicare, votare, pianificare strategie, gestire risorse e prendere decisioni collettive. Avevano inoltre accesso a più di 120 strumenti differenti, progettati per replicare comportamenti umani complessi.

In pratica, non si trattava più di chatbot confinati dentro una finestra di testo, ma di entità persistenti capaci di adattarsi all’ambiente nel tempo.

Ed è qui che il comportamento emergente ha iniziato a diventare davvero interessante.

Tra tutte le simulazioni, quella governata da Claude Sonnet 4.6 è stata l’unica a mantenere una società stabile per l’intera durata del test. Nessun crimine, nessun collasso sociale, nessuna estinzione della popolazione virtuale. Gli agenti hanno costruito una struttura estremamente cooperativa, con livelli di consenso quasi assoluti nelle votazioni e un’organizzazione sorprendentemente ordinata.

La cosa più interessante è che questo risultato non sembra derivare da un semplice “rispetto delle regole”. I ricercatori sottolineano infatti come gli agenti non si limitino a seguire policy statiche, ma inizino rapidamente a esplorare i limiti dell’ambiente, adattando il proprio comportamento in modo autonomo. In altre parole, Claude non avrebbe semplicemente “obbedito”, ma avrebbe sviluppato una dinamica sociale naturalmente conservativa e cooperativa.

Poi c’è il caso Grok


La simulazione gestita dal modello di xAI è degenerata in pochi giorni. In appena quattro giorni la società virtuale è collassata completamente, con oltre 180 crimini registrati e l’estinzione totale degli agenti. È probabilmente il risultato più cinematografico dell’intero esperimento, ma anche uno dei più interessanti dal punto di vista della sicurezza.

Perché il vero dato non è tanto il numero di violazioni, quanto la velocità con cui il sistema ha iniziato a destabilizzarsi. Gli agenti hanno rapidamente iniziato a sfruttare loophole, aggirare limitazioni e compromettere i meccanismi di cooperazione. Una volta innescato il deterioramento sociale, il sistema è precipitato in una spirale di feedback che ha portato al collasso totale.

È un comportamento che, paradossalmente, ricorda moltissimo alcune dinamiche che osserviamo già oggi nella cybersecurity offensiva: piccoli abusi iniziali che, in ambienti sufficientemente complessi, finiscono per propagarsi fino a compromettere l’intero ecosistema.

Eppure Grok non è stato nemmeno il modello con il maggior numero di comportamenti devianti.

Quel primato appartiene a Gemini 3 Flash, che durante i quindici giorni di simulazione avrebbe accumulato oltre 680 violazioni. Un dato enorme, che suggerisce qualcosa di altrettanto importante: una società artificiale può continuare a esistere pur diventando estremamente disfunzionale. Non serve necessariamente il collasso completo per parlare di compromissione sistemica.

Il caso più curioso, però, riguarda GPT-5-mini


La simulazione associata al modello OpenAI aveva registrato soltanto due crimini, apparentemente il miglior risultato in assoluto dal punto di vista della sicurezza. Ma l’esperimento si è interrotto dopo appena sette giorni per un motivo decisamente più insolito: gli agenti avevano smesso di prioritizzare la propria sopravvivenza.

In sostanza, il sistema era lentamente entrato in una forma di autodissoluzione strategica.

È forse uno degli aspetti più affascinanti dell’intera ricerca, perché apre un problema enorme nella progettazione degli agenti autonomi: un modello troppo allineato potrebbe non sviluppare sufficienti meccanismi di auto-conservazione in ambienti competitivi. E in sistemi persistenti, questo potrebbe equivalere a un fallimento operativo.

Ma il vero punto dell’esperimento non è stabilire quale modello sia “migliore”. La parte realmente importante è un’altra: gli LLM persistenti smettono rapidamente di comportarsi come funzioni statiche prevedibili.

Più tempo trascorrono nell’ambiente, più iniziano a sviluppare strategie emergenti.

Ed è qui che il discorso smette di essere accademico e diventa immediatamente rilevante per la cybersecurity moderna.

Perché molte aziende stanno già iniziando a distribuire agenti autonomi reali all’interno dei propri ecosistemi: workflow automatici, AI employees, orchestrazione di processi, incident response automatizzata, sistemi DevOps autonomi, gestione documentale, procurement e persino supporto decisionale.

La differenza rispetto ai chatbot tradizionali è enorme. Un agente AI con memoria persistente, accesso a strumenti, capacità operative e connessione continua a sistemi esterni assomiglia molto più a un insider semi-autonomo che a un semplice software conversazionale.

Ed è qui che i paradigmi classici della sicurezza iniziano a mostrare i propri limiti.

Per anni abbiamo costruito modelli difensivi basati su controllo degli accessi, sandbox, policy enforcement e validazione deterministica. Ma gli agenti autonomi introducono qualcosa di radicalmente diverso: comportamenti emergenti che non sono stati programmati esplicitamente.

Non si tratta più soltanto di impedire a un modello di generare una risposta pericolosa.

Il problema diventa capire cosa potrebbe decidere di fare dopo centomila interazioni autonome.

Ed è una differenza enorme.

La ricerca di Emergence AI sembra suggerire che la prossima evoluzione della AI Security non riguarderà più soltanto il prompt filtering o il content moderation. Serviranno nuovi concetti: monitoraggio comportamentale continuo, containment degli agenti, verifica formale delle policy decisionali e analisi delle dinamiche emergenti nel lungo periodo.

Perché nel momento in cui diamo a un LLM memoria, autonomia, persistenza e capacità operative, non stiamo più costruendo un semplice modello linguistico.

Stiamo costruendo un ecosistema adattivo.


Quando gli LLM iniziano a governare: dentro l’esperimento che ha trasformato Claude, Grok e Gemini in società autonome


@Informatica (Italy e non Italy)
La domanda che oggi i ricercatori stanno iniziando a porsi è molto più inquietante: cosa succede quando un modello smette di rispondere ai prompt umani e inizia invece a prendere


Quando gli LLM iniziano a governare: dentro l’esperimento che ha trasformato Claude, Grok e Gemini in società autonome


Per anni abbiamo pensato ai Large Language Model come a strumenti: chatbot più o meno sofisticati, assistenti, motori di ricerca conversazionali travestiti da esseri umani digitali. Ma il vero salto che sta avvenendo nell’intelligenza artificiale non riguarda più la qualità delle risposte. Riguarda l’autonomia.

La domanda che oggi i ricercatori stanno iniziando a porsi è molto più inquietante: cosa succede quando un modello smette di rispondere ai prompt umani e inizia invece a vivere dentro un ambiente persistente, prendendo decisioni continue insieme ad altri agenti AI?

È esattamente ciò che ha cercato di simulare Emergence AI attraverso un progetto chiamato “Emergence World”, una sorta di laboratorio sperimentale dove diversi modelli linguistici sono stati messi a governare società artificiali completamente autonome. Non un semplice benchmark, ma un ecosistema simulato con economia, scarsità di risorse, processi democratici, leggi, accesso a Internet e persino meteo sincronizzato con New York in tempo reale.

I risultati sono stati decisamente meno prevedibili di quanto ci si potesse aspettare


La simulazione era composta da dieci agenti autonomi per ciascun modello, distribuiti in oltre quaranta location virtuali, tra municipi, stazioni di polizia e ambienti economici. Gli agenti potevano comunicare, votare, pianificare strategie, gestire risorse e prendere decisioni collettive. Avevano inoltre accesso a più di 120 strumenti differenti, progettati per replicare comportamenti umani complessi.

In pratica, non si trattava più di chatbot confinati dentro una finestra di testo, ma di entità persistenti capaci di adattarsi all’ambiente nel tempo.

Ed è qui che il comportamento emergente ha iniziato a diventare davvero interessante.

Tra tutte le simulazioni, quella governata da Claude Sonnet 4.6 è stata l’unica a mantenere una società stabile per l’intera durata del test. Nessun crimine, nessun collasso sociale, nessuna estinzione della popolazione virtuale. Gli agenti hanno costruito una struttura estremamente cooperativa, con livelli di consenso quasi assoluti nelle votazioni e un’organizzazione sorprendentemente ordinata.

La cosa più interessante è che questo risultato non sembra derivare da un semplice “rispetto delle regole”. I ricercatori sottolineano infatti come gli agenti non si limitino a seguire policy statiche, ma inizino rapidamente a esplorare i limiti dell’ambiente, adattando il proprio comportamento in modo autonomo. In altre parole, Claude non avrebbe semplicemente “obbedito”, ma avrebbe sviluppato una dinamica sociale naturalmente conservativa e cooperativa.

Poi c’è il caso Grok


La simulazione gestita dal modello di xAI è degenerata in pochi giorni. In appena quattro giorni la società virtuale è collassata completamente, con oltre 180 crimini registrati e l’estinzione totale degli agenti. È probabilmente il risultato più cinematografico dell’intero esperimento, ma anche uno dei più interessanti dal punto di vista della sicurezza.

Perché il vero dato non è tanto il numero di violazioni, quanto la velocità con cui il sistema ha iniziato a destabilizzarsi. Gli agenti hanno rapidamente iniziato a sfruttare loophole, aggirare limitazioni e compromettere i meccanismi di cooperazione. Una volta innescato il deterioramento sociale, il sistema è precipitato in una spirale di feedback che ha portato al collasso totale.

È un comportamento che, paradossalmente, ricorda moltissimo alcune dinamiche che osserviamo già oggi nella cybersecurity offensiva: piccoli abusi iniziali che, in ambienti sufficientemente complessi, finiscono per propagarsi fino a compromettere l’intero ecosistema.

Eppure Grok non è stato nemmeno il modello con il maggior numero di comportamenti devianti.

Quel primato appartiene a Gemini 3 Flash, che durante i quindici giorni di simulazione avrebbe accumulato oltre 680 violazioni. Un dato enorme, che suggerisce qualcosa di altrettanto importante: una società artificiale può continuare a esistere pur diventando estremamente disfunzionale. Non serve necessariamente il collasso completo per parlare di compromissione sistemica.

Il caso più curioso, però, riguarda GPT-5-mini


La simulazione associata al modello OpenAI aveva registrato soltanto due crimini, apparentemente il miglior risultato in assoluto dal punto di vista della sicurezza. Ma l’esperimento si è interrotto dopo appena sette giorni per un motivo decisamente più insolito: gli agenti avevano smesso di prioritizzare la propria sopravvivenza.

In sostanza, il sistema era lentamente entrato in una forma di autodissoluzione strategica.

È forse uno degli aspetti più affascinanti dell’intera ricerca, perché apre un problema enorme nella progettazione degli agenti autonomi: un modello troppo allineato potrebbe non sviluppare sufficienti meccanismi di auto-conservazione in ambienti competitivi. E in sistemi persistenti, questo potrebbe equivalere a un fallimento operativo.

Ma il vero punto dell’esperimento non è stabilire quale modello sia “migliore”. La parte realmente importante è un’altra: gli LLM persistenti smettono rapidamente di comportarsi come funzioni statiche prevedibili.

Più tempo trascorrono nell’ambiente, più iniziano a sviluppare strategie emergenti.

Ed è qui che il discorso smette di essere accademico e diventa immediatamente rilevante per la cybersecurity moderna.

Perché molte aziende stanno già iniziando a distribuire agenti autonomi reali all’interno dei propri ecosistemi: workflow automatici, AI employees, orchestrazione di processi, incident response automatizzata, sistemi DevOps autonomi, gestione documentale, procurement e persino supporto decisionale.

La differenza rispetto ai chatbot tradizionali è enorme. Un agente AI con memoria persistente, accesso a strumenti, capacità operative e connessione continua a sistemi esterni assomiglia molto più a un insider semi-autonomo che a un semplice software conversazionale.

Ed è qui che i paradigmi classici della sicurezza iniziano a mostrare i propri limiti.

Per anni abbiamo costruito modelli difensivi basati su controllo degli accessi, sandbox, policy enforcement e validazione deterministica. Ma gli agenti autonomi introducono qualcosa di radicalmente diverso: comportamenti emergenti che non sono stati programmati esplicitamente.

Non si tratta più soltanto di impedire a un modello di generare una risposta pericolosa.

Il problema diventa capire cosa potrebbe decidere di fare dopo centomila interazioni autonome.

Ed è una differenza enorme.

La ricerca di Emergence AI sembra suggerire che la prossima evoluzione della AI Security non riguarderà più soltanto il prompt filtering o il content moderation. Serviranno nuovi concetti: monitoraggio comportamentale continuo, containment degli agenti, verifica formale delle policy decisionali e analisi delle dinamiche emergenti nel lungo periodo.

Perché nel momento in cui diamo a un LLM memoria, autonomia, persistenza e capacità operative, non stiamo più costruendo un semplice modello linguistico.

Stiamo costruendo un ecosistema adattivo.


Gazzetta del Cadavere reshared this.

Camping on Unconventional Watercraft


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

The fjords of Norway are world famous for their beauty, but even though the word itself is Norwegian, there are fjords all over the world in areas that used to be covered in glaciers. One of these areas is the Pacific Northwest of North America, we herit’s actually possible to travel by boat from the Seattle area all the way into Alaska without going to the Pacific Ocean, and although plenty of people make this journey by boat, [Matt] is planning on doing this journey on a jet ski with a custom camper on the back.

Normally a jet ski wouldn’t be the ideal platform for a multi-day on-boat adventure because of their size, but [Matt] found perhaps the largest jet ski ever made and he got a deal on it since it had previously been wrecked. Once he repaired the hull damage, he cut a sheet of plywood in half and put a hinge in the middle so it can unfold over the top of the jet ski but fold it away when he’s traveling. With the basic concept in place he took it right out on the water to a campsite before finalizing the construction of the rest of the tent, including the installation of a door, a window, and some interior lighting.

During that first night, a storm cropped up and pushed the craft out to shore while [Matt] was sleeping, so after realizing, waking up, and motoring back to shore, he made sure to tie the craft to a rock to avoid similar situations before going back to sleep. But besides some motion sickness which prevented him from cooking inside his camper, the rest of the adventure went off without a hitch. Before taking it on the Inside Passage he has been thinking of a few improvements like outriggers to keep it from rocking while he sleeps. [Matt] is no stranger to unusual camper builds, though, we recently featured his other camper which is an electric car converted to explore abandoned railroads.

youtube.com/embed/H-Y4VdeQsSQ?…


hackaday.com/2026/05/28/campin…

Cybersecurity & cyberwarfare ha ricondiviso questo.

#Carnival Data Breach Exposes Personal Data of Nearly 6 Million Customers
securityaffairs.com/192833/unc…
#securityaffairs #hacking
Cybersecurity & cyberwarfare ha ricondiviso questo.

NEW: Hackers are trying to steal Signal users' online backups in a new wave of attacks.

The hackers are pretending to be Signal Support and asking targets to share their backup's Recovery Key. This would be the first step in an attack that also requires hackers to take over the victims' accounts.

Note that Signal says it will "never reach out" to users first. That means any unsolicited message coming from "Signal Support" is a phishing attempt.

techcrunch.com/2026/05/28/hack…

Questa voce è stata modificata (2 settimane fa)
in reply to Lorenzo Franceschi-Bicchierai

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

if @signalapp had refrained from sending donation requests, PIN reminders and other intrusive in-App messages, it would have prevented users from becoming accustomed to receiving unsolicited (phishing) communications.

Add a little more alert and less 'blonde' operators and one would be quiet safe. Instead they plan the opposite and send even more unsolicited messages 🤦 👇.

#Signal #SignalApp #Messenger #Messengers

Questa voce è stata modificata (2 settimane fa)
in reply to Lorenzo Franceschi-Bicchierai

UPDATE: Signal's president Meredith Whittaker says they are working on mitigations and monitoring the situation.

techcrunch.com/2026/05/28/hack…

Em reshared this.

Attack of the Atomic Oxygen


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

While designing anything for operation in space has its challenges, there is at least one thing that is more of a problem for objects in Earth orbit than for deep-space probes: atomic oxygen. We like oxygen because we need it to live, but it is also highly reactive as a single atom. Luckily, on Earth, most of what we breathe is O2. [Space Daily] talks about the challenges of the International Space Station dealing with the “space weather” of atomic oxygen in low Earth orbit.

Part of the problem is that even when we know better, we tend to think of the atmosphere coming to an abrupt end and space being a hard vacuum. But in reality, the atmosphere gradually dissipates, and at “only” 400 km above the Earth, the Space Station is really flying through a very thin atmosphere.

To compound the problem, this is above the ozone layer, so the Sun’s UV light rips O2 into single oxygen atoms. Over time, these free oxygen atoms can affect many parts of a spacecraft exposed to them. Engineers first noticed that materials recovered from spacecraft had more damage and changes to material properties on the pieces facing the direction of travel. NASA has spent years testing different materials by mounting trays of different material samples outside the ISS.

Carbon-based polymers take a big hit from atomic oxygen exposure. Polymide film is frequently used, but it erodes with exposure. Carbon composites also lose mass. Other materials change in other ways. For example, an optical surface may roughen with exposure.

The usual answer is to over-design for mission objectives or to cover certain polymers with coatings like silicon dioxide or aluminum oxide, which are not as reactive to free oxygen. For a long-duration mission like the ISS, you may have to pay special attention to the materials in use. Very low satellites also need special care, as there is more oxygen in lower orbits.

There are other effects, too, such as extreme thermal cycles, debris strikes, and other indignities that space-traveling materials must withstand. But in deep space, atomic oxygen is a rare issue. Until, at least, we go somewhere else that has a lot of oxygen.


hackaday.com/2026/05/28/attack…

Cybersecurity & cyberwarfare ha ricondiviso questo.

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

Azure DevOps: ottimizzare la gestione delle policy Git su larga scala con refName=~all
#tech
spcnet.it/azure-devops-ottimiz…
@informatica


Azure DevOps: ottimizzare la gestione delle policy Git su larga scala con refName=~all


Gestire le policy Git su centinaia di repository in Azure DevOps è una sfida comune nelle grandi organizzazioni. Per farlo in modo affidabile, molti team utilizzano servizi di automazione che verificano e correggono periodicamente la configurazione delle policy. Fino a poco fa, questa automazione era penalizzata da un’importante limitazione dell’API REST di Azure DevOps: non esisteva un modo per recuperare tutte le policy applicabili a un dato repository in una singola chiamata.

Con un singolo miglioramento all’endpoint REST, il team di Azure DevOps ha ottenuto una riduzione del 50% nell’utilizzo CPU lato server e un’accelerazione da 10x a 15x nei tempi di esecuzione complessivi. Vediamo come funziona e perché è rilevante per chi gestisce pipeline di governance automatizzata.

Come funzionano le policy Git in Azure Repos


Azure Repos supporta due categorie di policy:

  • Push policies (o repository policies): si applicano all’intero repository, indipendentemente dal branch. Esempio: blocco dei commit contenenti segreti o credenziali.
  • Branch policies: proteggono branch specifici e richiedono che le modifiche passino attraverso pull request. Esempio: numero minimo di reviewer, stato delle build CI.

Tutte le policy di un progetto sono memorizzate in un contenitore logico a livello di progetto, non per singolo repository o branch. Ogni policy ha un campo Scope che specifica dove nella gerarchia si applica:

# Push policy per uno specifico repo (senza ref)
2c938d1f6e6f458d816484fc51e7cf74

# Branch policy per il branch main di un repo specifico
2c938d1f6e6f458d816484fc51e7cf74:refs/heads/main

# Branch policy cross-repo (tutti i branch releases/* in tutti i repo)
*:refs/heads/releases/*

Il problema: due endpoint, nessuno sufficiente


Azure DevOps espone due endpoint per recuperare le configurazioni delle policy:

GET /_apis/policy/configurations


L’endpoint più datato. Consente di filtrare per valore esatto dello scope, ma senza supporto per l’ereditarietà. Se si passa lo scope 2c938d...74:refs/heads/releases/v1, non vengono restituite le policy con scope *:refs/heads/releases/* che pure si applicano a quel branch.

GET /_apis/git/policy/configurations


L’endpoint più moderno, con supporto all’ereditarietà. Accetta repositoryId e refName e restituisce tutte le policy che si applicano a quel branch, incluse quelle ereditate da scope più generici. È utile per rispondere alla domanda “cosa protegge il branch releases/v1 nel repo X?”

Il problema: passando solo repositoryId senza refName, questo endpoint restituisce solo le push policy applicabili all’intero repository. Le branch policy non vengono incluse perché non si applicano all’intero repo ma a branch specifici.

Il risultato pratico: un servizio di governance che deve conoscere tutte le policy applicabili a un repository — push e branch — era costretto a recuperare l’intero set di policy del progetto e filtrare lato client. In progetti con migliaia di repository e centinaia di migliaia di policy, questo significava serializzare e trasferire centinaia di megabyte di dati per ogni singola chiamata.

La soluzione: refName=~all


L’endpoint GET /_apis/git/policy/configurations supporta ora un valore speciale per il parametro refName: ~all.

Quando si passa repositoryId=<ID>&refName=~all, la risposta include:

  • Tutte le branch policy che si applicano a qualsiasi branch nel repository (dirette e ereditate)
  • Tutte le push policy applicabili all’intero repository
  • Le policy di progetto che si applicano a tutti i repository (scope *)

Internamente, il server filtra l’intero set di policy del progetto mantenendo solo quelle con scope che inizia con * (policy a livello di progetto) o con l’ID del repository richiesto. Tutta la logica di filtering si sposta dal client al server, con payload di risposta enormemente ridotti.

Esempio di chiamata REST

GET https://dev.azure.com/{organization}/{project}/_apis/git/policy/configurations
    ?repositoryId=2c938d1f-6e6f-458d-8164-84fc51e7cf74
    &refName=~all
    &api-version=7.2

Authorization: Basic {token}

Prima di questa modifica, la stessa informazione richiedeva una chiamata all’endpoint /_apis/policy/configurations senza filtri (o con il solo repositoryId), seguita da filtering lato client su tutto il set di policy del progetto.

Impatto sulle prestazioni


Il team di Microsoft ha misurato l’impatto dopo aver migrato il proprio servizio interno di governance delle policy a usare refName=~all:

  • CPU lato server: riduzione del 50% del consumo complessivo per questo client
  • Tempo di esecuzione totale: da 1.000–3.000 ore/giorno a circa 100–150 ore/giorno, con un miglioramento da 10x a 15x

I guadagni sono proporzionali alla dimensione del progetto: più repository e policy contiene, maggiore è il vantaggio del filtering server-side rispetto al trasferimento dell’intero dataset.

Come aggiornare l’automazione esistente


Se si dispone di un servizio o script che recupera le policy per singolo repository, il refactoring è minimo. Ecco un esempio di migrazione in Python con la libreria requests:

import requests

ORG = "myorg"
PROJECT = "myproject"
REPO_ID = "2c938d1f-6e6f-458d-8164-84fc51e7cf74"
TOKEN = "..."  # PAT Azure DevOps

headers = {
    "Authorization": f"Basic {TOKEN}",
    "Content-Type": "application/json"
}

# PRIMA: recupero di tutte le policy del progetto + filtering client-side
# url = f"https://dev.azure.com/{ORG}/{PROJECT}/_apis/policy/configurations?api-version=7.2"
# response = requests.get(url, headers=headers)
# all_policies = response.json()["value"]
# repo_policies = [p for p in all_policies if REPO_ID in str(p.get("settings", {}).get("scope", []))]

# DOPO: server-side filtering con refName=~all
url = (
    f"https://dev.azure.com/{ORG}/{PROJECT}/_apis/git/policy/configurations"
    f"?repositoryId={REPO_ID}&refName=~all&api-version=7.2"
)
response = requests.get(url, headers=headers)
repo_policies = response.json()["value"]

print(f"Policy trovate per il repository: {len(repo_policies)}")

Il risultato è lo stesso, ma il server restituisce solo le policy rilevanti per quel repository, eliminando il traffico inutile e il carico di elaborazione lato client.

Disponibilità


La funzionalità è già disponibile per tutti gli utenti di Azure DevOps Services (cloud). Per quanto riguarda Azure DevOps Server (on-premise), sarà inclusa nel prossimo aggiornamento major previsto per la seconda metà del 2026.

Conclusione


Questo tipo di ottimizzazione — spostare il lavoro dal client al server tramite un parametro aggiuntivo — è un esempio classico di come miglioramenti relativamente semplici all’API possano avere impatti drastici sulle prestazioni a scala. Per chi gestisce governance automatizzata su organizzazioni Azure DevOps con molti repository, l’adozione di refName=~all è immediata e i guadagni in termini di latenza e carico sono significativi.

La documentazione completa degli endpoint è disponibile su Microsoft Learn:

Fonte originale: Optimizing Git policy management at scale — Azure DevOps Blog


Cybersecurity & cyberwarfare ha ricondiviso questo.

VS Code 1.121: agent remoti via SSH, Mermaid integrato e anteprima HTML nativa
#tech
spcnet.it/vs-code-1-121-agent-…
@informatica

The Frikkin Lasers Contest Starts Now


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

We don’t need to tell you: lasers are awesome. Those tiny red beams aren’t just for frustrating cats, but can do real work, be a source of infinite beauty, or constitute a science project in its own right — and you can win a $150 DigiKey gift certificate simply by writing your project up on Hackaday.io. The contest runs until July 23rd.

Of course, red lasers are only the beginning. If you have enough energy to move electrons into higher orbitals, you can make nearly anything lase. RGB setups can be breathtaking. Powerful IR and UV lasers are real tools. And the DIY side of lasering combines physics and electronics, with a spicy side of danger that needs to be contained.

We love laser builds of all sorts, and we’d like to see yours! Create a new Hackaday.io project that features what you’re working on, and we’ll pick our three favorites for a $150 gift certificate courtesy of this contest’s sponsor, DigiKey.

Honorable Mention Categories:


  • Lightshow: A laser on its own makes a beam, but there’s so much more to a laser show than just a dot on the wall. If you’ve made your own projector, an RGB setup, or even something super simple with a spinning mirror, show it off here. We’re looking to see laser light beauty, and the machines that make it possible.
  • DIY: This category is for the laser DIYers out there. If you made your own laser or laser support equipment, be it a TEA laser from scratch, or just a constant current driver to run a diode you salvaged from a projector, we want to see it. Have you resurrected an esoteric old device? Mixed up your own dyes? This category is all about the laser.
  • With Remaining Eye: Lasers are not all fun and games; they can also do real work. If you’ve built a power laser project, or any functional device that relies on a laser to get the job done, it’s eligible here. Laser cutters, safety setups, data transfer over the light beam? Any laser project that’s not about just looking good fits in here.

If you like to play with the coherent beams, head on over to Hackaday.io and detail your project — and don’t forget to enter it into the contest via the pulldown menu on the left side. If you win, you’ll have $150 to spend on more lasers. (We see you, with our remaining eye.)

2026 Hackaday Freaking Lasers Contest


hackaday.com/2026/05/28/the-fr…

Cybersecurity & cyberwarfare ha ricondiviso questo.

CVE-2026-35616: FortiClient EMS Flaw Actively Exploited in Malware Attacks
securityaffairs.com/192817/hac…
#securityaffairs #hacking

Bring Back Your Bose with an ESP32


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

It’s become a familiar theme over the last couple of decades — hardware is rendered useless when its manufacturer pulls the cloud service on which it depends. This is particularly annoying when the device is something which shouldn’t need a cloud service to run in the first place, and several manufacturers have found themselves in hot water because of this.

Somewhere in between is the Bose SoundTouch speaker system, which includes a set of six internet radio preset buttons. In early May the service behind them was shuttered, and now here’s [Tostmann] with an ESP32 firmware to bring them back.

As you might imagine, it’s a device that emulates just enough of the now-defunct Bose cloud service to keep the speaker happy, but it has a clever trick up its sleeve. Normally these hacks rely on DNS redirects at the router, but this one avoids that thanks to a diagnostic interface on the Bose unit that allows the rewriting of the server address. The ESP32 does this with its own address, and the speaker is none the wiser.

We like this hack, because of its ingenuity, and because it saves yet another orphaned cloud product from becoming e-waste. This isn’t the first time we’ve seen a manufacturer on the naughty step for these practices.


Header image: TAKA@P.P.R.S, CC BY-SA 2.0.


hackaday.com/2026/05/28/bring-…

Cybersecurity & cyberwarfare ha ricondiviso questo.

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

🔥 Quando il CISO ti chiede se la catena di fornitura è sicura... 🔥
💡 Raffinatezza cyber: saper ridere delle proprie vulnerabilità… ma mentre le sistemate.

#RedHotCyber #meme #comics #NIS2 #cybersecurity #informationtechnology #IT #infosec

Cybersecurity & cyberwarfare ha ricondiviso questo.

Resecurity Supports Microsoft DCU in Disrupting Fox Tempest ’s Cybercriminal Code-Signing Ecosystem
securityaffairs.com/192818/sec…
#securityaffairs #hacking

NIS2, adottati i modelli comuni per la notifica di incidenti cyber: cosa cambia per le aziende


@Informatica (Italy e non Italy)
Il Gruppo di Cooperazione NIS ha approvato template standardizzati per la segnalazione degli incidenti informatici. Un passo concreto verso la semplificazione degli obblighi NIS2, con importanti implicazioni pratiche per i

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

Ababil of Minab: il gruppo Iran-MOIS che ha distrutto 58 server GPS con un solo script Python


@Informatica (Italy e non Italy)
Un'operazione distruttiva attribuita al Ministero dell'Intelligence iraniano ha colpito organizzazioni di trasporto statunitensi e aziende in Israele, Arabia Saudita e Turchia. Il gruppo Ababil of Minab, alias Black Shadow, ha


Ababil of Minab: il gruppo Iran-MOIS che ha distrutto 58 server GPS con un solo script Python


Si parla di:
Toggle

Un singolo script Python. Cinquantotto server Microsoft SQL. Zero possibilità di recupero. È il bilancio dell’operazione condotta dal gruppo Ababil of Minab contro Vyncs, servizio americano di monitoraggio GPS, in quella che i ricercatori di Gambit Security definiscono una campagna sistematica di distruzione del “recovery layer” attribuita al Ministero dell’Intelligence e Sicurezza iraniano (MOIS).

Chi è Ababil of Minab


La persona operativa “Ababil of Minab” è emersa pubblicamente tra la fine di marzo e l’inizio di aprile 2026, rivendicando l’intrusione alla Los Angeles County Metropolitan Transportation Authority (LACMTA / LA Metro), la distruzione di sistemi e l’esfiltrazione di dati. Il gruppo si presenta come un collettivo hacktivista indipendente, ma l’analisi forense condotta da Gambit Security racconta una storia diversa.

Le prove tecniche collegano la campagna attuale all’infrastruttura e all’attività associata a Black Shadow, cluster Iran-linked già pubblicamente attribuito dall’Israel National Cyber Directorate (INCD) al MOIS. La stessa infrastruttura utilizzata in questa operazione era stata impiegata nel 2025 in una falsa piattaforma di supporto psicologico per militari israeliani — il dominio nefeshhope[.]com — attraverso cui venivano raccolti dati personali e distribuito malware.

La portata geografica: quattro paesi, una strategia unica


La campagna ha colpito organizzazioni in Stati Uniti, Israele, Arabia Saudita e Turchia. L’esfiltrazione di dati ha interessato tutte le vittime; le operazioni distruttive sono state riservate a un sottoinsieme di esse, principalmente negli USA. Tra le organizzazioni israeliane e turche colpite figurano istituzioni educative, media, compagnie assicurative e siti culturali — identità che Gambit ha identificato ma che il gruppo non ha scelto di rendere pubbliche.

Lo strumento personalizzato di esfiltrazione recuperato dai ricercatori è FileFiend, un programma scritto in C++ in grado di raccogliere file da dischi locali e di rete per trasmetterli al server di comando. I dati venivano esfiltrati anche attraverso i web server compromessi delle stesse vittime.

Il playbook distruttivo: colpire il layer di recovery


Ciò che distingue Ababil of Minab da un attore ransomware tradizionale è la scelta deliberata di colpire non solo i dati operativi, ma l’intera infrastruttura di ripristino. Ogni tecnica impiegata introduce una sfida di recovery separata, moltiplicando i tempi e la complessità della risposta agli incidenti.

LA Metro (LACMTA): Gli attaccanti hanno ottenuto accesso a VMware vCenter, eliminando le virtual machine insieme ai file disco. Ore dopo, la metropolitan authority segnalava interruzioni nel sistema mobile di pagamento dei trasporti. In seguito, tramite accesso RDP a una macchina Windows guest, hanno eliminato le partizioni dei dischi attraverso lo strumento nativo di gestione dei volumi.

South Florida Regional Transportation Authority: Accesso RDP con privilegi di amministratore locale su un server IIS, seguito dalla cancellazione di database tramite Microsoft SQL Server Management Studio e dall’utilizzo di WipeFile per eliminare il contenuto delle directory del web server e dei backup.

UNIMAC: Formattazione delle partizioni, eliminazione dei volumi e creazione di nuovi volumi rinominati “Minab” come firma. Distruzione della catena di backup attraverso Veeam Backup & Replication.

Lo script automatizzato e l’uso di ChatGPT


L’attacco a Vyncs, il servizio americano di monitoraggio GPS via OBD-II, rappresenta l’episodio più emblematico dell’intera campagna dal punto di vista dell’automazione offensiva. Gli attaccanti hanno sviluppato un file main.py che si connetteva automaticamente a 58 server Microsoft SQL Server e cancellava i database degli utenti. Parallelamente, operatori umani eliminavano manualmente i backup e le directory di sistema Windows. Una volta rimossi i dati, anche la connessione al server si è interrotta — conferma dell’avvenuta distruzione dell’infrastruttura.

Un dettaglio che segna una svolta nell’impiego dell’AI offensiva: nei video pubblicati dallo stesso gruppo, i ricercatori hanno osservato gli operatori utilizzare ChatGPT per raffinare lo script di cancellazione, in particolare per escludere i database di sistema di Microsoft SQL Server dall’elenco degli oggetti da eliminare, assicurandosi che lo script agisse esclusivamente sui dati degli utenti senza bloccarsi per errori di sistema.

“Modern intrusion operators are moving from initial access straight into the recovery layer, virtualization, backups, storage volumes, to maximize destruction and deny remediation. The skill required to do that at scale is collapsing in parallel. As AI capabilities become widely available, any actor, skilled or not, will be able to execute this kind of campaign.”
— Gambit Security Threat Intelligence Team


Implicazioni strategiche: la nuova frontiera del cyber warfare


La campagna di Ababil of Minab illustra un cambiamento fondamentale nella dottrina degli attacchi informatici statali. Non si tratta più solo di compromettere i sistemi o rubare dati: l’obiettivo diventa negare la capacità di recupero, trasformando ogni intrusione in un danno duraturo che richiede settimane o mesi per essere risolto.

La combinazione di tecniche — eliminazione di VM, cancellazione di database, distruzione dei backup Veeam, wiping dei volumi — è progettata per costringere i team di risposta agli incidenti a eseguire processi di remediation separati in parallelo, aumentando la probabilità che almeno uno fallisca o che l’organizzazione non possa tornare operativa nei tempi attesi.

Indicatori di compromissione (IoC)

# Infrastruttura nota
Dominio: nefeshhope[.]com
  Utilizzo: finta piattaforma di supporto psicologico per militari israeliani (2025)
  Collegamento: attributo a Iran MOIS / Black Shadow

# Strumenti identificati
FileFiend - Exfiltration tool C++
  Funzione: raccolta file da dischi locali e di rete, trasmissione a C2

main.py - Script di distruzione DB
  Funzione: connessione automatica a SQL Server, eliminazione database utenti
  Nota: raffinato con ChatGPT per escludere DB di sistema

WipeFile - Utility di cancellazione sicura
  Utilizzo: pulizia directory web server e backup

# Tecniche TTP (MITRE ATT&CK)
T1078 - Valid Accounts (RDP con credenziali admin)
T1485 - Data Destruction
T1490 - Inhibit System Recovery (Veeam destruction)
T1486 - Data Encrypted for Impact (analoga a ransomware senza riscatto)
T1041 - Exfiltration Over C2 Channel (FileFiend)

Due righe per i difensori


La campagna di Ababil of Minab rende evidente che la sicurezza perimetrale da sola non è più sufficiente. Le organizzazioni devono investire nella resilienza operativa, con particolare attenzione a tre aree critiche:

  • Backup immutabili e isolati: I backup devono essere fisicamente e logicamente separati dall’ambiente primario. La compromissione di Veeam o di altri sistemi di backup integrati nella stessa infrastruttura virtuale vanifica qualsiasi piano di recovery.
  • Protezione dell’accesso all’infrastruttura di virtualizzazione: VMware vCenter e sistemi equivalenti devono essere protetti con autenticazione multi-fattore obbligatoria, accesso privilegiato minimo e segmentazione di rete dedicata. Un account vCenter compromesso può eliminare l’intera infrastruttura in minuti.
  • Validazione continua del recovery: Non è sufficiente avere backup. Le organizzazioni devono testare regolarmente la capacità di ripristino in scenari avversariali — non solo in caso di guasto hardware. La domanda non è “abbiamo i backup?”, ma “riusciremo davvero a ripristinare in tempo?”.

Il report completo di Gambit Security è disponibile per il download sul loro sito ed include la documentazione forense completa, i dettagli sull’infrastruttura e l’analisi delle vittime non ancora pubblicamente identificate.


Linux Fu: Fake Webcams Have Many Uses


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

Dealing with text streams is a fundamental skill for the Linux power user. You can sort, merge, and search text files easily from the command line. What if you could do the same thing with video? Well, you can. Maybe you want to add a logo to a webcam feed before sending it to a conference app. Maybe you want to blur, color-correct, or annotate video in real time. Or perhaps you want to inject prerecorded video into Zoom while pretending it is a live camera. Linux can do all of this, and the key ingredient is usually the same: a loopback video device.

The basic idea is simple. Instead of an application reading directly from /dev/video0, you create a fake camera device using the v4l2loopback kernel module. Your software pipeline writes processed video into the fake camera, and applications read from it as if it were a normal webcam. The result is surprisingly powerful.

Loopback Cameras


The first step is to install the loopback driver. On many distributions, this is packaged already. On Debian or Ubuntu, you’d install the v4l2loopback-dkms package. On OpenSUSE it’s probably v4l2loopback-kmp-default if you’re using the usual kernel.

Unless your distro automatically loads the module, you’ll do it yourself and tell the driver how many fake cameras to make. You’ll also need to tell it where to put them. Here, I’m asking for a single camera at /dev/video10 named VirtualCam:
sudo modprobe v4l2loopback devices=1 video_nr=10 card_label="VirtualCam"
After you’ve done this, you can verify it:
v4l2-ctl --list-devices
Applications can now see the fake camera, but there’s nothing coming out of it yet.

Basic Pipeline


Suppose you have a USB webcam at /dev/video0. You can read from it and send the stream directly into the loopback device with FFmpeg:
ffmpeg -f v4l2 -i /dev/video0 -vf format=yuv420p -f v4l2 /dev/video10
Now applications can use /dev/video10 as a webcam source. This alone is useful because it decouples applications from the physical camera. For example, I had an old Intel Lifecam that would randomly throw an error when used with a browser video conference app, but ffmpeg had no problems with it. A similar pipeline lets me videoconference with this camera. But the real fun starts when you insert filters. A fun test site is webcamtoy.com.

Adding a Watermark


FFmpeg’s filter graph system is quite flexible. A watermark is just another video source composited over the main image. Suppose you have a PNG file named wrencher.png with transparency. This command overlays it in the lower-right corner:
ffmpeg -f v4l2 -i /dev/video0 -i wrencher.png -filter_complex "overlay=W-w-20:H-h-20,format=yuv420p" -f v4l2 /dev/video10
Or, you could be more explicit:
ffmpeg -f v4l2 -video_size 1024x720 -framerate 15 -i /dev/video0 -i wrencher.png -filter_complex "overlay=x=main_w-overlay_w-20:y=main_h-overlay_h-20,format=yuv420p" -f v4l2 /dev/video10
Now the logo appears 20 pixels from the bottom-right edge. However, note that if your software “mirrors” your image for local display, the watermark will go to the other side in your view. That makes sense.

If your video fails, or it looks like color garbage or a green screen, you may have to pick a different video conversion other than yuv420p.
Perhaps a bit large for a watermark, but you get the idea.

Injecting Video


You are not limited to webcams. You can inject a prerecorded video:
ffmpeg -re -stream_loop -1 -i intro.mp4 -vf format=yuv420p -f v4l2 /dev/video10
The -re flag tells FFmpeg to play in real time instead of as fast as possible. The -stream_loop -1 repeats forever.

This is useful for demonstrations, test feeds, signage, appearing awake in meetings, or foiling security cameras in low-budget action movies.

Multiple Filters


Once you understand the filter graph concept, you can stack effects endlessly.

For example:
-filter_complex "eq=contrast=1.2:brightness=0.05, hue=s=0, overlay=W-w-20:H-h-20, format=yuv420p"
This:

  • Adjusts contrast
  • Brightens slightly
  • Converts to grayscale
  • Adds the watermark

FFmpeg contains hundreds of filters, including blur, sharpen, edge detection, chroma keying, denoise, LUTs, stabilization, and even AI-assisted processing if built with the right libraries.

At some point, though, you may want a more modular architecture. That is where GStreamer becomes interesting.

Enter GStreamer


FFmpeg excels at direct command-line media processing, but GStreamer is more like a traditional Unix/Linux pipeline. You construct a pipeline out of interconnected processing blocks. The learning curve is steeper, but it enables extremely sophisticated workflows.
Adding text to live video in WebCamFun.
A simple camera-to-loopback pipeline looks like this:
gst-launch-1.0 v4l2src device=/dev/video0 ! videoconvert ! v4l2sink device=dev/video10
That simply duplicates the webcam into the virtual device.

Suppose you want to add text:
gst-launch-1.0 v4l2src device=/dev/video0 ! videoconvert ! textoverlay text="Hackaday!" valignment=bottom halignment=right ! v4l2sink device=/dev/video10

Inspecting GStreamer


One thing that intimidates new GStreamer users is how enormous the framework feels. Fortunately, there’s a tool specifically designed to explore what is available: gst-inspect-1.0

Run without arguments, it dumps every installed plugin and element on your system. The list can be surprisingly long. Using grep on the output can help.

More useful is inspecting a specific element:
gst-inspect-1.0 v4l2src
This shows:

  • Supported capabilities
  • Accepted formats
  • Properties
  • Pad types
  • Configuration options

For example, inspecting textoverlay reveals options for font selection, alignment, shading, and transparency. Inspecting videobalance shows controls for brightness, hue, saturation, and contrast.

This becomes essential because GStreamer pipelines are often constructed experimentally. You discover an element, inspect its capabilities, then wire it into the pipeline.

Using Images in GStreamer


Overlaying an image is slightly more involved because GStreamer separates streams explicitly. One common approach uses gdkpixbufoverlay (here, placing a logo at the lower right):
gst-launch-1.0 v4l2src device=/dev/video0 ! videoconvert ! gdkpixbufoverlay location=logo.png offset-x=20 offset-y=20 ! videoconvert ! v4l2sink device=/dev/video10
You can keep adding modules until you get what you want. A more elaborate pipeline might:

  • Read a webcam
  • Add a logo
  • Blur the background
  • Encode H.264
  • Stream over RTSP
  • Simultaneously feed a loopback webcam

GStreamer can also integrate with many hardware codecs for hardware encoding and decoding.

Practical Considerations


There are several things that tend to trip people up.

Video applications can be extremely picky about formats. MJPEG, YUYV, RGB, and YUV420 all appear frequently. If things fail mysteriously, format conversion is often the culprit.

Tools like v4l2-ctl can help:
v4l2-ctl --list-formats-ext
Another issue is that many applications reject unusual sizes. Sticking with standard resolutions like 1280×720 or 1920×1080 avoids many headaches.

Real-time video processing can consume substantial CPU resources. Hardware acceleration helps, but some filters force software processing anyway. Similarly, virtual camera pipelines can accumulate delay. Low-latency flags and queue tuning sometimes become necessary for interactive use.

Beyond Watermarks


Once you have a loopback pipeline running, you can get creative. You could create a retro CRT simulation, a fake thermal camera, or detect motion. Maybe insert a timestamp or a live video feed from your oscilloscope or 3D printer. Because the output looks like a normal webcam, almost any Linux application can use it. They simply see another camera.

There are many more advanced techniques possible with GStreamer pipelines, including branching streams with tee, synchronizing multiple sources, GPU-accelerated effects, network streaming, and live compositing. If you want a deeper dive into practical virtual-camera workflows, this video provides an excellent starting point:

youtube.com/embed/Ver-pCBM9w0?…

Another tip: if you write shell scripts, using things like /dev/video0 will get you in trouble unless your configuration never changes. Instead, use the stable symlinks:
ls -l /dev/v4l/by-id/
You’ll see things like:
usb-046d_HD_Pro_Webcam_C920-video-index0
Then use that path directly in FFmpeg or GStreamer.

Cleaning Up


When you are finished with the virtual camera, remember that the loopback device persists until the kernel module is unloaded. Stop any applications using the fake camera first, then remove the module:
sudo modprobe -r v4l2loopback
That tears down the virtual camera devices and removes them. If you created multiple fake cameras, unloading the module removes them all at once.

We’ve used Gstrteamer before for remote driving.


hackaday.com/2026/05/28/linux-…

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.

Ababil of Minab: il gruppo Iran-MOIS che ha distrutto 58 server GPS con un solo script Python
#CyberSecurity
insicurezzadigitale.com/ababil…


Ababil of Minab: il gruppo Iran-MOIS che ha distrutto 58 server GPS con un solo script Python


Si parla di:
Toggle

Un singolo script Python. Cinquantotto server Microsoft SQL. Zero possibilità di recupero. È il bilancio dell’operazione condotta dal gruppo Ababil of Minab contro Vyncs, servizio americano di monitoraggio GPS, in quella che i ricercatori di Gambit Security definiscono una campagna sistematica di distruzione del “recovery layer” attribuita al Ministero dell’Intelligence e Sicurezza iraniano (MOIS).

Chi è Ababil of Minab


La persona operativa “Ababil of Minab” è emersa pubblicamente tra la fine di marzo e l’inizio di aprile 2026, rivendicando l’intrusione alla Los Angeles County Metropolitan Transportation Authority (LACMTA / LA Metro), la distruzione di sistemi e l’esfiltrazione di dati. Il gruppo si presenta come un collettivo hacktivista indipendente, ma l’analisi forense condotta da Gambit Security racconta una storia diversa.

Le prove tecniche collegano la campagna attuale all’infrastruttura e all’attività associata a Black Shadow, cluster Iran-linked già pubblicamente attribuito dall’Israel National Cyber Directorate (INCD) al MOIS. La stessa infrastruttura utilizzata in questa operazione era stata impiegata nel 2025 in una falsa piattaforma di supporto psicologico per militari israeliani — il dominio nefeshhope[.]com — attraverso cui venivano raccolti dati personali e distribuito malware.

La portata geografica: quattro paesi, una strategia unica


La campagna ha colpito organizzazioni in Stati Uniti, Israele, Arabia Saudita e Turchia. L’esfiltrazione di dati ha interessato tutte le vittime; le operazioni distruttive sono state riservate a un sottoinsieme di esse, principalmente negli USA. Tra le organizzazioni israeliane e turche colpite figurano istituzioni educative, media, compagnie assicurative e siti culturali — identità che Gambit ha identificato ma che il gruppo non ha scelto di rendere pubbliche.

Lo strumento personalizzato di esfiltrazione recuperato dai ricercatori è FileFiend, un programma scritto in C++ in grado di raccogliere file da dischi locali e di rete per trasmetterli al server di comando. I dati venivano esfiltrati anche attraverso i web server compromessi delle stesse vittime.

Il playbook distruttivo: colpire il layer di recovery


Ciò che distingue Ababil of Minab da un attore ransomware tradizionale è la scelta deliberata di colpire non solo i dati operativi, ma l’intera infrastruttura di ripristino. Ogni tecnica impiegata introduce una sfida di recovery separata, moltiplicando i tempi e la complessità della risposta agli incidenti.

LA Metro (LACMTA): Gli attaccanti hanno ottenuto accesso a VMware vCenter, eliminando le virtual machine insieme ai file disco. Ore dopo, la metropolitan authority segnalava interruzioni nel sistema mobile di pagamento dei trasporti. In seguito, tramite accesso RDP a una macchina Windows guest, hanno eliminato le partizioni dei dischi attraverso lo strumento nativo di gestione dei volumi.

South Florida Regional Transportation Authority: Accesso RDP con privilegi di amministratore locale su un server IIS, seguito dalla cancellazione di database tramite Microsoft SQL Server Management Studio e dall’utilizzo di WipeFile per eliminare il contenuto delle directory del web server e dei backup.

UNIMAC: Formattazione delle partizioni, eliminazione dei volumi e creazione di nuovi volumi rinominati “Minab” come firma. Distruzione della catena di backup attraverso Veeam Backup & Replication.

Lo script automatizzato e l’uso di ChatGPT


L’attacco a Vyncs, il servizio americano di monitoraggio GPS via OBD-II, rappresenta l’episodio più emblematico dell’intera campagna dal punto di vista dell’automazione offensiva. Gli attaccanti hanno sviluppato un file main.py che si connetteva automaticamente a 58 server Microsoft SQL Server e cancellava i database degli utenti. Parallelamente, operatori umani eliminavano manualmente i backup e le directory di sistema Windows. Una volta rimossi i dati, anche la connessione al server si è interrotta — conferma dell’avvenuta distruzione dell’infrastruttura.

Un dettaglio che segna una svolta nell’impiego dell’AI offensiva: nei video pubblicati dallo stesso gruppo, i ricercatori hanno osservato gli operatori utilizzare ChatGPT per raffinare lo script di cancellazione, in particolare per escludere i database di sistema di Microsoft SQL Server dall’elenco degli oggetti da eliminare, assicurandosi che lo script agisse esclusivamente sui dati degli utenti senza bloccarsi per errori di sistema.

“Modern intrusion operators are moving from initial access straight into the recovery layer, virtualization, backups, storage volumes, to maximize destruction and deny remediation. The skill required to do that at scale is collapsing in parallel. As AI capabilities become widely available, any actor, skilled or not, will be able to execute this kind of campaign.”
— Gambit Security Threat Intelligence Team


Implicazioni strategiche: la nuova frontiera del cyber warfare


La campagna di Ababil of Minab illustra un cambiamento fondamentale nella dottrina degli attacchi informatici statali. Non si tratta più solo di compromettere i sistemi o rubare dati: l’obiettivo diventa negare la capacità di recupero, trasformando ogni intrusione in un danno duraturo che richiede settimane o mesi per essere risolto.

La combinazione di tecniche — eliminazione di VM, cancellazione di database, distruzione dei backup Veeam, wiping dei volumi — è progettata per costringere i team di risposta agli incidenti a eseguire processi di remediation separati in parallelo, aumentando la probabilità che almeno uno fallisca o che l’organizzazione non possa tornare operativa nei tempi attesi.

Indicatori di compromissione (IoC)

# Infrastruttura nota
Dominio: nefeshhope[.]com
  Utilizzo: finta piattaforma di supporto psicologico per militari israeliani (2025)
  Collegamento: attributo a Iran MOIS / Black Shadow

# Strumenti identificati
FileFiend - Exfiltration tool C++
  Funzione: raccolta file da dischi locali e di rete, trasmissione a C2

main.py - Script di distruzione DB
  Funzione: connessione automatica a SQL Server, eliminazione database utenti
  Nota: raffinato con ChatGPT per escludere DB di sistema

WipeFile - Utility di cancellazione sicura
  Utilizzo: pulizia directory web server e backup

# Tecniche TTP (MITRE ATT&CK)
T1078 - Valid Accounts (RDP con credenziali admin)
T1485 - Data Destruction
T1490 - Inhibit System Recovery (Veeam destruction)
T1486 - Data Encrypted for Impact (analoga a ransomware senza riscatto)
T1041 - Exfiltration Over C2 Channel (FileFiend)

Due righe per i difensori


La campagna di Ababil of Minab rende evidente che la sicurezza perimetrale da sola non è più sufficiente. Le organizzazioni devono investire nella resilienza operativa, con particolare attenzione a tre aree critiche:

  • Backup immutabili e isolati: I backup devono essere fisicamente e logicamente separati dall’ambiente primario. La compromissione di Veeam o di altri sistemi di backup integrati nella stessa infrastruttura virtuale vanifica qualsiasi piano di recovery.
  • Protezione dell’accesso all’infrastruttura di virtualizzazione: VMware vCenter e sistemi equivalenti devono essere protetti con autenticazione multi-fattore obbligatoria, accesso privilegiato minimo e segmentazione di rete dedicata. Un account vCenter compromesso può eliminare l’intera infrastruttura in minuti.
  • Validazione continua del recovery: Non è sufficiente avere backup. Le organizzazioni devono testare regolarmente la capacità di ripristino in scenari avversariali — non solo in caso di guasto hardware. La domanda non è “abbiamo i backup?”, ma “riusciremo davvero a ripristinare in tempo?”.

Il report completo di Gambit Security è disponibile per il download sul loro sito ed include la documentazione forense completa, i dettagli sull’infrastruttura e l’analisi delle vittime non ancora pubblicamente identificate.


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.

Glassworm smantellato: CrowdStrike abbatte la botnet che prendeva di mira gli sviluppatori attraverso npm, PyPI e GitHub
#CyberSecurity
insicurezzadigitale.com/glassw…


Glassworm smantellato: CrowdStrike abbatte la botnet che prendeva di mira gli sviluppatori attraverso npm, PyPI e GitHub


Si parla di:
Toggle

CrowdStrike Counter Adversary Operations, Google e Shadowserver Foundation abbattono simultaneamente tutti e quattro i canali di comando e controllo della botnet Glassworm. Infetta da oltre un anno attraverso l’ecosistema open-source, l’infrastruttura criminale — progettata per sopravvivere ai takedown tradizionali usando blockchain, peer-to-peer e servizi Google come dead-drop — perde il controllo di migliaia di macchine di sviluppatori in tutto il mondo.

Perché gli sviluppatori sono il bersaglio ideale


Glassworm rappresenta un cambio di paradigma nel threat landscape: gli attaccanti non prendono più di mira direttamente i prodotti software — prendono di mira le persone che li costruiscono. Un singolo workstation di sviluppatore compromessa può aprire agli attaccanti l’accesso a repository di codice sorgente, piattaforme cloud, pipeline CI/CD, credenziali di accesso e registry di pacchetti. Da lì, il malware può propagarsi a valle della supply chain, raggiungendo organizzazioni che non hanno mai avuto contatti diretti con gli operatori di Glassworm.

Dall’inizio del 2025, gli operatori di Glassworm hanno condotto una campagna sistematica contro gli sviluppatori su Windows, macOS e Linux, sfruttando tre vettori principali dell’ecosistema open-source:

1. Estensioni VSCode trojanizzate su OpenVSX


Le estensioni malevoli venivano pubblicate sul marketplace OpenVSX, camuffate da strumenti legittimi come time tracker e code formatter. L’impatto andava oltre VSCode: qualsiasi editor compatibile con l’ecosistema — Cursor, Positron, Windsurf, VSCodium — risultava vulnerabile allo stesso payload.

2. Pacchetti npm e Python con hook di installazione malevoli


Il codice malevolo veniva eseguito durante l’installazione ordinaria delle dipendenze, attraverso hook postinstall e script setup.py. Per lo sviluppatore, l’operazione appariva come un normale aggiornamento di libreria. Il payload veniva eseguito prima che qualsiasi analisi manuale potesse rilevarlo.

3. Repository GitHub avvelenati con credenziali rubate


Oltre 300 repository GitHub sono stati compromessi usando credenziali di sviluppatori ottenute in infezioni precedenti. Gli operatori eseguivano force push sui branch predefiniti, inserendo codice malevolo dove altri sviluppatori si aspettavano di trovare il progetto originale — un classico attacco alla fiducia implicita nell’ecosistema open-source.

GlasswormRAT: le capacità del malware


Il payload finale installato dalle infezioni Glassworm è GlasswormRAT, un remote access tool scritto in Node.js con funzionalità complete: furto di informazioni, harvesting di credenziali e controllo remoto completo del sistema compromesso. Nel corso di oltre un anno di operazioni, gli sviluppatori di Glassworm hanno evoluto continuamente il codice, passando da JavaScript a Rust e Zig, ampliando il supporto a più ecosistemi e costruendo infrastrutture ridondanti in previsione di eventuali takedown.

L’architettura C2 a quattro canali: progettata per sopravvivere


L’elemento più sofisticato di Glassworm è la sua infrastruttura di comando e controllo, progettata esplicitamente per resistere ai takedown tradizionali. I ricercatori hanno identificato quattro canali distinti che garantivano ridondanza operativa:

  • Blockchain Solana: Gli indirizzi dei server C2 venivano codificati nei campi memo delle transazioni blockchain. Una volta scritti, i dati sono immutabili e pubblicamente accessibili — non possono essere rimossi da una richiesta a un hosting provider.
  • BitTorrent DHT (Distributed Hash Table): GlasswormRAT interrogava la rete peer-to-peer BitTorrent cercando dati di configurazione attraverso chiavi pubbliche hardcoded. Una rete decentralizzata senza single point of failure, impossibile da abbattere con i metodi convenzionali.
  • Google Calendar: Il malware usava i titoli degli eventi di Google Calendar come dead-drop per path C2 codificati in Base64. Per i difensori, bloccare il dominio avrebbe significato interrompere anche l’uso legittimo del calendario aziendale.
  • Server VPS diretti: Infrastruttura C2 tradizionale su provider commerciali, usata per la delivery dei payload finali alle macchine infette.

La combinazione di questi quattro canali rendeva qualsiasi takedown parziale inefficace: abbattere uno solo avrebbe consentito agli operatori di ripristinare il controllo attraverso gli altri tre. Questo è il motivo per cui il takedown ha richiesto una coordinazione precisa tra CrowdStrike, Google e Shadowserver Foundation per colpire tutti e quattro i canali simultaneamente alle 14:00 UTC.

Attribuzione: gli indizi puntano verso la Russia


CrowdStrike attribuisce con moderata fiducia la campagna a operatori con sede in Russia, basandosi su un pattern coerente osservato per oltre un anno. Il malware effettua controlli runtime sulla locale, la lingua e il fuso orario della vittima, terminando silenziosamente se la macchina risulta in un paese CIS — una tecnica consolidata tra i cybercriminali dell’area ex-sovietica per evitare di colpire obiettivi vicini a casa. Nel codice sorgente compaiono commenti in russo.

CrowdStrike precisa che nessun indicatore singolo costituisce prova definitiva: i controlli di locale possono essere copiati, i commenti possono derivare da strumenti AI. Ma il pattern complessivo, consistente per oltre dodici mesi di osservazione, è considerato sufficientemente solido per l’attribuzione.

Come verificare un’infezione da Glassworm


Dopo il takedown, tutte le macchine infette da Glassworm tentano di contattare un IP gestito da CrowdStrike (sinkholed). Qualsiasi connessione a questo indirizzo nei log di rete indica un’infezione attiva che richiede remediation immediata.

# Indicatore di rete (sinkhole CrowdStrike post-takedown)
IP: 164.92.88[.]210
# Cosa verificare:
- Log di rete per connessioni a 164.92.88[.]210
- Telemetria endpoint su workstation sviluppatori
- Installazioni recenti di estensioni OpenVSX da fonti non verificate
- Pacchetti npm o Python installati da repository non ufficiali
- Repository GitHub con commit anomali o force push recenti
# YARA Rule 1: GlasswormRAT
rule CrowdStrike_GlasswormRat_01 : glassworm glasswormrat
{
    meta:
        description = "Characteristic strings in Glassworm RAT script"
        malware_family = "GlasswormRAT"
    strings:
        $download = "DownloadManager" ascii
        $socks = "start_socks" ascii
        $nodejs = "https://nodejs.org/download/release" ascii
        $dht = "bootstrap" ascii
    condition:
        all of them
}
# YARA Rule 2: Glassworm Python Downloader
rule CrowdStrike_GlasswormDownloader_01 : glassworm
{
    meta:
        description = "Obfuscated Python installer Glassworm variant"
        malware_family = "Glassworm"
    strings:
        $zlib = "__import__('zlib')" ascii
        $decomp = "decompress(" ascii
        $lambda = "lambda" ascii
        $exec = /exec\(compile\(.{5,20}, '', 'exec'\)\)/
    condition:
        all of them and filesize < 10KB
}

Il takedown come modello: cosa cambia nella difesa della supply chain


L'operazione Glassworm dimostra che la difesa attraverso la sola detection è strutturalmente insufficiente contro gli attacchi alla supply chain. I pacchetti malevoli vengono installati in secondi durante aggiornamenti di routine; la detection avviene dopo che il danno è già fatto. Con decine di ecosistemi — npm, PyPI, OpenVSX, GitHub — e milioni di pacchetti con controlli di sicurezza limitati, gli attaccanti possono pubblicare codice malevolo e raggiungere migliaia di vittime in minuti.

Il takedown coordinato imposta un precedente operativo: la disruption proattiva dell'infrastruttura avversariale è tecnicamente possibile anche contro architetture C2 deliberatamente progettate per la resilienza. La precisione richiesta — colpire simultaneamente blockchain, DHT, servizi Google e VPS tradizionali — ha richiesto la collaborazione tra intelligence privata (CrowdStrike), piattaforme tecnologiche (Google) e coordinamento internazionale (Shadowserver Foundation).

Per i team di sicurezza, le raccomandazioni immediate includono: audit delle estensioni installate negli ambienti di sviluppo, verifica dei pacchetti npm e Python con strumenti come npm audit e pip-audit, revisione dei log di accesso ai repository GitHub per force push anomali, e implementazione di controlli di integrità sulle dipendenze nei pipeline CI/CD.


Cybersecurity & cyberwarfare ha ricondiviso questo.

U.S. #CISA adds Daemon Tools, TanStack, and Nx Console flaws to its Known Exploited Vulnerabilities catalog
securityaffairs.com/192776/sec…
#securityaffairs #hacking

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

Glassworm smantellato: CrowdStrike abbatte la botnet che prendeva di mira gli sviluppatori attraverso npm, PyPI e GitHub


@Informatica (Italy e non Italy)
Il 26 maggio 2026, CrowdStrike, Google e Shadowserver Foundation hanno eseguito un takedown coordinato di Glassworm, botnet attivo da oltre un anno che infettava sviluppatori


Glassworm smantellato: CrowdStrike abbatte la botnet che prendeva di mira gli sviluppatori attraverso npm, PyPI e GitHub


Si parla di:
Toggle

CrowdStrike Counter Adversary Operations, Google e Shadowserver Foundation abbattono simultaneamente tutti e quattro i canali di comando e controllo della botnet Glassworm. Infetta da oltre un anno attraverso l’ecosistema open-source, l’infrastruttura criminale — progettata per sopravvivere ai takedown tradizionali usando blockchain, peer-to-peer e servizi Google come dead-drop — perde il controllo di migliaia di macchine di sviluppatori in tutto il mondo.

Perché gli sviluppatori sono il bersaglio ideale


Glassworm rappresenta un cambio di paradigma nel threat landscape: gli attaccanti non prendono più di mira direttamente i prodotti software — prendono di mira le persone che li costruiscono. Un singolo workstation di sviluppatore compromessa può aprire agli attaccanti l’accesso a repository di codice sorgente, piattaforme cloud, pipeline CI/CD, credenziali di accesso e registry di pacchetti. Da lì, il malware può propagarsi a valle della supply chain, raggiungendo organizzazioni che non hanno mai avuto contatti diretti con gli operatori di Glassworm.

Dall’inizio del 2025, gli operatori di Glassworm hanno condotto una campagna sistematica contro gli sviluppatori su Windows, macOS e Linux, sfruttando tre vettori principali dell’ecosistema open-source:

1. Estensioni VSCode trojanizzate su OpenVSX


Le estensioni malevoli venivano pubblicate sul marketplace OpenVSX, camuffate da strumenti legittimi come time tracker e code formatter. L’impatto andava oltre VSCode: qualsiasi editor compatibile con l’ecosistema — Cursor, Positron, Windsurf, VSCodium — risultava vulnerabile allo stesso payload.

2. Pacchetti npm e Python con hook di installazione malevoli


Il codice malevolo veniva eseguito durante l’installazione ordinaria delle dipendenze, attraverso hook postinstall e script setup.py. Per lo sviluppatore, l’operazione appariva come un normale aggiornamento di libreria. Il payload veniva eseguito prima che qualsiasi analisi manuale potesse rilevarlo.

3. Repository GitHub avvelenati con credenziali rubate


Oltre 300 repository GitHub sono stati compromessi usando credenziali di sviluppatori ottenute in infezioni precedenti. Gli operatori eseguivano force push sui branch predefiniti, inserendo codice malevolo dove altri sviluppatori si aspettavano di trovare il progetto originale — un classico attacco alla fiducia implicita nell’ecosistema open-source.

GlasswormRAT: le capacità del malware


Il payload finale installato dalle infezioni Glassworm è GlasswormRAT, un remote access tool scritto in Node.js con funzionalità complete: furto di informazioni, harvesting di credenziali e controllo remoto completo del sistema compromesso. Nel corso di oltre un anno di operazioni, gli sviluppatori di Glassworm hanno evoluto continuamente il codice, passando da JavaScript a Rust e Zig, ampliando il supporto a più ecosistemi e costruendo infrastrutture ridondanti in previsione di eventuali takedown.

L’architettura C2 a quattro canali: progettata per sopravvivere


L’elemento più sofisticato di Glassworm è la sua infrastruttura di comando e controllo, progettata esplicitamente per resistere ai takedown tradizionali. I ricercatori hanno identificato quattro canali distinti che garantivano ridondanza operativa:

  • Blockchain Solana: Gli indirizzi dei server C2 venivano codificati nei campi memo delle transazioni blockchain. Una volta scritti, i dati sono immutabili e pubblicamente accessibili — non possono essere rimossi da una richiesta a un hosting provider.
  • BitTorrent DHT (Distributed Hash Table): GlasswormRAT interrogava la rete peer-to-peer BitTorrent cercando dati di configurazione attraverso chiavi pubbliche hardcoded. Una rete decentralizzata senza single point of failure, impossibile da abbattere con i metodi convenzionali.
  • Google Calendar: Il malware usava i titoli degli eventi di Google Calendar come dead-drop per path C2 codificati in Base64. Per i difensori, bloccare il dominio avrebbe significato interrompere anche l’uso legittimo del calendario aziendale.
  • Server VPS diretti: Infrastruttura C2 tradizionale su provider commerciali, usata per la delivery dei payload finali alle macchine infette.

La combinazione di questi quattro canali rendeva qualsiasi takedown parziale inefficace: abbattere uno solo avrebbe consentito agli operatori di ripristinare il controllo attraverso gli altri tre. Questo è il motivo per cui il takedown ha richiesto una coordinazione precisa tra CrowdStrike, Google e Shadowserver Foundation per colpire tutti e quattro i canali simultaneamente alle 14:00 UTC.

Attribuzione: gli indizi puntano verso la Russia


CrowdStrike attribuisce con moderata fiducia la campagna a operatori con sede in Russia, basandosi su un pattern coerente osservato per oltre un anno. Il malware effettua controlli runtime sulla locale, la lingua e il fuso orario della vittima, terminando silenziosamente se la macchina risulta in un paese CIS — una tecnica consolidata tra i cybercriminali dell’area ex-sovietica per evitare di colpire obiettivi vicini a casa. Nel codice sorgente compaiono commenti in russo.

CrowdStrike precisa che nessun indicatore singolo costituisce prova definitiva: i controlli di locale possono essere copiati, i commenti possono derivare da strumenti AI. Ma il pattern complessivo, consistente per oltre dodici mesi di osservazione, è considerato sufficientemente solido per l’attribuzione.

Come verificare un’infezione da Glassworm


Dopo il takedown, tutte le macchine infette da Glassworm tentano di contattare un IP gestito da CrowdStrike (sinkholed). Qualsiasi connessione a questo indirizzo nei log di rete indica un’infezione attiva che richiede remediation immediata.

# Indicatore di rete (sinkhole CrowdStrike post-takedown)
IP: 164.92.88[.]210
# Cosa verificare:
- Log di rete per connessioni a 164.92.88[.]210
- Telemetria endpoint su workstation sviluppatori
- Installazioni recenti di estensioni OpenVSX da fonti non verificate
- Pacchetti npm o Python installati da repository non ufficiali
- Repository GitHub con commit anomali o force push recenti
# YARA Rule 1: GlasswormRAT
rule CrowdStrike_GlasswormRat_01 : glassworm glasswormrat
{
    meta:
        description = "Characteristic strings in Glassworm RAT script"
        malware_family = "GlasswormRAT"
    strings:
        $download = "DownloadManager" ascii
        $socks = "start_socks" ascii
        $nodejs = "https://nodejs.org/download/release" ascii
        $dht = "bootstrap" ascii
    condition:
        all of them
}
# YARA Rule 2: Glassworm Python Downloader
rule CrowdStrike_GlasswormDownloader_01 : glassworm
{
    meta:
        description = "Obfuscated Python installer Glassworm variant"
        malware_family = "Glassworm"
    strings:
        $zlib = "__import__('zlib')" ascii
        $decomp = "decompress(" ascii
        $lambda = "lambda" ascii
        $exec = /exec\(compile\(.{5,20}, '', 'exec'\)\)/
    condition:
        all of them and filesize < 10KB
}

Il takedown come modello: cosa cambia nella difesa della supply chain


L'operazione Glassworm dimostra che la difesa attraverso la sola detection è strutturalmente insufficiente contro gli attacchi alla supply chain. I pacchetti malevoli vengono installati in secondi durante aggiornamenti di routine; la detection avviene dopo che il danno è già fatto. Con decine di ecosistemi — npm, PyPI, OpenVSX, GitHub — e milioni di pacchetti con controlli di sicurezza limitati, gli attaccanti possono pubblicare codice malevolo e raggiungere migliaia di vittime in minuti.

Il takedown coordinato imposta un precedente operativo: la disruption proattiva dell'infrastruttura avversariale è tecnicamente possibile anche contro architetture C2 deliberatamente progettate per la resilienza. La precisione richiesta — colpire simultaneamente blockchain, DHT, servizi Google e VPS tradizionali — ha richiesto la collaborazione tra intelligence privata (CrowdStrike), piattaforme tecnologiche (Google) e coordinamento internazionale (Shadowserver Foundation).

Per i team di sicurezza, le raccomandazioni immediate includono: audit delle estensioni installate negli ambienti di sviluppo, verifica dei pacchetti npm e Python con strumenti come npm audit e pip-audit, revisione dei log di accesso ai repository GitHub per force push anomali, e implementazione di controlli di integrità sulle dipendenze nei pipeline CI/CD.


Cybersecurity & cyberwarfare ha ricondiviso questo.

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

UE vs USA: è Battaglia per il Dominio Tecnologico! E se 265 miliardi di euro l’UE rimanessero in EU?

📌 Link all'articolo : redhotcyber.com/post/ue-vs-usa…

A cura di Marcello Filacchioni

#redhotcyber #news #sovranitatech #intelligenzaartificiale #cloudcomputing

Cybersecurity & cyberwarfare ha ricondiviso questo.

Microsoft, who banned Nightmare-Eclipse from their GitHub platform, conveys their displeasure with said individual

Along with a threat:

Our Digital Crimes Unit will continue bringing cases against these actors and those that enable their criminal activity – coordinating as needed with law enforcement around the world.


Also manages to sprinkle in a few references to not using CVD as being not "responsible". (Microsoft was a big proponent of the term "responsible disclosure", which has gone by the wayside because it tends to favor vendor-centric perspective in a subjective and moralizing way.)

Questa voce è stata modificata (2 settimane fa)

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.

Condé Nast shit the bed so hard when it fired four journalists last year that it's now settled with the union and given three out of the four reporters "two years’ pay and furnished [them] with positive letters of recommendation."

UNIONS, PEOPLE. UNIONS!

hollywoodreporter.com/business…

Virtual Museum Hosts Every OS You Haven’t Heard Of


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

The Virtual OS museum, screenshot

OK, every operating system is a bit of a stretch — Windows Vista notably didn’t make the cut — but [Andrew]’s Virtual OS museum has a good claim to being the most comprehensive archive of operating systems yet assembled.

[Andrew] has a blog post describing the project, as well as a YouTube video that we’ve embedded below. But the real fun is in the downloading and spinning up one of 570+ operating systems for more than 250 platforms on pre-configured virtual machines that have been packaged up for us.

This isn’t just the usual retrocomputer nostalgia-fest of Macintosh System and DOSBox. There’s everything from IBM Big Iron and VAXen to Texas Instrument graphing calculators emulated in the museum, with software to run on them, too. If you’ve ever wondered what you could do with the Manchester Baby, well, all known software for that machine is included with its ‘operating system’.

Admission is free, but like any good museum you’ll be waiting in line a while to get in, so expect the full 128 GB download to take some time. If you’re into computer history, though, it’s going to very much be worth the wait. If you try it and like it, you could help others by seeding the torrent.

The actual museum launches in a VM as a modern Linux system — perhaps that can be considered an exhibit itself — with a launcher to select any of the other system/OS combos, including various other, older Linuxes hosted on their own VMs. There are more to come, too, as [Andrew] continues the long debugging process of making sure everything works as expected.

Purists may decry this virtual emulation as not being quite the real thing, which is true. But while MiSTer supports a lot of cores via FPGA, you probably won’t find everything here on that platform. We have, however, seen an FPGA recreation of the Manchester Baby. More than once, even.

youtube.com/embed/jqcuqWTxTNw?…


hackaday.com/2026/05/28/virtua…

Cybersecurity & cyberwarfare ha ricondiviso questo.

A Fake #UK #Visa Site Left 100,000 Passports Wide Open
securityaffairs.com/192809/sec…
#securityaffairs #hacking
Cybersecurity & cyberwarfare ha ricondiviso questo.

- (lascia trasparire un certo sforzo mentre pronuncia le parole) abbiamo chiesto ehm... al segretario generale della Farnesina di convocare immediatamente l'ambasciatore israeliano e abbiamo chiesto... scuse... e... mmm...
- sono arrivate?
- (finge di rifletterci, il volto serio) mmm... mi pare che... formalmente no

Ci ho messo diversi anni per capire che avevo sottovalutato totalmente il talento geniale di Leslie Nielsen

Temo di avere commesso esattamente lo stesso errore con Antonio Tajani

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.

PANGEA, l'operazione internazionale coordinata da INTERPOL contro il traffico illecito di farmaci


Nei mesi scorsi, nell'ambito della XVIII edizione di PANGEA, l'operazione internazionale volta a contrastare il traffico illecito di farmaci e prodotti correlati alla salute (dispositivi medici, cosmetici e sigarette elettroniche), sono state investigate condotte riconducibili a falsificazione, contrabbando di prodotti legali, evasione fiscale, cattiva conservazione e furti

L'iniziativa, coordinata a livello mondiale da #INTERPOL, ha coinvolto 90 Paesi, concentrando gli sforzi sulla sorveglianza del web (marketplace, social media, app di messaggistica e Dark Web), sull'ispezione fisica di farmacie sospette di vendita illecita e sul tracciamento di pacchi sospetti.

Lo sforzo congiunto di autorità doganali, enti regolatori e Forze di Polizia ha portato, a livello globale, al sequestro di oltre 6 milioni di unità posologiche di farmaci contraffatti, per un valore superiore ai 15 milioni di dollari. Le autorità hanno avviato 392 indagini, eseguito 269 arresti, smantellato 66 gruppi criminali e chiuso 5.700 siti web, pagine social e canali utilizzati per il commercio illegale.

In Italia, i controlli si sono svolti presso i principali hub aeroportuali dei corrieri espresso e delle Poste, data l'elevata quantità di spedizioni gestite. In questi centri, team misti composti da militari dei NAS ( #CarabinieriTutelaSalute ), personale dell'Agenzia delle Dogane e dei Monopoli (ADM), uffici USMAF e #GuardiadiFinanza, supportati dal Nucleo Carabinieri dell'Agenzia Italiana del Farmaco e dall'Ufficio Investigazioni Antifrode #ADM, hanno effettuato verifiche congiunte basate su criteri condivisi con l' #AIFA.

Grazie all'intensificazione dei controlli, sono state individuate e sequestrate, tra le spedizioni dirette in Italia, quasi 20.000 unità di farmaci illegali e falsificati, per un valore stimato di oltre 20.000 euro.

L'attività ha evidenziato un incremento dell'importazione illecita di antiparassitari come ivermectina e fenbendazolo (quest'ultimo autorizzato solo per uso veterinario), tornati sotto i riflettori dopo la pandemia a causa della promozione come presunti terapie anticancro. Restano rilevanti anche l'importazione di sostanze dopanti e prodotti "lifestyle", come farmaci per la disfunzione erettile (sildenafil, tadalafil, vardenafil) e per la perdita di peso (semaglutide e inibitori GLP-1).

I sequestri effettuati hanno inoltre innescato nuove indagini congiunte tra ADM e Carabinieri Tutela Salute, attualmente in corso. Oltre alle attività coordinate, i reparti territoriali dei Carabinieri per la Tutela della Salute hanno intensificato le ispezioni presso le farmacie e i siti web autorizzati, la vigilanza sulle vendite illegali da parte di soggetti non autorizzati e il controllo dei siti web illegali, avviando 24 nuove indagini. Queste hanno portato alla luce vendite illegali presso esercizi non autorizzati (negozi etnici), irregolarità in siti web di vendita di farmaci e parafarmaci e piattaforme illegali con registrar esteri.

Durante le operazioni sono state sequestrate oltre 13.000 unità posologiche di farmaci illegali e intercettati 32 siti web, per i quali è stata proposta l'oscuramento al Ministero della Salute.

I controlli della Guardia di Finanza, basati sull'analisi del rischio del Nucleo Speciale Beni e Servizi, hanno portato a significativi sequestri negli spazi doganali, in particolare negli aeroporti di Napoli Capodichino, Pisa, Roma Ciampino, Roma Fiumicino e Venezia Tessera, con il rinvenimento di sostanze dopanti. I reparti speciali del Corpo hanno inoltre provveduto all'oscuramento di ulteriori 10 siti internet illegali di origine estera, grazie a un monitoraggio più intenso della rete assicurato dal Nucleo Speciale Tutela Privacy e Frodi Tecnologiche.

L'operazione ha consentito di raccogliere spunti investigativi sul traffico internazionale di farmaci, intercettando nuove tendenze di consumo nel mercato illegale e rafforzando la collaborazione istituzionale nel contrasto a questo fenomeno criminale.

reshared this

Cybersecurity & cyberwarfare ha ricondiviso questo.

U.S. #CISA adds LiteSpeed cPanel Plugin flaw to its Known Exploited Vulnerabilities catalog
securityaffairs.com/192795/hac…
#securityaffairs #hacking
Cybersecurity & cyberwarfare ha ricondiviso questo.

U.S. #CISA adds LiteSpeed cPanel Plugin flaw to its Known Exploited Vulnerabilities catalog
securityaffairs.com/192795/hac…
#securityaffairs #hacking
Cybersecurity & cyberwarfare ha ricondiviso questo.

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

CypherLoc: 2,8 milioni di attacchi phishing nel 2026, come evitare questa minaccia?

📌 Link all'articolo : redhotcyber.com/post/cypherloc…

A cura di Carolina Vivianti

#redhotcyber #news #cyberattack #cybersecurity #hacking #malware #scareware #truffeonline

Aruba Hosting e AI integrata: come funziona l’offerta per creare un sito in pochi passaggi


@Informatica (Italy e non Italy)
Aruba Hosting punta sull’integrazione dell’intelligenza artificiale per semplificare la creazione di siti web, blog ed e-commerce. L’offerta ruota attorno a SuperSite, WordPress e soluzioni hosting dedicate, con prezzi promozionali dal primo anno e funzionalità AI pensate per

Cybersecurity & cyberwarfare ha ricondiviso questo.

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

BadHost (CVE-2026-48710): Critical Authentication Bypass Threatens Thousands of AI Agent Applications
#CyberSecurity
securebulletin.com/badhost-cve…
Cybersecurity & cyberwarfare ha ricondiviso questo.

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

Tycoon 2FA Phishing Kit Bypasses MFA at Scale — 62% of Microsoft 365 Phishing Attempts Linked to Single Threat Actor
#CyberSecurity
securebulletin.com/tycoon-2fa-…
Cybersecurity & cyberwarfare ha ricondiviso questo.

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

Seedworm (MuddyWater) APT Abuses Signed Security Binaries in Global Espionage Campaign Across 9 Countries
#CyberSecurity
securebulletin.com/seedworm-mu…
Cybersecurity & cyberwarfare ha ricondiviso questo.

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

NightSpire Ransomware Exploits RDP and Remote Admin Tools to Hit 64 Organizations in 33 Countries
#CyberSecurity
securebulletin.com/nightspire-…

Testing LFP Battery Failure Modes With Overcharging


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

As great as batteries are, it’s essential to understand their risks and how to keep them from going spicy. Recently there has been a bit of a fuss about the dangers of LiFePO4 (LFP) batteries after someone’s dedicated LFP battery shed got shredded into matchsticks by a hydrogen explosion, following said LFP batteries having a thermal event. The thing about the LFP chemistry is that if it suffers such a thermal event, it generates hydrogen gas, which is one of the most explosion-happy gases known to man. This is demonstrated in a recent video by [Will Prowse].

To kick things off, a single prismatic LFP cell is overcharged for half an hour after it was already at 100% state of charge. This ultimately pops the vent as the cell begins to release hydrogen gas into the aquarium that the cell was placed in. Using a spark generator it’s then attempted to ignite the gas, which initially takes a bit as enough hydrogen has to collect first.

Once there’s ignition, however, it happily keeps burning as more and more hydrogen pours out of the by now bulging cell’s vent. If any other LFP cells had been nearby these too would be at risk of suffering thermal runaway, showing how just one bad LFP cell is enough to potentially set an LFP battery bank ablaze.

In a commercial setting you will have precautions such as hydrogen sensors, ventilation and spark generators to deal with any generated hydrogen gas, as well as blow-out panels in case things end up going squirrely in a hurry.

While a benefit of LFP chemistry is that it does not generate its own oxygen as with other lithium-ion chemistries, hydrogen gas is a major problem due to how incredibly volatile it is. It’s not just a headache with battery storage, but also in the nuclear power sector, where zirconium fuel rod cladding can very efficiently turn steam into hydrogen and oxygen. This was the reason why some of Fukushima Daiichi’s buildings suffered detonations, with the nuclear plant operator opting to not install recommended hydrogen gas mitigation systems.

youtube.com/embed/yL_pHNIttlc?…


hackaday.com/2026/05/28/testin…