The Domain Name System (DNS) is a major functional component of the modern Internet. We rely on it for just about everything! It’s responsible for translating human-friendly domain names into numerical IP addresses that get traffic where it needs to go. At the heart of the system are the top-level domains (TLDs)—these sit atop the whole domain name hierarchy.

You might think these TLDs are largely immutable—rock solid objects that seldom change. That’s mostly true, but the problem is that these TLDs are sometimes linked to real-world concepts that are changeable. Like the political status of various countries! Then, things get altogether more complex. The .io top level domain is the latest example of that.

A Brief History

ICANN is the organization in charge of TLDs.
Before we get into the current drama, we should explain some background around top level domains. Basically, as the Internet started to grow out of its early nascent form, there was a need to implement a proper structured naming system for online entities. In the mid-1980s, the Internet Assigned Numbers Authority (IANA) introduced a set of original top level domains to categorize domain names. These were divided into two main types—generic top-level domains, and country code top-level domains. The generic TLDs are the ones we all know and love—.com, .org, .net, .edu, .gov, and .mil. The country codes, though, were more complex.

Initially, the country codes were based around the ISO 3166-1 alpha-2 standard—two letter codes to represent all necessary countries. These were, by and large, straightforward—the United Kingdom got .uk, Germany got .de, the United States got .us, and Japan got .jp.

Eventually, management of TLDs was passed from IANA to a new organization called ICANN—Internet Corporation for Assigned Names and Numbers. Over time, ICANN has seen fit to add more TLDs to the official list. That’s why today, you can register a domain with a .biz, .info, or .name registration. Or .horse, .Dad, .Foo, or so many others besides.
Wikipedia maintains an interactive decoding table that covers the full ISO 3166-1 alpha-2 code space, as used to designate ccTLDs. Credit: Wikipedia

What’s With .io?

The official logo of the .io ccTLD. The Internet Computer Bureau Ltd. is the registry organization in charge of it.
Over the past 20 years or so, the .io domain has become particularly popular with the tech set—the initialism recalls the idea of input/output. Thus, you have websites like Github.io or Hackaday.io using a country-code TLD for vanity purposes. It’s pretty popular in the tech world.

This was never supposed to be the case, however. The domain was originally designated for the British Indian Ocean Territory, all the way back in 1997. This is a small overseas territory of the United Kingdom, which occupies a collection of islands of the Chagos Archipelago. Total landmass of the territory is just 60 square kilometers. The largest island is Diego Garcia, which plays host to a military facility belonging to the UK and the United States. Prior to their removal by British authorities in 1968, the island played host to a population of locals known as Chagossians.
The flag of the British Indian Ocean Territory. Not even kidding.
The territory has been the subject of some controversy, often concerning the Chagossians and their wish to return to the land. More recently, the Mauritian government has made demands for the British government to relinquish the islands. The East African nation considers that the islands should have been handed back when Mauritius gained independence in 1968.

Recent negotiations have brought the matter to a head. On October 3, the British and Mauritius governments came to an agreement that the UK would cede sovereignty over the islands, and that they would hence become part of Mauritius. The British Indian Ocean Territory would functionally cease to exist, though the UK would maintain a 99-year lease over Diego Garcia and continue to maintain the military facility there.

The key problem? With the British Indian Ocean Territory no longer in existence, it would thus no longer be eligible for a country-code TLD. According to IANA, ccTLDs are based on the ISO 3166-1 standard. When a country ceases to exist, it is removed from the standard, and thus, the ccTLD is supposed to be retired in turn. IANA states protocol is to notify the manager of the ccTLD and remove it after five years by default. Managers can ask for an extension, limited to another five years for a total of ten years maximum. Alternatively, a ccTLD manager may allow the domain to be retired early at their own discretion.

However, as per The Register, the situation is more complex. The outlet spoke to ICANN, which is the organization actually in charge of declaring valid TLDs. A spokesperson provided the following comment:

ICANN relies on the ISO 3166-1 standard to make determinations on what is an eligible country-code top-level domain. Currently, the standard lists the British Indian Ocean Territory as ‘IO’. Assuming the standard changes to reflect this recent development, there are multiple potential outcomes depending on the nature of the change.

One such change may involve ensuring there is an operational nexus with Mauritius to meet certain policy requirements. Should ‘IO’ no longer be retained as a coding for this territory, it would trigger a 5-year retirement process described at [the IANA website], during which time registrants may need to migrate to a successor code or an alternate location.

We cannot comment on what the ISO 3166 Maintenance Agency may or may not do in response to this development. It is worth noting that the ISO 3166-1 standard is not just used for domain names, but many other applications. The need to modify or retain the ‘IO’ encoding may be informed by needs associated with those other purposes, such as for Customs, passports, and banking applications.

The Chagos Archipelago is, genuinely, a long way from everywhere. Credit: TUBS, CC BY-SA 3.0
Basically, ICANN passed the buck, putting the problem at the feet of the International Standards Organization which maintains ISO 3166-1. If the ISO standard maintains the IO designation for some reason, it appears that ICANN would probably follow suit. If ISO drops it for some reason, it could be retired as a ccTLD.

The Register notes that the .io record in ISO 3166-1 has not changed since a minor update in 2018. Any modification by ISO would be unlikely before the treaty between the UK and Mauritius is ratified in 2025. At that point, the five year clock could start ticking.

However, history is a great educator in this regard. There’s another grand example of a country that functionally ceased to exist. In 1991, the Soviet Union was no longer a going concern. And yet, the .su designation remains “exceptionally reserved” in the ISO 3166-1 standard at the request of the Foundation for Internet Development. However, the entry notes it was “removed from ISO 3166-1 in 1992” when the USSR broke up into its constituent states. Those states were all given their own country codes, except for Ukraine and Belarus, which had already entered ISO 3166 before this point.
.su domains are still very much a going concern, 33 years after the fall of the Soviet Union.
But can you still get a .su domain? Well, sure! Netim.com will happily register one for you. A number of websites still use the TLD, like this one, and it has reportedly become a popular TLD for cybercriminal activity. The current registry is the Russian Institute for Public Networks, and .su domains persist despite efforts by ICANN to end its use in 2007.

Given .io is so incredibly popular, it’s unlikely to disappear just because of some geopolitical changes. Even if it were to be designated for retirement, it would probably stick around for another five to ten years based on existing regulations. More likely, though, special effort will be made to officially reserve .io for continued use. Heck, even if ISO drops it, it could become a regular general TLD instead. If .pizza can be a domain, surely .io can be as well.

Long story short? There are questions around the future of .io, but nothing’s been decided yet. Expect vested interests to make sure it sticks around for the foreseeable future.

hackaday.com/2024/10/23/will-i…

Un disservizio al sito 112.gov.itha bloccato l’accesso degli utenti, mostrando vari avvisi di sicurezza. Inizialmente, i browser avvertono che “la connessione non è privata”, segnalando rischi per i dati sensibili.

Successivamente, viene riportato un certificato SSL del sito è scaduto, impedendo una connessione sicura. Questo errore è dovuto alla mancata validità del certificato SSL, scaduto, mettendo in evidenza una falla nella sicurezza e richiedendo un’urgente risoluzione.

Per ripristinare il servizio, è necessario rinnovare il certificato SSL e installarne uno di nuova validità. Questo garantirà nuovamente la sicurezza della connessione, eliminando gli avvisi di pericolo dai browser.

Il 112 è il numero unico di emergenza europeo, attivo in molti paesi per contattare le forze dell’ordine, i vigili del fuoco o i soccorsi medici. Funziona 24/7 per gestire situazioni critiche come incidenti o calamità naturali, facilitando un intervento rapido ovunque.

L’inaccessibilità di un sito come 112.gov.it può ritardare l’informazione e il supporto emergenziale, rendendo fondamentale risolvere il disservizio in tempi rapidi per non compromettere l’efficienza del sistema di emergenza.

L'articolo Down per il 112, il Numero Unico Europeo per le Emergenze. Si tratta di un certificato scaduto proviene da il blog della sicurezza informatica.

L’account ufficiale della Juventus su X (precedentemente noto come Twitter) è stato recentemente hackerato, generando una serie di post falsi, tra cui l’annuncio non autorizzato dell’acquisto di Arda Güler dal Real Madrid.

Questi tweet, scritti anche in turco, citavano il Fenerbahçe, vecchio club del calciatore, in una mossa chiaramente orchestrata per ingannare i fan.

In risposta, il club bianconero ha rapidamente avvisato i suoi sostenitori tramite il proprio account italiano, confermando l’attacco hacker e invitando alla prudenza. Questo attacco sottolinea l’importanza di mantenere un alto livello di sicurezza anche per gli account social delle principali società sportive, che rappresentano obiettivi attraenti per gli hacker a causa della loro grande visibilità e dell’enorme base di fan.

Non è la prima volta che un club di calcio viene preso di mira dai cybercriminali. Attacchi simili hanno colpito in passato altre squadre di alto livello, creando confusione tra i tifosi e minando la reputazione digitale dei club. Gli hacker spesso sfruttano la notorietà delle squadre per diffondere disinformazione o promuovere contenuti falsi, come successo nel caso della Juventus.

In particolare, l’annuncio fittizio riguardante Arda Güler ha creato scalpore, considerando il trasferimento del giocatore dal Fenerbahçe al Real Madrid nel luglio 2023. Molti fan, inizialmente ingannati dal post, hanno espresso stupore e confusione prima che la Juventus confermasse la natura fraudolenta dei tweet.

Gli attacchi informatici contro le squadre di calcio rappresentano una sfida crescente per la gestione della reputazione e della sicurezza online. Con sempre più squadre che utilizzano i social media come principale canale di comunicazione con i fan, la protezione di queste piattaforme diventa cruciale per evitare episodi simili.

In conclusione, l’incidente serve come monito sull’importanza di strategie di difesa adeguate contro le minacce digitali. La Juventus, come molti altri club, dovrà continuare a investire in soluzioni di cybersecurity per prevenire ulteriori violazioni.

Anche se non sappiamo se l’account della Juventus avesse abilitato la MFA, tu che stai ridendo perché sei di una squadra avversaria, hai attivato la Multi Factor Authentication?

L'articolo L’Account X della Juventus è stato Hackerato! Ma la Multi Factor Authentication (MFA)? proviene da il blog della sicurezza informatica.

Introduction

Lazarus APT and its BlueNoroff subgroup are a highly sophisticated and multifaceted Korean-speaking threat actor. We closely monitor their activities and quite often see them using their signature malware in their attacks — a full-feature backdoor called Manuscrypt. According to our research, Lazarus has been employing this malware since at least 2013 and we’ve documented its usage in 50+ unique campaigns targeting governments, diplomatic entities, financial institutions, military and defense contractors, cryptocurrency platforms, IT and telecommunication operators, gaming companies, media outlets, casinos, universities, and even security researchers — the list goes on.

On May 13, 2024, our consumer-grade product Kaspersky Total Security detected a new Manuscrypt infection on the personal computer of a person living in Russia. Since Lazarus rarely attacks individuals, this piqued our interest and we decided to take a closer look. We discovered that prior to the detection of Manuscrypt, our technologies also detected exploitation of the Google Chrome web browser originating from the website detankzone[.]com. On the surface, this website resembled a professionally designed product page for a decentralized finance (DeFi) NFT-based (non-fungible token) multiplayer online battle arena (MOBA) tank game, inviting users to download a trial version. But that was just a disguise. Under the hood, this website had a hidden script that ran in the user’s Google Chrome browser, launching a zero-day exploit and giving the attackers complete control over the victim’s PC. Visiting the website was all it took to get infected — the game was just a distraction.

We were able to extract the first stage of the attack — an exploit that performs remote code execution in the Google Chrome process. After confirming that the exploit was based on a zero-day vulnerability targeting the latest version of Google Chrome, we reported our findings to Google the same day. Two days later, Google released an update and thanked us for discovering this attack.

Acknowledgement for finding CVE-2024-4947 (excerpt from the security fixes included into Chrome 125.0.6422.60)

Having notified Google about the discovered vulnerability, we followed responsible vulnerability disclosure policy and refrained from sharing specific details in public, giving users sufficient time to apply the patch. This approach is also intended to prevent further exploitation by threat actors. Google took additional steps by blocking detankzone[.]com and other websites linked to this campaign, ensuring that anyone attempting to access these sites — even without our products — would be warned of their malicious nature.

