its-a-feature
commented
7 months ago Is there a reason you don't use the built-in clear command?
Open sclow opened 7 months ago
its-a-feature
commented
7 months ago Is there a reason you don't use the built-in clear command?
sclow
commented
7 months ago 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
commented
7 months ago 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
commented
7 months ago 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
commented
7 months ago 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,
Simon
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:
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.