Monthly Archives: May 2016

European Data Protection Supervisor Publishes 2015 Annual Report

On May 24, 2016, the European Data Protection Supervisor (“EDPS”) presented its Annual Report for 2015. The annual report provides an overview of the EDPS’ primary activities in 2015 and sets forth key priorities and challenges for 2016.

During 2015, the EDPS focused on ensuring the adoption of a new and effective data protection framework, providing recommendations for the adoption of the General Data Protection Regulation (“GDPR”). The EDPS also advised European institutions on new proposed legislations, such as the EU Passenger Name Record Directive, and worked closely with the Article 29 Working Party to analyze the consequences of the Court of Justice of the European Union’s (the “CJEU”) ruling in the Schrems case. They also advised the European Commission on alternative solutions for international data transfers. In addition, the EDPS launched several new initiatives, including on data ethics, big data, mobile health and intrusive surveillance.

In line with the EDPS Strategy 2015-2019, the EDPS will largely focus on the implementation of the GDPR during the course of 2016. The provisions of the GDPR will be directly applicable in all EU Member States as of May 25, 2018. Among other tasks, the EDPS will focus on ensuring the accountability of data controllers, increasing cooperation with national data protection authorities, empowering their activities through the establishment of the European Data Protection Board and implementing sustainable rules on international data transfers, following the ruling of the CJEU in the Schrems decision.

Also, the EDPS will continue to provide advice to the European institutions on the coherent and consistent application of EU data protection principles when negotiating trade agreements or international agreements linked to law enforcement, such as the Transatlantic Trade and Investment Partnership, the Trade in Services Agreement or the Umbrella Agreement.

In addition, the EDPS announced the release of an Opinion on the EU-U.S. Privacy Shield on May 30, 2016.

Read the EDPS’s press release.

Enterprise Security Weekly #3 – Vulnerability Management

Pwnie Express secures a $12.9 million funding round, Palo Alto forms strategic partnership with HardwareSolutions, Sophos introduces a new tool to combat ransomeware, webroot introduces a new IoT Security Gateway and Paul and John discuss some of the latest topics around vulnerability management.

Full Show Notes:

European Parliament Calls on European Commission to Renegotiate Privacy Shield

On May 26, 2016, the European Parliament approved a resolution calling for the European Commission to reopen negotiations with U.S. authorities on the EU-U.S. Privacy Shield (“Privacy Shield”), and to implement the recommendations of the Article 29 Working Party (“Working Party”) on the draft Privacy Shield adequacy decision.

The Working Party had previously published its recommendations in an Opinion regarding the draft decision issued by the European Commission on adequacy of the protection provided by the Privacy Shield. In the Opinion, the Working Party highlighted a number of key issues concerning access to European personal data by law enforcement and government agencies, and also recommended a number of changes to ensure that European citizens’ data are adequately protected.

The European Parliament’s resolution, although not binding, calls on the European Commission to “fully implement” the recommendations expressed by the Working Party in its Opinion.

It remains to be seen whether further changes will be made to the draft Privacy Shield adequacy decision, given the European Commission’s stated intention to have it in operation by summer 2016.

Will Spokeo Undermine CAFA?

As we previously reported, the Supreme Court’s decision in Spokeo v. Robins has been nearly universally lauded by defense counsel as a new bulwark against class actions alleging technical violations of federal statutes. It may be that. But Spokeo also poses a significant threat to defendants by defeating their ability to remove exactly the types of cases that defendants most want in federal court. The decision circumscribes the federal jurisdiction, with all its advantages, that defendants have enjoyed under Class Action Fairness Act (“CAFA”) for the past decade.

Under Spokeo, a plaintiff needs more than a statutory right of action in order to sue; he or she also needs a concrete, particularized injury traditionally required by Article III. The plaintiff, Robins, accused Spokeo of violating the Fair Credit Reporting Act (“FCRA”) by reporting information about him that was not true: specifically, that he is married, has children, has a job, is relatively affluent and holds a graduate degree. All false, according to Robins.

The Supreme Court found that while Robins had sufficiently alleged a statutory violation, he had not alleged a concrete injury sufficient to create Article III standing. The Court held that not every violation of a statute gives rise to federal standing, even where Congress has created a right of action for statutory violations. For instance, while reporting an incorrect zip code might technically violate the FCRA, “[i]t is difficult to imagine how the dissemination of an incorrect zip code, without more, could work any concrete harm.”

Defendants can now move to dismiss cases alleging technical statutory violations but no actual injury. But already, courts applying Spokeo have revealed that the decision is anything but an unalloyed boon to defendants. In Khan v. Children’s National Health System, Case No. 8:15-cv-02125, Judge Chuang considered a motion to dismiss a putative class action seeking recovery under a variety of consumer protection statutes for a data breach of a health care provider. The defendant had removed the case under CAFA. Relying on Spokeo, the court agreed that the plaintiff had not suffered a concrete injury and lacked standing — but instead of dismissing the case, Judge Chuang remanded it to state court. There lies the hidden danger of Spokeo.

Read the full client alert.


I'll be moving to a new position over the next few months, from intrusion analyst to penetration tester. As I make the transition to Red Team, I'll be posting articles and some of what I'm learning (but NetSec is ALWAYS learning something new) as well as Blue Team/intrusion analyst content.

Irish DPA Expected to Question EU Standard Contractual Clauses before Irish Courts

On May 25, 2016, Max Schrems stated that the Irish Data Protection Commissioner (the “DPC”) is expected to bring legal proceedings before the Irish courts concerning international data transfers under EU Standard Contractual Clauses.

In an unofficial statement to the Irish press, a representative of the DPC confirmed the DPC’s intention to seek declaratory relief in the Irish High Court and to recommend that the case be referred to the Court of Justice of the European Union (“CJEU”) for a preliminary ruling.

Read our previous entry on the Schrems ruling of the CJEU.

Hunton & Williams will continue monitoring this matter on the blog.

The Day the Earth Stood Still for CryptoWall

It’s been the norm in the cybersecurity industry to be intrigued and at the same time be infuriated by the people behind any successful large-scale malware attack. Ransomware is one such example. It’s been slowly released in the wild since the early 2009, but CryptoWall redefined the meaning of ransomware and took it to the next level. Early ransomware used file sharing sites to upload infected files disguised as a normal file that could be downloaded by anyone. Once downloaded, it would run through the user’s machines and start encrypting the user’s data or locking their machines. So how did the CryptoWall evade our traditional defender – antivirus? We’ll break down just how CryptoWall did it:

ACT I: Setting the Stage

Communication is the most common tool in any business today. CryptoWall authors have been scraping the Internet for any published company email addresses (usually available via marketing sites) to use as the entry point of the attack. These sourced email addresses are then blasted with phishing emails. These phishing emails are crafted in a way that makes the receiver think it’s an important email and should be read and understood properly. They usually contain a link to a direct download or a file attachment of CryptoWall – unbeknownst to the user. The encryption starts when the user clicks.

Here is the sample of a ransomware-laced email disguised as a email: email example email example

ACT II: The Latest CryptoWall 4.0 Disassembled

CryptoWall  4.0

Md5: e73806e3f41f61e7c7a364625cd58f65

On the initial infection, the sample resolves the addresses of all the API functions that it needs to call later. This is done by means of a list of hashes, one for the name of every API call. This way the malware does not have to use an import table or store API names directly as strings.

Next, the malware gathers the following system information:

  • ComputerName
  • UserName
  • SystemDrive serial number
  • Number of CPUs (using PROCESSOR_Level)
  • Revision Number of CPU (using PROCESSOR_REVISION)
  • OS Major version
  • OS Minor version
  • IsWow64
  • Keyboard Layout

Among the loaded modules are DLLs related to Windows Crypto API (CRYPTSP), Windows 7 Enhanced Cryptographic Provider (RSAENH). This suggests that the malware is going to perform some cryptographic operations.

Figure 2


It will create the md5 hash of the victims PC using the above system information by using the following API sequence:

  • CryptAcquireContext
  • CryptCreateHash ; Algorithm ID = CALG_MD5 0x00008003, hash key: nonkeyed algorithm (0)
  • CryptHashData
  • CryptGetHashParam


Example 1

Example 2

Example 3

The malware will inject code in a newly spawned child process – Explorer.exe – using the following APIs:

  • ZwCreateSection
  • ZwMapViewOfSection
  • ZwAllocateVirtualMemory
  • ZwWriteVirtualMemory
  • ZwProtectVirtualMemory
  • ZwQueueApcThread
  • ZwResumeThread

It will create a copy of the original file in the %APPDATA% folder and create AutoStart Registry entry.

The injected code will be responsible for disabling system protection, as well as deleting all the system shadow copy and injecting code in a newly spawned process, svchost.exe.

Deleting shadow copies

Deleting shadow copies, allowing the malware to disable file recovery services.

 AV Limitations:

