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.\u00a0 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.<\/p>\n
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.\u00a0 Each mitigation addresses specific behaviors and attack vectors that have been seen previously in multiple security incidents.<\/p>\n
Phase One: The Entry Point<\/strong><\/span> The most common method observed by our Security Support team in successfully compromising a system is through software vulnerabilities.\u00a0\u00a0 In the vast majority of cases, these are vulnerabilities in software for which updates are available but have not been applied.\u00a0 In troubleshooting with customers, we have found that these attacks typically target plug-ins, document readers for common formats and common web application frameworks.<\/p>\n MITIGATION<\/strong>:\u00a0 It is critical for IT Professionals to apply timely security updates for all software installed in their organization.\u00a0 This includes both Microsoft products as well as 3rd party software.\u00a0 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.\u00a0 This should be the case whether the software was centrally deployed or installed by end users.\u00a0 This also includes any application frameworks used in web-based applications.<\/p>\n Software vulnerabilities is one of the most common entry point\u2019s attackers use to cause malicious harm.\u00a0 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.\u00a0 Applying timely updates should be done for all products installed.<\/p>\n Phase Two: Gaining Administrator Control<\/strong><\/span> In our experience, gaining LocalSystem privileges is often times easy because the system which was compromised was setup as an administrator.\u00a0 The attacker will typically focus on the privileged account users so that they can gain control.<\/p>\n MITIGATION:\u00a0<\/strong> Minimize the number of systems running as a local administrator for both workstations and servers.\u00a0 Use privileged accounts only when necessary.<\/span><\/p>\n Phase Three: Establishing Roots<\/strong><\/p>\n 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.<\/p>\n MITIGATION:<\/strong>\u00a0 Regularly monitor your anti-virus\/anti-malware solution.\u00a0 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.\u00a0 Additionally, malware may disable security software or make configuration changes such as adding exceptions.<\/span><\/p>\n MITIGATION:\u00a0<\/strong> Use an application control approach such as AppLocker to help prevent the introduction of unwanted software.<\/span><\/p>\n Phase Four: Credential Theft<\/strong><\/span> MITIGATION:\u00a0<\/strong> Use unique passwords for the local Administrator account on every host in your enterprise.\u00a0 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.\u00a0 It is better still to disable this account entirely across your enterprise and monitor for attempted usage of it.\u00a0 Refer to Mitigating Pass-the-Hash (PtH) Attacks and Other Credential Theft Techniques<\/a> for details on this and other credentials-related mitigations.<\/span><\/p>\n MITIGATION:<\/strong>\u00a0 Prevent Domain Administrator accounts from logging onto machines that may be compromised by a less privileged user.\u00a0 Domain administrative accounts should never logon to member workstations or servers in the domain.\u00a0 They should use limited user accounts and use a Terminal Server gateway to RDP into the servers with their domain administrator accounts as required.\u00a0 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.<\/span><\/p>\n MITIGATION:\u00a0<\/strong> Many services run as LocalSystem.\u00a0 This is a highly privileged account.\u00a0 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.<\/span><\/p>\n More information on service accounts: <\/em><\/p>\n 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.<\/em><\/p>\n 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<\/a>) can do so. By default, this means only the Administrators are able; however, this privilege can also be granted to other users.<\/em><\/p>\n Phase Five: Data Theft<\/strong><\/span> MITIGATION:<\/strong> None.\u00a0 It is critical that the attacker has already been contained and controlled by the mitigations that have been listed previously.\u00a0 Detective controls are important in this phase to detect malicious activity.\u00a0<\/span><\/p>\n Discussion:<\/strong> 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.\u00a0 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\u2019s Rights Management Services<\/a> can be used to control access to data.\u00a0 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.<\/span><\/p>\n 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.\u00a0 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.\u00a0 With these credentials, they can dump the NTDS.dit file and in doing so, have the hashes of every account in the AD.\u00a0 Then, they target the information they are looking for and exfiltrate that data using a number of different mechanisms.<\/p>\n Watch for the next installment in this series, covering some of the things that you can do to be prepared for a security incident.\u00a0 For more information on Pass-the-Hash and other credential theft approaches, refer to Mitigating Pass-the-Hash (PtH) Attacks and Other Credential Theft<\/a> Techniques.<\/p>\n Neil Carpenter
\nInitially, the attacker is able to successfully compromise one or more machines.\u00a0 This may happen through phishing, targeted web attacks, exposed services, or other means.<\/p>\n
\nAfter the initial compromise, the attacker will want to obtain LocalSystem privileges.<\/p>\n
\nNow that the third-party is able to run persistent malware, credentials become a prime target.\u00a0 Credentials are generally stolen from local accounts, service accounts, and users who logon to the infected host.\u00a0 The aim here is to find privileged credentials, including domain administrator accounts, to use.<\/p>\n
\nIn this scenario, the attacker now has full access to privileged accounts and can act as those accounts \u2013 domain administrators, server administrators, VIPs \u2013 on the network to cause malicious harm.\u00a0 With this access, they may be able to obtain key intellectual property and other data.\u00a0 They may also connect to domain controllers and gather credentials for all users in the domain.<\/p>\n
\nSenior Security Escalation Engineer
\nCSS Security Team<\/p>\n