Although Charles Hall conducted his first successful run of the Hall-Héroult aluminium smelting process in the woodshed behind his house, it has ever since remained mostly out of reach of home chemists. It does involve electrolysis at temperatures above 1000 ℃, and can involve some frighteningly toxic chemicals, but as [Maurycy Z] demonstrates, an amateur can now perform it a bit more conveniently than Hall could.

[Maurycy] started by finding a natural source of aluminium, in this case aluminosilicate clay. He washed the clay and soaked it in warm hydrochloric acid for two days to extract the aluminium as a chloride. This also extracted quite a bit of iron, so [Maurycy] added sodium hydroxide to the solution until both aluminium and iron precipitated as hydroxides, added more sodium hydroxide until the aluminium hydroxide redissolved, filtered the solution to remove iron hydroxide, and finally added hydrochloric acid to the solution to precipitate aluminium hydroxide. He heated the aluminium hydroxide to about 800 ℃ to decompose it into the alumina, the starting material for electrolysis.

To turn this into aluminium metal, [Maurycy] used molten salt electrolysis. Alumina melts at a much higher temperature than [Maurycy]’s furnace could reach, so he used cryolite as a flux. He mixed this with his alumina and used an electric furnace to melt it in a graphite crucible. He used the crucible itself as the cathode, and a graphite rod as an anode. He does warn that this process can produce small amounts of hydrogen fluoride and fluorocarbons, so that “doing the electrolysis without ventilation is a great way to poison yourself in new and exciting ways.” The first run didn’t produce anything, but on a second attempt with a larger anode, 20 minutes of electrolysis produced 0.29 grams of aluminium metal.

[Maurycy]’s process follows the industrial Hall-Héroult process quite closely, though he does use a different procedure to purify his raw materials. If you aren’t interested in smelting aluminium, you can still cast it with a microwave oven.

hackaday.com/2025/07/22/the-ha…

While it might not be accurate to say VHS is dead, it’s certainly not a lively format. It continues on in undeath thanks to dedicated collectors and hobbyists, some of whom may be tempted to lynch Reddit user [CommonKingfisher] for embedding a video player inside a VHS tape.
Miniaturization in action. The video player probably cost about the same as the original VHS when you account for inflation.
The hack started with a promotional video card via Ali Express, which is a cheap enough way to get a tiny LCD player MP4 playing micro. As you can see, there was plenty of room in the tape for the guts of this. The tape path is obviously blocked, so the tape is not playable in this format. [CommonKingfisher] claims the hack is “reversible” but since he cut a window for the LCD out of the casing of the cassette, that’s going to be pretty hard to undo. On the other hand, the ultrasonic cutter he used did make a very clean cut, and that would help with reversibility.

The fact that the thing is activated by a magnetic sensor makes us worry for the data on that tape, too, whether or not the speaker is a peizo. Ultimately it doesn’t really matter; in no universe was this tape the last surviving copy of “The Matrix”, and it’s a lot more likely this self-playing “tape” gets watched than the VHS was going to be. You can watch it yourself in the demo video embedded below.

VHS nostalgia around here usually involves replicating the tape experience, rather than repurposing the tape. We’re grateful to [George Graves] for the tip. Tips of all sorts are welcome on our friendly neighborhood tips line.

youtube.com/embed/BYrY3nFrsho?…

hackaday.com/2025/07/22/video-…

We did explicitly ask for projects that use a 555 timer for the One Hertz Challenge, but we weren’t expecting the 555 to be the project. Yet, here we are, with [matt venn]’s Open Source 1Hz Blinky, that blinks a light with a 555 timer… but not one you’d get from Digikey.

Hooking a 555 to blink an LED at one hertz is a bog-simple, first-electronics-project type of exercise, unless you have to make the 555 first. Rather than go big, as we have seen before, [matt venn] goes very small, with a 555 implemented on a tiny sliver of Tiny Tapeout 6.

We’ve covered projects using that tapeout before, but in case you missed it, Tiny Tapeout gives space to anyone to produce ASICs on custom silicon using an open Process Design Kit, and we have [matt venn] to thank for it. The Tiny Tapeout implementation of the 555 was actually designed by [Vincent Fusco].

Of course wiring it up is a bit more complicated than dropping in a 555 timer to the circuit: the Tiny Tapeout ASIC must be configured to use that specific project using its web interface. There’s a demo video embedded below, with some info about the project– it’s not just a blinking LED, so it’s worth seeing. The output isn’t exactly One Hertz, so it might not get the nod in the Timelord category, but it’s going to be a very strong competitor for other 555-based projects– of which we could really use more, hint-hint. You’ve got until August 19th, if you think you can use a 555 to do something more interesting than blink an LED.

youtube.com/embed/QrB6msn3UzM?…

hackaday.com/2025/07/22/2025-o…

Nel corso degli ultimi mesi, YouTube ha intensificato la sua attività di contrasto contro campagne di disinformazione e operazioni di influenza coordinate, rimuovendo un numero considerevole di canali legati a vari paesi. Tra questi, spiccano 43 canali chiusi per attività legate alla Turchia: la campagna diffondeva contenuti in lingua turca a sostegno del Partito della Vittoria. Parallelamente, 12 canali, un account pubblicitario, un account AdSense e nove domini sono stati bloccati per una campagna pro-Romania a favore di un partito politico specifico.

Le attività riconducibili alla Russia hanno portato alla chiusura di centinaia di canali. Solo in alcuni esempi, sono stati chiusi 1.045 canali e bloccati due domini per una campagna collegata a una società di consulenza russa; ulteriori 507 canali sono stati rimossi per contenuti pro-Russia e critici verso Ucraina e Occidente; altri 392 canali, sempre riconducibili a una società di consulenza russa, sono stati eliminati per motivi analoghi. A questi si aggiungono decine di altri canali chiusi per campagne in diverse lingue, tra cui inglese, francese, spagnolo, ucraino e polacco.

Anche la Repubblica Popolare Cinese (PRC) è stata coinvolta in modo massiccio. In particolare, YouTube ha chiuso 1.545 canali per una rete inautentica che pubblicava contenuti in cinese e inglese su Cina e affari esteri statunitensi, e ulteriori 3.592 canali nei mesi successivi per attività simili. Nel mese di giugno, sono stati rimossi altri 2.598 canali e bloccato un dominio, sempre per operazioni legate alla PRC. Questi interventi confermano trend già documentati in precedenti report.

Non sono mancate azioni contro campagne legate ad altri paesi. In Azerbaijan sono stati chiusi 356 canali in un caso, 457 in un altro, e ulteriori 228 canali per campagne che diffondevano contenuti critici verso l’Armenia e oppositori del governo azero. In Iran sono stati chiusi 12 canali per contenuti a favore del governo iraniano e della Palestina e critici verso Israele; inoltre, sono stati bloccati due domini per campagne in arabo critiche verso Stati Uniti, Israele e Occidente.

Infine, YouTube ha agito anche contro campagne più circoscritte: quattro canali chiusi per attività legate a Israele con contenuti critici verso la Palestina; un canale e un dominio bloccati in Ghana per una campagna legata alle elezioni presidenziali; e quattro canali chiusi per attività pro-Cina e critiche verso le Filippine. Questi interventi, realizzati tra aprile e giugno, testimoniano la costante attività della piattaforma contro la disinformazione globale e le reti inautentiche.

L'articolo Pulizia storica su YouTube: eliminati oltre 10.000 canali collegati a Mosca, Pechino e Teheran proviene da il blog della sicurezza informatica.

We’ve all felt the frustration of cheap consumer electronics — especially when they aren’t actually cheap. How many of us have said “Who designed this crap? I could do better with an Arduino!” while resisting the urge to drop that new smart doorbell in the garbage disposal?

It’s an all-too familiar thought, and when it passed through [Mathieu]’s head while he was resetting the time and changing the batteries in his son’s power-hungry Pokémon alarm clock for the umpteenth time, he decided to do something about it.

The only real design requirement, imposed by [Mathieu]’s son, was that the clock’s original shell remained. Everything else, including the the controller and “antique” LCD could go. He ripped out the internals and installed an ESP32, allowing the clock to automatically sync to network time in the event of power loss. The old-school LCD was replaced with a modern, full-color TFT LCD which he scored on AliExpress for a couple of Euros.

Rather than just showing the time, the new display sports some beautiful pixel art by Woostarpixels, which [Mathieu] customized to have day and nighttime versions, even including the correct moon phase. He really packed as much into the ESP32 as possible, using 99.6% of its onboard 4 MB of flash. Code is on GitHub for the curious. All in all, the project is a multidisciplinary work of art, and it looks well-built enough to be enjoyed for years to come.

youtube.com/embed/mHJeMg9Hzjg?…

hackaday.com/2025/07/22/2025-o…

Picture this: it’s January 19th, 2038, at exactly 03:14:07 UTC. Somewhere in a data center, a Unix system quietly ticks over its internal clock counter one more time. But instead of moving forward to 03:14:08, something strange happens. The system suddenly thinks it’s December 13th, 1901. Chaos ensues.

Welcome to the Year 2038 problem. It goes by a number of other fun names—the Unix Millennium Bug, the Epochalypse, or Y2K38. It’s another example of a fundamental computing limit that requires major human intervention to fix.

By and large, the Y2K problem was dealt with ahead of time for critical systems. An amusing example of a Y2K failure was this sign at the École Centrale de Nantes, pictured on January 3, 2000. Credit: Bug de l’an 2000, CC BY-SA 3.0
The Y2K problem was simple enough. Many computing systems stored years as two-digit figures, often for the sake of minimizing space needed on highly-constrained systems, back when RAM and storage, or space on punch cards, were strictly limited. This generally limited a system to understanding dates from 1900 to 1999; when storing the year 2000 as a two-digit number, it would instead effectively appear as 1900 instead. This promised to cause chaos in all sorts of ways, particularly in things like financial systems processing transactions in the year 2000 and onwards.

The problem was first identified in 1958 by Bob Bemer, who was working on longer time scales with genealogical software. Awareness slowly grew through the 1980s and 1990s as the critical date approached and things like long-term investment bonds started to butt up against the year 2000. Great effort was expended to overhaul and update important computer systems to enable them to store dates in a fashion that would not loop around back to 1900 after 1999.

Unlike Y2K, which was largely about how dates were stored and displayed, the 2038 problem is rooted in the fundamental way Unix-like systems keep track of time. Since the early 1970s, Unix systems have measured time as the number of seconds elapsed since January 1st, 1970, at 00:00:00 UTC. This moment in time is known as the “Unix epoch.” Recording time in this manner seemed like a perfectly reasonable approach at the time. It gave systems a simple, standardized way to handle timestamps and scheduled tasks.

The trouble is that this timestamp was traditionally stored as a signed 32-bit integer. Thanks to the magic of binary, a signed 32-bit integer can represent values from -2,147,483,648 to 2,147,483,647. When you’re counting individual seconds, that gives you about plus and minus 68 years either side of the epoch date. Do the math, and you’ll find that 2,147,483,647 seconds after January 1st, 1970 lands you at 03:14:07 UTC on January 19th, 2038. That’s the final time that can be represented using the 32-bit signed integer, having started at the Unix epoch.
The Unix time integer immediately prior to overflow.
What happens next isn’t pretty. When that counter tries to increment one more time, it overflows. In two’s complement arithmetic, the first bit is a signed bit. Thus, the time stamp rolls over from 2,147,483,647 to -2,147,483,648. That translates to December 13th, 1901. In January 2038, this will be roughly 136 years in the past.
Unix time after the 32-bit signed integer has overflowed.
For an unpatched system using a signed 32-bit integer to track Unix time, the immediate consequences could be severe. Software could malfunction when trying to calculate time differences that suddenly span more than a century in the wrong direction, and logs and database entries could quickly become corrupted as operations are performed on invalid dates. Databases might reject “historical” entries, file systems could become confused about which files are newer than others, and scheduled tasks might cease to run or run at inappropriate times.

