Identity & access

Stolen sessions

We identify your platforms’ session cookies captured on infected devices and still valid: an access that needs neither a password nor a second factor.

Territory: Identities and access Organisation perimeter

The problem

A session cookie stolen from an infected device opens an account with neither password nor second factor: the session is already authenticated. For a consumer platform, it is the most discreet account takeover there is, and your logs show it as a normal login. The cookie, meanwhile, sits in a stealer log acquired as soon as it circulates, before the session is replayed.

Client area preview

What you see

Fictional data, for illustration only: no client, no real data.

What you get: this screen in your client area, refreshed at every synchronisation, with CSV and JSON export.

  1. 01

    Exposed sessions by platform, with capture date and apparent validity

  2. 02

    The source device and the other accesses captured with the session

  3. 03

    The status: to revoke, revoked, expired, and the export for your fraud team

How it works

Our answer in three steps

VesperID detects your platforms’ session cookies captured by information stealers, checks their apparent validity and gives you what you need to revoke them before they are replayed.

  1. 01

    You declare your platforms’ domains, the names of your session cookies and, for your own employees’ sessions, your Microsoft 365 tenant.

  2. 02

    The stealer logs our partners acquire as soon as they circulate are matched against your platforms’ cookies; the platform checks validity without ever replaying a session.

  3. 03

    You revoke server-side; the finding closes when the cookie expires or is revoked.

Where this data comes from

Cookies come from stealer logs acquired as soon as they circulate; VesperID checks that they belong to your platforms and that they are still valid, without ever replaying a session or keeping the cookie value.

Our sources in detail

Cross analyses

What the platform computes on top

This service’s data is crossed with the others’: here are the analyses that come out of it, all visible in the client area.

Discover the platform
  1. 01

    Validity and targeted hosts

    For every stolen session, whether it is still valid and which hosts of your organisation it opens.

  2. 02

    Immediate takeover

    A valid corporate cookie puts the identity in the “immediate” class and opens a chain whose impact is session replay or SSO access.

  3. 03

    Session revocation

    The playbook lists the sessions to revoke and the accounts to reset; the “sessions revoked” action lowers the employee’s risk.

What you receive

Stolen sessions

  1. 01

    Alert per session still valid

  2. 02

    Table of exposed sessions, exportable to your anti-fraud tools

  3. 03

    Revocation procedure and recommendations on session lifetime

  4. 04

    Monthly follow-up of exposed and revoked sessions

Frequently asked questions

  • Do you replay the cookie to check it?

    Never. Validity is estimated from the capture date and your session lifetimes; the safe answer remains revocation.

  • Do you keep the cookie value?

    No. We keep the name, the domain, the date and the source device. The value of a cookie of your own platforms can only be viewed on demand, after re-authentication, with a reason, and that viewing is logged; the value of a third-party service’s cookie is never revealed.

  • Is this only for consumer platforms?

    The service targets platforms whose customers log in from devices you do not control, and your own employees’ Microsoft 365 sessions, through your declared tenant; it is activated case by case at scoping.

Request an exposure assessment.

One hour with an analyst, not a demo: what already circulates about your organisation, what to monitor, what is better left alone. Reply within one working day.

No public price list: bespoke offering, written proposal after scoping.