All posts by Andy Green

[Podcast] Dr. Zinaida Benenson and the Human Urge to Click

[Podcast] Dr. Zinaida Benenson and the Human Urge to Click

Leave a review for our podcast & we'll send you a pack of infosec cards.

Dr. Zinaida Benenson is a researcher at the University of Erlangen-Nuremberg, where she heads the “Human Factors in Security and Privacy” group. She and her colleagues conducted a fascinating study into our spam clicking habits. Those of you who attended Black Hat last year may have heard her presentation on How to Make People Click on a Dangerous Link Despite their Security Awareness.

As we’ve already pointed on the IOS blog, phishing is a topic worthy of serious research. Her own clever study adds valuable new insights. Benenson conducted an experiment in which she phished college students (ethically, but without their direct knowledge) and then asked them why they clicked.

In the first part of our interview with Benenson, we discuss how she collected her results, and why curiosity seems to override security concerns when dealing with phish mail. We learned from Benenson that hackers take advantage of our inherent curiosity. And this curiosity about others can override the analytic security-aware part of our brain when we’re in a good mood!

So feel free to (safely) click on the above podcast to hear the interview.

New Post-Brexit UK Data Law: Long Live the GDPR!

New Post-Brexit UK Data Law: Long Live the GDPR!

The UK is leaving the EU to avoid the bureaucracy from Brussels, which includes having to comply with the General Data Protection Regulation (GDPR). So far, so good. However, since the EU is so important to their economy, the UK’s local data laws will in effect have to be at very high-level — basically, GDPR-like — or else the EU won’t allow data transfers.

Then there is the GDPR’s new principal of extra-territoriality or territorial scope — something we’ve yakked a lot about in the blog — which means non-EU countries will still have to deal with the GDPR.

Finally, as a practical matter the GDPR will kick in before the UK formally exits the EU. So the UK will be under the GDPR for at least a year or more no matter what.

Greater legal minds than mine have already commented on all this craziness.

The UK government looked at the situation, and decided to bite the bullet, or more appropriately eat the cold porridge

Last week, the UK released a statement of intent that commits the government to scrapping their existing law, the Data Protection Act, and replacing it with a new Data Protection Bill.

Looks Familiar

This document is very clear about what the new UK data law will look like. Or as they say:

Bringing EU law into our domestic law will ensure that we help to prepare the UK for the future after we have left the EU. The EU General Data Protection Regulation (GDPR) and the Data Protection Law Enforcement Directive (DPLED) have been developed to allow people to be sure they are in control of their personal information while continuing to allow businesses to develop innovative digital services without the chilling effect of over-regulation. Implementation will be done in a way that as far as possible preserves the concepts of the Data Protection Act to ensure that the transition for all is as smooth as possible, while complying with the GDPR and DPLED in full.

In effect, the plan is to have a law that will mirror the GDPR, allowing UK companies to continue to do business as usual

The Bill will include the GDPR’s new privacy rights for individuals: the “right to be forgotten”, data portability, and right to personal data access. And it will contain the GDPR’s obligations for controllers to report breaches, conduct impact assessments involving sensitive data, and designate data protection officers.

What about the GDPR’s considerable fines?

The UK has also gone along with the EU data law’s tiered structure – fines of up to 4% of global turnover (revenue).

Her Majesty’s Government may have left the EU, but EU laws for data privacy and security will remain. The GDPR is dead, long live the GDPR!

GDPR Resources

Of course, the new Bill will have its own articles, with different wording and numbering scheme than the GDPR. And legal experts will  no doubt find other differences — we’ll have to wait for the new law. Having said that, our considerable resources on the EU data law remain relevant.

For UK companies reading this post and looking for a good overview, here are three links that should help:


For a deeper dive into the GDPR, we offer for your edification these two resources:

And feel free to search the IOS blog and explore the GDPR on your own!

Working With Windows Local Administrator Accounts, Part III

Working With Windows Local Administrator Accounts, Part III

One point to keep in mind in this series is that we’re trying to limit the powers that are inherent in Administrator accounts. In short: use the Force sparingly. In the last post, we showed it’s possible to remove the local Administrator account and manage it centrally with GPOs. Let’s go over a few things I glossed over last time, and discuss additional ways to secure these accounts.

Restricted Groups: Handle with Care

In my Acme environment, the Restricted Groups GPO is used to push out a domain-level group to the local Administrators group in each of the OUs: one policy for Masa and Pimiento, another for Taco. It’s a neat trick, and for larger domains, it saves IT from having to do this through scripts or spending time performing this manually.

To refresh memories, here’s how my GPO for Restricted Groups looked:

Replaces local  Administrators groups with Acme-IT-1.

By using the “Member of this group” section, I’m forcing the Group Policy Manager to replace, not add, Acme-IT-1 to each local Administrators group in my OU. The problem is you may overwrite existing group members, and you don’t know what services or apps depend on certain local accounts being there.

You’ll likely want to evaluate this idea out on a small sample. This may involve more work— local scripts to re-add those accounts, or possibly creating new domain level accounts that can be added into the above.

Or if you prefer, you can use Group Policy Preferences (GPP). It has an update option for adding a new group (or user) under a local Administrator account (below). We know not to use GPP to reset local Administrator account passwords, right?

With GPP, you can add Acme-IT-2 to the local Administrators groups.

Even More Secure

There is, sigh, a problem in using Restricted Groups and centrally managed domain-level Administrator accounts. Since all users by default,  are under Domain Users, it means that local Administrators can be exploited through Pass-the-Hash (PtH) techniques — get NTLM hash, and pass to psexec — to log on to any other machine in the network.

This was the conundrum we were trying to grapple with in the first place! Recall: local Administrators are usually given simple — easily guessable or hackable — passwords which can then be leveraged to log on to other machines. We wanted to avoid having an Administrator-level local account that can be potentially used globally.

As I mentioned in the second post, this security hole can be addressed by creating a GPO – under User Rights Assignment — to restrict network access all together. This may not be practical in all cases for Administrators accounts.

Another possibility is to limit the machines that these domain-level Administrator accounts can log into. And again we make a lifeline call to User Rights Assignment, but this time enlisting the “Allows log on locally” property, adding the Acme-IT-1 Administrators group (below). We would do the same for the other OU in the Acme domain, but adding the Acme-IT-2 group.

This GPO prevents accounts from logging on to machines outside the specified domain. So even if a clever hacker gets into the Acme company, he could PtH with Administrator account but only within the OU.

It’s a reasonable solution. And I do realize that many companies likely already use this GPO property for ordinary user accounts, just for reasons I noted above.

Additional Thoughts

In writing this brief series, you quickly come to the conclusion that zillions of IT folks already know in their bones: you’re always trying to balance security against convenience. You won’t have a perfect solution, and you’ve probably erred on the side of convenience (to avoid getting shouted at by the user community).

Of course, you live with what you have. But then you should compensate for potential security holes by stepping up your monitoring game! You know where this is going.

One final caveat goes back to my amazing pen testing series where I showed how delegated Administrator groups can be leveraged to allow hacker to hop more freely around a domain—this has to do with accounts being in more than one Active Directory group. Take another look at it!

Working With Windows Local Administrator Accounts, Part II

Working With Windows Local Administrator Accounts, Part II

Before we delve into Restricted Groups, I thought it might be worthwhile to take a closer look at how hackers take advantage of Administrator passwords. For Pass-the-Hash fans, this post will show you how hashes can be used even with local accounts. I also had a chance to try Windows Local Administrator Passwords Solution or LAPS. Spoiler alert: LAPS scares me a little.

Passing Local Hashes

After writing the first post, I realized that you don’t necessarily need hashes of domain accounts. In fact, Windows also stores the hashes of local accounts in its Security Accounts Manager (SAM) database. Hash dumping tools such as crackmapexec and mimikatz let you view these hashes.

This leads to a more direct lateral movement tactic. As I pointed out last time, it is not unusual for local Administrator accounts to have exactly the same password on more than one machine. This would also mean the NTLM hashes would be the same as well.

Let’s say a hacker gains access to a server, and assuming he has enough privileges, then uses mimikatz to see if a local Administrator account is available. He can then try an experiment and pass the Administrator hash into, say, psexec to pop a shell on another server and gain Administrator privileges there as well.

You see what I’m getting at?  If you assume that Administrator passwords are the same on different machines, then you’re no longer dependent on a domain-level user to have left a hash in the LSASS memory of that box. This post explains more about LSASS if you’re confused by the last sentence.

On the other hand, the local user hashes are always there! Being a hacker or pen tester means that you’re always testing different ideas and playing the odds. So let’s go for broke!

Back in my Acme domain, I set the same local Administrator password on both my Masa and Taco servers – Taco is also my domain controller. In this scenario, I’m already on Masa, I’ve uploaded mimikatz and psexec.

By the way, both these tools have source code, so it wouldn’t be that difficult to make them fully undetectable after a few tweaks.

I was now flying under the radar on Masa, but couldn’t find anything interesting there. To begin my lateral move, I loaded mimikatz and dumped the hashes with the lsadump::samcommand.

Assuming that Taco also has the same Administrator password, I then use sekurlsa:pth to launch psexec and gain a shell on Taco (below).

Just try passing-the-hash with the local Administrator account. What do you have to lose?


When I changed the Taco Administrator’s password, this ploy didn’t work, and psexec was unable to pop a shell.

Lesson learned: it’s good idea to have different Administrator passwords.

LAPS and Aspirin

If you’re going to keep the local Administrator passwords, then you need to manage them. As I wrote about last time, these accounts can be disabled, and Restricted Groups can be used to delegate Administrator privileges to domain-level accounts.

In any case, people still want these local accounts. Microsoft apparently heard the collective cry of IT administrators, and in 2015 they released their Local Administrator Passwords Solution. It’s described with these words: “…solution to the issue of using a common local account with an identical password on every computer in a domain. LAPS resolves this issue by setting a different, random password for the common local administrator account on every computer in the domain.”

Seems simple. However as we’ve noted before,  Microsoft never, ever does anything nice and easy.

The first tip off was the LAPS architecture (see below).

Plans for the invasion of Mars.

Hmm, there is a client and server side to this. The documentation also indicates PowerShell scripts have to be run, and then there’s something about changing the Active Directory schema.

I boldly took the LAPS challenge and went as far as I could with the installation before the pounding in my head got to me.

This is not an easy install. LAPS is loaded onto your domain controller as well as on client computers that you want managed. Yeah, you use the Group Management Console to push out LAPS to the clients.

If you do the installation correctly, you’ll see the following interface pop up when you navigate in the GPO editor to Computer Configuration>Administrative Templates>LAPS.

I was afraid to pull the trigger on this. In theory, LAPS generates random passwords that are now centrally located on Active Directory in a new attribute as plaintext — that’s why you needed to update the AD schema.

Some security pros have pointed out that LAPS may, ahem, have its own problems. Essentially, you’re shifting the problem from local computers to Active Directory.

Back to Restricted Groups

After returning from my LAPS detour, I began to see Restricted Groups as the most practical way to manage local Administrator accounts. I started on this process in the previous post when I created a new AD group called Acme-IT, which then was pushed out and placed under the local Administrators group for each machine in the Acme domain

It’s a neat trick, and Restricted Groups allow IT to centrally control local Administrator access.

It would even be neater if I could segment my domain so that one group of users would be local Administrators for a subset of machines, and another group would control a different subset –creating as many sub-groupings as needed.

Otherwise, I’d fall into the trap of allowing a small group of users to have local Administrator access to the entire domain! No bueno.

And that’s where Organizational Units (OUs) come into play. It’s a way to divide up the domain so that you can associate specific GPOs with each OU subgroup.

You first set up these OU sub-divisions in Active Directory Users and Computer (below). For each OU, I assigned a subset of the domain’s computers. In my scenario, Acme-1 is associated with the Masa and Pimiento servers, and Acme-2 is associated with Taco, the domain controller.

Two new OUs join the Acme domain: Acme-1 and Acme-2.

I also had to remember to create Active Directory groups that will be associated with each of these OUs — Acme-IT-1 and  Acme-IT-2.

Now when I’m back in the Group Management Console, these OUs show up under the Acme domain (below). I added a Restricted Groups policy under each OU, making sure that the appropriate AD groups were used.

The OU payoff: segmented GPO policies!

It’s simpler than it sounds. In short: I’m enabling members of Acme-IT-1 to be an Administrator for Masa and Pimiento, and Acme-IT-2 members for Taco.

We’ll finish up this incredibly exciting topic in the next post and, as always, I’ll have a few closing thoughts. In the meantime, take a few aspirins for getting this far in the series.


Continue reading the next post in "Working With Local Administrator Accounts"

A Few Thoughts on Data Security Standards

A Few Thoughts on Data Security Standards

Did you know that the 462-page NIST 800-53 data security standard has 206 controls with over 400 sub-controls1?  By the way, you can gaze upon the convenient XML-formatted version here. PCI DSS is no slouch either with hundreds of sub-controls in its requirements’ document. And then there’s the sprawling IS0 27001 data standard.

Let’s not forget about security frameworks, such as COBIT and NIST CSF, which are kind of meta-standards that map into other security controls. For organizations in health or finance that are subject to US federal data security rules, HIPAA and GLBA’s data regulations need to be considered as well. And if you’re involved in the EU market, there’s GDPR; in Canada, it’s PIPEDA; in the Philippines, it’s this, etc., etc.

There’s enough technical and legal complexity out there to keep teams of IT security pros, privacy attorneys, auditors, and diplomats busy till the end of time.

