All posts by Andy Green

Day Tripping in the Amazon AWS Cloud, Part I: Security Overview

Day Tripping in the Amazon AWS Cloud, Part I: Security Overview

I’ve been an occasional user of “the cloud”, a result of working out some data security ideas and threat scenarios in the Amazon EC2 environment. I played at being a system admin while setting up a domain with a few servers, and configuring Active Directory on a controller. My focus was on having a Windows environment that I could do some pen testing. But there’s more to Amazon Web Services (AWS) than EC2 computing environments, and I decided it’s the right time to started exploring more of its services, especially from a security perspective.

There’s No “There” In the Cloud

It’s natural for many in IT (and corporate bloggers with IT backgrounds) to gravitate to EC2. It’s basically a virtual IT facility: Windows operating systems available on different virtual hardware, a virtual network where you don’t have to deal with cables or routers, virtual firewalls, and other network security features.

However, the cloud is more than just a recreation of the IT server room! They call it Amazon Web Services for a reason: Amazon offers computing and storage services removed from their familiar settings.

Get your AWS Services, AWS Services! Lots of choices from the AWS console.

Need just a cloud file system for sharing and working with documents? There’s Amazon WorkDocs.

What if you just want a Windows desktop environment for your small- or mid-size company without having to deal with all the messy server infrastructure? Amazon WorkSpaces is just for you.

Going a step further, what if you just need enormous amounts of raw storage for web applications, and you don’t really care that it’s not organized as a Windows file system.  For that, there’s Amazon S3 buckets.

Need access to an Active Directory environment? Amazon Directory is just the ticket.

In a way the Amazon cloud — and others have similar offerings — is really a collection of separate OS services that are not tied to a specific facility or location: AWS is, of course, accessible everywhere.


The first level of security then is controlling access to these services. For that AWS, has, but what else, an identity and access management system or IAM. It’s called — wait for it— IAM.

When I set up my first AWS account to use EC2, I was given root access and the ability to add new users and groups. You can think of these additional users as power users who can create and modify services in the AWS console. They’re the elite admins of the AWS cloud world.

Users can be organized into groups. And if you’re wondering where the access part of IAM, it’s through something called policies. We wrote a little about these JSON-structured things with respect to S3 buckets.

My IAM crew: adminandy, dangeroudan, sleazysal, and sneakysam.

Just as you can associate a policy with a bucket,  you can do the same with IAM users. I’ll talk about setting policies for AWS console users in the next post, but let’s say that the Amazon policies ain’t very intuitive.

In my scenario, I set up a policy for an IAM group called Restricted, which allows users only read access to the EC2 part of the AWS — in other words, preventing them from launching or stopping Amazon instances. I added two users into the Restricted group: sleazysal and sneakysam.

By the way, there are additional security protections that Amazon provides for AWS users, including multi-factor authentication — currently supporting only special hardware fobs — and separate security credentials that, as we’ll see, can be used to access Amazon services from within computing environment through AWS’s special command line interface or cli.

Next time we’ll learn more about the not very pretty details of policies and something called Amazon resource names or arns, which is the way you refer to just about everything in the Amazon-verse.

Keep in mind that IAM covers users at the level of the AWS console. To set up ordinary users and their permissions, you’ll need to work with plain vanilla directory environments, such as Active Directory, which will examine next time through AWS Directory services.

A completely intuitive access policy for the Restricted user group.

Some Auditing

The AWS console really a portal for admins to launch EC2 instances and other computing environments, set up buckets, create databases, and of course monitor activities.

AWS does support auditing of AWS services and this is done through their CloudTrail service. You can think of it as something like Microsoft’s Event Log, but not nearly as pretty—hard to believe, I know! Further on in this series, we’ll learn about Amazon Athena, which is a tool to help you tame the raw Amazon event logs.

Raw and uncooked: Amazon CloudTrail logs. We’ll use Athena to help organize it.

Bucket Brigade

It’s a good time to look at a service that provides a useful real-world application, S3 buckets. Buckets have obvious use cases in storing huge image files for web applications, but it can store any corporate big-data file.

Or in the scenario I worked out, you can think of buckets as a bare-bones file locker (below).

I’m using buckets to store Word docs that I can share with other IAM users!

However, more appropriate for this type of file sharing activity is the Amazon Workdocs service, which we’ll explore next time.

In any case, with S3 buckets you can configure access control lists for different IAM users. And for more sophisticated permissioning, you can also up more granular policies.

By the way, it’s relatively easy to upload files and other digital objects into the S3 buckets using the Amazon browser interface. There are even third-party apps, one of which I experimented with, that turn this into more of a file locking and sync service.

With some free-ware apps, you can turn S3 buckets into a file sharing service. Btw, you’ll need to borrow a users’ IAM credentials to configure.

What about monitoring and auditing bucket resources?

Amazon does offer a service called Macie, which it describes as “using machine learning to automatically discover, classify, and protect sensitive data in AWS”.

After reviewing Macie, I’d say it’s a data classification service with an alerting function, kind of something like this and this. You could envision, say, some corporate application monthly uploading  huge amounts of transactional data from several different locations into an Amazon S3 bucket. Macie would then monitor the bucket data and let you know who’s accessing it as well as alerting when it finds sensitive PII.

Macie has the ability to let you set regular expressions to discover PII patterns,  and to classify text using static strings — for example, find the word “proprietary” or “confidential” in a document.

I’ll make the point again that Amazon’s built-in tools are not the most informative or easy-to-use. At a minimum, Macie gives you some insights into the Amazon bucket data store.

We’ll see later that it is possible to import S3 bucket objects, using the Amazon command line interface, into a standard Windows environment. And from there, with the right tools, you can do a far better analysis.

Alerts and data classification with Amazon’s Macie.

Let’s take a breath.

We’ve laid out some of the basics of the AWS environment, and looked at a few security and auditing ideas. Next time will take closer look at some of these AWS security tools.

And then we’ll start getting into more of the meat, by examining  practical IT environments — particularly Workspace and Workdocs — and see what Amazon offers in terms of security.

(Spoiler alert: there ain’t much beyond standard Windows functions.)

Till next time!

[White Paper] Let Varonis Be Your EU GDPR Guide

[White Paper] Let Varonis Be Your EU GDPR Guide

Everyone knows that when you travel to a strange new country, you need a guide. Someone to point out the best ways to move around, offer practical tips on local customs, and help you get the most out of your experience.

The EU General Data Protection Regulation (GDPR) is a country with its own quirky rules (and steep fines if you don’t do things just right). So may we suggest using Varonis to help you navigate the data compliance and regulatory landscape of GDPR-istan?

We’ve amassed lots of experience in the last few years, talking to GDPR experts, exploring the GDPR’s legal fine print, and analyzing the latest guidelines from the regulators. But you don’t have to go through the back pages of the IOS blog to find it all.

Instead we’ve conveniently distilled all of our extensive GDPR travel wisdom into our new white paper.

What’s the best route through GDPR? We’ve developed a practical three-step approach. First, we explain how to use Varonis to monitor and identify risks in your file system environment by finding sensitive personal data with overly permissive access policies. Second, we guide you on the preventive actions to protect your data based on the previous analysis by restricting access rights and eliminating stale or unused data. And third, we offer advice on how to sustain and maintain your GDPR compliance through actively detecting security threats and using this feedback to update your IT policies.

Don’t delay! Download our GDPR travel guide today, and bon voyage. 


New SEC Guidance on Reporting Data Security Risk

New SEC Guidance on Reporting Data Security Risk

In our recent post on a 2011 SEC cybersecurity guidance, we briefly sketched out what public companies are supposed to be doing in terms of informing investors about risks related to security threats and actual incidents. As it happens, late last month the SEC issued a further guidance on cybersecurity disclosures, which “reinforces and expands” on the older one. Coincidence?

Of course! But it’s a sign of the times that we’re all thinking about how to take into account data security risks in business planning.

Just to refresh memories, the SEC asked public companies to report data security risk and incidents that have a “material impact” for which reasonable investors would want to know about. The reports can be filed annually in a 10-K, quarterly in a 10-Q, or, if need be, in a current report or 8-K.

Nowhere in the SEC laws and relevant regulations do the words data security or security risk show up. Instead “material risks”, “materiality”, and “material information” are heavily sprinkled throughout —  lawyer-speak for business data and events worth letting investors know about.

Looking for Material

It’s probably best to quote directly from the SEC guidance on the subject of materiality:

The materiality of cybersecurity risks or incidents depends upon their nature, extent, and potential magnitude, particularly as they relate to any compromised information or the business and scope of company operations The materiality of cybersecurity risks and incidents also depends on the range of harm that such incidents could cause.  This includes harm to a company’s reputation, financial performance, and customer and vendor relationships, as well as the possibility of litigation or regulatory investigations …

An important point to make about the SEC language above is that it’s not about any one particular thing — report ransomware, or a DoS attack — but rather, as the lawyers say, you have to do fact-based inquiry. If you want to get more of a flavor of this kind of analysis, check out this legal perspective.

However, the SEC does provide some insight into evaluating  reportable security risks. The complete list is in the guidance, but here are a few that would be most relevant to IOS readers: the occurrence of prior cybersecurity incidents, the probability and magnitude of a future incident, the adequacy of preventive actions taken to reduce cybersecurity risk, the potential for reputational harm, and litigation, regulatory, and remediation costs.

What about the types of real-world incidents that would have to be disclosed or reported?

I searched and searched, and I did find an example buried in a footnote — wonks can peruse the amazing footnote 33. It’s probably not a great surprise to learn that investors would be interested in knowing when “compromised information might include personally identifiable information, trade secrets or other confidential business information, the materiality of which may depend on the nature of the company’s business, as well as the scope of the compromised information.”

In short, the SEC guidance is just telling us what we in data security already know: the exposure of sensitive PII, such as social security and credit card numbers, or passwords to bank accounts, or trade secrets regarding, say, a cryptocurrency application, are worthy not only if notifying security staff but investors as well.

Something Noteworthy: Security Policies and Procedures

Sure the typical regulatory verbiage can quickly put you into REM sleep, but occasionally there’s something new and noteworthy buried in the text.

And this latest SEC guidance does have some carefully worded advice regarding cybersecurity procedures and policies. The SEC “encourages” public companies to have them, and to review their compliance. It also asks companies to review their cybersecurity disclosure controls and procedures, and to make sure they are sufficient to notify senior management so they can properly report it.

It’s worth repeating that SEC rules and regulations cover general business risk, not specifically cybersecurity risk. The guidance recommends that companies evaluate this special risk and inform investors when the risks change, and of course let them know about material cybersecurity incidents

Musings on Cybersecurity Disclosures for Public Companies

In the US, unlike in the EU, there is no single federal data security and breach notification law that covers private sector companies. Sure, we do have HIPAA and GLBA for healthcare and financial, but there isn’t an equivalent to the EU’s GPDR or, say, Canada’s PIPEDA. I’m aware that we have state breach notification laws, but for the most part they’re limited in the PII they cover and have a fairly high threshold for reporting incidents.

However, with this last SEC guidance, we have, for the first time, something like a national data security rule of thumb — not an obligation but rather a strong suggestion —  to have data security controls and reporting in place.

The SEC guidance is based on what investors should be made aware of and wouldn’t necessarily cover serious cybersecurity risks and incidents that don’t have a material financial or business impact.

However, it’s certainly an indication that change is afoot, and US public companies should be thinking about upping their data security game before they’re ultimately required to do so through a future law.

Let’s just say they have been warned.

North Carolina Proposes Tougher Breach Notification Rules

North Carolina Proposes Tougher Breach Notification Rules

If you’ve been reading our amazing blog content and whitepaper on breach notification laws in the US and worldwide, you know there’s often a hidden loophole in the legalese. The big issue — at least for data security nerds — is whether the data security law considers mere unauthorized access of personally identifiable information (PII) to be worthy of a notification.

This was a small legal point until something called ransomware came along.

You have heard of ransomware, right?

It’s that low-tech, but deadly malware that accesses data and encrypts it. To get the data back, the victim has to send a couple of bitcoins to the digital extortionists.

Last year ransomware had more than a few high-profile victims in the US, as well as, of course, across the globe.

But at the US state level, the difference between access alone and access and acquisition — the legal verbiage for copying — in a notification law determines whether the breach is to be reported to local authorities.

Based on my own research, I could only find a few states for which a ransomware attack would have to be reported locally. I should add that even for states that allow for just unauthorized access of PII, there’s often an additional “harm threshold” to the consumer—financial or credit risk, for example— that would have to be met, and so would rule out a pure ransomware attack in which the data wasn’t copied.

After factoring this in, I found only three states for which a ransomware attack ipso facto  I finally get to use that phrase! — would require a notification: New Jersey, Connecticut, and Virginia.

You can look through these charts prepared by some law firms for yourself, and if you come up with other candidates, let me know!

North Carolina: Laboratory of Democracy!

But wait, a legislator in the great state of North Carolina along with the attorney general last month proposed a change to the statutory language defining a breach.

This tweak moves NC from a state that considers a breach to be unauthorized access and acquisition — see section 75-61 (14) of its statutes — to unauthorized access or acquisition.

Now NC joins the aforementioned club for which ransomware attacks will by themselves force companies to notify authorities and consumers.

The new law will also change the time window in which the data breach will have to be reported after discovery. Searching through a huge PDF table of state breach laws, I can say most if not all states ask that a breach be reported “without unreasonable delay.”

Obviously, these words can be subject to interpretation. The proposed NC law instead sets the time limit to just 15 days.

I’m not aware of any other state that has a specific deadline.

The new law also adds consumer-friendly language that makes credit freezes — remember the outcry after Equifax — free upon request. Up to five years of credit monitoring will also be free of charge.

The law is supposed to tighten the rules on fines as well.

We’ll have to wait for the legislation to be reviewed and approved before we have the final legal details.

We’ll keep you posted.

North Carolina Has Lots of Breaches

On looking at their 2017 annual breach report produced by their Department of Justice, I was surprised to learn that over 1000 breaches were reported in this state alone.

That’s an incredibly large number. For comparison purposes, take a peek at California’s breach report for the years 2012- 2015. The incident counts are dramatically smaller— 178 in 2015.

I’m not sure what explains the difference.  But perhaps NC clearly has lots of law-abiding businesses, especially consumer-facing ones holding PII.

By the way, the current NC law covers an extensive list of identifiers, not only the usual social security, driver’s license, and account numbers, but also PINs, online passwords, digital signatures, and email addresses. This broad PII definition may have something to do with the NC data breach reporting spike we’re seeing.

In any case, if you combine their generous list of PII and the newer  breach notification rules, then you’ll have to admit that NC has upped its digital security game and may even be number one, moving past the formidable California and its tough breach law.

And of course, go Wolfpack.

What to be a legal eagle amongst your IT security peers when it comes to breach notification laws and ransomware? Download our comprehensive white paper on this fascinating subject!

Adventures in Malware-Free Hacking, Part IV

Adventures in Malware-Free Hacking, Part IV

For this next post, I was all ready to dive into a more complicated malware-free attack scenario involving multiple stages and persistence. Then I came across an incredibly simple code-free attack — no Word or Excel macro required! — that far more effectively proves the underlying premise in this series: it ain’t that hard to get past the perimeter.

The first attack I’ll describe is based on a Microsoft Word vulnerability involving the archaic Dynamic Data Exchange (DDE) protocol. It was only very recently patched. The second one leverages a more general vulnerability with Microsoft COM and its object passing capabilities.

Back to the DDE Future

Does anyone remember DDE? Probably not. It was an early inter-process communication protocol that allowed apps and devices to pass data.

I’m a little familiar with it because I used to review and test telecom gear – well, someone had to do it. At the time, DDE let caller ids pass to CRM apps that would ultimately pop-up a customer contact record for a call center agents. Yeah, you had to connect an RS-232 cable between the phone and the computer. Those were the days!

As it turns out, at this late date, Microsoft Word still supports DDE.

What makes this attack effectively code-free is that you can access the DDE protocol directly from Windows field codes. (Hat tip to SensePost for researching and writing about it.)

Field codes are another ancient MS Word feature that lets you add dynamic text and a bit of programming into a document The most obvious example of this is the  page numbers, which can be inserted into a footer using this field code {PAGE \*MERGEFORMAT}. It allows page numbers to be magically generated.

Pro tip: you can access field codes from the text section of the Word ribbon.

I remember first discovering this Word feature as a young lad and being amazed.

Until the patch disabled it, Word supported a DDE field option. The idea was that DDE would let Word communicate with an app and then embed the output in the document. This was an early version of an idea –communicating with external apps — that was later taken over by COM, which will get to below.

Anyway, hackers realized that the DDE app can be, wait for it, a vanilla command shell! The command shell, of course, launches PowerShell and from there hackers can do just about anything.

In the screenshot below, you can see how I used the stealthy technique introduced a few posts back: the teeny PowerShell script in the DDE field downloads more PowerShell, which then starts the second phase of the attack.

Thank you Windows for warning us that an embedded DDEAUTO field sneakily launches a shell.

The preferred method is to use a variant, the DDEAUTO field, which automatically launches the script when the Word document is opened.

Let’s step back.

As a beginning hacker, you can send a scary phish mail, pretending to be from the IRS, and embed a DDEAUTO field with a teeny first-stage PS script. You don’t have to do any real coding with the MS macro library, as I did in the last post.

The CEO opens the Word doc, the embedded script is activated, and the hacker is effectively inside the laptop. In my case, the remote PS script pops up a message, but it could just as easily have launched a PS Empire client that would grant shell access.

And before you can say Macedonia, the hackers are the wealthiest teenagers in their village.

A shell was launched without any real coding. Even a Macedonian child could do this!

It’s so easy!

DDE and Fields

After some prodding, Microsoft disabled DDE in Word, but at first they said that the feature was just being misused. Their reluctance is somewhat understandable.

