APT37 (Reaper): The Overlooked North Korean Actor

On Feb. 2, 2018, we published a blog
detailing the use of an Adobe Flash zero-day
vulnerability (CVE-2018-4878) by a suspected North Korean cyber
espionage group that we now track as APT37 (Reaper).

Our analysis of APT37’s recent activity reveals that the group’s
operations are expanding in scope and sophistication, with a toolset
that includes access to zero-day vulnerabilities and wiper malware. We
assess with high confidence that this activity is carried out on
behalf of the North Korean government given malware development
artifacts and targeting that aligns with North Korean state interests.
FireEye iSIGHT Intelligence believes that APT37 is aligned with the
activity publicly reported as Scarcruft
and Group123.

Read our report,
APT37
(Reaper): The Overlooked North Korean Actor, to learn more
about our assessment that this threat actor is working on behalf of
the North Korean government, as well as various other details about
their operations:

• Targeting: Primarily South Korea – though also Japan, Vietnam
  and the Middle East – in various industry verticals, including
  chemicals, electronics, manufacturing, aerospace, automotive, and
  healthcare.
• Initial Infection Tactics: Social engineering tactics
  tailored specifically to desired targets, strategic web compromises
  typical of targeted cyber espionage operations, and the use of
  torrent file-sharing sites to distribute malware more
  indiscriminately.
• Exploited Vulnerabilities: Frequent exploitation of
  vulnerabilities in Hangul Word Processor (HWP), as well as Adobe
  Flash. The group has demonstrated access to zero-day vulnerabilities
  (CVE-2018-0802), and the ability to incorporate them into
  operations.
• Command and Control Infrastructure: Compromised servers,
  messaging platforms, and cloud service providers to avoid detection.
  The group has shown increasing sophistication by improving their
  operational security over time.
• Malware: A diverse suite of malware for initial intrusion and
  exfiltration. Along with custom malware used for espionage purposes,
  APT37 also has access to destructive malware.

More information on this threat actor is found in our report,
APT37
(Reaper): The Overlooked North Korean Actor. You can also
register
for our upcoming webinar for additional insights into this group.

The post APT37 (Reaper): The Overlooked North Korean Actor appeared first on Security Boulevard.

from APT37 (Reaper): The Overlooked North Korean Actor

CVE-2017-10271 Used to Deliver CryptoMiners: An Overview of Techniques Used Post-Exploitation and Pre-Mining

Introduction

FireEye researchers recently observed threat actors abusing
CVE-2017-10271 to deliver various cryptocurrency miners.

CVE-2017-10271 is a known input validation vulnerability that exists
in the WebLogic Server Security Service (WLS Security) in Oracle
WebLogic Server versions 12.2.1.2.0 and prior, and attackers can
exploit it to remotely execute arbitrary code. Oracle released a Critical
Patch Update that reportedly fixes this vulnerability. Users who
failed to patch their systems may find themselves mining
cryptocurrency for threat actors.

FireEye observed a high volume of activity associated with the
exploitation of CVE-2017-10271 following the public posting of proof
of concept code in December 2017. Attackers leveraged this
vulnerability to subsequently download cryptocurrency miners in victim
environments. The recent cryptocurrency boom has resulted in a growing
number of operations – employing diverse tactics – aimed at stealing
cryptocurrencies. The idea that these cryptocurrency mining operations
are less risky, along with the potentially nice profits, could lead
cyber criminals to begin shifting away from ransomware campaigns.

Tactic #1: Delivering the miner directly to a vulnerable server

Some tactics we've observed involve exploiting CVE-2017-10271,
leveraging PowerShell to download the miner directly onto the victim’s
system (Figure 1), and executing it using ShellExecute().

Figure 1: Downloading the payload directly

Tactic #2: Utilizing PowerShell scripts to deliver the miner

Other tactics involve the exploit delivering a PowerShell script,
instead of downloading the executable directly (Figure 2).

Figure 2: Exploit delivering PowerShell script

This script has the following functionalities:

• Downloading miners from remote servers

Figure 3: Downloading cryptominers

As shown in Figure 3, the .ps1 script
tries to download the payload from the remote server to a vulnerable server.

• Creating scheduled tasks for persistence

Figure 4: Creation of scheduled task

• Deleting scheduled tasks of other known cryptominers

Figure 5: Deletion of scheduled tasks
related to other miners

In Figure 4, the cryptominer creates a
scheduled task with name “Update service for Oracle
products1”.  In Figure 5, a different variant deletes this task
and other similar tasks after creating its own, “Update service for
Oracle productsa”.  

From this, it’s quite clear that
different attackers are fighting over the resources available in the system.

• Killing processes matching certain strings associated with other
  cryptominers

Figure 6: Terminating processes directly

Figure 7: Terminating processes matching
certain strings

Similar to scheduled tasks deletion,
certain known mining processes are also terminated (Figure 6 and
Figure 7).

• Connects to mining pools with wallet key

Figure 8: Connection to mining pools

The miner is then executed with
different flags to connect to mining pools (Figure 8). Some of the
other observed flags are: -a for algorithm, -k for keepalive to
prevent timeout, -o for URL of mining server, -u for wallet key, -p
for password of mining server, and -t for limiting the number of miner threads.

• Limiting CPU usage to avoid suspicion

Figure 9: Limiting CPU Usage

To avoid suspicion, some attackers are
limiting the CPU usage of the miner (Figure 9).

Tactic #3: Lateral movement across Windows environments using
Mimikatz and EternalBlue

Some tactics involve spreading laterally across a victim’s
environment using dumped Windows credentials and the EternalBlue vulnerability
(CVE-2017-0144).

The malware checks whether its running on a 32-bit or 64-bit system
to determine which PowerShell script to grab from the command and
control (C2) server. It looks at every network adapter, aggregating
all destination IPs of established non-loopback network connections.
Every IP address is then tested with extracted credentials and a
credential-based execution of PowerShell is attempted that downloads
and executes the malware from the C2 server on the target machine.
This variant maintains persistence via WMI (Windows Management Instrumentation).

