Cambridge Votes to End ShotSpotter!


On Monday, May 18th, the Cambridge City Council voted 5 to 2 in support of a policy order directing the City Manager to end its ShotSpotter contract and remove the microphones from Cambridge neighborhoods. We want to thank our supporters and everyone else who spoke in favor of this policy order. Cambridge will be a safer city once ShotSpotter is removed.

This victory was because of years of organizing, testimony, research, and community pressure. The campaign to end ShotSpotter surveillance devices in Cambridge was led by the Stop ShotSpotter Camberville Coalition made up of The Black Response, SURJ Boston, Defund Somerville PD, BDS Boston and the Massachusetts Pirate Party. The campaign received vital support from:

and research support from the Community Resource Hub, Law for Black Lives, Tufts University Tisch College Community Research Center, and Boston University Spark!

We encourage community members to thank Councillors Ayah Al-Zubi, Jivan Sobrinho-Wheeler, Marc McGovern, Patty Nolan, and Mayor Sumbul Siddiqui for voting to get rid of ShotSpotter. Councillors Tim Flaherty and E. Denise Simmons opposed it; Councillor Cathie Zusy and Vice Mayor Burhan Azeem abstained.

This effort is not over. We still need to pressure the City Manager to terminate the contract and ensure that the microphones are removed. If you see any ShotSpotters, see the image above for what they look like, be sure to email us where it is so we can map them and verify that they are removed.


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

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.

CISA Flags Actively Exploited Langflow Flaw CVE-2025-34291 — AI Workflow Deployments at Risk
#CyberSecurity
securebulletin.com/cisa-flags-…
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.

2026 FIFA World Cup Phishing Fraud Triples in Scope: 222 Fake Domains, Four Criminal Clusters
#CyberSecurity
securebulletin.com/2026-fifa-w…
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.

Fine dell’autenticazione CBA diretta per Exchange ActiveSync: guida alla migrazione verso Microsoft Entra ID
#tech
spcnet.it/fine-dellautenticazi…
@informatica


Fine dell’autenticazione CBA diretta per Exchange ActiveSync: guida alla migrazione verso Microsoft Entra ID


L’8 maggio 2026, il team di Exchange Online di Microsoft ha annunciato la deprecazione dell’autenticazione basata su certificati (CBA) diretta per Exchange ActiveSync (EAS). Entro la fine del 2026, qualsiasi client EAS che utilizza certificati per autenticarsi direttamente contro Exchange Online dovrà migrare al nuovo metodo basato su Microsoft Entra ID, pena l’interruzione del servizio email mobile.

Se la tua organizzazione ha configurato l’accesso alle email mobili tramite certificati client, questo articolo ti guida attraverso tutto ciò che devi sapere: perché Microsoft sta effettuando questo cambiamento, chi è interessato e — soprattutto — come completare la migrazione prima della scadenza.

Cos’è l’autenticazione CBA diretta per Exchange ActiveSync?


Exchange ActiveSync (EAS) è il protocollo che permette ai dispositivi mobili (smartphone, tablet) di sincronizzare email, calendari e contatti con Exchange Online. L’autenticazione basata su certificati (Certificate-Based Authentication, CBA) rappresenta un approccio passwordless: invece di inserire credenziali, il dispositivo presenta un certificato X.509 per autenticarsi.

Nel flusso legacy attuale, il funzionamento è il seguente:

  1. I certificati client vengono distribuiti ai dispositivi mobili durante la configurazione MDM
  2. Quando l’app email si connette, invia il certificato direttamente a Exchange Online
  3. Exchange Online riceve il certificato e ne gestisce internamente la validazione
  4. L’accesso viene concesso senza che il client ottenga mai un token OAuth standard

Questo approccio, sebbene sicuro a livello crittografico, è classificato da Azure AD come autenticazione legacy: il client non ottiene mai un token OAuth moderno, ma si affida a un meccanismo interno ad alta privilegio all’interno di Exchange Online.

Perché Microsoft sta eliminando questo metodo?


Il problema centrale è che la CBA diretta verso Exchange bypassa il moderno ecosistema di autenticazione di Microsoft Entra ID. Le conseguenze pratiche per gli amministratori sono significative:

  • Incompatibilità con le Conditional Access Policy: le policy che bloccano l’autenticazione legacy in Azure AD bloccano anche la CBA diretta su EAS, creando un dilemma “tutto o niente” per chi vuole applicare controlli di sicurezza moderni senza interrompere l’accesso email mobile
  • Mancanza di token OAuth: senza un token OAuth standard, non è possibile applicare controlli granulari come la durata della sessione, la revoca in tempo reale o l’integrazione con Identity Protection
  • Superficie di attacco interna: Exchange Online si affida a un meccanismo interno ad alta privilegio per validare i certificati, introducendo una complessità architetturale non necessaria

Il nuovo flusso con Entra ID risolve tutti questi problemi:

  1. Il client invia il certificato a Microsoft Entra ID per la validazione
  2. Entra ID valida il certificato e restituisce un token OAuth al client
  3. Il client presenta il token OAuth a Exchange Online per l’autenticazione

In questo modo, la CBA diventa un metodo di autenticazione moderno a tutti gli effetti, integrato nel flusso OAuth standard e soggetto a tutte le Conditional Access Policy configurate nel tenant.

Chi è interessato da questa modifica?


È importante chiarire cosa non è interessato da questa deprecazione:

  • Outlook Mobile (usa già Modern Authentication)
  • Exchange Server on-premises
  • Altri client Exchange Online che non usano EAS con CBA
  • Organizzazioni che non hanno mai configurato EAS CBA

La modifica riguarda esclusivamente i client Exchange ActiveSync (tipicamente le app email native di iOS e Android) configurati per usare certificati client come metodo di autenticazione verso Exchange Online.

Come verificare se la tua organizzazione è interessata:

  1. Controlla la configurazione MDM: se il tipo di autenticazione nei profili email è impostato su “Certificate” anziché “OAuth”, probabilmente stai usando la CBA legacy
  2. Verifica i log di sign-in di Entra ID: accedi all’Azure Portal → Microsoft Entra ID → Sign-in logs → filtra per “Client App: Exchange ActiveSync”. Se in “Authentication Details” vedi “Certificate” come metodo di autenticazione, sei impattato


Guida alla migrazione verso Entra-Based CBA


La buona notizia è che l’infrastruttura PKI e le CA (Certificate Authority) utilizzate per EAS CBA sono fondamentalmente le stesse richieste per Entra CBA. Questo semplifica notevolmente la transizione.

Step 1: Abilitare Microsoft Entra CBA nel tenant


Accedi al portale Azure e naviga in Microsoft Entra ID → Protection → Authentication methods → Certificate-based authentication. Configura le tue Certificate Authority:

  • Almeno una CA root deve essere configurata in Entra ID, insieme a tutte le CA intermedie
  • Ogni CA deve avere una Certificate Revocation List (CRL) accessibile da un URL pubblico su Internet
  • Gli utenti devono avere accesso a un certificato emesso da una PKI attendibile

