IcedID Becomes Enhanced

hendryadrian.com

hendryadrian.com

The following is a clarified, reworded version of the original analysis that preserves the technical details and findings.

Joshua Platt and Jason Reaves investigated an IcedID distribution campaign that used GitLab to host a malicious executable. The researchers first observed a raw GitLab URL hosting a downloader binary (hxxps://gitlab.]com/group9652040/my1/-/raw/main/2.exe), and when inspecting that sample they noticed its import hash overlapped with another IcedID sample. That second sample communicated with a different domain, indicating the same or closely related codebase was being reused across distinct C2 infrastructures.

Unpacking the loader revealed many strings that point to system and network discovery capabilities. Some of the visible (decoded) strings include command templates and queries such as net view /all, net group “Domain Admins” /domain, whoami /groups, ipconfig /all, and systeminfo. The binary also contains templates for invoking cmd.exe and wmic.exe as well as references to registry locations and typical Windows folder names like AppData, Desktop, Startup, and Local AppData. In addition to local enumeration commands, the decoded strings contain URL templates and HTTP-related tokens, for example references to paths like /files/, user agent strings, and the C2 endpoints hxxps://aplihartom[.com/live/ and hxxps://fasestarkalim[.com/live/.

Closer examination showed that most strings in the binary are not stored in plaintext but are encoded. The decoding routine reads the first six bytes of each encoded blob — the initial 4-byte XOR seed followed by a 2-byte XOR-encoded length — to determine how many bytes to decode. The loader then runs an XOR loop that uses a pseudo-random number generator (PRNG)-like function seeded by that initial value. Reversing the algorithm shows a sequence of bit shifts and XOR operations applied to the seeded state to produce per-byte XOR masks, which the decoder applies to recover the original text. Once decoded, the full set of revealed strings includes many command templates, format strings, and URL placeholders. Not every decoded string is used at runtime, but enough are active to provide broad profiling and control functionality.

The PRNG and decode routines effectively obfuscate strings until runtime. In operational terms, the loader reads (seed, length) from the encoded blob, derives the true length by combining and masking those fields, and iteratively updates the seed with a custom function to generate a byte mask for each encoded byte. The final decoded outputs include detailed command lines, format specifiers, and C2-related templates such as POST/GET verbs, Content-Type: application/x-www-form-urlencoded, and the hardcoded User-Agent “Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Tob 1.1)”.

On the persistence side, the loader establishes long-term presence by creating a scheduled task and by moving itself into a hardcoded AppData location. The task object observed is named WindowsSystem32TasksUpdater. The binary is designed to relocate to AppDataRoamingCustom_update and to use filenames matching patterns like Update_[0-9a-f]+.exe while storing runtime data under names such as update_data.dat. The sample also uses a hardcoded mutex string (“runnung”) to prevent multiple concurrent instances.

Network behavior is similarly scripted. HTTP requests to C2 are built with static headers and payload formats: the Content-Type and User-Agent are hardcoded, and C2 POSTs target /live/ on the configured domains. The C2 payloads are BASE64-encoded and then RC4-encrypted; the RC4 key is the decoded literal ‘12345’. After decryption, the bot parses command messages where each instruction includes a numeric prefix followed by a URL. These numeric prefixes determine how the downloaded data should be handled: they can instruct the loader to save and execute a file in a specific way, to unpack data into a .dll and register it via rundll32, or to simply exit. URLs in commands may begin with front://, which the loader replaces with the active C2 domain when resolving and downloading the indicated resource.

Observed secondary downloads from this campaign include a “sysinfo” binary and a bp.dat file. The sysinfo binary performs largely the same enumeration as the initial loader but also queries an external service (ifconfig[.me) to determine the host’s public IP address, labeled “realip” in the analysis. The bp.dat artifact can be decrypted using an existing IcedID decryption script, and the analyst references an IcedID-file-decryptor implementation as a means to extract its contents.

Configuration values recovered from the loader include a group identifier (2949673345), a version number (1.1), and a primary C2 list containing fasestarkalim[.com/live/ and aplihartom[.com/live/. Additional C2 domains observed as part of the downloaded C2 list were wikistarhmania[.com/live/ and drendormedia[.com/live/. The network POST example included in the analysis demonstrates the exact header layout sent to the C2 host and identifies the host field as aplihartom.com in that sample.

For practical detection and response, the analysis highlights several actionable artifacts: the GitLab raw distribution URL, the hardcoded scheduled task name (WindowsSystem32TasksUpdater), the AppData target paths and filename patterns, the ‘runnung’ mutex, the static User-Agent and Content-Type in HTTP traffic, and the C2 domains. The command table used by the loader maps numeric codes to behaviors that control whether a downloaded payload is saved, executed, or ignored; the researchers thanked contributors (Antelox and xorsthingsv2) for corrections to that mapping.

This investigation places the sample squarely within known IcedID behavior patterns (see referenced Malpedia entry), but it also documents the campaign’s use of public GitLab hosting for distribution and details the binary’s custom string obfuscation, persistence, and C2 mechanisms. Analysts and defenders should search for the listed file paths, scheduled task name, mutex, User-Agent string, and C2 domains to detect or hunt for this loader, and should treat any matching GitLab-hosted executables with high suspicion.

References in the original analysis include a Malpedia IcedID entry, a TRIAGE behavioral record, and an IcedID decryption utility on GitHub. The original post credits Joshua Platt and Jason Reaves and notes community input on the command table.

Read more: https://medium.com/walmartglobaltech/icedid-gets-loaded-af073b7b6d39