u/manishrawat21

I built an automation pipeline to turn added CISA Known Exploited Vulnerabilities into actionable detections with little manual work.

The workflow does the following:

• Checks the CISA KEV catalog for vulnerabilities
• Gets the CVEs
• Uses Google Gemini to create Sigma detection rules
• Maps detections to the MITRE ATT&CK framework
• Sends results to Google Sheets, Slack, email and a SIEM for analysts to review

My goal was to save time on tracking KEV updates and writing detections while still having an analyst validate the results.

I documented the process, including the workflow, prompts, integrations and implementation details. If you work in detection engineering, threat hunting or threat intelligence I'd love to hear how you use CISA KEV in your environment. If you've automated any part of it.

Blog link in the comments.

I've been trying to get better at writing technical tutorials that people can actually follow instead of just explaining a concept.

I recently published a Medium article where I documented a project I built to automate the process of tracking new CISA Known Exploited Vulnerabilities and generating Sigma detection rules. It is a pretty specific cybersecurity topic, but I wrote it as a step by step guide with the goal of making it easy to understand and recreate.

I'm still figuring out what makes a technical article enjoyable to read, so I'd really appreciate honest feedback from other Medium writers. I'm more interested in hearing about the writing than the project itself. Was the structure clear? Did it keep your attention? Were there parts that felt confusing or unnecessary?

If you have a few minutes to read it, I'd genuinely appreciate your thoughts.

NOTE: In my last post, I asked for feedback on my detection logic, but some cybersecurity experts judged my post as AI content and asked for proof. Rather than discussing detection logic, they did everything, and that discussion of ours went south. Still, after all of this, my post reached 30+ likes, so now I want to publish my rule with POC, but I'm unable to add images.

SIGMA RULE:-

title: Suspicious Executable Activity from Temp Directories
id: 42461076-ab43-408d-bc8d-97016a04e2cf
description: Detects unsigned executables in Temp loading modules or DLLs, common in APT29 and malware staging
status: experimental
date: 2026/05/11
author: Manish Rawat
references:
   - https://attack.mitre.org/techniques/T1574
   - https://github.com/OTRF/Security-Datasets

logsource:
 product: windows
 category: Image loaded
detection:
 selection:
   EventID: 
     - 7
   Image|contains:
     - \\ProgramData\\
     - \\Temp\\
     - \\temp\\
 selection_ImageLoaded_location:
     ImageLoaded|contains:
       - \\Temp\\
       - \\temp\\
       - \\ProgramData\\
 selection_ImageLoaded_exe:
     ImageLoaded|endswith:
       - .exe
       - .pyd
 selection_signaturestatus:
     SignatureStatus: 
        - 'Unsigned'
        - 'Unavailable'
        - 'Invalid'
 selection_Signed:
     Signed: 
       - 'false'
       - '-'
 condition: 
       (selection or selection_ImageLoaded_location) 
       or (selection_ImageLoaded_exe and (selection_ImageLoaded_location or selection )) 
       or (selection_signaturestatus and (selection or selection_ImageLoaded_exe or selection_ImageLoaded_location)) 
       or (selection_Signed and (selection or selection_ImageLoaded_exe or selection_ImageLoaded_location)) 

falsepositives:
 - Software installers using temporary directories
 - Legitimate portable applications
 - Python development environments 
severity: medium
tags:
 - attack.t1059.006
 - attack.t1574

This is the raw lab logic. I am still tuning it for production.

Note: Detecting only double \\Temp\\ logic is making this detection weak (only 24 events triggered), but with individual \\Temp\\ detection, it is getting much more results (300+ events triggered). I know individual \\Temp\\ detection can lead to false positives, but we can narrow it down based on a 90 days or 30 days baseline.

SPL:

(EventID=7 Image IN ("\*\\\\ProgramData\\\\\*", "\*\\\\Temp\\\\\*", "\*\\\\temp\\\\\*")) OR ImageLoaded IN ("\*\\\\Temp\\\\\*", "\*\\\\temp\\\\\*", "\*\\\\ProgramData\\\\\*") OR (ImageLoaded IN ("\*.exe", "\*.pyd") ImageLoaded IN ("\*\\\\Temp\\\\\*", "\*\\\\temp\\\\\*", "\*\\\\ProgramData\\\\\*") OR (EventID=7 Image IN ("\*\\\\ProgramData\\\\\*", "\*\\\\Temp\\\\\*", "\*\\\\temp\\\\\*"))) OR (SignatureStatus IN ("Unsigned", "Unavailable", "Invalid") (EventID=7 Image IN ("\*\\\\ProgramData\\\\\*", "\*\\\\Temp\\\\\*", "\*\\\\temp\\\\\*")) OR ImageLoaded IN ("\*.exe", "\*.pyd") OR ImageLoaded IN ("\*\\\\Temp\\\\\*", "\*\\\\temp\\\\\*", "\*\\\\ProgramData\\\\\*")) OR (Signed IN ("false", "-") (EventID=7 Image IN ("\*\\\\ProgramData\\\\\*", "\*\\\\Temp\\\\\*", "\*\\\\temp\\\\\*")) OR ImageLoaded IN ("\*.exe", "\*.pyd") OR ImageLoaded IN ("\*\\\\Temp\\\\\*", "\*\\\\temp\\\\\*", "\*\\\\ProgramData\\\\\*"))  

