Any phishing campaign involving an active incident response element usually requires some evasive steps to prolong its longevity. This often includes being stealthier, performing anti-forensics actions, or avoiding certain tradecraft altogether. Phishing is no different, and is often the most ‘vulnerable’ part of a campaign from an active IR perspective. Using a distributed infrastructure built with independent components helps reduce the risk of the overall architecture being blocked, but individual phishing campaigns are likely to be caught and blocked throughout the duration. The longer we can stretch out the usability of each of those campaigns, the better our chances of gaining access. Using Apache mod_rewrite rules, we can rewrite potential incident responder or security appliance requests to an innocuous website or the target’s real... [Read More]

At times you may find yourself testing an environment comprised of a fair mix of operating systems. Maybe the marketing department is half Windows and half Mac OS X. In these cases, it may not be feasible to determine users’ operating systems via a preliminary phish. OS detection is nothing new. The goal of this method is to allow us to perform detection and proxying in one place while looking as legitimate as possible to the phish victim. No URL changing, no excessive page reloads and refreshes. This detection method is similar to my previous post about redirecting mobile users; however, leveraging JavaScript provides a more reliable method of operating system detection. OS Detector Page The HTML... [Read More]

There have been times when a curious phish recipient or a zealous help desk staff has loaded the phishing link in their browser and decided to take a peek at a higher directory or the root domain. Of course, most times there isn’t much else site to see. In those cases, the chances of being reported to IR went up significantly, sometimes leading to a phishing campaign being blocked. This is where invalid URI redirection comes in handy. We can whitelist resources the Apache server will proxy for the targets and redirect any other requests to the target’s real domain or another page of our choosing. In the demo below, the user navigates to spoofdomain.com/really/long/url.html and is served a page; however, when the user navigates... [Read More]

Often times a corporate internal network is heavily locked down. Workstations are restricted with limited internet access. These controls are often less strict on mobile devices (or sometimes not present), especially with BYOD being implemented more and more. While phishing, Apache access logs often show mobile devices accessing the malicious page, yet no sessions are established. I investigated a number of ways to solve the problem and ultimately landed on using Apache’s Rewrite module. The more I learned about mod_rewrite’s abilities, the more benefit I saw in using Apache redirectors for phishing. This post is the first in a series of posts about solving common problems that plague phishing including users visiting a malicious website on their mobile device, users visiting non-existent resources on our... [Read More]

SMB Relay is a well-known attack that involves intercepting SMB traffic and relaying the NTLM authentication handshakes to a target host. This post assumes you already understand the basics of SMB Relay (if not I highly suggest you check out Mark Baggett’s SANS post SMB Relay Demystified and NTLMv2 Pwnage with Python). SMB Relay has hands down been the most frequent foothold I’ve found on internal network pentests; however, sometimes the users in my broadcast domain don’t seem to have Local Administrator rights on any of the targeted hosts or AV is making the process take a lot longer. This is where Snarf comes to the rescue. I was on a network once where NBNS/LLMNR traffic was infrequent and administrator rights were limited.... [Read More]