Peritaje de fraude interno en empresas con infraestructura cloud

El CEO de una startup tecnológica sospecha que su CTO, con quien está en proceso de separación societaria, ha estado copiando código fuente y datos de clientes a su cuenta personal de AWS. El problema: toda la infraestructura está en cloud, el CTO tiene acceso privilegiado, y cualquier movimiento en falso le alertará y destruirá evidencia.

Este tipo de casos requiere un enfoque quirúrgico. Como perito informático forense con experiencia como CTO y certificación AWS Security, conozco desde dentro cómo operan estos sistemas y dónde quedan los rastros que otros no saben buscar.

El desafío del fraude interno en entornos cloud

Por qué es más difícil que en entornos tradicionales

En una empresa con servidores propios, puedes revisar discos duros, emails locales y logs del servidor. En empresas cloud-native, la situación es diferente:

• Acceso legítimo: El sospechoso tiene permisos reales para acceder a los datos
• Múltiples servicios: Datos distribuidos entre S3, RDS, GitHub, Slack, Google Drive…
• Sincronización personal: Posibilidad de sincronizar datos corporativos con cuentas personales
• Borrado de rastros: Conocimiento técnico para eliminar evidencia

Qué busco en una investigación de fraude interno

Mi experiencia gestionando equipos técnicos como CTO me permite saber qué patrones buscar:

1. Actividad fuera de horario laboral

• Accesos a sistemas críticos de madrugada o fines de semana
• Descargas masivas en horarios inusuales

2. Acceso a datos no relacionados con su rol

• Desarrollador accediendo a datos de clientes
• Ingeniero descargando contratos o información financiera

3. Uso de servicios de transferencia

• WeTransfer, Dropbox personal, Google Drive personal
• Conexiones a buckets S3 externos

4. Preparación de salida

• Exportaciones masivas días antes de renunciar
• Limpieza de historial o eliminación de archivos

Metodología de investigación encubierta

Fase 1: Recopilación silenciosa de evidencia

El objetivo es obtener evidencia sin alertar al sospechoso. Esto requiere acceso a nivel de administrador sin que quede registro visible para el usuario investigado.

En AWS:

# Habilitar logging adicional sin que el usuario lo sepa
# (requiere permisos de administrador de la organización)

# Activar CloudTrail con logging de datos S3
aws cloudtrail put-event-selectors \
  --trail-name investigation-trail \
  --event-selectors '[{
    "ReadWriteType": "All",
    "IncludeManagementEvents": true,
    "DataResources": [{
      "Type": "AWS::S3::Object",
      "Values": ["arn:aws:s3:::*/*"]
    }]
  }]'

# Redirigir logs a bucket de investigación (no visible para el usuario)

En GitHub Enterprise:

# Exportar audit log de la organización
gh api /orgs/EMPRESA/audit-log \
  --paginate \
  -X GET \
  -f phrase="actor:usuario_sospechoso" \
  > github-audit-$(date +%Y%m%d).json

En Google Workspace:

# Usando Admin SDK para exportar actividad
# Accesos a Drive, emails enviados, archivos compartidos

Fase 2: Análisis de patrones de comportamiento

Una vez tengo los logs, busco anomalías respecto al comportamiento habitual:

-- Análisis de accesos S3 del usuario sospechoso
WITH baseline AS (
  SELECT
    DATE_TRUNC('hour', eventTime) as hora,
    COUNT(*) as accesos_promedio
  FROM cloudtrail_logs
  WHERE userIdentity.userName = 'usuario_sospechoso'
    AND eventTime BETWEEN '2024-06-01' AND '2024-12-01'
  GROUP BY DATE_TRUNC('hour', eventTime)
),
reciente AS (
  SELECT
    DATE_TRUNC('hour', eventTime) as hora,
    COUNT(*) as accesos,
    SUM(CASE WHEN eventName = 'GetObject' THEN 1 ELSE 0 END) as descargas
  FROM cloudtrail_logs
  WHERE userIdentity.userName = 'usuario_sospechoso'
    AND eventTime > '2024-12-01'
  GROUP BY DATE_TRUNC('hour', eventTime)
)
SELECT
  r.hora,
  r.accesos,
  r.descargas,
  AVG(b.accesos_promedio) as promedio_historico,
  (r.accesos - AVG(b.accesos_promedio)) / STDDEV(b.accesos_promedio) as desviacion
FROM reciente r
CROSS JOIN baseline b
GROUP BY r.hora, r.accesos, r.descargas
HAVING (r.accesos - AVG(b.accesos_promedio)) / STDDEV(b.accesos_promedio) > 2
ORDER BY r.hora;

Fase 3: Correlación con eventos externos

Los fraudes internos suelen correlacionar con eventos externos:

Mi investigación incluye correlacionar la actividad técnica con el contexto empresarial que me proporciona el cliente.

Tipos de fraude interno que investigo

1. Robo de propiedad intelectual

Escenario típico: Desarrollador senior que va a montar empresa competidora.

Qué busco:

• Clonados de repositorios completos
• Exportaciones de bases de datos de clientes
• Descargas de documentación técnica
• Accesos a secretos y credenciales

