Cybersecurity

Credentials move between people every day. A developer gets a database credential via Slack. A contractor receives an admin account through email. Finance keeps the payroll system login in a shared spreadsheet. Each handoff is a breach waiting to happen. In 2026, that wait has a measurable value, and often counted in minutes.

This article breaks down exactly what's at stake in 2026, why employees keep doing it anyway, and how to fix it without making security feel like punishment.

Key takeaways

• Shared credentials are an access governance problem, not a user behavior problem. Policies that rely on employees doing the right thing fail at scale. Architecture that makes the right thing the easiest thing does not.
• Vault-mediated access eliminates the raw credential handoff. Users get into systems through the vault. They never see the password. Every action is logged and tied to an individual identity.
• RBAC at the group level is the only model that scales. Managing permissions per individual breaks down past a dozen people. Group-based inheritance means one change covers everyone on the team.
• MFA on privileged accounts limits blast radius when credentials are compromised. Credential compromise is a matter of when, not if. A second factor means a stolen password alone is not enough.
• Audit trails need to exist before the incident, not after. Incident response without logs is reconstruction from memory. Build the trail now.
• Legacy systems are a constraint, not an excuse. A service account stored in a vault with mediated access is not perfect, but it is documented, auditable, and revocable.
• Shadow IT is a friction signal. If employees are using personal tools for work credentials, the corporate vault is harder to use than it should be. Fix the onboarding, not the policy.
• Automate offboarding at the directory level. Every day a former employee retains access is an open liability. AD/LDAP integration closes it without manual intervention.

The dangers of insecure password sharing in 2026

Insecure password sharing exposes organizations to credential stuffing, account takeover (ATO), and insider threats — all of which have become significantly easier to execute as AI-enhanced attack tooling has matured. The core problem is that shared credentials destroy individual accountability: when five people use the same login, no audit trail tells you which one caused the breach.

The threat landscape has shifted materially as GPU hardware and cracking tooling have both advanced. Hive Systems' 2025 Password Table shows that short passwords remain dangerously exposed regardless of complexity. NIST SP 800-63B (updated August 2025) reflects the same reality: the guidelines now set a minimum floor of 15 characters and explicitly drop mandatory complexity rules in favor of length, recognizing that brute-force resistance scales exponentially with length, not with character substitution.

Time it takes a hacker to bruteforce your password in 2025

Credential stuffing has scaled with this tooling. Attackers feed leaked credential databases — billions of username/password pairs are available on dark web markets — into automated tools that test them across hundreds of services simultaneously. Shared passwords amplify the blast radius: one leaked credential can compromise every system where that password was reused.

Brute-force attacks have similarly benefited from AI. Modern cracking algorithms use neural networks to model human substitution patterns. Replacing a with @ or appending ! to a dictionary word no longer provides meaningful resistance. The attacker's model already accounts for it.

Insider threats are the less-discussed risk. When credentials are shared informally (over chat, email, or verbally) there is no record of who holds them at any given time. A disgruntled employee, a contractor whose engagement ended, or a former colleague who was never properly offboarded can retain access indefinitely. Without individual accounts and audit trails, you cannot detect the access, let alone attribute it.

How insecure sharing maps to specific attack vectors

Beyond convenience: Why employees still share passwords (and the real cost)

Employees share work passwords for the same mundane reasons they always have: emergencies, shared team accounts, delegated tasks. Sharing is the rational response when the secure path is slower than the task itself. When the formal access request process takes longer, people skip it.

That friction has a name. A 2025 peer-reviewed study "Digital detox: Exploring the impact of cybersecurity fatigue on employee productivity and mental health" published in Discover Mental Health (PMC/PubMed) surveyed 351 employees across IT, finance, healthcare, and education and found that cybersecurity fatigue (defined as mental and emotional exhaustion from repeated security demands) directly contributes to disengagement, reduced compliance, and burnout.

Cybersecurity fatigue — a state of mental and emotional exhaustion from repeated exposure to security demands — manifests through cognitive overload, stress, and disengagement, significantly impacting employee productivity and organizational resilience.

When mandatory rotation cycles, authentication prompts, and access request queues pile up, security stops feeling like protection and starts feeling like friction. The workaround becomes obvious: share the credential directly and get the work done.

This is a design failure, not a discipline problem. Proofpoint's research on human-centric threats consistently shows that employees bypass controls because the secure path takes longer than the insecure one. The credential gets shared, the task gets done, and no one thinks much about it.

Until something goes wrong. Verizon's 2025 DBIR found that credentials remain one of the most exploited entry points across industries. IBM's 2025 Cost of a Data Breach Report puts a number on what that means in practice: breaches involving compromised credentials take an average of 246 days to identify and contain — over eight months of undetected exposure — and carry an average total cost of $4.57M.

The accountability gap is what makes this hard to recover from. Once a credential is shared, you lose the ability to tie actions to individuals. That matters for incident response, for compliance audits, and for the basic question of "who changed this configuration at 2 a.m. on Saturday?" Shared credentials don't just create risk — they destroy the audit trail you need to understand what happened after the fact.

The ripple effect: Business impacts of insecure credential sharing

Insecure credential sharing creates financial, legal, and reputational exposure that extends well beyond the initial breach. Credential compromise is the dominant attack vector across industries. The breach itself is rarely the most expensive part. Incident response, regulatory scrutiny, and the audit trail gaps left by shared accounts compound the damage long after the initial intrusion.

The compliance dimension is specific and consequential. GDPR Article 32 requires "appropriate technical and organisational measures" to protect personal data — and shared credentials with no audit trail fail that standard directly. SOC 2 Trust Services Criteria CC6.1 requires logical access controls tied to individual identities. HIPAA's Technical Safeguard requirements under 45 CFR §164.312(a)(2)(i) mandate unique user identification. Sharing a single login across a team violates all three frameworks simultaneously.

Reputational damage follows a different timeline than financial damage. The breach costs are immediate. The reputational costs compound. Customers, partners, and regulators all factor breach history into their risk assessments. A credential-based breach that could have been prevented with basic access governance is particularly difficult to explain to a board or a regulator.

The offboarding scenario illustrates the risk concretely. An employee leaves with access to five shared accounts. Because credentials were never formally assigned, no one knows which systems they could reach. Revoking access means:

1. Identifying every shared password the employee knew
2. Finding every system where that password was used
3. Notifying every team that depends on those credentials
4. Rotating all of them without breaking anything in production

In practice, many organizations skip this entirely. That's how former employees retain active access for months.

Implementing frictionless governance: Solutions for secure password sharing

Frictionless governance is a credential management model that eliminates insecure sharing by making secure access faster than the workaround. It rests on three components: individual accountability (every user has their own identity), RBAC (permissions assigned to roles, not individuals), and audit logging (every access event is recorded and attributable).

The practical implementation requires four things:

1. A password vault with role-based access control. Users access credentials through the vault, not by receiving the password directly. RBAC (role-based access control) means permissions are inherited from group membership — add someone to the DevOps group, they get DevOps vault access. Remove them, access is revoked immediately.
2. End-to-end encryption with a zero-knowledge architecture. Credentials are encrypted client-side before leaving the user's device. The server stores ciphertext. Even a compromised server exposes nothing usable. AES-256 is the current standard for this.
3. MFA on every account. Multi-factor authentication (MFA) doesn't prevent credential sharing, but it limits the damage when a shared credential is compromised. An attacker with a stolen password still needs the second factor. For privileged accounts, hardware tokens or FIDO2 keys are preferable.
4. Passphrases over complex short passwords. A 16-character passphrase — four random words — is both more resistant to brute-force attacks and easier for users to remember than P@ssw0rd!2. Length provides exponential resistance; complexity provides linear resistance.

Identity and Access Management (IAM) integration extends this model to the directory level. When Passwork is connected to AD/LDAP, user provisioning and deprovisioning happen automatically. A user disabled in Active Directory loses vault access without any manual intervention. That's the offboarding problem solved at the infrastructure level.

Addressing legacy systems and shadow IT

Legacy systems are the most common reason teams justify shared credentials. A system built in 2008 may have no concept of individual user accounts — it has one admin login, and everyone who needs access uses it. This is a real constraint, not a policy failure.

The practical solution is a service account pattern with vault-mediated access. The shared credential lives in the vault, encrypted. Users access the system through the vault's session management — they never see the raw password. Access is logged at the vault level even if the target system has no native audit capability. When someone leaves, you rotate the credential in the vault. The system itself doesn't need to change.

One-time secrets and secure links address the adjacent problem: occasionally, a credential genuinely needs to be transmitted to someone outside your vault. A one-time secret link expires after a single view or after a defined time window. It's not a permanent solution, but it's categorically safer than a Slack message that sits in chat history indefinitely.

Shadow IT — employees using personal credential managers for work passwords — is harder to detect and carries its own risks. A personal vault has no organizational audit trail, no offboarding hook, and no guarantee of encryption standards. The fix is organizational: make the corporate vault easier to use than the personal one. If onboarding takes five minutes and the browser extension autofills credentials, most employees will use it. Friction is the enemy of adoption.

How Passwork makes secure sharing the default

The issues described above (shared credentials, broken offboarding, missing audit trails, legacy system constraints) are exactly what Passwork is built to handle. Here's how each maps to a specific capability.

• Shared credentials without accountability. Passwork replaces direct password handoffs with vault-mediated access. Users interact with systems through the vault. They never receive the raw credential. Every access event is logged, timestamped, and tied to an individual identity.
• Broken offboarding. Passwork integrates with AD/LDAP. When a user is disabled in Active Directory, vault access is revoked automatically. No manual rotation, no guesswork about which accounts they could reach.
• No audit trail. Every action in Passwork is recorded. When an incident occurs, you have a complete, attributable log. Not "someone on the DevOps team," but a specific user at a specific time.
• Legacy systems with shared logins. Passwork supports a service account pattern: the credential lives in the vault, encrypted. Users access the system through vault-mediated sessions and never see the password. The target system doesn't need to change.
• Occasional external sharing. For credentials that genuinely need to leave the vault — a contractor, a one-time handoff — Passwork generates one-time secret links that expire after a single view or a defined time window. Safer than a Slack message by design.
• Compliance gaps. Role-based access control, individual identity binding, and a full audit log directly support GDPR Article 32, SOC 2 CC6.1, and HIPAA §164.312 requirements. The audit trail you need for a regulator is the same one you need for incident response.

Moving from insecure to secure sharing: A practical 6-step migration

Most teams fail because the transition from informal sharing to structured access feels like a project no one has time for. This guide breaks it into six steps that can be executed incrementally, educing exposure at each stage without disrupting operations.

1. Audit what you're actually sharing. Before you can fix the problem, you need to know its scope. Survey your teams and document every shared credential: what system it accesses, who holds it, and how it was distributed. Spreadsheets, Slack history, and email threads are the most common sources. Don't skip this step. You cannot revoke access you don't know exists.
2. Classify by risk. Not all shared credentials carry equal risk. Prioritize by blast radius: production database credentials and admin accounts first, internal tooling second, low-sensitivity shared accounts last. This gives you a migration sequence that reduces exposure quickly without requiring you to move everything at once.
3. Deploy the vault and onboard your team. Set up Passwork and connect it to your directory service (AD/LDAP). Create role-based groups that mirror your existing team structure. Onboarding works best when the vault is already populated before you ask people to use it. Import existing credentials into the appropriate vaults before the rollout meeting.
4. Migrate credentials in priority order. Move high-risk credentials into the vault first. For each one: store it in Passwork, assign access to the relevant role group, and immediately stop distributing the raw password. For legacy systems that can't support individual accounts, implement the service account pattern — credential in the vault, access mediated through Passwork.
5. Enforce the new process and retire the old one. Block the informal channels. This means a clear policy: no credentials in Slack, email, or shared documents. For external sharing, use Passwork's one-time secret links instead of direct messages. The policy only works if the vault is already easier to use than the workaround — which is why steps 3 and 4 come first.
6. Audit, rotate, and maintain. Once credentials are in the vault, use Passwork's security audit tools to identify weak passwords, flag credentials that haven't been rotated, and review access logs for anomalies. Set a rotation schedule for privileged accounts. Review role group memberships quarterly — or trigger a review automatically on any organizational change.

The full migration for a 50-person team typically takes one to two weeks when executed in this order. The audit in step 1 usually takes the longest.

Key takeaways for CISOs and IT leaders

The core shift required is treating credential sharing as an access governance problem, not a user behavior problem. Policies that rely on employees "doing the right thing" will fail at scale. Architecture that makes the right thing the easy thing will not.

• Replace shared credentials with vault-mediated access. Users get access to systems through the vault, not through the password itself.
• Implement RBAC at the group level. Individual permission management doesn't scale; group-based inheritance does.
• Enforce MFA on all privileged accounts. Credential compromise is a matter of when, not if — MFA limits the damage.
• Establish audit trails before you need them. Incident response without logs is guesswork.
• Address legacy systems explicitly. A service account in a vault is not a perfect solution, but it's a documented, auditable one.
• Treat shadow IT as a design signal. If employees are using personal tools forwork credentials, your corporate tooling has a friction problem.
• Automate offboarding. Every day a former employee retains access is a liability. Directory integration eliminates the manual step.

Conclusion

Shared credentials have always been a liability. In 2026, with AI-enhanced cracking tools and breach costs averaging $4.57 million per incident, they're an indefensible one.

The fix doesn't require asking employees to be more disciplined. It requires building systems where the secure path is also the faster one. When vault access takes less time than a Slack message, people use the vault. When offboarding triggers automatic revocation, former employees don't retain access for months. When every action is logged, incident response stops being guesswork.

Start with your highest-risk shared credentials: admin accounts, production database access, anything touching regulated data. Move those into a vault with role-based access controls first. Then work outward, in priority order, using the six-step migration above.

Frequently asked questions

Why is insecure password sharing a significant security risk in 2026?

AI-enhanced cracking tools can break an 8-character password in under 12 minutes on consumer hardware (Hive Systems, 2025), and credential stuffing attacks run at industrial scale using billions of leaked pairs. Shared passwords eliminate individual accountability — when a breach occurs, there is no audit trail to identify who had access or when.

How can organizations securely manage passwords for legacy systems that only support a single shared login?

Use a service account pattern: store the shared credential in an encrypted vault and grant users vault-mediated access rather than the raw password. Access is logged at the vault level even when the target system has no native audit capability. When personnel changes occur, rotate the credential in the vault — the system itself does not need to change.

What is frictionless governance in the context of credential management?

Frictionless governance is a credential management model that makes secure access faster than the workaround. It combines individual user identities, RBAC for group-based permission inheritance, and full audit logging — so employees never need to share a raw password to get their work done.

How does shadow IT create credential security risks?

When employees store work passwords in personal credential managers, the organization loses audit trails, offboarding hooks, and control over encryption standards. A departing employee's personal vault retains every credential they saved there. The fix is making the corporate vault easier to use than the personal alternative — faster onboarding, browser autofill, mobile access.

Which compliance frameworks are violated by shared credentials?

Shared credentials without individual attribution violate GDPR Article 32 (appropriate technical measures for data protection), SOC 2 Trust Services Criteria CC6.1 (logical access controls tied to individual identities), and HIPAA 45 CFR §164.312(a)(2)(i) (unique user identification). All three require the ability to tie access events to a specific person.

How long does it typically take to detect a credential-based breach?

According to IBM's 2025 Cost of a Data Breach Report, breaches involving compromised credentials take an average of 246 days to identify and contain. Shared accounts make this worse: without individual behavioral baselines, anomalous activity blends in with normal multi-user traffic and rarely triggers alerts.

Shadow IT vs Shadow AI: Why AI is the bigger threat

Employees are using AI tools you didn’t approve, on accounts you can’t monitor, with data you can’t recover. Here’s what the risk actually looks like and what governance needs to address.

Passwork BlogAlex Muntyan

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

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

Shadow IT bezeichnet die Nutzung nicht genehmigter Technologie ohne Wissen oder Aufsicht der IT-Abteilung. Shadow AI ist die Nutzung nicht genehmigter KI-Tools, Modelle, Funktionen und Workflows — und sie ist oft risikoreicher, da sensible Daten verarbeitet, Entscheidungen beeinflusst, Ausgaben generiert und mit Anmeldedaten oder Systemen vollständig außerhalb der normalen Governance interagiert werden kann.

Das Ausmaß des Problems zeigt sich bereits in Daten zu Sicherheitsvorfällen:

• Jede fünfte Organisation meldete einen Sicherheitsvorfall aufgrund von Shadow AI, und eine hohe Shadow-AI-Nutzung erhöhte die durchschnittlichen Kosten eines Vorfalls um 670.000 US-Dollar — IBM's 2025 Cost of a Data Breach Report.
• Mehr als die Hälfte der Führungskräfte (58 %) gab an, dass ihre Organisation im vergangenen Jahr einen KI-bezogenen Sicherheitsvorfall oder einen Beinahe-Vorfall erlebt hat — Okta's AI Agents at Work 2026 Survey.
• Über 1,27 Millionen geleakte Secrets von KI-Diensten wurden auf öffentlichen GitHub-Repositories gefunden. Das sind 81 % mehr als im Vorjahr. Acht der zehn am schnellsten wachsenden Typen geleakter Secrets stehen im Zusammenhang mit KI-Diensten — GitGuardian's State of Secrets Sprawl 2026.
• Nur 5 % der Unternehmen haben vollständige Transparenz darüber, welche KI-Tools Mitarbeitende tatsächlich nutzen, und 78 % bestätigten entweder einen KI-bezogenen Sicherheitsvorfall oder konnten einen solchen nicht ausschließen — Check Point's 2026 Cloud Security Report.
• 92 % der Sicherheitsexperten sind besorgt über KI-Agenten und deren Auswirkungen auf die Sicherheit, doch nur 37 % der Organisationen haben eine formale KI-Richtlinie implementiert — Darktrace's State of AI Cybersecurity 2026.

Regierungen haben reagiert. Der EU AI Act wird nun aktiv durchgesetzt, mit Strafen für die nicht konforme Nutzung von Hochrisiko-KI-Systemen von bis zu 15 Millionen Euro oder 3 % des weltweiten Jahresumsatzes.

In den Vereinigten Staaten unterzeichnete Präsident Trump am 2. Juni 2026 eine Executive Order — „Promoting Advanced Artificial Intelligence Innovation and Security" — die CISA anweist, KI-gestützte Cyberabwehr für Bundessysteme und Betreiber kritischer Infrastrukturen auszubauen, und einen freiwilligen Rahmen für die Bewertung von Frontier-KI-Modellen vor der öffentlichen Freigabe etabliert. Die Verordnung reguliert nicht, wie Mitarbeitende KI in Unternehmen nutzen, signalisiert aber deutlich, dass KI-Sicherheit nun eine bundesweite Priorität ist und Organisationen, die kritische Infrastrukturen betreiben, bereits in den Geltungsbereich fallen.

Die Tools werden genutzt. Die Daten bewegen sich. Wohin? Die meisten Organisationen wissen es schlichtweg nicht.

Wichtige Erkenntnisse

• Shadow AI ist eine eigenständige Risikokategorie, nicht nur Shadow IT mit KI-Branding. Nicht genehmigte KI-Tools, Modelle und Agenten verarbeiten Daten, beeinflussen Entscheidungen und interagieren mit Anmeldedaten vollständig außerhalb der normalen Governance, während traditionelle Shadow IT nur unverwaltete Technologie-Wildwuchs verursacht.
• Die Daten zu Sicherheitsvorfällen sind bereits sichtbar. Jede fünfte Organisation meldete einen Sicherheitsvorfall aufgrund von Shadow AI. Die meisten Unternehmen haben kein klares Bild davon, welche KI-Tools Mitarbeitende tatsächlich nutzen.
• Persönliche Accounts sind die primäre Kontrolllücke. Die meiste KI-Tool-Nutzung erfolgt über persönliche Accounts, die SSO, DLP und zentralisiertes Logging umgehen, ohne Audit-Trail und ohne vertragliche Grundlage für Datenlöschung.
• KI-Agenten verlagern das Problem von der Dateneingabe zu Zugriff und Aktion. Agenten können Dateien lesen, APIs aufrufen und Code über delegierte OAuth-Berechtigungen ändern, und diese Aktionen werden möglicherweise nirgendwo protokolliert, wo das Sicherheitsteam Zugriff hat.
• Zugangsdaten-Exposition ist die schwerwiegendste Lücke. Logs, Code-Snippets, Umgebungsdateien und Browser-Autofill-Daten enthalten häufig Passwörter, API-Schlüssel oder Token. Werden diese in ein KI-Tool eingefügt, entsteht ein potenzieller dauerhafter Zugriffspfad — nicht nur ein Datenexpositions-Ereignis.
• Pauschale Verbote verlagern Shadow AI, sie eliminieren sie nicht. Mitarbeitende weichen auf persönliche Geräte und alternative Tools mit weniger Audit-Signalen aus. Effektive Governance bietet genehmigte Alternativen und überwacht die Bewegung sensibler Daten.
• Regulierungsbehörden haben reagiert. Der EU AI Act wird aktiv durchgesetzt, mit Strafen von bis zu 15 Millionen Euro oder 3 % des weltweiten Jahresumsatzes. Eine am 2. Juni 2026 unterzeichnete US-Executive-Order signalisiert, dass KI-Sicherheit nun eine bundesweite Priorität ist.
• Governance erfordert fünf spezifische Maßnahmen. Datenklassifizierung, Bereitstellung genehmigter Tools, Output-Governance, Überprüfung von Agenten-Berechtigungen und Secrets-Management. Bestehende Shadow-IT-Kontrollen sind notwendig, aber nicht ausreichend.

Was ist Shadow IT?

Shadow IT bezeichnet jede Technologie (Software, Hardware, Cloud-Dienste, SaaS-Anwendungen, Skripte oder Infrastruktur), die innerhalb einer Organisation ohne IT-Genehmigung, Wissen oder Aufsicht genutzt wird. Der Begriff umfasst ein breites Spektrum an Verhaltensweisen: Ein Mitarbeitender nutzt einen persönlichen Cloud-Speicher zum Teilen von Dateien, ein Team richtet ein nicht genehmigtes Projektmanagement-Tool ein, ein Entwickler führt Skripte auf unverwalteter Infrastruktur aus oder eine Abteilung abonniert ein SaaS-Produkt außerhalb des Beschaffungsprozesses.

Das Kernproblem bei Shadow IT ist der Verlust der Governance. Wenn die IT-Abteilung nicht weiß, dass ein Tool existiert, kann sie keine Zugriffskontrollen durchsetzen, keine Data Loss Prevention (DLP)-Richtlinien anwenden, den Datenlebenszyklus nicht verwalten oder den Zugriff entziehen, wenn ein Mitarbeitender das Unternehmen verlässt. Auch Lizenzierung, Compliance und Anforderungen an Audit-Trails fallen durch das Raster.

Shadow IT folgt einem vorhersehbaren Pfad. Ein Mitarbeitender benötigt ein Tool — schnellere Dateifreigabe, einen Projekt-Tracker, ein Skript, das auf etwas anderem als dem genehmigten Stack läuft. Der offizielle Prozess ist zu langsam oder das Tool ist einfach nicht verfügbar, also findet er eine eigene Lösung. Die IT erfährt davon nie.

Häufige Shadow-IT-Beispiele umfassen:

• Persönlicher Cloud-Speicher (Consumer-Accounts für Arbeitsdateien genutzt)
• Nicht genehmigte Messaging- und Collaboration-Apps
• Browser-Erweiterungen mit umfassenden Datenberechtigungen
• Unverwaltete SaaS-Abonnements, die vom Team-Budget bezahlt werden
• Von Entwicklern erstellte Skripte und Automatisierungstools, die außerhalb der IT-Sichtbarkeit laufen
• Consumer-Geräte, die mit Unternehmensnetzwerken verbunden sind

Shadow IT ist nicht immer böswillig. Das meiste beginnt als Produktivitäts-Workaround — ein Team benötigte ein Tool, die Beschaffung war langsam, und jemand fand eine kostenlose Alternative. Dieser Kontext ist wichtig für die Governance: Verbote ohne Ersatz funktionieren selten.

Was ist Shadow AI?

Shadow AI ist die nicht genehmigte Nutzung von KI-Tools, KI-Funktionen, Modellen, Prompts, Agenten und Workflows ohne IT-Genehmigung oder Aufsicht. Sie ist mit Shadow IT verwandt, aber unterschiedlich: Während Shadow IT hauptsächlich unverwalteten Technologie-Wildwuchs verursacht, verursacht Shadow AI unverwaltete Datenverarbeitung, unverwaltete Entscheidungsunterstützung und unverwaltete Aktionen.

Shadow AI umfasst eine breite und schnell wachsende Palette von Verhaltensweisen. Mitarbeitende nutzen öffentliche Large Language Models (LLMs) wie ChatGPT, Claude und Gemini über persönliche Accounts. Entwickler nutzen KI-Coding-Assistenten wie GitHub Copilot oder Cursor außerhalb von Enterprise-Tenants. Teams nutzen KI-Meeting-Assistenten, KI-Browser-Erweiterungen und KI-gestützte SaaS-Funktionen, die nie formal geprüft wurden. Einige Mitarbeitende bauen ihre eigenen KI-Workflows mit Consumer-Automatisierungstools.

