Cyberbro and the one-button reputation check for pasted indicators

Paste the garbage, get the reputation back

The project describes itself as a simple application that extracts your IoCs from garbage input and checks their reputation using multiple services, and the summary of what it is for is more specific: a simple and efficient way to check the reputation of your observables using multiple services, without having to deploy a complex solution.

That last clause is the design brief. The project is inspired by Cybergordon and by IntelOwl, both of which are substantial platforms, and Cyberbro's position is that a full threat intelligence platform is the wrong shape for a lot of cases. The scenario it targets is an analyst with a chunk of pasted log output or a list of indicators and a need to know which ones have been seen before. Doing that by hand means opening a dozen browser tabs, one per service, and pasting the same value into each.

So the input is deliberately loose. The Easy Input feature is paste raw logs or IoCs with automatic parsing and extraction, and the project lists advanced TLD extraction as a differentiator, described as accurate root domain detection for better lookups, and pragmatic data gathering that uses GitHub and Google to find overlooked IoCs.

The output side is a consolidated view. Multi-service checks cover reputation lookups for IPs, hashes, domains, URLs and Chrome extension IDs, and Chrome extension ID lookup is called out separately as a capability, since it returns extension names and CTI data from an ID rather than a domain.

The demo is at demo.cyberbro.net, and the documentation is at docs.cyberbro.net. There is also a note about using Cyberbro with an LLM through MCP for custom reports, with a separate repository for the MCP side.

The engine list is the product, and it is long

The configuration file is the clearest way to see what the tool actually does, and it is a long list of service credentials.

The sample env file names the engines and their credential variables: `ABUSEIPDB`, `ALIENVAULT`, `CRIMINALIP_API_KEY`, `DFIR_IRIS_API_KEY`, `DFIR_IRIS_URL`, `GOOGLE_CSE_CX`, `GOOGLE_CSE_KEY`, `GOOGLE_CSE_URL`, `GOOGLE_SAFE_BROWSING`, `HISTER_TOKEN`, `HISTER_BASE_URL`, `IPAPI`, `IPINFO`, `MISP_API_KEY`, `MISP_URL`, `OPENCTI_API_KEY`, `OPENCTI_URL`, `RL_ANALYZE_API_KEY`, `RL_ANALYZE_URL`, `RANSOMWARE_LIVE_API_KEY`, `ROSTI_API_KEY`, `SHODAN`, `SPUR_US`, `THREATFOX`, `VIRUSTOTAL` and `WEBSCOUT`.

The ones with a second variable, a client id and a secret, are the enterprise integrations: `CROWDSTRIKE_CLIENT_ID` with `CROWDSTRIKE_CLIENT_SECRET` and a `CROWDSTRIKE_FALCON_BASE_URL`, and `MDE_CLIENT_ID` with `MDE_CLIENT_SECRET` and `MDE_TENANT_ID` for Microsoft Defender for Endpoint. The `DFIR_IRIS_URL` and `MISP_URL` entries point at your own instances, and `OPENCTI_URL` shows a demo OpenCTI endpoint as the example.

The integrations list in the features section names Microsoft Defender for Endpoint, CrowdStrike, OpenCTI, Grep.App, Hudson Rock, and more, and adds an EDR Integration feature described as checking observables against your own security tools. That is the part with the most operational value for a team that already runs an EDR, because the lookup goes to an endpoint you own rather than to a public reputation service.

The readme also lists CTI Report Integration, fetching IoC related reports from IoC.One, and the requirements list confirms the CrowdStrike path with `crowdstrike-falconpy` as a dependency, alongside `ioc-fanger` for the extraction and `tldextract` for the domain handling.

Pivoting, caching and the report format

Beyond the reputation lookups, the tool does a few things that turn a lookup into an investigation.

Automated pivoting discovers related domains, URLs and IPs via reverse DNS and RDAP or Whois, and there is a separate feature for accurate domain and abuse information through RDAP or Whois and abuse contact lookups. The `querycontacts` dependency in the requirements file is what resolves those abuse contacts, and `dnspython` handles the reverse DNS side.

Processing is multithreaded for speed, which matters when a pasted log yields dozens of indicators and each one is a network call to a third party.

Caching is described as caching for faster repeat lookups, and there is a parenthetical detail that matters: it is enabled at multi-engines level, not each engine. So the cache sits above the individual services rather than inside each one, which means a repeat lookup of the same indicator is one call rather than one call per configured service.

Results are stored in SQLite, and the reports support advanced search, filtering, and export to CSV or Excel. The `openpyxl` and `pandas` dependencies in the requirements file are the Excel and data handling side of that.

There is also an analysis history and an experimental graph view. The demo screenshot in the readme shows a graph, and the feature list calls the graph view experimental, which is worth taking at face value when you are deciding whether to build a workflow on it.

The proxy support in the same list is what you need when the environment cannot reach the services directly, and the readme warns separately to be careful if a proxy is used.

Docker is the intended path, and the .env file is mandatory

The installation instructions are unusually direct, and the mandatory part is the configuration file.

The tip at the top of the getting started section says if you are lazy, you need Docker, and gives the whole sequence: do a `git clone`, copy `.env.sample` to `.env`, `docker compose up`, then go to `localhost:5000`.

