Purple Team - Breaking

the Cyber Kill Chain

Relatório de Estágio

Tomás Almeida Ferraz

2017018782

Orientadores:
Luís Eduardo Faria dos Santos | ISEC
Rui Gonçalo Joaquim Dias Amaro | Cipher

Licenciatura em Engenharia Informática

Ramo de Redes e Administração de Sistemas
Instituto Politécnico de Coimbra
Instituto Superior de Engenharia de Coimbra

XXXXX de 2020
Agradecimentos
Resumo

Palavras-chave:
Abstract

Keywords:
Conteúdo

1 Introdução 1
1.1 Enquadramento . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Entidade de acolhimento . . . . . . . . . . . . . . . . . . . . . 2
1.3 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.4 Plano de trabalhos . . . . . . . . . . . . . . . . . . . . . . . . 3
1.5 Metodologia de Trabalhos . . . . . . . . . . . . . . . . . . . . 3
1.6 Estrutura do Relatório . . . . . . . . . . . . . . . . . . . . . . 4

2 Conceitos 5
2.1 Red, Blue e Purple Teaming . . . . . . . . . . . . . . . . . . . 5
2.1.1 Red Teaming . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.2 Blue Teaming . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.3 Purple Teaming . . . . . . . . . . . . . . . . . . . . . . 8
2.2 Cyber Kill Chain . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3 MITRE ATT&CK . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3.1 Origem e enquadramento . . . . . . . . . . . . . . . . . 13
2.3.2 Organização da matriz ATT&CK . . . . . . . . . . . . 14
2.3.3 A Cyber Kill Chain no ATT&CK . . . . . . . . . . . . 16
2.3.4 Vetores de uso . . . . . . . . . . . . . . . . . . . . . . . 19
2.4 Emulação de adversários . . . . . . . . . . . . . . . . . . . . . 20

3 Estado da Arte 23
3.1 Análise de requisitos . . . . . . . . . . . . . . . . . . . . . . . 23
3.1.1 Escala das prioridades . . . . . . . . . . . . . . . . . . 23
3.1.2 Requisitos Funcionais . . . . . . . . . . . . . . . . . . . 23
3.1.3 Atributos de Qualidade . . . . . . . . . . . . . . . . . . 24
3.2 Estado da arte . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2.1 Escala de avaliação dos requisitos de qualidade . . . . . 25
3.2.2 Plataformas Simulação/Emulação de Ataques . . . . . 26
3.2.3 Modelos de avaliação de maturidade . . . . . . . . . . 35

v
vi CONTEÚDO

4 Emulação de adversários 37
4.1 APT1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.1.1 Enquadramento . . . . . . . . . . . . . . . . . . . . . . 37
4.1.2 Ciclo de vida do ataque . . . . . . . . . . . . . . . . . 39
4.2 APT3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.2.1 Enquadramento . . . . . . . . . . . . . . . . . . . . . . 42
4.2.2 Ciclo de vida do ataque . . . . . . . . . . . . . . . . . 43
4.2.3 Emulação do atividade do grupo . . . . . . . . . . . . . 45
4.3 OilRig . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.3.1 Enquadramento . . . . . . . . . . . . . . . . . . . . . . 45
4.3.2 Ciclo de vida do ataque . . . . . . . . . . . . . . . . . 47
4.3.3 Emulação do atividade do grupo . . . . . . . . . . . . . 48
4.4 APT41 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.4.1 Enquadramento . . . . . . . . . . . . . . . . . . . . . . 49
4.4.2 Ciclo de vida do ataque . . . . . . . . . . . . . . . . . 50
4.4.3 Emulação da atividade do grupo . . . . . . . . . . . . . 51

5 Modelo de avaliação de maturidade 53

A Proposta de Estágio 55
Lista de Figuras

2.1 Ciclo conceptual das Purple Teams . . . . . . . . . . . . . . . 9

2.2 A Cyber Kill Chain . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3 Estrutura da MITRE ATT&CK [6] . . . . . . . . . . . . . . . 15

3.1 User Interface do Infection Monkey [26] . . . . . . . . . . . . 27

3.2 Exemplo de documentação de técnica do Atomic Red Team [4] 28
3.3 Scripts da Red Team Automation [25] . . . . . . . . . . . . . . 29
3.4 APT Simulator - Diálogo Inicial [29] . . . . . . . . . . . . . . 30
3.5 Interface do CALDERA [11]. . . . . . . . . . . . . . . . . . . 32
3.6 Interface do ATT&CK Navigator[1] . . . . . . . . . . . . . . . 33

4.1 xxxx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.2 xxxx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

vii
viii LISTA DE FIGURAS
Lista de Tabelas

2.1 Penetration Testing versus Emulação de Adversários . . . . . 20

3.1 Prioridades dos requisitos funcionais. . . . . . . . . . . . . . . 24

3.2 Escala a utilizar na avaliação de ferramentas. . . . . . . . . . . 26
3.3 Avaliação atribuída ao Infection Monkey . . . . . . . . . . . . 27
3.4 Avaliação atribuída ao Atomic Red Team . . . . . . . . . . . . 28
3.5 Avaliação atribuída ao Red Team Automation . . . . . . . . . 29
3.6 Avaliação atribuída ao APT Simulator . . . . . . . . . . . . . 31
3.7 Avaliação atribuída ao CALDERA . . . . . . . . . . . . . . . 34
3.8 Comparação da avaliação atribuída as ferramentas de simula-
ção/emulação de ataques. . . . . . . . . . . . . . . . . . . . . 35

ix
x LISTA DE TABELAS
Glossário e Acrónimos

API Application Programming Interface.

APT Advanced Persistent Threat. Agente furtivo, geralmente patrocinado

por uma nação, que obtem acesso a uma rede de computadores e per-
manece oculto durante longos periodos de tempo.

ATT&CK Adversarial Tactics, Techniques, and Common Knowledge. Pro-

jeto desenvolvido pela MITRE de modo a documentar as táticas, téc-
nicas e procedimentos mais comuns, usados em ataques informáticos.

Blue Team Equipa que visa proteger a organização de ataques, tanto reais,
como os da Red Team.

C2 Command and Control

CERT Computer Emergency Response Team

CLI Command Line Interface

CSIRT Computer Security Incident Response Team. Grupo de profissionais

que fornece a uma organização serviços de prevenção, deteção e coor-
denação de potenciais emergências relacionadas com cibersegurança.

CVE Common Vulnerabilities and Exposures.

DoS Denial of Service.

EDR Endpoint Detection and Response. Disrupção do normal funciona-

mento de um sistema ou serviço.

Firmware. Software que fornece controlo de baixo nível sobre o hardware

específico do sistema.

FQDN Fully Qualified Domain Name.

FTP File Transfer Protocol.

xi
xii LISTA DE TABELAS

HTML HyperText Markup Language.

HTTP HyperText Transfer Protocol .
HTTPS HyperText Transfer Protocol Secure.
IDS Intrusion Detection System
IPS Intrusion Prevention System
MUCD Military Unit Cover Designator. Sequências numéricas de cinco
dígitos que fornecem anonimato à unidade em questão.
PDF Portable Document Format.
PenTesting Penetration Testing. Testes efetuados sobre um sistema, apli-
cação ou rede de computadores com o objetivo de encontrar vulnerabi-
lidades que um atacante possa explorar.
Purple Team Ponto de vista cooperativo que visa maximizar a efetividade
das Red e Blue teams, através de integração dos ataques com as defesas.
RAT Remote Access Trojan. Malware que permite a um hacker monitorizar
e controlar um sistema remotamente.
RDP Remote Desktop Protocol
Red Team Equipa que visa testar a efetividade dos sistemas de segurança
de uma organização através da emulação das técnicas e ferramentas
usadas pelos atacantes.
RAR Roshal Archive
REST Represantational State Transfer
RPCS Remote Procedure Call Service
SIEM Security Information and Event Management
SLL Secure Sockets Layer
SMB Server Message Block
TCP Transmission Control Protocol
TTP Tactics, Techniques, and Procedures. Termo militar que descreve o
modo de operação de um certo agente de ameaça.
Capítulo 1

Introdução

Este relatório documenta o trabalho desenvolvido ao longo do segundo se-

mestre do ano letivo de 2019/2020, no âmbito da unidade curricular Projeto
ou Estágio da licenciatura em Engenharia Informática - ramo de Redes e
Administração de Sistemas do Instituto Superior de Engenharia de Coimbra.

1.1 Enquadramento
Hoje em dia as organizações são cada vez mais alvo do crime informático,
devido aos negócios que processam, dinheiro que movimentam e informação
que possuem. Este crescimento exponencial de ataques tem levado a um
forte investimento em tecnologias e infraestruturas de segurança, de modo
a dotar as organizações da desejável (sensação de) segurança, algo que nem
sempre se verifica. O trabalho desenvolvido neste projeto procura validar em
que medida a infraestrutura avaliada, dá resposta aos mais recentes ataques,
promovidos por grupos de ataque Advanced Persistent Threat (APT), que
praticam o crime informático como meio de alcançar os seus objetivos.
A validação a realizar terá em conta, numa primeira fase, a deteção ou
prevenção da intrusão inicial numa organização, na qual o atacante tenta
ganhar acesso ao sistema alvo de modo a executar as suas próprias instru-
çõ[Link] além disso pretende validar também a deteção ou prevenção de
eventuais movimentos entre sistemas na rede comprometida e escaladas ile-
gítimas para privilégios de administrador, permitindo validar para além da
segurança perimetral, a capacidade de uma organização de detetar acessos
ilegítimos na sua rede e sistemas. A resposta a este tipo de ameaças permite
a uma organização reduzir o impacto associado a um ataque informático.

1
2 CAPÍTULO 1. INTRODUÇÃO

1.2 Entidade de acolhimento

A Dognædis é uma empresa com foco comercial na segurança informática.
Foi criada em 2010 por uma equipa de investigadores do Computer Emer-
gency Response Team (CERT) pertencente à Universidade de Coimbra. Essa
mesma equipa esteve envolvida na origem de um Computer Security Incident
Response Team (CSIRT) sediado no Instituto Pedro Nunes, uma incubadora
de empresas da Universidade de Coimbra. Em março de 2016 a Dognædis
foi adquirida pelo grupo Prosegur, um líder de mercado mundial no setor da
segurança.
A Dognædis apresenta-se como um eficiente provedor de serviços e inova-
dor vendedor de tecnologias de cibersegurança. Atualmente conta com cinco
linhas de serviço: Cyber Intelligence, Managed Security Services & Managed
Detection and Response, Audit & Testing, Consultancy e Security Technolo-
gies.
No final do ano de 2018, o grupo Prosegur adquiriu a Cipher, uma em-
presa de renome mundial com foco na área de cibersegurança, com escritórios
localizados na América do Norte, Europa e América Latina. Durante o ano
de 2019 todas as empresas incluídas na Divisão de Cibersegurança Prosegur
iniciaram por um processo de rebranding, transitando para uma marca global
- Cipher, a Prosegur Company.

1.3 Objetivos
O estágio aqui relatado, promovido pela Cipher, pretendeu o desenho e im-
plementação de uma solução que permita a avaliação da capacidade de de-
teção/prevenção de uma infraestrutura de segurança nas diversas fases que
caracterizam um ataque informático:

• Criação de um conjunto de cenários de ataque, mapeados com a matriz

MITRE ATT&CK, recriando a atividade de grupos APT.

• Estabelecimento de um modelo de avaliação de maturidade de soluções

de segurança, com base nos cenários de ataque implementados e o rácio
de prevenções/deteções alcançado.

• Avaliação de infraestruturas de segurança e rede subjacente, com base

no modelo de avaliação desenvolvido.

• Sugestão de novas soluções ou ações que visem dar resposta aos ataques
que a infraestrutura não consegue detetar.
1.4. PLANO DE TRABALHOS 3

1.4 Plano de trabalhos

O estágio teve início no dia 17 de Fevereiro de 2020, tendo terminado no dia
XXXX de XXXX de 2020. Foi feito o seguinte plano de trabalhos, de acordo
com a proposta de estágio (Anexo A), e também de acordo com os requisitos
impostos pela entidade de acolhimento:

• T1 - Avaliação das Plataformas de Simulação de ataque Avaliação das

ferramentas que devem ser utilizadas no decorrer do estágio.

• T2 - Estudo da Matriz MITRE ATT&CK Estudo da matriz MITRE

ATT&CK, a sua organização, nomenclatura, e os vários usos que pode
ser dados à mesma.

• T3 - Implementação de cenários de ataque Implementação dos cenários

de ataque, tentando recriar de forma fidedigna a atividade desenvolvida
pelos grupos APT.

• T4 - Execução dos cenários de ataque Em ambiente laboratiorial, os

cenários de ataque serão executados sobre uma infraestrutura de segu-
rança pré-definida, e verificada a percentagem de técnicas detetadas/-
previnidas pela infraestrutura.

• T5 - Desenho do modelo de avaliação de maturidade Com base nos

