Ever been at a party and landed in a heated argument about exactly where the International Space Station (ISS) is passing over at that very instant? Me neither, but it’s probably happened to someone. Assuming you were in that situation, and lacked access to your smartphone or any other form of internet connected device, you might like the pocket-sized Screen Tracker from [mars91].

The concept is simple. It’s a keychain-sized item that combines an ESP32, a Neopixel LED, and a small LCD screen on a compact PCB with a couple of buttons. It’s programmed to communicate over the ESP32’s WiFi connection to query a small custom website running on AWS. That website processes orbit data for the ISS and the positions of the planets, so they can be displayed on the LCD screen above a map of the Earth. We’re not sure what font it uses, but it looks pretty cool—like something out of a 90s sci-fi movie.

It’s a great little curio, and these sort of projects can have great educational value to boot. Creating something like this will teach you about basic orbits, as well as how to work with screens and APIs and getting embedded devices online. It may sound trivial when you’ve done it before, but you can learn all kinds of skills pursuing builds like these.

youtube.com/embed/Hi2Znc4YRa0?…

hackaday.com/2025/02/21/pocket…

This week Hackaday Editors Elliot Williams and Tom Nardi start things off with updates on the rapidly approaching Hackaday Europe and the saga of everyone’s favorite 3D printed boat.

From there they’ll cover an impressive method of seeing the world via WiFi, Amazon’s latest changes to the Kindle ecosystem, and an alternate reality in which USB didn’t take over the peripheral world. You’ll also hear about a multi-level hack that brings the joys of Linux into the world of Animal Crossing, 3D printed circuit components, and the imminent release of KiCAD 9.

Stick around until the end to learn about a unique hardened glass from East Germany and the disappointing reality of modern voice control systems.

html5-player.libsyn.com/embed/…
Where to Follow Hackaday Podcast

Places to follow Hackaday podcasts:

• iTunes
• Spotify
• Stitcher
• RSS
• YouTube
• Check out our Libsyn landing page

Download the DRM-free MP3 for safe keeping.

Episode 309 Show Notes:

News:

• Hackaday Europe 2025: Speakers, Lightning Talks, And More!
• 3DBenchy Sets Sail Into The Public Domain

What’s that Sound?

• Know that sound? Fill out this form for a chance to win a Hackaday Podcast t-shirt!

Interesting Hacks of the Week:

• Octet Of ESP32s Lets You See WiFi Like Never Before
  
  • Building Your Own SDR-based Passive Radar On A Shoestring
  • Open-Source Passive Radar Taken Down For Regulatory Reasons
  • [2502.09405] ESPARGOS: An Ultra Low-Cost, Realtime-Capable Multi-Antenna WiFi Channel Sounder

  
  

• Auto-Download Your Kindle Books Before February 26th Deadline
• In A World Without USB…
• Give Your Animal Crossing Villagers The Gift Of Linux
  
  • Because You Can: Linux On An Arduino Uno

  
  

• A Unique Linear Position Sensor Using Magnetostriction
  
  • 2024 :: fischertechnik Community

  
  

• MIT Demonstrates Fully 3D Printed, Active Electronic Components

Quick Hacks:

• Elliot’s Picks:
  
  • You Know This Font, But You Don’t Really Know It
  • Measuring Local Variances In Earth’s Magnetic Field
  • Probably The Most Esoteric Commodore 64 Magazine

  
  

• Tom’s Picks:
  
  • Get Ready For KiCAD 9!
  • Vacuum Forming With 3D Printed Moulds And Sheets
  • Belfry OpenSCAD Library (BOSL2) Brings Useful Parts And Tools Aplenty

  
  

Can’t-Miss Articles:

• The “Unbreakable” Beer Glasses Of East Germany
  
  • The High-Tech Valor Glass Vials Used To Deliver The Coronavirus Vaccine

  
  

• Be Careful What You Ask For: Voice Control

hackaday.com/2025/02/21/hackad…

One-wheels use motion-tracking hardware and fine motor control to let you balance on a single wheel. That’s neat and all, but [Michael Rechtin] had another idea in mind—what if a one-wheel used a track instead?

The idea behind the track was to make the one-wheel more capable on surfaces where wheels simply can’t compete. The tracked drivetrain was largely 3D printed, including some massive gears that are supplemented by a big old 150 mm ball bearing which sits around the drive motor itself. If you love planetary gear trains with a 4:1 reduction, this project is for you. Carbon-fiber reinforced filament was used for many of the parts to give them some additional strength. Control is a little different than a traditional one-wheel, since the flat-bottomed track means lean controls won’t work. Instead, a wireless hand throttle was constructed to enable the rider to command the direction of travel.

It’s not easy to ride, but the one-track does actually work. It’s capable of crawling its way around on grass and snow quite well. There were some issues with the printed tracks and rollers, particularly when turning, but tweaks to round out the track profile helped solve that issue to a degree. There’s a reason we often use wheels instead of tracks, but somehow tracks are still just cool.

youtube.com/embed/VicrABEfr3U?…

hackaday.com/2025/02/21/buildi…

OpenSSH has a newly fixed pair of vulnerabilities, and while neither of them are lighting the Internet on fire, these are each fairly important.

The central observation made by the Qualsys Threat Research Unit (TRU) was that OpenSSH contains a code paradigm that could easily contain a logic bug. It’s similar to Apple’s infamous goto fail; SSL vulnerability. The setup is this: An integer, r, is initialized to a negative value, indicating a generic error code. Multiple functions are called, with r often, but not always, set to the return value of each function. On success, that may set r to 0 to indicate no error. And when one of those functions does fail, it often runs a goto: statement that short-circuits the rest of the checks. At the end of this string of checks would be a return r; statement, using the last value of r as the result of the whole function.
1387 int
1388 sshkey_to_base64(const struct sshkey *key, char **b64p)
1389 {
1390 int r = SSH_ERR_INTERNAL_ERROR;
....
1398 if ((r = sshkey_putb(key, b)) != 0)
1399 goto out;
1400 if ((uu = sshbuf_dtob64_string(b, 0)) == NULL) {
1401 r = SSH_ERR_ALLOC_FAIL;
1402 goto out;
1403 }
....
1409 r = 0;
1410 out:
....
1413 return r;
1414 }

The potential bug? What if line 1401 was missing? That would mean setting r to the success return code of one function (1398), then using a different variable in the next check (1400), without re-initializing r to a generic error value (1401). If that second check fails at line 1400, the code execution jumps to the return statement at the end, but instead of returning an error code, the success code from the intermediary check is returned. The TRU researchers arrived at this theoretical scenario just through the code smell of this particular goto use, and used the CodeQL code analysis tool to look for any instances of this flaw in the OpenSSH codebase.

The tool found 50 results, 37 of which turned out to be false positives, and the other 13 were minor issues that were not vulnerabilities. Seems like a dead end, but while manually auditing how well their CodeQL rules did at finding the potentially problematic code, the TRU team found a very similar case, in the VerifyHostKeyDNS handling, that could present a problem. The burning question on my mind when reaching this point of the write-up was what exactly VerifyHostKeyDNS was.

SSH uses public key cryptography to prevent Man in the Middle (MitM) attacks. Without this, it would be rather trivial to intercept an outgoing SSH connection, and pretend to be the target server. This is why SSH will warn you The authenticity of host 'xyz' can't be established. upon first connecting to a new SSH server. And why it so strongly warns that IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! when a connection to a known machine doesn’t verify properly. VerifyHostKeyDNS is an alternative to trusting a server’s key on first connection, instead getting the cryptographic fingerprint in a DNS lookup.

So back to the vulnerability. TRU found one of these goto out; cases in the VerifyHostKeyDNS handling that returned the error code from a function on failure, but the code a layer up only checked for a -1 value. On one layer of code, only a 0 was considered a success, and on the other layer, only a -1 was considered a failure. Manage to find a way to return an error other than -1, and host key verification automatically succeeds. That seems very simple, but it turns out the only other practical error that can be returned is an out of memory error. This leads to the second vulnerability that was discovered.

OpenSSH has its own PING mechanism to determine whether a server is reachable, and what the latency is. When it receives a PING, it sends a PONG message back. During normal operation, that’s perfectly fine. The messages are sent and the memory used is freed. But during key exchange, those PONG packets are simply queued. There are no control mechanisms on how many messages to queue, and a malicious server can keep a client in the key exchange process indefinitely. In itself it’s a denial of service vulnerability for both the client and server side, as it can eat up ridiculous amount of memory. But when combined with the VerifyHostKeyDNS flaw explained above, it’s a way to trigger the out of memory error, and bypass server verification.

The vulnerabilities were fixed in the 9.9p2 release of OpenSSH. The client attack (the more serious of the two) is only exploitable if your client has the VerifyHostKeyDNS option set to “yes” or “ask”. Many systems default this value to “no”, and are thus unaffected.

JumbledPath

We now have a bit more insight into how Salt Typhoon recently breached multiple US telecom providers, and deployed the JumbledPath malware. Hopefully you weren’t expecting some sophisticated chain of zero-day vulnerabilities, because so far the answer seems to be simple credential stealing.

Cisco Talos has released their report on the attacks, and the interesting parts are what the attackers did after they managed to access target infrastructure. The JumbledPath malware is a Go binary, running on x86-64 Linux machines. Lateral movement was pulled off using some clever tricks, like changing the loopback address to an allowed IP, to bypass Access Control Lists (ACLs). Multiple protocols were abused for data gathering and further attacks, like SNMP, RADIUS, FTP, and SSH. There’s certainly more to this story, like where the captured credentials actually came from, and whose conversations were actually targeted, but so far those answers are not available.

Ivanti Warp-Speed Audit

The preferred method of rediscovering vulnerabilities is patch diffing. Vendors will often announce vulnerabilities, and even release updates to correct them, and never really dive into the details of what went wrong with the old code. Patch diffing is looking at the difference between the vulnerable release and the fixed one, figuring out what changed, and trying to track that back to the root cause. Researchers at Horizon3.ai knew there were vulnerabilities in Ivanti’s Endpoint manager, but didn’t have patches to reverse engineer. Seems like a bummer, but was actually serendipity, as the high-speed code audit looking for the known vulnerability actually resulted in four new ones being found!

They are all the same problem, spread across four API endpoints, and all reachable by an unauthenticated user. The code is designed to look at files on the local filesystem, and generate hashes for the files that are found. The problem is that the attacker can supply a file name that actually resolves to an external Universal Naming Convention (UNC) path. The appliance will happily reach out and attempt to authenticate with a remote server, and this exposes the system to credential relay attacks.

RANsacked

The Florida Institute for Cybersecurity Research have published a post and paper (PDF) about RANsacked, their research into various LTE and 5G systems. This is a challenging area to research, as most of us don’t have any spare LTE routing hardware laying around to research on. The obvious solution was to build their own, using open source software like Open5GS, OpenAirInterface, etc. The approach was to harness a fuzzer to find interesting vulnerabilities in these open implementations, and then apply that approach to closed solutions. Serious vulnerabilities were found in every target the fuzzing system was run against.

Their findings break down into three primary categories of vulnerabilities. The first is untrusted Non-Access Stratum (NAS) control messages getting handled by the “core”, the authentication, routing, and processing part of the cellular system. These messages aren’t properly sanitized before processing, leading to the expected crashes and exploits we see in every other insufficiently hardened system that processes untrusted data. The second category is the uncertainty in the protocol specifications and mismatch between what those specifications seem to indicate and the reality of cellular traffic. And finally, deserialization of ASN.1 data itself is subject to deserialization attacks. This group of research found a staggering 119 vulnerabilities in total.

Bits and Bytes

[RyotaK] at GMO Flatt Security found an interesting vulnerability in Chatwork, a popular messaging application in Japan. The desktop version of this tool is just an electron app, and it makes use of webviewTag, an obsolete Electron feature. This quirk can be combined with a dangerous method in the preload context, allowing for arbitrary remote code execution when a user clicks a malicious link in the application.

Once upon a time, Microsoft published Virtual Machines for developers to use for testing websites inside Edge and IE. Those VM images had the puppet admin engine installed, but no configuration set. And that’s not great, because in this state puppet will look for machine using the puppet hostname on the local network, and attempt to download a configuration from there. And because puppet is explicitly designed to administer machines, this automatically results in arbitrary code execution. The VMs are no longer offered, so we’re past the expiration date on this particular trick, but what an interesting quirk of these once-official images.

[Anurag] has an analysis of the Arechclient2 Remote Access Trojan (RAT). It’s a bit of .NET malware, aggressively obfuscated, that collects and exfiltrates data and credentials. There’s a browser element, in the form of a Chrome extension that reports itself as Google Docs. This is more data collection, looking for passwords and other form fills.

Signal users are getting hacked by good old fashioned social engineering. The trick is to generate a QR code from Signal that will permit the account scanning the code to log in on another device. It’s advice some of us have learned the hard way, but QR codes are just physical manifestations of URLs, and we really shouldn’t trust them lightly. Don’t click that link, and don’t scan that QR code.

hackaday.com/2025/02/21/this-w…

Negli ultimi tempi, il mondo imprenditoriale veneto è stato ripetutamente preso di mira da attacchi informatici di grande portata. Questa volta la vittima è Fashion Box, multinazionale con sede a Casella d’Asolo, nota per il suo celebre marchio di abbigliamento Replay.

