Unused variable in ability marked as requirement about caldera HOT 8 CLOSED

I have been using facts and requirements as a way to set the order of abilities with the batch planner. For instance, I may want a specific ability that downloads a tool to be run before an ability that uses the tool, even if the first one does not create any information to be used by the second one.

Wait, so an ability is not picking up a requirement that is listed? You should be able to have a Fact like that which can control execution through a corresponding requirement. Something like this: https://github.com/mitre/stockpile/blob/bac8177b6146bbe0f760e973428710d77e0081f2/app/requirements/existential.py

I re-checked my notes, I had forgotten the specifics.

This issue only occurs with paw_provenance (or to be more correct, it doesn't happen with existential) because this parser uses link.used, thus any fact that is not in the command is "not compliant" because it won't ever be found by the parser.

The reason I need to use paw_provenance instead of just existential for the batch optimization is for operations that use more than 1 host, as the installation of a tool does not take the same time on each host. So each host generates its own I'm done! fact, which is then used to start the next ability. That's the most logical way I found.

from caldera.

Looks like your first issue -- we aim to respond to issues as quickly as possible. In the meantime, check out our documentation here: http://caldera.readthedocs.io/

from caldera.

Hey @jeyam93, so it actually is used in the adversary, but in a sort of sly (non obvious) way. In short, when this adversary was prototyped, it had issues with repeatedly compromising the same hosts, which was not desired. So, the authors, working with Caldera's limited pre/post condition fact system did what they could to put some guardrails to make it work. In effect, this fact is one of the facts the adversary and fact source will use to try to prevent repeat spawning of the agent on the same host.

The fact (variable) is in the command so that it gets passed to the post action parsers. An implementation detail in Caldera, existing facts accessed in the parsers must be used in the action. Thus you get this (not ideal) hack of putting the fact in the command, even though not used by the command itself.

The fact/variable itself will actually get set in the parser if certain logic is hit (https://github.com/mitre/stockpile/blob/fe0c5b7bbd5dcdde4f90b5b6e493c2b0459d03e8/app/parsers/netlocalgroup.py#L71) and then be passed in to every follow on execution of the action (as the action will potentially fire on every new agent that is spawned).

Clear as mud?

from caldera.

An implementation detail in Caldera, existing facts accessed in the parsers must be used in the action
That's exactly the issue I ran into last week.
I have been using facts and requirements as a way to set the order of abilities with the batch planner. For instance, I may want a specific ability that downloads a tool to be run before an ability that uses the tool, even if the first one does not create any information to be used by the second one.

So what I did was create a random fact in the first, and use it as a requirement to the second, but I couldn't figure out for the life of me why the requirement didn't work... Took me a few days to understand that the fact needs to be in the actual command, so I now have a very ugly $whatever = #{the.requirement} at the beginning of my command.

Two follow-up questions:

• Is this behavior (requirements need to be in the command or they will always fail) documented? I found the solution by debugging, might have missed it in the doc.
• If not, it could be useful to document it explicitly and possibly to add a warning when a user creates a requirement for a fact that is not incuded in the command?

Also, what you explained in your 3rd paragraph isn't clear to me, but it might be a more elegant solution than just setting a useless variable as I do. I'm not sure how the parser (which operates after an ability) is able to influence the requirement check (before the ability) though, I'll try and understand that.

from caldera.

I have been using facts and requirements as a way to set the order of abilities with the batch planner. For instance, I may want a specific ability that downloads a tool to be run before an ability that uses the tool, even if the first one does not create any information to be used by the second one.

Wait, so an ability is not picking up a requirement that is listed? You should be able to have a Fact like that which can control execution through a corresponding requirement. Something like this: https://github.com/mitre/stockpile/blob/bac8177b6146bbe0f760e973428710d77e0081f2/app/requirements/existential.py

from caldera.

Is this behavior (requirements need to be in the command or they will always fail) documented?

Its implied, not explicit. We should detail explicitly.

from caldera.

Also, what you explained in your 3rd paragraph isn't clear to me, but it might be a more elegant solution than just setting a useless variable as I do. I'm not sure how the parser (which operates after an ability) is able to influence the requirement check (before the ability) though, I'll try and understand that.

Its the same approach you are doing, its just the same ability/parser will create the requirement/dummy fact. Its useful because the same ability will be hit many times in same operation because new agents are spawned start from first ability in adversary profile.

from caldera.

@jeyam93 Im going to close this one. Please reopen if need to.

from caldera.