DEV Community: Dolan

Why Wazuh Missed React2Shell

Dolan — Sun, 28 Dec 2025 08:36:59 +0000

Introduction

The security community was recently shaken by React2Shell, a critical unauthenticated Remote Code Execution (RCE) vulnerability. It was initially tracked under two CVEs:

CVE-2025-55182 – React
CVE-2025-66478 – Next.js

With a CVSS score of 10.0, this vulnerability impacts Next.js 15/16 (App Router) and any framework relying on React 19’s RSC implementation.

Wazuh published a great blog explaining how to detect this vulnerability:

👉 https://wazuh.com/blog/detecting-next-js-cve-2025-66478-rce-vulnerability-with-wazuh/

However, after doing deeper research, I found a critical limitation that applies not only to this CVE, but to most modern application stacks.

The Detection Gap: Why SIEMs Are Blind to Local Projects
Standard vulnerability detectors (including Wazuh’s default modules) excel at finding packages installed via system managers like apt or npm install -g. But modern development happens elsewhere:

Node.js: Most projects install dependencies locally in the project folder.
Python: Virtual environments (venv, uv) isolate packages from the system.
Docker: Packages are buried inside container layers (/var/lib/docker/...).

If your SIEM isn't looking at these local paths, you are flying blind.

So if a vulnerable version of Next.js or React exists inside a project directory, Wazuh will miss it.

I explained this problem earlier here:

👉 https://dev.to/0xdolan/why-you-shouldnt-rely-solely-on-detectors-373g

Wazuh provides several features that help, but none fully solve this problem.

IT Hygiene / Vulnerability Detection

👉 https://documentation.wazuh.com/current/getting-started/use-cases/it-hygiene.html#it-hygiene

👉 https://documentation.wazuh.com/current/user-manual/capabilities/vulnerability-detection/index.html

Detects globally installed packages only

Misses:

Local Node.js projects
Python venvs
Docker containers

File Integrity Monitoring (FIM)

👉 https://documentation.wazuh.com/current/user-manual/capabilities/file-integrity/index.html

Detects file changes

Does NOT extract:

Package names
Versions
Vulnerability status

Command Monitoring

👉 https://documentation.wazuh.com/current/user-manual/capabilities/command-monitoring/how-it-works.html

Can run scripts from the Wazuh manager
High risk
If manager is compromised → full agent compromise
Not recommended for frequent scans

So I needed a safer and more accurate approach.

The Solution: A Custom Inventory Workflow

We can’t rely on static scanners. Instead, we need a proactive script that:

Crawls the filesystem for package.json files.
Extracts version data for specific high-risk libraries (React/Next.js).
Logs these to a JSON file.
Feeds that file into Wazuh for real-time alerting.

Step 1: The Inventory Script

We use a Python script designed to be lightweight. Crucially, it does not exclude /var/lib/docker, allowing us to find vulnerable libraries inside container images.

Save as /usr/local/bin/scan_react2shell.py

#!/usr/bin/env python3

import json
import os
import sys
import time

# --- CONFIGURATION ---
LOG_FILE = "/var/log/react2shell_scan.json"
SEARCH_PATHS = ["/"]

# Excludes (Docker paths are NOT excluded so we can scan them)
EXCLUDE_DIRS = {"/proc", "/sys", "/dev", "/run", "/tmp", "/snap", "/boot"}


def scan_system():
    print(f"[*] Starting Inventory Scan on: {SEARCH_PATHS}")

    # Initialize Log File
    if not os.path.exists(LOG_FILE):
        try:
            with open(LOG_FILE, "w") as f:
                pass
            print(f"[*] Created new log file at {LOG_FILE}")
        except IOError as e:
            print(f"[!] Error creating log file: {e}")
            return

    count_inspected = 0

    for root_dir in SEARCH_PATHS:
        for dirpath, dirnames, filenames in os.walk(root_dir, followlinks=True):
            # Skip excluded directories
            if any(exclude in dirpath for exclude in EXCLUDE_DIRS):
                dirnames[:] = []
                continue

            if "package.json" in filenames:
                parent_dir = os.path.basename(dirpath)
                grandparent_dir = os.path.basename(os.path.dirname(dirpath))

                pkg_name = None

                if grandparent_dir == "node_modules":
                    if parent_dir == "react":
                        pkg_name = "react"
                    elif parent_dir == "next":
                        pkg_name = "next"

                if pkg_name:
                    full_path = os.path.join(dirpath, "package.json")
                    try:
                        with open(
                            full_path, "r", encoding="utf-8", errors="ignore"
                        ) as f:
                            data = json.load(f)
                            ver = data.get("version", "0.0.0")

                            print(f"[+] Found {pkg_name} v{ver} at {full_path}")
                            count_inspected += 1

                            # --- DOCKER TAGGING LOGIC ---
                            display_path = full_path
                            if (
                                "/var/lib/docker" in full_path
                                or "/var/lib/containerd" in full_path
                            ):
                                display_path = f"[DOCKER] {full_path}"

                            log_entry = {
                                "timestamp": time.strftime("%Y-%m-%dT%H:%M:%S"),
                                "scan_type": "react_inventory",
                                "package": pkg_name,
                                "version": ver,
                                "path": display_path,
                            }

                            with open(LOG_FILE, "a") as lf:
                                lf.write(json.dumps(log_entry) + "\n")

                    except Exception as e:
                        pass

    print(f"[*] Scan complete. Total Packages Logged: {count_inspected}")


if __name__ == "__main__":
    scan_system()

Note: This script scans for package.json and specifically flags packages like react and next while identifying if they are inside a Docker path.

Sample Output:

{"timestamp":"2025-12-11T13:15:07","scan_type":"react_inventory","package":"react","version":"19.2.1","path":"[DOCKER]/var/lib/docker/.../node_modules/react/package.json"}
{"timestamp":"2025-12-11T13:15:08","scan_type":"react_inventory","package":"next","version":"15.4.5","path":"/home/user/app/node_modules/next/package.json"}

Step 2: Wazuh Integration

Once the script generates /var/log/react2shell_scan.json, we need Wazuh to read it.

1. Configure the Agent:

Add this to the Wazuh agent or via centralized configuration (ossec.conf):

<localfile>
  <log_format>json</log_format>
  <location>/var/log/react2shell_scan.json</location>
</localfile>

Pushing the Configuration Centrally

To avoid manually editing the ossec.conf file on every server, we utilize Wazuh’s Centralized Configuration feature. By modifying the agent.conf file on the Manager, we can instruct all agents to start "watching" our custom inventory log.

On the Wazuh Manager:

Edit the shared configuration file for the default group:
vim /var/ossec/etc/shared/default/agent.conf

Add the following block inside the tags:

<agent_config>
  <!-- 
    This tells every agent to monitor the output of our inventory script.
    Wazuh will collect these JSON logs and send them to the manager for analysis.
  -->
  <localfile>
    <log_format>json</log_format>
    <location>/var/log/react2shell_scan.json</location>
  </localfile>
</agent_config>

How it works:

Synchronization: Once you save this file on the Manager, it automatically calculates a new MD5 checksum.
Propagation: The next time your agents check in (heartbeat), they will detect the configuration change, download the updated agent.conf file, and restart their log collector engine.
Visibility: From this point forward, any time your Python script (run via cron) updates /var/log/react2shell_scan.json, the data is instantly streamed to the Wazuh Manager to be checked against your custom React2Shell rules.

2. Create the Detection Rules:

In your Wazuh Manager (/var/ossec/etc/rules/local_rules.xml), add rules to flag specific vulnerable versions based on the Vercel and React security bulletins.

<group name="react_inventory,cve_2025_55182,cve_2025_66478,vulnerability,">
  <!-- INVENTORY: Log EVERY React/Next package found-->
  <rule id="100500" level="3"> 
    <decoded_as>json</decoded_as> 
    <field name="scan_type">react_inventory</field> 
    <description>Inventory: Found $(package) version $(version) at $(path).</description> 
  </rule>

<!-- Detect Vulnerable React.js -->
<rule id="100501" level="15">
  <if_sid>100500</if_sid>
  <field name="package">react</field>
  <field name="version" type="pcre2">
    ^19\.0\.0$|^19\.1\.[0-1]$|^19\.2\.0$
  </field>
  <info type="cve">CVE-2025-55182</info> 
  <info type="link">https://nvd.nist.gov/vuln/detail/CVE-2025-55182</info>
  <description>Vulnerable React2Shell detected: React $(version) at $(path)</description>
<mitre><id>T1190</id></mitre>
</rule>


  <!-- Detect Vulnerable Next.js -->
  <rule id="100502" level="15"> 
    <if_sid>100500</if_sid> 
    <field name="package">next</field>  
    <field name="version" type="pcre2">^15\.(0\.[0-4]|1\.[0-8]|2\.[0-5]|3\.[0-5]|4\.[0-7]|5\.[0-6])$|^16\.0\.[0-6]$</field>
  <info type="cve">CVE-2025-66478</info> 
  <info type="link">https://nvd.nist.gov/vuln/detail/CVE-2025-66478</info>
    <description>Vulnerable React2Shell detected: Next.js $(version) at $(path)</description> 
    <mitre><id>T1190</id></mitre> 
  </rule>
</group>

Step 3: Deployment via Ansible

How do you get this onto 100 servers? Don't use Wazuh's "Command Monitoring" for script execution. Giving a SIEM manager the right to run arbitrary scripts on all agents is a major security risk if the manager is compromised.

Instead, use Ansible. Create a playbook to:

Copy the Python script.
Set up a Cron job (e.g., daily at 2 AM).
Ensure the log file permissions are correct.

Notifications / Messenger Integration

To receive real-time alerts in your favorite messenger app, you can use these community integrations:

Slack: https://github.com/0xdolan/wazuh-slack-integration
Telegram: https://github.com/0xdolan/wazuh-telegram-integration
Microsoft Teams: https://github.com/0xdolan/wazuh-teams-integration

Conclusion

By shifting from "System Inventory" to "Application Inventory," we caught a CVSS 10.0 vulnerability that otherwise would have stayed hidden in a local node_modules folder.

Why You Shouldn’t Rely Solely on Detectors

Dolan — Mon, 08 Dec 2025 20:16:28 +0000

Recently, vulnerabilities like CVE-2025-55182 and CVE-2025-66478 have raised alarms for Next.js and React developers. If you're using Wazuh for vulnerability detection, there’s an important limitation you need to understand: project-local installs of npm packages might not be detected by default.

Why Wazuh Might Miss Vulnerable Packages

Wazuh’s vulnerability detection relies heavily on the Syscollector module, which scans installed software. Here’s the catch:

Global npm packages (npm install -g) are detected automatically. Standard paths include:

/usr/lib/node_modules
/usr/local/lib/node_modules

C:\Program Files\nodejs\node_modules
C:\Users\USER\AppData\Roaming\npm\node_modules

Local project installs (normal node_modules inside your project) are NOT scanned by default:

/var/www/project/node_modules
/home/user/app/node_modules
/app/node_modules

According to Wazuh documentation, support for scanning NPM and PyPI packages is limited to default installation paths. The developers have confirmed that scanning arbitrary project folders is not planned.

This means that if your Next.js or React project has a vulnerable package installed locally, Wazuh may miss it entirely unless you take extra steps.

What You Can Do

Even if Syscollector won’t detect project-local packages, you can leverage File Integrity Monitoring (FIM) and custom log collection to track changes and spot potential risks:

1. Monitor Your Project Folder with FIM

Add a custom path in /var/ossec/etc/ossec.conf to monitor your project directory:

<syscheck>
  <directories realtime="yes">/var/www/myapp</directories>
</syscheck>

This allows Wazuh to track:

File creations, deletions, and modifications
Changes in node_modules/ or config files
Suspicious additions or tampering

More details in the Wazuh FIM guide

2. Collect Logs from Build or Deployment

You can log your npm install and npm audit outputs and let Wazuh collect them:

<localfile>
  <location>/var/www/myapp/install_deps.log</location>
  <log_format>syslog</log_format>
</localfile>

<localfile>
  <location>/var/www/myapp/build.log</location>
  <log_format>syslog</log_format>
</localfile>

Run npm install > install_deps.log in your build pipeline
Optionally, run npm audit --json > audit.log and collect it

Then, create custom decoders and rules in Wazuh to alert you when known vulnerable packages are installed or modified.

Key Takeaways

Don’t rely solely on vulnerability detectors like Wazuh Syscollector for project-local npm installs.
Use FIM and log collection to monitor your codebase and dependencies.
Regularly run npm audit or third-party scanners like Snyk, etc. as part of your CI/CD pipeline.
Always combine automated detection with good monitoring practices for robust security coverage.

For more details on Wazuh CVE detection for Next.js, check out

By combining these approaches, you ensure that even project-local dependencies don’t slip under the radar, keeping your Next.js and React apps safer.

Posted with ❤️ by 0xdolan | GitHub

Watch Out for These Slash-Like Unicode Characters in Phishing Links

Dolan — Wed, 20 Aug 2025 16:25:11 +0000

Phishing attacks are getting sneakier, and sometimes all it takes is a single Unicode character to fool even a trained eye. One of the newest phishing techniques involves swapping the regular / (slash) with a similar-looking Unicode character.

Visually? Everything looks normal.

Under the hood? The link is not what you think.

Let’s take a look 👇

🔍 Phishing with Unicode: Slash Lookalikes

Attackers exploit Unicode to mimic legitimate URLs by swapping out the slash / with homoglyphs — characters that look the same but are actually different.

Character	Unicode	Description	Hover Link
/	U+002F	Solidus (Normal Slash)	https://booking.com
∖	U+2216	Set Minus (Backslash-like)	https://booking.com
⁄	U+2044	Fraction Slash	https://booking.com
∕	U+2215	Division Slash	https://booking.com
⧸	U+29F8	Big Solidus	https://booking.com
／	U+FF0F	Fullwidth Solidus	https://booking.com
︐	U+FE10	Presentation Form for Vertical Comma	https://booking.com
〳	U+3033	Vertical Kana Repeat Mark Upper	https://booking.com
㇓	U+31D3	CJK Stroke-like Character	https://booking.com
ん	U+3093	Hiragana Letter N (used in phishing)	https://booking.com
׃	U+05C3	Hebrew Punctuation Sof Pasuq	https://booking.com
܁	U+0701	Syriac Supralinear Full Stop	https://booking.com
᜵	U+1735	Philippine Single Punctuation	https://booking.com
፡	U+1361	Ethiopic Wordspace	https://booking.com
•	U+2022	Bullet	https://booking.com
＼	U+FF3C	Fullwidth Reverse Solidus (Backslash)	https://booking.com
᠆	U+1806	Mongolian Todo Soft Hyphen	https://booking.com
⁂	U+2042	Asterism	https://booking.com
⸻	U+2E3B	Two-Em Dash	https://booking.com
⹝	U+2E5D	Oblique Hyphen	https://booking.com
…	U+2026	Ellipsis	https://booking.com

🛡️ Why This Matters

Phishing pages crafted this way can:

Bypass visual inspection
Evade some automated filters
Trick users into trusting a malicious link

Hovering over links or inspecting the full URL is no longer enough unless you're looking for non-standard characters.

More on This

This phishing method has been spotted in the wild, including in a campaign targeting Booking.com customers:

📰 Read the full breakdown here:

👉 Booking.com phishing campaign uses sneaky character to trick you

🎬 Watch the analysis by John Hammond:

👉 YouTube: John Hammond Explains the Unicode Phishing Trick

Stay sharp and stay safe. Just because a link looks right, doesn’t mean it is.

💬 Have you seen similar techniques in the wild? Share below!

Wazuh 4.12 Slack Alert Integration

Dolan — Wed, 06 Aug 2025 05:43:04 +0000

Wazuh is a powerful open-source security platform for threat detection and response. This guide walks you through creating a custom integration script to send Wazuh alerts directly to Slack channels.

Note: Wazuh ships with a default slack.py script located at /var/ossec/integrations, but it’s generic and may not meet specific formatting or channel-routing needs. In this guide, we’ll build a tailored solution from scratch.

🛠️ Prerequisites

A Slack workspace with three channels and their webhooks:
- critical
- high
- medium
Wazuh 4.12 installed
Basic knowledge of Linux shell and Python

🔧 Create a Slack Workspace and Channels

Your Slack webhook URL will look like this:

https://hooks.slack.com/services/T00000000/B00000000/XXXXXXXXXXXXXXXXXXXXXXXX

Make sure your webhook URLs are structured like this:

📦 Step 1: Set up Python Virtual Environment in Wazuh

Create a Python virtual environment inside the Wazuh directory (/var/ossec) to avoid permission issues and package conflicts.

mkdir -p /var/ossec/venv
python3 -m venv /var/ossec/venv
source /var/ossec/venv/bin/activate
pip install requests  # or any needed packages

📁 Step 2: Create Slack Integration Script

Name the script with prefix custom-.

Location: /var/ossec/integrations/custom-slack.py

#!/var/ossec/venv/bin/python

import json
import re
import sys
from datetime import datetime

import requests

