What is malware?
Any software intentionally designed to cause damage to a computer, server or computer network.
Malware does the damage after it is implanted or
introduced in some way into a target’s computer
- Can take the form of executable code, scripts, active content,
and other software
What are explots?
Exploits are malicious programs that take advantage
of application software or OS vulnerabilities.
Do all exploits involve file-based malware?
No.
Attacks through exploit kits.
The most common method to distribute exploits and exploit kits
is through webpages, but exploits can also arrive in emails.
What are exploit kits?
Exploit kits are more comprehensive tools that contain a collection of exploits.
What is a vulnerability?
A vulnerability is a mistake in software code that provides
an attacker with direct access to a system or network.
What is Common Vulnerabilities and Exposures (CVE)?
It is a program launched in 1999 by MITRE to identify and catalog
vulnerabilities in software or firmware into a free “dictionary” for
organizations to improve their security.
Vulnerability reporting in CVEs.
The dictionary’s main purpose is to standardize the way each known
vulnerability or exposure is identified.
The Metasploit framework.
Metasploit Framework is a software platform for developing, testing, and executing exploits.
- It can be used to create security testing tools and exploit modules and as a penetration testing system.
Can incorporate new exploits in the form of modules (plug-ins).
What are rootkits?
The behavior of the operating system can be affected by the presence of rootkits.
- Enable access to a computer or areas of its software that is
not otherwise allowed (for example, to an unauthorized user).
Rootkits are a category of malware which has the ability to hide itself and cover up traces of activities.
What are rootkit goals?
- Enable future access to system by attacker
- Remove evidence of original attack and activity that
led to rootkit installation - Hide future attacker activity (files, net connections,
processes) and prevent it from being logged - Install tools to widen scope of penetration
- Secure system so other attackers can’t take control
of system from original attacker
Examples of rootkits.
Install a backdoor on the compromised system
Run a password logger on a compromised system
Rootkit tools: Backdoor programs.
Backdoor is an unauthorized way of gaining access to a
program, online service or an entire computer system
- Let attackers log in to the hacked system without using an exploit again
Rootkit tools: sniffers.
Packet sniffers
- Packet Sniffer is a program and/or device that monitor data
traveling over a network, TCP/IP or other network protocol
- Used to listen or to steal valuable information off a network; many
services such as “ftp” and “telnet” transfer their password in plain
text and it is easily capture by sniffer
Rootkit tools: wipers.
Log-wiping utilities
- Log file are the lists actions that have occurred, e.g., in UNIX, wtmp
logs time and date user log in into the system
- Log file enable admins to monitor, review system performance and
detect any suspicious activities
- Deleting intrusion records helps prevent detection of the intrusion
Rootkit tools: Miscellaneous attacker tools.
- DDOS program
- IRC program
- System patch: attacker may patch the system after successful attack; this will prevent other attacker to gain access into the system again
- Password cracker
- Vulnerability scanners
- Hiding utilities: utilities to conceal the rootkit files on compromised system
Rootkit stealth techniques.
File masquerading
Hooking
Direct Kernel Object Manipulation (DKOM)
Virtualization
- File masquerading.
Aquele exemplo de criar uma diretoria .. falsa.
Replace system files (or directories) with malicious versions
that shared the same name and services as the original
- Or create files (or dirs) that resemble legitimate files (or dirs)
Installation concealment:
- Use spaces to make filenames look like expected dot files: “. “ and “.. “
- Use dot files, which aren’t in ls output
- Use a subdirectory of a busy system directory like /dev, /etc, /lib, or /usr/lib
- Use filenames that system might use
/dev/hdd (if no 4th IDE disk exists)
/usr/lib/libX.a (libX11 is real Sun X-Windows)
- Delete rootkit install directory once installation is complete
Change system commands.
Command-level rootkits hide malware by changing system commands
- Based on principle: To suppress bad news, silence the messenger
Ou seja: se queres esconder que há malware, faz com que os comandos que denunciam o problema deixem de mostrar a verdade - “silencia” esses comandos. É exactamente isso que fazem command-level rootkits: alteram/substituem/enganam comandos para que deixem de reportar processos, portas, ficheiros, módulos, etc.
- Hooking.
The next step in evolution of rootkits was to redirect system
calls to malicious code, a technique known as hooking.
Hooking is when a given pointer to a given resource or
service is redirected to a different object.
E.g., instead of replacing the file containing the “ls” command, a
system call can be redirected to a custom “dir” command in
memory space that filters out the malicious files and folders.
Basically, hooking achieves the same effect as file
masquerading, but is more difficult to detect
- Don’t require changing executable files
- Integrity checkers ineffective when validating executable files
Where can hooking be performed?
Hooking can be performed at several layers in the
operating system, primarily libraries and kernel.
Library-level hooking.
Instead of replacing system utilities, rootkits can hide their
existence by making changes at the next level down in the
system architecture: the system run-time library
A good example is redirecting the open() and stat() calls
- The purpose of these modifications is to fool file-integrity-checking
software that examines executable file contents and attributes
- By redirecting the open() and stat() calls to the original file, the
rootkit makes it appear as if the file is still intact
- However, execve() executes the subverted file
Fluxo técnico (passo a passo, explicado)
Programas em userland normalmente chamam open() e stat() para ler ficheiros ou ver atributos.
Essas funções fazem parte da biblioteca de tempo de execução (por ex. libc).
Antes de chegar ao kernel, a chamada passa por essa biblioteca.
Hook em nível de biblioteca (ex.: LD_PRELOAD) substitui as funções open()/stat() por versões maliciosas.
Quando um programa chama open(), chama as versões hookadas.
As versões hookadas podem devolver o conteúdo/atributos antigos (ou fabricados) — o programa vê “tudo bem”.
execve() também tem uma função wrapper em libc, mas no fim é uma syscall que pede ao kernel para carregar e executar o ficheiro que está no disco.
O kernel lê o inode e os blocos do disco diretamente e carrega o binário real para memória.
Se o ficheiro em disco foi substituído por um binário malicioso, o kernel vai carregar essa versão maliciosa e executá-la — mesmo que as funções open()/stat() em userland estejam a devolver uma “versão limpa”.
Conclusão: Hookar open()/stat() engana verificadores e programas que ficam em userland. Mas execução real (quando o kernel carrega o binário) usa o conteúdo real em disco, portanto o malware pode ser executado apesar do “checker” ter visto uma versão limpa.
Observação: rootkits mais avançados também podem hookar a nível do kernel para enganar tudo — aí é muito mais complicado.
Ideia geral (passo a passo)
O hook substitui a rota normal: quando um programa pede open()/stat() etc., o pedido passa para a função hookada em vez da função original.
O hook guarda/tem acesso à função original: antes de substituir, o autor do hook guarda uma referência para a função original (ou sabe como chamá-la).
O hook decide o que fazer:
pode chamar a função original (delegar) e devolver o resultado ao programa — geralmente depois de filtrar ou modificar esse resultado;
ou pode não chamar a original e devolver uma resposta fabricada (falsa).
Resultado: o programa recebe a resposta do hook (que pode ser idêntica ao original ou alterada), sem saber que houve interferência.
1) Como o hook decide o que mostrar (resumo)
O hook intercepta chamadas (por ex. open, stat, read). Antes de substituir o funcionamento normal, o autor do hook normalmente tem um modo de aceder ao comportamento original. Quando chega uma chamada, o hook inspeciona o contexto da chamada e escolhe uma das duas opções:
Devolver a versão limpa (fabricada ou antiga) — se o hook decidir que o chamador é uma ferramenta de verificação, um administrador, ou algo que não deve ver o ficheiro real.
Devolver a versão real/maliciosa — se for um processo que deve executar o malware (ex.: o próprio serviço que o atacante quer controlar).
Em suma: o hook faz uma checagem rápida do chamador e escolhe qual resposta devolver.
2) Que factores o hook usa para decidir (coisas que ele olha)
Normalmente o hook verifica coisas simples do processo que faz a chamada. Exemplos típicos (coisas que podes entender facilmente):
Nome do processo (argv[0]) — se for sha256sum, tripwire, rpm, etc., devolve o limpo.
PID / PPID / UID — se o processo tiver UID inesperado ou for filho de um processo suspeito, pode devolver o real.
Caminho do executável (/proc/<pid>/exe) — se vier de /usr/bin/ vs de /tmp/ o comportamento muda.</pid>
Variáveis de ambiente (ex.: se LD_PRELOAD existe, ou se tem variáveis de debugging).
Se a chamada vem de um terminal interativo vs de um serviço/background.
Sequência de chamadas (por ex., se depois de open() vem um execve() no mesmo processo, o hook pode diferenciar).
Assinatura do leitor — alguns hooks mantêm uma lista de “ferramentas conhecidas” e as tratam de forma especial.
Resumindo: o hook olha quem pediu e decide — é por isso que um checker normal nunca vê a versão verdadeira se o hook o identificar.
3) Como isto engana os checkers (o porquê prático)
Um checker típico faz stat()/open()/read() para calcular um hash ou verificar metadados.
Se todas essas funções foram substituídas por hooks que devolvem os valores “bons”, o checker nunca lê o ficheiro real em disco — só lê a versão que o hook lhe forneceu.
Ou seja: o checker pensa que está tudo ok porque está a ler a mentira que o hook lhe deu.
Por isso é que os checkers userland sozinhos não provam que o sistema está limpo — eles usam as mesmas APIs que o hook controla.
Kernel-level hooking.
Just like user-level rootkits, kernel-level rootkits are
installed after a system’s security has been breached.
Kernel-level rootkits compromise the kernel
- Kernel runs in supervisor processor mode
- Thus, the rootkit gains complete control over the machine
Advantage: stealth, e.g.,
- Runtime integrity checkers cannot see rootkit changes
- All programs in the system can be affected by the rootkit
- Open backdoors/sniff network without running processes
Methods to inject rootkit code into a kernel.
- Loading kernel module into a running kernel
- Injecting code into the memory of a running kernel that
has no support for module loading - Injecting code into the kernel file or a kernel module file
-
02 - Legal Framework14
-
03 - Digital Investigation Process17
-
04 - Evidence Acquisition42
-
05 - Forensic data decoding32
-
06 - Steganography and watermarking26
-
07 - Memory Forensics31
-
08 - Storage and volume analysis38
-
09 - File system analysis techniques47
-
10 - File carving35
-
11 - Evidence in operating system37
-
12 - Temporal Analysis26
-
13 - Network traffic analyis31
-
14 - Pitfalls in network addressing24
-
15 - Investigation of computer networks30
-
16 - Wireless networks forensics43
-
17 - Email and web forensics33
-
18 - Deep web and anonymity26
-
19 - Online Anonymity28
-
20 - Botnets36
-
21 - Rootkits35
-
22 - Malware analysis11
-
23 - Cryptocurrency investigations29
-
24 - Mobile forensics36
-
25 - Cloud Forensics17
-
Exam 2024/2025 17
