Read Time:3 Minute, 23 Second

Two major South Korean churches have suffered extensive intrusions that exposed records associated with more than one million congregants, along with donation, payroll, employee and administrative information. The attacks followed different entry paths but converged on a common weakness: loosely controlled connections between public-facing applications, databases, internal services and cloud storage.

OASIS researchers reconstructed the activity from tools, stolen files and operator reports recovered from an attacker-controlled server. Their findings point to multi-stage intrusions involving application compromise, credential recovery, lateral movement and off-site staging rather than a single malware family. Because datasets can overlap, the precise number of unique people affected has not been independently confirmed.

A web shell opened the first environmentAt the first church, attackers gained a foothold through a web shell placed in an enterprise resource planning system. They reverse engineered ERP application components, decrypted database settings and obtained administrator access to Microsoft SQL Server. The attackers then used the database server’s xp_cmdshell capability to execute operating-system commands and move into linked systems.

From there, access expanded into membership, accounting, physical-access, library, chat and mail databases. The operators bypassed a database-monitoring control, recovered a MariaDB root password and found hardcoded network-attached storage credentials in backup-related configuration. The chain shows how one exposed application can become a bridge to several otherwise separate repositories.

The recovered collection contained approximately 960,000 congregant records updated during the previous two years, including names and South Korean resident registration numbers. It also included about 330,000 donation entries, 68,000 document-creation records, more than 14,000 chat messages and 6,874 login accounts. Investigators identified 47.3 GB across 13,939 files in a compromised MinIO bucket used for staging.

Leaked credentials and IDOR drove the second attackThe second church was reached through previously leaked credentials and authorization weaknesses in groupware and membership services. Insecure direct object reference flaws occur when an application accepts a record identifier supplied by a user but does not confirm that the user is permitted to view or change that record.

Using a valid member session, the attackers could access other users’ plaintext PINs and reset an account with manager-level privileges. They obtained roughly 89,000 congregant records, 383 employee records, 286 human-resources entries, 96 employee photographs and internal approval documents. Researchers also found exposed college-ministry APIs and cloud storage that allowed unrestricted reading and writing.

These details underline why valid credentials cannot substitute for authorization. Every request for a record must be checked against the current user’s privileges, even after authentication succeeds. Password-reset functions require especially strong safeguards because they can turn limited access into account takeover.

Connected systems multiplied the damageIn the first environment, the attack progressed from an internet-facing ERP component to database administration, operating-system execution, backup storage and cloud staging. In the second, a combination of exposed credentials and missing object-level checks crossed groupware, membership, SAP and storage services. Hardcoded secrets and excessive service privileges allowed the operators to keep moving after the initial compromise.

Religious and community organizations can hold a uniquely sensitive mix of identity, family, donation and communication data. Criminals could use that material for identity fraud, tailored phishing, extortion or scams that exploit trust within a congregation.

Containment and prevention stepsRemove unauthorized web shells and preserve forensic copies before rebuilding affected application servers.

Rotate database, NAS, cloud and application credentials; revoke tokens and invalidate active sessions.

Disable xp_cmdshell where it is not operationally necessary and constrain linked-server privileges.

Review ERP, SQL Server, NAS and cloud logs for unusual exports, bulk downloads and unexpected external connections.

Test every sensitive API for object-level authorization and strengthen privileged password-reset workflows.

Eliminate secrets from source code, configuration backups and publicly reachable storage.

Organizations should also alert affected people with clear guidance about targeted fraud and credential reuse. The broader lesson is architectural: segmentation, least privilege and enforced authorization can stop an initial application breach from becoming an organization-wide data loss event.

Read Time:3 Minute, 30 Second

Double Counter, the company behind a widely used Discord moderation and anti-spam bot, has disclosed a breach that exposed records on tens of millions of accounts after an intruder found a way into its cloud infrastructure on October 4, 2026. The company says Discord’s own systems were never touched — the compromise was entirely on Double Counter’s side — but the scale of exposed data and the attacker’s ability to briefly impersonate the bot itself make this a notable supply-chain-style incident for anyone running third-party bots in their servers.

An Old Server Became the Doorway InAccording to Double Counter’s account, the intrusion didn’t start with a clever new exploit. It started with a forgotten one: an old server hosted at OVH, left over from a previous hosting arrangement, was still running a publicly reachable instance of the analytics tool Metabase. A flaw in how that instance handled sessions let the attacker forge administrator access and reach credentials stored on that same host — including a cloud admin service-account key and a saved administrative command-line session. Double Counter has not tied the incident to a specific published CVE, so the exact root cause within Metabase remains unconfirmed.

Because the attacker used those stolen, legitimate credentials rather than creating new accounts, the activity blended in with normal administrative traffic for longer than a brand-new login would have. Once inside, the intruder added their own SSH key, exported a database copy to a cloud storage bucket, and opened a shell inside one of the bot’s running containers — a move that exposed the live Discord bot token itself.

A Few Hours of Chaos on the Support ServerWith the token in hand, the attacker used the bot’s own identity to grant themselves administrator rights on Double Counter’s official support server, reverse a staff member’s ban, and send unsolicited invitations to roughly 50 large Discord communities. Double Counter’s incident response team tried to cut the attacker off by revoking the token and issuing a replacement — but the intruder read the new token within minutes, apparently because the deeper service-account compromise was still active. A second attempt to revoke the service-account key also failed, since the attacker had already pivoted to the stolen administrative session. Access was only fully terminated later that day once every related session was revoked at once.

What Was Actually ExposedDouble Counter’s own disclosure lists the exposed data in granular terms: roughly 28 million Discord user IDs and usernames, about 27 million IP address and approximate location records, user-agent hashes tied to roughly 25 million accounts, and around one million unique email addresses — with heavy overlap between these groups rather than 81 million distinct people. Have I Been Pwned has already indexed roughly 275,000 unique emails from data that circulated publicly. The company states that Discord account passwords and payment card numbers were not exposed, and that cold-storage records covering a further 58 million users were untouched. Separately, a stolen Stripe API key tied to the breach was used to charge about $7,316 fraudulently against an unrelated company account; two legitimate customer charges were refunded.

Cleanup and the Bigger LessonIn its remediation, Double Counter says it decommissioned the old OVH server entirely, revoked all cloud access, rotated every credential involved, deleted webhooks the attacker could have planted, and moved its databases behind private networking rather than public endpoints. The bot’s authentication token now lives in dedicated secrets storage with logging on every access attempt, alongside new continuous monitoring.

For Discord server administrators, the practical takeaway isn’t really about Double Counter specifically — it’s about the dozens of third-party bots most communities run without a clear view of how those vendors secure their own backends. A bot’s permissions inside your server are only as trustworthy as the infrastructure behind it, and this incident shows how a single forgotten analytics server, left running years after its intended purpose ended, can cascade into tens of millions of exposed records and a hijacked support channel. Server owners relying on third-party bots should periodically review what permissions those integrations hold and watch for official breach disclosures from the vendors behind them.

Si parla di:

Toggle

Per anni il dibattito sull’uso offensivo dell’intelligenza artificiale nel #cybercrime è rimasto nel campo della prospettiva: scenari plausibili, proof-of-concept accademici, allarmi di settore. Il 7 ottobre 2026 la Corea del Sud potrebbe aver fornito il primo caso concreto e documentato di un agente AI utilizzato per violare il settore finanziario. Sette istituti bancari e finanziari sudcoreani, tra cui Shinhan Bank, KB Kookmin e Hana Bank, hanno subito intrusioni che gli investigatori della polizia e della Financial #Security Institute collegano a ARTEX, un tool open source di penetration test basato su agenti AI sviluppato in #Cina.

Sette istituti, decine di migliaia di clienti espostiIl quadro che emerge dalla stampa sudcoreana, #Korea JoongAng Daily, Korea Herald, SBS News e Korea Times, è quello di una campagna diffusa ma disomogenea, con tempi di rilevamento molto diversi da istituto a istituto:

Shinhan Bank: 25.727 clienti coinvolti, rilevata dopo circa 15 ore e 26 minuti dalla compromissione.

KB Kookmin Bank: 119 clienti, rilevamento dopo 67 ore e 41 minuti.

Hana Bank: 89 clienti, rilevamento dopo 41 ore e 44 minuti.

BNK Busan Bank: dati di 11 sviluppatori esterni in outsourcing.

Yegaram Savings Bank: circa 40.000 clienti coinvolti.

Welcome Savings Bank: circa 2.200 schede di clientela aziendale.

#Hyundai Capital: dati personali di agenti di prestito ipotecario.

Le stime complessive diffuse dai media locali oscillano tra 65.000 e 68.000 persone coinvolte, una forbice spiegabile con criteri di conteggio e finestre temporali diverse tra le fonti. I dati sottratti includono nominativi, recapiti, numeri di identificazione residenziale coreani, ID cliente, dettagli di richieste di prestito, limiti di credito calcolati e codici di decisione finale, tassi di interesse di mercato applicati, reddito annuo dichiarato, limiti di prestito personale e, per i #conti aziendali, ragione sociale e referenti.

La prova fumante: una stringa in cinese nei log dei server compromessiA collegare le intrusioni ad ARTEX non è stata una firma di #malware, ma un artefatto lasciato, apparentemente per distrazione operativa, sui server web compromessi: la stringa ARTEX-自主渗透試控制台, traducibile come “console di controllo per penetration test autonomo ARTEX”. Il Financial Security Institute ha condotto l’analisi forense di IP e log direttamente su Shinhan Bank, confermando la presenza di questo artefatto e tracciando l’infrastruttura usata per l’attacco: oltre venti indirizzi IP distribuiti su circa una dozzina di paesi, tra cui Stati Uniti, Giappone e Germania, utilizzati come catena di proxy prima di colpire i target coreani, uno schema di offuscamento ormai standard nelle intrusioni di matrice statale o paraorganizzata, qui applicato con l’aiuto di un orchestratore AI.

ARTEX, secondo la ricostruzione di SBS News, è un agente open source che orchestra più modelli linguistici di grandi dimensioni, tra cui Claude, GPT e DeepSeek, in un’unica pipeline autonoma capace di condurre attività di vulnerability assessment e, potenzialmente, di sfruttamento. Lo strumento sarebbe opera di uno sviluppatore cinese identificato nei report come Li Fuhua. Va sottolineato che l’origine open source dello strumento non implica automaticamente l’identità degli operatori dietro le intrusioni: a oggi nessuna autorità sudcoreana ha attribuito pubblicamente l’attacco a un gruppo o a uno stato specifico. Ciò che è stato accertato è l’impronta dello strumento, non la mano che lo ha impugnato.

