Scheduled tasks are still quite a handy way to get automation completed when referring to running scripts and automatically emailing people because it means you don’t have to manually do them, however, the dark side of scheduled tasks is that if they’re left unchecked, they can spread malware and ransom, and do other nasty malicious things.
Scheduled tasks allow you to run powershell commands, or for that matter many different commands with the user that does not need to be logged in to run that command(s)
Scheduled Tasks : Service Accounts
The modern workplace has what’s known as service accounts that are usually accounts that do these exact operations, but the password doesn’t expire for obvious reasons because you need to update all the tasks, The downside to that is if these passwords are not rotated when an employee leaves the company the scheduled task will continue to run until it’s disabled or the password is changed.
Anyway, I digress from the point……
Scheduled Task - Server Core - No GUI
If you wish to deploy a scheduled task with the domain controller, I always recommend running the main controllers as server core, Which means you don’t get a GUI - You reduce 70% of the tech vectors and the whole point is you remotely manage those servers.
Remote PowerShell : Remote Code Execution Alerts
If you wish to deploy schedule task to the servers because you will need to do that from a server with a GUI a couple of ways you can do that both both of those request will be remotely sending code to the domain controller, which will most likely be picked up by your SIEM as a remote code execution.
While technically the SIEM Is 100% accurate and this could be seen as a malicious attack, in this particular instance, it’s not and it’s an authorized action to install a legitimate scheduled task on a domain controller, however, monitoring is not aware of this it just sees the event and logs in alert, the problem is down to what gets done with that alert 🚨 (I really can’t go into that anymore on a public forum)
So what can you do about this?
Well, interestingly, if you’re going to run it from a remote server and install it on a domain controller Then not a lot, all Domain controllers are your code red asset, for one simple reason, they are the reason you can login to start your work every morning so without them, you’re pretty much dead in the water for anything that requires authentication which is these days absolutely everything.
The question - should technically be what can you do to help your security team, as any alerts on a domain controller should be investigated with upmost priority and a proper and thorough root cause investigation needs to take place, so my view is, there’s no point generating an alert in the category of “ Remote code execution” for a code red asset - when there are other ways of completing this task that why they still might fire your SIEM Alerting it won’t be for a potentially knee jerking category.
Back up XML for scheduled task
Firstly, do you need to back up the XML for the scheduled task you’d like to run on the domain controller, obviously, remember, you will be using a service account for this task and the file path will need to be the same on the domain controller.
I would make sure your path is exactly the same on your administration server as it will be on the domain controller for the schedule task once imported.
Then we need to start Powershell, which need to be as an administrator then you need this command:
Export-ScheduledTask -TaskName "<task name>" -TaskPath "<path the task in scheduler>" | out-file C:\Tasks\<task-name>.xml
This as an example would be, this is a random task, not the details for what you require:
Export-ScheduledTask -TaskName "ResolutionHost" -TaskPath "\Microsoft\Windows\WDI\" | out-file C:\temp\ResolutionHost.xml
When you run this command, you will get an XML file in the folder specified in the export section.
Copy XML to Domain Controller
Obviously, you will need to have access access to the domain controller to do this, and I would recommend copying this to a folder like c:\temp - for this particular action, you can easily use SMB (which absolutely should be available on a domain controller because that’s how Group policy processing is managed under the SYSVOL share)
❌ Dumping in NETLOGON
While you might think using the NETLOGON share, I would again highly NOT recommend against this because from my point of view that is another code red asset because lots of malicious software will use that share to spread scripts and other malicious software around your domain,
NOTE : Far too many times I’ve seen this share used to replicate files that have nothing to do with the login process among all your domain controllers, unfortunately, this is not the correct usage for this share, when people do this, this is not least administrative effort, this is called no effort at all.
Restore XML file for Scheduled Tasks
Then we need to start Powershell, which need to be as an administrator then you need this command:
Note : The syntax similar to the export command, but you need the user and password variable and its Register-ScheduledTask
Register-ScheduledTask -xml (Get-Content 'c:\temp\ResolutionHost.xml' | Out-String) -TaskName "Magical Bears" -TaskPath "\Exch\" -User bear.local\ScheduledTaskManager -Password <password>
That will import the task as disabled a you can see below:
Now you need to enable it with this command:
Enable-ScheduledTask -TaskPath "\Exch\" -TaskName "Magical Bears"
This will then enable it as you can see below:
If you need to disable it you can use this command:
Disable-ScheduledTask -TaskPath "\Exch\" -TaskName "Magical Bears"