Descrição

Uma fibra é uma unidade de execução que deve ser agendada manualmente pela aplicação, em vez de depender do mecanismo de escalonamento baseado em prioridade embutido no Windows. As fibras são frequentemente chamadas de threads leves. Para obter informações mais detalhadas sobre o que são e como funcionam as fibras, consulte a documentação oficial. As fibras permitem ter múltiplos fluxos de execução em uma única thread, cada um com seu próprio estado de registradores e pilha. Por outro lado, as fibras são invisíveis para o kernel, o que as torna um método mais furtivo (e mais barato) para executar código na memória do que criar novas threads.

Uma thread pode criar múltiplas fibras e alternar entre elas conforme desejado chamando a função SwitchToFiber. Antes disso, a própria thread atual deve ter se tornado uma fibra chamando ConvertThreadToFiber, já que apenas uma fibra pode criar outras fibras. Finalmente, para criar uma fibra que, quando escalonada, execute código na memória (por exemplo, após carregar reflativamente um PE ou algum shellcode), basta fazer uma chamada a CreateFiber.

A função SwitchToFiber é a parte mais importante desse processo e onde toda a mágica ocorre. Essa função permite escalonar uma fibra ou outra, tudo acontecendo no espaço do usuário. De acordo com a documentação oficial, "a função SwitchToFiber salva as informações de estado da fibra atual e restaura o estado da fibra especificada". Isso significa que, quando essa função é chamada, os valores dos registradores e a pilha são trocados do estado da fibra atual para o estado da fibra de destino, permitindo "esconder" a pilha da fibra atual assim que o processo é concluído. Isso também permite continuar a execução da fibra de destino a partir do mesmo ponto onde a execução foi interrompida (da mesma forma que acontece quando o escalonador alterna entre threads de acordo com sua própria lógica de prioridade).

E é exatamente isso que este simples PoC faz:

• Primeiro, temos um loader, que usará DInvoke para mapear manualmente a dll que contém nosso payload.
• Depois disso, o loader transformará a thread atual em uma fibra (conhecida daqui em diante como fibra de controle). A fibra de controle terá uma pilha "normal", já que o loader está sendo executado a partir de um PE no disco.
• O loader então criará uma nova fibra para executar a função run() exportada pela dll mapeada manualmente. Essa fibra será conhecida daqui em diante como fibra de payload.
• A fibra de controle alternará para a fibra de payload, que executará qualquer código que o payload contenha. Assim que o payload precisar entrar em um estado alertável (por exemplo, quando uma chamada a Sleep for necessária), a fibra de payload retorna para a fibra de controle, escondendo sua pilha (que pode conter vários IOC de atividade maliciosa).
• A fibra de controle realiza a chamada a Sleep. Quando a chamada retorna, ela alterna novamente para a fibra de payload para que esta possa continuar sua execução.

Este processo se repete indefinidamente.

Vantagens

O uso de fibras pode ser vantajoso para alguns tipos de payloads (como um beacon C2) por algumas destas razões:

• As fibras permitem executar código na memória sem a necessidade de usar as instruções JMP ou CALL do loader apontando para regiões de memória não mapeadas.
• Essa execução é realizada sem a criação de novas threads, prevenindo a geração de callbacks do kernel que podem ser coletados por um EDR.
• A pilha da fibra de payload pode ser escondida quando o payload entra em um estado alertável ou quando precisa aguardar uma operação de E/S pendente. Isso é feito usando uma fibra de controle com uma pilha normal que executa código do disco. Esse "esconderijo" é mais barato e mais fácil de implementar do que o processo normal de spoofing de pilha de thread.
• As fibras são invisíveis para o kernel e todo o procedimento de alternância acontece no espaço do usuário, o que facilita o ocultamento de um EDR.

Contras

• Apenas uma fibra pode ser escalonada por vez em uma thread, o que significa que para obter concorrência real usando fibras é preciso criar mais threads.
• Embora a pilha da fibra de payload seja escondida quando a fibra de controle é retomada, ela permanece na memória do processo e pode ser detectada por uma inspeção de memória.
• A ofuscação ainda é necessária para esconder o implante na memória; isso é apenas sobre esconder a pilha e o método de execução.

Compilação

Como estamos usando o plugin LITCRYPT para ofuscar literais de string, é necessário configurar a variável de ambiente LITCRYPT_ENCRYPT_KEY antes de compilar o código:

C:\Users\User\Desktop\Fiber> set LITCRYPT_ENCRYPT_KEY="yoursupersecretkey"

Depois disso, basta compilar tanto o payload quanto o loader e executar o último:

C:\Users\User\Desktop\Fiber\payload> cargo build --release
C:\Users\User\Desktop\Fiber\loader> cargo build --release
C:\Users\User\Desktop\Fiber\loader\target\release> loader.exe

Uso

Não há muito mistério na execução deste PoC. Tudo o que precisa ser feito é executar o loader e usar qualquer ferramenta como o ProcessHacker para inspecionar a pilha da thread. Como o payload retorna à fibra de controle antes de dormir, a pilha da fibra de payload permanece escondida na maior parte do tempo. Você verá na saída como as duas fibras são escalonadas consecutivamente seguindo a lógica já comentada.

O código é comentado para mostrar como usar, criar e escalonar fibras. Você notará que tanto o loader quanto o payload oferecidos como exemplo estão "presos" em um loop infinito, o que permite alternar indefinidamente entre as fibras e continuar a execução.

Se um payload diferente quiser ser testado, basta modificar o caminho localizado na linha 32 do arquivo src::main.rs do loader. Nesse caso, a nova dll deve exportar uma função run(PVOID) que receberá como parâmetro de entrada o endereço da fibra de controle. Essa função deve retornar à fibra de controle para chamar a função Sleep, embora você possa modificar esse comportamento conforme desejar para atender aos seus requisitos.

Outra maneira de testar esta ferramenta com um payload aleatório é realizar o hooking da IAT para redirecionar qualquer chamada à função Sleep (ou qualquer outra função importada) feita pelo payload para uma função localizada no loader, permitindo retornar à fibra de controle quando essa chamada ocorrer. Fica a seu critério.

Nas capturas de tela a seguir, podemos ver como a pilha da thread atual se move de uma região de memória privada para outra à medida que alternamos as fibras: