DEV Community: Tasha · DataSec Chronicles

The Rootkit Exorcist: Summoning Local AI to Investigate Suspicious Scripts 👻

Tasha · DataSec Chronicles — Tue, 27 Oct 2026 14:47:28 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 4: Ghost in the Machine

The terminal is blessed. The scripts are not.

What I Built

For the final week of Hacktoberfest 2026, I built The Rootkit Exorcist, a Python command-line tool that scans scripts for suspicious patterns and uses locally running AI to help explain the findings.

The theme was Ghost in the Machine, and I decided to take that rather literally.

What if a cybersecurity investigation tool had an AI-powered exorcist personality?

The result is a tool with two modes:

SOC Mode: A professional, evidence-focused presentation of suspicious patterns and AI-assisted investigation notes.
Exorcist Mode: The same underlying analysis, but with Halloween flair and a theatrical AI personality I affectionately call Father Llama.

Both modes use the same static detection engine.

I'm a senior data analyst transitioning into cybersecurity, and this project gave me another opportunity to connect my analytical background with security investigation workflows.

It also gave me an excuse to put this in a terminal:

✝ THE POWER OF CHMOD COMPELS YOU! ✝

Demo

Watch The Rootkit Exorcist in action:

The demonstration includes:

SOC Mode: Static script analysis with severity levels and MITRE ATT&CK mappings.
Markdown report: Exporting and previewing the investigation findings.
Exorcist Mode: AI-assisted explanations from Father Llama, powered by Llama 3.2 1B through Ollama.
Automated testing: Five passing unit tests.

All suspicious samples are synthetic and analyzed as text, not executed.

Code

The complete source code for The Rootkit Exorcist is available on GitHub.

Tash925 / rootkit-exorcist

A Python CLI for static script analysis, MITRE ATT&CK mapping, and Ollama-powered investigation reports. SOC by day, exorcist by night. 👻

✝ The Rootkit Exorcist 👻

The terminal is blessed. The scripts are not.

A Python-based static script analyzer that identifies potentially suspicious command patterns and uses Ollama with Llama 3.2 to generate supplementary investigation notes.

Built for the Hacktoberfest 2026 Week 4 DEV Challenge, The Rootkit Exorcist combines practical cybersecurity analysis with supernatural humor.

✝ THE POWER OF CHMOD COMPELS YOU! ✝

What Does It Do?

The Rootkit Exorcist reads script files as text without executing them.

It uses Python regular-expression rules to identify selected suspicious command patterns and provides two reporting modes:

SOC Mode: Professional, evidence-focused security reporting.
Exorcist Mode: Dramatic cybersecurity commentary with a spooky personality.

Both modes use the same detection engine.

Detection Capabilities

Rule	Detection	Severity	MITRE ATT&CK
EXO-001	Potential cron persistence	MEDIUM	T1053.003
EXO-002	Remote download piped into a shell	HIGH	T1105
EXO-003	PowerShell encoded command	MEDIUM	T1027

These are heuristic indicators, not proof…

View on GitHub

The repository includes the Python CLI, static detection rules, local Ollama integration, synthetic sample scripts, automated tests, and setup instructions.

How I Built It

I built The Rootkit Exorcist in Python, using a deterministic detection engine alongside Llama 3.2 1B running locally through Ollama.

The application has three main components:

1. Static detection engine

The scanner uses regular expressions to identify suspicious patterns, including:

Detection	Severity	MITRE ATT&CK
Potential cron persistence	Medium	T1053.003
Download and execute	High	T1105
Encoded PowerShell commands	Medium	T1027

Each detection includes the matching evidence, its location in the script, and a short explanation.

These are heuristic indicators, not confirmation of malicious activity.

2. Local AI interpretation

Once the scanner identifies suspicious patterns, the findings are passed to Llama 3.2 1B through Ollama.

The model generates additional explanations and suggested investigative steps.

I experimented with two presentation styles: a professional SOC analyst voice and a dramatic Halloween exorcist voice.

The important design choice was keeping the detection logic separate from the AI-generated interpretation.

The model does not decide which detection rules matched.

3. CLI reporting and testing

The tool can export its findings and AI notes to a Markdown report.

I also added automated unit tests covering the detection rules, benign input, and a false-positive scenario involving a cron listing command.

All five tests passed.

One unexpected part of development was troubleshooting local inference inside GitHub Codespaces.

An AI request timed out while the static scanner continued to produce findings and export the report. After verifying that Ollama could respond to a smaller prompt, I successfully ran the full theatrical analysis.

I also discovered and fixed a Python indentation bug that caused an error when running without the optional report export argument.

