ReelPhish: A Real-Time Two-Factor Phishing Tool

Social Engineering and Two-Factor Authentication

Social engineering campaigns are a constant threat to businesses
because they target the weakest chain in security: people. A typical
attack would capture a victim’s username and password and store it for
an attacker to reuse later. Two-Factor Authentication (2FA) or
Multi-Factor Authentication (MFA) is commonly seen as a solution to
these threats.

2FA adds an extra layer of authentication on top of the typical
username and password. Two common 2FA implementations are one-time
passwords and push notifications. One-time passwords are generated by
a secondary device, such as a hard token, and tied to a specific user.
These passwords typically expire within 30 to 60 seconds and cannot be
reused. Push notifications involve sending a prompt to a user’s mobile
device and requiring the user to confirm their login attempt. Both of
these implementations protect users from traditional phishing
campaigns that only capture username and password combinations.

Real-Time Phishing

While 2FA has been strongly recommended by security professionals
for both personal and commercial applications, it is not an infallible
solution. 2FA implementations have been successfully defeated using real-time
phishing techniques
. These phishing attacks involve interaction
between the attacker and victims in real time.

A simple example would be a phishing website that prompts a user for
their one-time password in addition to their username and password.
Once a user completes authentication on the phishing website, they are
presented with a generic “Login Successful” page and the one-time
password remains unused but captured. At this point, the attacker has
a brief window of time to reuse the victim’s credentials before expiration.

Social engineering campaigns utilizing these techniques are not new.
There have been reports of real-time
phishing in the wild
as early as 2010. However, these types of
attacks have been largely ignored due to the perceived difficulty of
launching such attacks. This article aims to change that perception,
bring awareness to the problem, and incite new solutions.

Explanation of Tool

To improve social engineering assessments, we developed a tool –
named ReelPhish – that simplifies the real-time phishing technique.
The primary component of the phishing tool is designed to be run on
the attacker’s system. It consists of a Python script that listens for
data from the attacker’s phishing site and drives a locally installed
web browser using the Selenium
framework
. The tool is able to control the attacker’s web browser
by navigating to specified web pages, interacting with HTML objects,
and scraping content.

The secondary component of ReelPhish resides on the phishing site
itself. Code embedded in the phishing site sends data, such as the
captured username and password, to the phishing tool running on the
attacker’s machine. Once the phishing tool receives information, it
uses Selenium to launch a browser and authenticate to the legitimate
website. All communication between the phishing web server and the
attacker’s system is performed over an encrypted SSH tunnel.

Victims are tracked via session tokens, which are included in all
communications between the phishing site and ReelPhish. This token
allows the phishing tool to maintain states for authentication
workflows that involve multiple pages with unique challenges. Because
the phishing tool is state-aware, it is able to send information from
the victim to the legitimate web authentication portal and vice versa.

Examples

We have successfully used ReelPhish and this methodology on numerous
Mandiant
Red Team
engagements. The most common scenario we have come
across is an externally facing VPN portal with two-factor
authentication. To perform the social engineering attack, we make a
copy of the real VPN portal’s HTML, JavaScript, and CSS. We use this
code to create a phishing site that appears to function like the original.

To facilitate our real-time phishing tool, we embed server-side code
on the phishing site that communicates with the tool running on the
attacker machine. We also set up a SSH tunnel to the phishing server.
When the authentication form on the phishing site is submitted, all
submitted credentials are sent over the tunnel to the tool on the
attacker’s system. The tool then starts a new web browser instance on
the attacker’s system and submits credentials on the real VPN portal.
Figure 1 shows this process in action.


Figure 1: ReelPhish Flow Diagram

We have seen numerous variations of two-factor authentication on VPN
portals. In some instances, a token is passed in a “secondary
password” field of the authentication form itself. In other cases, the
user must respond to a push request on a mobile phone. A user is
likely to accept an incoming push request after submitting credentials
if the phishing site behaved identically to the real site.

In some situations, we have had to develop more advanced phishing
sites that can handle multiple authentication pages and also pass
information back and forth between the phishing web server and the
tool running on the attacking machine. Our script is capable of
handling these scenarios by tracking a victim’s session on the
phishing site and associating it with a particular web browser
instance running on the attacker’s system. Figure 1 shows a general
overview of how our tool would function within an attack scenario.

We are publicly releasing the tool on the FireEye GitHub
Repository
. Feedback, pull requests, and issues can also be
submitted to the Git repository.

Conclusion

Do not abandon 2FA; it is not a perfect solution, but it does add a
layer of security. 2FA is a security mechanism that may fail like any
other, and organizations must be prepared to mitigate the impact of
such a failure.

Configure all services protected by 2FA to minimize attacker impact
if the attacker successfully bypasses the 2FA protections. Lowering
maximum session duration will limit how much time an attacker has to
compromise assets. Enforcing a maximum of one concurrent session per
user account will prevent attackers from being active at the same time
as the victim. If the service in question is a VPN, implement strict
network segmentation. VPN users should only be able to access the
resources necessary for their respective roles and responsibilities.
Lastly, educate users to recognize, avoid, and report social
engineering attempts.

By releasing ReelPhish, we at Mandiant hope to highlight the need
for multiple layers of security and discourage the reliance on any
single security mechanism. This tool is meant to aid security
professionals in performing a thorough penetration test from beginning
to end.

During our Red Team engagements at Mandiant, getting into an
organization’s internal network is only the first step. The tool
introduced here aids in the success of this first step. However, the
overall success of the engagement varies widely based on the target’s
internal security measures. Always work to assess and improve your
security posture as a whole. Mandiant provides a variety of services
that can assist all types of organizations in both of these activities.

Go to Source
Author: Pan Chan

Remote Symbol Resolution

Introduction

The following blog discusses a couple of common techniques that
malware uses to obscure its access to the Windows API. In both forms
examined, analysts must calculate the API start address and resolve
the symbol from the runtime process in order to determine functionality.

After introducing the techniques, we present an open source tool
we developed that can be used to resolve addresses from a process
running in a virtual machine by an IDA script. This gives us an
efficient way to quickly add readability back into the disassembly.

Techniques

When performing an analysis, it is very common to see malware try to
obscure the API it uses. As a malware analyst, determining which API
is used is one of the first things we must resolve in order to
determine the capabilities of the code.

Two common obfuscations we are going to look at in this blog are
encoded function pointer tables and detours style hook stubs. In both
of these scenarios the entry point to the API is not directly visible
in the binary.

For an example of what we are talking about, consider the code in
Figure 1, which was taken from a memory dump of xdata crypto
ransomware sample C6A2FB56239614924E2AB3341B1FBBA5.

Figure 1: API obfuscation code from a crypto
ransomware sample

In Figure 1, we see one numeric value being loaded into eax, XORed
against another, and then being called as a function pointer. These
numbers only make sense in the context of a running process. We can
calculate the final number from the values contained in the memory
dump, but we also need a way to know which API address it resolved to
in this particular running process. We also have to take into account
that DLLs can be rebased due to conflicts in preferred base address,
and systems with ASLR enabled.

Figure 2 shows one other place we can look to see where the values
were initially set.

Figure 2: Crypto malware setting obfuscated
function pointer from API hash

In this case, the initial value is loaded from an API hash lookup –
again not of immediate value. Here we have hit a crossroad, with
multiple paths we can take to resolve the problem. We can search for a
published hash list, extract the hasher and build our own database, or
figure out a way to dynamically resolve the decoded API address.

Before we choose which path to take, let us consider another sample.
Figure 3 shows code from Andromeda sample, 3C8B018C238AF045F70B38FC27D0D640.

Figure 3: API redirection code from an Andromeda sample

This code was found in a memory injection. Here we can see what
looks to be a detours style trampoline, where the first instruction
was stolen from the actual Windows API and placed in a small stub with
an immediate jump taken back to the original API + x bytes.

In this situation, the malware accesses all of the API through these
stubs and we have no clear resolution as to which stub points where.
From the disassembly we can also see that the stolen instructions are
of variable length.

In order to resolve where these functions go, we would have to:

  • enumerate all of the stubs
  • calculate how many bytes
    are in the first instruction
  • extract the jmp address
  • subtract the stolen byte count to find the API entrypoint
  • resolve the calculated address for this specific process
    instance
  • rename the stub to a meaningful value

In this sample, looking for cross references on where the value is
set does not yield any results.

Here we have two manifestations of essentially the same problem. How
do we best resolve calculated API addresses and add this information
back into our IDA database?

One of the first techniques used was to calculate all of the final
addresses, write them to a binary file, inject the data into the
process, and examine the table in the debugger (Figure 4). Since the
debugger already has a API address look up table, this gives a crude
yet quick method to get the information we need.

