DEV Community: Sanketh Subhas

I Built a Honeypot That Profiles Attackers and Maps Their Behavior to MITRE ATT&CK

Sanketh Subhas — Wed, 11 Mar 2026 02:46:59 +0000

Most security tools are defensive. They sit at the perimeter, wait for something bad to happen, and try to block it. A honeypot flips that logic entirely. Instead of blocking attackers, you invite them in, watch everything they do, and walk away with intelligence.
I wanted to understand what real attacker behavior looks like before it reaches production systems, so I built a Python-based honeypot that simulates SSH, HTTP, and FTP services, captures everything that touches those services, and generates a structured attacker intelligence report with every event mapped to MITRE ATT&CK.
Here is how I built it and what I learned.

The Problem with Passive Defense
Security teams spend most of their time defending known attack surfaces. Firewalls, IDS rules, SIEM alerts. The problem is that all of those tools respond to attacks. They do not teach you how attackers think, what credentials they try first, which vulnerabilities they probe before going deeper, or how a brute force attempt transitions into a web shell attempt.
Honeypots answer those questions. They are decoys with no legitimate users, so every connection is suspicious by definition. There is no noise to filter. Everything logged is an attack.
The gap I saw in most beginner honeypot setups is that they stop at logging. You get an IP address and a timestamp. I wanted something that went further: credential capture, behavioral pattern detection, attack type classification, and automatic MITRE ATT&CK mapping so the output was actually useful to a SOC analyst.

What I Built
The system runs three fake services simultaneously using Python's standard library only. No external dependencies, just socket, threading, json, re, and collections.
SSH on port 2222 accepts any connection and logs every username and password combination attempted. It never grants access. It just listens, captures, and flags IPs that exceed a brute force threshold.
HTTP on port 8080 handles incoming web requests and scans each one for attack signatures: SQL injection strings, web shell upload attempts, directory traversal patterns, admin panel probes, and general vulnerability scanning behavior.
FTP on port 2121 captures login attempts, flags anonymous login attempts, and detects default credential usage.
Every single event, regardless of service, gets mapped to a MITRE ATT&CK technique in real time. SSH brute force maps to T1110. Port scanning maps to T1046. SQL injection maps to T1190. Web shell attempts map to T1505.003. The full mapping table covers nine attack patterns across all three services.

The Intelligence Report
Logging raw events is useful. Summarizing them into an intelligence report is what makes a honeypot operationally valuable.
After a session ends, either via Ctrl+C on a live run or automatically after a simulation, the tool generates a report that shows:

Total events and unique attacker IPs
Brute force IP flags
Event breakdown by service, visualized as bar charts in the terminal
Top attacker IPs with their specific attack types listed
MITRE ATT&CK technique frequency across the session
Unique credential combinations attempted, with default credential flagging

The JSON logs that feed this report are structured to be SIEM-ready. They can pipe directly into Splunk, Elastic, or Microsoft Sentinel without transformation.

Here is a sample of what a session report looks like:

  HONEYPOT ATTACKER INTELLIGENCE REPORT

=================================================================
Total Events : 31
Unique Attackers: 7
Brute Force IPs : 2

EVENTS BY SERVICE
SSH ████████████████ 16
HTTP ████████████ 12
FTP ███ 3

TOP ATTACKER IPs
45.33.32.156 10 events | sql_injection, web_shell_attempt, database_probe
203.0.113.42 9 events | ssh_login_attempt, port_scan [BRUTE FORCE]

MITRE ATT&CK TECHNIQUES OBSERVED
T1110 Brute Force 9x
T1046 Network Service Scanning 8x
T1190 Exploit Public-Facing Application 3x
T1505.003 Web Shell 1x

CREDENTIALS ATTEMPTED (11 unique)
admin : admin [DEFAULT CRED]
root : password
pi : raspberry

Demo Mode
One thing I built specifically for testing and demonstrations is a --simulate flag. Running python3 honeypot.py --simulate --report generates a full simulated attack session without needing live internet traffic or exposed ports. It runs through SSH brute force, HTTP probing, FTP anonymous login attempts, and port scanning behavior, then generates the full report.
This means anyone cloning the repo can see exactly what the tool does in under 30 seconds without any infrastructure setup.