– Emulation TimeOut

Disable system restore

Disable system restore

Execution continues in the svchost.exe process.  This process formulates the commands needed to communicate with the C&C server. It will also gather the above system information and generate an md5 hash of the victims PC that will be used in communicating with the C&C server.

Some of the C&C servers:

C&C servers

C&C servers

The network communication is using HTTP, but with an encrypted payload. It will try to establish a connection in one of the following I2P proxy through I2P URLs. Once it succeeds, it will send a POST request with the encoded string request.

Figure 3

CryptoWall stores the following information inside a configuration file:

  • Received public key binary data
  • TXT
  • HTML
  • PNG

The last three files will be written in each folder of the victim’s system after the file-encryption process.

  • Normal file behavior
  • Payload after multiple layers of encryption

ACT III: “It’s like I left my keys inside my car”

If you’ve ever locked your keys inside your car, you know how irritating it feels. You know where they are, but you can’t do anything about it and you have to pay a locksmith to open it for you – or get real crafty with a wire coat hanger. Ransomware is a lot like that: Your most precious information and data has been held for ransom, and there is a chance that it could be released to the public – and you have no way to stop it.



Once CryptoWall has finished encrypting your files, it will launch the ransom notes that explain what happened and how to purchase the decrypter.

For an even deeper dive into CryptoWall, check out our analysis of CryptoWall 4 here.

ACT IV: Finding Solutions to Guard Against Ransomware

The bright spot in all this is that, if you can see the trend of the infection, there are lots of points where we can actually stop CryptoWall.

The first stop is via email. Advanced email defense solutions designed to catch malware that evades traditional defenses is a great tool to help stop attacks by detecting phishing links and exploits that deliver ransomware. That can stop CryptoWall from encrypting and taking the data from you.

The next defense is bolstering your network. Adding an advanced defense solution that identifies and correlates discovered threats with anomalous network activity is an invaluable tool to guard your data. ThreatTrack’s ThreatSecure Network, for instance, provides end-to-end network visibility and real-time detection to catch traffic hitting known malicious IPs associated with ransomware distribution and C&C.

The post The Day the Earth Stood Still for CryptoWall appeared first on ThreatTrack Security Labs Blog.

UK ICO Issues Priorities for GDPR Preparation

On May 24, 2016, the UK Information Commissioner’s Office (“ICO”) published priorities for preparing for the EU General Data Protection Regulation (“GDPR”).

The ICO’s priorities for issuing guidance to assist organizations with GDPR preparation are split into three phases.

Phase 1 – Familiarization and Key Building Blocks

This phase focuses on issuing guidance to help organizations understand the key differences between the EU Data Protection Directive and the GDPR. This builds on the Preparing for the GDPR – 12 Steps to Take Now document the ICO previously published. The ICO will produce its own guidance and provide input at the European level which will go towards the Article 29 Working Party guidance.

Phase 2 – Guidance Structure and Mapping, Process Review and Associated Tools

The ICO will develop a structure for its GDPR guidance and decide how to prioritize the work to refresh or create new guidance.

Phase 3 – Bulk Guidance Refresh/Production and Review

The ICO will draft, update and finalize its guidance, including linking to relevant European level guidance where appropriate.

Heavy Obfuscation != Malicious

Malicious actors use obfuscation to evade detection, but programmers use it also for various reasons, like restricting reuse or bypassing ad blockers. Obfuscation should increase your attention to an alert, but it's not always indicative of hostile activity.

Here's an example.

