DEV Community: sen

Keycloak tm 2

sen — Fri, 14 Nov 2025 11:57:22 +0000

Threat Model: Keycloak Authentication Provider in Kubernetes

System Architecture Overview

Components:

Keycloak instance running in Kubernetes container
REST API Gateway (external-facing)
Internal network communication only
JWT token-based authentication for downstream applications

STRIDE Threat Analysis

1. SPOOFING (Identity Theft)

Threat S.1: Credential Stuffing Attacks

MITRE Technique: T1110.004 - Brute Force: Credential Stuffing

Description: Attackers use leaked credentials from other breaches to authenticate against Keycloak
Impact: Unauthorized access to user accounts
Mitigations:
- Implement account lockout policies after failed attempts
- Enable CAPTCHA for login forms
- Implement rate limiting at API Gateway
- Use breach password detection (HaveIBeenPwned integration)
- Enforce MFA for all users
Challenges: Balancing security with user experience; legitimate users may be locked out

Threat S.2: JWT Token Forgery

MITRE Technique: T1606.001 - Forge Web Credentials: Web Cookies

Description: Attacker attempts to forge JWT tokens with weak signing algorithms or stolen keys
Impact: Complete authentication bypass
Mitigations:
- Use strong asymmetric algorithms (RS256, ES256) instead of HS256
- Implement short token expiration times (5-15 minutes for access tokens)
- Rotate signing keys regularly
- Store private keys in Kubernetes secrets with encryption at rest
- Implement token introspection for sensitive operations
Challenges: Key rotation requires coordination across services; short expiration increases refresh token usage

Threat S.3: Session Hijacking via Token Theft

MITRE Technique: T1539 - Steal Web Session Cookie

Description: Attacker steals JWT tokens from client-side storage or network traffic
Impact: Account takeover
Mitigations:
- Enforce HTTPS/TLS for all communications
- Use HttpOnly and Secure flags for refresh tokens
- Implement token binding to client certificates or device fingerprints
- Use short-lived access tokens with refresh token rotation
- Implement anomaly detection (IP changes, user-agent changes)
Challenges: Token binding may break legitimate multi-device scenarios

Threat S.4: Compromised Service Account Credentials

MITRE Technique: T1078.004 - Valid Accounts: Cloud Accounts

Description: Service-to-service authentication credentials leaked or compromised
Impact: Lateral movement within cluster
Mitigations:
- Use Kubernetes service accounts with RBAC
- Implement OAuth2 client credentials flow with certificate-based authentication
- Rotate service account credentials regularly
- Use pod security policies to limit service account usage
- Implement network policies restricting pod-to-pod communication
Challenges: Service credential rotation can cause service disruptions

2. TAMPERING (Data Modification)

Threat T.1: JWT Claims Manipulation

MITRE Technique: T1565.002 - Data Manipulation: Transmitted Data Manipulation

Description: Attacker modifies JWT claims (roles, permissions, user ID) after issuance
Impact: Privilege escalation, unauthorized access
Mitigations:
- Use digital signatures (RS256/ES256) to ensure token integrity
- Validate token signature on every request in downstream services
- Implement claim validation (issuer, audience, expiration)
- Use JWE (JSON Web Encryption) for sensitive claims
Challenges: Performance overhead of signature verification on every request

Threat T.2: Configuration Tampering in Kubernetes

MITRE Technique: T1612 - Build Image on Host

Description: Malicious modification of Keycloak ConfigMaps, Secrets, or container images
Impact: Authentication bypass, backdoor creation
Mitigations:
- Implement RBAC limiting access to Keycloak namespace
- Use admission controllers (OPA/Gatekeeper) to validate configurations
- Enable audit logging for all configuration changes
- Use signed container images and image scanning
- Implement GitOps for configuration management with approval workflows
Challenges: Overly restrictive RBAC may hinder legitimate operations

Threat T.3: Database Tampering

MITRE Technique: T1565.001 - Data Manipulation: Stored Data Manipulation

Description: Direct manipulation of Keycloak's backend database (user credentials, roles, client secrets)
Impact: Complete authentication system compromise
Mitigations:
- Encrypt database at rest
- Use network policies to restrict database access to Keycloak pods only
- Implement database access logging and monitoring
- Use strong database authentication (certificate-based)
- Regular database backups with integrity verification
- Hash passwords with strong algorithms (bcrypt/PBKDF2)
Challenges: Performance impact of encryption; backup security management

Threat T.4: Man-in-the-Middle Attacks

MITRE Technique: T1557 - Adversary-in-the-Middle

Description: Interception and modification of traffic between API Gateway and Keycloak
Impact: Credential theft, session hijacking
Mitigations:
- Use mutual TLS (mTLS) between API Gateway and Keycloak
- Implement service mesh (Istio/Linkerd) with automatic mTLS
- Use certificate pinning where possible
- Monitor for certificate anomalies
Challenges: Certificate management complexity; service mesh overhead

3. REPUDIATION (Denying Actions)

Threat R.1: Insufficient Audit Logging

MITRE Technique: T1070 - Indicator Removal

Description: Lack of comprehensive logging allows attackers to hide their activities
Impact: Inability to detect, investigate, or prove security incidents
Mitigations:
- Enable Keycloak event logging for all authentication events
- Log to centralized logging system (ELK, Splunk, CloudWatch)
- Implement tamper-proof logging (write-once storage)
- Log: login attempts, token issuance, permission changes, admin actions
- Implement log retention policies (compliance requirements)
- Use structured logging (JSON format)
Challenges: Log volume management; storage costs; GDPR compliance for user data in logs

Threat R.2: Token Replay Attacks

MITRE Technique: T1550.001 - Use Alternate Authentication Material: Application Access Token

