Senior Penetration Tester
Joining Bridewell in early 2021, Dominic brings over 10 years’ IT industry experience. As part of the penetration testing team, Dominic’s current focus is on delivering and designing complex bespoke tests and championing Red and Purple Team testing within numerous industries. Before joining Bridewell, Dominic worked as a Sys Admin for Windows and Unix before moving onto penetration testing, where he spent over 3 years within mainly CHECK, government and blue light projects.
In recent months, there have been a number of articles and posts around the rise of a new Phishing as a Service platform known as ‘Evil Proxy’. Many of these articles discuss how the platform allows criminals to ‘easily’ bypass Two Factor Authentication (2FA) and predict that low-skill attackers will drive significant uptake of the tool. While there has been discussion on what the tool is and how it is being used, little has been said on how organisations should counteract it.
In this blog, we will answer how your organisation can defend against Evil Proxy – as well as Man in the Middle attacks more generally.
What is Evil Proxy?
In short, 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 Man in the Middle (MiTM) phishing campaigns.
These phishing techniques are not new and have been used to great effect by threat actors and red teams alike for years. Historically, these techniques weren’t used frequently given that the majority of organisations still hadn’t fully rolled out Multifactor Authentication (MFA). However, the growing proliferation of MFA support across most products and services has forced attackers and red teams to utilise these methods more frequently. Today, they are used as standard.
Below is a simplified diagram of a standard attack process.
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, is often difficult to deploy, manage, and keep up to date. Many platforms regularly change or update authentication flows. As a result, 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 which increased complexity of use.
Defending Against MiTM Attacks
Although MiTM 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 help identify these attacks. All these principles can be applied by organisations specifically looking to defending against Evil Proxy.
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.
Not all MFA is created equal. Basic MFA as standard within platforms like Microsoft do not offer any protection to these types of attacks. On the other hand, physical tokens or FIDO2 compliant devices 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 or compatible on a large scale but can be used to sure up access to critical systems or services as required.
Data Centre Ranges
Default configurations for these tools are often 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. In a MiTM attack, anomalous and/or impossible login events can help to detect and alert on these attacks as they happen.
Unfortunately, these forms of alerts are often left unchecked or neglected in the security centre. Yet, best practice dictates that these should be closely monitored, or automated alert and remediation processes should be 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 IOCs
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 which allows for quick and easy detections from security teams. 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