DEV Community: Narasimha Mallegari

All 5 Security+ domains, Splunk certified, 35 applications sent

Narasimha Mallegari — Wed, 22 Apr 2026 00:35:07 +0000

Three weeks into a structured cybersecurity learning journey. Week 3 review.

What this week accomplished

All five Security+ domains are covered for the first time. Splunk certificate earned. Hash cracker built. 35 job applications sent. Four Python tools on GitHub. Bandit level 24.

Security+ — the full picture

Weeks 1-2 covered Domains 1-3 (50% of exam). Week 3 completed Domains 4 and 5 (48% of exam). All content has been seen at least once.

Domain 4 Security Operations — the domain most directly relevant to a SOC analyst role:

Incident response: 6 phases in exact order. Security+ tests whether you can identify which phase a given action belongs to. Preparation, Identification, Containment, Eradication, Recovery, Lessons Learned.

Digital forensics order of volatility: RAM first, archived media last. Evidence in RAM disappears on power off. Some sophisticated malware is designed to exist only in RAM for exactly this reason — no disk artifacts, clean exit on reboot.

SIEM and Splunk: SOC analysts use SIEM to correlate events across thousands of systems simultaneously. Splunk's SPL queries do the same thing my Python log analyzer does — find patterns in log data — at enterprise scale.

IOCs and TTPs, MITRE ATT&CK: The framework that maps known attacker techniques across the full attack lifecycle. Defenders use it to build detection rules. Knowing it signals to employers that you think about security like a professional.

Domain 5 Security Program Management:

Risk responses (accept, transfer, avoid, mitigate) — every business security decision is one of these four.

Five compliance frameworks — each one created in response to a category of breach that caused enough damage to require mandated minimum standards. Understanding why each framework exists makes the requirements easier to remember than memorizing a list.

Second practice test: 90. Improvement: 5 points. June exam target: 83%+.

What I built

Hash cracker: dictionary attack against MD5, SHA1, and SHA256. The result of testing "password123" against 14 million real passwords communicates the entire argument for bcrypt better than any explanation. MD5 falls in seconds. bcrypt would take thousands of years on the same hardware with the same wordlist.

Splunk Fundamentals 1

Free. All modules. Certificate earned. Added to LinkedIn certifications.

Splunk appears in approximately 70% of SOC Analyst job postings. A verifiable Splunk certificate provides a concrete credential to discuss in interviews while Security+ is still pending.

OverTheWire Bandit

Levels 16-23 covered SSH SSL auditing, diff for file comparison, startup file persistence techniques, SUID exploitation, netcat C2 communication, and cron job privilege escalation.

The cron job levels were the most instructive — they demonstrate a real attack technique on a real server, which is a different experience than reading about it in a textbook.

Applying during training

35 applications are not a random activity. It is starting a pipeline that takes 4-6 weeks to produce interviews. Starting Week 3 means potential first interviews around Week 5-7. That timing overlaps with the Security+ exam arrival, creating the ideal scenario — interviews scheduled at the moment the certificate arrives.

Waiting until "fully ready" delays the pipeline without adding meaningful qualification. The resume already has verifiable evidence of skills. The exam date signals a concrete timeline.

Everything on GitHub. Two repositories. Linked on profile.

Hash cracker built, Splunk certified, 35 job applications sent

Narasimha Mallegari — Wed, 22 Apr 2026 00:31:47 +0000

Three weeks into learning cybersecurity from zero. This covers Week 3.

Applying before feeling ready

I sent 35 job applications this week. I do not have the Security+ certificate yet. I applied anyway.

Here is what made that reasonable: Security+ exam booked for June 9, four Python tools on GitHub, Splunk Fundamentals 1 certificate earned this week, and 21 days of daily public documentation.

The pipeline from application to offer in cybersecurity averages 4-6 weeks. Applications sent now become interviews in Weeks 5-7. Those interviews happen right around when the Security+ arrives. Waiting until the cert was in hand would mean starting the pipeline at Week 8 — a 4-6 week delay with no benefit.

Security+ — all 5 domains covered for the first time

Domain 4 Security Operations is the most directly relevant to a SOC analyst role.

Incident response process — 6 phases that Security+ tests in strict order: Preparation, Identification, Containment, Eradication, Recovery, Lessons Learned.

Order of volatility in digital forensics: Collect RAM before hard drives. Evidence that exists only in memory is lost on power is off. Some malware exploits this deliberately — existing only in RAM with no disk artifacts.

Domain 5 covered risk management and compliance. The five frameworks (HIPAA, PCI-DSS, GDPR, SOC 2, NIST CSF) make more sense when you understand the category of damage that created each one.

Second practice test: 90/100. Improvement from Week 2: 95/100. On track for the June exam.

The hash cracker

Core logic in about 15 lines:

import hashlib

with open(wordlist, "r", errors="ignore") as f:
    for word in f:
        word = word.strip()
        if hashlib.md5(word.encode()).hexdigest() == target_hash:
            print(f"Found: {word}")
            break