As a security blogger, I’ve also puzzled and pondered over the aforementioned standards and regulations. I’m not the first to notice the obvious: data security standards fall into patterns that make them all very similar.

Security Control Connections

If you’ve mastered and implemented one, then very likely you’re compliant to others as well. In fact, that’s one good reason for having frameworks. For example, with, say NIST CSF, you can leverage your investment in ISO 27001 or ISA 62443 through their cross-mapped control matrix (below).

Got ISO 27001? Then you’re compliant with NIST CSF!

I think we can all agree that most organizations will find it impossible to implement all the controls in a typical data standard with the same degree of attention— when was last time you checked the physical access audit logs to your data transmission assets (NIST 800-53, PE-3b)?

So to make it easier for companies and the humans that work there, some of the standards group have issued further guidelines that break the huge list of controls into more achievable goals.

The PCI group has a prioritized approach to dealing with their DSS—they have six practical milestones that are broken into a smaller subset of relevant controls. They also have a best practices guide that views — and this is important — security controls into three broader functional areas: assessment, remediation, and monitoring.

In fact, we wrote a fascinating white paper explaining these best practices, and how you should be feeding back the results of monitoring into the next round of assessments. In short: you’re always in a security process.

NIST CSF, which itself is a pared down version of NIST 800-53, also has a similar breakdown of its controls into broader categories, including identification, protection, and detection. If you look more closely at the CSF identification controls, which mostly involve inventorying your IT data assets and systems, you’ll see that the main goal in this area is to evaluate or assess the security risks of the assets that you’ve collected.

File-Oriented Risk Assessments

In my mind, the trio of assess, protect, and monitor is a good way to organize and view just about any data security standard.

In dealing with these data standards, organizations can also take a practical short-cut through these controls based on what we know about the kinds of threats appearing in our world — and not the one that data standards authors were facing when they wrote the controls!

We’re now in a new era of stealthy attackers who enter systems undetected, often though phish mails, leveraging previously stolen credentials, or zero-day vulnerabilities. Once inside, they can fly under the monitoring radar with malware-free techniques, find monetizable data, and then remove or exfiltrate it.

Of course it’s important to assess, protect and monitor network infrastructure, but these new attack techniques suggest that the focus should be inside the company.

And we’re back to a favorite IOS blog theme. You should really be making it much harder for hackers to find the valuable data — like credit card or account numbers, corporate IP — in your file systems, and detect and stop the attackers as soon as possible.

Therefore, when looking at the how to apply typical data security controls, think file systems!

For, say, NIST 800.53, that means scanning file systems, looking for sensitive data, examining the ALCs or permissions and then assessing the risks (CM-8, RA-2,RA-3). For remediation or protection, this would involve reorganizing Active Directory groups and resetting ACLs to be more exclusive (AC-6). For detection, you’ll want to watch for unusual file system accesses that likely indicate hackers borrowing employee credentials (SI-4).

I think the most important point is not to view these data standards as just an enormous list of disconnected controls, but instead to consider them in the context of assess-protect-monitor, and then apply them to your file systems.

I’ll have more to say on a data or file-focused view of data security controls in the coming weeks.

1 How did I know that NIST 800-53 has over 400 sub-controls? I took the XML file and ran this amazing two lines of PowerShell:

[xml]$books = Get-Content 800-53-controls.xml
$books.controls.control|%{$_.statement.statement.number}| measure -line


Working With Windows Local Administrator Accounts, Part I

Working With Windows Local Administrator Accounts, Part I

In writing about hackers and their techniques, the issue of Windows local Administrator accounts often comes up. Prior to Windows 7, the Administrator account was created by default with no password. This was not a good security practice, and hackers have been taking advantage ever since.

Starting in Windows 7, the local Administrator accounts were disabled by default. And you should disable them in your domain regardless of which Windows OS you have! But for various reasons, some of them based on mistaken ideas, the local Administrator accounts hang around on many installations. They’ve too often been given easily guessable passwords by IT, and sometimes the same password across large parts of the domain.

If hackers can get a foothold on the system, they’ll look for this privileged local Administrator account as part of their evil checklist. They’ll then try to use these accounts as they start the lateral movement phase of their post-exploitation.

In short: they guess the local Administrator’s account password, grab the hashes of domain-level users with mimikatz, and then move around the network.

But I Need It!

Or they may not even have to grab hashes of domain-level users. In many environments, the local Administrator account passwords themselves are set using the same pattern: once you guess one, you can figure out the whole shebang.

In the real world, you may have to deal with IT staff arguing the Administrator accounts need to be available — perhaps because processes or software is dependent on their existence.

