PHISHING SCHOOL

Bypassing Web Proxies so Your Phish Don’t Suffocate

You just fought long and hard to convince a user to click on your link. They are dying to know about the contents of your macro enabled excel file. So, don’t let web proxies ruin your fun by blocking your payload! We are in the home stretch, but that doesn’t mean we get to take a victory lap just yet.

The Good Ol’ Days

I remember it well. The year was 2014, and I was embarking on my first phishing expedition as a fledgling penetration tester. I fired up my Metasploit listener, minted an EXE payload with Veil, and called it ‘dresscode_policy.doc.exe’. I sent out my emails and, in return, was blessed with a bounty of shells raining in from the deep blue internet. In those days, it seemed like there would always be phish on the table. Looking back now, I can hardly believe it was ever so easy.

Sparse Waters

We’ve continued to overphish the same waters year after year with reckless abandon and now the phish don’t bite like they used to. The same bait doesn’t work. The same nets come up empty. We have only ourselves to blame for being so selfish (selphish?). We used EXEs like harpoons and now they are completely blocked unless they are signed. We wove nets of PowerShell until AMSI and constrained language mode cut them to ribbons. We dredged scores of users with Excel macros until Microsoft almost did away with macros entirely. We even used mark of the web bypasses to the brink of extinction.

How will we ever catch a phish again?

What’s Really Happening

I was being a bit dramatic, but I did want to make one point:

Defenses adapt to threats and we are the threats.

As new phishing techniques emerge, one of the most obvious defenses has always been to try to block initial access payloads based on their file type. Someone starts slinging malware in Microsoft Excel add-in (XLL) files, and suddenly it makes sense for most organizations to just block these files outright. Payload types that were ‘working’ across the board just months ago tend to make too much noise and now get blocked.

We may mourn the fall of our favorite initial access payloads (R.I.P. OLE), but not all hope is lost. Let’s talk about the challenge of initial access from a high level so we can see our options more clearly. First, we’ll talk about objectives, then discuss defenses, and finally bypasses!

Can It Run Code?

If a file type can run code, or open another application that can run code, then it can likely be used for initial access. To get a full list of potentially dangerous files, we can look at the ones blocked by default on Outlook:

https://support.microsoft.com/en-us/office/blocked-attachments-in-outlook-434752e1-02d3-4e90-9124-8b81e49a8519

The list is 120 entries long! And even that is not the full list, considering that Outlook still allows dangerous file types like macro enabled Office documents. Thanks to @mrd0x, another good source is filesec.io:

https://filesec.io/#

Use the “Double Click” filter to find file types that are particularly useful for phishing. These “Double Click” files initiate some action when clicked by a user. Often running a script or executable of some kind. That list is 77 entries long!

Our goal for initial access is to successfully deliver at least one of these files to the target and convince them to open/run it. Which file types are allowed will vary depending on controls in your target environment, but it is extremely unlikely that all of these file types are blocked. Often, several of these “dangerous” files are used in business processes and have exceptions applied to them. We just need to find one exception!

The Wall

There is a wall between us and our target. It is lined with turrets that want to destroy our payload. This wall consists of the corporate proxy, the corporate firewall, and the target’s browser. Each has some visibility into what users are downloading and each will try to prevent users from inviting us into the network, but there’s a problem with their eyesight. They really only have three ways of knowing what file type is being downloaded, and we can control each one.

1. Extensions — The last characters of the file name (e.g., doc, txt, exe)
2. MIME Types — The content type we specify in our server response headers (e.g., application/msword, text/plain, application/x-msdownload)
3. Magic Numbers — The first bytes in a file (e.g., “50 4B 03 04” for .zip files or “4D 5A” for Windows executables)

Under normal circumstances, these indicators should all tell a consistent story like:

A windows executable with an extension of “exe”, AND a MIME type of “application/x-msdownload”, AND “4D 5A” (the “MZ” header) as the first two bytes.

Therefore, you could write a program to detect these dangerous files based on any single characteristic. Writing detections based on all three would be extremely redundant. I suspect many software engineers have made this very mistake. Choosing a single indicator, writing the detection logic, and thinking that would be enough. However, it’s the contents of the file and not its name, MIME type, or magic number that make it dangerous. Now that we have a clear view of our adversary, let’s talk about how we might slip past their watch.

Bypasses

