Category: Palo Alto Networks

Summary

Palo Alto Networks Unit 42 used the AutoFocus threat intelligence service to identify a series of phishing attacks against Japanese organizations. Using AutoFocus to quickly search and correlate artifacts across the collective set of WildFire and other Palo Alto Networks threat intelligence, we were able to associate the attacks with the group publicly known as “DragonOK.” [1] These attacks took place between January and March of 2015.

DragonOK has previously targeted Japanese high-tech and manufacturing firms, but we’ve identified a new backdoor malware, named “FormerFirstRAT,” deployed by these attackers. See the “Malware Details” section for analysis of the three RATs and two additional backdoors deployed in this persistent attack campaign.

Campaign Details

This campaign involved five separate phishing attacks, each carrying a different variant of Sysget malware, also known as HelloBridge. The malware was included as an attachment intended to trick the user into opening the malware. This included altering the icon of the executable to appear as other file types (Figure 1) as well as decoy documents to trick users into thinking they had opened a legitimate file.

Figure 1. Icons used by malicious Sysget attachments.

All of the Sysget files used in this campaign communicate with a single command and control (C2) server, hosted at biosnews[.]info. Sysget communicates with this server using the HTTP protocol; see the Malware Details section for specifics of the command and control traffic. All five phishing campaigns targeted a Japanese manufacturing firm over the course of two months, but the final campaign also targeted a separate Japanese high-tech organization. (Figure 2)

Figure 2. Five Sysget samples used to target two Japanese organizations.

Four of the five Sysget variants included a form of decoy document to trick users into believing they had opened a legitimate file rather than malware. Two of the executables used decoy documents that included information about obituaries. Figure 3 shows a GIF file containing an obituary notice for a woman, while Figure 4 shows a Microsoft Word document containing the obituary of a man.

Figure 3. Japanese decoy document containing an obituary notice for a woman.

Figure 4. Japanese decoy document containing an obituary notice for a woman.

The Sysget sample with a PDF icon created a second executable, named Adobe.exe, which simply displayed the following warning.

Figure 5. Error message generated by Adobe.exe

The final Sysget sample used a Microsoft Excel icon and opened an Excel document that contained cells filled with “XXXXXX.” (Figure 6)

Figure 6. Excel spreadsheet with Xs in multiple rows and columns.

These Sysget variants appear to be a first stage payload in these attacks. During analysis of this threat, we identified five additional backdoor tools hosted on biosnews[.]info which may be downloaded by the Sysget variants once the attackers have established a foothold.

Three of the backdoors, NFlog, PoisonIvy, and NewCT have previously been publicly associated with DragonOK. Additionally, the actors have now added the popular PlugX backdoor to their toolkit. An additional backdoor appears to be a new, custom-built tool, which we have not previously associated with DragonOK or any other attack group.  We’ve named this tool “FormerFirstRAT” as it appears to be the names used by the developers to refer to their creations. Figure 7 shows the relationship between these backdoors and their respective command and control servers.

Figure 7. Relationship between five additional backdoors used by DragonOK and their C2 servers in this campaign.

The following section details the functionality of the malware deployed in this campaign.

Malware Details

Sysget/HelloBridge

In this campaign, Sysget samples were attached to e-mails and used various icons to trick users into infecting their systems. The majority of these samples are self-extracting executables that contain both a malicious downloader, along with a legitimate file. When the self-extracting executable is launched, the downloader and legitimate file are typically dropped in one of the following directories and then executed:

• %PROGRAMFILES%
• %WINDIR%\Temp

When the malicious downloader is executed, it begins by creating the ‘mcsong[]’ event in order to ensure one instance is running. It then spawns a new instance of ‘C:\\windows\\system32\\cmd.exe’ with a window name of ‘Chrome-Update’. It attempts to obtain a handle to this window using the FindWindowW API call and then proceeds to send the following command to this executable. This allows the malware to indirectly execute a command within the cmd.exe process.

This registry key will ensure an executable that it later downloads is configured to persist across reboots. It then sends the ‘exit’ command to this executable, which will kill this particular process.

The malware then attempts to read the following file. This file is used to store a key that is later used to decrypt data received during network communications.

• %temp%\ibmCon6.tmp

If the file does not exist, it will make the following GET request:

The filename and name parameters are statically set in the above request. The server responds with data similar to the following:

The first two pieces of data (’17’ and ‘gh204503254′) are then written to the ibmCon6.tmp file referenced earlier.

The malware will copy itself to the %TEMP% directory with the executable name of ‘notilv.exe’. Due to the previously written registry key, this file will execute when the machine is restarted and the current user logs in.

