Detect F5 BIG-IP Stack-Based Buffer Overflow Exploitation (CVE-2025-53521) in Sumo Logic CSE
Detects exploitation attempts and post-exploitation activity related to CVE-2025-53521, a stack-based buffer overflow vulnerability (CWE-121) in F5 BIG-IP. This vulnerability is listed in CISA's Known Exploited Vulnerabilities catalog and may allow remote attackers to execute arbitrary code or cause denial of service by sending crafted requests that overflow stack buffers in BIG-IP processing components.
MITRE ATT&CK
Sumo Detection Query
_sourceCategory=f5/bigip OR _sourceCategory=network/f5 OR _sourceName=*bigip*
| where _raw matches /(?i)(buffer overflow|stack overflow|stack smash|segmentation fault|segfault|tmm crash|mcpd crash|core dump|CVE-2025-53521|K000156741|K000160486)/
| parse regex "(?P<src_ip>\\d{1,3}\\.\\d{1,3}\\.\\d{1,3}\\.\\d{1,3})" as src_ip nodrop
| parse regex "severity=(?P<severity>\\w+)" as severity nodrop
| parse regex "(?P<process>tmm|mcpd|httpd|tmsh)" as process nodrop
| timeslice 5m
| count as event_count, values(src_ip) as source_ips, values(severity) as severities, values(process) as affected_processes by _timeslice, _sourceHost
| where event_count > 1
| sort by event_count descSumo Logic query across F5 BIG-IP source categories searching for buffer/stack overflow indicators and crash signals, aggregated in 5-minute windows to surface burst exploitation patterns.
Data Sources
Required Tables
False Positives & Tuning
- F5 advisory monitoring pipelines injecting CVE strings into log aggregation streams
- BIG-IP rolling restarts during maintenance windows generating crash-like log entries
- Penetration test engagements targeting BIG-IP in authorized lab environments
- High-volume legitimate traffic bursts causing transient memory pressure and related log messages
Other platforms for CVE-2025-53521
Testing Methodology
Validate this detection against 3 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.
- Test 1Oversized HTTP POST Payload to BIG-IP Virtual Server
Expected signal: Network flow logs showing source IP sending >65535 bytes to BIG-IP destination port. BIG-IP LTM logs showing oversized request from test source IP. Possible 400 Bad Request or connection reset depending on BIG-IP version.
- Test 2BIG-IP iControl REST Reconnaissance Prior to Exploitation
Expected signal: BIG-IP iControl REST access logs in `/var/log/restjavad.0.log` showing authenticated GET requests from test source IP. Network logs showing HTTPS connections to BIG-IP management IP on port 443.
- Test 3Simulate BIG-IP TMM Crash and Core Dump Generation
Expected signal: Syslog messages from BIG-IP host containing 'tmm' process restart events, critical severity entries, and potential core dump references in `/var/core/`. F5 SNMP traps if configured.
Response Playbook
Triage
- Identify the affected F5 BIG-IP device(s) by correlating source/destination IPs in alerts with your BIG-IP asset inventory. Confirm the device model and software version via TMSH: `tmsh show sys version`.
- Review BIG-IP system logs for crash indicators: check `/var/log/tmm`, `/var/log/ltm`, and `/var/log/mcpd` for segmentation faults, core dumps, or stack overflow messages occurring near the alert timestamp.
- Inspect inbound traffic logs for anomalous request sizes or malformed payloads targeting BIG-IP virtual server IPs around the time of the alert, focusing on ports 443, 80, 4353, and any custom virtual server ports.
- Check CISA KEV and F5 advisory K000156741 to confirm whether your BIG-IP version falls within the affected range and whether the patch has been applied.
Containment
- If active exploitation is confirmed or strongly suspected, immediately isolate the affected BIG-IP device from the network by placing it in maintenance mode or disabling affected virtual servers: `tmsh modify ltm virtual <vs-name> disabled`.
- Apply F5 iRule-based mitigations or BIG-IP ASM/WAF policies to block or rate-limit oversized payloads to affected virtual servers as an interim measure while patching is coordinated.
- Block identified attacker source IPs at upstream network controls (firewall, upstream router ACL) to prevent continued exploitation attempts.
Evidence Collection
- Capture core dump files from `/var/core/` on the affected BIG-IP for forensic analysis. Preserve timestamps and do not modify files in place.
- Export BIG-IP qkview (`qkview -f /var/tmp/incident-$(date +%Y%m%d).qkview`) for F5 TAC and internal forensics, which bundles logs, configuration, and system state.
Escalation Criteria
- !Escalate immediately to the security incident response team and F5 TAC if core dumps, shell access from unexpected processes, or lateral movement from the BIG-IP management IP are observed post-exploitation.
- !Escalate to executive leadership and legal/compliance if the BIG-IP device handles PCI, HIPAA, or other regulated traffic and active exploitation is confirmed, triggering breach notification assessment.
Investigation Guide
Related Techniques
Forensic Artifacts
- >
Core dump files at `/var/core/` on BIG-IP filesystems containing stack memory at time of crash - >
BIG-IP LTM and TMM logs at `/var/log/ltm` and `/var/log/tmm` containing crash timestamps and source IPs - >
iControl REST API access logs at `/var/log/restjavad.0.log` for any unauthorized management API calls following exploitation - >
Network packet captures from BIG-IP span port or upstream TAP showing the malformed request payload triggering the overflow
Tuning Guidance
Start by scoping alerts to confirmed BIG-IP asset IPs in your environment to reduce noise from unrelated F5 vendor log sources. Tune the payload size threshold (default 65535 bytes) based on your largest legitimate application transfer sizes — increase to 131072 for environments handling large file uploads. For crash signal detection, add specific process names (tmm, mcpd) to reduce false positives from application-layer logs. If your BIG-IP is already patched per F5 advisory K000156741, consider demoting severity to informational and keeping the rule active for detection of unpatched systems in shadow IT.
Hunting Queries
Hunt for BIG-IP devices generating clusters of critical severity events over the past 7 days, which may indicate repeated exploitation attempts or crash loops resulting from CVE-2025-53521 abuse.
CommonSecurityLog
| where TimeGenerated >= ago(7d)
| where DeviceVendor == "F5" or DeviceProduct has "BIG-IP"
| where LogSeverity in ("0", "1", "2") // Emergency, Alert, Critical
| summarize CrashCount=count(), FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated), SourceIPs=make_set(SourceIP) by DeviceName, bin(TimeGenerated, 1h)
| where CrashCount > 3
| order by CrashCount descindex=f5 sourcetype="f5:bigip:syslog" severity IN ("emerg", "alert", "crit") earliest=-7d
| bucket _time span=1h
| stats count as crash_count values(src_ip) as source_ips by host, _time
| where crash_count > 3
| sort - crash_countAtomic Red Team Tests
Sends an oversized HTTP POST request to a BIG-IP virtual server to simulate the payload size condition associated with stack buffer overflow exploitation. Use only against lab/test BIG-IP instances with explicit authorization.
Command
python3 -c "
import socket, random, string
host = '${TARGET_BIGIP_IP}'
port = 443
payload_size = 131072
payload = ''.join(random.choices(string.ascii_letters, k=payload_size))
request = f'POST /vulnerable-endpoint HTTP/1.1\\r\\nHost: {host}\\r\\nContent-Length: {payload_size}\\r\\nContent-Type: application/octet-stream\\r\\n\\r\\n{payload}'
try:
s = socket.create_connection((host, port), timeout=10)
s.send(request.encode())
resp = s.recv(4096)
print(resp.decode(errors='ignore'))
s.close()
except Exception as e:
print(f'Connection result: {e}')
"Cleanup
No cleanup required. Connection is closed after single request. Monitor BIG-IP `/var/log/ltm` for generated log entries and delete test-generated traffic logs if required by lab policy.Expected Telemetry
Network flow logs showing source IP sending >65535 bytes to BIG-IP destination port. BIG-IP LTM logs showing oversized request from test source IP. Possible 400 Bad Request or connection reset depending on BIG-IP version.
Expected Detection
KQL and SPL queries should fire on the oversized payload condition. If BIG-IP is vulnerable, a tmm crash may be visible in `/var/log/tmm` and a core dump generated in `/var/core/`.
Simulates attacker reconnaissance of the BIG-IP iControl REST API to enumerate version and virtual server configuration before targeting CVE-2025-53521. Lab use only.
Command
curl -sk -u 'admin:${BIGIP_ADMIN_PASS}' 'https://${TARGET_BIGIP_IP}/mgmt/tm/sys/version' | python3 -m json.tool && curl -sk -u 'admin:${BIGIP_ADMIN_PASS}' 'https://${TARGET_BIGIP_IP}/mgmt/tm/ltm/virtual' | python3 -m json.toolCleanup
Review `/var/log/restjavad.0.log` on BIG-IP to confirm test log entries. No configuration changes made; no cleanup required beyond log review.Expected Telemetry
BIG-IP iControl REST access logs in `/var/log/restjavad.0.log` showing authenticated GET requests from test source IP. Network logs showing HTTPS connections to BIG-IP management IP on port 443.
Expected Detection
Hunting queries monitoring iControl REST access from non-whitelisted IPs or outside business hours should surface this activity. SIEM alerts on BIG-IP management API access from new source IPs.
On a lab BIG-IP instance, manually triggers a non-destructive TMM restart to simulate crash telemetry that would be generated post-exploitation. Validates that crash log detection rules are working correctly.
Command
ssh -p 22 admin@${TARGET_BIGIP_IP} 'tmsh restart sys service tmm && sleep 5 && tail -50 /var/log/tmm | grep -E "(crash|segfault|core|restart|overflow)"'Cleanup
TMM will automatically restart. Verify BIG-IP is operational after test: `tmsh show sys service tmm`. Remove test SSH session logs from BIG-IP audit log if required: review `/var/log/audit`.Expected Telemetry
Syslog messages from BIG-IP host containing 'tmm' process restart events, critical severity entries, and potential core dump references in `/var/core/`. F5 SNMP traps if configured.
Expected Detection
SIEM crash signal detection rules (SPL, KQL) should alert on critical-severity syslog entries referencing tmm process events. Chronicle and QRadar rules should surface F5 vendor log entries with crash keywords.