Is there a way to keep the Administrator accounts but lessen their power?

Microsoft has a few recommendations on how to secure them. Essentially, you configure a Group Policy Object (GPO) to disable network access, remote desktop, and a few other services through User Rights Assignment.

Enabling “deny access to this computer from the network” in the User Rights Assignment GPO.

Just to see this how would work, I went back to my now famous Acme domain that I set up up in Amazon Web Services.

Let’s assume passwords for Acme’s local Administrator accounts are based on a pattern — the server name followed by a numeric sequence — as a memory convenience for the beleaguered IT staff.

In my pretend scenario, I used the vanilla psexec utility — which by the way played a part in the recent NotPetya ransomware outbreak — to laterally move to the Taco server. Putting on my pen-testing hat, I entered my guess for the Administrator password to Taco, and miraculously it worked.

You can see the results of my psexec activities below before I set the “deny network access” GPO.

Taking advantage of silly Administrator passwords with psexec.

After I set the GPO, the psexec utility complained that my user name or password was invalid — User Rights Assignment was doing its job. If you’re trying this at home, remember to run gpupdate /forceon the domain controller to trigger the GPOs to sync to all the domain members.

This is a compromise solution that lets you keep the local Administrator accounts but prevents hackers from easily exploiting them to move around the network.

Don’t Change Passwords With Group Policy Preferences

The right thing to do is to disable the local Administrator, and then set up domain-level groups with restricted privileges under the local Administrators group. We’ll start discussing how to do this further below.

But let’s say your heart is set on keeping these local Administrator accounts; you realize the passwords were set for convenience (and not for security);  and you now want to improve the passwords on a global level.

Once upon a time, Microsoft introduced Group Policy Preferences (GPP) in Windows server 2008 to extend GPP. One of the new GPP capabilities allowed you to update user and group information on a domain basis.  At one point, you were allowed to change passwords and then push out the updated passwords across the domain

However, hackers found a major vulnerability in GPP’s  password distribution process. While Windows encrypted the password, they released — duh! — the encryption key in their technical documentation.

They’ve since put out a patch for it, and in the AWS instance I was most recently working with, the password entry was disabled — it’s grayed out in the graphic below.

In my AWS environment, the GPP feature for updating passwords is disabled. You may not be so lucky.

However, early on in my experimenting I launched an unpatched AWS instance, where I was able to enter the password. And sure enough I could pull up the AES-encrypted password from the SYSVOL folder.

And there are no doubt many more servers out in this world without the GPP patch. In fact, pen testing utilities such as crackmapexec search for encrypted passwords — see the -gpp-passwords option — in the SYSVOL folder and then conveniently decrypts them.

Thankfully, Microsoft came out with another way to do bulk updates of Administrator passwords, giving it the catchy name of Local Administrator Password Solution, or LAPS. You can download it here. I plan on giving it a try, and I’ll let you know the results.

Restricted Groups

The better way to handle local Administrator accounts is through the Restricted Groups GPO, found under Computer Configuration > Policies > Windows Settings> Security Settings. This GPO manages the local Administrators group by letting you add a domain-level group under it and then pushing the changes out across the domain. In short: you have a special group of users that’s centrally controlled with just the privileges to do the local administrative work they need.

For my Acme domain, I delegated local Administrator powers to the Acme-IT group (below).

Restricted Groups! Control local Administrators across the domain in one swoop.

There are additional subtleties in working with Restricted Groups that we’ll get to next time. And we’ll also take up Organizational Units or OUs, which gives us the power to segment the domain and improve the security of our Restricted Groups.


Continue reading the next post in "Working With Local Administrator Accounts"

Please Disable UPnP on Your Router. Now!

Please Disable UPnP on Your Router. Now!

Remember the first large-scale Mirai attack late last year? That was the one directed at IP cameras, and took advantage of router configurations settings that many consumers never bother changing. The main culprit, though, was Universal Plug and Play or UPnP, which is enabled as a default setting on zillions of routers worldwide.

Also known as port forwarding, UPnP is a convenient way for allowing gadgets, such as the aforementioned cameras (or WiFi-connected coffee pots), to be accessible on the other side of the firewall through a public port. UPnP automatically creates this public port when these gadgets are installed.

Command and Control Meets UPnP

However, this convenience factor provides an opening for hackers. In the case of Mirai, it allowed them to scan for these ports, and then hack into the device at the other end.

Hackers have now found an even more diabolical use of UPnP with the banking trojan Pinkslipbot, also known as QakBot or QBot.

Around since 2000, QakBot infects computers, installs a key logger, and then sends banking credentials to remote Command and Control (C2) servers.

