Detectar StopLogging y GuardDuty desactivado en CloudTrail
Evasión de defensas en AWS: StopLogging, DeleteTrail, selectores de eventos, GuardDuty, Config y Flow Logs borrados: lo que CloudTrail registra y lo que pierde.
En resumen. Dejar ciegos a los defensores también queda registrado. StopLogging y DeleteTrail los registra el propio trail que detienen; DeleteDetector aparece en CloudTrail aunque GuardDuty ya no exista; PutEventSelectors y UpdateTrail reducen en silencio lo que se registra. Trate cualquiera de estos eventos procedente de un principal inesperado como crítico, restablezca el registro de inmediato y después cubra el hueco: el historial de eventos es independiente de los trails y conserva 90 días de eventos de administración por región, así que un trail detenido rara vez significa cero evidencias.
Un atacante que ha pasado unos minutos en una cuenta de AWS sabe qué lo vigila. En cuanto tiene permisos de administrador, desactivar CloudTrail, GuardDuty, AWS Config o VPC Flow Logs le cuesta poco y a menudo está automatizado en un script. MITRE ATT&CK lo recoge como T1562.008 Impair Defenses: Disable or Modify Cloud Logs y T1562.001 Disable or Modify Tools.
CloudTrail: detener, eliminar o recortar
| Evento | Efecto | Qué revisar |
|---|---|---|
StopLogging | El trail deja de entregar registros; la configuración se conserva | requestParameters.name (trail), región, autor de la llamada |
DeleteTrail | El trail desaparece | Lo mismo |
UpdateTrail | Pueden cambiar el bucket de destino, el prefijo, el modo multirregión, los eventos globales o la clave de KMS | Compare la nueva configuración con la anterior |
PutEventSelectors / PutInsightSelectors | Pueden dejar de registrarse eventos de datos o de administración | eventSelectors / advancedEventSelectors |
StopEventDataStoreIngestion, DeleteEventDataStore | CloudTrail Lake se detiene o desaparece | ARN del almacén de datos de eventos |
Errores habituales entre los profesionales:
StopLoggingqueda registrado. La llamada se registra antes de que el registro se detenga, de modo que la identidad y la IP del atacante están en el último archivo entregado.- Recortar hace menos ruido que detener. Un
PutEventSelectorsque fijaReadWriteTypeenWriteOnly, o que elimina el selector de eventos de datos de S3, mantiene el trail "activo" en todos los paneles mientras descarta justo los eventos que necesita para demostrar el acceso a los datos. - Sabotaje del lado del bucket. Eliminar objetos de registro, cambiar la política del bucket o añadir una regla de ciclo de vida no toca el trail en absoluto. Busque
PutBucketPolicy,PutBucketLifecycleConfigurationyDeleteObjectssobre el bucket del trail (este último solo si los eventos de datos lo cubren). - Los trails de organización no se pueden detener desde una cuenta miembro; un atacante en una cuenta miembro puede apuntar en su lugar a los trails de la propia cuenta o a los servicios que se describen a continuación.
El propio GuardDuty genera Stealth:IAMUser/CloudTrailLoggingDisabled cuando se desactiva o elimina un trail (tipos de hallazgos), siempre que GuardDuty siga en funcionamiento.
GuardDuty: eliminar, suspender o silenciar
| Evento | Efecto |
|---|---|
DeleteDetector | GuardDuty desactivado en esa región; los hallazgos existentes desaparecen con él |
UpdateDetector con enable: false | Detector suspendido |
DisassociateFromAdministratorAccount, DisassociateFromMasterAccount | La cuenta miembro abandona la supervisión centralizada |
DeleteMembers, DisassociateMembers, StopMonitoringMembers | La cuenta de administrador deja de supervisar a los miembros |
CreateIPSet / UpdateIPSet | Lista de IP de confianza: GuardDuty ignora esas direcciones |
CreateFilter / UpdateFilter con action: ARCHIVE | Los hallazgos que coinciden se archivan automáticamente |
DeletePublishingDestination | Los hallazgos dejan de exportarse a S3 |
La lista de IP de confianza y el filtro de archivado automático son los más sutiles: GuardDuty sigue funcionando y la consola parece sana, pero la dirección del atacante no genera nada, o sus hallazgos se archivan antes de que nadie los lea.
Como eliminar un detector borra sus hallazgos, exporte los hallazgos de GuardDuty en cuanto sospeche un incidente (guía de exportación).
Todo lo demás que vigila
| Servicio | Eventos | ATT&CK |
|---|---|---|
| AWS Config | StopConfigurationRecorder, DeleteConfigurationRecorder, DeleteDeliveryChannel | T1562.001 |
| Security Hub | DisableSecurityHub, BatchDisableStandards | T1562.001 |
| Macie | DisableMacie, UpdateMacieSession (en pausa) | T1562.001 |
| Inspector | inspector2:Disable | T1562.001 |
| Detective | DeleteGraph, DisassociateMembership | T1562.001 |
| Registro de acceso de S3 | PutBucketLogging sin LoggingEnabled | T1562.008 |
| VPC Flow Logs | DeleteFlowLogs | T1562.008 |
| CloudWatch Logs | DeleteLogGroup, DeleteLogStream | T1070 |
No olvide la dimensión regional: GuardDuty, Config y Security Hub son servicios regionales. Un atacante que elimina el detector en eu-west-1 y después trabaja en ap-southeast-1, donde GuardDuty nunca se activó, está usando dos técnicas de evasión a la vez; la segunda es T1535 Unused/Unsupported Cloud Regions.
Cómo leer el hueco
Cuando se ha detenido el registro, su trabajo consiste en delimitar el punto ciego y rellenarlo con otras fuentes:
- Delimítelo. El evento
StopLoggingmarca el inicio; el siguiente archivo entregado (o el eventoStartLoggingcuando vuelva a activarlo) marca el final. - Historial de eventos. No le afecta la configuración de los trails (documentación): descárguelo para cada región y para la ventana del hueco. No obtendrá eventos de datos, pero sí los eventos de administración.
- Otros trails. Un trail de organización o un segundo trail de la cuenta pueden haber seguido funcionando.
- Estado en los servicios. Los recursos que existen ahora pero se crearon durante el hueco (usuarios, instancias, claves) pueden fecharse por su hora de creación:
user_creation_timeen el informe de credenciales,LaunchTimeen las instancias,CreateDateen las claves. - Evidencias de red. Los VPC Flow Logs, si sobrevivieron, cubren el hueco desde el lado de la red.
Deje constancia explícita del hueco en el informe. "No se encontró actividad maliciosa" y "no hay registros entre las 02:10 y las 03:40" son afirmaciones distintas.
Pasos de respuesta
- Reanude el registro (
StartLogging) o vuelva a crear el trail con su configuración anterior; reactive GuardDuty, Config y los servicios de seguridad en todas las regiones donde estaban funcionando. - Elimine las listas de IP de confianza y los filtros de archivado añadidos por el atacante; restaure los destinos de publicación.
- Configure alarmas para estos eventos: AWS describe cómo crear alarmas de CloudWatch sobre eventos de CloudTrail.
- Con AWS Organizations, deniegue estas acciones a todos salvo a un rol de acceso de emergencia (break-glass) mediante una política de control de servicios.
En el analizador
AWS Forensics califica un CloudTrail detenido o eliminado como crítico (basta por sí solo para el veredicto "Indicios de compromiso") y señala los cambios de configuración de los trails, el debilitamiento de GuardDuty (incluidas las listas de IP y los filtros de archivado), la detención de Config, la desactivación de servicios de seguridad, el registro de S3 desactivado, los Flow Logs eliminados y los grupos de registros eliminados. Consulte la referencia de eventos de CloudTrail para ver la lista completa, y los límites de una investigación basada solo en registros para saber lo que ninguna herramienta puede recuperar una vez que los registros han desaparecido.