Como faço para recuperar recursos da AWS que foram afetados pelo agente CrowdStrike Falcon?

Breve descrição

Em 19 de julho de 2024, às 04:09 UTC, uma atualização do agente CrowdStrike Falcon (csagent.sys) fez com que dispositivos baseados em Windows apresentassem erros de parada não planejados ou tela azul. Os dispositivos afetados incluem instâncias do Amazon Elastic Compute Cloud (Amazon EC2) e desktops virtuais do Amazon WorkSpaces Personal. Esse problema afeta somente instâncias do Windows do Amazon EC2 e WorkSpaces pessoais com o CrowdStrike instalado.

Para obter mais informações, consulte o Remediation and Guidance Hub: Falcon Content Update for Windows Hosts no site do CrowdStrike.

Normalmente, uma reinicialização da sua instância ou do WorkSpace permite que o agente CrowdStrike Falcon seja atualizado com êxito.

Observação: se sua instância usa volumes de armazenamento de instâncias, os dados armazenados nesses volumes não persistem quando a instância é interrompida, hibernada ou encerrada. Quando a instância é interrompida, hibernada ou encerrada, o volume do armazenamento de instâncias é apagado criptograficamente. Para obter mais informações, consulte Armazenamento temporário em blocos de armazenamento de instâncias do Amazon EC2 para instâncias do Amazon EC2.

Resolução

Se uma reinicialização não restaurar a instância para um estado íntegro, use o runbook do AWS Systems Manager Automation para restaurar suas instâncias. Ou restaure-as manualmente.

Se você optar por usar o runbook, primeiro execute as seguintes ações:

• Se o volume raiz do Amazon Elastic Block Store (Amazon EBS) estiver criptografado, certifique-se de que a chave de criptografia exista na sua conta. Além disso, você deve ter permissão para usá-lo.
• O runbook AWSSupport-Startec2RescueWorkflow interrompe sua instância. Se sua instância usa volumes de armazenamento de instâncias, use o método de recuperação manual para evitar a perda de dados.
• Antes de iniciar o runbook AWSSupport-Startec2RescueWorkflow, certifique-se de que seu usuário ou perfil do AWS Identity and Access Management (IAM) tenha as permissões necessárias. Para obter mais informações, consulte a seção Required IAM permissions do AWSSupport-StartEC2RescueWorkflow. Você também deve adicionar a permissão kms:CreateGrant ao perfil do IAM.

Identifique instâncias prejudicadas

Observação: se você receber erros ao executar comandos da AWS Command Line Interface (AWS CLI), consulte Solucionar erros da AWS CLI. Além disso, verifique se você está usando a versão mais recente da AWS CLI.

Para identificar instâncias com falha, execute o comando describe-instance-status da AWS CLI:

aws ec2 describe-instance-status --filters Name=instance-status.status,Values=impaired --query "InstanceStatuses[*].InstanceId" --region your-region

Observação: substitua your-region pela sua região da AWS.

Use o runbook do AWS Systems Manager Automation para restaurar uma única instância do EC2

Para usar o AWSSupport-Startec2RescueWorkflow para automatizar a recuperação, abra o runbook no console do Systems Manager e selecione a região e a instância que você está recuperando. Se o volume raiz do EBS estiver criptografado, defina AllowEncryptedVolume como True.

Esse fluxo de trabalho de runbook inicia uma instância temporária do EC2 (instância auxiliar) em uma nuvem privada virtual (VPC). A instância executada é automaticamente associada ao grupo de segurança padrão da VPC. A instância deve permitir a comunicação HTTPS de saída (porta TCP 443) com os endpoints do Amazon Simple Storage Service (Amazon S3) e do Systems Manager.

Você deve iniciar a instância em uma das seguintes sub-redes para que a instância alcance os serviços da AWS necessários para concluir as tarefas do fluxo de trabalho:

• Sub-rede pública com o parâmetro AssociatePublicIpAddress definido como True.
• Sub-rede privada com acesso à Internet por meio de NAT.

A instância auxiliar monta o volume raiz das instâncias selecionadas e, em seguida, executa o seguinte comando para excluir o arquivo afetado:

get-childitem -path "$env:EC2RESCUE_OFFLINE_DRIVE\Windows\System32\drivers\CrowdStrike\" -Include C-00000291*.sys -Recurse | foreach { $_.Delete()}

Para verificar o conteúdo da carga útil do Base64 OfflineScript do comando anterior, execute o seguinte comando:

PS C:\Windows\system32> [System.Text.Encoding]::UTF8.GetString([System.Convert]::FromBase64String("REPLACE_WITH_BASE64_HERE"))

Use o runbook do AWS Systems Manager Automation para restaurar várias instâncias do EC2

Para usar o runbook em várias instâncias do EC2, use IDs de instância, tags ou grupos de recursos.

Observação:

• O runbook inicia uma instância auxiliar para cada instância selecionada.
• Verifique se você tem endereços IP suficientes na sub-rede selecionada para suas instâncias.
• Verifique se você tem cotas de instância e cotas de volume do EBS suficientes.
• O tempo que o runbook de automação leva para ser concluído depende da quantidade de simultaneidade selecionada.

Use IDs de instância

Conclua as seguintes etapas:

1. Abra o runbook AWSSupport-StartEC2RescueWorkflow no console do Systems Manager.
2. Em Executar o runbook de automação, escolha Controle de taxa.
3. Na seção Destinos, escolha InstanceId para Parâmetro e, em seguida, escolha Valores de parâmetros para Destinos.
4. Em Parâmetros de entrada, selecione as instâncias que você deseja restaurar.
5. Para Controle de taxa, escolha sua opção de simultaneidade para o número de recursos que podem executar simultaneamente a automação. Para obter mais informações, consulte Automações de controle em grande escala.
6. Escolha Executar.

Use tags

Conclua as seguintes etapas:

1. Crie uma tag nova e exclusiva para usar somente nas instâncias que você deseja restaurar. Todas as instâncias com essa tag são destinadas à recuperação e podem causar perda não intencional de dados ou afetar a disponibilidade da instância. Para obter mais informações, consulte Marcar com tag os recursos do Amazon EC2 e Using Tag Editor.
2. Para verificar se somente as instâncias afetadas compartilham a nova tag, use o AWS Resource Explorer ou o Tag Editor.
3. Abra o runbook AWSSupport-StartEC2RescueWorkflow no console do Systems Manager.
4. Em Executar o runbook de automação, escolha Controle de taxa.
5. Na seção Destinos, escolha InstanceId para Parâmetro e, em seguida, escolha Valores de parâmetros para Destinos.
6. Em Tags, escolha Editar, insira a chave e o valor da tag e escolha Salvar.
7. Em Parâmetros de entrada, selecione as instâncias que você deseja restaurar.
8. Para Controle de taxa, escolha sua opção de simultaneidade para o número de recursos que podem executar simultaneamente a automação. Para obter mais informações, consulte Automações de controle em grande escala.
9. Escolha Executar.

Use grupos de recursos

Conclua as seguintes etapas:

1. Crie um novo grupo de recursos para usar somente nas instâncias que você deseja restaurar. Todas as instâncias desse grupo de recursos são destinadas à recuperação e podem causar perda não intencional de dados ou afetar a disponibilidade da instância. Para obter mais informações, consulte Creating query-based groups in AWS Resource Groups.
2. Para verificar se somente as instâncias afetadas pertencem ao novo grupo de recursos, use o console do AWS Resources Groups.
3. Abra o runbook AWSSupport-StartEC2RescueWorkflow no console do Systems Manager.
4. Em Executar o runbook de automação, escolha Controle de taxa.
5. Na seção Destinos, escolha InstanceId para Parâmetro e, em seguida, escolha Valores de parâmetros para Destinos.
6. Em Grupos de recursos, selecione o novo grupo de recursos.
7. Em Parâmetros de entrada, selecione as instâncias que você deseja restaurar.
8. Para Controle de taxa, escolha sua opção de simultaneidade para o número de recursos que podem executar simultaneamente a automação. Para obter mais informações, consulte Automações de controle em grande escala.
9. Escolha Executar.

Restaure manualmente suas instâncias

Conclua as seguintes etapas:

1. Crie um snapshot do volume raiz do EBS da instância.
2. Crie um novo volume do EBS a partir do snapshot na mesma zona de disponibilidade.
3. Inicie uma nova instância do Windows na mesma zona de disponibilidade.
4. Anexe o novo volume do EBS à nova instância como um volume de dados.
5. Baixe a ferramenta EC2Rescue para Windows Server na instância auxiliar.
6. Clique com o botão direito em EC2Rescue.exe e escolha Executar como administrador.
   Selecione Eu concordo no Contrato de Licença.
   Na tela de boas-vindas, escolha Avançar.
   Na tela Selecionar modo, escolha Instância off-line.
   Selecione o disco offline e, em seguida, escolha Avançar. Quando solicitado, selecione Sim e depois OK.
   Mantenha o EC2 Rescue em execução.
   Observação: se sua instância original usa o BitLocker para criptografar o volume raiz do EBS, siga as instruções na tela para fornecer sua senha ou chave de recuperação do BitLocker. Ou você pode usar manage-bde unlock na linha de comando. Para obter mais informações, consulte manage-bde unlock no site da Microsoft. Depois que a unidade for desbloqueada, repita a etapa 6.
7. Navegue até a pasta X:\Windows\System32\drivers\CrowdStrike\ no volume anexado e, em seguida, exclua C-00000291*.sys.
   Observação: neste exemplo, X: é a letra da unidade atribuída ao volume secundário do EBS da instância afetada. Pode ser uma letra diferente em seu ambiente.
