The fallacy of ‘manual work’ being faster

Like many people, due to recent events, I’ve had more time to reflect on myself and on some of my mistakes. I’ve always been a fan of sharing knowledge, that includes failures and the things you learn from them. So here is one of those failure from which upon self reflecting I’ve learned to change that behavior.

Sometimes you already knew something was true, but you just kept lying to yourself. This is even worse when you have recommended other people to do what you still refuse to do yourself, because you keep lying to yourself. The recommendation is good, the part where you don’t follow your own recommendation, that’s where it all goes down the drain. If you are wondering what I’m talking about, I’m talking about:

Doing all kinds of tasks manually, because in that precise moment it was the ‘quick’ option

The above is what I’ve been doing for the last couple of years, mainly because during my day job my work is less technical. This is the wrong approach, even if I told myself otherwise. The interesting part is that during this time I coached and advised people around me to:

  • stick to (further) learning programming languages
  • Learn devops
  • Take the time to automate and learn how to automate
  • Don’t worry about being slow now, it will pay off

So why then, did I not follow my own advise? Because besides the reason of it being quicker to do manually, I also told myself that by doing it manually it would be easier to retain technical knowledge.

Now this blog has turned up two fallacies:

  • Thinking that doing it manually is quicker
  • Thinking that by doing it manually you retain knowledge

Both of them are incorrect, that much is obvious, but why?

The first one is incorrect because the moments that warrant that ‘quickness’ in that precise moment are not as many as you’ve been telling yourself. My experience is that in a lot of cases it was perfectly fine to grab a couple of hours or a day or two to automate it. I actually experienced this, since other people with the exact same problem took the advise and automated it. They could later indeed benefit from their work and the more often that they automated tasks, the faster they could do it.

The second one is incorrect, because in a sense you are training yourself to:

Re-learn the same knowledge over and over again

Instead of learning something, documenting it and being able to go back to it. You are learning something, doing it by hand and then forgetting it. Yes you might retain some of it, but eventually it will fade. So if you need to do it again, you need to re-learn it again instead of referencing it and building upon your previous knowledge. I knew this all along, since I often went back to older scripts and code I wrote. I just never took the time to keep doing that when my day job diminished the amount of time I spent on technical problems. Somehow the reward of doing something fast in that precise moment, was bigger than automating it and reaping the benefits. The illusions and tricks the mind plays on you are truly magical.

To get myself going again, I decided to automate a thing I’ve been doing manually for the last couple of years, which is configuring a newly installed Ubuntu VM. The ansible setup is not perfect, but at least I’ve begun to automate it:

https://github.com/DiabloHorn/env-automata

I hope that other people in similar situations benefit from this self reflection and that they don’t fall for the same fallacy.

vysolator: vyos virtual network isolation

Sometimes projects are just born out of pure frustration, this is one of those projects. I’ve probably build like a dozen VyOS configurations to virtually isolate networks and virtual machines on my host. I  briefly touched upon this subject a couple of years ago when I wrote about stashing ESXi inside VMware workstation to achive a portable lab. Since then I’ve build multiple versions, to either ensure that Red Team operations and regular penetration tests are able to contain the breach to a single virtual machine or to enable training networks with multiple networks and clients. If we visualize a simple setup it looks like this:

This compartmentalizes potential breaches to their own segment. In this case each segment has a single VM, but it could contain multiple VMs. Yes, the virtualization layer becomes a single point of failure. I still think it adds value from most attacks that you could suffer. Including the usual surfing the internet and getting pwned one.

So here is a repo which contains the instructions and example config file to get you (read: most probably future me) started. The current setup ensures that you have one mgmt segment and one internet only segment. That means, you can manage your VyOS from the mgmt segment if you place a VM in it. You can browse the internet and nothing else if you place a VM in the internet only segment.

Whenever I build more segments that lend themselves to be of generic use I’ll update the repo. Feel free to send pull requests with either alternative configurations or improvements and segment expansion on the current one. @donnymaasland, already had a sneak preview and submitted some improvements. You can view the historical commits to review the improvements as well as some personal preferences on rules.

