ASM Custom Signatures, oh my!

I love the fact that the ASM has so many pre-built attack signatures. The ASM engineers do a fantastic job at responding to new issues and getting fresh signatures out to help defend our networks. But, sometimes I am not a patient monkey...

so I want to go in and get a mitigation to new vectors immediately.  Luckily, this is were custom attack signatures come in!

If you know regex ( )  and spend a little time reading the signature syntax, we can write a new rule for anything we can accurately detect.  

A basic rule is made up of 3 parts:

What you want to look for and where

A regular expression to match on

Reference links for the signature.

We all know about the onload event. It runs a script on page load. Easy peasy. We know it, we block it, it's done. So how does the ASM signature work protecting parameters?

Check it yo!

Full Signature

valuecontent:"onload";nocase;norm;re2:"/onload\b\W*=/Vsi";norm; reference:url,; reference:url,;

But what does it MEAN?!

Valuecontent:"onload"; - look at the alphanumeric value in parameter for the value "onload"

nocase; - the previous value is not case sensitive

norm; - apply normalization procedures to incoming data before trying to match the signature. This helps catch items that attempt to use evasion techniques by encoding the input in some other form. Simple example:

http:// = http:%2f%2f (simple URL encode)

re2: - the regular expression engine to use. RE2 was implementing Version 11.2 (and it is awesome).

"/onload\b\W*=/Vsi" - the regular expression

      / -start regex

     onload\b\W* - find the word onload,

             \b means word boundry, so find only onload.

              \W* means none word characters (anything that is not a letter, number or underscore). The * says as

               many of those as you want.

       This regex will match onload, startonload,onload=, but not onloadstart.

/ - stop the match string

Vsi  - modifiers from the custom syntax

V - Parameter and value pairs, or XML or JSON data payloads

i -  The match is not case-sensitive.

s - Change the dot character (.) to match any character whatsoever, including a new line, which normally it would not match.

Voila,  translation complete.

We is Learned, now do!

Let's apply the learning.  HTML5 introduced a slew of new event attributes. The upside,  they are some cool attributes! The downside, each event attribute presents a new fun little XSS attack.   The one I want to look at not is “onloadstart”  (w3 list of events). This attribute typically used to  kick off a script when a piece of media is loaded.

Creating the rule is easy. Honestly, we could pretty much copy the onload rule and add the word start, but for the exercise, lets walk the walk.

Our goal: A rule that can detect someone attempting to submit the onloadstart in a parameter.

1. what to we want to look for and where?

Look in the parameter with valuecontent, and we want the word onloadstart


We want it to be case insensitive

valuecontent:"onloadstart"; nocase;

and we want to make sure to catch any obfuscation techniques

valuecontent:"onloadstart"; nocase; norm;

2. What’s the regular expression to find that?

Use the RE2 engine:


Start by looking for the word onloadstart,


Then allow for none wordcharacters and an equal sign


Close up the expression and apply it to multiple payloads, case insensitive


and again, make sure to catch any obfuscation techniques


3. Finally, any references we used that we want the ASM engineers to see when it’s matched?


So here we go, our rule:




Let’s apply it to the ASM.  

1. Create the signature

     A. Click Options –> Attack Signatures –> Attack Signature Lists –> create

     B. Create a name, select the attack type (for this we use XSS)

     C. Insert the rule, select the accuracy and risk (dependent on your Cost benefit analysis and scope of rule)

     D. Hit create

2. Create a new signature set to assign the custom signature to

     A. Click Options –> Attack Signatures –> Attack Signature Sets –> create

     B. Create a name, select the attack type (for this we use XSS)

     C. Select the rule name you created from the list below (Hint, select the list and type the name to find it)

     D. Hit create

3. Assign the new signature set to the policy

     A. Click  Attack Signatures ->  Attack Signatures Configuration

     B. Select the custom signature list from Available Signature Sets:User-defined.

     C. Add it to the list and select whether to learn/alarm/block on the signatures in the set.

     D.  Save and apply the policy.


                                         Woot! Mission accomplished.




Published Sep 13, 2012
Version 1.0

Was this article helpful?


  • Not sure if this is only for 11.6.0 but it requires semi colon on the last tag.
  • I'm trying to make some rules to match URLs. Specifically, I want to block spam POSTs with more than 2 links in them. I'd really appreciate it if you could post an example of something like that. Thanks!