EmploLeaks: mapping a company's employees against a leak corpus

EmploLeaks scopes every collection step to one target company

Most credential search tools take an email address or a domain and tell you what they find. EmploLeaks works the other way around: you name a company, and it assembles the people first. The repository describes itself as an OSINT tool that helps detect members of a company with leaked credentials, and the pipeline reflects that order of operations. It gathers employee profiles from LinkedIn, generates plausible corporate email addresses from those profiles, then looks for those addresses in a leak database it keeps in ClickHouse. It also checks known breaches through the HaveIBeenPwned API, enumerates company subdomains, and looks up employees on social networks.

That makes it a tool for people who already work with corporate identity data, such as red team operators and bug bounty hunters validating whether an account takeover is plausible. The interesting output is the join between a real person, a derived work address, and a credential string from a breach. The project stores every collection locally in a SQLite database for later analysis, and it also ships an administrative web app with a FastAPI backend and a Next.js frontend for triaging results.

One caveat frames everything else: the leak search only works against whatever corpus you import. Out of the box there is no breach data, so the tool is an engine for querying data you supply rather than a source of that data.

A cmd2 shell with one plugin per collection source

The entry point is a single file, emploleaks.py, which runs an interactive command line session built on cmd2. Rather than a script of flags, you get a prompt where you switch between plugins and configure them as you go. The `use --plugin` command activates one of three sources, `deactivate` turns the current one off, and `show options` lists what the active plugin accepts. `setopt` writes a value, and if you omit the value the command prompts for it without echoing it, which is the intended path for session cookies and API keys.

The plugin set is small and visible in the tree. plugins/linkedin.py scrapes employee profiles using a LinkedIn session, plugins/github.py covers repositories, stalking and secret scanning, and plugins/hibp.py checks breach exposure through pyhibp. Each plugin reads its credentials from config/tokens.ini, a file excluded from version control. Two commands control that file directly: `autosave --enable` writes plugin configuration back to tokens.ini, and `autoload --enable` reads it at startup. With autosave on, a cookie you paste once survives a restart.

That design is a real convenience for a multi hour session, and it is also the main operational exposure. A single ini file holds every token for every source you have ever touched, and its security depends on the permissions of the machine running the session.

Two stores: ClickHouse for the corpus, SQLite for the results

The tool keeps two separate stores with two different jobs. ClickHouse holds the credential corpus. It is the search engine behind the leak queries, and the project expects it to hold large volumes of rows, so it ships a Docker Compose setup under clickhouse-docker with a docker-compose.yml and a config directory containing users.xml. The connection details live in the same tokens.ini file, under a clickhouse section with host, port, user, passwd and dbname keys.

SQLite holds what you gathered. It lands in data/emploleaks.db, and it is where the employee list, derived addresses, breach hits and enrichment results end up. The web app reads from that side, which is why a FastAPI backend and a Next.js frontend are bundled: they are triage surfaces over your local findings, not a hosted service.

Importing is where the corpus comes from. `import_leaks` reads credential files from the leaks_data folder, which is not committed to the repository, and `import_leaks --no-ai` restricts that to files whose format is already recognised. You can also point the command at another directory, or create a database manually with `create_db`. Connection handling is explicit: `connect_leaks` uses the saved settings, `connect_leaks --host --port --save` overrides and stores them, and `disconnect_leaks` closes the session. If the ClickHouse section is present in tokens.ini, the connection is established at startup without a command.

The leak parser asks an AI agent to design the schema

utils/leak_parser.py is the most unusual component. Instead of hardcoding regular expressions for every breach dump format, it runs a loop with a language model: the agent proposes a schema, validates it against a sample, gets a score and feedback with concrete error examples back, and retries until it converges. The same file is described as detecting UTF-16 and UTF-8 encodings, ASCII art banners, country code prefixes, stealer logs from families such as Redline, Lumma and Raccoon, and otherwise arbitrary email, username and URL layouts.