What This Looks Like in Practice
Deploy this on an AWS EC2 instance or DigitalOcean droplet with the ports exposed to the internet. Within hours, you will see real traffic. Bots and automated scanners hit open ports constantly. What you capture tells you a lot:

The most commonly attempted SSH credentials globally are still admin:admin, root:password, and pi:raspberry. Default credential hygiene matters.
HTTP scanners probe for /admin, /wp-login, /.env, and SQL injection strings before any human has looked at your site.
Brute force attempts rarely come from a single IP. Distributed credential stuffing is the norm.

All of that becomes structured threat intelligence when it runs through this tool.

Technical Design Decisions
A few choices I made deliberately:
Standard library only. No pip installs, no dependency conflicts, no version issues. The tool runs on any Python 3 environment out of the box.
Threading per service. Each fake service runs on its own thread so SSH, HTTP, and FTP capture simultaneously without blocking each other.
Threshold-based brute force detection. Rather than flagging every failed login, the tool tracks attempt counts per IP and raises a brute force flag only after a configurable threshold is crossed. This mirrors how real SOC alert rules work.
ATT&CK mapping at the event level. Instead of tagging sessions with a technique at the end, each individual event carries its ATT&CK technique ID as it is logged. This makes the data immediately usable for threat hunting queries.

Takeaways
Building this project reinforced something I keep coming back to: defenders who understand how attackers operate are better at their jobs. A honeypot is not just a trap. It is a training dataset for your threat model.
The credential lists alone are valuable. Seeing T1046 show up before T1190 in a session tells you that the attacker scanned for services before attempting exploitation. That sequencing is exactly what ATT&CK is designed to capture.
If you are building out a SOC capability or studying for a blue team role, I would strongly recommend deploying a honeypot, even a simple one, and spending time reading the logs. The patterns you see will show up again in your SIEM.

Links
GitHub: honeypot-attacker-intelligence
Portfolio: sankethsubhas.pages.dev
Questions or feedback? Drop them in the comments. If you have deployed a honeypot and captured interesting traffic patterns, I would like to hear what you saw.

How I Built a MITRE ATT&CK Threat Mapping Dashboard in Python

Sanketh Subhas — Mon, 09 Mar 2026 17:24:04 +0000

Mapping attack indicators to adversary techniques without any external libraries

When I started studying for SOC analyst roles, I kept running into the same gap: I could identify that something was malicious, but I couldn't systematically connect it to where it sat in an attacker's kill chain. That's exactly what MITRE ATT&CK solves and exactly why I built this tool.

The Problem
Security logs are noisy. A single incident can generate hundreds of events failed logins, encoded PowerShell commands, outbound beacons, lateral movement attempts. The challenge isn't detecting that something happened. It's answering what stage of the attack is this? How severe? What else might be coming next?
That's the job of ATT&CK mapping. And doing it manually during an incident is slow and error-prone.

What I Built
The MITRE ATT&CK Threat Mapping Dashboard is a Python CLI tool that takes any input a log file, raw text, or a built-in attack scenario and maps it to MITRE ATT&CK tactics and techniques automatically.
Here's what it produces:

Kill chain visualization : a live view of which of the 14 ATT&CK tactics are active
35+ technique mappings across all tactic stages
Severity ratings — CRITICAL / HIGH / MEDIUM / LOW per technique
JSON export — machine-readable output for SIEM integration (Splunk, Elastic, Sentinel)

And the entire thing runs on Python's standard library — re, json, argparse, collections. No pip installs. No dependencies. Just clone and run.

How It Works
The core of the tool is a technique signature database. Each ATT&CK technique (T-number, name, tactic, severity, description) is paired with a set of regex patterns — keywords and indicators that suggest that technique is present.
When you pass input to the tool, it runs every signature against the text and returns matches with their tactic context and severity.
pythonpython3 mitre_mapper.py --scenario ransomware
python3 mitre_mapper.py --file /var/log/auth.log
python3 mitre_mapper.py --text "mimikatz powershell encoded cobalt strike"
python3 mitre_mapper.py --scenario apt --output report.json


