Cautionary Tales: Stealth Coordinated Attack HOWTO
by Dragos Ruiu <dr@netsentry.net>
Wed Aug 25 1999

This article was originally published in Digital Mogul Volume 2-7, July 1999. Copyright 1999 uberbabe media inc. All rights reserved.

A lot has been written in the popular media about the effects of hostile coordinated traffic attacks (hacking), and, as a sysadmin, I find my systems increasingly under attack by hostile sources. Two years ago, we got mapped and port-scanned for vulnerabilities once a month. One year ago the scan frequency was up to once a week, and these days we get scanned several times a day with real attack attempts at least once a week. The Internet is becoming an increasingly hostile place and the traditional defenses and documentation of attack systems seems woefully inadequate.

With this article, I hope to remedy some of the false misconceptions of security that some admins have. Yes, I hope that descriptions of these attack techniques scare you into beefing up security on your home PC, at your office, everywhere. Over the last fifteen or so years, as a sysadmin of network connected systems, I have seen the knowledge of computer technologies propagate across the spectrum of human population, bringing with it the traditional demographic including the stupid people, the malicious people as well as the helpful and the apathetic people.

With the burst of Internet technology over the last few years there has also been a burst of new computer adoption, increasing pervasiveness of computing and networks and increasing occurrences and danger/damage caused by hostile computer use. While I don't believe for a second the over-inflated, hyped-up estimates of the cost of these hacker intrusions bandied in the media, I can vouch that the problem is real. As the chief technical weenie of our company, NetSentry Technology, I've been manning the front line defenses of our company net equipment.

I've also been documenting the increasingly hostile nature of attacks on our network and would like to share some of my experiences in this area. The technical level of the attacks is increasing at an alarming pace, and I haven't seen any documentation of these new attack techniques yet, so here are some cautionary tales culled from our real-life experiences. My hope is that after reading this you will re-examine your own network security. Most organizations are woefully under-protected.

The ISPs are having increasing difficulties in responding to customer requests for assistance in intrusion cases and the police are even further under-staffed and out-gunned technologically. So increasingly, it leaves companies to fend for themselves to secure their systems. Here is what you have to worry about.

I wish I could take credit for all the techniques described here, but a majority of them were derived from analysis of traffic used for hostile attacks on us. Credit belongs to the anonymous hackers that have taken a run at our defenses. I write the following from the point of view of the attacker to emphasize the point that security is vastly neglected at most sites and because I want to ask, what will you do when faced with these attacks? And what can you do with your current defensive equipment? Not much, I wager.

The phases of a successful attack are A) Reconnaissance, B) Vulnerability identification, C) Penetration, D) Control, E) Embedding, F) Data extraction/modification, and G) Attack relay.

A) Reconnaissance

The first part of a successful attack is to get to know the network topology in the region surrounding your target and the parties it communicates to. This is also an important part of the penetration of each successive layer of your target's networks. Currently, the best publicly available tool for net topology identification is Fyodor's excellent "nmap" program and derivatives. The objective of the reconnaissance is to understand as much about the target and to identify attack destinations defenses and potential attack relay bases.

In private circulation, the following tools exist or will soon exist:

Attack Tool: Coordinated multi-site scanners. Mapping software that distributes the mapping "probe" packets to be sent to the destination addresses and nearby sites over a number of geographically dispersed attack sites, and trickles them out at low rates to avoid detection so that there never is a lot of traffic at any one time or from any particular site (see stealth section). The results of the pokes and probes at the target that these systems send is summed and collated to build a picture of what equipment the target has installed.

There was a lot of noise in the press earlier this year as some of the crude versions of these coordinated scan tools were aimed at US military sites, but either the operators of these tools have improved them to the point where the relatively immature military defense systems no longer identify these scans, or the military has found some other threat to highlight in the press and use to get funding.

Attack Tool: Sniffer Detectors. Sniffers produce unique traffic patterns that may be detected. They also provide some interesting penetration vulnerabilities, as their network interfaces are placed in promiscuous mode, allowing all packets past the address filters to be processed by network stacks and applications. Some attack methods directly target security systems, which, ironically enough, are often notoriously insecure themselves.