While we respected Google’s request for a set disclosure period, on May 28, 2024, Microsoft published a blog post titled “Moonstone Sleet emerges as new North Korean threat actor with new bag of tricks,” which partially revealed our findings. According to the blog, Microsoft had also been tracking the campaign and associated websites since February 2024. However, their analysis overlooked a key point in the malicious campaign: the presence of the browser exploit and the fact that it was a high-severity issue — a zero-day. In this report, we explore in great detail the vulnerabilities exploited by the attackers and the game they used as bait (spoiler alert: we had to develop our own server for this online game).

The exploit

The website used by the attackers as a cover for their campaign was developed in TypeScript/React, and one of its
index.tsx files contained a small piece of code that loads and executes the Google Chrome exploit.

Website facade and the hidden exploit loader

The exploit contains code for two vulnerabilities: the first is used to gain the ability to read and write Chrome process memory from the JavaScript, and the second is used to bypass the recently introduced V8 sandbox.

First vulnerability (CVE-2024-4947)

The heart of every web browser is its JavaScript engine. The JavaScript engine of Google Chrome is called V8 — Google’s own open-source JavaScript engine. For lower memory consumption and maximum speed, V8 uses a fairly complex JavaScript compilation pipeline, currently consisting of one interpreter and three JIT compilers.

V8’s JavaScript compilation pipeline

When V8 starts to execute JavaScript, it first compiles the script into bytecode and executes it using the interpreter called Ignition. Ignition is a register-based machine with several hundred instructions. While executing bytecode, V8 monitors the program’s behavior, and may JIT-compile some functions for better performance. The best and fastest code is produced by TurboFan, a highly optimizing compiler with one drawback — the code generation takes too much time. Still, the difference in performance between Ignition and TurboFan was so significant that a new non-optimizing JIT compiler was introduced in 2021 called Sparkplug, which compiles bytecode into equivalent machine code almost instantly. Sparkplug-generated code runs faster than the interpreter, but the performance gap between Sparkplug- and TurboFan-generated code was still big. Because of this, in Chrome 117 (released in Q4 2023), the developers introduced a new optimizing compiler, Maglev, whose goal is to generate good enough code fast enough by performing optimizations based solely on feedback from the interpreter. CVE-2024-4947 (issue 340221135) is the vulnerability in this new compiler.

To understand this vulnerability and how it was exploited, let’s take a look at the code the attackers used to trigger it.
import * as moduleImport from 'export var exportedVar = 23;';

function trigger() {
moduleImport.exportedVar;
const emptyArray = [1, 2];
emptyArray.pop();
emptyArray.pop();
const arrHolder = {xxarr: doubleArray, xxab: fakeArrayBuffer};

function f() {
try {
moduleImport.exportedVar = 3.79837e-312;
} catch (e) { return false; }
return true;
}

while (!f()) { }

weakRef = new WeakRef(moduleImport);
return {emptyArray, arrHolder};
}

Code used by the attackers to trigger CVE-2024-4947

We can see in this code that it first accesses the exported variable
exportedVar of the moduleImport module and then creates the emptyArray array and the arrHolder dictionary. However, it seems that no real work is done with them, they are just returned by the function trigger. And then something interesting happens – the f function is executed until it returns “true”. However, this function returns “true” only if it can set the exported variable moduleImport.exportedVar to the “3.79837e-312” value, and if an exception occurs because of this, the f function returns “false”. How could it be that executing the same expression moduleImport.exportedVar = 3.79837e-312; should always return “false” until it returns “true”?LdaImmutableCurrentContextSlot
[53]Star1
LdaConstant
[0]SetNamedProperty r1, [1], [0] // moduleImport.exportedVar = 3.79837e-312;

Bytecode produced by the Ignition interpreter for “moduleImport.exportedVar = 3.79837e-312;”

If we take a look at the bytecode produced for this expression by Ignition and at the code of the
SetNamedProperty instruction handler, which is supposed to set this variable to the “3.79837e-312” value, we can see that it will always throw an exception — according to the ECMAScript specification, storing in a module object is always an error in JavaScript.mov rax, 309000D616Dh // JS object ptr for "moduleImport"
mov edi, [rax+3]
add rdi, r14
mov rax, 309001870B5h // JS object ptr for "3.79837e-312"
mov [rdi-1], eax

JIT code produced by Maglev for “moduleImport.exportedVar = 3.79837e-312;”

But if we wait until this bytecode has been executed enough times and V8 decides to compile it using the Maglev compiler, we’ll see that the resulting machine code doesn’t throw an exception, but actually sets this property somewhere in the
moduleImport object. This happens due to a missing check for storing to module exports — which is the CVE-2024-4947 vulnerability (you can find the fix here). How do attackers exploit it? To answer this, we need to understand how JavaScript objects are represented in memory.

Structure of JS objects

All JS objects begin with a pointer to a special object called
Map (also known as HiddenClass) which stores meta information about the object and describes its structure. It contains the object’s type (stored at a +8 offset), number of properties, and so on.

Structure of the “moduleImport” JS object

The
moduleImport module is represented in memory as a JSReceiver object, which is the most generic JS object and is used for types for which properties can be defined. It includes a pointer to the array of properties (PropertyArray) which is basically a regular JS object of the FixedArray type with its own Map. If in the expression moduleImport.exportedVar = 3.79837e-312; moduleImport was not a module but a regular object, the code would set the property #0 in that array, writing at a +8 offset; however, since it is a module and there is a bug, the code sets this property, writing at a +0 offset, overwriting the Map object with the provided object.

Structure of the “3.79837e-312” number JS object

Since 3.79837e-312 is a floating-point number, it is converted to a 64-bit value (according to the IEEE 754 standard) and stored in a
HeapNumber JS object at a +4 offset. This allows the attackers to set their own type for the PropertyArray object and cause a type confusion. Setting the type to 0xB2 causes V8 to treat the PropertyArray as a PropertyDictionary, which results in memory corruption because the PropertyArray and PropertyDictionary objects are of different sizes and the kLengthAndHashOffset field of the PropertyDictionary falls outside the bounds of the PropertyArray.
Now the attackers need to get the right memory layout and corrupt something useful. They defragment the heap and perform the actions that you can see in the
trigger function.

Memory layout created by the “trigger” function

What happens in this function is the following:

1. It accesses the exported module variable moduleImport.exportedVar to allocate moduleImport’s PropertyArray.
2. It creates an emptyArray with two elements.
3. Removing elements from this array reallocates the object that is used for storing the elements and sets emptyArray’s length to 0. This is an important step because in order to overwrite emptyArray’s length with PropertyDictionary’s hash, the length/hash must be equal to 0.
4. The trigger function creates the arrHolder dictionary with two objects. This step follows the creation of the emptyArray to allow the pointers of these two objects to be accessed and overwritten when the length of emptyArray is corrupted. The first object, xxarr: doubleArray is used to construct a primitive for getting the addresses of JS objects. The second object, xxab: fakeArrayBuffer is used to construct a primitive for getting read/write access to the whole address space of the Chrome process.
5. Next, the trigger function executes the f function until it is compiled by Maglev, and overwrites the type of the PropertyArray so it is treated as a PropertyDictionary object.
6. Executing new WeakRef(moduleImport) triggers the calculation of PropertyDictionary’s hash, and the length of emptyArray is overwritten with the hash value.
7. The trigger function returns emptyArray and arrHolder containing objects that can be overwritten with emptyArray.

After this, the exploit again abuses Maglev, or rather the fact that it optimizes the code based on the feedback collected by the interpreter. The exploit uses Maglev to compile a function that loads a
double value from an array obtained using arrHolder.xxarr. When this function is compiled, the attackers can overwrite the pointer to an array obtained using arrHolder.xxarr via emptyArray[5] and use this function to get the addresses of JS objects. Similarly, the attackers use arrHolder.xxab to compile a function that sets specific properties and overwrites the length of another ArrayBuffer-type object along with the pointer to its data (backing_store_ptr). This becomes possible when the pointer to the object accessible via arrHolder.xxab is replaced via emptyArray[6] with a pointer to the ArrayBuffer. This gives the attackers read and write access to the entire address space of the Chrome process.

Second vulnerability (V8 sandbox bypass)

At this point, the attackers can read and write memory from JavaScript, but they need an additional vulnerability to bypass the newly introduced V8 (heap) sandbox. This sandbox is purely software-based and its main function is to isolate the V8 memory (heap) in such a way that attackers cannot access other parts of the memory and execute code. How does it do this? You may have noticed that all the pointers in the previous section are 32 bits long. This is not because we’re talking about a 32-bit process. It’s a 64-bit process, but the pointers are 32 bits long because V8 uses something called pointer compression. The pointers are not stored in full, but just as their lower parts, or they could also be seen as a 32-bit offset from some “base” address. The upper part (the “base” address) is stored in CPU registers and added by the code. In this case, attackers should not be able to obtain real pointers from the isolated memory and have no way to obtain addresses for the stack and JIT-code pages.

To bypass the V8 sandbox, the attackers used an interesting but very common vulnerability associated with interpreters — we have previously seen variations of this vulnerability in multiple virtual machine implementations. In V8, regular expressions are implemented using its own interpreter, Irregexp, with its own set of opcodes. The Irregexp VM is completely different from Ignition, but it is also a register-based VM.
RegisterT& operator[](size_t index) { return registers_[index]; }

BYTECODE(PUSH_REGISTER) {
ADVANCE(PUSH_REGISTER);
if (!backtrack_stack.push(registers[LoadPacked24Unsigned(insn)])) {
return MaybeThrowStackOverflow(isolate, call_origin);
}
DISPATCH();
}

BYTECODE(SET_REGISTER) {
ADVANCE(SET_REGISTER);
registers[LoadPacked24Unsigned(insn)] = Load32Aligned(pc + 4);
DISPATCH();
}

Examples of vulnerable code in Irregexp VM instruction handlers

The vulnerability is that the virtual machine has a fixed number of registers and a dedicated array for storing them, but the register indexes are decoded from the instruction bodies and are not checked. This allows attackers to access the memory outside the bounds of the register array.
PUSH_REGISTER r(REGISTERS_COUNT + idx)
POP_REGISTER r(0)
PUSH_REGISTER r(REGISTERS_COUNT + idx + 1)
POP_REGISTER r(1)
// Overwrite "output_registers" ptr
SET_REGISTER r(REGISTERS_COUNT), holderAddressLow
SET_REGISTER r(REGISTERS_COUNT + 1), holderAddressHigh
// Overwrite "output_register_count"
SET_REGISTER r(REGISTERS_COUNT + 2), 2
// MemCopy(output_registers_, registers_.data(), output_register_count_ * sizeof(RegisterT));
SUCCEED

Malicious Irregexp VM bytecode for reading the memory outside of the register array bounds

Coincidentally, the pointers to
output_registers and output_register_count are located right next to the register array. This allows the attackers to read and write the memory outside of the V8 sandbox with the help of the SUCCEED opcode. Attackers use this to overwrite JIT’ed code with shellcode and execute it.
This issue (330404819) was submitted and fixed in March 2024. It is unknown whether it was a bug collision and the attackers discovered it first and initially exploited it as a 0-day vulnerability, or if it was initially exploited as a 1-day vulnerability.

Shellcode

At this point, the attackers need additional vulnerabilities to escape the Chrome process and gain full access to the system. In the best practices of sophisticated attackers, they run a validator in the form of a shellcode that collects as much information as possible and sends it to the server to decide whether to provide the next stage (another exploit) or not. This decision is made based on the following information: CPUID information (vendor, processor name, etc), whether it’s running on a VM or not, OS version and build, number of processors, tick count, OS product type, whether it’s being debugged or not, process path, file version info of system modules, file version info of process executable, and SMBIOS firmware table.

By the time we analyzed the attack, the attackers had already removed the exploit from the decoy website, preventing us from easily obtaining the next stage of the attack. At Kaspersky, we possess technologies that have allowed us to discover and help to fix a huge number of 0-day privilege escalation vulnerabilities exploited by sophisticated attackers in various malware campaigns over the years; however, in this particular case we would have to wait for the next attack in order to extract its next stage. We’ve decided to not wait, preferring to let Google fix the initial exploit used to perform the remote code execution in Google Chrome.

