Inside the IcedID BackConnect Protocol (Part 2)

Team Cymru updates its analysis of IcedID’s BackConnect (BC) protocol: since January 2023 they identified 34 medium/high‑confidence BC C2 servers, a shift to shorter C2 lifetimes, and increased concurrent C2 usage. Analysis links management IP activity, specific ports (e.g., TCP/8082 SOCKS, TCP/8083 VNC, TCP/8101) and victim NetFlow spikes to likely spam operations using BC’s SOCKS capability. #IcedID #BackConnect

Keypoints

34 medium/high‑confidence IcedID BC C2 servers were identified since 23 January 2023 (up from 11 in late‑2022).
Average C2 uptime dropped from ~28 days to ~8 days, with up to four C2s active concurrently.
Management infrastructure includes two previously identified static VPN nodes plus additional private VPN nodes, jump boxes, and consumer ISP hosts.
Ports of interest: TCP/8082 (assessed as BC SOCKS proxy), TCP/8083 (VNC/screen sharing), TCP/8101 (unknown), and victim connections frequently on TCP/443.
Victimology shows infected hosts can talk to multiple BC C2s and exhibit synchronous spikes in C2 traffic tied to outbound SMTP (TCP/587 and TCP/465) to the same mail servers.
Observed patterns support the hypothesis that BC’s SOCKS functionality is being used to proxy spam delivery through subsets of IcedID victims.
Tracking methodology relies on pivoting from management IPs and NetFlow to identify emergent C2s before broad victim traffic appears.

MITRE Techniques

No MITRE ATT&CK technique identifiers are explicitly mentioned in the article – ‘management activity continues to be sourced from two static VPN nodes.’

Indicators of Compromise

[IP addresses] BC C2 servers – 5.196.196.252, 68.183.198.18, and 40+ other IPs listed in the IOCs section.
[Ports] Management / BC protocol ports observed – TCP/8082 (SOCKS), TCP/8083 (VNC), TCP/8101 (unknown), TCP/443 (victim C2 comms), TCP/587 and TCP/465 (outbound mail activity).
[ISPs / ASN context] Management access and peers – MOLDTELECOM‑AS (VNC management), Rostelecom consumer IPs (TCP/8083 activity), Ukrainian ISP and Starlink observed for SOCKS management access.

Tracking procedure: identify and monitor a set of static management IPs that repeatedly connect to multiple candidate C2 servers and specific BC ports. Use NetFlow and connection metadata (ephemeral ports, TCP three‑way handshake, TCP flags) to infer established management sessions and pivot from those management hosts to enumerate active BC C2s. Regularly update the C2 timeline as new management pivots appear; Team Cymru observed a protocol shift (victim connections moving from TCP/8080 to TCP/443) and an increase in short‑lived, concurrently active C2s.

Management infrastructure analysis: map ports to services (TCP/8082 → BC SOCKS proxy, TCP/8083 → VNC/screen sharing, TCP/8101 → unknown) and classify management access types: private VPN nodes (examples: German node showing Tor inbound peers and TCP/8101; Latvian node with OpenVPN/TCP/1194 and blockchain activity; Russian node with mail ports outbound), jump boxes (multi‑hop access via OpenVPN from Swiss/US hosts), and consumer ISP IPs (Rostelecom) acting as small gateway endpoints. Correlate observed inbound peers (Tor, Tox, OpenVPN) and outbound peers to understand how operators/affiliates access BC C2s.

Victimology and operational correlation: identify candidate victims by filtering TCP/443 traffic to BC C2s and select hosts that communicate with three or more C2s over time. Analyze volumetric patterns — synchronous spikes across geographically dispersed victims — and cross‑reference with outbound SMTP activity (TCP/587, TCP/465). Repeated coincidences of BC traffic spikes and bursts of connections to the same mail servers indicate that BC’s SOCKS capability is likely being used to proxy spam delivery through compromised hosts. Continuous pivoting from management IPs and NetFlow enables earlier C2 identification and supports proactive blocking and threat hunting.