From what I can see (based on a sample of one data security company) field updating on opening a document is enabled and Word macros are disabled (with notification) by IT groups. By the way, you can find the relevant configuration settings in the Options section of Word.

However, even when field updating is enabled, Microsoft Word additionally prompts the user when a field is accessing remote data, as is the case with DDE (see above). Microsoft does indeed warn you.

But as we know from Dr. Zinaida Benenson, users will click away and ultimately activate the field update.

This is a roundabout way of thanking Microsoft for disabling the dangerous DDE feature.

How difficult is it to find an unpatched Windows environment?

For my own testing, I used AWS Workspaces to access a virtual desktop. And it was pretty easy to obtain an unpatched VM with MS Office that let me insert a DDEAUTO field.

No doubt there are, cough, more than a few corporate sites that still haven’t added the security patch.

The Mystery of Objects

Even if you have added their patch, there are other security holes in MS Office that let hackers accomplish something very similar to what we did with Word. In this next scenario, we’ll learn how to leverage Excel as the phish bait in a code-free attack.

To first understand this next scenario, let’s step a back a little to consider Microsoft Component Object Model or COM.

COM has been around since the 1990s and is described as a “language neutral, object-oriented component model” based on remote procedure calls. Read this StackOverflow post for basic COM definitions and terminology.

Generally, you can think of a COM app as Excel or Word or some other running binary executable.

As with all things more Microsoft, it’s more complicated than that.  It turns out that a COM app can alsobe a script—Jscript or VBScript. Technically, it’s called a scriptlet. You may have seen the .sct extension for a Windows file, which is the official suffix for scriptlets. These scriptlets are essentially scripting code encased in XML (below).

<?XML version="1.0"?>

<script language="JScript">

var r = new ActiveXObject("WScript.Shell").Run("cmd /k powershell -c Write-Host You have been scripted!");


Hacker and pen testers discovered that there are Windows utilities and apps that accept COM objects and, by extension, these user-crafted COM scriptlets.

Let’s call it a day!

Your homework is to watch this Derbycon video from 2016, which explains how hackers and pen testers have taken advantage of scriptlets. And also read this post on scriptlets and something called monikers.

To get ahead of the story, I can pass a scriptlet to a Windows utility, written in VBS, known as pubprn, which is buried in C:\Windows\system32\Printing_Admin_Scripts. By the way, there are other Windows utilities that take objects as parameters; we’ll just look at this particular one first.

It’s only natural that you can launch a shell from a printing script. Go Microsoft!

For my own testing I crafted a simple remote scriptlet that launches a shell and prints a “boo” message. Effectively, pubprn instantiates the scriptlet object thereby allowing the VBScript code to launch a shell.

This technique provides obvious advantages to hackers who want to “live off the land” and lurk in your system undetected

In the next post, I’ll explain how COM scriptlets can be exploited by hackers within an Excel spreadsheet.




Post-Davos Thoughts on the EU NIS Directive

Post-Davos Thoughts on the EU NIS Directive

I’ve been meaning to read the 80-page report published by the World Economic Forum (WEF) on the global risks humankind now faces. They’re the same folks who bring you the once a year gathering of the world’s bankers and other lesser humanoids held at a popular Swiss ski resort. I was told there was an interesting section on … data security.

And there was. Data security is part of a report intended to help our world leaders also grapple with climate change, nuclear annihilation, pandemics, economic meltdowns, starvation, and  terrorism.

How serious a risk are cyber attacks?

In terms of impact, digital warfare makes the WEF top-ten list of global issues, ranking in the sixth position, between water and food crises, and beating out the spread of infectious diseases in the tenth position. It’s practically a fifth horsemen of the apocalypse.

Some of the worrying factoids that the WEF brought to the attention of presidents, prime ministers, chancellors, and kings was that in 2016 over 350 million malware variants were unleashed on the world, and that by 2020, malware may potentially finds its way to over 8.4 billion IoT devices.

There are about 7.6 billion of us now, and so we’ll soon be outnumbered by poorly secured internet connected silicon-based gadgets. It’s not a very comforting thought.

The WEF then tried to calculate the economic damage of malware. One study they reference puts the global cost at $8 trillion over the next five years.

The gloomy WEF authors single out the economic impact of ransomware. Petya and NotPetya were responsible for large costs to many companies in 2017. Merck, FedEx, and Maersk, for example, each reported offsets to their bottom line of over $300 million last year as a result of NotPetya attacks.

Systemic Risk: We’re All Connected

However, the effects of malware extend beyond economics. One of the important points the report makes is that hackers are also targeting physical infrastructure.

WannaCry was used against the IT systems of railway providers, car manufacturers, and energy utilities. In other words, cyberattacks are disrupting things from happening in the real-world: our lights going out, our transportation halted, or factory lines shut down all because of malware.

And here’s where the WEF report gets especially frightening. Cyber attacks can potentially start a chain reaction of effects that we humans are not good at judging. They call it “systemic risk”

They put it this way:

“Humanity has become remarkably adept at understanding how to mitigate countless conventional risks that can be relatively easily isolated and managed with standard risk management approaches. But we are much less competent when it comes to dealing with complex risks in systems characterized by feedback loops, tipping points and opaque cause-and-effect relationships that can make intervention problematic.”

You can come up with your own doomsday scenarios – malware infects stock market algorithms leading to economic collapse and then war – but the more important point, I think, is that our political leaders will be forced to start addressing this problem.

And yes I’m talking about more regulations or stricter standards on the IT systems used to run our critical infrastructure.

NIS Directive

In the EU, the rules of the road for protecting this infrastructure are far more evolved than in the US. We wrote about the Network and Information Security (NIS) Directive way back in 2016 when it was first approved by the EU Parliament.

The Directive asks EU member states to improve co-operation regarding cyber-attacks against critical sectors of the economy — health, energy, banking, telecom, transportation, as well as some online businesses — and to set minimum standards for cyber security preparedness, including incident notification to regulators. The EU countries had 21 months to “transpose” the directive into national laws.

That puts the deadline for these NIS laws at May 2018, which is just a few months away. Yes, May will be a busy month for IT departments as both the GDPR and NIS go into effect.

