vulkro-sf org session
Live AuthSession audit: long-lived and stale sessions
(SF-SESSION-LIVE-001 / -002 / -003).
A session that stays valid for days is the canonical takeover persistence vector: a stolen session id keeps working long after the password is rotated. This command reads the sessions that exist in the org right now and splits them by how long they are valid and how old they are.
Synopsis
vulkro-sf org session --target-org <alias> [flags]
Flags
| Flag | Type | Default | Description |
|---|---|---|---|
--target-org, -o <alias> | string | (required) | Target org alias or username, as known to sf org login. |
--format <fmt> | table | json | table | Output format. |
--verbose, -v | flag | off | Bump stderr log verbosity. -v enables debug-level tracing for the vulkro + vulkro_sf targets; -vv enables trace. Honoured only when RUST_LOG is unset (an explicit RUST_LOG always wins). |
What gets read
AuthSession rows whose NumSecondsValid exceeds one day or whose
CreatedDate is more than 30 days behind now, plus the set of user ids
that hold Modify All Data. The second query lets the audit split the
long-lived band into admin and non-admin sessions without re-querying.
What gets reported
| Rule | Severity | What fires |
|---|---|---|
SF-SESSION-LIVE-001 | High | An admin user with NumSecondsValid above 86400 (one day). Stable, multi-day admin sessions are the canonical takeover persistence vector. Signal org-authsession-long-lived-admin. |
SF-SESSION-LIVE-002 | Medium | Any user with NumSecondsValid above 86400. Widens the account-takeover window for a stolen session id. Signal org-authsession-long-lived-any-user. |
SF-SESSION-LIVE-003 | Low | An active session whose CreatedDate is more than 30 days behind now. Stale workstation sessions never trigger a forced re-auth. Signal org-authsession-stale-active. |
Examples
vulkro-sf org session --target-org my-prod
vulkro-sf org session -o my-prod --format json > session.json
Exit codes
0- no findings.1- findings reported.2- error.
Scope and honesty
The org is read locally through your own authenticated sf CLI login;
nothing is sent anywhere. The audit reads session metadata (validity
window, creation time, owning user) and the admin user-id set. It does
not read session tokens, and it does not terminate any session.
Findings are posture signals about session configuration and age, not evidence that a session was hijacked. A long-lived admin session is frequently a legitimate admin who stayed logged in. A run with no findings does not certify that no session in the org is compromised.
Where to go next
- vulkro-sf org login-history - the logins that created these sessions, plus per-profile session-timeout policy.
- vulkro-sf org mfa - whether those logins were MFA-protected.