Write-ups

Runtime Isolation and Persistence Boundary Lab
(ram-workspace-lab)

What was the task?

Build a lab that relocates a complete user workspace into RAM and enforces an explicit persistence boundary using encrypted storage. The system should execute entirely from /dev/shm, isolate runtime state from disk and only persist data through a controlled commit operation.

The goal was to analyse how execution context (memory vs disk) affects system visibility, how runtime and persistent state can be separated and how explicit persistence changes the observability of user activity.

What did I observe?

Relocating $HOME to /dev/shm cleanly shifts all user activity into volatile memory, with no inherent dependency on disk-backed storage during runtime.

From the kernel and process perspective, applications behave identically regardless of whether their working directory resides in memory or on disk.

File-based artefacts are absent during execution, but reappear instantly once the workspace is repacked and written back to persistent storage.

Environment manipulation (overriding HOME and XDG_CONFIG_HOME) is sufficient to redirect most user-space behaviour without requiring deeper isolation mechanisms.

The commit phase becomes a clearly defined transition point where transient state is converted into persistent artefacts, making persistence an explicit and observable operation.

What I learned?

Execution context in Linux is largely independent of storage location, but strongly influences where observable artefacts are generated.

Separating runtime and persistence introduces a controllable boundary that allows precise reasoning about when and how data becomes durable.

Default system behaviour implicitly persists state, whereas explicit commit models require deliberate handling of inclusion, exclusion and failure conditions.

Configuration files such as .rwsignore form part of the execution contract and must remain external, immutable inputs to avoid unintended side effects.

Reliable persistence requires a transactional approach: intermediate failures must not destroy runtime state and cleanup must only occur after successful completion.

What is the security-relevant takeaway?

Execution from volatile memory reduces filesystem-based visibility during runtime, but does not eliminate observability at the process or memory level.

Delaying persistence shifts detection opportunities from static file inspection to temporal analysis of execution phases and commit events.

Explicit persistence boundaries demonstrate that data durability is not inherent to execution, but a consequence of controlled write operations.

Monitoring approaches that rely solely on filesystem artefacts will miss activity occurring entirely in memory-backed environments.

Effective analysis requires correlating runtime behaviour with persistence events, rather than treating disk state as the primary source of truth.

Repository

github.com/daniel-ploetzl/ram-workspace-lab

USB HID Input Simulation Lab (hid-lab)

What was the task?

Build a firmware based USB Human Interface Device (HID) running on an RP2350 microcontroller that simulates structured input patterns such as mouse movement, clicks, keyboard activity, scrolling and window switching. The system emulates interaction timing using non-uniform delays and probabilistic scheduling, while exposing both keyboard and mouse functionality over a single USB interface using HID report IDs.

The goal is controlled input generation for analysing how systems behave under synthetic USB HID event streams at both kernel input and application event levels.

What did I observe?

USB HID input is accepted by the operating system as a standard input source once a device is successfully enumerated and is processed through the kernel input subsystem without application layer authentication.

Timing structure strongly influences how input streams are classified. Uniform intervals are easily identifiable as synthetic whilst burst idle patterns with bounded jitter more closely resemble statistical properties of natural interaction.

The RP2350 combined with TinyUSB allows multiplexed HID functionality using report IDs over a single interface enabling keyboard and mouse logical devices to coexist within a shared HID endpoint model.

Host side input handling is event driven and stateful. Key state transitions such as press hold release mouse deltas and scroll events are interpreted independently. This means partial or delayed report sequences remain valid within the HID model.

What did I learn?

USB HID is stateless at the device report level but stateful in the host input subsystem. Correct emulation requires explicit modelling of state transitions from press to hold to release rather than emitting isolated events.

Realistic input simulation is not achieved through randomness alone but through structured timing. Burst phases idle phases and bounded jitter distributions produce more realistic interaction patterns than uniform randomness.

Embedded timing is constrained by scheduler granularity and USB polling intervals. Behaviour design must operate within coarse grained temporal resolution rather than assuming millisecond precision.

USB descriptors define the device capability contract whilst firmware defines runtime behaviour. Any mismatch between declared descriptors and emitted reports can result in dropped or ignored input at the host level.