The malware also has the capability to perform a Pass-the-Hash
attack with the NTLM information derived from Mimikatz in order to
download and execute the malware in remote systems.

Additionally, the malware exfiltrates stolen credentials to the
attacker via an HTTP GET request to:
'http://<C2>:8000/api.php?data=<credential data>'.

If the lateral movement with credentials fails, then the malware
uses PingCastle MS17-010 scanner (PingCastle is a French Active
Directory security tool) to scan that particular host to determine if
its vulnerable to EternalBlue, and uses it to spread to that host.

After all network derived IPs have been processed, the malware
generates random IPs and uses the same combination of PingCastle and
EternalBlue to spread to that host.

Tactic #4: Scenarios observed in Linux OS

We’ve also observed this vulnerability being exploited to deliver
shell scripts (Figure 10) that have functionality similar to the
PowerShell scripts.

Figure 10: Delivery of shell scripts

The shell script performs the following activities:

• Attempts to kill already running cryptominers

Figure 11: Terminating processes matching
certain strings

• Downloads and executes cryptominer malware

Figure 12: Downloading CryptoMiner

• Creates a cron job to maintain persistence

Figure 13: Cron job for persistence

• Tries to kill other potential miners to hog the CPU
  usage

Figure 14: Terminating other potential miners

The function shown in Figure 14 is used
to find processes that have high CPU usage and terminate them. This
terminates other potential miners and maximizes the utilization of resources.

Conclusion

Use of cryptocurrency mining malware is a popular tactic leveraged
by financially-motivated cyber criminals to make money from victims.
We’ve observed one threat actor mining around 1 XMR/day, demonstrating
the potential profitability and reason behind the recent rise in such
attacks. Additionally, these operations may be perceived as less risky
when compared to ransomware operations, since victims may not even
know the activity is occurring beyond the slowdown in system performance.

Notably, cryptocurrency mining malware is being distributed using
various tactics, typically in an opportunistic and indiscriminate
manner so cyber criminals will maximize their outreach and profits.

FireEye HX, being a behavior-based solution, is not affected by
cryptominer tricks. FireEye HX detects these threats at the initial
level of the attack cycle, when the attackers attempt to deliver the
first stage payload or when the miner tries to connect to mining pools.

At the time of writing, FireEye HX detects this activity with the
following indicators:

Detection Name

POWERSHELL DOWNLOADER (METHODOLOGY)

MONERO MINER (METHODOLOGY)

MIMIKATZ (CREDENTIAL STEALER)

Indicators of Compromise

MD5	Name
3421A769308D39D4E9C7E8CAECAF7FC4	cranberry.exe/logic.exe
B3A831BFA590274902C77B6C7D4C31AE	xmrig.exe/yam.exe
26404FEDE71F3F713175A3A3CEBC619B	1.ps1
D3D10FAA69A10AC754E3B7DDE9178C22	2.ps1
9C91B5CF6ECED54ABB82D1050C5893F2	info3.ps1
3AAD3FABF29F9DF65DCBD0F308FF0FA8	info6.ps1
933633F2ACFC5909C83F5C73B6FC97CC	lower.css
B47DAF937897043745DF81F32B9D7565	lib.css
3542AC729035C0F3DB186DDF2178B6A0	bootstrap.css

Thanks to Dileep Kumar Jallepalli and Charles Carmakal for their
help in the analysis.

The post CVE-2017-10271 Used to Deliver CryptoMiners: An Overview of Techniques
Used Post-Exploitation and Pre-Mining appeared first on Security Boulevard.

from CVE-2017-10271 Used to Deliver CryptoMiners: An Overview of Techniques Used Post-Exploitation and Pre-Mining

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.

The post ReelPhish: A Real-Time Two-Factor Phishing Tool appeared first on Security Boulevard.

from ReelPhish: A Real-Time Two-Factor Phishing Tool

Attacks Leveraging Adobe Zero-Day (CVE-2018-4878) – Threat Attribution, Attack Scenario and Recommendations

On Jan. 31, KISA (KrCERT) published an advisory
about an Adobe Flash zero-day vulnerability (CVE-2018-4878)
being exploited in the wild. On Feb. 1, Adobe issued an advisory
confirming the vulnerability
exists in Adobe Flash Player 28.0.0.137 and earlier versions,
and that successful exploitation could potentially allow an attacker
to take control of the affected system.

FireEye began investigating the vulnerability following the release
of the initial advisory from KISA.

Threat Attribution

We assess that the actors employing this latest Flash zero-day are a
suspected North Korean group we track as TEMP.Reaper. We have observed
TEMP.Reaper operators directly interacting with their command and
control infrastructure from IP addresses assigned to the STAR-KP
network in Pyongyang. The STAR-KP network is operated as a joint
venture between the North Korean Government's Post and
Telecommunications Corporation and Thailand-based Loxley Pacific.
Historically, the majority of their targeting has been focused on the
South Korean government, military, and defense industrial base;
however, they have expanded to other international targets in the last
year. They have taken interest in subject matter of direct importance
to the Democratic People's Republic of Korea (DPRK) such as Korean
unification efforts and North Korean defectors.

In the past year, FireEye iSIGHT Intelligence has discovered newly
developed wiper malware being deployed by TEMP.Reaper, which we detect
as RUHAPPY. While we have observed other suspected North Korean threat
groups such as TEMP.Hermit employ wiper malware in disruptive attacks,
we have not thus far observed TEMP.Reaper use their wiper malware
actively against any targets.

Attack Scenario

Analysis of the exploit chain is ongoing, but available information
points to the Flash zero-day being distributed in a malicious document
or spreadsheet with an embedded SWF file. Upon opening and successful
exploitation, a decryption key for an encrypted embedded payload would
be downloaded from compromised third party websites hosted in South
Korea. Preliminary analysis indicates that the vulnerability was
likely used to distribute the previously observed DOGCALL malware to
South Korean victims.

