Syslifters
[Feature Request] Hostnames/Targets Database
One of the major features of PlexTrac has is a host/targets database, where once a batch of findings is imported all the hosts associated with the finding are added to the project database organizing them into netbios name, IP address, DNS name, etc
I can take a shot at writing this up and adding this feature if it's not already on a roadmap down the road. Just point out what files I might need to look at and where the database gets initialized. Not the greatest with UI/Frontend stuff but I can prob get the bulk of this feature created and let you guys polish it off.
End goal being a Targets/Hosts section on the left under findings for the project. Ideally something where I can click on a specific host and see all vulns/findings associated to it. Edit/alter any info on the hosts/targets that will carry over to any finding it's in without needing to find each mention of IP 10.10.10.10 in each imported finding and change it to it's hostname/fqdn
Thank you for this feature request. Some thoughts about this from my side.
To wrap it up, the main benefits from this feature would be to:
- Overview of affected components (targets)
- Add additional information to each component (netbios name, IP address, DNS name, etc.)
- Filter findings by affected component
- Centralized modification of component naming updating all components
Ad 1: It should be easy to extract all affected components from the existing findings. This requires, however, a standardized field name (which must be present in the project design) with a standardized format. The best solution would be the predefined field affected_components (which is a list of strings).
(As not all designs have this field, this functionality suits better into a plugin.)
This also requires the pentester to use the same names for each component. Exact URLs (https://example.com/insecure.php) would only work if we parse the target and then group by fqdn (which makes the feature much more complex, especially point 3).
Ad 2: We probably would need to define a certain set of additional attributes. The naming from affected_components would be the central identifier (the "key"). We would need to handle the case when we rename the component to an already existing name that also has attributes (e.g., component1 with DNS name component1.com and component2 with DNS name component2.com both exist; a user now renames component1 to component2; a dialog might ask the user what attributes to apply and which to discard).
Ad 3: If there is a list of components already, this should be quite easy.
Ad 4: This is more tricky. Updating the name of the target must be confirmed using a button (no auto-save) because otherwise it could have side effects (e.g., when component and component1 exist, and we want to rename component to component12, the name would update to component1 during writing and then update all components to component12)
Could you do a --push-affected-components arg using reptor? Some pre setup for a project before you would run the normal --push-findings with reptor on a Nessus file for example
I mean technically that Nessus file could be that list of components already, that'll be your answer for Ad 3 in my opinion
Could you do a --push-affected-components arg using reptor? Some pre setup for a project before you would run the normal --push-findings with reptor on a Nessus file for example
That should be possible, though I don't yet fully understand the details.
As you write, this is a "pre-setup" step, I assume that there a no findings at this point in time. The "affected_component" field is (usually) part of a finding.
So my question would be: Where should the list appear in your report? Is this a report field with a list of all affected components?
the "pre-setup" was just a thought, technically yeah there would be findings in this Nessus file (could be either a host discovery scan or normal Nessus scan with actual findings too. Both would contain the "assets" found) If reptor parsed assets out automatically when --push-findings is ran that would work too instead of it being a pre-setup step.
The goal being to get: Centralized asset registry: Components are created once per project, not per finding. Cleaner payloads: Findings simply reference integers (ex: asset_ids) instead of duplicating strings everywhere. Better UI/UX: In SysReptor’s front-end you can now show a project’s “Asset Library” for quick selection (likely on the left below 'reporting')
I'm going to take a rough shot at a PR to show what I'm thinking
I was totally trying to let agentic AI do most of that heavy lifting but since I'm mostly guessing where all the logic is going I'm having a hard time keeping it on course with what I'm hoping to get.
I'm thinking it would be a good idea to have an affected components database since those are going to be mostly uniform across a specific report anyways. URLs for webapps hostnames, IP addresses, usernames for Internal and Externals with an option for port number
something similar to this structure { [UUID] , [URL/Hostname/Username] , [IP] , [Port/APIEndpoint] }
where [Port/APIEndpoint] info can be added per finding. The affected_components finding field can be a search bar that auto populates as you type a hostname, IP, URL like the findings templates, same optional manual add (maybe) with just that final field customizable. I can see the benefit of restricting editing the IP, URL, Hostname, etc inside only the "affected components" page if there was a new option on the left below "Notes" or "Reporting" This might be a bigger change than I was originally thinking but it would 1000% be a standout feature
Another goal to this would be to eventually use that to list each host with the number of vulnerabilities on each for each type
Vulnerabilities by host table: | Hostname | 3 Crit | 5 High | 6 Med | 3 Low | 12 Info |
Almost exactly like the "Hosts" tab on Nessus when you're looking at the results of a scan. Customer can see their problem PC's with the most vulns on them at the top
Another possible approach would be to generate this table of affected systems in the PDF design from the affected systems that are present in the findings.
Two other possibilities that rely on the affected systems in the findings would be creating plugins for:
- Create a markdown table from affected systems in findings (and copy/paste it where it's needed)
- Generate a notes structure from affected systems (if that helps, but that cannot be reused in the report)
Both plugins could be combined with a dedicated "affected systems page".
The drawback of all those solutions is that the naming (or at least the naming schema) of the affected systems must be the same throughout all findings.
Hi,
I think introducing an asset database to projects is quite a big feature. When implementing, we should keep it generic that it benefits many users and not limit it to a specific use case of a single user/company. Because of that, it should be possible to define custom fields (similar to custom finding fields, e.g. for notes, additional info) for assets in addition to hostname, IP, port, etc.
Here are some things to consider when implementing:
- add asset definition to design
- allow custom field definition
- add input field type "asset": select (or create) assets
- UI: maybe similar to field type user
- data storage in JSON: ID of asset
- data formatting during PDF rendering: use asset object instead of ID
- support exporting/importing asset database together with projects
- add REST API endpoints for asset management
- integrate with collaborative editing (events when assets are created or updated)
- asset view in web UI
If you only need a asset list in the PDF, this is already possible via defining custom fields and formatting/linking them via the Vue/HTML template language during PDF rendering:
- Define a list of assets in a report section (field type
list[object[id, hostname, ip, port, etc.]]). This is the central per-project data store to define/manage assets. - Finding field with asset ID (field type
combobox- supports auto-completion of targets referenced in other findings). Link assets via their ID to the asset definition entry. This can be a human-readable identifier string (instead of a UUID) to more easily identify references. - PDF rendering: finding.asset_id lookup in report.asset_database and render asset properties. You can use helper functions and inline variables in the Vue/HTML template.
With this approach it is possible to centrally manage assets and render them to PDFs similar to your proposed solution. The downside, however, is that the integration into the web UI is not seamless:
- no linking between asset->findings and statistics in the web UI (it's possible in the PDF, though)
- only partial autocomplete in finding.asset_id field (only previously used asset IDs)
