TryHackMe Protocols and Servers 2 (versão em português)

Introdução

Imagine fazer login no seu e-mail usando a rede Wi-Fi aberta de uma cafeteria. Seu cliente de e-mail se conecta ao servidor de e-mail, envia seu nome de usuário e senha e recupera suas mensagens.

Se essa conexão usar um protocolo em texto claro, cada pedaço de dado, incluindo suas credenciais, ficará visível para qualquer outra pessoa na mesma rede.

Esta sala examina como isso acontece, o que os atacantes fazem com esse acesso e como os protocolos modernos evitam esse problema.

A sala Protocols and Servers abordou os seguintes protocolos:

• Telnet
• HTTP
• FTP
• SMTP
• POP3
• IMAP

Esses protocolos foram projetados décadas atrás, quando segurança não era uma preocupação principal. Eles transmitem dados, incluindo credenciais, em texto claro.

Embora esses protocolos ainda estejam em uso, as implantações modernas quase sempre utilizam versões criptografadas: HTTPS em vez de HTTP, SFTP ou FTPS em vez de FTP, SMTPS em vez de SMTP, e assim por diante.

O Telnet foi amplamente substituído pelo SSH para administração remota.

Entender as versões inseguras ajuda você a reconhecer configurações incorretas, sistemas legados e os mecanismos fundamentais sobre os quais as versões seguras foram construídas.

Servidores que implementam esses protocolos estão sujeitos a diferentes tipos de ataques:

• Ataque de sniffing, ou captura de pacotes de rede
• Ataque Man-in-the-Middle, ou MITM
• Ataque de senha, ou ataque de autenticação
• Vulnerabilidades

Do ponto de vista de segurança, você sempre precisa pensar no que deseja proteger. Considere a tríade de segurança: Confidencialidade, Integridade e Disponibilidade, conhecida como CIA.

Confidencialidade refere-se a manter o conteúdo das comunicações acessível apenas às partes pretendidas.

Integridade é a garantia de que qualquer dado enviado esteja correto, consistente e completo ao chegar ao seu destino.

Disponibilidade refere-se à capacidade de acessar o serviço quando necessário.

Diferentes partes darão ênfase diferente a esses três elementos. Por exemplo, a confidencialidade seria a maior prioridade para uma agência de inteligência. Um banco online dará maior ênfase à integridade das transações. Já a disponibilidade é de máxima importância para qualquer plataforma que ganha dinheiro exibindo anúncios.

Sabendo que você está protegendo Confidencialidade, Integridade e Disponibilidade (CIA), um ataque busca causar Divulgação, Alteração e Destruição (DAD).

A figura abaixo reflete essa relação.

Esses ataques afetam diretamente a segurança do sistema.

A captura de pacotes de rede viola a confidencialidade e leva à divulgação de informações. Um ataque de senha bem-sucedido também pode levar à divulgação.

Um ataque Man-in-the-Middle (MITM) compromete a integridade do sistema, pois pode alterar os dados comunicados.

Esta sala se concentra nesses três ataques porque eles são parte essencial do design de protocolos e da implementação de servidores.

O cenário moderno de ataques

Embora as categorias fundamentais de ataque continuem as mesmas, o cenário evoluiu:

• Ataques de sniffing são mais difíceis em redes corretamente configuradas devido à ampla adoção de TLS, mas continuam eficazes contra serviços mal configurados, redes internas sem criptografia e sistemas legados.
• Ataques MITM são mitigados por tecnologias como HSTS, ou HTTP Strict Transport Security, certificate pinning e logs de Certificate Transparency, mas ainda podem ter sucesso quando essas proteções estão ausentes ou são implementadas incorretamente.
• Ataques de senha evoluíram além do brute force simples. Atacantes agora usam credential stuffing, que consiste em testar pares de usuário e senha vazados em violações de dados, password spraying, que consiste em testar senhas comuns em muitas contas, e também aproveitam enormes bases de dados de vazamentos.
• Vulnerabilidades fazem parte de um espectro mais amplo, e vulnerabilidades exploradas podem ter impactos diferentes nos sistemas-alvo. Por exemplo, explorar uma vulnerabilidade de Denial of Service (DoS) pode afetar a disponibilidade do sistema, enquanto explorar uma vulnerabilidade de Remote Code Execution (RCE) pode causar danos muito mais graves.

Uma vulnerabilidade, por si só, cria um risco; o dano só ocorre quando essa vulnerabilidade é explorada.

Vulnerabilidades não são abordadas nesta sala, pois possuem seu próprio módulo: Vulnerability Research.

Esta sala se concentra em como um protocolo pode ser atualizado ou substituído para proteger contra divulgação e alteração, preservando a confidencialidade e a integridade dos dados transmitidos.

Também será apresentada a ferramenta Hydra, uma ferramenta poderosa para testar a força de senhas por meio de tentativas de autenticação usando wordlists.

Entender como atacantes conduzem ataques contra credenciais ajuda você a compreender por que senhas fortes, políticas de bloqueio de conta e autenticação multifator são defesas essenciais.

Observação sobre a máquina de laboratório

Você precisará da máquina de laboratório anexada a partir da Task 5, que aborda SSH.

Você pode iniciá-la agora ou quando chegar a essa tarefa. As Tasks 2 a 4 são informativas e não exigem a VM.

Responda à pergunta abaixo:

Sugerimos que você inicie o AttackBox e a máquina de laboratório conforme avança para resolver as próximas tarefas.

Você pode se conectar aos diferentes serviços usando Telnet ou Netcat para praticar melhor e ter uma experiência de aprendizado mais completa.

Resposta: Não é necessária resposta

Sniffing Attacks

Um ataque de sniffing refere-se ao uso de uma ferramenta de captura de pacotes de rede para coletar informações sobre o alvo.

Quando um protocolo se comunica em texto claro, os dados trocados podem ser capturados por um terceiro para análise. Uma simples captura de pacotes de rede pode revelar informações como o conteúdo de mensagens privadas e credenciais de login, caso os dados não estejam criptografados durante a transmissão.

Onde os ataques de sniffing ainda são relevantes

Você pode pensar que ataques de sniffing estão ultrapassados, considerando a ampla adoção da criptografia TLS. No entanto, eles continuam sendo uma ameaça significativa em vários cenários:

• Redes corporativas internas, onde o tráfego entre sistemas pode não estar criptografado.
• Sistemas legados que ainda usam protocolos em texto claro, como servidores de e-mail antigos, dispositivos embarcados e sistemas de controle industrial.
• Serviços mal configurados, nos quais o TLS está disponível, mas não é obrigatório.
• Dispositivos IoT, que frequentemente usam protocolos não criptografados para comunicação.
• Redes sem fio, onde atacantes dentro do alcance podem capturar tráfego.
• Após um ataque MITM bem-sucedido que rebaixa ou remove a criptografia.

Durante testes de penetração internos e operações de red team, o sniffing continua sendo uma técnica valiosa para coletar credenciais e entender como os sistemas se comunicam.

Ferramentas de captura de pacotes

Um ataque de sniffing pode ser conduzido usando uma placa de rede Ethernet, padrão 802.3, desde que o usuário tenha as permissões adequadas, como permissões de root no Linux e privilégios de administrador no Windows.

Existem muitos programas disponíveis para capturar pacotes de rede. Os seguintes estão entre os mais comuns:

• Tcpdump é um programa gratuito, open-source e de linha de comando, ou CLI, que foi adaptado para funcionar em vários sistemas operacionais. Ele é leve e está disponível por padrão na maioria dos sistemas Linux.
• Wireshark é um programa gratuito, open-source e com interface gráfica, ou GUI, disponível para vários sistemas operacionais, incluindo Linux, macOS e Windows. Ele oferece recursos poderosos de filtragem, dissecação de protocolos e visualização.
• Tshark é uma alternativa CLI ao Wireshark que usa o mesmo mecanismo de dissecação. Ele é útil para scripts e automação.

Outras ferramentas que vale a pena conhecer incluem tcpflow, para remontar fluxos TCP; ngrep, para correspondência de padrões no tráfego de rede; e NetworkMiner, para extrair arquivos e imagens do tráfego capturado.

Também existem várias ferramentas especializadas para capturar senhas e mensagens completas. No entanto, isso ainda pode ser feito com o Tcpdump e o Wireshark, com algum esforço adicional.

Exemplo prático: capturando credenciais POP3

Considere um usuário verificando mensagens de e-mail usando POP3. O exemplo a seguir usa o Tcpdump para capturar o nome de usuário e a senha.

Esse ataque exige acesso ao tráfego de rede. Um atacante poderia obter esse acesso por meio de uma escuta física na rede, um switch com port mirroring configurado, ARP spoofing em uma rede local ou um sistema comprometido no mesmo segmento de rede.

Outra possibilidade é acessar o tráfego lançando um ataque Man-in-the-Middle (MITM) bem-sucedido.

O comando usado é:

sudo tcpdump port 110 -A

sudo tcpdump port 110 -A

O prefixo sudo é necessário porque capturas de pacotes exigem privilégios de root.

O filtro port 110 limita os pacotes capturados àqueles trocados com o servidor POP3, já que o POP3 usa a porta 110 por padrão.

A flag -A exibe o conteúdo dos pacotes capturados em formato ASCII, tornando credenciais em texto claro legíveis na saída.

Na saída do terminal acima, pacotes sem importância foram removidos para melhorar a clareza.

O nome de usuário e a senha foram enviados em pacotes separados. O primeiro pacote exibe explicitamente:

USER frank

USER frank

enquanto o último pacote revela a senha:

PASS D2xc9CgD

PASS D2xc9CgD

O Wireshark consegue obter os mesmos resultados.

Na janela do Wireshark abaixo, o campo de filtro contém:

pop

pop

Com apenas o tráfego POP3 exibido, o nome de usuário e a senha capturados ficam visíveis.

Filtros úteis do Tcpdump

Ao capturar tráfego, o uso de filtros eficazes ajuda você a se concentrar nos pacotes relevantes:

Mitigação

Qualquer protocolo que use comunicação em texto claro está suscetível a esse tipo de ataque. O único requisito para que o ataque tenha sucesso é o acesso a um sistema entre as duas partes que estão se comunicando ou ao mesmo segmento de rede.

A principal mitigação é adicionar uma camada de criptografia sobre o protocolo de rede.

O Transport Layer Security (TLS) foi adicionado ao HTTP, FTP, SMTP, POP3, IMAP e muitos outros protocolos. Para acesso remoto, o Telnet foi substituído pela alternativa segura Secure Shell (SSH).

Mitigações adicionais incluem:

• Segmentação de rede: limita quais sistemas conseguem enxergar o tráfego uns dos outros ao dividir a rede em zonas isoladas.
• VLANs e túneis criptografados: protegem o tráfego sensível mesmo em redes internas.
• Autenticação baseada em porta 802.1X: exige que os dispositivos se autentiquem antes de obter acesso à rede, impedindo que dispositivos não autorizados se conectem e capturem tráfego.
• Arquitetura Zero Trust: é um modelo de segurança que trata todo o tráfego de rede como potencialmente hostil, criptografando todas as comunicações independentemente de elas se originarem dentro ou fora do perímetro da rede.
• Monitoramento de ARP spoofing e outras técnicas de redirecionamento de tráfego: ajuda a detectar tentativas de sniffing em andamento.

A melhor prática moderna assume que a rede é hostil, inclusive redes internas. Isso significa criptografar todo o tráfego, não apenas o tráfego que atravessa a internet.

Para explorar mais sobre o Wireshark, consulte a sala Wireshark 101.

Responda às perguntas abaixo:

O que você precisa adicionar ao comando sudo tcpdump para capturar apenas tráfego Telnet?

Resposta: port 23

Qual é o filtro de exibição mais simples que você pode usar no Wireshark para mostrar apenas tráfego IMAP?

Resposta: imap

Man-in-the-Middle (MITM) attack

Um ataque Man-in-the-Middle (MITM) ocorre quando uma vítima, A, acredita que está se comunicando com um destino legítimo, B, mas, sem saber, está se comunicando com um atacante, E.

Na figura abaixo, A solicita a transferência de $20 para M. No entanto, E altera essa mensagem e substitui o valor original por um novo valor.

B recebe a mensagem modificada e age com base nela.

Esse ataque é relativamente simples de realizar se as duas partes não confirmarem a autenticidade e a integridade de cada mensagem.

Em alguns casos, o protocolo escolhido não oferece autenticação segura ou verificação de integridade. Alguns protocolos possuem inseguranças inerentes que os tornam suscetíveis a esse tipo de ataque.

Como os ataques MITM funcionam

Para que um atacante consiga se posicionar entre duas partes que estão se comunicando, normalmente ele precisa redirecionar o tráfego através do próprio sistema.

Técnicas comuns incluem:

• ARP Spoofing: é eficaz em redes locais. O atacante envia mensagens ARP, ou Address Resolution Protocol, falsificadas para associar seu endereço MAC ao endereço IP do gateway padrão ou do sistema-alvo. Como resultado, o tráfego destinado a esses sistemas passa a ser enviado para o atacante.
• DNS Spoofing: envolve fornecer respostas DNS falsas para redirecionar vítimas para servidores controlados pelo atacante. Isso pode acontecer por meio de servidores DNS comprometidos, DNS cache poisoning ou respondendo às consultas DNS mais rapidamente do que o servidor legítimo.
• Rogue Access Points: são pontos de acesso Wi-Fi falsos configurados por atacantes. Quando as vítimas se conectam a essas redes, muitas vezes nomeadas para parecer redes legítimas, como Airport_WiFi_Free, todo o tráfego passa pelo sistema do atacante.
• BGP Hijacking: opera no nível de roteamento da internet, onde atacantes anunciam rotas BGP falsas para redirecionar o tráfego por meio da própria infraestrutura. Esse é um ataque mais sofisticado, normalmente direcionado a organizações ou regiões específicas.

Ferramentas para ataques MITM

Muitas ferramentas podem auxiliar na realização de ataques MITM. Entendê-las ajuda você a reconhecer o que atacantes conseguem fazer e por que as mitigações são importantes:

• Bettercap é o sucessor moderno do Ettercap e é mantido ativamente. Ele oferece suporte a ARP spoofing, DNS spoofing, proxy HTTP/HTTPS e possui uma arquitetura modular para vários cenários de ataque.
• Ettercap é uma ferramenta clássica para ataques MITM em redes locais. Embora ainda funcione, o Bettercap geralmente é preferido em avaliações modernas.
• mitmproxy é um proxy HTTPS interativo que permite inspecionar e modificar tráfego. Ele é particularmente útil para analisar e manipular comunicações HTTP/HTTPS.
• Responder foi projetado para ambientes Windows e explora protocolos de resolução de nomes, como LLMNR, ou Link-Local Multicast Name Resolution, e NBT-NS, ou NetBIOS Name Service. Esses são protocolos de fallback que sistemas Windows usam quando a resolução DNS padrão falha.

O Responder escuta essas consultas de broadcast e responde com seu próprio endereço IP, enganando as vítimas para que enviem credenciais de autenticação ao atacante. Essa é uma técnica comum durante testes de penetração internos em ambientes Active Directory.

MITM contra tráfego criptografado

Ataques MITM podem atingir HTTPS e outros protocolos criptografados por meio de várias abordagens:

• SSL Stripping: rebaixa conexões HTTPS para HTTP. Quando uma vítima tenta se conectar a um site, o atacante intercepta a solicitação, estabelece uma conexão HTTPS com o servidor legítimo, mas entrega o conteúdo à vítima por HTTP não criptografado. A vítima pode não perceber a ausência do ícone de cadeado, especialmente se não digitou explicitamente [https://](https://.).
• Certificados falsos: envolvem o atacante apresentando seu próprio certificado e estabelecendo conexões criptografadas separadas com ambas as partes. Isso funciona se a vítima aceitar um aviso de certificado inválido ou se o atacante tiver comprometido uma Certificate Authority (CA).
• CAs comprometidas ou maliciosas: representam uma ameaça mais séria. Se um atacante controla uma CA confiável, ou obtém um certificado fraudulento emitido por uma delas, ele pode gerar certificados aparentemente válidos para qualquer domínio.

Defesas modernas contra MITM

Mecanismos modernos de segurança tornam ataques MITM significativamente mais difíceis do que eram há uma década:

• HTTPS Everywhere: a maioria dos sites agora usa HTTPS por padrão. Grandes navegadores marcam sites HTTP como "Not Secure", e alguns começaram a bloquear completamente conteúdo misto.
• HSTS, ou HTTP Strict Transport Security: informa aos navegadores que eles devem se conectar apenas via HTTPS por um período especificado. Depois que um navegador recebe um cabeçalho HSTS para um domínio, ele se recusará a conectar por HTTP, impedindo ataques de SSL stripping. Muitos sites importantes também estão na lista de HSTS preload, o que significa que os navegadores já vêm com a informação de que esses sites devem ser acessados apenas via HTTPS.
• Certificate Transparency (CT): exige que as CAs registrem todos os certificados emitidos em logs públicos e auditáveis. Isso torna muito mais difícil para atacantes obterem certificados fraudulentos sem detecção. Navegadores podem verificar esses logs e rejeitar certificados que não estejam devidamente registrados.
• Certificate Pinning: permite que aplicações especifiquem exatamente quais certificados ou chaves públicas são válidos para suas conexões. Isso é comum em aplicativos móveis e impede ataques mesmo se uma CA for comprometida. No entanto, torna a rotação de certificados mais complexa.
• DANE, ou DNS-based Authentication of Named Entities: usa DNSSEC para publicar informações de certificados em registros DNS, fornecendo um caminho alternativo de confiança que não depende exclusivamente do sistema de CAs.

Apesar dessas proteções, ataques MITM ainda são possíveis quando usuários ignoram avisos de certificado, aplicações não validam certificados corretamente, o alvo usa protocolos em texto claro, o atacante consegue comprometer uma CA confiável, redes internas não usam criptografia ou sistemas legados não oferecem suporte a recursos modernos de segurança.

MITM também pode afetar outros protocolos em texto claro, como FTP, SMTP e POP3.

A mitigação fundamental exige o uso de criptografia. A solução está na autenticação adequada junto com criptografia ou assinatura das mensagens trocadas.

Com a ajuda da Public Key Infrastructure (PKI) e de certificados raiz confiáveis, o Transport Layer Security (TLS) protege contra ataques MITM quando implementado corretamente.

Responda às perguntas abaixo:

Quantas interfaces diferentes o Ettercap oferece?

Resposta: 3

De quantas maneiras você pode invocar o Bettercap?

Resposta: 3

TLS (Transport Layer Security)

Esta task aborda a solução padrão para proteger a confidencialidade e a integridade dos pacotes trocados.

A abordagem descrita aqui pode proteger contra sniffing de senhas e ataques MITM.

Uma breve história do SSL e do TLS

O SSL, ou Secure Sockets Layer, surgiu quando a World Wide Web começou a receber novas aplicações, como compras online e envio de informações de pagamento.

A Netscape introduziu o SSL em 1994, com o SSL 3.0 sendo lançado em 1996. Com o tempo, foi necessário aumentar a segurança, e o protocolo TLS, ou Transport Layer Security, foi introduzido em 1999 com o TLS 1.0.

Desde então, o protocolo evoluiu significativamente:

• SSL 2.0 e SSL 3.0 estão obsoletos e são considerados inseguros. Eles nunca devem ser usados.
• TLS 1.0 e TLS 1.1 foram descontinuados em 2021 devido a vulnerabilidades conhecidas. Os principais navegadores não oferecem mais suporte a eles.
• TLS 1.2, lançado em 2008, ainda é amplamente utilizado e é considerado seguro quando configurado corretamente com suítes de criptografia modernas.
• TLS 1.3, lançado em 2018, é o padrão atual. Ele remove algoritmos criptográficos antigos, reduz a latência do handshake e fornece forward secrecy por padrão.

Você ainda verá o termo "SSL" sendo usado de forma coloquial, como em "certificado SSL", mas, na prática, todos os sistemas modernos usam TLS.

Quando alguém diz "SSL", quase sempre está se referindo a TLS.

Onde o TLS se encaixa no modelo de rede

Os protocolos comuns abordados até agora enviam dados em texto claro, tornando possível que qualquer pessoa com acesso à rede capture, salve e analise as mensagens trocadas.

A imagem abaixo mostra as camadas de rede do modelo ISO/OSI.

Os protocolos abordados até agora nesta sala estão na camada de aplicação. A criptografia pode ser adicionada por meio da camada de apresentação.

Como resultado, os dados serão apresentados em formato criptografado, chamado de ciphertext, em vez de sua forma original.

Vale observar que o modelo OSI é uma simplificação conceitual.

Na prática, o TLS opera entre as camadas de transporte e aplicação, em vez de se encaixar perfeitamente em uma única camada do modelo OSI.

No entanto, o diagrama é útil para entender que a criptografia fica abaixo do protocolo de aplicação, encapsulando seus dados antes da transmissão.

Atualizando protocolos com TLS

Um protocolo existente em texto claro pode ser atualizado para usar criptografia via TLS.

A tabela a seguir lista os protocolos abordados até agora e suas portas padrão antes e depois da atualização de criptografia via TLS.

O TLS não se limita a protocolos web e de e-mail. O DNS também pode ser protegido usando TLS.

O DNS over TLS (DoT) criptografa consultas DNS encapsulando o tráfego DNS padrão dentro de uma conexão TLS, normalmente na porta 853.

Uma abordagem relacionada, chamada DNS over HTTPS (DoH), envia consultas DNS como requisições HTTPS na porta 443.

Ambas evitam a espionagem de consultas DNS, que, de outra forma, revelariam quais sites um usuário está acessando.

TLS implícito vs STARTTLS

Existem duas abordagens para adicionar TLS a um protocolo:

TLS implícito usa uma porta dedicada, como mostrado na tabela acima. A conexão é criptografada desde o início. Quando você se conecta à porta 443 para HTTPS ou à porta 993 para IMAPS, a negociação TLS começa imediatamente.

STARTTLS permite atualizar uma conexão existente em texto claro para TLS na mesma porta. O cliente se conecta na porta padrão, por exemplo, porta 25 para SMTP, e então emite um comando STARTTLS para atualizar a conexão para TLS.

Essa abordagem é comum em protocolos de e-mail. Para SMTP, a porta 587, chamada de submission, com STARTTLS é a configuração recomendada para clientes de e-mail.

Ambas as abordagens fornecem criptografia. No entanto, o TLS implícito geralmente é preferido, porque o STARTTLS pode ser vulnerável a ataques de downgrade se não for implementado corretamente.

Um atacante realizando um ataque MITM poderia remover o comando STARTTLS da comunicação, forçando a conexão a permanecer em texto claro.

Como o HTTPS funciona

Considere o caso do HTTP.

Inicialmente, para recuperar uma página web usando HTTP, o navegador precisaria executar pelo menos os seguintes dois passos:

1. Estabelecer uma conexão TCP com o servidor web remoto.
2. Enviar requisições HTTP ao servidor web, como requisições GET e POST.

O HTTPS exige uma etapa adicional para criptografar o tráfego. Essa nova etapa acontece depois de estabelecer uma conexão TCP e antes de enviar as requisições HTTP.

Como resultado, o HTTPS exige pelo menos os seguintes três passos:

1. Estabelecer uma conexão TCP.
2. Estabelecer uma conexão TLS.
3. Enviar requisições HTTP ao servidor web.

O handshake TLS

Para estabelecer uma conexão TLS, o cliente precisa realizar um handshake com o servidor.

O handshake difere entre as versões do TLS. A seguir está uma visão simplificada do handshake do TLS 1.2:

ClientHello: o cliente envia uma mensagem indicando suas capacidades, incluindo versões TLS suportadas, suítes de criptografia e um valor aleatório.

ServerHello: o servidor responde com os parâmetros de conexão selecionados, seu certificado, que é um arquivo digital assinado por uma Certificate Authority (CA) para comprovar a identidade do servidor, e seu próprio valor aleatório.

Key Exchange: o cliente e o servidor trocam as informações necessárias para gerar a chave secreta compartilhada. O processo exato depende da suíte de criptografia escolhida.

Finished: ambos os lados confirmam que o handshake foi concluído com sucesso e passam a usar comunicação criptografada.

Melhorias do TLS 1.3

O TLS 1.3 melhora significativamente as versões anteriores:

• Handshake mais rápido: o TLS 1.3 exige apenas uma ida e volta, ou 1-RTT, para estabelecer uma conexão, em comparação com duas idas e voltas no TLS 1.2. Ele também oferece suporte à retomada 0-RTT para clientes que já se conectaram anteriormente, embora isso envolva alguns trade-offs de segurança.
• Forward secrecy por padrão: todas as suítes de criptografia do TLS 1.3 oferecem forward secrecy, o que significa que, se a chave privada do servidor for comprometida no futuro, sessões antigas gravadas anteriormente não poderão ser descriptografadas.
• Suítes de criptografia simplificadas: algoritmos antigos e inseguros foram removidos. Não há mais opções que possam levar a configurações fracas.
• Handshake criptografado: uma parte maior do handshake é criptografada, revelando menos informações para observadores.

O ponto principal é este: o cliente e o servidor concordam, de forma segura, sobre uma chave secreta que um terceiro monitorando o canal não consegue descobrir.

Toda a comunicação posterior é criptografada usando essa chave. Como resultado, depois que um handshake TLS é estabelecido, as requisições HTTP e os dados trocados não ficam acessíveis para alguém observando o canal de comunicação.

Certificados e confiança

Para que o TLS seja eficaz, especialmente ao navegar na web usando HTTPS, o sistema depende de certificados públicos assinados por Certificate Authorities (CAs) confiáveis para o seu sistema.

Quando você acessa o TryHackMe usando HTTPS, seu navegador espera que o servidor web do TryHackMe forneça um certificado assinado por uma autoridade certificadora confiável.

Isso garante que você está se comunicando com o servidor correto e que um ataque MITM não consiga ocorrer facilmente.

Na figura acima, as seguintes informações ficam visíveis:

• Para quem o certificado foi emitido? Esse é o nome da empresa que usará o certificado.
• Quem emitiu o certificado? Essa é a autoridade certificadora que emitiu o certificado.
• Período de validade. Um certificado expirado não deve ser confiável.

Seu navegador web lida com isso automaticamente, garantindo que você está se comunicando com o servidor correto e que sua comunicação está segura.

Ecossistema moderno de certificados

O cenário dos certificados evoluiu significativamente:

• Let's Encrypt foi lançado em 2015 e fornece certificados TLS gratuitos e automatizados. Isso removeu a barreira de custo que anteriormente impedia muitos sites de usar HTTPS. Como resultado, a adoção do HTTPS cresceu de menos de 50% do tráfego web em 2015 para mais de 95% atualmente.
• Certificate Transparency (CT) exige que as CAs registrem todos os certificados emitidos em logs públicos e auditáveis. Os navegadores podem verificar esses logs e rejeitar certificados que não estejam devidamente registrados. Isso torna muito mais difícil para atacantes obterem certificados fraudulentos sem serem detectados.
• Certificados de curta duração estão se tornando mais comuns. Os certificados da Let's Encrypt são válidos por apenas 90 dias, incentivando a automação e reduzindo a janela de exposição caso um certificado seja comprometido. Algumas organizações usam certificados válidos por apenas algumas horas ou dias.
• Automated Certificate Management Environment (ACME) é o protocolo usado pela Let's Encrypt e por outras CAs para automatizar a emissão e renovação de certificados. Ferramentas como o Certbot tornam simples obter e renovar certificados automaticamente.

Testando configurações TLS

Como profissional de segurança, talvez você precise avaliar configurações TLS. Algumas ferramentas úteis incluem:

• testssl.sh: uma ferramenta de linha de comando que verifica a configuração TLS de um servidor, incluindo protocolos suportados, suítes de criptografia e vulnerabilidades comuns. É a melhor escolha para avaliações detalhadas, especialmente contra sistemas internos que não estão publicamente acessíveis.
• sslyze: uma ferramenta em Python para analisar configurações SSL/TLS, útil para automação e integração em pipelines de CI/CD.
• SSL Labs, em ssllabs.com: um serviço web que fornece uma análise detalhada de servidores HTTPS expostos publicamente. É a opção mais rápida para uma avaliação pontual de um site público.
• nmap ssl-enum-ciphers: um script do Nmap que enumera suítes de criptografia suportadas como parte de uma varredura de portas mais ampla.

Problemas comuns a procurar incluem suporte a protocolos obsoletos, como TLS 1.0 e TLS 1.1, suítes de criptografia fracas, ausência de forward secrecy e problemas com certificados.

Responda à pergunta abaixo:

O DNS também pode ser protegido usando TLS. Qual é a sigla de três letras do protocolo DNS que usa TLS?

Resposta: DoT

Secure Shell (SSH)

Esta task aborda métodos de autenticação SSH, geração de chaves, verificação de chave do host, transferência de arquivos via SSH e considerações de hardening do SSH.

Certifique-se de que a máquina de laboratório da Task 1 esteja em execução antes de prosseguir. Se ela tiver expirado, reinicie-a agora.

O Secure Shell (SSH) foi criado para fornecer uma forma segura de administração remota de sistemas. Ele permite que você se conecte com segurança a outro sistema pela rede e execute comandos no sistema remoto.

O "S" em SSH significa secure, ou seja, seguro, o que pode ser resumido da seguinte forma:

• Você pode confirmar a identidade do servidor remoto.
• As mensagens trocadas são criptografadas e só podem ser descriptografadas pelo destinatário pretendido.
• Ambos os lados conseguem detectar qualquer modificação nas mensagens.

Os três pontos acima são garantidos pela criptografia. Em termos mais técnicos, eles fazem parte da confidencialidade e da integridade, possibilitadas pelo uso adequado de diferentes algoritmos de criptografia.

O SSH se tornou o padrão universal para administração remota de servidores, dispositivos de rede e infraestrutura em nuvem. Ele substituiu completamente o Telnet para acesso remoto interativo devido às suas garantias de segurança.

Métodos de autenticação SSH

Para usar SSH, você precisa de um servidor SSH e de um cliente SSH. O servidor SSH escuta na porta 22 por padrão.

O cliente SSH pode se autenticar usando vários métodos:

• Autenticação por senha: é o método mais simples. O usuário fornece um nome de usuário e uma senha, que são transmitidos pela conexão SSH criptografada. Embora a senha esteja protegida durante a transmissão, esse método é vulnerável a ataques de brute force caso senhas fracas sejam usadas.
• Autenticação por chave pública: é o método recomendado para uso regular. Você gera um par de chaves composto por uma chave privada, mantida em segredo na sua máquina, e uma chave pública, colocada nos servidores que deseja acessar. Ao se conectar, o servidor desafia você a provar que possui a chave privada sem realmente transmiti-la.
• Autenticação baseada em certificado: é usada em organizações maiores. Uma SSH Certificate Authority assina chaves de usuários e hosts, eliminando a necessidade de distribuir chaves públicas para cada servidor. Isso escala melhor e permite expiração e revogação de chaves.
• Autenticação multifator (MFA): combina vários métodos. Muitas organizações agora exigem tanto uma chave quanto uma senha de uso único gerada por um aplicativo autenticador.

Conectando via SSH

No Linux, macOS e Windows 10/11, você pode se conectar a um servidor SSH usando o comando:

ssh username@MACHINE_IP

ssh username@MACHINE_IP

Esse comando tenta se conectar ao servidor no endereço IP especificado usando o nome de login informado.

Se um servidor SSH estiver escutando na porta padrão, ele solicitará que você forneça a senha desse usuário, ou usará sua chave caso ela esteja configurada.

Depois de autenticado, você terá acesso ao terminal do servidor-alvo.

No exemplo acima, o comando abaixo foi executado:

ssh mark@MACHINE_IP

ssh mark@MACHINE_IP

Depois que a senha correta foi inserida, o acesso ao terminal do sistema remoto foi concedido.

O SSH é confiável para administração remota porque o nome de usuário e a senha foram enviados de forma criptografada. Todos os comandos executados no sistema remoto são enviados por um canal criptografado.

Verificação da chave do host

Se esta for a primeira vez que você se conecta a um sistema, será necessário confirmar a impressão digital, ou fingerprint, da chave pública do servidor SSH para evitar ataques Man-in-the-Middle (MITM).

No caso do SSH, geralmente não há uma terceira parte para verificar se a chave pública é válida. Portanto, essa verificação precisa ser feita manualmente ou por meio de uma verificação fora do canal principal de comunicação, conhecida como out-of-band verification.

Ao se conectar a um novo servidor, você verá uma mensagem como:

Idealmente, você deve verificar essa fingerprint por meio de um canal separado, como um sistema seguro de gerenciamento de configuração ou perguntando ao administrador do servidor, antes de aceitá-la.

Depois de aceita, a chave do host é armazenada em:

~/.ssh/known_hosts

~/.ssh/known_hosts

Se a chave mudar inesperadamente no futuro, o SSH exibirá um aviso. Isso pode indicar um ataque MITM ou que o servidor foi reinstalado.

Geração de chave SSH

Para configurar autenticação baseada em chave, gere um par de chaves usando:

ssh-keygen

ssh-keygen

As chaves Ed25519 são a recomendação atual. Elas são mais curtas, mais rápidas e consideradas mais seguras do que chaves RSA.

As chaves RSA devem usar pelo menos 4096 bits caso Ed25519 não esteja disponível.

Sua chave privada é armazenada em:

~/.ssh/id_ed25519

~/.ssh/id_ed25519

ou em:

~/.ssh/id_rsa

~/.ssh/id_rsa

e deve ser protegida com uma passphrase forte.

A chave pública é armazenada com a extensão .pub e pode ser compartilhada com segurança.

Para habilitar login baseado em chave em um servidor, adicione sua chave pública ao arquivo abaixo no sistema remoto:

~/.ssh/authorized_keys

~/.ssh/authorized_keys

Opções úteis do SSH

O SSH possui muitos recursos úteis para pentesters e administradores de sistemas:

Arquivo de configuração SSH

Para conexões frequentes, você pode criar atalhos em:

~/.ssh/config

~/.ssh/config

Com essa configuração, você pode simplesmente digitar:

ssh webserver

ssh webserver

em vez do comando completo.

Transferência segura de arquivos

O SSH oferece recursos de transferência segura de arquivos por meio de vários métodos:

SFTP, ou SSH File Transfer Protocol, é o método recomendado para transferências interativas de arquivos.

Ele fornece uma interface familiar, semelhante ao FTP, por meio de uma conexão SSH criptografada:

SCP, ou Secure Copy Protocol, tradicionalmente foi usado para cópias simples de arquivos.

No entanto, o projeto OpenSSH descontinuou o uso do scp em favor do sftp devido a preocupações de segurança com o protocolo SCP.

O SCP ainda funciona, mas exibe um aviso de descontinuação em sistemas mais recentes:

O rsync sobre SSH é preferido para transferir grandes volumes de dados ou sincronizar diretórios, pois ele transfere apenas as partes dos arquivos que foram alteradas:

SSH vs FTPS vs SFTP

Vale a pena esclarecer a diferença entre essas opções seguras de transferência de arquivos:

• SFTP roda sobre SSH, na porta 22, e é a opção mais comum atualmente para transferências seguras de arquivos.
• FTPS é o FTP protegido com TLS, usando a porta 990 para TLS implícito. Apesar dos nomes parecidos, é um protocolo diferente do SFTP.
• SCP também roda sobre SSH, mas está sendo gradualmente substituído pelo SFTP.

Para a maioria dos casos de uso, o SFTP é a opção recomendada, pois usa a mesma autenticação e criptografia do SSH, simplificando o gerenciamento.

Considerações de hardening do SSH

Ao avaliar ou configurar servidores SSH, considere estas configurações de segurança em:

/etc/ssh/sshd_config

/etc/ssh/sshd_config

• Desabilitar autenticação por senha com:

PasswordAuthentication no

PasswordAuthentication no

após configurar autenticação baseada em chave.

• Desabilitar login como root com:

PermitRootLogin no

PermitRootLogin no

para obrigar os usuários a se autenticarem primeiro como usuários comuns.

• Usar AllowUsers ou AllowGroups para restringir quais contas podem fazer login via SSH.
• Alterar a porta padrão para reduzir ruído de varreduras automatizadas. Isso é segurança por obscuridade, não um controle forte.
• Habilitar fail2ban ou ferramenta semelhante para bloquear tentativas repetidas de autenticação malsucedidas.
• Usar algoritmos modernos de troca de chaves e criptografia configurando:

KexAlgorithms
Ciphers
MACs

KexAlgorithms
Ciphers
MACs

Responda às perguntas abaixo:

Use SSH para se conectar ao MACHINE_IP como o usuário mark, usando a senha XBtc49AB. Usando uname -r, encontre a versão de release do Kernel.

Resposta: 5.15.0–119-generic

Use SSH para baixar o arquivo book.txt do sistema remoto. Quantos KB o scp exibiu como tamanho do download?

Resposta: 415

Ataque de Password

Certifique-se de que a máquina de laboratório da Task 1 esteja em execução antes de prosseguir. Se ela tiver expirado, reinicie-a agora.

Muitos protocolos exigem autenticação. Autenticação é provar que você é quem afirma ser.

Ao usar protocolos como POP3, o acesso à caixa de e-mail não deve ser concedido antes da verificação da identidade.

O exemplo de POP3 da sala Protocols and Servers é repetido abaixo para referência.

Nesse exemplo, o usuário é identificado como frank, e o servidor o autenticou porque a senha correta foi fornecida.

Fatores de autenticação

A autenticação, ou seja, provar sua identidade, pode ser realizada por meio de um dos fatores abaixo ou pela combinação de dois ou mais deles:

• Algo que você sabe, como uma senha ou código PIN.
• Algo que você possui, como um celular, uma chave de segurança ou um smart card.
• Algo que você é, como uma impressão digital ou reconhecimento facial.

Esta task se concentra em ataques contra senhas, o fator "algo que você sabe".

Por que senhas fracas continuam existindo

Com base nos 150 milhões de nomes de usuário e senhas vazados na violação de dados da Adobe em 2013, as dez senhas mais comuns incluíam 123456, password, qwerty e escolhas igualmente óbvias.

Os hábitos relacionados a senhas não melhoraram de forma significativa. Análises de vazamentos mais recentes mostram que senhas comuns nos anos 2020 ainda incluem:

• 123456 e variações, como 123456789, 12345678 e 1234567890.
• password e Password1.
• qwerty e qwerty123.
• Nomes de empresas ou serviços combinados com números, como Summer2024 e Welcome1.
• Times esportivos e referências da cultura pop.

A disponibilidade de enormes bases de dados de vazamentos tornou os ataques contra senhas mais eficazes do que nunca. Atacantes conseguem cruzar credenciais vazadas entre diferentes serviços porque muitos usuários reutilizam senhas.

Tipos de ataques contra senhas

Ataques contra senhas evoluíram além do brute force simples:

• Password guessing: exige algum conhecimento sobre o alvo, como o nome do animal de estimação, ano de nascimento, time favorito ou nomes dos filhos. Redes sociais tornam essa coleta de informações mais fácil do que nunca.
• Dictionary attack: tenta palavras comuns a partir de um dicionário ou wordlist. Isso é eficaz porque muitos usuários escolhem palavras reais ou variações simples.
• Brute force attack: tenta todas as combinações possíveis de caracteres. É um método exaustivo e demorado, mas eficaz contra senhas curtas. O espaço de busca cresce exponencialmente com o tamanho da senha, por isso senhas mais longas são significativamente mais seguras.
• Credential stuffing: usa pares de usuário e senha vazados em violações anteriores e tenta essas credenciais em outros serviços. Esse ataque explora a reutilização de senhas e é extremamente eficaz. Atacantes usam ferramentas automatizadas para testar milhões de credenciais em muitos sites simultaneamente.
• Password spraying: tenta um pequeno número de senhas muito usadas contra muitas contas. Em vez de tentar muitas senhas contra uma única conta, o que acionaria bloqueios, o atacante tenta uma ou duas senhas contra milhares de contas. Isso ajuda a contornar mecanismos de bloqueio de conta.
• Hybrid attacks: combinam palavras de dicionário com padrões comuns. Por exemplo, tentar Summer com anos adicionados, como Summer2023 e Summer2024, ou substituições comuns, como P@ssw0rd e Adm1n!.

Wordlists e dados de vazamentos

Com o tempo, pesquisadores de segurança e atacantes compilaram wordlists extensas contendo senhas vazadas em violações de dados.

Um exemplo clássico é a lista de senhas vazadas do RockYou, que pode ser encontrada no AttackBox em:

/usr/share/wordlists/rockyou.txt

/usr/share/wordlists/rockyou.txt

Wordlists modernas vão muito além do RockYou:

• SecLists é uma coleção de várias wordlists para diferentes finalidades, disponível em muitas distribuições de segurança em:

/usr/share/seclists/

/usr/share/seclists/

• CrackStation fornece wordlists otimizadas para quebra de senhas.
• Compilações de vazamentos contêm bilhões de senhas reais provenientes de várias violações de dados.

A escolha da wordlist deve depender do seu conhecimento sobre o alvo. Um usuário francês pode usar palavras em francês. Funcionários de uma empresa podem usar o nome da empresa com anos ou estações do ano.

Wordlists personalizadas para o alvo costumam ser mais eficazes do que listas genéricas.

THC Hydra

THC Hydra é uma ferramenta rápida e flexível de quebra de senhas que oferece suporte a muitos protocolos, incluindo FTP, POP3, IMAP, SMTP, SSH e todos os métodos relacionados a HTTP.

Ela fornece uma forma automatizada de testar senhas comuns ou entradas de uma wordlist contra serviços de rede.

A sintaxe geral de linha de comando é:

Onde as seguintes opções são especificadas:

• -l username: o nome de login do alvo.
• -P wordlist.txt: um arquivo de texto contendo as senhas que serão testadas.
• server: o hostname ou endereço IP do servidor-alvo.
• service: o serviço que você está atacando, por exemplo, ftp, ssh, imap, pop3 ou smtp.

Considere os exemplos a seguir:

Depois que a senha for encontrada, você pode pressionar CTRL-C para encerrar o processo.

Nas tasks do TryHackMe, espera-se que qualquer ataque seja concluído em menos de cinco minutos. Em cenários reais, os ataques levam mais tempo, e as opções de saída detalhada ou debug ajudam a monitorar o progresso.

Outras ferramentas de ataque a senhas

Embora o Hydra seja excelente para ataques contra serviços de rede, outras ferramentas servem a propósitos diferentes:

• Medusa é semelhante ao Hydra, mas possui um design modular. Algumas pessoas a consideram mais estável para determinados protocolos.
• Ncrack é desenvolvido pelo projeto Nmap e foi projetado para testes de autenticação paralelos em alta velocidade.
• CrackMapExec (CME) / NetExec é especializado em ambientes Windows e Active Directory, permitindo realizar password spraying em protocolos como SMB, WinRM, LDAP e outros.
• Burp Suite Intruder é útil para atacar formulários de login web quando os módulos HTTP do Hydra não funcionam corretamente.
• Hashcat e John the Ripper são usados para quebrar hashes de senha offline, em vez de atacar serviços ativos. Se você obtiver hashes de senha, por exemplo, a partir de um vazamento de banco de dados, essas ferramentas podem recuperar as senhas em texto claro muito mais rapidamente do que atacar um serviço online.

Mitigando ataques de senha

A mitigação contra ataques de senha depende do sistema-alvo. Defesas modernas incluem:

• Políticas de senha: impõem restrições mínimas de complexidade. Orientações modernas, como o NIST SP 800–63B, um padrão do governo dos Estados Unidos para diretrizes de identidade digital, recomendam focar mais no comprimento da senha do que em regras de complexidade, bloquear senhas conhecidas como comprometidas e não exigir trocas periódicas de senha, a menos que haja evidência de comprometimento.
• Bloqueio de conta: bloqueia temporária ou permanentemente uma conta após determinado número de tentativas malsucedidas. Isso é eficaz contra brute force, mas pode ser contornado por password spraying ou abusado para causar negação de serviço.
• Throttling e rate limiting: atrasam as respostas às tentativas de login. Alguns segundos de atraso são toleráveis para usuários legítimos, mas prejudicam bastante ferramentas automatizadas. Implementações mais sofisticadas usam exponential backoff.
• CAPTCHA: exige a resolução de um desafio difícil para máquinas. CAPTCHAs modernos usam análise comportamental e pontuação de risco, em vez de apenas reconhecimento de imagens.
• Multi-Factor Authentication (MFA): exige uma verificação adicional além da senha, como um código de aplicativo autenticador, SMS, embora SMS seja menos seguro, ou uma chave de segurança física. MFA é uma das defesas mais eficazes contra ataques de senha.
• Autenticação sem senha: elimina completamente as senhas usando métodos como:
• Passkeys, ou FIDO2/WebAuthn, que usam chaves criptográficas armazenadas nos dispositivos, substituindo senhas por verificação biométrica ou PIN.
• Magic links enviados por e-mail.
• Chaves de segurança físicas, como YubiKeys.
• Detecção de senhas vazadas: verifica senhas contra bases conhecidas de vazamentos durante o cadastro e o login. Serviços como Have I Been Pwned oferecem APIs para esse propósito.
• Análise comportamental: detecta anomalias, como tentativas de login a partir de locais incomuns, cenários de deslocamento impossível ou padrões consistentes com ataques automatizados.
• Controles baseados em IP: incluem geofencing, bloqueio de IPs maliciosos conhecidos e exigência de verificação adicional para novos dispositivos ou locais.

Usar uma combinação das abordagens acima fornece defesa em profundidade contra ataques de senha.

Para ambientes de alta segurança, migrar para autenticação sem senha elimina completamente muitos desses vetores de ataque.

Responda à pergunta abaixo:

Aprendemos que uma das contas de e-mail é lazie. Qual é a senha usada para acessar o serviço IMAP em 10.67.135.226?

Resposta: butterfly

Resumo

Esta sala examinou três ataques comuns contra protocolos de rede:

• Ataque de sniffing
• Ataque MITM
• Ataque de senha

Para cada um deles, o foco foi tanto na mecânica do ataque quanto nas etapas de mitigação.

Entender esses ataques fundamentais é essencial, pois eles formam a base para técnicas mais sofisticadas encontradas em testes de penetração avançados.

Principais aprendizados

O tema central desta sala é que protocolos em texto claro são inerentemente inseguros.

Qualquer protocolo que transmite dados sem criptografia é vulnerável a ataques de sniffing e MITM.

A solução é usar alternativas criptografadas:

• Use HTTPS em vez de HTTP.
• Use SSH em vez de Telnet.
• Use SFTP ou FTPS em vez de FTP.
• Use IMAPS, POP3S ou SMTPS em vez de suas versões em texto claro.

Mesmo com criptografia, a autenticação baseada em senha continua sendo um ponto fraco.

Senhas fortes, políticas de bloqueio de conta, rate limiting e autenticação multifator são defesas essenciais.

Sempre que possível, a autenticação sem senha usando passkeys ou autenticação baseada em certificados fornece uma segurança mais forte.

O cenário moderno

A maioria dos serviços expostos à internet usa criptografia TLS por padrão. No entanto, você ainda encontrará protocolos em texto claro em:

• Sistemas legados que não foram atualizados.
• Redes corporativas internas onde a criptografia nunca foi implementada.
• Dispositivos IoT e sistemas embarcados com capacidades limitadas.
• Serviços mal configurados, onde o TLS está disponível, mas não é obrigatório.
• Ambientes de desenvolvimento e teste.

Como pentester, identificar essas fraquezas e demonstrar seu impacto é uma habilidade valiosa.

Como defensor, garantir que todos os serviços usem criptografia e autenticação forte é um controle de segurança fundamental.

Trilhas de aprendizado relacionadas

Muitos outros ataques podem ser conduzidos contra servidores e protocolos específicos. Os módulos a seguir ajudarão você a desenvolver o que aprendeu aqui:

• Vulnerability Research: fornece mais informações sobre vulnerabilidades e exploits.
• Metasploit: treina você sobre como usar o Metasploit para explorar sistemas-alvo.
• Burp Suite: ensina como usar o Burp Suite para interceptar tráfego HTTP e lançar ataques relacionados à web.
• Network Security: aborda conceitos de segurança de rede, incluindo Nmap e evasão de firewall.

Referência de protocolos e portas

Os serviços abordados nesta sala estão listados na tabela a seguir, organizados em ordem alfabética.

*STARTTLS significa que a conexão começa sem criptografia na porta padrão e, em seguida, é atualizada para TLS depois que o cliente envia um comando STARTTLS.

Isso é diferente do TLS implícito, no qual a criptografia começa imediatamente após a conexão.

O STARTTLS é comum na porta 587 para envio de e-mail pelo cliente e também pode ser usado nas portas 25, 110 e 143.

Referência rápida do Hydra

O Hydra continua sendo uma ferramenta muito eficiente para ataques de senha contra serviços de rede.

Suas principais opções estão resumidas na tabela a seguir.

Ferramentas adicionais para explorar

Além do Hydra, considere aprender estas ferramentas que complementam o que foi abordado nesta sala:

Checklist defensivo

Ao avaliar ou proteger sistemas, verifique os seguintes pontos:

• Todos os serviços usam TLS 1.2 ou TLS 1.3 com suítes de criptografia fortes.
• Protocolos em texto claro, como Telnet, FTP e HTTP, estão desabilitados ou restritos a redes isoladas.
• O SSH usa autenticação baseada em chaves, com autenticação por senha desabilitada.
• Políticas de senha fortes são aplicadas, com detecção de senhas vazadas.
• Bloqueio de conta ou rate limiting está implementado para todos os pontos de autenticação.
• A autenticação multifator, ou MFA, está habilitada para sistemas sensíveis.
• A segmentação de rede limita o impacto de ataques de sniffing.
• A validação de certificados está corretamente implementada para prevenir ataques MITM.
• HSTS, ou HTTP Strict Transport Security, está habilitado em aplicações web para prevenir SSL stripping.
• Logs e monitoramento detectam anomalias de autenticação.

Entender tanto a perspectiva de ataque quanto a de defesa torna você um profissional de segurança mais eficaz, seja conduzindo testes de penetração ou construindo sistemas seguros.

Responda à pergunta abaixo:

Até aqui, você concluiu a oitava sala do módulo Network Security.Prossiga para a sala final deste módulo para testar suas habilidades.

Resposta: Não é necessária resposta