The clone step is:

git clone https://github.com/stanfrbd/cyberbro
cd cyberbro

and copying the sample config is the step the documentation labels mandatory:

cp .env.sample .env

You can leave the optional values empty. The note says that if you do not have API keys, no problem, just copy `.env.sample` to `.env` and leave optional values empty, and that you will be able to use all free engines.

The Docker launch is a single command:

docker compose up # use -d to run in background and use --build to rebuild the image

and the application is then at http://127.0.0.1:5000. There is a warning that matters if you have used the older tool: make sure you install the `compose` plugin as `docker compose` and not `docker-compose`. And a second warning that catches people out: in Docker, the app binds to `0.0.0.0` inside the container even if your local `.env` sets `FLASK_HOST=127.0.0.1`. The compose file confirms it, with `FLASK_HOST=0.0.0.0` hardcoded in the environment block, alongside `FLASK_PORT=${FLASK_PORT:-5000}` and the port mapping `${HOST_PORT:-5000}:${FLASK_PORT:-5000}`.

The older path is also documented: clone the repository and install the requirements, and you might want to create a `venv` before installing the dependencies.

Secrets, the version check, and a retired configuration format

Three operational details in the documentation are worth pulling out, because each one is the kind of thing that bites a team deployment.

First, the secrets warning. The documentation states that `.env` contains sensitive secrets and must never be committed, and for production or team deployments, use SOPS, Vault, or an equivalent secret manager workflow. The sample file repeats it, telling you to copy it to `.env` and fill in your API keys, and that you should not commit this file to your version control system.

Second, there is a version check that reaches out. The sample env file documents a `DISABLE_VERSION_CHECK` setting, to set to true to disable the version check and suppress the new update available popup, described as useful for air gapped or managed deployments where the check is unnecessary, with the default being false so the version check is enabled. The comment also covers SSL verification, with a note that setting it to true to enable SSL verification for API requests is recommended for production environments and false for development.

Third, an old configuration format was removed. Starting with version `v0.13.0`, Cyberbro no longer supports `secrets.json` and the `/config` page, with a link to a discussion on the subject, and a conversion path for anyone who still has a legacy file: `python3 scripts/secrets_json_to_env.py`.

That last one is a small migration note that says something about the project's pace. A configuration mechanism and an admin page were removed within a version, with a script provided to convert old files, and the CHANGELOG or the release notes are where a team upgrading from an older version would look for more detail.

The container runs as a non-root user, and the release notes show the churn

The Dockerfile shows a hardening decision that is worth calling out, because it is not the default shape for a Flask application.

The base image is `ghcr.io/astral-sh/uv:python3.13-bookworm-slim`, so the Python environment comes from uv rather than a plain Python image. The container starts as root, with the comment that root is kept for startup bootstrap tasks such as ownership migration, and then privileges are dropped. A `cyberbro` group and user are created with configurable `APP_UID` and `APP_GID` build arguments defaulting to 1000, the working directory is `/app`, the requirements are installed with `uv pip install --system --no-cache-dir -r requirements.txt`, and `/var/log/cyberbro` and `/app/data` are created and handed to the unprivileged user.

The privilege drop is done in two steps. `gosu` is installed, the entrypoint is `./prod/bootstrap.sh`, and the comment says the app entrypoint is executed by bootstrap as the unprivileged user, with `CMD ['./prod/entrypoint.sh']`. So there is a deliberate root to non-root handoff at startup rather than a container that simply runs as root, which is the right default for something that holds threat intelligence API keys.

The release notes show a project moving quickly. v0.15.3 on 2026-09-29 was a CSE endpoint config and dependencies update, v0.15.4 on 2026-10-02 fixed exact text search in the Hister search engine, and v0.15.5 on 2026-10-18 covered Scanmalware engine updates, an OpenCTI exact search fix and dependency updates. Two of the three most recent releases are search fixes in specific engines, which tells you that the engine integrations are where the maintenance effort goes, and that a given service can change its search behaviour under you.

The repository also carries a `ROADMAP.md`, a `SECURITY.md`, an `AGENTS.md`, a `tests/` directory with a `pytest.ini`, and per-engine directories under `engines/`, with `models/`, `utils/`, `templates/`, `static/`, `docs/`, `prod/` and `scripts/` alongside them.

Editorial conclusion

Cyberbro fits a threat hunting or SOC analyst doing quick triage on a batch of pasted indicators, who wants one screen that says which of them have been seen before, and who is comfortable wiring in API keys for the services they have accounts with. It is the wrong tool for a case that needs defensible evidence, since the tool is built for fast lookups rather than for a chain of custody, and it is the wrong tool if you cannot reach the threat intelligence services it depends on. Before you deploy it, verify three things: which engines are free and usable without keys, since the documentation says leaving optional values empty still gives you all the free engines, that `.env` handling matches your secret management, because the readme warns it holds sensitive secrets and must never be committed, and that the version check is disabled for an air gapped deployment, which the sample config offers as `DISABLE_VERSION_CHECK`. The code is MIT licensed, the last push was on 2026-10-19, and the newest release is v0.15.5 from 2026-10-18.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. stanfrbd/cyberbro on GitHub