Lure redirect_url not working

[kpomeroy1979]

@kgretzky The lure redirect_url option does not work. Regardless of the setting it does not redirect users after they complete the authentication and MFA flow using a Microsoft 365 Phishlet.

functionality used to work but seems like something has changed recently. Sometime after he modified the redirect code in evilginx3/core/http_proxy.go from using a Location header with a 302 code to using JavaScript the redirect_url is broken.

Each time the user authenticates, and goes through the MFA workflow the software captures credentials and session tokens, but then the whole process of logging in to MS365 starts over again, when in older versions it would redirect the user to somewhere (google, the real MS365, a custom landing page etc)

[matejsmycka]

Are you sure the redirect_url is not proxied (aka defined in proxy_hosts) with auto_filter=true (default), that would be feature.

[kpomeroy1979]

I found it. Those settings are in the actual phishlet itself in /usr/share/evilginx/phishlets/

Are you suggesting that I add auto_filter: true somewhere in the phishlet? Sorry I don't quite understand your advice.

Here are my current settings for my o365 Phishlet

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: false, is_landing:false}

[matejsmycka]

auto_filter: true is set by default.

Whenever you redirect a user to a URL in proxy_hosts, the filter is triggered, and all legitimate URLs are replaced with phishing URLs. So, you must redirect to some URLs, not in proxy hosts.

It is bad. However, it is a feature. I hope this will be modified in the future.

[matejsmycka]

The workaround is using some online URL shortener, which redirects users to legitimate sites.

Just search URL shorteners, paste in redirect URL, it will yield something like this: https://shorturl.at/hklsI

Which you can use as redirect_url.

[matejsmycka]

Also, the final page must meet all requirements in this IF statement.

https://github.com/kgretzky/evilginx2/blob/9e32484719681892945130187ea52737b3d72051/core/http_proxy.go#L1229

It is poorly implemented, and I had to change the source code and recompile my custom version for one usecase.

[roberthermanforex]

@kgretzky @matejsmycka how do I address the issue where the Evilginx lure URL stops working after one successful session and requires clearing cookies?

[yurigbur]

auto_filter: true is set by default.

Whenever you redirect a user to a URL in proxy_hosts, the filter is triggered, and all legitimate URLs are replaced with phishing URLs. So, you must redirect to some URLs, not in proxy hosts.

It is bad. However, it is a feature. I hope this will be modified in the future.

I don't really agree that this is a feature that is "working as intened" or rather this should be the way it works. Redirecting to the "original" page after finishing the phish is a very common use case as the users likely expect to land on this page. The trick with the URL shortener is likely the easiest one.

[matejsmycka]

of course, nobody is arguing otherwise

[kpomeroy1979]

The fix for me is to use a URL Shortener, and then just use that URL in the 'redirect_url' setting. That fixes my issue of the user constantly getting stuck in a log in loop over and over.

On Thu, Aug 1, 2024 at 8:38 AM . @.***> wrote:

of course, nobody is arguing otherwise

— Reply to this email directly, view it on GitHub https://github.com/kgretzky/evilginx2/issues/1040#issuecomment-2263242359, or unsubscribe https://github.com/notifications/unsubscribe-auth/AH5LZHQJPW6TX6JHCSZS44DZPJB5DAVCNFSM6AAAAABF7XP65KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENRTGI2DEMZVHE . You are receiving this because you authored the thread.Message ID: @.***>

[n3rada]

One potential solution to address this issue is to use the following JavaScript injection strategy. This approach leverages the js_inject feature, which executes the specified script after successful token retrieval. The script is triggered when the registered page is reached, and it automatically redirects the user to a safer destination or a different page.

js_inject:
   - trigger_domains: ["your-evil-domain.com"]
     trigger_paths: ["/path/trigger"]
     trigger_params: []
     script: document.location = "https://goodwebsite.io";

[dennisbaaten]

I've also been experiencing authentication loops when using (different kinds of) M365 phishlets. With or without a lures redirect_url: after successful authentication and token interception, I'm redirected back to the login screen featuring my phishing domain. I tried using a url shortener, but this had no effect.

However, what stopped the authentication loops for me (without redirecting to the legitimate domain), was changing this line in the phishlet: - {phish_sub: 'www', orig_sub: 'www', domain: 'office.com', session: false, is_landing:false} to this line: - {phish_sub: 'www', orig_sub: 'www', domain: 'office.com', session: false, auto_filter: false, is_landing:false}

Might not be the perfect solution, but for me it is sufficient. I'm using Evilginx for security awareness demo's.