List of in-the-wild 0-days caught and reported by Kaspersky over the past 10 years

Social activity

What never ceases to impress us is how much effort Lazarus APT puts into their social engineering campaigns. For several months, the attackers were building their social media presence, regularly making posts on X (formerly Twitter) from multiple accounts and promoting their game with content produced by generative AI and graphic designers.

Attackers’ accounts on X

One of the tactics used by the attackers was to contact influential figures in the cryptocurrency space to get them to promote their malicious website and most likely to also compromise them.

Attackers’ attempts to contact crypto-influencers

The attackers’ activity was not limited to X — they also used professionally designed websites with additional malware, premium accounts on LinkedIn, and spear phishing through email.

The game

Malicious website offering to download a beta version of the game

What particularly caught our attention in this attack was that the malicious website attacking its visitors using a Google Chrome zero-day was inviting them to download and try a beta version of a computer game. As big computer games fans ourselves, we immediately wanted to try it. Could the attackers have developed a real game for this campaign? Could this be the first computer game ever developed by a threat actor? We downloaded
detankzone.zip and it looked legit: the 400 MB-archive contained a valid file structure of a game developed in Unity. We unpacked the game’s resources and found “DeTankZone” logos, HUD elements, and 3D model textures. Debugging artifacts indicated that the game had been compiled by the attackers. We decided to give it a spin.

Start menu of the DeTankZone game

After an intro with the game’s logo, we are greeted with a typical online gaming start menu, asking us to enter valid account credentials to access the game. We tried to log in using some common account names and passwords, and then tried to register our own account through the game and the website — but nothing worked.

Is that really all this game has to offer? We started reverse engineering the game’s code and discovered that there was more content available beyond this start menu. We found the code responsible for communication with the game server and started reverse engineering that as well. The game was hardcoded to use the server running at “api.detankzone[.]com,” which clearly wasn’t working. But we really wanted to check this game out! What to do? We decided to develop our own game server, of course.

First, we discovered that the game uses the Socket.IO protocol to communicate with the server, so we chose the
python-socketio library to develop our own server. We then found a function with a list of all supported command names (event names) and reverse engineered how they are obfuscated. After that, we reverse engineered how the data was encoded: it turned out to be a JSON encrypted with AES256 and encoded with Base64. For the AES key it uses the string “Full Stack IT Service 198703Game”, while the string “MatGoGameProject” is used for the IV. We hoped that this information might reveal the identities of the game’s developers, but a Google search yielded no results. Finally, we reverse engineered the data format for a couple of commands, implemented them on our server, and replaced the server URL with the address of our own server. Success! After all this we were able to log into the game and play with the bots!

Screenshot from the game running with our custom server

Yes, it turned out to be a real game! We played it for a bit and it was fun — it reminded us of some shareware games from the early 2000s. Definitely worth the effort. The textures look a little tacky and the game itself closely resembles a popular Unity tutorial, but if Lazarus had developed this game themselves, it would have set a new bar for attack preparation. But no — Lazarus stayed true to themselves. It turns out that the source code for this game was stolen from its original developers.

The original game

DeFiTankLand (DFTL) – the original game

We found a legitimate game that served as a prototype for the attacker’s version – it’s called DeFiTankLand (DFTL). Studying the developers’ Telegram chat helped us build a timeline of the attack. On February 20, 2024, the attackers began their campaign, advertising their game on X. Two weeks later, on March 2, 2024, the price of the DeFiTankLand’s currency, DFTL2 coin, dropped, and the game’s developers announced on their Telegram that their cold wallet had been hacked and $20,000 worth of DFTL2 coins had been stolen. The developers blamed an insider for this. Insider or not, we suspect that this was the work of Lazarus, and that before stealing the coins they first stole the game’s source code, modified all the logos and references to DeFiTankLand, and used it to make their campaign more credible.

Conclusions

Lazarus is one of the most active and sophisticated APT actors, and financial gain remains one of their top motivations. Over the years, we have uncovered many of their attacks on the cryptocurrency industry, and one thing is certain: these attacks are not going away. The attackers’ tactics are evolving and they’re constantly coming up with new, complex social engineering schemes. Lazarus has already successfully started using generative AI, and we predict that they will come up with even more elaborate attacks using it. What makes Lazarus’s attacks particularly dangerous is their frequent use of zero-day exploits. Simply clicking a link on a social network or in an email can lead to the complete compromise of a personal computer or corporate network.

Historically, half of the bugs discovered or exploited in Google Chrome and other web browsers have affected its compilers. Huge changes in the code base of the web browser and the introduction of new JIT compilers inevitably lead to a large number of new vulnerabilities. What can end users do about this? While Google Chrome continues to add new JIT compilers, there is also Microsoft Edge, which can run without JIT at all. But it’s also fair to say that the newly introduced V8 sandbox might be very successful at stopping bugs exploitation in compilers. Once it becomes more mature, exploiting Google Chrome with JIT may be as difficult as exploiting Microsoft Edge without it.

Indicators of Compromise

Exploit
B2DC7AEC2C6D2FFA28219AC288E4750C
E5DA4AB6366C5690DFD1BB386C7FE0C78F6ED54F
7353AB9670133468081305BD442F7691CF2F2C1136F09D9508400546C417833A

Game
8312E556C4EEC999204368D69BA91BF4
7F28AD5EE9966410B15CA85B7FACB70088A17C5F
59A37D7D2BF4CFFE31407EDD286A811D9600B68FE757829E30DA4394AB65A4CC

Domains
detankzone[.]com
ccwaterfall[.]com

securelist.com/lazarus-apt-ste…

[Sebastian Lederer] has created Tridora: an unusual stack-based CPU core intended for FPGA deployment, co-developed with its own Pascal compiler. The 32-bit word machine is unusual in that it has not one but three stacks, 16-bit instruction words, and a limited ISA, more like those of the 8-bit world. No multiply or divide instructions will be found in this CPU.

The design consists of about 500 lines of Verilog targeting the Digilent Arty-A7 FPGA board, which is based around the Xilinx Artix-7 FPGA line. [Sebastian] plans to support the Nexys A7 board, which boasts a larger FPGA array but has less RAM onboard. The CPU clocks in at 83 MHz with four clock cycles per instruction, so over 20 MIPS, which is not so shabby for a homebrew design. Wrapped around that core are a few simple peripherals, such as the all-important UART, an SD card controller and a VGA display driver. On the software side, the Pascal implementation is created from scratch with quite a few restrictions, but it can compile itself, so that’s a milestone achieved. [Sebastian] also says there is a rudimentary operating system, but at the moment, it’s a little more than a loader that’s bundled with the program image.

The Tridora Gitlab project hosts the Verilog source, an emulator (written in Golang, not Pascal) and a suite of example applications. We see quite a few custom CPUs, often using older or less popular programming languages. Here’s an FPGA-based Forth machine to get you started. Implementing programming languages from scratch is also a surprisingly common hack. Check out this from-scratch compiler for the Pretty Laughable Programming language.

hackaday.com/2024/10/23/tridor…

Milano, 23 ottobre 2024 – I dispositivi e gli account aziendali si confermano gli asset più vulnerabili agli attacchi informatici, secondo quanto rilevato da “Intercepting Impact: 2024 Trend Micro Cyber Risk Report“, l’ultimo studio condotto da Trend Micro, leader globale nella cybersecurity. Lo studio pone l’accento sull’importanza di un cambiamento di prospettiva verso un approccio alla sicurezza basato sul rischio, in un contesto di minacce in continua evoluzione.

“Con questo report vengono condivise informazioni chiave su dove le organizzazioni possono trovarsi maggiormente esposte. I cybercriminali sfruttano spesso controlli di sicurezza deboli, configurazioni errate e vulnerabilità non adeguatamente protette”. Afferma Alessandro Fontana, Country Manager di Trend Micro Italia. “Le aziende dovrebbero abbracciare un approccio olistico e proattivo alla cybersecurity, che consideri l’intera superficie di attacco. Grazie all’intelligenza artificiale, è possibile calcolare con precisione il rischio effettivo e implementare misure di mitigazione mirate, migliorando sensibilmente la postura di sicurezza. Questo approccio rappresenta un autentico punto di svolta per l’intero settore”.

Attraverso un elenco di eventi di rischio, la piattaforma Trend Vision One™ calcola un punteggio per ogni asset presente in azienda e fornisce un indice di rischio. Il calcolo avviene confrontando variabili come la possibilità di subire un attacco, l’esposizione e la configurazione di sicurezza, con l’impatto che l’asset ha nell’organizzazione. Un asset con un basso impatto aziendale e pochi privilegi ha una superficie di attacco piccola, mentre un asset di valore elevato con più privilegi, ha una superficie di attacco ampia.

Questi gli asset più a rischio:

• Dispositivi: 22,6 milioni di dispositivi totali, di cui 877.316 classificati ad alto rischio
• Account: 53,9 milioni di account totali, di cui 12.346 classificati ad alto rischio
• Asset cloud: 14,5 milioni di asset cloud totali, di cui 9.944 classificati ad alto rischio
• Asset Internet: 1,1 milioni in totale, di cui 1.661 classificati ad alto rischio
• Application: 8,8 milioni di application totali, di cui 489 classificate ad alto rischio

Il numero di dispositivi ad alto rischio è molto superiore a quello degli account, anche se il numero totale di account è maggiore. I dispositivi hanno una superficie di attacco più ampia e possono essere presi di mira da più minacce. Tuttavia, gli account sono ancora preziosi in quanto possono garantire ai cybercriminali l’accesso a svariate risorse.

Lo studio sottolinea anche che:

• Le Americhe hanno l’indice di rischio medio più alto, con un punteggio di 43,4. Questo è determinato dalle vulnerabilità del settore bancario e delle infrastrutture critiche, oltre che dall’attrazione che la regione esercita nei confronti dei cybercriminali orientati al profitto
• L’Europa è la regione che risolve le vulnerabilità più rapidamente. Questo è indice di pratiche di sicurezza robuste
• L’industria mineraria ha il punteggio di rischio più elevato tra i settori verticali, grazie alla sua posizione strategica nella supply chain globale e all’ampia superficie di attacco
• Il settore farmaceutico è il più veloce nel correggere le vulnerabilità. Questo riflette l’importanza di proteggere i dati sensibili
• Il principale evento di rischio rilevato è l’accesso alle applicazioni cloud che hanno un livello di rischio elevato a causa della loro cronologia di dati e delle funzionalità di sicurezza note
• Altri eventi ad alto rischio che capitano frequentemente sono quelli che sfruttano account vecchi e inattivi, account con controlli di sicurezza disabilitati o che hanno inviato all’esterno dati sensibili

Lo studio ha inoltre scoperto molte configurazioni deboli che potrebbero portare a delle compromissioni, in particolare per quanto riguarda le impostazioni di controllo della security.

Il panorama delle minacce continua a evolversi e la capacità delle organizzazioni di identificare e gestire i rischi è sempre più cruciale. La piattaforma Trend Vision One™, grazie alla funzione integrata di Attack Surface Risk Management (ASRM), fornisce gli strumenti necessari per una visibilità completa sulle minacce e per mitigare il rischio in maniera efficace.

Per mitigare i rischi cyber, Trend Micro suggerisce le seguenti procedure:

• Ottimizzare le impostazioni di sicurezza dei prodotti per ricevere avvisi su configurazioni errate
• Contattare il proprietario del dispositivo e/o dell’account per verificare qualsiasi evento rischioso. L’evento può essere esaminato utilizzando la funzione di ricerca di Trend Vision One™ Workbench, per trovare ulteriori informazioni o verificare i dettagli dell’evento sul server di gestione del prodotto
• Disattivare gli account rischiosi o reimpostarli con una password forte e attivare l’autenticazione a più fattori (MFA)
• Applicare regolarmente le patch più recenti e aggiornare le versioni dell’applicazione e del sistema operativo

Il report si basa sui dati di telemetria della soluzione Attack Surface Risk Management (ASRM) di Trend Micro, disponibile all’interno della piattaforma per la sicurezza informatica Trend Vision One e sugli strumenti nativi eXtended Detection and Response (XDR). Lo studio si divide in due sezioni: la prima esamina il punto di vista dell’utente e approfondisce i rischi di asset, processi e vulnerabilità, mentre la seconda mappa i comportamenti dei cybercriminali, i parametri MITRE e TTP. I dati di telemetria prendono in considerazione il periodo tra il 25 dicembre 2023 e il 30 giugno 2024.