Recommendations

Adobe stated that it plans to release a fix for this issue the week
of Feb. 5, 2018. Until then, we recommended that customers use extreme
caution, especially when visiting South Korean sites, and avoid
opening suspicious documents, especially Excel spreadsheets. Due to
the publication of the vulnerability prior to patch availability, it
is likely that additional criminal and nation state groups will
attempt to exploit the vulnerability in the near term.

FireEye Solutions Detections

FireEye Email Security, Endpoint Security with Exploit Guard
enabled, and Network Security products will detect the malicious
document natively. Email Security and Network Security customers who
have enabled the riskware feature may see additional alerts based on
suspicious content embedded in malicious documents.

The post Attacks Leveraging Adobe Zero-Day (CVE-2018-4878) – Threat Attribution,
Attack Scenario and Recommendations appeared first on Security Boulevard.

from Attacks Leveraging Adobe Zero-Day (CVE-2018-4878) – Threat Attribution, Attack Scenario and Recommendations

Microsoft Office Vulnerabilities Used to Distribute Zyklon Malware in Recent Campaign

Introduction

FireEye researchers recently observed threat actors leveraging
relatively new vulnerabilities in Microsoft Office to spread Zyklon
HTTP malware. Zyklon has been observed in the wild since early 2016
and provides myriad sophisticated capabilities.

Zyklon is a publicly available, full-featured backdoor capable of
keylogging, password harvesting, downloading and executing additional
plugins, conducting distributed denial-of-service (DDoS) attacks, and
self-updating and self-removal. The malware may communicate with its
command and control (C2) server over The Onion Router (Tor) network if
configured to do so. The malware can download several plugins, some of
which include features such as cryptocurrency mining and password
recovery, from browsers and email software. Zyklon also provides a
very efficient mechanism to monitor the spread and impact.

Infection Vector

We have observed this recent wave of Zyklon malware being delivered
primarily through spam emails. The email typically arrives with an
attached ZIP file containing a malicious DOC file (Figure 1 shows a
sample lure).

The following industries have been the primary targets in this campaign:

• Telecommunications
• Insurance
• Financial Services

Figure 1: Sample lure documents

Attack Flow

1. Spam email arrives in the
   victim’s mailbox as a ZIP attachment, which contains a malicious DOC
   file.
2. The document files exploit at least three known
   vulnerabilities in Microsoft Office, which we discuss in the
   Infection Techniques section. Upon execution in a vulnerable
   environment, the PowerShell based payload takes over.
3. The
   PowerShell script is responsible for downloading the final payload
   from C2 server to execute it.

A visual representation of the attack flow and execution chain can
be seen in Figure 2.

Figure 2: Zyklon attack flow

Infection Techniques

CVE-2017-8759

This vulnerability was discovered
by FireEye in September 2017, and it is a vulnerability we have
observed being exploited in the wild.

The DOC file contains an embedded OLE Object that, upon execution,
triggers the download of an additional DOC file from the stored URL
(seen in Figure 3).

Figure 3: Embedded URL in OLE object

CVE-2017-11882

Similarly, we have also observed actors leveraging another
recently discovered
vulnerability (CVE-2017-11882) in Microsoft Office. Upon opening the
malicious DOC attachment, an additional download is triggered from a
stored URL within an embedded OLE Object (seen in Figure 4).

Figure 4: Embedded URL in OLE object

Figure 5: HTTP GET request to download
the next level payload

The downloaded file, doc.doc, is XML-based and contains a
PowerShell command (shown in Figure 6) that subsequently downloads the
binary Pause.ps1.

Figure 6: PowerShell command to download
the Pause.ps1 payload

Dynamic Data Exchange (DDE)

Dynamic Data Exchange (DDE) is the interprocess communication
mechanism that is exploited to perform remote code execution. With the
help of a PowerShell script (shown in Figure 7), the next payload
(Pause.ps1) is downloaded.

Figure 7: DDE technique used to download
the Pause.ps1 payload

