Al final de este tutorial , el autor ofrece algunas ideas para mejorar una Ataque de phishing básico.
Uno de ellos me intrigó, en particular: ¿Es posible usar las credenciales que una víctima ingresa en su página de phishing y usar, digamos API de Facebook o Twitter (o la que sea) y enviar esas credenciales al servicio real, por lo tanto, crear ¿Una sesión genuina para que la víctima nunca se haya dado cuenta de que han sido engañados?
Sí, es posible que un sitio de phishing actúe como un proxy entre el usuario y el sitio web esperado y, por lo tanto, registre / inyecte datos. Sin embargo, requeriría algo más sofisticado que solo SSLstrip en el sitio de phishing.
La URL en el navegador haría referencia al sitio de phishing durante la sesión.
Creo que todo depende de cómo las API sean realmente gestionadas por las credenciales. Realmente no sé cómo Facebook o Twitter manejan estas informaciones. Si la autenticación solo se realiza con el nombre de usuario y la contraseña, entonces ... creo que es posible.
Pero si se usan el nombre de usuario y la contraseña, además de una tercera credencial que solo está disponible en la computadora de la víctima y no se detecta en su página de phishing ... puede que no funcione.
Si su pregunta está relacionada principalmente con la afirmación de que la víctima nunca se dio cuenta de que fue engañada, creo que sería muy difícil, si no impracticable.
Por lo que sé, esta es la razón por la que usamos tokens csrf ( Cross-site request forgery ).
Teóricamente, cualquier cosa puede enviar datos POST a una URL que acepte datos POST ...
Supongamos que dodgysite.com/login maneja una solicitud POST para iniciar sesión. Todo lo que este sitio acepta es nombre de usuario / contraseña. Cualquier secuencia de comandos debe poder enviar una solicitud, incluido su sitio de phishing.
Mientras que securesite.com/login también puede manejar un token csrf único, que no aceptaría la solicitud si el token no coincide. Dado que este token se genera aleatoriamente cada vez que se carga el formulario de inicio de sesión, sería imposible que un actor malintencionado envíe datos POST válidos de otra parte.
Además de revisar cada solicitud de un token csrf válido, securesite.com/login también debe verificar que la solicitud proviene del mismo origen (es decir, el formulario de inicio de sesión legítimo en el sitio web).
Si estos dos requisitos no se cumplen, entonces sí, podría interactuar con el formulario de inicio de sesión desde una aplicación maliciosa.
Lea otras preguntas en las etiquetas phishing social-engineering