ITM is an open framework - Submit your contributions now.

Insider Threat Matrix™

  • ID: DT137
  • Created: 31st July 2025
  • Updated: 31st July 2025
  • Contributor: Richard Biolette

Discrepancies Between Physical Access Logs and System Authentication

In tightly controlled environments where system access is expected to be physically co-located (e.g., secure enclaves, badge-restricted zones, no-VPN networks), login events occurring without corresponding physical entry records indicate potential misuse of credentials or anti-forensic access. Subjects may provide or leak credentials to others, or operate under shared or impersonated accounts. This discrepancy can also signal badge cloning, tailgating, or failure to enforce physical-to-logical access binding.

 

Detection Methods

 

Compare physical access logs (e.g., Lenel, Genetec, CCure badge systems) with:

  • Active Directory login events
  • VPN or RDP session logs
  • Privileged session management tools

 

Construct correlation logic:

  • Alert when login event occurs but no badge entry for that subject within ±30 minutes.
  • Extend correlation window for multiple facility entry points if needed.

 

Filter for:

  • Logins to high-sensitivity systems
  • After-hours activity
  • Accounts with elevated privileges

 

Alert on:

  • Logins during badge absence
  • Logins post facility closure
  • Badge present, but login occurs from unassigned workstation

 

Example Scenario

In a secure IT operations center, access to administrative consoles is restricted to physically present engineers. On a holiday, an engineer’s domain account logs into the configuration server — but badge access records show they never entered the facility that day. Investigation reveals the password was shared with a colleague under informal backup practices, violating policy and creating audit ambiguity.

Sections

ID Name Description
AF024.002Unauthorized Credential Use

The subject employs valid credentials that were obtained outside of sanctioned provisioning channels to conceal their identity or perform actions under a false or misleading identity. This behavior, categorized as unauthorized credential use, is distinct from traditional account compromise—it reflects insider-enabled misuse, not external intrusion.

 

Credentials may be acquired through casual observation (e.g., shoulder surfing or unlocked workstations), social engineering, prior access (e.g., retained credentials from a former role), or covert means such as password capture tools. In some cases, credentials may be voluntarily shared by a collaborator or acquired opportunistically from unmonitored or abandoned accounts.

 

This tactic allows the subject to dissociate their actions from their known identity, delay detection, and in some cases, redirect suspicion to another individual. When used within privileged or high-sensitivity environments, unauthorized credential use can enable significant harm while bypassing conventional identity-based controls and alerting mechanisms.

 

Unlike service account sharing or account obfuscation (which involve legitimate, active credentials assigned to the subject), this behavior revolves around unauthorized access to credentials not formally linked to the subject. Investigators should prioritize this sub-section when audit trails show activity under an identity that does not correspond to role expectations, known behavioral patterns, or device history.

 

Key forensic indicators include:

  • Activity under stale or supposedly deactivated credentials.
  • Access from unfamiliar endpoints using accounts with known role assignments.
  • Unusual timing or geographic patterns inconsistent with the account’s assigned user.
  • Discrepancies between identity artifacts (e.g., login metadata) and session content (e.g., typing cadence, application use).

 

Unauthorized credential use is a high-risk concealment technique and often coincides with malicious or high-impact infringements.

IF025.001Service Account Sharing

A subject deliberately shares credentials for non-personal, persistent service accounts (e.g., admin, automation, deployment) with other individuals, either within or outside their team. These accounts often lack individual attribution, and when shared, they create a pool of untracked, unaccountable access.

 

Service account sharing typically emerges in high-pressure operational environments where speed or convenience is prioritized over access hygiene. Teams may rationalize the behavior as necessary to meet deployment deadlines, maintain uptime, or circumvent perceived access bottlenecks. In other cases, access may be extended informally to external collaborators, such as contractors or partner engineers, without proper onboarding or oversight.

 

When service account credentials are distributed, they become functionally equivalent to a shared key—undermining all identity-based controls. Investigators lose the ability to reliably associate actions with individuals, making forensic attribution difficult or impossible. This gap often delays incident response and enables repeated policy violations without detection.

 

Service accounts also frequently carry elevated privileges, operate without MFA, and are excluded from normal UAM logging, compounding the risk. Their use in this manner represents not just a technical misstep, but a structural breakdown in control integrity and accountability. In environments with compliance obligations or segmented access controls, service account sharing is a critical investigative red flag and should trigger formal review.

ME027.001Credentials in Ticketing Systems

Passwords, API keys, and privileged credentials are communicated, stored, or embedded in service desk tickets, including incident responses, change management notes, and administrative work orders. These credentials are often entered by IT or support personnel as part of access restoration, environment configuration, or user provisioning workflows.

 

Because many service desk platforms (such as ServiceNow, Jira Service Management, Freshservice & Zendesk) are broadly accessible across IT, engineering, and sometimes third-party vendor teams, the storage of credentials in ticketing systems significantly expands the number of individuals who can retrieve operationally sensitive access. In many cases, ticket logs are not considered part of the formal audit surface for access control, and standard retention, encryption, or obfuscation policies are inconsistently applied.

 

When credentials are available through searchable tickets, any subject with sufficient access to the service desk platform may bypass formal access provisioning and review processes. This creates an unmonitored path to privilege, especially when ticket histories are long-lived and tied to high-value systems. Investigators should treat such platforms as latent access repositories, especially during retrospective analysis of system access or in cases where no formal credential use appears in logs.