Lesson 05 — Persistence & Defense Evasion

Welcome

Gaining access to a cloud environment is only one stage of an adversary operation.

A sophisticated attacker may attempt to maintain access after the original entry point has been removed. They may also try to reduce the likelihood that security teams detect or investigate their activity.

These objectives are known as:

Persistence — maintaining access over time
Defense Evasion — avoiding, weakening, or bypassing security controls and visibility

In cloud environments, persistence rarely depends on installing software on a single server.

Instead, persistence may involve identities, permissions, automation systems, workload configurations, event-driven services, deployment pipelines, trust relationships, and cloud-native resources.

Examples include:

An unexpected identity assignment
A newly trusted principal
An unauthorized automation account
A modified CI/CD workflow
A scheduled serverless function
A Kubernetes workload configured to restart automatically
An additional credential attached to an application identity
A change to a resource policy
A long-lived cloud session
A hidden or poorly governed deployment path

Defense evasion may involve attempts to:

Reduce logging coverage
Modify monitoring configurations
Use trusted services to blend with normal activity
Operate through existing automation
Avoid high-volume activity
Use temporary credentials
Hide inside approved workflows
Exploit gaps between cloud providers and security tools

A professional Cloud Red Team does not disable production logging, deploy uncontrolled backdoors, or conceal malicious activity from the customer.

Instead, the Red Team evaluates whether persistence and defense-evasion conditions exist, safely validates approved scenarios, measures defensive visibility, and provides evidence-driven recommendations.

Authorization requirement: Persistence and defense-evasion testing must use dedicated test identities, synthetic resources, approved workloads, limited time windows, documented rollback procedures, and explicit written authorization. Never create uncontrolled access, disable production security controls, conceal activity from the control team, or leave test artifacts active after the engagement.

Learning Objectives

After completing this lesson, you will be able to:

Explain persistence in cloud environments.
Explain defense evasion in cloud environments.
Identify cloud-native persistence surfaces.
Review identity-based persistence risks.
Assess credentials and trust relationships.
Review CI/CD and automation persistence.
Assess Kubernetes and container persistence.
Review serverless persistence conditions.
Identify logging and monitoring weaknesses.
Understand how legitimate cloud services may conceal attacker activity.
Build persistence and defense-evasion attack-path maps.
Design safe persistence simulations.
Apply strict operational decision gates.
Validate monitoring and incident-response controls.
Remove all temporary artifacts.
Document business impact and remediation priorities.

Business Scenario

CloudNova Technologies is performing an authorized Cloud Red Team engagement for MedSecure Global.

The Red Team has already demonstrated a controlled attack path from a low-privilege development identity to an approved synthetic data asset.

Executive leadership now wants to determine whether a realistic attacker could:

Maintain access after the initial test credential is revoked.
Re-enter the approved environment through an automation or workload identity.
Create a controlled persistence mechanism inside a test account.
Use trusted cloud services to blend with normal activity.
Identify gaps in logging and detection.
Test whether the SOC can discover and remove the persistence mechanism.
Confirm that all temporary Red Team access can be completely removed.

The Rules of Engagement permit:

Dedicated Red Team test identities
Temporary role assignments
Synthetic credentials
Test-only serverless schedules
Test Kubernetes workloads
Approved CI/CD workflows
Detection validation
Controlled incident-response exercises

The Rules of Engagement prohibit:

Modifying production logging
Disabling security controls
Creating hidden access in production
Installing malware
Using real employee credentials
Accessing real customer data
Leaving active persistence after the test
Interacting with unapproved accounts or third parties
Concealing Red Team activity from the control team

Your objective is to identify persistence opportunities, validate one approved test scenario, evaluate defensive visibility, and confirm that all temporary access is removed.

What Is Cloud Persistence?

Cloud persistence is the ability to regain or maintain access to cloud resources after the original access method has been removed.

Cloud persistence may rely on:

Identities
Credentials
Roles
Trust relationships
Workloads
Automation
Scheduled services
Resource policies
Deployment systems
Federated access
Cloud-native integrations

Unlike persistence on a traditional endpoint, cloud persistence may survive:

Virtual machine replacement
Container restarts
Function redeployments
Password changes
Individual session termination
Infrastructure scaling
Application updates

This makes identity, automation, and governance especially important.

What Is Defense Evasion?

Defense evasion refers to actions intended to avoid prevention, detection, investigation, or containment.

In a cloud environment, defense evasion may involve:

Using legitimate administrative tools
Operating through approved services
Performing low-volume actions
Using temporary credentials
Leveraging automation accounts
Exploiting incomplete log coverage
Using cross-account relationships
Acting from expected cloud infrastructure
Hiding activity within normal deployment workflows
Taking advantage of inconsistent monitoring between platforms

During an authorized engagement, the purpose is to evaluate defensive gaps—not to teach uncontrolled concealment.

Persistence vs Defense Evasion

Area	Persistence	Defense Evasion
Primary Goal	Maintain or regain access	Avoid or delay detection
Common Surface	Identities and automation	Logging and monitoring
Example	Temporary test role created	Activity not correlated by SIEM
Enterprise Risk	Long-term unauthorized access	Extended attacker dwell time
Red Team Objective	Validate whether access can survive	Measure whether controls identify the activity

Enterprise Cloud Persistence Architecture

Initial Access

↓

Compromised or Controlled Identity

↓

Cloud Permission or Automation Path

↓

Persistence Surface

├── Identity Assignment
├── Trust Relationship
├── CI/CD Workflow
├── Kubernetes Workload
├── Serverless Schedule
├── Resource Policy
└── Application Credential

↓

Re-entry Validation

↓

Logging & Detection

↓

SOC Investigation

↓

Persistence Removal

Cloud Persistence Lifecycle

Identify Persistence Surface

↓

Confirm Scope

↓

Assess Business Relevance

↓

Design Synthetic Scenario

↓

Apply Decision Gate

↓

Create Minimum Test Artifact

↓

Validate Controlled Re-entry

↓

Measure Detection

↓

Trigger Investigation

↓

Remove Artifact

↓

Confirm Access Revocation

↓

Document Results

GoHackersCloud Persistence Assessment Workflow

Confirm Authorization

↓

Inventory Identities and Automation

↓

Review Credential Lifecycles

↓

Review Trust Relationships

↓

Review CI/CD and Deployment Systems

↓

Review Kubernetes and Container Workloads

↓

Review Serverless and Scheduled Services

↓

Review Resource Policies

↓

Assess Logging and Monitoring

↓

Identify Candidate Scenarios

↓

Apply Decision Gate

↓

Perform Minimum Controlled Validation

↓

Validate Detection and Response

↓

Remove All Artifacts

↓

Prepare Executive and Technical Reports

Phase 01 — Confirm Persistence Testing Scope

Objective

Ensure every persistence surface and target is explicitly authorized.

Confirm

Approved cloud account
Approved subscription
Approved project
Approved tenant
Approved cluster
Approved namespace
Approved serverless application
Approved CI/CD workflow
Approved test identity
Approved synthetic secret
Approved schedule
Approved test duration
Approved rollback procedure

Persistence Scope Register

Persistence Surface	Platform	Environment	Scope	Restriction
Test IAM Role	AWS	Test	Approved	Remove within test window
Test Managed Identity Assignment	Azure	Development	Approved	No production resources
Test Service Account Binding	Google Cloud	Test	Approved	Project-level only
Test CronJob	Kubernetes	Lab	Approved	Synthetic action only
Production Automation Account	Azure	Production	Out of Scope	No interaction

Scope Principle

Technical access does not equal authorization.

An operator must not use an available persistence path unless the exact source, destination, and mechanism are approved.

Phase 02 — Establish the Persistence Objective

A persistence objective should be measurable and safe.

Weak Objective

Maintain cloud access.

This is too broad.

Strong Objective

Determine whether a dedicated Red Team test identity can regain access to a synthetic storage object through an approved temporary automation role after the original session is revoked.

Example Objectives

Validate whether temporary credentials are properly revoked.
Determine whether a test workload identity remains active after application redeployment.
Assess whether a scheduled test function is detected.
Validate whether an unauthorized test role assignment is identified.
Determine whether the SOC detects a new trusted principal.
Assess whether a CI/CD workflow can recreate an approved test resource.
Validate whether access reviews identify a temporary test identity.

Phase 03 — Build the Persistence Surface Inventory

Identity Persistence Surfaces

