Over the past few months, I have had the opportunity to talk with a wide range of customers and prospects about their public and private cloud initiatives. Two common themes have arisen from these conversations. The first is that, while there is significant interest in leveraging the public cloud (Amazon Web Services and Azure in particular), there are many questions that still need to be answered. The second and more interesting theme was how organizational changes and an increased focus on DevOps can help improve cloud security.

Here’s why.

While participating in a cloud–focused roundtable with 30 or so CIOs/CISOs, I heard about how organizations are looking to move to the public cloud, what some of the concerns are, and how some are addressing them. The public cloud use cases I heard are primarily internal applications or those that present lower risk. One example was an internal, process-intensive forecasting tool that took days to run. In AWS, they can scale the CPU cycles up and run the application in a matter of hours – a perfect use of the public cloud. In other conversations, all internal application development is moved to the cloud, and separate resources are applied to development, testing, and production. Another way to look at it is that users are taking a cautious approach to testing the public cloud waters.

Most of the 90-minute conversation we had at the roundtable centered on risks and how to manage them. One participant was working to set up a process by which security, networking, and server teams would work together to decide which apps to move to the cloud. As part of the process, he was developing a set of criteria that would be used to decide if the associated data was cloud-worthy.

A second, significant conversation centered on documentation, and who should sign off on what is moved to the cloud. The feeling from most everyone was that most of the exec team should be aware of the efforts and associated risks – some food for thought there.

At both the roundtable and some of my customer engagements, I have been asking how users are managing the dynamics of security, networking and server/development teams. The answers vary widely. Some users admit they are managing it poorly: the groups operate in silos and security is deemed a bottleneck. To break down the walls, one user began holding social functions to bring the groups together with the premise being “get to know your co-worker.” The goal here is that, if they have some familiarity with each other, they may work more efficiently together. At least four of the other users I spoke with had taken the dramatic step of reorganizing the teams so they are working hand in hand. In addition to reorganizing, several took an additional step of offering and encouraging outside education as a means of expanding their skill set. This last step not only provides confidence in the uncertain times of reorganization but also enhances the user’s career – a win on both sides in many cases.

A final observation is that DevOps teams have become more engaged in the effort to include network security in their development efforts, and not just in their coding practices. In this case, network security is being baked into the application as it is developed through the use of tags and APIs.

These elements enable automation, a key tenant in the move towards cloud-first/cloud-ready development efforts. As new application workloads are added, tags assigned to the workloads can be used to automatically add the workload to the security policy. The result is security that keeps pace with the business.

The takeaways from these conversations were that organizations are moving to the public cloud in the right way: with an eye toward benefiting the business and an appropriate level of caution.

What are you doing to bring these teams together in your organization? Leave a comment and let me know.

Matt Keil

[Palo Alto Networks Blog]

This is the twelfth in our series of cybersecurity predictions for 2016. Stay tuned for more through the end of the year.

After yet another year of significant breaches of major organizations, senior executives have finally woken up to the threat of cyberattacks and are searching for answers to how to make the proper investments in people, process, and technology to develop a prevention mindset. To me, this will manifest itself in several ways in 2016:

The number of boards that actively address and govern computer and information security will increase

It has been a tough few years for companies and organizations seeking to avoid the headlines after suffering a major data breach, as hundreds of millions of records have been stolen from organizations, compromising sensitive intellectual property, credit card numbers, and even personal health information. In turn, corporate executives and boards of directors have realized that cybersecurity represents a significant enterprise risk and have shifted to risk management approaches in order to better fulfill their fiduciary obligations to protect the assets of their organizations.

In 2015 we witnessed a definitive shift in the way that senior corporate leadership and boards view cybersecurity; the needle has moved. Indeed, the 2015 Governance of Cybersecurityreport from Georgia Tech and Palo Alto Networks found that 63 percent of boards are actively addressing and governing computer and information security – nearly a two-fold increase from the 2012 report.

In 2016 we will continue to see this upward trend of active, board-level governance of cybersecurity activities, as cyber becomes more relevant to most, if not all, lines of business operations. Because of the rapid growth in threats to physical infrastructure, in particular, we predict, and trends support, that boards in the industrial and energy/utility industries will continue to raise their levels of involvement and governance to those of the financial services and IT/telecom industries.

Executives and board members will shift from awareness to accountability and action

