Manually created facts not recognized by requirements

[gitonglue]

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:

1. Create new fact source which set nmap.targets to 127.0.0.1
   

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

3. Create a Linux executor inside the ability with requirement to verify nmap.targets exists

• command: nmap -T4 -Pn #{nmap.targets}
• requirement module: plugins.stockpile.app.requirements.paw_provenance
• requirement source: nmap.targets
  

4. Create an Adversary that uses the created ability
   

5. 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

6. 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
  

7. 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):

• OS: MacOS Sonoma 14.3.1
• Browser: Firefox, Chrome

Backend

• Caldera version
  git rev-parse HEAD: 6d3d853
• OS: Ubuntu 24.04.2 LTS

[github-actions]

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/

[gitonglue]

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.

Thank you :)

[uruwhy]

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.

Thank you :)

@gitonglue are you referring to checking for empty variables when filling out #{variable.value} in operation link commands? If so, that wouldn't happen in a particular plugin, but rather in this main repo.

[uruwhy]

Closing since this is not actually a bug