IAM roles
Managed Identities
Service Accounts
Service Principals
Application registrations
Federated identities
Group membership
Permission sets
Custom roles
Temporary elevation
Break-glass access

Credential Persistence Surfaces

Access keys
Client secrets
Certificates
Service Account keys
API tokens
OAuth credentials
CI/CD tokens
Registry credentials
Kubernetes tokens
Signed access mechanisms

Automation Persistence Surfaces

CI/CD pipelines
Scheduled jobs
Cloud automation accounts
Infrastructure templates
GitOps workflows
Deployment scripts
Event rules
Workflow engines
Serverless schedules
Build systems

Workload Persistence Surfaces

Kubernetes Deployments
DaemonSets
StatefulSets
CronJobs
Container restart policies
Serverless functions
Virtual machine extensions
Startup scripts
Cloud-init configuration
Managed instance groups

Resource-Policy Persistence Surfaces

Storage policies
Key-management policies
Function resource policies
Registry policies
API permissions
Secret-store policies
Queue policies
Event-bus policies
Cross-account resource access

Phase 04 — Review Identity-Based Persistence

Identity changes can provide durable access.

Review

Newly created identities
New role assignments
Group membership
Federated access
Application registrations
Service Principal ownership
Service Account impersonation
Permission-set assignments
Temporary elevation
Cross-account trust

Assessment Questions

Can the current identity create another identity?
Can it assign permissions?
Can it modify group membership?
Can it create or modify application credentials?
Can it alter federation?
Can it change role trust?
Are new privileged assignments detected?
Are identity changes reviewed?
Are temporary assignments automatically removed?

Phase 05 — Review Credential Persistence

Long-lived credentials can enable re-entry.

Review

Credential age
Credential type
Rotation status
Expiration
Ownership
Storage method
Revocation process
Audit visibility
Usage history

Common Risks

Non-expiring credentials
Unowned access keys
Shared API tokens
Service Account keys
Long-lived certificates
CI/CD secrets without rotation
Credentials embedded in configuration
Credentials stored outside managed secret stores
Weak revocation processes

Credential Register

Credential	Identity	Type	Expiration	Owner	Risk
Test Automation Credential	Test Role	Temporary	1 hour	Red Team	Low
Legacy Build Token	Pipeline Account	Static	None	Unknown	High
Service Account Key	GCP Workload	Key File	1 year	DevOps	High

Phase 06 — Review Trust-Relationship Persistence

Trust relationships can allow an identity to regain access through another service or environment.

AWS Review Areas

Role trust policies
Federated principals
Web Identity Federation
Cross-account trust
Service principals
External IDs
Organization conditions

Azure Review Areas

Federated credentials
Service Principal ownership
Application permissions
Managed Identity assignments
Tenant trust
Azure DevOps service connections
Cross-subscription role assignments

Google Cloud Review Areas

Service Account impersonation
Workload Identity Federation
Cross-project IAM
Group-based permissions
Organization-level IAM
Service Account token creation

Assessment Questions

Can an external principal regain access?
Is the trusted principal still required?
Are restrictive conditions used?
Does trust cross a security boundary?
Are trust-policy changes monitored?
Is trust reviewed periodically?
Can a workload exchange an external identity for cloud access?

Phase 07 — Review CI/CD Persistence

CI/CD systems can recreate access repeatedly.

Review

Workflow modification permissions
Repository permissions
Branch protection
Pipeline identities
Deployment roles
Service connections
Secret variables
Environment approvals
Build agents
GitOps reconciliation
Infrastructure templates

Example Persistence Path

Compromised Development Identity

↓

Can Modify Test Workflow

↓

Pipeline Uses Deployment Identity

↓

Workflow Recreates Approved Test Role

↓

Role Provides Synthetic Resource Access

Assessment Questions

Who can modify deployment workflows?
Are code reviews required?
Are protected branches enforced?
Can pipelines create IAM resources?
Are deployment identities environment specific?
Are workflow changes logged?
Can a pipeline restore a removed identity?
Are unauthorized deployments detected?

Phase 08 — Review Infrastructure as Code Persistence

Infrastructure as Code can reproduce unauthorized changes.

Review

Terraform configurations
CloudFormation templates
Azure Bicep
ARM Templates
Kubernetes manifests
GitOps repositories
Policy repositories
State files
Remote backends

Risks

