Indicators of Compromise
See original GitHub issueCurrently the VRT doesn’t cater for situations where a compromise has occurred, and proof is available. This may not always be malicious, and there’s a few situations where this could apply:
-
A subdomain is clearly under the control of another organisation, which can happen when an IP has been released (in Microsoft Azure or another cloud based product), and later claimed by another organisation (but DNS mapping remains).
-
A more direct compromise, where a webshell, and other datapoints suggesting compromise have been found by a researcher.
-
Cryptojacking scripts found on a host website.
I believe this should be a P1, however I believe the language is important to help limit false positives, and so this can cover point two of the above in situations where the action may not necessarily be a malicious one. I’m not entirely certain what that wording would be, but the best I could land on was:
P1 - Evidence of Site Compromise or No Longer Controlled by Client
Alternatively, this could be a new category with branches off of it, but that in itself seems excessive for what is quite likely a rarer edge case.
Issue Analytics
- State:
- Created 5 years ago
- Reactions:3
- Comments:10 (9 by maintainers)
Top GitHub Comments
Definitely @codingo.
We send the swag with each release so once we cut the next version will send it out.
After discussing this with the team we agreed that there’s some potential for adding a new “varies” category. The proposed entry is: Varies -
Indicators of Compromise
This category could be used to build out a more detailed structure in the future.