How to Control and Detect Users Logging Onto Unauthorized Computers

Windows gives you a number of options for limiting which computers a specific account can be used to log onto. Using these features is a crucial part of protecting yourself from persistent attacks. You can: By restricting accounts to suitable machines, you can:

• Enforce written regulations based on best practice
• Slow down or stop the lateral movement by attackers
• Protect against pass-the-hash and related credential harvesting attacks

For privileged accounts, this mitigation strategy should be applied first. And using the allow and deny logon permissions is the simplest technique to limit accounts to particular computers. Each of the five types of Windows logon sessions has a “allow” and “deny” right listed in Group Policy’s User Rights section:

• Local logon (i.e. interactive logon at the console)
• Network logon (e.g. accessing remote computer’s file system via shared folder)
• Remote Desktop (i.e. Terminal Services)
• Service (when a service is started in the background, its service account is logged on in this type of session)
• Batch (i.e. Scheduled Task)

Naturally, the deny right will take precedence if an account has both “Logon locally” and “Deny logon locally.” You can grant these privileges to the specific groups of machines and users by carefully structuring OUs, GPOs, and user groups.

However, it can be challenging to configure the rights properly due to group policy’s indirect structure and the numerous objects it involves. It’s simple to accidentally block proper logon instances or leave holes in your controls.

Microsoft introduced Authentication Policy Silos in Windows Server 2012 R2. Silos are enforced centrally by the domain controller, as opposed to logon rights, which are enforced at the member machine level. In essence, you make an Authentication Policy Silo container and put the desired computers and user accounts in it. Now, access to those user accounts is restricted to computers within that silo. When handling Kerberos authentication requests, domain controllers only impose silo constraints; NTLM is not supported. Silo’d accounts must also be members of the new Protected Users group to prevent users’ accounts from getting around silo restrictions by authenticating using NTLM. Pass-the-hash and related credential attacks are prevented by joining Protected Users, which also disables NTLM for member accounts among other safeguards.

For what it’s worth, Active Directory also has the option to impose login limitations for domain user accounts by using the Logon Workstations setting. This setting, however, solely affects interactive logons and provides no control over other types of logon sessions.

Detecting Logon Violation Attempts

Both kinds of logon restriction violations can be observed in progress. Below is what to expect in the security log when your logon attempt fails because you have not been granted or are explicitly denied a particular logon entitlement.

As you can see, because of logon right limits, there is no centralized audit log record of failed logon attempts. Each computer on the network needs to have its logs collected and watched over.

In contrast, these are the events that are logged if you try to cross an authentication silo boundary.

The centralized management and monitoring of authentication silos is without a doubt a benefit. You may keep track of all attempts to circumvent your logon rules across the whole network by simply watching your domain controllers for event ID 4820. In addition, event ID 4820 reports the name of the silo, making it simple to identify policies.

Limiting privileged accounts is a crucial security measure for reducing the likelihood of pass-the-hash attacks and thwarting contemporary attackers. Make sure you don’t just configure these crucial controls and then overlook monitoring them, whether you implement logon limitations using user rights on local systems or centrally with Authentication Silos. You need to be aware of any admin attempts to go around security measures or any attempts by an intruder to travel around your network using credentials they’ve stolen.

If you want to know more about controlling and detecting users, talk to us today or email us at demo@cyb3r-x.com for a demo.