🎯 Goal

The objective for today was to transform the Windows VM from a simple investigation machine into a telemetry-generating endpoint and to complete the infrastructure blueprint of the entire cyber lab.

The focus areas were:

• installing Sysmon telemetry
• building a structured cyber lab architecture
• documenting full rebuild procedures for all systems
• completing the GitHub lab blueprint repository

By the end of the session the lab evolved from a loose set of VMs into a documented, reproducible cybersecurity environment.

🛠 What I Did

Installed Sysmon Telemetry

The most important task today was installing Sysmon (System Monitor).

Sysmon is part of Microsoft Sysinternals and records detailed system activity events that are extremely valuable for security investigations.

The installation process included:

Downloading Sysmon from the Sysinternals website.
Extracting the archive.
Installing Sysmon using the ARM64 binary compatible with the Windows VM.
Applying a structured configuration file based on the SwiftOnSecurity Sysmon configuration.

Once installed, Sysmon started running as a system service.

Verification confirmed the service was active:

Get-Service sysmon*

Output confirmed:

Running Sysmon64a

This means the system is now generating telemetry for events such as:

• process creation
• network connections
• registry modifications
• file creation events
• process injection activity

These events are stored in:

Event Viewer → Applications and Services Logs → Microsoft → Windows → Sysmon → Operational

This telemetry is the foundation of modern blue-team detection workflows.

Built the Cyber Lab Blueprint Repository

The repository created yesterday was expanded into a complete lab infrastructure blueprint.

The repository now contains:

cyberlab-blueprint

windows/
scripts/
config/
manual-tools/

docs/

Key files added include:

• Windows VM rebuild guide
• Ubuntu VM rebuild guide
• macOS host rebuild guide
• Cyber lab architecture documentation

The repository serves as a single source of truth for rebuilding the entire environment.

This means that if any VM is lost or corrupted, the environment can be recreated using the documentation and scripts stored in the repository.

Documented Full System Rebuild Procedures

A major part of today’s work involved writing structured rebuild documentation for every machine involved in the lab.

These guides explain how to reconstruct:

• the Windows SOC investigation VM
• the Ubuntu analysis VM
• the macOS host workstation

Each guide includes:

• installation steps
• required tools
• configuration instructions
• explanations for each component

This ensures the lab environment remains reproducible and maintainable.

Created Operational Rebuild Playbooks

In addition to the full teaching guides, I also created quick rebuild playbooks.

These are simplified operational checklists designed for situations where a VM must be rebuilt quickly.

The playbooks contain:

• minimal explanations
• exact commands
• fast rebuild procedures

This approach mirrors how real engineering teams maintain runbooks for infrastructure recovery.

Finalized the Cyber Lab Architecture

The full architecture of the lab was finalized and documented.

The environment now consists of three main machines:

macOS Host
Windows SOC VM
Ubuntu Analysis VM
Kali Attack VM

The workflow between these systems looks like this:

Kali VM
(simulated attacker)

↓

Windows VM
(telemetry generation)

↓

Ubuntu VM
(investigation and analysis)

↓

macOS Host
(orchestration and documentation)

This architecture allows the lab to simulate real blue-team investigation workflows.

🔗 Key Cybersecurity Connections

Today’s work connects directly to real-world security engineering practices.

Security teams rely on structured telemetry pipelines to detect suspicious activity.

Tools such as Sysmon provide visibility into system behavior that would otherwise remain hidden.

For example:

A suspicious command executed on Windows can generate a process creation event.

That event can then be analyzed to determine:

• which program launched the process
• which user executed it
• which parent process started it
• what command-line arguments were used

This type of telemetry forms the basis of threat detection and incident response.

🔍 Investigation Questions

When investigating Sysmon telemetry during an incident, analysts might ask:

Which process executed the suspicious command?
What parent process launched it?
What user account initiated the activity?
Did the process establish network connections to external infrastructure?
Are there related events such as registry changes or file creation?
Do similar events appear on other hosts in the environment?

These questions help analysts reconstruct the sequence of events surrounding suspicious activity.

🚨 Detection Opportunities

Sysmon telemetry provides many detection opportunities, including:

detecting unusual parent-child process chains
identifying suspicious PowerShell execution
detecting encoded command execution
monitoring unexpected network connections from processes
detecting suspicious file or registry modifications

Telemetry sources useful for these detections include:

Sysmon process creation events
Sysmon network connection events
Windows Event Logs
endpoint detection and response (EDR) telemetry.

🧭 MITRE ATT&CK Techniques

Sysmon telemetry often helps detect activity associated with MITRE ATT&CK techniques such as:

T1059 — Command and Scripting Interpreter
T1105 — Ingress Tool Transfer
T1218 — Signed Binary Proxy Execution
T1547 — Boot or Logon Autostart Execution

These techniques frequently appear in attacker activity recorded within endpoint telemetry.

⚠ Challenges

Architecture-Specific Sysmon Binary

The Windows VM runs on ARM architecture due to Parallels virtualization.

Because of this, the correct Sysmon binary had to be used:

Sysmon64a.exe

Using the wrong binary would cause the installation to fail.

Understanding system architecture compatibility is important when working with security tooling.

Repository Organization

A large number of files were created today including documentation, scripts, and configuration files.

Maintaining a clear repository structure was essential to avoid confusion and ensure the environment remains manageable.

This reinforced the importance of clear infrastructure organization.

📚 What I Learned

Several key insights emerged during today’s work.

Telemetry is the foundation of detection

Security investigations rely heavily on system telemetry.

Without logs and monitoring data, suspicious activity becomes extremely difficult to analyze.

Installing Sysmon transforms a normal Windows system into a high-visibility investigation endpoint.

Infrastructure documentation is critical

Even small lab environments can become difficult to maintain if their setup is undocumented.

Writing rebuild guides ensures the system can be recreated quickly in the future.

Structured environments accelerate learning

Instead of repeatedly rebuilding random systems, having a stable lab environment allows experimentation to build on previous work.

This improves learning efficiency significantly.

➡ Next Steps

The next stage of development for the lab will involve generating and investigating real telemetry events.

Planned activities include:

• executing suspicious PowerShell commands
• observing Sysmon process creation events
• analyzing event logs
• practicing investigation workflows

This will allow the lab to simulate real Security Operations Center (SOC) investigations.

🧠 Reflection

Today the lab transitioned from a set of virtual machines into a complete cyber security experimentation platform.

The environment now includes:

• automated system setup
• structured telemetry generation
• documented rebuild procedures
• version-controlled infrastructure

This creates a powerful foundation for future experimentation, investigation practice, and skill development.

Building environments like this mirrors the workflows used by real-world security engineers and analysts.

🧩 Lessons Learned

What worked

Installing Sysmon and structuring the repository provided immediate improvements to the lab’s investigative capabilities.

What broke

Some tools initially failed due to architecture compatibility and execution policy restrictions.

Why it broke

Windows security defaults and ARM compatibility requirements must be understood when installing security tools.

Fix / takeaway

Carefully verify architecture compatibility and configure execution policies appropriately when preparing investigation environments.

📈 Skill Progression Context

The work done today builds several key cybersecurity competencies.

These include:

• Windows system investigation
• telemetry collection and analysis
• environment automation
• infrastructure documentation
• Git-based environment management

These skills are highly relevant for roles such as:

SOC Analyst
Detection Engineer
Threat Hunter
Digital Forensics Analyst

Developing and maintaining a personal cyber lab like this provides a safe environment to practice the investigative workflows used by security professionals.