With the entrenchment of cybersecurity as a senior executive and board-level issue, awareness campaigns will become less pertinent and there will be an increased focus on practical business-level cybersecurity discussions aimed at helping boards and executives better protect their businesses. In 2016, boards and executives will “get it,” and will, consequently, need better advice on “what to do about it.”

While, as mentioned above, two-thirds of boards are actively addressing and governing cybersecurity, another 2015 survey conducted by the New York Stock Exchange and Veracodefound that only a third of boards have some degree of confidence that their companies are properly secured against cyberattacks. The same survey also found that boards are most likely to hold the CEO and the entire executive team accountable for a major incident.

With executives and boards more focused on CEOs, and executive teams clearly identified as accountable for managing cybersecurity risk, we believe that 2016 will see increasing interest in business-level frameworks to assist in related decision-making. While there are many technical security models, executives and boards lack similar models to evaluate the essential productivity-versus-risk question of cybersecurity. Moreover, unlike other functions of a business, cybersecurity does not yet have well-established and rigorous analytical tools to inform decision-making. Nevertheless, there are several efforts underway to address this gap.

Expect to see increasing attention paid to the work of organizations like the World Economic Forum, which this year debuted a “cyber value-at-risk” framework at its Annual Summit in Davos, Switzerland that attempts to capture existing vulnerabilities, value of assets, and profile of attackers with the ultimate goal of modeling potential losses related to cybersecurity incidents over a given period of time at a high confidence level.

Following the landmark move of Institutional Shareholder Services (ISS) to advise against the re-election of seven of Target’s ten board members in the wake of that company’s major 2014 breach, expect to see more cybersecurity-related shareholder action in 2016’s proxy season, particularly for companies that have experienced incidents to date.

Restructuring cybersecurity governance and reporting

Finally, we predict that 2016 will bring a major shift in that more CISOs will report directly to the CEO, putting those individuals on par with other senior officers. The CEO is ultimately responsible for the risk of a business, a responsibility he or she cannot delegate to any subordinate. As companies continue to shift toward a risk management approach to cybersecurity, the CISO and CIO must be peers to allow for a healthy and balanced productivity-versus-risk discussion that informs decision-making. This represents a significant departure from the status quo of CISO reporting, and this shift will take time, but we believe it will begin in earnest next year.

Want to explore more of our top 2016 cybersecurity predictions? Register now for Ignite 2016.

Will Howerton

[Palo Alto Networks Blog]

On the 15th of December, after much debate, what was first proposed back in 2012 will finally be established: the European Union has come to agreement on the General Data Protection Regulation (GDPR), which updates and replaces Europe’s Data Protection Directive – rules that were first defined in 1995 (directive 95/46/EC).

As business and cybersecurity leaders, what’s critical is the way in which we choose to interpret and respond to these changes that are now defined.

Why reform the Data Protection laws?

Since 1998, when the Data Protection Directive was originally implemented, the scale and scope of information stored online has significantly changed, so it makes sense to review the requirements to protect citizens’ privacy when online.

It is also a chance to make the regulation more manageable for businesses to follow; for example, it aims to reduce the audit burden and simplify application by harmonization across member countries. Previously each country had interpreted the directive in its own way, creating 28 flavors of the rules.

The new GDPR has garnered significant attention as it has been negotiated. One provision that has created much debate is the planned requirement for companies holding EU citizens’ data to have to notify their national regulator of any significant breach of personal data “without undue delay and, where feasible, not later than 72 hours after having become aware of it”.

Seen through numerous research reports, it often takes months to identify and respond to breaches today. The introduction of common GDPR penalties (capped at €10M–20M or 2%–4% of total worldwide annual turnover dependent on the type and level of infringement related to breaches, such as failure to notify) has made this a focal point as, commonly, the penalties and breach notification make headlines. For many the fear of brand impact and potential fines grabs the attention of most businesses. However the scope of fines is broader, as shown in the examples in the table, below (please note: this is not exhaustive or complete list):

Specifically in regard to breach notification, these penalties are not aimed to kick a business when it’s down, rather encourage businesses to notify in the defined time scales and ensure they have the appropriate “regard for the state of the art” controls in place to prevent such incidents from occurring.

The GDPR states that companies must implement appropriate technical and organizational measures with regard to the “state of the art”, that can ensure a level of security appropriate to risk. Fines aligned to articles in the revision, I would suggest, aim to be the motivator for businesses to raise the bar on good cybersecurity application. As citizens we expect businesses to comply to keep our data safe.

Your core decision?

It would be easy to review the above and consider your focus must now be on incident response; that typically means either building or growing the staff and capabilities you have in order to both discover and do the forensic analysis on a cyber incident.

The challenge here is threefold: firstly it does not address the cause of the breach problem; secondly it’s dependent on a skilled staff, which is a limited resource; thirdly it’s costly both in terms of the money and people required if you keep needing to respond.

As mentioned the regulation reform highlights the need for “regard for the state of the art”; my encouragement would be that this is where you should focus. If you have better protection so preventing incidents, you take away the heavy response requirements.

So why are we seeing more and more breaches in recent times?

Cybersecurity today is as complex as the IT that it’s protecting, with multiple components that must function together to identify and block the attacker. The challenge is that it’s based on legacy underpinnings.

Consider the city of London, which is believed to have been founded in 43 A.D. The transport infrastructure put in by the Romans soon after, which is still the foundation of much of the city’s key roads, simply struggle to stand up to today’s demands. If London traffic is typically a jam, consider some modern cities that have far more effective systems build leveraging modern state-of-the-art concepts, such as driverless cars, alternative transport, and traffic management systems to mention but a few.

In much the same way, we have put in security products based on their own capabilities; yet, today we have so many, the demands they each add independently stretch IT teams; then add the multiplier effect of getting them to work together. Quite literally we leverage some great technologies, but the underlying infrastructure is lacking and manual, so we are slow to find today’s complex attacks that require gathering data from across multiple solutions. The key point here is that “state of the art” means leveraging both the technical capabilities available today and the processes that allow people to function efficiently. The overall capabilities cannot be constrained by legacy components.

Considerations as you start to plan to comply with the GDPR

Obviously there are some key aspects, such as ensuring you understand the details and the timelines of the regulation, and its adoption, as they are published. But as you start to consider your strategy around achieving state of the art, or at least regard for it, ask yourself the following questions: 

• Is your cyber strategy and underlying infrastructure as old as the Data Protection Directive?

Cyber and the security available to enable it evolve at a tremendous pace. When did you last step back and consider just what is possible in terms of good, state-of-the-art cybersecurity best practices? Then define the transformation plan to move your business to this. For most the legacy challenge is the shackles that holds us back. If you were to build a cybersecurity strategy from scratch today, I suspect there would be some significant changes from what you have in place currently.

• How do you measure “state-of-the-art cybersecurity”?

Today the most common measure I see used is: did we find it, which, given enough tools and resources we can always achieve; however most don’t have unlimited access to either. Considering that the volume of threats seems only likely to increase, so will the scale of information we need to protect; we need to become increasingly efficient. As such we need a measure that looks at efficiency, which for me would be: How long does it take to detect? This is a measure we can monitor reactively but also proactively test. I would challenge that, when you fall below what you consider your acceptable timeframe, your security is no longer state- of-the-art, and you should be reviewing what and how you adapt/evolve to return to your defined measure.

• What is the acceptable workload for any security solution (operational efficacy and efficiency)?

To work at digital speed, you need solutions that are operationally efficient. You must consider what is an acceptable level of human interaction for any solution. Typically the lower the efficacy and/or the greater the human interaction the more you move from an automated to a manual solution. Today’s threats typically require correlation across multiple solutions to accurately detect; so, when considering the workload, you must also consider both the individual overhead and additional overhead needed to aggregate/correlate into a single platform.

All of these should start to identify just what the gap is today in your organization, allowing you to define the transformation plan to meet the requirements set out in the regulation reform.

Summary

Over the coming months, there will be a huge amount of discussion around the reform of data protection in the EU. The GDPR enters into force once published in the Official Journal of the European Union – a step that still needs to occur and will apply two years from that date. Thus, it is likely to be fully in effect in early 2018. Until now most held back from action, as the scope was not finalized.

Now you have a clear understanding of the expectations as you move from awareness to action.

In one respect this allows you to gain additional support from the business, as the new regulation is a very clear business mandate and driver; yet how we turn this into action, I would suggest, is open to interpretation. You can focus in on the notification requirement; or you can focus in on the underlying principle behind the reform, which was to raise the bar on cybersecurity, pulling capabilities closer to the state of the art that would better protect citizens’ data and prevent breaches from occurring. Nirvana would be that we never have to notify; the more we can move to an automated state-of-the-art approach that scales to current and future IT requirements, the closer we will get.