cenários executados e informação dos mecanismos de defesa da infraes-
trutura alvo, avaliar a maturidade da solução defesa, e ainda calcular
métricas de desempenho (F1 e Recall).

• T6 - Desenho de solução Com base nos resultados obtidos nas fases an-
teriores, devem ser pensadas soluções que permitam melhorar a avalia-
ção efetuada, reforçando os setores menos resilientes da infraestrutura.

• T7 - Relatório e Documentação Produção de documentação do projeto,

durante o decorrer do estágio.

1.5 Metodologia de Trabalhos

O estágio foi realizado entre o dia 17 de fevereiro de 2020 e o dia XXX de
XXXX de 2020, numa primeira fase nas instalações da empresa, em Coimbra,
posteriormente em regime de teletrabalho, face ao surto pandémico de SARS-
CoV-2(COVID-19). (A TERMINAR)
4 CAPÍTULO 1. INTRODUÇÃO

Tarefa Duração Prevista Inicio Fim Duração Real (horas)

T1 40 17/2/2020 21/2/2020 36
T2 40 24/2/2020 28/2/2020 39
T3 250 2/3/2020 13/5/2020 275
T4 80 14/5/2020
T5 150 14/5/2020 10 (15/4/2020)
T6 100
T7 61 1/3/2020

Ao longo deste período foram realizadas reuniões regularmente com o

orientador do ISEC. Foi ainda criada no Moodle da instituição um curso
para o acompanhamento do estágio que serviu de ponto de comunicação
entre orientador e aluno, albergando as várias versões do relatório, atas das
reuniões e repositório de material de apoio. As reuniões com o orientador da
Cipher foram realizadas quinzenalmente.

1.6 Estrutura do Relatório

Este relatório encontra-se dividido nos seguintes X capítulos:

• Capítulo 1- Neste capítulo é feita uma introdução à envolvente geral

do projeto, objetivos e requisitos do mesmo, é apresentada a entidade
de acolhimento e apresentada a estrutura do documento.

• Capítulo 2- Neste capítulo são apresentados conceitos essenciais para

uma melhor compreensão do trabalho desenvolvido e das ferramentas
e tecnologias usadas na mesmo.

• Capítulo 3-

• Capítulo 4- Neste capítulo encontram-se documentados os APTs que

foram alvo de estudo, as suas origens, motivações, ciclo de vida da sua
atividade e plano de emulação da mesma.
Capítulo 2

Conceitos

Neste capítulo serão apresentados alguns conceitos essenciais para a compre-

ensão do projeto desenvolvido.

2.1 Red, Blue e Purple Teaming

Os conceitos de seguida apresentados servem para distinguir as funções e
objetivos dos profissionais que trabalham na área da segurança de informa-
ção. A compreensão destes conceitos é importante para perceber quais os
objetivos deste estágio.

2.1.1 Red Teaming

Origem

O termo Red Team surge associado a exercícios de simulação militar dos Es-
tados Unidos da América em que a força opositora às forças estado-unidenses
é designada por red team, e tem por objetivo tomar o papel de um inimigo
composto por várias formas de ameaça, como pessoas, equipamentos e técni-
cas que são desconhecidas pelos defensores. Quando aplicado à segurança da
informação, o termo representa um grupo de hackers que testam as defesas
digitais e até mesmo físicas de uma organização e também a capacidade de
resposta dos defensores, ou seja, é uma forma de uma equipa de cibersegu-
rança testar como se comporta uma organização e os seus mecanismos de
defesa durante um ataque informático.

5
6 CAPÍTULO 2. CONCEITOS

Operação
Um exercício de red teaming por norma consiste numa simulação de um
ataque desenhado para medir o quão preparada está uma organização, os seus
funcionários, aplicações e controlos de segurança para receber um ataque real.
Para tal, a red team irá expor vulnerabilidades e riscos com origens distintas:

• Tecnológicas - Redes, aplicações, routers, switches, etc.

• Sociais - Funcionários, departamentos, parceiros de negócio, etc.

• Físicas - Edifícios, escritórios, data centers, armazéns, etc.

Durante um exercíco de read teaming os consultores de segurança recriam

cenários de ataque para descobrir potenciais vulnerabilidades sociais, físicas,
e tecnológicas. Para além disso, identificam também oportunidades para
ameaças reais, sejam elas exteriores ou interiores à organização, comprome-
terem os sistemas e informação da organização.

Objetivos
Os principais objetivos de uma red team passam por encontrar falhas de
segurança na infraestrutra auditada e ganhar acesso ao sistema, seja a falha
humana, tecnológica ou física. Para além disso, uma boa red team deve
também oferecer assistência na remediação destas falhas, um guia detalhado
de como melhorar as defesas da organização e um novo teste após as falhas
serem remediadas.

Red Teaming versus Penetration Testing

Muitas vezes os conceitos de red team e de penetration testing são confundidos
como sendo uma e a mesma coisa. Apesar de partilharem o mesmo objetivo
(identificar falhas de segurança e com isso melhorar a resiliência a ameaças
de uma organização) seguem uma abordagem operacional bastante distinta.
A utilidade de ambos é indiscutível, mas devem ser utilizados em contextos
diferentes. O Penetration Testing consiste em encontrar o maior número
de vulnerabilidades de segurança e erros de configuração possíveis, e tirar
proveito dos mesmos.
Já uma auditoria de red team não tem como principal foco encontrar o
maior número de vulnerabilidades possível, mas sim testar as capacidades de
deteção e resposta de uma organização. A equipa de red team tenta invadir
uma infraestrutura e aceder à informação da organização, da forma mais
furtiva possível. Por norma, este tipo de auditorias emula o comportamento
2.1. RED, BLUE E PURPLE TEAMING 7

de grupos que promovem o cibercrime o que permite testar as capacidades

de deteção/resposta da organização contra uma ameaça do mundo real.

2.1.2 Blue Teaming

Origem
À semelhança do conceito de red team, o termo blue team surgiu no âm-
bito militar, em que a blue team era a equipa encarregue de defender-se
dos ataques da red team. Quando aplicado à segurança informática, a blue
team representa o grupo de pessoas encarregues de implementar medidas de
segurança e garantir que as mesmas continuam a ser eficazes após a imple-
mentação, e também identificar possíveis vulnerabilidades nos sistemas da
organização. A principal diferença entre a blue team e a red team é que a
primeira tem como principal responsabilidade encontrar mecanismos de de-
fesa capazes de dar resposta a possíveis incidentes, embora a atividade da
equipa não se limite a dar resposta a ataques mas também em reforçar toda a
infraestrutura de segurança usando mecanismos de deteção, prevenção e mi-
tigação. Resumindo, a principal função da blue team é proteger os recursos
digitais de uma organização de qualquer tipo de ameaças.

Operação
Por norma, a blue team começa por recolher informação sobre os dados que
precisam de ser protegidos, e posteriormente implementam medidas de se-
gurança genéricas, como políticas de passwords mais restritivas, formações
aos funcionários da empresa para garantir que os mesmos percebem e agem
conforme as políticas implementadas.
Normalmente são implementadas ferramentas de monitorização, que per-
mitem que informações que dizem respeito aos sistemas sejam armazenadas
na forma de logs.
Podem ser esperados os seguintes tipos de atividades por parte de uma
blue team:

• Monitorizar as atividades dos utilizadores de modo a identificar possí-

veis indicadores de atividade maliciosa, como domínios, endereços IP,
assinaturas de ficheiros, entre outros.

• Instalar ferramentas de segurança nos endpoints (computadores).

• Assegurar que as firewalls e outros mecanismos de segurança se encon-

tram corretamente configurados e atualizados.
8 CAPÍTULO 2. CONCEITOS

• Implementar mecanismos como Intrusion Detection Systems (IDSs) ou

Intrusion Prevention Systems (IPSs) que permitem detetar ou prevenir
potenciais intrusões.
• Implementar mecanismos de ingestão e centralização de logs (Security
Information and Event Management (SIEM)).
• Analisar os padrões de tráfego de uma rede para detetar atividade
suspeita.
• Embeber a segurança da informação nos processos operacionais de uma
organização.

Objetivos
Como já referido, o principal objetivo de uma blue team é garantir a segurança
a longo prazo da informação que uma organização considera importante, atra-
vés da implementação de mecanismos e políticas de segurança robustas e da
monitorização constante da infraestrutura a proteger. Esta equipa é respon-
sável também por dar resposta a eventuais incidentes que possam ocorrer no
sistema a proteger. Para tal, deve identificar, conter e erradicar potenciais
ameaças que possam comprometer a segurança da informação protegida.

2.1.3 Purple Teaming

Origem
As red teams operam com um objetivo ofensivo através de avaliações de vul-
nerabilidade, testes de penetração, engenharia social e simulação de ataques.
Já as blue teams operam num âmbito defensivo, através da implementação
de controlos, monitorização e resposta a incidentes. No entanto, ambas as
equipas operam com um objetivo em comum: melhorar a segurança da orga-
nização. Apesar de partilharem o mesmo objetivo final que é melhorar a ro-
bustez dos processos, políticas e mecanismos de segurarança organizacionais,
muitas das vezes, ambas as equipas não conseguem desencadear totalmente o
seu potencial, devido a problemas operacionais, aumentados pelo facto de ti-
picamente ambas as equipas reportarem a hierarquias diferentes. Muitas das
vezes estas equipas operam sobre pressupostos errados, como por exemplo:
• Relatórios com muitas vulnerabilidades indicam um bom trabalho por
parte da red team.
• Sucesso de uma auditoria de red teaming medido através do número de
controlo que falham.
2.1. RED, BLUE E PURPLE TEAMING 9

• A ausência de alertas nos sistemas de monitorização da blue team sig-

nifica que os mecanismos de prevenção funcionam.

• A presença de muitos alertas nos sistemas de monitorização significa

que os mecanismos de deteção funcionam.

• Falhas da blue team equivalem ao sucesso da red team.

• Falhas da red team equivalem ao sucesso da blue team

Devido ao desenquadramento de objetivos entre as duas equipas surgiu
o conceito de purple team. As purple teams são um conceito que promove a
cooperação entre atacantes e defensores que operam com o mesmo objetivo
(aumentar a segurança da informação de um dado sistema). De tal modo, as
purple teams devem ser vistas como um modelo cooperativo e não uma equipa
dedicada. Nos últimos anos as organizações têm cada vez mais adotado este
modelo de cooperação em deteriorimento do tradicional modelo "red team vs
blue team".

Operação
O exercício desta metodologia tem como principal objetivo ajudar as equipas
de segurança a melhorar os seus processos operacionais. Muitas organizações
organizam com regularidade exercícios de purple teaming onde os objetivos,
timelines e conclusões estão delineados, e existe um processo formal para
avaliar as lições tiradas no decorrer da operação.
Do ponto de vista conceptual, o exercício de purple teaming pode ser visto
como uma ciclo de troca de informação permanente entre ambas as equipas
(blue e red ), que pode ser ilustrado pela figura 2.1. Por norma, quando as red
Partilha de procidementos documentados
Partilha de táticas de monitorização

Red Team Blue Team

Partilha de novos procedimentos de ataque

Ajuda no processo de gestão de vulnerabilidades

Figura 2.1: Ciclo conceptual das Purple Teams

teams terminam os seus testes e simulações, enviam à blue team um relatório

com as vulnerabilidades encontradas e esta por sua vez trata de as remediar.
10 CAPÍTULO 2. CONCEITOS

Este processo é longo, e nenhuma das equipas (blue e red ) obtém feedback
contínuo da outra.
As purple teams foram desenhadas para servir de ponte entre ambas as
equipas (red e blue), promovendo uma abordagem mais proativa e direta.
Pegando no caso anterior, quando a red team termina os seus testes e
simulações, envia o seu relatório, e aconselha a blue team sobre as vulnera-
bilidades que devem ser priorizadas e as falhas que devem ser corrigidas em
primeiro lugar. Por outro lado, a blue team monitoriza a atividade da red
team e partilha as suas técnicas de monitorização e deteção. Esta aborda-
gem reforça ambas as equipas. Enquanto a blue team fica mais informada
em como priorizar e medir as suas capacidades de deteção de ameaças, a
red team aprende mais sobre os mecanismos e tecnologias usados no setor
defensivo, levando à descoberta de vetores de ataque mais sofisticados.
Este projeto enquadra-se com o modelo de purple team, visto que para
além da implementação e execução dos cenários de ataque, atividade asso-
ciada ao exercício de red teaming, também são avaliadas os mecanismos de
defesa e a qualidade alarmística dos mesmos, adotando uma postura que tem
em conta a postura defensiva e ofensiva da cibersegurança.

2.2 Cyber Kill Chain

