Il phishing automatizzato, le frodi e lo sfruttamento dei dati in seguito a una violazione diventeranno operazioni perennemente attive in background

Milano, 15 dicembre 2025 – L’intelligenza artificiale agentica ridefinisce l’ecosistema criminale e presto permetterà di lanciare attacchi completamente automatizzati, che supereranno di gran lunga la potenza e la portata delle campagne ransomware e phishing attuali. Il dato emerge dall’ultimo report di Trend Micro, leader globale di cybersecurity, dal titolo “VibeCrime: Preparing Your Organization for the Next Generation of Agentic AI Cybercrime“.

Lo studio evidenzia che i cybercriminali utilizzeranno agenti AI specializzati, coordinati attraverso una regia centralizzata, al fine di condurre campagne su larga scala, adattive e altamente resilienti, riducendo al minimo l’intervento umano.

“L’intelligenza artificiale agentica fornisce ai criminali un arsenale pronto all’uso in grado di scalare, adattarsi e colpire anche senza l’intervento umano. Il rischio immediato non è un’improvvisa esplosione di crimini basati sull’AI, ma la lenta e inesorabile automazione degli attacchi che richiedevano capacità tecniche, tempo e sforzi. Questo sta già avvenendo”. Afferma Salvatore Marcis, Country Manager di Trend Micro Italia.

Gli highlight dello studio includono

• L’intelligenza artificiale agentica aumenterà enormemente il volume degli attacchi. Il phishing automatizzato, le frodi e lo sfruttamento dei dati in seguito a una violazione diventeranno operazioni perennemente attive in background
• Gli ecosistemi criminali passeranno da un modello cybercrime-as-a-service a uno cybercrime-as-a-servant, affidandosi ad agenti AI concatenati e a livelli di orchestrazione autonomi che gestiranno le attività criminali end-to-end
• Le piattaforme di difesa avranno bisogno di propri orchestratori e agenti autonomi per contrastare il cambiamento, altrimenti rischieranno di essere sopraffatte dalla portata e dalla velocità degli attacchi
• Nuove categorie di attacchi emergeranno molto più velocemente di quanto i difensori siano attualmente in grado di rilevare o mitigare

“L’Agentic AI ottimizzerà gli attacchi, amplificando i risultati di quelli con un basso ROI ed emergeranno nuovi modelli cybercriminali di business. Le aziende dovranno rivedere le strategie di security e investire in automazione e difese basate sull’intelligenza artificiale. Consigliamo di implementare un adeguato livello di resilienza prima che i cybercriminali industrializzino l’utilizzo dell’AI, altrimenti il rischio è di rimanere indietro nella corsa esponenziale agli armamenti, che separerà rapidamente le organizzazioni preparate da quelle che non lo sono.” Conclude Salvatore Marcis, Country Manager di Trend Micro Italia.

Ulteriori informazioni sono disponibili a questo link

Trend Micro

Trend Micro, leader globale di cybersecurity, contribuisce a rendere il mondo un posto più sicuro per lo scambio di informazioni digitali tra persone, organizzazioni pubbliche e private. Grazie all’IA e alle sue profonde conoscenze della cybersecurity, Trend protegge oltre 500.000 aziende e milioni di individui che utilizzano il cloud, le reti, gli endpoint e i più svariati dispositivi in tutto il mondo. Al centro della sua tecnologia c’è Trend Vision One, l’unica piattaforma di cybersecurity di livello enterprise potenziata dall’intelligenza artificiale, che centralizza la gestione dell’esposizione al rischio informatico e le operazioni di sicurezza, abilitando una protezione multilivello in ambienti on-premise, ibridi e multi-cloud.

L’impareggiabile intelligence sulle minacce di Trend permette alle organizzazioni di proteggersi proattivamente, ogni giorno, contro centinaia di milioni di minacce.

L'articolo Cybercrime e AI: l’intelligenza artificiale Agentica supererà presto le capacità di difesa proviene da Red Hot Cyber.

Sempre più sviluppatori stanno adottando strumenti supportati dall’intelligenza artificiale al fine di ottimizzare i loro processi lavorativi.

Ricordiamo che ultimamente Gartner ha emesso un avviso formale mettendo in guardia le organizzazioni sull’uso dei browser con funzionalità di intelligenza artificiale integrate, invitando le aziende a sospenderne temporaneamente l’adozione in ambito enterprise.