Once the security system is penetrated, all kinds of nice information like traffic patterns and passwords may be gleaned, and evidence of your attacks can be conveniently removed. And because of promiscuous listening in the sniffer you can even take it out with traffic destined for a different system.

Attack Tool: DNS Zone transfer. A DNS zone lists the externally accessible points a company maintains. A nice map of the externally visible systems that your target has put on the Internet and a great attack point list. Not many sysadmins go over the name server records closely enough to detect this, however the more advanced intrusion detection systems are getting better at identifying these kinds of transfers as pre-cursors to an attack.

The important information to gather is the DNS names and addresses of the target's hosts and neighbors. Then you must further identify the OS and open port configuration of each of your target's systems. The latter is determined using site scanners and analyzing the responses that a site delivers. Current tools such as "nmap" and "queso" are getting very good at determining device, OS version and some network application configuration information from careful analysis of the timing and contents of responses to probing or mapping traffic. The OS and port configuration are used to identify systems that could have software packages with vulnerabilities and bugs open for exploits.

Knowing who your target's ISPs are by analysis of address use can provide useful attack bases for your onslaught. Getting into their ISP's equipment and servers first could enable you to get important information about them and if you can subvert equipment installed on the same network links as your target can let you glean important information such as traffic patterns of your target. All without your target even suspecting. It may also be easier to penetrate the ISP than a secure target. Some ISPs such as @Home even keep extensive (but often out of date) databases listing customer's hardware and software configurations as well as other info, which if accessed can mitigate some of the dangers of triggering intrusion detection systems with your site scanning traffic.

Once the traffic patterns of the target's external traffic are known, a basic technique to take out a secure target is to first take over a less secure target that your main target talks to, and then come in to your main target under the cover of that site's usual traffic. Any site your target talks to periodically, including popular web sites, employee's dial-up accounts, and system traffic, such as network time protocol (NTP) clocks, are all candidates for attack relays.

Sprinkling in your attack traffic with large web downloads and ftp transfers will make it more difficult for security personnel to use sniffing and detection tools to identify your attack, as scrolling through reams of logs and captured data can often be more time consuming than possible with most network staffing levels. Taking out and controlling your target's conversation peers can provide you with useful channels through your target's defensive firewalls and detection systems. Your traffic will look on all the scanners like that web-site the Joe in IT is surfing to, but will provide you with a nice channel right past all the firewalls to a machine inside the core of your target's net.

One useful target is the DNS caches and servers that your target uses at your ISP. Accessing the DNS logs can give you the addresses of all the sites that your target talks to, and furthermore, careful analysis can even give indication of when the activity happened, or is happening, offering excellent potential for cover.

As we'll talk about later, owning the DNS server can have many benefits. In general the DNS servers are ripe with hacking opportunities.

Another useful target is the ISP DHCP server, which is used to dynamically assign IP addresses to clients on connection, as it can be used to identify periods of system activity from the logs, and also periodically establishes connections to the client systems as the address leases expire. A common DHCP vulnerability also allows client system takeover from this ISP host. DHCP address lease expiry also provides a nice way to signal embedded attack software at pre-determined times to do things like wake up in the middle of the night and send data when no-one is looking.

An often available source of useful relay bases for attacks is other systems in the same ISP client pool (on the same modem bank, other ADSL users on the same DSLAM, or cablemodem users on the same segment), which are in many cases default configuration, open like Swiss cheese, Windows systems - typically with file-sharing turned on and personal web services enabled, a combination that sports a plethora of available vulnerabilities to exploit. After taking out the easy "marshmallow" soft client PC, the adjacent main target can then be attacked using local subnet attacks, offering again some potentially powerful techniques for hiding from and exploiting your target's security systems.

In easy cases, the equipment rack will bridge broadcast traffic between the "marshmallow" and the target, allowing use of address resolution traffic such as ARP and DHCP to be used for system attacks and control. For stealth, these kinds of attack bases are excellent too, because the broadcast traffic is largely repetitive, very voluminous, and mostly uninteresting, which, combined with a great immaturity among the security tools for this kind of traffic, make it a ripe vulnerability area. Local area broadcasts can also be used as another "mapping" system too, even in passive listening to traffic at the nearby "marshmallow". By recording the address lookup broadcasts from your target, you can build up that traffic pattern information so that you can sneak into the site undetected.

Another often overlooked source of mapping and reconnaissance information (and break-ins) is the management systems the ISP may be maintaining. The Simple Network Management Protocol (SNMP) that most of these systems use is a bit too simple and is ripe with vulnerabilities, rich with information (including complete remote sniffers useable to pick up passwords in some RMON MIB equipment) and lame about security.

The most powerful relay base for attacks is the ISP's router system. Once you control the paths of your target's packets, you really have them at your mercy, as you can silently redirect any of their traffic to your attack relay bases without them knowing, and other fun tricks. However, most ISPs guard their Ciscos and other routers as the most valuable resource with the most defenses, so this is really a target for the most daring and brilliant attacks.

B) Vulnerability Identification

The objective of the mapping phase is to find externally accessible traffic paths into your target's net systems. Over the last year it has been easy to see what are the most popular scriptware for the so called script-kiddies: the low-tech, mostly teen, hackers who just download pre-compiled exploits and run it blindly against targets. The standard script-kiddy technique is to set up a broad address sweep broadcast of probe traffic, to the whole section of the Internet that seeks some sort of response from the target, that would indicate that software is installed with the vulnerability the exploit is using.

The classic vulnerabilities that we frequently see sweeps for are:

* FTP Server Exploits. Especially vulnerable are servers with
anonymous write access.
* NFS and SMB share vulnerabilities.
* Holes in POP and IMAP mail delivery servers.
* Vulnerabilities in the "bind" name daemon software.
* Web server CGI exploits (Apache, MS IIS).
* Installed control daemons such as BackOrifice.

The scans for these holes are so common these days that it is difficult for most sites to even catalog origins of such scans. These kinds of scans are so commonplace that, as long as traffic volume and frequency is controlled, it is possible to conduct them with relative impunity. But the attacker has to be prepared for the case of zealous sysadmins who contact ISPs and complain about port-scans. Never port-scan from a node you are not prepared to have disconnected, seized or otherwise lost.

Here, the best policy is to use the least useful and network connected systems in your attack fleet of controlled systems as they may be lost or jammed and blocked by firewall software when the hostile mapping probe traffic is detected. Mapping traffic stands out like a sore thumb when pointed at systems not running the vulnerable software - if the target has the tools to analyze this kind of attack (i.e. Abacus Sentry). If attacking a net-savvy sysadmin, he will be able to detect things like IMAP probes against servers not running mail software. However, even these days, targets with effective intrusion detection systems are few and far between. And sysadmins with enough time to examine, properly and frequently, all their logging systems are even fewer.

At the sites that have management and security systems, these are ripe targets too. Penetrating the security system has the best advantage of rendering the target effectively blind. I have seen experienced sysadmins dismiss unquestionable, hard evidence of tampering because their beloved and trusted, but thoroughly compromised, security sniffer shows them that there is nothing to worry about - or doesn't even show that kind of data at all. The other factors in the attacker's favor are the egos of the network designer and IT group.

Every sysadmin thinks their defensive plan is carefully thought out and "their" system couldn't possibly be penetrated. Here at NetSentry we used to contact operators of systems that had been compromised and were now being used for attacks against us. But after many hours of fruitless attempts to convince maintenance personnel, who, if you did reach them, often didn't even understand the attack traffic their own site was launching, insisted that it "couldn't possibly be our system, it must be your equipment or monitors that are wrong."

I remember very vividly one ISP we contacted: when we were watching, in pretty much real time, as the attackers were compromising system by system at their site and using each as a base for attacks against us, how their support person and security specialist looked at some local system when we called and decided that we couldn't possibly be correct.

An hour later, as the ISP's systems being used as attack relays switched from probing to all out denial of service flooding and attacks, we called back and everyone had happily gone home for the night there. We never did bother to call them again and as far as we know the attacker still owns all their systems. The only guys who really took one of our attempts at warnings seriously was the security department at a regional bank, who came in on a Saturday to put sniffers on the line - but they were a notable exception.

