PowerShell Jobs

by | Oct 7, 2021 | Detection, Incident Response, Monitoring, Windows

By Dray Agha

Jumpsec icons Detection 1

JUMPSEC investigators recently observed an adversary weaponising PowerShell Jobs to schedule their attack, whilst responding to an incident. In this article, we discuss what PowerShell jobs are, how they can be leveraged for malicious purposes, and how defenders can protect, detect, and respond to neutralise the threat. 

What are PowerShell Jobs

Adversaries are known to schedule parts of their campaign once they have infiltrated a target network. They may timetable their attack for an opportune moment (such as during unsociable hours, based on the region in which the infrastructure is hosted, or support teams reside) or set up a recurring task to ensure ongoing persistence

PowerShell jobs aren’t designed to be inherently malicious and have many legitimate use cases. However, as is often the case in cyber security, the innate functionality of PowerShell Jobs and its susceptibility to abuse means it can also be leveraged by an adversary. 

Using legitimately

When using the command line for most operating systems, users have to run a command and wait a microsecond for the system to return with a reply. This can be inconvenient – for example, when running a script that will take a while to run, or when you know that you want to run the command at a specific time or date in the future. 

When using PowerShell, a job allows you to push a task into the background. PowerShell will continue to work on your query behind the scenes and allow you to continue using the shell for other things. 

#Push command to the background
Start-Job -ScriptBlock {date}

#Retrieve the results of the backgrounded command
Receive-job -name X


According to schedule

PowerShell jobs can also be scheduled to execute on very particular conditions

#organise when the task should trigger
$trigger = New-JobTrigger -Daily -At "4:15 AM" -DaysInterval 3;

#register the PowerShell job
Register-ScheduledJob –Name Collect_date –ScriptBlock {date} –Trigger $trigger

image15 1

There are numerous ways to go and find where our scheduled job is located

#Either of these work just fine
Get-ScheduledJob -id x
Get-ScheduledTask -taskname x



We can also find out a scheduled job’s date, time, and frequency are due to be executed

Get-JobTrigger -name x


Malicious scheduled jobs

In the above example, we’re completing the rather boring scheduled job of collecting the date. A more interesting representative example of how PowerShell jobs can be leveraged by attackers was found during our response to a recent incident. 

Whilst this article won’t recreate the exact syntax the attacker used for obvious reasons, we’ve provided a functionally similar example below.

Using for evil

Let’s schedule a malicious PowerShell Job to run at 3 o’clock in the morning on Christmas Day – a gift to incident responders and sysadmins everywhere!

#schedule the job for Christmas
$trigger = New-JobTrigger -Once -At "12/25/2021 3:00 AM";

#point to the malicious script to execute
$file = C:\SuperEvil.ps1

#try to hide this job from the Task Scheduler GUI….will still show up in the command line and GUI (if the right options are selected in ‘View’)
$options = New-ScheduledJobOption –HideInTaskScheduler;

#and now schedule the job
Register-ScheduledJob –Name Christmas_Day -FilePath $file –Trigger $trigger –ScheduledJobOption $options


Now, we’ve emulated how an adversary could weaponise a PowerShell job to strike when the defenders are less likely to be able to manually react and respond. In these cases, automated measures to prevent and detect the threat are essential.

Hunting Malicious Jobs

Now, you know me, I’m not about to show you something malicious without showing you the defensive counterpart! Let’s put our Blue Team hat on


From a monitoring and detection point of view, if we combine Sysmon and Florian Roth’s config of rules, we can see how a PowerShell job would be flagged


  • The BLUE arrows: event info
    • The Event ID 11 involves file creation
  • The RED arrows: specific info
    • TargetFileName shows that the scheduled job has been written to the Task directory
    • Notice, however, we have no visibility to WHAT this task does….we just know it has been registered.
  • The PINK arrow: MITRE ATT&CK reference
    • This may not be in every sysmon config. However Florian Roth includes the MITRE ATT&CK tactic number in a particular event. This allows security analysts to schematise the event data they are observing with the wider TTPs of an adversary. 

In the above sysmon/endpoint log based SIEM, we would have some visibility of scheduled jobs. However this data won’t be enough for an analyst to work with. We need to dig deeper beyond passive monitoring to active threat hunting to identify exactly what this scheduled job is about. 



In our JUMPSEC clients’ environments, we have found no system-level usage of scheduled jobs. This suggests that scheduled jobs you identify are deliberately put there and are worth investigation.

You can query the scheduled jobs on a machine with this straight forward command



You can also examine when this scheduled job is due to be executed

Get-ScheduledJob | 
Get-JobTrigger |
Ft -Property @{Label="ScheduledJob";Expression={$_.JobDefinition.Name}},ID,Enabled, At, frequency, DaysOfWeek


Knowing that this premeditated attack will ruin Christmas for an incident responder, let’s neutralise the malicious PowerShell job that has been scheduled. 


You can remove a PowerShell scheduled job in two different ways, neither of which present a disadvantage. 

#option one
Unregister-ScheduledTask -TaskName Christmas_Day -verbose -Confirm:$false

#option two
Unregister-ScheduledJob Christmas_Day -verbose -Confirm:$false



We can confirm that the malicious tasks have been eradicated from this machine.


Scheduling Security

This article took inspiration from a real life attack, and examined how an adversary could abuse PowerShell scheduled Jobs to both gain persistence, and quietly dwell on a network before picking the opportune moment to strike. Scripted attacks must be proactively identified and eliminated, as automated attack chains can be speedily operated by an attacker, reducing the opportunity for defenders to respond. It’s important you are scouring your network for the recurring tasks that can give an attack a backdoor into your environment.  

Related articles: We recently wrote about how registry run keys can offer adversaries a stealthy persistence mechanism

Detect and investigate any recurring tasks you see in your environment, and you may just catch an adversarial campaign before they can cause any damage. Deny them the pleasure of striking on Christmas Day!

Any questions, comments, or criticisms please drop me a line

Twitter Github

Dray Agha, Security Researcher



The information provided on this website is to be used for educational purposes only. The author is in no way responsible for any misuse of the information provided. Any actions and or activities related to the material contained within this website is solely your responsibility.

You may also like…

Running Once, Running Twice, Pwned! Windows Registry Run Keys

The Windows registry is a vast and complex topic and cannot be understood and defended in one article. One particular area of interest from a security perspective is registry run keys. In this article, we discuss who uses them, how to uncover abuse, and how to eradicate evil from them.

Can Depix deobfuscate your data?

In this post, Caleb explores Depix and its potential to recover sensitive text from reports that were redacted by the original authors.

Share This