A number of recent articles and posts around the rise of evil proxy have started to emerge. Evil Proxy is a service based offering allowing “anyone” (providing you pass the bad guy vetting process) access to a web based platform to launch and manage MiTM phishing campaigns.
These phishing techniques are not new and have been used to great effect by Red Teams and Threat actors for years. However these were often deployed as required as the vast majority of organisations had still not fully rolled out MFA. However the growing proliferation of MFA support across most products has forced attackers and Red Teams to often utilise these methods as standard.
A simplified attack process is as follows.
Once this attack is complete the attacker has the ability to login to the target service as the user. This can be achieved by using the captured credentials and checking other potential service access points or using the authenticated session imported into their own browser to access resources as the user.
This attack although simple in concept was often difficult to deploy manage and keep up to date. Many platforms regularly change or update authentication flows so the “phishlets” used in popular tools such as EvilNginx2 had to be regularly updated and maintained to ensure success against newer portals. The author of these tools deliberately left these “phishlets” up to the end user thus increasing complexity of use.
I have included a number of reference blogs around the use and operation of these campaigns as that is not the focus of this article if you want to dig in deeper as to what frameworks are available and how they work have a look there.
So now what…
Although these attacks are now relatively simple to set up and highly effective there are still a number of mitigation steps that can be implemented to completely nullify or identify these attacks.
Conditional Access Policies
These are fantastic at thwarting these types of attacks. The “evil server” is the actual requester of the authentication event so locking down access to services and systems from trusted devices, ranges or locations is an ideal counter to this threat. Conditional access rules that only allow organisation controlled laptops and phones to access resources will stop this attack dead in its tracks. On recent Red Team engagements in advanced environments these policies prevented the effective use of this type of MiTM campaign.
Alternative MFA
Not all MFA is created equal. Basic MFA as standard within platforms like Microsoft do not offer any protection to these types of attacks. Physical tokens or FIDO2 compliant devices however do. These devices provide a more robust approach to MFA authentication with additional verification that prevents these forms of attack. These devices are often not practical on a large scale but can be used to sure up access to critical systems or services as required.
Data Centre Ranges
Often, in default configurations and by less advanced threats these platforms are just utilised on cloud servers. These services such as Linode, AWS, Azure, Digital Ocean or other providers give an attacker great flexibility in deploying infrastructure. However the IP ranges for these providers are well known and login or authentication events from these ranges are rare particularly within normal user areas. These anomalous login and impossible login events can help to detect and alert on these attacks as they happen. These forms of alerts are often left un checked or neglected in the security centre however these should be closely monitored or automated alert and remediation processes put in place. This detection is not fool proof as more advanced attackers may be more than capable of utilising proxy services to hide this marker, however these detections can still prove useful.
Default configuration and IOC’s
A number of these frameworks available on GitHub contain well known indicators within their requests from obvious headers in the request to other Easter eggs. Low skilled attackers may not modify their tooling allowing quick and easy detections. Sadly this does not appear to be the case with “evilproxy”. Likewise with other detection mechanisms these should not be completely relied upon as skilled attackers can easily modify tooling to evade static detections based on IOC’s
Sources & Links
https://thehackernews.com/2022/09/new-evilproxy-phishing-service-allowing.html
https://github.com/kgretzky/evilginx2
https://github.com/drk1wi/Modlishka
https://breakdev.org/evilginx-2-next-generation-of-phishing-2fa-tokens/
d-sec.net 