> For the complete documentation index, see [llms.txt](https://docs.stoik.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.stoik.io/prevention-tools/credentials.md). # Credentials The `Credentials` section gives you a dedicated view of everything Stoïk has found related to leaked credentials and compromised devices for your organisation. ## How it works Stoïk Protect is connected to three external intelligence providers: * **LeakCheck** monitors public data breaches: incidents where a company's user database was hacked and dumped online. * **Hudson Rock** and **Flare** collect infostealer logs: data silently exfiltrated from employee devices infected by malware. From the assets you've declared in the [External Scan](/prevention-tools/external-scan/configuration.md) (domain names, IP addresses), Stoïk continuously queries these providers for anything related to your organisation. Results flow into two tabs: **Exposed Data** and **Alerts**. ## Exposed Data Exposed Data is the full intelligence feed: every piece of data Stoïk has found leaked about your organisation online. It is organised into three sub-tabs: * **Raw logs:** every leak record, all data types (credentials, cookies, emails, phone numbers, IP addresses, …). * **Credentials:** credential-type leaks only: URL + login + password. * **Cookies:** session cookies exfiltrated from infected devices. For each entry, the side panel shows the intelligence provider that found it, the estimated leak date, the data type, and any linked alert. Review new entries and acknowledge them once investigated. Acknowledged entries remain visible but no longer count as new. {% hint style="info" %} An entry in Exposed Data does not necessarily mean the credential still works today. If we have confirmed it does, it appears as a Valid Credentials alert in the Alerts tab. {% endhint %} ## Alerts Alerts are what Stoïk has actively confirmed needs immediate action. There are two types. ### Valid Credentials A Valid Credentials alert means Stoïk found a leaked URL + login + password in Exposed Data and **confirmed it still grants access** to one of your services today (Microsoft 365, Fortinet VPN, Citrix, exposed web panels, and others). This is not a historical leak. It is a working credential that an attacker could use right now. To resolve it: 1. Reset the password for the affected account immediately. 2. Enable multi-factor authentication (MFA) on that account if not already active. 3. Check whether the same password is reused on other services. Change those too. 4. Mark the alert as resolved once done. Stoïk will verify the remediation. ### Infected Device An Infected Device alert means one of your employee devices has been identified as compromised by infostealer malware, by Hudson Rock or Flare. The device is actively exfiltrating data (passwords, cookies, browser autofill, saved credentials) until it is fully wiped. To resolve it: 1. Isolate the device from the network immediately (disconnect from Wi-Fi and LAN). 2. Wipe and reinstall the device from scratch. A virus scan alone is not sufficient. 3. Force a password reset for all accounts used on that device. 4. Invalidate active sessions on those accounts (sign out everywhere) to neutralise any stolen session cookies. 5. Enable MFA on the affected accounts. ### Personal devices Stoïk detects infected devices based on professional account activity. It cannot determine whether the device itself is a company-issued machine or a personal one. A personal device (a phone or laptop on which an employee connected a professional account) can therefore appear as an Infected Device alert. If you identify an alert as relating to a personal device, update the device type from the alert side panel: 1. Open the alert. 2. Switch the **Device type** from *Professional* to *Personal*. The alert moves to **Dismissed** status. It remains visible in the list but is filtered out by default and no longer counts as an active alert. {% hint style="info" %} Even on a personal device, the professional accounts used on it remain at risk. Before dismissing the alert, make sure the employee has reset their passwords and invalidated active sessions for any professional account they accessed on that device. {% endhint %} {% hint style="warning" %} If you believe an alert is a false positive, you can request a discard directly from the side panel. Stoïk will review the request before closing it. {% endhint %} ## How Alerts and Exposed Data are linked Valid Credentials alerts are built from Exposed Data: Stoïk picks leaked credentials from the feed and tests them against your services. Those that still work are promoted to Alerts. Infected Device alerts work in the other direction: each compromised device typically produces a payload of stolen data (passwords, cookies, browser data) that flows into Exposed Data. Opening an Infected Device alert shows you the associated Exposed Data entries. ## Data refresh frequency Stoïk queries each provider on a regular schedule: * Flare: every 24 hours * Hudson Rock: every 72 hours * LeakCheck: every 7 days Exposed Data and Infected Device alerts follow the same schedule as their respective provider. **Valid Credentials alerts** are tested as soon as new exposed credentials are detected. Stoïk then retests them every 3 days until the credential no longer works, so the alert automatically resolves once the password has been changed. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.stoik.io/prevention-tools/credentials.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.