Finally, system input simulation operates at the boundary between hardware abstraction and operating system event handling where small design decisions in timing state transitions and report structure directly influence how the host interprets behaviour.

What is the security relevant takeaway?

USB HID is a low friction input channel with no intrinsic authentication mechanism after successful device enumeration, making it a high impact interface for both automation and input injection scenarios.

Detection of synthetic input relies on aggregate behavioural signals rather than single events including timing regularity interaction density and absence of corrective or exploratory user behaviour patterns.

From a defensive perspective, correlating USB device enumeration events with subsequent input behaviour is more reliable than attempting per event classification at the input layer. This highlights that trust in input devices is implicitly granted at the hardware abstraction layer limiting the effectiveness of user space only validation models.

Repository

github.com/daniel-ploetzl/hid-lab

X11 Session Behaviour & Input Capture Lab (x11-lab)

What was the task?

Build a user-space X11 application that creates a fullscreen black window, completely captures all keyboard and mouse input, hides the cursor and blocks user interaction for a defined duration. After a configurable runtime, the program terminates all user processes via a signal-based mechanism.

The objective was to analyse how input control, focus and process termination can be enforced purely from user space using X11 primitives, without requiring elevated privileges.

What did I observe?

X11 allows a client to fully take over user interaction by combining an override-redirect window with input grabbing. The window manager is bypassed entirely, meaning the fullscreen window cannot be managed, minimised or overridden by normal desktop controls.

Grabbing the keyboard and pointer ensures that all input events are redirected exclusively to the created window. Other applications no longer receive input, effectively locking the user session at the display level.

The use of an invisible cursor removes visual feedback, reinforcing the perception of a frozen or blocked system. Despite this, the X server continues to process events normally in the background.

The event loop remains active and responsive, handling motion and key events while resetting the screensaver. This prevents the system from entering power-saving states during the lock period.

Process termination using kill(-1, SIGKILL) operates independently of X11 and targets all processes within the same process group or user context, providing a hard stop mechanism triggered by a timer.

What I learned?

X11 provides powerful primitives for controlling input and display state entirely from user space. Window manager bypass (override_redirect) combined with input grabs enables complete session takeover without requiring elevated privileges.

Input control in X11 is cooperative rather than enforced by strict isolation. A single client can monopolise input devices if it successfully acquires the necessary grabs.

Visual state (window content, cursor visibility) and input state (keyboard/mouse focus) are independent but can be combined to create strong control over user perception and interaction.

The system remains event-driven throughout: even in a “locked” state, the X server continues dispatching events and the client must explicitly handle or ignore them.

What is the security-relevant takeaway?

X11 allows any authorised client to capture global input and render fullscreen content without user consent, enabling effective denial-of-interaction scenarios entirely from user space.

Because input grabbing is not strongly restricted, a malicious or misconfigured application can prevent all other applications from receiving input, effectively locking the session.

The combination of input capture and process termination demonstrates that significant control over a user session can be achieved without kernel exploits or elevated privileges, relying solely on standard X11 and POSIX mechanisms.

Detection and prevention must therefore focus on restricting access to the X server and monitoring abnormal client behaviour, rather than relying on application-level safeguards.

This reinforces a fundamental limitation of X11: trust is granted at the client level and once connected, a process can exert extensive control over input and display state.

Repository

github.com/daniel-ploetzl/x11-lab

TryHackMe - Pentesting Fundamentals

What was the task?

Complete TryHackMe's "Pentesting Fundamentals" room. This is a foundational module covering penetration testing methodologies, legal and ethical frameworks, rules of engagement, and testing scopes (black box, grey box, white box).

What did I observe?

All penetration testing methodologies follow a general pattern: information gathering, enumeration and scanning, exploitation, privilege escalation, and post exploitation. The room covered several industry frameworks, each with different strengths and target domains. OSSTMM (Open Source Security Testing Methodology Manual) focuses on telecommunications and wired/wireless networks. OWASP (Open Web Application Security Project) specialises in web application security. NIST CSF (National Institute of Standards and Technology Cybersecurity Framework) provides standards for critical infrastructure and commercial organisations. NCSC CAF (National Cyber Security Centre Cyber Assessment Framework) applies to organisations performing vitally important services.

