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

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
  • Privacy Complaint Targets Google Over Unsolicited Ad Emails
  • Psychedelics Help People With Alcoholism Drink Less
  • Japan Signals Return To Nuclear Power To Stabilize Energy Supply
  • Korea Shatters Its Own Record for World's Lowest Fertility Rate
  • New Aluminum-Sulfur Battery Tech Offers Full Charging In Under a Minute
  • New York State Bill Would Require Speed Limiting Tech In New Cars
  • Notorious DRM Company Takes Aim At Switch Piracy
  • Hackers Are Breaking Into and Emptying Cash App Accounts
  • New Film 'BlackBerry' To Explore Rise and Fall of Canadian Smartphone
  • Chattanooga, Tennessee offers America's First Community-Wide 25 Gig Internet Service
  • California To Ban the Sale of New Gasoline Cars
  • Experts Warn of Widespread Exploitation Involving Hikvision Cameras
  • Google Pixel Sees Huge Sales Growth, Has 2% of North American Market
  • Bay Area Startup Wants To Make Call Center Workers Sound 'White and American'
  • Biden is Canceling Up To $10K in Student Loans, $20K For Pell Grant Recipients

      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

    % nice man woman

    No manual entry for woman.

    Virtualization, Virtual Machine & Virtual Server Consolidation - VMware

    The Community ENTerprise Operating System

    Get Slackware Linux


    Use Asterisk