Something that crops up time an time again is the usage of Privileged accounts to run applications on a server as part of a scheduled run, or cronjob.

TL;DR

DON’T use high Privilege, apply Principles of Least Privilege, Local Accounts, Manage them.

Using a highly privileged account to run your tasks is convenient, don’t get me wrong, I get it. You probably find that at a base level you are asking yourself these questions:

• What do I need to run this application successfully on my machine?
• Are security policies blocking the caching of credential (That need’s it’s own post!)?
• Am I working around those policies/ Do I need to?

The easiest answer to these questions is to use High privilege! … But the impact of doing so, when a TA is able to gain access to your systems is phenomenal.

An Example

If you are trying to get a scheduled task to run on a Windows server, you may use a credential stored in Active Directory. This credential will have entitlements and privileges to do “Stuff”. However as a mitigating factor, Security teams may apply polices that stop you from using (or caching) the credential from AD. It does this by blocking the ability to store the credential OR by denying a task to be run “over the network”.

A scheduled task could then be run with a local privileged account, in this example “SYSTEM”.

So what’s wrong with this? Well, it probably is easier to define what is right with this … Nothing, nothing is right with this is the answer.

Using system means that the application is running at the highest level of integrity and is able to access system resources that even an Admin account would be, by default, blocked from accessing immediately.

Lets say that the application executes “notepad.exe”, using this I could breakout from the session running notepad and spawn new child processes, like PowerShell, Command Prompt, “MyMal.exe”. With this foothold most defence mechanisms can now be shutdown or bypassed.

There are plenty of resources online that you could reference regarding this, but here are a few to take note of:-

• https://lolbas-project.github.io/
• https://gtfobins.github.io/
• https://www.loldrivers.io/

These resources explain how particular applications are exploited and abused, and each has a reference linked to the MITRE ATT&CK Framework. https://attack.mitre.org/

Here is an error that may drive you to perform the action referenced above :- https://techcommunity.microsoft.com/t5/ask-the-performance-team/task-scheduler-error-8220-a-specified-logon-session-does-not/ba-p/375056

What do you do?

POLP (not Plop). Principle of Least Privilege is one key element to securing the run of these applications. Create an account and give it the exact privileges it needs to perform the task in hand. Have an account specifically created to run that one thing, and have another account to manage a.n.other thing. If the application does not need to access any folders or directories than the one it needs to run it’s task, specify it. If it needs 2 folders or directories, Specify it… you see where that is going. Equally define the applications the account is allowed to execute.

Ok, I hear you say, “But, I have loads of tasks, that means loads of passwords”, and you are right. So you now need to think about how you perform PAM (Privileged Account Management). You will find that you can onboard these accounts to a PAM tool and have the tool rotate the credentials on a frequent basis. You are also then able to audit if a user is now retrieving that account secret from the PAM Vault. (Yea, PAM needs a few posts to cover the topics that are relevant to this topic).

The benefit of this is that logging can now be sent to a SIEM (Security Information and Events Management) where logic can be applied. Such as, “Did the account get checked out by a human, as I can see weird things happening”; IF Yes, Ask the end user what they are doing, IF No, Investigate!

When you have tools that can manage accounts like PAM, Local accounts are a great way to reduce the attack surface and potential impact of a compromise of the server running the task. Generally speaking, using an account that is homed in a directory where kerberos or MS-KILE has been implemented, does offer a higher level of security on the authentication method, but ill configuration can very quickly allow TA’s to move from system to system.

It is not easy work, as there are factors to consider, but the main one is, “Can I still provide Business as usual”. And in a broad manner, yes you can. In a business sponsorship for this type of security is required. The unfortunate thoughts of, “It’s not broke, don’t fix it” are toxic to System security, which inevitably is toxic to business and their customers.

Rarely do we get to work greenfield when implementing security, which is a real shame as most controls can be implemented with ease when security is at the fore front of decision making for technology. (But yet again, that’s another topic).

Right now, if you have highly privileged accounts running applications and tasks, go fix them. A Hexagonal wheel is fine, but a round wheel is great.