As I mentioned, we will need to slip past the proxy, firewall, and browser controls to get our payload on the target’s system; however, for sake of example, let’s say the most restrictive of these controls is the corporate proxy. System administrators have fine tuned their proxy rules to block any attempts to download known malicious file types over HTTP and HTTPS. Similar rules apply to the other two, but it will help to focus on just one control for now.

Bypass 1 — Exceptions

I told you that the proxy was going to block all malicious files, but were you really going to just take my word for it without testing? Tisk tisk! As mentioned earlier, there are tons of potentially malicious file types we can use. Some may be too obscure for network defenders to even know about. Others might need to be explicitly allowed because of a business need. Wouldn’t it cause problems for many companies if every Office document hosted on OneDrive was suddenly blocked? How long will our system administrators take the heat before they cave in and put in an exception? In practice, I have found these surprisingly often, so you might just get lucky.

Bypass 2 — Embed in HTML

Did you know you can dynamically generate a blob of data in JavaScript, in the browser, and then use just JavaScript to “Download” the contents to a file? This is a totally legitimate feature for most browsers. For example, web developers might need a way to expose a button on a page to download the contents of a “table” element to a CSV file for the user.

We can use this same feature to download arbitrary file contents to arbitrary file names. What makes this technique so useful to us is that there is no separate call to the server to download the payload. We can slip the contents of our payload inside a ‘script’ tag in an HTML document like a Trojan horse. The proxy will only see the HTML document being downloaded, and not know it contains another malicious file inside it. This technique is known as “Embed in HTML’’ and there are several tools that can help us automate weaponization. Here’s one that I’ve used for years:

https://github.com/Arno0x/EmbedInHTML

You might want to make a few tweaks so that you aren’t signatured based on the template, but the project is a great example of how to execute this attack well using encryption to further protect your payload.

Bypass 3 — Password Protected ZIP

I have found that ZIP files are very commonly allowed in corporate environments. There are so many legitimate uses for ZIP that it would be prohibitive to block them outright. To account for potentially dangerous ZIP files, many security products will actually unzip the contents to see what’s inside before making a determination about whether it is safe.

But what if they can’t open it? What if we include a password in our phishing email that the target will then use to open a password protected ZIP file? In most cases, the security product will not be able to properly vet the file, but will let the user download it anyway. I’ve used this technique with great success to slip all sorts of sketchy file types past corporate proxies.

Bypass 4 — FTP and WebDAV

Did you know that most browsers support FTP URLs? In our example of an extremely restrictive web proxy blocking downloads of HTTP and HTTPS, sending the user to an FTP share might slip past unnoticed. In addition, depending on how the proxy settings are being applied, they might not be enforced for explorer.exe visiting a WebDAV share. In that case, you might instruct a target to copy a UNC path and paste it into the file explorer.

Bypass 5 — MIME Trickery

Sometimes, we can get the receiving web browser to know the “real” payload type based on its MIME type, and spoof the file extension. A classic example of this is that Internet Explorer treats any file with the MIME type “application/hta” as an HTA file and will prompt the user to execute it. If our example proxy is blocking our “payload.hta” file based on the file extension, we can simply rename the file to “payload.pdf” while still specifying the HTTP header “Content-Type: application/hta” from our server.

Bypass 6 — Change the Extension

Let’s say that you want to deliver a PowerShell script to stage your malware, but the proxy blocked PS1 files. What if we just put the script in a TXT file and ask the target user to change the file name for us? Along the same lines, you might add a nonsense extension to the file and then instruct the user that they will need to select an application to open it (e.g., PowerShell). Sure, it’s not quite as convenient as having them just double-click the file, but you might be surprised what additional requests we can tack onto our phishing message if we already have them on the hook.

Bypass 7 — Magic Number Stomping

I’ve seen many cases where I’ve successfully delivered a stager written in Windows scripting utilities like PowerShell, VBA, JScript, etc. and seen a request from my stager to load the full payload, only to have the stager immediately die. What I found in several of these cases is that because I was staging a .NET assembly or other Windows executable, the download for my full payload was being signatured and blocked based on the first two bytes of the file. In this case, the “MZ” header that prepends all Windows EXE and DLL files. To get around this, a quick fix that has turned out to be really effective is just to remove those first two bytes from the file and then programmatically add them back using some logic in my stager.

Bypass 8 — Poison Existing Documents

Instead of trying to directly deliver payloads with our phishing campaign, what if we use CuddlePhish to first gain access to O365, Gmail, or Okta, and then abuse the target’s access to backdoor files we find on OneDrive, Teams, Google Drive, etc? If you aren’t familiar with CuddlePhish, it’s a tool we can use to bypass multi-factor authentication (MFA) while forcing phishing targets to log into services for us.

