rapid7/metasploit-framework

Browser Autopwn 2 is a complete redesign from the first one, so quite a few things will look and
feel different for you. Here are the features you should know about before using.

## Vulnerable Application

Browser Autopwn 2 is capable of targeting popular browsers and 3rd party plugins, such as:

* Internet Explorer
* Mozilla Firefox
* Adobe Flash
* Java
* ActiveX
* Silverlight

## Exploit URLs

Normally, the only URL you need to care about is the **BrowserAutoPwn URL**. This is the URL
you should send to the targets you wish to attack.

For debugging purposes, you can also see each browser exploit's specific URL path. You can do so
by setting the VERBOSE option to true in msfconsole, like this:

```
set VERBOSE true
```

And then when you run the module, there will be a list showing all the exploits that might be
used, including the URLs.

## Browser Autopwn 2 Options

**The HTMLContent Option**

The HTMLContent option allows you to serve a basic HTML web page to the browser instead of having a
blank one. It supports two syntaxes.

This example will basically print "Hello world!" on the browser while exploits are tested against
it.

```
set HTMLContent Hello world!  
```

This example will load file /tmp/hello_world.html and that's what the browser will see. Most likely
the second syntax is how you'd want to use the Content option.

Keep in mind that you should probably try to keep HTMLContent as simple as possible, otherwise
there is a possibility that it might actually influence the reliability of the exploits, especially
the ones that do memory corruption.

**The EXCLUDE_PATTERN option**

The EXCLUDE_PATTERN option is used for excluding exploit file names you don't want Browser
Autopwn 2 to use. This is a regex type option, you can be creative about this.

For example, Adobe Flash exploits in Metasploit tend to have the same file name that begins with:
"adobe_flash_", so to exclude those, you can do:

```
set EXCLUDE_PATTERN adobe_flash  
```

**The INCLUDE_PATTERN option**

The INCLUDE_PATTERN option is for loading specific exploits that you want Browser Autopwn 2 to use.
Let's reuse the Adobe Flash file name example, if you only want Flash exploits, you can do:

```
set INCLUDE_PATTERN adobe_flash  
```

If you set both INCLUDE_PATTERN and EXCLUDE_PATTERN, the evaluation for INCLUDE_PATTERN will kick
in first, followed by EXCLUDE_PATTERN.

**The MaxExploitCount option**

The MaxExploitCount option is for specifying how many exploits you want Browser Autopwn 2 to load.
By default, it's 21. But you can try to bump it up a little bit if you wish to try more exploits.
Note that by doing so you are also allowing more lower ranking modules to kick in, you will have
to figure out the sweet spot for it. An example of setting it:

```
set MaxExploitCount 30 
```

**The MaxSessionCount option**

The MaxSessionCount option is for limiting how many sessions to get. It may sound a little odd at
first because why would you want to do that, right? Well, a use case for this is when you don't
actually want to pop shells, instead you just want to know what exploits could be used, this is
something you can try. You can also use this if you don't want your attack to stay open the whole
time:

```
set MaxSessionCount 10  
```

**The ShowExploitList option**

The ShowExploitList option means displaying a list of exploits specific to each browser/client.
As we've explained before, when BAP2 loads 21 exploits, probably not all 21 will be served to
the browser, only some of them. In order to see those ones, you need to set this option:

```
set ShowExploitList true
```

**The AllowedAddresses option**

The AllowedAddresses option is for attacking a specific range of IPs as a way to avoid penetration
testing accidents. For example, when you send a malicious link to a specific person, that person
may actually share it with his friends, family or other people, and those people aren't your
targets so you shouldn't hit them. Well, Browser Autopwn doesn't know that, so one of the ways to
avoid that is to create a whitelist.
 
The option also supports two syntaxes. This is most likely how you will set it:

```
set AllowedAddresses file:///tmp/ip_list.txt  
```

The above will load file ip_list.txt. In that file, one IP per line.


**The ExploitReloadTimeout option**

The ExploitReloadTimeout is for setting how long BAP2 should wait before loading the next exploit.
By default, it's 3 seconds, but in case some exploits need more time (for example, longer time to
groom the heap, load other things, or it's doing a sleep somewhere), you will need to set this.
In most cases, you shouldn't have to.
 
Here's an example of setting it to 5 seconds:

```
set ExploitReloadTimeout 5000
```

## Scenarios

By default, Browser Autopwn 2 goes through the entire exploit module tree, and will try to use
different types of exploits - Firefox, Internet Explorer, Adobe Flash, Android, etc. If you want to
test a specific application, basically all you need to do is setting the
INCLUDE_PATTERN option (or maybe EXCLUDE_PATTERN).
 
However, there is another trick to make this task even easier. BAP2 also comes with the following
resource scripts that can automatically do this:

* bap_firefox_only.rc - For testing Firefox
* bap_flash_only.rc - Fore testing Adobe Flash
* bap_ie_only.rc - For testing Internet Explorer
* bap_dryrun_only.rc - Rickrolls the target, and shows you all the suitable exploits against that target. No exploits will actually be fired.

Here's an example of using bap_flash_only.rc to test Adobe Flash vulnerabilities:

```
$ ./msfconsole -q -r scripts/resource/bap_flash_only.rc   
```

## Logging

In addition, when a browser connects to BAP, this link-clicking event is also logged to the
database as a "bap.clicks" note type. If the ShowExploitList option is set to true, that will also
save the exploit list information so that after testing you can go back to the database and see
which users are vulnerable to what exploits.

Even if you don't set the ShowExploitList option, the logged link-clicking event data is more than
enough to prove that the user was social-engineered, which is still a security risk.

To see all the bap.clicks events, in msfconsole do:

```
notes -t bap.clicks
```

From there, you can do additional analysis of these notes, put it on your report, and hopefully
do something about it.