The legal foundation for pentesting is simple. Anything within the signed Rules of Engagement (RoE) is authorised, anything outside it is unauthorised access. The RoE document has three sections: Permission (explicit authorisation), Test Scope (which systems are in scope), and Rules (which techniques are permitted). Testing approach depends on how much information is provided. Black box testing (no internal knowledge), grey box testing (limited knowledge) or white box testing (full access to source code and architecture). Grey box is the most common in real engagements because it balances realism with efficiency.

What I learned?

The difference between legal and illegal testing is documentation. Without a signed RoE, the same actions constitute unauthorised access. Penetration testing is an authorised simulation of attacks. The methodology mirrors what an attacker would do, but under contract. Industry frameworks exist to standardise testing processes, but none are universal. OWASP focuses on web applications, OSSTMM on telecommunications and networks, NCSC CAF on critical infrastructure. Choosing the right framework depends on what is being tested. Black box testing takes significantly longer because of the information gathering phase, but it simulates an external attacker's perspective. White box testing is comprehensive but time intensive and typically performed by developers, not external testers. Grey box strikes a balance. Enough information to be efficient, but still testing from an attacker's viewpoint.

Security-relevant takeaway?

Understanding penetration testing methodologies is essential for offensive as well as defensive cybersecurity practitioners. The same stages an attacker follows (reconnaissance, scanning, exploitation, escalation) are what SOC operations should be monitoring for. Defensive detection requires understanding offensive methodology. The distinction between authorised and unauthorised testing also clarifies why some security research is legal and some is criminal. The difference is the contract, not the technique.

Platform

tryhackme.com/room/pentestingfundamentals

Linux Process Behaviour and Ephemeral Execution Lab (proc-lab)

What was the task?

Build a user-space Linux process lifecycle lab that explores transient execution, process isolation and controlled runtime behaviour using Bash. The system should migrate itself into volatile memory, detach from the terminal and execute a rotating payload process with bounded runtime and non-deterministic timing.

The goal was to analyse how processes behave when executed from ephemeral locations, how lifecycle control can be enforced at the process group level, and how observable patterns emerge from short-lived execution chains.

What did I observe?

Processes executed from /dev/shm behave identically to disk-backed binaries from the kernel perspective, but leave minimal persistent artefacts once removed.

Detaching via nohup and setsid cleanly separates execution from the parent shell, creating independent process groups that persist beyond session termination.

Rotating payload execution with short overlap windows creates continuous activity while avoiding a single long-lived process, resulting in fragmented but sustained behaviour.

Process group termination using negative PIDs reliably scopes signals to only the intended execution chain, preventing unintended impact on unrelated processes.

What I learned?

Process lifecycle control in Linux is fundamentally tied to process groups and session management rather than individual PIDs.

Ephemeral execution does not imply invisibility, but shifts observability towards runtime signals such as process creation frequency, naming patterns and execution paths.

Introducing bounded randomness in timing produces more realistic and less deterministic behaviour compared to fixed intervals.

Reliable cleanup requires explicit tracking of created artefacts rather than relying on pattern-based deletion.

Monitoring must operate independently of the execution context to provide an accurate external view of system behaviour.

What is the security-relevant takeaway?

Ephemeral execution in volatile memory combined with self-replication and rapid lifecycle changes reduces forensic visibility at the filesystem level, shifting detection requirements toward process behaviour and system call monitoring.

Process group signalling and /proc-based observation remain the primary reliable sources of truth in such environments, but are limited by timing granularity and sampling delay.

This demonstrates that security monitoring based solely on file artifacts or static process snapshots is insufficient in environments where execution is transient, overlapping and memory-resident.

Effective detection requires continuous correlation of process creation, lifespan and termination patterns rather than isolated inspection of individual process states.

Repository

github.com/daniel-ploetzl/proc-lab

TryHackMe - Introduction to Detection Engineering

What was the task?

Complete TryHackMe's "Introduction to Detection Engineering" room covering detection types, the detection engineering lifecycle, key frameworks (MITRE ATT&CK, Alerting and Detection Strategy (ADS), Detection Maturity Level (DML)), and applying the ADS Framework to an Active Directory privilege escalation detection scenario.

What did I observe?

Detection engineering operates on four detection types across two categories: Environment-based (Configuration and Modelling) and Threat-based (Indicator and Threat Behaviour). Configuration detection is easiest to implement in static environments but breaks in dynamic infrastructure. Indicator-based detection (Indicators of Compromise (IOCs), IP lists) is fastest to deploy but becomes obsolete as adversaries change infrastructure. Threat behaviour detection focuses on Tactics, Techniques and Procedures (TTPs) and withstands adversary evolution but requires extensive baseline data.

The Detection as Code approach treats detection rules like software with version control and Continuous Integration/Continuous Deployment (CI/CD) pipelines. Most Security Information and Event Management (SIEM) systems lack native version control for detection rules, which means changes are untracked and difficult to audit.

The ADS Framework mandates nine stages before production deployment: Goal, Categorisation, Strategy Abstract, Technical Context, Blind Spots & Assumptions, False Positives, Validation, Priority, Response. The Validation stage requires maintaining test scripts that generate true-positive events alongside detection rules.

Ryan Stillions' DML model shows most organisations operate at DML-1/DML-2 (atomic indicators and artifacts), which he describes as "chasing vapor trails". Higher maturity levels (DML-5+ for techniques, tactics, strategy) require progressively more contextual intelligence and abstraction.

The practical exercise demonstrated detecting unusual PowerShell host processes by monitoring for system.management.automation.dll loading into non-standard processes, a common Operational Security (OPSEC)-friendly technique adversaries use to avoid detection.

What I learned?

Detection engineering is continuous iteration, not one-time rule deployment. Rules must be modified as attack vectors and environments change. Combining detection types creates stronger coverage than relying on a single approach, e.g., pairing baseline modelling with configuration detection reduces false positives.

The ADS Framework forces you to think through the entire detection lifecycle before writing rules. The "Blind Spots & Assumptions" stage is counterintuitive but critical: explicitly documenting where your detection can fail enables risk assessment and compensating controls. For the PowerShell example, assumptions included endpoint tools running correctly, logs being forwarded and SIEM indexing successfully.

Validation is non-negotiable. Every detection should have accompanying test commands that generate true-positive events. Without this, you're deploying unverified rules into production.

The DML model revealed that most organisational resources concentrate on IOC feeds (DML-1), which are retroactive and adversary rate-of-change dependent. Moving toward behaviour-based detection (DML-5+) provides better Return on investment (ROI) but requires baseline data and more implementation effort.

Detection as Code (DaC) solves SIEM limitations by treating rules as version-controlled code. Sigma rules are vendor-agnostic and deployable across multiple SIEMs, which enables code reusability across detections.

What is the security-relevant takeaway?

Indicator-based detection (IP lists, hash values) is reactive and short-lived. Adversaries change infrastructure faster than organisations update indicator feeds. Investing disproportionately in DML-1/DML-2 approaches creates a maturity gap where detection always lags behind adversary capabilities.

Behaviour-based detection targeting TTPs provides sustainable defensive advantage because adversaries cannot easily change tactics without significant operational cost (Pyramid of Pain principle). However, this requires accurate baselines and cross-departmental collaboration to define normal behaviour.

Before deploying any detection rule, complete the ADS Framework validation stage with executable test commands. Untested detections generate alert fatigue when false positives fire, or worse, fail silently when real threats occur. Maintain validation scripts alongside detection rules in version control.

Map detection gaps proactively using MITRE ATT&CK during threat modelling, not reactively after incidents. Identify which TTPs your environment is vulnerable to, determine required data sources, then assess collection coverage. Missing log sources create blind spots that adversaries can exploit.

Platform

tryhackme.com/room/introtodetectionengineering

TryHackMe - Intro to Logs

What was the task?