Shadow AI folgt demselben Pfad wie Shadow IT, aber die Konsequenzen am Ende sind unterschiedlich. Ein Mitarbeitender muss schneller vorankommen — ein Dokument zusammenfassen, Code generieren, eine Antwort entwerfen. Es gibt kein genehmigtes Tool, oder das genehmigte Tool ist langsamer als das, das er bereits privat nutzt. Also verwendet er seinen eigenen Account, eine Browser-Erweiterung oder eine KI-Funktion, die in ein SaaS-Produkt eingebettet ist, das die IT zwar bereits genehmigt, aber nie geprüft hat.

Häufige Beispiele für Shadow AI in der Praxis:

• Mitarbeitende nutzen ChatGPT, Claude, Gemini oder Perplexity über persönliche Free-Tier-Accounts
• Entwickler nutzen KI-Coding-Assistenten außerhalb der Enterprise-Lizenzkontrolle
• Vertriebs- und Marketing-Teams nutzen KI-Schreibtools, die von der Sicherheitsabteilung nicht geprüft wurden
• HR- und Finanz-Teams nutzen KI, um Dokumente mit regulierten Daten zusammenzufassen
• KI-Meeting-Assistenten zeichnen Anrufe auf und transkribieren sie ohne Enterprise-Aufbewahrungskontrollen
• Browser-basierte KI-Erweiterungen mit Zugriff auf Seiteninhalte, Zwischenablage und Formularfelder
• Von Mitarbeitenden erstellte KI-Agenten, die sich mit SaaS-APIs oder internen Systemen verbinden

Das Ausmaß ist erheblich. Menlo Security's 2025 Report verzeichnete 10,53 Milliarden Besuche auf KI-Websites allein im Januar 2025, gegenüber 7 Milliarden im Februar 2024, wobei 80 % dieses Zugriffs über Browser erfolgten. Shadow AI ist kein Nischenverhalten — es ist die Art und Weise, wie die meisten Mitarbeitenden derzeit KI nutzen.

Shadow IT vs. Shadow AI: Die wichtigsten Unterschiede

Shadow IT und Shadow AI haben dieselbe Grundursache: Mitarbeitende lösen reale Probleme mit Tools, die die IT nicht genehmigt hat. Aber sie erzeugen unterschiedliche Risikoprofile und erfordern unterschiedliche Kontrollen.

Die Behebungslücke ist besonders signifikant. Wenn ein Mitarbeitender ein nicht genehmigtes SaaS-Tool nutzt, kann die IT den Zugriff entziehen und Daten migrieren. Wenn sensible Inhalte in den Workflow eines externen KI-Modells gelangen, ist es erheblich schwieriger, die Löschung zu bestätigen, die Nicht-Aufbewahrung nachzuweisen und den Vorfall einzugrenzen — insbesondere wenn der Zugriff über einen persönlichen Account erfolgte, ohne Enterprise-Audit-Trail.

Warum Shadow AI die größere Bedrohung ist

Shadow AI ist oft gefährlicher als traditionelle Shadow IT, da sie Daten nicht nur speichert oder verschiebt, sondern verarbeitet, generiert und darauf reagiert. Die folgenden fünf Dimensionen erklären, wo sich das Risikomodell ändert. Zusammen bilden sie das, was dieser Artikel als Shadow-AI-Risikomultiplikator bezeichnet.

1. Datenexfiltration erfolgt durch normale Arbeit

Mitarbeitende müssen Daten nicht absichtlich exfiltrieren. Sie fügen E-Mails, Verträge, Tabellen, Quellcode, Support-Tickets, Kundendaten, HR-Informationen und Systemprotokolle als Teil der normalen Arbeit in KI-Tools ein. Jeder Prompt ist ein potenzieller Datentransfer.

Harmonic Security's Analyse von 22.458.240 Enterprise-GenAI-Prompts aus 2025 erkannte 579.113 Fälle von sensiblen Datenexpositionen über 665 KI-Tools. Code, juristische Dokumente und Finanzdaten machten 74,5 % dessen aus, was exponiert wurde. Laut Cyberhaven's 2026 AI Adoption & Risk Report beinhalteten 39,7 % aller KI-Interaktionen sensible Daten, und Mitarbeitende gaben im Durchschnitt alle drei Tage sensible Daten in KI-Tools ein.

Sensible Daten und KI sind jetzt in tägliche Arbeitsabläufe eingebettet, und die Exposition ist nicht gelegentlich.

2. Persönliche Accounts brechen Enterprise-Kontrollen

Ein erheblicher Teil der KI-Nutzung erfolgt über persönliche Accounts statt Enterprise-Tenants. Cyberhavens 2026-Daten zeigten, dass 32,3 % der ChatGPT-Nutzung, 58,2 % der Claude-Nutzung und 60,9 % der Perplexity-Nutzung über persönliche Accounts erfolgte. Menlo Security's 2025 Report ergab, dass 68 % der Mitarbeitenden Free-Tier-KI-Tools über persönliche Accounts nutzten, wobei 57 % sensible Daten eingaben.

Persönliche Accounts umgehen SSO-Durchsetzung, Enterprise-Aufbewahrungsrichtlinien, zentralisiertes Logging, DLP-Kontrollen und Daten-Governance auf Admin-Ebene. Wenn ein Mitarbeitender Claude oder Perplexity über einen persönlichen Account nutzt, hat die Organisation keine Sichtbarkeit darüber, was eingereicht wurde, keinen Audit-Trail und keine vertragliche Grundlage für Datenlöschung oder Nicht-Training-Zusagen.

3. KI kann Entscheidungen beeinflussen, nicht nur Dateien speichern

Shadow IT erzeugt hauptsächlich unverwaltete Datenspeicherung oder -übertragung. Shadow AI tut etwas mehr: Sie fasst zusammen, klassifiziert, bewertet, empfiehlt, generiert Code und entwirft kundenorientierte oder juristische Inhalte. Ein nicht genehmigtes KI-Tool kann eine Geschäftsentscheidung auf Basis ungeprüfter Daten, einer unbekannten Modellversion und Annahmen, die der Benutzer nie untersucht hat, beeinflussen.

Halluzinationen, Modelldrift und Bias in KI-Outputs sind reale Fehlermodi. Wenn das Tool nicht genehmigt und der Output nicht zugeordnet ist, gibt es keine Möglichkeit, die Entscheidungskette im Nachhinein zu prüfen.

4. KI-Agenten erweitern das Problem von Eingabe zu Aktion

KI-Agenten können Dateien lesen, Zwischenablagen nutzen, APIs aufrufen, Nachrichten senden, Code ändern und sich mit SaaS-Systemen verbinden. Viele laufen auf Betriebssystemebene, pflegen persistente Kontextfenster und synchronisieren Daten mit Infrastruktur außerhalb der Aufsicht des Sicherheitsteams.

Dies verlagert Shadow AI von einem Dateneingabe-Problem zu einem Zugriffs-und-Aktions-Problem. Ein Agent mit delegierten OAuth-Berechtigungen oder einem API-Schlüssel kann im Namen eines Benutzers handeln, und diese Aktionen werden möglicherweise nirgendwo protokolliert, wo das Sicherheitsteam Zugriff hat.

5. Credential- und Secrets-Exposition verwandelt KI-Nutzung in Zugriffsrisiko

Logs, Code-Snippets, Umgebungsdateien, Browser-Autofill-Daten und Support-Tickets enthalten häufig Passwörter, API-Schlüssel oder Token. Werden diese in ein KI-Tool eingefügt — oft versehentlich — ist das Ergebnis nicht nur ein Datenexpositions-Ereignis. Es ist ein potenzieller dauerhafter Zugriffspfad.

IBM's 2025 Report ergab, dass 97 % der Organisationen, die über KI-Modelle oder -Anwendungen kompromittiert wurden, keine angemessenen KI-Zugriffskontrollen hatten, was bedeutet, dass die meisten Organisationen, die einen KI-bezogenen Sicherheitsvorfall erlebten, keine wirksame Kontrollschicht implementiert hatten.

Wenn Ihr Team beginnt, Shadow-AI-Exposition zu erfassen, sind Credentials und Secrets oft die schwerwiegendste Lücke. Passwork zentralisiert geteilte Passwörter, API-Schlüssel und Service-Account-Anmeldedaten in einem einzigen verschlüsselten Tresor mit RBAC, LDAP/SSO-Integration und einem vollständigen Audit-Log jedes Zugriffsereignisses. Wenn ein Mitarbeitender das Unternehmen verlässt oder ein KI-Workflow außer Betrieb genommen wird, wird der Zugriff an einem Ort entzogen, nicht über ein Dutzend Tools hinweg nachverfolgt. Passwork kostenlos testen

Praxisbeispiele für Shadow-AI-Risiken

Die folgenden Risikoszenarien sind repräsentativ für das, was Sicherheits- und IT-Teams abteilungsübergreifend erleben. Keines erfordert böswillige Absicht — jedes beginnt mit einem legitimen Produktivitätsziel.

Das Risiko konzentriert sich tendenziell auf eine kleine Anzahl stark genutzter Tools, was für die Governance-Priorisierung nützlich ist. Aber der Long Tail ist dennoch relevant — eine selten genutzte Integration kann dasselbe Credential-Expositionsrisiko bergen wie ein täglich genutzter Assistent.

Warum ein KI-Verbot Shadow AI meist verschlimmert

Ein pauschales Verbot von KI-Tools eliminiert Shadow AI nicht. Es verlagert sie. Mitarbeitende weichen auf persönliche Geräte, persönliche Accounts oder alternative Tools aus, in die die IT weniger Einblick hat. Das Ergebnis ist dieselbe Datenexposition mit weniger Audit-Signalen.

Laut einer im Mai 2026 veröffentlichten Okta-Umfrage gaben mehr als die Hälfte der Mitarbeitenden an, persönliche KI-Tools ohne Genehmigung zu nutzen. Zwei Drittel der US-amerikanischen Mitarbeitenden nutzen nicht genehmigte KI, und fast ein Viertel tut dies regelmäßig. Gleichzeitig gaben 58 % der Führungskräfte an, dass ihre Organisation im vergangenen Jahr einen KI-bezogenen Sicherheitsvorfall oder Beinahe-Vorfall hatte.

Die Okta-Studie ergab auch, dass mehr als die Hälfte der Mitarbeitenden sagt, die KI-Nutzungsrichtlinien ihrer Organisation seien unklar, schwer zu finden oder nicht vorhanden. Diese Lücke zwischen dem Vertrauen der Führungskräfte und der Erfahrung der Mitarbeitenden ist der Ort, an dem Shadow AI wächst.

Einige Hochrisiko-Anwendungsfälle sollten vollständig blockiert werden — das Einfügen von Kundendaten in ein öffentliches KI-Tool oder das Verbinden eines Consumer-KI-Agenten mit Produktionssystemen. Aber pauschale Verbote funktionieren nicht. Mitarbeitende nutzen Shadow AI aus rationalen Gründen: bessere Tools, schnellere Ergebnisse, eine Beschaffung, die zu langsam ist. Effektive Governance bietet genehmigte Alternativen, setzt klare Grenzen und überwacht die Bewegung sensibler Daten. Werden die zugrundeliegenden Anreize ignoriert, ändert sich das Verhalten nicht.

Wie Shadow AI im Unternehmen erkannt werden kann

Die Erkennung von Shadow AI erfordert Sichtbarkeit über Browser, Endpunkte, SaaS-Berechtigungen und Identitätssysteme hinweg. IBM's 2025-Studie ergab, dass nur 34 % der Organisationen mit KI-Governance-Richtlinien regelmäßige Audits auf nicht genehmigte KI durchführten — was bedeutet, dass die meisten Organisationen Richtlinien ohne operative Sichtbarkeit haben.

Ein praktischer Erkennungsansatz umfasst sieben Bereiche

1. Schritt 1. Inventarisieren Sie KI-Domains, Browser-Erweiterungen, SaaS-KI-Funktionen, KI-Meeting-Tools, KI-Coding-Assistenten und KI-Funktionen, die in bereits genehmigte Anwendungen eingebettet sind.
2. Schritt 2. Überwachen Sie browser-basierte GenAI-Nutzung, Kopieren/Einfügen-Ereignisse, Datei-Uploads und Downloads, wo dies rechtlich und ethisch nach den Mitarbeiterüberwachungsvorschriften Ihrer Rechtsordnung zulässig ist.
3. Schritt 3. Überprüfen Sie OAuth-Grants, API-Token, Service-Accounts und Drittanbieter-App-Berechtigungen. KI-Agenten und Integrationen fordern oft umfassende OAuth-Scopes an, die lange nach der Ersteinrichtung bestehen bleiben.
4. Schritt 4. Klassifizieren Sie sensible Datenkategorien, die niemals ohne ausdrückliche Genehmigung an externe KI-Tools übermittelt werden sollten: PII, Quellcode, Finanzprognosen, juristische Dokumente, regulierte Gesundheitsdaten und Credentials.
5. Schritt 5. Überprüfen Sie Identitätskontrollen: SSO-Abdeckung, MFA-Durchsetzung, SCIM/LDAP-Provisioning, RBAC-Zuweisungen und Vollständigkeit der Audit-Logs. Persönliche KI-Accounts umgehen all dies.
6. Schritt 6. Suchen Sie nach exponierten Credentials in Code-Repositories, Logs, Tickets und KI-bezogenen Workflows. Token und API-Schlüssel erscheinen an unerwarteten Stellen — Commit-History, Slack-Threads, Support-Tickets und KI-Prompt-Logs.
7. Schritt 7. Ordnen Sie die KI-Nutzung dem Geschäftsbedarf zu, bevor Sie sie blockieren. Das Verständnis, warum Mitarbeitende ein Tool nutzen, ist notwendig, um eine verwaltete Alternative bereitzustellen, die sie tatsächlich verwenden werden.

Wie Shadow-AI-Risiken reduziert werden können, ohne die Produktivität zu blockieren

Effektive Shadow-AI-Governance ist ebenso ein Enablement-Problem wie ein Sicherheitsproblem. Das Ziel ist es, Mitarbeitenden sichere, genehmigte Optionen zu geben und gleichzeitig Kontrollen dort anzuwenden, wo sensible Daten gefährdet sind.

Die Identitäts- und Zugriffsebene benötigt drei Dinge: SSO-Abdeckung über genehmigte KI-Tools, MFA-Durchsetzung und SCIM- oder LDAP-Provisioning, das den Zugriff direkt an den Beschäftigungsstatus bindet. Für Passwörter und Secrets verwandelt ein zentralisierter Tresor mit rollenbasierter Zugriffskontrolle, Active-Directory-Integration und Aktivitäts-Logs das Credential-Management von einer manuellen Aufgabe in einen auditierbaren Prozess.

Wo Passwörter und Secrets in die Shadow-AI-Governance passen

Bei der Shadow-AI-Governance geht es darum, welche Credentials und Berechtigungen KI-nahe Tools erreichen können.

Credential-Exposition in KI-Workflows geschieht oft indirekt:

• Ein Entwickler fügt eine Log-Datei in einen Coding-Assistenten ein — das Log enthält einen Datenbank-Connection-String
• Ein Support-Mitarbeiter teilt einen Screenshot in einem KI-Tool — der Screenshot zeigt einen API-Schlüssel in einem Browser-Tab
• Ein Mitarbeitender lädt eine Umgebungskonfigurationsdatei für KI-gestütztes Debugging hoch — die Datei enthält Service-Account-Credentials

Keines davon sind absichtliche Exfiltrations-Ereignisse. Alle schaffen echte Zugriffsrisiken.

KI-Coding-Assistenten und -Agenten verstärken dies. Sie können mit Repositories, Terminals, SaaS-APIs und lokalen Dateisystemen interagieren. Ein Agent mit Zugriff auf die Terminal-Sitzung eines Entwicklers kann Umgebungsvariablen, SSH-Schlüssel und Credential-Dateien lesen. Wenn dieser Agent über einen persönlichen Account ohne Enterprise-Audit-Trail läuft, hat die Organisation keinen Nachweis darüber, was zugegriffen wurde.

Das Governance-Ziel ist es zu verhindern, dass unverwaltete KI-Workflows ein eingefügtes Token oder geteiltes Passwort in einen dauerhaften Zugriffspfad verwandeln. Das erfordert spezifische Kontrollen: einzigartige Credentials pro Dienst, keine geteilten Passwörter in Chat oder Tickets, tresorbasiertes Teilen mit Zugriffskontrollen, Least Privilege bei Service-Accounts, MFA bei allen administrativen Zugriffen, regelmäßige Secret-Rotation, API-Schlüssel-Inventar, OAuth-Berechtigungsprüfungen und Audit-Logs, die den Credential-Zugriff abdecken.

Passwork ist als selbst gehostete Bereitstellung oder in der Cloud verfügbar, mit einer vollständigen REST API und CLI-Tools für Teams, die Credential-Management in bestehende DevOps-Workflows integrieren müssen. Zugriffsüberprüfungen, Audit-Logs und Rollenzuweisungen werden über eine einzige Oberfläche verwaltet — keine separaten Tools erforderlich. Mehr erfahren

Eine praktische Shadow-AI-Governance-Checkliste

Diese Checkliste ist für Sicherheitsingenieure und Compliance-Teams konzipiert, die ein Shadow-AI-Governance-Programm beginnen oder ausbauen. Überprüfen Sie sie vierteljährlich — KI-Tool-Funktionen und regulatorische Anforderungen ändern sich schneller, als jährliche Zyklen erfassen können.

Die Shadow-AI-Governance-Checkliste (10 Punkte)

1. Definieren Sie genehmigte, bedingte und verbotene KI-Anwendungsfälle nach Datentyp und Geschäftsfunktion.
2. Erstellen Sie eine Liste genehmigter KI-Tools nach Funktion: Schreiben, Coding, Datenanalyse, Meeting-Notizen, Kundensupport.
3. Verlangen Sie Enterprise-Accounts für genehmigte Tools, bei denen sensible Daten verarbeitet werden könnten.
4. Blockieren oder warnen Sie bei öffentlichem Upload eingeschränkter Datenkategorien (PII, Quellcode, Finanzprognosen, juristische Dokumente, Credentials).
5. Überprüfen Sie KI-Browser-Erweiterungen und OAuth-Berechtigungen — entziehen Sie solche ohne dokumentierten Geschäftsbedarf.
6. Auditieren Sie API-Token, Service-Accounts, geteilte Credentials und Secrets, die in der Nähe von KI-Workflows verwendet werden.
7. Fügen Sie DLP- oder Browser-Kontrollen für Prompts, Datei-Uploads und Kopieren/Einfügen-Ereignisse hinzu, wo angemessen und rechtlich zulässig.
8. Veröffentlichen Sie Beispiele für erlaubte und verbotene Prompts — konkrete Beispiele übertreffen abstrakte Richtlinien.
9. Schulen Sie Teams rollenspezifisch: Entwickler, Vertrieb, Recht, HR, Finanzen und Support stehen vor unterschiedlichen KI-Risikoszenarien.
10. Überprüfen Sie KI-Richtlinien vierteljährlich, da sich Tool-Funktionen, Anbieter-Aufbewahrungsbedingungen und Vorschriften schnell ändern.

Fazit

Shadow AI ist kein Grund, die KI-Einführung zu verlangsamen. Sie ist ein Grund, KI als Daten-, Identitäts- und Zugriffsproblem zu behandeln — dieselben Disziplinen, die Sicherheitsteams bereits auf andere Technologien anwenden, angewandt auf eine sich schneller bewegende und schwerer zu beobachtende Kategorie.

Die fünf Dimensionen des Shadow-AI-Risikomultiplikators — Datenexfiltration durch normale Arbeit, persönliche Accounts, die Enterprise-Kontrollen brechen, KI-beeinflusste Entscheidungen, agentische Aktionen und Credential-Exposition — erklären, warum bestehende Shadow-IT-Kontrollen notwendig, aber nicht ausreichend sind. Jede Dimension erfordert eine spezifische Antwort: Datenklassifizierung, Bereitstellung genehmigter Tools, Output-Governance, Überprüfung von Agenten-Berechtigungen und Secrets-Management.

Die Organisationen, die dies gut managen, sind diejenigen, die Mitarbeitenden sichere Optionen geben, klare Regeln definieren und die Monitoring-Fähigkeit aufbauen, um zu sehen, was tatsächlich passiert.

Wenn Ihr Team Shadow-AI-Kontrollen überprüft, beziehen Sie geteilte Passwörter, API-Schlüssel, Service-Accounts und Secrets in die Bewertung ein. Passwork unterstützt diesen Teil des Governance-Programms durch Zentralisierung des Credential-Zugriffs, Integration mit LDAP/SSO und Bereitstellung von Audit-Sichtbarkeit für passwortbezogene Workflows.

Häufig gestellte Fragen

Ist Shadow AI dasselbe wie Shadow IT?

Nein. Shadow AI ist mit Shadow IT verwandt, bezieht sich aber speziell auf nicht genehmigte KI-Tools, KI-Funktionen, Modelle, Prompts, Agenten und Workflows. Sie fügt eigenständige Risiken hinzu rund um die Datenverarbeitung durch Prompts und Datei-Uploads, Modell-Aufbewahrung, Qualität generierter Outputs und delegierte Berechtigungen für KI-Agenten. Traditionelle Shadow IT verursacht hauptsächlich unverwalteten Technologie-Wildwuchs.

Warum ist Shadow AI gefährlicher als Shadow IT?

Shadow AI ist oft gefährlicher, weil sie sensible Daten durch Prompts und Datei-Uploads exponieren, Geschäftsentscheidungen durch ungeprüfte Outputs beeinflussen und über Agenten und Integrationen mit Credentials oder Systemen interagieren kann. IBMs 2025-Studie ergab, dass Organisationen mit hoher Shadow-AI-Nutzung durchschnittlich 670.000 US-Dollar mehr an Kosten für Sicherheitsvorfälle hatten als solche mit geringer oder keiner Shadow-AI-Nutzung.

Welche Daten sollten Mitarbeitende niemals in öffentliche KI-Tools einfügen?

Mitarbeitende sollten keine Passwörter, API-Schlüssel, Token, Quellcode, Kundendaten, HR-Daten, juristische Dokumente, Finanzprognosen, regulierte Daten (Gesundheitsdaten, PII) oder vertrauliches geistiges Eigentum in öffentliche KI-Tools einfügen, es sei denn, die Organisation hat dieses Tool und den Anwendungsfall ausdrücklich mit angemessenen vertraglichen Datenschutzmaßnahmen genehmigt.

Können Unternehmen Shadow AI vollständig stoppen?

Die meisten Organisationen sollten sich nicht auf ein vollständiges Verbot verlassen. Harmonic Securitys 2025-Daten zeigten, dass zwar nur 40 % der Unternehmen offizielle KI-Abonnements erworben haben, Mitarbeitende bei über 90 % der Organisationen aber aktiv KI-Tools nutzen — meist über persönliche Accounts. Eine bessere Strategie ist es, genehmigte KI-Tools bereitzustellen, klare Anwendungsfälle zu definieren, die Bewegung sensibler Daten zu überwachen und Zugriffskontrollen durchzusetzen.

Wie können Sicherheitsteams Shadow AI erkennen?

Die Erkennung erfordert eine Kombination aus KI-Domain-Inventar, Browser-Sichtbarkeitstools, DLP, SaaS-Security-Posture-Review (SSPM), OAuth-Grant-Review, Endpunkt-Telemetrie und Mitarbeitermeldungen. Sicherheitsteams sollten auch KI-Funktionen auditieren, die in bereits genehmigte SaaS-Tools eingebettet sind — diese werden oft übersehen, weil die übergeordnete Anwendung genehmigt ist.

Wie helfen Passwort-Manager bei Shadow-AI-Risiken?

Passwort-Manager verwalten KI nicht direkt, reduzieren aber den Credential-Wildwuchs rund um KI-Workflows. Sie helfen dabei, geteilte Credentials zu zentralisieren, rollenbasierte Zugriffskontrollen durchzusetzen, Audit-Trails für Passwort- und Secret-Nutzung zu unterstützen, Secret-Rotation zu vereinfachen und Sichtbarkeit darüber zu bieten, welche Credentials mit wem geteilt werden — all das ist relevant, wenn KI-Tools oder -Agenten diese Credentials möglicherweise berührt haben.

Adressiert der EU AI Act Shadow AI?

Der EU AI Act (in Kraft seit August 2024, mit gestaffelten Verpflichtungen bis 2027) etabliert Anforderungen für KI-Systemanbieter und -betreiber, einschließlich Transparenz, Risikoklassifizierung und Governance-Verpflichtungen für Hochrisiko-KI-Systeme. Er reguliert nicht direkt die Nutzung von Consumer-KI-Tools durch Mitarbeitende, aber Organisationen, die dem Gesetz unterliegen, sollten sicherstellen, dass ihre KI-Governance-Programme nicht genehmigte Nutzung abdecken, insbesondere bei Hochrisiko-Anwendungsfällen. Rechtsabteilungen sollten die anwendbaren Verpflichtungen unter den spezifischen Artikeln prüfen, die für ihren KI-Einsatzkontext relevant sind.

VaultJacking: Wie eine PIN den Google Passwortmanager öffnet

VaultJacking zielt auf die PIN des Google Passwortmanagers ab, um Ihren gesamten Tresor zu entsperren. Eine abgefangene PIN legt alle gespeicherten Passwörter und Passkeys offen. Erfahren Sie, wie der Angriff funktioniert, wer gefährdet ist und was Sie tun können, wenn Sie Opfer von Phishing wurden.

Passwork BlogAlex Muntyan

NIS2 aktuelle Neuigkeiten: Updates Mai 2026

Bulgariens Sanktionsphase, Luxemburgs neues Gesetz, Cyberbeveiligingswet der Niederlande, ENISA NIS360 2026 — NIS2-Entwicklungen Mai 2026.

Passwork BlogAlex Muntyan

Passwork gewinnt Top Performer Spring 2026 auf SourceForge

Passwork wurde von SourceForge als Top Performer Spring 2026 ausgezeichnet und gehört damit 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 den Support.

Passwork BlogAlex Muntyan

Shadow IT es el uso de tecnología no aprobada sin conocimiento ni supervisión de TI. Shadow AI es el uso de herramientas, modelos, funciones y flujos de trabajo de IA no aprobados — y suele ser más arriesgado porque puede procesar datos sensibles, influir en decisiones, generar resultados e interactuar con credenciales o sistemas completamente fuera de la gobernanza normal.

La magnitud del problema ya es visible en los datos de brechas:

• Una de cada cinco organizaciones reportó una brecha debido a shadow AI, y el alto uso de shadow AI añadió un promedio de $670,000 a los costos de brechas — Informe del Costo de una Brecha de Datos 2025 de IBM.
• Más de la mitad de los ejecutivos (58%) reportaron que su organización experimentó un incidente de seguridad relacionado con IA o una situación cercana en el último año — encuesta AI Agents at Work 2026 de Okta.
• Se encontraron más de 1,27 millones de secretos de servicios de IA filtrados en GitHub público. Un 81% más que el año anterior. Ocho de los diez tipos de secretos filtrados de más rápido crecimiento están vinculados a servicios de IA — State of Secrets Sprawl 2026 de GitGuardian.
• Solo el 5% de las empresas tiene visibilidad completa sobre qué herramientas de IA están usando realmente los empleados, y el 78% confirmó un incidente de seguridad relacionado con IA o no pudo descartarlo — 2026 Cloud Security Report de Check Point.
• El 92% de los profesionales de seguridad están preocupados por los agentes de IA y su impacto en la seguridad, pero solo el 37% de las organizaciones tiene una política formal de IA implementada — State of AI Cybersecurity 2026 de Darktrace.

Los gobiernos han tomado nota. La Ley de IA de la UE está ahora en aplicación activa, con sanciones por uso no conforme de sistemas de IA de alto riesgo que alcanzan hasta 15 millones de euros o el 3% de la facturación anual global.

En Estados Unidos, el presidente Trump firmó una orden ejecutiva el 2 de junio de 2026 — «Promoting Advanced Artificial Intelligence Innovation and Security» — ordenando a CISA expandir las ciberdefensas habilitadas por IA en los sistemas federales y operadores de infraestructura crítica, y estableciendo un marco voluntario para evaluar modelos de IA de frontera antes de su lanzamiento público. La orden no regula cómo los empleados usan la IA dentro de las empresas, pero señala claramente que la seguridad de la IA es ahora una prioridad federal y que las organizaciones que operan infraestructura crítica ya están dentro del alcance.

Las herramientas están en uso. Los datos se están moviendo. ¿Hacia dónde? La mayoría de las organizaciones simplemente no lo sabe.

Puntos clave

• Shadow AI es una categoría de riesgo distinta, no solo Shadow IT con marca de IA. Las herramientas, modelos y agentes de IA no aprobados procesan datos, influyen en decisiones e interactúan con credenciales completamente fuera de la gobernanza normal, mientras que el Shadow IT tradicional solo crea dispersión tecnológica no gestionada.
• Los datos de brechas ya son visibles. Una de cada cinco organizaciones reportó una brecha debido a Shadow AI. La mayoría de las empresas no tiene una imagen clara de qué herramientas de IA están usando realmente los empleados.
• Las cuentas personales son la principal brecha de control. La mayoría del uso de herramientas de IA ocurre a través de cuentas personales que evitan SSO, DLP y registro centralizado, sin dejar rastro de auditoría ni base contractual para la eliminación de datos.
• Los agentes de IA desplazan el problema de la entrada de datos al acceso y la acción. Los agentes pueden leer archivos, llamar a APIs y modificar código mediante permisos OAuth delegados, y esas acciones pueden no registrarse en ningún lugar que el equipo de seguridad pueda ver.
• La exposición de credenciales es la brecha de mayor severidad. Los registros, fragmentos de código, archivos de entorno y datos de autocompletado del navegador frecuentemente contienen contraseñas, claves API o tokens. Cuando se pegan en una herramienta de IA, el resultado es una potencial ruta de acceso persistente, no solo un evento de exposición de datos.
• La prohibición total reubica el Shadow AI, no lo elimina. Los empleados migran a dispositivos personales y herramientas alternativas con menos señales de auditoría. Una gobernanza efectiva proporciona alternativas aprobadas y monitorea el movimiento de datos sensibles.
• Los reguladores han tomado nota. La Ley de IA de la UE está en aplicación activa, con sanciones que alcanzan 15 millones de euros o el 3% de la facturación anual global. Una orden ejecutiva de EE. UU. firmada el 2 de junio de 2026 señala que la seguridad de la IA es ahora una prioridad federal.
• La gobernanza requiere cinco respuestas específicas. Clasificación de datos, provisión de herramientas aprobadas, gobernanza de resultados, revisión de permisos de agentes y gestión de secretos. Los controles existentes de Shadow IT son necesarios pero no suficientes.

¿Qué es Shadow IT?

Shadow IT es cualquier tecnología (software, hardware, servicios en la nube, aplicaciones SaaS, scripts o infraestructura) utilizada dentro de una organización sin aprobación, conocimiento o supervisión de TI. El término abarca una amplia gama de comportamientos: un empleado que usa un almacenamiento personal en la nube para compartir archivos, un equipo que implementa una herramienta de gestión de proyectos no aprobada, un desarrollador que ejecuta scripts en infraestructura no gestionada, o un departamento que se suscribe a un producto SaaS fuera del proceso de adquisiciones.

El problema central del Shadow IT es la pérdida de gobernanza. Cuando TI no sabe que existe una herramienta, no puede aplicar controles de acceso, implementar políticas de Prevención de Pérdida de Datos (DLP), gestionar el ciclo de vida de los datos ni revocar el acceso cuando un empleado se va. Los requisitos de licencias, cumplimiento y rastro de auditoría también quedan sin cubrir.

El Shadow IT sigue un camino predecible. Un empleado necesita una herramienta — compartir archivos más rápido, un rastreador de proyectos, un script que funcione en algo diferente al stack aprobado. El proceso oficial es demasiado lento o la herramienta simplemente no está disponible, así que encuentran su propia solución. TI nunca se entera.

Ejemplos comunes de Shadow IT incluyen:

• Almacenamiento personal en la nube (cuentas de consumidor usadas para archivos de trabajo)
• Aplicaciones de mensajería y colaboración no aprobadas
• Extensiones de navegador con amplios permisos de datos
• Suscripciones SaaS no gestionadas pagadas con presupuesto del equipo
• Scripts y herramientas de automatización creados por desarrolladores que funcionan fuera de la visibilidad de TI
• Dispositivos de consumidor conectados a redes corporativas

El Shadow IT no siempre es malicioso. La mayoría comienza como una solución de productividad — un equipo necesitaba una herramienta, las adquisiciones eran lentas y alguien encontró una alternativa gratuita. Ese contexto importa para la gobernanza: la prohibición sin reemplazo rara vez funciona.

¿Qué es Shadow AI?

Shadow AI es el uso no autorizado de herramientas de IA, funciones de IA, modelos, prompts, agentes y flujos de trabajo sin aprobación ni supervisión de TI. Está relacionado con el Shadow IT pero es distinto: mientras que el Shadow IT principalmente crea dispersión tecnológica no gestionada, el Shadow AI crea procesamiento de datos no gestionado, soporte de decisiones no gestionado y acciones no gestionadas.

El Shadow AI incluye un conjunto amplio y de rápido crecimiento de comportamientos. Los empleados usan modelos de lenguaje grandes públicos (LLMs) como ChatGPT, Claude y Gemini a través de cuentas personales. Los desarrolladores usan asistentes de codificación con IA como GitHub Copilot o Cursor fuera de los tenants empresariales. Los equipos usan asistentes de reuniones con IA, extensiones de navegador con IA y funciones SaaS potenciadas por IA que nunca fueron revisadas formalmente. Algunos empleados construyen sus propios flujos de trabajo de IA usando herramientas de automatización de consumidor.

El Shadow AI sigue el mismo camino que el Shadow IT, pero las consecuencias al final son diferentes. Un empleado necesita moverse más rápido — resumir un documento, generar código, redactar una respuesta. No hay herramienta aprobada, o la herramienta aprobada es más lenta que la que ya usan personalmente. Así que usan su propia cuenta, una extensión de navegador o una función de IA integrada en un producto SaaS que TI ya aprobó pero nunca auditó.

Ejemplos comunes de Shadow AI en la práctica:

• Empleados usando ChatGPT, Claude, Gemini o Perplexity a través de cuentas personales de nivel gratuito
• Desarrolladores usando asistentes de codificación con IA fuera de los controles de licencia empresarial
• Equipos de ventas y marketing usando herramientas de escritura con IA no revisadas por seguridad
• Equipos de RR. HH. y finanzas usando IA para resumir documentos que contienen datos regulados
• Asistentes de reuniones con IA grabando y transcribiendo llamadas sin controles de retención empresarial
• Extensiones de IA basadas en navegador con acceso al contenido de la página, portapapeles y campos de formulario
• Agentes de IA construidos por empleados conectándose a APIs SaaS o sistemas internos

La escala es significativa. El informe 2025 de Menlo Security registró 10,53 mil millones de visitas a sitios de IA solo en enero de 2025, frente a 7 mil millones en febrero de 2024, con el 80% de ese acceso ocurriendo a través de navegadores. El Shadow AI no es un comportamiento de nicho — es la forma en que la mayoría de los empleados actualmente usa la IA.

Shadow IT vs Shadow AI: Las diferencias clave

El Shadow IT y el Shadow AI comparten la misma causa raíz: empleados resolviendo problemas reales con herramientas que TI no ha aprobado. Pero crean diferentes perfiles de riesgo y requieren diferentes controles.

La brecha de remediación es particularmente significativa. Cuando un empleado usa una herramienta SaaS no aprobada, TI puede revocar el acceso y migrar los datos. Cuando el contenido sensible entra en el flujo de trabajo de un modelo de IA externo, confirmar la eliminación, demostrar la no retención y delimitar el incidente es sustancialmente más difícil, especialmente cuando se accedió a la herramienta a través de una cuenta personal sin rastro de auditoría empresarial.

Por qué Shadow AI es la amenaza mayor

El Shadow AI es a menudo más peligroso que el Shadow IT tradicional porque no solo almacena o mueve datos — los procesa, genera y actúa sobre ellos. Las siguientes cinco dimensiones explican dónde cambia el modelo de riesgo. Juntas, forman lo que este artículo llama el multiplicador de riesgo del Shadow AI.

1. La exfiltración de datos ocurre a través del trabajo ordinario

Los empleados no necesitan exfiltrar datos intencionalmente. Pegan correos electrónicos, contratos, hojas de cálculo, código fuente, tickets de soporte, registros de clientes, información de RR. HH. y registros del sistema en herramientas de IA como parte del trabajo normal. Cada prompt es una potencial transferencia de datos.

El análisis de Harmonic Security de 22.458.240 prompts de IA generativa empresarial de 2025 detectó 579.113 instancias de exposición de datos sensibles en 665 herramientas de IA. El código, los documentos legales y los datos financieros representaron el 74,5% de lo expuesto. Según el AI Adoption & Risk Report 2026 de Cyberhaven, el 39,7% de todas las interacciones con IA involucraron datos sensibles, y los empleados introducen datos sensibles en herramientas de IA una vez cada tres días en promedio.

Los datos sensibles y la IA están ahora integrados en los flujos de trabajo diarios, y la exposición no es ocasional.

2. Las cuentas personales rompen los controles empresariales

Una parte significativa del uso de IA ocurre a través de cuentas personales en lugar de tenants empresariales. Los datos de 2026 de Cyberhaven encontraron que el 32,3% del uso de ChatGPT, el 58,2% del uso de Claude y el 60,9% del uso de Perplexity ocurrieron a través de cuentas personales. El informe 2025 de Menlo Security encontró que el 68% de los empleados usaron herramientas de IA de nivel gratuito a través de cuentas personales, con el 57% introduciendo datos sensibles.

Las cuentas personales evitan la aplicación de SSO, las políticas de retención empresarial, el registro centralizado, los controles DLP y la gobernanza de datos a nivel de administrador. Cuando un empleado usa Claude o Perplexity a través de una cuenta personal, la organización no tiene visibilidad de lo que se envió, no tiene rastro de auditoría y no tiene base contractual para la eliminación de datos o compromisos de no entrenamiento.

3. La IA puede influir en decisiones, no solo almacenar archivos

El Shadow IT principalmente crea almacenamiento o transferencia de datos no gestionados. El Shadow AI hace algo más: resume, clasifica, clasifica, recomienda, genera código y redacta contenido dirigido a clientes o legal. Una herramienta de IA no aprobada puede dar forma a una decisión empresarial basada en datos no verificados, una versión de modelo desconocida y suposiciones que el usuario nunca examinó.

Las alucinaciones, la deriva del modelo y el sesgo en los resultados de IA son modos de fallo reales. Cuando la herramienta no está sancionada y el resultado no está atribuido, no hay forma de auditar la cadena de decisiones después del hecho.

4. Los agentes de IA extienden el problema de la entrada a la acción

Los agentes de IA pueden leer archivos, usar portapapeles, llamar a APIs, enviar mensajes, modificar código y conectarse a sistemas SaaS. Muchos funcionan a nivel del sistema operativo, mantienen ventanas de contexto persistentes y sincronizan datos con infraestructura fuera de la supervisión del equipo de seguridad.

Esto mueve el Shadow AI de un problema de entrada de datos a un problema de acceso y acción. Un agente con permisos OAuth delegados o una clave API puede actuar en nombre de un usuario, y esas acciones pueden no registrarse en ningún lugar que el equipo de seguridad pueda ver.

5. La exposición de credenciales y secretos convierte el uso de IA en riesgo de acceso

Los registros, fragmentos de código, archivos de entorno, datos de autocompletado del navegador y tickets de soporte frecuentemente contienen contraseñas, claves API o tokens. Cuando estos se pegan en una herramienta de IA — a menudo accidentalmente — el resultado no es solo un evento de exposición de datos. Es una potencial ruta de acceso persistente.

El informe 2025 de IBM encontró que el 97% de las organizaciones comprometidas a través de modelos o aplicaciones de IA carecían de controles de acceso de IA adecuados, lo que significa que la mayoría de las organizaciones que experimentaron una brecha relacionada con IA no tenían ninguna capa de control significativa implementada.

Si su equipo está comenzando a mapear la exposición al Shadow AI, las credenciales y los secretos suelen ser la brecha de mayor severidad. Passwork centraliza contraseñas compartidas, claves API y credenciales de cuentas de servicio en una única bóveda cifrada con RBAC, integración LDAP/SSO y un registro de auditoría completo de cada evento de acceso. Cuando un empleado se va o se da de baja un flujo de trabajo de IA, el acceso se revoca en un solo lugar, sin necesidad de rastrearlo en una docena de herramientas. Pruebe Passwork gratis

Ejemplos reales de riesgo de Shadow AI

Los escenarios de riesgo a continuación son representativos de lo que los equipos de seguridad y TI encuentran en todos los departamentos. Ninguno requiere intención maliciosa — cada uno comienza con un objetivo de productividad legítimo.

El riesgo tiende a concentrarse en un pequeño número de herramientas de alto uso, lo cual es útil para la priorización de la gobernanza. Pero la larga cola todavía importa — una integración raramente usada puede conllevar el mismo riesgo de exposición de credenciales que un asistente de uso diario.

Por qué prohibir la IA generalmente empeora el Shadow AI

Una prohibición total de las herramientas de IA no elimina el Shadow AI. Lo reubica. Los empleados migran a dispositivos personales, cuentas personales o herramientas alternativas en las que TI tiene menos visibilidad. El resultado es la misma exposición de datos con menos señales de auditoría.

Según la encuesta de Okta publicada en mayo de 2026, más de la mitad de los empleados reportaron usar herramientas de IA personales sin aprobación. Dos tercios de los empleados en EE. UU. usan IA no sancionada, y casi una cuarta parte lo hace regularmente. Al mismo tiempo, el 58% de los ejecutivos dijo que su organización tuvo un incidente de seguridad relacionado con IA o una situación cercana en el año anterior.

La investigación de Okta también encontró que más de la mitad de los empleados dicen que las políticas de uso de IA de su organización son poco claras, difíciles de encontrar o inexistentes. Esa brecha entre la confianza ejecutiva y la experiencia del empleado es donde crece el Shadow AI.

Algunos casos de uso de alto riesgo deberían bloquearse directamente — pegar registros de clientes en una herramienta de IA pública, o conectar un agente de IA de consumidor a sistemas de producción. Pero la prohibición total no funciona. Los empleados adoptan shadow AI por razones racionales: mejores herramientas, resultados más rápidos, adquisiciones que se mueven demasiado lento. Una gobernanza efectiva proporciona alternativas aprobadas, establece límites claros y monitorea el movimiento de datos sensibles. Ignore los incentivos subyacentes y el comportamiento no cambiará.

Cómo detectar Shadow AI en la empresa

Detectar shadow AI requiere visibilidad en navegadores, endpoints, permisos SaaS y sistemas de identidad. La investigación de 2025 de IBM encontró que solo el 34% de las organizaciones con políticas de gobernanza de IA realizaron auditorías regulares para IA no sancionada — lo que significa que la mayoría de las organizaciones tienen política sin visibilidad operativa.

Un enfoque de detección práctico cubre siete áreas

1. Paso 1. Inventariar dominios de IA, extensiones de navegador, funciones de IA en SaaS, herramientas de reuniones con IA, asistentes de codificación con IA y funciones de IA integradas en aplicaciones ya aprobadas.
2. Paso 2. Monitorear el uso de IA generativa basada en navegador, eventos de copiar/pegar, cargas de archivos y descargas cuando sea legal y éticamente apropiado bajo las reglas de monitoreo de empleados de su jurisdicción.
3. Paso 3. Revisar concesiones OAuth, tokens API, cuentas de servicio y permisos de aplicaciones de terceros. Los agentes e integraciones de IA a menudo solicitan amplios alcances OAuth que persisten mucho después de la configuración inicial.
4. Paso 4. Clasificar las categorías de datos sensibles que nunca deberían enviarse a herramientas de IA externas sin aprobación explícita: datos de identificación personal, código fuente, pronósticos financieros, documentos legales, datos de salud regulados y credenciales.
5. Paso 5. Verificar los controles de identidad: cobertura de SSO, aplicación de MFA, aprovisionamiento SCIM/LDAP, asignaciones RBAC y completitud del registro de auditoría. Las cuentas de IA personales evitan todos estos.
6. Paso 6. Buscar credenciales expuestas en repositorios de código, registros, tickets y flujos de trabajo relacionados con IA. Los tokens y las claves API aparecen en lugares inesperados — historial de commits, hilos de Slack, tickets de soporte y registros de prompts de IA.
7. Paso 7. Mapear el uso de IA a la necesidad empresarial antes de bloquearlo. Comprender por qué los empleados usan una herramienta es necesario para proporcionar una alternativa gobernada que realmente usarán.

Cómo reducir el riesgo de Shadow AI sin bloquear la productividad

La gobernanza efectiva del Shadow AI es un problema de habilitación tanto como un problema de seguridad. El objetivo es dar a los empleados opciones seguras y aprobadas mientras se aplican controles donde los datos sensibles están en riesgo.

La capa de identidad y acceso necesita tres cosas: cobertura de SSO en las herramientas de IA aprobadas, aplicación de MFA y aprovisionamiento SCIM o LDAP que vincule el acceso directamente al estado de empleo. Para contraseñas y secretos, una bóveda centralizada con control de acceso basado en roles, integración con Active Directory y registros de actividad convierte la gestión de credenciales de una tarea manual en un proceso auditable.

Dónde encajan las contraseñas y los secretos en la gobernanza del Shadow AI

La gobernanza del Shadow AI trata sobre qué credenciales y permisos pueden alcanzar las herramientas adyacentes a la IA.

La exposición de credenciales en flujos de trabajo de IA a menudo ocurre indirectamente:

• Un desarrollador pega un archivo de registro en un asistente de codificación — el registro contiene una cadena de conexión a la base de datos
• Un ingeniero de soporte comparte una captura de pantalla en una herramienta de IA — la captura de pantalla muestra una clave API en una pestaña del navegador
• Un empleado carga un archivo de configuración de entorno para depuración asistida por IA — el archivo contiene credenciales de cuenta de servicio

Ninguno de estos es un evento de exfiltración deliberada. Todos ellos crean un riesgo de acceso real.

Los asistentes de codificación y agentes de IA agravan esto. Pueden interactuar con repositorios, terminales, APIs SaaS y sistemas de archivos locales. Un agente con acceso a la sesión de terminal de un desarrollador puede leer variables de entorno, claves SSH y archivos de credenciales. Si ese agente funciona a través de una cuenta personal sin rastro de auditoría empresarial, la organización no tiene registro de lo que se accedió.

El objetivo de la gobernanza es evitar que los flujos de trabajo de IA no gestionados conviertan un token pegado o una contraseña compartida en una ruta de acceso persistente. Eso requiere controles específicos: credenciales únicas por servicio, sin contraseñas compartidas en chat o tickets, compartición basada en bóveda con controles de acceso, privilegio mínimo en cuentas de servicio, MFA en todo acceso administrativo, rotación regular de secretos, inventario de claves API, revisiones de permisos OAuth y registros de auditoría que cubran el acceso a credenciales.

Passwork está disponible como despliegue autoalojado o en la nube, con una REST API completa y herramientas CLI para equipos que necesitan integrar la gestión de credenciales en flujos de trabajo DevOps existentes. Las revisiones de acceso, los registros de auditoría y las asignaciones de roles se gestionan a través de una única interfaz — sin necesidad de herramientas separadas. Más información

Una lista de verificación práctica para la gobernanza del Shadow AI

Esta lista de verificación está diseñada para ingenieros de seguridad y equipos de cumplimiento que comienzan o maduran un programa de gobernanza de Shadow AI. Revísela trimestralmente — las capacidades de las herramientas de IA y los requisitos regulatorios cambian más rápido de lo que los ciclos anuales pueden rastrear.

La lista de verificación de gobernanza de Shadow AI (10 puntos)

1. Definir casos de uso de IA aprobados, condicionales y prohibidos por tipo de datos y función empresarial.
2. Crear una lista de herramientas de IA aprobadas por función: redacción, codificación, análisis de datos, notas de reuniones, soporte al cliente.
3. Requerir cuentas empresariales para herramientas aprobadas donde se puedan procesar datos sensibles.
4. Bloquear o advertir sobre la carga pública de categorías de datos restringidos (datos de identificación personal, código fuente, pronósticos financieros, documentos legales, credenciales).
5. Revisar las extensiones de navegador de IA y los permisos OAuth — revocar aquellos sin una necesidad empresarial documentada.
6. Auditar tokens API, cuentas de servicio, credenciales compartidas y secretos usados cerca de flujos de trabajo de IA.
7. Añadir DLP o controles de navegador para prompts, cargas de archivos y eventos de copiar/pegar donde sea apropiado y legalmente permitido.
8. Publicar ejemplos de prompts permitidos y prohibidos — los ejemplos concretos superan a la política abstracta.
9. Formar a los equipos por rol: desarrolladores, ventas, legal, RR. HH., finanzas y soporte enfrentan diferentes escenarios de riesgo de IA.
10. Revisar las políticas de IA trimestralmente porque las capacidades de las herramientas, los términos de retención del proveedor y las regulaciones cambian rápidamente.

Conclusión

Shadow AI no es una razón para frenar la adopción de IA. Es una razón para gobernar la IA como un problema de datos, identidad y acceso — las mismas disciplinas que los equipos de seguridad ya aplican a otras tecnologías, aplicadas a una categoría que se mueve más rápido y es más difícil de observar.