The best targets are those that are the most widely known, used, and difficult to take off-line or re-locate. Mail, DNS, Web and FTP servers all fall into this category. With these servers, sites that notice suspicious traffic will often not off-line them because they are critical to network operations. And even if they take them off line and restore them from backup, or otherwise keep you out, they are often forced to bring the servers back with the same vulnerability as was available for initial entry because user complaints about the unavailability of network resources override the attempts to identify and close the hole.

Like penetrating the sniffer and management systems, the mail servers also provide excellent opportunities at invisibility, by letting you monitor internal conversations, what aspects of the intrusion have been detected and what countermeasures are being mandated.

C) Penetration

The most successful hack is the one where the target doesn't even know it has been penetrated. The next best thing is that when the intrusion is detected, they won't know where it's coming from. Since the source may be detected, it's better to use attack relays so the attacker's anonymity can be maintained. The general technique is to quickly find some clueless newbie who has put his home system or office server on the net with major vulnerabilities, and use that as a relay. Never use a system with your name or organization attached to it to attack.

Use several levels of indirection and make sure you cross several geographical and political boundaries to hide your trail. ISPs in the same country often will not share log information and this gets even more difficult across borders. I listened with sympathy when I heard a poor overworked security colleague who works for the Canadian RCMP describe the nine month process (!) for the paperwork to request log files from U.S. ISPs. The police and ISP security departments often have their hands tied by procedure and policy and general understaffing. The more organizational and geographic boundaries that your attack redirection trail can cross, the more safe and anonymous you will be.

People complain about the lack of anonymity on the net, but for those that cross that line into unauthorized systems use, there is altogether too much anonymity. It's often almost impossible to follow a chain of connections through multiple ISPs and countries. The hidden are truly anonymous on the net. Sysadmins should give up now on the romantic idea that you will be able to track down who is attacking you - it's just another bunch of random numeric addresses, and even if you trace it down to an ISP, their logs will only point to another ISP and so on.

If the attacker can knock out the target's intrusion and sniffing facilities then you can proceed the rampage though their network with relative impunity, but even if you don't have the technology to compromise such systems, there are a number of techniques you can use to make your attack more stealthy.

Attack Tools: Firewall tunnels. There are a wide variety of virtual private network and proxy programs, which you can use to relay your traffic to inside a protected network and not make the traffic appear on an intrusion detection system. Literally dozens of such firewall "borers", such as HTTPtunnel, are available now in source and binary form. These tunnel programs relay your traffic through the firewall and IDS systems by making it look like innocuous transfers to and from your "mole" system to common web-sites and other forms of traffic "chameleoning" to make it look unexceptional. These tunnels embed your attack and control traffic inside this relatively innocent looking traffic to seem like HTTP or partial TCP fragments. These tunnels can also encrypt your traffic, making it more difficult for your target to identify the penetration methods.

Most sites employ hard-shell, layered network security. That is to say the links external to the organization have firewalls and net proxies to restrict access to the inside network. The standard technique is to have a hardened Demilitarized Zone (DMZ) made up of firewalls and security IDS systems. The most secure sites will have multiple servers and systems dedicated to these roles, but the majority of installations often rely on one inadequate server for this gatekeeper function. And once you are through this shell, which is checked most often by maintenance personnel, you are usually into the internal network that has almost no security.

Another often overlooked security breach is to use floppy based Linux distributions such as the Trinux project, or client software for common Windows and NT systems, to carry in such a tunnel program physically into the organization where it can be surreptitiously installed on a system inside the "hard" shell. This "mole" or tunnel can then penetrate the security from the inside where vulnerabilities are seldom checked. From this attack relay base, you can proceed to scan the internal systems and take over other servers, further embedding your control of their infrastructure.

Firewalls are hardened quite well these days. But even so, some firewall operations can be predicted and broken, in areas like the port number sequences of outbound connections. With predictable sequence number connections, firewall connections can be hijacked and attack sequences passed through the defenses. And while firewalls are often tough, many sysadmins make mistakes and leave vulnerabilities open on the host the firewall runs on (like running Microsoft IIS on the firewall), allowing penetration and access to both the internal and external Ethernet interfaces on the box for malicious software to bridge packets between the two. Once the host with network interfaces on both segments is penetrated, packet hijack software can grab the packet and relay it to the other interface before the firewall software even sees it, essentially providing you with an invisible back-door into the target.

Some forms of firewall penetration do not even involve bypassing the firewall. One interesting attack technique it to identify frequently visited sites by the target, taint the DNS database with a forged update to their DNS server or cache so that the next time the target client contacts the frequently visited site, the traffic is pointed to one of your attack systems instead. This attack relay system can conveniently embed your attack exploit in relayed copies of the original web site. With modern Java enabled browsers, the client naively executes any code the supposedly well known site, which is in reality your attack relay, sends. The data is sent in response to a client's request through the firewall and walks right past the intrusion detectors, virtually indistinguishable from ordinary data. This attack mode is also available by taking over the target ISP's router or DNS server.

Other forms of stealth involve penetrating SNMP traffic statistics or nearby systems at their ISP or other peer clients to identify traffic activity. The design flaw of the Internet that makes identifying forged source addresses a difficult problem can also let you hide the origin of the attacks (so called "spoofing"). If attack traffic is sent from (or spoofed to look like) a source that is currently sending a lot of data to the target, it makes it that much more difficult to spot the attacks.

This buries the attack packet amongst reams of other voluminous data. It quickly scrolls the attack packets off the screen of sniffers and makes network security staff at the other end go through the tedious "find the needle in the haystack" procedure of sorting and filtering megabytes and megabytes of capture data if they suspect the attack. Most of the time they will not have the patience to exhaustively search for attacks by scrolling though the captures and logs, again rendering you invisible.

After penetration, further attack software can be embedded in ordinary traffic to transfer it into the target's systems. Patience is the key here. The lower the data rate that can be used to get the information in and out, the lower your chances of being detected are. Spreading out your packets, so only a few per hour are transmitted, makes your hack very difficult to detect with today's tools. (However, we have developed some special tools to counter this kind of attack.)

One of the more devious penetration methods we observed was a system that trickled data in and out in the normally unused padding at the end of user data packets. On normal sniffers and detectors, the packets looked completely innocent, as even those tools did not display the padding "garbage" used for the hack. This padding was used to install malicious software by trickling the attack executable into the target a little bit at a time, a few bytes with every packet.

Another interesting stealthy attack system that will negate most firewalls is to embed your hacking control channel for your attack bot software and results and information back from the bot in addressing translation requests, that by definition need to be passed on by firewalls. One such clever system we experienced was an attacker who penetrated another nearby client node on an ADSL system. They then penetrated one of our systems (a sniffer of all things) and installed a key-stroke logger that encoded the keystrokes typed at the console into the address field of Address Resolution Protocol (ARP) lookup messages, which were happily passed through the firewall and relayed to the attacker at the nearby system outside the firewall on the same subnet that received the ARP encoded keystrokes.

This key logger even delayed, encrypted and grouped keystroke transmissions to make detection more difficult. We have also seen keyboard loggers that were clever enough to store your keystrokes on disk, in case the system was disconnected from the network (like a laptop) for a while and then trickled them out later when the net connection was re-established. Key loggers provide easy access to most authentication tokens, scrambling keys and passwords.

The basic form of penetration is to use stack smashes which take advantage of basic low level coding bugs in a piece of applications software or an operating system component. The form of a stack smash exploit is to utilize a data coding that allows variable length data that you send to be erroneously copied into fixed length buffers or variables, and writing into data past the end of the buffer. Since this data can overrun the stack, you can overwrite a return address for the currently executing function and make the processors CPU jump to and execute arbitrary code of your choosing. If the bug exists in a privileged piece of software, these instructions that you jump to are virtually unlimited, allowing you to do literally anything with the penetrated computer.

