0 
0 Na Parte 1 de nossas histórias de ataques à nuvem do mundo real , examinamos exemplos do mundo real de dois ataques comuns à nuvem. O primeiro a partir de um mercado de software como serviço (SaaS), demonstrando a amplitude de possíveis vetores de acesso para ataques à nuvem e como ele pode permitir o movimento lateral para outros recursos da nuvem, incluindo o ambiente AWS de uma empresa. O segundo ataque na nuvem demonstrou como os invasores assumem a infraestrutura da nuvem para injetar criptomineradores para seu lucro.
Como testemunhamos, mais ataques foram movidos para a nuvem , então era apenas uma questão de tempo até que os ataques de ransomware também o fizessem. Vejamos dois cenários em que os invasores aproveitaram o ransomware para obter lucros e como os recursos exclusivos da nuvem ajudaram as vítimas a evitar o pagamento do resgate.
Demanda do MongoDB Ransomware mitigada
O primeiro caso (ou melhor, casos, pois esse ataque já apareceu várias vezes) é o notório ransomware MongoDB , que está em andamento há anos. O ataque em si é simples — os invasores usam um script para varrer a Internet (e agora, espaços de endereço de fornecedores de nuvem comuns) em busca de hosts que executam o MongoDB expostos à Internet. Os invasores tentam se conectar ao MongoDB com a senha de administrador vazia. Se for bem-sucedido, o ataque apaga o banco de dados e o substitui por uma nota dupla de ransomware : pague e seus dados serão devolvidos; não pague, e seus dados serão vazados.
A intervenção foi necessária para resolver a segunda parte do esquema de extorsão: vazamento de dados. Felizmente, a empresa tinha backups de dados, então a recuperação foi fácil, mas o banco de dados continha quantidades consideráveis de informações de identificação pessoal (PII), que, se vazadas, seriam uma grande crise para a empresa. Isso os forçou a pagar um resgate pesado ou lidar com a imprensa. O log padrão do MongoDB, infelizmente, não pode fornecer uma resposta definitiva sobre os dados acessados, pois nem todos os tipos potenciais de comandos de coleta de dados são registrados por padrão.
Foi aqui que a infraestrutura em nuvem se tornou uma vantagem. Embora o MongoDB possa não registrar todos os comandos, a AWS registra o tráfego que entra e sai dos servidores, porque cobra pelos custos da rede. Correlacionar o tráfego de rede que sai do servidor atacado com os horários em que os invasores estavam conectados ao servidor MongoDB comprometido forneceu prova de que os dados não poderiam ter sido baixados pelos invasores.
Isso permitiu que a empresa evitasse o pagamento do resgate e ignorasse a ameaça. Como esperado, nada mais foi ouvido dos atacantes.
Mitigação de Ransomware em um Ambiente de Nuvem
Outra empresa sofreu um ataque em seus principais servidores executados no AWS EC2 , onde foi atingida por um Trojan de ransomware, não muito diferente dos vistos em servidores locais. Como ocorre com frequência nos dias de hoje, esse foi outro ataque de ransomware de dupla extorsão e a empresa precisava de ajuda para lidar com os dois problemas.
Felizmente, devido à arquitetura e preparação da nuvem da empresa, havia instantâneos da AWS do ambiente de 14 dias atrás. Os invasores não tinham conhecimento dos instantâneos e não os desabilitaram em seu ataque. Isso permitiu que a empresa voltasse imediatamente para o dia anterior à criptografia de dados, resolvendo a primeira parte do ataque com o mínimo de esforço. Isso ainda deixou dois desafios a serem enfrentados: o possível vazamento de dados e a erradicação dos invasores do ambiente.
Para enfrentar esses desafios, houve uma investigação completa da violação, que se mostrou bastante complexa devido à natureza híbrida de seu ambiente. Os invasores comprometeram uma única conta com acesso limitado, usada por uma pessoa de TI. Em seguida, eles identificaram um servidor local legado onde esse indivíduo era um administrador e o usaram para assumir a conta de serviço Okta, permitindo o escalonamento de privilégios. Por fim, usando um serviço de VPN desativado, eles conseguiram pular para o ambiente de nuvem. Usando os privilégios elevados, eles assumiram os servidores EC2 e instalaram o malware.
A investigação produziu dois resultados significativos. A primeira foi a linha do tempo do ataque. Ele mostrou que o comprometimento de todos os hosts ocorreu antes que os primeiros instantâneos fossem tirados, indicando que os servidores recuperados foram comprometidos e não puderam ser usados. Novos servidores foram instalados, os dados foram transferidos para eles e os servidores originais afetados foram removidos.
A segunda descoberta foi ainda mais surpreendente. A análise de malware identificou que os invasores usaram o rclone.exe para copiar os arquivos para um local remoto. As credenciais de conexão foram codificadas no malware, para que a empresa pudesse se conectar ao mesmo local, identificar e remover seus arquivos, eliminando o acesso dos invasores aos arquivos, erradicando o aspecto de extorsão do ataque.
As violações da nuvem estão aqui para ficar
Como esses cenários da vida real revelam, os invasores estão se infiltrando na nuvem e as violações na nuvem estão aumentando . É hora das organizações se prepararem para incidentes na nuvem. Os cibercriminosos estão aproveitando os recursos da nuvem em ataques, e você também deve usá-los para proteger sua organização e evitar que uma crise chegue às manchetes.
FONTE: DARK READING