For example, the UK recently ended the consultation period for its NIS law. You can read the results of the report here. One key thing to keep in mind is that each national data regulator or authority will be asked to designate operators of “essential services”, EU-speak for critical infrastructure. They have 6-months starting in May to do this.

Anyway, the NIS Directive is a very good first step in monitoring and evaluating malware-based systemic risk. We’ll keep you posted as we learn more from the national regulators as they start implementing their NIS laws.



Adventures in Malware-Free Hacking, Part III

Adventures in Malware-Free Hacking, Part III

After yakking in the last two posts about malware-free attack techniques, we’re ready to handle a dangerous specimen. The Hybrid Analysis site is the resource I rely on to find these malware critters. While the information that HA provides for each sample —system calls, internet traffic, etc. — should be enough to satisfy a typical IT security pro, there is some value in diving into one of these heavily obfuscated samples to see what’s actually going on.

If you’re playing along at home, I suggest doing this in a sandbox, such as AWS, or if you’re working on your own laptop, just make sure to comment out the system calls that launch PowerShell.

Into the Obfuscated VBA Muck

The malware I eventually found in Hybrid Analysis is a VBA script that was embedded in a Word doc. As I mentioned last time, to see the actual script, you’ll need Frank Boldewin’s OfficeMalScanner.

After extracting the script, which I gave you a peek at in the last post, I decided to load the thing into the MS Word macro library. And then — gasp  —  stepped through it using the built-in debugger.

My goal was to better understand the obfuscations: to play forensic analyst and experience the frustrations involved in this job.

If you’re going into one of these obfuscated scripts for the first time in a debugger, you’ll likely be gulping espressos as you make your way through the mind numbing complex code and watch blankly as you look at the variable L_JEK being assigned the string “77767E6C797A6F6”.

It’s that much fun.

What I learned with this obfuscated VBA script is that only a very small part of it does any of the real work. Most of the rest is there to throw you off trail.

Since we’re getting into the nitty-gritty, I took a screen shot of the teeny part of the code that performs the true evil work of setting up the PowerShell command line that is ultimately launched by the VBA macro.

Tricky: just take the hex value and subtract 7 for the real ascii.

It’s very simple. The VBA code maintains a hex representation of the command line in a few variables and then translates it to a character string. The only “tricky” part is that hex values have been offset by 7.

So for example, the first part of the hex string comes from L_JEK (above). If you take 77 and subtract 7, you’ll get a hex 70. Do the same for 76 and you have obtain hex 6F. Look these up in any ascii table, and you’ll see it maps to the first two letter of “powershell”.

This ain’t a very clever obfuscation, but it doesn’t have to be!

All it has to accomplish is getting past virus scanners searching for obvious keywords or their ascii representations.  And this particular sample does this well enough.

Finally, after the code builds the command line, it then launches it through the CreateProcess function (below).

Either comment out system calls or set a breakpoint before it.

Think about it. A Word doc was sent in a phish mail to an employee. When the doc is opened, this VBA script  automatically launches a PowerShell session to start the next phase of the attack. No binaries involved, and the heavily obfuscated scripts will evade scanners.


To further my own education, I pulled out another macro from Hybrid Analytics (below) just to see what else is out there. This second one effectively does the same thing as the code above.

Secret code embedded in VBA.

It’s a little more clever in how it builds the command line. There’s a decode function, called “d”, that filters out characters from a base string by comparing against a secondary string.

It’s a high-school level idea, but it gets the job done: it will evade scanners and fool IT folks who are quickly looking at any logs for unusual activities.

Next Stop

In my first series of post on obfuscation, I showed that Windows Event logging captures enough details of PowerShell sessions — that is, if you enable the appropriate modules — to do a deep analysis after the fact.

Of course, the brilliance of malware-free attacks is that it’s hard to determine whether a PowerShell script at run-time is doing anything evil through a basic parsing of the command line by scanning event logs.


PowerShell sessions are being launched all the time, and one hacker’s PowerShell poison can be close to another IT admin’s PowerShell power tool. So if you want to alert every time a script downloads something from the Internet, you’ll be sending out too many false positives.

Of course, this leads to this blog’s favorite topic: the failure of perimeter defenses to stop phishing and FUD malware, and the power of User Behavior Analytics.

In short: it’s a losing battle trying to stop hackers from getting past perimeter defenses. The better strategy is to spot unusual file access and application behaviors, and then respond by de-activating accounts or taking another breach response measure.

That’s enough preaching for the day. In the next post, we’ll take a closer look at more advanced types of malware-free attacks.

Continue reading the next post in "Malware-Free Hacking"

SEC Guidance on Cyber Incidents and Risk Disclosures

SEC Guidance on Cyber Incidents and Risk Disclosures

You know, because you read it here in the IOS blog, that in the US data breach reporting is not nearly as strict and comprehensive as in the EU. At the federal level, we have tough rules for reporting incidents involving medical data (HIPAA) and less tough ones for financial data (GLBA). At the state level, there is a patchwork of notification laws for the exposure of a select set of identifiers. And that’s it!

Well not quite.

Realizing that cyber incidents can have an impact on the corporate bottom line, the SEC released an official guidance a few years back on reporting cyber security events to investors. For all my financial accountant readers, this information can be found here.

Starting in 2012, publicly traded companies are supposed to acknowledge the consequence of cyber catastrophes in their SEC filings. In describing these incidents, they need to take into account both the indirect and direct costs involved in the cost of remediation, litigation, reputation damage, and lost revenues.

When, What, and Where to Report

In general, you’re supposed to report only incidents that will have a “material impact”. This is lawyer talk for eliminating simple hacks — a hacker got into a single email account — while covering news  that a “reasonable” investor would want to know about: for example, 100 million social security numbers were taken take by a stealthy APT group.

However, there are exceptions.

If a cyber incident was widely reported in the news, then the company needs to file with the SEC regardless of the seriousness of the incident. Also any breaches that involved notifying a state or federal (HIPAA, GLBA, COPAA) regulator would require an SEC filing.

What information do you need to disclose?

