The Pirate Post ha ricondiviso questo.

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

Ubiquiti Issues Emergency Patches for Five Critical UniFi OS Vulnerabilities, Three Rated Maximum CVSS 10.0
#CyberSecurity
securebulletin.com/ubiquiti-is…
The Pirate Post ha ricondiviso questo.

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

CISA Adds Two Actively Exploited Microsoft Defender Zero-Days to KEV Catalog — Patch by June 3
#CyberSecurity
securebulletin.com/cisa-adds-t…
The Pirate Post 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.

Showboat e JFMBackdoor: il gruppo cinese Calypso spia le telecomunicazioni del Medio Oriente con malware Linux e Windows
#CyberSecurity
insicurezzadigitale.com/showbo…


Showboat e JFMBackdoor: il gruppo cinese Calypso spia le telecomunicazioni del Medio Oriente con malware Linux e Windows


I ricercatori di Lumen Technologies Black Lotus Labs hanno pubblicato il 21 maggio 2026 un’analisi dettagliata di due nuovi strumenti malevoli — Showboat (Linux) e JFMBackdoor (Windows) — impiegati in campagne di cyberspionaggio attribuite con moderata confidenza al gruppo cinese Calypso, noto anche come Red Lamassu. I bersagli: operatori di telecomunicazioni nel Medio Oriente, nell’Asia Pacifica e, più recentemente, entità negli Stati Uniti e in Ucraina.

Chi è Calypso / Red Lamassu


Calypso è un gruppo APT di matrice cinese attivo almeno dal 2018, storicamente orientato allo spionaggio su governi, settore energetico e telecomunicazioni in Asia Centrale e Medio Oriente. Il gruppo condivide infrastrutture e tooling con altri cluster affiliati alla Cina, in linea con il modello del cosiddetto digital quartermaster: una struttura centralizzata che rifornisce più gruppi APT di strumenti comuni come PlugX, ShadowPad e, ora, Showboat. Questa logica di condivisione complica l’attribuzione e amplifica la portata operativa.

Showboat: un framework post-exploitation modulare per Linux


Il punto di partenza dell’indagine è stato un binario ELF caricato su VirusTotal nel maggio 2025, inizialmente classificato come backdoor Linux sofisticato con capacità rootkit (Kaspersky lo traccia come EvaRAT). Showboat è progettato per sistemi Linux con un insieme di capacità modulari orientate alla persistenza silenziosa e al movimento laterale: shell remota per l’esecuzione di comandi arbitrari, trasferimento file bidirezionale, proxy SOCKS5 per il tunneling verso sistemi interni non esposti su internet, raccolta di informazioni di sistema, nascondimento dei processi dalla lista dei processi attivi, e recupero di payload da Pastebin (paste creato l’11 gennaio 2022) — tecnica che frammenta la kill chain su piattaforme legittime per eludere il rilevamento.

Il malware comunica con il server C2 trasmettendo informazioni di sistema in un campo PNG come stringa cifrata in Base64. La funzione proxy SOCKS5 è particolarmente significativa: consente agli attaccanti di interagire con macchine raggiungibili solo via LAN, espandendo silenziosamente il perimetro di compromissione verso asset interni critici.

JFMBackdoor: un impianto Windows a pieno spettro


A fianco di Showboat, i ricercatori hanno identificato JFMBackdoor, un impianto Windows distribuito tramite DLL side-loading. Si tratta di un RAT completo con accesso shell remoto, operazioni su file (upload, download, eliminazione), network proxying, cattura di screenshot e auto-rimozione (self-removal) per cancellare le tracce post-operazione. Il vettore DLL side-loading è un classico dei toolkit cinesi: consente di agganciare un processo legittimo per l’esecuzione del codice malevolo, riducendo la visibilità per le soluzioni EDR.

Vittime identificate e infrastruttura C2


L’analisi infrastrutturale ha rilevato le seguenti compromissioni: un provider di telecomunicazioni nel Medio Oriente (vittima principale, bersagliata almeno dal 2022), un ISP in Afghanistan, un’entità in Azerbaigian, due possibili compromissioni negli Stati Uniti e una in Ucraina, identificate tramite un cluster C2 secondario che condivide certificati X.509 con quello primario.

I nodi C2 mostrano correlazioni geografiche con indirizzi IP geolocalizzati a Chengdu, capoluogo della provincia del Sichuan — area già associata ad operazioni APT cinesi come quelle di APT41. La presenza di infrastruttura condivisa con altri cluster cinesi, tramite certificati e pattern C2 analoghi, rinforza l’ipotesi del digital quartermaster. Il gruppo ha registrato domini tematici che impersonano operatori telecom per rendere il traffico C2 meno sospetto.

Perché le telco sono obiettivi privilegiati dello spionaggio cinese


Le infrastrutture di telecomunicazione rappresentano un obiettivo di primaria importanza per le operazioni di intelligence offensiva. Il controllo, anche parziale, di un operatore telecom offre accesso a metadati di traffico, possibilità di intercettazioni mirate, informazioni su clienti governativi e aziendali, e capacità di prepararsi per operazioni disruptive in scenari di escalation geopolitica. Non è un caso che Showboat sia progettato specificatamente per Linux: i sistemi basati su questo OS costituiscono il backbone infrastrutturale della maggior parte delle telco mondiali. La funzione SOCKS5 rispecchia un obiettivo preciso: muoversi lateralmente e silenziosamente all’interno di reti segmentate, raggiungendo asset normalmente inaccessibili dall’esterno.

Indicatori di compromissione (IoC)

# Showboat - ELF binary (VirusTotal, maggio 2025)
SHA256: d6a4fad5448838dbc8cc6b33f1dbfbdc7a2fad36de58ff6a66dce96f729f7011
# Kaspersky classification: EvaRAT
# C2 infrastructure: IP geolocati a Chengdu (Sichuan, CN)
# Certificati X.509 condivisi tra cluster C2 primario e secondario
# Domini: pattern telecom-themed (impersonazione operatori target)
# Pastebin paste ID: creato 2022-01-11 (autoconcealment snippet)

Due righe per i difensori


Per le organizzazioni del settore telecomunicazioni e infrastrutture critiche, i ricercatori di Black Lotus Labs raccomandano: monitorare il traffico in uscita verso Pastebin e piattaforme di condivisione testo per rilevare scaricamenti di payload; analizzare le connessioni SOCKS5 anomale verso host interni non esposti; verificare l’integrità dei processi su sistemi Linux alla ricerca di tecniche di process hiding; implementare threat hunting specifico per DLL side-loading su endpoint Windows; correlare i certificati X.509 dei server C2 con quelli osservati da Black Lotus Labs. Come ha sottolineato il ricercatore Danny Adamitis: “La presenza di tali minacce dovrebbe essere interpretata come un segnale d’allarme precoce, indicativo di problemi di sicurezza potenzialmente più gravi e diffusi all’interno delle reti compromesse.”


The Pirate Post ha ricondiviso questo.

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

LiteSpeed cPanel Plugin Zero-Day (CVE-2026-48172) Actively Exploited to Gain Server Root Access
#CyberSecurity
securebulletin.com/litespeed-c…
The Pirate Post ha ricondiviso questo.

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

Microsoft Identity Manager 2016 SP3: supporto SQL Server 2022, Azure SQL con Managed Identity e AD FS SSO
#tech
spcnet.it/microsoft-identity-m…
@informatica


Microsoft Identity Manager 2016 SP3: supporto SQL Server 2022, Azure SQL con Managed Identity e AD FS SSO


MIM 2016 SP3: finalmente disponibile, con un percorso travagliato


Microsoft Identity Manager (MIM) 2016 Service Pack 3 è diventato generalmente disponibile il 14 maggio 2026, dopo una storia piuttosto movimentata: una prima versione era stata rilasciata a fine marzo 2026 ma Microsoft l’aveva silenziosa ritirata senza spiegazioni pubbliche. SP3 si posiziona come un aggiornamento di compatibilità di piattaforma più che una rivisitazione architetturale del prodotto, ma include alcune novità tecnicamente significative per gli scenari ibridi e cloud.

Per chi gestisce ambienti enterprise con Active Directory e sincronizzazione delle identità, MIM rimane un componente critico in molte organizzazioni. Con l’estensione del supporto fino al 9 gennaio 2029 (la data originale era gennaio 2026), Microsoft ha chiarito che il prodotto ha ancora vita davanti a sé, almeno come soluzione di transizione verso Entra ID Governance.

Principali aggiornamenti di compatibilità di piattaforma


SP3 estende la compatibilità ufficiale con le versioni più recenti degli stack Microsoft on-premise e cloud. I componenti aggiornati includono:

  • SQL Server 2022 — supporto completo per il database di MIM Service e MIM Synchronization Service
  • SharePoint Server Subscription Edition (SE) — il portale MIM può essere ospitato su SharePoint SE
  • Exchange Server Subscription Edition (SE) — supporto per la gestione delle cassette postali Exchange tramite MIM
  • System Center Service Manager DW 2022 — compatibilità aggiornata per gli scenari di data warehouse
  • Windows Server 2025 — supporto per il sistema operativo host aggiornato

Questi aggiornamenti sono fondamentali per le organizzazioni che hanno già migrato i propri server on-premise alle versioni più recenti e si trovavano a gestire MIM su stack non ufficialmente supportati, una situazione rischiosa dal punto di vista del supporto Microsoft.

Azure SQL Database per MIM Synchronization: la novità più rilevante


La novità tecnicamente più interessante di SP3 è il supporto nativo per Azure SQL Database come backend del MIM Synchronization Service, con autenticazione tramite managed identity. Questa funzionalità apre un nuovo scenario di deployment ibrido dove il motore di sincronizzazione di MIM può connettersi a un database gestito nel cloud senza dover gestire credenziali SQL esplicite in chiaro.

System-assigned vs User-assigned Managed Identity


SP3 supporta entrambe le varianti di managed identity per l’autenticazione verso Azure SQL:

  • System-assigned managed identity — legata al ciclo di vita del server MIM Sync, viene creata e dismessa automaticamente con la macchina virtuale. Più semplice da configurare, ma meno flessibile in scenari di disaster recovery o migrazione del server.
  • User-assigned managed identity — un’identità indipendente che può essere assegnata a più risorse e sopravvive alla VM. Preferita negli ambienti enterprise per la flessibilità e la possibilità di condividere le autorizzazioni tra più istanze server.

