Original ticket description:
Past experience has shown that Nuclei alone is inadequate in detecting dangling DNS records (namely, A and CNAME). The issue of speed (how quickly we find a record once it begins to dangle) should be improved with the tighter scan cadence, but we also need to improve the means by which we detect dangling records.
Currently, most instances of this issue are identified manually through the investigation of other Nuclei detections; incongruous site content and mismatched SSL certificate data usually make confirmation pretty straightforward, but sometimes context from Chariot screenshots / Wayback Machine / etc. is needed to confirm that the record is pointing to something that no longer belongs to a specific organization.
Ideally, we should detect these records before the IP is reissued, but this is challenging because an inactive IP that belongs to the customer and an inactive IP that used to belong to the customer look awfully similar. Attribution data from CSPs should help here, but that depends on some potentially complex functionality and wouldn't cover non-CSP hosting providers.
Preferred Solution
We'd like Chariot to automatically surface dangling DNS record findings
We'd like Chariot to mark risks originating from potentially dangling DNS records as "potentially dangling" so that operators can more quickly and accurately action those risks.
Allow operators to manually generate a dangling DNS record finding from a risk detection. This "manually generated" risk would receive continuous monitoring to check for changes to the DNS record/removal of the record and would auto-close once the IP is updated, or the record is removed (and auto-reopen if the dangling record resumes pointing at the associated IP). Ideally, creating the manual finding would mark the risks originating from the impacted record as "Rejected" because they were from dangling DNS records.
Problem
What problem does this feature solve?
Allow customers and MSP operators to more accurately action risks and manage dangling records in their attack surfaces.
Feature Description
Original ticket description: Past experience has shown that Nuclei alone is inadequate in detecting dangling DNS records (namely, A and CNAME). The issue of speed (how quickly we find a record once it begins to dangle) should be improved with the tighter scan cadence, but we also need to improve the means by which we detect dangling records.
Currently, most instances of this issue are identified manually through the investigation of other Nuclei detections; incongruous site content and mismatched SSL certificate data usually make confirmation pretty straightforward, but sometimes context from Chariot screenshots / Wayback Machine / etc. is needed to confirm that the record is pointing to something that no longer belongs to a specific organization.
Ideally, we should detect these records before the IP is reissued, but this is challenging because an inactive IP that belongs to the customer and an inactive IP that used to belong to the customer look awfully similar. Attribution data from CSPs should help here, but that depends on some potentially complex functionality and wouldn't cover non-CSP hosting providers.
Preferred Solution
Problem What problem does this feature solve?