22 - Malware analysis

Question 1

Why analyze malware?

Answer 1

• To assess damage
• To discover indicators of compromise
• To determine sophistication level of an intruder
• To identify a vulnerability
• To catch the “bad guy”®
• To answer questions…

Question 2

Static analysis techniques.

Answer 2

Hash the file
Virus scan
List properties and type of file
List strings inside the binary
Inspect raw bytes of the binary
List symbol info
View shared objects linked in at runtime

Disassembly: Automated disassemblers can take machine code and “reverse” it to a slightly higher-level.
Manual examination of disassembly is painstaking, slow, and can be hard.

Decompilation:
- Type of reverse engineering that takes an executable file as input, and attempts to create a high level source file which can be recompiled successfully
- The reverse of a compiler

Static analysis will reveal some immediate information
- Exhaustive static analysis could theoretically answer any question, but it is slow and hard

Question 3

Dynamic analysis techniques.

Answer 3

Usually you care more about “what” malware is doing
than “how” it is being accomplished.

Dynamic analysis is conducted by observing and
manipulating malware as it runs.

Enquanto que o static era depois de run.

Question 4

Creating safe environment.

Answer 4

Do not run malware on your computer

Old and busted:
- Shove several PCs in a room on isolated network, create disk
images, re-image a target machine to return to pristine state

Better:
- Use virtualization to make things fast and safe

It is easier to perform analysis if you allow the malware to “call home”… .

“Call home” = quando o malware, instalado numa máquina vítima, inicia ligações de saída para contactar um servidor de controlo (C2 — Command & Control) para receber ordens, enviar informações, descarregar payloads, etc. É o mecanismo que mantém o bot “ligado” ao atacante.

However:
- The attacker might change his behavior
- By allowing malware to connect to a controlling server, you may be
entering a real-time battle with an actual human for control of your
analysis (virtual) machine
- Your IP might become the target for additional attacks
- You may end up attacking other people

Riscos ao permitir call‑home para a Internet real

O atacante muda o comportamento

Se o C2 for controlado por uma pessoa, ele pode enviar comandos diferentes quando detecta que está a falar contigo (por exemplo, não enviar payloads inicialmente, enviar comandos para limpar evidências, executar código mais perigoso, pivotar).

Em suma: não estás a analisar um comportamento fixo, podes entrar numa interação adaptativa com o operador.

Real‑time battle: o atacante pode tentar controlar a máquina

O atacante pode tentar assumir controlo interactivo (shell remoto, reverse shell), instalar ferramentas de escalonamento, criar persistência, mover‑se lateralmente.

Em tempo real, ele pode também tentar identificar-te (IP, fingerprint) e contra‑atacar.

O teu IP pode tornar‑se alvo

Uma vez que o malware conecta a partir do teu IP, o adversário sabe onde está o “bot” (o teu lab). Ele pode lançar ataques dirigidos a esse IP (scans, exploit attempts, DDoS, backconnect).

Se o atacante for sofisticado, tenta explorar serviços abertos ou reconectar com payloads adicionais.

Risco de atacar terceiros (exfil / pivot)

O malware pode, sem querer ou por comando, usar a tua VM/host como salto para atacar outros sistemas (scans, DDoS, envio de spam, exploração).

Isso põe‑te em risco legal e ético — podes estar a causar danos a terceiros sem saber.

Therefore, we usually do not allow malware to touch the real
network:
- May entirely disable the networking capability
- Or use the host-only networking feature of your virtualization
platform

More advanced
- Establish real services (DNS, Web, etc) on your host OS or other
virtual machines
- Use netcat to create listening ports and interact with text-based client
- Build custom controlling servers as required (usually in a high-level
scripting language)

Question 5

Virtualization considerations.

Answer 5

Using a Virtual Machine helps, but…
Malicious code can detect that it is running in a virtual machine

A 0-day worm that can exploit a listening service on your
host OS will escape the sandbox
Even if you are using host-only networking!

Ou seja: host‑only NÃO é uma “garantia” absoluta

Host‑only evita tráfego externo, mas não elimina contacto directo com o host — se houver qualquer serviço vulnerável, esse contacto é suficiente.

2) Porque é que isso importa quando usas host‑only?

Host‑only geralmente cria uma rede privada entre a VM e o host. A VM e o host conseguem falar entre si (VM → Host), embora a VM possa não ter acesso à Internet.

Se, nessa interface host‑only, o host tem um serviço a ouvir (por ex. um agente de gestão, o Docker, um servidor SMB, ou outro daemon), a VM consegue tentar ligar‑se a esse serviço.

Se esse serviço tiver uma vulnerabilidade (um bug que permite execução de código, elevação de privilégios, ou corrupção de memória), um malware (ou worm) dentro da VM pode explorá‑la e fazer execução de código no host.

3) O que é um 0‑day e como ele pode “escapar” do sandbox

0‑day = vulnerabilidade desconhecida do fornecedor, sem correção ainda.

Um exploit 0‑day é um código que tira vantagem dessa vulnerabilidade para executar comandos não autorizados.

Se o serviço do host tem esse 0‑day e está acessível a partir da VM (via host‑only), então o exploit pode:

ligar‑se ao serviço do host;

enviar dados que desencadeiam o bug (ex.: uma mensagem malformada);

ganhar controle do processo do serviço ou do próprio host;

a partir daí, o atacante pode instalar código no host, mover‑se lateralmente, etc.

System Call Trace (strace)
The GNU debugger
Dump the process’ RAM and analyze it

Question 6

Zero Wine: Malware behavior analysis.

Answer 6

Zero Wine: a Malware Analysis Tool
Upload malware perform static and dynamic analyze
Virtual machine using Qemu or VMware and Linux/Wine

Output:
- Raw trace (Report)
- Strings
- PE headers
- Signature (API calls)

Question 7

Malware analysis methods.

Answer 7

Static analysis:
- No execution, analyzing a malware binary code without actually running the code
- Extensive search in the binary with various tools

Dynamic analysis:
- Execution - requires program to be executed in a closely monitored environment
- Extensive monitoring
- Alter the execution and program flow

Static analysis is safer:
- Since we aren’t actually running malicious code, we don’t have to worry (as much) about creating a safe environment

Question 8

Run antivirus program.

Answer 8

Static tho.

Question 9

Analyzing malware binaries can be challenging.

Answer 9

It adds three protective layers to an executable file:
- Obfuscation: scrambles the code in the executable thru obfuscated instructions
- Encryption of the binary program
- Fingerprint layer: will only run on certain computers

Question 10

Anti-static analysis techniques.

Answer 10

Disassembly desynchronization:
- Prevent the disassembly from finding the correct starting
address for one or more instructions. Forcing the disassembler
to lose track of itself

Dynamically computed target addresses:
- Address to which execution will flow in computed at run-time

Opcode obfuscation:
Encode or encrypt the actual instructions when the executable
file is being created (self modification)

Imported function obfuscation:
In order to avoid leaking information about potential actions
that a binary may perform, aimed at making it difficult for
the static analysts to determine which shared libraries and
library functions are used within an obfuscated binary

Targeted attacks on analysis tools

Question 11

Anti-dynamic analysis techniques.

Answer 11

Detecting virtualization
Detecting instrumentation (Sysinternals tools, WireShark etc.)
Detecting debuggers
Preventing debugging