Figure 4: ApiLogger from iDefense MAP injecting
a data file into a process and examining results in debugger

From here we can extract the resolved symbols and write a script to
integrate them into our IDB. This works, but it is bulky and involves
several steps.

Our Tool

What we really want is to build our own symbol lookup table for a
process and create a streamlined way to access it from our scripts.

The first question is: How can we build our own lookup table of API
addresses to API names? To resolve this information, we need to follow
some steps:

  • enumerate all of the DLLs loaded into a process
  • for
    each DLL, walk the export table and extract function name and
    RVA
  • calculate API entrypoint based on DLL base address and
    export RVA
  • build a lookup table based on all of this
    information

While this sounds like a lot of work, libraries are already
available that handle all of the heavy lifting. Figure 5 shows a
screenshot of a remote lookup
tool
we developed for such occasions.

Figure 5: Open source remote lookup application

In order to maximize the benefits of this type of tool, the tool
must be efficient. What is the best way to interface with this data?
There are several factors to consider here, including how the data is
submitted, what input formats are accepted, and how well the tool can
be integrated with the flow of the analysis process.

The first consideration is how we interface with it. For maximum
flexibility, three methods were chosen. Lookups can be submitted:

  • individually via textbox
  • in bulk by file or
  • over the network by a remote client

In terms of input formats, it accepts the following:

  • hex memory address
  • case insensitive API name
  • dll_name@ordinal
  • dll_name.export_name

The tool output is in the form of a CSV list that includes address,
name, ordinal, and DLL.

With the base tool capabilities in place, we still need an efficient
streamlined way to use it during our analysis. The individual lookups
are nice for offhand queries and testing, but not in bulk. The bulk
file lookup is nice on occasion, but it still requires data
export/import to integrate results with your IDA database.

What is really needed is a way to run a script in IDA, calculate the
API address, and then resolve that address inline while running an IDA
script. This allows us to rename functions and pointers on the fly as
the script runs all in one shot. This is where the network client
capability comes in.

Again, there are many approaches to this. Here we chose to integrate
a network client into a beta of IDA Jscript (Figure 6). IDA Jscript is
an open source IDA scripting tool with IDE that includes syntax
highlighting, IntelliSense, function prototype tooltips, and debugger.

Figure 6: Open source IDA Jscript decoding and
resolving API addresses

In this example we see a script that decodes the xdata pointer
table, resolves the API address over the network, and then generates
an IDC script to rename the pointers in IDA.

After running this script and applying the results, the decompiler
output becomes plainly readable (Figure 7).

Figure 7: Decompiler output from the xdata
sample after symbol resolution

Going back to the Andromeda sample, the API information can be
restored with the brief idajs script shown in Figure 8.

Figure 8: small idajs script to remotely resolve
and rename Andromeda API hook stubs

For IDAPython users, a python remote lookup client is also available.

Conclusion

It is common for malware to use techniques that mask the Windows API
being used. These techniques force malware analysts to have to extract
data from runtime data, calculate entry point addresses, and then
resolve their meaning within the context of a particular running process.

In previous techniques, several manual stages were involved that
were bulky and time intensive.

This blog introduces a small simple open source tool that can
integrate well into multiple IDA scripting languages. This combination
allows analysts streamlined access to the data required to quickly
bypass these types of obfuscations and continue on with their analysis.

We are happy to be able to open source the remote lookup application
so that others may benefit and adapt it to their own needs. Sample
network clients have been provided for Python, C#, D, and VB6.

Download a copy of
the tool
today.

Go to Source
Author: David Zimmer

Evolving Analytics for Execution Trace Data

Evolving Analytics for Execution Trace Data

Five years ago, Mandiant released a proof of concept tool named
ShimCacheParser, along with a blog post titled “Leveraging
the Application Compatibility Cache in Forensic Investigations
”.
Since then, ShimCache metadata has become increasingly popular as a
source of forensic evidence, both for standalone analysis and
enterprise intrusion investigations.

While five years may seem like a long time, few community efforts
have focused on leveraging ShimCache metadata at an enterprise scale.
Today, we intend to fix that with the release of a new tool called AppCompatProcessor.

AppCompatProcessor started as a simple tool to automate
ShimCacheParser execution on enterprise-wide investigations,
leveraging Python’s multiprocessing module to speed up the parsing
process. Later, it evolved to support faster regular expression
searching and has continued to evolve ever since. Today, it handles
both AppCompat and AmCache artifacts, has modules for processing more
than 11 different formats, and contains some novel analytics to
redefine the way we look at execution trace artifacts.

Available ‘Modules’ in the Initial Release

Upon execution, AppCompatProcessor (ACP) enumerates all the
available commands we refer to as ‘modules’, as seen in Figure 1.

Figure 1: List of commands and modules

Investigators will likely use ‘load’, ‘status’, ‘list’ and
‘dump’
 first. These will enable you to ingest data and enumerate
loaded hosts or dump the data for a specific host in the database.

Once you have ingested your data, the ‘search’ module will
enable you to search against a list of known-bad regular expressions
as part of your triaging or hunting methodology. The module will also
enable you to perform enterprise-wide string literal or regex searches
from CLI.

Regular expression searching leverages multiprocessing “under the
hood”. However, for simple literal string searches, the
fsearch’ module will automatically use the available indexes
to provide investigators with virtually immediate results.

The ‘Search’ and ‘FSearch’ functions empower an investigator to
search across the enterprise and much more. Perhaps you have found a
dropper and need to know the other systems it was executed on. Perhaps
an attacker is randomizing versioning information for binaries (stored
in AmCache), which is predictable. Perhaps the attacker has only been
active during specific timeframes. These objectives, and many more,
are capable using AppCompatProcessor. Due to the number of analysis
features offered by this tool, we will only discuss a subset of them.
Check the GitHub
page
for a more detailed description of each feature.


leven’
: Based on the Levenshtein
distance algorithm
, which measures the ‘edit distance’ between
two strings, the module will identify small deviations from any known
legitimate filename present in the WindowsSystem32 folder on your
dataset. ‘svchosts.exe’, ‘svch0st.exe’, ‘scvhost.exe’ – how many of
those do we have to search for? None. ‘leven’ will spot all of
them, as well as any other possible variation, and will do so for all
legitimate file names and conveniently report them for you to
investigate. You can also run the ‘leven’ module with a
user-supplied filename. In that case, ACP will report all small
deviations in your dataset, regardless of the folder those files are
found in. This is an effective technique for spotting attacker
intentional or unintended typos during an investigation.

Figure 2: High level explanation of how temporal
execution strength is calculated


tcorr’
: This module is based on a Temporal Correlation
execution engine, as shown in Figure 2. You supply a file name to it,
and it will determine what other files were executed before and after
(within a user configurable window). It calculates a correlation
‘strength’ index, which it uses to display the list of files that
present the strongest temporal execution correlation indexes with your
file name of interest. It will also automatically calculate if the
correlation is mutual by calculating the inverse correlation index,
which it will report as an ‘Inverse Bond’. ‘tcorr’ is great way
to triage suspicious files, or to easily find additional attacker
files as the investigation progresses. As a simple example, Figure 3
illustrates the results generated by ‘tcorr’ for “net.exe”. The
results provided evidence of the well-known fact that “net.exe” will
always execute “net1.exe”, resulting in a very strong temporal
execution correlation between both.

Figure 3: Explained output of “tcorr net.exe” command


tstack’
: Investigators often question if they’ve
overlooked some detail as a result of an attacker deviating from
observed TTPs. Time stacking analytics have been designed to provide
you with the list of file names that have predominantly executed
within, or close to, the supplied attacker’s time frame of activity,
as seen in Figure 4. As the technique is inherently most effective for
narrow time intervals, investigators will want to focus around the
time frames associated with attacker lateral movement.

Figure 4: Time Stacking calculation

Conclusion

One of the main reasons for the Open Source release of ACP is to
provide a framework for the community at large to delve into advanced
analytics. Having a tool available that automates some of the analysis
of ShimCache and AmCache artifacts at enterprise scale should lower
the entry barrier for investigators interested in developing advanced
analytics. There’s a tremendous amount of untapped value on advanced
execution trace analytics. The examples presented here, while
immediately useful, are just the beginning.

Download AppCompatProcessor today.

Five years ago, Mandiant released a proof of concept tool named
ShimCacheParser, along with a blog post titled “Leveraging
the Application Compatibility Cache in Forensic Investigations
”.
Since then, ShimCache metadata has become increasingly popular as a
source of forensic evidence, both for standalone analysis and
enterprise intrusion investigations.

While five years may seem like a long time, few community efforts
have focused on leveraging ShimCache metadata at an enterprise scale.
Today, we intend to fix that with the release of a new tool called AppCompatProcessor.

