AcuMonitor: Detecting XXE, Blind XSS, and SSRF Attacks

Conventional web application tests are fairly straightforward – the scanner sends a payload to a target, receives a response, analyzes that response, and based on the analysis of that response raises an alert. However, some vulnerabilities provide no response to a scanner during testing. In such cases, conventional web application tests don’t work.

Conventional Request/Response Testing Model

How Does AcuMonitor Solve This?

Out-of-band vulnerability tests are meant for vulnerabilities that do not provide a response to a scanner during testing and therefore are not detectable using the conventional request – response test model.

To detect out-of-band vulnerabilities, you need an intermediary service that the scanner has access to. Acunetix, combined with AcuMonitor, makes automatic detection of such vulnerabilities painless and transparent to the user running the scan.

The illustration below shows how Blind XSS is detected using Acunetix and AcuMonitor

  1. Acunetix sends a payload to the web application.
  2. The XSS payload gets stored in a datastore and may remain there for an indefinite amount of time (i.e. long after the scan has completed).
  3. This payload is executed inside a victim’s browser at a later date, possibly from an entirely different web application which shares the same datastore.
  4. Once the XSS payload is executed, it contacts AcuMonitor notifying it that it was executed.
  5. AcuMonitor in turn notifies Acunetix that the payload has executed.
  6. Acunetix raises an alert for the newly discovered Blind XSS vulnerability.


Detecting Blind XSS using AcuMonitor

What Vulnerabilities Can AcuMonitor Detect?

AcuMonitor can automatically detect the following vulnerabilities during a scan:

Security of AcuMonitor Data

A common question about AcuMonitor is: “Does the AcuMonitor service store details of vulnerabilities that it detected?”

AcuMonitor is designed to be secure in the way data is transferred to it, as well as in terms of what data it stores and for how long it stores that data.

AcuMonitor payloads always make use of TLS when possible. This ensures that connections to AcuMonitor are encrypted. Additionally, AcuMonitor does not receive or store enough information to identify the source of a vulnerability. In other words, AcuMonitor only knows that a payload from a vulnerability test conducted by Acunetix resulted in a callback but it does not know what the source of the vulnerability is. No information about the original HTTP request sent by Acunetix is stored in AcuMonitor either.

  • To distinguish between tests, AcuMonitor uses random unique identifiers generated by Acunetix.
  • The HTTP request originally used to trigger the vulnerability is not stored by AcuMonitor, instead it is stored on the machine running Acunetix.
  • Requests made to AcuMonitor are stored for a limited amount of time (maximum 7 days).