Enhancing the Caldera Scheduling Component
If you saw my last blog, you’ll know that I am in the process of developing an automated TTP testing environment at Code42. Caldera, the management center of our testing infrastructure, has proven to be an invaluable tool. It provides several features including various C2 agent options, a REST API, and several plugins — one of them being a plugin that automatically imports Atomic Tests from the Atomic Library!
Caldera also offers a scheduling component for your operations that allows you to schedule your operations to run at a specific time every day. This is a neat option, however, it would be even better if it granted the ability to create custom operation schedules — allowing the user to schedule out several different one-time operations weeks or even months in advance. This feature would not only give the user more fine-grained control over their operations but would also allow them to create a custom TTP testing schedule that executes automatically!
Luckily we can expand upon the scheduling component since Caldera is FOSS!
Browsing through the Caldera GitHub repo, we see a file called c_schedule.py. Let’s check it out. This file contains the Schedule constructor — let’s see where the Schedule object is instantiated in the codebase.
We can see that Schedule is instantiated here in the create_schedule function. In this function, we can also see that the data parameter contains the time information. Let’s trace back even further and see where create_schedule is called from.
We see that create_schedule is called from the REST API which can be hit with an HTTP PUT request. Let’s take a look at the frontend Javascript to ensure we are calling this PUT request when we schedule an operation from the web UI.
Awesome — at this point we know exactly how a Schedule is created by the user. There are now two more steps to take before making a code change.
- Determine how the tasking in Caldera functions to ensure that it can handle tasking with a DateTime as opposed to just a Time. If it can’t handle this by default we can implement functionality so that it does.
- Determine how the Schedule data (i.e. time) is persisted to disk by Caldera. We will likely need to edit this functionality to ensure that Caldera will store and retrieve a DateTime as opposed to just a Time.
Stay tuned for my next blog post where I will walk through the final two steps, implement the code changes, and give a demo of the new functionality! Until then, check out more blogs at https://redblue42.code42.com/.