In entrambi i casi, la managed identity deve essere configurata come External provider nel database Azure SQL e deve avere il ruolo db_owner (o i permessi minimi necessari) sullo schema MIM. La configurazione lato MIM avviene nel file di configurazione del Synchronization Service, specificando il tipo di autenticazione ActiveDirectoryManagedIdentity nella stringa di connessione.

Considerazioni pratiche sul deployment


Portare il database di MIM Sync su Azure SQL offre vantaggi concreti: alta disponibilità integrata, backup automatici, scaling elastico e riduzione del carico operativo sulla DBA. Tuttavia, le latenze di rete tra il server MIM Sync on-premise e Azure SQL devono essere valutate con attenzione. Cicli di sincronizzazione su connector con milioni di oggetti — come un Full Import su Active Directory con 200.000+ account — potrebbero risentire della latenza aggiuntiva rispetto a un SQL Server locale.

È consigliabile testare questa configurazione in ambiente di staging misurando i tempi dei management agent profile più pesanti (Full Import, Full Sync) prima di portarla in produzione.

AD FS SSO per il portale MIM: claims-based authentication


SP3 introduce il supporto per Active Directory Federation Services (AD FS) con autenticazione SSO basata su claims per il portale MIM. In precedenza, il portale si basava esclusivamente sull’autenticazione Windows integrata (Kerberos/NTLM). Con SP3, gli utenti possono autenticarsi al portale tramite AD FS, il che apre alcune possibilità interessanti:

  • Supporto per scenari in cui i client non sono domain-joined (utenti che accedono dall’esterno tramite Web Application Proxy)
  • Possibilità di applicare policy di autenticazione più granulari tramite AD FS, inclusi MFA e device compliance
  • Percorso di transizione verso Entra ID per organizzazioni che già federano le identità tramite AD FS

La configurazione richiede la registrazione del portale MIM come Relying Party Trust in AD FS e la corretta configurazione delle claim rules per mappare gli attributi utente alle autorizzazioni MIM. Microsoft ha aggiornato la documentazione ufficiale su Microsoft Learn con le istruzioni dettagliate per questo scenario.

Estensione del supporto: una boccata d’aria per i team IT


Forse la notizia più impattante per molte organizzazioni non è tecnica, ma temporale. La data di fine supporto di MIM 2016 è stata estesa dal 13 gennaio 2026 al 9 gennaio 2029 — tre anni in più. Per i team IT che stavano affrontando una corsa contro il tempo per migrare a Entra ID Governance, questa estensione offre una finestra più ampia per pianificare la transizione con la dovuta attenzione.

È comunque importante non interpretare questa estensione come un segnale che MIM riceverà nuove funzionalità significative. Microsoft è chiara: il percorso raccomandato per la gestione del ciclo di vita delle identità punta a Microsoft Entra ID Governance. MIM è in maintenance mode.

Come pianificare l’upgrade a SP3


Per chi gestisce MIM 2016, ecco i passi raccomandati:

  1. Verifica la versione corrente — la build di SP3 è 4.7.6.0. Controlla la versione installata tramite Programmi e Funzionalità o il registro di sistema.
  2. Consulta la matrice di compatibilità ufficiale su Microsoft Learn per identificare eventuali combinazioni di piattaforma non più supportate.
  3. Testa in staging prima della produzione, verificando la compatibilità con management agent personalizzati e regole di sincronizzazione custom.
  4. Valuta Azure SQL con managed identity se vuoi ridurre il debito operativo del database on-premise.
  5. Pianifica la migrazione a lungo termine verso Entra ID Governance, usando questo upgrade come occasione per documentare i processi attuali.


Conclusione


MIM 2016 SP3 è un aggiornamento pragmatico e necessario per le organizzazioni enterprise che ancora dipendono da questo strumento. L’aggiunta del supporto per Azure SQL con managed identity è la novità più rilevante dal punto di vista architetturale, mentre il supporto AD FS SSO colma una lacuna significativa per i deployment con accesso esterno al portale. L’estensione del supporto al 2029 completa il quadro, dando ai team IT il tempo necessario per una migrazione pianificata e non forzata verso le soluzioni cloud-native di Microsoft.


Fonti: 4sysops — MIM 2016 SP3 | Microsoft Learn — MIM 2016 news and updates | Identity Manager version history


Meeting Cancelled for 5/24


May 22

Due to the holiday weekend, the Pirate National Committee open meeting has been cancelled.

We apologize to anyone who was anticipating being at said meeting. Needless to say, we will still be on schedule for May 31st.

There will be no meeting on Sunday, June 7th at the conclusion of the Pirate National Conference.

Open meetings will return officially on June 21st.

Happy Memorial Day weekend! Don’t forget to tune in tomorrow to watch Drew Bingaman on Talk the Plank! at NoonET, and sign up to attend the conference!


uspirates.org/meeting-cancelle…

Elezioni e Politica 2026 reshared this.

The Pirate Post ha ricondiviso questo.

Nuovo successo giudiziario di NOYB che può fare da precedente in Europa: i pulsanti per "accettare" o "rifiutare" i cookie di tracciamento siano identici

L'emittente radiotelevisiva austriaca ORF (Austrian Broadcasting Corporation) deve modificare il banner sui cookie presente sul sito ORF.at per adeguarlo al GDPR. Lo ha stabilito il Tribunale amministrativo federale (BVwG), confermando così una decisione dell'Autorità austriaca per la protezione dei dati del 2024. Nello specifico, l'ORF deve garantire che i pulsanti per "accettare" o "rifiutare" i cookie di tracciamento siano identici, in modo da non indurre i visitatori ad acconsentire involontariamente . Attualmente, l' opzione "Accetta" è evidenziata in modo fuorviante con un colore diverso, il che può portare a un consenso involontario.

Il post di @noyb.eu

noyb.eu/en/noyb-success-orfat-…

@Privacy Pride

The Pirate Post ha ricondiviso questo.

Se vi siete persi la bellissima conferenza di Massimo Carboni del GARR sull'autonomia delle infrastrutture digitali per la ricerca, guardatela qui: garr.tv/w/7LkaeMuudf5SpHoppSoc… In particolare: "20 anni fa abbiamo delegato l'email. Oggi abbiamo rinunciato a capire come funzionano i sistemi complessi" (qui: garr.tv/w/7LkaeMuudf5SpHoppSoc…)
Questa voce è stata modificata (2 settimane fa)
The Pirate Post ha ricondiviso questo.

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

L’uscita di Tulsi Gabbard dall’intelligence USA e gli scenari di sicurezza nazionale
#CyberSecurity
insicurezzadigitale.com/luscit…


L’uscita di Tulsi Gabbard dall’intelligence USA e gli scenari di sicurezza nazionale


Le dimissioni di Tulsi Gabbard dalla guida dell’intelligence americana non sono più soltanto indiscrezioni filtrate da ambienti politici di Washington. Dopo ore di speculazioni, la conferma è arrivata direttamente tramite Fox News e successive dichiarazioni ufficiali della Casa Bianca: Gabbard lascerà il ruolo di Director of National Intelligence il 30 giugno 2026.

Nella lettera inviata al presidente Donald Trump, Gabbard ha motivato la decisione con il peggioramento delle condizioni di salute del marito, Abraham Williams, recentemente diagnosticato con una rara forma di tumore osseo. La direttrice dell’intelligence ha scritto di non poter “in coscienza” lasciarlo affrontare da solo la malattia mentre continua a ricoprire un incarico tanto invasivo e operativo.

Formalmente, quindi, la narrativa ufficiale parla di una scelta personale e familiare. Ma le fonti interne all’amministrazione raccontano uno scenario molto più complesso. Diversi insider citati dalla stampa americana sostengono infatti che Gabbard fosse ormai considerata politicamente isolata all’interno dell’apparato Trump e che la Casa Bianca stesse già valutando da tempo una sua sostituzione.

Secondo le ricostruzioni emerse nelle ultime settimane, il rapporto con Trump si sarebbe deteriorato progressivamente dopo una serie di contrasti su Iran, operazioni di sicurezza nazionale e gestione delle valutazioni intelligence. Uno degli episodi più delicati riguarda proprio le analisi sull’Iran: Gabbard aveva dichiarato davanti al Senato che non esistevano prove concrete di una ripresa del programma nucleare iraniano, entrando indirettamente in collisione con la linea più aggressiva sostenuta dall’amministrazione.

Da quel momento, il suo peso operativo sarebbe diminuito rapidamente. Secondo varie fonti, Gabbard sarebbe stata esclusa da alcuni briefing strategici sensibili e marginalizzata nelle decisioni relative alle operazioni internazionali. Parallelamente, all’interno della Casa Bianca cresceva la convinzione che il DNI non fosse più pienamente allineato alla postura politica dell’amministrazione Trump.

La dinamica con cui la notizia è emersa è particolarmente significativa. Prima ancora dell’annuncio ufficiale, numerosi leak avevano iniziato a circolare verso media statunitensi vicini agli ambienti governativi, descrivendo Gabbard come una figura in uscita già da settimane. In ambienti intelligence questo tipo di comunicazione viene spesso interpretato come una pressione politica indiretta: rendere pubblica una possibile sostituzione serve a indebolire ulteriormente il funzionario interessato e preparare il terreno alla transizione.

Trump ha pubblicamente elogiato il lavoro di Gabbard, definendola una figura che ha svolto “un grande lavoro” alla guida dell’intelligence americana, ma contemporaneamente ha annunciato immediatamente il nome del sostituto ad interim: Aaron Lukas.

Ed è proprio questo passaggio a essere particolarmente rilevante per chi osserva il settore intelligence e cybersecurity. Aaron Lukas non arriva dall’esterno ma dall’apparato interno dell’ODNI, dove ricopriva il ruolo di Principal Deputy Director of National Intelligence dal 2025. La scelta di una figura già integrata nella struttura suggerisce la volontà della Casa Bianca di evitare ulteriori scossoni in una fase estremamente delicata sul piano geopolitico e cyber.

La successione avviene infatti mentre gli Stati Uniti stanno affrontando una delle fasi più aggressive degli ultimi anni sul fronte cyber-intelligence: campagne APT attribuite a Cina, operazioni ibride riconducibili a Iran, tensioni crescenti con Russia e un ecosistema ransomware sempre più vicino a logiche di destabilizzazione geopolitica.

In questo contesto, il problema non è soltanto il cambio di leadership. Il vero nodo riguarda ciò che emerge dietro le dimissioni: una frattura sempre più evidente tra vertice politico e comunità intelligence americana. E quando questo accade negli Stati Uniti, le conseguenze raramente restano interne a Washington.