Tested against the MD5 hash of "password123" using rockyou.txt — 14 million real passwords. Found in [your actual time].

MD5: approximately 10 billion attempts per second on consumer hardware. bcrypt at cost factor 12: approximately 100 attempts per second. That difference — 100 million times slower — is the entire argument for modern password hashing.

Writing the tool made this concrete. Reading about it does not.

Splunk Fundamentals 1 — certified

Free course. All modules complete. Certificate earned and added to LinkedIn.

Key insight: The SPL search that finds top attacking IPs is the same operation as my Python log analyzer — same logic, different syntax, different scale:

index=main "Failed password" | stats count by src_ip | sort -count | head 10

Understanding the small Python version made the enterprise SIEM tool immediately intuitive.

Bandit level 24 — cron job exploitation

The most realistic technique from this week: finding a directory that a privileged cron job reads from and that a lower-privilege user can write to. Placing a script there. The cron job executes it with elevated permissions.

This is a real misconfiguration on production servers. The fix is simple — correct the write permissions on the cron input directory. Without that fix, any user who can write there can escalate their privileges.

Week 4

Full Security+ review. Third practice test. Interview preparation — because applications sent this week will generate responses this week and next. Five applications per day continue.

Code and notes on GitHub — link on profile.

Security+ started, 3 tools built, real attacks found on my own machine

Narasimha Mallegari — Sun, 19 Apr 2026 21:41:35 +0000

Two weeks into a structured cybersecurity learning journey. This is the Week 2 review. Week 1 review and daily posts are on my profile.

What changed between Week 1 and Week 2

Week 1 was building a mental model — understanding networking protocols, Linux commands, and basic Python.

Week 2 was applying that model — studying for a real certification, building tools that do real things, and seeing real evidence of attacks.

Security+ — 7 days of study

Booked CompTIA Security+ SY0-701 exam for June 9, 2026. Using Professor Messer's free course.

Domain 1 — General Security Concepts

CIA triad: three genuinely distinct properties that fail independently. Confidentiality fails in data breaches. Integrity fails when data is modified in transit. Availability fails during DDoS attacks.

Authentication (proving identity) and authorization (granting permissions) are separate systems. Both must work correctly. Broken access control — where authorization fails — is in the OWASP Top 10 every year.

Security control types: preventive, detective, corrective, deterrent, compensating. The exam tests which type applies to a given scenario.

Domain 2 — Threats and Vulnerabilities

Eight malware categories. Key distinction: the virus requires human action to spread. Worm spreads automatically through vulnerability exploitation. Different propagation, different defenses.

Eight social engineering attack types. Pretexting — creating a fabricated scenario to manipulate a target — is the one most people underestimate. It bypasses all technical controls.

Domain 3 — Security Architecture

Zero Trust replaces perimeter security. Never trust, always verify. Every access request is authenticated regardless of source. Required by government contracts and increasingly standard in enterprise.

First practice test score: Tracking weekly to measure improvement toward the exam.

Three tools built this week

Port Scanner v2 — upgraded with service name dictionary. Port numbers display with protocol names.

Password Generator — cryptographically random passwords using Python string and random libraries.

Log Analyzer — this one produced something real. Reads auth.log, ranks source IPs by failed SSH attempts. Ran on my own Kali machine. Found 10 failed login attempts from 30 unique external IP addresses in less than two weeks of uptime.

Writing a tool that finds real attacks on a real system you own is a different experience than reading about what attacks look like.

OverTheWire Bandit — levels 8 through 15

Level 10 reinforced an important point: base64 is encoding, not encryption. Looks mysterious, decodes instantly. Attackers use it for obfuscation. Recognizing it is a basic skill.

Level 12 was the most complex — a file compressed multiple times with different algorithms. The file command at each step identified the next compression type. The same technique is used when analyzing obfuscated malware payloads.

Level 14 introduced netcat — raw TCP connections to any host and port. One of the most versatile tools in network security.

Level 15 introduced OpenSSL for testing SSL connections.

Resume drafted

First draft complete. No cybersecurity job experience. Portfolio evidence instead: three Python tools with GitHub links, Security+ exam date, 14 days of public documentation. Any recruiter who clicks the GitHub links can verify working code with documentation.

Week 3

Security+ Domains 4 and 5 — Security Operations and Security Program Management — account for 48% of the exam combined. Domain 4 alone is 28%. This is where incident response, SIEM, threat intelligence, and vulnerability management live. The most relevant domain for a SOC analyst role.

First job applications are being sent this week.

Everything is public. GitHub repositories are linked on my profile.

Security+ started, 3 tools built, real attacks found on my own machine

Narasimha Mallegari — Sat, 18 Apr 2026 21:01:51 +0000

Two weeks into a structured cybersecurity learning journey. This is the Week 2 review. Week 1 review and daily posts are on my profile.

What changed between Week 1 and Week 2

