Hackers Exploiting ICTBroadcast Cookie Flaw (CVE-2025-2611) to Gain Remote Shells — What defenders should know

15.10.2025 siteguarding2

A critical command-injection bug in ICTBroadcast (an autodialer / call-center platform) — tracked as CVE-2025-2611 (CVSS ~9.3) — is being actively exploited in the wild. Researchers observed attackers using specially crafted HTTP requests that abuse unsafe handling of a session cookie (the BROADCAST cookie) to execute shell commands on exposed servers. Intelligence firms report ~200 internet-facing ICTBroadcast instances appear exposed, with attackers following a two-stage pattern (time-based probe, then attempts to establish reverse shells). Defenders must treat any exposed ICTBroadcast host as high risk and apply containment and remediation steps immediately.

What the vulnerability is (short version)

The application evaluates or passes session cookie data into a shell context without sufficient sanitization, allowing unauthenticated command injection via the BROADCAST cookie. Versions 7.4 and below are known vulnerable.
Because this occurs before authentication, exploitability is high: attackers can trigger remote command execution (RCE) remotely simply by sending crafted HTTP requests.

Item	Detail / Value	Why it matters
Vulnerability	CVE-2025-2611 — command injection via `BROADCAST` cookie (unauthenticated)	Pre-authenticated remote command execution (RCE) on exposed ICTBroadcast instances — immediate high-severity risk.
CVSS / Severity	~9.3 (Critical)	High likelihood of full system compromise and rapid weaponization once PoC published.
Affected versions	ICTBroadcast ≤ 7.4 (public advisories flagged these)	Operators must treat listed versions as vulnerable until vendor patch or mitigation is applied.
Observed exploitation	Active campaigns observed starting Oct 11, 2025; ~200 internet-facing instances reported reachable	Active mass-scanning and follow-on shell drop attempts — high urgency for containment.
Typical attacker pattern	Two-stage: low-noise probe to confirm RCE → attempts to establish reverse shells/persistence	Probe→exploit behavior enables early detection if pattern is monitored.
Primary impact	Remote shell, webshell installation, credential theft, lateral movement, data exfiltration	Compromise of telephony/dialer infrastructure can disrupt operations and leak sensitive customer data.

Evidence of active exploitation & scale

VulnCheck observed in-the-wild exploitation beginning October 11, 2025, and added CVE-2025-2611 to its KEV catalogue after tracking weaponized activity. They reported roughly 200 exposed instances reachable on the internet. The attack pattern was two-phase: a time-based probe to confirm remote command execution, followed by attempts to drop reverse shells.
The Hacker News consolidated these findings in an article summarizing the same activity and noted overlaps between payload infrastructure and previously observed RAT distribution campaigns (Fortinet had earlier flagged similar infrastructure).
Public exploit modules (Metasploit) and PoC exploit code were published after the disclosure window, increasing the risk of automated mass-scanning and exploitation. Rapid7 documented the Metasploit module addition. This makes rapid containment even more urgent.

Why this is dangerous

Unauthenticated RCE on a public-facing service = immediate full compromise risk (web shells, persistence, lateral movement, data theft).
The vulnerability is trivially exploitable remotely and is being actively weaponized — that combination drives rapid attacker activity and automated bots.

Known indicators (high-value IOCs & overlap)

The public reporting cites use of a domain and IP tied to prior campaigns (e.g., localto[.]net referenced in payloads and an IP 143.47.53.106 seen in post-exploit connections). These overlaps were flagged in threat intel reporting. Use these as starting indicators, but treat IOC lists as evolving.

Note: IOCs change rapidly. Use vendor threat feeds and your own telemetry for up-to-date lists before acting on any single indicator.

Defensive actions (immediate / high priority)

