Los equipos de ingeniería que crean, escalan y administran aplicaciones basadas en la nube en AWS saben que, en algún momento, sus aplicaciones e infraestructura estarán bajo ataque. Pero a medida que las aplicaciones se expanden y se agregan nuevas funciones, asegurar el alcance completo de un entorno de AWS se convierte en una tarea cada vez más compleja.
Para agregar visibilidad y auditabilidad, AWS CloudTrail rastrea quién, qué, dónde y cuándo de la actividad que ocurre en su entorno de AWS y registra esta actividad en forma de registros de auditoría. En consecuencia, los registros de auditoría de CloudTrail contienen información que es clave para monitorear las acciones realizadas en sus cuentas de AWS, identificando posibles comportamientos maliciosos y revelando partes de su infraestructura que podrían no estar configuradas correctamente.
En esta guía, veremos:
la estructura de los registros de auditoría de AWS CloudTrail
registros importantes de CloudTrail para monitorear
cómo Datadog puede ayudarlo a recopilar y monitorear sus registros de CloudTrail
Pero primero, echemos un vistazo rápido a cómo AWS CloudTrail organiza y monitorea la actividad dentro de sus cuentas de AWS.
Como se mencionó anteriormente, AWS CloudTrail registra cada instancia de actividad (como solicitudes de API e inicios de sesión de usuarios) que detecta en su entorno como un evento, que es un objeto JSON que especifica los detalles de la actividad, incluido el momento en que ocurrió, quién realizó la actividad, los recursos que se vieron afectados por la actividad, y más. Puede ver y filtrar todos sus eventos en la página Historial de eventos en la consola de AWS CloudTrail, donde están disponibles hasta 90 días después de que ocurran.
La mayoría de los clientes de AWS utilizan un seguimiento consolidado para todos los eventos de CloudTrail. Sin embargo, puede crear un flujo de eventos que filtre o excluya eventos. Por ejemplo, para reducir la carga de registros, es posible que desee crear un flujo de eventos que consista únicamente en actividades relacionadas con un determinado servicio o recurso de AWS. Para hacer esto, crea un rastro o un flujo de eventos que envía eventos a un depósito de AWS S3 elegido como archivos de registro. De esta manera, sus eventos están disponibles de acuerdo con la política de retención que especifique, se pueden filtrar rápidamente para encontrar problemas críticos y se les puede alertar sobre el uso de Amazon CloudWatch o Amazon Simple Notification Service (SNS).
CloudTrail guarda sus registros de auditoría en forma de archivo gzip en el depósito de S3 que especifica al crear el registro. El nombre del archivo incluye el número de cuenta del creador de la ruta, la región en la que se registró el registro y el mes, día y año en que se creó el archivo. Para obtener más información sobre cómo encontrar sus archivos de registro de CloudTrail, consulte la documentación de AWS.
De forma predeterminada, los senderos son independientes de la región; es decir, un rastro registrará eventos relevantes en cada región. Puede crear rutas de una sola región para centrarse en la actividad de una sola región, pero le recomendamos que cree una ruta para toda la región, ya que esto le dará más visibilidad y rastreará automáticamente los datos de las nuevas regiones a medida que se conectan.
También puede configurar un seguimiento de la organización para monitorear todos los registros generados por las cuentas de AWS dentro de una organización de AWS. AWS Organizations le permite administrar de forma centralizada los permisos de acceso de los usuarios en todas las cuentas de la organización y se puede configurar sin costo adicional. Se recomiendan las organizaciones cuando su equipo necesita administrar muchas cuentas de AWS diferentes al controlar su entorno en constante cambio y hacer cumplir las configuraciones en sus cuentas principales y de miembros.
Descripción de los registros de auditoría de AWS CloudTrail
AWS CloudTrail registra tres tipos diferentes de eventos de la mayoría de los servicios de AWS en función de las acciones que realizan los usuarios en la consola de administración de AWS, la interfaz de línea de comandos (CLI) y los SDK/API, así como las acciones automatizadas realizadas por AWS. Para obtener una lista de los servicios que CloudTrail no realiza un seguimiento, consulte la documentación de AWS. Los tres tipos de eventos son:
Eventos de administración: entradas para operaciones de administración y red (plano de control) realizadas en los recursos de su cuenta de AWS, como cambios en la configuración del grupo de seguridad, ajustes de permisos de funciones de IAM y alteraciones de la red de la nube virtual privada (VPC) de AWS.
Eventos de datos: entradas para operaciones de solicitud de datos, como los comandos Get, Delete y Put de la API, realizadas en un recurso del plano de datos de AWS.
Eventos de información: entradas que reflejan una actividad API inusual en su cuenta de AWS en comparación con su uso histórico de la API, como llamadas excesivas a la API en un corto período de tiempo.
Dado que los eventos de administración y datos constituyen la gran mayoría de los registros de eventos en CloudTrail, los analizaremos con más detalle. Para obtener más información sobre el uso de eventos de información para rastrear y descubrir anomalías en sus datos de AWS, consulte la documentación de AWS.
Gestión de eventos
Los eventos de administración incluyen todas las operaciones de administración realizadas en los recursos de su cuenta, así como la mayoría de las acciones que no son de API. Las acciones que no son de API incluyen inicios de sesión (AwsConsoleSignIn) en la consola de AWS y acciones de servicios automatizados como rotaciones de claves criptográficas (AwsServiceEvent). AWS CloudTrail registra los eventos de administración de forma predeterminada.
El evento de administración de muestra a continuación registra un inicio de sesión en la consola, indicado por el campo eventType: AwsConsoleSignIn. Muestra que alguien con el nombre de usuario Alice inició sesión correctamente en la consola de AWS sin autenticación multifactor.
{
"eventVersion": "1.05",
"userIdentity": {
"type": "IAMUser",
"principalId": "AIDABBBBBBBBBBBBBBBBB",
"arn": "arn:aws:iam::111111111111:user/alice",
"accountId": "111111111111",
"userName": "alice"
},
"eventTime": "2020-09-23T09:09:56Z",
"eventSource": "signin.amazonaws.com",
"eventName": "ConsoleLogin",
"awsRegion": "us-east-1",
"sourceIPAddress": "1.2.3.4",
"userAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.135 Safari/537.36",
"requestParameters": null,
"responseElements": {
"ConsoleLogin": "Success"
},
"additionalEventData": {
"LoginTo": "https://console.aws.amazon.com/console/home",
"MobileVersion": "No",
"MFAUsed": "No"
},
"eventID": "6894a571-9f34-47b8-b75c-5f4ca34f281e",
"eventType": "AwsConsoleSignIn",
"recipientAccountId": "111111111111"
}
Eventos de datos
Los eventos de datos brindan detalles sobre las operaciones realizadas en o dentro de un recurso o servicio, como los roles de AWS IAM, las instancias de Amazon EC2, los depósitos de Amazon S3 y las funciones de AWS Lambda. Debido a que suelen ser actividades de gran volumen, los eventos de datos están deshabilitados de forma predeterminada cuando crea un seguimiento; debe agregar los recursos o tipos de recursos a un registro para poder rastrearlos en AWS CloudTrail.
El siguiente ejemplo muestra que el usuario Alice realizó con éxito la operación PutObject Amazon S3 en un depósito llamado ejemplo-depósito para cargar el archivo ejemploArchivo.txt.
{
"eventVersion": "1.07",
"userIdentity": {
"type": "IAMUser",
"principalId": "AIDAAAAAAAAAAAAAAAAAA",
"arn": "arn:aws:iam::111111111111:user/Alice",
"accountId": "111111111111",
"accessKeyId": "AKIAAAAAAAAAAAAAAAAAA",
"userName": "Alice"
},
"eventTime": "2020-09-22T20:15:25Z",
"eventSource": "s3.amazonaws.com",
"eventName": "PutObject",
"awsRegion": "us-east-1",
"sourceIPAddress": "1.2.3.4",
"userAgent": "[Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.102 Safari/537.36]",
"requestParameters": {
"X-Amz-Date": "20200922T201524Z",
"bucketName": "example-bucket",
"X-Amz-Algorithm": "AWS4-HMAC-SHA256",
"x-amz-acl": "private",
"X-Amz-SignedHeaders": "content-md5;content-type;host;x-amz-acl;x-amz-storage-class",
"Host": "example-bucket.s3.us-east-1.amazonaws.com",
"X-Amz-Expires": "300",
"key": "exampleFile.txt",
"x-amz-storage-class": "STANDARD"
},
"responseElements": null,
"additionalEventData": {
"SignatureVersion": "SigV4",
"CipherSuite": "ECDHE-RSA-AES128-GCM-SHA256",
"bytesTransferredIn": 12,
"AuthenticationMethod": "QueryString",
"x-amz-id-2": "d2UncmUgaGlyaW5nIDopIGh0dHBzOi8vd3d3LmRhdGFkb2docS5jb20vY2FyZWVycy8K",
"bytesTransferredOut": 0
},
"requestID": "EEEEEEEEEEEEEEEE",
"eventID": "f378e059-d87f-44b7-aee2-7ebfa1beff93",
"readOnly": false,
"resources": [
{
"type": "AWS::S3::Object",
"ARN": "arn:aws:s3:::example-bucket/exampleFile.txt"
},
{
"accountId": "111111111111",
"type": "AWS::S3::Bucket",
"ARN": "arn:aws:s3:::example-bucket"
}
],
"eventType": "AwsApiCall",
"managementEvent": false,
"recipientAccountId": "111111111111",
"eventCategory": "Data"
}
Interpretación de sus registros de CloudTrail
Los registros de AWS CloudTrail contienen información invaluable que le permite monitorear la actividad en su entorno de AWS, por lo que es importante comprender cómo interpretarlos para realizar investigaciones. En esta sección, profundizaremos en un evento de administración de muestra en un archivo de registro de CloudTrail para ilustrar en qué campos debe concentrarse.
Los archivos de registro de CloudTrail se escriben en formato JSON y cada evento se presenta como un solo objeto JSON. Las entradas de todos los tipos de eventos incluyen algunos de los mismos campos importantes, como el ID de clave de acceso de la identidad de AWS que realizó la acción (campos de identidad de usuario) y los detalles de la acción realizada (nombre de evento y parámetros de solicitud). Las entradas de eventos de administración y datos también proporcionan campos de elementos de respuesta que lo ayudan a determinar si la acción se realizó correctamente.
En el fragmento a continuación, podemos ver que un usuario llamado Alice (userName) hizo una llamada para crear un nuevo usuario (eventName) llamado Bob (requestParameters).
{
"eventVersion": "1.05",
"userIdentity": {
"type": "IAMUser",
"principalId": "AIDAAAAAAAAAAAAAAAAAA",
"arn": "arn:aws:iam::111111111111:user/Alice",
"accountId": "111111111111",
"accessKeyId": "AKIAAAAAAAAAAAAAAAAAA",
"userName": "Alice"
},
"eventTime": "2020-09-21T10:31:20Z",
"eventSource": "iam.amazonaws.com",
"eventName": "CreateUser",
"awsRegion": "us-east-1",
"sourceIPAddress": "1.2.3.4",
"userAgent": "console.amazonaws.com",
"requestParameters": {
"userName": "bob",
"tags": []
},
"responseElements": {
"user": {
"path": "/",
"userName": "bob",
"userId": "AIDABBBBBBBBBBBBBBBBB ",
"arn": "arn:aws:iam::111111111111:user/bob",
"createDate": "Sep 21, 2020 10:31:20 AM"
}
},
"requestID": "604e7549-4ea4-4185-83b0-acff4e462d27",
"eventID": "600e50af-0a2c-4352-95a8-7b813c744072",
"eventType": "AwsApiCall",
"recipientAccountId": "111111111111"
}
Debido a que la entrada devuelve detalles de identificación para el usuario recién creado (responseElements), sabemos que el comando se ejecutó correctamente. De lo contrario, la respuesta JSON habría incluido un elemento errorCode y errorMessage, como se ve en la documentación de AWS.
Antes de analizar los registros de CloudTrail más importantes para monitorear, es esencial comprender los diferentes tipos de identidad de usuario definidos por CloudTrail y cómo CloudTrail identifica al usuario que realizó una acción.
Tipos de identidad de CloudTrail
Cada registro de eventos de CloudTrail contiene un elemento userIdentity que describe al usuario o servicio que realizó la acción. Dentro de este elemento, el campo de tipo describe qué tipo de usuario o servicio realizó la solicitud y qué nivel de credenciales empleó ese usuario o servicio para realizar la solicitud, los tipos de identidad de usuario de CloudTrail incluyen:
- Raíz: la solicitud se realizó con las credenciales de su cuenta principal de AWS. Si configura un alias para su cuenta de AWS, ese alias aparecerá aquí en su lugar.
- IAMUser: La solicitud se realizó con las credenciales de un usuario de IAM.
- FederatedUser: la solicitud la realizó un usuario con credenciales de seguridad temporales proporcionadas a través de un token de federación.
- AWSAccount: la solicitud fue realizada por una cuenta de AWS de un tercero.
- AWSService: la solicitud fue realizada por una cuenta de servicio de AWS. Muchos servicios de AWS utilizan cuentas de servicio para realizar acciones automatizadas en su nombre.
- AssumeRole: la solicitud se realizó con credenciales temporales obtenidas mediante la operación AssumeRole de AWS Security Token Service (STS).
Si bien la mayoría de estos tipos de identidad son bastante sencillos, los roles asumidos ofuscan el nombre del usuario que realizó la acción. En la siguiente sección, veremos cómo funcionan las llamadas AssumeRole en la práctica, cómo determinar el usuario detrás de una identidad AssumedRole y cómo un adversario inteligente podría usar una sesión AssumedRole para ocultar su verdadera identidad.
Interpretación de la identidad inicial de un registro de CloudTrail ‘AssumedRole’
Una práctica común para una configuración de múltiples cuentas en AWS es administrar todos los usuarios en una sola cuenta de AWS, a la que llamaremos cuenta A. A su vez, una mejor práctica de seguridad es asegurarse de que los usuarios de IAM no tengan ninguna política de IAM. directamente asociado con ellos, y en su lugar darles credenciales temporales para realizar acciones. Podemos hacer esto creando una cuenta separada (por ejemplo, la cuenta B) que contenga roles de IAM, cada uno de los cuales tiene un conjunto de acciones permitidas que se definen en una política de IAM. Luego, podemos permitir que los usuarios de la cuenta A asuman esos roles cuando necesiten realizar una acción.
Supongamos que un usuario de la cuenta A quiere enumerar todas las regiones de AWS habilitadas en la cuenta B. Primero, el usuario asumiría un rol en la cuenta B que tiene permisos DescribeRegions, obtendría las credenciales temporales devueltas por el comando AssumeRole y luego usaría ellos para ejecutar el comando. El registro de CloudTrail en el que un usuario (userName: Alice) de la cuenta A (accountId: 222222222222) asume un rol en la cuenta B (accountId: 11111111111) se vería así:
{
"eventVersion": "1.05",
"userIdentity": {
"type": "IAMUser",
"principalId": "AIDAAAAAAAAAAAAAAAAAA",
"arn": "arn:aws:iam::222222222222:user/Alice",
"accountId": "222222222222",
"accessKeyId": "AKIAAAAAAAAAAAAAAAAAA",
"userName": "Alice"
},
"eventTime": "2020-09-22T16:23:50Z",
"eventSource": "sts.amazonaws.com",
"eventName": "AssumeRole",
"awsRegion": "us-east-1",
"sourceIPAddress": "1.2.3.4",
"userAgent": "aws-sdk-go/1.16.8 (go1.12.7; linux; amd64)",
"requestParameters": {
"roleArn": "arn:aws:iam::111111111111:role/ExampleRole",
"roleSessionName": "ExampleRoleSession",
"externalId": "ffffffffffffffffffffffffffffffff",
"durationSeconds": 3600
},
"responseElements": {
"credentials": {
"accessKeyId": "ASIADDDDDDDDDDDDDDDD",
"expiration": "Sep 22, 2020 5:23:50 PM",
"sessionToken": "d2UncmUgaGlyaW5nIDopIGh0dHBzOi8vd3d3LmRhdGFkb2docS5jb20vY2FyZWVycy8K"
},
"assumedRoleUser": {
"assumedRoleId": "AROAEEEEEEEEEEEEEEEEE:ExampleRoleSession",
"arn": "arn:aws:sts::111111111111:assumed-role/ExampleRole/ExampleRoleSession"
}
},
"requestID": "4da64d92-6130-4355-86f2-1609a6eb53e1",
"eventID": "ffef7974-b1a0-4e88-b27f-0b143965f30c",
"resources": [
{
"accountId": "111111111111",
"type": "AWS::IAM::Role",
"ARN": "arn:aws:iam::111111111111:role/ExampleRole"
}
],
"eventType": "AwsApiCall",
"recipientAccountId": "111111111111",
"sharedEventID": "4f61c867-6a49-4c41-a267-388c38e99866"
}
El comando AssumeRole devuelve un AccessKeyId (ASIADDDDDDDDDDDDDDDD) que el usuario Alice puede usar para realizar las acciones delegadas del rol. En el siguiente registro de eventos, podemos ver que un usuario AssumedRole utiliza la clave de acceso ASIADDDDDDDDDDDDDDDD para realizar la operación DescribeRegions; por lo tanto, podemos inferir que el usuario Alice usó la clave de acceso.
{
"eventVersion": "1.05",
"userIdentity": {
"type": "AssumedRole",
"principalId": "AROAEEEEEEEEEEEEEEEEE:ExampleRoleSession",
"arn": "arn:aws:sts::111111111111:assumed-role/ExampleRole/ExampleRoleSession",
"accountId": "111111111111",
"accessKeyId": "ASIADDDDDDDDDDDDDDDD",
"sessionContext": {
"sessionIssuer": {
"type": "Role",
"principalId": "AROAEEEEEEEEEEEEEEEEE",
"arn": "arn:aws:iam::111111111111:role/ExampleRole",
"accountId": "111111111111",
"userName": "ExampleRole"
},
"webIdFederationData": {},
"attributes": {
"mfaAuthenticated": "false",
"creationDate": "2020-09-22T15:58:31Z"
}
}
},
"eventTime": "2020-09-22T16:26:02Z",
"eventSource": "ec2.amazonaws.com",
"eventName": "DescribeRegions",
"awsRegion": "us-east-1",
"sourceIPAddress": "1.2.3.4",
"userAgent": "aws-sdk-go/1.16.8 (go1.12.7; linux; amd64)",
"requestParameters": {
"regionSet": {}
},
"responseElements": null,
"requestID": "0a857cb2-90c4-4f09-9624-1149fb27f8a1",
"eventID": "26fe99a5-8ed5-4923-9cf7-b6cdf96fa5f3",
"eventType": "AwsApiCall",
"recipientAccountId": "111111111111"
}
Controlar los nombres de sesión de AssumedRole
Una buena manera de controlar los roles asumidos y rastrear más fácilmente a los usuarios que realizan acciones utilizando los roles asumidos es estipular el nombre de sesión del usuario. Para hacer esto, especifique los nombres de sesión permitidos en la política de confianza del rol que se asumirá. Por ejemplo la siguiente política de confianza especifica que para asumir un rol el usuario debe nombrar su sesión con su propio nombre de usuario. De lo contrario, el comando AssumeRole fallará.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::<AccountNumber>:root"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringLike": {
"sts:RoleSessionName": "${aws:username}"
}
}
}
]
}
Con esta configuración, puede rastrear y filtrar fácilmente las acciones realizadas en cada sesión de rol asumido, o atrapar a cualquiera que no proporcione un nombre de sesión válido. Para obtener más ejemplos de control de nombres de sesión, consulte la publicación de blog de AWS relacionada.
Registros clave de auditoría de CloudTrail para monitorear
Las políticas de IAM en AWS son complejas; potencialmente pueden proporcionar a los usuarios permisos para acceder a todos los recursos dentro de una cuenta de AWS. Esto significa que existe una amplia oportunidad para configuraciones erróneas de seguridad que, sin darse cuenta, permitirán que alguien manipule su entorno y se dé más acceso a sus activos. Al monitorear sus registros de auditoría, puede obtener una imagen más completa de la actividad de los usuarios y las formas en que los usuarios interactúan con sus recursos, incluso si están autorizados o no para realizar esas interacciones en primer lugar.
Los atacantes a menudo buscan permisos de IAM demasiado permisivos o configuraciones incorrectas en una amplia variedad de recursos de AWS, incluidos:
-Usuarios/roles de IAM
-Instancias EC2
-Cubos S3
Por ejemplo, un depósito de S3 puede tener una política adjunta que proporciona acceso de lectura a todos los usuarios autenticados, en lugar de solo a los usuarios autenticados dentro de su cuenta. Si un atacante descubriera esta vulnerabilidad, podría leer todos los datos guardados dentro de ese depósito, lo que podría exponer la información del cliente o de la empresa.
Sus registros de CloudTrail contienen un registro confiable de la actividad del usuario y, una vez que sepa en qué registros concentrarse, puede brindarle toda la información que necesita para monitorear su entorno. Los siguientes tipos de registros basados en recursos son particularmente importantes, ya que es donde se originarán la mayoría de las amenazas:
-Cuentas de usuario
-Buckets
-Componentes de red
A continuación, veremos algunos registros de muestra generados a partir de estas operaciones basadas en recursos. Al leer los registros de eventos, siempre debe prestar atención a los atributos JSON que pueden ayudarlo a detectar un posible ataque o una configuración incorrecta. Estos incluyen la respuesta de una llamada (es decir, los elementos de respuesta), la llamada a la API que se realizó (es decir, el nombre del evento) y cualquier información de identificación, como el usuario o el rol que llamó al comando (es decir, varios campos bajo userIdentity) .
Cuentas de usuario
Una de las formas más comunes para que un atacante se infiltre en su entorno es utilizando una clave de acceso secreta de AWS expuesta y enumerando los permisos de la clave. Si la clave expuesta tiene amplios permisos de administración, el atacante puede otorgarse más permisos mientras deshabilita su infraestructura de seguridad. Supervisar sus registros de CloudTrail para la siguiente actividad puede ayudarlo a alertarlo sobre los atacantes mientras inspeccionan sus permisos e intentan mantener la persistencia en su entorno:
–Actividad no autorizada
Los registros de actividad de usuarios no autorizados contienen el siguiente mensaje de error en los elementos de respuesta:
{
[...],
"errorCode": "Client.UnauthorizedOperation",
"errorMessage": "You are not authorized to perform this operation.",
"requestParameters": {
"regionSet": {}
},
"responseElements": null,
"requestID": "0a857cb2-90c4-4f09-9624-1149fb27f8a1",
"eventID": "26fe99a5-8ed5-4923-9cf7-b6cdf96fa5f3",
"eventType": "AwsApiCall",
"recipientAccountId": "111111111111"
}
Un solo registro de actividad no autorizada no es necesariamente indicativo de una amenaza. Por ejemplo, la acción no autorizada puede haber ocurrido debido a que un usuario no tenía los permisos necesarios para ver ciertos recursos de la consola de AWS. O podría ser el resultado de un servicio que intenta llamar a un recurso al que no tiene acceso.
Sin embargo, si esta es la primera vez que un usuario de IAM recibe un error de autorización, podría valer la pena investigar qué causó la vulnerabilidad. Podría ser el resultado de que un atacante intente usar la cuenta o el servicio para obtener más acceso a sus recursos. Por ejemplo, podrían intentar crear un nuevo usuario o rol como puerta trasera en su entorno, o expandir la política de IAM ya asociada con un usuario o rol al que obtuvieron acceso.
-AWS Guard Duty Detector Eliminado
Para pasar desapercibido al realizar acciones no autorizadas o malintencionadas, un atacante podría intentar desactivar los detectores de amenazas de Amazon GuardDuty que se ejecutan en su cuenta de AWS. Siempre vale la pena investigar cualquier caso de eliminación del detector GuardDuty.
Cubos
Los atacantes a menudo se dirigen a depósitos S3 cuando intentan violar su entorno. Al igual que con las cuentas de usuario, un atacante podría obtener acceso al contenido de un depósito debido a una mala configuración de seguridad o un error humano. Al monitorear sus registros de CloudTrail, puede detectar las siguientes técnicas de ataque de modificación y enumeración de depósitos.
-Cubos de AWS S3 enumerados
-Política de depósito de AWS S3 modificada
Si un atacante obtiene acceso a una instancia de EC2, lo primero que podría hacer es enumerar todos los depósitos de S3 a los que tiene acceso desde el perfil de la instancia correspondiente, o intentar cambiar la política de acceso de un depósito por completo. Como la mayoría de los recursos automatizados ya tienen acceso directo a todos los depósitos que necesitan, por lo general vale la pena investigar una llamada a ListBuckets o PutBucketPolicy.
-Bloqueo de acceso público de AWS S3 eliminado
De manera similar, un intento de eliminar un bloque de acceso público adjunto a un depósito S3 es un evento que debe investigarse. Este podría ser un usuario legítimo que intenta realizar una tarea eliminando un control de seguridad como mecanismo de depuración. Alternativamente, podría ser un atacante que intente abrir el depósito a la Internet pública. Recomendamos investigar los registros de eventos de DeleteAccountPublicAccessBlock lo antes posible.
Componentes de red
Los atacantes también pueden intentar acceder a su entorno a través de un recurso de red mal configurado como una VPC, una tabla de rutas, una puerta de enlace de red, una lista de control de acceso a la red o un grupo de seguridad. Los registros de CloudTrail pueden ayudarlo a detectar los siguientes tipos de posibles ataques a la red y tomar las medidas adecuadas para resolver la infracción.
-AWS VPC creado o modificado
-Tabla de rutas de AWS creada o modificada
-AWS Network Gateway creado o modificado
-Lista de control de acceso a la red de AWS creada o modificada
-Grupo de seguridad de AWS creado o modificado
Para verificar la postura de sus recursos de red y asegurarse de que estén configurados de manera segura, recomendamos utilizar la herramienta de Monitoreo de cumplimiento de Datadog, que escanea su entorno de AWS en busca de configuraciones incorrectas en tiempo real.
Es un conocido experto en seguridad móvil y análisis de malware. Estudió Ciencias de la Computación en la NYU y comenzó a trabajar como analista de seguridad cibernética en 2003. Trabaja activamente como experto en antimalware. También trabajó para empresas de seguridad como Kaspersky Lab. Su trabajo diario incluye investigar sobre nuevos incidentes de malware y ciberseguridad. También tiene un profundo nivel de conocimiento en seguridad móvil y vulnerabilidades móviles.