OpenCTI is an open-source cyber threat intelligence platform that ingests, manages, and analyzes threat data using the STIX 2.0/2.1 standard. The system is a monorepo containing a Node.js/TypeScript GraphQL backend (opencti-graphql), a React/Relay frontend (opencti-front), a Python client library (client-python), and a Python worker service (opencti-worker). The backend uses Elasticsearch/OpenSearch as its primary data store, Redis for caching and pub/sub, RabbitMQ for connector queues, and PostgreSQL for migrations. The frontend provides full CRUD UIs, dashboards, workspaces, playbook automation, and workflow management. Key entry points include the GraphQL API (resolvers per entity type), the frontend React app with Relay data fetching, and the Python client for programmatic access. Data flows involve ingestion via CSV/JSON/TAXII/RSS feeds, manual creation, connector enrichment, and inference rules that automatically derive relationships. External dependencies include Elasticsearch, Redis, RabbitMQ, MinIO/S3 for file storage, and optional AI services. The platform supports enterprise features (playbooks, PIR, XTM Hub) gated by license checks.
Yeti is a threat intelligence platform that ingests, enriches, correlates, and stores cyber threat observables, entities, indicators (YARA, Sigma, Suricata, regex, forensic artifacts), and DFIQ investigative questions. It provides a FastAPI-based REST API for CRUD operations, graph traversal, semantic search (via ChromaDB), and RBAC. The system uses ArangoDB as its primary graph/document database, Redis for message brokering, and Celery for background task scheduling. It includes a plugin architecture for feeds (30+ public sources like MITRE ATT&CK, CISA KEV, MISP, AbuseIPDB) and analytics (Shodan, Censys, VirusTotal, etc.). The codebase is well-structured with clean abstractions (ArangoYetiConnector, event system, polymorphic schemas, migration framework) but contains deprecated plugins and some configuration drift. It is primarily an application, not a data research project.
This repository is a community-driven threat hunting and detection engineering knowledge base rather than a deployable application. It contains 26+ Windows-focused Jupyter notebooks (authored as Jupytext Markdown) that each follow a strict hypothesis-driven methodology: hypothesis, technical context, offensive tradecraft, pre-recorded security datasets, SQL/Pandas analytics, and Sigma rule output. The repo also includes deep Windows internals documentation, MITRE ATT&CK group profiles (CTI), pre-hunt data management guidance, and a small YARA signature set. The dominant character is data_research: the core artifacts are analytical notebooks, structured metadata, and threat intelligence data, with a hybrid component of Python build scripts that generate the Jupyter Book, table of contents, ATT&CK Navigator layers, and evaluation reports.
Sherlock is a monolithic Python CLI for username enumeration across social networks. For a given username it fans out concurrent HTTP probes to roughly 400 external sites (defined declaratively in sherlock_project/resources/data.json), then classifies each response as Claimed / Available / Unknown / Illegal / WAF using three detection modes: HTTP status code, presence/absence of a site-specific error message in the response body, or redirect behavior (redirects disabled, 2xx/3xx means claimed). Requests run in parallel via a requests-futures session capped at 20 workers; an optional per-site regex short-circuits illegal usernames without sending a request, and hardcoded fingerprint strings detect Cloudflare / PerimeterX / AWS WAF blocks. The CLI accepts one or more usernames, supports {?} wildcard expansion into `_`, `-`, `.` variants, and reports results to the terminal via a QueryNotify observer, with optional .txt, .csv, and .xlsx export. The system is fully data-driven: no per-site code exists. Each manifest entry declares the probe URL, error detection method, error signatures, optional headers/request method/JSON payload, and NSFW flag; a JSON Schema (data.schema.json) enforces conditional consistency (e.g., errorMsg required when errorType includes 'message'). By default the manifest is fetched live from https://data.sherlockproject.xyz, with an ephemeral false-positive exclusion list pulled from a dedicated GitHub branch; --local, --json, and --site flags override this behavior. Entry points are the `sherlock` console script, `python -m sherlock_project`, a Docker image entrypoint, and an Apify Actor (.actor/) that wraps the Docker image and pushes JSON results into an Apify dataset. Engineering strengths include the declarative manifest/schema design, a genuinely useful test suite (schema validation, live-target probe tests, randomized false-positive fuzzing, a Unicode regression test for issue #2730), and CI that runs a tox matrix across Python 3.10-3.14t on three OSes, validates only manifest entries modified by a PR, comments the validation summary back on the PR, and updates the exclusions list daily. Weaknesses: nearly all orchestration and output-format logic lives in a ~1,200-line sherlock.py; notify.py uses a module-global result counter; sites.py has mutable default arguments and a dead username_unclaimed parameter; the --print-found flag is always True (store_true combined with default=True); stem is an unused declared dependency; and the request layer relies on requests-futures, an effectively unmaintained library. The project is actively maintained and extremely popular (93k+ stars), and its health depends on hundreds of external sites remaining stable, hence the extensive removed-sites documentation and dedicated false-positive/false-negative issue templates. Technical drift is moderate rather than severe: the Python ^3.9 floor is now EOL, requests-futures is unmaintained, the WAF fingerprint catalog has not been extended since late 2024, and the PyPI readme still documents removed --tor flags.