The kill chain output makes it immediately clear which attack stages are active:

▶ Credential Access ██ T1110, T1003
▶ Lateral Movement █ T1021
▶ Command and Control █ T1071
▶ Impact █ T1486
A blank stage means no indicators detected. A filled stage means something matched — and you can drill into exactly what.

ATT&CK Coverage
The tool covers all 14 Enterprise ATT&CK tactics:
TacticSample TechniquesInitial AccessPhishing, Valid Accounts, Remote ServicesExecutionPowerShell, Scheduled Tasks, User ExecutionPersistenceAutostart, Web Shells, Account CreationCredential AccessMimikatz, Brute Force, MITMLateral MovementEternalBlue, SMB, Remote ServicesImpactRansomware, Data Destruction, Service Stop
...and 9 more tactics with full technique coverage.

The Three Built-in Scenarios
I added three pre-built attack scenarios so you can see the tool in action without needing a live log file:
Ransomware — maps credential dumping, encryption, C2 beaconing, and lateral movement. Produces 10 technique matches across 9 tactics.
APT (Advanced Persistent Threat) — simulates a nation-state style intrusion with reconnaissance, spearphishing, privilege escalation, and long-term persistence.
Web Attack — covers SQL injection, web shell deployment, reverse shell activity, and data exfiltration via HTTP.
Each scenario is designed to reflect real-world attack patterns documented in MITRE's threat actor profiles.

Why This Matters for SOC Work
This project directly mirrors what analysts do during triage:
Threat hunting — you paste a suspicious log snippet and immediately see which ATT&CK techniques are present, instead of manually cross-referencing the framework.
Incident response — when an incident is active, the kill chain view tells you what stage the attacker is at and what's likely coming next.
SOC triage — severity ratings (CRITICAL down to LOW) let you prioritize which detections need immediate attention vs. monitoring.
Purple team exercises — red team operators can map their own activity to ATT&CK and hand it to blue team as a detection coverage checklist.
SIEM integration — the JSON export flag (--output report.json) produces structured output that feeds directly into Splunk, Elastic, or Sentinel pipelines.

What I Learned
Building this forced me to actually read the ATT&CK framework in depth — not just know it exists, but understand how tactics relate to each other sequentially, how techniques nest under tactics, and how real-world indicators map to T-numbers.
The regex-based approach also taught me something practical: most ATT&CK indicators in logs aren't subtle. mimikatz, encoded command, your files have been encrypted — attackers leave fingerprints. The skill is knowing where to look and what it means when you find it.

Try It Yourself
GitHub: github.com/SankethSubhas/mitre-attack-threat-mapper
bashgit clone https://github.com/SankethSubhas/mitre-attack-threat-mapper.git
cd mitre-attack-threat-mapper
python3 mitre_mapper.py --scenario apt
All 8 of my open-source cybersecurity tools are on my portfolio at sankethsubhas.pages.dev

How I Built a Python Network Scanner That Thinks Like an Attacker

Sanketh Subhas — Sun, 08 Mar 2026 23:09:01 +0000

Open ports are open doors. Here's how I built a tool that finds them, scores the risk, and maps every finding to MITRE ATT&CK with zero external dependencies.
The Problem
Every network has blind spots.
Firewall rules get misconfigured. Services get spun up and forgotten. A developer opens port 3389 for "just a quick test" and never closes it. Six months later, a ransomware group finds it.
The scary part? These exposures are trivially easy to find if you know where to look.
So I built a tool that looks.

What the Tool Does
The Network Scanner & Vulnerability Reporter is a Python-based tool that:

Scans a target IP or entire CIDR range for open ports
Identifies what service is running on each port
Checks each service against a built-in vulnerability database
Maps every finding to a MITRE ATT&CK technique
Calculates an overall risk score from 0–100
Generates a full report with remediation guidance
Exports JSON for SIEM or ticketing system integration

Zero external dependencies. Pure Python standard library only.

Why I Built It This Way
Most vulnerability scanners are black boxes. You run Nessus, get a PDF, and hand it to someone else to interpret.
I wanted to understand what's actually happening under the hood what a scanner is really asking, what the responses mean, and how to turn raw port data into something actionable.
This tool is my answer to that question.

The Technical Architecture
Port Scanning — Multithreaded TCP
The scanner uses socket and concurrent.futures.ThreadPoolExecutor to send TCP connection attempts across 29 common ports simultaneously. Multithreading keeps the scan fast even on full CIDR ranges.
pythonwith ThreadPoolExecutor(max_workers=50) as executor:
futures = {executor.submit(scan_port, ip, port): port for port in ports}


Each connection either succeeds (port open) or times out (closed/filtered). No raw packets, no root required.

**Service Identification**

Open ports get mapped to known service names via a static dictionary — port 22 becomes SSH, port 445 becomes SMB, port 3389 becomes RDP, and so on across 29 services.

**Vulnerability Matching**

Each identified service is checked against a built-in vulnerability database. This isn't CVE scanning it's risk pattern matching. Port 23 open? That's Telnet — cleartext protocol, CRITICAL risk. Port 27017 open? That's MongoDB — likely unauthenticated access.

The database covers the services that actually show up in breach reports: SMB (EternalBlue), RDP (ransomware entry), Redis (no-auth data exposure), Elasticsearch (unauthenticated access), and more.

**MITRE ATT&CK Mapping**

Every vulnerability finding gets tagged with the relevant ATT&CK technique:

- RDP exposed → T1076 (Remote Desktop Protocol)
- SMB exposed → T1210 (Exploitation of Remote Services)
- Telnet open → T1040 (Network Sniffing)

This transforms raw scan output into adversary-aligned intelligence — exactly the framing a SOC or threat intel team needs.

**Risk Scoring**

The tool calculates a composite risk score 0–100 based on the severity and count of findings:

| Score | Rating |
|-------|--------|
| 70–100 | 🔴 CRITICAL |
| 45–69 | 🟠 HIGH |
| 20–44 | 🟡 MEDIUM |
| 0–19 | 🟢 LOW |



**Sample Output**

=================================================================

NETWORK SCANNER & VULNERABILITY REPORTER

Target : 192.168.1.1
Open Ports : 4 | Vulnerabilities: 6
Risk Score : 85/100 [██████████████████████████████████░░░░░░]

Rating : 🔴 CRITICAL RISK

⚠️ VULNERABILITIES (6)

[CRITICAL] RDP Exposed to Internet (Port 3389)
MITRE ATT&CK : T1076 — Remote Desktop Protocol
Remediation : Restrict RDP to VPN only, enable NLA, use MFA

[CRITICAL] SMB Port Exposed (Port 445)
MITRE ATT&CK : T1210 — Exploitation of Remote Services
Remediation : Block SMB at firewall, apply MS17-010 patch

Real-World Relevance
This maps directly to what security teams actually do:
Attack surface mapping — finding exposed services before attackers do is the first step in any vulnerability management program.
Risk prioritization — not every open port is equal. This tool scores and ranks so the most dangerous exposures get fixed first.
SIEM integration — the JSON export can feed directly into Splunk, Elastic, or any ticketing system like ServiceNow.
Compliance support — regular network scans are a control requirement under NIST CSF, CIS Controls, and ISO 27001. This tool produces the evidence.

What I Learned
Building this taught me things no certification course covers:
Multithreading changes everything. A single-threaded scanner on a /24 range would take minutes. With 50 concurrent threads, it's seconds. Understanding thread pool sizing and timeout tuning is a real skill.
The vulnerability database is the hardest part. Writing port-scanning logic is straightforward. Deciding which services are risky, why, and how to explain it to a non-technical stakeholder — that's the GRC thinking that makes a security tool actually useful.
MITRE ATT&CK is a communication framework. Mapping findings to ATT&CK techniques isn't just for show. It lets you speak the same language as threat intel teams, red teams, and incident responders. A finding labeled "T1210 — Exploitation of Remote Services" means something specific and actionable to anyone in the security space.

Try It Yourself
bashgit clone https://github.com/SankethSubhas/network-scanner-vulnerability-reporter.git
cd network-scanner-vulnerability-reporter

Scan a single host (use scanme.nmap.org for legal testing)

python3 network_scanner.py scanme.nmap.org

Scan a network range

