Uma Lambda pode ter different versions (com different code em cada versão).
Então, você pode criar different aliases apontando para different versions da função e definir diferentes weights para cada um.
Dessa forma, um atacante poderia criar uma backdoored version 1 e uma version 2 com apenas o legit code e executar somente a version 1 em 1% das requests para permanecer furtivo.

Version Backdoor + API Gateway

Copy the original code of the Lambda
Create a new version backdooring the original code (or just with malicious code). Publish and deploy that version to $LATEST
Call the API gateway related to the lambda to execute the code
Create a new version with the original code, Publish and deploy that version to $LATEST.
This will hide the backdoored code in a previous version
Go to the API Gateway and create a new POST method (or choose any other method) that will execute the backdoored version of the lambda: arn:aws:lambda:us-east-1:<acc_id>:function:<func_name>:1
Note the final :1 of the arn indicating the version of the function (version 1 will be the backdoored one in this scenario).
Select the POST method created and in Actions select Deploy API
Now, when you call the function via POST your Backdoor will be invoked

Cron/Event actuator

O fato de você poder fazer lambda functions rodarem quando algo acontece ou quando passa um intervalo de tempo torna o Lambda uma forma comum de obter persistência e evitar detecção.
Aqui estão algumas ideias para tornar sua presença na AWS mais furtiva criando lambdas.

Toda vez que um novo user é criado, a Lambda gera uma nova user key e envia para o atacante.
Toda vez que uma nova role é criada, a Lambda concede permissões de assume role para usuários comprometidos.
Toda vez que novos cloudtrail logs são gerados, deletar/alterar eles

RCE abusando de AWS_LAMBDA_EXEC_WRAPPER + Lambda Layers

Abuse da variável de ambiente AWS_LAMBDA_EXEC_WRAPPER para executar um wrapper controlado pelo atacante antes do runtime/handler iniciar. Entregue o wrapper via um Lambda Layer em /opt/bin/htwrap, configure AWS_LAMBDA_EXEC_WRAPPER=/opt/bin/htwrap e então invoque a função. O wrapper roda dentro do processo do runtime da função, herda a execution role da função e, por fim, faz exec do runtime real para que o handler original ainda seja executado normalmente.

{{#ref}} aws-lambda-exec-wrapper-persistence.md {{#endref}}

AWS - Lambda Function URL Public Exposure

Abuse de destinations assíncronas do Lambda junto com a configuração de Recursion para fazer uma função se re-invocar continuamente sem um agendador externo (sem EventBridge, cron, etc.). Por padrão, o Lambda termina loops recursivos, mas configurando recursion para Allow reativa-os. Destinations entregam do lado do serviço para invokes async, então um único invoke seed cria um canal stealthy de heartbeat/backdoor sem necessidade de código. Opcionalmente throttle com reserved concurrency para manter o ruído baixo.

{{#ref}} aws-lambda-async-self-loop-persistence.md {{#endref}}

AWS - Lambda Alias-Scoped Resource Policy Backdoor

Crie uma versão escondida da Lambda com lógica do atacante e aplique uma resource-based policy com escopo para aquela versão específica (ou alias) usando o parâmetro --qualifier em lambda add-permission. Conceda apenas lambda:InvokeFunction sobre arn:aws:lambda:REGION:ACCT:function:FN:VERSION a um principal atacante. Invocações normais via nome da função ou alias primário permanecem inalteradas, enquanto o atacante pode invocar diretamente o ARN da versão backdoored.

Isto é mais furtivo do que expor um Function URL e não altera o alias de tráfego primário.

{{#ref}} aws-lambda-alias-version-policy-backdoor.md {{#endref}}

Freezing AWS Lambda Runtimes

Um atacante que possui permissions lambda:InvokeFunction, logs:FilterLogEvents, lambda:PutRuntimeManagementConfig, e lambda:GetRuntimeManagementConfig pode modificar a runtime management configuration de uma função. Este ataque é especialmente efetivo quando o objetivo é manter uma função Lambda em uma versão de runtime vulnerável ou preservar compatibilidade com layers maliciosas que podem ser incompatíveis com runtimes mais novos.

O atacante modifica a runtime management configuration para fixar a versão do runtime:

# Invoke the function to generate runtime logs
aws lambda invoke \
--function-name $TARGET_FN \
--payload '{}' \
--region us-east-1 /tmp/ping.json

sleep 5

# Freeze automatic runtime updates on function update
aws lambda put-runtime-management-config \
--function-name $TARGET_FN \
--update-runtime-on FunctionUpdate \
--region us-east-1

Verifique a configuração aplicada:

aws lambda get-runtime-management-config \
--function-name $TARGET_FN \
--region us-east-1

Opcional: Fixar em uma versão específica do runtime

# Extract Runtime Version ARN from INIT_START logs
RUNTIME_ARN=$(aws logs filter-log-events \
--log-group-name /aws/lambda/$TARGET_FN \
--filter-pattern "INIT_START" \
--query 'events[0].message' \
--output text | grep -o 'Runtime Version ARN: [^,]*' | cut -d' ' -f4)

Fixar em uma versão específica do runtime:

aws lambda put-runtime-management-config \
--function-name $TARGET_FN \
--update-runtime-on Manual \
--runtime-version-arn $RUNTIME_ARN \
--region us-east-1