Assumed Compromise (Internal Pivot) Test
The objective of the Assumed Compromise (Internal Pivot) Test is to assess the customer environment for conditions that might allow an attacker to move laterally, escalate privileges, access sensitive information, or systemically compromise the target environment. This test can be considered a post-compromise engagement in the context of either a malicious employee who infiltrates an organization or a system that has been successfully infected with malware. Customer Return on Investment (ROI) should be considered when deciding when to switch between execution models.
As a side effect of tester activity, alerts generated by various attacks are collected and included in the ensuing report. Visibility of the target organization may be used to influence the overall rating for the engagement. However, this evidence should be analyzed for the potential for actionable response. As an example, an alert generated by Microsoft ATA warning of identity theft may be more immediately actionable than results of a SIEM query executed manually to discover activity.
To seed access to the environment, the target organization typically provides Remote Desktop Protocol (RDP) access to a host and Active Directory domain credentials with a provisioned email account to simulate compromise. The simulated compromise user should emulate the configuration of a real user on the network. It may be useful to have the points of contact consider the users most likely to be targeted for or successfully phished and model the test account after that user. In some situations, the points of contact may request that simulated payloads be sent to the organization to attempt detonation, rather than providing domain credentials and remote access. In these cases, the tester should negotiate a time beyond which payload delivery and detonation will be discontinued and remote access will be granted.
During testing, it is common to engage in password spraying, protocol abuse, sensitive data hunting, and Active Directory analysis to achieve any goals negotiated with the customer. In that sense, the customer may have the broad goal of Active Directory domain takeover or may provide specific information (intellectual property, customer information, PII, PHI, employee information, etc.) or systems (ICS devices, CDE systems, network infrastructure, etc.) they wish to use to demonstrate impact. This engagement typically includes the following elements, although this is not an exhaustive list:
title: Compromised Host Reconnaissance
Analysis of the provided test host allows estimation of the security posture of the environment. Typical tasks associated with this process include identification of security products, checks for unattended installation files, enumeration of local users and group membership, security tool bypass opportunities, and review of the file system for sensitive data or useful functionality. If custom applications are installed on the system, download and analysis of those applications should be performed as custom binaries sometimes contain valid credentials.title: Local Privilege Escalation
During testing, it is customary (at the very least) to check the initial compromised host for privilege escalation opportunities. With elevated privileges, the ability to execute attacks, bypass security products, suppress alerts, or install tools may be possible. In addition, privilege escalation on other systems may result in the ability to inspect configuration files or harvest credentials from memory, leading to domain privilege escalation and lateral movement.title: Command and Control (C2) Channel Established
Establishing a functional command and control channel can provide expanded opportunities to execute attacks and bypass security products in the target environment. Tools can be executed in-memory (Cobalt Strike Execute-Assembly, inlineExecute-Assembly, and Beacon Object Files) on the compromised host or proxied through the host (Cobalt Strike Proxy Pivot and Reverse Proxy, PortBender, and ProxyChains) to attack target network infrastructure.title: Active Directory SYSVOL Analysis
The SYSVOL share is readable by any domain user and its contents are replicated to every domain controller in the environment. Typically, this share is used to house logon scripts (typically batch and visual basic scripts) and group policy definitions. Analysis of logon scripts might reveal clear text credentials, mapped network drives, or caches of session details captured for use by administrators. In addition, group policy analysis can be used to identify mapped network drives (drives.xml), restricted group policy identification (groups.xml), local account renaming policies (groups.xml), group policy preferences (although long defunct) and other useful details for privilege escalation and lateral movement.title: Active Directory Configuration Analysis
Active Directory potentially represents a massive attack surface to an organization. As a result, it is critical for an attacker to gain situational awareness within the Active Directory environment (both on premises and cloud-based). Using tools like BloodHound (C#, PowerShell, and Python variants included), Vibe, ADRecon, and the ldapsearch Beacon Object File (BOF) an attacker can build an offline representation of Active Directory and session state. BloodHound analysis allows the attacker to identify privilege escalation and lateral movement opportunities that might otherwise go unnoticed.title: Protocol Abuse and Forced Authentication Attacks
The internal network of an organization typically exposes a much larger attack surface to a tester. The mere presence of certain protocols can present a significant opportunity for attack. As an example, protocols like Dynamic Host Configuration Protocol (DCHP), IPv6, Link-Local Multicast Name Resolution (LLMNR), and NetBIOS Name Service (NBNS) may allow an attacker to harvest or relay credentials (where SMB signing is disabled).
In addition, the authenticated nature of the Assumed Compromise (Pivot) Test exposes additional opportunities like Kerberos ticket harvesting, AS-REP ticket harvesting, and watering hole credential harvesting (malicious URL or LNK file dropped on writable SMB share).
Attacks like NoPac, PetitPotam, SharpSCCM, and Active Directory Certificate Services (ADCS) Abuse can present an easy path to Domain Admin within an environment.title: Authenticated Resource Enumeration
Often, the provided user context provides access to resources that the organization may not have anticipated or expected. Enumeration of resources accessible from the test user (or subsequently compromised users) context can provide additional opportunities to escalate privileges or move laterally. The following are typical resource enumeration activies:
+ Server Message Block (SMB) Shares – SMB enumeration can be used to identify accessible network shares and as an indicator of elevated privileges on a host. When organizations typically assess the exposure of SMB shares, they usually focus their attention on common mapped network drives within the environment. In reality, SMB shares on other systems can pose a significant risk to the organization, exposing configuration files, credentials, virtual machine elements, and sensitive information, to name a few common resources discovered.
+ Microsoft SQL Server – Accessible Microsoft SQL server instances provide potential for lateral movement and privilege escalation within an Active Directory environment. Auditing SQL server configurations might lead to remote code execution in the underlying operating system, capture or relay of credentials for the SQL server service account, or discovery of sensitive information.
+ E-Mail/Microsoft Exchange/O365 – In Outlook, users can directly share their own mailboxes to allow other users access to read or send email. Lack of understanding may lead a user to assign improper permissions, inadvertently allowing a wide audience mailbox access.
title: Credential Harvesting
Credential harvesting can be achieved using several different techniques. In addition to methods outlined in Protocol Abuse and Forced Authentication Attacks, several post-compromise activities can be used to gather additional credentials useful in the context of the environment. These include registry analysis, browser profile analysis, token stealing, in-memory kerberos ticket harvesting, and memory analysis. Browser profile analysis normally occurs after a payload is executed in the context of a new user. Token stealing, memory analysis, and registry analysis typically occur after obtaining administrative access on a computer.title: Password Attacks
Like the internal network penetration test, password guessing, password spraying, and default credential checks are often conducted on Assumed Compromise (Internal Pivot) tests. In the context of this test, password spraying is often conducted to demonstrate the impact of a weak password policy or to expand access to the environment.
In the case of weak password policy testing, the default domain password policy and any fine-grained policies should be reviewed. Even in the presence of strong password policies, accounts with older passwords (discovered via Active Directory analysis) can be subject to attack. Spraying passwords discovered during sensitive content discovery can be a valuable source of guesses.
Password spraying frequency should be approved by the customer and coordinated with other testers when concurrent testing is performed (simultaneous internal and external penetration test) to avoid account lockout.In an assumed compromise engagement, the tasks outlined above are typically executed in cyclical fashion. When a new context is gained (access to a new system or user account), re-execution of tasks may provide new opportunities for lateral movement and privilege escalation.
In particularly well secured environments, the tester may need to revert to more overt activities like port scanning. In addition, if endpoint security products interfere with testing activity causing limited to no progress, it may be necessary to negotiate placing the endpoint products in alert only mode.
Social engineering is not in scope for an Assumed Compromise (Internal Pivot) test unless it is explicitly included in the Statement of Work as a non-standard element.