Volume 01 — Computer and Internet Foundations: What Happens Before You Even Type a Command
Part of series: Cloud Security Journey — Zero to Engineer
The moment that changed how I see computers happened inside a Windows 10 VM with Task Manager open.
I was looking at four processes — smss.exe (PID 360), csrss.exe (PID 463), lsass.exe (PID 704), services.exe (PID 684) — and I realized that every single thing that runs on Windows traces back to these four. Every service, every user process, every security tool. And one of these four — lsass.exe — is storing your password hash in memory right now. That single fact explains why Mimikatz exists, why credential dumping is one of the most common post-compromise techniques in real attacks, and why Microsoft built Credential Guard specifically to protect that one process.
That is what Volume 01 felt like. Not an introduction to computers. A realization that I had been using systems without understanding what was actually happening inside them.
What Volume 01 Actually Covered
The volume has 20 topics spanning hardware basics, operating systems, internet fundamentals, security principles, cryptography, and how the industry is structured. I am not going to list all 20 here. I am going to tell you the parts that genuinely changed how I think.
The hardware foundation was faster than I expected. CPU, RAM, storage, GPU, motherboard — these became real when I connected them to security. Cache memory is why Spectre works. Binary is why subnet masks look the way they do and why buffer overflows are possible. BIOS and UEFI are not just firmware — UEFI Secure Boot is the control that prevents bootkits from loading before your OS. I ran through these topics in Kali VM with uname -r, dmesg, and /proc/cpuinfo — seeing the kernel's view of the same hardware I had been treating as a black box.
Operating systems went much deeper than I anticipated. The kernel runs in Ring 0 with unrestricted hardware access. Every user application — including your antivirus — runs in Ring 3. This separation is enforced by the CPU hardware, not software. A kernel exploit is one that crosses from Ring 3 to Ring 0, and at that point every security control above it collapses simultaneously.
Windows Internals — The Part That Took the Most Time
Topic 5 (Windows OS Basics) was where I spent the most days, and it was worth every one of them.
NTFS surprised me with how much forensic information it stores. Four timestamps per file. A Master File Table with records for every file that has ever existed on the volume including deleted ones. A $UsnJrnl (Update Sequence Number Journal) that records every file system change — ransomware encrypting 10,000 files leaves a distinct pattern here even after the damage is done. I confirmed the cluster size with fsutil fsinfo ntfsinfo C: — 4096 bytes — which means a 1-byte file still occupies 4KB on disk.
Alternate Data Streams genuinely surprised me. NTFS allows a file to have multiple data streams. The hidden stream is invisible in Windows Explorer, invisible in dir, and has zero impact on the reported file size. I proved this with two commands:
echo "hidden payload" > test.txt:hidden_stream
dir test.txt → shows 0 bytes visible content
dir /R test.txt → shows :hidden_stream:$DATA
That is how malware hides data inside a legitimate file. One command to create it. One specific flag (/R) to detect it.
The Registry persistence lab was the one that made me uncomfortable. I ran reg add "HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run" as a regular user — no administrator prompt, no UAC warning, no confirmation dialog. A registry entry that survives every reboot was created in one command. Then I deleted it. Then I thought about how many machines have entries in that key that nobody has ever looked at.
Windows Event Logging gave me real forensic output. I created a test backdoor account with net user backdoor /add followed by net localgroup Administrators backdoor /add. Event ID 4720 (account created) and Event ID 4732 (added to privileged group) both appeared in the Security log immediately. I verified them with wevtutil qe Security. These two Event IDs are what SOC analysts watch for — I generated and confirmed them myself rather than just reading about them.
Linux, Networking, and the Security Connections
Linux file permissions became real when I ran find / -perm -u=s -type f in Kali and saw every SUID binary on the system. SUID means the binary runs as its owner, not as you. Every SUID binary owned by root is a potential privilege escalation path if it has a vulnerability. That one command is a standard check in every Linux security assessment.
The networking section connected everything I had learned to real attacks. Port 445 + EternalBlue = WannaCry spreading to 230,000 machines without a single user click. Port 23 open with default credentials = Mirai recruiting 600,000 IoT devices into a botnet. Colonial Pipeline — one VPN password, no MFA — 45% of US East Coast fuel supply disrupted. These are not history lessons. They are engineering failures with documented technical causes.
I ran dig google.com +trace, traceroute 8.8.8.8, nmap -sV localhost, and ss -tlnp in Kali VM. The DNS resolution trace alone — watching the query go from root servers to TLD to authoritative nameserver — made the 10-step walkthrough I had written in my notes feel like something I had actually seen rather than memorized.
What This Volume Changed
Before Volume 01, I understood computers as tools. After it, I understand them as systems with documented attack surfaces at every layer. The kernel is an attack surface. The file system timestamps are a forensic artifact. The registry Run key is a persistence mechanism. The process list is an investigation starting point.
Every one of these realizations came from running commands in a terminal and reading the output — not from reading about them.
All labs are committed to my GitHub repository with notes, output, and interview prep questions for every topic: https://github.com/Asheesh-01/cloud-security-journey
What Is Coming in Volume 02
Volume 02 goes much deeper into OS internals — both Windows and Linux. Kernel architecture, process internals, Windows Registry in depth, Linux file permissions at the SUID and sticky bit level, logging with auditd, and the volume ends with a real Linux hardening script built from scratch. The Lynis security audit tool runs against the VM and the findings become a written security report — the first real security artifact of the roadmap.
If you are building toward a security role or just want to understand what is actually happening inside the systems you use every day — follow along. Everything is public and documented.
Connect with me:
GitHub: https://github.com/Asheesh-01/cloud-security-journey
Platform: https://cyberdragons.in
"Volume 01 complete. Volume 02 in progress. The streak continues."
#cloudsecurity #linux #windows #cybersecurity #aws #networking #ethicalhacking #100daysofcode #infosec #blueteam