Both experiences reinforced the value of testing the entire workflow rather than only the detection logic.

Why Does Open Innovation Matter?

Open-weight models made this project possible without depending on a hosted AI API for every investigation.

With Ollama, I could run Llama locally, experiment with different prompts, and control how the AI layer interacted with the deterministic scanner.

That flexibility mattered because I wanted to explore the boundary between identifying evidence and interpreting it.

During testing, Father Llama sometimes described suspicious commands as definitively malicious, even when the scanner had only identified patterns that required further investigation.

That was an important lesson.

AI-generated explanations are useful, but they are not evidence by themselves.

Having control over the local model and the surrounding Python workflow allowed me to experiment with that distinction directly.

Open innovation also makes projects like this approachable for learners. Someone can inspect the detection rules, change the prompts, run the model locally, and build on the idea.

There are trade-offs, including model performance and hardware limitations, but the ability to experiment openly is valuable.

The Spirit of It

Halloween gave me the creative direction, but cybersecurity gave me the underlying question.

What happens when a suspicious command appears in a script?

Does it belong there?

Is there a legitimate explanation?

What evidence would help determine the next step?

The Rootkit Exorcist doesn't answer those questions conclusively. It provides a starting point for investigation.

And despite its name, it does not detect rootkits directly or establish that a script is malicious.

It's a learning project built around static analysis, local AI experimentation, and the importance of human verification.

My favorite moment was finally getting Father Llama to deliver his full theatrical analysis after an earlier timeout.

THEATRICAL EXORCISM COMPLETE!

The project was working, the tests were passing, and the AI had officially embraced its Halloween personality.

As I continue moving from data analytics into cybersecurity, I keep returning to one idea:

The tool changes. The question doesn't.

And sometimes the question is:

Does this belong here?

Happy Hacktoberfest! 👻✝️💜

Small Businesses Don’t Read CVEs. So I Built a Translator.

Tasha · DataSec Chronicles — Wed, 14 Oct 2026 22:13:09 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle

What I Built

AlertCadence — a tool that turns raw security advisories into plain-English briefs a small business can actually read.

Security advisories are written for engineers. A small-business owner doesn't read "path traversal via crafted request" — they skim it and move on. Managed IT providers (MSPs) feel this constantly: they need to tell clients, "here's what to patch and why it matters," but translating CVEs into calm, clear language by hand eats their Monday mornings.

AlertCadence does the translation. It pulls CISA's feed of actively exploited vulnerabilities, keeps the ones affecting software small businesses actually run, and rewrites each into three plain sentences: what happened, why it matters to your business, and what we're doing about it — generated by a model running entirely on the user's own machine.

The person who'd pay for it: an MSP who wants to send clients a credible weekly security brief without writing it from scratch and without sending client data to a cloud AI.

Demo

🔗 Live: alertcadence.tech

The landing page explains the tool; "See this week's brief →" opens a real brief generated from live CISA data by a local model — six current advisories (Fortinet, Apple, SharePoint, WordPress, Magento, Google Pixel), each translated into plain English, with ransomware-linked ones listed first.

Code

Tash925 / alertcadence

Plain-English security briefs for small businesses, generated by a local open model. Hacktoberfest 2026.

AlertCadence

Plain-English security briefs for small businesses — generated by a local open model.

Built for the Hacktoberfest 2026 Open-Source AI Challenge, Week 2: Side Hustle A project by DataSec Chronicles.

Live site: alertcadence.tech

A real brief, generated from live CISA data by a local model — each advisory in plain English, ransomware-linked ones first.

What it does

Security advisories are written for engineers. A small-business owner doesn't read "path traversal via crafted request" — they skim it and move on.

AlertCadence translates. It pulls CISA's feed of actively-exploited vulnerabilities, keeps the ones affecting software small businesses actually run, and rewrites each into three plain sentences:

What happened — the issue, in plain English
Why it matters to your business — the practical risk
What we're doing — reassuring, proactive language an MSP would use

The result is one clean HTML brief an MSP can review and send…

View on GitHub

A Python pipeline: fetch → extract → summarize → store → render. The README walks through each step.

How I Built It

Local open-weight model — Google Gemma (gemma2:2b) via Ollama.

The whole pipeline runs on my own machine. But the interesting part was how I used the model — and what I decided not to let it do.

A 2B model is small. Feed it a raw advisory, and it leaks exploit syntax into the "plain English," drifts into Markdown, and — worst of all for security — invents details when the source is vague. Tightening the prompt helped a little. It wasn't enough.

What worked was giving the model a smaller job. A deterministic Python step extracts a small fixed set of facts first — vendor, product, type of flaw, ransomware flag — and the model only ever receives those. It can't leak exploit syntax it never sees. It can't misjudge relevance it never evaluates. The guardrail is the architecture, not the prompt.

When an advisory's details are genuinely thin, the model is told to say so plainly rather than guess. I tested that deliberately — fed it a vulnerability with almost no public detail — and instead of inventing a mechanism, it said: "the specifics aren't public yet." For anything going out under an MSP's name, that honesty is the whole ballgame.

Storage — MongoDB Atlas, keeping a durable history of every brief generated, with a local JSON fallback so the pipeline never breaks if the database is unreachable.

Data — CISA Known Exploited Vulnerabilities, where everything is confirmed exploited, so risk is pre-filtered at the source.

Why Does Open Innovation Matter?

Three reasons, and they're the reason the project works at all:

Privacy. This is a tool an MSP would run against their client list. A cloud API would mean sending that to someone else's servers. A local open model means the data never leaves the machine — which, for a security tool, isn't a nice-to-have; it's the whole reason it can be trusted.
Cost. Open-weight + local = $0 per brief. No per-token bill, so an MSP keeps full margin on comms they should be sending anyway.
Control. I could constrain a small open model exactly how I needed — feed it only pre-extracted facts, force it to admit uncertainty. That tight control over the model's inputs is what made it safe for security content. A closed API gives you less of that.

The open pieces aren't decoration. They're what make the tool trustworthy enough to exist.

My First User

No paying users yet — but I built this in public, and the response from the people closest to the problem has been the real early signal.

A few reactions stood out as I shared the approach: that a local model turning CVE text into plain English is exactly the translation layer small businesses without a security team need, and that filtering for relevant software before the model runs is the right order — the model should only ever see what survived the logic, not the raw feed.

The most useful exchange came from someone who runs a chatbot on a testing lab's site. They zeroed in on the part where the model admits when a detail isn't public, because in their world a made-up answer is worse than no answer at all. They suggested saving those "detail not available" cases as a regression test — so if a future model update quietly starts filling in the blanks, it fails loudly instead of slipping through. That's my next build.

That's exactly why I build in public: someone who'd been burned by hallucination handed me my next feature. The step after that is a round of feedback from actual small-business owners to check how clearly the briefs land for the people they're written for.

Prize Categories

Best Use of Gemma — Gemma (open-weight, via Ollama) is the engine; the whole project is built around constraining a small local model to produce safe, calm, non-technical security writing.
Best Use of MongoDB Atlas — stores every brief's advisories and summaries, with a graceful local fallback.
Best .tech Domain — live at alertcadence.tech.

Built with 💜 by DataSec Chronicles. The tool changes, the question doesn't.

The Security Dictionary: Trail Edition — Cybersecurity Concepts as Outdoor Missions, Powered by Local Gemma

Tasha · DataSec Chronicles — Sat, 10 Oct 2026 17:09:42 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass

What I Built

The Security Dictionary: Trail Edition — a tool that teaches kids cybersecurity by sending them outside.

Pick an explorer's age, where you're exploring, and how long you've got. The tool hands you a security concept framed as an outdoor mission, and a warm voice reads it aloud — so the phone goes in your pocket and the learning happens in the real world.

IOC → find three clues something was here before you
Alert → notice what grabs your attention
Firewall → find barriers that let some things through and keep others out
Encryption → invent a secret signal only you and a friend understand
Phishing → spot something tempting — feel the pull, but don't go to it

It's a branch of The Security Dictionary, a project where I take intimidating security language and make it understandable. This asks the next question: what if understanding didn't begin with another definition, but with an experience?

My whole background is "finding what doesn't belong" — atmospheric anomalies, fraud, threat hunting. That's not a definition you memorize; it's a reflex you build by doing. So I wondered what happens if a kid learns a security concept by hunting for it outside first, and the definition comes after. Map an alert to a knocked-over flowerpot. Map a firewall to the backyard fence. The definition lands because the kid already lived it.

It's built for kids ages 5–13 (three reading levels), and honestly for any family that wants a reason to put the screens down and go look at something.

Demo

The flow: pick your explorer → get a mission → tap listen → a warm voice reads it aloud → pocket the phone and head out → come back for the payoff that connects what you found to the security concept.

Code

Tash925 / security-dictionary-trail-edition

Cybersecurity, learned outside — kid-friendly outdoor missions powered by local Gemma + ElevenLabs. Hacktoberfest 2026.

The Security Dictionary: Trail Edition 🌿

Cybersecurity, learned outside. An offline tool that turns security concepts into kid-friendly outdoor missions — so the phone goes in your pocket and the learning happens in the real world.

