A while ago I gave a presentation / workshop on evading anti virus using multiple techniques. This was the agenda:

  • Common pitfalls
  • Lab prerequisites
  • AV detection methods
  • Signature evasion
  • Heuristics evasion
    • Packers / Crypters / etc
    • Payload transformations
  • Building your own evasion
    • Meterpreter loaders
    • Shellcode executers

You can download the slides here, keep in mind that the goal of the presentation / workshop was to give the attendees a broad overview and some pointers so that they could continue researching the subject themselves. A last addition to the presentation is a POC script to split files while maintaining a valid PE.

An IP whitelist is one of the many measures applied to protect services, hosts and networks from attackers. It only allows those that are on the IP whitelist to access the protected resources and all others are denied by default. As attackers we have multiple obstacles to overcome if we want to bypass this and not always will it be possible. In my personal opinion there are two situation in which you will end up as an attacker:

  1. You are NOT on the same network as your target
  2. You are on the same network as your target

In the first situation you will (generally speaking) not be able to access or influence the network traffic of your target. This in turn enables the TCP/IP mechanisms to be useful and prevent you from accessing the resources, although maybe not prevent you from discovering who is on the whitelist.

In the second situation you will (generally speaking) be able to access or influence the network traffic of your target. This enables us as attacker to identify as well as bypass IP restrictions, by manipulating the TCP/IP protection mechanisms, to gain access to the protected resources.

For both situations there is an often overlooked detail which is: how do you know which IPs are on the whitelist? Mostly it is just assumed that either you know that upfront or discover that due to a connection being active while you initiate your attack. In this blog posts we’ll discuss the two situations and describe the techniques available to identify IPs on whitelist which have no active connection. A small helper script can be found here.

Read the rest of this entry »

YARA for pentesters

Posted: December 25, 2017 in general

YARA is a pattern matching swiss army knife often used by malware researchers. The strength of YARA is to quickly and easily identify files based on rules which are mostly aimed at identifying byte patterns. This aides malware researches, threat intelligence and forensic investigators to identify malware samples.

We can of course use the same approach to identify files containing juicy information which like always will hopefully aid us to pwn some network somewhere. Most of the files that we use like ntds.dit/registry hives reside at fixed location or at the bare minimum at configurable locations. This usually causes us to write pretty awesome scripts to retrieve and process these files to get the juicy info. YARA can be a nice tool to account for the unexpected events of system administrators placing these and many other files in unexpected locations.

To start with the end result, let’s see the results of searching for file with passwords (loosely used to also identify hashes) inside a directory:

sudo yara -r -t hashed_passwords juicy_files.txt /etc
shadow_file /etc/shadow
shadow_file /etc/shadow-

and if we do this inside a directory which contains some test files:

yara -r -t hashed_passwords juicy_files.txt files
shadow_file files/shadow
hive_file files/mysecurity
hive_file files/mysam
hive_file files/system
ntds_file files/ntds.dit
hive_file files/mysystem

Like you can imagine you can use this approach to search entire filesystems at once as well as network shares. Since the rules are very powerful and easy to write I think it’s much easier to maintain a repository of rules instead of custom scripts for each juicy file that we encounter during our pwnage. You can find the repository over here, feel free to commit more rules :)

Lately I’ve had to deal with setups which had transparent full disk encryption and were pretty hardened. If you are wondering what ‘transparent full disk encryption’  means, that’s how I call solutions that encrypt your hard disk, but don’t require any interaction from the user to boot into the operating system. They usually accomplish this because they:

  • use secure boot and a TPM with key sealing (good)
  • they use proprietary software-only obfuscation to hide the key (bad)
  • use an external hardware device to store the keys without secure boot or key sealing (bad)

Most of the time the goal is to break out of a preconfigured application and the usual tricks like these ones, don’t really work:

However getting access to safe mode / start up repair does partially work for some of these setups:

Partially, because most of the options were not present and those that were present only gave me a cmd.exe which was disabled with a local group policy. An interesting approach the defence side took was replacing explorer.exe with an executable which did nothing. Even if you managed to break out of their application you still had nothing, no desktop, no menu, no buttons etc. For a few setups where the ‘startup-repair’ options seemed to work the encryption drivers did not load, resulting in an environment with no access to the target disk. In case you were wondering about network attacks, those were a no go as well, since the firewalls were strictly configured for ingress and egress traffic, based on ip/port/application and yes the connection themselves used TLS with client certificates and not vulnerable to man in the middle attacks.

Usually when I encounter these environment it still is possible to perform a variety of Direct Memory Access (DMA) attacks using tools like inception or pcileech. In these cases however this was physically not possible, either because there were no DMA ports available or just because I didn’t have the correct hardware with me to perform the attacks.

A common issues with all those setups however was the fact that the disk encryption software did not seal the encryption keys to a hardware security device like a TPM. This enables an attacker to create an image from the hard disk and boot this image on another computer. If the attacker also got a hold of the enclosure (USB key, smart card, obfuscated algorithm, unencrypted partition) holding the encryption keys it becomes possible to boot the disk image and fully control the victim disk in an untrusted environment.

In this blog article we are going to have a look at some of the things that you can do when you can boot a disk image of an otherwise unpenetrable environment. Please keep in mind that in part we are reinventing the wheel for two reasons:

  • Learning the nitty gritty details
  • Having a portable and understandable solution

There are solutions available that probably would enable you to achieve the same result, but for my personal taste I prefer to have something much more lightweight that can be easily ported between QEMU versions. Additionally you could also achieve the same result with the quick & dirty approach of booting the image in VMWare, pausing the machine, editing the memory file, resuming the machine. However I prefer QEMU since it allows full control over the entire process, due to the build in GDB server as well as customising the inner workings by editing/adding code and recompiling it. The following existing projects already wrap QEMU with cool and handy features if you want to use these type of setups to analyse malware or other applications:

Enough introduction of what we are going to do, let’s dive in and start elevating our shells to SYSTEM ;)
Read the rest of this entry »

Re-evaluating how some actions are performed can sometimes lead to new insights, which is exactly the reason for this blog post. Be aware that I’ve only tested this on two ‘test’ networks, so I cannot guarantee this will always work. Worst scenario you’ll read an (hopefully) out-of-the-box blog entry about an alternative port scan method that maybe only works in weird corner cases. The source for the script can be found on my gist, if you prefer to skip my ramblings and jump directly to the source.

One of the things I usually do is sniff traffic on the network that I am connected to with either my laptop or a drop device. At that point the output of the ifconfig command usually looks similar to this:

 eth0 Link encap:Ethernet HWaddr 00:0c:29:4b:e7:35 
 inet6 addr: fe80::20c:29ff:fe4b:e735/64 Scope:Link
 RX packets:386316 errors:0 dropped:0 overruns:0 frame:0
 TX packets:25286 errors:0 dropped:0 overruns:0 carrier:0
 collisions:0 txqueuelen:1000 
 RX bytes:390745367 (390.7 MB) TX bytes:4178071 (4.1 MB)

Like you will notice the interface has no IPv4 IP address assigned, you can ignore the IPv6 address for now. Normally I determine which IP address or MAC address to clone based on the traffic that I captured and analysed previously. Then I’m all set to start port scanning or performing other type of attacks.

This time however I wondered what type of activities I could perform without an IP address. I mean it would be pretty interesting to talk IP to devices, somehow see a response and not be traceable, right? So I decided to see if it would for example be possible to perform a port scan on the network without having an IP address configured on my network interface.

Since usually when you want to perform non-standard, weird or nifty tricks with TCP/IP you have to resort to raw sockets I decided to directly jump to scapy to build a POC. My working theory was as follow:

Normally when I am just sniffing traffic I see all kind of traffic that gets send to the broadcast address, so what if we perform a port scan and we specify the broadcast address as the source?

I decided to test this using two virtual machine (ubuntu & Windows 10) with the network settings on ‘NAT’ and also tested with the same virtual machines while bridged to a physical network. The following oneliners can be used to transmit the raw packet:

pkt = Ether(dst='00:0c:29:f6:a5:65',src='00:08:19:2c:e0:15') / IP(dst='',src='') / TCP(dport=445,flags='S')

Running tcpdump will confirm if this works or not, moment of truth:

tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
23:27:21.903583 IP (tos 0x0, ttl 64, id 1, offset 0, flags [none], proto TCP (6), length 40) > Flags [S], cksum 0x803e (correct), seq 0, win 8192, length 0
23:27:21.904440 IP (tos 0x0, ttl 128, id 31823, offset 0, flags [DF], proto TCP (6), length 44) > Flags [S.], cksum 0x03be (correct), seq 3699222724, ack 1, win 65392, options [mss 1460], length 0
23:27:24.910050 IP (tos 0x0, ttl 128, id 31824, offset 0, flags [DF], proto TCP (6), length 44) > Flags [S.], cksum 0x03be (correct), seq 3699222724, ack 1, win 65392, options [mss 1460], length 0
23:27:30.911092 IP (tos 0x0, ttl 128, id 31825, offset 0, flags [DF], proto TCP (6), length 44) > Flags [S.], cksum 0x03be (correct), seq 3699222724, ack 1, win 65392, options [mss 1460], length 0
23:27:42.911498 IP (tos 0x0, ttl 128, id 31829, offset 0, flags [DF], proto TCP (6), length 40) > Flags [R], cksum 0x1af8 (correct), seq 3699222725, win 0, length 0

wOOOOOOOt!! It seems to work. We can clearly see the packet being sent to the ‘.178’ IP address from the broadcast (.255) source address and then we see the response flowing back to the broadcast address.

Now that’s pretty interesting right? Essentially we can now perform port scans without being really traceable on the network. Somehow this still feels ‘weirdish’ because it just works on first try…so still thinking I missed something :/

sudo ./ipless-scan.py 00:0c:29:f6:a5:65 -p 445 3389 5000 -i eth0
2017-10-26 23:13:33,559 - INFO - Started ipless port scan
2017-10-26 23:13:33,559 - INFO - Started sniffer and waiting 10s
2017-10-26 23:13:43,568 - INFO - Starting port scan
2017-10-26 23:13:43,604 - INFO - Found open port - 445
2017-10-26 23:13:43,628 - INFO - Found open port - 3389
2017-10-26 23:13:43,645 - INFO - Found closed port - 5000
2017-10-26 23:13:43,654 - INFO - Finished port scan, waiting 5s for packets
2017-10-26 23:13:52,626 - INFO - Stopped sniffer

A good periodic reminder when attempting to learn things is that reading about the subject is not the same as actually practicing the subject you read about. That is why it’s always a good thing to practice what you have read. In this case we are going to dive into the well known Java deserialization bugs that have been around for a while now. The best part of practicing it is that you get to really know the subject at hand and can attempt to improve upon it for your own needs. For this blog post we are going to attempt the following:

  1. Exploit a deserialization bug
  2. Manually create our payload

So to clarify, step one will be about practicing the exploitation of a serialization bug with current tools as well as explaining the approach taken. The second step zooms in on the payload; what exactly is the payload? How can we construct it by hand? With the end result of fully understanding how it works as well as having an approach to understand similar bugs in the future.

I’ll mention all tools used throughout the blog post, but at the very least you’ll need the following:

That is the bug we will be exploiting. The reason for choosing a simulated bug is the fact that we can control all aspects of it and thus better understand how a deserialization exploit really works.

Read the rest of this entry »

There are a ton of ways to brute force login forms, you just need to google for it and the first couple of hits will usually do it. That is of course unless you have Burp in which case it will be sufficient for most of the forms out there. Sometimes however it will not be so straight forward and you’ll need to write your own tool(s) for it. This can be for a variety of reasons, but usually it boils down to either a custom protocol over HTTP(S) or some custom encryption of the data entered. In this post we are going to look at two ways of writing these tools:

  • Your own python script
  • A Greasemonkey script

Since to write both tools you first need to understand and analyse the non-default login form let’s do the analysis part first. If you want to follow along you’ll need the following tools:

  • Python
  • Burp free edition
  • Firefox with the Greasemonkey plugin
  • FoxyProxy
  • FireFox developer tools (F12)

Please note that even though we are using some commercially available software as an example, this is NOT a vulnerability in the software itself. Most login forms can be brute forced, some forms slower than others ;) As usual you can also skip the blog post and directly download the python script & the Greasemonkey script. Please keep in mind that they might need to be adjusted for your own needs.

Read the rest of this entry »