Ulteriori informazioni sono disponibili a questo link

L'articolo Dispositivi e Account sotto Attacco: il report di Trend Micro svela le ultime Vulnerabilità proviene da il blog della sicurezza informatica.

Il regolatore irlandese di Internet e dei media Coimisiún na Meán ha adottato e pubblicato un codice di sicurezza online , che entrerà in vigore dal mese prossimo. Il documento riguarderà le più grandi piattaforme video le cui sedi si trovano nel paese, tra cui TikTok di ByteDance, YouTube di Google e Instagram e Facebook Reels di Meta.

Secondo le disposizioni del Codice, le piattaforme sono tenute a includere nelle loro condizioni di utilizzo il divieto di pubblicazione e distribuzione di una serie di contenuti dannosi, come il cyberbullismo, la promozione del suicidio o di disordini alimentari, nonché contenuti che incitano all’odio, violenza, terrorismo, contenente materiale su abusi sessuali su minori, razzismo e xenofobia.

Adam Hurley, portavoce di Coimisiún na Meán, ha spiegato che il nuovo Codice integra la legge europea sui servizi digitali (DSA). A differenza della legislazione europea, che si concentra sulla lotta ai contenuti illegali, il documento irlandese copre una gamma più ampia di materiali potenzialmente pericolosi.

Anche se tecnicamente il Codice si applica solo ai servizi video che forniscono servizi agli utenti in Irlanda, le aziende tecnologiche possono applicare misure simili in tutta la regione per semplificare il processo di conformità e prevenire problemi di standard di contenuto incoerenti.

È importante notare che la legislazione dell’UE vieta l’imposizione di obblighi generali di monitoraggio dei contenuti sulle piattaforme. Secondo Hurley, il codice irlandese non richiede l’implementazione di filtri di avvio, ma espande l’attuale approccio di notifica e rimozione consentendo agli utenti di segnalare contenuti dannosi per il follow-up.

Verifica dell’età per la pornografia

Il documento presta particolare attenzione alla tutela dei minori. Le piattaforme video che consentono la pubblicazione di contenuti pornografici o di violenza gratuita devono implementare sistemi di verifica dell’età “appropriati”. Il regolatore valuterà le tecnologie utilizzate su base individuale.

Inoltre, i siti sono tenuti a creare sistemi di classificazione dei contenuti e a fornire il controllo parentale per i materiali che possono influenzare negativamente lo sviluppo fisico, mentale o morale dei bambini sotto i 16 anni di età.

Sistemi di raccomandazione

Inizialmente l’autorità di regolamentazione aveva considerato di richiedere alle piattaforme video di disabilitare per impostazione predefinita le raccomandazioni sui contenuti basate sulla profilazione. Tuttavia, a seguito delle consultazioni dello scorso anno, la misura non è stata inclusa nella versione finale del Codice. Le questioni relative ai sistemi di raccomandazione saranno invece regolate dalla legge paneuropea sui servizi digitali.

Il Codice di sicurezza online fa parte del quadro normativo digitale generale dell’Irlanda per proteggere gli utenti dalle minacce online. Il documento opera parallelamente alla legge europea sui servizi digitali, applicata anche da Coimisiún na Meán.

Secondo il commissario irlandese per la sicurezza online Niamh Hodnett, l’adozione del codice segna la fine dell’era dell’autoregolamentazione dei social network. L’autorità di regolamentazione intende informare i cittadini sui loro diritti su Internet e ritenere le piattaforme responsabili del mancato rispetto dei requisiti stabiliti.

L'articolo L’Irlanda Contro il Cyber Bullismo! Nuove regole Per TikTok, YouTube e Meta! proviene da il blog della sicurezza informatica.

It’s likely that many Hackaday readers will have had their interest in electronics as a child honed by exposure to an electronics kit. The type of toy that featured a console covered in electronic components with spring terminals, and on which a variety of projects could be built by wiring up circuits. [Matthew North Music] has a couple of these, and he’s made a video investigating whether they can be used to make music.

The kits he’s found are a Radio Shack one from we’re guessing the 1970s, and a “Cambridge University Recording Studio” kit that looks to be 1990s-vintage. The former is all discrete components and passive, while the latter sports that digital audio record/playback chip that was the thing to have in a novelty item three decades ago. With them both he can create a variety of oscillator and filter circuits, though for the video he settles for a fairly simple tone whose pitch is controlled by an light-dependent resistor, and a metronome as a drum beat.

The result is a little avant garde, but certainly shows promise. The beauty of these kits is they can now be had for a song, and as grown-ups we don’t have to follow the rules set out in the book, so we can see there’s a lot of fun to be had. We look forward to some brave soul using them in a life performance at a hacker camp.

youtube.com/embed/4-5OS5oOVbo?…

hackaday.com/2024/10/23/75-in-…

Gli anniversari, siano essi personali o professionali, offrono l’opportunità di riflettere sui progressi e di immaginare nuovi orizzonti. Nel 2024, il programma Common Vulnerabilities and Exposures (CVE) celebra 25 anni di attività. Fondato nel 1999, CVE si è trasformato da un progetto limitato a una risorsa globale fondamentale per identificare e affrontare le vulnerabilità informatiche, espandendosi fino a oltre 400 CVE Numbering Authorities (CNA) in più di 40 paesi. (In Italia ancora Zero!).

L’espansione delle CNA ha consentito una copertura geografica più ampia e una comprensione più profonda delle vulnerabilità regionali. Questo ha migliorato la capacità delle organizzazioni di identificare, monitorare e mitigare le minacce a livello locale. L’automazione, introdotta negli ultimi anni, ha ulteriormente potenziato la velocità e la qualità con cui i CVE vengono assegnati e aggiornati, permettendo una risposta più rapida alle minacce.

Nonostante questi progressi, ci sono ancora sfide da affrontare, come il miglioramento delle relazioni con la comunità open-source. In passato, il programma CVE ha sofferto di arretrati e lunghi tempi di attesa, generando sfiducia. Oggi, però, la collaborazione con grandi fondazioni open-source, come la Apache e la Python Software Foundation, ha rafforzato i legami e migliorato il processo di segnalazione delle vulnerabilità.

Un’altra sfida riguarda la percezione negativa delle vulnerabilità. Alcune organizzazioni sono riluttanti a rivelarle tempestivamente per timore di reazioni negative da parte dei clienti, ma questa concezione è superata. Anche se non è ancora così per tutte le aziende, la trasparenza nella gestione delle vulnerabilità dimostra impegno verso la sicurezza e protezione degli utenti, un segno di maturità e non di debolezza.

Le origini del programma CVE

Fondato nel 1999, il programma CVE è nato dalla necessità di standardizzare la denominazione delle vulnerabilità, che fino a quel momento erano identificate in modo disomogeneo dai vari fornitori di software.

L’obiettivo principale era quello di facilitare la condivisione dei dati tra le organizzazioni e consentire una gestione più efficace delle vulnerabilità. Questo ha portato alla creazione di un elenco centralizzato di vulnerabilità pubblicamente divulgate, utilizzato oggi da aziende, governi e ricercatori di tutto il mondo.

Con la rapida crescita del settore informatico, anche il numero di vulnerabilità è aumentato esponenzialmente. Nel 2016, il programma CVE ha attraversato una trasformazione significativa, adottando un modello federato che ha permesso a una rete più ampia di CNA di pubblicare i propri record di vulnerabilità.

Questo cambiamento ha accelerato la capacità di assegnare CVE ID e ha migliorato la qualità e la velocità con cui le informazioni sulle vulnerabilità vengono condivise.

L’impatto del programma sulle industrie globali

Oggi, il programma CVE è essenziale per molte industrie, dalle tecnologie di rete ai dispositivi IoT, fino ai settori più sensibili come la sanità e l’energia. Le vulnerabilità segnalate dai CNA vengono integrate in strumenti di gestione della sicurezza, sistemi di monitoraggio degli eventi e piattaforme di risposta agli incidenti. Questo approccio unificato ha permesso di migliorare l’efficacia delle difese informatiche globali, riducendo il tempo necessario per mitigare le minacce.

Uno degli sviluppi più significativi degli ultimi anni è stato l’incremento della partecipazione della comunità open source. Grandi organizzazioni come la Python Software Foundation e la Apache Software Foundation hanno aderito come CNA, contribuendo alla segnalazione tempestiva di vulnerabilità nei loro progetti.

Questo rafforza il ruolo del programma CVE nel supportare la sicurezza dei software open source, che oggi rappresentano una parte fondamentale dell’infrastruttura digitale globale.

Le sfide future: intelligenza artificiale e nuove minacce

Mentre il programma CVE guarda al futuro, nuove sfide stanno emergendo, tra cui l’aumento delle vulnerabilità legate all’intelligenza artificiale (IA).

La crescente adozione dell’IA nelle operazioni informatiche porta con sé nuove categorie di minacce, che richiedono un adattamento delle metodologie di identificazione delle vulnerabilità. Il programma CVE dovrà continuare a innovare e collaborare con esperti del settore per affrontare questi nuovi rischi.

Conclusioni: un pilastro per i prossimi 25 anni

Il programma CVE ha dimostrato, nel corso dei suoi 25 anni, di essere un punto di riferimento imprescindibile per la gestione delle vulnerabilità.

Con l’evoluzione continua del panorama delle minacce informatiche, il programma dovrà affrontare nuove sfide, ma la sua missione rimarrà invariata: identificare, definire e catalogare le vulnerabilità per proteggere la comunità globale. Guardando al futuro, CVE continuerà a essere un attore chiave nel rafforzamento delle difese digitali mondiali.

L'articolo Un Mare di Vulnerabilità! Auguri ai 25 Anni del CVE Program mentre in Italia Ancora Zero CNA proviene da il blog della sicurezza informatica.

Nei dibattiti pubblici la Cina viene spesso rappresentata come un monolite. Un potere rappresentato dal Partito-Stato che domina dall’alto sia le dinamiche interne al suo Paese che quelle con gli altri stati. A causa delle crescenti restrizioni imposte dalle autorità cinesi, accentuate dalla crisi pandemica, gli studiosi della Cina incontrato sempre maggiori difficoltà nello studio dei temi politici e sociali.

Per questo motivo, i ricercatori si sono focalizzati su una particolare macroarea delle politiche del gigante orientale: le sue attività verso l’estero. L’analisi delle dinamiche di questa macroarea ha fatto ipotizzare l’esistenza di un livello meno conosciuto e spesso trascurato, definito “ventre molle della Cina globale“, che rappresenta la Cina al di fuori della Cina.

Principalmente, l’attenzione mediatica si concentra su aspetti come il commercio internazionale e la geopolitica. Il “ventre molle della Cina” include anche le attività delle organizzazioni criminali cinesi all’estero, i flussi finanziari illeciti generati e le loro interazioni con le controparti locali.

Il gruppo di esperti dietro l’inchiesta

La ricerca condotta da Ivan Franceschini (Asia Institute, University of Melbourne), Ling Li (Università Ca’ Foscari di Venezia) e Mark Bo (Inclusive Development International), è pubblicata sulla rivista scientifica OrizzonteCina.

Dalla Cina al Sud-est asiatico: la migrazione del cybercrimine

L’industria delle truffe online affonda le sue radici negli anni ’90 nell’isola di Taiwan, per spostarsi poi nella Cina continentale. Tra il 2005 e il 2010 la crescente pressione delle autorità cinesi e taiwanesi ha spinto le organizzazioni criminali a spostare le operazioni (e i server) verso il Sud-est asiatico, in paesi come Cambogia, Filippine, Laos, Myanmar, Thailandia e Vietnam, attratte da costi di manodopera più bassi e da un contesto normativo spesso più permissivo.

Organizzazioni

A gestire i compound sono organizzazioni criminali provenienti prevalentemente dalla Cina continentale e da Taiwan. Inizialmente piccole e poco strutturate, si sono evolute nel tempo trasformandosi in veri e propri cluster criminali. Raggruppandosi in aree specifiche, hanno dato vita alle cosiddette Scam City o Compound City, “fortezze” costruite in zone rurali ben sorvegliate dove centinaia a volte migliaia di persone lavorano giorno e notte, generando un’economia di agglomerazione illegale. La crescita esponenziale dell’industria delle truffe ha favorito l’integrazione con il settore del gioco d’azzardo online. Questo connubio, facilitato dalla presenza di un’infrastruttura di rete sviluppata e dalla disponibilità di manodopera ha permesso un’ulteriore espansione delle attività criminali.

Per sostenere questa crescita, i gruppi criminali hanno avuto bisogno di un ininterrotto flusso di “manodopera”. Il reclutamento avveniva e avviene spesso con metodi ingannevoli e violenti: false promesse di lavoro ben pagato attirano persone non solo dalla Cina, ma anche da altri paesi del Sud-est asiatico e, in misura crescente, da India e Africa. Una volta giunte nelle Scam City, le vittime sono private dei documenti, detenute contro la loro volontà e costrette a partecipare alle attività criminali.

Il dramma della schiavitù moderna nei compound

Il fenomeno ha ricevuto minore attenzione mediatica in Occidente. Un caso emblematico, riportato dai media inglesi nel 2021, è stato quello di una donna filippina attirata in Cambogia con la promessa di un lavoro ben pagato, poi trattenuta contro la sua volontà. La donna, che aveva risposto ad un annuncio di lavoro sui social media, fu liberata solo grazie all’intervento dei media dopo che il marito ne denunciò la scomparsa.

Lo studio di Franceschini evidenzia anche il cambiamento demografico all’interno dei compound. Se inizialmente erano popolati prevalentemente da cittadini cinesi con bassa scolarizzazione, le restrizioni alla mobilità imposte dalla Cina in risposta alla pandemia hanno spinto i gruppi criminali a cambiare strategie di reclutamento. Per trovare “manodopera”, si sono rivolti a canali clandestini come il traffico di esseri umani, reti di reclutamento illegale, ma anche a nuovi flussi migratori provenienti da altri paesi del Sud-est asiatico. Spesso persone con bassa scolarizzazione in difficoltà economiche, disposte a rischiare pur di trovare un lavoro. Alle spalle di queste organizzazioni criminali non si nascondono solo le tradizionali Triadi o Mafie cinesi, ma anche uomini di affari, milizie locali, politici e polizie locali.

La Scamdemia globale

Sebbene la moderna struttura di questa gigantesca macchina delle truffe online si sia consolidata in Cambogia e nelle Filippine, ed oggi ha il suo fulcro in Myanmar e Laos, Il fenomeno, non si limita al solo Sud-est asiatico, ma si estende ad altre regioni del mondo. Attività di questo tipo sono state documentate in Emirati Arabi Uniti, Georgia, Messico e in molti altri paesi. Queste attività criminali comprendono: truffe romantiche, investimenti fraudolenti, phishing e ransomware, hanno assunto proporzioni tali da richiedere la creazione di un neologismo: si parla di scamdemia (ingl. scamdemic, da scam, “truffa”, e pandemic, “pandemia”).

I numeri del cybercrimine

Per comprendere la vastità del fenomeno, è sufficiente analizzare i dati allarmanti forniti dal Ministero della Pubblica Sicurezza cinese. Nel 2022 i casi di frode telematica risolti dalla polizia sinofona sono aumentati del 5% rispetto il precedente anno, raggiungendo la cifra di 464.000, molti dei quali perpetrati nel Sud-est asiatico. Nel 2021, la polizia cinese ha arrestato 690.000 sospetti e restituito 1,7 miliardi di dollari americani alle vittime di truffe in tutto il Paese.

Il fenomeno non si limita alla Cina. Nel Sud-est asiatico, a Singapore, nel 2021, ai cittadini vittime di truffe tecnologiche è stata sottratta una cifra pari a 468,85 milioni di dollari americani, 2,5 volte in più rispetto all’anno precedente.

In Thailandia, fonti ufficiali dichiarano che nel 2021 le frodi telefoniche sono aumentate del 270%, con un incremento superiore al 50% di SMS fraudolenti rispetto al 2020. Le autorità thailandesi riferiscono che 800 cittadini sono truffati ogni giorno.

Il disperato appello dei banchieri thailandesi, che nel 2022 hanno dichiarato perdite pari a circa 500 milioni di baht (circa 14,5 milioni di dollari americani), ha scatenato una lotta senza quartiere ai crimini informatici.

I Risultati

I risultati di questa lotta sono stati la sospensione di 50.000 conti bancari fraudolenti, la serrata di 2.000 siti per il gioco d’azzardo e la sospensione di 118.500 numeri di telefono per l’invio di phishing.

Le scamdemie non hanno confini, si diffondono rapidamente in tutto il mondo, attraverso internet e i social media. A Hong Kong, nel 2022, le truffe relative alle criptovalute hanno fatto registrare perdite finanziarie per un ammontare di 1,7 miliardi di dollari di Hong Kong (circa 216 milioni di dollari americani), cifra pari al doppio dell’anno precedente, con 23.000 segnalazioni di reati riferiti ad attività tecnologica. A Taiwan, nella prima metà del 2022, si sono registrati 13.301 casi, nei quali sono stati sottratti in maniera fraudolenta 4,1 miliardi di dollari taiwanesi (circa 130 milioni di dollari americani). Persino l’Australia non è immune al fenomeno, come testimonia la brutta avventura di una donna australiana persuasa a investire in un tipo di criptovaluta falsa da un truffatore che ha poi sostenuto di essere trattenuto in un compound in Cambogia.

Schiavi del web: la vita all’interno dei compound

Studiare queste nuove forme di schiavitù moderna e i luoghi in cui si svolgono ha rappresentato una sfida per i ricercatori. I compound sono “fortezze” inespugnabili, dotate di sofisticati sistemi di sorveglianza. Avvicinare i sopravvissuti, è altrettanto difficile: traumatizzati e diffidenti, temono ritorsioni.

Per superare queste difficoltà, il gruppo di ricerca ha utilizzato un approccio innovativo, sfruttando gli stessi strumenti di comunicazione impiegati dalle bande criminali per il reclutamento: app di messaggistica istantanea come WeChat, Douyin, Jiandanwang e Telegram. WeChat ha permesso di seguire online gli attori cinesi legati ai compound. Douyin e Jiandanwang hanno fornito dettagli sui compound grazie a informatori anonimi. Telegram è stato usato per monitorare il traffico di esseri umani: alcuni gruppi condividevano tecniche e frasari di truffa, altri pubblicavano i prezzi per la vendita delle persone.

Sono stati utilizzati anche strumenti più tradizionali, come i media in lingua cinese, spesso più liberi di investigare. Blogger, youtuber e influencer hanno offerto spunti e informazioni attraverso video, post e commenti. Sono stati analizzati anche i registri delle imprese locali e i social media di uomini d’affari e politici, alla ricerca di complicità con le organizzazioni criminali.

Conclusioni

In conclusione, lo studio sulle Scam city mette in discussione la visione della Cina globale focalizzata esclusivamente sulle politiche ufficiali. Dall’analisi delle attività criminali come le truffe online, emerge un quadro molto complesso, con attori cinesi che agiscono in modo autonomo in un rapporto di contrasto con il Partito-Stato.

I compound, centri nevralgici di queste attività illecite, dimostrano come il potere cinese non sia monolitico e come le interazioni con gli attori locali siano fondamentali per il successo di queste operazioni. Le Scam City risultato di dinamiche transnazionale, richiedono un approccio globale.

Studiare questo “ventre molle della Cina” offre una prospettiva unica ma più ampia per comprenderne le contraddizioni e le nuove sfide, spingendoci a ripensare le nostre interpretazioni e a considerare la complessità e le dinamiche del Paese del Dragone. Questo studio, quindi, apre nuove prospettive di ricerca e sottolinea l’urgenza di una collaborazione internazionale per contrastare il cybercrimine.

Glossario

• Scam: truffa
• Compound: Riferito a strutture edificate in aree isolate e sottoposte a stretta sorveglianza, utilizzate come basi operative per le organizzazioni criminali che gestiscono le truffe online. Spesso al loro interno vengono sequestrate e sfruttate le vittime di tratta di esseri umani.
• Scamdemia: Neologismo che combina i termini inglesi “scam” (truffa) e “pandemic” (pandemia), descrivere la crescita esponenziale delle truffe online.
• Phishing: Tecnica di ingegneria sociale utilizzata per ottenere informazioni confidenziali, come password o dati bancari, spacciandosi per un ente o un’azienda affidabile.
• Cluster criminale: Insieme di organizzazioni criminali che operano nello stesso settore, in questo caso delle truffe online

L'articolo Dentro le Scam City! Come il Cybercrimine Diventa La Nuova Forma di schiavitù nel Sud-Est Asiatico proviene da il blog della sicurezza informatica.

Negli ultimi anni, il mondo della criminalità informatica ha assistito all’emergere di nuove minacce sempre più sofisticate, in grado di colpire un’ampia gamma di target. Una delle novità più preoccupanti in questo panorama è il ransomware Cicada3301, recentemente analizzato da diversi esperti di sicurezza informatica, inclusi noi del gruppo Dark Lab di Red Hot Cyber, che abbiamo avuto l’opportunità di intervistare i membri della ransomware gang dietro questa pericolosa minaccia.

L’ascesa di Cicada3301: un ransomware cross-platform

Cicada3301 non è un ransomware qualsiasi. La sua capacità di operare su sistemi Windows e Linux lo rende particolarmente pericoloso, poiché permette ai suoi operatori di colpire un’ampia varietà di infrastrutture IT, incluse quelle che tradizionalmente erano considerate più sicure, come i server Linux. L’adozione di una strategia cross-platform rappresenta un’evoluzione significativa rispetto ai ransomware tradizionali, che spesso si concentrano su una singola piattaforma.

Questa peculiarità si riflette nella struttura stessa del codice malevolo, sviluppato utilizzando linguaggi di programmazione multipiattaforma come GoLang, che consente la compilazione e l’esecuzione su diverse architetture hardware e sistemi operativi. È proprio questo che rende Cicada3301 particolarmente adattabile e letale, consentendogli di attaccare sistemi eterogenei all’interno delle reti aziendali.

Caratteristiche tecniche

Dal punto di vista tecnico, Cicada3301 si presenta con diverse caratteristiche avanzate. Innanzitutto, il ransomware utilizza algoritmi crittografici di tipo RSA-2048 e AES-256, garantendo un elevato livello di sicurezza nella cifratura dei file. Questo rende virtualmente impossibile, senza la chiave di decrittazione, ripristinare i file colpiti. Una volta eseguito sul sistema bersaglio, Cicada3301 esegue una scansione completa alla ricerca di file di valore, inclusi documenti, database e backup, colpendo anche i file di configurazione critici per il funzionamento dei servizi IT.

Uno degli aspetti più insidiosi è l’utilizzo di tattiche di movimento laterale, che permettono al malware di diffondersi rapidamente all’interno di una rete, infettando più dispositivi. Il ransomware sfrutta vulnerabilità note (CVE) nei servizi di rete e negli applicativi comunemente utilizzati nei sistemi Linux e Windows, aprendo una porta d’ingresso per ulteriori attacchi. Questa capacità di muoversi lateralmente nella rete interna aumenta notevolmente la sua efficacia, rendendo difficile fermare l’infezione una volta avviata.

Inoltre, Cicada3301 incorpora una componente di esfiltrazione dei dati. Prima di cifrare i file, il ransomware invia una copia dei dati più sensibili a server remoti controllati dagli attaccanti, creando una seconda leva per il ricatto: la minaccia di pubblicare o vendere le informazioni rubate nel caso in cui il riscatto non venga pagato. Questa doppia estorsione è una tattica ormai consolidata nelle moderne campagne ransomware.

L’intervista esclusiva di Red Hot Cyber con la gang dietro Cicada3301

Come gruppo Dark Lab di Red Hot Cyber, abbiamo avuto il privilegio di intervistare i membri della gang che si cela dietro Cicada3301. Nel corso dell’intervista, è emerso un quadro inquietante sulle motivazioni e le strategie adottate. La gang ha dichiarato che il loro obiettivo principale non sono solo le grandi corporazioni, ma anche infrastrutture critiche come ospedali, reti energetiche e pubbliche amministrazioni. La loro convinzione è che queste organizzazioni abbiano “fondi sufficienti per pagare”, ma siano anche vulnerabili per via della dipendenza da sistemi legacy e della scarsa sicurezza.

Un altro punto interessante emerso dall’intervista è che Cicada3301 sta cercando di affermarsi come un marchio all’interno del mondo del Ransomware-as-a-Service (RaaS). Offrono infatti il loro malware a affiliati tramite un modello di business che consente ai cyber criminali meno esperti di utilizzare la piattaforma per attacchi ransomware, in cambio di una percentuale sui riscatti ottenuti. Questa struttura decentralizzata permette alla gang di operare su una scala più ampia, aumentando esponenzialmente il numero di vittime potenziali.

Come difendersi da Cicada3301

Per fronteggiare minacce di questo calibro, è essenziale adottare una strategia di sicurezza olistica, che comprenda misure preventive e reattive. Tra le migliori pratiche per ridurre il rischio di infezione da Cicada3301, possiamo suggerire:

1. Aggiornamenti costanti dei sistemi e delle applicazioni per correggere le vulnerabilità conosciute.
2. Segmentazione della rete, per limitare i danni nel caso in cui un dispositivo venga compromesso.
3. Backup regolari dei dati più critici, conservati offline o su piattaforme di storage con accesso limitato.
4. Implementazione di soluzioni avanzate di rilevamento delle minacce, come l’uso di EDR (Endpoint Detection and Response) o XDR, che possono identificare movimenti laterali sospetti all’interno della rete.
5. Formazione continua del personale per prevenire attacchi di phishing e altre tattiche di ingegneria sociale, spesso utilizzate per diffondere ransomware come Cicada3301.

Conclusioni

L’evoluzione del ransomware verso un modello cross-platform come quello di Cicada3301 rappresenta un salto qualitativo che richiede una risposta altrettanto avanzata. Le aziende devono investire in misure di sicurezza proattive e innovative, poiché i criminali informatici, come quelli dietro Cicada3301, continuano a sviluppare nuove tecniche per aggirare le difese tradizionali. Noi di Red Hot Cyber continueremo a monitorare attentamente l’evoluzione di queste minacce, grazie anche alla nostra esperienza sul campo e ai contatti diretti con gli attori del cybercrime.

Questo ransomware è solo l’inizio di un futuro in cui le minacce cross-platform diventeranno sempre più comuni. Prevenire, mitigare e rispondere in modo rapido e preciso sarà la chiave per la sopravvivenza nel panorama digitale moderno.

L'articolo Cicada3301: Il nuovo ransomware cross-platform che minaccia i sistemi Windows e Linux proviene da il blog della sicurezza informatica.

[DTSS_Smudge] correctly intuits that if you are interested in an old Heathkit signal generator, you probably already know how to solder. So, in a recent video, he focused on the components he decided to update for safety and other reasons. Meanwhile, we get treated to a nice teardown of this iconic piece of test gear.

If you didn’t grow up in the 1960s, it seems strange that the device has a polarized line cord with one end connected to the chassis. But that used to be quite common, just like kids didn’t wear helmets on bikes in those days.

A lot of TVs were “hot chassis” back then, too. We were always taught to touch the chassis with the back of your hand first. That way, if you get a shock, the associated muscle contraction will pull your hand away from the electricity. Touching it normally will make you grip the offending chassis hard, and you probably won’t be able to let go until someone kindly pulls the plug or a fuse blows.

These signal generators were very common back in the day. A lot of Heathkit gear was very serviceable and more affordable than the commercial alternatives. In 1970, these cost about $32 as a kit or $60 already built. While $32 doesn’t sound like much, it is equivalent to $260 today, so not an impulse buy.

Some of the parts are simply irreplaceable. The variable capacitor would be tough to source since it is a special type. The coils would also be tough to find replacements, although you might have luck rewinding them if it were necessary.

We are spoiled today with so many cheap quality instruments available. However, there was something satisfying about building your own gear and it certainly helped if you ever had to fix it.

There was so much Heathkit gear around that even though they’ve been gone for years, you still see quite a few units in use. Not all of their gear had tubes, but some of our favorite ones did.

hackaday.com/2024/10/22/heathk…

Despite the rise of ARM processors in more and more computers from embedded systems to daily driver PCs, the x86 architecture maintains a stronghold in the computing space that won’t be going away anytime soon. One of the main drivers of this is its beachhead in industrial systems; the x86 architecture is backwards-compatible farther back than many of us have been alive and in situations where machines need to run for years with minimum downtime it’s good to know you can grab any x86 system off the shelf and it’ll largely work. This is also true for gaming, so if you’re like [Yeo Kheng Meng] and want to run games like DOOM natively on modern hardware it’s certainly possible, although there are a few catches.

This build goes into the design of a modern AMD Ryzen 5 desktop computer, with all of the components selected specifically for their use running software more than three decades old now. [Yeo Kheng Meng] is targeting DOS 6.22 as his operating system of choice, meaning that modern EFI motherboards won’t necessarily work. He’s turned to business class products as a solution for many of these issues, as motherboards targeting business and industrial customers often contain more support for antiquated hardware like PS/2 and parallel ports while still having modern amenities like DDR5 memory slots. PS/2 ports additionally are an indicator that the motherboard will supports older non-EFI boot modes (BIOS) and can potentially run DOS natively. Everything here can also run modern operating systems, since he isn’t building this system only to run DOS and retro games.

Beyond the motherboard choice, he’s also using a Soundblaster card for audio which is a design choice generally relegated to history, but still used in modern gaming by a dedicated group. There’s also a floppy drive running via a USB header adapter cable. Of course, there are a few problems running DOS and other era-appropriate software natively on such incomprehensibly fast hardware (by early 90s standards). Some video games were hard coded to the processor clock of the x86 process of the era, so increasing the clock speed orders of magnitude results in several playability issues. In emulators it’s easier to provide an artificially slow clock speed, but on real hardware this isn’t always possible. But [Yeo Kheng Meng] has done a lot to get this modern computer running older software like this. Another take we’ve seen for retro gaming on original hardware is this system which uses a brand-new 486 processor meant for use in industrial settings as well.

hackaday.com/2024/10/22/a-mode…

When you are troubleshooting, it is sometimes useful to disconnect a part of your circuit to see what happens. If your new PCB isn’t perfect, you might also need to add some extra wires or components — not that any of us will ever admit to doing that, of course. When ICs were in sockets, it was easy to do that. [MrSolderFix] shows his technique for lifting pins on SMD devices in the video below.

He doesn’t use anything exotic beyond a microscope. Just flux, a simple iron, and a scalpel blade. Oh, and very steady hands. The idea is to heat the joint, gently lift the pin with the blade, and wick away excess solder. If you do it right, you’ll be able to put the pin back down where it belongs later. He makes the sensible suggestion of covering the pad with a bit of tape if you want to be sure not to accidentally short it during testing. Or, you can bend the pin all the way back if you know you won’t want to restore it to its original position.

He does several IC pins, but then shows that you need a little different method for pins that are near corners so you don’t break the package. In some cases for small devices, it may work out better to simply remove them entirely, bend the pins as you want, and then reinstall the device.

A simple technique, but invaluable. You probably don’t have to have a microscope if you have eagle eyes or sufficient magnification, but the older you get, the more you need the microscope.

Needless to say, you can’t do this with BGA packages. SMD tools used to be exotic, but cheap soldering stations and fine-tipped irons have become the norm in hacker’s workshops.

youtube.com/embed/uXFBJS7g_jg?…

hackaday.com/2024/10/22/give-y…

In general, the simpler a thing is, the better. That doesn’t appear to apply to engines, though, at least not how we’ve been building them. Pistons, cranks, valves, and seals, all operating in a synchronized mechanical ballet to extract useful work out of some fossilized plankton.

It doesn’t have to be that way, though, if the clever engineering behind this wobbling disk air engine is any indication. [Retsetman] built the engine as a proof-of-concept, and the design seems well suited to 3D printing. The driven element of the engine is a disk attached to the equator of a sphere — think of a model of Saturn — with a shaft running through its axis. The shaft is tilted from the vertical by 20° and attached to arms at the top and bottom, forming a Z shape. The whole assembly lives inside a block with intake and exhaust ports. In operation, compressed air enters the block and pushes down on the upper surface of the disk. This rotates the disc and shaft until the disc moves above the inlet port, at which point the compressed air pushes on the underside of the disc to continue rotation.

[Resetman] went through several iterations before getting everything to work. The main problems were getting proper seals between the disc and the block, and overcoming the friction of all-plastic construction. In addition to the FDM block he also had one printed from clear resin; as you can see in the video below, this gives a nice look at the engine’s innards in motion. We’d imagine a version made from aluminum or steel would work even better.

If [Resetman]’s style seems familiar, it’s with good reason. We’ve featured plenty of his clever mechanisms, like this pericyclic gearbox and his toothless magnetic gearboxes.

youtube.com/embed/z3x-_-5T9DQ?…

hackaday.com/2024/10/22/a-wobb…

It’s easy to use electricity — solar-generated or otherwise — to desalinate water. However, traditional systems require a steady source of power. Since solar panels don’t always produce electricity, these methods require some way to store or acquire power when the solar cells are in the dark or shaded. But MIT engineers have a fresh idea for solar-powered desalination plants: modify the workload to account for the amount of solar energy available.

This isn’t just a theory. They’ve tested community-sized prototypes in New Mexico for six months. The systems are made especially for desalinating brackish groundwater, which is accessible to more people than seawater. The goal is to bring potable water to areas where water supplies are challenging without requiring external power or batteries.

The process used is known as “flexible batch electrodialysis” and differs from the more common reverse osmosis method. Reverse osmosis, however, requires a steady power source as it uses pressure to pump water through a membrane. Electrodialysis is amenable to power fluctuations, and a model-based controller determines the optimal settings for the amount of energy available.

There are other ways to use the sun to remove salt from water. MIT has dabbled in that process, too, at a variety of different scales.

hackaday.com/2024/10/22/for-de…

Grandoreiro is a well-known Brazilian banking trojan — part of the Tetrade umbrella — that enables threat actors to perform fraudulent banking operations by using the victim’s computer to bypass the security measures of banking institutions. It’s been active since at least 2016 and is now one of the most widespread banking trojans globally.

INTERPOL and law enforcement agencies across the globe are fighting against Grandoreiro, and Kaspersky is cooperating with them, sharing TTPs and IoCs. However, despite the disruption of some local operators of this trojan in 2021 and 2024, and the arrest of gang members in Spain, Brazil, and Argentina, they’re still active. We now know for sure that only part of this gang was arrested: the remaining operators behind Grandoreiro continue attacking users all over the world, further developing new malware and establishing new infrastructure.

Every year we observe new Grandoreiro campaigns targeting financial entities, using new tricks in samples with low detection rates by security solutions. The group has evolved over the years, expanding the number of targets in every new campaign we tracked. In 2023, the banking trojan targeted 900 banks in 40 countries — in 2024, the newest versions of the trojan targeted 1,700 banks and 276 crypto wallets in 45 countries and territories, located on all continents of the world. Asia and Africa have finally joined the list of its targets, making it a truly global financial threat. In Spain alone, Grandoreiro has been responsible for fraudulent activities amounting to 3.5 million euros in profits, according to conservative estimates — several failed attempts could have yielded beyond 110 million euros for the criminal organization.

In this article, we will detail how Grandoreiro operates, its evolution over time, and the new tricks adopted by the malware, such as the usage of 3 DGAs (domain generation algorithm) in its C2 communications, the adoption of ciphertext stealing encryption (CTS), and mouse behavior tracking, aiming to bypass anti-fraud solutions. This evolution culminates with the appearance of lighter, local versions, now focused on Mexico, positioning the group as a challenge for the financial sector, law enforcement agencies and security solutions worldwide.

Grandoreiro: One malware, many operators, fragmented versions

Grandoreiro is a banking trojan of Brazilian origin that has been active since at least 2016. Grandoreiro is written in the Delphi programming language, and there are many versions, indicating that different operators are involved in developing the malware.

Since 2016, we have seen the threat actors behind Grandoreiro operations regularly improving their techniques to stay unmonitored and active for a longer time. In 2020, Grandoreiro started to expand its attacks in Latin America and later in Europe with great success, focusing its efforts on evading detection using modular installers.

