informatica ha ricondiviso questo.

friendica (DFRN) - Collegamento all'originale
The media in this post is not displayed to visitors. To view it, please log in.

CVE-2026-5426: zero-day in KnowledgeDeliver LMS sfruttato per distribuire BLUEBEAM e Cobalt Strike BEACON


@Informatica (Italy e non Italy)
Mandiant ha pubblicato i dettagli dell'exploitation attiva di CVE-2026-5426, zero-day nel LMS KnowledgeDeliver causato da chiavi ASP.NET machineKey hardcoded e condivise tra tutte le installazioni.

(in)sicurezza digitale

2026-05-27 07:47:40

wordpress - Collegamento all'originale

CVE-2026-5426: zero-day in KnowledgeDeliver LMS sfruttato per distribuire BLUEBEAM e Cobalt Strike BEACON


Si parla di:
Toggle

Un attore di minacce non ancora attribuito ha sfruttato una vulnerabilità zero-day nel sistema LMS KnowledgeDeliver, sviluppato dalla giapponese Digital Knowledge, per ottenere Remote Code Execution non autenticato e distribuire la web shell in-memory BLUEBEAM. L’indagine di Mandiant rivela un attacco sofisticato a più strati: dalla deserialization di ViewState ASP.NET al social engineering degli utenti finali con un falso plugin di autenticazione che installa Cobalt Strike BEACON, personalizzato per organizzazione. Una vulnerabilità che colpisce sistemi universitari e aziendali in tutto il mondo a causa di una scelta progettuale fatale: chiavi crittografiche condivise tra tutte le installazioni.

La radice del problema: chiavi macchina hardcoded


KnowledgeDeliver è un Learning Management System (LMS) enterprise ampiamente utilizzato in Giappone e in numerosi contesti educativi e corporate internazionali. Come molte applicazioni ASP.NET, utilizza la funzionalità ViewState per preservare lo stato delle pagine web tra una richiesta e l’altra. ViewState è protetto tramite una machineKey: una coppia di chiavi crittografiche (validationKey + decryptionKey) che garantiscono l’autenticità e la riservatezza dei dati serializzati inviati tra client e server.

Il difetto critico di KnowledgeDeliver, ora tracciato come CVE-2026-5426, consiste nell’utilizzo di valori machineKey statici e identici in tutte le installazioni del prodotto. Digital Knowledge distribuiva il software con chiavi hardcoded nel file web.config, anziché generare valori unici per deployment. Il risultato è devastante: chiunque abbia accesso a una singola installazione — anche la propria — può ricavare le chiavi e usarle per forgiare payload ViewState malevoli validi su qualunque altro server che esegue KnowledgeDeliver nel mondo.

La catena di attacco: da ViewState a RCE


L’exploitation della vulnerabilità segue un pattern ben documentato, già osservato in attacchi a Sitecore e in campagne evidenziate da Microsoft riguardanti chiavi macchina esposte. L’attaccante costruisce un payload serializzato contenente istruzioni arbitrarie e lo inserisce nel parametro __VIEWSTATE di una normale richiesta HTTP. Il server ASP.NET, fidandosi della firma crittografica (valida perché l’attaccante conosce la chiave), deserializza il payload e lo esegue con i privilegi del processo IIS (tipicamente Network Service o Application Pool Identity).

L’intera operazione non richiede credenziali, autenticazione pregressa o interazione utente sul lato server. Un singolo POST HTTP con il ViewState artefatto è sufficiente a ottenere esecuzione di codice remoto. Mandiant ha datato la compromissione iniziale alla fine del 2025, suggerendo che l’attore fosse a conoscenza della vulnerabilità mesi prima della disclosure pubblica avvenuta il 24 febbraio 2026.

BLUEBEAM: la web shell fantasma


Una volta ottenuto il foothold iniziale, l’attaccante ha distribuito BLUEBEAM, una web shell .NET nota anche come Godzilla. Ciò che distingue BLUEBEAM dalle web shell tradizionali è la sua natura interamente in-memory: il malware non scrive file su disco ma viene caricato direttamente nel processo worker IIS (w3wp.exe), riducendo drasticamente la superficie di rilevamento per strumenti forensi e antivirus basati sulla scansione del filesystem.

BLUEBEAM comunica con il suo operatore tramite richieste HTTP POST cifrate, mascherandosi come normale traffico web. Attraverso questo canale, l’attaccante può eseguire comandi arbitrari, caricare ulteriori payload, modificare file e mantenere persistenza nell’ambiente compromes. Mandiant ha osservato l’uso del tool di sistema icacls per allargare i permessi sul filesystem, indebolendo ulteriormente i controlli di sicurezza dell’host compromesso.

Il vettore secondario: social engineering sugli utenti finali


L’attacco non si è fermato al server. Con l’accesso a w3wp.exe, l’attaccante ha manomesso i file JavaScript legittimi del portale LMS, iniettando codice malevolo nelle pagine visitate dagli studenti e dai dipendenti. Il codice iniettato mostrava un avviso di sicurezza convincente, informando l’utente della necessità di installare un “plugin di autenticazione” aggiuntivo per continuare ad accedere alla piattaforma. Parallelamente, caricava script da infrastruttura controllata dall’attaccante.

Gli utenti che installano il falso plugin vengono infettati con un Cobalt Strike BEACON, il framework di post-exploitation commerciale più abusato nel panorama delle minacce avanzate. L’elemento che rivela la natura mirata e pianificata dell’operazione è la personalizzazione del payload: il BEACON era cifrato con una chiave derivata dal nome dell’organizzazione vittima, dimostrando che l’attaccante aveva condotto ricognizione preventiva e aveva predisposto un payload ad hoc per ogni target.

Timeline degli eventi


  • Fine 2025: Compromissione iniziale rilevata da Mandiant durante un incident response
  • 24 febbraio 2026: Data limite per le installazioni vulnerabili (le versioni precedenti a questa data con machineKey di default sono esposte)
  • 25 maggio 2026: Pubblicazione dell’advisory Mandiant/Google Cloud e assegnazione CVE-2026-5426


Indicatori di compromissione (IoC)

# BLUEBEAM web shell
SHA-256: 7c1f99dca8e5a7897892f9d224a6495023a2cfd2671697d229d355978c415ed2
File:    LoadLibrary.dll (caricato in-memory da w3wp.exe)
# CVE
CVE-2026-5426 – KnowledgeDeliver ASP.NET machineKey RCE (CVSS: critico)
# Segnali di detection
Windows Application Log - Event ID 1316 (ViewState validation failure/anomalia)
Processo: w3wp.exe che genera child process cmd.exe, powershell.exe, cscript.exe
File JS del portale modificati con tag 
User-Agent anomali nelle richieste POST a pagine .aspx (concatenazione di UA multipli)
Uso di icacls.exe da processi IIS per modifica permessi
# Pattern ViewState malevolo
Parametro __VIEWSTATE con lunghezza anomala (>50KB)
Richieste POST a pagine .aspx che non prevedono ViewState volumioso

Remediation e due righe per i difensori


La mitigazione primaria e indispensabile è la rotazione immediata dei valori machineKey a valori unici e crittograficamente robusti per ogni singola installazione. Le chiavi devono essere generate con un generatore di numeri casuali sicuro (CSPRNG) e non devono mai essere condivise tra ambienti diversi. La configurazione va inserita nel file web.config sotto il tag <system.web><machineKey validationKey="..." decryptionKey="..." />. Oltre alla remediation tecnica, le organizzazioni dovrebbero limitare l'accesso al portale LMS a range IP fidati, condurre threat hunting retrospettivo alla ricerca di sign of compromise elencati sopra, verificare l'integrità dei file JavaScript del portale tramite confronto hash, e investigare eventuali installazioni del presunto "plugin di autenticazione" sulle macchine degli utenti finali. Questo incidente è un promemoria sistematico del rischio insito nelle configurazioni di default condivise: una singola chiave hardcoded può trasformare un'applicazione enterprise globale in una superficie di attacco che compromette simultaneamente organizzazioni altrimenti non correlate.


@Informatica (Italy e non Italy)
informatica ha ricondiviso questo.

friendica (DFRN) - Collegamento all'originale
The media in this post is not displayed to visitors. To view it, please log in.

Void Dokkaebi evolve InvisibleFerret: il malware nordcoreano ora usa Cython per sfuggire agli antivirus


@Informatica (Italy e non Italy)
Void Dokkaebi (Famous Chollima), APT nordcoreano specializzato nel targeting di sviluppatori software, ha aggiornato il proprio infostealer InvisibleFerret compilandolo da Python a Cython. I file ora

(in)sicurezza digitale

2026-05-26 16:57:29

wordpress - Collegamento all'originale

Void Dokkaebi evolve InvisibleFerret: il malware nordcoreano ora usa Cython per sfuggire agli antivirus