IDS triggered on a rule for a common exploit kit, specifically on an eval statement. The code was:
(function(){var z="";var b="2866756e6374696f6e28297b66756e6374696f6e20682865297b7472797b636f6f6b696541727261793d5b5d3b666f722876617220623d2f5e5c733f696e6361705f7365735f2f2c643d646f63756d656e742e636f6f6b69652e73706c697428225c78336222292c633d303b633c642e6c656e6774683b632b2b296b65793d645b635d2e73756273747228302c645b635d2e696e6465784f6628225c7833642229292c76616c75653d645b635d2e73756273747228645b635d2e696e6465784f6628225c78336422292b312c645b635d2e6c656e677468292c622e74657374286b657929262628636f6f6b696541727261795b636f6f6b696541727261792e6c656e6774685d3d76616c7565293b636f6f6b6965733d636f6f6b696541727261793b646967657374733d417272617928636f6f6b6965732e6c656e677468293b666f7228623d303b623c636f6f6b6965732e6c656e6774683b622b2b297b666f722876617220673d652b636f6f6b6965735b625d2c633d643d303b633c672e6c656e6774683b632b2b29642b3d672e63686172436f646541742863293b646967657374735b625d3d647d7265733d652b225c7832635c7836345c7836395c7836375c7836355

;for(var i=0;ieval(eval('String.fromCharCode('+z+')'));})();

Changing the eval to print, and running it through Rhino, we get this:

[jstebelton@bwyissrv05 ~]$ rhino 10
(function(){function h(e){try{cookieArray=[];for(var b=/^\s?incap_ses_/,d=document.cookie.split("\x3b"),c=0;cres;g=new Date;g.setTime(g.getTime()+2E4);document.cookie="\x5f\x5f\x5f\x75\x74\x6d\x76\x63\x3d"+e+("\x3b\x20\x65\x78\x70\x69\x72\x65\x73\x3d"+g.toGMTString())+"\x3b\x20\x70\x61\x74\x68\x3d\x2f"}function l(e){for(var b=[],d=0;d"\x3d"+k)}break;case "\x76\x61\x6c\x75\x65":try{b[b.length]=encodeURIComponent(c+"\x3d"+eval(c).toString())}catch(h){b[b.length]=encodeURIComponent(c+"\x3d"+h)}break;case "\x70\x6c\x75\x67\x69\x6e\x73":try{p=navigator.plugins;pres="";for(a in p)pres+=(p[a].description+"\x20").substring(0,20);b[b.length]=encodeURIComponent("\x70\x6c\x75\x67\x69\x6e\x73\x3d"+pres)}catch(l){b[b.length]=encodeURIComponent("\x70\x6c\x75\x67\x69\x6e\x73\x3d"+l)}break;case "\x70\x6c\x75\x67\x69\x6e":try{for(i in a=navigator.plugins,a)if(f=a[i].filename.split("\x2e"),2==f.length){b[b.length]=encodeURIComponent("\x70\x6c\x75\x67\x69\x6e\x3d"+f[1]);break}}catch(m){b[b.length]=
encodeURIComponent("\x70\x6c\x75\x67\x69\x6e\x3d"+m)}}}return b=b.join()}var m=[["\x6e\x61\x76\x69\x67\x61\x74\x6f\x72","\x65\x78\x69\x73\x74\x73\x5f\x62\x6f\x6f\x6c\x65\x61\x6e"],["\x6e\x61\x76\x69\x67\x61\x74\x6f\x72\x2e\x76\x65\x6e\x64\x6f\x72","\x76\x61\x6c\x75\x65"],["\x6f\x70\x65\x72\x61","\x65\x78\x69\x73\x74\x73\x5f\x62\x6f\x6f\x6c\x65\x61\x6e"],["\x41\x63\x74\x69\x76\x65\x58\x4f\x62\x6a\x65\x63\x74","\x65\x78\x69\x73\x74\x73\x5f\x62\x6f\x6f\x6c\x65\x61\x6e"],["\x6e\x61\x76\x69\x67\x61\x74\x6f\x72\x2e\x61\x70\x70\x4e\x61\x6d\x65","\x76\x61\x6c\x75\x65"],["\x70\x6c\x61\x74\x66\x6f\x72\x6d","\x70\x6c\x75\x67\x69\x6e"],["\x77\x65\x62\x6b\x69\x74\x55\x52\x4c","\x65\x78\x69\x73\x74\x73\x5f\x62\x6f\x6f\x6c\x65\x61\x6e"],["\x6e\x61\x76\x69\x67\x61\x74\x6f\x72\x2e\x70\x6c\x75\x67\x69\x6e\x73\x2e\x6c\x65\x6e\x67\x74\x68\x3d\x3d\x30","\x76\x61\x6c\x75\x65"],["\x5f\x70\x68\x61\x6e\x74\x6f\x6d","\x65\x78\x69\x73\x74\x73\x5f\x62\x6f\x6f\x6c\x65\x61\x6e"]];try{h(l(m)),document.createElement("\x69\x6d\x67").src="\x2f\x5f\x49\x6e\x63\x61\x70\x73\x75\x6c\x61\x5f\x52\x65\x73\x6f\x75\x72\x63\x65\x3f\x53\x57\x4b\x4d\x54\x46\x53\x52\x3d\x31\x26\x65\x3d"+Math.random()}catch(n){img=document.createElement("\x69\x6d\x67"),img.src="\x2f\x5f\x49\x6e\x63\x61\x70\x73\x75\x6c\x61\x5f\x52\x65\x73\x6f\x75\x72\x63\x65\x3f\x53\x57\x4b\x4d\x54\x46\x53\x52\x3d\x31\x26\x65\x3d"+

We have hex encoding as the output of the function, so we can use a hex decoder to get the final output:

encodeURIComponent("plugin="+m)}}}return b=b.join()}var m=[["navigator","exists_boolean"],["navigator.vendor","value"],["opera","exists_boolean"],["ActiveXObject","exists_boolean"],["navigator.appName","value"],["platform","plugin"],["webkitURL","exists_boolean"],["navigator.plugins.length==0","value"],["_phantom","exists_boolean"]];try{h(l(m)),document.createElement("img").src="/_Incapsula_Resource?SWKMTFSR=1&e="+Math.random()}catch(n){img=document.createElement("img"),img.src="/_Incapsula_Resource?SWKMTFSR=1&e="+

Incapsula is a DDoS protection security vendor.

Enterprise Security Weekly #1 – Threat Hunting

Paul and John Strand begin a new series here on Security Weekly. They delve into Threat Hunting, FireEye, Tripwire IP360, and much more. Check this prime OG Episode of Enterprise Security Weekly!

Security Weekly Web Site: Follow us on Twitter: @securityweekly

EU Member States to European Commission: Remove Barriers to Data Flows

On May 23, 2016, half of the EU Member States sent a letter to the European Commission and the Netherlands (which holds the rotating presidency), seeking the removal of barriers to the free flow of data both within and outside the EU to benefit the EU from new data-driven technologies, according to Reuters and

The countries behind the letter include Belgium, Britain, Bulgaria, Czech Republic, Denmark, Estonia, Finland, Ireland, Latvia, Luxembourg, Lithuania, Poland, Slovenia and Sweden. The letter urged Brussels to avoid regulations that are seen as a barrier to the development of data-driven technologies, and to avoid “one size fits all” rules for online platforms.

This request comes in anticipation of the European Commission’s presentation on May 25 of the results of an online inquiry into online platforms and potential future actions that may be needed. The inquiry is in connection with the EU’s Digital Single Market strategy, an EU initiative to enhance and make the EU’s digital economy competitive.

Leaping Forward – Telling the Story of How InfoSec Has Matured into Cyber Risks

Readers of this blog know that I've spent nearly the past decade curating some of the best quotes about information security and related topics. What started as a self-serving repository of good material for my own use eventually grew into this blog. I owe a big thank you to all of those who, over the course of the years, have shared this site with others around them.

However, in the past year, I have to admit that I've been much more active on a different blog, that of the IBM sponsored SecurityIntelligence blog. Which brings me to this post.

Just this week, the IBM site published my 30th article, "Five Signs the CISO Who Got You Here Isn’t the Best One to Get You There," whose topic relates nicely to the evolution of the field of information security -- let's admit, security was never really just an IT issue -- and the evolution of the role of CISO.

Just as businesses have had to evolve in order to thrive, or even just to survive, so must we evolve, as information security professionals, in the face of a changing reality. We now have the attention that we've been asking C-Suite executives and board directors for. We must now step up to fulfill this new role, to meet these new expectations. The stakes are high -- businesses everywhere are getting hammered by attackers, some after a quick buck, others after the company's crown jewels.

In pitching and developing these 30 articles, I've always sought to bring value to the reader, primarily aimed at CISOs or aspiring CISOs. I'm including below the full set of links to these 30 articles (in ascending chronological order). And since IBM's blog doesn't allow for comments, I'm inviting readers everywhere to leave comments on this post instead.

Again, thank you for your support, and for your readership.

As an Information Security Professional, Are You Having the Right Conversations?
Improving Your Security Awareness Campaigns: Examples From Behavioral Science
Cyber Risks: From the Trenches to the Boardroom
CISO Influence: The Role of the Power Distance Index and the Uncertainty Avoidance Dimensions
How Helping Educators Is Good for the Cybersecurity Industry
Addressing the Information Security Skills Gap in Partnership With Academia
Why Is Your Board of Directors Finally Asking About Cyber Risks?
What Cybersecurity Questions Are Boards Asking CISOs?
Five Must-Read Articles on the Cybersecurity Skills Gap
What Can CISOs Take From the New NYSE Cybersecurity Guide?
How Are US Armed Forces Closing the Cyber Skills Gap?
How Should CISOs Report Cyber Risks to Boards?
Beyond Tech Skills: Leadership Qualities for CISOs
Get the Most Out of Your Recent Security Hires With Soft Skills
Get the Most Out of Your Recent Security Hires: The Value of Professional Development
New Year’s Resolutions for the Effective CISO
Cyber Risks: Three Areas of Concern for 2016
Highlights From the World Economic Forum’s Global Risks Report 2016
2015: The Year Feds Warned About Cyber Risks
Is Your CISO Ready to Be a Risk Leader?
Is Your CISO Out Of Place?
FTC Studying Practices of Nine PCI Companies
C-Suite Dynamics Can Impact The Organization's Cybersecurity
It's Not Too Late to Correct Your Security Posture
Securing the C-Suite, Part 1: Lessons for Your CIO and CISO
Securing the C-Suite, Part 2: The Role of CFOs, CMOs and CHROs
Securing the C-Suite, Part 3: All Eyes on the CEO
Engaging Conversations Key to Improving Cyber Risk Decisions
How to Make the Most of Your Pen Test
Five Signs the CISO Who Got You Here Isn't The Best One To Get You There

CVE-2016-4117 (Flash up to and Exploit Kits

Discovered being exploited in the wild by FireEye [1] on May 8, 2016, patched 4 days later with Flash, CVE-2016-4117 is making its way to Exploit Kits.

Magnitude :
CVE confirmed by FireEye - Thanks !
On 2016-05-21 Magnitude is firing an exploit to Flash up to

Magnitude firing exploit to Flash - 2016-05-21
For now i did not get exploitation in the different pass i tried but in the Flash exploit we can see some quite explicit imports :

 import com.adobe.tvsdk.mediacore.timeline.operations.DeleteRangeTimelineOperation;

Magnitude Flash Exploit showing import of the DeleteRangeTimelineOperation

Spotted sample :  f5cea58952ff30e9bd2a935f5843d15952b4cf85cdd1ad5d01c8de2000c48b0a
Fiddler sent here.
Updates to come as it appears to be a work in progress.

Neutrino :
Spotted by Eset.

2016-05-23 Neutrino successfully exploit CVE-2016-4117 on Flash and drop here CryptXXX
Sample in that pass : 30984accbf40f0920675f6ba0b6daf2a3b6d32c751fd6d673bddead2413170e8
Fiddler sent here (Password is malware)
Out of topic payload: 110891e2b7b992e238d4afbaa31e165a6e9c25de2aed442574d3993734fb5220 CryptXXX

Angler EK:
CVE identification by Henri Nurmi from F-Secure. Thanks !
Angler EK successfully exploit Flash on 2016-05-23 dropping Dridex

Sample in that pass : 310528e97a26f3fee05baea69230f8b619481ac53c2325da90345ae7713dcee2
Fiddler sent here
Out of topic payload  : 99a6f5674b738591588416390f22dedd8dac9cf5aa14d0959208b0087b718902
Most likely Dridex 123 targeting Germany based on distribution path.

Sundown :  [3]

Sample in that pass : cf6be39135d8663be5241229e0f6651f9195a7434202067616ae00712a4e34e6 

Fiddler sent here  (password : malware)

Read More:
[1] CVE-2016-4117: Flash Zero-Day Exploited in the Wild - 2016-05-13 - Genwei Jiang - FireEye
[2] New Flash Vulnerability CVE-2016-4117 Shares Similarities With Older Pawn Storm Exploit - 2016-05-13 - Moony Li - TrendMicro
[3] Sundown EK – Stealing Its Way to the Top - 2016-09-02 - Spiderlabs

NTIA Releases Drone Privacy Best Practices

On May 19, 2016, the U.S. Department of Commerce’s National Telecommunications and Information Administration (“NTIA”) announced that its multistakeholder process to develop best practices to address privacy, transparency and accountability issues related to private and commercial use of unmanned aircraft systems (“UAS”) had concluded with the group reaching a consensus on a best practices document. As we previously reported, the NTIA announced in March 2015 the multistakeholder process in response to a Presidential Memorandum issued by the White House in February 2015, which directed NTIA to facilitate discussion between private sector entities to develop standards for commercial UAS use.

The best practices, which are voluntary, encourage UAS operators to take certain measures including:

  • make a reasonable effort to provide notice to individuals of the use of UAS, including the general timeframe and area in which UAS may intentionally be collecting personal information;
  • show care in collecting and storing information that identifies a particular person;
  • avoid the collection of covered data where the operator knows the data subject has a reasonable expectation of privacy;
  • limit the use and sharing of personal information (e.g., for purposes such as credit eligibility, healthcare or employment eligibility) without consent;
  • avoid sharing personal information for marketing purposes;
  • secure any personal information collected; and
  • monitor and comply with evolving laws relating to UAS.

The best practices also acknowledge that UAS have the potential to provide significant benefits to both consumers and businesses. The stakeholders who participated in the group included representatives from industry, news organizations, consumer and privacy advocacy groups, academics and trade associations.

Pharmaceutical Company to Plead Guilty and Settle Drug Marketing Charges

Recently, Aegerion Pharmaceuticals announced that it will enter into several settlements and plead guilty to two misdemeanors in connection with alleged violations of HIPAA, drug marketing regulations and securities laws. The criminal charges stem from the company’s marketing of a cholesterol drug called Juxtapid. Aegerion allegedly failed to comply with risk evaluation and management strategies and marketed Juxtapid (which is labeled with a warning about liver toxicity) without proper directions for use. 

Aegerion will also pay $40 million to settle claims by the Department of Justice and Securities and Exchange Commission, and enter into a deferred prosecution agreement related to alleged violations of HIPAA. The specific violations of HIPAA have not been made public, but an Aegerion spokesperson stated that it “does not relate to a breach of our privacy or security with respect to patient health information.”

Understanding the Latest Version of Locky Ransomware

It is one of the most prevalent spam malware in the wild today: Locky ransomware. The Locky malware authors started their campaign last year but didn’t become very active until January 2016 – and they haven’t slowed down since.

Locky e-mails usually come in with an attached zip archive and once extracted may contain a document or JavaScript. The Locky ransomware we discovered included a JavaScript that will potentially download and run an executable. The executable is the focal point of this analysis and the latest version of the Locky ransomware.

Locky spam email

The spam email sent by the malware authors.

Basic Infection Flow and File Hashes:

  • 1582A0B6A04854C39F8392B061C52A7A – The .zip attachment
  • 59D2E5827F0EFFE7569B2DAE633AFD1F – The JavaScript extracted from the .zip
  • F79C950FA3EFC3BB29A4F15AE05448F2The Locky executable downloaded by the Javascript
Basic infection and file hashes

Basic infection and file hashes

Indications of Compromise:

It is fairly easy to find out if a machine is infected by Locky. The image below shows the desktop background of a compromised Windows XP machine.

Desktop of a Locky-infected computer

Desktop of a Locky-infected computer


The files that have been encrypted by the ransomware are named with the extension “.locky” and their names start with the personal ID for the infected user – in this case “8B74B4AA40D51F4A,” an MD5 hash. There is also a text file named “_HELP_instructions.txt” that contains the same message displayed in the desktop background.

Locky files

Locky files

Locky creates an encrypted user-specific registry key at HKCU\Software. The details about the registry values will be discussed later on in this post. The key created was “8W21gQe9WZ3tc.


Encrypted user-specific key

Encrypted user-specific key


Payment Instructions

The user is instructed to install TOR browser to access the payment webpage – shown below. The victim must have a bitcoin wallet to send 1.5 bitcoin to the specified bitcoin address.

Payment page for Locky ransomware

Payment page for Locky ransomware 

A Look at the JavaScript 59D2E5827F0EFFE7569B2DAE633AFD1F

The JavaScript is straightforward. The following lines are visible once opened in a text editor:

JavaScript 1

JavaScript 1

The Javascript downloads via GET command from http://goldish[dot]dk/o2pds and executes it in %Temp%. The executable will not run properly if not located in a %Temp% folder.

In-Depth Analysis of the Executable F79C950FA3EFC3BB29A4F15AE05448F2

Just like other malware families such as Upatre, Dridex and Crypto, the real Locky executable is wrapped by some encryption routines to avoid signature-based detections. The last step of the unwrapping process is to decompress the executable by using RTLDecompressBuffer API. We’ve seen this same method before from Upatre and Necurs rootkit downloaders.

RTLDecompressBuffer API

RTLDecompressBuffer API


The MD5 of the unwrapped Locky executable analyzed is F35D01F835FC637E0D9E66CD7E571C06.

The first step of the executable is to decrypt the following CnC Server IP addresses.

CnC Server IP addresses

CnC Server IP addresses


The executable retrieves the Windows directory by the API GetWindowsDirectoryA. Then it will be used as a parameter for the API GetVolumeNameForVolumeMountPointA. This Function retrieves the volume GUID path associated with the machine’s Windows folder.

Windows directory

Windows directory 

This GUID will serve as the initial basis of the Locky ransomware for the unique ID of the user.

First, GUID be used by the executable for the API CryptHashData.

API CryptHashData

API CryptHashData

For The executable to obtain the unique ID – “8B74B4AA40D51F4A” – for the machine, it will use the API CryptGetHashParam to get the unique ID associated with the GUID. It is visible at the first 8 Bytes at the hex dump.

API CryptGetHashParam

API CryptGetHashParam


This unique ID is correlated with the new registry key of this version of Locky. The ID will be converted by a checksum to string routine implemented by the executable to obtain a string that will be used as its registry key.

For this new version, these particular set of instructions explain why the new registry key is “8W21gQe9WZ3tc” instead of “Locky,” used before in the older versions.

New registry key

New registry key 

CnC Communication

The Locky executable sends a “POST” request to “http://<IP/Domain>/submit.php” by the following commands and parameters:

Commands Parameters (Remove the <>)
&act=getkey&affid= id=<>,&lang=<>,&corp=<>,&serv=<>,&os=<>,&sp=<>,&x64=<>
&act=gettext&lang= id=<>
&act=stats&path= id=<>,&encrypted=<>,&failed=<>,&length=<>

An example of parameters for Command &act=getkey&affid=: (Not Encrypted Form)


These commands will be sent to the CnC server in encrypted form via the API HttpSendRequestA. The executable also receives an encrypted reply via the API InternetReadFile.

CnC server commands

CnC server commands


After sending the getkey command to the CnC, the executable will decrypt the encrypted message and getkey command it received the public RSA key. The image below shows a part of the decryption routine. The public RSA key is at the ASCII dump.

Decryption routine

Decryption routine 

Saving The Public Key in the User’s Machine

The executable will encrypt the public RSA key and its checksum will be converted to a string equivalent – just like how the registry key was created. It will be stored as a binary value in its registry key at HKCU\Software. The value name is “270CwQa9XuPIc7.”

Encrypting public RSA key

Encrypting public RSA key

A Message to the User

Then it will send the CnC command “&act=gettext&lang=.” This will retrieve the Locky ransomware message equivalent to the desktop background image.

Locky ransomware message

Locky ransomware message


Once again, just like the public RSA key, this message will be encrypted, stored to a binary value in the HKCU\software registry key created by the executable. The message is equivalent to the registry value “7CaY397p5R.”

Gathering the Drives, Network Resources and Files to Encrypt

Network Shares and Resources:

The executable used a routine consisting of APIs WNetOpenEnumW, WNetEnumResourcesW, WNetAddConnection2 and WNetCloseEnum to parse through these three types of resources:


The usage of NetResource Parsing Routine for different types of resources:

NetResource Parsing Routine

NetResource Parsing Routine

Upon enabling a shared folder for the machine under analysis, the image shows that the executable will connect to the shared folder so it can encrypt the files in the shared folder later on.

Encrypting files in the shared folder

Encrypting files in the shared folder

The executable then uses the APIs GetLogicalDrives and GetDriveTypeW to gather the possible drives to encrypt. In this case, it obtained the “C:\” drive.

Encrypting the C:/ drive

Encrypting the C:/ drive 

The last step is to spawn the thread that will encrypt the files per folder in the drives and resources that were gathered.

Final step in the Locky ransomware process

Final step in the Locky ransomware process


Deleting the Shadow Copies to Prevent Data Restoration

The next step for the executable is to delete the shadow copies by running this command:

“vssadmin.exe Delete Shadows /All /Quiet”

Other Ransomwares, including Crypto, has used this same command.

The File Encryption Process – the Thread Spawned

The first step in this phase is to parse the directories and files of the machine. The executable allocates a memory space as a structured reference for the files to be encrypted.

White List Check

While parsing the directories of the machine, it will check the file name of each file against the following set of white list strings. File names that have one of the “ff.” strings will not be encrypted.

  • @_HELP_instructions.bmp, _HELP_instructions.txt, _Locky_recover_instructions.bmp, _Locky_recover_instructions.txt, tmp, winnt, Application Data, AppData, Program Files (x86), Program Files, temp, thumbs.db, $Recycle.Bin, System Volume Information, Boot, Windows

Black List Check

The Locky executable also checks the extension of the file to be encrypted. If the file has one of the “ff.” extensions, it will be encrypted.

  • .001, .002, .003, .004, .005, .006, .007, .008, .009, .010, .011, .123, .3dm, .3ds, .3g2, .3gp, .602, .7z, .ARC, .CSV, .DOC, .DOT, .MYD, .MYI, .NEF, .PAQ, .PPT, .RTF, .SQLITE3, .SQLITEDB, .XLS, .aes, .asc, .asf, .asm, .asp, .avi, .bak, .bat, .bmp, .brd, .cgm, .class, .cmd, .cpp, .crt, .cs, .csr, .db, .dbf, .dch, .dif, .dip, .djv, .djvu, .docb, .docm, .docx, .dotm, .dotx, .fla, .flv, .frm, .gif, .gpg, .gz, .hwp, .ibd, .jar, .java, .jpeg, .jpg, .js, .key, .lay, .lay6, .ldf, .m3u, .m4u, .max, .mdb, .mdf, .mid, .mkv, .mml, .mov, .mp3, .mp4, .mpeg, .mpg, .ms11, .ms11 (Security copy), .n64, .odb, .odg, .odp, .ods, .odt, .onetoc2, .otg, .otp, .ots, .ott, .p12, .pas, .pdf, .pem, .php, .pl, .png, .pot, .potm, .potx, .ppam, .pps, .ppsm, .ppsx, .pptm, .pptx, .psd, .pst, .qcow2, .rar, .raw, .rb, .sch, .sh, .sldm, .sldx, .slk, .sql, .stc, .std, .sti, .stw, .svg, .swf, .sxc, .sxd, .sxi, .sxm, .sxw, .tar, .tar.bz2, .tbk, .tgz, .tif, .tiff, .txt, .uop, .uot, .vb, .vbs, .vdi, .vmdk, .vmx, .vob, .wav, .wb2, .wk1, .wks, .wma, .wmv, .xlc, .xlm, .xlsb, .xlsm, .xlsx, .xlt, .xltm, .xltx, .xlw, .xml, .zip, wallet.dat (filename specific)

API and Function-Level Overview of the File Encryption Process:

The Locky ransomware’s claim that it uses AES and RSA is basically true. It used Crypto APIs during the encryption process, including CryptGenRandom and CryptEncrypt. It also had two functions in this process that used the instructions “aesenc” and “aeskeygenassisst.

API overview

API overview

Dissecting the Last 0x344 Bytes of an Encrypted Locky File

In the image below, the last 0x344 bytes are being written at the end of file. The first four bytes are hard coded by the executable. We believe this is some sort of an identifier for the Locky ransomware authors for the version that encrypted the user’s files.

Hard-coded 0x8956FE93

Hard-coded 0x8956FE93


Writing to the file

Writing to the file 

The Next 0x10 bytes are obviously the unique ID of the user. The next 0x100 bytes are the output of the CryptEncrypt API. The last 0x230 bytes are from the AESENC function mentioned from the encryption flow before.

Finalizing the Infection

The executable will generate the “_HELP_instructions.txt” file for every folder path where it encrypted a file. It will also generate an equivalent Bitmap image for the instructions and store it so it becomes the user’s desktop background.

The executable will then send another actioncalled “stats” – to the CnC server:                  id=8B74B4AA40D51F4A&act=stats&path=c%3A&encrypted=1&failed=0&length=5912

Path = the infected Drive “C:\”

Encrypted = True

Failed = false

Length = number of files

The last step is to create the last encrypted registry value. It is equivalent to the previous version “Completed = Yes.” This completes the details about the three encrypted registry values.

Last step of the encryption process

Last step of the encryption process


The analyzed executable also had the domain generation algorithm, which has been known to exist for the Locky ransomware since its existence last year. It will be used by the executable if it cannot receive a response from the initially decrypted IP addresses.

How to Mitigate

Using ThreatSecure products, it is possible to block the ransomware executable from downloading. The image below shows ThreatSecure Network detecting the malicious download via the GET procedure.


ThreatSecure in action

ThreatSecure in action 

Prior to opening an e-mail attachment, the customer can use ThreatTrack’s dynamic malware analysis sandbox product – ThreatAnalyzer – to determine if the file is malicious. ThreatAnalyzer logs its output in a file named “analysis.xml.” By looking at this output, you can tell it has seen the executable’s ransomware behaviors (IoCs).

Stored and Encrypted Files to .locky:

The sandbox detects that the files were encrypted, and the “Help Instructions” text file was also generated.

Help instructions text file

Help instructions text file 

Network capture of Communication to CnC via post command to the CnC Server IP:

An outgoing connection is being initiated by Locky.

Network capture of communication to CnC

Network capture of communication to CnC


Process capture of Vssadmin.exe execution, deleting all backups:

Process capture of Vssadmin.exe execution

Process capture of Vssadmin.exe execution

Setting an encrypted registry value “4Y0743Ngl” at HKCU\software:

Prior to file encryption, Locky enumerates the network resources of the machine, which can also be encrypted. ThreatAnalyzer was also able to see this behavior:

Locky enumerating network resources

Locky enumerating network resources


As shown here, advanced threat defense products like those used here help avoid ransomware infection. The advanced solutions catch the emerging threat before it can do any damage.

What’s more, the sandbox capabilities of ThreatAnalyzer also showed that it can log indications of compromise and potential malicious activities once a user accidentally opens the attachment – one more way users are guarded against increasingly popular ransomware attacks.

The post Understanding the Latest Version of Locky Ransomware appeared first on ThreatTrack Security Labs Blog.

EU Council Adopts the Network and Information Security Directive

On May 17, 2016, the European Council adopted its position at first reading of the Network and Information Security Directive (the “NIS Directive”). The NIS Directive was proposed by the European Commission on February 7, 2013, as part of its cybersecurity strategy for the European Union, and is designed to increase cooperation between EU Member States on cybersecurity issues.

The NIS Directive will impose security obligations on “operators of essential services” in critical sectors and “digital service providers.” These operators will be required to take measures to manage cyber risks and report major security incidents.

Operators of essential services will include entities within the energy, transport, banking, financial market infrastructures, health, drinking water supply and distribution, and digital infrastructure sectors. The security obligations imposed on these operators will be stronger than those for digital service providers (i.e., providers offering online marketplaces, online search engines and cloud computing services in the EU).

Further, each EU Member State will be required to (1) designate one or more national authorities on the security of network and information systems and (2) establish a strategy for dealing with cyber threats.

Next steps

The NIS Directive must be approved by the European Parliament in plenary session. The NIS Directive is expected to enter into force in August 2016. Thereafter, EU Member States will have 21 months to adopt the necessary national provisions. Following this period, EU Member States will have six months to identify operators of essential services. In order to do so, EU Member States should assess whether services are essential for the maintenance of critical social and economic activities.

Supreme Court Finds Consumers Must Prove Injury in Class Actions

On May 16, 2016, the United States Supreme Court issued a decision in Spokeo Inc. v. Thomas Robins, holding 6-2 that the Ninth Circuit’s ruling applied an incomplete analysis when it failed to consider both aspects of the injury-in-fact requirement under Article III. Writing for the Court, Justice Samuel Alito found that a consumer could not sue Spokeo, Inc., an alleged consumer reporting agency that operates a “people search engine,” for a mere statutory violation without alleging actual injury.

In this case, after discovering that his Spokeo-generated profile contained inaccurate information, the respondent filed a federal class-action complaint against Spokeo, alleging that the company willfully failed to comply with the requirements of the Fair Credit Reporting Act of 1970 (“FCRA”). The FCRA regulates the creation and use of consumer reports by consumer reporting agencies for certain specified purposes. The District Court dismissed the respondents’ complaint, holding that he had not properly pleaded injury-in-fact as required by Article III. The Ninth Circuit reversed the District Court’s decision, finding that because Spokeo allegedly violated the respondent’s statutory rights and that the respondents’ “personal interests in the handling of his credit information are individualized,” the respondent had adequately alleged an injury in fact.

According to the Supreme Court opinion, the injury-in-fact requirement requires a plaintiff to show that he or she suffered “an invasion of a legally protected interest” that is “concrete and particularized.” The Court found that the Ninth Circuit’s injury-in-fact analysis failed to address the “concreteness” requirement, which is distinct from an injury being “particularized” (i.e., affects a plaintiff in a personal and individual way).

The Court also reasoned that the Ninth Circuit failed to address whether the alleged procedural violations involved a degree of risk sufficient to meet the “concreteness” requirement. While a “concrete” injury need not be tangible, the Court indicated that a statutory violation alone does not automatically satisfy the injury-in-fact requirement. According to the Court, “[t]his does not mean, however, that the risk of real harm cannot satisfy that requirement.”

Privacy Provisions Not Included in Small Drone Rule

As we previously reported, the Federal Aviation Administration’s (“FAA’s”) proposed “small drone rule” nears completion of the interagency review process, but one potential stumbling block has been removed, at least for now. On Tuesday, May 10, 2016, the U.S. Court of Appeals for the D.C. Circuit denied a request by the Electronic Privacy Information Center (“EPIC”) to review the FAA’s decision not to include privacy provisions in its Notice of Proposed Rulemaking for the Operation and Certification of Small Unmanned Aircraft Systems (“NPRM”), as well as its denial of an EPIC petition to the same effect. The court decided that there were no reasonable grounds for EPIC’s delay in filing for review of the FAA’s denial of EPIC’s 2012 petition that sought to cause the FAA to promulgate privacy regulations pertaining to drones. The court further concluded that EPIC’s challenge to the NPRM itself is premature, as the rule is not yet final.

In the NRPM, the FAA signaled that “[privacy] issues are beyond the scope of this rulemaking,” but that it would participate in the multistakeholder engagement process related to privacy and the operation of unmanned aircraft systems being led by the National Telecommunications and Information Administration. Consequently, and in light of the FAA’s opposition to EPIC’s petition and legal action, the final version of the NRPM is not expected to incorporate privacy provisions. EPIC has already indicated its intention to resume its challenge to the NRPM, if that indeed is the case.

Read My Lips: Let’s Kill 0Day

0day is cool.  Killing 0day, sight unseen, at scale — that’s cooler.

If you agree with me, you might be my kind of defender, and the upcoming O’Reilly Security Conference(s) might be your kind of cons.

Don’t get me wrong.  Offense is critical.  Defense without Offense is after all just Compliance.  But Defense could use a home.  The Blue Team does not always have to be the away team.

So for quite some time, I’ve been asking Tim O’Reilly to throw a highly technical defensive security event.  Well, be careful what you wish for.  I actually keynoted his Velocity event with Zane Lackey a while back, and was struck by the openness of the environment, and the technical competence of the attendees.  This is a thing that would be good for Defense, and so I’ve taken the rare step of actually joining the Program Committee for this one,  CFP’s for NYC & Amsterdam are still open (but not for much longer!).  How would you know if this is your sort of party?

NIST’s SAMATE project has been assembling this enormous collection of minimized vulnerability cases.  They’re just trying to feed static analyzers, but if you’re filled with ideas of what else is possible with these terabytes of goodies – this is your con.

Researchers at Stanford instrumented the IDE’s of students, and watched how early failures predicted later ones.  Can we predict the future authorship of security vulnerabilities?  In what ways do languages themselves predict failures, independent of authors?  If this interests you, this is your con.

If you’re in operations, don’t feel left out.  You’re actually under attack, and you’re actively doing things to keep the lights on.  We want to know how you’re fighting off the hordes.

We live in a golden age of compilers actually trying to help us (this was not always the case).  Technologies like Address Sanitizer, Undefined Behavior Sanitizer, Stack Protection / /GS along with the Microsoft universe of Control Flow Guard and the post-Boehm-ish MemGC suggest a future of much faster bug discovery and much better runtime protections.  Think you’ve got better?  Think you can measure better?  Cool, show us.

Or show us we’re wrong.  Offensive researchers, there are better places for you to demonstrate the TLS attack of the hour, but if you haven’t noticed, a lot of defensive techniques have gotten a “free pass”, E for effort, that sort of thing.  There’s a reason we call ‘em sandboxes; they’re things kids step into and out of pretty freely.  Mitigations not living up to their hype?  Security technologies actually hosting insecurity?  Talk to a bunch of people who’d care.

We’re not going to fix the world just by blowing things up.  Come, show us your most devious hacks, let’s redefine how we’re going to defend and fix the Internet.

Advocate General Advises EU’s Highest Court that IP Addresses are Personal Data

On May 12, 2016, the Advocate General (“AG”) of the Court of Justice of the European Union (“CJEU”) issued an opinion stating that Internet Protocol (“IP”) addresses are personal data and data protection law should apply to IP addresses. Specifically, the AG urged the CJEU to rule that a dynamic IP address is personal data to the extent that an Internet access provider has additional data that in combination with the IP address would allow for the re-identification of the user.

The opinion was issued in Patrick Breyer v. Federal Republic of Germany, a case which was referred to the CJEU by Germany’s Supreme Court in 2014. The AG’s opinion is a procedural step before the court issues its final decision, which is expected soon. The opinion is not binding on the CJEU, but is highly influential.

FTC Orders Mobile Device Manufacturers to Provide Information about Security Updates for Study

On May 9, 2016, the Federal Trade Commission announced it had issued Orders to File a Special Report (“Orders”) to eight mobile device manufacturers requiring them to, for purposes of the FTC’s ongoing study of the mobile ecosystem, provide the FTC with “information about how [the companies] issue security updates to address vulnerabilities in smartphones, tablets, and other mobile devices.” The FTC’s authority to issue such Orders comes from Section 6(b) of the FTC Act.

The following companies are receiving the orders:

  • Apple, Inc.;
  • Blackberry Corp.;
  • Google, Inc.;
  • HTC America, Inc.;
  • LG Electronics USA, Inc.;
  • Microsoft Corp.;
  • Motorola Mobility, LLC; and
  • Samsung Electronics America, Inc.

Among other details, the Orders require the relevant companies to provide information regarding:

  • factors the companies consider in deciding whether to patch a vulnerability on a particular mobile device;
  • any written policies, contracts, testing or certification documentation the companies maintain regarding mobile device security;
  • disclosures the companies have made to consumers regarding mobile device security updates;
  • (1) detailed data on the specific mobile devices the companies have offered for sale to consumers since August 2013; (2) the vulnerabilities that have affected those devices; and (3) whether and when the companies patched such vulnerabilities.

The companies must file their responses within 45 days from the date of service of the Orders.

Excellent Manual Javascript Deobfuscation Walk through

Security Researcher Aditya K Sood posted an excellent walk through of manual Javascript Obfuscation on his log, Malware At Stake (

Saturday, April 7, 2012

JavaScript Obfuscation - Manual Armor (1)

Recently, we came across a similar set of obfuscated JavaScripts that are being used continuously in conjunction with automate Browser Exploits Packs (BEPs) such as BlackHole etc. There are several variations of this type of obfuscated JavaScript. Our team prefer to do obfuscation manually because sometimes automated tools are not good enough to perform the deobfuscation. In this post, we are going to discuss about the methodology that  we prefer to follow at SecNiche labs. Let's take a look at the obfuscated JavaScript shown below

The methodology  goes like this:

Step1: Beautify Your JavaScript: 
The very first (basic) step is to beautify the obfuscated JavaScript. For analysis perspective, beautifying the
code such as appropriate indentation makes it very easy to decipher the initial structures in the JavaScript. 
Always do this step before proceeding further.

Step 2: Divide and Rule
This strategy works perfectly fine while analyzing obfuscated JavaScripts. The motive behind this step is to a
analyze the code in small snippet for better grasp.

Applying step 1 and step 2 to the given JavaScript code,  we get part 1 of the code as follows

and part 2 of the code as follows

In part 2, to interpret the given code as single string , one has to use characters ["" +]. Even for doing 
automated analysis, these parameters are required to be tuned so that appropriate interpretation of the string 
can be done. Check the string passed to variable "n".

Step 3: Extract the Logic 
On the modular code (divided code snippets), try to apply the logic step by step (top to bottom). When we
compute the value of "h" we get : h=-2*Math.log(Math.E);   //     h = -2      //

The next logic is to compute the value of "n" first. We have the n="[string]".split("a"), which means we have 
to split the string. By default, split function actually dissects the string n by a delimiter ",". We tweak the code
a bit as presented below:

On executing this code in JavaScript interpreter we get the output as follows,

At this point, we successfully unwraps some part of code by having the value of h and n. Now, we have to 
dissect the loop present in the part 2 as follows

for(i=0;-n.length<-i br="" i="">        {


To compute the code finally, we need to unwrap the logic used in the loop. Step 4 involves the automation of 
the code.

Step4: Automating the Process - Python
In step 4, we need to automate the process to get the next value of the string. On understanding the logic, we
write a following python script to compute the loop

The code actually multiply the every single value by 2 and build up the new string. So, we are almost at the 
end. So we need to build up the final code as presented below

So here we have the final script as follows
A good methodology always  helps to attain the target.

CIPL Releases Outcomes Report of First GDPR Implementation Project Workshop in Amsterdam

On March 16, 2016, the Centre for Information Policy Leadership (“CIPL”) at Hunton & Williams LLP co-hosted a one-day workshop in Amsterdam, Netherlands, together with the Dutch Ministry of Security and Justice, to kick off CIPL’s new long-term project on the implementation of the EU General Data Protection Regulation (“GDPR”). The project aims to address the need for a constructive and expert dialogue between industry, regulators and key policymakers with the following specific objectives:

  • facilitating consistency in the interpretation of the GDPR across the EU;
  • informing and advancing constructive and forward-thinking interpretations of key GDPR requirements;
  • facilitating consistency in the further implementation of the GDPR by EU Member States, the European Commission and the European Data Protection Board;
  • examining best practices and challenges in the implementation of the key GDPR requirements;
  • sharing industry experiences and views to benchmark, coordinate and streamline the implementation of new compliance measures; and
  • examining how the new GDPR requirements should be interpreted and implemented to advance the European Digital Single Market strategy and data-driven innovation, while protecting the privacy of individuals and respecting the fundamental right to data protection.

Under the title of “Towards a Successful and Consistent Implementation of the GDPR,” the workshop focused on GDPR issues that require further interpretation and guidance. More than 100 participants from numerous EU data protection authorities (“DPAs”), the European Data Protection Supervisor, the European Commission, several government ministries, EU and U.S. businesses, as well as from academia and other organizations, participated in the workshop.

CIPL also has released its workshop report Implementing and Interpreting the GDPR: Challenges and Opportunities (the “Report”). The key themes and takeaways from the Amsterdam workshop that are discussed in the Report include:

  • In order to ensure the consistent implementation and interpretation of the GDPR, ongoing, high-level and open engagement between industry, EU DPAs, the European institutions (e.g., the Commission), the ministries of the Member States and other stakeholders (e.g., privacy professionals) is essential.
  • The Article 29 Working Party and the Commission will hold several meetings over the next two years which will provide suitable forums for stakeholder involvement.
  • The successful GDPR implementation and interpretation also will depend on various considerations, such as taking into account the aims of the European strategy on the Digital Single Market, devising “future-proof” and technologically neutral interpretation and implementation guidance, ensuring a harmonized European approach (as far as possible) and considering the areas of overlap between the GDPR and other European laws (e.g., competition law and the E-Privacy Directive).
  • “Accountability” is a cornerstone of the GDPR and must be understood by all the relevant stakeholders. Regulators should incentivize companies to adopt and develop accountability tools.
  • “Smart” data protection regulation may enable EU DPAs to discharge their GDPR roles more effectively and tackle the significant changes in their roles and their powers at national and European levels.
  • The data protection officer is a linchpin of organizational accountability. It is essential to clarify the functional and organizational aspects of the data protection officer role in order to ensure the effectiveness of the role.
  • The understanding of “risk” and “high risk” must be harmonized, and effective risk assessment methodologies that consider both the risks and the benefits of processing must be developed and agreed, without determining a definitive list of “high risk” processing.
  • Codes of conduct, certifications, seals and binding corporate rules can be effective compliance and accountability tools. It would be preferable if they worked at the “programmatic” rather than just the product level only. Regulators should also incentivize the adoption and development of such measures.
  • Implementing and interpreting the rights to data portability, erasure and object raise various problems which need to be resolved. For example, there are potential interactions between the data portability right and other legal areas, such as intellectual property, which need to be addressed.
  • The GDPR transparency provisions should be implemented and interpreted in order to minimize any tension between the GDPR provisions on transparency and detailed notice. Relatedly, the relevant stakeholders should carefully consider whether icons are suitable transparency tools.
  • The GDPR will raise specific challenges for start-ups and small and medium-sized enterprises that need to be addressed, for example, by involving start-ups and small and medium-sized enterprises in the stakeholder engagement process. Also, stakeholders might explore how larger and more experienced companies can help shape how start-ups and small and medium-sized enterprises approach data protection compliance.

The Report also provides information about next steps in CIPL’s ongoing GDPR implementation initiative, including working groups to develop written input, workshops, webinars and engagements with relevant regulators and government officials.

Security Weekly #463 – Interview with Ferruh Mavituna, CEO of Netsparker

Do you want to know the inside scoop of Netsparker? Listen to us interview Ferruh Mavituna, who has been in the security industry for well over a decade and his ambition to ease the process of automatically detecting web application vulnerabilities led him to build Netsparker, and pursued it to the point of commercial reality. Ferruh is also Netsparker’s Product Architect.

Looking Beyond the Small Drone Rule? The FAA Announces a Drone Advisory Committee

On May 3, 2016, the Federal Aviation Administration (“FAA”) announced the establishment of a Drone Advisory Committee (“DAC”) intended to increase transparency and collaboration between the FAA and key stakeholders in the ongoing effort to develop and implement an overall integration strategy for Unmanned Aircraft Systems (“UAS”).

The DAC comes on the heels of the FAA’s formation of the UAS registration task force last year and the MicroUAS aviation rulemaking committee this spring. With the success of those smaller groups, and with the anticipated role out of the “small drone rule” in June, this more permanent committee evidences the FAA’s commitment to the broader integration of commercial drones and a recognition that a partnership with industry is critical to addressing emerging issues in this rapidly evolving industry.

The FAA will be working with the Radio Technical Commission for Aeronautics (“RTCA”) on the selection process of the DAC and membership is expected to include C-suite executives from key industry stakeholders. FAA Administrator Michael Huerta will be the Designated Federal Official and Intel’s CEO, Brian Krzanich, has been tapped to chair the DAC. Huerta said, “Input from stakeholders is critical to our ability to achieve that perfect balance between integration and safety … We know that our policies and overall regulation of this segment of aviation will be more successful if we have the backing of a strong, diverse coalition.”

Those interested in membership in the DAC are encouraged to complete the Registration of Interest form by May 19, 2016. The final selection of members is expected by May 31, 2016.

FTC Announces First APEC Cross-Border Privacy Rules Enforcement Action

On May 4, 2016, the Federal Trade Commission issued a press release announcing its recent settlement with the hand-held vaporizers manufacturer, Very Incognito Technologies, Inc. (“Vipvape”). The FTC had charged Vipvape with falsely claiming that it was a certified company under the Asia-Pacific Economic Cooperation (“APEC”) Cross-Border Privacy Rules (“CBPR”) framework. The settlement prohibits Vipvape from misleading consumers about its participation in any privacy and security certification program, including the APEC CBPR framework. This is the first CBPR-related case taken up by the FTC.

The APEC CBPR framework is a regional, multilateral, cross-border data transfer mechanism and enforceable privacy code of conduct developed for businesses by the 21 APEC member economies. The CBPRs implement the nine high-level APEC Privacy Principles set forth in the APEC Privacy Framework. Currently, the U.S., Mexico, Canada and Japan are participants in the APEC CBPR framework. Other APEC economies are in the process of determining how and when they may join.

Update: On June 29, 2016, the FTC approved the settlement with Vipvape.

EU General Data Protection Regulation Published in the EU Official Journal

On May 4, 2016, the EU General Data Protection Regulation (“GDPR”) was published in the Official Journal of the European Union.

Following the European Parliament’s vote to adopt the GDPR on April 14, 2016, and the signing of the final draft on April 27, 2016, the GDPR will enter into force 20 days following its publication in the Official Journal of the European Union. Its provisions will be directly applicable in all EU Member States two years after this date, on May 25, 2018.

After four years of drafting and negotiations, the GDPR finally replaces and harmonizes the existing EU data protection legal framework.

The Cryptographically Provable Con Man

It’s not actually surprising that somebody would claim to be the creator of Bitcoin.  Whoever “Satoshi Nakamoto” is, is worth several hundred million dollars.  What is surprising is that credible people were backing Craig Wright’s increasingly bizarre claims.  I could speculate why, or I could just ask.  So I mailed Gavin Andresen, Chief Scientist of the Bitcoin Foundation, “What the heck?”:

What is going on here?

There’s clear unambiguous cryptographic evidence of fraud and you’re lending credibility to the idea that a public key operation could should or must remain private?

He replied as follows, quoted with permission:

Yeah, what the heck?

I was as surprised by the ‘proof’ as anyone, and don’t yet know exactly what is going on.

It was a mistake to agree to publish my post before I saw his– I assumed his post would simply be a signed message anybody could easily verify.

And it was probably a mistake to even start to play the Find Satoshi game, but I DO feel grateful to Satoshi.

If I’m lending credibility to the idea that a public key operation should remain private, that is entirely accidental. OF COURSE he should just publish a signed message or (equivalently) move some btc through the key associated with an early block.

Feel free to quote or republish this email.

Good on Gavin for his entirely reasonable reaction to this genuinely strange situation.

Craig Wright seems to be doubling down on his fraud, again, and I don’t care.  The guy took an old Satoshi signature from 2009 and pretended it was fresh and new and applied to Sartre.  It’s like Wright took the final page of a signed contract and stapled it to something else, then proclaimed to the world “See?  I signed it!”.

That’s not how it works.

Say what you will about Bitcoin, it’s given us the world’s first cryptographically provable con artist.  Scammers always have more to say, but all that matters now is math.  He can actually sign “Craig Wright is Satoshi Nakamoto” with Satoshi’s keys, openly and publicly.  Or he can’t, because he doesn’t have those keys, because he’s not actually Satoshi.

A Glimpse at Petya Ransomware

Ransomware has become an increasingly serious threat. Cryptowall, TeslasCrypt and Locky are just some of the ransomware variants that infected large numbers of victims. Petya is the newest strain and the most devious among them.

Petya will not only encrypt files but it will make the system completely useless, leaving the victim no choice but to pay for the ransom, and it will encrypt filesystem’s Master File Table, which leaves the operating system unable to load. MFT is an essential file in NTFS file system. It contains every file record and directory on NTFS logical volume. Each record contains all the particulars that the operating system need to boot properly.

Like any other malware, Petya is widely distributed via a job application spear-phishing email that comes with a Dropbox link luring the victim by claiming the link contains self-extracting CV; in fact, it contains self-extracting executable that would later unleash its malicious behavior.

Petya dropper

Petya’s dropper

Petya's infection behavior

Petya’s infection behavior

 Petya ransomware has two infection stages. The first stage is MBR infection and encryption key generation, including the decryption code used in ransom messages. The second stage is MFT encryption.

First Stage of Encryption

First infection stage behavior

First infection stage behavior

An MBR infection is made through straightforward \\.\PhysicalDrive0 manipulation with the help of DeviceIOControl API. It first retrieves the physical location of the root drive \\.\c by sending IOCTL_VOLUME_GET_VOLUME_DISK_EXTENTS control code to the device driver.  Then it sends the extended disk partition info of \\.\PhysicalDrive0 through IOCTL_VOLUME_GET_VOLUME_DISK_EXTENTS control code.


The dropper will encrypt the original MBR using XOR opcode and 0x37 and save it for later use. It will also create 34 disk sectors containing 0x37. Right after the 34 sectors are Petya’s MFT infecting code. Located on Sector 56 is the original encrypted MBR.

Infected disk view

Infected disk view

Infected disk view

Infected disk view

Original Encrypted MBR

Original Encrypted MBR

After the MBR infection, it will intentionally crash the system by triggering NTRaiseHardError. This will trigger BSOD and the system will start, which will cause the machine to load using the infected MBR.

Code snippet triggering BSOD

Code snippet in triggering BSOD



Once we inspected the dumped image of the disk, we discovered it was showing a fake CHKDSK screen. We will also see the ransom message and ASCII skull art.

Dumped disk image

Dumped disk image

Second Infection Stage

The stage 2 infection code is written in 16-bit architecture, which uses BIOS interrupt calls.

Upon system boot up, it will load into memory Petya’s malicious code, which is located at sector 34. It will first determine if the system is already infected by checking the first byte at sector is 0x0. If not infected, it will display fake CHKDSK.



When someone sees the Figure 8, it means that the MFT table is already encrypted using salsa20 algorithm.

Figure 8

The victim will see this screen upon boot.

The victim will see this screen upon boot.

Ransom message and instructions

Ransom message and instructions

Petya Ransomware Page

The webpage for the victim to access their personal decryption key is protected against bots and contains information about when the Petya ransomware project was launched, warnings on what not to do when recovering files and an FAQ page. The page is surprisingly very user friendly and shows the days left before the ransom price will be doubled.

Ransom page captcha

Ransom page captcha

 Petya’s homepage

Petya’s homepage

It also contains news feeds, including different blogs and news from AV companies warning about Petya.

News 1 Figure 13

News 2

They also provide a step-by-step process on how to pay the ransom, including instructions on how to purchase bitcoin. Support via web is included too in case the victim encounters problems in the transaction they’ve made. Petya’s ransom is a lot cheaper compared to other ransomware, too.

Petya web page 1

Petya web page 2

Petya web page 3

Petya web page 4

On Step 4 of the payment procedure, the “next” button is disabled until they’ve confirmed that they already received the payment.

Petya support page

Petya’s support page

Below is a shot of ThreatTrack’s ThreatSecure Network dashboard catching Petya. Tools like ThreatSecure can detect and disrupt attacks in real time.

ThreatSecure Network catching Petya ransomware

ThreatSecure Network catching Petya ransomware


The post A Glimpse at Petya Ransomware appeared first on ThreatTrack Security Labs Blog.

CII Issues Investor-Engagement Guide on Cyber Risk

Recently, the Council of Institutional Investors (“CII”) issued a guide to shareholder engagement on cyber risk. The guide is intended to enable shareholders to ask appropriate questions of boards to gauge whether companies are taking proper steps to mitigate cyber risk. The guide poses the following five questions:

  • How are the company’s cyber risks communicated to the board, by whom and with what frequency?
  • Has the board evaluated and approved the company’s cybersecurity strategy?
  • How does the board ensure that the company is organized appropriately to address cybersecurity risks? Does management have the skill sets it needs?
  • How does the board evaluate the effectiveness of the company’s cybersecurity efforts?
  • When did the board last discuss whether the company’s disclosure of cyber risk and cyber incident is consistent with SEC guidance?

CII’s guide demonstrates the ongoing importance of cybersecurity and of boards being knowledgeable in the corporate governance area.

A Decade of Exploit Database Data

Managing the Exploit Database is one of those ongoing tasks that ends up taking a significant amount of time and often, we don't take the time to step back and look at the trends as they occur over time. Have there been more exploits over the years? Perhaps fewer? Is there a shift in platforms being targeted? Has the bar for exploits indeed been raised with the increase in more secure operating system protections?

Validating Satoshi (Or Not)


  1. Yes, this is a scam.  Not maybe.  Not possibly.
  2. Wright is pretending he has Satoshi’s signature on Sartre’s writing.  That would mean he has the private key, and is likely to be Satoshi.  What he actually has is Satoshi’s signature on parts of the public Blockchain, which of course means he doesn’t need the private key and he doesn’t  need to be Satoshi.  He just needs to make you think Satoshi signed something else besides the Blockchain — like Sartre.  He doesn’t publish Sartre.  He publishes 14% of one document.  He then shows you a hash that’s supposed to summarize the entire document.  This is a lie.  It’s a hash extracted from the Blockchain itself.  Ryan Castellucci (my engineer at White Ops and master of Bitcoin Fu) put an extractor here.  Of course the Blockchain is totally public and of course has signatures from Satoshi, so Wright being able to lift a signature from here isn’t surprising at all.
  3. He probably would have gotten away with it if the signature itself wasn’t googlable by Redditors.
  4. I think Gavin et al are victims of another scam, and Wright’s done classic misdirection by generating different scams for different audiences.


UPDATE:  This signature does actually validate, you just have to use a different version of OpenSSL than I did originally.


Of course, if this is the signature that already went out with that block, it doesn’t matter.  So I’m looking into that right now.

Update 2:

OK, yes, this is intentional scammery.  This is the 2009 transaction.  See this:


And then, that hex is of course this hex, as in the zip below:


Of course that’s exactly what Uptrenda on Reddit posted.  Gotta give Wright very small props, that’s a mildly clever replay attack, foiled by total lack of QA.


So Craig Wright is claiming to be Satoshi, and importantly, Gavin Andreson believes him.  I say importantly because normally I wouldn’t even give this document a second thought, it’s obviously scam style.  But Gavin.  Yet, the procedure that’s supposed to prove Dr. Wright is Satoshi is aggressively, almost-but-not-quite maliciously resistant to actual validation.  OK, anyone can take screenshots of their terminal, but sha256sums of everything but the one file you actually would like a hash of?  More importantly, lots of discussion of how cryptography works, but not why we should consider this particular public key interesting.

But it could actually be interesting.  This public key claimed is indeed from a very early block, which was the constraint I myself declared.

But for those with an open mind, moving a few chunks of the so-called “bitcoin billion” should be proof enough, says Dan Kaminsky, a well-known security researcher with a history of bitcoin analysis. Even the theory that Wright might have somehow hacked Nakamoto’s computer hardly discounts that proof, Kaminsky argues. “Every computer can be hacked. But if he hacked Satoshi, then this guy knew who the real Satoshi was, and that’s more than what the rest of us can say,” Kaminsky points out. “If Wright does a transaction with one of these keys, he’s done something no other wannabe-Satoshi has done, and we should recognize that.”

OK, it’s not a key attached to the Bitcoin billion, but Block 9 is close enough for me.  The bigger issue is that I can’t actually get the process to yield a valid signature.  I’ve gone over the data a few times, and the signature isn’t actually validating.  I’m not going to read too much into this because Dr. Wright didn’t actually post an OpenSSL version, and who knows if something changed.  But it is important to realize — anyone can claim a public key, that’s why they’re called public keys.  The signature actually does need to validate and I haven’t gotten it to work.2016-05-02_02h15_23.png

I could have missed something, it’s pretty late.  So here’s the binary blobs — nobody should have to try to hand transcribe and validate hex like this.  If I had to speculate, it’s just some serious fat fingering, where the signature is actually across some other message (like that Sartre text we see 14% of).  Alternate explanations have to be … unlikely.