Las cinco dimensiones del multiplicador de riesgo del Shadow AI — exfiltración de datos a través del trabajo ordinario, cuentas personales que rompen los controles empresariales, decisiones influenciadas por IA, acción agéntica y exposición de credenciales — explican por qué los controles existentes de Shadow IT son necesarios pero no suficientes. Cada dimensión requiere una respuesta específica: clasificación de datos, provisión de herramientas aprobadas, gobernanza de resultados, revisión de permisos de agentes y gestión de secretos.

Las organizaciones que gestionan esto bien son las que dan a los empleados opciones seguras, definen reglas claras y construyen la capacidad de monitoreo para ver lo que realmente está sucediendo.

Si su equipo está revisando los controles de Shadow AI, incluya contraseñas compartidas, claves API, cuentas de servicio y secretos en la evaluación. Passwork apoya esta parte del programa de gobernanza centralizando el acceso a credenciales, integrándose con LDAP/SSO y proporcionando visibilidad de auditoría para flujos de trabajo relacionados con contraseñas.

Preguntas frecuentes

¿Es Shadow AI lo mismo que Shadow IT?

No. Shadow AI está relacionado con Shadow IT pero involucra específicamente herramientas de IA, funciones de IA, modelos, prompts, agentes y flujos de trabajo no aprobados. Añade riesgos distintos en torno al procesamiento de datos a través de prompts y cargas de archivos, retención de modelos, calidad de resultados generados y permisos delegados para agentes de IA. El Shadow IT tradicional principalmente crea dispersión tecnológica no gestionada.

¿Por qué Shadow AI es más peligroso que Shadow IT?

Shadow AI es a menudo más peligroso porque puede exponer datos sensibles a través de prompts y cargas de archivos, influir en decisiones empresariales a través de resultados no verificados e interactuar con credenciales o sistemas a través de agentes e integraciones. La investigación de 2025 de IBM encontró que las organizaciones con alto uso de shadow AI incurrieron en un promedio de $670,000 más en costos de brechas que aquellas con bajo o ningún uso de shadow AI.

¿Qué datos nunca deberían pegar los empleados en herramientas de IA públicas?

Los empleados no deberían pegar contraseñas, claves API, tokens, código fuente, registros de clientes, registros de RR. HH., documentos legales, pronósticos financieros, datos regulados (registros de salud, datos de identificación personal) o propiedad intelectual confidencial en herramientas de IA públicas a menos que la organización haya aprobado explícitamente esa herramienta y caso de uso con protecciones de datos contractuales apropiadas.

¿Pueden las empresas detener completamente el Shadow AI?

La mayoría de las organizaciones no deberían depender de la prohibición completa. Los datos de 2025 de Harmonic Security encontraron que mientras solo el 40% de las empresas han comprado suscripciones oficiales de IA, los empleados en más del 90% de las organizaciones usan activamente herramientas de IA — principalmente a través de cuentas personales. Una mejor estrategia es proporcionar herramientas de IA aprobadas, definir casos de uso claros, monitorear el movimiento de datos sensibles y aplicar controles de acceso.

¿Cómo pueden los equipos de seguridad detectar Shadow AI?

La detección requiere una combinación de inventario de dominios de IA, herramientas de visibilidad del navegador, DLP, revisión de postura de seguridad SaaS (SSPM), revisión de concesiones OAuth, telemetría de endpoints e informes de empleados. Los equipos de seguridad también deberían auditar las funciones de IA integradas en herramientas SaaS ya aprobadas — estas a menudo se pasan por alto porque la aplicación principal está sancionada.

¿Cómo ayudan los gestores de contraseñas con el riesgo de Shadow AI?

Los gestores de contraseñas no gobiernan la IA por sí mismos, pero reducen la dispersión de credenciales en torno a los flujos de trabajo de IA. Ayudan a centralizar credenciales compartidas, aplicar controles de acceso basados en roles, soportar rastros de auditoría para el uso de contraseñas y secretos, simplificar la rotación de secretos y proporcionar visibilidad sobre qué credenciales se comparten y con quién — todo lo cual importa cuando las herramientas o agentes de IA pueden haber tocado esas credenciales.

¿Aborda la Ley de IA de la UE el Shadow AI?

La Ley de IA de la UE (en vigor desde agosto de 2024, con obligaciones escalonadas hasta 2027) establece requisitos para proveedores y desplegadores de sistemas de IA, incluyendo obligaciones de transparencia, clasificación de riesgos y gobernanza para sistemas de IA de alto riesgo. No regula directamente el uso de herramientas de IA de consumidor por parte de empleados, pero las organizaciones sujetas a la Ley deberían asegurar que sus programas de gobernanza de IA cubran el uso no sancionado, particularmente para casos de uso de alto riesgo. Los equipos legales deberían revisar las obligaciones aplicables bajo los artículos específicos relevantes para su contexto de despliegue de IA.

VaultJacking: cómo un PIN expone la bóveda de Google

VaultJacking ataca el PIN de Google Password Manager para desbloquear toda la bóveda. Un solo PIN capturado expone todas las contraseñas y passkeys guardadas. Descubra cómo funciona el ataque, quién está en riesgo y qué hacer si ha sido víctima de phishing.

Passwork BlogAlex Muntyan

Últimas noticias NIS2: actualizaciones de mayo 2026

Sanciones en Bulgaria, nueva ley en Luxemburgo, Cyberbeveiligingswet en Países Bajos, ENISA NIS360 2026: novedades de aplicación de NIS2 en mayo de 2026.

Passwork BlogAlex Muntyan

Passwork gana Top Performer Primavera 2026 en SourceForge

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

Passwork BlogAlex Muntyan

Shadow IT is the use of unapproved technology without IT knowledge or oversight. Shadow AI is the use of unapproved AI tools, models, features, and workflows — and it is often riskier because it can process sensitive data, influence decisions, generate outputs, and interact with credentials or systems entirely outside normal governance.

The scale of the problem is already visible in breach data:

• One in five organizations reported a breach due to shadow AI, and high shadow AI usage added an average of $670,000 to breach costs — IBM's 2025 Cost of a Data Breach Report.
• More than half of executives (58%) reported that their organization experienced an AI-related security incident or a close call in the past year — Okta's AI Agents at Work 2026 survey.
• Over 1.27 million AI service secrets were found leaked on public GitHub. 81% more than the year before. Eight of the ten fastest-growing leaked secret types are tied to AI services — GitGuardian's State of Secrets Sprawl 2026.
• Only 5% of businesses have full visibility into which AI tools employees are actually using, and 78% either confirmed an AI-related security incident or could not rule one out — Check Point's 2026 Cloud Security Report.
• 92% of security professionals are concerned about AI agents and their security impact, yet only 37% of organizations have a formal AI policy in place — Darktrace's State of AI Cybersecurity 2026.

Governments have taken notice. The EU AI Act is now in active enforcement, with penalties for non-compliant use of high-risk AI systems reaching up to €15 million or 3% of global annual turnover.

In the United States, President Trump signed an executive order on June 2, 2026 — "Promoting Advanced Artificial Intelligence Innovation and Security" — directing CISA to expand AI-enabled cyber defenses across federal systems and critical infrastructure operators, and establishing a voluntary framework for assessing frontier AI models before public release. The order does not regulate how employees use AI inside enterprises, but it signals clearly that AI security is now a federal priority and that organizations operating critical infrastructure are already in scope.

The tools are in use. The data is moving. Where? Most organizations just don't know.

Key takeaways

• Shadow AI is a distinct risk category, not just Shadow IT with AI branding. Unapproved AI tools, models, and agents process data, influence decisions, and interact with credentials entirely outside normal governance, where traditional Shadow IT only creates unmanaged technology sprawl.
• The breach data is already visible. One in five organizations reported a breach due to Shadow AI. Most businesses have no clear picture of which AI tools employees are actually using.
• Personal accounts are the primary control gap. Most AI tool usage happens through personal accounts that bypass SSO, DLP, and centralized logging, leaving no audit trail and no contractual basis for data deletion.
• AI agents shift the problem from data input to access and action. Agents can read files, call APIs, and modify code through delegated OAuth permissions, and those actions may not be logged anywhere the security team can see.
• Credential exposure is the highest-severity gap. Logs, code snippets, environment files, and browser autofill data frequently contain passwords, API keys, or tokens. When pasted into an AI tool, the result is a potential persistent access path, not just a data exposure event.
• Blanket prohibition relocates Shadow AI, it doesn't eliminate it. Employees move to personal devices and alternative tools with fewer audit signals. Effective governance provides approved alternatives and monitors sensitive data movement.
• Regulators have taken notice. The EU AI Act is in active enforcement, with penalties reaching €15 million or 3% of global annual turnover. A U.S. executive order signed June 2, 2026 signals that AI security is now a federal priority.
• Governance requires five specific responses. Data classification, approved tool provisioning, output governance, agent permission review, and secrets management. Existing Shadow IT controls are necessary but not sufficient.

What is Shadow IT?

Shadow IT is any technology (software, hardware, cloud services, SaaS applications, scripts, or infrastructure) used within an organization without IT approval, knowledge, or oversight. The term covers a wide range of behavior: an employee using a personal cloud drive to share files, a team spinning up an unapproved project management tool, a developer running scripts on unmanaged infrastructure, or a department subscribing to a SaaS product outside the procurement process.

The core problem with Shadow IT is governance loss. When IT doesn't know a tool exists, it can't enforce access controls, apply Data Loss Prevention (DLP) policies, manage the data lifecycle, or revoke access when an employee leaves. Licensing, compliance, and audit trail requirements also fall through the gaps.

Shadow IT follows a predictable path. An employee needs a tool — faster file sharing, a project tracker, a script that runs on something other than the approved stack. The official process is too slow or the tool simply isn't available, so they find their own solution. IT never finds out.

Common Shadow IT examples include:

• Personal cloud storage (consumer accounts used for work files)
• Unapproved messaging and collaboration apps
• Browser extensions with broad data permissions
• Unmanaged SaaS subscriptions paid by a team budget
• Developer-built scripts and automation tools running outside IT visibility
• Consumer devices connected to corporate networks

Shadow IT is not always malicious. Most of it starts as a productivity workaround — a team needed a tool, procurement was slow, and someone found a free alternative. That context matters for governance: prohibition without replacement rarely works.

What is Shadow AI?

Shadow AI is the unsanctioned use of AI tools, AI features, models, prompts, agents, and workflows without IT approval or oversight. It is related to Shadow IT but distinct: where Shadow IT mainly creates unmanaged technology sprawl, Shadow AI creates unmanaged data processing, unmanaged decision support, and unmanaged action.

Shadow AI includes a broad and fast-growing set of behaviors. Employees use public large language models (LLMs) like ChatGPT, Claude, and Gemini through personal accounts. Developers use AI coding assistants such as GitHub Copilot or Cursor outside enterprise tenants. Teams use AI meeting assistants, AI browser extensions, and AI-powered SaaS features that were never formally reviewed. Some employees build their own AI workflows using consumer automation tools.

Shadow AI follows the same path as Shadow IT, but the consequences at the end are different. An employee needs to move faster — summarize a document, generate code, draft a response. There's no approved tool, or the approved tool is slower than the one they already use personally. So they use their own account, a browser extension, or an AI feature embedded in a SaaS product IT already approved but never audited.

Common examples of Shadow AI in practice:

• Employees using ChatGPT, Claude, Gemini, or Perplexity through personal free-tier accounts
• Developers using AI coding assistants outside enterprise license controls
• Sales and marketing teams using AI writing tools not reviewed by security
• HR and finance teams using AI to summarize documents containing regulated data
• AI meeting assistants recording and transcribing calls without enterprise retention controls
• Browser-based AI extensions with access to page content, clipboard, and form fields
• Employee-built AI agents connecting to SaaS APIs or internal systems

The scale is significant. Menlo Security's 2025 report recorded 10.53 billion visits to AI sites in January 2025 alone, up from 7 billion in February 2024, with 80% of that access happening through browsers. Shadow AI is not a niche behavior — it is how most employees currently use AI.

Shadow IT vs Shadow AI: The key differences

Shadow IT and Shadow AI share the same root cause: employees solving real problems with tools IT hasn't approved. But they create different risk profiles and require different controls.

The remediation gap is particularly significant. When an employee uses an unapproved SaaS tool, IT can revoke access and migrate data. When sensitive content enters an external AI model's workflow, confirming deletion, proving non-retention, and scoping the incident is substantially harder, especially when the tool was accessed through a personal account with no enterprise audit trail.

Why Shadow AI is the bigger threat

Shadow AI is often more dangerous than traditional Shadow IT because it doesn't just store or move data — it processes, generates, and acts on it. The following five dimensions explain where the risk model changes. Together, they form what this article calls the Shadow AI risk multiplier.

1. Data exfiltration happens through ordinary work

