Creating Vulnerabilities
When creating a vulnerability in AttackForge, we assign it to an asset on the project scope. There are two (2) methods you can use to create a vulnerability:
- 1.Add Vulnerability
- 2.Import Vulnerability
Considering that adding vulnerabilities is part of the role for a pentester - only users with Edit access to the project can perform this function.
To add a vulnerability on a project, click on Create Vulnerability from the project quick actions menu.
Select the relevant library.
- Main Vulnerabilities contains the majority of the vulnerability write-ups/templates.
- Imported Vulnerabilities contains write-ups/templates for vulnerabilities that have been imported from tools and scanners.
- Project Vulnerabilities is where you can define and create project-specific vulnerability write-ups/templates. This is useful if the vulnerability contains sensitive information or data you do not want shared with other users for other projects.
Select the write-up/template from the chosen library. Hovering over an entry in the library will show you the details in the right-hand side. You can use keywords to search your library.
If you cannot find a vulnerability write-up/template you wish to use, you can create a new entry in the relevant libraries by clicking on Create Writeup button.
Select one or more assets which are affected by the vulnerability.
You can capture vulnerabilities at an 'affected endpoint' level. This is useful for tracking and remediating every individual case where a vulnerability has been identified on an asset.
For example, you can track vulnerabilities:
- Per IP + PORT combination
- Per affected URL
- Per affected API endpoint
- Per line of code
A new vulnerability will be created for every affected endpoint.
By default, vulnerabilities are set to be immediately visible. This means any project team member can see the vulnerabilities right away. This is by design, to help information flow faster to the right people and to reduce Time-To-Remediate (TTR). However you can choose to set visibility to Pending which will place the vulnerability in the draft/pending state. Only users with Edit privileges on the project will be able to see the vulnerability (for quality review, tech review, peer review).
If you are using manual scoring - you will have option to manually select the Likelihood of Exploitation (from 1 [difficult to exploit] to 10 [trivial to exploit]) and Priority (Critical / High / Medium / Low / Info).
If you are using the CVSS scoring, you will see in-app calculator which will help you easily determine the CVSS score and adjust Likelihood of Exploitation and Priority accordingly, including adding CVSS scores + vector string as tags.
Include detailed steps to reproduce the issue. This is a rich-text field so you can include HTML payloads.
You can include additional asset-level notes which relate to the finding. This is an optional field. You can add as many notes as needed.
By default, tags will be assigned based on the vulnerability template in the library. However you can add additional tags if required. Note if using CVSS scoring - additional tags related to scores are automatically created for you.
You can also create custom tags which support arbitrary key/value pairs.
Where possible, try linking test cases to the vulnerability. This will help developers / engineers better understand what you were testing when it lead to discovery of this issue, which in turn provides knowledge transfer to help them avoid making same mistakes in the future.
You can link multiple test cases.
Upload any files and supporting evidence such as screenshots. If you want the screenshots to appear in-line in either the Steps to Reproduce or Notes sections when report is generated, you can click Add to Steps to Reproduce button or use shorthand syntax {{{YOUR_FILE_NAME}}}
The vulnerability (or vulnerabilities) will now be registered and assigned to the affected assets on the project. They will be automatically included in all on-demand reporting.
To import a vulnerability on a project, select Import Vulnerabilities from the project quick actions menu.
Select a tool you wish to import from, for example Nessus, BURP, Qualys, etc.
After you select a tool, you will be prompted to select the output file from the tool in order to parse the data. See example below for Nessus.
Once the data has been parsed, you can then select the vulnerabilities you wish to import into your project.
You can click on the vulnerability to preview the data which will be imported. You can update any of the vulnerability details as needed.
Once you have made your selection, you can click on Parameters to set custom configuration for the import. You can choose which vulnerability library you would like to map against for this import; set visibility for imported vulnerabilities; enter a custom mapping expression (see section below); or assign custom tags to the vulnerabilities.
When importing vulnerabilities, if a writeup does not exist in the library or cannot be mapped to using the default or custom mapping expressions - it will be automatically created for you.
Similarly if the affected asset does not exist on the project, it will be automatically created for you.
Click on Imported Selected to start the importing process. A summary of the import will be provided after it has finished.
AttackForge supports the ability to define a custom import mapping expression. This can be used to map your vulnerabilities to specific entries in your vulnerability libraries.
This powerful utility helps you to:
- Combine vulnerabilities into a single unique writeup
- Ensure your imported vulnerabilities are matched against known good and customer-ready write-ups
- Speed up your quality assurance and review process
- Reduce the amount of duplicate and similar entries in your vulnerability libraries
For example, say you have three (3) vulnerabilities your wish to import from Nessus:
- SSL Version 2 and 3 Protocol Detection
- TLS Version 1.0 Protocol Detection
- TLS Version 1.1 Protocol Detection
However, you want to map these against one (1) single known-good writeup in your library which covers all various TLS related configuration issues:
- Weak TLS Implementation
You can achieve this as follows:
vuln.tags.pluginID $in writeup.tags.pluginID
This expression works as follows:
- For every imported vulnerability (vuln), do the following
- For every writeup in the selected library (writeup), do the following
- Does the vulnerability have a tag 'pluginID' (vuln.tags.pluginId)?
- Does the writeup have a tag 'pluginID' (writeup.tags.pluginID)?
- Is one in the other? (vuln.tags.pluginID $in writeup.tags.pluginID)
- If Yes, map this imported vulnerability to the writeup in the selected library
- Otherwise, proceed to import vulnerability as per normal
Add the expression:
Compare the pluginID tag in the vulnerability:
With the pluginID tag in the write-ups within the selected library:
The imported vulnerabilities which matched are now grouped by Weak TLS Configuration writeup:
vuln.custom_tags.tls_weakness === writeup.custom_tags.tls_weakness
This expression works as follows:
- For every imported vulnerability (vuln), do the following
- For every writeup in the selected library (writeup), do the following
- Does the vulnerability have a custom tag 'tls_weakness' (vuln.custom_tags.tls_weakness)?
- Does the writeup have a custom tag 'tls_weakness' (writeup.custom_tags.tls_weakness)?
- Do they match? (vuln.custom_tags.tls_weakness === writeup.custom_tags.tls_weakness)
- If Yes, map this imported vulnerability to the writeup in the library
- Otherwise, proceed to import vulnerability as per normal
- vuln.priority - <string> priority of the vulnerability. Is either Critical / High / Medium / Low / Info
- vuln.title - <string> title of the vulnerability
- vuln.tags.<tag> - <string> a specific tag listed within tags. Requires the tag to have a colon-separator within the tag e.g. key:value
- vuln.custom_tags.<tag> - <string> a specific custom tag listed within custom tags. Replace <tag> with the name of your custom tag
- vuln.likelihood_of_exploitation - <integer> likelihood of exploitation for vulnerability. Is a number between 1 to 10
- vuln.description - <string> description of the vulnerability
- vuln.attack_scenario - <string> attack scenario of the vulnerability
- vuln.remediation_recommendation - <string> remediation recommendation of the vulnerability
- vuln.custom_field.<key> - <string> vulnerability custom field. Replace <key> with the key of your custom field
- vuln.proof_of_concept - <string> proof of concept / steps to reproduce for the vulnerability
- vuln.import_source - <string> import source for the vulnerability
- vuln.import_source_id - <string> import source id for the vulnerability
- writeup.title - <string> title of the vulnerability writeup
- writeup.tags.<tag> - <string> a specific tag listed within tags. Requires the tag to have a colon-separator within the tag e.g. key:value
- writeup.custom_tags.<tag> - <string> a specific custom tag listed within custom tags. Replace <tag> with the name of your custom tag
- writeup.likelihood_of_exploitation - <integer> likelihood of exploitation for vulnerability writeup. Is a number between 1 to 10
- writeup.description - <string> description of the vulnerability writeup
- writeup.attack_scenario - <string> attack scenario of the vulnerability writeup
- writeup.remediation_recommendation - <string> remediation recommendation of the vulnerability writeup
- writeup.custom_field.<key> - <string> vulnerability writeup custom field. Replace <key> with the key of your custom field
- writeup.import_source - <string> import source for the vulnerability
- writeup.import_source_id - <string> import source id for the vulnerability
Expressions support multiple operators which can be used to build more complex expressions:
- NOT or ! - used to negate an expression. For example !(vuln.title === "TLS")
- AND or && - used to and multiple expressions. For example vuln.title === "TLS" AND writeup.title === "TLS Weakness"
- OR or || - used to or multiple expressions. For example (vuln.title === "TLS" OR vuln.title === "SSL") AND writeup.title === "TLS Weakness"
- == - used to check for equivalency. For example vuln.title == "TLS"
- === - used to check for equality. For example vuln.title === "TLS"
- != or !== - used to check for not equivalency. For example vuln.title !== "TLS"
- > - used to check for greater-than comparison. For example vuln.likelihood_of_exploitation > 5
- < - used to check for less-than comparison. For example vuln.likelihood_of_exploitation < 5
- >= - used to check for greater-than-or-equals comparison. For example vuln.likelihood_of_exploitation >= 5
- <= - used to check for less-than-or-equals comparison. For example vuln.likelihood_of_exploitation <= 5
- ( ) or !() - used to group statements together. For example (vuln.title === "TLS" OR vuln.title === "SSL") AND writeup.title === "TLS Weakness"
- $in - used to check if a value is in a list of values. For example vuln.tags.pluginID $in writeup.tags.pluginID
- $nin - used to check if a value is not in a list of values. For example vuln.tags.pluginID $nin writeup.tags.pluginID
- =~ /RegEx/i - used to check for a regular expression. For example writeup.title =~ /SSL/i checks whether the vulnerability writeup has 'SSL' within its title.
vuln.tags.pluginID $in writeup.tags.pluginID
This expression will match a vulnerability that has a tag 'pluginID' which is also found in the writeups' tags.
vuln.custom_tags.tls_weakness === writeup.custom_tags.tls_weakness
This expression will match a vulnerability and a writeup that both have a custom tag 'tlsweakness' which has the same value.
(vuln.tags.pluginID $in writeup.tags.pluginID) OR (vuln.tags.someID $in writeup.tags.pluginID)
This expression will match a vulnerability that has either a tag 'pluginID' or 'someID' which is also found in the writeups' tags.
Last modified 2mo ago