Week 1 was about understanding how things work — networking protocols, Linux commands, basic Python. The goal was to build a mental model.

Week 2 was about applying that understanding — studying for a real certification, building tools that do real things, and confronting real evidence of attacks.

The difference is not just in what I learned. It is in what I produced.

Security+ — 7 days of study

I booked the CompTIA Security+ SY0-701 exam for June 9, 2026. Eight weeks to study. I am using Professor Messer's free course on his website.

Seven days in, three domains covered:

Domain 1 — General Security Concepts

The CIA triad is not marketing language. Each component represents a genuinely distinct security property that can fail independently:

Confidentiality fails in data breaches
Integrity fails when data is modified in transit
Availability fails during DDoS attacks and ransomware

Authentication (proving identity) and authorization (granting permissions) are separate systems that both need to work correctly. Security+ tests whether you can identify which one is broken in a given scenario.

Domain 2 — Threats, Vulnerabilities, and Mitigations

This is the largest domain at 22% of the exam. Eight malware categories, eight social engineering attack types, vulnerability scanning, penetration testing phases, and threat intelligence.

The malware distinction that appears most on practice tests: a virus requires human action to spread. Worms spread automatically by exploiting vulnerabilities. They have different propagation mechanisms, which means they require different defenses.

Social engineering: pretexting is the one that most people underestimate. A convincing scenario and a phone call can bypass technical defenses entirely. Training is the only defense.

Domain 3 — Security Architecture

Zero Trust is the most important concept here. Never trust, always verify. Every access request is authenticated and authorized regardless of whether it comes from inside or outside the network. This replaced perimeter security when remote work and cloud services made the concept of a network perimeter meaningless.

Three tools built this week

Port Scanner v2 — upgraded with a service name dictionary. Port numbers now display with protocol names. Small change, more useful output.

Password Generator — generates cryptographically random passwords using Python's string and random libraries. Takes length and count as input. 20 lines.

Log Analyzer — this one produced something real. It reads Linux auth.log files and ranks source IP addresses by failed SSH login attempts.

I ran it against /var/log/auth.log on my Kali machine. My system has been running for less than two weeks and already has external IP addresses in the log with multiple failed SSH attempts.

That is a real attack against a real system I own, caught by a tool I wrote.

In a production environment, SIEM tools do this at enterprise scale — parsing millions of log entries from thousands of systems simultaneously and alerting on anomalous patterns. My script does the same thing on a small scale. Understanding it at the code level makes the enterprise tool more intuitive.

OverTheWire Bandit — levels 8 through 15

Key concepts from this week's levels:

Level 10 — base64 decoding. Base64 is encoding, not encryption. Looks mysterious, decodes instantly. Attackers use it for obfuscation. One command undoes it.

Level 12 — layered compression. A file compressed multiple times using gzip, bzip2, and tar. Had to use the file command after each decompression to identify the next layer. This is how malware analysts unpack obfuscated payloads.

Level 14 — SSH key authentication. A private key file is used to log into a server without a password. How cloud servers are accessed in production environments. Stolen SSH keys = persistent backdoor access.

Level 15 — netcat. Raw TCP connections to any host and port. One of the most versatile tools in network security and penetration testing.

Resume drafted

First draft complete. No cybersecurity job experience. Instead: technical skills section with 12 tools and concepts, three Python security tools with GitHub links and documentation, Security+ exam date, and 14 days of public learning documentation.

The goal is that a recruiter who spends 30 seconds on the resume and then 2 minutes on GitHub has enough verifiable evidence to decide this candidate is worth interviewing.

Week 3 starts

Security+ Domains 4 and 5 — Security Operations and Security Program Management — are 48% of the exam combined. Domain 4 alone is 28%. This is where incident response, threat intelligence, SIEM, and vulnerability management live. The most relevant domain for a SOC analyst role.

First job applications are being sent this week. Resume is ready. Security+ is listed as in progress with an exam date.

Everything is public. Two GitHub repositories and blog posts are linked on my profile.

I built a log analyzer, and it found real attacks on my own machine

Narasimha Mallegari — Sat, 18 Apr 2026 20:57:52 +0000

I am documenting every day of my cybersecurity learning journey publicly. This post covers Days 8 through 12 — the first half of Week 2.

The log analyzer and what it found

The most significant thing I built this week is a Python log analyzer. It reads Linux auth.log files, finds every failed SSH login attempt, extracts the source IP from each one, and counts how many times each IP tried.

Here is the core logic:

from collections import Counter

failed_ips = []
with open("/var/log/auth.log", "r") as f:
    for line in f:
        if "Failed password" in line:
            parts = line.split()
            for i, part in enumerate(parts):
                if part == "from":
                    failed_ips.append(parts[i + 1])

ip_counts = Counter(failed_ips)
for ip, count in ip_counts.most_common(10):
    print(ip + " — " + str(count) + " attempts")

I ran this against my actual Kali machine's auth.log. My system has been running for less than two weeks. The output showed real external IP addresses that had attempted SSH brute force attacks — automated scanners crawling the internet looking for systems with weak SSH credentials.

That is what SOC analysts see at enterprise scale — except they are watching thousands of servers simultaneously using SIEM tools. My script does the same thing for a single log file. Writing it at the code level makes the enterprise workflow more intuitive.

Security+ — 5 days of study

Started CompTIA Security+ SY0-701 on Day 8 using Professor Messer's free course. Here is what the first five days covered.

Malware types — the most tested area of Domain 2

The distinction that appears most on practice tests: virus vs worm.

A virus requires human action to spread. It attaches to files and moves when those files are shared.

A worm spreads automatically. It exploits vulnerabilities to move across networks without anyone clicking anything. WannaCry was a worm — it used the EternalBlue exploit on SMB port 445 and infected 230,000 systems across 150 countries in a single day without requiring any user interaction.

Understanding this distinction at the mechanism level, not just the definition level, is what makes it stick on exam day.

Social engineering — most breaches start here

Eight attack types: phishing, spear phishing, whaling, vishing, smishing, pretexting, baiting, tailgating.

The one I had not thought carefully about: pretexting. An attacker creates a convincing scenario — "I am the new IT admin, I need your credentials to migrate your account" — and relies on the target's willingness to be helpful. No exploit. No malware. Just a believable story.

Technical defenses cannot stop pretexting. Training is the defense.

Zero Trust — replacing perimeter security

The old model: build a wall around the network, trust everything inside. This failed when remote work and cloud services dissolved the perimeter.

Zero Trust: never trust, always verify. Every access request is authenticated and authorized regardless of source. A device already inside the network is treated as untrusted until it proves otherwise.

Base64 — not encryption

Bandit level 10 reinforced something worth writing about explicitly.

Base64 looks like encrypted data. It is not. It is encoding — converting binary data to ASCII text. Anyone can decode it instantly with one command: base64 --decode.

Attackers use it to make payloads look mysterious in logs and scripts. It is one layer of obfuscation. Once you recognize base64 (padding with = at the end, characters from A-Z a-z 0-9 + /), decoding it takes seconds.

The same is true for ROT13 — rotating letters 13 positions. Not encryption. Not security. Appears in CTF challenges constantly.

Port scanner version 2

Updated the port scanner from Week 1 to display service names alongside port numbers. Changed one output line using a Python dictionary lookup:

common_services = {21: "FTP", 22: "SSH", 80: "HTTP", 443: "HTTPS"}
service = common_services.get(port, "Unknown")
print("[OPEN]   Port " + str(port) + " — " + service)

Now instead of "[OPEN] Port 22" it shows "[OPEN] Port 22 — SSH". Small change, meaningfully more useful.

Three tools on GitHub now

Port scanner (v2 with service names), password generator, and log analyzer. All with documentation explaining how they work and what I learned building them. Link on my profile.

I built a port scanner from scratch, and it taught me more than running Nmap ever did

Narasimha Mallegari — Tue, 14 Apr 2026 06:14:28 +0000

What was covered today

OverTheWire Bandit levels 4 through 7, Python chapters 3 and 4 (functions and lists), and writing a working port scanner from scratch in Python.

The port scanner

Here is the complete code. I will explain every meaningful line afterward.

import socket
from datetime import datetime

print("=" * 50)
print("  Python Port Scanner")
print("=" * 50)

target = input("\nEnter IP address or domain to scan: ")

print("\nTarget:     " + target)
print("Started:    " + str(datetime.now()))
print("-" * 50)

open_ports = []

for port in range(1, 1025):
    try:
        sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
        sock.settimeout(0.5)
        result = sock.connect_ex((target, port))
        if result == 0:
            print("[OPEN]   Port " + str(port))
            open_ports.append(port)
        sock.close()
    except KeyboardInterrupt:
        print("\nScan interrupted.")
        break
    except socket.gaierror:
        print("Could not resolve hostname.")
        break

print("-" * 50)
print("Scan complete. Open ports: " + str(open_ports))

How it actually works

The core of this entire script is four lines:

sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
sock.settimeout(0.5)
result = sock.connect_ex((target, port))
if result == 0:

socket.socket(AF_INET, SOCK_STREAM) creates a TCP socket. AF_INET means IPv4. SOCK_STREAM means TCP. This is the same type of connection your browser makes when it loads a website.

sock.settimeout(0.5) tells the socket to give up after half a second if there is no response. Without this, the scanner would wait indefinitely on filtered ports and take hours to complete.

sock.connect_ex((target, port)) attempts a full TCP connection to the target on the given port. This is different from connect() — connect_ex returns an integer error code instead of raising an exception. If it returns 0, the connection succeeded. The port is open. A service is listening.

That is the entire concept of port scanning. Attempt a connection. Record whether it succeeded.

Nmap does this same fundamental operation with many more features layered on top — service version detection, OS fingerprinting, script scanning. But underneath all of that, at the core, it is still: attempt TCP connection, record result.

