{
	"id": "6a691157-ccaf-438e-afaf-24cb21c6a2b2",
	"created_at": "2026-04-06T00:09:20.516117Z",
	"updated_at": "2026-04-10T13:12:47.220474Z",
	"deleted_at": null,
	"sha1_hash": "f664a2328547d13ae33f1b0f88425d1d5772d1d5",
	"title": "Inside the IcedID BackConnect Protocol",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1226641,
	"plain_text": "Inside the IcedID BackConnect Protocol\r\nBy Team Cymru\r\nPublished: 2025-04-08 · Archived: 2026-04-05 17:56:00 UTC\r\nDeriving Threat Actor TTPs from Management Infrastructure Tracking\r\nYou can find our previous work on Stage 1 and Stage 2 of IcedID’s initial infection chain in our Dragons\r\nNews Blog. Data on Stage 1 C2 infrastructure is now also shared as part of our Botnet Analysis and\r\nReporting Service (BARS).\r\nAs part of our ongoing tracking of IcedID / BokBot, we wanted to share some insights derived from infrastructure\r\nassociated with IcedID’s BackConnect (BC) protocol. When deployed post “initial” compromise, the BC protocol\r\nallows the threat actor(s) additional functionality, using the infected host as a proxy.\r\nAmongst other things, the BC protocol contains a VNC module, providing the malware operator(s) with a remote-access channel which can be brokered for profit.\r\nFor a comprehensive description of the BC protocol, we recommend this blog by Netresec. Furthermore, we must\r\ncredit @malware_traffic having drawn upon his collection of threat actor telemetry data to confirm some of the\r\nobservations shared in this post.\r\nKey Findings\r\nEleven BC C2s identified since 01 July 2022, managed via two VPN nodes.\r\nOperators likely located in Moldova and Ukraine managing distinct elements of the BC protocol.\r\nEvidence of malicious use of the SpaceX Starlink network identified.\r\nExposure of several tools and processes utilized by the operators, including temporary SMS messaging, file\r\nsharing, cryptocurrency wallets, and a favorite local radio station.\r\nStarting Point - 51.89.201.236\r\nThe starting point for our analysis is derived from the two sources mentioned above; although not a new\r\nphenomenon, reporting on the BC protocol is fairly scarce, with the last major point of reference, prior to the most\r\nrecent coverage, being made in May 2020.\r\nIn early October 2022, an IOC (51.89.201.236:8080) derived from an IcedID infection was identified by\r\n@malware_traffic. The IOC was later attributed as a C2 server for the BC protocol by Netresec, noting a change\r\nin the auth value (0x08088b1f) used by the bot and C2 server for verification purposes.\r\nhttps://www.team-cymru.com/post/inside-the-icedid-backconnect-protocol\r\nPage 1 of 11\n\nFigure 1: https://twitter.com/netresec/status/1577966512459087874\r\nWith an active C2 server for the BC protocol identified, our first step was to examine our network telemetry data\r\nsurrounding this IP address, looking for indications of management access, common peers, and subsequent similar\r\npatterns of activity, e.g., evidence of victim communications over TCP/8080.\r\nhttps://www.team-cymru.com/post/inside-the-icedid-backconnect-protocol\r\nPage 2 of 11\n\nFigure 2: Initial Data Pivots\r\nOver time, by repeating this process it was possible to identify two long standing management IP addresses, which\r\nwere observed in communication with 11 distinct BC C2 servers (including 51.89.201.236) since 01 July 2022.\r\nhttps://www.team-cymru.com/post/inside-the-icedid-backconnect-protocol\r\nPage 3 of 11\n\nFigure 3: C2 Server Timeline (Based on Management Traffic)\r\nBased on the data behind Figure 3, we can state that the average life cycle for a BC C2 server, based on first and\r\nlast observations of management traffic, is approximately four weeks and that there are generally one or two\r\nservers active at any given time.\r\nAdditionally, in all cases communications between the C2 and management servers commenced and ceased on a\r\nMonday to Friday schedule - indicating a degree of “professionalism” to the operation and a point which became a\r\ntrend during this analysis.\r\nAuth Value Changes\r\nReturning to the aforementioned auth value (0x08088b1f), based on our investigations, the campaigns involving\r\n51.89.201.236 are the first time the “new” auth value was observed. However, this finding is caveated with the\r\nfact that relevant PCAP data was not available for the two preceding C2 IPs - 135.125.242.223 and\r\n198.244.187.242.\r\nAll prior C2s used the “previous” auth value (0x974f014a), which was associated with IcedID dating back a\r\nnumber of years. The change in auth value therefore likely happened at some point between 30 August and 22\r\nSeptember 2022.\r\nhttps://www.team-cymru.com/post/inside-the-icedid-backconnect-protocol\r\nPage 4 of 11\n\nFigure 4: Auth Value for 135.181.175.108 (Last Active 30 August 2022)\r\nManagement Insights\r\nThe remainder of this blog will focus on the two management IP addresses which have been associated with the\r\noperation of the BC protocol for at least half a year.\r\nThese IPs consistently connect to the BC C2 servers on the same two (separate) static ports, one which hosts a\r\nVNC service and the second which we hypothesize is associated with the SOCKS proxy module.\r\nhttps://www.team-cymru.com/post/inside-the-icedid-backconnect-protocol\r\nPage 5 of 11\n\nFigure 5: BackConnect Management\r\nSetting the BC protocol management communications to one side, examining the rest of the data available for\r\nthese two IP addresses provides an insight into the threat actor(s) operation, with some hints at attribution.\r\nVNC Management\r\nThe first observation with the VNC Management is that it appears to be a VPN node. When examining inbound\r\nconnections, a large proportion take place on UDP/1194, a port commonly associated with OpenVPN as the\r\nservice’s default port.\r\nThe VNC Management IP is therefore most likely used for routing traffic / providing anonymisation to the\r\noperator(s) and may not host any digital artifacts.\r\nOn the other side of the OpenVPN connections are numerous Moldovan IPs, the vast majority of which are\r\nassigned to a large residential broadband provider. In the 30-day period prior to the time of writing this report, 31\r\ndistinct Moldovan IPs were observed connecting to the VNC Management IP. Interestingly, the communications\r\ndo not overlap, pointing towards a single user / access point.\r\nOur hypothesis in this case is that the operator(s) of VNC Management IP are employing some operational\r\nsecurity measures whilst operating from / via a residential access point. The data available points to an end\r\nuser frequently rebooting their router in order to refresh their public IP address.\r\nTurning to outbound connections, a number of observations can be made, indicating potential operator TTPs.\r\nFirstly, regular traffic to TeamViewer infrastructure was observed, indicating that the software may be installed on\r\nthe operator’s machine, with usage routed through TeamViewer’s servers. Like VNC, TeamViewer has been used\r\npreviously by threat actors for remote access management purposes, for example, it is leveraged to gain access to\r\nnetworks and establish persistence in ransomware operations.\r\nSecondly, communications with a single Tor relay were observed over an extended period. This particular finding\r\nmay be indicative of a single operator accessing the Tor network via the VNC Management IP.\r\nBy default, the Tor browser utilizes a small pool of Guard relays, which is refreshed approximately every 60\r\ndays. Ongoing communications with a single Tor relay is therefore indicative of an end user accessing Tor\r\nvia the Tor browser.\r\nAs each instance of the Tor browser has its own set of Guard relays, multiple users accessing the Tor\r\nnetwork via the same VPN access point would result in the observation of connections to multiple Tor\r\nrelays.\r\nhttps://www.team-cymru.com/post/inside-the-icedid-backconnect-protocol\r\nPage 6 of 11\n\nFigure 6: Communications with Tor Relay\r\nBy examining the timeline of activity involving communications with this particular Tor relay, we can see that it\r\nwas likely associated with the operator until 3 December 2022, when the Guard pool likely reset. Since this date\r\nwe have not observed any further connections to Tor relays; likely as a result of a coverage gap.\r\nThe majority of the Tor activity fits to a Monday to Friday schedule, although there were some days where access\r\ntook place over the weekend. Most notably on 5 and 6 November 2022, following a spike in activity on 3\r\nNovember 2022.\r\nThis activity coincided with a resurgence of Emotet activity, which included a new version of IcedID being\r\ndropped alongside it. The spike is therefore a possible indicator of collusion between the operators of\r\nEmotet and IcedID.\r\nAside from Tor, connections were also observed to IPs assigned to Telegram, indicating likely use of Telegram\r\nmessenger. This finding is not particularly exciting (Telegram is used widely), but serves to highlight the overall\r\nTTPs of the VNC Management IP operators.\r\nMore interestingly, traffic to onlinesim[.]ru caught our attention. This website appears to provide temporary\r\n‘virtual’ numbers to be used for sending / receiving SMS messages.\r\nBy virtue of the fact that this domain was accessed via the same infrastructure as is used to manage the BC\r\nC2s, it can be inferred that these temporary numbers serve a purpose in the overall process; although the\r\nexact use-case is currently unknown.\r\nAnother indicator for operator attribution came in the form of connections to an API for a local radio station based\r\nin Chelyabinsk, Central Russia.\r\nWe have two hypotheses for this activity, a) the API is embedded in another website and is pulling data\r\nfrom the radio station in Chelyabinsk, or b) the operator has some ties to that particular region of Russia;\r\nan expat living in Moldova?\r\nhttps://www.team-cymru.com/post/inside-the-icedid-backconnect-protocol\r\nPage 7 of 11\n\nFinally, we observed RDP connections to a set of IPs that share a distinct machine name, however it is unclear\r\nwhat the purpose of these connections are beyond the obvious use of the RDP protocol.\r\nFigure 7: Summary of Activity - VNC Management IP\r\nSOCKS Management\r\nIntriguingly, although the SOCKS Management IP serves a similar purpose to the VNC Management IP, there are\r\nvariations in both how this is accomplished and by whom.\r\nLike the VNC Management IP, the SOCKS Management IP appears to be a VPN node, masking the true location\r\nof the operator(s), used to funnel not only BC protocol-related communications, but also other (mostly) connected\r\nactivities.\r\nInbound traffic to the SOCKS Management IP is observed over UDP/51820, the default port for the open-source\r\nWireGuard VPN service.\r\nNoting the similar use of an (albeit different) open-source, and likely private, VPN service.\r\nOn the other end of these communications are a handful of IPs assigned to providers in Ukraine. Most\r\nsignificantly, several of these IPs are attributable to ‘SpaceX Starlink’ infrastructure provided to Ukraine to help\r\nmaintain Internet connectivity since the commencement of Russia’s “special operation” / illegal invasion in\r\nFebruary 2022.\r\nhttps://www.team-cymru.com/post/inside-the-icedid-backconnect-protocol\r\nPage 8 of 11\n\nIt is possible that this is the first example of the Starlink infrastructure being used by cyber criminals.\r\nBeyond the Ukrainian IPs, in this case it is difficult to attribute the management activity more specifically; as the\r\ninfrastructure is likely utilized by tens, or even hundreds of users at any given time.\r\nFigure 8: Inbound and Outbound Activity - SOCKS Management IP\r\nLooking at outbound connections from the SOCKS Management IP, there is similar use of Tor and Telegram.\r\nAlthough, in the case of Tor, this may be more indicative of some form of automated or hidden service-related\r\nactivity as communications with numerous Tor relays were observed.\r\nThis is in comparison with the VNC Management IP which appeared to only communicate with the one Tor\r\nrelay; matching more closely the ‘expected’ behavior of an individual using the Tor browser.\r\nAdditionally, a large volume of connections, both inbound and outbound, over TCP and UDP/33445 were\r\nobserved, generally associated with Tox messenger.\r\nTox has been utilized by cyber criminals in the past, including for C2 purposes. The default port for Tox is\r\nUDP/33445, however mobile connections default to TCP - it is therefore possible that the operator(s) of the\r\nSOCKS Management IP are using it to access Tox on both desktop and mobile.\r\nIn much the same way as the BC C2s have a life cycle of around four weeks, the SOCKS Management IP also\r\ncommunicates with cloud infrastructure (accessed via SSH) with the cloud peer IP changing over time. However,\r\nit was noted that all of the cloud IPs displayed the same unique SSH Server Host Key, indicating a likely\r\nconsistent setup.\r\nFinally, looking at outbound web-browsing activity (TCP/80 and TCP/443), the SOCKS Management IP is used to\r\naccess IP addresses associated with Gofile (file sharing), ProtonMail, Trezor (cryptocurrency wallet), and a not\r\ninsignificant number of pornographic sites (someone in IcedID senior management needs to crack down on\r\nadherence to the Acceptable Use Policy!).\r\nhttps://www.team-cymru.com/post/inside-the-icedid-backconnect-protocol\r\nPage 9 of 11\n\nFigure 9: Summary of Activity - SOCKS Management IP\r\nConclusion\r\nThis blog serves two purposes, the first is to highlight our tracking of BC C2 infrastructure, sharing details of C2\r\nservers and the process we undertake behind the scenes in order to identify them.\r\nWe will continue to share details of new / emerging BC C2 servers via our Twitter account\r\n@teamcymru_S2.\r\nThe second is to provide a snapshot into a ‘day in the life of’ the BC operators, and in doing so, providing wider\r\ncontext on threat actor TTPs.\r\nIn the case of BC, there appears to be two operators managing the overall process within distinct roles. Much of\r\nthe activity we observe and have described in this blog occurs during the typical working week (Monday to\r\nFriday).\r\nBoth of these points indicate a degree of ‘professionalism’ in the operation of the BC protocol, and by\r\nextension IcedID itself.\r\nEvidence of a ‘dispersed’ workforce undertaking specific tasks may also help to explain some of the variations in\r\nthe TTPs observed. Whilst seemingly using two distinct VPN services, we can see an overall ‘playbook’ in use,\r\ni.e., its best practice to use a VPN for purposes of anonymization. The fact that both services are configured with\r\nhttps://www.team-cymru.com/post/inside-the-icedid-backconnect-protocol\r\nPage 10 of 11\n\ndefault settings indicate either laziness, attempts to ‘hide within the noise’, or a lack of understanding /\r\nappreciation of the tooling in use.\r\nWe were surprised that beyond the use of a VPN node, very few steps appear to have been taken to cover the\r\noperators’ tracks; we think this speaks to a confidence in ‘invincibility’, by operating from regions where law\r\nenforcement action is difficult to effect / prioritize.\r\nThe use of services like ProtonMail, TeamViewer and Telegram is commonly observed within threat actor\r\noperator playbooks, and these mainstream tools continue to be used by maliciously motivated individuals.\r\nServices like Gofile and onlinesim[.]ru may point to more ‘operator-specific’ TTPs, whilst also highlighting a\r\ngeneral use of file sharing and temporary SMS platforms.\r\nFinally, by highlighting a number of areas where we still have question marks in our understanding, we\r\nhope that we can encourage future collaboration on the BC protocol.\r\nWe hope that this blog post has been informative and has served to provide confidence in the IOCs which we have\r\npreviously shared on this subject matter.\r\nIOCs\r\nBackConnect C2 Servers\r\n135.125.242.223\r\n135.181.175.108\r\n137.74.104.108\r\n176.31.136.226\r\n185.156.172.97\r\n188.40.246.37\r\n198.244.187.242\r\n198.251.84.61\r\n212.114.52.91\r\n51.195.169.87\r\n51.89.201.236\r\nSource: https://www.team-cymru.com/post/inside-the-icedid-backconnect-protocol\r\nhttps://www.team-cymru.com/post/inside-the-icedid-backconnect-protocol\r\nPage 11 of 11\n\nFigure 2: Initial Over time, by repeating Data Pivots this process it was possible to identify two long standing management  IP addresses, which\nwere observed in communication with 11 distinct BC C2 servers (including 51.89.201.236) since 01 July 2022.\n   Page 3 of 11",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://www.team-cymru.com/post/inside-the-icedid-backconnect-protocol"
	],
	"report_names": [
		"inside-the-icedid-backconnect-protocol"
	],
	"threat_actors": [],
	"ts_created_at": 1775434160,
	"ts_updated_at": 1775826767,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/f664a2328547d13ae33f1b0f88425d1d5772d1d5.pdf",
		"text": "https://archive.orkl.eu/f664a2328547d13ae33f1b0f88425d1d5772d1d5.txt",
		"img": "https://archive.orkl.eu/f664a2328547d13ae33f1b0f88425d1d5772d1d5.jpg"
	}
}