October 21, 2026

TryHackMe Free: Intro to Logs

Before we start

By Daniel Almeida

4 min read

Before we start

Hi! This is my first post here on Medium, so I'll keep it simple and straight to the point. My idea is to take the notes I make while studying cybersecurity and turn them into articles. Writing down what I learn helps me retain it, and maybe it will help someone else who is just starting out too.

To kick things off, I'm bringing you the Intro to Logs room from TryHackMe, which I completed a while ago. Let's get into it.

What are logs?

Think of the rings of a tree. Each ring tells how that year went: thick when it went well, thin when it was tough. Logs do the same thing in a system. Every login, every file access, every error or network connection leaves a digital footprint.

A log is basically a record of events that happened in a system. Each entry usually includes:

  • Timestamp: when the event happened
  • Source: the system or application that generated the record
  • Event type: what happened
  • Details: user, IP address, device, etc.

A single entry on its own seems meaningless. But when you gather several logs and cross-reference them, they start answering the questions of an investigation: what, when, where, who, whether it succeeded, and what the result was.

Example from the room

In the room's scenario, the fictional company SwiftSpend Financial suffered an attack. The logs made it possible to reconstruct everything:

  • What: an adversary accessed the company's GitLab
  • When: September 8th, 2023, at 22:10
  • Where: from an IP inside the VPN segment (10.10.133.0/24)
  • Who: identified by the browser's User-Agent and the assigned IP
  • Successful? Yes, an API key was publicly exposed and the attacker kept access through a web shell
  • Result: remote code execution and post-exploitation activity

This shows the power of logs: without them, you're blind.

Types of logs

  • Application logs: status, errors and warnings from applications
  • Audit logs: activities related to compliance and regulation
  • Security logs: logins, permission changes, firewall activity
  • Server logs: system, event, error and access logs from servers
  • System logs: kernel, system errors, boot sequences, hardware
  • Network logs: traffic and network connections
  • Database logs: queries and updates
  • Web server logs: requests, URLs, response codes

Log formats

The format defines the structure of the data in a log file. The room splits them into three groups:

Semi-structured: a mix of predictable parts and free text

  • Syslog
  • Windows Event Log (EVTX)

Structured: follow a strict pattern, easy to analyse

  • CSV / TSV
  • JSON
  • W3C Extended Log Format (used by IIS)
  • XML

Unstructured: free text, harder to process

  • NCSA Common Log Format (CLF), used by default in Apache
  • NCSA Combined, used by default in Nginx (adds referrer and user agent)

There are also custom formats, which offer flexibility but may require specific tools for parsing.

Logging standards

A standard doesn't just define the format. It also defines which events to record, how to transmit them securely and how long to keep them. Some the room mentions:

  • Common Event Expression (CEE), by MITRE
  • OWASP Logging Cheat Sheet
  • Syslog Protocol (RFC 5424)
  • NIST SP 800–92
  • Logging guides for Azure, Google Cloud and Oracle Cloud

Collection, management and centralisation

Collection: identify the sources (servers, databases, apps, network devices), choose a collector, configure the parameters and test. One important point: keep clocks synchronised with NTP. If the times are wrong, the incident timeline is compromised. On Linux you can synchronise with ntpdate pool.ntp.org.

Management: store securely, organise by source or type, make backups and review periodically.

Centralisation: bring everything into one place (Elastic Stack, Splunk), connect the sources, set up monitoring and alerts, and integrate with incident management tools.

Storage, retention and deletion

Keeping logs forever isn't an option, so you need to balance usefulness and cost. The room explains retention in three tiers:

Tier Period Access Hot 3 to 6 months Near real-time Warm 6 months to 2 years Easy, but not immediate Cold 2 to 5 years Archived, used for retroactive analysis

When it comes to deletion, you have to be careful not to erase what may still be useful, and it's important to comply with laws like the GDPR.

Best practices:

  • Define policies based on business needs and legal requirements
  • Review policies regularly
  • Automate storage, retention and deletion
  • Encrypt sensitive logs
  • Back up before deleting

The log analysis process

This was the section I enjoyed the most. Analysis goes through several stages:

  1. Parsing: break the log into understandable components
  2. Normalisation: put data from different sources into a common format
  3. Sorting: order by time, source, severity, etc.
  4. Classification: assign categories to filter what matters
  5. Enrichment: add context (geolocation, threat intelligence, user data)
  6. Correlation: link related events
  7. Visualisation: charts and heat maps to spot patterns
  8. Reporting: summarise for management, security teams or auditors

Tools

For complex tasks there are SIEMs, like Splunk and Elastic. But in incident response, when speed is needed, the native Linux tools get the job done: cat, grep, sed, sort, uniq, awk and sha256sum. On Windows there are EZ-Tools and Get-FileHash.

One detail that stuck with me: you should calculate the hash of the log file at the time of collection, to ensure integrity and admissibility in court.

Techniques

  • Pattern recognition
  • Anomaly detection
  • Correlation analysis
  • Timeline analysis
  • Machine Learning and AI
  • Visualisation
  • Statistical analysis

Practical part

The room has two approaches, both using the open-source Log Viewer tool:

1. Raw logs: open the files directly in Log Viewer by specifying the paths in the URL. It's great for quick inspections and preserves the original format.

2. Consolidated and parsed log: use awk and sed to normalise the entries from each file (nginx, cron, sshd, GitLab's api_json) into a common format, merge everything into one file, and then:

# (optional) filter by a suspicious IP
grep "34.253.159.159" /tmp/parsed_consolidated.log > /tmp/filtered_consolidated.log
# sort by date and time
sort /tmp/parsed_consolidated.log > /tmp/sort_parsed_consolidated.log
# remove duplicates
uniq /tmp/sort_parsed_consolidated.log > /tmp/uniq_sort_parsed_consolidated.log

In the end, you open the result in Log Viewer and get a single timeline with events from multiple sources. This is where I understood how correlation works in practice.

Conclusion

Logs are much more than old records. Whoever knows how to read them can diagnose problems, detect threats and meet legal requirements. What stood out to me most in this room was realising that collecting, organising and preserving the integrity of logs is just as important as knowing how to analyse them.

Thanks for reading my first post! If you have tips, corrections or suggestions for rooms I should do next, leave them in the comments. See you in the next one.

#cybersecurity #tryhackme #logs #blueteam #infosec