Understanding that made Nmap feel less like a black box.

Testing it

I ran it against 127.0.0.1 first — my own Kali machine. Then against scanme.nmap.org — the legal practice server.

The results matched what Nmap found on Day 3. Two different tools, both written to do the same network-level operation, report the same open ports. That cross-validation felt important. It confirmed I understood what the tool was doing rather than just hoping it worked.

OverTheWire Bandit levels 4 through 7

The Bandit levels today introduced the find command with property-based searching. This is where it started feeling most like real security work.

Level 5 → 6 required finding a file that was exactly 1033 bytes and not executable:

find. -type f -size 1033c! -executable

The ! is the negation operator. It means NOT. So this finds files that are NOT executable. Combined with the size filter, only one file matches.

Level 6 → 7 required searching the entire server for a file owned by a specific user and belonging to a specific group:

find / -user bandit7 -group bandit6 -size 33c 2>/dev/null

Searching from / means the entire file system. This generates hundreds of permission denied errors as it tries to read directories we cannot access. 2>/dev/null sends all those errors to nowhere.

One file path appeared in the output. That was the answer.

This exact command structure appears in privilege escalation checklists. After gaining initial access to a Linux system, attackers search for files owned by privileged users that they might be able to read or write — configuration files, private keys, scripts. The find command is how they locate them efficiently.

Level 7 → 8 was grep:

grep "millionth" data.txt

The file has millions of lines. grep found the one relevant line instantly. This is used constantly in security work — searching log files for specific events, finding credentials in configuration files, and parsing tool output to find relevant lines.

What Python chapters 3 and 4 added

Chapter 3 was functions. The port scanner has no separate functions — everything is in the main script. But once I add features like service name lookup or output saving, those will become functions. Understanding return values made the socket code make more sense: connect_ex returns an integer, I check if that integer equals 0, and I make a decision.

Chapter 4 was a list. The open_ports list in the scanner is a direct application of Chapter 4. Append to the list inside the loop, print the full list at the end. Simple, but it made the chapter feel immediately practical rather than theoretical.

What this building taught me

I could have run Nmap to scan ports. I have been running Nmap. But I would not have understood what was actually happening.

Building the scanner made me think about:

What is a socket, and why does it need to be created and closed for each port?
Why does settimeout matter, and what happens without it?
What does connect_ex actually do under the hood versus connect?
Why does returning 0 mean success in socket programming?

These questions did not come up when I ran Nmap. They came up when I had to write the code myself.

That is the difference between using tools and understanding them. Both matter in cybersecurity. But understanding is what makes you dangerous — in the right way.

The code is on my GitHub. Link to my profile. Week 2 starts tomorrow with Security+ study beginning in earnest.

One missing flag on a cookie enables session hijacking, and I almost glossed over it

Narasimha Mallegari — Thu, 09 Apr 2026 03:09:04 +0000

I am documenting every day of my cybersecurity learning journey publicly. This is Day 5. Previous posts are on my profile.

What was covered today

DNS record types in depth, TryHackMe HTTP in Detail and DNS in Detail rooms, Python chapters 1 and 2 from Automate the Boring Stuff, and writing and running my first Python script in Kali Linux.

The thing about cookies I almost missed

I was working through the TryHackMe HTTP in Detail room and hit the section about cookies. I already understood roughly what cookies were — they store your login session, so you do not have to log in on every page.

What I did not understand was the security flags. Specifically HttpOnly.

Here is what HttpOnly does: when a cookie has the HttpOnly flag set, JavaScript cannot read it. That sounds like a minor technical detail. It is not.

If a website has a cross-site scripting (XSS) vulnerability — meaning an attacker can inject JavaScript into a page — and your session cookie does not have HttpOnly set, that injected script can read your session cookie and send it to the attacker. The attacker now has your session. They are logged in as you. They never needed your password.

The fix is one word. HttpOnly. The developer adds it when they create the cookie. Done. Session cookie theft via XSS becomes impossible.

But it is missed constantly. Bug bounty hunters find this all the time on real production websites. It is in the OWASP Top 10 under broken authentication. Companies pay bounties for it.

I almost read past it because it looked like a minor detail. It is not minor. It is the kind of thing that separates a developer who understands security from one who does not — and it is exactly what a SOC analyst needs to recognize in an incident report.

DNS record types — why each one matters

I covered basic DNS on Day 3 — what DNS does and how to query it. Today was about the specific record types and their individual security implications.

The ones that surprised me most:

TXT records reveal a company's entire email security posture. SPF, DKIM, and DMARC records are all stored as TXT records. If you query a company's TXT records and find no SPF record, you know their domain can be used to send spoofed emails that may pass spam filters. That is the foundation of business email compromise attacks.

CNAME records create subdomain takeover vulnerabilities. If a company has a CNAME pointing to a third-party service they no longer use, an attacker can claim that service and control what visitors to that subdomain see. There are documented cases of this affecting major companies — subdomains of Microsoft, Google, and hundreds of others have been vulnerable to this at various points.

PTR records are used in forensics. When you see a suspicious IP in a log file and do a reverse DNS lookup, the PTR record tells you what domain it belongs to. This is one of the first things an analyst does during incident response when investigating an unknown connection.

Starting Python

I have been looking forward to this and slightly dreading it at the same time. I have never written code before.

Two chapters in — the dread is mostly gone.

Python reads like instructions written in near-English. Al Sweigart writes Automate the Boring Stuff like he is explaining things to a friend, not writing documentation. Chapter 1 covers variables, data types, and basic operators. Chapter 2 covers flow control — if statements, for loops, and while loops.

What clicked for me:

Every security tool at its core is just a loop. A port scanner loops through port numbers and checks each one. A password cracker loops through a wordlist. A directory brute-forcer loops through paths. Chapter 2 — specifically the for loop and range() function — is the conceptual foundation for all of those tools.

for port in range(1, 1025):
    # check if this port is open
    # This is the core of a port scanner

That is not a working port scanner yet. But that mental model — loop through a range of numbers and do something with each one — is the entire concept. The next few days will add the socket library and the actual connection logic. But the loop is the skeleton.

First script written and run

Here is what I wrote today:

name = input("What is your name? ")
print("Welcome to cybersecurity training, " + name + "!")
print("")

for i in range(1, 6):
    print("Loading security module " + str(i) + "...")

print("")
print("All modules loaded. Training begins now.")

I ran it with python3 first_script.py in my Kali terminal. It worked on the first try. That felt good.

More importantly, when I made a mistake earlier and forgot a closing parenthesis, Python gave me this:

SyntaxError: '(' was never closed

Exact line. Exact problem. I fixed it in ten seconds. Error messages in Python are genuinely helpful, which is not something I expected going in.

What five days of this have felt like

Looking back at the week:

Day 1: OSI model — networking theory
Day 2: Wireshark — watching packets live
Day 3: Nmap — scanning real servers
Day 4: Linux and Bandit — working on a remote server
Day 5: DNS records, HTTP internals, Python starts

Every day has had at least one moment where something clicked through doing rather than reading. Today it was the cookie flags — reading about them was fine, but working through the TryHackMe room where you actually exploit the absence of HttpOnly made it concrete.

Tomorrow: more Bandit levels, Python functions and lists, and writing a port scanner. That is the goal for Day 6 — first real security tool.

Notes are on my GitHub — link on my profile.
https://github.com/narasimhamallegari/cybersecurity-notes

Learning Cybersecurity — OverTheWire Bandit taught me more about Linux in one hour than a week of reading

Narasimha Mallegari — Tue, 07 Apr 2026 03:28:54 +0000

I am documenting every day of my cybersecurity learning journey publicly. This is Day 4. Previous entries are on my profile if you want to follow from the start.

What was covered today

Linux fundamentals through linuxjourney.com, 18 commands practiced in my Kali terminal, OverTheWire Bandit levels 0 through 3, and TryHackMe Linux Fundamentals Part 1.

Why Linux specifically

I want to write this down because I think it is worth stating clearly.

90% of servers on the internet run Linux. Every major cloud platform runs Linux underneath. Kali Linux — the operating system I use for all my security work — is built on Linux. When a penetration tester gains initial access to a system, it is almost always a Linux shell they end up in.

Linux is not background knowledge in cybersecurity. It is the main environment. Knowing it well is the difference between being able to do the actual work and just knowing the theory.

The commands that surprised me the most

I expected Linux to be harder to learn than it is. The commands themselves are short and logical — ls to list, cd to change directory, cat to read, and find to search. The difficulty is not memorizing them. It is understanding what happens when you combine them.

The one that clicked for me today was this:

find / -perm -4000 2>/dev/null

This searches the entire file system for files with SUID permissions set. SUID means the file runs with the permissions of its owner rather than the person running it. If a SUID file is owned by root and has a vulnerability, a low-privilege attacker can exploit it to gain root access.

This command — one line — is something every attacker runs within the first few minutes of getting a shell on a Linux system. I ran it in Kali today and found several SUID files. Now I understand why privilege escalation checklists always start with checking for SUID binaries.

OverTheWire Bandit — the best learning experience of the week

OverTheWire Bandit is at overthewire.org/wargames/bandit. It is free. You connect with SSH and work through levels, each one teaching a real Linux skill through a practical challenge.

I went in expecting it to feel educational. It did not. It felt like working.

Level 0: Connect, find a file, and read it. Simple. cat readme. Done.

Level 1: The file is named with a single dash character. I ran cat - and nothing happened — it just waited for keyboard input. Spent a few minutes on this one.

The reason: in Linux (and in most Unix-like systems), a single dash is a special character that means standard input. The shell interprets it before even looking for a file. The fix is to give the shell a path context:

cat ./-

The ./ says "this is a file in the current directory." Now the shell treats the dash as part of a filename rather than a special character. Problem solved.

