New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Custom abilities do not support requirement definitions using stockpile basic parser #2974
Comments
I take that back, the YML created doesn't quite match. It is (from created yml)
vs (from readthedocs.io)
The line "relationship_match:" doesn't exist in the sample. |
These V1 and V0 formats seem to refer to the 2 formats you found. Meaning, both formats should be parsed and loaded as Requirements properly. I have not met your issue while using requirements in custom abilities and adversaries. My guess is that you have another issue with your example that's not related to these different requirements formats.
|
@guillaume-duong-bib I think you are correct that the issue is in the parser for the definitions. Please note that in these screenshots I don't have a target field defined for the data.requirements.basic parser ingesting later with requirements. I've done this exact same process with that field populated and got the same results. A "Hello" to create a custom field with basic parser: A "World" receiver using the stockpile parser: A "World" receiver using a customized parser: This customized receiver is a copy of the parser from stockpile with a bunch of logging turned on, and a couple bits of logic flipped. This is experimental, just trying to understand why this was failing. I'm not much of a Python guy so this could be not the best solution. |
Just because I love going overkill with diagnostic data, here's the console output for my custom parser changes. This output includes the changes I noted above. basic.py | self.is_valid_relationship | first argument is link.used
|
And the output from my custom parser, with the original logic - basic.py | self.is_valid_relationship | first argument is [f for f in link.used if f != uf]
The "validating if in used facts" output doesn't show since it isn't getting iterated through. There is no 'fact in used_facts" statement for the loop it's embedded in.. The |
TL;DR: you are using the wrong requirement. Here's what I can say:
Although the |
@guillaume-duong-bib, many thanks for the detailed assistance! Can you clarify what you mean by the following a bit?
It's a pretty standard thing in English at least to have only a subject and a verb without an object so maybe this is confusing me. However one of the stock abilities parsers does exactly this, so it seems supported in Caldera? Returning to the behavior of the basic parser, I see in the Parsers docs where you have to have the target defined. The windows lateral movement guide example has does not have a target for plugins.stockpile.app.requirements.basic about half way down. I'm guessing needs a documentation update for clarity. A dedicated page for the stock parsers and their requirements would be great.. I'd love to be involved in that. To be sure I understand how this parser should be working, I worked through this again with all three fields populated. If I'm understanding plugins.stockpile.app.parsers.basic correctly, this should result in source "hello" exists and is equal to "this is hello". The edge is the literal string "exists". The output exists and is set to "this is hello". That's my read of the facts created. If this is the case, I should have all three conditions present and met. In theory shouldn't I be able to use plugins.stockpile.app.requirements.basic to parse the output? This is "OC - World Default Requirement" for reference. If so, why is "OC - World Default Requirement" skipped and fail to execute in my operation? |
|
I've noticed something about the
The above is very different from something like
in the sense that I do not expect the value of The exception is in
but in that case, So in summary, this parser is not meant to be used the way you did (and I did in my tests), that is to say with a relation between 2 non-existing facts. It's either used:
This may have been obvious to some, but this is a good discovery for me, now I understand its purpose properly. |
Thanks @guillaume-duong-bib, appreciate your insight. I didn't make a lot of headway using that lateral movement guide, so I stopped and designed my own variation, hence the questions here about building out relationships. The "exists" for the edge definitely wasn't the best example, that was a poor choice on my part. Something more like "has_software_xyz_installed" or "is_network_accessible" is more of what I was thinking. Those cases could still be pulled apart further apart and have a true / false value in the object instead of being implied. I see what you mean about needing to use the target definition in the command block along with the basic definition, using the output variable in "OC - World Default Requirement" has the anticipated results in the flow. I really wasn't expecting there to be smarts in place about the variables being used when checking if they should be available.
|
I've been working on a set of ability definitions - one for each parser from stockpile. For each parser one, two or three arguments. The goal was to create an adversary that I could import into my other adversary definitions that would display exactly what conditions would be met and why as I develop my own emulation plans. Would either that set of definitions or the chart output be useful to post back here? Seems like something that might be worth adding to the readthedocs documentation. |
I can't say I see precisely what your set does, so I guess if you don't mind sharing it, this may be helpful to some. |
Sure thing. Hello facts are defined as follows. Each of the "World" command uses #{hello} for V1 or V2, or both #{hello} and #{output} for V3. This chart is a breakdown of how the various combinations of stockpile rules function for one of my test devices. A ZIP file of the output so it's reproducible. Please note that this expects there to be a copy of the 'requirements' files under data/requirements/.. That's a remnant of my earlier testing, left in place so I could add debugging output without breaking the production copies of these files if needed. |
Describe the bug
Fact requirements are not respected for custom abilities on v 5.0.0.
This is based on the requirement definition, structured after https://caldera.readthedocs.io/en/latest/Requirements.html.
The relationship creation process for the demonstration below is using the factory stock "View remote shares".
To Reproduce
Create a new adversary.
Use an ability such as "View remote shares" to create facts
Notably this should have a parser definition similar to the following.
The step "OC - Test Display" will not be listed.
Expected behavior
The step "OC - Test Display" should be listed, or reasons for the failure included, either in the web interface or the console output.
Additional
I have checked the YML definition and it matches what looks right from the documentation.
The text was updated successfully, but these errors were encountered: