SEATTLE, WA and LONDON – JUNE 5, 2018 – InfoSecurity Europe Conference – The Cloud Security Alliance (CSA), the world’s leading organization dedicated to defining standards, certifications and best practices to help ensure a secure cloud computing environment, today released the CSA Code of Conduct (CoC) Self-Assessment. An essential tool for those charged with General Data Privacy Requirements (GDPR) compliance, the CSA CoC Self-Assessment provides a transparent means for standardizing compliance initiatives.
“The CSA Code of Conduct for GDPR Compliance is a comprehensive and complete resource for supporting cloud providers’ compliance and fostering accountability and transparency in the market. Today, with the release of the CSA CoC Self Assessment, we are offering cloud service providers the opportunity to openly demonstrate to business partners and regulators evidence of their adherence to the GDPR requirements. The CSA CoC Self Assessment acts as the assurance and transparency component of the STAR Program,” said Daniele Catteddu, CSA Chief Technology Officer, lead outside counsel and Privacy Level Agreement (PLA) Working Group co-chair. “We believe it will go a long way toward providing the industry with a standard for accurate compliance with the GDPR.”
“The release of the CSA CoC Self Assessment serves two purposes,” said Paolo Balboni, European ICT, privacy and data protection lawyer, and co-chair of the PLA Working Group. “First, to afford cloud service providers (CSP) a means to demonstrate, in a structured way, the level of personal data protection they offer, and second, to provide cloud customers and potential customers a tool to evaluate and compare the level of personal data protection offered by various CSPs. And while the CSA CoC Self-Assessment is not verified by a qualified third-party, it does offer transparency regarding the level of protection offered by a cloud service provider.”
CSPs and cloud customers that would like to adhere to the CSA CoC for GDPR should submit the CoC Statement of Adherence and PLA Code of Practice (CoP) Template – Annex 1 using the STAR submission form found here. CSA will then verify that a “good faith” effort has been made to thoroughly address the entire Code of Conduct and then will publish the Self Assessment on STAR. The applicant will receive a self-attestation compliance mark once all the necessary conditions are satisfied.
Those interested in learning more about the CSA Code of Conduct for GDPR Compliance should visit the CSA GDPR Resource Center, a community-driven website with tools and resources to help educate cloud service providers and enterprises on the new European data protection regulation.
The CSA PLA Working Group is comprised of independent privacy and data protection subject matter experts, privacy officers, and representatives from data protection authorities. It was formed in 2012 to help transpose the Art. 29 WP and EU National Data Protection Regulators’ recommendations on cloud computing into an easy-to-use outline for CSPs to follow when disclosing personal data-handling practices. The scope and objective of the PLA initiative were previously presented to the European Parliament as part of discussions on the potential effect of the proposed General Data Protection Regulation on cloud computing. Since then, the PLA Working Group engages in defining a structured method for communicating the level of privacy that a CSP agrees to maintain.
About Cloud Security Alliance
The Cloud Security Alliance (CSA) is the world’s leading organization dedicated to defining and raising awareness of best practices to help ensure a secure cloud computing environment. CSA harnesses the subject matter expertise of industry practitioners, associations, governments, and its corporate and individual members to offer cloud security- specific research, education, certification, events and products. CSA’s activities, knowledge and extensive network benefit the entire community impacted by cloud — from providers and customers, to governments, entrepreneurs and the assurance industry — and provide a forum through which diverse parties can work together to create and maintain a trusted cloud ecosystem.
Many analyses of cybersecurity include consideration of the field’s constant state of flux and change. As the battlefield of the internet evolves, typically, so do the attack strategies, weapons, defense mechanisms and actors. However, according to ISACA’s 2018 State of Cybersecurity research, two elements that remain relatively constant are the types of attackers and the type of attack leveraged.
Specifically, based upon the input of respondents, the report noted that while attacks are increasing, outside of certain niche variants, the types of attacks have remained constant, with monetary theft as the main aim of most attackers. These trends identify that while certain cybersecurity considerations change, proven attackers, victims and attack processes will never go out of style.
Deeper examination of the report provides a greater understanding of the static trend of attack types by malicious actors. Survey respondents indicate that the three main attack mechanisms leveraged against their organizations are phishing, malware and social engineering. When compared to the 2017 report, this trend remains mostly static, with minimal variation. Additionally, the cybercriminal attacker profile remained steady as the attacker type.
While the main attack vectors and actors remain primarily static, the number of attacks are increasing dramatically, with the majority of respondents indicating that the number of attacks they are experiencing are increasing year over year. This trend could be due to multiple considerations. For example, as artificial intelligence (AI) enables business processes, malicious agents can also leverage AI to streamline attacks. This increase in efficiency allows an attacker to conduct more attacks with less infrastructure. Additionally, greater accessibility to the growing dark web allows attackers to work together more easily than in the past.
Though attackers might leverage certain tools to increase their operational efficiency, and thus their attack capability, others have found themselves largely relegated to the dustbin. Specifically, the report identified a substantive decrease, nearly 20%, in ransomware attacks. This might seem shocking considering high-profile ransomware incidents such as the one that recently hit the city of Atlanta in the United States, wherein many city operations remained crippled for more than a week. However, deeper analysis identifies that most organizations now have a response plan inclusive of a potential ransomware attack and are less willing to pay the ransom requested by attackers.
The decrease in ransomware attacks, coupled with the steady state of phishing, malware and social engineering, hint at one of the basic truisms of cybersecurity – the greatest weakness in organizations is often its individuals. When considering ransomware response, it’s easy to identify that proper backup policies and procedures can render an organization relatively ransomware-proof. If an attack occurs, cybersecurity response teams can commence mitigation by rolling out the most recent proven backup image to the impacted machines while hardening them from subsequent attack. This action is relatively independent of individual sentiment and discernment. However, phishing and social engineering are still reliant, primarily, upon the discernment of an individual expected to implement proper cybersecurity hygiene in his or her daily activities.
Although attacks are on the rise, it is important to remember that efforts to combat them are increasing as well. Indeed, based upon analysis of the report, the defense mechanisms and policies established by organizations can act as indicators as to why ransomware attacks are declining. Yet, while certain niche attacks might change over time, proven attack tools, such as phishing, social engineering, and malware, are here for the long-haul. As long as individuals do not practice appropriate cybersecurity hygiene, they will remain the main attack methods for malicious actors who are attempting to defraud organizations.
Frank Downs, Director and SME, Cyber Security Practice, ISACA
The Sofacy group remains a persistent global threat. Unit 42 and others have shown in the first half of 2018 how this threat actor group continues to target multiple organizations throughout the world with a strong emphasis on government, diplomatic and other strategic organizations primarily in North America and Europe.
Following up our most recent Sofacy research in February and March of 2018, we have found a new campaign that uses a lesser known tool widely attributed to the Sofacy group called Zebrocy. Zebrocy is delivered primarily via phishing attacks that contain malicious Microsoft Office documents with macros as well as simple executable file attachments. This third campaign is consistent with two previously reported attack campaigns in terms of targeting: the targets were government organizations dealing with foreign affairs. In this case however the targets were in different geopolitical regions.
An interesting difference we found in this newest campaign was that the attacks using Zebrocy cast a far wider net within the target organization: the attackers sent phishing emails to a an exponentially larger number of individuals. The targeted individuals did not follow any significant pattern, and the email addresses were found easily using web search engines. This is a stark contrast with other attacks commonly associated with the Sofacy group where generally no more than a handful of victims are targeted within a single organization in a focus-fire style of attack.
In addition to the large number of Zebrocy attacks we discovered, we also observed instances of the Sofacy group leveraging the Dynamic Data Exchange (DDE) exploit technique previously documented by McAfee. The instances we observed, however, used the DDE exploit to deliver different payloads than what was observed previously. In one instance the DDE attack was used to deliver and install Zebrocy. In another instance, the DDE attack was used to deliver an open-source penetration testing toolkit called Koadic. The Sofacy group has leveraged open source or freely available tools and exploits in the past but this is the first time that Unit 42 has observed them leveraging the Koadic toolkit.
Links to previous attacks
In our February report, we discovered the Sofacy group using Microsoft Office documents with malicious macros to deliver the SofacyCarberp payload to multiple government entities. In that report, we documented our observation that the Sofacy group appeared to use conventional obfuscation techniques to mask their infrastructure attribution by using random registrant and service provider information for each of their attacks. In particular, we noted that the Sofacy group deployed a webpage on each of the domains. This is odd because attackers almost never set up an actual webpage on adversary C2 infrastructure. Even stranger, each webpage contained the same content within the body. Since that report, we continued our research into this oddity. Using this artifact, we were able to pivot and discover another attack campaign using the DealersChoice exploit kit with similar victimology to what we saw in February. Continuing to use this artifact, we discovered another domain with the same content body, supservermgr[.]com. This domain was registered on December 20, 2017 and within a few days was resolving to 92.222.136[.]105, which belonged to a well-known VPS provider often used by the Sofacy group.
Unfortunately, at the time of collection, the C2 domain had been sinkholed by a third party. Based on dynamic and static analysis of the malware sample associated with the supservermgr[.]com domain however, we were able to determine several unique artifacts which allowed us to expand our dataset and discover additional findings. First, we determined the sample we collected, d697160ae… was attempting to communicate to its C2 at hxxp://supservermgr[.]com/sys/upd/pageupd.php to retrieve a Zebrocy AutoIT downloader. Because the domain had been sinkholed, this activity could not be completed. However, we were able determine a unique, hard-coded user agent used for the C2 communications:
Using AutoFocus, we pivoted from the user agent string to expand our data set to three additional Zebrocy samples using the exact same user agent. This led us to additional infrastructure for Zebrocy at 185.25.51[.]198 and 185.25.50[.]93. At this point we had collected nearly thirty samples of Zebrocy in relation to the original sample and its associated C2 domain. Additional pivoting based on artifacts unique to this malware family expanded our dataset to hundreds of samples used over the last several years. Most of the additional samples were the Delphi and AutoIT variants as reported by ESET. However, several of the collected samples were a C++ variant of the Zobracy downloader tool. In addition, we discovered evidence of a completely different payload in Koadic being delivered as well. Also, we found the IP address 185.25.50[.]93 hosting C2 services for a Delphi backdoor that ESET’s report states is the final stage payload for these attacks.
A Maltego chart diagramming the relational analysis we performed is below:
Figure 1 Visualization of relationships
Please note this is not a comprehensive chart of all Zebrocy and Koadic samples we were able to collect. Only samples mentioned or relevant to the relational analysis have been included.
From the 185.25.50[.]93 C2 IP, we discovered another hard-coded user agent being used by Zebrocy:
Mozilla/5.0 (Windows NT 6.1; WOW64) WinHttp/1.6.3.8 (WinHTTP/5.1) like Gecko
We observed several samples of Zebrocy using this user agent targeting the foreign affairs ministry of a large Central Asian nation. Pivoting off of this artifact provided us additional Zebrocy samples. One sample in particular, cba5ab65a… used yet another unique user agent string in combination with the previous user agent for its C2:
Mozilla v5.1 (Windows NT 6.1; rv:6.0.1) Gecko/20100101 Firefox/6.0.1
A malware sample using two separate unique user agent strings is uncommon. A closer examination of the tool revealed the second user agent string was from a secondary payload that was retrieved by the cba5ab65a… sample. Pivoting from the Mozilla v5.1 user agent revealed over forty additional Zebrocy samples, with several again targeting the same Central Asian nation. Two samples specifically, 25f0d1cbc… and 115fd8c61… provided additional artifacts we were able to pivot from to discover weaponized documents to deliver Zebrocy as well as a Koadic.
Examining the use of the unique user agents’ strings over time shows that while previously only the Mozilla/5.0 user agent was in use, since mid 2017 all three user agent strings have been used by the Zebrocy tool for its C2 communications.
Figure 2 Timeline of User Agents
DDE Documents
The two weaponized documents we discovered leveraging DDE were of particular interest due to victimology and a change in tactics.
While examining 25f0d1cbc…, we were able to pivot from its C2 220.158.216[.]127 to gather additional Zebrocy samples as well as a weaponized document. This document (85da72c7d…) appears to have been targeting a North American government organization dealing with foreign affairs. It leveraged DDE to retrieve and install a payload onto the victim host. A decoy document is deployed in this attack, with the contents purporting be a publicly available document from the United Nations regarding the Republic of Uzbekistan.
Figure 3 Example of delivery document
Figure 4 Lure image used
The creator of the weaponized document appended their DDE instructions to the end of the document after all of the decoy contents. When the document is opened in Word, the instructions are not immediately visible, as Word does not display these fields contents by default. As you can see in the following screenshot, simply attempting to highlight the lines in which the DDE instructions reside does not display them.
Figure 5 Hidden DDE commands
Enabling the “Toggle Field Codes” feature reveals the DDE instructions to us and shows that the author had set instructions to size 1 font and with a white coloring. The use of a white font coloring to hide contents within a weaponized document is a technique we had previously reported being used by the Sofacy group in a malicious macro attack.
The DDE instructions attempt to run the following the following command on the victim host, which attempts to download and execute a payload from a remote server:
During our analysis, we observed this DDE downloading and executing a Zebrocy AutoIt downloader (f27836430…), configured to attempt to download an additional payload from 220.158.216[.]127. The DDE instructions also included another command that it did not run, which suggests it is an artifact of a prior version of this delivery document. The following shows this unused command, which exposed an additional server within Sofacy’s infrastructure would download and execute an encoded PowerShell script from 92.114.92[.]102:
The unused command above appears to be related to previous attacks, specifically attacks that occurred in November 2017 as discussed by McAfee and ESET. The payload delivered in these November 2017 attacks using DDE enabled documents was SofacyCarberp, which differs from the Zebrocy downloader delivered in the February 2018 attacks.
115fd8c61… was another Zebrocy sample we were able to pivot from by gathering additional samples connecting to its C2 86.106.131[.]177. The additional samples targeted the same large Central Asian nation state as previously mentioned but more interestingly, one of the samples was a weaponized document also leveraging DDE and containing a non-Zebrocy payload. The payload turned out to be an open source penetration test toolkit called Koadic. It is a toolkit similar to Metasploit or PowerShell Empire and is freely available to anyone on Github.
Figure 6 Example of delivery document
The RTF document (8cf3bc2bf…) was very small in size at 264 bytes, which can be seen in its entirety here:
The contents above use the DDE functionality in Microsoft Word to run a PowerShell script to download the Koadic payload from a remote server, save it as an executable file on the system and then execute the payload.
Conclusion
The Sofacy group continues their targeted attack campaigns in 2018. As mentioned in this blog, Sofacy is carrying out parallel campaigns to attack similar targets around the world but with different toolsets. The Zebrocy tool associated with this current strain of attacks is constructed in several different forms based on the programming language the developer chose to create the tool. We have observed Delphi, AutoIt, and C++ variants of Zebrocy, all of which are related not only in their functionality, but also at times by chaining the variants together in a single attack. These attacks are still largely perpetrated via spear phishing campaigns, whether via simple executable attachments in hopes that a victim will launch the file to using a previously observed DDE exploitation technique.
Palo Alto Networks customers are protected from Zebrocy and Koadic attacks by:
All known Zebrocy samples have a malicious verdict in WildFire
AutoFocus customers can track this campaign with the following Tags:
On February 19, 2018, we saw a spear phishing email sent to a foreign affairs organization within a Central Asian country, which attempted to delivered an attached Zebrocy downloader (5b5e80f63…) written in the Delphi programming language. This downloader obtained a second downloader, which in this case was very similar in functionality but was written in C++ instead of Delphi.
This variation of the Zebrocy downloader begins by gathering the serial number for the storage volume with the label “C:\” and the computer name. It then creates an invisible window (0x0 pixel) in the bottom right corner of the screen, which will call the main function of the Trojan.
The main function of the Trojan interacts with its configured C2 server to obtain additional code to execute. The main function gets pertinent strings to communicate with its C2 by calling a sub-function with a specific number that the sub-function uses as a case within a switch statement to decrypt the desired string. For instance, here are the resulting decrypted strings from each of the case statements (dd7e69e1…):
The Trojan uses raw sockets to communicate with its C2 server and uses the decrypted string above to create HTTP requests. It starts by calling this specific sub-function with an argument of 1 to get the IP address for the C2 to connect. It then calls the subfunction with the argument of 2 to get the string that it will use as the HTTP POST request. The main function then calls the subfunction with the argument 3 to get the POST data parameter (“porg”) along with the volume serial number and computer name and will send this data to the C2 via the HTTP POST request. The resulting HTTP POST request looks like the following:
We have not seen a C2 server respond to our requests during our analysis, however, we do know how the Trojan will parse the C2’s response for specific data.
-1 – Deletes the buffer and exits the Trojan.
009 – Deletes the buffers and exits the Trojan.
If neither of the above values are found at the beginning of the HTTP response, the Trojan checks the C2 response for the ASCII representation of hexadecimal bytes. The Trojan will convert these hexadecimal bytes to their binary values and write them to a file and will run the file using the “open” function using the ShellExecuteW API function.
We have seen the following HTTP POST parameters within the Zebrocy C++ samples:
porg
structOne
oq
volume
DDE Details
The author of the DDE document used in the February 2018 attacks used some obfuscation techniques in an attempt to evade detection. First, the DDE instructions heavily rely on the QUOTE field, which converts decimal values to their ASCII equivalent character. Also, the author capitalized the “E” in the “dde” command to evade case sensitive signatures. Lastly, the author bolded the “dd” characters within the “dde” command, which breaks the string up within the XML of the DOCX file (word/document.xml) to make signature development difficult, as seen here:
In addition to the aforementioned DOCX file, we found another related DDE enabled document based on an infrastructure overlap with a Zebrocy C2 IP address. This related delivery document was an RTF file that downloaded and installed a payload used to load the open-source Koadic tool. We do not have telemetry on the target or attack vector, but we know the RTF file used DDE to download and execute an executable that loaded Koadic.
The payload (abbad7acd…) is an executable that appears to have been created by a VBScript to Executable tool and further obfuscated with a cryptor. Our analysis shows some possible ties to the Vbs to Exe tool by F2KO Software but we have yet to confirm a direct overlap. We believe the actor used a cryptor on the payload, as it obtains a filename and script from within its resources and decodes these resources by multiplying each byte by negative one. The payload then uses the MD5 hash (14331d289e737093994395d3fc412afc) of what appears to be a hardcoded SHA1 hash (B6A75B1EF701710D7AEADE0FE93DE8477F3BD506) as an RC4 key to decrypts the resulting decoded data. For instance, the following data exists within a resource:
fb 70 b0 c9 bd c5 8a d4 0c 54 fd 4c 6d bb f0 0f
By multiplying each byte with -1, we obtain the following data:
05 90 50 37 43 3b 76 2c f4 ac 03 b4 93 45 10 f1
After using RC4 and the key 14331d289e737093994395d3fc412afc, the following cleartext data appears:
\x00\x00\x00\x00FlashRun.vbs
We do not see the payload using this FlashRun.vbs filename, instead it uses a temporary file name to store an embedded VBScript file, such as %Temp%\4.tmp\5.vbs. The embedded VBScript is retrieved from a resource and decrypted using the same algorithm as discussed above, which results in the following cleartext:
The Koadic C2 server will respond to this request with Javascript code that acts as the Koadic staging payload, which allows the actor to run additional Koadic modules on the end system to carry out their post-exploitation activities. Unfortunately, we did not observe the Koadic modules used by Sofacy during out analysis.
For businesses that have a lot of resources tied up in logistics and inventory, enterprise resource planning (ERP) systems can be a lifesaver. However, you should never invest in an ERP system blindly. With so much valuable data filtering through such a system, you must pay attention to cybersecurity.
Understanding the Need for ERP Security
The goal of ERP software is to help organizations manage the day-to-day business activities they face – such as project management, manufacturing, and accounting – with minimal friction and seamless oversight. Modern ERP systems truly are remarkable in their functionality and utility.
One of the key principles of ERP is the central collection of data for broad distribution across the organization. Instead of having a bunch of individual databases storing fragmented data, everything is organized into a single data reservoir where the appropriate parties push and pull the information they need to perform their job functions properly.
In 99.99 percent of situations, ERP systems improve functionality for businesses and allow them to accomplish tasks more efficiently and effectively. But any time you have so much data funneling through a single system, there’s always the risk that it could become compromised – especially in today’s hostile cyber environment.
According to a 2017 report published by Crowd Research Partners, 89 percent of security experts anticipate more attacks against ERP systems in the near future, while 30 percent expect a significant increase in the number of attacks.
How to Enhance ERP Security
If leading security experts are worried about ERP security, you should be too. Without data integrity, ERP systems collapse. The question is, what can be done to improve security and mitigate threats?
Move to the Cloud…Now!
There’s a common belief that transitioning to a cloud ERP solution takes a lot of time and energy that businesses don’t have – but this is nothing more than a myth. You have to transition as soon as possible.
“Making critical decisions based on old data and legacy software is like driving a business forward while looking in the rear-view mirror,” ACCEO ERP explains in a recent blog post. “In truth, as your business grows, entering data and synchronizing your systems will consume even more of your time. Contrary to older systems, the modern ERP offers speed and adaptability, with extensive and scalable development applications that can be installed as your business evolves.”
Control Access to Your ERP System With each person you give access to your ERP system, you’re opening up another possible entry point for an attack. By controlling access, you reduce risk.
“One simple tactic to help control access to your ERP system is to make sure that all users have good password management habits,” Thriveon explains in a blog post. “That includes using two factor authentication when possible, [using] strong passwords that are changed regularly, and [avoiding] sharing user names and passwords amongst multiple people.”
Have a Response Plan in Place
One of the most troubling things about ERP security is that most businesses don’t have any sort of plan in place. In fact, the majority of companies don’t even know who’s in charge. According to research, 43 percent think the CIO is responsible, while 28 percent believe it’s the duty of the CISO.
If you stand any chance of protecting your data, you need a response plan in place. You can’t afford to be pointing fingers and figuring out duties on the fly.
Protect Your Data and Your Business It’s impossible to be serious about ERP in 2018 and beyond without prioritizing data integrity and cybersecurity. Cybercriminals see your company’s ERP system as the “Holy Grail” and will come after it with great intensity. Now’s the time to be proactive and defend your data.
