Monthly Archives: December 2017

Info Stealing: a new operation in the wild

Attack attribution is always a very hard work. False Flags, Code Reuse and Spaghetti Code  makes impossible to assert "This attack belongs to X". Indeed nowadays makes more sense talking about Attribution Probability rather then Attribution by itself. "This attack belongs to X with 65% of attribution probability" it would be a correct sentence.

I made this quick introduction because the following analysis would probably take the reader to think about specific attribution, but it wont be so accurate, so please be prepared to have not such a clear conclusions.

Today I'd like to show an interesting analysis of a quite new InfoStealer Malware delivered by eMail to many International Companies. The analysis shows up interesting Code Reuse capabilities, apparently originated by Japanese Attackers reusing an English Speaker Attacker source code. Again I have not enough artifacts to give attributions but only few clues as follows. In the described analysis, the original sample was delivered by (with high probability a compromised South Africa account) to one of my spamming email addresses.

The obtained sample is a Microsoft Word document within macro in it. The macros were heavily obfuscated by using four rounds of substitutions and UTF-8 encoding charsets (which, by the way, is super annoying). The following image shows the obfuscated macro code with UTF-8 charsets.

Stage 1: Obfuscation
 By using oletools and "tons" of cups of coffee (to be awake until late night to make recursive steps) I finally was able to extract the invoked command, showed in the following image.

Stage 1: Invoked Command
A fashionable powershell command drops and executes: hxxp:// Powershell seems to be a "must have" in contemporary Malware. Analyzing the "dropping" url and tracking down the time it is in "Index Of" mode (2017-0-13), I suspect it is not a compromised website rather a crafted web server or a compromised host of a dead company.

Dropping Web Site

By surfing on the Malware propagator web site I founded out many malicious executables (sees IoC section) each one showing up specific behaviors such as: password stealers, RAT and Banking Trojans. Even if the samples were developed for different targets, all of them shared the following basic behaviors:

  • Check for victims IP address before getting into Malicious activities (maybe related to targeted activities)
  • Install itself into auto execution path
  • Tries to fingerprint the target system (such as CPU, HD, Memory, Username, System, etc..)
  • Sniff for Keystrokes

I'd like to write a simple analysis for each found sample, but today time is not my friend, so let's focalize to one of the malicious samples. Let's get done the received sample by digging into the "second stage" dropped by the powershell "first stage" from After few seconds on second stage (off.exe) it became clear that it was a .NET software. By reversing the interpreted .NET language some clear text comments appeared interesting. Japanese language such as comments and variable names came out from static analysis. Let's have a look to them.

Stage 2: Apparently Japanese characters

While the sample pretends to be compiled from "Coca-Cola Enterprise" (maybe a target operation against Coca-Cola ? Or a targeted operation agains Coca-Cola Suppliers ? So why it ended up to my inbox ? Anyway ... ) google translator suggests me that Japanese characters are in text: such as the "Entry Point", "Class names" and "Function Names". 

Stage 2: Japanese Names and Self Encoding Structures

It was not hard to figure out that Stage 2 was auto-extracting bytes from itself (local variables) and saving them back to hard drive after having set up auto execution registry key on windows local registry.  The following image shows the xoring function used to decrypt converted bytes to the real payload. 

Stage 2: Xoring function to extract Stage 3

On my run, the xored payload took the name of GIL.exe; another .NET  executable. We are now facing the third stage. By analyzing the decompiled sample it became clear that:
  • The coding style was quite different from the previous stage (Stage 2)
  • The implementation style was different from the previous stage as well
  • The sample was interested on information about the user, the machine, the webservices on the PC and to many more windows specific parameters.
Stage 3:  New Language in Strings and Class names
Stage 3: New Code Style

By closely investigating Stage 3, the analyst would probably notice the heavy presence of "decorators", a different format in the definition style and last but not least the code composition. Everything looks like belonging to different single developers. The variable language, the comments structure and the general usage of terms, takes the analyst to believe in having found two different developers belonging to different cultures (maybe countries). Finally the malware looks for users, computes, and webservices informations and drops everything up to C2 by posting parameters to :

Following the principal IoC for the described threat.
  • Hash Stage 1:
    • 7f1860673de9b1c2e6f7d6963a499e8ba4e412a1
    • bf4a26c9e52a8cacc7afd7d95d197bff1e47fb00
  • Hash Stage 2:
    • ac55ee783f3ed0bd23eccd01040a128dc6dc7851
  • Hash Stage 3:
    • 6a38e4acd9ade0d85697d10683ec84fa0daed11c
  • Persistence: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run\kij %APPDATA%\Roaming\kij\kij.exe
  • Dropping URL:
  • Command and Control:
  • Related hashes from harvesting Dropping URL:
    • 62c9d2ae7bafa9c594230c570b66ec2d4fa674a6
    • b15b69170994918621ceb33cb339149bdff5b065
    • 55abcfb85e664fbc8ad1cb8b60a08409c2d26caa
    • f843427e9b7890f056eaa9909a5103bba6ffb8fd
    • f2b81e66fcb1032238415b83b75b3fe8bf28247d
    • cab90f7c935d355172b0db123d20b6a7d1403f65
    • c1ba30d7adec6d545d5274f95943f787ad4c03e7
    • ed9959bb0087f2c985b603cee0e760f3e0faaab15
    • c93851627ffd996443f85d916f3dbedd70e0ff69
    • 144b34b4816062c2308a755273159e0460ffd604
    • 98293b80ccf312a8da99c2b5ca36656adebd0d0f 
    • 2875d1b54337b1c17c8f4cd5f6b2d579667ee3d9 
    • 0b4299ffb3f9aa59e19dd726e79d95365fe1d461
    • 46bb0b10d790a3f21867308e7dcdeb06784a1570
    • 0960726560a94fbbb327aa84244f9588a3c68be8 
    • a480a75c3af576e5656abadb47d11515a18a82be
    • 2ba809c53eda2a475b1353c34f87ce62b6496e16
    • 5b0c3071aa63e18aa91af59083223d3cceb0fa3c 
    • dc780bf338053e9c1b0fdf259c831eb8a2768169

As final thought I'd like to highlight the following key concept of that analysis:
  • From a single email, the analyst could discover attacker's assets, mapping them and disarming them (through IoC). 
  • The analyzed code shows apparent evidences to belonging to different groups of attackers.
  • The analyzed samples show code reuse. Code reuse is dangerous because it makes attackers more powerful and extremely quick to change Malware behavior.
Hope you enjoyed.

Happy New Year – Startup Security Weekly #67

This week, Rick Olesek and Rich Walchuck of CryptoniteNXT join us for an interview! In the article discussion, we talk about startups most likely to succeed, how to pitch your app to investors, and calculating your total addressable market! In the news, we have updates from Thales, Amazon, Convercent, ADT, and more on this episode of Startup Security Weekly!

Full Show Notes:

Visit for all the latest episodes!

FERC Issues Notice of Proposed Rulemaking Aimed at Expanding Data Breach Reporting Obligations

On December 21, 2017, the Federal Energy Regulatory Commission (“FERC”) issued a Notice of Proposed Rulemaking (“NOPR”) aimed at expanding mandatory reporting obligations in relation to cybersecurity incidents. In particular, FERC’s NOPR would direct the North American Electric Reliability Corporation (“NERC”) to develop modifications to certain Critical Infrastructure Protection (“CIP”) Reliability Standards so that those standards require mandatory reporting of cybersecurity incidents that compromise or attempt to compromise a responsible entity’s Electronic Security Perimeter (“ESP”) or associated Electronic Access Control or Monitoring Systems.

Currently, the CIP Reliability Standards require cybersecurity incidents to be reported only if they have actually disrupted one or more reliability tasks, so unsuccessful attempts to penetrate an ESP— or successful attempts that do not disrupt reliability tasks—would not need to be reported. FERC’s staff noted in the presentation of the NOPR that the existing reporting threshold for cybersecurity incidents “may understate the true scope of cyber-related threats facing the bulk electric system,” citing the fact that there were zero reported cybersecurity incidents in either 2015 or 2016 under the current reporting requirements. This lack of reported cybersecurity incidents stands in contrast with the 59 cybersecurity incidents within the Energy Sector to which the Department of Homeland Security responded in 2016 alone.

In addition to broadening the scope of the mandatory reporting requirements, the NOPR also seeks to improve the quality of the reports themselves by specifying the information that is required to be included in cybersecurity incident reports in an effort to facilitate comparative analysis. NERC would also be required to file with FERC an anonymized, aggregated annual public summary of the reports.

Comments on the NOPR must be filed with FERC within 60 days after it is published in the Federal Register.

Merry Christmas – Paul’s Security Weekly #541

Bob Hillery, Co-Founder and Director of InGuardians joins us for an interview, and Kevin Finisterre, Principal of the Security Consultancy of Department 13 joins us to deliver the tech segment! In the news, Uber pays hacker to keep quiet, flaw in Intel processors allowing undetectable malware, Apple patches other High Sierra security holes, and more on this episode of Paul's Security Weekly!

Full Show Notes:

Visit for all the latest episodes!

Privacy and Information Security Law Blog’s Top 10 Posts of 2017

What were the hottest privacy and cybersecurity topics for 2017? Our posts on the EU General Data Protection Regulation (“GDPR”), EU-U.S. Privacy Shield, and the U.S. executive order on cybersecurity led the way in 2017. Read our top 10 posts of the year.

Article 29 Working Party Releases GDPR Action Plan for 2017

On January 16, 2017, the Article 29 Working Party (“Working Party”) published further information about its Action Plan for 2017, which sets forth the Working Party’s priorities and objectives in the context of implementation of the GDPR for the year ahead. The Action Plan closely follows earlier GDPR guidance relating to Data Portability, the appointment of Data Protection Officers and the concept of the Lead Supervisory Authority, which were published together by the Working Party on December 13, 2016. Continue reading

Privacy Shield: Impact of Trump’s Executive Order

On January 25, 2017, President Trump issued an Executive Order entitled “Enhancing Public Safety in the Interior of the United States.” While the Order is primarily focused on the enforcement of immigration laws in the U.S., Section 14 declares that “Agencies shall, to the extent consistent with applicable law, ensure that their privacy policies exclude persons who are not United States citizens or lawful permanent residents from the protections of the Privacy Act regarding personally identifiable information.” This provision has sparked a firestorm of controversy in the international privacy community, raising questions regarding the Order’s impact on the Privacy Shield framework, which facilitates lawful transfers of personal data from the EU to the U.S. While political ramifications are certainly plausible from an EU-U.S. perspective, absent further action from the Trump Administration, Section 14 of the Order should not impact the legal viability of the Privacy Shield framework. Continue reading

CNIL Publishes Six Step Methodology and Tools to Prepare for GDPR

On March 15, 2017, the French data protection authority (the “CNIL”) published a six step methodology and tools for businesses to prepare for the GDPR that will become applicable on May 25, 2018. Continue reading

German DPA Publishes English Translation of Standard Data Protection Model

On April 13, 2017, the North Rhine-Westphalia State Commissioner for Data Protection and Freedom of Information published an English translation of the draft Standard Data Protection Model. The SDM was adopted in November 2016 at the Conference of the Federal and State Data Protection Commissioners. Continue reading

President Trump Signs Executive Order on Cybersecurity

On May 11, 2017, President Trump signed an executive order (the “Order”) that seeks to improve the federal government’s cybersecurity posture and better protect the nation’s critical infrastructure from cyber attacks. The Order also seeks to establish policies for preventing foreign nations from using cyber attacks to target American citizens. Read the full text of the Order.

Bavarian DPA Tests GDPR Implementation of 150 Companies

On May 24, 2017, the Bavarian Data Protection Authority (“DPA”) published a questionnaire to help companies assess their level of implementation of the GDPR. Continue reading

Article 29 Working Party Releases Opinion on Data Processing at Work

The Working Party recently issued its Opinion on data processing at work (the “Opinion”). The Opinion, which complements the Working Party’s previous Opinion 08/2001 on the processing of personal data in the employment context and Working document on the surveillance of electronic communications in the workplace, seeks to provide guidance on balancing employee privacy expectations in the workplace with employers’ legitimate interests in processing employee data. The Opinion is applicable to all types of employees and not just those under an employment contract (e.g., freelancers). Continue reading

New Data Protection Enforcement Provisions Take Effect in Russia

As reported in BNA Privacy Law Watch, on July 1, 2017, a new law took effect in Russia allowing for administrative enforcement actions and higher fines for violations of Russia’s data protection law. The law, which was enacted in February 2017, imposes higher fines on businesses and corporate executives accused of data protection violations, such as unlawful processing of personal data, processing personal data without consent, and failure of data controllers to meet data protection requirements. Whereas previously fines were limited to 300 to 10,000 rubles ($5 to $169 USD), under the new law, available fines for data protection violations range from 15,000 to 75,000 rubles ($254 to $1,269 USD) for businesses and 3,000 to 20,000 rubles ($51 to $338 USD) for corporate executives. Continue reading

CNIL Publishes GDPR Guidance for Data Processors

On September 29, 2017, the French Data Protection Authority published a guide for data processors to implement the new obligations set by the GDPR. Continue reading

Article 29 Working Party Releases Guidelines on Automated Individual Decision-Making and Profiling

On October 17, 2017, the Working Party issued Guidelines on Automated individual decision-making and Profiling for the purposes of Regulation 2016/679 (the “Guidelines”). The Guidelines aim to clarify the GDPR’s provisions that address the risks arising from profiling and automated decision-making. Continue reading…

Blog-ified Tweetstorm

I dumped this on Twitter as a tweetstorm, but it is worth sharing here in one place.

Those who have followed me for a while have probably noticed that I rarely get technical here anymore. My world, and world view have changed.

I still play with stuff, but it tends to be specific to the nice folks who pay me, or esoteric stuff for personal use. Or for @SecurityBSides networks and labs.

I believe that right now I can do more good by supporting our communities and the people in them (that means YOU) than by focusing on technology myself.

The past few years have not been fun for me. My wife had a 2.5 year battle with cancer which ended a year ago this Friday, I've spent the past year discovering what it means to be without her after 40 years together.