Grandoreiro generally operates as Malware-as-a-Service, although it’s slightly different from other banking trojan families. You won’t find an announcement on underground forums selling the Grandoreiro package — it seems that access to the source-code or builders of the trojan is very limited, only for trusted partners.

After the arrests of some operators, Grandoreiro split its codebase into lighter versions, with fewer targets. These fragmented versions of the trojan are a reaction to the recent law enforcement operations. This discovery is supported by the existence of two distinct codebases in simultaneous campaigns: newer samples featuring updated code, and older samples which rely on the legacy codebase, now targeting only users in Mexico — customers of around 30 banks.

2022 and 2023 campaigns

Grandoreiro campaigns commonly start with a phishing email written in the target country language. For example, the emails distributed in most of Latin America are in Spanish. However, we also saw the use of Google Ads (malvertising) in some Grandoreiro campaigns to drive users to download the initial stage of infection.

Phishing emails use different lures to make the victim interact with the message and download the malware. Some messages refer to a pending phone bill, others mimic a tax notification, and son. In early 2022 campaigns, the malicious email included an attached PDF. As soon as the PDF is opened, the victim is prompted with a blurred image except for a part containing “Visualizar Documento” (“View Document” in Spanish). When the victim clicks the button, they are redirected to a malicious web page which prompts them to download a ZIP file. Since May 2022, Grandoreiro campaigns include a malicious link inside the email body that redirects the victim to a website that then downloads a malicious ZIP archive on the victim’s machine. These ZIP archives commonly contain two files: a legitimate file and a Grandoreiro loader, which is responsible for downloading, extracting and executing the final Grandoreiro payload.

The Grandoreiro loader is delivered in the form of a Windows Installer (MSI) file that extracts a dynamic link library (DLL) file and executes a function embedded in the DLL. The function will do nothing if the system language is English, but otherwise the final payload is downloaded. Most likely, this means that the analyzed versions didn’t target English-speaking countries. There have also been other cases where a VBS file is used instead of the DLL to execute the final payload.

Grandoreiro recent infection flow

As for the malware itself, in August 2022 campaigns, the final payload was an incredibly big 414 MB portable executable file disguised with a PNG extension (which is later renamed to EXE dynamically by the loader). It masked itself as an ASUS driver using the ASUS icon and was signed with an “ASUSTEK DRIVER ASSISTANTE” digital certificate.

In 2023 campaigns, Grandoreiro used samples with rather low detection rates. Initially, we identified three samples related to these campaigns, compiled in June 2023. All of them were portable executables, 390 MB big, with the original name “ATISSDDRIVER.EXE” and internal name “ATIECLXX.EXE”. The main purpose of these samples is to monitor the victims’ visits to financial institution websites and steal their credentials. The malware also allows threat actors to remotely control the victim machines and perform fraudulent transactions within them.

In the campaign involving the discussed samples, the malware tries to impersonate an AMD External Data SSD driver and is signed with an “Advice informations” digital certificate in order to appear legitimate and evade detection.

Implant impersonating AMD driver

Digital certificate used by Grandoreiro malware

In both cases, the malware is an executable that registers itself to be launched with Windows. However, it is worth noting that in the majority of Grandoreiro attacks, a DLL sideloading technique is employed, using legitimate binaries that are digitally signed to run the malware.

The considerable size of the executables can be explained by the fact that Grandoreiro utilizes a binary padding technique to inflate the size of the malicious files as a way to evade sandboxes. To achieve this, the attackers add multiple BMP images to the resource section of the binary. In the example below, the sample included several big images. The sizes of the highlighted images are around 83.1 MB, 78.8 MB, 75.7 and 37.6 MB. However, there are more of them in the binary, and together all the images add ~376 MB to the file.

Binary padding used by Grandoreiro

In both 2022 and 2023 campaigns, Grandoreiro used a well-known XOR-based string encryption algorithm that is shared with other Brazilian malware families. The difference is the encryption key. For Grandoreiro, some magic values were the following:

The various checks and validations aimed at avoiding detection and complicating malware analysis were also changed in the 2022 and 2023 versions. In contrast with the older Grandoreiro campaigns, we found that some of the tasks that were previously executed by the final payload are now implemented in the first stage loader. These tasks include security checks, anti-debugging techniques, and more. This represents a significant change from previous campaigns.

One of these tasks is the use of the geolocation service ip-api.com/json to gather the target’s IP address location data. In a campaign reported in May 2023 by Trustwave, this task is performed by a JScript code embedded in an MSI installer before the delivery of the final payload.

There are numerous other checks that have been transferred into the loader, although some of them are still present in the banking trojan itself. Grandoreiro gathers host information such as operating system version, hostname, display monitor information, keyboard layout, current time and date, time zone, default language and mouse type. Then the malware retrieves the computer name and compares it against the following strings that correspond to known sandboxes:

• WIN-VUA6POUV5UP;
• Win-StephyPC3;
• difusor;
• DESTOP2457;
• JOHN-PC.

Computer name validation

It also collects the username and verifies if it matches with the “John” or “WORK” strings. If any of these validations match, the malware stops its execution.

Grandoreiro includes detection of tools commonly used by security analysts, such as regmon.exe, procmon.exe, Wireshark, and so on. The process list varies across the malware versions, and it was significantly expanded in 2024, so we’ll share the full list later in this post. The malware takes a snapshot of currently executing processes in the system using the CreateToolhelp32Snapshot() Windows API and goes through the process list using Process32FirstW() and Process32NextW(). If any of the analysis tools exists in the system, the malware execution is terminated.

Grandoreiro also checks the directory in which it is being executed. If the execution paths are D:\programming or D:\script, it terminates itself.

Another anti-debugging technique implemented in the trojan involves checking for the presence of a virtual environment by reading data from the I/O Port “0x5658h” (VX) and looking for the VMWare magic number 0x564D5868. The malware also uses the IsDebuggerPresent() function to determine whether the current process is being executed in the context of a debugger.

Last but not least, Grandoreiro searches for anti-malware solutions such as AVAST, Bitdefender, Nod32, Kaspersky, McAfee, Windows Defender, Sophos, Virus Free, Adaware, Symantec, Tencent, Avira, ActiveScan and CrowdStrike. It also looks for banking security software, such as Topaz OFD and Trusteer.

In terms of the core functionality, some Grandoreiro samples check whether the following programs are installed:

• CHROME.EXE;
• MSEDGE.EXE;
• FIREFOX.EXE;
• IEXPLORE.EXE;
• OUTLOOK.EXE;
• OPERA.EXE;
• BRAVE.EXE;
• CHROMIUM.EXE;
• AVASTBROWSER.EXE;
• VeraCrypt;
• Nortonvpn;
• Adobe;
• OneDrive;
• Dropbox.

If any of these is present on the system, the malware stores their names to further monitor user activity in them.

Grandoreiro also checks for crypto wallets installed on the infected machine. The malware includes a clipboard replacer for crypto wallets, monitoring the user’s clipboard activity and replacing the clipboard data with the threat actor keys.

Clipboard replacer

2024 campaigns

During a certain period of time in February 2024, a few days after the announcement of the arrest of some of the gang’s operators in Brazil, we observed a significant increase in emails detected by spam traps. There was a notable prevalence of Grandoreiro-themed messages masquerading as Mexican CFDI communications. Mexican CFDI, short for “Comprobante Fiscal Digital por Internet” is an electronic invoicing system administered by the Mexican Tax Authority (SAT — Servicio de Administración Tributaria). It facilitates the creation, transmission, and storage of digital tax documents, mandatory for businesses in Mexico to record transactions for tax purposes.

In our investigation, we have acquired 48 samples associated not only with this instance but also with various other campaigns.

Notably, this new campaign added a new sandbox detection mechanism, namely a CAPTCHA before the execution of the main payload, as a way to avoid the automatic analysis used by some companies:

Grandoreiro anti-sandbox CAPTCHA

It is worth noting that in the 2024 Grandoreiro campaigns, the new sandbox evasion code has been implemented in the downloader. Although the main sample still has anti-sandbox functionality too, if a sandbox is detected, it is simply not downloaded. Besides that, the new version also added detection of many tools to its arsenal, aiming to avoid analysis. Here is whole list of analysis tools detected by the newest versions:

These are some RAT features that we found in this version:

• Auto-update feature allows newer versions of the malware to be deployed to the victim’s machine;
• Sandbox/AV detection, still present in the main module, which includes more tools than previous versions;
• Keylogger feature;
• Ability to select country for listing victims;
• Banking security solutions detection;
• Checking geolocation information to ensure it runs in the target country;
• Monitoring Outlook emails for specific keywords;
• Ability to use Outlook to send spam emails.

In terms of static analysis protection, in 2024 versions, Grandoreiro has implemented enhanced encryption measures. Departing from its previous reliance on commonly shared encryption algorithms found in other malware, Grandoreiro has now adopted a multi-layered encryption approach. The decryption process in the newer versions is the following. Initially, the string undergoes deobfuscation through a simple replacement algorithm. Following this, Grandoreiro employs the encryption algorithm based on XOR and conditional subtraction typically utilized by Brazilian malware; however, it differs from them by incorporating a lengthy, 140759-byte string instead of smaller magic strings we saw in 2022 and 2023 samples. Subsequently, the decrypted string undergoes base64 decoding before being subjected to decryption via the AES-256 algorithm. Notably, the AES key and IV are encrypted within Grandoreiro’s code. Upon completion of all these steps, the decrypted string is successfully recovered.

Grandoreiro AES key and IV

In newer samples, Grandoreiro upgraded yet again the encryption algorithm using AES with CTS, or Ciphertext Stealing, a specialized encryption mode used when the plaintext is not a multiple of the block size, which in this case is the 128-bit (16-byte) block size used by AES. Unlike more common padding schemes, such as PKCS#7, where the final block is padded with extra bytes to ensure it fits a full block, CTS operates without padding. Instead, it manipulates the final partial block of data by encrypting the last full block and XORing its output with the partial block. This allows encryption of any arbitrary-length input without adding extra padding bytes, preserving the original size of the data.

ECB Encryption Steps for CTS

In the case of Grandoreiro, the malware’s encryption routine does not add standard padding to incomplete blocks of data. Their main goal is to complicate analysis: it takes time to figure out that CTS was used, and then more time to implement decryption in this mode, which makes the extraction and obfuscation of strings more complicated. This marks the first time this particular method has been observed in a malware sample.

As the threat actors continue to evolve their techniques, changing the encryption in every iteration of the malware, the use of CTS in malware may signal a shift toward more advanced encryption practices.

Local versions: old meets new

In a recent campaign, our analysis has revealed the existence of an older variant of the malware that utilizes legacy encryption keys, outdated algorithms, and a simplified structure, but which runs in parallel to the campaign using the new code. This variant targets fewer banks — about 30 financial institutions, mainly from Mexico. This analysis clearly indicates that another developer, likely with access to older source code, is conducting new campaigns using the legacy version of the malware.

How they steal your money

Operators behind Grandoreiro are equipped with a wide variety of remote commands, including an option to lock the user screen and present a custom image (overlay) to ask the victim for extra information. These are usually OTPs (one-time passwords), transaction passwords or tokens received by SMS, sent by financial institutions.

A new tactic that we have discovered in the most recent versions found in July 2024 and later suggests that the malware is capturing user input patterns, particularly mouse movements, to bypass machine learning-based security systems. Two specific strings found in the malware — “GRAVAR_POR_5S_VELOCIDADE_MOUSE_CLIENTE_MEDIA” (“Record for 5 seconds the client’s average mouse speed”) and “Medição iniciada, aguarde 5 segundos!” (“Measurement started, please wait 5 seconds!”) — indicate that Grandoreiro is monitoring and recording the user’s mouse activity over a short period. This behavior appears to be an attempt to mimic legitimate user interactions in order to evade detection by anti-fraud systems and security solutions that rely on behavioral analytics. Modern cybersecurity tools, especially those powered by machine learning algorithms, analyze user’s behavior to distinguish between human users and bots or automated malware scripts. By capturing and possibly replaying these natural mouse movement patterns, Grandoreiro could trick these systems into identifying the activity as legitimate, thus bypassing certain security controls.

