{
	"id": "3849253b-3dfc-4f76-838c-dc558ff5a511",
	"created_at": "2026-04-29T02:22:18.098197Z",
	"updated_at": "2026-04-29T08:21:37.066358Z",
	"deleted_at": null,
	"sha1_hash": "16e50cc8c9933d6cf107d95aeb95484f6d242c08",
	"title": "Evilginx 2.1 - The First Post-Release Update",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 69385,
	"plain_text": "Evilginx 2.1 - The First Post-Release Update\r\nBy Kuba Gretzky\r\nPublished: 2018-09-10 · Archived: 2026-04-29 02:03:04 UTC\r\nAbout 2 months ago, I've released Evilginx 2. Since then, a lot of you reported issues or wished for specific\r\nfeatures.\r\nYour requests have been heard! I've finally managed to find some time during the weekend to address the most\r\npressing matters.\r\n[\u003e\u003e Download Evilginx 2 from GitHub \u003c\u003c](https://github.com/kgretzky/evilginx2)\r\nHere is what has changed and how you can use the freshly baked features.\r\nChangelog - version 2.1\r\nDeveloper mode added\r\nIt is finally much easier to develop and test your phishlets locally. Start Evilginx with -developer command-line\r\nargument and it will switch itself into developer mode.\r\nIn this mode, instead of trying to obtain LetsEncrypt SSL/TLS certificates, it will automatically generate self-signed certificates.\r\nEvilginx will generate a new root CA certificate when it runs for the first time. You can find the CA certificate at\r\n$HOME/.evilginx/ca.crt or %USERPROFILE%\\.evilginx\\ca.crt . Import this certificate into your certificate\r\nstorage as a trusted root CA and your browsers will trust every certificate, generated by Evilginx.\r\nSince this feature allows for local development, there is no need to register a domain at domain registrars. Just use\r\nany domain you want and set the server IP to 127.0.0.1 or your LAN IP:\r\nconfig domain anydomainyouwant.com\r\nconfig ip 127.0.0.1\r\nIt is important that your computer redirects all connections to phishing sites, to your local IP address. In order to\r\ndo that, you need to modify the hosts file.\r\nFirst, generate the hosts redirect rules with Evilginx, for the phishlet you want:\r\n: phishlets hostname twitter twitter.anydomainyouwant.com\r\n: phishlets get-hosts twitter\r\n127.0.0.1 twitter.anydomainyouwant.com\r\nhttps://breakdev.org/evilginx-2-1-the-first-post-release-update/\r\nPage 1 of 4\n\n127.0.0.1 abs.twitter.anydomainyouwant.com\r\n127.0.0.1 api.twitter.anydomainyouwant.com\r\nCopy the command output and paste it into your hosts file. The hosts file can be found at:\r\nLinux: /etc/hosts\r\nWindows: %WINDIR%\\System32\\drivers\\etc\\hosts\r\nRemember to enable your phishlet and you can start using Evilginx locally (can be useful for demos too!).\r\nAuthentication cookie detection was completely rewritten\r\nThere were some limitations in the initial implementation of session cookie detection, so I rewrote a significant\r\nportion of its code. Now, Evilginx is able to detect and properly use httpOnly and hostOnly flags, as well as\r\npath values for each captured cookie.\r\nIMPORTANT! Previously captured sessions will not load properly with latest version of Evilginx, so make sure\r\nyou backup your captured sessions before updating.\r\nEvilginx will now properly handle cookie domains .anydomain.com vs anydomain.com . This is very important\r\nas I've noticed, during testing, the imported cookies will not provide a working session if cookie domain is set\r\nimproperly.\r\nThe difference between each is, that cookie set for domain .anydomain.com will be sent in requests to\r\nanydomain.com and also to any sub-domain of .anydomain.com (e.g. auth.anydomain.com ), while the cookie\r\nset for domain anydomain.com will be sent only with requests to anydomain.com .\r\nI had to also update current phishlets to properly detect cookie domain names (with . prefix or without), so you\r\nmay also need to update your private ones, accordingly.\r\nRegular expressions for cookie names and POST key names\r\nIt has come to my attention that some websites will dynamically generate cookie names or POST key names,\r\nbased on user ID or some other factors. Since Evilginx was only able to look for fixed names, it would never be\r\nable to properly capture such cookies or intercept a username/password field in POST request.\r\nNow, you can enter regular expressions for both cookie names and POST user_regex and pass_regex , by\r\nadding regexp to the string, after a comma , separator.\r\nHere is the example. Let's say we want to capture a cookie that has the name session_user_738299 , where\r\n738299 is the user ID, which will be different for every user and thus will be a dynamic value. We can set up\r\ncapturing of this cookie with regular expressions, like this (considering that the numerical value is always 6\r\ndigits):\r\nauth_tokens:\r\n - domain: '.anydomain.com'\r\n keys: ['session_user_[0-9]{6},regexp']\r\nhttps://breakdev.org/evilginx-2-1-the-first-post-release-update/\r\nPage 2 of 4\n\nThis also can be done for POST keys. If we need to intercept a POST key, that will hold a username, with name\r\nuser[session_id_36273] , we can do:\r\nuser_regex:\r\n key: 'user\\[session_id_.*\\],regexp'\r\n re: '(.*)'\r\nSame applies to pass_regex of course.\r\nURL path detection for triggering session capture\r\nYou will find websites that set the session cookie ID before you even start typing your email in the login form. In\r\nsuch cases, Evilginx would detect the session cookie, capture it and since it was the last cookie it was meant to\r\ncapture, it would consider the session captured. This would not be the case, since even no credentials were\r\nentered.\r\nAs smart people pointed out on Github, this can be remedied by detecting an HTTP request to specific URL path,\r\nwhich happens only after the user has successfully authenticated (e.g. /home ).\r\nNow you can add a new parameter in your phishlet auth_urls , where you provide an array of URL paths that\r\nwill trigger the session capture. If we wanted to look for HTTP request to /home , we could do set it up like this:\r\nauth_urls:\r\n - '/home'\r\nWith auth_urls set up in the phishlet, Evilginx will not trigger a session capture even when it considers all\r\nsession cookies captured. These cookies will be stored only after the HTTP request to any of the specified URL\r\npaths happens.\r\nIMPORTANT! URL paths in auth_urls are all considered regular expressions, so proper escaping may be\r\nrequired (also no need to add ,regexp to each string)\r\nThere is now a cool trick that utilizes both auth_urls feature and regular expressions for cookie names.\r\nIf you ever come across a website that sends cookies in such a way that makes them impossible to detect with\r\nregular expressions, you can just opt for capturing all the cookies for a given domain and waiting for the URL\r\ntrigger.\r\nThis is how you'd do it:\r\nauth_tokens:\r\n - domain: '.anydomain.com'\r\n keys: ['.*,regexp'] # captures all cookies for that domain\r\nauth_urls:\r\n - '/home' # saves all captured cookies when this request is made\r\nhttps://breakdev.org/evilginx-2-1-the-first-post-release-update/\r\nPage 3 of 4\n\nThis is a very messy approach and I'd prefer to not see phishlets rely on that too much, but it can be done.\r\nEmpty subdomains now work\r\nThere was a bug that would prevent phishlets to work for websites that do not use any subdomains for some of\r\ntheir hostnames. This is no longer an issue and as an example to prove that it is fixed, I've slightly modified the\r\ntwitter phishlet to work with twitter.com hostname.\r\nWrapping up\r\nKeep posting issues you are having with creating your own phishlets as I'm sure there will still be scenarios that\r\nwill require some adjustments made to Evilginx.\r\nYou can update by pulling latest changes to the master branch. I will post a binary release once I confirm that\r\neverything is stable.\r\n[\u003e\u003e Follow me on Twitter \u003c\u003c](https://twitter.com/mrgretzky)\r\n[\u003e\u003e Download Evilginx 2 from GitHub \u003c\u003c](https://github.com/kgretzky/evilginx2)\r\nI have some nice ideas still for upcoming releases like dynamic custom Javascript injection and forcing\r\n\"Remember Me\" check boxes by POST parameter injection.\r\nHope you are liking Evilginx so far.\r\nEnjoy this update!\r\nSource: https://breakdev.org/evilginx-2-1-the-first-post-release-update/\r\nhttps://breakdev.org/evilginx-2-1-the-first-post-release-update/\r\nPage 4 of 4",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://breakdev.org/evilginx-2-1-the-first-post-release-update/"
	],
	"report_names": [
		"evilginx-2-1-the-first-post-release-update"
	],
	"threat_actors": [],
	"ts_created_at": 1777429338,
	"ts_updated_at": 1777450897,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/16e50cc8c9933d6cf107d95aeb95484f6d242c08.pdf",
		"text": "https://archive.orkl.eu/16e50cc8c9933d6cf107d95aeb95484f6d242c08.txt",
		"img": "https://archive.orkl.eu/16e50cc8c9933d6cf107d95aeb95484f6d242c08.jpg"
	}
}