Egress Checking

Most penetration testers have, at one time or another, had the need to measure or circumvent egress firewalls; internal audit exercises and some internal penetration tests are good examples. For the purposes of simplicity, assume that there is an opportunity to execute code on either a Windows or a UNIX machine; the next stage would be to effectively 'portscan' your machine's IP address from the compromised machine in order to find out which ports can be used to egress data. This technique could be applicable during a simulated attack; the problem is that it is not stealthy by default.

This is not a new problem; there are a large number of scripts and tools designed to meet this need and the majority do this very well. This tool aims to improve on the principles on which the other tools have been built, offering a few additional features in a slightly more user-friendly way. I wanted a tool that could offer something for both windows and UNIX systems, that would present the commands and tools to run as one-liners, could offer both TCP and UDP, that could take advantage of native tools on the client, that could format the results and does not require me to immediately kill all my existing listeners.

This tool comprises two main components:

• Generating packets on all ports in a given range, which would be run on the compromised host (the client). For example, assume that the client's address is 10.0.0.1.
• Measuring which connections were made to your machine (the attacker). For example, assume that your IP address is 192.168.0.1.

On the basis of the example above, this tool will allow you to connect to 192.168.0.1 on each port from 10.0.0.1, and let you see which connections were successful, which effectively will identify gaps or breaches in firewalls. The basic approach is to:

• Generate a 'one-liner' that can be run on the client. Currently, ECF can generate one-liners in python and powershell, but I'll add other scripts in the fullness of time.
• Use tcpdump to monitor connections to your machine. ECF will print the command that you need to run to perform the necessary capturing and filtering. If used in TCP mode, it just looks for SYN packets. Tcpdump will be configured to save the filtered capture file.
• Parse the tcpdump file, from which the results can be displayed in a number of formats, useful for other tools or simply for reporting. Currently, tshark is used as a pcap parser; ECF provides the parameters to pass to tshark.

Regardless of the scripting language used, code that is generated by this framework will generate packets according to the following routine:

• The metadata (target IP address, port range, number of threads etc. to use) will be 'hardcoded' into the script. The script is semi-dynamically generated based on the parameters provided.
• If THREADS is set to 1, this effectively means that threading will be disabled and the code that manages threads will not be included.
• If THREADS is greater than 1, the script will import a threading library if necessary, divide up the ports to be scanned between the threads and launch all of them.
  • For example, if all ports between 10 and 20 were included and 4 threads were configured, the script would assign the 4 threads to scan the following ports:
    • Thread 1: 10, 14, 18
    • Thread 2: 11, 15, 19
    • Thread 3: 12, 16, 20
    • Thread 4: 13, 17
  • Each thread will loop through the requested ports and, depending on the configuration, will attempt to connect() (for TCP) and sendto() (for UDP). If both protocols are requested, the script will attempt the TCP connection first, followed by the UDP scan. In the example above, Thread 1 will connect to TCP/10, UDP/10, TCP/14, UDP/14, TCP/18, UDP/18 and then exit.
• The main script will exit once all threads have completed and will block until then. However, sockets are created in non-blocking mode, meaning that it runs very quickly.

EgressCheck is interactive; you will be presented with a prompt at which you can type commands. Each command is listed below, along with notes about it for additional information.

Syntax: get [option]

This command will list the various options that can be set. Typing 'get' on its own will list all values.

Typing an option name will display the value of that option only.

The options are summarised below.

Where it makes sense, the parameters are tab-completable.

Syntax: set [option] [value]

The 'set' command is used to change one of the options above. When setting an option, ECF will display the option name, a '=>' symbol and then the option value below it, for confirmation. Examples:

If you attempt to set an invalid option, you will see an error message. For example:

Where it makes sense, the parameters are tab-completable.

Syntax: generate [format]

The generate command is used to produce the connect-back scripts to run on the compromised hosts, and to produce example tcpdump and tshark commands in order to capture and filter the connections on your machine. The available formats are tab-completable and currently comprise:

The table below summarises the capabilities of the currently available client-side scripts (i.e. those that generate the egress traffic):

Whenever the generate command is run, the relevant output will also be written to a temporary file to make it easier to transfer, execute or audit the scripts. For example, running 'generate python-cmd' will generate the one-liner and include a statement to the effect of:

The format of this name is:[type-of-file]_[year][month][day]_[hh][mm][ss]_[random].[extension] I have deliberately specified the month as a short name instead of a number to avoid the confusion over whether the date is in US format or UK format. The temporary files are not cleaned up after ECF exits; this is deliberate because it gives you the opportunity to hash or audit the files if needed as evidence during a simulated attack or other penetration test.

The egress code will use non-blocking sockets and, when configured without delays and multiple threads, covered the full range of ports (1-65535) in both TCP and UDP in just over 11 seconds.

When this code was run on the target machine, the execution completed in 11.255 seconds. The packet capture on the source machine was analysed which showed the connections being received.

An artificial delay of 100ms was configured and a new python one-liner was generated and tested. I have left this as a default simply to be a bit kinder to the target machine. However, I have tested this (without a delay) on a number of different systems and networks and have not noticed any problems.

With this delay, the script completed in just under 4 and a half minutes.

• The compromised machine is 10.0.0.1 which runs Linux.
• Your machine is 192.168.0.1.
• You want to identify egress opportunities from 10.0.0.1 to 192.168.0.1 across all 65535 TCP and UDP ports.

On your machine:

On your system, run the tcpdump command provided by the 'generate tcpdump' directive:

On the compromised system, run the python one-liner:

Once the script has finished, go back to your machine and close tcpdump. You can then parse the pcap file to extract the TCP and UDP connections that were received. This was tested on a test network that permitted egress on TCP ports 21,80,443,8080 and UDP ports 161,53447 and blocked all others:

This can then be formatted using basic UNIX tools either for injection into other tools or for reporting. For example:

There are a number of different approaches that others have implemented and that I've tried. However, I have had mixed results from them. One tool used scapy to sniff packets; despite being a very elegant approach, I found that it did not seem to capture all packets. Another tool worked by opening up listening sockets on a large number of ports on your machine, and monitoring connections to them. Nothing wrong with it, but you can't do too many at once, and I wanted a solution that would sniff the packets (meaning that you may not have to drop your software firewall, nor would you need to kill any existing listeners that you have). Geoff Jones' Egresser (https://github.com/cyberisltd/Egresser) works by using iptables to redirect all traffic to a single port, and 'reflecting' traffic on that port. I couldn't use it natively because FreeBSD doesn't have iptables (but pf/ipf/ipfw could all be used in its place), but it was that tool that inspired me to build on the idea and I owe him a shout out for it. Do bear in mind that his tool works slightly differently in that the client side tool aggregates the results (based on the server effectively reflecting them); ECF relies on the server storing a packet capture which can then be parsed offline. Egresser arguably gives a truer picture because it shows bidirectional TCP traffic and you could rely on a "normal" TCP C&C channel from that. ECF will assume that egress is possible on receipt of a SYN packet; I have come across IDS systems that allow SYN packets through but block the actual data which is why I adopted this approach as an alternative. Using tcpdump has a few other benefits too; for example, it does not require listeners to be set up. In addition, this technique could easily be used on machines several layers deep on a target network. If access to a machine has been compromised through a pivot with sufficient privileges to dump traffic, internal egress could be assessed too.

Not really. You can configure a delay between packets being generated if you want to. I've tried to keep the client code (one liners) as small as possible; they really are very simple scripts.

It is as accurate as it reasonably can be; remember that your host is simply capturing incoming SYN packets (for TCP) and incoming UDP packets and, if they match the source and destination IPs, displaying them. It can't tell for sure whether the packets were generated by the helper script or not but, if the packets arrive at your host, perhaps it is not important how they were generated. This will be inaccurate if there are intercepting proxies or traffic managing such as NAT in place; there may be egress channels which will not be immediately obvious from the results of this script.

Yes in that it is, at heart, very basic. There are two parts; a client (which generates traffic) and the listener (on which you can run tcpdump). If you run the tcpdump code on your own host and run something else which generates traffic to you, tcpdump will faithfully record the traffic which is received regardless of the tool used to generate it. It is certainly not designed to replace other scripts; it was built to meet a need that could not be directly met by publicly available tooling.

Penetration testers looking to identify egress channels during engagements and system administrators who wish to audit their systems to test the basic effectiveness of their firewall configuration. I hope it is of use to someone.