That one challenge explained something about Linux command parsing that I had not thought about before — the shell is doing interpretation work before any command even runs. That becomes relevant in web security too: SQL injection and command injection both exploit the fact that interpreters process special characters before treating input as data.

Level 2: File with spaces in the name. Spaces break shell syntax because the shell treats each space-separated word as a separate argument. Solution: quote the filename.

cat "spaces in this filename."

Level 3: Hidden file inside a directory. Running ls shows nothing. Running ls -la shows a file called .hidden — the dot at the start makes it a hidden file in Linux.

cd inhere
ls -la
cat .hidden

Four levels. Each one taught something I will use in real security work: filename edge cases, shell character handling, and hidden files. These are not academic concepts. They come up in CTF competitions, in post-exploitation on real systems, and in forensic investigations.

File permissions — the concept that unlocks Linux security

When I ran ls -la in Kali, I saw lines like this:

-rwxr-xr-- 1 kali kali 4096 Apr 6 16:00 myscript.sh

That string of r, w, x, and dashes at the start is the permission set. It tells you exactly who can read, write, and execute the file — the owner, the group, and everyone else.

Understanding permissions is what makes privilege escalation possible to understand. Misconfigured permissions are one of the most common vulnerabilities on Linux systems. A file that should only be readable by root but is readable by everyone — that is a misconfiguration that leaks sensitive data. A script that runs as root but is writable by a low-privilege user — that is a privilege escalation waiting to be exploited.

Once you understand permissions, you start seeing why so many security findings come back to "this file has incorrect permissions set."

TryHackMe Linux Fundamentals Part 1

Completed today. The room has a built-in terminal so you can practice without needing your own Linux machine. The questions reinforce the same commands I practiced in Kali, which is exactly the kind of deliberate repetition that builds muscle memory.

One concept this room clarified: the difference between absolute and relative paths. An absolute path starts from / and works from anywhere. A relative path depends on where you currently are. In security scripts, absolute paths are safer because the script behaves predictably regardless of where it is called from.

What four days of this have felt like

The pattern I have noticed: every day, there is at least one moment where something abstract becomes concrete. Day 2 it was watching a TCP handshake happen in Wireshark. On Day 3, it was seeing open ports on a real server through Nmap. Day 4, it was the cat ./- moment in Bandit — realizing the shell is doing interpretation work I never thought about.

These moments do not come from reading. They come from doing something in a terminal and hitting an unexpected result. That is when the learning actually happens.

Four days in. Every day on GitHub. Tomorrow: DNS records, HTTP details, and Python starts.

Notes are on my GitHub — link on my profile if you want to follow along.

Learning Cybersecurity — I ran my first real Nmap scan, and it made ports click in a way no video ever did

Narasimha Mallegari — Mon, 06 Apr 2026 04:31:36 +0000

I am documenting every single day of my cybersecurity learning journey publicly. This is Day 3. Previous entries are on my profile.

What today was about

Common ports, IP addresses, Nmap scanning in Kali Linux, DNS recon commands, and completing the TryHackMe OSI Model room. On paper, that sounds like a full course. In practice, it was about 2 hours, and the most hands-on day I have had so far.

Ports — why I finally understand why they matter

I have been reading the words "port number" for three days. Today I watched Professor Messer's Common Ports video, and something about the way he explains it made it land.

Ports are numbered doors on a server. Every service that runs on a server listens on a specific port waiting for connections. SSH waits on door 22. Web servers wait on door 80 (HTTP) or 443 (HTTPS). MySQL databases wait on door 3306.

The security implication is direct: if you find port 3389 open on a Windows server, you know Remote Desktop is running. That is a door that ransomware groups specifically target because they can brute force the login and get full access to the machine. Understanding ports means understanding what every open door on a server could let in.

The port I found most interesting to learn about was 445 — SMB (Windows file sharing). This is the port that the EternalBlue exploit used, which is what spread WannaCry ransomware globally in 2017. One misconfigured port, one unpatched vulnerability, and 230,000 computers across 150 countries were encrypted. Real consequences from a port number.

Running Nmap for the first time

Nmap is already installed in Kali Linux. I opened the terminal and typed:

nmap scanme.nmap.org

That is it. One command. And results appeared showing which ports are open on a real server on the internet.

I then ran version detection:

nmap -sV scanme.nmap.org

This does not just show you that port 22 is open. It tells you the exact software and version. OpenSSH 6.6.1p1 in my case. That version number matters because if there is a known vulnerability in that specific version, an attacker now has a precise target.

The workflow I did today — DNS queries, then Nmap — is literally the first 20 to 30 minutes of a professional penetration test. The reconnaissance phase. The attacker (or, in my case, a student on a legal practice target) maps the infrastructure before touching anything.

DNS recon — I did not expect this to be interesting

I ran nslookup, dig, and host against google.com today.

What struck me is that this information is completely public. There is no authentication, no permission required, and no login. Anyone in the world can query the DNS records of any domain. And those records reveal a lot:

A records show IP addresses
MX records show which servers handle email for the domain
NS records show which nameservers control DNS for the domain
TXT records often reveal which third-party services a company uses

From a security standpoint, an attacker uses this to map a company's infrastructure before ever sending a single malicious packet. And the company has no way to see who is querying their DNS records or to prevent it.

Understanding this made me think differently about domain registration and DNS management. Companies should audit their own DNS records regularly to make sure they are not exposing more than intended.

TryHackMe OSI Model room — 14 out of 16

Completed it today. The two questions I got wrong both involved the boundary between Layer 2 and Layer 3. Specifically, ARP — Address Resolution Protocol. ARP maps IP addresses (Layer 3) to MAC addresses (Layer 2). Because it deals with IP addresses, you might assume Layer 3. But ARP actually operates at Layer 2 because the MAC address lookup is a Data Link layer function.

The boundary between layers is where the tricky exam questions live. Something to review.

What I noticed about how I am learning

Three days in, I can see a pattern in what actually makes things stick:

Watch the video → immediately open the terminal → run the command I just learned about → write down what I see and why it matters.

The gap between watching and doing needs to be as short as possible. When I watched the Nmap video and then immediately opened Kali and ran the scan, the concepts were still fresh, and the hands-on made them concrete. When I tried to do exercises hours after watching a video, I had to rewatch sections.

Twenty minutes of hands-on practice after a video is worth more than two hours of watching without touching a terminal.

Tomorrow — Linux fundamentals

Day 4 shifts to Linux. I will be working through linuxjourney.com, running commands in my Kali terminal, and starting OverTheWire Bandit — a game where you SSH into a remote server and find passwords using Linux commands. Looking forward to that one.

All notes and commands from today are on my GitHub. https://github.com/narasimhamallegari/cybersecurity-notes

Learning Cybersecurity — I watched my own internet traffic, and it changed how I think about security

Narasimha Mallegari — Sat, 04 Apr 2026 19:39:51 +0000

I am documenting every day of my cybersecurity learning journey publicly.

What I did today

Watched Professor Messer's TCP/IP video, installed Wireshark, completed my first TryHackMe room, and spent about two hours actually watching packets move through my own network.

The moment everything clicked

I have read about TCP handshakes probably five times in the last week. SYN, SYN-ACK, ACK. I understood the words. I could repeat them back. But I did not really understand them.

Today I opened Wireshark, started a capture, loaded a website, and watched it happen in real time on my own machine. My computer sent a SYN. The server replied SYN-ACK. My machine confirmed with ACK. Then the data started flowing.

That is the moment the moment theory became real for me. It is three packets. It happens in milliseconds. And it happens every single time any device anywhere connects to any other device on the internet.

The HTTP experiment that honestly surprised me

I set up a Wireshark filter for HTTP traffic and visited a website that does not use HTTPS — neverssl.com, which exists specifically for this kind of testing.

I found one of the captured packets and clicked on it. In the lower panel of Wireshark, I could read my entire web request. Every header. The browser I was using. The page I requested. Everything.

Plain text. Completely readable.

I knew HTTPS was important before today. But seeing HTTP traffic readable in Wireshark made it real in a way that reading about it never did. If I were on public WiFi at a coffee shop using an HTTP website, anyone else on that network could run Wireshark and read exactly what I was sending. Logins. Session tokens. Everything.

This is why security researchers talk about public WiFi being dangerous. It is not theoretical. You can literally watch it happen.

DNS — something I never thought about before

When you type a website address into your browser, your computer does not magically know where to go. It sends a DNS query first — essentially asking "hey, what is the IP address for this domain name?"

In Wireshark, I could see this happen before the page even started loading. The DNS query left my machine. A response came back with the IP address. Then the TCP connection to that IP started.

Every website visit involves this. You just never see it unless you are looking at the raw traffic.

TryHackMe — first room done

Completed the "What is Networking?" room on TryHackMe today. It covered what networks are, IP addresses, MAC addresses, and the basics of ping and ICMP.

One thing I picked up that I did not know before: MAC addresses are hardware-level identifiers that cannot change, while IP addresses are assigned by the network and can change. So when a device connects to a new WiFi network, it gets a new IP — but its MAC address stays the same.

That distinction matters in security because MAC addresses can be used to track devices even when they change IP addresses, and MAC spoofing (faking your MAC address) is a real attack technique.

Questions I left with today

How does a router decide the best path when there are multiple routes to a destination?
What is inside a TLS certificate, and how does it prove a website is legitimate?
If WiFi is encrypted, why is it still possible for attackers to intercept traffic?

These go on my list.

What is on the plan for tomorrow

Professor Messer Common Ports video — memorizing the standard port numbers
First Nmap scan in Kali Linux on a legal test target
TryHackMe OSI Model room
DNS recon commands in terminal — nslookup, dig, host

All my notes are on my GitHub. If you are also learning cybersecurity and want to compare notes, feel free to connect.