python3 network_scanner.py 192.168.1.0/24

Export JSON report

python3 network_scanner.py 192.168.1.1 --output report.json
Only scan systems you own or have explicit written permission to test.

Links

🔗 GitHub: network-scanner-vulnerability-reporter
🌐 Portfolio: sankethsubhas.pages.dev
💼 LinkedIn: linkedin.com/in/sanketh-subhas

How I Built a Phishing Email Analyzer That Scores Risk 0–100

Sanketh Subhas — Sun, 08 Mar 2026 01:20:56 +0000

A hands-on walkthrough of email header analysis, SPF/DKIM/DMARC validation, and phishing detection using pure Python

Introduction
Phishing is still the number one initial access vector in cyberattacks. According to virtually every major threat report, over 90% of successful breaches start with a phishing email. Yet most people — and even some security teams — still rely on gut feeling to decide if an email is suspicious.
I wanted to change that. So I built a Python tool that analyzes raw email files, checks every technical indicator, and produces a scored risk verdict from 0 to 100. No gut feeling required.
This article walks through exactly how it works, what it checks, and why those checks matter.

What Does the Tool Actually Do?
The Phishing Email Analyzer takes a raw .eml email file as input and runs it through a series of checks across four categories:

Header analysis (From, Reply-To, Return-Path mismatches)
Authentication validation (SPF, DKIM, DMARC)
Content analysis (urgency keywords, credential requests, suspicious links)
Attachment analysis (double extensions, executable disguises)

Each indicator adds points to a risk score. At the end, the tool returns a color-coded verdict:

0–30: Likely Legitimate
31–60: Suspicious
61–80: High Risk
81–100: Critical — High Probability Phishing

The Technical Foundation: What is an .eml File?
An .eml file is the raw format of an email. It contains everything — headers, body, attachments — all in plain text. Every email client can export emails in this format, which makes it perfect for forensic analysis.
Python's built-in email library can parse .eml files natively, which means the entire tool runs with no external dependencies beyond the standard library.

The Checks — And Why They Matter

Header Mismatch Detection Legitimate emails have consistent headers. The From address, Reply-To address, and Return-Path should all point to the same domain. When they don't — that's a red flag. Attackers frequently use a display name like "PayPal Security" while the actual sending address is noreply@paypa1-security.xyz. The tool extracts all three headers and flags any domain mismatch immediately.
SPF, DKIM, and DMARC Validation These three protocols are the backbone of email authentication:

SPF (Sender Policy Framework) — verifies that the sending server is authorized to send on behalf of the domain
DKIM (DomainKeys Identified Mail) — verifies that the email content hasn't been tampered with in transit using a cryptographic signature
DMARC — ties SPF and DKIM together and tells receiving servers what to do if either check fails

The tool checks the Authentication-Results header — which is added by the receiving mail server — for pass/fail status on all three. A legitimate email from a major organization will almost always pass all three. A phishing email often fails one or more.

URL and Link Analysis The tool extracts every URL from the email body and checks for:

URL shorteners (bit.ly, tinyurl, etc.) — used to hide the real destination
Suspicious TLDs (.xyz, .tk, .ml) — popular with attackers because they are cheap or free
IP addresses used directly in links — no legitimate organization sends links like http://185.220.101.34/login
Lookalike domains — domains that visually resemble trusted brands (paypa1.com, amaz0n.net)

Urgency and Credential Request Keywords Phishing emails almost universally use psychological pressure. The tool scans the email body for phrases like "your account will be suspended," "verify immediately," "click here to confirm your password," and similar patterns. Each match increases the risk score.
Attachment Analysis Malicious attachments often disguise themselves using double extensions — invoice.pdf.exe looks like a PDF but executes as a program. The tool checks every attachment filename for this pattern and flags executable file types hidden behind document extensions.

Running It
The tool is simple to use. Download a suspicious email as a .eml file and run:
python3 phishing_analyzer.py suspicious_email.eml
The output shows every check with a pass/fail result and explains why each indicator matters, followed by the final risk score and verdict.