Employees don't need to exfiltrate data intentionally. They paste emails, contracts, spreadsheets, source code, support tickets, customer records, HR information, and system logs into AI tools as part of normal work. Each prompt is a potential data transfer.

Harmonic Security's analysis of 22,458,240 enterprise GenAI prompts from 2025 detected 579,113 sensitive data exposure instances across 665 AI tools. Code, legal documents, and financial data accounted for 74.5% of what was exposed. According to Cyberhaven's 2026 AI Adoption & Risk Report, 39.7% of all AI interactions involved sensitive data, and employees input sensitive data into AI tools once every three days on average.

Sensitive data and AI are now embedded in daily workflows, and the exposure is not occasional.

2. Personal accounts break enterprise controls

A significant share of AI usage happens through personal accounts rather than enterprise tenants. Cyberhaven's 2026 data found that 32.3% of ChatGPT usage, 58.2% of Claude usage, and 60.9% of Perplexity usage occurred through personal accounts. Menlo Security's 2025 report found that 68% of employees used free-tier AI tools via personal accounts, with 57% inputting sensitive data.

Personal accounts bypass SSO enforcement, enterprise retention policies, centralized logging, DLP controls, and admin-level data governance. When an employee uses Claude or Perplexity through a personal account, the organization has no visibility into what was submitted, no audit trail, and no contractual basis for data deletion or non-training commitments.

3. AI can influence decisions, not just store files

Shadow IT mainly creates unmanaged data storage or transfer. Shadow AI does something more: it summarizes, classifies, ranks, recommends, generates code, and drafts customer-facing or legal content. An unapproved AI tool can shape a business decision based on unverified data, an unknown model version, and assumptions the user never examined.

Hallucinations, model drift, and bias in AI output are real failure modes. When the tool is unsanctioned and the output is unattributed, there is no way to audit the decision chain after the fact.

4. AI agents extend the problem from input to action

AI agents can read files, use clipboards, call APIs, send messages, modify code, and connect to SaaS systems. Many run at the operating system level, maintain persistent context windows, and synchronize data to infrastructure outside security team oversight.

This moves Shadow AI from a data-input problem to an access-and-action problem. An agent with delegated OAuth permissions or an API key can act on behalf of a user, and those actions may not be logged anywhere the security team can see.

5. Credential and secrets exposure turns AI use into access risk

Logs, code snippets, environment files, browser autofill data, and support tickets frequently contain passwords, API keys, or tokens. When these get pasted into an AI tool — often accidentally — the result is not just a data exposure event. It is a potential persistent access path.

IBM's 2025 report found that 97% of organizations compromised through AI models or applications lacked proper AI access controls, which means most organizations that experienced an AI-related breach had no meaningful control layer in place.

If your team is starting to map Shadow AI exposure, credentials and secrets are often the highest-severity gap. Passwork centralizes shared passwords, API keys, and service account credentials in a single encrypted vault with RBAC, LDAP/SSO integration, and a full audit log of every access event. When an employee leaves or an AI workflow is decommissioned, access is revoked in one place, not tracked down across a dozen tools. Try Passwork free

Real-world examples of Shadow AI risk

The risk scenarios below are representative of what security and IT teams encounter across departments. None require malicious intent — each starts with a legitimate productivity goal.

Risk tends to concentrate in a small number of high-usage tools, which is useful for governance prioritization. But the long tail still matters — a rarely used integration can carry the same credential exposure risk as a daily-use assistant.

Why banning AI usually makes Shadow AI worse

A blanket ban on AI tools does not eliminate Shadow AI. It relocates it. Employees move to personal devices, personal accounts, or alternative tools that IT has less visibility into. The result is the same data exposure with fewer audit signals.

According to Okta survey published in May 2026, more than half of employees reported using personal AI tools without approval. Two-thirds of U.S.-based employees use unsanctioned AI, and nearly a quarter do so regularly. At the same time, 58% of executives said their organization had an AI-related security incident or close call in the previous year.

The Okta research also found that more than half of employees say their organization's AI usage policies are unclear, difficult to find, or non-existent. That gap between executive confidence and employee experience is where Shadow AI grows.

Some high-risk use cases should be blocked outright — pasting customer records into a public AI tool, or connecting a consumer AI agent to production systems. But blanket prohibition doesn't work. Employees adopt shadow AI for rational reasons: better tools, faster results, procurement that moves too slowly. Effective governance provides approved alternatives, sets clear boundaries, and monitors sensitive data movement. Ignore the underlying incentives and the behavior won't change.

How to detect Shadow AI in the enterprise

Detecting shadow AI requires visibility across browsers, endpoints, SaaS permissions, and identity systems. IBM's 2025 research found that only 34% of organizations with AI governance policies performed regular audits for unsanctioned AI — meaning most organizations have policy without operational visibility.

A practical detection approach covers seven areas

1. Step 1. Inventory AI domains, browser extensions, SaaS AI features, AI meeting tools, AI coding assistants, and AI features embedded in already-approved applications.
2. Step 2. Monitor browser-based GenAI usage, copy/paste events, file uploads, and downloads where legally and ethically appropriate under your jurisdiction's employee monitoring rules.
3. Step 3. Review OAuth grants, API tokens, service accounts, and third-party app permissions. AI agents and integrations often request broad OAuth scopes that persist long after initial setup.
4. Step 4. Classify sensitive data categories that should never be submitted to external AI tools without explicit approval: PII, source code, financial forecasts, legal documents, regulated health data, and credentials.
5. Step 5. Check identity controls: SSO coverage, MFA enforcement, SCIM/LDAP provisioning, RBAC assignments, and audit log completeness. Personal AI accounts bypass all of these.
6. Step 6. Search for exposed credentials in code repositories, logs, tickets, and AI-related workflows. Tokens and API keys appear in unexpected places — commit history, Slack threads, support tickets, and AI prompt logs.
7. Step 7. Map AI usage to business need before blocking it. Understanding why employees use a tool is necessary for providing a governed alternative that they will actually use.

How to reduce Shadow AI risk without blocking productivity

Effective Shadow AI governance is an enablement problem as much as a security problem. The goal is to give employees safe, approved options while applying controls where sensitive data is at risk.

The identity and access layer needs three things: SSO coverage across approved AI tools, MFA enforcement, and SCIM or LDAP provisioning that ties access directly to employment status. For passwords and secrets, a centralized vault with role-based access control, Active Directory integration, and activity logs turns credential management from a manual chore into an auditable process.

Where passwords and secrets fit into Shadow AI governance

Shadow AI governance is about what credentials and permissions AI-adjacent tools can reach.

Credential exposure in AI workflows often happens indirectly:

• A developer pastes a log file into a coding assistant — the log contains a database connection string
• A support engineer shares a screenshot in an AI tool — the screenshot shows an API key in a browser tab
• An employee uploads an environment configuration file for AI-assisted debugging — the file contains service account credentials

None of these are deliberate exfiltration events. All of them create real access risk.

AI coding assistants and agents compound this. They can interact with repositories, terminals, SaaS APIs, and local file systems. An agent with access to a developer's terminal session can read environment variables, SSH keys, and credential files. If that agent runs through a personal account with no enterprise audit trail, the organization has no record of what was accessed.

The governance goal is to prevent unmanaged AI workflows from turning a pasted token or shared password into a persistent access path. That requires specific controls: unique credentials per service, no shared passwords in chat or tickets, vault-based sharing with access controls, least privilege on service accounts, MFA on all administrative access, regular secret rotation, API key inventory, OAuth permission reviews, and audit logs covering credential access.

Passwork is available as a self-hosted deployment or in the cloud, with a full REST API and CLI tools for teams that need to integrate credential management into existing DevOps workflows. Access reviews, audit logs, and role assignments are managed through a single interface — no separate tooling required. Learn more

A practical Shadow AI governance checklist

This checklist is designed for security engineers and compliance teams beginning or maturing a Shadow AI governance program. Review it quarterly — AI tool capabilities and regulatory requirements change faster than annual cycles can track.

The Shadow AI governance checklist (10 points)

1. Define approved, conditional, and prohibited AI use cases by data type and business function.
2. Create a list of approved AI tools by function: writing, coding, data analysis, meeting notes, customer support.
3. Require enterprise accounts for approved tools where sensitive data may be processed.
4. Block or warn on public upload of restricted data categories (PII, source code, financial forecasts, legal documents, credentials).
5. Review AI browser extensions and OAuth permissions — revoke those without a documented business need.
6. Audit API tokens, service accounts, shared credentials, and secrets used near AI workflows.
7. Add DLP or browser controls for prompts, file uploads, and copy/paste events where appropriate and legally permitted.
8. Publish examples of allowed and prohibited prompts — concrete examples outperform abstract policy.
9. Train teams by role: developers, sales, legal, HR, finance, and support face different AI risk scenarios.
10. Review AI policies quarterly because tool capabilities, vendor retention terms, and regulations change quickly.

Conclusion

Shadow AI is not a reason to slow AI adoption. It is a reason to govern AI as a data, identity, and access problem — the same disciplines that security teams already apply to other technology, applied to a faster-moving and harder-to-observe category.

The five dimensions of the Shadow AI risk multiplier — data exfiltration through ordinary work, personal accounts that break enterprise controls, AI-influenced decisions, agentic action, and credential exposure — explain why existing Shadow IT controls are necessary but not sufficient. Each dimension requires a specific response: data classification, approved tool provisioning, output governance, agent permission review, and secrets management.

The organizations that manage this well are the ones that give employees safe options, define clear rules, and build the monitoring capability to see what is actually happening.

If your team is reviewing Shadow AI controls, include shared passwords, API keys, service accounts, and secrets in the assessment. Passwork supports this part of the governance program by centralizing credential access, integrating with LDAP/SSO, and providing audit visibility for password-related workflows.

Frequently Asked Questions

Is Shadow AI the same as Shadow IT?

No. Shadow AI is related to Shadow IT but specifically involves unapproved AI tools, AI features, models, prompts, agents, and workflows. It adds distinct risks around data processing through prompts and file uploads, model retention, generated output quality, and delegated permissions for AI agents. Traditional Shadow IT mainly creates unmanaged technology sprawl.

Why is Shadow AI more dangerous than Shadow IT?

Shadow AI is often more dangerous because it can expose sensitive data through prompts and file uploads, influence business decisions through unverified outputs, and interact with credentials or systems through agents and integrations. IBM's 2025 research found that organizations with high shadow AI usage incurred an average of $670,000 more in breach costs than those with low or no shadow AI usage.

What data should employees never paste into public AI tools?

Employees should not paste passwords, API keys, tokens, source code, customer records, HR records, legal documents, financial forecasts, regulated data (health records, PII), or confidential IP into public AI tools unless the organization has explicitly approved that tool and use case with appropriate contractual data protections in place.

Can companies completely stop Shadow AI?

Most organizations should not rely on complete prohibition. Harmonic Security's 2025 data found that while only 40% of companies have purchased official AI subscriptions, employees at over 90% of organizations actively use AI tools — mostly through personal accounts. A better strategy is to provide approved AI tools, define clear use cases, monitor sensitive data movement, and enforce access controls.

How can security teams detect Shadow AI?

Detection requires a combination of AI domain inventory, browser visibility tools, DLP, SaaS security posture review (SSPM), OAuth grant review, endpoint telemetry, and employee reporting. Security teams should also audit AI features embedded in already-approved SaaS tools — these are often overlooked because the parent application is sanctioned.

How do password managers help with Shadow AI risk?

Password managers do not govern AI by themselves, but they reduce credential sprawl around AI workflows. They help centralize shared credentials, enforce role-based access controls, support audit trails for password and secret use, simplify secret rotation, and provide visibility into which credentials are shared and with whom — all of which matter when AI tools or agents may have touched those credentials.

Does the EU AI Act address Shadow AI?

The EU AI Act (in force from August 2024, with phased obligations through 2027) establishes requirements for AI system providers and deployers, including transparency, risk classification, and governance obligations for high-risk AI systems. It does not directly regulate employee use of consumer AI tools, but organizations subject to the Act should ensure their AI governance programs cover unsanctioned use, particularly for high-risk use cases. Legal teams should review applicable obligations under the specific articles relevant to their AI deployment context.

VaultJacking: How one PIN can expose a Google password manager vault

VaultJacking targets the Google Password Manager PIN to unlock your entire vault. One captured PIN exposes every saved password and passkey. Learn how the attack works, who’s at risk, and what to do if you’ve been phished.

Passwork BlogAlex Muntyan

NIS2 latest news: May 2026 enforcement updates

Bulgaria’s full sanctions phase, Luxembourg’s new law, Netherlands’ Cyberbeveiligingswet, ENISA NIS360 2026 — NIS2 enforcement developments from May 2026.

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

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