Dall’exploit manuale all’orchestrazione autonomaIl presidente della Financial Services Commission, Lee Eog-weon, ha dichiarato che “non si può escludere che l’intelligenza artificiale sia stata utilizzata negli attacchi”, una formulazione volutamente cauta ma significativa da parte del massimo regolatore finanziario del paese. Il presidente Lee Jae-myung ha disposto un irrigidimento immediato delle misure di sicurezza nel settore, sottolineando che “la velocità è essenziale”, un’affermazione che suona quasi ironica se si considera che proprio la velocità di esecuzione è il vantaggio competitivo che un agente AI offre rispetto a un operatore umano nella fase di ricognizione e sfruttamento delle vulnerabilità.

Le cause profonde individuate dagli inquirenti non sono esotiche: autenticazione debole e conservazione eccessiva di dati nei sistemi di richiesta prestiti e di supporto ai dipendenti, gli stessi punti deboli che qualunque penetration test tradizionale avrebbe potuto individuare. La differenza, se la pista ARTEX verrà confermata, sta nella scala e nella velocità con cui un agente AI è in grado di mappare automaticamente queste debolezze su decine di sistemi esposti, candidandosi a essere ricordato come il primo caso pubblicamente documentato di hacking “agentico” contro il settore finanziario.

La risposta: controlli d’emergenza su 500 istitutiLa Financial Supervisory Service ha diramato un alert agli indirizzi IP malevoli individuati a circa 500 istituti finanziari sudcoreani, imponendo controlli di sicurezza d’emergenza con scadenze molto strette, entro il giovedì successivo alla scoperta. L’indagine penale è condotta dalla Cyber Terror Investigation Unit della Polizia Nazionale coreana in collaborazione con il Financial Security Institute, mentre la FSS coordina la risposta regolatoria settoriale. Al momento nessuna delle due agenzie ha pubblicato un report tecnico completo con indicatori di compromissione dettagliati, comprensibile, trattandosi di un’indagine ancora in corso, ma la granularità con cui la stampa coreana ha ricostruito banca per banca tempi di rilevamento e volumi di dati esposti è insolitamente alta per un incidente di appena pochi giorni.

Cosa fare, in attesa di confermePer i team di sicurezza, in particolare nel settore finanziario, l’episodio sudcoreano è un campanello d’allarme operativo più che tecnico in senso stretto:

Rivedere l’autenticazione e il controllo degli accessi sui sistemi di back-office esposti a terze parti (richiesta prestiti, supporto dipendenti, portali per sviluppatori esterni), spesso meno presidiati dei canali rivolti al cliente.

Applicare principi di minimizzazione dei dati: la conservazione prolungata di informazioni di credito, reddito e identificazione personale amplifica l’impatto di ogni singola violazione.

Monitorare pattern di scansione e sfruttamento ad alta velocità e alta copertura, tipici di un’orchestrazione automatizzata, distinti dai pattern più lenti e mirati di un operatore umano.

Considerare l’esistenza di strumenti open source di penetration test “agentici” come un dato di fatto del panorama delle minacce 2026, non come un’ipotesi futuribile: se uno sviluppatore indipendente ha potuto costruire ARTEX, repliche o varianti sono solo questione di tempo.

Tracciare catene di proxy multi-paese come parte ordinaria della due diligence su traffico anomalo in ingresso, dato il pattern di offuscamento osservato (oltre 20 IP in una dozzina di paesi).

Resta una domanda aperta, e probabilmente lo resterà per settimane: quanta della violazione è davvero opera autonoma di un agente AI, e quanta invece riflette un operatore umano che ha semplicemente usato ARTEX come acceleratore di un attacco comunque pianificato e diretto da persone? La distinzione non è accademica, cambia radicalmente le implicazioni per la difesa, ma al momento le fonti disponibili non permettono di scioglierla con certezza. Quello che è già chiaro è che il settore finanziario sudcoreano ha dovuto affrontare, in presa diretta, uno scenario di cui fino a poche settimane fa si discuteva solo in convegni e report previsionali.

Indicatori e riferimenti# Artefatto identificativo rinvenuto sui server compromessi
ARTEX-自主渗透試控制台 ("console di controllo per penetration test autonomo ARTEX")

Infrastruttura

• oltre 20 indirizzi IP come catena di proxy
• distribuiti su circa 12 paesi (inclusi USA, Giappone, Germania)

Istituti coinvolti (clienti/record esposti)

Shinhan Bank - 25.727 (rilevamento: 15h26m)
KB Kookmin Bank - 119 (rilevamento: 67h41m)
Hana Bank - 89 (rilevamento: 41h44m)
BNK Busan Bank - 11 sviluppatori esterni
Yegaram Savings Bank - ~40.000
Welcome Savings Bank - ~2.200 record aziendali
Hyundai Capital - dati agenti mutuo

Enti coinvolti nelle indagini

• Cyber Terror Investigation Unit, Korean National Police Agency
• Financial Security Institute
• Financial Supervisory Service (FSS)Fonti: Korea JoongAng Daily; SBS News (edizione inglese); Korea Herald; Korea Times; Seoul Economic Daily; Herald Business.

Read Time:4 Minute, 1 Second

Shoppers who use the ASOS mobile app got an unwelcome surprise on the morning of October 6, 2026, when a push notification appeared on their phones under the blunt heading “ASOS HACKED.” The message was not from ASOS marketing — it was planted by an attacker who had found a way into the retailer’s customer-messaging infrastructure, and it set off a scramble inside the company to figure out exactly what had actually been touched.

A Notification Channel Turned Into a MegaphoneAccording to details that have emerged since the incident, the rogue notification was addressed directly to ASOS’s data protection officer and IT staff, demanding they “engage” with the attackers or risk having stolen data leaked. It included a link to a Telegram channel and asserted that the group had “fully compromised” ASOS’s Snowflake environment, the cloud data platform many large retailers use to warehouse customer and sales information.

ASOS has confirmed that something real did happen, but it has been careful to separate confirmed fact from the attacker’s own claims. The company says it is “investigating unauthorised activity involving third-party platforms that we use to communicate with customers” and that it immediately cut off access to the notification system once the rogue message was spotted. Beyond that, ASOS has only confirmed an “unauthorised customer notification” — not a verified breach of its Snowflake instance.

What Data Might Be Exposed — and What Probably Isn’tASOS has said that basic personal details, such as customer names and contact information, may have been accessed through the compromised notification platform. Importantly, the retailer states it does not believe payment card numbers or account passwords were affected by this particular incident. That is a meaningfully different exposure profile than a full database theft would represent, assuming the assessment holds up under further investigation.

Security researchers who reviewed the incident have urged caution about taking the attacker’s framing at face value. A spokesperson from Check Point told reporters that the group behind the message may simply be trying to pressure and embarrass ASOS into contact, rather than demonstrating genuine access to backend systems. Gaining control of a third-party notification tool does not, by itself, prove an attacker also reached ASOS’s cloud data warehouse, payment systems, or core retail network — those would typically require separate footholds.

Not ASOS’s First Rodeo This YearThis is the second publicly disclosed security incident to hit ASOS in a matter of months. Back in late July 2026, the company confirmed that customer accounts had been accessed using login credentials obtained from outside the company — a classic credential-stuffing attack, where criminals reuse username and password combinations leaked from unrelated breaches to try their luck against other sites. That episode, detected on July 28 and confirmed the next day, reportedly exposed names, addresses, phone numbers, dates of birth, and partial card details such as expiration dates and the last four digits of payment cards.

ASOS responded to the July incident by locking affected accounts, forcing password resets, and blocking or reversing suspicious transactions. There is no confirmed link between that earlier credential-stuffing wave and this month’s notification-platform compromise, but the back-to-back nature of the incidents has put additional scrutiny on the retailer’s third-party vendor relationships and its broader security posture.

Market and Customer FalloutThe financial market reaction was swift: ASOS shares reportedly fell more than 11%, with some intraday trading showing declines approaching 13%, as the news of a public “hacked” notification spread faster than the company’s own clarifications. ASOS has stated its website and app continued operating normally throughout, and it has cybersecurity and business continuity insurance in place with a major global insurer, though it says it is too early to gauge any impact on trading performance.

What Customers Should Do NowSecurity teams and consumers alike should treat this as a reminder that a dramatic-looking notification is not, on its own, proof of a specific type of compromise. ASOS customers are advised to:

Avoid clicking the Telegram link referenced in the rogue notification, and ignore any follow-up messages that try to leverage the incident to request passwords or payment information.

Watch official ASOS channels for verified updates rather than relying on screenshots circulating on social media.

Change their ASOS password if they have reused it anywhere else, and enable unique, strong passwords going forward.

Monitor bank and card statements for unusual activity, even though ASOS says payment data is not believed to be affected.

ASOS says it is working with external specialists and relevant authorities to determine the scope of the incident. Until that investigation concludes, the gap between what attackers claim and what has actually been verified remains the central open question — one that will likely shape how seriously regulators and customers treat the retailer’s next update.

Read Time:4 Minute, 22 Second

Security researchers at LevelBlue have pulled back the curtain on a credential-harvesting toolkit, internally named TIKTOUK, that turns an everyday WordPress mistake — leaving a site backup or configuration file sitting in a publicly reachable location — into a pipeline for stealing cloud and email credentials at scale. A leaked control panel used to run the operation revealed roughly 50,000 real, server-side credentials gathered from about 37,000 domains, including hundreds of AWS access keys that the researchers confirmed were still active.

Rather than relying on one single exploit, TIKTOUK bundles several different collection techniques together: scanning sites for exposed sensitive files, recovering stored passwords from plugin configurations, and scraping secrets out of JavaScript served to ordinary site visitors. LevelBlue says the operation was already running at meaningful scale by the time it was identified through a combination of source code review, reverse engineering, and controlled lab testing.

Inside the Toolkit’s ArchitectureTIKTOUK is built from two Python components plus a Linux-based crawler written in Go, all of which check in with a central HTTP service to receive tasks and report back findings. The coordination layer distributes targets and collects results, though LevelBlue’s testing didn’t find evidence of a fully automatic handoff between the different components — suggesting a human operator may still be steering parts of the operation.

