DEV Community: Khalif AL Mahmud

Practical Reconnaissance and Attack Surface Discovery with Subfinder, httpx, FFUF, Katana, and AI

Khalif AL Mahmud — Wed, 02 Sep 2026 21:22:38 +0000

I wanted to understand what a careful, low-impact reconnaissance process looks like before any deeper security testing begins. The goal was not to “attack” a system, but to build an accurate map of publicly observable assets: domains, live hosts, technologies, directories, URLs, and authentication-related routes.

This exploration used Playtika’s authorized bug-bounty scope as the example. The in-scope target was the wildcard *.playtika.com, with the important restriction that only assets explicitly included by the program should be considered. Everything below focuses on discovery and documentation—not exploitation.

Problem statement

A large organization rarely has a single website. It may have APIs, shops, content sites, staging systems, CDN hosts, game services, administrative applications, and older endpoints spread across many subdomains. Looking only at the main homepage can therefore miss most of the observable attack surface.

The practical problem was to answer six questions:

Which subdomains can be identified from public sources?
Which of those hosts respond over HTTP or HTTPS?
What technologies and version clues are exposed?
Which directories and URLs are visible through normal discovery and crawling?
Which assets deserve attention based on function and naming?
Can an AI-assisted wordlist organize what has already been observed without inventing unsupported names?

Step-by-step reconnaissance workflow

1. Confirm the authorization boundary

Before running tools, I recorded the target and scope:

Program: Playtika bug bounty
Target: *.playtika.com
Rule: include only assets listed by the program; exclude anything outside the published scope

Caption: Capture the program page showing the authorized `.playtika.com` wildcard and the exclusion notice for domains or applications not specifically included.*

This scope check matters because a wildcard alone does not automatically authorize every related service, third-party hostname, or discovered dependency.

2. Enumerate subdomains with Subfinder

I used Subfinder to collect publicly discoverable subdomains, then sorted and deduplicated the results:

subfinder -d playtika.com -silent | sort -u | tee playtika_subdomains.txt

The document shows examples such as api.playtika.com, account.hof-dsa.playtika.com, admin.cc-api-dsa.playtika.com, assets.wsop.playtika.com, and many CDN, API, pre-production, and game-related names.

Caption: Capture the first visible portion of the Subfinder output, including several discovered subdomains.

Caption: Capture the terminal command that writes sorted unique results to playtika_subdomains.txt.

To count the result set, I used:

wc -l playtika_subdomains.txt

The recorded result was 447 unique subdomains.

Caption: Capture the wc -l output showing 447 playtika_subdomains.txt.

3. Probe for live HTTP and HTTPS hosts

Next, I reduced the subdomain list to hosts that responded to web probes:

httpx-toolkit -l playtika_subdomains.txt -silent -o playtika_live_hosts.txt

The document records 95 live HTTP/HTTPS hosts.

Caption: Capture the live URLs produced by the HTTP probing step.

Caption: Capture the command and output showing 95 playtika_live_hosts.txt.

For a more useful first-pass fingerprint, I also collected status codes, page titles, and detected technologies:

httpx-toolkit -l playtika_live_hosts.txt -silent -status-code -title -tech-detect -o playtika_tech.txt

Examples in the output included:

cdn-shop.playtika.com returning 200, with HTTP/3 and HSTS indicators.
events.playtika.com returning 200, with Cloudflare, HTTP/3, HubSpot, HubSpot CMS Hub, and LinkedIn Ads indicators.
octopus.playtika.com returning 200, titled Octopus Ad Manager.
Several hosts returning 301, 404, or Access Denied, which is still useful context during inventory building.

Caption: Capture representative lines from playtika_tech.txt showing status codes, titles, and technology fingerprints.

4. Review technology fingerprints

The identified technologies included:

Cloudflare and Cloudflare Bot Management
HTTP/3 and HSTS
Nginx and Varnish
Bootstrap, jQuery, jQuery UI, and Slick
HubSpot CMS Hub
Google Cloud/CDN and Platform.sh
Hugo 0.125.7
Nginx 1.22.0
OneTrust

Version clues are not vulnerabilities by themselves. They are useful for understanding the stack, checking documentation, and deciding where careful, authorized review may be appropriate.

5. Run conservative directory discovery with FFUF

I tested the main web host with FFUF using the SecLists common directory wordlist and matched common successful or redirect status codes:

ffuf -u https://ww.playtika.com/FUZZ \
  -w /usr/share/seclists/Discovery/Web-Content/common.txt \
  -Mmc 200,204,301,302,307,308 \
  -o playtika_dirs.json -of json

The recorded scan used 40 threads, a 10-second timeout, and completed 4,750 wordlist requests without errors.

Caption: Capture FFUF’s URL, wordlist, matcher, thread count, timeout, and completed scan summary.

I also ran a second pass with a smaller directory-focused wordlist:

ffuf -u https://ww.playtika.com/FUZZ \
  -w /usr/share/seclists/Discovery/Web-Content/common_directories.txt \
  -mc 200,204,301,302,307,308 \
  -o playtika_dirs2.json -of json

Caption: Capture the second FFUF command using common_directories.txt and its completed run.

The important result was negative: these FFUF scans did not produce additional matching directories in the recorded work. That does not prove that no other paths exist; it only describes what these wordlists and response filters found.

6. Check robots.txt and sitemap.xml directly

Public metadata files often reveal useful navigation information without brute forcing. I checked their status and final URL first:

curl -s -o /dev/null -w "%{http_code} %{url_effective}\n" \
  https://ww.playtika.com/robots.txt

curl -s -o /dev/null -w "%{http_code} %{url_effective}\n" \
  https://ww.playtika.com/sitemap.xml

Both returned HTTP 200.

Caption: Capture the two curl checks showing successful responses for robots.txt and sitemap.xml.

I then read their contents:

curl -s https://ww.playtika.com/robots.txt
curl -s https://ww.playtika.com/sitemap.xml

The robots file pointed to the sitemap. The sitemap exposed paths including:

/careers/
/get-to-know-us/
/games/
/life-at-playtika/
/in-the-press/
/press-releases/
/careers/security-it/
/careers/data-science/
/careers/research-development/

The paths most worth reviewing next were /careers/, /games/, /get-to-know-us/, /press-releases/, and /careers/security-it/. The next safe step would be to inspect links, forms, parameters, JavaScript references, and access controls without attempting to bypass them.

7. Crawl URLs and application routes with Katana

To discover links and client-side resources exposed through the web application, I crawled the main host with Katana:

katana -u https://www.playtika.com -silent -o playtika_katana.txt

Caption: Capture the Katana command and representative URLs returned by the crawl.

The crawl produced 1,330 unique URLs:

sort -u playtika_katana.txt | wc -l

Caption: Capture the deduplication/count command and the 1330 result.

I also filtered the collected URLs for JavaScript resources:

sort -u playtika_katana.txt | grep -Fi '\.js' | head -50

The results included JavaScript from contactus.playtika.com, news.playtika.com, Cloudflare Rocket Loader, OneTrust, jQuery, Bootstrap, Slick, and other application resources. JavaScript files can reveal route names and integration points, but they should be treated as clues for authorized review—not as an invitation to probe unrelated services.

Caption: Capture the filtered list of .js resources, including application-hosted and third-party scripts.

The most notable application paths were under contactus.playtika.com, including login, SSO, password-reset, and other .do routes. The later summary identified examples such as:

/contact
/amb_login.do
/login_locate_sso.do

These routes were considered interesting because authentication and account-recovery workflows are security-sensitive, not because their names alone demonstrate a flaw.

8. Build an AI-assisted wordlist from observed terms

I extracted terms from the discovered subdomains by removing the base domain, splitting on dots and hyphens, and sorting unique values:

cat playtika_subdomains.txt \
  | sed 's/\.playtika\.com//g' \
  | tr '.-' '\n' \
  | sort -u > playtika_terms.txt

wc -l playtika_terms.txt

The initial file contained 297 terms. I then filtered it to clean alphabetic/underscore-style entries:

grep -E '^[a-zA-Z][a-zA-Z0-9_]*$' playtika_terms.txt \
  | sort -u > playtika_clean_terms.txt

wc -l playtika_clean_terms.txt
head -50 playtika_clean_terms.txt

The cleaned file contained 290 terms.

Caption: Capture the commands producing playtika_terms.txt, the count of 297, and representative extracted terms.

Caption: Capture the filtering command, the count of 290 cleaned terms, and the beginning of the cleaned list.

The prompt used for organization was intentionally restrictive:

You are assisting with authorized bug-bounty reconnaissance for an in-scope wildcard target: *.playtika.com.

Below is a list of terms extracted from discovered subdomains:
[insert the contents of playtika_clean_terms.txt]

Create a clean, categorized reconnaissance wordlist using only terms supported by the provided data.

Categories:
1. API/authentication
2. Administrative/management
3. Development/staging
4. Web/content
5. Cloud/infrastructure
6. Game/application-specific
7. General useful terms

Remove obvious noise, duplicates, and meaningless fragments.
Do not invent organization-specific terms that are not supported by the input.
Return only the categorized wordlist.

Useful categorized entries included:

API/authentication: account, api, auth, capi
Administrative/management: admin, analystday, award, center, automation, achievements, challenges
Development/staging: alpha, beta, builds, ci, ce
Web/content: blog, assets, cdn, chat
Cloud/infrastructure: aws, accelerator, ams, autoconfig, autodiscover, cert, analytics
Game/application-specific: bestfiends, bingo, bingoblitz, blitz, bonus, card, caesarsgames
General: app, android, ads, bot, addub, cc

The AI did not discover a new subdomain or endpoint solely from this wordlist. Its practical value was organization and prioritization of evidence already collected.

9. Prioritize the attack surface without exploiting it

Combining host names, live status, technology clues, and crawled routes produced a practical priority list.

Priority	Asset	Why it stood out
High	`contactus.playtika.com`	Authentication, SSO, password-reset, and `.do` routes were observed
High	`api.playtika.com`	Clearly identified API endpoint
High	`prod-api-epayments.playtika.com`	Explicitly payment-related production API hostname
High	`preprod.playtika.com`	Pre-production environment
High	`events.playtika.com`	Live application with identifiable HubSpot and Cloudflare technology
Medium	`www.playtika.com`	Main web application with detailed technology fingerprint
Medium	`shop.playtika.com`	Live commercial web application
Medium	`news.playtika.com`	Live content application with several JavaScript technologies
Medium	`one-prod.playtika.com`	Production-related service hostname
Medium	`octopus.playtika.com`	Live application identified as Octopus Ad Manager

Manual review broadly agreed with this AI-assisted prioritization. The strongest recurring signals were authentication, APIs, payment-related naming, production/pre-production separation, and the size of the URL corpus.

How to Verify

Readers reproducing this workflow should use a target they own or a program that explicitly permits the activity.

Confirm the target, wildcard rules, exclusions, rate limits, and reporting requirements.
Install the exact tool versions available in your environment: Subfinder, httpx-toolkit, FFUF, Katana, and SecLists.
Run Subfinder and verify that the output file contains one hostname per line.
Use sort -u and wc -l to reproduce the deduplicated subdomain count.
Probe only in-scope hosts with httpx-toolkit and save the live list.
Compare playtika_tech.txt with the recorded status codes, titles, and technology indicators.
Run FFUF conservatively, keep the thread count and matchers documented, and inspect the JSON output rather than assuming every redirect is a real directory.
Request robots.txt and sitemap.xml directly and compare the listed paths.
Crawl the authorized main host with Katana, then run sort -u ... | wc -l to verify the URL count.
Extract terms only from observed hostnames, apply strict cleaning, and ensure the AI prompt forbids invented entries.
Review the final inventory manually. A priority label is a hypothesis for further authorized review, not proof of a vulnerability.

What I Learned

I learned that reconnaissance is most useful when it is treated as a chain of evidence rather than a collection of disconnected tool outputs. Subfinder showed the breadth of the namespace, httpx-toolkit separated names from reachable web services, and Katana connected those services to real application paths and JavaScript resources.

The sitemap was also a good reminder that straightforward sources can be more valuable than aggressive guessing. FFUF did not add matching directories in this work, while robots.txt and sitemap.xml exposed meaningful content paths.

The AI step was helpful, but not magical. It organized observed terms and highlighted sensible categories; it did not produce a new asset. I also came away with a stronger appreciation for scope checking and documentation. A host that looks interesting is still out of bounds if the program does not include it.

Common Mistakes

Mistake	Why It Happens	How to Fix
Treating every discovered hostname as authorized	Enumeration reveals names outside the actual program boundary	Check every asset against the published scope before probing it
Counting duplicate subdomains or URLs	Multiple sources and crawl paths produce repeated entries	Use `sort -u` before counting
Assuming a live host is a vulnerability	A `200`, `301`, or identifiable technology only proves reachability or exposure	Record it as an observation and perform only permitted follow-up checks
Interpreting version disclosure as an exploit	Version strings feel more conclusive than they are	Validate context and avoid exploit attempts unless explicitly authorized
Over-trusting FFUF results	Wordlists, filters, redirects, and wildcard responses can distort output	Compare status, size, title, and baseline responses; review JSON results
Ignoring `robots.txt` and sitemaps	They look too ordinary to be security-relevant	Read them early as low-impact sources of application paths
Using AI to invent names	A model may fill gaps with plausible-looking terms	Provide observed data only and require evidence-backed output
Treating login or password-reset paths as proof of weakness	Sensitive functionality is interesting but not automatically insecure	Document the route and stop at authorized, non-destructive verification
Running scans too aggressively	High concurrency can affect availability and violate program rules	Use conservative settings, respect rate limits, and monitor errors

Conclusion

A repeatable reconnaissance workflow can turn a broad wildcard into a structured inventory without crossing into exploitation. In this exploration, Subfinder identified 447 unique subdomains, httpx-toolkit found 95 live HTTP/HTTPS hosts, and Katana collected 1,330 unique URLs. Technology fingerprinting, sitemap review, and JavaScript filtering added context that raw hostnames could not provide.

The most valuable outcome was not a single “magic” finding. It was the combined picture: which services exist, which ones respond, how they are built, where application paths are exposed, and which assets deserve careful authorized review. That is the foundation for responsible security testing.

I Set Up a Fake Internet to Catch a Trojan: Analyzing FlexenseActivator.exe

Khalif AL Mahmud — Tue, 25 Aug 2026 16:28:32 +0000

There's a malware trick I'd read about but never witnessed firsthand: a trojan that checks whether it's connected to the real internet before doing anything malicious. If it detects a sandbox — no internet, wrong hardware, a debugger slowing it down — it goes quiet.

So for a graduate malware analysis project, I decided to give it a real internet. A fake one.

This is a walkthrough of how I analyzed FlexenseActivator.exe — a trojan disguised as a software activation tool — inside a fully isolated two-VM lab. I'll explain what the malware does, how I caught it doing it, and what any of this means for defenders.

⚠️ Safety note: All analysis was conducted in isolated virtual machines with no internet access. A REMnux VM intercepted all network traffic. Nothing ran on a production system.

The Sample

File:    FlexenseActivator.exe
SHA-256: 18676ae2eaa48ac6037fa239d282acca0b6c7cd6c7d384abe6b5cd379f2c5e50
Family:  Trojan.Win32.Tiggre / Zpevdo
Packed:  UPX v0.89.6 (Delphi stub)
Score:   100/100 (Hybrid Analysis) | 33/76 AV vendors (VirusTotal)

This file is distributed inside pirated RAR and ZIP archives for Flexense disk management software — SysGauge, Disk Pulse Pro, Disk Savvy. Users download what they think is a crack tool. VirusTotal shows 151 tracked execution parent archives, all pirated Flexense software bundles. The infection vector is straightforward: software piracy.

The Lab Setup

Before touching the sample, I built an isolated environment:

┌─────────────────────────────────────┐
│         Host Machine                │
│  ┌─────────────┐  ┌──────────────┐  │
│  │ Windows 10  │  │   REMnux     │  │
│  │ Analysis VM │←→│ Gateway VM   │  │
│  │  (AV off)   │  │ INetSim 1.3.2│  │
│  │             │  │ FakeDNS      │  │
│  └─────────────┘  └──────────────┘  │
│     192.168.56.20   192.168.56.10   │
│         Host-only network only      │
└─────────────────────────────────────┘

INetSim simulates HTTP, HTTPS, and DNS services on the REMnux VM. FakeDNS redirects every DNS query the Windows VM makes to INetSim. So when the malware asks "am I connected to the internet?" — INetSim answers yes.

This matters because many modern trojans check for connectivity before acting. On a disconnected analysis machine, they stay dormant. You see nothing.

Phase 1: Static Analysis — What Is This Thing?

Before executing anything, I loaded the file into PEStudio.

The first number that caught my attention: entropy 7.916.

Entropy measures byte randomness on a scale from 0 to 8. Normal executables land between 5 and 7. Packed or encrypted content pushes above 7.5. At 7.916, this binary is almost maximally random — direct evidence of a packer.

PEStudio confirmed: UPX v0.89.6 (Delphi stub). The actual malicious code is compressed inside and only appears in memory at runtime.

The PE sections told the same story:

Section	Raw Size	Entropy	What It Means
UPX0	0 bytes	0	Empty placeholder — payload unpacks here
UPX1	328,704 bytes	7.93	Compressed actual payload
.rsrc	95,744 bytes	7.71	Resources (unusually high entropy)

UPX0 has zero raw size but 790KB virtual size. That's the decompression target — empty on disk, filled at runtime.

One more detail: the binary's compiler timestamp is 2019, but the resource section timestamp is 2011. The icons and cursors were borrowed from an older Delphi project. This is a common fingerprint — malware authors recycle legitimate application templates to make binaries look more credible.

VirusTotal cross-check: 33/76 vendors detected it. The 43 who missed it are exactly why packing works.

Phase 2: Dynamic Analysis — Watching It Run

With Process Hacker open, I launched the sample.

It immediately appeared highlighted in pink — Process Hacker's color for suspicious processes. Windows Security fired a threat notification even with Defender mostly disabled. The process lived for a few seconds, did its work, and terminated. It doesn't stay resident. It sets things up and leaves.

Process Monitor captured everything during that window. Within the first second: 6 threads created simultaneously. UPX-packed malware often launches parallel threads — one to decompress, one to inject, one to handle network.

The GoogleUpdater Disguise

The most sophisticated behavior: the malware drops a complete fake GoogleUpdater installation:

C:\Program Files (x86)\Google\GoogleUpdater\136.0.7079.0\
    ├── updater.exe
    ├── Crashpad\
    │   └── attachments\
    └── uninstall.cmd

C:\Program Files (x86)\Google\GoogleUpdater\137.0.7129.0\
    └── (same structure)

Two versions — 136 and 137 — dropped simultaneously. This is a persistence mechanism designed to survive removal attempts. If you delete one version, the other reinstates it.

Legitimate Google Update has one version directory. Multiple numbered Google1184, Google2872, Google2972 directories in Program Files are a strong indicator of compromise.

Process Injection × 5

The malware then injected its code into five separate GoogleUpdater processes — each launched with --update --system --enable-logging flags that mimic the real Google Update service signature.

It also injected into WMIADAP.EXE (WMI Activity Performance Data).

After injection: the malware terminated all the injected processes, plus svchost (WerSvcGroup) and wmiadap. It cleaned up its injection targets. Its code was already running inside Windows processes — it no longer needed the hosts.

Phase 3: Catching the Fake Internet Call

This is where INetSim paid off.

Once the malware confirmed it was in a (seemingly) live environment, it made an HTTP GET request:

GET /ncsi.txt HTTP/1.1
Host: www.msftncsi.com
User-Agent: Microsoft NCSI

NCSI is Microsoft's Network Connectivity Status Indicator — the system Windows uses to show the internet icon in your taskbar. By querying this URL and getting a 200 OK response, the malware confirms internet access before proceeding with any C2 activity.

INetSim's log:

[http_80_tcp] recv: GET /ncsi.txt HTTP/1.1
[http_80_tcp] info: Sending fake file configured for extension 'txt'
[http_80_tcp] send: HTTP/1.1 200 OK

FakeDNS showed the full domain redirect chain:

fakedns[INFO]: update.googleapis.com  -> 192.168.56.10
fakedns[INFO]: ctldl.windowsupdate.com -> 192.168.56.10
fakedns[INFO]: www.msftncsi.com       -> 192.168.56.10

Wireshark then captured TCP/443 connections to Microsoft CDN IPs — the malware was doing SSL certificate chain verification before attempting any real C2 communication. It checks the TLS infrastructure is legitimate before exposing itself.

In a real analysis sandbox without INetSim, all of this either fails silently or never triggers. The malware would appear to do nothing malicious.

Phase 4: A Look Inside with IDA Pro

The final step: loading the binary into IDA Pro to see the UPX decompressor stub's assembly.

The entry point at 0x512130 matched what both PEStudio and Hybrid Analysis reported — consistent across all tools, which is a good sign your analysis is clean.

The opening instructions are textbook UPX 3.x:

start:
    pusha                               ; save all registers
    mov  esi, offset dword_4C2EE0       ; point to compressed data
    lea  edi, [esi - 0xC1EEEh]         ; destination: UPX0 section
    mov  dword ptr [edi+0xD09F4h], 592F7785h  ; write decompression seed
    push edi
    xor  ebp, 0FFFFFFFFh               ; init CRC counter
    jmp  loc_51215A                     ; enter decompression loop

A full reverse engineering of the unpacked payload is the next step — that requires letting the process reach its OEP (Original Entry Point) in a debugger, then dumping memory. That's for the next analysis round.

MITRE ATT&CK Summary

Tactic	ID	What I Observed
Execution	T1204	User ran the file directly
Persistence	T1543/T1547	Fake GoogleUpdater installation + autostart
Privilege Escalation	T1055	Process injection into GoogleUpdater × 5
Defense Evasion	T1027	UPX packing + XOR-encoded config strings
Defense Evasion	T1497	RDTSC timing check — anti-debugger
Discovery	T1082/T1057	System info + process enumeration
C2	T1071	HTTPS to Microsoft CDN for cert verification

What Defenders Should Watch For

If you run a SOC or manage endpoints:

Multiple GoogleUpdater version directories in Program Files (x86)\Google\ — legitimate installs have one
GoogleUpdater processes launched with unusual session IDs or --enable-logging on non-Google machines
NCSI queries repeated at intervals — legitimate Windows checks this occasionally; malware polls it repeatedly
Unsigned executables in %TEMP% re-executing themselves
Entropy > 7.5 in scanned files — flag for manual review

The SHA-256 hash is your most reliable IOC: 18676ae2eaa48ac6037fa239d282acca0b6c7cd6c7d384abe6b5cd379f2c5e50

What I Learned

Setting up INetSim and FakeDNS taught me something I couldn't learn from just reading: malware is network-aware by design. Modern trojans don't just run — they check their environment, verify connectivity, validate TLS infrastructure, and only then proceed. A naïve sandbox catches none of this.

The NCSI check was the most elegant evasion technique I encountered. It's not suspicious on its own — Windows does it constantly. But watching a trojan use it as a readiness gate was a clear demonstration of how blending into normal system behavior is itself a form of defense evasion.

Full Technical Report + IOCs

Complete report with PEStudio output, Wireshark captures, IDA Pro screenshots, full IOC list, and ATT&CK mapping:

🔗 https://github.com/MalwareAnalysisLabs/malware-analysis-writeups

What's Next

Unpack the binary dynamically in x32dbg, dump memory at OEP
Reverse engineer the unpacked payload's main function
Attempt to decode the XOR-obfuscated config strings (2,/+0&7!4-)1# etc.)
Compare Tiggre family behavior across different campaign variants

What tools or techniques have you used for packed binary analysis? Drop a comment — I'm particularly curious about approaches to Delphi-compiled malware.

How I Analyzed NanoLocker Ransomware: A Beginner's Guide to Static & Dynamic Analysis

Khalif AL Mahmud — Tue, 25 Aug 2026 15:26:27 +0000

When I started my graduate program in Computer & Information Science, "malware analysis" sounded intimidating — reverse engineers with years of experience, arcane assembly code, and tools I'd never heard of.

Then I actually sat down and did it.

This post walks through how I analyzed NanoLocker ransomware (lansrv.exe) — a real, actively-detected malware sample — using publicly available tools. If you're a beginner trying to understand how malware analysis works in practice, this is for you.

⚠️ Disclaimer: This analysis was conducted in a controlled, isolated environment for educational purposes only. Never execute malware on a production machine.

What Is NanoLocker?

NanoLocker is a file-encrypting ransomware trojan from the nanolocker/rents/dynamer family. Despite being compiled in 2016, it was still being submitted to VirusTotal as recently as February 2026. That alone tells you something important: good evasion code has a long shelf life.

The sample I analyzed:

File Name : lansrv.exe (also NanoLocker.exe)
SHA-256   : 462e30eb9cf267315e5f39e4fec4cfff78b34a5f6ebf61bad06cdfd9cbe0a06a
File Size : 196.50 KB
Detected  : 59/71 AV engines (83.1%) on VirusTotal

The name lansrv.exe is intentional — it's designed to look like a LAN server service process. This is masquerading (MITRE T1036), and it's one of the first things to notice.

Step 1: Static Analysis — What's Inside the File?

Static analysis means examining the file without running it. I focused on three areas:

PE Section Entropy

Every Windows executable has sections. I checked entropy (randomness) values:

Section	Entropy	What It Means
`.text`	6.38	Normal — main code
`.rdata`	4.79	Normal — read-only data
`.data`	6.40	Normal — variables
`.rsrc`	4.82	178 KB — embedded payload

The .rsrc section at 178KB was the red flag. That's not normal for a 196KB executable. This section stores the embedded ransomware resources that get dropped on execution.

Imported DLLs

What DLLs a file imports tells you a lot about its capabilities:

DLL	Why Malicious?
`crypt32.dll`	Encryption — generating ransom keys
`ws2_32.dll`	Networking — C2 communication
`advapi32.dll`	Registry — persistence setup
`iphlpapi.dll`	Network adapter enumeration — sandbox detection

Seeing crypt32.dll + ws2_32.dll together in ransomware is a classic pattern: encrypt files locally, send the key to attacker's server.

Strings Extraction

From 334 total strings, some stood out immediately:

%LOCALAPPDATA%\lansrv.exe     → Persistence path
%LOCALAPPDATA%\lansrv.ini     → Encrypted config (87KB)
52.91.55.122                  → Hardcoded C2 server
C:\ransomware3.exe            → Self-reference (the dropper)
CoCreateInstance              → COM persistence evasion

Hardcoded C2 IPs in strings are a gift for defenders — block 52.91.55.122 at the firewall and you've cut off one communication channel.

Step 2: Dynamic Analysis — What Does It Actually Do?

Dynamic analysis means watching the malware execute in a sandbox. I used VirusTotal's dynamic analysis, Joe Sandbox, and Hybrid Analysis.

What Happened When It Ran

1. Environment Check First
Before doing anything malicious, NanoLocker checks:

CPU name (is this a VM?)
CPU clock timing (is execution being accelerated in a sandbox?)
Executes long sleep periods to outlast sandbox timeouts

This is why many samples show "clean" in quick sandbox scans — they just... wait.

2. Persistence Setup

Copies itself → %USERPROFILE%\AppData\Local\lansrv.exe
Config file   → %LOCALAPPDATA%\lansrv.ini (87KB encrypted)
Registry      → Boot/Logon Autostart (T1547)

Every reboot, it comes back.

3. Process Injection
NanoLocker injects into wuapihost.exe — a legitimate Windows Update process. This hides its activity inside a trusted process, making it harder to detect in task manager.

4. File Discovery & Encryption
Using shell32.dll, it enumerates user directories looking for documents, images, and personal files. It encrypts them and sends the decryption key to 52.91.55.122.

5. Network Communication
Six IPs contacted during execution:

IP	Port	Purpose
`52.91.55.122`	ICMP	Primary C2 — key exfiltration
`192.229.211.108`	80	Unencrypted payload download
`20.99.184.37/246`	443	Encrypted C2
`23.216.147.64/76`	443	Encrypted C2

Step 3: MITRE ATT&CK Mapping

Mapping behavior to MITRE ATT&CK transforms your analysis from "here's what it does" to "here's how it fits into known attacker patterns." This is what SOC teams and threat intel analysts actually use.

Tactic	ID	Behavior
Execution	T1204	User runs the file directly
Persistence	T1547	Boot/Logon Autostart
Priv. Escalation	T1055	Process injection
Defense Evasion	T1027	Obfuscated config strings
Defense Evasion	T1036	Masquerades as LAN service
Discovery	T1082	CPU/environment fingerprinting
C2	T1071	HTTPS over port 443
Impact	T1486	Data Encrypted for Impact

What I Learned

A few things genuinely surprised me:

1. 10-year-old malware is still relevant. NanoLocker uses evasion techniques that are still effective in 2026 — sleep-based sandbox evasion, process injection into trusted processes, COM+ manipulation. Understanding "old" malware teaches you fundamentals that still apply.

2. The name is part of the attack. lansrv.exe is designed to look like infrastructure software. If you saw it in Task Manager, would you think twice? Social engineering isn't just phishing emails — it's also how malware names itself.

3. Hardcoded IOCs are gold for defenders. The moment I saw 52.91.55.122 in the strings, that IP becomes a firewall rule. Simple static analysis produces actionable defensive intelligence.

4. MITRE ATT&CK bridges analysis and defense. Before this, ATT&CK felt abstract. After mapping NanoLocker's behaviors, I understand why it exists — it gives analysts and defenders a shared language.

Tools I Used

VirusTotal — Multi-AV scanning + behavioral analysis
Hybrid Analysis — Sandbox execution
PE analysis tools — Section/entropy inspection
MITRE ATT&CK Navigator — Framework mapping

Full Technical Report + IOCs

If you want the full analysis with all IOCs, PE section details, and complete ATT&CK mapping, I've documented everything on GitHub:

🔗 https://github.com/MalwareAnalysisLabs/malware-analysis-writeups

The repository includes the full PDF report, IOC lists in markdown format, and ATT&CK mapping table — ready to use for reference or learning.

What's Next

This was my first structured malware analysis. Next, I want to:

Run samples through Ghidra for actual disassembly
Try deobfuscating that C:!@I~wF: encoded config string
Compare NanoLocker's encryption implementation to other ransomware families

If you're also learning malware analysis, what tools or resources have helped you most? Drop a comment — I'm always looking for what to learn next.

Sysmon vs. auditd on Linux: What a Sandworm-Style Attack Actually Reveals

Khalif AL Mahmud — Mon, 24 Aug 2026 19:22:04 +0000

Disclosure: This article is a technical review and analysis of the following paper for my Computer System Security (CSS) course at PIEAS:
Joshua Keller, "Enhancing Linux Threat Detection: A Sysmon-Based Approach to Identifying Sandworm TTPs," SANS Institute, January 2026.
All experimental results, lab data, and findings referenced here belong to the paper's author. My contribution is the analysis, summary, and commentary.

Why This Paper Caught My Attention

Linux runs a lot of critical infrastructure — 78.3% of internet-facing web servers, and critical workloads for 72.6% of Fortune 500 companies. And attackers have noticed: Kaspersky reported a 130% year-over-year increase in Linux exploit attacks in Q1 2024 alone.

Yet most of the tooling, research, and community knowledge around endpoint detection still skews heavily toward Windows. Sysmon for Linux has existed since 2021, but there has been very little published research on how it actually performs against real APT-style activity.

This SANS paper by Joshua Keller addresses that gap directly — and the results are worth understanding if you work in, or are studying, Linux security.

What the Paper Does

The author ran a controlled, reproducible experiment: set up identical Ubuntu 24.04 servers, run the same 16-step Sandworm-style attack against each one, and then count what each logging configuration actually caught.

Three configurations were tested:

Tool	Ruleset	Purpose
Sysmon for Linux v1.4.0	Generic broad config	The "new" tool being evaluated
auditd v3.1.2	DISA STIG (Ubuntu 24.04)	Widely-used compliance baseline
auditd v3.1.2	Neo23x0 (community ruleset)	Detection-focused alternative