# Slack webhook URLs (Critical, High, Medium)
WEBHOOK_CRITICAL = ""  # replace with your Critical channel webhook
WEBHOOK_HIGH = ""  # replace with your High channel webhook
WEBHOOK_MEDIUM = ""  # replace with your Medium channel webhook

# Excluded Wazuh Rule IDs
excluded_rules: list = []  # Example: ["1002", "5715", "18107"]


def escape_markdown(text):
    """
    Escapes characters used by Slack markdown to avoid unintended formatting.
    Only *, _, `, and ~ are special in Slack and need escaping.
    """
    if not isinstance(text, str):
        text = str(text)
    # Escape only Slack formatting characters: *, _, `, and ~
    return re.sub(r"([*`_~])", r"\\\1", text)


def choose_webhook(level):
    try:
        lvl = int(level)
    except ValueError:
        return WEBHOOK_MEDIUM
    if lvl >= 11:
        return WEBHOOK_CRITICAL
    elif lvl >= 7:
        return WEBHOOK_HIGH
    else:
        return WEBHOOK_MEDIUM


def main():
    if len(sys.argv) < 2:
        print("[ERROR] No alert file path provided.")
        sys.exit(1)
    alert_file = sys.argv[1]
    try:
        with open(alert_file) as f:
            alert = json.load(f)
    except Exception as e:
        print(f"[ERROR] Failed to read or parse JSON: {e}")
        sys.exit(1)

    rule_id = alert.get("rule", {}).get("id")
    if rule_id in excluded_rules:
        print(f"[INFO] Skipping excluded rule ID: {rule_id}")
        sys.exit(0)

    data = alert.get("data", {})
    srcuser = data.get("srcuser") or data.get("dstuser") or "unknown"
    srcip = data.get("srcip", "unknown")
    srcport = data.get("srcport", "unknown")
    agent_name = alert.get("agent", {}).get("name", "unknown")
    alert_level = alert.get("rule", {}).get("level", "unknown")
    description = alert.get("rule", {}).get("description", "No description")
    full_log = alert.get("full_log", "No full log available")
    timestamp_raw = alert.get("timestamp", "unknown")

    try:
        dt = datetime.fromisoformat(timestamp_raw.replace("Z", "+00:00"))
        timestamp = dt.strftime("%Y-%m-%d %H:%M:%S")
    except ValueError:
        timestamp = timestamp_raw

    # Build Slack message with block formatting
    text = (
        "*:rotating_light: Wazuh Alert Notification*\n\n"
        f"*Time:* `{escape_markdown(timestamp)}`\n"
        f"*Username:* `{escape_markdown(srcuser)}`\n"
        f"*Source IP:* `{escape_markdown(srcip)}`\n"
        f"*Source Port:* `{escape_markdown(srcport)}`\n"
        f"*Agent:* `{escape_markdown(agent_name)}`\n\n"
        f"*Rule ID:* `{escape_markdown(rule_id)}`\n"
        f"*Level:* `{escape_markdown(alert_level)}`\n\n"
        f"*Description:*\n    {escape_markdown(description)}\n\n"
        f"*Full Log:*\n    {full_log}"
    )

    vuln = alert.get("vulnerability", {})
    cve_id = vuln.get("cve", "")
    cve_title = vuln.get("title", "")
    if cve_id:
        cve_url = f"https://cti.wazuh.com/vulnerabilities/cves/{cve_id}"
        text += (
            f"\n\n*🛡️ CVE:* `{escape_markdown(cve_id)}`\n"
            f"*Title:* {escape_markdown(cve_title)}\n"
            f"<{escape_markdown(cve_url)}|Details in CTI>"
        )

    text += "\n\n────────────────────────\n"

    webhook_url = choose_webhook(alert_level)
    payload = {"text": text}
    resp = requests.post(webhook_url, json=payload)
    if resp.status_code != 200:
        print(f"[ERROR] Slack response: {resp.status_code} – {resp.text}")


if __name__ == "__main__":
    main()

🔧 Step 3: Create Shell Wrapper Script

Wazuh calls shell scripts, so create a simple wrapper to call the Python script. It should have the same name of the python file without the .py extension.
Location: /var/ossec/integrations/custom-slack

#!/bin/sh

# Set the virtual environment Python binary
CUSTOM_PYTHON="/var/ossec/venv/bin/python3"

SCRIPT_PATH_NAME="$0"
DIR_NAME="$(cd "$(dirname "${SCRIPT_PATH_NAME}")"; pwd -P)"
SCRIPT_NAME="$(basename "${SCRIPT_PATH_NAME}")"
PYTHON_SCRIPT="${DIR_NAME}/${SCRIPT_NAME}.py"

# Run the integration script using custom Python interpreter
${CUSTOM_PYTHON} "${PYTHON_SCRIPT}" "$@"

Make both scripts executable and set proper ownership:

chmod 750 /var/ossec/integrations/custom-slack*
chown root:wazuh /var/ossec/integrations/custom-slack*

Step 4: Configure Integration in `ossec.conf`

Ensure that logall_json is enabled by setting it to yes in your ossec.conf file:

<ossec_config>
  <global>
    <jsonout_output>yes</jsonout_output>
    <alerts_log>yes</alerts_log>
    <logall>yes</logall>
    <logall_json>yes</logall_json>
  </global>
</ossec_config>

Add the integration block in /var/ossec/etc/ossec.conf:
The <name> tag value (custom-slack) must exactly match the name of your wrapper script.

<ossec_config>
    <integration>
    <name>custom-slack</name>
    <alert_format>json</alert_format>
    </integration>
</ossec_config>

Restart Wazuh to apply changes:

systemctl restart wazuh-manager.service

✅ Step 6: Test the Integration

Test manually with an alert JSON file:

/var/ossec/integrations/custom-slack /var/ossec/logs/alerts/alerts.json

Related Projects

Wazuh Telegram Integration – Send Wazuh alerts to Telegram using a similar method.

🚀 Result

You’ll begin receiving real-time Slack alerts for all critical, high, and medium-level events. Each alert is detailed, well-formatted, and clearly marked by severity, helping you respond faster and more effectively.

If you found this useful or have questions, feel free to comment. Happy monitoring! 👨‍💻📱

Created with ❤️ by 0xdolan | GitHub | View this guide on GitHub

Wazuh 4.12 Telegram Alert Integration (with SSH Login Alerts)

Dolan — Fri, 01 Aug 2025 06:47:53 +0000

Wazuh is a robust open-source security platform, but it doesn't include native support for Telegram alerts. This guide walks you through a simple method to send alerts, like SSH login attempts, to Telegram using a custom integration script.

🛠️ Prerequisites

A Telegram bot and your chat ID (official guide, or use the quick setup below)
Wazuh 4.12 installed
Basic Linux shell and Python knowledge

How to Create a Telegram Bot

Creating a Telegram bot is quick and easy with Telegram’s official BotFather:

Open Telegram and search for @botfather.
Start a conversation and send /start to begin.
Create your bot with the command /newbot.
Follow the instructions:
- Provide a display name for your bot.
- Choose a unique username that ends with bot (e.g., WazuhAlertBot).
BotFather will then return your bot token, which looks like this: 123456789:ABCdefGhIJKlmNoPQRstUVwxyz1234567890.
Keep this token safe, it's required to send messages from your bot.

You can now find your bot on Telegram using its username and send it a message to start.

How to Get Your Telegram Chat ID

To send alerts to Telegram, you'll need your chat ID. The script below fetches your chat ID by reading the latest message sent to your bot.

Steps

Replace the bot_token in the script with the token you got from BotFather.
Send any message to your bot via Telegram (e.g., "hello").
Run the script below using Python.
Your chat ID will be printed in the terminal.

Python Script to Retrieve Chat ID

import requests

bot_token = ""  # Replace with your bot token

def get_chat_id():
    url = f"https://api.telegram.org/bot{bot_token}/getUpdates"
    response = requests.get(url)
    if response.status_code == 200:
        data = response.json()
        if "result" in data and len(data["result"]) > 0:
            # Get chat ID from the last message
            chat_id = data["result"][-1]["message"]["chat"]["id"]
            print(f"Your Chat ID is: {chat_id}")
        else:
            print("No messages found. Please send a message to your bot first.")
    else:
        print(f"Failed to get updates: {response.status_code}")

if __name__ == "__main__":
    get_chat_id()

📦 Step 1: Set up Python Virtual Environment in Wazuh

Create a Python virtual environment inside the Wazuh directory (/var/ossec) to avoid permission issues and package conflicts.

mkdir -p /var/ossec/venv
python3 -m venv /var/ossec/venv
source /var/ossec/venv/bin/activate
pip install requests  # or any needed packages