The probing component handles initial reconnaissance: it pulls a list of targets, confirms which ones are running WordPress, and then sends specially crafted REST API batch requests that combine a malformed URL with delete and content-rendering operations. When a request formatted as JSON gets rejected, the tool automatically retries using multipart encoding instead — and that retry frequently succeeds. That specific fallback pattern, LevelBlue notes, gives defenders a distinctive signature to hunt for in their own web server logs.

Turning a Backup File Into a Credential DumpA separate collection module goes after exposed WordPress configuration backups directly, pulling database credentials and WordPress security keys out of them. It doesn’t stop there — the same component also probes for exposed environment files, repository configuration, raw database backups, and debug logs, essentially sweeping up anything left accessible through a plain web request that shouldn’t be.

Some of its database queries are notably methodical: nested batch requests first retrieve the name WordPress uses for its options table, then feed that name into follow-up queries designed to pull the option values themselves. The tool decodes hexadecimal-encoded responses back into readable text and assembles structured records containing database settings, stored email credentials, AWS key pairs, and recognizable API key patterns.

From Website Compromise to Cloud TakeoverThe blast radius extends well past the compromised website itself. The leaked operator panel contained AWS keys with the potential to be abused for sending email, spinning up compute resources, or accessing AI services tied to the victim’s cloud account. TIKTOUK’s collector can specifically decrypt stored settings from popular SMTP plugins — WP Mail SMTP, Easy WP SMTP, and FluentSMTP — recovering plaintext email credentials using encryption keys or configuration material the tool already has access to. LevelBlue is careful to note this isn’t a cryptographic breakthrough; the toolkit simply gets its hands on what it needs to unlock settings that were never meant to be exposed in the first place. In one particularly efficient step, it can even derive an Amazon SES email password directly from a stolen AWS secret key.

A third piece, the JavaScript crawler, fetches site pages and any scripts they load, scanning the contents for credential patterns tied to services like SendGrid, Anthropic, AWS Bedrock, and AWS more broadly — all secrets that were likely embedded in client-side code by mistake and shipped straight to every visitor’s browser.

Exploitation Links and What’s Still UnconfirmedLevelBlue connected TIKTOUK’s request patterns to two specific vulnerabilities, CVE-2026-60137 and CVE-2026-63030, which affect a batch-route mechanism in WordPress versions 6.9.x prior to 6.9.5 and 7.0.x prior to 7.0.2. Importantly, the firm’s lab testing didn’t go as far as demonstrating a full working exploit — controlled test targets returned pre-prepared responses without actually executing attacker-supplied SQL. That said, separate incident telemetry did confirm the toolkit successfully retrieved payloads and communicated with its controller infrastructure in the wild, and investigators separately identified a related Go-based botnet capable of remote command execution.

In short: the lab results establish exactly how the components behave, not that a specific live production site has been fully breached end-to-end using this chain. Site operators shouldn’t read that distinction as reassuring, though, given the scale of credentials already found in the leaked panel.

What WordPress Site Owners Should CheckConfirm backup files, configuration exports, and debug logs are never stored inside a publicly web-accessible directory.

Update WordPress past the affected 6.9.x and 7.0.x ranges identified in the advisory.

Rotate SMTP plugin credentials and any AWS keys that may have been referenced in configuration files or client-side JavaScript.

Watch server logs for the JSON-then-multipart retry pattern on REST batch endpoints as a potential sign of probing activity.

Audit JavaScript served to visitors for hard-coded API keys or secrets that should never have been placed there.

Read Time:4 Minute, 1 Second

South Korea has ordered a sweeping investigation into a series of breaches across its financial sector after banks, lenders and finance companies disclosed the exposure of sensitive personal information. President Lee Jae Myung directed officials to examine the incidents in full and develop stronger safeguards, elevating what had appeared to be separate company-level events into a national cybersecurity priority.

The response follows disclosures from several institutions in the opening days of October. Although the reported victim counts and affected systems vary widely, the incidents share an uncomfortable theme: business-support platforms outside the core banking environment can still contain valuable identity and credit data. Authorities are now investigating whether the attacks are related and whether automation or artificial intelligence assisted the intruders.

Multiple Institutions Report Exposed Personal DataShinhan Bank reported the largest breach among the major banks, affecting roughly 25,000 customers. The exposed records included names, telephone numbers, annual income and loan limits. Some files also contained resident registration numbers, making the incident more serious because those identifiers can support identity fraud and highly convincing social-engineering attacks.

KB Kookmin Bank and Hana Bank announced smaller but still sensitive exposures. KB said information belonging to 119 customers leaked through a mobile work-support system used by employees. Hana identified abnormal access to an operations-support system involving 89 customers. The affected Hana records reportedly included names, national identification numbers, addresses, email addresses, phone numbers and employer details.

Other organizations also reported incidents. Yegaram Savings Bank said approximately 40,000 customers were affected, while Hyundai Capital disclosed exposure involving 146 housing-loan agents. BNK Busan Bank separately reported information linked to 11 outsourced workers. These numbers refer to different populations and should not be combined into a single confirmed victim total.

AI Clues Do Not Yet Prove a Unified CampaignLocal reporting cited traces of an AI-based automation tool in the Shinhan investigation, while another report said several attacks used common IP addresses. Those clues may help investigators connect infrastructure or methods, but they do not yet establish that one threat actor conducted every intrusion. Nor do they show that an autonomous AI system independently carried out the compromises.

No complete public attack chain has been released. Authorities have not identified a common vulnerability, named malware family or definitive set of indicators spanning all affected institutions. The known access points also appear to include loan-agent websites and internal employee-support tools rather than only public online-banking applications. That distinction matters for both attribution and remediation.

Support Systems Create a Wider Attack SurfaceKB and Hana reportedly said the affected environments were separated from their internet and mobile banking services, and that the incidents did not expose customer transaction data. Segmentation may have limited the immediate financial impact, but it did not prevent the loss of information that criminals can use for follow-on fraud.

The pattern is a reminder that security programs must cover the entire financial-services ecosystem, including:

employee portals and mobile work-support applications;

loan-agent, contractor and outsourced-service platforms;

operations systems holding identity and credit information;

third-party connections with access to customer records; and

logs capable of linking unusual access across separate environments.

Systems considered secondary to the main banking platform can receive less monitoring and slower security investment, even when they store highly sensitive records. Attackers can exploit that imbalance, targeting a weaker application to obtain data suitable for impersonation, phishing or loan fraud without ever entering the core transaction network.

What Authorities and Financial Firms Need to EstablishPolice began examining the incidents on October 2, and financial authorities ordered broader checks at banks and card companies. The most urgent questions are whether the same infrastructure appears in multiple breaches, how attackers first gained access, whether compromised third parties created shared exposure, and what role automation played after entry.

Affected firms should preserve authentication, web, endpoint and administrative logs before retention windows erase useful evidence. They should also review privileged access to support systems, rotate potentially exposed credentials, validate network separation and notify people whose identification data may be misused. Monitoring should extend beyond direct account theft to targeted phishing and fraudulent credit applications.

For customers, the disclosures warrant extra caution around messages that reference real loan details, employers or contact information. Accurate personal data can make a fraudulent call or email appear legitimate. Requests to disclose passwords, one-time codes or transfer funds should be verified through an institution’s official channel rather than through contact details supplied in the message.

The investigation may eventually show several unrelated breaches rather than one coordinated operation. Even so, South Korea’s sector-wide response reflects the broader lesson: financial security depends on every system that collects, processes or supports sensitive customer information, not only the applications that move money.

Source: Cyber Security News.

Read Time:3 Minute, 20 Second

The Pentagon has confirmed a significant data breach involving its Defense Manpower Data Center (DMDC), the system that maintains personnel records for the U.S. military. Officials say unauthorized users exploited a file-sharing vulnerability to access an information system containing unencrypted personal data belonging to millions of current and former service members, dependents, and civilian personnel.

The Scale of the ExposureAccording to the Department’s own disclosure, the incident affected approximately 2.76 million living individuals and roughly 294,000 deceased individuals whose records remained in DMDC systems. The exposed files reportedly contained a wide range of sensitive identifiers: full names, Social Security numbers, dates of birth, contact information, demographic details, and military occupational data that can reveal a person’s role, unit history, or specialty within the armed forces.

That last category is worth dwelling on. Unlike a typical retailer breach, where exposed data is mostly financial, a breach that ties identity information to military occupational history carries added counterintelligence value — it can help a foreign adversary map personnel, specialties, and career trajectories across the force, not just commit identity fraud against individuals.

Nine Months Before Anyone NoticedPerhaps the most troubling detail is the timeline. The Department says the unauthorized access began around October 2025 and continued until DMDC discovered and closed the file-sharing flaw on July 16, 2026 — meaning the exposure window ran for roughly nine months before it was caught. Long dwell times like this are common in breaches involving overlooked file-sharing or storage misconfigurations, since this type of exposure rarely triggers the kind of alerts that a traditional network intrusion would.

The Pentagon has stated that it currently has no evidence the exposed data has been misused. That is a meaningful data point, but it is not the same as a guarantee: Social Security numbers and dates of birth don’t expire, and data obtained in a breach can sit dormant for months or years before showing up in fraud attempts, so the absence of misuse so far does not close the risk window.

Why This Breach Is Different From a Typical Consumer LeakDurability of the data: Names, SSNs, and birth dates don’t lose their value to criminals the way a stolen credit card number does once it’s canceled.

Dual-use risk: The same records that enable identity theft and phishing against individuals can also support targeting by state-aligned intelligence services.

Deceased individuals included: Nearly 294,000 records belonged to deceased people — a reminder that identity theft risk doesn’t end at death, since estates, benefits, and surviving family members can still be targeted.

Scale across a sensitive population: Military-affiliated records are a higher-value target than an average consumer database, raising the stakes of any downstream exploitation.

What’s Being Offered to Affected IndividualsThe Department says it is offering one year of credit monitoring and identity-restoration services to those affected. For a breach involving Social Security numbers, a single year of monitoring is a common but limited mitigation — identity thieves are known to wait out monitoring windows before acting, which is why experts generally recommend affected individuals take additional steps on their own.

Enroll in the credit monitoring and identity-restoration services the Department is offering, and keep enrollment records in case you need to dispute fraud later.

Consider placing a long-term credit freeze with the major credit bureaus, which doesn’t expire after a year the way monitoring offers typically do.

Watch for phishing or impersonation attempts that reference military service, deployment history, or benefits — these are more convincing when attackers already have real personal details to work with.