You have some wiggle room. The SEC recognizes that too much detail might compromise an ongoing investigation. You should describe at a high level the nature of the breach, and in addition, an estimate of the number of people impacted, the categories of affected data, the remediation efforts that were taken, and the plans to prevent future incidents.

At a minimum, companies will need to report overall cyber risks they face in their annual 10-Ks. For a serious cyber incident, they should file it as an 8-K immediately — although there’s no specific time window — instead of waiting for the quarterly report.

I’m a blogger, not a lawyer, so if you want legal advice, read this to learn what real attorneys have to say on this subject.

Real-World 8-K Filing

Want to get inspired by an actual 8-K material filing for a cyber event?

Gaze on the screenshot below showing the beginning of an cyber incident description for a health company.

They exist: SEC 8-K filings for data breaches.

One last point about these filings. The SEC’s Edgar system, where all this information is reported and kept, in theory should be  a source of information regarding breach incidents for public companies.

Useful to know! At least for security bloggers and other compliance wonks.

Adventures in Malware-Free Hacking, Part II

Adventures in Malware-Free Hacking, Part II

I’m a fan of the Hybrid Analysis site. It’s kind of a malware zoo where you can safely observe dangerous specimens captured in the wild without getting mauled. The HA team runs the malware in safe sandboxes and records systems calls, file created, and internet traffic, displaying the results for each malware sample. So you don’t have to necessarily spend time puzzling over or even, gulp, running the heavily obfuscated code to understand the hackers’ intentions.

The HA samples I focused on use either encasing JavaScript or Visual Basic for Applications (VBA) scripts, which are the “macros” embedded in Word or Excel documents attached to phish mails. These scripts then launch a Powershell session on the victim’s computer. The hackers usually send to the PowerShell a Base64-encoded stream. It’s all very sneaky and meant to make it difficult for monitoring software to find obvious keywords to trigger on.

Mercifully, the HA teams decodes Base64 and displays the plain text. In effect, you don’t really need to focus on how these scripts work because you’ll see the command line of the spawned processes in HA’s “Process launched” section. The screenshots below illustrate this:

Hybrid Analysis captures the Base64-encoded commands sent to a PowerShell process …

… and then decodes it for you. #amazing

In the last post, I created my own mildly obfuscated JavaScript container to launch a PowerShell session.

Then my script, like a lot of PowerShell-based malware, downloads a second PowerShell script from a remote web site. To do this safely, my dudware downloads a harmless 1-line of PS to print out a message.

This being the IOS blog we never, ever do anything nice and easy. Let’s take my scenario a step further.

PowerShell Empire and Reverse Shells

One of the goals of this exercise is to show how (relatively) easy it is for a hacker to get around legacy perimeter defenses and scanning software. If a non-programming security blogger such as myself can cook up potent fully undetected or FUD malware in a couple of afternoons (with help from lots of espressos), imagine what a smart Macedonian teenager can do!

And if you’re an IT security person who needs to convince a stubborn manager – I know they don’t exist, but let’s say you have one – that the company needs to boost its secondary defenses, my malware-free attack example might do the trick.

I’m not suggesting you actually phish management, though you could. If you take this route and use my scripts, the message that prints on their laptops would count as a cybersecurity “Boo!”.  It may be effective in your case.

But if your manager then challenges you by saying, “so what”, you can then follow up with what I’m about to show you.

Hackers want to gain direct access to the victim’s laptop or server. We’ve already reviewed how Remote Access Trojans (RATs) can be used to sneakily send and download files, issue commands, and hunt for valuable content.

However, you don’t have to go that far. It’s very easy to gain shell access, which for certain situations might be all a hacker requires – to get in and get out with a few sensitive files from the CEO’s laptop.

Remember the amazing PowerShell Empire post-exploitation environment that I wrote about?

It’s a, cough, pen testing tool, that among its many features lets you easily create a PowerShell-based reverse shell. You can more learn more about this on the PSE site.

Let’s take a quick walk through. I set up my malware testing environment within my AWS infrastructure so I can work safely. And you can do the same to show management a PoC (and not get fired for running grey area hacking software on the premises.)

If you bring up the main console of PowerShell Empire, you’ll see this:

First, you configure a listener on your hacking computer. Enter the commander “listener”, and follow up with “set Host” and the IP address of your system — that’s the “phone home” address for the reverse shell. Then launch the listener process with an “execute” command (below). The listener forms one end of your shell connection.

For the other, you’ll need to generate agent-side code, by entering the “launcher” command (below). This generates code for a PowerShell agent — note that it’s Base64-encoded — and will form the second stage of the payload. In other words, my JavaScript encasing code from last time will now pull down the PowerShell launcher agent, instead of the harmless code to output “Evil Malware”, and  connect to the remote agent in reverse-shell fashion.

Reverse-shell magic. This encoded PowerShell command will connect back to theremote listener and set up a shell.

To run this experiment, I played the part of an innocent victim and clicked on Evil.doc, which is  the JavaScript I set up last time. Remember? The PowerShell was configured to not pop-up a window, so the victim won’t notice anything unusual is going on. However, if you look at the Windows Task Manager, you’ll see the background PowerShell process, which may not trigger alarms ’cause it’s just PowerShell, right?

Now when you click on Evil.doc, a hidden background process will connect to the PowerShell Empire agent.

Putting on my hacker-pentester hat, I returned to my PowerShell Empire console, and now see the message that my agent is active.

I then issued an interact command to pop up a shell in PSE. And I’m in! In short: I hacked into the Taco server that I set-up once upon a time.

What I just described is not a lot of work. If you’re doing this for kicks during a long lunch hour or two to improve your infosec knowledge, it’s a great way to see how hackers get around border security defenses and stealthily lurk in your system.

And IT managers who believe that they’ve built breach-proof defense may, fingers crossed, find this enlightening – if you can convince them to sit down long enough.

Let’s Go Live

As I’ve been suggesting, real-world malware-free hacking is just variation on what I just presented. To get a little bit of a preview of the next post, I searched for Hybrid Analysis specimen that works in a similar fashion to my made-up sample. I didn’t have to search very long – there’s lots of this attack technique on their site

