A new Linux malware sample that strongly aligns with the SysUpdate malware family used by APT27/Iron Tiger.
Initially detected on a client’s system, the binary behaved like a system service and executed the GNU/Linux id command when run without specific arguments, returning the output as part of its basic functionality.
Closer inspection showed that the sample was a packed ELF64 binary, dynamically linked, with no section headers, written in C++ and using an unknown obfuscated packer to frustrate traditional static analysis.
Most importantly, the malware communicated with its command-and-control (C2) servers using encrypted traffic across multiple protocols, prompting analysts to focus on reversing and defeating its custom encryption logic.
A recent DFIR investigation led researchers at LevelBlue to a new Linux malware sample that strongly aligns with the SysUpdate malware.
SysUpdate Variant Malware
During triage, dynamic analysis and EDR telemetry indicated behavior consistent with previously reported SysUpdate variants, giving analysts a high degree of confidence that this was an evolution of the same family rather than a completely new strain.
The team used a combination of syscall tracing, network socket monitoring, and static analysis of memory regions containing unusual constants and dense bitwise operations to quickly locate the encryption-related routines.
At a high level, the C2 logic relied on a key generation function and a separate routine that handled both encryption and decryption depending on a flag.
One wrapper function, named generate_key, accepted a structure pointer and a plaintext key, then iterated 64 times over a buffer to produce a derived key using an internal routine referred to as generate_key_internal.
The internal routine contained several odd integer constants and references to data tables resembling S-boxes, further suggesting that the malware used a custom or heavily modified symmetric cipher.
Another critical routine, informally called xor_and_UNK_1, took parameters describing encryption state: a stack-allocated encryption parameter structure, an encrypt/decrypt flag, data size, an 8-byte key, and two data buffer pointers that changed roles based on the mode.
For decryption, the function verified that the buffer length was aligned to 8 bytes, then processed the data in 8-byte blocks inside a loop until all bytes were consumed.
Each block was first passed through a helper function humorously named i_am_clearly_encryption_unknown?, which operated on the data using constants such as 0xf0f0f0f, 0x33333333, and 0xff00ff, as well as S-box-like tables, before applying a final XOR with the plaintext key.
This layered design meant that defenders could not simply XOR the traffic with a static key; they needed to reproduce the full transformation chain to decrypt C2 messages reliably.
To avoid fully re-implementing the unknown encryption algorithm, the researcher used the Unicorn Engine, via Rust bindings, to emulate the malware’s own code and make it “decrypt itself.”
Using Binary Ninja’s High Level Intermediate Language (HLIL) view alongside GDB, the analyst identified the exact points in execution where key generation and decryption routines were invoked, then carved out the necessary machine code, data segments, and CPU state from process memory.
Memory regions such as stack, heap, crypto-related data (“false heap”), and code were mapped into the Unicorn emulator using the same virtual addresses seen at runtime, making cross-referencing with Binary Ninja and GDB straightforward.
The key generation emulator initialized stack snapshots, loaded the mysterious crypto tables, crafted a controlled heap with the plaintext key (extracted from the live malware), and injected the machine code for generate_key_internal and generate_key.
Register state was then reconstructed to match the original execution context, pointing RDI at the output buffer for the generated key and RSI at the plaintext key in the emulated heap, with other registers set to expected values or null as determined during dynamic analysis.
Implications for Defenders
By starting emulation at the generate_key entry point and stopping just after completion, the tool produced the exact derived key bytes used by the malware, which were then written to gend_key.bin for reuse.
The enc_key pointer is then set to the next 8-byte block in the encrypted blob. It then continues incrementing by 8 bytes until the entire data buffer has been decrypted.
For organizations facing advanced threats like APT27/Iron Tiger, this case underlines the value of combining reverse engineering, binary emulation, and DFIR to break opaque C2 channels on Linux systems.
A second emulator wrapped the xor_and_UNK_1 routine to decrypt captured network traffic: the heap was populated with intercepted encrypted C2 data, the known plaintext key, the derived key from gend_key.bin, and an output buffer.
With registers configured to signal decrypt mode, specify the buffer length, and point to input/output regions, the emulator executed the original decryption logic and dumped the cleartext C2 payload to DECRYPTED.bin.
This approach effectively turned the malware’s proprietary encryption into an advantage for defenders, enabling analysts to decrypt C2 traffic without fully understanding or documenting the complete cipher internals.
The technique is reusable: as long as responders can extract the relevant code fragments, crypto tables, and runtime keys from future SysUpdate variants, the same emulation framework can be adapted to new samples with minimal changes.
It also demonstrates that defenders do not always need to “solve” a custom encryption scheme mathematically when they can safely sandbox and drive the attacker’s own routines to reveal their secrets.
Follow us on Google News, LinkedIn, and X to Get Instant Updates and Set GBH as a Preferred Source in Google.
