Detectando ataques baseados em credenciais no Databricks

Na Databricks, sabemos que seus dados são seu ativo mais valioso. A Databricks trabalhou com milhares de clientes para implantar de forma segura a Databricks Data + AI Platform com os recursos adequados para atender aos seus requisitos de segurança, privacidade e regulatórios.

O ciberataque moderno nem sempre começa com um perímetro rompido; ele começa com um login válido. Assim que um invasor obtém um cookie de sessão vazado, um token de acesso pessoal (PAT) ou uma credencial de principal de serviço, a invasão inicial já está concluída. A partir desse momento, todo o objetivo dele é se misturar e operar sob o disfarce de seu usuário ou serviço comprometido.

Mas ter uma chave não significa que você conhece o prédio. Imagine um intruso passando um crachá para entrar em um escritório seguro. Ele pode ter passado pelas portas giratórias, mas ainda precisa lidar com o segurança, adivinhar a quais andares tem acesso e descobrir onde fica o cofre. Como um invasor não tem o contexto profundo e localizado dos seus funcionários reais, o comportamento dele eventualmente o entregará. Detectar essas irregularidades é a forma como você o pega.

Nesta postagem, detalhamos como ocorre um ataque baseado em credenciais na plataforma Databricks, como detectar a mudança no comportamento de uma identidade usando os logs de auditoria detalhados da Databricks e o Genie, como responder após confirmar um comprometimento e quais controles limitam o que uma credencial roubada pode fazer inicialmente.

Um modelo para rastrear ataques baseados em credenciais

Ao estabelecer o acesso por meio de credenciais legítimas, os invasores, assim como os profissionais de segurança, também entendem que seu acesso pode ser revogado a qualquer momento se eles se desviarem muito do comportamento esperado da identidade. Os invasores contam com sequenciamento de ataques não linear, como validar um conjunto de credenciais para mapear seu ambiente e, em seguida, recuperar outro conjunto de credenciais para retornar por meio de uma nova identidade ou workspace que não tenha atividade de reconhecimento associada a ele. Além disso, os invasores podem coletar informações sem estabelecer persistência ou encontrar uma forma de voltar para a sua plataforma Databricks antes de concluírem seus objetivos.

Como isso se parece na prática

Considere um engenheiro de dados cujo token de acesso pessoal foi copiado de um log de integração e entrega contínuas (CI/CD) mal configurado. Em minutos, o token é usado a partir de um novo IP para listar escopos de segredos, catálogos e repositórios em todo o workspace, algo que esse engenheiro nunca fez. Um segredo que contém a credencial de um principal de serviço é lido. Uma hora depois, esse principal de serviço, e não o engenheiro, cria uma função, adiciona a si mesmo a um grupo de administradores e exporta alguns scripts de inicialização. Cada um desses eventos pode passar por uso rotineiro da plataforma, mas, vistos em conjunto, eles mostram uma intrusão progredindo na cadeia de ataques.

Na Databricks, esperamos um sequenciamento de eventos não linear em relação a ataques baseados em credenciais e usamos esse modelo para conectar eventos individuais em uma única investigação, em vez de tratá-los como eventos não relacionados.

Os seis estágios de um ataque baseado em credenciais

Quando os invasores usam credenciais comprometidas em um ambiente de Plataforma como Serviço (PaaS), como o Databricks, a atividade deles pode ser agrupada em seis estágios, embora raramente avancem por eles em linha reta. Cada estágio abaixo descreve o que o invasor está tentando fazer e o que procurar nas tabelas de log de auditoria da Databricks. Trate esta orientação como um ponto de partida e ajuste-a para a automação normal do seu ambiente.

Observação: Os eventos são gravados como service_name.action_name, por exemplo secrets.getSecret.

1. O invasor obtém acesso com credenciais válidas

O login em si raramente parece incomum. Como a credencial é real, a autenticação é bem-sucedida como seria para o proprietário legítimo. No entanto, o que a identidade faz nos minutos após o login costuma ser muito diferente de sua atividade normal, e essa mudança é o que os responsáveis pela resposta a incidentes podem detectar. No exemplo do engenheiro de dados, o token roubado se autentica com sucesso, e a única diferença no login é um IP de origem que o engenheiro nunca usou. A atividade que se segue é o que se destaca.

Objetivo do invasor: Acessar o workspace com credenciais válidas, seja uma sessão de navegador roubada, um PAT reutilizado ou uma credencial de principal de serviço, e misturar-se à atividade que os controles foram criados para permitir.

O que procurar:

• Use o evento de autenticação como o ponto de partida para sua linha do tempo. Um login isolado raramente é suficiente para gerar um alerta, mas seu user_identity, source_ip_address, user_agent, sessionId, request_id e workspace_id permitem que você acompanhe o que a credencial faz em seguida.
• Marque eventos accounts.tokenLogin que chegam em uma rajada curta de um cliente desconhecido e são seguidos pelo uso do mesmo token de um IP de origem diferente. Esse padrão pode indicar que alguém está testando um token roubado, e requestParams.tokenId permite vincular esses eventos ao mesmo token.
• Marque tokens OAuth de principais de serviço que são gerados a partir da rede esperada com um agente de usuário inesperado, especialmente quando a atividade de um novo IP de origem ocorre em até um minuto.

2. O invasor mapeia o ambiente

Em seguida, o invasor precisa descobrir o que a credencial pode alcançar antes que o acesso seja revogado. Como resultado, uma identidade comprometida pode mudar de sua atividade comum para listar dados, segredos, código e controles de rede em segundos. Esse reconhecimento geralmente abrange vários serviços de uma só vez e se move mais rápido do que uma pessoa navegando pela interface do usuário. No nosso cenário, esse estágio é a rajada de chamadas listando escopos de segredos, catálogos e repositórios minutos após o uso do token, o que é uma atividade que o engenheiro nunca realizou antes.

Objetivo do invasor: Construir um mapa de dados acessíveis, credenciais, repositórios e salvaguardas para planejar um caminho mais profundo no ambiente antes que o acesso seja revogado.

O que procurar:

• Procure uma única identidade fazendo chamadas rápidas de listagem nos planos de workspace e de conta, como secrets.listScopes / listSecrets, unityCatalog.listMetastores / listCatalogs / listSchemas / listExternalLocations / listStorageCredentials, repos.listRepos e accountsManager.listWorkspaceConfigurations / listNetworkConfigurations / listStorageConfigurations no nível da conta. Por exemplo, cinco ou mais APIs de descoberta distintas chamadas em um minuto dificilmente correspondem a uma pessoa navegando na plataforma.
• Compare a atividade com a linha de base da identidade. A primeira enumeração de segredos já realizada por uma identidade estabelecida, ou uma sessão SQL que muda de consultas de negócios para SHOW TABLES em esquemas de controle de acesso e configuração, é mais significativa do que um alto volume de chamadas. Quando o registro de auditoria detalhado está ativado, commandSubmit preserva a consulta em commandText.
• Inclua solicitações com falha em sua pesquisa. Investigue a primeira IpAccessDenied de uma identidade, especialmente quando ela segue accounts.oidcTokenAuthorization ou se repete em workspaces. Nesse caso, a autorização foi bem-sucedida, mas a solicitação veio de uma rede bloqueada, o que costuma ser o registro mais antigo de uma credencial sendo reutilizada de um local não confiável.

3. O invasor coleta mais credenciais

A coleta de credenciais geralmente exige várias etapas. O invasor lista os escopos de segredos, lista os segredos neles e, em seguida, lê aqueles que parecem úteis. O valor recuperado permite que ele retorne como uma identidade diferente, frequentemente com mais privilégios. Por esse motivo, vale a pena acompanhar cada segredo lido por uma identidade suspeita. No exemplo do engenheiro de dados, o invasor lê um segredo que contém a credencial de um principal de serviço. A partir desse momento, a investigação precisa acompanhar duas identidades: o engenheiro e o principal de serviço.

Objetivo do invasor: Recuperar um token, chave de API ou segredo de principal de serviço que atualize o ponto de acesso inicial para acesso em todo o ambiente sob uma nova identidade.

O que procurar:

• Configure alertas para a progressão de chamadas. secrets.listScopes por conta própria é comum e gera ruído. No entanto, listScopes seguido por listSecrets e depois getSecret, repetido em vários escopos em rápida sucessão, indica extração de dados. listSecrets registra o escopo, e getSecret registra tanto o escopo quanto a chave.
• Correlacione leituras negadas com leituras bem-sucedidas posteriores. Um getSecret negado em um escopo rigidamente controlado, seguido por uma leitura bem-sucedida da mesma chave ou de uma chave relacionada em um escopo menos restrito, sugere que a identidade está procurando uma cópia que possa acessar.
• Monitore o acesso do lado da computação além da API de segredos. Quando o registro de auditoria detalhado está ativado, os eventos de submitCommand em notebook e commandSubmit no Databricks SQL podem mostrar código chamando utilitários de segredos ou executando read_files() em caminhos que contêm credenciais. Lembre-se de que o texto enviado mostra o que foi executado, mas não confirma que um valor foi retornado.
• Conecte cada leitura de segredo ao que acontece em seguida, como um novo accounts.tokenLogin, atividade de service principal vista pela primeira vez, um IP ou user agent alterado, ou chamadas de generateTemporaryTableCredential / generateTemporaryVolumeCredential. Durante a resposta, redefina todas as credenciais que a identidade possa ter alcançado e verifique onde cada uma foi usada, além de onde foi armazenada.

4. O invasor encontra um caminho de execução viável

Uma vez estabelecido o acesso, os invasores procuram uma maneira de executar seu próprio código. No Databricks, isso geralmente acontece por meio de funções definidas pelo usuário (UDFs) e jobs. Uma função pode encapsular uma carga útil em código de aparência comum que pode ser chamado repetidamente, e um job pode executar esse código em uma programação em diferentes recursos de computação. Como tal, a pergunta chave para detecção é se uma identidade começou a realizar ações que não havia realizado antes. Voltando ao engenheiro de dados, uma hora após a leitura do segredo, o service principal cria uma função. Como o service principal, em vez do engenheiro, realiza essa ação, uma pesquisa restrita apenas à atividade do engenheiro não a encontraria.

Objetivo do invasor: Estabelecer uma maneira confiável e reutilizável de executar cargas úteis, com uma alternativa quando uma rota de computação for bloqueada.

O que procurar:

• Priorize eventos createFunction de uma identidade, IP ou catálogo sem histórico de criação de funções, especialmente quando vários aparecem em um curto período. Onde as definições de função estiverem disponíveis, sinalize códigos que executam processos, avaliam códigos dinamicamente, acessam metadados de instâncias, abrem conexões de rede de saída ou gravam no armazenamento em nuvem. Rastreie também referências entre funções, pois um wrapper de aparência inofensiva pode chamar uma UDF de maior risco. Observe que function_info em system.access.audit é mascarado, exceto para administradores de conta e databricks_pii_access; portanto, combine dados de auditoria com inventários de funções.
• Rastreie o caminho de Jobs por identidade, IP e ID de job ou execução. Uma sequência típica é importNotebook, depois changeJobAcl, Jobs create, runNow e getRunOutput. Esses eventos raramente preservam o corpo do notebook, portanto, retenha as versões do notebook e as configurações de job junto com eles. Atividades repetidas de importação e execução de uma única fonte são um sinal mais forte do que qualquer uma das ações isoladamente.
• Procure uma identidade que altere o recurso de computação após uma falha. Por exemplo, a criação de cluster com falha ou submitRun seguido em pouco tempo por startWarehouse, ou por um novo job em uma computação diferente, pode indicar um invasor contornando um caminho bloqueado. Os códigos de resposta e o curto intervalo entre os eventos são o que separa essa sequência de erros rotineiros. A computação serverless é uma alternativa comum.

5. O invasor estabelece persistência

