05.10.2024
Top 5 Best Jobs for Your PMP Certification in 2024
Posted by Marbenz Antonio on November 3, 2022
Although the Mitigating Pass-the-Hash Attacks and Other Credential Theft whitepaper was released ten years ago, the techniques are still useful because they help stop attackers from gaining access to the network and using credential-dumping tools to extract password hashes, user credentials, or Kerberos tickets from local memory. With those resources at their disposal, an attacker may move laterally through the network to take the login details for other privileged accounts. All of this leads to their ultimate objective, which includes getting access to your private company data, the Active Directory (AD) database, key business apps, and more, with the assistance of Microsoft 365 Defender.
We’ll discuss the three primary lateral movement mitigations in this blog article and how Microsoft 365 Defender can support your team in making the most of each mitigation:
The tier model can be used to segment accounts with access to protected domains. The tier method analyzes your AD environment into 3 separate tiers with different rights and access, which helps to reduce credential theft. It was moving from a normal user workstation to an application server or domain controller is prevented by dividing the tiers. There won’t be a path for an attacker to migrate to more sensitive accounts and servers if the computer hosting a regular user account is compromised and password hashes are obtained by the attacker. The three tiers are listed in order from 0 to 2, with 0 being the most restricted:
The different tiers must be entirely separated from one another for the tier model to work as intended. To achieve this, Group Policy Objects (GPOs) that restrict signing in across tiers can be created. The tier boundaries cannot be crossed by any account. For instance, a Tier 0 administrator should not be permitted to access a Tier 1 or Tier 2 machine. The password for that account has to be reset if the credentials are revealed to a stronger tier.
The use of Privileged Access Workstations (PAW) reduces lateral movement too. Users with more than one account in the domain must use different computers since an account in one tier can only sign in to computers in that tier. Only Tier 0 assets should be accessed by a Tier 0 user without a PAW. However, the Tier 0 account owner shouldn’t access productivity software or check email on the same computer (a Tier 2 activity).
As said before, an attacker will be able to go laterally to obtain the credentials of the sensitive account if they can successfully harvest the credentials of any of the accounts in the path. The use of Microsoft Defender for Identity is one way to identify any lateral movement routes in your environment. Defender for Identity may help to prevent this and quickly identify any lateral movement paths for each sensitive account by integrating data from account sessions, local admins on machines, and group memberships. The attacker will be able to move laterally and obtain the credentials for the sensitive account if they can successfully harvest the credentials of any of the accounts on the path.
Defender for Identity provides functionality to add more accounts and groups to the classification if needed, but by default, it classifies a few groups and the people who make up those groups as sensitive. By removing local administrators, restricting access, or splitting accounts, the goal is to prevent possible attack vectors (see Figure 2).
Local admins are a prime target for attackers because they have access to a lot of credential harvesting and lateral movement opportunities. Even worse, local admin administration and monitoring are occasionally overlooked. During the operating system deployment, the local administrator password is usually created once for all computers in the organization, including those used by administrators. An attacker can compromise a local account password on one system and instantly get administrator-level access to all client machines on the network if local admin passwords are not randomly generated across client machines.
However, the useful method Microsoft Local Admin Password Solution (LAPS) completely automates password management for local accounts. After installation, LAPS will create a random password for the local admin account and add it to a confidential attribute of the matching computer account in AD. Your team can define which people will be able to get passwords from AD and which PCs will be managed during the deployment process, such as the helpdesk staff.
LAPS configuration tracking is provided in Vulnerability management > Security recommendations in Microsoft Defender for Endpoint.
Run the following search in Advanced Hunting to get a detailed report on your devices:
DeviceTvmSecureConfigurationAssessment | where ConfigurationId == "scid-84" | where OSPlatform == "Windows10" | where IsCompliant == 0 | project DeviceName, OSPlatform
Microsoft Defender for Cloud Apps with Defender for Identity integration contains a similar report. It also keeps track of LAPS deployment from an AD perspective by showing computer objects whose LAPS passwords haven’t been changed in the previous 60 days. Even if the material in both publications is similar, it comes from different sources. To cross-check the status of the LAPS deployment, the two reports can be used.
Customers of Defender for Endpoint can observe all monitored activities and the setup helps improve unusual activity from the local administrator account. For example, the following query identifies network usage of local admin:
DeviceLogonEvents | where AccountSid endswith '-500' and parse_json(AdditionalFields).IsLocalLogon != true | join kind=leftanti IdentityLogonEvents on AccountSid // Remove the domain's built-in admin account
By adding the Local account and member of the Administrators group (S-1-5-114) entity to the Deny access to this computer from the network GPO setting, your team can additionally prevent access from local admin accounts across the network. Since LAPS can only cover one account per device, this will limit an attacker’s lateral movement and protect any other local admin accounts that could be present on the system.
Our experience has demonstrated that this final mitigation is usually disregarded. This mitigation provides a simple and effective method to make lateral movement for an attacker more challenging by simply blocking the ability to connect from one computer to another.
Although host-based firewalls have a poor reputation for being challenging to manage, using Windows Defender Firewall to block inbound traffic on Windows PCs is not a difficult task. Most of the client-server applications don’t anticipate any inbound connections from the servers and start all network communication on the client side. However, Windows Defender Firewall must be configured to block all inbound connections for this mitigation to be effective (unless specifically allowed by one of the rules). It is important to disable local firewall rule merging because doing anything else will make this mitigation inactive. Please refer to the Microsoft Intune documentation or the Pass-the-Hash Mitigations whitepaper1 for more information on installing the Windows Defender Firewall.
It’s important to identify any applications that have been overlooked or did not get exceptions to allow inbound connections after the initial configuration is complete. Defender for Endpoint might be of help in this regard by significantly improving firewall monitoring and reporting capabilities. Your team can quickly begin analyzing the firewall logs for any misconfigurations once Windows Defender Firewall has been set to prevent inbound connections on a test set of devices.
A firewall report with all the necessary details is already included in the Reports area of the Microsoft 365 Defender portal. There is an Advanced hunting button in each report area that displays the important query and allows you to go deeper into the data.
The most important report, in this case, is Remote IPs targeting multiple computers. It is simple to change the existing query to just include test devices:
DeviceEvents
| where DeviceName in ("testdevice1.contoso.com", "testdevice2.contoso.com")
| where ActionType == "FirewallInboundConnectionBlocked"
| summarize ConnectionsBlocked = count() by RemoteIP
| sort by ConnectionsBlocked
The firewall configuration can be changed to include the IP addresses returned by the query as exceptions after they have been verified to be valid applications needing inbound access to client computers (such as peer-to-peer applications or any remote management software).
Here at CourseMonster, we know how hard it may be to find the right time and funds for training. We provide effective training programs that enable you to select the training option that best meets the demands of your company.
For more information, please get in touch with one of our course advisers today or contact us at training@coursemonster.com
