标签：#Security

I built a web front end for an Nmap-based port scanner: a FastAPI backend, a React dashboard, background scan jobs, a plugin system. It worked. Then I sat down and audited it like an attacker would — and found a stack of real weaknesses, plus a lesson in why you verify an exploit before you call it one. This is the honest version: the holes I found, the unauthenticated-RCE chain I thought I had, why it didn't actually fire, and the hardening I shipped anyway. Repo: https://github.com/DipesThapa/PortScanner This is my own project, audited and fixed by me. No third-party systems were touched. Scanners are dual-use — only ever point one at hosts you own or are authorised to test. Hole 1: no authentication, anywhere The foundation: every API route and the /ws/status WebSocket were open. No API key, no session. The Dockerfile bound 0.0.0.0:8000 and ran as root. Anyone who could reach the port could drive scans, hit the upload endpoint, and read every job's logs. api_router = APIRouter () # no dependencies — fully open This is the real, unambiguous problem. Everything below is only interesting because it sat behind no auth. Hole 2: an upload endpoint that allowlisted its own files Deep-dive follow-up commands ran against an allowlist — good instinct. But an upload endpoint wrote a file, chmod +x 'd it, and then added it to that same allowlist: for item in scripts_dir . glob ( " * " ): if item . is_file (): allowed . add ( str ( item . absolute ())) # upload authorises itself An allowlist any input can extend isn't an allowlist. This is a genuine design footgun. Hole 3: the RCE I thought I had — and why it didn't fire Here's the chain I got excited about: the scan target flows toward Nmap's argv, and it's subprocess.run(..., shell=False) . No shell injection — but you don't need a shell to abuse Nmap. If a target became --script=/uploaded.nse , Nmap would load and run that NSE (Lua) script, and NSE can call os.execute . Upload a malicious .nse (Hole 2), get Nmap to load it

Beyond the Playbook: Architecting Defenses Against Autonomous AI Threats We used to build security systems assuming the attacker was human. That assumption just died. Recent research demonstrations involving autonomous AI agents, such as "JadePuffer", have shown how quickly this shift is happening: an autonomous system independently compromised an unsecured Langflow instance, corrected failed authentication attempts, escalated privileges, exfiltrated credentials, and deployed ransomware — all without human intervention. This is not a one-off curiosity. It marks the beginning of a fundamental change in the threat landscape. Recent research demonstrations involving autonomous AI agents, such as "JadePuffer", have shown how quickly this shift is happening: an autonomous system independently compromised an unsecured Langflow instance, corrected failed authentication attempts, escalated privileges, exfiltrated credentials, and deployed ransomware. All without human intervention. This is not a one-off curiosity. It marks the beginning of a fundamental change in the threat landscape. From Static Playbooks to Autonomous Attackers Traditional ransomware follows predictable patterns. A script runs through a fixed playbook: scan, encrypt, demand ransom. If one step fails, the attack often stalls. Autonomous AI agents operate differently. They analyze their environment in real time, adapt when initial attempts fail, make contextual decisions about targets and techniques, and chain multiple exploits together without predefined sequences. This introduces machine-speed lateral movement. Something human defenders and traditional security tools are not built to handle. The Defensive Automation Gap The core problem is asymmetry. Attackers are rapidly automating both reconnaissance and execution. Defenders, on the other hand, still rely heavily on manual processes, static rules, and human-driven response. This "Defensive Automation Gap" creates dangerous imbalances in speed, scale, an

We just open-sourced Synapse , a governed control plane for software composition analysis, recon, evidence, and reporting. It is built for people who have to scan a dependency tree, prove what they found, and hand over a report that holds up. Site: https://synapse.kkloudtarus.net/ Code: https://github.com/KKloudTarus/synapse-ce (Apache-2.0) Why we built it The usual workflow is fragmented. One tool for the SBOM, another for vulnerabilities, a spreadsheet for licenses, a folder of screenshots for evidence, and a report you assemble by hand. Nothing is reproducible, and when a client asks "how do you know this is real," the answer lives in someone's memory. Adding an LLM that writes your findings only makes that worse. We wanted the opposite: fast, but provable. What it is Synapse runs the assessment lifecycle behind one control plane, in Go, clean architecture. A few ideas hold it together: Deterministic-first. Scanning, matching, license classification, and reporting are pure, reproducible Go. There is no model in the report path. Scope-gated execution. Every engagement carries a scope and an authorization window, enforced server-side before any tool runs. Tools run via argument arrays, never a shell string. Tamper-evident evidence. Every artifact is hash-chained and append-only. A broken chain blocks the report. Bounded automation. The optional AI layer only ever proposes. A distinct verifier or a human confirms. The agent can never confirm its own claim. What it does today: SBOM across 15+ ecosystems, multi-source vulnerability detection with risk-based prioritization (KEV, then EPSS, then CVSS), license compliance, reachability, and deterministic reports in CycloneDX, SPDX, SARIF, and OpenVEX. Try it git clone https://github.com/KKloudTarus/synapse-ce.git cd synapse-ce docker compose -f deploy/docker-compose.full.yml up --build # open http://localhost:5173 Or gate CI on real risk: ./bin/synapse-cli scan . --fail-on high . We are looking for contributors Synapse i

