Custom Vulnerability Object to detect Failed WordPress Logins

Showing results for 
Show  only  | Search instead for 
Did you mean: 

Custom Vulnerability Object to detect Failed WordPress Logins

L1 Bithead

I'm trying to stem the flood of wordpress brute force attacks coming into our network (we host a lot of WP sites).

Detecting WP logins is relatively easy, by setting up a signature that looks for the regex wp\-login\.php in the http-req-uri-path context with the http-method = POST qualifier. I can now see all of the wp-login requests coming into our network.

However, detecting a failed WP means also detecting the 200 response code from the web server (WordPress issues a 302 redirect upon sucessful login, a 200 upon failure).

I have tried adding an extra AND condition to my signature which checks for http-rsp-code = 200 but it doesn't trigger. So...

Custom Vuln Signature:

Severity : Informational

Default Action : Alert

Direction : client2server

Affected System : server

Signature (Standard)

Scope : Transaction

Ordered Condition Match

Condition 1 : pattern-match http-req-uri-path ~= wp\-login\.php

Condition 2 : equal-to http-rsp-code == 200

Why is this failing to work? Without Condition 2 it shows up all wp logins, but with Condition 2 it sees nothing. Help 🙂


L7 Applicator

Hello Simonblackler,

Could you please post your query to DEVCENTER, they might help you for your custom signature.


L4 Transporter


We control wordpress logins in the following manner:

force your web content management staff us only access the Wordpress login page from on the network (internal zone) and if they require it from of the network then require them to use a vpn solution.   This then means that any wordpress login request from the internet is not desirable and can be blocked with the signature that just identifies the incoming request from the internet.  We have been doing this for over a year now with a lot of success.


Thanks Phil, unfortunately this won't work - we are a web host and host thousands of wp sites - we need to block/reset incoming connections from external/public IP addresses that repeatedly fail to log into WP correctly.

L7 Applicator

The signature does look correct for the response code 200.  Can you do a packet capture on a failed login and confirm what the data looks like in the response?

Steve Puluka BSEET - IP Architect - DQE Communications (Metro Ethernet/ISP)
ACE PanOS 6; ACE PanOS 7; ASE 3.0; PSE 7.0 Foundations & Associate in Platform; Cyber Security; Data Center

L5 Sessionator

Hello Simon,

Try making the scope as session instead of transaction.


Hari Yadavalli


If you look at the document located here: Creating Custom Threat Signatures in particular look at Example 4 located on page 45.  You can create a combination signature to detect brute force attempts with variables you can set (# of connection attempts in a time period) that will separate the valid users from those who are up to no good.


Hey Steven, thanks for your reply. I captured the transaction - and here is the "Follow TCP Stream" output from Wireshark of the relevant packets...

POST /wp-login.php HTTP/1.1


Connection: keep-alive

Content-Length: 110

Cache-Control: max-age=0

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8


User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/36.0.1985.125 Safari/537.36

Content-Type: application/x-www-form-urlencoded

DNT: 1


Accept-Encoding: gzip,deflate,sdch

Accept-Language: en-GB,en-US;q=0.8,en;q=0.6

Cookie: wordpress_test_cookie=WP+Cookie+check


HTTP/1.1 200 OK

Server: nginx

Date: Mon, 04 Aug 2014 09:36:41 GMT

Content-Type: text/html; charset=UTF-8

Transfer-Encoding: chunked

Connection: keep-alive

X-Powered-By: PHP/5.3.28

Expires: Wed, 11 Jan 1984 05:00:00 GMT

Cache-Control: no-cache, must-revalidate, max-age=0

Pragma: no-cache

X-Frame-Options: SAMEORIGIN

Set-Cookie: wordpress_test_cookie=WP+Cookie+check; path=/

Content-Encoding: gzip

The actual Hex dump of the POST and the response (respectively) are:

Wireshark has no difficulty seeing this transaction and correctly decodes the Status Code as 200 in the analysis frame at the bottom of the window.

I can only assume that there is a bug in PAN OS or this is by design (i.e. unable to mix req and rsp contexts in a single signature)?

Thanks for your reply - I have read that document backwards and forwards several times, trying to see if I'm missing something obvious 🙂

Unfortunately, the approach highlighted in the example is too simplistic. It is quite possible that an IP address might log into numerous WP sites legitimately. Web designers in particular are a customer group we don't want to annoy by being overly zealous. As we are a web host, we have a LOT of legitimate WP login requests. We already block clear cases of abuse using a similar combination signature, but a lot of attacks are characterised by a handful of failed logins from an IP every hour - not enough to trigger the combination signature, but still a problem, especially when we have several hundred IPs exhibiting similar behaviour.

Dear Hari,

Making the scope Session is not appropriate - and doesn't work anyway :-)... In a session it would be expected that at some point a POST request for wp-login.php will be made, and at some point later in the session a 200 status will be issued (not necessarily as the direct result of a login, but precipitated by a later page request in the same session).

  • 9 replies
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!