Family members of deceased personnel whose records were exposed should also monitor for fraudulent activity tied to the deceased’s identity, including attempts to open credit in their name.

The breach adds to a growing list of incidents affecting government personnel data in recent years, underscoring how legacy file-sharing systems inside large bureaucracies remain an attractive and persistent target even as organizations invest heavily in perimeter defenses elsewhere.

Si parla di:

Toggle

Un laptop sequestrato ad Amsterdam, sei giorni prima che il mondo scoprisse che l’#FBI stesso era stato violato. Dentro, oltre alle tracce digitali di uno dei presunti leader di #ShinyHunters, gli investigatori olandesi hanno trovato qualcosa che va ben oltre l’#estorsione informatica: i dettagli di due omicidi da commettere all’estero. La vicenda, resa pubblica il 29 settembre da FBI e polizia olandese, segna uno dei momenti più surreali nella storia recente del #cybercrime organizzato e arriva accompagnata da un messaggio diretto del Bureau al resto del collettivo: “Sapete come trovarci, e noi sappiamo come trovare voi”.

L’arresto prima dell’hackIl 15 settembre la polizia nazionale olandese ha arrestato Pepijn van der Stap, 24 anni, residente ad Amsterdam, con l’accusa di far parte di ShinyHunters e di aver tentato di istigare la commissione di due omicidi. Non è un nome nuovo per le forze dell’ordine: nel 2023 era già stato condannato con lo pseudonimo “Umbreon” per estorsioni e furti di dati. Il tribunale distrettuale di Rotterdam ne ha disposto la detenzione in isolamento per almeno altri 90 giorni, segno che gli inquirenti ritengono il rischio di inquinamento delle prove o di coordinamento con complici tutt’altro che teorico.

Il dettaglio che rende la vicenda ancora più inquietante è la tempistica: l’arresto è avvenuto sette giorni prima che ShinyHunters rivendicasse pubblicamente, il 22 settembre, la violazione dei sistemi dell’FBI. Gli inquirenti, analizzando il materiale sequestrato, hanno scoperto che il sospetto aveva raccolto “una grande quantità di informazioni”, inclusi i piani per due omicidi da eseguire fuori dai confini olandesi. Le autorità non hanno chiarito se i target fossero legati alle attività del gruppo o a dinamiche personali, ma il dato basta da solo a spostare la narrazione di ShinyHunters da “collettivo di estorsori digitali” a qualcosa di più vicino al crimine organizzato con propaggini nel mondo fisico.

La violazione dell’FBI: una questione di ego più che di soldiPochi giorni dopo l’arresto del presunto leader, il resto del collettivo ha rivendicato di aver sottratto tra i 2 e i 3 terabyte di dati dal portale FBIJobs.gov, sfruttando una vulnerabilità zero-day in #Oracle #PeopleSoft. Tra i dati sottratti figurerebbero informazioni relative al personale del Bureau, inclusi dettagli sui membri della Remote Operations Unit, alcuni assegnati a indagini su Cina e #Russia: un’esposizione potenzialmente molto sensibile sul piano della #sicurezza operativa degli agenti coinvolti.

Ciò che distingue questo episodio dal consueto modus operandi del gruppo è la motivazione dichiarata. Interpellato da BleepingComputer, ShinyHunters ha affermato che l’attacco ai sistemi federali “non è mai stato a scopo di estorsione finanziaria né di pubblicazione dei dati”, ma una risposta diretta a un avviso dell’FBI che metteva in dubbio la veridicità delle loro precedenti rivendicazioni. In altre parole: un atto dimostrativo, una prova di capacità contro l’istituzione che li sta cacciando, più che un’operazione lucrativa. È un cambio di registro significativo per un gruppo che, secondo le stime dell’FBI, ha colpito oltre 140 organizzazioni incassando circa 70 milioni di dollari in pagamenti di riscatto nell’ultimo anno.

“Vi conviene presentarvi voi per primi”Il 29 settembre il direttore assistente della Cyber Division dell’FBI, Brett Leatherman, ha diffuso un messaggio insolitamente diretto rivolto ai membri ancora in libertà del collettivo: “Sapete come trovarci, e noi sappiamo come trovare voi. Vi suggerisco di farvi avanti voi per primi, finché la scelta è ancora vostra.” Un invito alla resa che il gruppo, per ora, ha respinto pubblicamente mantenendo un atteggiamento di sfida nei confronti del Bureau, secondo quanto riportato da SecurityWeek.

Chi sono davvero ShinyHuntersAttivo dal 2019, ShinyHunters si è costruito una reputazione come uno dei gruppi più prolifici nel furto e nella rivendita di dati su larga scala: dai 270 milioni di record di Wattpad ai 91 milioni di Tokopedia, fino ai 560 milioni di Ticketmaster e ai 30 milioni di clienti di Santander. Nel 2025 e nel 2026 il gruppo ha allargato il raggio d’azione colpendo anche atenei di primo piano come Penn, Harvard e Princeton, oltre a una lunga serie di aziende che si affidano a piattaforme SaaS come Salesforce e Snowflake, spesso compromesse tramite furto di token OAuth o configurazioni cloud errate piuttosto che exploit tecnici sofisticati.

Il collettivo non ha mai operato in modo isolato: la sua composizione si sovrappone parzialmente ad altri gruppi legati al network criminale noto come “The Com”, inclusi Scattered Spider e Lapsus$. L’etichetta “Scattered Lapsus$ Hunters”, comparsa più volte nelle rivendicazioni pubbliche degli ultimi mesi, riflette proprio questa convergenza di membri tra i tre collettivi, tutti caratterizzati da un profilo demografico simile, giovani, spesso minorenni al momento dei primi reati, di lingua inglese, e da una propensione a cercare visibilità mediatica quasi quanto il guadagno economico.

Gli arresti, del resto, non sono una novità per il gruppo. Il francese Sébastien Raoult fu catturato in Marocco nel maggio 2022 ed estradato negli Stati Uniti, dove nel gennaio 2024 ha ricevuto una condanna a tre anni di reclusione. Nel giugno 2025 un diciannovenne del Massachusetts, Matthew D. Lane, si è dichiarato colpevole per l’attacco a PowerSchool, mentre sempre nel giugno 2025 le autorità francesi hanno arrestato quattro presunti membri. Nessuno di questi colpi, però, ha mai fermato stabilmente l’operatività del collettivo: la leadership si riforma, i canali Telegram cambiano nome, e le campagne di estorsione riprendono nel giro di settimane.

Due righe per i difensoriAl di là dell’elemento di cronaca nera, la vicenda offre due indicazioni operative concrete. La prima è che ShinyHunters resta un consumatore vorace di vulnerabilità in applicazioni enterprise esposte, Oracle PeopleSoft in questo caso, dopo campagne precedenti contro Oracle E-Business Suite, un pattern che le organizzazioni con installazioni Oracle legacy dovrebbero monitorare con priorità alta, specie su portali HR e gestione del personale raggiungibili da Internet. La seconda è che l’escalation verso la minaccia di violenza fisica, per quanto riconducibile a un singolo individuo e non necessariamente a una policy del gruppo, segnala un livello di rischio che i team di sicurezza aziendale e le funzioni di protezione esecutiva non possono più permettersi di ignorare quando valutano l’esposizione a questi collettivi: non si tratta più soltanto di dati e riscatti, ma potenzialmente di sicurezza personale di dipendenti e dirigenti coinvolti nelle indagini o nella risposta agli incidenti.

Per chi gestisce ambienti Oracle PeopleSoft o E-Business Suite esposti, la raccomandazione resta quella consueta ma oggi più urgente: applicare tempestivamente le patch critiche Oracle, segmentare l’accesso ai portali HR da Internet, monitorare i log di autenticazione per anomalie e verificare la presenza di eventuali SSO o integrazioni SaaS (Salesforce, Snowflake e simili) con permessi più ampi del necessario, dato che restano il vettore preferito del gruppo per il furto di dati su vasta scala.

Si parla di:

Toggle

Per due mesi e tre giorni, qualcuno ha letto in tempo reale tutta la posta elettronica in arrivo su Belnet, la rete nazionale belga per la ricerca e l’#istruzione che collega università, centri di ricerca e amministrazioni pubbliche. L’accesso è passato per una vulnerabilità zero-day in un prodotto di terze parti che Belnet, a incidente concluso, si è rifiutata di nominare. È un caso che dice più cose su cosa NON viene comunicato nella #cybersecurity europea che su cosa viene comunicato e per un lettore esperto, il silenzio è spesso il dato più interessante.

Cosa è successoBelnet è l’infrastruttura di rete gestita dallo Stato belga che fornisce connettività a università, istituti di ricerca, ospedali universitari e diverse amministrazioni pubbliche del paese: un ruolo per certi versi assimilabile a quello del GARR in Italia o di JANET nel Regno Unito. Secondo quanto ricostruito, un attore non identificato ha sfruttato una falla zero-day in una tecnologia fornita da un vendor esterno per intercettare e copiare, senza essere rilevato, tutta la corrispondenza in ingresso destinata a Belnet e ad almeno un’organizzazione cliente, allegati compresi.

La finestra di esposizione confermata va dal 22 luglio al 25 settembre 2026, quando la falla è stata infine chiusa (alle 08:10 ora locale). Belnet stessa ha precisato che questo intervallo rappresenta soltanto il “periodo confermato di perdita dati”, non necessariamente il momento dell’accesso iniziale: in altre parole, la presenza dell’attaccante nell’infrastruttura potrebbe risalire a prima del 22 luglio, e l’organizzazione non è in grado di escluderlo. L’intrusione è stata rilevata il 24 settembre, un giorno prima della #patch, una finestra di reazione rapida una volta scoperta l’anomalia, ma che segue oltre nove settimane di raccolta email passata sotto silenzio.

Il non-detto è il puntoBelnet ha confermato l’incidente e dichiarato di aver informato le autorità competenti, il Centro per la Cibersicurezza del #Belgio (CCB) sta seguendo le indagini, e allertato i clienti sulle possibili conseguenze. Ma su tre punti cruciali per qualunque analisi di rischio, il comunicato resta muto: quale sia il vendor coinvolto, quale sia il prodotto specifico, e quale sia stato il meccanismo di exploitation. Senza queste informazioni è impossibile correlare l’incidente con un #CVE pubblico, verificare se altre organizzazioni che usano lo stesso prodotto siano a rischio, o stimare se la vulnerabilità sia stata sfruttata anche altrove prima della disclosure.