Greg Day

[Palo Alto Networks Blog]

Last week we hosted the first ever Unit 42 Twitter chat with several of our Unit 42 experts, including Ryan Olson (@ireo), Jen Miller Osborn (@jadefh), Robert Falcone (@r0bf4lc), and Bryan Lee (@obiwanblee). The chat, “Sure Things and Long Shots, A Look at the 2016 Threat Landscape,” tackled questions from the biggest shifts in the threat landscape to the most effective measures to protect against those threats, and the best ways people can protect themselves in 2016.

The #PANWchat also served as the official launch of the new @Unit42_Intel Twitter handle, which moderated yesterday’s chat. Make sure to follow @Unit42_Intel for the latest from our Unit 42 team.

Take a look at some of the highlights from the chat below or catch up on the entire conversation through the #PANWchat hashtag. And be sure to check out our ongoing series of predictions for 2016!

How do you see threat landscape continuing to evolve in 2016?

What have been the most effective measures to protect against those threats?

What is your most surprising “long shot” prediction for 2016? Why?

How can the average consumer protect themselves against the threats of 2016?

How will the practice of threat research evolve in 2016?

Thank you to everyone who participated in and followed the #PANWchat. We look forward to doing more of these chats in the future.

In the meantime, make sure to follow @Unit42_Intel for the latest research reports and news from Unit 42, the Palo Alto Networks threat intelligence team.

Anna Lough

[Palo Alto Networks Blog]

We observed a targeted attack in November directed at an individual working for the French Ministry of Foreign Affairs. The attack involved a spear-phishing email sent to a single French diplomat based in Taipei, Taiwan and contained an invitation to a Science and Technology support group event.

The actors attempted to exploit CVE-2014-6332 using a slightly modified version of the proof-of-concept (POC) code to install a Trojan called Emissary, which is related to the Operation Lotus Blossom campaign. The TTPs used in this attack also match those detailed in the paper. The targeting of this individual suggests the actors are interested in breaching the French Ministry of Foreign Affairs itself or gaining insights into relations between France and Taiwan.

We have created the Emissary tag for AutoFocus users to track this threat.

En garde!

On November 10, 2015, threat actors sent a spear-phishing email to an individual at the French Ministry of Foreign Affairs. The subject and the body of the email suggest the targeted individual had been invited to a Science and Technology conference in Hsinchu, Taiwan. The e-mail appears quite timely, as the conference was held on November 13, 2015, which is three days after the attack took place.

The email body contained a link to the legitimate registration page for the conference, but the email also had two attachments with the following filenames that also pertain to the conference:

1. 蔡英文柯建銘全國科技後援會邀請函.doc (translates to “Tsai Ker Chien-ming National Science and Technology Support Association invitations.doc”)
2. 書面報名表格.doc (translates to “Written Application Form.doc”)

Both attachments are malicious Word documents that attempt to exploit the Windows OLE Automation Array Remote Code Execution Vulnerability tracked by CVE-2014-6332. Upon successful exploitation, the attachments will install a Trojan named Emissary and open a Word document as a decoy.

The first attachment opens a decoy (Figure 2) that is a copy of an invitation to a Science and Technology conference this past November 13th held in Hsingchu, Taiwan, while the second opens a decoy (Figure 1) that is a registration form to attend the conference. The conference was widely advertised online and on Facebook, however in this case the invitation includes a detailed itinerary that does not seem to have appeared online. The Democratic Progressive’s Party (DPP) Chairwoman Tsai Ing-wen and DPP caucus whip and Hsinchu representative Ker Chien-ming were the primary political sponsors of the conference and are longtime political allies. Tsai Ing-wen is the current front-runner for the Taiwanese Presidency and Ker Chien-ming may become Speaker if she wins. The conference focused on using open source technology, open international recruiting, and partnerships to continue developing Hsinchu as the Silicon Valley of Taiwan. It particularly noted France as an ally in this, and France is Taiwan’s second largest technology partner and fourth largest trading partner in Europe.

Figure 1 Decoy document containing written application form

Figure 2 Decoy document containing the invitation and agenda for event

Exploiting CVE-2014-6332

The threat actors attempted to exploit CVE-2014-6332 using the POC code available in the wild. The POC code contains inline comments that explain how the malicious VBScript exploits this vulnerability, so instead of discussing the malicious script or exploit itself, we will focus on the portions of the script that the threat actors modified.

The actors removed the explanatory comments from the VBScript and made slight modifications to the POC code. The only major functional difference between the POC and the VBScript involved adding the ability to extract and run both a decoy document and payload. Figure 3 and 4 compare the differing “runshell” command within the POC and the malicious documents used in this attack. The code in Figure 3 shows that the POC does nothing more than launch the notepad.exe application upon successful exploitation. Figure 4 shows the malicious document creating a file named “ss.vbs” that it writes a VBScript to using a series of “echo” statements. After writing the VBScript, the malicious document executes the “ss.vbs” file.

Figure 3 Code block containing “runshell” function in CVE-2014-6332 proof-of-concept VBScript

Figure 4 Code block containing “runshell” function in malicious VBScript within attachment

The ss.vbs file is responsible for locating the payload and decoy document from the initial malicious document, as well as decrypting, saving and opening both of the files. The script has hardcoded offsets to the location of both the payload and decoy document within the initial document. The script will decrypt both of the embedded files using a two-byte XOR loop that skips the first byte and then decrypts the remaining using “A” and “C” as the key. After decrypting the embedded files, the script saves the decoy to “t.doc” and the payload to “mm.dll” in the “%APPDATA%\LocalData” folder. Finally, the script will open the decoy document and launch the payload by calling its exported function named “Setting”.

Figure 5 VBScript within ss.vbs responsible for extracting and running the payload and decoy

Emissary 5.3 Analysis

The payload of this attack is a Trojan that we track with the name Emissary. This Trojan is related to the Elise backdoor described in the Operation Lotus Blossom report. Both Emissary and Elise are part of a malware group referred to as “LStudio”, which is based on the following debug strings found in Emissary and Elise samples:

d:\lstudio\projects\worldclient\emissary\Release\emissary\i386\emissary.pdb

d:\lstudio\projects\lotus\elise\Release\EliseDLL\i386\EliseDLL.pdb

There is code overlap between Emissary and Elise, specifically in the use of a common function to log debug messages to a file and a custom algorithm to decrypt the configuration file. The custom algorithm used by Emissary and Elise to decrypt their configurations use the “srand” function to set a seed value for the “rand” function, which the algorithm uses to generate a key. While the “rand” function is meant to generate random numbers, the malware author uses the “srand” function to seed the “rand” function with a static value. The static seed value causes the “rand” function to create the same values each time it is called and results in a static key to decrypt the configuration. The seed value is where the Emissary and Elise differ in their use of this algorithm, as Emissary uses a seed value of 1024 (as seen in Figure 6) and Elise uses the seed value of 2012.

Figure 6 Custom algorithm in Emissary using ‘srand’ and ‘rand’ with 1024 as a seed value

While these two Trojans share code, we consider Emissary and Elise separate tools since their configuration structure, command handler and C2 communications channel differ. The Emissary Trojan delivered in this attack contains the components listed in Table 1. At a high level, Emissary has an initial loader DLL that extracts a configuration file and a second DLL containing Emissary’s functional code that it injects into Internet Explorer.

Table 1 Dropped files associated with Emissary Trojan seen in attack on French Ministry of Foreign Affairs

The loader Trojan named “ishelp.dll” had an original name of “Loader.dll”, which will extract the Emissary payload from a resource named “asdasdasdasdsad” and write it to a file named “A08E81B411.DAT”. The loader will then write an embedded configuration to a file named “75BD50EC.DAT”. The loader Trojan creates a mutex named “_MICROSOFT_LOADER_MUTEX_” and finishes by injecting the Emissary DLL in “A08E81B411.DAT” into a newly spawned Internet Explorer process.

The Emissary Trojan runs within the Internet Explorer process. It begins by reading and decrypting its configuration file, which has the following structure:

We decrypted and parsed the configuration file that accompanied the payload used in this attack, which resulted in the following settings:

Version: 5.3
GUID: ba87c1c5-f71c-4a8b-b511-07aa113d9103
C2 Server 1: http://ustar5.PassAs[.]us/default.aspx
C2 Server 2: http://203.124.14.229/default.aspx
C2 Server 3: http://dnt5b.myfw[.]us/default.aspx
Campaign Code: UPG-ZHG-01
Sleep Delay: 300