The malware I eventually found in Hybrid Analysis is a VBA script that was embedded in a Word doc. So instead of faking the doc extension, which I did for my JavaScript example, this malware-free malware is really, truly, a Microsoft document.

If you’re playing along at home, I picked this sample, called rfq.doc.

I quickly learned you often can’t directly pull out the actual evil VBA scripts. The hackers compressed or hid them, and they won’t show up in Word’s built-in macro tools.

You’ll need a special tool to extract it. Fortunately, I stumbled upon Frank Boldewin’s OfficeMalScanner. Danke, Frank.

Using this tool, I pulled out the heavily obfuscated VBA code. It looks a little bit like this:

Obfuscation done by pros. I’m impressed!

Attackers are really good at obfuscation, and my efforts in creating Evil.doc was clearly the work of a rank amateur.

Anyway, next time we’ll get out our Word VBA debuggers, delve into this code a little bit, and compare our analysis to what HA came up with it.

Continue reading the next post in "Malware-Free Hacking"

Adventures in Malware-Free Hacking, Part I

Adventures in Malware-Free Hacking, Part I

When I first started looking into the topic of hackers living off the land by using available tools and software on the victim’s computer, little did I suspect that it would become a major attack trend. It’s now the subject of scary tech headlines, and security pros are saying it’s on the rise. It seems like a good time for a multi-part IOS blog series on this subject.

Known also as file-less or zero-footprint attacks, malware-free hacking typically uses PowerShell on Windows systems to stealthily run commands to search and exfiltrate valuable content. To IT security team monitoring for hacker activities, file-less attack are very difficult to spot, often evading virus scanners and other signature-based detection systems.

In short, legacy defense can’t really deal with this style of attack. Of course there is, ahem, security software that will spot the malware activity on file systems.

Anyway, I’ve written about  some of these ideas before in my PowerShell obfuscation series, but more from a theoretical view. Then I discovered the Hybrid Analysis site, where you can find uploaded samples of malware captured in the wild.

Wild PowerShell

I thought it would be a great place to look for some file-less malware specimens. I wasn’t disappointed. By the way, if you want to go on your own malware hunting expedition, you’ll have to be vetted by the Hybrid Analysis folks so they know you’re doing white hat work. As a blogger who writes about security, I passed with flying colors. I’m sure you will too.

Besides having samples, they also provide great insights into what the malware is doing. Hybrid Analysis runs the submitted malware in their own sandbox, and monitors for system calls, processes launched, and Internet activity, as well as pulling out suspicious text strings.

For binaries and other executables in particular, where you can’t even look at the actual high-level code, this container technique allows HA to decide whether the malware is evil or merely suspicious based on its run-time activity. And then they’ll rate the sample.

For the malware-free PowerShell and other scripting samples (Visual Basic, JavaScript, etc.) I was looking for, I could see the actual code. For example, I came across this PowerShell creature:

You too can run base64 encoded PowerShell to evade detection. Note the use of the Noninteractive parameter in this live sample from Hybrid Analysis.

If you’ve read my obfuscation posts, you’ll know that the -e parameter indicates that what follows is base64 encoded. By the way Hybrid Analysis helpfully provides the decoded PowerShell as well. If you want to try decoding base64 PS on your own, you can run this command to do the work: $DecodedText = [System.Text.Encoding]::Unicode.GetString([System.Convert]::FromBase64String($EncodedText))

Getting in Deeper

I decoded the script using this technique, and you can see the resulting plaintext PowerShell malware below.

Note the time sensitivity of this PS malware, and the use of cookies to pass back more information. I modified this real-world sample in my own testing.

I was feeling a little nervous handling this live malware on my own laptop. Attention Varonis IT Security: please note that I worked with an on-line PowerShell console and also my own separate AWS environment. Got that, IT?

Anyway, we’ve seen this particular attack style before —  in the PS obfuscation series — wherein the base64 encoded PS is itself pulling more of the malware from another site, creating a .Net Framework WebClient object to do the heavy lifting.

Why this approach?

For security software that’s scanning the Windows event log, the base64 encoding prevents text-based pattern matching from doing some easy detection – matching on say the string “WebClient”. And since the real evil part of the malware is then downloaded and injected into the PS app itself, this approach completely evades detection. Or so I thought.

It turns out with more advanced Windows PowerShell logging enabled – see my post — you can effectively see the downloaded string in the event log. I commend Microsoft (as did others!) for this added level of logging.

However, hackers then responded by base64 encoding the downloaded PowerShell from the remote site, so it would then show up in the Windows event log like the encoded sample above. Makes sense, right?

Adding More Scripting Sauce

The real-world samples in Hybrid Analysis then take this idea a step further. Hackers cleverly hide this PowerShell attack in Microsoft Office macros written in Visual Basic and in other scripts. The idea is that the victim receives a phish mail from say, FedEx, with a Word doc described as an invoice. She then clicks on the doc that then launches a macro that then eventually launches the actual PowerShell.

Often times, the Visual Basic script itself is obfuscated so that it evades virus and malware scanners.

Yes, it’s complicated and evil. And I’m only doing a very shallow dive.

In the spirit of the above, I decided as a training exercise to encase the above PowerShell within some obfuscated JavaScript. You can see the results of my hacking handiwork:

Obfuscated JavaScript hiding the encoded PowerShell. Real hackers, of course, do this better than me.

There is one technique I borrowed from “in the wild” samples: the use of  Wscript.Shell to launch the actual encoded PowerShell. It’s the way you get out of the script environment to interact with the rest of the system.

By the way, JavaScript is on its own a vehicle for delivering malware. Many Windows environment have by default the Windows Script Host, which will directly run JS.  In this scenario, the encasing JS malware is attached as a file with a .doc.js suffix.  Windows will only show the first suffix, so it will appear to the victim as a Word doc.  The JS icon is rendered as a scroll-like graphic. Not surprisingly, people will click on this attachment thinking it’s a document.

Don’t click on that JS icon that resembles a scroll! It will download evil malware. You’ve been warned.

For my own encasing JavaScript malware, I modified the PowerShell sample above to download a script from a web site I control. The remote PS script merely prints out “Evil Malware”.