Gli analisti sottolineano che questi strumenti introducono rischi di sicurezza non necessari, poiché le configurazioni predefinite privilegiano l’usabilità e l’automazione a scapito della protezione dei dati, del controllo delle sessioni e della governance degli accessi.

Oggi parliamo di un racconto emerso su Reddit dove uno sviluppatore ha chiesto aiuto dopo aver utilizzato la CLI di Claude per ripulire i pacchetti in un vecchio repository, innescando un’eliminazione di dati a livello di sistema che ha quasi reso inutilizzabile il suo Mac.

La “CLI di Claude” è l’interfaccia a riga di comando (Command Line Interface) che permette di interagire con Claude (l’AI di Anthropic) direttamente dal terminale, senza passare da browser o interfacce grafiche. Consente di usare Claude come assistente AI locale/operativo per sviluppo, analisi e automazione.

Dopo un’analisi, la CLI di Claude ha identificato la causa principale: un comando malformato. Nello specifico, aveva eseguito: rm -rf tests/ patches/ plan/ ~/. La falla critica risiedeva nel carattere finale ~, che estendeva l’ambito di eliminazione alla directory home dell’utente.

Di conseguenza, venivano cancellate enormi quantità di dati, tra cui, a titolo esemplificativo ma non esaustivo, l’intera cartella Desktop, Documenti e Download, la directory Portachiavi (~/Library/Keychains) contenente le credenziali archiviate, l’archivio delle credenziali di Claude (~/.claude), i dati delle applicazioni e, di fatto, tutto il contenuto presente in /Users/.

Con la crescente adozione, aumentano anche le segnalazioni di guasti catastrofici causati da questi strumenti. In un precedente incidente, uno sviluppatore ha utilizzato Google Antigravity per cancellare una cache, ma l’intero disco D: è stato cancellato. L’intelligenza artificiale si è poi scusata, attribuendo il disastro a un proprio errore operativo, sebbene i file persi fossero irrecuperabili.

Alcuni sviluppatori partecipanti alla discussione hanno evidenziato che i colleghi delle loro società avevano sperimentato incidenti analoghi. L’origine del problema, secondo loro, risiede nell’incapacità di restringere la directory di lavoro della CLI di Claude, concedendo di fatto all’intelligenza artificiale un accesso senza limiti all’intera macchina. Questo tipo di approccio, mettevano in guardia, è intrinsecamente rischioso.

Recuperare i dati dopo una cancellazione di questo tipo è estremamente difficile. Tuttavia, l’incidente offre una lezione appresa a fatica. Successivamente, diversi ingegneri hanno suggerito di effettuare la CLI di Claude all’interno di un ambiente Docker containerizzato.

L’obiettivo è salvaguardare il sistema host usando la containerizzazione come strato di isolamento, in modo che, qualora l’IA dovesse riscontrare problemi, non sia in grado di eliminare file sulla macchina sottostante.

L'articolo Intelligenza Artificiale e CLI di Claude: cancellato l’intero disco D per errore proviene da Red Hot Cyber.

Recently, [Greg Kroah-Hartman] proclaimed the joyous news on the Linux Kernel Mailing List that stable General Purpose Interface Bus (GPIB) support has finally been merged into the 6.19 Linux kernel.

The GPIB is a short-range 8-bit, multi-master interface bus that was standardized as IEEE 488. It first saw use on HP laboratory equipment in the 1970s, but was soon after also used by microcomputers like the Commodore PET, Commodore 64 and others. Although not high-speed with just 8 MB/s, nor with galvanic isolation requirements, it’s an uncomplicated bus design that can be implemented without much of a blip on the BOM costs.

The IEEE 488 standard consists of multiple elements, with 488.1 defining the physical interface and 488.2 the electrical protocol. Over the decades a communication protocol was also developed, in the form of SCPI and its standardized way of communicating with a wide range of devices using a simple human-readable protocol.

Although the physical side of IEEE 488 has changed over the years, with Ethernet becoming a major alternative to the short GPIB cables and large connectors, the electrical protocol and SCPI alike are still very much relevant today. This latest addition to the Linux kernel should make it much easier to use both old and new equipment equipped with this bus.

hackaday.com/2025/12/16/after-…

ubiquità: no grazie
spieghiamoci, dunque:

noblogo.org/differx/ubiquita-n…

#annotazione #ubiquita #slowforward #EntropiaGratis

Introduction

Imagine you’re cruising down the highway in your brand-new electric car. All of a sudden, the massive multimedia display fills with Doom, the iconic 3D shooter game. It completely replaces the navigation map or the controls menu, and you realize someone is playing it remotely right now. This is not a dream or an overactive imagination – we’ve demonstrated that it’s a perfectly realistic scenario in today’s world.

The internet of things now plays a significant role in the modern world. Not only are smartphones and laptops connected to the network, but also factories, cars, trains, and even airplanes. Most of the time, connectivity is provided via 3G/4G/5G mobile data networks using modems installed in these vehicles and devices. These modems are increasingly integrated into a System-on-Chip (SoC), which uses a Communication Processor (CP) and an Application Processor (AP) to perform multiple functions simultaneously. A general-purpose operating system such as Android can run on the AP, while the CP, which handles communication with the mobile network, typically runs on a dedicated OS. The interaction between the AP, CP, and RAM within the SoC at the microarchitecture level is a “black box” known only to the manufacturer – even though the security of the entire SoC depends on it.

Bypassing 3G/LTE security mechanisms is generally considered a purely academic challenge because a secure communication channel is established when a user device (User Equipment, UE) connects to a cellular base station (Evolved Node B, eNB). Even if someone can bypass its security mechanisms, discover a vulnerability in the modem, and execute their own code on it, this is unlikely to compromise the device’s business logic. This logic (for example, user applications, browser history, calls, and SMS on a smartphone) resides on the AP and is presumably not accessible from the modem.

To find out, if that is true, we conducted a security assessment of a modern SoC, Unisoc UIS7862A, which features an integrated 2G/3G/4G modem. This SoC can be found in various mobile devices by multiple vendors or, more interestingly, in the head units of modern Chinese vehicles, which are becoming increasingly common on the roads. The head unit is one of a car’s key components, and a breach of its information security poses a threat to road safety, as well as the confidentiality of user data.

During our research, we identified several critical vulnerabilities at various levels of the Unisoc UIS7862A modem’s cellular protocol stack. This article discusses a stack-based buffer overflow vulnerability in the 3G RLC protocol implementation (CVE-2024-39432). The vulnerability can be exploited to achieve remote code execution at the early stages of connection, before any protection mechanisms are activated.

Importantly, gaining the ability to execute code on the modem is only the entry point for a complete remote compromise of the entire SoC. Our subsequent efforts were focused on gaining access to the AP. We discovered several ways to do so, including leveraging a hardware vulnerability in the form of a hidden peripheral Direct Memory Access (DMA) device to perform lateral movement within the SoC. This enabled us to install our own patch into the running Android kernel and execute arbitrary code on the AP with the highest privileges. Details are provided in the relevant sections.

Acquiring the modem firmware

The modem at the center of our research was found on the circuit board of the head unit in a Chinese car.

Circuit board of the head unit

Description of the circuit board components:

Using information about the modem’s hardware, we desoldered and read the embedded multimedia memory card, which contained a complete image of its operating system. We then analyzed the image obtained.

Remote access to the modem (CVE-2024-39431)

The modem under investigation, like any modern modem, implements several protocol stacks: 2G, 3G, and LTE. Clearly, the more protocols a device supports, the more potential entry points (attack vectors) it has. Moreover, the lower in the OSI network model stack a vulnerability sits, the more severe the consequences of its exploitation can be. Therefore, we decided to analyze the data packet fragmentation mechanisms at the data link layer (RLC protocol).

We focused on this protocol because it is used to establish a secure encrypted data transmission channel between the base station and the modem, and, in particular, it is used to transmit higher-layer NAS (Non-Access Stratum) protocol data. NAS represents the functional level of the 3G/UMTS protocol stack. Located between the user equipment (UE) and core network, it is responsible for signaling between them. This means that a remote code execution (RCE) vulnerability in RLC would allow an attacker to execute their own code on the modem, bypassing all existing 3G communication protection mechanisms.

3G protocol stack