On and yes, I do agree that Qubes OS is a superior solution, however this is more versatile. Also this does not have the same threat model that Qubes OS has. For those wondering about the threat model for this, here is a quick summary of it / the intended features:

      • Contain regular breaches to a single segment
      • Protect against regular attacks
      • Not intended to withstand targeted or advanced attacks
      • Avoid user mistakes by enforcing network ACLs from a central system
        • Improve ease of use by just requiring users to place VMs in the right segment
      • Aid Red Team / Pentest to not fuckup when they have to use specific exit IP addresses

Lessons learned on written social engineering attacks

I’ve had some interesting conversations on the topic of performing social engineering attacks via email and decided to share some of my past lessons learned. The focus will not be so much on the technical side as it will be much more focused on the social aspect. Although much of today’s written social engineering attacks are carried out using email, there are other written communication methods which can and should be used depending on your objectives.

The social aspect for me concerns the journey from the moment the victim receives the email until the moment that your objective is achieved. Whereby the objective often relates to infecting the victim it could also involve having the victim send you some documents or perform other actions. The victim’s social journey is something that can be influenced, but in my experience it is not something that you’ll fully control.

When I started out with attacking organizations and individuals I was often under the impression that everything should work on the first try. This of course is not true. What is true, is that you should assume failure and put some thought and effort into the consequences. One of the more important lessons I learned early on in regards to performing social engineering via written media is:

It really doesn’t matter, nobody cares.

Have you ever looked at your own communication? have you ever worked in a SOC or followed up on incidents? Eventually most companies as well as victims are pretty tired of the endless stream of shit that they receive on a daily basis. So yes, there will be investigations, they might even follow-up on your attack, but then what? It’s not like they can block all senders or block the entire internet or forbid their employees from working and talking to potential customers, partners, vendors right? So yeah, you guessed it right, if you mess up:

You get to try it again, and again and again…

Of course there are some exceptions like when you really mess up and they figure out you’ve been hired to attack them or if you technically have a ‘tell’ which would enable them to block all incoming attacks pretty quickly. Although…how would they block you across all possible communication channels that their employees use?

Anyhow I’m getting ahead of myself, let’s talk about some war stories and I hope you learn as much as I did from them. As usual I garbled up a lot of information, timelines and other details to attempt some anonymization. Oh and yes, the technical part of these attacks eventually matters, specially if you have to get some code execution, but with the proper social engineering context this can sometimes become much, much easier to perform.

Continue reading “Lessons learned on written social engineering attacks”

Old Skool Red Team

Today I stumbled upon the tweet from Dominic Chell which was about this article that he wrote. This triggered a feeling of nostalgia of the era during which red team was still not a very familiar term with most of the clients. This triggered me to write up the story of a red team that I participated in around ~2010. To ensure that some details remain hidden, I’ve mixed in a couple of techniques from other red teams that I participated in around the same period. Although I’d almost bet that the gaps in my memory are enough to obfuscate the most important details :P

You might be wondering, why write up something old and probably with zero relevance to the actual state of defense today? The reason is exactly that, to hopefully provide insight in how clients and technology have evolved to make it more difficult for adversaries not only to get in, but to remain undetected. In addition I hope that the mistakes that we made back then enable other people to learn from.

If you feel that you are suddenly hoping that you would have done red teams back then, don’t feel sad. There is a big probability that in another ~10 years you will look back and think: Whoa, red teaming was pretty easy around ~2019.

If you enjoy stories from the past, keep on reading.

Continue reading “Old Skool Red Team”

Secure slack bot; An exercise in threat modeling

secure, that’s one of those words that is capable of triggering a (usually negative) physical reaction with most people working in the security industry. Thing is, whenever someone claims secure, they usually forget to mention against what kind of threat(s) it is secure. So every once in a while I like to attempt to build something that is secure against a chosen threat model, just for the fun of the mental workout.

This blog will be about the exercise of performing a threat model of a slack bot I might build. It will not contain instructions on how to implement it, it will just be my train of thought while doing a threat model for the solution I want to build.