False Positive:

1. Software installers using temporary directories
2. Legitimate portable applications
3. Python development environments

Tools Worth Monitioring:

• PsExec64.exe
• sdelete64.exe
• PSEXESVC.exe

If you've some suggestion or feedback, please feel free to DM. Detection insights are valuable to me. If you hate this post, then do what you want to do.

I have been posting my security research and threat hunting deep dives on Medium for a while now. While the reach is decent I have hit a wall that I am not sure how to climb over.

The Situation

Right now I have 56 followers. My stats are actually solid. I am pulling in about 1k views and 500 reads on average and gaining maybe 5 to 10 followers a month.

The Huge Issue

I am from a country where Stripe is not available. Since Medium uses Stripe for the Partner Program I am basically stuck. Even when I hit that 100 follower mark I will not be able to officially join the program to earn from my stories.

I need your advice on a few things:

• The Stripe Problem: If you are in a country that Stripe does not support how are you handling this? Is there a legit workaround or am I locked out of the MPP forever?
• Should I pivot: Since I cannot get paid through the program should I stop focusing on Medium and move my research to Substack or a personal blog where I can use other payment methods?
• Growing faster: My views are high but my followers are low. How do I get more of those readers to actually hit the follow button in the cybersecurity niche?
• Strategy: Should I even bother applying to the MPP later or should I just focus on using Medium to build a brand and portfolio instead?

I really like the platform but I do not want to keep shouting into a void if there is no way to actually grow or monetize here.

Has anyone else been in this spot? What would you do?

Most detection rules focus on obvious indicators, such as hashes or C2 domains. Advanced actors like APT29 do not play that game.

NOTE: Keep your feedback focused strictly on the detection rule and the telemetry. I am sharing this research to contribute to the community, not to compete with anyone. If you are just going to derail the thread with off topic arguments, I do not need your feedback.

WHAT I FOUND:

Adversaries are running unsigned executables from C:\Windows\Temp\ and loading Python compiled modules ((dot)pyd files) from AppData\Local\Temp. In isolation this looks like normal software installation. In context it is adversary staging.

THE DETECTION LOGIC:

I built my alerts based on the exact path and signature correlations from my lab notes. The alert triggers on these specific combinations:

• Temp: An image executing from Temp or Image loading module or DLL from Temp.
• ProgramData: A process in ProgramData loading image or image loading from ProgramData.
• Legit + Unsigned: A signed legitimate process loading an unsigned .exe or .pyd module.
• Temp + Legit: Execution from Temp loading legitimate signed System32 DLLs.

WHY EVENTID 7 MATTERS: Process Creation (EventID 1) tells you WHAT ran. Image Load (EventID 7) tells you WHAT IT IS LOADING.

Example from the telemetry: Image: C:\Windows\Temp\python(dot)exe ImageLoaded: C:\Users\pbeesly\AppData\Local\Temp_MEI29522_ctypes(dot)pyd Signed: false

APT29 staged python.exe and loaded modules BEFORE executing the final payload. Most rules miss this because they only watch process creation.

TOOLS WORTH MONITORING (even if legitimate):

• PsExec64(dot)exe for remote execution
• sdelete64(dot)exe for anti forensics
• PSEXESVC(dot)exe for lateral movement

FALSE POSITIVES: Software installers, portable apps, and Python development environments will trigger this. That is standard tuning for your specific environment.

SIGMA RULE:-

title: Suspicious Executable Activity from Temp Directories
id: 42461076-ab43-408d-bc8d-97016a04e2cf
description: Detects unsigned executables in Temp loading modules or DLLs, common in APT29 and malware staging
status: experimental
date: 2026/05/11
author: Manish Rawat
references:
   - https://attack.mitre.org/techniques/T1574
   - https://github.com/OTRF/Security-Datasets

logsource:
 product: windows
 category: Image loaded
detection:
 selection:
   EventID: 
     - 7
   Image|contains:
     - \\ProgramData\\
     - \\Temp\\
     - \\temp\\
 selection_ImageLoaded_location:
     ImageLoaded|contains:
       - \\Temp\\
       - \\temp\\
       - \\ProgramData\\
 selection_ImageLoaded_exe:
     ImageLoaded|endswith:
       - .exe
       - .pyd
 selection_signaturestatus:
     SignatureStatus: 
        - 'Unsigned'
        - 'Unavailable'
        - 'Invalid'
 selection_Signed:
     Signed: 
       - 'false'
       - '-'
 condition: 
       (selection or selection_ImageLoaded_location) 
       or (selection_ImageLoaded_exe and (selection_ImageLoaded_location or selection )) 
       or (selection_signaturestatus and (selection or selection_ImageLoaded_exe or selection_ImageLoaded_location)) 
       or (selection_Signed and (selection or selection_ImageLoaded_exe or selection_ImageLoaded_location)) 

falsepositives:
 - Software installers using temporary directories
 - Legitimate portable applications
 - Python development environments 
severity: medium
tags:
 - attack.t1059.006
 - attack.t1574

This is the raw lab logic. I am still tuning it for production.

Note: Detecting only double \\Temp\\ logic is making this detection weak (only 24 events triggered), but with individual \\Temp\\ detection, it is getting much more results (300+ events triggered). I know individual \\Temp\\ detection can lead to false positives, but we can narrow it down based on a 90 days or 30 days baseline.

SPL:

(EventID=7 Image IN ("\*\\\\ProgramData\\\\\*", "\*\\\\Temp\\\\\*", "\*\\\\temp\\\\\*")) OR ImageLoaded IN ("\*\\\\Temp\\\\\*", "\*\\\\temp\\\\\*", "\*\\\\ProgramData\\\\\*") OR (ImageLoaded IN ("\*.exe", "\*.pyd") ImageLoaded IN ("\*\\\\Temp\\\\\*", "\*\\\\temp\\\\\*", "\*\\\\ProgramData\\\\\*") OR (EventID=7 Image IN ("\*\\\\ProgramData\\\\\*", "\*\\\\Temp\\\\\*", "\*\\\\temp\\\\\*"))) OR (SignatureStatus IN ("Unsigned", "Unavailable", "Invalid") (EventID=7 Image IN ("\*\\\\ProgramData\\\\\*", "\*\\\\Temp\\\\\*", "\*\\\\temp\\\\\*")) OR ImageLoaded IN ("\*.exe", "\*.pyd") OR ImageLoaded IN ("\*\\\\Temp\\\\\*", "\*\\\\temp\\\\\*", "\*\\\\ProgramData\\\\\*")) OR (Signed IN ("false", "-") (EventID=7 Image IN ("\*\\\\ProgramData\\\\\*", "\*\\\\Temp\\\\\*", "\*\\\\temp\\\\\*")) OR ImageLoaded IN ("\*.exe", "\*.pyd") OR ImageLoaded IN ("\*\\\\Temp\\\\\*", "\*\\\\temp\\\\\*", "\*\\\\ProgramData\\\\\*"))  

If you've some suggestion or feedback, please feel free to DM. Detection insights are valuable to me. If you hate this post, then do what you want to do.

I have been focusing on threat detection recently and wanted to share the methodology behind a rule I built to detect suspicious EventID 7 activity. I used the APT29 dataset from MITRE ATT&CK to understand how malware staging looks in real logs instead of just relying on generic indicators.

The rule targets unsigned executables in Temp directories that are loading modules or DLLs. This is a pattern I saw repeatedly in the APT29 kill chain where initial access drops payloads into user writable paths.

My logic uses a "double suspicion" approach to keep the fidelity high:

1. The executable is running from \Temp or \ProgramData.
2. The loaded image is also located in those same writable paths.
3. The SignatureStatus is Unsigned, Unavailable, or Invalid.

I am also monitoring how specific tools like PsExec64.exe and sdelete64.exe interact with these paths.

I am planning to add the full .yml to my GitHub repository soon. Right now I want to share the logic here to get your feedback and see if I missed anything.

Questions for the community:

1. In a production environment how much noise do you still see from signed binaries loading unsigned modules from \ProgramData?
2. How would you rate this logic for someone looking for a remote SOC or Detection Engineering role?

I am moving from theory to evidence based on my analysis of 37 real Sysmon events from this specific attack. I will link the full technical breakdown in the comments if anyone wants to dig into the raw telemetry.