Questo tipo di reticenza, comune quando un fornitore critico non vuole essere identificato pubblicamente, o quando accordi di responsabilità contrattuale sono ancora in negoziazione, lascia un vuoto che nella prassi CTI internazionale viene sempre più spesso criticato: un IOC condiviso in ritardo, o mai condiviso, protegge il vendor ma esporre gli altri utenti dello stesso prodotto a un rischio residuo che nessuno può misurare. Belnet non ha nemmeno indicato l’attribuzione: non si sa se dietro l’attacco ci sia un gruppo con finalità di #intelligence, un broker di accessi che ha poi rivenduto la backdoor, o un attore puramente cybercriminale interessato ai dati intercettati per finalità di frode o estorsione.

Perché la geografia del bersaglio contaIl dettaglio che rende questo incidente più di una semplice violazione email è la natura di Belnet come infrastruttura critica di ricerca e governo. Il traffico che attraversa la rete non è quello di un’azienda qualunque: include comunicazioni di ministeri, università coinvolte in progetti di ricerca strategica (incluse collaborazioni internazionali e possibili programmi a duplice uso civile-militare), ospedali universitari e istituti scientifici. Il Belgio ha già una storia di infrastrutture di rete pubblica bersaglio di operazioni attribuite a servizi di intelligence stranieri, il caso Belgacom del 2013, legato a GCHQ, resta il precedente più noto, e ogni nuovo incidente su reti governative belghe viene letto a Bruxelles, sede di NATO e Commissione Europea, con un’attenzione geopolitica che va oltre il singolo data breach.

Va detto con chiarezza: al momento non esiste alcuna attribuzione ufficiale a un attore statale per questo specifico incidente, e sarebbe scorretto presentarlo come tale. Ma il profilo tecnico, uno zero-day non banale contro un fornitore di infrastruttura, silenzioso per oltre due mesi, mirato alla raccolta passiva di corrispondenza piuttosto che a un impatto distruttivo o estorsivo immediato, è coerente con un modus operandi da cyberspionaggio più che da cybercrimine finanziario, e merita di essere seguito nelle prossime settimane per capire se emergeranno collegamenti con campagne note.

Cosa possono fare i difensoriPer i team di sicurezza di università, enti di ricerca e amministrazioni che si affidano a provider di connettività nazionale o consortile (in Italia: GARR; a livello europeo: GÉANT e le NREN nazionali), questo caso è un buon promemoria che il rischio della supply chain non riguarda solo i software desktop o le librerie open source, ma anche l’infrastruttura di rete e i suoi fornitori di componenti “invisibili”, gateway di posta, sistemi di filtraggio, appliance di sicurezza perimetrale. Alcune azioni concrete:

Richiedere ai propri provider NREN/ISP conferma scritta se utilizzano tecnologie coinvolte in incidenti pubblicamente noti, anche quando il vendor non è nominato;

Considerare la cifratura end-to-end della corrispondenza sensibile che transita su reti di ricerca condivise, per ridurre l’impatto di un’intercettazione a monte del provider;

Monitorare eventuali comunicazioni successive del CCB belga o di CERT-EU, che potrebbero rilasciare indicatori più specifici una volta chiusa l’indagine;

Nei contratti con fornitori di infrastruttura critica, inserire clausole di disclosure minima garantita (vendor, CVE, timeline) in caso di incidente, per evitare di ritrovarsi nella stessa cecità informativa vissuta ora dai clienti Belnet.

Aggiorneremo l’articolo se il CCB belga o Belnet rilasceranno ulteriori dettagli su vendor coinvolto, CVE assegnato o attribuzione.

Si parla di:

Toggle

Non è la solita #estorsione a scopo di lucro. Il 22 settembre 2026 il collettivo #ShinyHunters ha rivendicato una violazione dei sistemi HR dell’#FBI, sostenendo di aver sottratto dati personali su “quasi tutti gli agenti” del Bureau e sugli aspiranti tali, e di averlo fatto non per soldi ma per costringere l’agenzia a ritrattare un proprio avviso pubblico. È il secondo attacco noto contro sistemi FBI nel 2026, e il primo in cui un gruppo cybercriminale si rivolge direttamente, per nome, al direttore Kash Patel e all’assistant director della #Cyber Division Brett Leatherman, trasformando un data breach in un braccio di ferro istituzionale.

Dalla PSA dell’FBI alla rappresagliaIl casus belli, secondo la ricostruzione di più testate (TechCrunch, Nextgov/FCW, DataBreaches.net), risale a un Public Service Announcement diffuso dall’FBI tramite l’IC3 il 15 maggio 2026, in cui il Bureau descriveva le tattiche di ShinyHunters come intimidatorie e in parte estorsive: comunicazioni minacciose verso le vittime e i loro familiari, episodi di swatting (false segnalazioni di emergenza per far intervenire la polizia armata presso l’abitazione del bersaglio) ed esagerazioni sui dati effettivamente sottratti o sul materiale compromettente in possesso del gruppo. ShinyHunters contesta questa ricostruzione, sostenendo che la loro attività non sia motivata finanziariamente, e ha chiesto — con un ultimatum di una settimana — che l’avviso venga ritirato.

Cosa sarebbe successo tecnicamenteSecondo quanto riportato da 404 Media, che per prima ha ricevuto un campione dei dati, e ripreso da TechCrunch, il punto d’ingresso sarebbe stato un server #Oracle #PeopleSoft usato dall’FBI per le risorse umane, sfruttato per poi effettuare un pivot verso un ambiente #cloud #Amazon (GovCloud) che ospitava i registri del personale. Gli attaccanti sostengono di aver avuto accesso al sistema nella notte tra lunedì e martedì e di aver esfiltrato tra i 2 e i 3 terabyte di dati, incluso l’accesso al servizio interno “Medlink”. Il campione condiviso con i giornalisti conterrebbe circa 5.000 record di dipendenti, con nomi, indirizzi di casa, numeri di telefono, date di nascita e dettagli sui coniugi. Al momento della pubblicazione delle prime notizie, il portale delle candidature apply.fbijobs.gov mostrava un avviso di manutenzione, dopo che — secondo alcune fonti — in una fase precedente il sito era stato brevemente sfigurato con un messaggio di rivendicazione del gruppo.

L’FBI non ha fornito commenti ufficiali alle richieste dei giornalisti, e allo stato attuale le affermazioni di ShinyHunters restano non verificate in modo indipendente: si tratta, come spesso accade con questo genere di rivendicazioni, di claim del gruppo attaccante corroborati solo da un campione limitato di dati.

Chi è ShinyHunters, e perché questo attacco è diversoShinyHunters è tra i marchi più riconoscibili del #cybercrime degli ultimi anni: dietro la sigla si sono avvicendati diversi cluster e affiliazioni, spesso in orbita con la galassia “Scattered Lapsus$ Hunters”, responsabile di alcune delle campagne di data theft ed estorsione più rumorose del biennio, dai raid contro istanze Salesforce mal configurate fino alle violazioni ai danni di grandi retailer e provider SaaS. Ciò che distingue l’episodio FBI dal solito playbook — accesso, esfiltrazione, richiesta di riscatto, leak site — è la motivazione dichiarata: non estorcere denaro all’organizzazione violata, ma usare i dati sottratti come leva per costringere l’agenzia governativa a modificare la propria comunicazione pubblica nei loro confronti. È una forma di pressione ibrida, a metà tra il ricatto reputazionale e l’intimidazione istituzionale, che segna un’escalation nel rapporto — già teso — tra le agenzie federali statunitensi e i gruppi di cybercrime più esposti mediaticamente.

Le implicazioni per la sicurezza nazionaleAl di là della componente propagandistica, l’aspetto più delicato riguarda il possibile impatto controintelligence: dati anagrafici su agenti in servizio e le loro famiglie — indirizzi, numeri di telefono, legami familiari — sono esattamente il tipo di informazione che, se autentica e in mano ad attori ostili o rivenduta sul mercato criminale, può essere sfruttata per campagne di coercizione, sorveglianza fisica o tentativi di reclutamento/ricatto nei confronti del personale delle forze dell’ordine. È lo stesso ordine di preoccupazioni sollevato in precedenza per altre violazioni di dati governativi sensibili, ed è il motivo per cui, a prescindere dalla verifica indipendente delle rivendicazioni, l’FBI difficilmente potrà limitarsi a un comunicato di routine.

Cosa osservare nei prossimi giorniUna risposta ufficiale — o il silenzio prolungato — da parte dell’FBI, che di per sé è un segnale sullo stato delle indagini interne.

L’eventuale pubblicazione di ulteriori campioni di dati da parte di ShinyHunters se l’ultimatum sulla PSA non verrà rispettato.

Conferme indipendenti sull’autenticità dei dati, dato che il gruppo ha uno storico di rivendicazioni sia accurate sia gonfiate per finalità di visibilità.

Possibili riflessi su altre agenzie federali che usano la stessa piattaforma Oracle PeopleSoft per la gestione HR, qualora il vettore di accesso iniziale fosse confermato e replicabile.

Due righe per i difensoriVerificare la postura di sicurezza delle istanze Oracle PeopleSoft esposte, incluse patch, segmentazione di rete e autenticazione verso i moduli HR.

Rivedere le policy di accesso e i log di audit per gli ambienti AWS GovCloud collegati a sistemi di gestione del personale.

Predisporre piani di comunicazione e supporto per il personale i cui dati personali potrebbero essere esposti, incluse misure contro possibili tentativi di swatting o intimidazione.

Monitorare i leak site e i canali Telegram associati a ShinyHunters e alla galassia Scattered Lapsus$ Hunters per individuare tempestivamente eventuali pubblicazioni di dati.

Fonti: TechCrunch, Nextgov/FCW, DataBreaches.net, Cybernews, 404 Media (via TechCrunch).

Eh si… lo so che ora siamo tutti con gli occhi puntati su #Revolut, ma intanto in Italia succedono cose…

Attacco informatico a Comune di Prato. #cyberattack #databreach

Questa stava sfuggendo ma ho rimediato subito, discussione aperta sul forum per tenere traccia: https://internet-forum.it/d/5234-comune-di-prato-8926

@informatica@feddit.it

Revolut è stata davvero hackerata? Non proprio.

Il punto più interessante della vicenda è un altro: una richiesta apparentemente proveniente da una PEC istituzionale italiana avrebbe permesso di ottenere dati sensibili di centinaia di clienti.

