Is there a way to execute abilities only on the new agent?

[kacvinsky-tom]

Hello,

I am creating an adversary profile with a bunch of abilities, which should be executed on two victim machines.

I deploy an agent on the first one and run the operation. However, the adversary profile consists of an ability that deploys the agent on a second machine with PsExec. From that point, the planner runs abilities on both agents, but I want to use only the new one.

I've read through the documentation but couldn't find any straightforward answer to this problem. Can you suggest me some easy solution, so from that point I can only run link of abilities only on the second agent?

I thought about either killing the first agent or adding the ability right after deploying the agent, which will fail on the first machine but succeed on the other.

Thanks!

[Guil33]

You could use groups if you just wanted to execute the operation on the first agent, e.g. agent 1 is part of group "1", if you limit the operation to group "1" it should install the agent of the new victim hosts and not use them. That would be somewhat clean, but it probably can't work the other way round, so this doesn't answer your question.

A dirtier way I can think of for your issue would be to use facts.

I first considered using requirements as well, but after some thinking I can't figure out how, since you would need to have the new agent parse a new fact without allowing the first agent to do the same. (My idea was to have the deployment ability create a fact for the new agent, then use this fact as a paw_provenance requirement for the following abilities... But this fact would be created for the first agent, so it doesn't work. Maybe you can think of some way to do this.)

Following this though, you could add something like echo victimHostname to your deployment ability, have it parsed into a fact e.g. victim.new.hostname (or whatever) and check for this fact in the code of the next abilities:
if (#{victim.new.hostname} -eq hostname) {...} else {echo "not executed"}.
This isn't a fast solution, but it's relatively easy and should also work on a larger scale, since even if you have several facts victim.new.hostname, the if will ignore them.
Obvious issues of this workaround:

• you have to add the if to all the abilities that you want to restrict to your second victim.
• although the next abilities will be "prevented" by the if and thus not actually executed, they will still be created by Caldera in the operation, meaning you will se them on the dashboard & report. So not ideal nor optimized.

In short, I definitely don't have a simple solution to this. Killing the first agent after the deployment may be your best shot, assuming you no longer need it for anything. I might have overlooked some simpler method, though.

[kacvinsky-tom]

@Guil33 Thank you very much for your detailed response!

I also thought about hostname parsing, and it seems the most realistic way of accomplishing it without killing the first agent.
However, the "mess" with failed abilities in the dashboard & report irritates me.

It would be nice if there were a way of starting up an ability in the adversary profile based on the agent's name or, at least, order. I thought this must have been somehow implemented, as it's important when emulating the APT attack, but it seems I was wrong.

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days

[elegantmoose]

@kacvinsky-tom Late to the party but the preferred solution here is to use a custom planner. You could essentially see what candidate actions are on the queue, filter out the actions for preferred agent, and then apply those actions to the operation.

Its not a simple solution, as you would need to write some code, but it also is not overly hard.

https://caldera.readthedocs.io/en/latest/How-to-Build-Planners.html