Com uma forma de executar código, os invasores tentam garantir que possam retornar após a revogação da credencial original. Os métodos comuns de persistência incluem concessões de acesso, tokens recém-criados, alterações de associação a grupos e workspaces, e edições no plano de controle. O sinal mais útil é uma alteração confidenciavel feita por uma identidade ou contexto de execução desconhecido. Por exemplo, uma alteração de permissão feita de dentro de um job merece mais escrutínio do que a mesma alteração feita por um administrador no console. Em seguida no cenário, o service principal se adiciona a um grupo de administradores. Mesmo que o token do engenheiro seja revogado, essa associação ao grupo mantém o acesso do invasor.

Objetivo do invasor: Criar caminhos de acesso duráveis e independentes que sobrevivam à revogação da credencial comprometida.

O que procurar:

• Configure alertas para concessões de permissão e identidade de contextos inesperados, como putAcl em um escopo de segredo, updatePermissionAssignment, addPrincipalToGroup ou setAdmin. Preste atenção especial quando um service principal concede acesso a outra identidade, ou quando várias atribuições ocorrem em um curto período.
• Trate as tentativas de alterar os controles de segurança como de alta severidade, mesmo quando falharem. Isso inclui setSetting / deleteSetting, edições de lista de acesso de IP e createPrivateAccessSettings. Revise a alteração solicitada, a resposta e a origem antes de concluir se um controle foi de fato ignorado. Revise também as alterações de grupo SCIM provenientes de qualquer outra fonte que não seja o IdP esperado.
• Sinalize chamadas generateDbToken de uma origem desconhecida ou durante a execução de um job. Cada token resultante é uma credencial separada que precisará ser revogada.
• Fique atento a cargas de trabalho que continuam por conta própria. Correlacione eventos do plano de controle com run_by, run_as e a janela de execução esperada. Se um job continuar modificando grupos, permissões ou configurações após o término da atividade interativa do invasor, ele poderá estar mantendo o acesso por conta própria. Preserve a definição do job e os artefatos antes de encerrá-lo.

6. O invasor coleta dados e limpa os rastros de acesso

A coleta de dados pode ser tão pequena quanto algumas exportações direcionadas, e a limpeza pode envolver mais do que apenas excluir arquivos. Fique atento a exportações direcionadas, solicitações de credenciais temporárias, remoção de ferramentas de curta duração e comandos ofuscados que tornam a atividade mais difícil de ser reconstruída. Qualquer um desses eventos pode parecer rotineiro, portanto, a sequência ao redor deles importa mais do que a exportação ou exclusão individual. Por fim, o service principal do nosso cenário exporta alguns scripts de inicialização. Sozinho, isso é uma exportação pequena. No entanto, como ela ocorre após uma leitura de segredo e uma nova função do mesmo service principal, ela deve ser investigada como parte da mesma intrusão.

Objetivo do invasor: Pegar os dados importantes e apagar as ferramentas mais óbvias, mantendo um acesso mais silencioso.

O que procurar:

• Analise o contexto de cada exportação em vez do número de exportações. workspaceExport registra o caminho, o formato e se foi um download direto. Priorize exportações feitas por identidades desconhecidas, para caminhos ou formatos incomuns, de redes nunca vistas antes, ou que ocorram após acesso a segredos ou nova execução. Uma exportação pequena e direcionada de scripts de inicialização pode vazar mais do que um dump em massa de SOURCE.
• Mantenha registros de objetos de curta duração. Um createFunction seguido por deleteFunction para a mesma função em uma sessão, ou um ciclo repetido de criação, exclusão e recriação, pode indicar uma tentativa de remover evidências. Preserve as definições e o tempo antes de reverter qualquer coisa. Objetos que sobrevivem geralmente recebem nomes mais plausíveis do que aqueles que foram excluídos.
• Conecte picos de credenciais temporárias e leitura de dados (generateTemporaryTableCredential, generateTemporaryVolumeCredential, Delta Sharing, leituras de armazenamento em nuvem) a um reconhecimento anterior. Comandos codificados ou em script são comuns demais para gerar alertas por si só, então correlação-os com um agente de usuário desconhecido, comportamento semelhante a automação, acesso a segredos ou novas funções.

Investigando ataques baseados em credenciais com o Genie

Usando a cadeia de ataques baseados em credenciais como guia, você pode direcionar o Genie para percorrer os estágios do ataque sem precisar escrever cada consulta do zero. Cada detecção nesta postagem é executada em telemetria que você já possui. O Databricks grava a atividade do plano de controle na tabela de sistema system.access.audit.

Para começar, instale o Detection App, que adiciona um agente do Genie para o registro de auditoria do Databricks. Você pode usá-lo a partir do Genie One de duas maneiras:

• Pergunte com suas próprias palavras, como "Quais notebooks o usuário@example.com exportou ontem?" O Genie escreve e executa o SQL para você.
• Use as detecções integradas. O agente do Detection App Genie inclui mais de 30 detecções, que vão desde uso indevido de tokens até concessões de administrador. Pergunte "Quem criou tokens de acesso pessoal na semana passada?" e o Genie executa a detecção correspondente em vez de escrever um novo SQL. Dê a ele um objetivo, como "Fomos comprometidos nos últimos 90 dias?", e ele percorrerá as detecções, uma de cada vez.

Lembre-se de dois limites. Primeiro, um resultado vazio não significa que nada aconteceu. O evento pode estar fora da sua janela de tempo ou o registro de auditoria detalhado pode estar desativado. Segundo, os logs de auditoria registram que algo mudou e quem mudou, mas muitas vezes não os valores antigos ou novos.

Da detecção à resposta

Assim que uma busca revela uma identidade que não se encaixa no padrão normal, o foco muda para o acesso que o invasor ainda possui. Como os ataques baseados em credenciais não são lineares, o primeiro acesso que você encontra raramente é o único. No exemplo do engenheiro de dados, revogar o token do engenheiro deixaria a credencial da entidade de serviço, sua associação ao grupo de administradores e a função que ela criou. Uma resposta completa remove a credencial original, bem como todos os caminhos que o invasor criou posteriormente, incluindo concessões, tokens, funções e trabalhos que continuam sendo executados após a desativação do usuário.

Para uma suspeita de comprometimento de workspace, os responsáveis pela resposta devem:

1. Desativar a identidade. Desative o usuário no nível da conta, o que bloqueia todos os workspaces. Não há uma API para encerrar as sessões de navegador de um usuário, mas a desativação as bloqueia. Para uma entidade de serviço, exclua seus segredos do OAuth e desative-a com a API SCIM da conta. Os tokens OAuth que a entidade de serviço já possui permanecem válidos por até uma hora.
2. Revogar seus tokens de acesso pessoal. A desativação de um usuário não exclui seus tokens, e os tokens voltam a funcionar se o usuário for reativado. Use a Token Management API ou o relatório de tokens no console da conta.
3. Salve o que precisar e, em seguida, pare a computação. Exporte primeiro as definições de jobs e as versões dos notebooks. Em seguida, ancele as execuções de jobs, encerre os clusters e pare os SQL warehouses. No serverless, cancele a execução ou instrução. Desativar um usuário não para a computação que já está em execução.
4. Gire todos os segredos que o ator leu. Altere-os na fonte e atualize o valor armazenado. Gire também a credencial que o invasor usou para entrar.
5. Desfazer a persistência criada pelo ator. Remova ACLs de escopo de segredo, atribuições de workspace e associações de grupo. Exclua as funções e revoque as concessões. Restaure suas políticas de entrada baseada em contexto (e listas de acesso IP, se ainda as usar) a partir de seus próprios registros.
6. Verifique o código que a identidade pôde alterar fora do Databricks, como scripts de inicialização e código ETL no armazenamento em nuvem.
7. Confirme se parou. Execute uma busca na atividade realizada pelo ator. Se o registro de auditoria detalhado estivesse desativado, ative-o. O texto do comando só é registrado enquanto estiver ativado.

Evitando ataques baseados em credenciais

