Detections
- Home
- - Detections
- -DT137
- 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.002 | Unauthorized 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:
Unauthorized credential use is a high-risk concealment technique and often coincides with malicious or high-impact infringements. |
IF025.001 | Service 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.001 | Credentials 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. |