Security, et al

Randy's Blog on Infosec and Other Stuff

«  How to Audit Privileged O... | Severing the Horizontal K... »

How to control and detect users logging onto unauthorized computers

Fri, 11 Nov 2016 11:08:40 GMT

indows gives you several ways to control which computers a given account can logon to. Leveraging these features is a critical way to defend against persistent attackers. By limiting accounts to appropriate computers you can

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

The first place to start using mitigation technique is with privileged accounts. And the easiest way to restrict accounts to specified computers is with the allow and deny logon rights. In Group Policy under User Rights you will find an allow and deny right for each of Windows’ 5 types of logon sessions

  • 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 it’s service account is logged on in this type of session)
  • Batch (i.e. Scheduled Task)

Of course if an account has both “Logon locally” and “Deny logon locally” the deny right will take precedence. By careful architecture of OUs, group policy objects and user groups you can assign these rights to the desired combinations of computers and users.

But because of the indirect nature of group policy and the many objects involved it can be complicated to configure the rights correctly. It’s easy to leave gaps in your controls or inadvertently prevent appropriate logon scenarios.

In Windows Server 2012 R2 Microsoft introduced Authentication Policy Silos. Whereas logon rights are enforced at the member computer level, silos are enforced centrally by the domain controller. Basically you create an Authentication Policy Silo container and assign the desired user accounts and computers to that silo. Now those user accounts can only be used for logging on to computers in that silo. Domain controllers only enforce silo restrictions when processing Kerberos authentication requests – not NTLM. To prevent users accounts from bypassing silo restrictions by authenticating via NTLM silo’d accounts must also be members of the new Protected Users group. Membership in Protected Users triggers a number of different controls designed to prevent pass-the-hash and related credential attacks – including disabling NTLM for member accounts.

For what it’s worth Active Directory has one other way to configure logon restrictions and that’s with the Logon Workstations setting on domain user accounts. However, this setting only applies to interactive logons and offers no control over the other logon session types.

Detecting Logon Violation Attempts

You can monitor failed attempts to violate both types of logon restrictions. When you attempt to logon but fail because you have not been granted or are explicitly denied a given logon right here’s what to expect in the security log.

Which Security Log

Event ID


Local computer being attempted for logon


Logon Failure

Failure reason: The user has not been granted the requested logon type at this machine.

Status: 0xC000015B

Domain Controller


Successful Kerberos TGT Request

Note that this is a successful event.  To the domain controller this was as a successful authentication. 


As you can see there is no centralized audit log record of logon failures due to logon right restrictions. You must collector and monitor the logs of each computer on the network.

On the other hand, here are the event logged when you attempt to violate an authentication silo boundary.

Which Security Log

Event ID


Local computer being attempted for logon


Logon Failure

Failure reason: User not allowed to logon at this computer

Status: 0xC000006E

Domain Controller

4820 Failure

A Kerberos Ticket-granting-ticket (TGT) was denied because the device does not meet the access control restrictions. 

The silo is identified

4768 Failed Kerberos TGT Request

Result Code: 0xC

An obvious advantage of Authentication Silos is the central control and monitoring. Just monitor your domain controllers for event ID 4820 and you’ll know about all attempts to bypass your logon controls across the entire network. Additionally, event ID 4820 reports the name of the silo which makes policy identification instant.

Restricting privileged accounts is a key control in mitigating the risk of pass-the-hash and fighting modern attackers. Whether you enforce logon restrictions with user rights on local systems or centrally with Authentication Silos make sure you don’t just use a “fire and forget” approach in which you configure but neglect monitoring these valuable controls. You need to know when an admin is attempting to circumvent controls or when an attacker is attempting to move laterally across your network using harvested credentials.

"This article by Randy Smith was originally published by EventTracker"

email this digg reddit dzone
comments (0)references (0)

5 Indicators of Endpoint Evil
Auditing Privileged Operations and Mailbox Access in Office 365 Exchange Online
Live with Dell at RSA 2015
Severing the Horizontal Kill Chain: The Role of Micro-Segmentation in Your Virtualization Infrastructure

Comments disabled

powered by Bloget™


Recent Blogs


Upcoming Webinars
    Additional Resources