Description: Captured valid tokens are replayed by attackers
Impact: Unauthorized access using legitimate tokens
Mitigations:
- Implement token jti (JWT ID) claim with one-time use validation
- Use short token lifetimes
- Implement token revocation lists (though challenging at scale)
- Bind tokens to specific clients/IPs where appropriate
- Monitor for anomalous token usage patterns
Challenges: Stateless JWT benefits lost with revocation checking; performance impact

4. INFORMATION DISCLOSURE (Exposing Information)

Threat I.1: Exposed Secrets in Container Environment

MITRE Technique: T1552.007 - Unsecured Credentials: Container API

Description: Keycloak secrets, database credentials, or signing keys exposed via environment variables or config files
Impact: Complete authentication system compromise
Mitigations:
- Use Kubernetes secrets with encryption at rest enabled
- Implement external secrets management (HashiCorp Vault, AWS Secrets Manager)
- Use CSI drivers for secret injection
- Never embed secrets in container images
- Implement secret scanning in CI/CD pipelines
- Use workload identity where possible
Challenges: Secrets management complexity; application changes for external secret providers

Threat I.2: Information Leakage via Error Messages

MITRE Technique: T1213 - Data from Information Repositories

Description: Detailed error messages reveal system architecture, usernames, or configuration details
Impact: Intelligence gathering for targeted attacks
Mitigations:
- Configure generic error messages for authentication failures
- Disable stack traces in production
- Implement proper exception handling
- Log detailed errors server-side only
- Use separate logging for debug vs. production
Challenges: Balancing security with troubleshooting needs

Threat I.3: JWT Token Information Disclosure

MITRE Technique: T1552.001 - Unsecured Credentials: Credentials In Files

Description: JWT tokens contain sensitive information in claims (PII, internal IDs)
Impact: Privacy violations, information leakage
Mitigations:
- Minimize claims in JWT tokens (only essential data)
- Use opaque reference tokens for sensitive operations
- Implement JWE for encrypting token contents
- Avoid storing sensitive PII in tokens
- Use token introspection endpoint for detailed information
Challenges: Balance between token size and information needs; encryption overhead

Threat I.4: Keycloak Admin Console Exposure

MITRE Technique: T1190 - Exploit Public-Facing Application

Description: Admin console accessible from unintended networks or with weak authentication
Impact: Complete system compromise, user data breach
Mitigations:
- Restrict admin console to specific IPs/networks via NetworkPolicy
- Require MFA for all admin accounts
- Use separate admin realm with stricter security
- Implement time-based access restrictions
- Regular admin access reviews
- Use just-in-time admin access
Challenges: Emergency access scenarios; admin user experience

Threat I.5: Container Image Vulnerabilities

MITRE Technique: T1525 - Implant Internal Image

Description: Vulnerabilities in base images or Keycloak dependencies expose sensitive data
Impact: Container compromise, data exfiltration
Mitigations:
- Regular vulnerability scanning (Trivy, Clair, Snyk)
- Use minimal base images (distroless)
- Implement automated patching workflows
- Use admission controllers to block vulnerable images
- Monitor CVE feeds for Keycloak-specific vulnerabilities
Challenges: False positives in scanning; breaking changes in updates

5. DENIAL OF SERVICE (Resource Exhaustion)

Threat D.1: Authentication Request Flooding

MITRE Technique: T1499.002 - Endpoint Denial of Service: Service Exhaustion Flood

Description: Mass authentication requests overwhelm Keycloak
Impact: Legitimate users cannot authenticate
Mitigations:
- Implement rate limiting at API Gateway (per IP, per user)
- Configure Kubernetes resource limits (CPU, memory)
- Implement horizontal pod autoscaling (HPA)
- Use connection pooling for database
- Implement request queuing with circuit breakers
- Deploy Web Application Firewall (WAF)
Challenges: Distinguishing legitimate high traffic from attacks; autoscaling costs

Threat D.2: Token Generation Exhaustion

MITRE Technique: T1499.004 - Endpoint Denial of Service: Application or System Exploitation

Description: Attackers repeatedly request token refresh, exhausting resources
Impact: Service degradation or failure
Mitigations:
- Rate limit token refresh endpoints
- Implement token refresh quotas per user/session
- Use sliding window rate limiting
- Monitor token generation metrics
- Implement graceful degradation
Challenges: Legitimate apps with multiple services may hit limits

Threat D.3: Database Connection Pool Exhaustion

MITRE Technique: T1499.002 - Endpoint Denial of Service: Service Exhaustion Flood

Description: Excessive authentication requests exhaust database connections
Impact: Complete authentication service failure
Mitigations:
- Configure appropriate connection pool sizes
- Implement connection timeouts
- Use read replicas for token validation
- Cache frequently accessed data (realm configuration, client data)
- Implement database query optimization
Challenges: Cache invalidation complexity; consistency issues

Threat D.4: Resource Exhaustion via Slow Loris

MITRE Technique: T1499.001 - Endpoint Denial of Service: OS Exhaustion Flood

Description: Slow, prolonged connections exhaust container resources
Impact: Service unavailability
Mitigations:
- Configure connection timeouts at API Gateway and Keycloak
- Implement request size limits
- Use reverse proxy with timeout controls
- Monitor connection metrics
- Configure pod disruption budgets
Challenges: Slow legitimate clients may be affected

6. ELEVATION OF PRIVILEGE (Gaining Unauthorized Access)

Threat E.1: Container Escape

MITRE Technique: T1611 - Escape to Host

Description: Attacker exploits container runtime vulnerability to access Kubernetes node
Impact: Complete cluster compromise
Mitigations:
- Run containers as non-root users
- Implement Pod Security Standards (restricted profile)
- Use seccomp and AppArmor/SELinux profiles
- Disable privileged containers
- Keep container runtime updated
- Use RuntimeClass with sandboxed runtimes (gVisor, Kata)
Challenges: Application compatibility with security restrictions

Threat E.2: Privilege Escalation via Keycloak Vulnerabilities

MITRE Technique: T1068 - Exploitation for Privilege Escalation

Description: Exploiting Keycloak bugs to gain admin privileges
Impact: Complete authentication system control
Mitigations:
- Keep Keycloak updated to latest stable version
- Subscribe to security advisories
- Implement defense-in-depth (even admin can't access certain resources)
- Regular security assessments and penetration testing
- Implement role-based access control with principle of least privilege
Challenges: Update testing overhead; potential breaking changes

Threat E.3: Kubernetes RBAC Misconfiguration

MITRE Technique: T1078.004 - Valid Accounts: Cloud Accounts

Description: Overly permissive RBAC allows unauthorized access to Keycloak resources
Impact: Configuration tampering, credential theft
Mitigations:
- Implement least privilege RBAC policies
- Regular RBAC audits
- Use namespace isolation
- Implement admission controllers for policy enforcement
- Monitor for privilege escalation attempts
Challenges: RBAC complexity; operational overhead

Threat E.4: Client Secret Compromise Leading to Privilege Escalation

MITRE Technique: T1552.001 - Unsecured Credentials: Credentials In Files

Description: Compromised OAuth2 client credentials used to gain elevated access
Impact: Access to resources beyond intended scope
Mitigations:
- Use public clients with PKCE for SPAs and mobile apps
- Rotate client secrets regularly
- Implement client authentication with mutual TLS
- Use dynamic client registration carefully
- Audit client configurations regularly
- Implement scope validation and least privilege
Challenges: Managing secret rotation across multiple services

Threat E.5: Admin REST API Exploitation

MITRE Technique: T1212 - Exploitation for Credential Access

Description: Unauthorized access to Keycloak Admin REST API
Impact: Complete realm manipulation, user data access
Mitigations:
- Restrict Admin API access via network policies
- Require separate authentication for Admin API
- Implement API rate limiting
- Use IP allowlisting for admin operations
- Enable comprehensive audit logging for admin actions
Challenges: Legitimate automation may require admin API access

Additional Kubernetes-Specific Threats

Threat K.1: Sidecar Container Injection

MITRE Technique: T1525 - Implant Internal Image

Description: Malicious sidecar containers injected to intercept Keycloak traffic
Impact: Credential theft, traffic manipulation
Mitigations:
- Use admission webhooks to validate pod specifications
- Implement Pod Security Admission
- Monitor for unexpected container additions
- Use service mesh with mTLS
Challenges: Legitimate sidecars (logging, monitoring) need allowlisting

Threat K.2: Supply Chain Attacks

MITRE Technique: T1195.002 - Supply Chain Compromise: Compromise Software Supply Chain

Description: Compromised Keycloak container images or dependencies
Impact: Backdoors, malware in authentication system
Mitigations:
- Use official Keycloak images only
- Implement image signing and verification
- Use private container registry with scanning
- Implement Software Bill of Materials (SBOM)
- Regular dependency audits
Challenges: False positives; trusted source verification

JWT-Specific Threats in Downstream Applications

Threat J.1: Algorithm Confusion Attacks

MITRE Technique: T1556 - Modify Authentication Process

Description: Attacker changes JWT algorithm from RS256 to HS256, using public key as HMAC secret
Impact: Token forgery, authentication bypass
Mitigations:
- Explicitly specify and validate expected algorithm
- Never accept "none" algorithm
- Use JWT libraries with algorithm validation
- Implement JWK (JSON Web Key) sets with proper validation
Challenges: Requires proper library configuration in all consuming services

Threat J.2: Token Substitution Attacks

MITRE Technique: T1134 - Access Token Manipulation

Description: Valid token from one context used in another unauthorized context
Impact: Unauthorized access to resources
Mitigations:
- Validate audience (aud) claim strictly
- Implement resource-specific tokens
- Use scope validation
- Validate token issuer (iss) claim
Challenges: Complex multi-tenant or multi-service architectures

Cross-Cutting Security Measures

Network Security

Implement NetworkPolicies: Restrict egress/ingress to only necessary services
Use Service Mesh: Automatic mTLS, traffic control, observability
Segment Networks: Separate Keycloak, database, and application networks

Monitoring & Detection

SIEM Integration: Feed all logs to security information and event management
Anomaly Detection: ML-based detection of unusual authentication patterns
Metrics Monitoring: Track failed authentications, token generation rates, latency
Alert on: Multiple failed logins, unusual token patterns, configuration changes

Compliance & Governance

Regular Security Audits: Penetration testing, code reviews
Compliance Frameworks: GDPR, SOC2, ISO 27001 considerations
Incident Response Plan: Documented procedures for breach scenarios
Regular Updates: Patch management schedule

Key Challenges Summary

Performance vs. Security Trade-offs: Token validation, encryption, and logging impact performance
Operational Complexity: Secret rotation, certificate management, and configuration across multiple services
User Experience: Security measures (MFA, rate limiting) may frustrate legitimate users
Stateless vs. Stateful Dilemma: JWT benefits of statelessness conflict with revocation needs
Multi-Service Coordination: Consistent security implementation across consuming applications
Cloud-Native Complexity: Kubernetes adds layers of potential vulnerabilities
Compliance Requirements: GDPR, data retention policies complicate logging and monitoring
Emergency Access: Balancing security restrictions with operational needs during incidents

Priority Recommendations

Critical (Implement Immediately):

Enable mTLS between all components
Implement strong RBAC in Kubernetes
Use external secrets management
Enable comprehensive audit logging
Implement JWT signature validation with RS256

High Priority:

Deploy service mesh for automatic security
Implement MFA for all accounts
Set up rate limiting and DDoS protection
Regular vulnerability scanning and patching
Network segmentation with NetworkPolicies

Medium Priority:
1.Implement token binding/device fingerprinting

Deploy SIEM with anomaly detection
Regular penetration testing
Implement JWE for sensitive claims
Automated secret rotation

This threat model should be reviewed quarterly and updated as the architecture evolves or new threats emerge.

Keycloak tm1

sen — Fri, 14 Nov 2025 11:51:16 +0000

Scope and assumptions

Deployment: Keycloak running in a Kubernetes pod(s) inside a cluster, reachable only via an internal REST API gateway (no direct external access).
Purpose: Keycloak is the authentication provider issuing JWTs consumed by other applications after successful authentication.
Components considered: Keycloak pods, ingress/internal API gateway, Service/ClusterIP, ConfigMaps/Secrets, PersistentVolumes (if used for DB/backups), underlying K8s control plane (API server, etcd), network policies, and client applications that accept JWTs.
Threat model method: STRIDE applied to data flows and components; each threat lists likely MITRE ATT&CK techniques (TIDs described conceptually), mitigations, and operational challenges.

Data flow (high level)

User/client → API gateway (TLS) → Keycloak (internal REST) for authentication.
Keycloak authenticates user (userstore, social/LDAP, or federated IdP) and issues a JWT.
Client presents JWT to other services behind the gateway; services validate token signature, claims, expiry, etc.
Keycloak contacts backing services (database, user federation, SMTP, token revocation/INTrospect endpoints).

STRIDE threats, MITRE technique mappings, and mitigations

Spoofing (identity impersonation)

Threats:
- Attacker forges requests to Keycloak or the gateway impersonating internal services or users.
- Compromised service account or API key used to call Keycloak admin endpoints.
- Stolen admin credentials or session cookies allow console access.
MITRE techniques (examples):
- Valid Accounts; Credential Access; Abuse of Credentials; Use of Compromised Accounts.
Mitigations:
- Mutual TLS between API gateway and Keycloak; enforce client certs for internal service-to-service calls.
- Use short-lived, scoped service accounts (K8s) with minimal RBAC; avoid long-lived static tokens.
- Enforce strong MFA for Keycloak admin console and privileged APIs.
- Rotate and store secrets in a secure vault; do not store admin credentials in ConfigMaps.
- Log and alert on anomalous admin or service-account activity.
Challenges:
- Managing mTLS certificates lifecycle across pods and gateways.
- Ensuring zero-trust internal network posture without breaking legacy flows.

Tampering (modification of data, configs, or code)

Threats:
- Modification of JWT validation logic, Keycloak configuration, or themes via compromised image or malicious ConfigMap.
- Tampering with token storage or refresh token flows (e.g., modifying DB entries).
- Man-in-the-middle altering JWTs in transit if TLS misconfigured.
MITRE techniques:
- Modify System Image; Hijack Execution Flow; Manipulate Data; Ingress Tool Transfer.
Mitigations:
- Use image signing and image policy admission controllers (e.g., in-toto, Sigstore, Notary).
- Protect ConfigMaps/Secrets: mark secrets, mount-only where required, use KMS-backed SecretStores.
- Immutable infrastructure patterns: avoid manual in-cluster edits; use GitOps for config changes with PR reviews.
- Enable and enforce TLS for all in-cluster traffic; use network policies to limit egress/ingress.
- Run Keycloak with read-only filesystem where possible and minimal container privileges.
Challenges:
- Deploying and operating image signing and admission controllers reliably.
- Migrating legacy operational patterns to GitOps and immutable configs.

Repudiation (deny actions were taken)

Threats:
- Lack of reliable audit logs for authentication events, admin changes, token issuance/revocation.
- Log tampering or loss (e.g., attacker deletes or modifies logs in pod).
MITRE techniques:
- Indicator Removal on Host; Log Deletion or Manipulation.
Mitigations:
- Centralize and append-only store logs to an external SIEM or logging cluster (use TLS + authentication to ingest).
- Enable Keycloak audit logging (admin events, user events) and secure log pipeline with integrity checks.
- Retain immutable audit trails (WORM) for a defined retention period.
- Use kubernetes audit logging for K8s API server activity; monitor for suspicious RBAC changes.
Challenges:
- Cost and complexity of secure, immutable logging.
- Ensuring logs contain necessary context (JWT IDs, request IDs) without leaking sensitive data.

Information Disclosure (exposure of sensitive data)

Threats:
- Secrets (client secrets, signing keys, database credentials) exposed in etcd, ConfigMaps, or logs.
- JWTs leaked via insecure storage, logs, or overly permissive CORS on services consuming JWTs.
- Backup or snapshot exposure containing Keycloak data.
MITRE techniques:
- Exfiltration Over Alternative Protocols; Data from Information Repositories.
Mitigations:
- Encrypt secrets at rest (etcd encryption, KMS) and in transit. Restrict etcd access to control plane only.
- Use hardware-backed key management for JWT signing keys (HSM or cloud KMS). Rotate signing keys with overlap/rollover strategy.
- Avoid logging full JWTs or sensitive claims; mask or redact tokens in logs.
- Apply least privilege to RBAC and network policies; restrict access to backups and PVs.
- Limit token lifetime and scope; use audience and issuer claims strictly.
Challenges:
- Key rotation without breaking token validation across multiple services.
- Ensuring third-party federated IdPs adhere to same secrecy standards.

Denial of Service (availability)

Threats:
- High authentication request volume (DDoS) to Keycloak or API gateway causing outage.
- Resource exhaustion in the pod (CPU/memory) or backing DB leading to failed auths.
- Misconfigured liveness/readiness causing cascading restarts during spikes.
MITRE techniques:
- Network Denial of Service; Resource Hijacking; Service Stop.
Mitigations:
- Put rate-limiting / throttling at the API gateway; per-IP and per-client quotas.
- Autoscale Keycloak horizontally with proper session affinity handling and a robust database tier (connection pooling).
- Use resource requests/limits and QoS classes in Kubernetes; reserve node capacity for critical auth components.
- Implement circuit breakers and graceful degradation for downstream services if auth unavailable.
- Monitor realistic SLA and create alerts for auth latency/availability anomalies.
Challenges:
- Statefulness of sessions and single-signer JWT handling complicate horizontal scaling.
- Balancing rate limits to block abuse without blocking legitimate burst traffic.

Elevation of Privilege (gain higher privileges)

Threats:
- Exploits in Keycloak or its dependencies allowing admin privilege escalation or remote code execution.
- Misconfigured RBAC or overly broad client roles allowing privilege abuse.
- Compromised container allowing access to K8s node credentials or host filesystem.
MITRE techniques:
- Exploit Public-Facing Application; Privilege Escalation; Abuse Elevated Permissions.
Mitigations:
- Keep Keycloak and dependencies patched; subscribe to security advisories and have a patching process.
- Harden container runtime: run as non-root, drop Linux capabilities, use seccomp and AppArmor/SELinux profiles.
- Implement least-privilege RBAC both in Keycloak (clients, roles) and Kubernetes (ServiceAccounts).
- Use Pod Security Policies / OPA/Gatekeeper policies to prevent privileged pods or hostPath mounts.
- Scan images and run vulnerability scanning in CI; block known vulnerable images from deployment.
Challenges:
- Timely patching in environments requiring high stability.
- Legacy integrations that require elevated permissions.

Additional JWT-specific threats and mitigations

Threat: Replay of stolen JWTs.
- Mitigation: Short JWT lifetime; use refresh tokens with rotation and detection; include jti and nonce and optional token revocation lists or introspection for high-sensitivity flows.
- Challenge: Performance/complexity of token introspection at scale; balancing stateless JWT benefits vs revocation needs.
Threat: JWT signature algorithm downgrade or misconfiguration (e.g., none algorithm or weak key).
- Mitigation: Enforce strong algorithms (RS256/ES256), validate "alg", rotate keys securely, use KMS/HSM for private keys.
- Challenge: Coordinating key rollover across services and clients.
Threat: Incorrect claim validation (audience, issuer, expiry).
- Mitigation: Standardize validation library usage; publish JWKS endpoint securely behind gateway; enforce claim checks in all consuming services.
- Challenge: Legacy clients may accept tokens leniently.

Mapping to MITRE ATT&CK: practical examples

Credential theft → Valid Accounts / Credential Access: attacker steals Keycloak admin password or service account token.
Lateral movement → Internal Spearphishing / Use of Valid Accounts: compromised pod uses cluster network to call Keycloak admin APIs.
Persistence → Create or Modify System Process: attacker modifies startup to maintain access.
Defense evasion → Credential dumping; log deletion: attacker tampers with Keycloak logs.

Mitigation tiers and prioritized recommendations

Preventive (highest priority)
- Enforce mTLS between gateway and Keycloak; restrict Keycloak Service to internal cluster network only.
- Protect signing keys in KMS/HSM and rotate keys; enable etcd encryption and KMS-backed secrets.
- Harden containers (non-root, seccomp, read-only FS) and enforce admission policies for images.
- Strong RBAC and MFA for admin operations; no static admin credentials in code.
Detective
- Centralized immutable logging and alerting for admin events, auth anomalies, suspicious token issuance, and configuration changes.
- Runtime monitoring: anomalous authentication rates, failed logins, privilege changes.
Responsive
- Token revocation & introspection capability and incident runbooks for compromised keys/accounts.
- Rapid patching and rollback procedures; blue-green or canary for breaking changes.

Operational challenges and residual risks

Key rotation: coordinating signing key rotation so currently valid JWTs remain accepted while moving to new keys requires design (JWKS with key identifiers and overlap).
Token revocation vs statelessness: adding revocation/introspection reintroduces state and latency; must be engineered for scale.
Internal trust assumptions: "internal-only" network can be breached; insider threats and lateral movement remain a major risk.
Performance vs security trade-offs: strict validation, introspection, and logging add overhead; must be balanced with SLAs.
Third-party identity providers: security posture of federated IdPs affects the whole system; limited control over external IdP vulnerabilities.
Secret sprawl: multiple clients and environments increase key/secret management complexity.

Practical checklist (actionable)

Enforce mTLS and internal-only Service type for Keycloak.
Store signing keys in KMS/HSM; reject plain secret private keys in cluster.
Shorten JWT lifetime; implement refresh-token rotation with revocation.
Centralize admin and user event logs to an immutable SIEM.
Enforce image signing and admission controller policies.
Harden RBAC in Keycloak and K8s; require MFA for admin access.
Apply network policies to restrict pod-to-pod access.
Run regular pentests and CVE/patch management for Keycloak and components.
Implement rate-limiting and WAF rules at the gateway; monitor for auth floods.
Document incident playbooks for key compromise and mass token revocation.

sftp threat model - perplexity

sen — Wed, 30 Jul 2025 09:28:25 +0000

Here is a threat model for a machine-to-machine SFTP connection used for file exchange, based on the STRIDE methodology and aligned with MITRE ATT&CK techniques.

Threat Model: Machine-to-Machine SFTP File Exchange

Context: Secure File Transfer Protocol (SFTP) is used for automated, secure file transfers between machines. It relies on SSH for encryption and authentication to protect data in transit.

STRIDE Categories Applied to SFTP Connection

1. Spoofing (Identity Forgery)

Threats:

An attacker impersonates a legitimate machine or user to gain unauthorized SFTP access.
Weak or compromised SSH keys/passwords can enable spoofing.
Man-in-the-Middle (MitM) attacks on SSH handshake. MITRE Techniques:
T1078 (Valid Accounts): Use of stolen credentials or keys to authenticate.
T1556 (Modify Authentication Process): Attacker modifies authentication to bypass controls.

2. Tampering (Data Manipulation)

Threats:

Unauthorized modification of files during transfer or on the server due to insufficient integrity checks.
Alteration of SFTP server or client configurations to introduce vulnerabilities. MITRE Techniques:
T1565 (Data Manipulation): Changing files in transit or at rest.
T1609 (Container and Resource Hijacking): Manipulating containerized SFTP setups or environment.

3. Repudiation (Denial of an Action)

Threats:

Lack of adequate logging makes it possible for an entity to deny performing file transfers or modifications.
Insufficient audit trails on file uploads/downloads. MITRE Techniques:
T1078 (Valid Accounts): Since legitimate credentials might be used, evidence can be hard to distinguish.
T1622 (Indirect Command Execution): Actions performed via automated scripts without user accountability.

4. Information Disclosure (Data Exposure)

Threats:

Exposure of sensitive data if encryption is misconfigured or disabled.
Compromise of SSH keys leading to unauthorized decryption of traffic.
Server misconfigurations allowing directory listing or unauthorized file access. MITRE Techniques:
T1537 (Transfer Data to Cloud Account): Exfiltrated data via compromised SFTP.
T1040 (Network Sniffing): Intercepting unencrypted SFTP traffic if encryption is weak or bypassed.

5. Denial of Service (Service Disruption)

Threats:

Flooding SFTP server with connection requests to exhaust resources.
Exploiting server misconfigurations leading to crashes or lockouts. MITRE Techniques:
T1499 (Endpoint Denial of Service): Overloading SFTP endpoint.
T1022 (Data Encrypted for Impact): Encrypting data or system components making SFTP ineffective.

6. Elevation of Privilege (Unauthorized Access Rights Increase)

Threats:

Exploiting vulnerabilities in SSH or SFTP server software to gain higher privileges.
Improper file permissions allowing access escalation. MITRE Techniques:
T1068 (Exploitation for Privilege Escalation): Attacker exploits flaws to gain root/admin on SFTP server.
T1617 (Access Token Manipulation): Leveraging valid tokens for privilege escalation.

Additional Considerations for Machine-to-Machine SFTP

Authentication Methods: Prefer public key authentication over passwords to mitigate spoofing risks. Rotate and protect SSH keys diligently[1][3].
Configuration Hardening: Ensure strict file and directory permissions. Disable unused SSH/SFTP features and monitor configurations for unauthorized changes[1][7].
Logging and Monitoring: Maintain comprehensive logs of file transfer operations and SSH sessions to mitigate repudiation and facilitate incident response[1][4].
Patch Management: Regularly update SSH and SFTP server software to fix known vulnerabilities that could be exploited for tampering or privilege elevation[1].
Network Controls: Use firewall rules and IP whitelisting to restrict SFTP access to trusted machines[1][7].
Encryption Integrity: Employ strong SSH encryption algorithms and verify server fingerprints to prevent MitM and interception[3].

This threat model combines STRIDE with MITRE ATT&CK techniques related to credential use, data manipulation, denial of service, and privilege escalation consistent with risks intrinsic to SFTP-based automated file exchange between machines.

If you want, I can also provide a tabular or more detailed report for each STRIDE category with specific mitigations. Would you like that?

[1] https://www.kiteworks.com/secure-file-transfer/sftp-vulnerabilities/
[2] https://www.iriusrisk.com/resources-blog/threat-modeling-methodology-stride
[3] https://www.kiteworks.com/secure-file-transfer/sftp-security/
[4] https://www.jit.io/resources/app-security/stride-threat-model-a-complete-guide
[5] https://www.reddit.com/r/AskTechnology/comments/icmfwp/is_sftp_really_the_most_secure_way_of/
[6] https://ctid.mitre.org/projects/threat-modeling-with-attack/
[7] https://jadaptive.com/push-sftp/advanced-sftp-server-configuration-and-security-best-practices/
[8] https://attack.mitre.org/techniques/T1570/
[9] https://www.jscape.com/blog/why-more-it-professionals-are-switching-from-basic-sftp-server-software-to-mft
[10] https://www.practical-devsecops.com/types-of-threat-modeling-methodology/

SFTP threat model by Claude

sen — Tue, 29 Jul 2025 11:49:28 +0000

SFTP Machine-to-Machine Threat Model

STRIDE Methodology + MITRE ATT&CK Framework

System Architecture Overview

Components:

Client Server (Server A): Initiates SFTP connections, automated file transfers
SFTP Server (Server B): Receives connections, hosts files, manages access
Network Infrastructure: Routers, switches, firewalls between servers
Credential Management: Key stores, certificate authorities, secret management
File Systems: Local and shared storage for file operations
Monitoring Systems: Logs, SIEM, security monitoring tools

Trust Boundaries:

Network perimeter (internal vs external networks)
Server boundaries (OS kernel, application space)
Credential storage boundaries
File system access boundaries

S - SPOOFING IDENTITY

Threat Scenarios & MITRE ATT&CK Techniques

T1.1: Server Identity Spoofing

MITRE Techniques:

T1557.002 - Man-in-the-Middle: ARP Cache Poisoning
- Attacker poisons ARP tables to intercept traffic
- Redirects SFTP connections to malicious server
T1590.005 - Gather Victim Network Information: IP Addresses
- Reconnaissance to identify target server addresses
T1556.003 - Modify Authentication Process: Pluggable Authentication Modules
- Compromise authentication mechanisms on target server

Attack Vectors:

DNS spoofing/cache poisoning to redirect Server A to malicious endpoint
BGP hijacking to route traffic through attacker infrastructure
Certificate authority compromise to issue fraudulent certificates

T1.2: Client Credential Compromise

MITRE Techniques:

T1552.004 - Unsecured Credentials: Private Keys
- Extract SSH private keys from compromised systems
T1555.003 - Credentials from Password Stores: Credentials from Web Browsers
- Harvest stored credentials from management interfaces
T1078.002 - Valid Accounts: Domain Accounts
- Use compromised service accounts for unauthorized access

Attack Vectors:

Memory dumping to extract private keys from running processes
File system access to steal credential files
Supply chain attacks targeting credential management tools

Countermeasures:

C1.1: Certificate pinning and HPKP (HTTP Public Key Pinning)
C1.2: Mutual TLS authentication with hardware-backed certificates
C1.3: Network monitoring for ARP/DNS anomalies
C1.4: Regular credential rotation with automated key management

T - TAMPERING WITH DATA

Threat Scenarios & MITRE ATT&CK Techniques

T2.1: Data Modification in Transit

MITRE Techniques:

T1040 - Network Sniffing
- Capture network traffic for analysis and modification
T1557.001 - Man-in-the-Middle: LLMNR/NBT-NS Poisoning
- Intercept and modify network communications
T1601.002 - Modify System Image: Downgrade System Image
- Force use of weaker encryption protocols

Attack Vectors:

SSL/TLS downgrade attacks forcing weaker ciphers
Protocol manipulation to bypass integrity checks
Network appliance compromise for traffic modification

T2.2: File System Tampering

MITRE Techniques:

T1565.001 - Data Manipulation: Stored Data Manipulation
- Modify files on source or destination servers
T1070.004 - Indicator Removal on Host: File Deletion
- Remove evidence of file tampering
T1222.002 - File and Directory Permissions Modification: Linux and Mac File and Directory Permissions Modification
- Alter permissions to enable unauthorized access

Attack Vectors:

Rootkit installation for persistent file system access
Backup system compromise to modify archived files
Configuration file tampering to alter transfer behavior

Countermeasures:

C2.1: End-to-end encryption with authenticated encryption modes
C2.2: File integrity monitoring (FIM) with cryptographic hashes
C2.3: Immutable infrastructure and infrastructure as code
C2.4: Digital signatures for critical files and configurations

R - REPUDIATION

Threat Scenarios & MITRE ATT&CK Techniques

T3.1: Log Tampering and Evidence Destruction

MITRE Techniques:

T1070.001 - Indicator Removal on Host: Clear Windows Event Logs
- Delete authentication and transfer logs
T1070.002 - Indicator Removal on Host: Clear Linux or Mac System Logs
- Remove evidence of unauthorized activities
T1562.002 - Impair Defenses: Disable Windows Event Logging
- Prevent future logging of activities

Attack Vectors:

Log server compromise to modify audit trails
Time synchronization attacks to create timeline confusion
Credential theft to perform actions under legitimate identities

T3.2: Transaction Denial

MITRE Techniques:

T1070.006 - Indicator Removal on Host: Timestomp
- Modify file timestamps to hide activities
T1036.005 - Masquerading: Match Legitimate Name or Location
- Disguise malicious activities as legitimate operations

Countermeasures:

C3.1: Immutable audit logging with cryptographic integrity
C3.2: Multi-destination log streaming to prevent single point of failure
C3.3: Blockchain-based audit trails for critical transactions
C3.4: Time synchronization with authenticated NTP servers

I - INFORMATION DISCLOSURE

Threat Scenarios & MITRE ATT&CK Techniques

T4.1: Credential and Key Exposure

MITRE Techniques:

T1552.001 - Unsecured Credentials: Credentials In Files
- Extract credentials from configuration files
T1005 - Data from Local System
- Access sensitive files on compromised systems
T1140 - Deobfuscate/Decode Files or Information
- Decrypt or decode stored credential material

Attack Vectors:

Memory forensics to extract encryption keys
Configuration file exposure through web servers
Environment variable disclosure in process listings

T4.2: Traffic Analysis and Data Interception

MITRE Techniques:

T1040 - Network Sniffing
- Capture and analyze network traffic patterns
T1020 - Automated Exfiltration
- Systematically steal data through compromised channels
T1041 - Exfiltration Over C2 Channel
- Use command and control infrastructure for data theft

Attack Vectors:

Side-channel attacks on encryption implementations
Traffic pattern analysis to infer sensitive information
Compromised network infrastructure for data collection

Countermeasures:

C4.1: Hardware Security Modules (HSMs) for key protection
C4.2: Perfect Forward Secrecy (PFS) in all encrypted communications
C4.3: Traffic padding and dummy transactions to obscure patterns
C4.4: Zero-knowledge architecture for credential management

D - DENIAL OF SERVICE

Threat Scenarios & MITRE ATT&CK Techniques

T5.1: Resource Exhaustion Attacks

MITRE Techniques:

T1498.001 - Network Denial of Service: Direct Network Flood
- Overwhelm network infrastructure with traffic
T1499.004 - Endpoint Denial of Service: Application or System Exploitation
- Exploit application vulnerabilities to cause crashes
T1565.003 - Data Manipulation: Runtime Data Manipulation
- Modify system behavior to cause resource exhaustion

Attack Vectors:

SSH connection flooding to exhaust server resources
Large file upload attacks to consume storage
Fork bomb attacks through compromised accounts

T5.2: Infrastructure Disruption

MITRE Techniques:

T1489 - Service Stop
- Stop critical services required for SFTP operations
T1529 - System Shutdown/Reboot
- Force system restarts to disrupt operations
T1485 - Data Destruction
- Delete critical system files or configurations

Countermeasures:

C5.1: Rate limiting and connection throttling
C5.2: Resource quotas and monitoring with automated responses
C5.3: Redundant infrastructure with automated failover
C5.4: DDoS protection at multiple network layers

E - ELEVATION OF PRIVILEGE

Threat Scenarios & MITRE ATT&CK Techniques

T6.1: SSH Service Exploitation

MITRE Techniques:

T1068 - Exploitation for Privilege Escalation
- Exploit SSH daemon vulnerabilities for root access
T1055.012 - Process Injection: Process Hollowing
- Inject malicious code into SSH processes
T1543.002 - Create or Modify System Process: Systemd Service
- Create persistent backdoors through system services

Attack Vectors:

Buffer overflow attacks against SSH implementations
Configuration vulnerabilities (weak ciphers, root login enabled)
Race condition exploits in file handling

T6.2: Container and Virtualization Escapes

MITRE Techniques:

T1611 - Escape to Host
- Break out of containerized environments
T1055.001 - Process Injection: Dynamic-link Library Injection
- Inject malicious libraries into running processes
T1134.001 - Access Token Manipulation: Token Impersonation/Theft
- Steal and impersonate privileged access tokens

Attack Vectors:

Container runtime vulnerabilities for host access
Kernel exploits through syscall interfaces
Shared resource exploitation (shared volumes, networks)

T6.3: Lateral Movement

MITRE Techniques:

T1021.004 - Remote Services: SSH
- Use compromised credentials for lateral movement
T1550.003 - Use Alternate Authentication Material: Pass the Ticket
- Reuse authentication tokens across systems
T1080 - Taint Shared Content
- Modify shared files to compromise additional systems

Countermeasures:

C6.1: Principle of least privilege with mandatory access controls
C6.2: Container security with runtime protection
C6.3: Regular vulnerability scanning and automated patching
C6.4: Network microsegmentation and zero-trust architecture

Advanced Persistent Threat (APT) Scenarios

APT Scenario 1: Supply Chain Compromise

MITRE Techniques Chain:

T1195.002 - Supply Chain Compromise: Compromise Software Supply Chain
T1554 - Compromise Client Software Binary
T1078.002 - Valid Accounts: Domain Accounts
T1020 - Automated Exfiltration

Attack Flow:

Compromise SFTP client software or libraries
Establish persistent backdoor in client systems
Harvest credentials and perform automated data exfiltration
Use legitimate channels to avoid detection

APT Scenario 2: Living Off The Land

MITRE Techniques Chain:

T1078.003 - Valid Accounts: Local Accounts
T1021.004 - Remote Services: SSH
T1083 - File and Directory Discovery
T1005 - Data from Local System
T1041 - Exfiltration Over C2 Channel

Attack Flow:

Compromise legitimate service accounts
Use SSH for authorized but malicious access
Perform reconnaissance using standard system tools
Exfiltrate data through legitimate protocols

Risk Assessment Matrix

Threat ID	STRIDE Category	MITRE Technique	Likelihood	Impact	Risk Level
T1.1	Spoofing	T1557.002	Medium	High	High
T1.2	Spoofing	T1552.004	High	Critical	Critical
T2.1	Tampering	T1040, T1557.001	Low	High	Medium
T2.2	Tampering	T1565.001	Medium	High	High
T3.1	Repudiation	T1070.001/002	Medium	Medium	Medium
T4.1	Info Disclosure	T1552.001	High	Critical	Critical
T4.2	Info Disclosure	T1040	Medium	High	High
T5.1	DoS	T1498.001	High	Medium	Medium
T5.2	DoS	T1489	Low	High	Medium
T6.1	Privilege Escalation	T1068	Low	Critical	High
T6.2	Privilege Escalation	T1611	Medium	Critical	High
T6.3	Privilege Escalation	T1021.004	High	High	Critical

Detection and Monitoring Framework

MITRE ATT&CK-Based Detection Rules

Credential Access Detection:

- Monitor for: T1552.004 (Private Keys)
  - File access to .ssh directories
  - Unusual process access to key files
  - Memory dumps of SSH processes

- Monitor for: T1555.003 (Password Stores)
  - Access to credential management APIs
  - Unusual queries to secret management systems

Lateral Movement Detection:

- Monitor for: T1021.004 (SSH)
  - SSH connections from unusual source IPs
  - Multiple failed authentication attempts
  - SSH sessions outside normal business hours
  - Connections to unusual destination ports

Defense Evasion Detection:

- Monitor for: T1070.001/002 (Log Clearing)
  - Log deletion events
  - Log service stopping/starting
  - Unusual log volume changes

Behavioral Analytics

Baseline normal M2M communication patterns
Detect anomalies in file transfer volumes, timing, and destinations
Monitor for unusual network traffic patterns
Track credential usage patterns and detect anomalies

Implementation Roadmap

Phase 1: Critical Risk Mitigation (0-30 days)

Implement secure credential management (HSM/Vault)
Deploy certificate-based authentication
Enable comprehensive audit logging
Implement network monitoring for ATT&CK techniques

Phase 2: Defense in Depth (30-90 days)

Deploy file integrity monitoring
Implement network microsegmentation
Set up behavioral analytics and anomaly detection
Establish incident response procedures

Phase 3: Advanced Security (90+ days)

Deploy zero-trust architecture
Implement advanced threat hunting capabilities
Establish threat intelligence integration
Conduct regular red team exercises

Continuous Operations

Monthly credential rotation
Quarterly vulnerability assessments
Annual penetration testing with MITRE ATT&CK framework
Continuous monitoring and alerting
Regular threat model updates based on new attack techniques