Last updated at Tue, 25 Jul 2017 18:20:47 GMT
This blog post describes a simple phishing attack covered in today's webcast. The goal is to create a fake front-end to an organization's Outlook Web Access portal and convince users to login through this portal. In the course of an authorized security assessment this type of attack provides an initial foot in the door to the target organization and takes few resources to setup.
This technique relies on the following steps:
- Clone the target's existing OWA site to match graphics and versions
- HTTrack or Firefox "Save page as"
- Register a look-alike domain (mail.example.com -> mailexample.com)
- Gandi.net even provides free SSL certificates as part of COM registration
- IDN-style names can make this even harder to identify
- Create a logging page (or just grep web logs for static content)
- Quick and dirty (and insecure) example: https://gist.github.com/1642717
- Rewrite the OWA HTML to change the links/images
- Point the form POST to the real OWA portal
- Modify flogon.js to log prior to re-posting to the real OWA
- Add ProcessForms() and call this in the first line of clkLgn();
- Example:https://gist.github.com/1642673
The result is a site that looks like the original and acts like the original. A bad password takes the user to the real site with the expected error and a correct password takes them to the real site and logs them in. Microsoft could mitigate this by adding CSRF tokens to the form authentication template in OWA. This basic technique was used with both Exchange 2007 and Exchange 2010 OWA installations.
To convince users to access the mis-named site, I typically craft an email with a subject like "Welcome to Outlook Web Access" - pasting in a typical "enrollment" email, linking to the fake portal (with the displayed link pointing to the real portal).Telling the user that they have 24 hours to access the portal to keep their account active may help speed things along as well.
If you conduct this type of phishing attack for another organization, the friendly thing to do is transfer the domain to their IT staff after the conclusion of the test. At the least, it takes a potential phishing domain off a list that a real attacker could draw from.
Happy (legal) phishing,
-HD