The point here is that instead of delivering payloads from our phishing site, we target access to the places where we expect our target organization is storing and sharing documents. You could even take this a step further and use access to Outlook webmail and Teams to message other employees at the target organization and prompt them to “review your changes” to your poisoned documents.

Addressing the Whale in the Boat: A.K.A. Mark of the Web

Many red teamers get discouraged by the mark of the web (MOTW) and treat it like it’s a death sentence for any payload they wish to deliver during phishing. I have to say that this is simply not the case. I think it’s very rarely the MOTW that is the last nail in the coffin for phishing payloads. For one, I know of at least two MOTW bypasses that still work (sorry, but I’m not sharing those at this time), so I know there are bound to be more. If you dig around, then I’m sure you can find one.

Secondly, MOTW doesn’t always mean your payload is belly-up and dead in the water. For many file types, it just adds another annoying prompt or two to make sure the user really wants to “keep” and “open” the sketchy file.

Finally, you can always just ask your target to right-click on the file, select “Properties”, and check the “Unblock” button:

It really is that easy! Keep in mind that this is the absolute most difficult MOTW bypass out there and it’s not that hard. Most users will be willing and able to perform this bypass for you.

In Conclusion

Proxies, firewalls, and browsers are going to try to block sketchy files and that can really take the wind out of our sails when trying to deliver payloads with phishing. Luckily, we have options, somewhere in the range of dozens to hundreds of options, so it’s unlikely that every single potentially malicious file type is blocked. In addition, most security products only block file types based on attributes that we can control. Therefore, we have several tricks we can use to potentially bypass them. Worst case scenario, we just need a little extra social engineering to get our targets to make a file modification before opening/running our payload.

And remember! Phish are friends, not food…

---

Phish Out of Water was originally published in Posts By SpecterOps Team Members on Medium, where people are continuing the conversation by highlighting and responding to this story.

The post Phish Out of Water appeared first on Security Boulevard.

PHISHING SCHOOL

How to Make Your Phishing Sites Blend In

As you read this, bots are coming to find and destroy your phishing sites. You need to protect them before it’s too late! But how?

A phishing page is no good if our targets never get to see it. After bypassing the secure email gateway, convincing a user to click our link, and bypassing any link crawlers, the last “user outbound” control we need to circumvent is the corporate web proxy. Frequently, organizations will choose to route all of their web traffic (HTTP and HTTPS) through a proxy to block known-bad websites, monitor users, and implement data loss prevention (DLP) on web resources. For phishing, our main concern is staying off the known-bad list. That means we need to avoid being crawled by services that might categorize us as malicious and sound the alarm for others before we even send out the phishing campaign. We also need to avoid tell-tails that might trigger a proxy to identify our content as malicious in real time.

Do I Know You?

Have you ever really looked at your logs when you start up a web server? I don’t just mean an Apache access log. I mean full request URLs, queries, headers, and bodies. Within minutes of opening port 80 or 443, you will see traffic from a variety of internet addresses. If you scrutinize the traffic and its intent, you will see that they are generally asking one of two questions:

1. What are you?
2. Can I exploit you?

You didn’t tell anyone that you were starting a website or what domain you just bought, but the traffic shows up right away just the same. How could this be? Well, it turns out that with modern networking speeds, it really isn’t all that expensive or time consuming to scan the whole public IPv4 range for a few common ports like 80 and 443. Open-source tools like Zmap tout the ability to scan the full IPv4 range in just five minutes:

https://zmap.io/

Because of this, both researchers and black hat hackers are constantly running their own internet “surveys” looking to identify and fingerprint open web ports. For research projects, like Shodan and Project Sonar, benign HTTP requests are used to interrogate open web servers to catalog each web service. Black hat hackers, on the other hand, will configure their scanners to run exploit checks against each web server, looking for opportunistic wins. Also in the research camp, you will see traffic from security vendors that run internet surveys to identify and block list potential threats based on HTTP response content.

Obviously, if we want our phishing sites to stay off of security vendor block lists, we should be careful not to present “phishy” looking content to just any observer of our websites; especially ones that just discovered our site by scanning our server’s public IP address. Using server name indication (SNI) on our web server, it is easy enough to present a default page when our website is requested using its IP address and only show our phishing page when a request is made for our phishing domain. This will block IP based scanners from seeing our phishing pages. However, this approach is not sufficient on its own. Unfortunately, the moment you register a domain for phishing and set up your phishing site, your domain name will be leaked to the public in two sources:

