Reattack
When you have applied a solution for an existing vulnerability, you can request a reattack for us to validate its effectiveness. You can do this from the Locations and To-DoList sections of the ARM. The steps required are fundamentally the same in both sections. Here, we show you how to do it from Locations.
Log into your ARM account and click on one of your groups to access it. Once inside the group, you will see a list of all the types of vulnerabilities it has.
Now look for the type of vulnerability that contains the individual vulnerability or vulnerabilities for which you want to request a reattack are grouped and click on it. By doing this, you will land on the Locations tab of the type of vulnerability you chose. You can select only open vulnerabilities, and only those whose reattack status is neither Requested nor On_hold are eligible for reattacks. When you have made your selection, click on the Reattack button on the right-hand side of the screen.
The following form will appear where you will have to explain the applied solution.
After requesting the reattack, you will see the word Requested in the Reattack column corresponding to that vulnerability. From then on, you will have to wait for the response from the
Fluid Attacksteam. The latter’s response time will comply with the conditions set forth in the service-level agreements.
In the Consulting tab, you will see a new comment related to the justification you gave when requesting the reattack. In this same tab, our hackers can generate other comments and notify the decision taken on your request.
Reattack outcomes
The reattack status will be Verified (open) if the vulnerability you requested to reattack is still exploitable. Our hackers will give you evidence of how it was exploited, which you can access in the Evidence tab.
If the vulnerability is still open and you cannot close it for the moment, you can consider defining other treatments. One of them is Permanently accepted vulnerability. However, you can later try to remediate this vulnerability and request a reattack to verify its remediation.
The status will be Verified (closed) if the vulnerability you requested to reattack has been proven by our hackers to have been successfully remediated.
Reattacks on hold
Sometimes reattacks are delayed due to events in your environment, and having to send another reattack request can be tedious. That is why the ARM has the On_hold status for reattacks. This status denotes when reattack requests are put on hold. When the events are solved, the reattack request is automatically reactivated without having to be repeated. This use of automation provides agility to the reattack process.
Reattack for machine vulnerabilities
If the vulnerability was reported by Machine, there is no need to attach or write any detailed justification, since this service only analyzes code that is found on the repository and does not account for anything extra. If you believe the report might be a False Positive, or is not a vulnerability due to extra configurations in your environment, you can contact a hacker or request the Zero Risk treatment, instead of the reattack.
Because of the automated nature of the machine, the consulting report will only have a simple message, detailing open or closed locations resulting from the re-attack. If the reasons for the results of the re-attack are not clear, you can check the documentation of the vulnerability for code examples, or, contact a hacker if it is still unclear.
Search for vulnerabilities in your apps for free with our automated security testing! Start your 21-day free trial and discover the benefits of our Continuous Hacking Machine Plan. If you prefer a full service that includes the expertise of our ethical hackers, don't hesitate to contact us for our Continuous Hacking Squad Plan.