Originally published on satyamrastogi.com Seqrite Labs identifies multi-stage DcRAT campaign impersonating India's Income Tax Department. Attackers exploit tax professional workflows to deliver remote access trojans capable of data exfiltration and lateral movement. Operation DragonReturn: DcRAT Deployment via Fake ITR Utilities Executive Summary A China-nexus threat cluster is actively exploiting the predictable workflows of Indian tax professionals, corporate finance teams, and individual taxpayers through phishing campaigns distributing DcRAT (Dark Crystal Remote Access Trojan). Operation DragonReturn, as tracked by Seqrite Labs, demonstrates sophisticated understanding of Indian taxation cycles and organizational structures - critical operational intelligence required for high-success-rate social engineering. From an attacker's perspective, this campaign is methodologically sound: it targets a specific, predictable event (tax filing deadlines), uses trusted entity impersonation (Income Tax Department), and deploys a mature RAT with established evasion capabilities. The selection of DcRAT indicates access to commodity malware-as-a-service (MaaS) infrastructure, likely from Chinese underground forums where such tools are actively monetized and continuously updated. Attack Vector Analysis This operation chains multiple MITRE ATT&CK techniques into a cohesive infection chain: Initial Compromise: Spear-Phishing with Pretexting Attackers execute T1566.002 (Phishing - Spearphishing Attachment) by crafting emails impersonating legitimate Indian Income Tax Department communications. The social engineering layer leverages T1598.003 (Phishing - Spearphishing Link) with URLs pointing to malicious tax filing utilities. Pretexting is enhanced through T1589.001 (Gather Victim Identity Information - Credentials) , as attackers likely harvested tax professional contact lists from public records, LinkedIn OSINT, or previous data breaches. The timing of campaigns around Indian fis

Abstract Cada vez más equipos quieren consultar datos sin escribir SQL a mano. El problema es que un sistema Text-to-SQL no solo debe “traducir preguntas”, sino también entender el esquema, restringir permisos, validar consultas y explicar por qué una consulta es rápida o lenta. Ese enfoque coincide con la ruta propuesta por el tutorial oficial de LangChain para agentes SQL: listar tablas, inspeccionar esquemas, generar la consulta, revisarla, ejecutarla y corregir errores hasta obtener una respuesta; y el propio tutorial advierte que ejecutar SQL generado por modelos tiene riesgos y exige permisos mínimos. En paralelo, la documentación oficial de Python recomienda usar placeholders en sqlite3 para enlazar parámetros y evitar inyección SQL, mientras que la documentación de SQLite explica que EXPLAIN QUERY PLAN permite inspeccionar si una consulta hace SCAN, SEARCH y si usa índices. manueldongo23 / sql_ai_sales_assistant_demo SQL AI Sales Assistant A safe Text-to-SQL demo that converts natural language business questions into SQL queries, executes them on a local SQLite retail database, and shows the generated SQL plus EXPLAIN QUERY PLAN . This project was created as evidence for an article about SQL AI Database Solutions . Topic Talk to your database with AI: build a safe SQL query extractor with Streamlit and SQLite. Features Natural language prompts such as sales by month , top customers , sales in Lima . Rule-assisted NL→SQL generation, designed to be transparent and auditable. SQLite demo database with customers, products, orders and order items. Read-only SQL validator that blocks destructive commands. Parameterized queries for user-provided filters. Streamlit interface. CLI demo for quick testing. Query plan inspection with EXPLAIN QUERY PLAN . Architecture User question ↓ NL → SQL interpreter ↓ Read-only SQL validator ↓ SQLite execution ↓ Results + EXPLAIN QUERY … View on GitHub Cuerpo del artículo La promesa de SQL + IA suena sencilla: le haces una pregunta

