Customizing attack modules in Rapid7’s AppSpider

Today we’re going to take a look on how we can add, modify and enhance AppSpider attack modules payloads.

Before we begin a small introduction of what is AppSpider. Here is a description from their website:

“AppSpider is a dynamic application security testing solution that allows you to scan web and mobile applications for vulnerabilities.”

With that introduction out of the way. Let’s get started.

Note : We will not be covering on this tutorial the installation phase of AppSpider nor how to create a configuration to scan an asset as these topics are well covered in the official documentation that is available online [Link] . Instead, I will be focusing on how AppSpider Attack policy work, how Attack modules are structured, and how we can modify them.

How AppSpider perform attacks

AppSpider uses “Attack Modules” to perform attacks on targets to search for vulnerabilities. It comes preloaded with a bunch of these (over fifty attack module) for different types of attacks [See Below]

AppSpider Attack Modules

These modules are at the heart of the AppSpider, so let us take a look at how they work behind the scene.

We navigate to the install directory and to the modules folder located in “[DriveLetter]:\Rapid7\AppSpider7\ScanEngine\Modules”

Attack modules directory

This is where all the magic happens. Inside each folder, we’ll find mainly two files (attacks.cfg, module.cfg).

Module configuration file

Let’s take a look on how they work and what is their purpose.

Module configuration file (module.cfg)

AppSpider engine uses this file to load the module configuration before starting the attack.

Here we find all the information related to the attack module such as: the display name, module description, module type, module recommendation, attack points and a lot more. A list of these elements and what they do is kindly provided by Rapid7 themselves via their documentation [Link].

Module attack configuration file (attacks.cfg) :

This file will contain the configuration for each attack. That includes the payloads and the expected regular expressions of the results. The engine will use these attack configurations to perform its checks on the selected endpoints.

Now that we have seen, the structure of how a built-in attack module functions let us take a practical example and modify an existing module with our custom payloads.

Customizing an attack module

To keep things simple, we will be looking at the “XSS_Simple” attack module and we will not be modifying any configuration we’ll only take a look at the attacks.cfg file and how we can add payloads to it.

First, let’s see how an attack configuration block is structured in this module.

XSS_Simple Module

A typical attack configuration in the “XSS_Simple” module is composed of four basic blocks

1. ID: An identifier for the attack. Must be unique in the context of the module.
2. Description: A short description of the attack.
3. AttackString: The payload to inject during the attack.
4. VulnRegex: A regular expression used to check if the attack was a success.

Therefore, to add a new payload to this module we’ll only need to follow this structure.

Let us add for example the following payload.

<AttackConfig>
  <Id>XSSS_Custom_01</Id>
  <Description><![CDATA[Unfiltered <noscript> tag]]></Description>
  <CAPEC>18</CAPEC>
  <CustomParameterList>
    <CustomParameter>
      <Name>AttackString</Name>
      <Value><![CDATA["><noscript><p title="</noscript><img src=x onerror=alert(%RANDNUM%)>">]]></Value>
    </CustomParameter>
    <CustomParameter>
      <Name>VulnRegex</Name>
      <Value><![CDATA[]]></Value>
    </CustomParameter>
  </CustomParameterList>
</AttackConfig>

Paste this to the “attacks.cfg” file and we’re done.

The only thing left to do is to scan an target while selecting this attack module to see our new payload in action.

Here are the results after the scan.

Traffic log of the scan

We can see our newly created payload is being executed.

Thanks for reading.

Questions? Comments? Contact me via twitter @nas_bench