Void Dokkaebi, il gruppo APT nordcoreano tracciato anche come Famous Chollima, ha completato una significativa evoluzione del proprio arsenale offensivo: il malware infostealer InvisibleFerret è stato ricompilato da Python a Cython, trasformando script leggibili in binari nativi che sfuggono alla quasi totalità dei meccanismi di rilevamento basati sull’analisi del codice sorgente. La ricerca pubblicata da Trend Micro a maggio 2026 rivela una campagna di spionaggio industriale di proporzioni allarmanti che colpisce sviluppatori software con accesso a wallet di criptovalute e infrastrutture CI/CD.

Profilo del gruppo: chi è Void Dokkaebi


Void Dokkaebi, denominato anche Famous Chollima nell’ecosistema di threat intelligence di CrowdStrike, è un intrusion set allineato agli interessi della Repubblica Popolare Democratica di Corea (RPDC). Il gruppo si distingue da altre unità cyber nordcoreane come Lazarus Group per la specializzazione quasi esclusiva nel targeting di sviluppatori software, ingegneri DevOps e professionisti del settore Web3 che detengono chiavi di firma, credenziali di wallet e accesso privilegiato a pipeline di continuous integration e deployment.

La sua tattica operativa preferita è quella del “fake job interview”: gli operatori si spacciano per recruiter di aziende crypto o AI rinominate, contattano le vittime su piattaforme come LinkedIn o GitHub, e le convincono a clonare ed eseguire repository di codice come parte di una presunta prova tecnica per un colloquio. Il codice in apparenza innocuo nasconde i payload malevoli.

La campagna del 2026: infrastruttura blockchain e repository compromessi


L’analisi condotta a marzo-maggio 2026 ha rivelato la portata impressionante dell’infrastruttura malevola costruita dal gruppo. I ricercatori hanno identificato:

  • Oltre 750 repository GitHub infetti, molti appartenenti a organizzazioni legittime come DataStax e Neutralinojs, che presentano marcatori di infezione nei workflow CI/CD
  • Più di 500 configurazioni di task Visual Studio Code modificate per eseguire payload al momento dell’apertura del progetto
  • 101 istanze dello strumento di commit tampering utilizzato per iniettare codice malevolo nei repository

L’elemento più innovativo della campagna 2026 è l’utilizzo di infrastruttura blockchain per la distribuzione dei payload. Void Dokkaebi sfrutta Tron, Aptos e Binance Smart Chain come staging server per i malware, rendendo gli indicatori di compromissione praticamente immuni ai tradizionali meccanismi di takedown. Aggiornare un riferimento su blockchain equivale a cambiare il payload consegnato a tutte le vittime già infette, senza modificare un singolo byte nei repository.

L’evoluzione tecnica: da Python a Cython


Il cuore dell’aggiornamento analizzato da Trend Micro riguarda InvisibleFerret, il modulo infostealer centrale nell’arsenale di Void Dokkaebi. Precedentemente distribuito come script Python in chiaro — facilmente analizzabili e rilevabili da sistemi YARA e EDR — il malware è stato interamente ricompilato tramite Cython.

Cython è un compilatore che traduce codice Python in sorgente C/C++ e poi in binari nativi. Il risultato pratico è che InvisibleFerret viene ora distribuito come file .pyd su Windows (Python extension DLL) e come librerie condivise .so su macOS. Entrambi i formati sono binari compilati: non contengono stringhe leggibili, non sono interpretabili senza reverse engineering specializzato, e bypassano le regole di detection tradizionalmente scritte per identificare script Python sospetti.

Le capacità del malware rimangono invariate rispetto alle versioni precedenti:

  • Apertura di backdoor per accesso remoto persistente
  • Furto di credenziali dai principali browser (Chrome, Firefox, Edge)
  • Monitoraggio degli appunti di sistema (clipboard hijacking per intercettare indirizzi di wallet)
  • Keylogging per catturare password e seed phrase
  • Esfiltrazione diretta da wallet di criptovalute locali
  • Ricognizione dell’ambiente: processi in esecuzione, file system, variabili d’ambiente


Toolset correlato: BeaverTail, OtterCookie, OmniStealer


InvisibleFerret non opera mai isolatamente. Il gruppo lo utilizza in combinazione con altri malware della stessa famiglia operativa. BeaverTail è il dropper JavaScript iniziale che viene eseguito durante il “test tecnico”, il quale successivamente scarica e installa InvisibleFerret. OtterCookie è un ulteriore stealer focalizzato sui browser e sui file di configurazione. OmniStealer amplia la superficie di furto a client di posta e applicazioni VPN. Tutti questi componenti possono essere aggiornati dinamicamente tramite i reference blockchain, garantendo al gruppo una flessibilità operativa senza precedenti.

Indicatori di compromissione (IoC)

# File IOC - InvisibleFerret Cython (maggio 2026)
# Estensioni malevole su Windows
*.pyd  (file Python extension DLL con firma digitale assente o anomala)
# Estensioni malevole su macOS
*.so   (librerie condivise caricate da processi Python non standard)
# Pattern comportamentale
Processo Python che carica estensioni .pyd/.so non firmate da directory temp
Connessioni in uscita verso endpoint Tron/Aptos/BSC non previsti dall'applicazione
Lettura anomala del keychain macOS o del credential manager Windows
Accessi al filesystem wallet: ~/.bitcoin, ~/.ethereum, ~/.solana
# Infrastruttura C2 (blockchain-staged)
TRC20 address utilizzati come dead drop resolver su Tron network
Transazioni su Aptos con payload codificati nei campi memo

Due righe per i difensori


La migrazione a Cython rende obsolete le regole YARA basate su stringhe Python. I team di sicurezza devono aggiornare la propria postura difensiva su più livelli. A livello di endpoint, occorre implementare controlli di integrità sulle estensioni Python caricate dinamicamente e monitorare processi Python che importano moduli non presenti nell’ambiente di sviluppo ufficiale. A livello di rete, è essenziale bloccare o monitorare le connessioni verso endpoint RPC di reti blockchain non autorizzate (Tron API: api.trongrid.io, Aptos: fullnode.aptoslabs.com). A livello procedurale, le organizzazioni dovrebbero verificare l’identità dei recruiter prima di clonare ed eseguire qualsiasi repository fornito esternamente, e condurre i test tecnici in ambienti isolati (sandbox o VM senza credenziali di produzione). Gli sviluppatori che lavorano su progetti Web3 o che detengono wallet crypto devono essere considerati target ad alto rischio e ricevere formazione specifica sul riconoscimento di queste campagne di ingegneria sociale.


@Informatica (Italy e non Italy)
informatica ha ricondiviso questo.

glitchsoc - Collegamento all'originale
The media in this post is not displayed to visitors. To view it, please go to the original post.

Retry Storm nelle architetture distribuite: quando la resilienza diventa il problema
#tech
spcnet.it/retry-storm-nelle-ar…
@informatica

Spcnet.it

2026-05-26 16:59:19

wordpress - Collegamento all'originale

Retry Storm nelle architetture distribuite: quando la resilienza diventa il problema


Le architetture distribuite moderne sono progettate per la resilienza. Aggiungiamo retry per i fallimenti transitori, replica per la durabilità, autoscaling per l’elasticità, circuit breaker per l’isolamento. Ogni meccanismo, preso singolarmente, migliora la disponibilità. Ma sotto stress, la loro interazione può abbattere l’intero sistema.

La maggior parte delle interruzioni enterprise non è causata dall’assenza di fault tolerance. È causata da meccanismi di fault tolerance non delimitati che reagiscono simultaneamente. Questo articolo analizza il fenomeno del retry storm e mostra come progettare sistemi con bounded reliability.

1. Retry Storm: quando la resilienza moltiplica il traffico


I retry sono progettati per proteggere dai fallimenti temporanei. Ma i retry moltiplicano il carico. Ecco un esempio semplificato della logica di retry che si trova comunemente nei sistemi di integrazione tra servizi:

import time
import random

def downstream_service():
    latency = random.choice([0.1, 0.2, 0.8])
    time.sleep(latency)
    if latency > 0.7:
        raise TimeoutError("Slow response")
    return "OK"

def call_with_retries(max_attempts=3):
    for attempt in range(max_attempts):
        try:
            return downstream_service()
        except TimeoutError:
            print(f"Retry {attempt+1}")
    raise Exception("Failed after retries")

In condizioni normali questa logica funziona correttamente. Ma sotto carico elevato si innesca una spirale:
  1. La latenza aumenta
  2. Scattano i timeout
  3. Ogni richiesta viene ritentata fino a 3 volte
  4. Il traffico verso il backend triplica
  5. Il backend rallenta ulteriormente
  6. Aumentano i retry

