1 Windows Logs & Sysmon
Windows logs matter enormously because Windows remains common across enterprise endpoints and servers. Get comfortable with Windows Event Viewer and Windows Security auditing, starting with these Event IDs:
| Event ID | Meaning |
|---|---|
| 4624 | Successful logon |
| 4625 | Failed logon |
| 4648 | Logon using explicit credentials |
| 4672 | Special privileges assigned |
| 4688 | New process created |
| 4720 | User account created |
| 4724 | Password reset attempted |
| 4728 / 4732 | User added to a global / local security group |
| 4740 | Account locked |
| 4768 / 4769 | Kerberos TGT / service ticket requested |
| 4771 | Kerberos pre-authentication failed |
| 1102 | Audit log cleared |
Don't try to memorise every Event ID — learn how to look them up and understand the fields inside them. Microsoft's recommended security-monitoring event collections cover most of the logon, process, account, group and auditing events above.
Many organisations also deploy Microsoft's Sysmon for much richer Windows telemetry — process creation, network connections, file creation, driver loading, DNS queries, registry changes, and process access. Sysmon Event ID 1 is process creation; Event ID 3 is a network connection. Microsoft describes Sysmon as a Windows system service and driver that records detailed system activity and can feed it straight into a SIEM for analysis.
2 Linux Logs
SOC analysts need Linux fluency too. Typical sources: /var/log/auth.log, /var/log/secure, /var/log/messages, /var/log/syslog, and modern distributions' journalctl. A sample SSH authentication sequence:
Aug 30 08:04:21 web01 sshd[28451]: Failed password for invalid user admin from 203.0.113.72 port 49121 ssh2
Aug 30 08:04:24 web01 sshd[28451]: Failed password for root from 203.0.113.72 port 49123 ssh2
Aug 30 08:05:02 web01 sshd[28466]: Accepted password for devops from 203.0.113.72 port 49201 ssh2
🔮 Predict first
What in this sequence should immediately catch your attention?
Reveal the answer
Same source IP, multiple failed attempts against different usernames (including a probe against root), immediately followed by a successful authentication as devops from that identical IP — worth investigating exactly like the Windows 4625→4624 pattern from Lesson 1, just in a different log format.
3 Network Logs: Firewall, DNS, Proxy & Web Server
A firewall log entry: time=08:22:44 action=allow src=10.20.15.81 dst=198.51.100.40 src_port=51382 dst_port=443 protocol=tcp bytes_sent=1842 bytes_received=774. One connection alone is rarely enough context — ask how often it recurs, which device and process generated it, whether the destination is known, and whether DNS telemetry shows a matching domain.
DNS logs can be especially valuable: client=10.20.15.81 query=update-check.example type=A response=198.51.100.40. If that same device queries the same domain every 60 seconds for hours, that regular pattern can resemble command-and-control beaconing — MITRE describes C2 as adversary communication with compromised systems, often deliberately blended into normal application-layer protocols to avoid standing out.
Web proxy logs reveal which sites users reach, files downloaded, URLs requested, HTTP methods, response codes, and data transferred — e.g. user=CORP\alice method=GET url=https://download.example/payload.zip status=200 bytes=1849231. Combined with endpoint telemetry, this can pinpoint exactly when a suspicious file entered the environment.
Web server logs follow a familiar Apache/nginx-style format: 203.0.113.50 - - [30/Aug/2026:08:40:31 +0000] "POST /login HTTP/1.1" 401 512. Hundreds of near-identical entries — POST /login, HTTP 401, same source, high frequency — is a classic signature of an authentication attack against a web application, not just an internal system.
4 Cloud Logs
Traditional infrastructure asked "who logged into the server?" Cloud environments add a second, equally critical question: who called the API? An attacker may never touch a server directly — compromised cloud credentials calling APIs can be just as damaging, and look completely different in the logs.
AWS CloudTrail
Records API activity:
{
"eventTime": "2026-08-30T09:12:42Z",
"eventSource": "iam.amazonaws.com",
"eventName": "CreateAccessKey",
"sourceIPAddress": "203.0.113.91",
"userIdentity": { "type": "IAMUser", "userName": "automation-admin" }
}
Worth asking: why did this account create an access key? Was there an approved change? Where did the request originate? Has this account ever created credentials before? Was the new key subsequently used?
Azure and Microsoft Entra logs
Analysts commonly work with Entra sign-in logs, Entra audit logs, Azure Activity Logs, Microsoft 365 audit logs, and Defender alerts. A sign-in event might show a successful login with MFA satisfied — but don't automatically read MFA success = legitimate login. An attacker can steal sessions, tokens, cookies, or an already-approved MFA session (Module 9, Lessons 2 and 6 cover exactly how). Modern SOC investigation requires understanding authentication well beyond "did the password match."
5 SaaS & Legacy Enterprise Logs
Global organisations run heavily on SaaS — Microsoft 365, Google Workspace, Salesforce, ServiceNow, GitHub, Slack, Zoom, Workday, Okta — and important security signal lives in their audit logs too. Example: User: finance.director. Activity: Created mailbox forwarding rule. Destination: external-address@example.net. Mailbox forwarding rules get investigated often because attackers who compromise an email account frequently try to maintain access to incoming messages even after the obvious compromise gets cleaned up.
Don't assume every company runs modern cloud infrastructure, either. Large organisations may still operate Windows Server 2008/2012, legacy Unix, AIX, Solaris, mainframes, IBM i/AS400, older Oracle databases, older network appliances, and proprietary banking applications — a bank might run a thoroughly modern Microsoft 365 environment alongside a decades-old mainframe, simultaneously. Security monitoring there may involve Syslog, SNMP traps, Windows Event Forwarding, database audit logs, mainframe SMF records, RACF security events, or application-specific flat files. Understanding the concept of a log — a timestamped record of something that happened, worth correlating with everything else — is worth far more than memorising any one vendor's interface.
6 Working With Realistic Data
SOC skills aren't learned from slides — they're learned by analysing telemetry. But production logs from real companies should never be used for training, because they can contain employee information, customer information, IP addresses, internal hostnames, credentials, tokens, and other personal data. The right approach is sanitised logs, public cybersecurity datasets, lab-generated telemetry, or synthetic events built on genuine vendor formats — exactly the approach this module's lab pack (Lesson 5) takes, using reserved documentation IP ranges throughout.
Splunk's Boss of the SOC (BOTS) datasets are an excellent public example, purpose-built for blue-team investigation training with realistic telemetry including Sysmon and Suricata data. Security Onion is also worth knowing about — it lets you pivot between alerts and the underlying full packet captures, connecting a detection back to the actual traffic that triggered it.
Lesson Outcome
You should now be able to recognise the key Windows Event IDs and what Sysmon adds on top of them, read Linux authentication logs for the same failed-then-successful pattern taught in Lesson 1, interpret firewall/DNS/proxy/web server logs, read AWS CloudTrail and Entra sign-in events with appropriate scepticism about "MFA success," and explain why SaaS and legacy logs both still matter. Lesson 5 puts all of this into practice with real investigation walkthroughs and the full downloadable lab pack.