L’azione degli hacker è iniziata il 29 gennaio con una tecnica di brute force riporta il Corriere Del Veneto, un metodo che consiste nel tentare innumerevoli combinazioni di password per ottenere accesso ai sistemi aziendali. Nonostante le misure di sicurezza implementate, i criminali informatici sono riusciti a oltrepassare le difese, compromettendo i server della sede centrale di Asolo. I dati sottratti riguardano informazioni sensibili legate all’attività logistica e commerciale dell’azienda, mentre le consociate estere sembrano essere rimaste al riparo dall’attacco. La criticità della situazione è legata soprattutto alla gestione di dati di dipendenti, collaboratori e fornitori provenienti da diverse parti del mondo.

Le organizzazioni sindacali hanno espresso forte preoccupazione per le conseguenze di questa incursione informatica. I rappresentanti di Filctem Cgil e Femca Cisl hanno evidenziato come Fashion Box abbia agito tempestivamente per arginare il danno e proteggere i lavoratori. Secondo le prime dichiarazioni, al momento non risultano impatti diretti sull’occupazione, ma la situazione resta fluida e in evoluzione. Anche il sindaco di Asolo ha sottolineato l’importanza dell’azienda per l’economia locale, sottolineando come un attacco di questa portata possa mettere in difficoltà numerose famiglie del territorio.

Le analisi condotte dagli esperti di sicurezza informatica di Fashion Box hanno evidenziato che i dati trafugati includono informazioni personali e finanziarie di dipendenti ed ex dipendenti, oltre a documenti di riconoscimento e codici bancari di fornitori. La sottrazione di questi dati potrebbe rallentare significativamente le operazioni logistiche dell’azienda, costringendola a ricostruire parte delle informazioni compromesse. Nel frattempo, sono in corso attività per rafforzare i sistemi di sicurezza informatica e prevenire ulteriori intrusioni.

Fashion Box ha immediatamente segnalato l’accaduto alle autorità competenti sia in Italia che nei paesi coinvolti, come Austria, Francia, Germania, Spagna e Regno Unito. Inoltre, è stata presentata una denuncia alla magistratura per avviare un’indagine ufficiale sul caso. L’attacco rappresenta un ulteriore segnale di allarme sulla crescente vulnerabilità delle aziende del territorio di fronte alle minacce cyber.

Il caso di Fashion Box si inserisce in un contesto preoccupante in cui le imprese venete, nonostante investimenti in sicurezza, continuano a essere bersaglio privilegiato di attacchi informatici. Questo episodio evidenzia la necessità di strategie ancora più avanzate per la protezione dei dati e una maggiore sensibilizzazione su queste minacce, che possono avere impatti economici e occupazionali rilevanti.

L'articolo Il Marchio Replay nel Mirino degli Hacker: Violati i Server dell’Azienda Italiana Fashion Box! proviene da il blog della sicurezza informatica.

Un aneddoto che vale la pena riproporre qui su Friendica, anche se lunghetto... 😆

La backroom

Angry Likho (referred to as Sticky Werewolf by some vendors) is an APT group we’ve been monitoring since 2023. It bears a strong resemblance to Awaken Likho, which we’ve analyzed before, so we classified it within the Likho malicious activity cluster. However, Angry Likho’s attacks tend to be targeted, with a more compact infrastructure, a limited range of implants, and a focus on employees of large organizations, including government agencies and their contractors. Given that the bait files are written in fluent Russian, we infer that the attackers are likely native Russian speakers.

We’ve identified hundreds of victims of this attack in Russia, several in Belarus, and additional incidents in other countries. We believe that the attackers are primarily targeting organizations in Russia and Belarus, while the other victims were incidental—perhaps researchers using sandbox environments or exit nodes of Tor and VPN networks.

At the beginning of 2024, several cybersecurity vendors published reports on Angry Likho. However, in June, we detected new attacks from this group, and in January 2025, we identified malicious payloads confirming their continued activity at the moment of our research.

Technical details

Initial attack vector

The initial attack vector used by Angry Likho consists of standardized spear-phishing emails with various attachments. Below is an example of such an email containing a malicious RAR archive.

Contents of spear-phishing email inviting the victim to join a videoconference

The archive includes two malicious LNK files and a legitimate bait file.

Bait document from spear-phishing email inviting the victim to join a videoconference

The content of this document is almost identical to the body of the phishing email.