The malware then makes the following request:

The filename and uid parameters are statically set in the above request. The response data is decrypted using the RC4 cryptographic stream cipher. The ‘gh204503254′ data that was previously downloaded is used as the key. The following Python code can be used for decryption, using the ‘gh204503254′ key:

At this stage, the remote server can send a number of different responses. The following example response will instruct the malware to download a remote executable file:

‘filename.exe’ is the path where the downloaded file will be stored, and ‘01234567890123456789012345678901’ is the value supplied in the subsequent HTTP request. When this command is received, the following example request is made:

At this point, the remote server will respond with an unencrypted file that the malware saves to the system.

The remote server can also send the following example response. This response will instruct the malware to upload the specified file:

An example upload request can be seen below:

The remote server can also send the following example response. This response will instruct the malware to execute the given command:

The results of this -execution are stored in a temporary text file in the %TEMP% directory. These results are encrypted using the same technique mentioned previously. An example upload of these results can be seen below:

PlugX

PlugX is a backdoor that is often used by actors in targeted attacks. This version of PlugX attempts to disguise itself as a Symantec product. The following icon is present in this sample:

Figure 8. PlugX file uses Symantec logo icon. 

Upon execution, the malware will install itself as a service with the following parameters:

Service Name	RasTls
Service Display Name	RasTls
Service Description	Symantec 802.1x Supplicant

It may also set the following registry key for persistence:

PlugX is a well-studied malware family with a long history of use in targeted attacks. More information on its history is available at the following links.

• https://www.fireeye.com/blog/threat-research/2014/07/pacific-ring-of-fire-plugx-kaba.html
• http://www.sophos.com/en-us/medialibrary/pdfs/technical%20papers/plugx-thenextgeneration.pdf
• https://www.blackhat.com/docs/asia-14/materials/Haruyama/Asia-14-Haruyama-I-Know-You-Want-Me-Unplugging-PlugX.pdf

FormerFirstRAT

This remote administration tool (RAT) is referred to as “FormerFirstRAT” by its authors. FormerFirstRAT communicates using unencrypted HTTP over port 443; the use of mismatching ports and communication protocols is not uncommon in targeted attack campaigns. In addition, port / protocol mis-match traffic can be an indicator of bad activity.

When the malware starts, it writes the following registry key to ensure persistence:

The malware then proceeds to send an HTTP POST request with information about the victim system. The following information is collected:

• Victim IP address
• Username
• Administrative privileges
• RAT status (active/sleep)
• RAT version (in this case, 0.8)
• Microsoft Windows version
• UserID (Volume Serial followed by an underscore and a series of ‘1’s)
• Language

The following settings are used for command and control:

The malware encrypts network communication using the AES128 encryption cipher. It uses the MD5 of ‘tucwatkins’ in order to generate the key. All data is sent via HTTP POST requests. While not a distinct TTP, the author of this malware may be a soap-opera fan. The following code demonstrates how you can decrypt the malware communications using Python:

The malware then enters a loop where it will send out periodic requests to the remote server. The remote server has the ability to respond and provide instructions to the RAT. We have identified the following functionalities:

• Modify sleep timer between requests
• Execute a command and return the command output
• Browse the file system
• Download files
• Delete files
• Exfiltrate victim information

An example HTTP POST request can be seen below.

NFlog

When loaded inside of a running process, NFlog begins by spawning a new thread. This new thread is responsible for all malicious activities produced by this DLL. Initially, the malware will set the following registry key:

Where [current_executable_filename] is the path to the current running executable, which is acquired via a call to GetModuleFileNameA. This registry key ensures that the malware will persist across reboots when the current user logs in.

Multiple string obfuscation routines are included in this malware sample. Strings contained in the binary are decrypted via a simple binary XOR against a single byte key of 0x25.

The malware proceeds to create a named event object of ‘GoogleZCM’ and uses this event in order to ensure only one instance of this malware is running at a given time.

The malware proceeds to make an attempt at binding to the local host on port 1139.

The malware attempts to ensure Internet connectivity by making a request to http://www.microsoft.com. An example request is shown below.

The malware looks for a response ‘Server’ header to contain the string ‘IIS’.

This malware proceeds to check for connectivity to the remote host by making a POST request to the ‘/news/STTip.asp’ URI to the new.hotpmsn[.]com domain. An example is shown below.

The malware then sends out victim information via a POST request to the ‘/news/SNews.asp’ URI. This request also contains a GET parameter of ‘HostID’, which contains the victim’s MAC address. An example request can be seen below.