Unauthorized identity definitions
Hidden role assignments
Modified trust policies
Scheduled resources
Recreated credentials
Weak change approvals
Drift between code and deployed state
Unreviewed modules
Secrets embedded in templates

Assessment Objective

Determine whether an unauthorized change could return after manual remediation because it remains defined in source-controlled infrastructure.

Phase 09 — Review Kubernetes Persistence

Kubernetes controllers are designed to keep workloads running.

This creates legitimate operational resilience but may also support persistence if governance is weak.

Review

Deployments
DaemonSets
StatefulSets
CronJobs
Jobs
Admission webhooks
Operators
Service Accounts
RoleBindings
ClusterRoleBindings
Secrets
ConfigMaps
GitOps controllers
Helm releases

Example Controlled Scenario

Approved Test Namespace

↓

Temporary Test CronJob

↓

Synthetic Log Event

↓

Runtime Detection

↓

SOC Investigation

↓

CronJob Removal

Assessment Questions

Who can create persistent workloads?
Are privileged workloads blocked?
Are new workloads monitored?
Are scheduled jobs reviewed?
Can GitOps recreate a removed workload?
Are admission controls enforced?
Are namespace boundaries effective?
Are workload identities restricted?

Phase 10 — Review Container Persistence

Container persistence may be supported by:

Restart policies
Orchestrator controllers
Host-mounted storage
Startup configuration
Image tags
Shared registries
Build pipelines
Runtime configuration

Review

Container restart behavior
Image provenance
Mutable image tags
Registry permissions
Host volumes
Runtime policies
Deployment automation
Image-promotion workflows

Key Question

Could an unauthorized workload return after being removed because the image, deployment configuration, or automation remains trusted?

Phase 11 — Review Serverless Persistence

Serverless services can provide scheduled, event-driven, and automatically scaled execution.

Review

Scheduled functions
EventBridge rules
Azure Timer Triggers
Cloud Scheduler
Event Grid
Eventarc
Pub/Sub
SNS
SQS
Function resource policies
Deployment roles
Function aliases
Versions
Layers or dependencies

Example Controlled Scenario

Approved Test Scheduler

↓

Invokes Test Function

↓

Function Writes Synthetic Event

↓

Monitoring Alert Generated

↓

Scheduler Disabled and Removed

Assessment Questions

Who can deploy or modify functions?
Who can create event triggers?
Are schedules inventoried?
Are function permissions restricted?
Are new triggers detected?
Can old function versions retain risky behavior?
Are function changes reviewed?

Phase 12 — Review Event-Driven Persistence

Event-driven architectures may repeatedly invoke workloads.

Review

Event rules
Queues
Topics
Subscriptions
Webhooks
Scheduled events
Database triggers
Object-storage events
Event filters
Dead-letter queues

Risks

Unknown event subscriptions
Broad event permissions
Persistent trigger rules
Unmonitored queue consumers
Cross-account event access
Replayed events
Forgotten schedules
Weak ownership

Phase 13 — Review Resource-Policy Persistence

Resource policies can grant continued access even after identity permissions change.

Review

Storage bucket policies
Key policies
Secret-store policies
Registry policies
API resource policies
Queue policies
Function invocation permissions
Event-bus policies
Database access policies

Assessment Questions

Does the resource trust an external principal?
Does the policy use wildcards?
Are conditions enforced?
Is the principal still valid?
Are resource-policy changes monitored?
Could resource access survive identity remediation?

Phase 14 — Review Cloud Session Persistence

Cloud sessions and tokens may remain valid after other controls change.

Review

Session duration
Token lifetime
Refresh tokens
Federated sessions
Role chaining
Session revocation
Conditional Access
Continuous access evaluation
Workload token expiration

Risks

Long session duration
Delayed revocation
Persistent refresh tokens
Weak session attribution
Unmonitored role chaining
Incomplete sign-out procedures

Phase 15 — Understand Cloud Defense Evasion

Defense evasion in cloud environments frequently relies on trusted services and normal administrative workflows.

Potential conditions include:

Incomplete audit logging
Missing data-access logs
Inconsistent SIEM ingestion
Shared administrative identities
Approved automation masking unusual actions
Missing cross-account correlation
Excessive alert thresholds
Unmonitored regions
Unmonitored projects or subscriptions
Logging exclusions
Short retention periods
Security-tool configuration drift
Weak workload telemetry

