OSINT Toolkit: a local Docker workspace for IOC lookups, email analysis and Sigma rules

A prototype that puts fifteen services behind one local interface

OSINT Toolkit is a fullstack web application for security analysts, self-hostable and run on demand in a Docker container. The pitch in the README is consolidation: it brings various security tools into a single environment to shorten everyday work, and it adds generative AI to support analysis and decision making.

The scope is deliberately narrow in one direction and wide in another. It is not a data lake or a case management system. The README states that it is optimized for single-user operation, runs locally in a Docker container, and is not intended for long-term data storage or management. What it is for is accelerating daily workflows, with news aggregation and analysis, IOC and email investigations, and the creation of threat detection rules named explicitly.

That framing matters for anyone evaluating it, because it changes what you should hold it to. A single-user, local, on-demand tool is judged on how fast it gets an analyst to an answer. A shared platform is judged on availability, concurrency and retention, and this project does not claim any of those.

The repository layout follows the shape of the application: a backend/ directory, a frontend/ directory and a docker-compose.yaml at the root, plus a .github/ directory, a CONTRIBUTING.md, a FUNDING.yml, a LICENSE file and a NOTICE file. The primary language is JavaScript, and the licence is AGPL-3.0, which the README spells out in plain terms rather than leaving to the licence text alone.

The README opens with a warning that should be quoted rather than paraphrased: OSINT Toolkit is not production ready yet, and it is an early prototype that still needs some work. For a tool that reaches out to many third-party services and stores investigation data, that sentence is the most important line in the document for a prospective user.

One query routed to the right services by indicator type

The IOC Tools module is the core of the platform, and its design decision is type detection rather than service selection.

The module analyses indicators of compromise such as IP addresses, hashes, email addresses, domains and URLs. It queries services like VirusTotal, AlienVault, AbuseIPDB, along with social media platforms like Reddit and Twitter. The key mechanism is stated plainly in the README: the module automatically detects the type of IOC being analysed and uses the appropriate services, so the analyst does not have to know which feed answers which question. The service list in the README is large. For IP addresses it names AbuseIPDB, Alienvault, Checkphish.ai, CrowdSec, GitHub, IPQualityScore, Maltiverse, Pulsedive, Shodan, ThreatFox, Twitter and Virustotal. For domains and URLs the list includes Google Safe Browsing and URLScan. For emails, Emailrep.io, Hunter.io, Have I Been Pwnd and Maltiverse appear. For hashes, Alienvault, GitHub, Maltiverse, Pulsedive, Reddit, ThreatFox, Twitter and Virustotal. For CVEs, GitHub and NIST NVD.

That table is also a dependency list, whether or not the README frames it that way. Each of those services needs an account, and many need an API key, so the real setup cost of this tool is partly the number of external accounts you have to register for.

Analysis works one indicator at a time or in bulk, and the module supports fanging and defanging, which the README describes as a way to share IOCs safely. Defanging is the practice of breaking up a URL or domain so that it does not become clickable in a document or a chat message, and the round trip matters when an analyst has to move a suspicious indicator from a tool into a ticket without tripping a scanner on the way.

The type detection also means the module's behaviour for a given input depends on what a third party returns, which is the main source of unpredictability in the tool.

The Newsfeed extracts indicators from articles as you read them

The Newsfeed module is a different kind of feature, and arguably the one that changes the analyst's habits most.

It aggregates cybersecurity news from sources the README names, including Wired, The Hacker News, Security Magazine, Threatpost, TechCrunch Security and Dark Reading. The stated purpose is to keep you current on industry trends and potential threats without visiting multiple websites or subscribing to numerous newsletters.

The part that matters more than the aggregation is what happens next. The module extracts IOCs automatically from the news articles, and lets you analyze the news using AI. That is a different workflow from the IOC Tools module, where you bring an indicator and ask about it. Here the indicator arrives as a by-product of reading, and the article becomes the pivot rather than the query.

For a detection engineer, that inversion is the interesting part. A rule author normally starts from an adversary or a technique and works backwards to a pattern. A newsfeed that extracts indicators from reporting gives the same rule author a stream of candidate indicators, dated and attributed, which is a different and arguably better starting point for writing Sigma or Yara content.

The AI involvement sits on top of that. The README mentions AI analysis in the Newsfeed module, in the Email Analyzer, and in a dedicated AI Templates module, and the overall positioning of the project is that AI capabilities provide additional support for analysis and decision making. The AI Templates module is described as offering AI-based solutions for log data analysis, email text analysis and source code explanation, letting you create templates for AI tasks and supporting you in the prompt engineering process.

That last point is worth a caveat. An AI Templates module that stores prompts is a module that stores prompts, and in a security tool the content of those prompts will often contain indicators and email content pulled from investigations. The README does not describe what is sent to which model provider, or whether any of it leaves the container, and for a tool that aggregates news and pulls in live API responses from a dozen services, that is a question to answer before a real investigation runs through it.

Drag an .eml in, get a parsed message and its indicators