After decrypting the configuration file, Emissary interacts with its command and control (C2) servers using HTTP or HTTPS, depending on the protocol specified in the configuration file. The initial network beacon sent from Emissary to its C2 server, seen in Figure 7, includes a Cookie field that contains a “GUID”, “op” and “SHO” field. The GUID field is a unique identifier for the compromised system that is obtained directly from the configuration file. The op field has a value of “101”, which is a static value that represents the initial network beacon. The SHO field contains the external IP address of the infected system, which Emissary obtains from a legitimate website “showip.net”, specifically parsing the website’s response for ‘<input id=”checkip” type=”text” name=”check_ip” value=’, which contains the IP address of the system.

Figure 7 Network beacon sent from Emissary Trojan to C2 server

The C2 server response to this beacon (seen in Figure 8) will contain a header field called “Set-Cookie”, which contains a value of “SID”. The SID value is base64 encoded and encrypted using a rolling XOR algorithm, which once decoded and decrypted contains a 36-character GUID value. The Emissary Trojan will use this GUID value provided by the C2 server as an encryption key that it will use to encrypt data sent in subsequent network communications.

Figure 8 C2 response to Emissary beacon

The C2 server provides commands to the Trojan as a three digit numeric string within the data portion of the HTTP response (in the form of “op=<command>”), which the Emissary Trojan will decrypt and compare to a list of commands within its command handler. The command handler function within the Emissary Trojan supports six commands, as seen in Table 2.

Table 2 Command handler within Emissary version 5.3

If the command issued from the C2 server does not match the one listed in the Trojan saves the message “unkown:%s” to the log file. The command set available within Emissary allows the threat actors backdoor access to a compromised system. Using this access, the threat actors can exfiltrate data and carry out further activities on the system, including interacting directly with the system’s command shell and downloading and executing additional tools for further functionality.

Threat Infrastructure

The infrastructure associated with the Emissary C2 servers used in this attack includes ustar5.PassAs[.]us, 203.124.14.229 and dnt5b.myfw[.]us. The infrastructure is rather isolated as the only overlap in domains includes appletree.onthenetas[.]com. The overlap, as seen in Figure 9 involves two IP addresses that during the same time frame resolved both the appletree.onthenetas[.]com domain and the Emissary C2 domain of ustar5.PassAs[.]us. The other C2 domain used by this Emissary payload, specifically dnt5b.myfw[.]us currently resolves to the 127.0.0.1. This provides another glimpse into TTPs for these threat actors, as it suggests that the threat actors set the secondary C2 domains to resolve to the localhost IP address to avoid network detection and change this to a routable IP address when they need the C2 server operational. Additionally, while this infrastructure does not overlap with that used in Operation Lotus Blossom, that also fits with the TTPs. In each case, the threat actors used separate infrastructure for different targets, another way to help avoid detection.

Figure 9 Infrastructure associated with Emissary Trojan

Conclusion

APT threat actors, most likely nation state-sponsored, targeted a diplomat in the French Ministry of Foreign Affairs with a seemingly legitimate invitation to a technology conference in Taiwan. It is entirely possible the diplomat was truly invited to the conference, or at least would not have been surprised by the invitation, adding to the likelihood the attachment would have been opened. The actors were attempting to exploit CVE-2014-6332 to install a new version of the Emissary Trojan, specifically version 5.3.

The Emissary Trojan is related to the Elise malware used in Operation Lotus Blossom, which was an attack campaign on targets in Southeast Asia, in many cases also with official looking decoy documents that do not appear to have been available online. Additionally, the targeting of a French diplomat based in Taipei, Taiwan aligns with previous targeting by these actors, as does the separate infrastructure. Based on the targeting and lures, Unit 42 assesses that the threat actors’ collection requirements not only include militaries and government agencies in Southeast Asia, but also nations involved in diplomatic and trade agreements with them.

Indicators

Related Hashes
748feae269d561d80563eae551ef7bfd -書面報名表格.doc
9fd6f702763a9840bd1b3a898eb9c62d -蔡英文柯建銘全國科技後援會邀請函.doc
06f1d2be5e981dee056c231d184db908 – ishelp.dll
6278fc8c7bf14514353797b229d562e8 – A08E81B411.DAT
e9f51a4e835929e513c3f30299567abc – 75BD50EC.DAT

Command and Control
203.124.14.229
ustar5.PassAs[.]us
appletree.onthenetas[.]com
dnt5b.myfw[.]us

Robert Falcone and Jen Miller-Osborn

[Palo Alto Networks Blog]