The included binary data is XORed against a 4-byte key of “\x35\x8E\x9D\x7A”. Once decrypted, we see the following data:

This data contains the following information, separated by the ‘#%#’ delimiter:

• Victim MAC Address (Host ID)
• Command (if available)
• Victim IP address
• Username
• Windows OS version
• Windows language
• Current time
• Status

The server’s response to this request allows this malware to accept a number of commands. The commands and their associated response URIs can be seen below. Please note that all commands must be encrypted using the 4-byte XOR key previously identified.

Command	Description	URI
CMD	Executes provided command	/news/STravel.asp
Browse	Directory listing of provided directory	/news/SJobs.asp
UploadFile	Upload specified file	/news/SSports.asp
DownLoad	Download specified file	/news/SWeather.asp
DelFile	Delete specified file	N/A

PoisonIvy

This malware was identified as the popular PoisonIvy remote access trojan (RAT). The following debug strings were discovered to be embedded within the one of the decrypted dropped files.

• d:\MyProject\Street2008\PotPlayer\Release_Mini_Unicode\PotPlayerMini.pdb

PoisonIvy begins by creating three files in the following locations.

• %APPDATA%\\svchosts.exe
• %APPDATA%\\PotPlayer.dll
• %APPDATA%\\demo.dat

Next, the malware executes the svchosts.exe executable via a call to WinExec. The svchosts.exe malware begins by decrypting the PotPlayer.dll library prior to loading it within it’s own process. It proceeds to load the following exported functions from PotPlayer.dll.

• PreprocessCmdLineExW
• UninitPotPlayer
• CreatePotPlayerExW
• DestroyPotPlayer
• RunPotPlayer
• SetPotPlayRegKeyW

The loading of PotPlayer.dll triggers the DLL’s DllEntryPoint function, which contains the core of the malicious functionality. When PotPlayer.dll is initially loaded, the malware will load and execute a stub of shellcode. This shellcode spawns a new instance of the current executable in a suspended state. It then decrypts the ‘demo.dat’ file using the following algorithm:

This decrypted code is then injected to the suspended process prior to that process being resumed.  This newly created svchost.exe process begins by dynamically loading a number of libraries and functions. The malware consists primarily of shellcode. It then proceeds to create the following mutex:

Next it attempts to delete the original executable. It then sets the following registry key. If running as an administrator, HKLM is used. Otherwise it is set in the context of HKCU.

The malware then begins preparing for network communication. It attempts to identify any proxies that may be present. It collects the victim’s MAC address and hostname and concatenates them into a single string.

PoisonIvy is configured to communicate with the bbs.reweblink[.]com domain. The following example request demonstrates a HTTP request being made:

The following configuration details were extracted from this malware:

RAT Identifier	12008
Proxy Count	0
Communications Key	DF#671d@!
Auto-remove Dropper	True
C&C	bbs.reweblink[.]com:80

NewCT

NewCT 64-bit DLL backdoor that makes periodic requests to its command and control server. This family makes a request to http://www.microsoft.com in order to verify Internet connectivity. This same technique was witnessed in the previously discussed NFlog malware sample.

When Internet connectivity is confirmed, the malware will send a POST request similar to the following:

The following decoded data is contained within the above POST request, including a specific campaign identifier.

Key	0x30303137
Domain	bbs.jpaols.com:80
Victim ID	60F81DCC2FCF_WIN-71FN1PE1AT8
Campaign	APR1_2.3
URI	index.asp

Conclusion

The DragonOK actors appear to have evolved their TTPs, using two new families of malware, one of which appears to be custom-built. However, they have continued using the same email addresses to register domains intended for C2 and / or malware hosting, as well as re-using some of these domains over a period of years.  This means even with new malware they are still fairly easy to track and the new malware itself was not particularly advanced in relation to what the group has used in the past.

While DragonOK actors may not be the most technically advanced, they have demonstrated a high level of persistence in going after their targets time and again over a relatively short period of time.  Many so-called “APT” groups are more persistent than advanced, and DragonOK falls into that category.  Unfortunately, these tools combined with spear-phishing attacks are often successful for malicious actors with enough time. All of the malware samples described in this blog were identified properly by WildFire as malware.

We encourage customers to confirm these indicator sets are in their current security solutions, add them when appropriate, and proactively search their networks for an existing compromise. The ideal security solution employs a platform-based approach that provides protection at each stage of the attack kill-chain, automatically adding new protections as unknown threats are detected.