The RLC protocol uses three different transmission modes: Transparent Mode (TM), Unacknowledged Mode (UM), and Acknowledged Mode (AM). We are only interested in UM, because in this mode the 3G standard allows both the segmentation of data and the concatenation of several small higher-layer data fragments (Protocol Data Units, PDU) into a single data link layer frame. This is done to maximize channel utilization. At the RLC level, packets are referred to as Service Data Units (SDU).

Among the approximately 75,000 different functions in the firmware, we found the function for handling an incoming SDU packet. When handling a received SDU packet, its header fields are parsed. The packet itself consists of a mandatory header, optional headers, and data. The number of optional headers is not limited. The end of the optional headers is indicated by the least significant bit (E bit) being equal to 0. The algorithm processes each header field sequentially, while their E-bits equal 1. During processing, data is written to a variable located on the stack of the calling function. The stack depth is 0xB4 bytes. The size of the packet that can be parsed (i.e., the number of headers, each header being a 2-byte entry on the stack) is limited by the SDU packet size of 0x5F0 bytes.

As a result, exploitation can be achieved using just one packet in which the number of headers exceeds the stack depth (90 headers). It is important to note that this particular function lacks a stack canary, and when the stack overflows, it is possible to overwrite the return address and some non-volatile register values in this function. However, overwriting is only possible with a value ending in one in binary (i.e., a value in which the least significant bit equals 1). Notably, execution takes place on ARM in Thumb mode, so all return addresses must have the least significant bit equal to 1. Coincidence? Perhaps.

In any case, sending the very first dummy SDU packet with the appropriate number of “correct” headers caused the device to reboot. However, at that moment, we had no way to obtain information on where and why the crash occurred (although we suspect the cause was an attempt to transfer control to the address 0xAABBCCDD, taken from our packet).

Gaining persistence in the system

The first and most important observation is that we know the pointer to the newly received SDU packet is stored in register R2. Return Oriented Programming (ROP) techniques can be used to execute our own code, but first we need to make sure it is actually possible.

We utilized the available AT command handler to move the data to RAM areas. Among the available AT commands, we found a suitable function – SPSERVICETYPE.

Next, we used ROP gadgets to overwrite the address 0x8CE56218 without disrupting the subsequent operation of the incoming SDU packet handling algorithm. To achieve this, it was sufficient to return to the function from which the SDU packet handler was called, because it was invoked as a callback, meaning there is no data linkage on the stack. Given that this function only added 0x2C bytes to the stack, we needed to fit within this size.

Stack overflow in the context of the operating system

Having found a suitable ROP chain, we launched an SDU packet containing it as a payload. As a result, we saw the output 0xAABBCCDD in the AT command console for SPSERVICETYPE. Our code worked!

Next, by analogy, we input the address of the stack frame where our data was located, but it turned out not to be executable. We then faced the task of figuring out the MPU settings on the modem. Once again, using the ROP chain method, we generated code that read the MPU table, one DWORD at a time. After many iterations, we obtained the following table.

The table shows what we suspected – the code section is only mapped for execution. An attempt to change the configuration resulted in another ROP chain, but this same section was now mapped with write permissions in an unused slot in the table. Because of MPU programming features, specifically the presence of the overlap mechanism and the fact that a region with a higher ID has higher priority, we were able to write to this section.

All that remained was to use the pointer to our data (still stored in R2) and patch the code section that had just been unlocked for writing. The question was what exactly to patch. The simplest method was to patch the NAS protocol handler by adding our code to it. To do this, we used one of the NAS protocol commands – MM information. This allowed us to send a large amount of data at once and, in response, receive a single byte of data using the MM status command, which confirmed the patching success.

As a result, we not only successfully executed our own code on the modem side but also established full two-way communication with the modem, using the high-level NAS protocol as a means of message delivery. In this case, it was an MM Status packet with the cause field equaling 0xAA.

However, being able to execute our own code on the modem does not give us access to user data. Or does it?

The full version of the article with a detailed description of the development of an AR exploit that led to Doom being run on the head unit is available on ICS CERT website.

As of Dec. 15, the U.S. Press Freedom Tracker has documented 32 detainments or charges against journalists in the U.S. — 28 of those at immigration-related protests — according to a new report released by the Freedom of Press Foundation (FPF) project this week.