Um ciberataque pode ser executado de inúmeras maneiras diferentes, po-
dendo variar em complexidade, técnicas utilizadas e atores envolvidos. Para
tal, é necessário que seja estabelecida uma abordagem sequencial para des-
crever um ciberataque. O termo Cyber Kill Chain denomina as etapas de um
ciberataque, desde a sua fase de reconhecimento até à etapa de exfiltração, ou
seja, transferência não autorizada dos dados recolhidos. A kill chain ajuda
a compreensão e o combate ao grupos Advanced Persistent Threat (APT),
grupos que praticam o cibercrime e que tipicamente acedem a uma infra-
estrutura e permanecem na mesma durante largos períodos de tempo sem
serem detetados.
A Lockheed Martin, empresa americana da indústria aeroespacial e se-
gurança, derivou a framework kill chain, de um modelo militar que foi es-
tabelecido para identificar, preparar o ataque, confrontar, e destruir o alvo
[8]. Esta abordagem permite sistematizar a análise e replicação de ataques
informáticos, associando as diversas atividades observadas a etapas específi-
cas da Cyber Kill Chain. Esta associação facilita o processo de partilha de
informação entre os analistas de segurança, e entre organizações.
Conforme a figura 2.2 indica, podemos sintetizar a Cyber Kill Chain nos
seguintes oito pontos:
2.2. CYBER KILL CHAIN 11

CKC1

Reconhecimento
CKC2 CKC8

Intrusão Exfiltração

CKC3 Exploit CKC7

Denial of Service

Ofuscação
Escalada de Privilégios

CKC6
CKC4
Movimentos Laterais

CKC5

Figura 2.2: A Cyber Kill Chain

• CKC1 - Reconhecimento. Fase de observação, durante a qual os atacan-

tes auditam a infraestrutura de fora para dentro, de modo a identificar
os alvos e estratégias para desferir um eventual ataque.

• CKC2 - Intrusão. Com base nas informações obtidas na fase anterior,

os atacantes conseguem entrar na infraestrutura , normalmente com
base em código malicioso ou eventuais vulnerabilidades de segurança
presentes no sistema.

• CKC3 - Exploit. Execução de código malicioso de modo a ganhar uma

posição mais segura nos sistemas comprometidos, através da exploração
da exploração das suas vulnerabilidades.
12 CAPÍTULO 2. CONCEITOS

• CKC4 - Escalada de privilégios. De modo a aceder a uma maior quanti-

dade de dados, por norma os atacantes necessitam de ganhar privilégios
de administrador ou sistema.

• CKC5 - Movimentos Laterais. Os atacantes movem-se de sistema em

sistema dentro da infraestrutura. Este movimento destina-se a alcançar
privilégios mais elevados, a aceder a mais informação ou aumentar o
número de sistemas comprometidos.

• CKC6 - Ofuscação. De modo a dificultar o processo de análise forense,

ou seja, investigação que tem como objetivo recolher provas e indi-
cadores de que o sistema foi comprometido, os atacantes geralmente
encobrem os seus rastos, deixando falsas pistas e limpando ficheiros de
logs.

• CKC7 -Denial of Service. Disrupção do normal funcionamento de um,

ou vários sistemas/serviços, de modo a impedir que o ataque em curso
seja monitorizado, rastreado ou bloqueado.

• CKC8 - Exfiltração. Extrair da infraestrutura comprometida a infor-

mação aí encontrada.

Para tornar possível o processo da implementação de cenários ataque, um

dos focos principais deste estágio, é vital que sejam compreendidas, mesmo
de modo abstrato, todas as etapas/fases que compõem um ciberataque.

2.3 MITRE ATT&CK

A MITRE é uma organização sem fins lucrativos que trabalha em diversas
áreas de interesse publico como inteligência artificial, data science, ciberse-
gurança, entre outras. A MITRE desenvolveu a ATT&CK [27] como um
modelo para documentar diversas técnicas que atacantes utilizam no decurso
de um ciberataque. A framework possui diversas matrizes de diferentes téc-
nicas, usadas durante um ciberataque, divididas em diferentes táticas (etapas
do ataque). De momento estão implementadas matrizes distintas para cada
uma das plataformas seguintes:

• Windows

• macOS

• Linux
2.3. MITRE ATT&CK 13

• Cloud

• Mobile

• Sistemas de Controlo Industrial

No âmbito deste projeto foram apenas utilizadas as matrizes Windows e

Linux.
Desde a sua origem, em 2013, a ATT&CK tornou-se um dos recursos mais
referenciados da cibersegurança. As matrizes são uma base de conhecimento
de técnicas de hacking baseadas em observações do mundo real, que podem
auxiliar na montagem de mecanismos de defesa eficazes.[27].
Em linhas gerais tanto a Cyber Kill Chain como a ATT&CK seguem as
mesmas etapas associadas a um ciberataque. A principal diferença entre as
duas é que a ATT&CK não impõe uma ordem específica de operações, e que
a ATT&CK fornece informação mais detalhada sobre as ações levadas a cabo
pelos atacantes, a forma como estas ações se encaixam umas nas outras, a
maneira como estas ações se enquadram com os objetivos de alto nível dos
atacantes e a correlação das ações com os mecanismos de defesa eficazes na
deteção dessas ações.

2.3.1 Origem e enquadramento

A ATT&CK surgiu da necessidade de categorizar o comportamento dos ata-
cantes durante um ciberataque. O primeiro modelo da ATT&CK surgiu em
setembro de 2013 e focava-se apenas no ambiente Windows. Ao longe dos
dois anos seguintes foi sendo refinada através de pesquisa interna por parte
da MITRE, e em Maio de 2015 foi disponibilizada ao público com noventa
e seis técnicas encaixadas em nove táticas distintas. Desde então, a plata-
forma foi crescendo com base em contribuições por parte da comunidade de
cibersegurança. Em 2017 a plataforma foi expandida de forma a cobrir as pla-
taformas macOS e Linux, e a matriz tomou o nome de ATT&CK Enterprise.
Nesse mesmo ano um modelo complementar também foi disponibilizado, o
PRE-ATT&CK, que cobre técnicas que são executadas antes de o próprio
ataque ser conduzido (planeamento, recolha de informações sobre os alvos,
definição de prioridades, entre outros). Ainda em 2017 foi publicada uma
versão da matriz para sistemas móveis (smartphones). Durante o ano de
2019 foram incorporadas na matriz ATT&CK Enterprise técnicas especifi-
cas ao ambiente de Cloud. Já no ano de 2020 foi também disponibilizada a
ATT&CK for ICS que documenta comportamentos conduzidos em ambien-
tes de sistemas de controlo industrial. As atividades descritas na plataforma
são em grande parte obtida de informação de dominio público, por exemplo,
14 CAPÍTULO 2. CONCEITOS

incidentes reportados publicamente. Isto permite que a plataforma descreva

com precisão as atividades conduzidas pelos atacantes em ambientes reais.
As informações relevantes para a plataforma podem ter origem em diversas
fontes como relatórios de incidentes, apresentações, webinars, blogs, amostras
de código malicoso, entre outros. A framework sofre atualizações pontuais,
como mudança de nome de algumas técnicas, pequenas alterações a técnicas
da mesma, que não se refletem na matriz. Por norma, duas a três vezes por
ano a matriz é atualizada de forma mais relevante, seja para adicionar no-
vos conteúdos ou para reformular os existentes, ou até para depreciar certas
técnicas que os autores da matriz considerem que perderam a sua relevância.
A framework ATT&CK foi desenvolvida para dar resposta aos seguintes
desafios:

• Foco nos comportamentos dos adversários. Ao se focar nos comporta-

mentos adversários, nomeadamente táticas e técnicas, as organizações
podem desenvolver novas estratégias de análise para a deteção de po-
tenciais ataques. Os indicadores típicos de atividade maliciosa, como
domínios, endereços IP, hashes de ficheiros, chaves do Registry são fa-
cilmente alterados pelos atacantes e apenas indicam que um atacante
interagiu com um sistema mas não a maneira como o mesmo interagiu.

• Ciclos de vida que não serviam. Os modelos do ciclo de vida de uma

ameaça e da cyber kill chain são demasiado abstratos, não permitiam
o desejável relacionamento entre comportamentos e defesas.

• Aplicação a ambientes reais. As Tactics, Techniques, and Proceduress

(TTPs), ou seja os padrões de atividade associados a uma ciberameaça,
precisavam de ser baseados em incidentes observados de modo a serem
aplicáveis em ambientes reais.

• Taxonomia comum. As TTPs precisam de ser comparáveis entre dife-

rentes tipos de grupos adversários, usando a mesma terminologia.

A capacidade de uma organização para detetar e parar uma intrusão, é dras-

ticamente melhorada se os desafios atrás mencionados forem endereçados.

2.3.2 Organização da matriz ATT&CK

As técnicas presentes na matriz encontram-se agrupadas num conjunto de
táticas de modo a providenciar um contexto de fácil compreensão de cada
técnica. Cada técnica inclui informação que é relevante tanto para a red
team, de modo a permitir a compreensão da origem e funcionamento de uma
2.3. MITRE ATT&CK 15

técnica, como para a blue team, permitindo a esta a perceção dos eventos e
artefactos gerados pela técnica em uso.

Táticas

As táticas representam o "porquê"de uma técnica. São o objetivo de uma

determinada ação levada a cabo por um atacante. Servem de categorias
contextuais, e cobrem notações de alto nível, para aquilo que os adversários
fazem durante uma operação. Na matriz, as táticas representam as colunas
da mesma.

Técnicas

As técnicas representam como é que um adversário alcança um objetivo tá-

tico ao levar a cabo uma ação. Como podem existir várias maneiras para
um adversário alcançar um dado objetivo tático, cada tática, contem várias
técnicas.
A relação entre táticas e técnicas pode ser visualizada na matriz MITRE
ATT&CK, como indica a figura 2.3:

Figura 2.3: Estrutura da MITRE ATT&CK [6]

Para cada entrada na matriz é dado um identificador único o que per-

mite uma taxonomia universal, facilitando a partilha de informação entre as
equipas de uma organização, e também entre organizações.
16 CAPÍTULO 2. CONCEITOS

Mitigações
Para além da matriz de mapeamento entre táticas e técnicas, a plataforma
ATT&CK também fornece algumas informações complementares à matriz,
sendo uma delas a tabela de mitigações, ou seja, um conjunto de mitigações
afetas às técnicas presentes na matriz. Por exemplo para a técnica T1040[17],
Network Sniffing,ou seja a captura de tráfego, uma mitigação possível seria, a
mitigação M1041[13], Encrypt Sensisitve Information, ou seja assegurar-nos
que o tráfego circula cifrado.

Grupos
A plataforma também fornece informação acerca de grupos APT, mapeando-
os com as técnicas que os mesmos utilizam. A informação fornecida é com-
posta por conjuntos de dados relativos a intrusões atribuídas ao mesmo ata-
cante. A framework utiliza o termo grupo para descrever grupos, adversários,
campanhas e qualquer agente relacionado com atividade maliciosa. Alguns
grupos podem ser identificados por vários nomes.

Software
Termo genérico para código comercial ou artesanal, utilitários dos sistemas
operativos, ou outras ferramentas usadas para executar atividade maliciosa.
As aplicações usadas encontram-se diretamente mapeadas com as técnicas
presentes na matriz, e também com os grupos que usam o software. Podem
ser divididas em duas categorias: ferramentas ou malware(código malicioso).
Uma ferramenta é um utilitário open-source ou comercial usada tanto por
defensores ou adversários. Exemplos de ferramentas podem incluir, Mimi-
katz[15], Metasploit, PsExec[19], netstat[16], Tasklist[20], etc. Já o Malware
é software usado com fins exclusivamente maliciosos. Exemplos de malwares
podem ser PlugX[18],CHOPSTICK[12], 4H RAT[10], etc.

2.3.3 A Cyber Kill Chain no ATT&CK

Na matriz MITRE ATT&CK algumas fases da Cyber Kill Chain foram su-
pressas, e outras adicionadas de modo a melhor espelhar aquilo que os grupos
APT praticam na sua atividade. As fases da Cyber Kill Chain na matriz
ATT&CK são denominadas táticas, e são as seguintes[14]:

• Initial Acess Esta fase equivale à fase de intrusão (CKC2) na Cyber

Kill Chain apresentada no início do capítulo (figura 2.2). O adversário
2.3. MITRE ATT&CK 17

tenta entrar na rede. Consiste em técnicas que exploram vários veto-

res de entrada de modo a ganhar acesso à rede. Podem passar por
Spearphishing (golpe informático dirigido a uma organização ou pes-
soa com vista a roubar dados ou a executar código remotamente) ou
exploração de vulnerabilidades em servidores de acesso público.

• Execution Corresponde à fase de Exploit (CKC3) na figura 2.2. O ad-

versário tenta executar código malicioso no sistema comprometido. Por
norma estas técnicas encontram-se emparelhadas com outras técnicas
de outras táticas de modo a alcançar objetivos mais genéricos, como
explorar a rede ou conduzir atividades de exfiltraçãode dados sensí-
veis. Por exemplo, um adversário pode usar malware que possibilite o
acesso remoto para executar um script de PowerShell que conduza o
mapeamento da rede alvo.

• Persistence O adversário tenta manter o acesso ao sistema invadido.