The problem with this form of attack is that it often requires detailed knowledge of the operating system and memory map of the target. Often this form of attack will have to be coded in multiple ways to account even for the version of OS and software package being penetrated. The drawback for the attacker and the advantage for the defender is that usually stack smashes involves "groping" around blindly, sending multiple variants with different offsets and values until the appropriate magic version number that works correctly and responds back is found. In some cases an incorrect variant can crash software and systems, necessitating lots of patience and long time delays between variants tried.

A common target for stack smashes are recent and older variants of the "bind" name daemon that is in almost universal use to translate from symbolic DNS names and URLs into numeric IP addresses. The code and traffic structure of this program is very complicated, difficult to debug and ripe with vulnerabilities and bugs. One 17 year-old hacker managed to take over more than 12,000 systems over two years - before he was caught with an automated "bind" takeover worm.

Another common form of attack is to exploit the increasingly complex and powerful native data types of applications software (especially Microsoft products that often contain several complete programming languages in things like word processors and mail readers). Web server script exploits also fall into this category. The basic technique here is to either hijack an existing connection and inject malicious data or to send unsolicited attack traffic that will take over the application and eventually the system.

D) Control

Once you are into the system and have compromised a piece of software, the next bit of work is to get control of the host. This is usually a bootstrap process, where a piece of small code, "the exploit", is first gotten into the target and the vulnerability is used to execute the code. This code needs to contact one of your attack relay systems and download further code and instructions. The simplest form of bootstrap is to allow remote access to a command shell that can execute arbitrary operating system commands.

There are many forms of bootstraps, as they are often linked to the exploit itself, and some, like BackOrifice, include a whole command interpreter. But those more advanced download a minimum of code and use existing portions of the operating system code to build a remote control system attack bot. These advanced exploits can, in object oriented fashion, build whole parallel network stacks and control systems that run invisibly in the background on the machines using software already installed on the machine.

A portion of the bootstrap process during attack is to restart or patch the application that was crashed so that the intrusion is not noticeable. Other important parts of this process include cleaning up the log files to remove intrusion messages and hiding the attack bot so that it isn't listed in the task viewer or process list. "Scrubbing" the log files can be easily accomplished by recording the file pointers to important log files at exploit time, installing and bootstrapping your attack bot and then "rewinding" the log files to their pre-attack positions to erase any evidence of the installation by overwriting the operating system file pointers in memory with your pre-attack copies. Subsequent log entries will overwrite the evidence of the attack. Log files to be cleaned up include sniffer capture files, system event logs, DNS and other daemon diagnostic files, IDS systems files and file integrity checkers like Tripwire. The good attack bots make log-files almost useless for intrusion detection.

Your attack bot can control the machine up to the privilege level of the software that has been penetrated. It can access any resource that the original software could. In many cases, this will not include super-user "root" or "administrator" privileges and you will need to use another local exploit to break in further. One alternative approach is to download a password cracker and dictionary to be stored in invisible files or unused portions of the disk and let this cracker run in the background on the machine (invisibly off any task list of course), using a brute force search for the password on the same machine. This generates little traffic, and is very difficult to detect by the target, as the machine will work silently to crack the password for you when idle. One such attack system that was used against us used a remarkably compact word-list and a very patient brute force cracker - to good success.

Super-user privileges are not needed all the time. Even in cases where the cracked software has been limited to accessing only a few resources, it is often enough to use the system as an attack relay base. One of our attackers used a "bind" exploit once on a firewall system where we had purposefully confined the non-privileged version of "bind" program to a "chroot" jail that limited filesystem access to a very small subset of files. This didn't stop the sophisticated attacker much, as even the ordinary user privilege "bind" already had permission to access both internal and external Ethernet interfaces and bridge packets between the two to bypass the firewall software.

With careful design, your attack bot can allow you to encrypt, hide, download, remotely install and run arbitrary software packages, and send traffic so that even sniffers installed on the target do not see the packets. It is relatively straightforward to insert and remove packets from the network card, transmit and receive queues, so that normal OS security and logging measures on the penetrated host never even detect the traffic (including bypassing low-level transmit and receive counters). Similarly, it isn't a major technical feat to hide the bot tasks so that they don't show up on system diagnostics. You can completely remotely control a machine and run programs on it, upload and download data, without any indication to the user other than occasional sporadic slowness - which on Windows is almost indistinguishable from normal performance, and Linux and NT aren't much better.

