A suplantación de identidad La queja es una pista, no un hallazgo técnico completo. Es posible que el periodista haya visto un nombre para mostrar engañoso, una dirección similar, un mensaje reenviado o una cuenta legítima comprometida. Responda preservando lo que observaron, identificando evidencia faltante y protegiendo cualquier acción comercial afectada. No cambie la política de dominio simplemente porque una captura de pantalla contenga el nombre de la empresa.
Reúna el conjunto de pruebas útiles más pequeño
Solicite el mensaje original utilizando un canal seguro aprobado cuando sea posible, junto con la hora aproximada de recepción, buzón afectado y descripción de la acción solicitada. Preservar el original antes de la redacción. Registrar quién lo suministró, cuándo fue adquirido y si provino directamente del receptor o a través de un intermediario. Un cuerpo reenviado puede omitir encabezados que sean esenciales para la investigación.
Mantenga la evidencia original bajo un control de acceso adecuado. Cree una copia para compartir separada que elimine detalles innecesarios del destinatario, contenido personal o archivos adjuntos no relacionados y al mismo tiempo conserve los campos de identidad relevantes. Haga un hash en ambos archivos y documente las redacciones para que un revisor pueda entender por qué sus bytes difieren. Los hashes se unen un récord a bytes; no prueban que el contenido sea auténtico ni que el remitente haya sido identificado correctamente.
Identificar la evidencia de autenticación confiable
Encuentre el sistema que evaluó el mensaje al recibirlo. Un Authentication-Results El campo es significativo sólo dentro de su límite de confianza establecido, como explica RFC 8601 . Resultados de autenticación. Un encabezado generado o que no es de confianza no debe promocionarse como observación del receptor simplemente porque utiliza un formato válido.
Comparar desde, sobre y DKIM identidades sin confundir una firma aprobada con la aprobación comercial. DMARC aborda la autenticación de dominio alineada en lugar de todas las formas de suplantación. RFC 9989. Si el mensaje original o los registros confiables no están disponibles, mantenga el resultado sin resolver y describa qué evidencia adicional lo cambiaría.
Construya un libro mayor de incidentes hipotéticos
Para el caso de enseñanza DEMO-COMPLAINT-01, supongamos que un reclamante informa una solicitud de cambio de pago con información visible de billing@brand-pay.test . No se proporcionan bytes de mensajes reales, marcas de tiempo del receptor, resultados de autenticación confiables ni detalles del cliente. Registre el hash original como no disponible, no como un resumen inventado. La clasificación sigue siendo provisional hasta que se obtengan las pruebas pertinentes.
Asigne las siguientes acciones propuestas por separado: las operaciones de correo obtienen la exportación original aprobada y el contexto de recepción confiable; finanzas verifica la solicitud a través de un canal conocido; el líder del incidente autoriza cualquier intercambio o contención necesario. Estos son roles ilustrativos, no personas reales que aceptaron asignaciones.
Para una copia real para compartir posteriormente, registre la referencia original, cada campo redactado, propósito, destinatario, aprobación y hash del archivo resultante. Mantenga el original inmutable. Un hash modificado puede identificar bytes modificados, pero no puede establecer quién fue el autor del mensaje o una cadena de custodia que nunca se registró. Para este ejemplo escrito no se realizó ningún archivo original, muestra redactada, cálculo hash o acción de incidente externo.
Responder con un hallazgo acotado
Un acuse de recibo útil indica lo que se ha recibido, lo que se desconoce y quién está investigando. Evite acusar a un proveedor o prometer que el problema se solucionará antes de que las pruebas de identidad y ruta respalden esa conclusión. Si el dinero o las credenciales pueden estar en riesgo, siga el proceso de incidentes de la organización de inmediato mientras continúa la recopilación de pruebas. El FBI recomienda una verificación independiente de las solicitudes de pago y cambios de cuenta. orientación del FBI.
Asigne a cada elemento faltante un propietario y una siguiente acción. El equipo de correo puede recuperar los registros del receptor, el equipo comercial puede verificar la solicitud y el líder de seguridad puede coordinar la contención. Mantenga el intercambio externo dentro del alcance aprobado, especialmente cuando el original contenga información confidencial.
Cierra sólo las conclusiones respaldadas por evidencia. Una solicitud similar confirmada puede clasificarse mientras la atribución del proveedor siga sin resolverse. Una ruta de envío legítima reparada puede cerrar el defecto de autenticación sin resolver el daño comercial. Conserve esas distinciones en el paquete final del incidente para que el próximo revisor no confunda un hallazgo parcial con una resolución completa.
Mantenga los hallazgos dentro de la evidencia
Los ejemplos son ayudas para la toma de decisiones defensivas, no acusaciones observadas contra personas reales o proveedores actuales. Conserve la evidencia de autenticación, la verificación comercial y la atribución por separado. Las fuentes de protocolos actuales describen la validación del dominio y los límites de resultados confiables; no proporcionan la evidencia de la cuenta faltante ni autorizan la publicación de una acusación.