Add the ability to cancel / delete a task before it has been picked up by an agent

[sclow]

This pull request adds an option to the modal dialogue for a task that is either in status "submitted" or "delegating tasks" that can be used to delete the task so long as it has not already been picked up by an agent.

This is only possible if users have access to the "delete_task_by_pk" mutation within GraphQL.

Therefore permissions to grant the ability to delete from the task table within Hasura have been granted to the following user groups:

• mythic_admin
• operation_admin
• operator

Those permission changes can be seen from ~ line 6408 within ${mythic_root}/hasura-docker/metadata/tables.yaml.

Basic testing has not identified an issue generating a report of issued (and executed) tasks; nor does there appear to be an issue with MITRE mappings within the operation view.

The rationale behind this addition is simple; an operator quality of life enhancement especially when using BOF's.
If an operator mistypes the parameters to a BOF there is a high probability of agent death and / or detection if the agent does not die gracefully.

Having the ability to remove a task prior to an agent calling back in is very handy especially if extended sleep times are in use. From an auditing perspective, there seems little to lose removing those tasks from the generated logs if the commands never get delivered to an agent.

[its-a-feature]

Is there a reason you don't use the built-in clear command?

[sclow]

Short answer... never spotted it before.

Longer answer: running "help" with no parameters gave agent commands; not the builtin "free ones".

Time for me to re-read the documents :)

I will take another look at the "clear" implementation; having it available with the comment / copy / etc dialogues may make it easier to find.

[its-a-feature]

No worries! I can definitely make sure it shows up in the help commands. You can also always hit tab and cycle through available commands and available parameters.

I love that you took the time to make a UI feature for this though! You're the first one :) I'll check it out and see what we can do with it. In general, I'm always hesitant about the actual "deletion" of data within Mythic (which is why I purposefully hide it away in scripting). I don't like the idea of somebody running commands on a remote system, then "cleaning up" by deleting evidence that they did anything from other operators or deconfliction.

If you notice, most objects in the database have a "deleted" flag so that if you delete something, all that really happens is I just hide it from your view, but it's still there and available via scripting.

[sclow]

I would be very happy if we can link the UI to the clear command; i.e. have it clear the specific task when an operator is tasked loaded (e.g. ran command and desperately wants to un-run command before agent picks it up :) ).

I would still argue for it to be a UI component from a quality of life perspective though.
I have no issues with tasks being marked as cleared; especially if I still have agents to play with!

[sclow]

Hi Cody (@its-a-feature ),

I hope you don't mind, but I have had another stab at task cancellation within the UI.

Following your feedback, it now creates a new task for the command "clear", parameters "task.display_id" and maps to the same parent_process_id as the task to be cancelled. Therefore it should appear at the same "level" as a command to be cancelled (important for the UI to make sense around delegated tasks).

I have tested it on a couple of agents and (Atlas and Apfel) and it seems to behave as expected so long as you clear the task prior to the agent collecting it.

If I have managed to update things correctly, you should see a new commit in my branch that this PR is now linked to. If not; ping me and I will do my best to close any gaps in my lack of process :).

TL;DR,

• Tasks can be cancelled from UI using the "delete / wastebin" icon that is now in the modal dialogue.
• Tasks are cancelled not deleted from database therefore audit trail is preserved.
• GraphQL permissions are no longer messed around with.
• Fast fingered users of BOF's should no longer have heart attacks so long as sleep is set to something operationally sensible.

Simon