Remember C2?

When we wrote our first series on pen testing, we described how remote access trojans (RATs) residing on the victims’ computers are sent commands remotely from the hackers’ servers over an HTTP or HTTPS connection.

This is a stealthy approach in post-exploitation because it makes it very difficult for IT security to spot any abnormalities. After all, to an admin or technician watching the network it would just appear that the user is web browsing — even though the RAT is receiving embedded commands to log keystrokes or search for PII, and exfiltrating passwords, credit card numbers, etc. to the C2s.

The right defense against this is to block the domains of known C2 hideouts. Of course, it becomes a cat-and-mouse game with the hackers as they find new dark spots on the Web to set up their servers as old ones are filtered out by corporate security teams.

And that’s where Pinkslipbot has added a significant innovation. It has introduced, for lack of a better term, middle-malware, which infects computers, but not to take user credentials! Instead, the middle-malware installs a proxy C2 server that relays HTTPS to the real C2 servers.

Middle-malware: C2 servers can be anywhere!

The Pinkslipbot infrastructure therefore doesn’t have a fixed domain for their C2 servers. In effect, the entire Web is their playing field! It means that it’s almost impossible to maintain a list of known domains or addresses to filter out.

What does UPnP have to do with Pinkslipbot?

When the Pinkslipbot is taking over a consumer laptop, it checks to see if UPnP is enabled. If it is, the Pinkslipbot middle-malware issues a UPnP request to the router to open up a public port. This allows Pinslipbot to then act as a relay between those computers infected with the RATs and the hackers’ C2 servers (see the diagram).

It’s fiendish, and I begrudgingly give these guys a (black) hat tip.

One way for all of us to make these kinds of attacks more difficult to pull off is to simply disable the UPnP or port-forwarding feature on our home routers. You probably don’t need it!

By the way, you can see this done here for my own home Linksys router. And while you’re carrying out the reconfiguration, take the time to come up with a better admin password.

Do this now!

Security Stealth Wars: IT Is Not Winning (With Perimeter Defenses)

PhishingFUD malware, malware-free hacking with PowerShell, and now hidden C2 servers. The hackers are gaining the upper-hand in post-exploitation: their activities are almost impossible to block or spot with traditional perimeter security techniques and malware scanning.

What to do?

The first part is really psychological: you have to be willing to accept that the attackers will get in. I realize that it means admitting defeat, which can be painful for IT and tech people. But now you’re liberated from having to defend an approach that no longer makes sense!

Once you’ve passed over this mental barrier, the next part follows: you need a secondary defense for detecting hacking that’s not reliant on malware signatures or network monitoring.

I think you know where this is going. Defensive software that’s based on – wait for it — User Behavior Analytics (UBA) can spot the one part of the attack that can’t be hidden: searching for PII in the file system, accessing critical folders and files, and copying the content.

In effect, you grant the hackers a small part of the cyber battlefield, only to defeat them later on.

I Click Therefore I Exist: Disturbing Research On Phishing

I Click Therefore I Exist: Disturbing Research On Phishing

Homo sapiens click on links in clunky, non-personalized phish mails. They just do. We’ve seen research suggesting a small percentage are simply wired to click during their online interactions. Until recently, the “why” behind most people’s clicking behaviors remained something of a mystery. We now have more of an answer to this question based on findings from German academics. Warning:  IT security people will not find their conclusions very comforting.

Attention Marketers: High Click-Through Rates!

According to research by Zinaida Benenson and her colleagues, the reasons for clicking on phish bait are based on an overall curiosity factor, and then secondarily, on content that connects in some way to the victim.

The research group used the following email template in the experiment, and sent it to over 1200 students at two different universities:


The New Year’s Eve party was awesome! Here are the pictures:

http://<IP address>/photocloud/page.php?h=<participant ID>

But please don’t share them with people who have not been there!

See you next time!

<sender’s first name>

The message, by the way, was blasted out during the first week of January.

Anybody want to guess what was the overall click-through rate for this spammy message?

A blazing 25%.

Marketers everywhere are officially jealous of this awesome metric.

Anyway, the German researchers followed up with survey questions to find the motivations behind these click-aholics.

Of those who responded to the survey, 34% said they were curious about the party pictures linked to in the mail, another 27% said the message fits the time of year, and another 16% said they thought they knew the sender based on just the first name.

To paraphrase one of those cat memes, “Humans is EZ to fool!”

The clever German researchers conducted a classic cover-story design in their experiment. They enlisted students to ostensibly participate in a study on Internet habits and offered online shopping vouchers as an incentive. Nothing was mentioned about phish mails being sent to them.