1. The Internet Corporation for Assigned Names and Numbers (ICANN) Centralized Zone Data Service (CZDS) zone lists: https://czds.icann.org/home
2. Google’s Certificate Transparency service: https://certificate.transparency.dev/

When you register your domain, your domain is added to ICANN’s zone list for your top-level domain. Security product vendors frequently download the updated lists and scan any domains they have not seen yet. In addition, when you register a TLS cert for your website (assuming you are properly protecting your clients’ data by using TLS while phishing), your certificate details will be published by Certificate Transparency. If you haven’t seen the data set before, take a minute to check out Ryan Sears’s Cert Stream project to view a sample of certificate transparency data in real time from a browser:

https://certstream.calidog.io/

You can bet security vendors are also subscribing to the Certificate Transparency feed to identify new domains and subdomains to scan for malicious websites, so configuring SNI is not enough to keep the scanners at bay. Now that we know what we are up against, let’s talk about how to protect our phishing sites.

Avoiding Pitfalls

First, recognize that any website you put out on the internet is going to be scanned. At a minimum, we want to avoid several common pitfalls that will get your phishing site burned immediately.

N00b Mistake 1: Respond with phishing content to every HTTP request

Instead, you should configure your server to deliver benign content by default. Only deliver malicious content when the URL matches specific attributes that you put in your phishing links; for example, a special “GET” parameter that indicates to the server that this is a legitimate click.

N00b Mistake 2: Using new domains for phishing

Instead, whenever possible, it is best to let them sit and deliver benign content for at least a few weeks before using them for phishing. We know that bots are going to crawl our sites, so why not just lay low and give them time to make an incorrect assessment of our domain? It’s always nice to have a solid domain ready to go when you need it, so if you don’t have any “seasoned” domains ready to go at this moment, go ahead and buy a few to start the aging process. You’ll thank me later.

N00b Mistake 3: Listing subdomains in TLS certificate requests

When you list subdomains for your phishing domains in TLS certificate requests, you are giving away unnecessary telemetry to the enemy. Use wildcard certs instead! There are tons of scripts and web server plugins that automate the process for you. Personally, I am a big fan of Caddy because of how easy it makes obtaining and automatically renewing certs:

https://caddyserver.com/

N00b Mistake 4: Phishing content in predictable locations

Don’t serve your malicious content from a predictable or common location; especially not the web root!

NO NO NO:

https://www.myofficeonline.com/index.html

Still NO:

https://www.myofficeonline.com/owa/outlook/logon.html

Decent! Now we’re talking!

https://www.myofficeonline.com/documents/policies/confimation/index.html

Just a couple mkdir commands and we’ve added a ton of additional protection against web crawlers.

N00b Mistake 5: 1-to-1 clones

If you are trying to clone a common login page like Outlook or a VPN gateway, don’t just clone the site. These are dead giveaways! Imagine if a crawler sees a page that looks exactly like Outlook HTML source code, but the server’s response headers show Apache instead of IIS? If that happens, you’re busted! Instead of trying to fix the headers to also blend in, it’s way easier to just change the HTML. The end result just needs to look like the real thing.

Phishing with Images — Just take a screenshot of the page you want to clone, set it as the background for your page, and then position inputs over top! You might have to tweak the styling to adjust for screen size, but this works well for many simple phishing pages. The page will look the same to a human, and completely different to a bot.

Encoded Clones — Use some JavaScript to encode the HTML of a cloned page. Then, deliver the encoded data, alongside a decode function to dynamically print the HTML when the page loads. This requires a little more coding knowledge but is a nice general solution. Here’s a proof-of-concept I whipped up in a few minutes that gzips the HTML of the ‘body’ tag on a page and prints it to the console. The decode script unzips the content that we put in a variable and swaps the current document’s ‘body’:

//Encode Script - Run this from the console on a webpage you want to clone
function _arrayBufferToBase64( buffer ) {
var binary = '';
var bytes = new Uint8Array( buffer );
var len = bytes.byteLength;
for (var i = 0; i < len; i++) {
binary += String.fromCharCode( bytes[ i ] );
}
return window.btoa( binary );
}
function compress(string, encoding) {
const byteArray = new TextEncoder().encode(string);
const cs = new CompressionStream(encoding);
const writer = cs.writable.getWriter();
writer.write(byteArray);
writer.close();
return new Response(cs.readable).arrayBuffer();
}
compress(document.body.innerHTML, 'gzip').then(
  (result)=>console.log(_arrayBufferToBase64(result))
)

