Phishing: Pushing Evilginx to its limit

Jean Marsault — Thu, 17 Jul 2025 15:03:33 +0000

Phishing attacks are as old as the Internet. However, over the years, the techniques and means for the phishing changes but the final goal is the same: getting an initial access to the internal network.

Usually, threat actors try to send malicious documents such as HTA applications or malicious Office documents but, with the growth of SMTP security solutions such as ProofPoint, the default Office hardening related to macros and the rise of awareness about phishing, these types of techniques are less and less used.

Today, threat actors do not perform phishing to get a direct initial access to the company network, but to retrieve the digital identity of a user: its Office365/GoogleWorkspace/Okta identity. They then reuse this identity through SSO applications until they find a way to breach the internal network through exposed applications such as Citrix or VPN.

To limit such attacks, companies started enforcing MFA to ensure that even if a threat actor successfully retrieves a valid set of user credentials through phishing or harvesting, he won’t be able to complete the authentication process or reuse them on a different application.

Phishing 101

IDP, cookies and phishing

The MFA protection implemented by companies is a good way to limit the impact of successful phishing. Indeed, even if the threat actor retrieves the user credentials, he won’t be able to spoof the user’s identity as he won’t be able to validate the MFA.

However, today the MFA is usually only asked during the first authentication: once the user is authenticated on the identity provider, it gives him a proof of authentication the user can forward to any service. With this proof of authentication, the user does not need any additional active authentication, therefore not needing to re-validate the MFA as long as the ticket is valid.

In the most common web IDPs such as Azure, Google or Okta, this ticket is represented by the cookies. When the user connects to the IDP for the first time, the service sends back a cookie that is valid for 1 hour, 1 day or 2 years. With these cookies, the user can connect to any other SSO-compliant web service without authentication.

Cookie as session

In a nutshell, the user IDP cookies represent the user digital identity. Therefore, in a phishing attack whose primary goal is to spoof the user digital identity, the attacker will try to steal the cookies once the user has successfully performed his authentication.

Evilginx

Evil proxy

In order to steal the cookies, the attacker must be placed in a man-in-the-middle position during the authentication process. However, with TLS security enforced in the majority of IDP, the user will be aware that something wrong is happening.

That’s where Evilginx comes into play. Instead of performing a simple man-in-the-middle attack by relaying the packet to the IDP, Evilginx will create a malicious proxy: the user does not authenticate on accounts.google.com, but he will authenticate to login.evilginx.com:

Evilgproxy functionning

I will not take more time to develop the evil-proxy principle as it is already well documented on the internet.

Phislets 101

For example, during the authentication to Azure, the following domains are used:

login.microsoftonline.com
www.microsoftonline.com
aadcdn.microsoftonline.com

The problem is that during the authentication flow, the IDP will redirect the user to specific pages with the domain hardcoded in the response. For example, during a classic SAML authentication flow, the IDP will force the client to perform a POST request to a specific hardcoded domain. Therefore, even if the user started its authentication process on login.evilginx.com, during the authentication flow he will be redirected to login.microsoftonline.com breaking the man-in-the-middle position.

Evilginx uses specific configuration files known as phishlets to handle such cases. The phishlet configuration will allow Evilginx to know what domain must be re-written in the server response. So if the IDP sends back a response such as:


[…]

With the phishlet, Evilginx will know that the domain login.microsoftonline.com must be rewritten and will send back to the target the following modified page:


[…]

With such match and replace pattern, Evilginx is able to trap the user inside the malicious application even if the IDP tries to redirect the user to a specific page.

Auto-replace limits

The Evilginx phishlet auto-replace has its limits. Indeed, sometime the server does not directly hardcode the domain in the page but builds it through a JS script.

In this case, Evilginx is not able to automatically detect the domain pattern. As phishlet designers, we need then to understand how the script is working and manually replace the part building the redirection domain through a match/replace.

CORS

In Okta, authentication flow is based on several JS scripts fetched from the oktadcn domain. The script dynamically builds the redirection URL: it takes the Okta tenant name and appends ‘okta.com’. Therefore, when Okta tries to reach the specific page using the okta.com domain, it fails due to CORS protection (trying to reach okta.com/idp/idx/introspect from evilginx.com):

Okta CORS

By debugging the application, it is possible to find where the URL building is done and modify it through a match and replace:

Replace: array");var t=
By: array");e.redirectUri=e.redirectUri.replace("okta.com","evilginx.com");var t=

With this simple indication, Evilginx will apply the match and replace on-the-fly, avoiding the redirection of the user outside of the phishing application.

JS integrity

When modifying the JS file or any other file through Evilginx, it can cause troubles due to the script integrity hash:

 LANGUAGE=“JavaScript”>

hp_d01(unescape(“%3E%23//JGCF[..snip..]%23//-JGCF//%3C”));//–>





Il est en général possible de rencontrer deux types d’obfuscation JavaScript :

La première construit un code qui sera désobfusqué et exécuté grâce à la fonction eval()
La seconde construit un code qui sera désobfusqué et exécuté en l’ajoutant dynamiquement dans le code de la page, par exemple via document.write()

Ce challenge utilise la seconde méthode, et le code final peut donc être récupéré en utilisant l’inspecteur HTML de Chrome / Firefox / Opera :

Le code complet de la fonction JavaScript est le suivant :

 language=“JavaScript”>

function Kod(s, pass) {

var i=0;

var BlaBla=“”;

for(j=0; j<s.length; j++) {

BlaBla += String.fromCharCode((pass.charCodeAt(i++))^(s.charCodeAt(j)));

if (i>=pass.length)

i=0;

}

return(BlaBla);

}

function f(form){

var pass=document.form.pass.value;

var hash=0;

for(j=0; j<pass.length; j++){

var n= pass.charCodeAt(j);

hash += ((n–j+33)^31025);

}

if (hash == 529387) {

var Secret =“”+“\x4f\x01\x13\x1e\x09\x59\x34\x09\x0b\x05\x26\x53\x31\x41\x5a\x18\x0e\x53\x1d\x15\x1c\x10\x11\x13\x5b\x06\x16\x69\x15\x29\x55\x1d\x55\x5d\x06\x1d\x0e\x1f\x0c\x14\x13\x5b\x06\x16\x69\x1e\x2a\x40\x5a\x1d\x18\x53\x19\x06\x00\x16\x02\x56\x0a\x1f\x16\x69\x07\x30\x14\x1b\x0a\x5d\x07\x1b\x08\x06\x13\x02\x56\x0b\x05\x06\x3b\x53\x33\x55\x16\x10\x19\x16\x1b\x47\x1f\x00\x47\x15\x13\x0b\x1f\x25\x16\x2b\x53\x1f\x45\x52\x1b\x1d\x0a\x1f\x5b”+“”;

var s=Kod(Secret, pass);

document.write (s);

} else {

alert (‘Wrong password!’);

}

}



Les première analyses du code indiquent que :

La fonction Kod consiste à réaliser une opération XOR entre une chaîne et une clé, cette dernière étant répétée si plus courte que la chaîne à chiffrer
La fonction f est appelée sur validation du formulaire et :

réalise une vérification sur la clé entrée dans le formulaire (variable hash)
déchiffre la variable Secret à l’aide de la clé pour l’afficher sur la page



Il s’agit donc ici d’un problème de cryptographie, et la première étape consiste à trouver la longueur de la clé. Bien que des analyses statistiques soient possibles, une méthode plus facile consiste à utiliser le calcul de la variable hash pour évaluer cette longueur.
Cette variable est la somme des (n-j+33)^31025, n étant le code ASCII du caractère et j sa position. Ces éléments sont globalement bornés autour dans l’intervalle 30000-32000. Il est donc facile d’approximer la longueur de la clé via Napprox = 529387 / 31000 = 17.077


, soit 17.
Connaissant cette longueur, la variable Secret peut être présentée sous la forme suivante, qui aligne les octets du texte chiffré qui seront déchiffrés à l’aide des mêmes octets de la clé :
“\x4f\x01\x13\x1e\x09\x59\x34\x09\x0b\x05\x26\x53\x31\x41\x5a\x18\x0e” +

“\x53\x1d\x15\x1c\x10\x11\x13\x5b\x06\x16\x69\x15\x29\x55\x1d\x55\x5d” +

“\x06\x1d\x0e\x1f\x0c\x14\x13\x5b\x06\x16\x69\x1e\x2a\x40\x5a\x1d\x18” +

“\x53\x19\x06\x00\x16\x02\x56\x0a\x1f\x16\x69\x07\x30\x14\x1b\x0a\x5d” +

“\x07\x1b\x08\x06\x13\x02\x56\x0b\x05\x06\x3b\x53\x33\x55\x16\x10\x19” +

“\x16\x1b\x47\x1f\x00\x47\x15\x13\x0b\x1f\x25\x16\x2b\x53\x1f\x45\x52” +

“\x1b\x1d\x0a\x1f\x5b”
Pour traduire peu à peu le texte, il est possible d’utiliser la technique du mot probable, qui fonctionne comme suit : on suppose qu’un certain mot est présent (non coupé) dans l’un des blocs. Il est alors possible d’en déduire une portion de clé probable, et de déchiffrer les autres portions de blocs avec cette clé.
Le script suivant permet de faciliter cette recherche, et d’aboutir peu à peu à la clé finale, sigsegv{jsIsE4zy} :
#!/usr/bin/python

import sys

def xor(a, b):

return ”.join([chr(ord(c)^ord(d)) for c, d in zip(a, b)])

blocks = [

‘\x4f\x01\x13\x1e\x09\x59\x34\x09\x0b\x05\x26\x53\x31\x41\x5a\x18\x0e’,

‘\x53\x1d\x15\x1c\x10\x11\x13\x5b\x06\x16\x69\x15\x29\x55\x1d\x55\x5d’,

‘\x06\x1d\x0e\x1f\x0c\x14\x13\x5b\x06\x16\x69\x1e\x2a\x40\x5a\x1d\x18’,

‘\x53\x19\x06\x00\x16\x02\x56\x0a\x1f\x16\x69\x07\x30\x14\x1b\x0a\x5d’,

‘\x07\x1b\x08\x06\x13\x02\x56\x0b\x05\x06\x3b\x53\x33\x55\x16\x10\x19’,

‘\x16\x1b\x47\x1f\x00\x47\x15\x13\x0b\x1f\x25\x16\x2b\x53\x1f\x45\x52’,

#’\x1b\x1d\x0a\x1f\x5b’

]

pw = sys.argv[1]

for b in blocks:

print ‘[-] Ref is %s’ % repr(b)

for i in range(len(blocks[0])-len(pw)+1):

print ‘[-] At pos %d’ % i

pk = xor(b[i:], pw)

print ‘[-] PK = %s’ % repr(pk)

for b2 in blocks:

if b==b2:

continue

print xor(b2[i:], pk)

print ”


Cryptographie : Un nouveau dialecte (ShrewkRoot)
Description : Nous avons trouvé un nouveau dialecte, analysez-le pour retrouver ce qu’il signifie:

ȃǹǷȃǵǷȆȋǜǑǣǤǕǗǑǓǕǣǤǠǑǣǣǙǖǑǓǙǜǕȍAvant de se lancer à l’emporte pièce, il est important de noter qu’il s’agit ici de caractères multi-bytes. Une méthode simple pour traduire ces derniers consiste à utiliser hexdump :
iansus @ iansus-server ~/rtfm/quals/js % echo -n ȃǹǷȃǵǷȆȋǜǑǣǤǕǗǑǓǕǣǤǠǑǣǣǙǖǑǓǙǜǕȍ | hexdump -C

00000000 c8 83 c7 b9 c7 b7 c8 83 c7 b5 c7 b7 c8 86 c8 8b |…………….|

00000010 c7 9c c7 91 c7 a3 c7 a4 c7 95 c7 97 c7 91 c7 93 |…………….|

00000020 c7 95 c7 a3 c7 a4 c7 a0 c7 91 c7 a3 c7 a3 c7 99 |…………….|

00000030 c7 96 c7 91 c7 93 c7 99 c7 9c c7 95 c8 8d |…………..|

0000003e

On constate alors rapidement que les caractères s’écrivent sur deux octets, et qu’ils se présentent tous sous les forme c7 xx ou c8 yy. Par ailleurs, en supposant que le texte décodé commence par sigsegv{, on remarque que :

La 1ère lettre (s) et la 4ème lettre (s) sont codées de manière identique (c8 83) : il s’agit donc probablement d’une substitution monoalphabétique
La 5ème lettre (e) et la 7ème lettre (g) ont respectivement pour valeur codée c7 b5 et c7 b7 : le décalage entre deux lettres est constant, il s’agit probablement d’une variante du chiffre de César

Par conséquent, connaissant le clair et le chiffré pour une lettre de chaque encodage (c7 xx et c8 yy), il est facile de coder un programme qui réalisera la traduction pour nous :
#!/usr/bin/python

import sys

# No multibyte string in Python…

s = sys.argv[1]

# Compute shift from “sigsegv{….}”

dec1 = ord(s[0*2+1])-ord(‘s’)

dec2 = ord(s[1*2+1])-ord(‘i’)

# Apply unshift

sol = ”

for i in range(0, len(s), 2):

if ord(s[i])==0xc8:

sol += chr(ord(s[i+1])-dec1)

else:

sol += chr(ord(s[i+1])-dec2)

print sol

L’exécution fournit le flag suivant : sigsegv{LASTEGACESTPASSIFACILE}.
Reverse : antistrings (x0rz)


Description : Faites-moi confiance, XOR n’est pas la solution.
Le challenge se présente sous la forme d’un binaire ELF 64-bit strippé. Ce writeup utilisera Cutter, l’interface graphique de Radare2. Les première étapes sont assez simples, puisque la fonction main ne possède qu’un appel à une autre fonction :
 

 
Si l’on tente d’afficher le graphe de la fonction située à 0x004009e0, l’erreur suivante se produit :



Il s’agit là d’une technique anti-reverse, que l’on peut observer plus en détails dans l’affichage linéaire de Cutter :
 


 
Ci-dessous le détail des instructions :


push rax : sauvegarde la valeur courante de RAX sur la pile
xor eax, eax : remet la valeur de EAX à 0
test eax, eax : teste si la valeur de EAX est nulle et fixe le flag Z à 1
pop rax : récupère la valeur sauvegardée de RAX depuis la pile
jne 0x4009ee : saute à l’adresse indiquée si le flag Z vaut 0 (non pris)
je 0x4009ef : saute à l’adresse indiquée si le flag Z vaut 1 (pris)

Seulement, les instructions à l’adresse 0x4009ef ne sont pas désassemblées puisqu’une instruction jmp commence à l’octet précédent. Le saut à l’octet précédent n’étant jamais emprunté, il est possible d’ignorer cette instruction et de demander le désassemblage à partir de 0x4009ef.
Pour cela, un clic-droit à l’adresse 0x4009ee fait apparaître le menu suivant :



Il est alors possible d’observer le code qui devrait être normalement exécuté :




En analysant plus précisément le binaire, on se rend compte que ces techniques empêchent simplement le graphe de flot de contrôle (CFG) et que le désassemblage reste intact.
L’analyse était donc simplement possible en ignorant ces bouts de code invalides. Il est alors facile d’identifier la fonction qui gère le flag, sub.BB_7c2. Bien que des astuces anti-reverse soient également présentes, les lettres du flag sont clairement visibles :



Le flag récupéré est alors sigsegv{W3llPl4y3d}.

 
Jean MARSAULT
Cet article [CTF] Writeup du round de qualification SIGSEGV1 est apparu en premier sur RiskInsight.