This discovery highlights the continuous evolution of malware like Grandoreiro, where attackers are increasingly incorporating tactics designed to counter modern security solutions that rely on behavioral biometrics and machine learning.

To perform the cash-out in the victim’s account, Grandoreiro operators’ options are to transfer money to the account of local money mules, using transfer apps, buy cryptocurrency or gift cards, or even going to an ATM. Usually, they search for money mules in Telegram channels, paying $200 to $500 USD per day:

Grandoreiro operator looking for money mules

Infrastructure

The newest Grandoreiro version uses 3 Domain Generation Algorithms (DGAs), generating valid domains for command and control (C2) communications. The algorithm uses the current daytime to select strings of predefined lists and concatenates them with a magic key to create the final domain.

By dynamically generating unique domain names based on various input data, the algorithm complicates traditional domain-based blocking strategies. This adaptability allows the malicious actors to maintain persistent command-and-control communications, even when specific domains are identified and blacklisted, requiring security solutions to base their protection not on a fixed list of domains, but on an algorithm for generating them.

Since early 2022, Grandoreiro leverages a known Delphi component shared among different malware families named RealThinClient SDK to remotely access victim machines and perform fraudulent actions. This SDK is a flexible and modular framework for building reliable and scalable Windows HTTP/HTTPS applications with Delphi. By using RealThinClient SDK, the program can handle thousands of active connections in an efficient multithreaded manner.

Grandoreiro C2 Communication

Operator tool

Grandoreiro’s Operator is the tool that allows the cybercriminal to remotely access and control the victim’s machine. It’s a Delphi-based software that lists its victims whenever they start browsing a targeted financial institution website.

Grandoreiro’s Operator tool

Once the cybercriminal chooses a victim to operate on, they will be presented with the following screen, seen in the image below, which allows many commands to be executed and visualizes the victim’s desktop.

Grandoreiro’s Operator commands

Cloud VPS

One overlooked feature of the Grandoreiro malware is what is called “Cloud VPS” by the attackers — it allows cybercriminals to set up a gateway computer between the victim’s machine and the malware operator, thus hiding the cybercriminal’s real IP address.

This is also used by them to make investigation harder, as the first thing noted is the gateway’s IP address. When requesting a seizure, an investigator just finds the gateway module. Meanwhile, the criminal has already set up a new gateway somewhere else and new victims connect to the new one through its DGA.

Grandoreiro Cloud VPS

Victims and targets

The Grandoreiro banking trojan is primed to steal the credentials accounts for 1,700 financial institutions, located in 45 countries and territories. After decrypting the strings of the malware, we can see the targeted banks listed separated by countries/territories. This doesn’t mean that Grandoreiro will target a specific bank from the list; it means it is ready to steal credentials and act, if there is a local partner or money mule who can operationalize and complete the action. The banks targeted by Grandoreiro are located in Algeria, Angola, Antigua and Barbuda, Argentina, Australia, Bahamas, Barbados, Belgium, Belize, Brazil, Canada, Cayman Islands, Chile, Colombia, Costa Rica, Dominican Republic, Ecuador, Ethiopia, France, Ghana, Haiti, Honduras, India, Ivory Coast, Kenya, Malta, Mexico, Mozambique, New Zealand, Nigeria, Panama, Paraguay, Peru, Philippines, Poland, Portugal, South Africa, Spain, Switzerland, Tanzania, Uganda, United Kingdom, Uruguay, USA, and Venezuela. It’s important to note that the list of targeted banks and institutions tend to slightly change from one version to another.

From January to October 2024, our solutions blocked more than 150,000 infections impacting more than 30,000 users worldwide, a clear sign the group is still very active. According to our telemetry, the countries most affected by Grandoreiro infections are Mexico, Brazil, Spain, and Argentina, among many others.

Conclusion

We understand how difficult it is to eradicate a malware family, but it is possible to impede their operation with the cooperation of law enforcement agencies and the private sector — modern financial cybercrime can and must be fought.

Brazilian banking trojans are already an international threat; they’re filling the gaps left by Eastern European gangs who have migrated into ransomware. We know that in some countries, internet banking is declining on desktops, forcing Grandoreiro to target companies and government entities who are still using operating in that way.

The threat actors behind the Grandoreiro banking malware are continuously evolving their tactics and malware to successfully carry out attacks against their targets and evade security solutions. Kaspersky continues to cooperate with INTERPOL and other agencies around the world to fight the Grandoreiro threat among internet banking users.

This threat is detected by Kaspersky products as HEUR:Trojan-Banker.Win32.Grandoreiro, Trojan-Downloader.OLE2.Grandoreiro, Trojan.PDF.Grandoreiro and Trojan-Downloader.Win32.Grandoreiro.

For more information, please contact: crimewareintel@kaspersky.com

Indicators of Compromise

Host based
f0243296c6988a3bce24f95035ab4885
dd2ea25752751c8fb44da2b23daf24a4
555856076fad10b2c0c155161fb9384b
49355fd0d152862e9c8e3ca3bbc55eb0
43eec7f0fecf58c71a9446f56def0240
150de04cb34fdc5fd131e342fe4df638
b979d79be32d99824ee31a43deccdb18

securelist.com/grandoreiro-ban…

We’ve been hinting at it for a few months now, running a series of articles on SAOs, then a Supercon Add-On Challenge. We even let on that the badge would have space for multiple SAOs this year, but would you believe six?

Way back in 2017ish, Hackaday’s own [Brian Benchoff] and the [AND!XOR] crew thought it would be funny and useful to create a “standard” for adding small custom PCB art-badges onto bigger conference badges. The idea was to keep it quick and dirty, uncomplicated and hacky, and the “Shitty” Add On was born. The badge community took to this like wildfire. While the community has moved on from the fecal humor, whether you call these little badgelets “SAOs”, “Simple Add-Ons”, or even “Supercon-8 Add Ons”, there’s something here for everyone. So if you’ve already got some SAOs in a drawer, bring them to this year’s Supercon and show them off!

But you don’t need to bring your own SAOs. We thought that as long as we were providing six SAO ports, we’d provide you with a small starter collection: four of them, in fact. A fantastic capacitive touch wheel designed by [Todbot], a beautiful spiral petal matrix of LEDs designed by [Voja Antonic], a completely blank-slate protoboard petal, and an I2C-enabled microcontroller proto-petal.

Bringing it all together, of course, is the main badge, which sports a Raspberry Pi Pico W on the back-side, for WiFi and Bluetooth connectivity. This badge is intended to be a showcase of SAOs, and we thought that there have always been some under-explored corners of the spec. The most recent six-pin standard has power, ground, two GPIO pins, and an I2C pair. How often do we see SAOs that only use the power lines? This year, that changes!

Every GPIO pin on all six SAO slots is individually accessible, and the Pi Pico’s two hardware I2C peripheral busses are broken out on the left and right sides of the badge respectively. (Have an I2C enumeration conflict? Just move one of the offenders to the other side.) The idea here, combined with the wireless features and a trio of buttons on the front, is to give you a big sandbox to explore the possibilities of SAOs that go farther than just art.

Many Ways to Play

Straight out of the gate, the touch wheel and the LED petal matrix invite you to play with them, all the while fooling you into learning a little bit about interfacing I2C devices. You see, I2C devices have a unique address, and the rest of the functionality is handled by as if they were memory-mapped peripherals. What does this mean? If you want to ask the touch wheel where your finger is, you simply query its memory location 0. To set the LED colors, you write bytes to memory locations 15, 16, and 17 for red, green, and blue, respectively. Each spiral arm of the LED matrix petal is simply a byte in memory – write to it and the blinkies blink.

The take-home: I2C devices are fun and to play with. And when you start combining the functions of multiple SAOs, you can really start getting creative. But we’ve only scratched the surface. The I2C proto petal includes a CH32V003 chip, with its own dedicated I2C device hardware peripheral, so if you have essentially anything that you can solder to it, you can turn that into an I2C-enabled device to add to the party.

This is a multi-lingual party, though. The main badge, and all of the connection logic, runs on MicroPython. This makes it just a few lines of code to display your finger presses on the touchwheel over on the LED petal matrix, for instance, and we’ll have some demo code to ease you in. (And we’re frantically writing more!) But the I2C protoboard requires a little bit of C. If you’ve got a CH32V003 environment set up, by all means bring it – we love [CHLohr]’s CH32V003fun. We’re working on getting the badge board to program the CH32 in-situ, and we’re 99% sure we’ll have that ready by showtime. We’ll have demo code here to get you started as well. Will you program your first RISC-V chip at this year’s Supercon?

But say you don’t want anything to do with all this software? Just give me the solder! The blank-slate protoboard is for you. It breaks out the SAO lines, and gives you maximal room for creative hardware play. Heck, you could solder an LED, a resistor, and call it done. Or play around with the possibilities of the GPIOs. Low-code or no-code, the choice is yours.

Participate!

We know you’re all looking forward to getting your hands on the badge and the SAOs and getting creative. Here is the 2024 Supercon SAO Badge GitHub repository, for your perusal. All of the design files that we have are there in the hardware directory, but the code is not yet complete. If you want to design a 3D-printed case or add-on, you’ll find the vector files in PDF.

As usual [Voja] makes his circuit diagrams by hand, so you’ll find a beautifully annotated schematic that lets you know where each and every pin goes. If you’re not feeling the AA battery love, you’ll see that [Voja] has left you some pads to hook up an external power supply, for instance.

But the software is a work in progress, and in particular, we don’t know what I2C devices you’ll be bringing with you. We’re going to include as many MicroPython I2C device libraries as we can find, from OLED screens to magnetometers, and we’d like them to be on the default conference image. So if you’ve a device that you’d like us to support, either drop a link in the comments below or add the code in the libraries folder and submit a pull request! We’ll be flashing these at the absolute last minute, of course, but please get it in this weekend if you can.

Supercon!

Supercon 8’s badge is the unofficial world-record holder for the most SAO connectors on any official conference badge, but it also aspires to encourage you to play around with the functional aspects of our favorite mini-badge form factor. Heck, maybe you’ll learn a thing or two about I2C along the way? Push some GPIOs around? Or maybe you’ll just have a fun weekend with a soldering iron, some stellar talks, and some great company. Whatever it’s going to be, we can’t wait to see you all, and to see what you come up with!

If you have any questions about the badge, fire away in the comments here.

You do have your tickets already, right? See you soon!

(C3P0 add-on by [kuro_dk] and Cyclops by [Simenzhor] not included.)

For serious high-voltage plasma, you need a serious transformer. [Jay Bowles] from Plasma Channel is taking his projects to the next level, so he built a beefy 6000:1 flyback transformer.

[Jay] first built a driving circuit for his dream transformer, starting with a simple 555 circuit and three MOSFETs in parallel to handle 90 A of current. This led to an unexpected lesson on the necessity for transistor matching as one of them let out the Magic Smoke. On his second attempt, the 555 was swapped for an adjustable pulse generator module with a display, and a single 40 A MOSFET on the output.

The transformer is built around a large 98×130 mm ferrite core, with eleven turns on the primary side. All the hard work is on the secondary side, where [Jay] designed a former to accommodate three winding sections in series. With the help of the [3D Printing Nerd], he printed PLA and resin versions but settled on the resin since it likely provided better isolation.

[Jay] spent six hours of quality time with a drill, winding 4000 feet (~1200 m) of enameled wire. On the initial test of the transformer, he got inch-long arcs on just 6 V and 15 W of input power. Before pushing the transformer to its full potential, he potted the secondary side in epoxy to reduce the chances of shorts between the windings.

Unfortunately, the vacuum chamber hadn’t removed enough of the air during potting, which caused a complete short of the middle winding as the input started pushing 11 V. This turned the transformer into a beautiful copper and epoxy paperweight, forcing [Jay] to start again from scratch.

On the following attempt [Jay] took his time during the potting process, and added sharp adjustable electrodes to act as voltage limiters on the output. The result is beautiful 2.25-inch plasma arcs on only 11 V and 100 W input power. This also meant he could power it with a single 580 mAh 3S LiPo for power.

[Jay] plans to use his new transformer to test materials he intends to use in future plasma ball, ion thruster, and rail gun projects. We’ll be keeping an eye out for those!

youtube.com/embed/DkhpuuPljS4?…

hackaday.com/2024/10/22/pushin…