In un’architettura a livelli tipica — Gateway → Experience API → Process API → System API → Database — se ogni livello gestisce i retry in modo indipendente, l’amplificazione del carico diventa moltiplicativa, non additiva. Un singolo rallentamento del database può abbattere tre livelli API a cascata in pochi minuti.

Il pattern Bounded Retry (sicuro per la produzione)


La soluzione non è eliminare i retry, ma delimitarli e renderli consapevoli del carico di sistema:

def call_with_bounded_retries(max_attempts=2, system_load=0.5):
    # Fail-fast quando il sistema è sotto stress
    if system_load > 0.75:
        return None

    for attempt in range(max_attempts):
        try:
            return downstream_service()
        except TimeoutError:
            # Exponential backoff con jitter
            backoff = 0.2 * (2 ** attempt)
            time.sleep(backoff + random.uniform(0, 0.1))
    return None

Le differenze chiave rispetto alla versione base:
  • Ceiling sui retry: massimo 2 tentativi invece di 3
  • Exponential backoff: aumenta il tempo di attesa ad ogni tentativo
  • Jitter: aggiunge variabilità casuale per evitare wave di retry sincronizzate
  • Load-aware circuit: disabilita i retry completamente quando il sistema è sovraccarico


2. Fan-out della replica e collasso della coordinazione


La replica sincrona migliora la durabilità dei dati. Ma ogni write si moltiplica per il numero di repliche, aumentando il costo di coordinazione:

def write_to_replicas(data, replicas=3):
    for _ in range(replicas):
        time.sleep(0.2)  # Simula latenza di replica

Sotto traffico elevato, il lag delle repliche cresce, i client iniziano a ritentare le scritture, e il carico effettivo di write raddoppia. In sistemi di elaborazione aziendale (ordini, fatturazione, riconciliazione) questo pattern causa un collasso del throughput non perché i dati vadano persi, ma perché la coordinazione sopraffà il sistema.

La soluzione è la durabilità stratificata: non tutte le scritture richiedono le stesse garanzie. Le transazioni critiche usano replica completa; log ed eventi non critici ne richiedono meno. La reliability deve essere proporzionata, non massimizzata ciecamente.

3. Loop di feedback dell’autoscaling


L’autoscaling reagisce alle metriche di traffico. Ma se queste metriche sono gonfiate dai retry, il sistema escala in risposta a traffico artificiale:

def autoscale_safe(request_rate, sustained_load):
    # Scala su domanda sostenuta, non su spike da retry
    if sustained_load and request_rate > 120:
        print("Scaling up — domanda organica confermata")

Segnali più affidabili su cui basare l’autoscaling:
  • Domanda sostenuta (non spike improvvisi)
  • Tendenze nella distribuzione della latenza (P95, P99)
  • RPS organiche (esclusi i retry)
  • Velocità di crescita delle code


4. Il problema reale: le reazioni correlate


Retry, replica e autoscaling reagiscono ciascuno a segnali diversi. Ma sotto stress, reagiscono tutti allo stesso segnale di degradazione. Questa correlazione crea il fallimento a cascata.

Scenario reale — payment reconciliation service:

  1. La latenza dell’ERP sale a 700ms
  2. Il servizio Billing va in timeout a 500ms
  3. Billing ritenta 3 volte
  4. La Process API ritenta l’orchestrazione
  5. Il Gateway ritenta la richiesta client
  6. L’autoscaling reagisce allo spike
  7. Il lag di replica del database aumenta
  8. La Dead Letter Queue inizia a riempirsi

In pochi minuti, un rallentamento minore diventa un’interruzione di piattaforma. La causa principale: reazione non delimitata.

5. Pattern di Bounded Reliability per sistemi API

Retry Budget


Il carico effettivo è: Carico Effettivo = RPS in ingresso × Numero Retry. Con 1.000 RPS e 3 retry, il backend riceve 3.000 richieste. Impostare un budget massimo di retry per richiesta e per servizio è non negoziabile in produzione.

Classificazione degli Errori


Non tutti gli errori sono retriable. Una tassonomia chiara:

Tipo di ErroreRetry?Azione
CONNECTIVITYSìBounded retry
TIMEOUTSìBackoff esponenziale
VALIDATION (4xx)NoFail fast
AUTH (401/403)NoAlert immediato

I retry ciechi su errori di validazione o autenticazione sono debito architetturale.

Idempotency obbligatoria


I retry senza idempotency causano corruzione dei dati. Il transaction ID deve essere deterministic, non generato casualmente ad ogni tentativo:

# ❌ Non sicuro: genera un nuovo ID ad ogni retry
transaction_id = uuid()

# ✅ Sicuro: riusa l'ID dalla richiesta originale
transaction_id = payload.get("transaction_id") or request.headers["correlation-id"]

Dead Letter Queue con Osservabilità


Tracciare le seguenti metriche come segnali di early warning:

  • Percentuale di retry sul totale delle richieste
  • Frequenza dei timeout per endpoint
  • Velocità di crescita della DLQ
  • Shift nella distribuzione P95 della latenza


Conclusione


Le retry storm non iniziano con un fallimento catastrofico. Iniziano con un piccolo aumento di latenza, qualche timeout, una manciata di retry. Poi i meccanismi di fault tolerance reagiscono insieme — e la loro interazione non controllata trasforma un disagio minore in un’interruzione totale.

La resilienza nelle architetture distribuite non significa aggiungere più safety net. Significa controllare come quei safety net si comportano sotto stress. Delimita i retry. Classifica i fallimenti. Forza l’idempotency. Scala su domanda organica. Monitora i loop di feedback prima che si avvitino.

La differenza tra una piattaforma resiliente e un fallimento a cascata sta quasi sempre nella risposta a una sola domanda: i tuoi meccanismi di reliability sono controllati o sono illimitati?

Fonte: How Retry Storms Crash API-Led Systems: Bounded Reliability Patterns — DZone


How Retry Storms Crash API-Led Systems

Unbounded retries and autoscaling can turn minor latency into cascading outages. API reliability must be bounded and load-aware to prevent retry storms.
Manjeera Chanda (dzone.com)

#tech @Informatica (Italy e non Italy)
informatica ha ricondiviso questo.

glitchsoc - Collegamento all'originale
The media in this post is not displayed to visitors. To view it, please go to the original post.

nmap su Linux: guida completa alla scansione e discovery di rete
#tech
spcnet.it/nmap-su-linux-guida-…
@informatica

Spcnet.it

2026-05-26 16:59:55

wordpress - Collegamento all'originale

nmap su Linux: guida completa alla scansione e discovery di rete


nmap è uno degli strumenti più potenti e longevi nell’arsenale di qualsiasi sistemista Linux. Nato nel 1997, è oggi uno standard de facto per l’audit di rete, la verifica della superficie d’attacco esposta e il troubleshooting di connettività. Questa guida copre i comandi e le tecniche che un sysadmin usa davvero in produzione: niente teoria astratta, solo esempi concreti.

Nota legale: scansionate solo reti e host di vostra proprietà o per cui avete un’autorizzazione esplicita. La scansione non autorizzata può essere illegale nella vostra giurisdizione.

Installazione di nmap


nmap è disponibile nei repository di tutte le principali distribuzioni Linux:

# Debian / Ubuntu
sudo apt install nmap

# Fedora / RHEL / CentOS
sudo dnf install nmap

# Arch / Manjaro
sudo pacman -S nmap

Verificate l’installazione con:
nmap --version

Dovreste vedere qualcosa come Nmap version 7.94 o superiore. Le funzionalità più avanzate (SYN scan, OS detection) richiedono privilegi root.

Host Discovery: chi è attivo sulla rete?


Il primo passo in qualsiasi audit è capire quali host sono raggiungibili. Il ping scan usa il flag -sn, che dice a nmap di non eseguire scansioni delle porte:

nmap -sn 192.168.1.0/24

Su una LAN locale nmap usa ARP discovery, più veloce e capace di trovare dispositivi che ignorano il ping ICMP. L’output tipico è:
Nmap scan report for 192.168.1.1
Host is up (0.0011s latency).
MAC Address: A4:3E:51:XX:XX:XX (Ubiquiti Networks)

Nmap scan report for 192.168.1.10
Host is up (0.00032s latency).
MAC Address: DC:A6:32:XX:XX:XX (Raspberry Pi Trading)

È un inventario rapido: ottimo dopo aver aggiunto un nuovo dispositivo e non ricordarsi quale IP ha ottenuto dal DHCP.

Scansione delle Porte

Scansione di default


Senza flag aggiuntivi, nmap scansiona le 1.000 porte TCP più comuni. Non richiede root, ma i risultati sono meno dettagliati:

nmap 192.168.1.10

SYN Scan (Stealth Scan)


La SYN scan è la modalità default quando si esegue nmap come root. Invia un pacchetto SYN senza completare il three-way handshake TCP: più veloce e meno visibile nei log applicativi:

sudo nmap -sS 192.168.1.10

Scansione di tutte le 65.535 porte


Le 1.000 porte di default possono mancare servizi su porte non standard — MySQL su 33060, SSH spostato su 2222:

sudo nmap -sS -p- 192.168.1.10

Porte specifiche o range

# Porte specifiche
sudo nmap -p 22,80,443,3306 192.168.1.10

# Range di porte
sudo nmap -p 1-1024 192.168.1.10

UDP Scanning


L’UDP è spesso dimenticato. DNS (porta 53), SNMP (161) e NTP (123) girano su UDP e sono vettori comuni di attacco e misconfiguration:

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

Rilevamento di Servizi e Versioni


Il flag -sV esegue probe sulle porte aperte per determinare servizio e versione. È il primo scan da eseguire su un server sconosciuto:

sudo nmap -sV 192.168.1.10

Output esempio:
PORT     STATE SERVICE VERSION
22/tcp   open  ssh     OpenSSH 8.9p1 Ubuntu 3ubuntu0.6
80/tcp   open  http    nginx 1.24.0
3306/tcp open  mysql   MySQL 8.0.35

Rivela immediatamente con cosa si ha a che fare e può evidenziare software obsoleto — un win immediato per la sicurezza.

Rilevamento del Sistema Operativo


nmap può fare ipotesi sull’OS basandosi sul fingerprinting del TCP/IP stack:

sudo nmap -O 192.168.1.10

Output:
OS details: Linux 5.15 - 5.19, Linux 6.1
Network Distance: 1 hop

Non è sempre preciso su VM o dispositivi con stack TCP personalizzati, ma fornisce un segnale utile per distinguere server Linux da macchine Windows o embedded su un segmento di rete.

Aggressive Scan: tutto in uno


Il flag -A abilita OS detection, version detection, script scanning e traceroute in un colpo solo:

sudo nmap -A 192.168.1.10

Genera molto traffico e richiede tempo. Non usatelo su reti di produzione senza motivo, ma per un audit completo di un singolo host è estremamente comodo.

Nmap Scripting Engine (NSE)


L’NSE è ciò che distingue nmap da un semplice port scanner. Permette di eseguire script contro host e servizi scoperti. Gli script si trovano in /usr/share/nmap/scripts/ e coprono vulnerability detection, enumerazione di servizi e molto altro.

Verifiche pratiche

# Categoria default
sudo nmap --script=default 192.168.1.10

# Scansione vulnerabilità (più invasivo - usare deliberatamente)
sudo nmap --script=vuln 192.168.1.10

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

# Header HTTP esposti (versioni server, debug info)
sudo nmap --script=http-headers -p 80,443 192.168.1.10

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

L’HTTP headers scan è sorprendentemente utile: è frequente trovare server che espongono header con versione del software e informazioni di debug che avrebbero dovuto essere rimosse.

Per elencare tutti gli script disponibili per un servizio:

ls /usr/share/nmap/scripts/ | grep -i ssh

Formati di Output


Per qualunque cosa oltre un controllo rapido, salvare l’output è fondamentale:

# Output normale su file
sudo nmap -sV 192.168.1.0/24 -oN scan_results.txt

# XML (utile per automazione e import in altri tool)
sudo nmap -sV 192.168.1.0/24 -oX scan_results.xml

# Formato grepable
sudo nmap -sV 192.168.1.0/24 -oG scan_results.gnmap

# Tutti i formati in una volta sola
sudo nmap -sV 192.168.1.0/24 -oA scan_results

Il flag -oA crea tutti e tre i file con il prefisso specificato. L’output XML si presta bene al parsing automatizzato.

Timing e Velocità


nmap dispone di sei template di timing, da T0 (lentissimo) a T5 (aggressivo). Il default è T3. Per la maggior parte delle scansioni su reti locali affidabili:

sudo nmap -sS -T4 192.168.1.0/24

Su VPN o connessioni lente, scendere a T2 evita falsi negativi causati da pacchetti persi.

Combinazioni Pratiche per Sysadmin


Questi sono i comandi che si usano davvero nel lavoro quotidiano:

# Porte aperte su un host (solo quelle definitivamente aperte)
sudo nmap -sS -T4 --open 192.168.1.10

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

# MySQL esposto sulla rete? (non dovrebbe mai esserlo)
sudo nmap -p 3306 --open 192.168.1.0/24

# Host discovery + version scan concatenati (solo host attivi)
sudo nmap -sn 192.168.1.0/24 -oG - | grep "Up" | awk '{print $2}' | sudo nmap -sV -iL -

L’ultimo comando è particolarmente potente: esegue prima un ping scan, filtra gli host attivi, poi esegue la version scan solo su di loro. Ideale per subnet grandi.

Gestione dei Target e Firewall

# Range di IP
nmap 192.168.1.1-50

# Host da file (uno per riga)
nmap -iL hosts.txt

# Escludere host dalla scansione
nmap 192.168.1.0/24 --exclude 192.168.1.1,192.168.1.5

nmap distingue tre stati delle porte: open, closed e filtered. Una porta filtered indica che un firewall sta bloccando i probe. Se vedete molte porte filtered su un server di vostra proprietà senza aspettarvelo, investigate: potrebbe essere ufw, firewalld, regole nftables o un security group del cloud provider.

Conclusione


Host discovery, port scanning, version detection, NSE scripts e salvataggio dell’output sono le fondamenta di nmap. Iniziate con -sn per la discovery, aggiungete -sV quando servono i dettagli sui servizi, portate gli script NSE quando volete approfondire. Mantenete il timing conservativo sulle reti di produzione e aggressivo nel vostro lab.

Se state verificando le regole firewall, nmap è tra i migliori strumenti per controllare che ciò che pensate sia bloccato lo sia davvero.

Fonte originale: nmap on Linux: Guide to Network Scanning and Discovery — LinuxBlog.io


nmap on Linux: Guide to Network Scanning and Discovery | LinuxBlog.io

A practical guide to nmap on Linux covering host discovery, port and service scanning, OS detection, NSE scripts, output formats, and real-world command combinations sysadmins actually use.
Hayden James (LinuxBlog.io)

#tech @Informatica (Italy e non Italy)

don't like this

informatica ha ricondiviso questo.

friendica (DFRN) - Collegamento all'originale

Magnifica Humanitas e non solo, ecco le vere sfide dell’intelligenza artificiale. Parla il prof. Giustozzi

Per vedere altri post come questo, segui la comunità @Informatica (Italy e non Italy)

Conversazione di Marco Mayer con Corrado Giustozzi, docente di cybersecurity nel corso di Laurea Magistrale in Ingegneria dei Sistemi Intelligenti

@Informatica (Italy e non Italy)
informatica ha ricondiviso questo.

friendica (DFRN) - Collegamento all'originale

Accessi non autorizzati a GitHub: in gioco la supply chain software, ecco come difendersi


@Informatica (Italy e non Italy)
Il dato significativo non è soltanto l’accesso non autorizzato a repository interni di GitHub, ma il vettore. Ecco perché una componente apparentemente periferica diventa porta d’ingresso verso asset ad alto valore e

@Informatica (Italy e non Italy)
informatica ha ricondiviso questo.

mastodon - Collegamento all'originale

I Paesi Bassi bloccano l'acquisizione da parte degli Stati Uniti di un fornitore digitale vitale

In tutta Europa sono aumentate le preoccupazioni circa la dipendenza dell'Unione dalla tecnologia americana.

politico.eu/article/netherland…

@informatica

Netherlands blocks US takeover of vital digital supplier

BRUSSELS — The Dutch government is blocking a United States-based company’s attempts to acquire a key online identification IT supplier. Dutch firm Solvinity runs a platform for the country…
Pieter Haeck (POLITICO)
@Informatica (Italy e non Italy)
informatica ha ricondiviso questo.

friendica (DFRN) - Collegamento all'originale

Truffa WhatsApp con malware 0click: allarme su iPhone (iOs 16)


@Informatica (Italy e non Italy)
Una catena di vulnerabilità tra ImageIO e WhatsApp per iOS ha colpito iPhone fermi a iOS 16, permettendo a un attaccante di inviare richieste di bonifico dai numeri delle vittime senza lasciare tracce nelle chat locali né nei dispositivi collegati
L'articolo Truffa WhatsApp con

@Informatica (Italy e non Italy)
informatica ha ricondiviso questo.

mastodon - Collegamento all'originale

Copia privata, il Tar del Lazio sospende la “tassa” sul Cloud per la copia privata. Accolti i ricorsi (fra gli altri) di AWS e IBM