Per verificare la configurazione via PowerShell (Microsoft Graph PowerShell):

# Recupera le CA di autenticazione configurate nel directory
Get-MgOrganizationCertificateBasedAuthConfiguration -OrganizationId (Get-MgOrganization).Id

# Oppure con il modulo AzureAD (legacy)
Get-AzureADTrustedCertificateAuthority

Step 2: Verificare i certificati utente


Per Exchange ActiveSync, i certificati client devono contenere l’indirizzo email routable dell’utente nel campo Subject Alternative Name (SAN), in uno dei seguenti formati:

  • Principal Name: user@domain.com
  • RFC822 Name: user@domain.com (Entra ID lo mappa all’attributo Proxy Address)

I certificati già usati per la CBA diretta su EAS soddisfano quasi certamente questo requisito. Verifica semplicemente la presenza dell’email aziendale nel campo SAN del certificato.

Step 3: Aggiornare la configurazione dei dispositivi


Questa è la parte più operativa della migrazione. I profili email sui dispositivi mobili devono essere aggiornati per eseguire l’autenticazione certificato contro Entra ID invece che direttamente verso Exchange. In pratica:

  • Se usi Microsoft Intune: aggiorna i profili di configurazione email per usare OAuth + certificati come metodo di autenticazione. Consulta la documentazione Intune per le specifiche della configurazione per iOS e Android
  • Se usi soluzioni MDM di terze parti (VMware Workspace ONE, JAMF, MobileIron, ecc.): consulta il vendor per le istruzioni specifiche sull’abilitazione dell’autenticazione Entra con certificati

I nuovi endpoint dedicati per la CBA su EAS sono:

  • Multi-tenant worldwide: outlook-cba.office365.com
  • GCC-High: outlook-cba.office365.us
  • DoD: outlook-dod-cba.office365.us


Step 4: Test e monitoraggio


Prima del rollout globale, testa il nuovo flusso Entra CBA con un gruppo pilota di dispositivi e utenti. Monitora i log di sign-in di Entra ID e i report sui dispositivi Exchange ActiveSync per identificare eventuali dispositivi che ancora usano il metodo legacy.

Timeline e pianificazione


I punti chiave da tenere a mente:

  • Immediato: blocco per i nuovi tenant — non possono più configurare la CBA legacy
  • Prossime settimane: Microsoft invierà comunicazioni Message Center ai tenant impattati
  • Fine 2026: la CBA diretta verso Exchange Online verrà disabilitata per tutti i tenant esistenti

Microsoft raccomanda di completare la migrazione ben prima della scadenza di fine 2026 per evitare interruzioni del servizio. Considerando i tempi tipici di test, approvazione e deployment nei dispositivi mobili aziendali, è consigliabile iniziare la pianificazione adesso.

Conclusione


La deprecazione della CBA diretta per Exchange ActiveSync è parte del percorso di Microsoft verso la modernizzazione completa dell’autenticazione su Exchange Online, sulla scia dell’eliminazione di Basic Auth avvenuta negli anni scorsi. Il nuovo flusso basato su Entra ID offre sicurezza equivalente — passwordless, resistente al phishing, basato su certificati — con una ben migliore integrazione nell’ecosistema moderno di autenticazione e la piena compatibilità con le Conditional Access Policy.

Se la tua organizzazione usa EAS con CBA, il momento di iniziare la pianificazione della migrazione è adesso: la runway fino a fine 2026 è sufficiente per una transizione ordinata, ma non illimitata.


Fonte: Microsoft Tech Community — Exchange Team Blog (8 maggio 2026) | 4sysops.com


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.

art-template npm Package Backdoored to Deliver iOS Browser Exploit Kit via Supply Chain Attack
#CyberSecurity
securebulletin.com/art-templat…
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.

Liquibase: gestione delle modifiche al database e automazione CI/CD
#tech
spcnet.it/liquibase-gestione-d…
@informatica


Liquibase: gestione delle modifiche al database e automazione CI/CD


La gestione delle modifiche allo schema di un database è uno degli aspetti più delicati e sottovalutati nei progetti software moderni. Script SQL sparsi, modifiche manuali non documentate, disallineamenti tra ambienti di sviluppo, staging e produzione: questi problemi sono comuni in quasi ogni team di sviluppo. Liquibase risolve questi problemi portando il controllo di versione al database, proprio come Git fa con il codice sorgente.

Cos’è Liquibase e perché usarlo


Liquibase è uno strumento open source per il database schema change management. Permette di definire, versionare e distribuire le modifiche allo schema del database tramite file di configurazione (chiamati changelog), supportando oltre 30 database diversi: Oracle, MySQL, PostgreSQL, SQL Server, DB2 e molti altri.

Il problema che Liquibase risolve è semplice ma critico: applicare modifiche al database con script SQL tradizionali è un processo manuale, error-prone e difficile da tracciare. Questi script spesso mancano di versioning, rendendo quasi impossibile sapere quale versione dello schema è in produzione rispetto allo sviluppo. Liquibase standardizza questo processo tramite file di configurazione versionati, tracciamento automatico via checksum MD5 e supporto nativo al rollback.

Concetti fondamentali


Prima di entrare nell’implementazione, è essenziale comprendere i quattro pilastri architetturali di Liquibase:

Changelog: è il file principale che contiene tutte le modifiche al database, organizzate in sequenza. Può essere in formato XML, YAML, JSON o SQL puro. Tipicamente si usa un file master che include sotto-changelog organizzati per release o sprint.

ChangeSet: è l’unità atomica di modifica, identificata univocamente da una coppia id + author. Ogni changeset viene eseguito una sola volta e tracciato nella tabella DATABASECHANGELOG. Una regola fondamentale: non modificare mai un changeset già eseguito; crea sempre un nuovo changeset per le correzioni.

Preconditions: verifiche condizionali che devono passare prima dell’esecuzione di un changeset. Permettono di rendere sicure le migrazioni anche in scenari complessi (es. verificare che una colonna non esista già prima di aggiungerla).

Contexts e Labels: meccanismi di filtraggio per controllare quali changeset vengono eseguiti in quale ambiente (dev, staging, prod). Indispensabili per gestire dati di test o configurazioni ambiente-specifiche.

Struttura base di un changelog YAML


Ecco un esempio pratico di changelog in formato YAML per la creazione di una tabella transazioni con supporto al rollback:

