📊 Logfile (window) analysis
The analysis of log files (windows) is the systematic collection, correlation and evaluation of event records to detect attacks in a timely manner, support incident investigation and meet compliance requirements. The Roadmap covers the whole process from log sources and formats to centralised analysis of SIEs and signs of attack based on recognised standards (NIST SP 800-92, ISO 2701, OWASP). Examples are illustrative and targeted for training.
What is window analysis
Log management life cycle - NIST SP 800-92
The logfile (log) is a chronological record of events in the system - who, when, where and what he did. Window analysis is the process of collecting, normalising and evaluating these records to detect security incidents, support investigations and comply with compliance requirements. NIST SP 800-92 is described as a continuous life cycle from event generation to controlled disposal.
Basic principle: analyze centrally and outside the host to be tested - in a compromised system windows can no longer be trusted. The findings of the analysis reversibly specify what and how to log.
Danger Detection
Windows are the main source of early detection of attacks - failed login, change of privileges, abnormal network traffic.
Investigation
During an incident, windows reconstruct event chronology (timeline) - what the attacker did when and how far was.
Eligibility
ISO 27001, PCI DSS, NIS2 and GDPR require login, storage and regular review as mandatory control.
Liability
Continuing audit records provide a non-repudiation - which entity performed whose activities.
Activity Report
Errors and performance windows help to determine the norm (baseline) and to detect its deviations.
What log
Authentication, refusal of access, changes in configuration and rights, administrative actions and errors.
Disable Sensitive
Passwords, tokens, full card numbers and unnecessary personal data are not recorded in the windows (GDPR data minimisation) - masks or skips.
Noise signal
More windows are not better - without normalisation and selection analysts drown in noise. Defines what really needs to be monitored.
Unitary time
For all sources, synchronized time (NTP) and UTC. Without this, events from different systems cannot be correctly grouped (ISO 27001 A.8.17).
Where windows are created and how they look
Classification of sources and common formats
Windows come from many layers - operating systems, network equipment, applications and cloud. To compare and correlate them, different formats are normalised into a single scheme. Structured formats (JSON) are machine readable and greatly facilitate automatic analysis compared to free text lines.
Operating system
Linux: syslog, journald, /var/log/auth.log, auditd. Windows: Security / System / Application Event Log (EVTX), Sysmon. macOS: Unified Logging (log show), OpenBSM auditd.
Network
Firewall, IDS/IPS (Suricata, Zeek), proxy, VPN, DNS requests, NetFlow / flow window.
Applications
Web server (access / error window), database, application business events - preferably structured (JSON).
Cloud and Identity
AWS CloudTrail, Azure Activity, GCP Audit Window, VPC flow window. IdP (Entra ID, Octa) login events.
| Format | Type | Where to occur | Remarks |
|---|---|---|---|
| Syslog (RFC 5424) | partly structured | Linux/Unix, network equipment | Standard protocol for transmission. Contains facility, security, timestamp, host. |
| JSON | structured | modern applications, cloud | Machine readable (key-value). Simple parsing and searching. Recommended format. |
| Windows EVTX | structured (binary) | Windows Event Log | Events with Event ID. Reading with wevtutil / Get-WinEvent or SIEM agent. |
| CEF / LEEF | structured | security equipment, SIEM | Independent formats of producers for the transmission of events to SIEM. |
| W3C / Combined | partly structured | nginx, Apache, EES | Web server access log. Fields in a fixed order, parse with grock. |
One event, three formats (examples)
# 1) syslog (RFC 5424) - daļēji strukturēts <38>1 2026-06-03T14:22:01.003Z srv-01 sshd 2913 - - Failed password for root from 203.0.113.7 port 51022 ssh2 # 2) nginx combined - tīmekļa access log 203.0.113.7 - - [03/Jun/2026:14:22:01 +0000] "POST /admin/login HTTP/1.1" 401 564 "-" "curl/8.2" # 3) JSON - strukturēts (mašīnlasāms, ieteicams) { "ts": "2026-06-03T14:22:01Z", "host": "srv-01", "event": "auth.failure", "user": "root", "src_ip": "203.0.113.7", "service": "sshd", "outcome": "failure" }
Normalisation
Fields from different sources are converted into a single schematic (e.g. ECS - Elastic Common Schema) so that different windows can be searched and correlated together.
Parse
Free text rows shall be divided into fields with samples (gron, regex). Structured JSON windows prevent this step to a large extent.
Enrichment
The events are complemented by the context: GeoIP after IP, the role of an asset, the reputation of threat intel - this speeds up decision making.
From source to SIEM
Centralised collection, storage and integrity
The window should not be analysed only on the installation where they originated: if the system is compromised, the attacker can delete or change them. Therefore, windows are delivered as soon as possible outside the host to a central (append-only) storage, where they are parse, indexed and analysed.
Integrity: windows are delivered out of the host quickly, stored append-only/WORM and checked by the mixing (hash). Storage period according to the laws and regulations - NIS2 at least 12 months, PCI DSS year. Time synchronized (NTP, UTC), otherwise events from different sources cannot be correctly correlated.
Centralisation
All windows in one place allow to correlate events between systems and protect evidence if source equipment is compromised.
Integrity
Append-only/WORM storage and mixing amounts (hash) prevent unseen editing - essential for legal value.
Retention
The time limit for storage shall be set by law and by the need for investigation. By maturity - controlled destruction, not natural deletion.
Safe transmission
The windows are sent via an encrypted channel (syslog over TLS, RFC 5425) with buffering so that a short-term network failure does not lose them.
How Data Gets Discovery
Analytical techniques and Pyramid of Pain
The window analysis combines a rule-based (signature) discovery with a behavioural (anomaly) analysis. David Bianco's 'Pyramid of Pain' model arranges the indicators according to how difficult it is to attack them: the higher the pyramid is based on discovery, the more durable it is.
Pyramid of Pain: on the right - how easy the attacker to replace the indicator. Discovery by behavior (TTP, above) is much more persistent than after a single IP or mixer sum (down), which the attacker replaces easily.
Signature / Regulations
Examples of known attacks as search rules (e.g. Sigma, correlation). Exactly, but only notice known.
Detection of abnormalities
First, the norm (baseline) is determined, then the deviation - unusual time, volume, geography, rare actions.
Conduct analysis
User & Entry Behavior Analytics - creates a behavioural profile of each user and system and signals its violations.
Correlation
Link events from different sources into one scene - e.g. application failed + success + change of privileges.
Threshold / aggregation
Counts events in the window - e.g. N failed login per minute from one IP = brute force alarm.
Chromology (timeline)
The events are arranged in order of time axis (super-timeline) for the reconstruction of an incident - e.g. with Plaso / Timesketch.
Sigma
Manufacturer independent disclosure rules format (YAML). One rule is converted into different SIEM queries (SPL, KQL, EQL).
MITRE ATT&CK
An attacker's tactics and technical knowledge base. Window discoveries are drawn to specific techniques to evaluate coverage.
False alarms
Rules must be regulated (tuning) - too widely creates false positive and fatigue effects, too narrowly miss attacks.
Enrichment
Threat intelligence, GeoIP and active contexts increase the accuracy of discoveries and accelerate prioritisation.
What to look for in windows
Typical signs of attacks and key events
Most attacks leave traces in log files. The following shows how to recognise the most frequent stages of attack in the operating systems - Windows (Event ID), Linux (auth.log) and macOS (Unified Logging) - and network telemetry (tcpdump, tshark, Zeek), linking them to attack phases after MITRE ATT&CK.
A separate event may be normal - a sign of it sequence and time compressionwhat the correlation reveals. Audit log clearance (1102) is anti-forensics signal.
| Event ID | Source | Meaning | What to notice |
|---|---|---|---|
| 4624 | Security | Successful application | Logon Type: 2 interactive, 3 network, 10 RDP |
| 4625 | Security | No login failed | Much in a row from one IP = brute force. Many accounts = password spray |
| 4648 | Security | Application with direct accreditation data | sign of speech, lateral movement |
| 4672 | Security | Special privileges granted | Administrative session - link to 4624 |
| 4688 | Security | A new process has been created | Command line arguments (if enabled). Suspected parental-child processes |
| 4720 / 4732 | Security | Account created / added to group | Escalation of privileges, persistence |
| 4768 / 4769 | Security | Kerberos TGT / TGS | Signs of Kerberoasting, Golden / Silver ticket |
| 7045 | System | New Service Installed | stability; unusual service name or path |
| 1102 | Security | Audit log cleared | Anti-forensics - almost always suspicious |
| Sysmon 1/3/11 | Sysmon | Process / Network / File | Detailed telemetry. Essential for EDR-style detection |
One feature in three operating systems - search for the source of failed applications
─── LINUX · /var/log/auth.log (vai: journalctl -u ssh) ─── Jun 3 14:22:01 srv-01 sshd[2913]: Failed password for root from 203.0.113.7 port 51022 ssh2 Jun 3 14:23:11 srv-01 sshd[2960]: Accepted password for deploy from 203.0.113.7 port 51190 ssh2 # ← veiksme + sudo seko $ grep "Failed password" auth.log | awk '{print $(NF-3)}' | sort | uniq -c | sort -rn ─── WINDOWS · Security Event Log (PowerShell) ─── PS> Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625} -MaxEvents 200 | Group-Object { $_.Properties[19].Value } | Sort-Object Count -Descending # avota IP pēc 4625 ─── macOS · Unified Logging (log show) ─── $ log show --last 1h --predicate 'process == "sshd" AND eventMessage CONTAINS "Failed"' 2026-06-03 14:22:01.003+0000 sshd: Failed password for root from 203.0.113.7 port 51022 ssh2 $ log show --predicate 'process == "sudo"' --last 30m # sudo / privilēģiju eskalācija
Network telemetry - C2 communication and data export characteristics (tcpdump · tshark · Zeek)
─── tcpdump · pakešu līmenis - savienojumi ar aizdomīgo IP ─── $ tcpdump -ni eth0 'host 203.0.113.7 and tcp port 22' 14:22:01.003 IP 203.0.113.7.51022 > 10.0.0.5.22: Flags [S], seq 0, length 0 14:22:01.004 IP 10.0.0.5.22 > 203.0.113.7.51022: Flags [R.], # atteikts ─── tshark · DNS pieprasījumi - tunelēšanas / exfil pazīme (gari, reti domēni) ─── $ tshark -r capture.pcap -Y "dns.flags.response == 0" -T fields -e dns.qry.name a8f3c1d9e7b2...e9.exfil.example # neparasti garš subdomēns = iespējama DNS tunelēšana ─── Zeek · conn.log - beaconing (regulāri, vienāda izmēra savienojumi uz vienu mērķi) ─── $ cat conn.log | zeek-cut id.orig_h id.resp_h id.resp_p duration orig_bytes | sort | uniq -c | sort -rn | head 240 10.0.0.5 198.51.100.9 443 1.01 512 # ← 240 gandrīz identiski savienojumi = iespējams C2 beacon
Brute force / spray
Many failed logins (4625 / Filed password). Brute force - one IP. Password spray - one password against many accounts.
Local movement
4624 Type 3 + 4648 between hosts, unusual administrative links, use of remote services.
Persistence
New services (7045), planned tasks (4698), cron changes, new accounts (4720) - to keep access.
Foot-skiing
Audit log cleaning (1102), missing intervals, off logging - clear anti-forensics signal.
Data removal
Unusual large output, DNA tunnelling, connections to unknown destinations in non-standard time.
Web attacks
SQLi / XSS samples in access window, 4xx/5xx compactions, scanner User-Agent strings, access to admin roads.
Ecosystem and references
Tools, good practices and international standards
SEM
Centralized, indexed and correlated windows with alarms and dashboards: Splunk, Elastic Security, Microsoft Sentinel, QRadar, Wazuh, Graylog.
Agents / shippers
Collect and send windows to the center: Filebeat, Winlogbeat, Fluentd / Fluent Bit, rsyslog, syslog-ng, NXLog.
Opening languages
Rules and queries: Sigma (independent), Splunk SPL, Microsoft KQL, Elastic EQL; CLI - grep, awk, jq.
Host / IR
Endpoint and investigation: auditd, Sysmon, osquery; timeline - Plaso / log2timeline, Timesketch.
Centralize and backup
The windows are taken out of the host immediately. Keep append-only/WORM with a mess check.
Synchronize time
NTP and UTC for all sources - without which the correlation between systems is not reliable (ISO 27001 A.8.17).
Structure (JSON)
Structured windows facilitate parsing, search and automation. Defines a single scheme.
Unique Secrets
Mask passwords, tokens and excess personal data (GDPR data minimisation).
Regulate alarms
Reviews and rules apply to reduce false positive and alert fatigue.
Link to IR
Discoveries go to incident response process (NIST SP 800-61) - windows are its fuel.
Relationship to the NIS2
The NIS2 (EU 2022/2555) requires the logging, monitoring and detection of incidents. Keeping windows supports reporting obligations.
DGPR
Windows often contain personal data (IP, username) - they are subject to data minimisation, storage periods and access control.
Reservation
The material is an educational overview, not a full text of standards. Specific implementation should always be considered as an official source.