Polish security researcher Piotr Duszynski has developed a new reverse proxy tool for penetration testers that can be used to carry out phishing exploits as part of a red team exercise.
So far so meh, but Duszynski has put his tool, called Modlishka, onto GitHub for anyone to download.
That sparks a little more interest. Throw in the fact that not only can Modlishka bypass many of the 2FA schemes in use today, but also automates the whole process, and we have to sit up and take note.
Modlishka, from the Polish 'modliszka' which means mantis, was written to make it as effective and simple as possible for penetration testers to breach the target internal network perimeter using the social engineering route.
In his 'how to use' Wiki Duszynski helpfully notes, "Before you start any email phishing campaign, you will need a credible domain name. Obviously, in order to minimise the risk of being easily spotted by the target user the chosen domain should be as similar to the original as possible."
There's also the small matter of getting the required wildcard SSL certificate before Modlishka can be used, but once again the instructions are there to use LetsEncrypt with acme.sh script to automate the process.
Automation is at the heart of Modlishka and it is this – along with the man-in-the-middle nature of the proxy which enables the real-time collection of 2FA token – that makes Modlishka such a powerful hacking tool.
The author of Modlishka does issue a disclaimer on GitHub: "This tool is made only for educational purposes and can be only used in legitimate penetration tests. Author does not take any responsibility for any actions taken by its users."
However, releasing it into the public domain like this raises questions about the validity of that decision. Perhaps the most obvious being whether the benefit to penetration testers outweighs the risk of wannabe black hats having access to such a powerful point and click hacking tool? Duszynski says that "without a working proof of concept... the risk is treated as theoretical" and therefore "no real measures are taken to address it properly."
SC Media UK has been asking the industry for its opinion.
"Releasing a tool allows organisations to test their defences and also build new defences for that specific tool," Cesar Cerrudo, CTO at ethical hacking outfit IOActive, told SC. "There are benefits for organisations that are proactive on security to use these kinds of tools. By doing so they can better understand what they are defending against in order to create new IDS rules, train the users, and ultimately strengthen their overall security posture."
Matthew Hall, penetration test team leader at Sec-1, part of the Claranet Cyber Security Unit, was quick to point out that exploit kits like Modlishka are nothing new. "This form of phishing and man-in-the-middle platform has previously been implemented by the evilginx project over two years ago," Hall told SC. "Publishing any exploitation toolkit demonstrates how simple it is for a malicious person to attack systems and users, and thus encourages businesses and users to improve defences and recovery capabilities against layered attacks."
While these kind of tools have, indeed, been available to security firms and black hats alike for the longest time, they don't tend to find their way into the public domain for fear of exposing the exploit techniques in use and therefore enabling them to be neutralised. A point made by Thomas Richards, associate principal consultant at Synopsys, who told SC, "Releasing this tool to the public allows for enterprises to understand how to the tool works and create detection or prevention techniques to stop the tool."
So, what should enterprises be doing to ensure that their networks are not susceptible to exploit kits such as Modlishka?
Duszynski himself recommends utilising hardware based 2FA tokens that use an authentication protocol such as U2F which is used by YubiKey for example.
If that's not possible, then Annabel Jamieson, an associate manager at Accenture Security, recommends that in order to mitigate Modlishka organisations should:
Utilise deep packet inspection with SSL interception by a trusted proxy your organisation controls to help detect the Modlishka server from Reverse-Proxying the connection.
Utilise DNS RPZs with a trusted authoritative DNS server to help to prevent the resolution of the fake Modlishka server domain in the first place.
Implement strict access controls on systems to mitigate the opportunity and capability of threat actors to successfully authenticate the systems despite having the correct credentials.
Raise awareness of new social engineering tricks used in phishing campaigns and providing users with threat intelligence that tracks these new techniques and tactics.