Most of the times it ends in the project not being finished or if I finish it people point out all kind of security issues in the solution. The latter being the main reason that I like doing these type of projects, since I’ve come to realize that somehow when you are designing a secure solution on your own, you will always end up with blind spots. While if you where to look at the same solution without building it you’d be spotting those exact same security issues. Thus you learn a lot from attempting to build a secure solution and have some else shoot some nice holes in it.

This time I decided to build a simple slack bot that would be capable of receiving a URL to an online Youtube video and download it for offline consumption. After some thinking I came to the following definition of the slack bot being secure:

    • Hard target to casual and opportunistic attackers
    • Hard target for memory corruption vulnerabilities
    • When breached, constraint the attacker to pre-defined resources

So basically I want the solution to be secure against a curious user that uses the bot and decides he wants to hack it for the lulz. In addition when the attacker succeeds, I want that the attacker is only able to view / modify the information that I consider expendable. You’ll notice that I’m saying ‘when the attacker succeeds’ and not ‘if the attacker succeeds’. This is due to the fact that I always assume it will be breached, thus forcing myself to answer the question(s): “what’s the impact? can I accept it? if not, what should I mitigate?”. The other reason is of course that I’m a terrible sysadmin, and I expect myself to forget to patch stuff :( Besides the security requirements I also wanted to learn something new, so I decided I wanted to develop the bot using go.

So how do you proceed to design something with the above requirements? Normally I just perform a threat model-ish approach whereby I mentally think of the assets, attacks and the corresponding security controls to mitigate those attacks, sometimes with the aid of a whiteboard. This time however I decided to give the more formal drawing of a threat model a go. So i searched around, found this awesome blog and after a short while of (ab)using draw.io I ended up with the following result:

Initial threat model
Initial threat model

Let’s dive into this diagram and see how to further improve the security controls or security boundaries.

TL;DR Threat modeling is a fun and useful mental exercise and aids in spotting potential attacks you might forget to secure against. Also it is 2019, we should be using seccomp and apparmor or similar technologies much more frequent.

Continue reading “Secure slack bot; An exercise in threat modeling”

Notes on ZFS / Solaris forensics

A while ago I wrote a script to perform what I called poor man’s forensics. The script was meant as a way to utilize the native operating system to extract some minimal data from exotic filesystems to be able to create a timeline and identify possible abnormalities. As a reminder to myself here are some additional raw notes, commands and resources on performing (forensic || incident response || compromise assessments) investigations on ZFS / Solaris environments. I encountered ZFS / Solaris during some of the FoxCert investigations I participated in.

These raw notes are by no means complete and you must definitely not follow these blindly and always ensure you are working on a copy of a copy of a copy of the real evidence.

Continue reading “Notes on ZFS / Solaris forensics”

Introduction to physical penetration tests

Depending on your personality the concept of being legally allowed to break into places has a kind of mythical ring to it. You’ve seen it happen in movies and series like James Bond, Mission Impossible, Leverage and a dozen others and you might have wondered is that how it really happens in real life? On some level you already know that the movie depictions are not that close to reality. Why? Mostly due to all those other stories of regular burglary where the break-in is much less sophisticated, yet very effective.

In this blog post I’m going to try and give an overview of physical penetration tests and how to start doing them from my own perspective (European context, we have to worry less about guns). In addition I will focus on the type of tests where a target asks you to ‘casually’ break in and gain access to a room, plant a device or steal some specific information. ‘Casually’, what does that even mean? In my experience it means that you get one or two days for your preparations and one day to execute the attack. Doesn’t seem like a lot, but you’d be surprised how many targets can be breached with minimal preparations, some courage and the fact that you aren’t really going to jail when caught ;)

I’m also no expert on this subject, so feel free to leave corrections as well as additional tips, tricks and personal experiences in the comments. Lastly, not all physical penetration tests will be the ideal take 4 weeks to do your thing type of job. So I consider it good practice to also be able to perform these type of smaller jobs where thinking on your feet is almost mandatory, not to mention fun if you like to practice your improvisation skills.