The Pirate Post ha ricondiviso questo.

#openaccess Risposta di SPARC pensata per gli USA da estendere anche ai vassalli italiani:

  1. Distinguere fra accesso aperto e pubblicazione a pagamento
  2. Riconoscere che la pubblicazione a pagamento non solo drena denaro pubblico, ma deteriora la qualità della ricerca
  3. Non trattare le condizioni del "mercato" (*) editoriale attuali come immutabili

(*) Con le virgolette perché il complesso oligarchico editorial-accademico non ha proprio nulla a che vedere con Adam Smith


Update. Also see the excellent #SPARC response to the #GAO report.
sparcopen.org/news/2026/sparc-…

"We urge Congress and federal agencies to:
1. Distinguish public access from pay-to-publish…
2. Recognize that pay-to-publish doesn’t just cost the government and taxpayers more; it compromises the science it purports to support…
3. Decline to treat current market conditions as fixed…."

#APCs #OpenAccess #ScholComm #USPol #USPolitics


Judge angled for federal gig while hearing Trump’s Pulitzer suit


Dear Friend of Press Freedom:

ABC seems to have found its spine, but whether attorney and judicial watchdogs will follow suit when lawless lawyers harm the free press remains an open question. Meanwhile, a major government transparency win temporarily ensures that presidential records can’t be destroyed or locked away. Here’s more on what we’ve been working on to protect press freedom.

Complaint: Judge angled for federal gig while hearing Trump’s Pulitzer suit


A new complaint filed by Freedom of the Press Foundation (FPF) with a judicial ethics commission argues that Jeffrey Kuntz, chief judge of a Florida appeals court, violated his ethical duties by ruling in President Donald Trump’s favor in a defamation lawsuit while simultaneously seeking a nomination from Trump to the federal judiciary.

Kuntz failed to recuse himself from Trump’s frivolous defamation lawsuit against the Pulitzer Prize Board or disclose his conflict of interest to the parties. Two weeks after he ruled for Trump, the White House Counsel’s Office interviewed Kuntz for a judicial vacancy. He’s since been nominated to the federal bench.

“Trump can’t win his SLAPP suits on the merits, so he finds ways to corrupt the court system instead,” said Seth Stern, FPF’s chief of advocacy. “Attorney disciplinary commissions are notorious for inaction, often functioning more like protection rackets for lawyers and judges than regulators. That said, we hope the commission will rise to the moment and do the right thing.”


Press groups rally behind ABC as FCC targets ‘The View’


The American Broadcasting Company is (finally) living up to its name by standing up for a vital American value.

This week, a coalition of press freedom groups led by FPF joined an open letter in solidarity with ABC, which recently took a stand against the Federal Communications Commission, accusing the agency in an FCC filing of attempting to “chill critical protected speech.”

“Corporate owners only invite more bullying when they capitulate,” said FPF Deputy Director of Advocacy Adam Rose. “But history shows that fighting back is a winning formula.”


Court orders Trump team to preserve presidential records


A federal judge has temporarily ordered the Trump administration officials to follow the Presidential Records Act and preserve text messages, including Signal messages, related to its work. The judge issued the order in response to a motion filed in a lawsuit brought by FPF, Citizens for Responsibility and Ethics in Washington, the American Historical Association, and American Oversight.

As FPF Daniel Ellsberg Chair on Government Secrecy Lauren Harper said, the court’s order “takes an important step in ensuring that presidential records remain exactly what they have been for nearly 50 years: public property.” For more on the lawsuit, subscribe to FPF’s newsletter on government secrecy, The Classifieds.


Paramount, Ellisons silent on Trump CNN threats


Our shareholder demand to Paramount earlier this month focused on CEO David Ellison trading journalistic independence for merger approval. Ellison reportedly promised Trump “sweeping” changes at CNN if he buys its parent company, Warner Bros. Discovery.

It made headlines, but one issue it raised deserves more attention, as FPF Executive Director Trevor Timm explained in a recent video. Last month, Trump took to Truth Social and announced a criminal investigation after CNN quoted an Iranian statement he didn’t like. Any investigation would be totally frivolous, but the president personally threatening a company you’re seeking to buy is a big deal.

But David Ellison and his centibillionaire father and financier Larry haven’t said a word — either about the threat’s materiality to the transaction or in defense of the rights of the journalists they hope to soon employ. That’s how little they care about both their shareholders and press freedom.


New bill seeks to curb abusive subpoenas


Administrative subpoenas allow the government to demand records from big tech and phone companies, in secret and without ever going before a judge. So it’s no surprise that the Trump administration has been caught exploiting them to target its online critics and watchdogs.

A new bipartisan bill in Congress, the Subpoena Abuse Prevention Act, would rein in those abuses. That’s good news for journalists, whose phone records have been targeted by both Democratic and Republican administrations.

“For journalists in particular, phone records can expose sensitive information about communications with confidential sources,” FPF Senior Adviser Caitlin Vogus explained. “This legislation would strengthen protections for those communications and help ensure that journalists cannot be targeted with subpoenas for doing their jobs.”


What we're reading


The Trump administration arrested this journalist. She says the censorship is ongoing

The Washington Post
The government’s baseless criminal charges against Minnesota-based journalist Georgia Fort are discouraging her from speaking to sources. They should be dropped immediately, along with the cases brought against other journalists who covered the St. Paul church protest.


Trust no one in the ‘Mangionista’ debate over who is doing real journalism in NYC

Hell Gate
Chris Robbins, who had to sue the New York City Police Department so Gothamist could get press passes after eight years of waiting, gets it right: “Don’t we want to keep the definition of ‘journalist’ as wide as possible? Isn’t the alternative an invitation to the government to start pulling the ladder up on who gets to be a reporter?”


PSC reverses student magazine decision after blocking publication of LGBTQ stories

WEAR News
It’s good that Pensacola State College changed course, but it’s outrageous that it ever happened. Don’t colleges have professors and lawyers on hand with the minimal level of familiarity with the First Amendment needed to spot the constitutional problems here?


Democratic senators demand release of U.S. report on killing of Palestinian-American journalist Shireen Abu Akleh

Haaretz
It’s been more than four years since Palestinian-American journalist Shireen Abu Akleh was shot dead in the West Bank. It’s time for the U.S. to open up its investigation into her death.


How a landlord tried to silence tenants and stop a Shelterforce story

Shelterforce
A landlord threatened a tenants’ union for speaking to the press before they’d settled a case and agreed to refrain from making public statements. That’s wrong. “The public deserves to know what’s going on in their communities economically [and] socially. If people are afraid to talk to reporters, we are poorer as a society for it,” FPF’s Rose explained.


Notre Dame pro-abortion-rights professor ordered to pay $200k in fees in failed libel lawsuit against student newspaper

The Volokh Conspiracy
SLAPPs, or strategic lawsuits against public participation, targeting journalists are always wrong, but it’s especially galling for a professor to try to use the legal system to silence a student newspaper. Hopefully this fee award will deter others who try to bully student journalists.


freedom.press/issues/judge-ang…

Elezioni e Politica 2026 reshared this.

The Pirate Post ha ricondiviso questo.

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

Google Patches Two Critical Chrome RCE Flaws in Urgent Update — Update to 148.0.7778.178 Now
#CyberSecurity
securebulletin.com/google-patc…
The Pirate Post ha ricondiviso questo.

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

Dark Web Brokers Flood Forums With Recycled Breach Data Disguised as Fresh Corporate Leaks
#CyberSecurity
securebulletin.com/dark-web-br…
The Pirate Post ha ricondiviso questo.

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

Operation Saffron: International Authorities Dismantle ‘First VPN’ Criminal Network Linked to Global Ransomware Attacks
#CyberSecurity
securebulletin.com/operation-s…
The Pirate Post ha ricondiviso questo.

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

Azure Linux 4.0: Microsoft adotta Fedora come upstream e lancia Azure Container Linux in GA
#tech
spcnet.it/azure-linux-4-0-micr…
@informatica


Azure Linux 4.0: Microsoft adotta Fedora come upstream e lancia Azure Container Linux in GA


Microsoft ha annunciato ufficialmente Azure Linux 4.0 all’Open Source Summit North America, tenutosi a Minneapolis il 18 maggio 2026. Con questa release, la distribuzione Linux di Microsoft — precedentemente nota come CBL-Mariner — compie un salto architetturale significativo: abbandona il proprio sistema di packaging indipendente e adotta Fedora Linux come upstream base, mantenendo il formato RPM e le personalizzazioni specifiche per Azure.

In parallelo, Microsoft ha annunciato la disponibilità generale di Azure Container Linux, un sistema operativo immutabile ottimizzato per workload containerizzati su Azure.

Dalla CBL-Mariner ad Azure Linux: una breve storia


CBL-Mariner (Common Base Linux Mariner) è nata internamente in Microsoft come distribuzione Linux leggera per supportare i propri servizi cloud e dispositivi. Nel 2022 è stata rinominata Azure Linux e resa open source, diventando la base di alcune immagini ufficiali per Azure Virtual Machines e Azure Kubernetes Service (AKS).

Azure Linux 3 è ancora la versione stabile consigliata per la produzione. Azure Linux 4.0 è attualmente in public preview su Azure Virtual Machines.

Il cambio fondamentale: Fedora come upstream


Il cambiamento più rilevante di Azure Linux 4 riguarda il modello di sviluppo del packaging. Microsoft ha scelto di derivare i propri pacchetti direttamente dalle sorgenti Fedora, invece di mantenere spec RPM scritti internamente da zero.

Dal README del repository GitHub ufficiale:

“Azure Linux is an open-source Linux distribution built and optimized for Azure, with sources derived from Fedora Linux.”


In pratica, il sistema è definito tramite file di configurazione TOML e overlay mirati applicati sopra i sorgenti di packaging di Fedora. Microsoft ha dichiarato che questi overlay sono volutamente limitati per evitare una divergenza eccessiva dall’upstream.

Struttura tecnica del repository


Il repository di Azure Linux 4 include spec RPM generati automaticamente, prodotti applicando gli overlay di Azure Linux ai sorgenti upstream di Fedora. Questi file sono inclusi nel repository per garantire trasparenza e auditabilità della supply chain.

Per la build vengono usati gli strumenti RPM standard dell’ecosistema Fedora/RHEL:

# Build di un pacchetto con mock (ambiente isolato)
mock -r azurelinux-4-x86_64 --rebuild pacchetto.src.rpm

# Build diretta con rpmbuild
rpmbuild -ba SPECS/pacchetto.spec

# Build con Koji (sistema di build distribuito)
koji build azurelinux4 pacchetto.src.rpm

L’uso di tooling standard come mock, rpmbuild e Koji è una scelta deliberata: chi conosce già l’ecosistema Fedora o RHEL può contribuire ad Azure Linux senza dover imparare strumenti proprietari.

Vantaggi del modello Fedora-based


Adottare Fedora come upstream porta vantaggi concreti su più fronti:

  • Sicurezza e patch veloci: le vulnerabilità risolte upstream in Fedora possono essere incorporate rapidamente, senza dover riapplicare patch su spec mantenuti separatamente
  • Ecosistema di pacchetti più ampio: Fedora ha un repository di pacchetti molto più vasto di quello che Microsoft poteva mantenere autonomamente in CBL-Mariner
  • Toolchain familiare: dnf, rpm, mock, Koji — strumenti già noti a migliaia di amministratori di sistema
  • Audit della supply chain: gli spec generati automaticamente e committati nel repo rendono verificabile ogni dipendenza


Azure Container Linux: l’alternativa immutabile


Annunciato in GA insieme ad Azure Linux 4.0 Preview, Azure Container Linux è una distribuzione separata, progettata specificamente per workload containerizzati. Le caratteristiche principali:

  • Sistema operativo immutabile: il filesystem di sistema è read-only; gli aggiornamenti avvengono per sostituzione dell’intera immagine, non pacchetto per pacchetto
  • Ottimizzato per AKS: superficie di attacco ridotta, nessun package manager esposto, avvio rapido
  • Aggiornamenti atomici: simile all’approccio di Flatcar Linux o CoreOS, con rollback automatico in caso di failure

I due prodotti si rivolgono a use case diversi: Azure Linux 4 per VM general purpose, Azure Container Linux per nodi Kubernetes e workload container-native.

Come provare Azure Linux 4.0 su Azure


Azure Linux 4.0 è disponibile in public preview su Azure Virtual Machines. Per creare una VM con questa immagine tramite Azure CLI:

# Cerca l'immagine Azure Linux 4 disponibile
az vm image list   --publisher MicrosoftCBLMariner   --offer azure-linux-4   --all   --output table

# Crea una VM in anteprima
az vm create   --resource-group myResourceGroup   --name myAzureLinux4VM   --image MicrosoftCBLMariner:azure-linux-4:azure-linux-4-gen2:latest   --size Standard_D2s_v5   --admin-username azureuser   --generate-ssh-keys

Per chi vuole esplorare il codice sorgente o contribuire, il repository è disponibile su GitHub nel branch 4.0:
git clone https://github.com/microsoft/azurelinux.git
cd azurelinux
git checkout 4.0

Cosa rimane invariato


Nonostante il cambio di upstream, Microsoft mantiene le caratteristiche distintive di Azure Linux:

  • Ottimizzazioni kernel specifiche per Azure (driver paravirtualizzati, supporto RDMA, ecc.)
  • Integrazione nativa con Azure Monitor, Azure Arc e gli altri servizi della piattaforma
  • Conformità agli standard di sicurezza Microsoft (FIPS 140-3, CIS Benchmark)
  • Ciclo di supporto allineato alle esigenze enterprise


Considerazioni per i sysadmin


Per chi gestisce infrastrutture su Azure, Azure Linux 4 rappresenta un’evoluzione interessante. L’allineamento con Fedora significa che le competenze RPM già acquisite su RHEL o CentOS Stream sono direttamente applicabili. La toolchain di build è quella standard, la documentazione upstream è più ricca, e le patch di sicurezza arriveranno più velocemente.

Il consiglio di Microsoft di restare su Azure Linux 3 per i workload in produzione è ragionevole: la versione 4 è ancora in preview attiva. Tuttavia, per chi gestisce ambienti di test o vuole prepararsi alla migrazione, vale la pena esplorare il repository e familiarizzare con la nuova struttura già adesso.


Fonte: Linuxiac — Microsoft Azure Linux 4 Moves to a Fedora-Based Foundation | Microsoft Open Source Blog


The Pirate Post ha ricondiviso questo.

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

WantToCry Ransomware Encrypts Files Remotely Over SMB — No Malware Required
#CyberSecurity
securebulletin.com/wanttocry-r…
The Pirate Post ha ricondiviso questo.

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

Guida ai file di log su Linux: leggere, cercare e gestire i log con tail, grep e journalctl
#tech
spcnet.it/guida-ai-file-di-log…
@informatica


Guida ai file di log su Linux: leggere, cercare e gestire i log con tail, grep e journalctl


Perché i log sono il primo posto dove guardare


Quando qualcosa si rompe su un sistema Linux, i log sono quasi sempre la prima risposta. Eppure molti amministratori li consultano solo come ultima risorsa, quando ormai il danno è fatto. I log raccontano cosa sta facendo il sistema adesso, cosa ha fatto ieri notte, e cosa esattamente è andato storto alle 3:00 di questa mattina. Imparare a leggerli, cercarli e gestirli è una delle competenze fondamentali di ogni sysadmin.

Questa guida copre i file di log che ogni amministratore Linux dovrebbe conoscere, gli strumenti per cercarli in modo efficiente, e come evitare che crescano fino a riempire il disco.

Dove vivono i log su Linux


La maggior parte dei file di log si trova sotto /var/log/. Alcuni sono testo semplice, altri sono binari e richiedono strumenti dedicati per essere letti. Ecco i più importanti:

  • /var/log/syslog (Debian/Ubuntu) o /var/log/messages (RHEL/CentOS/Fedora) — messaggi generali di sistema da kernel e servizi.
  • /var/log/auth.log (Debian/Ubuntu) o /var/log/secure (RHEL/CentOS/Fedora) — tentativi di autenticazione, uso di sudo, accessi SSH.
  • /var/log/kern.log — messaggi specifici del kernel. Utile per problemi hardware e driver.
  • /var/log/dmesg — output del kernel ring buffer dal boot. Accessibile anche tramite il comando dmesg.
  • /var/log/dpkg.log — cronologia di installazione, rimozione e aggiornamento pacchetti su sistemi Debian.
  • /var/log/dnf.log o /var/log/yum.log — equivalente per Fedora/RHEL.
  • /var/log/apache2/ o /var/log/httpd/ — log di accesso ed errore di Apache.
  • /var/log/nginx/ — log di accesso ed errore di Nginx.
  • /var/log/mysql/ — log degli errori MySQL.
  • /var/log/cron o /var/log/cron.log — cronologia di esecuzione dei cron job.

Sui sistemi moderni basati su systemd, molti di questi log tradizionali sono affiancati o sostituiti dal journal di systemd. Ne parliamo nella sezione dedicata a journalctl.

Lettura di base: tail, less e cat


Per i file di testo semplice, gli strumenti classici funzionano benissimo.

Visualizzare la coda del log

tail /var/log/syslog

Seguire un log in tempo reale

tail -f /var/log/syslog

Utile quando si sta riproducendo un problema in diretta. Per seguire più file contemporaneamente:
tail -f /var/log/syslog /var/log/auth.log

Sfogliare il log completo con paginazione

less /var/log/syslog

All’interno di less: G salta alla fine, g torna all’inizio, /pattern cerca un termine. Molto più veloce di quanto sembri.

Ricerca nei log con grep


Quando un log cresce oltre qualche MB, scorrere manualmente diventa inutile. grep è lo strumento principale per filtrare le righe rilevanti.

Trovare tutti i fallimenti di autenticazione SSH

grep "Failed password" /var/log/auth.log

Ricerca case-insensitive

grep -i "error" /var/log/syslog

Mostrare il contesto intorno a ogni match (3 righe prima e dopo)

grep -C 3 "Out of memory" /var/log/syslog

Ricerca ricorsiva in una directory

grep -r "connection refused" /var/log/nginx/

Contare quante volte appare un pattern

grep -c "Failed password" /var/log/auth.log

Filtrare per una data specifica

grep "^May 21" /var/log/syslog

Combinare tail e grep per cercare solo nelle righe recenti

tail -n 500 /var/log/syslog | grep "error"

Il journal di systemd: journalctl


Su qualsiasi distro moderna basata su systemd, journalctl è spesso più potente dei file di log tradizionali. Il journal raccoglie output da tutti i servizi, dal kernel e dal processo di boot in un formato binario strutturato e interrogabile.

Comandi essenziali di journalctl

# Tutte le voci del journal (dalla più vecchia)
journalctl

# Dal più recente al più vecchio
journalctl -r

# Seguire il journal in tempo reale (come tail -f)
journalctl -f

# Solo i messaggi del kernel
journalctl -k

# Log di un servizio specifico
journalctl -u nginx
journalctl -u sshd

# Solo dal boot corrente
journalctl -b

# Dal boot precedente (utile dopo un crash o riavvio imprevisto)
journalctl -b -1

# Solo errori e livelli superiori (emergency, alert, critical, error)
journalctl -p err

# Filtro per intervallo di tempo
journalctl --since "2026-05-21 08:00:00" --until "2026-05-21 09:00:00"

# Oppure con tempo relativo
journalctl --since "1 hour ago"

# Output compatto senza pager, utile per piping
journalctl -u sshd -o short --no-pager | tail -50

Il flag --no-pager disabilita l’apertura automatica di less e restituisce l’output direttamente al terminale. Indispensabile quando si vuole fare pipe verso grep o altri strumenti.

Analisi dei log di autenticazione SSH


Il log di autenticazione è uno dei più importanti su qualsiasi server esposto a internet. Se il server ha un IP pubblico, ci saranno tentativi di brute-force costanti. Ecco come analizzarli.

Vedere i fallimenti SSH recenti

# Su Debian/Ubuntu
grep "Failed password" /var/log/auth.log | tail -20

# Su RHEL/CentOS/Fedora
grep "Failed password" /var/log/secure | tail -20

# Su qualsiasi sistema systemd
journalctl -u sshd | grep "Failed password" | tail -20

Trovare gli IP che attaccano di più

grep "Failed password" /var/log/auth.log \
    | grep -oP 'from \K[0-9.]+' \
    | sort | uniq -c | sort -rn | head -10

Questo one-liner estrae l’IP sorgente da ogni riga di login fallito, conta le occorrenze e le ordina per frequenza decrescente. L’anchor sulla parola from mantiene il match corretto indipendentemente dal formato esatto della riga (con o senza “invalid user”). L’output di questo comando è spesso sufficiente a motivare l’installazione immediata di fail2ban.

Log del kernel e del boot con dmesg


Il comando dmesg legge dal kernel ring buffer ed è particolarmente utile per diagnosticare problemi hardware, driver e dischi.

# Tutti i messaggi kernel
dmesg

# Con timestamp leggibili
dmesg -T

# Solo errori e warning
dmesg -T --level=err,warn

# Cercare errori disco
dmesg -T | grep -i "error\|fail\|reset"

Se un disco sta cedendo, si vedranno righe che menzionano il nome del device (sda, nvme0, ecc.) con parole come I/O error o hard resetting link. Non vanno ignorate.

Gestione della rotazione: logrotate


I log mangiano disco se non vengono gestiti. Su quasi tutti i sistemi Linux, logrotate si occupa di questo automaticamente: comprime e ruota i file di log secondo una schedulazione configurabile.

Il file di configurazione principale è /etc/logrotate.conf, mentre le configurazioni per singola applicazione si trovano sotto /etc/logrotate.d/.

Un esempio tipico per Nginx:

/var/log/nginx/*.log {
    daily
    missingok
    rotate 14
    compress
    delaycompress
    notifempty
    create 0640 www-data adm
    sharedscripts
    postrotate
        [ -f /var/run/nginx.pid ] && kill -USR1 `cat /var/run/nginx.pid`
    endscript
}

Le direttive principali da conoscere:
  • daily / weekly / monthly — frequenza di rotazione.
  • rotate 14 — quanti file vecchi conservare prima di cancellare.
  • compress — comprime i log ruotati con gzip.
  • delaycompress — non comprime il log ruotato più di recente (utile per applicazioni che tengono il file aperto brevemente dopo la rotazione).
  • missingok — non genera errore se il file di log non esiste.
  • postrotate — esegue un comando dopo la rotazione, tipicamente per segnalare all’applicazione di riaprire il file di log.


Test e debug di logrotate

# Simulare la rotazione senza eseguirla davvero
sudo logrotate --debug /etc/logrotate.conf

# Forzare la rotazione immediatamente (utile per test)
sudo logrotate --force /etc/logrotate.d/nginx

Gestione della dimensione del journal systemd


Anche il journal di systemd può crescere molto se non monitorato. Verificare l’utilizzo disco e limitarlo:

# Verificare lo spazio occupato dal journal
journalctl --disk-usage

# Ridurre il journal a un massimo di 500 MB
sudo journalctl --vacuum-size=500M

# Mantenere solo le voci degli ultimi 30 giorni
sudo journalctl --vacuum-time=30d

Per impostare un limite permanente, modificare /etc/systemd/journald.conf:
[Journal]
SystemMaxUse=500M
MaxRetentionSec=1month

Dopo la modifica, riavviare il servizio: sudo systemctl restart systemd-journald.

Un workflow pratico per il troubleshooting


Quando si affronta un problema su un server Linux, un approccio sistematico ai log risparmia tempo. Partire da journalctl -p err -b per vedere tutti gli errori del boot corrente, poi restringere con journalctl -u nome-servizio --since "30 min ago" per il servizio specifico. Se il problema è comparso dopo un riavvio, journalctl -b -1 mostra i log del boot precedente. Per problemi hardware, dmesg -T --level=err,warn è spesso la risposta più rapida.

I log su Linux non sono una last resort: sono la prima e più affidabile fonte di verità su cosa sta succedendo nel sistema.


Fonte originale: LinuxBlog.io — Linux Log Files: Guide to Reading, Searching, and Managing Logs di Hayden James.


The Pirate Post ha ricondiviso questo.

Um den Begriff digitale Souveränität ranken sich viele Legenden, wie auch die diesjährige re:publica zeigte. Julia Pohle und Marielle-Sophie Düh unterzogen diese vor Ort einer Wirklichkeitsprüfung. Und sie zeigen eine Alternative zum Buzzword auf.

netzpolitik.org/2026/digitale-…

in reply to netzpolitik.org

@esthermenhard Jetzt habe ich den Text zweimal gelesen, um den alternativen Ausdruck zu finden. Dann begriff ich, dass es nicht eine Alternative ist, sondern mehrere, von denen von Fall zu Fall die treffende zu wählen ist:

Wenn wir in der Debatte um digitale Souveränität weiterkommen wollen, so Pohles und Dühs Fazit, müssen wir auf den Begriff möglichst verzichten. Stattdessen sollten wir klar benennen, um was es uns konkret geht – um Wettbewerbsfähigkeit, um öffentliche Beschaffung, um Grundrechte, um Sicherheitspolitik.


(meine Hervorhebungen)

Man könnte noch mehr aufzählen, aber das dürften die wichtigsten Begriffe sein, wenn Wettbewerbsfähigkeit sehr weit gefasst wird und z.B. Bildung einschließt.

#digitaleSouveränität #digitaleUnabhängigkeit

The Pirate Post 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.

“Patchato” non significa protetto: attaccanti bypassano l’MFA sui VPN SonicWall Gen6 e raggiungono i file server in 30 minuti
#CyberSecurity
insicurezzadigitale.com/patcha…


“Patchato” non significa protetto: attaccanti bypassano l’MFA sui VPN SonicWall Gen6 e raggiungono i file server in 30 minuti


Si parla di:
Toggle

C’è una categoria di vulnerabilità particolarmente insidiosa: quella delle patch che non funzionano perché nessuno ha seguito tutte le istruzioni. È esattamente quello che sta accadendo con i dispositivi SonicWall Gen6 SSL-VPN e CVE-2024-12802, con intrusioni ransomware già documentate in ambienti multipli tra febbraio e maggio 2026.

Il problema: patch firmware vs. rimedio reale


CVE-2024-12802 è una vulnerabilità di authentication bypass nelle appliance SonicWall SSL-VPN. La radice del problema sta in come SonicWall gestisce due diversi formati di login Active Directory: UPN (User Principal Name, il formato simile a un indirizzo email) e SAM (Security Account Manager, il formato legacy). L’enforcement dell’MFA è applicato indipendentemente a ciascun formato di login, non all’identità utente sottostante.

Un attaccante che conosce credenziali valide può autenticarsi usando il percorso UPN anche quando l’MFA è configurata, perché l’enforcement specifico per quel percorso è assente. L’aggiornamento firmware corregge la gestione delle sessioni, ma non rimuove la configurazione LDAP preesistente che consente il bypass. Come spiega ReliaQuest nel loro report: “Patching the firmware doesn’t remove the existing LDAP configuration that allows the bypass; the vulnerable configuration remains in place.”

La rimediazione completa richiede sei passaggi manuali aggiuntivi documentati nel security advisory SNWLID-2025-0001 di SonicWall: cancellare completamente la configurazione LDAP esistente e ricrearla senza il formato userPrincipalName su cui fa leva l’exploit. I workflow standard di patch management non sono progettati per verificare passi di riconfigurazione manuale — la versione firmware viene aggiornata, il controllo versione passa, il dispositivo sembra protetto. Non lo è.

L’exploitation osservata: dalla VPN al file server in 30 minuti


Tra febbraio e marzo 2026, i ricercatori di ReliaQuest hanno documentato quella che valutano come la prima exploitation in-the-wild di CVE-2024-12802 in ambienti multipli. Il pattern di intrusione osservato è stato consistente tra gli incidenti: gli attaccanti eseguono brute force delle credenziali VPN, bypassano l’MFA usando il percorso UPN vulnerabile, e si muovono rapidamente all’interno delle reti.

In alcuni casi, bastano 13 tentativi di brute force per ottenere credenziali valide. In un incidente specifico documentato da ReliaQuest, l’attaccante è passato dall’accesso VPN iniziale a un file server domain-joined, stabilendo una connessione RDP con una password locale condivisa di amministratore, in meno di trenta minuti.

Il comportamento post-compromissione è rivelatorio: dopo aver stabilito il foothold iniziale, l’attaccante ha tentato di distribuire un Cobalt Strike beacon per command-and-control e ha cercato di caricare un driver vulnerabile — probabilmente tramite la tecnica Bring Your Own Vulnerable Driver (BYOVD) per neutralizzare la protezione endpoint. L’EDR presente ha bloccato entrambi i tentativi. Ma l’attaccante si è disconnesso deliberatamente, è tornato giorni dopo usando account diversi, e ha ripetuto il pattern — comportamento più coerente con un initial access broker che valuta il valore della vittima che con un gruppo ransomware in fase di esecuzione immediata.

Il problema dei log: l’MFA sembra funzionare quando non funziona


Una delle caratteristiche più pericolose di questo attacco è il modo in cui appare nei log. Come riportano i ricercatori di ReliaQuest: “The rogue login attempts observed in the investigated incidents still appeared as a normal MFA flow in logs, leading defenders to believe that MFA worked even when it failed.”

Il segnale chiave da cercare nei log di autenticazione VPN è il valore sess="CLI", che indica autenticazione VPN scriptata o automatizzata. La maggior parte delle organizzazioni non monitora attivamente questo campo. I numeri di evento 238 e 1080 sono ulteriori indicatori da inserire nelle regole di alerting.

Dispositivi affetti e stato di fine vita


La vulnerabilità è specifica all’hardware Gen6, che include i modelli NSa 2700, NSa 3700, NSa 4700, NSa 5700 e NSa 6700 con firmware SonicOS 7.0 attraverso 7.1.1. Questo rappresenta un ulteriore problema: i dispositivi Gen6 hanno raggiunto il fine vita il 16 aprile 2026 e non ricevono più aggiornamenti di sicurezza.

Per i dispositivi Gen7 e Gen8, la situazione è diversa: gli aggiornamenti firmware alle versioni 7.2.0-7015 e 8.0.1-8017 incorporano già i passi di rimediazione descritti nell’advisory, e dopo l’upgrade è nuovamente supportato l’uso di userPrincipalName nelle configurazioni LDAP. Il problema è esclusivo al parco installato Gen6.

I settori più colpiti nei casi documentati includono servizi finanziari, sanità e manifatturiero, suggerendo un threat actor con conoscenza specifica del settore e obiettivi di alto valore economico.

Indicatori di compromissione e detection

# LOG INDICATORS (SonicWall SSL-VPN authentication logs)
sess="CLI"          # Autenticazione VPN automatizzata/scriptata - indicatore chiave
Event ID 238        # Evento da monitorare in correlazione con sess=CLI
Event ID 1080       # Evento da monitorare in correlazione con sess=CLI

# BEHAVIORAL INDICATORS
- Accessi VPN da IP appartenenti a VPS o infrastruttura VPN
- Autenticazioni UPN riuscite per account con MFA configurata
- Brute force con numero basso di tentativi (anche solo 13)
- RDP da sistemi interni verso file server entro 30 minuti dall'accesso VPN
- Installazione di Cobalt Strike beacon post-compromissione
- Tentativi di caricamento driver vulnerabili (BYOVD)

# CVE
CVE-2024-12802 - SonicWall SSL-VPN Authentication Bypass (MFA bypass via UPN path)
Advisory: SNWLID-2025-0001

Due righe per i difensori


  • Verifica rimediazione completa: Non basta che il firmware sia aggiornato. Seguire tutti e sei i passaggi manuali dell’advisory SNWLID-2025-0001 di SonicWall — questo include cancellare e ricreare la configurazione LDAP senza userPrincipalName.
  • Caccia retroattiva nei log: Cercare sess="CLI" nei log di autenticazione VPN degli ultimi mesi. Se presente insieme ad autenticazioni “riuscite” per account con MFA attiva, la protezione potrebbe essere stata bypassata in precedenza.
  • Migrazione Gen6: Considerare la migrazione urgente da Gen6 a Gen7/Gen8, dato il fine vita raggiunto ad aprile 2026. Non ci saranno patch per vulnerabilità future su questo hardware.
  • Monitoraggio accessi VPN da range anomali: Alerting su login VPN originati da IP di VPS provider o range VPN, specialmente per account con MFA configurata.
  • Correlazione eventi 238 e 1080: Aggiungere questi event ID alle regole SIEM in correlazione con il campo sess=”CLI”.
  • Revisione LDAP: Verificare che la configurazione LDAP attiva non contenga userPrincipalName come formato di lookup.

Il takeaway più importante di questa vicenda non è tecnico, ma procedurale: i workflow di patch management standard non sono progettati per verificare passi di riconfigurazione manuale. Una patch applicata non è necessariamente una vulnerabilità chiusa. In contesti di sicurezza perimetrale, questo principio va internalizzato nei processi di verifica post-patch.


The Pirate Post 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.

Una riunione urgente su Teams e il conto svuotato: la nuova truffa che sfrutta il panico da videocall
#CyberSecurity
insicurezzadigitale.com/una-ri…


Una riunione urgente su Teams e il conto svuotato: la nuova truffa che sfrutta il panico da videocall


C’è un dettaglio interessante nelle nuove campagne cyber che stanno circolando nelle ultime ore: non cercano più di sembrare sofisticate. Cercano di sembrare normali.

Una notifica su Microsoft Teams.

Un collega che chiede supporto.

Una call urgente prima di una riunione.

E pochi minuti dopo, credenziali rubate, malware installato o conti aziendali compromessi.

Tra le notizie emerse nelle ultime ore nel panorama cybersecurity internazionale, una delle più interessanti riguarda proprio una nuova ondata di attacchi che sfruttano Microsoft Teams come leva di social engineering. Il punto centrale non è tanto la tecnica utilizzata dai criminali, quanto il modo in cui stanno cambiando le abitudini delle vittime.

Per anni il phishing è stato associato a email sospette, allegati strani e messaggi scritti male. Oggi invece gli attaccanti stanno puntando sempre di più sugli strumenti di lavoro quotidiani: Teams, Zoom, Slack, Google Meet.

Perché funzionano.

E soprattutto perché in molte aziende le persone vivono ormai in uno stato costante di urgenza digitale.

La dinamica osservata nelle campagne più recenti è piuttosto semplice. La vittima riceve un messaggio Teams apparentemente legittimo, spesso collegato a un meeting imminente o a un problema tecnico. In alcuni casi viene chiesto di aprire un file condiviso, installare un aggiornamento, autenticarsi nuovamente oppure partecipare rapidamente a una videocall.

Tutto appare plausibile.

È proprio questo il punto.

I criminali non stanno cercando di violare firewall o bypassare vulnerabilità sofisticate. Stanno sfruttando la pressione psicologica tipica dell’ambiente lavorativo moderno.

Una notifica improvvisa durante una giornata piena di call.

Una richiesta urgente del reparto IT.

Un manager che scrive “mi serve subito”.

Nel contesto giusto, il cervello smette di analizzare e inizia semplicemente a reagire.

È questa la vera evoluzione del social engineering nel 2026: attacchi costruiti attorno ai comportamenti umani più che attorno alle vulnerabilità tecniche.

Le piattaforme collaborative sono diventate perfette per questo tipo di operazioni. A differenza delle email tradizionali, gli strumenti di messaggistica aziendale trasmettono automaticamente un senso di fiducia maggiore. Se un messaggio arriva su Teams, molti utenti tendono inconsciamente a considerarlo “interno”, quindi sicuro.

Ed è qui che i criminali stanno trovando spazio.

In diversi scenari osservati negli ultimi mesi, gli attaccanti utilizzano account compromessi reali per avviare conversazioni credibili con dipendenti dell’azienda. In altri casi sfruttano tenant esterni, nickname aziendali o identità molto simili a quelle originali.

L’obiettivo può cambiare.

A volte si tratta di furto credenziali.

Altre volte di installare malware.

In alcuni casi ancora più critici, gli attacchi servono come porta iniziale per intrusioni ransomware.

Ed è qui che il problema smette di essere “solo IT”.

Perché queste campagne funzionano esattamente come funzionano le truffe telefoniche contro gli anziani o le frodi sentimentali online: sfruttano fiducia, fretta e manipolazione emotiva.

La tecnologia cambia.

La psicologia umana molto meno.

Negli ambienti enterprise moderni esiste ormai una pressione costante alla reperibilità immediata. Rispondere velocemente è diventato quasi un obbligo culturale. Ed è proprio questa dinamica che rende strumenti come Teams particolarmente pericolosi dal punto di vista del social engineering.

Un’email può essere ignorata.

Una notifica Teams durante l’orario lavorativo no.

Anche perché spesso compare direttamente sul desktop, interrompe altre attività e arriva mentre l’utente sta già gestendo decine di conversazioni contemporaneamente.

In pratica il cybercrime sta imparando a inserirsi perfettamente nei micro-momenti di distrazione.

Ed è probabilmente questa la parte più inquietante.

Non serve più creare una finta pagina perfetta o un malware invisibile. Basta convincere una persona stanca, stressata o distratta a cliccare nel momento giusto.

Per questo motivo le aziende stanno iniziando a rivedere anche la formazione interna. Le classiche campagne anti-phishing basate solo sulle email non bastano più. Oggi il social engineering passa attraverso chat aziendali, videochiamate, sistemi di collaborazione e perfino notifiche push.

La vera sfida della cybersecurity moderna non è soltanto proteggere le infrastrutture.

È proteggere l’attenzione umana.

E in un mondo dove lavoriamo continuamente dentro piattaforme collaborative, distinguere una richiesta autentica da una manipolazione sta diventando sempre più difficile.


The Pirate Post ha ricondiviso questo.

Der Deepfake-Skandal um Grok basierte auf Daten, die die Organisation AI Forensics gesammelt hatte. Der Direktor der NGO spricht über das Risiko, ins Visier von Musk zu geraten und darüber, welche weiteren Probleme ihnen in der Arbeit begegnen.

netzpolitik.org/2026/ai-forens…

in reply to netzpolitik.org

Also in English: Without the data-driven investigation conducted by AI Forensics the Grok deepfake scandal might never have been uncovered. In an interview with netzpolitik.org, the NGO’s director Marc Faddoul talks about the risk of being targeted by Elon Musk, and what other issues they encounter in their work for regulators such as the European Commission.

netzpolitik.org/2026/ai-forens…

The Pirate Post ha ricondiviso questo.

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

🍪🎉 noyb win: The Federal Administrative Court confirmed that the buttons to ‘accept’ or ‘reject’ tracking cookies on ORF.at must be designed equally. 🥳 Learn more: noyb.eu/en/noyb-success-orfat-… #privacy #austria #cookies
Questa voce è stata modificata (2 settimane fa)

How Paramount and DC Bar enabled Trump’s ‘weaponization’ slush fund


This week, President Donald Trump once again hijacked the court system to launder corruption. He purportedly “settled” litigation with his own Department of Justice in exchange for a $1.8 billion slush fund to compensate political allies who claim to be victims of weaponization, as well as a deal to never investigate alleged tax evasion by the Trump family.

That’s the same DOJ that outside its headquarters flies a giant banner of Trump — making his best tough guy face, with his eyes uncharacteristically open. But before the DOJ unfurled its “Dear Leader” flag, Federal Communications Commission Chair Brendan Carr pinned Trump’s gilded image to his lickspittling lapel and renounced his agency’s independence.

And before the DOJ’s latest mockery of the legal system, Carr facilitated Trump’s shakedown of CBS parent Paramount, holding up regulatory approval of Paramount’s merger with Skydance until it paid Trump $16 million to settle his absolutely frivolous lawsuit over the editing of an interview with Kamala Harris by “60 Minutes.” He approved the merger two days after Trump got the check.

That could’ve been the end of it. Last July, Freedom of the Press Foundation (FPF) filed an ethics complaint against Carr, an attorney, with the Washington, D.C. Bar, making what we thought was an uncontroversial argument: It’s unethical for officers of the court to help the president use those courts to extract palm grease from companies they regulate.

Had the D.C. Bar disbarred or even merely disciplined Carr, Trump’s lawyers would know that facilitating self-dealing schemes might cost them something. It may not have stopped the administration’s avalanche of grift, but it might have hindered DOJ lawyers from so readily signing off on such blatant lawlessness.

But it didn’t. Instead, Disciplinary Counsel Hamilton P. Fox III wrote in a letter dismissing our complaint that the ethics rules we cited had not previously been applied in similar contexts. He also included an incoherent argument that the First Amendment gave Carr some sort of wiggle room. As if to underscore his lack of First Amendment expertise, he marked his dismissal letter “confidential” (an alarmingly common practice among disciplinary offices). Here’s a pro tip: Don’t try to impose a prior restraint on an organization with “freedom of the press” in its name.

If the administration is going to go after you anyway, you might as well do your job.

But it should be obvious why there were no analogous precedents for the relief our complaint sought. No prior FCC chair helped a sitting president turn a courtroom into a conduit for bribery.

And even if the First Amendment could arguably acquiesce Carr’s anti-speech investigations of licensees (it can’t — just consult the statute under which the FCC operates or ask the version of Carr from before he put on that lapel pin), that has nothing to do with facilitating presidential shakedowns. There’s no universe where that’s protected by the Constitution.

The ethics rules’ prohibitions on “conduct involving dishonesty, fraud, deceit, or misrepresentation” and “conduct prejudicial to the administration of justice” were drafted broadly on purpose — it’s impossible to predict every way future attorneys may misbehave. There’s plenty of room in those rules to crack down on Carr if the disciplinary office wanted to.

The reality is that Fox did what attorney disciplinary commissions frequently do — find an excuse to duck out of politically charged complaints (notwithstanding the occasional case that is too egregious for even them to ignore, e.g., Ed Martin and Rudy Giuliani). Lawyers joke about the inefficacy of disciplinary offices — it’s an open secret that they operate more like protection rackets for members of the bar than serious regulators.

Now we see where that cowardice led — a $16 million corrupt settlement begot a $1.8 billion one. And the D.C. Bar’s hands-off approach certainly hasn’t earned it any goodwill from the administration. The DOJ filed suit against Fox and the D.C. Bar earlier this month, with Acting Attorney General Todd Blanche calling it a “blatantly partisan arm of leftist causes,” apparently because it disciplined the likes of Jeffrey Clark for trying to overturn the 2020 election.

There’s some good news. Lawyers from the Public Integrity Project are fighting the DOJ’s shenanigans in court, and the Legal Accountability Center has filed a new attorney disciplinary complaint against Carr. It’s an opportunity for Fox and the D.C. Bar to right past wrongs. If the administration is going to go after you anyway, you might as well do your job.

And maybe after you’re done battling Blanche’s political attacks, you can apply for some compensation from that weaponization fund you enabled.


freedom.press/issues/how-param…

reshared this

Things to Look Forward to from the United States Pirate Party


May 21st

We have two things we wanted to tell you about since plenty of action is happening on the Pirate side of things:

1.) Our 2026 Pirate National Conference: […] Hoist the Colours and Spill the Tea (20 Years a Pirate!) is quickly approaching, with June 6th-7th being less than three weeks away! You might be thinking “I wish I could be involved in the 2026 PNC.”

The good news is, Boston or not: you can!

Sign up at this link, whether you’re attending in-person or online, and get involved in our 20th anniversary celebration! It’s gonna be buckets of fun.

Plus we have a boat, like all good Pirates do.

2.) Drew Bingaman, candidate for PA House 108 and Pirate through and through, will be joining us Saturday for Talk the Plank! at NoonET. Don’t miss Captain emeritus Drew Bingaman discuss his campaign, and don’t forget to bring your questions! We will be checking the YouTube livestream.

3.) As was voted on by the Pirate National Committee, the open PNC meetings, held between the regular PNC meetings, was be moved to livestream starting this Sunday, May 24th. However, this may be postponed until June 20th. Update to come tomorrow on the status of the meeting.

That’s all for now! We’ll see you Saturday for Talk the Plank!, potentially Sunday for our open meeting, and June 6th-7th for our Pirate National Conference!


uspirates.org/things-to-look-f…

Elezioni e Politica 2026 reshared this.

The Pirate Post ha ricondiviso questo.

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

Exchange Online Writeback: sincronizzare le modifiche cloud con Active Directory on-premises
#tech
spcnet.it/exchange-online-writ…
@informatica


Exchange Online Writeback: sincronizzare le modifiche cloud con Active Directory on-premises


Il problema storico degli ambienti ibridi Exchange


Chiunque abbia gestito un ambiente ibrido Exchange-Active Directory conosce bene il dolore: le caselle email esistono su Exchange Online, ma gli attributi che le descrivono — indirizzi proxy, parametri di routing, configurazioni di delivery — devono essere sempre sincronizzati con l’Active Directory on-premises. Le applicazioni line-of-business leggono questi dati direttamente dall’AD locale, e se Exchange Online e l’AD si disallineano, iniziano i problemi: email che non arrivano, rubriche inconsistenti, applicazioni interne che non trovano gli indirizzi corretti.

Fino ad oggi, la soluzione era mantenere almeno un server Exchange on-premises solo per gestire questo ciclo di scrittura degli attributi. Un server costoso da mantenere, aggiornare e mettere in sicurezza, la cui unica ragione di esistere era permettere la modifica degli attributi Exchange nell’Active Directory locale. Microsoft lo aveva già ammesso esplicitamente: il percorso verso l’abbandono dell’ultimo Exchange server on-premises era bloccato proprio da questo nodo tecnico.

Con la public preview del Writeback per Cloud-Managed Remote Mailboxes, annunciata a maggio 2026, questo nodo comincia finalmente a sciogliersi.

Cosa cambia con il Writeback di Exchange Online


La nuova funzionalità consente a Exchange Online di sincronizzare automaticamente le modifiche agli attributi Exchange dalla cloud verso l’Active Directory on-premises, invertendo il flusso tradizionale. Finora la sincronizzazione era unidirezionale: dall’AD locale verso Exchange Online, gestita da Microsoft Entra Connect Sync (o dal predecessore Azure AD Connect). Ora, con il writeback abilitato, qualsiasi modifica apportata a un mailbox cloud-managed — un nuovo indirizzo proxy, una modifica al display name Exchange, una variazione nei parametri di routing — viene automaticamente propagata all’AD on-premises tramite Microsoft Entra Cloud Sync.

Il risultato pratico è che l’AD locale rimane sempre aggiornato, e le applicazioni on-premises che leggono direttamente gli attributi Exchange dall’AD continuano a funzionare correttamente — anche dopo aver spostato la gestione delle mailbox completamente nel cloud.

Architettura della soluzione


Il writeback utilizza Microsoft Entra Cloud Sync come layer di trasporto tra Exchange Online e l’AD on-premises. Un aspetto importante da sottolineare: Entra Cloud Sync non sostituisce Entra Connect Sync. Le due soluzioni coesistono fianco a fianco. Le organizzazioni che usano già Entra Connect Sync per la sincronizzazione identità non devono disinstallare o sostituire nulla — installano semplicemente un agent Entra Cloud Sync aggiuntivo e configurano il nuovo flusso di writeback.

Il percorso di dati completo è quindi:

  1. L’amministratore modifica un attributo Exchange Online (es. aggiunge un alias email)
  2. Exchange Online propaga la modifica a Microsoft Entra ID
  3. Entra Cloud Sync rileva la modifica e la scrive nell’Active Directory on-premises
  4. Le applicazioni LOB leggono il dato aggiornato dall’AD locale in tempo reale


Come abilitare il Writeback: configurazione passo per passo


Il prerequisito fondamentale è avere almeno un agent Microsoft Entra Cloud Sync installato e configurato per il dominio AD target. Una volta soddisfatto questo requisito, la configurazione del writeback avviene dall’interfaccia di Entra ID:

Microsoft Entra Admin Center
→ Identity → Hybrid Management → Entra Connect
→ Cloud Sync → Configurations
→ New configuration → EXO to AD attribute sync (Preview)


Nella pagina di configurazione, si verifica che l’agent selezionato corrisponda al dominio corretto, quindi si conferma con Create. Dalla scheda Overview della nuova configurazione, si clicca Start provisioning per avviare il flusso di sincronizzazione.

Una volta avviato, il sistema inizia a monitorare le modifiche agli attributi Exchange nelle mailbox cloud-managed e a propagarle verso l’AD on-premises. Non è richiesta nessuna configurazione aggiuntiva sull’Exchange Server on-premises — anzi, questo è esattamente il punto: con questa funzionalità attiva, l’Exchange server locale non è più necessario per il writeback degli attributi.

Limiti della Preview e roadmap


La funzionalità è attualmente in Public Preview con alcune limitazioni da tenere presenti:

  • Limite di mailbox: Durante la preview il writeback supporta tenant con meno di 200.000 mailbox cloud-managed. Il limite verrà rimosso o aumentato alla General Availability.
  • GA target: Microsoft ha indicato la fine di giugno 2026 come obiettivo per la General Availability.
  • Attributi supportati: Il writeback copre gli attributi Exchange designati — indirizzi proxy, parametri di routing, attributi mail-related — non l’intera struttura dell’oggetto AD.


Implicazioni strategiche per i sysadmin


Questa funzionalità rappresenta un passo concreto verso quello che Microsoft chiama “Last Exchange Server Retirement” — la possibilità di eliminare definitivamente l’ultimo server Exchange on-premises dalle infrastrutture ibride senza perdere funzionalità critiche.

Per i team IT, significa valutare concretamente un percorso di dismissione hardware e software che finora era rimasto bloccato. Un server Exchange on-premises richiede licenze, hardware dedicato (o VM), aggiornamenti cumulativi, patching della sicurezza e competenze specializzate per la manutenzione. Eliminarlo non è solo un risparmio economico: riduce la superficie d’attacco e semplifica l’architettura complessiva.

Naturalmente, prima di pianificare la dismissione, è necessario verificare alcune condizioni:

  • Tutte le mailbox gestite on-premises devono essere migrate a Exchange Online come cloud-managed remote mailboxes
  • Le applicazioni LOB che leggono attributi Exchange dall’AD devono essere testate nel nuovo scenario di writeback
  • La latenza di sincronizzazione di Entra Cloud Sync deve essere compatibile con le esigenze delle applicazioni
  • I flussi di email che usano connettori on-premises devono essere valutati separatamente


Conclusione


Il writeback di Exchange Online verso Active Directory on-premises è una delle novità più rilevanti per i sysadmin che gestiscono ambienti Microsoft ibridi. Risolve un problema tecnico che aveva bloccato molte organizzazioni nella loro transizione al cloud-only per anni, togliendo l’ultimo alibi per mantenere un server Exchange on-premises attivo.

Il fatto che sia ancora in preview suggerisce di non pianificare dismissioni immediate, ma è il momento giusto per iniziare i test in ambienti non produttivi, validare la compatibilità con le applicazioni LOB e costruire il piano di migrazione. La GA prevista per fine giugno 2026 potrebbe arrivare in coincidenza con la scadenza dei certificati Secure Boot: due scadenze importanti da non ignorare nello stesso mese.


Fonti: Microsoft Tech Community – Writeback for Cloud-Managed Remote Mailboxes, Microsoft Learn – Cloud-based management of Exchange attributes, Petri IT Knowledgebase – Exchange Online Writeback


The Pirate Post 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.

TeamPCP viola GitHub dall’interno: 3.800 repository sottratti in 18 minuti tramite un’estensione VS Code malevola
#CyberSecurity
insicurezzadigitale.com/teampc…


TeamPCP viola GitHub dall’interno: 3.800 repository sottratti in 18 minuti tramite un’estensione VS Code malevola


18 minuti. È il tempo in cui una versione trojanizzata dell’estensione VS Code Nx Console (nrwl.angular-console) è rimasta disponibile sul Visual Studio Marketplace il 18 maggio 2026. Un lasso di tempo apparentemente irrisorio, ma sufficiente perché il gruppo criminale TeamPCP compromettesse il device di almeno un dipendente GitHub e sottraesse circa 3.800 repository interni — uno degli incidenti di supply chain più gravi dell’anno sul piano dell’impatto sistemico.

Il contesto: TeamPCP e la catena TanStack


Per capire la violazione di GitHub è necessario risalire di dieci giorni. L’11 maggio 2026, TeamPCP aveva già pubblicato 84 artifact npm malevoli distribuiti su 42 pacchetti nel namespace TanStack — uno degli ecosistemi più adottati per il web development con React. Quell’operazione, che il sito ha seguito nelle settimane precedenti nella campagna Mini Shai-Hulud, aveva come obiettivo la compromissione a cascata di developer tramite dipendenze malevole che esfiltravano credenziali e token durante l’installazione.

TeamPCP ha guadagnato notorietà rapidamente come attore specializzato negli attacchi alla developer trust surface: non attacca i sistemi delle vittime direttamente, ma compromette la catena di strumenti e dipendenze su cui i developer si fidano implicitamente ogni giorno. L’attacco TanStack era già sufficientemente grave da soli — ma era anche il setup per qualcosa di più ambizioso.

Il vettore: Nx Console 18.95.0


Nx Console (nrwl.angular-console) è un’estensione VS Code con 2,2 milioni di installazioni e lo status di verified publisher — la certificazione più alta che Microsoft assegna agli editori sul marketplace. Questa combinazione di popolarità e fiducia istituzionale ne fa un bersaglio di enorme valore per un attore supply chain.

Il team di Nx ha successivamente ricostruito la catena causale: uno dei propri developer era stato precedentemente compromesso nel contesto dell’attacco a TanStack. Le sue credenziali GitHub erano trapelate, permettendo a TeamPCP di accedere al repository dell’estensione, modificare il codice, e pubblicare la versione 18.95.0 — quella avvelenata. Il meccanismo era semplice ma letale: non appena un developer apriva qualsiasi workspace in VS Code con l’estensione installata, il malware iniziava a raccogliere silenziosamente le credenziali memorizzate nel sistema.

La timeline dell’attacco


  • 11 maggio 2026 — TeamPCP pubblica 84 pacchetti npm malevoli nel namespace TanStack; un developer Nx viene compromesso
  • 18 maggio 2026, 12:30 UTC — Nx Console 18.95.0 (versione backdoor) appare sul VS Code Marketplace
  • 18 maggio 2026, 12:48 UTC — La versione malevola viene rimossa dal Marketplace (18 minuti di esposizione)
  • 18 maggio 2026, ~13:06 UTC — Rimossa da Open VSX (36 minuti totali di esposizione)
  • 20 maggio 2026 — GitHub conferma la violazione: circa 3.800 repository interni esfiltrati, avvio rotazione di tutti i secret esposti


L’impatto: 3.800 repository interni di GitHub


GitHub ha confermato la sottrazione di circa 3.800 repository interni a opera di TeamPCP. L’azienda ha proceduto immediatamente alla rotazione di tutti i secret potenzialmente esposti. Non è ancora stato reso noto se i repository contengano codice relativo alla piattaforma github.com stessa, strumenti interni, infrastrutture di supporto o documentazione riservata — ma la sola portata numerica dell’esfiltrazione suggerisce un accesso profondo all’ecosistema di sviluppo interno di Microsoft GitHub. L’incidente ha colpito anche Grafana, compromessa attraverso un percorso diverso ma sempre legato alla catena TanStack.

Perché questo attacco è strutturalmente diverso


A differenza dei classici attacchi alla supply chain che operano a livello di package manager (npm, PyPI), questo incidente colpisce il layer dell’IDE — la superficie più prossima al developer e quella con i privilegi di accesso più ampi. Un’estensione VS Code non è un pacchetto passivo: ha accesso al filesystem locale, alle variabili d’ambiente di sistema, ai token Git memorizzati, alle chiavi SSH, ai file di configurazione cloud e all’intera sessione di sviluppo attiva.

Un’estensione verified con milioni di installazioni diventa, una volta compromessa, un vettore di distribuzione quasi impossibile da bloccare con le tradizionali difese perimetrali. La maggior parte degli endpoint detection agent non monitora il comportamento delle estensioni IDE con la stessa granularità con cui monitora i processi di sistema — un gap che TeamPCP ha sfruttato con precisione chirurgica.

Indicatori di compromissione (IoC)

# TeamPCP - GitHub Breach via Nx Console - IoC (maggio 2026)
# Estensione malevola
EXTENSION: nrwl.angular-console (Nx Console) versione 18.95.0
MARKETPLACE: Visual Studio Code Marketplace
TIMEFRAME: 2026-05-18 12:30–12:48 UTC (VS Code Marketplace)
TIMEFRAME: 2026-05-18 12:30–13:06 UTC (Open VSX)
# Infrastruttura TeamPCP documentata
DOMAIN: t.m-kosche.com (infra C2 TeamPCP)
# Campagne correlate
CAMPAIGN: Mini Shai-Hulud (npm/PyPI, 160+ pacchetti)
CAMPAIGN: TanStack supply chain (84 artifact npm su 42 pacchetti, 2026-05-11)
# Possibili alias
ACTOR: TeamPCP
ACTOR_ALIAS: UNC6780 (attribuzione parziale)
# Azione raccomandata
ACTION: Verificare estensioni VS Code installate nel periodo 2026-05-11/20
ACTION: Ruotare tutti i token GitHub/credential store sui sistemi degli sviluppatori

Due righe per i difensori


L’incidente impone una revisione urgente della postura di sicurezza degli ambienti di sviluppo. I team di sicurezza dovrebbero verificare immediatamente se l’estensione Nx Console 18.95.0 è stata installata su device aziendali nel periodo 11–20 maggio 2026, e in caso affermativo avviare la rotazione di tutte le credenziali presenti sui sistemi coinvolti — token GitHub, chiavi SSH, credenziali cloud, certificati. È fondamentale estendere il monitoraggio EDR alle estensioni IDE, configurando alert per comportamenti anomali come lettura massiva di file di configurazione, accesso ai credential store di sistema o connessioni di rete originate dal processo VS Code verso endpoint inusuali. Sul piano organizzativo, è necessario implementare il principio del minimo privilegio per le credenziali usate negli ambienti di sviluppo: i developer non dovrebbero mai usare token con permessi di scrittura su repository interni critici sui propri device personali. Infine, considerare l’adozione di ambienti di sviluppo isolati — container o VM dedicati — per i progetti a più alto rischio, separando fisicamente l’ambiente di esecuzione del codice dall’ambiente di lavoro quotidiano.


Upcoming Pirate Events


Join us at one or more Pirate Events scheduled for May and June:


masspirates.org/blog/2026/05/2…

Elezioni e Politica 2026 reshared this.

The Pirate Post ha ricondiviso questo.

Présenter sa carte d'identité ou utiliser FranceConnect sera-t-il bientôt obligatoire pour accéder aux réseaux sociaux ? C'est ce que prépare une proposition de loi imposant une vérification d'âge pour empêcher les moins de 15 ans d'utiliser ces plateformes. Poussé par la France et la Commission européenne, un tel mécanisme porterait un coup très grave à l'anonymat, la vie privée et la liberté d'expression en ligne.

laquadrature.net/2026/05/21/de…

The Pirate Post ha ricondiviso questo.

La Quadrature du Net recrute !

Nous cherchons sur Paris une personne ayant une appétence pour la compréhension et la vulgarisation des systèmes techniques et de leurs impacts politiques, qui pourrait nous aider à construire et diffuser notre analyse politique et à mobiliser sur nos sujets. ⬇️

laquadrature.net/la-quadrature…

#JeRecrute

in reply to La Quadrature du Net

Votre mission sera de participer à la construction et à la diffusion de l'analyse politique de La Quadrature. Dans un premier temps, vous travaillerez sur le thème de l'IA et des algorithmes de contrôles utilisés par les administrations sociales (notre campagne « France Contrôle »), mais vous aurez vocation à évoluer ensuite sur d'autres thématiques.
in reply to La Quadrature du Net

Concrètement, nous cherchons quelqu'un qui a de l'expérience en matière de vulgarisation des sujets techniques ou bien en matière d'animation de réseaux. Si vous savez notamment faire de la veille politique et médiatique, travailler en équipe, parler anglais, et êtes bien entendu intéressé·e par nos sujets, alors venez postuler !
in reply to La Quadrature du Net

Le poste est à Paris, mais le télétravail ponctuel est possible. Les candidatures sont ouvertes jusqu'au 21 juin, et nous commencerons les entretiens dès début juin. Alors si vous voulez nous rejoindre pour réfléchir, agir et construire une alternative critique à l'utilisation dominante et répressive des technologies, envoyez nous votre candidature ! 👍

laquadrature.net/la-quadrature…

“Fight for Us, Not for Them”: A Public Interest Vision for EU Tech Policy — new speakers announced


As EU digital policy faces growing pressure from deregulation and “simplification” agendas, civil society experts, lawmakers, regulators, and journalists are coming together in Brussels and online to make the case for a bold public-interest vision of technology policy: one that protects people, communities, democracy, and our fundamental rights.

The post “Fight for Us, Not for Them”: A Public Interest Vision for EU Tech Policy — new speakers announced appeared first on European Digital Rights (EDRi).

Elezioni e Politica 2026 reshared this.

The Pirate Post ha ricondiviso questo.

Vor guten einem Jahr bohrte sich eine Tränengaspatrone in den Schädel des Fotografen Pablo Grillo. Der Polizist, der die Waffe abgefeuert hat, steht heute vor Gericht. Möglich war das nur, weil sich Freiwillige tagelang durch Videos gewühlt haben.

netzpolitik.org/2026/nach-schu…