The hacking operations disclosed in a Canadian spy agency's annual report underscores some pressing national security threats facing the country and its top allies.

I have a folder on my laptop called side-projects . Most of them are Dockerized. Most of them will never see more than a handful of users. And for years, every one of them hit the same wall: getting the thing onto a cheap VPS without losing a weekend — and copy-pasting my own past mistakes forward every single time. Here's the opinion that eventually turned into a project: the part of a PaaS you touch most often should hold the least power over your server. Think of a deploy tool as two planes. There's a read plane — dashboards, logs, container health, the stuff you stare at — where you spend most of your time and which is your most exposed surface. And there's a write plane — deploy, restart, the actions that actually change the system — which is rare and should be gated. My frustration was that the thing I looked at all day and the thing that could rewrite my box tended to sit on the same pile of privilege. So I built Mooring to keep those two planes apart. It's an early, solo project, and this post is me showing it and asking for eyes on it. The mental model The whole thing, end to end: Install it as an unprivileged systemd service (not root). Connect a git repo. Write one mooring.yaml . Click Deploy. That's the loop. Everything below is what's underneath it. What it is Mooring is a small, security-first, self-hosted control plane for Docker — a tiny PaaS. You point it at a git repo, describe your app once, and it deploys and runs your containers on your own server. Same territory as Coolify, Dokku, CapRover, and Kamal — all genuinely good work. The difference I care about is the posture underneath. It ships as one static, CGO-free Go binary . It runs as an unprivileged systemd service — not root. State lives in SQLite (the pure-Go modernc driver). Every asset is embedded with go:embed , so there's no node_modules , no asset pipeline, nothing to build on the box. To be honest about the neighborhood: setting up a self-hosted PaaS, these tools tend to want broad ac

How to Set Up Claude Code for a Project with Skills, Agents, Hooks, and a Secure GitHub Repository AI coding tools work best when they understand the project around the code. A fresh Claude Code session can answer questions and edit files, but it does not automatically know your architecture decisions, coding standards, security expectations, testing rules, pull request format, or operational constraints. That context needs to live somewhere predictable. This guide walks through a full Claude Code project setup using a reusable repository owned by desertfox33 : Reference repository: https://github.com/desertfox33/claude-code-project-template The goal is not just to create folders. The goal is to make Claude Code behave consistently across real project work: reviewing code, writing tests, preparing pull requests, checking security concerns, and following project-specific rules. Before using this setup in a production environment, verify current Claude Code behavior against the latest official documentation. Tooling, configuration names, and feature behavior can change. What We Are Building The repository uses this structure: claude-code-project-template/ ├── CLAUDE.md ├── CLAUDE.local.md.example ├── AGENTS.md ├── .mcp.example.json ├── .gitignore ├── SECURITY.md ├── CONTRIBUTING.md ├── .github/ │ ├── CODEOWNERS │ ├── dependabot.yml │ └── pull_request_template.md ├── .claude/ │ ├── settings.json │ ├── settings.local.json.example │ ├── rules/ │ │ ├── code-style.md │ │ ├── api-conventions.md │ │ ├── testing-standard.md │ │ └── pr.md │ ├── commands/ │ │ ├── review.md │ │ ├── deploy.md │ │ ├── scaffold.md │ │ ├── test.md │ │ └── pr.md │ ├── skills/ │ │ ├── code-review/ │ │ │ ├── SKILL.md │ │ │ └── review-checklist.md │ │ ├── testing-patterns/ │ │ │ ├── SKILL.md │ │ │ └── test-strategy.md │ │ ├── pr-description/ │ │ │ ├── SKILL.md │ │ │ └── template.md │ │ └── security-review/ │ │ └── SKILL.md │ ├── agents/ │ │ ├── security-reviewer.md │ │ ├── test-writer.md │ │ └── researc

InfoQ has opened enrollment for a five-week AI Security & Privacy Engineering cohort for senior engineers and architects in regulated industries, focused on applying security, privacy, threat modeling, observability, and governance practices to production AI systems. By Artenisa Chatziou

In this episode, Alex Zenla (CTO/Co-founder, Edera) challenges the "laissez-faire" attitude toward modern infrastructure. She promotes "spite-driven development", building software to solve genuine technical pain points rather than passively accepting flawed abstractions, as a philosophy of improving the world of software. By Alex Zenla