This example illustrates how the attackers gain access to victims’ systems. All these emails (and others like them in our collection) date back to April 2024. We observed no further activity from this group until we discovered an unusual implant, described below. Based on our telemetry, the attackers operate periodically, pausing their activities for a while before resuming with slightly modified techniques.

Previously unknown Angry Likho implant

In June 2024, we discovered a very interesting implant associated with this APT. The implant was distributed under the name FrameworkSurvivor.exe from the following URL:

hxxps://testdomain123123[.]shop/FrameworkSurvivor.exe

This implant was created using the legitimate open-source installer, Nullsoft Scriptable Install System, and functions as a self-extracting archive (SFX). We’ve previously observed this technique in multiple Awaken Likho campaigns.

Below are the contents of the archive, opened using the 7-Zip archiver.

Contents of the malicious SFX archive

The archive contains a single folder, $INTERNET_CACHE, filled with many files without extensions.

Installation script of the self-extracting archive

To understand how the SFX archive infects a system when launched, we had to find and analyze its installation script. The latest versions of 7-Zip do not allow extraction of this script, but it can be retrieved using older versions. We used 7-Zip version 15.05 (the last version supporting extraction of the installation script):

Contents of the malicious SFX archive opened in 7-Zip version 15.05

The installation script was named [NSIS].nsi, and was partially obfuscated.

Obfuscated contents of the installation script

After deobfuscation, we were able to determine its primary purpose:

Deobfuscated installation script from the malicious SFX implant

The script searches for the folder on the victim’s system using the $INTERNET_CACHE macro, extracts all the files from the archive into it, renames the file “Helping” to “Helping.cmd”, and executes it.

Helping.cmd command file

Below are the contents of the Helping.cmd file:

Contents of the Helping.cmd file

This file is heavily obfuscated, with several meaningless junk lines inserted between each actual script command. Once deobfuscated, the script’s logic becomes clear. Below is the code, with some lines modified for readability:

Deobfuscated Helping.cmd

The Helping.cmd script launches a legitimate AutoIt interpreter (Child.pif) with the file i.a3x as a parameter. The i.a3x file contains a compiled AU3 script. With that in mind, we can assume that this script implements the core logic of the malicious implant.

AU3 script

To recover the original AU3 file used when creating the i.a3x file, we created a dummy executable with a basic AutoIt script, swapped its content with i.a3x, and used a specialized tool to extract the original AU3 script.
We ended up with the original AU3 file:

Restored AU3 script

The script is heavily obfuscated, with all strings encrypted. After deobfuscating and decrypting the code, we analyzed it. The script begins with a few verification procedures:

The AU3 script checks the environment

The script checks for artifacts associated with emulators and research environments of security vendors. If a match is found, it either terminates or executes with a 10,000 ms delay to evade detection.

Interestingly, we’ve seen similar checks in the Awaken Likho implants. This suggests that the attackers behind these two campaigns share the same technology or are the same group using different tools for different targets and tasks.

The script next sets an error-handling mode by calling SetErrorMode() from the kernel32.dll with the flags SEM_NOALIGNMENTFAULTEXCEPT, SEM_NOGPFAULTERRORBOX, and SEM_NOOPENFILEERRORBOX, thus hiding system error messages and reports. If this call fails, the script terminates.

Afterward, the script deletes itself from disk by calling FileDelete(“i”) and generates a large text block, as shown below.

Code for generating “shellcode”

This block is presumably shellcode that will be loaded into memory and executed. However, it is also packed and encrypted. Once unpacked and decrypted, the AU3 script attempts to inject the malicious payload into the legitimate AutoIt process.

Final activity of the AU3 script

Main payload

To obtain the shellcode, we saved a dump of the decrypted and unpacked payload once the AU3 malicious script had fully processed it. After removing unnecessary bytes from the dump, we recovered the original payload of the attack. It turned out to be not shellcode but a full-fledged MZ PE executable file.

The decrypted and unpacked payload—an MZ PE file

Our products detect this payload with the following verdicts:

• HEUR:Trojan.MSIL.Agent.pef
• HEUR:Trojan.Win32.Generic

We examined this payload and concluded that it is the Lumma Trojan stealer (Trojan-PSW.Win32.Lumma).

The Lumma stealer gathers system and installed software information from the compromised devices, as well as sensitive data such as cookies, usernames, passwords, banking card numbers, and connection logs. It also steals data from 11 browsers, including Chrome, Chromium, Edge, Kometa, Vivaldi, Brave, Opera Stable, Opera GX Stable, Opera Neon, Mozilla Firefox and Waterfox, as well as cryptocurrency wallets such as Binance and Ethereum. Additionally, it exfiltrates data from cryptowallet browser extensions (MetaMask) and authenticators (Authenticator), along with information from applications such as the remote access software AnyDesk and the password manager KeePass.

Command servers

This sample contains encoded and encrypted addresses of command servers. Using a simple decryption procedure in the executable file code, we restored the original domain names used as command servers.

• averageorganicfallfaw[.]shop
• distincttangyflippan[.]shop
• macabrecondfucews[.]shop
• greentastellesqwm[.]shop
• stickyyummyskiwffe[.]shop
• sturdyregularrmsnhw[.]shop
• lamentablegapingkwaq[.]shop
• Innerverdanytiresw[.]shop
• standingcomperewhitwo[.]shop

By identifying the command server names from this malware variant, we were able to identify other related samples. As a result, we discovered over 60 malicious implants. Some of them had the same payload, and we managed to find additional attacker-controlled command servers (the addresses listed below were used in the identified samples alongside the original command servers):

• uniedpureevenywjk[.]shop
• spotlessimminentys[.]shop
• specialadventurousw[.]shop
• stronggemateraislw[.]shop
• willingyhollowsk[.]shop
• handsomelydicrwop[.]shop
• softcallousdmykw[.]shop

We’re convinced that the main objectives of this APT group are to steal sensitive data using stealers and establish full control over infected machines via malicious remote administration utilities.

New activity

We’ve been tracking the attacks of this campaign since June 2024. However, in January 2025, the attackers showed a new surge in activity, as reported by our colleagues from F6 (previously known as F.A.C.C.T.). We analyzed the indicators of compromise they published and identified signs of a potential new wave of attacks, likely in preparation since at least January 16, 2025:

Files found in Angry Likho’s payload repositories

We managed to download malicious files hosted in repositories seen in the January Angry Likho attack while they were still accessible. Analysis of the files test.jpg and test2.jpg revealed that they contained the same .NET-based payload, encoded using Base64. Last year, we documented Angry Likho attacks that used image files containing malicious code. Moreover, the filenames match those of the samples we recently discovered.

This further confirms that the Angry Likho group, responsible for these attacks, remains an active threat. We are continuing to monitor this threat and providing up-to-date cyber intelligence data about it and the TTPs used by the group.

Victims

At the time of our investigation, our telemetry data showed hundreds of victims in Russia and several in Belarus. Most of the SFX archives had filenames and bait documents in Russian, thematically linked to government institutions in Russia. These institutions and their contractors are the primary targets of this campaign.

Attribution

We attribute this campaign to the APT group Angry Likho with a high degree of confidence. It shares certain similarities with findings from our colleagues at BI.ZONE and F6, as well as previous attacks by the group:

1. The same initial implant structure (an archive with similar contents, sent in an email).
2. Similar bait documents with the same naming patterns and themes, mostly written in Russian.
3. Command files and AutoIt scripts used to install the implant are obfuscated similarly. Newer versions contain more sophisticated installation scripts, with extra layers of obfuscation to complicate analysis.
4. The implant described in this report contains a known payload—the Lumma stealer (Trojan-PSW.Win32.Lumma). We have not previously seen this tool used in Angry Likho campaigns, but earlier attacks showed similar data exfiltration tactics, suggesting the group is still targeting cryptowallet files and user credentials.

Conclusion

We are continuing to monitor the activity of the Angry Likho APT, which targets Russian organizations. The group’s latest attacks use the Lumma stealer, which collects a vast amount of data from infected devices, including browser-stored banking details and cryptowallet files. As before, the complex infection chain was contained in a self-extracting archive distributed via email. We believe that the attackers crafted spear-phishing emails tailored to specific users, attaching bait files designed to attract their interest. Additionally, we identified more malicious samples linked to this campaign based on common command servers and repositories.
Let’s sum up by highlighting the notable features of this campaign and other similar ones:

1. The attack techniques remain relatively consistent over time, with only minor modifications. Despite this, the attackers are successfully achieving their objectives.
2. The attackers occasionally pause their activity, only to return with a new wave of attacks after a certain period.
3. The group relies on readily available malicious utilities obtained from darknet forums, rather than developing its own tools. The only work they do themselves is writing mechanisms of malware delivery to the victim’s device and crafting targeted phishing emails.

To protect against such attacks, organizations need a comprehensive security solution that provides proactive threat hunting, 24/7 monitoring, and incident detection. Our product line for businesses helps identify and prevent attacks of any complexity at an early stage. The campaigns in this article rely on phishing emails as the initial attack vector, highlighting the importance of regular employee training and awareness programs for corporate security.

