Privileged Access Management (PAM)

A subject leaving the organisation with access to sensitive data with the intent to access and exfiltrate sensitive data or otherwise contravene internal policies.

A subject is able to create, modify, or delete cloud resources within an organization.

The subject deliberately adopts or fabricates an identity—visually, digitally, or procedurally—to gain access, mislead stakeholders, or enable a planned insider event. Impersonation may occur in physical environments (e.g., unauthorized use of uniforms or cloned ID cards), digital platforms (e.g., email aliases or collaboration tools), or human interactions (e.g., job interviews). These behaviors typically precede unauthorized access, credential misuse, sabotage, or data exfiltration, and may allow subjects to operate without attribution or delay detection.

Impersonation is a high-risk preparatory behavior that often precedes direct misuse of trust. By assuming a false identity or misrepresenting role, authority, or affiliation, the subject gains unauthorized access or influence—without triggering traditional insider threat controls.

The subject violates organizational policy by allowing or enabling the use of their credentials by another individual or by using credentials that do not align with their identity and/or they are not authorized to use. 

Account sharing undermines accountability, auditability, and access control mechanisms, and is frequently linked to the obfuscation of intent, collusion, or circumvention of oversight. It is often rationalized as a convenience, but may also support broad policy evasion, unauthorized task delegation, or illicit collaboration.

The subject deliberately misuses account constructs to obscure identity, frustrate attribution, or undermine investigative visibility. This includes the use of shared, secondary, abandoned, or illicitly obtained accounts in ways that violate access integrity and complicate forensic analysis.

Unlike traditional infringement behaviors, account misuse in the anti-forensics context is not about the action itself—but about how identity is obfuscated or displaced to conceal that action. These behaviors sever the link between subject and activity, impeding both real-time detection and retrospective investigation.

• Common anti-forensic account misuse techniques include:
• Operating across multiple sanctioned accounts to fragment behavior trails.
• Using shared service accounts to mask individual actions.
• Re-activating or leveraging dormant credentials to perform access without attribution.
• Exploiting misconfigured or ghost accounts left from previous users, contractors, or integrations.

Investigators encountering unexplainable log artifacts, attribution conflicts, or unexpected session collisions should assess whether account misuse is being used as a deliberate concealment tactic. Particular attention should be paid in environments lacking centralized identity governance or with known privilege sprawl.

Account misuse as an anti-forensics strategy often coexists with more overt infringements—enabling data exfiltration, sabotage, or policy evasion while preserving plausible deniability. As such, its detection is crucial to understanding subject intent, tracing activity with confidence, and restoring the chain of custody in incident response.

Subjects with access to production and pre-production environments—whether as users, developers, or administrators—hold the potential to exploit or compromise highly sensitive organizational assets. Production environments, which host live applications and databases, are critical to business operations and often contain real-time data, including proprietary business information and personally identifiable information (PII). A subject with access to these systems can manipulate operational processes, exfiltrate sensitive data, introduce malicious code, or degrade system performance.

Pre-production environments, used for testing, staging, and development, often replicate production systems, though they may contain anonymized or less protected data. Despite this, pre-production environments can still house sensitive configurations, APIs, and testing data that can be exploited. A subject with access to these environments may uncover system vulnerabilities, access sensitive credentials, or introduce code that could be escalated into the production environment.

In both environments, privileged access provides a direct pathway to the underlying infrastructure, system configurations, logs, and application code. For example, administrative access allows manipulation of security policies, user permissions, and system-level access controls. Similarly, access to development environments can provide insights into source code, configuration management, and test data—all of which could be leveraged to further insider activity.

Subjects with privileged access to critical environments are positioned not only to exploit system vulnerabilities or bypass security controls but also to become targets for recruitment by external actors seeking unauthorized access to sensitive information. These individuals may be approached or coerced to intentionally compromise the environment, escalate privileges, or exfiltrate data on behalf of malicious third parties.

Given the sensitivity of these environments, subjects with privileged access represent a significant insider threat to the integrity of the organization's systems and data. Their position allows them to manipulate or exfiltrate sensitive information, either independently or in collaboration with external actors. The risk is further amplified as these individuals may be vulnerable to recruitment or coercion, making them potential participants in malicious activities that compromise organizational security. As insiders, their knowledge and access make them a critical point of concern for both data protection and operational security.

A subject with access to privileged groups (e.g., Domain Admins, Enterprise Admins, or Security Groups) or non-user accounts (such as service accounts, application identities, or shared mailboxes) gains elevated control over systems, applications, and sensitive organizational data. Access to these groups or accounts often provides the subject with knowledge of security configurations, user roles, and potentially unmonitored or sensitive activities that occur within the system.

Shared mailboxes, in particular, are valuable targets. These mailboxes are often used for group communication across departments or functions, containing sensitive or confidential information, such as internal discussions on financials, strategic plans, or employee data. A subject with access to shared mailboxes can gather intelligence from ongoing conversations, identify targets for further exploitation, or exfiltrate sensitive data without raising immediate suspicion. These mailboxes may also bypass some security filters, as their contents are typically considered routine and may not be closely monitored.

Access to privileged accounts and shared mailboxes also allows subjects to escalate privileges, alter system configurations, access secure data repositories, or manipulate security settings, making it easier to both conduct malicious activities and cover their tracks. Moreover, service and application accounts often have broader access rights across systems or environments than typical user accounts and are frequently excluded from standard monitoring protocols, offering potential pathways for undetected exfiltration or malicious action.

This elevated access gives subjects insight into critical system operations and internal communications, such as unencrypted data flows or internal vulnerabilities. This knowledge not only heightens their potential for malicious conduct but can also make them a target for external threat actors seeking to exploit this elevated access.