Para voltar ao prédio comercial: a entrada baseada em contexto decide quem passa pelas portas giratórias, e o menor privilégio decide quais andares o crachá pode abrir. A detecção precoce compra tempo de resposta, mas os controles preventivos limitam o que uma credencial roubada pode fazer. Os controles abaixo são agrupados pelo que eles retiram do invasor, aproximadamente na ordem em que quebram a cadeia de ataques.

Mantenha as credenciais roubadas do lado de fora

O controle preventivo mais forte contra a reutilização de credenciais é o controle de entrada baseado em contexto. Ele avalia quem está fazendo uma solicitação, de onde ela vem e para que serve, em vez de depender de um único perímetro de rede. Isso é especialmente útil à medida que mais organizações se afastam das VPNs. Mesmo sem uma rede corporativa para se ancorar, você pode limitar um token roubado aos contextos que seu proprietário realmente usa. Por exemplo, você pode restringir uma entidade de serviço privilegiada a solicitações de API de redes confiáveis, aplicando uma política diferente aos usuários humanos.

• Aplique políticas a solicitações de workspace e de conta. As políticas de workspace não cobrem o console da conta ou as APIs em nível de conta.
• Comece no modo de simulação (dry-run). Revise as negações e violações de simulação em system.access.inbound_network, proteja primeiro as entidades de serviço privilegiadas e faça a aplicação real após contabilizar a automação legítima e as integrações de parceiros.
• Teste os fluxos de trabalho serverless e de conectividade privada antes da aplicação ampla, pois eles seguem regras de política separadas. Documente todas as exceções e monitore o uso delas.
• Trate as listas de acesso IP como uma camada adicional. Onde ambas se aplicam, uma solicitação deve passar por ambas. Configure as listas do workspace e do console da conta se ainda as utilizar.

Faça com que as credenciais coletadas valham menos

• Defina requisitos de expiração e rotação para credenciais de entidades de serviço, credenciais de integração e tokens de acesso pessoal, e desative credenciais que não são mais usadas. Credenciais dormentes são particularmente atraentes para invasores porque um comprometimento pode passar despercebido por meses.
• Aplique o menor privilégio nos escopos de segredos. Evite armazenar cópias de credenciais poderosas em escopos com ACLs diferentes e revise quem pode listar o conteúdo do escopo, bem como quem pode recuperar valores.

Limite o que uma credencial pode executar ou alterar

• Restrinja operações de alto impacto. Limite a criação de UDFs, alterações de ACL em escopos de segredo, alterações de permissão de workspace, administração de jobs e alterações de políticas de entrada a identidades aprovadas e automação controlada.
• Separe os caminhos administrativos dos caminhos de computação. Os tempos de execução de trabalhos comuns não devem conseguir modificar os controles de conta e de rede, e qualquer tentativa de fazer isso deve gerar um alerta.
• Proteja os ambientes de execução em nuvem. Use configurações de serviços de metadados protegidas quando aplicável e restrinja a saída de dados da computação para que as cargas de trabalho não possam acessar livremente endpoints de credenciais ou destinos não aprovados.
• Restrinja quais identidades podem gerenciar identidades de contas, atribuir acesso a workspaces e criar trabalhos.

Guarde as evidências

• Preserve telemetria pronta para investigação em caso de potenciais comprometimentos de segurança.
• Mantenha logs de auditoria, histórico de versões de notebooks e trabalhos, definições e dependências de UDF, histórico de alterações de permissões, eventos de gravação em armazenamento em nuvem e logs de negação de entrada baseada em contexto por tempo suficiente para reconstruir uma campanha.

Lembre-se de que o raio de alcance de uma credencial roubada é tão prejudicial quanto os privilégios atribuídos a ela. Reduza essa exposição e consiga buscar atividades anômalas seguindo estas etapas:

• Consulte as melhores práticas de segurança do Databricks para proteger seus workspaces e sua conta.
• Ative o registro de auditoria detalhado e configure o controle de entrada baseado em contexto para cobrir ambos os planos.
• Implante o Detection App para iniciar suas buscas e faça a sua primeira pergunta ao Genie: "Fomos comprometidos nos últimos 90 dias?"

(Esta publicação no blog foi traduzida utilizando ferramentas baseadas em inteligência artificial) Publicação original