Consiste em técnicas usadas para manter acesso ao sistema, mesmo
que sejam tomadas ações como reboots, mudança de credenciais e ou-
tras ações que poderiam cortar o acesso aos sistemas. Estas técnicas
incluem qualquer mudança em ficheiros de configuração, substituição
de código legítimo, ou adição de código ao código executado no arran-
que do sistema.

• Privilege Escalation Corresponde à fase de Escalada de Privilégios (CKC4)

na figura 2.2. Consiste em técnicas que os adversários usam para ga-
nhar permissões mais elevadas, num sistema ou rede. Abordagens co-
muns para esta tática normalmente passam por explorar fraquezas do
sistema, configurações erradas e vulnerabilidades.

• Defense Evasion Técnicas que permitem ao adversário não ser dete-

tado. Estas podem incluir a desinstalação ou desabilitação de ferra-
mentas de segurança, ofuscação ou cifra de dados ou abuso de processos
que sejam confiados pelo sistema de modo a "mascarar"o malware.

• Credential Access O adversário tenta roubar nomes e passwords das

contas do sistema. Por norma inclui técnicas de keylogging(captura de
teclas premidas) ou credential dumping (extração de passwords de uma
máquina). Ao usar credenciais legítimas, o adversário pode aceder aos
sistemas, de modo quase imperceptível, tendo a possibilidade de assim
criar ou alterar contas para conseguir alcançar os seus objetivos mais
facilmente.
18 CAPÍTULO 2. CONCEITOS

• Discovery Técnicas que o adversário pode usar para conhecer melhor o

sistema alvo, através da observação e descoberta de serviços ou máqui-
nas. Deste modo o adversário pode tomar decisões mais informadas,
antes de agir. Estas técnicas também permitem aos adversários explo-
rar o que estes podem controlar e tirar proveito, de modo a alcançar
o seu objetivo mais facilmente. Por norma, são usadas ferramentas
nativas aos sistemas operativos para tal fim.

• Lateral Movement Equivale à fase de Movimentos Laterais da Cyber

Kill Chain apresentada na figura 2.2. O adversário tenta mover-se entre
máquinas no sistema. Por norma, de modo a alcançar os seus objetivos,
o adversário vê-se obrigado a infetar outros sistemas, de modo a aceder
a outras contas, que possuam privilégios mais altos.

• Collection Por norma, consiste em técnicas que permitam ao adversário

a recolha de informação relevante aos objetivos que movem o adversá-
rio. Alvos comuns destas técnicas incluem drives, browsers, ficheiros de
áudio, ficheiros de vídeo e emails.

• Command and Control O adversário tenta comunicar, remotamente,

com o sistema comprometido, de modo a controlá-lo. Por norma os ad-
versários tentam camuflar o tráfego originado, com tráfego "normal",
de modo a dificultar a deteção da sua atividade. Existem várias manei-
ras de estabelecer um Command and Control (C2), ou seja, uma forma
de controlar a(s) máquina(s) infetadas, dependendo da infraestrutura
e rede do adversário.

• Exfiltration Equivale à fase de Exfiltração (CKC8) apresentada na fi-

gura 2.2. Consiste em técnicas, que permitem ao adversário colher
informação potencialmente valiosa alojada nos sistemas comprometi-
dos. Após recolher os dados, os adversários geralmente ofuscam-os de
modo a evitar a deteção enquanto os exfiltram. Este processo pode
envolver a compressão e cifra dos mesmos. Técnicas para mover os
dados para fora do sistema ou rede, normalmente exploram o canal de
Command and Control, ou um outro alternativo.

• Impact É a fase final da Cyber Kill Chain, em que o adversário tenta

manipular, interromper, ou destruir o sistema e/ou informação que
controla de forma ilegítima. Consiste em técnicas usadas para inter-
romper a disponibilidade ou comprometer a integridade, através da
manipulação dos processos de negócio e operacionais, que por vezes
podem parecer legítimos, mas foram alterados de modo a refletir os
2.3. MITRE ATT&CK 19

objetivos do adversário. Esta tática pode incluir destruição ou cifra de

dados, disrupção do normal funcionamento de serviços e máquinas e
corrupção do firmware das máquinas infetadas.

2.3.4 Vetores de uso

Como a plataforma ATT&CK é uma fonte de informação valiosa, podendo
ser utilizada com diversos fins, dos quais se destacam os seguintes:

• Threat Intelligence A plataforma pode ser usada por qualquer organi-

zação que pretenda montar uma defesa orientada a ameaças, visto que
descreve os TTPs e comportamentos adversários. Desta forma torna-se
possível a comparação entre grupos APT, de forma a endereçar alguns
dos problemas identificados anteriormente, nomeadamente a falta de
uma taxonomia comum. A Cyber Threat Intelligence estuda aquilo que
os adversários fazem e com base nessa informação, melhora o processo
de tomada de decisão[22].

• Detection and analytics Construir processos para detetar técnicas ATT&CK

é substancialmente diferente das técnicas de deteção habituais. Em
vez de serem identificadas as técnicas que são conhecidas por serem
maliciosas e bloqueá-las, as análises baseadas no ATT&CK envolvem
a recolha de logs e eventos acerca da atividade no sistema e utiliza-
os para identificar comportamentos suspeitos, descritos na plataforma
ATT&CK[31].

• Adversary Emulation and Red Teaming Exercício de red teaming, que

imita uma ameaça conhecida, de modo a definir as ações e compor-
tamentos que a red team usa. São construídos cenários para testar
certos aspetos de uma técnica. A red team segue o cenário enquanto
opera na rede alvo, de modo a testar como os mecanismos de defesa se
comportam tendo em conta a ação dos adversários emulados[28].

• Assessments and Engineering Tem como objetivo fornecer dados úteis

aos engenheiros de segurança, de modo a efetuar algumas melhorias
nos processos de defesa. Este processo pode ser descrito nos seguintes
três passos:[2]

1. Perceber como é que as tecnologias de defesa se comportam pe-

rante as técnicas do ATT&CK,
2. Identificar as lacunas mais prioritárias na cobertura atual do sis-
tema,
20 CAPÍTULO 2. CONCEITOS

3. Modificar as defesas, ou adquirir novas, para endereçar as lacunas.

Para o desenvolvimento deste projeto a matriz foi, numa primeira fase,

estudada de forma exaustiva, e depois utilizada como referência na imple-
mentação dos cenários de ataque, visto que documenta de forma apelativa
as técnicas empregues pelos grupos APT. Todas as técnicas utilizadas nos
cenários implementados encontram-se diretamente mapeadas com a matriz
MITRE ATT&CK.

2.4 Emulação de adversários

Hoje em dia, a maioria das avaliações de segurança estão fortemente focadas
nas defesas de pré-compromisso, ou seja, o quão bem a organização con-
segue prevenir uma intrusão. As red teams avaliam as infraestruturas de
uma organização através de análise de vulnerabilidades e testes de penetra-
ção no sistema, simulando ataques sofisticados, o mais realistas possíveis. No
entanto, os mecanismos de defesa pós-compromisso também tem especial im-
portância, e também devem ser tidos em conta no desenho de infraestruturas
seguras. Ao conduzir, por exemplo testes de penetração (Penetration Tes-
ting), apenas é avaliada a resiliência de um sistema em parar uma intrusão
deixando, muitas vezes, aspetos relevantes para trás, como por exemplo, a
capacidade de deteção de exfiltração de dados.
O conceito de Emulação de Adversários consiste em, com base na infor-
mação que se encontra ao alcance da organização, seja ela pública ou privada,
recriar o modo de operação de um grupo APT, seguindo as mesmas TTPs
e chegar a um objetivo final similar, com o maior grau de aproximação da
realidade possível. A tabela 2.1 contrapõe as principais diferenças entre o
penetration testing e a emulação de adversários.

Penetration Testing Emulação de Adversários

Identificar e explorar vulnerabilidades Avaliar o quão resiliente é
num sistema de modo a avaliar a uma organização face à atividade
segurança do mesmo. de um grupo APT.
Foco num âmbito específico Foco na execução de um cenário
(aplicações,rede,etc.). predefinido.
Maior foco na prevenção, menos Foco tanto na prevenção como na
foco na deteção. deteção.

Tabela 2.1: Penetration Testing versus Emulação de Adversários

A recriação da ativade não se limita apenas às técnicas de intrusão (pré

2.4. EMULAÇÃO DE ADVERSÁRIOS 21

compromisso), mas também recria a atividade realizada nos sistemas após

a intrusão (pós-compromisso), como recolha de informação e credenciais,
escaladas de privilégios ilegítimas, possíveis movimentos laterais e exfiltração
da informação recolhida.
Ao seguir a esta abordagem, a organização pode realmente descobrir o
grau de resiliência que as suas infraestruturas têm, contra a atividade de uma
ameaça em específico.
A emulação de adversários ajuda as organizações a perceberem melhor
como um ataque organizado afetaria a sua infraestrutura, dando resposta às
seguintes três questões:

• Como é que um ataque dirigido especificamente a uma organização se

manifestaria na infraestrutura da mesma?

• O que poderia fazer o atacante com o acesso obtido?

• Quão robusta é a postura de segurança atual da organização, e o quão

eficiente é a previnir, detetar e remediar um ataque dirigido?

De forma a tornar os cenários emulados o mais realistas possíveis, a ati-

vidade da APT a emular, deve ser recriada de forma realista. Assim que
o grupo a emular for escolhido, por norma, tendo em conta a indústria à
qual a organização pertence e os grupos de ataque que no passado mostra-
ram especial interesse por essas mesmas indústrias, devem ser identificados
as táticas, técnicas e procedimentos usados por esses grupos, e adquiridas
as ferramentas utilizadas pelo grupo (quando não maliciosas) ou recriadas
de forma fidedigna. Após todo esse processo o cenário deve ser executado,
recriando passo a passo toda a atividade do grupo emulado.
22 CAPÍTULO 2. CONCEITOS
Capítulo 3

Estado da Arte

Neste capítulo serão apresentados os requisitos que o projeto deverá cumprir.

São também apresentadas e qualificadas várias ferramentas estudadas para
cada componente do projeto.

3.1 Análise de requisitos

Os requisitos funcionais do projeto foram levantados de acordo com a pro-
posta de estágio e as necessidades da entidade acolhedora. Estes requisitos
permitem prioritizar certos aspetos do projeto o que permite uma melhor
metodologia de trabalhos.

3.1.1 Escala das prioridades

Os requisitos do projeto foram definidos com base nas seguintes prioridades:
• Must Have - requisito indispensável, normalmente atribuído a aspetos
do núcleo do projeto, sem os quais o projeto fica inviabilizado.
• Should Have - requisito importante, embora não seja essencial, sem ele
o produto final será desvalorizado.
• Nice to Have - aspetos laterais, acrescentam valor ao projeto, mas a
sua ausência não se torna penalizadora

3.1.2 Requisitos Funcionais

De acordo com as necessidades da Cipher e após dialogo permanente com a
mesma, foram definidos os seguintes requisitos funcionais para o projeto a
desenvolver:

23
24 CAPÍTULO 3. ESTADO DA ARTE

• RF1- Implementação de cenários de ataque mapeados com a atividade

de grupos Advanced Persistent Threat (APT).

• RF2- Execução dos cenários de ataque implementados.

• RF3- Definir e implementar modelo de avaliação de maturidade da

infraestrutura testada.

• RF4- Sugerir soluções que visem dar resposta, às técnicas que a infra-
estrutura não conseguiu responder.

• RF5- Permitir a orquestração dos cenários de ataque implementados

anteriormente.

• RF6- Fornecer informação detalhada sobre as técnicas detetadas, blo-

queadas e executadas, bem como métricas e grafismos relevantes.

• RF7- Desenvolver aplicação que permita interligar as várias compo-

nentes utilizadas para satisfazer os requisitos anteriores.

A relação entre os requisitos funcionais e as prioridades encontra-se explícita

na tabela 3.1:

ID Prioridade
RF1 Must have
RF2 Must have
RF3 Must have
RF4 Should have
RF5 Should have
RF6 Should have
RF7 Nice to have

Tabela 3.1: Prioridades dos requisitos funcionais.

3.1.3 Atributos de Qualidade

Emulação de adversários
Os seguintes atributos serão usados para avaliar as plataformas e ferramentas
a utilizar na emulação de adversários:
3.2. ESTADO DA ARTE 25

• Automação - A plataforma deve permitir que os cenários de ataque

sejam facilmente automatizados de forma a tornar a sua repetição e
execução o menos complexas possíveis.

• Controlo - O processo de execução de ataques deve ser facilmente con-

trolado pelo operador, podendo este pausar, parar e repetir todas as
etapas do cenário. A plataforma deve ainda deixar claro o ponto de
execução dos ataques e resultados do mesmo.

• Realismo - Os cenários de ataque e a sua execução deverão aproximar-

se o máximo possível daquilo que os atacantes são observados a realizar
em sistemas reais.

• Portabilidade - Os cenários de ataque devem ser facilmente utilizados