Isolate exposed hosts now
- If ICTBroadcast is internet-facing, block traffic to the server at the firewall or network ACL level until it can be validated or patched.
- If blocking is not possible, restrict access to known management networks or VPNs.
Patch / update
- Apply any vendor patches or recommended mitigations from ICT Innovations if available. If a vendor patch is not yet available, remove the service from the internet or limit access. (Public advisories already list versions ≤7.4 as vulnerable.)
Hunt for compromise
- Check the server for suspicious processes, unexpected network connections, unusual cron jobs, new users, or web shells. Look for recently modified files under web roots.
- Search logs for requests with unusual or repeatedly-encoded cookie values, especially requests to /login.php or other auth endpoints. (Reports indicate attackers probe login pages and leverage the BROADCAST cookie to test for command execution.)
Containment checklist
- Capture memory and disk images for forensic analysis before rebooting if compromise is suspected.
- Snapshot VM and preserve logs (web server, application, system auth, firewall).
- Rotate any credentials that could have been exposed via the compromised system and revoke API keys/tokens used by the instance.
Network controls
- Block outbound connections to suspicious infrastructure (e.g., the IPs/domains reported in intel) at perimeter firewall and proxy.
- Apply egress filtering: deny unexpected outbound ports (nc/shell callbacks often use uncommon ports).
Detection
- Deploy network and host detection rules (see examples below). Monitor for:
  - HTTP requests with cookie header containing high-entropy/base64 payloads and backticks.
  - Rapid sequence of small-timing probes followed by long-running connections (typical of probe→payload pattern).
- Use your EDR to look for spawn of /bin/sh, mkfifo, nc, bash -i, or unexpected python/perl reverse shells.

Aspect	Details	Defender takeaway
Root cause	Unsafe server-side handling/evaluation of the `BROADCAST` cookie value that allows shell interpretation	Any code path that interpolates cookie content into shell commands is high risk — review and remove such patterns.
Exploitability	Unauthenticated command injection (remote attacker only needs to send specially-crafted HTTP requests)	Treat exposed instances as fully compromised until proven otherwise; immediate isolation recommended.
Common attack flow	HTTP probe -> check output/behavior -> deliver shell payload (reverse shell / webshell) -> persistence	Detect both reconnaissance phase (probe strings) and active phase (long-lived connections, suspicious processes).
Files/paths of interest	Web root and script handlers (application login endpoints such as `/login.php`), temporary directories, cron entries	Hunt for modified/added files, unexpected scripts, or new scheduled jobs after suspected probe times.
Processes to watch	Unexpected shells or network tools: `/bin/sh`, `bash -i`, `nc`, `python -c`	EDR rules should alert on these processes spawned by web-server user accounts (e.g., www-data, apache).
Why rapid spread likely	Public PoCs & Metasploit modules available; automated scanners will rapidly enumerate and attempt exploitation	Prioritize patch/containment — private exploit code accelerated mass exploitation risk.

Practical detection patterns (defender-oriented examples)

These are defensive patterns to help detect exploitation. Do not use them to craft attacks.

HTTP log search (example): look for requests where Cookie: BROADCAST= contains unusual characters/backticks or repeated base64 substrings; e.g., in web logs:

# pseudo-search: match BROADCAST cookie that contains backticks or base64-like patterns
grep -I "Cookie: .*BROADCAST=" /var/log/apache2/access.log | egrep -i '`|\|base64|-d'

EDR / process hunt (examples):

Processes launched as mkfifo/nc/bash -i/sh -i → immediate alert.
New inbound connections from unusual IPs shortly after suspicious HTTP requests.

IDS signature (conceptual Suricata rule)
(Implement and tune in your environment; treat as high-sensitivity and monitor false positives.)

# SURICATA pseudo-rule (illustrative only)
alert http any any -> $HOME_NET any (msg:"ICTBroadcast cookie suspicious BASE64 in BROADCAST cookie"; http_header; content:"Cookie"; content:"BROADCAST="; pcre:"/BROADCAST=.*(base64|`|mkfifo|nc|bash)/i"; sid:1000001; rev:1; classtype:attempted-admin; priority:1;)

Incident response playbook (short)

Triage: Identify impacted host(s) and isolate from network.
Collect: Save volatile evidence (memory), webserver/app logs, and full filesystem snapshot.
Analyze: Look for webshells, persistence, unusual user accounts, outbound callbacks, and suspicious crontabs.
Eradicate: Rebuild from known-good images after removing persistence and closing the vulnerability; do not simply patch in place if full compromise is suspected.
Recovery: Restore services behind hardened controls and monitoring; rotate secrets and credentials.
Post-incident: Report to stakeholders, update IOC lists, feed intel to peers and trusted CERTs.

Longer-term mitigations & development fixes