The Red Team should review these conditions without disabling or bypassing controls.

Phase 16 — Review Logging Coverage

AWS Logging Sources

AWS CloudTrail
CloudWatch Logs
VPC Flow Logs
S3 data events
Lambda logs
EKS audit logs
GuardDuty
Security Hub

Azure Logging Sources

Azure Activity Logs
Microsoft Entra ID logs
Azure Monitor
Diagnostic Settings
Microsoft Defender for Cloud
Microsoft Sentinel
Key Vault logs
AKS logs

Google Cloud Logging Sources

Cloud Audit Logs
Cloud Logging
VPC Flow Logs
GKE Audit Logs
Secret Manager logs
Security Command Center
Cloud Functions logs

Review Questions

Are management events collected?
Are data-access events collected?
Are logs centralized?
Is every region covered?
Are all accounts, subscriptions, and projects included?
Is retention appropriate?
Are logs protected from modification?
Are alerts configured?
Are high-value identities monitored?

Phase 17 — Review Logging Modification Permissions

An identity with logging administration permissions represents significant risk.

High-Risk Capabilities

Modify audit logging
Change diagnostic settings
Delete log sinks
Modify retention
Exclude events
Disable telemetry
Change SIEM connectors
Delete alerts
Modify detection rules
Change security-service configuration

Assessment Questions

Who can modify logging?
Is separation of duties enforced?
Are logging changes themselves logged?
Are security controls protected by dedicated accounts?
Are unexpected changes alerted?
Is emergency restoration documented?

Phase 18 — Review Detection Gaps

Common Detection Gaps

Cross-account role assumptions not correlated
Service Account impersonation not alerted
Managed Identity use not monitored
New workload deployments ignored
Scheduled function creation not detected
New event rules not monitored
Registry changes not correlated
CI/CD changes missing from SIEM
Secret access without alerting
Logging changes without escalation

Detection Gap Register

Activity	Expected Log	Detection Present	Gap
New test role assignment	Audit log	Yes	None
New Kubernetes CronJob	Audit log	No	Missing detection
New scheduled function	Function event log	Partial	No correlation
Logging configuration change	Admin audit log	Yes	Alert delayed

Phase 19 — Review Use of Legitimate Cloud Services

Attackers may use legitimate services because their activity appears operationally normal.

Examples include:

Automation services
Serverless functions
Object storage
Cloud messaging
CI/CD platforms
Remote management services
Scheduled tasks
Native APIs

The Red Team should evaluate whether:

Usage baselines exist.
unusual behavior is detected.
privileged actions require approval.
automation identities are monitored.
business ownership is documented.
administrative activity is attributable.

Phase 20 — Build the Persistence Attack Map

Example Map

Approved Test Identity

↓

Can Modify Test CI/CD Workflow

↓

Workflow Uses Deployment Role

↓

Deployment Role Creates Test Scheduler

↓

Scheduler Invokes Test Function

↓

Function Accesses Synthetic Resource

↓

Activity Produces Partial Logging

↓

SOC Detects Only Final Resource Access

Map Each Stage

Starting identity
Required permission
Persistence surface
Re-entry mechanism
Expected control
Observed control
Detection result
Business impact
Cleanup requirement

Phase 21 — Identify Candidate Persistence Scenarios

Candidate scenarios should be:

Explicitly authorized
Temporary
Reversible
Non-destructive
Observable
Based on synthetic resources
Relevant to the threat model
Connected to a business objective

Candidate Scenario Matrix

Scenario	Surface	Safety	Detection Value	Priority
Temporary Test Role Assignment	Identity	High	High	High
Scheduled Test Function	Serverless	High	High	High
Test Kubernetes CronJob	Kubernetes	High	High	Medium
Modified Test CI/CD Workflow	Automation	Medium	High	High

Phase 22 — Design the Controlled Persistence Scenario

Scenario Template

Field	Description
Scenario ID	Unique identifier
Starting Identity	Approved Red Team identity
Persistence Surface	Approved test mechanism
Re-entry Condition	How controlled access returns
Synthetic Objective	Test resource
Maximum Duration	Time limit
Expected Telemetry	Required logs
Expected Detection	Alert or SOC action
Rollback	Removal process
Stop Condition	Immediate halt trigger

