Threat Summary
A single OTX pulse (TLP: WHITE) highlights a suspected SMTP botnet built from exposed Dixell/Copeland XWEB PRO refrigeration controllers—devices commonly deployed in supermarkets and cold storage facilities. The activity set comprises nine IPv4 addresses, with at least three confirmed as refrigeration controllers. The listed indicators include CVE-2026-25085 (explicitly called out in the pulse) plus two additional CVE identifiers (CVE-2026-109618, CVE-2026-109619) that are present as IOCs but not described in detail in the provided pulse text.
Collectively, the intelligence indicates an abuse-infrastructure model rather than a conventional endpoint malware campaign: internet-exposed ICS/IoT controllers are being leveraged as spam and proxy infrastructure, likely to provide distributed sending capacity, obscure operator origin, and reduce the effectiveness of IP-based blocking by rotating across compromised devices.
Likely objective: monetizable abuse enablement (spam distribution and/or proxying) using quietly compromised, highly available, and often unmaintained OT/IoT assets.
Key takeaway for defenders: this is less about “detecting malware on Windows endpoints” and more about asset exposure, protocol misuse, egress control, and controller integrity in retail/OT networks.
Threat Actor / Malware Profile
Threat actor: Unknown (no attribution in the pulse).
Malware families: Not specified in the pulse.
What can be inferred from the reported behavior
Because the pulse describes SMTP botnet / proxy abuse on internet-exposed controllers, the operational profile typically looks like:
- Distribution / compromise method: opportunistic scanning and exploitation of reachable controller management interfaces; may include vulnerable services, weak/default credentials, or exposed web consoles.
- Payload behavior: lightweight agent or abused built-in functionality enabling:
- outbound SMTP sessions to third-party mail servers (spam sending),
- inbound/outbound proxy relaying (TCP forwarding) to hide upstream operators,
- periodic check-ins to receive target lists, message templates, or relay instructions.
- C2 communication: often simple TCP-based command channels, HTTPS to a small set of servers, or DNS-based discovery; however, specific C2 details are not provided in the pulse.
- Persistence mechanism: controller-side persistence may involve configuration changes, added services, modified startup scripts/cron equivalents, or firmware-level tampering. The pulse does not specify the persistence mechanism, so defenders should treat persistence as “possible” until proven otherwise via device audit.
- Anti-analysis techniques: many IoT botnets rely on minimal logging, disabling local logging, and using common ports (25/465/587/80/443) to blend in; some implement delayed execution or only activate when traffic is received. Not explicitly stated in the pulse—treat as a risk pattern to hunt for.
IOC Analysis
The pulse contains the following indicator types:
- IPv4 addresses (primary): likely botnet nodes (compromised controllers and/or relay infrastructure). These are most actionable for:
- egress/ingress blocking,
- retro-hunting in network logs,
- identifying whether any internal host attempted SMTP or proxy-like communications to these IPs.
- CVE identifiers (secondary): used to guide exposure validation and patching/mitigation. CVEs are not “blockable” indicators; they are risk signals to drive remediation and compensating controls.
How SOC teams should operationalize these IOCs
- Network controls: block inbound/outbound to listed IPs where feasible (especially outbound SMTP).
- Detect abuse behavior: alert on unexpected outbound SMTP (25/465/587) from OT/IoT VLANs, HVAC/refrigeration subnets, or any device class that should never send email.
- Asset correlation: join IOC matches with asset inventory (device type, owner, location, business unit) to identify controller exposure quickly.
- Vulnerability management: verify whether any XWEB PRO controllers are internet-reachable and whether mitigations exist for the referenced CVEs (vendor guidance, firmware updates, ACLs, disabling remote access).
Tooling that helps decode/enrich the indicators
- Passive DNS / NetFlow / firewall logs: identify inbound scanning and outbound SMTP patterns.
- Shodan/Censys-style exposure checks (internal equivalents): validate internet exposure of controller interfaces (use carefully and legally).
- SMTP telemetry: look for anomalous HELO/EHLO strings, high connection rates, many destination MXs, or repeated failed authentications.
Detection Engineering
YAML
---
title: Outbound SMTP From OT/IoT or Refrigeration Controller Subnets
id: 2b6f9a1c-3a4b-4f3f-9c6f-0d3f6d0f7a01
status: experimental
description: Detects outbound SMTP connections (25/465/587) originating from OT/IoT/refrigeration controller network segments. Intended to surface botnet-driven spam/proxy abuse on devices that should not send email.
author: Security Arsenal
logsource:
category: network_connection
product: zeek
service: conn
detection:
selection_ports:
dst_port:
- 25
- 465
- 587
selection_ot_subnets:
src_ip|cidr:
- 10.0.0.0/8 # adjust to your OT/IoT ranges
- 172.16.0.0/12 # adjust to your OT/IoT ranges
- 192.168.0.0/16 # adjust to your OT/IoT ranges
filter_known_mail_relays:
src_ip|cidr:
- 10.10.10.0/24 # example: approved mail relay subnet (adjust)
condition: selection_ports and selection_ot_subnets and not filter_known_mail_relays
fields:
- ts
- src_ip
- src_port
- dst_ip
- dst_port
- proto
- service
- duration
- orig_bytes
- resp_bytes
falsepositives:
- Misclassified subnets where legitimate mail relays exist
- Rare IoT devices with built-in notification features (should be explicitly allow-listed)
level: high
tags:
- attack.command_and_control
- attack.exfiltration
- attack.t1071
- ics.iot
- smtp_abuse
references:
- https://securityscorecard.com/blog/a-dish-served-lukewarm-the-refrigerator-botnet/
date: 2026/11/09
---
title: Network Connections To Suspected Refrigerator Botnet IPs
id: 5d0c1d9d-3e2a-4d31-9d0c-8e2c9f2b6a02
status: experimental
description: Flags any network connection to IPv4 indicators associated with the suspected SMTP botnet described in the OTX pulse.
author: Security Arsenal
logsource:
category: network_connection
detection:
selection_iocs:
DestinationIp:
- 84.1.34.242
- 78.21.151.21
- 90.0.156.128
- 160.19.119.226
- 168.195.122.22
condition: selection_iocs
fields:
- TimeGenerated
- SourceIp
- DestinationIp
- DestinationPort
- Protocol
falsepositives:
- Unlikely unless the IPs are reused by legitimate services (validate with enrichment)
level: critical
tags:
- attack.command_and_control
- attack.t1071
- smtp_abuse
- ics.iot
date: 2026/11/09
---
title: Excessive SMTP Connection Attempts From a Single Internal Host (Botnet Behavior)
id: 0d0d9f6f-1e3b-4e41-9a2b-6f1a2d3c4b03
status: experimental
description: Detects high-rate outbound SMTP connection attempts from one internal host to many distinct destinations, consistent with spam sending infrastructure behavior.
author: Security Arsenal
logsource:
category: network_connection
detection:
selection_smtp:
DestinationPort:
- 25
- 465
- 587
condition: selection_smtp
timeframe: 10m
aggregation:
- field: SourceIp
aggregation: count
by:
- SourceIp
condition: gte
value: 50
fields:
- SourceIp
- count
falsepositives:
- Legitimate outbound mail gateways (exclude known SMTP relays)
- Monitoring systems performing health checks (tune thresholds)
level: medium
tags:
- attack.t1071
- spam
- smtp_abuse
- detection.threshold
date: 2026/11/09
KQL — Microsoft Sentinel / Defender
// Microsoft Sentinel hunt: Refrigerator botnet IOC IPs + suspicious outbound SMTP from unexpected devices
let BotnetIPs = dynamic(["84.1.34.242","78.21.151.21","90.0.156.128","160.19.119.226","168.195.122.22"]);
let SmtpPorts = dynamic([25,465,587]);
DeviceNetworkEvents
| where TimeGenerated >= ago(7d)
| where RemotePort in (SmtpPorts) or RemoteIP in (BotnetIPs)
| extend IocHit = iif(RemoteIP in (BotnetIPs), 1, 0)
| summarize Connections=count(), FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated),
DistinctRemoteIPs=dcount(RemoteIP), IocHits=sum(IocHit)
by DeviceName, DeviceId, LocalIP, InitiatingProcessFileName, InitiatingProcessCommandLine, RemotePort
| order by IocHits desc, Connections desc;
PowerShell
# Refrigerator Botnet IOC Hunt (Windows-centric visibility)
# Looks for: (1) established outbound TCP connections to known botnet IPs, (2) outbound SMTP sessions to 25/465/587,
# (3) suspicious local listeners commonly used for proxying, and (4) basic persistence surface review.
# Run elevated. Tune exclusions for known mail gateways.
$BotnetIPs = @("84.1.34.242","78.21.151.21","90.0.156.128","160.19.119.226","168.195.122.22")
$SmtpPorts = @(25,465,587)
Write-Host "=== [1] Established TCP connections to botnet IOC IPs ==="
Get-NetTCPConnection -State Established -ErrorAction SilentlyContinue |
Where-Object { $BotnetIPs -contains $_.RemoteAddress } |
Select-Object LocalAddress,LocalPort,RemoteAddress,RemotePort,State,OwningProcess,
@{n='ProcessName';e={(Get-Process -Id $_.OwningProcess -ErrorAction SilentlyContinue).ProcessName}} |
Format-Table -AutoSize
Write-Host "`n=== [2] Outbound SMTP connections (25/465/587) ==="
Get-NetTCPConnection -State Established -ErrorAction SilentlyContinue |
Where-Object { $SmtpPorts -contains $_.RemotePort } |
Select-Object LocalAddress,LocalPort,RemoteAddress,RemotePort,State,OwningProcess,
@{n='ProcessName';e={(Get-Process -Id $_.OwningProcess -ErrorAction SilentlyContinue).ProcessName}} |
Sort-Object RemoteAddress -Unique |
Format-Table -AutoSize
Write-Host "`n=== [3] Potential local proxy listeners (common proxy ports) ==="
$ProxyPorts = @(1080,3128,8080,8888,9050) # SOCKS/HTTP proxy/Tor common ports
Get-NetTCPConnection -State Listen -ErrorAction SilentlyContinue |
Where-Object { $ProxyPorts -contains $_.LocalPort } |
Select-Object LocalAddress,LocalPort,OwningProcess,
@{n='ProcessName';e={(Get-Process -Id $_.OwningProcess -ErrorAction SilentlyContinue).ProcessName}} |
Format-Table -AutoSize
Write-Host "`n=== [4] Persistence surface review (Run keys + recent scheduled tasks) ==="
$RunPaths = @(
"HKLM:\Software\Microsoft\Windows\CurrentVersion\Run",
"HKCU:\Software\Microsoft\Windows\CurrentVersion\Run"
)
foreach ($p in $RunPaths) {
if (Test-Path $p) {
Write-Host "-- $p"
Get-ItemProperty $p | Select-Object * | Format-List
}
}
Write-Host "`n-- Scheduled tasks (recently created/modified tasks may be worth review)"
Get-ScheduledTask -ErrorAction SilentlyContinue |
Where-Object { $_.TaskPath -notlike "\Microsoft*" } |
Select-Object TaskName, TaskPath, State, Author |
Sort-Object TaskPath, TaskName |
Format-Table -AutoSize
Write-Host "`n=== Notes ==="
Write-Host "If you find SMTP/proxy behavior from OT/IoT-adjacent systems, validate asset ownership and isolate pending vendor/controller review."
Response Priorities
Immediate (0–24h)
- Block/alert on the listed IPv4 indicators at the perimeter and internal egress points; investigate any matches.
- Enforce default-deny outbound SMTP: only approved mail gateways should initiate 25/465/587.
- Identify any XWEB PRO / refrigeration controller assets reachable from the internet; place behind VPN/allow-list or disable remote access.
- Isolate suspected compromised controllers from production OT segments; capture configs/logs if available.
24 hours
- If your environment shows spam relaying or proxy behavior, treat it as compromise until proven otherwise: rotate any credentials used on controller management interfaces (including integrator/service accounts) and review access logs.
- Validate whether the controllers have vendor-recommended mitigations for CVE-2026-25085 (and assess the other listed CVE IOCs as applicable to your firmware/version).
1 week (architecture hardening)
- Segment OT/IoT networks; restrict controller management interfaces to jump hosts and allow-listed sources.
- Implement egress filtering for OT VLANs (deny SMTP, restrict outbound to required vendor endpoints).
- Add monitoring for SMTP rate anomalies and “many-destination” patterns typical of spam infrastructure.
- Establish a lifecycle plan: firmware management, configuration baselines, logging, and periodic exposure checks.
Related Resources
Security Arsenal Incident Response Managed SOC & MDR Services AlertMonitor Threat Detection From The Dark Side Intel Hub
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.