{
	"id": "11ec2ba7-e1fa-4395-a21e-d6ecf260d96f",
	"created_at": "2026-04-06T00:17:50.624429Z",
	"updated_at": "2026-04-10T13:11:19.262989Z",
	"deleted_at": null,
	"sha1_hash": "17e8327593c8004c6627c3dc95c6e49f687d911e",
	"title": "Inside the IcedID BackConnect Protocol (Part 2)",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 659657,
	"plain_text": "Inside the IcedID BackConnect Protocol (Part 2)\r\nBy Team Cymru\r\nPublished: 2025-04-08 · Archived: 2026-04-05 19:04:39 UTC\r\nIntroduction\r\nIn this blog post, we will provide an update on our continued analysis and tracking of infrastructure associated\r\nwith IcedID’s BackConnect (BC) protocol; a continuation of the analysis we shared in late-December 2022, which\r\nyou can read here, in addition to our campaign metrics and infrastructure tracking blog posts.\r\nNote: whilst the same BC protocol is utilized by several other threat operations, including Bazar and QakBot, this\r\nblog post focuses specifically on IcedID infrastructure.\r\nGiven that it is deployed post-compromise following initial assessments of the value of a victim host, the use of\r\nthe BC protocol is of particular interest to us, and remains a priority for our overall tracking of IcedID. Analyzing\r\nactivity related to BC infrastructure provides a strategic view into threat actor activity and interests, as it is a\r\nwindow into what occurs after a successful infection and the victim was deemed valuable for their use.\r\nSince our last post, updates were made to the version of the BC protocol used by the IcedID threat actors during\r\nmid-April 2023. The last time we observed updates to the protocol was 7 months ago in September 2022. One of\r\nthe more noticeable changes, shared by Palo Alto Networks’ Unit 42, was in the port utilized by victim hosts when\r\nconnecting to the BC command and control (C2) server, which was updated from TCP/8080 to TCP/443.\r\nIn our previous blog post, we referenced 11 IcedID BC C2 servers, active from the beginning of July 2022 through\r\nthe end of 2022. Our analysis highlighted that generally two C2 servers were active at any given time, and the\r\naverage life cycle for a C2 server was around four weeks. We will revisit this C2 timeline in order to assess how\r\nIcedID’s use of the BC protocol has evolved over the past six months, and in doing so also review the associated\r\nmanagement infrastructure used to access / administer it.\r\nKey Findings\r\nThe overall quantity of BC C2s has increased.\r\nA total of 34 medium and high confidence IcedID BC C2 servers were identified since 23 January\r\n2023, up from 11 we observed from July 2022 until the end of the year.\r\nThe average life cycle for a BC C2 has decreased.\r\nThe average uptime of a BC C2 decreased from 28 days to eight days, and concurrently active\r\nservers increased from two to a maximum of four.\r\nAdditional management infrastructure has been identified.\r\nManagement activity continues to be sourced from two static VPN nodes, with other common\r\nmanagement peers observed.\r\nManagement-related activity has evolved from our last blog post.\r\nhttps://www.team-cymru.com/post/inside-the-icedid-backconnect-protocol-part-2\r\nPage 1 of 12\n\nManagement activity now varies from C2 to C2, we do not always observe connections from the\r\nsame management IPs.\r\nObserved management activity is likely a mix of IcedID operator and affiliate access.\r\nVictims can communicate with multiple BC C2 servers over time.\r\nA possible connection between BC-infected victims and spamming activity was identified.\r\nC2 Server Timeline\r\nAs explained in our previous blog post, a methodology was established for tracking BC C2 servers based on the\r\nobservance of management traffic from a number of static IP addresses. By regularly monitoring outbound traffic\r\nfrom these IPs, we continue to identify new C2 servers as communications commence.\r\nFigure 2: IcedID BC Protocol Management - c. November 2022\r\nIn this instance, management traffic is defined as IP addresses observed in communications with multiple C2\r\nservers, connecting to specific ports of interest, in repeated established sessions. The established sessions element\r\nis inferred based upon observed ephemeral ports and TCP flags, in simple terms; scenarios involving a consistent\r\nephemeral port with evidence of a successful TCP three-way handshake and subsequent activity / data transfer.\r\nhttps://www.team-cymru.com/post/inside-the-icedid-backconnect-protocol-part-2\r\nPage 2 of 12\n\nFigure 3: A Simple Visualization of the Previous Waffle 🙂\r\nGetting back to the C2 servers, the following timeline illustrates the periods when we observed management\r\ntraffic, and by extension an indication of when the C2 servers were in active use.\r\nWhilst this section is based on the enumeration of BC C2 servers since the aforementioned updates in April 2023,\r\nfor completeness we include all identified C2 servers (since the beginning of 2023) in the Indicators of\r\nCompromise section at the end of this post.\r\nFigure 4: Timeline of BC C2 Servers from mid-April 2023 Onwards\r\nSince 11 April 2023, a total of 20 high confidence BC C2 servers were identified, based on pivots from\r\nmanagement infrastructure.\r\nThe first observation is that the number of concurrent C2 servers in operation has increased since our previous\r\nblog post, with as many as four C2 servers receiving management communications on a particular day. We also\r\nnote that the life cycle of the C2 servers has decreased significantly, from around 28 days to just over eight.\r\nhttps://www.team-cymru.com/post/inside-the-icedid-backconnect-protocol-part-2\r\nPage 3 of 12\n\nFigure 5: Previous Timeline - July to December 2022\r\nThere are a number of hypothesized reasons for these changes and each one is not independent of the others (nor\r\nis the following list exhaustive):\r\nGreater awareness of BC infrastructure has resulted in faster response times; both in reporting to hosting\r\nproviders and mitigation activities; leading to a shorter C2 shelf-life.\r\nAn increase in the use of the BC protocol by IcedID threat actors and their affiliates has required additional\r\ninfrastructure to be stood up.\r\nDisruption / changes to activities has increased the need for additional back-up / fall-over C2 servers.\r\nGeneral evolution of threat actor modus operandi - e.g. “statistics show that an individual C2 server\r\nreaches its peak potential on day N (\u003c28 days), so why not rotate them more often?”. We know from\r\nanalyzing other IcedID infrastructure that the admins run a metrics-influenced operation.\r\nSince IcedID returned from its winter hiatus on 23 January 2023 through the end of June 2023, we have identified\r\n34 medium (50-75%) and high (75-99%) confidence BC C2 servers. In the case of the four medium confidence\r\nC2 servers, we (Team Cymru) were not able to confirm their usage with the same veracity, but on the balance of\r\nprobabilities are likely connected to IcedID BC activity; indeed some were reported by other researchers.\r\nManagement Infrastructure\r\nIn this section we will provide background context on the IP addresses we have observed accessing the BC C2s on\r\nparticular ports of interest; namely TCP/8082, TCP/8083, and TCP/8101.\r\nWe assess that TCP/8082 relates to the BC SOCKS proxy, TCP/8083 to VNC (screen sharing), however at this\r\nstage it is unclear what the use of TCP/8101 relates to. We began to observe this port (TCP/8081) open on BC C2\r\nservers over the past few months.\r\nThe two IP addresses we detailed in our previous blog post (see Figure 2) continue to be used to access BC C2\r\nservers, however they are no longer observed in every single case.\r\nThe VNC Management IP continues to be accessed from IP addresses assigned to MOLDTELECOM-AS\r\nand was last observed communicating with BC C2 servers in early July 2023.\r\nhttps://www.team-cymru.com/post/inside-the-icedid-backconnect-protocol-part-2\r\nPage 4 of 12\n\nThe SOCKS Management IP continues to be accessed from an IP address assigned to a Ukrainian ISP,\r\ninterspersed with irregular connections from Starlink infrastructure. Communications with BC C2 servers\r\nwas last observed in early June 2023.\r\nOver the past six months, we have observed other IPs accessing the BC C2 servers. By following the activities of\r\na number of these IPs we are able to fill in the blanks where we don’t see communications from those two\r\noriginally identified management nodes.\r\nIt is unclear why the IPs accessing the C2s vary depending on C2, ; although it is plausible to assess that the\r\nactivity originates from both IcedID operators and their affiliates.\r\nThe recently identified management IPs fall into three distinct categories:\r\nPrivate VPN Nodes\r\nThese IPs appear to be utilized in the same way as the initial two management IPs, with a limited number of\r\ninbound peers. Outbound traffic is broadly limited to IcedID BC-related infrastructure, with connections occurring\r\non all three ports of interest.\r\nGerman Node\r\nThis IP connects to BC C2 servers on TCP/8101 and is currently active at the time of writing. Aside from\r\nconnections to BC C2 servers, we also observe inbound connections from Tor relays - hinting at how this node is\r\naccessed.\r\nLatvian Node 🇱🇻\r\nThis IP connects to BC C2 servers on TCP/8082 and TCP/8083 and is also currently active at the time of writing.\r\nThis IP is observed in traffic indicative of blockchain/cryptocurrency trading and the use of Tor and Tox\r\nmessenger. TCP/1194, commonly associated with OpenVPN, is open on this IP - again hinting at how this node is\r\naccessed.\r\nRussian Node\r\nThis IP connects to BC C2 servers on TCP/8082 and TCP/8101 and is also currently active at the time of writing.\r\nAside from connections to BC C2 servers, we also observe outbound connections utilizing common mail ports\r\n(25, 143, 468, 993, etc).\r\nhttps://www.team-cymru.com/post/inside-the-icedid-backconnect-protocol-part-2\r\nPage 5 of 12\n\nFigure 6: Private VPN Nodes - Hypothesized Management Access\r\nJump Boxes\r\nIn February we published a blog post stemming from an investigation into an IP address which was observed\r\nconnecting to various elements/levels of the IcedID infrastructure, including BC C2 servers. This IP was\r\ngeolocated to Chile, but there was clear evidence that it was utilized by a Russian-speaking operator.\r\nSince our last post, we have observed the Chilean jump box was accessed via an OpenVPN connection from an IP\r\ngeolocated to Switzerland - assigned to Private Layer Inc, a Panamanian-registered VPS provider.\r\nWe have continued to monitor this Swiss IP, which has led to the identification of further jump boxes, utilized in\r\nmuch the same way as we described in the blog.\r\nhttps://www.team-cymru.com/post/inside-the-icedid-backconnect-protocol-part-2\r\nPage 6 of 12\n\nFigure 7: Jump Box Management and Identification\r\nSince June, an IP geolocated to the United States has been used as the current jump box and again this has\r\nincluded access to BC C2 servers.\r\nWe continue to assess that this infrastructure is associated with IcedID administration.\r\nRussian Telecommunications (Rostelecom)\r\nThese appear to be consumer IPs which, based on data from Spur Intelligence, are utilized as small gateways for a\r\nlimited number of concurrent users. We have observed numerous IPs (with no cross-over in usage) assigned to\r\nRostelecom, Russia’s largest ISP, in communication with BC C2 servers using port TCP/8083.\r\nWhois information for these IPs is consistent in identifying them as previous VolgaTelecom infrastructure for the\r\nMari El region of Russia. VolgaTelecom was absorbed by Rostelecom in 2011; it is unclear if this infrastructure\r\ncontinues to serve Mari El, however this may provide an indication of the end user’s location if so.\r\nOutside of the connections to BC C2 servers, we observe general Internet usage, BitTorrent activity, and evidence\r\nof the use of crypto-mining software.\r\nVictimology\r\nIn simple terms, victimology refers to the practice of understanding and studying the characteristics of victims\r\nversus focusing on the perpetrators. In cyber threat research we can use victim to C2 communications, at a large\r\nscale, to understand trends in threat activity.\r\nWe looked for potential victims by identifying activity that matched typical C2 communication over TCP/443,\r\nexcluding traffic that was likely researcher or scanner related. Eventually a sample of eight candidate victim IPs\r\nhttps://www.team-cymru.com/post/inside-the-icedid-backconnect-protocol-part-2\r\nPage 7 of 12\n\nfrom various ASNs and geographical regions was collected, all of which communicated with three or more BC\r\nC2s over a relatively long period of time. We found there were many other potential victims connections to the C2\r\nservers, but the majority communicated with only one or two, and for shorter time periods.\r\nIn the timeline below, connections with the BC C2 servers for each victim is indicated by a line next to the\r\ngeolocation of the victim. Each box on a line represents the start and end date of communication between the\r\nvictim and the C2 server listed within the box. Underneath the x-axis of the timeline are flags showing when we\r\nfirst spotted the C2 in the management infrastructure we monitor (a replication of Figure 4).\r\nFigure 8: BC Victim Timeline\r\nFor all of the victims in our sample, first connections to a new BC C2 server began after we identified the C2 via\r\nmonitoring the management related IPs mentioned in the section above. The two management nodes we originally\r\nwrote about in our previous blog only communicated with five of the BC C2 servers, and in some cases this only\r\noccurred after victim traffic had commenced.\r\nThis is a good example of why we continuously update our tracking of upstream threat actor infrastructure,\r\nwhilst it might remain static for a duration, this infrastructure can change or be superseded by other key\r\nhosts. In the case of IcedID BC infrastructure we were able to adapt our insights by continuing to pivot\r\nfrom NetFlow data for known BC C2 servers.\r\nWe see that victims can communicate with multiple BC C2s over time while they remain infected, but not every\r\nvictim communicates with every new C2. In fact, there is no discernable pattern around how long a victim\r\ncommunicates with a C2, when victims switch to a new C2, or which C2 servers a victim communicates with.\r\nHowever, when we pivot to analyzing the volume of traffic between victims and C2s, we finally see a pattern\r\nemerge.\r\nhttps://www.team-cymru.com/post/inside-the-icedid-backconnect-protocol-part-2\r\nPage 8 of 12\n\nFigure 9: Spikes in BC Victim Traffic Volume\r\nRegardless of C2, some days show jumps in traffic volume between the victims and C2 servers. For example, on\r\n13 June 2023 there was a spike for the British, Japanese, and German victims, but they were not communicating\r\nwith the same C2. The German and Japanese victims were communicating with C2 207.154.203.203, while the\r\nBritish victim was communicating with C2 68.183.198.18.\r\nThis is potentially indicative of the overall coordination of IcedID victims interacted with using the BC\r\nprotocol. Whilst victims may be communicating with separate C2 servers, we see peaks in activity within\r\nthe same time parameters. This points to the same IcedID operator or affiliate accessing multiple victims\r\nfor a specific purpose, likely via a panel which consolidates all victims together regardless of specific C2\r\nserver.\r\nTCP/587 and TCP/465 Activity\r\nWhile analyzing victim NetFlow data, we found that all eight victims from our sample group shared outbound\r\nconnections to some of the same obscure mail servers over TCP/465 and TCP/587, typically in bursts on the same\r\nday. We hypothesize these communications may be connected to IcedID delivery / spam operations.\r\nOften we observe the victims connecting to the same mail servers concurrently, or scenarios when victims switch\r\nbetween mail servers which are ultimately in the same pool. Essentially, there is a lot of overlap which appears\r\nmore than just coincidental, where batches of victim machines are used, presumably using the SOCKS element of\r\nBC, to access mail servers. When we look back into our data, we observe this pattern of activity occurring as far\r\nback as March 2023, and potentially even before.\r\nAdditionally, the bursts of activity coincide quite clearly with the previous line chart showing the volume of\r\nconnections between victims and BC C2s, specifically on:\r\n10, 19, and 30 May 2023\r\n13, 23, and 24 June (and an uptick at the end of the research window, 26/27 June) 2023\r\nhttps://www.team-cymru.com/post/inside-the-icedid-backconnect-protocol-part-2\r\nPage 9 of 12\n\nFigure 10: BC Victim Mail Server Traffic\r\nAre they related? Based on the comparison of the two charts, it seems likely. On the days where victims had a\r\nspike in BC C2 traffic, there was also a burst of activity from victims sending outbound connections to mail\r\nservers over TCP/587 (and sometimes TCP/465). It is unlikely that such a random group of victims would\r\ncoincidently have the same type of activity on the same days, repeatedly over months. It’s far more unlikely that it\r\nwould also coincidently align with victim/BC C2 activity.\r\nWhilst we have no definitive proof at this point in time, our current hypothesis, based on the findings described\r\nabove, is that BC is used (at least in part) to enable spamming operations associated with IcedID and their\r\naffiliates. Specifically, the SOCKS element of BC is used to proxy connections to mail servers via a subset of\r\nIcedID victims.\r\nConclusion\r\nIn this blog post we have outlined how IcedID BC infrastructure has expanded over the first half of 2023; with an\r\nincrease in C2 servers observed in total, and in parallel use at any point in time.\r\nWe have also discussed some of our techniques for tracking emergent C2 infrastructure, often on a timeline\r\nwhereby identification occurs before victim traffic is observed. Early identification is key to preventing future\r\ncompromise, threat actor-victim interaction and eventual data / financial loss.\r\nIn examining management infrastructure associated with IcedID BC, we are also able to discern a pattern of\r\nmultiple distinct accesses from users we assess to be both associated with the day to day operations of IcedID, and\r\ntheir affiliates who interact with victim hosts post-compromise.\r\nThrough victimology analysis we are also able to provide a hypothesized purpose for the BC protocol; we would\r\nassume one of several purposes. The evidence in our NetFlow data suggests that certain IcedID victims are used\r\nas proxies in spamming operations, enabled by BC’s SOCKS capabilities.\r\nThis is a potential double blow for victims, not only are they compromised and incurring data / financial loss, but\r\nthey are also further exploited for the purposes of spreading further IcedID campaigns.\r\nRecommendations\r\nUsers of Pure SignalTM Recon and Scout can follow this activity by pivoting from the BC C2 servers\r\nprovided in the IOCs section at the end of this blog post.\r\nhttps://www.team-cymru.com/post/inside-the-icedid-backconnect-protocol-part-2\r\nPage 10 of 12\n\nIn general we would recommend that the IOCs are used for cyber defense measures; both proactive\r\nblocking and reactive threat hunting. Threatfox is an excellent open-source resource for up to date IOCs\r\nrelating to IcedID and many other threat campaigns.\r\nIndicators of Compromise\r\nBC C2 Servers\r\n5.196.196.252\r\n135.148.217.85\r\n80.66.88.71\r\n45.61.137.220\r\n193.239.85.16\r\n185.99.132.16\r\n167.99.235.95 (Medium)\r\n162.33.179.145\r\n46.21.153.153\r\n193.149.176.100\r\n45.61.139.144\r\n45.61.137.159 (Medium)\r\n45.61.139.235 (Medium)\r\n193.149.176.198\r\n192.153.57.134\r\n193.149.187.7\r\n162.33.179.218\r\n139.59.33.128\r\n138.197.146.18\r\n167.99.248.131\r\n134.122.62.178\r\n104.248.223.35\r\nhttps://www.team-cymru.com/post/inside-the-icedid-backconnect-protocol-part-2\r\nPage 11 of 12\n\n64.227.48.93\r\n209.38.220.183\r\n161.35.166.97\r\n138.68.244.54\r\n68.183.198.18\r\n207.154.203.203\r\n64.227.146.71\r\n116.203.30.206 (Medium)\r\n139.59.186.140\r\n139.59.72.105\r\n104.248.21.165\r\n159.89.116.11\r\nSource: https://www.team-cymru.com/post/inside-the-icedid-backconnect-protocol-part-2\r\nhttps://www.team-cymru.com/post/inside-the-icedid-backconnect-protocol-part-2\r\nPage 12 of 12\n\nWe see that victim communicates victims can communicate with every with multiple new C2. In fact, BC C2s over there is no discernable time while they remain pattern around infected, how long but not every a victim\ncommunicates with a C2, when victims switch to a new C2, or which C2 servers a victim communicates with.\nHowever, when we pivot to analyzing the volume of traffic between victims and C2s, we finally see a pattern\nemerge.       \n   Page 8 of 12",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://www.team-cymru.com/post/inside-the-icedid-backconnect-protocol-part-2"
	],
	"report_names": [
		"inside-the-icedid-backconnect-protocol-part-2"
	],
	"threat_actors": [],
	"ts_created_at": 1775434670,
	"ts_updated_at": 1775826679,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/17e8327593c8004c6627c3dc95c6e49f687d911e.pdf",
		"text": "https://archive.orkl.eu/17e8327593c8004c6627c3dc95c6e49f687d911e.txt",
		"img": "https://archive.orkl.eu/17e8327593c8004c6627c3dc95c6e49f687d911e.jpg"
	}
}