{
	"id": "e1452451-fb35-4660-b962-1d664f804854",
	"created_at": "2026-04-06T00:20:17.475285Z",
	"updated_at": "2026-04-10T03:23:51.63531Z",
	"deleted_at": null,
	"sha1_hash": "555a70bbe59249958aed349b57dbc17e5966ab1d",
	"title": "breaking the ice a deep dive into the IcedID banking trojans new major version release",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 41081790,
	"plain_text": "breaking the ice a deep dive into the IcedID banking trojans new\r\nmajor version release\r\nBy Nir Somech, Limor Kessem\r\nPublished: 2020-04-01 · Archived: 2026-04-05 13:01:38 UTC\r\nNir Somech\r\nMalware Researcher – Trusteer IBM\r\nLimor Kessem\r\nX-Force Cyber Crisis Management Global Lead\r\nIBM\r\nThe IcedID banking Trojan was discovered by IBM X-Force researchers in 2017. At that time, it targeted banks,\r\npayment card providers, mobile services providers, payroll, webmail and e-commerce sites, mainly in the U.S.\r\nIcedID has since continued to evolve, and while one of its more recent versions became active in late-2019, X-Force researchers have identified a new major version release that emerged in 2020 with some substantial\r\nchanges.\r\nThis post will delve into the technical details of IcedID version 12 (0xC in hexadecimal). Before we delve into the\r\ntechnical details, here are the components that saw changes applied in this new version:\r\nNew anti-debugging and anti-VM checks.\r\nModified infection routine and file location on disk.\r\nHiding encrypted payload in .png file (steganography).\r\nModification of code injection tactics.\r\nModified cryptographic functions.\r\nIn this post, you will also find information on IcedID’s naming algorithms that are used for creating names for its\r\nvarious files, events, and resources. We also mention how to find and extract the malware’s internal version\r\nnumber.\r\nIcedID’s entry point – Targeted maldocs via other malware\r\nIcedID is spread via malspam emails typically containing Office file attachments. The files are boobytrapped with\r\nmalicious macros that launch the infection routine, fetch and run the payload.\r\nIn February 2020 campaigns, maldocs spread in spam first dropped the OStap malware, which then dropped\r\nIcedID. OStap was also a vehicle for TrickBot infections in recent months. IcedID has a connection to the Emotet\r\ngang, having been dropped by Emotet in the past.\r\nhttps://securityintelligence.com/posts/breaking-the-ice-a-deep-dive-into-the-icedid-banking-trojans-new-major-version-release/\r\nPage 1 of 43\n\nThe latest tech news, backed by expert insights\r\nStay up to date on the most important—and intriguing—industry trends on AI, automation, data and beyond with\r\nthe Think Newsletter, delivered twice weekly. See the IBM Privacy Statement.\r\nAttack turf\r\nIcedID’s targeting has been consistent since it emerged. Its focus remains on the North American financial sector,\r\ne-commerce, and social media. IcedID targets business users and business banking services.\r\nIcedID’s loader’s behavior\r\nUpon the first time running the loader in our labs, we observed that it performs a few actions before deciding\r\nwhether to infect the machine or not. It begins by loading encrypted code from the resource section, decrypts it\r\nand executes.\r\nhttps://securityintelligence.com/posts/breaking-the-ice-a-deep-dive-into-the-icedid-banking-trojans-new-major-version-release/\r\nPage 2 of 43\n\nFigure 1: IcedID loader running encrypted code\r\n1. As part of the code being executed, the loader uses some newly added anti-VM \u0026 anti-debugging\r\ntechniques in order to check if it’s being run in a VM or a sandbox. The output of these checks, alongside\r\nother parameters, is then sent to the attacker’s command and control (C\u0026C/C2) server to determine if the\r\nvictim’s machine should be infected or not.If the malware is to proceed to infect the machine, the C2 server\r\nsends back the necessary files to execute, like the malware’s configuration file, the actual malicious\r\npayload (saved as encrypted and packed .png file) and a few other accompanying files.The loader then\r\ncopies itself into two locations:\r\n1. C:\\ImgContent\\\r\nHiding code inside an image is a technique known as steganography.\r\nhttps://securityintelligence.com/posts/breaking-the-ice-a-deep-dive-into-the-icedid-banking-trojans-new-major-version-release/\r\nPage 3 of 43\n\nFigure 2: IcedID loader copies itself to local disk\r\n1. %appdata%\\local\\[user]\\[generated_name]\\\r\nhttps://securityintelligence.com/posts/breaking-the-ice-a-deep-dive-into-the-icedid-banking-trojans-new-major-version-release/\r\nPage 4 of 43\n\nFigure 3: IcedID loader copies itself to a second location on the local disk\r\nNext, in order to maintain persistency on the victim’s machine, the malware creates a task in the task scheduler\r\ntriggering a run of the loader at log on and every hour.\r\nhttps://securityintelligence.com/posts/breaking-the-ice-a-deep-dive-into-the-icedid-banking-trojans-new-major-version-release/\r\nPage 5 of 43\n\nFigure 4: IcedID task scheduler\r\nhttps://securityintelligence.com/posts/breaking-the-ice-a-deep-dive-into-the-icedid-banking-trojans-new-major-version-release/\r\nPage 6 of 43\n\nFigure 5: IcedID task scheduler\r\nAfter copying itself to these two locations and after creating the persistency mechanism, it executes couple of anti-VM and anti-debugging checks to allow the C2 to ‘approve’ proceeding to infect the machine. The loader\r\ndownloads all the necessary files in order to execute.\r\nIn the next section, we will go over the anti-VM and anti-debugging checks the loader performs.\r\nOne of the important files the loader fetches is the malicious payload that contains all of IcedID’s logic and which\r\nis actually the main module of the malware. It saves this core module under the path\r\n“%appdata%\\local\\user_name\\photo.png“. This file is initially encrypted and packed.\r\nThe path and the file name of the downloaded payload are both hardcoded.\r\nhttps://securityintelligence.com/posts/breaking-the-ice-a-deep-dive-into-the-icedid-banking-trojans-new-major-version-release/\r\nPage 7 of 43\n\nFigure 6: IcedID is saved as a packed, encrypted image\r\nThe loader reads the downloaded payload, which is saved as an encrypted .png file, then decrypts it, and will later\r\ninject it to a newly created svchost process.\r\nFigure 7: Loader reads IcedID payload\r\nNext, the loader creates a new process, svchost, and injects the decrypted IcedID payload into it.\r\nhttps://securityintelligence.com/posts/breaking-the-ice-a-deep-dive-into-the-icedid-banking-trojans-new-major-version-release/\r\nPage 8 of 43\n\nFigure 8: Process injection into a svchost process\r\nIcedID’s injected payload\r\nIcedID’s actual payload starts executing once it is injected to a newly created svchost process.\r\nSince the injected IcedID payload is originally packed, it begins by unpacking itself.\r\nAfter unpacking itself, the core IcedID module performs some initialization steps in order to run properly. It\r\ndownloads and reads different files necessary for the execution flow, like the configuration file (chercrgnaa.dat in\r\nthis case), certificate file (3D8C2D77.tmp in this case), and other supporting resources.\r\nhttps://securityintelligence.com/posts/breaking-the-ice-a-deep-dive-into-the-icedid-banking-trojans-new-major-version-release/\r\nPage 9 of 43\n\nFigure 9: IcedID payload launched into action\r\nThe IcedID module checks to make sure there is no other instance of that same file and that it is not already\r\nrunning, gets some information about the victim’s system, checks the versioning, sends some information to the\r\nC2 and starts scanning for running browser processes in order to inject its payload into them and hook them. The\r\nbrowser hooking will allow IcedID to detect targeted URLs and deploy web-injections accordingly.\r\nInfection process via loader and IcedID payload:\r\n1. The loader communicates with the C2 to fetch the IcedID payload\r\n2. The downloader downloads the malicious payload – a file named photo.png*\r\n3. The loader runs photo.png\r\n4. The loader creates a new instance of svchost.exe\r\n5. Loader injects the malicious payload into the new svchost.exe process\r\nhttps://securityintelligence.com/posts/breaking-the-ice-a-deep-dive-into-the-icedid-banking-trojans-new-major-version-release/\r\nPage 10 of 43\n\nThe second step in the list above happens only the first time the malware is run, or when it updates and downloads\r\na newer version of the malicious payload, photo.png. That happens because after downloading the photo.png file,\r\nit saves it to a disk so that every time the malware is launched, it simply has to load the file from the disk into\r\nmemory.\r\nSee the naming algorithms section – svchost mutex name – for more information.\r\nFigure 10: Infection process via loader and IcedID payload\r\nAnti-VM and anti-debugging tactics\r\nIcedID’s new version has been upgraded with additional abilities to hide itself and detect when it is being run in a\r\nvirtual environment or in debug mode. In previous versions, this malware did not feature these evasion\r\ntechniques.\r\nhttps://securityintelligence.com/posts/breaking-the-ice-a-deep-dive-into-the-icedid-banking-trojans-new-major-version-release/\r\nPage 11 of 43\n\nThe checks start with the loader that’s programmed to identify if it is running in a virtualized environment or\r\nunder a debugger. In the images below, we can see the function named “anti_vm” that checks whether the\r\nmalware is running in an emulator.\r\nThe loader also uses some anti-debugging and anti-VM instructions such as the Read-Time-Stamp-Counter\r\ninstruction (RDTSC), which can help it detect if a researcher is pausing the debugger in different steps., if it is\r\nbeing run under a debugger. It uses CPUID with 0x40000000 as a parameter looking for hypervisor brands,\r\nCPUID and more.\r\nWe can see in the image below that the loader runs in a loop 255 times. Inside the loop, it executes the RDSTC\r\ninstruction at both the beginning and at the end of the loop, and in between it executes the command CPUID with\r\n0x01 as a parameter.\r\nFigure 11: Using the RDTSC instruction to detect running under debug mode\r\nUsually, the output of the CPUID instruction with 0x01 as a parameter is used to detect VMs, but here it ignores\r\nthe output and only calculates the time difference between the first and the second calls of RDSTC.\r\nDepending on the calculated delta, the loader increments the relevant counter:\r\n0 \u003c Difference \u003c 250? ++less_250_miliseconds\r\n250 \u003c Difference \u003c 500? ++less_500_miliseconds\r\n500 \u003c Difference \u003c 750? ++less_750_miliseconds\r\n750 \u003c Difference \u003c 1000? ++less_1000_miliseconds\r\nelse? ++Big_Gap\r\nNext, the malware performs yet another test in order to validate if it is running in a VM or on a physical machine:\r\nhttps://securityintelligence.com/posts/breaking-the-ice-a-deep-dive-into-the-icedid-banking-trojans-new-major-version-release/\r\nPage 12 of 43\n\nFigure 12: Malware checking if it is being run in a test environment\r\nIt calls CPUID with 0x40000000 as a parameter and the output is a value that indicates the VM vendor brand and\r\ntype when it is run inside a virtual machine:\r\nVMM_XEN: ebx = 0x566e6558 and ecx = 0x65584d4d and edx = 0x4d4d566e\r\nVMM_HYPER_V: ebx = 0x7263694D and ecx = 0x666F736F and edx = 0x76482074\r\nVMM_VMWARE: ebx = 0x61774d56 and ecx = 0x4d566572 and edx = 0x65726177\r\nVMM_KVM: ebx = 0x4b4d564b and ecx = 0x564b4d56 and edx = 0x0000004d\r\nAll this collected data is later sent to the C2 server to help determine if the malware is being run in a VM or\r\ndebugged environment. According to the output, the C2 server decides whether to send all the files necessary to\r\ninfect the machine and run the IcedID core module.\r\nhttps://securityintelligence.com/posts/breaking-the-ice-a-deep-dive-into-the-icedid-banking-trojans-new-major-version-release/\r\nPage 13 of 43\n\nCode injection techniques\r\nIcedID has two code injection methods.\r\nThe first injection method is used when the malware is launched for the first time or at system start-up. This first\r\nmethod injects code into a spawned svchost.exe process.\r\nThe second injection method takes place when the malware detects that a browser process is running in the\r\nbackground and injects its shellcode to that running browser process.\r\nIcedID uses a slight code obfuscation to make it difficult to analyze. The code obfuscation works by calling\r\nWindows API functions indirectly instead of calling the functions directly using dynamically loading the Windows\r\nAPI functions it calls into Registers.\r\nLet’s look at these two techniques more visually. IcedID has two code injection methods.\r\nIcedID’s svchost process injection method\r\nIn the first code injection type, the malware begins by creating a svchost process in suspend state.\r\nhttps://securityintelligence.com/posts/breaking-the-ice-a-deep-dive-into-the-icedid-banking-trojans-new-major-version-release/\r\nPage 14 of 43\n\nFigure 13: IcedID code injection process\r\nhttps://securityintelligence.com/posts/breaking-the-ice-a-deep-dive-into-the-icedid-banking-trojans-new-major-version-release/\r\nPage 15 of 43\n\nFigure 14: IcedID code injection process\r\nNext, it allocates memory in the target process (svchost.exe) and injects its shellcode into the allocated memory. It\r\nthen changes the protection flag of the allocated memory space to PAGE_READ_EXECUTE.\r\nNext, it calls the function “NtQueueApcThread” with the main thread of the injected process and the entry point\r\naddress in the injected shellcode.\r\nAt the end of the injection process, it calls “NtResumeThread” in order to run its own code in the now injected\r\nprocess (svchost.exe).\r\nhttps://securityintelligence.com/posts/breaking-the-ice-a-deep-dive-into-the-icedid-banking-trojans-new-major-version-release/\r\nPage 16 of 43\n\nFigure 15: IcedID code injection process\r\nhttps://securityintelligence.com/posts/breaking-the-ice-a-deep-dive-into-the-icedid-banking-trojans-new-major-version-release/\r\nPage 17 of 43\n\nFigure 16: IcedID code injection process\r\nhttps://securityintelligence.com/posts/breaking-the-ice-a-deep-dive-into-the-icedid-banking-trojans-new-major-version-release/\r\nPage 18 of 43\n\nFigure 17: IcedID code injection process\r\nhttps://securityintelligence.com/posts/breaking-the-ice-a-deep-dive-into-the-icedid-banking-trojans-new-major-version-release/\r\nPage 19 of 43\n\nFigure 18: IcedID code injection process\r\nSvchost –\u003e Browser injection method\r\nThis second case takes place when the malicious svchost process detects that a browser process was launched. It\r\ngets a handle to the process and calls the function “Inject_browser” as shown in the figure below.\r\nhttps://securityintelligence.com/posts/breaking-the-ice-a-deep-dive-into-the-icedid-banking-trojans-new-major-version-release/\r\nPage 20 of 43\n\nFigure 19: IcedID browser injection process\r\nInside “Inject_browser” it calls three functions — “ZwWritevirtualMemory”, “NtProtectVirtualMemory” and\r\n“ZwAllocatevirtualMemory” — in order to inject its shellcode into the browser’s process.\r\nAfter injecting the shellcode into the browser process, it calls “CreateRemoteThread” with the entry point address\r\nin the injected shellcode.\r\nhttps://securityintelligence.com/posts/breaking-the-ice-a-deep-dive-into-the-icedid-banking-trojans-new-major-version-release/\r\nPage 21 of 43\n\nFigure 20: IcedID browser injection process\r\nhttps://securityintelligence.com/posts/breaking-the-ice-a-deep-dive-into-the-icedid-banking-trojans-new-major-version-release/\r\nPage 22 of 43\n\nFigure 21: IcedID browser injection process\r\nhttps://securityintelligence.com/posts/breaking-the-ice-a-deep-dive-into-the-icedid-banking-trojans-new-major-version-release/\r\nPage 23 of 43\n\nFigure 22: IcedID browser injection process\r\nIcedID’s cryptographic choices and techniques\r\nIcedID uses a few different decryption and decoding algorithms to hide some artefacts that can help malware\r\nresearchers understand the context of its functions and operational flow.\r\nThe cryptographic functions are being used in all processes that IcedID creates or injects, namely svchost and web\r\nbrowser processes.\r\nIcedID’s cryptography functions are as follows:\r\n1. Decode (int a1)\r\nhttps://securityintelligence.com/posts/breaking-the-ice-a-deep-dive-into-the-icedid-banking-trojans-new-major-version-release/\r\nPage 24 of 43\n\nUsually used with other decryption algorithms — for example, the algorithms that decode browser event name or\r\nmutex in svchost process. The function gets one argument, an integer, and runs a few bitwise operations on this\r\nparameter.\r\nFigure 23: IcedID decoding function Decode (int a1)\r\n2. Decrypt (int key, string encrypted_string)\r\nUsually used to decrypt encrypted strings and artefacts in the code in order to harden the reverse-engineering\r\nprocess. The function gets two arguments: key (integer) and string to decrypt (string). This function remains\r\nunchanged from the last version of IcedID.\r\nhttps://securityintelligence.com/posts/breaking-the-ice-a-deep-dive-into-the-icedid-banking-trojans-new-major-version-release/\r\nPage 25 of 43\n\nFigure 24: IcedID decryption function\r\n3. Decode_by_constant (int key, char[] arr)\r\nResponsible for generating event names for browser processes that IcedID manages to infect. The function gets\r\ntwo arguments: constant\\key (integer) and array (char[]).\r\nhttps://securityintelligence.com/posts/breaking-the-ice-a-deep-dive-into-the-icedid-banking-trojans-new-major-version-release/\r\nPage 26 of 43\n\nFigure 25: IcedID Decode_by_constant function\r\n4. CreateGlobalKey (string sid)\r\nCreates a global key that is then used for other encryption and decryption algorithms and for naming algorithms.\r\nThis function gets one argument: the system ID (SID) of the infected user’s device. The algorithm being used here\r\nis the Fowler–Noll–Vo hash.\r\nhttps://securityintelligence.com/posts/breaking-the-ice-a-deep-dive-into-the-icedid-banking-trojans-new-major-version-release/\r\nPage 27 of 43\n\nFigure 26: IcedID using the Fowler–Noll–Vo hash non-cryptographic hash function\r\n5. RC4_variant (int[] arr)\r\nThis function is responsible for decrypting encrypted files, such as configuration files, the encrypted payload\r\ndownloaded from the C2, the code loaded and injected to the svchost process, and more.\r\nThis encryption/decryption algorithm is an RC4 cipher variant that continues to use the string ‘zeus’ as the\r\nkeyword like it does in previous versions.\r\nThere were slight changes in the RC4 cipher in this version which means that standard RC4 decryption algorithms\r\nin Python libraries will not work against only the RC4-encrypted data because it has been customized by IcedID’s\r\ndevelopers. A custom or modified RC4 decryptor would have to be used to decrypt new configurations.\r\nThe function gets one argument – an array – that contains the encrypted payload to decrypt.\r\nhttps://securityintelligence.com/posts/breaking-the-ice-a-deep-dive-into-the-icedid-banking-trojans-new-major-version-release/\r\nPage 28 of 43\n\nFigure 27: IcedID using the RC4 stream cipher to encrypt/decrypt resources\r\n6. initKey (int GlobalKey, int constant, int[] key)\r\nInitializes the key for the RC4 variant decryption algorithm. It gets three parameters: the GlobalKey (integer),\r\nconstant (integer) and an array of integer/chars.\r\nhttps://securityintelligence.com/posts/breaking-the-ice-a-deep-dive-into-the-icedid-banking-trojans-new-major-version-release/\r\nPage 29 of 43\n\nFigure 28: IcedID initKey function\r\nIcedID’s naming algorithms\r\nIcedID uses a few naming algorithms in order to generate names for its files, directories, mutexes, events, etc.\r\nHere are some of the different uses of IcedID’s naming algorithms:\r\n1. Browser event name\r\nWhen the malware injects itself into a new browser process, it creates an event in order to know that this browser\r\nprocess has already been injected. It uses the function “decode_by_constant(int key, char[] arr)” in order to\r\ngenerate the event name. The event name is similar for all types of browsers. For the event name created in the\r\nbrowser, the key is hardcoded with the value 6 (key = 6).\r\nhttps://securityintelligence.com/posts/breaking-the-ice-a-deep-dive-into-the-icedid-banking-trojans-new-major-version-release/\r\nPage 30 of 43\n\nFigure 29: IcedID uses a naming algorithm to generate names for events\r\n2. Svchost mutex name\r\nhttps://securityintelligence.com/posts/breaking-the-ice-a-deep-dive-into-the-icedid-banking-trojans-new-major-version-release/\r\nPage 31 of 43\n\nFigure 30: IcedID uses a naming algorithm to name mutexes it creates\r\nWhen the malware is injected into a svchost process that it created, it also creates a mutex in order to know that\r\nthis svchost process has already been injected.\r\nIn the image below, we can see the “create_mutex_svchost” function. At the beginning of the function, it calls the\r\nfunction “generate_mutex_name” and generates the name of the mutex that will be created. The function has two\r\nparameters: key, which is the hardcoded value 7, and array, which will contain the generated name.\r\nhttps://securityintelligence.com/posts/breaking-the-ice-a-deep-dive-into-the-icedid-banking-trojans-new-major-version-release/\r\nPage 32 of 43\n\nFigure 31: IcedID mutex naming technique\r\nThe function “generate_mutex_name” first calls the function “mutex_name” with key=7 and an empty array that\r\nwill contain the characters used for the mutex name.\r\nNext, it calls the function “decrypt” with the encrypted “mutex_name_format” string. Finally, it prints and returns\r\nthe mutex name to the array it got as an argument.\r\nThe function “mutex_name” gets as arguments a key (key=7) and array that will contain the resulting mutex\r\nname. It runs a few bitwise operations on the argument key and the globalkey/init_key.\r\nThe result of this bitwise operation is the svchost mutex name.\r\nhttps://securityintelligence.com/posts/breaking-the-ice-a-deep-dive-into-the-icedid-banking-trojans-new-major-version-release/\r\nPage 33 of 43\n\nFigure 32: IcedID mutex naming technique\r\n3. Configuration file paths\r\nFirst, the malware retrieves the “appdata\\local\\” path by calling the function SHGetFolderPathW with 0x1c as a\r\nparameter, as pictured below in Figure 33 (circled in black).\r\nNext, it calls the function Decode_by_constant(key, arr) with key=4. The return value is the name of the folder in\r\n“appdata\\local\\”, as pictured below in Figure 33 (circled in gray).\r\nThere are two configuration files in the configuration folder, both with .dat extensions.\r\nIn order to generate the file names, IcedID performs the following steps:\r\n1. Each of the files has an initial constant value (0 and 1) and the malware runs some bitwise operations on\r\nthem and gets an integer as a result (5 and 261), as pictured below in Figure 33 (circled in red).\r\n2. Next, it takes the generated value and calls the function Decode_by_constant(key, arr) with\r\nkey=generated_value. The returned value is the first X letters in X+2 letters of the T configuration file, as\r\npictured below in Figure 33 (circled in red).\r\nhttps://securityintelligence.com/posts/breaking-the-ice-a-deep-dive-into-the-icedid-banking-trojans-new-major-version-release/\r\nPage 34 of 43\n\n3. The last two characters of the configuration file’s name are generated by executing bitwise operations on\r\nthe initial value related to the file, as pictured below in Figure 33 (circled in yellow).\r\nFigure 33: IcedID configuration files path definition\r\nhttps://securityintelligence.com/posts/breaking-the-ice-a-deep-dive-into-the-icedid-banking-trojans-new-major-version-release/\r\nPage 35 of 43\n\nFigure 34: IcedID configuration files\r\nIcedID’s certificate files\r\nThe IcedID version we examined stores certificate files related to the malware under “appdata\\local\\Temp” with\r\nthe same name as the global key the malware generates. The suffix of the certificate file is .tmp.\r\nhttps://securityintelligence.com/posts/breaking-the-ice-a-deep-dive-into-the-icedid-banking-trojans-new-major-version-release/\r\nPage 36 of 43\n\nFigure 35: IcedID certificate files stored as .tmp files\r\nIcedID’s configuration files\r\nIcedID downloads configuration files from the C\u0026C. The configuration files contain targeted banks and retailers,\r\nand the payload injected into the browser processes.\r\nhttps://securityintelligence.com/posts/breaking-the-ice-a-deep-dive-into-the-icedid-banking-trojans-new-major-version-release/\r\nPage 37 of 43\n\nFigure 36: IcedID configuration files\r\nIcedID’s code versioning\r\nIcedID’s developers continuously update its code over time. While bug fixes are naturally more frequent, we also\r\nsee the occasional release of a new major version. This malware’s version number is hardcoded and resides in the\r\nencrypted photo.png file.\r\nWe can see the version number in the malicious svchost process by looking at the function that contains the main\r\nlogic of the malware.\r\nhttps://securityintelligence.com/posts/breaking-the-ice-a-deep-dive-into-the-icedid-banking-trojans-new-major-version-release/\r\nPage 38 of 43\n\nFigure 37: IcedID version number is a part of its code\r\nCircled in red in Figure 37 above, we can see the sample version: 12 (0xC in hexadecimal).\r\nBrowser hooking\r\nWhen IcedID detects a browser process running in the system, it injects its malicious payload into the browser\r\nprocess and hooks relevant functions. Some of the targeted functions are Windows API functions, such as those\r\nfrom the kernel32, crypt32, WinINet and ws2_32 dynamic link libraries and some related to the browser vendor.\r\nhttps://securityintelligence.com/posts/breaking-the-ice-a-deep-dive-into-the-icedid-banking-trojans-new-major-version-release/\r\nPage 39 of 43\n\nhttps://securityintelligence.com/posts/breaking-the-ice-a-deep-dive-into-the-icedid-banking-trojans-new-major-version-release/\r\nPage 40 of 43\n\nFigure 38: Browser hooked functions\r\nIcedID still in the cyber crime game\r\nIcedID emerged in 2017 and continues to evolve its capabilities. While it has not been the most active malware\r\nover the past three years, its low activity volumes are mostly attributed to its continued focus on the same attack\r\nturf: North America. And while it has not topped the charts of 2019’s most prevalent banking Trojans, it has\r\nconsistently been targeting banks and retailers, and receives updates to the mechanisms that allow it to keep\r\nworking on devices that get updated over time.\r\nhttps://securityintelligence.com/posts/breaking-the-ice-a-deep-dive-into-the-icedid-banking-trojans-new-major-version-release/\r\nPage 41 of 43\n\nFigure 39: Top banking Trojans in 2019 (Source: IBM X-Force)\r\nWith its known connections to elite cybercrime gangs originating in Russia and other parts of Eastern Europe, the\r\nIcedID Trojan, and the group that operates it, are likely to continue to be part of the cybercrime arena.\r\nInterestingly, while we have been observing different gangs in this sphere diversify their revenue models to\r\ninclude high-stakes ransomware attacks, IcedID has not been part of the same trend so far. Will it follow in the\r\nfootsteps of its counterparts? We will be following the trend as it evolves.\r\nTo stay up to date on IcedID and other malware and receive technical updates on the threat landscape, read IBM\r\nX-Force research blogs on Security Intelligence and visit X-Force Exchange.\r\nIOCs\r\nhttps://securityintelligence.com/posts/breaking-the-ice-a-deep-dive-into-the-icedid-banking-trojans-new-major-version-release/\r\nPage 42 of 43\n\nMD5s:\r\nLoader: 9C8EF9CCE8C2B7EDA0F8B1CCDBE84A14\r\nPayload: 925689582023518E6AA8948C3F5E7FFE\r\nConnections:\r\nhxxp://www.hiperdom[.]top\r\nhxxp://www.gertuko[.]top\r\nFile Paths:\r\nC:\\Users\\[user]\\AppData\\Local\\”generated name”\r\nC:\\Users\\[user]\\AppData\\Local\\”user name”\r\nC:\\Users\\[user]\\AppData\\Local\\Temp\r\nSource: https://securityintelligence.com/posts/breaking-the-ice-a-deep-dive-into-the-icedid-banking-trojans-new-major-version-release/\r\nhttps://securityintelligence.com/posts/breaking-the-ice-a-deep-dive-into-the-icedid-banking-trojans-new-major-version-release/\r\nPage 43 of 43\n\n https://securityintelligence.com/posts/breaking-the-ice-a-deep-dive-into-the-icedid-banking-trojans-new-major-version-release/   \nFigure 29: IcedID uses a naming algorithm to generate names for events\n2. Svchost mutex name   \n   Page 31 of 43\n\nWhen IcedID process and hooks detects a browser relevant functions. process running Some of in the system, the targeted functions it injects its malicious are Windows payload into API functions, the browser such as those\nfrom the kernel32, crypt32, WinINet and ws2_32 dynamic link libraries and some related to the browser vendor.\n   Page 39 of 43",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"ETDA"
	],
	"references": [
		"https://securityintelligence.com/posts/breaking-the-ice-a-deep-dive-into-the-icedid-banking-trojans-new-major-version-release/"
	],
	"report_names": [
		"breaking-the-ice-a-deep-dive-into-the-icedid-banking-trojans-new-major-version-release"
	],
	"threat_actors": [
		{
			"id": "d90307b6-14a9-4d0b-9156-89e453d6eb13",
			"created_at": "2022-10-25T16:07:23.773944Z",
			"updated_at": "2026-04-10T02:00:04.746188Z",
			"deleted_at": null,
			"main_name": "Lead",
			"aliases": [
				"Casper",
				"TG-3279"
			],
			"source_name": "ETDA:Lead",
			"tools": [
				"Agentemis",
				"BleDoor",
				"Cobalt Strike",
				"CobaltStrike",
				"RbDoor",
				"RibDoor",
				"Winnti",
				"cobeacon"
			],
			"source_id": "ETDA",
			"reports": null
		}
	],
	"ts_created_at": 1775434817,
	"ts_updated_at": 1775791431,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/555a70bbe59249958aed349b57dbc17e5966ab1d.pdf",
		"text": "https://archive.orkl.eu/555a70bbe59249958aed349b57dbc17e5966ab1d.txt",
		"img": "https://archive.orkl.eu/555a70bbe59249958aed349b57dbc17e5966ab1d.jpg"
	}
}