Complete TryHackMe's "Intro to Logs" room, a beginner module covering log types, formats, standards, collection, storage, retention, deletion and a hands-on exercise using rsyslog and Unix tools to collect, parse, consolidate and analyse logs from multiple sources.

What did I observe?

Logs from different sources come in incompatible formats, e.g. nginx uses Combined Log Format, syslog uses its own timestamping, and application logs use JSON or XML. Before any analysis is possible, these need to be normalised to a common timestamp format. The practical exercise used awk and sed to rewrite timestamps from each source into a sortable format, then sort and uniq to deduplicate.

Time synchronisation (NTP) is a prerequisite. Without it, correlating events across systems is unreliable. Log retention follows a Hot/Warm/Cold model: recent logs in fast-query storage, older logs in a data lake, archived logs in compressed cold storage. GDPR (General Data Protection Regulation) requires unnecessary data to be removed, but deletions must be deliberate and auditable, with backups taken where retention is legally required. rsyslog can be configured per-service (e.g. isolating all sshd messages to a dedicated file) with a single config file in /etc/rsyslog.d/.

What I learned?

Centralisation is not optional. Without it, attack timelines cannot be reconstructed across systems. Parsing and normalisation are required before any analysis, as raw logs from heterogeneous sources are not directly comparable.

A single awk pipeline can normalise, extract, and reformat logs, but the logic differs per source format and must be written individually. Filtering after consolidation (e.g. by IP) is an effective way to reduce scope and focus on relevant events.
Log integrity matters: taking a hash (sha256sum) during collection is required if logs may later be used as evidence.

What is the security-relevant takeaway?

Effective detection depends on log collection working correctly before it depends on analysis tools. Missing centralisation, incorrect time synchronisation, or insufficient log retention silently break event correlation.

Log rotation is a security control, not housekeeping. Logs rotated too aggressively may remove data needed for investigation, while logs that are never rotated create availability and compliance risks. Retention policies must balance forensic needs, storage limits and European/national data protection requirements.

Platform

tryhackme.com/room/introtologs

Authentication Log Analysis Tool (soc-auth-triage)

What was the task?

Build a command-line tool to analyse system authentication logs and extract SSH-related authentication events. The script should identify failed login attempts, targeted usernames, time-based attack patterns and potential compromises by correlating failed logins with subsequent successful ones from the same source IP.

What did I observe?

On a production VPS, a small number of source IPs were responsible for the majority of failed login attempts, each registering hundreds of attempts within hours. The most targeted account was root, followed by common service accounts like mysql and backup.

Attack activity clustered in specific hours rather than being spread evenly, which is consistent with automated tools, not manual attempts. Modern Linux systems use RFC3339 timestamps and log Connection closed ... [preauth] instead of the traditional Failed password pattern. On some minimal cloud images, /var/log/auth.log doesn't exist at all and systemd logs only to journalctl.

What I learned?

Depending on configuration, systemd may log to files or to journalctl only. fail2ban blocks attempts before they appear as Failed password entries, so pattern matching must also handle Connection closed ... [preauth]. Correlating different event types (failed vs. successful) requires process substitution < <(...) to avoid subshell variable scope issues.

Key learning: In security log analysis, simple Unix tools (grep, awk, cut, sort, uniq) combined in clear pipelines are often more readable and maintainable than heavily complex regular expressions.

Beyond the technical implementation, I learned the importance of being explicit about assumptions when analysing logs. Log formats, available fields and even the presence of log files differ between systems, so tooling must fail safely and make its limitations visible rather than silently producing incomplete results. This reinforced that log analysis is less about writing clever parsing logic and more about systematically reducing uncertainty while avoiding false conclusions.

What is the security-relevant takeaway?

Automated scanning is constant background noise on any public-facing server. When reviewing authentication logs, the most relevant correlation to check first is whether repeated failed login attempts from the same source IP are later followed by a successful login, as this requires closer inspection.

Time-based clustering helps distinguish automated scanning from normal user behaviour. Repeated attempts against non-existent accounts usually indicate reconnaissance, where an attacker is testing which usernames exist before trying valid credentials.

Repository

github.com/daniel-ploetzl/soc-auth-triage

→ Home → About me → Contact