E) Embedding

After you have gotten in and have control of the target, the next step is ensuring that you can retain control even if your actions are discovered. You need to quickly map the local net and penetrate any other system suspected of being a sniffer or key communications links, such as mail servers, to observe any suspicion of intrusion on the part of the target's IT staff.

The next portion of clean up is to trickle in any additional attack code into the target and whatever is needed to make your controlling attack bot install and hide itself on disk. The point here is to allow your bot to survive a system re-boot and retain control so that you do not have to go through the dangerous - and detectable - attack and clean-up sequence again. Several techniques have been observed for doing this. One is to overwrite existing and little used OS files that exist in nice, known predictable places/paths, but are seldom used (the more marginal games that come with OS distributions, and terminal definitions for obscure terminals quickly come to mind for this purpose).

A sophisticated variation on this is to encrypt and spread your binary over many files (sometimes called steganography). Another alternative that requires more low level programming is to use unused, empty portions of local disks. The system then has to be modified to re-enable your bot after rebooting.

A variation on this hidden attack bot is to install a back-door that will lie dormant on the disk and install a small, difficult to detect bot that waits until receipt of a special traffic trigger which will then set off re-assembly from code pieces spread out on disk files and activation of the more powerful attack relay bot. This kind of traffic trigger system could also be used to render the traffic invisible. One attack system installed itself across multiple systems and suspended normal OS operations and triggered execution of the loaded command in the attack bot upon receipt of a multicast trigger.

The OS remained suspended until a time out or reset trigger was received, allowing the exploit to run without any normal security and logging active. By using a multicast trigger, multiple systems can be triggered and momentarily suspended simultaneously, and if the control bot is installed on any sniffer systems, data recording was suspended while the attack bots execute their commands in this suspended state and send their traffic, again rendering the whole attack invisible. Multicast traffic also has the added advantage of being not reported in the default configuration of most sniffers, so unless the IT staff explicitly enables reporting, they will not usually be aware of it. This kind of attack is very difficult to detect unless an operator is paying very close attention to traffic LEDs.

One condition for the attacker to plan for is what happens to your bot if it is discovered. One attacker once used a system that erased itself if it lost contact with the attack relay base for more than a certain period of time, or if the system was re-booted (as would happen when a system gets off-lined because breaches are suspected). In this way any evidence was erased whenever a penetration was suspected.

The Perl language, if installed on the target, provides a nice compact way to download very powerful programs with a minimum of data transferred, and the standard Perl kit includes routines for embedding (hiding) your Perl script into other binaries.

Another clever exploit is to store a piece of your attack bot bootstrap sequence on the network card itself. Most modern network cards have 64 bytes (or more) of EEPROM that are used to store the 6 byte hardware MAC address, leaving the majority of the space unused. More sophisticated server network cards even have more space for downloadable firmware. The mostly unused network card EEPROM is typically loaded by OS drivers in its entirety - usually to a fixed address static buffer. A small segment of code could be programmed into the card and executed from this buffer by an exploit.

The advantages to storing a portion of the attack code in the NIC is that it makes tracing the activity of the exploit difficult for someone trying to reverse engineer the code, and more importantly, a short program installed here will survive a disk formatting and OS re-install. This kind of exploit will lead to a lot of head scratching and questions about "How the hell do they keep getting back in after a disk wipe?" at the target.

F) Data extraction/modification

After you have established control, then you can get on with your nefarious purposes. Typically this will be data extraction and modification on the target system. On Microsoft systems, the registry and Microsoft's own system information utility, enable rapid gathering and dense transmission of key system configuration back to your attack relay. Under Linux, the /proc filesystem provides the most rapid clues as to system configuration, allowing your attack bot to build a summary of what it found on the newly penetrated server and transmit it to the relay.

Important attributes of data extraction and control of modifications for attack bots are to hide and encrypt this data stream. It will be beneficial to spread these transmissions out over several relay destinations and have them happen at low rates. One of the safer, stealthier data extraction systems is to embed the data in HTTP web transfers that make up a large percentage of most site traffic these days. Putting your encrypted data deep into packets and disguising it as JPEG or GIF binary data will help hide it. Most traffic loggers and sniffers usually capture only the beginning of most packets, so embedding your data deep into the packet will make it all that much more difficult to see, depending on what security tools your target is equipped with.

As was mentioned above ARP and DNS also provide methods of hiding your data transmissions. A key piece of information on the path to hiding your attack bot data traffic amongst the target's traffic is understanding your target's traffic patterns. You need to know when, how (what protocol) and who the target is talking to. Both Linux/Unix and Windows come with some pre-made system tools that you can use to record these traffic patterns, without downloading much additional software.

The more sophisticated network cards under Windows come with RMON and other MIBs that can be used to gather traffic pattern information, so that your traffic can be spoofed and modified to look like client traffic requested by users at the target site. RedHat Linux contains many pre-installed mapping tools including arpwatch and SNMP that can be used to monitor local traffic to see what kinds of traffic will likely escape detection. Penetrations of the target's ISP to get traffic stats can be a boon here too.

Another important kind of data hiding is to send your data in little bursts, and follow that data with a burst of legitimate addressing or ARP traffic to scroll your attack data off the display screen of any sniffers in case you encounter a fairly quiet traffic level at the target's system. Doing this kind of data transmission in the wee hours of the morning will also lower the chances that there are any humans looking at status screens at the network control center and noticing anomalies.

G) Attack Relay

The final step in attacking is to successfully use your new system as a relay base for other attacks. Building up a large "fleet" of attack bases is its own reward - with more systems to attack from your subsequent conquests will be more stealthy and difficult to track. But now your target relay site will likely notice if you start port-scanning "trantor.army.mil" or other such contentious targets, so be careful (this is another real-life example scenario used on us here). Most sysadmins will not take kindly to the possibility of getting phone calls from the U.S. military asking why their servers are attacking them. But then again, most won't notice.

Attack-Tool: One clever exploit a hacker used on one of the "honey-pot" decoy systems we use as hacker-bait for analysis was an SNMP triggered attack reflector. This system used two SNMP triggers to effectively hide the out-bound attacks. The first trigger put the system into listen mode. After sending the trigger, the attacker quickly sends a spoofed attack packet containing the attack to the relay system. The spoofed attack packet is coded to look like a packet from the attack destination to the relay.

Upon receipt of the second SNMP trigger and after a delay, the recorded attack packet is sent back to the actual attack target with the original source and destination reversed. In this way the sequence of the attack is seemingly reversed, with the local relay system responding with a single packet after receipt of the single packet from the target. Unless you look carefully on most sniffers and IDS systems, it looks like the target is attacking the relay system instead of the other way around.

A good ploy to avoid detection is to use many different attack relay or mapping systems and to avoid using the same attack relay system twice in the same day or week with a particular target. An isolated packet here and there destined for a strange system will not arouse many suspicions, but repeated transmissions to the same target could possibly trigger off alarms at the relay or target - however unlikely that may be with most sysadmins asleep at the security wheel.

Conclusion

I hope the above attack techniques scare any sysadmins reading this. As they should. Too may people these days feel that security is keeping out the script-kiddies or installing a firewall. There are a lot of nastier things out there on the net than the mindless script-hordes, so beware. I hope you can use this article to justify better security measures to your boss. This stuff is out there - it's been used on us. Odds are these kinds of exploits have been used on you and you have no knowledge of it. There are malicious minds developing new attack bots, and communities of people dedicated to the breaching of security measures. I would even surmise that there are now organized and funded efforts on the part of military and intelligence agencies to further develop such offensive software.

One of these days, organized crime may even wake up to this. As we are discovering, it's the law of the jungle out there on the Net, and there are few places to turn to for assistance in case you get some malicious bozo attacking you. Often you are left to your own devices, and with little support from your own organization, that may be technically illiterate when it comes to network security. The only defense seems to be to stay technologically ahead of the attackers - a constant and resource intensive process. The good news is that it's easier to play defense than offence. Good luck.

P.S. You do have good backups, don't you?