Built for the Hacktoberfest 2026 Open-Source AI Challenge, Week 1: Touch Grass.

A branch of The Security Dictionary by DataSec Chronicles.

What it does

Pick an explorer age, a place, and how long you've got. The tool gives you a security concept framed as a mission you do outside:

IOC → find three clues something was here before you
Alert → notice what grabs your attention
Firewall → find barriers that let some things through and keep others out
Encryption → invent a secret signal only you and a friend understand
Phishing → spot something tempting — feel the pull, but don't go to it

A warm voice reads the mission aloud, so…

View on GitHub

The whole thing is one self-contained HTML file plus the mission prompts and the generated narration — no build step, no framework. The prompts/ folder has the exact template and safety constraints used to generate the missions.

How I Built It

Local open-weight model — Google Gemma, via Ollama (gemma2:2b).

Every mission is generated locally by Gemma. The model takes one security concept plus the child's age and writes a fresh, age-appropriate mission — the same concept becomes a different mission each time, which a static list of scavenger hunts could never do. That variety is the whole reason to use a model at all.

The interesting engineering was constraining a tiny local model to behave. A 2B model drifts — it invents unsafe suggestions, slips into markdown, pads and repeats. Getting it to reliably produce a safe, structured, age-appropriate mission took real prompt-tuning: too loose, and it invented things that weren't there; too tight, and it dropped the actual teaching. The balance point is the technical heart of this project. The safety block in the prompt is explicit — the model is told never to have a child touch, taste, chase, approach anything unfamiliar, enter unsafe areas, identify or eat plants, or leave their adult's area. Generative output aimed at children needs constraints built for the context it runs in.

I generated each of the five concepts across three reading levels (5–7, 8–10, 11–13) — fifteen missions — then baked them into the page so it runs with no model server and no internet.

Voice — ElevenLabs.

The narration is pre-generated with ElevenLabs and embedded in the page, so it plays offline once loaded. Voice here isn't a feature I bolted on because this was an AI challenge. I added it because requiring a child to read generated instructions would undermine the entire premise — the interface needed to disappear so the kid could listen, pocket the phone, and go. For a kid who finds reading hard, that's not a convenience; it's what makes the tool usable at all. Not every kid learns best by reading.

Why Does Open Innovation Matter?

Three reasons, and they're the reason the project holds together rather than nice-to-haves:

It runs offline. On a trail, in a backyard, anywhere with no signal. A cloud API can't promise that.
No child's data leaves the device. This is a tool for kids. A cloud-based version would send a child's inputs to someone else's server. Running an open model locally means it never has to — and as a security person, that's the difference between a tool I'd hand my own kids and one I wouldn't. For a children's tool, local isn't a performance choice. It's the whole reason it can be trusted.
It costs nothing to run, so any family or classroom can use it, not just ones who can afford API bills.

The open pieces aren't decoration. They are the project.

How It Went (I took it outside)

I tested it with a kid in my target age range. I let her drive — press the buttons, hit "Give me a mission." She got Firewall, tapped listen, and smiled at the voice. Then she went and found the fence in the backyard, and said she understood the concept better having found it first. I could see her following along as the voice spoke — the screen genuinely receded. Her words: "I really like this."

And it did the one thing the theme asks for: it got us outside to look around.

It also gave me a real finding. On the 11–13 tier — which currently falls back to a plain browser voice instead of the ElevenLabs narration — she immediately didn't like it. That told me the voice isn't a nice-to-have; it's load-bearing for whether a kid stays engaged. Next build: real voice across all three age tiers, not just 8–10.

Prize Categories

Best Use of Gemma — Gemma (open-weight, via Ollama) generates every mission locally. It's the engine of the whole tool.
Best Use of ElevenLabs — ElevenLabs gives the missions a voice, which is what lets a child listen instead of read and actually put the screen away.

Built with 💜 by DataSec Chronicles. The tool changes, the question doesn't.

Does This Belong Here? I Built a Phishing Checker for the People I Love

Tasha · DataSec Chronicles — Sat, 03 Oct 2026 16:04:20 +0000

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend

What I Built

"Does This Belong Here?" — a friendly phishing checker for the people in my life who still get spam.

I built it for my mom and my husband. They both know the basic rule — don't click suspicious links — but nobody ever explained the why, and the why is the part that actually protects you in the moment. When a real scam email lands, dressed up to look urgent and official, the rule evaporates, and the panic takes over.

This tool closes that gap.

You paste in an email or text that feels off, and it walks you through it the way a security analyst would — in plain English, no jargon. It gives a one-line verdict, a short list of the red flags it spotted and why each one matters (the threat behind it), and one calm next step.

Every answer ends with the question that keeps you safe:

"Does this belong here?"

It's not trying to make anyone a security expert. It's trying to hand them the instinct — the same "does this belong here?" question a SOC analyst asks on every alert, pointed at their own inbox.

I handed it to my husband. Here's what happened.

This is the part I care about most, because the challenge is Build for a Friend — so I actually gave it to one.

I set it up and let my husband loose on it with a real email. He copied a whole message, pasted it into the box... and then tried to click the box, expecting something to happen.

I had to point him to the "Check it for me" button.

Noted. 😂

It was a real, humbling piece of UX feedback. Building for non-technical people means watching exactly where they get stuck, and he found my blind spot in about ten seconds.

Then the "Thinking like an analyst..." screen came up, and when the verdict appeared, he was genuinely a little surprised it had actually read and understood the email.

He went through the breakdown, agreed with every red flag it found... and said:

"Good job."

That was the whole goal in one sentence.

Not "wow, impressive AI" — just a regular person reading a plain-English explanation of a suspicious email and trusting it enough to agree.

That's the tool working.

Demo

Try it live: 👉 labs.datasecchronicles.com/tools/does-this-belong-here

The app itself runs in your browser — there's no DataSec Labs backend, and I don't store your message or API key.

To use the live version, you'll need a free Google AI Studio API key. Your message is sent directly from your browser to Google's Gemma API for analysis.

Because Gemma is open-weight, this same concept can also evolve into a fully local version where analysis happens on your own machine instead of sending the message to a cloud API.

Code

Tash925 / does-this-belong-here

A friendly phishing checker built with Gemma (open-weight AI) — plain-language scam detection for non-technical people. #Hacktoberfest

🛡️ Does This Belong Here?

A friendly phishing checker for the people in your life who still get spam.

Paste in an email or text that feels off, and it walks you through it the way a security analyst would — in plain English, no jargon. One-line verdict, the red flags it spotted and why each one matters, and one calm next step. Every answer ends with the question that keeps you safe: "Does this belong here?"

Built with Gemma, Google's open-weight model, for the Hacktoberfest 2026 "Build for a Friend" Weekend Challenge.

Part of DataSec Chronicles — storm to SOC, finding what doesn't belong.

Why I built it

My mom knows not to click the link. My husband does too. Most people have picked up the don'ts — but nobody ever explained the why, and the why is the part that actually protects you when…

View on GitHub

It's a single self-contained HTML file — one page, no build step, no backend. The whole thing is HTML, CSS, and a little JavaScript, deliberately low-code so the idea and the writing carry it.

How I Built It

The core is Gemma, Google's open-weight model, doing the actual analysis.

The app:

Takes the suspicious message the user pastes in.
Sends it to Gemma with a carefully written system prompt that tells it to act as a warm, plain-spoken helper for a non-technical person — give a verdict, name the red flags with the reason each one matters, and never shame the person for asking.
Returns a clean, structured answer anyone can act on.

The interesting engineering wasn't the plumbing — it was the prompt.

Getting an open model to explain phishing the way a kind, patient expert would took real iteration, especially getting it to stop showing its reasoning scratch work and just hand over the finished answer.

I also made the app query which models my key can actually use and automatically pick an available Gemma, so it doesn't break when model names change out from under it — which they did, mid-build.

Why Does Open Innovation Matter?

Because of whose data this is.

The whole point of this tool is to check a real email — which often contains personal details, names, account references, and private information.

The live version currently sends that message directly from the user's browser to Google's Gemma API for analysis. DataSec Labs doesn't receive or store it.

But building around an open-weight model creates another possibility: local-first analysis.

The same idea could run with Gemma entirely on the user's own computer through something like Ollama. In that version, the suspicious email wouldn't need to leave the person's machine at all.

That's especially important for a tool designed for people who may already be vulnerable to scams.

Open innovation gives developers the option to move beyond "paste your private information into someone else's cloud" and build tools where users can retain much more control over their own data.

For a small, personal safety tool like this, that isn't just an interesting technical option.

It's part of what makes open models worth building with.

Prize Categories

Best Use of Gemma — Gemma (Google's open-weight model) is the engine doing all the phishing analysis.

I'd Love Your Feedback

I built this because knowing the rule "don't click suspicious links" and recognizing why something is suspicious in the moment are two different things.

If you try Does This Belong Here?, I'd love to hear what you think — especially if there's something that could make it easier for a non-technical person to use.

And if you have questions about the build, Gemma, or what I learned testing it with my husband, leave them in the comments. 💜

Built as part of DataSec Chronicles — storm to SOC, finding what doesn't belong. 💜