Guilgo Blog

Notes from my daily work with technology.

Wazuh has released 4.9.1, which fixes the CVE-2025-24016 vulnerability (insecure deserialization in the Wazuh Server) that was later exploited by Mirai variants against exposed servers. Effective mitigation is to upgrade to 4.9.1 or later on manager, indexer and dashboard, then upgrade agents to maintain compatibility.

Executive summary

  • CVE-2025-24016 allows RCE on wazuh-manager (v ≥ 4.4.0 and < 4.9.1). Fixed in 4.9.1.
  • There was active exploitation by Mirai botnets in 2025 against servers with exposed API.
  • Wazuh stated that the bug requires API credentials; with panel or API exposed and weak keys, the risk is critical.

Sources: CVE/NVD, Release notes 4.9.1, Akamai/Censys advisories and official upgrade guide.

Timeline

  • 17‑Oct‑2024: 4.9.1 released with the fix.
  • Feb‑2025: Public disclosure of the CVE and PoC.
  • Mar‑Jun‑2025: Mirai campaigns automated the exploit against misconfigured Wazuh.

Affected versions

  • Server (manager): 4.4.0 → 4.9.0 vulnerable. Safe: 4.9.1+.
  • Agents: not affected by the CVE, but must be ≤ manager version for compatibility.
  • Indexer/Dashboard: upgrade together with the manager.

Urgent upgrade (manager, indexer, dashboard)

Run as root. Ensure you have backup and a maintenance window. Keep all three components on the same version.

Debian/Ubuntu (APT)

apt-get update
apt-get install --only-upgrade wazuh-manager wazuh-indexer wazuh-dashboard
systemctl restart wazuh-manager wazuh-indexer wazuh-dashboard

RHEL/Alma/Rocky (DNF/YUM)

dnf makecache || yum makecache
dnf upgrade -y wazuh-manager wazuh-indexer wazuh-dashboard || yum update -y wazuh-manager wazuh-indexer wazuh-dashboard
systemctl restart wazuh-manager wazuh-indexer wazuh-dashboard

Version check

/var/ossec/bin/wazuh-control status  # status
dpkg -l | egrep 'wazuh-(manager|indexer|dashboard)' || rpm -qa | egrep 'wazuh-(manager|indexer|dashboard)'

If you use Ansible/Puppet/Helm, set version: 4.9.1 (or current stable) in playbooks/charts and deploy.

Agent upgrade

Recommended: remote from the manager or via API for large fleets.

# List agents and known versions
/var/ossec/bin/agent_control -l

# Trigger remote upgrade (all that can be upgraded)
/var/ossec/bin/agent_upgrade -a

# Example selective by ID
/var/ossec/bin/agent_upgrade -A 012

Alternative: local upgrade with APT/DNF on each endpoint. On Windows, use the WPK package or the wizard from the Dashboard.

Post-patch validation

  1. Compatibility: manager==indexer==dashboard.
  2. Connected agents: no pending upgrade, no disconnected.
  3. Clean logs: no new errors in /var/ossec/logs/ossec.log or .../api/api.log.
  4. Exposure: port 55000/tcp (API) must not be publicly accessible.

Detection and monitoring

Ingest API log for correlation

Add to the manager’s ossec.conf to read api.log as JSON:

<ossec_config>
  <localfile>
    <log_format>json</log_format>
    <location>/var/ossec/logs/api/api.log</location>
    <tag>wazuh_api</tag>
  </localfile>
</ossec_config>

Reload:

/var/ossec/bin/wazuh-control restart

Local alert rules (exploit indicators)

Create/edit /var/ossec/etc/rules/local_rules.xml:

<group name="wazuh_api,attack,mirai,">
  <!-- Access to sensitive run_as endpoint -->
  <rule id="109010" level="10">
    <if_group>wazuh_api</if_group>
    <match>authenticate/run_as</match>
    <description>Wazuh API endpoint run_as invoked</description>
    <mitre>
      <id>T1190</id>
      <id>T1210</id>
    </mitre>
  </rule>

  <!-- Deserialized payload pattern -->
  <rule id="109011" level="12">
    <if_group>wazuh_api</if_group>
    <match>__unhandled_exc__</match>
    <description>Possible CVE-2025-24016 exploitation attempt (__unhandled_exc__)</description>
    <mitre>
      <id>T1190</id>
    </mitre>
  </rule>
</group>

Adjust levels/mitre to your policies. These rules do not exploit anything, they only detect patterns.

Quick Kibana/OpenSearch queries

index:wazuh-alerts-* AND (data.message:"authenticate/run_as" OR data.message:"__unhandled_exc__")

index:wazuh-alerts-* AND rule.groups:"wazuh_api" AND rule.id:10901*

Relevant IoCs (Mirai campaigns observed in 2025)

IoCs change frequently. Use them for temporary blocking and feed your threat‑intel with live lists. Public references included the following domains/IPs observed in exploitation attempts and C2:

IPs

176.65.134.62
104.168.101.27
209.141.34.106
65.222.202.53
196.251.86.49

Domains/Subdomains

nuklearcnc.duckdns.org
cbot.galaxias.cc
neon.galaxias.cc
pangacnc.com
jimmyudp-raw.xyz

Quick rules (example) to flag source/origin matching IoC by srcip or url (adapt to your event schema):

<group name="mirai,ioc,network,">
  <rule id="109020" level="12">
    <field name="srcip">176.65.134.62</field>
    <description>Mirai IoC: source IP 176.65.134.62</description>
  </rule>
  <rule id="109021" level="12">
    <regex field="url">nuklearcnc\.duckdns\.org|cbot\.galaxias\.cc|neon\.galaxias\.cc|pangacnc\.com|jimmyudp-raw\.xyz</regex>
    <description>Mirai IoC: observed C2 domain</description>
  </rule>
</group>

Hardening (essential after upgrading)

  • Close 55000/tcp to the outside; restrict API by firewall/VPN.
  • Rotate Dashboard/API credentials; disable default accounts.
  • TLS and strong password policies; MFA if you use SSO.
  • Least privilege: don’t share admin keys; use service accounts.
  • Ongoing monitoring of api.log and unusual Wazuh events.

5-step checklist

  1. Upgrade to 4.9.1 or later on manager/indexer/dashboard.
  2. Upgrade agents and verify connectivity.
  3. Ingest api.log and apply detection rules.
  4. Close/restrict the API; rotate credentials.
  5. Apply IoCs and review activity dashboards.

References

If you are already on 4.10.x–4.13.x branches, you are also protected against CVE-2025-24016. Keep a regular patch cycle.

avatar

Sysadmin, self-taught by curiosity.

FEATURED TAGS
linux microsoft powershell security sysadmin telegram wazuh wsus