Example Scenario

Field	Value
Scenario ID	PER-VAL-01
Starting Identity	RedTeam-Automation-User
Persistence Surface	Test EventBridge schedule
Re-entry Condition	Scheduled invocation
Synthetic Objective	Write test event to approved log
Maximum Duration	30 minutes
Expected Telemetry	CloudTrail and function logs
Expected Detection	New scheduled-rule alert
Rollback	Disable and delete schedule
Stop Condition	Unexpected resource invocation

Phase 23 — Persistence Validation Decision Gate

Before creating any test persistence artifact, confirm:

Authorization

Safety

Detection

Audit logging is enabled
Expected event is documented
Alert expectation is defined
SOC or control team is prepared
Evidence repository is ready

Decision

Condition	Action
All requirements satisfied	Proceed
Artifact cannot be safely removed	Do not proceed
Production impact possible	Stop
Logging unavailable	Delay or redesign
Scope uncertain	Pause
Third-party interaction possible	Exclude

Phase 24 — Perform Minimum Controlled Persistence Validation

Controlled Workflow

Confirm Decision Gate

↓

Record Current Identity and Context

↓

Create One Approved Test Artifact

↓

Verify Artifact Label and Expiration

↓

Revoke Original Test Session

↓

Validate Controlled Re-entry

↓

Access Synthetic Objective

↓

Capture Logs and Alerts

↓

Notify Control Team

↓

Remove Test Artifact

↓

Revoke Residual Access

↓

Confirm Cleanup

↓

Document Outcome

Minimum-Action Principles

Create only one artifact.
Use a clear Red Team label.
Set an expiration.
Do not hide the artifact from the control team.
Do not modify production security controls.
Do not create secondary persistence.
Stop after proving the objective.
Remove access immediately after validation.

Phase 25 — Validate Defense-Evasion Detection

The objective is to determine whether potentially evasive behavior is visible—not to conceal it indefinitely.

Controlled Behaviors to Validate

Low-volume role use
Use of a trusted automation identity
Scheduled test workload execution
Cross-account access through an approved role
Use of temporary credentials
Function execution outside normal hours
New resource-policy assignment
Test workload created through CI/CD

Detection Questions

Was the action logged?
Was an alert generated?
Was the identity correctly attributed?
Was the activity correlated across services?
Did the SOC recognize the persistence mechanism?
Could responders identify the root cause?
Could they remove all related access?

Phase 26 — Measure Detection and Response

Detection Metrics

Time to log generation
Time to SIEM ingestion
Time to alert
Time to analyst review
Time to escalation
Time to containment
Time to complete artifact removal

Detection Validation Table

Activity	Expected Telemetry	Expected Alert	Result
New test role assignment	IAM audit log	Privileged assignment alert	Detected / Not Detected
Scheduled test function	Function and scheduler logs	New schedule alert	Detected / Not Detected
Test CronJob creation	Kubernetes Audit Log	Suspicious workload alert	Detected / Not Detected
CI/CD workflow modification	Repository audit log	Protected workflow alert	Detected / Not Detected

Phase 27 — Trigger Controlled Incident Response

Where approved, the Blue Team or SOC should investigate and remove the persistence artifact.

Expected Response Activities

Validate the alert
Identify the creating identity
Review related actions
Determine scope
Disable the test artifact
Revoke credentials or sessions
Confirm no secondary access
Preserve evidence
Document containment

Response Assessment

Evaluate whether responders:

Identified the correct artifact.
Found the original access path.
Reviewed related identities.
Checked connected resources.
Removed all temporary access.
Preserved evidence.
Communicated clearly.
Escalated appropriately.

Phase 28 — Remove All Persistence Artifacts

Cleanup is mandatory.

Cleanup Checklist

Phase 29 — Verify Complete Access Revocation

After cleanup, confirm that:

The original test identity cannot re-enter.
The persistence artifact no longer exists.
Temporary credentials are invalid.
Scheduled execution has stopped.
Workloads do not restart.
CI/CD does not recreate the artifact.
GitOps does not restore the configuration.
Resource policies are correct.
No residual role assignments remain.
Monitoring remains enabled.

Verification Outcome