databaseChangeLog:
  - changeSet:
      id: create-payment-table
      author: devops.team
      changes:
        - createTable:
            tableName: payment_transaction
            columns:
              - column:
                  name: id
                  type: varchar(50)
                  constraints:
                    primaryKey: true
                    nullable: false
              - column:
                  name: amount
                  type: decimal(15,2)
                  constraints:
                    nullable: false
              - column:
                  name: currency_code
                  type: char(3)
                  constraints:
                    nullable: false
              - column:
                  name: transaction_date
                  type: timestamp
                  defaultValueComputed: CURRENT_TIMESTAMP
              - column:
                  name: status
                  type: varchar(20)
                  constraints:
                    nullable: false
      rollback:
        - dropTable:
            tableName: payment_transaction

Il blocco rollback è fondamentale: definisce esplicitamente come annullare la modifica, rendendo ogni deployment reversibile in modo prevedibile.

Configurazione per ambienti multipli


Un file liquibase.properties separato per ogni ambiente permette di gestire connessioni e contesti in modo sicuro:

# liquibase-dev.properties
changeLogFile=db/changelog.yaml
url=jdbc:postgresql://localhost:5432/devdb
username=dev_user
password=${DB_PASSWORD}
contexts=dev,test
defaultSchemaName=DEV_SCHEMA
logLevel=DEBUG

Nota importante: le credenziali non devono mai essere committate nel repository. Usa variabili d’ambiente, HashiCorp Vault, AWS Secrets Manager o Kubernetes Secrets per la gestione dei segreti.

Precondizioni per deployment sicuri


Le precondizioni rendono Liquibase robusto in ambienti dove lo schema potrebbe trovarsi in stati intermedi. Questo esempio in SQL nativo verifica che una colonna non esista prima di aggiungerla:

--liquibase formatted sql

--changeset devops.team:add-merchant-id
--preconditions onFail:MARK_RAN onError:HALT
--precondition-sql-check expectedResult:0 SELECT COUNT(*) FROM information_schema.columns WHERE table_name = 'payment_transaction' AND column_name = 'merchant_id'

ALTER TABLE payment_transaction 
ADD COLUMN merchant_id VARCHAR(50);

--rollback ALTER TABLE payment_transaction DROP COLUMN merchant_id;

Il comportamento onFail:MARK_RAN istruisce Liquibase a segnare il changeset come già eseguito (senza eseguirlo) se la precondizione fallisce — comportamento ideale quando la colonna esiste già per altri motivi.

Integrazione in pipeline CI/CD


La vera potenza di Liquibase emerge quando viene integrato in una pipeline di deployment automatizzato. Ecco un esempio completo con Jenkins:

pipeline {
    agent any
    
    stages {
        stage('Validate') {
            steps {
                sh 'liquibase validate'
            }
        }
        
        stage('Deploy Staging') {
            steps {
                sh 'liquibase --contexts=staging update'
            }
        }
        
        stage('Deploy Production') {
            when { 
                branch 'main' 
            }
            steps {
                input 'Deploy to Production?'
                sh 'liquibase --contexts=prod update'
            }
        }
    }
    
    post {
        failure {
            sh 'liquibase rollbackCount 1'
        }
    }
}

Il blocco post { failure } garantisce il rollback automatico dell’ultimo changeset in caso di errore — un salvagente fondamentale in produzione.

Pattern Kubernetes: Init Container


Per architetture cloud-native, il pattern degli init container è ideale: Liquibase viene eseguito come container di inizializzazione prima dell’avvio dell’applicazione, garantendo che lo schema sia sempre aggiornato prima che il servizio inizi a ricevere traffico:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: payment-service
spec:
  template:
    spec:
      initContainers:
      - name: liquibase-migration
        image: liquibase/liquibase:4.25.0
        command:
        - liquibase
        - --url=jdbc:postgresql://$(DB_HOST):5432/$(DB_NAME)
        - --username=$(DB_USER)
        - --password=$(DB_PASSWORD)
        - update
        env:
        - name: DB_HOST
          valueFrom:
            secretKeyRef:
              name: db-credentials
              key: host
      containers:
      - name: payment-service
        image: payment-service:latest
        ports:
        - containerPort: 8080

Best practice per ambienti enterprise


Alcune regole fondamentali per adottare Liquibase in contesti di produzione:

  • Principio del minimo privilegio: l’utente Liquibase deve avere solo i permessi DDL necessari, mai privilegi DBA completi.
  • Revisione obbligatoria: ogni modifica al changelog deve passare per una Pull Request con review da un secondo sviluppatore prima del merge.
  • Test su dati realistici: prima del deployment in produzione, eseguire le migrazioni in un ambiente staging con volumi di dati simili a quelli di produzione per individuare problemi di performance.
  • Mai modificare changeset già eseguiti: il checksum MD5 rileverei la modifica e bloccherebbe il deployment. Crea sempre un nuovo changeset per le correzioni.
  • Crea indici dopo i bulk insert: creare indici prima di caricare grandi quantità di dati aumenta enormemente il tempo di migrazione senza benefici pratici.


Monitoraggio con Prometheus e Grafana


Per ambienti enterprise, integrare le metriche Liquibase in un sistema di osservabilità permette di rilevare problemi prima che impattino la produzione. Le metriche chiave da tracciare includono:

  • Durata per changeset: identifica migrazioni lente che potrebbero causare downtime
  • Lock contention: conflitti sulla tabella DATABASECHANGELOGLOCK in ambienti multi-istanza
  • Checksum failures: modifica non autorizzata a changeset già eseguiti
  • Rollback rate: indicatore di qualità del processo di testing prima del deployment


# Esempio metriche Prometheus esportate da Liquibase
liquibase_deployment_success_total{environment="prod"} 145
liquibase_changeset_duration_seconds_bucket{id="1",database="prod",le="0.5"} 120
liquibase_rollback_total{environment="prod"} 3
liquibase_deployment_failure_total{environment="prod",reason="validation_error"} 2

Conclusione


Liquibase trasforma la gestione del database da processo manuale e rischioso a pratica ingegneristica controllata e auditabile. L’integrazione con i sistemi CI/CD permette di applicare agli schemi database gli stessi standard di qualità già applicati al codice applicativo: versionamento, review, test automatizzati e rollback prevedibile.

Per team che adottano DevOps o pratiche di continuous delivery, Liquibase non è un’opzione ma una necessità: è il tassello mancante tra il deployment del codice e quello del database.

Fonte: Liquibase: Database Change Management and Automated Deployments — DZone


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.

AI Discovers 10,000+ Zero-Days: Anthropic’s Claude Mythos Preview Transforms Cybersecurity Defense
#CyberSecurity
securebulletin.com/ai-discover…
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.

Megalodon: 5.561 repository GitHub compromessi in sei ore con workflow CI/CD malevoli
#CyberSecurity
insicurezzadigitale.com/megalo…


Megalodon: 5.561 repository GitHub compromessi in sei ore con workflow CI/CD malevoli