📁 Step 2: Create Telegram Integration Script

Name the script with prefix custom-.

Location: /var/ossec/integrations/custom-telegram.py

#!/var/ossec/venv/bin/python

import json
import re
import sys
from datetime import datetime

import requests

# Telegram Bot credentials
bot_token = ""  # Replace with your Telegram bot token
chat_id = ""  # Replace with your Telegram chat ID

# === Excluded Wazuh Rule IDs ===
excluded_rules: list = []  # Example: ["1002", "5715", "18107"]


def escape_markdown_v2(text):
    if not isinstance(text, str):
        text = str(text)
    # Escape special MarkdownV2 characters
    escape_chars = r"_*[]()~`>#+-=|{}.!"
    return re.sub(r"([%s])" % re.escape(escape_chars), r"\\\1", text)


def main():
    if len(sys.argv) < 2:
        print("[ERROR] No alert file path provided.")
        sys.exit(1)

    alert_file = sys.argv[1]

    try:
        with open(alert_file, "r") as f:
            alert = json.load(f)
    except Exception as e:
        print(f"[ERROR] Failed to read or parse alert JSON file: {e}")
        sys.exit(1)

    rule_id = alert.get("rule", {}).get("id", None)

    if rule_id in excluded_rules:
        print(f"[INFO] Skipping excluded rule ID: {rule_id}")
        sys.exit(0)

    # Extract fields
    data = alert.get("data", {})
    srcuser = data.get("srcuser") or data.get("dstuser") or "unknown"
    srcport = data.get("srcport", "unknown")
    srcip = alert.get("data", {}).get("srcip", "unknown")
    agent_name = alert.get("agent", {}).get("name", "unknown")
    alert_level = alert.get("rule", {}).get("level", "unknown")
    rule_id = alert.get("rule", {}).get("id", "unknown")
    description = alert.get("rule", {}).get("description", "No description")
    full_log = alert.get("full_log", "No full log available")
    timestamp_raw = alert.get("timestamp", "unknown")

    # Convert timestamp to human readable format (date and time to seconds)
    try:
        # Try parsing ISO8601 format
        dt = datetime.fromisoformat(timestamp_raw.replace("Z", "+00:00"))
        timestamp = dt.strftime("%Y-%m-%d %H:%M:%S")
    except Exception:
        timestamp = timestamp_raw  # fallback if parsing fails

    # Build message
    message = (
        "*🚨 Wazuh Alert Notification*\n\n"
        f"🕒 *Time:* `{escape_markdown_v2(timestamp)}`\n"
        f"👤 *Username:* `{escape_markdown_v2(srcuser)}`\n"
        f"🌐 *Source IP:* `{escape_markdown_v2(srcip)}`\n"
        f"🚪 *Source Port:* `{escape_markdown_v2(srcport)}`\n"
        f"💻 *Agent:* {escape_markdown_v2(agent_name)}\n\n"
        f"🆔 *Rule ID:* `{escape_markdown_v2(rule_id)}`\n"
        f"🧱 *Level:* *{escape_markdown_v2(alert_level)}*\n\n"
        f"📄 *Description:*\n{escape_markdown_v2(description)}\n\n"
        f"🔍 *Full Log:*\n{escape_markdown_v2(full_log)}"
    )

    vuln = alert.get("vulnerability", {})
    cve_id = vuln.get("cve", "")
    cve_title = vuln.get("title", "")
    cve_url = f"https://cti.wazuh.com/vulnerabilities/cves/{cve_id}" if cve_id else ""

    if cve_id:
        message += (
            f"\n\n*🛡️ CVE:* `{escape_markdown_v2(cve_id)}`\n"
            f"*📄 Details:* {escape_markdown_v2(cve_title)}\n"
            f"[🔗 View in CTI]({escape_markdown_v2(cve_url)})"
        )

    # Send to Telegram
    url = f"https://api.telegram.org/bot{bot_token}/sendMessage"
    payload = {"chat_id": chat_id, "text": message, "parse_mode": "MarkdownV2"}

    response = requests.post(url, json=payload)
    if response.status_code != 200:
        print(f"[ERROR] Telegram response: {response.status_code} - {response.text}")


if __name__ == "__main__":
    main()

🔧 Step 3: Create Shell Wrapper Script

#!/bin/bash
/var/ossec/venv/bin/python3 /var/ossec/integrations/custom-telegram.py "$@"

