- Linux news and help for home broadband internet users
 Home | Files | Case Mods | Reviews | Forum | Search | Links | RDF | Contact | Uptime | Server Info | Tracker

Installation Guide
Setting Up
Internet Sharing
Port Forwarding
Services Config
Installing Programs
Game Servers
Using IPTables
Useful Commands
Kernel Upgrading
System Recovery
Red Hat 7.2 Setup
OpenBSD Setup
BPA Login Setup
PPPoE Setup
Add New Hardware
VMware ESX Cmds
Our RC5 Team
Help Support Us

Linux Security
NetStats FAQ
Linux KIS Trojan
CAT5/LAN Cables
Domain Names
Presario RH Install APC Debian DVD
  • Vim 9.0 Released
  • Former Top Apple Lawyer Pleads Guilty To Insider Trading
  • SQLite or PostgreSQL? It's Complicated!
  • Government Policies Will Not Get UK To Net Zero, Warns Damning Report
  • Gartner Predicts 9.5% Drop in PC Shipments
  • The Really Important Job Interview Questions Engineers Should Ask (But Don't)
  • Webb Telescope Will Look for Signs of Life Way Out There
  • Mickey Mouse Could Soon Leave Disney As 95-Year Copyright Expiry Nears
  • BioNTech, Pfizer To Start Testing Universal Vaccine For Coronaviruses
  • Crypto Platform Vauld Suspends Withdrawals, Trading Amid 'Financial Challenges'
  • Hacker Claims To Have Stolen Data of 1 Billion Chinese From Police
  • Microsoft Finds 'Raspberry Robin' Worm in Hundreds of Windows Networks
  • A Library of Books No One Can Read For 100 Years
  • Texts and Web Searches Have Been Used to Prosecute Women for Abortions
  • Berlin Builds a Giant Thermos to Help Heat Homes This Winter

      Kernel Intrusion System (KIS) Trojan

      The following information was posted by redlander in our forums, the origin of the information was from the SecurityFocus/Linux mailing list (if you want to sign up for the mailing list then visit this site This is a definite must read for anyone who runs a Linux machine.



    This document 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.

    1. Introduction
    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.

    2. Description
    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.

    By issuing 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.

    3. Operation
    The KIS trojan is inserted on a victim host by executing a binary that installs the trojan, and loads the KIS trojan kernel module.

    The trojan 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.

    During loading, the KIS kernel module performs several tasks:

    • Conceals the Modules Presence by Removing the Module from the modules_list structure.
    • Replaces key system calls.
    • Replaces portions of the vfs structures for the net/tcp, net/udp, and net/raw files in the procfs.
    • Spawns a kernel_thread to process incoming commands from the network.
    • Replaces the ip_packet_type structure with a new structure to allow KIS to monitor all ip based network traffic and add observed commands to queue.

    Commands are 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.

    The queue manager takes a queued command off of the queue and performs the directed command.

    Valid commands include:

    • Execution of A Process
    • Hiding a running process
    • Revealing a hidden process
    • Hiding a file
    • Revealing a file
    • Hiding a connection
    • Revealing a connection
    • Ping
    • Shutdown 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 of 0.80.

    Additionally, 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.

    4. Risk
    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.

    Despite the 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.

    5. Detection
    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.

    On systems 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:

    During normal operations (i.e., runlevel 3 or 5)

    • "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.
    • Repeated runs of "init", such as switching between runlevels or rebooting will cause the system to hang, generate error messages or crash.
    • Portscans on the system reveal open and listening ports that are not reflected in a netstat.
    Alternatively, 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 files.
    find / -name ht -mode 000 -print

    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

    6. Cleaning
    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.

    Using this 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.

    Tim Lawless

    Proudly Hosted By:
    Hosted by PEBKAC Consulting

    Please read our Legal Notice for information concerning our site and its content.
    All logos and trademarks in this site are property of their respective owner. All the rest © 2000 - 2016 by


    D-Link DI-704P
    VIA EPIA-M 9000
    Tux Applique
    Ricoh MP5125A
    AMD XP 2600+
    3DProphet 9000Pro
    Radeon 9700 Pro
    XTNDAccess IrDA
    Netgear FS-524s
    DSR2161 KVM
    Game TheaterXP & XPS-510 Speakers
    3D Prophet 4000XT
    AutoView 400
    Back-UPS CS 350
    Dual Neon Kit
    SwitchView KVM
    20x4 LCD Kit
    Window Kit

    XML error: Attribute without value at line 2.
    Google Search
    Enter Keywords:

    Bash Jokes

    % [Where is Jimmy Hoffa?

    Missing ].

    Virtualization, Virtual Machine & Virtual Server Consolidation - VMware

    The Community ENTerprise Operating System

    Get Slackware Linux


    Use Asterisk