Hacking the PS4, part 3 – Kernel exploitation
Hacking the PS4, part 3 – Kernel exploitation
In many cases Red Team tools are not written because someone feels
like writing a tool, or wakes up one morning thinking, “I want to
write a tool today”. Red Teamers generally identify tedious tasks in
their methodology and then create tools that automate these tasks for
current and future assessments. As my boss likes to say, jokingly:
laziness breeds ingenuity!
At Mandiant, we’ve developed (or significantly contributed to) a
fair number of tools and scripts to make our lives easier. In order to
ensure the broader security community is aware of these tools and
where to download them from, we’re going to start releasing a “tool
roundup” blog post on a semi-regular basis. The intent of these blog
posts is to highlight newly developed tools, or major changes to
existing tools. We also make this a fun read by including some case
studies to demonstrate tool use.
Team is frequently introduced to diverse networks, technologies,
defenses, and organizational structures. Each network presents new
challenges that must be overcome, and with all clients, there is
overlap with infrastructure and configuration. Existing public tools
might not scale properly in larger environments or might not help the
Red Team address specific phases of an attack
life cycle. The tools being discussed have all been revised or
developed in some form or fashion over the last couple of months. We
hope they make your engagements easier and bring awareness to the community.
Tool: ADEnumerator (https://github.com/chango77747/AdEnumerator)
Domain enumeration is an essential task during the reconnaissance
phase of the attack life cycle. When you compromise a domain-joined
system, it is fairly simple to enumerate objects from the domain using
Active Directory Service Interfaces (ADSI) or the Windows “net”
commands. ADSI works well from non-domain joined systems using the
“runas” command with the “netonly” switch, as shown in Figure 1. It
can be a hassle to craft detailed LDAP queries for ADSI to perform
domain enumeration, so we automated this processing using raw LDAP
queries in a tool called ADEnumerator.
Figure 1. Using PowerShell and ADSI for domain enumeration
ADEnumerator is a PowerShell module designed to query Active
Directory servers from non-domain systems. The following use cases
apply to ADEnumerator:
Figure 2 demonstrates importing the ADEnumerator.psm1 module,
establishing an LDAP connection to a domain controller, and executing
various domain enumeration methods. There are plenty of additional
methods within ADEnumerator – see the header of the script for a full
list of methods.
Figure 2. ADEnumertor.psm1 import and enumeration
Alternatively, you can install Remote
Server Administration Tools on your attack platform and use
“runas” to execute “mmc” and add the Active Directory snap-in. Then
you can change the domain to your target domain and view the entire
Active Directory structure in a GUI, as shown in Figure 3.
Figure 3. Active Directory snap-in running as
Tools: CredNinja (https://github.com/Raikia/CredNinja) & WMIOps (https://github.com/ChrisTruncer/WMIOps)
Have you been in a situation where you have a list of more than 100
credentials, but you are not sure which credentials are valid? Or,
you’re not sure which credentials have administrative rights to a
target system? CredNinja was created for just that (and it can do
more!). Use cases and general functionality are as follows:
o Logon Failure – Invalid credentials (protection against
locking out accounts included)
o Access Denied – Not
o File listing – Local admin!
CredNinja is very useful when performing privilege escalation and
lateral movement because you can identify systems for which your
credentials have elevated privileges, and continue dumping credentials
on those systems. Figure 4 demonstrates the power of CredNinja by
identifying various systems where the domain credentials have local
administrator rights, and whether or not credentials are invalid.
CredNinja can also be run against a single system to clean up your
credential list by removing invalid credentials.
Figure 4. CredNinja run against various systems
using credential list
Windows Management Instrumentation (WMI) is the new hotness
in terms of offensive capabilities. WMIOps is a PowerShell script that
uses WMI to perform a variety of actions on hosts, local or remote,
within a Windows environment. It was designed primarily for use on
penetration tests or Red Team engagements. Some existing tools use WMI
for offensive tasks; WMIOps was built to combine these techniques into
a single tool to accomplish various tasks in the attack life cycle.
Figure 5 shows the Get-ProcessOwnersWMI method in WMIOps to get a
list of users from target system Win7-Client02. User “Dick.Grayson”
had local administrator privileges on Win7-Client02 and was authorized
to execute arbitrary WMI commands. User “Bruce.Wayne” had running
processes on Win7-Client02, which indicates that the user potentially
has clear text credentials stored in Local Security Authority
Subsystem Service (LSASS).
To obtain credentials for “Bruce.Wayne”, WMIOps method
Invoke-RemoteScriptWithOutput is used in Figure 6 to execute a remote
PowerShell process that issues command “Invoke-Expression” to download
and execute the “Invoke-Mimikatz” script over HTTPS. The command also
instructs the output to be sent to web server 10.181.73.210 listening
on HTTPS. Mimikatz output was sent to the web server, as shown in
Figure 5. Get-ProcessOwnersWMI method in WMIOps
to get a list of users with running processes
Figure 6. Invoke-RemoteScriptWithOutput method
to call Invoke-Mimikatz and send output to the “callbacksite”
Figure 7. Mimikatz output sent from the command
executed in Figure 4
Tool: EyeWitness (https://github.com/ChrisTruncer/EyeWitness)
One of the most common initial vectors into a network is default
credentials to known web administrative portals such as Jboss, Apache
Tomcat, Jenkins, etc. EyeWitness is known to scale networks by taking
screenshots of the web page of each web server identified in your
reconnaissance phase. We added an “active-scan” module to EyeWitness
that provides the following functionalities:
The “active-scan” Boolean flag is shown in Figure 8. Example report
and console output is shown in Figure 9 and Figure 10. An additional
category called “Identified Logins” is also added to the report if
EyeWitness identified a login, but was not able to authenticate to it.
If you want to learn more about this module, a full blog post on this
module was written here: https://www.christophertruncer.com/eyewitness-and-active-account-enumeration/.
Figure 8. Active-scan flag in EyeWitness
Figure 9. Successful authentication using the
Figure 10. EyeWitness report output
Tool: Egress-Assess (https://github.com/ChrisTruncer/Egress-Assess)
The combined capabilities of Mandiant, FireEye, and iSIGHT Partners
brings unparalleled threat intelligence and technology to every
engagement. Clients regularly ask us to identify threat actors
targeting their industry specifically and to emulate their TTPs to
assess the organization’s current detection capabilities.
Egress-Assess is a Python tool that was created to emulate known
attacker TTPs, such as IP addresses and Fully Qualified Domain Names
(FQDNs) connecting to the Internet. Egress-Assess is publicly
available; however, Mandiant maintains a proprietary version of
Egress-Assess that contains known network-based indicators (NBIs) that
replicate real threat groups.
Egress-Assess modifies the host value in the HTTP(s) header request
to be a known-bad IP address or FQDN, and generates web requests to
known-bad URIs. Furthermore, the tool can generate fake PII, PHI, or
PCI data to emulate data theft. We use Egress-Assess to assess our
client’s detection capabilities by emulating real threat group
indicators and/or data theft. A list of supported threat actor groups
available in the public version of Egress-Assess is shown in Figure
11. If you want to learn more about this Egress-Assess, a full blog
post on this module was written here: https://www.christophertruncer.com/egress-assess-testing-egress-data-detection-capabilities/.
Figure 11. List of threat actors available in Egress-Assess
These are just a handful of tools and practical examples of using
those tools for Red Team operations. We encourage you to play with
these tools and start using them on your assessments or in your labs.
We want to reemphasize that each tool was created or modified as the
need was identified. It can be very exciting to identify a need and
develop tools and techniques to automate a task or accomplish an
objective. Some tools introduce new techniques to accomplish a goal,
while other tools simply automate existing tools and techniques to
scale better. Whatever your motive, introducing new tools and
techniques is an excellent way to provide awareness in our industry
and generate higher quality security.
Websphere/JBoss/OpenNMS/Symantec Endpoint Protection Manager – Java Deserialization Remote Code Execution
FireEye has identified a campaign involving phishing websites that
appear as legitimate Amazon sites. Amazon is the largest online
retailer and threat actors frequently target its customers. In this
attack, a person browsing the internet would be directed to authentic
looking – yet fake – Amazon webpages that request a variety of
information, including Amazon credentials, home address and payment
card data. Any information entered into the phishing websites could be
sent to the attackers and potentially used to make fraudulent charges
and commit other crimes.
FireEye detected this phishing campaign through our email MPS
platform and has seen attacks primarily targeting Amazon customers in
the U.S., Canada and Europe. FireEye has made Amazon.com aware of this
phishing campaign. In addition to aggressively investigating all suspicious
email reports, Amazon.com provides resources for customers to identify
whether an email is from Amazon.com and to protect
While there have been numerous reports on Amazon phishing attacks in
the past, this campaign is particularly interesting for security
analysts because of the evasion techniques being used by the
attackers. Though various instances of this phishing practice have
been previously used, we’ve been following this particular campaign
variant since June 21, 2016. Some of the evasion techniques used in
this campaign include:
After clicking the initial URL, the user is redirected to the
phishing template page hosted on another compromised site. The
campaign is browser-aware in terms of the URL it displays in the
browser. Hexadecimal encoded domains are displayed when Firefox or
Safari are used while clear text is displayed in Chrome. An example
rendering is shown in Figure 1.
Figure 1. Initial Phishing Page
To the user, the page appears to be a legitimate Amazon login page.
Behind the scenes, however, numerical HTML encoding of Unicode
characters are prevalent throughout the page serving up the fake
Amazon login page, as shown in Figure 2. This tactic helps to evade
Figure 2. Numerical HTML encoding of Unicode
Characters in the Amazon phishing page.
The malicious actor behind this phishing campaign regularly updated
connect.php on the initial compromised host. The purpose of the
initial host is to redirect users to infected machines hosting
phishing sites where the phishing template page has been uploaded. As
these endpoint phishing sites get taken down, a new one is established
and the redirection page is modified to point to the new phishing page location.
Figure 3 shows an example of a complete redirection chain.
Figure 3. Redirection Chain example
After the initial redirection to the second URL in the chain, the
first thing the server does is include an anti-detection module. This
anti-detection module blocks certain IPs, including search engines
such as Google, anti-phishing tools such as Netcraft, and other
network service providers. This makes the website not detectable by
bots by returning a 404 Not Found page instead of continuing
redirection to the phishing template. An example of the extracted IP
based anti-detection code is shown in Figure 4.
Figure 4. IP based anti-detection code
The next action the server takes if their IP is not banned is to
record a log of the victims who visit the page. Code extracted shows
that the logging includes the visitor’s IP, user-agent, operating
system, browser, hostname and referer information, as shown in Figure 5.
Figure 5. Visitor tracking code
Figure 6 shows the debug log file left by the template writer.
Figure 6. Debug log file
After logging the user information, code is executed to create a
random md5 hash path name for the phishing page that will ultimately
be served to the end user. After all resources are copied to the
random path, the server redirects the visitor to this path
(redirections 3 through 5 in Figure 3), thus rendering the actual
phishing page in the user’s browser. The code responsible for
generating the random path is shown in Figure 7.
Figure 7. Path randomization code
At this point, the initial phishing template page shown in Figure 1
is rendered in the user’s browser. After entering their initial login
credentials, the user is taken through a series of two more pages
shown in Figure 8 and Figure 9. This is to harvest address and billing information.
Figure 8. Fake Address Verification Page
Figure 9. Fake Billing Information Page
After the victim has entered all the requested information, the
server sends an email containing the information to the attacker’s
email address and redirects the user to the real Amazon webpage.
The code shown in Figure 10 is the code that builds the email
message sent to the phisher.
Figure 10. Email building code
The victim’s information is contained in the $message variable that
is built from the user’s responses to the pages shown in Figure 8 and
Figure 9. Figure 11 shows the code that builds the message contents,
which contains the harvested user’s information.
Figure 11. Message building code
After the harvested credentials are emailed to the attackers, the
user is sent a final redirection to the legitimate Amazon page. The
code behind this redirection is shown in Figure 12.
Figure 12. Final redirection
Detecting these types of threats can be tricky, particularly when
the attacker is leveraging some interesting evasion techniques.
Oftentimes users are redirected to phishing pages after clicking on a
malicious link. FireEye recommends that users exercise caution when
clicking on links from untrusted parties, avoid opening emails from
unknown senders, and be wary of emails from anyone requesting
personally identifiable information. Additionally, and most
importantly, users should only log into Amazon by visiting the website directly.
Ransomware is a common method of cyber extortion for financial gain
that typically involves users being unable to interact with their
files, applications or systems until a ransom is paid. Accessibility
of cryptocurrency such as Bitcoin has direc…
A security researcher recently published source code
for a working exploit for CVE-2016-0189 and the Neutrino Exploit Kit
(EK) quickly adopted it.
CVE-2016-0189 was originally exploited as a zero-day vulnerability
attacks in Asia. The vulnerability resides within scripting
engines in Microsoft’s Internet Explorer (IE) browser, and is
exploited to achieve Remote Code Execution (RCE). According to the
researcher’s repository, the open source exploit affects IE on at
least Windows 10. It is possible that attackers could use or repurpose
the attack for earlier versions of Windows.
Microsoft patched CVE-2016-0189
in May on Patch Tuesday. Applying this patch will protect a
system from this exploit.
The popular Neutrino EK was quick to adopt this exploit. Neutrino
works by embedding multiple exploits into one Shockwave Flash (SWF)
file. Once run, the SWF profiles the victim’s system – shown in Figure
1 – to determine which of its embedded exploits to use.
Figure 1. Neutrino EK SWF profiles a victim
Next, it decrypts and runs the applicable exploit, as shown in
Figure 2. This is different from most other EKs, in which an earlier
exploits from the server.
Figure 2. Decrypt and embed the selected exploit
into an iframe
In this example, Neutrino embedded exploits for five vulnerabilities
that have been patched since May or earlier: three for Adobe Flash
Player (CVE-2016-4117, CVE-2016-1019, CVE-2015-8651) and two for
Internet Explorer (CVE-2016-0189, CVE-2014-6332). CVE-2016-0189 is the
newest addition to Neutrino’s arsenal.
This CVE-2016-0189 vulnerability stems from a failure to put a lock
on an array before working on it. This omission can lead to an issue
when the array is changed while another function is in the middle of
working on it. Memory corruption can occur if the “valueOf “ property
of the array is set to a script function that changes the array size,
as shown in Figure 3.
Figure 3. Neutrino setting triggering conditions
After Microsoft released the patch, a security researcher compared
the original and patched programs to identify the root cause of the
vulnerability and create a fully functioning exploit. The exploit
embedded within Neutrino is identical to this researcher’s exploit,
except for the code that runs after initial control.
Reports of a Zero-day attack affecting numerous Office 365 users emerged late last month (hat tip to the researchers at Avanan), and the culprit was a new variant of the Cerber ransomware discovered earlier this year. As with the other Zero-day threats that have been popping-up like mushrooms of late, the main methods of infection […]
Hacking the PS4, part 2 – Userland code execution
Python smtplib 2.7.11 / 3.4.4 / 3.5.1 – Man In The Middle StartTLS Stripping