Make both scripts executable and set proper ownership:

chmod 750 /var/ossec/integrations/custom-telegram*
chown root:wazuh /var/ossec/integrations/custom-telegram*

Step 4: Configure Integration in `ossec.conf`

Ensure that logall_json is enabled by setting it to yes in your ossec.conf file:

<ossec_config>
  <global>
    <jsonout_output>yes</jsonout_output>
    <alerts_log>yes</alerts_log>
    <logall>yes</logall>
    <logall_json>yes</logall_json>
  </global>
</ossec_config>

Add the integration block in /var/ossec/etc/ossec.conf:
The <name> tag value (custom-telegram) must exactly match the name of your wrapper script.

<ossec_config>
  <integration>
      <name>custom-telegram</name>
      <level>7</level>
      <alert_format>json</alert_format>
  </integration>
</ossec_config>

Setting level to 7 means only alerts with level 7 or higher trigger the Telegram alert.

🔒 Step 5: Elevate SSH Login Rule Level in Wazuh

By default, successful SSH login events (SID 5715) have a low alert level and do not trigger integrations. To resolve this, create or update the file /var/ossec/etc/rules/local_rules.xml with the following content:

<group name="local,syslog,sshd,">
  <rule id="100011" level="7" overwrite="yes">
    <if_sid>5715</if_sid>
    <description>sshd: Successful SSH login with elevated level.</description>
    <group>authentication_success,pci_dss_10.2.5,</group>
  </rule>
</group>

This configuration overrides the level of rule ID 5715 and raises it to level 7, ensuring it triggers and sends alerts to Telegram.

🔗 Rules Syntax — Wazuh rule definitions and structure

After making these changes, restart the Wazuh manager to apply them:

systemctl restart wazuh-manager

✅ Step 6: Test the Integration

Test manually with an alert JSON file:

/var/ossec/integrations/custom-telegram /var/ossec/logs/alerts/alerts.json

Or wait for a real SSH login alert to be sent to Telegram.

Related Projects

Wazuh Slack Integration – Send Wazuh alerts to Slack using a similar method.

🚀 Result

Receive real-time Telegram alerts for SSH logins and other critical events with detailed, nicely formatted messages, perfect for quick incident response.

If you found this useful or have questions, feel free to comment. Happy monitoring! 👨‍💻📱

Created with ❤️ by 0xdolan | GitHub | View this guide on GitHub

DEV Community: Dolan

Why Wazuh Missed React2Shell

Introduction

IT Hygiene / Vulnerability Detection

File Integrity Monitoring (FIM)

Command Monitoring

The Solution: A Custom Inventory Workflow

Step 1: The Inventory Script

Step 2: Wazuh Integration

1. Configure the Agent:

Pushing the Configuration Centrally

2. Create the Detection Rules:

Step 3: Deployment via Ansible

Notifications / Messenger Integration

Conclusion

Why You Shouldn’t Rely Solely on Detectors

Why Wazuh Might Miss Vulnerable Packages

What You Can Do

1. Monitor Your Project Folder with FIM

2. Collect Logs from Build or Deployment

Key Takeaways

Watch Out for These Slash-Like Unicode Characters in Phishing Links

🔍 Phishing with Unicode: Slash Lookalikes

🛡️ Why This Matters

More on This

Wazuh 4.12 Slack Alert Integration

🛠️ Prerequisites

🔧 Create a Slack Workspace and Channels

📦 Step 1: Set up Python Virtual Environment in Wazuh

📁 Step 2: Create Slack Integration Script

🔧 Step 3: Create Shell Wrapper Script

Step 4: Configure Integration in ossec.conf

✅ Step 6: Test the Integration

Related Projects

🚀 Result

Wazuh 4.12 Telegram Alert Integration (with SSH Login Alerts)

🛠️ Prerequisites

How to Create a Telegram Bot

How to Get Your Telegram Chat ID

Steps

Python Script to Retrieve Chat ID

📦 Step 1: Set up Python Virtual Environment in Wazuh

📁 Step 2: Create Telegram Integration Script

🔧 Step 3: Create Shell Wrapper Script

Step 4: Configure Integration in ossec.conf

🔒 Step 5: Elevate SSH Login Rule Level in Wazuh

✅ Step 6: Test the Integration

Related Projects

🚀 Result

Step 4: Configure Integration in `ossec.conf`

Step 4: Configure Integration in `ossec.conf`