{
	"id": "97cbb685-54bd-4960-be21-a6755d0b5d9c",
	"created_at": "2026-04-29T02:21:27.080141Z",
	"updated_at": "2026-04-29T08:22:33.560045Z",
	"deleted_at": null,
	"sha1_hash": "dd5b214e684d34d6d920b32e2df70c0f535a64ff",
	"title": "Evilginx 3.2 - Swimming With The Phishes",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 98231,
	"plain_text": "Evilginx 3.2 - Swimming With The Phishes\r\nBy Kuba Gretzky\r\nPublished: 2023-08-24 · Archived: 2026-04-29 02:09:22 UTC\r\nWelcome back!\r\nI've recently managed to find some free time to work on reverse proxy support for the latest Google updates and in\r\nthe process I've made several additions to the Evilginx code base, which I think some of you will find useful.\r\nTo start, I wanted to give a big shoutout to Daniel (@dunderhay) for publishing a great post on how he used\r\nEvilginx to phish the Microsoft 365 ADFS environment and how he even made his modifications to succeed!\r\nEvilginx is getting more love this year than in the last couple of years and I'm very happy about it. I have big plans\r\nfor Evilginx, which I will announce soon, but first I wanted to give you a rundown of what the latest 3.2 update\r\nconsists of.\r\nI will start with the most significant changes.\r\nDynamic Redirection on Session Capture\r\nOne of the behaviours, that annoyed me when using Evilginx, was the fact that sometimes it was not possible to\r\nimmediately redirect the phished user to the configured redirect_url , once all session tokens were captured.\r\nEvilginx could only redirect the browser once the targeted website attempted to navigate to a different page, on its\r\nown.\r\nIt made redirects not work on single-page applications. I learned it first-hand during the development of the\r\nTraining Lab for my Evilginx Mastery course. The main page of the lab changes its contents dynamically and\r\nnever navigates to a different URL. This means that once session tokens are captured by Evilginx, the tool is\r\nunable to redirect the user to redirect_url address.\r\nIn the 3.2 update, I've managed to solve the problem with injected JavaScript sending out HTTP long polling\r\nrequests on every proxied page, to retrieve session capture status directly from the Evilginx proxy server in real-time. Evilginx will inject its own JavaScript code on every HTML page load, which will be responsible for\r\nquerying https://\u003cphish_domain\u003e/s/\u003cphish_session_id\u003e infinitely. Evilginx proxy server will respond with a\r\nJSON structure, containing the redirect_url value only when the session is successfully captured. Otherwise,\r\nthe connection will time out after 30 seconds and will be retried afterwards. Long polling allows Evilginx to let\r\nthe injected script know that the session was captured immediately when it happens.\r\nThe script will then change the window.location URL to the retrieved redirect_url value, redirecting the user\r\nto a preconfigured page address. Redirection should now work great within Evilginx Mastery Training Lab.\r\nInstead of HTTP long polling, I could've used WebSockets, but I wanted to keep it simple without the need to rely\r\non external libraries, which would need to be injected as well.\r\nhttps://breakdev.org/evilginx-3-2/\r\nPage 1 of 5\n\nTemporary Lure Pausing\r\nImagine a situation - you're on a phishing engagement and finally get to send out your phishing lures. Once the\r\nemails start arriving at the target inbox, the mailbox server opens them one by one and scans the HTML content of\r\nevery phishing URL. The mail server then determines emails as phishing and they are sent to quarantine.\r\nThere are many ways to prevent automated scanners from seeing the content of your phishing pages, but the most\r\nstraightforward method would be to simply hide your phishing pages for a brief moment, right before you send\r\nout the emails. Enough to hide their content from automated scanners, but not from the targeted user.\r\nNow you can easily hide your lures from prying eyes by pausing them for a specific time duration with:\r\nlures pause \u003cid\u003e \u003ctime_duration\u003e\r\nThe best part is that you don't have to worry about unpausing a lure manually. Once the pause period expires, the\r\nlure with become active again and you will get a notification about it in the terminal. The pause state also persists\r\nbetween Evilginx restarts.\r\nInterception of HTTP Requests\r\nhttps://breakdev.org/evilginx-3-2/\r\nPage 2 of 5\n\nI found out that sometimes it would be useful to be able to block some of the proxied requests or have them return\r\ncustom responses, without the proxied requests ever reaching the destination server.\r\nNow you can detect specific requests within the new intercept section in your phishlets, which will match\r\nspecific URL paths on domains within your proxy_hosts list. Once the request matches your filters, you will be\r\nable to detour the request and return your response with a custom HTTP status code.\r\nintercept:\r\n - {domain: 'www.linkedin.com', path: '^\\/report_error$', http_status: 200, body: '{\"error\":0}'', mime: \"applic\r\n - {domain: 'app.linkedin.com', path: '^\\/api\\/v1\\/log\\/.*', http_status: 404}\r\nIn the example above, any request to https://www.linkedin.com/report_error will be intercepted and will\r\nreturn HTTP status 200 with response body {\"error\":0} and MIME type application/json .\r\nThe second entry will make sure that all requests to https://app.linkedin.com/api/v1/log/\u003cwhatever\u003e will\r\nreturn 404 Not Found HTTP response.\r\nRedirect URL Added to Phishlets\r\nSometimes for the phishlet to work properly and to not interrupt the phished user's experience, it needs to redirect\r\nthe user's browser right after session tokens are successfully captured. For now, the redirect would happen only if\r\nredirect_url was specified for the lure, used with the phishing engagement.\r\nAt times, it is important to have a default redirect_url specified, especially if we want the user to be redirected\r\nto the home page of the phished website, by design. Sometimes the redirection to the home page will happen\r\nautomatically, but sometimes it needs to be enforced.\r\nFrom this Evilginx version, you can set a default redirect_url in the phishlet you are creating to make sure the\r\nphished user is redirected, once session tokens are captured, even if redirect_url has not been set up for the\r\ngiven lure.\r\nUnauthorized Request Redirects Per Phishlet\r\nFirst of all, I've changed the name redirect_url from global config to unauth_url , to better illustrate its\r\npurpose and so it doesn't get confused with redirect_url set up in phishlets or lures.\r\nIMPORTANT! Keep note that the URL you set for unauthorized request redirects may reset itself after the\r\nupdate, due to the name change.\r\nUnauthorized URL or unauth_url holds the URL address where visitors will be redirected if they open any URL\r\non the phishing domain, which doesn't correspond to any valid URL or if the lure is currently paused.\r\nSo far, it was possible to set up unauth_url globally, which would provide the same URL to redirect to for all\r\nactive phishlets. With 3.2 you can now override the global unauth_url by specifying a value for each phishlet\r\nwith:\r\nhttps://breakdev.org/evilginx-3-2/\r\nPage 3 of 5\n\nphishlets unauth_url \u003cphishlet\u003e \u003curl\u003e\r\nThis feature was suggested by @0x_aalex who was also kind enough to submit a PR with his implementation.\r\nThank you for that!\r\nTweaks and Fixes\r\nAdditionally to several new features, Evilginx has also received some QoL tweaks and fixes, which should\r\nimprove the overall phishing performance.\r\nDisabled caching of proxied content by web browsers\r\nSometimes it was especially frustrating to test the sub_filters of your phishlets because your web browser\r\ncached the content of your previous modification. Every time you made small changes and had to retest, it was\r\nrequired to clear the browser cache.\r\nStarting from the 3.2 update, Evilginx will prevent web browsers from caching HTML, JavaScript and JSON\r\ncontent by injecting Cache-Control: no-cache, no-store HTTP header in proxied responses.\r\nThis should also make working with js_inject much more convenient.\r\nJavaScript injected through external references\r\nNormally when your phishlets inject JavaScript, through js_inject functionality, Evilginx would drop the\r\nwhole script into the content of the HTML page within \u003cscript\u003e...\u003c/script\u003e tags. This approach was kind of\r\nmessy, so I figured out a way to inject multiple scripts as external references, like this:\r\n\u003cscript type=\"application/javascript\" src=\"/s/48d378a85f0867ef16bf0fd28deda0d4b30139c54805033803e7fdcbc31f293c/\r\n\u003cscript type=\"application/javascript\" src=\"/s/48d378a85f0867ef16bf0fd28deda0d4b30139c54805033803e7fdcbc31f293c.j\r\nRequests to download external JavaScript resources will be intercepted by Evilginx proxy and the response will be\r\ndelivered from Evilginx directly, without ever being forwarded to the destination website.\r\nThis approach should make it possible to introduce dynamic JS obfuscation, in the future. (Stay tuned!)\r\nChangelog\r\nHere is the full changelog for Evilginx 3.2:\r\nFeature: URL redirects on successful token capture now work dynamically on every phishing page. Pages\r\ndo not need to reload or redirect first for the redirects to happen.\r\nFeature: Lures can now be paused for a fixed time duration with lures pause \u003cid\u003e . Useful when you\r\nwant to briefly redirect your lure URL when you know sandboxes will try to scan them.\r\nFeature: Added phishlet ability to intercept HTTP requests and return custom responses via a new\r\nintercept section.\r\nhttps://breakdev.org/evilginx-3-2/\r\nPage 4 of 5\n\nFeature: Added a new optional redirect_url value for phishlet config, which can hold a default redirect\r\nURL, to redirect to, once tokens are successfully captured. redirect_url set for the specific lure will\r\noverride this value.\r\nFeature: You can now override globally set unauthorized redirect URL per phishlet with phishlet\r\nunauth_url \u003cphishlet\u003e \u003curl\u003e .\r\nFixed: Disabled caching for HTML and Javascript content to make on-the-fly proxied content replacements\r\nand injections more reliable.\r\nFixed: Blocked requests will now redirect using javascript, instead of HTTP location header.\r\nFixed: Improved JS injection by adding \u003cscript src\"...\"\u003e references into HTML pages, instead of\r\ndumping the whole script there.\r\nFixed: Changed redirect_url to unauth_url in global config to avoid confusion.\r\nFixed: Fixed HTTP status code response for Javascript redirects.\r\nFixed: Javascript redirects now happen on text/html pages with valid HTML content.\r\nFixed: Removed ua_filter column from the lures list view. It is still viewable in lure detailed view.\r\nClosing Thoughts\r\nHope you enjoy this update and there is more to come for Evilginx!\r\nIf you are interested in mastering the Evilginx phishing framework, consider checking out my Evilginx Mastery\r\ncourse:\r\nIn the upcoming weeks, I want to show off a sneak peek of Evilginx Pro and outline all of its extra features.\r\nEvilginx Pro will be a paid product I want to distribute only to vetted red teaming companies around the world.\r\nI will post more details when I'm ready!\r\nIf you are interested in how to protect against reverse proxy phishing, do check out the talk I gave in May at\r\nx33fcon cybersecurity conference from this year:\r\nFor now, stay tuned and you can always follow me on Twitter @mrgretzky.\r\nSource: https://breakdev.org/evilginx-3-2/\r\nhttps://breakdev.org/evilginx-3-2/\r\nPage 5 of 5",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://breakdev.org/evilginx-3-2/"
	],
	"report_names": [
		"evilginx-3-2"
	],
	"threat_actors": [],
	"ts_created_at": 1777429287,
	"ts_updated_at": 1777450953,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/dd5b214e684d34d6d920b32e2df70c0f535a64ff.pdf",
		"text": "https://archive.orkl.eu/dd5b214e684d34d6d920b32e2df70c0f535a64ff.txt",
		"img": "https://archive.orkl.eu/dd5b214e684d34d6d920b32e2df70c0f535a64ff.jpg"
	}
}