I need advice from security professionals.

I've been building detection engineering and threat hunting skills for 2 years through a personal SOC lab. All my work is documentedon Github

What I've built:
- Analyzed 196,071 APT29 adversary events in Splunk
- Wrote Sigma detection rules (LSASS access, PowerShell abuse, DLL hijacking)
- Built automated IR pipeline (Wazuh → N8N → zero manual steps)
- Published threat hunting research series on methodology
- Top 3% TryHackMe Blue Team globally

#Technical_Skills:
- Splunk SPL query development
- Sigma/YARA rule authoring
- MITRE ATT&CK mapping
- Hypothesis-based threat hunting
- SOAR automation
- Log analysis across endpoint, network sources

#The_Problem:
- I have zero traditional SOC experience. No corporate job history in security. Self-taught from 2021.

#My_Question:
Which roles should I actually be targeting?

I've been applying to:
SOC Analyst (most require 1-3 years experience)
Detection Engineer (most want 3-5 years)
Threat Hunter (senior-level, not realistic)

Should I be looking at:
- SOC Analyst Tier 1 / Level 1?
- Junior Security Analyst?
- Cybersecurity Analyst - Entry Level?
- Security Operations Intern (even though I'm 2 years out of school)?
- MSSP analyst roles (higher volume, more willing to train)?

Or completely different:
- Contract/freelance detection rule writing?
- Security consulting for small businesses?
- Technical sales for security vendors (get my foot in the door)?

For people who've hired for SOC roles: What job title would you post for someone with my skill set?

For people who were in my position: What role did you actually get hired into, and what was the path?

I'm not afraid of starting at the bottom. I just need to know which bottom to aim for.

Hey everyone,

I need some honest advice.

For the past couple of years, I’ve been focused on threat detection and SOC work. I built my own lab, simulated attacks, and worked through a full APT29 dataset. I analyzed thousands of Sysmon logs in Splunk and created detection rules for things like LSASS access, lateral movement, and persistence.

I also converted detections to Sigma, tested them, and wrote about the process. I try to keep everything practical and based on real behavior, not just theory.

But I am not getting the results I expected. Very few opportunities, very little response.

So I want to ask directly

• Are my skills still not enough for a remote SOC or detection role
• Am I focusing on the wrong areas
• Or is the problem how I am presenting my work

If anyone has been in this position or is already working in this field, I would really appreciate your honest input on what I should do next.

Thanks

https://manishrawat21.substack.com/p/why-your-siem-still-cant-catch-powershell?r=7dntti

https://preview.redd.it/urehf33bwbyg1.jpg?width=1080&format=pjpg&auto=webp&s=d09b4d69118b16921ad9116858df1f94265090fc

So I've been going through the MITRE APT29 dataset (the 196k Sysmon events they released from their eval). Wanted to understand why PowerShell attacks keep working when we all know they're happening.

Most SIEMs either alert on everything or nothing. Both suck.

What I kept seeing in the logs:

• Encoding flags everywhere (-enc, -e, -encoded, all the variations)
• Office apps spawning powershell.exe as a child process
• That PowerShell then making network calls or downloading stuff
• Evasion parameters like -NoProfile and -window hidden on basically every malicious execution
• Process chains that make no sense for legit activity (wscript -> cmd -> powershell)

The thing is, these patterns show up consistently. Not sometimes. Every time there's actual malicious activity in the dataset.

So I wrote a Sigma rule that looks for these combinations. Not just "PowerShell ran" (useless), but "Office app spawned PowerShell AND it's making network connections" or "PowerShell with encoding flags AND suspicious parent process."

Tested it on the full dataset. Catches the malicious stuff. Then ran it on Splunk against normal admin activity to see what breaks. Got some false positives (automation that uses encoding for credentials mostly), but way less noise than the usual approach.

The rule's on my GitHub with the Splunk conversion and some notes on tuning. I'm putting it out there because honestly, I want to know if I'm missing something obvious. What are you all using for PowerShell detection that actually works in production?

Also curious about false positive patterns you've run into. I documented what I found, but every environment is different.

Anyway, feedback welcome. If this approach has holes I'm not seeing, I'd rather know now before claiming it solves anything.

Hey everyone,

I’m Manish, working on threat research and writing. I started posting on Substack about a month ago, mostly sharing my findings, notes, and cybersecurity stuff every Monday.

But honestly, the reach has been pretty low so far. Most posts get around 7–10 views and I haven’t picked up any followers yet.

Not sure if it’s the content, consistency, or just distribution. Would really appreciate any honest feedback or suggestions on what I should improve or try differently.

Thanks!