Evidencia clave:

-- Detectar clonados de repos privados
SELECT
  eventTime,
  actor,
  repo,
  action
FROM github_audit_log
WHERE actor = 'usuario_sospechoso'
  AND action IN ('repo.clone', 'repo.download_zip')
ORDER BY eventTime DESC;

2. Exfiltración de datos de clientes

Escenario típico: Comercial que se va a la competencia con la cartera de clientes.

Qué busco:

• Exportaciones de CRM (Salesforce, HubSpot)
• Descargas de listas de contactos
• Reenvío de emails a cuentas personales
• Sincronización con Google Drive personal

Evidencia clave:

-- Actividad de exportación en Salesforce
SELECT
  Created_Date,
  User_Name,
  Action,
  Section,
  Rows_Processed
FROM salesforce_event_log
WHERE User_Name = 'usuario_sospechoso'
  AND Action LIKE '%Export%'
ORDER BY Created_Date DESC;

3. Sabotaje de sistemas

Escenario típico: Empleado despedido que mantiene accesos y sabotea la infraestructura.

Qué busco:

• Eliminación de recursos críticos (instancias, bases de datos)
• Modificación de configuraciones de seguridad
• Creación de backdoors o accesos alternativos
• Borrado de logs y evidencia

Evidencia clave:

-- Acciones destructivas en AWS
SELECT
  eventTime,
  userIdentity.userName,
  eventName,
  requestParameters
FROM cloudtrail_logs
WHERE eventName IN (
  'DeleteDBInstance', 'TerminateInstances', 'DeleteBucket',
  'DeleteSecurityGroup', 'RevokeSecurityGroupIngress'
)
ORDER BY eventTime DESC;

4. Fraude financiero mediante manipulación de sistemas

Escenario típico: Empleado que modifica precios, descuentos o comisiones en el sistema.

Qué busco:

• Modificaciones en bases de datos de precios
• Accesos a paneles de administración fuera de proceso normal
• Patrones de transacciones que benefician a terceros específicos

Caso de estudio: El CTO que se iba con todo

Situación

Startup de 50 empleados. El CTO (socio minoritario) está en proceso de salida conflictiva. La empresa sospecha que está preparando una empresa competidora con tecnología copiada.

Mi investigación

Semana 1: Recopilación silenciosa

• Activé logging adicional en AWS sin notificación
• Exporté audit logs de GitHub, Slack y Google Workspace
• Documenté el estado actual de todos los repositorios

Semana 2: Análisis de patrones

• Identifiqué 847 clonados de repositorios en las últimas 4 semanas
• Detecté sincronización de Google Drive corporativo con cuenta personal
• Encontré conexiones a bucket S3 externo con datos de producción

Semana 3: Correlación y timeline

• El bucket S3 externo pertenecía a una cuenta AWS registrada a nombre del CTO
• Los clonados coincidían con fechas de reuniones con potenciales inversores
• La empresa competidora se registró 2 semanas antes de la renuncia formal

Resultado

El informe pericial documentó:

• 12.3 GB de código fuente copiado a infraestructura personal
• Lista completa de clientes exportada vía Google Takeout
• Documentación técnica confidencial en bucket S3 externo
• Timeline completo de preparación de la empresa competidora

La empresa utilizó el informe para:

1. Procedimiento judicial por competencia desleal
2. Denuncia por revelación de secretos empresariales
3. Negociación de indemnización

Consideraciones legales específicas

Legitimidad de la investigación

Para que la evidencia sea admisible, la investigación debe ser legítima:

• Proporcionalidad: La gravedad de la sospecha justifica la investigación
• Finalidad: El objetivo es legítimo (proteger activos empresariales)
• Información previa: El empleado conocía la política de uso de sistemas corporativos
• Minimización: Solo se analiza lo necesario para la investigación

Preservación de la cadena de custodia

Cada pieza de evidencia se documenta con:

• Hash SHA-256 del archivo original
• Timestamp de adquisición
• Método de obtención
• Persona responsable en cada paso

Preparación para el procedimiento judicial

Mi informe está diseñado para ser utilizado en:

• Procedimiento laboral (despido disciplinario)
• Procedimiento civil (competencia desleal, daños y perjuicios)
• Procedimiento penal (revelación de secretos, acceso ilícito)

Cuándo contactar a un perito especializado

• Antes del despido: Para asegurar evidencia que soporte la decisión
• Al detectar anomalías: Comportamiento inusual en logs o sistemas
• En procesos de salida conflictiva: Socios, directivos o empleados clave
• Tras detectar competidor sospechoso: Producto demasiado similar, clientes que se van

No esperes a que el daño sea irreversible. La investigación preventiva es siempre más efectiva que la reactiva.

Sobre el autor: Jonathan Izquierdo es perito informático forense con certificación AWS Security Specialty y más de 15 años de experiencia como CTO gestionando equipos técnicos. Esta experiencia operativa permite investigaciones más precisas porque conozco desde dentro cómo trabajan los perfiles técnicos y dónde dejan rastro.

> Ver servicios de peritaje cloud