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:
netstat -a -n
Proto Local Address Foreign Address State
TCP 0.0.0.0:21 0.0.0.0:0 LISTENING
TCP 0.0.0.0:23 0.0.0.0:0 LISTENING
TCP 0.0.0.0:25 0.0.0.0:0 LISTENING
TCP 0.0.0.0:80 0.0.0.0:0 LISTENING
TCP 0.0.0.0:135 0.0.0.0:0 LISTENING
TCP 0.0.0.0:443 0.0.0.0:0 LISTENING
TCP 0.0.0.0:445 0.0.0.0:0 LISTENING
TCP 0.0.0.0:1025 0.0.0.0:0 LISTENING
TCP 0.0.0.0:1028 0.0.0.0:0 LISTENING
TCP 0.0.0.0:2203 0.0.0.0:0 LISTENING
TCP 0.0.0.0:3389 0.0.0.0:0 LISTENING
TCP 0.0.0.0:5000 0.0.0.0:0 LISTENING
TCP 192.168.1.3:23 192.168.1.2:50310 ESTABLISHED
TCP 192.168.1.3:139 0.0.0.0:0 LISTENING
TCP 192.168.1.3:2203 192.168.1.2:50312 ESTABLISHED
TCP 192.168.1.3:3389 192.168.1.2:1656 ESTABLISHED
TCP 192.168.1.3:5000 192.168.1.1:53023 ESTABLISHED
TCP 192.168.1.3:5000 192.168.1.1:55782 ESTABLISHED
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]).
ServiceDisplayName=HXD Service 100
ServiceDescription=powerful NT rootkit
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.