Skip to main content
These playbooks start from public evidence. They do not require you to log in to the discovered app, submit forms, or use a surfaced credential.
Only access or test systems you own or are authorised to assess. A credential surfaced by Periphery may be used only to notify its owner unless you already have explicit authorisation to use it.

​
An unexpected app matching your organisation

  1. Capture the evidence. Record the hostname, provider, last seen value, and why the app matched your domain.
  2. Check the match reason. A company email or domain mention can appear on a third-party or unrelated page. See Understanding results.
  3. Do not treat the match as attribution. The console and API surface candidate matches only. Periphery performs ownership investigation and attribution through the managed service on the Pro plan.
  4. Inspect the public snapshot. Look for environment names, contact addresses, exposed data, and credential findings. Remember that the artifacts can be older than last seen.
  5. Remediate at the source once ownership is established. If the deployment is yours, remove or restrict anything that should not be public and retire forgotten deployments through the provider.
  6. Remove the Periphery record if needed. After fixing the source, the operator can follow the removal request process.
Do not treat the domain match itself as proof that the deployment is yours. Attribution is part of Periphery’s Pro managed service.

​
An exposed credential

  1. Do not test it again. A verified finding already means Periphery confirmed it at snapshot time; validity may have changed since.
  2. Revoke or rotate first. Do this before deleting the page or deployment. Removing public content does not invalidate a credential that has already leaked.
  3. Update dependants. Replace the credential anywhere legitimate systems still use it.
  4. Remove the leak. Fix the source code, generated bundle, environment configuration, documentation, or build output that exposed the value.
  5. Review issuer-side activity. If you own the credential, use the issuer’s normal audit logs and incident-response process to look for activity you do not recognise.
  6. Treat unverified findings proportionally. If the string maps to a real secret you own, rotate it. If it is clearly a placeholder or test value, document that conclusion rather than assuming every pattern match is live.
See Emails and credentials for verification semantics.

​
A possible clone or phishing deployment

  1. Start from the suspicious app and click its favicon, or search its faviconHash: value.
  2. Remove unrelated query terms if you want the broadest set of apps using that icon.
  3. Compare the candidates using independent signals: hostname, page title and text, branding, contact details, and the provider.
  4. Separate legitimate reuse from suspicious reuse. Framework defaults, product logos, templates, and partner deployments commonly share icons.
  5. If you confirm abuse through your own investigation, use your organisation’s normal brand, abuse, or provider-reporting process.
A favicon match is a lead, not proof of common ownership or malicious intent.

​
A finding you do not own

If the app or credential belongs to someone else:
  • Do not log in, submit data, or use a surfaced credential to test access.
  • Limit your report to what was already publicly visible and the Periphery URL or hostname needed to reproduce the observation.
  • Contact an appropriate security or abuse address when there is a legitimate reason to notify the owner.
  • Do not publish raw credentials as proof.
  • The acceptable use policy applies to every finding.
If the record is about an app you operate and you want it removed from Periphery, use the removal request process.