One of the unique approaches we have observed is the use of dot-less
IP addresses (example: hxxp://258476380).

Figure 8 shows the network communication of the Pause.ps1 download.

Figure 8: Network communication to
download the Pause.ps1 payload

Zyklon Delivery

In all these techniques, the same domain is used to download the
next level payload (Pause.ps1), which is another PowerShell
script that is Base64 encoded (as seen in Figure 8).

The Pause.ps1 script is responsible for resolving the APIs
required for code injection. It also contains the injectable
shellcode. The APIs contain VirtualAlloc(), memset(), and
CreateThread(). Figure 9 shows the decoded Base64 code.

Figure 9: Base64 decoded Pause.ps1

The injected code is responsible for downloading the final payload
from the server (see Figure 10). The final stage payload is a PE
executable compiled with .Net framework.

Figure 10: Network traffic to download
final payload (words.exe)

Once executed, the file performs the following activities:

1. Drops a copy of itself in
   %AppData%\svchost.exe\svchost.exe and drops an XML file, which
   contains configuration information for Task Scheduler (as shown in
   Figure 11).
2. Unpacks the code in memory via process
   hollowing. The MSIL file contains the packed core payload in its
   .Net resource section.
3. The unpacked code is Zyklon.

Figure 11: XML configuration file to
schedule the task

The Zyklon malware first retrieves the external IP address of the
infected machine using the following:

• api.ipify[.]org
• ip.anysrc[.]net
• myexternalip[.]com
• whatsmyip[.]com

The Zyklon executable contains another encrypted file in its .Net
resource section named tor. This file is decrypted and injected
into an instance of InstallUtiil.exe, and functions as a Tor anonymizer.

Command & Control Communication

The C2 communication of Zyklon is proxied through the Tor network.
The malware sends a POST request to the C2 server. The C2 server is
appended by the gate.php, which is stored in file memory. The
parameter passed to this request is getkey=y. In response to this
request, the C2 server responds with a Base64-encoded RSA public key
(seen in Figure 12).

Figure 12: Zyklon public RSA key

After the connection is established with the C2 server, the malware
can communicate with its control server using the commands shown in
Table 1.

Command	Action
sign	Requests system information
settings	Requests settings from C2 server
logs	Uploads harvested passwords
wallet	Uploads harvested cryptocurrency wallet data
proxy	Indicates SOCKS proxy port opened
miner	Cryptocurrency miner commands
error	Reports errors to C2 server
ddos	DDoS attack commands

Table 1: Zyklon accepted commands

The following figures show the initial request and subsequent server
response for the “settings” (Figure 13), “sign” (Figure 14), and
“ddos” (Figure 15) commands.

Figure 13: Zyklon issuing “settings”
command and subsequent server response

Figure 14: Zyklon issuing “sign” command
and subsequent server response

Figure 15: Zyklon issuing “ddos” command
and subsequent server response

Plugin Manager

Zyklon downloads number of plugins from its C2 server. The plugin
URL is stored in file in following format:

• /plugin/index.php?plugin=<Plugin_Name>

The following plugins are found in the memory of the Zyklon malware:

• /plugin/index.php?plugin=cuda
• /plugin/index.php?plugin=minerd
• /plugin/index.php?plugin=sgminer
• /plugin/index.php?plugin=socks
• /plugin/index.php?plugin=tor
• /plugin/index.php?plugin=games
• /plugin/index.php?plugin=software
• /plugin/index.php?plugin=ftp
• /plugin/index.php?plugin=email
• /plugin/index.php?plugin=browser

The downloaded plugins are injected into: Windows\Microsoft.NET\Framework\v4.0.30319\RegAsm.exe.

Additional Features

The Zyklon malware offers the following additional capabilities (via plugins):

Browser Password Recovery

Zyklon HTTP can recover passwords from popular web browsers, including:

• Google Chrome
• Mozilla Firefox
• Internet Explorer
• Opera
  Browser
• Chrome Canary/SXS
• CoolNovo Browser
• Apple Safari
• Flock Browser
• SeaMonkey
  Browser
• SRWare Iron Browser
• Comodo Dragon
  Browser

FTP Password Recovery

Zyklon currently supports FTP password recovery from the following
FTP applications:

• FileZilla
• SmartFTP
• FlashFXP
• FTPCommander
• Dreamweaver
• WS_FTP

Gaming Software Key Recovery

Zyklon can recover PC Gaming software keys from the following games:

• Battlefield
• Call
  of Duty
• FIFA
• NFS
• Age of Empires
• Quake
• The Sims
• Half-Life
• IGI
• Star Wars

Email Password Recovery

Zyklon may also collect email passwords from following applications:

• Microsoft Outlook
  Express
• Microsoft Outlook 2002/XP/2003/2007/2010/2013
• Mozilla Thunderbird
• Windows Live Mail 2012
• IncrediMail, Foxmail v6.x - v7.x
• Windows Live
  Messenger
• MSN Messenger
• Google Talk
• GMail
  Notifier
• PaltalkScene IM
• Pidgin (Formerly Gaim)
  Messenger
• Miranda Messenger
• Windows Credential
  Manager

License Key Recovery

The malware automatically detects and decrypts the license/serial
keys of more than 200 popular pieces of software, including Office,
SQL Server, Adobe, and Nero.

Socks5 Proxy

Zyklon features the ability to establish a reverse Socks5 proxy
server on infected host machines.

Hijack Clipboard Bitcoin Address

Zyklon has the ability to hijack the clipboard, and replaces the
user’s copied bitcoin address with an address served up by the actor’s
control server.

Zyklon Pricing

Researchers identified different versions of Zyklon HTTP being
advertised in a popular underground marketplace for the following prices:

• Normal build: $75
  (USD)
• Tor-enabled build: $125 (USD)
• Rebuild/Updates:
  $15 (USD)
• Payment Method: Bitcoin (BTC)

Conclusion

Threat actors incorporating recently discovered vulnerabilities in
popular software – Microsoft Office, in this case – only increases the
potential for successful infections. These types of threats show why
it is very important to ensure that all software is fully updated.
Additionally, all industries should be on alert, as it is highly
likely that the threat actors will eventually move outside the scope
of their current targeting.

At this time of writing, FireEye Multi Vector Execution (MVX)
engine is able to recognize and block this threat. Table 2 lists
the current detection and blocking capabilities by product.

Detection Name	Product	Action
POWERSHELL DOWNLOADER D (METHODOLOGY)	HX	Detect
SUSPICIOUS POWERSHELL USAGE (METHODOLOGY)	HX	Detect
POWERSHELL DOWNLOADER (METHODOLOGY)	HX	Detect
SUSPICIOUS EQNEDT USAGE (METHODOLOGY)	HX	Detect
TOR (TUNNELER)	HX	Detect
SUSPICIOUS SVCHOST.EXE (METHODOLOGY)	HX	Detect
Malware.Binary.rtf	EX/ETP/NX	Block
Malware.Binary	EX/ETP/NX	Block
FE_Exploit_RTF_CVE_2017_8759	EX/ETP/NX	Block
FE_Exploit_RTF_CVE201711882_1	EX/ETP/NX	Block

Table 2: Current detection capabilities by
FireEye products

Indicators of Compromise

The contained analysis is based on the representative sample lures
shown in Table 3.

MD5	Name
76011037410d031aa41e5d381909f9ce	accounts.doc
4bae7fb819761a7ac8326baf8d8eb6ab	Courier.doc
eb5fa454ab42c8aec443ba8b8c97339b	doc.doc
886a4da306e019aa0ad3a03524b02a1c	Pause.ps1
04077ecbdc412d6d87fc21e4b3a4d088	words.exe

Table 3: Sample Zyklon lures

Network Indicators

• 154.16.93.182
• 85.214.136.179
• 178.254.21.218
• 159.203.42.107
• 217.12.223.216
• 138.201.143.186
• 216.244.85.211
• 51.15.78.0
• 213.251.226.175
• 93.95.100.202
• warnono.punkdns.top

The post Microsoft Office Vulnerabilities Used to Distribute Zyklon Malware in
Recent Campaign appeared first on Security Boulevard.

from Microsoft Office Vulnerabilities Used to Distribute Zyklon Malware in Recent Campaign

FLARE IDA Pro Script Series: Simplifying Graphs in IDA

Introduction

We’re proud to release a new plug-in for IDA Pro users –
SimplifyGraph – to help automate creation of groups of nodes in the
IDA’s disassembly graph view. Code and binaries are available from the
FireEye GitHub
repo. Prior to this release we submitted it in the 2017
Hex-Rays plugin contest, where it placed third overall.

My personal preference is to use IDA’s graph mode when doing the
majority of my reverse engineering. It provides a graphical
representation of the control flow graph and gives visual cues about
the structure of the current function that helps me better understand
the disassembly.

Graph mode is great until the function becomes complex. IDA is often
forced to place adjacent nodes relatively far apart, or have edges in
the graph cross and have complex paths. Using the overview graph
becomes extremely difficult due to the density of nodes and edges, as
seen in Figure 1.

Figure 1: An annoying function

IDA has a built-in mechanism to help simplify graphs: creating
groups of nodes, which replaces all of the selected nodes with a new
group node representative. This is done by selecting one or more
nodes, right-clicking, and selecting “Group nodes”, as shown in Figure
2. Doing this manually is certainly possible, but it becomes tedious
to follow edges in complex graphs and correctly select all of the
relevant nodes without missing any, and without making mistakes.

Figure 2: Manual group creation

The SimplifyGraph IDA Pro plug-in we’re releasing is built to
automate IDA’s node grouping capability. The plug-in is
source-compatible with the legacy IDA SDK in 6.95, and has been ported
to the new SDK for IDA 7.0. Pre-built binaries for both are available
on the Releases tab
for the project repository.

The plug-in has several parts, which are introduced below. By
combining these together it’s possible to isolate parts of a control
flow graph for in-depth reverse engineering, allowing you to look at
Figure 3 instead of Figure 1.

Figure 3: Isolated subgraph to focus on

Create Unique-Reachable (UR) Subgraph

Unique-Reachable nodes are all nodes reachable in the graph from a
given start node and that are not reachable from any nodes not
currently in the UR set. For example, in Figure 4, all of the
Unique-Reachable nodes starting at the green node are highlighted in
blue. The grey node is reachable from the green node, but because it
is reachable from other nodes not in the current UR set it is pruned
prior to group creation.

Figure 4: Example Unique Reachable selection

The plug-in allows you to easily create a new group based on the UR
definition. Select a node in IDA's graph view to be the start of the
reachable search. Right click and select "SimplifyGraph ->
Create unique-reachable group". The plug-in performs a graph
traversal starting at this node, identifies all reachable nodes, and
prunes any nodes (and their reachable nodes) that have predecessor
nodes not in the current set. It then prompts you for the node text to
appear in the new group node.

If you select more than one node (by holding the Ctrl key when
selecting nodes) for the UR algorithm, each additional node acts as a
sentry node. Sentry nodes will not be included in the new group, and
they halt the graph traversal when searching for reachable nodes. For
example, in Figure 5, selecting the green node first treats it as the
starting node, and selecting the red node second treats it as a sentry
node. Running the “Create unique-reachable group” plug-in option
creates a new group made of the green node and all blue nodes. This
can be useful when you are done analyzing a subset of the current
graph, and wish to hide the details behind a group node so you can
concentrate on the rest of the graph.

Figure 5: Unique reachable with sentry

The UR algorithm operates on the currently visible graph, meaning
that you can run the UR algorithm repeatedly and nest groups.

Switch Case Groups Creation

Switch statements implemented as jump tables appear in the graph as
nodes with a large fan-out, as shown in Figure 6. The SimplifyGraph
plug-in detects when the currently selected node has more than two
successor nodes and adds a right-click menu option “SimplifyGraph
-> Create switch case subgraphs”. Selecting this runs the
Unique-Reachable algorithm on each separate case branch and
automatically uses IDA’s branch label as the group node text.

Figure 6: Switch jumptable use

Figure 7 shows a before and after graph overview of the same
function when the switch-case grouping is run.

Figure 7: Before and after of switch
statement groupings

Isolated Subgraphs

Running Edit -> Plugins -> SimplifyGraph brings up a new
chooser named "SimplifyGraph - Isolated subgraphs" that
begins showing what I call isolated subgraphs of the current graph, as
seen in Figure 8.

Figure 8: Example isolated subgraphs chooser

A full definition appears later in the appendix including how these
are calculated, but the gist is that an isolated subgraph in a
directed graph is a subset of nodes and edges such that there is a
single entrance node, a single exit node, and none of the nodes (other
than the subgraph entry node) is reachable by nodes not in the subgraph.

Finding isolated subgraphs was originally researched to help
automatically identify inline functions. It does this, but it turns
out that this graph construct occurs naturally in code without inline
functions. This isn’t a bad thing as it shows a natural grouping of
nodes that could be a good candidate to group to help simplify the
overall graph and make analysis easier.

Once the chooser is active, you can double click (or press Enter) on
a row in the chooser to highlight the nodes that make up the subgraph,
as seen in Figure 9.

Figure 9: Highlighted isolated subgraph

You can create a group for an isolated subgraph by:

• Right-clicking on the
  chooser row and selecting "Create group", or pressing
  Insert while a row is selected.
• Right-clicking in a
  highlighted isolated subgraph node and selecting "SimplifyGraph
  -> Create isolated subgraph".

Doing either of these prompts you for text for the new graph node to create.

If you manually create/delete groups using IDA you may need to
refresh the chooser's knowledge of the current function groups
(right-click and select "Refresh groups" in the chooser).
You can right click in the chooser and select "Clear
highlights" to remove the current highlights. As you navigate to
new functions the chooser updates to show isolated subgraphs in the
current function. Closing the chooser removes any active highlights.
Any custom colors you applied prior to running the plug-in are
preserved and reapplied when the current highlights are removed.

Isolated subgraph calculations operates on the original control flow
graph, so isolated subgroups can't be nested. As you create groups,
rows in the chooser turn red indicating a group already exists, or
can't be created because there is an overlap with an existing group.

Another note: this calculation does not currently work on functions
that do not return (those with an infinite loop). See the Appendix for details.

Graph Complement

Creating groups to simplify the overall control flow graph is nice,
but it doesn’t help understand the details of a group that you create.
To assist with this, the last feature of the plug-in hides everything
but the group you’re interested in allowing you to focus on your
reverse engineering. Right clicking on a collapsed group node, or a
node that that belongs to an uncollapsed group (as highlighted by IDA
in yellow), brings up the plug-in option “Complement & expand
group” and “Complement group”, respectively. When this runs the
plug-in creates a group of all nodes other than the group you’re
interested in. This has the effect of hiding all graph nodes that you
aren’t currently examining and allows you to better focus on analysis
of the current group. As you can see, we’re abusing group creation a
bit so that we can avoid creating a custom graph viewer, and instead
stay within the built-in IDA graph disassembly view which allows us to
continue to markup the disassembly as you’re used to.

Complementing the graph gives you the view seen in Figure 10, where
the entire graph is grouped into a node named “Complement of group X”.
When you’re done analyzing the current group, right click on the
complement node and select IDA’s “Ungroup nodes” command.

Figure 10: Group complement

Example Workflow

As an example that exercises the plug-in, let’s revisit the function
in Figure 1. This is a large command-and-control dispatch function for
a piece of malware. It contains a large if-else-if series of inlined
strcmp comparisons that branch to the logic for each command when the
input string matches the expected command.

1. Find all of the inline
   strcmp’s and create groups for those. Run Edit -> Plugins ->
   SimplifyGraph to bring up the plug-in chooser. In this function
   nearly every isolated subgraph is a 7-node inlined strcmp
   implementation. Go through in the chooser to verify, and create a
   group. This results in a graph similar to Figure 11.

   
   Figure 11: Grouped strcmp
   
   

2. When an input string matches a command string, the
   malware branches to code that implements the command. To further
   simplify the graph and make analysis easier, run the
   Unique-Reachable algorithm on each separate command by right
   clicking on the first node after each string-comparison and
   selecting SimplifyGraph -> Create unique-reachable group. After
   this we now have a graph as in Figure 12.

   
   Figure 12: Grouped command logic
   
   

3. Now perform your reverse engineering on each
   separate branch in the dispatch function. For each command handler
   group node that we created, right click that node and select
   “SimplifyGraph -> Complement & expand group”. A result of
   complementing a single command handler node is shown in Figure 13,
   which is much easier to analyze.

   
   Figure 13: Group complement
   
   

4. When done analyzing the current command handler,
   delete the complement group by right clicking the “Complement of
   group X” node and use IDA’s built-in “Ungroup nodes” command. Repeat
   for the remaining command handler grouped nodes.

Config

You can tweak some of the configuration by entering data in a file
named %IDAUSR%/SimplifyGraph.cfg, where %IDAUSR% is typically
%APPDATA%/Hex-Rays/IDA Pro/ unless explicitly set to something else.
All of the config applies to the isolated subgraph component. Options:

* SUBGRAPH_HIGHLIGHT_COLOR: Default 0xb3ffb3: The color to apply to
nodes when you double click/press enter in the chooser to show nodes
that make up the currently selected isolated subgraph. Not everyone
agrees that my IDA color scheme is best, so you can set your own
highlight color here.

* MINIMUM_SUBGRAPH_NODE_COUNT: Default 3: The minimum number of
nodes for a valid isolated subgraph. If a discovered subgraph has
fewer nodes than this number it is not included in the shown list.
This prevents trivial two-node subgraphs from being shown.

* MAXIMUM_SUBGRAPH_NODE_PERCENTAGE: Default 95: The maximum percent
of group nodes (100.0 *(subgroup_node_count /
total_function_node_count)) allowed. This filters out isolated
subgraphs that make up (nearly) the entire function, which are
typically not interesting.

Example SimplifyGraph.cfg contents

```

"MINIMUM_SUBGRAPH_NODE_COUNT"=5

"MAXIMUM_SUBGRAPH_NODE_PERCENTAGE"=75

"SUBGRAPH_HIGHLIGHT_COLOR"=0x00aa1111

```

Prior work:

I came across semi-related work while working on this: GraphSlick from
the 2014
Hex-Rays contest. That plug-in had different goals to
automatically identifying (nearly) identical inline functions via CFG
and basic block analysis, and patching the program to force mock
function calls to the explicit function. It had a separate viewer to
present information to the user.

SimplifyGraph is focused on automating tasks when doing manual
reverse engineering (group creation) to reduce the complexity of
disassembly in graph mode. Future work may incorporate the same
prime-products calculations to help automatically identify isolated subgraphs.

Installation

Prebuilt Windows binaries are available from the Releases tab of the
GitHub project page. The ZIP files contain both IDA 32 and IDA
64 plug-ins for each of the new IDA 7.0 SDK and for the legacy IDA
6.95 SDK. Copy the two plug-ins for your version of IDA to the
%IDADIR%\plugins directory.

Building

This plug-in & related files were built using Visual Studio 2013
Update 5.

Environment Variables Referenced by project:

* IDASDK695: path to the extracted IDA 6.95 SDK. This should have
`include` and `lib` paths beneath it.

* IDASDK: path to the extracted IDA 7.0 (or newer) SDK. This Should
have `include` and `lib` paths beneath it.

* BOOSTDIR: path to the extracted Boost library. Should have `boost`
and `libs` paths beneath it.

The easiest way is to use the Microsoft command-line build tools:

* For IDA7.0: Launch VS2013 x64 Native Tools Command Prompt, then run:

```

msbuild SimplifyGraph.sln /property:Configuration=ReleaseIDA70_32 /property:Platform=x64

msbuild SimplifyGraph.sln /property:Configuration=ReleaseIDA70_64 /property:Platform=x64

```

* For IDA6.95: Launch VS2013 x86 Native Tools Command Prompt, then run:

```

msbuild SimplifyGraph.sln /property:Configuration=ReleaseIDA695_32 /property:Platform=Win32

msbuild SimplifyGraph.sln /property:Configuration=ReleaseIDA695_64 /property:Platform=Win32

```

Conclusion

I hope this blog has shown the power of automatically grouping nodes
within a disassembly graph view, and viewing these groups in isolation
to help with your analysis. This plug-in has become a staple of my
workflow, and we’re releasing it to the community with the hope that
others find it useful as well.

Appendix: Isolated Subgraphs

Finding isolated subgraphs relies on calculating the immediate
dominator and immediate post-dominator trees for a given function graph.

A node d dominates n if every path to n must go through d.

The immediate dominator p of node n is basically the closest
dominator to n, where there is no node t where p dominates t, and t
dominates n.

A node z post-dominates a node n if every path from n to the exit
node must go through z.

The immediate post-dominator x of node n is the closest
post-dominator, where there is no node t where t post-dominates n and
x post-dominates t.

The immediate dominator relationship forms a tree of nodes, where
every node has an immediate dominator other than the entry node.

The Lengauer-Tarjan algorithm can efficiently calculate the
immediate dominator tree of a graph. It can also calculate the
immediate post-dominator tree by reversing the direction of each edge
in the same graph.

The plug-in calculates the immediate dominator tree and immediate
post-dominator tree of the function control flow graph and looks for
the situations where the (idom[i] == j) and (ipdom[j] == i). This
means all paths from the function start to node i must go through node
j, and all paths from j to the function terminal must go through i. A
candidate isolated subgraph thus starts at node j and ends at node i.

For each candidate isolated subgraph, the plug-in further verifies
only the entry node has predecessor nodes not in the candidate
subgraph. The plug-in also filters out candidate subgraphs by making
sure they have a minimum node count and cover a maximum percentage of
nodes (see MINIMUM_SUBGRAPH_NODE_COUNT and
MAXIMUM_SUBGRAPH_NODE_PERCENTAGE in the config section).

One complication is that functions often have more than one terminal
node – programmers can arbitrarily return from the current function at
any point. The immediate post-dominator tree is calculated for every
terminal node, and any inconsistencies are marked as indeterminate and
are not possible candidates for use. Functions with infinite loops do
not have terminal nodes, and are not currently handled.

For a simple example, consider the graph in Figure 14. It has the
following immediate dominator and post-dominator trees:

Figure 14: Example graph

Node	idom
0	None
1	0
2	1
3	1
4	3
5	3
6	3
7	6
8	0

Node	ipdom
0	8
1	3
2	3
3	6
4	6
5	6
6	7
7	8
8	None

Looking for pairs of (idom[i] == j) and (ipdom[j] == i) gives the following:

(0, 8) (1, 3) (3, 6) (6,7)

(0, 8) is filtered because it makes up all of the nodes of the graph.

(1,3) and (6, 7) are filtered out because they contain nodes
reachable from nodes not in the set: for (1, 3) node 2 is reachable
from node 6, and for (6, 7) node 2 is reachable from node 1.

This leaves (3, 6) as the only isolate subgraph in this example,
shown in Figure 15.

Figure 15: Example graph with isolated subgraph

The post FLARE IDA Pro Script Series: Simplifying Graphs in IDA appeared first on Security Boulevard.

from FLARE IDA Pro Script Series: Simplifying Graphs in IDA

Threat Actor Leverages Windows Zero-day Exploit in Payment Card Data Attacks

The post Threat Actor Leverages Windows Zero-day Exploit in Payment Card Data Attacks appeared first on Security Boulevard.

from Threat Actor Leverages Windows Zero-day Exploit in Payment Card Data Attacks

New FakeNet-NG Feature: Content-Based Protocol Detection

I (Matthew Haigh) recently contributed to FLARE’s FakeNet-NG
network simulator by adding content-based protocol detection and
configuration. This feature is useful for analyzing malware that uses
a protocol over a non-standard port; for example, HTTP over port 81.
The new feature also detects and adapts to SSL so that any protocol
can be used with SSL and handled appropriately by FakeNet-NG. We were
motivated to add this feature since it was a feature of the original
FakeNet and it was needed for real world malware.

What is FakeNet-NG

FakeNet-NG simulates
a network so malware analysts can run samples with network
functionality without the risks of an Internet connection. Analysts
can examine network-based indicators via FakeNet-NG’s textual and pcap
output. It is plug-and-play, configurable, and works on both Windows
and Linux. FakeNet-NG simulates common protocols to trick malware into
thinking it is connected to the Internet. FakeNet-NG supports the
following protocols: DNS, HTTP, FTP, POP, SMTP, IRC, SSL, and TFTP.

Previous Design

Previously FakeNet-NG employed Listener modules, which were bound to
configurable ports for each protocol. Any traffic on those ports was
received by the socket and processed by the Listener. 

In the previous architecture, packets were redirected using a
Diverter module that utilized WinDivert for Windows and netfilter for
Linux. Each incoming and outgoing packet was examined by the Diverter,
which kept a running list of connections. Packets destined for
outbound ports were redirected to a default Listener, which would
respond to any packet with an echo of the same data. The Diverter also
redirected packets based on whether FakeNet-NG was run in Single-Host
or Multi-Host mode, and if any applications were blacklisted or
whitelisted according to the configuration. It would simply release
the packet on the appropriate port and the intended Listener would
receive it on the socket.

New Design

My challenge was to eliminate this port/protocol dependency. In
order to disassociate the Listeners from the corresponding ports, a
new architecture was needed. The first challenge was to maintain
Listener functionality. The original architecture relied on Python
libraries that interact with the socket. Therefore, we needed to
maintain “socket autonomy” in the Listener, so we added a “taste()”
function for each Listener. The routine returns a confidence score
based on the likelihood that the packet is associated with the
protocol. Figure 1 demonstrates the taste() routine for HTTP, which
looks for the request method string at the beginning of the packet
data. It gives an additional point if the packet is on a common HTTP
port. There were several choices for how these scores were to be
tabulated. It could not happen in the Diverter because of the TCP
handshake. The Diverter could not sample data from data-less handshake
packets, and if the Diverter completed the handshake, the connection
could not easily be passed to a different socket at the Listener
without disrupting the connection.

Figure 1: HTTP taste() example

Proxy

We ultimately decided to add a proxy Listener that maintains
full-duplex connections with the client and the Listener, with both
sides unaware of the other. This solves the handshake problem and
maintains socket autonomy at the Listener. The proxy is also easily
configurable and enables new functionality. We substituted the proxy
for the echo-server default Listener, which would receive traffic
destined for unbound ports. The proxy peeks at the data on the socket,
polls the Listeners, and creates a new connection with the Listener
that returns the highest score. The echo-server always returns a score
of one, so it will be chosen if no better option is detected. The
analyst controls which Listeners are bound to ports and which
Listeners are polled by the proxy. This means that the listeners do
not have to be exposed at all; everything can be decided by the proxy.
The user can set the Hidden option in the configuration file to False
to ensure the Listener will be bound to the port indicated in the
configuration file. Setting Hidden to True will force any packets to
go through the proxy before accessing the Listener. For example, if
the analyst suspects that malware is using FTP on port 80, she can
‘hide’ HTTP from catching the traffic, and let the proxy detect FTP
and forward the packet to the FTP Listener. Additional configuration
options exist for choosing which protocols are polled by the proxy.
See Figure 2 and Figure 3 for configuration examples. Figure 2 is a
basic configuration for a Listener, and Figure 3 demonstrates how the
proxy is configurable for TCP and UDP.

Figure 2: Listener Configuration Options

Figure3: Proxy Configuration Options

The proxy also handles SSL detection. Before polling the Listeners,
the proxy examines the packet. If SSL is detected, the proxy “wraps”
the socket in SSL using Python’s OpenSSL library. With the combination
of protocol and SSL detection, each independent of the other,
FakeNet-NG can now handle just about any protocol combination.

The proxied SSL implementation also allows for improved packet
analysis. The connection between the proxy and the Listener is not
encrypted, which allows FakeNet to dump un-encrypted packets to the
pcap output. This makes it easier for the analyst to examine the
packet data. FakeNet continues to produce pcap output that includes
packet data before and after modification by FakeNet. While this
results in repetitive data, it is often useful to see the original
packet along with the modification.

Example

Figure 4 shows verbose (-v) output from FakeNet on Windows
responding to an HTTP request on port 81 from a clowncar malware
variant (SHA-256
8d2dfd609bcbc94ff28116a80cf680660188ae162fc46821e65c10382a0b44dc).
Malware such as clowncar use traditional protocols over non-standard
ports for many reasons. FakeNet gives the malware analyst the
flexibility to detect and respond to these cases automatically.

Figure 4: clowncar malware using HTTP on
port 81

Conclusion

FLARE’s FakeNet-NG tool is a powerful network-simulation tool
available for Windows and Linux. The new content-based protocol
detection and SSL detection features ensure that FakeNet-NG remains
the most useful tool for malware analysts. Configuration options give
programmers the flexibility necessary to respond to malware using most
protocols on any port.

The post New FakeNet-NG Feature: Content-Based Protocol Detection appeared first on Security Boulevard.

from New FakeNet-NG Feature: Content-Based Protocol Detection

2017 Flare-On Challenge Solutions

Another year, another successful Flare-On Challenge. I’d first like
to thank our challenge authors for their hard work developing each of
the challenges, and also for writing up their solutions:

• Challenge #1: Dominik Weber (@Invalid_handle)
• Challenge #2: Nhan Huynh
• Challenge #3: Matt Williams
  (@0xmwilliams)
• Challenge #4: James T. Bennett
  (@jtbennettjr)
• Challenge #5: Tyler Dean (@spresec)
• Challenge #6: Jon Erickson (@2130706433)
• Challenge #7:
  Michael Bailey (@mykill)
• Challenge #8: Moritz Raabe
  (@m_r_tz)
• Challenge #9: Joshua Homan
• Challenge #10:
  Dominik Weber (@Invalid_handle)
• Challenge #11: Nick Harbour
  (@nickharbour)
• Challenge #12: Jay Smith (@jay_smif)

Our popularity and participation continued to swell, with a 57
percent increase in total players (3240) and a 304 percent increase in
the number of players who solved at least one challenge (2566) over
last year. The overall difficulty also appears to have increased this
year, with only 2.7 percent of players (90 total) completing the
challenge, a decrease from the 6 percent who completed last
year’s challenge.

The following graph shows the total number of players who solved
each stage of the challenge:

The 90 players who completed the challenge will have their names
forever listed on our hall of fame, and they will receive a prize. The
prize this year is this massive Flare pin that measures nearly 4
inches across:

This pin is a great item to sport on your backpack or affix to your
lanyard. The above is a mock-up from the manufacturer – we expect to
receive them in the next few weeks and will begin shipping them to the
winners soon after.

All the binaries from this year’s challenge are now posted on the Flare-On
website (password: flare), and here are the solutions written by
each challenge author:

1. SOLUTION
   #1
2. SOLUTION
   #2
3. SOLUTION
   #3
4. SOLUTION
   #4
5. SOLUTION
   #5
6. SOLUTION
   #6
7. SOLUTION
   #7
8. SOLUTION
   #8
9. SOLUTION
   #9
10. SOLUTION
    #10
11. SOLUTION
    #11
12. SOLUTION
    #12

The post 2017 Flare-On Challenge Solutions appeared first on Security Boulevard.

from 2017 Flare-On Challenge Solutions