Imagine a situation. A cold October morning, a design institute in the regional center of one of Russia's regions. Someone from the HR department visits one of the job vacancy pages on the institute's website, posted a couple of days ago, and sees a photo of a cat. The morning quickly stops being boring...
In this article, Pavel Suprunyuk, the technical director of the auditing and consulting department at Group-IB, discusses the role of socio-technical attacks in projects assessing practical security, the unusual forms they can take, and how to protect against such attacks. The author clarifies that the article is of a review nature; however, if any aspect interests the readers, the experts at Group-IB are ready to answer questions in the comments.
Part 1. Why so serious?
Let's return to our cat. After some time, the HR department removes the photo (screenshots here and further are partially retouched to conceal real names), but it stubbornly reappears, gets deleted again, and this happens several more times. The HR department realizes that the cat has serious intentions and doesn't want to go away, prompting them to call for the help of a web programmer — the person who created the website and is familiar with it, now administering it. The programmer logs into the site, removes the annoying cat once more, discovers it was posted under the HR department's name, then hypothesizes that the HR password has leaked to some network pranksters, and changes it. The cat no longer appears.
What actually happened? Regarding the group of companies that included the institute, specialists from Group-IB conducted penetration testing in a format close to Red Teaming (in simpler terms, this is a simulation of targeted attacks on your company using the most advanced methods and tools from the arsenal of hacker groups). We detailed Red Teaming. It's important to know that a very wide range of attacks from previously agreed upon can be applied during such a test, including social engineering. Clearly, the placement of the cat was not the ultimate goal of what was happening. The actual goal was the following:
- the institute's website was hosted on a server within the institute's own network, rather than on third-party servers;
- uma vazamento da conta do departamento de recursos humanos foi encontrado (um arquivo de log de e-mails na raiz do site). Não era possível administrar o site com essa conta, mas páginas de vagas podiam ser editadas;
- ao alterar as páginas, era possível inserir scripts em JavaScript. Normalmente, isso torna as páginas interativas, mas nessa situação, esses mesmos scripts poderiam roubar do navegador do visitante o que diferenciava o departamento de recursos humanos de um programador, e o programador de um visitante comum — o identificador de sessão no site. O gato foi o gatilho do ataque e a imagem utilizada para chamar a atenção. Em HTML, isso parecia assim: se a imagem carregou, o JavaScript já foi executado e seu identificador de sessão, junto com os dados do seu navegador e IP, já foi roubado.
- Com o identificador de sessão do administrador em mãos, seria possível ter acesso total ao site, hospedar páginas executáveis em PHP, e assim obter acesso ao sistema operacional do servidor, e então à própria rede local, que era um objetivo intermediário importante do projeto.
O ataque terminou com um sucesso parcial — o identificador de sessão do administrador foi roubado, mas estava atrelado ao endereço IP. Não conseguimos contornar isso, não conseguimos elevar nossas permissões no site para nível de administrador, mas elevamos nosso ânimo. O resultado final foi obtido em outra parte do perímetro da rede.
Parte 2. Estou escrevendo para você — o que mais posso fazer? E também estou ligando e passando pelo seu escritório, derrubando pen drives.
O que aconteceu na situação do gato é um exemplo de engenharia social, embora não exatamente clássica. Na verdade, houve mais eventos nessa história: havia o gato, havia uma instituição, um departamento de recursos humanos, e um programador, mas também havia e-mails com perguntas de esclarecimento que supostos "candidatos" enviaram ao próprio departamento de recursos humanos e ao programador, a fim de provocá-los a acessar a página do site.
A propósito dos e-mails. Um email comum — provavelmente, o principal meio de execução de engenharia social — não perdeu sua relevância há várias décadas e, às vezes, leva a consequências das mais inusitadas.
A próxima história costumamos contar em nossos eventos, pois é muito ilustrativa.
Normalmente, com os resultados de projetos de engenharia social, elaboramos estatísticas, que são, como se sabe, coisas secas e chatolas. Uma certa porcentagem de destinatários abriu o anexo do e-mail, uma certa porcentagem clicou no link, e essas três pessoas até informaram seu login e senha. Em um projeto, obtivemos mais de 100% de inserção de senhas — ou seja, foi mais do que enviamos.
Isso ocorreu da seguinte forma: foi enviado um e-mail de phishing, supostamente do CISO de uma corporação pública, com a exigência de "testar urgentemente as alterações no serviço de e-mail". O e-mail chegou ao líder de um grande departamento que lidava com suporte técnico. O líder estava muito empenhado em cumprir as ordens da alta administração e o encaminhou a todos os subordinados. O call center em si era bastante grande. De modo geral, situações em que alguém encaminha "e-mails de phishing interessantes" para seus colegas e eles também caem na armadilha são bastante comuns. Para nós, esse é o melhor feedback sobre a qualidade da elaboração do e-mail.
Um pouco depois, fomos desmascarados (o e-mail foi enviado de uma caixa de correio comprometida):
O sucesso desse ataque foi causado pelo fato de que, durante o envio, foram exploradas várias falhas técnicas no sistema de e-mail do cliente. Ele estava configurado de tal forma que era possível enviar qualquer e-mail em nome de qualquer remetente da própria organização sem autenticação, mesmo da internet. Ou seja, era possível se passar pelo CISO, pelo chefe de suporte técnico ou por qualquer outra pessoa. Mais ainda, a interface do e-mail, ao observar e-mails do "seu" domínio, gentilmente inseria uma foto da lista de contatos, o que tornava o remetente mais natural.
Para ser honesto, esse tipo de ataque não se refere a tecnologias especialmente complexas, é uma exploração bem-sucedida de uma falha básica na configuração do e-mail. Isso é regularmente discutido em recursos especializados de TI e segurança da informação, mas ainda assim, há empresas onde isso tudo está presente. Uma vez que ninguém tende a verificar detalhadamente os cabeçalhos de serviço do protocolo de e-mail SMTP, o e-mail geralmente é verificado quanto a "perigos" pelos ícones de alerta da interface do e-mail, que nem sempre mostram o quadro completo.
É interessante notar que uma vulnerabilidade como essa funciona também em outra direção: um invasor pode enviar um e-mail em nome da sua empresa para um destinatário externo. Por exemplo, ele pode falsificar uma fatura de pagamento recorrente em seu nome, indicando, em vez dos seus dados, outros. Desconsiderando questões de antifraude e de retirada de fundos, essa é provavelmente uma das formas mais simples de roubo de dinheiro por meio de engenharia social.
Além do roubo de senhas por phishing, um clássico dos ataques socio-técnicos é a distribuição de anexos executáveis. Se esses anexos conseguirem ultrapassar todas as barreiras de proteção, que as empresas modernas geralmente possuem, um canal de acesso remoto será estabelecido no computador da vítima. Para demonstrar as consequências do ataque, o controle remoto obtido pode ser ampliado até o acesso a informações confidenciais extremamente importantes. É notável que a esmagadora maioria dos ataques que assustam a todos na mídia começa exatamente dessa forma.
Em nosso departamento de auditoria, por curiosidade, calculamos algumas estatísticas aproximadas: qual é o valor total dos ativos das empresas às quais tivemos acesso ao nível de 'Administrador de domínio' principalmente através de phishing e distribuição de anexos executáveis? Este ano, esse valor atingiu aproximadamente 150 bilhões de euros.
É claro que o envio de e-mails provocativos e a publicação de fotos de gatos em sites não são as únicas formas de engenharia social. Nestes exemplos, tentamos mostrar a diversidade das formas de ataque e suas consequências. Além de e-mails, um potencial atacante pode ligar para obter as informações necessárias, espalhar dispositivos (como pen drives) com arquivos executáveis no escritório da empresa-alvo, se candidatar a um estágio para obter acesso físico à rede local sob o pretexto de ser um instalador de câmeras de vigilância. Todos esses são, aliás, exemplos de nossos projetos concluídos com sucesso.
Parte 3. A aprendizagem é luz, enquanto a ignorância é escuridão.
Surge uma pergunta pertinente: tudo bem, existe engenharia social, parece perigosa, mas o que as empresas devem fazer a respeito? O Capitão Óbvio vem em socorro: é necessário proteger-se, e de forma abrangente. Parte da proteção deve ser direcionada a medidas de segurança que já se tornaram clássicas, como os meios técnicos de proteção da informação, monitoramento, e a implementação organizacional e legal dos processos. Contudo, a maior parte, em nossa opinião, deve focar no trabalho direto com os funcionários, que são o elo mais frágil. Afinal, não importa o quanto você fortaleça a tecnologia ou escreva regulamentos rígidos, sempre haverá um usuário que encontrará uma nova forma de quebrar tudo. E nem os regulamentos nem a tecnologia conseguirão acompanhar a criatividade do usuário, especialmente quando orientado por um criminoso qualificado.
Em primeiro lugar, é importante treinar o usuário: explicar que mesmo em seu trabalho rotineiro, podem surgir situações relacionadas à engenharia social. Para nossos clientes, frequentemente realizamos sobre higiene digital — eventos que ensinam habilidades básicas para combater ataques em geral.
Posso acrescentar que uma das melhores medidas de proteção não é memorizar regras de segurança da informação, mas sim uma avaliação um tanto distanciada da situação:
- Quem é meu interlocutor?
- De onde surgiram suas propostas ou pedidos (isso nunca aconteceu antes, e agora apareceu)?
- O que há de incomum neste pedido?
Até mesmo um tipo de fonte de e-mail incomum ou um estilo de fala atípico do remetente pode desencadear uma cadeia de dúvidas que interromperá o ataque. Instruções escritas também são necessárias, mas funcionam de maneira diferente, não podendo especificar todas as possíveis situações. Por exemplo, os administradores de segurança da informação escrevem que não se deve inserir sua senha em recursos de terceiros. E se o recurso «seu», «corporativo», da rede pedir a senha? O usuário pensa: «Na nossa empresa, já existem duas dezenas de serviços com uma única conta, por que não poderia haver mais um?» Daí decorre mais uma regra: um fluxo de trabalho bem estruturado também afeta diretamente a segurança: se um departamento vizinho pode solicitar informações apenas por escrito e somente através do seu superior, uma pessoa «de um parceiro de confiança da empresa» não poderá solicitá-las por telefone — para você isso será um absurdo. É especialmente importante ficar alerta se o seu interlocutor exige que tudo seja feito imediatamente, ou «ASAP», como é moda escrever. Mesmo no trabalho cotidiano, essa situação muitas vezes não é saudável, e em condições de possíveis ataques — é um forte gatilho. Não há tempo para explicar, execute meu arquivo!
Percebemos que os usuários, como lendas para um ataque sociotécnico, sempre são influenciados por temas relacionados a dinheiro de alguma forma: promessas de aumentos, privilégios, presentes, além de informações com supostas fofocas e intrigas locais. Em outras palavras, os mesmos velhos «pecados capitais» funcionam: avareza, ganância e curiosidade excessiva.
Um bom treinamento sempre deve incluir prática. Aqui, especialistas em testes de penetração podem ajudar. A próxima pergunta é: o que e como vamos testar? Na Group-IB, propomos a seguinte abordagem — escolher imediatamente o foco do teste: ou avaliar a prontidão para ataques apenas dos próprios usuários, ou verificar a segurança da empresa como um todo. E testar métodos de engenharia social, simulando ataques reais — ou seja, o mesmo phishing, envio de documentos executáveis, ligações e outras técnicas.
No primeiro caso, o ataque é cuidadosamente planejado em conjunto com representantes do cliente, principalmente com seus especialistas em TI e segurança da informação. As lendas, ferramentas e técnicas de ataque são acordadas. O cliente fornece grupos focais e listas de usuários para o ataque, que incluem todos os contatos necessários. Exceções são criadas nas medidas de proteção, uma vez que as mensagens e cargas úteis devem chegar ao destinatário, pois, neste projeto, o interesse está apenas na reação das pessoas. Opcionalmente, podem ser inseridos marcadores no ataque, por meio dos quais o usuário pode perceber que se trata de um ataque — por exemplo, é possível cometer alguns erros de ortografia nas mensagens ou deixar imprecisões na cópia do estilo da marca. Ao final do projeto, obtém-se a chamada "estatística seca": quais grupos focais e em que volume reagiram aos cenários.
No segundo caso, o ataque é realizado com conhecimentos iniciais nulos, pelo método "caixa-preta". Coletamos informações sobre a empresa, seus funcionários, perímetro de rede, formamos lendas para o ataque, escolhemos métodos e buscamos possíveis meios de proteção utilizados na empresa-alvo, adaptamos ferramentas e elaboramos cenários. Nossos especialistas utilizam tanto métodos clássicos de inteligência de fontes abertas (OSINT) quanto o produto desenvolvido pela Group-IB — Threat Intelligence, um sistema que, na preparação para phishing, pode atuar como um agregador de informações sobre a empresa por um longo período, incluindo informações confidenciais. Obviamente, para que o ataque não se torne uma surpresa desagradável, seus detalhes também são acordados com o cliente. O resultado é um teste de penetração completo, mas com uma engenharia social avançada no seu cerne. Uma opção lógica nesse caso é desenvolver o ataque dentro da rede, chegando até os níveis mais altos de privilégios em sistemas internos. Aliás, aplicamos ataques sociotécnicos de forma semelhante em , e em alguns testes de penetração. O resultado é que o cliente receberá uma visão independente e abrangente de sua proteção contra determinado tipo de ataques sociotécnicos, além de uma demonstração da eficácia (ou, pelo contrário, ineficácia) da linha de defesa estabelecida contra ameaças externas.
Recomendamos realizar esse tipo de treinamento pelo menos duas vezes por ano. Em primeiro lugar, toda empresa tem rotatividade de funcionários e a experiência anterior é gradualmente esquecida. Em segundo lugar, as técnicas e modos de ataque estão sempre mudando, o que leva à necessidade de adaptação dos processos de segurança e dos meios de proteção.
Se falarmos sobre medidas técnicas de proteção contra ataques, as seguintes ajudam consideravelmente:
- A presença obrigatória de autenticação de dois fatores nos serviços publicados na internet. Lançar em 2019 serviços assim sem sistemas de Single Sign On, sem proteção contra força bruta de senhas e sem autenticação de dois fatores em uma empresa com várias centenas de funcionários é equivalente a um convite aberto para "quebrar meu sistema". Uma proteção implementada corretamente tornará a rápida utilização de senhas roubadas impossível e dará tempo para remediar as consequências de um ataque de phishing.
- Controle de restrição de acesso, minimização de direitos dos usuários nos sistemas e cumprimento das diretrizes de configuração segura dos produtos lançados por cada grande fabricante. Essas são frequentemente medidas simples em essência, mas muito eficazes e difíceis de implementar na prática, que todos, de certa forma, negligenciam em prol da velocidade de trabalho. Algumas são tão necessárias que, sem elas, nenhum meio de proteção pode garantir segurança.
- Uma linha de filtragem de e-mails bem estruturada. Antispam, verificação completa de anexos em busca de código malicioso, incluindo testes dinâmicos por meio de sandboxes. Um ataque bem preparado pressupõe que o anexo executável não será detectado por meios antivírus. A sandbox, ao contrário, testará tudo, usando os arquivos da mesma forma que um humano os utilizaria. Como resultado, qualquer componente malicioso será revelado pelas mudanças que provoca dentro da sandbox.
- Meios de proteção contra ataques direcionados. Como já mencionado, os clássicos softwares antivírus não detectam arquivos maliciosos em um ataque bem planejado. Os produtos mais avançados devem automaticamente monitorar a soma de eventos que ocorrem na rede — tanto no nível de um host individual quanto no nível do tráfego dentro da rede. Em caso de ataques, surgem cadeias de eventos muito características que podem ser rastreadas e interrompidas, se houver um monitoramento focado em eventos desse tipo.
Artigo original na revista «Information Security/ Segurança da Informação» #6, 2019.
Fonte: habr.com