//Decode Script - Swap out the content variable with your encoded content, 
//and include this script in your document head
function decompress(byteArray, encoding) {
const cs = new DecompressionStream(encoding);
const writer = cs.writable.getWriter();
writer.write(byteArray);
writer.close();
return new Response(cs.readable).arrayBuffer().then(function (arrayBuffer) {
return new TextDecoder().decode(arrayBuffer);
});
}
function base64ToArrayBuffer(base64) {
var binaryString = atob(base64);
var bytes = new Uint8Array(binaryString.length);
for (var i = 0; i < binaryString.length; i++) {
bytes[i] = binaryString.charCodeAt(i);
}
return bytes.buffer;
}
var content = 'H4sIAAAAAAAACvNITM5WKMlIVQjIScxLLVFUVAQA9yGx4xIAAAA='
decompress(base64ToArrayBuffer(content), 'gzip').then(
 (result)=>document.body.innerHTML=result)
)

Note that this will swap whatever is in the body of the page, so we can put any benign content we want there when the document is delivered to the browser. Because we can’t dynamically modify the ‘head’ tag with JavaScript, you will need to keep that part intact. You might want to obfuscate or minify the contents of the head as well if there are any clear indicators as to what you are spoofing. Here’s a full example with some minified JavaScript:

<html><head>
<title>Example Domain</title>
<script>
function d(e,n){const r=new DecompressionStream(n),t=r.writable.getWriter();return t.write(e),t.close(),new Response(r.readable).arrayBuffer().then((function(e){return(new TextDecoder).decode(e)}))}function b(e){for(var n=atob(e),r=new Uint8Array(n.length),t=0;t<n.length;t++)r[t]=n.charCodeAt(t);return r.buffer}var content="H4sIAAAAAAAACvNITM5WKMlIVQjIScxLLVFUVAQA9yGx4xIAAAA=";d(b(content),"gzip").then((e=>document.body.innerHTML=e));
</script>
</head>
<body>
<div style="">
<h1 style="">Example Domain</h1>
<p style="">Nothing to see here.</p>
</div>
</body></html>

Leveling Up

While avoiding pitfalls will likely be enough to sneak past most web proxies, we can do even better with a couple of tricks.

No Domain Required: Public Hosting

Most phishing sites can be delivered as static files. There are plenty of reputable domains that allow users to publish static content. You could use a content delivery network (CDN), GitHub Pages, Google Docs, Google Apps Script, Vercel, OneDrive, and many others to host phishing documents and sites; then you don’t have to worry so much about your domain’s reputation.

Warning! Keep in mind that phishing is obviously frowned upon by these services, but any domain registrar is also going to frown on what we do as red teamers. At some point, we have to pick who we will potentially offend and live with our choice knowing that we are not the bad guys. In any case, be thoughtful about what account you use knowing that it might get suspended or banned.

Next Level: Phishing with Video

What!?! Is that even possible? Yes, and it’s sick! With a browser-in-the-middle attack, we can phish users with video content. They see a video feed of the real website, and their interactions with the phishing page are reflected back to them through the video. This approach has many benefits, but for the sake of this blog post, just know that the content that is delivered to the end user is not a traditional phishing page at all. It’s a video stream, which makes it very hard for bots to spot that there is anything phishy about the page. To the bot, it just looks like a pretty minimal video player.

I released a tool called CuddlePhish to automate browser-in-the-middle attacks for red teamers. It’s one of my favorite weapons in my phishing arsenal. If you are interested in using browser-in-the-middle, go check out my post on the subject:

https://posts.specterops.io/phishing-with-dynamite-7d33d8fac038

In conclusion

When phishing, we should expect users to be behind a web proxy. With this in mind, we will need to stay off the known-bad lists. By making the contents of our phishing sites and pages as benign as possible, we can trick proxies into thinking we are safe. In general, we should configure our phishing servers to deliver completely harmless content by default so that web crawlers will categorize our domains as safe. In addition, we can make modifications to the HTML of our pages or use advanced attacks like browser-in-the-middle to trick proxies in real time when users click our links.

---

Drink Like a Phish was originally published in Posts By SpecterOps Team Members on Medium, where people are continuing the conversation by highlighting and responding to this story.

The post Drink Like a Phish appeared first on Security Boulevard.