Sanitize all input (including cookies): never evaluate cookie content in a shell or pass raw cookie data into shell commands. Use parameterized execution APIs and appropriate escaping (avoid system()/backticks in PHP/Python that pass user data into shells).
Principle of least privilege: run web apps with reduced rights that cannot spawn privileged system utilities or write to persistent startup locations.
WAF + schema validation: enforce strict schemas on inputs and block anomalous cookie values; use behavioral rules to pick up probes.
Reduce internet exposure: services like ICTBroadcast typically do not need to be internet-facing. Place them behind VPNs or internal networks where possible.
Secure CI/CD: ensure secrets are not leaked and the appliance images are built from hardened baselines.

IOC / Pattern	Observed value (example)	Detection action / SIEM query example (defensive)
Malicious infrastructure (example)	domain: `localto[.]net` — IP: `143.47.53.106`	Block/monitor outbound traffic to these indicators; add to internal denylist and watch for DNS resolves/HTTP connections to these hosts.
Suspicious cookie values	`Cookie: BROADCAST=`	SIEM: search web logs for requests with `Cookie` header containing `BROADCAST=` and special characters/backticks/base64 patterns. Example Splunk-style: index=web sourcetype=access_combined "BROADCAST=" \| regex Cookie=".(base64\|`\|mkfifo\|nc\|bash)."
Probe → long connection pattern	Short HTTP probe followed by long-lived outbound TCP to uncommon ports	Alert when an HTTP request from the same client is followed (within X minutes) by long TCP egress from the host. Correlate web logs + netflow.
Process-based detections	Web server process spawning `/bin/sh` or `nc`	EDR: alert if child process of webserver account is shell / netcat / python with network sockets. Example (conceptual): alert on parent=/usr/sbin/apache2 AND process_name in (sh,bash,nc,python).
Honeypot / canary path hits	Requests to fake endpoints like `/.git/`, `/admin-old/`, or intentionally baited cookie values	Log and alert all accesses to canary endpoints; use them as early indicators of scanning/recon activity.
IDS rule (illustrative)	Suricata-style pseudorule watching BROADCAST cookie for suspicious tokens	Implement tuned IDS rule, e.g.: http_header; content:"BROADCAST="; pcre:"/BROADCAST=.*(base64\|`\|mkfifo\|nc\|bash)/i"; — tune to reduce false positives.

Sources & further reading

VulnCheck research & advisory on active exploitation (CVE-2025-2611).
NVD / CVE summary for CVE-2025-2611 (description of unsafe cookie handling; versions ≤7.4 vulnerable).
The Hacker News coverage summarizing the active exploitation and IOCs.
Rapid7: Metasploit module added for ICTBroadcast RCE (public module history).

Priority	Action	Implementation notes / verification
Immediate (now)	Isolate exposed ICTBroadcast hosts from internet	Block inbound at perimeter (firewall/NGFW) or add IP allowlist/VPN-only access. Verify with blocked external curl from an external host.
Immediate (now)	Apply vendor patch or remove service until patched	If no vendor patch yet, take service offline or replace with patched image. Log change and record downtime window.
High	Hunt for compromise indicators	Collect logs, check modified webroot files, crontabs, new users, scheduled tasks, and unusual outbound connections. If suspicious, capture memory before reboot.
High	Contain suspected compromises	Snapshot VMs, quarantines networks, rotate keys/credentials associated with the host, revoke tokens used by the instance.
High	Remove persistence & rebuild	Rebuild from known-good images after analysis; do not simply patch in-place if persistence is found. Validate integrity of restored host.
Medium	Block & monitor attacker infrastructure	Block known malicious IPs/domains (e.g., `143.47.53.106`, `localto[.]net`), add to SIEM watchlists, and share indicators with peers/CERT.
Medium	Improve detection & telemetry	Tune WAF/IDS/EDR rules, enable detailed webserver logging, enable outbound egress controls, instrument application-level telemetry for cookie anomalies.
Low (weeks)	Code remediation & secure development	Refactor server code to never pass unsanitized cookie values to shells; adopt safe APIs (no `system()` with user input); add static analysis to CI.
Low (policy)	Post-incident actions & governance	Rotate org credentials if exposure suspected; update incident report, communicate to stakeholders, update asset inventory to avoid future public exposure.

Final words

This is a high-risk vulnerability being actively exploited in the wild. If you run ICTBroadcast (or discover it on your network), assume compromise until proven otherwise: isolate, collect evidence, then remediate by patching or removing the service from internet exposure. Coordinate with your incident response and threat-intelligence teams, and share anonymized indicators with trusted community feeds so others can detect and block the same activity.