La decisione è giunta dopo le proteste del settore tecnologico nel suo insieme (Anitec-Assinform, AIIP, Assintel) rispetto ad un provvedimento considerato come una “tassa” pretestuosa nei confronti di provider di servizi aziendali B2B per la conservazione di copia privata di contenuti in Cloud.

key4biz.it/copia-privata-il-ta…

@informatica

Copia privata, Tar sospende “tassa” su Cloud su ricorso IBM e AWS

Tar del Lazio sospende fino a metà giugno il decreto che estendeva anche ai cloud provider il pagamento dell'equo compenso per copia privata.
Paolo Anastasio (Key4biz)
@Informatica (Italy e non Italy)
informatica ha ricondiviso questo.

friendica (DFRN) - Collegamento all'originale

Tra NIS2 e Standard


@Informatica (Italy e non Italy)
Nello scenario degli standard nazionali e internazionali, è opportuno prendere in esame quelli più rilevanti in termini di adozione e compatibilità. Questo articolo analizza, confronta e riflette sulle differenze tra […]
L'articolo Tra NIS2 e Standard proviene da Edoardo Limone.

L'articolo proviene edoardolimone.com/2026/05/26/t…

@Informatica (Italy e non Italy)
informatica ha ricondiviso questo.

friendica (DFRN) - Collegamento all'originale

Magnifica Humanitas, che cosa lega il Papa ad Anthropic

Per vedere altri post come questo, segui la comunità @Informatica (Italy e non Italy)

Il più importante documento programmatico di Papa Leone XIV parla non tanto di tecnologia, ma di come la Chiesa può agire in un contesto in trasformazione. L'intervento di Andrea Cavallini, sacerdote da 15 anni nella diocesi di Roma e docente di

@Informatica (Italy e non Italy)
informatica ha ricondiviso questo.

friendica (DFRN) - Collegamento all'originale
The media in this post is not displayed to visitors. To view it, please log in.

Laravel-Lang compromessa: oltre 700 versioni PHP infettate da uno stealer cross-platform


@Informatica (Italy e non Italy)
Un attacco supply chain ha riscritto oltre 700 tag git nei pacchetti Laravel-Lang per distribuire uno stealer PHP cross-platform capace di esfiltrare credenziali cloud, token CI/CD, wallet crypto e segreti DevOps. Il payload si

(in)sicurezza digitale

2026-05-25 16:37:30

wordpress - Collegamento all'originale

Laravel-Lang compromessa: oltre 700 versioni PHP infettate da uno stealer cross-platform


Un sofisticato attacco alla supply chain ha compromesso quattro pacchetti PHP appartenenti al progetto Laravel-Lang, iniettando codice malevolo in oltre 700 versioni pubblicate in rapida successione tra il 22 e il 23 maggio 2026. Il payload — uno stealer cross-platform da quasi 6.000 righe di codice — è stato progettato per drenare credenziali cloud, token CI/CD, wallet di criptovalute e segreti di repository da qualsiasi sistema che utilizzi queste librerie di localizzazione diffusissime nell’ecosistema Laravel.

La natura dell’attacco: tag git riscritti, non codice sorgente


Quello che rende questa campagna particolarmente insidiosa è la tecnica adottata: gli attaccanti non hanno modificato il codice sorgente del repository, bensì hanno riscritto ogni tag git esistente in ciascun repository per puntare a commit malevoli appartenenti a un fork controllato dagli aggressori. Questo approccio bypassa molti controlli di integrità tradizionali basati sull’analisi dei diff del codice principale.

GitHub consente ai tag di versione di puntare a commit di fork dello stesso repository. Gli attaccanti hanno sfruttato questa funzionalità per sostituire silenziosamente tutti i tag — compresi quelli di versioni storicamente sicure — con riferimenti a commit malevoli nel fork. Il risultato pratico è che anche un progetto che non aggiornava le dipendenze da mesi si ritrovava improvvisamente a scaricare codice ostile.

I ricercatori di Socket, Aikido Security, StepSecurity e Snyk hanno analizzato in dettaglio l’incidente, confermando che le versioni compromesse sono state pubblicate in rapida successione — alcune a pochi secondi di distanza l’una dall’altra — il 22 e il 23 maggio 2026, con oltre 700 versioni identificate tra i quattro pacchetti interessati. La velocità di pubblicazione indica quasi certamente un processo automatizzato.

I pacchetti compromessi


I quattro pacchetti colpiti sono componenti fondamentali dell’ecosistema di localizzazione per applicazioni Laravel:

  • laravel-lang/lang — le traduzioni principali per decine di lingue
  • laravel-lang/http-statuses — messaggi di stato HTTP localizzati
  • laravel-lang/attributes — traduzioni degli attributi dei form
  • laravel-lang/actions — azioni comuni localizzate

Si sospetta che gli attaccanti abbiano ottenuto accesso a credenziali a livello di organizzazione, a sistemi di automazione del repository o all’infrastruttura di rilascio del progetto. Packagist ha risposto tempestivamente rimuovendo le versioni malevole e mettendo temporaneamente in stato di “unlisted” i pacchetti interessati per prevenire ulteriori installazioni.

Il meccanismo di esecuzione automatica: autoloader Composer


La funzionalità malevola è contenuta in un file denominato src/helpers.php, incorporato nei tag di versione compromessi. Il file è registrato nel campo autoload.files del composer.json di ciascun pacchetto. Questa scelta tecnica è devastante: qualsiasi applicazione PHP che esegua require __DIR__.'/vendor/autoload.php' all’avvio — ovvero praticamente ogni applicazione Laravel, Symfony, PHPUnit o framework PHP moderno — esegue automaticamente il payload senza che sia necessaria alcuna chiamata di metodo esplicita.

“Il backdoor viene eseguito automaticamente ad ogni richiesta PHP gestita dall’applicazione compromessa”, ha spiegato Socket nella propria analisi. Lo script genera un identificatore univoco per host (un hash MD5 che combina il percorso della directory, l’architettura del sistema e l’inode) per garantire che il payload si attivi una sola volta per macchina, limitando le esecuzioni ridondanti e aiutando il malware a restare non rilevato dopo l’esecuzione iniziale.

Payload: uno stealer modulare con 15 collector specializzati


Il dropper contatta il server flipboxstudio[.]info per recuperare il payload principale: uno stealer PHP cross-platform da circa 5.900 righe di codice, organizzato in 15 moduli collector specializzati. Su Windows viene distribuito un launcher Visual Basic Script eseguito tramite cscript; su Linux e macOS il payload viene eseguito tramite exec().

L’elenco di ciò che lo stealer è in grado di raccogliere è impressionante per ampiezza e profondità:

  • Cloud provider: ruoli IAM AWS e documenti di identità dell’istanza, credenziali default di Google Cloud, token di accesso Microsoft Azure, profili service principal, token di account DigitalOcean, Heroku, Vercel, Netlify, Railway, Fly.io
  • Container e orchestrazione: token Service Account Kubernetes, configurazioni Helm registry, token HashiCorp Vault, auth token Docker, configurazioni cluster Kubernetes
  • CI/CD e DevOps: token e configurazioni di Jenkins, GitLab Runner, GitHub Actions, CircleCI, TravisCI, ArgoCD
  • Criptovalute: seed phrase e file di portafogli Electrum, Exodus, Atomic, Ledger Live, Trezor, Wasabi, Sparrow; dati di estensioni browser MetaMask, Phantom, Trust Wallet, Ronin, Keplr, Solflare, Rabby
  • Browser: cronologia, cookie e login data da Chrome, Edge, Firefox, Brave, Opera, usando un eseguibile Windows embedded in Base64 che bypassa Chromium’s App-Bound Encryption (ABE)
  • Password manager: vault locali e dati di estensioni 1Password, Bitwarden, LastPass, KeePass, Dashlane, NordPass
  • Comunicazioni e sessioni: token di Discord, Slack, Telegram; sessioni PuTTY/WinSCP, Windows Credential Manager, sessioni RDP
  • File sensibili: chiavi private SSH, credenziali Git, history di shell, file .env, wp-config.php, docker-compose.yml, variabili d’ambiente del processo PHP
  • Email e FTP: dati Outlook, Thunderbird, FileZilla, WinSCP, CoreFTP
  • VPN: configurazioni OpenVPN, WireGuard, NetworkManager, NordVPN, ExpressVPN, CyberGhost, Mullvad

Dopo aver raccolto tutto il materiale disponibile, il payload cripta i risultati con AES-256 e li trasmette all’endpoint flipboxstudio[.]info/exfil, dopodiché si cancella dal disco per limitare le tracce forensi.

IoC (Indicatori di Compromissione)

