Creating Vulnerabilities
Last updated
Last updated
Check YouTube for more tutorials: https://youtube.com/@attackforge
Vulnerabilities in AttackForge get created on projects. A vulnerability is linked to either one or more projects.
With the exception of Administrators, a user can only see vulnerabilities for which they have access to the project(s) linked to those vulnerabilities.
Every project can have up to 10,000 vulnerabilities. This limit helps to ensure reports can be created for the project.
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:
Add Vulnerability
Import Vulnerabilities
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 menu.
Writeups are knowledge-bases for your vulnerabilities. Writeups make it easy to search and reuse vulnerability definitions that you or your teams have previously created in a Writeups Library - saving you time and effort on recreating what has already been done before.
When creating a vulnerability, you will be able to select from Writeups in Writeups Libraries for which you have access.
All Writeups - contains all the Writeups you have access to across all your libraries.
Main Vulnerabilities - contains the majority of the vulnerability writeups.
Imported Vulnerabilities - contains writeups for vulnerabilities that have been imported from tools and scanners.
Project Vulnerabilities - is where you can define and create project-specific writeups. This is useful if the vulnerability contains information you do not want shared with other users outside of your project. It also helps to create derivatives of other writeups which are tailored towards your project.
Custom Libraries - any custom writeups libraries which you have access to.
Select the writeup 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 writeup 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 choose from Individual or Grouped options:
Create unique vulnerabilities on every project, and assign relevant affected assets to each unique vulnerability
Create individual vulnerabilities for every asset
Create a combination of unique vulnerabilities and individual vulnerabilities – for ultimate flexibility!
Individual option will create a seperate vulnerability for every affected asset
Grouped option will create a single vulnerability and link all affected assets to that vulnerability
Using grouped option can help you to:
Increase efficiency when working on infrastructure penetration tests
Reduce the overall number of vulnerabilities whilst preserving affected asset data
Reduce effort required for quality review cycles on vulnerabilities
When using grouped option, every asset can have its own notes, tags, and affected components.
Components can be used to track which part(s) of the asset has the vulnerabilities, for example you can include URLs, ports, line of code, etc.
Every component can also have its own notes and tags.
When using the grouped option, every asset can be individually tracked and actioned.
This is useful for monitoring the progress against assets on a vulnerability.
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 access on the project will be able to see pending vulnerabilities - 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 an in-app calculator which will help you easily determine the CVSS score which will automatically set the Likelihood of Exploitation and Priority accordingly, including adding CVSS scores + CVSS 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 notes which relate to the finding. This is an optional field. You can add as many notes as needed.
Depending on how you have configured your vulnerability form for the current project, you may have other custom fields or section that need to be completed. You can customize your vulnerability form from the Administration module.
Tags will be assigned based on the writeup. However you can add additional tags if required.
If using CVSS scoring - additional tags related to CVSS are automatically created for you.
You can also create custom tags which support arbitrary key/value pairs.
Where possible, link 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 to a vulnerability.
Upload any files and supporting evidence. You must first create the vulnerability.
If you want the screenshots to appear in-line when you view the vulnerabilities or in reports, you can click Add to Steps to Reproduce button or use shorthand syntax:
{{{FILE_NAME}}}
The vulnerability will now be created and assigned to the affected assets on the project.
You can tailor your vulnerability form to match the needs of your project.
For example, you can create a custom vulnerability form depending on the type of testing being undertaken on the project:
Web Application
Infrastructure
Code Review
Red Team
Purple Team
PCI DSS
Etc.
The vulnerability will display the custom fields when viewing the vulnerability. For example, on a Red Team project - we can show extra Red Team related section and fields for the vulnerability:
In your Project Custom Fields settings, create a multi-select custom field that will be used to assign the various types of testing on the project.
In your Vulnerability Custom Fields settings, create new fields and sections that will have a Hide Expression applied to only show those fields or sections under certain conditions, for example when the relevent testing type is selected on the project.
Using the example above, we can set the following Hide Expression to only show this section when the Red Team testing type is selected on the project:
This condition states the following:
Hide this field when
No selection has been set for testing_types multi-select field on the project
The testing_types multi-select field on the project is currently empty (had selections before, but now all selections have been removed)
The testing_types multi-select field has values AND one of those values does not include the selection Red Team
Therefore, this field should only show when a Red Team selection has been made in the testing_types field.
Create or Edit your project and select a matching testing type in your new project custom field, for example Red Team.
Now when you create a vulnerability on the project, a new section will appear for Red Team related information.
You can use this same approach to tailor your form to match the needs of your project.
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 will have a choice between selecting Individual or Grouped.
Individual will allow you to import one vulnerability per affected asset.
Grouped will allow you to automatically group affected assets for each vulnerability.
In the example above, there was a 94% reduction in vulnerabilities when choosing Grouped option, whilst preserving the same amount of data.
This means you can focus your attention on the important vulnerabilities and track their affected assets much more efficiently.
You can view all of the affected assets, and for each asset – see related data for its affected components.
You can configure the Grouping options to adjust the rules for how the grouping is performed.
Once you have made your selection, you can move to the Edit and Review step.
Here you can see the final set of vulnerabilities for selection and make any remaining adjustments as needed prior to import.
You can still choose to configure your import options such as dynamic parser actions and Writeup library for mapping.
Once your import begins, you will be kept update to date with its progress.
And once it’s finished, you will see a summary of the import and option to view the vulnerabilities.
When importing vulnerabilities, if a writeup does not exist in the library or cannot be mapped - 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.
Vulnerabilities with grouped assets will now show in your vulnerability tables, with option to expand each vulnerability to see its affected assets data.
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 using the Individual option:
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:
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, move to the next writeup or proceed to import vulnerability as per normal if no match found
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:
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, move to the next writeup or proceed to import vulnerability as per normal if no match found
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.
This expression will match a writeup if its title partially or fully matches the title of the vulnerability. For example, if your vulnerabilities were Out-of-date Version (React) & Out-of-date Version (Bootstrap) - you can match them to a writeup with the title Out-of-date Version.
This expression will match a vulnerability that has a tag 'pluginID' which is also found in the writeups' tags.
This expression will match a vulnerability and a writeup that both have a custom tag 'tlsweakness' which has the same value.
This expression will match a vulnerability that has either a tag 'pluginID' or 'someID' which is also found in the writeups' tags.
