Cybersecurity

O VaultJacking é uma técnica de phishing que visa o cofre do Google Password Manager ao capturar o PIN que o desbloqueia. Demonstrado pela PhishU em 20 de maio de 2026, o ataque mostra como um único segredo de seis dígitos, capturado durante uma sessão de phishing adversary-in-the-middle (AiTM), pode dar a um atacante acesso a todas as palavras-passe e passkeys sincronizadas que a vítima tem guardadas no Google Password Manager.

Para as empresas, o risco é maior do que parece. O cofre do navegador de um único colaborador pode conter credenciais de SSO, acesso a consolas cloud, inícios de sessão em plataformas financeiras e chaves de repositórios de código: tudo num só local e exposto por um único PIN capturado. É um risco organizacional que fica fora da maioria dos playbooks de resposta a incidentes existentes e fora da visibilidade da maioria das equipas de TI e de segurança.

Pontos principais

O VaultJacking é relevante porque os gestores de palavras-passe dos navegadores concentram palavras-passe, passkeys e fluxos de recuperação num único alvo de elevado valor. Antes de continuar a leitura, eis o que é necessário saber.

• O VaultJacking visa a camada de sincronização do cofre. O ataque não quebra a criptografia WebAuthn. Explora o fluxo de inscrição de dispositivos, que determina quem pode ler o cofre sincronizado.
• O PIN do Google Password Manager é um segredo de acesso ao cofre. A Google utiliza o PIN para proteger os dados de credenciais cifrados. Deve ser tratado como tal, e não como um código descartável.
• Um único PIN capturado pode expor todo o cofre. A demonstração da PhishU mostra que a introdução de um único PIN pode permitir a um atacante decifrar todas as palavras-passe e passkeys sincronizadas em infraestrutura controlada pelo operador.
• O risco empresarial aumenta com as lacunas de governação. A mistura de perfis pessoais e profissionais, os perfis do Chrome não geridos e as credenciais privilegiadas guardadas em cofres de navegador aumentam, todos, o raio de impacto.
• A resposta a incidentes tem de ir além da reposição da palavra-passe. Um evento de VaultJacking suspeito exige a revisão de dispositivos, sessões, passkeys, conteúdo do cofre e inícios de sessão em serviços associados, e não apenas a alteração de uma palavra-passe.

O que é o VaultJacking?

O VaultJacking é uma técnica de phishing que visa o acesso ao cofre do Google Password Manager e a respetiva experiência de recuperação. Em vez de roubar a credencial de um único site, o atacante captura o PIN do Google Password Manager durante uma sessão de phishing AiTM e utiliza-o para inscrever um dispositivo sob o seu controlo no domínio de segurança Google da vítima, o que lhe dá acesso a todo o cofre de credenciais sincronizado. O termo e a demonstração de ponta a ponta têm origem na investigação publicada pela PhishU.

O phishing de credenciais tradicional visa uma conta de cada vez. O VaultJacking é uma classe de ataque diferente: o atacante ignora por completo as credenciais individuais e vai diretamente ao repositório que as contém a todas.

A investigação da PhishU descreve o ataque como totalmente coerente com o phishing AiTM habitual. O proxy AiTM captura o PIN juntamente com os cookies de sessão. Um processo em segundo plano adiciona depois uma passkey controlada pelo atacante à conta Google da vítima, para persistência, associa-se ao domínio de segurança a partir da infraestrutura do atacante com o PIN capturado e decifra todo o cofre. O operador vê todas as credenciais sincronizadas numa única vista.

Browser Syncjacking, uma técnica distinta referida pela PhishU, chega à mesma camada de sincronização da Google através de uma extensão maliciosa do navegador. O VaultJacking não requer um ponto de apoio no dispositivo nem uma extensão.

O que é o PIN do Google Password Manager?

O PIN do Google Password Manager é um segredo distinto da palavra-passe da conta Google e do bloqueio de ecrã do dispositivo. A documentação da Google descreve-o como uma forma de proteger os dados cifrados do Google Password Manager, utilizar passkeys num novo dispositivo e verificar a identidade.

Os utilizadores confundem com frequência três segredos diferentes, e essa confusão contribui para a eficácia do VaultJacking:

O pedido do PIN do Google Password Manager surge ao criar a primeira passkey num novo dispositivo, ao aceder a credenciais guardadas e cifradas em determinados contextos de recuperação ou quando um novo dispositivo se associa ao domínio de segurança Google. Este último cenário é precisamente o que o VaultJacking explora.

A razão estrutural para este funcionamento, de acordo com a análise da PhishU ao código-fonte do Chromium (chrome/browser/webauthn/enclave_manager.cc e components/trusted_vault/), é que o fluxo de associação ao domínio de segurança da Google exige duas verificações: um início de sessão na conta Google e a introdução correta do PIN. Não existe pedido de aprovação entre dispositivos, notificação push para os dispositivos existentes nem confirmação do tipo «aprovar a partir de outro dispositivo».

O iCloud Keychain da Apple exige que os dispositivos existentes aprovem os novos. O modelo da Google não o faz. A Google fez uma escolha deliberada de experiência de utilização: um PIN com limite de tentativas no servidor é mais fácil de recuperar do que um modelo de aprovação por notificação push quando o utilizador perdeu todos os seus dispositivos. O VaultJacking é a consequência dessa escolha.

Como funciona a cadeia de ataque do VaultJacking

A descrição seguinte apresenta o ataque de forma concetual, para fins defensivos. Não são incluídos detalhes de implementação ofensiva.

1. Isca. A vítima recebe uma ligação de phishing e chega a uma página que imita um início de sessão ou um fluxo de conta legítimo da Google. Qualquer fluxo de início de sessão inesperado recebido por e-mail, chat ou anúncio deve ser encarado com desconfiança.
2. Transferência de confiança. O proxy AiTM apresenta um pedido de PIN com o aspeto da interface da própria Google: o mesmo tipo de letra, o mesmo campo de seis células, o mesmo texto. A formação dos utilizadores deve abranger os pedidos de PIN do gestor de palavras-passe, e não apenas as palavras-passe e os códigos OTP.
3. Captura do PIN. A vítima introduz o PIN no fluxo de phishing. O PIN é um segredo de acesso ao cofre, com sensibilidade equivalente à de uma palavra-passe mestra.
4. Inscrição do dispositivo do atacante. O atacante utiliza o PIN capturado para se associar ao domínio de segurança Google da vítima a partir de infraestrutura sob o seu controlo. É também registada uma passkey do atacante para persistência. Após qualquer suspeita de contacto com phishing, devem ser revistos de imediato os dispositivos com sessão iniciada e as passkeys registadas.
5. Decifragem do cofre. O Security Domain Secret é libertado pelo autenticador na cloud da Google e o dispositivo do atacante decifra todas as palavras-passe e passkeys sincronizadas. O cofre pode conter credenciais de e-mail, SSO, consolas cloud, plataformas financeiras e repositórios de código.
6. Comprometimento de outros serviços. As credenciais de terceiros guardadas são utilizadas contra outros serviços. Deve proceder-se à rotação das credenciais de elevado valor e monitorizar os inícios de sessão em serviços de terceiros.

A PhishU testou o processo de ponta a ponta em contas reais do Google Password Manager, incluindo a reprodução de passkeys de terceiros capturadas, independentemente de a credencial original ser baseada em hardware. Esta deve ser tratada como uma técnica demonstrada. Não existem provas públicas de exploração ativa generalizada à data da redação, mas a técnica não requer acesso especializado nem um ponto de apoio no dispositivo.

O VaultJacking significa que as passkeys foram quebradas?

Não. O VaultJacking não quebra a criptografia das passkeys. As passkeys baseiam-se em autenticação de chave pública vinculada à origem, tal como definida na especificação W3C WebAuthn: a chave privada nunca sai do dispositivo e a cerimónia de autenticação está vinculada à origem do site legítimo. Uma página de phishing não consegue reproduzir uma asserção WebAuthn no site real, porque a verificação da origem falha. Essa proteção mantém-se.

O que o VaultJacking demonstra é que as passkeys não existem isoladas. Existem dentro de um cofre, que se sincroniza entre dispositivos, que depende de um mecanismo de recuperação, que é governado por um PIN. O atacante contorna por completo a cerimónia criptográfica ao visar, em vez disso, a camada de gestão do cofre.

A Google descreve as passkeys como uma forma de iniciar sessão com uma impressão digital, uma leitura facial ou o bloqueio de ecrã, de forma mais simples e segura do que com palavras-passe. Essa descrição é rigorosa na camada de autenticação por site. O problema que o VaultJacking revela situa-se um nível acima: o que governa o acesso ao repositório que guarda essas passkeys.

Porque é que um só PIN pode ter um grande raio de impacto

Um cofre de palavras-passe é um repositório concentrado de acessos. Um único PIN capturado expõe todas as credenciais que a vítima alguma vez guardou no Google Password Manager.

O Identity Threat Landscape Report de 2025 da Recorded Future concluiu que o dispositivo comprometido médio forneceu 87 credenciais roubadas e que 276 milhões das credenciais indexadas em 2025 incluíam cookies de sessão ativos, o que significa que os atacantes podiam contornar a MFA por completo nessas contas.

O DBIR 2026 da Verizon contextualiza o efeito em cadeia: o abuso de credenciais surge, em algum momento, em 39 % de todas as violações confirmadas, em mais de 22 000 incidentes em 145 países. Raramente os atacantes ficam pela primeira porta que uma credencial roubada abre. Movem-se lateralmente, escalam privilégios e percorrem todos os inícios de sessão guardados até encontrarem algo valioso.

Quem está mais em risco?

O risco concentra-se onde se sobrepõem três condições: os dados do cofre do navegador são o principal repositório de credenciais, as credenciais profissionais e pessoais partilham um perfil e as credenciais privilegiadas foram parar a um sistema de nível consumidor.

1. O problema da mistura de credenciais. Os colaboradores guardam credenciais profissionais em perfis pessoais do Chrome. Os administradores não têm visibilidade nem controlo sobre o conteúdo do cofre nem sobre os dispositivos sincronizados. Isto significa que as palavras-passe da empresa ficam fora do perímetro de segurança, com cópia de segurança nos servidores da Google e acessíveis a partir de qualquer dispositivo em que o colaborador alguma vez tenha iniciado sessão.
2. Os utilizadores privilegiados são o alvo de maior valor. As palavras-passe de administrador guardadas no Google Password Manager representam a concentração de risco mais perigosa. O comprometimento de um só cofre expõe as chaves de plataformas de identidade, infraestrutura cloud, sistemas financeiros e ferramentas de segurança. Uma única conta de administrador comprometida torna-se um ponto de pivô para o movimento lateral em toda a organização.
3. A formação em segurança não abrange esta superfície de ataque. Os programas de sensibilização para a segurança ensinam os utilizadores a reconhecer e-mails de phishing e a proteger códigos OTP. Não os ensinam a reconhecer os pedidos de PIN do gestor de palavras-passe como alvos sensíveis. Os utilizadores veem um pedido de PIN e cumprem: não o encaram como um evento de segurança que deveria suscitar desconfiança.
4. As lacunas de política deixam as credenciais no sítio errado. A maioria das organizações não tem uma política que separe os cofres dos navegadores da gestão de credenciais empresariais. As credenciais partilhadas, as palavras-passe de administrador e as contas break-glass podem ficar guardadas onde for mais conveniente para os colaboradores. Não existe registo de auditoria que mostre onde estas credenciais se encontram ou quem lhes acedeu.
5. Os processos de revisão de dispositivos e sessões são demasiado lentos. Uma inscrição de dispositivo ou um acesso ao cofre suspeitos podem passar despercebidos durante semanas.

O último ponto é mais importante do que parece. A PhishU refere que a Google envia um único e-mail de «novo início de sessão no Windows» quando um novo dispositivo se associa ao domínio de segurança, o mesmo aviso enviado para qualquer novo início de sessão no Chrome. Não é enviada nenhuma notificação push para os dispositivos existentes. Numa operação AiTM em que o atacante capturou também a sessão de e-mail da vítima, esse e-mail pode ser suprimido antes de o utilizador o ver.

O que fazer se o PIN do Google Password Manager tiver sido alvo de phishing

Um evento de VaultJacking suspeito não deve ser tratado como um incidente de uma única palavra-passe. Deve ser tratado como possível exposição do cofre até prova em contrário.

A sequência de triagem seguinte destina-se a equipas de segurança e a particulares. Os nomes de eventos do Google Workspace devem ser verificados na documentação atual do Google Admin antes de criar deteção automatizada.

Os passos 5 e 7 são aqueles em que a maioria das respostas a incidentes falha. Alterar a palavra-passe da conta Google sem efetuar a rotação das credenciais subsequentes que esta protege é como trocar a fechadura de um cofre-forte depois de o conteúdo já ter sido fotografado.

O Passwork oferece visibilidade sobre todas as credenciais, sobre quem lhes acedeu e quando. O acesso baseado em funções mantém as credenciais partilhadas num único local, com um registo de auditoria completo, em vez de dispersas por perfis pessoais de navegador. Descobrir como funciona

Travar a violação: Resposta técnica passo a passo

Quando se suspeita de um evento de VaultJacking, os primeiros 60 minutos determinam até onde se propaga o dano. Estes passos destinam-se a engenheiros de segurança e administradores de TI. Devem ser executados por ordem, pois os passos posteriores dependem das provas preservadas nos anteriores.

1. Forçar o fim de todas as sessões ativas. Aceda a myaccount.google.com/security → «Manage all devices» (gerir todos os dispositivos) → revogue todas as sessões que não consiga confirmar fisicamente. Não delegue esta tarefa no utilizador afetado: faça-o a partir de uma consola de administração, sempre que possível. A revogação de sessões corta o acesso a um atacante que tem acesso ao cofre mas ainda não terminou de extrair as credenciais.
2. Auditar as passkeys registadas antes de revogar mais nada. Aceda a myaccount.google.com/security → «Passkeys and security keys» (passkeys e chaves de segurança). Faça primeiro uma captura de ecrã da lista completa e revogue depois todas as entradas que o utilizador não consiga identificar pelo nome do dispositivo e pela data de registo. Uma passkey registada pelo atacante sobrevive à reposição da palavra-passe e restabelece a persistência. A investigação da PhishU confirma que o processo em segundo plano regista uma passkey do operador como parte do fluxo normal do VaultJacking: a persistência está incorporada por conceção.
3. Extrair o registo de auditoria do Google Workspace. Em admin.google.com → Reports (Relatórios) → Audit (Auditoria) → Login, filtre pela conta do utilizador afetado na janela de 24 horas em torno do evento de phishing reportado. Procure qualquer evento login_type combinado com um IP de origem fora dos intervalos conhecidos da organização. Uma nova inscrição de dispositivo a partir de um IP não reconhecido, poucos minutos após o clique no phishing, é um forte indicador de comprometimento do cofre. Antes de criar consultas automatizadas, verifique os nomes atuais dos campos de eventos do Google Workspace na documentação do Google Admin SDK.
4. Configurar um alerta SIEM para deteção futura. Crie uma regra de correlação de alta prioridade: novo evento de inscrição de dispositivo numa conta Google + IP de origem fora da lista de permissões de IP da empresa + intervalo inferior a 10 minutos desde um clique conhecido em phishing. A maioria das organizações não tem atualmente qualquer deteção para eventos ao nível do cofre: esta regra colmata essa lacuna. O formato de boletins de ameaças da F5 Labs recomenda criar regras de deteção SIEM associadas a indicadores comportamentais específicos, em vez de depender apenas de notificações por e-mail.
5. Efetuar a rotação das credenciais por rigorosa ordem de prioridade. Não faça a rotação em bloco sem registar cada ação: o registo de auditoria é necessário para o relatório do incidente e para as decisões de notificação subsequentes.
   1. Contas de SSO e de fornecedores de identidade
   2. Credenciais de raiz e de administrador das consolas cloud
   3. Tokens de repositórios de código e segredos de pipelines de CI/CD
   4. Credenciais das plataformas financeiras e de processamento salarial
   5. Credenciais de VPN e de acesso remoto
   6. Quaisquer contas break-glass ou contas de serviço partilhadas guardadas no cofre
6. Verificar os serviços de terceiros subsequentes. Reveja os eventos de início de sessão da conta afetada em todos os serviços de terceiros durante as 48 horas seguintes ao evento de phishing. Os atacantes testam normalmente as credenciais guardadas nas horas seguintes ao acesso ao cofre. O DBIR 2026 da Verizon concluiu que o abuso de credenciais surge em 39 % das violações confirmadas: o movimento lateral através de inícios de sessão guardados é o passo seguinte esperado, e não um caso extremo.
7. Passo 7. Preservar as provas forenses antes da remediação completa. Faça capturas de ecrã da lista de dispositivos, exporte o registo de auditoria, registe o URL e a hora do phishing e documente quais as credenciais que estavam no cofre no momento do evento. A revogação destrói a persistência do atacante, mas também destrói algumas provas. Primeiro preservar, depois remediar.

O Passwork oferece à equipa de segurança um registo de auditoria completo de cada evento de acesso a credenciais: quem abriu o quê, quando e a partir de que dispositivo. Quando ocorre um incidente, a cadeia de provas está pronta. Ver como funciona

Como os particulares podem reduzir o risco de VaultJacking

O conselho prático é breve. Resume-se, na sua maior parte, a tratar o PIN do Google Password Manager como se trataria uma palavra-passe mestra, porque, funcionalmente, é uma.

• Não introduza o PIN do Google Password Manager em nenhuma página a que tenha chegado através de uma ligação num e-mail, chat ou anúncio. Aceda diretamente às definições da conta Google através da introdução de myaccount.google.com na barra de endereços.
• Reveja periodicamente os dispositivos com sessão iniciada e as passkeys registadas em myaccount.google.com. Um dispositivo desconhecido ou uma passkey que não reconheça merece ser investigado, e não ignorado. A investigação da PhishU mostra que as passkeys registadas pelo atacante são adicionadas em silêncio, sem notificação para os dispositivos existentes nem pedido push.
• Mantenha separados os perfis de navegador pessoais e profissionais. Se um perfil pessoal for comprometido, as credenciais profissionais não devem estar dentro do raio de impacto. O Secure Sign-in Trends Report de 2025 da Okta concluiu que a adoção de autenticadores resistentes a phishing passou de 8,6 % para 14,0 % num ano, mas a adoção na camada de autenticação não protege um cofre governado por um PIN.
• Evite guardar credenciais de administrador ou privilegiadas muito sensíveis num cofre de navegador de consumo. Essas credenciais exigem capacidade de auditoria e controlos de acesso que os cofres de navegador não oferecem. Continue a utilizar passkeys: continuam a ser mais seguras do que as palavras-passe reutilizáveis na camada de cada site. O problema não são as passkeys. O problema é o que governa o repositório que as guarda.

Evitar o próximo ataque: Lista de verificação de política e governação

O Secure Sign-in Trends Report de 2025 da Okta concluiu que a adoção de autenticadores resistentes a phishing passou de 8,6 % para 14,0 % dos utilizadores num ano, um aumento de 63 %. Esse crescimento é um progresso real. A lacuna de governação é que as organizações estão a adotar passkeys mais depressa do que estão a criar políticas para gerir os cofres que as guardam.

Os passos seguintes são proporcionais à sensibilidade das credenciais envolvidas. Nem todas as organizações precisam de todos os controlos. Todas as organizações que guardam credenciais privilegiadas em cofres de navegador precisam de uma política que aborde especificamente essa situação.

1. Auditar as credenciais privilegiadas que se encontram atualmente em cofres de navegador. Utilize o MDM ou as ferramentas de endpoint para identificar o estado de sincronização dos perfis do Chrome em todos os dispositivos geridos. Se não for possível responder à pergunta «que contas de administrador estão sincronizadas com perfis Google pessoais», essa é a primeira lacuna a colmatar, antes de redigir qualquer política.
2. Redigir uma política que nomeie categorias de credenciais específicas. Proíba o armazenamento de contas break-glass, credenciais de administrador, contas de serviço partilhadas, credenciais de raiz cloud e segredos de CI/CD em qualquer cofre de navegador de consumo. Uma política que refere «dados sensíveis» sem nomear categorias produz uma conformidade inconsistente. Nomeie as categorias. Defina uma data de aplicação.
3. Migrar as credenciais abrangidas antes da data de aplicação. Uma política sem um caminho de migração produz repositórios de credenciais paralelos. Transfira todas as credenciais abrangidas pelo Passo 2 para um gestor de palavras-passe empresarial com controlo de acesso baseado em funções e registo de auditoria completo antes de a política entrar em vigor. O Passwork permite a implementação autoalojada com cifragem AES-256, integração AD/LDAP e registo de auditoria completo, e foi concebido especificamente para esta separação entre credenciais corporativas privilegiadas e a comodidade do navegador pessoal.
4. Impor perfis de navegador geridos e separados para utilização profissional. Evite a mistura de cofres pessoais e profissionais através de políticas MDM e da formação dos utilizadores. Quando um perfil pessoal é comprometido, as credenciais profissionais não devem ficar abrangidas. Trata-se de uma alteração de configuração, e não apenas de uma recomendação.
5. Atualizar a formação de sensibilização para o phishing de modo a incluir os pedidos do cofre. Os programas de sensibilização para a segurança ensinam os utilizadores a reconhecer e-mails de phishing e a proteger códigos OTP. Não ensinam que um pedido de PIN do gestor de palavras-passe acarreta o mesmo risco que uma palavra-passe mestra. Inclua explicitamente no programa de formação os pedidos do cofre, os fluxos de recuperação e os pedidos de PIN. Os utilizadores que compreendem o que o PIN desbloqueia são significativamente mais difíceis de atacar com VaultJacking.
6. Incluir um runbook de exposição do cofre no plano de resposta a incidentes. O runbook deve abranger: revogação de sessões, auditoria da inscrição de dispositivos, revisão de passkeys, rotação de credenciais subsequentes e monitorização de contas de terceiros, como uma única resposta coordenada. Percorra a deteção, a contenção e a rotação. Identifique os passos que a equipa não consegue executar atualmente.
7. Configurar a deteção de novas inscrições de dispositivos em contas privilegiadas. Configure o CASB ou a plataforma de identidade para alertar sobre novas inscrições de dispositivos na conta Google a partir de dispositivos não geridos ou não reconhecidos, para todos os utilizadores com acesso privilegiado.
8. Rever trimestralmente a governação dos perfis de navegador. Os colaboradores mudam de funções, dispositivos e hábitos de credenciais mais depressa do que as revisões anuais conseguem captar. Uma verificação trimestral dos dispositivos geridos com a sincronização do Chrome ativada e do tipo de perfil ativo custa menos do que uma resposta a um incidente de exposição de cofre.

Porque um gestor de palavras-passe empresarial é mais seguro do que um cofre de navegador

Um gestor de palavras-passe de navegador resolve um problema de comodidade pessoal: preenchimento automático, sincronização entre dispositivos, armazenamento sem esforço. Para um utilizador individual, é uma escolha razoável. Num ambiente empresarial, essa mesma simplicidade converte-se numa vulnerabilidade estrutural.

O Passwork é a alternativa empresarial aos cofres de navegador pessoais. A extensão de navegador do Passwork funciona exatamente como um gestor de palavras-passe integrado no navegador: preenche automaticamente os inícios de sessão nos sites e propõe guardar novas credenciais, mas guarda-as num cofre corporativo protegido, em vez de num perfil de navegador pessoal.

O Passwork permite a implementação autoalojada, a cifragem AES-256, a integração com Active Directory e LDAP, a autorização SSO, o controlo de acesso baseado em funções, o registo de auditoria completo, a integração com SIEM e ferramentas de REST API e CLI para fluxos de trabalho DevOps.

A diferença é de arquitetura. Um cofre de navegador privilegia a comodidade individual. Um gestor de palavras-passe empresarial privilegia o controlo e a visibilidade organizacionais. Quando as credenciais privilegiadas acabam num cofre de navegador, escolheu-se a ferramenta errada para a tarefa, não porque a ferramenta seja má, mas porque foi concebida para outro problema.

Conclusão: O que fazer em relação ao VaultJacking

A ameaça descrita pelo VaultJacking é específica: uma técnica de phishing que transforma um único PIN capturado em exposição de credenciais a todo o cofre. A resposta deve ser igualmente específica: não o pânico em relação às passkeys, nem a desvalorização do risco dos cofres de navegador, mas uma política lúcida que separe a comodidade das credenciais pessoais da governação das credenciais privilegiadas.

Comece pela auditoria. Descubra que credenciais privilegiadas se encontram atualmente em cofres de navegador. Que contas de administrador estão sincronizadas com dispositivos pessoais? Que credenciais break-glass estão guardadas no Google Password Manager? Essa resposta indicará quanto trabalho há a fazer.

A partir daí, o caminho é simples: proibir credenciais privilegiadas nos cofres de navegador, transferi-las para um gestor de palavras-passe empresarial com registos de auditoria e controlos de acesso e alargar a formação de sensibilização para a segurança aos pedidos do cofre e aos fluxos de recuperação.

O VaultJacking não é motivo para abandonar os gestores de palavras-passe dos navegadores. É motivo para os utilizar para aquilo para que foram concebidos, as credenciais pessoais, e para criar um sistema separado e auditável para tudo o resto.

O Passwork é um gestor empresarial autoalojado de palavras-passe e segredos, concebido para a governação de credenciais privilegiadas. Disponibiliza acesso baseado em funções, registos de auditoria completos e uma separação total em relação aos cofres de navegador de consumo. Ver como se integra na infraestrutura

Perguntas frequentes

O que é o VaultJacking?

O VaultJacking é uma técnica de phishing que visa o cofre do Google Password Manager ao capturar o PIN do Google Password Manager do utilizador durante uma sessão de phishing adversary-in-the-middle. O PIN capturado é utilizado para inscrever um dispositivo controlado pelo atacante no domínio de segurança Google da vítima, o que permite decifrar todas as palavras-passe e passkeys sincronizadas guardadas no cofre. A técnica foi demonstrada de ponta a ponta pela PhishU em maio de 2026.

O VaultJacking é uma vulnerabilidade da Google?

Com base nas notícias publicadas, o VaultJacking é uma técnica demonstrada de phishing e de abuso de fluxos de trabalho, e não uma vulnerabilidade classificada nos sistemas da Google. Explora a conceção do fluxo de inscrição de dispositivos da Google, nomeadamente a ausência de aprovação entre dispositivos para novas adesões ao domínio de segurança, opção que a Google tomou deliberadamente como compromisso de experiência de utilização para a recuperação em caso de perda de dispositivos. A questão de saber se a Google classifica isto como uma vulnerabilidade que exige correção é distinta e não obteve resposta pública à data da redação.

O VaultJacking quebra as passkeys?

Não. As passkeys baseiam-se em criptografia de chave pública vinculada à origem, tal como definida na especificação W3C WebAuthn. Uma página de phishing não consegue reproduzir uma asserção WebAuthn no site real, porque a vinculação à origem falha. O VaultJacking visa a camada de cofre e de recuperação que guarda as passkeys, e não a própria cerimónia criptográfica de autenticação. As passkeys continuam a ser resistentes a phishing na camada de início de sessão de cada site.

O que é o PIN do Google Password Manager?

O PIN do Google Password Manager é um segredo que protege os dados cifrados do Google Password Manager. De acordo com a documentação da Google, é criado quando o utilizador guarda a primeira passkey num computador, iPhone ou iPad e é utilizado para aceder a passkeys em novos dispositivos, verificar a identidade e garantir que nem a Google consegue ler o conteúdo cifrado do cofre. É distinto da palavra-passe da conta Google e do bloqueio de ecrã do dispositivo.

Um único PIN pode expor todas as palavras-passe guardadas?

A demonstração da PhishU mostra que um PIN de seis dígitos do Google Password Manager capturado pode permitir a um atacante decifrar todo o cofre sincronizado, todas as palavras-passe guardadas e todas as passkeys sincronizadas, a partir de infraestrutura controlada pelo atacante. O PIN liberta o Security Domain Secret, que decifra o cofre numa única operação. Se o PIN foi introduzido numa página a que não se acedeu diretamente, deve ser tratado como possível exposição total do cofre.

O que fazer se o PIN tiver sido introduzido numa página suspeita?

Reveja de imediato os dispositivos com sessão iniciada e as passkeys registadas em myaccount.google.com. Revogue quaisquer dispositivos ou sessões desconhecidos. Altere a palavra-passe da conta Google. Efetue a rotação das credenciais de elevado valor guardadas no cofre, com prioridade para SSO, e-mail, consolas cloud, plataformas financeiras e contas de administrador. Verifique nos serviços de terceiros se existe atividade de início de sessão invulgar. Se pertencer a uma organização, abra um processo de resposta a incidentes em vez de tratar a situação como um problema de uma única conta.

As empresas devem proibir o Google Password Manager?

Uma proibição generalizada não é a política adequada para a maioria das organizações. Uma abordagem baseada no risco funciona melhor: restringir o armazenamento de credenciais privilegiadas e partilhadas a um gestor de palavras-passe empresarial com controlos de auditoria, impor perfis de navegador geridos e separados para utilização profissional e alargar a formação de sensibilização para o phishing aos pedidos do gestor de palavras-passe e aos fluxos de recuperação. O Google Password Manager é adequado para credenciais pessoais; não foi concebido para contas break-glass nem para acesso de administrador partilhado.

As chaves de segurança de hardware são suficientes para travar este ataque?

As chaves de segurança de hardware reforçam a garantia do início de sessão na conta Google, mas não governam automaticamente a sincronização do cofre do navegador, os fluxos de recuperação nem as credenciais guardadas no cofre. O VaultJacking visa a camada de gestão do cofre, e não o passo de início de sessão na conta. Uma chave de hardware na conta Google reduz o risco de tomada de controlo da conta, mas não impede que um utilizador seja induzido a introduzir o PIN do Google Password Manager numa página de phishing.

Gestão de palavras-passe e acessos para PME: O KeePass é suficiente?

A utilizar o KeePass na equipa? Conheça os riscos ocultos do KeePass para PME em 2026: falhas de sincronização, lacunas de conformidade e quando migrar para um gestor de palavras-passe empresarial.

Passwork BlogAlex Muntyan

O Passwork é distinguido como Top Performer Spring 2026 na SourceForge

O Passwork foi distinguido pela SourceForge como Top Performer Spring 2026 e ficou no top 10 % de mais de 100 000 soluções. A distinção baseia-se exclusivamente em avaliações verificadas: 4,8 estrelas no total e 5,0 (pontuação máxima) em suporte.

Passwork BlogAlex Muntyan

Ciclo de vida da rotação de segredos: Da criação à revogação

A rotação de segredos falha quando é tratada como uma tarefa agendada e não como um ciclo de vida. Este guia abrange as sete fases, desde a criação e a atribuição de responsabilidade até à rotação segura, à revogação de emergência e às evidências de auditoria.

Passwork BlogAlex Muntyan

VaultJacking ist eine Phishing-Technik, die auf den Tresor des Google Passwortmanagers abzielt, indem sie die PIN abfängt, die ihn entsperrt. Am 20. Mai 2026 von PhishU demonstriert, zeigt der Angriff, wie ein einziges sechsstelliges Geheimnis — während einer Adversary-in-the-Middle-Phishing-Sitzung (AiTM) abgefangen — einem Angreifer Zugang zu jedem synchronisierten Passwort und Passkey verschaffen kann, den ein Opfer im Google Passwortmanager gespeichert hat.

Für Unternehmen ist das Risiko größer als es erscheint. Der Browser-Tresor eines einzelnen Mitarbeiters kann SSO-Anmeldedaten, Cloud-Konsolen-Zugang, Logins für Finanzplattformen und Code-Repository-Schlüssel enthalten: alles an einem Ort und durch eine einzige abgefangene PIN offengelegt. Dies ist ein organisatorisches Risiko, das außerhalb der meisten bestehenden Incident-Response-Playbooks liegt und außerhalb der Sichtbarkeit der meisten IT- und Sicherheitsteams.

Wichtigste Erkenntnisse

VaultJacking ist relevant, weil Browser-Passwortmanager Passwörter, Passkeys und Wiederherstellungsabläufe in einem einzigen hochwertigen Ziel konzentrieren. Bevor Sie weiterlesen, hier das Wichtigste:

• VaultJacking zielt auf die Tresor-Synchronisierungsebene. Der Angriff bricht nicht die WebAuthn-Kryptographie. Er missbraucht den Geräteregistrierungsablauf, der bestimmt, wer den synchronisierten Tresor lesen kann.
• Die Google-Passwortmanager-PIN ist ein Tresor-Zugangsgeheimnis. Google verwendet die PIN zum Schutz verschlüsselter Anmeldedaten. Behandeln Sie sie entsprechend — nicht als belanglosen Code.
• Eine abgefangene PIN kann den gesamten Tresor offenlegen. Die Demonstration von PhishU zeigt, dass eine einzige PIN-Eingabe einem Angreifer ermöglichen kann, jedes synchronisierte Passwort und jeden Passkey auf einer vom Angreifer kontrollierten Infrastruktur zu entschlüsseln.
• Das Unternehmensrisiko skaliert mit Governance-Lücken. Die Vermischung von persönlichen und beruflichen Profilen, nicht verwaltete Chrome-Profile und privilegierte Anmeldedaten in Browser-Tresoren erhöhen den Schadensradius.
• Die Incident Response muss über einen Passwortwechsel hinausgehen. Ein vermutetes VaultJacking-Ereignis erfordert die Überprüfung von Geräten, Sitzungen, Passkeys, Tresorinhalten und nachgelagerten Logins — nicht nur das Ändern eines Passworts.

Was ist VaultJacking?

VaultJacking ist eine Phishing-Technik, die auf den Tresor-Zugang und die Wiederherstellungserfahrung des Google Passwortmanagers abzielt. Anstatt eine einzelne Website-Anmeldung zu stehlen, fängt der Angreifer die Google-Passwortmanager-PIN während einer AiTM-Phishing-Sitzung ab und verwendet sie, um ein vom Angreifer kontrolliertes Gerät in die Google-Sicherheitsdomäne des Opfers einzuschreiben. Dadurch erhält er Zugang zum gesamten synchronisierten Anmeldedaten-Tresor. Der Begriff und die End-to-End-Demonstration stammen aus der veröffentlichten Forschung von PhishU.

Traditionelles Credential-Phishing zielt auf ein Konto nach dem anderen. VaultJacking ist eine andere Angriffsklasse: Der Angreifer umgeht einzelne Anmeldedaten vollständig und greift direkt auf das Repository zu, das alle enthält.

Die Forschung von PhishU beschreibt den Angriff als vollständig konsistent mit Standard-AiTM-Phishing. Der AiTM-Proxy fängt die PIN zusammen mit Session-Cookies ab. Ein Hintergrundprozess fügt dann einen Passkey des Angreifers zum Google-Konto des Opfers für Persistenz hinzu, tritt der Sicherheitsdomäne von der Angreifer-Infrastruktur aus mit der abgefangenen PIN bei und entschlüsselt den gesamten Tresor. Der Betreiber sieht alle synchronisierten Anmeldedaten in einer einzigen Ansicht.

Browser Syncjacking, eine separate Technik, auf die PhishU verweist, erreicht dieselbe Google-Sync-Ebene über eine bösartige Browser-Erweiterung. VaultJacking erfordert weder einen Geräte-Zugang noch eine Erweiterung.

Was ist die Google-Passwortmanager-PIN?

Die Google-Passwortmanager-PIN ist ein separates Geheimnis, das sich von Ihrem Google-Kontopasswort und Ihrer Geräte-Bildschirmsperre unterscheidet. Googles Dokumentation beschreibt sie als eine Möglichkeit, verschlüsselte Google-Passwortmanager-Daten zu schützen, Passkeys auf einem neuen Gerät zu verwenden und die Identität zu verifizieren.

Benutzer verwechseln häufig drei verschiedene Geheimnisse, und diese Verwirrung ist Teil dessen, was VaultJacking so effektiv macht:

Die Aufforderung zur Eingabe der Google-Passwortmanager-PIN erscheint beim Erstellen Ihres ersten Passkeys auf einem neuen Gerät, beim Zugriff auf verschlüsselte gespeicherte Anmeldedaten in bestimmten Wiederherstellungskontexten oder wenn ein neues Gerät Ihrer Google-Sicherheitsdomäne beitritt. Das letzte Szenario ist genau das, was VaultJacking ausnutzt.

Der strukturelle Grund, warum dies funktioniert, liegt laut der Analyse von PhishU des Chromium-Quellcodes (chrome/browser/webauthn/enclave_manager.cc und components/trusted_vault/) darin, dass Googles Sicherheitsdomänen-Beitrittsablauf zwei Prüfungen erfordert: eine Google-Kontoanmeldung und eine erfolgreiche PIN-Eingabe. Es gibt keine geräteübergreifende Genehmigungsaufforderung, keine Push-Benachrichtigung an bestehende Geräte, keine „Von einem anderen Gerät genehmigen"-Bestätigung.

Apples iCloud-Schlüsselbund erfordert, dass bestehende Geräte neue genehmigen. Googles Modell nicht. Google hat einen bewussten UX-Kompromiss getroffen: Eine PIN mit einem serverseitigen Wiederholungslimit ist einfacher zu handhaben als ein Push-to-Approve-Modell, wenn ein Benutzer alle seine Geräte verloren hat. VaultJacking ist die Konsequenz dieses Kompromisses.

Wie die VaultJacking-Angriffskette funktioniert

Das Folgende beschreibt den Angriff konzeptionell für Verteidigungszwecke. Es sind keine offensiven Implementierungsdetails enthalten.

1. Köder. Das Opfer erhält einen Phishing-Link und landet auf einer Seite, die einen legitimen Google-Anmelde- oder Kontoablauf imitiert. Behandeln Sie jeden unerwarteten Anmeldeablauf, der per E-Mail, Chat oder Werbelink ankommt, mit Misstrauen.
2. Vertrauenstransfer. Der AiTM-Proxy rendert eine PIN-Aufforderung, die dem Stil von Googles eigener Oberfläche entspricht: gleiche Schriftart, gleiche sechs-Zellen-Eingabe, gleicher Text. Die Benutzerschulung muss Passwortmanager-PIN-Aufforderungen abdecken, nicht nur Passwörter und OTP-Codes.
3. PIN-Abfang. Das Opfer gibt die PIN in den Phishing-Ablauf ein. Die PIN ist ein Tresor-Zugangsgeheimnis, das in seiner Sensibilität einem Masterpasswort entspricht.
4. Angreifer-Geräteregistrierung. Der Angreifer verwendet die abgefangene PIN, um der Google-Sicherheitsdomäne des Opfers von einer vom Angreifer kontrollierten Infrastruktur aus beizutreten. Ein Passkey des Angreifers wird ebenfalls für Persistenz registriert. Überprüfen Sie angemeldete Geräte und registrierte Passkeys sofort nach jedem vermuteten Phishing-Kontakt.
5. Tresor-Entschlüsselung. Das Security Domain Secret wird von Googles Cloud-Authenticator freigegeben, und das Gerät des Angreifers entschlüsselt jedes synchronisierte Passwort und jeden Passkey. Der Tresor kann Anmeldedaten für E-Mail, SSO, Cloud-Konsolen, Finanzplattformen und Code-Repositories enthalten.
6. Nachgelagerte Kompromittierung. Gespeicherte Drittanbieter-Anmeldedaten werden gegen andere Dienste verwendet. Rotieren Sie hochwertige Anmeldedaten und überwachen Sie Drittanbieter-Logins.

PhishU hat dies End-to-End gegen Live-Google-Passwortmanager-Konten getestet, einschließlich der Wiedergabe von abgefangenen Drittanbieter-Passkeys, unabhängig davon, ob die ursprünglichen Anmeldedaten hardwaregestützt waren. Behandeln Sie dies als eine demonstrierte Technik. Es gibt zum Zeitpunkt des Schreibens keine öffentlichen Beweise für eine weit verbreitete aktive Ausnutzung, aber die Technik erfordert keinen spezialisierten Zugang oder Geräte-Zugriff.

Bedeutet VaultJacking, dass Passkeys unsicher sind?

Nein. VaultJacking bricht nicht die Passkey-Kryptographie. Passkeys basieren auf ursprungsgebundener Public-Key-Authentifizierung, wie in der W3C WebAuthn-Spezifikation definiert: Der private Schlüssel verlässt niemals das Gerät, und die Authentifizierungszeremonie ist an den legitimen Website-Ursprung gebunden. Eine Phishing-Seite kann eine WebAuthn-Assertion nicht gegen die echte Website wiedergeben, weil die Ursprungsprüfung fehlschlägt. Dieser Schutz bleibt bestehen.

Was VaultJacking demonstriert, ist, dass Passkeys nicht isoliert existieren. Sie existieren in einem Tresor, der über Geräte synchronisiert wird, der auf einem Wiederherstellungsmechanismus basiert, der durch eine PIN gesteuert wird. Der Angreifer umgeht die kryptographische Zeremonie vollständig, indem er stattdessen auf die Tresor-Verwaltungsebene abzielt.

Google beschreibt Passkeys als eine Möglichkeit, sich mit Fingerabdruck, Gesichtserkennung oder Bildschirmsperre anzumelden — einfacher und sicherer als Passwörter. Diese Beschreibung ist auf der Ebene der Einzelsite-Authentifizierung korrekt. Das Problem, das VaultJacking aufzeigt, liegt eine Ebene höher: Was steuert den Zugang zum Speicher, der diese Passkeys enthält.

Warum eine PIN einen großen Schadensradius erzeugen kann

Ein Passwortmanager-Tresor ist ein konzentrierter Speicher für Zugang. Eine abgefangene PIN legt alle Anmeldedaten offen, die das Opfer jemals im Google Passwortmanager gespeichert hat.

Der Identity Threat Landscape Report 2025 von Recorded Future stellte fest, dass das durchschnittliche kompromittierte Gerät 87 gestohlene Anmeldedaten ergab und dass 276 Millionen der 2025 indexierten Anmeldedaten aktive Session-Cookies enthielten — was bedeutet, dass Angreifer MFA für diese Konten vollständig umgehen konnten.

Verizons DBIR 2026 setzt die nachgelagerten Auswirkungen in einen Kontext: Der Missbrauch von Anmeldedaten erscheint irgendwann in 39 % aller bestätigten Sicherheitsverletzungen, über mehr als 22.000 Vorfälle in 145 Ländern hinweg. Angreifer bleiben selten bei der ersten Tür stehen, die gestohlene Anmeldedaten öffnen. Sie bewegen sich lateral, eskalieren Privilegien und arbeiten sich durch jeden gespeicherten Login, bis sie etwas Wertvolles finden.

Wer ist am stärksten gefährdet?

Das Risiko konzentriert sich dort, wo drei Bedingungen zusammentreffen: Browser-Tresor-Daten sind der primäre Anmeldedatenspeicher, Arbeits- und persönliche Anmeldedaten teilen ein Profil, und privilegierte Anmeldedaten sind in einem Consumer-System gelandet.

1. Das Problem der Vermischung von Anmeldedaten. Mitarbeiter speichern Arbeits-Anmeldedaten in persönlichen Chrome-Profilen. Administratoren haben keine Sichtbarkeit oder Kontrolle über Tresorinhalte oder synchronisierte Geräte. Dies bedeutet, dass Unternehmenspasswörter außerhalb des Sicherheitsperimeters leben, auf Googles Servern gesichert werden und von jedem Gerät aus zugänglich sind, bei dem sich der Mitarbeiter jemals angemeldet hat.
2. Privilegierte Benutzer sind das hochwertigste Ziel. Im Google Passwortmanager gespeicherte Admin-Passwörter stellen die gefährlichste Risikokonzentration dar. Eine Tresor-Kompromittierung legt die Schlüssel zu Identitätsplattformen, Cloud-Infrastruktur, Finanzsystemen und Sicherheits-Tools offen. Ein einziges kompromittiertes Admin-Konto wird zum Drehpunkt für laterale Bewegung in der gesamten Organisation.
3. Sicherheitstraining deckt diese Angriffsfläche nicht ab. Security-Awareness-Programme lehren Benutzer, Phishing-E-Mails zu erkennen und OTP-Codes zu schützen. Sie lehren Benutzer nicht, Passwortmanager-PIN-Aufforderungen als sensible Ziele zu erkennen. Benutzer sehen eine PIN-Anfrage und kommen ihr nach — sie sehen es nicht als ein Sicherheitsereignis, das Skepsis auslösen sollte.
4. Richtlinienlücken lassen Anmeldedaten am falschen Ort. Die meisten Organisationen haben keine Richtlinie, die Browser-Tresore von der Unternehmens-Anmeldedatenverwaltung trennt. Geteilte Anmeldedaten, Admin-Passwörter und Break-Glass-Konten werden möglicherweise dort gespeichert, wo es Mitarbeitern bequem erscheint. Es existiert kein Audit-Trail, der zeigt, wo diese Anmeldedaten liegen oder wer darauf zugegriffen hat.
5. Geräte- und Sitzungsüberprüfungsprozesse sind zu langsam. Verdächtige Geräteregistrierungen oder Tresorzugriffe können wochenlang unbemerkt bleiben.

Der letzte Punkt ist wichtiger, als es erscheinen mag. PhishU merkt an, dass Google eine einzige E-Mail „Neue Anmeldung unter Windows" sendet, wenn ein neues Gerät der Sicherheitsdomäne beitritt — dieselbe Benachrichtigung, die für jede neue Chrome-Anmeldung gesendet wird. Auf bestehenden Geräten wird keine Push-Benachrichtigung ausgelöst. In einem AiTM-Angriff, bei dem der Angreifer auch die Posteingangs-Sitzung des Opfers abgefangen hat, kann diese E-Mail unterdrückt werden, bevor der Benutzer sie sieht.

Was zu tun ist, wenn eine Google-Passwortmanager-PIN möglicherweise gephisht wurde

Behandeln Sie ein vermutetes VaultJacking-Ereignis nicht als Einzelpasswort-Vorfall. Behandeln Sie es als mögliche Tresor-Exposition, bis das Gegenteil bewiesen ist.

Die folgende Triage-Sequenz richtet sich an Sicherheitsteams und Einzelpersonen. Google-Workspace-Ereignisnamen sollten anhand der aktuellen Google-Admin-Dokumentation überprüft werden, bevor eine automatisierte Erkennung erstellt wird.

Die Schritte 5 und 7 sind dort, wo die meisten Incident Responses zu kurz greifen. Das Google-Kontopasswort zu rotieren, ohne die nachgelagerten Anmeldedaten zu rotieren, die es schützt, ist wie das Schloss an einem Safe zu wechseln, nachdem der Inhalt bereits fotografiert wurde.

Passwork gibt Ihnen Einblick in alle Anmeldedaten, wer darauf zugegriffen hat und wann. Rollenbasierter Zugriff bedeutet, dass geteilte Anmeldedaten an einem Ort mit vollständigem Audit-Trail bleiben — nicht über persönliche Browser-Profile verstreut. Erfahren Sie, wie es funktioniert

Wie Einzelpersonen das VaultJacking-Risiko reduzieren können

Der praktische Rat hier ist kurz. Das meiste läuft darauf hinaus, die Google-Passwortmanager-PIN genauso zu behandeln wie ein Masterpasswort.

• Geben Sie die Google-Passwortmanager-PIN nicht auf einer Seite ein, die Sie durch Klicken auf einen Link in einer E-Mail, einem Chat oder einer Werbung erreicht haben. Navigieren Sie direkt zu den Google-Kontoeinstellungen.
• Überprüfen Sie Ihre angemeldeten Geräte und registrierten Passkeys unter myaccount.google.com regelmäßig. Ein unbekanntes Gerät oder ein unbekannter Passkey ist eine Untersuchung wert.
• Halten Sie persönliche und berufliche Browser-Profile getrennt. Wenn ein persönliches Profil kompromittiert wird, sollten Arbeits-Anmeldedaten nicht im Schadensradius sein.
• Vermeiden Sie das Speichern hochsensibler Admin- oder privilegierter Anmeldedaten in einem Consumer-Browser-Tresor. Diese Anmeldedaten benötigen Auditierbarkeit und Zugriffskontrollen, die Browser-Tresore nicht bieten.
• Verwenden Sie weiterhin Passkeys. Sie bleiben auf der Einzelsite-Ebene sicherer als wiederverwendbare Passwörter. Verstehen Sie nur, welche Aufforderungen legitim sind und welche nicht.

Unternehmenskontrollen und Richtlinienempfehlungen

Oktas Secure Sign-in Trends Report 2025 stellte fest, dass die Einführung von phishing-resistenten Authentifikatoren in einem Jahr von 8,6 % auf 14,0 % der Benutzer wuchs — ein Anstieg von 63 %. Dieses Wachstum ist eine gute Nachricht. Das Governance-Problem ist, dass Organisationen Passkeys schneller einführen, als sie die Richtlinien zur Verwaltung der Tresore aufbauen, die sie speichern.

Die folgenden Kontrollen sind proportional zur Sensibilität der beteiligten Anmeldedaten. Nicht jede Organisation benötigt jede Kontrolle, aber jede Organisation, die privilegierte Anmeldedaten in Browser-Tresoren speichert, benötigt eine Richtlinie, die dies speziell adressiert.

• Browser-Profil-Governance. Erzwingen Sie separate verwaltete Arbeitsprofile. Entmutigen Sie die Vermischung von persönlichen und Arbeits-Tresoren durch Richtlinien und Benutzerschulung.
• Speicherung privilegierter Anmeldedaten. Verbieten Sie das Speichern von Admin-, Break-Glass-, Cloud-Root-, Finanz- und Service-Account-Anmeldedaten in nicht verwalteten Browser-Tresoren. Browser-Tresore sind bequem für die persönliche Nutzung. Sie sind nicht für geteilte Anmeldedaten, privilegierten Zugang oder Audit-Trails konzipiert.
• Enterprise-Passwort-Management. Verwenden Sie einen dedizierten Enterprise-Passwortmanager für geteilte, privilegierte und auditierte Anmeldedaten. Passwork ist eine selbst gehostete Lösung, die genau für diese Trennung entwickelt wurde: privilegierte Anmeldedaten in einem kontrollierten, auditierbaren Tresor mit rollenbasierter Zugriffskontrolle, AD/LDAP-Integration und vollständigem Audit-Log.
• Phishing-resistente MFA. Setzen Sie die Einführung von WebAuthn und FIDO2 fort. Erweitern Sie die Benutzerschulung auf Wiederherstellungsabläufe und Tresor-Aufforderungen, nicht nur auf Passwörter und OTP-Codes.
• Geräte- und Sitzungssichtbarkeit. Überwachen Sie auf unbekannte Geräteregistrierungen, ungewöhnliche Sitzungsaktivitäten und unerwartete Kontosicherheitsänderungen. Google sendet eine „Neue Anmeldung"-E-Mail für jede neue Chrome-Anmeldung. In einem AiTM-Angriff, bei dem der Angreifer auch die Posteingangs-Sitzung des Opfers abgefangen hat, kann diese E-Mail unterdrückt werden, bevor der Benutzer sie sieht.
• Incident Response. Erstellen Sie ein Tresor-Expositions-Runbook, das Anmeldedaten-Rotation, Sitzungswiderruf, Passkey-Überprüfung und Drittanbieter-Kontoüberwachung umfasst.
• Security Awareness. Schulen Sie Benutzer, dass PINs, Passwortmanager-Aufforderungen und Wiederherstellungsabläufe Phishing-Ziele sind. Sie tragen dasselbe Risiko wie Passwörter und OTP-Codes.

Der Punkt zum Enterprise-Passwortmanager verdient Betonung. Browser-Tresore sind bequem und verbessern die Passwort-Einzigartigkeit für viele Benutzer. Sie sind nicht für geteilte Anmeldedaten, privilegierten Zugang oder Audit-Trails konzipiert.

Warum ein Enterprise-Passwortmanager sicherer ist als ein Browser-Tresor für Arbeits-Anmeldedaten

Ein Browser-Passwortmanager löst ein persönliches Komfortproblem: Autofill, Gerätesynchronisation, mühelose Speicherung. Für einen einzelnen Benutzer ist das eine vernünftige Wahl. Für eine Unternehmensumgebung wird dieselbe Einfachheit zu einer strukturellen Schwachstelle.

Passwork ist die Enterprise-Alternative zu persönlichen Browser-Tresoren. Die Passwork-Browser-Erweiterung funktioniert genau wie ein integrierter Browser-Passwortmanager — sie füllt Logins auf Websites automatisch aus, bietet an, neue Anmeldedaten zu speichern — speichert sie aber in einem geschützten Unternehmens-Tresor anstatt in einem persönlichen Browser-Profil.

Passwork unterstützt selbst gehostete Bereitstellung, AES-256-Verschlüsselung, Active Directory- und LDAP-Integration, SSO-Autorisierung, rollenbasierte Zugriffskontrolle, vollständiges Audit-Logging, SIEM-Integration sowie REST API- und CLI-Tools für DevOps-Workflows.

Der Unterschied ist architektonisch. Ein Browser-Tresor priorisiert individuellen Komfort. Ein Enterprise-Passwortmanager priorisiert organisatorische Kontrolle und Sichtbarkeit. Wenn privilegierte Anmeldedaten in einem Browser-Tresor landen, wurde das falsche Werkzeug für die Aufgabe gewählt — nicht weil das Werkzeug schlecht ist, sondern weil es für ein anderes Problem konzipiert wurde.

Fazit: Was gegen VaultJacking zu tun ist

Die Bedrohung, die VaultJacking beschreibt, ist spezifisch: eine Phishing-Technik, die eine abgefangene PIN in tresorweite Anmeldedaten-Exposition verwandelt. Die Reaktion sollte ebenso spezifisch sein — keine Panik über Passkeys und keine Verharmlosung des Browser-Tresor-Risikos, sondern eine klare Richtlinie, die persönlichen Anmeldedaten-Komfort von privilegierter Anmeldedaten-Governance trennt.

Beginnen Sie mit dem Audit. Finden Sie heraus, welche privilegierten Anmeldedaten derzeit in Browser-Tresoren liegen. Welche Admin-Konten sind mit persönlichen Geräten synchronisiert? Welche Break-Glass-Anmeldedaten sind im Google Passwortmanager gespeichert? Diese Antwort wird Ihnen sagen, wie viel Arbeit noch zu tun ist.

Von dort aus ist der Weg klar: Verbieten Sie privilegierte Anmeldedaten in Browser-Tresoren, verschieben Sie sie in einen Enterprise-Passwortmanager mit Audit-Trails und Zugriffskontrollen, und erweitern Sie Ihr Security-Awareness-Training auf Tresor-Aufforderungen und Wiederherstellungsabläufe.

VaultJacking ist kein Grund, Browser-Passwortmanager aufzugeben. Es ist ein Grund, sie für das zu verwenden, wofür sie konzipiert wurden — persönliche Anmeldedaten — und ein separates, auditierbares System für alles andere aufzubauen.

Passwork ist ein selbst gehosteter Enterprise-Passwort- und Secrets-Manager, der für privilegierte Anmeldedaten-Governance entwickelt wurde. Er bietet rollenbasierten Zugriff, vollständige Audit-Logs und vollständige Trennung von Consumer-Browser-Tresoren. Erfahren Sie, wie er in Ihre Infrastruktur passt

Häufig gestellte Fragen

Was ist VaultJacking?

VaultJacking ist eine Phishing-Technik, die auf den Tresor des Google Passwortmanagers abzielt, indem sie die Google-Passwortmanager-PIN des Benutzers während einer Adversary-in-the-Middle-Phishing-Sitzung abfängt. Die abgefangene PIN wird verwendet, um ein vom Angreifer kontrolliertes Gerät in die Google-Sicherheitsdomäne des Opfers einzuschreiben, wodurch jedes synchronisierte Passwort und jeder Passkey im Tresor entschlüsselt wird. Die Technik wurde im Mai 2026 End-to-End von PhishU demonstriert.

Ist VaultJacking eine Google-Schwachstelle?

Basierend auf veröffentlichten Berichten ist VaultJacking eine demonstrierte Phishing- und Workflow-Missbrauchstechnik, keine klassifizierte Schwachstelle in Googles Systemen. Sie nutzt das Design von Googles Geräteregistrierungsablauf aus — insbesondere das Fehlen einer geräteübergreifenden Genehmigung für neue Sicherheitsdomänen-Beitritte — was Google bewusst als UX-Kompromiss für die Wiederherstellung bei verlorenem Gerät gewählt hat. Ob Google dies als Schwachstelle klassifiziert, die eine Behebung erfordert, ist eine separate Frage, die zum Zeitpunkt des Schreibens nicht öffentlich beantwortet wurde.

Bricht VaultJacking Passkeys?

Nein. Passkeys basieren auf ursprungsgebundener Public-Key-Kryptographie, wie in der W3C WebAuthn-Spezifikation definiert. Eine Phishing-Seite kann eine WebAuthn-Assertion nicht gegen die echte Website wiedergeben, weil die Ursprungsbindung fehlschlägt. VaultJacking zielt auf den Tresor und die Wiederherstellungsebene ab, die Passkeys speichert — nicht auf die kryptographische Authentifizierungszeremonie selbst. Passkeys bleiben auf der Einzelsite-Login-Ebene phishing-resistent.

Was ist die Google-Passwortmanager-PIN?

Die Google-Passwortmanager-PIN ist ein Geheimnis, das verschlüsselte Google-Passwortmanager-Daten schützt. Laut Googles Dokumentation wird sie erstellt, wenn ein Benutzer seinen ersten Passkey auf einem Computer, iPhone oder iPad speichert, und sie wird verwendet, um auf Passkeys auf neuen Geräten zuzugreifen, die Identität zu verifizieren und sicherzustellen, dass nicht einmal Google den verschlüsselten Tresorinhalt lesen kann. Sie unterscheidet sich vom Google-Kontopasswort und von der Geräte-Bildschirmsperre.

Kann eine PIN alle meine gespeicherten Passwörter offenlegen?

Die Demonstration von PhishU zeigt, dass eine abgefangene sechsstellige Google-Passwortmanager-PIN einem Angreifer ermöglichen kann, den gesamten synchronisierten Tresor zu entschlüsseln — jedes gespeicherte Passwort und jeden synchronisierten Passkey — von einer vom Angreifer kontrollierten Infrastruktur aus. Die PIN gibt das Security Domain Secret frei, das den Tresor in einer einzigen Operation entschlüsselt. Wenn Sie die PIN auf einer Seite eingegeben haben, zu der Sie nicht direkt navigiert sind, behandeln Sie dies als mögliche vollständige Tresor-Exposition.

Was sollte ich tun, wenn ich die PIN auf einer verdächtigen Seite eingegeben habe?

Überprüfen Sie sofort Ihre angemeldeten Geräte und registrierten Passkeys unter myaccount.google.com. Widerrufen Sie alle unbekannten Geräte oder Sitzungen. Ändern Sie Ihr Google-Kontopasswort. Rotieren Sie hochwertige Anmeldedaten, die im Tresor gespeichert sind — priorisieren Sie SSO, E-Mail, Cloud-Konsolen, Finanzplattformen und Admin-Konten. Überprüfen Sie Drittanbieterdienste auf ungewöhnliche Login-Aktivitäten. Wenn Sie in einer Organisation sind, eröffnen Sie einen Incident-Response-Fall, anstatt dies als Einzelkonto-Problem zu behandeln.

Sollten Unternehmen den Google Passwortmanager verbieten?

Ein pauschales Verbot ist für die meisten Organisationen nicht die richtige Richtlinie. Ein risikobasierter Ansatz funktioniert besser: Beschränken Sie die Speicherung privilegierter und geteilter Anmeldedaten auf einen Enterprise-Passwortmanager mit Audit-Kontrollen, erzwingen Sie separate verwaltete Browser-Profile für die Arbeit und erweitern Sie das Phishing-Awareness-Training auf Passwortmanager-Aufforderungen und Wiederherstellungsabläufe. Der Google Passwortmanager ist für persönliche Anmeldedaten geeignet; er ist nicht für Break-Glass-Konten oder geteilten Admin-Zugang konzipiert.

Reichen Hardware-Sicherheitsschlüssel aus, um dies zu stoppen?

Hardware-Sicherheitsschlüssel stärken die Sicherheitsgarantie bei der Google-Kontoanmeldung, aber sie steuern nicht automatisch die Browser-Tresor-Synchronisation, Wiederherstellungsabläufe oder die im Tresor gespeicherten Anmeldedaten. VaultJacking zielt auf die Tresor-Verwaltungsebene ab, nicht auf den Kontoanmeldeschritt. Ein Hardware-Schlüssel für das Google-Konto reduziert das Risiko einer Kontoübernahme, verhindert aber nicht, dass ein Benutzer dazu verleitet wird, seine Google-Passwortmanager-PIN auf einer Phishing-Seite einzugeben.

Passwort- und Zugangsverwaltung für KMUs: Reicht KeePass aus?

Verwenden Sie KeePass für Ihr Team? Entdecken Sie die versteckten Risiken von KeePass für KMUs im Jahr 2026 — Synchronisierungsfehler, Compliance-Lücken und wann Sie zu einem Unternehmens-Passwortmanager wechseln sollten.

Passwork BlogAlex Muntyan

Passwork gewinnt Top Performer Frühling 2026 auf SourceForge

Passwork wurde von SourceForge als Top Performer Frühling 2026 ausgezeichnet und gehört zu den besten 10 % von über 100.000 Lösungen. Die Auszeichnung basiert ausschließlich auf verifizierten Bewertungen — 4,8 Sterne insgesamt, mit einer perfekten 5,0 für Support.

Passwork BlogAlex Muntyan

Secrets-Rotations-Lebenszyklus: Von der Erstellung bis zum Widerruf

Secret-Rotation scheitert, wenn sie als geplante Aufgabe statt als Lebenszyklus behandelt wird. Dieser Leitfaden behandelt alle sieben Phasen — von Erstellung und Besitz bis hin zu sicherer Rotation, Notfall-Widerruf und Audit-Nachweisen.

Passwork BlogAlex Muntyan

VaultJacking es una técnica de phishing que ataca la bóveda de Google Password Manager capturando el PIN que la desbloquea. Demostrada por PhishU el 20 de mayo de 2026, el ataque muestra cómo un único secreto de seis dígitos, capturado durante una sesión de phishing adversary-in-the-middle (AiTM), puede dar a un atacante acceso a cada contraseña y passkey sincronizada que la víctima haya almacenado en Google Password Manager.

Para las empresas, los riesgos son mayores de lo que parecen. La bóveda del navegador de un solo empleado puede contener credenciales SSO, acceso a consolas en la nube, inicios de sesión de plataformas financieras y claves de repositorios de código: todo en un solo lugar y expuesto por un único PIN capturado. Es un riesgo organizacional que queda fuera de la mayoría de los manuales de respuesta a incidentes existentes, y fuera de la visibilidad de la mayoría de los equipos de TI y seguridad.

Puntos clave

VaultJacking importa porque los gestores de contraseñas del navegador concentran contraseñas, passkeys y flujos de recuperación en un único objetivo de alto valor. Antes de continuar leyendo, esto es lo que necesita saber.

• VaultJacking ataca la capa de sincronización de la bóveda. El ataque no rompe la criptografía WebAuthn. Abusa del flujo de inscripción de dispositivos que gobierna quién puede leer la bóveda sincronizada.
• El PIN de Google Password Manager es un secreto de acceso a la bóveda. Google utiliza el PIN para proteger los datos de credenciales cifrados. Trátelo en consecuencia, no como un código desechable.
• Un único PIN capturado puede exponer toda la bóveda. La demostración de PhishU muestra que una única entrada de PIN puede permitir a un atacante descifrar cada contraseña y passkey sincronizada en infraestructura controlada por el operador.
• El riesgo empresarial escala con las brechas de gobernanza. La mezcla de perfiles personales y laborales, los perfiles de Chrome no gestionados y las credenciales privilegiadas almacenadas en bóvedas del navegador aumentan el radio de impacto.
• La respuesta a incidentes debe ir más allá de un restablecimiento de contraseña. Un evento sospechoso de VaultJacking requiere revisar dispositivos, sesiones, passkeys, contenidos de la bóveda e inicios de sesión posteriores, no solo cambiar una contraseña.

¿Qué es VaultJacking?

VaultJacking es una técnica de phishing que ataca la experiencia de acceso y recuperación de la bóveda de Google Password Manager. En lugar de robar una credencial de un sitio, el atacante captura el PIN de Google Password Manager durante una sesión de phishing AiTM y lo utiliza para inscribir un dispositivo controlado por el atacante en el dominio de seguridad de Google de la víctima, obteniendo acceso a toda la bóveda de credenciales sincronizadas. El término y la demostración completa se originan en la investigación publicada por PhishU.

El phishing tradicional de credenciales ataca una cuenta a la vez. VaultJacking es una clase diferente de ataque: el atacante evita las credenciales individuales por completo y va directamente al repositorio que las contiene todas.

La investigación de PhishU describe el ataque como totalmente consistente con el phishing AiTM estándar. El proxy AiTM captura el PIN junto con las cookies de sesión. Un proceso en segundo plano añade entonces una passkey propiedad del atacante a la cuenta de Google de la víctima para persistencia, se une al dominio de seguridad desde la infraestructura del atacante usando el PIN capturado, y descifra toda la bóveda. El operador ve cada credencial sincronizada en una sola vista.

Browser Syncjacking, una técnica separada que PhishU referencia, alcanza la misma capa de sincronización de Google mediante una extensión de navegador maliciosa. VaultJacking no requiere ni un punto de apoyo en el dispositivo ni una extensión.

¿Qué es el PIN de Google Password Manager?

El PIN de Google Password Manager es un secreto separado de la contraseña de su cuenta de Google y del bloqueo de pantalla de su dispositivo. La documentación de Google lo describe como una forma de proteger los datos cifrados de Google Password Manager, usar passkeys en un nuevo dispositivo y verificar la identidad.

Los usuarios frecuentemente confunden tres secretos diferentes, y esa confusión es parte de lo que hace efectivo a VaultJacking:

Verá el aviso del PIN de Google Password Manager al crear su primera passkey en un nuevo dispositivo, al acceder a credenciales guardadas cifradas en ciertos contextos de recuperación, o cuando un nuevo dispositivo se une a su dominio de seguridad de Google. Este último escenario es exactamente lo que VaultJacking explota.

La razón estructural por la que esto funciona, según el análisis de PhishU del código fuente de Chromium (chrome/browser/webauthn/enclave_manager.cc y components/trusted_vault/), es que el flujo de unión al dominio de seguridad de Google requiere dos verificaciones: un inicio de sesión en la cuenta de Google y una entrada exitosa del PIN. No hay aviso de aprobación entre dispositivos, ni notificación push a los dispositivos existentes, ni confirmación de «aprobar desde otro dispositivo».

El Llavero de iCloud de Apple requiere que los dispositivos existentes aprueben los nuevos. El modelo de Google no lo hace. Google hizo una elección deliberada de experiencia de usuario: un PIN con un límite de reintentos del lado del servidor es más fácil de recuperar que un modelo de aprobación por push cuando un usuario ha perdido todos sus dispositivos. VaultJacking es la consecuencia de esa decisión.

Cómo funciona la cadena de ataque de VaultJacking

Lo siguiente describe el ataque conceptualmente con fines defensivos. No se incluyen detalles de implementación ofensiva.

1. Señuelo. La víctima recibe un enlace de phishing y llega a una página que imita un flujo legítimo de inicio de sesión o cuenta de Google. Trate cualquier flujo de inicio de sesión inesperado que llegue por correo electrónico, chat o enlace de anuncio con sospecha.
2. Transferencia de confianza. El proxy AiTM presenta un aviso de PIN con el mismo estilo que la propia interfaz de Google: misma fuente, misma entrada de seis celdas, mismo texto. La educación del usuario debe cubrir los avisos de PIN del gestor de contraseñas, no solo las contraseñas y los códigos OTP.
3. Captura del PIN. La víctima introduce el PIN en el flujo de phishing. El PIN es un secreto de acceso a la bóveda, equivalente en sensibilidad a una contraseña maestra.
4. Inscripción del dispositivo del atacante. El atacante utiliza el PIN capturado para unirse al dominio de seguridad de Google de la víctima desde infraestructura controlada por el atacante. También se registra una passkey propiedad del atacante para persistencia. Revise los dispositivos conectados y las passkeys registradas inmediatamente después de cualquier contacto sospechoso de phishing.
5. Descifrado de la bóveda. El Security Domain Secret es liberado por el autenticador en la nube de Google, y el dispositivo del atacante descifra cada contraseña y passkey sincronizada. La bóveda puede contener credenciales para correo electrónico, SSO, consolas en la nube, plataformas financieras y repositorios de código.
6. Compromiso posterior. Las credenciales de terceros guardadas se utilizan contra otros servicios. Rote las credenciales de alto valor y monitorice los inicios de sesión de terceros.

PhishU probó esto de extremo a extremo contra cuentas reales de Google Password Manager, incluyendo la reproducción de passkeys de terceros capturadas independientemente de si la credencial original estaba respaldada por hardware. Trate esto como una técnica demostrada. No hay evidencia pública de explotación activa generalizada en el momento de escribir esto, pero la técnica no requiere acceso especializado ni punto de apoyo en el dispositivo.

¿VaultJacking significa que las passkeys están rotas?

No. VaultJacking no rompe la criptografía de las passkeys. Las passkeys se basan en autenticación de clave pública vinculada al origen según se define en la especificación W3C WebAuthn: la clave privada nunca sale del dispositivo, y la ceremonia de autenticación está vinculada al origen del sitio legítimo. Una página de phishing no puede reproducir una aserción WebAuthn contra el sitio real porque la verificación de origen falla. Esa protección se mantiene.

Lo que demuestra VaultJacking es que las passkeys no existen de forma aislada. Existen dentro de una bóveda, que se sincroniza entre dispositivos, que depende de un mecanismo de recuperación, que está gobernado por un PIN. El atacante evita la ceremonia criptográfica por completo al atacar la capa de gestión de la bóveda en su lugar.

Google describe las passkeys como una forma de iniciar sesión con huella dactilar, escaneo facial o bloqueo de pantalla — más simple y más seguro que las contraseñas. Esa descripción es precisa en la capa de autenticación por sitio. El problema que VaultJacking expone está un nivel más arriba: qué gobierna el acceso al almacén que contiene esas passkeys.

Por qué un único PIN puede crear un gran radio de impacto

Una bóveda de gestor de contraseñas es un almacén concentrado de accesos. Un único PIN capturado expone cada credencial que la víctima haya guardado en Google Password Manager.

El Informe del Panorama de Amenazas de Identidad 2025 de Recorded Future encontró que el dispositivo comprometido promedio proporcionaba 87 credenciales robadas, y que 276 millones de las credenciales indexadas en 2025 incluían cookies de sesión activas — lo que significa que los atacantes podían eludir completamente el MFA para esas cuentas.

El DBIR 2026 de Verizon pone el efecto posterior en contexto: el abuso de credenciales aparece en algún momento en el 39% de todas las brechas confirmadas, en más de 22.000 incidentes en 145 países. Los atacantes rara vez se detienen en la primera puerta que abre una credencial robada. Se mueven lateralmente, escalan privilegios y trabajan a través de cada inicio de sesión guardado hasta que encuentran algo valioso.

¿Quién está en mayor riesgo?

El riesgo se concentra donde se superponen tres condiciones: los datos de la bóveda del navegador son el almacén principal de credenciales, las credenciales de trabajo y personales comparten un perfil, y las credenciales privilegiadas han terminado en un sistema de nivel consumidor.

1. El problema de mezcla de credenciales. Los empleados guardan credenciales de trabajo en perfiles personales de Chrome. Los administradores no tienen visibilidad ni control sobre el contenido de la bóveda o los dispositivos sincronizados. Esto significa que las contraseñas corporativas viven fuera del perímetro de seguridad, respaldadas en los servidores de Google, y accesibles desde cualquier dispositivo en el que el empleado haya iniciado sesión.
2. Los usuarios privilegiados son el objetivo de mayor valor. Las contraseñas de administrador almacenadas en Google Password Manager representan la concentración de riesgo más peligrosa. Un compromiso de bóveda expone las llaves a plataformas de identidad, infraestructura en la nube, sistemas financieros y herramientas de seguridad. Una única cuenta de administrador comprometida se convierte en un punto de pivote para el movimiento lateral a través de toda la organización.
3. La formación en seguridad no cubre esta superficie de ataque. Los programas de concienciación de seguridad enseñan a los usuarios a reconocer correos de phishing y proteger códigos OTP. No enseñan a los usuarios a reconocer los avisos de PIN del gestor de contraseñas como objetivos sensibles. Los usuarios ven una solicitud de PIN y cumplen — no lo ven como un evento de seguridad que debería activar el escepticismo.
4. Las brechas de políticas dejan las credenciales en el lugar equivocado. La mayoría de las organizaciones no tienen una política que separe las bóvedas del navegador de la gestión de credenciales empresariales. Las credenciales compartidas, contraseñas de administrador y cuentas de emergencia pueden almacenarse donde los empleados encuentren conveniente. No existe un registro de auditoría que muestre dónde viven estas credenciales o quién las ha accedido.
5. Los procesos de revisión de dispositivos y sesiones son demasiado lentos. La inscripción sospechosa de dispositivos o el acceso a la bóveda puede pasar desapercibido durante semanas.

El último punto importa más de lo que podría parecer. PhishU señala que Google envía un único correo electrónico de «nuevo inicio de sesión en Windows» cuando un nuevo dispositivo se une al dominio de seguridad — la misma notificación enviada para cualquier nuevo inicio de sesión en Chrome. No se dispara ninguna notificación push en los dispositivos existentes. En un compromiso AiTM donde el atacante también ha capturado la sesión del buzón de la víctima, ese correo puede ser suprimido antes de que el usuario lo vea.

Qué hacer si un PIN de Google Password Manager puede haber sido phisheado

No trate un evento sospechoso de VaultJacking como un incidente de una sola contraseña. Trátelo como posible exposición de la bóveda hasta que se demuestre lo contrario.

La siguiente secuencia de triaje es para equipos de seguridad e individuos. Los nombres de eventos de Google Workspace deben verificarse contra la documentación actual del Administrador de Google antes de construir detección automatizada.

Los pasos 5 y 7 son donde la mayoría de las respuestas a incidentes fallan. Rotar la contraseña de la cuenta de Google sin rotar las credenciales posteriores que protege es como cambiar la cerradura de una caja fuerte después de que el contenido ya haya sido fotografiado.

Passwork le proporciona visibilidad de cada credencial, quién accedió a ella y cuándo. El control de acceso basado en roles significa que las credenciales compartidas permanecen en un solo lugar con un registro de auditoría completo — no dispersas en perfiles de navegador personales. Explore cómo funciona

Cómo los individuos pueden reducir el riesgo de VaultJacking

El consejo práctico aquí es breve. La mayor parte se reduce a tratar el PIN de Google Password Manager de la misma manera que trataría una contraseña maestra.

• No introduzca el PIN de Google Password Manager en ninguna página a la que haya llegado haciendo clic en un enlace de correo electrónico, chat o anuncio. Navegue directamente a la configuración de la cuenta de Google.
• Revise sus dispositivos conectados y passkeys registradas en myaccount.google.com periódicamente. Un dispositivo o passkey desconocido vale la pena investigar.
• Mantenga los perfiles de navegador personales y de trabajo separados. Si un perfil personal se ve comprometido, las credenciales de trabajo no deberían estar en el radio de impacto.
• Evite guardar credenciales de administrador o privilegiadas altamente sensibles en una bóveda de navegador de consumidor. Esas credenciales necesitan auditabilidad y controles de acceso que las bóvedas del navegador no proporcionan.
• Continúe usando passkeys. Siguen siendo más seguras que las contraseñas reutilizables en la capa por sitio. Solo comprenda qué avisos son legítimos y cuáles no.

Controles empresariales y recomendaciones de políticas

El Informe de Tendencias de Inicio de Sesión Seguro 2025 de Okta encontró que la adopción de autenticadores resistentes al phishing creció del 8,6% al 14,0% de usuarios en un año — un aumento del 63%. Ese crecimiento es una buena noticia. El problema de gobernanza es que las organizaciones están adoptando passkeys más rápido de lo que están construyendo las políticas para gestionar las bóvedas que las almacenan.

Los siguientes controles son proporcionales a la sensibilidad de las credenciales involucradas. No todas las organizaciones necesitan todos los controles, pero toda organización que almacene credenciales privilegiadas en bóvedas del navegador necesita una política que aborde eso específicamente.

• Gobernanza del perfil del navegador. Imponga perfiles de trabajo gestionados separados. Desaconseje la mezcla de bóvedas personales y de trabajo a través de políticas y educación del usuario.
• Almacenamiento de credenciales privilegiadas. Prohíba almacenar credenciales de administrador, emergencia, root de nube, finanzas y cuentas de servicio en bóvedas de navegador no gestionadas. Las bóvedas del navegador son convenientes para uso personal. No están diseñadas para credenciales compartidas, acceso privilegiado o registros de auditoría.
• Gestión empresarial de contraseñas. Use un gestor de contraseñas empresarial dedicado para credenciales compartidas, privilegiadas y auditadas. Passwork es una solución autoalojada construida exactamente para esta separación: credenciales privilegiadas en una bóveda controlada y auditable con control de acceso basado en roles, integración AD/LDAP y registro de auditoría completo.
• MFA resistente al phishing. Continúe adoptando WebAuthn y FIDO2. Extienda la educación del usuario para cubrir flujos de recuperación y avisos de bóveda, no solo contraseñas y códigos OTP.
• Visibilidad de dispositivos y sesiones. Monitorice inscripciones de dispositivos desconocidos, actividad de sesión inusual y cambios inesperados en la seguridad de la cuenta. Google envía un correo de «nuevo inicio de sesión» para cualquier nuevo inicio de sesión en Chrome. En un compromiso AiTM donde el atacante también ha capturado la sesión del buzón de la víctima, ese correo puede ser suprimido antes de que el usuario lo vea.
• Respuesta a incidentes. Construya un manual de exposición de bóveda que incluya rotación de credenciales, revocación de sesiones, revisión de passkeys y monitorización de cuentas de terceros.
• Concienciación de seguridad. Capacite a los usuarios de que los PINs, avisos del gestor de contraseñas y flujos de recuperación son objetivos de phishing. Conllevan el mismo riesgo que las contraseñas y los códigos OTP.

El punto sobre el gestor de contraseñas empresarial merece énfasis. Las bóvedas del navegador son convenientes y mejoran la unicidad de las contraseñas para muchos usuarios. No están diseñadas para credenciales compartidas, acceso privilegiado o registros de auditoría.

Por qué un gestor de contraseñas empresarial es más seguro que una bóveda del navegador para credenciales de trabajo

Un gestor de contraseñas del navegador resuelve un problema de conveniencia personal: autocompletado, sincronización entre dispositivos, almacenamiento sin esfuerzo. Para un usuario individual, esa es una elección razonable. Para un entorno corporativo, esa misma simplicidad se convierte en una vulnerabilidad estructural.

Passwork es la alternativa empresarial a las bóvedas personales del navegador. La extensión de navegador de Passwork funciona exactamente como un gestor de contraseñas integrado del navegador — autocompleta inicios de sesión en sitios web, ofrece guardar nuevas credenciales — pero las almacena en una bóveda corporativa protegida en lugar de un perfil personal del navegador.

Passwork soporta despliegue autoalojado, cifrado AES-256, integración con Active Directory y LDAP, autorización SSO, control de acceso basado en roles, registro de auditoría completo, integración SIEM y herramientas REST API y CLI para flujos de trabajo DevOps.

La diferencia es arquitectónica. Una bóveda del navegador prioriza la conveniencia individual. Un gestor de contraseñas empresarial prioriza el control y la visibilidad organizacional. Cuando las credenciales privilegiadas terminan en una bóveda del navegador, se ha elegido la herramienta incorrecta para el trabajo — no porque la herramienta sea mala, sino porque fue diseñada para un problema diferente.

Conclusión: Qué hacer ante VaultJacking

La amenaza que describe VaultJacking es específica: una técnica de phishing que convierte un único PIN capturado en exposición de credenciales a nivel de bóveda. La respuesta debe ser igualmente específica — no pánico sobre las passkeys, y no descarte del riesgo de la bóveda del navegador, sino una política clara que separe la conveniencia de credenciales personales de la gobernanza de credenciales privilegiadas.

Comience con la auditoría. Descubra qué credenciales privilegiadas viven actualmente en bóvedas del navegador. ¿Qué cuentas de administrador están sincronizadas con dispositivos personales? ¿Qué credenciales de emergencia están almacenadas en Google Password Manager? Esa respuesta le dirá cuánto trabajo hay por hacer.

A partir de ahí, el camino es directo: prohíba las credenciales privilegiadas en bóvedas del navegador, muévalas a un gestor de contraseñas empresarial con registros de auditoría y controles de acceso, y extienda su formación de concienciación de seguridad para cubrir avisos de bóveda y flujos de recuperación.

VaultJacking no es una razón para abandonar los gestores de contraseñas del navegador. Es una razón para usarlos para lo que fueron diseñados — credenciales personales — y para construir un sistema separado y auditable para todo lo demás.

Passwork es un gestor de contraseñas y secretos empresarial autoalojado construido para la gobernanza de credenciales privilegiadas. Proporciona acceso basado en roles, registros de auditoría completos y separación total de las bóvedas de navegador de consumidor. Vea cómo encaja en su infraestructura

Preguntas frecuentes

¿Qué es VaultJacking?

VaultJacking es una técnica de phishing que ataca la bóveda de Google Password Manager capturando el PIN de Google Password Manager del usuario durante una sesión de phishing adversary-in-the-middle. El PIN capturado se utiliza para inscribir un dispositivo controlado por el atacante en el dominio de seguridad de Google de la víctima, descifrando cada contraseña y passkey sincronizada almacenada en la bóveda. La técnica fue demostrada de extremo a extremo por PhishU en mayo de 2026.

¿Es VaultJacking una vulnerabilidad de Google?

Según los informes publicados, VaultJacking es una técnica demostrada de phishing y abuso de flujos de trabajo, no una vulnerabilidad clasificada en los sistemas de Google. Explota el diseño del flujo de inscripción de dispositivos de Google — específicamente la ausencia de aprobación entre dispositivos para nuevas uniones al dominio de seguridad — que Google eligió deliberadamente como una decisión de experiencia de usuario para la recuperación de dispositivos perdidos. Si Google clasifica esto como una vulnerabilidad que requiere una corrección es una cuestión separada que no ha sido respondida públicamente en el momento de escribir esto.

¿VaultJacking rompe las passkeys?

No. Las passkeys se basan en criptografía de clave pública vinculada al origen según se define en la especificación W3C WebAuthn. Una página de phishing no puede reproducir una aserción WebAuthn contra el sitio real porque la vinculación al origen falla. VaultJacking ataca la capa de bóveda y recuperación que almacena las passkeys — no la ceremonia de autenticación criptográfica en sí. Las passkeys siguen siendo resistentes al phishing en la capa de inicio de sesión por sitio.

¿Qué es el PIN de Google Password Manager?

El PIN de Google Password Manager es un secreto que protege los datos cifrados de Google Password Manager. Según la documentación de Google, se crea cuando un usuario guarda su primera passkey en un ordenador, iPhone o iPad, y se utiliza para acceder a passkeys en nuevos dispositivos, verificar la identidad y asegurar que ni siquiera Google pueda leer el contenido cifrado de la bóveda. Es distinto de la contraseña de la cuenta de Google y del bloqueo de pantalla del dispositivo.

¿Puede un único PIN exponer todas mis contraseñas guardadas?

La demostración de PhishU muestra que un PIN de Google Password Manager de seis dígitos capturado puede permitir a un atacante descifrar toda la bóveda sincronizada — cada contraseña guardada y cada passkey sincronizada — desde infraestructura controlada por el atacante. El PIN libera el Security Domain Secret, que descifra la bóveda en una sola operación. Si introdujo el PIN en una página a la que no navegó directamente, trátelo como posible exposición completa de la bóveda.

¿Qué debo hacer si introduje el PIN en una página sospechosa?

Revise sus dispositivos conectados y passkeys registradas en myaccount.google.com inmediatamente. Revoque cualquier dispositivo o sesión desconocida. Cambie su contraseña de la cuenta de Google. Rote las credenciales de alto valor guardadas en la bóveda — priorice SSO, correo electrónico, consolas en la nube, plataformas financieras y cuentas de administrador. Compruebe los servicios de terceros en busca de actividad de inicio de sesión inusual. Si está en una organización, abra un caso de respuesta a incidentes en lugar de tratar esto como un problema de una sola cuenta.

¿Deberían las empresas prohibir Google Password Manager?

Una prohibición general no es la política correcta para la mayoría de las organizaciones. Un enfoque basado en riesgos funciona mejor: restrinja el almacenamiento de credenciales privilegiadas y compartidas a un gestor de contraseñas empresarial con controles de auditoría, imponga perfiles de navegador gestionados separados para uso laboral, y extienda la formación de concienciación sobre phishing para cubrir avisos del gestor de contraseñas y flujos de recuperación. Google Password Manager es apropiado para credenciales personales; no está diseñado para cuentas de emergencia o acceso de administrador compartido.

¿Son las llaves de seguridad de hardware suficientes para detener esto?

Las llaves de seguridad de hardware fortalecen la garantía de inicio de sesión de la cuenta de Google, pero no gobiernan automáticamente la sincronización de la bóveda del navegador, los flujos de recuperación o las credenciales almacenadas dentro de la bóveda. VaultJacking ataca la capa de gestión de la bóveda, no el paso de inicio de sesión de la cuenta. Una llave de hardware en la cuenta de Google reduce el riesgo de toma de control de la cuenta pero no impide que un usuario sea engañado para introducir su PIN de Google Password Manager en una página de phishing.

Gestión de contraseñas y accesos para pymes: ¿Es KeePass suficiente?

¿Usa KeePass para su equipo? Descubra los riesgos ocultos de KeePass para pymes en 2026 — fallos de sincronización, brechas de cumplimiento y cuándo cambiar a un gestor de contraseñas corporativo.

Passwork BlogAlex Muntyan

Passwork gana Top Performer primavera 2026 en SourceForge

Passwork ha sido nombrado Top Performer primavera 2026 por SourceForge, situándose en el 10% superior de más de 100.000 soluciones. La insignia se basa enteramente en reseñas verificadas — 4,8 estrellas en general, con un 5,0 perfecto en soporte.

Passwork BlogAlex Muntyan

Ciclo de vida de la rotación de secretos: De la creación a la revocación

La rotación de secretos falla cuando se trata como una tarea programada en lugar de un ciclo de vida. Esta guía cubre las siete etapas — desde la creación y propiedad hasta la rotación segura, revocación de emergencia y evidencia de auditoría.

Passwork BlogAlex Muntyan

VaultJacking is a phishing technique that targets the Google Password Manager vault by capturing the PIN that unlocks it. Demonstrated by PhishU on May 20, 2026, the attack shows how a single six-digit secret, captured during an adversary-in-the-middle (AiTM) phishing session, can give an attacker access to every synced password and passkey a victim has stored in Google Password Manager.

For businesses, the stakes are higher than they appear. A single employee's browser vault can hold SSO credentials, cloud console access, finance platform logins, and code repository keys: all in one place and exposed by one captured PIN. It is an organizational risk that sits outside most existing incident-response playbooks, and outside the visibility of most IT and security teams.

Key takeaways

VaultJacking matters because browser password managers concentrate passwords, passkeys, and recovery flows into a single high-value target. Before reading further, here is what you need to know.

• VaultJacking targets the vault sync layer. The attack does not break WebAuthn cryptography. It abuses the device-enrollment flow that governs who can read the synced vault.
• The Google Password Manager PIN is a vault-access secret. Google uses the PIN to protect encrypted credential data. Treat it accordingly, not as a throwaway code.
• One captured PIN can expose the entire vault. PhishU's demonstration shows that a single PIN entry can allow an attacker to decrypt every synced password and passkey on operator-controlled infrastructure.
• Enterprise risk scales with governance gaps. Personal/work profile mixing, unmanaged Chrome profiles, and privileged credentials stored in browser vaults all increase the blast radius.
• Incident response must go beyond a password reset. A suspected VaultJacking event requires reviewing devices, sessions, passkeys, vault contents, and downstream logins, not just changing one password.

What is VaultJacking?

VaultJacking is a phishing technique that targets the Google Password Manager vault access and recovery experience. Instead of stealing one site credential, the attacker captures the Google Password Manager PIN during an AiTM phishing session and uses it to enroll an attacker-controlled device into the victim's Google security domain, gaining access to the entire synced credential vault. The term and the end-to-end demonstration originate from PhishU's published research.

Traditional credential phishing targets one account at a time. VaultJacking is a different class of attack: the attacker bypasses individual credentials entirely and goes straight for the repository that holds all of them.

PhishU's research describes the attack as fully consistent with standard AiTM phishing. The AiTM proxy captures the PIN alongside session cookies. A background worker then adds an attacker-owned passkey to the victim's Google account for persistence, joins the security domain from attacker infrastructure using the captured PIN, and decrypts the entire vault. The operator sees every synced credential in a single view.

Browser Syncjacking, a separate technique PhishU references, reaches the same Google sync layer via a malicious browser extension. VaultJacking requires neither a device foothold nor an extension.

What is the Google Password Manager PIN?

The Google Password Manager PIN is a separate secret from your Google account password and your device screen lock. Google's documentation describes it as a way to protect encrypted Google Password Manager data, use passkeys on a new device, and verify identity.

Users frequently confuse three different secrets, and that confusion is part of what makes VaultJacking effective:

You will see the Google Password Manager PIN prompt when creating your first passkey on a new device, when accessing encrypted saved credentials in certain recovery contexts, or when a new device joins your Google security domain. That last scenario is exactly what VaultJacking exploits.

The structural reason this works, according to PhishU's analysis of the Chromium source (chrome/browser/webauthn/enclave_manager.cc and components/trusted_vault/), is that Google's security domain join flow requires two checks: a Google account sign-in and a successful PIN entry. There is no cross-device approval prompt, no push notification to existing devices, no "approve from another device" confirmation.

Apple's iCloud Keychain requires existing devices to approve new ones. Google's model does not. Google made a deliberate UX trade-off: a PIN with a server-side retry cap is easier to recover from than a push-to-approve model when a user has lost all their devices. VaultJacking is the consequence of that trade-off.

How the VaultJacking attack chain works

The following describes the attack conceptually for defensive purposes. No offensive implementation details are included.

1. Lure. The victim receives a phishing link and lands on a page that imitates a legitimate Google sign-in or account workflow. Treat any unexpected sign-in flow arriving via email, chat, or ad link with suspicion.
2. Trust transfer. The AiTM proxy renders a PIN prompt styled to match Google's own interface: same font, same six-cell input, same copy. User education must cover password-manager PIN prompts, not only passwords and OTP codes.
3. PIN capture. The victim enters the PIN into the phishing flow. The PIN is a vault-access secret, equivalent in sensitivity to a master password.
4. Attacker device enrollment. The attacker uses the captured PIN to join the victim's Google security domain from attacker-controlled infrastructure. An attacker-owned passkey is also registered for persistence. Review signed-in devices and registered passkeys immediately after any suspected phishing contact.
5. Vault decryption. The Security Domain Secret is released by Google's cloud authenticator, and the attacker's device decrypts every synced password and passkey. The vault may contain credentials for email, SSO, cloud consoles, financial platforms, and code repositories.
6. Downstream compromise. Saved third-party credentials are used against other services. Rotate high-value credentials and monitor third-party logins.

PhishU tested this end to end against live Google Password Manager accounts, including replay of captured third-party passkeys regardless of whether the original credential was hardware-backed. Treat this as a demonstrated technique. There is no public evidence of widespread active exploitation at the time of writing, but the technique requires no specialized access or device foothold.

Does VaultJacking mean passkeys are broken?

No. VaultJacking does not break passkey cryptography. Passkeys are based on origin-bound public-key authentication as defined in the W3C WebAuthn specification: the private key never leaves the device, and the authentication ceremony is bound to the legitimate site origin. A phishing page cannot replay a WebAuthn assertion against the real site because the origin check fails. That protection holds.

What VaultJacking demonstrates is that passkeys do not exist in isolation. They exist inside a vault, which syncs across devices, which relies on a recovery mechanism, which is governed by a PIN. The attacker bypasses the cryptographic ceremony entirely by targeting the vault management layer instead.

Google describes passkeys as a way to sign in with a fingerprint, face scan, or screen lock — simpler and safer than passwords. That description is accurate at the per-site authentication layer. The issue VaultJacking surfaces is one level up: what governs access to the store that holds those passkeys.

Why one PIN can create a large blast radius

A password-manager vault is a concentrated store of access. One captured PIN exposes every credential the victim has ever saved in Google Password Manager.

Recorded Future's 2025 Identity Threat Landscape Report found that the average compromised device yielded 87 stolen credentials, and that 276 million of the credentials indexed in 2025 included active session cookies — meaning attackers could bypass MFA entirely for those accounts.

Verizon's 2026 DBIR puts the downstream effect in context: credential abuse appears at some point in 39% of all confirmed breaches, across more than 22,000 incidents in 145 countries. Attackers rarely stop at the first door a stolen credential opens. They move laterally, escalate privileges, and work through every saved login until they hit something valuable.

Who is most at risk?

Risk concentrates where three conditions overlap: browser vault data is the primary credential store, work and personal credentials share a profile, and privileged credentials have ended up in a consumer-grade system.

1. The credential mixing problem. Employees save work credentials in personal Chrome profiles. Admins have no visibility or control over vault contents or synced devices. This means corporate passwords live outside the security perimeter, backed up to Google's servers, and accessible from any device the employee has ever logged into.
2. Privileged users are the highest-value target. Admin passwords stored in Google Password Manager represent the most dangerous concentration of risk. One vault compromise exposes the keys to identity platforms, cloud infrastructure, finance systems, and security tooling. A single compromised admin account becomes a pivot point for lateral movement across the entire organization.
3. Security training doesn't cover this attack surface. Security awareness programs teach users to recognize phishing emails and protect OTP codes. They don't teach users to recognize password-manager PIN prompts as sensitive targets. Users see a PIN request and comply — they don't see it as a security event that should trigger skepticism.
4. Policy gaps leave credentials in the wrong place. Most organizations have no policy separating browser vaults from enterprise credential management. Shared credentials, admin passwords, and break-glass accounts may be stored wherever employees find it convenient. No audit trail exists to show where these credentials live or who has accessed them.
5. Device and session review processes are too slow. Suspicious device enrollment or vault access may go unnoticed for weeks.

The last point matters more than it might appear. PhishU notes that Google sends a single "new sign-in on Windows" email when a new device joins the security domain — the same notification sent for any new Chrome login. No push notification fires on existing devices. In an AiTM engagement where the attacker has also captured the victim's inbox session, that email can be suppressed before the user sees it.

What to do if a Google Password Manager PIN may have been phished

Do not treat a suspected VaultJacking event as a single-password incident. Treat it as possible vault exposure until proven otherwise.

The following triage sequence is for security teams and individuals. Google Workspace event names should be verified against current Google Admin documentation before building automated detection.

Steps 5 and 7 are where most incident responses fall short. Rotating the Google account password without rotating the downstream credentials it protects is like changing the lock on a safe after the contents have already been photographed.

Passwork gives you visibility into every credential, who accessed it, and when. Role-based access means shared credentials stay in one place with a complete audit trail — not scattered across personal browser profiles. Explore how it works

Stopping the breach: step-by-step technical response

When a VaultJacking event is suspected, the first 60 minutes determine how far the damage spreads. These steps are for security engineers and IT administrators. Execute them in order — later steps depend on evidence preserved in earlier ones.

1. Force sign-out of all active sessions. Navigate to myaccount.google.com/security → "Manage all devices" → revoke every session you cannot physically account for. Do not delegate this to the affected user — do it from an admin console where possible. Session revocation cuts off an attacker who has vault access but has not yet finished extracting credentials.
2. Audit registered passkeys before revoking anything else. Go to myaccount.google.com/security → "Passkeys and security keys." Screenshot the full list first, then revoke every entry the user cannot identify by device name and registration date. An attacker-registered passkey survives a password reset and re-establishes persistence. PhishU's research confirms that the background worker registers an operator-owned passkey as part of the standard VaultJacking flow — persistence is built in by design.
3. Pull the Google Workspace audit log. In admin.google.com → Reports → Audit → Login, filter for the affected user's account within the 24-hour window around the reported phishing event. Look for any login_type event combined with a source IP outside your organization's known ranges. A new device enrollment from an unrecognized IP within minutes of a phishing click timestamp is a strong indicator of vault compromise. Verify current Google Workspace event field names against Google Admin SDK documentation before building automated queries.
4. Configure a SIEM alert for future detection. Create a high-priority correlation rule: new Google account device enrollment event + source IP not in corporate IP allowlist + time delta under 10 minutes from a known phishing click. Most organizations currently have no detection for vault-layer events — this rule closes that gap. F5 Labs' threat bulletin format recommends building SIEM detection rules tied to specific behavioral indicators rather than relying on email notifications alone.
5. Rotate credentials in strict priority order. Do not rotate in bulk without logging each action — you need the audit trail for the incident report and for downstream notification decisions.
   1. SSO and identity provider accounts
   2. Cloud console root and admin credentials
   3. Code repository tokens and CI/CD pipeline secrets
   4. Finance and payroll platform logins
   5. VPN and remote access credentials
   6. Any break-glass or shared service accounts stored in the vault
6. Check downstream third-party services. Review login events from the affected account on all third-party services for the 48-hour window after the phishing event. Attackers typically test saved credentials within hours of vault access. Verizon's 2026 DBIR found credential abuse appears in 39% of confirmed breaches — lateral movement through saved logins is the expected next step, not an edge case.
7. Step 7. Preserve forensic evidence before full remediation. Screenshot the device list, export the audit log, record the phishing URL and timestamp, and document which credentials were in the vault at the time of the event. Revocation destroys attacker persistence — but it also destroys some evidence. Preserve first, remediate second.

Passwork gives your security team a full audit log of every credential access event — who opened what, when, and from which device. When an incident happens, you have the evidence trail ready. See how it works

How individuals can reduce VaultJacking risk

The practical advice here is short. Most of it comes down to treating the Google Password Manager PIN the same way you would treat a master password — because functionally, it is one.

• Do not enter the Google Password Manager PIN into any page you reached by clicking a link in email, chat, or an ad. Navigate to Google account settings directly by typing myaccount.google.com into the address bar.
• Review your signed-in devices and registered passkeys at myaccount.google.com periodically. An unfamiliar device or a passkey you do not recognize is worth investigating — not ignoring. PhishU's research shows that attacker-registered passkeys are added silently, with no notification to existing devices and no push prompt.
• Keep personal and work browser profiles separate. If a personal profile is compromised, work credentials should not be in the blast radius. Okta's 2025 Secure Sign-in Trends Report found phishing-resistant authenticator adoption grew from 8.6% to 14.0% in one year — but adoption at the authentication layer does not protect a vault that is governed by a PIN.
• Avoid saving highly sensitive admin or privileged credentials in a consumer browser vault. Those credentials need auditability and access controls that browser vaults do not provide. Continue using passkeys — they remain safer than reusable passwords at the per-site layer. The issue is not passkeys. The issue is what governs the store that holds them.

Building the controls that prevent the next one: policy and governance checklist

Okta's 2025 Secure Sign-in Trends Report found that phishing-resistant authenticator adoption grew from 8.6% to 14.0% of users in one year — a 63% increase. That growth is real progress. The governance gap is that organizations are adopting passkeys faster than they are building policies to manage the vaults that store them.

The following steps are proportional to the sensitivity of credentials involved. Not every organization needs every control. Every organization that stores privileged credentials in browser vaults needs a policy that addresses that specifically.

1. Audit which privileged credentials currently live in browser vaults. Use your MDM or endpoint tooling to identify Chrome profile sync status on all managed devices. If you cannot answer "which admin accounts are synced to personal Google profiles," that is the first gap to close — before writing any policy.
2. Write a policy that names specific credential categories. Prohibit storage of break-glass accounts, admin credentials, shared service accounts, cloud-root credentials, and CI/CD secrets in any consumer browser vault. A policy that says "sensitive data" without naming categories produces inconsistent compliance. Name the categories. Set an enforcement date.
3. Migrate covered credentials before the enforcement date. A policy without a migration path produces shadow credential stores. Move all credentials covered by Step 2 into an enterprise password manager with role-based access control and a full audit log before the policy takes effect. Passwork supports self-hosted deployment with AES-256 encryption, AD/LDAP integration, and complete audit logging — built specifically for this separation between privileged corporate credentials and personal browser convenience.
4. Enforce separate managed browser profiles for work use. Prevent personal and work vault mixing through MDM policy and user education. When a personal profile is compromised, work credentials should not be in scope. This is a configuration change, not just a recommendation.
5. Update phishing awareness training to cover vault prompts. Security awareness programs teach users to recognize phishing emails and protect OTP codes. They do not teach users that a password-manager PIN prompt carries the same risk as a master password. Add vault prompts, recovery flows, and PIN requests to your training curriculum explicitly. Users who understand what the PIN unlocks are significantly harder to VaultJack.
6. Build a vault-exposure runbook into your incident response plan. The runbook must cover: session revocation, device enrollment audit, passkey review, downstream credential rotation, and third-party account monitoring — as a single coordinated response. Walk through detection, containment, and rotation. Identify which steps your team cannot currently execute.
7. Configure detection for new device enrollments on privileged accounts. Set your CASB or identity platform to alert on new Google account device enrollments from unmanaged or unrecognized devices for all users with privileged access.
8. Review browser profile governance quarterly. Employees change roles, devices, and credential habits faster than annual reviews capture. A quarterly check on which managed devices have Chrome sync enabled and what profile type is active costs less than one vault-exposure incident response.

Why an enterprise password manager is safer than a browser vault for work credentials

A browser password manager solves a personal convenience problem: autofill, device sync, effortless storage. For an individual user, that is a reasonable choice. For a corporate environment, that same simplicity becomes a structural vulnerability.

Passwork is the enterprise alternative to personal browser vaults. The Passwork browser extension works exactly like a built-in browser password manager — it autofills logins on websites, offers to save new credentials — but stores them in a protected corporate vault instead of a personal browser profile.

Passwork supports self-hosted deployment, AES-256 encryption, Active Directory and LDAP integration, SSO authorization, role-based access control, full audit logging, SIEM integration, and REST API and CLI tools for DevOps workflows.

The difference is architectural. A browser vault prioritizes individual convenience. An enterprise password manager prioritizes organizational control and visibility. When privileged credentials end up in a browser vault, you have chosen the wrong tool for the job — not because the tool is bad, but because it was designed for a different problem.

Conclusion: What to do about VaultJacking

The threat VaultJacking describes is specific: a phishing technique that turns one captured PIN into vault-wide credential exposure. The response should be equally specific — not panic about passkeys, and not dismissal of browser vault risk, but a clear-eyed policy that separates personal credential convenience from privileged credential governance.

Start with the audit. Find out which privileged credentials currently live in browser vaults.Which admin accounts are synced to personal devices? Which break-glass credentials are stored in Google Password Manager? That answer will tell you how much work there is to do.

From there, the path is straightforward: prohibit privileged credentials in browser vaults, move them to an enterprise password manager with audit trails and access controls, and extend your security awareness training to cover vault prompts and recovery flows.

VaultJacking is not a reason to abandon browser password managers. It is a reason to use them for what they were designed for — personal credentials — and to build a separate, auditable system for everything else.

Passwork is a self-hosted enterprise password and secrets manager built for privileged credential governance. It provides role-based access, full audit logs, and complete separation from consumer browser vaults. See how it fits into your infrastructure

Frequently Asked Questions

What is VaultJacking?

VaultJacking is a phishing technique that targets the Google Password Manager vault by capturing the user's Google Password Manager PIN during an adversary-in-the-middle phishing session. The captured PIN is used to enroll an attacker-controlled device into the victim's Google security domain, decrypting every synced password and passkey stored in the vault. The technique was demonstrated end to end by PhishU in May 2026.

Is VaultJacking a Google vulnerability?

Based on published reporting, VaultJacking is a demonstrated phishing and workflow-abuse technique, not a classified vulnerability in Google's systems. It exploits the design of Google's device-enrollment flow — specifically the absence of cross-device approval for new security domain joins — which Google chose deliberately as a UX trade-off for lost-device recovery. Whether Google classifies this as a vulnerability requiring a fix is a separate question that has not been publicly answered at the time of writing.

Does VaultJacking break passkeys?

No. Passkeys are based on origin-bound public-key cryptography as defined in the W3C WebAuthn specification. A phishing page cannot replay a WebAuthn assertion against the real site because the origin binding fails. VaultJacking targets the vault and recovery layer that stores passkeys — not the cryptographic authentication ceremony itself. Passkeys remain phishing-resistant at the per-site login layer.

What is the Google Password Manager PIN?

The Google Password Manager PIN is a secret that protects encrypted Google Password Manager data. According to Google's documentation, it is created when a user saves their first passkey on a computer, iPhone, or iPad, and it is used to access passkeys on new devices, verify identity, and ensure that not even Google can read the encrypted vault contents. It is distinct from the Google account password and from the device screen lock.

Can one PIN expose all my saved passwords?

PhishU's demonstration shows that a captured six-digit Google Password Manager PIN can allow an attacker to decrypt the entire synced vault — every saved password and every synced passkey — from attacker-controlled infrastructure. The PIN releases the Security Domain Secret, which decrypts the vault in a single operation. If you entered the PIN on a page you did not navigate to directly, treat it as possible full vault exposure.

What should I do if I entered the PIN on a suspicious page?

Review your signed-in devices and registered passkeys at myaccount.google.com immediately. Revoke any unfamiliar devices or sessions. Change your Google account password. Rotate high-value credentials saved in the vault — prioritize SSO, email, cloud consoles, financial platforms, and admin accounts. Check third-party services for unusual login activity. If you are in an organization, open an incident-response case rather than treating this as a single-account issue.

Should companies ban Google Password Manager?

A blanket ban is not the right policy for most organizations. A risk-based approach works better: restrict privileged and shared credential storage to an enterprise password manager with audit controls, enforce separate managed browser profiles for work use, and extend phishing awareness training to cover password-manager prompts and recovery flows. Google Password Manager is appropriate for personal credentials; it is not designed for break-glass accounts or shared admin access.

Are hardware security keys enough to stop this?

Hardware security keys strengthen Google account sign-in assurance, but they do not automatically govern browser-vault synchronization, recovery flows, or the credentials stored inside the vault. VaultJacking targets the vault management layer, not the account sign-in step. A hardware key on the Google account reduces the risk of account takeover but does not prevent a user from being tricked into entering their Google Password Manager PIN on a phishing page.

Password and access management for SMBs: Is KeePass enough?

Using KeePass for your team? Discover the hidden risks of KeePass for SMBs in 2026 — sync failures, compliance gaps, and when to switch to a corporate password manager.

Passwork BlogAlex Muntyan

Passwork wins Top Performer Spring 2026 on SourceForge

Passwork has been named a Top Performer Spring 2026 by SourceForge, ranking in the top 10% of 100,000+ solutions. The badge is based entirely on verified reviews — 4.8 stars overall, with a perfect 5.0 for support.

Passwork BlogAlex Muntyan

Secrets rotation lifecycle: From creation to revocation

Secret rotation fails when it’s treated as a scheduled task rather than a lifecycle. This guide covers all seven stages — from creation and ownership to safe rotation, emergency revocation, and audit evidence.

Passwork BlogAlex Muntyan

Tres cosas ocurrieron en abril de 2026 que no parecen estar conectadas — hasta que se ve el patrón.

APT28 secuestró 18.000 routers en 120 países y redirigió el tráfico de autenticación a través de un proxy adversario intermediario. Sin malware. Solo una advertencia de certificado TLS que la mayoría de los usuarios ignoraron. Credenciales de Microsoft 365 y tokens OAuth recopilados en el punto intermedio, MFA completamente eludido.

Un desarrollador en una startup de productividad con IA fue infectado por un infostealer común. El malware costó aproximadamente 200 dólares en un foro de la darknet. Extrajo un token OAuth almacenado en el navegador, lo entregó a los atacantes, y en cuestión de horas estaban dentro del entorno de producción de Vercel — enumerando claves API, credenciales de bases de datos y claves de firma.

ShinyHunters extrajo tokens de autenticación de un proveedor de análisis externo llamado Anodot y pasó el día monetizando el acceso a docenas de plataformas downstream. Vimeo. Zara. Clientes de Snowflake. Ninguna de las plataformas principales fue comprometida directamente. El ataque se ejecutó completamente a través de la capa de integración.

El hilo común: la brecha nunca comenzó donde terminó el daño. Cada atacante entró a través de un periférico — un proveedor, una integración, un dispositivo olvidado — y pivotó hacia el objetivo real desde allí.

Este resumen cubre los incidentes de credenciales y autenticación que definieron abril de 2026, las estadísticas que les dan contexto, y lo que colectivamente significan para cómo las organizaciones gestionan el acceso.

Conclusiones clave

• APT28 secuestró 18.000 routers en 120 países para robar tokens OAuth de Microsoft 365. La campaña FrostArmada no requirió malware y casi no dejó rastro visible — la configuración DNS fue sobrescrita silenciosamente para redirigir el tráfico de autenticación a través de un proxy adversario intermediario. MFA fue completamente eludido. El FBI desmanteló la infraestructura en abril de 2026.
• Storm-2372 eludió MFA a escala sin robar una sola contraseña. La campaña abusó del flujo OAuth Device Code, usando señuelos específicos por rol generados por IA para engañar a las víctimas y que autorizaran sesiones controladas por atacantes. El toolkit (EvilTokens) automatizó toda la operación de principio a fin.
• La brecha de Anodot expuso tokens almacenados de docenas de plataformas downstream. ShinyHunters extrajo tokens de autenticación de un proveedor de análisis externo y los usó para acceder a datos de clientes en Vimeo (119.000 usuarios) e Inditex/Zara (197.000 registros). Snowflake no fue comprometido — el ataque se ejecutó completamente a través de la capa de integración.
• Un infostealer común en el dispositivo de un desarrollador fue suficiente para vulnerar el entorno de producción de Vercel. Lumma Stealer comprometió Context.ai, un proveedor de IA periférico. El acceso OAuth heredado dio a los atacantes entrada directa a los sistemas de Vercel — sin zero-day, sin phishing al personal de Vercel requerido.
• Un paquete malicioso de Bitwarden CLI circuló vía npm durante 94 minutos. Los atacantes secuestraron una GitHub Action en el pipeline CI/CD e inyectaron un payload dirigido a secretos de desarrolladores, credenciales en la nube y configuraciones de herramientas de codificación con IA — con auto-propagación integrada a través de repositorios accesibles.
• El desarrollo asistido por IA llevó las filtraciones de secretos a un récord de 28,6 millones en 2025 — un aumento del 34% interanual. Las filtraciones de credenciales de servicios de IA crecieron un 81%. Los commits coautorados por herramientas de IA filtran secretos aproximadamente al doble de la tasa base. El 64% de los secretos expuestos en 2022 permanecían activos y explotables en 2026.
• Cada incidente importante de este mes siguió el mismo patrón. El objetivo principal nunca fue la víctima final — los atacantes se movieron a través de un proveedor periférico, un token almacenado o una dependencia comprometida para alcanzar el objetivo real. MFA no detuvo ninguna de las campañas de robo de credenciales. La superficie de ataque es la capa de integración, el pipeline CI/CD y la concesión OAuth.

APT28: campaña de secuestro DNS FrostArmada desarticulada por autoridades internacionales

Una operación policial internacional que involucró al FBI, el Departamento de Justicia de EE. UU. y el gobierno polaco, con soporte técnico de Microsoft y Black Lotus Labs, desmanteló FrostArmada: una campaña de APT28 que secuestró configuraciones DNS de routers para robar credenciales de Microsoft 365 y tokens OAuth. Activa desde mayo de 2025, la campaña infectó 18.000 dispositivos en 120 países en su pico en diciembre de 2025.

Qué ocurrió

APT28 (también rastreado como Fancy Bear, Forest Blizzard, Strontium y Storm-2754) — atribuido por el NCSC y el DoJ de EE. UU. a la unidad militar 26165 del GRU ruso — comprometió routers SOHO expuestos a internet explotando vulnerabilidades públicas conocidas. El objetivo principal fue el TP-Link WR841N vía CVE-2023-50224, que permitía a atacantes no autenticados extraer credenciales del router mediante una solicitud HTTP GET manipulada, y luego sobrescribir la configuración DHCP/DNS con una segunda solicitud.

La cadena de ataque funcionó de la siguiente manera:

1. El router es comprometido vía una vulnerabilidad conocida; la configuración DNS es sobrescrita para apuntar a nodos VPS controlados por el atacante
2. La nueva configuración DNS es automáticamente distribuida a todos los dispositivos internos vía DHCP — portátiles, teléfonos, todo en la red
3. Cuando un usuario consulta un dominio relacionado con autenticación, el servidor DNS malicioso devuelve la IP del atacante en lugar de la real
4. El usuario es redirigido a un proxy adversario intermediario (AitM)
5. El proxy pasa las solicitudes al servicio legítimo — mientras recopila silenciosamente contraseñas y tokens OAuth en el punto intermedio
6. La única advertencia visible para la víctima: un error de certificado TLS, fácilmente ignorado

El enfoque requirió mínima interacción del usuario final y casi no dejó rastro visible. Black Lotus Labs lo describió como «todo thriller, sin relleno de malware».

Cómo evolucionó la campaña

La actividad más temprana fue limitada y comenzó en mayo de 2025. El punto de inflexión llegó el 5 de agosto de 2025, cuando el NCSC publicó su informe Authentic Antics describiendo un conjunto de herramientas de Forest Blizzard para robar credenciales de Microsoft Office. Lumen detectó explotación generalizada de routers y redirección DNS comenzando el día siguiente (6 de agosto), confirmando una rápida adaptación de técnicas después de la exposición pública.

Este patrón es consistente con la historia más amplia de Forest Blizzard. El grupo ha evolucionado continuamente sus métodos de robo de credenciales desde al menos 2021: desde fuerza bruta con password spraying contra servicios de Microsoft, a recolección de hashes NTLM vía routers comprometidos, hasta infraestructura AitM completa. El grupo también es conocido por desplegar la herramienta basada en LLM «LAMEHUG» junto con técnicas más tradicionales.

Cómo se organizó la infraestructura

Black Lotus Labs identificó dos clústeres operacionales distintos:

• Equipo de expansión — enfocado en comprometer nuevos routers SOHO y hacer crecer la botnet a escala, apuntando a un gran conjunto de equipos de red vía interfaces web expuestas
• Clúster AitM — manejó la recopilación de credenciales y tokens; también realizó operaciones interactivas contra routers MikroTik específicos

El secuestro DNS fue oportunista por diseño: lanzar una red amplia, luego filtrar el tráfico interceptado para clasificar víctimas de probable valor de inteligencia en cada etapa de la cadena.

Objetivos y alcance

La campaña apuntó principalmente a agencias gubernamentales, ministerios de asuntos exteriores, cuerpos policiales, proveedores de TI y hosting, y organizaciones que ejecutan servidores de correo on-premise. Microsoft confirmó ataques AitM contra subdominios de Microsoft 365, incluyendo Outlook en la web. Black Lotus Labs y el NCSC también observaron ataques dirigidos a organizaciones gubernamentales en el norte de África, América Central y el sudeste asiático, incluyendo «una plataforma de identidad nacional en un país europeo».

El desmantelamiento

El FBI llevó a cabo una operación técnica autorizada por tribunal, restableciendo remotamente las configuraciones DNS en routers comprometidos para apuntar de nuevo a resolvers legítimos. La operación fue probada extensivamente en firmware TP-Link afectado para asegurar que no impactara la funcionalidad normal del router ni recopilara datos de usuarios.

Lumen bloqueó el tráfico hacia la infraestructura afectada y añadió indicadores de compromiso en Lumen Defender. Los routers pueden limpiarse completamente restaurando la configuración de fábrica. TP-Link confirmó el alcance en una declaración oficial:

«TP-Link ha realizado una revisión interna e identificado que múltiples productos legacy de TP-Link pueden estar afectados por esta vulnerabilidad. Excepto TL-WR940N v6 (EOS desde 2024), todos los productos afectados han alcanzado el estado de fin de vida (EOL) y ya no están dentro del ciclo de mantenimiento estándar de TP-Link.»

En la práctica, esto significa que no vendrán parches — el reemplazo es la única vía de remediación para el hardware afectado.

Qué hacer

Acciones prioritarias para equipos de red y seguridad:

• Reemplace cualquier router que ya no reciba actualizaciones de firmware — el hardware en fin de vida fue el punto de entrada principal
• Verifique la configuración del resolver DNS en su router y compárela con valores conocidos buenos de su ISP
• Implemente certificate pinning en dispositivos corporativos gestionados vía MDM — esto genera un error cuando un proxy AitM intenta inspeccionar el tráfico
• Revise las reglas del firewall para prevenir la exposición no deseada de interfaces de gestión remota
• Monitoree los logs de inicio de sesión de Microsoft Entra para patrones anómalos de uso de tokens OAuth

Phishing con IA de Storm-2372: evasión masiva de MFA vía Device Code

Microsoft documentó una campaña de phishing a gran escala por Storm-2372 que eludió MFA sin robar una sola contraseña. El ataque abusó del flujo de autenticación OAuth Device Code — un mecanismo legítimo diseñado para dispositivos que no pueden soportar inicios de sesión interactivos — para engañar a los usuarios y que autorizaran sesiones controladas por atacantes. La campaña fue impulsada por EvilTokens, un toolkit de phishing como servicio que automatizó toda la operación de principio a fin.

Cómo funcionó

El ataque se desarrolló en tres fases:

• Reconocimiento: 10–15 días antes del phishing, el grupo verificó la validez de las cuentas objetivo vía el endpoint GetCredentialType de Microsoft.
• Entrega: la IA generativa produjo correos señuelo hiperpersonalizados adaptados al rol de cada objetivo — RFPs para personal de compras, facturas para equipos de finanzas, notificaciones de flujo de trabajo de fabricación para operaciones. Las cadenas de redirección pasaron por Vercel, Cloudflare Workers y AWS Lambda para mezclarse con el tráfico empresarial legítimo.
• Captura de tokens: cuando una víctima hacía clic en el enlace, un script en segundo plano generaba un Device Code en vivo en tiempo real — evitando la ventana de expiración estándar de 15 minutos. La víctima completaba MFA en la página de inicio de sesión real de Microsoft, autorizando sin saberlo la sesión del atacante.

La actividad post-compromiso se centró en objetivos de alto valor: exfiltración de correo electrónico, reglas de bandeja de entrada maliciosas para persistencia, y reconocimiento de Microsoft Graph para mapear la estructura organizacional y los permisos.

Objetivos y alcance

La campaña apuntó a organizaciones en los sectores gubernamental, financiero, manufacturero y de TI. La actividad post-compromiso no fue indiscriminada: los actores de amenazas usaron enriquecimiento automatizado — cruzando referencias de perfiles públicos y directorios corporativos — para clasificar cuentas comprometidas y priorizar individuos en roles financieros o ejecutivos para una explotación más profunda.

Actividad post-compromiso

Una vez obtenidos los tokens, los atacantes se enfocaron en mantener el acceso y extraer datos. Esto incluyó exfiltración de correo electrónico, creación de reglas de bandeja de entrada maliciosas para redirigir u ocultar comunicaciones, y reconocimiento de Microsoft Graph para mapear la estructura organizacional y los permisos — permitiendo movimiento lateral mientras los tokens robados permanecieran válidos.

Qué hacer

• Deshabilite el flujo Device Code para usuarios y aplicaciones que no lo requieran vía políticas de Acceso Condicional
• Monitoree consultas anómalas al endpoint GetCredentialType y patrones inusuales de emisión de tokens
• Implemente políticas de vida útil de tokens y evaluación de acceso continuo para limitar las ventanas de validez de tokens robados
• Trate los señuelos personalizados por IA específicos por rol como un vector de amenaza documentado — la capacitación de concienciación genérica es insuficiente

Filtración de tokens de Anodot: Vimeo, Zara y docenas más afectados en la campaña de ShinyHunters

Más de una docena de empresas sufrieron robo de datos después de que tokens de autenticación fueran robados de Anodot, un proveedor de análisis basado en IA adquirido por Glassbox en noviembre de 2025. La mayoría de los ataques apuntaron a entornos de clientes de Snowflake. Entre las víctimas confirmadas: Vimeo (119.000 usuarios afectados) y la empresa matriz de Zara, Inditex (197.000 registros expuestos). La plataforma Snowflake en sí no fue vulnerada — el ataque se ejecutó completamente a través de la capa de integración de terceros.

Qué ocurrió

Anodot proporciona detección de anomalías en tiempo real para datos comerciales y operacionales, integrándose directamente con Snowflake, S3, Amazon Kinesis y otras plataformas. Para funcionar, almacena tokens de autenticación en nombre de sus clientes. Cuando el entorno de Anodot fue vulnerado, esos tokens almacenados dieron a los atacantes acceso directo a los datos de clientes downstream — no se requirió ninguna vulnerabilidad en Snowflake en sí.

El grupo de extorsión ShinyHunters se atribuyó la responsabilidad, diciendo a BleepingComputer que robaron datos de docenas de empresas en un solo viernes usando tokens recolectados de Anodot. El grupo también insinuó que podrían haber tenido acceso a Anodot durante algún tiempo antes de actuar. ShinyHunters posteriormente intentó usar los mismos tokens robados contra cuentas de clientes de Salesforce — pero fue detectado y bloqueado por detección basada en IA antes de tener éxito.

Snowflake respondió bloqueando cuentas de clientes potencialmente impactadas y notificando a las organizaciones afectadas. La página de estado de Anodot mostró todos los conectores caídos en todas las regiones geográficas desde el fin de semana del incidente. Ni Anodot ni su empresa matriz Glassbox respondieron a las consultas de prensa al momento de la publicación.

Víctimas confirmadas

Vimeo confirmó que la brecha de Anodot expuso datos de usuarios y clientes — principalmente datos técnicos, títulos de videos, metadatos, y en algunos casos direcciones de correo electrónico. En su divulgación oficial, Vimeo declaró:

«Los datos accedidos no incluyen contenido de video de Vimeo, credenciales de inicio de sesión de usuario válidas, ni información de tarjetas de pago. Las credenciales de inicio de sesión de usuarios y clientes de Vimeo están seguras. Al enterarnos del incidente, deshabilitamos rápidamente todas las credenciales de Anodot, eliminamos la integración de Anodot con los sistemas de Vimeo, y contratamos expertos en seguridad externos para asistir con la investigación.»

Según Have I Been Pwned, 119.200 direcciones de correo electrónico únicas fueron expuestas, a veces acompañadas de nombres. ShinyHunters publicó cientos de gigabytes de datos de Vimeo después de listar a la empresa en su portal de extorsión «paga o filtramos».

Zara (Inditex) también fue listada por ShinyHunters como parte de la misma campaña. El grupo publicó lo que afirmó ser un terabyte de datos, supuestamente incluyendo 95 millones de registros de tickets de soporte. Have I Been Pwned registró 197.400 direcciones de correo electrónico únicas en la brecha, junto con SKUs de productos, IDs de pedidos y datos de mercado geográfico. Inditex confirmó el incidente pero declaró que no afectó contraseñas ni información de pago.

Por qué importa

Este incidente es un riesgo estructural, no un evento aislado. Las integraciones SaaS-a-SaaS rutinariamente involucran delegación de credenciales: un servicio se autentica en nombre de otro, almacenando tokens de larga duración con amplios permisos. Esa autorización se otorga una vez y raramente se revisa. Cuando el servicio delegado es comprometido, cada conexión downstream que mantiene se convierte en un vector de ataque — y la plataforma principal no tiene visibilidad ni control sobre la brecha.

El playbook de ShinyHunters es consistente: identificar un servicio de integración periférico, comprometerlo, extraer tokens almacenados y monetizar el acceso a través de extorsión antes de que las víctimas puedan responder.

Qué hacer

• Mantenga un inventario actualizado de todas las integraciones SaaS de terceros y las credenciales que mantienen en su nombre
• Aplique alcance de mínimo privilegio a todas las concesiones OAuth y tokens API emitidos a servicios externos
• Establezca políticas de expiración de tokens — evite tokens de larga duración indefinida para integraciones de terceros
• Realice revisiones periódicas de acceso y revoque autorizaciones para servicios que ya no estén en uso activo
• Trate la postura de seguridad del proveedor de integración como parte de su proceso de evaluación de riesgo de proveedores

Las integraciones de terceros no revisadas y los tokens de larga duración son un riesgo estructural, no un caso extremo. Passwork proporciona a los equipos de seguridad un inventario centralizado de credenciales con acceso basado en roles y un registro de auditoría completo — para que nada persista sin ser notado. Vea cómo funciona

Vercel: ataque a la cadena de suministro vía OAuth y Lumma Stealer

Un empleado de Vercel usó Context.ai — una herramienta de productividad con IA de terceros — conectada a su cuenta corporativa de Google Workspace vía OAuth. Cuando Context.ai fue comprometido, los atacantes heredaron ese acceso OAuth, tomaron control de la cuenta de Vercel del empleado y pivotaron hacia los sistemas de producción.

Variables de entorno no sensibles — claves API, tokens, credenciales de bases de datos, claves de firma — fueron enumeradas y descifradas. Vercel contrató a Google Mandiant para la investigación forense y describió a los atacantes como «altamente sofisticados basándose en su velocidad operacional y profundo entendimiento de la superficie API del producto de Vercel».

Qué ocurrió

Trend Micro identificó a Lumma Stealer como el infostealer usado en el compromiso inicial de Context.ai. Lumma es una herramienta de malware como servicio común que extrae credenciales almacenadas en navegadores, cookies de sesión y tokens de autenticación de máquinas infectadas. Un dispositivo de desarrollador infectado en un pequeño proveedor de IA se convirtió en el punto de entrada para una brecha de datos de 2 millones de dólares en una importante plataforma en la nube.

Vercel confirmó que las variables de entorno secretas — aquellas explícitamente marcadas como sensibles — estaban almacenadas cifradas y no fueron comprometidas. Las variables no secretas fueron expuestas. La empresa describió a los atacantes como «altamente organizados» y contrató a Mandiant para la investigación forense.

«Hemos identificado un incidente de seguridad que involucró acceso no autorizado a ciertos sistemas internos de Vercel. Estamos investigando activamente y hemos contratado expertos en respuesta a incidentes para ayudar a investigar y remediar.» — Declaración oficial de Vercel

Por qué importa

Las concesiones OAuth son fáciles de crear y raramente se revisan. Cuando un empleado conecta una herramienta de terceros a una cuenta corporativa, típicamente otorga amplios permisos con un solo clic — y esa autorización persiste indefinidamente a menos que se revoque explícitamente. Cada aplicación conectada es un punto de pivote potencial si esa aplicación es alguna vez comprometida.

La cadena de ataque aquí no requirió ningún zero-day, ningún phishing directo a un empleado de Vercel, y ninguna vulnerabilidad en el código propio de Vercel. Un infostealer común en la máquina de un desarrollador en un proveedor periférico fue suficiente.

Qué hacer

• Audite todas las aplicaciones OAuth conectadas a cuentas corporativas de Google Workspace y Microsoft 365
• Aplique políticas que restrinjan qué aplicaciones de terceros pueden autorizar los empleados
• Marque todas las variables de entorno sensibles explícitamente — y trate las variables no marcadas como potencialmente expuestas
• Despliegue detección de endpoints capaz de identificar actividad de infostealers antes de que ocurra la exfiltración de credenciales
• Rote todas las variables de entorno no sensibles como precaución si la aplicación OAuth de Context.ai estaba presente en su entorno

Bitwarden CLI comprometido en el ataque a la cadena de suministro de Checkmarx

22 de abril de 2026. El paquete Bitwarden CLI @bitwarden/cli@2026.4.0 fue distribuido con código malicioso durante 94 minutos — entre las 5:57 PM y las 7:30 PM ET — vía una GitHub Action secuestrada en el pipeline CI/CD de Bitwarden. El compromiso es parte de la campaña más amplia de cadena de suministro de Checkmarx, atribuida al actor de amenazas TeamPCP. Bitwarden confirmó el incidente y declaró que no se accedió a datos de bóvedas de usuarios finales.

Qué hizo el código malicioso

El código inyectado se ejecutó vía un hook de preinstalación y apuntó a credenciales en múltiples superficies: archivos de entorno locales e historial de shell, secretos de GitHub Actions, credenciales de pipelines CI/CD, archivos de configuración para herramientas de codificación con IA (Claude, Cursor, Codex CLI, Aider, Kiro) y tokens npm. Los datos robados fueron cifrados con AES-256-GCM y exfiltrados a audit.checkmarx[.]cx — un dominio que suplantaba a Checkmarx — con un repositorio de GitHub como respaldo.

Si se encontraban tokens de GitHub, el malware inyectaba flujos de trabajo de Actions maliciosos en cada repositorio accesible y usaba credenciales npm recolectadas para publicar más versiones de paquetes maliciosos downstream. Endor Labs lo describió como uno de los «payloads de cadena de suministro npm más capaces» publicados hasta la fecha.

Qué hacer

• Fije todas las dependencias CI/CD — GitHub Actions, paquetes npm, imágenes Docker — a hashes de commit específicos verificados
• Implemente verificación de integridad de dependencias (checksums, firmas Sigstore) antes de la instalación
• Restrinja los permisos del pipeline CI/CD al alcance mínimo requerido
• Si el paquete fue instalado durante la ventana afectada, rote todos los secretos accesibles desde ese entorno inmediatamente

GitGuardian: los agentes de IA llevaron a la filtración de 29 millones de secretos

El informe State of Secrets Sprawl 2026 de GitGuardian encontró 28.649.024 nuevos secretos expuestos en repositorios públicos de GitHub en 2025 — un aumento del 34% interanual y el mayor salto anual en la historia del informe. El principal impulsor: el desarrollo asistido por IA.

Por qué la IA empeora esto

Los asistentes de IA aceleran el desarrollo hasta el punto en que el código parece listo para producción — y se hace commit — antes de que nadie haya decidido dónde deben vivir las credenciales. Los commits coautorados por Claude Code filtran secretos aproximadamente al doble de la tasa base en GitHub público. Una superficie de riesgo separada emergió con los archivos de configuración MCP: GitGuardian encontró 24.008 secretos únicos expuestos en configuraciones de Model Context Protocol en 2025.

Cifras clave

Una vez que un secreto es cometido a un repositorio público, es efectivamente público — independientemente de si luego se elimina. Los escáneres automatizados recolectan secretos recién cometidos en minutos después de la publicación.

Qué hacer

• Implemente hooks pre-commit y escaneo de secretos CI/CD para capturar credenciales antes de que lleguen a los repositorios
• Aplique herramientas dedicadas de gestión de secretos (HashiCorp Vault, AWS Secrets Manager) como el único mecanismo de almacenamiento de credenciales permitido
• Rote cualquier credencial que alguna vez haya aparecido en un repositorio público, independientemente de cuán brevemente
• Establezca políticas de gobernanza de credenciales específicamente para integraciones de agentes de IA — trate las identidades de agentes como objetos de gestión de acceso de primera clase

Qué tienen en común los incidentes de abril

Tres patrones se repiten en cada incidente de este mes:

• El objetivo principal raramente fue la víctima final — los atacantes se movieron a través de un proveedor periférico, una aplicación OAuth de terceros o una dependencia CI/CD comprometida para alcanzar el objetivo real.
• MFA proporcionó menos protección de lo asumido — tanto la campaña Device Code como las cadenas de robo de tokens OAuth lo eludieron completamente sin tocar una contraseña.
• La IA aceleró la velocidad del atacante en ambos lados — la IA generativa personalizó el phishing a escala mientras el desarrollo asistido por IA creó un volumen récord de credenciales expuestas.

Abril de 2026 en números: el mes en ciberseguridad

Abril de 2026 continuó la trayectoria establecida a principios de año — más incidentes, mayor impacto, y cadenas de ataque que cada vez más evaden los controles tradicionales. El ransomware, el robo de credenciales y el compromiso de la cadena de suministro dominaron el panorama de amenazas en todos los sectores.

Volumen de brechas y ataques

Exposición de credenciales y secretos

Técnicas de ataque en foco

Conclusión

Abril de 2026 confirmó un cambio que se ha estado gestando durante años: la capa de autenticación es la superficie de ataque principal, y los tokens de sesión son el objetivo principal.

APT28 secuestró 18.000 routers para interceptar tokens OAuth sin tocar jamás una contraseña. Storm-2372 eludió MFA a escala usando un flujo de autenticación legítimo. ShinyHunters extrajo tokens almacenados de un proveedor de análisis externo y monetizó el acceso a través de docenas de plataformas downstream — ninguna de las cuales fue comprometida directamente. Un infostealer común en la máquina de un solo desarrollador en un proveedor periférico fue suficiente para alcanzar el entorno de producción de Vercel.

Los 28,6 millones de secretos expuestos en GitHub, las campañas de robo de tokens ejecutadas por APT28 y Storm-2372, y la brecha de Anodot que afectó a docenas de plataformas downstream apuntan a la misma brecha estructural: la gestión de acceso construida para un entorno más simple no está siguiendo el ritmo de cómo las organizaciones realmente operan hoy.

Proteger credenciales ahora significa gobernar todo el ciclo de vida — emisión, rotación, delegación y revocación — a través de usuarios humanos, cuentas de servicio, claves API e identidades de agentes de IA. El shadow IT, las concesiones OAuth no revisadas y los secretos codificados en pipelines CI/CD son la superficie de ataque. El perímetro no lo es.

Los incidentes en este resumen comparten una brecha estructural: credenciales y tokens que existían fuera de la gobernanza — no revisados, no rotados, no revocados. Passwork proporciona una bóveda autoalojada con control de acceso basado en roles, permisos estructurados y un registro de auditoría completo. Pruebe Passwork en su infraestructura

Preguntas frecuentes

¿Cuál fue la amenaza de ciberseguridad más significativa en abril de 2026?

La campaña FrostArmada de APT28 fue el incidente operacionalmente más significativo del mes. Al secuestrar la configuración DNS en más de 18.000 routers SOHO sin parchar en 120 países, el grupo vinculado al GRU ruso interceptó silenciosamente credenciales de Microsoft 365 y tokens OAuth de agencias gubernamentales, cuerpos policiales y proveedores de TI — eludiendo MFA sin desplegar malware ni hacer phishing directo a usuarios individuales.

¿Cómo elude el robo de tokens OAuth a MFA?

Los tokens OAuth se emiten después de que un usuario ya ha completado la autenticación — incluyendo cualquier paso de MFA. Robar el token significa heredar una sesión completamente autenticada. MFA protege el proceso de inicio de sesión; no protege el token que resulta de él. Los atacantes que interceptan o roban tokens se saltan el proceso de inicio de sesión por completo, haciendo que MFA sea irrelevante en esa etapa.

¿Qué es la técnica de phishing Device Code usada por Storm-2372?

El phishing Device Code abusa de un flujo OAuth legítimo diseñado para dispositivos con entrada limitada. Los atacantes inician el flujo, luego entregan el código resultante a las víctimas vía correos de phishing personalizados con IA. Cuando la víctima ingresa el código en la página de autenticación real de Microsoft, sin saberlo autoriza la sesión del atacante — emitiendo un token de acceso válido sin exponer su contraseña ni activar ningún desafío MFA. El token es legítimo porque el usuario completó la autenticación él mismo.

¿Por qué fue significativo el ataque a la cadena de suministro de Bitwarden CLI?

Demostró que las herramientas de seguridad llevan el mismo riesgo de cadena de suministro que cualquier otra dependencia de software. Una versión maliciosa de Bitwarden CLI fue distribuida vía npm durante 94 minutos después de que los atacantes secuestraran una GitHub Action en el pipeline CI/CD. El código inyectado apuntó a secretos de desarrolladores, credenciales en la nube y tokens de pipelines — y fue construido para auto-propagarse a cada repositorio que el token de GitHub de la víctima pudiera alcanzar.

¿Qué es la dispersión de credenciales y por qué se está acelerando?

La dispersión de credenciales se refiere a la proliferación descontrolada de secretos — claves API, tokens, contraseñas, certificados — a través de repositorios, archivos de configuración, herramientas de colaboración y pipelines CI/CD. El informe State of Secrets Sprawl 2026 de GitGuardian encontró 28,6 millones de nuevos secretos expuestos en repositorios públicos de GitHub en 2025, un aumento del 34% interanual impulsado en gran parte por el desarrollo asistido por IA. El código llega a producción más rápido de lo que las políticas de gobernanza de credenciales pueden seguir el ritmo — y el 64% de los secretos expuestos en 2022 permanecían activos y explotables en 2026.

Dentro de ataques reales a la cadena de suministro: Bitwarden CLI, Axios y Vercel

¿Por qué vulnerar su red cuando los atacantes pueden comprometer una dependencia de confianza con millones de descargas y deslizarse silenciosamente en miles de organizaciones a la vez? Tres campañas de 2026 prueban que los ataques a la cadena de suministro ya no son incidentes aislados.

Passwork BlogAlex Muntyan

Ataques de fuerza bruta en 2026: tipos, ejemplos y cómo prevenirlos

Clústeres GPU, listas de palabras asistidas por IA, botnets de 2,8M de dispositivos. La fuerza bruta ha escalado. Esta guía cubre seis variantes de ataque, casos reales de 2025 y una estrategia de defensa en capas que su equipo puede implementar hoy.

Passwork BlogAlex Muntyan

Caos de contraseñas: por qué es un problema empresarial y cómo solucionarlo

Una contraseña olvidada cuesta 70 dólares. Una brecha cuesta 4,44 millones de dólares. Ambas comienzan de la misma manera — credenciales compartidas por Slack, almacenadas en hojas de cálculo, nunca rotadas. Esto es lo que realmente cuesta el caos de contraseñas y cómo eliminarlo.

Passwork BlogAlex Muntyan

Im April 2026 geschahen drei Dinge, die zunächst unzusammenhängend erscheinen — bis man das Muster erkennt.

APT28 kaperte 18.000 Router in 120 Ländern und leitete Authentifizierungsverkehr über einen Adversary-in-the-Middle-Proxy um. Keine Malware. Nur eine TLS-Zertifikatswarnung, die die meisten Benutzer ignorierten. Microsoft 365-Zugangsdaten und OAuth-Tokens wurden am Mittelpunkt abgegriffen, MFA wurde vollständig umgangen.

Ein Entwickler bei einem KI-Produktivitäts-Startup wurde von einem handelsüblichen Infostealer infiziert. Die Malware kostete etwa 200 $ in einem Darknet-Forum. Sie extrahierte ein im Browser gespeichertes OAuth-Token, übergab es den Angreifern, und innerhalb weniger Stunden befanden sie sich in Vercels Produktionsumgebung — wo sie API-Keys, Datenbank-Zugangsdaten und Signaturschlüssel auflisteten.

ShinyHunters erbeutete Authentifizierungstokens von einem Drittanbieter für Analysen namens Anodot und verbrachte den Tag damit, den Zugang zu Dutzenden von nachgelagerten Plattformen zu monetarisieren. Vimeo. Zara. Snowflake-Kunden. Keine der primären Plattformen wurde direkt kompromittiert. Der Angriff lief vollständig über die Integrationsschicht.

Der gemeinsame Nenner: Der Angriff begann nie dort, wo der Schaden entstand. Jeder Angreifer drang über eine Peripherie ein — einen Anbieter, eine Integration, ein vergessenes Gerät — und bewegte sich von dort zum eigentlichen Ziel.

Dieser Digest behandelt die Zugangsdaten- und Authentifizierungsvorfälle, die den April 2026 prägten, die Statistiken, die ihnen Kontext geben, und was sie gemeinsam für das Zugriffsmanagement in Organisationen bedeuten.

Wichtigste Erkenntnisse

• APT28 kaperte 18.000 Router in 120 Ländern, um Microsoft 365 OAuth-Tokens zu stehlen. Die FrostArmada-Kampagne erforderte keine Malware und hinterließ kaum sichtbare Spuren — DNS-Einstellungen wurden stillschweigend überschrieben, um Authentifizierungsverkehr über einen Adversary-in-the-Middle-Proxy umzuleiten. MFA wurde vollständig umgangen. Das FBI zerschlug die Infrastruktur im April 2026.
• Storm-2372 umging MFA im großen Stil, ohne ein einziges Passwort zu stehlen. Die Kampagne missbrauchte den OAuth Device Code-Flow und nutzte KI-generierte rollenspezifische Köder, um Opfer dazu zu bringen, von Angreifern kontrollierte Sitzungen zu autorisieren. Das Toolkit (EvilTokens) automatisierte den gesamten Vorgang von Anfang bis Ende.
• Der Anodot-Vorfall legte gespeicherte Tokens für Dutzende nachgelagerter Plattformen offen. ShinyHunters extrahierte Authentifizierungstokens von einem Drittanbieter für Analysen und nutzte sie, um auf Kundendaten bei Vimeo (119.000 Benutzer) und Zara/Inditex (197.000 Datensätze) zuzugreifen. Snowflake wurde nicht kompromittiert — der Angriff lief vollständig über die Integrationsschicht.
• Ein handelsüblicher Infostealer auf dem Gerät eines einzigen Entwicklers reichte aus, um in Vercels Produktionsumgebung einzudringen. Lumma Stealer kompromittierte Context.ai, einen peripheren KI-Anbieter. Geerbter OAuth-Zugriff verschaffte Angreifern direkten Zugang zu Vercel-Systemen — kein Zero-Day, kein Phishing von Vercel-Mitarbeitern erforderlich.
• Ein bösartiges Bitwarden CLI-Paket zirkulierte 94 Minuten lang über npm. Angreifer kaperten eine GitHub Action in der CI/CD-Pipeline und injizierten eine Payload, die auf Entwickler-Secrets, Cloud-Zugangsdaten und KI-Coding-Tool-Konfigurationen abzielte — mit eingebauter Selbstverbreitung über erreichbare Repositories.
• KI-unterstützte Entwicklung führte zu einem Rekord von 28,6 Millionen geleakten Secrets im Jahr 2025 — ein Anstieg von 34 % im Jahresvergleich. Leaks von KI-Service-Zugangsdaten wuchsen um 81 %. Commits, die mit KI-Tools erstellt wurden, leaken Secrets mit etwa der doppelten Basisrate. 64 % der 2022 exponierten Secrets waren 2026 noch aktiv und ausnutzbar.
• Jeder größere Vorfall in diesem Monat folgte demselben Muster. Das primäre Ziel war nie das endgültige Opfer — Angreifer bewegten sich über einen peripheren Anbieter, ein gespeichertes Token oder eine kompromittierte Abhängigkeit zum eigentlichen Ziel. MFA stoppte keine der Zugangsdatendiebstahl-Kampagnen. Die Angriffsfläche ist die Integrationsschicht, die CI/CD-Pipeline und der OAuth-Grant.

APT28: DNS-Hijacking-Kampagne FrostArmada von internationalen Behörden zerschlagen

Eine internationale Strafverfolgungsoperation unter Beteiligung des FBI, des US-Justizministeriums und der polnischen Regierung, mit technischer Unterstützung von Microsoft und Black Lotus Labs, zerschlug FrostArmada: eine APT28-Kampagne, die Router-DNS-Einstellungen kaperte, um Microsoft 365-Zugangsdaten und OAuth-Tokens zu stehlen. Aktiv seit Mai 2025, infizierte die Kampagne auf ihrem Höhepunkt im Dezember 2025 18.000 Geräte in 120 Ländern.

Was geschah

APT28 (auch bekannt als Fancy Bear, Forest Blizzard, Strontium und Storm-2754) — vom NCSC und dem US-Justizministerium der russischen GRU-Militäreinheit 26165 zugeschrieben — kompromittierte internetexponierte SOHO-Router durch Ausnutzung bekannter öffentlicher Schwachstellen. Das primäre Ziel war der TP-Link WR841N über CVE-2023-50224, das es nicht authentifizierten Angreifern ermöglichte, Router-Zugangsdaten über eine manipulierte HTTP-GET-Anfrage zu extrahieren und dann DHCP/DNS-Einstellungen mit einer zweiten Anfrage zu überschreiben.

Die Angriffskette funktionierte wie folgt:

1. Router wird über eine bekannte Schwachstelle kompromittiert; DNS-Einstellungen werden überschrieben, um auf von Angreifern kontrollierte VPS-Knoten zu verweisen
2. Neue DNS-Konfiguration wird automatisch über DHCP an alle internen Geräte verteilt — Laptops, Telefone, alles im Netzwerk
3. Wenn ein Benutzer eine authentifizierungsbezogene Domain abfragt, gibt der bösartige DNS-Server die IP des Angreifers statt der echten zurück
4. Benutzer wird zu einem Adversary-in-the-Middle (AitM)-Proxy umgeleitet
5. Der Proxy leitet Anfragen an den legitimen Dienst weiter — während er stillschweigend Passwörter und OAuth-Tokens am Mittelpunkt sammelt
6. Die einzige sichtbare Warnung für das Opfer: ein TLS-Zertifikatsfehler, der leicht ignoriert werden kann

Der Ansatz erforderte minimale Endbenutzer-Interaktion und hinterließ fast keine sichtbare Spur. Black Lotus Labs beschrieb es als „all thriller, no malware filler".

Wie sich die Kampagne entwickelte

Die früheste Aktivität war begrenzt und begann im Mai 2025. Der Wendepunkt kam am 5. August 2025, als das NCSC seinen Authentic Antics-Bericht veröffentlichte, der ein Forest Blizzard-Toolset zum Stehlen von Microsoft Office-Zugangsdaten beschrieb. Lumen erkannte ab dem nächsten Tag (6. August) weit verbreitete Router-Ausnutzung und DNS-Umleitung, was eine schnelle Anpassung der Taktiken nach der öffentlichen Enthüllung bestätigte.

Dieses Muster ist konsistent mit der breiteren Geschichte von Forest Blizzard. Die Gruppe hat ihre Methoden zum Diebstahl von Zugangsdaten seit mindestens 2021 kontinuierlich weiterentwickelt: von Brute-Force-Passwort-Spraying gegen Microsoft-Dienste über NTLM-Hash-Harvesting über kompromittierte Router bis hin zu vollständiger AitM-Infrastruktur. Die Gruppe ist auch dafür bekannt, das LLM-basierte Tool „LAMEHUG" neben traditionelleren Techniken einzusetzen.

Wie die Infrastruktur organisiert war

Black Lotus Labs identifizierte zwei unterschiedliche operative Cluster:

• Expansionsteam — konzentrierte sich auf die Kompromittierung neuer SOHO-Router und das Wachstum des Botnets im großen Maßstab, wobei ein großer Pool von Netzwerkgeräten über exponierte Weboberflächen anvisiert wurde
• AitM-Cluster — übernahm die Sammlung von Zugangsdaten und Tokens; führte auch interaktive Operationen gegen bestimmte MikroTik-Router durch

Das DNS-Hijacking war von vornherein opportunistisch angelegt: ein weites Netz auswerfen und dann den abgefangenen Verkehr filtern, um Opfer von wahrscheinlichem Geheimdienstwert in jeder Phase der Kette zu priorisieren.

Ziele und Umfang

Die Kampagne zielte hauptsächlich auf Regierungsbehörden, Außenministerien, Strafverfolgungsbehörden, IT- und Hosting-Anbieter sowie Organisationen mit On-Premise-E-Mail-Servern. Microsoft bestätigte AitM-Angriffe gegen Microsoft 365-Subdomains, einschließlich Outlook im Web. Black Lotus Labs und das NCSC beobachteten auch Angriffe auf Regierungsorganisationen in Nordafrika, Zentralamerika und Südostasien, darunter „eine nationale Identitätsplattform in einem europäischen Land".

Die Zerschlagung

Das FBI führte eine gerichtlich genehmigte technische Operation durch und setzte die DNS-Konfigurationen auf kompromittierten Routern aus der Ferne zurück, um wieder auf legitime Resolver zu verweisen. Die Operation wurde ausgiebig auf betroffener TP-Link-Firmware getestet, um sicherzustellen, dass sie die normale Router-Funktionalität nicht beeinträchtigt oder Benutzerdaten sammelt.

Lumen blockierte den Verkehr zur betroffenen Infrastruktur und fügte Kompromittierungsindikatoren in Lumen Defender hinzu. Router können durch Wiederherstellen der Werkseinstellungen vollständig bereinigt werden. TP-Link bestätigte den Umfang in einer offiziellen Erklärung:

„TP-Link hat eine interne Überprüfung durchgeführt und festgestellt, dass mehrere ältere TP-Link-Produkte von dieser Schwachstelle betroffen sein können. Mit Ausnahme des TL-WR940N v6 (EOS seit 2024) haben alle betroffenen Produkte den End-of-Life (EOL)-Status erreicht und befinden sich nicht mehr im Standard-Wartungslebenszyklus von TP-Link."

In der Praxis bedeutet dies, dass keine Patches kommen werden — der Austausch ist der einzige Behebungsweg für betroffene Hardware.

Was zu tun ist

Prioritätsmaßnahmen für Netzwerk- und Sicherheitsteams:

• Ersetzen Sie alle Router, die keine Firmware-Updates mehr erhalten — End-of-Life-Hardware war der primäre Einstiegspunkt
• Überprüfen Sie die DNS-Resolver-Einstellungen in Ihrer Router-Konfiguration und gleichen Sie diese mit bekannten guten Werten Ihres ISP ab
• Implementieren Sie Certificate Pinning auf Unternehmensgeräten, die über MDM verwaltet werden — dies erzeugt einen Fehler, wenn ein AitM-Proxy versucht, den Verkehr zu inspizieren
• Überprüfen Sie Firewall-Regeln, um eine ungewollte Exposition von Remote-Management-Schnittstellen zu verhindern
• Überwachen Sie Microsoft Entra-Anmeldeprotokolle auf anomale OAuth-Token-Nutzungsmuster

Storm-2372 KI-Phishing: Massiver MFA-Bypass über Device Code

Microsoft dokumentierte eine groß angelegte Phishing-Kampagne von Storm-2372, die MFA umging, ohne ein einziges Passwort zu stehlen. Der Angriff missbrauchte den OAuth Device Code-Authentifizierungsflow — einen legitimen Mechanismus, der für Geräte entwickelt wurde, die keine interaktiven Logins unterstützen können — um Benutzer dazu zu verleiten, von Angreifern kontrollierte Sitzungen zu autorisieren. Die Kampagne wurde von EvilTokens angetrieben, einem Phishing-as-a-Service-Toolkit, das den gesamten Vorgang von Anfang bis Ende automatisierte.

Wie es funktionierte

Der Angriff entfaltete sich in drei Phasen:

• Aufklärung: 10–15 Tage vor dem Phishing überprüfte die Gruppe die Gültigkeit der Zielkonten über Microsofts GetCredentialType-Endpunkt.
• Zustellung: Generative KI produzierte hyperpersonalisierte Köder-E-Mails, die auf die Rolle jedes Ziels zugeschnitten waren — Ausschreibungen für Beschaffungsmitarbeiter, Rechnungen für Finanzteams, Fertigungs-Workflow-Benachrichtigungen für den Betrieb. Umleitungsketten liefen über Vercel, Cloudflare Workers und AWS Lambda, um sich mit legitimem Unternehmensverkehr zu vermischen.
• Token-Erfassung: Wenn ein Opfer auf den Link klickte, generierte ein Hintergrundskript in Echtzeit einen Live-Device-Code — unter Umgehung des standardmäßigen 15-Minuten-Ablaufzeitfensters. Das Opfer schloss MFA auf Microsofts echter Login-Seite ab und autorisierte dabei unwissentlich die Sitzung des Angreifers.

Post-Kompromittierungs-Aktivitäten konzentrierten sich auf hochwertige Ziele: E-Mail-Exfiltration, bösartige Posteingangsregeln zur Persistenz und Microsoft Graph-Aufklärung zur Kartierung der Organisationsstruktur und Berechtigungen.

Ziele und Umfang

Die Kampagne zielte auf Organisationen in den Bereichen Regierung, Finanzen, Fertigung und IT. Post-Kompromittierungs-Aktivitäten waren nicht wahllos: Bedrohungsakteure nutzten automatisierte Anreicherung — Querverweise mit öffentlichen Profilen und Unternehmensverzeichnissen — um kompromittierte Konten zu triagieren und Personen in Finanz- oder Führungspositionen für tiefere Ausnutzung zu priorisieren.

Post-Kompromittierungs-Aktivität

Sobald Tokens erlangt wurden, konzentrierten sich Angreifer auf die Aufrechterhaltung des Zugangs und die Datenextraktion. Dies umfasste E-Mail-Exfiltration, die Erstellung bösartiger Posteingangsregeln zur Umleitung oder Verschleierung von Kommunikation und Microsoft Graph-Aufklärung zur Kartierung der Organisationsstruktur und Berechtigungen — was laterale Bewegung ermöglichte, solange die gestohlenen Tokens gültig blieben.

Was zu tun ist

• Deaktivieren Sie den Device Code-Flow für Benutzer und Anwendungen, die ihn nicht benötigen, über Conditional Access-Richtlinien
• Überwachen Sie anomale GetCredentialType-Endpunktabfragen und ungewöhnliche Token-Ausstellungsmuster
• Implementieren Sie Token-Lebensdauerrichtlinien und kontinuierliche Zugriffsbewertung, um die Gültigkeitszeitfenster gestohlener Tokens zu begrenzen
• Behandeln Sie rollenspezifische KI-personalisierte Köder als dokumentierten Bedrohungsvektor — allgemeine Awareness-Schulungen reichen nicht aus

Anodot-Token-Leak: Vimeo, Zara und Dutzende weitere von ShinyHunters-Kampagne betroffen

Über ein Dutzend Unternehmen erlitten Datendiebstahl, nachdem Authentifizierungstokens von Anodot gestohlen wurden, einem KI-basierten Analyseanbieter, der im November 2025 von Glassbox übernommen wurde. Die Mehrheit der Angriffe zielte auf Snowflake-Kundenumgebungen. Unter den bestätigten Opfern: Vimeo (119.000 betroffene Benutzer) und Zaras Mutterkonzern Inditex (197.000 exponierte Datensätze). Die Snowflake-Plattform selbst wurde nicht kompromittiert — der Angriff lief vollständig über die Drittanbieter-Integrationsschicht.

Was geschah

Anodot bietet Echtzeit-Anomalieerkennung für Geschäfts- und Betriebsdaten und integriert sich direkt mit Snowflake, S3, Amazon Kinesis und anderen Plattformen. Um zu funktionieren, speichert es Authentifizierungstokens im Namen seiner Kunden. Als Anodots Umgebung kompromittiert wurde, verschafften diese gespeicherten Tokens Angreifern direkten Zugang zu nachgelagerten Kundendaten — keine Schwachstelle in Snowflake selbst war erforderlich.

Die ShinyHunters-Erpressergruppe bekannte sich zur Verantwortung und erklärte BleepingComputer, dass sie an einem einzigen Freitag Daten von Dutzenden von Unternehmen gestohlen haben, indem sie von Anodot erbeutete Tokens verwendeten. Die Gruppe deutete auch an, dass sie möglicherweise eine Zeit lang Zugang zu Anodot gehabt hatten, bevor sie handelten. ShinyHunters versuchte anschließend, dieselben gestohlenen Tokens gegen Salesforce-Kundenkonten zu verwenden — wurde jedoch durch KI-basierte Erkennung erkannt und blockiert, bevor sie Erfolg hatten.

Snowflake reagierte, indem es potenziell betroffene Kundenkonten sperrte und betroffene Organisationen benachrichtigte. Anodots Statusseite zeigte alle Konnektoren in allen geografischen Regionen ab dem Wochenende des Vorfalls als ausgefallen an. Weder Anodot noch seine Muttergesellschaft Glassbox reagierten zum Zeitpunkt der Veröffentlichung auf Presseanfragen.

Bestätigte Opfer

Vimeo bestätigte, dass der Anodot-Vorfall Benutzer- und Kundendaten exponierte — hauptsächlich technische Daten, Videotitel, Metadaten und in einigen Fällen E-Mail-Adressen. In seiner offiziellen Offenlegung erklärte Vimeo:

„Die abgerufenen Daten enthalten keine Vimeo-Videoinhalte, gültige Benutzeranmeldedaten oder Zahlungskarteninformationen. Vimeo-Benutzer- und Kundenanmeldedaten sind sicher. Nach Bekanntwerden des Vorfalls haben wir umgehend alle Anodot-Anmeldedaten deaktiviert, die Anodot-Integration mit Vimeo-Systemen entfernt und externe Sicherheitsexperten zur Unterstützung bei der Untersuchung beauftragt."

Laut Have I Been Pwned wurden 119.200 einzigartige E-Mail-Adressen exponiert, manchmal begleitet von Namen. ShinyHunters veröffentlichte Hunderte von Gigabytes an Vimeo-Daten, nachdem sie das Unternehmen auf ihrem „Zahlen-oder-Leak"-Erpressungsportal gelistet hatten.

Zara (Inditex) wurde ebenfalls von ShinyHunters als Teil derselben Kampagne gelistet. Die Gruppe veröffentlichte, was sie als ein Terabyte an Daten bezeichnete, angeblich einschließlich 95 Millionen Support-Ticket-Datensätzen. Have I Been Pwned verzeichnete 197.400 einzigartige E-Mail-Adressen im Datenleck, zusammen mit Produkt-SKUs, Bestell-IDs und geografischen Marktdaten. Inditex bestätigte den Vorfall, erklärte jedoch, dass er keine Passwörter oder Zahlungsinformationen betraf.

Warum das wichtig ist

Dieser Vorfall ist ein strukturelles Risiko, kein einmaliges Ereignis. SaaS-zu-SaaS-Integrationen beinhalten routinemäßig Credential-Delegation: Ein Dienst authentifiziert sich im Namen eines anderen und speichert langlebige Tokens mit umfangreichen Berechtigungen. Diese Autorisierung wird einmal erteilt und selten überprüft. Wenn der delegierte Dienst kompromittiert wird, wird jede nachgelagerte Verbindung, die er hält, zu einem Angriffsvektor — und die primäre Plattform hat keine Sichtbarkeit oder Kontrolle über den Vorfall.

Das ShinyHunters-Playbook ist konsistent: einen peripheren Integrationsdienst identifizieren, ihn kompromittieren, gespeicherte Tokens extrahieren und den Zugang durch Erpressung monetarisieren, bevor Opfer reagieren können.

Was zu tun ist

• Führen Sie ein aktuelles Inventar aller Drittanbieter-SaaS-Integrationen und der Zugangsdaten, die sie in Ihrem Namen halten
• Wenden Sie Least-Privilege-Scoping auf alle OAuth-Grants und API-Tokens an, die an externe Dienste ausgegeben werden
• Legen Sie Token-Ablaufrichtlinien fest — vermeiden Sie unbefristete langlebige Tokens für Drittanbieter-Integrationen
• Führen Sie regelmäßige Zugriffsüberprüfungen durch und widerrufen Sie Autorisierungen für Dienste, die nicht mehr aktiv genutzt werden
• Behandeln Sie die Sicherheitslage von Integrationsanbietern als Teil Ihres Vendor-Risk-Assessment-Prozesses

Ungeprüfte Drittanbieter-Integrationen und langlebige Tokens sind ein strukturelles Risiko, kein Randfall. Passwork bietet Sicherheitsteams ein zentralisiertes Inventar von Zugangsdaten mit rollenbasierter Zugriffskontrolle und einem vollständigen Audit-Trail — damit nichts unbemerkt bestehen bleibt. Erfahren Sie, wie es funktioniert

Vercel: Supply-Chain-Angriff über OAuth und Lumma Stealer

Ein Vercel-Mitarbeiter nutzte Context.ai — ein KI-Produktivitätstool eines Drittanbieters — das über OAuth mit seinem geschäftlichen Google Workspace-Konto verbunden war. Als Context.ai kompromittiert wurde, erbten Angreifer diesen OAuth-Zugriff, übernahmen das Vercel-Konto des Mitarbeiters und drangen in Produktionssysteme ein.

Nicht-sensible Umgebungsvariablen — API-Keys, Tokens, Datenbank-Zugangsdaten, Signaturschlüssel — wurden aufgelistet und entschlüsselt. Vercel beauftragte Google Mandiant für die forensische Untersuchung und beschrieb die Angreifer als „hochentwickelt basierend auf ihrer operativen Geschwindigkeit und ihrem tiefgreifenden Verständnis von Vercels Produkt-API-Oberfläche".

Was geschah

Trend Micro identifizierte Lumma Stealer als den Infostealer, der bei der initialen Kompromittierung von Context.ai verwendet wurde. Lumma ist ein handelsübliches Malware-as-a-Service-Tool, das im Browser gespeicherte Zugangsdaten, Session-Cookies und Authentifizierungstokens von infizierten Maschinen extrahiert. Ein infiziertes Entwicklergerät bei einem kleinen KI-Anbieter wurde zum Einstiegspunkt für einen 2-Millionen-Dollar-Datenvorfall bei einer großen Cloud-Plattform.

Vercel bestätigte, dass geheime Umgebungsvariablen — die explizit als sensibel markiert waren — verschlüsselt gespeichert wurden und nicht kompromittiert wurden. Nicht-geheime Variablen wurden exponiert. Das Unternehmen beschrieb die Angreifer als „hoch organisiert" und beauftragte Mandiant für die forensische Untersuchung.

„Wir haben einen Sicherheitsvorfall identifiziert, der unbefugten Zugriff auf bestimmte interne Vercel-Systeme umfasste. Wir untersuchen aktiv und haben Incident-Response-Experten zur Unterstützung bei Untersuchung und Behebung beauftragt." — Offizielle Stellungnahme von Vercel

Warum das wichtig ist

OAuth-Grants sind leicht zu erstellen und werden selten überprüft. Wenn ein Mitarbeiter ein Drittanbieter-Tool mit einem Unternehmenskonto verbindet, erteilt er typischerweise mit einem einzigen Klick umfangreiche Berechtigungen — und diese Autorisierung besteht unbefristet fort, es sei denn, sie wird explizit widerrufen. Jede verbundene Anwendung ist ein potenzieller Pivot-Punkt, falls diese Anwendung jemals kompromittiert wird.

Die Angriffskette erforderte hier keinen Zero-Day, kein direktes Phishing eines Vercel-Mitarbeiters und keine Schwachstelle in Vercels eigenem Code. Ein handelsüblicher Infostealer auf dem Rechner eines Entwicklers bei einem peripheren Anbieter war ausreichend.

Was zu tun ist

• Überprüfen Sie alle mit geschäftlichen Google Workspace- und Microsoft 365-Konten verbundenen OAuth-Anwendungen
• Setzen Sie Richtlinien durch, die einschränken, welche Drittanbieter-Anwendungen Mitarbeiter autorisieren können
• Markieren Sie alle sensiblen Umgebungsvariablen explizit — und behandeln Sie nicht markierte Variablen als potenziell exponiert
• Setzen Sie Endpunkt-Erkennung ein, die Infostealer-Aktivität vor der Exfiltration von Zugangsdaten identifizieren kann
• Rotieren Sie als Vorsichtsmaßnahme alle nicht-sensiblen Umgebungsvariablen, falls die Context.ai OAuth-App in Ihrer Umgebung vorhanden war

Bitwarden CLI bei Checkmarx Supply-Chain-Angriff kompromittiert

22. April 2026. Das Bitwarden CLI-Paket @bitwarden/cli@2026.4.0 wurde mit bösartigem Code für 94 Minuten verteilt — zwischen 17:57 und 19:30 Uhr ET — über eine gekaperte GitHub Action in Bitwardens CI/CD-Pipeline. Die Kompromittierung ist Teil der breiteren Checkmarx Supply-Chain-Kampagne, die dem Bedrohungsakteur TeamPCP zugeschrieben wird. Bitwarden bestätigte den Vorfall und erklärte, dass keine Endbenutzer-Tresordaten abgerufen wurden.

Was der bösartige Code tat

Der injizierte Code wurde über einen Preinstall-Hook ausgeführt und zielte auf Zugangsdaten über mehrere Oberflächen ab: lokale Umgebungsdateien und Shell-Verlauf, GitHub Actions Secrets, CI/CD-Pipeline-Zugangsdaten, Konfigurationsdateien für KI-Coding-Tools (Claude, Cursor, Codex CLI, Aider, Kiro) und npm-Tokens. Gestohlene Daten wurden mit AES-256-GCM verschlüsselt und an audit.checkmarx[.]cx exfiltriert — eine Domain, die Checkmarx imitierte — mit einem GitHub-Repository als Fallback.

Wenn GitHub-Tokens gefunden wurden, injizierte die Malware bösartige Actions-Workflows in jedes erreichbare Repository und nutzte erbeutete npm-Zugangsdaten, um weitere bösartige Paketversionen nachgelagert zu veröffentlichen. Endor Labs beschrieb es als eine der „leistungsfähigeren npm Supply-Chain-Payloads", die bisher veröffentlicht wurden.

Was zu tun ist

• Pinnen Sie alle CI/CD-Abhängigkeiten — GitHub Actions, npm-Pakete, Docker-Images — auf spezifische verifizierte Commit-Hashes
• Implementieren Sie Abhängigkeitsintegritätsprüfung (Checksummen, Sigstore-Signaturen) vor der Installation
• Beschränken Sie CI/CD-Pipeline-Berechtigungen auf den minimal erforderlichen Umfang
• Wenn das Paket während des betroffenen Zeitfensters installiert wurde, rotieren Sie sofort alle Secrets, die von dieser Umgebung aus zugänglich waren

GitGuardian: KI-Agenten führten zum Leak von 29 Millionen Secrets

GitGuardians State of Secrets Sprawl 2026-Bericht fand 28.649.024 neue Secrets, die 2025 in öffentlichen GitHub-Repositories exponiert wurden — ein Anstieg von 34 % im Jahresvergleich und der größte jährliche Sprung in der Geschichte des Berichts. Der Haupttreiber: KI-unterstützte Entwicklung.

Warum KI das verschlimmert

KI-Assistenten beschleunigen die Entwicklung bis zu dem Punkt, an dem Code produktionsreif aussieht — und committet wird — bevor irgendjemand entschieden hat, wo Zugangsdaten gespeichert werden sollten. Commits, die mit Claude Code erstellt wurden, leaken Secrets mit etwa der doppelten Basisrate in öffentlichem GitHub. Eine separate Risikofläche entstand mit MCP-Konfigurationsdateien: GitGuardian fand 24.008 einzigartige Secrets, die 2025 in Model Context Protocol-Konfigurationen exponiert wurden.

Wichtige Zahlen

Sobald ein Secret in ein öffentliches Repository committet wurde, ist es praktisch öffentlich — unabhängig davon, ob es später gelöscht wird. Automatisierte Scanner ernten neu committete Secrets innerhalb von Minuten nach der Veröffentlichung.

Was zu tun ist

• Implementieren Sie Pre-Commit-Hooks und CI/CD-Secret-Scanning, um Zugangsdaten abzufangen, bevor sie Repositories erreichen
• Erzwingen Sie dedizierte Secrets-Management-Tools (HashiCorp Vault, AWS Secrets Manager) als einzigen erlaubten Mechanismus zur Speicherung von Zugangsdaten
• Rotieren Sie jede Zugangsdaten, die jemals in einem öffentlichen Repository erschienen ist, unabhängig davon, wie kurz
• Etablieren Sie Zugangsdaten-Governance-Richtlinien speziell für KI-Agent-Integrationen — behandeln Sie Agent-Identitäten als erstklassige Zugriffsmanagement-Objekte

Was die Vorfälle im April gemeinsam haben

Drei Muster wiederholen sich in jedem Vorfall dieses Monats:

• Das primäre Ziel war selten das endgültige Opfer — Angreifer bewegten sich über einen peripheren Anbieter, eine Drittanbieter-OAuth-App oder eine kompromittierte CI/CD-Abhängigkeit, um das eigentliche Ziel zu erreichen.
• MFA bot weniger Schutz als angenommen — sowohl die Device-Code-Kampagne als auch die OAuth-Token-Diebstahl-Ketten umgingen sie vollständig, ohne ein Passwort zu berühren.
• KI beschleunigte die Geschwindigkeit der Angreifer auf beiden Seiten — generative KI personalisierte Phishing im großen Maßstab, während KI-unterstützte Entwicklung ein Rekordvolumen an exponierten Zugangsdaten erzeugte.

April 2026 in Zahlen: Der Monat in der Cybersicherheit

Der April 2026 setzte die zu Jahresbeginn etablierte Entwicklung fort — mehr Vorfälle, breitere Auswirkungen und Angriffsketten, die zunehmend traditionelle Kontrollen umgehen. Ransomware, Zugangsdatendiebstahl und Supply-Chain-Kompromittierung dominierten die Bedrohungslandschaft in allen Sektoren.

Umfang von Datenvorfällen und Angriffen

Exposition von Zugangsdaten und Secrets

Angriffstechniken im Fokus

Fazit

Der April 2026 bestätigte eine Verschiebung, die sich seit Jahren aufgebaut hat: Die Authentifizierungsschicht ist die primäre Angriffsfläche, und Session-Tokens sind das primäre Ziel.

APT28 kaperte 18.000 Router, um OAuth-Tokens abzufangen, ohne jemals ein Passwort zu berühren. Storm-2372 umging MFA im großen Maßstab unter Verwendung eines legitimen Authentifizierungsflows. ShinyHunters extrahierte gespeicherte Tokens von einem Drittanbieter für Analysen und monetarisierte den Zugang zu Dutzenden nachgelagerter Plattformen — von denen keine direkt kompromittiert wurde. Ein handelsüblicher Infostealer auf dem Rechner eines einzigen Entwicklers bei einem peripheren Anbieter war ausreichend, um Vercels Produktionsumgebung zu erreichen.

Die 28,6 Millionen auf GitHub exponierten Secrets, die von APT28 und Storm-2372 durchgeführten Token-Diebstahl-Kampagnen und der Anodot-Vorfall, der Dutzende nachgelagerter Plattformen betraf, weisen alle auf dieselbe strukturelle Lücke hin: Zugriffsmanagement, das für eine einfachere Umgebung konzipiert wurde, hält nicht Schritt damit, wie Organisationen heute tatsächlich arbeiten.

Der Schutz von Zugangsdaten bedeutet jetzt, den vollständigen Lebenszyklus zu verwalten — Ausstellung, Rotation, Delegation und Widerruf — über menschliche Benutzer, Dienstkonten, API-Keys und KI-Agent-Identitäten hinweg. Schatten-IT, ungeprüfte OAuth-Grants und hardcodierte Secrets in CI/CD-Pipelines sind die Angriffsfläche. Die Perimeter ist es nicht.

Die Vorfälle in diesem Digest haben eine strukturelle Lücke gemeinsam: Zugangsdaten und Tokens, die außerhalb der Governance existierten — ungeprüft, unrotiert, nicht widerrufen. Passwork bietet einen selbst gehosteten Tresor mit rollenbasierter Zugriffskontrolle, strukturierten Berechtigungen und einem vollständigen Audit-Log. Testen Sie Passwork in Ihrer Infrastruktur

Häufig gestellte Fragen

Was war die bedeutendste Cybersicherheitsbedrohung im April 2026?

Die APT28 FrostArmada-Kampagne war der operativ bedeutendste Vorfall des Monats. Durch das Kapern von DNS-Einstellungen auf über 18.000 ungepatchten SOHO-Routern in 120 Ländern fing die mit dem russischen GRU verbundene Gruppe stillschweigend Microsoft 365-Zugangsdaten und OAuth-Tokens von Regierungsbehörden, Strafverfolgungsbehörden und IT-Anbietern ab — unter Umgehung von MFA ohne Malware zu verteilen oder einzelne Benutzer direkt zu phishen.

Wie umgeht OAuth-Token-Diebstahl MFA?

OAuth-Tokens werden ausgestellt, nachdem ein Benutzer die Authentifizierung bereits abgeschlossen hat — einschließlich aller MFA-Schritte. Das Stehlen des Tokens bedeutet, eine vollständig authentifizierte Sitzung zu erben. MFA schützt den Anmeldeprozess; es schützt nicht das Token, das daraus resultiert. Angreifer, die Tokens abfangen oder stehlen, überspringen den Anmeldeprozess vollständig, wodurch MFA in dieser Phase irrelevant wird.

Was ist die Device-Code-Phishing-Technik, die von Storm-2372 verwendet wurde?

Device-Code-Phishing missbraucht einen legitimen OAuth-Flow, der für eingabebeschränkte Geräte entwickelt wurde. Angreifer initiieren den Flow und übermitteln den resultierenden Code dann über KI-personalisierte Phishing-E-Mails an Opfer. Wenn das Opfer den Code auf Microsofts echter Authentifizierungsseite eingibt, autorisiert es unwissentlich die Sitzung des Angreifers — und stellt ein gültiges Zugriffstoken aus, ohne sein Passwort preiszugeben oder eine MFA-Aufforderung auszulösen. Das Token ist legitim, weil der Benutzer die Authentifizierung selbst abgeschlossen hat.

Warum war der Bitwarden CLI Supply-Chain-Angriff bedeutsam?

Er zeigte, dass Sicherheitstools dasselbe Supply-Chain-Risiko tragen wie jede andere Softwareabhängigkeit. Eine bösartige Version des Bitwarden CLI wurde 94 Minuten lang über npm verteilt, nachdem Angreifer eine GitHub Action in der CI/CD-Pipeline gekapert hatten. Der injizierte Code zielte auf Entwickler-Secrets, Cloud-Zugangsdaten und Pipeline-Tokens ab — und war darauf ausgelegt, sich auf jedes Repository zu verbreiten, das das GitHub-Token des Opfers erreichen konnte.

Was ist Credential-Sprawl und warum beschleunigt er sich?

Credential-Sprawl bezieht sich auf die unkontrollierte Verbreitung von Secrets — API-Keys, Tokens, Passwörter, Zertifikate — über Repositories, Konfigurationsdateien, Collaboration-Tools und CI/CD-Pipelines. GitGuardians State of Secrets Sprawl 2026-Bericht fand 28,6 Millionen neue Secrets, die 2025 in öffentlichen GitHub-Repositories exponiert wurden — ein Anstieg von 34 % im Jahresvergleich, hauptsächlich angetrieben durch KI-unterstützte Entwicklung. Code erreicht die Produktion schneller, als Zugangsdaten-Governance-Richtlinien mithalten können — und 64 % der 2022 exponierten Secrets waren 2026 noch aktiv und ausnutzbar.

Brute-Force-Angriffe 2026: Typen, Beispiele & Schutzmaßnahmen

GPU-Cluster, KI-gestützte Wortlisten, Botnets mit 2,8 Mio. Geräten. Brute Force hat skaliert. Dieser Leitfaden behandelt sechs Angriffsvarianten, reale Fälle aus 2025 und eine mehrschichtige Verteidigungsstrategie zur sofortigen Umsetzung.

Passwork BlogAlex Muntyan

Supply-Chain-Angriff: Bitwarden CLI, Checkmarx und Schutz

Wie Angreifer vertrauenswürdige Pakete, GitHub Actions und CI/CD-Pipelines in stille Einfallstore verwandeln. Warum Architektur, gepinnte Abhängigkeiten und Secrets-Governance die einzigen Kontrollen sind, die den Schadensradius tatsächlich begrenzen.

Passwork BlogAlex Muntyan

Passwort-Chaos: Warum es ein Geschäftsproblem ist

Ein vergessenes Passwort kostet 70 $. Ein Datenleck kostet 4,44 Millionen $. Beides beginnt gleich — Zugangsdaten über Slack geteilt, in Tabellen gespeichert, nie geändert. Hier erfahren Sie, was Passwort-Chaos wirklich kostet und wie Sie es beseitigen.

Passwork BlogAlex Muntyan

Abril de 2026 quedará grabado en la memoria de los equipos de seguridad españoles. En apenas treinta días, más de seis millones de registros de clientes quedaron expuestos, la Comisión Europea amenazó a España con una sanción por incumplimiento normativo y el Gobierno aprobó dos proyectos de ley que cambiarán las reglas del juego para miles de empresas. Todo al mismo tiempo.

Este artículo resume lo que ocurrió, por qué importa y qué pueden hacer hoy las organizaciones para no protagonizar el próximo titular.

Un mes de brechas en cadena

El sector energético, en el punto de mira

El mismo actor que en enero filtró datos de millones de clientes de Endesa volvió a golpear en abril, esta vez contra Naturgy. El hacker conocido como «Spain» exfiltró aproximadamente 74,2 GB de información sensible: nombres, números de DNI/NIF, cuentas bancarias (IBAN), datos de suministro (CUPS) y direcciones físicas de más de 1,8 millones de clientes.

Al mismo tiempo, Iberdrola reconoció una brecha a través de su partner comercial Zirconite, que comprometió los datos de unos 150.000 clientes actuales y antiguos. El patrón es idéntico en ambos casos: el vector de entrada no fue la empresa matriz, sino un tercero de su cadena de suministro.

Retail y fitness: sectores inesperados, consecuencias reales

El 15 de abril, Inditex comunicó un acceso no autorizado a bases de datos alojadas en un proveedor externo. La compañía aseguró que no se vieron afectados datos financieros ni personales sensibles, pero el incidente pone sobre la mesa los riesgos inherentes a delegar el almacenamiento de datos en terceros.

Un día después, la cadena de gimnasios Basic Fit —con más de 150 centros en España— confirmó la exposición de datos bancarios, nombres y fechas de nacimiento de más de 4,5 millones de usuarios en toda Europa. Una sola brecha, consecuencias continentales.

Mapfre y el ultimátum de Lapsus$

La aseguradora Mapfre recibió un ultimátum del conocido grupo Lapsus$: 15 días para evitar la publicación de datos supuestamente robados. Un recordatorio de que el ransomware y la extorsión basada en datos siguen siendo las tácticas preferidas de los grupos más organizados.

El marco regulatorio cambia de velocidad

Dos proyectos de ley en un mismo mes

El Gobierno aprobó en abril el Proyecto de Ley de Protección y Resiliencia de Entidades Críticas, que transpone la Directiva CER (2022/2557) al ordenamiento jurídico español, con el Secretariado de Estado de Seguridad (SES) como autoridad competente.

En paralelo avanza el Anteproyecto de Ley de Coordinación y Gobernanza de la Ciberseguridad, vehículo de transposición de la Directiva NIS2. Los expertos que participaron en el foro CIO ForwardTech & ThreatScape Spain subrayaron dos implicaciones directas para las empresas: mayor responsabilidad de los consejos de administración y requisitos de auditoría más estrictos sobre la cadena de suministro.

La UE aprieta las tuercas

La Comisión Europea solicitó la imposición de una multa a España por no haber transpuesto la Directiva CER antes de octubre de 2024, fecha límite incumplida. La presión de Bruselas es ahora un factor regulatorio tan real como cualquier inspección de la AEPD.

Hablando de la AEPD: el organismo estrenó una herramienta interactiva para consultar notificaciones de brechas de datos y sancionó en abril a un centro educativo con 5.000 euros por una filtración derivada del robo de un equipo informático.

Las cifras que contextualizan el problema

El INCIBE publicó su informe anual con datos de 2025: 122.223 incidentes de ciberseguridad gestionados, un 26% más que en 2024. El sector bancario concentró el 34% de los incidentes en empresas; el malware y el fraude online fueron los vectores dominantes.

En Cataluña, la Agencia de Ciberseguridad bloqueó el 80% de los 9.100 millones de ciberataques registrados contra el sector público en 2025, aunque los incidentes con éxito se duplicaron hasta 6.544, con sanidad y universidades como principales víctimas.

Soberanía digital y criptografía postcuántica

Abril también trajo movimientos estratégicos en el mercado. La empresa española S2 Grupo y el proveedor de nube europeo OVHcloud anunciaron una alianza para ofrecer soluciones cloud y de ciberseguridad 100% europeas a sectores críticos, en respuesta directa a los requisitos de NIS2 y al RGPD.

La red de SOC de Vodafone España fue incorporada al registro europeo TF-CSIRT, un reconocimiento de madurez operativa relevante para sus clientes empresariales.

En el horizonte más lejano, España avanza en criptografía postcuántica (PQC) a través del proyecto ARQADE, liderado por la Fundación CTIC. Cataluña ha comprometido 18 millones de euros para preparar su infraestructura ante las amenazas que traerá la computación cuántica. El Centro Nacional de Inteligencia (CNI), por su parte, ha recomendado limitar el uso de equipos de Huawei en sectores críticos de telecomunicaciones.

Qué lecciones extraer para su organización

Los incidentes de abril tienen un denominador común que debería preocupar a cualquier CISO o responsable de IT:

1. La cadena de suministro es el eslabón débil. Naturgy, Iberdrola e Inditex no fueron comprometidas directamente, sino a través de partners y proveedores externos. NIS2 ya exige auditar estos terceros; los incidentes de abril demuestran que no es burocracia, es necesidad.
2. Los datos de acceso son el objetivo real. DNIs, IBANs, credenciales de usuario: lo que los atacantes buscan son los datos que permiten suplantar identidades o acceder a otros sistemas. Gestionar, rotar y centralizar el acceso a credenciales corporativas —especialmente en entornos con múltiples proveedores— es más urgente que nunca.
3. El marco normativo ya no es una opción. Con NIS2, CER y la presión de la Comisión Europea, las empresas que operen en sectores esenciales o importantes en España afrontan auditorías reales y sanciones reales. Documentar los controles y demostrar cumplimiento ya no puede postergarse.
4. El sector público también es objetivo. Municipios, universidades, hospitales: los actores con menores presupuestos de seguridad son blanco recurrente. La inversión pública a través del programa RETECH (162 millones de euros vía NextGenerationEU) es una respuesta sistémica, pero cada entidad necesita también su propia línea de defensa.

Conclusión

Abril de 2026 ha sido un mes de avisos. Avisos en forma de brecha de datos, de multas europeas y de legislación que ya no puede ignorarse. Las organizaciones que salgan mejor paradas serán las que ya hayan ordenado su casa: accesos controlados, proveedores auditados, credenciales gestionadas de forma centralizada y equipos con capacidad de respuesta ante incidentes.

La pregunta no es si su empresa será objetivo. La pregunta es si estará preparada cuando lo sea.

¿Quiere saber cómo Passwork ayuda a las organizaciones a centralizar y proteger el acceso a credenciales corporativas en entornos multi-proveedor? Solicite una demo gratuita

Ataque a la cadena de suministro: Bitwarden CLI y Checkmarx

Cómo los atacantes convierten paquetes de confianza, GitHub Actions y pipelines CI/CD en puntos de entrada silenciosos. Por qué la arquitectura, las dependencias fijadas y la gobernanza de secretos son los únicos controles que realmente contienen el radio de impacto.

Passwork BlogAlex Muntyan

Últimas noticias NIS2: Cambios y su impacto en empresas de la UE

Bélgica estableció el primer plazo de evaluación de conformidad para el 18 de abril de 2026. Los Países Bajos están a días de iniciar la aplicación. Aquí se explica dónde se encuentra la oleada regulatoria en este momento y qué deben abordar ahora los responsables de TI.

Passwork BlogAlex Muntyan

Ataques de fuerza bruta en 2026: tipos, ejemplos y prevención

Clústeres de GPU, diccionarios asistidos por IA, botnets de 2,8 millones de dispositivos. La fuerza bruta ha escalado. Esta guía cubre seis variantes de ataque, casos reales de 2025 y una estrategia de defensa en capas que su equipo puede implementar hoy.

Passwork BlogAlex Muntyan

Am 22. April 2026 wurde ein Credential Stealer in einem Paket mit 250.000 monatlichen Downloads ausgeliefert. Er wurde bei der Installation unbemerkt ausgeführt, erforderte keine Benutzerinteraktion und wurde automatisch von CI-Runnern in Dutzenden von Pipelines heruntergeladen. Als das Paket aus der Registry entfernt wurde, waren bereits echte Systeme kompromittiert worden.

Nur ein routinemäßiges Dependency-Update.

Moderne Infrastruktur ist nur so sicher wie ihre schwächste Abhängigkeit. Wenn Angreifer Ihren Perimeter nicht direkt durchbrechen können, kompromittieren sie etwas, dem Sie bereits vertrauen, und gelangen so direkt in Ihre Umgebung.

Ein Supply-Chain-Angriff ist die Kompromittierung eines vertrauenswürdigen Drittanbieters, einer Softwarekomponente oder eines Dienstes, um nachgelagerte Ziele zu infiltrieren. Der Angreifer benötigt nicht Ihre Zugangsdaten. Er braucht Zugang zu etwas, das Ihre Build-Pipeline automatisch um 3 Uhr morgens abruft. Er braucht einen Preinstall-Hook, der ausgeführt wird, bevor Sie ihn überprüfen können.

Der Bitwarden CLI-Vorfall ist der jüngste Beweis dafür, dass diese Bedrohung operativ, koordiniert und beschleunigt ist. In diesem Artikel analysieren wir, wie der Angriff funktionierte, was er uns über moderne Infrastruktur lehrt und welche Kontrollen Supply-Chain-Kompromittierungen tatsächlich davon abhalten, in Ihre Umgebung zu gelangen.

Wichtigste Erkenntnisse

• Supply-Chain-Angriffe umgehen Ihren Perimeter, indem sie das ausnutzen, dem Sie bereits vertrauen — Pakete, CI-Workflows und Plugins werden in Ihrer Umgebung mit vollen Privilegien ausgeführt, ohne einen einzigen Phishing-Link.
• Die Bitwarden CLI-Kompromittierung im April 2026 war eine koordinierte, mehrstufige Operation — Angreifer kaperten eine GitHub Action eines Drittanbieters, stahlen ein npm-Token und veröffentlichten @bitwarden/cli@2026.4.0 mit einem Credential Stealer, der bei der Installation unbemerkt ausgeführt wurde.
• Transitive Dependencies sind Ihre größte ungeprüfte Angriffsfläche — Ihre Anwendung importiert möglicherweise zehn Pakete direkt, aber jedes davon lädt Dutzende weitere, von denen keines die gleiche Prüfung wie First-Party-Code erhält.
• Architektur ist eine stärkere Kontrolle als Prozesse — Ein System, das so konzipiert ist, dass die Kompromittierung einer Komponente nichts Brauchbares liefert, ist grundlegend widerstandsfähiger als eines, das darauf angewiesen ist, dass alle Kontrollen gleichzeitig halten.
• Secrets in CI/CD-Pipelines sind das primäre Ziel — GitHub-Tokens, SSH-Schlüssel und Cloud-Zugangsdaten, die in einem einzigen Build-Job abgegriffen werden, können eine Kompromittierung auf jedes Repository und jede Pipeline ausweiten, die dieses Token erreichen kann.
• Verteidigung erfordert kontinuierliche Kontrollen, keine periodischen — Gepinnte Dependencies, signierte Builds, SBOM-Tracking, zeitlich begrenzte Tokens mit begrenztem Umfang und Secrets-Rotation müssen bei jedem Commit ausgeführt werden, nicht jedes Quartal.

Was ist ein Supply-Chain-Angriff

Ein Supply-Chain-Angriff tritt auf, wenn ein Angreifer einen vertrauenswürdigen Drittanbieter, ein Open-Source-Paket oder eine Softwarekomponente kompromittiert, um eine bösartige Nutzlast an nachgelagerte Organisationen zu liefern. Der Angreifer nutzt die Vertrauensbeziehung zwischen einem Lieferanten und seinen Nutzern aus, was die Erkennung deutlich schwieriger macht als bei einem direkten Eindringen.

Die Angriffsfläche ist groß, weil moderne Software auf Schichten von Abhängigkeiten aufgebaut ist. Ihre Anwendung importiert möglicherweise direkt zehn Pakete, aber jedes davon importiert Dutzende weitere. Diese transitiven Dependencies (Komponenten, auf die Ihr Code indirekt angewiesen ist) werden selten mit der gleichen Sorgfalt geprüft wie First-Party-Code.

Supply-Chain-Angriffe fallen in mehrere Kategorien:

• Software-Supply-Chain-Angriffe — Bösartiger Code, der in Open-Source-Bibliotheken, Paket-Registries (npm, PyPI) oder Vendor-Software-Updates eingeschleust wird.
• CI/CD-Pipeline-Angriffe — Kompromittierung von Build-Systemen, GitHub-Actions-Workflows oder Container-Registries, um den Build-Prozess abzufangen.
• Drittanbieter-Service-Angriffe — Ausnutzung von SaaS-Tools, Plugins oder Managed Services, die privilegierten Zugriff auf Kundenumgebungen haben.
• Hardware-Supply-Chain-Angriffe — Physische Manipulation von Firmware oder Komponenten, bevor sie den Endbenutzer erreichen (seltener im Software-Kontext, aber bei staatlichen Operationen dokumentiert).

Der gemeinsame Nenner: Das Opfer installiert, führt aus oder vertraut etwas, das bereits als Waffe eingesetzt wurde.

Die Anatomie eines modernen Supply-Chain-Angriffs

Ein Supply-Chain-Angriff folgt einem vorhersehbaren Lebenszyklus. Die Kenntnis der Phasen macht ihn vermeidbar.

1. Aufklärung. Angreifer scannen öffentliche Repositories, Paket-Registries und CI/CD-Konfigurationen nach Schwachstellen: ungeschützte GitHub-Tokens, Pakete mit hohen Download-Zahlen und minimaler Maintainer-Beteiligung oder Actions-Workflows mit übermäßigen Berechtigungen.
2. Upstream-Kompromittierung. Der Angreifer erhält Schreibzugriff auf ein vertrauenswürdiges Artefakt, indem er Maintainer-Zugangsdaten stiehlt, einen bösartigen Pull Request einreicht oder Code direkt in eine Build-Pipeline einschleust. Die bösartige Nutzlast wird dort eingebettet, wo sie automatisch ausgeführt wird: ein Preinstall-Hook, ein Workflow-Schritt, ein Plugin-Update.
3. Ruhephase. Das kompromittierte Artefakt wird veröffentlicht und wartet. Automatisierte Systeme (CI-Runner, Dependency-Manager, Entwickler-Workstations) laden das Update ohne menschliche Überprüfung herunter. Der bösartige Code bleibt inaktiv, bis er ausgelöst wird.
4. Downstream-Auslieferung. Entwickler und Pipelines installieren die infizierte Version über normale, vertrauenswürdige Kanäle. Es gibt keinen Phishing-Link zum Anklicken, keinen verdächtigen Anhang zum Öffnen. Der Credential Stealer wird als Teil des Standard-Build-Prozesses ausgeführt.
5. Privilegien-Eskalation. Mit dem etablierten Erstzugang sammelt der Angreifer Secrets: API-Tokens, SSH-Schlüssel, Umgebungsvariablen, Cloud-Zugangsdaten. GitHub-Tokens sind besonders wertvoll — sie können genutzt werden, um bösartige Workflows in jedes Repository einzuschleusen, das das Token erreichen kann, und die Kompromittierung weiter downstream zu verbreiten.

Ungeschützte Secrets in CI/CD-Pipelines sind genau das, was Angreifer in Phase fünf abgreifen. Testen Sie Passwork kostenlos und sehen Sie, wie strukturiertes Secrets-Management Ihre Angriffsfläche reduziert → passwork.pro

Fallstudie: Die Bitwarden CLI- und Checkmarx-Kampagne 2026

Der Bitwarden CLI-Supply-Chain-Angriff, bestätigt von JFrog und Socket am 23. April 2026, ist eine der technisch präzisesten Credential-Harvesting-Operationen, die bisher dokumentiert wurden. Er zielte direkt auf Entwickler ab: ihre Tokens, ihre KI-Tools, ihre Pipelines. Und er enthielt eine wichtige architektonische Lektion für die gesamte Branche.

Der Angriff entfaltete sich in Phasen, wobei jede eine andere Vertrauensebene in der Software-Supply-Chain ausnutzte.

Was passierte

Am 22. April 2026 wurde eine bösartige Version des Bitwarden CLI (@bitwarden/cli@2026.4.0) in der npm-Registry veröffentlicht. Das Paket hat über 250.000 monatliche Downloads, was es zu einem hochwertigen Ziel macht. Der bösartige Code war in bw1.js eingebettet und wurde über einen Preinstall-Hook in package.json ausgelöst, der zuerst bw_setup.js ausführte, um die Bun-Runtime zu installieren, und dann bw1.js — die eigentliche bösartige Nutzlast (OX Security, 2026). Keine Benutzerinteraktion erforderlich.

Die Angreifer drangen nicht direkt in Bitwarden ein. Sie kompromittierten eine GitHub Action eines Drittanbieters, die in Bitwardens CI/CD-Pipeline verwendet wurde, erlangten Zugriff auf Workflow-Secrets einschließlich eines npm-Tokens und verwendeten es, um das bösartige Paket zu veröffentlichen. Der Angriff nutzte die CI/CD-Pipeline als Einstiegspunkt — konsistent mit dem breiteren Muster, das in der Checkmarx-Supply-Chain-Kampagne identifiziert wurde. Die Zeichenkette "Shai-Hulud: The Third Coming", die im Paket eingebettet war, bestätigte, dass dies die dritte Iteration einer laufenden, organisierten Kampagne war — kein opportunistischer Einzelfall.

Entscheidend ist, dass keine Benutzer-Tresore betroffen waren. Bitwardens Zero-Knowledge-Architektur bedeutete, dass der Server niemals Masterpasswörter oder Zugriff auf entschlüsselte Benutzerdaten hatte. Selbst bei kompromittiertem CI/CD konnte der Angreifer nicht an das gelangen, was die Architektur schützen sollte.

Was die Malware tat

Die bösartige Nutzlast (die dritte Phase des „Shai-Hulud"-Wurms) führte folgende Sequenz aus:

1. Russische Sprachprüfung. Bevor irgendetwas anderes getan wurde, prüfte die Malware, ob auf dem Host-Rechner die russische Sprache konfiguriert war. Falls ja, wurde sie sofort beendet. Dies ist eine Standard-Selbstschutztechnik: Die Autoren vermeiden es, ihre eigenen Entwicklungsrechner zu infizieren, und dies deutet stark auf einen russischsprachigen Bedrohungsakteur hin.
2. Credential Harvesting. Sie zielte auf GitHub- und npm-Tokens, .ssh-Verzeichnisse, .env-Dateien, Shell-History, GitHub-Actions-Umgebungsvariablen, AWS-, GCP- und Azure-Zugangsdaten sowie GitHub-Runner-Informationen ab.
3. KI-Tool-Targeting. Konfigurationsdateien für KI-Coding-Assistenten (Claude, Kiro, Cursor, Codex CLI und Aider) wurden explizit ins Visier genommen, was widerspiegelt, wie tief diese Tools mittlerweile in Entwickler-Workflows eingebettet sind und wie viel sensiblen Kontext sie lokal speichern.
4. Verschlüsselte Exfiltration über GitHub. Alle gestohlenen Daten wurden mit AES-256-GCM unter Verwendung asymmetrischer Verschlüsselung verschlüsselt — was bedeutet, dass nur der private Schlüssel des Bedrohungsakteurs sie entschlüsseln kann. Die Daten wurden in ein neu erstelltes öffentliches GitHub-Repository auf dem eigenen Account des Opfers hochgeladen, mit Dateien namens results-TIMESTAMP-ID.json. Ein sekundärer Kanal exfiltrierte Daten an audit.checkmarx[.]cx, eine Domain, die die legitime Checkmarx-Plattform imitierte. Die Verwendung von GitHub als C2-Server ist beabsichtigt: Datenverkehr zu github.com wird selten von Sicherheitstools markiert und kann nicht zu einer vom Bedrohungsakteur kontrollierten Domain zurückverfolgt werden.
5. Selbstverbreitung. Das macht Shai-Hulud zu einem Wurm, nicht nur zu einem Stealer. Wenn gültige npm-Tokens gefunden wurden, lud die Malware eines der eigenen npm-Pakete des Opfers herunter, schleuste bösartigen Code ein und veröffentlichte automatisch eine neue Version — wodurch die Infektion auf die Downstream-Benutzer des Opfers übertragen wurde.
6. Pipeline-Verbreitung. Wenn GitHub-Tokens gefunden wurden, schleuste die Malware bösartige Actions-Workflows in zugängliche Repositories ein, extrahierte CI/CD-Secrets und weitete die Kompromittierung auf jede Pipeline aus, die das Token des Entwicklers erreichen konnte.

Wie StepSecurity anmerkte: „Ein einzelner Entwickler mit installiertem @bitwarden/cli@2026.4.0 kann zum Einstiegspunkt für eine breitere Supply-Chain-Kompromittierung werden, wobei der Angreifer dauerhaften Workflow-Injection-Zugriff auf jede CI/CD-Pipeline erhält, die das Token des Entwicklers erreichen kann."

OX Security bestätigte, dass verschlüsselte Exfiltrationsdaten zum Zeitpunkt der Entdeckung bereits in öffentlichen GitHub-Repositories vorhanden waren — echte Rechner waren kompromittiert worden, bevor das Paket entfernt wurde.

Der Checkmarx-Vorfall: 23. März 2026

Diese Kampagne begann nicht im April. Laut dem Checkmarx-Sicherheitsupdate wurden am 23. März 2026 bösartige Versionen von zwei OpenVSX-Plugins etwa um 02:53 UTC veröffentlicht und blieben bis 15:41 UTC verfügbar. Zwei GitHub-Actions-Workflows (ast-github-action und kics-github-action) wurden ebenfalls kompromittiert. Organisationen, die diese Artefakte während dieses Zeitfensters heruntergeladen und ausgeführt haben, waren gefährdet.

Der Bitwarden CLI-Vorfall im April folgte demselben GitHub-Actions-Supply-Chain-Vektor und bestätigte eine aktive, sich entwickelnde Kampagne statt eines isolierten Vorfalls.

Die architektonische Lektion

Der Bitwarden-Vorfall spiegelt ein Muster wider, das die Branche immer wieder neu lernt: Sicherheitskontrollen auf Prozessebene können umgangen werden. Architektonische Einschränkungen nicht. Ein System, das so konzipiert ist, dass die Kompromittierung einer Komponente nichts Brauchbares liefert, ist grundlegend widerstandsfähiger als eines, das darauf angewiesen ist, dass alle Kontrollen gleichzeitig halten.

Passwork basiert auf diesem Prinzip. Zugangsdaten werden clientseitig verschlüsselt, bevor sie den Server erreichen. Der Server speichert Chiffretext. Ein Datenbank-Breach, ein kompromittierter Server oder ein böswilliger Administrator liefert nichts ohne die clientseitigen Schlüssel. Die Passwork CLI-Veröffentlichung auf PyPI folgt einem halbmanuellen Prozess von vertrauenswürdigen Rechnern — eine CI/CD-Kompromittierung kann keine automatische Veröffentlichung eines bösartigen Artefakts auslösen.

Die Frage, die Sie zu jedem Tool in Ihrem Stack stellen sollten: Wenn diese Komponente kompromittiert wird, was erhält der Angreifer tatsächlich?

Sie wechseln von einem anderen Passwort-Manager? Passwork bietet Teams, die von einer konkurrierenden Lösung wechseln, einen Migrationsrabatt von 10 %. Passwork kostenlos testen

Weitere bemerkenswerte Supply-Chain-Angriffe (2020–2026)

Der Bitwarden CLI-Vorfall ist der jüngste in einer Reihe von schwerwiegenden Supply-Chain-Kompromittierungen, die die Sichtweise von Sicherheitsteams auf Drittanbieter-Risiken verändert haben.

Jeder Vorfall teilt ein strukturelles Muster: Angreifer fanden einen vertrauenswürdigen, automatisierten Auslieferungsmechanismus und fügten ihre Nutzlast dort ein, wo sie ohne Prüfung ausgeführt werden würde:

• event-stream etablierte, dass das Vertrauen in Open-Source-Maintainer im großen Maßstab ausnutzbar ist
• SolarWinds zeigte, dass selbst signierte, vom Anbieter verteilte Updates als Waffe eingesetzt werden können
• XZ Utils demonstrierte, dass langfristiges Social Engineering von Maintainern ein gangbarer Angriffsweg ist
• Codecov bewies, dass CI/CD-Infrastruktur selbst ein hochwertiges Ziel ist — aus Build-Pipelines abgegriffene Secrets können ganze Organisationen öffnen
• Der 3CX-Fall führte ein neues Bedrohungsmodell ein: ein Supply-Chain-Angriff als Einstiegspunkt für einen weiteren Supply-Chain-Angriff

Die Angriffsfläche hat sich mit jeder Iteration erweitert. Was als isolierte Paket-Hijacks begann, hat sich zu koordinierten, mehrstufigen Kampagnen entwickelt, die auf die gesamte Software-Lieferkette abzielen.

Die wahren Kosten von Supply-Chain-Schwachstellen

Supply-Chain-Angriffe sind teuer — und die Kosten steigen. Laut der Wiz-Analyse von 2025 werden die globalen Kosten von Software-Supply-Chain-Angriffen auf 60 Milliarden Dollar im Jahr 2025 geschätzt und sollen bis 2031 138 Milliarden Dollar erreichen.

Diese Zahlen spiegeln direkte Incident-Response-Kosten, regulatorische Strafen, Reputationsschäden und die nachgelagerten Kosten der betroffenen Kunden wider — nicht nur die des kompromittierten Anbieters.

Die regulatorische Dimension verstärkt das finanzielle Risiko. Organisationen, die unter DSGVO, HIPAA, SOC 2 oder ISO 27001 operieren, unterliegen obligatorischen Meldepflichten bei Datenschutzverletzungen und potenziellen Bußgeldern, wenn Supply-Chain-Vorfälle zu unbefugtem Zugriff auf persönliche oder regulierte Daten führen. Eine kompromittierte CI/CD-Pipeline, die Umgebungsvariablen mit Datenbank-Zugangsdaten exfiltriert, ist nicht nur ein operativer Vorfall — sie ist ein Compliance-Ereignis.

Für Organisationen mit ausgereiften Sicherheitsprogrammen sind die schwerer zu quantifizierenden Kosten der Vertrauensverlust. Wenn ein Entwickler-Tool, das in Hunderten von Pipelines verwendet wird, kompromittiert wird, geht die Behebung weit über das Patchen hinaus: Jedes Secret, das hätte exponiert werden können, muss als kompromittiert behandelt und rotiert werden.

So verhindern Sie Supply-Chain-Angriffe in CI/CD-Umgebungen

Die Verhinderung von Supply-Chain-Angriffen erfordert Kontrollen auf jeder Ebene des Software-Auslieferungsprozesses. Die folgenden Praktiken adressieren die spezifischen Angriffsvektoren, die in den Kampagnen von 2026 beobachtet wurden.

• Pinnen Sie Dependency-Versionen und verifizieren Sie Hashes. Verwenden Sie niemals flexible Versionsbereiche in Produktions-Pipelines. Pinnen Sie exakte Versionen und validieren Sie Prüfsummen gegen einen bekannten guten Zustand. Dies verhindert nicht die Kompromittierung eines Maintainer-Accounts, eliminiert aber die automatische Exposition gegenüber neu veröffentlichten bösartigen Versionen.
• Erzwingen Sie signierte Builds und Provenance-Attestierung. Ein signiertes Artefakt mit einer verifizierbaren Build-Kette ist deutlich schwerer unbemerkt zu manipulieren.
• Erstellen und pflegen Sie eine Software Bill of Materials (SBOM). Eine SBOM gibt Ihnen eine vollständige Inventur jeder Komponente in Ihrer Software, einschließlich transitiver Dependencies. Wenn eine neue Schwachstelle oder ein bösartiges Paket bekannt wird, können Sie sofort feststellen, ob Sie betroffen sind — ohne manuelles Auditing.
• Führen Sie kontinuierliche Software Composition Analysis (SCA) durch. Statische, einmalige Scans sind unzureichend. SCA-Tools sollten bei jedem Pull Request und jedem Dependency-Update laufen und neue Pakete, ungewöhnliche Preinstall-Hooks und unerwartete Netzwerkaufrufe in Paket-Skripten markieren.
• Wenden Sie Zero-Trust-Prinzipien auf CI/CD-Workflows an. GitHub-Actions-Workflows sollten mit den minimal erforderlichen Berechtigungen arbeiten. Verwenden Sie kurzlebige Tokens mit Geltungsbereich für einzelne Jobs, keine langlebigen persönlichen Zugangs-Tokens. Prüfen Sie Workflow-Dateien auf Drittanbieter-Action-Referenzen und pinnen Sie sie auf spezifische Commit-SHAs, nicht auf veränderbare Tags.
• Rotieren Sie CI/CD-Secrets regelmäßig und nach jedem Vorfall. Behandeln Sie Secrets in CI/CD-Umgebungen als kurzlebige Zugangsdaten. Jedes Token, jeder API-Schlüssel oder SSH-Schlüssel, der hätte exponiert werden können, sollte sofort rotiert werden. Ein strukturierter Secrets-Management-Prozess macht dies operativ machbar statt zu einem manuellen Scramble.
• Überwachen Sie auf anomales Exfiltrationsverhalten. Die Bitwarden CLI-Malware stellte ausgehende Verbindungen zu audit.checkmarx[.]cx her. Netzwerk-Level-Überwachung des CI-Runner-Egress-Traffics hätte dies markiert. Erstellen Sie eine Allowlist erwarteter ausgehender Ziele für Build-Umgebungen und alarmieren Sie bei Abweichungen.
• Prüfen Sie KI-Coding-Tool-Konfigurationen. Die Kampagne von 2026 zielte explizit auf Konfigurationsdateien für Claude, Cursor, Aider und ähnliche Tools ab. Diese Dateien enthalten oft API-Schlüssel und Kontext über die Codebasis. Behandeln Sie sie als sensible Artefakte und beziehen Sie sie in Ihren Secrets-Scanning-Umfang ein.

Fazit

Supply-Chain-Angriffe funktionieren, weil sie das Einzige ausnutzen, was Organisationen nicht einfach prüfen können: das in automatisierte Systeme eingebettete Vertrauen. Jede Dependency, die Ihre Pipeline abruft, jede GitHub Action, die Ihr Workflow referenziert, jedes Plugin, das Ihre IDE lädt — jedes ist ein potenzieller Einstiegspunkt.

Die Bitwarden CLI- und Checkmarx-Kampagnen von 2026 machen die Bedrohung konkret. Ein einzelnes kompromittiertes Paket, das unbemerkt von einem CI-Runner installiert wird, kann jedes Secret in der Umgebung eines Entwicklers exponieren und sich durch jede Pipeline verbreiten, die dieses Token erreichen kann. Der Angriff kündigt sich nicht an. Er wird als Teil Ihres normalen Build-Prozesses ausgeführt.

Die Verteidigung dagegen erfordert mehr als periodische Audits. Sie erfordert Zero-Trust-Architektur, angewandt auf die Software-Supply-Chain: gepinnte Dependencies, signierte Artefakte, SBOM-Tracking, kontinuierliche SCA und kurzlebige Tokens mit begrenztem Umfang. Secrets müssen als vergänglich behandelt werden — regelmäßig rotiert, sicher gespeichert und niemals ohne Governance in Code oder Umgebungsdateien eingebettet.

Robustes Secrets-Management ist hier eine grundlegende Kontrolle. Wenn Zugangsdaten in einem strukturierten, zugangskontrollierten Tresor wie Passwork gespeichert werden, anstatt über .env-Dateien und Entwickler-Workstations verstreut zu sein, schrumpft der Explosionsradius einer Supply-Chain-Kompromittierung erheblich. Angreifer können stehlen, was sie erreichen können. Machen Sie es zu nichts.

Bereit, Ihren Explosionsradius zu reduzieren? Passwork bietet Ihrem Team einen strukturierten Secrets-Tresor mit rollenbasiertem Zugriff, vollständigem Audit-Logging und einer Self-Hosted-Bereitstellung, die Zugangsdaten von Drittanbieter-Infrastruktur fernhält. Teams, die von einem anderen Passwort-Manager migrieren, erhalten 10 % Rabatt. Passwork entdecken

FAQ: Supply-Chain-Angriffe

Was ist ein Supply-Chain-Angriff in der Cybersicherheit?

Ein Supply-Chain-Angriff ist ein Cyberangriff, der einen vertrauenswürdigen Drittanbieter, ein Open-Source-Paket oder eine Softwarekomponente kompromittiert, um Zugriff auf nachgelagerte Ziele zu erlangen. Anstatt eine Organisation direkt anzugreifen, schleusen Angreifer bösartige Nutzlasten in Software-Updates, Build-Pipelines oder Dependencies ein, die das Ziel automatisch installiert.

Wie funktionierte der Bitwarden CLI-Supply-Chain-Angriff?

Das bösartige Paket @bitwarden/cli@2026.4.0 wurde am 22. April 2026 auf npm mit einem in bw1.js eingebetteten Credential Stealer veröffentlicht und über einen Preinstall-Hook ausgeführt. Es sammelte GitHub-Tokens, SSH-Schlüssel, Umgebungsvariablen, Cloud-Secrets und KI-Coding-Tool-Konfigurationen und exfiltrierte die Daten — mit AES-256-GCM verschlüsselt — an eine Domain, die Checkmarx imitierte.

Was ist der Unterschied zwischen einem Supply-Chain-Angriff und einem direkten Cyberangriff?

Ein direkter Angriff zielt auf die eigenen Systeme des Opfers ab — sein Netzwerk, seine Zugangsdaten oder seine Anwendungen. Ein Supply-Chain-Angriff zielt stattdessen auf einen vertrauenswürdigen Lieferanten oder eine Dependency ab und nutzt dieses Vertrauen, um die Abwehr des Opfers zu umgehen. Das Opfer installiert oder führt die kompromittierte Komponente freiwillig über normale Prozesse aus, was die Erkennung erheblich erschwert.

Was sind transitive Dependencies und warum sind sie für die Sicherheit wichtig?

Transitive Dependencies sind Softwarekomponenten, auf die Ihr Code indirekt angewiesen ist — Bibliotheken, die von Ihren direkten Dependencies importiert werden, die wiederum andere importieren. Sie werden selten mit der gleichen Sorgfalt wie First-Party-Code geprüft, werden aber in Ihrer Umgebung mit denselben Privilegien ausgeführt. Eine Kompromittierung irgendwo in dieser Kette kann Ihre Anwendung betreffen.

Was ist eine SBOM und wie hilft sie, Supply-Chain-Angriffe zu verhindern?

Eine Software Bill of Materials (SBOM) ist ein strukturiertes Inventar jeder Komponente in einem Softwareprodukt, einschließlich aller direkten und transitiven Dependencies. Wenn ein bösartiges Paket oder eine Schwachstelle bekannt wird, ermöglicht eine SBOM Sicherheitsteams sofort festzustellen, ob ihre Software betroffen ist — ohne manuelles Durchsuchen von Dependency-Trees in jedem Projekt.

Welche GitHub-Actions-Sicherheitspraktiken reduzieren das Supply-Chain-Risiko?

Pinnen Sie alle Drittanbieter-Actions auf spezifische Commit-SHAs statt auf veränderbare Versions-Tags. Verwenden Sie kurzlebige, job-spezifische Tokens anstelle von langlebigen persönlichen Zugangs-Tokens. Beschränken Sie Workflow-Berechtigungen auf das erforderliche Minimum. Prüfen Sie alle Workflow-Dateien auf unerwartete Drittanbieter-Referenzen und überwachen Sie CI-Runner-Egress-Traffic auf anomale ausgehende Verbindungen.

Wie sollten Organisationen reagieren, wenn ein kompromittiertes Paket in ihrer CI/CD-Pipeline installiert wurde?

Behandeln Sie alle Secrets, die während der betroffenen Build-Jobs zugänglich waren, als kompromittiert. Rotieren Sie jedes Token, jeden API-Schlüssel, SSH-Schlüssel und jede Cloud-Zugangsdaten, die hätten exponiert werden können. Überprüfen Sie GitHub-Actions-Workflow-Dateien auf unautorisierte Änderungen. Prüfen Sie Repository-Zugriffsprotokolle auf unerwartete Commits oder Workflow-Läufe. Melden Sie den Vorfall gemäß Ihren regulatorischen Verpflichtungen unter DSGVO, HIPAA oder anwendbaren Frameworks.

Brute-Force-Angriffe 2026: Typen, Beispiele und wie Sie sie verhindern

GPU-Cluster, KI-gestützte Wortlisten, Botnets mit 2,8 Millionen Geräten. Brute Force hat skaliert. Dieser Leitfaden behandelt sechs Angriffsvarianten, reale Fälle aus 2025 und eine mehrschichtige Verteidigungsstrategie, die Ihr Team heute implementieren kann.

Passwork BlogAlex Muntyan

NIS2 aktuelle Nachrichten: Was sich geändert hat und was es für EU-Unternehmen bedeutet

84 % der betroffenen Organisationen geben zu, dass sie nicht bereit sind. Belgien setzte die erste Konformitätsbewertungsfrist auf den 18. April 2026. Die Niederlande stehen kurz vor der Durchsetzung. Hier ist der aktuelle Stand der Regulierungswelle und was IT-Führungskräfte jetzt tun müssen.

Passwork BlogAlex Muntyan

Passwort-Chaos: Warum es ein Geschäftsproblem ist und wie Sie es lösen

Ein vergessenes Passwort kostet 70 $. Ein Datenleck kostet 4,44 Millionen $. Beides beginnt auf die gleiche Weise — Zugangsdaten, die über Slack geteilt, in Tabellenkalkulationen gespeichert und nie rotiert werden. Hier erfahren Sie, was Passwort-Chaos wirklich kostet und wie Sie es eliminieren.

Passwork BlogAlex Muntyan

El 22 de abril de 2026, un ladrón de credenciales se distribuyó dentro de un paquete con 250.000 descargas mensuales. Se ejecutó silenciosamente durante la instalación, no requirió interacción del usuario y fue descargado automáticamente por ejecutores de CI en docenas de pipelines. Para cuando el paquete fue retirado del registro, máquinas reales ya habían sido comprometidas.

Solo una actualización rutinaria de dependencias.

La infraestructura moderna es tan segura como su dependencia más débil. Cuando los atacantes no pueden vulnerar su perímetro directamente, comprometen algo en lo que usted ya confía y lo utilizan para entrar directamente en su entorno.

Un ataque a la cadena de suministro es el compromiso de un proveedor externo de confianza, un componente de software o un servicio para infiltrarse en objetivos aguas abajo. El atacante no necesita sus credenciales. Necesita acceso a algo que su pipeline de compilación descarga automáticamente a las 3 de la madrugada. Necesita un hook de preinstalación que se ejecute antes de que usted pueda inspeccionarlo.

El incidente de Bitwarden CLI es la última prueba de que esta amenaza es operativa, coordinada y se está acelerando. En este artículo, analizamos cómo funcionó el ataque, qué nos enseña sobre la infraestructura moderna y qué controles realmente previenen que los compromisos de la cadena de suministro lleguen a su entorno.

Puntos clave

• Los ataques a la cadena de suministro evaden su perímetro al convertir en arma lo que usted ya confía — paquetes, flujos de trabajo de CI y plugins se ejecutan en su entorno con privilegios completos, sin un solo enlace de phishing.
• El compromiso de Bitwarden CLI de abril de 2026 fue una operación coordinada y multietapa — los atacantes secuestraron una GitHub Action de terceros, robaron un token de npm y publicaron @bitwarden/cli@2026.4.0 con un ladrón de credenciales que se ejecutaba silenciosamente durante la instalación.
• Las dependencias transitivas son su mayor superficie de ataque sin auditar — su aplicación puede importar diez paquetes directamente, pero cada uno de ellos incorpora docenas más, ninguno de los cuales recibe el mismo escrutinio que el código propio.
• La arquitectura es un control más fuerte que el proceso — un sistema diseñado de manera que comprometer un componente no proporcione nada útil es fundamentalmente más resiliente que uno que depende de que todos los controles se mantengan simultáneamente.
• Los secretos en pipelines de CI/CD son el objetivo principal — los tokens de GitHub, las claves SSH y las credenciales de nube recolectados en un solo trabajo de compilación pueden propagar un compromiso a través de cada repositorio y pipeline al que ese token pueda acceder.
• La defensa requiere controles continuos, no periódicos — dependencias fijadas, compilaciones firmadas, seguimiento de SBOM, tokens efímeros con alcance limitado y rotación de secretos deben ejecutarse en cada commit, no cada trimestre.

Qué es un ataque a la cadena de suministro

Un ataque a la cadena de suministro ocurre cuando un adversario compromete un proveedor externo de confianza, un paquete de código abierto o un componente de software para entregar una carga maliciosa a organizaciones aguas abajo. El atacante explota la relación de confianza entre un proveedor y sus consumidores, lo que hace que la detección sea significativamente más difícil que con una intrusión directa.

La superficie de ataque es amplia porque el software moderno se construye sobre capas de dependencias. Su aplicación puede importar directamente diez paquetes, pero cada uno de ellos importa docenas más. Estas dependencias transitivas (componentes de los que su código depende indirectamente) rara vez se auditan con el mismo rigor que el código propio.

Los ataques a la cadena de suministro se dividen en varias categorías:

• Ataques a la cadena de suministro de software — Código malicioso inyectado en bibliotecas de código abierto, registros de paquetes (npm, PyPI) o actualizaciones de software de proveedores.
• Ataques a pipelines de CI/CD — Compromiso de sistemas de compilación, flujos de trabajo de GitHub Actions o registros de contenedores para interceptar el proceso de compilación.
• Ataques a servicios de terceros — Explotación de herramientas SaaS, plugins o servicios gestionados que tienen acceso privilegiado a los entornos de los clientes.
• Ataques a la cadena de suministro de hardware — Manipulación física del firmware o componentes antes de que lleguen al usuario final (menos común en contextos de software, pero documentado en operaciones de estados-nación).

El hilo común: la víctima instala, ejecuta o confía en algo que ya ha sido convertido en arma.

La anatomía de un ataque moderno a la cadena de suministro

Un ataque a la cadena de suministro sigue un ciclo de vida predecible. Conocer las fases es lo que lo hace prevenible.

1. Reconocimiento. Los atacantes escanean repositorios públicos, registros de paquetes y configuraciones de CI/CD en busca de eslabones débiles: tokens de GitHub desprotegidos, paquetes con alto número de descargas y mínimos mantenedores, o flujos de trabajo de Actions con permisos excesivos.
2. Compromiso aguas arriba. El atacante obtiene acceso de escritura a un artefacto de confianza robando credenciales de mantenedores, enviando una solicitud de extracción maliciosa o inyectando código directamente en un pipeline de compilación. La carga maliciosa se incrusta donde se ejecutará automáticamente: un hook de preinstalación, un paso de flujo de trabajo, una actualización de plugin.
3. Latencia. El artefacto comprometido se publica y espera. Los sistemas automatizados (ejecutores de CI, gestores de dependencias, estaciones de trabajo de desarrolladores) descargan la actualización sin revisión humana. El código malicioso permanece latente hasta que se activa.
4. Entrega aguas abajo. Los desarrolladores y los pipelines instalan la versión infectada a través de canales normales y de confianza. No hay ningún enlace de phishing en el que hacer clic, ningún archivo adjunto sospechoso que abrir. El ladrón de credenciales se ejecuta como parte del proceso de compilación estándar.
5. Escalada de privilegios. Con el acceso inicial establecido, el atacante recolecta secretos: tokens de API, claves SSH, variables de entorno, credenciales de nube. Los tokens de GitHub son particularmente valiosos — pueden convertirse en arma para inyectar flujos de trabajo maliciosos en cada repositorio al que el token pueda acceder, propagando el compromiso más aguas abajo.

Los secretos desprotegidos en pipelines de CI/CD son exactamente lo que los atacantes recolectan en la fase cinco. Pruebe Passwork gratis y vea cómo la gestión estructurada de secretos reduce su exposición → passwork.pro

Caso de estudio: la campaña de Bitwarden CLI y Checkmarx de 2026

El ataque a la cadena de suministro de Bitwarden CLI, confirmado por JFrog y Socket el 23 de abril de 2026, es una de las operaciones de recolección de credenciales técnicamente más precisas documentadas hasta la fecha. Se dirigió directamente a los desarrolladores: sus tokens, sus herramientas de IA, sus pipelines. Y conllevó una importante lección arquitectónica para toda la industria.

El ataque se desarrolló en etapas, cada una explotando una capa diferente de confianza en la cadena de suministro de software.

Qué ocurrió

El 22 de abril de 2026, se publicó una versión maliciosa de Bitwarden CLI (@bitwarden/cli@2026.4.0) en el registro de npm. El paquete tiene más de 250.000 descargas mensuales, lo que lo convierte en un objetivo de alto valor. El código malicioso estaba incrustado en bw1.js y se activaba mediante un hook de preinstalación en package.json, que primero ejecutaba bw_setup.js para instalar el runtime Bun, y luego ejecutaba bw1.js — la carga maliciosa real (OX Security, 2026). No se requería interacción del usuario.

Los atacantes no vulneraron directamente a Bitwarden. Comprometieron una GitHub Action de terceros utilizada en el pipeline de CI/CD de Bitwarden, obtuvieron acceso a los secretos del flujo de trabajo, incluyendo un token de npm, y lo usaron para publicar el paquete malicioso. El ataque utilizó el pipeline de CI/CD como punto de entrada — consistente con el patrón más amplio identificado en la campaña de cadena de suministro de Checkmarx. La cadena "Shai-Hulud: The Third Coming" incrustada en el paquete confirmó que esta era la tercera iteración de una campaña organizada y continua — no un incidente aislado oportunista.

De manera crítica, ninguna bóveda de usuarios se vio afectada. La arquitectura de conocimiento cero de Bitwarden significaba que el servidor nunca almacenó contraseñas maestras ni acceso a datos de usuario descifrados. Incluso con el CI/CD comprometido, el atacante no pudo alcanzar lo que la arquitectura estaba diseñada para proteger.

Qué hizo el malware

La carga maliciosa (la tercera fase del gusano «Shai-Hulud») realizó la siguiente secuencia:

1. Verificación de idioma ruso. Antes de hacer cualquier otra cosa, el malware verificaba si la máquina anfitriona tenía configurado el idioma ruso. Si era así, salía inmediatamente. Esta es una técnica estándar de autoprotección: los autores evitan infectar sus propias máquinas de desarrollo, y apunta fuertemente a un actor de amenazas de habla rusa.
2. Recolección de credenciales. Se dirigió a tokens de GitHub y npm, directorios .ssh, archivos .env, historial del shell, variables de entorno de GitHub Actions, credenciales de AWS, GCP y Azure, e información del GitHub Runner.
3. Targeting de herramientas de IA. Los archivos de configuración para asistentes de codificación con IA (Claude, Kiro, Cursor, Codex CLI y Aider) fueron objetivo explícito, reflejando cuán profundamente estas herramientas están ahora integradas en los flujos de trabajo de los desarrolladores y cuánto contexto sensible almacenan localmente.
4. Exfiltración cifrada vía GitHub. Todos los datos robados fueron cifrados con AES-256-GCM usando cifrado asimétrico — lo que significa que solo la clave privada del actor de amenazas puede descifrarlos. Los datos se cargaron a un repositorio público de GitHub recién creado en la propia cuenta de la víctima, con archivos nombrados results-TIMESTAMP-ID.json. Un canal secundario exfiltró datos a audit.checkmarx[.]cx, un dominio que suplantaba la plataforma legítima de Checkmarx. Usar GitHub como servidor de C2 es deliberado: el tráfico a github.com rara vez es marcado por herramientas de seguridad y no puede rastrearse hasta un dominio controlado por el actor de amenazas.
5. Auto-propagación. Esto es lo que convierte a Shai-Hulud en un gusano, no solo un ladrón. Si se encontraban tokens de npm válidos, el malware descargaba uno de los propios paquetes de npm de la víctima, inyectaba código malicioso en él y republicaba una nueva versión — propagando la infección a los usuarios aguas abajo de la víctima automáticamente.
6. Propagación por pipeline. Si se encontraban tokens de GitHub, el malware inyectaba flujos de trabajo maliciosos de Actions en repositorios accesibles, extrayendo secretos de CI/CD y extendiendo el compromiso a cada pipeline al que el token del desarrollador pudiera acceder.

Como señaló StepSecurity: «Un solo desarrollador con @bitwarden/cli@2026.4.0 instalado puede convertirse en el punto de entrada para un compromiso más amplio de la cadena de suministro, con el atacante obteniendo acceso persistente de inyección de flujos de trabajo a cada pipeline de CI/CD al que el token del desarrollador pueda acceder».

OX Security confirmó que los datos de exfiltración cifrados ya estaban presentes en repositorios públicos de GitHub en el momento del descubrimiento — máquinas reales habían sido comprometidas antes de que el paquete fuera retirado.

El incidente de Checkmarx: 23 de marzo de 2026

Esta campaña no comenzó en abril. Según la actualización de seguridad de Checkmarx, el 23 de marzo de 2026, se publicaron versiones maliciosas de dos plugins de OpenVSX aproximadamente a las 02:53 UTC y permanecieron disponibles hasta las 15:41 UTC. Dos flujos de trabajo de GitHub Actions (ast-github-action y kics-github-action) también fueron comprometidos. Las organizaciones que descargaron estos artefactos durante ese período y los ejecutaron quedaron expuestas.

El incidente de Bitwarden CLI de abril siguió el mismo vector de cadena de suministro de GitHub Actions, confirmando una campaña activa y en evolución en lugar de un incidente aislado.

La lección arquitectónica

El incidente de Bitwarden refleja un patrón que la industria sigue reaprendiendo: los controles de seguridad a nivel de proceso pueden eludirse. Las restricciones arquitectónicas no. Un sistema diseñado de manera que comprometer un componente no proporcione nada útil es fundamentalmente más resiliente que uno que depende de que todos los controles se mantengan simultáneamente.

Passwork está construido sobre este principio. Las credenciales se cifran del lado del cliente antes de que lleguen al servidor. El servidor almacena texto cifrado. Una brecha de base de datos, un servidor comprometido o un administrador desleal no obtiene nada sin las claves del lado del cliente. La publicación de Passwork CLI en PyPI sigue un proceso semimanual desde máquinas de confianza — el compromiso de CI/CD no puede desencadenar una publicación automatizada de un artefacto malicioso.

La pregunta que debe hacerse sobre cualquier herramienta en su stack: si este componente se compromete, ¿qué obtiene realmente el atacante?

¿Está migrando desde otro gestor de contraseñas? Passwork ofrece un descuento del 10 % a los equipos que cambien desde una solución de la competencia. Prueba Passwork gratis

Otros ataques notables a la cadena de suministro (2020–2026)

El incidente de Bitwarden CLI es el más reciente en una serie de compromisos de alto impacto a la cadena de suministro que han reconfigurado cómo los equipos de seguridad piensan sobre el riesgo de terceros.

Cada incidente comparte un patrón estructural: los atacantes encontraron un mecanismo de entrega automatizado y de confianza e insertaron su carga donde se ejecutaría sin escrutinio:

• event-stream estableció que la confianza en los mantenedores de código abierto es explotable a escala
• SolarWinds demostró que incluso las actualizaciones firmadas y distribuidas por el proveedor pueden convertirse en arma
• XZ Utils demostró que la ingeniería social a largo plazo de los mantenedores es una vía de ataque viable
• Codecov probó que la propia infraestructura de CI/CD es un objetivo de alto valor — los secretos recolectados de los pipelines de compilación pueden desbloquear organizaciones enteras
• El caso de 3CX introdujo un nuevo modelo de amenaza: un ataque a la cadena de suministro utilizado como punto de entrada para otro ataque a la cadena de suministro

La superficie de ataque se ha expandido con cada iteración. Lo que comenzó como secuestros aislados de paquetes ha evolucionado hacia campañas coordinadas y multietapa que apuntan a toda la cadena de entrega de software.

El verdadero coste de las vulnerabilidades en la cadena de suministro

Los ataques a la cadena de suministro son costosos — y el coste se está acelerando. Según el análisis de Wiz de 2025, los costes globales de los ataques a la cadena de suministro de software se estiman en 60.000 millones de dólares en 2025 y se proyecta que alcancen los 138.000 millones de dólares para 2031.

Estas cifras reflejan los costes directos de respuesta a incidentes, sanciones regulatorias, daño reputacional y los costes derivados que soportan los clientes afectados — no solo el proveedor vulnerado.

La dimensión regulatoria agrava la exposición financiera. Las organizaciones que operan bajo GDPR, HIPAA, SOC 2 o ISO 27001 enfrentan requisitos obligatorios de notificación de brechas y posibles multas cuando los incidentes de la cadena de suministro resultan en acceso no autorizado a datos personales o regulados. Un pipeline de CI/CD comprometido que exfiltra variables de entorno que contienen credenciales de base de datos no es solo un incidente operativo — es un evento de cumplimiento.

Para organizaciones con programas de seguridad maduros, el coste más difícil de cuantificar es la confianza. Cuando una herramienta de desarrollo utilizada en cientos de pipelines se compromete, el esfuerzo de remediación se extiende mucho más allá de parchear: cada secreto que podría haber sido expuesto debe tratarse como comprometido y rotarse.

Cómo prevenir ataques a la cadena de suministro en entornos de CI/CD

Prevenir ataques a la cadena de suministro requiere controles en cada capa del proceso de entrega de software. Las siguientes prácticas abordan los vectores de ataque específicos vistos en las campañas de 2026.

• Fije las versiones de dependencias y verifique los hashes. Nunca use rangos de versión flotantes en pipelines de producción. Fije versiones exactas y valide las sumas de verificación contra un estado conocido como bueno. Esto no evitará el compromiso de una cuenta de mantenedor, pero elimina la exposición automática a versiones maliciosas recién publicadas.
• Aplique compilaciones firmadas y atestación de procedencia. Un artefacto firmado con una cadena de compilación verificable es significativamente más difícil de manipular sin ser detectado.
• Genere y mantenga una lista de materiales de software (SBOM). Un SBOM le proporciona un inventario completo de cada componente en su software, incluyendo dependencias transitivas. Cuando se divulga un nuevo paquete malicioso o vulnerabilidad, puede determinar inmediatamente si está afectado — sin auditoría manual.
• Ejecute análisis continuo de composición de software (SCA). Los escaneos estáticos y únicos son insuficientes. Las herramientas SCA deben ejecutarse en cada solicitud de extracción y cada actualización de dependencia, marcando nuevos paquetes, hooks de preinstalación inusuales y llamadas de red inesperadas en scripts de paquetes.
• Aplique principios de confianza cero a los flujos de trabajo de CI/CD. Los flujos de trabajo de GitHub Actions deben operar con los permisos mínimos requeridos. Use tokens efímeros con alcance a trabajos individuales, no tokens de acceso personal de larga duración. Audite los archivos de flujo de trabajo para referencias a Actions de terceros y fíjelos a SHAs de commit específicos, no a etiquetas mutables.
• Rote los secretos de CI/CD regularmente y después de cada incidente. Trate los secretos en entornos de CI/CD como credenciales de corta duración. Cualquier token, clave de API o clave SSH que pudiera haber sido expuesto debe rotarse inmediatamente. Un proceso estructurado de gestión de secretos hace esto operacionalmente factible en lugar de una carrera manual.
• Monitorice comportamientos anómalos de exfiltración. El malware de Bitwarden CLI hizo conexiones salientes a audit.checkmarx[.]cx. El monitoreo a nivel de red del tráfico de salida del ejecutor de CI habría marcado esto. Cree una lista blanca de destinos salientes esperados para entornos de compilación y alerte sobre desviaciones.
• Audite las configuraciones de herramientas de codificación con IA. La campaña de 2026 se dirigió explícitamente a archivos de configuración de Claude, Cursor, Aider y herramientas similares. Estos archivos a menudo contienen claves de API y contexto sobre la base de código. Trátelos como artefactos sensibles e inclúyalos en el alcance de su escaneo de secretos.

Conclusión

Los ataques a la cadena de suministro funcionan porque explotan lo único que las organizaciones no pueden auditar fácilmente: la confianza incorporada en los sistemas automatizados. Cada dependencia que su pipeline descarga, cada GitHub Action que su flujo de trabajo referencia, cada plugin que su IDE carga — cada uno es un punto de entrada potencial.

Las campañas de Bitwarden CLI y Checkmarx de 2026 hacen concreta la amenaza. Un solo paquete comprometido, instalado silenciosamente por un ejecutor de CI, puede exponer cada secreto en el entorno de un desarrollador y propagarse a través de cada pipeline al que ese token pueda acceder. El ataque no se anuncia. Se ejecuta como parte de su proceso de compilación normal.

Defenderse contra esto requiere más que auditorías periódicas. Requiere arquitectura de confianza cero aplicada a la cadena de suministro de software: dependencias fijadas, artefactos firmados, seguimiento de SBOM, SCA continuo y credenciales efímeras con alcance limitado. Los secretos deben tratarse como perecederos — rotados regularmente, almacenados de forma segura y nunca incrustados en código o archivos de entorno sin gobernanza.

Una gestión robusta de secretos es un control fundamental aquí. Cuando las credenciales se almacenan en una bóveda estructurada con acceso controlado como Passwork en lugar de estar dispersas en archivos .env y estaciones de trabajo de desarrolladores, el radio de explosión de un compromiso de la cadena de suministro se reduce significativamente. Los atacantes pueden robar lo que pueden alcanzar. Haga que sea nada.

¿Listo para reducir su radio de explosión? Passwork proporciona a su equipo una bóveda de secretos estructurada con acceso basado en roles, registro de auditoría completo y una implementación autoalojada que mantiene las credenciales fuera de la infraestructura de terceros. Los equipos que migran desde otro gestor de contraseñas reciben un 10 % de descuento. Explorar Passwork

Preguntas frecuentes: ataques a la cadena de suministro

¿Qué es un ataque a la cadena de suministro en ciberseguridad?

Un ataque a la cadena de suministro es un ciberataque que compromete un proveedor externo de confianza, un paquete de código abierto o un componente de software para obtener acceso a objetivos aguas abajo. En lugar de atacar directamente a una organización, los adversarios insertan cargas maliciosas en actualizaciones de software, pipelines de compilación o dependencias que el objetivo instala automáticamente.

¿Cómo funcionó el ataque a la cadena de suministro de Bitwarden CLI?

El paquete malicioso @bitwarden/cli@2026.4.0 se publicó en npm el 22 de abril de 2026, con un ladrón de credenciales incrustado en bw1.js y ejecutado mediante un hook de preinstalación. Recolectó tokens de GitHub, claves SSH, variables de entorno, secretos de nube y configuraciones de herramientas de codificación con IA, y luego exfiltró los datos — cifrados con AES-256-GCM — a un dominio que suplantaba a Checkmarx.

¿Cuál es la diferencia entre un ataque a la cadena de suministro y un ciberataque directo?

Un ataque directo apunta a los propios sistemas de la víctima — su red, credenciales o aplicaciones. Un ataque a la cadena de suministro apunta en cambio a un proveedor o dependencia de confianza, utilizando esa confianza para eludir las defensas de la víctima. La víctima instala o ejecuta el componente comprometido voluntariamente, a través de procesos normales, lo que hace que la detección sea significativamente más difícil.

¿Qué son las dependencias transitivas y por qué importan para la seguridad?

Las dependencias transitivas son componentes de software de los que su código depende indirectamente — bibliotecas importadas por sus dependencias directas, que a su vez importan otras. Rara vez se auditan con el mismo rigor que el código propio, pero se ejecutan en su entorno con los mismos privilegios. Un compromiso en cualquier parte de esa cadena puede afectar a su aplicación.

¿Qué es un SBOM y cómo ayuda a prevenir ataques a la cadena de suministro?

Una lista de materiales de software (SBOM) es un inventario estructurado de cada componente en un producto de software, incluyendo todas las dependencias directas y transitivas. Cuando se divulga un paquete malicioso o vulnerabilidad, un SBOM permite a los equipos de seguridad determinar inmediatamente si su software está afectado — sin rastrear manualmente árboles de dependencias en cada proyecto.

¿Qué prácticas de seguridad de GitHub Actions reducen el riesgo de la cadena de suministro?

Fije todas las Actions de terceros a SHAs de commit específicos en lugar de etiquetas de versión mutables. Use tokens efímeros con alcance de trabajo en lugar de tokens de acceso personal de larga duración. Restrinja los permisos de flujo de trabajo al mínimo requerido. Audite todos los archivos de flujo de trabajo para referencias inesperadas de terceros, y monitorice el tráfico de salida del ejecutor de CI para conexiones salientes anómalas.

¿Cómo deben responder las organizaciones si se instaló un paquete comprometido en su pipeline de CI/CD?

Trate todos los secretos accesibles durante los trabajos de compilación afectados como comprometidos. Rote cada token, clave de API, clave SSH y credencial de nube que pudiera haber sido expuesto. Revise los archivos de flujo de trabajo de GitHub Actions para modificaciones no autorizadas. Audite los registros de acceso del repositorio para commits o ejecuciones de flujo de trabajo inesperados. Reporte el incidente según sus obligaciones regulatorias bajo GDPR, HIPAA o los marcos aplicables.

Ataques de fuerza bruta en 2026: tipos, ejemplos y cómo prevenirlos

Clústeres de GPU, listas de palabras asistidas por IA, botnets de 2,8 millones de dispositivos. La fuerza bruta ha escalado. Esta guía cubre seis variantes de ataque, casos reales de 2025 y una estrategia de defensa en capas que su equipo puede implementar hoy.

Passwork BlogAlex Muntyan

Últimas noticias de NIS2: qué cambió y qué significa para las empresas de la UE

El 84% de las organizaciones en el ámbito admiten que no están preparadas. Bélgica estableció la primera fecha límite de evaluación de conformidad el 18 de abril de 2026. Los Países Bajos están a días de la aplicación. Aquí está dónde se encuentra la ola regulatoria y qué deben hacer los líderes de TI ahora.

Passwork BlogAlex Muntyan

Caos de contraseñas: por qué es un problema empresarial y cómo solucionarlo

Una contraseña olvidada cuesta 70 dólares. Una brecha cuesta 4,44 millones de dólares. Ambas empiezan de la misma manera — credenciales compartidas por Slack, almacenadas en hojas de cálculo, nunca rotadas. Aquí está lo que realmente cuesta el caos de contraseñas y cómo eliminarlo.

Passwork BlogAlex Muntyan

Why breach a well-defended corporate network when you can compromise an npm package with millions of weekly downloads and slip silently into thousands of those networks at once?

On April 22, 2026, a credential stealer shipped inside a package with 250,000 monthly downloads. It executed silently at install time, required no user interaction, and was pulled automatically by CI runners across dozens of pipelines. By the time security teams detected the compromise, real machines had already been compromised. Just a routine dependency update.

This is the core vulnerability of modern infrastructure: you are only as secure as your weakest dependency. When attackers can't breach your perimeter directly, they compromise something you already trust and ride it straight into your environment.

The 2026 supply chain campaigns prove this isn't theoretical. Three coordinated attacks across different vectors hit production systems within weeks of each other. Each one followed the same pattern: identify a trusted package, inject malicious code, wait for automation to do the work.

These aren't isolated incidents. They're proof that supply chain attacks have become industrialized, coordinated, and accelerating.

Key takeaways

• Supply chain attacks bypass your perimeter by weaponizing trust. Packages, CI workflows, and plugins execute in your environment with full privileges. No phishing link required. The attacker becomes part of your normal build process.
• The 2026 campaigns exposed three distinct attack surfaces simultaneously. CI/CD pipeline compromise (Bitwarden CLI), transitive dependency injection (Axios), and OAuth token theft (Vercel/Context.ai) demonstrate that attackers are no longer targeting single vectors.
• Transitive dependencies are your largest blind spot. Your application imports ten packages directly, but each pulls in dozens more. These invisible layers execute with the same privileges as your code, yet most teams never audit them. One compromised transitive dependency can propagate through hundreds of downstream projects.
• Secrets in CI/CD pipelines are the primary target. A single build job that harvests a GitHub token can propagate a compromise across every repository and pipeline that token can reach. The attacker doesn't need to break into your infrastructure. They just need to extract what's already there.
• Architecture beats process. A system designed so that compromising one component yields nothing useful is fundamentally more resilient than one that relies on every control holding simultaneously. Secrets should be encrypted, scoped, and rotated, not scattered across environment files and developer machines.
• Defence requires continuous controls, not periodic audits. Pinned dependencies, signed builds, SBOM tracking, scoped ephemeral tokens, and secrets rotation must run on every commit, not every quarter. The attack window is measured in hours. Your response window must be faster.

What is a supply chain attack

A supply chain attack occurs when an adversary compromises a trusted third-party vendor, open-source package, or software component to deliver a malicious payload to downstream organizations. Instead of attacking your infrastructure directly, the attacker inserts malicious code into something you already trust, and your own systems pull it in automatically.

The attack exploits a fundamental asymmetry: you audit your own code rigorously, but you install third-party dependencies with minimal scrutiny. The attacker knows this. They know that compromising a single trusted package reaches thousands of organizations in parallel, through their own build pipelines, with their own credentials.

Why transitive dependencies make the attack surface exponential

Modern software is built on layers of dependencies. Your application may directly import ten packages, but each of those imports dozens more. These transitive dependencies execute in your environment with the same privileges as first-party code, yet they are rarely audited at all.

A single compromised transitive dependency can propagate through hundreds of downstream projects without any of them knowing they've imported it. The attacker doesn't need to compromise the packages you explicitly depend on. They can compromise something three or four layers deep in your dependency tree, and the malicious code still executes in your CI/CD pipeline.

Supply chain attack vectors

The scale of the threat in 2025–2026

Supply chain attacks are no longer rare incidents. They are now an industrialized threat.

• Over 70% of organizations experienced at least one material third-party cybersecurity incident in the past year (SecurityScorecard, 2025).
• 454,600+ new malicious packages were identified in registries in 2025, representing a 75% year-over-year increase. These packages were cumulatively downloaded 9.8 trillion times across npm, PyPI, Maven Central, NuGet, and Hugging Face (Sonatype, 2026).
• $60 billion estimated global cost of software supply chain attacks in 2025, projected to reach $138 billion by 2031 (Cybersecurity Ventures, 2025).
• 2.6 billion weekly downloads affected by the Shai-Hulud worm campaign targeting npm packages (Trend Micro, 2025).

The regulatory dimension compounds the financial exposure. Organizations operating under GDPR, HIPAA, SOC 2, or ISO 27001 face mandatory breach notification requirements and potential fines when supply chain incidents result in unauthorized access to personal or regulated data.

The anatomy of a modern supply chain attack

A supply chain attack follows a predictable lifecycle:

• Phase 1: Reconnaissance. Attackers scan public repositories, package registries, and CI/CD configurations for weak links: unprotected GitHub tokens in workflow logs, packages with high download counts and minimal maintainers, Actions workflows with excessive permissions.
• Phase 2: Upstream compromise. The attacker gains write access to a trusted artifact by stealing maintainer credentials, submitting a malicious pull request that passes code review, or compromising a CI/CD pipeline.
• Phase 3: Dormancy. The compromised artifact is published and waits. Automated systems pull the update without human review.
• Phase 4: Downstream delivery. Developers and pipelines install the infected version through normal, trusted channels. The credential stealer executes as part of the standard build process.
• Phase 5: Privilege escalation and propagation. With initial access established, the attacker harvests secrets: API tokens, SSH keys, environment variables, cloud credentials. GitHub tokens are particularly valuable because they can be weaponized to inject malicious workflows into every repository the token can reach.

Unprotected secrets in CI/CD pipelines are exactly what attackers harvest in phase five. Passwork centralizes credential management and audit logging, so you can track which secrets were accessed, when, and by whom. This turns CI/CD from a blind spot into a controlled environment. Try Passwork free

Three major supply chain attacks of 2026

The 2026 campaigns demonstrate a coordinated shift in attack sophistication. Rather than isolated package hijacks, threat actors targeted three distinct vectors simultaneously, each exposing different layers of the software supply chain.

Bitwarden CLI compromise (April 2026)

On April 22, 2026, a malicious version of the Bitwarden CLI (@bitwarden/cli@2026.4.0) was published to the npm registry. The package has over 250,000 monthly downloads. The malicious code was embedded in bw1.js and triggered via a preinstall hook in package.json (OX Security).

The attackers didn't breach Bitwarden directly. They compromised a third-party GitHub Action used in Bitwarden's CI/CD pipeline, gained access to workflow secrets including an npm token, and used it to publish the malicious package. The string "Shai-Hulud: The Third Coming" embedded in the package confirmed this was the third iteration of an ongoing, organized campaign.

What the malware did

The malicious payload performed the following sequence:

• Russian-language check. Before doing anything else, the malware checked whether the host machine had Russian language configured. If so, it exited immediately. This is a standard self-protection technique: the authors avoid infecting their own development machines, and it points strongly to a Russian-speaking threat actor.
• Credential harvesting. It targeted GitHub and npm tokens, .ssh directories and private keys, .env files and shell history, GitHub Actions environment variables, and AWS, GCP, and Azure credentials. Configuration files for AI coding assistants (Claude, Cursor, Aider, Codex CLI, and Kiro) were explicitly targeted, reflecting how deeply these tools are now embedded in developer workflows and how much sensitive context they store locally.
• Encrypted exfiltration via GitHub. All stolen data was encrypted with AES-256-GCM using asymmetric encryption, meaning only the threat actor's private key can decrypt it. The data was uploaded to a newly created public GitHub repository on the victim's own account, with files named results-TIMESTAMP-ID.json. A secondary channel exfiltrated data to audit.checkmarx[.]cx, a domain impersonating the legitimate Checkmarx platform. Using GitHub as a C2 server is deliberate: traffic to github.com is rarely flagged by security tools and cannot be traced to a threat-actor-controlled domain.
• Self-propagation. This is what makes Shai-Hulud a worm, not just a stealer. If valid npm tokens were found, the malware downloaded one of the victim's own npm packages, injected malicious code into it, and republished a new version, spreading the infection to the victim's downstream users automatically.
• Pipeline propagation. If GitHub tokens were found, the malware injected malicious Actions workflows into accessible repositories, extracting CI/CD secrets and extending the compromise to every pipeline the developer's token could reach.

As StepSecurity noted: "A single developer with @bitwarden/cli@2026.4.0 installed can become the entry point for a broader supply chain compromise, with the attacker gaining persistent workflow injection access to every CI/CD pipeline the developer's token can reach."

OX Security confirmed that encrypted exfiltration data was already present in public GitHub repositories at the time of discovery. Real machines had been compromised before the package was pulled.

The architectural lesson

The Bitwarden incident reflects a pattern the industry keeps relearning: process-level security controls can be bypassed. Architectural constraints cannot. A system designed so that compromising one component yields nothing useful is fundamentally more resilient than one that relies on every control holding simultaneously.

Passwork is built on this principle. Credentials are encrypted client-side before they ever reach the server. The server stores ciphertext. A database breach, a compromised server, or a rogue administrator yields nothing without the client-side keys. Passwork CLI publishing to PyPI follows a semi-manual process from trusted machines — CI/CD compromise cannot trigger an automated release of a malicious artifact.

Axios (March 2026)

On March 31, 2026, the widely used Axios npm package (100+ million weekly downloads) was compromised when an attacker hijacked the maintainer's credentials and published malicious versions. But the attack's true sophistication lay in how it exploited transitive dependencies.

Instead of embedding malware directly in Axios, the attackers created a fake npm package named plain-crypto-js@4.2.1, designed to appear legitimate and similar to the real crypto-js library. They then modified Axios to import plain-crypto-js as a dependency.

When developers installed the compromised Axios version, npm automatically resolved and installed plain-crypto-js. The fake package contained a post-install script that executed before any other code ran, downloading and executing a Remote Access Trojan (RAT) payload.

Transitive dependencies are your largest unaudited attack surface. Security teams often audit direct dependencies carefully, but transitive dependencies are rarely inspected. The plain-crypto-js attack exploited this blind spot by combining typosquatting, automated execution, transitive insertion, and ephemeral distribution. The attack was attributed to Sapphire Sleet, a threat actor group known for supply chain targeting.

Vercel and Context.ai (February–April 2026)

The Vercel breach began not at Vercel, but at Context.ai, a small AI startup that provides AI-powered development tools. In February 2026, an employee at Context.ai was infected with Lumma Stealer, an infostealer malware that harvested credentials and OAuth tokens from the infected machine.

With access to Context.ai's OAuth tokens, the attacker could access Vercel's internal systems, retrieve OAuth tokens that Vercel customers had granted to Context.ai, exfiltrate environment variables containing deployment secrets, and access customer AWS and Google Workspace credentials.

The breach remained undetected for approximately two months. By the time Vercel discovered the compromise in April 2026, OAuth tokens from multiple customers had been stolen.

Why OAuth trust is a critical vulnerability

OAuth tokens are designed to delegate access without sharing passwords. If the application is compromised, the token is compromised. The token looks legitimate because it is legitimate. It's just being used by an attacker instead of the intended application. OAuth provides no mechanism to distinguish between authorized and unauthorized use of a valid token once it's been stolen.

What makes the Vercel incident significant is the speed of the attack chain. From initial infection at Context.ai to full compromise of Vercel customers took approximately two months, faster than many organizations' quarterly security review cycles. The attack demonstrates how a single compromised third-party application can weaponize trust relationships between platforms, turning OAuth delegation into a supply chain vector.

Historical context: Notable supply chain attacks (2017–2025)

Each incident shares a structural pattern: attackers found a trusted, automated delivery mechanism and inserted their payload where it would execute without scrutiny.

How to defend against supply chain attacks

Preventing supply chain attacks requires controls at every layer of the software delivery process.

Level 1: Dependency control

• Pin exact versions and verify checksums. Never use floating version ranges in production. Pin exact versions and validate checksums against a known-good state. This won't prevent a maintainer account compromise, but it eliminates automatic exposure to newly published malicious versions.
• Generate and maintain a software bill of materials (SBOM). An SBOM gives you a complete inventory of every component in your software, including transitive dependencies. When a vulnerability or malicious package is disclosed, you can immediately determine whether you're affected without manual auditing.
• Run continuous software composition analysis (SCA). SCA tools should run on every pull request and every dependency update, flagging new packages and their provenance, unusual preinstall hooks or post-install scripts, unexpected network calls in package scripts, and known malicious packages.

Level 2: Artifact integrity

• Enforce signed builds and provenance attestation. A signed artifact with a verifiable build chain is significantly harder to tamper with undetected. Use tools like Sigstore to sign and verify build artifacts.
• Verify package signatures at install time. npm, PyPI, and other registries support package signing. Verify signatures before installing dependencies.

Level 3: CI/CD infrastructure protection

• Apply zero-trust principles to CI/CD workflows. GitHub Actions workflows should operate with minimum permissions required: use ephemeral tokens scoped to individual jobs, not long-lived personal access tokens; pin third-party Actions to specific commit SHAs, not mutable tags; and use OIDC tokens instead of static credentials where possible.
• Rotate CI/CD secrets regularly and after every incident. Treat secrets in CI/CD environments as short-lived credentials. Any token, API key, or SSH key that could have been exposed should be rotated immediately.
• Monitor for anomalous exfiltration behavior. Allowlist expected outbound destinations for build environments and alert on deviations.

Level 4: Developer perimeter defense

• Audit AI coding tool configurations. The 2026 campaign explicitly targeted configuration files for Claude, Cursor, and Aider. Treat them as sensitive artifacts and include them in your secrets scanning scope.
• Audit OAuth applications and grants. Review which third-party applications have OAuth access to your GitHub, Vercel, and cloud accounts. Revoke access for applications no longer in use.
• Implement secrets scanning in your development environment. Scan developer workstations, local Git repositories, and IDE configurations for exposed credentials.

Centralized secrets management as the foundation

All of these controls depend on one critical principle: secrets must be stored securely, accessed with minimal privilege, and rotated rapidly.

Process controls fail without architectural constraints. A developer who needs to rotate a GitHub token shouldn't have to manually update it in five different .env files, three CI/CD platforms, and two deployment tools. That friction creates incentives to skip rotation or reuse tokens across environments.

Centralized secrets management solves this. A structured vault provides a single source of truth for all credentials, role-based access control so developers only access the secrets they need, audit logging of every access and modification, and rapid rotation of secrets across all systems that use them.

When a supply chain incident occurs and you need to rotate every GitHub token, npm token, and cloud credential that could have been exposed, a centralized vault makes this operationally feasible. Without it, rotation becomes a manual, error-prone scramble, and incomplete rotations leave attack vectors open.

Conclusion

Supply chain attacks work because they exploit the one thing organizations can't easily audit: the trust embedded in automated systems. Every dependency your pipeline pulls, every GitHub Action your workflow references, every plugin your IDE loads — each is a potential entry point.

The 2026 Bitwarden CLI, Axios, and Vercel campaigns make the threat concrete. A single compromised package, installed silently by a CI runner, can expose every secret in a developer's environment and propagate through every pipeline that token can reach. The attack doesn't announce itself. It executes as part of your normal build process.

Defending against this requires zero-trust architecture applied to the software supply chain: pinned dependencies, signed artifacts, SBOM tracking, continuous SCA, and short-lived scoped credentials. Secrets must be treated as perishable — rotated regularly, stored securely, and never embedded in code or environment files without governance.

Robust secrets management is a foundational control here. When credentials are stored in a structured, access-controlled vault like Passwork rather than scattered across .env files and developer workstations, the blast radius of a supply chain compromise shrinks significantly. Attackers can steal what they can reach. Make it nothing.

Ready to reduce your blast radius? Passwork gives your team a structured secrets vault with role-based access, full audit logging, and a self-hosted deployment that keeps credentials off third-party infrastructure. Teams migrating from a another password manager receive a 10% migration discount. Try Passwork free

FAQ: Supply chain attacks

What is a supply chain attack in cybersecurity?

A supply chain attack is a cyberattack that compromises a trusted third-party vendor, open-source package, or software component to gain access to downstream targets. Instead of attacking an organization directly, adversaries insert malicious payloads into software updates, build pipelines, or dependencies that the target installs automatically.

What is the Shai-Hulud worm?

Shai-Hulud is a worm campaign that compromised the Bitwarden CLI npm package in April 2026. It's called a worm because it self-propagates: after harvesting credentials, it injects malicious code into the victim's own npm packages and republishes them, spreading the infection to downstream users automatically. The name "Shai-Hulud: The Third Coming" indicates this was the third iteration of an ongoing, organized campaign.

Why are OAuth tokens a dangerous attack vector?

OAuth tokens are designed to delegate access without sharing passwords. If an application (like Context.ai) is compromised, the OAuth tokens it holds are compromised. The token looks legitimate because it is legitimate — it's just being used by an attacker instead of the intended application. The victim has no way to know their OAuth grant has been weaponized until the damage is discovered.

What is a transitive dependency?

A transitive dependency is a software component that your code relies on indirectly — a library imported by your direct dependencies, which in turn imports others. Transitive dependencies are rarely audited with the same rigor as first-party code, yet they execute in your environment with the same privileges. The Axios attack exploited this by injecting a fake transitive dependency (plain-crypto-js) that was automatically installed when developers installed the compromised Axios package.

How did the Bitwarden CLI supply chain attack work?

The malicious @bitwarden/cli@2026.4.0 package was published to npm on April 22, 2026, with a credential stealer embedded in bw1.js and executed via a preinstall hook. It harvested GitHub tokens, SSH keys, environment variables, cloud secrets, and AI coding tool configurations, then exfiltrated the data — encrypted with AES-256-GCM — to a domain impersonating Checkmarx.

What is the difference between a supply chain attack and a direct cyberattack?

A direct attack targets the victim's own systems — their network, credentials, or applications. A supply chain attack targets a trusted supplier or dependency instead, using that trust to bypass the victim's defenses. The victim installs or runs the compromised component voluntarily, through normal processes, which makes detection significantly harder.

What are transitive dependencies and why do they matter for security?

Transitive dependencies are software components that your code relies on indirectly — libraries imported by your direct dependencies, which in turn import others. They are rarely audited with the same rigor as first-party code, yet they execute in your environment with the same privileges. A compromise anywhere in that chain can affect your application.

What is an SBOM and how does it help prevent supply chain attacks?

A software bill of materials (SBOM) is a structured inventory of every component in a software product, including all direct and transitive dependencies. When a malicious package or vulnerability is disclosed, an SBOM lets security teams immediately determine whether their software is affected — without manually tracing dependency trees across every project.

What GitHub Actions security practices reduce supply chain risk?

Pin all third-party Actions to specific commit SHAs rather than mutable version tags. Use ephemeral, job-scoped tokens instead of long-lived personal access tokens. Restrict workflow permissions to the minimum required. Audit all workflow files for unexpected third-party references, and monitor CI runner egress traffic for anomalous outbound connections.

How should organizations respond if a compromised package was installed in their CI/CD pipeline?

Treat all secrets accessible during the affected build jobs as compromised. Rotate every token, API key, SSH key, and cloud credential that could have been exposed. Review GitHub Actions workflow files for unauthorized modifications. Audit repository access logs for unexpected commits or workflow runs. Report the incident per your regulatory obligations under GDPR, HIPAA, or applicable frameworks.

Brute force attacks in 2026: Types, examples & how to prevent them

GPU clusters, AI-assisted wordlists, botnets of 2.8M devices. Brute force has scaled. This guide covers six attack variants, real-world cases from 2025, and a layered defense strategy your team can implement today.

Passwork BlogAlex Muntyan

NIS2 latest news: What changed and what it means for EU businesses

84% of in-scope organizations admit they’re not ready. Belgium set the first conformity assessment deadline on April 18, 2026. The Netherlands is days away from enforcement. Here’s where the regulatory wave stands and what IT leaders need to act on now.

Passwork BlogAlex Muntyan

Password chaos: Why it’s a business problem and how to fix it

A forgotten password costs $70. A breach costs $4.44 million. Both start the same way — credentials shared over Slack, stored in spreadsheets, never rotated. Here’s what password chaos actually costs and how to eliminate it.

Passwork BlogAlex Muntyan

Einleitung

Um 3:14 Uhr nachts beobachtet niemand die Authentifizierungs-Logs. Ein Skript, das auf einer gemieteten Cloud-Instanz läuft, sendet seinen zehntausendsten Anmeldeversuch an ein VPN-Portal. Um 3:17 Uhr erhält es eine Antwort, die sich von den anderen unterscheidet. Zugriff gewährt. Keine Malware, kein Social Engineering, keine Insider-Bedrohung. Nur ein schwaches Passwort, automatisierte Geduld und eine Lücke im Monitoring.

Einer von drei erfolgreichen Angriffen auf Webanwendungen beginnt heute auf die gleiche Weise: Ein automatisiertes Skript durchläuft Anmeldedaten, bis etwas funktioniert. Laut dem Verizon Data Breach Investigations Report 2025 haben sich Brute-Force-Angriffe auf einfache Webanwendungen im letzten Jahr fast verdreifacht — von etwa 20 % auf 60 %. Dies signalisiert, dass automatisierte Credential-Angriffe zur primären Waffe geworden sind, nicht zum Ausweichplan.

Die zugrundeliegende Mechanik hat sich nicht geändert: Kombinationen ausprobieren, bis eine funktioniert. Was sich geändert hat, ist die Geschwindigkeit, Skalierung und Intelligenz hinter diesen Versuchen. Moderne GPU-Cluster, KI-gestützte Wordlist-Generierung und Botnets mit Millionen kompromittierter Geräte haben das, was einst ein langsamer, auffälliger Angriff war, in etwas Schnelles, Verteiltes und schwer Erkennbares verwandelt.

Dieser Artikel behandelt, was Brute-Force-Angriffe sind, wie sie sich 2026 entwickelt haben, die sechs Hauptvarianten, Praxisbeispiele aus 2025–2026 und eine mehrschichtige Verteidigungsstrategie, die Ihr Team heute implementieren kann.

Wichtigste Erkenntnisse

• Brute-Force-Angriffe sind automatisierte Credential-Angriffe — Skripte durchlaufen systematisch Benutzernamen- und Passwortkombinationen, bis eine funktioniert, und nutzen schwache, wiederverwendete oder vorhersagbare Passwörter aus — nicht Software-Schwachstellen.
• Sechs verschiedene Varianten zielen auf unterschiedliche Schwachstellen ab: Einfache Brute-Force, Dictionary-Angriffe, Credential Stuffing, Password Spraying, Reverse Brute Force und Hybrid-Angriffe — jede darauf ausgelegt, einen bestimmten Satz von Abwehrmaßnahmen zu umgehen.
• Moderne Hardware hat schwache Passwörter unhaltbar gemacht: Ein GPU-Cluster kann ein 8-Zeichen-MD5-gehashtes Passwort in Minuten knacken. Passwortlänge und sicheres Hashing bestimmen den realen Widerstand.
• Mehrschichtige Abwehrmaßnahmen funktionieren, aber nur bei konsequenter Durchsetzung. MFA, starke Passwortrichtlinien, Breach-Datenbank-Prüfung, Kontosperren, Rate Limiting und ein Passwort-Manager machen Brute-Force-Angriffe gemeinsam unpraktikabel. Jede einzelne Lücke reicht einem Angreifer zur Ausnutzung.
• Erkennung ist eine präventive Kontrolle, nicht nur eine reaktive. Das Erkennen von Angriffssignaturen — Spitzen bei fehlgeschlagenen Anmeldungen, langsame Spraying-Muster, unmögliche Reisen — gibt Ihrem Team Zeit, die Quelle zu blockieren, bevor Anmeldedaten validiert werden.
• Ein Passwort-Manager ist die strukturelle Lösung für Credential-Wiederverwendung — die Hauptursache hinter Credential Stuffing. Für Teams erzwingt er auch Rotation, markiert kompromittierte Anmeldedaten und schließt die Offboarding-Lücke, die veraltete Anmeldedaten jahrelang gültig lässt.

Was ist ein Brute-Force-Angriff?

Ein Brute-Force-Angriff verschafft unbefugten Zugriff auf ein System durch systematisches Ausprobieren jeder möglichen Kombination von Anmeldedaten (Benutzernamen, Passwörter oder Verschlüsselungsschlüssel), bis die richtige gefunden ist. Er nutzt menschliches Verhalten aus: schwache, wiederverwendete oder vorhersagbare Passwörter.

Stellen Sie es sich vor wie das Ausprobieren jedes Schlüssels an einem Schlüsselbund. Mit genügend Zeit und Rechenleistung wird irgendwann einer passen. Das Ziel des Angreifers ist es, diese Zeit auf etwas Praktikables zu reduzieren — und 2026 macht moderne Hardware das zunehmend erreichbar.

Brute-Force-Angriffe zielen auf Authentifizierungs-Endpunkte: Anmeldeseiten, SSH- und RDP-Dienste, VPN-Portale, API-Gateways und Admin-Panels. Jedes System, das einen Benutzernamen und ein Passwort akzeptiert, ist ein potenzielles Ziel.

Wie Brute-Force-Angriffe 2026 funktionieren

Im Kern ist ein Brute-Force-Angriff Automatisierung im großen Maßstab. Ein Angreifer setzt ein Skript oder Tool ein, das Credential-Kombinationen in schneller Folge an den Authentifizierungs-Endpunkt eines Zielsystems sendet. Das Skript protokolliert erfolgreiche Treffer und macht weiter.

Was 2026 von vor einem Jahrzehnt unterscheidet, ist die Infrastruktur hinter diesen Skripten.

Der KI- und Hardware-Faktor

Moderne Grafikkarten (ursprünglich für Gaming und maschinelles Lernen entwickelt) sind außergewöhnlich effizient bei paralleler Berechnung — genau das, was Password Cracking erfordert. Ein Cluster aus 12 NVIDIA RTX 5090 GPUs kann Hunderte Milliarden MD5-Hash-Kombinationen pro Sekunde testen (Hive Systems).

Bei schwach gehashten Anmeldedaten fällt ein 8-Zeichen-Passwort in Minuten — oder weniger. Gegen bcrypt mit modernen Kosteneinstellungen kann dieselbe Hardware Jahre benötigen. Der Unterschied liegt nicht an der Hardware des Angreifers. Es geht darum, ob das Zielsystem Passwörter sicher speichert.

Machine-Learning-Modelle, die auf geleakten Passwort-Datensätzen trainiert wurden (Tools wie PassGAN, basierend auf Generative Adversarial Networks), lernen reale Passwortverteilungen ohne menschengeschriebene Regeln. Sie sagen wahrscheinliche Muster voraus: An Namen angehängte Geburtstage, gängige Zeichensubstitutionen, kulturspezifische Phrasen.

In Tests gegen den RockYou-Breach-Datensatz traf PassGAN 47 % der echten Passwörter. In Kombination mit konventionellen Cracking-Tools wurden 24 % mehr Treffer erzielt als mit beiden Ansätzen allein. Der Suchraum schrumpft nicht durch Brute Force — er schrumpft durch Vorhersage.

Die Quantenbedrohung

Quantencomputing nutzt quantenmechanische Phänomene zur Informationsverarbeitung auf eine Weise, die klassische Computer nicht können. Während ein klassischer Prozessor Möglichkeiten sequenziell durcharbeitet, wertet ein Quantensystem viele Zustände gleichzeitig aus. Angewendet auf Kryptografie wird diese Parallelität zur direkten Bedrohung für die mathematischen Probleme, die der aktuellen Verschlüsselung zugrunde liegen.

Quantencomputing führt ein längerfristiges Risiko ein. IBMs Quanten-Roadmap prognostiziert, dass kryptografisch relevante Quantencomputer aktuelle asymmetrische Verschlüsselungsstandards noch in diesem Jahrzehnt untergraben könnten.

Quantenangriffe auf gehashte Passwörter bleiben theoretisch, aber Organisationen, die langlebige Geheimnisse und Verschlüsselungsschlüssel verwalten, sollten mit der Evaluierung von Post-Quanten-Kryptografiestandards beginnen — NIST hat seine ersten Post-Quanten-Standards 2024 finalisiert.

Botnets und verteilte Angriffe

Ein Botnet ist ein Netzwerk kompromittierter Geräte (Server, Router, IoT-Endpunkte, PCs), die ohne Wissen ihrer Besitzer von einem Angreifer ferngesteuert werden. Jedes Gerät fungiert als unabhängiger Knoten, der Anfragen senden, Systeme sondieren oder Anmeldeversuche übermitteln kann. Die Skalierung kann Millionen koordiniert arbeitender Maschinen erreichen.

Angreifer operieren selten von einer einzelnen IP aus. Moderne Brute-Force-Kampagnen nutzen Botnets, um Anmeldeversuche über verschiedene Quelladressen zu verteilen und so IP-basiertes Rate Limiting und geografische Sperren zu umgehen.

Anfang 2025 verfolgte die Shadowserver Foundation eine Kampagne, die täglich 2,8 Millionen IP-Adressen nutzte, um VPN-Anmeldeportale von Palo Alto Networks, Ivanti und SonicWall anzugreifen (BleepingComputer).

Die angreifenden Knoten waren überwiegend kompromittierte MikroTik-, Huawei- und Cisco-Router — gekaperte Geräte verteilt über Dutzende Länder, wobei der größte Cluster aus Brasilien stammte. Der Traffic wurde über Residential-Proxy-Netzwerke geleitet, sodass jeder Versuch wie normaler Heimanwender-Traffic aussah statt wie ein Bot. Standard-IP-basierte Abwehrmaßnahmen sahen etwas, das wie normaler Traffic aussah.

Arten von Brute-Force-Angriffen

Brute-Force-Angriffe teilen ein Prinzip: Zugang durch systematisches Testen von Anmeldedaten erlangen, bis etwas funktioniert. Die Methoden unterscheiden sich darin, was sie testen, woher sie ihre Daten beziehen und welche Abwehrmaßnahmen sie umgehen sollen.

1. Einfacher Brute-Force-Angriff

Die direkteste Variante: Jede mögliche Zeichenkombination wird der Reihe nach ausprobiert — aaa, aab, aac — bis ein Treffer gefunden wird. Keine Vorkenntnisse über das Ziel sind erforderlich. Der Angriff verlässt sich vollständig auf Rechenleistung.

Er ist nur gegen kurze oder einfache Passwörter effektiv. Bei einem 8-Zeichen-Passwort mit gemischten Zeichen können moderne GPU-Cluster die Suche in Stunden abschließen. Ab 12 Zeichen wird derselbe Ansatz rechnerisch unpraktikabel — der Suchraum wächst exponentiell mit jedem hinzugefügten Zeichen.

2. Dictionary-Angriff

Ein Dictionary-Angriff ersetzt die erschöpfende Aufzählung durch eine kuratierte Liste wahrscheinlicher Passwörter (Wörter, Phrasen und bekannte Anmeldedaten) und verengt so den Suchraum dramatisch. Der Angreifer setzt auf menschliche Vorhersagbarkeit statt auf rohe Rechenleistung.

Diese Listen reichen von einfachen Zusammenstellungen der 10.000 häufigsten Passwörter bis zu Multi-Gigabyte-Datensätzen aus geleakten Anmeldedaten, regionalen Slang und branchenspezifischer Terminologie. Jedes Passwort, das natürlicher Sprache ähnelt, ist anfällig. Zufälligkeit ist die einzige zuverlässige Verteidigung.

3. Credential Stuffing

Credential Stuffing ist die automatisierte Wiederverwendung von Benutzernamen-Passwort-Paaren, die bei früheren Datenschutzverletzungen gestohlen wurden. Angreifer nehmen Benutzernamen-Passwort-Paare und testen sie gegen andere Dienste und nutzen die Tatsache aus, dass viele Benutzer dieselben Anmeldedaten über mehrere Konten hinweg wiederverwenden.

Im Juli 2024 wurde eine Zusammenstellung von fast 10 Milliarden einzigartigen Passwörtern — genannt RockYou2024 — in einem kriminellen Forum veröffentlicht und bot Angreifern einen beispiellosen Pool an Anmeldedaten (Cybernews, 2024).

Das Verständnis der Gefahren der Passwortwiederverwendung ist hier wesentlicher Kontext — ein einziges kompromittiertes Konto auf einer Plattform kann sich kaskadenartig auf den gesamten digitalen Fußabdruck auswirken.

4. Password Spraying

Password Spraying kehrt den typischen Ansatz um. Anstatt viele Passwörter gegen ein Konto zu probieren (was Sperren auslöst), probiert der Angreifer ein oder zwei gängige Passwörter — Password1!, Welcome2026 — über Tausende von Konten.

Es bleibt unter Sperrschwellen und ist besonders effektiv gegen große Organisationen mit schwachen Passwortrichtlinien. Über 97 % der Identitätsangriffe beinhalten Password Spray oder Brute Force, laut dem Microsoft Digital Defence Report 2025.

5. Reverse-Brute-Force-Angriff

Ein Reverse-Brute-Force-Angriff beginnt mit einem bekannten Passwort (typischerweise aus einem Breach oder einem bekannten Standard stammend) und testet es systematisch gegen eine Liste von Benutzernamen. Die Anmeldedaten sind fix; die Identität ist die Unbekannte.

Diese Methode ist am effektivsten, wenn das Zielpasswort weit verbreitet ist: Ein Standard-Firmenpasswort, das beim Onboarding verteilt wurde, ein gängiges durch eine schwache Richtlinie vorgeschriebenes Muster oder ein Credential, das in einem früheren Leak auftauchte. Während ein Standardangriff ein Konto tief sondiert, sondiert ein Reverse-Angriff viele Konten mit chirurgischer Präzision.

6. Hybrid-Brute-Force-Angriff

Ein Hybrid-Brute-Force-Angriff kombiniert Wörterbuch-Wörter mit programmatischen Mutationen — Anhängen von Zahlen, Jahren oder Sonderzeichen (Summer2026!, admin@123), Ersetzen von Buchstaben durch Symbole oder Verschieben der Groß-/Kleinschreibung. Er ist darauf ausgelegt, Passwörter zu knacken, die komplex erscheinen, aber vorhersagbaren Konstruktionsmustern folgen.

Diese Angriffe zielen auf die Lücke zwischen Passwortrichtlinie und menschlichem Verhalten. Wenn Benutzer aufgefordert werden, ein Passwort zu „verkomplizieren", führen sie selten echte Zufälligkeit ein — sie hängen 1! an ein bekanntes Wort an oder schreiben den ersten Buchstaben groß. Hybrid-Angriffe sind genau darauf ausgelegt, diesen Instinkt auszunutzen, was regelbasierte Komplexitätsanforderungen zu einer schwächeren Verteidigung als Länge allein macht.

Vergleichstabelle für Brute-Force-Angriffe

Die Verwaltung von Anmeldedaten in einem großen Team schafft genau die Angriffsfläche, die Brute-Force-Kampagnen ausnutzen. Erfahren Sie, wie Passwork Team-Tresore mit rollenbasiertem Zugriff und durchgesetzten Passwortrichtlinien strukturiert

Praxisbeispiele für Brute-Force-Angriffe (2025)

Brute-Force- und Credential-Stuffing-Angriffe stellen weiterhin eine erhebliche Bedrohung dar und entwickeln sich in Raffinesse und Umfang weiter. Die folgenden Fälle aus 2025 und 2026 verdeutlichen die anhaltenden Risiken und die kritische Bedeutung robuster Authentifizierung und Sicherheitspraktiken.

Australische Superannuation-Fonds — März 2025

Angriffstyp: Credential Stuffing (koordiniert, Multi-Target).

Am Wochenende vom 29.–30. März 2025 wurden fünf große australische Pensionsfonds (AustralianSuper, REST Super, Hostplus, Australian Retirement Trust und Insignia Financial) gleichzeitig mit Combo-Listen aus unabhängigen früheren Breaches angegriffen. Über 20.000 Konten wurden kompromittiert.

Vier AustralianSuper-Mitglieder verloren zusammen 500.000 AUD. REST schaltete sein MemberAccess-Portal vollständig ab, nachdem bei ca. 8.000 Mitgliedern persönliche Daten offengelegt worden waren.

23andMe — 2023 → regulatorische Konsequenzen 2025

Angriffstyp: Credential Stuffing

Zwischen April und September 2023 testeten Angreifer Anmeldedaten aus unabhängigen Breaches gegen 23andMe-Konten. Durch die DNA-Relatives-Funktion kaskadierten anfängliche Kompromittierungen in die Offenlegung genetischer und Abstammungsdaten von etwa 6,9 Millionen Nutzern — von denen die meisten nie direkt angegriffen worden waren.

„Mega Leak" — 16 Milliarden Anmeldedaten offengelegt — Juni 2025

Angriffstyp: Credential Stuffing (Quelldaten)

Im Juni 2025 entdeckten Cybernews-Forscher ca. 30 Datensätze mit über 16 Milliarden Anmeldedatensätzen — URLs, Benutzernamen und Klartext-Passwörter. Die Daten wurden hauptsächlich durch Infostealer-Malware gesammelt, die auf Verbrauchergeräte abzielte. Betroffene Plattformen waren unter anderem Google, Apple und Facebook. Bemerkenswert: BleepingComputer bestätigte, dass die Datensätze einen erheblichen Anteil recycelter Anmeldedaten aus älteren Breaches enthalten — nicht alle Datensätze stellen also frische Offenlegungen dar.

Jaguar Land Rover — März 2025 + September 2025

Angriffstyp: Credential Stuffing / gestohlene Anmeldedaten (Infostealer-Herkunft)

Im März 2025 durchbrach die HELLCAT-Ransomware-Gruppe JLR mit gestohlenen Jira-Anmeldedaten, die durch Infostealer-Malware gesammelt wurden. Bedrohungsakteur „Rey" leakte am 10. März ca. 700 interne Dokumente. Tage später nutzte ein zweiter Akteur „APTS" Anmeldedaten aus dem Jahr 2021 — die einem Drittanbieter-Auftragnehmer gehörten — um auf denselben Jira-Server zuzugreifen und weitere ca. 350 GB Daten zu leaken, darunter Quellcode, Entwicklungsprotokolle und Mitarbeiterdaten.

Im September 2025 legte ein separater Angriff, der einer Gruppe namens „Scattered Spider Lapsus$ Hunters" zugeschrieben wurde, globale IT-Systeme lahm und stoppte die Produktion im Halewood-Werk, wobei Mitarbeiter nach Hause geschickt wurden.

Zusammenfassungstabelle

Wie erkennt man einen Brute-Force-Angriff?

Prävention ist das Ziel, aber Erkennung ist das Sicherheitsnetz. Brute-Force-Angriffe hinterlassen konsistente Signaturen in Authentifizierungs-Logs — wenn Sie wissen, worauf Sie achten müssen.

• Spitzen bei fehlgeschlagenen Anmeldeversuchen — Ein plötzlicher Anstieg von Authentifizierungsfehlern gegen ein einzelnes Konto oder verteilt über viele ist der direkteste Indikator. Legen Sie eine Baseline für Ihre Umgebung fest und alarmieren Sie bei Abweichungen.
• Mehrere Sperren von derselben Quell-IP — Selbst verteilte Angriffe hinterlassen teilweise Muster. Wiederholte Sperren, die vom selben IP-Bereich oder ASN (Autonomous System Number) stammen, deuten auf automatisierte Aktivität hin.
• Unmögliche Reisen — Ein Benutzer, der sich von London und dann innerhalb von 30 Minuten von Singapur authentifiziert, löst in modernen SIEM- und Identity-Plattformen automatisch eine Markierung aus. Das Signal allein ist nicht schlüssig: VPN-Exit-Nodes, Split-Tunneling-Konfigurationen und Cloud-Proxy-Dienste produzieren routinemäßig False Positives. Der Wert liegt in der Untersuchung, die es auslöst — nicht in der Annahme, die es bestätigt.
• Hohes Anfragevolumen an Authentifizierungs-Endpunkte — Hunderte von POST-Anfragen pro Minute an /login oder /api/auth von einer einzelnen Quelle sind kein organischer Traffic. Überwachen Sie Ihre Login-Endpunkte auf Anfrageraten, die die menschliche Tippgeschwindigkeit überschreiten.
• Verteilte Low-and-Slow-Muster — Password Spraying vermeidet gezielt das Auslösen von Sperren pro Konto. Achten Sie auf ein Muster, bei dem viele verschiedene Konten jeweils genau einen oder zwei fehlgeschlagene Versuche innerhalb eines kurzen Zeitfensters erhalten — dies ist die Spraying-Signatur.
• Ungewöhnliche User-Agent-Strings oder fehlende Header — Automatisierte Tools senden oft Anfragen mit generischen oder fehlenden User-Agent-Strings, fehlenden Standard-Browser-Headern oder mit ungewöhnlichen TLS-Fingerprints.

Wie verhindert man Brute-Force-Angriffe?

Die Verteidigung gegen Brute Force ist ein Stack. Jede Schicht kompensiert die Schwächen der anderen.

Starke Passwortrichtlinien durchsetzen

Länge ist wichtiger als Komplexität. Eine 16-Zeichen-Passphrase ist exponentiell schwerer zu knacken als ein 8-Zeichen-String mit gemischten Zeichen. Bewegen Sie Ihre Organisation weg von Mindestlängen-Richtlinien, die technisch P@ssw0rd erlauben, hin zu Mindest-Entropie-Richtlinien, die echte Unvorhersehbarkeit erfordern. Lesen Sie Best Practices für Enterprise Password Management für ein strukturiertes Framework.

Schlüsselanforderungen gemäß NIST SP 800-63B:

• Mindestens 15 Zeichen für Konten ohne MFA; mindestens 8 mit durchgesetztem MFA
• Keine willkürlichen Komplexitätsregeln, die vorhersagbare Muster erzeugen
• Maximale Länge von mindestens 64 Zeichen zur Unterstützung von Passphrasen
• Blockieren von Passwörtern, die in Breach-Datenbanken erscheinen — neue Anmeldedaten bei der Erstellung gegen Dienste wie Have I Been Pwned prüfen, nicht erst danach

Anmeldedaten gegen Breach-Datenbanken prüfen

Bevor ein Passwort akzeptiert wird, überprüfen Sie, ob es nicht bereits in einem bekannten Datenleck aufgetaucht ist. NIST SP 800-63B und OWASP verlangen dies als separate Kontrolle — getrennt von Passwortlänge- oder Komplexitätsregeln. Ein Angreifer, der einen Dictionary-Angriff gegen Ihre Systeme ausführt, arbeitet mit denselben geleakten Datensätzen. Das Blockieren dieser Passwörter bei der Registrierung entfernt sie vollständig von der Angriffsfläche.

Multi-Faktor-Authentifizierung implementieren

MFA ist die wirksamste Einzelkontrolle gegen Credential-basierte Angriffe — ein kompromittiertes Passwort allein reicht nicht für den Zugang. Allerdings ist MFA nicht unfehlbar. MFA-Fatigue-Angriffe — bei denen Angreifer wiederholte Push-Benachrichtigungen senden, bis ein Benutzer aus Frustration eine genehmigt — haben MFA bei großen Organisationen umgangen. Phishing-resistente MFA-Methoden wie FIDO2 und Passkeys eliminieren diesen Vektor vollständig.

Kontosperren und progressive Verzögerungen konfigurieren

Konfigurieren Sie Authentifizierungssysteme so, dass Konten nach einer definierten Anzahl fehlgeschlagener Versuche (typischerweise 5–10) gesperrt werden, oder implementieren Sie progressive Verzögerungen, die mit jedem Fehlversuch exponentiell zunehmen. Progressive Verzögerungen sind oft vorzuziehen gegenüber harten Sperren, die selbst für Denial-of-Service gegen legitime Benutzer missbraucht werden können.

Rate Limiting auf IP- und ASN-Ebene anwenden

Kontosperren schützen einzelne Konten. Rate Limiting schützt den Authentifizierungs-Endpunkt selbst. Dies sind unterschiedliche Kontrollen mit unterschiedlichen Zielen. Begrenzen Sie die Anzahl der Anmeldeanfragen pro IP-Adresse pro Zeitfenster. Eskalieren Sie zu ASN-Level-Blockierung, wenn verteilte Muster auftreten.

CAPTCHA und Bot-Management einsetzen

CAPTCHA-Challenges unterscheiden menschliche Benutzer von automatisierten Skripten auf der Authentifizierungsebene. Moderne Bot-Management-Plattformen gehen weiter und analysieren Verhaltenssignale — Mausbewegung, Tipprhythmus, TLS-Fingerprints — um nicht-menschlichen Traffic zu identifizieren, bevor er das Anmeldeformular erreicht.

Zero-Trust-Architektur implementieren

Zero Trust basiert auf dem Prinzip, dass kein Benutzer, Gerät oder Netzwerksegment von Natur aus vertrauenswürdig ist. Selbst nach erfolgreicher Authentifizierung wird der Zugriff kontinuierlich basierend auf Kontext verifiziert: Gerätezustand, Standort, Verhalten und Least-Privilege-Zugriffsregeln. Wenn ein Brute-Force-Angriff ein Konto kompromittiert, begrenzt Zero Trust den Explosionsradius, indem laterale Bewegung zu anderen Systemen und Ressourcen verhindert wird.

Authentifizierungs-Logs überwachen und bei Anomalien alarmieren

Erkennung ist eine präventive Kontrolle, nicht nur eine reaktive. Das Erkennen eines laufenden Angriffs gibt Ihrem Team Zeit, die Quelle zu blockieren, Sitzungen ungültig zu machen und den Schaden einzudämmen. Konfigurieren Sie SIEM-Alarme für: Spitzen bei fehlgeschlagenen Authentifizierungsversuchen, Unmögliche-Reisen-Ereignisse, hohes Anfragevolumen an Login-Endpunkte und das Low-and-Slow-Spraying-Muster, bei dem viele Konten jeweils genau einen oder zwei Fehlversuche innerhalb eines kurzen Zeitfensters erhalten.

Einen Passwort-Manager verwenden

Passwortwiederverwendung ist der Treibstoff, der Credential Stuffing im großen Maßstab praktikabel macht. Wenn ein Breach Anmeldedaten offenlegt, wird jeder andere Dienst, bei dem dieses Passwort wiederverwendet wird, automatisch verwundbar — ohne zusätzlichen Aufwand des Angreifers. Ein Passwort-Manager eliminiert dies, indem er ein einzigartiges Passwort mit hoher Entropie für jedes Konto generiert und speichert, wodurch Wiederverwendung strukturell unmöglich wird.

Für einzelne Benutzer erreicht jeder seriöse Passwort-Manager dies. Für Teams und Organisationen sind die Anforderungen anders und die Einsätze höher.

Passwork wurde speziell für diese Umgebung entwickelt. Es bietet IT-Teams einen zentralisierten, strukturierten Tresor, in dem Anmeldedaten mit granularer, rollenbasierter Zugriffskontrolle organisiert sind: Jeder Benutzer sieht nur das, was seine Rolle erlaubt, nicht mehr. Geteilte Anmeldedaten werden in geteilten Tresoren mit definierten Berechtigungen gespeichert.

Mehrere Funktionen von Passwork adressieren direkt die in diesem Artikel behandelten Angriffsvektoren:

• Anpassbarer Passwort-Generator — erzwingt Längen- und Komplexitätsanforderungen bei der Erstellung, sodass die Richtlinien-Compliance nicht dem individuellen Urteil überlassen wird.
• Passwortsicherheits-Dashboard — verfolgt kontinuierlich den Status aller gespeicherten Anmeldedaten und markiert schwache, wiederverwendete, veraltete und potenziell kompromittierte Passwörter im gesamten Tresor. Wenn ein Mitarbeiter das Unternehmen verlässt, markiert Passwork automatisch jede Anmeldedaten, auf die diese Person Zugriff hatte, als potenziell kompromittiert und fordert zur Rotation auf.
• Zero-Knowledge-Client-seitige Verschlüsselung — Anmeldedaten werden auf der Client-Seite verschlüsselt, bevor sie den Server erreichen. Selbst mit vollem Zugriff auf die Datenbank oder die zugrundeliegende Infrastruktur erhält ein Angreifer nichts Lesbares. Der Verschlüsselungsschlüssel verlässt nie das Gerät des Benutzers.
• Vollständiges Audit-Log — jede Aktion im Tresor wird protokolliert: Wer hat auf was zugegriffen, wann und von wo. Dies ist die Sichtbarkeitsebene, die Post-Incident-Untersuchungen ermöglicht und die Compliance mit DSGVO, NIS2 und ähnlichen Frameworks unterstützt.
• Zwei-Faktor-Authentifizierung, Passkeys und Hardware-Sicherheitsschlüssel — Passwork unterstützt 2FA über Authenticator-Apps und WebAuthn-basierte Authentifizierung einschließlich Biometrie und FIDO2-Hardware-Schlüssel und fügt eine zweite Schicht über das Tresor-Passwort selbst hinaus hinzu.
• Konfigurierbare Kontosperre — Administratoren legen den Schwellenwert für fehlgeschlagene Anmeldeversuche fest, nach dem ein Konto gesperrt wird. Dies wendet Brute-Force- und Credential-Stuffing-Schutz auf Tresor-Ebene an — nicht nur am Netzwerkperimeter.
• Self-Hosted-Deployment — Passwork läuft vollständig innerhalb Ihrer eigenen Infrastruktur. Anmeldedaten verlassen nie Ihre Umgebung, werden auf Server- und Client-Seite mit AES-256 verschlüsselt (Zero-Knowledge-Architektur) und werden ausschließlich von Ihrem Team verwaltet.

Der JLR-Breach illustrierte, was ohne diese Struktur passiert: Anmeldedaten aus 2021, die einem Drittanbieter-Auftragnehmer gehörten, waren vier Jahre später noch gültig, ohne Rotation und ohne MFA auf der Jira-Instanz. Ein zentralisierter Tresor mit durchgesetzten Rotationsrichtlinien und einem Offboarding-Workflow hätte dieses Fenster geschlossen, bevor es ausgenutzt wurde.

Fazit

Brute-Force-Angriffe sind in der Praxis skalierbarer geworden. Günstige GPU-Rechenleistung, KI-gestützte Wordlist-Generierung und massive Botnets bedeuten, dass das, was einst erhebliche Ressourcen erforderte, jetzt fast keine mehr benötigt. Der 37-%-Anteil von Webanwendungsangriffen, die im Verizon DBIR 2025 Brute Force zugeschrieben werden, ist das Ergebnis dieser Zugänglichkeit.

Die gute Nachricht: Die Abwehrmaßnahmen funktionieren. MFA, starke und einzigartige Passwörter, Kontosperr-Richtlinien und Verhaltensüberwachung machen Brute-Force-Angriffe gemeinsam unpraktikabel gegen ein gehärtetes Ziel. Angreifer bewegen sich in Richtung des geringsten Widerstands — was bedeutet, dass Organisationen, die mehrschichtige Authentifizierungssicherheit effektiv implementieren, sich selbst aus dem Pool leichter Ziele entfernen.

Das eigentliche Risiko besteht darin, dass sie inkonsistent angewendet werden — ein Team nutzt MFA, ein anderes nicht. Geteilte Anmeldedaten in Tabellenkalkulationen gespeichert; Passwortrichtlinien, die auf dem Papier existieren, aber technisch nicht durchgesetzt werden. Das Schließen dieser Lücken ist, wo die eigentliche Arbeit liegt.

Passwork bietet IT-Teams einen strukturierten, prüffähigen Credential-Tresor mit rollenbasiertem Zugriff — entwickelt für Umgebungen, in denen Inkonsistenz Risiken schafft. Vollständiges Self-Hosted-Deployment und Zero-Knowledge-Verschlüsselung — auf Ihrer Infrastruktur vom ersten Tag an. Kostenlose Testversion erhalten

Häufig gestellte Fragen

Was ist der Unterschied zwischen einem Brute-Force-Angriff und einem Dictionary-Angriff?

Ein einfacher Brute-Force-Angriff probiert systematisch jede mögliche Zeichenkombination ohne Vorkenntnisse. Ein Dictionary-Angriff verwendet eine kuratierte Liste wahrscheinlicher Passwörter — gängige Wörter, bekannte Phrasen, geleakte Anmeldedaten — um den Suchraum zu reduzieren. Dictionary-Angriffe sind schneller und gezielter; einfache Brute Force ist erschöpfend, aber langsamer. Beide werden durch lange, zufällige Passwörter besiegt, die nicht natürlicher Sprache ähneln.

Können Brute-Force-Angriffe MFA umgehen?

Standard-Brute-Force kann MFA nicht direkt umgehen — ein korrektes Passwort allein reicht nicht für den Zugang. Allerdings nutzen Angreifer benachbarte Techniken: MFA-Fatigue (wiederholtes Senden von Push-Benachrichtigungen, bis der Benutzer eine genehmigt), Echtzeit-Phishing (Abfangen und Wiederverwenden von MFA-Token) und Session-Hijacking (Stehlen authentifizierter Sitzungscookies nach dem Login). Phishing-resistente MFA-Methoden wie FIDO2-Hardware-Schlüssel und Passkeys eliminieren die Phishing- und Fatigue-Vektoren vollständig.

Sind Brute-Force-Angriffe illegal?

Ja. Unbefugte Brute-Force-Angriffe gegen Systeme, die Sie nicht besitzen oder für die Sie keine ausdrückliche Genehmigung zum Testen haben, sind nach der Computerbetruggesetzgebung in den meisten Rechtsordnungen illegal — einschließlich des Computer Fraud and Abuse Act (CFAA) in den Vereinigten Staaten, des Computer Misuse Act im Vereinigten Königreich und der EU-Richtlinie über Angriffe auf Informationssysteme (2013/40/EU). Die Strafen umfassen erhebliche Geldstrafen und Freiheitsstrafen. Autorisierte Penetrationstests erfordern eine schriftliche Genehmigung des Systemeigentümers.

Wie lange dauert es, ein Passwort mit Brute Force zu knacken?

Das hängt von der Passwortlänge, dem Zeichensatz und der Art der Hash-Speicherung ab. Ein 8-Zeichen-MD5-gehashtes Passwort fällt in unter einer Stunde gegen einen modernen GPU-Cluster. Dasselbe Passwort, mit bcrypt bei hohem Kostenfaktor gehasht, kann auf derselben Hardware Jahre dauern. Länge ist die zuverlässigste Variable unter Ihrer Kontrolle: Jedes zusätzliche Zeichen multipliziert den Suchraum exponentiell. Eine 16-Zeichen-Passphrase gegen bcrypt ist mit aktueller Hardware rechnerisch unpraktikabel zu knacken.

Was ist Credential Stuffing und wie unterscheidet es sich von Brute Force?

Credential Stuffing verwendet verifizierte Benutzernamen/Passwort-Paare aus früheren Datenschutzverletzungen und testet sie gegen andere Dienste. Es rät nicht — es verwendet wieder. Brute Force generiert oder durchläuft Kombinationen ohne Vorkenntnisse über gültige Anmeldedaten. Credential Stuffing ist schneller und gezielter, weil es mit echten Anmeldedaten arbeitet, und es hat speziell wegen der Passwortwiederverwendung über Dienste hinweg Erfolg.

Welche Systeme werden am häufigsten von Brute-Force-Angriffen angegriffen?

Authentifizierungs-Endpunkte mit öffentlicher Exposition tragen das höchste Risiko: SSH- und RDP-Dienste, VPN-Portale, Webanwendungs-Anmeldeseiten, Admin-Panels (WordPress /wp-admin, cPanel) und API-Authentifizierungs-Endpunkte. Die Kampagne 2025, die 2,8 Millionen IPs nutzte, konzentrierte sich speziell auf VPN-Gateways und Firewalls — Perimeter-Geräte, die bei Kompromittierung direkten Zugang zu internen Netzwerken bieten.

Introducción

A las 3:14 AM, nadie está vigilando los registros de autenticación. Un script ejecutándose en una instancia en la nube alquilada envía su intento de inicio de sesión número diez mil a un portal VPN. A las 3:17 AM, recibe una respuesta diferente a las demás. Acceso concedido. No hay malware, ni ingeniería social, ni amenaza interna. Solo una contraseña débil, paciencia automatizada y una brecha en la supervisión.

Uno de cada tres ataques exitosos contra aplicaciones web ahora comienza de la misma manera: un script automatizado probando credenciales hasta que algo funciona. Según el Informe de Investigaciones de Filtraciones de Datos 2025 de Verizon, los ataques de fuerza bruta contra aplicaciones web básicas casi se triplicaron durante el último año — saltando de aproximadamente 20% a 60%. Es una señal de que los ataques automatizados de credenciales se han convertido en un arma principal, no en un recurso de respaldo.

La mecánica subyacente no ha cambiado: probar combinaciones hasta que una funcione. Lo que ha cambiado es la velocidad, escala e inteligencia detrás de esos intentos. Los clústeres de GPU modernos, la generación de listas de palabras asistida por IA y las botnets que abarcan millones de dispositivos comprometidos han transformado lo que alguna vez fue un ataque lento y ruidoso en algo rápido, distribuido y difícil de detectar.

Este artículo cubre qué son los ataques de fuerza bruta, cómo han evolucionado en 2026, las seis variantes principales, ejemplos del mundo real de 2025–2026 y una estrategia de defensa por capas que su equipo puede implementar hoy.

Puntos clave

• Los ataques de fuerza bruta son ataques automatizados de credenciales — los scripts prueban sistemáticamente combinaciones de nombre de usuario y contraseña hasta que una funciona, explotando contraseñas débiles, reutilizadas o predecibles en lugar de vulnerabilidades de software.
• Seis variantes distintas atacan diferentes debilidades: fuerza bruta simple, ataques de diccionario, credential stuffing, password spraying, fuerza bruta inversa y ataques híbridos — cada uno diseñado para evadir un conjunto específico de defensas.
• El hardware moderno ha hecho indefendibles las contraseñas débiles: un clúster de GPU puede descifrar una contraseña de 8 caracteres con hash MD5 en minutos. La longitud de la contraseña y el hash seguro son lo que determina la resistencia en el mundo real.
• Las defensas por capas funcionan, pero solo cuando se aplican consistentemente. MFA, políticas de contraseñas robustas, verificación contra bases de datos de filtraciones, bloqueo de cuentas, limitación de velocidad y un gestor de contraseñas hacen colectivamente que los ataques de fuerza bruta sean imprácticos. Cualquier brecha individual es suficiente para que un atacante la explote.
• La detección es un control preventivo, no solo reactivo. Reconocer las firmas de ataque — picos de inicios de sesión fallidos, patrones de spraying lentos y graduales, viajes imposibles — le da a su equipo tiempo para bloquear la fuente antes de que las credenciales sean validadas.
• Un gestor de contraseñas es la solución estructural para la reutilización de credenciales — la causa raíz detrás del credential stuffing. Para equipos, también impone la rotación, marca credenciales comprometidas y cierra la brecha de desvinculación que deja credenciales obsoletas válidas durante años.

¿Qué es un ataque de fuerza bruta?

Un ataque de fuerza bruta obtiene acceso no autorizado a un sistema probando sistemáticamente todas las combinaciones posibles de credenciales (nombres de usuario, contraseñas o claves de cifrado) hasta encontrar la correcta. Explota el comportamiento humano: contraseñas débiles, reutilizadas o predecibles.

Piénselo como probar cada llave de un llavero. Dado suficiente tiempo y potencia de cómputo, una eventualmente encajará. El objetivo del atacante es reducir ese tiempo a algo práctico y, en 2026, el hardware moderno lo hace cada vez más alcanzable.

Los ataques de fuerza bruta apuntan a endpoints de autenticación: páginas de inicio de sesión, servicios SSH y RDP, portales VPN, puertas de enlace API y paneles de administración. Cualquier sistema que acepte un nombre de usuario y contraseña es un objetivo potencial.

Cómo funcionan los ataques de fuerza bruta en 2026

En esencia, un ataque de fuerza bruta es automatización a escala. Un atacante despliega un script o herramienta que envía combinaciones de credenciales al endpoint de autenticación de un sistema objetivo en rápida sucesión. El script registra las coincidencias exitosas y continúa.

Lo que separa 2026 de hace una década es la infraestructura detrás de esos scripts.

El factor de la IA y el hardware

Las tarjetas gráficas modernas (originalmente diseñadas para juegos y aprendizaje automático) son excepcionalmente eficientes en computación paralela, que es exactamente lo que requiere el descifrado de contraseñas. Un clúster de 12 GPU NVIDIA RTX 5090 puede probar cientos de miles de millones de combinaciones de hash MD5 por segundo (Hive Systems).

Contra credenciales con hash débil, una contraseña de 8 caracteres cae en minutos — o menos. Contra bcrypt con configuraciones de costo modernas, el mismo hardware puede tardar años. La diferencia no está en el hardware del atacante. Está en si el sistema objetivo almacena las contraseñas de forma segura.

Los modelos de aprendizaje automático entrenados con conjuntos de datos de contraseñas filtradas (herramientas como PassGAN, construidas sobre redes generativas adversarias) aprenden distribuciones de contraseñas del mundo real sin reglas escritas por humanos. Predicen patrones probables: fechas de nacimiento añadidas a nombres, sustituciones comunes de caracteres, frases culturalmente específicas.

En pruebas contra el conjunto de datos de la filtración RockYou, PassGAN coincidió con el 47% de las contraseñas reales. Combinado con herramientas de descifrado convencionales, descubrió un 24% más de coincidencias que cualquiera de los enfoques por separado. El espacio de búsqueda no se reduce por fuerza bruta — se reduce por predicción.

La amenaza cuántica

La computación cuántica utiliza fenómenos mecánico-cuánticos para procesar información de maneras que las computadoras clásicas no pueden. Mientras un procesador clásico trabaja a través de posibilidades secuencialmente, un sistema cuántico evalúa muchos estados simultáneamente. Aplicado a la criptografía, ese paralelismo se convierte en una amenaza directa a los problemas matemáticos que sustentan el cifrado actual.

La computación cuántica introduce un riesgo a más largo plazo. La hoja de ruta cuántica de IBM proyecta que las computadoras cuánticas criptográficamente relevantes podrían socavar los estándares actuales de cifrado asimétrico dentro de esta década.

Los ataques cuánticos a contraseñas hasheadas siguen siendo teóricos, pero las organizaciones que gestionan secretos de larga duración y claves de cifrado deberían comenzar a evaluar los estándares de criptografía post-cuántica — NIST finalizó sus primeros estándares post-cuánticos en 2024.

Botnets y ataques distribuidos

Una botnet es una red de dispositivos comprometidos (servidores, routers, endpoints IoT, computadoras personales) controlados remotamente por un atacante sin el conocimiento de sus propietarios. Cada dispositivo actúa como un nodo independiente, capaz de enviar solicitudes, sondear sistemas o enviar intentos de inicio de sesión. La escala puede alcanzar millones de máquinas operando de forma coordinada.

Los atacantes rara vez operan desde una sola IP. Las campañas modernas de fuerza bruta usan botnets para distribuir intentos de inicio de sesión a través de diferentes direcciones de origen, evadiendo la limitación de velocidad basada en IP y el bloqueo geográfico.

A principios de 2025, la Shadowserver Foundation rastreó una campaña que utilizaba 2,8 millones de direcciones IP diariamente para atacar portales de inicio de sesión VPN de Palo Alto Networks, Ivanti y SonicWall (BleepingComputer).

Los nodos atacantes eran predominantemente routers MikroTik, Huawei y Cisco comprometidos — dispositivos secuestrados distribuidos en docenas de países, con el clúster más grande originándose en Brasil. El tráfico se enrutaba a través de redes de proxy residenciales, haciendo que cada intento pareciera provenir de un usuario doméstico normal en lugar de un bot. Las defensas estándar basadas en IP veían lo que parecía tráfico normal.

Tipos de ataques de fuerza bruta

Los ataques de fuerza bruta comparten un principio: obtener acceso probando sistemáticamente credenciales hasta que algo funcione. Los métodos difieren en qué prueban, cómo obtienen sus datos y qué defensas están diseñados para evadir.

1. Ataque de fuerza bruta simple

La variante más directa: cada combinación de caracteres posible se prueba en secuencia — aaa, aab, aac — hasta encontrar una coincidencia. No se requiere conocimiento previo del objetivo. El ataque depende enteramente de la potencia computacional.

Es efectivo solo contra contraseñas cortas o simples. Contra una contraseña de 8 caracteres usando caracteres mixtos, los clústeres de GPU modernos pueden completar la búsqueda en horas. Más allá de 12 caracteres, el mismo enfoque se vuelve computacionalmente impráctico — el espacio de búsqueda crece exponencialmente con cada carácter añadido.

2. Ataque de diccionario

Un ataque de diccionario reemplaza la enumeración exhaustiva con una lista curada de contraseñas probables (palabras, frases y credenciales conocidas), reduciendo drásticamente el espacio de búsqueda. El atacante apuesta por la previsibilidad humana en lugar de la computación bruta.

Estas listas van desde compilaciones básicas de las 10.000 contraseñas más comunes hasta conjuntos de datos de varios gigabytes construidos a partir de credenciales filtradas, jerga regional y terminología específica de la industria. Cualquier contraseña que se parezca al lenguaje natural es vulnerable. La aleatoriedad es la única defensa confiable.

3. Credential stuffing

El credential stuffing es la reutilización automatizada de pares de nombre de usuario y contraseña robados de filtraciones de datos anteriores. Los atacantes toman pares de nombre de usuario y contraseña y los prueban contra otros servicios, explotando el hecho de que muchos usuarios reutilizan las mismas credenciales en múltiples cuentas.

En julio de 2024, una compilación de casi 10 mil millones de contraseñas únicas — denominada RockYou2024 — fue publicada en un foro criminal, proporcionando a los atacantes un conjunto de credenciales sin precedentes del cual trabajar (Cybernews, 2024).

Comprender los peligros de la reutilización de contraseñas es un contexto esencial aquí — una sola cuenta comprometida en una plataforma puede propagarse en acceso a través de toda una huella digital.

4. Password spraying

El password spraying invierte el enfoque típico. En lugar de probar muchas contraseñas contra una cuenta (lo que activa bloqueos), el atacante prueba una o dos contraseñas comunes — Password1!, Welcome2026 — en miles de cuentas.

Se mantiene por debajo de los umbrales de bloqueo y es particularmente efectivo contra grandes organizaciones con políticas de contraseñas débiles. Más del 97% de los ataques de identidad involucran password spraying o fuerza bruta, según el Informe de Defensa Digital de Microsoft 2025.

5. Ataque de fuerza bruta inversa

Un ataque de fuerza bruta inversa comienza con una contraseña conocida (típicamente obtenida de una filtración o un valor predeterminado conocido) y la prueba sistemáticamente contra una lista de nombres de usuario. La credencial está fija; la identidad es la incógnita.

Este método es más efectivo cuando la contraseña objetivo es ampliamente compartida: una contraseña corporativa predeterminada distribuida durante la incorporación, un patrón común exigido por una política débil, o una credencial que apareció en una filtración anterior. Donde un ataque estándar sondea una cuenta en profundidad, un ataque inverso sondea muchas cuentas con precisión quirúrgica.

6. Ataque híbrido de fuerza bruta

Un ataque híbrido de fuerza bruta combina palabras de diccionario con mutaciones programáticas — añadiendo números, años o caracteres especiales (Summer2026!, admin@123), sustituyendo letras con símbolos o cambiando mayúsculas. Está diseñado para descifrar contraseñas que parecen complejas pero siguen patrones de construcción predecibles.

Estos ataques apuntan a la brecha entre la política de contraseñas y el comportamiento humano. Cuando se requiere que los usuarios «compliquen» una contraseña, rara vez introducen verdadera aleatoriedad — añaden 1! a una palabra familiar o ponen en mayúscula la primera letra. Los ataques híbridos están construidos para explotar exactamente ese instinto, haciendo que los requisitos de complejidad basados en reglas sean una defensa más débil que la longitud sola.

Tabla comparativa de ataques de fuerza bruta

Gestionar credenciales en un equipo grande crea exactamente la superficie de ataque que explotan las campañas de fuerza bruta. Vea cómo Passwork estructura bóvedas de equipo con acceso basado en roles y políticas de contraseñas aplicadas

Ejemplos reales de ataques de fuerza bruta (2025)

Los ataques de fuerza bruta y credential stuffing continúan siendo una amenaza significativa, evolucionando en sofisticación y escala. Los siguientes casos de 2025 y 2026 destacan los riesgos persistentes y la importancia crítica de prácticas robustas de autenticación y seguridad.

Fondos de jubilación australianos — marzo 2025

Tipo de ataque: Credential stuffing (coordinado, multi-objetivo).

Durante el fin de semana del 29–30 de marzo de 2025, cinco importantes fondos de pensiones australianos (AustralianSuper, REST Super, Hostplus, Australian Retirement Trust e Insignia Financial) fueron atacados simultáneamente usando listas combinadas de filtraciones anteriores no relacionadas. Más de 20.000 cuentas fueron comprometidas.

Cuatro miembros de AustralianSuper perdieron colectivamente 500.000 AUD. REST cerró su portal MemberAccess por completo después de que ~8.000 miembros tuvieran datos personales expuestos.

23andMe — 2023 → consecuencias regulatorias en 2025

Tipo de ataque: Credential stuffing

Entre abril y septiembre de 2023, los atacantes probaron credenciales de filtraciones no relacionadas contra cuentas de 23andMe. A través de la función DNA Relatives, los compromisos iniciales se propagaron en exposición de datos genéticos y de ascendencia pertenecientes a aproximadamente 6,9 millones de usuarios — la mayoría de los cuales nunca habían sido atacados directamente.

«Mega filtración» — 16 mil millones de credenciales expuestas — junio 2025

Tipo de ataque: Credential stuffing (datos fuente)

En junio de 2025, investigadores de Cybernews descubrieron ~30 conjuntos de datos que contenían más de 16 mil millones de registros de inicio de sesión — URL, nombres de usuario y contraseñas en texto plano. Los datos fueron recolectados principalmente por malware infostealer dirigido a dispositivos de consumidores. Las plataformas afectadas incluyeron Google, Apple, Facebook y otras. Notablemente, BleepingComputer confirmó que los conjuntos de datos incluyen una proporción significativa de credenciales recicladas de filtraciones anteriores, lo que significa que no todos los registros representan exposiciones nuevas.

Jaguar Land Rover — marzo 2025 + septiembre 2025

Tipo de ataque: Credential stuffing / credenciales robadas (fuente infostealer)

En marzo de 2025, el grupo de ransomware HELLCAT vulneró JLR usando credenciales de Jira robadas recolectadas mediante malware infostealer. El actor de amenazas «Rey» filtró ~700 documentos internos el 10 de marzo. Días después, un segundo actor «APTS» usó credenciales que databan de 2021 — pertenecientes a un contratista externo — para acceder al mismo servidor Jira y filtrar ~350 GB adicionales de datos incluyendo código fuente, registros de desarrollo y expedientes de empleados.

En septiembre de 2025, un ataque separado atribuido a un grupo que se autodenominaba «Scattered Spider Lapsus$ Hunters» paralizó los sistemas de TI globales y detuvo la fabricación en la planta de Halewood, enviando a los empleados a casa.

Tabla resumen

Cómo detectar un ataque de fuerza bruta

La prevención es el objetivo, pero la detección es la red de seguridad. Los ataques de fuerza bruta dejan firmas consistentes en los registros de autenticación — si sabe qué buscar.

• Picos en intentos de inicio de sesión fallidos — Un aumento repentino en fallos de autenticación contra una sola cuenta, o distribuidos en muchas, es el indicador más directo. Establezca una línea base para su entorno y alerte sobre desviaciones.
• Múltiples bloqueos desde la misma IP de origen — Incluso los ataques distribuidos dejan patrones parciales. Bloqueos repetidos originados desde el mismo rango de IP o ASN (Número de Sistema Autónomo) sugieren actividad automatizada.
• Viaje imposible — Un usuario autenticándose desde Londres y luego desde Singapur en 30 minutos activa una alerta automática en plataformas SIEM y de identidad modernas. La señal por sí sola no es concluyente: los nodos de salida VPN, las configuraciones de túnel dividido y los servicios de proxy en la nube producen rutinariamente falsos positivos. El valor está en la investigación que provoca — no en la suposición que confirma.
• Alto volumen de solicitudes a endpoints de autenticación — Cientos de solicitudes POST por minuto a /login o /api/auth desde una sola fuente no es tráfico orgánico. Supervise sus endpoints de inicio de sesión para tasas de solicitud que excedan la velocidad de escritura humana.
• Patrones distribuidos lentos y graduales — El password spraying específicamente evita activar bloqueos por cuenta. Busque un patrón donde muchas cuentas diferentes reciben exactamente uno o dos intentos fallidos dentro de una ventana corta — esta es la firma del spraying.
• Cadenas de user-agent inusuales o encabezados faltantes — Las herramientas automatizadas a menudo envían solicitudes con cadenas de user-agent genéricas o ausentes, encabezados de navegador estándar faltantes o con huellas TLS inusuales.

Cómo prevenir ataques de fuerza bruta

La defensa contra la fuerza bruta es una pila. Cada capa compensa las debilidades de las otras.

Aplicar políticas de contraseñas robustas

La longitud importa más que la complejidad. Una frase de contraseña de 16 caracteres es exponencialmente más difícil de descifrar que una cadena de 8 caracteres de caracteres mixtos. Aleje a su organización de políticas de longitud mínima que técnicamente permiten P@ssw0rd y muévase hacia políticas de entropía mínima que requieran verdadera imprevisibilidad. Revise las mejores prácticas de gestión de contraseñas empresariales para un marco estructurado.

Requisitos clave según NIST SP 800-63B:

• Mínimo 15 caracteres para cuentas sin MFA; mínimo 8 con MFA aplicado
• Sin reglas de complejidad arbitrarias que produzcan patrones predecibles
• Longitud máxima de al menos 64 caracteres para soportar frases de contraseña
• Bloquear contraseñas que aparezcan en bases de datos de filtraciones — verificar nuevas credenciales contra servicios como Have I Been Pwned en el momento de creación, no después

Verificar credenciales contra bases de datos de filtraciones

Antes de aceptar una contraseña, verifique que no haya aparecido ya en una filtración de datos conocida. NIST SP 800-63B y OWASP requieren esto como un control distinto — separado de las reglas de longitud o complejidad de contraseña. Un atacante ejecutando un ataque de diccionario contra sus sistemas está trabajando con los mismos conjuntos de datos filtrados. Bloquear esas contraseñas en el registro las elimina de la superficie de ataque por completo.

Implementar autenticación multifactor

MFA es el control individual más efectivo contra ataques basados en credenciales — una contraseña comprometida por sí sola no es suficiente para el acceso. Dicho esto, MFA no es infalible. Los ataques de fatiga MFA — donde los atacantes envían notificaciones push repetidas hasta que un usuario aprueba una por frustración — han evadido MFA en organizaciones importantes. Los métodos MFA resistentes al phishing como FIDO2 y passkeys eliminan este vector por completo.

Configurar bloqueos de cuenta y retrasos progresivos

Configure los sistemas de autenticación para bloquear cuentas después de un número definido de intentos fallidos (típicamente 5–10), o implemente retrasos progresivos que aumenten exponencialmente con cada fallo. Los retrasos progresivos son a menudo preferibles a los bloqueos duros, que pueden ser utilizados como arma para denegación de servicio contra usuarios legítimos.

Aplicar limitación de velocidad a nivel de IP y ASN

El bloqueo de cuenta protege cuentas individuales. La limitación de velocidad protege el endpoint de autenticación en sí. Estos son controles diferentes con objetivos diferentes. Restrinja el número de solicitudes de inicio de sesión por dirección IP por ventana de tiempo. Escale al bloqueo a nivel de ASN cuando surjan patrones distribuidos.

Desplegar CAPTCHA y gestión de bots

Los desafíos CAPTCHA diferencian usuarios humanos de scripts automatizados en la capa de autenticación. Las plataformas modernas de gestión de bots van más allá, analizando señales de comportamiento — movimiento del ratón, cadencia de escritura, huellas TLS — para identificar tráfico no humano antes de que llegue al formulario de inicio de sesión.

Implementar arquitectura de confianza cero

La confianza cero opera bajo el principio de que ningún usuario, dispositivo o segmento de red es inherentemente confiable. Incluso después de una autenticación exitosa, el acceso se verifica continuamente según el contexto: salud del dispositivo, ubicación, comportamiento y reglas de acceso de mínimo privilegio. Si un ataque de fuerza bruta compromete una cuenta, la confianza cero limita el radio de explosión previniendo el movimiento lateral a otros sistemas y recursos.

Supervisar registros de autenticación y alertar sobre anomalías

La detección es un control preventivo, no solo reactivo. Detectar un ataque en progreso le da a su equipo tiempo para bloquear la fuente, invalidar sesiones y contener el daño. Configure alertas SIEM para: picos en intentos de autenticación fallidos, eventos de viaje imposible, alto volumen de solicitudes a endpoints de inicio de sesión y el patrón de spraying lento y gradual donde muchas cuentas reciben exactamente uno o dos fallos dentro de una ventana corta.

Usar un gestor de contraseñas

La reutilización de contraseñas es el combustible que hace viable el credential stuffing a escala. Cuando una filtración expone una credencial, cada otro servicio donde esa contraseña se reutiliza se vuelve vulnerable — automáticamente, sin ningún esfuerzo adicional del atacante. Un gestor de contraseñas elimina esto generando y almacenando una contraseña única de alta entropía para cada cuenta, haciendo la reutilización estructuralmente imposible.

Para usuarios individuales, cualquier gestor de contraseñas de buena reputación logra esto. Para equipos y organizaciones, los requisitos son diferentes y los riesgos son mayores.

Passwork está construido específicamente para este entorno. Proporciona a los equipos de TI una bóveda centralizada y estructurada donde las credenciales se organizan con control de acceso granular basado en roles: cada usuario ve solo lo que su rol permite, nada más. Las credenciales compartidas se almacenan en bóvedas compartidas con permisos definidos.

Varias características de Passwork abordan directamente los vectores de ataque cubiertos en este artículo:

• Generador de contraseñas personalizable — aplica requisitos de longitud y complejidad en el momento de creación, para que el cumplimiento de políticas no quede al juicio individual.
• Panel de seguridad de contraseñas — rastrea continuamente el estado de todas las credenciales almacenadas, marcando contraseñas débiles, reutilizadas, obsoletas y potencialmente comprometidas en toda la bóveda. Cuando un empleado se va, Passwork marca automáticamente cada credencial a la que tenía acceso como potencialmente comprometida y solicita la rotación.
• Cifrado de conocimiento cero del lado del cliente — las credenciales se cifran en el lado del cliente antes de llegar al servidor. Incluso con acceso completo a la base de datos o la infraestructura subyacente, un atacante no recupera nada legible. La clave de cifrado nunca sale del dispositivo del usuario.
• Registro de auditoría completo — cada acción en la bóveda se registra: quién accedió a qué, cuándo y desde dónde. Esta es la capa de visibilidad que hace posible la investigación post-incidente y apoya el cumplimiento con GDPR, NIS2 y marcos similares.
• Autenticación de dos factores, passkeys y llaves de seguridad de hardware — Passwork soporta 2FA mediante aplicaciones de autenticación y autenticación basada en WebAuthn incluyendo biometría y llaves de hardware FIDO2, añadiendo una segunda capa más allá de la contraseña de la bóveda en sí.
• Bloqueo de cuenta configurable — los administradores establecen el umbral de intentos de inicio de sesión fallidos después del cual una cuenta se bloquea. Esto aplica protección contra fuerza bruta y credential stuffing a nivel de la bóveda misma — no solo en el perímetro de red.
• Despliegue autoalojado — Passwork se ejecuta completamente dentro de su propia infraestructura. Los datos de credenciales nunca salen de su entorno, se cifran con AES-256 tanto en el lado del servidor como del cliente (arquitectura de conocimiento cero), y son gestionados exclusivamente por su equipo.

La filtración de JLR ilustró lo que sucede sin esta estructura: las credenciales de 2021 pertenecientes a un contratista externo seguían siendo válidas cuatro años después, sin rotación y sin MFA en la instancia de Jira. Una bóveda centralizada con políticas de rotación aplicadas y un flujo de trabajo de desvinculación habría cerrado esa ventana antes de que fuera explotada.

Conclusión

Los ataques de fuerza bruta se han vuelto más escalables en la práctica. La computación GPU barata, la generación de listas de palabras asistida por IA y las botnets masivas significan que lo que antes requería recursos significativos ahora no requiere casi ninguno. El 37% de los ataques a aplicaciones web atribuidos a fuerza bruta en el DBIR 2025 de Verizon es el resultado de esa accesibilidad.

La buena noticia: las defensas funcionan. MFA, contraseñas robustas y únicas, políticas de bloqueo de cuenta y supervisión del comportamiento hacen colectivamente que los ataques de fuerza bruta sean imprácticos contra un objetivo endurecido. Los atacantes se mueven hacia la menor resistencia — lo que significa que las organizaciones que implementan seguridad de autenticación por capas efectivamente se eliminan del grupo de objetivos fáciles.

El riesgo real es que se aplican inconsistentemente — un equipo usando MFA, otro no. Credenciales compartidas almacenadas en hojas de cálculo; políticas de contraseñas que existen en papel pero no se aplican técnicamente. Cerrar esas brechas es donde está el verdadero trabajo.

Passwork proporciona a los equipos de TI una bóveda de credenciales estructurada y auditable con acceso basado en roles — construida para los entornos donde la inconsistencia crea riesgo. Despliegue autoalojado completo y cifrado de conocimiento cero — en su infraestructura desde el primer día. Obtener prueba gratuita

Preguntas frecuentes

¿Cuál es la diferencia entre un ataque de fuerza bruta y un ataque de diccionario?

Un ataque de fuerza bruta simple prueba cada combinación de caracteres posible sistemáticamente, sin conocimiento previo. Un ataque de diccionario usa una lista curada de contraseñas probables — palabras comunes, frases conocidas, credenciales filtradas — para reducir el espacio de búsqueda. Los ataques de diccionario son más rápidos y dirigidos; la fuerza bruta simple es exhaustiva pero más lenta. Ambos son derrotados por contraseñas largas y aleatorias que no se parezcan al lenguaje natural.

¿Pueden los ataques de fuerza bruta evadir MFA?

La fuerza bruta estándar no puede evadir MFA directamente — una contraseña correcta por sí sola no es suficiente para el acceso. Sin embargo, los atacantes usan técnicas adyacentes: fatiga MFA (enviar notificaciones push repetidas hasta que el usuario apruebe una), phishing en tiempo real (capturar y reproducir tokens MFA), y secuestro de sesión (robar cookies de sesión autenticadas después del inicio de sesión). Los métodos MFA resistentes al phishing como las llaves de hardware FIDO2 y passkeys eliminan los vectores de phishing y fatiga por completo.

¿Son ilegales los ataques de fuerza bruta?

Sí. Los ataques de fuerza bruta no autorizados contra sistemas que usted no posee o no tiene permiso explícito para probar son ilegales bajo la legislación de fraude informático en la mayoría de las jurisdicciones — incluyendo la Ley de Fraude y Abuso Informático (CFAA) en Estados Unidos, la Ley de Uso Indebido de Computadoras en el Reino Unido, y la Directiva de la UE sobre Ataques contra Sistemas de Información (2013/40/UE). Las sanciones incluyen multas significativas y prisión. Las pruebas de penetración autorizadas requieren permiso escrito del propietario del sistema.

¿Cuánto tiempo lleva descifrar una contraseña con fuerza bruta?

Depende de la longitud de la contraseña, el conjunto de caracteres y cómo se almacena el hash. Una contraseña de 8 caracteres con hash MD5 cae en menos de una hora contra un clúster de GPU moderno. La misma contraseña hasheada con bcrypt a un factor de costo alto puede tardar años en el mismo hardware. La longitud es la variable más confiable bajo su control: cada carácter adicional multiplica el espacio de búsqueda exponencialmente. Una frase de contraseña de 16 caracteres contra bcrypt es computacionalmente impráctico de descifrar con el hardware actual.

¿Qué es el credential stuffing y en qué se diferencia de la fuerza bruta?

El credential stuffing usa pares verificados de nombre de usuario/contraseña de filtraciones de datos anteriores y los prueba contra otros servicios. No adivina — reutiliza. La fuerza bruta genera o cicla a través de combinaciones sin conocimiento previo de credenciales válidas. El credential stuffing es más rápido y dirigido porque trabaja con credenciales reales, y tiene éxito específicamente debido a la reutilización de contraseñas entre servicios.

¿Qué sistemas son más comúnmente atacados por ataques de fuerza bruta?

Los endpoints de autenticación con exposición pública conllevan el mayor riesgo: servicios SSH y RDP, portales VPN, páginas de inicio de sesión de aplicaciones web, paneles de administración (WordPress /wp-admin, cPanel) y endpoints de autenticación API. La campaña de 2025 que utilizó 2,8 millones de IP se centró específicamente en puertas de enlace VPN y firewalls — dispositivos perimetrales que, si se comprometen, proporcionan acceso directo a las redes internas.

Introduction

At 3:14 AM, no one is watching the authentication logs. A script running on a rented cloud instance sends its ten-thousandth login attempt to a VPN portal. At 3:17 AM, it gets a response that's different from the others. Access granted. There is no malware, no social engineering, no insider threat. Just a weak password, automated patience, and a gap in monitoring.

One in three successful attacks against web applications now begins the same way: an automated script cycling through credentials until something works. According to the 2025 Verizon Data Breach Investigations Report, brute force attacks against basic web applications nearly tripled over the last year — jumping from roughly 20% to 60%. It's a signal that automated credential attacks have become a primary weapon, not a fallback.

The underlying mechanics haven't changed: try combinations until one works. What has changed is the speed, scale, and intelligence behind those attempts. Modern GPU clusters, AI-assisted wordlist generation, and botnets spanning millions of compromised devices have transformed  what was once a slow, noisy attack into something fast, distributed, and difficult to detect.

This article covers what brute force attacks are, how they’ve evolved in 2026, the six main variants, real-world examples from 2025–2026, and a layered defense strategy your team can implement today.

Key takeaways

• Brute force attacks are automated credential attacks — scripts systematically cycle through username and password combinations until one works, exploiting weak, reused, or predictable passwords rather than software vulnerabilities.
• Six distinct variants target different weaknesses: simple brute force, dictionary attacks, credential stuffing, password spraying, reverse brute force, and hybrid attacks — each designed to bypass a specific set of defenses.
• Modern hardware has made weak passwords indefensible: a GPU cluster can crack an 8-character MD5-hashed password in minutes. Password length and secure hashing are what determine real-world resistance.
• Layered defenses work but only when consistently enforced. MFA, strong password policies, breach database screening, account lockouts, rate limiting, and a password manager collectively make brute force attacks impractical. Any single gap is enough for an attacker to exploit.
• Detection is a preventive control, not just a reactive one. Recognizing attack signatures — failed login spikes, low-and-slow spraying patterns, impossible travel — gives your team time to block the source before credentials are validated.
• A password manager is the structural fix for credential reuse — the root cause behind credential stuffing. For teams, it also enforces rotation, flags compromised credentials, and closes the offboarding gap that leaves stale credentials valid for years.

What is a brute force attack?

A brute force attack gains unauthorized access to a system by systematically trying every possible combination of credentials (usernames, passwords, or encryption keys) until the correct one is found. It exploits  human behavior: weak, reused, or predictable passwords.

Think of it as trying every key on a keyring. Given enough time and computing power, one will eventually fit. The attacker's goal is to reduce that time to something practical and in 2026, modern hardware makes that increasingly achievable.

Brute force attacks target authentication endpoints: login pages, SSH and RDP services, VPN portals, API gateways, and admin panels. Any system that accepts a username and password is a potential target.

How brute force attacks work in 2026

At its core, a brute force attack is automation at scale. An attacker deploys a script or tool that sends credential combinations to a target system's authentication endpoint in rapid succession. The script logs successful matches and moves on.

What separates 2026 from a decade ago is the infrastructure behind those scripts.

The AI and hardware factor

Modern graphics cards (originally designed for gaming and machine learning) are exceptionally efficient at parallel computation, which is exactly what password cracking requires. A cluster of 12 NVIDIA RTX 5090 GPUs can test hundreds of billions of MD5 hash combinations per second (Hive Systems).

Against weakly hashed credentials, an 8-character password falls in minutes — or less. Against bcrypt with modern cost settings, the same hardware may take years. The difference isn't the attacker's hardware. It's whether the target system stores passwords securely.

Machine learning models trained on leaked password datasets (tools like PassGAN, built on generative adversarial networks) learn real-world password distributions without human-written rules. They predict likely patterns: birthdays appended to names, common character substitutions, culturally specific phrases.

In testing against the RockYou breach dataset, PassGAN matched 47% of real passwords. Сombined with conventional cracking tools, it uncovered 24% more matches than either approach alone. The search space doesn't shrink by brute force — it shrinks by prediction.

The quantum threat

Quantum computing uses quantum-mechanical phenomena to process information in ways classical computers cannot. Where a classical processor works through possibilities sequentially, a quantum system evaluates many states simultaneously. Applied to cryptography, that parallelism becomes a direct threat to the mathematical problems that underpin current encryption.

Quantum computing introduces a longer-term risk. IBM's quantum roadmap projects that cryptographically relevant quantum computers could undermine current asymmetric encryption standards within this decade.

Quantum  attacks on hashed passwords remain theoretical, but organizations managing long-lived secrets and encryption keys should begin evaluating post-quantum cryptography standards — NIST finalized its first post-quantum standards in 2024.

Botnets and distributed attacks

A botnet is a network of compromised devices (servers, routers, IoT endpoints, personal computers) controlled remotely by an attacker without their owners' knowledge. Each device acts as an independent node, capable of sending requests, probing systems, or submitting login attempts. The scale can reach millions of machines operating in coordination.

Attackers rarely operate from a single IP. Modern brute force campaigns use botnets to distribute login attempts across different source addresses, bypassing IP-based rate limiting and geographic blocking.

In early 2025, the Shadowserver Foundation tracked a campaign using 2.8 million IP addresses daily to target  VPN login portals from Palo Alto Networks, Ivanti, and SonicWall (BleepingComputer).

The attacking nodes were predominantly compromised MikroTik, Huawei, and Cisco routers — hijacked devices spread across dozens of countries, with the largest cluster originating from Brazil. The traffic was routed through residential proxy networks, making each attempt appear to come from a regular home user rather than a bot. Standard IP-based defenses saw what looked like normal traffic.

Types of brute force attacks

Brute force attacks share one principle: gain access by systematically testing credentials until something works. The methods differ in what they test, how they source their data, and which defenses they're designed to bypass.

1. Simple brute force attack

The most straightforward variant: every possible character combination is tried in sequence — aaa, aab, aac — until a match is found. No prior knowledge of the target is required. The attack relies entirely on computational power.

It is effective only against short or simple passwords. Against an 8-character password using mixed characters, modern GPU clusters can complete the search in hours. Beyond 12 characters, the same approach becomes computationally impractical — the search space grows exponentially with each added character.

2. Dictionary attack

A dictionary attack replaces exhaustive enumeration with a curated list of likely passwords (words, phrases, and known credentials) dramatically narrowing the search space. The attacker bets on human predictability rather than raw computation.

These lists range from basic compilations of the 10,000 most common passwords to multi-gigabyte datasets built from leaked credentials, regional slang, and industry-specific terminology. Any password that resembles natural language is vulnerable. Randomness is the only reliable defense.

3. Credential stuffing

Credential stuffing is the automated reuse of username and password pairs stolen from previous data breaches. Attackers take username and password pairs and test them against other services, exploiting the fact that many users reuse the same credentials across multiple accounts.

In July 2024, a compilation of nearly 10 billion unique passwords — dubbed RockYou2024 — was posted on a criminal forum, providing attackers with an unprecedented pool of credentials to work from (Cybernews, 2024).

Understanding the dangers of password reuse is essential context here — a single compromised account on one platform can cascade into access across an entire digital footprint.

4. Password spraying

Password spraying inverts the typical approach. Rather than trying many passwords against one account (which triggers lockouts), the attacker tries one or two common passwords — Password1!, Welcome2026 — across thousands of accounts.

It stays below lockout thresholds and is particularly effective against large organizations with weak password policies. Over 97% of identity attacks involve password spray or brute force, according to Microsoft Digital Defence Report 2025.

5. Reverse brute force attack

A reverse brute force attack starts with a known password (typically sourced from a breach or a known default) and tests it systematically against a list of usernames. The credential is fixed; the identity is the unknown.

This method is most effective when the target password is widely shared: a default corporate password distributed during onboarding, a common pattern mandated by a weak policy, or a credential that appeared in a previous leak. Where a standard attack probes one account deeply, a reverse attack probes many accounts with surgical precision.

6. Hybrid brute force attack

A hybrid brute force attack combines dictionary words with programmatic mutations — appending numbers, years, or special characters (Summer2026!, admin@123), substituting letters with symbols, or shifting capitalization. It is designed to crack passwords that appear complex but follow predictable construction patterns.

These attacks target the gap between password policy and human behavior. When users are required to "complicate" a password, they rarely introduce true randomness — they append 1! to a familiar word or capitalize the first letter. Hybrid attacks are built to exploit exactly that instinct, making rule-based complexity requirements a weaker defense than length alone.

Brute force attack comparison table

Managing credentials across a large team creates exactly the attack surface brute force campaigns exploit. See how Passwork structures team vaults with role-based access and enforced password policies

Real-world brute force attack examples (2025)

Brute force and credential stuffing attacks continue to be a significant threat, evolving in sophistication and scale. The following cases from 2025 and 2026 highlight the persistent risks and the critical importance of robust authentication and security practices.

Australian superannuation funds — March 2025

Attack type: Credential stuffing (coordinated, multi-target).

Over the weekend of 29–30 March 2025, five major Australian pension funds (AustralianSuper, REST Super, Hostplus, Australian Retirement Trust, and Insignia Financial) were simultaneously targeted using combo lists from unrelated prior breaches. Over 20,000 accounts were compromised.

Four AustralianSuper members collectively lost AUD 500,000. REST shut down its MemberAccess portal entirely after ~8,000 members had personal data exposed.

23andMe — 2023 → regulatory consequences in 2025

Attack type: Credential stuffing

Between April and September 2023, attackers tested credentials from unrelated breaches against 23andMe accounts. Through the DNA Relatives feature, initial compromises cascaded into exposure of genetic and ancestry data belonging to approximately 6.9 million users — most of whom had never been directly targeted.

"Mega Leak" — 16 billion credentials exposed — June 2025

Attack type: Credential stuffing (source data)

In June 2025, Cybernews researchers discovered ~30 datasets containing over 16 billion login records — URLs, usernames, and plaintext passwords. The data was harvested primarily by infostealer malware targeting consumer devices. Platforms affected included Google, Apple, Facebook, and others. Notably, BleepingComputer confirmed the datasets include a significant proportion of recycled credentials from older breaches, meaning not all records represent fresh exposures.

Jaguar Land Rover — March 2025 + September 2025

Attack type: Credential stuffing / stolen credentials (infostealer-sourced)

In March 2025, the HELLCAT ransomware group breached JLR using stolen Jira credentials harvested via infostealer malware. Threat actor "Rey" leaked ~700 internal documents on 10 March. Days later, a second actor "APTS" used credentials dating back to 2021 — belonging to a third-party contractor — to access the same Jira server and leak an additional ~350 GB of data including source code, development logs, and employee records.

In September 2025, a separate attack attributed to a group calling itself "Scattered Spider Lapsus$ Hunters" shut down global IT systems and halted manufacturing at the Halewood plant, with employees sent home.

Summary table

How to detect a brute force attack

Prevention is the goal, but detection is the safety net. Brute force attacks leave consistent signatures in authentication logs — if you know what to look for.

• Spikes in failed login attempts — A sudden increase in authentication failures against a single account, or spread across many, is the most direct indicator. Establish a baseline for your environment and alert on deviations.
• Multiple lockouts from the same source IP — Even distributed attacks leave partial patterns. Repeated lockouts originating from the same IP range or ASN (Autonomous System Number) suggest automated activity.
• Impossible travel — A user authenticating from London and then from Singapore within 30 minutes triggers an automatic flag in modern SIEM and identity platforms. The signal alone is not conclusive: VPN exit nodes, split-tunneling configurations, and cloud proxy services routinely produce false positives. The value is in the investigation it prompts — not the assumption it confirms.
• High request volume to authentication endpoints — Hundreds of POST requests per minute to /login or /api/auth from a single source is not organic traffic. Monitor your login endpoints for request rates that exceed human typing speed.
• Distributed low-and-slow patterns — Password spraying specifically avoids triggering per-account lockouts. Look for a pattern where many different accounts each receive exactly one or two failed attempts within a short window — this is the spraying signature.
• Unusual user-agent strings or missing headers — Automated tools often send requests with generic or absent user-agent strings, missing standard browser headers, or with unusual TLS fingerprints.

How to prevent brute force attacks

Defense against brute force is a stack. Each layer compensates for the weaknesses of the others.

Enforce strong password policies

Length matters more than complexity. A 16-character passphrase is exponentially harder to crack than an 8-character string of mixed characters. Move your organization away from minimum-length policies that technically permit P@ssw0rd and toward minimum-entropy policies that require genuine unpredictability. Review enterprise password management best practices for a structured framework.

Key requirements per NIST SP 800-63B:

• Minimum 15 characters for accounts without MFA; minimum 8 with MFA enforced
• No arbitrary complexity rules that produce predictable patterns
• Maximum length of at least 64 characters to support passphrases
• Block passwords that appear in breach databases — check new credentials against services like Have I Been Pwned at the point of creation, not after the fact

Screen credentials against breach databases

Before a password is accepted, verify it hasn't already appeared in a known data breach. NIST SP 800-63B and OWASP both require this as a distinct control — separate from password length or complexity rules. An attacker running a dictionary attack against your systems is working from the same leaked datasets. Blocking those passwords at registration removes them from the attack surface entirely.

Implement multi-factor authentication

MFA is the single most effective control against credential-based attacks — a compromised password alone is not enough  for access. That said , MFA is not infallible. MFA fatigue attacks — where attackers send repeated push notifications until a user approves one out of frustration — have bypassed MFA at major organizations. Phishing-resistant MFA methods such as FIDO2 and passkeys  eliminate this vector entirely. 

Configure account lockouts and progressive delays

Configure authentication systems to lock accounts after a defined number of failed attempts (typically 5–10), or implement progressive delays that increase exponentially with each failure. Progressive delays are often preferable to hard lockouts, which can themselves be weaponized for denial-of-service against legitimate users.

Apply rate limiting at the IP and ASN level

Account lockout protects individual accounts. Rate limiting protects the authentication endpoint itself. These are different controls with different targets. Restrict the number of login requests per IP address per time window. Escalate to ASN-level blocking when distributed patterns emerge.

Deploy CAPTCHA and bot management

CAPTCHA challenges differentiate human users from automated scripts at the authentication layer. Modern bot management platforms go further, analyzing behavioral signals — mouse movement, typing cadence, TLS fingerprints — to identify non-human traffic before it reaches the login form.

Implement zero trust architecture

Zero trust operates on the principle that no user, device, or network segment is inherently trusted. Even after successful authentication, access is continuously verified based on context: device health, location, behavior, and least-privilege access rules. If a brute force attack does compromise  one account, zero trust limits the blast radius by preventing lateral movement to other systems and resources.

Monitor authentication logs and alert on anomalies

Detection is a preventive control, not just a reactive one. Catching an attack in progress gives your team time to block the source, invalidate sessions, and contain the damage. Configure SIEM alerts for: spikes in failed authentication attempts, impossible travel events, high request volume to login endpoints, and the low-and-slow spraying pattern where many accounts each receive exactly one or two failures within a short window.

Use a password manager

Password reuse is the fuel that makes credential stuffing viable at scale. When one breach exposes a credential, every other service where that password is reused becomes vulnerable — automatically, without any additional effort from the attacker. A password manager eliminates this by generating and storing a unique, high-entropy password for every account, making reuse structurally impossible.

For individual users, any reputable password manager achieves this. For teams and organizations, the requirements are different and the stakes are higher.

Passwork is built specifically for this environment. It gives IT teams a centralized, structured vault where credentials are organized with granular, role-based access control: each user sees only what their role permits, nothing more. Shared credentials are stored in shared vaults with defined permissions.

Several of Passwork's features directly address the attack vectors covered in this article:

• Customizable password generator — enforces length and complexity requirements at the point of creation, so policy compliance isn't left to individual judgment.
• Password security dashboard — continuously tracks the status of all stored credentials, flagging weak, reused, outdated, and potentially compromised passwords across the entire vault. When an employee leaves, Passwork automatically marks every credential they had access to as potentially compromised and prompts rotation.
• Zero-knowledge client-side encryption — credentials are encrypted on the client side before they ever reach the server. Even with full access to the database or underlying infrastructure, an attacker retrieves nothing readable. The encryption key never leaves the user's device.
• Full audit log — every action in the vault is logged: who accessed what, when, and from where. This is the visibility layer that makes post-incident investigation possible and supports compliance with GDPR, NIS2, and similar frameworks.
• Two-factor authentication, passkeys, and hardware security keys — Passwork supports 2FA via authenticator apps and WebAuthn-based authentication including biometrics and FIDO2 hardware keys, adding a second layer beyond the vault password itself.
• Configurable account lockout — administrators set the threshold of failed login attempts after which an account is locked. This applies brute-force and credential stuffing protection at the vault level itself — not just at the network perimeter.
• Self-hosted deployment — Passwork runs entirely within your own infrastructure. Credential data never leaves your environment, is encrypted with AES-256 on both server and client sides (zero-knowledge architecture), and is managed exclusively by your team.

The JLR breach illustrated what happens without this structure: credentials from 2021 belonging to a third-party contractor were still valid four years later, with no rotation and no MFA on the Jira instance. A centralized vault with enforced rotation policies and an offboarding workflow would have closed that window before it was exploited.

Conclusion

Brute force attacks have become more scalable in practice. Cheap GPU compute, AI-assisted wordlist generation, and massive botnets mean that what once required significant resources now requires almost none. The 37% share of web application attacks attributed to brute force in the 2025 Verizon DBIR is the result of that accessibility.

The good news: the defenses work. MFA, strong and unique passwords, account lockout policies, and behavioral monitoring collectively make brute force attacks impractical against a hardened target. Attackers move toward lowest resistance  — which means organizations that implement layered authentication security effectively remove themselves from the easy-target pool.

The real risk is that they're inconsistently applied — one team using MFA, another not. Shared credentials stored in spreadsheets; password policies that exist on paper but aren't enforced technically. Closing those gaps is where the real work lies.

Passwork gives IT teams a structured, auditable credential vault with role-based access — built for the environments where inconsistency creates risk. Full self-hosted deployment and zero-knowledge encryption — on your infrastructure from day one. Get free trial

Frequently asked questions

What is the difference between a brute force attack and a dictionary attack?

A simple brute force attack tries every possible character combination systematically, with no prior knowledge. A dictionary attack uses a curated list of likely passwords — common words, known phrases, leaked credentials — to reduce the search space. Dictionary attacks are faster and more targeted; simple brute force is exhaustive but slower. Both are defeated by long, random passwords that don't resemble natural language.

Can brute force attacks bypass MFA?

Standard brute force cannot bypass MFA directly — a correct password alone isn't enough  for access. However, attackers use adjacent techniques: MFA fatigue (sending repeated push notifications until the user approves), real-time phishing (capturing and replaying MFA tokens), and session hijacking (stealing authenticated session cookies after login). Phishing-resistant MFA methods such as FIDO2 hardware keys and passkeys eliminate the phishing and fatigue vectors entirely.

Are brute force attacks illegal?

Yes. Unauthorized brute force attacks against systems you do not own or have explicit permission to test are illegal under computer fraud legislation in most jurisdictions — including the Computer Fraud and Abuse Act (CFAA) in the United States, the Computer Misuse Act in the United Kingdom, and the EU Directive on Attacks Against Information Systems (2013/40/EU). Penalties include significant fines and imprisonment. Authorized penetration testing requires written permission from the system owner.

How long does it take to crack a password with brute force?

It depends on password length, character set, and how the hash is stored. A 8-character MD5-hashed password falls in under an hour against a modern GPU cluster. The same password hashed with bcrypt at a high cost factor may take years on the same hardware. Length is the most reliable variable under your control: every additional character multiplies the search space exponentially. A 16-character passphrase against bcrypt is computationally impractical to crack with current hardware.

What is credential stuffing and how does it differ from brute force?

Credential stuffing uses verified username/password pairs from previous data breaches and tests them against other services. It doesn't guess — it reuses. Brute force generates or cycles through combinations without prior knowledge of valid credentials. Credential stuffing is faster and more targeted because it works with real credentials, and it succeeds specifically because of password reuse across services.

What systems are most commonly targeted by brute force attacks?

Authentication endpoints with public exposure carry the highest risk: SSH and RDP services, VPN portals, web application login pages, admin panels (WordPress /wp-admin, cPanel), and API authentication endpoints. The 2025 campaign utilizing  2.8 million IPs focused specifically on VPN gateways and firewalls — perimeter devices that, if compromised, provide direct access to internal networks.

NIS2 compliance latest news: June and July 2026 enforcement update

Four EU member states referred to court, the Netherlands’ NIS2 law enters force August 15, Germany’s BSI is auditing 29,000 entities, and the EU published its first AI-cybersecurity action plan. Here’s everything that changed in June–July 2026.

Passwork BlogPasswork Team

Shadow IT in 2026: Risks, detection, and how to manage it

Shadow IT in 2026 spans AI agents, orphaned SaaS accounts, and unmonitored LLM sessions — risks most organizations can’t see. Learn what’s changed, what it costs, and how a 6-step governance framework closes the gap.

Passwork BlogAlex Muntyan

Team password management: The complete guide for 2026

Learn how teams share credentials securely in 2026 — RBAC, audit logs, offboarding checklists, NIST SP 800-63B Rev. 4 requirements, and self-hosted vs. cloud deployment.

Passwork BlogAlex Muntyan

Einleitung

Datenresidenz und Datensouveränität klingen fast wie dasselbe. Sind sie aber nicht.

Viele europäische Unternehmen wählen einen US-basierten Anbieter, entscheiden sich für die EU-Rechenzentrum-Option und betrachten die Frage der Datenresidenz als gelöst. Rechtlich ist sie das nicht. Der US CLOUD Act gibt amerikanischen Bundesbehörden die Befugnis, jedes in den USA eingetragene Unternehmen zur Herausgabe von Daten zu zwingen, die überall auf der Welt gespeichert sind. Die Daten befinden sich in Europa. Die rechtliche Verpflichtung nicht.

Dies ist die Spannung, auf die europäische Unternehmen stoßen, wenn sie entscheiden, wie sie einen Passwort-Manager hosten. DSGVO, NIS2, DORA und der CLOUD Act schaffen sich überschneidende Anforderungen, die sich nicht durch die Wahl des nächstgelegenen Rechenzentrums lösen lassen. Das Hosting-Modell (wem die Infrastruktur gehört, unter welcher Rechtsordnung, mit welchem Maß an organisatorischer Kontrolle) ist es, was das Compliance-Bild tatsächlich bestimmt.

Dieser Leitfaden zeigt die Hosting-Modelle auf, die europäischen Unternehmen zur Verfügung stehen, den regulatorischen Rahmen, der jedes einzelne prägt, und die Kriterien, die die Entscheidung bestimmen sollten.

Kernaussagen

• Die Wahl eines EU-Rechenzentrums löst die Datensouveränität nicht. Wenn der Anbieter in den USA eingetragen ist, zwingt der CLOUD Act ihn, Daten an amerikanische Behörden herauszugeben — unabhängig davon, wo sich die Server physisch befinden.
• Vier regulatorische Rahmenwerke prägen die Hosting-Entscheidung. DSGVO, NIS2, DORA und der US CLOUD Act schaffen sich überschneidende Verpflichtungen, die keine Rechenzentrumsauswahl allein erfüllen kann. Das Hosting-Modell bestimmt die rechtliche Verteidigungsfähigkeit.
• On-Premises ist das einzige Modell, das den Zugriff Dritter konstruktionsbedingt ausschließt. Es eliminiert die CLOUD-Act-Exposition vollständig und gibt der Organisation die volle Infrastrukturkontrolle, erfordert jedoch interne IT-Kapazitäten für Betrieb und Wartung.
• Souveräne EU-Cloud ist ein glaubwürdiger Mittelweg. Die europäischen Ausgaben für souveräne Cloud-IaaS sollen 2026 voraussichtlich 12,6 Milliarden US-Dollar erreichen — ein Anstieg von 83 % im Jahresvergleich (Gartner, 2026). Das Modell liefert verwaltete Infrastruktur ohne Risiko ausländischer Rechtsordnung.
• Das richtige Modell hängt von vier Variablen ab. Branchenklassifizierung, regulatorische Exposition, interne IT-Kapazität und Gesamtbetriebskosten bestimmen, ob On-Premises, souveräne EU-Cloud oder hybride Architektur die vertretbare Wahl ist.

Das europäische Hosting-Spektrum

Europäischen Unternehmen stehen fünf unterschiedliche Hosting-Konfigurationen für einen Passwort-Manager zur Verfügung. Zwei fallen für die meisten EU-Unternehmen außerhalb realistischer Compliance-Überlegungen. Drei sind einer eingehenden Bewertung wert.

US-Cloud mit US-Rechenzentrum liegt außerhalb des Umfangs dieses Leitfadens und für die meisten europäischen Unternehmen außerhalb des Bereichs realistischer Überlegungen. Wenn sich Server in den Vereinigten Staaten befinden und die Muttergesellschaft in den USA eingetragen ist, befinden sich die Daten physisch außerhalb der EU. Diese Kombination löst DSGVO-Übertragungspflichten gemäß Artikeln 44–49 aus und schafft gleichzeitig volle CLOUD-Act-Exposition.

US-Cloud mit EU-Rechenzentrum ist einen Schritt näher an der Compliance — aber keine saubere Lösung. Der Passwort-Manager-Anbieter betreibt Server in einer EU-Region (z. B. Frankfurt, Dublin), sodass sich die Daten physisch in Europa befinden. Das erfüllt die DSGVO-Anforderungen zur Datenresidenz auf dem Papier. Wenn die Muttergesellschaft jedoch in den USA eingetragen ist, gilt der US CLOUD Act unabhängig davon, wo sich die Server befinden. Amerikanische Behörden können legal Zugang zu diesen Daten verlangen, ohne EU-Rechtskanäle zu nutzen. Das Risiko ist geringer als beim vorherigen Modell, aber Souveränität ist nicht garantiert.

Die drei Modelle, die einer Bewertung wert sind:

• Souveräne EU-Cloud. Der Dienst läuft auf Infrastruktur, die von EU-basierten Anbietern betrieben wird, außerhalb der US- oder anderer ausländischer Rechtsordnung. Dieses Modell erfüllt die DSGVO-Anforderungen zur Datenresidenz und eliminiert die CLOUD-Act-Exposition.
• On-Premises-Bereitstellung. Der Passwort-Manager läuft vollständig innerhalb der eigenen Infrastruktur der Organisation (physische Server, Private Cloud oder Air-Gap-Umgebungen). Kein Drittanbieter hat Zugriff auf die Anmeldedaten. Dies ist das einzige Modell, das vollständige Infrastrukturkontrolle bietet.
• Hybride Architektur. Eine Kombination aus On-Premises-Tresoren für sensible Anmeldedaten und cloudbasiertem Zugriff für verteilte Teams. Erfordert sorgfältige Richtliniengestaltung, um Compliance-Lücken zwischen den beiden Umgebungen zu vermeiden.

Die Wahl zwischen diesen Modellen ist eine Frage der Regulierung und des Risikomanagements.

Wie EU-Vorschriften das Passwort-Manager-Hosting bestimmen

DSGVO, NIS2, DORA und der US CLOUD Act erlegen jeweils spezifische Verpflichtungen auf, die direkt einschränken, welches Hosting-Modell eine europäische Organisation vertretbar wählen kann. Das Verständnis der Wechselwirkung zwischen diesen Rahmenwerken ist der Ausgangspunkt für jede Bereitstellungsentscheidung.

DSGVO und Datenresidenz

Die Datenschutz-Grundverordnung ist das primäre Rechtsrahmenwerk der EU für die Erhebung, Speicherung und Übertragung personenbezogener Daten. Sie gilt für jede Organisation, die personenbezogene Daten von EU-Bürgern verarbeitet, unabhängig davon, wo diese Organisation ihren Sitz hat.

Die DSGVO verlangt nicht ausdrücklich, dass Daten innerhalb der EU gespeichert werden. Sie verlangt, dass personenbezogene Daten, die außerhalb der EU übertragen werden, nach einem gleichwertigen Standard geschützt werden — durch Standardvertragsklauseln (SCCs), Angemessenheitsbeschlüsse oder andere Übertragungsmechanismen gemäß Artikeln 44–49. Für einen Passwort-Manager, der Mitarbeiter-Anmeldedaten und zugehörige Metadaten (Benutzernamen, URLs, E-Mail-Adressen) speichert, gilt die DSGVO direkt.

„Jegliche Übermittlung personenbezogener Daten, die bereits verarbeitet werden oder nach ihrer Übermittlung an ein Drittland oder eine internationale Organisation zur Verarbeitung bestimmt sind, ist nur zulässig, wenn der Verantwortliche und der Auftragsverarbeiter die in diesem Kapitel niedergelegten Bedingungen einhalten und auch die sonstigen Bestimmungen dieser Verordnung eingehalten werden." — DSGVO, Artikel 44 (Allgemeine Grundsätze der Datenübermittlung)

Das Risiko ist nicht theoretisch. Im August 2024 verhängte die niederländische Datenschutzbehörde eine Geldstrafe von 290 Millionen Euro gegen Uber wegen der Übertragung personenbezogener Daten europäischer Taxifahrer auf US-Server ohne Anwendung der nach DSGVO Kapitel V erforderlichen Schutzmaßnahmen. Keine Standardvertragsklauseln, kein Angemessenheitsbeschluss, kein alternativer Übertragungsmechanismus. Der Verstoß erstreckte sich über mehr als zwei Jahre. Der Fall veranschaulicht direkt, wie die Durchsetzung von Artikel 44 in der Praxis aussieht: Mitarbeiterdaten, grenzüberschreitende Infrastruktur und eine neunstellige Strafe.

NIS2 und kritische Infrastruktur

Die NIS2-Richtlinie (Netz- und Informationssicherheitsrichtlinie 2) ist die primäre Cybersicherheitsgesetzgebung der EU und ersetzt die ursprüngliche NIS-Richtlinie von 2016. Sie legt verbindliche Sicherheitsanforderungen für Organisationen fest, die in kritischen Sektoren in den EU-Mitgliedstaaten tätig sind, mit Schwerpunkt auf Risikomanagement, Vorfallmeldung und Lieferkettensicherheit.

NIS2 erweitert den Kreis der als „wesentliche" oder „wichtige" Einrichtungen eingestuften Organisationen erheblich. Sektoren wie Energie, Verkehr, Bankwesen, Gesundheitswesen, digitale Infrastruktur und öffentliche Verwaltung müssen ihre Technologieanbieter nun als Teil ihres Sicherheitsperimeters behandeln, nicht nur ihre interne Infrastruktur.

Ein Passwort-Manager, der Anmeldedaten in einer Drittanbieter-Cloud-Umgebung speichert, fällt unter diesen Perimeter. Er ist ein direkter Lieferant eines sicherheitskritischen Dienstes. NIS2 Artikel 21(2) verlangt von den betroffenen Einrichtungen die Umsetzung von Maßnahmen, die mindestens Folgendes umfassen:

„Sicherheit der Lieferkette einschließlich sicherheitsbezogener Aspekte der Beziehungen zwischen den einzelnen Einrichtungen und ihren unmittelbaren Anbietern oder Diensteanbietern." — NIS2-Richtlinie, Artikel 21(2), Richtlinie (EU) 2022/2555

Die Wahl eines US-basierten Cloud-Anbieters für die Speicherung von Anmeldedaten ohne dokumentierte Risikobewertung schafft eine konkrete Compliance-Lücke. Nach NIS2 können nationale Aufsichtsbehörden verbindliche Anweisungen erteilen und Bußgelder verhängen. Für wesentliche Einrichtungen begründet Artikel 20 auch die persönliche Haftung der Mitglieder des Leitungsorgans.

DORA und Besonderheiten des Finanzsektors

Der Digital Operational Resilience Act (DORA) ist das regulatorische Rahmenwerk der EU für digitale operationelle Resilienz im Finanzsektor. Er legt Anforderungen fest, wie Finanzunternehmen IKT-Risiken (Informations- und Kommunikationstechnologie) managen, und deckt Drittanbieterabhängigkeiten, Vorfallmeldung und Resilienztests ab, um die Stabilität von Finanzdienstleistungen in der EU zu gewährleisten.

Ein cloudbasierter Passwort-Manager qualifiziert sich als IKT-Drittanbieter-Dienst nach DORA. Diese Einstufung löst spezifische vertragliche Verpflichtungen aus — einschließlich der Anforderung zu dokumentieren, wo Daten gespeichert und verarbeitet werden. Artikel 30(2)(b) der Verordnung (EU) 2022/2554 lautet:

„Die Standorte, d. h. die Regionen oder Länder, in denen die vertraglich vereinbarten oder ausgelagerten Funktionen und IKT-Dienste erbracht werden sollen und in denen Daten verarbeitet werden sollen, einschließlich des Speicherorts, sowie die Anforderung an den IKT-Drittanbieter, das Finanzunternehmen vorab zu benachrichtigen, wenn er beabsichtigt, solche Standorte zu ändern." — DORA, Artikel 30(2)(b), Verordnung (EU) 2022/2554

Wenn der Passwort-Manager-Anbieter in den USA ansässig ist, muss das Finanzinstitut dokumentieren, wie es die CLOUD-Act-Exposition handhabt, und sicherstellen, dass der Vertrag die DORA-Anforderungen für Datenzugang, Portabilität und Kündigung erfüllt.

Der US CLOUD Act

Der Clarifying Lawful Overseas Use of Data Act (CLOUD Act, 2018) ist ein US-Bundesgesetz, das Strafverfolgungsbehörden ermöglicht, in den USA eingetragene Unternehmen zur Herausgabe von Daten zu zwingen, die überall auf der Welt gespeichert sind, einschließlich Servern in EU-Rechenzentren. Die Verpflichtung gilt unabhängig davon, wo sich die Daten physisch befinden. Der entscheidende Faktor ist die Unternehmensgerichtsbarkeit des Anbieters.

Das Gesetz ist in diesem Punkt eindeutig:

„Ein Anbieter von elektronischen Kommunikationsdiensten oder Remote-Computing-Diensten muss den Verpflichtungen dieses Kapitels nachkommen, Inhalte einer leitungsgebundenen oder elektronischen Kommunikation sowie Aufzeichnungen oder andere Informationen in Bezug auf einen Kunden oder Abonnenten, die sich im Besitz, Gewahrsam oder unter der Kontrolle des Anbieters befinden, zu sichern, zu sichern oder offenzulegen, unabhängig davon, ob sich diese Kommunikation, Aufzeichnung oder andere Information innerhalb oder außerhalb der Vereinigten Staaten befindet." — 18 U.S.C. § 2713, Pub. L. 115–141, div. V, §103(a)(1), 23. März 2018

Das Unternehmen kann die Anordnung anfechten, aber die rechtliche Verpflichtung besteht unabhängig davon, wo sich die Server befinden.

Für europäische Organisationen, die mit sensiblen Anmeldedaten umgehen (privilegierter Zugang, Passwörter für Finanzsysteme, Infrastrukturschlüssel), schafft dies ein strukturelles Risiko, das EU-Regionen-Rechenzentren allein nicht lösen. Souveräne Cloud oder On-Premises-Bereitstellung sind die einzigen Modelle, die diese Exposition vollständig eliminieren.

Passwork ist ein europäischer Passwort-Manager, der genau für dieses regulatorische Umfeld entwickelt wurde — mit On-Premises- und Cloud-Optionen, die auf DSGVO- und NIS2-Compliance sowie Datensouveränität ausgelegt sind. So funktioniert es

Cloud-Passwort-Manager in Europa: Komfort vs. Kontrolle

Cloud-Hosting bedeutet, dass die Server des Anbieters Ihre Daten speichern und verarbeiten — die Organisation greift über das Internet auf den Dienst zu, ohne die zugrunde liegende Infrastruktur zu verwalten. Bei Passwort-Managern bedeutet dies, dass Anmeldedaten, Metadaten und Zugriffsprotokolle auf Servern liegen, die einem Dritten gehören und von diesem betrieben werden, in Rechenzentren, die die Organisation nicht kontrolliert.

Cloudbasierte Passwort-Manager bieten schnelle Bereitstellung, automatische Updates und keinen Infrastruktur-Overhead. Für viele europäische Organisationen sind sie die Standardwahl — 53 % der EU-Unternehmen nutzten 2025 kostenpflichtige Cloud-Computing-Dienste, ein Anstieg um 7,4 Prozentpunkte gegenüber 2023 (Eurostat, 2026).

Der Reiz ist offensichtlich: keine Server zu warten, der Anbieter übernimmt das Patching, und der Zugriff funktioniert von jedem Gerät aus. Für KMU ohne dedizierte Sicherheitsteams senkt dies die Hürde für die Einführung eines ordnungsgemäßen Anmeldedaten-Managements.

Wo Cloud für EU-Organisationen zu kurz greift

Das Modell der geteilten Verantwortung ist das zentrale Thema. Bei einer Cloud-Bereitstellung kontrolliert der Anbieter die Infrastruktur, die Architektur des Verschlüsselungsschlüssel-Managements und die Backup-Systeme. Die Organisation kontrolliert den Benutzerzugang und die Richtlinien, aber nicht die zugrunde liegende Datenumgebung.

Zero-Knowledge-Architektur adressiert dies teilweise: Wenn der Anbieter niemals die Entschlüsselungsschlüssel besitzt, kann ein serverseitiger Sicherheitsvorfall keine Klartext-Anmeldedaten offenlegen. Die ICO-Strafe gegen LastPass veranschaulicht die Grenzen — der Vorfall legte Metadaten (Namen, E-Mails, URLs) offen, obwohl verschlüsselte Tresorinhalte geschützt waren. Metadaten sind personenbezogene Daten nach der DSGVO.

AES-256-Verschlüsselung im Ruhezustand ist eine Grundanforderung, kein Unterscheidungsmerkmal. Entscheidend ist, wo Schlüssel generiert und gespeichert werden, wer darauf zugreifen kann und ob die Architektur des Anbieters diese Schlüssel außerhalb seiner eigenen Reichweite hält.

On-Premises-Passwort-Manager: Maximale Souveränität

On-Premises-Bereitstellung bedeutet, dass der Passwort-Manager auf Servern läuft, die der Organisation gehören und von ihr betrieben werden — kein Anbieter hat Netzwerkzugriff auf den Anmeldedatenspeicher. Alle Anmeldedaten, Metadaten und Zugriffsprotokolle verbleiben innerhalb des eigenen Infrastrukturperimeters der Organisation.

Dies ist das einzige Hosting-Modell, das die Anforderungen an die Datensouveränität vollständig erfüllt und die Drittanbieter-Exposition konstruktionsbedingt eliminiert.

Für Organisationen in regulierten Sektoren (Finanzinstitute, Gesundheitsdienstleister, Betreiber kritischer Infrastrukturen unter NIS2) entfernt die On-Premises-Bereitstellung eine ganze Kategorie von Drittanbieter-Risiken aus der Compliance-Gleichung.

Wo On-Premises die einzige praktikable Option ist

Air-Gap-Umgebungen stellen die sicherste Variante dar: Der Passwort-Manager wird in einem Netzwerk ohne Internetverbindung betrieben. Dies ist relevant für industrielle Steuerungssysteme, klassifizierte Umgebungen oder jeden Kontext, in dem der Anmeldedatenspeicher physisch von externen Netzwerken isoliert sein muss.

Wie oben dargelegt, ist die On-Premises-Bereitstellung mit einem Nicht-US-Anbieter das einzige Modell, das die CLOUD-Act-Exposition vollständig eliminiert, indem es die US-Unternehmensgerichtsbarkeit entfernt, die die Verpflichtung überhaupt erst auslöst.

On-Premises-Bereitstellung: Vor- und Nachteile

Die TCO-Kalkulation verlagert Kosten von wiederkehrenden SaaS-Gebühren zu internen IT-Arbeitskosten und Infrastruktur. Für Organisationen, die bereits eigene Server betreiben und ein Sicherheitsteam haben, sind die Grenzkosten für das Hinzufügen eines selbst gehosteten Passwort-Managers oft niedriger als es erscheint.

Die tatsächlichen Kosten von On-Premises liegen in der operativen Disziplin, die für die Wartung erforderlich ist. Unternehmen ohne dediziertes Sicherheitsteam oder ausgereiften Patch-Management-Prozess werden feststellen, dass die Einschränkungsspalte schwieriger zu handhaben ist, als die Vorteilsspalte vermuten lässt.

Passwork ist als vollständig selbst gehostete Lösung verfügbar: auf den eigenen Servern der Organisation bereitgestellt, ohne ausgehende Verbindungen. Der Quellcode steht zur Prüfung zur Verfügung, und die Plattform unterstützt Air-Gap-Umgebungen. Für Teams, die Prüfern oder Regulierungsbehörden gegenüber vollständige Datensouveränität nachweisen müssen, ist dies das Bereitstellungsmodell, das die Diskussion beendet.

Passwork On-Premises gibt Ihrem Team volle Infrastrukturkontrolle — kein Drittanbieter-Zugriff, ohne Ausnahmen. On-Premises-Bereitstellung erkunden

Der souveräne Cloud-Mittelweg

Souveräne EU-Cloud-Anbieter bieten einen dritten Weg: verwaltete Infrastruktur mit Cloud-typischem Komfort, die vollständig innerhalb der EU-Rechtsordnung betrieben wird und außerhalb der Reichweite ausländischer Rechtsrahmen liegt. Die europäischen Ausgaben für souveräne Cloud-IaaS sollen 2026 voraussichtlich 12,6 Milliarden US-Dollar erreichen, ein Anstieg von 83 % gegenüber 2025 (Gartner, 2026).

Das Wachstum wird durch geopolitischen Druck angetrieben. Der US CLOUD Act, kombiniert mit aufsehenerregenden Vorfällen im Zusammenhang mit Hyperscaler-Abhängigkeit, hat europäische Organisationen dazu gebracht, ihre Cloud-Anbieterwahl zu überdenken.

Für einen Passwort-Manager, der auf souveräner Cloud-Infrastruktur bereitgestellt wird, liefert die Hosting-Umgebung dokumentierte Nachweise, dass die Daten innerhalb der EU-Rechtsordnung verbleiben — direkt relevant für die NIS2-Compliance-Dokumentation und DORA-Drittanbieter-Risikobewertungen.

Souveräne Cloud adressiert Rechtsordnung und Infrastrukturkontrolle. Sie ersetzt nicht die Notwendigkeit, die Passwort-Manager-Anwendung selbst zu bewerten. Die Hosting-Schicht und die Anwendungsschicht sind separate Sicherheitsfragen.

Hybride Architektur

Eine hybride Architektur kombiniert On-Premises-Tresore für sensible Anmeldedaten mit cloudbasiertem Zugriff für verteilte Teams. Es ist eine Richtlinien- und Engineering-Entscheidung, die explizite Grenzen zwischen dem erfordert, was lokal bleibt und was durch externe Infrastruktur läuft.

Der Reiz ist praktischer Natur. Organisationen mit Remote- oder international verteilten Teams können nicht immer jede Authentifizierungsanfrage durch ein On-Premises-System leiten, ohne Latenz- oder Verfügbarkeitsrisiken einzuführen. Ein hybrides Setup ermöglicht es Sicherheitsteams, die sensibelsten Anmeldedatenklassen (privilegierte Konten, Infrastruktur-Secrets, Compliance-sensible Anmeldedaten) in einem lokal kontrollierten Tresor zu halten und gleichzeitig den Zugriff auf weniger sensible Ressourcen über eine Cloud-Schicht zu erweitern.

Die Compliance-Komplexität skaliert jedoch mit der Architektur. Jede Grenze zwischen den On-Premises- und Cloud-Komponenten ist eine potenzielle Lücke: in der Audit-Abdeckung, in der Durchsetzung von Zugriffsrichtlinien, im Umfang der Incident Response. Wenn die Cloud-Schicht unter eine ausländische Rechtsordnung fällt, erstrecken sich die Souveränitätsschutzmaßnahmen der On-Premises-Komponente nicht automatisch darauf.

Hybride Architektur ist das flexibelste Modell in diesem Spektrum — und das anspruchsvollste im korrekten Betrieb. Für Organisationen mit der Engineering-Kapazität, es zu verwalten, bietet es eine praktikable Balance zwischen Kontrolle und Zugänglichkeit. Für diejenigen ohne diese Kapazität ist On-Premises oder souveräne EU-Cloud die vertretbarere Wahl.

Passwork für europäische Unternehmen: Von Anfang an für Souveränität gebaut

Passwork ist ein europäischer Passwort-Manager — als europäisches Unternehmen eingetragen und betrieben, mit rechtlichem Sitz in Spanien unter EU-Recht. Er wurde zuerst On-Premises entwickelt, für Organisationen, die volle Infrastrukturkontrolle benötigen, und bietet seitdem eine Cloud-Option, die vollständig innerhalb der EU gehostet wird.

Dies ist für europäische Unternehmen wichtig, weil die Rechtsordnung des Anbieters selbst Teil des Compliance-Bildes ist. Ein europäisches Unternehmen, das unter EU-Recht operiert, unterliegt keiner US-CLOUD-Act-Exposition. Die Architektur und Bereitstellungsoptionen von Passwork wurden mit diesem regulatorischen Kontext im Sinn entwickelt.

On-Premises-Bereitstellung

Passwork On-Premises läuft vollständig innerhalb der eigenen Infrastruktur der Organisation. Der Anbieter hat keinen Zugriff auf den Anmeldedatenspeicher — keinen Fernzugriff, keine Telemetrie und keine Hintertür. Alle Daten, Verschlüsselungsschlüssel und Backups verbleiben innerhalb der Systeme der Organisation.

Schlüsselfähigkeiten für regulierte Umgebungen:

• Volle Infrastrukturkontrolle — Bereitstellung auf eigenen Servern, Private Cloud oder Air-Gap-Netzwerken. Unterstützt Umgebungen ohne Internetverbindung.
• Zero-Knowledge-Architektur — Anmeldedaten werden auf der Client-Seite ver- und entschlüsselt. Der Server speichert nur Chiffretext und verarbeitet niemals Klartext-Passwörter, was bedeutet, dass ein kompromittierter Server nichts Lesbares offenlegt.
• Rollenbasierte Zugriffskontrolle — Granulare Berechtigungen auf Tresor-, Ordner- und Anmeldedaten-Ebene. Integration mit Active Directory, Azure AD, LDAP und SAML SSO für automatisierte Benutzerbereitstellung und Lifecycle-Management.
• Audit-Protokolle — Vollständige Aktivitätshistorie für jeden Anmeldedaten-Zugriff, jede Änderung und jedes Freigabeereignis. Unterstützt direkt die DSGVO-Rechenschaftspflicht und NIS2-Vorfallsdokumentation.
• AES-256-Verschlüsselung — Anmeldedaten im Ruhezustand und bei der Übertragung verschlüsselt. Schlüssel verbleiben innerhalb der Infrastruktur der Organisation.
• Compliance-Berichte — Integriertes Reporting für Sicherheitsaudits, Zugriffsüberprüfungen und regulatorische Dokumentation.
• Skaliert von 10 bis über 30.000 Benutzer — Dieselbe Architektur funktioniert für ein mittelständisches IT-Team und ein Großunternehmen mit komplexen Berechtigungsstrukturen.

Die Mehrheit der Passwork-Kunden wählt laut unternehmensinternen Daten die On-Premises-Bereitstellung. Dies gilt insbesondere für Großunternehmen, Regierungsstellen und Organisationen in stark regulierten Branchen.

Passwork Cloud: EU-gehostet, Zero-Knowledge

Passwork Cloud wird in Deutschland gehostet. Alle Daten bleiben innerhalb der EU-Rechtsordnung, verarbeitet und gespeichert unter EU-Recht.

Die Architektur verwendet clientseitige Verschlüsselung mit Zero-Knowledge-Design: Der Server sieht niemals Klartext-Anmeldedaten. Ver- und Entschlüsselung erfolgen auf der Client-Seite, sodass auch im Falle eines serverseitigen Vorfalls die Anmeldedaten geschützt bleiben.

Passwork Cloud enthält den vollständigen Enterprise-Funktionsumfang:

• Benutzerverwaltung, Active Directory / LDAP-Integration, SSO
• Audit-Protokolle und Compliance-Berichte
• Erweiterte MFA und Sicherheitsrichtlinien
• Browser-Erweiterungen, mobile Apps und REST API
• DevOps-Secrets-Management — CLI, Python-Bibliothek, Kubernetes-Integration, CI/CD-Pipeline-Unterstützung

Die Preise beginnen bei 3 € pro Benutzer pro Monat (Standardlizenz) und 4,50 € pro Benutzer pro Monat (Erweiterte Lizenz). Die langfristigen Betriebskosten liegen etwa 30 % unter dem Branchendurchschnitt.

Sicherheitsstatus

Passwork besitzt eine ISO 27001-Zertifizierung für Entwicklung, Infrastruktur und Betrieb. Das Unternehmen führt jährliche Penetrationstests durch Dritte durch, einschließlich über HackerOne, und wendet einen DevSecOps-Ansatz mit statischer und dynamischer Analyse an, die in jeden Build integriert ist.

Dieser Sicherheitsstatus ist direkt relevant für Organisationen, die die Sicherheitspraktiken ihres Passwort-Manager-Anbieters dokumentieren müssen — eine Anforderung sowohl nach NIS2 Artikel 21 als auch nach dem DORA-Rahmenwerk für Drittanbieter-Risikomanagement.

Entscheidungsrahmen: Das richtige Modell für Ihre Organisation wählen

Das richtige Hosting-Modell hängt von vier Variablen ab: regulatorische Exposition, Branchenklassifizierung, interne IT-Kapazität und Gesamtbetriebskosten. Die folgende Tabelle ordnet gängige Organisationsprofile empfohlenen Bereitstellungsmodellen zu.

TCO-Überlegungen

Die Gesamtbetriebskosten für jedes Modell umfassen mehr als Lizenz- oder Infrastrukturkosten. Compliance-Overhead ist ein realer Kostenfaktor: Die Zeit für Anbieter-Risikobewertungen, Audit-Dokumentation und Incident-Response-Planung variiert erheblich je nach Modell.

On-Premises-Bereitstellung konzentriert die Compliance-Arbeit intern — die Organisation kontrolliert die Umgebung und kann Audit-Nachweise direkt erbringen. Cloud-Bereitstellungen verlagern einen Teil der Compliance-Arbeit auf das Anbietermanagement: Überprüfung von Sicherheitszertifizierungen, Aushandeln von DPA-Bedingungen, Pflege eines DORA-Drittanbieterregister-Eintrags.

Für NIS2-regulierte Einrichtungen kann der Compliance-Overhead einer schlecht dokumentierten Cloud-Bereitstellung die Infrastrukturkosten einer On-Premises-Bereitstellung übersteigen. Diese Kalkulation lohnt sich, bevor man zur reibungsärmsten Option greift.

Fazit

Das Hosting-Modell für einen Passwort-Manager ist eine architektonische Entscheidung mit langfristigen Compliance-Auswirkungen. DSGVO, NIS2, DORA und der US CLOUD Act schaffen ein regulatorisches Umfeld, in dem die falsche Wahl dokumentierte Haftung erzeugt.

Das Modellspektrum gibt europäischen Organisationen echte Optionen. Die richtige Wahl hängt von der Branchenklassifizierung, der regulatorischen Exposition, der internen IT-Kapazität und einer ehrlichen TCO-Kalkulation ab, die den Compliance-Overhead einschließt.

Für Organisationen, die maximale Kontrolle benötigen, eliminiert die On-Premises-Bereitstellung die Drittanbieter-Exposition vollständig. Für diejenigen, die verwaltete Infrastruktur ohne Risiko ausländischer Rechtsordnung benötigen, ist souveräne EU-Cloud ein glaubwürdiger Weg. Hybride Architekturen funktionieren, wenn keines der Extreme zur operativen Realität passt.

Passwork ist ein europäischer Passwort-Manager, der das gesamte Spektrum abdeckt: On-Premises-Bereitstellung für Organisationen, die vollständige Infrastrukturkontrolle benötigen, und EU-gehostete Cloud für Teams, die verwaltetes Hosting ohne Verzicht auf Datensouveränität wünschen. Beide Optionen basieren auf derselben Zero-Knowledge-Verschlüsselungsarchitektur und beinhalten die Audit-, Zugriffskontroll- und Compliance-Reporting-Funktionen, die regulierte europäische Unternehmen benötigen.

Bereit für den ersten Schritt? Starten Sie Ihre kostenlose Passwork-Testversion, um vollständige Kontrolle, automatisiertes Anmeldedaten-Management und unternehmensweiten Datenschutz zu erhalten.

Häufig gestellte Fragen

Ist ein Cloud-Passwort-Manager DSGVO-konform?

Ein Cloud-Passwort-Manager kann DSGVO-konform sein, wenn der Anbieter personenbezogene Daten auf einer gültigen Rechtsgrundlage verarbeitet, einen Auftragsverarbeitungsvertrag (AVV) bereitstellt, der die Anforderungen von Artikel 28 erfüllt, und angemessene Schutzmaßnahmen für Datenübertragungen außerhalb der EU anwendet. Die Compliance hängt von der Architektur und den Vertragsbedingungen des Anbieters ab — nicht allein vom Cloud-Hosting.

Verlangt die DSGVO, dass Daten in Europa gespeichert werden?

Die DSGVO schreibt keine EU-Datenspeicherung vor. Sie verlangt, dass personenbezogene Daten, die außerhalb der EU übertragen werden, nach einem gleichwertigen Standard geschützt werden — durch Angemessenheitsbeschlüsse, Standardvertragsklauseln oder andere Mechanismen gemäß Artikeln 44–49. Die Speicherung von Daten in der EU vereinfacht die Compliance, ist aber keine rechtliche Anforderung der Verordnung selbst.

Was ist der US CLOUD Act und warum ist er für EU-Unternehmen relevant?

Der US CLOUD Act (2018) erlaubt US-Bundesbehörden, in den USA eingetragene Unternehmen zur Herausgabe von Daten zu zwingen, die überall auf der Welt gespeichert sind, einschließlich EU-Rechenzentren. Für europäische Organisationen, die US-basierte Passwort-Manager-Anbieter nutzen, bedeutet dies, dass Anmeldedaten dem Zugriff der US-Regierung unterliegen könnten, unabhängig davon, wo sich die Server physisch befinden.

Wann gilt NIS2 für Hosting-Entscheidungen bei Passwort-Managern?

NIS2 gilt, wenn die Organisation als „wesentliche" oder „wichtige" Einrichtung eingestuft ist — darunter Energie, Verkehr, Bankwesen, Gesundheitswesen, digitale Infrastruktur und öffentliche Verwaltung. Für diese Organisationen ist ein Passwort-Manager Teil der IKT-Lieferkette, und Artikel 21 verlangt dokumentierte Sicherheitsmaßnahmen für alle Lieferkettenkomponenten.

Was verlangt DORA für cloudbasierte Passwort-Manager in Finanzdienstleistungen?

DORA verlangt von Finanzunternehmen, ein Register der IKT-Drittanbieter zu führen, Risikobewertungen kritischer Anbieter durchzuführen und sicherzustellen, dass Verträge Audit-, Datenzugangs- und Austrittsrechte enthalten. Ein cloudbasierter Passwort-Manager, der von einem Finanzinstitut genutzt wird, ist ein IKT-Drittanbieter-Dienst nach DORA — das Institut muss diese Abhängigkeit formell dokumentieren und managen.

Was ist der Unterschied zwischen einer souveränen EU-Cloud und einem regulären EU-Rechenzentrum?

Ein reguläres EU-Rechenzentrum, das von einem US-Unternehmen betrieben wird, unterliegt weiterhin der US-Rechtsordnung durch den CLOUD Act. Ein souveräner Cloud-Anbieter ist vollständig innerhalb der EU eingetragen und wird dort betrieben, ohne rechtliche Verpflichtung, ausländischen Regierungsanfragen nach Daten nachzukommen. Die Unterscheidung ist relevant für DSGVO-Transfer-Risikobewertungen und NIS2-Lieferkettendokumentation.

Wie unterstützt Passwork die Compliance für europäische Organisationen?

Passwork ist ein europäisches Unternehmen unter EU-Recht, ISO 27001-zertifiziert, mit On-Premises- und EU-gehosteten Cloud-Bereitstellungsoptionen. Die On-Premises-Bereitstellung eliminiert den Drittanbieter-Zugriff vollständig. Die Cloud-Version wird in Deutschland unter EU-Rechtsordnung mit Zero-Knowledge-Verschlüsselung gehostet. Beide Optionen umfassen Audit-Protokolle, Compliance-Berichte und rollenbasierte Zugriffskontrolle zur Unterstützung der DSGVO-, NIS2- und DORA-Anforderungen.

Prävention von Datenschutzverletzungen für Unternehmen: Über einfachen Virenschutz hinaus

82 % der Angriffe im Jahr 2026 sind malware-frei — Virenschutz wird sie nicht erkennen. Dieser Leitfaden behandelt eine 7-Schichten-Verteidigungsstrategie, die für Anmeldedatendiebstahl, laterale Bewegung und Lieferkettenangriffe konzipiert ist.

Passwork BlogAlex Muntyan

Bereitstellungsmodelle für Passwort-Manager: Cloud, Self-Hosted & Hybrid

Die Wahl, wo Sie Ihren Passwort-Manager betreiben, ist genauso wichtig wie die Wahl, welchen Sie verwenden. Dieser Leitfaden erklärt Cloud-, Self-Hosted- und Hybrid-Bereitstellung — mit einer Compliance-Matrix für DSGVO, HIPAA und NIS2 und einem klaren Blick auf die Kompromisse jedes Modells.

Passwork BlogAlex Muntyan

Frühjahr 2026 EU-Cybersicherheits-Update: Was sich geändert hat

Das Frühjahr 2026 brachte den bedeutendsten institutionellen Sicherheitsvorfall der EU, ihre ersten Cybersanktionen des Jahres und vier wichtige Cybersicherheitsvorschriften, die gleichzeitig in Kraft treten. NIS2, DORA, CRA und CSA2 setzen nun harte Fristen — und echte Strafen. Hier erfahren Sie, was sich geändert hat, wer betroffen ist und was zu tun ist.

Passwork BlogAlex Muntyan

Introducción

Residencia de datos y soberanía de datos suenan casi como lo mismo. Pero no lo son.

Muchas organizaciones europeas eligen un proveedor estadounidense, seleccionan la opción de centro de datos en la UE y consideran resuelta la cuestión de la residencia de datos. Legalmente, no lo está. La ley CLOUD Act de EE. UU. otorga a las autoridades federales estadounidenses el poder de obligar a cualquier empresa constituida en EE. UU. a entregar datos almacenados en cualquier parte del mundo. Los datos están en Europa. La obligación legal no.

Esta es la tensión que enfrentan las empresas europeas al elegir cómo alojar un gestor de contraseñas. GDPR, NIS2, DORA y la CLOUD Act crean requisitos superpuestos que no se resuelven eligiendo el centro de datos más cercano. El modelo de alojamiento (quién posee la infraestructura, bajo qué jurisdicción, con qué nivel de control organizativo) es lo que realmente determina el panorama de cumplimiento.

Esta guía mapea los modelos de alojamiento disponibles para las organizaciones europeas, el marco regulatorio que configura cada uno y los criterios que deben guiar la decisión.

Puntos clave

• Elegir un centro de datos en la UE no resuelve la soberanía de datos. Si el proveedor está constituido en EE. UU., la CLOUD Act le obliga a entregar datos a las autoridades estadounidenses — independientemente de dónde se encuentren físicamente los servidores.
• Cuatro marcos regulatorios configuran la decisión de alojamiento. GDPR, NIS2, DORA y la CLOUD Act de EE. UU. crean obligaciones superpuestas que ninguna selección de centro de datos por sí sola puede satisfacer. El modelo de alojamiento es lo que determina la defensibilidad legal.
• El despliegue local es el único modelo que elimina el acceso de terceros por diseño. Elimina completamente la exposición a la CLOUD Act y otorga a la organización control total de la infraestructura, pero requiere capacidad interna de TI para operar y mantener.
• La nube soberana de la UE es un punto intermedio creíble. Se proyecta que el gasto europeo en IaaS de nube soberana alcanzará los 12.600 millones de dólares en 2026 — un aumento del 83% interanual (Gartner, 2026). El modelo ofrece infraestructura gestionada sin riesgo de jurisdicción extranjera.
• El modelo adecuado depende de cuatro variables. La clasificación del sector, la exposición regulatoria, la capacidad interna de TI y el coste total de propiedad determinan si el despliegue local, la nube soberana de la UE o la arquitectura híbrida es la opción defendible.

El espectro de alojamiento europeo

Las organizaciones europeas tienen cinco configuraciones de alojamiento distintas disponibles para un gestor de contraseñas. Dos quedan fuera de la consideración realista de cumplimiento para la mayoría de las empresas de la UE. Tres merecen una evaluación en profundidad.

Nube estadounidense con centro de datos en EE. UU. queda fuera del alcance de esta guía y, para la mayoría de las organizaciones europeas, fuera del alcance de la consideración realista. Cuando los servidores están ubicados en Estados Unidos y la empresa matriz está constituida en EE. UU., los datos residen físicamente fuera de la UE. Esa combinación activa las obligaciones de transferencia del GDPR según los Artículos 44–49 y crea exposición total a la CLOUD Act simultáneamente.

Nube estadounidense con centro de datos en la UE es un paso más cerca del cumplimiento — pero no una solución limpia. El proveedor del gestor de contraseñas opera servidores en una región de la UE (por ejemplo, Fráncfort, Dublín), por lo que los datos residen físicamente en Europa. Eso satisface los requisitos de residencia de datos del GDPR sobre el papel. Sin embargo, cuando la empresa matriz está constituida en EE. UU., la CLOUD Act de EE. UU. se aplica independientemente de dónde estén los servidores. Las autoridades estadounidenses pueden obligar legalmente al acceso a esos datos sin invocar los canales legales de la UE. El riesgo es menor que en el modelo anterior, pero la soberanía no está garantizada.

Los tres modelos que vale la pena evaluar:

• Nube soberana de la UE. El servicio se ejecuta en infraestructura propiedad de proveedores con sede en la UE y operada por ellos, fuera de la jurisdicción estadounidense u otra extranjera. Este modelo aborda los requisitos de residencia de datos del GDPR y elimina la exposición a la CLOUD Act.
• Despliegue local. El gestor de contraseñas se ejecuta completamente dentro de la propia infraestructura de la organización (servidores físicos, nube privada o entornos aislados). Ningún proveedor externo tiene acceso a los datos de credenciales. Este es el único modelo que proporciona control completo de la infraestructura.
• Arquitectura híbrida. Una combinación de bóvedas locales para credenciales sensibles y acceso basado en la nube para equipos distribuidos. Requiere un diseño cuidadoso de políticas para evitar crear brechas de cumplimiento entre los dos entornos.

La elección entre estos modelos es una cuestión de regulación y gestión de riesgos.

Cómo las regulaciones de la UE dictan el alojamiento de gestores de contraseñas

GDPR, NIS2, DORA y la CLOUD Act de EE. UU. imponen cada una obligaciones específicas que restringen directamente qué modelo de alojamiento puede elegir defensiblemente una organización europea. Comprender la interacción entre estos marcos es el punto de partida para cualquier decisión de despliegue.

GDPR y residencia de datos

El Reglamento General de Protección de Datos es el principal marco legal de la UE que rige la recopilación, almacenamiento y transferencia de datos personales. Se aplica a cualquier organización que procese datos personales de residentes de la UE, independientemente de dónde esté ubicada esa organización.

El GDPR no exige explícitamente que los datos se almacenen dentro de la UE. Lo que exige es que los datos personales transferidos fuera de la UE estén protegidos con un estándar equivalente — a través de Cláusulas Contractuales Tipo (CCT), decisiones de adecuación u otros mecanismos de transferencia según los Artículos 44–49. Para un gestor de contraseñas que almacena credenciales de empleados y metadatos asociados (nombres de usuario, URL, direcciones de correo electrónico), el GDPR se aplica directamente.

«Cualquier transferencia de datos personales que estén siendo objeto de tratamiento o que vayan a ser objeto de tratamiento después de la transferencia a un tercer país o a una organización internacional solo se efectuará si, a reserva de las demás disposiciones del presente Reglamento, el responsable y el encargado del tratamiento cumplen las condiciones establecidas en el presente capítulo.» — GDPR, Artículo 44 (Principio general de las transferencias)

El riesgo no es teórico. En agosto de 2024, la Autoridad de Protección de Datos de los Países Bajos multó a Uber con 290 millones de euros por transferir los datos personales de conductores de taxi europeos a servidores de EE. UU. sin aplicar ninguna de las salvaguardas requeridas según el Capítulo V del GDPR. Sin Cláusulas Contractuales Tipo, sin decisión de adecuación, sin mecanismo alternativo de transferencia. La violación abarcó más de dos años. El caso ilustra directamente cómo es la aplicación del Artículo 44 en la práctica: datos de empleados, infraestructura transfronteriza y una multa de nueve cifras.

NIS2 e infraestructura crítica

La Directiva NIS2 (Directiva de Seguridad de las Redes y de la Información 2) es la principal legislación de ciberseguridad de la UE, que sustituye a la Directiva NIS original de 2016. Establece requisitos de seguridad vinculantes para las organizaciones que operan en sectores críticos en los Estados miembros de la UE, con un enfoque en la gestión de riesgos, la notificación de incidentes y la seguridad de la cadena de suministro.

NIS2 amplía significativamente el alcance de las organizaciones clasificadas como entidades «esenciales» o «importantes». Sectores que incluyen energía, transporte, banca, sanidad, infraestructura digital y administración pública ahora deben tratar a sus proveedores de tecnología como parte de su perímetro de seguridad, no solo su infraestructura interna.

Un gestor de contraseñas que almacena credenciales en un entorno de nube de terceros entra dentro de ese perímetro. Es un proveedor directo de un servicio crítico para la seguridad. El Artículo 21(2) de NIS2 requiere que las entidades cubiertas implementen medidas que incluyan al menos:

«Seguridad de la cadena de suministro, incluidos los aspectos relacionados con la seguridad relativos a las relaciones entre cada entidad y sus proveedores o prestadores de servicios directos.» — Directiva NIS2, Artículo 21(2), Directiva (UE) 2022/2555

Elegir un proveedor de nube con sede en EE. UU. para el almacenamiento de credenciales sin una evaluación de riesgos documentada crea una brecha de cumplimiento concreta. Según NIS2, las autoridades de supervisión nacionales pueden emitir instrucciones vinculantes e imponer multas. Para las entidades esenciales, el Artículo 20 también establece responsabilidad personal para los miembros del órgano de dirección.

DORA y especificidades del sector financiero

El Reglamento de Resiliencia Operativa Digital (DORA) es el marco regulatorio de la UE para la resiliencia operativa digital en el sector financiero. Establece requisitos sobre cómo las entidades financieras gestionan los riesgos de tecnologías de la información y la comunicación (TIC), cubriendo dependencias de terceros, notificación de incidentes y pruebas de resiliencia, para garantizar la estabilidad de los servicios financieros en toda la UE.

Un gestor de contraseñas alojado en la nube califica como un servicio TIC de terceros según DORA. Esa clasificación activa obligaciones contractuales específicas — incluyendo el requisito de documentar dónde se almacenan y procesan los datos. El Artículo 30(2)(b) del Reglamento (UE) 2022/2554 establece:

«Las ubicaciones, es decir, las regiones o países, donde se prestarán las funciones contratadas o subcontratadas y los servicios de TIC y donde se procesarán los datos, incluida la ubicación de almacenamiento, y el requisito de que el proveedor tercero de servicios de TIC notifique a la entidad financiera con antelación si prevé modificar dichas ubicaciones.» — DORA, Artículo 30(2)(b), Reglamento (UE) 2022/2554

Si el proveedor del gestor de contraseñas tiene sede en EE. UU., la institución financiera debe documentar cómo gestiona la exposición a la CLOUD Act y garantizar que el contrato cumpla con los requisitos de DORA sobre acceso a datos, portabilidad y terminación.

La CLOUD Act de EE. UU.

La Ley de Clarificación del Uso Legal de Datos en el Extranjero (CLOUD Act, 2018) es una ley federal de EE. UU. que permite a las agencias de aplicación de la ley obligar a las empresas constituidas en EE. UU. a entregar datos almacenados en cualquier parte del mundo, incluidos servidores ubicados en centros de datos de la UE. La obligación se aplica independientemente de dónde residan físicamente los datos. El factor determinante es la jurisdicción corporativa del proveedor.

El estatuto es inequívoco en este punto:

«Un proveedor de servicio de comunicación electrónica o servicio de computación remota deberá cumplir con las obligaciones de este capítulo de preservar, respaldar o divulgar el contenido de una comunicación electrónica o por cable y cualquier registro u otra información perteneciente a un cliente o suscriptor dentro de la posesión, custodia o control de dicho proveedor, independientemente de si dicha comunicación, registro o información se encuentra dentro o fuera de los Estados Unidos.» — 18 U.S.C. § 2713, Pub. L. 115–141, div. V, §103(a)(1), 23 de marzo de 2018

La empresa puede impugnar la orden, pero la obligación legal existe independientemente de dónde estén ubicados los servidores.

Para las organizaciones europeas que manejan credenciales sensibles (acceso privilegiado, contraseñas de sistemas financieros, claves de infraestructura) esto crea un riesgo estructural que los centros de datos en la región de la UE por sí solos no resuelven. La nube soberana o el despliegue local son los únicos modelos que eliminan esta exposición por completo.

Passwork es un gestor de contraseñas europeo creado exactamente para este entorno regulatorio, con opciones tanto locales como en la nube diseñadas en torno al cumplimiento de GDPR y NIS2 y la soberanía de datos. Vea cómo funciona

Gestores de contraseñas en la nube en Europa: Conveniencia vs control

Alojamiento en la nube significa que los servidores del proveedor almacenan y procesan sus datos — la organización accede al servicio a través de internet sin gestionar ninguna infraestructura subyacente. Para los gestores de contraseñas, esto significa que las credenciales, los metadatos y los registros de acceso residen en servidores propiedad de un tercero y operados por él, en centros de datos que la organización no controla.

Los gestores de contraseñas alojados en la nube ofrecen despliegue rápido, actualizaciones automáticas y sin sobrecarga de infraestructura. Para muchas organizaciones europeas, son la opción predeterminada — el 53% de las empresas de la UE utilizaron servicios de computación en la nube de pago en 2025, 7,4 puntos porcentuales más que en 2023 (Eurostat, 2026).

El atractivo es sencillo: no hay servidores que mantener, el proveedor se encarga de los parches y el acceso funciona desde cualquier dispositivo. Para las PYMES sin equipos de seguridad dedicados, esto reduce la barrera para implementar una gestión adecuada de credenciales.

Dónde la nube se queda corta para las organizaciones de la UE

El modelo de responsabilidad compartida es el problema central. En un despliegue en la nube, el proveedor controla la infraestructura, la arquitectura de gestión de claves de cifrado y los sistemas de respaldo. La organización controla el acceso de usuarios y las políticas, pero no el entorno de datos subyacente.

La arquitectura de conocimiento cero aborda parcialmente esto: si el proveedor nunca posee las claves de descifrado, una brecha del lado del servidor no puede exponer credenciales en texto plano. La multa del ICO contra LastPass ilustra los límites — la brecha expuso metadatos (nombres, correos electrónicos, URL) aunque el contenido cifrado de las bóvedas estaba protegido. Los metadatos son datos personales según el GDPR.

El cifrado AES-256 en reposo es un requisito básico, no un diferenciador. Lo que importa es dónde se generan y almacenan las claves, quién puede acceder a ellas y si la arquitectura del proveedor mantiene esas claves fuera de su propio alcance.

Gestores de contraseñas locales: Máxima soberanía

El despliegue local significa que el gestor de contraseñas se ejecuta en servidores que la organización posee y opera — ningún proveedor tiene acceso de red al almacén de credenciales. Todas las credenciales, metadatos y registros de acceso permanecen dentro del propio perímetro de infraestructura de la organización.

Este es el único modelo de alojamiento que satisface completamente los requisitos de soberanía de datos y elimina la exposición a terceros por diseño.

Para organizaciones en sectores regulados (instituciones financieras, proveedores de atención sanitaria, operadores de infraestructura crítica según NIS2) el despliegue local elimina toda una categoría de riesgo de terceros de la ecuación de cumplimiento.

Dónde el despliegue local es la única opción viable

Los entornos aislados representan la variante más segura: el gestor de contraseñas opera en una red sin conectividad a internet. Esto es relevante para sistemas de control industrial, entornos clasificados o cualquier contexto donde el almacén de credenciales deba estar físicamente aislado de redes externas.

Como se cubrió anteriormente, el despliegue local con un proveedor no estadounidense es el único modelo que elimina completamente la exposición a la CLOUD Act al eliminar la jurisdicción corporativa estadounidense que activa la obligación en primer lugar.

Despliegue local: Ventajas y desventajas

El cálculo del TCO desplaza los costes de las tarifas SaaS recurrentes al trabajo de TI interno y la infraestructura. Para organizaciones que ya operan sus propios servidores y tienen un equipo de seguridad en su lugar, el coste marginal de añadir un gestor de contraseñas autoalojado es a menudo menor de lo que parece.

El coste real del despliegue local es la disciplina operativa necesaria para mantenerlo. Las empresas que carecen de un equipo de seguridad dedicado o un proceso maduro de gestión de parches encontrarán la columna de limitaciones más difícil de gestionar de lo que sugiere la columna de ventajas.

Passwork está disponible como una solución completamente autoalojada: desplegada en los propios servidores de la organización, sin conexiones salientes. El código fuente está disponible para auditoría, y la plataforma soporta entornos aislados. Para equipos que necesitan demostrar soberanía total de datos a auditores o reguladores, este es el modelo de despliegue que cierra el argumento.

Passwork local otorga a su equipo control total de la infraestructura — sin acceso de terceros, sin excepciones. Explore el despliegue local

El punto intermedio de la nube soberana

Los proveedores de nube soberana de la UE ofrecen una tercera vía: infraestructura gestionada con la comodidad del estilo de la nube, operada completamente dentro de la jurisdicción de la UE y fuera del alcance de los marcos legales extranjeros. Se proyecta que el gasto europeo en IaaS de nube soberana alcanzará los 12.600 millones de dólares en 2026, un aumento del 83% respecto a 2025 (Gartner, 2026).

El crecimiento está impulsado por la presión geopolítica. La CLOUD Act de EE. UU., combinada con incidentes de alto perfil que involucran dependencia de hiperescaladores, ha llevado a las organizaciones europeas a reconsiderar sus elecciones de proveedores de nube.

Para un gestor de contraseñas desplegado en infraestructura de nube soberana, el entorno de alojamiento proporciona evidencia documentada de que los datos permanecen dentro de la jurisdicción de la UE — directamente relevante para la documentación de cumplimiento de NIS2 y las evaluaciones de riesgo de terceros de DORA.

La nube soberana aborda la jurisdicción y el control de la infraestructura. No reemplaza la necesidad de evaluar la propia aplicación del gestor de contraseñas. La capa de alojamiento y la capa de aplicación son cuestiones de seguridad separadas.

Arquitectura híbrida

Una arquitectura híbrida combina bóvedas locales para credenciales sensibles con acceso basado en la nube para equipos distribuidos. Es una decisión de política e ingeniería que requiere límites explícitos entre lo que permanece local y lo que pasa por infraestructura externa.

El atractivo es práctico. Las organizaciones con equipos remotos o distribuidos internacionalmente no siempre pueden enrutar cada solicitud de autenticación a través de un sistema local sin introducir latencia o riesgos de disponibilidad. Una configuración híbrida permite a los equipos de seguridad mantener las clases de credenciales más sensibles (cuentas privilegiadas, secretos de infraestructura, credenciales sensibles para el cumplimiento) en una bóveda controlada localmente, mientras extienden el acceso a recursos menos sensibles a través de una capa en la nube.

La complejidad del cumplimiento, sin embargo, escala con la arquitectura. Cada límite entre los componentes locales y en la nube es una brecha potencial: en cobertura de auditoría, en aplicación de políticas de acceso, en alcance de respuesta a incidentes. Si la capa en la nube cae bajo una jurisdicción extranjera, las protecciones de soberanía del componente local no se extienden automáticamente a ella.

La arquitectura híbrida es el modelo más flexible en este espectro — y el más exigente de operar correctamente. Para organizaciones con la capacidad de ingeniería para gestionarlo, ofrece un equilibrio viable entre control y accesibilidad. Para aquellas sin ella, el despliegue local o la nube soberana de la UE es la opción más defendible.

Passwork para empresas europeas: Construido para la soberanía desde el principio

Passwork es un gestor de contraseñas europeo — constituido y operado como empresa europea, con su base legal en España bajo la legislación de la UE. Fue construido primero para despliegue local, para organizaciones que necesitan control total de la infraestructura, y desde entonces ha añadido una opción en la nube alojada completamente dentro de la UE.

Esto importa para las empresas europeas porque la propia jurisdicción del proveedor es parte del panorama de cumplimiento. Una empresa europea que opera bajo la legislación de la UE no tiene exposición a la CLOUD Act de EE. UU. La arquitectura y las opciones de despliegue de Passwork fueron diseñadas teniendo en cuenta este contexto regulatorio.

Despliegue local

Passwork local se ejecuta completamente dentro de la propia infraestructura de la organización. El proveedor no tiene acceso al almacén de credenciales — sin acceso remoto, sin telemetría y sin puerta trasera. Todos los datos, claves de cifrado y copias de seguridad permanecen dentro de los sistemas de la organización.

Capacidades clave para entornos regulados:

• Control total de la infraestructura — despliegue en sus propios servidores, nube privada o redes aisladas. Soporta entornos sin conectividad a internet.
• Arquitectura de conocimiento cero — las credenciales se cifran y descifran en el lado del cliente. El servidor almacena solo texto cifrado y nunca procesa contraseñas en texto plano, lo que significa que un servidor comprometido no expone nada legible.
• Control de acceso basado en roles — permisos granulares a nivel de bóveda, carpeta y credencial. Se integra con Active Directory, Azure AD, LDAP y SSO SAML para el aprovisionamiento automatizado de usuarios y la gestión del ciclo de vida.
• Registros de auditoría — historial completo de actividad para cada acceso, modificación y evento de compartición de credenciales. Soporta directamente los requisitos de responsabilidad del GDPR y la documentación de incidentes de NIS2.
• Cifrado AES-256 — credenciales cifradas en reposo y en tránsito. Las claves permanecen dentro de la infraestructura de la organización.
• Informes de cumplimiento — informes integrados para auditorías de seguridad, revisiones de acceso y documentación regulatoria.
• Escala de 10 a más de 30.000 usuarios — la misma arquitectura funciona para un equipo de TI de mercado medio y una gran empresa con estructuras de permisos complejas.

La mayoría de los clientes de Passwork eligen el despliegue local, según los datos internos de la empresa. Esto es especialmente cierto para grandes empresas, organismos gubernamentales y organizaciones en industrias altamente reguladas.

Passwork Cloud: Alojado en la UE, conocimiento cero

Passwork Cloud está alojado en Alemania. Todos los datos permanecen dentro de la jurisdicción de la UE, procesados y almacenados bajo la legislación de la UE.

La arquitectura utiliza cifrado del lado del cliente con diseño de conocimiento cero: el servidor nunca ve credenciales en texto plano. El cifrado y descifrado ocurren en el lado del cliente, por lo que incluso en caso de un incidente del lado del servidor, los datos de credenciales permanecen protegidos.

Passwork Cloud incluye el conjunto completo de funciones empresariales:

• Gestión de usuarios, integración con Active Directory / LDAP, SSO
• Registros de auditoría e informes de cumplimiento
• MFA avanzado y políticas de seguridad
• Extensiones de navegador, aplicaciones móviles y REST API
• Gestión de secretos DevOps — CLI, biblioteca Python, integración con Kubernetes, soporte de pipelines CI/CD

Los precios comienzan en 3 € por usuario al mes (licencia estándar) y 4,50 € por usuario al mes (licencia avanzada). Los costes de propiedad a largo plazo son aproximadamente un 30% inferiores al promedio de la industria.

Postura de seguridad

Passwork posee certificación ISO 27001 en desarrollo, infraestructura y operaciones. La empresa realiza pruebas de penetración anuales por terceros, incluso a través de HackerOne, y aplica un enfoque DevSecOps con análisis estático y dinámico integrado en cada compilación.

Esta postura de seguridad es directamente relevante para las organizaciones que necesitan documentar las prácticas de seguridad de su proveedor de gestor de contraseñas — un requisito tanto del Artículo 21 de NIS2 como del marco de gestión de riesgos de terceros de DORA.

Marco de decisión: Eligiendo el modelo adecuado para su organización

El modelo de alojamiento adecuado depende de cuatro variables: exposición regulatoria, clasificación del sector, capacidad interna de TI y coste total de propiedad. La tabla siguiente mapea perfiles organizativos comunes a modelos de despliegue recomendados.

Consideraciones de TCO

El coste total de propiedad para cada modelo incluye más que costes de licencia o infraestructura. La sobrecarga de cumplimiento es una partida real: el tiempo dedicado a evaluaciones de riesgo de proveedores, documentación de auditoría y planificación de respuesta a incidentes varía significativamente según el modelo.

El despliegue local concentra el trabajo de cumplimiento internamente — la organización controla el entorno y puede producir evidencia de auditoría directamente. Los despliegues en la nube desplazan parte del trabajo de cumplimiento a la gestión de proveedores: revisar certificaciones de seguridad, negociar términos de DPA, mantener una entrada en el registro de terceros de DORA.

Para las entidades reguladas por NIS2, la sobrecarga de cumplimiento de un despliegue en la nube mal documentado puede superar el coste de infraestructura del despliegue local. Vale la pena hacer ese cálculo antes de optar por defecto por la opción de menor fricción.

Conclusión

El modelo de alojamiento para un gestor de contraseñas es una decisión arquitectónica con implicaciones de cumplimiento a largo plazo. GDPR, NIS2, DORA y la CLOUD Act de EE. UU. crean un entorno regulatorio donde la elección incorrecta genera responsabilidad documentada.

El espectro de modelos ofrece a las organizaciones europeas opciones reales. La elección correcta depende de la clasificación del sector, la exposición regulatoria, la capacidad interna de TI y un cálculo honesto del TCO que incluya la sobrecarga de cumplimiento.

Para organizaciones que necesitan máximo control, el despliegue local elimina completamente la exposición a terceros. Para aquellas que necesitan infraestructura gestionada sin riesgo de jurisdicción extranjera, la nube soberana de la UE es un camino creíble. Las arquitecturas híbridas funcionan cuando ningún extremo se ajusta a la realidad operativa.

Passwork es un gestor de contraseñas europeo que cubre todo el espectro: despliegue local para organizaciones que requieren control completo de la infraestructura, y nube alojada en la UE para equipos que desean alojamiento gestionado sin sacrificar la soberanía de datos. Ambas opciones están construidas sobre la misma arquitectura de cifrado de conocimiento cero e incluyen las funciones de auditoría, control de acceso e informes de cumplimiento que necesitan las empresas europeas reguladas.

¿Listo para dar el primer paso? Inicie su prueba gratuita de Passwork para obtener control completo, gestión automatizada de credenciales y protección de datos de nivel empresarial.

Preguntas frecuentes

¿Es un gestor de contraseñas en la nube compatible con el GDPR?

Un gestor de contraseñas en la nube puede ser compatible con el GDPR si el proveedor procesa datos personales bajo una base legal válida, proporciona un Acuerdo de Procesamiento de Datos (DPA) que cumpla con los requisitos del Artículo 28, y aplica salvaguardas apropiadas para cualquier transferencia de datos fuera de la UE. El cumplimiento depende de la arquitectura y los términos contractuales del proveedor — no solo del alojamiento en la nube.

¿Exige el GDPR que los datos se almacenen en Europa?

El GDPR no obliga al almacenamiento de datos en la UE. Exige que los datos personales transferidos fuera de la UE estén protegidos con un estándar equivalente — a través de decisiones de adecuación, Cláusulas Contractuales Tipo u otros mecanismos según los Artículos 44–49. Almacenar datos en la UE simplifica el cumplimiento pero no es un requisito legal según el propio reglamento.

¿Qué es la CLOUD Act de EE. UU. y por qué importa a las empresas de la UE?

La CLOUD Act de EE. UU. (2018) permite a las autoridades federales estadounidenses obligar a las empresas constituidas en EE. UU. a entregar datos almacenados en cualquier parte del mundo, incluidos centros de datos de la UE. Para las organizaciones europeas que utilizan proveedores de gestores de contraseñas con sede en EE. UU., esto significa que los datos de credenciales podrían estar sujetos al acceso del gobierno estadounidense independientemente de dónde estén ubicados físicamente los servidores.

¿Cuándo se aplica NIS2 a las decisiones de alojamiento de gestores de contraseñas?

NIS2 se aplica cuando la organización está clasificada como entidad «esencial» o «importante» — cubriendo energía, transporte, banca, sanidad, infraestructura digital y administración pública, entre otros. Para estas organizaciones, un gestor de contraseñas es parte de la cadena de suministro TIC, y el Artículo 21 requiere medidas de seguridad documentadas para todos los componentes de la cadena de suministro.

¿Qué exige DORA para los gestores de contraseñas alojados en la nube en servicios financieros?

DORA exige que las entidades financieras mantengan un registro de proveedores de servicios TIC de terceros, realicen evaluaciones de riesgo de proveedores críticos y garanticen que los contratos incluyan derechos de auditoría, acceso a datos y salida. Un gestor de contraseñas alojado en la nube utilizado por una institución financiera es un servicio TIC de terceros según DORA — la institución debe documentar y gestionar esta dependencia formalmente.

¿Cuál es la diferencia entre una nube soberana de la UE y un centro de datos regular de la UE?

Un centro de datos regular de la UE operado por una empresa estadounidense sigue estando sujeto a la jurisdicción de EE. UU. a través de la CLOUD Act. Un proveedor de nube soberana está constituido y opera completamente dentro de la UE, sin obligación legal de cumplir con solicitudes de datos de gobiernos extranjeros. La distinción importa para las evaluaciones de riesgo de transferencia del GDPR y la documentación de la cadena de suministro de NIS2.

¿Cómo apoya Passwork el cumplimiento para las organizaciones europeas?

Passwork es una empresa europea bajo la legislación de la UE, con certificación ISO 27001, y opciones de despliegue local y en la nube alojada en la UE. El despliegue local elimina completamente el acceso de terceros. La versión en la nube está alojada en Alemania bajo jurisdicción de la UE con cifrado de conocimiento cero. Ambas opciones incluyen registros de auditoría, informes de cumplimiento y control de acceso basado en roles para apoyar los requisitos de GDPR, NIS2 y DORA.

Prevención de brechas de datos para empresas: Más allá del antivirus básico

El 82% de los ataques en 2026 no usan malware — el antivirus no los detectará. Esta guía cubre una estrategia de defensa de 7 capas diseñada para el robo de credenciales, el movimiento lateral y el compromiso de la cadena de suministro.

Passwork BlogAlex Muntyan

Modelos de despliegue de gestores de contraseñas: Nube, autoalojado e híbrido

Elegir dónde ejecutar su gestor de contraseñas importa tanto como elegir cuál. Esta guía desglosa el despliegue en la nube, autoalojado e híbrido — con una matriz de cumplimiento para GDPR, HIPAA y NIS2, y una visión clara de las compensaciones que conlleva cada modelo.

Passwork BlogAlex Muntyan

Actualización de ciberseguridad de la UE primavera 2026: Qué cambió

La primavera de 2026 trajo la brecha institucional más significativa de la UE, sus primeras sanciones cibernéticas del año y cuatro importantes regulaciones de ciberseguridad aplicándose simultáneamente. NIS2, DORA, CRA y CSA2 ahora establecen plazos firmes — y sanciones reales. Esto es lo que cambió, quién está afectado y qué hacer.

Passwork BlogAlex Muntyan

Introduction

Data residency and data sovereignty sound almost like the same thing. But they aren't.

Many European organizations choose a US-based vendor, select the EU data center option, and consider the data residency question resolved. Legally, it isn't. The US CLOUD Act gives American federal authorities the power to compel any US-incorporated company to produce data stored anywhere in the world. The data is in Europe. The legal obligation is not.

This is the tension European businesses run into when choosing how to host a password manager. GDPR, NIS2, DORA, and the CLOUD Act create overlapping requirements that don't resolve by picking the nearest data center. The hosting model (who owns the infrastructure, under which jurisdiction, with what level of organizational control) is what actually determines the compliance picture.

This guide maps the hosting models available to European organizations, the regulatory framework that shapes each one, and the criteria that should drive the decision.

Key takeaways

• Choosing an EU data center does not resolve data sovereignty. If the vendor is US-incorporated, the CLOUD Act compels them to produce data for American authorities — regardless of where the servers physically sit.
• Four regulatory frameworks shape the hosting decision. GDPR, NIS2, DORA, and the US CLOUD Act create overlapping obligations that no data center selection alone can satisfy. The hosting model is what determines legal defensibility.
• On-premises is the only model that eliminates third-party access by design. It removes CLOUD Act exposure entirely and gives the organization full infrastructure control, but requires internal IT capacity to operate and maintain.
• Sovereign EU cloud is a credible middle ground. European spending on sovereign cloud IaaS is projected to reach $12.6 billion in 2026 — an 83% increase year-over-year (Gartner, 2026). The model delivers managed infrastructure without foreign jurisdiction risk.
• The right model depends on four variables. Sector classification, regulatory exposure, internal IT capacity, and total cost of ownership determine whether on-premises, sovereign EU cloud, or hybrid architecture is the defensible choice.

The European hosting spectrum

European organizations have five distinct hosting configurations available for a password manager. Two fall outside realistic compliance consideration for most EU businesses. Three are worth evaluating in depth.

US cloud with US data center sits outside the scope of this guide and, for most European organizations, outside the scope of realistic consideration. When servers are located in the United States and the parent company is US-incorporated, data physically resides outside the EU. That combination triggers GDPR transfer obligations under Articles 44–49 and creates full CLOUD Act exposure simultaneously.

US cloud with EU data center is a step closer to compliance — but not a clean solution. The password manager vendor operates servers in an EU region (e.g., Frankfurt, Dublin), so data physically resides in Europe. That satisfies GDPR data residency requirements on paper. However, when the parent company is US-incorporated, the US CLOUD Act applies regardless of where the servers sit. American authorities can legally compel access to that data without invoking EU legal channels. The risk is lower than the previous model, but sovereignty is not guaranteed

The three models worth evaluating:

• Sovereign EU cloud. The service runs on infrastructure owned and operated by EU-based providers, outside US or other foreign jurisdiction. This model addresses GDPR data residency requirements and eliminates CLOUD Act exposure.
• On-premises deployment. The password manager runs entirely within the organization's own infrastructure (physical servers, private cloud, or air-gapped environments). No third-party vendor has access to credential data. This is the only model that gives complete infrastructure control.
• Hybrid architecture. A combination of on-premises vaults for sensitive credentials and cloud-based access for distributed teams. Requires careful policy design to avoid creating compliance gaps between the two environments.

The choice between these models is a regulatory and risk management question.

How EU regulations dictate password manager hosting

GDPR, NIS2, DORA, and the US CLOUD Act each impose specific obligations that directly constrain which hosting model a European organization can defensibly choose. Understanding the interaction between these frameworks is the starting point for any deployment decision.

GDPR and data residency

The General Data Protection Regulation is the EU's primary legal framework governing the collection, storage, and transfer of personal data. It applies to any organization processing the personal data of EU residents, regardless of where that organization is based.

GDPR does not explicitly require data to be stored within the EU. What it requires is that personal data transferred outside the EU is protected to an equivalent standard — through Standard Contractual Clauses (SCCs), adequacy decisions, or other transfer mechanisms under Articles 44–49. For a password manager storing employee credentials and associated metadata (usernames, URLs, email addresses), GDPR applies directly.

"Any transfer of personal data which are undergoing processing or are intended for processing after transfer to a third country or to an international organisation shall take place only if, subject to the other provisions of this Regulation, the conditions laid down in this Chapter are complied with by the controller and processor." — GDPR, Article 44 (General principle for transfers)

The risk is not theoretical. In August 2024, the Dutch Data Protection Authority fined Uber €290 million for transferring the personal data of European taxi drivers to US servers without applying any of the safeguards required under GDPR Chapter V. No Standard Contractual Clauses, no adequacy decision, no alternative transfer mechanism. The violation spanned more than two years. The case directly illustrates what Article 44 enforcement looks like in practice: employee data, cross-border infrastructure, and a nine-figure penalty.

NIS2 and critical infrastructure

The NIS2 Directive (Network and Information Security Directive 2) is the EU's primary cybersecurity legislation, replacing the original NIS Directive from 2016. It establishes binding security requirements for organizations operating in critical sectors across EU member states, with a focus on risk management, incident reporting, and supply chain security.

NIS2 significantly expands the scope of organizations classified as "essential" or "important" entities. Sectors including energy, transport, banking, healthcare, digital infrastructure, and public administration must now treat their technology vendors as part of their security perimeter, not just their internal infrastructure.

A password manager storing credentials in a third-party cloud environment falls within that perimeter. It is a direct supplier of a security-critical service. NIS2 Article 21(2) requires covered entities to implement measures that include at least:

"Supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers." — NIS2 Directive, Article 21(2), Directive (EU) 2022/2555

Choosing a US-based cloud provider for credential storage without a documented risk assessment creates a concrete compliance gap. Under NIS2, national supervisory authorities can issue binding instructions and impose fines. For essential entities, Article 20 also establishes personal liability for members of the management body.

DORA and financial sector specifics

The Digital Operational Resilience Act (DORA) is the EU's regulatory framework for digital operational resilience in the financial sector. It sets requirements for how financial entities manage information and communication technology (ICT) risks, covering third-party dependencies, incident reporting, and resilience testing, to ensure the stability of financial services across the EU.

A cloud-hosted password manager qualifies as an ICT third-party service under DORA. That classification triggers specific contractual obligations — including a requirement to document where data is stored and processed. Article 30(2)(b) of Regulation (EU) 2022/2554 states:

"The locations, namely the regions or countries, where the contracted or subcontracted functions and ICT services are to be provided and where data is to be processed, including the storage location, and the requirement for the ICT third-party service provider to notify the financial entity in advance if it envisages changing such locations" — DORA, Article 30(2)(b), Regulation (EU) 2022/2554

If the password manager provider is US-based, the financial institution must document how it manages CLOUD Act exposure and ensure the contract meets DORA's requirements for data access, portability, and termination.

The US CLOUD Act

The Clarifying Lawful Overseas Use of Data Act (CLOUD Act, 2018) is a US federal law that allows law enforcement agencies to compel US-incorporated companies to produce data stored anywhere in the world, including servers located in EU data centers. The obligation applies regardless of where the data physically resides. The determining factor is the corporate jurisdiction of the provider.

The statute is unambiguous on this point:

"A provider of electronic communication service or remote computing service shall comply with the obligations of this chapter to preserve, backup, or disclose the contents of a wire or electronic communication and any record or other information pertaining to a customer or subscriber within such provider's possession, custody, or control, regardless of whether such communication, record, or other information is located within or outside of the United States." — 18 U.S.C. § 2713, Pub. L. 115–141, div. V, §103(a)(1), March 23, 2018

The company can challenge the order, but the legal obligation exists regardless of where the servers are located.

For European organizations handling sensitive credentials (privileged access, financial system passwords, infrastructure keys) this creates a structural risk that EU-region data centers alone do not resolve. Sovereign cloud or on-premises deployment are the only models that eliminate this exposure entirely.

Passwork is a European password manager built for exactly this regulatory environment with both on-premises and cloud options designed around GDPR and NIS2 compliance and data sovereignty. See how it works

Cloud password managers in Europe: Convenience vs control

Cloud hosting means the vendor's servers store and process your data — the organization accesses the service over the internet without managing any underlying infrastructure. For password managers, this means credentials, metadata, and access logs reside on servers owned and operated by a third party, in data centers the organization does not control.

Cloud-hosted password managers offer fast deployment, automatic updates, and no infrastructure overhead. For many European organizations, they are the default choice — 53% of EU enterprises used paid cloud computing services in 2025, up 7.4 percentage points from 2023 (Eurostat, 2026).

The appeal is straightforward: no servers to maintain, the vendor handles patching, and access works from any device. For SMBs without dedicated security teams, this lowers the barrier to deploying proper credential management.

Where cloud falls short for EU organizations

The shared responsibility model is the central issue. In a cloud deployment, the vendor controls the infrastructure, the encryption key management architecture, and the backup systems. The organization controls user access and policies but not the underlying data environment.

Zero-knowledge architecture partially addresses this: if the vendor never holds the decryption keys, a server-side breach cannot expose plaintext credentials. The ICO fine against LastPass illustrates the limits — the breach exposed metadata (names, emails, URLs) even though encrypted vault contents were protected. Metadata is personal data under GDPR.

AES-256 encryption at rest is a baseline requirement, not a differentiator. What matters is where keys are generated, stored, and who can access them and whether the vendor's architecture keeps those keys outside their own reach.

On-premises password managers: Maximum sovereignty

On-premises deployment means the password manager runs on servers the organization owns and operates — no vendor has network access to the credential store. All credentials, metadata, and access logs remain within the organization's own infrastructure perimeter.

This is the only hosting model that fully satisfies data sovereignty requirements and eliminates third-party exposure by design.

For organizations in regulated sectors (financial institutions, healthcare providers, critical infrastructure operators under NIS2) on-premises deployment removes an entire category of third-party risk from the compliance equation.

Where on-premises is the only viable option

Air-gapped environments represent the most secure variant: the password manager operates on a network with no internet connectivity. This is relevant for industrial control systems, classified environments, or any context where the credential store must be physically isolated from external networks.

As covered above, on-premises deployment with a non-US vendor is the only model that eliminates CLOUD Act exposure entirely by removing the US corporate jurisdiction that triggers the obligation in the first place.

On-premises deployment: Pros and cons

The TCO calculation shifts costs from recurring SaaS fees to internal IT labor and infrastructure. For organizations that already operate their own servers and have a security team in place, the marginal cost of adding a self-hosted password manager is often lower than it appears.

The real cost of on-premises is the operational discipline required to maintain it. Businesses that lack a dedicated security team or a mature patch management process will find the limitations column harder to manage than the advantages column suggests.

Passwork is available as a fully self-hosted solution: deployed on the organization's own servers, with no outbound connections. The source code is available for audit, and the platform supports air-gapped environments. For teams that need to demonstrate full data sovereignty to auditors or regulators, this is the deployment model that closes the argument.

Passwork on-premises gives your team full infrastructure control — no third-party access, no exceptions. Explore on-premises deployment

The sovereign cloud middle ground

Sovereign EU cloud providers offer a third path: managed infrastructure with cloud-style convenience, operated entirely within EU jurisdiction and outside the reach of foreign legal frameworks. European spending on sovereign cloud IaaS is projected to reach $12.6 billion in 2026, an 83% increase from 2025 (Gartner, 2026).

The growth is driven by geopolitical pressure. The US CLOUD Act, combined with high-profile incidents involving hyperscaler dependency, has pushed European organizations to reconsider their cloud vendor choices.

For a password manager deployed on sovereign cloud infrastructure, the hosting environment provides documented evidence that data stays within EU jurisdiction — directly relevant for NIS2 compliance documentation and DORA third-party risk assessments.

Sovereign cloud addresses jurisdiction and infrastructure control. It does not replace the need to evaluate the password manager application itself. The hosting layer and the application layer are separate security questions.

Hybrid architecture

A hybrid architecture combines on-premises vaults for sensitive credentials with cloud-based access for distributed teams. It is a policy and engineering decision that requires explicit boundaries between what stays local and what moves through external infrastructure.

The appeal is practical. Organizations with remote or internationally distributed teams cannot always route every authentication request through an on-premises system without introducing latency or availability risks. A hybrid setup lets security teams keep the most sensitive credential classes (privileged accounts, infrastructure secrets, compliance-sensitive credentials) in a locally controlled vault, while extending access to less sensitive resources through a cloud layer.

The compliance complexity, however, scales with the architecture. Every boundary between the on-premises and cloud components is a potential gap: in audit coverage, in access policy enforcement, in incident response scope. If the cloud layer falls under a foreign jurisdiction, the sovereignty protections of the on-premises component do not automatically extend to it.

Hybrid architecture is the most flexible model in this spectrum — and the most demanding to operate correctly. For organizations with the engineering capacity to manage it, it offers a workable balance between control and accessibility. For those without, on-premises or sovereign EU cloud is the more defensible choice.

Passwork for European businesses: Built for sovereignty from the start

Passwork is a European password manager — incorporated and operated as a European company, with its legal base in Spain under EU law. It was built on-premises first, for organizations that need full infrastructure control, and has since added a cloud option hosted entirely within the EU.

This matters for European businesses because the vendor's own jurisdiction is part of the compliance picture. A European company operating under EU law does not carry US CLOUD Act exposure. Passwork's architecture and deployment options were designed with this regulatory context in mind.

On-premises deployment

Passwork on-premises runs entirely within the organization's own infrastructure. The vendor has no access to the credential store — no remote access, no telemetry, and no backdoor. All data, encryption keys, and backups remain inside the organization's systems.

Key capabilities for regulated environments:

• Full infrastructure control — deploy on your own servers, private cloud, or air-gapped networks. Supports environments with no internet connectivity.
• Zero-knowledge architecture — credentials are encrypted and decrypted on the client side. The server stores only ciphertext and never processes plaintext passwords, which means a compromised server exposes nothing readable.
• Role-based access control — granular permissions at vault, folder, and credential level. Integrates with Active Directory, Azure AD, LDAP, and SAML SSO for automated user provisioning and lifecycle management.
• Audit logs — complete activity history for every credential access, modification, and sharing event. Directly supports GDPR accountability requirements and NIS2 incident documentation.
• AES-256 encryption — credentials encrypted at rest and in transit. Keys stay within the organization's infrastructure.
• Compliance reports — built-in reporting for security audits, access reviews, and regulatory documentation.
• Scales from 10 to 30,000+ users — the same architecture works for a mid-market IT team and a large enterprise with complex permission structures.

The majority of Passwork's customers choose on-premises deployment, according to the company's internal data. This is especially true for large enterprises, government bodies, and organizations in highly regulated industries.

Passwork Cloud: EU-hosted, zero-knowledge

Passwork Cloud is hosted in Germany. All data stays within EU jurisdiction, processed and stored under EU law.

The architecture uses client-side encryption with zero-knowledge design: the server never sees plaintext credentials. Encryption and decryption happen on the client side, so even in the event of a server-side incident, credential data remains protected.

Passwork Cloud includes the full enterprise feature set:

• User management, Active Directory / LDAP integration, SSO
• Audit logs and compliance reports
• Advanced MFA and security policies
• Browser extensions, mobile apps, and REST API
• DevOps secrets management — CLI, Python library, Kubernetes integration, CI/CD pipeline support

Pricing starts at €3 per user per month (Standard) and €4.50 per user per month (Advanced). Long-term ownership costs run approximately 30% below the industry average.

Security posture

Passwork holds ISO 27001 certification across development, infrastructure, and operations. The company runs annual third-party penetration tests, including through HackerOne, and applies a DevSecOps approach with static and dynamic analysis integrated into every build.

This security posture is directly relevant for organizations that need to document their password manager vendor's security practices — a requirement under both NIS2 Article 21 and DORA's third-party risk management framework.

Decision framework: Choosing the right model for your organization

The right hosting model depends on four variables: regulatory exposure, sector classification, internal IT capacity, and total cost of ownership. The table below maps common organizational profiles to recommended deployment models.

TCO considerations

Total cost of ownership for each model includes more than licensing or infrastructure costs. Compliance overhead is a real line item: the time spent on vendor risk assessments, audit documentation, and incident response planning varies significantly by model.

On-premises deployment concentrates compliance work internally — the organization controls the environment and can produce audit evidence directly. Cloud deployments shift some compliance work to vendor management: reviewing security certifications, negotiating DPA terms, maintaining a DORA third-party register entry.

For NIS2-regulated entities, the compliance overhead of a poorly documented cloud deployment can exceed the infrastructure cost of on-premises deployment. That calculation is worth running before defaulting to the lowest-friction option.

Conclusion

The hosting model for a password manager is an architectural decision with long-term compliance implications. GDPR, NIS2, DORA, and the US CLOUD Act create a regulatory environment where the wrong choice generates documented liability.

The model spectrum gives European organizations real options. The right choice depends on sector classification, regulatory exposure, internal IT capacity, and an honest TCO calculation that includes compliance overhead.

For organizations that need maximum control, on-premises deployment eliminates third-party exposure entirely. For those that need managed infrastructure without foreign jurisdiction risk, sovereign EU cloud is a credible path. Hybrid architectures work when neither extreme fits the operational reality.

Passwork is a European password manager that covers the full spectrum: on-premises deployment for organizations that require complete infrastructure control, and EU-hosted cloud for teams that want managed hosting without sacrificing data sovereignty. Both options are built on the same zero-knowledge encryption architecture and include the audit, access control, and compliance reporting features that regulated European businesses need.

Ready to take te frist step? Start your free Passwork trial to get complete control, automated credential management, and enterprise-grade data protection.

Frequently asked questions

Is a cloud password manager GDPR compliant?

A cloud password manager can be GDPR compliant if the vendor processes personal data under a valid legal basis, provides a Data Processing Agreement (DPA) meeting Article 28 requirements, and applies appropriate safeguards for any data transfers outside the EU. Compliance depends on the vendor's architecture and contractual terms — not cloud hosting alone.

Does GDPR require data to be stored in Europe?

GDPR does not mandate EU data storage. It requires that personal data transferred outside the EU is protected to an equivalent standard — through adequacy decisions, Standard Contractual Clauses, or other mechanisms under Articles 44–49. Storing data in the EU simplifies compliance but is not a legal requirement under the regulation itself.

What is the US CLOUD Act and why does it matter for EU businesses?

The US CLOUD Act (2018) allows US federal authorities to compel US-incorporated companies to produce data stored anywhere in the world, including EU data centers. For European organizations using US-based password manager vendors, this means credential data could be subject to US government access regardless of where the servers are physically located.

When does NIS2 apply to password manager hosting decisions?

NIS2 applies when the organization is classified as an "essential" or "important" entity — covering energy, transport, banking, healthcare, digital infrastructure, and public administration, among others. For these organizations, a password manager is part of the ICT supply chain, and Article 21 requires documented security measures for all supply chain components.

What does DORA require for cloud-hosted password managers in financial services?

DORA requires financial entities to maintain a register of ICT third-party service providers, conduct risk assessments of critical providers, and ensure contracts include rights to audit, data access, and exit. A cloud-hosted password manager used by a financial institution is an ICT third-party service under DORA — the institution must document and manage this dependency formally.

What is the difference between a sovereign EU cloud and a regular EU data center?

A regular EU data center operated by a US company is still subject to US jurisdiction through the CLOUD Act. A sovereign cloud provider is incorporated and operated entirely within the EU, with no legal obligation to comply with foreign government data requests. The distinction matters for GDPR transfer risk assessments and NIS2 supply chain documentation.

How does Passwork support compliance for European organizations?

Passwork is a European company under EU law, ISO 27001 certified, with on-premises and EU-hosted cloud deployment options. On-premises deployment eliminates third-party access entirely. The cloud version is hosted in Germany under EU jurisdiction with zero-knowledge encryption. Both options include audit logs, compliance reports, and role-based access control to support GDPR, NIS2, and DORA requirements.

Data breach prevention for business: Beyond basic antivirus

82% of attacks in 2026 are malware-free — antivirus won’t catch them. This guide covers a 7-layer defense strategy built for credential theft, lateral movement, and supply chain compromise.

Passwork BlogAlex Muntyan

Passwork vs 1Password: Best Password Manager for EU

GDPR, NIS2, ANSSI 2027 — the regulatory pressure keeps building. We compare Passwork and 1Password on the criteria that matter to European businesses: data sovereignty, audit readiness, deployment model, and real total cost of ownership.

Passwork BlogPasswork Team

NIS2 compliance latest news: June and July 2026 enforcement update

Four EU member states referred to court, the Netherlands’ NIS2 law enters force August 15, Germany’s BSI is auditing 29,000 entities, and the EU published its first AI-cybersecurity action plan. Here’s everything that changed in June–July 2026.

Passwork BlogPasswork Team

Einleitung

Ihr Sicherheitsteam hat gerade die Antivirenlizenz verlängert. Patches sind aktuell. Die Firewall-Regeln wurden seit zwei Jahren nicht geändert — weil nichts schiefgegangen ist. Warum landen Organisationen mit all diesen Maßnahmen trotzdem auf der Liste der Datenschutzverletzungen?

Weil die Tools, die 2010 funktionierten, für eine Bedrohung entwickelt wurden, die nicht mehr existiert.

Moderne Angreifer liefern keine Malware an Ihre Endpunkte. Sie beschaffen sich gültige Anmeldedaten — durch Phishing, eine geleakte Datenbank oder einen kompromittierten Anbieter — und authentifizieren sich wie jeder andere Benutzer. Von dort aus bewegen sie sich leise, eskalieren Berechtigungen und exfiltrieren Daten über Wochen. Bis jemand es bemerkt, ist der Schaden bereits angerichtet.

Antivirensoftware hat keine Signatur für einen legitimen Login.

Dieser Artikel erläutert, wie eine mehrschichtige, identitätszentrierte Verteidigung tatsächlich aussieht — und welche Kontrollen priorisiert werden sollten, wenn Sie 2026 einen Security-Stack aufbauen oder auditieren.

Wichtigste Erkenntnisse

• Signaturbasierte Antivirensoftware übersieht die Mehrheit moderner Angriffe. CrowdStrikes Global Threat Report 2026 stellte fest, dass 82 % der Erkennungen im Jahr 2025 malwarefrei waren — Angreifer nutzten Anmeldedatenmissbrauch und dateilose Techniken, die keinen binären Fußabdruck zum Scannen hinterlassen.
• Gestohlene Anmeldedaten sind der führende Erstzugriffsvektor. Verizons DBIR 2025 ergab, dass kompromittierte Anmeldedaten bei etwa 30 % der Datenschutzverletzungen beteiligt waren. Angreifer authentifizieren sich als legitime Benutzer und umgehen dabei jede Kontrolle, die zur Erkennung von Malware entwickelt wurde.
• Enterprise-Passwortmanagement und PAM sind grundlegende Kontrollen. Zentralisierte Anmeldedatenspeicherung, Durchsetzung des Least-Privilege-Prinzips und Just-In-Time-Zugriffsbereitstellung adressieren direkt die Angriffsvektoren, die für die meisten Datenschutzverletzungen verantwortlich sind.
• Zero-Trust-Architektur ist die strukturelle Antwort auf laterale Bewegung. Kontinuierliche Verifizierung von Identität, Gerätezustand und Verhaltenskontext — kombiniert mit Mikrosegmentierung — begrenzt einen Angreifer selbst nach der ersten Kompromittierung.
• Compliance-Frameworks definieren das Minimum, nicht den angemessenen Standard. DSGVO, NIS2, SOC 2 und ISO 27001 schreiben alle Zugriffskontrollen und Incident-Response-Verfahren vor, aber keines definiert die genaue Implementierung. Die Lücke zwischen dem Abhaken und effektiver Sicherheit ist dort, wo die meisten Datenschutzverletzungen auftreten.

Was ist eine Datenschutzverletzung? (Die moderne Definition)

Eine Datenschutzverletzung ist jeder bestätigte Vorfall, bei dem sensible, geschützte oder vertrauliche Informationen ohne Autorisierung zugegriffen, offengelegt oder exfiltriert werden. Dies umfasst personenbezogene Daten (PII), Finanzdaten, geistiges Eigentum und geschützte Gesundheitsinformationen (PHI).

Der Unterschied zwischen einem Sicherheitsvorfall und einer bestätigten Datenschutzverletzung ist operativ wichtig.

• Sicherheitsvorfall — jedes Ereignis, das Vertraulichkeit, Integrität oder Verfügbarkeit bedroht. Bewusst breit gefasst; die meisten eskalieren nicht weiter.
• Bestätigte Datenschutzverletzung — unberechtigter Zugriff auf Daten ist als Tatsache festgestellt. Dies löst obligatorische Meldepflichten gemäß DSGVO Artikel 33, NIS2 Artikel 23 und ähnlichen Rahmenwerken aus.

Diese Grenze bestimmt Ihre rechtliche Exposition, Ihre Meldefrist und ob Aufsichtsbehörden Sie als Opfer oder als fahrlässige Partei behandeln.

Warum Antivirensoftware nicht mehr ausreicht, um Datenschutzverletzungen zu verhindern

Antivirensoftware scannt Dateien und Prozesse gegen eine Datenbank bekannter Malware-Signaturen und blockiert dann alles, was übereinstimmt. Es war das richtige Tool für eine Bedrohungslandschaft, die auf ausführbaren Dateien und bekannten Virenstämmen basierte.

Ältere Antivirensoftware basiert auf signaturbasierter Erkennung: Wenn die Bedrohung nicht in der Datenbank ist, wird sie nicht erkannt. Dieses Modell versagt bei Bedrohungen, die überhaupt nicht wie Malware aussehen.

Laut CrowdStrikes Global Threat Report 2026 waren 82 % der Erkennungen im Jahr 2025 malwarefrei — das bedeutet, Angreifer nutzten Anmeldedatenmissbrauch, Living-off-the-Land-Techniken und dateilose Ausführung, die keinen binären Fußabdruck zum Scannen hinterlassen. Googles Threat Intelligence Team verfolgte 90 Zero-Day-Schwachstellen, die 2025 in freier Wildbahn ausgenutzt wurden, wobei jede ein Angriffsfenster darstellt, für das noch keine Signatur existiert.

Die 7-Schichten-Strategie zur Verhinderung von Datenschutzverletzungen für 2026

Ein mehrschichtiges Verteidigungsmodell adressiert die gesamte Angriffskette — vom Erstzugriff über laterale Bewegung bis zur Exfiltration. Jede Schicht unten ist nach Auswirkung und Implementierungspriorität geordnet.

1. Phishing-resistente MFA und Enterprise-Passwortmanagement durchsetzen

Microsoft-Forschung bestätigt, dass MFA mehr als 99,2 % der Account-Kompromittierungsangriffe blockiert. Diese einzelne Kontrolle eliminiert die überwiegende Mehrheit der anmeldedatenbasierten Eindringversuche — aber nur, wenn sie korrekt implementiert wird.

SMS-basierte MFA ist anfällig für SIM-Swapping und Prompt-Bombing. Phishing-resistente Alternativen — FIDO2-Hardware-Keys, Passkeys und zertifikatsbasierte Authentifizierung — entfernen den menschlichen Abfangvektor vollständig. Diese sollten der Standard für jeden Account mit Zugriff auf sensible Systeme sein.

MFA allein löst jedoch nicht das zugrundeliegende Problem der Anmeldedatenhygiene. Mitarbeiter verwenden Passwörter auf persönlichen und Unternehmenskonten wieder, teilen Anmeldedaten über Chat und speichern sie in Tabellen. Verizons DBIR 2025 stellte fest, dass gestohlene Anmeldedaten bei etwa 30 % der Datenschutzverletzungen der Erstzugriffsvektor waren. Ein Enterprise-Passwortmanager schließt diese Lücke durch Zentralisierung der Anmeldedatenspeicherung, Durchsetzung starker Passwortrichtlinien und Eliminierung von Ad-hoc-Freigaben.

Passwork ist speziell für diesen Anwendungsfall entwickelt. Es wird vollständig auf Ihrer eigenen Infrastruktur bereitgestellt — keine Anmeldedaten verlassen jemals Ihre Umgebung. Alle Geheimnisse werden mit AES-256 sowohl auf Server- als auch auf Client-Seite unter einer Zero-Knowledge-Architektur verschlüsselt.

Die Integration mit Active Directory und LDAP automatisiert die Benutzerbereitstellung und -deprovisionierung, sodass der Zugriff in dem Moment entzogen wird, in dem ein Mitarbeiter das Unternehmen verlässt. Jeder Anmeldedatenzugriff, jede Änderung und jedes Freigabeereignis wird in einem manipulationssicheren Audit-Trail protokolliert — was direkt die Anforderungen an Insider-Bedrohungen und Compliance-Audits adressiert. Passwork ist ISO/IEC 27001-zertifiziert, was bestätigt, dass das Informationssicherheitsmanagement internationalen Standards entspricht.

Die Verwaltung gemeinsam genutzter Anmeldedaten über Teams hinweg ohne einen strukturierten Tresor ist einer der schnellsten Wege zu einer Datenschutzverletzung. Erfahren Sie, wie Passwork Enterprise-Passwortmanagement handhabt → passwork.pro

2. Privileged Access Management (PAM) implementieren

Privileged Access Management (PAM) ist ein Sicherheitsframework, das den Zugriff auf Konten mit erhöhten Systemberechtigungen kontrolliert, überwacht und auditiert — die Anmeldedaten, die einem Angreifer bei Kompromittierung administrative Kontrolle über Ihre Infrastruktur geben.

PAM regelt den Zugriff auf hochwertige Ziele: Domain-Controller, Cloud-Konsolen, Datenbankserver und Netzwerkinfrastruktur. Über die Zugriffskontrolle hinaus erzwingt es zusätzliche Sicherheit auf Sitzungsebene: Aufzeichnung von Aktivitäten, Auditierung von Befehlen und Bereitstellung von Zugriff durch Just-In-Time (JIT)-Mechanismen. JIT bedeutet, dass Admin-Rechte für ein definiertes Zeitfenster gewährt und automatisch entzogen werden — was dauerhafte Berechtigungen eliminiert, die Angreifer nach der ersten Kompromittierung ausnutzen können.

Das Prinzip der minimalen Rechtevergabe ist die operative Grundlage: Jeder Benutzer, jedes Dienstkonto und jede Anwendung erhält nur den minimalen Zugriff, der für ihre Funktion erforderlich ist, und nicht mehr.

Die Durchsetzung minimaler Rechte beginnt auf der Anmeldedatenebene. Das rollenbasierte Zugriffsmodell von Passwork ermöglicht Administratoren die Zuweisung granularer Berechtigungen pro Benutzer oder Gruppe — mit genauer Kontrolle darüber, wer bestimmte Anmeldedaten ansehen, kopieren oder ändern kann.

Jede Rolle ist vollständig konfigurierbar: Anstatt zwischen vollem Administratorzugriff und keinem zu wählen, können Berechtigungen auf spezifische Funktionen beschränkt werden — Benutzerverwaltung, LDAP-Konfiguration, Audit-Logs oder Tresoreinstellungen — unabhängig voneinander.

3. Eine Zero-Trust-Architektur einführen

Zero Trust ist ein Sicherheitsmodell, das auf der Annahme basiert, dass keinem Benutzer, Gerät oder Netzwerksegment standardmäßig vertraut werden sollte — unabhängig davon, ob die Anfrage innerhalb oder außerhalb des Unternehmensperimeters erfolgt. Der Zugriff wird erst nach kontinuierlicher Verifizierung von Identität, Gerätezustand und Verhaltenskontext gewährt.

Das Modell basiert auf drei Kernprinzipien:

• Explizit verifizieren — jede Zugriffsanfrage wird basierend auf allen verfügbaren Datenpunkten authentifiziert und autorisiert: Identität, Gerätezustand, Standort und Verhaltenskontext.
• Least-Privilege-Zugriff verwenden — Benutzer und Systeme erhalten nur die Berechtigungen, die für ihre aktuelle Aufgabe erforderlich sind, was den Explosionsradius einer Kompromittierung begrenzt.
• Von einer Kompromittierung ausgehen — die Architektur ist so konzipiert, als ob ein Angreifer bereits drin ist. Mikrosegmentierung, verschlüsselte Traffic-Inspektion und kontinuierliche Überwachung begrenzen laterale Bewegung, bevor sie eskaliert.

Diese Architektur adressiert direkt laterale Bewegung. Wenn ein Angreifer einen Endpunkt oder ein Konto kompromittiert, verhindern Zero-Trust-Mikrosegmentierung und kontinuierliche Authentifizierungsprüfungen, dass sie auf benachbarte Systeme übergreifen.

Zero Trust ist eine Designphilosophie, die durch Identitätsanbieter, Netzwerksegmentierung und Richtliniendurchsetzungspunkte implementiert wird — kein einzelnes Produkt oder keine einzelne Anbieterlösung. NIST SP 800-207 bietet das maßgebliche Framework für die Implementierung.

4. Auf Endpoint Detection and Response (EDR) upgraden

Endpoint Detection and Response (EDR) ist eine Sicherheitstechnologie, die Endpunktaktivitäten kontinuierlich überwacht — Prozesse, Netzwerkverbindungen, Dateisystemänderungen und Benutzerverhalten — und automatisierte Reaktionen auslöst, wenn anomale Muster erkannt werden.

EDR ersetzt das statische Signaturmodell durch Verhaltensüberwachung. Anstatt zu fragen „stimmt diese Datei mit einer bekannten Bedrohung überein?", fragt EDR „verhält sich dieser Prozess wie ein Angriff?"

Diese Unterscheidung erkennt dateilose Malware, Credential-Dumping-Tools und Ransomware-Staging-Aktivitäten, bevor die Ausführung abgeschlossen ist. EDR-Lösungen führen ein kontinuierliches Telemetrie-Protokoll der Endpunktaktivitäten und ermöglichen eine forensische Rekonstruktion nach einem Vorfall — entscheidend sowohl für die Eindämmung als auch für die Compliance-Berichterstattung.

Ransomware war bei 44 % der Datenschutzverletzungen im Jahr 2025 vorhanden, gegenüber 32 % im Vorjahr. EDR mit automatisierten Reaktionsfähigkeiten — Isolierung eines Endpunkts in dem Moment, in dem anomales Verhalten erkannt wird — ist heute eine Basiskontrolle für jede Organisation, die sensible Daten verarbeitet.

EDR-Lösungen in der Praxis

• CrowdStrike Falcon — cloudnativer Agent mit Echtzeit-Verhaltenserkennung, automatisierter Eindämmung und Threat-Intelligence-Integration
• SentinelOne Singularity Endpoint — autonome Reaktion ohne Cloud-Abhängigkeit; enthält Rollback-Fähigkeit für Ransomware-betroffene Dateien
• Microsoft Defender for Endpoint — tief in das Microsoft-Ökosystem integriert; deckt Windows, macOS, Linux, iOS und Android ab
• Palo Alto Networks Cortex XDR — erweitert Endpunkt-Telemetrie auf Netzwerk- und Cloud-Daten; einheitliche Erkennung über die gesamte Angriffsoberfläche
• Trend Micro Vision One — kombiniert EDR mit XDR über E-Mail, Endpunkte, Server und Cloud-Workloads
• Sophos Intercept X — enthält Anti-Exploit- und Anti-Ransomware-Module neben Verhaltenserkennung; als Managed Service verfügbar
• Cisco Secure Endpoint — integriert sich in Ciscos breiteren Security-Stack; stark bei Threat Hunting und retrospektiver Analyse

5. Data Loss Prevention (DLP) und Verschlüsselung einsetzen

Data Loss Prevention (DLP) ist eine Reihe von Technologien und Richtlinien, die die Bewegung sensibler Daten über Endpunkte, Netzwerke und Cloud-Umgebungen erkennen, überwachen und einschränken — um unbefugten Zugriff, Übertragung oder Exfiltration zu verhindern, bevor eine Datenschutzverletzung bestätigt wird.

DLP-Tools überwachen und kontrollieren die Bewegung sensibler Daten: PII, Finanzdaten, Quellcode und regulierte Informationen. Sie setzen Richtlinien durch, die unbefugte Uploads in Cloud-Speicher blockieren, Exfiltration per E-Mail verhindern und anomale Massen-Datenübertragungen kennzeichnen.

DLP-Tools in der Praxis

Der Markt bietet Lösungen in drei Bereitstellungsmodellen — Endpunkt, Netzwerk und Cloud — die oft in einer einzigen Plattform kombiniert werden:

Endpunkt-DLP

• Microsoft Purview DLP — native Integration mit Microsoft 365 und Windows-Endpunkten; deckt E-Mail, Teams, SharePoint und lokale Dateiaktivitäten ab
• Forcepoint DLP — verhaltensbasierte Erkennung mit tiefgehender Inhaltsprüfung über Endpunkte und Webkanäle
• Digital Guardian (Fortra) — granularer Endpunkt-Agent mit forensischem Logging; starke Abdeckung für geistiges Eigentum

Netzwerk- und Cloud-DLP

• Netskope DLP — cloudnativ; konzipiert für SaaS, IaaS und Web-Traffic-Inspektion
• Symantec DLP (Broadcom) — deckt Netzwerk, Endpunkt und Cloud-Speicher mit Datenerkennung und -klassifizierung ab
• Palo Alto Networks Enterprise DLP — in den NGFW- und Prisma-SASE-Stack integriert; kein separater Agent erforderlich
• Varonis — kartiert sensible Daten über Dateifreigaben, Cloud-Speicher und E-Mail; enthält Anomalieerkennung für Benutzerverhalten

Verschlüsselung ist die ergänzende Kontrolle. Daten, die im Ruhezustand und bei der Übertragung verschlüsselt sind, bleiben selbst bei Exfiltration unlesbar. Vollständige Festplattenverschlüsselung auf Endpunkten, TLS 1.3 für Daten bei der Übertragung und offline gespeicherte verschlüsselte Backups bilden die Baseline. Für regulierte Branchen ist Verschlüsselung nicht optional — NIS2 Artikel 21 und DSGVO Artikel 32 verweisen beide darauf als angemessene technische Schutzmaßnahme.

6. Drittanbieter- und Lieferkettenrisiken managen

Drittanbieterrisiko ist die Exposition, die durch Anbieter, Auftragnehmer und Software-Abhängigkeiten in Ihre Umgebung gelangt — Entitäten außerhalb Ihrer direkten Kontrolle, die dennoch Zugriff auf Ihre Systeme, Daten oder Codebasis haben. Die Beteiligung von Drittanbietern an Datenschutzverletzungen verdoppelte sich laut Verizons DBIR 2025 im Jahresvergleich.

Anbieterrisikomanagement erfordert mehr als jährliche Fragebögen. Wirksame Kontrollen umfassen:

• Beschränkung des Drittanbieterzugriffs auf nur die Systeme, die sie benötigen
• MFA-Anforderung für alle externen Konten
• Überwachung der Drittanbieter-Sitzungsaktivitäten
• Einbeziehung von Sicherheitsanforderungen in vertragliche Vereinbarungen

Lieferkettenangriffe sind ein eigenständiger und schwerer zu erkennender Vektor: Bösartiger Code wird in Software eingeschleust, bevor sie Sie erreicht — durch eine kompromittierte Build-Pipeline, ein manipuliertes Paket-Repository oder ein gekapertes Anbieter-Update. Wenn die Nutzlast ankommt, sieht sie bereits legitim aus. Zwei Vorfälle von Anfang 2026 illustrieren das Ausmaß der Exposition:

• Trivy (März 2026). Der Schwachstellenscanner von Aqua Security wurde über seine Docker-Images kompromittiert und lieferte eine Information-Stealer-Nutzlast an Teams, die jeden Grund hatten, dem Tool zu vertrauen.
• Axios (März 2026). Angreifer, die mit dem nordkoreanischen Bedrohungsakteur UNC1069 in Verbindung stehen, betteten einen Remote-Access-Trojaner in das weit verbreitete Axios-npm-Paket ein und verteilten ihn still über die Abhängigkeitskette.

In beiden Fällen kam bösartiger Code über einen vertrauenswürdigen Kanal — bevor eine interne Kontrolle die Chance hatte, ihn abzufangen. Effektive Verteidigung erfordert Software-Composition-Analyse und Integritätsverifizierung für alle Drittanbieterkomponenten.

7. Kontinuierliche Security-Awareness-Schulungen durchführen

Der menschliche Faktor war bei 60 % der Datenschutzverletzungen im Jahr 2025 beteiligt. Jährliche Compliance-Schulungen ändern das Verhalten nicht — sie produzieren abgehakte Checkboxen, kein Sicherheitsbewusstsein.

Effektive Programme führen kontinuierliche, simulierte Phishing-Kampagnen durch, die auf aktuelle Angriffstechniken kalibriert sind. Wenn ein Mitarbeiter auf einen simulierten Phishing-Link klickt, erhält er sofort kontextbezogenes Feedback — nicht eine vierteljährliche Erinnerung.

Gamifizierte Plattformen, die individuelle Verbesserungen im Laufe der Zeit verfolgen, erzielen messbare Reduzierungen der Klickraten. Sicherheitskultur wird durch Wiederholung und Relevanz aufgebaut, nicht durch jährliche Vorträge.

Wie Compliance-Frameworks die Verhinderung von Datenschutzverletzungen beeinflussen

Compliance-Frameworks (DSGVO, NIS2, DORA, SOC 2) schreiben spezifische technische Kontrollen vor: Zugriffsprotokollierung, Verschlüsselung, Incident-Response-Verfahren und Anbietermanagement. Die Erfüllung dieser Anforderungen etabliert eine Sicherheits-Baseline.

Compliance definiert den minimal akzeptablen Standard — nicht den angemessenen. Ein SOC 2 Type II-Audit bestätigt, dass Kontrollen während des Auditzeitraums existierten und effektiv funktionierten; es macht keine Aussage darüber, was am Tag nach dem Verlassen des Auditors passiert, oder ob diese Kontrollen gegen Ihre tatsächliche Bedrohungslandschaft ausreichen. Organisationen, die Compliance mit Sicherheitsstrategie gleichsetzen, erfahren den Unterschied in der Regel im ungünstigsten Moment.

Nutzen Sie Frameworks als strukturierten Ausgangspunkt. Bauen Sie basierend auf Ihrem tatsächlichen Bedrohungsmodell darüber hinaus.

Was jedes Framework tatsächlich erfordert

Die Tabelle zeigt ein Muster: Jedes Framework deckt Zugriffskontrolle und Incident Response in irgendeiner Form ab, aber keines schreibt genau vor, wie. Diese Implementierungslücke ist dort, wo die meisten Datenschutzverletzungen auftreten — nicht weil das Framework falsch war, sondern weil die Organisation bei der Checkbox aufgehört hat.

Passworks Audit-Logs, rollenbasierte Zugriffskontrollen und ISO 27001-Zertifizierung unterstützen direkt die Compliance mit DSGVO-, NIS2- und SOC 2-Anforderungen. Entdecken Sie Passworks Compliance-relevante Funktionen → passwork.pro

Entwicklung eines Incident-Response-Plans (von einer Kompromittierung ausgehen)

Prävention ist niemals absolut. Der IBM Cost of a Data Breach Report 2025 stellte fest, dass die durchschnittliche Zeit zur Identifizierung und Eindämmung einer Datenschutzverletzung 241 Tage beträgt. Organisationen mit einem getesteten Incident-Response-Plan dämmen Datenschutzverletzungen deutlich schneller ein — und schnellere Eindämmung reduziert direkt die Kosten.

Ein wirksamer IR-Plan definiert: wer einen Vorfall deklariert, wie der Eskalationspfad aussieht, wie Systeme isoliert werden, wann Aufsichtsbehörden und betroffene Parteien benachrichtigt werden müssen und wie Beweise für die forensische Analyse gesichert werden. DSGVO Artikel 33 erfordert die Meldung an Aufsichtsbehörden innerhalb von 72 Stunden nach Kenntnis einer Datenschutzverletzung — eine Frist, die ohne einen vordefinierten Prozess nicht einzuhalten ist.

Testen Sie den Plan. Eine Tabletop-Übung, die einmal im Jahr durchgeführt wird, offenbart Lücken, die keine Dokumentation aufdecken kann.

Fazit

Die Bedrohungslandschaft hat sich entscheidend von malwarebasierten Angriffen hin zu Identitätsausnutzung, dateilosen Techniken und Lieferkettenkompromittierungen verlagert. Ein signaturbasiertes Antivirenprodukt adressiert keinen dieser Vektoren effektiv.

Das oben beschriebene 7-Schichten-Modell — verankert durch phishing-resistente MFA, Enterprise-Passwortmanagement und Zero-Trust-Architektur — spiegelt wider, wie moderne Angriffe tatsächlich funktionieren und wo Kontrollen die größte Wirkung haben. Jede Schicht adressiert eine spezifische Phase der Angriffskette. Zusammen schaffen sie eine Defense-in-Depth, die ältere Perimetersicherheit nicht replizieren kann.

Auditieren Sie Ihren aktuellen Stack gegen diese sieben Schichten. Identifizieren Sie, welche Kontrollen fehlen, welche teilweise implementiert sind und welche falsch konfiguriert sind. Die Lücken, die Sie finden, sind die Lücken, die ein Angreifer zuerst finden wird.

Passwork ist als Self-hosted- und Cloud-Lösung verfügbar mit AES-256-Verschlüsselung, AD/LDAP-Integration, vollständiger Audit-Protokollierung und ISO 27001-Zertifizierung. Testen Sie Passwork in Ihrer Umgebung → passwork.pro

Häufig gestellte Fragen

Worauf sollten Unternehmen bei einem Enterprise-Passwortmanager achten?

Priorisieren Sie On-Premise- oder Self-hosted-Bereitstellung, damit Anmeldedaten innerhalb Ihrer Infrastruktur bleiben. Wesentliche Fähigkeiten umfassen Zero-Knowledge-AES-256-Verschlüsselung, Active Directory- und LDAP-Integration für automatisierte Benutzerbereitstellung, manipulationssichere Audit-Logs und ISO 27001-Zertifizierung. Passwork erfüllt alle diese Anforderungen und wird vollständig in Ihrer eigenen Umgebung bereitgestellt.

Was ist die häufigste Ursache für eine Datenschutzverletzung im Jahr 2026?

Gestohlene Anmeldedaten bleiben der führende Erstzugriffsvektor. Verizons DBIR 2025 ergab, dass kompromittierte Anmeldedaten bei etwa 30 % der Datenschutzverletzungen beteiligt waren. Angreifer beschaffen sie durch Phishing, geleakte Datenbanken oder kompromittierte Anbieter — und authentifizieren sich dann als legitime Benutzer, wobei sie signaturbasierte Abwehrmechanismen vollständig umgehen.

Warum reicht Antivirensoftware nicht mehr aus, um Datenschutzverletzungen zu verhindern?

Antivirensoftware basiert auf signaturbasierter Erkennung: Sie identifiziert Bedrohungen durch Abgleich von Dateien mit einer Datenbank bekannter Malware. Laut CrowdStrikes Global Threat Report 2026 waren 82 % der Erkennungen im Jahr 2025 malwarefrei — das bedeutet, Angreifer nutzten Anmeldedatenmissbrauch und dateilose Techniken, die keinen binären Fußabdruck zum Scannen hinterlassen.

Was ist der Unterschied zwischen einem Sicherheitsvorfall und einer Datenschutzverletzung?

Ein Sicherheitsvorfall ist jedes Ereignis, das Vertraulichkeit, Integrität oder Verfügbarkeit bedroht — die meisten eskalieren nicht weiter. Eine bestätigte Datenschutzverletzung bedeutet, dass unberechtigter Zugriff auf Daten als Tatsache festgestellt ist. Diese Unterscheidung bestimmt Ihre rechtliche Exposition: DSGVO Artikel 33 und NIS2 Artikel 23 erfordern die Meldung an Aufsichtsbehörden innerhalb von 72 Stunden nach Bestätigung einer Datenschutzverletzung.

Was bedeutet Zero-Trust-Architektur in der Praxis tatsächlich?

Zero Trust bedeutet, dass keinem Benutzer, Gerät oder Netzwerksegment standardmäßig vertraut wird — unabhängig davon, ob die Anfrage innerhalb oder außerhalb des Unternehmensperimeters erfolgt. Jede Zugriffsanfrage wird gegen Identität, Gerätezustand und Verhaltenskontext verifiziert. Mikrosegmentierung begrenzt laterale Bewegung, wenn ein Konto oder Endpunkt kompromittiert wird. NIST SP 800-207 bietet das maßgebliche Implementierungsframework.

Was ist ein Lieferkettenangriff und wie unterscheidet er sich von einer Standard-Anbieterverletzung?

Ein Lieferkettenangriff schleust bösartigen Code in Software ein, bevor sie den Endbenutzer erreicht — durch eine kompromittierte Build-Pipeline, ein manipuliertes Paket-Repository oder ein gekapertes Update. Anders als bei einer Anbieterverletzung, bei der der Angreiferzugriff die Bedrohung ist, macht ein Lieferkettenangriff die Software selbst zur Waffe. Wenn die Nutzlast ankommt, erscheint sie bereits legitim.

Was ist die durchschnittliche Zeit zur Erkennung und Eindämmung einer Datenschutzverletzung?

Laut IBMs Cost of a Data Breach Report 2025 beträgt die durchschnittliche Zeit zur Identifizierung und Eindämmung einer Datenschutzverletzung 241 Tage. Organisationen mit einem getesteten Incident-Response-Plan dämmen Datenschutzverletzungen deutlich schneller ein. Dieser Geschwindigkeitsunterschied reduziert direkt die finanzielle und regulatorische Exposition — einschließlich des 72-Stunden-Meldefensters, das gemäß DSGVO Artikel 33 erforderlich ist.

Was sollte ein Enterprise-Passwortmanager enthalten, um Compliance zu unterstützen?

On-Premise-Bereitstellung, damit Anmeldedaten innerhalb Ihrer Infrastruktur bleiben, AES-256-Zero-Knowledge-Verschlüsselung, Active Directory- und LDAP-Integration für automatisierte Bereitstellung und Deprovisionierung, manipulationssichere Audit-Logs und ISO 27001-Zertifizierung. Diese Fähigkeiten adressieren direkt die Zugriffskontroll- und Audit-Anforderungen gemäß DSGVO, NIS2 und SOC 2. Passwork erfüllt alle diese Anforderungen und wird vollständig in Ihrer eigenen Umgebung bereitgestellt.

Wie reduziert Privileged Access Management das Risiko von Datenschutzverletzungen?

PAM kontrolliert den Zugriff auf hochwertige Konten — Domain-Controller, Cloud-Konsolen, Datenbankserver — und erzwingt Just-In-Time-Bereitstellung: Admin-Rechte werden für ein definiertes Zeitfenster gewährt und automatisch entzogen. Dies eliminiert dauerhafte Berechtigungen, die Angreifer nach der ersten Kompromittierung ausnutzen. Das Prinzip der minimalen Rechtevergabe begrenzt den Explosionsradius eines einzelnen kompromittierten Kontos.

Frühjahr 2026 EU-Cybersicherheits-Update: Was sich geändert hat

Das Frühjahr 2026 brachte die bedeutendste institutionelle Datenschutzverletzung der EU, ihre ersten Cyber-Sanktionen des Jahres und vier große Cybersicherheitsvorschriften, die gleichzeitig in Kraft treten. NIS2, DORA, CRA und CSA2 setzen jetzt harte Fristen — und echte Strafen. Hier erfahren Sie, was sich geändert hat, wer betroffen ist und was zu tun ist.

Passwork BlogAlex Muntyan

NIS2-Passwortanforderungen: Was europäische Unternehmen 2026 tun müssen

Lücken bei Anmeldedaten sind der führende NIS2-Audit-Fehlergrund im Jahr 2026. Dieser Leitfaden behandelt die Passwortanforderungen gemäß Artikel 21, die Ausrichtung an NIST SP 800-63B, AD-Härtungsschritte und die Auditnachweise, nach denen Aufsichtsbehörden zuerst fragen.

Passwork BlogAlex Muntyan

Bereitstellungsmodelle für Passwortmanager: Cloud, Self-Hosted & Hybrid

Die Wahl, wo Sie Ihren Passwortmanager betreiben, ist genauso wichtig wie die Wahl, welchen Sie verwenden. Dieser Leitfaden erläutert Cloud-, Self-hosted- und Hybrid-Bereitstellung — mit einer Compliance-Matrix für DSGVO, HIPAA und NIS2 und einem klaren Blick auf die Kompromisse, die jedes Modell mit sich bringt.

Passwork BlogAlex Muntyan

Introducción

Su equipo de seguridad acaba de renovar la licencia del antivirus. Los parches están actualizados. Las reglas del firewall no han cambiado en dos años — porque nada salió mal. Entonces, ¿por qué las organizaciones que tienen todo esto implementado siguen apareciendo en la lista de divulgación de filtraciones?

Porque las herramientas que funcionaban en 2010 fueron diseñadas para una amenaza que ya no existe.

Los atacantes modernos no entregan malware a sus endpoints. Adquieren un conjunto válido de credenciales — mediante phishing, una base de datos filtrada o un proveedor comprometido — y se autentican como cualquier otro usuario. A partir de ahí, se mueven silenciosamente, escalan privilegios y exfiltran datos durante semanas. Para cuando alguien lo nota, el daño ya está hecho.

El antivirus no tiene una firma para un inicio de sesión legítimo.

Este artículo desglosa cómo es realmente una defensa en capas centrada en la identidad — y qué controles priorizar si está construyendo o auditando una pila de seguridad en 2026.

Puntos clave

• El antivirus basado en firmas no detecta la mayoría de los ataques modernos. El Informe Global de Amenazas 2026 de CrowdStrike encontró que el 82% de las detecciones en 2025 no contenían malware — los atacantes utilizaron abuso de credenciales y técnicas sin archivos que no dejan huella binaria para escanear.
• Las credenciales robadas son el principal vector de acceso inicial. El DBIR 2025 de Verizon encontró que las credenciales comprometidas estuvieron involucradas en aproximadamente el 30% de las filtraciones. Los atacantes se autentican como usuarios legítimos, evadiendo todos los controles diseñados para detectar malware.
• La gestión de contraseñas empresariales y PAM son controles fundamentales. El almacenamiento centralizado de credenciales, la aplicación del principio de mínimo privilegio y el aprovisionamiento de acceso Just-In-Time abordan directamente los vectores de ataque responsables de la mayoría de las filtraciones.
• La arquitectura Zero Trust es la respuesta estructural al movimiento lateral. La verificación continua de identidad, estado del dispositivo y contexto de comportamiento — combinada con microsegmentación — contiene a un atacante incluso después del compromiso inicial.
• Los marcos de cumplimiento definen el mínimo, no el estándar apropiado. GDPR, NIS2, SOC 2 e ISO 27001 exigen controles de acceso y respuesta a incidentes, pero ninguno prescribe la implementación exacta. La brecha entre la casilla de verificación y la seguridad efectiva es donde ocurren la mayoría de las filtraciones.

¿Qué es una filtración de datos? (La definición moderna)

Una filtración de datos es cualquier incidente confirmado en el que información sensible, protegida o confidencial es accedida, divulgada o exfiltrada sin autorización. Esto incluye información de identificación personal (PII), registros financieros, propiedad intelectual e información de salud protegida (PHI).

La distinción entre un incidente de seguridad y una filtración de datos confirmada es importante operativamente.

• Incidente de seguridad — cualquier evento que amenaza la confidencialidad, integridad o disponibilidad. Amplio por diseño, la mayoría nunca escala más allá.
• Filtración de datos confirmada — el acceso no autorizado a datos se establece como un hecho. Esto activa obligaciones de notificación obligatorias bajo el Artículo 33 del GDPR, el Artículo 23 de NIS2 y marcos similares.

Ese límite determina su exposición legal, su plazo de notificación y si los reguladores lo tratan como víctima o como parte negligente.

Por qué el antivirus ya no es suficiente para la prevención de filtraciones de datos

El software antivirus escanea archivos y procesos contra una base de datos de firmas de malware conocidas, y luego bloquea cualquier cosa que coincida. Era la herramienta correcta para un panorama de amenazas construido alrededor de archivos ejecutables y cepas de virus conocidas.

El antivirus tradicional depende de la detección basada en firmas: si la amenaza no está en la base de datos, no se detecta. Ese modelo falla contra amenazas que no parecen malware en absoluto.

Según el Informe Global de Amenazas 2026 de CrowdStrike, el 82% de las detecciones en 2025 no contenían malware — lo que significa que los atacantes utilizaron abuso de credenciales, técnicas living-off-the-land y ejecución sin archivos que no dejan huella binaria para que el antivirus la escanee. El Equipo de Inteligencia de Amenazas de Google rastreó 90 vulnerabilidades de día cero explotadas en la naturaleza en 2025, cada una representando una ventana de ataque donde aún no existe ninguna firma.

La estrategia de prevención de filtraciones de datos de 7 capas para 2026

Un modelo de defensa en capas aborda toda la cadena de ataque — desde el acceso inicial hasta el movimiento lateral y la exfiltración. Cada capa a continuación está ordenada por impacto y prioridad de implementación.

1. Implemente MFA resistente al phishing y gestión de contraseñas empresariales

La investigación de Microsoft confirma que MFA bloquea más del 99,2% de los ataques de compromiso de cuentas. Ese único control elimina la gran mayoría de las intrusiones basadas en credenciales, pero solo si se implementa correctamente.

El MFA basado en SMS es vulnerable al SIM-swapping y al bombardeo de solicitudes. Las alternativas resistentes al phishing — llaves de hardware FIDO2, passkeys y autenticación basada en certificados — eliminan por completo el vector de interceptación humana. Estas deberían ser el estándar para cualquier cuenta con acceso a sistemas sensibles.

Sin embargo, el MFA por sí solo no resuelve el problema subyacente de higiene de credenciales. Los empleados reutilizan contraseñas entre cuentas personales y corporativas, comparten credenciales por chat y las almacenan en hojas de cálculo. El DBIR 2025 de Verizon encontró que las credenciales robadas fueron el vector de acceso inicial en aproximadamente el 30% de las filtraciones. Un gestor de contraseñas empresarial cierra esa brecha centralizando el almacenamiento de credenciales, aplicando políticas de contraseñas fuertes y eliminando el uso compartido ad-hoc.

Passwork está diseñado específicamente para este caso de uso. Se implementa completamente en su propia infraestructura — ningún dato de credenciales sale de su entorno. Todos los secretos están cifrados con AES-256 tanto en el lado del servidor como del cliente bajo una arquitectura de conocimiento cero.

La integración con Active Directory y LDAP automatiza el aprovisionamiento y desaprovisionamiento de usuarios, de modo que el acceso se revoca en el momento en que un empleado se va. Cada acceso, modificación y evento de uso compartido de credenciales se registra en un registro de auditoría a prueba de manipulaciones — abordando directamente los requisitos de amenazas internas y auditorías de cumplimiento. Passwork posee la certificación ISO/IEC 27001, lo que confirma que su gestión de seguridad de la información cumple con los estándares internacionales.

Gestionar credenciales compartidas entre equipos sin una bóveda estructurada es uno de los caminos más rápidos hacia una filtración. Vea cómo Passwork gestiona las contraseñas empresariales → passwork.pro

2. Implemente la gestión de acceso privilegiado (PAM)

La gestión de acceso privilegiado (PAM) es un marco de seguridad que controla, monitorea y audita el acceso a cuentas con permisos elevados del sistema — las credenciales que, si se comprometen, dan a un atacante control administrativo sobre su infraestructura.

PAM gobierna el acceso a objetivos de alto valor: controladores de dominio, consolas en la nube, servidores de bases de datos e infraestructura de red. Más allá del control de acceso, aplica seguridad adicional a nivel de sesión: grabación de actividad, auditoría de comandos y aprovisionamiento de acceso mediante mecanismos Just-In-Time (JIT). JIT significa que los derechos de administrador se otorgan por una ventana definida y se revocan automáticamente — eliminando los privilegios permanentes que los atacantes pueden explotar después del compromiso inicial.

El principio de mínimo privilegio es la base operativa: cada usuario, cuenta de servicio y aplicación recibe el acceso mínimo requerido para su función, y nada más.

La aplicación del mínimo privilegio comienza a nivel de credenciales. El modelo de acceso basado en roles de Passwork permite a los administradores asignar permisos granulares por usuario o grupo — controlando exactamente quién puede ver, copiar o modificar credenciales específicas.

Cada rol es completamente configurable: en lugar de elegir entre acceso de administrador completo y ninguno, puede delimitar permisos a funciones específicas — gestión de usuarios, configuración de LDAP, registros de auditoría o configuraciones de bóvedas — independientemente unas de otras.

3. Adopte una arquitectura Zero Trust

Zero Trust es un modelo de seguridad basado en la suposición de que ningún usuario, dispositivo o segmento de red debe ser confiable por defecto — independientemente de si la solicitud se origina dentro o fuera del perímetro corporativo. El acceso se otorga solo después de la verificación continua de identidad, estado del dispositivo y contexto de comportamiento.

El modelo se basa en tres principios fundamentales:

• Verificar explícitamente — cada solicitud de acceso se autentica y autoriza basándose en todos los puntos de datos disponibles: identidad, estado del dispositivo, ubicación y contexto de comportamiento.
• Usar acceso de mínimo privilegio — los usuarios y sistemas reciben solo los permisos requeridos para su tarea actual, limitando el radio de impacto de cualquier compromiso.
• Asumir la brecha — la arquitectura está diseñada como si un atacante ya estuviera dentro. La microsegmentación, la inspección de tráfico cifrado y el monitoreo continuo contienen el movimiento lateral antes de que escale.

Esta arquitectura aborda directamente el movimiento lateral. Cuando un atacante compromete un endpoint o cuenta, la microsegmentación de Zero Trust y las verificaciones continuas de autenticación evitan que pivoten hacia sistemas adyacentes.

Zero Trust es una filosofía de diseño implementada a través de proveedores de identidad, segmentación de red y puntos de aplicación de políticas — no es un producto único o solución de un proveedor. NIST SP 800-207 proporciona el marco autorizado para la implementación.

4. Actualice a detección y respuesta de endpoints (EDR)

La detección y respuesta de endpoints (EDR) es una tecnología de seguridad que monitorea continuamente la actividad de los endpoints — procesos, conexiones de red, cambios en el sistema de archivos y comportamiento del usuario — y activa respuestas automatizadas cuando se detectan patrones anómalos.

EDR reemplaza el modelo de firma estática con monitoreo de comportamiento. En lugar de preguntar «¿coincide este archivo con una amenaza conocida?», EDR pregunta «¿se comporta este proceso como un ataque?»

Esa distinción detecta malware sin archivos, herramientas de volcado de credenciales y actividad de preparación de ransomware antes de que se complete la ejecución. Las soluciones EDR mantienen un registro continuo de telemetría de la actividad de los endpoints, permitiendo la reconstrucción forense después de un incidente — crítico tanto para la contención como para los informes de cumplimiento.

El ransomware estuvo presente en el 44% de las filtraciones en 2025, frente al 32% del año anterior. EDR con capacidades de respuesta automatizada — aislando un endpoint en el momento en que se detecta un comportamiento anómalo — es ahora un control básico para cualquier organización que maneje datos sensibles.

Soluciones EDR en la práctica

• CrowdStrike Falcon — agente nativo en la nube con detección de comportamiento en tiempo real, contención automatizada e integración de inteligencia de amenazas
• SentinelOne Singularity Endpoint — respuesta autónoma sin dependencia de la nube; incluye capacidad de reversión para archivos afectados por ransomware
• Microsoft Defender for Endpoint — profundamente integrado con el ecosistema de Microsoft; cubre Windows, macOS, Linux, iOS y Android
• Palo Alto Networks Cortex XDR — extiende la telemetría de endpoints a datos de red y nube; detección unificada en toda la superficie de ataque
• Trend Micro Vision One — combina EDR con XDR a través de correo electrónico, endpoints, servidores y cargas de trabajo en la nube
• Sophos Intercept X — incluye módulos anti-exploit y anti-ransomware junto con detección de comportamiento; disponible como servicio gestionado
• Cisco Secure Endpoint — se integra con la pila de seguridad más amplia de Cisco; fuerte en búsqueda de amenazas y análisis retrospectivo

5. Implemente prevención de pérdida de datos (DLP) y cifrado

La prevención de pérdida de datos (DLP) es un conjunto de tecnologías y políticas que detectan, monitorean y restringen el movimiento de datos sensibles a través de endpoints, redes y entornos en la nube — previniendo el acceso, transferencia o exfiltración no autorizados antes de que se confirme una filtración.

Las herramientas DLP monitorean y controlan el movimiento de datos sensibles: PII, registros financieros, código fuente e información regulada. Aplican políticas que bloquean cargas no autorizadas al almacenamiento en la nube, previenen la exfiltración por correo electrónico y señalan transferencias masivas de datos anómalas.

Herramientas DLP en la práctica

El mercado ofrece soluciones en tres modelos de implementación — endpoint, red y nube — a menudo combinados dentro de una sola plataforma:

DLP de endpoint

• Microsoft Purview DLP — integración nativa con Microsoft 365 y endpoints de Windows; cubre correo electrónico, Teams, SharePoint y actividad de archivos locales
• Forcepoint DLP — detección basada en comportamiento con inspección profunda de contenido a través de endpoints y canales web
• Digital Guardian (Fortra) — agente de endpoint granular con registro a nivel forense; fuerte cobertura para propiedad intelectual

DLP de red y nube

• Netskope DLP — nativo en la nube; diseñado para inspección de tráfico SaaS, IaaS y web
• Symantec DLP (Broadcom) — cubre red, endpoint y almacenamiento en la nube con descubrimiento y clasificación de datos
• Palo Alto Networks Enterprise DLP — integrado en el NGFW y la pila Prisma SASE; no requiere agente separado
• Varonis — mapea datos sensibles a través de recursos compartidos de archivos, almacenamiento en la nube y correo electrónico; incluye detección de anomalías en el comportamiento del usuario

El cifrado es el control complementario. Los datos cifrados en reposo y en tránsito permanecen ilegibles incluso si se exfiltran. El cifrado de disco completo en endpoints, TLS 1.3 para datos en tránsito y copias de seguridad cifradas almacenadas fuera de línea forman la línea base. Para industrias reguladas, el cifrado no es opcional — el Artículo 21 de NIS2 y el Artículo 32 del GDPR lo mencionan como una medida técnica apropiada.

6. Gestione el riesgo de terceros y cadena de suministro

El riesgo de terceros es la exposición que entra en su entorno a través de proveedores, contratistas y dependencias de software — entidades fuera de su control directo que, sin embargo, tienen acceso a sus sistemas, datos o código fuente. La participación de terceros en las filtraciones se duplicó año tras año, según el DBIR 2025 de Verizon.

La gestión de riesgo de proveedores requiere más que cuestionarios anuales. Los controles efectivos incluyen:

• Limitar el acceso de terceros solo a los sistemas que necesitan
• Requerir MFA para todas las cuentas externas
• Monitorear la actividad de sesión de terceros
• Incluir requisitos de seguridad en los acuerdos contractuales

Los ataques a la cadena de suministro son un vector distinto y más difícil de detectar: el código malicioso se inyecta en el software antes de que llegue a usted — a través de un pipeline de compilación comprometido, un repositorio de paquetes manipulado o una actualización de proveedor secuestrada. Para cuando la carga útil llega, ya parece legítima. Dos incidentes de principios de 2026 ilustran el rango de exposición:

• Trivy (marzo 2026). El escáner de vulnerabilidades de Aqua Security fue comprometido a través de sus imágenes Docker, entregando una carga útil de robo de información a equipos que tenían toda la razón para confiar en la herramienta.
• Axios (marzo 2026). Atacantes vinculados al actor de amenazas norcoreano UNC1069 incrustaron un troyano de acceso remoto dentro del paquete npm Axios, ampliamente utilizado, y lo distribuyeron silenciosamente a través de la cadena de dependencias.

En ambos casos, el código malicioso llegó a través de un canal de confianza — antes de que cualquier control interno tuviera la oportunidad de interceptarlo. Una defensa efectiva requiere análisis de composición de software y verificación de integridad para todos los componentes de terceros.

7. Realice formación continua de concienciación en seguridad

El elemento humano estuvo involucrado en el 60% de las filtraciones en 2025. La formación de cumplimiento anual no cambia el comportamiento — produce finalización de casillas de verificación, no concienciación en seguridad.

Los programas efectivos ejecutan campañas de phishing simuladas continuas, calibradas según las técnicas de ataque actuales. Cuando un empleado hace clic en un enlace de phishing simulado, recibe retroalimentación inmediata y contextual — no un recordatorio trimestral.

Las plataformas gamificadas que rastrean la mejora individual a lo largo del tiempo producen reducciones medibles en las tasas de clics. La cultura de seguridad se construye a través de la repetición y la relevancia, no de conferencias anuales.

Cómo los marcos de cumplimiento impactan en la prevención de filtraciones de datos

Los marcos de cumplimiento (GDPR, NIS2, DORA, SOC 2) exigen controles técnicos específicos: registro de acceso, cifrado, procedimientos de respuesta a incidentes y gestión de proveedores. Cumplir con estos requisitos establece una línea base de seguridad.

El cumplimiento define el estándar mínimo aceptable — no el apropiado. Una auditoría SOC 2 Tipo II confirma que los controles existieron y operaron efectivamente durante el período de auditoría; no hace ninguna declaración sobre lo que sucede el día después de que el auditor se va, o si esos controles son suficientes contra su panorama de amenazas real. Las organizaciones que sustituyen el cumplimiento por la estrategia de seguridad tienden a descubrir la diferencia en el peor momento posible.

Use los marcos como un punto de partida estructurado. Construya más allá de ellos basándose en su modelo de amenazas real.

Qué requiere realmente cada marco

La tabla revela un patrón: cada marco cubre el control de acceso y la respuesta a incidentes de alguna forma, pero ninguno prescribe exactamente cómo. Esa brecha de implementación es donde ocurren la mayoría de las filtraciones — no porque el marco estuviera equivocado, sino porque la organización se detuvo en la casilla de verificación.

Los registros de auditoría, controles de acceso basados en roles y certificación ISO 27001 de Passwork apoyan directamente el cumplimiento de los requisitos de GDPR, NIS2 y SOC 2. Explore las características de Passwork relevantes para el cumplimiento → passwork.pro

Desarrollo de un plan de respuesta a incidentes (asumir la brecha)

La prevención nunca es absoluta. El Informe de Costo de una Filtración de Datos 2025 de IBM encontró que el tiempo medio para identificar y contener una filtración es de 241 días. Las organizaciones con un plan de respuesta a incidentes probado contienen las filtraciones significativamente más rápido — y una contención más rápida reduce directamente el costo.

Un plan de RI efectivo define: quién declara un incidente, cómo es la ruta de escalación, cómo se aíslan los sistemas, cuándo se debe notificar a los reguladores y las partes afectadas, y cómo se preserva la evidencia para el análisis forense. El Artículo 33 del GDPR requiere notificación a las autoridades de supervisión dentro de las 72 horas posteriores a tener conocimiento de una filtración — un plazo que es imposible de cumplir sin un proceso predefinido.

Pruebe el plan. Un ejercicio de simulación ejecutado una vez al año revela brechas que ninguna cantidad de documentación puede exponer.

Conclusión

El panorama de amenazas se ha alejado decisivamente de los ataques basados en malware hacia la explotación de identidad, técnicas sin archivos y compromiso de la cadena de suministro. Un producto antivirus basado en firmas no aborda ninguno de estos vectores de manera efectiva.

El modelo de 7 capas anterior — anclado por MFA resistente al phishing, gestión de contraseñas empresariales y arquitectura Zero Trust — refleja cómo funcionan realmente los ataques modernos y dónde los controles tienen el mayor impacto. Cada capa aborda una etapa específica de la cadena de ataque. Juntas, crean una defensa en profundidad que la seguridad perimetral tradicional no puede replicar.

Audite su pila actual contra estas siete capas. Identifique qué controles están ausentes, cuáles están parcialmente implementados y cuáles están mal configurados. Las brechas que encuentre son las brechas que un atacante encontrará primero.

Passwork está disponible como solución autoalojada y en la nube con cifrado AES-256, integración AD/LDAP, registro de auditoría completo y certificación ISO 27001. Pruebe Passwork en su entorno → passwork.pro

Preguntas frecuentes

¿Qué deben buscar las empresas en un gestor de contraseñas empresarial?

Priorice la implementación local o autoalojada para que los datos de credenciales permanezcan dentro de su infraestructura. Las capacidades esenciales incluyen cifrado AES-256 de conocimiento cero, integración con Active Directory y LDAP para aprovisionamiento automatizado de usuarios, registros de auditoría a prueba de manipulaciones y certificación ISO 27001. Passwork cumple con todos estos requisitos y se implementa completamente dentro de su propio entorno.

¿Cuál es la causa más común de una filtración de datos en 2026?

Las credenciales robadas siguen siendo el principal vector de acceso inicial. El DBIR 2025 de Verizon encontró que las credenciales comprometidas estuvieron involucradas en aproximadamente el 30% de las filtraciones. Los atacantes las obtienen mediante phishing, bases de datos filtradas o proveedores comprometidos — luego se autentican como usuarios legítimos, evadiendo todas las defensas basadas en firmas.

¿Por qué el antivirus ya no es suficiente para la prevención de filtraciones de datos?

El antivirus depende de la detección basada en firmas: identifica amenazas comparando archivos con una base de datos de malware conocido. Según el Informe Global de Amenazas 2026 de CrowdStrike, el 82% de las detecciones en 2025 no contenían malware — lo que significa que los atacantes utilizaron abuso de credenciales y técnicas sin archivos que no dejan huella binaria para que el antivirus la escanee.

¿Cuál es la diferencia entre un incidente de seguridad y una filtración de datos?

Un incidente de seguridad es cualquier evento que amenaza la confidencialidad, integridad o disponibilidad — la mayoría nunca escala más allá. Una filtración de datos confirmada significa que el acceso no autorizado a datos se establece como un hecho. Esa distinción determina su exposición legal: el Artículo 33 del GDPR y el Artículo 23 de NIS2 requieren notificación a las autoridades de supervisión dentro de las 72 horas posteriores a confirmar una filtración.

¿Qué significa realmente la arquitectura Zero Trust en la práctica?

Zero Trust significa que ningún usuario, dispositivo o segmento de red es confiable por defecto — independientemente de si la solicitud se origina dentro o fuera del perímetro corporativo. Cada solicitud de acceso se verifica contra identidad, estado del dispositivo y contexto de comportamiento. La microsegmentación limita el movimiento lateral si una cuenta o endpoint se ve comprometido. NIST SP 800-207 proporciona el marco de implementación autorizado.

¿Qué es un ataque a la cadena de suministro y cómo difiere de una filtración de proveedor estándar?

Un ataque a la cadena de suministro inyecta código malicioso en el software antes de que llegue al usuario final — a través de un pipeline de compilación comprometido, un repositorio de paquetes manipulado o una actualización secuestrada. A diferencia de una filtración de proveedor, donde el acceso del atacante es la amenaza, un ataque a la cadena de suministro convierte el software en un arma. Para cuando la carga útil llega, ya parece legítima.

¿Cuál es el tiempo medio para detectar y contener una filtración de datos?

Según el Informe de Costo de una Filtración de Datos 2025 de IBM, el tiempo medio para identificar y contener una filtración es de 241 días. Las organizaciones con un plan de respuesta a incidentes probado contienen las filtraciones significativamente más rápido. Esa diferencia de velocidad reduce directamente la exposición financiera y regulatoria — incluyendo la ventana de notificación de 72 horas requerida bajo el Artículo 33 del GDPR.

¿Qué debe incluir un gestor de contraseñas empresarial para apoyar el cumplimiento?

Implementación local para que los datos de credenciales permanezcan dentro de su infraestructura, cifrado AES-256 de conocimiento cero, integración con Active Directory y LDAP para aprovisionamiento y desaprovisionamiento automatizados, registros de auditoría a prueba de manipulaciones y certificación ISO 27001. Estas capacidades abordan directamente los requisitos de control de acceso y auditoría bajo GDPR, NIS2 y SOC 2. Passwork cumple con todos estos requisitos y se implementa completamente dentro de su propio entorno.

¿Cómo reduce la gestión de acceso privilegiado el riesgo de filtración?

PAM controla el acceso a cuentas de alto valor — controladores de dominio, consolas en la nube, servidores de bases de datos — y aplica aprovisionamiento Just-In-Time: los derechos de administrador se otorgan por una ventana definida y se revocan automáticamente. Esto elimina los privilegios permanentes que los atacantes explotan después del compromiso inicial. El principio de mínimo privilegio limita el radio de impacto de cualquier cuenta comprometida individual.

Actualización de ciberseguridad de la UE primavera 2026: Qué cambió

La primavera de 2026 trajo la filtración institucional más significativa de la UE, sus primeras sanciones cibernéticas del año y cuatro regulaciones importantes de ciberseguridad aplicándose simultáneamente. NIS2, DORA, CRA y CSA2 ahora establecen plazos firmes — y sanciones reales. Esto es lo que cambió, quién se ve afectado y qué hacer.

Passwork BlogAlex Muntyan

Requisitos de contraseñas de NIS2: Qué deben hacer las empresas europeas en 2026

Las brechas de credenciales son el principal punto de fallo en las auditorías NIS2 en 2026. Esta guía cubre los requisitos de contraseñas del Artículo 21, la alineación con NIST SP 800-63B, los pasos de fortalecimiento de AD y la evidencia de auditoría que los reguladores solicitan primero.

Passwork BlogAlex Muntyan

Modelos de implementación de gestores de contraseñas: Nube, autoalojado e híbrido

Elegir dónde ejecutar su gestor de contraseñas importa tanto como elegir cuál. Esta guía desglosa la implementación en la nube, autoalojada e híbrida — con una matriz de cumplimiento para GDPR, HIPAA y NIS2, y una visión clara de las compensaciones que conlleva cada modelo.

Passwork BlogAlex Muntyan