Not very evil.

Of course, real hackers are interested in gaining access to a laptop or server, say, through a shell..

In the next post, I’ll show how to do this by using PowerShell Empire, which I wrote about once upon a time.

We probably dove a little too deep for an introductory post, so I’ll let you catch your breath and cover some of this again next time. And then we can start grokking real-world malware-free attacks with the preliminaries out of the way.


Continue reading the next post in "Malware-Free Hacking"

Our Most Underappreciated Blog Posts of 2017

Our Most Underappreciated Blog Posts of 2017

Another year, another 1293 data breaches involving over 174 million records. According to our friends at the Identity Theft Resource Center, 2017 has made history by breaking 2016’s record breaking 1091 breaches. Obviously it’s been a year that many who directly defend corporate and government systems will want to forget.

Before we completely wipe 2017 from our memory banks, I decided to take one last look at the previous 12 months worth of IOS posts.  While there are more than a few posts that did not receive the traffic we had hoped, they nevertheless contained some really valuable security ideas and practical advice.

In no particular order, here are my favorite underachieving posts of the 2017 blogging year.


Wade Baker Speaks – We did a lot of interviews with security pros this year —researchers, front-line IT warriors, CDOs, privacy attorneys.  But I was most excited by our chat with Wade Baker. The name may not be familiar, but for years Baker produced the Verizon DBIR, this blog’s favorite source of breach stats. In this transcript, Wade shares great data-driven insights into the threat environment, data breach costs, and how to convince executives to invest in more data security.

Ann Cavoukian and GDPR – It’s hard to believe that the General Data Protection Regulation (GDPR) is only a few months away. You can draw a line from Cavoukian’s Privacy by Design ideas to the GDPR.  For companies doing business in the EU, it will soon be the case that PbD will effectively be the law. Read the Cavoukian transcript to get more inspired.

Diversity and Data Security – The more I learn about data security and privacy, the more I’m convinced that it will “take a village”.  The threat is too complex for it to be pigeon-holed into an engineering problem. A real-world approach will involve multiple disciplines — psychology, sociology, law, design, red-team thinking, along with computer smarts. In this interview with Allison Avery, Senior Organizational Development & Diversity Excellence Specialist at NYU Langone Medical Center, we learn that you shouldn’t have preconceived notions of who has the right cyber talents.

Infosec Education

PowerShell Malware –  PowerShell is a great next-generation command line shell. In the last few years, hackers have realized this as well and are using PowerShell for malware-free hacking. A few months ago I started looking into obfuscated PowerShell techniques, which allow hackers to hide the evil PowerShell and make it almost impossible for traditional scanners to detect. This is good information for IT people who need to get a first look at the new threat environment. In this two-part series, I referenced a Black Hat presentation given by Lee Holmes — yeah, that guy!  Check out Lee’s comment on the post.

Varonis and Ransomware – This was certainly the year of weaponized ransomware with WannaCry, Petya, et. al. using the NSA-discovered EternalBlue exploit to hold data hostage on a global scale. In this post, we explain how our DatAlert software can be used to detect PsExec, which is used to spread the Petya-variant of the malware. And in this other ransomware post, we also explain how to use DatAlert to detect the mass encryption of files and to limit your risks after ransomware infection.

PowerShell as a Cyber Monitoring Tool – I spent a bit of effort in this long series explaining how to use PowerShell to classify data and monitor events — kind of a roll-your-own Varonis. Alas, it didn’t get the exposure I had hoped. But there are some really great PowerShell tips, and sample code using Register-EngineEvent to monitor low-level file access events. A must read if you’re a PowerShell DIY-er.


NIS, the Next Big EU Security Law – While we’ve all been focused on the EU GDPR, there’s more EU data security rules that go into effect in 2018. For example, The Network and Information Security (NIS) Directive.  EU countries have until July 2018 to “transpose” this directive into their own national laws. Effectively, the NIS Directive asks companies involved in critical infrastructure — energy, transportation, telecom, and Internet — to have in place data security procedures and to notify regulators when there’s a serious cyber incident. Unlike the GDPR, this directive is not just about data exposure but covers any significant cyber event, including DoS, ransomware, and data destruction.

GDPR’s 72-Hour Breach Notification – One particular GDPR requirement that’s been causing major headaches for IT is the new breach notification rules. In October, we received guidelines from the regulators. It turns out that there’s more flexibility than was first thought. For example, you can provide EU regulators partial information in the first 72-hours after discovery and more complete information as it becomes available. And there are many instances where companies will not have to additionally contact individuals if the personal data exposed is not financially harmful. It’s complicated so read this post to learn the subtleties.

By the way, we’ve been very proud of our GDPR coverage. At least one of our posts has been snippetized by Google, which means that at least Google’s algorithms think our GDPR content is the cat’s meow. Just sayin’.


Man vs. Machine – Each week Cindy Ng leads a discussion with a few other Varonians, including Mike Buckbee, Killian Englert, and Kris Keyser. In this fascinating podcast, Cindy and her panelists take on the question of ethics in software and data security design. We know all too well that data security is often not thought about when products are sold to consumers — maybe afterwards after a hack. We can and should do a better job in training developers and introducing better data laws, for example the EU GDPR. But what is “good enough” for algorithms that think for themselves in, say,  autonomous cars?  I don’t have the answer, but is what great fun listening to this group talk about this issue.

Cybercrime Startups – It’s strange at first to think of hackers as entrepreneurs and their criminal team as a startup. But in fact there are similarities, and hacking in 2017 starts looking like a viable career option for some. In this perfect drive-time podcast, our panelists explore the everyday world of the cybercrime startup.

Fun Security Facts

Securing S3 –  As someone who uses Amazon Web Services (AWS) to quickly test out ideas for blog posts, I’m a little in awe of Amazon’s cloud magic and also afraid to touch many of the configuration options. Apparently, I’m not the only one who gets lost in AWS since there have been major breach involving its heavily used data storage feature, known as S3. In this post, Mikes covers S3’s buckets and objects and explains how to set up security policies. Find out how to avoid being an S3 victim in 2018!