In sei ore, tra le 11:36 e le 17:48 UTC del 18 maggio 2026, una campagna automatizzata denominata Megalodon ha iniettato 5.718 commit malevoli in 5.561 repository GitHub, esfiltrandone segreti CI/CD, credenziali cloud, chiavi SSH e token API verso un server di comando e controllo. È l’attacco alla supply chain dello sviluppo software più rapido e capillare mai documentato, e fa parte di un’ondata più ampia che sta ridisegnando il panorama delle minacce per sviluppatori e team DevOps.

Come funziona Megalodon: l’automazione al servizio del compromesso di massa


I ricercatori di SafeDep e StepSecurity hanno analizzato la campagna in dettaglio. L’attaccante ha utilizzato account GitHub usa-e-getta con username alfanumerici casuali di 8 caratteri (es. rkb8el9r, bhlru9nr, lo6wt4t6), configurando git per falsificare l’identità dell’autore con nomi plausibili — build-bot, auto-ci, ci-bot, pipeline-bot — e indirizzi email automatizzati come build-system@noreply.dev. Questi nomi mimano la normale attività di automazione CI/CD, riducendo drasticamente la probabilità che un commit sospetto venga rilevato durante una code review.

Il payload iniettato è un workflow GitHub Actions contenente uno script bash codificato in Base64. Una volta che il proprietario del repository accetta il pull request o effettua un push, il workflow si attiva nella pipeline CI/CD e procede all’esfiltrazione massiva di dati verso il C2 all’indirizzo 216.126.225[.]129:8443.

Dati esfiltrati: una lista completa