The approach buys you coverage of dump formats nobody has written a parser for yet, which matters because leak files change shape constantly. It also moves cost and failure into the model call. Parsing depends on an AI backend, and utils/ai_classifier.py shows the pattern the project uses elsewhere, with OpenAI and Ollama mentioned as options. A schema that scores well on one sample can still mis-map columns on a second file, and the loop, by design, ends when the agent decides it has converged rather than at a fixed threshold.

The escape hatch is explicit. `import_leaks --no-ai` skips the agent entirely and takes only files in known formats, which is the deterministic path when you need the same parse twice and get the same answer.

Telegram sync and social lookups widen the collection

Beyond the plugin shell, several utility modules widen what gets collected. telegram_sync.py is a standalone userbot daemon built on Telethon that joins approved Telegram channels and pulls credential files down automatically. utils/email_lookup.py uses Holehe to look up an email address across roughly 120 platforms, and utils/profile_lookup.py uses Maigret to look up a username across more than 500. utils/discovery.py enumerates subdomains with assetfinder and can add SecurityTrails when a key is present. Secret scanning of GitHub and GitLab repositories uses gitleaks as an optional external tool.

Employee records can also be sorted by department, which utils/ai_classifier.py handles with the same model provider approach as the parser. Reports can be generated as interactive HTML with profile photos, and results exported to CSV.

Read together, these modules describe a wide collection surface with a wide dependency surface. Holehe, Maigret, assetfinder, gitleaks, SecurityTrails, the HaveIBeenPwned API and a ClickHouse server are separate external assumptions, and the Telegram daemon is a long running background process with its own session credentials. Each addition buys a different kind of signal, and each one needs its own setup before the corresponding output is worth anything.

Installing EmploLeaks and registering your first company

The documented setup path is short. Python 3.10 or newer and pip are required, along with an internet connection. Clone the project and install its dependencies:

git clone https://github.com/yourusername/emploleaks.git
cd emploleaks

pip install -r requirements.txt

Note that the clone URL in the documentation carries a placeholder owner, so you need the real repository address. The requirements file asks for minimum versions only, for example cmd2>=2.4.3 and requests>=2.31.0, so pip will pull the newest release that satisfies each floor.

If you want the leak database locally, bring up the bundled ClickHouse service first:

cd clickhouse-docker
docker compose up -d
cd ..

Then start the session, with debug output available through a flag:

python emploleaks.py

python emploleaks.py -d

Inside the shell, `add_company --name` creates a target, `select_company --name` makes it active, `list_companies` shows what exists, and `delete_company --name` removes a company together with its data. Activate the LinkedIn plugin with `use --plugin linkedin`, set the session cookies through `setopt`, and enable `autosave --enable` so the configuration survives a restart. The HaveIBeenPwned plugin needs an API key, and the gitleaks step needs the binary on your path.

Where the documentation stops and where to look instead

Several constraints are worth stating plainly. The project has no GitHub releases, so there is no upgrade path beyond the default branch, and the last push was on 2026-05-19. Nothing in the tree states a licence, which matters if you intend to modify or redistribute the code. The README does not document a rollback procedure, a supported Python matrix beyond 3.10+, or a headless mode for the interactive session, so a scheduled run against a company would need your own wrapper.

The nearest alternatives follow different shapes. Running gitleaks directly against a repository gives you secret exposure in source control but no employee scope and no breach history. Querying the HaveIBeenPwned API directly answers whether one address appears in a known breach without a local corpus or a ClickHouse deployment. Maigret and Holehe on their own cover account discovery by username and by email without tying results to a company record. EmploLeaks is worth the extra setup when you need all of those sources joined to a single company, kept in a local SQLite database, and exportable as HTML or CSV for a report.

Editorial conclusion

Adopt EmploLeaks if you already maintain a leak corpus and need results scoped to one company with a local SQLite copy for later triage. Skip it if you only want a single breach check per address, since HaveIBeenPwned and gitleaks answer that without a ClickHouse instance. Before anything else, confirm the licence, since the project states none, and check the pinned minimum versions in requirements.txt, because no release tags exist beyond the last push on 2026-05-19.

Frequently asked questions

Official sources

1. infobyte/emploleaks on GitHub
2. Issues
3. Project website
4. README