This isn’t just some abstract future problem. If you grew up in the 20th century, it might sound far off—but 2038 is just 13 years away. In fact, the 2038 bug is already causing issues today. Any software that tries to work with dates beyond 2038—such as financial systems calculating 30-year mortgages—could fall over this bug right now.
In 2012, NetBSD 6.0 introduced 64-bit Unix time across both 32-bit and 64-bit architectures. There is also a binary compatibility layer for running older applications, though they will still suffer the year 2038 problem internally. Credit: NetBSD changelog
The obvious fix is to move from 32-bit to 64-bit timestamps. A 64-bit signed integer can represent timestamps far into the future—roughly 292 billion years in fact, which should cover us until well after the heat death of the universe. Until we discover a solution for that fundamental physical limit, we should be fine.

Indeed, most modern Unix-based operating systems have already made this transition. Linux moved to 64-bit time_t values on 64-bit platforms years ago, and since version 5.6 in 2020, it supports 64-bit timestamps even on 32-bit hardware. OpenBSD has used 64-bit timestamps since May 2014, while NetBSD made the switch even earlier in 2012.

Most other modern Unix filesystems, C compilers, and database systems have switched over to 64-bit time by now. With that said, some have used hackier solutions that kick the can down the road more than fixing the problem for all of foreseeable time. For example, the ext4 filesystem uses a complicated timestamping system involving nanoseconds that runs out in 2446. XFS does a little better, but its only good up to 2486. Meanwhile, Microsoft Windows uses its own 64-bit system tracking 100-nanosecond intervals since 1 January 1601. This will overflow as soon as the year 30,828.

The challenge isn’t just in the operating systems, though. The problem affects software and embedded systems, too. Most things built today on modern architectures will probably be fine where the Year 2038 problem is concerned. However, things that were built more than a decade ago that were intended to run near-indefinitely could be a problem. Enterprise software, networking equipment, or industrial controllers could all trip over the Unix date limit come 2038 if they’re not updated beforehand. There are also obscure dependencies and bits of code out there that can cause even modern applications to suffer this problem if you’re not looking out for them.
In 2022, a coder called Silent identified a code snippet that was reintroducing the Year 2038 bug to new software. Credit: Silent’s blog via screenshot
The real engineering challenge lies in maintaining compatibility during the transition. File formats need updating and databases must be migrated without mangling dates in the process. For systems in the industrial, financial, and commercial fields where downtime is anathema, this can be very challenging work. In extreme cases, solving the problem might involve porting a whole system to a new operating system architecture, incurring huge development and maintenance costs to make the changeover.

The 2038 problem is really a case study in technical debt and the long-term consequences of design decisions. The Unix epoch seemed perfectly reasonable in 1970 when 2038 felt like science fiction. Few developing those systems thought a choice made back then would have lasting consequences over 60 years later. It’s a reminder that today’s pragmatic engineering choices might become tomorrow’s technical challenges.

The good news is that most consumer-facing systems will likely be fine. Your smartphone, laptop, and desktop computer almost certainly use 64-bit timestamps already. The real work is happening in the background—corporate system administrators updating server infrastructure, embedded systems engineers planning obsolescence cycles, and software developers auditing code for time-related assumptions. The rest of us just get to kick back and watch the (ideally) lack of fireworks as January 19, 2038 passes us by.

hackaday.com/2025/07/22/the-ep…

