You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
When using plugins.stockpile.app.requirements.paw_provenance to verify if the specified variable exists in source facts, it does not recognize manually created fact. It results in two unexpected behavior.
1st unexpected behavior – marking fact as not collected, despite there is a fact created
nmap.targets is defined in fact source
Adversary profile still warn nmap.targets is not collected
2nd unexpected behavior - Adversary operation does not run
the ability never runs in operation. indicated by 0 decision | 4 min ago
To Reproduce
Steps to reproduce the behavior:
Create new fact source which set nmap.targets to 127.0.0.1
Create an ability which run nmap commands with fact-defined targets
Create a Linux executor inside the ability with requirement to verify nmap.targets exists
Refresh the page and select the newly created Adversary again
A warning is shown One or more of the abilities have unmet requirements, which may result in a failed operation if ran sequentially.. However, the fact is actually created in step 1
Proceed to create operation with the adversary created in step 4
Adversary: name of the adversary profile created in step 4
Fact source: name of the fact source created in step 1
Let the operation runs for a few minutes. There will not be any ability run
the ability never runs in operation. indicated by 0 decision | 4 min ago
Expected behavior
Two expectation
1st expectation - no warning in Adversary profile
If the variable can be located in any fact sources, it should not throw warning
2nd expectation – ability successfully run in operation
Since the variable is retrievable from the selected fact source, it should be able to run
Secondly, if we manually select potential link, it can actually show the variable.
Desktop (please complete the following information):
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/
Apologies for the issue submission — I overlooked the manual and didn’t fully understand the purpose of plugins.stockpile.app.requirements.paw_provenance. This module verifies that an agent has collected facts itself before execution; any fact not collected by the agent is not considered fulfilled.
I plan to submit a separate PR to Stockpile for enabling a plugin that checks whether a variable is not null. So far, I haven’t found an existing plugin that does this. If one already exists, please let me know so I can avoid re-inventing the wheel.
Describe the bug
When using
plugins.stockpile.app.requirements.paw_provenance
to verify if the specified variable exists in source facts, it does not recognize manually created fact. It results in two unexpected behavior.1st unexpected behavior – marking fact as not collected, despite there is a fact created
nmap.targets
is defined in fact sourcenmap.targets
is not collected2nd unexpected behavior - Adversary operation does not run
0 decision | 4 min ago
To Reproduce
Steps to reproduce the behavior:
Create new fact source which set

nmap.targets
to127.0.0.1
Create an ability which run nmap commands with fact-defined targets

Create a Linux executor inside the ability with requirement to verify
nmap.targets
existsnmap -T4 -Pn #{nmap.targets}
plugins.stockpile.app.requirements.paw_provenance
nmap.targets
Create an Adversary that uses the created ability

Refresh the page and select the newly created Adversary again
One or more of the abilities have unmet requirements, which may result in a failed operation if ran sequentially.
. However, the fact is actually created in step 10 decision | 4 min ago
Expected behavior
Two expectation
1st expectation - no warning in Adversary profile
2nd expectation – ability successfully run in operation
Since the variable is retrievable from the selected fact source, it should be able to run
Secondly, if we manually select potential link, it can actually show the variable.
Desktop (please complete the following information):
Backend
git rev-parse HEAD
: 6d3d853The text was updated successfully, but these errors were encountered: