describes the Kernel Intrusion System (KIS) trojan that affects
Linux 2.2 and 2.4 systems. The specific version of the KIS trojan
analyzed is labeled 0.9.
At the Defcon Conference in Las Vegas, NV at 10:00am PST on July
14th 2001, the KIS trojan was published by an individual who is
identified as Optyx. The trojan is designed to automate the loading
of a kernel module. Once loaded the kernel module will attempt to
conceal its presence, and listen to the network for instructions.
The KIS trojan is a hybrid between zombie daemons which came to
light as a result of DDOS attacks on major sites at the beginning
of 2000 and kernel level rootkits that are used by hostile entities
to conceal their presence on a system after a successful compromise.
In its remote
control client, the KIS trojan delivers a similar look and feel
as is associated with Back Orifice or SubSeven.
commands from a remote KIS client, an individual is capable of executing
processes on a victim host while hiding arbitrary files, child processes
and network connections.
The KIS trojan
is introduced into a system in the form of a regular executable
binary that contains the KIS kernel module and the trojan.
The KIS trojan is inserted on a victim host by executing a binary
that installs the trojan, and loads the KIS trojan kernel module.
is installed into the system by replacing the /sbin/init binary
with the trojan. Upon bootup, the trojaned /sbin/init will load
the KIS kernel module and subsequently call the original "init"
binary that has been moved to a hidden directory. This ensures that
the KIS trojan is the first kernel module loaded on the system.
In the testing
of the KIS system, it appears it was designed only to load from
init. Multiple runs of the trojan binary, such as what would occur
if it were to replace /bin/sh or another binary that runs often,
can cause the system to hang, generate "Out of Memory" messages
or become unstable.
the KIS kernel module performs several tasks:
the Modules Presence by Removing the Module from the modules_list
key system calls.
portions of the vfs structures for the net/tcp, net/udp, and net/raw
files in the procfs.
a kernel_thread to process incoming commands from the network.
the ip_packet_type structure with a new structure to allow KIS
to monitor all ip based network traffic and add observed commands
sent to the KIS trojaned system from a KIS client console. The commands
are sent via directed IP packets with a specific length to match
a modulus and remainder defined in the KIS module upon compile.
If the packet
matches the length requirements and decrypts into a valid command
packet, then the command is added to a queue for processing.
manager takes a queued command off of the queue and performs the
of A Process
a running process
a hidden process
and Removal of the Trojan
The queue manager
is always running, monitoring the incoming queue of commands. As
a result, the load on a victim system will never fall below a load
as a result of the replaced system calls and the requirements to
manage hidden files and processes, file system operations such as
listing or even compiling a kernel consume up to 30% more system
time then the victim system would consume in a non-trojaned state.
The KIS system permits a remote execution of processes on a victim
system. Combined with its ability to conceal such executions, files,
and network activity from normal processes, the KIS system provides
a prime platform from which attacks against the integrity and availability
of other compromised systems may be launched.
need to compile a KIS trojan for each kernel, a pre-compiled KIS
trojan could be packaged and distributed to victim hosts that are
running stock kernels.
If such a
pre-compiled binaries were to be included into a RPM or DEB package,
a KIS trojan could be introduced to victim systems by administrators
installing a new or updated package.
The KIS system can be detected on initial load by the St Michael
0.05 Linux Kernel Module. The St Michael Linux kernel module is
a integrity monitor for the 2.2 and 2.4 Linux kernels.
not running St Michael, or that are suspected of being infected
by the KIS trojan, the following observations can be made to determine
if the system is actually infected:
operations (i.e., runlevel 3 or 5)
if the system can be safely brought down and booted off of a clean
or rescue media, search the file system for a file called "ht" with
mode 000. This is the hidden file table used by KIS to list hidden
- "ps -auwx
| grep init" will reveal two "init" processes.
- The system
load will be high, not falling below 0.8 even when all observable
processes are idle or sleeping.
runs of "init", such as switching between runlevels or rebooting
will cause the system to hang, generate error messages or crash.
on the system reveal open and listening ports that are not reflected
in a netstat.
find / -name ht -mode 000
Also, the trojaned init process is copied to a file in the same directory
as the original init binary, but named "init."
find / -name init\. -print
Additionally, to determine if files are hidden by KIS or any other
trojan the following method may be applied:
1. Boot the system normally. Generate a file list via:
find / -type f -print > listing.1
2. Boot the system into single user mode using 'clean' media such
as a rescue disk. Mount all the filesystems (i.e., on /mnt)
find /mnt -type f -print |
sed -e "/\/mnt//g" > listing.2
3. Diff the two listings to determine the hidden files
diff -u listing.1 listing.2
To remove KIS, the trojaned init binary needs to be replaced with
a clean init binary or the original init binary.
The original init binary is stored in the same directory that the
ht file is stored in. There are two files that are named similarly:
"init." and "init".
"init" is the original init binary.
"init." is a copy of the trojan.
Copy the "init" file over the trojaned init file:
cp init /sbin/init
The "ht" file will contain files and directories that are hidden.
These files may contain information about the attack and what the
trojaned system was used for.
If the source
for KIS is recovered, the server.h file will contain the keys, modulus,
and remainder needed to communicate with the KIS server.
information it may be possible to sniff the network, identifying
packets that are sent in attempts to contact the KIS server. In
some circumstances, such as with the PING command, the origin IP
address will likely not be spoofed.