[1] Operation Quantum Entanglement – Thoufique Haq, Ned Moran, Sai Vashisht, and Mike Scott – https://www.fireeye.com/resources/pdfs/white-papers/fireeye-operation-quantum-entanglement.pdf

Sample Summary

Sysget/HelloBridge

Filename	].exe
First Seen	19 Jan 2015
SHA256	227de988efdcf886bc0be7dc3df9f51a727664593de47352df31757853e42968
C2	biosnews[.]info
Resolution	23.229.234.160
PDB string	D:\Work\1021WinInetGEnc1\Release\WinInetG.pdb

Filename	A.exe
First Seen	27 Jan 2015
SHA256	35784ec1968d322092cb6826f7795f65eeb0b8365ac8c7d8756851c92acf31ae
C2	biosnews[.]info
Resolution	23.229.234.160
PDB string	D:\Work\1021WinInetGEnc1\Release\WinInetG.pdb

Filename
First Seen	10 Mar 2015
SHA256	0b97ced3fabb14dbffa641d9bd1cc9dd8c97eab9cb6160d43202ee078e017989
C2	biosnews[.]info
Resolution	23.229.234.160
PDB string	D:\Work\1021WinInetGEnc1\Release\WinInetG.pdb

Filename	address.exe
First Seen	16 Mar 2015
SHA256	287e29ca7b2177fdaa561a96284726ada636dbbdaadfdbeadf88164e625ed88e
C2	biosnews[.]info
Resolution	23.229.234.160
PDB string	D:\Work\1021WinInetGEnc1\Release\WinInetG.pdb

PlugX

Filename	schost.exe
First Seen	16 Mar 2015
SHA256	70ac649d31db748c4396a9a3f7a9c619c8d09e6400492ab3447520fb726083c4
C2	http.tourecord.com
Resolution	103.20.193.62

PoisonIvy

Filename	shost.exe
First Seen	17 Mar 2015
SHA256	6e95215a52e1cbf4a58cb24c91750151170ea3d59fa9dbfe566e33a2ffc04f4c
C2	bbs.reweblink.com
Resolution	103.20.193.62

FirstFormerRAT

Filename	RpcRtRemote.dll
First Seen	16 Mar 2015
SHA256	e68b70eaaf45fa43e726a29ce956f0e6ea26ece51165a1989e22597aebba244f
C2	https.reweblink.com
Resolution	103.20.193.62

Nflog

Filename	chrome_frame_helper.dll
First Seen	17 Mar 2015
SHA256	64cbcb1f5b8a9d98b3543e3bf342e8c799e0f74f582a5eb0dc383abac7692f63
C2	new.hotpmsn.com
Resolution	58.64.156.140

NewCT

Filename	shost.exe
First Seen	17 Mar 2015
SHA256	6e95215a52e1cbf4a58cb24c91750151170ea3d59fa9dbfe566e33a2ffc04f4c
C2	bbs.reweblink.com
Resolution	103.20.193.62

[Palo Alto Networks Blog]

We’re pleased to share a recent post from Dan Cybulski and CTOVision.com, the research blog of Cognitio Corp., covering a recent discussion by Palo Alto Networks expert Tim Treat at the 2015 Insider Threat Summit in Monterey, Calif.

It is no secret that insider threat is a serious issue that every organization is facing. A look back at 2014 reveals any number of breaches that can be traced back to malicious or exploited insiders. The 2014 Data Breach Investigation Report published by Verizon highlighted that insider threats showed the most significant year over year growth from 2013 to 2014, although this number is likely not indicative of increased insider activity as much as it is proof that organizations are getting better at detecting these threats. But therein lies the problem: today, it seems as though every analytic company has an angle on helping organizations detect the threat, but detecting the threat in stale data limits an organization’s ability to minimize or prevent damage. Interestingly enough, Palo Alto Networks is working on ways to help its customers leverage the high fidelity data coming out of its Enterprise Security Platform…

Read the rest of the post here.

[Palo Alto Networks Blog]

The volume of malware alerts received daily by security teams in Financial Services can reach into the tens of thousands. Properly addressing and prioritizing these alerts requires tools and security products that deliver a high degree of automation and eliminate many of the manual tasks that security teams still have to deal with when they are using traditional products.

During this webinar we describe how an integrated and streamlined approach to security can not only detect the most aggressive threats before they cause any damage, but also block any further propagation of malware through an automated closed loop approach that minimizes the reliance on manual intervention and important security team resources.

[Palo Alto Networks Blog]

