Presented by: Ashwin (Microsoft Azure MVP)
AADInternals is a PowerShell-based framework for administering, enumerating, and exploiting Azure Active Directory. The tool is publicly available on GitHub.
Source:
MITRE ATT&CK® Matrix for Enterprise
Now, let's see the details around the series of events associated with this software in chronological order, and how we can work to mitigate or detect these threats.
AADInternals can check for the existence of user email addresses using public Microsoft APIs.
Adversaries may gather email addresses that can be used during targeting. Even if internal instances exist, organizations may have public-facing email infrastructure and addresses for employees.
Adversaries may easily gather email addresses, since they may be readily available and exposed via online or other accessible data sets (ex: Social Media or Search Victim-Owned Websites). Email addresses could also be enumerated via more active means (i.e. Active Scanning), such as probing and analyzing responses from authentication services that may reveal valid usernames in a system.
Gathering this information may reveal opportunities for other forms of reconnaissance (ex: Search Open Websites/Domains or Phishing for Information), establishing operational resources (ex: Email Accounts), and/or initial access (ex: Phishing or Brute Force via External Remote Services).
Pre-compromise
This technique cannot be easily mitigated with preventive controls since it is based on behaviors performed outside of the scope of enterprise defenses and controls. Efforts should focus on minimizing the amount and sensitivity of data available to external parties.
Monitoring the following activities in your Organization can help you detect this technique.
Network Traffic: Network Traffic Content
Logged network traffic data showing both protocol header and body values (ex: PCAP)
Monitor for suspicious network traffic that could be indicative of probing for email addresses and/or usernames, such as large/iterative quantities of authentication requests originating from a single source (especially if the source is known to be associated with an adversary/botnet). Analyzing web metadata may also reveal artifacts that can be attributed to potentially malicious activity, such as referer or user-agent string HTTP/S fields.
AADInternals can gather information about a tenant’s domains using public Microsoft APIs.
Adversaries may gather information about the victim's network domain(s) that can be used during targeting. Information about domains and their properties may include a variety of details, including what domain(s) the victim owns as well as administrative data (ex: name, registrar, etc.) and more directly actionable information such as contacts (email addresses and phone numbers), business addresses, and name servers.
Adversaries may gather this information in various ways, such as direct collection actions via Active Scanning or Phishing for Information. Information about victim domains and their properties may also be exposed to adversaries via online or other accessible data sets (ex: WHOIS). Gathering this information may reveal opportunities for other forms of reconnaissance (ex: Search Open Technical Databases, Search Open Websites/Domains, or Phishing for Information), establishing operational resources (ex: Acquire Infrastructure or Compromise Infrastructure), and/or initial access (ex: Phishing).
Pre-compromise
This technique cannot be easily mitigated with preventive controls since it is based on behaviors performed outside of the scope of enterprise defenses and controls. Efforts should focus on minimizing the amount and sensitivity of data available to external parties.
Much of this activity may have a very high occurrence and associated false positive rate, as well as potentially taking place outside the visibility of the target organization, making detection difficult for defenders.
Detection efforts may be focused on related stages of the adversary lifecycle, such as during Initial Access.
AADInternals can send phishing emails containing malicious links designed to collect users’ credentials.
Adversaries may send spearphishing messages with a malicious link to elicit sensitive information that can be used during targeting. Spearphishing for information is an attempt to trick targets into divulging information, frequently credentials or other actionable information. Spearphishing for information frequently involves social engineering techniques, such as posing as a source with a reason to collect information (ex: Establish Accounts or Compromise Accounts) and/or sending multiple, seemingly urgent messages.
All forms of spearphishing are electronically delivered social engineering targeted at a specific individual, company, or industry. In this scenario, the malicious emails contain links generally accompanied by social engineering text to coax the user to actively click or copy and paste a URL into a browser. The given website may closely resemble a legitimate site in appearance and have a URL containing elements from the real site. From the fake website, information is gathered in web forms and sent to the adversary. Adversaries may also use information from previous reconnaissance efforts (ex: Search Open Websites/Domains or Search Victim-Owned Websites) to craft persuasive and believable lures.
Software Configuration
Use anti-spoofing and email authentication mechanisms to filter messages based on validity checks of the sender domain (using SPF) and integrity of messages (using DKIM). Enabling these mechanisms within an organization (through policies such as DMARC) may enable recipients (intra-org and cross domain) to perform similar message filtering and validation.
User Training
Users can be trained to identify social engineering techniques and spearphishing attempts.
Monitoring the following activities in your Organization can help you detect this technique.
Application Log: Application Log Content
Logging, messaging, and other artifacts provided by third-party services (ex: metrics, errors, and/or alerts from mail/web applications)
Monitor for suspicious email activity, such as numerous accounts receiving messages from a single unusual/unknown sender. Filtering based on DKIM+SPF or header analysis can help detect when the email sender is spoofed. Monitor for references to uncategorized or known-bad sites. URL inspection within email (including expanding shortened links) can also help detect links leading to known malicious sites.
Network Traffic: Network Traffic Content
Logged network traffic data showing both protocol header and body values (ex: PCAP)
Monitor and analyze traffic patterns and packet inspection associated to protocol(s), leveraging SSL/TLS inspection for encrypted traffic, that do not follow the expected protocol standards and traffic flows (e.g extraneous packets that do not belong to established flows, gratuitous or anomalous traffic patterns, anomalous syntax, or structure). Consider correlation with process monitoring and command line to detect anomalous processes execution and command line arguments associated to traffic patterns (e.g. monitor anomalies in use of files that do not normally initiate connections for respective protocol(s)).
Network Traffic: Network Traffic Flow
Summarized network packet data, with metrics, such as protocol headers and volume (ex: Netflow or Zeek http.log)
Monitor network data for uncommon data flows. Processes utilizing the network that do not normally have network communication or have never been seen before are suspicious.
AADInternals can send "consent phishing" emails containing malicious links designed to steal users’ access tokens.
Adversaries may send spearphishing emails with a malicious link in an attempt to gain access to victim systems. Spearphishing with a link is a specific variant of spearphishing. It is different from other forms of spearphishing in that it employs the use of links to download malware contained in email, instead of attaching malicious files to the email itself, to avoid defenses that may inspect email attachments. Spearphishing may also involve social engineering techniques, such as posing as a trusted source.
All forms of spearphishing are electronically delivered social engineering targeted at a specific individual, company, or industry. In this case, the malicious emails contain links. Generally, the links will be accompanied by social engineering text and require the user to actively click or copy and paste a URL into a browser, leveraging User Execution. The visited website may compromise the web browser using an exploit, or the user will be prompted to download applications, documents, zip files, or even executables depending on the pretext for the email in the first place. Adversaries may also include links that are intended to interact directly with an email reader, including embedded images intended to exploit the end system directly or verify the receipt of an email (i.e. web bugs/web beacons).
Adversaries may also utilize links to perform consent phishing, typically with OAuth 2.0 request URLs that when accepted by the user provide permissions/access for malicious applications, allowing adversaries to Steal Application Access Tokens. These stolen access tokens allow the adversary to perform various actions on behalf of the user via API calls.
Audit
Audit applications and their permissions to ensure access to data and resources are limited based upon necessity and principle of least privilege.
Restrict Web-Based Content
Determine if certain websites that can be used for spearphishing are necessary for business operations and consider blocking access if activity cannot be monitored well or if it poses a significant risk.
Software Configuration
Use anti-spoofing and email authentication mechanisms to filter messages based on validity checks of the sender domain (using SPF) and integrity of messages (using DKIM). Enabling these mechanisms within an organization (through policies such as DMARC) may enable recipients (intra-org and cross domain) to perform similar message filtering and validation.
User Account Management
Azure AD Administrators apply limitations upon the ability for users to grant consent to unfamiliar or unverified third-party applications.
User Training
Users can be trained to identify social engineering techniques and spearphishing emails with malicious links which includes phishing for consent with OAuth 2.0
Monitoring the following activities in your Organization can help you detect this technique.
Application Log: Application Log Content
Logging, messaging, and other artifacts provided by third-party services (ex: metrics, errors, and/or alerts from mail/web applications)
Monitor for third-party application logging, messaging, and/or other artifacts that may send spearphishing emails with a malicious link in an attempt to gain access to victim systems. Filtering based on DKIM+SPF or header analysis can help detect when the email sender is spoofed. URL inspection within email (including expanding shortened links) can help detect links leading to known malicious sites. Detonation chambers can be used to detect these links and either automatically go to these sites to determine if they're potentially malicious, or wait and capture the content if a user visits the link.
Network Traffic: Network Traffic Content
Logged network traffic data showing both protocol header and body values (ex: PCAP)
Monitor and analyze SSL/TLS traffic patterns and packet inspection associated to protocol(s) that do not follow the expected protocol standards and traffic flows (e.g extraneous packets that do not belong to established flows, gratuitous or anomalous traffic patterns, anomalous syntax, or structure). Consider correlation with process monitoring and command line to detect anomalous processes execution and command line arguments associated to traffic patterns (e.g. monitor anomalies in use of files that do not normally initiate connections for respective protocol(s)).
Network Traffic: Network Traffic Flow
Summarized network packet data, with metrics, such as protocol headers and volume (ex: Netflow or Zeek http.log)
Monitor network data for uncommon data flows. Processes utilizing the network that do not normally have network communication or have never been seen before are suspicious.
AADInternals is written and executed via PowerShell.
Adversaries may abuse PowerShell commands and scripts for execution. PowerShell is a powerful interactive command-line interface and scripting environment included in the Windows operating system. Adversaries can use PowerShell to perform a number of actions, including discovery of information and execution of code. Examples include the Start-Process cmdlet which can be used to run an executable and the Invoke-Command cmdlet which runs a command locally or on a remote computer (though administrator permissions are required to use PowerShell to connect to remote systems).
PowerShell may also be used to download and run executables from the Internet, which can be executed from disk or in memory without touching disk.
A number of PowerShell-based offensive testing tools are available, including Empire, PowerSploit, PoshC2, and PSAttack.
PowerShell commands/scripts can also be executed without directly invoking the powershell.exe binary through interfaces to PowerShell's underlying System.Management.Automation assembly DLL exposed through the .NET framework and Windows Common Language Interface (CLI).
Antivirus/Antimalware
Anti-virus can be used to automatically quarantine suspicious files.
Code Signing
Set PowerShell execution policy to execute only signed scripts.
Disable or Remove Feature or Program
It may be possible to remove PowerShell from systems when not needed, but a review should be performed to assess the impact to an environment, since it could be in use for many legitimate purposes and administrative functions.
Disable/restrict the WinRM Service to help prevent uses of PowerShell for remote execution.
Execution Prevention
Use application control where appropriate.
Privileged Account Management
When PowerShell is necessary, restrict PowerShell execution policy to administrators. Be aware that there are methods of bypassing the PowerShell execution policy, depending on environment configuration.
Monitoring the following activities in your Organization can help you detect this technique.
Command: Command Execution
Invoking a computer program directive to perform a specific task (ex: Windows EID 4688 of cmd.exe showing command-line parameters, ~/.bash_history, or ~/.zsh_history)
If proper execution policy is set, adversaries will likely be able to define their own execution policy if they obtain administrator or system access, either through the Registry or at the command line. This change in policy on a system may be a way to detect malicious use of PowerShell. If PowerShell is not used in an environment, then simply looking for PowerShell execution may detect malicious activity. It is also beneficial to turn on PowerShell logging to gain increased fidelity in what occurs during execution (which is applied to .NET invocations). PowerShell 5.0 introduced enhanced logging capabilities, and some of those features have since been added to PowerShell 4.0. Earlier versions of PowerShell do not have many logging features. An organization can gather PowerShell execution details in a data analytic platform to supplement it with other data.
Module: Module Load
Attaching a module into the memory of a process/program, typically to access shared resources/features provided by the module (ex: Sysmon EID 7)
Monitor for loading and/or execution of artifacts associated with PowerShell specific assemblies, such as System.Management.Automation.dll (especially to unusual process names/locations).
Process: Process Creation
Birth of a new running process (ex: Sysmon EID 1 or Windows EID 4688)
Monitor for newly executed processes that may abuse PowerShell commands and scripts for execution.
Process: Process Metadata
Contextual data about a running process, which may include information such as environment variables, image name, user/owner, etc.
Consider monitoring for Windows event ID (EID) 400, which shows the version of PowerShell executing in the EngineVersion field (which may also be relevant to detecting a potential Downgrade Attack) as well as if PowerShell is running locally or remotely in the HostName field. Furthermore, EID 400 may indicate the start time and EID 403 indicates the end time of a PowerShell session.
Script: Script Execution
Launching a list of commands through a script file (ex: Windows EID 4104)
Monitor for any attempts to enable scripts running on a system would be considered suspicious. If scripts are not commonly used on a system, but enabled, scripts running out of cycle from patching or other administrator functions are suspicious. Scripts should be captured from the file system when possible to determine their actions and intent.
AADInternals can register a device to Azure AD.
Adversaries may register a device to an adversary-controlled account. Devices may be registered in a multifactor authentication (MFA) system, which handles authentication to the network, or in a device management system, which handles device access and compliance.
MFA systems, such as Duo or Okta, allow users to associate devices with their accounts in order to complete MFA requirements. An adversary that compromises a user’s credentials may enroll a new device in order to bypass initial MFA requirements and gain persistent access to a network.
Similarly, an adversary with existing access to a network may register a device to Azure AD and/or its device management system, Microsoft Intune, in order to access sensitive data or resources while bypassing conditional access policies.
Devices registered in Azure AD may be able to conduct Internal Spearphishing campaigns via intra-organizational emails, which are less likely to be treated as suspicious by the email client. Additionally, an adversary may be able to perform a Service Exhaustion Flood on an Azure AD tenant by registering a large number of devices.
Multi-factor Authentication
Require multi-factor authentication to register devices in Azure AD. Configure multi-factor authentication systems to disallow enrolling new devices for inactive accounts.
Monitoring the following activities in your Organization can help you detect this technique.
Active Directory: Active Directory Object Creation
Initial construction of a new active directory object (ex: Windows EID 5137)
Monitor for the registration or joining of new device objects in Active Directory.
Application Log: Application Log Content
Logging, messaging, and other artifacts provided by third-party services (ex: metrics, errors, and/or alerts from mail/web applications)
Azure AD creates several log entries when new devices are enrolled, which can be monitored for unexpected device registrations. Additionally, joined devices can be viewed via the Azure AD portal.
User Account: User Account Modification
Changes made to an account, such as permissions and/or membership in specific groups (ex: Windows EID 4738 or /var/log access/authentication logs)
Monitor user accounts for new and suspicious device associations, such as those originating from unusual sources, occurring at unusual times, or following a suspicious login.
AADInternals can create new Azure AD users.
Adversaries may create a cloud account to maintain access to victim systems. With a sufficient level of access, such accounts may be used to establish secondary credentialed access that does not require persistent remote access tools to be deployed on the system.
Adversaries may create accounts that only have access to specific cloud services, which can reduce the chance of detection.
Multi-factor Authentication
Use multi-factor authentication for user and privileged accounts.
Network Segmentation
Configure access controls and firewalls to limit access to critical systems and domain controllers. Most cloud environments support separate virtual private cloud (VPC) instances that enable further segmentation of cloud systems.
Privileged Account Management
Do not allow privileged accounts to be used for day-to-day operations that may expose them to potential adversaries on unprivileged systems.
Monitoring the following activities in your Organization can help you detect this technique.
User Account: User Account Creation
Initial construction of a new account (ex: Windows EID 4720 or /etc/passwd logs)
Monitor for newly constructed user accounts through the collection of usage logs from cloud user and administrator accounts to identify unusual activity in the creation of new accounts and assignment of roles to those accounts. Monitor for accounts assigned to admin roles that go over a certain threshold of known admins.
AADInternals can create a backdoor by converting a domain to a federated domain which will be able to authenticate any user across the tenant. AADInternals can also modify DesktopSSO information.
Adversaries may modify the configuration settings of a domain to evade defenses and/or escalate privileges in domain environments. Domains provide a centralized means of managing how computer resources (ex: computers, user accounts) can act, and interact with each other, on a network. The policy of the domain also includes configuration settings that may apply between domains in a multi-domain/forest environment. Modifications to domain settings may include altering domain Group Policy Objects (GPOs) or changing trust settings for domains, including federation trusts.
With sufficient permissions, adversaries can modify domain policy settings. Since domain configuration settings control many of the interactions within the Active Directory (AD) environment, there are a great number of potential attacks that can stem from this abuse. Examples of such abuse include modifying GPOs to push a malicious Scheduled Task to computers throughout the domain environment or modifying domain trusts to include an adversary controlled domain where they can control access tokens that will subsequently be accepted by victim domain resources. Adversaries can also change configuration settings within the AD environment to implement a Rogue Domain Controller.
Adversaries may temporarily modify domain policy, carry out a malicious action(s), and then revert the change to remove suspicious indicators.
Audit
Identify and correct GPO permissions abuse opportunities (ex: GPO modification privileges) using auditing tools such as BloodHound (version 1.5.1 and later)[7].
Privileged Account Management
Use least privilege and protect administrative access to the Domain Controller and Active Directory Federation Services (AD FS) server. Do not create service accounts with administrative privileges.
User Account Management
Consider implementing WMI and security filtering to further tailor which users and computers a GPO will apply to.
Monitoring the following activities in your Organization can help you detect this technique.
Active Directory: Active Directory Object Creation
Initial construction of a new active directory object (ex: Windows EID 5137)
Monitor for newly constructed active directory objects, such as Windows EID 5137
Active Directory: Active Directory Object Deletion
Removal of an active directory object (ex: Windows EID 5141)
Monitor for unexpected deletion of an active directory object, such as Windows EID 5141
Active Directory: Active Directory Object Modification
Changes made to an active directory object (ex: Windows EID 5163 or 5136)
Monitor for changes made to AD settings for unexpected modifications to user accounts, such as deletions or potentially malicious changes to user attributes (credentials, status, etc.).
Command: Command Execution
Invoking a computer program directive to perform a specific task (ex: Windows EID 4688 of cmd.exe showing command-line parameters, ~/.bash_history, or ~/.zsh_history)
Monitor executed commands and arguments for modifications to domain trust settings, such as when a user or application modifies the federation settings on the domain or updates domain authentication from Managed to Federated via ActionTypes Set federation settings on domain and Set domain authentication.
AADInternals can modify registry keys as part of setting a new pass-through authentication agent.
Adversaries may interact with the Windows Registry to hide configuration information within Registry keys, remove information as part of cleaning up, or as part of other techniques to aid in persistence and execution.
Access to specific areas of the Registry depends on account permissions, some requiring administrator-level access. The built-in Windows command-line utility Reg may be used for local or remote Registry modification. Other tools may also be used, such as a remote access tool, which may contain functionality to interact with the Registry through the Windows API.
Registry modifications may also include actions to hide keys, such as prepending key names with a null character, which will cause an error and/or be ignored when read via Reg or other utilities using the Win32 API. Adversaries may abuse these pseudo-hidden keys to conceal payloads/commands used to maintain persistence.
The Registry of a remote system may be modified to aid in execution of files as part of lateral movement. It requires the remote Registry service to be running on the target system. Often Valid Accounts are required, along with access to the remote system's SMB/Windows Admin Shares for RPC communication.
Restrict Registry Permissions
Ensure proper permissions are set for Registry hives to prevent users from modifying keys for system components that may lead to privilege escalation.
Monitoring the following activities in your Organization can help you detect this technique.
Command: Command Execution
Invoking a computer program directive to perform a specific task (ex: Windows EID 4688 of cmd.exe showing command-line parameters, ~/.bash_history, or ~/.zsh_history)
Monitor executed commands and arguments for actions that could be taken to change, conceal, and/or delete information in the Registry. The Registry may also be modified through Windows system management tools such as Windows Management Instrumentation and PowerShell, which may require additional logging features to be configured in the operating system to collect necessary information for analysis.
Process: OS API Execution
Initial construction of a WMI object, such as a filter, consumer, subscription, binding, or provider (ex: Sysmon EIDs 19-21)
Monitor for API calls associated with concealing Registry keys, such as Reghide. Inspect and cleanup malicious hidden Registry entries using Native Windows API calls and/or tools such as Autoruns and RegDelNull
Process: Process Creation
Birth of a new running process (ex: Sysmon EID 1 or Windows EID 4688)
Monitor processes and command-line arguments for actions that could be taken to change, conceal, and/or delete information in the Registry. (i.e. reg.exe, regedit.exe)
Windows Registry: Windows Registry Key Creation
Initial construction of a new Registry Key (ex: Windows EID 4656 or Sysmon EID 12)
Monitor for newly constructed registry keys or values to aid in persistence and execution.
Windows Registry: Windows Registry Key Deletion
Removal of a Registry Key (ex: Windows EID 4658 or Sysmon EID 12)
Monitor for unexpected deletion of windows registry keys to hide configuration information, remove information as part of cleaning up, or as part of other techniques to aid in persistence and execution.
Windows Registry: Windows Registry Key Modification
Changes made to a Registry Key and/or Key value (ex: Windows EID 4657 or Sysmon EID 13|14)
Monitor for changes made to windows registry keys or values. Consider enabling Registry Auditing on specific keys to produce an alertable event (Event ID 4657) whenever a value is changed (though this may not trigger when values are created with Reghide or other evasive methods). Changes to Registry entries that load software on Windows startup that do not correlate with known software, patch cycles, etc., are suspicious, as are additions or changes to files within the startup folder. Changes could also include new services and modification of existing binary paths to point to malicious files. If a change to a service-related entry occurs, then it will likely be followed by a local or remote service start or restart to execute the file.
AADInternals can create a backdoor by converting a domain to a federated domain which will be able to authenticate any user across the tenant. AADInternals can also modify DesktopSSO information.
Adversaries may modify the configuration settings of a domain to evade defenses and/or escalate privileges in domain environments. Domains provide a centralized means of managing how computer resources (ex: computers, user accounts) can act, and interact with each other, on a network. The policy of the domain also includes configuration settings that may apply between domains in a multi-domain/forest environment. Modifications to domain settings may include altering domain Group Policy Objects (GPOs) or changing trust settings for domains, including federation trusts.
With sufficient permissions, adversaries can modify domain policy settings. Since domain configuration settings control many of the interactions within the Active Directory (AD) environment, there are a great number of potential attacks that can stem from this abuse. Examples of such abuse include modifying GPOs to push a malicious Scheduled Task to computers throughout the domain environment or modifying domain trusts to include an adversary controlled domain where they can control access tokens that will subsequently be accepted by victim domain resources. Adversaries can also change configuration settings within the AD environment to implement a Rogue Domain Controller.
Adversaries may temporarily modify domain policy, carry out a malicious action(s), and then revert the change to remove suspicious indicators.
Audit
Identify and correct GPO permissions abuse opportunities (ex: GPO modification privileges) using auditing tools such as BloodHound (version 1.5.1 and later)[7].
Privileged Account Management
Use least privilege and protect administrative access to the Domain Controller and Active Directory Federation Services (AD FS) server. Do not create service accounts with administrative privileges.
User Account Management
Consider implementing WMI and security filtering to further tailor which users and computers a GPO will apply to.
Monitoring the following activities in your Organization can help you detect this technique.
Active Directory: Active Directory Object Creation
Initial construction of a new active directory object (ex: Windows EID 5137)
Monitor for newly constructed active directory objects, such as Windows EID 5137
Active Directory: Active Directory Object Deletion
Removal of an active directory object (ex: Windows EID 5141)
Monitor for unexpected deletion of an active directory object, such as Windows EID 5141
Active Directory: Active Directory Object Modification
Changes made to an active directory object (ex: Windows EID 5163 or 5136)
Monitor for changes made to AD settings for unexpected modifications to user accounts, such as deletions or potentially malicious changes to user attributes (credentials, status, etc.).
Command: Command Execution
Invoking a computer program directive to perform a specific task (ex: Windows EID 4688 of cmd.exe showing command-line parameters, ~/.bash_history, or ~/.zsh_history)
Monitor executed commands and arguments for modifications to domain trust settings, such as when a user or application modifies the federation settings on the domain or updates domain authentication from Managed to Federated via ActionTypes Set federation settings on domain and Set domain authentication.
AADInternals can dump secrets from the Local Security Authority.
Adversaries with SYSTEM access to a host may attempt to access Local Security Authority (LSA) secrets, which can contain a variety of different credential materials, such as credentials for service accounts.[1][2][3] LSA secrets are stored in the registry at HKEY_LOCAL_MACHINE\SECURITY\Policy\Secrets. LSA secrets can also be dumped from memory.[4]
Reg can be used to extract from the Registry. Mimikatz can be used to extract secrets from memory.
Password Policies
Ensure that local administrator accounts have complex, unique passwords across all systems on the network.
Privileged Account Management
Follow best practices for design and administration of an enterprise network to limit privileged account use across administrative tiers.
User Training
Limit credential overlap across accounts and systems by training users and administrators not to use the same password for multiple accounts.
Monitoring the following activities in your Organization can help you detect this technique.
Command: Command Execution
Invoking a computer program directive to perform a specific task (ex: Windows EID 4688 of cmd.exe showing command-line parameters, ~/.bash_history, or ~/.zsh_history)
Monitor executed commands and arguments that may access to a host may attempt to access Local Security Authority (LSA) secrets. Remote access tools may contain built-in features or incorporate existing tools like Mimikatz. PowerShell scripts also exist that contain credential dumping functionality, such as PowerSploit's Invoke-Mimikatz module, which may require additional logging features to be configured in the operating system to collect necessary information for analysis.
Windows Registry: Windows Registry Key Access
Opening a Registry Key, typically to read the associated value (ex: Windows EID 4656)
Monitor for the LSA secrets are stored in the registry at HKEY_LOCAL_MACHINE\SECURITY\Policy\Secrets being accessed
AADInternals can steal users’ access tokens via phishing emails containing malicious links.
Adversaries can steal application access tokens as a means of acquiring credentials to access remote systems and resources.
Application access tokens are used to make authorized API requests on behalf of a user or service and are commonly used as a way to access resources in cloud and container-based applications and software-as-a-service (SaaS). OAuth is one commonly implemented framework that issues tokens to users for access to systems. Adversaries who steal account API tokens in cloud and containerized environments may be able to access data and perform actions with the permissions of these accounts, which can lead to privilege escalation and further compromise of the environment.
In Kubernetes environments, processes running inside a container communicate with the Kubernetes API server using service account tokens. If a container is compromised, an attacker may be able to steal the container’s token and thereby gain access to Kubernetes API commands.
Token theft can also occur through social engineering, in which case user action may be required to grant access. An application desiring access to cloud-based services or protected APIs can gain entry using OAuth 2.0 through a variety of authorization protocols. An example commonly-used sequence is Microsoft's Authorization Code Grant flow. An OAuth access token enables a third-party application to interact with resources containing user data in the ways requested by the application without obtaining user credentials.
Adversaries can leverage OAuth authorization by constructing a malicious application designed to be granted access to resources with the target user's OAuth token. The adversary will need to complete registration of their application with the authorization server, for example Microsoft Identity Platform using Azure Portal, the Visual Studio IDE, the command-line interface, PowerShell, or REST API calls. Then, they can send a Spearphishing Link to the target user to entice them to grant access to the application. Once the OAuth access token is granted, the application can gain potentially long-term access to features of the user account through Application Access Token.
Application access tokens may function within a limited lifetime, limiting how long an adversary can utilize the stolen token. However, in some cases, adversaries can also steal application refresh tokens, allowing them to obtain new access tokens without prompting the user.
Audit
Administrators should audit all cloud and container accounts to ensure that they are necessary and that the permissions granted to them are appropriate. Additionally, administrators should perform an audit of all OAuth applications and the permissions they have been granted to access organizational data. This should be done extensively on all applications in order to establish a baseline, followed up on with periodic audits of new or updated applications. Suspicious applications should be investigated and removed.
Restrict Web-Based Content
Administrators can block end-user consent to OAuth applications, disabling users from authorizing third-party apps through OAuth 2.0 and forcing administrative consent for all requests. They can also block end-user registration of applications by their users, to reduce risk. A Cloud Access Security Broker can also be used to ban applications.
Azure offers a couple of enterprise policy settings in the Azure Management Portal that may help:
"Users -> User settings -> App registrations: Users can register applications" can be set to "no" to prevent users from registering new applications. "Enterprise applications -> User settings -> Enterprise applications: Users can consent to apps accessing company data on their behalf" can be set to "no" to prevent users from consenting to allow third-party multi-tenant applications
User Account Management
Enforce role-based access control to limit accounts to the least privileges they require. A Cloud Access Security Broker (CASB) can be used to set usage policies and manage user permissions on cloud applications to prevent access to application access tokens. In Kubernetes applications, set "automountServiceAccountToken: false" in the YAML specification of pods that do not require access to service account tokens.
User Training
Users need to be trained to not authorize third-party applications they don’t recognize. The user should pay particular attention to the redirect URL: if the URL is a misspelled or convoluted sequence of words related to an expected service or SaaS application, the website is likely trying to spoof a legitimate service. Users should also be cautious about the permissions they are granting to apps. For example, offline access and access to read emails should excite higher suspicions because adversaries can utilize SaaS APIs to discover credentials and other sensitive communications.
Monitoring the following activities in your Organization can help you detect this technique.
User Account: User Account Modification
Changes made to an account, such as permissions and/or membership in specific groups (ex: Windows EID 4738 or /var/log access/authentication logs)
Administrators should set up monitoring to trigger automatic alerts when policy criteria are met. For example, using a Cloud Access Security Broker (CASB), admins can create a "High severity app permissions" policy that generates alerts if apps request high severity permissions or send permissions requests for too many users.Security analysts can hunt for malicious apps using the tools available in their CASB, identity provider, or resource provider (depending on platform.) For example, they can filter for apps that are authorized by a small number of users, apps requesting high risk permissions, permissions incongruous with the app’s purpose, or apps with old "Last authorized" fields. A specific app can be investigated using an activity log displaying activities the app has performed, although some activities may be mis-logged as being performed by the user. App stores can be useful resources to further investigate suspicious apps.Administrators can set up a variety of logs and leverage audit tools to monitor actions that can be conducted as a result of OAuth 2.0 access. For instance, audit reports enable admins to identify privilege escalation actions such as role creations or policy modifications, which could be actions performed after initial access.
AADInternals can gather unsecured credentials for Azure AD services, such as Azure AD Connect, from a local machine.
Adversaries may search local file systems and remote file shares for files containing insecurely stored credentials. These can be files created by users to store their own credentials, shared credential stores for a group of individuals, configuration files containing passwords for a system or service, or source code/binary files containing embedded passwords.
It is possible to extract passwords from backups or saved virtual machines through OS Credential Dumping. Passwords may also be obtained from Group Policy Preferences stored on the Windows Domain Controller.
In cloud and/or containerized environments, authenticated user and service account credentials are often stored in local configuration and credential files. They may also be found as parameters to deployment commands in container logs. In some cases, these files can be copied and reused on another machine or the contents can be read and then used to authenticate without needing to copy any files.
Audit
Preemptively search for files containing passwords and take actions to reduce the exposure risk when found.
Password Policies
Establish an organizational policy that prohibits password storage in files.
Restrict File and Directory Permissions
Restrict file shares to specific directories with access only to necessary users.
User Training
Ensure that developers and system administrators are aware of the risk associated with having plaintext passwords in software configuration files that may be left on endpoint systems or servers.
Monitoring the following activities in your Organization can help you detect this technique.
Command: Command Execution
Invoking a computer program directive to perform a specific task (ex: Windows EID 4688 of cmd.exe showing command-line parameters, ~/.bash_history, or ~/.zsh_history)
While detecting adversaries accessing these files may be difficult without knowing they exist in the first place, it may be possible to detect adversary use of credentials they have obtained. Monitor executed commands and arguments of executing processes for suspicious words or regular expressions that may indicate searching for a password (for example: password, pwd, login, secure, or credentials). See Valid Accounts for more information.
File: File Access
Opening a file, which makes the file contents available to the requestor (ex: Windows EID 4663)
Monitor for files being accessed that may search local file systems and remote file shares for files containing insecurely stored credentials. While detecting adversaries accessing these files may be difficult without knowing they exist in the first place, it may be possible to detect adversary use of credentials they have obtained.
AADInternals can gather encryption keys from Azure AD services such as ADSync and Active Directory Federated Services servers.
Adversaries may search for private key certificate files on compromised systems for insecurely stored credentials. Private cryptographic keys and certificates are used for authentication, encryption/decryption, and digital signatures. Common key and certificate file extensions include: .key, .pgp, .gpg, .ppk., .p12, .pem, .pfx, .cer, .p7b, .asc.
Adversaries may also look in common key directories, such as ~/.ssh for SSH keys on * nix-based systems or C:\Users\(username)\.ssh\ on Windows. These private keys can be used to authenticate to Remote Services like SSH or for use in decrypting other collected files such as email.
Adversary tools have been discovered that search compromised systems for file extensions relating to cryptographic keys and certificates.
Some private keys require a password or passphrase for operation, so an adversary may also use Input Capture for keylogging or attempt to Brute Force the passphrase off-line.
Audit
Ensure only authorized keys are allowed access to critical resources and audit access lists regularly.
Encrypt Sensitive Information
When possible, store keys on separate cryptographic hardware instead of on the local system.
Password Policies
Use strong passphrases for private keys to make cracking difficult.
Restrict File and Directory Permissions
Ensure permissions are properly set on folders containing sensitive private keys to prevent unintended access.
Monitoring the following activities in your Organization can help you detect this technique.
Command: Command Execution
Invoking a computer program directive to perform a specific task (ex: Windows EID 4688 of cmd.exe showing command-line parameters, ~/.bash_history, or ~/.zsh_history)
Monitor executed commands and arguments that may search for private key certificate files on compromised systems for insecurely stored credentials.
File: File Access
Opening a file, which makes the file contents available to the requestor (ex: Windows EID 4663)
Monitor access to files and directories related to cryptographic keys and certificates as a means for potentially detecting access patterns that may indicate collection and exfiltration activity.
AADInternals can be used to forge Kerberos tickets using the password hash of the AZUREADSSOACC account.
Adversaries who have the password hash of a target service account (e.g. SharePoint, MSSQL) may forge Kerberos ticket granting service (TGS) tickets, also known as silver tickets. Kerberos TGS tickets are also known as service tickets.
Silver tickets are more limited in scope in than golden tickets in that they only enable adversaries to access a particular resource (e.g. MSSQL) and the system that hosts the resource; however, unlike golden tickets, adversaries with the ability to forge silver tickets are able to create TGS tickets without interacting with the Key Distribution Center (KDC), potentially making detection more difficult.
Password hashes for target services may be obtained using OS Credential Dumping or Kerberoasting.
Encrypt Sensitive Information
Enable AES Kerberos encryption (or another stronger encryption algorithm), rather than RC4, where possible.
Password Policies
Ensure strong password length (ideally 25+ characters) and complexity for service accounts and that these passwords periodically expire.[6] Also consider using Group Managed Service Accounts or another third party product such as password vaulting.[6]
Privileged Account Management
Limit service accounts to minimal required privileges, including membership in privileged groups such as Domain Administrators.
Monitoring the following activities in your Organization can help you detect this technique.
Logon Session: Logon Session Metadata
Contextual data about a logon session, such as username, logon type, access tokens (security context, user SIDs, logon identifiers, and logon SID), and any activity associated within it
Monitor for anomalous Kerberos activity, such as malformed or blank fields in Windows logon/logoff events (Event ID 4624, 4634, 4672).
AADInternals can be used to create SAML tokens using the AD Federated Services token signing certificate.
An adversary may forge SAML tokens with any permissions claims and lifetimes if they possess a valid SAML token-signing certificate. The default lifetime of a SAML token is one hour, but the validity period can be specified in the NotOnOrAfter value of the conditions ... element in a token. This value can be changed using the AccessTokenLifetime in a LifetimeTokenPolicy. Forged SAML tokens enable adversaries to authenticate across services that use SAML 2.0 as an SSO (single sign-on) mechanism.
An adversary may utilize Private Keys to compromise an organization's token-signing certificate to create forged SAML tokens. If the adversary has sufficient permissions to establish a new federation trust with their own Active Directory Federation Services (AD FS) server, they may instead generate their own trusted token-signing certificate. This differs from Steal Application Access Token and other similar behaviors in that the tokens are new and forged by the adversary, rather than stolen or intercepted from legitimate users.
An adversary may gain administrative Azure AD privileges if a SAML token is forged which claims to represent a highly privileged account. This may lead to Use Alternate Authentication Material, which may bypass multi-factor and other authentication protection mechanisms.
Active Directory Configuration
For containing the impact of a previously forged SAML token, rotate the token-signing AD FS certificate in rapid succession twice, which will invalidate any tokens generated using the previous certificate.
Audit
Enable advanced auditing on AD FS. Check the success and failure audit options in the AD FS Management snap-in. Enable Audit Application Generated events on the AD FS farm via Group Policy Object.
Privileged Account Management
Restrict permissions and access to the AD FS server to only originate from privileged access workstations.
User Account Management
Ensure that user accounts with administrative rights follow best practices, including use of privileged access workstations, Just in Time/Just Enough Administration (JIT/JEA), and strong authentication. Reduce the number of users that are members of highly privileged Directory Roles.
Monitoring the following activities in your Organization can help you detect this technique.
Logon Session: Logon Session Creation
Initial construction of a new user logon session (ex: Windows EID 4624, /var/log/utmp, or /var/log/wmtp)
Monitor for logins using SAML tokens which do not have corresponding 4769 and 1200 events in the domain. These logins may occur on any on-premises resources as well as from any cloud environment that trusts the certificate.
Logon Session: Logon Session Metadata
Contextual data about a logon session, such as username, logon type, access tokens (security context, user SIDs, logon identifiers, and logon SID), and any activity associated within it
Consider modifying SAML responses to include custom elements for each service provider. Monitor these custom elements in service provider access logs to detect any anomalous requests.
User Account: User Account Authentication
An attempt by a user to gain access to a network or computing resource, often by providing credentials (ex: Windows EID 4625 or /var/log/auth.log)
Monitor for user authentication attempts, when requesting access tokens to services, that failed because of Conditional Access Policies (CAP). Some SAML tokens features, such as the location of a user, may not be as easy to claim.
Web Credential: Web Credential Creation
Initial construction of new web credential material (ex: Windows EID 1200 or 4769)
Monitor for creation of access tokens using SAML tokens which do not have corresponding 4769 and 1200 events in the domain.
Web Credential: Web Credential Usage
An attempt by a user to gain access to a network or computing resource by providing web credentials (ex: Windows EID 1202)
Monitor for the use of access tokens to access services such as email that were created using SAML tokens which do not have corresponding 1202 events (i.e. "The Federation Service validated a new credential") in the domain.
AADInternals can enumerate Azure AD groups.
Adversaries may attempt to find cloud groups and permission settings. The knowledge of cloud permission groups can help adversaries determine the particular roles of users and groups within an environment, as well as which users are associated with a particular group.
With authenticated access there are several tools that can be used to find permissions groups. The Get-MsolRole PowerShell cmdlet can be used to obtain roles and permissions groups for Exchange and Office 365 accounts.
Azure CLI (AZ CLI) and the Google Cloud Identity Provider API also provide interfaces to obtain permissions groups. The command az ad user get-member-groups will list groups associated to a user account for Azure while the API endpoint GET https://cloudidentity.googleapis.com/v1/groups lists group resources available to a user for Google.
Adversaries may attempt to list ACLs for objects to determine the owner and other accounts with access to the object, for example, via the AWS GetBucketAcl API. Using this information an adversary can target accounts with permissions to a given object or leverage accounts they have already compromised to access the object.
This type of attack technique cannot be easily mitigated with preventive controls since it is based on the abuse of system features.
Monitoring the following activities in your Organization can help you detect this technique.
Application Log: Application Log Content
Logging, messaging, and other artifacts provided by third-party services (ex: metrics, errors, and/or alerts from mail/web applications)
Monitor for events collected that may attempt to find cloud groups and permission settings.
Command: Command Execution
Invoking a computer program directive to perform a specific task (ex: Windows EID 4688 of cmd.exe showing command-line parameters, ~/.bash_history, or ~/.zsh_history)
Monitor for executed commands and arguments that may attempt to find cloud groups and permission settings.
Group: Group Enumeration
An extracted list of available groups and/or their associated settings (ex: AWS list-groups)
Monitor for an extracted list of available groups and/or their associated setting
Group: Group Metadata
Contextual data about a group which describes group and activity around it, such as name, permissions, or user accounts within the group
Contextual data about a group which describes group and activity around it that may attempt to find cloud groups and permission settings.
Process: Process Creation
Birth of a new running process (ex: Sysmon EID 1 or Windows EID 4688)
Monitor newly executed processes that may attempt to find cloud groups and permission settings.
AADInternals can enumerate Azure AD users.
Adversaries may attempt to get a listing of cloud accounts. Cloud accounts are those created and configured by an organization for use by users, remote support, services, or for administration of resources within a cloud service provider or SaaS application.
With authenticated access there are several tools that can be used to find accounts. The Get-MsolRoleMember PowerShell cmdlet can be used to obtain account names given a role or permissions group in Office 365. The Azure CLI (AZ CLI) also provides an interface to obtain user accounts with authenticated access to a domain. The command az ad user list will list all users within a domain.
The AWS command aws iam list-users may be used to obtain a list of users in the current account while aws iam list-roles can obtain IAM roles that have a specified path prefix. In GCP, gcloud iam service-accounts list and gcloud projects get-iam-policy may be used to obtain a listing of service accounts and users in a project.
Audit
Routinely check user permissions to ensure only the expected users have the ability to list IAM identities or otherwise discover cloud accounts.
User Account Management
Limit permissions to discover cloud accounts in accordance with least privilege. Organizations should limit the number of users within the organization with an IAM role that has administrative privileges, strive to reduce all permanent privileged role assignments, and conduct periodic entitlement reviews on IAM users, roles and policies.
Monitoring the following activities in your Organization can help you detect this technique.
Command: Command Execution
Invoking a computer program directive to perform a specific task (ex: Windows EID 4688 of cmd.exe showing command-line parameters, ~/.bash_history, or ~/.zsh_history)
Monitor logs for actions that could be taken to gather information about cloud accounts, including the use of calls to cloud APIs that perform account discovery.
System and network discovery techniques normally occur throughout an operation as an adversary learns the environment, and also to an extent in normal network operations. Therefore discovery data and events should not be viewed in isolation, but as part of a chain of behavior that could lead to other activities, such as Lateral Movement, based on the information obtained.
AADInternals can enumerate information about a variety of cloud services, such as Office 365 and Sharepoint instances or OpenID Configurations.
An adversary may attempt to enumerate the cloud services running on a system after gaining access. These methods can differ from platform-as-a-service (PaaS), to infrastructure-as-a-service (IaaS), or software-as-a-service (SaaS). Many services exist throughout the various cloud providers and can include Continuous Integration and Continuous Delivery (CI/CD), Lambda Functions, Azure AD, etc.
Adversaries may attempt to discover information about the services enabled throughout the environment. Azure tools and APIs, such as the Azure AD Graph API and Azure Resource Manager API, can enumerate resources and services, including applications, management groups, resources and policy definitions, and their relationships that are accessible by an identity.
Stormspotter is an open source tool for enumerating and constructing a graph for Azure resources and services, and Pacu is an open source AWS exploitation framework that supports several methods for discovering cloud services.
This type of attack technique cannot be easily mitigated with preventive controls since it is based on the abuse of system features.
Monitoring the following activities in your Organization can help you detect this technique.
Cloud Service: Cloud Service Enumeration
An extracted list of cloud services (ex: AWS ECS ListServices)
Cloud service discovery techniques will likely occur throughout an operation where an adversary is targeting cloud-based systems and services. Data and events should not be viewed in isolation, but as part of a chain of behavior that could lead to other activities based on the information obtained.Normal, benign system and network events that look like cloud service discovery may be uncommon, depending on the environment and how they are used. Monitor cloud service usage for anomalous behavior that may indicate adversarial presence within the environment.
Copyright © 2022 AshwinPro