L’ultimo aggiornamento di sicurezza per Windows Server 2019, rilasciato l’8 luglio, contiene un fastidioso problema che può compromettere il funzionamento di interi cluster. L’aggiornamento, numero KB5062557, causa errori nel Servizio Cluster, un componente fondamentale che gestisce i nodi di elaborazione distribuita e ne garantisce l’interazione fluida. Dopo l’installazione della patch, il sistema potrebbe iniziare a comportarsi in modo imprevedibile: il Servizio Cluster si avvia, quindi si blocca immediatamente, i nodi si disconnettono dal cluster, entrano in stato di isolamento e le macchine virtuali in questa infrastruttura si riavviano ripetutamente.

Secondo una notifica interna ottenuta da BleepingComputer, il problema si manifesta con errori persistenti con codice evento 7031 nei log di sistema. In pratica, ciò significa che il cluster è instabile, le macchine si comportano in modo irregolare e l’amministratore riscontra una serie di problemi anziché ricevere un aggiornamento di routine. La situazione è particolarmente problematica per chi utilizza BitLocker su dischi Cluster Shared Volumes (CSV): tali configurazioni sono soggette a ulteriori errori quando si tenta di riconnettere i nodi al cluster.

Microsoft conferma il problema, lo definisce noto e invita i clienti a non farsi prendere dal panico, ma non offre ancora soluzioni indipendenti. Invece di una patch universale, l’azienda offre soluzioni individuali: se un’organizzazione riscontra il problema descritto, è necessario contattare il servizio di supporto aziendale Microsoft. Solo tramite questo servizio è possibile ottenere istruzioni temporanee su come mitigare le conseguenze e aggirare il bug.

Non esiste una tempistica specifica per il rilascio di una correzione completa. Microsoft chiarisce solo che sta lavorando per includere la soluzione definitiva in una delle prossime versioni di Windows Update. Dopodiché, tutte le misure temporanee ricevute dal supporto tecnico diventeranno irrilevanti e non sarà necessario applicarle.

Non è la prima volta che gli aggiornamenti di Windows Server causano problemi. All’inizio di luglio, Microsoft ha risolto un altro grave problema che impediva a WSUS (Windows Server Update Services) di sincronizzarsi correttamente con Microsoft Update, bloccando l’installazione di nuovi aggiornamenti. Un’altra conseguenza dell’aggiornamento di giugno è stato il blocco del servizio DHCP su alcuni server: questo problema è stato fortunatamente risolto nella build cumulativa di luglio.

Nel frattempo, gli amministratori che gestiscono Windows Server 2019 dovrebbero prestare la massima attenzione durante l’installazione dell’ultimo aggiornamento, soprattutto se l’infrastruttura utilizza il clustering e la crittografia dei volumi BitLocker. Prima di aggiornare i sistemi di produzione, è meglio verificare se questo possa causare un disastro improvviso.

L'articolo Aggiornamento Windows Server 2019: problemi al servizio cluster e BitLocker proviene da il blog della sicurezza informatica.

Wall warts. Plug mounted power supplies that turn mains voltage into low voltage DC on a barrel jack to power a piece of equipment. We’ve all got a load of them for our various devices, most of us to the extent that it becomes annoying. [Mikeselectricstuff] has the solution, in the shape of a USB-C PD power supply designed to replace a barrel jack socket on a PCB.

The video below provides a comprehensive introduction to the topic before diving into the design. The chip in question is the CH224K, and he goes into detail on ordering the boards for yourself. As the design files are freely available, we wouldn’t be surprised if they start turning up from the usual suppliers before too long.

We like this project and we can see that it would be useful, after all it’s easy to end up in wall wart hell. We’ve remarked before that USB-C PD is a new technology done right, and this is the perfect demonstration of its potential.

youtube.com/embed/BElU9LPbaA8?…

hackaday.com/2025/07/22/usb-c-…

It hasn’t been that long since humans figured out how to create power grids that integrated multiple generators and consumers. Ever since AC won the battle of the currents, grid operators have had to deal with the issues that come with using AC instead of the far less complex DC. Instead of simply targeting a constant voltage, generators have to synchronize with the frequency of the alternating current as it cycles between positive and negative current many times per second.