The attack was modelled on MITRE's ATT&CK evaluation for Sandworm — a well-documented APT group attributed to Russia's GRU, responsible for attacks including the three-year Centreon intrusion disclosed by France's ANSSI in 2021.

Tools used by the paper's author: VMware Workstation Pro 17.6.2, MITRE Caldera (adversary emulation), Hydra (SSH brute-force), Elasticsearch + Kibana 8.14.3 for log analysis.

The Attack Chain

The simulated attack followed six broad stages across 16 steps:

1. Initial Access
SSH brute-force using Hydra against a weak credential (fherbert:horses). This is the noisiest stage — all three tools detected it.

2. Web Shell Deployment
Using the compromised credentials, a PHP web shell was uploaded to /tmp/ via SCP and then moved to the web root at /var/www/html/. Suspicious, detectable — if your logging is configured for it.

3. Discovery
Via the web shell, the attacker ran whoami, uname -a, ls -lsahR, and cat /etc/passwd using curl. These commands ran under the www-data user — which is not normal and is a strong indicator of web shell activity.

4. Execution & Privilege Escalation
A Sandcat agent (Sandworm's golang-based implant) was downloaded from the Caldera C2 server on port 8888, given executable permissions, and run via a SUID binary named /bin/backup. The outbound curl to a non-standard port is a detection opportunity.

5. Persistence
Two persistence mechanisms were established:

A crontab entry to run the agent every hour and on reboot
A fake systemd service file named syslogd.service — deliberately named to blend in

6. Credential Access
With root access via the agent, the attacker read /etc/shadow (all password hashes), .bash_history (which contained credentials added during setup), and SSH private keys.

What Each Tool Actually Saw

This is the part of the paper that matters most.

After Initial Access — DISA STIG Goes Nearly Blind

Once the attacker moved past the SSH brute-force, the DISA STIG auditd configuration generated almost no useful telemetry. It missed the web shell discovery commands, the agent download and execution, both persistence mechanisms, and the credential access stage entirely.

This is striking because DISA STIG is a regulatory standard — it represents what many organizations actually deploy on production systems.

Sysmon Caught Everything

Sysmon logged relevant events at every stage. A few examples from the paper's data:

Web shell detection: Sysmon Event ID 1 captured mv /tmp/search.php /var/www/html/ with the full command line, user (fherbert), and process executable.
Discovery stage: Event ID 1 captured sh -c -- whoami running under www-data — a clear web shell indicator.
Persistence: Event ID 11 logged the creation of the crontab temp file and the syslogd.service file.
Credential access: cat /etc/shadow, cat .bash_history, cat id_rsa — all captured with the user (root) and full command.

Total logs during the attack window: 996

Neo23x0 Also Caught Everything — But Louder

The community-maintained Neo23x0 auditd ruleset matched Sysmon's coverage across all stages. However, it generated 2,624 log entries — about 2.63× Sysmon's volume.

There's also a usability difference: auditd often splits event context across multiple log entries (e.g., the username in a syscall log, the command arguments in a proctitle log), which requires correlation. Sysmon consolidates this into a single event.

The Detection Comparison at a Glance

Attack Stage	Sysmon	auditd (DISA STIG)	auditd (Neo23x0)
Initial Access (SSH)	✅	✅	✅
Web Shell Deployment	✅	⚠️ Partial	✅
Discovery	✅	❌	✅
Execution / Agent Staging	✅	❌	✅
Persistence (cron + systemd)	✅	❌	✅
Credential Access	✅	❌	✅

Three Things Worth Taking Away

1. Compliance ≠ Security
The DISA STIG is a serious, widely-applied standard. But it was built for regulatory coverage, not detection. This paper demonstrates with actual log data that passing a compliance checklist does not mean your system can detect a real intruder.

2. The Log-to-Noise Tradeoff Is Real
Sysmon's 996 logs vs. Neo23x0's 2,624 logs isn't just a number — it's analyst time, SIEM ingestion costs, and alert fatigue. Detection capability matters, but so does the signal-to-noise ratio of what you're sending to your SIEM.

3. Sysmon Has a Genuine Advantage in Usability
For teams already familiar with Sysmon on Windows (and that number is growing, especially with Microsoft's announcement that native Sysmon functionality is coming to Windows in 2026), the Linux version offers a consistent rule syntax and consolidated event format. The barrier to adoption is lower than auditd for teams without deep Linux audit expertise.

One Notable Limitation

Sysmon does not capture SSH usernames via PAM. During the SSH brute-force stage, auditd's USER_AUTH and USER_LOGIN records included the targeted username (fherbert) directly. Sysmon only saw the connection spike — to determine the affected user, you'd need to correlate with SSH application logs.

This is a real gap for initial access investigation and worth knowing before deploying Sysmon as a sole detection layer.

My Takeaway from Reviewing This Paper

I reviewed this paper for my Computer System Security course at PIEAS, and wrote a structured summary report and class presentation based on it.

The thing that stayed with me is how concrete the paper is. It doesn't argue theoretically that Sysmon is better than auditd — it runs the same attack against both and counts the logs. That methodology is simple and reproducible, and the results are clear.

For anyone working toward a blue team or detection engineering role, this paper is a useful read. Not because Sysmon is a silver bullet, but because it illustrates how much detection capability is left on the table when logging is configured for compliance rather than for visibility.

Resources

My summary report and class presentation slides: https://github.com/Computer-System-Security/linux-threat-detection-sysmon-review/
Original SANS paper: Joshua Keller, SANS Institute Reading Room, January 2026
MITRE ATT&CK Sandworm evaluation: https://attackevals.github.io/ael/enterprise/sandworm/
Neo23x0 auditd ruleset: https://github.com/Neo23x0/auditd
Sysmon for Linux: https://github.com/microsoft/SysmonForLinux

This article is a review and analysis written as part of CSS coursework (MS in Cyber Security, PIEAS). All experimental findings referenced here are from the original SANS paper by Joshua Keller.

AI-Driven OSINT & Active Recon: How Artificial Intelligence Is Changing Reconnaissance

Khalif AL Mahmud — Mon, 24 Aug 2026 15:28:10 +0000

Reconnaissance has always been the first real step in any security assessment — long before anything else happens, someone has to figure out what's actually out there. Social footprints, website details, DNS records, media authenticity — all of it starts with information gathering.

What's changed recently is how much artificial intelligence is now part of that process. I spent some time going through five core areas of AI-driven OSINT and active reconnaissance — social media, websites and geolocation, DNS and network recon, deepfake detection, and fully automated recon pipelines — and wanted to write up what I learned about how AI is changing the way this work gets done, along with where it still needs a human double-checking it.

Problem Statement

AI is increasingly built into OSINT tooling, promising faster data collection and analysis across social media, websites, images, and network infrastructure. But faster isn't the same as accurate, and automated doesn't mean unsupervised. Understanding where AI genuinely helps in reconnaissance — and where its results still need human judgment — is the gap this post works through.

1. Social Media OSINT (SOCMINT)

SOCMINT means collecting and studying information that people share publicly on social media — posts, comments, photos, and profile details. Analysts use it to understand a person, a group, or an ongoing situation without hacking anything, since the data is already public.

Social media profiling is building a picture of someone by putting together different pieces of their online activity — posts, followers, likes, location tags, and writing style. Over time, this can reveal habits, interests, and even daily routines.

Where AI helps: AI can scan huge amounts of posts and comments much faster than a human, spot patterns across accounts, group similar topics together, and automatically pull out useful details like names, places, or dates. This saves a lot of manual reading and searching.

AI-powered sentiment analysis is when AI reads text and decides whether the tone is positive, negative, or neutral. On social media, it's used to see how people feel about a topic, brand, or event by looking at thousands of posts at once.

The risk: AI can misread sarcasm, slang, or context and give a wrong conclusion about someone's intent or opinion. If that wrong result is trusted blindly, it can lead to unfair judgments about a real person.

2. Website OSINT & Geolocation

Website OSINT is gathering public information about a website — things like who registered the domain, what technology it runs on, its hosting server, and old versions of the site. All of this comes from open, legal sources.

GEO Location OSINT is the process of figuring out where a photo, video, or post was made by studying visible clues in it, such as street signs, buildings, mountains, or shadows, along with any location data attached to the file.

How metadata helps: many photos secretly store metadata (EXIF data) like GPS coordinates, the camera model, and the exact time the photo was taken. If this data hasn't been removed, it can point almost directly to where the picture was taken.

How AI assists: AI can compare a photo against millions of images to find visual matches, recognize landmarks, read text in signs, and even guess a general region based on the landscape, buildings, or vegetation shown.

The limitation: AI can guess wrong when a place looks similar to many other locations around the world, or when the image has very few unique landmarks. The result is often a suggestion, not a guaranteed answer, and still needs human confirmation.

3. DNS & Network Recon

Nslookup is a command-line tool used to check the DNS records of a domain, mainly to find out which IP address a website name points to.

Dig is a more detailed DNS lookup tool. It shows extra information such as mail server records, name servers, and response times, which makes it more useful for deeper DNS checks than Nslookup.

DNS reconnaissance means collecting information about a domain's DNS setup — its IP addresses, subdomains, and mail servers — to understand how a target's network is structured.

DNS enumeration is the process of finding as many subdomains, hostnames, and DNS records connected to a domain as possible, usually with automated tools that try common names or search public records.

Why it matters: DNS information can reveal hidden parts of a network, like test servers or admin panels, which are not obvious from just visiting the main website. This helps build a full map of a target's online infrastructure.

4. AI Deepfake Detection

A deepfake is a fake image, video, or audio clip created by AI that makes it look or sound like a real person said or did something they never actually did.

AI-powered deepfake detection is the use of AI models to check whether a piece of media is real or artificially generated, by looking for small technical flaws left behind during the fake creation process.

How AI identifies manipulation: AI looks for tiny signs that are hard for humans to notice, such as unnatural blinking, odd lighting on the face, blurred edges around the face, or mismatched shadows and reflections.

Why manual verification matters: deepfake detection tools can still make mistakes, especially with high-quality fakes or low-quality real videos. A human should always double-check the result before treating it as final proof, since a wrong call can seriously harm someone's reputation.

5. Automated Recon Pipelines

An automated reconnaissance pipeline is a set of recon tools and steps linked together so that scanning, data gathering, and reporting happen automatically one after another, instead of an analyst running each tool by hand.

An AI recon agent is a program that can plan and run reconnaissance steps on its own, deciding what to search or scan next based on what it finds, with little to no human input during the process.

How AI agents automate OSINT workflows: AI agents can trigger multiple tools in order, like running a DNS lookup, then searching social media, then checking a website, and automatically combine the results into one organized report.

Benefits: it saves a lot of time, covers more ground than manual work, reduces small human errors, and can run continuously to catch new information as soon as it appears.

Risks: automated tools can accidentally scan systems that were never approved, collect more data than needed, or produce inaccurate results that get trusted without a proper human review.

Why authorized targets only: scanning or collecting data on a system without permission is illegal in most places, even if the tool is automated. Getting proper authorization first protects both the analyst and the organization from legal trouble.

How to Verify

Compare Nslookup and Dig results for the same domain and confirm you can explain the extra fields Dig returns
Check whether a photo you took yourself still has its EXIF/GPS metadata intact
Run a sentence with sarcasm through a sentiment analysis tool and see if it gets misclassified
Confirm authorization/scope before treating any recon target — automated or manual — as fair game

What I Learned

Working through this helped me understand how deeply AI has become part of modern OSINT and reconnaissance work. AI tools make data collection and analysis much faster, but they are not perfect and can produce wrong results if used without human judgment. I also realized how important it is to only perform reconnaissance on authorized targets, since even automated tools can cross legal boundaries if used carelessly. Overall, this gave me a clearer picture of both the power and the responsibility that comes with using AI in cybersecurity.

Common Mistakes

Mistake	Why It's a Problem	Better Approach
Trusting AI sentiment analysis as fact	Misses sarcasm, slang, and context	Treat it as a signal, not a verdict
Assuming an AI geolocation guess is confirmed	Similar-looking places cause false confidence	Cross-check against metadata and multiple visual clues
Using only Nslookup for DNS recon	Misses mail records, name servers, response details	Use Dig alongside it for a fuller picture
Treating deepfake detection results as final proof	Detection tools can still be wrong on tricky media	Always have a human verify before acting on the result
Running automated recon without checking authorization	Can scan systems that were never approved	Confirm authorization and scope before any automated scan
Letting an AI recon agent run fully unsupervised	Can escalate scope or trust bad results without review	Keep human review in the loop at each stage

Conclusion

AI hasn't replaced the reconnaissance analyst — it's sped up the collection and first-pass analysis while making human judgment more important than ever. Whether it's reading sentiment, guessing a location, spotting a deepfake, or running an automated pipeline, the same pattern holds: let AI handle the scale, keep a human on the verification, and never skip authorization. That balance is what actually makes AI-assisted OSINT reliable.

Hidden in Plain Sight: Steganography, EXIF Geolocation, and AI-Powered Log Analysis

Khalif AL Mahmud — Mon, 24 Aug 2026 15:00:19 +0000

A few weeks back I went down a rabbit hole that started with one simple question: how easy is it, really, to hide a secret inside an ordinary-looking JPEG — and how would a defender ever catch it?

That question turned into a full weekend project covering two very different but connected corners of security work: steganography (hiding and finding secrets inside media files) and log analysis (finding the story hidden inside thousands of boring log lines). Along the way I leaned on AI tools to speed up both the detection and the analysis side, which turned out to be the most interesting part of the whole exercise.

This post walks through everything I did — extracting a hidden message from an image, pulling GPS coordinates out of EXIF metadata, running an AI-assisted steganalysis scan, and finally using an AI assistant to triage 10,000 lines of Apache access logs for suspicious activity.

Problem Statement

Two questions I wanted real, hands-on answers to:

Can hidden data inside an image actually be detected and extracted reliably — and can AI meaningfully help with that detection?
When you're staring down a huge pile of raw system or web server logs, can AI actually speed up finding the anomalies, or is it just noise?

The best way to answer both was to just do it: hide/extract data myself, run it through an automated steganalysis pipeline, then separately dig through real authentication logs and a public Apache access log dataset.

Step-by-Step Walkthrough

1. Extracting a hidden message with Steghide

steghide is a classic LSB (Least Significant Bit) steganography tool — it embeds a file inside an image or audio file by making tiny, visually imperceptible changes to pixel data. Extraction is just the reverse of that process.

Given a suspicious image (mons.jpg), extraction looked like this:

steghide extract -sf /home/khalif/Desktop/mons.jpg
Enter passphrase:
the file "secret.txt" does already exist. overwrite ? (y/n) y
wrote extracted data to "secret.txt".

You can also point it at a specific output path with -xf:

steghide extract -sf /home/khalif/Desktop/mons.jpg -xf /home/khalif/Desktop/secret.txt
Enter passphrase:
wrote extracted data to "/home/khalif/Desktop/secret.txt".

And then just read it:

cat secret.txt
Every secure system is just undiscovered weak logic.

2. Pulling the exact location from EXIF metadata

Images from phones often carry a lot more than pixels — camera make/model, timestamps, and sometimes precise GPS coordinates, all sitting quietly in the EXIF header. exiftool makes this trivial to pull out:

exiftool /home/khalif/Desktop/picture.jpg

Buried in the output were the geolocation fields:

GPS Latitude    : 25 deg 43' 56.97" N
GPS Longitude   : 89 deg 15' 22.66" E
GPS Position    : 25 deg 43' 56.97" N, 89 deg 15' 22.66" E

This is a good reminder for anyone sharing photos online: metadata can leak far more than people realize, and it takes one command to pull it back out.

3. AI-assisted steganalysis with Aperi'Solve

Manually trying every steganalysis technique against a suspicious file gets old fast, so I ran the same image through Aperi'Solve, a web-based tool that automates a whole pipeline of steganalysis checks — bit-plane decomposition, zsteg-style extraction, steghide, outguess, jsteg, jpseek, metadata inspection, and more — all in one pass.

The results confirmed what I already knew from the manual extraction, but automatically:

Decomposer / bit-plane analysis — ran successfully, showing the superimposed color-channel breakdown
Steghide module — flagged Success and independently extracted the same secret.txt file
Jsteg — reported no hidden data (correctly, since the image wasn't encoded with that method)
Outguess — failed to extract (also expected, wrong technique for this file)

This is where AI/ML genuinely earns its keep in steganalysis: instead of manually running six different tools against every suspicious file, an automated pipeline (and increasingly, CNN-based classifiers trained on stego vs. clean images) can flag which files deserve a closer human look, at scale.

4. Practicing log analysis fundamentals

Before touching real data, I worked through two hands-on labs to build a mental model of what "normal" log activity looks like versus a genuine compromise:

Log fundamentals — logging sources, formats, standards, centralization, retention, and hands-on filtering practice
Windows incident investigation — tracing an actual breach through Windows event logs: identifying the attacker's foothold, a malicious scheduled task, credential dumping via Mimikatz, the external C2 IP address, a webshell dropped through a vulnerable upload endpoint, and even DNS poisoning targeting a legitimate domain

Working through a real (simulated) breach start-to-finish made it obvious how much of incident response is just pattern recognition across timestamps — which set up the next part perfectly.

5. Building a timeline from my own system logs

Next I turned to my own Kali VM and filtered journalctl for anything security-relevant:

sudo journalctl --since "2026-08-08" | grep -Ei "failed|failure|authentication|invalid|sudo|session opened|session closed" | tail -100

Scanning the filtered output, one sequence stood out:

01:08:45 - Password check failed for user khalif
01:08:45 - PAM reported authentication failure
01:08:49 - xfce4-screensaver: setuid failed: Operation not permitted

I laid the surrounding events out as a timeline:

Time	Observed Event	Analysis
01:08:45	Password check failed for user	Authentication anomaly detected
01:08:45	PAM reported authentication failure	Confirms the failed authentication
01:08:49	setuid operation failed	Permission-related system error
01:09:01	Root CRON session opened and closed	Routine automated activity
01:09:34	User executed a command via sudo	Administrative activity
01:11:37	User accessed apt history log via sudo	Related to investigation
01:12:41	User ran journalctl via sudo	Related to investigation

Important nuance: a failed login plus a setuid error doesn't automatically mean "attacker." It's just as likely to be a mistyped password followed by an unrelated desktop-session hiccup. I flagged it as anomalous and worth a second look, not as confirmed malicious activity — that distinction matters a lot in real incident response, where over-alerting burns analyst trust just as fast as under-alerting does.

6. Turning an AI assistant loose on 10,000 log lines

For the second half of the log analysis, I grabbed a public sample Apache access log (10,000 entries) and uploaded it straight to an AI assistant with a simple prompt: analyze this for anomalies and suspicious activity.

The model parsed all 10,000 entries and came back with a structured breakdown covering status code distribution, top requesting IPs, User-Agent patterns, HTTP methods, and known-bad URL signatures. It surfaced three genuinely interesting findings:

Coordinated CMS admin-panel scanning — repeated hits on /wp-login.php and /administrator/index.php from multiple IPs, all with blank User-Agent strings (a classic automated-scanner fingerprint)
A vulnerability scan targeting the FCKeditor file-upload exploit — an old but still commonly probed-for vulnerability
Repeated failed requests from an automated client pointing at a missing file — this one turned out to be a misconfiguration, not an attack, once the requesting client was identified

Every one of the suspicious requests returned a 403 or 404, meaning none of the scans actually succeeded — but the pattern-matching itself, done in seconds across 10,000 lines, is exactly the kind of triage work that would take a human analyst a lot longer to do by hand.

How to Verify

If you want to reproduce any of this:

Steghide extraction — install with sudo apt install steghide, then run steghide extract -sf <image> on a known stego-embedded file.
EXIF metadata — install with sudo apt install libimage-exiftool-perl, then run exiftool <image> and check for GPS Latitude / GPS Longitude fields.
Aperi'Solve — upload any image at aperisolve.com and check which modules return "Success" versus "No result."
journalctl filtering — adjust the --since date and the grep -Ei pattern to match your own system's timestamps, then confirm the flagged lines correspond to real login attempts (last -f /var/log/wtmp is a good cross-check).
AI log triage — grab any public Apache/Nginx access log sample, upload it to an AI assistant, and compare its flagged IPs/paths against a quick manual grep for wp-login, admin, or .php in the same file.

What I Learned

Working through both halves of this project side by side made the connection between them a lot clearer than I expected. Steganography and log analysis are really the same underlying skill wearing two different outfits: finding a meaningful signal buried inside a huge amount of ordinary-looking noise. Whether that noise is pixel values in a JPEG or ten thousand HTTP requests, the workflow is the same — narrow the field with automated tooling, then apply human judgment to what's left.

The other big takeaway was about calibration. AI tools are genuinely fast at flagging candidates — a suspicious image, a burst of failed logins, a scanning pattern in a log file — but they're not a verdict machine. The "anomalous, not confirmed malicious" framing I used for my own auth logs is the right default posture, and it's one I plan to carry into any future investigation work.

Common Mistakes

Mistake	Why It's a Problem	Better Approach
Assuming a failed login = an attack	Password typos and session glitches happen constantly	Cross-reference multiple log sources before concluding malicious intent
Only running one steganalysis tool	Different embedding techniques need different detection tools	Run a multi-tool pipeline (or an automated one) so no single blind spot slips through
Ignoring EXIF metadata on shared images	Photos can leak precise GPS location without anyone realizing	Strip metadata (`exiftool -all=`) before sharing sensitive images publicly
Treating every AI-flagged anomaly as confirmed	Automated flags are a starting point, not a conclusion	Always validate AI findings against raw log evidence before acting
Skipping a proper timeline	Isolated log lines are hard to interpret out of context	Lay events out chronologically — the sequence often tells the real story

Conclusion

Hiding a message in an image and hiding an attack in a wall of logs turn out to require the exact same mindset: assume there's a signal in the noise, narrow it down systematically, and don't stop at the first tool's output. AI made both halves of this project noticeably faster — automated steganalysis pipelines and AI-assisted log triage both did in seconds what would've taken a lot longer by hand — but the actual judgment calls, like distinguishing "anomalous" from "confirmed malicious," still came down to careful, manual reasoning.

If you're getting into digital forensics or blue-team work, I'd genuinely recommend doing both halves of this exercise yourself — hide something in an image and try to find it, then pull a public access log and go hunting. It sticks a lot better than reading about it.

Cracking the Code: A Hands-On Journey Through Cryptography, Hash Cracking, and Post-Quantum Security

Khalif AL Mahmud — Sat, 08 Aug 2026 15:21:07 +0000

I've always been fascinated by the idea that a string of random-looking characters can hide something real — a password, a message, an identity. So I decided to spend some real hands-on time with cryptography: not just reading about it, but actually cracking hashes, exploring how AI is starting to change cryptanalysis, and thinking through what happens to encryption once quantum computers become practical.

This write-up walks through everything I explored — from classical ciphers like Caesar and Vigenère, to symmetric encryption (AES vs DES), to practical hash cracking with hashcat and john, and finally into asymmetric cryptography, RSA, and the NIST Post-Quantum Cryptography standards.

If you're getting into cybersecurity and want a practical feel for how this stuff actually works (not just textbook definitions), this should be a useful walkthrough.

Problem Statement

Encryption and hashing are everywhere — logins, banking, messaging — but most people (myself included, before this) treat them as a black box. I wanted to answer a few concrete questions:

How do classical ciphers actually work, and why are they broken so easily today?
What really separates a "secure" algorithm like AES from an obsolete one like DES?
Why do we salt passwords, and what does a salt actually prevent?
Can AI meaningfully speed up hash identification and cracking?
How does public/private key cryptography (RSA) work under the hood?
Why is quantum computing considered a real threat to today's encryption, and what is the industry doing about it?

To make this concrete, I set up a Kali Linux VM and worked through a batch of unknown hashes, identifying and cracking each one using real tools instead of just theory.

Step-by-Step Walkthrough

1. Setting Up the Environment

I used Kali Linux (in VirtualBox) with hashid, hashcat, and john the ripper — all pre-installed on Kali, plus the classic rockyou.txt wordlist.

First thing: the wordlist ships compressed and permission-locked, so it needs to be unzipped with elevated privileges:

cd /usr/share/wordlists
gunzip rockyou.txt.gz

If you hit a Permission denied error (very common), just escalate first:

sudo su
gunzip rockyou.txt.gz

2. Identifying Unknown Hash Types

Before you can crack a hash, you need to know what kind of hash it is. hashid is great for a quick first guess:

hashid '3580c9267518807d14803ab6821fa067b4dba1210a4148a243b9e9383bae6a1e'

For trickier or more ambiguous hashes, I also cross-checked against an online hash identifier tool, which gave confidence scores and useful context (e.g. "this format is most commonly seen in Windows AD/NTDS dumps").

3. Cracking with Hashcat

Once I had a working hash-mode guess, I saved the hash to a file and ran it against rockyou.txt:

echo 'PASTE_HASH_HERE' > hash1.txt
hashcat -m 1400 -a 0 hash1.txt /usr/share/wordlists/rockyou.txt

-m 1400 tells hashcat the hash type (in this case, SHA-256)
-a 0 means a straight dictionary attack

To see the cracked result:

hashcat -m 1400 --show hash1.txt

I repeated this same process for several hashes of different types — SHA-256, SHA-512, and raw MD5 — just swapping the -m mode number to match each algorithm.

4. Cracking Salted / bcrypt Hashes with John the Ripper

Not every hash plays nicely with hashcat's default modes, especially bcrypt. For those, john handled it well:

john hash5.txt --wordlist=/usr/share/wordlists/rockyou.txt

Bcrypt is intentionally slow (that's the point — it resists brute force), so this one took noticeably longer to crack than the SHA-based hashes. To reveal the result:

john hash5.txt --show

5. Practicing on TryHackMe's "Crack the Hash" Room

To push further, I worked through TryHackMe's Crack the Hash room ( https://tryhackme.com/room/crackthehash ) , which throws a mix of easy and progressively harder hashes at you — including salted hashes where the salt is given separately and has to be appended/prepended correctly before cracking.

This part really reinforced why salting matters: without knowing the exact salt and how it's combined with the password, even a correct wordlist guess won't produce a matching hash.

Digging Into the Theory

Classical Ciphers: Caesar & Vigenère

The Caesar Cipher just shifts every letter by a fixed number of positions. With only 25 possible shifts, it's trivial to brute-force.

The Vigenère Cipher improves on this by using a repeating keyword, so each letter of the plaintext gets a different shift value. It resists simple brute force, but a technique called Kasiski examination can still recover the key length by spotting repeated patterns in the ciphertext — and from there, the cipher falls.

AES vs DES

	DES	AES
Key size	56-bit	128 / 192 / 256-bit
Status today	Obsolete, crackable in hours	Industry standard
Used for	Legacy systems	Government & modern encryption

DES simply wasn't built for today's compute power. AES, especially at 256-bit, remains effectively unbreakable with current classical hardware.

Why Salting Matters

Without a salt, two users with the password password123 end up with identical hashes — which is exactly what precomputed rainbow tables exploit. A salt is a random value mixed in before hashing, so identical passwords produce completely different hashes, forcing an attacker to crack each one individually.

Where AI Fits Into Cryptanalysis

This was the part I found most interesting. AI isn't replacing traditional tools like hashcat — it's making the guessing smarter:

Predicting likely hash algorithms from structure/length faster than rule-based identifiers
Learning patterns from leaked password datasets to generate more realistic candidate passwords (common substitutions, suffix patterns, etc.) instead of pure brute force
Speeding up the reconnaissance phase in CTF-style challenges by identifying cipher/encoding types automatically

I also drafted a reusable prompt template for using an LLM to systematically break a Caesar Cipher — trying all 25 shifts, evaluating which output reads as real English, and clearly stating the result:

You are a cryptanalysis expert. I have an intercepted message that appears
to be encoded using a Caesar Cipher.

Encrypted message: [CIPHERTEXT HERE]

Please do the following:
1. Try all 25 possible shift values (1 through 25).
2. Show the decrypted output for each shift.
3. Identify which shift produces readable English text.
4. State the correct shift value and the final plaintext.
5. Briefly explain how you identified the correct decryption.

RSA and Public/Private Keys

RSA relies on a simple asymmetry in difficulty: multiplying two large primes is fast, but factoring the resulting product back into those primes is extremely hard. Anyone can encrypt a message with my public key, but only my private key can decrypt it — which is what makes secure communication over an untrusted channel possible in the first place.

The Quantum Threat

Two quantum algorithms change the picture:

Shor's Algorithm can factor large numbers exponentially faster than classical computers, which would break RSA outright if a sufficiently powerful quantum computer existed.
Grover's Algorithm effectively halves the strength of symmetric keys, so a 256-bit AES key would offer roughly the security of a 128-bit key against a quantum attacker.

That's why NIST ran a multi-year competition and, in 2024, finalized its first Post-Quantum Cryptography (PQC) standards — CRYSTALS-Kyber for key exchange/encryption and CRYSTALS-Dilithium (ML-DSA) for digital signatures, both based on lattice problems believed to resist quantum attacks.

How to Verify

If you want to reproduce any of this yourself:

Spin up a Kali Linux VM (or use any distro with hashcat, john, and hashid installed).
Download rockyou.txt and place it in /usr/share/wordlists/.
Save a hash to a .txt file, identify its type with hashid, then run the matching hashcat -m <mode> command.
Confirm the crack with hashcat --show or john --show.
Try TryHackMe's Crack the Hash room yourself for a structured, escalating challenge set.

What I Learned

Working through this hands-on rather than just reading about it changed how I think about "secure" systems. A few things stuck with me:

Cryptography is only as strong as its weakest implementation detail (looking at you, missing salts).
Hash cracking is really a wordlist-and-rules problem — the algorithm matters less than how predictable the underlying password is.
AI's real value right now is in speeding up identification and guessing, not magically breaking strong encryption.
Post-quantum cryptography isn't science fiction planning anymore — NIST already has finalized standards, and the migration is already underway in parts of the industry.

Common Mistakes Table

Mistake	Why It Happens	Fix
Guessing the wrong hashcat mode (`-m`)	Similar-length hashes (SHA-256 vs others) look alike	Cross-check with a hash identifier tool before running hashcat
Forgetting to unzip/permission-fix `rockyou.txt`	Wordlist ships compressed and root-owned on Kali	`sudo gunzip rockyou.txt.gz` before first use
Ignoring salts on salted hashes	Salt isn't hashed the same way in every format	Check the exact salt placement (prefix/suffix) required by that hash type
Assuming AES-256 is "quantum-proof"	AES resists Shor's Algorithm but not Grover's	Understand Grover only weakens AES, it doesn't fully break it
Treating AI hash-cracking as magic	AI still needs data patterns to learn from	Use AI to speed up identification/guessing, not as a silver bullet

Conclusion

Cryptography sits at the foundation of almost everything we trust online, and there's a real gap between knowing the definitions and actually being able to identify, crack, and reason about these systems hands-on. This exercise pushed me to close some of that gap — and it also made the post-quantum conversation feel a lot less abstract. If you're working through similar material, I'd genuinely recommend setting up a lab and cracking a few hashes yourself rather than just reading the theory.

What My Own Wi-Fi Traffic Looked Like Under Wireshark (And Why 88% of It Wasn't Even TLS)

Khalif AL Mahmud — Wed, 05 Aug 2026 15:43:19 +0000

I've used the internet every day for years without ever actually looking at what leaves my laptop when I open a webpage. So I decided to fix that: install Wireshark, capture a few minutes of completely normal browsing on my home Wi-Fi, and see what's really going on underneath.

What I found surprised me. I expected mostly HTTPS/TLS traffic. Instead, the biggest chunk of data wasn't TLS at all — it was a protocol I barely knew existed.

This post walks through the setup, what I captured, and the three things that changed how I think about "just browsing the web."

Problem Statement

The goal was simple: capture live traffic from a normal browsing session and actually understand it — not just glance at packet counts, but dig into protocols, DNS behavior, top talkers, and anything that looked off. Before this, Wireshark was just an icon I'd never clicked.

Step-by-Step Walkthrough

1. Getting Wireshark Running

I installed Wireshark on Windows 10 and let it install Npcap alongside it — without that driver, no network interfaces show up in the capture list at all. After a restart, I opened Wireshark and picked my Wi-Fi interface, since that was the only one showing live activity in the little traffic graph next to each interface.

2. Generating Some Normal Traffic

Before starting the capture, I closed every other app so the capture wouldn't get flooded with unrelated noise. Then I hit record and did a few ordinary things over 2–3 minutes:

Opened https://www.wikipedia.org over HTTPS
Opened http://neverssl.com on purpose, just to see what plain unencrypted traffic looks like
Ran a couple of terminal commands:

ping 8.8.8.8
nslookup github.com

Played a short YouTube video for about 15 seconds

Then I stopped the capture and saved it. The final file held 11,272 packets — way more than I expected from a few minutes of "light" browsing.

3. Breaking Down the Protocols

Instead of scrolling through thousands of rows one by one, I used:

Statistics → Protocol Hierarchy

This gives a percentage breakdown of every protocol in the capture, by both packet count and byte volume — which turned out to be the most important view in the whole exercise.

I expected most of the data to be standard HTTPS over TCP. Instead, when I checked the Percent Bytes column, almost 88% of all the data in the capture wasn't TLS/TCP — it was QUIC, a newer transport protocol that runs over UDP instead of TCP. YouTube and other Google services use it now instead of the classic TLS-over-TCP combo, mainly because it's faster to set up and handles packet loss better.

That also explained something odd: TCP accounted for a decent chunk of packets (13.4%) but almost no bytes (0.3%). Those were mostly handshake and acknowledgment packets — the real weight of the video traffic was moving through QUIC the entire time without me noticing anything different.

4. Looking at DNS Queries

To isolate just the questions my laptop was asking (not the responses), I used this filter:

dns.flags.response == 0

Some of the domains that showed up:

www.youtube.com
googleads.g.doubleclick.net
yt3.ggpht.com
en.wikipedia.org

What caught me off guard was that opening one YouTube video triggered lookups for six different domains within about 20 seconds: the main YouTube domain, a Google accounts domain, a thumbnail CDN, an ad-tracking domain, and the actual video CDN host. Most of these were CDNs and analytics services I never directly asked for.

My DNS server was my home router (192.168.1.1), and every query went out in plain text over UDP port 53. That means anyone on the same network — or my ISP — could see exactly which sites I was visiting, even though the sites themselves were encrypted over HTTPS.

5. Finding the Top Talkers

Next I checked:

Statistics → Conversations

Unsurprisingly, my own machine was in every conversation, but the heaviest single connection by far was the YouTube video CDN — video streaming pulls dramatically more data than loading a text-based page ever does.

6. Checking for Anything Unusual

I filtered for retransmissions with:

tcp.analysis.retransmission

A few things stood out:

A handful of retransmitted TCP segments, most likely from a weak Wi-Fi signal in my room
A batch of RST packets — mostly my own laptop tearing down idle keep-alive connections
Constant SSDP broadcast traffic from my router, plus an mDNS announcement from another device on the same network
Background traffic to Microsoft telemetry endpoints even though I wasn't running any Office apps

Nothing here looked malicious. But it was a solid reminder of how much a device "talks" in the background even when it feels idle.

How to Verify

If you want to reproduce this yourself:

Install Wireshark + Npcap and pick your active network interface
Start a capture, then browse normally for 2–3 minutes (mix of HTTPS, an unencrypted site, a DNS lookup, and some streaming)
Stop the capture and open Statistics → Protocol Hierarchy — check the Percent Bytes column, not just packet counts
Filter with dns.flags.response == 0 to see outbound DNS questions only
Open Statistics → Conversations to find your top talkers
Filter with tcp.analysis.retransmission to spot connection issues

What I Learned

Almost everything is encrypted now — but DNS and SNI still leak where you're going. HTTPS hides the content, not the destination.
A single page visit is never one connection. It's a dozen or more, quietly firing off to CDNs, trackers, and third-party services.
Filters are what make Wireshark usable. Without them, 11,000+ packets are just noise; with the right filter, the same data tells a clear story.

If I had more time, I'd capture traffic from a single specific app in isolation and compare how differently apps behave on the wire — especially privacy-focused apps versus ad-supported ones.

Common Mistakes

Mistake	Why It Trips People Up	Fix
Assuming HTTPS traffic is always TCP/TLS	QUIC (UDP-based) is now common for major services like YouTube and Google	Always check Protocol Hierarchy by bytes, not assumptions
Judging traffic volume by packet count	Packet count and byte volume tell very different stories (see TCP handshake vs QUIC video)	Sort by Percent Bytes, not Percent Packets
Skipping Npcap during install	Wireshark shows zero interfaces without it	Always let the installer add Npcap, then restart
Scrolling raw packet lists manually	Thousands of packets are unreadable without structure	Use Statistics menus and display filters from the start
Ignoring "idle" background traffic	Devices talk constantly even without active use	Check Conversations and DNS logs even during "quiet" periods

Conclusion

Before this, I thought of the internet as just "pages loading." After actually watching the packets, it feels more like a noisy background conversation that never really stops. Encryption protects what you're sending, but not where you're sending it — and that gap is exactly what tools like Wireshark make visible. If you've never opened it before, I'd genuinely recommend spending twenty minutes capturing your own traffic. It's a strangely eye-opening exercise.

Building My First LAN in Cisco Packet Tracer: Connecting 4 PCs Through a Switch

Khalif AL Mahmud — Sun, 26 Jul 2026 19:13:42 +0000

Networking always felt like one of those "black box" topics to me — you know your laptop connects to Wi-Fi and somehow reaches the internet, but the actual mechanics of how devices talk to each other on a local network stay invisible. I decided to fix that by getting hands-on with Cisco Packet Tracer and building the simplest possible network from scratch: a handful of PCs, one switch, and enough IP addresses to make them all understand each other.

This post walks through exactly what I did, why each step matters, and how I verified the whole thing actually worked — not just looked right on screen.

Problem Statement

The goal was straightforward on paper: connect four computers to a single switch, give each one its own IP address, and confirm they can all reach each other over the network. Simple as that sounds, it forces you to actually understand a few core networking concepts:

Why you need a specific cable type to connect a PC to a switch
How IP addresses and subnet masks decide which devices can "see" each other
How to prove connectivity actually works, instead of just assuming it does

Tools Used

Cisco Packet Tracer
1x Switch (2960 series)
4x PCs
Copper Straight-Through cables

Step-by-Step Walkthrough

Step 1: Set Up the Devices

I opened Packet Tracer and dragged a 2960 switch into the middle of the workspace, then placed four PCs around it. Nothing connected yet — just laying out the topology first so I could see the shape of the network before wiring anything up.

Step 2: Cable Everything Together

This is where the "which cable do I use" question comes in. There are two main copper cable types in Packet Tracer: Straight-Through and Crossover. The rule of thumb is:

Different device types (PC ↔ Switch, PC ↔ Router) → Straight-Through cable
Same device types (Switch ↔ Switch, PC ↔ PC) → Crossover cable

Since I was connecting PCs to a switch — two different device types — a Straight-Through cable was the correct choice. I connected each PC's FastEthernet0 port to its own port on the switch:

PC0 → Switch Fa0/1
PC1 → Switch Fa0/2
PC2 → Switch Fa0/3
PC3 → Switch Fa0/4

After a few seconds, every link light turned green, which confirmed the physical layer connection was solid on all four links.

Step 3: Assign IP Addresses

With cabling done, the next job was making each PC addressable on the network. I went into each PC's Desktop → IP Configuration, switched to Static, and assigned the following:

PC	IP Address	Subnet Mask
PC0	192.168.1.1	255.255.255.0
PC1	192.168.1.2	255.255.255.0
PC2	192.168.1.3	255.255.255.0
PC3	192.168.1.4	255.255.255.0

The subnet mask is the important detail here. Using 255.255.255.0 on every PC keeps them all in the same 192.168.1.0 network, which is what allows them to talk to each other directly without needing a router. If the subnet masks didn't match, or the IPs landed in different subnets, the PCs would technically be cabled together but logically isolated — a good reminder that physical connection and network connection are two very different things.

How to Verify

Configuring IPs is one thing — proving they actually work is another. I opened PC0's Command Prompt and ran:

ping 192.168.1.2
ping 192.168.1.3
ping 192.168.1.4

Every single ping came back with a Reply from... response and 0% packet loss, which confirmed PC0 could reach PC1, PC2, and PC3 without any issues.

Pinging 192.168.1.2 with 32 bytes of data:
Reply from 192.168.1.2: bytes=32 time<1ms TTL=128
Reply from 192.168.1.2: bytes=32 time<1ms TTL=128
Reply from 192.168.1.2: bytes=32 time<1ms TTL=128
Reply from 192.168.1.2: bytes=32 time<1ms TTL=128

Ping statistics for 192.168.1.2:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss)

If a ping had failed, the next things I'd check are: cable type, whether the link light is actually green, whether the subnet masks match across devices, and whether I typo'd an IP address (it happens more often than you'd think).

What I Learned

This was a small setup, but it packed in a surprising number of fundamentals:

Switches operate at Layer 2 — they don't care about IP addresses to forward traffic within the same network, but the PCs still need valid IPs to communicate meaningfully above that layer.
Cable type matters more than I expected. Straight-Through vs. Crossover isn't just trivia — plugging in the wrong one (in real hardware, anyway) can mean no link light at all.
Subnet masks define the "neighborhood." Two devices can be cabled together perfectly and still fail to talk if their masks put them in different logical networks.
Ping is your best friend for verification. It's a simple command, but it's the fastest way to confirm connectivity actually exists rather than just looking correct visually.

Common Mistakes Table

Mistake	Why It Happens	Fix
Using a Crossover cable instead of Straight-Through	Mixing up when each cable type applies	Remember: different device types = Straight-Through
Mismatched subnet masks	Copy-pasting config without double-checking	Verify every PC uses the same mask if they should be on one network
Typo in IP address	Manual entry across multiple PCs	Double-check each octet before moving to the next PC
Assuming green link light = full connectivity	Confusing physical layer with network layer	Always confirm with `ping`, not just visual cues
Forgetting to set Static mode before entering an IP	DHCP is selected by default	Switch to Static first, then fill in the address fields

Conclusion

Building this tiny four-PC network was a great reminder that networking fundamentals aren't complicated once you actually build them out yourself instead of just reading about them. Cabling, addressing, and verifying — that's really the whole loop, and once it clicks, scaling up to routers, VLANs, and larger topologies feels a lot less intimidating.

Linux, Networking, Scripting, and AI: What Every Beginner Pentester Should Know

Khalif AL Mahmud — Fri, 17 Jul 2026 17:42:50 +0000

When I started digging deeper into cybersecurity, I quickly realized that almost everything in this field circles back to one operating system: Linux. Whether you're running a vulnerability scan, writing a quick automation script, or asking an AI tool to explain a weird output, Linux is the environment where it all happens.

I wanted to write down what I've learned so far in a way that's actually useful for someone just getting started — no fluff, just the stuff that matters.

Why Linux Dominates Cybersecurity

Linux is open-source, free, and highly customizable. Unlike Windows or macOS, it gives you full control over the system — down to the smallest configuration file. That level of control is exactly why almost every serious security tool is built for Linux first.

And within the Linux world, there's one distribution that stands out for security work: Kali Linux.

What Makes Kali Linux Special

Kali is a Linux distribution built specifically for penetration testing, maintained by Offensive Security. It comes preloaded with hundreds of tools covering:

Network scanning
Vulnerability assessment
Password testing
Digital forensics
Web application testing
Wireless security testing

Basically, if you're doing ethical hacking, Kali saves you the trouble of hunting down and installing every tool yourself.

Getting Comfortable With the Linux Filesystem

One of the first mental shifts coming from Windows is realizing there's no "C: drive." Everything starts from a single root directory: /.

A few directories you'll bump into constantly:

/home — where regular users keep their personal files
/etc — system and application configuration files
/var — logs, caches, and other data that changes often
/root — the home directory of the root (admin) user

Once that structure clicks, navigating any Linux system starts to feel natural.

The Commands You'll Actually Use Every Day

You don't need to memorize hundreds of commands to get productive. A small core set covers most of your daily work:

pwd                     # show current directory
ls                      # list files and folders
cd folder_name          # change directory
mkdir new_folder        # create a directory
touch file.txt          # create an empty file
cp source destination   # copy files
mv source destination   # move or rename files
rm file.txt             # delete a file
cat file.txt            # print file content

These feel small individually, but combined they let you move around, inspect, and manipulate a system faster than any GUI ever could.

Permissions: Read, Write, Execute

Linux controls access through three roles — owner, group, and others — and three permission types:

Read (4) — view or open a file
Write (2) — modify a file
Execute (1) — run it as a program or script

You change permissions with chmod, and most professionals prefer the numeric shorthand over the +x / +w style because it's faster and sets everything in one shot:

chmod 755 script.sh

That single command says: full control for the owner, read-and-execute for everyone else. Clean and quick.

Installing Software: apt and dpkg

Two commands handle almost all your software needs on Kali:

sudo apt update
sudo apt install nmap

apt pulls packages (and their dependencies) straight from repositories. When you already have a .deb file downloaded locally, dpkg installs it directly:

sudo dpkg -i package.deb

PATH and Environment Variables

Ever wonder how Linux knows where to find a program when you just type its name? That's the PATH variable at work — it's a list of directories the shell automatically searches.

echo $PATH

Environment variables in general are how the system and applications share small but important pieces of information, like usernames or language settings, without hardcoding them anywhere.

Networking Basics You Can't Skip

A few networking concepts show up constantly in security work:

IP address — the unique identifier of a device on a network
DNS — translates domain names like google.com into IP addresses
Gateway — the device (usually your router) that connects your local network to the internet

And the commands to actually see this in action:

ip a            # view IP address, interfaces, MAC address
ip route        # view gateway and routing info
ping google.com # test connectivity
traceroute facebook.com  # trace the path packets take

ping tells you if a host is reachable. traceroute shows you the hops your traffic takes to get there — genuinely useful when you're debugging connectivity or mapping out a network.

Scripting: Where Automation Begins

Once you're comfortable with commands, the next natural step is stringing them together. That's where Bash scripting comes in:

#!/bin/bash
echo "Hello From Khalif"

Save it, make it executable, and run it — congratulations, you've automated your first task.

Beyond Bash, Python is the real workhorse in cybersecurity. It's used for building network scanners, analyzing logs, automating repetitive tasks, and even developing full security tools. If you're serious about this field, learning Python isn't optional — it's foundational.

Where AI Fits Into All of This

This is the part that genuinely excites me. AI tools are starting to show up as real assistants in the pentesting workflow — not replacements for skill, but accelerators for it.

Tools like PentestGPT can help with:

Understanding vulnerabilities
Explaining confusing tool output
Suggesting the next step in an assessment
Writing commands and scripts
Drafting reports

AI is also increasingly used for threat detection, malware analysis, log analysis, intrusion detection, and phishing detection — anywhere there's a large volume of data that needs fast pattern-matching.

The Catch

AI isn't magic, and it definitely isn't infallible. It can:

Suggest incorrect commands
Miss context a human would catch instantly
Expose sensitive data if used carelessly
Lack the judgment and intuition a real analyst brings

That's why the right mental model is: AI is an assistant, not a replacement. It speeds up the boring parts and helps you learn faster, but the judgment calls — and the ethics — stay with the human.

Using AI Responsibly

A few ground rules I try to keep in mind:

Respect privacy, always
Never run unauthorized tests or attacks
Double-check AI-generated output before trusting it
Stay within legal and ethical boundaries
Treat AI as a co-pilot, not the pilot

Final Thoughts

None of this is groundbreaking on its own — Linux fundamentals, basic networking, a bit of scripting, and an intro to AI tools. But together, they form the backbone of how modern security work actually gets done. If you're starting out in cybersecurity, getting genuinely comfortable with these basics will take you further than jumping straight into flashy tools.

How Stuxnet Broke Into an "Offline" Nuclear Facility — Without Ever Touching the Internet

Khalif AL Mahmud — Fri, 17 Jul 2026 17:39:20 +0000

If you've spent any time in cybersecurity, you've probably heard the Stuxnet story thrown around as some kind of legendary tale. But here's the part that still trips people up: Iran's nuclear facility wasn't even connected to the internet. So how exactly did malware get in?

Turns out, "air-gapped" doesn't mean "unreachable." It just means attackers have to get a little more creative.

The Human Element Nobody Talks About Enough

Stuxnet didn't come in through some flashy remote exploit or a phishing email. It came in through a USB drive.

Somewhere along the line, an employee or contractor plugged in an infected USB drive into a computer at the facility. That's it. That was the entry point. No firewall to bypass, no network to breach — just a small piece of hardware crossing a physical boundary that no software defense could stop.

It's a good reminder that "air-gapped" systems are only as secure as the humans and removable media that interact with them. You can isolate a network from the internet, but you can't fully isolate it from people.

From One Machine to Industrial Sabotage

Once Stuxnet infected that first local machine, it didn't just sit there. It started spreading laterally through the internal network — the same kind of network segment that was supposed to be "safe" because it wasn't internet-facing.

Eventually, it found what it was looking for: the centrifuges' operating frequency. Stuxnet was specifically engineered to manipulate that frequency, causing physical damage to the equipment while feeding false readings back to operators so everything looked normal on the monitoring systems.

This is what made Stuxnet genuinely different from typical malware at the time. It wasn't just stealing data or crashing systems — it was reaching through code into the physical world and causing real, mechanical destruction. That crossover from digital to physical is a big reason Stuxnet is still studied as a landmark case in industrial control system (ICS) security.

A Quick Detour: What About Bloatware?

Slightly different topic, but worth a mention since it's related to system security hygiene: bloatware.

Bloatware refers to unnecessary pre-installed software that ships with a device — stuff you never asked for and rarely use. Beyond just eating up storage and system resources, bloatware quietly increases your attack surface. Every extra piece of software running on a machine is one more potential entry point for something to go wrong, whether that's a vulnerability, a misconfiguration, or just unnecessary background access to system resources.

It's a small thing, but it ties back to the same core lesson as Stuxnet: security isn't just about what's connected to the internet. It's about everything that has physical or logical access to a system — from USB drives to pre-loaded software nobody asked for.

The Takeaway

Stuxnet is a masterclass in why "isolated" systems still need serious security discipline. Air-gapping raises the bar, but it doesn't eliminate risk — it just shifts the attack vector from the network to the physical world. USB policies, endpoint monitoring, and controlling what touches your machines matter just as much as firewalls and network segmentation.

Over a decade later, it's still one of the best real-world examples of why defense-in-depth isn't optional.

Dark Web vs Dark Net vs TOR — Untangling Three Terms People Use Interchangeably

Khalif AL Mahmud — Thu, 16 Jul 2026 15:39:15 +0000

"Dark web," "dark net," and "TOR" get thrown around like they're all the same thing — usually in the same breath, usually with a slightly ominous tone. When I actually looked into it for this assignment, I realized they're related but distinct concepts, each describing a different layer of the same overall picture. Here's how I'd break it down.

Dark Web

The dark web is a hidden part of the internet that isn't indexed by search engines and is usually accessed through the TOR network. So when you Google something, you're searching the "surface web" or "deep web" (like your email inbox or a private database) — none of that touches the dark web at all.

The dark web exists to provide privacy, anonymity, and secure communication. It's mainly accessed through the TOR browser, and — this part surprised me — it was originally created to protect sensitive government and military communications, not for the reasons it's often associated with today.

Dark Net

The dark net is a private and anonymous network that hosts hidden websites and services. If the dark web is the content — the actual hidden sites and pages — the dark net is closer to the infrastructure underneath it, the network layer that makes accessing that hidden content possible in the first place.

Like the dark web, the dark net exists to provide anonymity, privacy, and secure communication, and it's accessed using special software such as TOR. It was also created originally to protect sensitive communications and support anonymous communication more broadly.

TOR

TOR (The Onion Router) is a network and browser used to hide a user's identity and location online. It's the actual tool that makes accessing the dark web and dark net possible for a regular person.

TOR exists to provide privacy, anonymity, and secure communication, and is accessed using the TOR browser. Same origin story as the other two: it was originally created to protect sensitive government and military communications, and was later released more broadly.

The name "onion router" isn't random, either — TOR works by routing your traffic through multiple layers of encrypted relays (like layers of an onion), so no single point in the chain knows both who you are and what you're accessing at the same time.

So how do these three fit together?

Here's the way I'd summarize the relationship:

TOR is the tool — the browser and network protocol that provides anonymity.
Dark net is the underlying network that hidden services run on, typically accessed via tools like TOR.
Dark web is the content layer — the actual hidden websites and pages that live on the dark net, reachable through TOR.

They all share the same core purpose (privacy, anonymity, secure communication) and largely overlap in practice, which is exactly why people use the terms so loosely. But technically, each one describes a slightly different piece of the same puzzle.

Worth remembering

None of these three technologies are inherently good or bad — they're neutral tools. The same anonymity that gets misused for illegal activity is also what protects journalists, whistleblowers, activists, and people living under oppressive surveillance regimes. Context is everything. Understanding what these terms actually mean (instead of just associating them with vague "scary internet" vibes) is a much more useful starting point than the popular narrative usually gives credit for.