Tunelamento de rede com… QEMU?

Atacantes tendem a dar preferência ao uso de ferramentas legítimas durante as diferentes etapas de um ataque, visto que elas podem os ajudar na evasão de sistemas de detecção, além de minimizar o tempo e custos no desenvolvimento de malware. Varreduras de rede, extração da memória de um processo, exfiltração de dados, execução remota de arquivos e até mesmo a encriptação de um disco – todas essas técnicas podem ser realizadas por meio de softwares legítimos. Para ganhar acesso à infraestrutura comprometida e dar prosseguimento ao ataque, adversários podem utilizar malware previamente instalado ou se conectar à rede via RDP ou VPN corporativa utilizando credenciais válidas previamente obtidas (para isso, atacantes devem possuir contas com os privilégios apropriados). Outro meio de se conectar à rede interna da organização afetada envolve a utilização de ferramentas para configuração de túneis ou o encaminhamento de portas entre os servidores corporativos e a máquina do atacante. Isso permite que os atacantes burlem regras de NAT e firewalls para ganhar acesso aos sistemas internos. É essa categoria de software que iremos discutir neste artigo.

Estatísticas

Diversas ferramentas podem ser utilizadas para configurar um túnel entre dois sistemas. Algumas delas se conectam diretamente, enquanto outras podem fazer o uso de um proxy, ocultando o endereço IP real do servidor do atacante. Durante a resposta a incidentes cibernéticos, identificamos os seguintes utilitários sendo amplamente empregados nos últimos três anos.

• Stowaway
• ligolo
• 3proxy
• dog-tunnel
• chisel
• FRP
• ngrok
• gs-netcat
• plink
• iox
• nps

Os mais frequentes foram o ngrok e FRP. Essas ferramentas foram identificadas em 10% do total de ataques.

QEMU como uma ferramenta de tunelamento

Enquanto investigávamos um incidente em uma grande empresa há alguns meses, detectamos uma atividade maliciosa incomum em um dos sistemas. Realizamos a análise dos artefatos, apenas para identificar que o atacante instalou e executou as seguintes ferramentas:

• Angry IP Scanner – utilizado para realizar varreduras na rede.
• mimikatz – ferramenta utilizada em ataques ao Active Directory para extração de senhas, hashes e tickets do Kerberos.
• QEMU – ferramenta para emulação de hardware.

As duas primeiras são autoexplicativas, mas a utilização do QEMU levantou algumas questões. Qual uso os atacantes dariam para um software de virtualização?

Conseguimos capturar a linha de execução do QEMU por meio da análise da memória do dispositivo comprometido. Identificamos que ele foi iniciado sem nenhum LiveCD ou imagem de disco, o que é muito incomum para o QEMU. Os seguintes argumentos foram utilizados pelo atacante para executar o QEMU:

onde <IP> era um endereço IP externo.

Vamos examinar em detalhes cada um dos argumentos:

• -m 1M: especifica a quantidade de RAM que será alocada para a máquina virtual. Neste caso, apenas 1 MB, quantidade insuficiente para a maioria dos sistemas operacionais modernos.
• -netdev user,id=lan,restrict=off: cria uma interface de rede virtual de usuário chamada lan, o que permite à máquina virtual se comunicar com dispositivos externos a partir da interface do sistema hospedeiro. A opção restrict=off remove restrições nas conexões de entrada e saída.
• -netdev socket,id=sock,connect=<IP>:443: cria uma interface do tipo socket nomeada sock, que provê uma conexão com o servidor remoto no endereço IP especificado e utilizando a porta 443.
• -netdev hubport,id=port-lan,hubid=0,netdev=lan: adiciona uma porta ao hub virtual com hubid=0, que está vinculado à interface de rede virtual lan.
• -netdev hubport,id=port-sock,hubid=0,netdev=sock: da mesma forma, essa opção adiciona outra porta ao hub virtual vinculado à interface de rede sock.
• -nographic: inicia o QEMU sem a interface gráfica, informações serão exibidas no console.

O endereço IP presente nos argumentos imediatamente nos chamou atenção: era um endereço externo e sem relação alguma com a organização atacada. Após consultarmos a documentação do QEMU, constatamos que ele suporta conexões entre máquinas virtuais. A opção -netdev cria dispositivos de rede (backend) que podem então se conectarem às máquinas virtuais. Cada um dos diversos dispositivos de rede é definido por um tipo e suporta opções extras. A seguir é apresentada uma descrição dos valores de -netdev que foram utilizados.

user (user network stack)

Esta é a forma mais simples de conectar uma máquina virtual a uma rede. O tráfego passa pelo host e a máquina virtual se conecta à rede como se fosse um aplicativo comum da máquina do hospedeiro.

No exemplo, mynet0 é o ID da rede (backend) e e1000 é um adaptador de rede (frontend) presente na máquina virtual.

hubport (virtual hub)

Conecta diferentes dispositivos de rede, similarmente a um hub.

socket

