Microsoft Office Security Account Protection
Protecting user accounts on a corporate network based on the MS Windows domain is a typical and simple task. Everything has already been implemented and regulated (for example, in MS TechNet Password Best practices or in 17/21 orders of the FSTEC ):- Using a 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 the “service” technology accounts?
Such records exist in any corporate network and are used, for example, for:
- the functioning of programs and services on servers;
- communication programs with the DBMS (for domain authorization in the DBMS);
- Create service mailboxes in Exchange.
We also refer to this list the administrator accounts, if they are used for the above tasks.
We will talk about security features of official accounts later.
Why is it necessary to “protect” service accounts “in a special way”?
Because it is impossible to apply the same security policies to them as to ordinary user records, namely:
- Temporary blocking of the user in case of incorrect password entry.
You cannot block the service record, otherwise the service in which this record is involved will cease to function for all network users. Such blocking may occur due to employee error, deliberate sabotage, or virus activity associated with brute force passwords (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 ask for 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 busting and over the years with an unchangeable password. And if we consider that during the operation of the service more than one engineer could attach to its service, we consider the password to be known to a wide circle of people.
Security for service accounts is lower than for user accounts, and using them you can do anything on the network, especially since they are often endowed with extended privileges.
The following are tricks to minimize the risk of unauthorized use of business accounts. All of them have been tested and implemented in the corporate network.
Auto Unlock & Alert
Disabling account lockout policies if you enter an incorrect password is fraught with a complete lack of password protection.
You can apply the following solution:
- extend the account lockout policy to everyone, including service accounts;
- in case of blocking the service account, immediately unlock it and notify the security administrator about the fact of blocking, indicating the computer on which the password was entered incorrectly.
As a result, although we do not stop attempts to guess the password, we notify the administrator, giving him the opportunity to quickly respond to the incident.
Implementation:
On the domain controller in the event scheduler, we configure the task that is triggered by the lock event of a specific service account:
Event Properties -> Tab: Triggers -> Create -> Set Date: On event -> Parameters: Custom -> Create event filter ... -> Tab: XML ->
Where:
[USERNAME] - name of the account being controlled;
[DOMAIN NAME] is the domain name.
Next, we configure the action for this event - launching a script that takes the account name as arguments, removes the lock from it, and sends an email notification.
In our case, this is a powershell script, launching 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 that is 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);
- each blocked account was searched in the domain group “service accounts” (for example);
- in case the account is in the group, it was unlocked and the administrator was notified.
Block full work
Most service accounts are used to run specific services or to run on servers. So, for them, you can turn off all the extra features. For example, prohibit the ability to log on locally to computers on a network.
Microsoft suggests doing 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:
- we create the domain group “service accounts” and add to it all the accounts that do not need to log on locally to the computers on the network;
- we create a domain group policy that applies to the created group and includes the only rule - start at the entrance to the system% SystemRoot% \ System32 \ logoff.exe.
As a result, even if the password for the account is compromised, logging on to network computers with it will be problematic.
Suspicious Activity Monitoring
If the account was created to work with the database or authorize the application, then it has nothing to do on the file servers or domain controller. Of course, with correctly configured access rights, it will not get 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 systems.
It will be superfluous to describe monitoring options using specific protection systems as an example, given that each network has its own, I’ll only list events that it makes sense to “catch”:
- authorization on computers and servers (including failed authorization attempts);
- calling on file servers, creating and changing files on them;
- access to the domain controller;
- Launching applications unnecessary for this account.
To summarize
Compromise and subsequent unauthorized use of service accounts are a serious threat to any corporate network and more attention should be paid to their protection and control when building a protection system. Using generic policies for service accounts is not appropriate. You need to understand what functionality can be blocked, and what needs to be put in control.