MalwareAnalysisReports/AmateraStealer/Amatera Stealer v1.md
at main · VenzoV/MalwareAnalysisReports
By VenzoV
Archived: 2026-04-05 15:45:28 UTC
Sample
At the time of analysis, this was the only sample I was able to locate related to the Amatera stealer. I was also
unable to find any prior public reports or technical write-ups on Amatera. The only references I identified (though
others may exist) were a few posts on X discussing its command-and-control (C2) panel.
While drafting this analysis, Proofpoint published a brief blog post noting that Amatera is a rebranded version of
ACR Stealer, as previously analyzed by AhnLab.
The sample referenced in this post is available on MalwareBazaar and VirusTotal.
SHA256
73fd51d4a0959e5c5a82db9be0d765069d02a2b97f51f55f5d6422a7bec01caa
The sample I analyzed below appears to differ from the one referenced by Proofpoint. It seems to represent an
earlier or test version of the malware, as it lacks significant obfuscation and does not incorporate advanced anti-analysis techniques. Also big give away is the "build_id" string set to "test_5"
In the last section I will add the differences and similarties as I got, for now it contains only a quick glance of the
similarties found within the shellcode and hashing algorithm.
C2 Communications
The main features for C2 communications are:
Connects to C2 server at "afdprox.icu" on port 443
Uses RC4 encryption for data transmission
Implements authorization headers for authentication
Sends stolen data via POST requests to "/core/sendPart"
Receives config from "/core/createSession"
The two functions that iteract with the C2 are:
mw_C2GetConfig -> Gets JSON config
mw_C2SendData -> Sends Stolend data RC4 encrypted
https://github.com/VenzoV/MalwareAnalysisReports/blob/main/AmateraStealer/Amatera%20Stealer%20v1.md
Page 1 of 11

The stealer will make use of the Authorization header to connect to C2 and receive an encrypted config. The data
will be base64 decoded and then decrypted. The function mw_ParseC2Data() is evidence that the config is in a
JSON format. Also previous ACR reported by AhnLab shows a very similar json.
Following some of the JSON fields the malware looks for and saves the values:
https://github.com/VenzoV/MalwareAnalysisReports/blob/main/AmateraStealer/Amatera%20Stealer%20v1.md
Page 2 of 11

As for mw_C2SendData, this function is pretty standard. It will RC4 encrypt stolen data and send it to the C2.
C2 Config Decryption
After reviewing other builds—particularly those resembling the ones analyzed in Proofpoint’s research rather than
test builds—I was able to decrypt the C2 configuration using the following method:
def xor_decrypt_exact(encrypted: bytes, key: bytes) -> bytes:
 if len(key) != 10:
 raise ValueError("Key must be exactly 10 bytes")
 decrypted = bytearray(len(encrypted))
 for i in range(len(encrypted)):
 decrypted[i] = encrypted[i] ^ key[i % 10]
 return bytes(decrypted)
https://github.com/VenzoV/MalwareAnalysisReports/blob/main/AmateraStealer/Amatera%20Stealer%20v1.md
Page 3 of 11

The key can be found right at the start of the code:
Following the c2 config:
Amatera Config:
{"b":[{"n":"b\\c8","p":"\\Local\\Google\\Chrome\\User Data","t":1,"pn":"chrome.exe"},{"n":"b\\c8","p
System Information Harvesting
The malware comprehensively profiles the victim's system by collecting:
Machine GUID and hardware identifiers
Hostname and username
Operating system details and locale information
Installation date and timezone
Display/monitor information
Processor details and total RAM
List of installed software and running processes
Takes screenshots of the desktop
Steals clipboard contents
https://github.com/VenzoV/MalwareAnalysisReports/blob/main/AmateraStealer/Amatera%20Stealer%20v1.md
Page 4 of 11

Data Theft
The malware specifically targets Chromium-based browsers:
Extracts Chrome/Chromium encryption keys from Local State files
Steals stored passwords, cookies, and browsing data
Harvests browser extension data (likely targeting cryptocurrency wallet extensions)
Processes app-bound encryption keys for newer Chrome versions
Also targets Mozilla Firefox data
Searches for and steals desktop cryptocurrency wallet files
Steals Telegram Desktop session files and data
Harvests Steam account information
Shellcode
First Shellcode
https://github.com/VenzoV/MalwareAnalysisReports/blob/main/AmateraStealer/Amatera%20Stealer%20v1.md
Page 5 of 11

While analyzing Chrome-related files, the malware invokes a function tasked with injecting shellcode into the
target browser, based on parameters defined in its configuration. The shellcode is executed by creating a new
thread within the browser process.
Notably, the payload consists of a two-stage shellcode, both stages embedded within the sample itself. The first
stage is responsible for locating, parsing, and decompressing the second-stage shellcode. This process involves
scanning memory for specific patterns used to identify and extract the embedded payload.
The first-stage shellcode employs a custom hashing algorithm to obfuscate the API functions it requires. It
performs classic PEB (Process Environment Block) walking to dynamically resolve the addresses of these
functions at runtime, a common technique used to evade static analysis and avoid reliance on import tables.
Once the necessary APIs are resolved, the shellcode searches memory for a predefined marker indicating the
location of the second-stage shellcode. It then constructs the appropriate entry point and transfers execution to it.
Additionally, the shellcode appears to support both RC4 encryption and RTL compression for the embedded
payloads. However, in this particular sample, neither of these obfuscation methods is applied—the payload is in
plain or minimally encoded form.
https://github.com/VenzoV/MalwareAnalysisReports/blob/main/AmateraStealer/Amatera%20Stealer%20v1.md
Page 6 of 11

Following the python version of the hashing algorithm:
def ror(value, bits, width=32):
 return ((value >> bits) | (value << (width - bits))) & (2**width - 1)
def compute_hash(utf16le_bytes):
 result = 0
 i = 0
 while i + 1 < len(utf16le_bytes):
 char = utf16le_bytes[i]
 next_byte = utf16le_bytes[i+1]
 # Check for UTF-16 null terminator (two null bytes)
 if char == 0x00 and next_byte == 0x00:
 break
 byte = char # only low byte used (so ASCII-safe)
 byte_1 = byte - 0x20
https://github.com/VenzoV/MalwareAnalysisReports/blob/main/AmateraStealer/Amatera%20Stealer%20v1.md
Page 7 of 11

if byte < 0x61:
 byte_1 = byte
 result = ror(result, 0xc) + byte_1
 i += 2 # move to next UTF-16 char
 return result
Second Shellcode
This shellcode uses a COM API to steal browser data and to change security context.
The COM infrastructure is initialized by loading essential libraries such as ole32.dll and oleaut32.dll, which
provide access to COM functionality. Key COM functions like CoInitializeEx, CoUninitialize, CoCreateInstance,
and CoSetProxyBlanket are resolved. Additionally, BSTR functions for handling strings, such as
SysAllocStringByteLen and SysFreeString, are also resolved to facilitate memory management and string
operations.
The COM object is then created and configured by calling CoInitializeEx(0, 2), which sets the apartment
threading model for the process. The COM instance is instantiated using CoCreateInstance. To ensure proper
security, the proxy blanket is set with CoSetProxyBlanket, which configures the authentication and authorization
settings. The proxy blanket is specifically set with RPC_C_AUTHN_LEVEL_PKT_PRIVACY, which provides
the highest authentication level (combining both integrity and encryption), ensuring the communication is secure.
It also uses RPC_C_IMP_LEVEL_IMPERSONATE, allowing the process full access to the caller's token.
Additionally, EOAC_STATIC_CLOAKING is applied, allowing the use of the thread's token silently without
revealing its identity.
https://github.com/VenzoV/MalwareAnalysisReports/blob/main/AmateraStealer/Amatera%20Stealer%20v1.md
Page 8 of 11

n the analyzed non-test build of the malware, several COM CLSIDs were identified as being used to interface with
browser elevation services. These CLSIDs correspond to known COM classes and interfaces responsible for
executing processes with elevated privileges, often related to browser components.
CLSID: {1FCBE96C-1697-43AF-9140-2897C7C69767}
Identified as the MicrosoftEdgeElevationService COM class.
Responsible for handling elevation requests for the legacy Microsoft Edge browser.
CLSID: {C9C2B807-7731-4F34-81B7-44FF7779522B}
Associated with the IElevatorEdge COM interface.
Facilitates elevation operations specific to Edge's elevation broker mechanism.
Further notes on how this typically works can be found Here
Similarties with Proofpoint research
Upon analyzing the Proofpoint sample, we observe that the shellcode section exhibits a structure highly
similar to that found within the binary.
Notably, the pattern used to locate the initial shellcode—which subsequently loads a secondary payload—is
consistent across samples. The implementation appears nearly identical, even utilizing the same hash values for
resolving ntdll.dll and kernel32.dll.
https://github.com/VenzoV/MalwareAnalysisReports/blob/main/AmateraStealer/Amatera%20Stealer%20v1.md
Page 9 of 11

Additionally, the string "Elevator.exe" is present in the second-stage shellcode, suggesting a shared origin or
toolkit.
The following highlights the reuse of the same hashing algorithm within the shellcode:
https://github.com/VenzoV/MalwareAnalysisReports/blob/main/AmateraStealer/Amatera%20Stealer%20v1.md
Page 10 of 11

Source: https://github.com/VenzoV/MalwareAnalysisReports/blob/main/AmateraStealer/Amatera%20Stealer%20v1.md
https://github.com/VenzoV/MalwareAnalysisReports/blob/main/AmateraStealer/Amatera%20Stealer%20v1.md
Page 11 of 11