(Also, this "being single" thing is bizarre, now I get what you kids have been complaining about- but that's a story for another day, or a stand-up comedy set)

Thank you all for all of your words and acts of kindness, large and small. It has meant a great deal to me. I might not be here now if not for the support of more people than I can thank.

Yeah, I said that. There were days when I asked myself the question "Do I want to wake up tomorrow?". And there were times when the answer was "no". I never seriously considered acting on it, but yes, there were ugly days, and not just a few.

If I can repay the amazing support and kindness shown to me by making things less bad for others I'm all in.

Disclaimer: I am not a psychologist, therapist, doctor, or anything like that. That said, if you need someone to talk/vent/rant/cry to, I'll be here as much as I can. Really. Dealing with stress, burnout, anxiety, illness, or death: I'll do my best to be here for you.

I travel a lot and I'm not always available, so don't count on me for immediate responses. But count on me. And if I get overwhelmed, I'll back off until I can resume.

I'm not the only one to make an offer like this, find one of us or turn to professionals if you need more than a sympathetic ear.

The holidays are a time of happiness and joy for many people. But they are also unpleasant for many of us, so let's take care of each other this holiday season. And the rest of the year, too.

Now you smart kids get busy on the technology stuff.



The CNIL Serves Formal Notice to WhatsApp Regarding Sharing Data with Facebook

On December 18, 2017, the French data protection authority (“CNIL”) publicly announced that it served a formal notice to WhatsApp regarding the sharing of WhatsApp users’ data with Facebook Inc. (“Facebook”). This decision, dated November 27, 2017, follows the CNIL’s investigations regarding Facebook’s 2014 acquisition of WhatsApp. In 2016, WhatsApp updated its Terms of Service and Privacy Policy to reflect the sharing of information with Facebook. Following this update, the Article 29 Working Party (“Working Party”) requested explanations from WhatsApp on its data processing practices and data sharing, and asked the company to stop sharing data for targeted advertising purposes. The Working Party also gave a mandate to its subgroup in charge of the cooperation on investigations and sanctions to coordinate actions of the relevant national data protection authorities. It is in that context that the CNIL started its investigation of WhatsApp’s data processing practices.

In its decision, the CNIL found that WhatsApp violated the French Data Protection Act of January 6, 1978, as amended (Loi relative à l’informatique, aux fichiers et aux libertés) by: (1) sharing data with Facebook without an appropriate legal basis, (2) not providing sufficient notice to the relevant data subjects, and (3) not cooperating with the CNIL during the investigation.

Lack of Legal Basis

While WhatsApp shares its users’ data with Facebook for both business intelligence and security purposes, the CNIL focused its analysis on the “business intelligence” purpose. WhatsApp represented that such sharing was based on consent and legitimate interest as legal grounds. In its analysis of both legal bases, the CNIL concluded that:

  • WhatsApp cannot rely on consent to share users’ data with Facebook for “business intelligence” purposes on the grounds that: (1) the consent is not specific enough, and only refers to the messaging service and improving Facebook’s services, and (2) the consent is not freely given, as the only way for a user to object to such processing is to uninstall the application.
  • WhatsApp cannot rely on a legitimate interest to share users’ data with Facebook for “business intelligence” purposes because the company has not implemented sufficient safeguards to preserve users’ interests or fundamental rights. There is no mechanism for the users to refuse the data sharing while continuing to use the application.

Lack of Notice to Data Subjects

The CNIL found that WhatsApp did not provide sufficient notice on the registration form to data subjects about sharing personal data with Facebook.

Lack of Cooperation with the CNIL

The CNIL found that WhatsApp did not provide necessary cooperation during the investigation, such as refusing to provide the CNIL with data pertaining to a sample of French users on the basis that such request conflicts with U.S. law.

The CNIL’s Requests

In its formal notice, the CNIL requires WhatsApp to, within one month:

  • cease sharing users’ data with Facebook for the purpose of “business intelligence” without a legal basis;
  • provide a notice to data subjects that complies with the French Data Protection Act, and informs them of the purposes for which the data is shared with Facebook and their rights as data subjects;
  • provide the CNIL with all the sample personal data requested (i.e., all data shared by WhatsApp with Facebook for a sample of 1,000 French users); and
  • confirm that the company has complied with all of the CNIL’s requests above within the one month deadline.

If WhatsApp fails to comply with the terms of the formal notice within one month, the CNIL may appoint an internal investigator, who may propose that the CNIL imposes sanctions against the company for violations of the French Data Protection Act.

Christmas Directories – Enterprise Security Weekly #73

This week, Paul and John talk about Active Directory insecurity, how to solve problems with endpoint detection and response, and how to fix authentication issues! In the news, we have updates from Flexera, Amazon, ExtraHop, and more on this episode of Enterprise Security Weekly!


Full Show Notes:


Visit for all the latest episodes!

Transitioning from Blue Team to Red Team

I moved from Desktop Supervisor to Network Security in 2000. I did Blue Team for two companies from 2000 until early this year. At that point I was given an opportunity to move to Red Team as the company's in-house penetration tester. Starting in a new discipline in Network Security is a daunting task after spending so many years in another area, but a couple of things already were in my favor. I had taken two Red Team oriented SANS courses and certified in both and I had been doing deep dive intrusion analysis for all those years. I was exposed to a lot of methodologies and exploits.

But defending isn't attacking, and the learning curve was (is) still very wide. Fortunately, there are shared areas of knowledge between being an intrusion analyst and a pen tester. If you're just breaking into network security, those areas will serve you well regardless of what direction you go (or change to in the future).

1. Linux

Linux is the operating system of choice for the majority of tools for both pen testing and intrusion analysis. There are some exceptions, tools you can only run on Windows, but that's a very small subset. The more Linux you learn, the better prepared you'll be to use whichever tool is the correct one for any given situation. Fortunately, there's more free (and excellent) self training on Linux than any other subject I know of. You don't need to spend thousands of dollars taking training courses or get a Linux certification; there are hundreds of sites that will teach you step by step. Of course, if you're fortunate enough to work for a company that wants you to do RedHat or Linux Foundation training and will pay for it, by all means do so. Certifications will help you both move up in your current position and, if you should need to or choose to, find a new position. Redhat is the most well known name and bigger companies will be running it because of their excellent support, but there are other good courses and certs you can obtain. But by all means, spin up a Linux machine and get in it and learn. The more you learn, the better off you'll be.

2. Scripting

You don't need to be a programmer to do either job, but learning some scripting skills will really help you. Whether it's Bash or a language like Python or Ruby or Perl, being able to create a script to do repetitive tasks is an immense time saver. Another advantage is that if the tool you need to use is written in a shell or a language you understand, you can open it and follow the logic to see what it does, or even modify it, tweak and customize it, to suit your unique purpose. Python is extremely popular right now so a lot of the tools being released are written in it. And it's one of the easiest languages to learn. And, like Linux, there are a lot of free resources to learn Python.

3. Networking

Learning about networking is essential, whether you're running exploits or investigating an attack. Without a basic knowledge of how networks work and the components that comprise them, you'll be confused and lost in a short amount of time. You don't have to be a packet jockey to do intrusion analysis (the vast majority of attacks have switched from server side to client side anyways), but you will need to be able to follow the flow of traffic and understand the protocols in use to get a clear picture of the attack and whether it was successful or not. From a pentester's vantage point, you need to understand the network you're attacking to find the correct target and use the correct tool, and to be able to understand the responses your attack receives. If it's unsuccessful, you need to be able to determine why and what to change. The more you understand, and it's a vast and complex field, the better off you'll be.

Finally, whatever direction you go in, invest in yourself learning. The hardest part of doing that is your free time. You're not going to be able to learn everything you need to know while at your job or in a weeks worth of training once a year. If you want to advance, you'll need to sacrifice some of your own free time to study and learn. If it's something you naturally enjoy learning about, it won't be too big a burden. If you absolutely hate studying the subject matter, maybe it's time to step back and reassess if this is really what you want to do the rest of your life.

Good luck in your career, and Merry Christmas and have a Blessed New Year.

Lisa Sotto Recognized as a Leading Woman Lawyer by Crain’s New York Business

On December 18, 2017, Lisa Sotto, chair of the Global Privacy and Cybersecurity practice at Hunton & Williams LLP and managing partner of the firm’s New York office, was recognized among the Leading Women Lawyers in NYC by Crain’s New York Business.

This inaugural listing features female attorneys who have impacted New York City in significant ways, and honors their distinguished careers and exceptional civic and philanthropic activities. “Their stories are ones of fierce determination, passion for the law, keen intelligence, and inspiring achievement,” the New York State Bar Association’s Committee on Women in the Law recently noted.

Subscribers can access the full list here.

Article 29 Working Party Published Guidelines on Transparency under the GDPR

On December 12, 2017, the Article 29 Working Party (“Working Party”) published its guidelines on transparency under Regulation 2016/679 (the “Guidelines”). The Guidelines aim to provide practical guidance and clarification on the transparency obligations introduced by the EU General Data Protection Regulation (“GDPR”). The transparency obligations require controllers to provide certain information to data subjects regarding the processing of their personal data. Key takeaways from the Guidelines include:

  • “Concise, transparent, intelligible and easily accessible” information notices: In order to be compliant, the information provided to data subjects regarding the processing of their personal data must be clearly distinguished from other information. This means controllers that attempt to hide processing information in the middle of wider terms and conditions will be in breach of the GDPR. The Working Party recommends processing information be provided in a “layered” structure that allows data subjects to navigate easily through the information. The Guidelines suggest that the first layer provide a clear overview of processing where they can find more detailed information, as well as information for data subjects on processing that has the greatest impact on them and processing that may come as a surprise to them. It is further recommended that a hyperlink to the privacy policy is provided at the point of data collection.
  • “Clear and plain language” must be used: Information should be provided in a manner that is easy to understand and avoids complex sentences and language structures. Language must also be unambiguous, and avoid abstract terminology or equivocal language (e.g., conditional tenses and qualifying terms, such as “may,” “might” or “some”). In particular, where information is provided to children or other vulnerable people, the vocabulary, style and tone of the language must be adapted appropriately.
  • Information must be “in writing or by other means”: Where a controller maintains a website, the Working Party recommends using electronically layered privacy notices. Other electronic means can be used to provide information to data subjects, including “just-in-time” contextual pop-up notices, 3D touch or “hover-over” notices and privacy dashboards. The chosen method must be appropriate for the circumstances.
  • Information “may be provided orally”: Controllers may provide information orally if the identity of the data subject is clear. This does not apply to the provision of general privacy information to prospective customers or users whose identity currently cannot be verified. Oral information may be provided on a person-by-person basis or by automated means. Where automated means are adopted, the Working Party recommends the implementation of measures that allow data subjects to re-listen to the information, for example, through pre-recorded messages that can be replayed. In this context, controllers must maintain records and be able to demonstrate that (1) the data subject requested that information is provided orally, (2) where necessary, the identity of the data subject was verified, and (3) information was in fact provided to the data subject.
  • Information must be provided free of charge: Controllers are prohibited from charging fees for the provision of processing information to data subjects. The provision of information also cannot be made conditional upon entry into a financial transaction.
  • Content of the notice: With respect to the content of information to be provided to data subjects, the Guidelines refer to Articles 13 and 14 of the GDPR and the Annex to the Guidelines, which list the categories of information that must be included in the notices. The Working Party also clarifies that all categories of information to be provided pursuant to Articles 13 and 14 of the GDPR are of equal importance. The Working Party recommends that controllers provide data subjects with an overview of the consequences of the processing as it affects them, in addition to the information prescribed by the Articles.
  • Changes to the notice: The Guidelines emphasize that the transparency requirements apply throughout the processing process. Any subsequent changes to a privacy notice must be communicated to data subjects. In this respect, the Guidelines recommend controllers explain to data subjects any likely impact that the changes may have on them. Where processing occurs on an ongoing basis, controllers are recommended to inform and periodically remind data subjects of the scope of the data processing.
  • Timing: Information must be provided to data subjects at the commencement phase of the processing cycle when personal data is obtained and, in the case of personal data that is obtained indirectly, within a reasonable period (and no later than one month) following the receipt of the personal data. Where personal data is obtained indirectly and is to be used for communications with data subjects, information must be provided, at the latest, at the time of the first communication, but in any event within one month of receipt.
  • Exceptions to the obligation to provide information: The Guidelines explain that exceptions to the obligation to provide information to data subjects about the processing of their personal data must be interpreted and applied narrowly. In addition, it stresses the importance of accountability for controllers. Where controllers seek to rely on exceptions, then as a general rule they must be able to demonstrate the circumstances or reasons that justify reliance on those exemptions (e.g., demonstrate the reasons why providing the information would prove impossible or involve disproportionate efforts).

The Guidelines state that controllers must review all information provided to data subjects regarding the processing of their personal data prior to May 25, 2018. The Working Party is accepting comments on the Guidelines until January 23, 2018.

How to securely erase your Android device in 4 steps

It's an inevitable moment in the smartphone-owning cycle, the point at which a newer, shinier model comes along and your trusty old device is no longer needed.

Maybe your company bought you a new Android phone. Maybe your old one was getting too slow. Or maybe you just love electronics and couldn't resist the lure of whatever sexy new Android device your favorite manufacturer started selling.

Whatever the case, it's common nowadays to find yourself with an extra phone. And while there are plenty of practical uses for an old Android device, there's also a time when the best choice is to sell, donate, or otherwise pass it along.                                                                            

To read this article in full, please click here

Hack Naked News #154 – December 19, 2017

Michael reports on a suspected North Korea Ransomware attack, Kaspersky federal software ban, compelled passwords, and 1 in 3 IT professionals looking for new jobs! Jason Wood of Paladin Security joins us for the expert commentary on Bitcoin, and more on this episode of Hack Naked News!


Full Show Notes:


Visit for all the latest episodes!

Don’t be a security snob. Support your business team!

Don't be a security snob. Support your business team!

There have been many a times that access controls have been discussed in the meetings related to web development. With an interconnected world of APIs it is very important to understand the authentication of these end-points. One of the best approach I always vouch for is mutual authentication on SSL certificates (or 2 way SSL). Most of the times it is viable but it fails when either of party couldn't support it (hence not mutual). So, what to do when the business can't implement your "security requirement"?

The role of security is not to hinder the business, but to support it. It has to act as a pillar, and not a tollgate. We all know, that's audit!

Are you a security snob?
The rules/ regulations made by us, auditors and regulators are to make sure the architecture, implementation and roll-out is secure, and the information is tightly controlled. It is in no manner adding to the miseries of developers at the last stage of go-live. The security requirements must be clear right from the design phase. There must be a security architect appointed to work in accordance with the industry standards, and security nitty-gritties. Sometimes the security team gets to know that few important implementations have not been considered and now the project is at final stage. What should the security do - Shall it take business to the grinding halt? Shall it take the developers back to drawing board? No and no! Don't be a snob!

Look forward, and figure out the workarounds; strong mitigations steps to find a way to lower the risk. As long as you can lower the risk to minimum by using WAF, access controls, and white-listing etc. the business can make a plan to "fix" it in the next release. Make sure business understands the risk - brand or financial, and then if the risk is too high - involve the "C" suite executives, but support the business instead of bashing them with - you didn't do this, or that. It is counter-productive and doesn't help any party.

In most cases "business" accounts for the IT security paychecks and it's your (security team) job to avoid it looking like an overhead, but an investment!
IT security is NOT generating money. So don't point fingers, but hold hands!

Now, in the case of mutual authentication - what if the 2-way SSL is not available? Is IP white-listing a possible option with API credentials? Yes, if the IP is not shared by the whole network & the traffic is over secure channel. It's a strong measure to apply and restrict the participating parties to talk 1:1 on an encrypted channel. But then, I have been asked what if there is IP spoofing? Come'on guys! IP spoofing doesn't work the way you think. It's a TCP handshake; how do you expect the handshake to succeed when the IP doesn't ACK the SYN-ACK? Rememeber, the "actual IP" is not expecting the SYN-ACK & traffic will not go to the "malicious IP". So, IP spoofing over Internet is out of picture.

As a security specialist, try to understand that there are various ways to strengthen the security without being a pain in the ass. There are ways to implement compensatory controls; making sure the traffic is encrypted, access controls are tightly restricted, and risk is lowered significantly. If you can do this, you can definitely help business go live, and give them time to manage the security expectations more constructively.

Cheers, and be safe.

Cancer Center Settles with HHS for $2.3 Million over Data Breach

As reported in BNA Privacy Law Watch, on December 6, 2017, health care provider 21st Century Oncology agreed to pay $2.3 million to settle charges by the Department of Health and Human Services’ (“HHS”) Office for Civil Rights (“OCR”) that its security practices led to a data breach involving patient information. The settlement was made public in the company’s December 6, 2017, bankruptcy filing. The HHS charges stemmed from a 2015 data breach involving the compromise of Social Security numbers, medical diagnoses and health insurance information of at least 2.2 million patients. OCR found that 21st Century Oncology failed to perform risk assessments on its systems or implement effective security protocols to protect patient information. As part of the settlement, 21st Century Oncology did not admit liability but did agree, in addition to the $2.3 million payment, to undertake a revision of its information security policies and procedures and to implement certain information security measures, including risk assessments.

aPAColypse now: Exploiting Windows 10 in a Local Network with WPAD/PAC and JScript

by Ivan Fratric, Thomas Dullien, James Forshaw and Steven Vittitoe


Many widely-deployed technologies, viewed through 20/20 hindsight, seem like an odd or unnecessarily risky idea. Engineering decisions in IT are often made with imperfect information and under time pressure, and some oddities of the IT stack can best be explained with “it seemed like a good idea at the time”. In the personal view of some of the authors of this post, WPAD (“Web Proxy Auto Discovery Protocol” - and more specifically “Proxy Auto-Config”), is one of these oddities.

At some point in the very early days of the Internet - prior to 1996 - engineers at Netscape decided that JavaScript was a good language to write configuration files in. The result was PAC - a configuration file format that works as follows: The browser connects to a pre-configured server, downloads the PAC file, and executes a particular Javascript function to determine proper proxy configuration. Why not? It certainly is more expressive and less verbose than (let’s say) XML, and seems a reasonable way to provide configurations to many clients.

PAC itself was coupled with a protocol called WPAD - a protocol that makes it unnecessary for the browser to have a pre-configured server to connect to. Instead, WPAD allows the computer to query the local network to determine the server from which to load the PAC file.

Somehow this technology ended up being an IETF draft which expired in 1999, and now, in 2017, every Windows machine will ask the local network: “Hey, where can I find a Javascript file to execute?”. This can happen via a number of mechanisms: DNS, WINS, but - perhaps most interestingly - DHCP.

In recent years, browser exploits have mutated from being primarily DOM-oriented to targeting Javascript engines directly, so the mere mention that we can get Javascript execution over the network without the browser was motivating. An initial investigation revealed that the JS Engine responsible for executing these configuration files was jscript.dll - the legacy JS Engine that also powered IE7 and IE8 (and is still reachable in IE11 in IE7/8 compatibility mode if appropriate script attributes are used). This is both good and bad - on the one hand, it means that not every Chakra bug is automatically a local network remote attack, but on the other hand, it means that some pretty old code will be responsible for executing our Javascript.

Security researchers have previously warned about the dangers of WPAD. But, as far as we know, this is the first time that an attack against WPAD is demonstrated that results in the complete compromise of the WPAD user’s machine.

Windows is certainly not the only piece of software that implements WPAD. Other operating systems and applications do as well. For example Google Chrome also has a WPAD implementation, but in Chrome’s case, evaluating the JavaScript code from the PAC file happens inside a sandbox. And other operating systems that support WPAD don’t enable it by default. This is why Windows is currently the most interesting target for this sort of attack.

Web Proxy Auto-Discovery

As mentioned above, WPAD will query DHCP and DNS (in that order) to obtain a URL to connect to - apparently LLMNR and Netbios can also be used if no response from DNS is available. Some peculiarities of WPAD-over-DNS enable surprising attack vectors.

Attack scenario: Local network via DHCP

In the most common scenario, a machine will query the local DHCP server using option code 252. The DHCP server replies with a string - like “http://server.domain/proxyconfig.pac”, which specifies a URL from which the configuration file should be fetched. The client then proceeds to fetch this file, and execute the contents as Javascript.
In a local network, an attacker can simply impersonate the DHCP server - either by ARP games or by racing the legitimate DHCP. The attacker can then provide a URL where the malicious Javascript file is hosted.

Attack scenario: Remote over the internet via privileged position and DNS

Aside from the local-network attack scenario, the fact that lookup for WPAD may also happen via DNS creates a secondary attack scenario. Many users configure their computers to perform DNS lookups against one of the public, globally visible DNS servers (such as,, and In such a scenario, a machine will send DNS queries (such as wpad.local) to the server which sits outside of the local network. An attacker in a privileged position on the network (e.g. a gateway, or any other upstream host) can monitor the DNS queries and spoof a reply, directing the client to download and execute a malicious Javascript file.

Setups like these seem to be common - according to this Wikipedia entry, a nontrivial proportion of the traffic that the DNS root servers see are .local requests.

Attack scenario: Remote over the internet via malicious wpad.tld

A particular oddity of WPAD is that it recursively walks the local machine name to find domains to query. If a machine is called “”, the following domains are supposedly queried in order:


This has (according to this Wikipedia entry) in the past led to people registering and redirecting traffic to an online auction site. Further quoting from that entry:

Through the WPAD file, the attacker can point users' browsers to their own proxies and intercept and modify all of WWW traffic. Although a simplistic fix for Windows WPAD handling was applied in 2005, it only fixed the problem for the .com domain. A presentation at Kiwicon showed that the rest of the world was still critically vulnerable to this security hole, with a sample domain registered in New Zealand for testing purposes receiving proxy requests from all over the country at the rate of several a second. Several of the wpad.tld domain names (including COM, NET, ORG, and US) now point to the client loopback address to help protect against this vulnerability, though some names are still registered (
Thus, an administrator should make sure that a user can trust all the DHCP servers in an organisation and that all possible wpad domains for the organisation are under control. Furthermore, if there's no wpad domain configured for an organisation, a user will go to whatever external location has the next wpad site in the domain hierarchy and use that for its configuration. This allows whoever registers the wpad subdomain in a particular country to perform a man-in-the-middle attack on large portions of that country's internet traffic by setting themselves as a proxy for all traffic or sites of interest.

The IETF draft, on the other hand, explicitly asks for clients to only allow “canonical” (e.g. non-top-level domains). We have not investigated to what extent clients implement this, or if second-level domains (such as are the culprit in the historical cases of traffic redirection.

Either way: Bugs in the Javascript engine under consideration can be exploited remotely via the internet if one manages to register wpad.$TLD for a given organization’s TLD, provided said TLD is not explicitly blacklisted by the client implementation. Given that the IETF draft from 1999 refers to a list of TLDs from 1994 (RFC1591), it is unlikely that clients have been updated to reflect the proliferation of new TLDs.

Our attempts to register$TLD for a variety of TLDs were not (yet) successful.


We spent some time looking for bugs in jscript.dll and employed both manual analysis and fuzzing. JScript initially posed some challenge because a lot of “features” useful for triggering bugs in JavaScript engines can’t be used in JScript, simply due to it being too old to support them. For example:

  • There are no multiple arrays types (int array, float array etc.). Thus confusing one array type for another is not possible.
  • There are not as many optimizations (“fast paths”) as in the newer, faster JavaScript engines. These fast paths are often the source of bugs.
  • It is not possible to define a getter/setter on a generic JavaScript object. It is possible to call defineProperty but only on DOM objects which doesn’t work for us as there won’t be a DOM in the WPAD process. Even if there were, a lot of JScript functions will simply fail when called on a DOM object with a message “JScript object expected”.
  • It is impossible to change an object’s prototype once it is created (i.e. there is no “__proto__” property).

However, JScript does suffer from more “old-school” vulnerability classes such as use-after-free. JScript’s garbage collector is described in this old MSDN article. JScript uses a non-generational mark-and-sweep garbage collector. Essentially, whenever a garbage collection is triggered, it marks all the JScript objects. Then it scans them starting from a set of “root” objects (sometimes also referred to as “scavengers”) and clears the mark from all the objects it encounters. All the objects that are still marked get deleted. One recurring problem is that local variables on the stack aren’t added to the list of root objects by default, meaning that a programmer needs to remember to add them to the garbage collector’s root list, especially if those variables refer to objects that can be deleted during the function’s lifetime.

Other possible types of vulnerabilities include buffer overflows, uninitialized variables etc.

For fuzzing, we used the grammar-based Domato fuzzing engine and wrote a new grammar specifically for JScript. We identified interesting built-in properties and functions to add to the grammar by looking at EnsureBuiltin methods of various JScript objects. The JScript grammar has been added to the Domato repository here.

Between fuzzing and manual analysis we identified seven security vulnerabilities. They are summarized in the table below:

Vulnerability class
Vulnerabilities affecting IE8 mode
Vulnerabilities affecting IE7 mode
Heap overflow
Uninitialized variable
Out-of-bounds read

At the time of publishing this blog post, all the bugs have been fixed by Microsoft.

The table breaks down the vulnerabilities by class and compatibility mode required to trigger them. JScript in WPAD is equivalent to running a script in IE7 compatibility mode, which means that, although we found 7 vulnerabilities, “only” 5 of them can be triggered in WPAD. However, the other vulnerabilities can still be used against Internet Explorer (including IE11) when put into IE8 compatibility mode by a malicious webpage.


Understanding JScript VARs and Strings

Since in the remainder of this blogpost we’re going to talk about JScript VARs and Strings a lot, it is useful to describe these before going deeper into how the exploits work.

JScript VAR is a 24-byte (on 64-bit builds) structure that represents a JavaScript variable and is essentially the same as the VARIANT data structure described in this MSDN article. In most cases (sufficient to follow the exploit) its memory layout looks like this:

Variable type, 3 for integer, 5 for double, 8 for string etc.
Depending on the type, either an immediate value or a pointer
Unused for most types

For example, we can represent a double precision number by a VAR that has 5 written in the first 2 bytes (indicating the double type), followed by an actual double value at offset 8. The last 8 bytes are going to be unused but they are going to be copied around if a value of another VAR is copied from this VAR.

A JScript string is a type of VAR that has the type 8 and a pointer at offset 8. The pointer points into a BSTR structure described here. On 64-bit builds BSTR layout looks like this:

String length in bytes not counting the null character at the end
String characters (16-bit) followed by a null character

A String VAR points directly to the character array, which means that, to obtain a String's length, the pointer needs to be decremented by 4 and the length read from there. Note that BSTRs are handled by OleAut32.dll and are allocated on a separate heap (i.e. a different heap than is being used for other JScript objects).

Freeing of BSTRs is also different than for most objects because, instead of directly freeing a BSTR, when SysFreeString is called, it first puts a string in a cache controlled by OleAut32.dll. This mechanism is described in detail in Heap Feng Shui in JavaScript.

Stage 1: Infoleak

The purpose of the infoleak will be to obtain the address of a string in memory whose content we fully control. We won’t be leaking any executable module addresses at this point, that will come later. Instead, the goal is to defeat high-entropy heap randomization and make the second stage of the exploit reliable without having to use heap spraying.

For the infoleak we’re going to use this bug in RegExp.lastParen. To understand the bug let’s first take a closer look at the memory layout of jscript!RegExpFncObj which corresponds to the JScript RegExp object. At offset 0xAC RegExpFncObj contains a buffer of 20 integers. Actually these are 10 pairs of integers: the first element of the pair is the start index into the input string and the second element is the end index. Whenever RegExp.test, RegExp.exec or with a RegExp parameter encounter a capturing group (parentheses in the RegExp syntax), the start and end index of the match are stored here. Obviously in the buffer there is space for only 10 matches, so only the first 10 matches are stored in this buffer.

However, if RegExp.lastParen is called and there were more than 10 capturing groups, RegExpFncObj::LastParen will happily use the number of capturing groups as an index into the buffer, leading to out-of-bounds read. Here is a PoC:

 var r= new RegExp(Array(100).join('()'));

The 2 indices (let’s call them start_index and end_index) are read outside the bounds of the buffer and can thus be made arbitrarily large. Assuming this first out-of-bounds access doesn’t cause a crash, if the values in those indices are larger than the length of the input string, then a second out-of-bounds access is going to occur which allows us to read a outside the bounds of the input string. The string content read out-of-bounds like this is going to be returned to the caller in a String variable where it can be examined.

This second out-of-bounds read is what we’re going to use, but first we need to figure out how to get controlled data into start_index and end_index. Fortunately, looking at the layout of RegExpFncObj, there is data we control after the end of the index buffer: RegExp.input value. By setting RegExp.input to an integer value and using a RegExp composed of 41 sets of empty parentheses, when  RegExp.lastParen gets called, start_index is going to be 0 and the end_index is going to be whatever value we wrote to RegExp.input.

If we make an input string adjacent to a freed string, then by reading after the bounds of input string, we can obtain the heap metadata such as the pointers to the other free heap segments (Left, Right and Parent node in the red-black tree of heap chunks, see Windows 10 Segment Heap Internals for more information). Image 1 shows the relevant objects at the moment of infoleak.

Image 1: Heap infoleak layout

We are using 20000 bytes-long strings as input in order for them not to be allocated on the Low Fragmentation Heap (LFH can only be used for allocations of 16K bytes and smaller) since the heap metadata for the LFH is different and does not include useful pointers in Windows 10 Segment Heap. Additionally, LFH introduces randomness that would affect our ability to place the input string next to a freed string.

By reading the heap metadata out of the returned string, we can obtain an address of a freed string. Then, if we allocate a string of the same size as the freed string, it might be placed at this address and we achieved our goal, that is we know the address of memory of a string whose content we control.

The whole infoleak process looks like this:

  1. Allocate 1000 10000-character strings (note: 10000 characters == 20000 bytes).
  2. Free every second one.
  3. Trigger the info leak bug. Use one of the remaining strings as an input strings and read 20080 bytes.
  4. Analyze the leaked string and obtain the pointer to one of the freed strings.
  5. Allocate 500 strings of the same length as the freed strings (10000 characters) with a specially crafted content.

The content of the specially crafted strings is not important at this stage, but will be important in the next one, so it will be described there. Also note that, by examining heap metadata, we can easily determine which heap implementation the process is using (Segment Heap vs NT heap).

Images 2 and 3 show heap visualization created using Heap History Viewer at the time around the infoleak. Green stripes represent allocated blocks (occupied by strings), grey stripes represent allocated blocks that are then freed by later allocated again (the stings we free and then reallocate after triggering the infoleak bug) and the white stripes represent data that is never allocated (guard pages). You can see how strings get allocated as the time passes, then half of them are freed (grey ones) and sometime later get allocated again (the stripes become green).

We can see that there are going to be guard pages after every 3 allocations of this size. Our exploit is never actually going to touch any of these guard pages (it reads too little data past the end of the string for that to occur) but in ⅓ of the cases there won’t be a free string after the input string for the infoleak so the expected heap metadata will be missing. We can, however, easily detect this case and either trigger the infoleak bug using another input string or silently abort the exploit (note: we didn’t trigger any memory corruption up to this point).

Image 2: Heap Diagram: Showing the evolution of the heap over time
Image 3: Step-by-step illustration of leaking a pointer to a string.

Stage 2: Overflow

In stage 2 of the exploit we’re going to use this heap overflow bug in Array.sort. In case the number of elements in the input array to Array.sort is larger than Array.length / 2, JsArrayStringHeapSort (called by Array.sort if a comparison function isn’t specified) is going to allocate a temporary buffer of the same size as the number of elements currently in the array (note: can be smaller than array.lenght). It is then going to attempt to retrieve the corresponding elements for every array index from 0 to Array.length and, if that element exists, add it to the buffer and convert to string. If the array doesn’t change during the lifetime of JsArrayStringHeapSort, this will work fine. However, JsArrayStringHeapSort converts array elements into strings which can trigger toString() callbacks. If during one of those toString() callbacks elements are added to the array where they were previously undefined, an overflow is going to occur.

To understand the bug and its exploitability better let’s take a closer look at the structure of the buffer we’ll overflow out of. It is already mentioned that the array will have the same size as the number of elements currently in input array (to be exact, it is going to be number of elements + 1). Each element of the array is going to be 48 bytes in size (in a 64-bit build) with the following structure:

Pointer to a string VAR after the original VAR at offset 16 is converted to string
Index (int) of the current element
VAR holding the original array element
int 0 or 1 depending on the type of VAR at offset 16

During JsArrayStringHeapSort, each element of the array with index < array.length is retrieved, and if the element is defined the following happens:

  1. The array element is read into VAR at offset 16
  2. The original VAR is converted into a string VAR. A pointer to the string VAR is written at offset 0.
  3. At offset 8, the index of the current element in array is written
  4. Depending on the original VAR type, 0 or 1 is written at offset 40

Looking at the structure of the temporary buffer, we don’t control a lot of it directly. If an array member is a string, then at offsets 0 and 24 we’re going to have a pointer that, when dereferenced, at offset 8 contains another pointer to the data we control. This is, however, one level of indirection larger than what would be useful to us in most situations.

However, if a member of array is a double precision number, then at offset 24 (corresponding to offset 8 into the original VAR) the value of that number is going to be written and it is directly under our control. If we create a number with the same double representation as the pointer obtained in Stage 1, then we can use our overflow to overwrite a pointer somewhere after the end of the buffer with a pointer to the memory we directly control.

Now the question becomes, what can we overwrite in this way to advance the exploit. One of the possible answers presents itself if we take a closer look at how Objects work in JScript.

Each Object (more specifically, a NameList JScript object) is going to have a pointer to a hashtable. This hashtable is just an array of pointers. When a member element of an Object is accessed, a hash of the name of the element is computed. Then, a pointer at the offset corresponding to the lowest bits of the hash is dereferenced. This pointer points to a linked list of object elements and this linked list is traversed until we reached an element with the same name as the requested element. This is shown in image 4.

Image 4: JScript Object element internals

Note that, when the name of the element is less than 4 bytes, it is stored in the same structure as the VAR (element value). Otherwise, there is going to be a pointer to the element name. Name lengths <=4 are sufficient for us so we don’t need to go into the details of this.

An Object hashtable is a good candidate to overwrite because:

  • We can control which elements of it are dereferenced by accessing the corresponding object members. Elements we overwrite with data we don’t control will simply never be accessed.
  • We have limited control over the hashtable size by controlling how many members the corresponding object has. For example a hashtable starts with 1024 bytes, but if we add more than 512 elements to the object, the hashtable will be reallocated to 8192 bytes.
  • By overwriting a hashtable pointer with a pointer to data we control, we can create fake JScript vars in the data we control and access them simply by accessing the corresponding object members.

To perform the overwrite reliably we do the following:

  1. Allocate and free a lot of memory blocks with size 8192. This will turn on the Low Fragmentation Heap for allocation of size 8192. This will ensure that the buffer we are overflowing out of, as well as hashtable we are overflowing into will be allocated on the LFH. This is important because it means there will be no other allocations of other sizes nearby to spoil the exploit attempt (since an LFH bucket can only contain allocations of a certain size). This in turn ensures that we will be overwriting exactly what we want with high reliability.
  2. Create 2000 objects, each containing 512 members. In this state, each object has a hashtable of 1024 bytes. However, adding just one more element to one of these objects will cause its hashtable to grow to 8192 bytes.
  3. Add the 513 element to the first 1000 objects, causing 1000 allocations of 8192-byte hashtables.
  4. Trigger Array.sort with an array with length=300 and 170 elements. This allocates a buffer of size (170+1)*48=8208 bytes. Due to LFH granularity this object will be allocated in the same LFH bucket as 8192-byte hashtables.
  5. Immediately (in the toString() method of the first array element) add 513th element to the second 1000 objects. This makes us pretty certain that by now the sort buffer is neighboring one of the hashtables. In the same toString() method also add more elements to the array which will cause it to grow out-of-bounds.

Image 5 shows heap visualization around the address of the sort buffer (red line). You can see the sort buffer is surrounded by allocations of similar size which all correspond to Object hashtables. You can also observe the LFH randomness in the sense that subsequent allocations are not necessarily on subsequent addresses, however this makes no difference for our exploit.

Image 5: Heap visualization around the overflow buffer

As mentioned previously, we crafted our overflow in such a way that some of the hashtable pointers of an unlucky JScript object will get overwritten with pointers into the data we control. Now finally what exactly we put into this data comes into play: we crafted it in such a way that it contains 5 (fake) JavaScript variables:

  • Variable 1 just contains number 1337.
  • Variable 2 is of special type 0x400C. This type basically tells JavaScript that the actual VAR is pointed to by pointer at offset 8, and this pointer should be dereferenced before reading or writing this variable. In our case, this pointer points 16 bytes before Variable 1. This basically means that the last 8-byte qword of Variable 2 and the first 8-byte qword of Variable 1 overlap.
  • Variable 3, Variable 4 and Variable 5 are simple integers. What is special about them is that they contain numbers 5, 8 and 0x400C in their last 8 bytes, respectively.

The state of the corrupted Object after the overflow is shown in image 6.

Image 6: State of objects after the overflow. Red areas indicate where the overflow occurred. Each box in the bottom row (except those marked as ‘...’) corresponds to 8 bytes. Data contained in ‘...’ boxes is omitted for clarity

We can access Variable 1 by simply accessing the corrupted object at the correct index (let’s call it index1) and similarly for Variables 2-5. In fact, we can detect which Object we corrupted by accessing index1 of all objects and seeing which now has the value 1337.

Overlapping Variable 1 and Variable 2 has the effect that we can change the type (first WORD) of Variable 1 into 5 (double), 8 (string) or 0x400C (pointer). We do this by reading Variable 2, 3 or 4 and then writing the read value into Variable 2. For example the statement

corruptedobject[index2] = corruptedobject[index4];

Has the effect that the type of Variable 1 will be changed into a String (8), while all other fields of Variable 1 will remain unchanged.

This layout gives us several very powerful exploitation primitives:

  • If we write some variable that contains a pointer into Variable 1, we can disclose the value of this pointer by changing the type of Variable 1 to double (5) and reading it out
  • We can disclose (read) memory at an arbitrary address by faking a String at that address. We can accomplish this by first writing a double value corresponding to the address we want to read into Variable 1 and then changing the type of Variable 1 toString (8).
  • We can write to an arbitrary address by first writing a numeric value corresponding to the address into Variable 1, then changing the type of Variable 1 to 0x400C (pointer) and finally writing some data to Variable 1.

With these exploit primitives, normally getting the code execution would be pretty simple, but since we’re exploiting Windows 10 we first need to bypass the Control Flow Guard (CFG).

Stage 3: CFG bypass

There are probably other known bypasses we could have used here, but it turns out that there are some very convenient bypasses (once attacker has a read/write primitive) specific to jscript.dll. We are going to exploit the facts that:

  • Return addresses are not protected by CFG
  • Some Jscript objects have pointers to the native stack

Specifically, each NameTbl object (in Jscript, all JavaScript objects inherit from NameTbl), at offset 24 holds a pointer to CSession object. CSession object, at offset 80 holds a pointer to near the top of the native stack.

Thus, with an arbitrary read, by following a chain of pointers from any JScript object, it is possible to retrieve a pointer to the native stack. Then, with an arbitrary write, it is possible to overwrite a return address, bypassing CFG.

Stage 4: Getting code execution as Local Service

With all the exploit elements in place, we can now proceed to getting the code execution. We are doing it in these steps:

  1. Read the address of jscript.dll from a vtable of any JScript object
  2. Read the address of kernel32.dll by reading the import table of jscript.dll
  3. Read the address of kernelbase.dll by reading the import table of kernel32.dll
  4. Scan kernel32.dll for rop gadgets we are going to need
  5. Get the address of WinExec from the export table of kernel32.dll
  6. Leak the stack address as explained in the previous section
  7. Prepare the ROP chain and write it to the stack, starting with a return address closest to our leaked stack address.

The ROP chain we are using looks like this:

[address of RET]  //needed to align the stack to 16 bytes
[address of POP RCX; RET] //loads the first parameter into rcx
[address of command to execute]
[address of POP RDX; RET] //loads the second parameter into rdx
[address of WinExec]

By executing this ROP chain we are calling WinExec with a command we specified. For example, if we run the command ‘cmd’ we are going to see a command prompt being spawned, running as Local Service (the same user WPAD service runs as).

Unfortunately, from a child process running as Local Service, we can’t talk to the network, but what we can do is drop our privilege escalation payload from memory to a disk location Local Service can write and execute it from there.

Stage 5: Privilege escalation

While the Local Service account is a service account, it doesn’t have administrative privileges. This means the exploit is quite limited in what it can access and modify on the system, especially to persist after exploitation or after the system has been rebooted. While there’s always likely to be an unfixed privilege escalation in Windows we don’t need to find a new vulnerability to escalate our privileges. Instead we can abuse a built-in feature to escalate from Local Service to the SYSTEM account. Let’s look at the privileges that the service account for WPAD has been granted:

Image 7: Service Access Token’s Privileges showing Impersonate Privilege

We’ve only got three privileges, but the highlighted privilege, SeImpersonatePrivilege is important. This privilege allows the service to impersonate other users on the local system. The reason the service has impersonate privilege is it accepts requests from all users on the local system and might need to perform actions on their behalf. However, as long as we can get an access token for the account we want to impersonate we can get the full access rights of the token’s user account, including SYSTEM which would give us administrator rights on the local system.

Abusing impersonation is a known issue with the Windows security model (you can find more details by searching for Token Kidnapping). Microsoft have tried to make it harder to get an access token for a privileged user but it’s virtually impossible to close all possible routes. For example, James discovered a vulnerability in Windows’ implementation of DCOM which allows any user to get access to a SYSTEM access token. While Microsoft fixed the direct privilege escalation vulnerability they didn’t, or perhaps couldn’t, fix the token kidnapping issue. We can abuse this feature to capture the SYSTEM token, impersonate the token, then completely compromise the system, such as installing a privileged service.

There’s an existing implementation of the token kidnapping via DCOM (RottenPotato) however the implementation was designed for use with the Metasploit framework’s getsystem command which we’re not using. Therefore, we implemented our own simpler version in C++ which directly spawns an arbitrary process with a SYSTEM token using the CreateProcessWithToken API. As a bonus we were able to compile it to an executable of 11KiB in size, much smaller than RottenPotato, which made it easier to drop to disk and run from the ROP payload.

Tying it all together

When the WPAD service queries for the PAC file, we serve the exploit file which exploits the WPAD service and runs WinExec to drop and execute the privilege escalation binary. This binary then executes a command (hardcoded ‘cmd’ in our case) as SYSTEM.

The exploit worked pretty reliably in our experiments, but it is interesting to note that a 100% reliable exploit isn’t required - if the exploit crashes the WPAD service, a new instance is going to get spawned when a client makes another request from WPAD service, so an attacker can just try again. There will be no indication in the UI that the WPAD service has crashed, although Window Error Reporting will likely pick up the crash and report it to Microsoft, provided that the user didn’t disable it.

In fact, our exploit doesn’t clean up gracefully and will crash the WPAD service once it runs its payload, so if we keep serving the exploit PAC file after the service has been exploited, it will just get exploited again. You can see the effect of that in Image 7, which was taken after leaving the exploit server running for some minutes and making a lot of HTTP requests in the victim machine.

Image 7: Did we leave the exploit running for too long?

We’ll publish the exploit source code in the issue tracker shortly.


Executing untrusted JavaScript code is dangerous, and executing it in an unsandboxed process is even more so. This is true even if it’s done by a relatively compact JavaScript engine such as jscript.dll. We identified 7 security vulnerabilities in it and successfully demonstrated reliable code execution from local network (and beyond) against a fully patched (at the time of writing) Windows 10 64-bit with Fall Creators Update installed.

Since the bugs are now fixed, does this mean we are done and can go home? Unlikely. Although we spent a fair amount of time, effort and compute power on finding jscript.dll bugs, we make no claims that we found all of them. In fact, where there are 7 bugs, there is likely to be an 8th. So if something doesn’t change it is quite possible we’ll see a chain like this used in the wild someday (and that is, of course, optimistically assuming that attackers don’t have this capability already).

So, what can Microsoft do to make future attacks like this harder:

  • Disable WPAD by default. In fact, while the other operating systems support WPAD, Windows is the only one where it is enabled by default.
  • Sandbox the JScript interpreter inside the WPAD service. Since the interpreter needs to execute a JavaScript function with well defined inputs and return the output string, sandboxing it should be pretty straightforward. Given the simplicity of the input-output model, it would be great if Microsoft introduced a sandbox of comparable restrictiveness to seccomp-strict: Some processes really do not need more privileges than “receive a bit of data”, “perform a bit of computation”, “return a bit of data”.

In case you want to take action on your own, the only way to prevent this type of attack using new, currently unknown vulnerabilities, seems to be to completely disable the WinHttpAutoProxySvc service. Sometimes this can’t be done in the Services UI (“Startup type” control will be grayed out) due to other services depending on WPAD, but it can be done via the corresponding registry entry. Under “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WinHttpAutoProxySvc” change the value of “Start” from 3 (manual) to 4 (disabled).

These are some of the advices commonly found online when searching for “disabling WPAD” that did not work to prevent the attack in our experiments:

  • Turning off “Automatically detect settings” in Control Panel
  • Setting “WpadOverride” registry key
  • Putting “ wpad” in the hosts file (this is going to stop the DNS variant but likely not the DHCP variant)

Check the Soundstage – Startup Security Weekly #66

In our article discussion, we discuss managing risk, defining moments for your customers, ditching PowerPoint for better apps, and planning communications to avoid pitfalls! In the news, we have updates from Simility, Upstream, ShieldX, Atos, Menlo Security, and more on this episode of Startup Security Weekly!

Full Show Notes:

Visit for all the latest episodes!

Spread Your Vegemite – Paul’s Security Weekly #540

Joe Gray of the Advanced Persistent Security podcast joins us for an interview! Ed Skoudis of the SANS Institute joins us to discuss the SANS Holiday Hack Challenge and what he’s been up to in the cyber world! In the news, the team discusses on-demand webcasts, net neutrality, pen testing, and Vegemite with Joff!

Full Show Notes:

Visit for all the latest episodes!


FTC Hosts Workshop on Informational Injury

On December 12, 2017, the Federal Trade Commission hosted a workshop on informational injury in Washington, D.C., where industry experts, policymakers, researchers and legal professionals considered how to best characterize and measure potential injuries and resulting harms to consumers when information about them is misused or inappropriately protected.

Acting FTC Chairwoman Maureen Ohlhausen delivered opening remarks at the commencement of the day-long workshop and noted the key goals of the meeting were to (1) better identify different types of privacy injury, (2) explore frameworks for quantitatively measuring and estimating the risk of harm, and (3) better understand how consumers and businesses weigh the risks of increased exposure to privacy injuries against the benefits of personal information use. Another stated goal was to determine when FTC intervention may be warranted.

The four panel workshop began with a discussion of types of informational injuries that can and do occur in the marketplace, followed by a discussion of potential factors to consider in assessing consumer injury. Later in the afternoon, the discussion turned to business and consumer perspectives on the benefits, costs and risks of collecting and sharing data. The workshop concluded with a panel on different methods for and challenges in measuring injury.

  • Injuries 101: The first panel discussed negative outcomes that arise from unauthorized access to and misuse of consumers’ personal data. The discussion included an examination of the broad range of injuries that can occur. This was not limited to common informational injuries, such as financial harms resulting from identity theft, but also included lesser known harms such as medical and biometric identity theft, doxing (which is the public release of documents people wish to keep private), stalker ware apps, algorithmic decision making, discrimination based on knowledge of sensitive data points, predictive policing and the personalization of services.

Panelists called on the FTC to take a number of measures to further study these informational risks and injuries, including studying different types of identity theft distinctly and not limiting this to one general topic, and writing reports on substantive harms that have meaningful impacts on people’s lives and the potential solutions.

More generally, panelists called for efforts to understand harms to come up with the appropriate measures and to take a multifactorial approach, considering different expertise and different victims and stakeholders. Such measures should include the creation of a clear set of societal norms for tech platforms and the development of ethical frameworks to guide information use.

  • Potential Factors in Assessing Injury: The second panel discussed potential factors in assessing consumer injury, including types of injury, magnitude and the sensitivity of consumer data. Consideration was given to whether the same factors apply in both the privacy and security contexts, the risk of potential injury versus realized injury and when government intervention is warranted.

Panelists were presented with two consumer harm and injury hypotheticals (one in a privacy context, based on retail tracking and marketing, and one in a security context, based on unauthorized access to company consumer data) and asked to assess at which stage of the hypothetical they believed consumer injury was taking place. Responses varied with some noting that, in the retail tracking hypothetical, until actual harm is realized, no consumer injury has taken place, while others stated that retail tracking to determine aggregate consumer interest in a product could be enough to cause injury. Panelists were then asked at which stage of the hypotheticals they believed government intervention should occur. Some panelists stated it should occur if the information is sensitive, while others noted over-enforcement can be a deterrent to new technologies.

With respect to the data security hypothetical, panelists were asked the same question of which stage they believed injury occurred. Responses varied again, largely on similar logic, with some noting that unless actual harm is realized through the use of breached data, no injury occurs, and others taking the line that unauthorized access to consumer data alone is enough to constitute injury.

With respect to enforcement, one panelist noted that the FTC can look at these issues in a broader way than the court system. For instance, it can look at social harms in ways that courts cannot. Further, the unfairness doctrine under Section 5 of the FTC Act was mentioned as having the potential to facilitate the FTC in exploring how to assess risk and harm.

Panelists also discussed the role of consumer expectations in determining (1) whether there was injury; (2) whether there should be a distinction between the collection of information and use of information (whereby use, but not collection, may result in injury); (3) risks associated with the use or failure to use sensitive data; (4) the role of considering countervailing benefits in assessing net injury; (5) whether quantifiability of harm is an effective or sufficient criterion for cognizable injury in the privacy context; and (6) the role of the market in mediating the issue of acceptable privacy risks.

  • Business and Consumer Perspectives: The third panel examined how businesses and consumers perceive and evaluate the benefits, costs and risks of data collection and sharing in light of potential benefits and injuries. The panel also discussed considerations businesses take into account when choosing privacy and data security practices, and consumer decision making regarding sharing their information.

With respect to the business perspective, one panelist noted that when businesses try to assess risk they start by looking at the benefits, and most businesses go through privacy impact assessments to mitigate risks to an acceptable level in light of benefits. Another panelist took the view that businesses overestimate the benefits of data uses and are not internalizing the risks. A third panelist noted that business perspectives vary from sector to sector.

With respect to the consumer perspective, panelists noted that consumers view data as one aspect of the transaction and are willing to pay with information rather than money. They may not, however, be aware of what disclosing their information means and consumer education efforts to date have largely been ineffective. One panelist noted that default options are extremely important because people usually do not make choices if they do not fully understand them. Too many choices, however, can lead to complexity and can overburden consumers.

The session concluded with one panelist recommending that the FTC pursue other methods than the traditional approaches of transparency, notice, choice and consent, noting that these have been tried in the past and do not work. The data economy is too complex and a constantly moving target. In addition, it has to be considered that other areas of law and regulation (e.g., environment, nutrition, conflict resolution and arbitration, etc.) make similar demands on consumer attention through transparency, thereby adding to the burden on consumers. Panelists also suggested looking at what people do rather than what they say about privacy. One panelist stated that watching the big industry players and understanding their responsible data practices is an effective path forward. It was also suggested that consumers have only so much time to make choices and that responsible and ethical information use by companies is the way forward in protecting consumers.

  • Measuring Injury: The final panel examined methods for and challenges in assessing informational injuries. Discussion points included how to quantify injury and the risk of injury, as well as how consumer choice and stated preferences can be accounted for.

Panelists noted that most work in measuring injury has been conducted through surveys. A key issue raised in this regard is the privacy paradox. In a survey, most people will state they care about privacy but do not act accordingly. Actual, rather than reported, preferences may be more insightful, but one panelist cautioned that this issue is complex and that one cannot generalize that “revealed action” is a better indicator than “stated preferences.” There may be other explanations for why people act the way they do other than for privacy-related reasons. Building on this point, one panelist noted the cyber insurance market shows what customers are willing to pay for privacy, but acknowledged the limitations and rarity of personal cyber insurance coverage.

Panelists agreed that further research is needed to get an understanding on baseline risk and that to measure causal links, we need to have a better understanding of what causes injury to happen. One panelist called for more research on what prevents harm from happening. For the FTC and other government agencies going forward, panelists asked for thought to be given to new risks hitting consumers more directly, such as ransomware, and to consider appropriate remedies, taking into account the costs to the consumer. Another suggestion was to identify occasions of injury where there is no effect on individuals.

Andrew Stivers, Deputy Director for Consumer Protection in the Bureau of Economics of the FTC, delivered closing remarks and emphasized the importance to the FTC of continued work on informational injury.

The FTC will accept public comments on the workshop until January 26, 2018. Details regarding submissions can be found in the detailed public notice about the workshop.

Article 29 Working Party Publishes Guidance on Consent Under the GDPR

Recently, the EU’s Article 29 Working Party (the “Working Party”) adopted guidelines (the “Guidance”) on the meaning of consent under the EU General Data Protection Regulation (“GDPR”). In this Guidance, the Working Party has confirmed that consent should be a reversible decision where a degree of control must remain with the data subject. The Guidance provides further detail on what is necessary to ensure that consent satisfies the requirements of the GDPR:

  • Freely given. Consent is not valid where there is an imbalance of power or where it is conditioned to the performance of a contract. In addition, consent must be granular and given separately for each data processing operation, and there should be no detriment to the data subject if the data subject elects to withdraw his or her consent.
  • Specific. Consent must be given for the processing of personal data for a specific purpose.
  • Informed. To be fully informed, the following information must be provided to the data subject before consent is given: (1) the identity of the data controller; (2) the purpose of each of the processing operations for which consent is sought, (3) the personal data that will be collected based on consent; (4) the existence of the right to withdraw consent; (5) information about the use of the personal data for decisions based solely on automated processing, including profiling; and (6) if the consent relates to transfers of personal data outside the EEA, information about the possible risks of personal data transfers to third-party countries in the absence of an adequacy decision and appropriate safeguards.
  • Clear affirmative action. Consent must be an unambiguous indication of the data subject’s wishes and accordingly, must be given by a statement or by a clear affirmative action which signifies agreement to the processing of personal data relating to the data subject.

Meaning of Explicit Consent

The Guidance also provides further information on the meaning of “explicit” consent, which is obtained for the processing of special categories of data, the transfer of personal data outside the EEA, or for automated individual decision-making. The Guidance states that for consent to be “explicit,” the data subject must give an express statement of his or her consent, for example, by expressly confirming his or her consent in an explicit statement. In the electronic context, an express statement of consent could be given by the data subject by filling in an electronic form, sending an email, uploading a scanned document or using an electronic signature.

Demonstrating Consent

The Working Party indicates that data controllers are free to develop methods to demonstrate that consent has been validly obtained in a way that is fitting with their daily operations, and the GDPR is not prescriptive in this regard. Nevertheless, to demonstrate that consent was validly given, the data controller must be able to prove, in each individual case, that a data subject has given consent. In addition, the Guidance indicates that data controllers should retain records of consent only for so long as necessary for compliance with legal obligations to which it is subject, or for the establishment, exercise or defense of legal claims. The information retained should not go beyond what is necessary to demonstrate that valid consent has been obtained.

Children’s Consent

The GDPR requires parental consent in relation to the processing of children’s personal data in the context of information society services (e.g., a website or video streaming service) offered directly to children. The GDPR does not, however, specify the means that should be used to verify whether a user is a child or to obtain the consent of the child’s parents. The Guidance suggests that data controllers should adopt a proportionate approach based on the inherent risk associated with the processing and the available technology solutions. For example, the Working Party suggests that in low-risk scenarios, verification of parental responsibility by email may be sufficient, but in higher risk scenarios, more rigorous methods may be used, such as requiring the parent to make a £/$/€ 0.01 payment to the controller via a bank transaction. The Working Party recognizes, however, that verification may be challenging in a number of circumstances, and this will be taken into account when deciding whether the controller has taken “reasonable” efforts to ensure that parental consent has been obtained.

Pre-existing Consent

The Guidance indicates that consent which has been obtained prior to the GDPR will continue to be valid under the GDPR, provided it meets the conditions for consent required by the GDPR. The Working Party notes, in this regard, that existing consents must meet all GDPR requirements if they are to be valid, including the requirement that the data controller is able to demonstrate that consent was validly obtained. Thus, the Working Party is of the view that any consents which are presumed to be valid, but of which no record is kept, will not be valid under the GDPR. Similarly, existing consents that do not meet the “clear affirmative action” requirement under the GDPR, for example, because they were obtained by means of a pre-checked box, also will not be valid under the GDPR.

For processing operations in relation to which existing consent will no longer be valid, the Working Party recommends that data controllers (1) seek to obtain new consent in a way that complies with the GDPR, or (2) rely on a different legal basis for carrying out the processing in question. If a data controller is unable to do either of those things then the processing activities concerned should cease.

Lisa Sotto Honored as an “Outstanding Woman in the Legal Profession”

On December 11, 2017, Lisa Sotto, chair of Hunton & Williams LLP’s Global Privacy and Cybersecurity practice, was one of 54 women in the legal profession honored at the New York County Lawyers Association’s (“NYCLA’s) 103rd annual dinner. “NYCLA has long been at the forefront of equality…At this year’s annual dinner, we are thrilled to honor the contributions of women lawyers and focus a spotlight on their accomplishments,” said NYCLA President Michael McNamara. Among the women honored were judges, prosecutors, district attorneys, general counsel, partners and executives.

Lessons learned from a Man-in-the-Middle attack

It’s become a widely accepted mantra that experiencing a cyber breach is a question of ‘when’ and not ‘if’. For Fox-IT ‘if’ became ‘when’ on Tuesday, September 19 2017, when we fell victim to a “Man-in-the-Middle” attack. As a result of the multi-layered security protection, detection and response mechanisms we had in place, the incident was both small and contained, but as a cyber security specialist it has made us look long and hard at ourselves. While the police investigation is still on-going, we are sharing details of this incident with the public now that we feel confident that most details are sufficiently clear. This is about who we are and what we do. We believe that ultimately in these cases, transparency builds more trust than secrecy and there are lessons to be learned, both good and bad, that we want to share.

So what happened?

In the early morning of September 19 2017, an attacker accessed the DNS records for the domain at our third party domain registrar. The attacker initially modified a DNS record for one particular server to point to a server in their possession and to intercept and forward the traffic to the original server that belongs to Fox-IT. This type of attack is called a Man-in-the-Middle (MitM) attack. The attack was specifically aimed at ClientPortal, Fox-IT’s document exchange web application, which we use for secure exchange of files with customers, suppliers and other organizations. We believe that the attacker’s goal was to carry out a sustained MitM attack.

Because we detected and addressed the breach quickly we limited the total effective MitM time to 10 hours and 24 minutes. In the scheme of the industry average time of detection of weeks this was a short exposure, but we couldn’t prevent the attacker from intercepting a small number of files and information that they should not have had access to. An important first step in our response was to contact Law Enforcement and share the necessary information with them to enable them to start a criminal investigation.

The incident unfolded as follows (all times are CEST):

Sept 16 2017 First reconnaissance activities against our infrastructure that we believe are attributable to the attacker. These included regular port scans, vulnerability scans and other scanning activities.
Sept 19 2017, 00:38 The attacker changed DNS records for domain at a third party provider.
Sept 19 2017, 02:02 Latest moment in time that we have been able to determine that still pointed to our legitimate ClientPortal server. This means that traffic destined for the ClientPortal was not being intercepted yet.
Sept 19 2017, 02:05-02:15 Maximum 10-minute time window during which the attacker temporarily rerouted and intercepted Fox-IT email for the specific purpose of proving that they owned our domain in the process of fraudulently registering an SSL certificate for our ClientPortal.
Sept 19 2017, 02:21 The actual MitM against our ClientPortal starts. At this point, the fraudulent SSL certificate for ClientPortal was in place and the IP DNS record for was changed to point to a VPS provider abroad.
Sept 19 2017, 07:25 We determined that our name servers for the domain had been redirected and that this change was not authorized. We changed the DNS settings back to our own name servers and changed the password to the account at our domain registrar. This change will have taken time to have full effect, due to caching and the distributed nature of the domain name system.
Sept 19 2017, 12:45 We disabled the second factor authentication for our ClientPortal login authentication system (text messages), effectively preventing users of ClientPortal from successfully logging in and having their traffic intercepted. Other than that, we kept ClientPortal functional in order not to disclose to the attacker that we knew what they were doing, and to give ourselves more time to investigate. At this point, the MitM against ClientPortal was still active technically, but would no longer receive traffic to intercept as users would not be able to perform two factor authentication and log in.
Sept 19 – Sept 20 2017 A full investigation into the incident was undertaken, along with notification of all clients that had files intercepted and the relevant authorities, including the Dutch Data Protection Authority. A police investigation was launched and is still ongoing. Based on the outcome of our investigation, we understood the scope of the incident, we knew that the attack was fully countered and we were prepared to re-enable two factor authentication on ClientPortal in order to make it fully functional again.
Sept 20, 15:38 ClientPortal fully functional again. Our internal investigation into the incident continued.

What kind of information did the attacker intercept?

As mentioned, the attacker was able to redirect inbound traffic to ClientPortal and emails going to the domain for a short period of time. At no stage did they have access to any external or internal Fox-IT system, or indeed system level access to our ClientPortal.

When investigating the attack, we made heavy use of our own technology. For all Fox-IT traffic, we employ CTMp network sensors to detect anomalies and alert us of attacks. All our sensors do full packet capture and this is what allowed us to determine precisely, beyond any doubt, which information was intercepted by the attacker, the timeline of the event and who was affected by the attack.

Because of this we know the following about the information that the attacker was able to intercept:

  • We know the following facts about the information that the attacker intercepted:
    1. Nine individual users logged in and their credentials were intercepted and all users were contacted immediately. Because we use two factor authentication, these credentials alone were not enough for the attacker to log in to ClientPortal.
    2. Twelve files (of which ten were unique) were transferred and intercepted.
      • Of these, three files were client confidential in nature, none were classified as state secret. Files classified as state secret are never transferred through our ClientPortal.
      • Other files were in the public domain and not confidential.
      • All affected clients in respect of these files were contacted immediately.
    3. One mobile phone number was intercepted and this person was informed.
    4. A subset of names and email addresses of ClientPortal users were intercepted.
      • We determined that this information alone would not be considered sensitive, but we have nevertheless informed those people affected.
    5. The names of accounts in ClientPortal were intercepted.
      • This is a list of the names of organizations that we have exchanged files with in the past. This includes organizations such as customers, partners and suppliers.
      • After review, we determined that the names alone would not be considered sensitive.
  • Email: we know that the attacker intercepted Fox-IT email for a maximum of 10 minutes, and that during those 10 minutes, emails destined for Fox-IT were redirected to an external email provider. Since email distribution is decentralized on the internet, we have no way of determining which emails were intercepted by the attacker during that time.

The start of the incident response process

We have determined that the attacker successfully logged in to the DNS control panel of our third party domain registrar provider using valid credentials. This raises two key questions:

  • How were valid credentials obtained?
  • Why was access to the domain registrar possible with single factor rather than multi factor authentication?

On the question of how the credentials were obtained we have conducted extensive internal investigations alongside those conducted by the police investigating the incident. We interviewed people that had access to the vault, carried out extensive forensic investigation of all the systems that the password could been used on, and performed additional network forensics. We currently have no evidence that the password was stolen from any of our own internal systems. Right now, based on our own and the police investigation, we have strong evidence that supports our hypothesis that the adversary gained access to our credentials through the compromise of a third party provider. Investigations are ongoing.

A factor which possibly helped the attacker was that the password had not been changed since 2013. While our password is considered strong and can withstand brute force attacks, it was not changed because it was hardly ever used: DNS settings in general change very rarely. Nevertheless, this was something we could clearly have improved in our process.

The infrequency of our engagement with our domain registrar is also behind the answer to the second question, as to how the attacker was able to gain access to the DNS records solely using a username/password combination. Two factor authentication (2FA) – whereby the initial attempt to log-on can only be completed once a code sent to an authorized device is entered as second factor authentication – should be standard practice here. We chose our domain name registrar provider 18 years ago when 2FA was neither a consideration nor a possibility. We were surprised to find that the registrar still does not support 2FA. It is always worth asking: does your DNS registrar support 2FA? The answer may surprise you.

Reasonably quick detection but room for improvement

We hold our hands up to a number of errors on prevention, but we did decidedly better in the areas of detection and response. Once the attack was ongoing, we detected it reasonably quickly: within a few hours compared to the typical industry average of weeks before an attack is detected.

Our Security Operations Center (SOC) had noticed that a number of scans for weaknesses on our infrastructure were made in the days leading up to the attack. These were treated as regular “background noise on the internet” and not followed up on. While paying attention to those scans would probably not have helped us predict the following attack, it would certainly have raised our attention and we have now established mechanisms to improve early warning of suspicious security probing of this nature.

Effective response, containment and scope determination

In general, once an incident is detected, the most important goal becomes to limit the incident and determine the impact of the attack. Once we knew about the incident, we acted quickly and we were able to limit the impact of the incident quite effectively and in a timely manner.

The most important action that we took in order to limit the impact of the attack was to disable 2FA, in lieu of disabling login functionality altogether. We did this specifically to prevent people from successfully logging in but so as not to alert the attacker to the fact that we knew of the attack. This allowed us to better understand the modus operandi and scope of the attack before taking specific actions to mitigate it, an approach which is standard operating procedure for our CERT team. From that moment on, nobody could log in, effectively preventing traffic to our ClientPortal from being intercepted. Note that this did not directly stop the attack, but it stopped its effectiveness.

The use of full packet capture and CTMp network sensors was crucial in determining the scope of the attack. We could, within a few hours of finding out about the attack, determine exactly who was affected and what the scope of the attacker was. This helped us to understand the incident with confidence and to quickly notify those directly affected and the Dutch Data Protection Authority.

Lessons learned and recommendations

Looking back on this incident, we learned the following lessons and have the following recommendations:

  • Choose a DNS provider that doesn’t allow changes through a control panel but requires a more manual process, considering that name servers are very stable and hardly every change. If you do require more frequent changes, use 2FA.
  • Ensure that all system access passwords are reviewed regularly and changed, even those which are used rarely.
  • Deploy certificate transparency monitoring in order to detect, track and respond to fraudulent certificates.
  • Deploy full packet capture capabilities with good retention in crucial points of your infrastructure, such as the DMZ and border gateways.
  • Always inform Law Enforcement at an early stage, so that they can help you with your investigations, as we did in our case.
  • Make it a management decision to first understand an attack before taking specific actions to mitigate it. This may include letting an attack continue for a short period of time. We consciously made that decision.

Looking back in conclusion

While we deeply regret the incident and the shortcomings on our part which contributed to it, we also acknowledge that a number of the measures we had in place enabled us to detect the attack, respond quickly and confidently and thereby limited the scale and length of the incident. And that’s why the twin mantras in security should always be followed:

  • layered security; and
  • prevention, detection and response.

At the time that ‘if’ becomes ‘when’, it is the combination of these that ultimately determines your overall resilience and cyber security stance.

In the Clouds – Enterprise Security Weekly #72

Jeff Schilling, CSO of Armor joins us for an interview to discuss Cloud based security and incident response! In the news, updates from LogRhythm, Optiv Security, Fortinet, RiskSense, and more on this episode of Enterprise Security Weekly!

Full Show Notes:

Visit for all the latest episodes!

IDG Contributor Network: Who are you really inviting in?

Back in the olden days, you might have hidden a key under the door mat, in a flower pot, or hanging on an inconspicuous nail somewhere on your property. It not only meant you would never be locked out of your own home, but it was also a move for safety or convenience. Paramedics could open your door with directions if you were hurt inside your home, and neighbors who called you at work about a large package on your doorstep could help you out by moving it inside.

Over the years, technology has caught up with our home security. For years now, retailers have sold front door deadbolt locks that allow outsiders access to your property by punching in the physical buttons on the lock, releasing the mechanism and letting them open the door. That meant changing out the code every single time you shared it with someone though, just to ensure that they didn’t come back at a later date.

To read this article in full, please click here

Hack Naked News #153 – December 12, 2017

Paul reports on Google patches, vulnerability in two keyless entry locks, Mozilla security updates, and 1.4 billion plain-text leaked passwords found online! Jason Wood of Paladin Security joins us for the expert commentary, and more on this episode of Hack Naked News!


Full Show Notes:


Visit for all the latest episodes!

FTC and FCC Announce Cooperation on Repeal of Net Neutrality Rules

Recently, the FTC and FCC announced their intent to enter into a Memorandum of Understanding (“MOU”) under which the agencies would coordinate their efforts following the adoption of the Restoring Internet Freedom Order (the “Order”). As we previously reported, if adopted, the Order would repeal the rules put in place by the FCC in 2015 that prohibit high-speed internet service providers (“ISPs”) from stopping or slowing down the delivery of websites and from charging customers extra fees for high-quality streaming and other services. 

The MOU identifies a number of ways in which the FTC and FCC will facilitate their joint and common goals, including:

  • The FCC will review informal consumer complaints concerning the compliance of ISPs with the disclosure obligations set forth in the new transparency rule (and take enforcement actions against ISPs as appropriate). Those obligations include publicly providing information concerning an ISP’s practices with respect to blocking, throttling, paid prioritization and congestion management.
  • The FTC will investigate and take enforcement actions against ISPs for unfair, deceptive or otherwise unlawful acts or practices, including those pertaining to the accuracy of disclosures made by ISPs pursuant to Order requirements.
  • The agencies may coordinate and cooperate to develop guidance for consumers to assist in their understanding of ISP practices.
  • The FCC and FTC will share consumer complaints pertaining to the Order’s requirements to the extent feasible and subject to the agencies’ requirements and policies governing, among other things, the protection of confidential, personally identifiable or non-public information.
  • The FCC and FTC will share relevant investigative techniques and tools, intelligence, technical and legal expertise, and best practices in response to reasonable requests for such assistance from either agency.

The FCC is scheduled to vote on the draft Order on December 14, 2017.

Criminals in a festive mood

This morning the Fox-IT Security Operations Center observed a large number of phishing e-mails that contained a link to a downloadable zip file. Anyone downloading and opening that zip file would infect themselves with banking malware, that would subsequently try to lure the victim into divulging their credit card information.

So far nothing new: e-mail as attack vector, distribution of the Zeus Panda banking trojan, targeting the same institutions.

Except that this time, it appears the criminals are preparing for the festive season. What stood out to us is the inclusion of a number of local retailers that are now targeted by this banking trojan. Some targeted websites which were extracted from the configuration are:

  • Coolblue
  • Otto
  • Amazon
  • De Volksbank (SNS, ASN & Regiobank)
  • ING
  • ABN Amro
  • Knab
  • Triodos

So now, when someone has infected themselves with this malware by opening the malicious zip file, not only will the malware ask for their credit card details when they visit their bank’s website, but also when they visit an online retailer for (Christmas) shopping.

Read on for recommendations, notable observations, stats and screenshots and technical details including indicators of compromise.

The usual recommendations for end users apply: be alert for criminals attacking you by sending legitimate looking e-mails with links and attachments. And be alert for websites behaving differently and asking for credit card details or other personal data where they normally don’t. If you suspect an infection, you may check out a website from a different device to see if it behaves the same. If it doesn’t, you may be infected.

The e-mail itself is nothing out of the ordinary. It appears to be targeting the Netherlands and Germany, using Dutch text and faking the Dutch DHL Group. This is what it looks like:

Beste heer/mevrouw,
UW ZENDING IS ONDERWEG ,Informatie Over Uw Zending is in dokument.

Controleer hieronder uw zending- en contactgegevens. Klik op om te bevestigen.
Bedankt dat u heeft gekozen voor On Demand Delivery.
DHL Express – Excellence. Simply delivered.
Nederlandse Post DHL Group

For organisations, the recommendations are also familiar: isolate any infected systems prior to cleaning them, change any password that was used after infection and consider client certificates on that system compromised. You may refer to the indicators of compromise later on in this post.

Additional interesting observations
The malware that is being distributed is called Zeus Panda, which we’ve followed for almost two years now. This is a variant of the Zeus family of malware that Fox-IT has observed since around 2006, for the purpose of protecting its own customers. The name Zeus Panda comes from the web panel used by the malware operators.

At the time of writing, the two malicious zip file referred in the emails received a little over 48 thousand clicks, mostly in the Netherlands, but also in other parts of Western Europe and some in North America. Out of those 48 thousand clicks, only 11 thousand came from a Window system, which is the only platform that the malware runs on. The other 37 thousands people were safe! A clear example and proof of the shotgun approach that criminals still successfully use.

Also interesting is the clunky nature of the injects. As shown in the screenshots below, the code that the criminals inject into the website on the infected system looks, well, unfinished.

Full statistics
The link in the email is a Google Shortened URL, which downloads the zip-file from

By default Google shortened URL’s keeps track of the following statistics:
– Amount of clicks
– Used Browsers
– Referrers
– Countries
– Platforms

Requesting the statistics of the shortened URL results in the following statistics for:


Screenshot of the inject asking for credit card details
From an infected system, Zeus Panda will inject extra code into a website. Once the code is injected into one of the targeted web pages, an extra form is added for creditcard information. For example, Coolblue’s webshop page would look like this, clunky and unfinished. Please note that Coolblue has no control over the fact that criminals attempt to inject code into their website from infected machines.


Zeus Panda Banker web inject

EDIT: the total click count for both domains has increased to a total of 66 thousand, even though both ZIP-files are not available anymore.

Indicators of Compromise
hxxp:// (compromised website)
hxxp:// (compromised website)

hxxps:// (SSL connection)

—External panel for injects—

MD5: aefc0fe15836165291cb66eac5ffd177
SHA256: 588e31ac96bd6318f787602e87f86b75d4b5537679e11ba5a509589148033275

contactgegevens 12_2017_10_00_.js
MD5: deb9a0aa69270a0b263b80ed13880b24
SHA256: eb65b1d5f5b3ccc263a4984275c084b63b0a262a87d55887d6a4d744a75e4112

MD5: 4ac38a4efa276f8d64c1ed39a53e7ab8
SHA256: e556273db50d4588d7e4b5183d06d39b0ebedbb094fc2a39b59416212c829324

Making a simple network traffic graph with tshark and afterglow

Outputting a pcap file for CSV format for using afterglow. pl and neato (Graphviz) to create a graph
To make a simple source and destination graph..
First make the capture file using tcpdump
tcpdump -nn -i -q
Then use tshark to extract the source and destination IP address and output to a comma separated file
tshark -T fields -nn -r capture.pcap -E separator=, -e ip.src -e ip.dst > output.txt
Sort and remove duplicates
cat output.txt | sort | uniq > output.csv
or just sort to see all connections
cat output.txt | sort > output.csv
Edit file to remove any lines with incorrect data (like just a comma)
Process the file through afterglow to format in dot graph format that Graphviz can use
cat output.csv | afterglow/ -t >
Create your graph in .png format
cat | neato -Tpng > output.png

Weekly Cyber Risk Roundup: Bitcoin Attacks Dominate Headlines, New Phishing Warnings

Several cryptocurrency exchanges were among the week’s top trending cybercrime targets due to a variety of different currency thefts, data breaches, and warnings from researchers.


The most impactful incident occurred at the bitcoin mining platform and exchange NiceHash, which said on Wednesday that its payment system was compromised and the bitcoin in its wallet was stolen. NiceHash said it is “working to verify the precise number of BTC taken”; however, news outlets reported that a wallet linked to the attack obtained around 4,736 bitcoin, which is valued at more than $72 million based on Saturday’s price. The company has not released many details about the attack other than that it began after an employee’s computer was compromised.

In addition, researchers warned this week that the increased valuation of bitcoin has led to it becoming one of the top 10 most targeted industries for DDoS attacks. On Monday, Bitfinex said that its services were disrupted by a DDoS attack. On Thursday, Coinbase warned that the explosion of interest in digital currencies was creating “extreme volatility and stress” on its systems and warned its users to invest responsibly as any future downtime could impact their ability to trade.

News outlets also reported that some Bittrex customers who go through the company’s manual verification process but are rejected have received customer support emails that contain the passports details and photographs of other users, although Bittrex has not confirmed the reports.

Finally, the SEC announced that it obtained an emergency asset freeze to halt the Initial Coin Offering PlexCorps after it raised up to $15 million from thousands of investors by falsely promising a 13-fold profit in less than a month’s time.


Other trending cybercrime events from the week include:

  • TIO Networks announces breach: PayPal announced a breach at TIO Networks, a payment processor it acquired in July, that affects approximately 1.6 million customers. City Utilities (CU) and Duke Energy have since notified customers that their personal information was compromised due to the breach, as TIO was the provider of the operating system for CU’s payment kiosks and mobile payment app, in addition to being used to process Duke Energy’s in-person payments.
  • Payment card breaches: The Image Group is notifying customers of a temporary vulnerability on its eCommerce platform, Payflow Pro, that made some payment card numbers susceptible to interception while in transit to PayPal. JAM Paper & Envelope is notifying customers of a payment card card breach affecting its website due to unauthorized access by a third party. A payment card breach involving the Royal National Institute for the Blind’s web store affects as many as 817 customers, and around 55 individuals have already reported fraudulent activity as a result of the incident.
  • Extortion attacks: The Alameda County Library is notifying its users that their personal information may have been compromised after it received an extortion email that claimed hackers had gained access to the library’s entire database of users and may sell that information if they weren’t paid a five bitcoin ransom. The Mecklenburg County government in North Carolina said that its computer systems were infected with ransomware that is demanding $23,000 for the encryption key. Mad River Township Fire and EMS Department in Ohio said that years of data related to residents who used EMS or fire services was lost due to a ransomware infection. The fertility clinic CCRM Minneapolis said that nearly 3,300 patients may have had their information compromised due to a ransomware attack.
  • Other notable incidents: The Center for Health Care Services in San Antonio is notifying 28,434 patients that their personal information was stolen by a former employee. The County of Humboldt is notifying current and former employees that the Humboldt County Sheriff’s Office recovered payroll documents from the county. Pulmonary Specialists of Louisville is notifying patients their information may have been compromised due to possible unauthorized access. Virtual keyboard developer Ai.Type, bike sharing company oBike, Real Time Health Quotes, and Stanford University all had data breaches due to accidental data exposure. Baptist Health Louisville, Sinai Health System, and The Henry Ford Health System notified patients of employee email account breaches.
  • Law enforcement actions: Authorities reportedly shut down Leakbase, a service that sold access to more than two billion credentials collected from old data breaches. The Justice Department announced a software developer at the National Security Agency’s Tailored Access Operations has pleaded guilty to removing classified NSA data and later having that data stolen from his personal computer by Russian state-sponsored actors. A Michigan man pleaded guilty to gaining access to the Washtenaw County computer network and altering the electronic records of at least one inmate in an attempt to get the inmate released early. A Missouri man has been sentenced to six years in prison for hacking his former employer, American Crane & Tractor Parts, in order to steal trade secrets.

SurfWatch Labs collected data on many different companies tied to cybercrime over the past week. Some of those “newly seen” targets, meaning they either appeared in SurfWatch Labs’ data for the first time or else reappeared after being absent for several weeks, are shown in the chart below.


Cyber Risk Trends From the Past Week

2017-12-8_RiskScoresPhishing concerns were highlighted once again this past week due to a newly announced vulnerability that allows malicious actors to spoof emails, as well as warnings that phishers are making efforts to appear more legitimate.

A researcher has discovered a collection of bugs in email clients, dubbed “Mailsploit,” that circumvents spoofing protection mechanisms and, in some cases, allows code injection attacks. The vulnerabilities were found in dozens of applications, including Apple Mail, Mozilla Thunderbird, Microsoft Outlook 2016, Yahoo! Mail, ProtonMail, and others.

The bug has been fixed in 10 products and triaged for 8 additional products, the researcher said. In addition, Mozilla and Opera said they won’t fix the bug as they consider it to be a server-side problem; however, Thunderbird developer Jörg Knobloch told Wired that a patch would be made available. DMARC spoofing protection is not attacked directly using Mailsploit,  the researcher said, but rather bypassed by taking advantage of how the clients display the email sender name.

In addition, researchers said that nearly a quarter of all phishing websites are now hosted on HTTPS domains, up from three percent a year ago. The increase is due to both an increased number of HTTPS websites that can be compromised and used to host malicious content, as well as phishers registering HTTPS domains themselves due to their belief that the “HTTPS” designation makes a phishing site seem more legitimate to potential victims. An informal poll conducted by PhishLabs found that more than 80% of the respondents incorrectly believed the green padlock associated with HTTPS websites indicated that a website was either legitimate or safe — when in reality it only means that the connection is encrypted.

Individuals and organizations should be aware that malicious actors continue to leverage exploits like Mailsploit along with more secure-looking websites in order to dupe potential victims via phishing attacks with the goal of installing malware, gaining access to networks, or stealing sensitive data.

Channeling Back – Startup Security Weekly #65

Todd O'Boyle of StrongArm joins us for an interview! In our article discussion, we discuss behaviors that can drive cultural change, the power of office back-channeling, and the five traits of successful teams at Google! In the news, we have updates from InterVision, Prevoty, Okta, and Riskonnect, and more on this episode of Startup Security Weekly

Full Show Notes:

Visit for all the latest episodes!


Paul’s Security Weekly #539 – Dental Security Weekly

Lisa O'Connor of Accenture Labs joins us for an interview to discuss threat intelligence, advanced cyber hunting, active defense, and security of the Industrial Internet of things! Eyal Neemany of Javelin Networks joins us for the tech segment to discuss bypassing Two-Factor Authentication! Paul and Larry talk about Uber, vulnerable banking apps, and bluetooth on the news, on this weeks episode of Paul's Security Weekly!

Full Show Notes:

Visit for all the latest episodes!

→Follow us on Twitter:

→Like us on Facebook:

Article 29 Working Party Meeting Sets Out State of Play on Privacy Initiatives

Recently, the EU’s Article 29 Working Party (”Working Party”) held a plenary meeting to discuss, among other things, the implementation of the EU General Data Protection Regulation (“GDPR”) and the EU-U.S. Privacy Shield. As well as adopting its first Joint Annual Review Report on the Privacy Shield, the Working Party has been working on a number of documents that offer review and/or guidance on the GDPR, including:

  • guidelines on (1) consent and transparency, (2) data protection certifications, and (3) derogations for personal data transfers under the GDPR;
  • updated “referentials” on adequacy and binding corporate rules for data controllers and processors; and
  • tools for cooperation between data protection authorities on data breach notifications.

Future work includes:

  • developing a position on Article 3 of the GDPR, which pertains to the GDPR’s territorial scope;
  • a new opinion on the proposal of the ePrivacy Regulation, which the European Commission aims to introduce alongside the GDPR.

In addition to these documents, the Working Party has made progress on defining the organization and structure of the European Data Protection Board (“EDPB”), which will be ready by May 2018. The EDPB will replace the Working Party and will have a more active role in the regulation of data protection practices across the EU in comparison to its predecessor. The Working Party also has established a taskforce to focus on harmonization with respect to the calculation of fines imposed under the GDPR, having recognized that there exists a range of approaches to sanctioning across EU Member States.

CIPL Submits Comments to Article 29 WP’s Proposed Guidelines on ADM and Profiling

On December 1, 2017, the Centre for Information Policy Leadership (“CIPL”) at Hunton & Williams LLP submitted formal comments to the Article 29 Working Party (the “Working Party”) on its Guidelines on Automated Individual Decision-Making and Profiling (the “Guidelines”). The Guidelines were adopted by the Working Party on October 3, 2017, for public consultation.

In its comments to the Guidelines, CIPL recommends several changes or clarifications the Working Party should incorporate in its final guidelines, including the following:

Automated Decision-Making (“ADM”)

  • Article 22 of the EU General Data Protection Regulation (“GDPR”) should not be interpreted as a general prohibition of ADM. This interpretation is not mandated by the text of the GDPR, is not necessary to give effect to the additional protections of Article 22, and is too restrictive to ensure that the GDPR remains principle-based and future-proof in light of evolving data processing, machine learning and AI.
  • Article 22 should, instead, be interpreted as a right to be invoked, which is line with the text of the GDPR as well as with the spirit and essence of the right not to be subject to solely ADM, which produces legal effects or similarly significant effects. Under this approach, ADM is permitted under all six processing grounds, including legitimate interest, unless the individual invokes his or her right not to be subject to ADM. This right can be invoked prospectively or retrospectively.
  • The meaning of “legal” effect and “similarly significant” effect must be interpreted strictly to ensure Article 22 only covers truly impactful ADM.
  • For an ADM process to produce a similarly significant effect, it must rise to the same level as producing a legal effect, which is a high bar.
  • The Working Party should provide examples of categories of solely automated decisions that produce legal effects, similarly significant effects and decisions which do not produce such effects.
  • The Guidelines on targeted advertising should be revised, and, in particular, the example put forward to demonstrate a targeted ad producing a similarly significant effect removed.
  • The Working Party should clarify that using data to train or enhance algorithms is exempt from the requirements of Article 22 of the GDPR once the organization has made efforts to sufficiently de-identify the training data where possible, and employ other risk minimizing controls where appropriate and necessary (e.g., administrative and contractual controls).
  • The Guidelines should clarify that the nature and scope of human intervention is highly contextual and can include a range of measures. The ultimate goal of human intervention should be to ensure correct automated processing and a fair and accurate decision, and human intervention must relate to a specific instance of ADM.


  • The Working Party should make clear that data processing only falls within the definition of profiling under the GDPR if collected personal data is actually used to evaluate, analyze or predict personal aspects relating to a natural person, and that manual evaluation does not equate to profiling.
  • The Guidelines should highlight that there are two, rather than three, types of profiling:(1) general profiling and (2) profiling that results in a solely automated decision which produces legal effects or similarly significantly affects an individual.
  • The Guidelines should make clear that profiling does not undermine an individual’s freedom to choose certain products or services, with the exception of extreme circumstances. Most forms of profiling and targeted advertising based on profiles do not restrict an individual’s freedom to choose certain products or services.
  • Linked to profiling and targeted advertising, the Guidelines should highlight that the granularity of the segmentation does not necessarily mean the legitimate interest of the data controller is overridden automatically by the data subject. This is one factor to consider in the balancing test and must be measured alongside the risks of the likelihood of identification of an individual and safeguards provided by the data controller, such as setting a minimum audience size.
  • The Guidelines should clarify that that the right to object in Article 21(1) of the GDPR does not impose a different legitimate interest standard than Article 6(1)(f), and that in the face of an objection to profiling, the data controller must only demonstrate that the data controller’s earlier legitimate interest analysis was correct and that its legitimate interests still prevail.

CIPL’s comments were developed based on input by the private sector participants in CIPL’s ongoing GDPR Implementation Project, which includes more than 85 individual private sector organizations. As part of this initiative, CIPL will continue to provide formal input about other GDPR topics the Working Party prioritizes.


NCCIC is aware of a public report of an improper authentication vulnerability affecting WAGO PFC200, a Programmable Logic Controller (PLC) device. According to this report, the vulnerability is exploitable by sending a TCP payload on the bound port. This report was released after attempted coordination with WAGO. NCCIC has notified the affected vendor of the report and has asked the vendor to confirm the vulnerability and identify mitigations. NCCIC is issuing this alert to provide notice of the report and identify baseline mitigations for reducing risks to these and other cybersecurity attacks.

CIPL Submits Comments to Article 29 WP’s Proposed Guidelines on Data Breach Notification

On December 1, 2017, the Centre for Information Policy Leadership (“CIPL”) at Hunton & Williams LLP submitted formal comments to the Article 29 Working Party (the “Working Party”) on its Guidelines on Personal Data Breach Notification (the “Guidelines”). The Guidelines were adopted by the Working Party on October 3, 2017, for public consultation.

The EU General Data Protection Regulation (“GDPR”) introduces specific breach notification obligations for data controllers and processors. CIPL’s comments on the Guidelines commend the Working Party for drawing lessons from the experiences of other jurisdictions where breach notification has been a longstanding requirement. Additionally, CIPL’s comments welcome the discussions surrounding at what point a data controller is deemed to be aware of a personal data breach, as well as the recognition of the need to allow a phased notification of the supervisory authority in some circumstances.

CIPL’s comments, however, also emphasize several key issues that it believes need further clarification. The key recommendations for improving the Guidelines include the following:

Availability Breaches

  • The definition of an “availability breach” used in the Guidelines does not fit the GDPR’s Article 4(12) definition of a “personal data breach.” The Working Party should revise the definition of an “availability breach” in the Guidelines to refer only to a breach in which there is an accidental or unlawful loss or destruction of personal data.

Risk Assessment

  • The Working Party should, when discussing the term “data breach,” distinguish between a personal data breach per Article 4(12) of the GDPR and a “notifiable” personal data breach per Articles 33 and 34.
  • Some of the examples discussed in the section on Risk Assessment fail to include an analysis of both the severity and the likelihood of a breach resulting in a risk to individuals’ rights and freedoms. Several of the breach examples in Annex B should be amended to reflect both aspects of the risk assessment.
  • Data controllers should not be required to continuously reassess the risk posed by a past data breach in light of future technological developments long after the breach occurred. The Guidelines should clarify that such a reassessment need only be undertaken if a major breakthrough occurs immediately or within a short time period after the breach.

Criteria to Consider in Assessing Breach Risk

  • To help supervisory authorities manage the number of breach notifications they receive and to enable them to deal with those reports effectively, a threshold of breach size for internal administrative purposes might be established. The threshold size (e.g., between 250 and 500 individuals) should be consistent across all jurisdictions.
  • The Working Party should also consider setting a threshold for the number of individuals affected by a breach that would trigger the requirement to notify the supervisory authorities, except where the breach poses a high risk to individual rights and freedoms.
  • The imputation that any data breach involving a large number of individuals or special categories of personal data should automatically be deemed to have a likelihood of risk to individuals’ rights and freedoms should be eliminated. The likelihood and severity of the risks should be considered regardless of the number affected or the type of personal data involved.

Timing of Notification

  • The Guidelines should clarify that the 72 hour deadline for notification does not begin until after the data controller has completed an investigation that results in awareness that the incident involved personal data and is likely to result in a risk to individuals’ rights and freedoms.
  • An organization’s decision to hire a forensics firm or engage in a technical investigation does not automatically mean the organization is aware of a notifiable breach.
  • The Working Party should make clear that as part of a phased notification, a data controller may avail itself of a mechanism for keeping reported information confidential until its investigation is complete.

Controller-Processor Responsibilities

  • The description of a data processor’s timeline to notify a data controller about a breach should be changed from “immediate” to “prompt.” Immediate notification is an unclear and unrealistic expectation that could imply that data processors should notify data controllers of any and every security incident, without any prior investigation.
  • The Working Party should clarify that joint data controllers can designate responsibility for notification, or jointly notify the supervisory authority and jointly communicate with affected individuals.

Supervisory Authority to Notify

  • The Guidelines should clarify which supervisory authority should be notified by a data controller that does not have an establishment in the EU, and which authority should be notified by a data controller when a breach affects only individuals not located in the jurisdiction of the data controller’s lead authority.

Methods of Communication to Individuals

  • The potential drawbacks of email and SMS as a sole communication method for notifying individuals about a personal data breach should be highlighted, as these communication channels are fraud-prone.

CIPL’s comments were developed based on input by the private sector participant’s in CIPL’s ongoing GDPR Implementation Project, which includes more than 85 individual private sector organizations. As part of this initiative, CIPL will continue to provide formal input about other GDPR topics the Working Party prioritizes.

New Targeted Attack in the Middle East by APT34, a Suspected Iranian Threat Group, Using CVE-2017-11882 Exploit

Less than a week after Microsoft issued a patch for CVE-2017-11882 on Nov. 14, 2017, FireEye observed an attacker using an exploit for the Microsoft Office vulnerability to target a government organization in the Middle East. We assess this activity was carried out by a suspected Iranian cyber espionage threat group, whom we refer to as APT34, using a custom PowerShell backdoor to achieve its objectives.

We believe APT34 is involved in a long-term cyber espionage operation largely focused on reconnaissance efforts to benefit Iranian nation-state interests and has been operational since at least 2014. This threat group has conducted broad targeting across a variety of industries, including financial, government, energy, chemical, and telecommunications, and has largely focused its operations within the Middle East. We assess that APT34 works on behalf of the Iranian government based on infrastructure details that contain references to Iran, use of Iranian infrastructure, and targeting that aligns with nation-state interests.

APT34 uses a mix of public and non-public tools, often conducting spear phishing operations using compromised accounts, sometimes coupled with social engineering tactics. In May 2016, we published a blog detailing a spear phishing campaign targeting banks in the Middle East region that used macro-enabled attachments to distribute POWBAT malware. We now attribute that campaign to APT34. In July 2017, we observed APT34 targeting a Middle East organization using a PowerShell-based backdoor that we call POWRUNER and a downloader with domain generation algorithm functionality that we call BONDUPDATER, based on strings within the malware. The backdoor was delivered via a malicious .rtf file that exploited CVE-2017-0199.

In this latest campaign, APT34 leveraged the recent Microsoft Office vulnerability CVE-2017-11882 to deploy POWRUNER and BONDUPDATER.

The full report on APT34 is available to our MySIGHT customer community. APT34 loosely aligns with public reporting related to the group "OilRig". As individual organizations may track adversaries using varied data sets, it is possible that our classifications of activity may not wholly align.

CVE-2017-11882: Microsoft Office Stack Memory Corruption Vulnerability

CVE-2017-11882 affects several versions of Microsoft Office and, when exploited, allows a remote user to run arbitrary code in the context of the current user as a result of improperly handling objects in memory. The vulnerability was patched by Microsoft on Nov. 14, 2017. A full proof of concept (POC) was publicly released a week later by the reporter of the vulnerability.

The vulnerability exists in the old Equation Editor (EQNEDT32.EXE), a component of Microsoft Office that is used to insert and evaluate mathematical formulas. The Equation Editor is embedded in Office documents using object linking and embedding (OLE) technology. It is created as a separate process instead of child process of Office applications. If a crafted formula is passed to the Equation Editor, it does not check the data length properly while copying the data, which results in stack memory corruption. As the EQNEDT32.exe is compiled using an older compiler and does not support address space layout randomization (ASLR), a technique that guards against the exploitation of memory corruption vulnerabilities, the attacker can easily alter the flow of program execution.


APT34 sent a malicious .rtf file (MD5: a0e6933f4e0497269620f44a083b2ed4) as an attachment in a malicious spear phishing email sent to the victim organization. The malicious file exploits CVE-2017-11882, which corrupts the memory on the stack and then proceeds to push the malicious data to the stack. The malware then overwrites the function address with the address of an existing instruction from EQNEDT32.EXE. The overwritten instruction (displayed in Figure 1) is used to call the “WinExec” function from kernel32.dll, as depicted in the instruction at 00430c12, which calls the “WinExec” function.

Figure 1: Disassembly of overwritten function address

After exploitation, the ‘WinExec’ function is successfully called to create a child process, “mshta.exe”, in the context of current logged on user. The process “mshta.exe” downloads a malicious script from hxxp://mumbai-m[.]site/b.txt and executes it, as seen in Figure 2.

Figure 2: Attacker data copied to corrupt stack buffer

Execution Workflow

The malicious script goes through a series of steps to successfully execute and ultimately establish a connection to the command and control (C2) server. The full sequence of events starting with the exploit document is illustrated in Figure 3.

Figure 3: CVE-2017-11882 and POWRUNER attack sequence

  1. The malicious .rtf file exploits CVE-2017-11882.
  2. The malware overwrites the function address with an existing instruction from EQNEDT32.EXE.
  3. The malware creates a child process, “mshta.exe,” which downloads a file from: hxxp://mumbai-m[.]site/b.txt.
  4. b.txt contains a PowerShell command to download a dropper from: hxxp://dns-update[.]club/v.txt. The PowerShell command also renames the downloaded file from v.txt to v.vbs and executes the script.
  5. The v.vbs script drops four components (hUpdateCheckers.base, dUpdateCheckers.base, cUpdateCheckers.bat, and GoogleUpdateschecker.vbs) to the directory: C:\ProgramData\Windows\Microsoft\java\
  6. v.vbs uses CertUtil.exe, a legitimate Microsoft command-line program installed as part of Certificate Services, to decode the base64-encoded files hUpdateCheckers.base and dUpdateCheckers.base, and drop hUpdateCheckers.ps1 and dUpdateCheckers.ps1 to the staging directory.
  7. cUpdateCheckers.bat is launched and creates a scheduled task for GoogleUpdateschecker.vbs persistence.
  8. GoogleUpdateschecker.vbs is executed after sleeping for five seconds.
  9. cUpdateCheckers.bat and *.base are deleted from the staging directory.

Figure 4 contains an excerpt of the v.vbs script pertaining to the Execution Workflow section.

Figure 4: Execution Workflow Section of v.vbs

After successful execution of the steps mentioned in the Execution Workflow section, the Task Scheduler will launch GoogleUpdateschecker.vbs every minute, which in turn executes the dUpdateCheckers.ps1 and hUpdateCheckers.ps1 scripts. These PowerShell scripts are final stage payloads – they include a downloader with domain generation algorithm (DGA) functionality and the backdoor component, which connect to the C2 server to receive commands and perform additional malicious activities. 

hUpdateCheckers.ps1 (POWRUNER)

The backdoor component, POWRUNER, is a PowerShell script that sends and receives commands to and from the C2 server. POWRUNER is executed every minute by the Task Scheduler. Figure 5 contains an excerpt of the POWRUNER backdoor.

Figure 5: POWRUNER PowerShell script hUpdateCheckers.ps1

POWRUNER begins by sending a random GET request to the C2 server and waits for a response. The server will respond with either “not_now” or a random 11-digit number. If the response is a random number, POWRUNER will send another random GET request to the server and store the response in a string. POWRUNER will then check the last digit of the stored random number response, interpret the value as a command, and perform an action based on that command. The command values and the associated actions are described in Table 1.





Server response string contains batch commands

Execute batch commands and send results back to server


Server response string is a file path

Check for file path and upload (PUT) the file to server


Server response string is a file path

Check for file path and download (GET) the file

Table 1: POWRUNER commands

After successfully executing the command, POWRUNER sends the results back to the C2 server and stops execution.

The C2 server can also send a PowerShell command to capture and store a screenshot of a victim’s system. POWRUNER will send the captured screenshot image file to the C2 server if the “fileupload” command is issued. Figure 6 shows the PowerShell “Get-Screenshot” function sent by the C2 server.

Figure 6: Powershell Screenshot Functionality

dUpdateCheckers.ps1 (BONDUPDATER)

One of the recent advancements by APT34 is the use of DGA to generate subdomains. The BONDUPDATER script, which was named based on the hard-coded string “B007”, uses a custom DGA algorithm to generate subdomains for communication with the C2 server.

DGA Implementation

Figure 7 provides a breakdown of how an example domain (456341921300006B0C8B2CE9C9B007.mumbai-m[.]site) is generated using BONDUPDATER’s custom DGA.

Figure 7: Breakdown of subdomain created by BONDUPDATER

  1. This is a randomly generated number created using the following expression: $rnd = -join (Get-Random -InputObject (10..99) -Count (%{ Get-Random -InputObject (1..6)}));
  2. This value is either 0 or 1. It is initially set to 0. If the first resolved domain IP address starts with 24.125.X.X, then it is set to 1.
  3. Initially set to 000, then incremented by 3 after every DNS request
  4. First 12 characters of system UUID.
  5. “B007” hardcoded string.
  6. Hardcoded domain “mumbai-m[.]site”

BONDUPDATER will attempt to resolve the resulting DGA domain and will take the following actions based on the IP address resolution:

  1. Create a temporary file in %temp% location
    • The file created will have the last two octets of the resolved IP addresses as its filename.
  2. BONDUPDATER will evaluate the last character of the file name and perform the corresponding action found in Table 2.




File contains batch commands, it executes the batch commands


Rename the temporary file as .ps1 extension


Rename the temporary file as .vbs extension

Table 2: BONDUPDATER Actions

Figure 8 is a screenshot of BONDUPDATER’s DGA implementation.

Figure 8: Domain Generation Algorithm

Some examples of the generated subdomains observed at time of execution include:




Network Communication

Figure 9 shows example network communications between a POWRUNER backdoor client and server.

Figure 9: Example Network Communication

In the example, the POWRUNER client sends a random GET request to the C2 server and the C2 server sends the random number (99999999990) as a response. As the response is a random number that ends with ‘0’, POWRUNER sends another random GET request to receive  an additional command string. The C2 server sends back Base64 encoded response.

If the server had sent the string “not_now” as response, as shown in Figure 10, POWRUNER would have ceased any further requests and terminated its execution.

Figure 10: Example "not now" server response

Batch Commands

POWRUNER may also receive batch commands from the C2 server to collect host information from the system. This may include information about the currently logged in user, the hostname, network configuration data, active connections, process information, local and domain administrator accounts, an enumeration of user directories, and other data. An example batch command is provided in Figure 11.

Figure 11: Batch commands sent by POWRUNER C2 server


APT34 has used POWRUNER and BONDUPDATER to target Middle East organizations as early as July 2017. In July 2017, a FireEye Web MPS appliance detected and blocked a request to retrieve and install an APT34 POWRUNER / BONDUPDATER downloader file. During the same month, FireEye observed APT34 target a separate Middle East organization using a malicious .rtf file (MD5: 63D66D99E46FB93676A4F475A65566D8) that exploited CVE-2017-0199. This file issued a GET request to download a malicious file from:


As shown in Figure 12, the script within the dupatechecker.doc file attempts to download another file named dupatechecker.exe from the same server. The file also contains a comment by the malware author that appears to be an apparent taunt to security researchers.

Figure 12: Contents of dupdatechecker.doc script

The dupatechecker.exe file (MD5: C9F16F0BE8C77F0170B9B6CE876ED7FB) drops both BONDUPDATER and POWRUNER. These files connect to proxychecker[.]pro for C2.

Outlook and Implications

Recent activity by APT34 demonstrates that they are capable group with potential access to their own development resources. During the past few months, APT34 has been able to quickly incorporate exploits for at least two publicly vulnerabilities (CVE-2017-0199 and CVE-2017-11882) to target organizations in the Middle East. We assess that APT34’s efforts to continuously update their malware, including the incorporation of DGA for C2, demonstrate the group’s commitment to pursing strategies to deter detection. We expect APT34 will continue to evolve their malware and tactics as they continue to pursue access to entities in the Middle East region.


Filename / Domain / IP Address

MD5 Hash or Description

CVE-2017-11882 exploit document





















Malware Staging Server

CVE-2017-0199 exploit document


Malware Staging Server







Has resolved mumbai-m[.]site & hpserver[.]online

Has resolved mumbai-m[.]site and dns-update[.]club

Has resolved dns-update[.]club

Has resolved dns-update[.]club

Has resolved ns2.dns-update[.]club & hpserver[.]online & anyportals[.]com




























Working Party Releases Opinion on Joint Review of EU-U.S. Privacy Shield

As we previously reported, this October, the EU Commission released its report and accompanying working document on the first annual review of the EU-U.S. Privacy Shield framework. On November 28, 2017, the Article 29 Data Protection Working Party (the “Working Party”) adopted an opinion on the review (the “Opinion”). While the Opinion notes that the Working Party “welcomes the various efforts made by US authorities to set up a comprehensive procedural framework to support the operation of the Privacy Shield,” the Opinion also identifies some remaining concerns and recommendations with respect to both the commercial and national security aspects of the Privacy Shield framework. The Opinion also indicates that, if the EU and U.S. do not, within specified time frames, adequately address the Working Party’s concerns about the Privacy Shield, the Working Party may bring legal action to challenge the Privacy Shield’s validity.

Read the full text of the Opinion.

In Which You Get a Chance to Save Democracy

Let’s start with the end: you can do something to change the broken political landscape in the United States, but you have to act quickly. Here’s a link to donate directly to outsider candidates I support who aren’t getting the funds they need. They are dedicated to working for their constituents’ healthcare, jobs, and community, but their districts are low income and have been ignored by national Democratic leadership. Any amount helps, no matter how small, but if you’re not a US citizen or permanent resident and can’t donate, at least you can help get the word out.

A few decades ago, I started became concerned about the national political landscape. Bush’s war on terror and the PATRIOT act were nightmares for freedom, and then Obama increased surveillance and drone strikes. At the same time, corporate lobbyists and PACs had grown to overrun the electoral process with their outsized influence.

The US is a rich country in funds and resources, but also in values. The Declaration of Independence puts it right up front: people have inherent rights that can’t be legislated away, and the government is there to secure those rights, drawing its power from the people. We don’t always live up to these values, but change has come upon us time and again with simple questions like, “am I not a man and a brother?

We are now at a critical point. Ignore the distracting presidency — Republicans are openly backing corporations & the wealthy by driving up the deficit and dismantling the thin safety net we have. Establishment Democrats are disorganized and out of touch with their roots, siding with financial interests instead of the poor and middle class. It’s time for a change.

Given that there isn’t a strong third party, the best bet is to renovate the Democrats from the inside. Too often, they have run weak candidates in districts that were too small or rural for them to care about, or even let the race go unopposed.

This has been a mistake. There is a huge vacuum for truly populist, outsider candidates. For 2018, the Democratic establishment appears to be cruising on anti-Trump sentiment, hoping enough voters are energized by his antics to turn against their local Republicans. Their tired playbook of dumping tons of outside money into business-friendly candidates to annoy residents with nonstop TV ads late in the campaign is another mistake.

The good news is that first-time Democratic candidates are running that support common sense policies like access to healthcare, investing in infrastructure, and education. And, they’re focused on the basics: build a ground campaign that talks to voters and recruits volunteers to get out the vote. The community they build will outlast this one election. But since they’re running in districts that have been ignored by the Democratic organization, they are lacking basic funds.

More good news: we’re not talking a lot of money. Your $10 or $100 donation makes a huge difference when $2,000/month hires a staff member. I know many of you are engineers & entrepreneurs that can give even more.

If these outsider candidates raise enough money before the primaries next year, it gets very interesting. The national Democratic party will notice the schoolteacher that just wiped the floor with their perennial, bland contender, outraising them with individual donations. Once they’re in the spotlight, these candidates will attract much more funding going into the main election and win their races.

Time is running out for 2017 to get these candidates off to a good start, so please consider giving an amount that hurts a bit, because it will be too late if we wait for the Democratic leadership to figure it out on their own.

FCC Releases Plan to Repeal Net Neutrality Rules

Recently, FCC Chairman Ajit Pai released a draft of the Restoring Internet Freedom Order (the “Order”). If adopted, the Order would repeal the rules put in place by the FCC in 2015 that prohibit high-speed internet service providers (“ISPs”) from stopping or slowing down the delivery of websites and from charging customers extra fees for high-quality streaming and other services.

The Order would reverse the FCC’s 2015 landmark decision to classify broadband Internet access as a “telecommunications service” subject to the regulatory obligations under Title II of the Communications Act of 1934 (the “Act”). By reclassifying broadband Internet as an “information service” under Title I of the Act, the Order asserts that this “light-touch” approach will “promote investment and innovation” by removing the application of “laws of a bygone era” to broadband Internet service. Additionally, the Order would require ISPs to disclose their network management practices, performance and commercial terms of service to consumers, to provide individual consumers the ability to decide what broadband service best meets their needs.

The Order also would return jurisdiction to regulate broadband privacy and data security practices to the FTC, which, according to the Order, would “enable the FTC to apply its extensive privacy and data security expertise to provide the uniform online privacy protections that consumers expect and deserve.” In 2016, the FCC adopted Broadband Consumer Privacy Rules that required ISPs to provide consumers with increased choice, transparency and security over their personal information. Earlier this year, Congress voted to nullify the Privacy Rules, prohibiting the FCC from adopting anything “substantially similar.” Acting FTC Chairman Maureen K. Ohlhausen issued a statement in response to the draft Order, stating that the FTC “stands ready to protect broadband subscribers from anticompetitive, unfair, or deceptive acts and practices just as we protect consumers in the rest of the Internet ecosystem.”

The FCC is scheduled to vote on the draft Order on December 14, 2017.

Hack Naked News #152 – December 5, 2017

Paul reports on a flaw found in Dirty COW patch, Apache Software security updates, more hacks in 2018, and a MailSploit e-mail spoofing flaw! Jason Wood joins us to give expert commentary on a Federal Data Breach Legislation, and more on this episode of Hack Naked News!Full Show Notes:

Visit for all the latest episodes!

Startup Security Weekly #64 – Legal in Some States

Zach Schlumpf of IOActive joins us. In our article discussion, we talk about winning arguments, turning insight into execution, and avoiding the "Yes" dilemma. In the news, we have updates from Bitdefender, McAfee, Barracuda Networks, Pwnie Express, ReversingLabs, and more on this episode of Startup Security Weekly!

Full Show Notes:

Visit for all the latest episodes!

Some random thoughts on Damian Green and those porn allegations

If you live in the UK then you might have noticed the somewhat bizarre furore over Damian Green MP and his alleged viewing of pornography on house his Parliament computer. Now, I don't know for certain if he did or didn't, but to put it in context his private email address also allegedly turned up in the Ashley Madison leak and on top of that there are sexual harassment allegations too. But

On "Advanced" Network Security Monitoring

My TaoSecurity News page says I taught 41 classes lasting a day or more, from 2002 to 2014. All of these involved some aspect of network security monitoring (NSM). Many times students would ask me when I would create the "advanced" version of the class, usually in the course feedback. I could never answer them, so I decided to do so in this blog post.

The short answer is this: at some point, advanced NSM is no longer NSM. If you consider my collection - analysis - escalation - response model, NSM extensions from any of those phases quickly have little or nothing to do with the network.

Here are a few questions I have received concerned "advanced NSM," paired with the answers I could have provided.

Q: "I used NSM to extract a binary from network traffic. What do I do with this binary?"

A: "Learn about reverse engineering and binary analysis."


Q: "I used NSM to extra Javascript from a malicious Web page. What do I do with this Javascript?"

A: "Learn about Javascript de-obfuscation and programming."


Q: "I used NSM to capture an exchange between a Windows client and a server. What does it mean?"

A: "Learn about Server Message Block (SMB) or Common Internet File System (CIFS)."


Q: "I used NSM to capture cryptographic material exchanged between a client and a server. How do I understand it?"

A: "Learn about cryptography."


Q: "I used NSM to grab shell code passed with an exploit against an Internet-exposed service. How do I tell what it does?"

A: "Learn about programming in assembly."


Q: "I want to design custom hardware for packet capture. How do I do that?"

A: "Learn about programming ASICs (application specific integrated circuits)."

I realized that I had the components of all of this "advanced NSM" material in my library. I had books on reverse engineering and binary analysis, Javascript, SMB/CIFS, cryptography, assembly programming, ASICs, etc.

The point is that eventually the NSM road takes you to other aspects of the cyber security landscape.

Are there *any* advanced area for NSM? One could argue that protocol analysis, as one finds in tools like Bro, Suricata, Snort, Wireshark, and so on constitute advanced NSM. However, you could just as easily argue that protocol analysis becomes more about understanding the programming and standards behind each of the protocols.

In brief, to learn advanced NSM, expand beyond NSM.

FTC Releases Agenda for Workshop on Consumer Informational Injuries

Recently, the Federal Trade Commission released the final agenda for a workshop being held on December 12, 2017, that will address the various consumer injuries that result from the unauthorized access to or misuse of consumers’ personal information.

Following opening remarks by Acting FTC Chairman Maureen K. Ohlhausen, the workshop will include four panel discussions on (1) the various types of injuries that result from information security incidents; (2) the factors used to assess such “informational injuries,” including the type and magnitude of the injury and the sensitivity of personal information involved in the incident; (3) how businesses and consumers evaluate the costs and benefits of sharing their information in light of potential benefits and injuries; and (4) the different methods used to assess and quantify informational injury and the challenges associated with such methods.

The workshop is open to the public and will be webcast live on the FTC’s website. Additional information on the workshop is available on the FTC’s website.

Paul’s Security Weekly #538 – Enjoy the Taste

Allison Miller joins us for an interview, Mick Douglas of the SANS Institute shows us how to feed common and default logs into ELK stacks, and we report on the latest security news on this episode of Paul's Security Weekly!

Full Show Notes:

Visit for all the latest episodes!

→Follow us on Twitter:

→Like us on Facebook: