Many of the IT Professionals that contact our customer service and support group have common questions related to security incidents and are seeking guidance on how to mitigate threats from determined adversaries. Given the level of interest in this information and common scenarios that exist amongst different organizations, we are publishing a multi-part series which will detail common security incidents organizations face and provide recommended mitigations based on guidance from our Security Support team.
It is important to note that each phase has one or more technical and, more importantly, administrative controls that could have been used to block or slow down the attack. These mitigations are listed after each phase. Each mitigation addresses specific behaviors and attack vectors that have been seen previously in multiple security incidents.
Phase One: The Entry Point
Initially, the attacker is able to successfully compromise one or more machines. This may happen through phishing, targeted web attacks, exposed services, or other means.
The most common method observed by our Security Support team in successfully compromising a system is through software vulnerabilities. In the vast majority of cases, these are vulnerabilities in software for which updates are available but have not been applied. In troubleshooting with customers, we have found that these attacks typically target plug-ins, document readers for common formats and common web application frameworks.
MITIGATION: It is critical for IT Professionals to apply timely security updates for all software installed in their organization. This includes both Microsoft products as well as 3rd party software. Microsoft infrastructure such as System Center Configuration Manager (SCCM) & Windows Server Update Services (WSUS) can apply updates to Microsoft products but they do not cover 3rd party products, unless that 3rd party has released a manifest for their product. This should be the case whether the software was centrally deployed or installed by end users. This also includes any application frameworks used in web-based applications.
Software vulnerabilities is one of the most common entry point’s attackers use to cause malicious harm. This becomes even more critical when running a system in local administrator mode as attackers may try to install products that could introduce new vulnerabilities. Applying timely updates should be done for all products installed.
Phase Two: Gaining Administrator Control
After the initial compromise, the attacker will want to obtain LocalSystem privileges.
In our experience, gaining LocalSystem privileges is often times easy because the system which was compromised was setup as an administrator. The attacker will typically focus on the privileged account users so that they can gain control.
MITIGATION: Minimize the number of systems running as a local administrator for both workstations and servers. Use privileged accounts only when necessary.
Phase Three: Establishing Roots
Once the attacker is able to run as LocalSystem, they install malware to provide persistence on the host, capture user credentials, and remotely control the machine.
MITIGATION: Regularly monitor your anti-virus/anti-malware solution. Often times tools used in an attack were detected by anti-malware but not cleaned or addressed. In these scenarios the attacker can install other malicious software. Additionally, malware may disable security software or make configuration changes such as adding exceptions.
MITIGATION: Use an application control approach such as AppLocker to help prevent the introduction of unwanted software.
Phase Four: Credential Theft
Now that the third-party is able to run persistent malware, credentials become a prime target. Credentials are generally stolen from local accounts, service accounts, and users who logon to the infected host. The aim here is to find privileged credentials, including domain administrator accounts, to use.
MITIGATION: Use unique passwords for the local Administrator account on every host in your enterprise. When an attacker discovers that the local administrator account has the same password on every, or even on a group, of hosts, they will use this to move laterally across any host that shares the same password. It is better still to disable this account entirely across your enterprise and monitor for attempted usage of it. Refer to Mitigating Pass-the-Hash (PtH) Attacks and Other Credential Theft Techniques for details on this and other credentials-related mitigations.
MITIGATION: Prevent Domain Administrator accounts from logging onto machines that may be compromised by a less privileged user. Domain administrative accounts should never logon to member workstations or servers in the domain. They should use limited user accounts and use a Terminal Server gateway to RDP into the servers with their domain administrator accounts as required. The simplest approach to this is to use a group policy to remove the Logon Locally rights for domain administrators from all machines except for domain controllers.
MITIGATION: Many services run as LocalSystem. This is a highly privileged account. Where possible use LocalService and NetworkService accounts to run the services instead of domain admin accounts where the passwords are held in clear text in the LSA process memory space while the system is running.
More information on service accounts:
Services are applications that run when the system boots. Just like any other process on the system, services must run under some kind of user identity. When the service starts, the operating system will authenticate the account used for the service. To do this, it needs a username and password, which is stored in the Local Security Authority (LSA) Secrets. The LSA Secrets are maintained by the LSA to hold certain sensitive information, such as the computer account credentials, encryption keys, and service account credentials.
The LSA Secrets are encrypted on disk and decrypted by the OS when the machine boots. They are then held in clear text in the LSA process memory space while the system is running. To get at this information, the third party must hook a debugger to the LSA process. That may sound daunting, but there are utilities designed specifically for extracting secrets from LSA. Note that as the LSA is running as LocalSystem, not just anyone can attach a debugger to a process running; however, any user who has the SeDebugPrivilege (which is required to debug and adjust the memory of a process owned by another account) can do so. By default, this means only the Administrators are able; however, this privilege can also be granted to other users.
Phase Five: Data Theft
In this scenario, the attacker now has full access to privileged accounts and can act as those accounts – domain administrators, server administrators, VIPs – on the network to cause malicious harm. With this access, they may be able to obtain key intellectual property and other data. They may also connect to domain controllers and gather credentials for all users in the domain.
MITIGATION: None. It is critical that the attacker has already been contained and controlled by the mitigations that have been listed previously. Detective controls are important in this phase to detect malicious activity.
Discussion: Before an incident occurs, customers should identify their critical data and secure it using such controls as encryption, on disk and in transit, as well as pre-defining which business group should have access to which data. Because domain administrators can change access control lists (ACLs) on files and folders, this is not a mitigation, however the use of a system like Microsoft’s Rights Management Services can be used to control access to data. Business critical data should be located on secured storage and backed up to a secured system as well as offsite to recover from site-wide issues, and frequent testing of restores should be performed.
Of course these are just examples of the scenarios and security best practices we recommend to customers based on what we are seeing in the trenches at the moment. In terms of the life cycle of the attack, the attackers manage to compromise in the context of logged on administrators, then use pass-the-hash attacks to elevate their privileges to that of domain administrators. With these credentials, they can dump the NTDS.dit file and in doing so, have the hashes of every account in the AD. Then, they target the information they are looking for and exfiltrate that data using a number of different mechanisms.
Watch for the next installment in this series, covering some of the things that you can do to be prepared for a security incident. For more information on Pass-the-Hash and other credential theft approaches, refer to Mitigating Pass-the-Hash (PtH) Attacks and Other Credential Theft Techniques.
Neil Carpenter
Senior Security Escalation Engineer
CSS Security Team
Since mid-April 2024, Microsoft has observed an increase in defense evasion tactics used in campaigns abusing file hosting services like SharePoint, OneDrive, and Dropbox. These campaigns use sophisticated techniques to perform social engineering, evade detection, and compromise identities, and include business email compromise (BEC) attacks.
Microsoft has observed the threat actor tracked as Storm-0501 launching a multi-staged attack where they compromised hybrid cloud environments and performed lateral movement from on-premises to cloud environment, leading to data exfiltration, credential theft, tampering, persistent backdoor access, and ransomware deployment. The said attack targeted multiple sectors in the United States, including government, manufacturing, transportation, […]
Microsoft discovered a vulnerability pattern in multiple popular Android applications that could enable a malicious application to overwrite files in the vulnerable application’s internal data storage directory, which could lead to arbitrary code execution and token theft, among other impacts. We have shared our findings with Google’s Android Application Security Research team, as well as the developers of apps found vulnerable to this issue. We anticipate that the vulnerability pattern could be found in other applications. We’re sharing this research more broadly so developers and publishers can check their apps for similar issues, fix as appropriate, and prevent them from being introduced into new apps or releases.
Microsoft Threat Intelligence presents cases of threat actors misusing OAuth applications as automation tools in financially motivated attacks.