And yes, after the real study on phishing was completed, the student subjects were told the reason for the research, the results, and given a good stern warning about not clicking on silly phish mail links.

Benenson also gave a talk on her research at last year’s Black Hat. It’s well-worth your time.

Phishing: The Ugly Truth

At the IOS blog, we’ve also been writing about phishing and have been following the relevant research. In short: we can’t say we’re surprised by the findings of the German team, especially as it relates to clicking on links to pictures.

The German study seems to confirm our own intuitions: people at corporate at jobs are bored and are finding cheap thrills by gazing into the private lives of strangers.

Ok, you can’t change human nature, etc.

But there’s another more disturbing conclusion related to the general context of the message.The study strongly suggests the more you know and can say about the target in the phish mail, the more likely it is that they will click. And in fact in an earlier study by Benenson, a 56% click-rate was achieved when the phish mail recipient was addressed by name.

Here’s what they had to say about their latest research:

 … fitting the content and the context of the message to the current life situation of a person plays an important role. Many people did not click because they learned to avoid messages from unknown senders, or with an unexpected content  … For some participants, however, the same heuristic (‘does this message fit my current situation?’) led to the clicks, as they thought that the message might be from a person from their New Year’s Eve party, or that they might know the sender.


Implications for Data Security

At Varonis, we’ve been preaching the message that you can’t expect perimeter security to be your last line of defense. Phishing, of course, is one of the major reasons why hackers find it so easy to get inside the corporate intranet.

But hackers are getting smarter all the time, collecting more details about their phishing targets to make the lure more attractive.The German research shows that even poorly personalized content is very effective.

So imagine what happens if they gain actual personal preference and other informational details from observing victims on social media sites or, perhaps, through a previous hack of another web site you engage with.

Maybe a smart hacker who’s been stalking me might send this fiendish email to my Varonis account:

Hey Andy,

Sorry I didn’t see you Black Hat this year! I ran into your colleague Cindy Ng, and she said you’d really be interested in research I’m doing on phishing and user behavior analytics. Click on this link and let me know what you think.  Hope things are going well at Varonis!


Bob Simpson, CEO of Phishing Analytics

Hmmm, you know I could fall for something like this the next time I’m in a vulnerable state.

The takeaway lesson for IT is that they need a secondary security defense, one that monitors hackers when they’re behind the firewall and can detect unusual behaviors by analyzing file system activity.

Want to find out more, click here!

Did you click? Good, that link doesn’t point to a Varonis domain!

Another conclusion of the study is that your organization should also undertake security training, especially for non-tech savvy staff.

We approve as well: it’s a worthwhile investment!

GDPR: Troy Hunt Explains it All in Video Course

GDPR: Troy Hunt Explains it All in Video Course

You’re a high-level IT security person, who’s done the grunt work of keeping your company compliant with PCI DSS, ISO 27001, and a few other security abbreviations, and one day you’re in a meeting with the CEO, CSO, and CIO. When the subject of General Data Protection Regulation or GDPR comes up, all the Cs agree that there are some difficulties, but everything will be worked out.

You are too afraid to ask, “What is the GDPR?”

Too Busy for GDPR

We’ve all been there, of course. Your plate has been full over the last few weeks and months hunting down vulnerabilities, hardening defenses against ransomware and other malware, upgrading your security, along with all the usual work involved in keeping the IT systems humming along.

So it’s understandable that the General Data Protection Regulation may have flown under your radar.

However, there’s no need to panic.

The GDPR shares many similarities with other security standards and regulations so it’s just question of learning some basic background, the key requirements of the new EU law, and a few gotchas, preferably explained by an instructor with a knack for connecting with IT people.

Hunt on GDPR

And that’s why we engaged with Troy Hunt to develop a 7-part video course on the GDPR. Troy is a web security guru, Australian Microsoft Regional Director, and author whose security writing has appeared in Forbes, Time Magazine, and Mashable. And he’s no stranger to this blog as well!

Let’s get back to you and other busy IT security folks like you who need to get up to speed quickly.  With just an hour of your time, Troy will cover the basic vocabulary and definitions (“controller”, “processor”, “personal data”), the key concept underlying GDPR (personal data is effectively owned by the consumer), and what you’ll need to do to keep your organization compliant (effectively, minimize and monitor this personal data.)

By the way, Troy also explains how US companies, even those without EU offices, can get snagged by GDPR’s territorial scope rule— Article 3 to be exact. US-based e-commerce companies: you’ve been warned!