Nel video ricostruiamo cosa sappiamo, cosa è ancora da confermare e perché il vero problema è la catena di fiducia.

🎥 https://youtu.be/tjcKUgznoM4

#CyberSecurity #Revolut #PEC #DataBreach #ZeroTrust

Si parla di:

Toggle

Per sei mesi, secondo la ricostruzione emersa in questi giorni, qualcuno ha usato una casella di posta elettronica certificata di uno degli uffici periferici del #Ministero dell’Interno per convincere #Revolut a consegnare dati riservati su centinaia di clienti benestanti in mezza #Europa. Non un attacco informatico ai sistemi Revolut, che l’azienda insiste siano rimasti «pienamente sicuri», ma qualcosa di più insidioso: l’abuso sistematico di un canale che #banche ed #exchange sono tenute per legge a considerare affidabile. La vicenda, che coinvolge un attore che si firma IAmNotAVillain, un riscatto sceso da 780 milioni di dollari in #Bitcoin a 3 milioni in #Monero nel giro di un weekend, e una minaccia — non confermata — di aver sottratto 147 GB di documenti dalle forze dell’ordine italiane, è probabilmente il caso di social engineering istituzionale più elaborato mai raccontato su un exchange #fintech europeo.

Anatomia dell’attacco: una PEC della Prefettura come grimaldelloIl punto di innesco individuato dagli investigatori è un account di posta elettronica certificata riconducibile alla Prefettura di Reggio Calabria, sul dominio istituzionale pec.interno.it. Da quella casella compromessa, gli attaccanti si sono spacciati per funzionari della Polizia Postale italiana e hanno iniziato a inviare a Revolut richieste formali di dati su singoli clienti, presentate come parte di indagini in corso. Secondo la ricostruzione di un analista che ha seguito da vicino il caso (identificato pubblicamente con lo pseudonimo Korra), la tecnica usata è stata descritta come “spray and pray”: centinaia di ID di transazione inviati in sequenza a Revolut, ciascuno accompagnato da una richiesta di dettagli del titolare del conto, sfruttando gli obblighi di cooperazione con le forze dell’ordine europee (gli ordini di produzione dati transfrontalieri previsti dal quadro e-evidence dell’UE).

Revolut, dal canto suo, ha inquadrato l’accaduto come «una sofisticata #truffa di impersonificazione esterna», sottolineando che le richieste fraudolente sono passate attraverso un canale di comunicazione statale regolamentato e hanno aggirato i controlli di autenticazione della posta elettronica — SPF, DKIM e DMARC — proprio perché provenivano da un dominio governativo genuino e non da un dominio civetta facilmente bloccabile. È il paradosso al cuore di questo incidente: più il canale è istituzionalmente affidabile, meno le difese tecniche standard sono in grado di intercettarne l’abuso.

Caccia ai «crypto whales»: una selezione mirata, non casualeQuello che distingue questo caso da un generico furto di dati è la metodologia di selezione delle vittime. Gli attaccanti non hanno chiesto dati a caso: secondo le ricostruzioni giornalistiche, hanno prima condotto un’attività di blockchain analysis per identificare, tra gli utenti Revolut, i portafogli con asset in criptovalute di valore significativo — i cosiddetti “crypto whales” — per poi usare il canale PEC compromesso per ottenere l’identità reale dietro quei wallet. Circa 680 clienti risultano coinvolti, in maggioranza residenti in Svizzera e Francia, ma con vittime disperse in oltre 30 paesi europei complessivamente.

È un modello operativo che ribalta la sequenza classica del data breach: non si parte da un accesso di sistema per poi vedere cosa si trova, si parte da un’analisi on-chain pubblica per costruire una lista di bersagli ad alto valore, e solo dopo si cerca lo strumento — in questo caso un canale istituzionale abusato — per trasformare quell’informazione pubblica (un indirizzo wallet) in un’informazione privata e monetizzabile (nome, documento, indirizzo di casa).

Cosa è stato sottrattoIl pacchetto di dati che l’attaccante sostiene di avere, e che ha iniziato a mostrare come prova su un leak site con countdown pubblico, include copie di passaporti e patenti, selfie di verifica dell’identità (i classici “liveness check” richiesti in fase di onboarding KYC), indirizzi di residenza, IBAN, estratti conto ed estese cronologie di transazioni, incluse quelle in criptovalute con tanto di controparti coinvolte. È esattamente il tipo di dataset che, nelle mani sbagliate, abilita frodi di identità, tentativi di SIM swap mirati e attacchi di social engineering “su misura” contro le vittime, che a quel punto possono essere contattate con dettagli finanziari reali per aumentare la credibilità della truffa.

Da 780 milioni in Bitcoin a 3 milioni in Monero: l’evoluzione del riscattoLa cronologia della richiesta di riscatto racconta da sola l’incertezza e forse l’inesperienza di chi gestisce l’estorsione. Nel fine settimana precedente alla pubblicazione della notizia circolava una richiesta iniziale attorno a 10.000 Bitcoin, circa 780 milioni di dollari all’epoca — una cifra così sproporzionata da apparire più una dichiarazione d’intenti mediatica che una reale base negoziale. Nel giro di poche ore la richiesta è stata rivista drasticamente al ribasso: circa 6.000 XMR (Monero), equivalenti a circa 3 milioni di dollari, con un termine perentorio di 24 ore prima di mettere in vendita i dati dei 680 clienti ad altri gruppi criminali.

Il passaggio da Bitcoin a Monero è di per sé un indicatore operativo interessante: Bitcoin resta tracciabile su una blockchain pubblica, e proprio l’uso della blockchain analysis per identificare le vittime dimostra che l’attaccante conosce bene questi strumenti — sa quindi che accettare un pagamento in BTC significherebbe lasciare una pista visibile agli stessi investigatori che useranno le sue tecniche contro di lui. Monero, con la sua privacy crittografica nativa, elimina quel rischio. Al momento in cui scriviamo, secondo le fonti giornalistiche, Revolut non risulta aver ricevuto alcuna richiesta di riscatto attraverso canali negoziali diretti: il countdown corre pubblicamente sul leak site, non in una trattativa privata.

Le 147 GB non confermate: un attacco più ampio alla PA italiana?La parte più delicata, e meno verificabile, della vicenda riguarda le affermazioni dello stesso IAmNotAVillain su un compromissione ben più ampia delle sottodivisioni della polizia italiana. L’attore sostiene di aver mantenuto accesso persistente per circa sei mesi a diverse caselle di posta istituzionali, sottraendo complessivamente circa 147 GB di materiale che includerebbe documenti interni, calendari operativi, file personali di funzionari e corrispondenza ufficiale. Nessuna fonte indipendente ha finora confermato l’entità di questa esfiltrazione, e va trattata con la cautela dovuta a ogni claim di un attore criminale che ha tutto l’interesse a gonfiare la propria immagine per rafforzare la leva estorsiva. Detto questo, la Polizia Postale, la Polizia di Stato, il Ministero dell’Interno e l’Agenzia per la Cybersicurezza Nazionale hanno confermato indagini in corso, pur senza commenti ufficiali sul merito, e una europarlamentare ha definito l’episodio «allarmante a un livello inimmaginabile».

Due righe per i difensoriQuesto caso è un promemoria scomodo per chiunque gestisca processi di compliance, KYC o cooperazione con le forze dell’ordine in ambito fintech: l’autenticità tecnica di un dominio di provenienza (PEC governativa, SPF/DKIM/DMARC validi) non equivale all’autenticità della richiesta che trasporta. I team di trust & safety dovrebbero prevedere canali di verifica secondari e fuori banda per ogni richiesta di dati sensibili proveniente da autorità, specie quando il volume delle richieste aumenta in modo anomalo in un breve periodo — il pattern “spray and pray” descritto in questo caso avrebbe dovuto, in teoria, far scattare un campanello d’allarme sul numero di richieste da un singolo mittente. Per le pubbliche amministrazioni, il caso conferma quanto le caselle PEC, spesso trattate come infrastruttura “di serie B” rispetto alla posta elettronica ordinaria, meritino lo stesso livello di hardening, MFA e monitoraggio degli accessi riservato ai sistemi considerati critici.

Dettagli tecnici e timelineAttore: IAmNotAVillain
Canale d'accesso: casella PEC istituzionale (dominio pec.interno.it),
riconducibile alla Prefettura di Reggio Calabria: entilocali.prefrc@pec.interno.it
Tecnica: impersonificazione di autorità di polizia via canale statale
verificato (bypass SPF/DKIM/DMARC per dominio legittimo)
Metodo di selezione vittime: blockchain analysis per individuare
wallet Revolut ad alto controvalore ("crypto whales")
Vittime: ~680 clienti, prevalenza Svizzera/Francia, ~30+ paesi UE coinvolti
Dati esfiltrati: passaporti, patenti, selfie KYC, indirizzi, IBAN,
estratti conto, cronologia transazioni incluse crypto

Timeline:

• ~marzo 2026: presunto inizio dell'accesso persistente alla PEC
• settembre 2026: Revolut rileva anomalie verificando le richieste
  direttamente con le autorità italiane
• weekend pre-17/09/2026: richiesta di riscatto iniziale ~10.000 BTC
• 17/09/2026: riscatto rivisto a ~6.000 XMR (~3M USD), deadline 24h
• 17/09/2026: Polizia Postale italiana avvia indagine formale

Claim non verificato: ulteriori ~147 GB da caselle di polizia italiana
Fonte: Revolut, Security Affairs, Irish Times, riscontri giornalisticiAl di là dell’esito della trattativa sul riscatto, la lezione di questo incidente è già scritta: nell’era della blockchain analysis a portata di chiunque, il perimetro da difendere per un exchange non è più solo il proprio datacenter, ma ogni singolo canale istituzionale che si è impegnato ad ascoltare quando bussa un’autorità. E quel canale, in questo caso, si è rivelato l’anello più debole della catena.

Breaking, exclusive and spicy, from me:

A new identity theft service launched on the dark web this week is selling digital scans of more than 153 million drivers licenses from people in the United States and Canada. Based on interviews with individuals whose licenses are available for purchase on this service, it appears to be siphoning images collected by a widely-used identity verification company based in Louisiana. KrebsOnSecurity also has learned that the New Orleans field office of the Federal Bureau of Investigation (FBI) today launched an official inquiry into the source of the images.

https://krebsonsecurity.com/2026/09/fbi-probes-service-selling-153m-drivers-licenses/

