Security, et al

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

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

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

Notes

Local computer being attempted for
logon

4625

Logon Failure

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

Status: 0xC000015B

Domain Controller

4768

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

Notes

Local computer being attempted for
logon

4625

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"