Simulado
SECURITY+
baseado em
SOC!
Treine para a prova Security+ e aplique os conceitos em um cenário real de SOC!
Reforce os domínios da Security+ (Ameaças/Vulnerabilidades, Arquiteturas e Design, Implementação, Operações e Resposta, Governança e Risco) e veja como eles se aplicam no dia a dia de um SOC.
Faça a correlação entre a realidade e os conhecimentos adquiridos nos estudos dos cinco domínios da CompTIA Security+ respondendo questões ambientadas no dia a dia de um SOC!
Todas as questões foram criadas do zero, baseadas completamente no que pede a CompTIA Security+. Aqui não tem tradução mal feita ou questões copiadas e coladas de inteligência artificial!
SECURITY+ AMBIENTADO EM SOC
Neste simulado você terá:
Simulado para a realidade de um SOC
Na prática com a teoria
Este simulado não é apenas teoria - cada questão foi projetada para ligar o conteúdo da prova ao contexto de SOC real.
Mais importante do que saber como são as questões é saber como aplicar o conhecimento na vida real!
Amostras
Veja algumas questões que estão no simulado
1. Ao analisar eventos do web server do cliente durante um threat hunting, o analista do SOC percebe a seguinte URL:
https://sitedocliente.com.br/login.php?user=admin'/**/O/**/R/**/'1'='1
Ele nota que se trata de um SQL Injection, porém a regra de detecção não pegou essa tentativa. Qual técnica foi aplicada pelo ator de ameaça?
https://sitedocliente.com.br/login.php?user=admin'/**/O/**/R/**/'1'='1
Ele nota que se trata de um SQL Injection, porém a regra de detecção não pegou essa tentativa. Qual técnica foi aplicada pelo ator de ameaça?
➤ Clique aqui para ler a resposta e a explicação
Resposta correta: A
Explicação: Sabe-se que o operador 'OR' é muito usado em ataques de SQL Injection. No entanto, na URL da questão, aparecem comentários de SQL entre o 'O' e o 'R' e em demais partes. Como comentários são ignorados na execução, que nesse caso seria no banco de dados da aplicação web, então se trata do operador 'OR'. A regra de detecção de SQL Injection não pegou essa tentativa pois, provavelmente, contém os caracteres 'OR' diretamente escritos na regra, sem prever possíveis comentários de SQL, e como o SIEM interpreta os caracteres como textos puros e não como comandos de SQL, então ele não usou a regra em questão. Essa é uma tática muito comum de obfuscação, pois não foram escondidos os caracteres reais do dado (no caso, do comando), e sim criadas distrações irrelevantes na execução do comando para tentar evitar de ser detectado justamente por regras de SIEM, pois é muito difícil um engenheiro de detecção de um SOC prever todos os tipos de obfuscações possíveis de serem empregadas numa string - principal motivo da necessidade de trabalhos de threat hunting em SOC. O caso não é de hashing pois os dados não foram criptografados de maneira unilateral, nem de criptografia real pois é possível ver o comando SQL entre os comentários, e também não é mascaramento de dados pois é possível ver todos os caracteres, e não apenas uma parte, usados no comando SQL, só que entre comentários.
Explicação: Sabe-se que o operador 'OR' é muito usado em ataques de SQL Injection. No entanto, na URL da questão, aparecem comentários de SQL entre o 'O' e o 'R' e em demais partes. Como comentários são ignorados na execução, que nesse caso seria no banco de dados da aplicação web, então se trata do operador 'OR'. A regra de detecção de SQL Injection não pegou essa tentativa pois, provavelmente, contém os caracteres 'OR' diretamente escritos na regra, sem prever possíveis comentários de SQL, e como o SIEM interpreta os caracteres como textos puros e não como comandos de SQL, então ele não usou a regra em questão. Essa é uma tática muito comum de obfuscação, pois não foram escondidos os caracteres reais do dado (no caso, do comando), e sim criadas distrações irrelevantes na execução do comando para tentar evitar de ser detectado justamente por regras de SIEM, pois é muito difícil um engenheiro de detecção de um SOC prever todos os tipos de obfuscações possíveis de serem empregadas numa string - principal motivo da necessidade de trabalhos de threat hunting em SOC. O caso não é de hashing pois os dados não foram criptografados de maneira unilateral, nem de criptografia real pois é possível ver o comando SQL entre os comentários, e também não é mascaramento de dados pois é possível ver todos os caracteres, e não apenas uma parte, usados no comando SQL, só que entre comentários.
2. O SOC recebe quase mil alertas de tentativas de login no Active Directory do cliente. Ao analisar as tentativas o analista percebe que em todas elas nenhum nome de usuário foi reutilizado, ou seja, em cada tentativa um nome de usuário diferente era tentado. Que tipo de ataque melhor se alinha com as características desse incidente?
➤ Clique aqui para ler a resposta e a explicação
Resposta correta: A
Explicação: O fato de não ter tentado mais de uma vez a descoberta da senha de cada nome de usuário define que um Password Spraying foi executado. Nesse tipo de ataque, o ator de ameaças tenta uma senha única, geralmente das mais comuns, e procura adivinhar qual usuário utilizou tal senha fraca. Ao contrário do Brute Force, onde poucos usuários diferentes são tentados mas muitas senhas distintas são usadas para tentar adivinhar a combinação dessas credenciais. Já em Default Credentials (credenciais padrões) se utiliza credenciais padrões como admin/admin, root/toor e similares, não havendo grande variação de nomes de usuários tentados pois esses nomes geralmente são parecidos com "admin". O incidente do enunciado não se trata de um Credential Stuffing, que é quando credenciais de vazamentos anteriores são tentados e, quando uma senha de um determinado usuário citado nesse vazamento não é válida, geralmente tenta-se o mesmo usuário com outra senha já que pode ter havido uma troca de senha após a descoberta do vazamento, mas geralmente o nome do usuário se mantém na organização.
Explicação: O fato de não ter tentado mais de uma vez a descoberta da senha de cada nome de usuário define que um Password Spraying foi executado. Nesse tipo de ataque, o ator de ameaças tenta uma senha única, geralmente das mais comuns, e procura adivinhar qual usuário utilizou tal senha fraca. Ao contrário do Brute Force, onde poucos usuários diferentes são tentados mas muitas senhas distintas são usadas para tentar adivinhar a combinação dessas credenciais. Já em Default Credentials (credenciais padrões) se utiliza credenciais padrões como admin/admin, root/toor e similares, não havendo grande variação de nomes de usuários tentados pois esses nomes geralmente são parecidos com "admin". O incidente do enunciado não se trata de um Credential Stuffing, que é quando credenciais de vazamentos anteriores são tentados e, quando uma senha de um determinado usuário citado nesse vazamento não é válida, geralmente tenta-se o mesmo usuário com outra senha já que pode ter havido uma troca de senha após a descoberta do vazamento, mas geralmente o nome do usuário se mantém na organização.