#databreach #privacy #id #breach #fbi

🔎 Italian school vendor lists 6.1TB

#xplOitrs lists stolen files for $50.000.
Spaggiari Group says it's all ok.
And the threat actor smirks.

Thanks #FanPage for the mention, ransomNews is happy to serve 😎

🔗 read more: https://www.fanpage.it/innovazione/tecnologia/violato-il-gestore-dei-software-piu-usati-nelle-scuole-ditalia-dati-in-vendita-a-50-000-dollari/

#ransomNews #cyberthreats #DataBreach

Si parla di:

Toggle

Il 20 agosto 2026 il gruppo di #cybercrime xpl0itrs ha rivendicato sul proprio leak site l’esfiltrazione di 6,1 terabyte di dati da oltre 3.000 istituti scolastici italiani, colpendo l’infrastruttura del Gruppo Spaggiari di Parma, storico fornitore del registro elettronico ClasseViva usato ogni giorno da milioni di studenti, famiglie e docenti in tutta Italia. La rivendicazione ha acceso i riflettori su uno dei fornitori più capillari dell’ecosistema scolastico nazionale, ma la risposta ufficiale dell’azienda — arrivata il giorno successivo — ridimensiona sensibilmente la portata dell’incidente, aprendo un caso di studio interessante sul divario tra ciò che i gruppi ransomware rivendicano e ciò che, effettivamente, è stato compromesso.

Il bersaglio: cent’anni di storia, 4.000 scuole, 4,5 milioni di utentiFondato nel 1926, il Gruppo Spaggiari si è evoluto da editore scolastico a fornitore di servizi digitali per la gestione della didattica, diventando negli anni uno dei nomi più riconoscibili della #scuola italiana grazie a ClasseViva, il registro elettronico che connette istituti, insegnanti, studenti e famiglie. Secondo i dati riportati dall’azienda stessa, la piattaforma è oggi utilizzata da oltre 4.000 #scuole attive con più di 4,5 milioni di utenti giornalieri — una superficie d’attacco enorme, che rende qualunque incidente di #sicurezza su questo fornitore un potenziale problema di scala nazionale.

Chi è xpl0itrs: dalla supply chain agli attacchi ad alto profiloxpl0itrs è un collettivo di cybercrime a scopo di lucro emerso all’inizio del 2026, che secondo le analisi di threat intelligence opera in stretto coordinamento con un altro gruppo, #TeamPCP, condividendo accesso iniziale, strumenti e talvolta le stesse vittime all’interno di un ecosistema focalizzato sulla compromissione della supply chain software. Il modus operandi del gruppo si concentra su furto di token di sviluppo — Personal Access Token, credenziali #OAuth, chiavi API — sottratti da ambienti di sviluppo, seguito da esfiltrazione di dati da repository e infrastrutture interne. Un membro che si fa chiamare “boxturtl” funge da portavoce pubblico, presentandosi come ex red teamer professionista.

Nelle scorse settimane il gruppo ha rivendicato, con diversi gradi di credibilità, violazioni ai danni di realtà molto note tra cui Spotify, il Dipartimento del Tesoro statunitense, OpenAI e Trustpilot, oltre a vittime indirette raggiunte tramite la compromissione di progetti open source come Trivy, BitWarden CLI, LiteLLM e Checkmarx KICS. Il profilo tracciato da Dataminr valuta le rivendicazioni del gruppo come “generalmente credibili”, basandosi su campioni di dati che contengono riferimenti plausibili a risorse di sviluppo interne e metadati Git coerenti con un accesso autentico mantenuto almeno fino a maggio 2026. Gli analisti segnalano inoltre legami indiretti con i cluster di estorsione DarkRomance e con il brand ShinyHunters, e una tecnica MITRE ATT&CK documentata — T1486, Data Encrypted for Impact — che colloca il gruppo nella categoria ransomware/extortion a tutti gli effetti, con almeno otto rivendicazioni pubblicate sul proprio leak site negli ultimi trenta giorni.

La rivendicazione contro la versione ufficialeSecondo la rivendicazione pubblicata da xpl0itrs, i 6,1 TB sottratti includerebbero nomi, indirizzi email, numeri di telefono e almeno un campo password relativo a oltre 3.000 istituti scolastici — senza, secondo quanto dichiarato dagli stessi attaccanti, identificatori governativi come codici fiscali o numeri di documento. Spaggiari ha risposto con un comunicato ufficiale datato 21 agosto 2026, precisando che a essere compromesso sarebbe stato esclusivamente il componente “Modulistica Smart” della piattaforma Bergantini — uno strumento per la gestione della modulistica scolastica — e non il registro elettronico ClasseViva, i sistemi di gestione didattica o quelli amministrativi, definiti dall’azienda “un sistema distinto e separato” rispetto a quello colpito.

Un dettaglio significativo emerso dalla ricostruzione è la data dell’intrusione originaria: secondo Spaggiari l’accesso non autorizzato risalirebbe al 30 giugno 2026, quasi due mesi prima della rivendicazione pubblica del 20 agosto. Un intervallo così ampio tra compromissione e divulgazione è tutt’altro che insolito nel panorama ransomware: spesso corrisponde al tempo impiegato dagli attaccanti per l’esfiltrazione, l’eventuale negoziazione privata con la vittima (evidentemente naufragata, in questo caso) e, infine, la pubblicazione sul leak site come leva estorsiva. L’azienda ha dichiarato di aver notificato l’incidente al Garante per la protezione dei dati personali, all’Agenzia per la Cybersicurezza Nazionale (ACN) e alle forze dell’ordine.

Perché il divario tra le due versioni contaIl contrasto tra la portata rivendicata (6,1 TB, oltre 3.000 scuole) e quella riconosciuta ufficialmente (un singolo modulo di modulistica) è un pattern ricorrente nelle dinamiche di doppia estorsione: i gruppi ransomware hanno tutto l’interesse a massimizzare la percezione del danno per aumentare la pressione sulla vittima e il valore di rivendita dei dati, mentre le aziende colpite tendono, comprensibilmente, a circoscrivere la narrazione pubblica il più possibile. Senza una verifica indipendente di un campione dei dati esfiltrati — al momento non disponibile pubblicamente — è prematuro stabilire quale delle due versioni sia più vicina alla realtà, ma il profilo di xpl0itrs, storicamente valutato come “generalmente credibile” dagli analisti, invita quantomeno alla cautela verso un ridimensionamento totale dell’incidente.

Rischi concreti per famiglie e istitutiAnche nello scenario più contenuto descritto da Spaggiari, l’esposizione di nominativi, email, numeri di telefono e credenziali legate al mondo scolastico costituisce un rischio concreto: questo tipo di dataset è particolarmente appetibile per campagne di phishing mirato verso segreterie scolastiche e famiglie (spesso mascherate da comunicazioni ClasseViva o da avvisi del Ministero dell’Istruzione), per tentativi di account takeover su servizi che riutilizzano le stesse credenziali, e per la profilazione di minori, un tema su cui il Garante privacy italiano è tradizionalmente molto attento. Le scuole coinvolte dovrebbero considerare, come misura precauzionale indipendentemente dall’entità confermata del breach, la rotazione delle credenziali di accesso al modulo Modulistica Smart, l’attivazione di autenticazione a più fattori dove disponibile e un’allerta mirata al personale su possibili tentativi di phishing a tema scolastico nelle prossime settimane.

Riferimenti e indicatori# Incidente Gruppo Spaggiari / ClasseViva
Attore: xpl0itrs (coordinato con TeamPCP)
Tecnica MITRE ATT&CK: T1486 - Data Encrypted for Impact
Componente rivendicato come compromesso: Modulistica Smart (piattaforma Bergantini)
Data intrusione dichiarata da Spaggiari: 30 giugno 2026
Data rivendicazione pubblica: 20 agosto 2026
Data comunicato ufficiale Spaggiari: 21 agosto 2026
Volume dati rivendicato: ~6,1 TB / 3.000+ istituti scolastici
Tipologia dati rivendicati: nominativi, email, numeri di telefono, password (parziale)
Notifiche effettuate: Garante Privacy, ACN, forze dell'ordineFonti: comunicato ufficiale Gruppo Spaggiari, ransomware.live, Dataminr Intel Brief, GalaxyWarden, monitoraggio leak site.

Si parla di:

Toggle

Connor Riley Moucka, 26 anni, di Kitchener (Ontario), si è dichiarato colpevole mercoledì 5 agosto 2026 davanti a un tribunale federale dello stato di Washington per #frode informatica, frode telematica, furto di identità aggravato e cospirazione. È l’epilogo giudiziario di quella che resta una delle campagne di furto dati ed estorsione più estese mai orchestrate contro un singolo fornitore #cloud: l’attacco del 2024 alla piattaforma #Snowflake, che ha colpito almeno 165 aziende clienti e portato al furto di miliardi di record. Moucka rischia fino a 32 anni di carcere e sarà sentenziato il 27 ottobre.

Non una violazione di Snowflake, ma delle credenziali dei suoi clientiIl dettaglio tecnico che ha reso il caso Snowflake un caso di #scuola è che la piattaforma stessa non è mai stata compromessa. #Mandiant, incaricata da Snowflake di condurre l’indagine forense, ha attribuito la campagna a un cluster tracciato come UNC5537 e ha confermato che gli attaccanti hanno sfruttato credenziali valide ma esposte da tempo — in alcuni casi risalenti al 2020 — raccolte tramite #infostealer su macchine di dipendenti o partner delle aziende clienti. La mancanza sistemica di autenticazione a più fattori sugli account Snowflake ha fatto il resto, trasformando credenziali rubate anni prima in un accesso diretto ai #data warehouse di centinaia di organizzazioni.

Secondo Mandiant, il gruppo dietro la campagna era basato in Nord America e collaborava con almeno un membro operante dalla Turchia — identificato in seguito in John Erin Binns, già legato all’hack di T-Mobile del 2021 e arrestato in Turchia nel 2024.

Le vittime: dalle telco alla sanità, passando per la vendita di bigliettiL’elenco delle aziende colpite tra febbraio e ottobre 2024 legge come una rassegna delle violazioni più discusse dell’anno: AT&T, con i log di chiamate e #SMS di oltre 100 milioni di clienti; #Ticketmaster/Live Nation, con dati relativi a circa 560 milioni di utenti; Advance Auto Parts; uno dei distretti scolastici più grandi degli Stati Uniti; Neiman Marcus; Santander; LendingTree. I dati sottratti includevano estratti bancari, informazioni finanziarie, numeri di registrazione DEA, patenti di guida, passaporti e numeri di previdenza sociale.

Estorsione, ri-estorsione e mercati undergroundDopo l’esfiltrazione, gli attaccanti hanno tentato di estorcere le aziende vittime minacciando la pubblicazione dei dati online, incassando circa 2,5 milioni di dollari in pagamenti di riscatto. Moucka ha inoltre guadagnato altri 495.000 dollari pubblicizzando parte dei dati rubati su forum criminali come #BreachForums e XSS.is. Un dettaglio particolarmente inquietante emerso dagli atti processuali riguarda una vittima estorta due volte: nella seconda occasione, Moucka avrebbe utilizzato dati personali relativi a un funzionario governativo ex ed ai suoi familiari per aumentare la pressione. Le perdite complessive stimate per le vittime ammontano a circa 9,5 milioni di dollari.

Prima dell’arresto, avvenuto nel novembre 2024 e seguito dall’estradizione negli Stati Uniti nel luglio 2025, Moucka aveva parlato con la testata 404 Media dicendosi consapevole dell’imminente cattura e ammettendo di aver distrutto prove in vista dell’arresto.

Due righe per i difensoriIl caso Snowflake ha ridefinito il modello di minaccia per i servizi SaaS e data warehouse: non serve violare il fornitore cloud se le identità dei suoi clienti restano esposte. Per i team di sicurezza le lezioni pratiche restano attuali due anni dopo i fatti:

Imporre l’autenticazione a più fattori su tutti gli account con accesso a piattaforme cloud e data warehouse, senza eccezioni per account di servizio o legacy.

Ruotare periodicamente le credenziali e trattare come compromesse quelle esposte in precedenti data breach, anche se risalenti a diversi anni prima.

Monitorare i mercati underground e i forum come BreachForums per individuare precocemente la messa in vendita di dati aziendali.

Validare i log di accesso alle piattaforme SaaS per individuare pattern anomali provenienti da IP o infrastrutture non riconducibili agli utenti abituali.

La condanna definitiva di Moucka, attesa il 27 ottobre, non chiude del tutto il caso: restano aperte le posizioni di altri complici legati alla campagna, a conferma che dietro un singolo nome pubblico si nasconde quasi sempre un’infrastruttura criminale collaborativa e distribuita.

Timeline e dati chiaveCampagna attiva: febbraio - ottobre 2024
Cluster di minaccia (Mandiant): UNC5537
Aziende clienti Snowflake colpite: almeno 165
Vettore d'accesso: credenziali valide esposte (alcune dal 2020), assenza di MFA
Vittime principali: AT&T (100M+ utenti, log chiamate/SMS), Ticketmaster/Live Nation (560M utenti),
Advance Auto Parts, Neiman Marcus, Santander, LendingTree, distretto scolastico USA
Guadagni stimati: ~2,5M USD (riscatti) + 495.000 USD (vendita dati underground)
Perdite vittime stimate: ~9,5M USD
Mercati underground utilizzati: BreachForums, XSS.is
Complice: John Erin Binns (Turchia, già legato all'hack T-Mobile 2021)
Arresto Moucka: novembre 2024 (Canada) - Estradizione: luglio 2025
Dichiarazione di colpevolezza: 5 agosto 2026
Sentenza attesa: 27 ottobre 2026 (fino a 32 anni di carcere)

Cinque anni e mezzo di carcere ciascuno. È questa la cifra con cui la giustizia britannica ha chiuso, almeno sul fronte penale, uno degli attacchi informatici più dirompenti mai subiti da un’infrastruttura critica del Regno Unito: l’intrusione del 2024 in Transport for London, l’authority che gestisce la mobilità dell’intera Londra. Owen Flowers, 18 anni, e Thalha Jubair, 20, sono stati condannati il 16 luglio 2026 dalla Woolwich Crown Court. Sono, secondo l’accusa, i primi ad essere condannati per la Section 3ZA del Computer Misuse Act — la fattispecie più grave della legge britannica sui crimini informatici — e la National Crime Agency (NCA) definisce il loro caso il più grande procedimento per cybercrime mai affrontato dai tribunali del Paese.

Chi sono Flowers e Jubair, e cosa hanno fattoI due sono descritti dalla NCA come membri di primo piano di Scattered Spider, il collettivo criminale tracciato anche come Octo Tempest, UNC3944 e 0ktapus, responsabile secondo gli inquirenti di centinaia di attacchi tra il 2022 e il 2025. La Crown Prosecution Service (CPS) è più cauta nell’attribuzione diretta, notando che gli imputati hanno rivendicato in vari momenti l’appartenenza al gruppo senza che questo costituisse, di per sé, la base dell’accusa.

L’intrusione in TfL è avvenuta tra il 31 agosto e il 3 settembre 2024. L’attacco ha reso inutilizzabili 148 sistemi dell’authority, costringendo tutti i 27.000 dipendenti a recarsi fisicamente in un ufficio per il reset delle credenziali — non essendo più possibile farlo da remoto in sicurezza. Sono stati compromessi anche il sistema di rimborsi Oyster (inclusi, per circa 5.000 persone, numeri di conto bancario e codici sort code), il servizio Dial-a-Ride per i cittadini con disabilità, il canale dei pagamenti digitali e le domande per le Oyster photocard agevolate per bambini e giovani. NCA e CPS stimano il danno complessivo, tra perdite e costi di ripristino, in 29 milioni di sterline.

Un rischio sistemico da 56 miliardi di sterlineIl dato più inquietante emerso dal processo riguarda ciò che sarebbe potuto succedere e non è successo. Secondo la ricostruzione dell’accusa, le conversazioni tra i due imputati suggerivano l’intenzione di cancellare l’accesso al termine dell’operazione, ma nessuno può dire con certezza cosa avessero realmente pianificato. La NCA stima che uno shutdown riuscito della rete di TfL — che gestisce in media 9 milioni di spostamenti al giorno — avrebbe potuto costare all’economia britannica fino a 56 miliardi di sterline. Uno scenario rimasto ipotetico solo perché TfL, rendendosi conto della compromissione, ha scelto di disattivare preventivamente la propria rete per contenere gli attaccanti.

I due si sono dichiarati colpevoli il 22 giugno 2026, il primo giorno del processo, evitando così il dibattimento. Hanno ammesso il reato sulla base di aver agito in modo “reckless” — sconsiderato — rispetto al rischio di causare o creare un pericolo significativo per il benessere umano, elemento costitutivo della Section 3ZA.

Come sono stati identificatiFlowers è stato arrestato per la prima volta il 6 settembre 2024, tre giorni dopo la fine dell’intrusione in TfL, nella sua abitazione a Walsall. Al momento dell’arresto, gli agenti NCA lo hanno sorpreso mentre era ancora attivo su due ulteriori obiettivi: le reti delle organizzazioni sanitarie statunitensi SSM Health Care Corporation e Sutter Health. Tra i dispositivi sequestrati — laptop, computer desktop, hard disk e chiavette USB — un portatile Acer conteneva uno screenshot della connettività di rete verso l’infrastruttura TfL e diversi video, registrati dallo stesso Flowers, che mostravano Jubair muoversi all’interno dei sistemi dell’authority londinese durante l’attacco. I due comunicavano in tempo reale su Telegram e condividevano uno spazio di lavoro online.

L’accusa ha dimostrato che Flowers era collegato al server remoto usato per lanciare tutte e tre le intrusioni, con prove ricavate dai suoi stessi dispositivi. Le informazioni che collegano Jubair all’attacco TfL sono state invece ottenute all’estero, con la collaborazione di autorità giudiziarie di altri Paesi — un dettaglio che la CPS non ha specificato ulteriormente. Jubair, arrestato il 16 settembre 2025, ha un secondo procedimento ancora aperto negli Stati Uniti: un atto d’accusa depositato nel New Jersey lo collega a circa 120 intrusioni di rete e almeno 47 vittime statunitensi tra maggio 2022 e settembre 2025, per oltre 115 milioni di dollari in riscatti pagati, incluse violazioni ai danni di un’infrastruttura critica USA e dei tribunali federali. Su questo fronte rischia fino a 95 anni di carcere; nessuna delle comunicazioni ufficiali diffuse finora affronta il tema dell’estradizione.

Scattered Spider è davvero finita?La NCA sostiene che l’azione contro i due abbia “sostanzialmente fermato” il gruppo, citando una valutazione di Microsoft secondo cui gli arresti ne avrebbero degradato in modo significativo la capacità operativa. Ma la stessa agenzia ammette che altri criminali potrebbero continuare a usare il marchio “Scattered Spider” per rivendicare nuovi attacchi. Non è un’ipotesi remota: a gennaio 2026 Mandiant ha documentato l’espansione di un’operazione di estorsione a marchio ShinyHunters che replica lo stesso modello — vishing verso i dipendenti, pagine di phishing per rubare credenziali SSO e codici MFA, enrollment di un dispositivo dell’attaccante per bypassare l’autenticazione multifattore.

È proprio questo il punto debole che accomuna la maggior parte dei casi riconducibili a Scattered Spider: non un exploit tecnico sofisticato, ma la manipolazione dei processi di help desk — reset password, gestione dei dispositivi MFA — con tecniche di social engineering telefonico mirate e ben documentate.

Due righe per i difensoriIl caso TfL resta un caso di scuola su come un’infrastruttura critica possa essere messa in ginocchio non da uno zero-day, ma da processi organizzativi vulnerabili al fattore umano. Alcune indicazioni pratiche per ridurre l’esposizione a gruppi con TTP simili a Scattered Spider:

Verificare sempre l’identità con procedure fuori banda (callback su numero verificato, verifica video) prima di eseguire reset password, modifiche MFA o enrollment di nuovi dispositivi richiesti telefonicamente all’help desk.

Limitare la possibilità per il personale di help desk di eseguire reset critici senza approvazione di un secondo operatore (four-eyes principle).

Monitorare enrollment MFA anomali, specialmente se avvengono subito dopo un reset password.

Coinvolgere le forze dell’ordine tempestivamente in caso di incidente: secondo la NCA, la collaborazione precoce di TfL è stata determinante per l’esito del procedimento.

Segmentare le reti operative critiche (biglietteria, pagamenti, servizi per l’utenza vulnerabile) da quelle amministrative, per limitare l’impatto di una compromissione laterale.

Fonti: The Hacker News, National Crime Agency.