# Dominio C2 principale
flipboxstudio[.]info
flipboxstudio[.]info/exfil
# File malevolo nei pacchetti
src/helpers.php  (registrato in autoload.files di composer.json)
# Pacchetti PHP compromessi (verificare versioni 22-23 maggio 2026)
laravel-lang/lang
laravel-lang/http-statuses
laravel-lang/attributes
laravel-lang/actions
# Verifica presenza del file malevolo
find ./vendor -name "helpers.php" -path "*/laravel-lang/*" -exec grep -l "flipboxstudio" {} \;

Contesto: una campagna in crescita nell’ecosistema PHP


Questo attacco non è isolato. Negli ultimi mesi si è assistito a un’ondata di compromissioni delle supply chain nei principali registri di pacchetti. In particolare, la campagna Mini Shai-Hulud attribuita al gruppo TeamPCP (UNC6780) ha colpito pacchetti npm di TanStack, Mistral AI, Guardrails AI e OpenSearch, diffondendosi come un vero e proprio worm grazie all’abuso di token OIDC GitHub e al meccanismo di trusted publishing di npm. Il fatto che ora un attacco simile colpisca l’ecosistema PHP/Composer dimostra che i gruppi criminali stanno sistematicamente esplorando tutti i principali registri di pacchetti come vettori di attacco.

La tecnica di riscrivere i tag git invece di modificare il codice sorgente rappresenta un’evoluzione tattica significativa: bypassando i controlli diff tradizionali, rende molto più difficile il rilevamento automatico da parte degli strumenti di analisi della composizione software (SCA).

Due righe per i difensori


  • Verificare immediatamente se le applicazioni Laravel utilizzano uno dei quattro pacchetti compromessi e controllare le versioni installate durante il periodo 22-23 maggio 2026
  • Ruotare tutte le credenziali (AWS, GCP, Azure, GitHub, npm, CI/CD, database) su qualsiasi sistema che abbia eseguito codice con le versioni infette
  • Non revocare immediatamente i token sospetti prima di aver isolato e acquisito un’immagine forense del sistema: il malware include meccanismi di risposta alla revoca
  • Bloccare il dominio flipboxstudio[.]info a livello di firewall/DNS
  • Implementare controlli di integrità sui tag git (verificare le firme dei commit) e considerare il pinning degli hash SHA degli artefatti nel composer.lock
  • Adottare strumenti SCA capaci di rilevare tag git riscritti, non solo modifiche al codice sorgente
  • Aggiornare a versioni sicure dei pacchetti rilasciate dal team Laravel-Lang dopo la rimozione delle versioni malevole da Packagist


@Informatica (Italy e non Italy)
informatica ha ricondiviso questo.

friendica (DFRN) - Collegamento all'originale
The media in this post is not displayed to visitors. To view it, please log in.

Operazione Saffron: smantellata First VPN, il servizio criminale usato da 25 gang ransomware


@Informatica (Italy e non Italy)
Un'operazione internazionale coordinata da sette paesi ha sequestrato 33 server e chiuso First VPN, la VPN criminale attiva dal 2014 preferita da almeno 25 gruppi ransomware. Le autorità avevano accesso segreto ai sistemi prima del

(in)sicurezza digitale

2026-05-25 16:38:53

wordpress - Collegamento all'originale

Operazione Saffron: smantellata First VPN, il servizio criminale usato da 25 gang ransomware


Un’operazione internazionale coordinata da sette paesi ha smantellato First VPN, un servizio VPN criminale attivo dal 2014 che per oltre un decennio ha fornito anonimato e copertura a ransomware gang, operatori di botnet e criminali informatici di ogni tipo. L’Operazione Saffron — condotta tra il 19 e il 20 maggio 2026 da autorità francesi e olandesi con il supporto di Europol ed Eurojust — ha portato al sequestro di 33 server, alla chiusura di domini multipli e all’identificazione di migliaia di utenti criminali. Almeno 25 gruppi ransomware si erano affidati al servizio per nascondere le proprie attività.

Cos’era First VPN: un servizio progettato per il crimine


A differenza dei normali provider VPN commerciali, First VPN era stato strutturalmente concepito per rispondere alle esigenze operative dei criminali informatici. Il servizio operava server in 27 paesi, accettava pagamenti anonimi e metteva a disposizione un’infrastruttura deliberatamente opaca, pubblicizzando esplicitamente la propria offerta agli hacker attraverso forum del dark web.

Europol ha confermato che First VPN non si limitava a offrire connessioni anonime: forniva ai cybercriminali pagamenti anonimi, infrastruttura nascosta e una serie di servizi specificamente commercializzati per chi voleva condurre attività illegali. L’FBI ha dichiarato che almeno 25 gang ransomware si servivano del servizio per mascherare il traffico malevolo, condurre ricognizioni sulle reti delle vittime, operare botnet, lanciare attacchi DDoS ed eseguire frodi su larga scala.

La durata operativa del servizio — dodici anni, dal 2014 al 2026 — rende First VPN uno dei provider criminali più longevi mai smantellati. Nel corso di questi anni il servizio ha rappresentato un elemento dell’infrastruttura criminale digitale quasi quanto certi servizi bullet-proof hosting che proteggono server di command-and-control.

Operazione Saffron: anatomia del takedown


L’Operazione Saffron è stata guidata dalle autorità di Francia e Paesi Bassi, con la partecipazione di cinque ulteriori paesi. Europol ed Eurojust hanno svolto un ruolo di coordinamento, mentre Bitdefender è stato tra i partner privati che hanno contribuito all’operazione con intelligence tecnica.

Il bilancio dell’operazione è significativo:

  • 33 server sequestrati in tutta l’infrastruttura del servizio
  • Chiusura di tutti i domini associati a First VPN
  • Identificazione di migliaia di utenti criminali — le autorità hanno ottenuto accesso ai log e ai dati del provider
  • 83 pacchetti di intelligence su 506 utenti condivisi con i paesi partner per follow-up investigativi
  • Interrogatorio dell’operatore in Ucraina da parte di autorità francesi e olandesi

Un dato particolarmente rilevante: le autorità avevano accesso segreto ai sistemi di First VPN prima del takedown, raccogliendo intelligence sugli utenti e le loro attività. Come in precedenti operazioni simili (VPNLab, Fbi’s Anom), il monitoraggio anticipato ha permesso di costruire casi investigativi solidi contro i clienti del servizio.

Chi utilizzava First VPN: 25 gang ransomware e un ecosistema criminale variegato


Secondo l’FBI, First VPN era un punto di convergenza per una molteplicità di attori criminali. Le 25 gang ransomware che lo utilizzavano lo impiegavano principalmente per:

  • Mascherare l’identità degli operatori durante la fase di ricognizione e compromissione iniziale delle reti
  • Gestire i pannelli di command-and-control dei loro malware senza esporre infrastrutture proprie
  • Condurre negoziazioni con le vittime attraverso connessioni anonimizzate
  • Eseguire exfiltrazione di dati verso server di staging

Oltre al ransomware, il servizio veniva impiegato per la gestione di botnet, attacchi DDoS-as-a-service, frodi finanziarie e altre forme di cybercrime. La natura “crime-as-a-service” dell’offerta di First VPN riflette la professionalizzazione crescente dell’ecosistema criminale informatico, dove le diverse componenti delle operazioni illecite — exploit kit, accesso iniziale, VPN anonime, criptazione, estorsione — vengono acquistate come servizi separati su mercati specializzati.

Il contesto: la guerra delle autorità contro l’infrastruttura criminale


Il takedown di First VPN si inserisce in una sequenza di operazioni di law enforcement che negli ultimi anni ha progressivamente eroso l’infrastruttura tecnologica del cybercrimine organizzato. Tra le operazioni più significative degli ultimi 24 mesi si ricordano: il takedown di LockBit (febbraio 2024), l’operazione contro ALPHV/BlackCat (dicembre 2023), il sequestro di BreachForums (maggio 2024) e, più recentemente, l’arresto di Jacob Butler, il 23enne canadese alias “Dort” accusato di aver operato la botnet KimWolf — responsabile di attacchi DDoS da record a quasi 30 terabit al secondo, che hanno infettato quasi 2 milioni di dispositivi tra telecamere di sorveglianza e cornici digitali connesse a internet.

Ciò che emerge da questa serie di operazioni è una strategia deliberata da parte delle autorità: colpire non solo i singoli criminali, ma l’infrastruttura condivisa che permette a decine di gruppi diversi di operare. Sequestri di VPN criminali, hosting bullet-proof, servizi di riciclaggio crypto e forum di coordinamento costano al cybercrimine non solo singoli attori ma intere reti di supporto operative.

Le implicazioni investigative: i log di First VPN


