AiTM vs Email URL Rewriting vs Conceal 

I was running through the past several days of AiTM (adversary-in-the-middle) detections, looking for something new and unique. I did find a few that were more interesting than the others. They were not from a common industry vertical or geographic location. They were not part of a phishing campaign or tied to a single threat actor.  In fact, on the surface, they had nothing in common, except for one very notable characteristic - they safely passed through URL rewriting, email inspection, and protection services. 

Email URL Rewriting Overview 

I am not implying these services are bad or ineffectual. They serve a purpose in your layered detection defense.  The real problem is that they tend to rely on static indicators of compromise (IOCs). IOCs have been in use in the threat intelligence and protection field for as long as I can remember, so they are not new. The issue with them is that, for them to be effective, someone had to have already been affected. In most of these cases, an automated analysis system will eventually process the URLs and determine that they are malicious. At that point, those indicators will be added to the threat feeds and will be blocked for future victims. 

This analysis and the propagation of IOCs through the automated systems take time.  A tightly targeted phishing campaign may have just a few victims. On the flip side, a mass phishing campaign may have thousands. The time window between the initial kickoff of the phishing campaign, often referred to as patient zero, and the propagation of these indicators leaves a large percentage of victims vulnerable. Depending on where and how these IOCs get published, the victims’ organizations may not even detect the attack post-impact. This gives threat actors ample time to gain initial access, perform reconnaissance, move laterally, and initiate an impact, such as information exfiltration or ransomware infection. 

Industry statistics indicate that an average of 200,000 to 300,000 new domains are created daily, with over 900,000 recorded on a single day during a previous peak period. Many of these domains, once created and registered, will be parked to allow them to age out and no longer be considered new. Parking a domain refers to a domain that has been created and registered but has no activity associated with it.  On top of this, there are also a significant number of domains that expire daily. The key takeaway is that it is almost impossible for these services to keep up with the large volume of domain-based IOCs.  

As if that is not bad enough, you also must factor in redirections so that the path from the initial URL to the final malicious destination can change. Many of these attack chains are designed to support reconfiguration when necessary, so that if any infrastructure is discovered, other components can be quickly reconfigured to bypass those systems and continue the campaign with minimal downtime. 

Keeping all the information in the back of your mind, don’t despair. Conceal has the answer to this widespread monumental problem. In a minute, we will look at a few specific examples, but (spoiler alert) – it’s all about detecting based on content put into context rather than just looking at static IOCs. If an email URL rewriting service detects and blocks access before we see it, that’s a win for your organization, and we here at Conceal are happy whenever a threat actor is defeated.  We also want to make sure we see what others cannot and act on that information.  

Real World AiTM Email Attacks 

In this blog, we will take you through two AiTM attacks delivered via email. We will try to keep as much information as possible, but will redact information to protect the customers’ identities. In the first example, we could see the complete attack chain. For the second case, we were unable to successfully detonate the attack sequence in our own environment, so we will discuss it based on the data available. 

AiTM Phishing Attack 1 

This attack started with a link inside of an email.  

If the safelinks check passes, you end up at:

That URL currently returns a “404 Code: NoSuchKey” error; however, at the time this was valid you ended up at:

Not much exciting happening on this page but note the “Wait Redirecting…” title letting you know that something is happening in the background. 

This URL redirects to the final AiTM credential stealing destination.

We have discussed these types of AiTM attacks in prior blog entries. For more information, please see . At this point in our investigation, we do not have any attribution information. Based on the redacted information, we do know that this was targeted at a single individual. Analyzing more undisclosed characteristics associated with this attack, we believe this attack was conducted by a skilled threat actor or group.  

AiTM Phishing Attack 2 

This is another email based AiTM attack. This one starts with the Mandrill app URL, which is a paid Mailchimp add-on. Mailchimp is a widely used email marketing and automation platform. As discussed in previous blogs, many commercial tools and applications are misused by threat actors. Mailchimp is a great example of this; it is widely and successfully used for legitimate sales and marketing, so this is just another tactic used by threat actors to make a phishing email appear valid.  Here is the initial URL.

This goes through the next two resolution steps.

This is where our investigation is currently stalled out. It appears that this attack chain is performing a validation check to proceed to the next step. As proof of this, at one point, we saw part of the Tesichile URL chain redirect to a well-known retailer’s website. At the time of our investigation, we were unable to obtain the RoboCheck URL to proceed. We do know that the URL redirection chain ended up being blocked at the AiTM page hosted at: 

Real World Results 

In both cases, Conceal stopped these attacks before an unsuspecting victim entered any credentials. Like everyone else, static IOCs are part of our detection stack; however, after analyzing our detection statistics, we found that a large percentage of our interventions are based on content-in-context. We use all available information at the exact time of the browser activity to make our determination. This allows for a much higher detection rate when you are dealing with advanced threat actors who rely on target validation measures to ensure that only their specific victims are impacted.  We do not rely on sandboxing from a system in a completely different geographic location, possibly within a well-known IP address range. Some of the most advanced threat actors will only deliver malicious content to systems originating from the IP address space of their intended victim companies. If you’re not looking at the context from a victim system, you will never see the attack in any sandboxed system. 

In many attack scenarios, Conceal blocks malicious activity mid-redirection chain, long before the victim is presented with the final attack content. Each of the attacks covered in this blog had multiple detections, any of which would have been enough to block the phishing page.  Having multiple detection capabilities not only ensures that we find all the badness, but it also greatly helps eliminate false positives so that we do not interfere with normal day-to-day operations.  

As noted at the beginning of this blog entry, this is not meant to in any way diminish URL rewriting protection; it’s a great feature to have in your detection stack, and like Conceal detecting in the middle of a redirection chain, URL rewriting can prevent the user from being presented with malicious content.  However, just relying on that for your email protection leaves you vulnerable to many of today’s advanced phishing attacks.  Conceal’s real-time browser protection covers a major blind spot in the traditional detection stack. No SSL man-in-the-middle, no forcing all traffic through a proxy, nothing, just native browser protection in real-time. 

To learn more about how Conceal delivers browser security without deploying a new browser, visit conceal.io and request a demo.