Test Results
I included two sample emails in the repository to demonstrate the contrast:
The phishing sample — a fake PayPal security alert — scored 100/100. It triggered 13 indicators including a From/Reply-To domain mismatch, failed SPF, URL shorteners, urgency keywords, and a credential request.
The legitimate sample — a standard professional email — scored 0/100. Every header was consistent, no suspicious URLs, no urgency language.
The contrast makes the tool's value immediately clear.

What I Learned
Building this tool gave me a much deeper understanding of why email authentication protocols exist and how attackers work around them. Most phishing emails don't try to bypass SPF or DKIM — they just rely on the fact that most people never check those headers manually. Automating those checks removes the human error factor entirely.
It also reinforced something important about SOC work: the difference between a trained analyst and a beginner is often just knowing what to look for. This tool encodes that knowledge into a repeatable process.

Try It Yourself
The full source code, sample emails, and README are available on GitHub:
GitHub: https://github.com/SankethSubhas/phishing-email-analyzer

Sanketh Subhas is a Cybersecurity Analyst with 3.5+ years of experience in SOC operations, GRC, and threat detection.
Portfolio: sankethsubhas.pages.dev | GitHub: github.com/SankethSubhas

How I Built a SQL-Driven User Access Review & Compliance Audit

Sanketh Subhas — Fri, 06 Mar 2026 18:32:45 +0000

Introduction

One of the most common findings in a compliance audit is simple: the wrong people still have access to systems they shouldn't. Terminated employees. Sales reps with admin rights. Accounts that haven't been touched in months.
This is exactly what a GRC Analyst is hired to catch and in this project, I built a SQL-based User Access Review (UAR) to simulate a real audit workflow.

The Scenario
Imagine you're a GRC Analyst at a mid-sized company. The IAM (Identity and Access Management) policy says:

Terminated employees must have database access revoked within 24 hours
Only IT and DevOps staff can hold Admin privileges (Principle of Least Privilege)
Any account inactive for 90+ days is considered stale and must be disabled

Your job: write SQL audit queries to find every policy violation.

Step 1 — Building the Mock Database
I created a simple user_access table with intentional policy violations baked in:
sqlCREATE TABLE user_access (
user_id INT,
name VARCHAR(50),
department VARCHAR(50),
role VARCHAR(20),
status VARCHAR(10),
last_login DATE,
termination_date DATE
);

INSERT INTO user_access VALUES (101, 'Alice Smith', 'IT', 'Admin', 'Active', '2026-02-01', NULL);
INSERT INTO user_access VALUES (102, 'Bob Jones', 'Sales', 'Admin', 'Active', '2026-01-15', NULL);
INSERT INTO user_access VALUES (103, 'Charlie Brown', 'HR', 'User', 'Terminated', '2025-12-01', '2025-12-05');
INSERT INTO user_access VALUES (104, 'David Wilson', 'Marketing', 'User', 'Active', '2025-08-20', NULL);
Three violations are hiding in plain sight — can you spot them?

Step 2 — The Audit Queries
Audit 1: Zombie Accounts — Terminated employees still with active access
sqlSELECT name, department, termination_date
FROM user_access
WHERE status = 'Terminated' AND termination_date IS NOT NULL;
Finding: Charlie Brown (HR) was terminated on Dec 5, 2025 — access never revoked. High Risk.

Audit 2: Privilege Escalation Check — Non-IT/DevOps users with Admin rights
sqlSELECT name, department, role
FROM user_access
WHERE role = 'Admin' AND department NOT IN ('IT', 'DevOps');
Finding: Bob Jones (Sales) has Admin privileges. Violates Principle of Least Privilege. Medium Risk.

Audit 3: Stale Account Detection — No login in 90+ days
sqlSELECT name, department, last_login,
JULIANDAY('now') - JULIANDAY(last_login) AS days_inactive
FROM user_access
WHERE status = 'Active'
AND JULIANDAY('now') - JULIANDAY(last_login) > 90;
Finding: David Wilson (Marketing) hasn't logged in since August 2025 — over 180 days inactive. Medium Risk.

Step 3 — The GRC Executive Summary
This is what separates a security project from a GRC project. The code is just the tool. The report is the deliverable.

Audit Finding Report — Q1 2026
Finding 1 (High Risk): One terminated employee (Charlie Brown, HR) retains active database access 90+ days post-termination. Immediate remediation required.
Finding 2 (Medium Risk): One active employee (Bob Jones, Sales) holds Admin privileges without business justification. Violates Principle of Least Privilege.
Finding 3 (Medium Risk): One active account (David Wilson, Marketing) has been inactive for 180+ days. Account should be disabled pending review.
Recommendation: Implement an automated trigger between the HR system and the database to disable accounts within 24 hours of termination. Conduct quarterly access reviews for all Admin-level users.

What I Learned
This project taught me how GRC work actually flows in practice — you don't just find vulnerabilities, you document them, assign risk levels, and recommend remediations that a business can act on. The SQL is almost secondary. The report is the real output.
If you're breaking into GRC, I'd strongly recommend building something like this. It's concrete, demonstrable, and directly mirrors what compliance teams do every day.

Links

🔗 GitHub: github.com/SankethSubhas/sql-user-access-review
🌐 Portfolio: sankethsubhas.pages.dev

This is part of my open-source cybersecurity portfolio — 8 projects built to demonstrate real GRC and SOC skills.

I Built a CIS Benchmark Compliance Checker That Works on Both macOS and Linux

Sanketh Subhas — Thu, 05 Mar 2026 20:25:43 +0000

Security hardening is one of those things everyone talks about but few actually implement consistently. The CIS Benchmarks exist for a reasonthey’re the gold standard for OS-level security configuration. So I built a tool that actually checks your system against them, automatically, on both macOS and Linux.

What it does

The CIS Benchmark Compliance Checker audits your system configuration against CIS Level 1 controls the baseline hardening standards used by enterprises, government agencies, and security teams worldwide. It runs locally, requires no agent, and outputs a clean compliance report.

It checks for:

Password policy enforcement (minimum length, complexity, expiry)
SSH hardening (root login disabled, protocol version, idle timeout)
Firewall status (pf on macOS, ufw/iptables on Linux)
Audit logging (auditd on Linux, audit framework on macOS)
World-writable file detection
Core dump restrictions
Unnecessary service enumeration
Why cross-platform matters

Most compliance scripts are written for one OS and abandoned. Security teams in the real world manage mixed fleets developers on macOS, servers on Ubuntu or RHEL. This tool detects the OS at runtime and applies the correct benchmark checks automatically. One script, two platforms, zero manual switching.

How it works

The tool uses Python’s subprocess module to run native OS commands — defaults read, sysctl, launchctl, systemctl, ss, auditctl — and parses the output against expected CIS-compliant values. Each check returns PASS, FAIL, or WARNING, and the final report includes a compliance percentage score.

python

def check_ssh_root_login():
result = subprocess.run(['sshd', '-T'], capture_output=True, text=True)
if 'permitrootlogin no' in result.stdout.lower():
return "PASS"
return "FAIL"
The report is exported as a structured text file, organized by control category — ready to drop into a GRC audit trail or a SOC ticket.

MITRE ATT&CK mapping

Each control maps back to ATT&CK techniques:

SSH hardening → T1021.004 (Remote Services: SSH)
Audit logging → T1562.002 (Disable Windows Event Logging — Linux equivalent)
World-writable files → T1222 (File and Directory Permissions Modification)

What I learned

macOS and Linux look similar on the surface but behave very differently at the syscall and config level. launchctl vs systemctl, pf vs ufw, defaults vs /etc/ — mapping equivalent controls across both took real research. That gap is exactly why most compliance tools are single-platform.

Try it yourself

GitHub: github.com/SankethSubhas/cis-benchmark-compliance-checker

Run it, check your score, and see how hardened your system actually is.

I Built a Log Analyzer That Detects Cyberattacks — Here’s How It Works

Sanketh Subhas — Wed, 04 Mar 2026 20:10:19 +0000

A hands-on deep dive into log analysis, threat detection, and MITRE ATT&CK mapping using pure Python

Every cyberattack leaves a trail. Whether it’s a brute force attempt against an SSH server, a SQL injection probe against a web application, or a port scan mapping your network — the evidence is always there, buried in log files.