Il punto più interessante — e preoccupante per chi ha usato il servizio — è la questione dei log. First VPN sosteneva, come quasi tutti i provider VPN nel mercato criminale, di non conservare log delle attività degli utenti. Le operazioni precedenti (VPNLab, IVPN, DoubleVPN) hanno dimostrato che queste affermazioni sono spesso false o parzialmente vere. In questo caso, la conferma che le autorità hanno ottenuto accesso anticipato ai sistemi e hanno costruito 83 pacchetti di intelligence su 506 utenti specifici suggerisce fortemente che dati sufficienti per l’identificazione erano disponibili.

Per le organizzazioni di sicurezza che seguono gruppi ransomware attivi, questo takedown ha una conseguenza pratica immediata: tutti i gruppi che utilizzavano First VPN dovranno migrare verso infrastrutture alternative, il che storicamente causa disruption operativa misurabile nelle campagne ransomware nelle settimane successive a simili operazioni.

Consigli per i difensori


  • Monitorare i log di rete per connessioni in entrata o in uscita verso i range IP precedentemente associati all’infrastruttura di First VPN (le ION saranno condivise dai partner istituzionali nelle prossime settimane)
  • Aspettarsi un picco di attività ransomware nelle prossime 2-4 settimane: i gruppi che perdono infrastrutture di supporto tendono ad accelerare le campagne attive prima di riorganizzarsi
  • Aggiornare le TTP di threat modeling per i gruppi ransomware di riferimento: cambieranno IP, provider VPN e infrastruttura C2 in risposta all’operazione
  • Condividere intelligence con i centri nazionali (in Italia, ACN) per contribuire alla costruzione dei pacchetti investigativi di follow-up sui 506 utenti identificati


@Informatica (Italy e non Italy)
informatica ha ricondiviso questo.

friendica (DFRN) - Collegamento all'originale

DBIR 2026, il ritorno ai fondamentali nella cyber: le 5 azioni strutturali da mettere in campo


@Informatica (Italy e non Italy)
Una prospettiva empirica che va un po' controcorrente rispetto ai soliti toni allarmistici. Ecco i dati e i consigli che emergono del report DBIR 2026 di Verizon
L'articolo DBIR 2026, il ritorno ai fondamentali nella

@Informatica (Italy e non Italy)
informatica ha ricondiviso questo.

friendica (DFRN) - Collegamento all'originale

Magnifica Humanitas, Papa Leone XIV lancia un appello per disarmare l’intelligenza artificiale

Per vedere altri post come questo, segui la comunità @Informatica (Italy e non Italy)

Con la sua prima enciclica, "Magnifica Humanitas", Papa Leone XIV ha delineato il suo desiderio di proteggere la dignità e la capacità di agire dell'uomo nell'era

@Informatica (Italy e non Italy)
informatica ha ricondiviso questo.

friendica (DFRN) - Collegamento all'originale

Il Trump Mobile parte male: data breach e appena 30mila ordini


@Informatica (Italy e non Italy)
Il provider telefonico e produttore dellosmartphone a marchio Trump ha confermato l’esposizione online di dati personali dei propri clienti: nomi, indirizzi email, indirizzi postali, numeri di cellulare e identificativi degli ordini erano accessibili sul web. Chris Walker, portavoce della

@Informatica (Italy e non Italy)
informatica ha ricondiviso questo.

friendica (DFRN) - Collegamento all'originale

La battaglia epica tra Epic e Apple finirà alla Corte Suprema

Per vedere altri post come questo, segui la comunità @Informatica (Italy e non Italy)

Nonostante il ritorno di Fortnite sull'App Store di Apple, Epic Games starebbe festeggiando prematuramente: Cupertino intende infatti startmag.it/innovazione/la-bat…

@Informatica (Italy e non Italy)
informatica ha ricondiviso questo.

friendica (DFRN) - Collegamento all'originale

Perché l’acquisizione di Activision da parte di Microsoft ha fatto trasalire un fondo pensione

Per vedere altri post come questo, segui la comunità @Informatica (Italy e non Italy)

Si risolverà con un risarcimento da 250 milioni di dollari la causa intentata dal fondo pensione svedese Sjunde AP-Fonden che aveva accusato gli ex dirigenti di Activision

@Informatica (Italy e non Italy)
informatica ha ricondiviso questo.

friendica (DFRN) - Collegamento all'originale

Quacivi a capo dell’Acn: perché è svolta per la cyber italiana


@Informatica (Italy e non Italy)
L’arrivo di Andrea Quacivi alla guida dell’ACN coincide con un momento delicato per la NIS2, con ’aumento degli attacchi ransomware e della pressione sulla supply chain software. La governance cyber italiana continua a oscillare tra logiche amministrative e

@Informatica (Italy e non Italy)
informatica ha ricondiviso questo.

friendica (DFRN) - Collegamento all'originale

Meta continua a licenziare per fare posto all’AI

Per vedere altri post come questo, segui la comunità @Informatica (Italy e non Italy)

Con una fredda mail arrivata all'alba il founder di Meta Mark Zuckerberg lascia a casa 8mila dipendenti, una trentina pure in Italia, e spiega che l'azienda deve correre sull'Ai. Nelhttps://www.startmag.it/innovazione/meta-continua-a-licenziare-per-fare-posto-allai/

@Informatica (Italy e non Italy)
informatica ha ricondiviso questo.

glitchsoc - Collegamento all'originale
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

Spcnet.it

2026-05-24 18:16:49

wordpress - Collegamento all'originale

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


Retirement of Direct Exchange ActiveSync Certificate-Based Authentication by End of 2026 | Microsoft Community Hub

We are announcing the deprecation of Exchange ActiveSync (EAS) certificate-based authentication (CBA) directly to Exchange Online.  
The_Exchange_Team (TECHCOMMUNITY.MICROSOFT.COM)

#tech @Informatica (Italy e non Italy)
informatica ha ricondiviso questo.

glitchsoc - Collegamento all'originale
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

Spcnet.it

2026-05-24 18:17:13

wordpress - Collegamento all'originale

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 non open source rilasciato con licenza FSL con disponibilità del codice sorgente, 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


Liquibase: Database Change Management + Automated Deployment

Liquibase automates schema versioning and deployment via changelogs, enabling version-controlled, rollback-ready migrations with tracking for DevOps pipelines.
Suman Basak (dzone.com)

#tech @Informatica (Italy e non Italy)
informatica ha ricondiviso questo.

friendica (DFRN) - Collegamento all'originale
The media in this post is not displayed to visitors. To view it, please log in.

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


@Informatica (Italy e non Italy)
In sei ore il 18 maggio 2026, la campagna automatizzata Megalodon ha iniettato 5.718 commit malevoli in 5.561 repository GitHub, esfiltrandone credenziali cloud, chiavi SSH e segreti CI/CD verso un C2 esterno. L'operazione, collegata al gruppo

(in)sicurezza digitale

2026-05-24 18:15:13

wordpress - Link to source

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.


@Informatica (Italy e non Italy)
informatica ha ricondiviso questo.

mastodon - Collegamento all'originale

#europa accelera sulla sovranità #IA, cercando un equilibrio tra etica e competitività contro #USA e #Cina. In #Germania nasce l’alleanza tra #Thales e #Google #Cloud per proteggere dati pubblici e infrastrutture critiche con un cloud sovrano europeo. Sul fronte dei pagamenti, l’#euro digitale punta a ridurre la dipendenza da #Visa e #Mastercard, mentre Linus #Torvalds accusa la #AI di rallentare #Linux con bug report automatici inutili.

@informatica

bit.ly/4wNvugg

🚀 Da zero a digital » Newsletter n° 152

Il tuo aggiornamento digitale: gratuito, indipendente, senza pubblicità. La tecnologia spiegata senza filtri, solo per te.
Open Genova APS (Da zero a digital)
#ai #USA #Google #Europa #Cina #linux #IA #torvalds #cloud #ViSA #germania #euro #MasterCard #Thales @Informatica (Italy e non Italy)
informatica ha ricondiviso questo.

friendica (DFRN) - Collegamento all'originale
The media in this post is not displayed to visitors. To view it, please log in.

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


@Informatica (Italy e non Italy)
Webworm, APT di allineamento cinese attivo dal 2022, ha aggiornato il suo arsenale con due nuovi backdoor: EchoCreep, che usa Discord come canale C2, e GraphWorm, che sfrutta Microsoft Graph API e OneDrive per

(in)sicurezza digitale

2026-05-23 20:58:09

wordpress - Link to source

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.


@Informatica (Italy e non Italy)
informatica ha ricondiviso questo.

friendica (DFRN) - Collegamento all'originale

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


@Informatica (Italy e non Italy)
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

(in)sicurezza digitale

2026-05-23 17:51:48

wordpress - Collegamento all'originale

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.


Account WhatsApp compromessi su iPhone con iOS 16: l’attacco 0click che bypassa i dispositivi collegati - Forenser Srl

