The Credential Paradox: How HailBytes SAT Handles Captured Passwords

Phishing simulation platforms exist to catch employees before a real attacker does. One of the most effective tests — spoofed Microsoft 365 or VPN login pages — captures the credentials users type into a fake form. That data is genuinely useful: it tells you not just that someone clicked, but that they went all the way through to handing over their credentials.

But it creates a problem. Now your security awareness training platform is sitting on a database of real corporate passwords. If the platform itself is ever compromised, you’ve handed an attacker a ready-made credential list. And depending on your jurisdiction or compliance framework, storing plaintext user credentials — even in a simulation context — may violate your own data handling policy.

The latest HailBytes SAT release addresses this directly, shipping two explicit credential storage policies so you make a deliberate, documented choice rather than inheriting whatever default the platform happened to have.

The Default: Redact at Write

When a user submits credentials to a phishing landing page, HailBytes SAT identifies password-shaped fields by name — password, passwd, pwd, passphrase, secret, otp, totp, mfa — using case-insensitive matching. Those fields are rewritten to a length-only sentinel before the event is written to the database:

__REDACTED__:len=12

The actual credential is gone immediately. You can still report on it — you know the user submitted something, and you know how long it was — but there is nothing to recover, no decryption key to rotate, no plaintext to leak. Non-sensitive fields pass through untouched.

This is the default because it aligns with the principle of data minimization: don’t keep what you don’t need to keep. For most programs, knowing that a user submitted credentials is the relevant data point. The actual credential value adds risk without adding insight.

The Opt-In: Encrypt at Rest

Some scenarios genuinely require knowing what was submitted, not just that something was. The clearest case is incident response: if a user submits their real Active Directory password to a fake Microsoft login page, you need to know whether to force a credential reset immediately. “Someone submitted 12 characters” does not answer that question; “someone submitted their current password” does.

The opt-in mode encrypts captured password fields with AES-256-GCM using the appliance’s master key before writing to the database. The ciphertext is stored with a per-record random nonce, so identical submissions produce different ciphertexts. An authorized admin can decrypt a captured value for IR purposes through a dedicated API call; the value never appears in the standard results view.

If encryption fails at write time — key unavailable, system fault — the platform degrades gracefully to redaction rather than aborting the event or writing plaintext. A failed write is worse than losing the credential value.

Making the Policy Visible

Both modes ship with UI affordances designed to prevent accidental misconfiguration. In the landing page editor, enabling Capture passwords reveals an Encrypt at rest checkbox. Whichever mode is active, a banner renders below the form settings explaining the exact storage guarantee in plain language:

• Encryption on: an informational banner noting that captured credentials are encrypted under the appliance master key and recoverable by authorized admins.
• Encryption off: a warning banner noting that only the field length is stored and the credential cannot be recovered.

This makes the active policy legible at a glance to anyone editing the landing page, rather than requiring them to dig into global settings.

Compliance Implications

Regulators and auditors increasingly apply the same data handling scrutiny to security tooling that they apply to production systems. GDPR’s Article 25 (privacy by design) calls for data minimization by default — the redact mode operationalizes that for phishing simulations. For SOC 2 and ISO 27001, having a documented, enforced credential storage policy means the question “what do you do with credentials captured in simulations?” has a concrete, auditable answer rather than “we don’t think the platform stores them.”

Organizations under HIPAA face additional exposure: a phishing simulation database that holds plaintext credentials is a potential breach vector in its own right. The redact default eliminates that surface entirely.

A Note for MSSPs

The credential storage policy is set per landing page, not globally, which matters for MSSPs running diverse campaign types across clients. A low-stakes click-rate campaign uses redaction. An IR-readiness drill where the client specifically wants to know if employees submitted real credentials can use encryption. Each client instance forwards to its own storage, with its own master key — there is no shared credential pool across tenants.