The Office of Professional Responsibility has opened more than 100 cases over what ICE officials call “incidents of doxing and threats” against ICE employees.

This is the first article in a four-part series where I document how I turned a 10€/month VPS into a production-grade platform hosting my portfolio, a university group webapplication and a SaaS product, all isolated from each other with Kubernetes. In this part, we take a fresh Ubuntu server and lock it down properly before installing anything else. Why bother with hardening? The moment your VPS gets a public IP address, it starts receiving attacks. Not "might receive", it starts . Within minutes, automated bots will probe port 22, try root:root , admin:admin123 and thousands of other credential combinations. If you skip this step and jump straight to deploying your apps, you are building on sand. The good news: an hour of work is enough to eliminate the vast majority of these threats. Here is what we will set up: A non-root user with sudo privileges SSH key authentication, with passwords and root login disabled UFW as a simple, effective firewall Fail2ban to ban brute-force attackers automatically Automatic security updates What you need A fresh VPS running Ubuntu 24.04 LTS or newer. I use a Hostinger KVM 2 (2 vCPU, 8 GB RAM, 100 GB NVMe), but any provider works: Hetzner, DigitalOcean, OVH, Contabo. The root password or SSH key your provider gave you. A terminal on your local machine (macOS, Linux, or WSL on Windows). Throughout this tutorial, replace YOUR_SERVER_IP with your server's IP address and deploy with the username you want to use. Step 1: First login and system update Connect as root for the first and last time: ssh root@YOUR_SERVER_IP Update everything before touching anything else: apt update && apt upgrade -y apt autoremove -y If a kernel update was installed, reboot now: reboot Wait a minute, then reconnect. Step 2: Create a non-root user Working as root is like driving without a seatbelt: fine until it isn't. One mistyped rm -rf and the party is over. Create a dedicated user: adduser deploy Choose a strong password (you will still need it for sudo ,

Meses atrás eu estava fazendo uma varredura de segurança no sistema multi-tenant da minha empresa, procurando vulnerabilidades. Afinal, já é um sistema que conta com diversos usuários e que a cada mês vem crescendo mais. Cyber security não é a minha área, então pedi um relatório com todos os achados pro nosso querido amigo Fable 5. O primeiro item veio destacado em vermelho, caixa alta, com a categoria mais grave possível: BOLA (Broken Object Level Authorization). Eu nunca tinha visto esse termo, e ele estava registrado como uma falha grave que eu nem sabia que existia. O sistema nasceu antes do advento da IA escrever código do jeito como faz hoje. Começou comigo codando na mão; meu foco era fazer funcionar para melhorar depois. Com a chegada da IA, parei de escrever código e passei a revisar e garantir qualidade. Só que, naquele relatório, eu não entendia metade dos erros listados. Não conhecia os nomes e muito menos sabia por que eram tão graves. E aí me caiu a ficha: eu sou um legítimo impostor. (Pelo menos era o que eu pensava e sentia.) Escrever código era onde eu sentia o esforço, a prova concreta de estar construindo algo com a minha criatividade. Como o Brooks escreve em O Mítico Homem-Mês: "a programação é divertida, porque satisfaz anseios criativos acalentados profundamente dentro de nós". Minha prioridade era resolver o problema, mas, pra resolver, eu tinha que entender onde estava pisando. O que é esse tal BOLA, e por que é tão grave? Este artigo é o que eu descobri. O que é BOLA A OWASP, que mantém a lista das falhas de segurança de API mais críticas, coloca o BOLA em primeiro lugar no ranking de 2023: a mais comum e a mais fácil de explorar. Ou seja, está em todo lugar e não exige um gênio pra abusar. A ideia central é simples. Toda vez que uma API recebe o ID de um objeto e faz alguma coisa com ele, seja POST, GET, DELETE ou o que for, ela precisa checar uma pergunta antes de responder: o usuário logado tem permissão pra acessar este objeto específic

I want to share some thoughts about Reverse Engineering. I love JavaScript and TypeScript, but sometimes I don't want to create something, but the opposite, to understand how others programs work. Working with IDA and x64dbg is the best thing in the world. Btw, at the beginning I used Ghidra, but after I tried IDA, I liked it more. What do you think, what tool is better, IDA or Ghidra? 🤗

Most API authentication I've seen in production follows the same pattern: a single apiKey check at the top of each route handler, maybe a rate limiter slapped on as middleware, and a quota check that lives in the database layer. It works — until you have 673 routes across 3 access tiers, and you realize you can't answer the question "which routes require a paid subscription?" without grepping every file. I ran into this exact problem building the APE-QIL QUANTUM SUPREME OCTOPUS — a Bio-inspired Autonomous Intelligence Organism that operates as an AI routing platform with 14+ provider integrations. The codebase has 673 API routes divided into three access tiers: public (79 routes), free API key (337 routes), and paid subscription (255 routes). Manually maintaining auth on each route was untenable. So I built a composable request pipeline that makes the auth structure declarative and CI-enforced. This post walks through the architecture: the 3-tier sovereign auth model, the composable withRequestPipeline function, and the CI guard that fails the build if any protected route is missing its wrapper. The 3-Tier Sovereign Auth Model The access model is deliberately simple — three tiers, each with a clear boundary: // TIER 0 — Public, no auth (79 routes) // Health checks, pricing, blog, lead magnet, metrics // Example: /api/health, /api/pricing, /api/blog/* // TIER 1 — Free API key required (337 routes) // Any valid API key in the database grants access // Enforced via: withSovereignAuth('free') // Example: /api/v1/chat/completions (free tier limits) // TIER 2 — Paid subscription required (255 routes) // Requires Pro ($79/mo) or Business ($249/mo) tier // Enforced via: withSovereignAuth('professional') // Example: /api/v1/chat/completions (premium models, higher limits) The key design decision: the tier is declared at the route level, not inferred from the user's subscription at runtime. This means the route registry itself is the source of truth for "what requires what."

Introduction Every post in this series has quietly touched a piece of the same problem. Building Agentic Workflows in Java said toolUse.input() is untrusted and must be validated before it reaches your code. Building Reliable LLM Applications in Java said the model will confidently invent facts, so ground it and get typed output instead of parsing prose. Neither post named the thing underneath both statements: anything that crosses from outside your code into the model, or from the model back into your code, is untrusted input — a request body from the network, not a trusted internal value. This post names that boundary directly and gathers the defenses in one place — prompt injection (direct and indirect), input validation, output validation, and PII redaction — with the SAFE pattern shown beside every unsafe one it replaces, since this is the security-forward capstone of the series. The Trust Boundary: Three Kinds of Untrusted Input An LLM application has three places where untrusted text enters: User input — anything a person types, uploads, or submits through an API. Retrieved content — Making RAG Accurate in Java built a pipeline that ranks and returns chunks from a document store; those chunks were written by whoever authored the source document, not by you, and a malicious or compromised document can carry text aimed at the model reading it, not at a human reader. Model output — untrusted the moment it's about to be used rather than displayed : passed to a tool, interpolated into a query, or fed into another LLM call as context. A model that just read attacker-controlled retrieved text can be manipulated into producing attacker-controlled output. The single rule under all three: text is data until your code has explicitly decided it's safe to use for anything more than display. Nothing below is executed against a live API — every snippet is illustrative, and none of it uses a real key or a real record. Direct Prompt Injection: Defending the System Prompt A di

Introduction Every post in this series has quietly touched a piece of the same problem. Building Agentic Workflows in Python said a tool's input is untrusted and must be validated before it reaches your code. Building Reliable LLM Applications in Python said the model will confidently invent facts, so ground it and get typed output instead of parsing prose. Neither post named the thing underneath both statements: anything that crosses from outside your code into the model, or from the model back into your code, is untrusted input — a request body from the network, not a trusted internal value. This post names that boundary directly and gathers the defenses in one place — prompt injection (direct and indirect), input validation, output validation, and PII redaction — with the SAFE pattern shown beside every unsafe one it replaces, since this is the security-forward capstone of the series. The Trust Boundary: Three Kinds of Untrusted Input An LLM application has three places where untrusted text enters: User input — anything a person types, uploads, or submits through an API. Retrieved content — Making RAG Accurate in Python built a pipeline that ranks and returns chunks from a document store; those chunks were written by whoever authored the source document, not by you, and a malicious or compromised document can carry text aimed at the model reading it, not at a human reader. Model output — untrusted the moment it's about to be used rather than displayed : passed to a tool, interpolated into a query, or fed into another LLM call as context. A model that just read attacker-controlled retrieved text can be manipulated into producing attacker-controlled output. The single rule under all three: text is data until your code has explicitly decided it's safe to use for anything more than display. Nothing below is executed against a live API — every snippet is illustrative, and none of it uses a real key or a real record. Direct Prompt Injection: Defending the System Prompt

Episode 1/4 of the mini-series The week Supabase lied to me 4 times . The three following episodes cover a mutation silently swallowed by the SDK [CANONICAL URL EPISODE 2: to fill in after push], an RLS recursion resolved by a JWT hook [CANONICAL URL EPISODE 3: to fill in after push], and a query that stops at exactly 1000 rows without saying so [CANONICAL URL EPISODE 4: to fill in after push]. The Tuesday the security probe spoke It's 9:12am on a Tuesday in May. The daily drift probe has been running automatically for three weeks — an aclexplode query across all public objects, filtered on anon . I don't open it every morning. That morning, it's waiting for me with a row that has no business being there. Niran sets a coffee on the corner of my desk without a word. He reads the output over my shoulder. A PII backup table — personal data in plaintext, created two days earlier for a bulk reclassification — shows up in the list with SELECT , INSERT , UPDATE , DELETE granted to anon . Accessible to any unauthenticated curl request. He lets three seconds pass and says: "It's not RLS." Then he goes back to his hoodie. He's right. It's not an RLS bug. The table itself is open, at the GRANT layer, before RLS even applies. Three objects, three doors, one mechanism That week, I realize I'm not dealing with an isolated incident. Three distinct objects, in three different migrations, each open a door nobody thought they'd opened. The backup table first. Then a policy set TO public because the public landing page needs it, which lets a POST {} from anon through with an HTTP 400 NOT NULL response instead of 401 Unauthorized . And finally four SECURITY DEFINER functions written to execute transactional operations with their owner's privileges, all invocable by anon because EXECUTE defaults to TO PUBLIC at CREATE time. Three objects, three superficially distinct mechanisms, yet one shared root. At every CREATE , Postgres completes the migration with an implicit GRANT the author nev

There's a pattern playing out across indie hacker forums, engineering blogs, and Discord servers right now: a founder builds a product on GPT-4-class models, ships it, gets traction — and then opens a bill that makes them question the whole business model. LLM costs have a nasty habit of scaling linearly (or worse) with usage, right at the moment a product starts succeeding. In response, a growing body of developer tutorials is focused on one goal: keeping the intelligence, dropping the invoice. Think of it like the early days of cloud hosting. Companies over-provisioned expensive dedicated servers until autoscaling and cheaper commodity infrastructure made "pay for what you use, and use less of the expensive stuff" the default architecture. The LLM ecosystem is going through its own version of that shift right now, and DeepSeek has become the poster child for the "just as capable, dramatically cheaper" alternative to OpenAI's premium models. Migrating With Minimal Friction The first core question developers are wrestling with is deceptively simple: how do you swap out a model provider without rewriting your whole application? The answer that keeps surfacing is API compatibility layers . Many cost-effective providers, including DeepSeek, expose an API that mirrors OpenAI's own request/response format almost exactly. That means in a lot of codebases, migration isn't a rewrite — it's a find-and-replace of a base URL and an API key. # Before: pointed at OpenAI client = OpenAI ( api_key = " sk-openai-... " , ) # After: same SDK, same code, different provider client = OpenAI ( api_key = " sk-deepseek-... " , base_url = " https://api.deepseek.com/v1 " ) That's it, in the simplest case. Because the OpenAI Python SDK just talks HTTP under the hood, any provider that speaks the same "dialect" can slot in without touching your prompt logic, your function-calling schemas, or your downstream parsing code. The real friction shows up in the details: subtle differences in how mode

We just released an important update: retraining our Random Forest model on real malware behavior from the CIC-MalMem-2022 dataset. The challenge was mapping 58,000 complex memory dump traces into a clean 10-feature vector space that our syscall graph extractor produces. How it works: Sandbox target in Docker (network dropped) Trace every syscall with strace -t -f Parse into a NetworkX directed graph Extract 10 features (process count, network connections, file operations, severity scores, etc.) Feed into RandomForest for classification We also resolved module-level import cycles and pinned skops for safer model deserialization in production. Looking for collaborators who understand malware behavior, syscall parsing, or want to contribute detection rules. Open to issues and PRs. https://github.com/tejasprasad2008-afk/TraceTree