Na primeira geração dos rootkits, foi enfatizada a manipulação de comandos dos sistemas operacionais, mudanças que atribuíam funções diferenciadas ou inadequadas ao comando original. Durante um considerável período essas manipulações foram consideradas eficientes aos olhos dos desenvolvedores dos malwares, porém, uma atitude satisfatória também foi aderida pelos programadores e administradores de sistemas.

Essa atitude implantava sistemas auditores nos comandos e programas que compunham o Kernel, eles procuravam atuar baseado na data de modificações dos comandos e tamanho dos arquivos, o que acabou inibindo e impedindo a atuação desse tipo de rootkit. Um exemplo clássico da atuação desse tipo de malware foi descrito por MARCELO, A. (2003) no livro Segurança em Linux, o qual procurou detalhar a atuação de um Rootkit, este modificava o comando ifconfig, fazendo com que as interfaces de redes atuassem em promiscuidade, captando dessa forma tudo o que circulava na rede. O autor ainda comparou a essa situação com um sniffer, que tem praticamente a mesma função, ou seja, aplica o modo promiscuo a um equipamento que tenha características semelhantes a uma interface de rede.

As System Calls foram os principais alvos dos Rootkits, durante a segunda geração, já que elas compõem partes importantes dos módulos do sistema. Um ataque às System Calls provocava enorme mudança nas funções do Kernel, dentre elas destacava-se: transformações das quais os processos não eram mais visíveis, embora estivessem em processamento, e outros como mudanças no comando mkdir (este é responsável pela criação de diretórios), muito utilizado em ambientes LINUX/UNIX.

Na terceira geração dos Rootkits os endereçamentos de memória foram explorados, e através deles obteve-se mais uma grande evolução dos Rootkits, a que passou a ser chamada de Suckit:

Ele é um rootkit completamente funcional que é carregado via /dev/kmem. Ou seja, ele não precisa de um kernel com suporte a módulos carregáveis do kernel. Ele possui um shell para acesso remoto protegido por senha, iniciado por um pacote com spoof (passando pela maioria das configurações de firewall) e pode esconder processos, arquivos e conexões. (Em: http://www.debian.org/News/2003/20031202.pt.html)

Geralmente o Suckit é rodado na inicialização do sistema como /sbin/init (diretório responsável pela inicialização dos arquivos binários do Linux) adquirindo PID (Identificação de Processo) 1, onde inicia uma backdoor ( também conhecida como porta dos fundos, é na verdade uma porta de comunicação oculta, que pode dar acesso ao invasor, ela pode ser criada por um usuário ou por uma aplicação) e uma cópia do binário init original, execuções posteriores são redirecionadas a partir de então ao original, facilitando sua ocultação no Kernel.

O Linux possui um diretório /dev/kmen e outro /dev/men, ambos com privilégio de gravação fornecido somente ao Root, onde o primeiro tem a função de endereçar a memória virtual mais swap, que posteriormente é transformada em memória real. Esses diretórios se fizeram alvos da terceira geração dos Rootkits, onde a idéia era, através dos arquivos reportados neles, formar uma System Calls própria, onde os arquivos são comparados e reescritos no Kmen. Técnica extremamente funcional e criativa que teoricamente foi vista como irreparável, porem a estratégia de auditoria conseguiu superar mais uma vez este recurso, já que os aplicativos instalados no sistema geram diretórios próprios e com diferentes funções, acessos e links utilizados pelo sistema também passaram a serem monitorados com mais precisão a partir daí.