Kerberoasting is a technique that can be exploited by a subject to escalate privileges and gain unauthorized access to sensitive systems within a network. From the perspective of a subject—who may be a low-privileged user with legitimate access to the network—the attack takes advantage of weaknesses in the Kerberos authentication protocol used by Active Directory (AD).

Kerberos Authentication Process

In a Kerberos-based network (like those using Active Directory), clients—users, computers, or services—authenticate to services using service tickets. When a client wants to access a service (e.g., a file server or email service), it requests a service ticket from the Ticket Granting Service (TGS). This request is made using the Service Principal Name (SPN) of the target service.

The TGS then issues a service ticket containing the hashed credentials (password) of the service account associated with that SPN. These credentials are encrypted in the service ticket, and the client can present the ticket to the service to authenticate.

Subject Requesting Service Tickets

A subject, typically a domain user with limited privileges, can exploit this process by requesting service tickets for service accounts running critical or high-privilege services, such as domain controllers or admin-level service accounts. These accounts are often associated with SPNs in Active Directory.

The subject can identify these SPNs—often for high-value targets like SQL Server, Exchange, or other administrative services—by querying the domain or using enumeration tools. Once these SPNs are identified, the subject can request service tickets for these service accounts from the TGS.

Cracking the Service Tickets

The key aspect of the Kerberoasting attack is that the service tickets contain hashed credentials of the service account. If these service accounts use weak, easily guessable passwords, the subject can extract the service tickets and attempt to crack the hashes offline using tools like Hashcat or John the Ripper.

Since these passwords are typically not subject to regular user password policies (i.e., they may not be as complex), weak or easily cracked passwords are a prime target for the subject.

Privilege Escalation and Unauthorized Access

Once the subject successfully cracks the password of a service account, they can use the credentials to gain elevated privileges. For example:

• If the cracked service account belongs to a high-privilege service (e.g., Domain Admins or Enterprise Admins), the subject can use these credentials to access systems, services, and parts of the network they would not ordinarily be permitted to access. This could include sensitive files, servers, or even Active Directory itself.
• The subject can use these credentials to move laterally within the network, expanding their access to additional systems that are typically restricted to high-privilege accounts.
• With administrative-level access, the subject can make changes to critical systems, alter configurations, or install malicious software. This could lead to further insider events, such as data exfiltration, malware deployment, or even persistent backdoors for ongoing unauthorized access.

Reconnaissance and Exploitation

The subject can perform additional reconnaissance within the network to identify other high-privilege accounts and services associated with service accounts. They can continue requesting service tickets for additional SPNs and cracking any other weak passwords they find, gradually escalating their access to more critical systems.

With broad access, the subject may also attempt to manipulate access controls, elevate privileges further, or carry out malicious actions undetected. This provides a potential stepping stone to more serious insider threats and an expanded attack surface for other actors.

A subject provisions cloud-based resources without prior authorization or a documented business justification. This unauthorized activity may circumvent established governance, security, or cost-management controls, potentially exposing the organization to operational, financial, or regulatory risk.

The subject deletes IT resources resulting in harm to the organization. Examples include virtual machines, virtual disk images, user accounts, and DNS records.

The subject creates, modifies, or misuses digital identities within internal communication or collaboration environments—such as email, chat platforms (e.g., Slack, Microsoft Teams), or shared document spaces—to impersonate trusted individuals or roles. This tactic is used to gain access, issue instructions, extract sensitive data, or manipulate workflows under the guise of legitimacy.

Impersonation in this context can be achieved through:

• Lookalike email addresses (e.g., spoofed domains or typo squatting).
• Cloned display names in collaboration tools.
• Shared calendar invites or chats initiated under false authority.
• Use of compromised or unused accounts from real employees, contractors, or vendors.

The impersonation may be part of early-stage insider coordination, privilege escalation attempts, or subtle reconnaissance designed to map workflows, bypass controls, or test detection thresholds.

Example Scenarios:

• A subject registers a secondary internal email alias (john.smyth@corp-secure.com) closely resembling a senior executive and uses it to request financial data from junior employees.
• A subject joins a sensitive Slack channel using a display name that mimics another department member and quietly monitors ongoing discussions related to mergers and acquisitions activity.
• A compromised service account is used by an insider to initiate SharePoint document shares with external parties, appearing as a legitimate internal action.
• The subject impersonates an IT support contact via Teams or email to socially engineer MFA tokens or password resets.

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.

The subject leverages multiple accounts under their control—each legitimate on its own—to distribute, disguise, or segment activity in a manner that defeats identity-based attribution. This technique, referred to as account obfuscation, is designed to frustrate forensic correlation between subject behavior and account usage.

Unlike role-sanctioned multi-account use (e.g., one account for user access, another for administrative tasks), account obfuscation involves the deliberate operational separation of actions across identities to conceal intent, evade controls, or introduce ambiguity. This may involve:

• Using a privileged account to perform high-risk or policy-violating actions while maintaining a clean audit trail on the primary user account.
• Staging data using an internal identity and exfiltrating it using an external or contractor credential.
• Alternating between corporate and guest accounts to avoid continuous session logging or alerting thresholds.

This behavior is often facilitated by weak identity governance, fragmented access models, or unmanaged role transitions. It is especially difficult to detect in environments where access provisioning is ad hoc, audit scopes are limited, or account correlation is not enforced at the SIEM or UAM level.

From an investigative standpoint, account obfuscation serves as a deliberate anti-forensics tactic—enabling subjects to operate with plausible deniability and complicating timeline reconstruction. Investigators should review cross-account behavior patterns, concurrent session overlaps, and role-permission inconsistencies when this technique is suspected.

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.