Persistência do atacante

Invadir uma vez não basta para quem ataca: a senha pode ser trocada, a sessão pode cair. Por isso, logo depois de entrar, o atacante monta uma forma de voltar sem precisar invadir de novo. É a persistência.

As formas mais comuns num servidor Linux:

• Criar uma conta nova. Aparece no log de autenticação como new user: name=... (do programa useradd), em geral seguida de passwd/chpasswd e de usermod ... to group 'sudo', para a conta já nascer com poder de administrador.
• Adicionar uma chave SSH ao arquivo authorized_keys de uma conta. Depois, o login aparece como Accepted publickey for ..., sem senha.
• Agendar uma tarefa (cron) que reabre o acesso de tempos em tempos.

Como separar o que é do atacante do que é normal:

Pista	Conta legítima	Conta do atacante
Hora	Horário comercial	De madrugada, dentro da sessão da invasão
Quem criou	Administrador conhecido, via sudo	A própria conta invadida
Tipo	Funcionário, ou conta de sistema (nologin, número abaixo de 1000)	Shell normal, logo colocada no sudo
Depois	Uso esperado	Login por chave vindo do endereço do ataque

Exemplo. Um new user: name=svc_monitor às 02:15, logo depois de uma invasão às 02:14, seguido de add 'svc_monitor' to group 'sudo' e, meia hora depois, Accepted publickey for svc_monitor from <endereço do ataque>, é persistência clara. O nome imita uma conta de serviço para passar despercebido.

Isso importa porque é o passo que a resposta a incidentes mais esquece. Trocar a senha invadida não adianta se ficou uma conta ou uma chave nova. Depois de conter o ataque, procure sempre contas, chaves e tarefas que nasceram depois da invasão.