Microsoft Entra ID Sign-in Logs

The subject pre-authorizes access to internal or third-party services using OAuth or other token-based mechanisms, creating persistent or stealth access pathways for future use. This staging behavior allows access to be decoupled from standard authentication workflows, enabling the subject to retrieve, manipulate, or exfiltrate data without using core credentials or triggering routine identity-based alerts.

Token staging is particularly relevant in cloud and hybrid environments where delegated access via OAuth, SAML, or API keys is commonly used. When authorization tokens grant broad scopes (e.g., full mailbox or document access), they can effectively serve as alternate credentials — often surviving role changes, session terminations, or identity deactivations.

From an investigative standpoint, this behavior constitutes an intentional act of access persistence setup. It may indicate foresight, circumvention of governance controls, or preparation for covert activity. Detection typically requires correlating authorization logs with subject role, timing, and expected access boundaries - especially where third-party application use diverges from organizational norms.

A subject retrieves email files from a remote email server. The subject might use their own or other obtained credentials to access an email mailbox and subsequently copy emails and/or data contained within emails. Remote email collection can be conducted against on-premises email servers, webmail, and cloud-based email services.

A subject may search for or otherwise explore files on a Collaboration Platform (such as SharePoint, OneDrive, Confluence, etc) to identify sensitive or valuable information.

The subject grants unauthorized access to organizational collaboration platforms, such as Slack, Microsoft Teams, Confluence, or equivalent tools, thereby exposing them to internal information, workflows, or discussions outside their clearance or role-based access. This behavior may occur by inviting a guest account, elevating access permissions for an existing contact, or bypassing formal onboarding channels to enable out-of-policy access.

Such unauthorized collaboration introduces a high-risk vector for information leakage, intellectual property exposure, and unmonitored data sharing. In many cases, these platforms contain embedded files, chat histories, integration logs, and operational metadata that extend beyond what the subject may intend to share. Even when performed under the guise of productivity or convenience, this behavior constitutes a clear infringement of acceptable use policies and undermines formal access governance structures.

The action is often difficult to detect retrospectively if audit logging for guest access is not enabled or if collaboration platforms lack integration with centralized identity providers. Investigators should consider whether the access was temporary or persistent, and whether the subject demonstrated awareness of the policy violation (e.g., through attempts to obscure or justify the behavior).

The subject develops a custom API that monitors specific activities, network traffic, and system changes within the target environment. The API could monitor HTTP/HTTPS requests directed at sensitive endpoints, track modifications to security group settings (such as firewalls or access policies), and identify administrative actions like changes to user accounts, data access requests, or logging configurations.

This tripwire API is embedded within various parts of the environment:

• Cloud Services: It hooks into serverless functions, containers, or virtual machines to monitor access and activity.
• Applications: It integrates into custom-built web applications to observe access to certain URLs, paths, or endpoints.
• Infrastructure Services: It monitors cloud management APIs (e.g., AWS, Azure, Google Cloud) for unusual activities indicative of an investigation.

Once deployed, the tripwire API continuously monitors network traffic, API calls, and system changes for indicators of an investigation. It looks for:

• Known Security Tools: Scanning for network traffic signatures from common security tools (like Nessus or nmap) or patterns associated with incident response teams.
• Unusual Access: Detecting attempts from IP ranges linked to internal security teams or cloud provider security operations centers.
• System Changes: Watching for actions typical of an investigation, such as new logging mechanisms, alterations to IAM roles, or the activation of cloud monitoring services.

The API can use whitelists for expected IP addresses or user accounts, triggering alerts if unexpected access occurs.

Upon detecting activity, the API tripwire can take immediate evasive actions:

• Alert the Subject: It sends covert alerts to an external server controlled by the subject, through an HTTP request, encrypted email, or messaging platform.
• Suspend Malicious Activity: If integrated into a malicious workflow, the API can halt ongoing data exfiltration or malware processes.
• Clean Up Evidence: It triggers scripts to delete logs, clear files, or reset system configurations to hinder forensic analysis.
• Feign Normalcy: It restores access controls and system settings to their default state, masking any signs of unusual activity.

The subject deliberately deletes emails - either sent, received, or both - with the intent to obstruct investigative visibility, remove evidence of policy violations, or eliminate traces of communication relevant to an insider event. While routine inbox maintenance is common, patterns of targeted deletion may indicate purposeful concealment.

The subject accesses a corporate hardware asset, most commonly a laptop or corporate mobile device, after their employment has formally ended. This typically occurs due to gaps in deprovisioning, delayed hardware recovery, or the subject physically retaining the device despite offboarding procedures. Post-termination access may be opportunistic or intentional, and may precede or coincide with data exfiltration, sabotage, or unauthorized continuation of internal access.

This sub-section is relevant in cases where the hardware asset is no longer linked to an active identity in HR systems but remains technically functional and capable of network, VPN, or service access. Such access undermines the assumption that termination alone revokes operational capability and may point to procedural drift in IT, HR, or facilities handover workflows.

A subject deliberately shares credentials for an individually assigned user account with another person, or uses credentials assigned to another individual without authorization. Individually assigned accounts are intended to be used only by the assigned account holder and are governed by organizational policy, access control requirements, and identity management processes. Sharing or using another person’s account violates these controls by moving access outside approved provisioning, delegation, and review mechanisms.

User account sharing typically emerges where convenience, workload pressure, informal delegation, or perceived access delays are prioritized over account-use policy. Teams may rationalize the behavior as necessary for shift coverage, urgent operational tasks, peer assistance, or temporary access needs. In other cases, a subject may share or receive account credentials to avoid onboarding delays, bypass access request processes, or complete work without obtaining the permissions formally required for their role.

When user account credentials are shared, the receiving individual gains access through an identity that was not assigned, approved, or reviewed for their use. This can bypass role-based access controls, segregation of duties, conditional access policies, approval workflows, and access review assumptions. The infringement is not dependent on malicious intent; the policy violation arises from the unauthorized transfer or use of identity-bound access.

User account sharing may expose sensitive systems, regulated data, approval functions, administrative consoles, or business workflows to individuals who have not been formally authorized for that level of access. In environments with compliance obligations, privileged workflows, or strict access governance requirements, user account sharing should be treated as a significant infringement and reviewed against the organization’s Acceptable Use Policy, identity governance standards, and disciplinary or remediation processes.

A subject accesses or uses an account that was previously issued to them by the organization but is no longer authorized for their use. This may occur after employment has ended, a contract has expired, a role has changed, a project has concluded, or access has otherwise ceased to be permitted.

This behavior may involve the subject using retained credentials, active sessions, multi-factor authentication enrollment, recovery options, device trust, federated access, cached authentication material, or connected service access after authorization has ended. The defining behavior is that the subject continues to access an account that they were once permitted to use but are no longer authorized to access.

A subject accesses or uses a service account, automation account, application identity, deployment account, or other non-personal account without being assigned, delegated, approved, or operationally authorized to use it. These accounts are typically created for system, application, administrative, automation, or integration functions rather than direct individual use.

This behavior may involve the subject independently obtaining or using credentials, keys, tokens, secrets, certificates, stored authentication material, or configuration artifacts associated with the service account. The defining behavior is that the subject uses a non-personal account outside the scope of any approved role, workflow, or administrative process.

A subject accesses or uses a privileged, administrative, or elevated account without being assigned, delegated, approved, or authorized to use that account. This may include domain administrator accounts, local administrator accounts, cloud administrator roles, database administrator accounts, security tool administrator accounts, root accounts, break-glass accounts, or other identities with elevated system or data access.

This behavior may involve the subject independently obtaining or using privileged credentials, administrative tokens, active sessions, SSH keys, emergency access material, privileged access management credentials, or other elevated authentication mechanisms. The defining behavior is that the subject performs activity through a privileged account that has not been authorized for their use.

A subject accesses or uses an account that is inactive, abandoned, ownerless, misassigned, or no longer clearly linked to an authorized individual or business function. This may include accounts belonging to former personnel, legacy applications, inactive contractors, deprecated systems, unmanaged test identities, or accounts that remain active despite no current operational owner.

This behavior may involve the subject independently identifying and using an account that still authenticates but is no longer actively managed, monitored, or assigned for legitimate operational use. The defining behavior is that the subject uses an account whose continued availability does not represent authorization for the subject to access it.

The subject activates elevated permissions that are assigned to them or conditionally available through an established organizational or operating-system mechanism. This may include sudo, an elevation prompt, just-in-time access, privileged identity management, cloud role assumption, or an equivalent governed process.

The activation may itself be approved or unapproved. It should be recorded where entering the elevated context is materially relevant to an investigation, including where an approved mechanism is used outside its authorized purpose or before a later infringement.