Auto login to LiveID with Burp Macros/Session

A common problem when doing a web app assessment is being logged out. This sort of thing sucks. It can happen for a variety of reasons. For example, I’ve run across sites that have short timeouts, and I’ve run across sites that log you out whenever a WAF fires. In scenarios like these, it’s handy to automate the process of logging back in.

This post is about how to do that using Burp macros and session handling against Live ID. The same technique could be used against almost any website with a login (gmail, facebook, yahoo, etc.) so this really isn’t a problem with Live at all. In 2010 I wrote a burp plugin that automated this same situation, but luckily since then Burp has improved and the plugin is no longer necessary.

To clarify what I’m trying to do

For the sake of clarity, say I want to be logged in to *, no matter what.  For example, an unauthenticated request to might look something like this.

and notice burp’s cookie jar is also empty

But it doesn’t matter. The request goes through anyway, exactly as if I were logged in in the first place.

The same thing should happen if I’ve logged out, been logged out, my session expired, etc. The same thing should happen whether I’m in repeater, scanner, intruder, etc. I just want to always be logged in.

First, the easy way

If you load this burp config file it will have everything pretty much setup to auto login to live. All you should need to do is to add your creds to the ‘ login’ macro in request 3 where it says YOURUSER and YOURPASSWORD.


The following steps are starting from scratch, but might be useful if you’re trying the same thing elsewhere.

1. Create a macro that logs in to LiveID

This setting is under Options->Sessions->macros.  Here you want to create a rule that re-logs in. I used four requests to simulate a login to hotmail, though it could be various sites. The requests looked something like this:

Request 1:

GET / HTTP/1.1

Request 2:

Grab all the parameters from the request 1 redirect

GET /login.srf?wa=wsignin1.0&rpsnv=11&ct=1328218303&rver=6.1.6206.0&wp=MBI& HTTP/1.1

Request 3 – you’ll notice a csrf value in the page retrieved from Request 2 (PPFT). Grab that and put it in the request.

POST /ppsecure/post.srf?wa=wsignin1.0&rpsnv=11&ct=1328218303&rver=6.1.6206.0&wp=MBI& HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 464*X3vaE0zlJd%21CuSvWW5KR7oo821b05kJ*q*QI86LZ%21KAITFA45s%21j9AS1hbDBJ8l*Dm6WaSaeLkqwQoalApRiYR6JDKnYED4j*mxlN5aS1SOzap5Ny2ATyi041M1nfhrnlMUFQQxem5miQ1B1wSFtsmJyJyuJ1WxnC*1D6AVXpDYoUS7vQ9z6ybDQ3Zt3MsXM*DYw2yCpt0hnsRm2RmosTXhwBLxbtfIZQWCYJJ6Pimw4yg%24%24&idsbho=1&PwdPad=&sso=&i1=1&i2=1&i3=29830&i4=&i12=1&i13=&i14=1092&i15=1506&i16=9462&i17=

Request 4, actually might not be necessary… but just follow the redirect again.

One piece here is extracting information from previous requests. To do this, configure the individual requests and create a custom parameter in the response. For example, in request 2, highlight the PPFT value and burp will take care of adding it. It should end up looking something like this:

Most the parameters can be prefilled in request 3, but the canary takes that extra step.

2. Create Session Rules that Detect if you’re logged out, and if you are, call the macro from step 1

Like step 1, this is pretty straightforward using burp. Go to the session handling section and create a new rule. In that rule, add a a “Rule action”. This action checks if a session is valid or not, and if it’s not, it runs the macro we just created. In this case, I detect if I’m logged out if I’m redirected to or if I see “Windows Live ID requires JavaScript to sign in.” in the response.

^^ this is the redirect check

If I am logged out, I tell the session handling action to call the macro we created.

The last thing that’s necessary here is to define the scope, both in terms of the tools and the sites. For me, I added all tools to the scope other than the proxy, and to the URL scope.

3. Troubleshoot using sessions tracer

One essential debugging tool is to use the session tracer. A good trace should look something like the following:

Go through the requests one by one to make sure everything goes as expected, first the detection that you’re not logged in, then the various requests necessary to login.

Anyway, it took me a bit to get this working properly, so hopefully this is helpful. Have fun!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s