Check	Result
Original session revoked	Pass / Fail
Persistence artifact removed	Pass / Fail
Automation does not recreate artifact	Pass / Fail
Synthetic access blocked	Pass / Fail
Logging remains active	Pass / Fail

Phase 30 — Review Persistence Governance

Governance Areas

Identity lifecycle
Credential lifecycle
Role approval
Workload ownership
CI/CD governance
Infrastructure change control
Event-rule inventory
Scheduled workload inventory
Service Account governance
Access recertification
Logging change approval
Exception management

Governance Questions

Does every identity have an owner?
Are credentials assigned expiration dates?
Are scheduled workloads inventoried?
Are trust relationships reviewed?
Are automation changes approved?
Are temporary assignments removed automatically?
Is logging protected by separation of duties?
Are dormant workloads removed?
Are resource policies periodically reviewed?

Common Enterprise Findings

Persistence and defense-evasion assessments frequently identify:

Long-lived credentials
Dormant privileged identities
Unreviewed trust relationships
Shared deployment identities
CI/CD pipelines with excessive permissions
Unmonitored scheduled functions
Forgotten Kubernetes CronJobs
Weak GitOps approval
Mutable container image tags
Resource policies granting external access
Missing data-access logging
Inconsistent SIEM ingestion
Excessive logging administration permissions
Weak alerting for IAM changes
Delayed session revocation
Poor ownership of automation accounts
Incomplete cleanup procedures

Risk Classification

Severity	Description
Critical	Persistence path enables durable access to critical business assets while avoiding effective detection
High	Persistent access can be established across a major trust boundary or privileged identity
Medium	Persistence condition requires additional permissions or operational conditions
Low	Limited lifecycle, monitoring, or governance weakness
Informational	Security maturity recommendation

Risk Factors

Consider:

Duration of access
Privilege level
Resource sensitivity
Ease of re-entry
Detection coverage
Revocation capability
Automation reach
Cross-environment impact
Business criticality
Cleanup complexity

Phase 31 — Document the Complete Persistence Path

Do not report only the final artifact.

Explain how the conditions connect.

Example

Approved Development Identity

↓

Can Modify Test CI/CD Workflow

↓

Pipeline Uses Broad Deployment Role

↓

Role Creates Scheduled Test Function

↓

Function Uses Persistent Execution Identity

↓

Function Accesses Synthetic Secret

↓

Activity Not Detected Until Secret Access

Record for Every Stage

Source identity
Permission used
Persistence mechanism
Duration
Re-entry method
Expected security control
Observed security control
Detection result
Business impact
Cleanup status
Recommended remediation

Phase 32 — Prepare the Persistence Assessment Report

Executive Summary

Include:

Engagement objective
Persistence scenario tested
Re-entry outcome
Detection outcome
Response outcome
Business impact
Residual risk
Strategic recommendations

Technical Report

Include:

Scope
Rules of Engagement
Methodology
Persistence surface inventory
Credential lifecycle review
Trust analysis
CI/CD assessment
Kubernetes assessment
Serverless assessment
Logging review
Controlled validation steps
Evidence
Detection results
Cleanup verification
Findings
Remediation roadmap

Remediation Strategy

Identity Controls

Use temporary access.
Remove dormant identities.
restrict role assignment permissions.
review trust relationships.
enforce identity ownership.
automate expiration.
monitor new privileged access.

Credential Controls

Eliminate long-lived keys.
use managed identities and federation.
rotate credentials.
enforce expiration.
centralize secrets.
monitor credential creation.

Automation Controls

Protect workflows.
require peer review.
separate deployment identities.
enforce environment approvals.
monitor automation changes.
prevent pipeline self-escalation.

Kubernetes Controls

Restrict CronJobs and DaemonSets.
enforce admission policies.
monitor new workloads.
apply namespace boundaries.
govern Service Accounts.
review GitOps changes.

Serverless Controls

Inventory schedules and triggers.
restrict function deployment.
monitor new event rules.
limit execution-role permissions.
alert on unusual invocation patterns.

Logging Controls

Centralize audit logs.
protect logging administration.
enable data-access logging.
alert on logging changes.
monitor all regions and projects.
increase retention.
correlate identity and workload events.

Governance Controls

Maintain persistence-surface inventories.
perform access reviews.
document owners.
enforce removal of temporary artifacts.
test incident-response playbooks.
review all scheduled workloads.

