{
	"id": "ceb81858-879e-4205-8b70-668254e63d85",
	"created_at": "2026-04-06T00:13:37.893739Z",
	"updated_at": "2026-04-10T13:13:10.600437Z",
	"deleted_at": null,
	"sha1_hash": "54317361621dc39aa98575c356346ccbca463bad",
	"title": "ICEDIDs network infrastructure is alive and well",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1678528,
	"plain_text": "ICEDIDs network infrastructure is alive and well\r\nBy Daniel Stepanic, Seth Goodwin, Derek Ditch, Andrew Pease\r\nPublished: 2022-10-31 · Archived: 2026-04-05 17:58:18 UTC\r\nKey takeaways\r\nICEDID is a full-featured trojan that uses TLS certificate pinning to validate C2 infrastructure.\r\nWhile the trojan has been tracked for several years, it continues to operate relatively unimpeded.\r\nA combination of open source collection tools can be used to track the C2 infrastructure.\r\nFor information on the ICEDID configuration extractor and C2 infrastructure validator, check out our posts\r\ndetailing this:\r\nICEDID configuration extractor\r\nICEDID network infrastructure checking utility\r\nPreamble\r\nICEDID, also known as Bokbot, is a modular banking trojan first discovered in 2017 and has remained active over the last\r\nseveral years. It has been recently known more for its ability to load secondary payloads such as post-compromise\r\nframeworks like Cobalt Strike, and has been linked to ransomware activity.\r\nICEDID is implemented through a multistage process with different components. Initial access is typically gained through\r\nphishing campaigns leveraging malicious documents or file attachments.\r\nWe’ll be discussing aspects of ICEDID in the next couple of sections as well as exploring our analysis technique in tracking\r\nICEDID infrastructure.\r\nInitial access\r\nCommand and control\r\nPersistence\r\nCore functionality\r\nNetwork infrastructure\r\nAs mentioned in the Preamble, ICEDID has been around for many years and has a rich feature set. As the\r\nmalware has been analyzed multiple times over the years, we are going to focus on some of the more interesting\r\nfeatures.\r\nInitial access\r\nICEDID infections come in many different forms and have been adjusted using different techniques and novel execution\r\nchains to avoid detection and evade antimalware products. In this sample, ICEDID was delivered through a phishing email.\r\nThe email contains a ZIP archive with an embedded ISO file. Inside the ISO file is a Windows shortcut (LNK) that, when\r\ndouble-clicked, executes the first stage ICEDID loader (DLL file).\r\nInitial infection - Windows shortcut \u0026 DLL\r\nThe Windows shortcut target value is configured to execute %windir%\\system32\\rundll32.exe olasius.dll,PluginInit\r\ncalling the PluginInit export, which starts the initial stage of the ICEDID infection. This stage is responsible for decrypting\r\nthe embedded configuration, downloading a GZIP payload from a C2 server, writing an encrypted payload to disk (\r\nlicense.dat ), and transferring execution to the next stage.\r\nhttps://www.elastic.co/security-labs/icedids-network-infrastructure-is-alive-and-well\r\nPage 1 of 10\n\nWindows shortcut command-line\r\nThe first ICEDID stage starts off by deciphering an encrypted configuration blob of data stored within the DLL that is used\r\nto hold C2 domains and the campaign identifier. The first 32 bytes represent the XOR key; the encrypted data is then\r\ndeciphered with this key.\r\nConfiguration decryption function\r\nCommand and control\r\nICEDID constructs the initial HTTP request using cookie parameters that contain hexadecimal data from the infected\r\nmachine used for fingerprinting the victim machine. This request will proceed to download the GZIP payload irrespective of\r\nany previous identifying information.\r\neSentire has published research that describes in detail how the gads, gat, ga, u, and io cookie parameters are created.\r\nICEDID HTTP request\r\nhttps://www.elastic.co/security-labs/icedids-network-infrastructure-is-alive-and-well\r\nPage 2 of 10\n\nBelow are the cookie parameters and example associated values behind them.\r\nParameter Example Data Note\r\n__gads 3000901376:1:16212:134\r\nContains\r\nflag, Get\r\nnumber\r\nprocesse\r\n__gat 10.0.19044.64 OS versi\r\n__ga 1.591594.1635208534.76\r\nHypervi\r\ninformat\r\nCPUID/\r\nfunction\r\n__u 4445534B544F502D4A4B4738455432:6A6F656C2E68656E646572736F6E:33413945354637303742414339393534\r\nStores co\r\nusernam\r\n__io 21_3990468985_3832573211_2062024380 Security\r\n__gid 006869A80704 Encrypte\r\nThe downloaded GZIP payload contains a custom structure with a second loader ( hollow.dat ) and the encrypted ICEDID\r\ncore payload ( license.dat ). These two files are written to disk and are used in combination to execute the core payload in\r\nmemory.\r\nICEDID writing the second stage loader and payload\r\nThe next phase highlights a unique element with ICEDID in how it loads the core payload ( license.dat ) by using a custom\r\nheader structure instead of the traditional PE header. Memory is allocated with the sections of the next payload looped over\r\nand placed into their own virtual memory space. This approach has been well documented and serves as a technique to\r\nobstruct analysis.\r\nICEDID loading custom structure (header/sections)\r\nEach section has its memory protection modified by the VirtualProtect function to enable read-only or read/write access to\r\nthe committed region of memory using the PAGE_READWRITE constant.\r\nhttps://www.elastic.co/security-labs/icedids-network-infrastructure-is-alive-and-well\r\nPage 3 of 10\n\nICEDID using the PAGE_READWRITE constant\r\nOnce the image entry point is set up, the ICEDID core payload is then loaded by a call to the rax x86 register.\r\nICEDID loading its core payload\r\nPersistence\r\nICEDID will attempt to set up persistence first using a scheduled task, if that fails it will instead create a Windows Registry\r\nrun key. Using the Bot ID and RDTSC instruction, a scheduled task or run key name is randomly generated. A scheduled\r\ntask is created using taskschd.dll , configured to run at logon for the user, and is triggered every 1 hour indefinitely.\r\nICEDID scheduled task\r\nCore functionality\r\nThe core functionality of the ICEDID malware has been well documented and largely unchanged. To learn more about the\r\ncore payload and functionality, check out the Malpedia page that includes a corpus of completed research on ICEDID.\r\nThat said, we counted 23 modules during the time of our analysis including:\r\nMitM proxy for stealing credentials\r\nBackconnect module\r\nCommand execution (PowerShell, cmd)\r\nhttps://www.elastic.co/security-labs/icedids-network-infrastructure-is-alive-and-well\r\nPage 4 of 10\n\nShellcode injection\r\nCollect\r\nRegistry key data\r\nRunning processes\r\nCredentials\r\nBrowser cookies\r\nSystem information (network, anti-virus, host enumeration)\r\nSearch and read files\r\nDirectory/file listing on user’s Desktop\r\nICEDID configuration extractor\r\nElastic Security Labs has released an open source tool, under the Apache 2.0 license, that will allow for configurations to be\r\nextracted from ICEDID samples. The tool can be downloaded here.\r\nIcedID configuration decryption tool output\r\nTLS certificate pinning\r\nPrevious research into the ICEDID malware family has highlighted a repetitive way in how the campaigns create their self-signed TLS certificates. Of particular note, this technique for creating TLS certificates has not been updated in\r\napproximately 18 months. While speculative in nature, this could be reflective of the fact that this C2 infrastructure is not\r\nwidely tracked by threat data providers. This allows ICEDID to focus on updating the more transient elements of their\r\ncampaigns (file hashes, C2 domains, and IP addresses).\r\nThe team at Check Point published in-depth and articulate research on tracking ICEDID infrastructure using ICEDID’s TLS\r\ncertificate pinning feature. Additionally, Check Point released a script that takes an IP address and port, and validates the\r\nsuspect TLS serial number against a value calculated by the ICEDID malware to confirm whether or not the IP address is\r\ncurrently using an ICEDID TLS certificate.\r\nWe are including a wrapper that combines internet scanning data from Censys, and ICEDID C2 infrastructure conviction\r\nfrom the Check Point script. It can be downloaded here.\r\nDataset\r\nAs reported by Check Point, the TLS certificate information uses the same Issuer and Subject distinguished names to\r\nvalidate the C2 server before sending any data.\r\nICEDID C2 TLS certificate pinning\r\nTo build our dataset, we used the Censys CLI tool to collect the certificate data. We needed to make a slight adjustment to\r\nthe query from Check Point research, but the results were similar.\r\nhttps://www.elastic.co/security-labs/icedids-network-infrastructure-is-alive-and-well\r\nPage 5 of 10\n\ncensys search 'services.tls.certificates.leaf_data.subject_dn:\"CN=localhost, C=AU, ST=Some-State, O=Internet Widgits Pty\r\n[\r\n {\r\n \"ip\": \"103.208.85.237\",\r\n \"services\": [\r\n {\r\n \"port\": 22,\r\n \"service_name\": \"SSH\",\r\n \"transport_protocol\": \"TCP\"\r\n },\r\n {\r\n \"port\": 80,\r\n \"service_name\": \"HTTP\",\r\n \"transport_protocol\": \"TCP\"\r\n },\r\n {\r\n \"port\": 443,\r\n \"service_name\": \"HTTP\",\r\n \"certificate\": \"c5e7d92ba63be7fb2c44caa92458beef7047d7f987aaab3bdc41161b84ea2850\",\r\n \"transport_protocol\": \"TCP\"\r\n }\r\n ],\r\n \"location\": {\r\n \"continent\": \"Oceania\",\r\n \"country\": \"New Zealand\",\r\n \"country_code\": \"NZ\",\r\n…truncated…\r\nThis provided us with 113 IP addresses that were using certificates we could begin to attribute to ICEDID campaigns.\r\nJARM / JA3S\r\nWhen looking at the data from Censys, we also identified other fields that are useful in tracking TLS communications:\r\nJARM and JA3S, both TLS fingerprinting tools from the Salesforce team.\r\nAt a high-level, JARM fingerprints TLS servers by actively collecting specific elements of the TLS Server Hello responses.\r\nJA3S passively collects values from the TLS Server Hello message. JARM and JA3S are represented as a 62-character or\r\n32-character fingerprint, respectively.\r\nJARM and JA3S TLS fingerprints in Kibana\r\nJARM and JA3S add additional data points that improve our confidence in connecting the ICEDID C2 infrastructure. In our\r\nresearch, we identified 2ad2ad16d2ad2ad22c2ad2ad2ad2adc110bab2c0a19e5d4e587c17ce497b15 as the JARM and\r\ne35df3e00ca4ef31d42b34bebaa2f86e as the JA3S fingerprints.\r\nIt should be noted that JARM and JA3S are frequently not uncommon enough to convict a host by themselves. As\r\nan example, in the Censys dataset, the JARM fingerprint identified over 15k hosts, and the JA3S fingerprint\r\nidentified over 3.3M hosts. Looking at the JARM and JA3S values together still had approximately 8k hosts.\r\nThese are data points on the journey to an answer, not the answer itself.\r\nICEDID implant defense\r\nBefore ICEDID communicates with its C2 server, it performs a TLS certificate check by comparing the certificate serial\r\nnumber with a hash of the certificate's public key. As certificate serial numbers should all be unique, ICEDID uses a self-signed certificate and an expected certificate serial number as a way to validate the TLS certificate. If the hash of the public\r\nkey and serial number do not match, the communication with the C2 server does not proceed.\r\nhttps://www.elastic.co/security-labs/icedids-network-infrastructure-is-alive-and-well\r\nPage 6 of 10\n\nICEDID certificate validation function\r\nWe used the Check Point Python script (which returns a true or false result for each passed IP address) to perform an\r\nadditional check to improve our confidence that the IP addresses were part of the ICEDID C2 infrastructure and not simply a\r\ncoincidence in having the same subject and issuer information of the ICEDID TLS certifications. A true result has a\r\nmatching ICEDID fingerprint and a false result does not. This resulted in 103 IPs that were confirmed as having an ICEDID\r\nTLS certificate and 10 that did not (as of October 14, 2022).\r\nICEDID TLS certificate confirmation\r\nImporting into Elasticsearch\r\nNow that we have a way to collect IPs based on the TLS certificate elements and a way to add additional context to aid in\r\nconviction; we can wrap the logic in a Bash script as a way to automate this process and parse the data for analysis in\r\nElasticsearch.\r\n#!/bin/bash -eu\r\nset -o pipefail\r\nSEARCH='services.tls.certificates.leaf_data.subject_dn:\"CN=localhost, C=AU, ST=Some-State, O=Internet Widgits Pty Ltd\" and\r\nhttps://www.elastic.co/security-labs/icedids-network-infrastructure-is-alive-and-well\r\nPage 7 of 10\n\nwhile read -r line; do\r\n _ts=$(date -u +%FT%TZ)\r\n _ip=$(echo ${line} | base64 -d | jq '.ip' -r)\r\n _port=$(echo ${line} | base64 -d | jq '.port' -r)\r\n _view=$(censys view \"${_ip}\" | jq -c)\r\n _is_icedid=$(python3 -c \"import icedid_checker; print(icedid_checker.test_is_icedid_c2('${_ip}','${_port}'))\")\r\n echo \"${_view}\" | jq -S --arg is_icedid \"${_is_icedid}\" --arg timestamp \"${_ts}\" '. + {\"@timestamp\": $timestamp, \"thre\r\ndone \u003c \u003c(censys search --pages=-1 \"${SEARCH}\" | jq '.[] | {\"ip\": .ip, \"port\": (.services[] | select(.certificate?).port)}\r\nThis outputs the data as an NDJSON document called icedid_infrastructure.ndjson that we can upload into Elasticsearch.\r\nIdentified ICEDID IP infrastructure\r\nIn the above image, we can see that there are hosts that have the identified JARM fingerprint, the identified TLS issuer and\r\nsubject elements, but did not pass the Check Point validation check. Additionally, one of the two hosts has a different JA3S\r\nfingerprint. This highlights the value of the combination of multiple data sources to inform confidence scoring.\r\nWe are also providing this script for others to use.\r\nObserved adversary tactics and techniques\r\nElastic uses the MITRE ATT\u0026CK framework to document common tactics, techniques, and procedures that advanced\r\npersistent threats use against enterprise networks.\r\nAs stated above, ICEDID has been extensively analyzed, so below we are listing the tactics and techniques that we observed\r\nand are covered in this research publication. If you’re interested in the full set of MITRE ATT\u0026CK tactics and techniques,\r\nyou can check out MITRE’s page on ICEDID.\r\nTactics\r\nTactics represent the why of a technique or sub-technique. It is the adversary’s tactical goal: the reason for performing an\r\naction.\r\nDiscovery\r\nExecution\r\nPersistence\r\nDefense evasion\r\nReconnaissance\r\nResource development\r\nInitial access\r\nCommand and control\r\nPrivilege Escalation\r\nTechniques / Sub techniques\r\nTechniques and Sub techniques represent how an adversary achieves a tactical goal by performing an action.\r\nPermission Groups Discovery\r\nAccount Discovery\r\nCommand and Scripting Interpreter\r\nSoftware Discovery\r\nSystem Binary Proxy Execution\r\nRemote System Discovery\r\nNetwork Share Discovery\r\nPhishing: Spearphishing attachment\r\nScheduled Task/Job: Scheduled Task\r\nhttps://www.elastic.co/security-labs/icedids-network-infrastructure-is-alive-and-well\r\nPage 8 of 10\n\nObfuscated Files or Information\r\nProcess Injection\r\nDetections and preventions\r\nDetection logic\r\nEnumeration of Administrator Accounts\r\nCommand Shell Activity Started via RunDLL32\r\nSecurity Software Discovery using WMIC\r\nSuspicious Execution from a Mounted Device\r\nWindows Network Enumeration\r\nPreventions\r\nMalicious Behavior Detection Alert: Command Shell Activity\r\nMemory Threat Detection Alert: Shellcode Injection\r\nMalicious Behavior Detection Alert: Unusual DLL Extension Loaded by Rundll32 or Regsvr32\r\nMalicious Behavior Detection Alert: Suspicious Windows Script Interpreter Child Process\r\nMalicious Behavior Detection Alert: RunDLL32 with Unusual Arguments\r\nMalicious Behavior Detection Alert: Windows Script Execution from Archive File\r\nYARA\r\nElastic Security has created YARA rules to identify this activity. Below is a YARA rule specifically to identify the TLS\r\ncertificate pinning function used by ICEDID.\r\nrule Windows_Trojan_IcedID_cert_pinning {\r\n meta:\r\n author = \"Elastic Security\"\r\n creation_date = \"2022-10-17\"\r\n last_modified = \"2022-10-17\"\r\n threat_name = \"Windows.Trojan.IcedID\"\r\n arch_context = \"x86\"\r\n license = \"Elastic License v2\"\r\n os = \"windows\"\r\n strings:\r\n$cert_pinning = { 74 ?? 8B 50 ?? E8 ?? ?? ?? ?? 48 8B 4C 24 ?? 0F BA F0 ?? 48 8B 51 ?? 48 8B 4A ?? 39 01\r\n condition:\r\n $cert_pinning\r\n}\r\nReferences\r\nThe following were referenced throughout the above research:\r\nhttps://malpedia.caad.fkie.fraunhofer.de/details/win.icedid\r\nhttps://research.checkpoint.com/2021/melting-ice-tracking-icedid-servers-with-a-few-simple-steps/\r\nhttps://attack.mitre.org/software/S0483/\r\nIndicators\r\nThe indicators observed in this research are posted below. All artifacts (to include those discovered through TLS certificate\r\npinning) are also available for download in both ECS and STIX format in a combined zip bundle.\r\nIndicator Type Note\r\ndb91742b64c866df2fc7445a4879ec5fc256319e234b1ac5a25589455b2d9e32 SHA256 ICEDID malware\r\nyolneanz[.]com domain ICEDID C2 domain\r\n51.89.190[.]220 ipv4-addr ICEDID C2 IP address\r\nhttps://www.elastic.co/security-labs/icedids-network-infrastructure-is-alive-and-well\r\nPage 9 of 10\n\nSource: https://www.elastic.co/security-labs/icedids-network-infrastructure-is-alive-and-well\r\nhttps://www.elastic.co/security-labs/icedids-network-infrastructure-is-alive-and-well\r\nPage 10 of 10",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://www.elastic.co/security-labs/icedids-network-infrastructure-is-alive-and-well"
	],
	"report_names": [
		"icedids-network-infrastructure-is-alive-and-well"
	],
	"threat_actors": [
		{
			"id": "610a7295-3139-4f34-8cec-b3da40add480",
			"created_at": "2023-01-06T13:46:38.608142Z",
			"updated_at": "2026-04-10T02:00:03.03764Z",
			"deleted_at": null,
			"main_name": "Cobalt",
			"aliases": [
				"Cobalt Group",
				"Cobalt Gang",
				"GOLD KINGSWOOD",
				"COBALT SPIDER",
				"G0080",
				"Mule Libra"
			],
			"source_name": "MISPGALAXY:Cobalt",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		}
	],
	"ts_created_at": 1775434417,
	"ts_updated_at": 1775826790,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/54317361621dc39aa98575c356346ccbca463bad.pdf",
		"text": "https://archive.orkl.eu/54317361621dc39aa98575c356346ccbca463bad.txt",
		"img": "https://archive.orkl.eu/54317361621dc39aa98575c356346ccbca463bad.jpg"
	}
}