Complicating matters further, the transmission lines between generators and consumers, along with any kind of transmission equipment on the lines, add their own inductive, capacitive, and resistive properties to the system before the effects of consumers are even tallied up. The result of this are phase shifts between voltage and current that have to be managed by controlling the reactive power, lest frequency oscillations and voltage swings result in a complete grid blackout.

Flowing Backwards

We tend to think of the power in our homes as something that comes out of the outlet before going into the device that’s being powered. While for DC applications this is essentially true – aside from fights over which way DC current flows – for AC applications the answer is pretty much a “It’s complicated”. After all, the primary reason why we use AC transmission is because transformers make transforming between AC voltages easy, not because an AC grid is easier to manage.
Image showing the instantaneous electric power in AC systems and its decomposition into active and reactive power; when the current lags the voltage 50 degrees. (Credit: Jon Peli Oleaga)
What exactly happens between an AC generator and an AC load depends on the characteristics of the load. A major part of these characteristics is covered by its power factor (PF), which describes the effect of the load on the AC phase. If the PF is 1, the load is purely resistive with no phase shift. If the PF is 0, it’s a purely reactive load and no net current flows. Most AC-powered devices have a power factor that’s somewhere between 0.5 to 0.99, meaning that they appear to be a mixed reactive and resistive load.
The power triangle, showing the relationship between real, apparent and reactive power. (Source: Wikimedia)
PF can be understood in terms of the two components that define AC power, being:

• Apparent Power (S, in volt-amperes or VA) and
• Real Power (P, in watts).