Consultant Best Practices

Professional Cloud Red Team Operators should:

Never create uncontrolled persistence.
Use one clearly labeled test artifact.
Set an expiration time.
Use synthetic resources only.
Keep the control team informed.
Avoid disabling or weakening production logging.
Apply a formal decision gate.
Validate both re-entry and detection.
Perform immediate cleanup.
Confirm that automation does not recreate the artifact.
Verify all sessions and credentials are revoked.
Distinguish persistence risk from defense-evasion risk.
Report the complete attack path.
Recommend controls that prevent, detect, and remove persistence.

Key Takeaways

Cloud persistence is commonly identity-, automation-, and workload-driven.
CI/CD, GitOps, Kubernetes controllers, serverless schedules, and resource policies can maintain access.
Defense evasion often exploits incomplete telemetry and trusted administrative workflows.
Persistence testing must be temporary, labeled, reversible, and explicitly authorized.
The Red Team should never disable production security controls.
Every test artifact must have an owner, expiration, rollback plan, and cleanup confirmation.
Detection and incident-response validation are essential outcomes.
Complete access revocation must be verified after testing.
Findings should explain how multiple conditions create durable access and delayed detection.

Lesson Summary

In this lesson, you learned how authorized Cloud Red Teams assess persistence and defense-evasion risks across identities, credentials, trust relationships, CI/CD systems, Infrastructure as Code, Kubernetes, containers, serverless services, event-driven platforms, resource policies, and logging systems.

You built persistence-surface inventories, reviewed credential lifecycles, analyzed automation and workload relationships, identified monitoring gaps, designed safe persistence simulations, applied decision gates, validated controlled re-entry, measured SOC detection, removed all test artifacts, and verified complete access revocation.

A professional persistence assessment does not leave hidden access behind.

It demonstrates whether durable access could exist, measures whether defenders can discover and remove it, and provides practical recommendations that strengthen identity governance, automation security, monitoring, and incident response.

Knowledge Check

How does cloud persistence differ from endpoint persistence?
What is the difference between persistence and defense evasion?
Why are CI/CD pipelines significant persistence surfaces?
How can GitOps recreate a removed workload?
Why are scheduled serverless functions relevant to persistence assessments?
What controls must be confirmed before creating a test persistence artifact?
Why should the test artifact be clearly labeled and time limited?
Which logging gaps may allow persistent access to remain undetected?
What must be verified after artifact cleanup?
Why should persistence findings be reported as complete attack paths?

Practical Assignment

Create an Enterprise Cloud Persistence & Defense-Evasion Assessment Plan for a fictional multi-cloud organization.

Your plan must include:

Assessment scope
Persistence objectives
Identity persistence inventory
Credential lifecycle assessment
Trust-relationship review
CI/CD persistence assessment
Infrastructure as Code persistence review
Kubernetes persistence review
Container persistence review
Serverless persistence review
Event-driven persistence review
Resource-policy assessment
Logging coverage review
Logging-administration review
Detection-gap register
Three candidate persistence scenarios
Scenario-prioritization matrix
Controlled validation scenario
Decision-gate checklist
Expected telemetry
Detection and response plan
Cleanup checklist
Access-revocation verification
Risk-rating model
Executive reporting structure
Remediation roadmap

Assignment Deliverables

Submit:

Persistence Assessment Plan
Persistence Surface Inventory
Credential Lifecycle Register
Trust Relationship Map
CI/CD Persistence Review
Kubernetes and Serverless Persistence Map
Logging Coverage Matrix
Detection Gap Register
Candidate Scenario Matrix
Controlled Validation Plan
Decision-Gate Checklist
Evidence Register
Detection Validation Table
Cleanup Checklist
Access Revocation Report
Executive Persistence Risk Summary
Technical Assessment Report
Remediation Roadmap

What’s Next?

➡️ Lesson 06 — Command & Control in Cloud Environments

In the next lesson, you will learn how authorized Cloud Red Teams assess command-and-control risks in cloud environments without deploying uncontrolled malware or covert infrastructure.

You will study cloud communication paths, management channels, serverless orchestration, container and Kubernetes control surfaces, approved simulation techniques, network and identity telemetry, operational safety, detection validation, and the enterprise controls required to identify and contain suspicious cloud communications.