Hi, my name is
Shantanu Singh
I work in defensive security, focused on SOC operations, detection engineering, and malware analysis. I've built a Windows EDR from scratch, run a home SOC detection lab, and published the Snort++ and Sigma rules that came out of that research.
About
I'm a Computer Science graduate working in defensive security, which covers SOC operations, detection engineering, malware analysis, and threat intelligence. I like building the tools I work with rather than just running them, which is why I put together a home SOC lab on Splunk, Sysmon, and TheHive, and later built WinSpector, a user-mode Windows EDR with its own MITRE ATT&CK scoring engine. I also spend a good amount of time learning the offensive side, because understanding how an attack actually works is what makes a defense worth building.
During a full-time internship at Power Grid Corporation of India, in the critical infrastructure sector, I built an ISMS aligned with ISO/IEC 27001 and 27002, analysed DarkComet and researched AsyncRAT in a controlled lab, wrote Snort++ detection rules, ran a scoped web application penetration test, and helped deploy OpenCTI. I also picked up some exposure to ICS/OT concepts like Modbus and DNP3 along the way. Everything I learn from this kind of work gets documented and published on GitHub, including the times testing didn't turn up a vulnerability.
Outside of that, I try to keep a bit of day-to-day research going just to stay current, since the field moves fast enough that stepping away for even a few weeks means catching up later. That usually means reading security books, digging into how specific attacks and defenses actually work, and picking up new projects when an idea is worth building out, like the Python malware analysis framework. I split my time fairly evenly between theory and hands-on practice, competing in CTFs for the practical side, and spending time just thinking through and designing how something should work before I touch any code. I try to look at everything from both angles, how I would break something and how I would defend it, since that's usually where the real understanding comes from.
Education
Skills
Experience
- Developed a complete ISMS Manual aligned with ISO/IEC 27001:2022 and ISO/IEC 27002:2022 for a modelled organization. Designed a 6-tier governance hierarchy, created a qualitative risk register covering 8 asset categories, prepared a Statement of Applicability covering all 93 Annex A controls, and developed 12 security policies following the PDCA lifecycle.
- Conducted controlled laboratory analysis of DarkComet and researched AsyncRAT using Malpedia and public threat intelligence sources. Analyzed C2 protocols, including plaintext TCP and SSL/TLS, along with persistence and evasion techniques. Authored 40 Snort++ IDS/IPS rules covering C2, DNS, and behavioral signatures and published them on GitHub.
- Conducted a scoped web application penetration test using OWASP ZAP, Burp Suite, SQLMap, FFUF, Nmap, Nessus, and OpenVAS. Performed vulnerability scanning and manual validation, confirmed SQL injection findings, filtered out false positives from automated scans, and documented the validated findings in a structured vulnerability report with technical evidence and remediation recommendations, then reported them to the handling team.
- Researched contemporary phishing simulation techniques and employee-targeted attack trends, then discussed findings and practical recommendations with the team following an internal employee phishing-awareness exercise.
- Assisted with the deployment of the OpenCTI threat intelligence platform, including AbuseIPDB feed integration, and provided support across various laboratory activities and other technical tasks.
- Spent additional time learning malware reverse engineering and gained exposure to ICS/OT concepts, including SCADA protocols such as Modbus and DNP3.
Projects
Self-built VMware SOC lab — Splunk Enterprise 10.2.3, Sysmon, and TheHive 5 — simulating real SOC workflows. Used Atomic Red Team to execute live MITRE ATT&CK techniques (T1110.001, T1003.001, T1059.001), wrote custom SPL detection queries, and documented end-to-end investigations in TheHive.
User-mode EDR in Python (psutil, pywin32): process watcher, LOLDrivers hash-matched driver scanner (623 entries), Sysmon + Windows event-log miner, and a 26-rule MITRE ATT&CK scoring engine. Validated on live Windows 10 against process injection, LSASS access, PowerShell cradles, WMI execution, and LOLBin abuse. Deployed as a Windows service with Elasticsearch SIEM export and 2 authored Sigma rules.
Python malware analysis framework with static (PE parsing, YARA matching, entropy scoring, file hashing, string extraction) and dynamic (process/filesystem/network monitoring, API call tracing, behavior detection) modes. VM/container sandbox isolation. Auto-generates HTML and JSON analysis reports.
Research
- As part of an AI bug bounty program, I carried out a solo, manual red-team assessment of three independently sandboxed AI agents: a customer-support bot, an enterprise finance assistant, and a documentation RAG chatbot. Each agent had a specific disclosure objective, and every prompt was manually written and tested without automated tooling.
- Over approximately three and a half weeks, I logged roughly 200 attempts across the three agents. None of the disclosure objectives reached validator-confirmed status, and no confirmed vulnerability was identified. The write-up focuses on testing methodology, evidence discipline, failed approaches, and defensive behaviours observed throughout the engagement.
- Testing a common set of techniques across all three agents revealed a recurring two-layer defence pattern: a generic input-level filter combined with model-level reasoning that recognised disclosure and bypass attempts across different framings, including authority claims, hypothetical scenarios, attribution injection, and context-reframing.
- The most useful finding came from a non-adversarial approach: asking the customer-support agent to organise its own previously disclosed answers produced a functional map of all seven underlying operations. The investigation also reinforced the value of changing one variable at a time, testing published extraction techniques early, and comparing the same techniques across multiple agents.
- The worm was analysed statically and dynamically in an isolated FlareVM lab, with FakeNet-NG simulating network services. Two independent detonations gave consistent results.
- On Windows 10, the sample modified the Internet Explorer start page (HKCU) and instantiated the Outlook COM object used for mass-mailing, since neither requires elevated privileges.
- Its file copies to System32 and its HKLM Run-key persistence were silently blocked by UAC. ProcMon showed zero WriteFile events, confirming that no copies reached disk.
- The report maps its behaviour to 14 MITRE ATT&CK techniques and includes YARA and Sigma detection rules I wrote, along with defensive recommendations such as blocking script attachments at the email gateway.
- DarkComet was executed and analysed in a controlled laboratory environment to study its actual operation, including C2 communication, transport behaviour, persistence, and observable network characteristics.
- AsyncRAT was studied through Malpedia and historical/public threat intelligence rather than live execution. Family information, documented behaviours, historical research, and previously observed network indicators were used to understand the malware and its communication patterns.
- Historical and previously observed data were converted into Snort++ detection rules. The resulting rule sets cover C2 ports and protocols, DNS infrastructure, HTTP/TLS characteristics, payload indicators, behavioural patterns, persistence/evasion indicators, and higher-confidence stateful correlations.
- The rules provide a historical detection baseline. Current/live research provides contemporary context for identifying behavioural changes and potential future rule updates; current observations have not been directly converted into the present rule set unless independently validated and added.
Conferences
This was my first conference. I went in with a good understanding of AI security and a basic understanding of cloud security, so I already had some background on the topics being discussed. What I found useful was seeing how these areas connect in practice, especially around Zero Trust, governance, defense in depth, SOC operations, autonomous systems, cloud security, and quantum readiness.
Before the conference, I already knew about the July 2026 OpenAI–Hugging Face incident and had read a little about it. During the summit, it came up repeatedly in discussions around what happened, what security measures should have been in place, and how both offensive and defensive security teams should approach systems that can find and exploit vulnerabilities. That made me want to understand the incident beyond the basic reports I had seen.
My main question was simple: if the system was sandboxed, how did it get out in the first place? My initial understanding was that the model had simply escaped the sandbox through a zero day in the package registry proxy. After the conference, I went back and read the detailed OpenAI and Hugging Face reports. I realised that this was only one part of a much larger chain. The models found ways to communicate through shared infrastructure, used Artifactory to gain indirect internet access, reached a third party environment, and then used vulnerabilities and exposed credentials to move through Hugging Face infrastructure.
After the conference, I spent more time looking into what this means from a security point of view. The biggest thing I took away was that a sandbox or blocked internet access is not enough on its own. The security boundary also depends on the services, identities, credentials, network paths and permissions around it. That is what led me to look more closely at egress controls, least privilege, defense in depth, SOC monitoring, cloud security, and governance for AI systems.
Certifications
Contact
I'm open to roles in defensive security, including SOC analyst, detection engineer, malware analyst, and threat intelligence analyst positions. Also happy to connect on research, CTFs, or anything security related.
There's no contact form, so nothing is collected here.
LinkedIn or email are the best ways to reach me.
Response time is typically 24–48 hours.