The PF is defined as the ratio of P to S (i.e. `PF = P / S). Reactive Power (Q, in var) is easily visualized as the angle theta (Θ) between P and S if we put them as respectively the leg and hypotenuse of a right triangle. Here Θ is the phase shift by which the current waveform lags the voltage. We can observe that as the phase shift increases, the apparent power increases along with reactive power. Rather than being consumed by the load, reactive power flows back to the generator, which hints at why it’s such a problematic phenomenon for grid-management.

From the above we can deduce that the PF is 1.0 if S and P are the same magnitude. Although P = I × V gets us the real power in watts, it is the apparent power that is being supplied by the generators on the grid, meaning that reactive power is effectively ‘wasted’ power. How concerning this is to you as a consumer mostly depends on whether you are being billed for watts or VAs consumed, but from a grid perspective this is the motivation behind power factor correction (PFC).

This is where capacitors are useful, as they can correct the low PF on inductive loads like electric motors, and vice versa with inductance on capacitive loads. As a rule of thumb, capacitors create reactive power, while inductors consume reactive power, meaning that for PFC the right capacitance or inductance has to be added to get the PF as close to 1.0 as possible. Since an inductor absorbs the excess (reactive) power and a capacitor supplies reactive power, if both are balanced 1:1, the PF would be 1.0.

In the case of modern switching-mode power supplies, automatic power factor correction (APFC) is applied, which switch in capacitance as needed by the current load. This is, in miniature, pretty much what the full-scale grid does throughout the network.

Traditional Grids

Magnetically controlled shunt reactor (MCSR). (Credit: Tayosun, Wikimedia)
Based on this essential knowledge, local electrical networks were expanded from a few streets to entire cities. From there it was only a matter of time before transmission lines turned many into few, with soon transmission networks spanning entire continents. Even so, the basic principles remain the same, and thus the methods available to manage a power grid.

Spinning generators provide the AC power, along with either the creation or absorption of reactive power on account of being inductors with their large wound coils, depending on their excitation level. Since transformers are passive devices, they will always absorb reactive power, while both overhead and underground transmission lines start off providing reactive power, overhead lines start absorbing reactive power if overloaded.

In order to keep reactive power in the grid to a healthy minimum, capacitive and inductive loads are switched in or out at locations like transmission lines and switchyards. The inductive loads often taken the form of shunt reactors – basically single winding transformers – and shunt capacitors, along with active devices like synchronous condensers that are effectively simplified synchronous generators. In locations like substations the use of tap changers enables fine-grained voltage control to ease the load on nearby transmission lines. Meanwhile the synchronous generators at thermal plants can be kept idle and online to provide significant reactive power absorption capacity when not used to actively generate power.

Regardless of the exact technologies employed, these traditional grids are characterized by significant amounts of reactive power creation and absorption capacity. As loads join or leave the grid every time that consumer devices are turned off and on, the grid manager (transmission system operator, or TSO) adjusts the state of these control methods. This keeps the grid frequency and voltage within their respective narrowly defined windows.

Variable Generators

Over the past few years, most newly added generating capacity has come in the form of weather-dependent variable generators that use grid-following converters. These devices take the DC power from generally PV solar and wind turbine farms and convert them into AC. They use a phase-locked loop (PLL) to synchronize with the grid frequency, to match this AC frequency and the current voltage.

Unfortunately, these devices do not have the ability to absorb or generate reactive power, and instead blindly follow the current grid frequency and voltage, even if said grid was going through reactive power-induced oscillations. Thus instead of damping these oscillations and any voltage swings, these converters serve to amplify these issues. During the 2025 Iberian Peninsula blackout, this was identified as one of the primary causes by the Spanish TSO.

Ultimately AC power grids depend on solid reactive power management, which is why the European group of TSOs (ENTSO-E) already recommended in 2020 that grid-following converters should get replaced with grid-forming converters. These feature the ability absorb and generate reactive power through the addition of features like energy storage and are overall significantly more useful and robust when it comes to AC grid management.

Although AC doesn’t rule the roost any more in transmission networks, with high-voltage DC now the more economical option for long distances, the overwhelming part of today’s power grids still use AC. This means that reactive power management will remain one of the most essential parts of keeping power grids stable and people happy, until the day comes when we will all be switching back to DC grids, year after the switch to AC was finally completed back in 2007.

hackaday.com/2025/07/22/power-…

La nuova famiglia di malware LameHug utilizza il Large Language Model (LLM) per generare comandi che vengono eseguiti sui sistemi Windows compromessi. Come riportato da Bleeping Computer, LameHug è scritto in Python e utilizza l’API Hugging Face per interagire con il Qwen 2.5-Coder-32B-Instruct LLM, che può generare comandi in base ai prompt forniti. Si noti che l’utilizzo dell’infrastruttura Hugging Face può contribuire a garantire la segretezza delle comunicazioni e che l’attacco rimarrà inosservato per un periodo di tempo più lungo.

Questo modello, creato da Alibaba Cloud, èopen source e progettato specificamente per la generazione di codice, il ragionamento e l’esecuzione di istruzioni di programmazione. Può convertire descrizioni in linguaggio naturale in codice eseguibile (in più linguaggi) o comandi shell. LameHug è stato scoperto il 10 luglio di quest’anno, quando dipendenti delle autorità esecutive ucraine hanno ricevuto email dannose inviate da account hackerati.

Le email contenevano un archivio ZIP con il loader di LameHug, camuffato dai file Attachment.pif, AI_generator_uncensored_Canvas_PRO_v0.9.exe e image.py. Nei sistemi infetti, LameHug aveva il compito di eseguire comandi per effettuare ricognizioni e rubare dati generati dinamicamente tramite richieste a LLM.
Prompt per la generazione di comandi
Le informazioni di sistema raccolte venivano salvate in un file di testo (info.txt) e il malware cercava ricorsivamente documenti in cartelle come Documenti, Desktop, Download, per poi trasmettere i dati raccolti ai suoi operatori tramite richieste SFTP o HTTP POST. La pubblicazione sottolinea che LameHug è il primo malware documentato che utilizza LLM per eseguire attività dannose.

Sempre più spesso vediamo una preoccupante integrazione tra malware e intelligenza artificiale, che rende le minacce informatiche più sofisticate, flessibili e difficili da individuare. L’uso dei Large Language Model come “motori” per generare in tempo reale comandi dannosi permette agli attaccanti di adattarsi rapidamente, di diversificare le tecniche di attacco e di ridurre la rilevabilità da parte dei sistemi di difesa tradizionali.

LameHug rappresenta un chiaro esempio di questa nuova generazione di minacce: malware che non solo automatizzano le attività dannose, ma sono anche in grado di “ragionare” e rispondere dinamicamente agli input, sfruttando la potenza degli LLM. Un fenomeno che segna l’inizio di una nuova fase nelle minacce informatiche, in cui l’AI non è solo uno strumento difensivo, ma diventa parte integrante e attiva dell’arsenale offensivo dei cyber criminali.

L'articolo Arriva LameHug: il malware che utilizza l’AI per rubare i dati sui sistemi Windows proviene da il blog della sicurezza informatica.

Secondo quanto riportato guancha.cn e da altri media, Louis Vuitton ha recentemente inviato una comunicazione ai propri clienti per informarli di una fuga di dati che ha interessato circa 420.000 clienti a Hong Kong. I dati trapelati comprendono nomi, numeri di passaporto, date di nascita, indirizzi, indirizzi email, numeri di telefono, registri degli acquisti e preferenze sui prodotti. Louis Vuitton Hong Kong (LVHK) ha specificato che non sono stati coinvolti dati relativi ai pagamenti e ha dichiarato di aver notificato tempestivamente l’accaduto sia alle autorità competenti sia ai clienti interessati.

A seguito dell’incidente, l’Ufficio del Commissario per la privacy dei dati personali di Hong Kong ha comunicato di aver avviato un’indagine per accertare i fatti e verificare, tra le altre cose, se vi sia stata una notifica tardiva da parte dell’azienda. Va inoltre sottolineato che dall’inizio dell’anno Louis Vuitton ha già subito diversi gravi incidenti legati alla sicurezza dei dati.

Secondo Lin Yue, consulente capo di Lingyan Management Consulting e analista del settore dei beni di consumo, le cause principali di questi incidenti ricorrenti sarebbero da ricercare nell’abitudine, da parte dei marchi del lusso, di raccogliere quantità eccessive di dati non sempre necessari, come numeri di passaporto, e in misure di protezione e tecnologie di sicurezza non all’altezza della sensibilità dei dati gestiti.

Chen Jingjing, fondatrice di Jingjie Interactive, ha aggiunto che questa vulnerabilità riflette uno squilibrio tra la rapida digitalizzazione del settore del lusso e gli investimenti ancora insufficienti in sicurezza informatica: i marchi sono bravi a comunicare esclusività e artigianalità, ma spesso trascurano le fondamenta tecnologiche per proteggere i dati dei clienti.

Lin Yue ha inoltre sottolineato come la fuga di dati possa causare gravi danni sia per i consumatori, esposti a frodi e molestie, sia per i marchi stessi, che rischiano un crollo della fiducia, procedimenti legali e danni reputazionali. Chen Jingjing ha osservato che per i brand di lusso, la sicurezza dei dati dovrebbe diventare parte integrante dell’esperienza premium offerta ai clienti, e andrebbe inserita come priorità nelle strategie aziendali a lungo termine.

Infine, come misure di tutela, Lin Yue ha consigliato ai consumatori di limitare la quantità di dati personali condivisi con i brand e di cambiare regolarmente le proprie password. Per le aziende, invece, ha suggerito di trattare i dati come asset intangibili fondamentali, adottare tecnologie di protezione più avanzate – come password dinamiche per i sistemi CRM e limitazioni dell’accesso fuori orario – per consolidare davvero la fiducia dei propri clienti.

L'articolo Fuga di dati Louis Vuitton: 420.000 clienti coinvolti a Hong Kong proviene da il blog della sicurezza informatica.