MongoBleed Detector

Offline MongoDB Analysis Tool for CVE-2025-14847 (MongoBleed)

A standalone Linux command-line tool that analyzes MongoDB data to identify likely exploitation of CVE-2025-14847 using multiple detection modules.

Table of Contents

• Overview
• Detection Modules
• Requirements
• Installation
• Two Modes of Operation
• Mode 1: Local Analysis
• Mode 2: Remote Collection
• Command-Line Options
• Confidence Levels
• Example Output
• Testing
• Caveats & Limitations
• References & Credits
• License

Overview

MongoBleed (CVE-2025-14847) is a memory disclosure vulnerability in MongoDB's zlib decompression that allows attackers to extract sensitive data—credentials, session tokens, PII—directly from server memory without authentication.

This tool helps incident responders detect exploitation attempts using multiple evidence sources:

• Module A: Log correlation (connection events, metadata absence)
• Module B1: Assert counts analysis (serverStatus.asserts snapshots)
• Module B2: FTDC spike detection (diagnostic.data time series)

Key Features

• Multi-Module Detection - Correlates multiple data sources for higher confidence
• Offline & Agentless - No network connectivity required during analysis
• Auto-Discovery - Automatically detects available data sources
• Remote Collection - Collects data from multiple hosts via SSH
• Combined Scoring - HIGH/MEDIUM/LOW confidence verdicts
• Streaming Processing - Handles large log files efficiently

Detection Modules

Module A: Log Correlation

Analyzes MongoDB JSON logs to detect exploitation patterns:

Event ID	Type	Description
22943	Connection Accepted	Logged when a client connects
51800	Client Metadata	Logged when a client sends driver/application info
22944	Connection Closed	Logged when a client disconnects

Key insight: Legitimate MongoDB drivers always send client metadata. The MongoBleed exploit connects, extracts memory, and disconnects—but never sends metadata.

Module B1: Assert Counts

Analyzes snapshots of db.serverStatus().asserts to detect unusual patterns in asserts.user counters:

• Multiple Snapshots: Compares snapshots over time to detect sudden spikes in user assertions
• Single Snapshot Heuristic: When only one snapshot is available, detects suspicious patterns by comparing asserts.user to other assertion types. If user asserts are disproportionately high (ratio ≥250x) or all other types are zero, flags as suspicious (MEDIUM confidence)

Note: Cumulative counters can produce false positives. Use in combination with FTDC (Module B2) for best results.

Module B2: FTDC Spike Detection

Analyzes MongoDB's Full-Time Diagnostic Data Capture (FTDC) files to detect time-localized spikes in assertion counters. FTDC samples serverStatus periodically, enabling precise timing of potential attacks.

Requirements

Shell Script (mongobleed-detector.sh)

• Linux or macOS (bash 4+)
• jq - JSON processor
• awk (gawk recommended)
• gzip - For compressed log support

Python Components (optional, for FTDC decoding)

• Python 3.8+
• pymongo - For FTDC file decoding

Remote Scanner (mongobleed-remote.py)

• Python 3.8+
• Native SSH client (ssh, scp commands)
• No additional Python packages required for basic operation

Install Dependencies

# Shell script dependencies
# Debian/Ubuntu
apt-get install jq gawk gzip

# RHEL/CentOS/Fedora
dnf install jq gawk gzip

# macOS
brew install jq gawk

# Python dependencies (for FTDC decoding)
pip install -r requirements.txt

Installation

# Clone the repository
git clone https://github.com/your-org/mongobleed-detector.git
cd mongobleed-detector

# Make scripts executable
chmod +x mongobleed-detector.sh
chmod +x mongobleed-remote.py
chmod +x ftdc-decode.py

# Install Python dependencies (optional, for FTDC support)
pip install -r requirements.txt

Two Modes of Operation

Mode 1: Local Analysis

Analyze data that has been manually collected from MongoDB hosts.

Mode 2: Remote Collection

Automatically collect data from multiple hosts via SSH, then analyze locally.

Mode 1: Local Analysis

Step 1: Collect Data

Collect data from your MongoDB hosts and organize it into this structure:

./collected-data/
├── logs/                    # MongoDB JSON logs
│   ├── mongod.log
│   ├── mongod.log.1
│   └── mongod.log.2.gz
├── assert-counts/           # serverStatus().asserts snapshots
│   ├── asserts-2025-01-01.json
│   └── asserts-2025-01-02.json
└── ftdc-files/              # FTDC diagnostic.data contents
    ├── metrics.2025-01-02T10-00-00Z-00000
    └── metrics.interim

Collecting Logs

# Copy from remote host
scp user@mongohost:/var/log/mongodb/mongod.log* ./collected-data/logs/

Collecting Assert Counts

Run this command on the MongoDB host (requires mongosh access):

mongosh --quiet --eval 'JSON.stringify({
  timestamp: new Date().toISOString(),
  hostname: db.hostInfo().system.hostname,
  asserts: db.serverStatus().asserts,
  uptime: db.serverStatus().uptime
})' > asserts-$(date +%Y%m%d-%H%M%S).json

Copy the resulting JSON file to ./collected-data/assert-counts/.

Tip: Run this command multiple times (e.g., hourly) to establish a baseline and detect spikes.

Collecting FTDC Files

FTDC files are located at:

• mongod: <storage.dbPath>/diagnostic.data/ (commonly /var/lib/mongodb/diagnostic.data/)
• mongos: Derived from systemLog.path (e.g., /var/log/mongodb/mongos.diagnostic.data/)

# Copy FTDC files (may require sudo)
sudo cp /var/lib/mongodb/diagnostic.data/metrics.* ./collected-data/ftdc-files/

Step 2: Run Analysis

# Auto-discovery mode - analyzes all available data
./mongobleed-detector.sh --data-dir ./collected-data/

# With custom thresholds
./mongobleed-detector.sh --data-dir ./collected-data/ \
    -t 1440 \              # 24-hour lookback
    -c 50 \                # Lower connection threshold
    --spike-threshold 50   # Lower spike threshold

Legacy Mode (Logs Only)

For backward compatibility, you can still analyze logs directly:

# Scan default paths
./mongobleed-detector.sh

# Scan specific log files
./mongobleed-detector.sh -p /path/to/logs/*.json

# Forensic mode (analyze multiple hosts)
./mongobleed-detector.sh --forensic-dir /evidence/

Mode 2: Remote Collection

Automatically collect data from multiple hosts and analyze:

# Create hosts file
cat > hosts.txt << EOF
mongo-prod-01.example.com
mongo-prod-02.example.com
mongo-staging.example.com
EOF

# Collect and analyze
./mongobleed-remote.py --hosts-file hosts.txt --user admin --output-dir ./collected-data/

Remote Scanner Options

# Use specific SSH key
./mongobleed-remote.py --hosts-file hosts.txt --user admin --key ~/.ssh/mongodb_key

# Parallel execution
./mongobleed-remote.py --hosts-file hosts.txt --user admin --parallel 10

# Skip FTDC collection (faster)
./mongobleed-remote.py --hosts-file hosts.txt --user admin --skip-ftdc

# Collect only, analyze later
./mongobleed-remote.py --hosts-file hosts.txt --user admin --collect-only

# Pass SSH options (e.g., jump host)
./mongobleed-remote.py --hosts-file hosts.txt --user admin \
    -o "ProxyJump=bastion.example.com"

# Use sudo for privileged file access (FTDC files are often restricted)
./mongobleed-remote.py --hosts-file hosts.txt --user admin --sudo

# Debug mode to troubleshoot connection issues
./mongobleed-remote.py --hosts-file hosts.txt --user admin --debug