With exploit kits readily available to attackers, even ‘good’ applications can go ‘bad.’ Many endpoint security approaches begin by trusting everything, and monitoring for patterns or malicious behaviors, while others attempt to whitelist trusted applications and block the rest. The “Zero Trust model” of information security, coined by Forrester, has traditionally been applied to network communications, but today’s advanced cyber threats warrant a new approach in which the Zero Trust model is extended to endpoints; on the OS, on connected devices, and in memory.

This is particularly important as most resources an attacker might be interested in – data and applications – will live on the endpoint. This webinar, hosted by Sebastian Goodwin, examines how an organization can, and why they should, extend a “never trust, always verify” philosophy to their endpoint security.

[Palo Alto Networks Blog]

It’s no secret that attackers use trusted applications to stealthily launch threats into organizations.

A recent example is the November 2014 attack on Forbes.com where the attacker used two chained zero-day Adobe Flash and Internet Explorer (IE) vulnerabilities hosted on the Forbes.com website to create a watering hole targeting users in financial services industries. Visitors to the exploited page using IE 9+ browsers with the Flash plugin enabled inadvertently downloaded a malicious .SWF file, which allowed attackers to gain control over the victim’s machine. The attack was discovered by Invincea’s threat research team.

Another example, discovered by Alien Vault Labs, occurred in August 2014. Attackers used what was likely a cross-site scripting (XSS) vulnerability on an industrial company’s web site to load Scanbox on to victims’ machines to collect information about what software the machines were running and sent that information back to the attacker.

In the examples above, three different applications were leveraged: Adobe Flash, Internet Explorer, and a web application (web page). These aren’t just occasional occurrences, either. Sujata Ramamoorthy, Cisco’s Director of Information Security, estimated that more than 70 percent of attacks leverage application vulnerabilities.

Thought Experiment: An App-Perfect World

For a second let’s imagine a world where all applications were 100 percent secure all of the time. What would this mean for the world of cybercrime? For starters, it would mean that cybercriminals would be much more hard-pressed in finding ways to attack users and organizations, drastically decreasing not only the ways in which a profit could be earned through cyber crime, but also the amount of profit gained from a successful attack. The extra work involved to find a way to compromise the application would have a negative impact on the criminal organization’s bottom line, which could lead to cuts in funding for attack research and staff.

Making it more difficult (and thus more expensive) to launch a successful attack means fewer attackers and fewer attacks. At the end of the day, hackers have to pay the bills, too. Sure, there would still be armies of nation-state hackers and guys who won’t accept defeat and opt to spend their free time hammering out new attack methods, but the threat landscape would change — drastically, and for the better.

Back to Reality

Of course, I know a world with totally secure applications is just a fantasy. However, that doesn’t mean we are helpless to better protect ourselves against application-borne threats. So, how do you make the applications you’re using or creating more secure and resilient?

1. Use secure coding practices and stringent security testing procedures throughout the software development lifecycle to ensure that your application cannot be used maliciously…

This means making sure applications are architected with security as a priority, right next to functionality, and testing every version or iteration of the software during development, QA, staging, and production. It sounds exhausting, but it’s less exhausting than having to scramble after hemorrhaging customers due to an unpatched production vulnerability that led to a security incident or data breach.

…and taking additional precautions even after the code goes live through patching and tools like web application firewalls and intrusion prevention systems.

Even after thorough testing procedures, a web application firewall or intrusion prevention system can help to block potential evil-doers from combing through applications for attack vectors by alerting on or blocking host sweeps and port scans. In addition to ensuring that your applications aren’t serving up easily-exploited vulnerabilities, these tools also help identify and thwart internal and external users who attempt to access restricted resources or search for potential vulnerabilities.

2. Architect your network so that all traffic and applications on all ports and protocols — including those that use SSL encryption — are visible and void of threats, and data remains secure.

This has to do more with the Zero Trust methodology. Make it incredibly time-consuming and expensive for cybercriminals to target you. Know which applications are being used and what kinds of risks they introduce, and then try to reduce the impact of those risks by limiting the use of unsecured features within those applications, controlling which of your users has access to those application features, and segmenting and securing data to which those applications have access.

Gaining complete visibility into the applications traversing your network and controlling the way users are able to interact with them is paramount to preventing threats that leverage them to access the network. This is a large part of the premise behind the multitude of “next-generation” security products currently on the market: that they can identify traffic and classify it within the context of applications. If you can tie traffic to applications and allow only certain applications onto the network, then you’ve reduced your security risk. If you can then focus on securing potential attack vectors within those applications, real prevention becomes possible.

[Palo Alto Networks Blog]