The problem is that log files are enormous. A busy web server can generate millions of log entries per day. Finding the needle in that haystack manually is impossible — which is exactly why Security Information and Event Management (SIEM) tools like Splunk, Microsoft Sentinel, and IBM QRadar exist.

But here’s the thing: most cybersecurity professionals use these tools without truly understanding the detection logic underneath. I wanted to change that for myself — so I built a log analyzer from scratch using nothing but Python.

What Are Log Files?
Before we get into the code, let’s understand what we’re working with.

Apache Access Logs record every HTTP request to a web server. Each line looks like this:

192.168.1.100 — — [01/Mar/2026:10:23:45 +0000] “GET /admin HTTP/1.1” 404 512

This tells us: the IP address that made the request, the timestamp, what they requested (/admin), the HTTP method (GET), and the response code (404 = not found).

Windows Authentication Logs (Security Event Log) record every login attempt on a Windows system. Event ID 4625 means a failed login. If you see hundreds of Event ID 4625 from the same IP in a short time period — that’s a brute force attack.

The Three Attacks We Detect

Brute Force — MITRE ATT&CK T1110

Brute force attacks involve repeatedly trying username/password combinations until one works. The detection logic is simple: if the same IP address fails to authenticate more than 5 times within a short window, flag it.

if failed_attempts[ip] > BRUTE_FORCE_THRESHOLD:
findings.append({
‘type’: ‘Brute Force’,
‘technique’: ‘T1110’,
‘severity’: ‘CRITICAL’,
‘ip’: ip,
‘count’: failed_attempts[ip]
})

This is exactly how enterprise SIEMs work — correlation rules that trigger when a threshold is exceeded.

SQL Injection — MITRE ATT&CK T1190

SQL injection attacks try to manipulate database queries through web form inputs or URL parameters. Common signatures include keywords like UNION SELECT, DROP TABLE, OR 1=1, and — (SQL comment).

Become a Medium member
SQL_PATTERNS = [
r”union\s+select”, r”drop\s+table”,
r”or\s+1\s*=\s*1", r” — \s*$”,
r”exec\s*(“, r”xp_cmdshell”
]

We scan the request URL in each log line for these patterns using Python’s re (regular expressions) module.

Port Scanning — MITRE ATT&CK T1046

A port scan is when an attacker probes a target to discover which ports are open — gathering intelligence before launching an actual attack. The signature is many requests to different endpoints from the same IP in rapid succession, often resulting in many 404 responses.

MITRE ATT&CK Mapping
What makes this tool more than just a log parser is the ATT&CK mapping. Every detected threat is tagged with its MITRE technique ID:

This context matters enormously in a SOC environment. Knowing that an alert maps to T1110 (Credential Access) tells an analyst that an attacker is trying to gain access — very different from T1046 (Discovery), which suggests they’re still in the reconnaissance phase.

The Output
The tool outputs a color-coded terminal report:

[CRITICAL] Brute Force Attack Detected
IP: 192.168.1.100 | Attempts: 47 | Technique: T1110
Recommendation: Block IP, enable account lockout policy

[HIGH] SQL Injection Attempt
IP: 10.0.0.55 | Payload: UNION SELECT * FROM users | Technique: T1190
Recommendation: Enable WAF, review input validation

And a JSON export that can be ingested directly into a SIEM platform.

What I Learned
Building this tool taught me something that no certification course did: detection is about context, not just signatures.

A single failed login is normal. Fifty failed logins from the same IP in 30 seconds is an attack. The difference is context — and building the logic to establish that context from raw log data is a fundamental skill every SOC analyst needs.

Try It Yourself
Full source code on GitHub:
github.com/SankethSubhas/log-analyzer-threat-detector
Requirements: Python 3 only. No pip install needed.

git clone https://github.com/SankethSubhas/log-analyzer-threat-detector
cd log-analyzer-threat-detector
python3 log_analyzer.py — file sample_auth.log

Sanketh Subhas is a Cybersecurity Analyst with 3.5+ years of experience in SOC operations, GRC, and threat detection.
Portfolio: sankethsubhas.pages.dev | GitHub: github.com/SankethSubhas

Cybersecurity
Python
Blue Team
Mitre Attack