8. Retorne ao EC2 Rescue.
   Escolha Diagnosticar e resgatar e, em seguida, escolha Avançar.
   Mantenha todas as opções como padrão.
   Escolha Avançar e, em seguida, escolha Avançar novamente.
   Quando solicitado, escolha Rescue, escolha OK e, em seguida, Avançar.
   Escolha Concluir.
   Na janela pop-up exibida, selecione Corrigir assinatura de disco e OK.
   Se a opção Corrigir assinatura do disco estiver acinzentada, escolha OK.
9. Separe o volume do EBS da nova instância.
10. Crie um snapshot do volume EBS desanexado.
11. Selecione o mesmo tipo de volume (por exemplo, gp2 ou gp3) da instância afetada e, em seguida, crie uma Amazon Machine Image (AMI) a partir do snapshot.
12. Substitua o volume raiz na instância original do EC2 e especifique a AMI.

Amazon WorkSpaces

Se várias reinicializações não retornarem seu WorkSpace a um estado íntegro, restaure o WorkSpace para um snapshot anterior. Se a restauração do WorkSpace não retornar seu WorkSpace ao estado íntegro, reconstrua-o.

Resolução de problemas

Se as etapas anteriores não resolverem a conectividade com sua instância do EC2, siga estas etapas de solução de problemas para sua opção de recuperação.

Use o runbook do Systems Manager Automation

Problema: a instância auxiliar não pode se conectar aos endpoints de serviço da AWS. Esse problema pode causar uma falha na etapa do fluxo de trabalho de automação waitForEc2RescueInstanceToBeManaged.
Solução: confirme se o grupo de segurança padrão permite que o tráfego de saída (porta TCP 443) alcance o Systems Manager e os endpoints do S3. Além disso, certifique-se de que a sub-rede selecionada possa se conectar a esses endpoints. Para usar um grupo de segurança personalizado, atualize o valor do parâmetro HelperInstanceSecurityGroupId com seu ID de grupo de segurança. Se você escolher uma sub-rede pública, defina o parâmetro AssociatePublicIpAddress como True. Você também pode definir o parâmetro SubnetId como CreateNewVPC para que o autômato crie uma nova VPC com a conectividade necessária.

Problema: a instância afetada não é interrompida porque a proteção de parada está ativada.
Solução: desative a proteção de parada para a instância afetada e execute novamente a automação.
Observação: se sua instância usa volumes de armazenamento de instâncias, os dados armazenados nesses volumes não persistem quando a instância é interrompida.

Problema: a instância auxiliar falha ao iniciar.
Solução: o tipo de instância selecionado para a instância EC2Rescue pode não estar disponível na zona de disponibilidade da sub-rede da instância auxiliar. Use um tipo de instância compatível na mesma zona de disponibilidade da instância auxiliar.

Problema: a automação falha ao verificar se a criação da pilha do AWS CloudFormation foi concluída com o erro “Stack AWSSupport-EC2Rescue-{UUID} entered unexpected state: DELETE_IN_PROGRESS”.
Solução: para determinar o que causou a falha na pilha, obtenha o UUID e use o console do CloudFormation. A falha na pilha pode ocorrer se você não tiver permissões para criar os recursos da pilha. Para obter mais informações, consulte a seção Required IAM permissions do AWSSupport-StartEC2RescueWorkflow e Como solucionar erros de acesso negado ou operação não autorizada em uma política do IAM?

Problema: o runbook falha na etapa assertInstanceRootVolumeIsNotEncrypted do fluxo de trabalho de automação devido a um volume EBS criptografado.
Solução: se o volume usar criptografia do EBS, defina o parâmetro AllowEncryptedVolume como True.

Problema: a VPC padrão foi excluída.
Solução: defina o parâmetro SubnetId como CreateNewVPC para criar uma nova VPC que permita que a instância se recupere com sucesso.

Problema: a etapa detachInstanceRootVolume do fluxo de trabalho de automação falha com a mensagem de erro “error occurred (IncorrectState) when calling the DetachVolume operation: Unable to detach root volume”. 
Solução: ao executar a automação, mantenha a instância no estado Parado.

Restauração manual de instâncias

Problema: a instância falha ao inicializar com o erro: “O aplicativo ou o sistema operacional não pôde ser carregado porque um arquivo registrado está ausente ou contém erros”.
Solução: se você não selecionou Corrigir assinatura de disco, você pode ter uma colisão de assinatura de disco.
Para resolver esse problema, siga a etapa 8 nas etapas de restauração manual. Se você restaurou a instância sem o EC2 Rescue, consulte Problemas comuns com instâncias do Windows.

Observação: se as etapas anteriores de solução de problemas não resolverem a conectividade com sua instância do EC2, entre em contato com o AWS Support. Certifique-se de fazer uma captura de tela da instância inacessível.

Informações relacionadas

Run the EC2Rescue tool on unreachable instances