La lista di informazioni sottratte dalla campagna Megalodon è particolarmente estesa e rivela quanto profondamente il workflow malevolo si radichi nell’ambiente di esecuzione CI/CD:

  • Variabili d’ambiente CI, /proc/*/environ e ambiente del processo PID 1
  • Credenziali AWS (access key, secret key, session token)
  • Access token Google Cloud Platform
  • Credenziali di ruolo IAM ottenute via AWS IMDSv2, GCP metadata server e Azure IMDS
  • Chiavi private SSH
  • Configurazioni Docker e Kubernetes
  • Vault token (HashiCorp Vault)
  • Terraform credentials
  • Shell history
  • Chiavi API, stringhe di connessione a database, JWT, chiavi PEM private
  • GITHUB_TOKEN, token GitLab CI/CD e Bitbucket
  • File .env, credentials.json, service-account.json e altri file di configurazione sensibili
  • GitHub Actions OIDC token (URL + token)


# Indicatori di Compromissione - Megalodon
# C2 server
216.126.225.129:8443
# Account attaccante (pattern)
Username: 8 caratteri alfanumerici casuali (es. rkb8el9r, bhlru9nr, lo6wt4t6)
Author forged: build-bot, auto-ci, ci-bot, pipeline-bot
Email forged: build-system@noreply.dev, ci-bot@automated.dev
# Varianti payload
SysDiag          - Workflow su ogni push/pull_request (mass variant)
Optimize-Build   - Workflow su workflow_dispatch (targeted variant, backdoor dormante)
# Pacchetto npm compromesso
@tiledesk/tiledesk-server versioni 2.18.6 - 2.18.12
# Finestra temporale dell'attacco
18 maggio 2026, 11:36 - 17:48 UTC
5.718 commit su 5.561 repository in ~6 ore
# Pacchetti npm malevoli (Polymarket drainer - campagna correlata)
polymarket-trading-cli, polymarket-terminal, polymarket-trade
polymarket-auto-trade, polymarket-copy-trading, polymarket-bot
polymarket-claude-code, polymarket-ai-agent, polymarket-trader
Endpoint esfiltrazione: hxxps://polymarketbot.polymarketdev.workers[.]dev/v1/wallets/keys

Due varianti per due obiettivi


L’analisi tecnica ha identificato due varianti del payload con finalità diverse. La variante SysDiag è quella di massa: aggiunge un workflow attivato da ogni push e pull request, massimizzando le opportunità di esecuzione. La variante Optimize-Build è più chirurgica: sostituisce i workflow esistenti con trigger workflow_dispatch, creando backdoor dormienti che l’attaccante può attivare on-demand tramite le API di GitHub. Nel caso di @tiledesk/tiledesk-server è stata utilizzata la variante targeted, che colpisce i CI/CD runner ma non si attiva quando il pacchetto npm viene semplicemente installato dagli utenti finali.

“Il compromesso di GitHub da parte di TeamPCP era solo l’inizio”, ha dichiarato Moshe Siman Tov Bustan di OX Security. “Quello che arriverà è un’ondata infinita, uno tsunami di attacchi cyber contro sviluppatori in tutto il mondo.”

Il contesto: TeamPCP e l’ecosistema open source sotto attacco


Megalodon si inserisce in una serie di attacchi orchestrati dal gruppo TeamPCP, che ha sfruttato la natura interconnessa della supply chain software per compromettere centinaia di progetti open source in modalità worm-like. Tra le vittime precedenti: TanStack, Grafana Labs, OpenAI, Mistral AI e ora GitHub direttamente. Il gruppo ha stabilito partnership con BreachForums e crew di estorsione come LAPSUS$ e VECT, combinando motivazioni finanziarie con possibili interessi geopolitici: è stato documentato il deployment di wiper malware su macchine localizzate in Iran e Israele.

La risposta di npm all’ondata di attacchi è stata drastica: invalidazione di tutti i token di accesso granulare con write access che bypassano l’autenticazione a due fattori. NPM ha anche raccomandato il passaggio a Trusted Publishing per ridurre la dipendenza da questi token. Come ha sottolineato Socket, però, l’intervento compra tempo ma non chiude la vulnerabilità sottostante: finché il worm è attivo, continuerà a raccogliere nuovi token non appena i maintainer ne genereranno di nuovi.

Due righe per i difensori


La campagna Megalodon evidenzia debolezze strutturali nella sicurezza delle pipeline CI/CD. I team DevSecOps dovrebbero adottare le seguenti contromisure:

  • Abilitare il pinning dei workflow: configurare i GitHub Actions workflow per usare SHA commit espliciti invece di tag mutabili (es. uses: actions/checkout@abc1234 invece di @v3), rendendo impossibile la sostituzione silenziosa dei workflow
  • Implementare policy di branch protection: richiedere review obbligatorie per ogni push su branch principali, con particolare attenzione alle modifiche a file .github/workflows/
  • Monitorare le credenziali con secret scanning: strumenti come GitHub Secret Scanning, Trufflehog o Gitleaks possono rilevare credenziali accidentalmente incluse nei commit
  • Adottare Trusted Publishing: su npm e PyPI, il Trusted Publishing elimina la necessità di token statici che possono essere rubati
  • Revisione dei permessi GITHUB_TOKEN: limitare i permessi del token al minimo necessario per il workflow specifico, usando permissions: nel file YAML
  • Audit degli accessi OIDC: implementare policy rigorose per i token OIDC usati per l’accesso a cloud provider da pipeline CI
  • Alerting su deployment key e PAT: monitorare l’uso di Personal Access Token e deploy key, revocando immediatamente quelli non più in uso

Megalodon rappresenta un punto di svolta nella storia degli attacchi alla supply chain: la capacità di compromettere oltre 5.500 repository in meno di sei ore, utilizzando tecniche di evasione che mimano il normale traffico CI/CD, suggerisce un livello di automazione e pianificazione che andrà oltre i singoli episodi. La domanda non è più se una pipeline subirà un tentativo di compromissione, ma quando — e se l’organizzazione ha le visibility necessarie per accorgersene in tempo.


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.

Dieci anni del GDPR: i tuoi dati, i tuoi diritti

Il 24 maggio 2026 ricorre il decimo anniversario dell'entrata in vigore del Regolamento generale sulla protezione dei dati (GDPR). Questa legge storica ha conferito per la prima volta ai cittadini europei un reale controllo sui propri dati personali, cambiando per sempre la vita online.

commission.europa.eu/news-and-…

@privacypride@feddit.it

The Pirate Post ha ricondiviso questo.

Did you ever hear about Pablo Grillo? In #Argentina he became a symbol for police violence and freedom of press. Digital forensic of the collective "Mapa de la Policia" helped to bring his case to court. I wrote for @netzpolitik_feed about it (in german) - people from the "Mapa" will be in Berlin in June:

netzpolitik.org/2026/nach-schu…

The Pirate Post ha ricondiviso questo.

Tote Links, gelöschte Webpages und geänderte URLs machen das Internet zu einem Ort der Sackgassen. Wie Informationen im Netz verschwinden, erinnert an einen der berühmtesten Bibliotheksbrände der Geschichte. Doch allzu oft sind es nicht Katastrophen, die Wissen vernichten, sondern Desinteresse - schreibt @CarlaSiepmann in ihrer Kolumne:

netzpolitik.org/2026/breakpoin…

in reply to netzpolitik.org

Dafür gibt es ein archive.org und ähnliche Seiten. Grösseres Problem ist das cookie popup. Auf facebook & co, wo man schon angemeldet ist, gibt es keinen cookie popup.

Es ist auch voll dysfunktional, die Seiten könnten einfach ihre Serverlogs verkaufen, ohne cookie. Es gibt auch die "edid" hack, was als cookie Funktioniert, aber nicht cookie selbst.

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.

Webworm evolve: i backdoor EchoCreep e GraphWorm trasformano Discord e Microsoft Graph in canali C2
#CyberSecurity
insicurezzadigitale.com/webwor…


Webworm evolve: i backdoor EchoCreep e GraphWorm trasformano Discord e Microsoft Graph in canali C2


Quando un gruppo APT decide di nascondere le proprie comunicazioni malevole dentro le API di prodotti Microsoft o nei canali Discord, il confine tra traffico legittimo e operazione di spionaggio si fa quasi invisibile per i tradizionali strumenti di sicurezza di rete. È esattamente la scelta operativa che ha compiuto Webworm, gruppo di allineamento cinese attivo da almeno il 2022, che nel 2025 ha arricchito il proprio toolkit con due nuovi implant: EchoCreep e GraphWorm.

Chi è Webworm: storia e attribuzioni


Webworm è stato documentato pubblicamente per la prima volta da Symantec (ora parte di Broadcom) nel settembre 2022. Il gruppo prende di mira agenzie governative e aziende nei settori IT, aerospaziale ed energia elettrica, con un focus geografico che comprende Russia, Georgia, Mongolia e diverse nazioni asiatiche ed europee. I ricercatori hanno identificato sovrapposizioni operative significative con cluster tracciati come FishMonger (alias Aquatic Panda), SixLittleMonkeys e Space Pirates — tutti threat actor con legami all’intelligence cinese.

La scelta dei bersagli — istituzioni governative, operatori di infrastrutture critiche e fornitori di servizi IT — è coerente con gli obiettivi strategici di raccolta intelligence attribuiti agli attori state-sponsored cinesi. Le recenti campagne hanno ampliato il raggio d’azione verso l’Europa, segnalando un’evoluzione geopolitica degli interessi del gruppo.

EchoCreep: Discord come infrastruttura C2


EchoCreep è il componente più semplice — ma non per questo meno insidioso — del nuovo arsenale. Utilizza Discord come canale di Command and Control, sfruttando le API della piattaforma di messaggistica per ricevere comandi dagli operatori e restituire output dalle macchine compromesse. Le funzionalità documentate dai ricercatori includono:

  • Upload e download di file arbitrari verso/dal sistema vittima
  • Esecuzione di comandi tramite cmd.exe con restituzione dell’output agli operatori
  • Persistenza tramite canale Discord dedicato, non esposto pubblicamente

L’analisi del canale Discord utilizzato da EchoCreep rivela che i primi comandi risalgono al 21 marzo 2024: ciò significa che l’implant era già operativo in campagne reali ben prima della sua scoperta pubblica, probabilmente inosservato per oltre un anno.

La scelta di Discord come C2 non è casuale. Il traffico verso discord.com è quasi universalmente consentito nelle policy di rete aziendali, il protocollo è HTTPS e il volume di traffico legittimo è enorme — condizioni ideali per mascherare comunicazioni malevole nel rumore di fondo.

GraphWorm: Microsoft OneDrive come dead drop


GraphWorm è il componente più sofisticato del nuovo toolkit. Utilizza Microsoft Graph API — la stessa infrastruttura usata da milioni di applicazioni enterprise — per le comunicazioni C2, sfruttando specificamente gli endpoint di OneDrive. La tecnica del “cloud dead drop” — usare servizi cloud legittimi come proxy per i comandi — è in crescita tra gli APT più avanzati, ma GraphWorm la porta a un livello di granularità operativa notevole.

Per ciascuna vittima compromessa, GraphWorm crea una directory dedicata su OneDrive, permettendo agli operatori di gestire in modo indipendente le operazioni su target diversi senza interferenze. Le capacità documentate includono:

  • Spawn di nuove sessioni cmd.exe per l’esecuzione interattiva di comandi
  • Avvio di processi arbitrari sul sistema vittima
  • Upload e download di file da/verso OneDrive tramite Graph API
  • Self-termination controllata su segnale degli operatori, per ridurre le tracce forensi

Il traffico verso graph.microsoft.com è considerato trust implicito nella maggior parte degli ambienti enterprise Microsoft 365, rendendo il rilevamento basato sul blocco dei domini o sull’ispezione superficiale del traffico del tutto inefficace.

Tooling, proxy custom e TTP completi


Webworm integra i propri backdoor con un ecosistema di strumenti offensive collaudato. Per la fase di ricognizione, il gruppo usa tool open source come dirsearch e nuclei per eseguire brute-force dei path su web server delle vittime e identificare vulnerabilità sfruttabili. Sul lato infrastrutturale, Webworm ha sviluppato una suite di proxy custom: WormFrp, ChainWorm, SmuxProxy e WormSocket. Questi strumenti non si limitano a cifrare le comunicazioni: supportano il chaining su host multipli — sia interni che esterni alla rete bersaglio — permettendo la costruzione di tunnel multi-hop difficili da tracciare. Il gruppo utilizza inoltre SoftEther VPN per un ulteriore layer di offuscamento dell’infrastruttura C2.

Indicatori di compromissione (IoC)

# Webworm - EchoCreep / GraphWorm IoC (maggio 2026)
# Tool legittimi usati in contesto malevolo
TOOL: dirsearch (github.com/maurosoria/dirsearch)
TOOL: nuclei (github.com/projectdiscovery/nuclei)
# Custom proxy tools Webworm
TOOL: WormFrp
TOOL: ChainWorm
TOOL: SmuxProxy
TOOL: WormSocket
# Patterns comportamentali da monitorare
BEHAVIOR: cmd.exe spawned by non-standard parent process
BEHAVIOR: Unusual OneDrive API calls (graph.microsoft.com) with file creation in per-victim dirs
BEHAVIOR: Discord API traffic with binary/encoded payloads
BEHAVIOR: SoftEther VPN client installation/execution
# Cluster correlati
ALIAS: FishMonger / Aquatic Panda
ALIAS: SixLittleMonkeys
ALIAS: Space Pirates

Due righe per i difensori


L’abuso di servizi cloud legittimi per il C2 richiede un cambio di paradigma nel rilevamento. Il blocco a livello di dominio è inefficace — occorre spostare l’attenzione sul comportamento. I blue team dovrebbero implementare analisi comportamentale del traffico verso API cloud note, cercando pattern anomali di upload/download non correlati all’attività utente attesa. È fondamentale monitorare la creazione di directory insolite su OneDrive enterprise tramite i log di Microsoft 365 Defender e correlare gli accessi OAuth a Microsoft Graph con i baseline comportamentali degli account di servizio. Sul piano degli endpoint, qualsiasi processo che spawni cmd.exe con parent process inusuali dovrebbe attivare alert ad alta priorità. Infine, regole Sigma per i pattern di traffico Discord e Graph API anomali, combinate con threat intelligence sui cluster Webworm, permettono un rilevamento proattivo di queste campagne.


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.

Whatsapp compromesso su iPhone, la ricerca di Forenser sullo 0-click
#CyberSecurity
insicurezzadigitale.com/whatsa…


Whatsapp compromesso su iPhone, la ricerca di Forenser sullo 0-click


Una premessa prima di iniziare: se hai un iPhone con iOS inferiore a 16.7.12, aggiorna, è già tardi e un miracolo che non sia ancora successo niente di brutto.

Detto questo, per anni l’ecosistema Apple è stato raccontato come una fortezza quasi inespugnabile. “Se hai un iPhone sei al sicuro” è diventato uno dei mantra più ripetuti anche fuori dalla bolla tech. Poi arrivano casi come quello documentato da Forenser e improvvisamente quella narrativa inizia a incrinarsi. Non perché iPhone sia diventato improvvisamente insicuro, ma perché il punto debole — come spesso accade — non è il dispositivo in sé. È la catena completa: notifiche, sessioni, social engineering, bug, sincronizzazioni cloud e fiducia implicita dell’utente.

La ricerca pubblicata da Forenser fotografa infatti una serie di compromissioni WhatsApp osservate su dispositivi Apple rimasti fermi a iOS 16 (specificatamente sotto il famoso aggiornamento alla 16.7.12). Non si parla di semplici tentativi di phishing “artigianali”, ma di account effettivamente presi in controllo, con accessi alle chat e utilizzo dell’identità digitale delle vittime per colpire ulteriori contatti.

Le vittime, infatti, non riportano comportamenti compatibili con il classico phishing. Nessun link cliccato volontariamente, nessuna installazione di applicazioni sospette, nessun QR code scansionato deliberatamente, nessuna richiesta di OTP condivisi. Eppure gli account risultano violati.

È questo il dettaglio che ha acceso l’interesse della comunità forense.

Secondo quanto riportato nell’analisi di Forenser, gli utenti colpiti avrebbero ricevuto messaggi specifici poco prima della compromissione. Messaggi che, in alcuni casi, sembrano avere un comportamento anomalo lato client. La ricostruzione tecnica suggerisce che il vettore d’attacco possa sfruttare una vulnerabilità legata alla gestione dei contenuti ricevuti da WhatsApp su iOS 16, permettendo l’esecuzione di operazioni malevole senza necessità di interazione diretta dell’utente.

In altre parole: il semplice ricevere il messaggio potrebbe essere sufficiente ad attivare la catena di compromissione.

È questo il vero significato di 0-click. Nessun tap. Nessun consenso. Nessun comportamento “sbagliato” da parte della vittima.

Nel mondo mobile moderno, questo tipo di attacco rappresenta uno degli scenari più pericolosi in assoluto, perché elimina completamente il principale livello difensivo su cui si basa gran parte della sicurezza consumer: l’utente stesso. Le campagne di phishing tradizionali funzionano solo se qualcuno sbaglia. Gli exploit 0-click invece trasformano il dispositivo in un bersaglio passivo.

La ricerca di Forenser suggerisce inoltre un elemento fondamentale: il problema sembrerebbe concentrarsi su device ancora fermi a certe release superate di iOS 16. Questo potrebbe indicare la presenza di vulnerabilità già corrette nelle versioni successive di iOS, ma ancora sfruttabili sui terminali non aggiornati. Ed è qui che emerge uno dei problemi più sottovalutati dell’ecosistema Apple: l’idea che “se hai un iPhone allora sei automaticamente al sicuro”.

In realtà il modello di sicurezza Apple funziona in maniera estremamente efficace proprio grazie agli aggiornamenti continui. Restare bloccati su una major release precedente significa esporsi progressivamente a vulnerabilità già note, studiate e potenzialmente weaponizzate.

Dal punto di vista operativo, un attacco del genere è devastante perché estremamente difficile da rilevare. Non lascia i classici indicatori di compromissione associati al malware tradizionale. Non rallenta necessariamente il dispositivo. Non mostra finestre sospette. Non installa applicazioni visibili. Tutto avviene all’interno di una superficie software considerata “trusted”: l’app di messaggistica stessa.

E WhatsApp rappresenta un bersaglio ideale.

Dentro quell’applicazione oggi transitano conversazioni personali, documenti, codici OTP, messaggi vocali, relazioni professionali e spesso persino elementi di autenticazione indiretta per servizi bancari o aziendali. Compromettere WhatsApp non significa più soltanto leggere chat private: significa ottenere accesso a una porzione enorme dell’identità digitale della vittima.

L’aspetto forse più interessante dell’indagine di Forenser è che porta l’attenzione su una categoria di minacce spesso percepite come lontane dal mondo reale. Quando si parla di exploit 0-click si pensa immediatamente ad attori statali, intelligence offensive e spyware da milioni di euro. Ma la linea che separa il cyberespionage dal cybercrime si sta assottigliando sempre di più. Tecniche un tempo esclusive delle operazioni governative iniziano lentamente a comparire anche in scenari meno sofisticati.

Ed è esattamente questo a rendere il caso così importante.

Perché al netto dei dettagli tecnici ancora da chiarire completamente, la ricerca di Forenser mostra un cambiamento preciso nel panorama delle minacce mobile: gli smartphone non vengono più attaccati soltanto inducendo l’utente a commettere errori. Sempre più spesso, basta semplicemente raggiungerli.


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.

Hotpatching gratuito per Windows Server 2025 con Azure Arc: guida all’abilitazione
#tech
spcnet.it/hotpatching-gratuito…
@informatica


Hotpatching gratuito per Windows Server 2025 con Azure Arc: guida all’abilitazione


Cos’è l’Hotpatching e perché cambia tutto


Ogni amministratore di sistema conosce bene il problema: arriva il patch Tuesday, si pianifica una finestra di manutenzione, si notificano gli utenti, si aspetta il riavvio e si incrocia le dita sperando che tutto torni su senza intoppi. Con Windows Server 2025 e l’hotpatching abilitato da Azure Arc, questo ciclo faticoso si riduce drasticamente. E da maggio 2026, questa funzionalità è completamente gratuita per tutti i server Arc-enabled.

L’hotpatching consente di applicare aggiornamenti di sicurezza al sistema operativo senza riavviare il server nella maggior parte dei mesi. Microsoft ha annunciato che dal 15 maggio 2026 tutta la fatturazione per l’hotpatch è stata interrotta per i server Windows Server 2025 Standard e Datacenter connessi ad Azure Arc. Non sono più previsti costi per core, tariffe orarie o voci separate in fattura.

Come funziona il ciclo di aggiornamento


L’hotpatching non elimina completamente i riavvii, ma li riduce sensibilmente. Il ciclo funziona su base trimestrale:

  • Mese baseline (1 riavvio ogni 3 mesi): viene installato un aggiornamento cumulativo completo che richiede un riavvio. Questo aggiornamento “alza l’asticella” del sistema per i mesi successivi.
  • Mesi hotpatch (i 2 mesi successivi): vengono distribuiti solo gli aggiornamenti di sicurezza incrementali, applicati in-memory senza riavvio.

In un anno solare si ottengono fino a 8 aggiornamenti mensili senza riavvio e soli 4 riavvii baseline pianificabili. Per ambienti di produzione ad alta disponibilità, è una differenza sostanziale.

Prerequisiti tecnici


Prima di abilitare l’hotpatching, verificare che il server soddisfi i requisiti seguenti:

  • Windows Server 2025 Standard o Datacenter (build 26100.1742 o successiva). Le build di anteprima non sono supportate.
  • Il server deve essere connesso ad Azure Arc tramite il Connected Machine Agent.
  • La macchina deve supportare la Virtualization-Based Security (VBS): firmware UEFI con Secure Boot abilitato. Per le VM Hyper-V, è richiesta una macchina virtuale di Generazione 2.
  • Una subscription Azure attiva (esiste un tier gratuito per iniziare).

Nota: Windows Server 2025 Datacenter: Azure Edition ha l’hotpatching abilitato per impostazione predefinita e non richiede Azure Arc.

Verifica e abilitazione di Virtual Secure Mode (VBS)


Quando si abilita l’hotpatch dal portale Azure, il sistema verifica automaticamente se la Virtual Secure Mode (VSM) è attiva. Se non lo è, l’operazione fallisce con un errore. È conveniente verificare prima manualmente.

Verifica dello stato VSM con PowerShell

Get-CimInstance -Namespace 'root/Microsoft/Windows/DeviceGuard' `
    -ClassName 'win32_deviceGuard' | `
    Select-Object -ExpandProperty 'VirtualizationBasedSecurityStatus'

Se il valore restituito è 2, VSM è attivo e si può procedere. Se è 0 o 1, occorre abilitarlo.

Abilitazione di VSM tramite registro di sistema

New-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\DeviceGuard' `
    -Name 'EnableVirtualizationBasedSecurity' `
    -PropertyType 'Dword' `
    -Value 1 -Force

Dopo aver impostato il valore, riavviare il server e verificare nuovamente che VirtualizationBasedSecurityStatus restituisca 2.

In alternativa, VSM viene abilitato automaticamente configurando funzionalità come Credential Guard, Hypervisor-Protected Code Integrity (HVCI) o Secured-core server. Se il proprio ambiente utilizza già una di queste feature, VSM è probabilmente già attivo.

Connessione ad Azure Arc


Se il server non è ancora connesso ad Azure Arc, il modo più rapido per un singolo server è scaricare ed eseguire lo script di onboarding dal portale Azure:

  1. Aprire il portale Azure e cercare Azure Arc → Machines.
  2. Cliccare su Add/Create → Add a machine.
  3. Selezionare Add a single server e seguire la procedura guidata.
  4. Scaricare ed eseguire lo script PowerShell generato sul server target.

Per un deployment su scala (decine o centinaia di server), Azure Arc supporta l’installazione tramite Group Policy, service principal, Terraform o Configuration Manager. Il Connected Machine Agent è leggero e ha un impatto minimo sulle risorse del sistema.

Abilitazione dell’Hotpatch dal portale Azure


Una volta che il server è connesso ad Azure Arc e VSM è attivo, abilitare l’hotpatch richiede pochi click:

  1. Nel portale Azure, navigare su Azure Arc → Machines.
  2. Selezionare il nome del server target.
  3. Nel pannello laterale, fare clic su Hotpatch.
  4. Cliccare su Confirm.
  5. Attendere circa 10 minuti per la propagazione delle modifiche.

Se lo stato rimane bloccato su Pending, verificare la connettività verso gli endpoint Azure Arc e controllare i log dell’agente in C:\ProgramData\AzureConnectedMachineAgent\Logs.

Automazione con Azure Update Manager


Per gestire l’hotpatching su scala, Azure Update Manager (AUM) è lo strumento consigliato. Permette di:

  • Definire maintenance windows per controllare quando vengono applicati gli aggiornamenti baseline (quelli che richiedono il riavvio).
  • Configurare update policies per applicare automaticamente gli hotpatch nei mesi non-baseline.
  • Monitorare lo stato di conformità di tutti i server Arc da un’unica dashboard.
  • Integrare con Azure Monitor per alert e reportistica.

Con AUM è possibile impostare una finestra di manutenzione mensile di 30 minuti per i riavvii baseline, sapendo che nei due mesi successivi nessun riavvio sarà necessario per gli aggiornamenti di sicurezza. Una politica ragionevole è schedulare i riavvii baseline nella notte del secondo mercoledì del mese baseline, allineandosi al ciclo Patch Tuesday di Microsoft.

Script PowerShell per il troubleshooting dell’agente Arc


Se dopo l’abilitazione l’hotpatch non si attiva correttamente, questo script PowerShell aiuta a diagnosticare i problemi più comuni:

# Verifica stato agente Azure Arc
$svc = Get-Service -Name "himds" -ErrorAction SilentlyContinue
if ($svc) {
    Write-Host "Azure Connected Machine Agent: $($svc.Status)"
} else {
    Write-Host "ERRORE: servizio HIMDS non trovato. Arc non e' installato."
}

# Verifica VBS
$vbs = Get-CimInstance -Namespace 'root/Microsoft/Windows/DeviceGuard' `
    -ClassName 'win32_deviceGuard' | `
    Select-Object -ExpandProperty 'VirtualizationBasedSecurityStatus'
Write-Host "VBS Status: $vbs (2 = attivo, 0/1 = non attivo)"

# Verifica Secure Boot
$sb = Confirm-SecureBootUEFI -ErrorAction SilentlyContinue
Write-Host "Secure Boot abilitato: $sb"

# Log agente Arc (ultimi 50 errori)
$logPath = "C:\ProgramData\AzureConnectedMachineAgent\Logs"
if (Test-Path $logPath) {
    Get-ChildItem $logPath -Filter "*.log" | 
        Sort-Object LastWriteTime -Descending | 
        Select-Object -First 1 | 
        Get-Content | Select-String "ERROR","WARN" | 
        Select-Object -Last 50
}

Considerazioni finali


Il passaggio dell’hotpatching a servizio gratuito rappresenta un cambiamento significativo nella gestione delle patch per Windows Server. Prima era necessario scegliere tra la semplicità operativa (nessun riavvio) e il costo aggiuntivo ($1.50 USD per core al mese, introdotto a luglio 2025). Ora quella scelta non esiste più.

Per chi gestisce ambienti Windows Server 2025 ibridi o on-premises, il percorso consigliato è: verificare i prerequisiti hardware (UEFI + Secure Boot), connettere i server ad Azure Arc, abilitare l’hotpatch dal portale e configurare Azure Update Manager per le finestre di manutenzione baseline. Il risultato pratico: meno riavvii, meno downtime, meno stress per il team IT — senza costi aggiuntivi.


Fonte originale: 4sysops — Free Windows Server 2025 hotpatching with Azure Arc. Documentazione ufficiale: Microsoft Learn — Enable Hotpatch for Azure Arc-enabled servers. Annuncio Microsoft: Microsoft Tech Community.


The Pirate Post ha ricondiviso questo.

In Italia esistono le persone, le conoscenze e, in potenza, l'infrastruttura per uscire dalla minorità digitale, ma i politici dei due partiti meno piccoli non lo sanno né lo vogliono sapere.
The Pirate Post ha ricondiviso questo.

La battaglia per tagliare i ponti tra Italia e Israele nello scambio dei dati personali


Non solo torture e sanzioni commerciali, con Israele c'è in ballo anche la privacy. L’Autorità europea per la protezione dei dati personali ha chiesto un'indagine sulla condotta di Israele, mentre una coalizione italiana si appella al Garante Privacy

Non solo: poiché Israele controlla l'intera infrastruttura di telecomunicazione dei Territori palestinesi occupati e non applica alcuna limitazione territoriale interna nel trattamento dei dati provenienti dall'estero, vi è un rischio concreto e imminente – si legge nella lettera del 2025 – che i dati personali trasferiti dall'Unione europea a entità israeliane confluiscano nei sistemi di sorveglianza militare senza alcuna restrizione o trasparenza. Cosa decide di fare questa volta la Commissione europea? Niente, di nuovo.


wired.it/article/battaglia-tag…

@eticadigitale

Grazie a @vecna per la segnalazione

The Pirate Post ha ricondiviso questo.

«Sfruttare le norme sui diritti umani per contrastare le violazioni della privacy da parte dello Stato».
mastodon.social/@privacypride/…


Non dobbiamo normalizzare gli abusi della sorveglianza digitale. La nuova guida dell'EFF sottolinea i passi concreti da compiere per contrastarli.

Per contribuire a tracciare un percorso verso soluzioni, @eff lancia la guida "Contrastare la sorveglianza digitale arbitraria nelle Americhe" , che si aggiunge al nostro ampio lavoro volto a sfruttare le norme sui diritti umani per contrastare le violazioni della privacy da parte dello Stato.

eff.org/deeplinks/2026/05/we-m…

@privacypride@feddit.it


in reply to Trames Venenosus

@privacypride
Le uniche violazioni dei diritti umani che non vengono mai normalizzate sono quelle dell'articolo 17 comma 2 «Nessun individuo potrà essere arbitrariamente privato della sua proprietà».
Questo viene invocato anche per i signori delle guerre più sanguinose.

Anzi, a pensarci bene, solo per loro, perché della distruzione delle proprietà oltre che della vita delle loro vittime sembra non interessare molto a nessuno.

Trames Venenosus reshared this.

The Pirate Post ha ricondiviso questo.

Zwei wichtige Interviews bei @netzpolitik_feed zeigen, warum Forschung und zivilgesellschaftlicher Einsatz so wichtig für die Umsetzung des DSA sind. Josephine Ballon (HateAid) bzw. Marc Faddoul (AI Forensics) erläutern ihre Arbeit und weshalb Unterstützung aus der Politik nötig ist.

netzpolitik.org/2026/hateaid-n…

netzpolitik.org/2026/ai-forens…

Questa voce è stata modificata (2 giorni fa)
The Pirate Post ha ricondiviso questo.

"Der Fall zeigt für mich, wozu Menschen fähig sind, wenn sie sich zusammenschließen, gemeinsam aufstehen und sich wehren." Ein Rückblick auf die Woche von @dleisegang

netzpolitik.org/2026/die-woche…

The Pirate Post ha ricondiviso questo.

Eigentlich gibt es hohe Hürden dafür, wenn die Polizei mit einem Foto öffentlich nach Tatverdächtigen fahnden will. Doch zum einen setzen manche Öffentlichkeitsfahndungen auch für kleine Delikte ein, zum anderen stammen die Regeln dafür aus einer Zeit vor großen sozialen Medien. Athena Möller kritisiert im Grundrechte-Report 2026, dass sich trotz guter Vorschläge daran nichts ändert

netzpolitik.org/2026/oeffentli…

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.

Ukrainian Intelligence Report: Russian APT Groups Intensify Cyber Operations — 5,927 Incidents, 37% Rise in 2025
#CyberSecurity
securebulletin.com/ukrainian-i…
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 giorni 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…