Protection of Microsoft service accounts

Protection of user accounts in the corporate network based on the MS Windows domain is a typical and simple task. Everything is already implemented and regulated (for example, in MS TechNet Password Best practices or in 17/21 orders of the FSTEC ):

• The use of complex and long password;
• Temporary blocking of the user in case of incorrect password entry;
• Periodic mandatory password change by the user.

But what to do with "service" technology accounts?
Such records are in any corporate network and are used, for example, for:

• the operation of programs and services on servers;
• communication programs with the DBMS (with domain authorization in the DBMS);
• create service mailboxes in Exchange.

We also assign to this list administrator accounts, if they are used for the above tasks.
We will continue to talk about the features of the protection of service accounts.

Why do you need to "special" to protect service accounts?

Because it is impossible to apply the same security policies to them as to ordinary user entries, namely:

• Temporary blocking of the user in case of incorrect password entry.
  It is impossible to block the service record, otherwise the service, in which this record is involved, will cease to function for all users of the network. Such blocking can occur due to an employee error, targeted sabotage, or brute-force password activity (for example, Net-Worm.Win32.Kido).
  
• Periodic mandatory password change by the user.
  You cannot set a periodic mandatory password change for a service account, otherwise the system will request a password change and block the record, and the service using it will, again, stop functioning.

It turns out that the network has a lot of service accounts that are not protected from brute force and over the years non-removable password. And if we consider that during the operation of the service, not one engineer could attach to his service, we consider the password known to a wide circle of people.
Protection for service accounts is lower than that of user accounts, and using them you can do anything on the network, especially since they are often endowed with extended privileges.
The following are techniques to minimize the risk of unauthorized use of service accounts. All of them have been tested and implemented in the corporate network.

Auto unlock and alert

Disabling account lockout policies in case of entering the wrong password is fraught with a complete lack of protection against password guessing.
You can apply the following solution:

• The policy of blocking accounts to extend to all, including service accounts;
• in case of blocking a service account, to unblock it immediately and notify the security administrator of the fact of blocking, indicating the computer on which the password was entered incorrectly.

As a result, although we do not stop trying to find a password, we notify the administrator, giving him the opportunity to quickly respond to the incident.
')
Implementation:
On the domain controller in the event scheduler, configure the task triggered by the lock event of a specific service account:
Event properties -> Tab: Triggers -> Create -> Assign date: At event -> Parameters: Custom -> Create event filter ... -> Tab: XML ->

<QueryList> <Query Id="0" Path="Security"> <Select Path="Security">*[System[(EventID=4740)]] and *[EventData[Data[@Name='TargetUserName'] and (Data='[USERNAME]')]] and *[EventData[Data[@Name='SubjectDomainName'] and (Data='[DOMAIN NAME]')]]</Select> </Query> </QueryList> 

Where:
[USERNAME] - the name of the controlled account;
[DOMAIN NAME] - domain name.

Next, set up an action for this event — launching a script that takes the name of an account as an argument, removes the lock from it, and sends an e-mail notification.
In our case, this is a powershell script, run with arguments:

 -ExecutionPolicy RemoteSigned -Command "& {C:\Scripts\Unlock.ps1 -user [USERNAME] }" 

The basis of the script are the commands:

 Import-Module ActiveDirectory //    Unlock-ADAccount $user //      Get-EventLog -LogName 'Security' -newest 10000 | Where-Object {$_.EventID -eq 4740 -and $_.ReplacementStrings[0] -eq "$user"} | Select-Object -first 1 //   ,        Net.Mail //  . 

This event in the task scheduler must be duplicated for each service account under control. If there are too many such records, then it makes sense to upgrade the solution to:

• the task in the scheduler was triggered when any account was blocked (event 4740 in the security log);
• searched for each blocked account in the domain group "service accounts" (for example);
• if the account is in a group, it is unlocked and notified to the administrator.

Lock full work

Most of the service accounts are used to run specific services or to work on servers. So, for them, you can disable all the extra features. For example, to prohibit the possibility of local access to computers on the network.
Microsoft proposes to do this with the appropriate policy located here: Security Settings \ Local Policies \ User Rights Assignment \ Local Login . But sometimes using this policy is difficult, then you can use the following method:

• create a domain group "service accounts" and add all accounts to it, which need not be able to log on to computers on the network;
• create a domain group policy that applies to the created group and includes the only rule - to start at the% SystemRoot% \ System32 \ logoff.exe login.

As a result, even if the account password is compromised, it will be problematic to log into the network computers with it.

Suspicious Activity Monitoring

If an account is created for working with a database or authorizing an application, then it has nothing to do on file servers or a domain controller. Of course, with properly configured access rights, it will not go there, but who will give a guarantee? Therefore, it is necessary to conduct various kinds of monitoring of suspicious activity on the part of official accounts. For these purposes you can use:

• task schedulers and scripts;
• various SIEM solutions;
• DLP system.

Describe the monitoring options on the example of specific protection systems in this article will be superfluous, given that they have their own in each network, I will cite only events that it makes sense to “catch”:

• authorization on computers and servers (including unsuccessful authorization attempts);
• calling on file servers, creating and changing files on them;
• calls to the domain controller;
• launching applications that are not needed by this account.

Summing up

Compromising and subsequent unauthorized use of service accounts are a serious threat to any corporate network and when building a protection system, greater attention should be paid to their protection and control. Using generic policies for service accounts is not suitable. It is necessary to understand what functionality can be blocked, and what needs to be put under control.