nas várias versões dos sistemas. Para tal, não devem depender de ca-
racterísticas ou software específico. Idealmente, os cenários deverão ser
executados apenas com recurso a ferramentas do sistema ou a software
standalone entregado como payload (ficheiros entregues para auxiliar
a execução de um ataque). A plataforma a usar deve poder ser exe-
cutada em qualquer sistema operativo sem necessitar de configurações
adicionais no mesmo.

Modelo de avaliação de maturidade

Os seguintes atributos serão usados para avaliar as metodologias de avaliação
da infraestrutura de segurança:
• Portabilidade - O modelo de avaliação deve ser facilmente aplicável a
diversos sistemas e infraestruturas, independentemente das tecnologias
e mecanismos de segurança utilizados no mesmo.

• Repetibilidade - O modelo de avaliação deve ser facilmente iterável,

podendo ser facilmente aplicável de forma sucessiva.

• Escalabilidade - O modelo deve poder ser aplicado independentemente

do numero de técnicas ou cenários a avaliar.

3.2 Estado da arte

3.2.1 Escala de avaliação dos requisitos de qualidade
Para tornar as ferramentas comparáveis e facilitar o processo de escolha de
ferramentas será atribuída uma nota de zero a quatro a cada um dos requisitos
26 CAPÍTULO 3. ESTADO DA ARTE

de qualidade definidos anteriormente. A tabela 3.2 expressa o significado de

cada uma das notas:

Nota Definição
1 Não permite
2 Permite Pouco
3 Permite
4 Permite bastante

Tabela 3.2: Escala a utilizar na avaliação de ferramentas.

3.2.2 Plataformas Simulação/Emulação de Ataques

De seguida serão apresentadas várias plataformas estudadas para o efeito de
simulação ou emulação de ataques, todas elas open source:

Infection Monkey
O Infection Monkey (figura 3.1) é uma ferramenta de Breach and Attack
(tecnologia de simulação de ataques conhecidos) de código aberto que avalia a
a resiliência de uma infraestrutura, otimizada para ambientes em cloud/data
center. Tem uma arquitetura de Command and Control (C2), o que obriga
a instalação de um Remote Access Trojan (RAT) (agente que permite o
controlo da máquina de forma remota) nos terminais. As ferramentas de
anti-vírus por norma classificam o RAT utilizado pelo Infection Monkey como
malicioso, o que obriga a que estas estejam desativadas durante o decorrer das
operações. O emulador dá a possibilidade de escolher o primeiro endpoint a
infetar, controlar os endpoints que este deve atacar, ou simplesmente deixar
a ferramenta correr e ver que tipo de vulnerabilidades esta encontra. A
ferramenta utiliza Tactics, Techniques, and Proceduress (TTPs) utilizadas
por adversários reais, que pecam por serem poucas e pouco versáteis.
Notavelmente, as técnicas usadas pela ferramenta, quando executadas
manualmente e sem o RAT, geralmente conseguem iludir uma grande parte
dos sistemas anti-virus.
No geral, o Infection Monkey é um bom emulador para testar as defesas
de uma rede, no que diz respeito ao acesso inicial e aos movimentos laterais e
há quem a considere mais próxima a uma ferramenta de Penetration Testing
(PenTesting) do que própriamente de emulação de adversários. A tabela
3.3 revela a classificação atribuída ao Infection Monkey, tendo em conta os
requisitos de qualidade definidos:
3.2. ESTADO DA ARTE 27

Figura 3.1: User Interface do Infection Monkey [26]

Requisito Automação Controlo Realismo Portabilidade

Nota 4 2 3 3

Tabela 3.3: Avaliação atribuída ao Infection Monkey

Atomic Red Team

O Atomic Red Team (figura 3.2) é um repositório de testes atómicos que

podem ser executados rápidamente por qualquer equipa de segurança. Estes
testes podem ser executados através da Powershell, Command Line e Shell.
São compativeis com a maioria dos sistemas operativos, e também dispõe de
uma Application Programming Interface (API) escrita em Ruby.
Esta plataforma possui uma framework escrita em Python que permite a
automação da execução dos testes atómicos.
Possui também uma grande quantidade de técnicas para as várias fases
da kill chain, que se encontram mapeadas com a matriz MITRE ATT&CK.
Permite ainda adicionar novas implementações de técnicas. Maior parte das
técnicas aqui implementadas conseguem passar despercebidas aos sistemas
de anti-virus.
Esta plataforma carece de capacidades de logging, remoção de vestígios e
de documentação e requer alguns conhecimentos de cibersegurança para ser
utilizada. No entanto trata-se de uma base de dados que contém técnicas
implementadas, que é uma ajuda preciosa no desenvolvimento de cenários de
28 CAPÍTULO 3. ESTADO DA ARTE

Figura 3.2: Exemplo de documentação de técnica do Atomic Red Team [4]

ataque. A tabela 3.4 revela a classificação atribuída ao Atomic Red Team,

tendo em conta os requisitos de qualidade definidos:

Requisito Automação Controlo Realismo Portabilidade

Nota 2 3 3 4

Tabela 3.4: Avaliação atribuída ao Atomic Red Team

Red Team Automation

A Red Team Automation (figura 3.3) é uma framework de scripts construída
para ajudar as blue teams a testar as suas capacidades de deteção contra
atividade maliciosa. A framework é composta por scripts Python que recria
mais de cinquenta técnicas da matriz ATT&CK.
Esta framework não tem componentes centrais como um servidor de C2.
Como foi desenvolvida em Python, apenas pode ser utilizada em ambien-
tes que suportem a linguagem e em máquinas que tenham o Python insta-
lado. Alternativamente podem ser usadas ferramentas que permitam gerar
um executável através de um ficheiro Python, permitindo a sua execução
em plataformas que não tenham o Python instalado. Para usufruir de todas
as vulnerabilidades que a framework explora , são necessárias ferramentas
adicionais, como por exemplo o PsExec [24].
A documentação fornecida pelos autores da framework é algo escassa, e
apenas cobre o processo de instalação e execução. Os scripts possuem alguns
3.2. ESTADO DA ARTE 29

Figura 3.3: Scripts da Red Team Automation [25]

Requisito Automação Controlo Realismo Portabilidade

Nota 3 2 3 2

Tabela 3.5: Avaliação atribuída ao Red Team Automation

comentários que permitem identificar a técnica que os mesmos recriam e

descrevem o modo de funcionamento geral.
Os scripts podem ser ser combinados para recriar um ataque com vários
procedimentos. Podem ser adicionados outros scripts utilizando Python,
o que obriga o utilizador a ter conhecimentos da linguagem para usar a
plataforma de modo efetivo.
A plataforma não fornece qualquer tipo de log que permita documentar
a execução do scripts, no entanto possui um mecanismo de reversão das
técnicas executadas, o que pode ser útil para repor os sistemas em que foram
executados os testes. No geral a framework é útil para testar infraestruturas
e simular ameaças reais. O facto da plataforma assentar em Python torna
o processo de adição de técnica avançadas mais simples. As pontuações
atribuídas ao Red Team Automation encontram-se explícitas na tabela 3.5.
30 CAPÍTULO 3. ESTADO DA ARTE

APT Simulator
O APT Simulator (figura 3.4) é um script batch que procura ser o mais sim-
ples possível e reduzir ao máximo a interação com o utilizador. O script
corre sobre Windows sem serem necessárias outras ferramentas e configura-
ções adicionais. Não existe suporte para outros sistemas operativos.

Figura 3.4: APT Simulator - Diálogo Inicial [29]

A documentação surge na forma de comentários nos próprios scripts, em-

bora a página do Github [29] forneça bastante informação acerca da ferra-
menta, nomeadamente o âmbito, funcionalidades e processo de instalação. A
adição de novos procedimentos e criação de novos ataques pode ser feita atra-
vés da edição e junção dos ficheiros batch, embora para tal sejam necessários
alguns conhecimentos relacionados com as tecnologias envolvidas. Podem
ser também adicionadas novas ferramentas a utilizar durante o ataque, por
exemplo, ferramentas de escalada de privilégios. Para tal basta adiciona-las
à pasta da framework e escrever um script batch que faça uso das mesmas.
A maioria das técnicas já implementadas no APT Simulator são detetadas
pelo software de anti-vírus. No Github [29] da ferramenta é fornecida ainda
informação sobre os dispositivos de segurança (anti-vírus, sistema de dete-
ção de intrusões,Endpoint Detection and Response (EDR),etc.) que devem
detetar cada uma das técnicas implementadas.
3.2. ESTADO DA ARTE 31

A plataforma peca pela falta de capacidades de logging, falta da compo-

nente de C2 e funcionalidade de reverter os testes executados.
No geral a plataforma é competente para testar a capacidade de deteção
a nível do endpoint(máquina). É de fácil implementação e de rápida execu-
ção, fornecendo capacidades básicas de testagem da segurança da máquina.
No entanto torna-se ineficaz na execução de cenários mais compostos e com-
plexos. A tabela [aptsimtab] ilustra a pontuação atribuída à ferramenta,
conforme os requisitos de qualidade definidos anteriormente.

Requisito Automação Controlo Realismo Portabilidade

Nota 3 2 3 2

Tabela 3.6: Avaliação atribuída ao APT Simulator

CALDERA
O CALDERA (figura 3.5) é uma framework de cibersegurança desenhada
para simular cenários de ataque. A arquitetura da framework é composta
por duas partes:

• Núcleo - Código da framework, constituido por um servidor de C2 assín-

crono com uma Represantational State Transfer (REST) API (API de
um serviço web que segue as linhas orientadoras da arquitetura REST)
e uma web interface.

• Plugins - Repositórios adicionais de código que adicionam novas funcio-

nalidades à framework, como agentes, novas interfaces gráficas, coleções
de técnicas, etc.. Os plugins disponibilizados à data, são os seguintes:

– Sandcat - Agente (aplicação que permite o controlo remoto da má-

quina onde irá decorrer o ataque) padrão. Escrito em GoLang o
que permite a compatibilidade entre plataformas e sistemas opera-
tivos. Comunica com o CALDERA no porto Transmission Control
Protocol (TCP) 8888.
– Mock - Adiciona um conjunto de agentes simulados ao CALDERA
que permite executar um cenário de ataque sem ter nenhuma má-
quina (física ou virtual) para o efeito.
– Terminal - Adiciona capacidades de reverse-shell (terminal) ao CAL-
DERA, ou seja permite a interação manual e inserção de comandos
nas máquinas alvo.
32 CAPÍTULO 3. ESTADO DA ARTE

Figura 3.5: Interface do CALDERA [11].

– Stockpile - Adiciona um repositório de técnicas e cenários de ata-

que pré-implementados.
– Response - Plugin que permite a automatização de resposta a inci-
dentes nas máquinas comprometidas, o que permite implementar
medidas de remediação e resposta aos cenários de ataque execu-
tados.
– Compass - Permita a criação de grelhas para visualizar os cenários
de ataque implementados e as técnicas que os mesmos cobrem na
MITRE ATT&CK. Para tal, utiliza o ATT&CK Navigator (figura
3.6).
– Caltack - Adiciona o website público da MITRE ATT&CK ao
CALDERA. Útil para referenciar a matriz, em casos em que o
operador não consegue ter acesso à Internet.
– SSL - Coloca o CALDERA a correr sobre HyperText Transfer
Protocol Secure (HTTPS). Quando carregado, o CALDERA des-
poleta o serviço de HAProxy na máquina hospedeira. Apenas
disponível quando o servidor do CALDERA corre sobre Linux ou
3.2. ESTADO DA ARTE 33

macOS. Necessita a instalação do HAProxy.

– Atomic - Carrega o repositório Atomic Red Team e respetivos
testes, já apresentado anteriormente, para o CALDERA.
– GameBoard - Permite a monitorização de de atividades de red
team e de blue team. Atribui um sistema de pontuação e decide
qual o lado que ganhou.
– Human - Permite a construção de "humanos"que executam tare-
fas no sistema alvo, de modo a ofuscar as ações do cenário. As
tarefas simuladas vão desde a navegação com um browser, até à
inserção de comandos na linha de comandos e criação de fichei-
ros, simulando a atividade de um utilizador comum. Útil também
para perceber a taxa de falsos positivos que o sistema de segurança
gera.
– Training - Permite a um utilizador ganhar um certificado que
prova a proficiência com a plataforma CALDERA.

Figura 3.6: Interface do ATT&CK Navigator[1]

De momento os agentes (aplicação que permite o controlo remoto da má-

quina) que o CALDERA disponibiliza podem correr em ambientes Windows,
34 CAPÍTULO 3. ESTADO DA ARTE

Linux e macOS. Estes agentes podem utilizar diversos protocolos para co-
municar com o servidor de C2 (servidor do CALDERA), como o protocolo
HyperText Transfer Protocol (HTTP) ou recorrendo a um socket TCP.
A plataforma tem uma interface gráfica amigável, onde se pode consultar
o estado dos agentes, configurar os mesmos, consultar a os cenários de ataque
existentes, criar novos cenários de ataque e despoletar um ataque num con-
junto de máquinas alvo. Às técnicas criadas podem ser adicionados payloads
(ficheiros ou contéudo a ser transportado) para auxiliarem na execução das
técnicas, como executáveis, ficheiros zip, entre outros.
As capacidades de controlo e logging do CALDERA são no geral boas,
visto que ao operar a plataforma, consegue-se sempre perceber aquilo que
está a acontecer no sistema alvo, e é possível pausar, reiniciar, saltar téc-
nicas e concluir o ataque sempre que assim desejado. A plataforma inclui
também um mecanismo de cleanup, ou seja sempre que seja terminada a
execução de um cenário de ataque, as ações executadas no mesmo são rever-
tidas. A variedade de agentes, permite também utilizar diversos protocolos
de comunicação sobre o canal de C2, podendo explorar algumas combinações
que outras plataforma não permitem, por exemplo, se por alguma razão, o
tráfego HTTP não for permitido na rede alvo, pode ser usado o agente TCP.
De todas as soluções estudadas, esta é a mais completa e robusta, com
atualizações contínuas, por norma mensais, suporte contínuo por parte da
comunidade, que se disponibiliza para esclarecer dúvidas ou até mesmo im-
plementar certos aspetos que sejam pedidos (feature request. Toda esta inte-
ração pode ser feita através da página do Github.[11] É também a plataforma
que permite mais portabilidade, sendo que os agentes podem ser lançados nos
sistemas alvos sem necessidade de instalar algum tipo de software. A pontu-
ação atribuída ao CALDERA encontra-se explícita na tabela 3.7

Requisito Automação Controlo Realismo Portabilidade

Nota 4 4 3 4

Tabela 3.7: Avaliação atribuída ao CALDERA

Análise Comparativa das Ferramentas

Na tabela 3.8 é sumarizada a avaliação atribuída às ferramentas de simula-
ção/emulação de ataque apresentadas anteriormente.
Com base no estudo efetuado, e também nas orientações recebidas pela
entidade acolhedora, que desde o inicio do estágio indicou que provavelmente
o CALDERA seria a plataforma que ia mais de encontro aquilo que são os
objetivos do estágio, a plataforma escolhida foi o CALDERA, tanto pela
3.2. ESTADO DA ARTE 35

Requisito
Automação Controlo Realismo Portabilidade Média da avaliação
Ferramenta
Infection Monkey 4 2 3 3 3.0
Atomic Red Team 2 3 3 4 3.0
Red Team Automation 3 2 3 2 2.5
APT Simulator 3 2 3 2 2.5
CALDERA 4 4 3 4 3.75

Tabela 3.8: Comparação da avaliação atribuída as ferramentas de simula-

ção/emulação de ataques.

sua capacidade de automação, como pela sua estrutura e modo de operação

bem-definido, por possibilitar uma capacidade de controlo e logging bastante
avançada, e também por ser uma ferramenta em constante evolução, bem
aceite pela comunidade de cibersegurança.

3.2.3 Modelos de avaliação de maturidade

Após pesquisa, não foi encontrado nenhum modelo que permitisse a avaliação
de uma infraestrutura de segurança que fosse de encontro aos objetivos do
estágio. Então, optou-se por criar um modelo que fosse de encontro aquilo que
é pretendido do estágio. O modelo e a validação dos requisitos de qualidade
serão apresentados em capítulo próprio (Capítulo 5).
36 CAPÍTULO 3. ESTADO DA ARTE
Capítulo 4

Emulação de adversários

Ao longo deste capítulo serão apresentados os cenários de ataque que foram

implementados com base nos grupos APT estudados.

4.1 APT1
4.1.1 Enquadramento
Origem
O grupo APT1, também conhecido por Comment Crew ou Comment Group,
é um grupo de ciberespionagem chinês que foi associado ao 2nd Bureau of
the People’s Liberation Army vulgarmente referido pelo seu MUCD Unit
61398. Acredita-se que este grupo empregue algumas centenas ou até mesmo
milhares de pessoas, com base na infraestrutura física possuída pela mesma.
Acredita-se que parte desta infraestrutura resida na área de Pudong New Area
em Shangai. O edifício central ao complexo nesta localização tem 12 andares
e foi construído em 2007, a China Telecom, empresa estatual, forneceu uma
infraestrutura especial de fibra ótica ao edifício, em nome da defesa nacional.
Por norma a Unit 61398 exige que o seu pessoal tenha conhecimentos na área
de segurança informática, redes e administração de sistemas e proficiência em
inglês.

Alvos e Motivações
O início das atividades deste grupo remonta a 2006. Desde então foi obser-
vado a comprometer 141 organizações espalhadas por 20 indústrias diferentes,
o que mostra que este grupo não têm foco particular em uma dada industria,
sendo o seu objetivo servir os interesses nacionais chineses, sendo os alvos

37
38 CAPÍTULO 4. EMULAÇÃO DE ADVERSÁRIOS

definidos de forma coincidente com aqueles que o governo identifica como

alvos estratégicos para o desenvolvimento do país, incluindo 4 das 7 indús-
trias que a China identificou no seu 12o plano quinquenal. Das 141 vitimas
deste grupo, 87% estão sediadas em países cuja a língua oficial é o inglês.
Os ataques observados, tiveram como alvo uma vasta gama de indústrias,
incluindo: Tecnologia da Informação, Transporte, Eletrónica de alta gama,
Serviços Financeiros, Navegação, Serviços Legais, Serviços de Engenharia,
Media, Agricultura, Telecomunicações, Químicos e Farmacêuticos, Energia,
Investigação Científica, Administração Pública, Construção e Fabrico, Ae-
ronáutica e Defesa, Educação, Serviços Médicos e Industria metalúrgica e
mineira.

Infraestrutura

Estima-se que este grupo controle milhares de sistemas de modo a suportar

as suas atividades de intrusão. Foram observados a estabelecer um mínimo
de 937 de servidores de Command and Control hospedados em 849 endereços
IP distintos, distribuídos por 13 países diferentes. A maioria desses endereços
pertencem a organizações registadas na China (709) seguida pelos Estados
Unidos (109). Ao longo dos últimos anos foram confirmados pelo menos 2551
FQDNs atribuídos ao APT1. As estimativas apontam para que a infraestru-
tura deste grupo inclua pelo menos 1000 servidores. Dado o volume, duração
e tipo de atividade observado, conclui-se que o grupo tem o suporte direto
de linguistas, investigadores, autores de malware, e especialistas de várias
industrias.

Operação

O grupo apresenta uma metodologia de ataque bem definida, desenhada para

roubar um grande volume de dados. Assim que o acesso ao sistema é estabe-
lecido, o grupo volta a visitar o sistema periodicamente ao longo de meses ou
anos, de modo a roubar propriedade intelectual, como processos de fabrico,
planos de negócio, resultados de testes, acordos de parceria, emails e listas
de contactos. De modo a conseguir realizar este tipo de tarefas, são empre-
gues algumas ferramentas e técnicas exclusivas a este grupo, incluindo duas
ferramentas desenhadas para roubar emails - GETMAIL e MAPIGET. Este
grupo mantém, em média, o acesso a um sistema comprometido pelo período
de 356 dias.
4.1. APT1 39

4.1.2 Ciclo de vida do ataque

O grupo APT1 apresenta uma metodologia de ataque bem definida. Por
norma começam com campanhas de Spearphishing, procedendo à instalação
de armas digitais exclusivas e terminam com a exportação dos dados para a
China.

Compromisso Inicial
Representam os métodos que os intrusos empregam para penetrar a infra-
estrutura da organização. De um modo geral a maioria dos grupos APT
opta pelo uso de Spearphishing, e o APT1 não é excepção. Os emails de
phishing por norma contêm um anexo malicioso, ou um hyperlink para um
ficheiro malicioso. O assunto e o texto no email, por norma são familiares
ou relevantes para o alvo, muitas das vezes sendo usadas contas de web-
mail, com nomes de pessoas pertencentes à organização, que são familiares
ao alvo, como nomes de colegas. Por norma, os ficheiros anexos aos emails,
são ficheiros .ZIP, embora também tenham sido empregues ficheiros, que apa-
rentemente teriam a extensão .pdf, mas o nome do ficheiro teria 119 espaços
a seguir a ".pdf"seguidos de .exe, a verdadeira extensão do ficheiro.

Estabelecimento de acesso
Envolve ações que garantam controlo sobre a rede alvo, a partir de fora da
infraestrutura. O grupo APT1 estabelece o acesso assim que o que os des-
tinatários dos emails, executem o ficheiro malicioso e um backdoor é conse-
quentemente instalado no sistema. Um backdoor é um software que permite
a um intruso enviar comandos ao sistema comprometido, de forma remota.
Em quase todos os casos, os backdoor estabelecem as conecções com o servi-
dor "Command and Control"intruso, de modo a contornar as firewalls, que
por norma são bastantes restritas nas conecções que são iniciadas de fora do
sistema, mas que se tornam permissivas nas coneções iniciadas do sistema
para o exterior. Embora o grupo APT1 ocasionalmente empregue backdoors
públicos, como o Poison Ivy ou Gh0st RAT, a maioria das vezes eram usados
backdoors desenvolvidos pelo grupo, para tal fim.
O backdoor mais observado a ser empregue pelo APT1, é o WEBC2, um
backdoor beachhead. Os beachhead backdoors são por norma minimalistas,
oferecendo funcionalidades reduzidas, como recolha de ficheiros, recolha de
informações básicas do sistema, e ativação da execução de outras funcionali-
dades mais significativas, como os backdoors comuns. O backdoor WEBC2
foi concebido para obter uma página web de um servidor Command and
control, e intrepertar dados entre as tags HTML, como comandos.
40 CAPÍTULO 4. EMULAÇÃO DE ADVERSÁRIOS

Outro backdoor bastante utilizado por este grupo é o BISCUIT, um back-

door standard, que oferece ao intruso de habilidades mais avançadas, como:

• Criação, modificação, remoção e execução de programas.

• Listagem, arranque e pausa de processos.

• Alterações ao Registry do sistema.

• Captura de teclas premidas e movimentos de cursor.

• Captura de passwords.

• Log off, e encerramento do sistema.

O grupo tentou camuflar as comunicações com o serivdor C2, através

da imitação de protocolos, como: MSN Messenger, Jabber e Gmail Calen-
dar. Quando os responsáveis pela defesa da infraestrutura observam este
tráfego, normalmente ele é dado como seguro. Adicionalmente, o grupo uti-
liza também encriptação SLL, estabelecendo assim um túnel SLL entre os
dispositivos.

Escalada de Privilégio
O grupo APT1 por norma, utiliza credenciais legítimas para aceder aos siste-
mas, levantando assim menos suspeitas. O grupo usa predominantemente fer-
ramentas de domínio público para este fim, como: Mimikatz,lslass,pwdump
e fgdump.

Reconhecimento interno
Nesta fase é recolhida informação acerca do ambiente alvo. Tendencialmente
são usadas ferramentas do sistema para este fim. O APT1 foi observado a
utilizar um script batch para automatizar e tornar este processo mais ex-
pedito. O script realizava as seguintes operações e guardava o output num
ficheiro de texto :

• Mostrar a configuração de rede do sistema alvo.

• Listar os serviços que estão a correr no sistema alvo.

• Listar os processos que estão a correr no sistema alvo.

• Listar as contas no sistema.

4.1. APT1 41

• Listar as contas com privilégios de administrador.

• Listar as conecções de rede ativas.

• Listar as partilhas de rede ativas.

• Listar outros sistemas na rede.

• Listar computadores e contas conforme o grupo ("domain controllers",

"domain users", "domain admins", etc).

Movimentos Laterais

Assim que o intruso tem acesso à rede e credenciais legitimas, torna-se trivial
para o mesmo mover-se na rede, de forma transparente. O intruso pode-se
ligar a recursos partilhados em outros sistemas, e podem executar comandos
noutros sistemas usando a ferramenta "psexec"desenvolvida pela Microsoft.
Estas ações tornam-se complicadas de detetar visto que são utilizadas cre-
denciais legítimas de um administrador, e visto que os próprios usam essas
mesmas técnicas para realizar operações nos sistemas.

Persistência

Nesta fase, o intruso toma medidas para garantir o acesso contínuo e controlo
de longo prazo nos sistemas alvos. O grupo APT1 alcança isto de 3 formas
distintas:

• Instalação de novos backdoors em vários sistemas Ao longo da

sua estadia na rede, o grupo habitualmente instala novos backdoors, à
medida que penetram novos sistemas. Assim quando um backdoor é
descoberto e eliminado, ainda existem outros backdoors para uso.

• Uso de credenciais legitimas de VPN Utilização de usernames e

passwords roubados para entrarem nas VPNs das vítimas, permitindo
o acesso a tudo o que a vítima também tenha acesso.

• Log in em portais Web Com as credenciais roubadas, os intrusos

podem entrar em portais web e em webmails como o Outlook Web
Access.
42 CAPÍTULO 4. EMULAÇÃO DE ADVERSÁRIOS

Exfiltração
O grupo, antes de retirar os ficheiros recolhidos da rede, comprime-os em
arquivos. Por norma é usada o formato RAR , para garantir que os ficheiros
estão protegidos por password. Após a compressão, os ficheiros são extraídos
da rede por FTP ou pelo canal de Command and Control.

4.2 APT3
4.2.1 Enquadramento
Origem
O grupo APT3, também conhecido por Gothic Panda ou Pirpi, é um grupo
Chinês que os investigadores atribuem ao Ministério da Segurança de Estado
Chinês. Embora havendo uma quantidade limitada de informação acerca
deste grupo, a MITRE desenvolveu um plano de emulação da atividade
deste grupo.[9] Em maio de 2017, um grupo denominado por "instrusion-
truth"correlacionou o grupo APT3 com uma empresa, Guangzhou Boyu In-
formation Technology Company, com sede em Guangzhou, China. Numa in-
vestigação mais profunda foi possível concluir que a empresa, conhecida por
Boyusec, estava a trabalhar para o Ministério da Segurança de Estado Chinês.
Os registos mais antigos de atividade deste grupo remontam a 2010.[7] Em
novembro de 2016, um relatório interno do Pentágono expôs que a Boyusec
e a Huawei, estavam a desenvolver em conjunto produtos de segurança, que
possivelmente contiam backdoors, o que permitia aos Chineses a "captura de
dados e controlo de equipamentos de telecomunicações".[7]

Alvos e Motivações
Este grupo mostrou particular interesse nas seguintes indústrias: Aeroespa-
cial e Defesa , Construção e Engenharia, Alta Tecnologia, Telecomunicações
e Transporte, sendo provavelmente coincidentes com os interesses do Minis-
tério Chinês.[7][9] Tradicionalmente o grupo tinha como alvos preferenciais
organizações Norte Americanas e internacionais, no entanto aparentemente,
por volta de março de 2016, o seu foco primário tornaram-se organizações de
Hong Kong.[9]

Operação
O grupo apresenta uma metodologia sofisticada, empregando uma vasta
gama de ferramentas e técnicas, como zero-day exploits, spearphishing. Os
4.2. APT3 43

relatórios públicos apontam que este grupo teria interesse a exfiltração de in-
formação, nomeadamente propriedade intelectual de natureza industrial.[9]
Foram atribuidas a este grupo as operações Clandestine Wolf, Clandestine
Fox e Double Tap. [5] [21]. Em ambas as operações foram usadas CVEs.

4.2.2 Ciclo de vida do ataque

Compromisso Inicial

O objetivo desta fase é a execução de código e estabelecer o controlo sobre

a infraestrutura alvo. Para tal , foram feitas campanhas de spearphishing
que entegravam anexos e links malignos. Foram também explorados vários
zero-days em vários browsers, no Windows e no Adobe Flash.[9]

Implantação do C2

O trafego C2 é assente sobre o protocolo HTTP, nomeadamente pedidos

HTTP GET, que fornecem um mecanismos de "beacon"periodicamente. O
campo das Cookies contem informação para o servidor C2, que responde com
uma página Web que contem o comando codificado numa tag HTML espe-
cifica. Este grupo também é conhecido por ter utilizado protocolos binários
específicos. Algumas das ferramentas usadas por este grupo também contêm
mecanismos anti-sandbox, que fazem com que o RAT pause entre execuções.
Para além disso, também foram observadas algumas aplicações do protocolo
SSL.

Defense Evasion

Muitas das ferramentas open-source usadas pelo grupo, foram modificadas

para previnir a deteção. Ao mesmo tempo o malware observado utiliza téc-
nicas de anti-disassembly, como a obrigatioridade de vários parametros de
linha de comandos para ser executado.

Reconhecimento

Por norma o APT3 realiza o reconhecimento interno, ou com a sua ferra-

menta OSInfo ou com comandos nativos ao Windows. Por norma é dado um
maior enfâse à descoberta e listagem de grupos do dominio com permissões
elevadas , como "Domain Admins2 ou "Enterprise Admins". É também dada
importância à listagem de utilizadores nestes grupos de permissão elevada.
44 CAPÍTULO 4. EMULAÇÃO DE ADVERSÁRIOS

Escalada de Privilégios

De modo a proceder às fases seguintes (recolha de credenciais e persistência),

normalmente torna-se necessário escalar privilégios se o intruso não tiver
controlo de um processo de alta integridade. No entanto o único relato de
escaladas de privilégios locais efetuadas por este grupo é a exploração do
CVE-2014-4113, que passa pela exploração do gestor de janelas, [Link],
que interage com algumas threads da GUI, e o valor retornado por esta
interação não é validado propriamente. Se explorado com sucesso resulta
na escalada de privilégios. É possível que este grupo se apoio no use de
credenciais legitimas, para realizar as suas operações.

Persistência

De modo a garantir o acesso permanente independentemente de interrup-

ções ao funcionamento do sistema, este grupo exploru vários mecanismos,
como por exemplo a criação de serviçoes, a criação de tarefas agendadas,
colocação de scripts na pasta de arranque, manipulação de funcionalidades
acessibilidade (teclas presas), ativação do RDP, criação de contas no sistema.

Acesso a credenciais

Este grupo usou uma vasta gama de ferramentas e técnicas para aceder a
credenciais legitimas. Foram reportados usos de ferramentas como pwdump,
mimikatz, Lazagne e ChromePass. O mimikatz, por exemplo, é injetado
no [Link], responsavél pelo serviço de autenticação WinLogon, e assim
o mimikatz consegue recolher as credenciais em plaintext. Foi observada
também a instalação de Keyloggers, que pode ser usado para a descoberto
de credenciais em outros sistemas.

Movimentos Laterais

O APT3 move-se lateralmente através da rede, usando as credenciais reco-

lhidas e procurando por reuso destas credenciais nov vários sistemas e recur-
sos. O grupo dá prioridade à movimentação para servidores de ficheiros ou
servidores de impressão. Também foi observado o uso de uma ferramenta
especifica ao grupo, denominada RemoteCMD que permite a execução de
comandos em sistemas remotos, operações sobre ficheiros e agendamento de
tarefas.
4.3. OILRIG 45

Exfiltração
Após recolher os ficheiros pretendidos o grupo passa então à exfiltração dos
dados recolhidos. Estes ficheiros são comprimidos e encriptados, armaze-
nados na reciclagem do sistema, e depois exfiltrados, através do protocolo
HTTPS no porto 443, no entanto também já foram observadas exfiltrações
com base em encriptação SSL e com base em HTTP.

4.2.3 Emulação do atividade do grupo

De forma a emular o comportamento do grupo, dentro das limitações que
um cenário de simulação põe, seguiu-se uma abordagem concordante com a
seguinte figura:

4.3 OilRig
4.3.1 Enquadramento
Origem
O grupo OilRig, ou APT34, é um grupo de origem Iraniana, que opera pri-
mariamente no Médio Oriente, e tem como alvos organizações na região. Pelo
que se observou, as primeiras campanhas atribuídas a este grupo remontam a
2014. O grupo foi observado a comprometer a cadeia de valores de várias or-
ganizações, explorando assim as relações de confiança entre várias entidades,
de modo a atingir os seus alvos primários.[23]

Alvos e Motivações
O APT OilRig por norma tem como alvos organizações a operar no Médio
Oriente do setor financeiro, energético, governamental e de telecomunicações.
A atividade deste grupo está provavelmente associada ao governo Iraniano,
visto que foca os seus esforços em adquirir informação que sirva os interesses
governamentais do País, e também pelo facto da infraestrutura usada ser
Iraniana.[3]

Operação
Os ataques atribuidos a esta organização têm como suporte um grande foco
na engenharia social, ao invés de vulnerabilidades de software. Este facto, no
entanto, não comprova a falta de recursos e know-how do grupo, visto que
46 CAPÍTULO 4. EMULAÇÃO DE ADVERSÁRIOS

Figura 4.1: xxxx

o grupo demonstrou maturidade ao longo de várias fases da cadeia de com-

promisso como, por exemplo, malware personalizado, Tunneling do tráfego
resultante da comunicação com o servidor C2, através do protocolo DNS, uso
de backdoors personalizados, entre outros.[30]
4.3. OILRIG 47

4.3.2 Ciclo de vida do ataque

Compromisso Inicial

Como já referido, o mecanismo principal de compromisso é a engenharia

social, através de campanhas de phishing tanto através de anexos maliciosos,
como de URLs comprometidos. No entanto, o grupo foi também observado
a usar algumas vulnerabilidades que teria sido corrigidas recentemente, para
comprometer o alvo.

Defense Evasion

As ferramentas e malware usados pelo grupo, terão sido testadas pelo mesmo,
numa fase prévia ao ataque, de modo a contornar os mecanismos de defesa
da infraestrutura alvo.

Acesso a credenciais

Após ser obtido o acesso ao sistema, este grupo procede à recolha de creden-
ciais. Os mecanismos usados são, à semelhança da maioria dos outros grupos,
ferramentas que permitem o despejo (dumping) das credenciais, como o Mi-
mikatz.

Movimentos Laterais

De modo a mover-se pelos vários sistemas da infraestrutura alvo, o grupo

usa as credenciais obtidas na fase anterior, deixando assim poucos vestígios
desse movimento.

Persistência

O grupo OilRig dá preferência ao uso de ferramentas padrão para manter

o acesso ao sistema, ao invés das suas próprias ferramentas. O grupo foi
observado a usar os protocolos RDP e SSH para aceder aos sistemas com-
prometidos.

Exfiltração

Para exfiltrar a informação recolhida, o grupo dá preferencia ao uso do pro-

tocolo FTP.
48 CAPÍTULO 4. EMULAÇÃO DE ADVERSÁRIOS

4.3.3 Emulação do atividade do grupo

De forma a emular o comportamento do grupo, dentro das limitações que
um cenário de simulação põe, segui-se uma abordagem concordante com a
seguinte figura:

Figura 4.2: xxxx

4.4. APT41 49

4.4 APT41
4.4.1 Enquadramento
Origem

A atividade do grupo APT41 é atribuida a indivíduos que trabalham em

nome do governo chinês, promovendo campanhas de ciberespionagem. São
também atribuídas a estes individuos campanhas conduzidas com objetivos
financeiros para ganhos pessoais.

Alvos e Motivações

As observações da atividade do grupo reportam que os seus alvos são consis-

tentemente coincidentes com os interesses nacionais da China, por exemplo,
de mover capacidades de produção para capacidades Pesquisa e Densenvol-
vimento. Estas iniciativas estão delineadas no Plano "Made in China 2025",
anunciado em 2015, e que pretende mudar o foco económico da china para
produtos e serviços de maior valor incluindo, farmacêuticos, semicondutores
e outras industrias de alta tecnologia. Por outro lado, também foram ob-
servadas campanhas com o objetivo explicito de ganho financeiro pessoal,
usando as mesmas ferramentas observadas nas campanhas patrocinadas pelo
estado Chinês. O horário destes ataques sugere que durante o dia, o grupo
conduza atividade relacionada com o estado chinês, e a atividade relacionada
com motivos pessoais, ocorre geralmente em horário noturno, o que sugere
que o grupo promova a atividade relacionada com benefícios pessoais como
uma ocupação de tempos livres. Os principais focos de atividade do grupo
são:

• Industria Médica/Farmaceutica

• Telecomunicações

• Industria Tecnologica

• Industria dos Video Jogos (ganho pessoal)

Os alvos deste grupo alinham-se com os planos de desenvolvimento Chi-

neses, tendo no passado atacando organizações em 14 países, entre os quais:
França, Índia, Itália, Japão, Coreia do Sul, Estados Unidos, Reino Unido,
entre outos.
50 CAPÍTULO 4. EMULAÇÃO DE ADVERSÁRIOS

Operação
O que torna este grupo único é o facto de empregar malware tipicamente
reservado para fins de espionagem, em atividades que caiem fora do âm-
bito dos interesses de estado. Este grupo é altamente sofisticado e inovador,
empregando compromissos da cadeira de valores das organizações, uso consis-
tente de certificados digitais comprometidos, e uso de bootkits, sugerem uma
"know-how"bastante sofisticado e um conjunto de recursos bem estruturado.

4.4.2 Ciclo de vida do ataque

Compromisso Inicial
O grupo emprega várias técnicas para comprometer os seus alvos, incluindo
campanhas de phishing, exploração de relação de confiança entre organiza-
ções, utilização de credenciais roubadas e exploração de vulnerabilidades.

Estabelecimento de acesso
Para este objetivo foram usados maioritariamente malwares que instalam
backdoors nas directorias temporárias do sistema. O grupo foi observado
a mascarar os seus ficheiros e dominios com o nome de software anti-virus
popular:
• [Link]

• [Link]

• [Link]
O grupo utiliza também vulnerabilidades do sistema, nomeadamente a vul-
nerabilidade das "teclas persistentes"para lançar o seu malware nos sistemas
vitima.

Escalada de Privilégios
O grupo eleva os seus privilégios nos sitemas através de ferramentas que
permitam a recolha de credenciais e hashes de passwords. Estas ferramentas
incluem:
• Mimikatz

• ACEHASH

• PwDump
4.4. APT41 51

• NTDSDump

• Windows Credential Editor

Reconhecimento Interno
O APT41 conduz atividades de reconhecimento de sistemas e rede após usar
credenciais comprometidas para entrar noutros sistemas. O grupo utiliza fer-
ramentas do Sistema Operativo, como o "netstat"e o "net share"em conjunto
com malware não público, como as famílias de malware SOGU, HIGHNOON
e WIDETONE.

Movimentos Laterais
Ao avaliar a arquitetura da rede e identificar sistemas de interesse, o grupo
move-se rapidamente para esses sistemas. Em atividade observada no pas-
sado, foram comprometidos vários sistemas espalhados geográficamente, em
menos de 2 semanas. Para tal o grupo utiliza vários métodos, como sessões
de RDP, credenciais roubadas, criação de contas com privilégios elevados,
entre outros.

Persistência
De modo a manter a sua presença no sistema comprometido, foram explora-
dos várias abordagens, a vulnerabilidade das "teclas persistentes", bootkits,
agendamento de tarefas, modificações ao registry e manipulação dos ficheiros
de arranque.

Completar a Missão
O grupo foi observado a criar arquivos RAR dos ficheiros recolhidos. O
grupo foi também observado a comprometer e manipular bases de dados e
a comprometer ambientes de produção. O grupo também foi observado a
encriptar os dados do sistema, o típico ataque "Ransomware".

4.4.3 Emulação da atividade do grupo

52 CAPÍTULO 4. EMULAÇÃO DE ADVERSÁRIOS
Capítulo 5

Modelo de avaliação de
maturidade

53
54 CAPÍTULO 5. MODELO DE AVALIAÇÃO DE MATURIDADE

Percentagem Nota Qualitativa

>97% A+
94% - 97% A
90% - 94% A-
87% - 89% B+
83% - 86% B
80% - 82% B-
77% - 79% C+
73% - 76% C
70% - 72% C-
65% - 69% D+
60% - 64% D
55% - 59% D-
<55% F
Apêndice A

Proposta de Estágio

55
 Departamento de Engenharia Informática e de Sistemas

Proposta de Projeto/Estágio
Ano Letivo de 2019/2020
2º Semestre

Purple Team - Breaking the Cyber Kill Chain

SUMÁRIO

Neste trabalho pretende-se que o aluno simule um conjunto de ataques coordenados a uma
infraestrutura híbrida de sistemas Windows e Linux, testando as diversas fases que compõem a
Cyber Kill Chain, de validando se os mecanismos de defesa existentes na infraestrutura visada,
são capazes de os detetar e/ou parar.

Face aos resultados obtidos, deve ser estabelecido um modelo de avaliação de maturidade à
infraestrutura de segurança implementada nessa rede, que inclua a percentagem de deteções e
prevenções, face aos ataques executados.

Para além do resultado de maturidade, a avaliação deverá procurar definir um roadmap de

integração de soluções que permitam dar resposta a tais ataques. Para tal, deverá o aluno em
ambiente de laboratório, testar mecanismos de defesa que permitam dar resposta aos ataques
que serão simulados.

Estágio destinado a:

Tomás Almeida Ferraz, aluno nº 21270605 / 2017018782

RAMO: Indicar o(s) ramo(s) em que se enquadra:

x Redes e Administração de Sistemas

1. ÂMBITO
As empresas, pelos negócios que processam, dinheiro que movimentam e informação que
possuem, são cada vez mais um alvo preferencial do crime informático.

Este crescimento exponencial de ataques tem levado a que cada vez mais, as empresas invistam
em tecnologia e infraestrutura de segurança, que lhes transmita uma sensação de
impermeabilidade face a estes ataques, algo que nem sempre se verifica.

O trabalho apresentado, procura dar resposta a esta incerteza, validando em que medida a
infraestrutura adquirida e/ou monitorizada pelas organizações, dá resposta aos mais recentes
ataques, praticados por grupos de ataque APT (Advanced Persistent Threats).
1/4
 Departamento de Engenharia Informática e de Sistemas

Esta avaliação não terá apenas em consideração a intrusão inicial numa organização, mas
também movimentos laterais e possíveis escaladas de privilégios ilegítimos dentro da mesma.
Assim, permite validar para além da segurança perimetral, quão capaz é a organização de
detetar acessos ilegítimos na sua rede e sistemas, caso a segurança perimetral não tenha
detetado atempadamente a ameaça.

Assegurar uma resposta a ameaças que se processem dentro da rede, permite à organização
reduzir o impacto associado a ataques que tenham passado o primeiro nível de defesa,
impedindo que estes se propaguem a todos os ativos de rede internos.

2. OBJECTIVOS
O presente projeto/estágio pretende atingir os seguintes objetivos genéricos:
1 Criar um conjunto de cenários de ataque, mapeados com a matriz de táticas, técnicas e
procedimentos Mitre Att&ck, utilizando para tal, a titulo de exemplo as seguintes
plataformas:
◦ Caldera (testes Atomic Red Team)
◦ Red Team Automation
◦ APT Simulator
◦ (...)
2 Estabelecer um modelo de avaliação de maturidade de soluções, com base nos testes
executados e o gap entre as deteções / prevenções conseguidas e as táticas/técnicas
utilizadas no ataque.
3 Avaliar uma infraestrutura de segurança e rede subjacente, recorrendo aos cenários de
ataque criados.
4 Sugerir novos casos de uso e/ou soluções, que possam dar resposta aquilo que a
infraestrutura atualmente não consegue dar resposta, atribuindo-lhe uma avaliação
consequente após a aplicação de tais medidas/roadmap de implementação.

3. PROGRAMA DE TRABALHOS
O projeto/estágio consistirá nas seguintes atividades e respetivas tarefas:
• T1 – Avaliação das Plataformas de simulação de ataque – Esta tarefa prevê que o
estagiário possa avaliar quais as ferramentas que pretende utilizar para gerar os cenários
de ataque.
• T2 – Estudo da Matriz Mitre Att&ck – Estudo da matriz e sua organização, entendendo
de que forma se aplicam os conceitos espelhados nesta na infraestrutura de segurança
de uma organização.

2/4
 Departamento de Engenharia Informática e de Sistemas

• T3 – Estudo de casos de uso & SIGMA Rules - Esta tarefa visa preparar a fase final dos
trabalhos, em que se procurará, face àquilo que a infraestrutura não conseguir detetar
dos seus ataques, o aluno deverá sugerir um conjunto de casos de uso e/ou soluções que
o consigam.
• T4 – Implementação de Cenários de Ataque - Com base no estudo inicial, gerar os
cenários de ataque, mapeando-os com ataques reais promovidos por grupos ATP.
• T5 – Execução de cenários de ataque – Em ambiente laboratorial, os cenários
desenvolvidos serão executados sobre uma infraestrutura de segurança pré-definida,
devendo o aluno verificar a percentagem de técnicas detetadas / prevenidas pela
infraestrutura.
• T6 - Estabelecer modelo de avaliação de maturidade - Baseado no estudo e resultados
laboratoriais anteriores, encontrar um modelo de avaliação, que permita atribuir um
resultado de maturidade da organização, face às suas deteções e monitorização
realizada.
• T7 – Desenho de Solução – Com base nos resultados obtidos e nos testes executados, o
aluno deverá pensar uma solução capaz de dar resposta aos cenários desenvolvidos,
desenhando para tal comparativamente às redes avaliadas, um roadmap de
implementação que lhes permita melhorar o seu resultado de maturidade. (ex: adoção
de soluções como sysmon, ou Firewall de rede, e/ou criação de novos casos de uso nas
plataformas existentes)

4. CALENDARIZAÇÃO DAS TAREFAS

O plano de escalonamento dos trabalhos é apresentado em seguida

5. LOCAL E HORÁRIO DE TRABALHO

O trabalho será realizado a partir dos escritórios da Dognaedis, em Coimbra. O aluno será
integrado no SOC da Dognaedis, para que perceba os cenários de ataque mais comuns no dia-
adia de uma organização.

Horário de Trabalho: 9h00 às 18h00, com uma hora de almoço.

3/4
 Departamento de Engenharia Informática e de Sistemas

6. TECNOLOGIAS ENVOLVIDAS
• Sistemas Operativos: Linux & Windows.

• Linguagens: Bash & Python

• Aprendizagem decorrente do projeto: Caldera, Atomic Red, Mitre Att&ck, SIGMA,

Sysmon, Elastic Stack, etc.

7. METODOLOGIA
Prevê-se que o desenvolvimento seja assente numa metodologia ágil, assegurando a realização
de reuniões semanais de acompanhamento ao projecto, sobre as quais será verificada a
conformidade com o planeamento estabelecido neste documento enquanto macro-tarefas e
com o planeamento delineado pelos estagiários para execução da fase de implementação.
O dossier de projeto deverá ser elaborado pelo estagiário ao longo da execução do projecto,
com o apoio do orientador.

8. ORIENTAÇÃO

Empresa:

Nome: Rui Gonçalo Joaquim Dias Amaro (ramaro@[Link])

Categoria: Managed Security Services Manager

DEIS-ISEC:

Nome: Luís Eduardo Faria dos Santos (lsantos@[Link])

Categoria: Professor Adjunto

4/4
60 APÊNDICE A. PROPOSTA DE ESTÁGIO
Bibliografia

[1] Anomali. O que é MITRE ATTCK e como ele é útil. url: https :
//[Link]/pt/what-mitre-attck-is-and-how-it-is-
useful.
[2] Andy Applebaum. Getting Started with ATTCK: Assessments and En-
gineering. url: https : / / medium . com / mitre - attack / getting -
started-with-attack-assessment-cc0b01769cb4.
[3] APT34. url: [Link] threats/apt-
[Link]#apt34.
[4] Red Canary. Atomic Red Team. url: [Link]
atomic-red-team.
[5] Erica Eng e Dan Caselden. Threat Research - Operation Clandestine
Wolf. url: https : / / www . fireeye . com / blog / threat - research /
2015/06/operation-clandestine-wolf-adobe-flash-zero-day.
html.
[6] Threat Express. MITRE ATTCK. url: https : / / threatexpress .
com/redteaming/mitre_attack/.
[7] Insikt Group. Recorded Future Research Concludes Chinese Ministry
of State Security Behind APT3. url: [Link]
com/chinese-mss-behind-apt3/.
[8] Sarah Hospelhorn. What is The Cyber Kill Chain and How to Use it
Effectively. url: https : / / www . varonis . com / blog / cyber - kill -
chain/.
[9] Christopher A Korban et al. APT3 Adversary Emulation Plan. url:
[Link] docs /APT3_Adversary _Emulation _
[Link].
[10] MITRE. 4H RAT. url: https : / / attack . mitre . org / software /
S0065.

61
62 BIBLIOGRAFIA

[11] MITRE. CALDERA - Automated Adversary Emulation. url: https:

//[Link]/mitre/caldera.
[12] MITRE. CHOPSTICK. url: [Link]
S0023.
[13] MITRE. Encrypt Sensitive Information. url: [Link]
org/mitigations/M1041/.
[14] MITRE. Enterprise Tactics. url: https : / / attack . mitre . org /
tactics/enterprise/.
[15] MITRE. Mimikatz. url: https : / / attack . mitre . org / software /
S0002/.
[16] MITRE. netstat. url: [Link]
[17] MITRE. Network Sniffing. url: [Link]
T1040/.
[18] MITRE. PlugX. url: [Link]
[19] MITRE. PsExec. url: [Link]
[20] MITRE. Tasklist. url: https : / / attack . mitre . org / software /
S0057.
[21] Ned Moran et al. Threat Research - Operation Double Tap. url: https:
//[Link]/blog/threat-research/2014/11/operation_
[Link].
[22] Katie Nickels. Getting Started with ATTCK: Threat Intelligence. url:
https : / / medium . com / mitre - attack / getting - started - with -
attack-cti-4eb205be4b2f.
[23] OilRig. url: [Link]
[24] Mark Russinovich. PsExec v2.2. url: [Link]
en-us/sysinternals/downloads/psexec.
[25] SecTechno. Endgame Red Team Automation (RTA) Framework.
[26] SecTechno. Infection Monkey – Data Center Security Testing Framework.
url: [Link] monkey- data- center-
security-testing-framework/.
[27] Blake Strom. ATT&CK 101. url: https : / / medium . com / mitre -
attack/att-ck-101-17074d3bc62.
[28] Blake Strom. Getting Started with ATTCK: Adversary Emulation and
Red Teaming. url: [Link]
started-with-attack-red-29f074ccf7e3.
BIBLIOGRAFIA 63

[29] Nextron Systems. APT Simulator. url: [Link]

APTSimulator.
[30] Unit 42 Playbook Viewer. url: [Link] [Link]/
playbook_viewer/?pb=oilrig.
[31] John Wunder. Getting Started with ATTCK: Detection and Analytics.
url: [Link]
attack-detection-a8e49e4960d0.