Conecta máquinas virtuais diretamente por meio de sockets, visando criar topologias de rede de VMs ou conectar VMs instaladas em hosts distintos.
# VM1

# VM2, conectada a VM1

VM1 aguarda conexões na porta 1234, enquanto VM2 se conecta a essa porta. Este foi o caminho que os atacantes seguiram: executaram um “cliente” no sistema comprometido e ele se conectou ao servidor malicioso para abrir acesso à rede corporativa na qual o “cliente” estava sendo executado. Essa abordagem não degrada a performance do sistema comprometido, já que o adversário não estava utilizando uma imagem de disco ou LiveCD ao executar o QEMU.

Não foi possível determinar de maneira precisa como os atacantes executaram o QEMU no servidor malicioso. Dessa forma, decidimos testar essa técnica em um ambiente controlado composto por três sistemas:

• InternalHost: localizado na rede alvo, sem acesso à Internet e executando um servidor de RDP na porta 3389. Seu objetivo é simular o sistema isolado sem acesso à Internet.
• PivotHost: localizado na rede alvo, mas com acesso à Internet. Seu objetivo é simular o sistema explorado pelos atacantes e utilizado para chegar ao InternalHost.
• AttackerServer: hospedado na nuvem. Seu objetivo é simular o servidor dos adversários.

Nosso objetivo durante os testes foi conseguir comunicação com o InternalHost a partir do AttackerServer. A imagem a seguir apresenta uma visão geral da topologia utilizada.

Diagrama da rede utilizada

Utilizamos o QEMU no AttackerServer para executar uma VM com o sistema Kali Linux via LiveCD. Um dispositivo de rede foi conectado à máquina virtual como um adaptador de rede ouvindo na porta 443.

Outra cópia do QEMU foi executada no PivotHost e se conectou ao AttackerServer presente na nuvem via porta 443 por meio do dispositivo citado. Também conectamos um dispositivo de usuário no mesmo hub. As opções de iniciação do QEMU foram muito similares às que identificamos sendo utilizadas pelo adversário anteriormente.

Uma vez iniciado, o QEMU configura um túnel entre o PivotHost e o AttackerServer, mais precisamente, para a VM Kali Linux. Foi possível utilizar as ferramentas presentes no Kali Linux para varrer a rede na qual o PivotHost estava conectado, permitindo a identificação de outros sistemas.

Varredura de rede

A varredura da rede via Nmap expõe que o InternalHost, endereço IP 192.168.56.109, estava com a porta 3389 aberta. Realizamos uma conexão ao InternalHost utilizando o RDP.

Conexão RDP ao InternalHost bem-sucedida

O QEMU não utiliza nenhuma encriptação extra ao tunelar o tráfego. Ele transmite os pacotes encapsulados sem criptografia. Os dados dos pacotes a nível de aplicação enviados ao servidor contêm o tamanho do frame Ethernet encapsulado (4 bytes, destacados em amarelo na imagem abaixo), seguidos pelo frame Ethernet (destacado em vermelho).

Exemplo de um frame Ethernet encapsulado

O tamanho do frame Ethernet encapsulado exposto na imagem acima é de 89 (0x59) bytes. Esse valor é imediatamente seguido pelo frame Ethernet encapsulado. A partir da captura de tráfego obtida no PivotHost, foi possível obter o tráfego encapsulado simplesmente removendo os primeiros 58 bytes (para TCP: 14 bytes do Ethernet + 20 bytes do IP + 20 bytes dos cabeçalhos TCP + 4 bytes do tamanho interno do pacote). Isso pode ser feito por meio do utilitário editcap do Wireshark após remover do arquivo PCAP pacotes que não contêm tráfego encapsulado.

O resultado foi um arquivo PCAP contendo o tráfego enviado por meio do túnel.

Pacote original transmitido por meio do túnel

Portanto, constatamos que essa técnica foi muito eficaz para alcançar a persistência na rede. Além dos dispositivos de rede supracitados, o QEMU suporta diversos outros, que também podem ser utilizados pelos adversários na execução dos seus ataques.

Conclusão

A utilização de ferramentas legítimas pelos atacantes não é novidade para os profissionais de resposta a incidentes. Entretanto, temos que admitir que os adversários muitas vezes são bem criativos e utilizam programas improváveis, como foi o caso do QEMU, para execução dos seus ataques. Isso evidencia ainda mais a necessidade de uma proteção multinível, composta pela segurança dos endpoints e pela utilização de soluções especializadas na detecção e mitigação de ataques complexos e direcionados. Somente uma segurança abrangente, que inclui o monitoramento 24/7 da rede (NDR, NGFW) e dos endpoints (EDR, EPP), composta por especialistas em SOC, pode detectar e bloquear anomalias rapidamente e nos estágios iniciais. Nosso serviço de MDR já é capaz de detectar esse tipo de atividade suspeita via QEMU. Ademais, regras apropriadas de IDS foram adicionadas à plataforma KATA com a identificação Backdoor.Agent.QEMU.C&C.