The report notes how, unlike most years, the majority of journalists were released without charges or had them soon dropped, with law enforcement instead focusing on deterring news gathering rather than pursuing charges.

• Read the Tracker's 2025 arrest report

Tracker Senior Reporter Stephanie Sugars, who authored the report, said it was “shocking” to see the sharp increase in the number of journalists released without being charged.

“While perhaps a sign that officers know the journalists cannot be charged as protesters, each detention pulls eyes and ears from often chaotic protest scenes, and that may well be the point,” Sugars said.

For journalist Dave Decker, being arrested at an anti-deportation demonstration in Miami last month and held in custody for more than 30 hours was a way to “put the brakes on press freedom,” he told the Tracker.

“News is only news for a couple of hours, when it’s breaking like that,” Decker said. “I would say that there were no wires out there, there were no local people, there were no stand-ups, no TV, no helicopter. There was none of that there. So I was literally the only journalist out there. They effectively stopped the news from getting out.”

In 2025, more than 30 journalists were detained or charged for doing their jobs.

freedom.press/issues/report-mo…

Reposted from the US Pirate Party.

Weeks of voting has come to a conclusion, and it is official: Boston, MA will be the host city for the 2026 Pirate National Conference, taking place on June 6th, 2026.

A single round knockout elimination tournament featuring twelve cities has concluded with Boston defeating fellow finalist city Vicksburg, MS.

The following cities, in addition to Vicksburg, shall remain in permanent consideration for a future conference host city:

• Albuquerque, NM
• Chicago, IL
• Las Vegas, NV
• Louisville, KY
• Mobile, AL
• New Orleans, LA
• Plattsburgh, NY
• Portland, OR
• Providence, RI
• San Francisco, CA*
• Seattle, WA

*San Francisco was host city for the 2025 Pirate National Conference and thus was not in consideration for the 2026 conference
We promised a conference on a boat, and by hell or high water, we will get ourselves a conference on a boat.

Boston being selected as host city not only provides us with an instantly recognizable location, but one so deeply entrenched in U.S. history and struggles against tyranny.

As well, this allows us to honor the Massachusetts Pirate Party properly. The MAPP features some of the hardest working and most dedicated Pirates in the country, so having our conference, one which will mark twenty years of the United States Pirate Party, in their home state is fitting.

There wouldn’t be a twenty years old Pirate Party in existence today without the work of the Massachusetts Pirate Party. For that, I could not think of a more perfect setting.

We look forward to providing you with more details about our conference as the weeks go on. In the meantime, we look forward to seeing you in Boston (or online, since it’s a in-person-online hybrid conference).

Boston, Victory is Arrrs.

masspirates.org/blog/2025/12/1…

Weeks of voting has come to a conclusion, and it is official: Boston, MA will be the host city for the 2026 Pirate National Conference, taking place on June 6th, 2026.

A single round knockout elimination tournament featuring twelve cities has concluded with Boston defeating fellow finalist city Vicksburg, MS.

The following cities, in addition to Vicksburg, shall remain in permanent consideration for a future conference host city:

• Albuquerque, NM
• Chicago, IL
• Las Vegas, NV
• Louisville, KY
• Mobile, AL
• New Orleans, LA
• Plattsburgh, NY
• Portland, OR
• Providence, RI
• San Francisco, CA*
• Seattle, WA

*San Francisco was host city for the 2025 Pirate National Conference and thus was not in consideration for the 2026 conference
We promised a conference on a boat, and by hell or high water, we will get ourselves a conference on a boat.

Boston being selected as host city not only provides us with an instantly recognizable location, but one so deeply entrenched in U.S. history and struggles against tyranny.

As well, this allows us to honor the Massachusetts Pirate Party properly. The MAPP features some of the hardest working and most dedicated Pirates in the country, so having our conference, one which will mark twenty years of the United States Pirate Party, in their home state is fitting.

There wouldn’t be a twenty years old Pirate Party in existence today without the work of the Massachusetts Pirate Party. For that, I could not think of a more perfect setting.

We look forward to providing you with more details about our conference as the weeks go on. In the meantime, we look forward to seeing you in Boston (or online, since it’s a in-person-online hybrid conference).

Boston, Victory is Arrrs.

uspirates.org/the-2026-pirate-…