OAuth Failure Monitoring Template for BIG-IP APM

If you're using F5 BIG-IP APM as an OAuth authorization server, you need a monitoring baseline before an exploit appears in your logs. The recent CVE-2026-94127 vulnerability, with a 9.8 CVSS score, showed that OAuth authentication failures can indicate reconnaissance or active exploitation when they cluster from a single source.

This template provides a monitoring script, alert thresholds, and investigation procedures you can implement today.

Purpose of This Template

This monitoring framework detects abnormal OAuth authentication failure patterns in BIG-IP APM deployments. It aims to:

• Flag repetitive authentication failures from the same IP address.
• Correlate OAuth failures with TMM crashes or core dumps.
• Generate actionable alerts for security teams.
• Provide an audit trail for post-incident forensics.

You'll use F5's native tmctl command to query OAuth statistics and correlate them with system logs. The template includes threshold baselines, but you'll need to adjust them to fit your environment's normal failure rate.

Prerequisites

Before deploying this monitoring template, ensure the following:

• Access Level: Root or tmsh access to your BIG-IP APM instance.
• Configuration Requirement: APM must be configured as an OAuth authorization server. Deployments using APM only as an OAuth client or resource server don't need this monitoring.
• Log Retention: Confirm /var/log/audit and /var/log/ltm retain at least 30 days of data.
• Alerting Infrastructure: SIEM integration or email relay configured for alert delivery.
• Baseline Period: Run the diagnostic script for 7 days to establish your normal OAuth failure rate before enabling alerts.

The Monitoring Script

Save this as /shared/scripts/oauth_monitor.sh on your BIG-IP APM system:

#!/bin/bash
# OAuth Authentication Failure Monitor for BIG-IP APM
# Detects potential CVE-2026-94127 exploitation patterns

THRESHOLD=10
ALERT_EMAIL="[email protected]"
LOG_FILE="/var/log/oauth_monitor.log"
TIMESTAMP=$(date '+%Y-%m-%d %H:%M:%S')

# Query OAuth statistics
OAUTH_STATS=$(tmctl global_oauth_stat -s total_requests,total_userinfo_requests,total_failed)
FAILED_COUNT=$(echo "$OAUTH_STATS" | grep total_failed | awk '{print $2}')

# Extract failures by source IP from audit log (last hour)
RECENT_FAILURES=$(grep -i "oauth.*authentication.*failed" /var/log/audit | \
  awk -v cutoff="$(date -d '1 hour ago' '+%b %d %H:%M')" '$0 > cutoff' | \
  awk '{print $NF}' | sort | uniq -c | sort -rn)

# Check for IPs exceeding threshold
SUSPICIOUS_IPS=$(echo "$RECENT_FAILURES" | awk -v thresh="$THRESHOLD" '$1 > thresh {print $2}')

if [ -n "$SUSPICIOUS_IPS" ]; then
  echo "[$TIMESTAMP] ALERT: OAuth failure threshold exceeded" >> "$LOG_FILE"
  echo "$RECENT_FAILURES" >> "$LOG_FILE"
  
  # Check for TMM core dumps in last 2 hours
  TMM_CORES=$(find /var/core -name "tmm_core*" -mmin -120)
  
  if [ -n "$TMM_CORES" ]; then
    echo "[$TIMESTAMP] WARNING: TMM core dumps detected alongside OAuth failures" >> "$LOG_FILE"
    echo "$TMM_CORES" >> "$LOG_FILE"
    
    # Send high-priority alert
    mail -s "CRITICAL: BIG-IP APM potential exploitation detected" "$ALERT_EMAIL" < "$LOG_FILE"
  else
    # Send standard alert
    mail -s "WARNING: BIG-IP APM OAuth failure spike" "$ALERT_EMAIL" < "$LOG_FILE"
  fi
fi

# Rotate log if over 10MB
LOG_SIZE=$(stat -f%z "$LOG_FILE" 2>/dev/null || stat -c%s "$LOG_FILE")
if [ "$LOG_SIZE" -gt 10485760 ]; then
  mv "$LOG_FILE" "${LOG_FILE}.$(date '+%Y%m%d')"
  gzip "${LOG_FILE}.$(date '+%Y%m%d')"
fi

Add to cron for hourly execution:

0 * * * * /shared/scripts/oauth_monitor.sh

Customizing the Script

Adjust the Failure Threshold: The default THRESHOLD=10 is based on F5's guidance that "more than 10 such messages in the logs" warrants investigation. If your environment sees legitimate OAuth failures during peak hours (like mobile app retries or expired tokens), consider raising this to 15 or 20 after analyzing your baseline.

Tune the Time Window: The script checks the last hour of audit logs. If you run it less frequently than hourly, adjust the date -d '1 hour ago' parameter to match your cron interval.

Refine IP Extraction: The awk '{print $NF}' assumes your audit log format places the source IP in the last field. Run grep -i "oauth.*authentication.*failed" /var/log/audit | head -5 and verify the field position, then adjust the awk column reference.

Integrate with Your SIEM: Replace the mail command with a syslog forward or API call to your SIEM:

logger -t oauth_monitor -p local0.warn "Suspicious OAuth failures from $SUSPICIOUS_IPS"

Add Geo-Blocking Logic: If your OAuth clients come from known regions, add a GeoIP lookup and flag authentication attempts from unexpected countries.

Validation Steps

1. Verify Baseline Collection: Run tmctl global_oauth_stat -s total_requests,total_userinfo_requests,total_failed manually and confirm you're getting numeric output for all three counters.

2. Test the Alert Path: Temporarily lower THRESHOLD=2 and trigger a few failed OAuth requests (invalid client_id or malformed token). Within one hour, you should receive an alert email.

3. Confirm Log Correlation: After triggering test failures, check /var/log/audit for corresponding entries. If they don't appear, verify your APM logging level is set to Informational or Debug.

4. Validate TMM Core Detection: Run ls -lh /var/core/tmm_core* to confirm the script can access core dump files. If you see permission errors, add the monitoring user to the appropriate group.

5. Check for False Positives: After 7 days of baseline monitoring, review /var/log/oauth_monitor.log for patterns. If you're getting daily alerts during legitimate traffic spikes, increase the threshold or narrow the source IP whitelist.

This monitoring template won't prevent exploitation of a zero-day vulnerability, but it gives you visibility into reconnaissance activity before an attacker escalates to remote code execution. Pair this with F5's recommended iRule mitigation and prioritize hotfix deployment for any BIG-IP APM instance exposed to the internet. According to Shadowserver Foundation tracking, more than 15,000 BIG-IP APM deployments are internet-facing. If yours is one of them, this monitoring script should be running before the next vulnerability disclosure.