The authoritative resource for physical and converged security
In a profit-driven, ethically-unconstrained criminal enterprise like phishing it is not surprising that threat actors have evolved to match the times. Rather than focus on techniques, this article will discuss how phishing applications have changed to match new security standards.
Only 22% of Microsoft clients have adopted two-factor protection, so the traditional phishing attacks are still effective against most small to mid-sized operations. In the case of the enterprise client, we are seeing a transition towards phishing attacks that can seamlessly target two-factor protected accounts.
In a Proofpoint survey (www.securitysa.com/*phish1), 83% of organisations said they experienced a successful email-based phishing attack in 2021, versus 57% in 2020. That equates to a 46% increase in organisations hit with a successful phishing attack last year.
Of those 54% experienced a breach of customer or client data and 48% saw credential or account compromise, 46% experienced ransomware infection. In 2021, Microsoft blocked 25,6 billion Azure AD brute-force authentication attacks and intercepted 35,7 billion phishing emails.
This is the part where we shame you for not using two-factor authentication. In the more antiquated operations, attackers hosted realistic copies of the target web applications and required some effort to clone target websites. Attackers would have to match updates to target websites and upgrade their own infrastructure in tandem.
To reduce this effort, threat actors began to produce all-in-one toolkits which automatically fetched static copies of target websites and served them to targets and protected them with various cloaking mechanisms.
We can see examples in the images, where the background changes according to the target domain. These phishing applications typically break once credentials have been obtained and provide no additional user-interaction.
With the adoption of two-factor mechanisms by cloud hosts (which protect against 90% of targeted attacks with ‘off the shelf’ kits and 100% of bot attacks) phishing toolkits have begun to adopt real-time mechanisms in place of static content.
These are usually in the form of man-in-the-middle (MITM) phishing toolkits. One readily available open-source tool is Evilginx, which can be downloaded from Github and provides full 2FA interception capabilities and has already been forked into several other open-source tools.
These MITM toolkits act as reverse proxy servers, acting as middleman between the victim and the victim mail server. Responses and requests are proxied between victim and target server, while the threat actor stores credentials and session tokens and authentication session cookies. This eliminates the need to create and maintain a realistic phishing web page.
Unlike traditional phishing attacks where site behaviour changes after credentials are intercepted, the site will continue to offer functionality for the victim because the browsing session is maintained by the attacker infrastructure.
This allows the attacker more time to profile the victim. This is an important distinction for new phishing toolkits, the continuous proxying of traffic between the target and victim machine before and after exploitation.
In addition to this functionality, modern MITM toolkits protect traffic by using tokenised lures. These are essentially random tokens which would be included in requests to access the phishing content.
Traffic flow can be directed in cases where the token is missing to specific web pages. These applications also allow rapid decommissioning of tokens, so that links will stop responding. This allows precise targeting and custom attacks. It also means that campaigns are up for longer because it is harder to blacklist links.
According to an MIT study, 40% of MITM phishing websites will operate for more than one day and around 15% remain operational for over 20 days. Older phishing sites are statistically likely to be down within a single day. The same study found that 27% of MITM phishing toolkits were co-located on the same IP as a benign domain. This would indicate attackers are using dedicated infrastructure or reuse existing malicious infrastructure. Previous data showed more than half of all phishing domains resolved to the IP addresses of compromised (legitimate) websites.
Findings and mitigation
One positive is that MITM phishing changes the request/response time profile such that it exposes the traffic to network fingerprinting. This is because traffic must be proxied. This opens this kind of phishing up to various detection techniques.
On the downside, the obfuscation mechanisms which are used by MITM phishing reduces the effectiveness of blocklists. Targets seem to be predominantly enterprise users, but we expect this to change as more clients adopt 2FA.
To mitigate these efforts, the following starting points should be considered.
1. Have a think before you click the link: Don’t click it. Hover over the link and verify where the link is directing too. If address looks odd, do not click on it. If you accidentally click on the link, don’t enter any data.
2. Use multi-factor applications that provide one-time pins (OTP) rather than just 2FA or go ‘passwordless’: Never be satisfied with just a username and a password.
3. Look out for malicious email attachments: Don’t open attachments unless you have no other option. Share content within Teams or Sharepoint.
4. Don’t upload your attachments to be checked in public sites like Virustotal or any.run: This may seem counter-intuitive, but don’t upload your attachments to be checked in free malware scanners. All the data becomes accessible to everyone else. You can download any submission from any.run and view the content in the sample. Use in-house scanners or a paid service that hides sample content. Threat actors use any.run to profile company data from submitted PDFs, which include invoices.
5. Use security at the mail gateway and at the endpoint: Mimecast offers URL security for links inside your email and mail security on your mail gateway. Use a monitored endpoint detection response application on your endpoint.
For more information contact J2 Software,
© Technews Publishing (Pty) Ltd | All Rights Reserved
printer friendly version