Before I forget, this information is mostly for your general running off the mill big corporation with standard security and where the target is just interested in an attacker that doesn’t invest a lot of time in the attack. Don’t attempt to access high security facilities with minimal preparation. Even though it might succeed, you will most likely strand at the first door or person that you attempt to bypass.

Continue reading “Introduction to physical penetration tests”

Introduction to analysing full disk encryption solutions

I’ve written a couple of times on the subject of boot loaders and full disk encryption, but I haven’t really explored it in more detail. With this blog post I hope to dive a bit deeper into how to actually start performing these type of analysis and why they are useful to perform. I’ll start with the usefulness first and then go into the part on how to do it, but will not be fully reversing a disk encryption boot loader. I won’t be doing a lot of hard-core reversing like finding vulnerabilities within the cryptographic operations or reversing custom filesystem implementations, but hopefully provide enough information to get started in the area of reversing unknown boot loaders.

The type of products with which you can use the approaches and techniques described in this blog post are the most useful when applied to full disk encryption (FDE) solutions that are configured to not require pre-boot authentication. The reason being, that you then could potentially obtain the disk decryption key. If the solution requires pre-boot authentication, the information that you can obtain, might be reduced to meta-data or ‘deleted’ files. Which brings us to the whole, why are these type of analysis useful?

The reason of why this is useful, I didn’t fully realise until a couple of years ago when a colleague introduced me to the wonders of all the (hidden) information that FDE solutions may contain. Let’s look at the type of information that you may encounter while investigating these solutions:

  • (encrypted) Hidden file systems
  • (obfuscated) Encryption keys
  • Usernames
  • (hashed/encrypted) Passwords
  • Windows domain credentials
  • Configuration information of the FDE solution
  • Files marked for deletion
  • Finding 0days and bypassing encryption

Based on the above list of items we can pretty much conclude that analysing FDE solutions is useful from an offensive as well as from a defensive point of view. It can either help us to breach a target network or obtain sensitive information as well as collect forensic evidence or aid us into understanding the specific cryptographic implementation to enable us to decrypt the disk and analyse it. The helper tools I’ve used in this blog post can be found here. Keep on reading if you want to know the rest of all the details and the process I usually follow. I’ll try to describe the following steps:

  • Creating a (partial) copy of the disk
  • Analysing the disk
  • Static & dynamic boot analysis

Since I don’t have easy access to disk encryption software with the exact features I’d like to analyse I’ll be using DiskCryptor as an example product.

For some reason it seems that the products with the most interesting features to reverse engineer have a horrendous ‘request trial’ process as well as not providing trials to a random researcher on the internet :( sad panda :(

The other reason to use DiskCryptor is the fact that it is open source, thus enabling people that want to get started with type of stuff to more easily understand difficult snippets of assembly. My personal approach to a lot of reversing challenges usually revolves around finding a similar open source variant first or finding the open source components used in the proprietary solution if applicable. Reason being that it makes your life a lot easier to understand not only general concepts, but also specific code quirks. A very nice explanation on finding as much information as possible before your start reversing is given by Alex Ionescu in his offensive con keynote ‘Reversing without reversing’.

Oh and there is no specific goal, besides just explaining my general thought process. As a side note I am no reverse engineering expert, so feel free to correct me :-)

Continue reading “Introduction to analysing full disk encryption solutions”

Remote NTLM relaying through meterpreter on Windows port 445

The hijacking of port 445 to perform relay attacks or hash capturing attacks has been a recurring topic for a while now. When you infect a target with meterpreter, how do you listen on port 445? A few weeks ago this topic resurfaced again in part due to Dirk-jan (@_dirkjan) that saw this question flying by in the #bloodhoundgang slack channel and asked me to look into it. This sounded like fun to figure out and he promised that if it worked, he’d document a working setup that would be able to perform SMB relay attacks through meterpreter. Turns out, this is an already solved problem with readily available tools out there, but not a lot of people are aware about the solution.

We will explain how you can leverage these tools to perform relay attacks on a target on which you have a meterpreter session. The added benefit of this approach is the fact that you don’t need python2exe or a whole python stack on the infected host, just a simple driver and a meterpreter infection will do the trick.

The first part of this blog will focus on the thought process of being able to hijack port 445 and the second part of this entry will focus on making it usable for relay attacks. If you want to skip the thought process and relay setup you can also skip directly to the already available solution:

The rest of this entry is divided into the following sections:

  • Who is the owner of port 445?
  • Hijacking and redirecting port 445
  • The full SMB relay setup through meterpreter

Please note that we took the easy route while writing this blog post and just put all the files on the disk. If you want to avoid that we suggest that you use a ram disk solution or expand the current meterpreter in-memory execution functionality to support something similar to this.

In addition there is a high probability that you either have to recompile the source of the solution statically to ensure you won’t be needing additional DDL files or you’ll have to bundle those DLL files. All this is however left as an exercise to the reader ;)
Continue reading “Remote NTLM relaying through meterpreter on Windows port 445”

Creating a ram disk through meterpreter

The magical ‘in memory execution‘ option of meterpreter is of course one of the better options that we as attackers love to use. However if you want to store ‘random files’ in memory or need to execute more complex applications which contain dependencies on other files, there is no ‘in memory’ option for that as far as i know. To be more specific, on Linux you can do it with build in commands, on Windows you need to install third party software (list of ram drive software). I decided to dig into it and see if I could achieve this through a meterpreter session. The reasons for wanting a ram disk are multiple, if you are still wondering:

  • store stolen data in memory only, until you can move it
  • execute applications which require multiple files
  • running multiple legitimate files from memory

You might be asking, why not use it to bypass AV? This is of course possible, but you would need to modify the driver for this to work and ask Microsoft to sign it. To bypass AV there are enough methods available in my opinion, I sometimes just want to be able to store multiple files in memory.

Where to start? I decided to start with the ImDisk utility for two reason:

  • It is open source
  • It has a signed driver

The first reason allows me to better understand the under the hood stuff, the second reason allows me to use it on Windows versions that require a signed driver. First thing I tried is to use the bundled tools, but it seems that the command line interface has a dependency on the control panel dll file. I tried a quick recompile, but then I thought, why not code my own version? The original version includes, amongst other things, the ability to load and save the ram disk as an image file and for the moment I won’t be needing that functionality. So i decided to code my own reduced functionality version of the original client. It would have been easier to just use the original client, but this was more fun and thought me a thing or two about driver communication.

The original source code was very very clear, which made it a breeze to hack together some code to talk to the driver. I still need to add way more error handling, but for now it does the job and you can use it through meterpreter. Be aware of the fact that it still leaves traces on the regular hard disk, like explained in this blog. A short overview of the traces left behind:

  • The dropped driver
  • The registry modifications to load the driver
    • The driver loading does not use a service, thus there is no evidence of a service creation
  • The mounted ram disk
  • Traces of files executed or placed on the ram disk

For me the benefits of having an easy way to execute multiple files from memory outweigh the above mentioned forensic artefacts. In addition it becomes more difficult to retrieve the original files, unless the incident response team creates a memory image or has access to a pre-installed host agent which retrieves the files from the ram disk. Let’s get practical, here is how to use it through a meterpreter session (I won’t go into details on how to obtain the meterpreter session):

Continue reading “Creating a ram disk through meterpreter”

Presentation: Understanding & avoiding AV detection

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.

Identify a whitelisted IP address

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.

Continue reading “Identify a whitelisted IP address”

YARA for pentesters

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 :)

attacking encrypted systems with qemu and volatility

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 ;)
Continue reading “attacking encrypted systems with qemu and volatility”

Port scanning without an IP address

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
 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
 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='172.16.218.178',src='172.16.218.255') / TCP(dport=445,flags='S')
sendp(pkt,iface='eth0')

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)
 172.16.218.255.20 > 172.16.218.178.445: 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)
 172.16.218.178.445 > 172.16.218.255.20: 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)
 172.16.218.178.445 > 172.16.218.255.20: 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)
 172.16.218.178.445 > 172.16.218.255.20: 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)
 172.16.218.178.445 > 172.16.218.255.20: 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 172.16.218.178 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