mirror of
https://github.com/mukul975/Anthropic-Cybersecurity-Skills.git
synced 2026-06-11 13:44:56 +03:00
Translate top skills to Spanish
Adds Spanish translations for 7 cybersecurity skills.
This commit is contained in:
juliosuas
GitHub
@@ -0,0 +1,291 @@
|
||||
---
|
||||
name: building-incident-response-dashboard
|
||||
description: >
|
||||
Builds real-time incident response dashboards in Splunk, Elastic, or Grafana to provide SOC
|
||||
analysts and leadership with situational awareness during active incidents, tracking affected
|
||||
systems, containment status, IOC spread, and response timeline. Use when IR teams need unified
|
||||
visibility during incident coordination and post-incident reporting.
|
||||
domain: cybersecurity
|
||||
subdomain: soc-operations
|
||||
tags: [soc, dashboard, incident-response, splunk, visualization, situational-awareness, metrics]
|
||||
version: "1.0"
|
||||
author: mahipal
|
||||
license: Apache-2.0
|
||||
language: es
|
||||
---
|
||||
# Construcción de un Dashboard de Respuesta a Incidentes
|
||||
|
||||
## Cuándo Utilizar
|
||||
|
||||
Utilice esta habilidad cuando:
|
||||
- Los equipos de IR necesitan dashboards en tiempo real durante incidentes activos para coordinación y seguimiento
|
||||
- La dirección del SOC requiere dashboards operacionales que muestren el estado de incidentes y la carga de trabajo de los analistas
|
||||
- Las revisiones post-incidente necesitan líneas de tiempo visuales y evaluaciones de impacto
|
||||
- Las sesiones informativas ejecutivas requieren métricas de incidentes de alto nivel y análisis de tendencias
|
||||
|
||||
**No utilizar** para dashboards de monitoreo diario del SOC (use Incident Review en su lugar) — los dashboards de IR están diseñados para la coordinación de incidentes activos e informes de gestión.
|
||||
|
||||
## Requisitos Previos
|
||||
|
||||
- Plataforma SIEM (Splunk con Dashboard Studio, Elastic Kibana o Grafana)
|
||||
- Datos de eventos notables e incidentes en el SIEM (índice incident_review de Splunk ES)
|
||||
- Integración con sistema de tickets (ServiceNow, Jira) para seguimiento de remediación
|
||||
- Tablas de búsqueda de activos e identidades para enriquecimiento de contexto
|
||||
- Acceso de publicación de dashboards para el equipo SOC y distribución a la gerencia
|
||||
|
||||
## Flujo de Trabajo
|
||||
|
||||
### Paso 1: Diseñar el Layout del Dashboard de Incidente Activo
|
||||
|
||||
Construir un dashboard en Splunk Dashboard Studio para seguimiento de incidentes activos:
|
||||
|
||||
```xml
|
||||
<dashboard version="2" theme="dark">
|
||||
<label>Active Incident Response Dashboard</label>
|
||||
<description>Real-time tracking for IR-2024-0450</description>
|
||||
|
||||
<row>
|
||||
<panel>
|
||||
<title>Incident Summary</title>
|
||||
<single>
|
||||
<search>
|
||||
<query>
|
||||
| makeresults
|
||||
| eval incident_id="IR-2024-0450",
|
||||
status="CONTAINMENT",
|
||||
severity="Critical",
|
||||
affected_hosts=7,
|
||||
contained_hosts=5,
|
||||
iocs_identified=23,
|
||||
hours_elapsed=round((now()-strptime("2024-03-15 14:00","%Y-%m-%d %H:%M"))/3600,1)
|
||||
| table incident_id, status, severity, affected_hosts, contained_hosts, iocs_identified, hours_elapsed
|
||||
</query>
|
||||
</search>
|
||||
</single>
|
||||
</panel>
|
||||
</row>
|
||||
</dashboard>
|
||||
```
|
||||
|
||||
### Paso 2: Construir el Panel de Sistemas Afectados en Tiempo Real
|
||||
|
||||
Rastrear sistemas afectados y su estado de contención:
|
||||
|
||||
```spl
|
||||
| inputlookup ir_affected_systems.csv
|
||||
| eval status_color = case(
|
||||
status="Contained", "#2ecc71",
|
||||
status="Compromised", "#e74c3c",
|
||||
status="Investigating", "#f39c12",
|
||||
status="Recovered", "#3498db",
|
||||
1=1, "#95a5a6"
|
||||
)
|
||||
| stats count by status
|
||||
| eval order = case(status="Compromised", 1, status="Investigating", 2,
|
||||
status="Contained", 3, status="Recovered", 4)
|
||||
| sort order
|
||||
| table status, count
|
||||
|
||||
--- Tabla detallada de hosts
|
||||
| inputlookup ir_affected_systems.csv
|
||||
| lookup asset_lookup_by_cidr ip AS host_ip OUTPUT category, owner, priority
|
||||
| table hostname, host_ip, category, owner, status, containment_time,
|
||||
compromise_vector, analyst_assigned
|
||||
| sort status, hostname
|
||||
```
|
||||
|
||||
### Paso 3: Construir el Panel de Seguimiento de IOCs
|
||||
|
||||
Monitorear la propagación de IOCs en el entorno:
|
||||
|
||||
```spl
|
||||
--- IOCs identificados durante el incidente
|
||||
index=* (src_ip IN ("185.234.218.50", "45.77.123.45") OR
|
||||
dest IN ("evil-c2.com", "malware-drop.com") OR
|
||||
file_hash IN ("a1b2c3d4...", "e5f6a7b8..."))
|
||||
earliest="2024-03-14"
|
||||
| stats count AS hits, dc(src_ip) AS unique_sources,
|
||||
dc(dest) AS unique_dests, latest(_time) AS last_seen
|
||||
by sourcetype
|
||||
| sort - hits
|
||||
|
||||
--- Línea de tiempo de IOCs
|
||||
index=* (src_ip IN ("185.234.218.50") OR dest="evil-c2.com")
|
||||
earliest="2024-03-14"
|
||||
| timechart span=1h count by sourcetype
|
||||
|
||||
--- Seguimiento de descubrimiento de nuevos IOCs
|
||||
| inputlookup ir_ioc_list.csv
|
||||
| stats count by ioc_type, source, discovery_time
|
||||
| sort discovery_time
|
||||
| table discovery_time, ioc_type, ioc_value, source, status
|
||||
```
|
||||
|
||||
### Paso 4: Construir el Panel de Línea de Tiempo de Respuesta
|
||||
|
||||
Crear una línea de tiempo cronológica del incidente:
|
||||
|
||||
```spl
|
||||
| inputlookup ir_timeline.csv
|
||||
| sort _time
|
||||
| eval phase = case(
|
||||
action_type="detection", "Detección",
|
||||
action_type="triage", "Triaje",
|
||||
action_type="containment", "Contención",
|
||||
action_type="eradication", "Erradicación",
|
||||
action_type="recovery", "Recuperación",
|
||||
1=1, "Otro"
|
||||
)
|
||||
| eval phase_color = case(
|
||||
phase="Detección", "#e74c3c",
|
||||
phase="Triaje", "#f39c12",
|
||||
phase="Contención", "#e67e22",
|
||||
phase="Erradicación", "#2ecc71",
|
||||
phase="Recuperación", "#3498db"
|
||||
)
|
||||
| table _time, phase, action, analyst, details
|
||||
```
|
||||
|
||||
Ejemplo de datos de línea de tiempo:
|
||||
```csv
|
||||
_time,action_type,action,analyst,details
|
||||
2024-03-15 14:00,detection,Alerta activada - Beacon de Cobalt Strike detectado,splunk_es,Evento notable NE-2024-08921
|
||||
2024-03-15 14:12,triage,Alerta triada - verdadero positivo confirmado,analyst_jdoe,Puntuación VT 52/72 en hash del beacon
|
||||
2024-03-15 14:23,containment,Host WORKSTATION-042 aislado,analyst_jdoe,Aislamiento de red con CrowdStrike
|
||||
2024-03-15 14:35,containment,Dominio C2 bloqueado en firewall,analyst_msmith,Regla desplegada en Palo Alto
|
||||
2024-03-15 15:00,eradication,Escaneo de IOCs a nivel empresarial iniciado,analyst_jdoe,Búsqueda en Splunk en todos los índices
|
||||
2024-03-15 15:30,containment,3 hosts adicionales identificados y aislados,analyst_msmith,Movimiento lateral confirmado
|
||||
2024-03-15 16:00,eradication,Malware eliminado de todos los hosts afectados,analyst_tier3,Limpieza con CrowdStrike RTR
|
||||
2024-03-15 18:00,recovery,Sistemas restaurados y en monitoreo,analyst_msmith,Período de monitoreo de 72 horas iniciado
|
||||
```
|
||||
|
||||
### Paso 5: Construir el Dashboard de Operaciones del SOC
|
||||
|
||||
Rastrear las métricas generales de rendimiento del SOC:
|
||||
|
||||
```spl
|
||||
--- Volumen de incidentes por severidad (últimos 30 días)
|
||||
index=notable earliest=-30d
|
||||
| stats count by urgency
|
||||
| eval order = case(urgency="critical", 1, urgency="high", 2, urgency="medium", 3,
|
||||
urgency="low", 4, urgency="informational", 5)
|
||||
| sort order
|
||||
|
||||
--- MTTD (Tiempo Medio de Detección)
|
||||
index=notable earliest=-30d status_label="Resolved*"
|
||||
| eval mttd_minutes = round((time_of_first_event - orig_time) / 60, 1)
|
||||
| stats avg(mttd_minutes) AS avg_mttd, median(mttd_minutes) AS med_mttd,
|
||||
perc95(mttd_minutes) AS p95_mttd
|
||||
|
||||
--- MTTR (Tiempo Medio de Respuesta/Resolución)
|
||||
index=notable earliest=-30d status_label="Resolved*"
|
||||
| eval mttr_hours = round((status_end - _time) / 3600, 1)
|
||||
| stats avg(mttr_hours) AS avg_mttr, median(mttr_hours) AS med_mttr by urgency
|
||||
|
||||
--- Distribución de carga de trabajo por analista
|
||||
index=notable earliest=-7d
|
||||
| stats count by owner
|
||||
| sort - count
|
||||
|
||||
--- Desglose de disposición de alertas
|
||||
index=notable earliest=-30d status_label IN ("Resolved*", "Closed*")
|
||||
| stats count by disposition
|
||||
| eval percentage = round(count / sum(count) * 100, 1)
|
||||
| sort - count
|
||||
```
|
||||
|
||||
### Paso 6: Construir el Dashboard de Sesión Informativa Ejecutiva
|
||||
|
||||
Crear un dashboard de alto nivel para la dirección durante incidentes mayores:
|
||||
|
||||
```spl
|
||||
--- Panel de resumen ejecutivo
|
||||
| makeresults
|
||||
| eval metrics = "Impacto de Negocio: 1 servidor de archivos fuera de línea (depto. Finanzas), "
|
||||
."Recuperación Estimada: 4 horas, "
|
||||
."Riesgo de Pérdida de Datos: Bajo (respaldos verificados), "
|
||||
."Impacto al Cliente: Ninguno, "
|
||||
."Notificación Regulatoria: No requerida (sin exposición de PII confirmada)"
|
||||
|
||||
--- Comparación de tendencias (mes actual vs mes anterior)
|
||||
index=notable earliest=-60d
|
||||
| eval period = if(_time > relative_time(now(), "-30d"), "Mes Actual", "Mes Anterior")
|
||||
| stats count by period, urgency
|
||||
| chart sum(count) AS incidents by period, urgency
|
||||
|
||||
--- Principales categorías de amenazas
|
||||
index=notable earliest=-30d
|
||||
| top rule_name limit=10
|
||||
| table rule_name, count, percent
|
||||
```
|
||||
|
||||
### Paso 7: Automatizar las Actualizaciones del Dashboard
|
||||
|
||||
Usar búsquedas programadas de Splunk para mantener los datos del dashboard:
|
||||
|
||||
```spl
|
||||
--- Búsqueda programada para actualizar la tabla de sistemas afectados (se ejecuta cada 5 minutos)
|
||||
index=* (src_ip IN [| inputlookup ir_ioc_list.csv | search ioc_type="ip"
|
||||
| fields ioc_value | rename ioc_value AS src_ip])
|
||||
earliest=-1h
|
||||
| stats latest(_time) AS last_seen, count AS event_count,
|
||||
values(sourcetype) AS data_sources by src_ip
|
||||
| eval status = if(last_seen > relative_time(now(), "-15m"), "Activo", "Inactivo")
|
||||
| outputlookup ir_affected_systems_auto.csv
|
||||
```
|
||||
|
||||
## Conceptos Clave
|
||||
|
||||
| Término | Definición |
|
||||
|---------|-----------|
|
||||
| **Conciencia Situacional** | Comprensión en tiempo real del alcance del incidente, sistemas afectados y progreso de la respuesta |
|
||||
| **MTTD** | Tiempo Medio de Detección — tiempo promedio desde la ocurrencia de la amenaza hasta la generación de la alerta del SOC |
|
||||
| **MTTR** | Tiempo Medio de Respuesta — tiempo promedio desde la alerta hasta la resolución o contención del incidente |
|
||||
| **Tasa de Contención** | Porcentaje de sistemas afectados aislados exitosamente en relación con el total de sistemas comprometidos |
|
||||
| **Gráfico de Quema** | Seguimiento visual de las tareas de investigación abiertas restantes a lo largo del tiempo durante un incidente |
|
||||
| **Sesión Informativa Ejecutiva** | Dashboard de resumen no técnico que muestra el impacto en el negocio, la línea de tiempo y el estado de recuperación |
|
||||
|
||||
## Herramientas y Sistemas
|
||||
|
||||
- **Splunk Dashboard Studio**: Framework moderno de dashboards con visualización de arrastrar y soltar y datos en tiempo real
|
||||
- **Elastic Kibana Dashboard**: Plataforma de visualización con Lens, Maps y Canvas para dashboards de seguridad
|
||||
- **Grafana**: Plataforma de visualización de código abierto que soporta múltiples fuentes de datos incluyendo Elasticsearch y Splunk
|
||||
- **Microsoft Sentinel Workbooks**: Framework de dashboards nativo de Azure con visualización de analíticas basadas en Kusto
|
||||
- **TheHive**: Plataforma de respuesta a incidentes de código abierto con seguimiento de casos integrado y dashboards de métricas
|
||||
|
||||
## Escenarios Comunes
|
||||
|
||||
- **Incidente de Ransomware Activo**: Dashboard que muestra la propagación del cifrado, estado de contención, verificación de respaldos, progreso de recuperación
|
||||
- **Investigación de Brecha de Datos**: Dashboard que rastrea almacenes de datos afectados, volumen de exfiltración, requisitos de notificación
|
||||
- **Respuesta a Campaña de Phishing**: Dashboard que muestra el conteo de destinatarios, tasa de clics, exposición de credenciales, estado de remediación
|
||||
- **Informe Mensual del SOC**: Dashboard para la dirección con tendencias de incidentes, métricas MTTD/MTTR, rendimiento de analistas
|
||||
- **Auditoría de Cumplimiento**: Dashboard que demuestra cobertura de detección, cumplimiento de SLA de respuesta y métricas de cierre de incidentes
|
||||
|
||||
## Formato de Salida
|
||||
|
||||
```text
|
||||
DASHBOARD DE RESPUESTA A INCIDENTES — IR-2024-0450
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
|
||||
ESTADO: FASE DE CONTENCIÓN (6h 30m transcurridas)
|
||||
|
||||
Sistemas Afectados: Progreso de Contención:
|
||||
Comprometidos: 2 [==========----------] 71%
|
||||
En Investigación: 1 5 de 7 sistemas contenidos
|
||||
Contenidos: 3
|
||||
Recuperados: 1
|
||||
|
||||
Resumen de IOCs: Línea de Tiempo de Respuesta:
|
||||
IPs: 4 14:00 — Alerta activada
|
||||
Dominios: 2 14:12 — Confirmado como malicioso
|
||||
Hashes: 3 14:23 — Primer host aislado
|
||||
URLs: 5 15:00 — Escaneo empresarial iniciado
|
||||
Correos: 1 15:30 — 3 hosts más aislados
|
||||
|
||||
Métricas Clave:
|
||||
MTTD: 12 minutos
|
||||
MTTC: 23 minutos (primer host)
|
||||
Analistas Activos: 3 (Nivel 2: 2, Nivel 3: 1)
|
||||
|
||||
Impacto de Negocio: BAJO — Servidor de archivos de Finanzas fuera de línea, sin afectación a sistemas orientados al cliente
|
||||
```
|
||||
@@ -0,0 +1,36 @@
|
||||
---
|
||||
name: configuring-suricata-for-network-monitoring
|
||||
description: Configure and tune Suricata IDS/IPS for network threat detection and monitoring.
|
||||
domain: cybersecurity
|
||||
subdomain: network-security
|
||||
tags: [suricata, ids, ips, network-security, threat-detection]
|
||||
version: "1.0"
|
||||
author: mahipal
|
||||
license: Apache-2.0
|
||||
language: es
|
||||
---
|
||||
|
||||
# Configuración de Suricata para Monitoreo de Red
|
||||
|
||||
## Descripción General
|
||||
|
||||
Suricata es un motor IDS/IPS de alto rendimiento de código abierto capaz de inspección profunda de paquetes, detección basada en firmas y anomalías, y análisis de protocolos en tiempo real.
|
||||
|
||||
## Prerrequisitos
|
||||
|
||||
- Suricata 7.0+ instalado
|
||||
- Acceso root/sudo para configuración de red
|
||||
- Interfaz de red en modo promiscuo (SPAN/TAP)
|
||||
|
||||
## Pasos
|
||||
|
||||
1. Instalar Suricata y configurar interfaz de captura
|
||||
2. Configurar `suricata.yaml` con redes HOME_NET y EXTERNAL_NET
|
||||
3. Habilitar fuentes de reglas con `suricata-update`
|
||||
4. Desarrollar reglas personalizadas para la organización
|
||||
5. Configurar umbrales para reducir falsos positivos
|
||||
6. Validar con `suricata -T` y monitorear vía `eve.json`
|
||||
|
||||
## Resultado Esperado
|
||||
|
||||
Motor Suricata operativo con alertas precisas de amenazas de red y falsos positivos minimizados.
|
||||
@@ -0,0 +1,45 @@
|
||||
---
|
||||
name: detecting-credential-dumping-techniques
|
||||
description: Detect LSASS credential dumping, SAM database extraction, and NTDS.dit theft using Sysmon Event ID 10, Windows Security logs, and SIEM correlation rules
|
||||
domain: cybersecurity
|
||||
subdomain: threat-detection
|
||||
tags:
|
||||
- credential-dumping
|
||||
- lsass
|
||||
- mimikatz
|
||||
- sysmon
|
||||
- active-directory
|
||||
- windows-security
|
||||
- defense-evasion
|
||||
version: "1.0"
|
||||
author: mahipal
|
||||
license: Apache-2.0
|
||||
language: es
|
||||
---
|
||||
|
||||
# Detección de Técnicas de Volcado de Credenciales
|
||||
|
||||
## Descripción General
|
||||
|
||||
El volcado de credenciales (MITRE ATT&CK T1003) es una técnica de post-explotación donde los adversarios extraen credenciales de autenticación de la memoria del sistema operativo, hives del registro o bases de datos del controlador de dominio. Esta habilidad cubre la detección de acceso a la memoria de LSASS mediante Sysmon Event ID 10 (ProcessAccess), la exportación del hive del registro SAM mediante reg.exe, la extracción de NTDS.dit mediante ntdsutil/vssadmin, y el abuso de MiniDump con comsvcs.dll. Las reglas de detección analizan bitmasks de GrantedAccess, procesos invocantes sospechosos y firmas de herramientas conocidas.
|
||||
|
||||
## Requisitos Previos
|
||||
|
||||
- Sysmon v14+ desplegado con registro de ProcessAccess (Event ID 10) para lsass.exe
|
||||
- Política de auditoría de seguridad de Windows habilitando la creación de procesos (Event ID 4688) con registro de línea de comandos
|
||||
- SIEM Splunk o Elastic ingiriendo registros de Sysmon y de seguridad de Windows
|
||||
- Python 3.8+ para análisis de registros
|
||||
|
||||
## Pasos
|
||||
|
||||
1. Configurar Sysmon para registrar eventos ProcessAccess dirigidos a lsass.exe
|
||||
2. Reenviar Sysmon Event ID 10 y Windows Event ID 4688 al SIEM
|
||||
3. Crear reglas de detección para patrones de GrantedAccess conocidos (0x1010, 0x1FFFFF)
|
||||
4. Detectar MiniDump con comsvcs.dll y procdump.exe apuntando al PID de LSASS
|
||||
5. Alertar sobre comandos de exportación de hives SAM/SECURITY/SYSTEM mediante reg.exe
|
||||
6. Detectar creación de shadow copy con ntdsutil/vssadmin para robo de NTDS.dit
|
||||
7. Correlacionar detecciones con contexto de usuario/host para puntuación de riesgo
|
||||
|
||||
## Salida Esperada
|
||||
|
||||
Informe JSON que contiene indicadores detectados de volcado de credenciales con clasificación de técnica, calificaciones de severidad, detalles del proceso, mapeo a MITRE ATT&CK, y consultas de detección para Splunk/Elastic.
|
||||
@@ -0,0 +1,122 @@
|
||||
# Lateral Movement Investigation Checklist
|
||||
|
||||
## Incident Details
|
||||
|
||||
| Field | Value |
|
||||
|---|---|
|
||||
| **Incident ID** | |
|
||||
| **Date/Time Detected** | |
|
||||
| **Analyst** | |
|
||||
| **Detection Source** | Zeek — lateral movement detection |
|
||||
| **Severity** | ☐ Critical ☐ High ☐ Medium ☐ Low |
|
||||
|
||||
## Initial Triage
|
||||
|
||||
- [ ] Review Zeek notice.log for lateral movement alerts
|
||||
- [ ] Identify the suspected source host (patient zero)
|
||||
- [ ] Determine the timeframe of suspicious activity
|
||||
- [ ] Check if activity correlates with known maintenance/change windows
|
||||
- [ ] Verify source host is not a known admin workstation
|
||||
|
||||
## SMB Admin Share Analysis (T1021.002)
|
||||
|
||||
- [ ] Query `smb_mapping.log` for admin share access (`C$`, `ADMIN$`, `IPC$`)
|
||||
```bash
|
||||
cat smb_mapping.log | zeek-cut ts id.orig_h id.resp_h path | grep -iE '(ADMIN\$|C\$|IPC\$)'
|
||||
```
|
||||
- [ ] Identify the user account used for SMB authentication
|
||||
- [ ] Check `dce_rpc.log` for `svcctl` service creation (PsExec indicator)
|
||||
```bash
|
||||
cat dce_rpc.log | zeek-cut ts id.orig_h id.resp_h endpoint operation | grep -i svcctl
|
||||
```
|
||||
- [ ] List all hosts accessed via admin shares from the source
|
||||
- [ ] Document share paths and timestamps
|
||||
|
||||
## RDP Pivot Analysis (T1021.001)
|
||||
|
||||
- [ ] Query `conn.log` for internal RDP connections
|
||||
```bash
|
||||
cat conn.log | zeek-cut ts id.orig_h id.resp_h id.resp_p duration | awk '$4 == 3389'
|
||||
```
|
||||
- [ ] Identify hosts acting as both RDP client and server (pivot nodes)
|
||||
- [ ] Map the full RDP pivot chain
|
||||
- [ ] Check RDP session durations for anomalies
|
||||
- [ ] Verify if RDP is authorized for identified hosts
|
||||
|
||||
## Pass-the-Hash Analysis (T1550.002)
|
||||
|
||||
- [ ] Query `ntlm.log` for multi-source authentication per user
|
||||
```bash
|
||||
cat ntlm.log | zeek-cut ts id.orig_h username domainname success | sort -k3
|
||||
```
|
||||
- [ ] Identify accounts authenticating from 3+ distinct sources
|
||||
- [ ] Check if flagged accounts are service accounts (expected multi-source)
|
||||
- [ ] Determine if source hosts are authorized for the flagged accounts
|
||||
- [ ] Cross-reference with Active Directory logon events
|
||||
|
||||
## DCSync Analysis (T1003.006)
|
||||
|
||||
- [ ] Query `dce_rpc.log` for `drsuapi` endpoint calls
|
||||
```bash
|
||||
cat dce_rpc.log | zeek-cut ts id.orig_h id.resp_h endpoint operation | grep -i drsuapi
|
||||
```
|
||||
- [ ] Verify if source hosts are legitimate domain controllers
|
||||
- [ ] If non-DC source detected: **ESCALATE IMMEDIATELY**
|
||||
- [ ] Document source IP, destination DC, and timestamp
|
||||
- [ ] Check if krbtgt or privileged accounts may be compromised
|
||||
|
||||
## Lateral Tool Transfer Analysis (T1570)
|
||||
|
||||
- [ ] Query `files.log` for executable transfers between internal hosts
|
||||
```bash
|
||||
cat files.log | zeek-cut ts tx_hosts rx_hosts filename mime_type total_bytes | \
|
||||
grep -E 'x-dosexec|x-executable'
|
||||
```
|
||||
- [ ] Identify transferred filenames and sizes
|
||||
- [ ] Extract file hashes from `files.log` for threat intelligence lookup
|
||||
- [ ] Check if files were subsequently executed (correlate with endpoint logs)
|
||||
|
||||
## Scope Assessment
|
||||
|
||||
- [ ] Total number of affected hosts: ____
|
||||
- [ ] Total number of compromised accounts: ____
|
||||
- [ ] Earliest indicator timestamp: ____
|
||||
- [ ] Latest indicator timestamp: ____
|
||||
- [ ] Network segments affected: ____
|
||||
- [ ] Any evidence of data exfiltration: ☐ Yes ☐ No ☐ Unknown
|
||||
|
||||
## Evidence Collection
|
||||
|
||||
- [ ] Preserve relevant Zeek logs (copy, do not modify originals)
|
||||
- [ ] Capture full PCAPs for key timeframes if available
|
||||
- [ ] Export timeline from `scripts/process.py` output
|
||||
- [ ] Screenshot/export SIEM correlation results
|
||||
- [ ] Document chain of custody
|
||||
|
||||
## Containment Actions
|
||||
|
||||
- [ ] Isolate confirmed compromised hosts from network
|
||||
- [ ] Disable compromised user accounts
|
||||
- [ ] Block lateral movement paths (firewall rules)
|
||||
- [ ] If DCSync detected: initiate credential rotation
|
||||
- [ ] If PtH detected: force password reset for affected accounts
|
||||
- [ ] Restrict RDP access to authorized admin workstations only
|
||||
|
||||
## Post-Incident
|
||||
|
||||
- [ ] Update Zeek detection thresholds based on findings
|
||||
- [ ] Add legitimate admin share usage to allowlists
|
||||
- [ ] Document lessons learned
|
||||
- [ ] Update incident response playbook
|
||||
- [ ] Schedule follow-up threat hunt in 30 days
|
||||
- [ ] Brief stakeholders on findings and remediation
|
||||
|
||||
## Notes
|
||||
|
||||
_Use this space for free-form investigation notes, timeline reconstruction, and analyst observations._
|
||||
|
||||
---
|
||||
|
||||
**Template version:** 1.0
|
||||
**Last updated:** 2025-03-17
|
||||
**MITRE ATT&CK references:** TA0008, T1021.001, T1021.002, T1550.002, T1570, T1003.006
|
||||
@@ -0,0 +1,285 @@
|
||||
---
|
||||
name: implementing-cloud-security-posture-management
|
||||
description: >
|
||||
Implementing Cloud Security Posture Management (CSPM) to continuously monitor multi-cloud
|
||||
environments for misconfigurations, compliance violations, and security risks using Prowler,
|
||||
ScoutSuite, AWS Security Hub, Azure Defender, and GCP Security Command Center.
|
||||
domain: cybersecurity
|
||||
subdomain: cloud-security
|
||||
tags: [cloud-security, cspm, multi-cloud, compliance, prowler, scoutsuite]
|
||||
version: "1.0"
|
||||
author: mahipal
|
||||
license: Apache-2.0
|
||||
language: es
|
||||
---
|
||||
|
||||
# Implementación de Gestión de Postura de Seguridad en la Nube (CSPM)
|
||||
|
||||
## Cuándo Utilizar
|
||||
|
||||
- Al establecer monitoreo continuo de seguridad en entornos AWS, Azure y GCP
|
||||
- Cuando los requisitos de cumplimiento demandan evaluación automatizada de postura contra CIS, SOC 2 o PCI DSS
|
||||
- Cuando los equipos de seguridad necesitan visibilidad de las configuraciones incorrectas en la nube en múltiples cuentas y suscripciones
|
||||
- Al construir un flujo de trabajo de operaciones de seguridad que detecte y remedie desviaciones de las líneas base de seguridad
|
||||
- Al migrar cargas de trabajo a la nube y se necesita aplicar controles de seguridad
|
||||
|
||||
**No utilizar** para protección de cargas de trabajo en tiempo de ejecución (use herramientas CWPP como Falco o Aqua), para pruebas de seguridad de aplicaciones (use herramientas DAST/SAST), ni para detección de intrusiones en red (use IDS nativos de la nube como GuardDuty o Network Watcher).
|
||||
|
||||
## Requisitos Previos
|
||||
|
||||
- Credenciales multi-nube con permisos de auditoría de seguridad de solo lectura en todos los entornos objetivo
|
||||
- Prowler v3+ instalado (`pip install prowler`)
|
||||
- ScoutSuite instalado (`pip install scoutsuite`)
|
||||
- AWS Config, Azure Policy y GCP Organization Policy habilitados en los respectivos entornos
|
||||
- Destino central de registros (bucket S3, Log Analytics Workspace o Cloud Storage) para agregación de hallazgos
|
||||
- Canales de notificación configurados (Slack, PagerDuty, correo electrónico) para alertas de hallazgos críticos
|
||||
|
||||
## Flujo de Trabajo
|
||||
|
||||
### Paso 1: Desplegar Servicios CSPM Nativos de la Nube
|
||||
|
||||
Habilitar las capacidades CSPM integradas en cada proveedor de nube para la evaluación de postura de referencia.
|
||||
|
||||
```bash
|
||||
# AWS: Habilitar Security Hub con estándares FSBP y CIS
|
||||
aws securityhub enable-security-hub --enable-default-standards
|
||||
aws securityhub batch-enable-standards --standards-subscription-requests \
|
||||
'[{"StandardsArn":"arn:aws:securityhub:::standards/cis-aws-foundations-benchmark/v/1.4.0"}]'
|
||||
|
||||
# Azure: Habilitar Microsoft Defender for Cloud (nivel CSPM)
|
||||
az security pricing create --name CloudPosture --tier standard
|
||||
az security auto-provisioning-setting update --name default --auto-provision on
|
||||
|
||||
# GCP: Habilitar Security Command Center Premium
|
||||
gcloud services enable securitycenter.googleapis.com
|
||||
gcloud scc settings update --organization=ORG_ID \
|
||||
--enable-asset-discovery
|
||||
```
|
||||
|
||||
### Paso 2: Ejecutar Prowler para Evaluación Multi-Nube
|
||||
|
||||
Ejecutar Prowler para realizar verificaciones de seguridad exhaustivas en los tres proveedores de nube.
|
||||
|
||||
```bash
|
||||
# Evaluación de AWS con todas las verificaciones CIS
|
||||
prowler aws \
|
||||
--profile production \
|
||||
-M json-ocsf csv html \
|
||||
-o ./prowler-results/aws/ \
|
||||
--compliance cis_1.4_aws cis_1.5_aws
|
||||
|
||||
# Evaluación de Azure
|
||||
prowler azure \
|
||||
--subscription-ids SUB_ID_1 SUB_ID_2 \
|
||||
-M json-ocsf csv html \
|
||||
-o ./prowler-results/azure/ \
|
||||
--compliance cis_2.0_azure
|
||||
|
||||
# Evaluación de GCP
|
||||
prowler gcp \
|
||||
--project-ids project-1 project-2 \
|
||||
-M json-ocsf csv html \
|
||||
-o ./prowler-results/gcp/ \
|
||||
--compliance cis_2.0_gcp
|
||||
|
||||
# Ver resumen en todos los proveedores
|
||||
prowler aws --list-compliance
|
||||
```
|
||||
|
||||
### Paso 3: Ejecutar ScoutSuite para Comparación Cross-Cloud
|
||||
|
||||
Usar ScoutSuite para una evaluación de seguridad multi-nube unificada con informes visuales.
|
||||
|
||||
```bash
|
||||
# Escanear AWS
|
||||
python3 -m ScoutSuite aws --profile production \
|
||||
--report-dir ./scoutsuite/aws/
|
||||
|
||||
# Escanear Azure
|
||||
python3 -m ScoutSuite azure --cli \
|
||||
--all-subscriptions \
|
||||
--report-dir ./scoutsuite/azure/
|
||||
|
||||
# Escanear GCP
|
||||
python3 -m ScoutSuite gcp --user-account \
|
||||
--all-projects \
|
||||
--report-dir ./scoutsuite/gcp/
|
||||
|
||||
# Cada uno produce un informe HTML con hallazgos puntuados por riesgo
|
||||
```
|
||||
|
||||
### Paso 4: Construir Pipeline Automatizado de Monitoreo de Cumplimiento
|
||||
|
||||
Crear un pipeline programado que ejecute verificaciones CSPM diariamente y enrute los hallazgos a los canales apropiados.
|
||||
|
||||
```bash
|
||||
# Crear escaneo diario de Prowler con EventBridge + CodeBuild (AWS)
|
||||
cat > buildspec.yml << 'EOF'
|
||||
version: 0.2
|
||||
phases:
|
||||
install:
|
||||
commands:
|
||||
- pip install prowler
|
||||
build:
|
||||
commands:
|
||||
- prowler aws -M json-ocsf -o s3://security-findings-bucket/prowler/$(date +%Y%m%d)/
|
||||
- prowler aws --compliance cis_1.5_aws -M csv -o s3://security-findings-bucket/prowler/compliance/
|
||||
post_build:
|
||||
commands:
|
||||
- |
|
||||
CRITICAL=$(cat output/*.json | grep -c '"CRITICAL"')
|
||||
if [ "$CRITICAL" -gt 0 ]; then
|
||||
aws sns publish --topic-arn arn:aws:sns:us-east-1:ACCOUNT:security-alerts \
|
||||
--subject "Prowler: $CRITICAL hallazgos críticos" \
|
||||
--message "Revisar en s3://security-findings-bucket/prowler/$(date +%Y%m%d)/"
|
||||
fi
|
||||
EOF
|
||||
|
||||
# Programar con EventBridge
|
||||
aws events put-rule \
|
||||
--name daily-prowler-scan \
|
||||
--schedule-expression "cron(0 6 * * ? *)" \
|
||||
--state ENABLED
|
||||
```
|
||||
|
||||
### Paso 5: Configurar Agregación y Deduplicación de Hallazgos
|
||||
|
||||
Agregar hallazgos de múltiples herramientas CSPM y proveedores de nube en una vista unificada.
|
||||
|
||||
```python
|
||||
# findings_aggregator.py - Normalizar y deduplicar hallazgos CSPM
|
||||
import json
|
||||
import hashlib
|
||||
from datetime import datetime
|
||||
|
||||
def normalize_finding(finding, source):
|
||||
"""Normalizar hallazgos de diferentes herramientas CSPM a un formato común."""
|
||||
normalized = {
|
||||
'id': hashlib.sha256(f"{finding.get('ResourceId','')}{finding.get('CheckId','')}".encode()).hexdigest()[:16],
|
||||
'source': source,
|
||||
'cloud': finding.get('Provider', 'unknown'),
|
||||
'account': finding.get('AccountId', finding.get('SubscriptionId', '')),
|
||||
'region': finding.get('Region', ''),
|
||||
'resource_type': finding.get('ResourceType', ''),
|
||||
'resource_id': finding.get('ResourceId', ''),
|
||||
'severity': finding.get('Severity', 'INFO').upper(),
|
||||
'status': finding.get('Status', 'FAIL'),
|
||||
'title': finding.get('CheckTitle', finding.get('Title', '')),
|
||||
'description': finding.get('StatusExtended', ''),
|
||||
'compliance': finding.get('Compliance', {}),
|
||||
'remediation': finding.get('Remediation', {}).get('Recommendation', {}).get('Text', ''),
|
||||
'timestamp': datetime.utcnow().isoformat()
|
||||
}
|
||||
return normalized
|
||||
|
||||
def aggregate_findings(prowler_file, scoutsuite_file):
|
||||
findings = {}
|
||||
for file_path, source in [(prowler_file, 'prowler'), (scoutsuite_file, 'scoutsuite')]:
|
||||
with open(file_path) as f:
|
||||
for line in f:
|
||||
raw = json.loads(line)
|
||||
normalized = normalize_finding(raw, source)
|
||||
if normalized['status'] == 'FAIL':
|
||||
findings[normalized['id']] = normalized
|
||||
return sorted(findings.values(), key=lambda x: {'CRITICAL':0,'HIGH':1,'MEDIUM':2,'LOW':3}.get(x['severity'],4))
|
||||
```
|
||||
|
||||
### Paso 6: Implementar Detección de Desviaciones y Auto-Remediación
|
||||
|
||||
Configurar respuestas automatizadas ante desviaciones de configuración que violen las líneas base de seguridad.
|
||||
|
||||
```bash
|
||||
# Auto-remediación de AWS Config para buckets S3 no conformes
|
||||
aws configservice put-remediation-configurations --remediation-configurations '[{
|
||||
"ConfigRuleName": "s3-bucket-public-read-prohibited",
|
||||
"TargetType": "SSM_DOCUMENT",
|
||||
"TargetId": "AWS-DisableS3BucketPublicReadWrite",
|
||||
"Parameters": {
|
||||
"S3BucketName": {"ResourceValue": {"Value": "RESOURCE_ID"}}
|
||||
},
|
||||
"Automatic": true,
|
||||
"MaximumAutomaticAttempts": 3,
|
||||
"RetryAttemptSeconds": 60
|
||||
}]'
|
||||
|
||||
# Azure Policy para auto-remediación
|
||||
az policy assignment create \
|
||||
--name "enforce-storage-encryption" \
|
||||
--policy "/providers/Microsoft.Authorization/policyDefinitions/404c3081-a854-4457-ae30-26a93ef643f9" \
|
||||
--scope "/subscriptions/SUB_ID" \
|
||||
--enforcement-mode Default
|
||||
|
||||
# Restricción de GCP Organization Policy
|
||||
gcloud resource-manager org-policies set-policy policy.yaml --organization=ORG_ID
|
||||
# policy.yaml: constraint: constraints/storage.publicAccessPrevention, enforcement: true
|
||||
```
|
||||
|
||||
## Conceptos Clave
|
||||
|
||||
| Término | Definición |
|
||||
|---------|------------|
|
||||
| CSPM | Gestión de Postura de Seguridad en la Nube, la práctica de monitorear continuamente la infraestructura cloud en busca de configuraciones incorrectas y violaciones de cumplimiento |
|
||||
| Desviación de Configuración | Cambios no intencionados en las configuraciones de recursos cloud que se desvían de la línea base de seguridad aprobada con el tiempo |
|
||||
| Línea Base de Seguridad | Un conjunto documentado de requisitos mínimos de configuración de seguridad que todos los recursos cloud deben cumplir |
|
||||
| Marco de Cumplimiento | Un conjunto estructurado de controles y requisitos de seguridad (CIS, SOC 2, PCI DSS, NIST) contra los cuales se evalúan las configuraciones cloud |
|
||||
| Severidad del Hallazgo | Clasificación de riesgo de una configuración incorrecta basada en la explotabilidad y el impacto potencial (Crítico, Alto, Medio, Bajo, Informativo) |
|
||||
| Auto-Remediación | Acción correctiva automatizada que restaura un recurso no conforme a su configuración requerida sin intervención manual |
|
||||
|
||||
## Herramientas y Sistemas
|
||||
|
||||
- **Prowler**: Herramienta de evaluación de seguridad multi-nube de código abierto con más de 300 verificaciones alineadas a CIS, PCI DSS, HIPAA y NIST
|
||||
- **ScoutSuite**: Herramienta de auditoría de seguridad multi-nube que produce informes HTML puntuados por riesgo a partir de datos de configuración recopilados por API
|
||||
- **AWS Security Hub**: CSPM nativo de AWS con hallazgos agregados y evaluación de estándares de cumplimiento
|
||||
- **Microsoft Defender for Cloud**: CSPM nativo de Azure con puntuación de seguridad, cumplimiento regulatorio y protección de cargas de trabajo
|
||||
- **GCP Security Command Center**: Plataforma de seguridad nativa de GCP con inventario de activos, escaneo de vulnerabilidades y monitoreo de cumplimiento
|
||||
|
||||
## Escenarios Comunes
|
||||
|
||||
### Escenario: Establecer CSPM para una Empresa Multi-Nube
|
||||
|
||||
**Contexto**: Una empresa ejecuta cargas de trabajo de producción en AWS (principal), Azure (identidad y servicios Microsoft) y GCP (analítica de datos). El equipo de seguridad necesita visibilidad unificada de la postura.
|
||||
|
||||
**Enfoque**:
|
||||
1. Habilitar CSPM nativo de la nube en cada proveedor: Security Hub, Defender for Cloud, SCC
|
||||
2. Desplegar escaneos de Prowler como trabajos programados diariamente en cada entorno mediante pipelines CI/CD
|
||||
3. Normalizar y agregar hallazgos en un data lake central usando el script de agregación
|
||||
4. Construir dashboards en Grafana o Kibana mostrando puntuaciones de postura por nube, cuenta y severidad
|
||||
5. Configurar auto-remediación para correcciones conocidas (bloqueos de acceso público, habilitación de cifrado)
|
||||
6. Enrutar hallazgos CRÍTICOS a PagerDuty para respuesta inmediata y hallazgos ALTOS a tickets de Jira
|
||||
7. Producir informes semanales de cumplimiento para los ejecutivos mostrando datos de tendencias
|
||||
|
||||
**Errores comunes**: Ejecutar herramientas CSPM con permisos excesivamente amplios crea un objetivo de alto valor. Use cuentas de servicio dedicadas con permisos de solo lectura y rote las credenciales regularmente. Diferentes herramientas CSPM pueden reportar la misma configuración incorrecta de manera diferente, por lo que la lógica de deduplicación debe tener en cuenta los formatos variables de ID de recurso y títulos de hallazgos entre herramientas.
|
||||
|
||||
## Formato de Salida
|
||||
|
||||
```text
|
||||
Dashboard de Gestión de Postura de Seguridad en la Nube
|
||||
========================================================
|
||||
Organización: Acme Corp
|
||||
Fecha de Evaluación: 2026-02-23
|
||||
Entornos: AWS (12 cuentas), Azure (8 suscripciones), GCP (5 proyectos)
|
||||
|
||||
PUNTUACIONES DE POSTURA:
|
||||
AWS: 82/100 (+3 desde la semana pasada)
|
||||
Azure: 76/100 (-1 desde la semana pasada)
|
||||
GCP: 79/100 (+5 desde la semana pasada)
|
||||
General: 79/100
|
||||
|
||||
HALLAZGOS POR SEVERIDAD:
|
||||
Crítico: 18 (AWS: 7, Azure: 8, GCP: 3)
|
||||
Alto: 67 (AWS: 28, Azure: 24, GCP: 15)
|
||||
Medio: 234 (AWS: 98, Azure: 87, GCP: 49)
|
||||
Bajo: 412 (AWS: 178, Azure: 134, GCP: 100)
|
||||
|
||||
PRINCIPALES CATEGORÍAS CON FALLOS:
|
||||
1. Políticas IAM excesivamente permisivas (43 hallazgos)
|
||||
2. Cifrado en reposo no habilitado (38 hallazgos)
|
||||
3. Exposición de red pública (29 hallazgos)
|
||||
4. Brechas en registro y monitoreo (24 hallazgos)
|
||||
5. Credenciales y claves sin uso (19 hallazgos)
|
||||
|
||||
AUTO-REMEDIACIÓN (Últimos 7 Días):
|
||||
Hallazgos auto-remediados: 34
|
||||
Remediación manual pendiente: 51
|
||||
Excepciones aprobadas: 8
|
||||
```
|
||||
@@ -8,7 +8,7 @@ description: >
|
||||
false positives through rule tuning and logging analysis.
|
||||
domain: cybersecurity
|
||||
subdomain: cloud-security
|
||||
tags: [cloud-waf, aws-waf, azure-waf, owasp-protection, rate-limiting]
|
||||
tags: [cloud-waf, aws-waf, azure-waf, cloudflare-waf, owasp-protection, rate-limiting]
|
||||
version: 1.0.0
|
||||
author: mahipal
|
||||
license: Apache-2.0
|
||||
@@ -265,7 +265,7 @@ After 7-14 days of Count mode with acceptable false positive rates, switch manag
|
||||
|
||||
## Output Format
|
||||
|
||||
```
|
||||
```text
|
||||
Cloud WAF Configuration Report
|
||||
================================
|
||||
Web ACL: production-waf
|
||||
|
||||
@@ -0,0 +1,36 @@
|
||||
---
|
||||
name: implementing-rbac-for-kubernetes-cluster
|
||||
description: Implement RBAC in Kubernetes with least-privilege roles, service accounts, and audit policies.
|
||||
domain: cybersecurity
|
||||
subdomain: container-security
|
||||
tags: [kubernetes, rbac, access-control, container-security, least-privilege]
|
||||
version: "1.0"
|
||||
author: mahipal
|
||||
license: Apache-2.0
|
||||
language: es
|
||||
---
|
||||
|
||||
# Implementación de RBAC en Kubernetes
|
||||
|
||||
## Descripción General
|
||||
|
||||
El Control de Acceso Basado en Roles (RBAC) en Kubernetes permite definir permisos granulares para usuarios, grupos y cuentas de servicio, implementando políticas de mínimo privilegio.
|
||||
|
||||
## Prerrequisitos
|
||||
|
||||
- Clúster Kubernetes 1.26+ con RBAC habilitado
|
||||
- kubectl con permisos de administrador
|
||||
- Herramientas: `kubectl auth can-i`, `rakkess`
|
||||
|
||||
## Pasos
|
||||
|
||||
1. Auditar permisos existentes con `kubectl get clusterrolebindings`
|
||||
2. Identificar cuentas con permisos excesivos
|
||||
3. Crear Roles con mínimo privilegio por carga de trabajo
|
||||
4. Configurar RoleBindings apropiados
|
||||
5. Implementar auditoría de accesos
|
||||
6. Validar con `kubectl auth can-i --list`
|
||||
|
||||
## Resultado Esperado
|
||||
|
||||
Clúster con RBAC de mínimo privilegio, ServiceAccounts seguros y auditoría activa.
|
||||
@@ -0,0 +1,49 @@
|
||||
---
|
||||
name: performing-memory-forensics-with-volatility3
|
||||
description: Analyze memory dumps to extract processes, network connections, and malware artifacts using Volatility3.
|
||||
domain: cybersecurity
|
||||
subdomain: digital-forensics
|
||||
tags: [forensics, memory-analysis, volatility3, incident-response]
|
||||
version: "1.0"
|
||||
author: mahipal
|
||||
license: Apache-2.0
|
||||
language: es
|
||||
---
|
||||
|
||||
# Análisis Forense de Memoria con Volatility3
|
||||
|
||||
## Descripción General
|
||||
|
||||
Volatility3 es el framework líder de código abierto para análisis forense de memoria. Permite extraer procesos en ejecución, conexiones de red, módulos cargados, artefactos de malware, credenciales en memoria, y evidencia de actividad maliciosa desde volcados de memoria RAM de sistemas Windows, Linux y macOS.
|
||||
|
||||
## Prerrequisitos
|
||||
|
||||
- Python 3.8+ con Volatility3 instalado (`pip install volatility3`)
|
||||
- Volcado de memoria adquirido (formatos: raw, EWF, LiME, VMware .vmem)
|
||||
- Tablas de símbolos apropiadas para el SO analizado
|
||||
- Espacio en disco suficiente (2-3x el tamaño del volcado de memoria)
|
||||
|
||||
## Conceptos Clave
|
||||
|
||||
| Concepto | Descripción |
|
||||
|----------|-------------|
|
||||
| **Plugin PsList** | Lista procesos activos con PID, PPID, tiempo de creación |
|
||||
| **Plugin NetScan** | Extrae conexiones de red y puertos en escucha |
|
||||
| **Plugin MalFind** | Detecta inyección de código en procesos (secciones PAGE_EXECUTE_READWRITE) |
|
||||
| **Plugin DllList** | Lista DLLs cargadas por cada proceso |
|
||||
| **Plugin Handles** | Muestra handles abiertos (archivos, registros, mutex) |
|
||||
| **Plugin CmdLine** | Extrae líneas de comando de procesos |
|
||||
|
||||
## Pasos
|
||||
|
||||
1. Identificar el perfil del SO del volcado de memoria
|
||||
2. Ejecutar `vol -f memory.dmp windows.pslist` para listar procesos
|
||||
3. Analizar procesos sospechosos con `windows.pstree` para ver jerarquía
|
||||
4. Buscar conexiones de red con `windows.netscan`
|
||||
5. Detectar inyección de código con `windows.malfind`
|
||||
6. Extraer artefactos específicos (DLLs, handles, líneas de comando)
|
||||
7. Correlacionar hallazgos para construir timeline del ataque
|
||||
|
||||
## Resultado Esperado
|
||||
|
||||
Reporte detallado de hallazgos forenses incluyendo procesos maliciosos identificados, conexiones C2, artefactos de malware extraídos, y timeline de actividad del atacante en el sistema comprometido.
|
||||
@@ -0,0 +1,38 @@
|
||||
---
|
||||
name: performing-osint-with-spiderfoot
|
||||
description: Automate OSINT collection using SpiderFoot REST API and CLI for target profiling, module-based reconnaissance, and structured result analysis across 200+ data sources
|
||||
domain: cybersecurity
|
||||
subdomain: threat-intelligence
|
||||
tags: [osint, spiderfoot, reconnaissance, threat-intelligence, attack-surface, target-profiling]
|
||||
version: "1.0"
|
||||
author: mahipal
|
||||
license: Apache-2.0
|
||||
language: es
|
||||
---
|
||||
|
||||
# Recolección de OSINT con SpiderFoot
|
||||
|
||||
## Descripción General
|
||||
|
||||
SpiderFoot es una herramienta de automatización OSINT de código abierto con más de 200 módulos que se integra con fuentes de datos para inteligencia de amenazas y mapeo de superficie de ataque. Esta skill utiliza la API REST de SpiderFoot y la CLI (sf.py/spiderfoot-cli) para crear y gestionar escaneos, seleccionar módulos por caso de uso (footprint, investigate, passive), analizar resultados estructurados para dominios, IPs, direcciones de correo, credenciales filtradas y registros DNS, y generar perfiles de inteligencia del objetivo.
|
||||
|
||||
## Prerrequisitos
|
||||
|
||||
- SpiderFoot 4.0+ instalado o cuenta SpiderFoot HX en la nube
|
||||
- Python 3.8+ con la librería requests
|
||||
- Servidor SpiderFoot ejecutándose en el puerto predeterminado 5001
|
||||
- Opcional: Claves API para módulos de VirusTotal, Shodan, HaveIBeenPwned
|
||||
|
||||
## Pasos
|
||||
|
||||
1. Conectar a la API REST de SpiderFoot o utilizar la interfaz CLI
|
||||
2. Crear un nuevo escaneo con especificación del objetivo (dominio, IP, correo, nombre)
|
||||
3. Seleccionar módulos de escaneo por caso de uso (all, footprint, investigate, passive)
|
||||
4. Monitorear el progreso del escaneo mediante polling de la API
|
||||
5. Recuperar y analizar resultados del escaneo por tipo de elemento de datos
|
||||
6. Extraer hallazgos clave: subdominios, IPs, correos, credenciales filtradas
|
||||
7. Generar reporte estructurado de inteligencia OSINT
|
||||
|
||||
## Resultado Esperado
|
||||
|
||||
Reporte JSON que contiene hallazgos OSINT organizados por tipo de dato (dominios, IPs, correos, credenciales, registros DNS), atribución de módulo fuente, y resumen del perfil del objetivo con indicadores de riesgo.
|
||||
Reference in New Issue
Block a user