Un weekend tranquillo, di fine maggio: il tempo passa senza problemi fino a quando non iniziano ad arrivare messaggi ambigui sull’applicazione di WhatsApp
forenser (Forenser Srl)

@Informatica (Italy e non Italy)
informatica ha ricondiviso questo.

glitchsoc - Collegamento all'originale
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

Spcnet.it

2026-05-23 16:42:25

wordpress - Collegamento all'originale

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.


Simplified access to Hotpatching enabled by Azure Arc for Windows Server 2025 | Microsoft Community Hub

With Windows Server 2025, we introduced hotpatch enabled by Azure Arc, delivering security updates to Windows Server across hybrid and multicloud...
sharmajyoti (TECHCOMMUNITY.MICROSOFT.COM)

#tech @Informatica (Italy e non Italy)
informatica ha ricondiviso questo.

mastodon - Collegamento all'originale

Il Texas fa causa a Meta e WhatsApp per presunte violazioni della privacy legate alla crittografia

L'ufficio del procuratore generale del Texas ha intentato causa giovedì contro WhatsApp e la sua società madre Meta, apre una nuova schedaL'accusa è stata di aver tratto in inganno i consumatori circa la robustezza e la portata delle misure di crittografia di WhatsApp, accusa che un portavoce di Meta ha respinto

reuters.com/legal/government/t…

@informatica

Grazie a Marco per la segnalazione

@Informatica (Italy e non Italy)
informatica ha ricondiviso questo.

friendica (DFRN) - Collegamento all'originale

Il Papa, Anthropic e la tenaglia Usa-Cina sul Vaticano

Per vedere altri post come questo, segui la comunità @Informatica (Italy e non Italy)

Leone XIV ha scelto il suo alleato tecnologico tra i nemici della Casa Bianca? L'intervento di Luigi Ricci, autore di Vaticano Zero Day

startmag.it/innovazione/il-pap…

@Informatica (Italy e non Italy)
in reply to Informa Pirata

mastodon - Collegamento all'originale

Piero Bosio

Le chiavi del regno dei cieli, chiavi di login e di criptazione/decriptazione, per legare (criptare) e scioglire (decriptare) in terra come nei cieli, arriveranno in futuro con l'analisi cognitiva nel dominio dello spirito. Tuttavia l'Informatica, così come l'IA sono discipline che riguardano la mistica booleana della Matematica, una mistica che non sta né in cielo né in terra.
informatica ha ricondiviso questo.

friendica (DFRN) - Collegamento all'originale
The media in this post is not displayed to visitors. To view it, please log in.

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


@Informatica (Italy e non Italy)
Lumen Technologies Black Lotus Labs ha identificato due nuovi impianti malevoli, Showboat per Linux e JFMBackdoor per Windows, utilizzati dal gruppo APT cinese Calypso (Red

(in)sicurezza digitale

2026-05-23 06:55:44

wordpress - Link to source

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.”


@Informatica (Italy e non Italy)
informatica ha ricondiviso questo.

friendica (DFRN) - Collegamento all'originale

Chi è Andrea Quacivi, il nuovo capo dell’Agenzia per la cybersicurezza al posto di Frattasi


@Informatica (Italy e non Italy)
Tutto sul manager Andrea Quacivi, nuovo direttore generale dell'Agenzia per la cybersicurezza nazionale (Acn) che prende il posto del prefetto Bruno Frattasi. Fatti e approfondimenti sulle ragioni del ribaltone ai vertici

@Informatica (Italy e non Italy)
informatica ha ricondiviso questo.

glitchsoc - Collegamento all'originale
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

Spcnet.it

2026-05-23 06:08:01

wordpress - Collegamento all'originale

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


Supported software platforms

Find the products and versions that are compatible with each of the MIM 2016 components
learn.microsoft.com

#tech @Informatica (Italy e non Italy)
informatica ha ricondiviso questo.

friendica (DFRN) - Collegamento all'originale

Effetto data center per le tariffe elettriche negli Usa. Report Nyt

Per vedere altri post come questo, segui la comunità @Informatica (Italy e non Italy)

Gli americani stanno pagando molto di più per l'elettricità e i data center richiedono molta più energia alle compagnie startmag.it/innovazione/effett…

@Informatica (Italy e non Italy)
informatica ha ricondiviso questo.

friendica - Collegamento all'originale
The media in this post is not displayed to visitors. To view it, please go to the original post.

Il livello degli stipendi degli sviluppatori in Romania è evidentemente più alto di quello che c'è in Italia

apply.workable.com/modash/j/C1…

@Informatica (Italy e non Italy)

Senior Product Engineer (remote position in the EU) - Modash

The world doesn’t need giant media organizations to tell every story. The world needs millions of creators. Independent voices who bring weird, wonderful stories to life online.We’re working to help every creator earn a living.
apply.workable.com
@Informatica (Italy e non Italy)
informatica ha ricondiviso questo.

friendica (DFRN) - Collegamento all'originale

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


@Informatica (Italy e non Italy)
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

(in)sicurezza digitale

2026-05-22 20:24:33

wordpress - Collegamento all'originale

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.


@Informatica (Italy e non Italy)
informatica ha ricondiviso questo.

mastodon - Collegamento all'originale

I parlamentari USA chiedono spiegazioni mentre la CISA tenta di contenere la fuga di dati

I parlamentari di entrambe le camere del Congresso stanno chiedendo spiegazioni alla CISA ( Agenzia statunitense per la sicurezza informatica e delle infrastrutture ) dopo che KrebsOnSecurity ha riportato questa settimana che un collaboratore esterno della CISA ha intenzionalmente pubblicato le chiavi AWS GovCloud e una vasta quantità di altri segreti dell'agenzia su un account pubblico di GitHub . L'indagine giunge mentre la CISA sta ancora lottando per contenere la violazione e invalidare le credenziali trapelate.

krebsonsecurity.com/2026/05/la…

@informatica

Lawmakers Demand Answers as CISA Tries to Contain Data Leak

Lawmakers in both houses of Congress are demanding answers from the U.S. Cybersecurity & Infrastructure Security Agency (CISA) after KrebsOnSecurity reported this week that a CISA contractor intentionally published AWS GovCloud keys and a vast trove …
krebsonsecurity.com
@Informatica (Italy e non Italy)
informatica ha ricondiviso questo.

mastodon - Collegamento all'originale

Trump Mobile conferma di aver esposto i dati personali dei clienti, inclusi numeri di telefono e indirizzi di casa 🤡🤡🤡

Il fornitore di servizi telefonici Trump Mobile ha confermato di aver esposto su internet i nomi, gli indirizzi email, gli indirizzi postali, i numeri di cellulare e gli identificativi degli ordini dei propri clienti.

techcrunch.com/2026/05/22/trum…

@informatica

Trump Mobile confirms it exposed customers' personal data, including phone numbers and home addresses | TechCrunch

President Trump’s branded cell phone maker and cell provider said the exposure was linked to a third-party platform, and was evaluating whether it needs to notify customers.
Lorenzo Franceschi-Bicchierai (TechCrunch)
@Informatica (Italy e non Italy)
informatica ha ricondiviso questo.

glitchsoc - Collegamento all'originale
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

Spcnet.it

2026-05-22 12:57:36

wordpress - Collegamento all'originale

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


From open source to agentic systems: Microsoft at Open Source Summit North America 2026 | Microsoft Open Source Blog

Discover how Azure Linux 4.0 and Azure Container Linux deliver a secure, scalable Linux foundation for cloud native apps, containers, and AI workloads.
Brendan Burns (Microsoft Open Source Blog)

#tech @Informatica (Italy e non Italy)
informatica ha ricondiviso questo.

glitchsoc - Collegamento all'originale
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

Spcnet.it

2026-05-22 12:59:17

wordpress - Collegamento all'originale

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.


Linux Log Files: Guide to Reading, Searching, and Managing Logs | LinuxBlog.io

A practical guide to Linux log files: where they live, how to read and search them with tail, grep, and journalctl, how to manage log rotation, and a real-world troubleshooting workflow.
Hayden James (LinuxBlog.io)

#tech @Informatica (Italy e non Italy)
informatica ha ricondiviso questo.

mastodon - Collegamento all'originale
The media in this post is not displayed to visitors. To view it, please go to the original post.

Dal 1° giugno 2026, GitHub Copilot passa dal modello a "richieste premium" a un sistema basato su crediti di utilizzo.
Ho fatto una simulazione con il mio utilizzo molto leggero e il risultato è chiaro: costi raddoppiati (10$/mese -> 20$/mese).
Per chi usa Copilot più intensivamente, si profilano vere e proprie impennate.

Suggerimento: Monitorate attentamente l'utilizzo nei prossimi mesi e valutate se il nuovo modello vi conviene realmente.

@informatica #GitHubCopilot

#githubcopilot @Informatica (Italy e non Italy)
⇧