While Troy doesn’t expect you to be an attorney, he analyzes and breaks down a few of more critical requirements and the penalties for not complying, particularly on breach reporting, so that you’ll be able to keep up with some of the legalese when it arises at your next GDPR meeting.

And I think you’ll see by the end of the course that while there may be some new aspects to this EU law, as Troy notes, the GDPR really legislates IT common sense.

What are you waiting for?  Register and get GDPR-aware starting today!





[Infographic] From Bad Report Cards to Insider Data Theft

[Infographic] From Bad Report Cards to Insider Data Theft

We’ve all read the news recently about employees and contractors selling internal customer data records or stealing corporate intellectual property. But insiders breaking bad have been with us as long as we’ve had computers and disgruntled humans who understand IT systems.

You may not know it, but academic researchers have also been studying the psychological insides of insiders.

Carnegie Mellon’s Computer Emergency Response Team (CERT) has an entire group devoted to insider threats. Based on looking at real cases, these academics have come up with, to our minds, a very convincing model of what drives insiders.

In short, it’s their belief that the root causes lie beyond just a raise or promotion denied, but rather in earlier traumas, likely starting in childhood.

For instance, it is thought that children who, during a famous psych experiment, immediately ate the marshmallow (instead of waiting for two marshmallows) had issues with parental and other authority figures that would later show up through impulsive behaviors. Or perhaps for a certain kind of child, not getting into the genius program for advanced 4-year-olds can have devastating consequences later!

We’ve turned the complex CERT multi-stage insider model into this more accessible infographic. Check out the original CERT paper (or read our incredibly informative series) to learn more.


Disabling PowerShell and Other Malware Nuisances, Part III

Disabling PowerShell and Other Malware Nuisances, Part III

This article is part of the series "Disabling PowerShell and Other Malware Nuisances". Check out the rest:

One of the advantages of AppLocker over Software Restriction Policies is that it can selectively enable PowerShell for Active Directory groups. I showed how this can be done in the previous post. The goal is to limit as much as possible the ability of hackers to launch PowerShell malware, but still give legitimate users access.

It’s a balancing act of course. And as I suggested, you can accomplish the same thing by using a combination of Software Restriction Policies (SRP) and ACLs, but AppLocker does this more efficiently in one swoop.

Let’s Get Real About Whitelisting

As a practical matter, whitelisting is just plain hard to do, and I’m guessing most IT security staff won’t go down this route. However, AppLocker does provide an ‘audit mode’ that makes whitelisting slightly less painful than SRP.

AppLocker can be configured to log events that show up directly in the Windows Event Viewer. For whatever reason, I couldn’t get this to work in my AWS environment. But this would be a little less of a headache than setting up a Registry entry and dealing with a raw file — the SPR approach.

In any case, I think most of you will try what I did. I took the default rules provided by AppLocker to enable the standard Windows system and program folders, added an exception for PowerShell, and then created a special rule to allow only member of a select AD group — Acme-VIPs in my case — to access PowerShell.

AppLocker: Accept the default path rules, and then selectively enable PowerShell.

Effectively, I whitelisted all-the-usual Windows suspects, and then partially blacklisted PowerShell.

PowerShell for Lara, who’s in the Acme-VIPs group, but no PowerShell for Bob!

And Acme Was Hacked

No, the hacking of my Acme domain on AWS is not going to make any headlines. But I thought as a side note it’s worth mentioning.

I confess: I was a little lax with my Amazon firewall port setting, and some malware slipped in.

After some investigation, I discovered a suspicious executable in  the \Windows\Prefetch directory. It was run as a service that looked legit, and it opened a zillion UDP ports.

It took me an afternoon or two to figure all this out. My tip offs were when my server became somewhat sluggish, and then receiving an Amazon email politely suggesting that my EC2 instance may have been turned into a bot used for a DDoS attack.

This does relate to SRP and AppLocker!

Sure, had I activated these protection services earlier, Windows would have been prevented from launch the malware, which was living in in a non-standard location.

Lesson learned.

And I hold my head in shame if I caused some DDos disturbance for someone, somewhere.

Final Thoughts

Both SRP and AppLocker also have rules that take into account file hashes and digital certificates. Either will provide an additional level of security that the executable are really what they claim to be, and not the work of evil hackers.

AppLocker is more granular than SRP when it comes to certificates, and it allows you to filter on a specific app from a publisher and a version number as well. You can learn more about this here.

Bottom line: whitelisting is not an achievable goal for the average IT mortal. For the matter at hand, disabling PowerShell, my approach of using default paths provided by either SRP or AppLocker, and then selectively allowing PowerShell for certain groups — easier with AppLocker — would be far more realistic.