Indicators of compromise

File hashes

Implants

f8df6cf748cc3cf7c05ab18e798b3e91
ef8c77dc451f6c783d2c4ddb726de111
de26f488328ea0436199c5f728ecd82a
d4b75a8318befdb1474328a92f0fc79d
ba40c097e9d06130f366b86deb4a8124
b0844bb9a6b026569f9baf26a40c36f3
89052678dc147a01f3db76febf8441e4
842f8064a81eb5fc8828580a08d9b044
7c527c6607cc1bfa55ac0203bf395939
75fd9018433f5cbd2a4422d1f09b224e
729c24cc6a49fb635601eb88824aa276
69f6dcdb3d87392f300e9052de99d7ce
5e17d1a077f86f7ae4895a312176eba6
373ebf513d0838e1b8c3ce2028c3e673
351260c2873645e314a889170c7a7750
23ce22596f1c7d6db171753c1d2612fe
0c03efd969f6d9e6517c300f8fd92921
277acb857f1587221fc752f19be27187

Payload

faa47ecbcc846bf182e4ecf3f190a9f4
d8c6199b414bdf298b6a774e60515ba5
9d3337f0e95ece531909e4c8d9f1cc55
6bd84dfb987f9c40098d12e3959994bc
6396908315d9147de3dff98ab1ee4cbe
1e210fcc47eda459998c9a74c30f394e
fe0438938eef75e090a38d8b17687357

Bait files

e0f8d7ec2be638fbf3ddf8077e775b2d
cdd4cfac3ffe891eac5fb913076c4c40
b57b13e9883bbee7712e52616883d437
a3f4e422aecd0547692d172000e4b9b9
9871272af8b06b484f0529c10350a910
97b19d9709ed3b849d7628e2c31cdfc4
8e960334c786280e962db6475e0473ab
76e7cbab1955faa81ba0dda824ebb31d
7140dbd0ca6ef09c74188a41389b0799
5c3394e37c3d1208e499abe56e4ec7eb
47765d12f259325af8acda48b1cbad48
3e6cf927c0115f76ccf507d2f5913e02
32da6c4a44973a5847c4a969950fa4c4

Malicious domains

testdomain123123[.]shop
averageorganicfallfaw[.]shop
distincttangyflippan[.]shop
macabrecondfucews[.]shop
greentastellesqwm[.]shop
stickyyummyskiwffe[.]shop
sturdyregularrmsnhw[.]shop
lamentablegapingkwaq[.]shop
innerverdanytiresw[.]shop
standingcomperewhitwo[.]shop
uniedpureevenywjk[.]shop
spotlessimminentys[.]shop
specialadventurousw[.]shop
stronggemateraislw[.]shop
willingyhollowsk[.]shop
handsomelydicrwop[.]shop
softcallousdmykw[.]shop

securelist.com/angry-likho-apt…

It is easy to port C compilers to architectures that look like old minicomputers or bigger CPUs. However, as the authors of the Small Device C Compiler (SDCC) found, pushing C into a typical 8-bit CPU is challenging. Lessons learned from SDCC inspired a new 8-bit architecture, F8. This isn’t just a theoretical architecture. You can find an example Verilog implementation in the SDDC project and on GitHub. The name choice may turn out to be unfortunate as there was an F8 CPU from Fairchild back in the 1970s that apparently few people remember.

In the video from FOSDEM 2025, [Phillip Krause] provides a nice overview of the how and why of F8. While it might seem odd to create a new 8-bit CPU when you can get bigger CPUs for pennies, you have to consider that 8-bit machines are more than enough for many jobs, and if you can squeeze one into an FPGA, it might be a good choice as opposed to having to get a bigger FPGA to hold your design and a 32-bit CPU.

Many 8-bit computers struggle with efficient C code mainly because the data size is smaller than the width of a pointer. Doing things like adding two numbers takes more code, even in common situations. For example, suppose you have a pointer to an array, and each element of the array is four bytes wide. To find the address of the n’th element, you need to compute: element_n = base_address + (n *4). On, say, an 8086 with 16-bit pointers and many 16-bit instructions and addressing modes can do the calculation very succinctly.

Other problems you frequently run into with compiling code for small CPUs include segmented address spaces, dedicated registers for memory indexing, and difficulties putting wider items on a stack (or, for some very small CPUs, even having a stack, at all).

The wish list was to include stack-relative addressing, hardware 8-bit multiplication, and BCD support to help support an efficient printf implementation.

Keep in mind, it isn’t that you can’t compile C for strange 8-bit architectures. SDDC is proof that you can. The question is how efficient is the generated code. F8 provides features that facilitate efficient binaries for C programs.

We’ve seen other modern 8-bit CPUs use SDCC. Writing C code for the notorious PIC (with it’s banked memory, lack of stack, and other hardships) was truly a surreal experience.

hackaday.com/2025/02/21/a-new-…

Un grande imprenditore italiano diceva moltissimi anni fa: “L’Italia procede ancora nel compromesso, nei vecchi sistemi del trasformismo politico, del potere burocratico, delle grandi promesse, dei grandi piani e delle modeste realizzazioni”.

Ma ovviamente tutti ci aspettiamo che non sia così.

L’Italia progetta di creare un proprio sistema di satelliti in orbita bassa per le comunicazioni governative, ha affermato il ministro dell’Industria Adolfo Urso. Questa mossa è vista come un’alternativa all’utilizzo della rete Starlink di Elon Musk, di cui si era già parlato nel governo di Georgia Meloni.

In precedenza, il governo aveva preso in considerazione l’utilizzo di Starlink per le comunicazioni crittografate tra funzionari che lavoravano in aree ad alto rischio. Tuttavia, l’idea ha suscitato aspre critiche da parte dell’opposizione, che ha espresso preoccupazione per il fatto di affidare un elemento chiave della sicurezza nazionale nelle mani di un imprenditore straniero con stretti legami con il governo degli Stati Uniti.

Adolfo Urso, di Fratelli d’Italia, ha dichiarato al Parlamento che il governo sta lavorando alla creazione di un sistema satellitare indipendente in orbita bassa, con la partecipazione di importanti aziende italiane. Ha sottolineato che il nuovo sistema diventerà un’alternativa competitiva agli operatori stranieri, tra cui SpaceX.

Non è ancora noto quali aziende prenderanno parte al progetto, ma il capo del Ministero locale dell’Industria e del Commercio ha affermato che l’agenzia spaziale nazionale condurrà uno studio di fattibilità. Non è inoltre specificata la tempistica di attuazione del programma.

Elon Musk ha già espresso in passato la sua disponibilità a offrire i suoi servizi all’Italia e il suo rapporto amichevole con Meloni ha alimentato le aspettative di una possibile cooperazione. Tuttavia, il ministro della Difesa Guido Crosetto ha affermato che non sono stati ancora raggiunti accordi.

Attualmente sono 6.700 i satelliti Starlink operativi in ​​orbita terrestre bassa. Mentre in precedenza l’Italia aveva preso in considerazione un contratto quinquennale da 1,5 miliardi di euro con SpaceX, ora il Paese sta compiendo un passo avanti verso la creazione di una propria infrastruttura di comunicazioni sicure e indipendenti. In questo modo l’Italia intende garantire il controllo sulle comunicazioni di importanza strategica e ridurre la dipendenza dalle tecnologie straniere.

L'articolo L’Italia sfida Elon Musk! In arrivo la Nostra Rete Satellitare Nazionale? proviene da il blog della sicurezza informatica.

If you think sonic booms from supersonic aircraft are a nuisance, wait until the sky is full of planes propelled by up-scaled versions of this interesting but deafening audio resonance engine.

Granted, there’s a lot of work to do before this “Sonic Ramjet” can fly even something as small as an RC plane. Creator [invalid_credentials] came up with the idea for a sound-powered engine after listening to the subwoofers on a car’s audio system shaking the paint off the body. The current design uses a pair of speaker drivers firing into 3D printed chambers, which are designed based on Fibonacci ratios to optimize resonance. When the speakers are driven with a low-frequency sine wave, the chambers focus the acoustic energy into powerful jets, producing enough thrust to propel a small wheeled test rig across a table.

It’s fair to ask the obvious question: is the engine producing thrust, or is the test model moving thanks to the vibrations caused by the sound? [invalid_credentials] appears to have thought of that, with a video showing a test driver generating a powerful jet of air. Downloads to STL files for both the large and small versions of the resonating chamber are provided, if you want to give it a try yourself. Just be careful not to annoy the neighbors too much.

Thanks to [cabbage] for the tip via [r/3Dprinting].

hackaday.com/2025/02/21/acoust…

Un'alta carica della P.A. che non sembra avere chiaro un concetto, come dire... Piuttosto intuitivo.

Il Direttore Generale: #brevestoriatriste