AppCompatProcessor started as a simple tool to automate
ShimCacheParser execution on enterprise-wide investigations,
leveraging Python’s multiprocessing module to speed up the parsing
process. Later, it evolved to support faster regular expression
searching and has continued to evolve ever since. Today, it handles
both AppCompat and AmCache artifacts, has modules for processing more
than 11 different formats, and contains some novel analytics to
redefine the way we look at execution trace artifacts.

Available ‘Modules’ in the Initial Release

Upon execution, AppCompatProcessor (ACP) enumerates all the
available commands we refer to as ‘modules’, as seen in Figure 1.

Figure 1: List of commands and modules

Investigators will likely use ‘load’, ‘status’, ‘list’ and
‘dump’
 first. These will enable you to ingest data and enumerate
loaded hosts or dump the data for a specific host in the database.

Once you have ingested your data, the ‘search’ module will
enable you to search against a list of known-bad regular expressions
as part of your triaging or hunting methodology. The module will also
enable you to perform enterprise-wide string literal or regex searches
from CLI.

Regular expression searching leverages multiprocessing “under the
hood”. However, for simple literal string searches, the
fsearch’ module will automatically use the available indexes
to provide investigators with virtually immediate results.

The ‘Search’ and ‘FSearch’ functions empower an investigator to
search across the enterprise and much more. Perhaps you have found a
dropper and need to know the other systems it was executed on. Perhaps
an attacker is randomizing versioning information for binaries (stored
in AmCache), which is predictable. Perhaps the attacker has only been
active during specific timeframes. These objectives, and many more,
are capable using AppCompatProcessor. Due to the number of analysis
features offered by this tool, we will only discuss a subset of them.
Check the GitHub
page
for a more detailed description of each feature.


leven’
: Based on the Levenshtein
distance algorithm
, which measures the ‘edit distance’ between
two strings, the module will identify small deviations from any known
legitimate filename present in the WindowsSystem32 folder on your
dataset. ‘svchosts.exe’, ‘svch0st.exe’, ‘scvhost.exe’ – how many of
those do we have to search for? None. ‘leven’ will spot all of
them, as well as any other possible variation, and will do so for all
legitimate file names and conveniently report them for you to
investigate. You can also run the ‘leven’ module with a
user-supplied filename. In that case, ACP will report all small
deviations in your dataset, regardless of the folder those files are
found in. This is an effective technique for spotting attacker
intentional or unintended typos during an investigation.

Figure 2: High level explanation of how temporal
execution strength is calculated


tcorr’
: This module is based on a Temporal Correlation
execution engine, as shown in Figure 2. You supply a file name to it,
and it will determine what other files were executed before and after
(within a user configurable window). It calculates a correlation
‘strength’ index, which it uses to display the list of files that
present the strongest temporal execution correlation indexes with your
file name of interest. It will also automatically calculate if the
correlation is mutual by calculating the inverse correlation index,
which it will report as an ‘Inverse Bond’. ‘tcorr’ is great way
to triage suspicious files, or to easily find additional attacker
files as the investigation progresses. As a simple example, Figure 3
illustrates the results generated by ‘tcorr’ for “net.exe”. The
results provided evidence of the well-known fact that “net.exe” will
always execute “net1.exe”, resulting in a very strong temporal
execution correlation between both.

Figure 3: Explained output of “tcorr net.exe” command


tstack’
: Investigators often question if they’ve
overlooked some detail as a result of an attacker deviating from
observed TTPs. Time stacking analytics have been designed to provide
you with the list of file names that have predominantly executed
within, or close to, the supplied attacker’s time frame of activity,
as seen in Figure 4. As the technique is inherently most effective for
narrow time intervals, investigators will want to focus around the
time frames associated with attacker lateral movement.

Figure 4: Time Stacking calculation

Conclusion

One of the main reasons for the Open Source release of ACP is to
provide a framework for the community at large to delve into advanced
analytics. Having a tool available that automates some of the analysis
of ShimCache and AmCache artifacts at enterprise scale should lower
the entry barrier for investigators interested in developing advanced
analytics. There’s a tremendous amount of untapped value on advanced
execution trace analytics. The examples presented here, while
immediately useful, are just the beginning.

Download AppCompatProcessor today.

Go to Source
Author: Matias Bevilacqua

Powered by WPeMatico