The Email Analyzer is the most concrete of the modules, and the easiest to understand from the documentation.

The workflow is drag and drop. You drop an .eml file into the module, and it parses the file, performs basic security checks, extracts indicators of compromise, and analyzes the message with the help of AI. The extracted IOCs can then be analyzed using the various open source intelligence services, which is the handoff into the IOC Tools module.

The design choice worth noting is the file format. Working from a saved .eml rather than from a live mailbox means the analyst can analyse a message that has already been quarantined, forwarded to a shared mailbox, or exported from a ticketing system, and it means the analysis does not require credentials for the mail system. It also means the tool handles one message at a time, by hand.

The basic security checks are described only as basic. The README does not enumerate them, does not say which header anomalies are detected, and does not describe any attachment handling. For a module whose output feeds an analyst's decision about whether to escalate, that is the detail to probe first.

Two other modules round out the platform. The CVSS Calculator computes the CVSS 3.1 score of a vulnerability and exports the calculation as a markdown or JSON file, which is convenient for attaching the score and the vector to a write-up. The Detection Rules module is a graphical interface for creating Sigma, Yara and Snort/Surplicate rules, and the README is careful to call it a GUI for creating rules rather than a rule engine, so it is an authoring surface and not a place to run detection logic.

Deploying with docker compose, and the migration you will need

Deployment is a Docker Compose workflow, and the README documents four steps. Download the repository and extract the files, navigate to the directory where the docker-compose.yaml file lives, run docker-compose up -d, and once the container is running, open the application in the browser at http://localhost:4000.

The compose file in the repository root shows what is being started. There is a backend service built from the ./backend context with its own Dockerfile, named backend, with a volume mapping ./data to /backend/data, attached to a bridge network called otk-network. There is a frontend service built from ./frontend, also on otk-network, and it publishes the port mapping 4000 to 80, which is where the local address in the README comes from:

  frontend:
    networks:
        - otk-network
    build:
      context: ./frontend
      dockerfile: Dockerfile
    container_name: frontend
    ports:
      - "4000:80"

The one extra step is the migration. The README says that if the database schema changed, you run a migration before starting the container:

docker compose run --rm backend alembic upgrade head

Alembic appears in that command, and the backend service is where it runs, which tells you the backend holds a relational database with versioned migrations. The ./data volume is how the data survives a container rebuild.

One note on the compose file, because it will bite someone. The backend service declares no ports mapping, only the frontend does. The backend is reachable on the internal bridge network, and it is the frontend container that is exposed to the host. That is a sensible arrangement for a local single-user tool, and it also means the backend is not directly addressable from the host without a change to the compose file.

AGPL-3.0, the licence change, and a prototype you should not expose

Two things about the licensing deserve close attention, and the project is unusually clear about both.

First, the licence moved. The release history shows v0.1.0 on 2026-04-12 described as the last release under the MIT License, v0.2.0 on the same day described as the transition licence from MIT to AGPL-3.0, and v1.0.0 on 2026-04-15. The README states that versions up to and including v0.1.0 were released under the MIT License and remain available under those terms. So the code you may have seen referenced elsewhere under MIT is only MIT up to that point, and the current tree is AGPL-3.0.

The README spells out what that means in its own words: you are free to use, modify and distribute the software, provided that any modified versions or services built on it are also made available under AGPL-3.0, including when offered as a network service. The phrase about network services is the part that matters for a web application, and it is why the commercial licence option exists. The README says that if AGPL-3.0 does not fit your use case, for example integrating OSINT Toolkit into a proprietary product or offering it as a managed service without open-sourcing your modifications, a commercial licence is available, with a contact address given. That is a legal matter for your own counsel, and this review is not interpreting the terms.

Second, the maturity question is separate from the licence question. The README's warning that the project is not production ready, plus the stated single-user optimisation and the explicit note that it is not intended for long-term data storage, together say that this is a workstation tool. Running it locally on a laptop for your own investigations is the intended use. Exposing it on a network, pointing a team at it, or relying on it to hold case data would all be going beyond what the documentation claims.

On maintenance, the repository is not archived and the last push was on 2026-04-28, which is close to six months before this review. The v1.0.0 tag and the licence change are both from April 2026, so the project reached a 1.0 milestone and then went quiet. The README does not say why, and there is no statement about ongoing development.

Editorial conclusion

OSINT Toolkit fits a security analyst who wants one local interface instead of fifteen browser tabs, who can run a container on a laptop, and who is comfortable running a prototype that the README describes as not production ready. It is the wrong choice for team deployment, for long-term case storage, or for an organisation that cannot accept AGPL-3.0 obligations without buying a commercial licence, since the project states that modified versions and network services must be made available under AGPL-3.0. Before you deploy it, read the LICENSE and NOTICE files at the repository root, run the alembic migration command the README lists whenever the database schema changes, and remember that the tool is optimised for single-user operation and is not meant for long-term data storage.

Frequently asked questions

Official sources

1. dev-lu/osint_toolkit on GitHub
2. Issues
3. License: AGPL-3.0
4. README
5. Releases