CyberArk shows how ‘shadow admins’ can be created in cloud environments

There’s little doubt “digital transformation” is here to stay. And it is equally clear that just about all of the fundamental network vulnerabilities we already know about will escalate, in lockstep, with any benefits accrued.

It turns out that speeding up tech innovation cuts both ways.

Related article: How safeguarding privileged accounts can lower insurance

A vivid illustration of this  truism comes from the rising challenges businesses face locking down privileged accounts. I had the chance to visit with CyberArk security researchers Lavi Lazarovitz and Asaf Hecht just after they carried out a stunning demo at RSA Conference 2018.

The pair showed how threat actors can create all-powerful  “shadow admin” accounts within cloud platforms, such as Amazon Web Services, Microsoft Azure and Google Cloud, simply by manipulating the very design features meant to make cloud services nimble and agile.

For a full drill down on our discussion, please listen to the accompanying podcast. Here are key takeaways.

On-premise vs. cloud

Some context: When I interviewed CyberArk CEO Udi Mokady back in 2013, we discussed how most organizations had a lot to learn about privileged access security best practices. The vast majority of organizations at the time underestimated the number of privileged accounts that existed in their networks, allowed employees to widely share passwords, did not use two-factor authentication much, and changed passwords infrequently.

Since then companies have made substantial progress. Privileged access security technologies and best practices have been more widely adopted with respect to on-premises data centers. Companies are paying much closer attention to the use —  and abuse — of privileged accounts, credentials and secrets, especially those that provide root access to mission-critical systems.


Fast forward to 2018 and digital transformation. Today we are in a headlong drive to radically reduce use of on-premises systems, and shift computing infrastructure and software development into the cloud.  So Lazarovitz and Hecht set out to test how well privileged access security policies and procedures developed for on-premises networks held up in a cloud environment.

It took a few months of focused research for them to discover a way to elevate a standard-privilege cloud account to high-privilege status. “We were able to take seemingly less privileged accounts and use them to escalate privileges and take control over the whole cloud environment, just dominate the environment,” Lazarovitz told me.

Manipulating instances

Hecht walked me through a scenario by which a typical DevOps engineer’s account, with the ability to create fresh computing instances, though not alter them, could be juiced up.

This can be done, he explained, by an attacker using the DevOps engineer’s standard, restricted account privileges to create a fresh computing instance, and then altering a few lines of related policy in that fresh instance to create a fresh highly-privileged account.

Lazarovitz and Hecht demoed several alarming pivots a threat actor, in possession of a DevOps engineer’s standard privileged account could make. In one demo, they showed how it was possible to create a fresh computing instance and use that as a foothold to wipe out all of the target organization’s cloud instances.

Explains Hecht: “So, for example, a DevOps user could have permission to create a new machine instance. An attacker could take this new machine and, from there, he could do other malicious actions on behalf of this newly created machine. A limited user can escalate and gain the equivalent power of the full admin.”

Fresh vectors

If you think this is just another theoretical demo, showing a worst case scenario to sell product,  think again.

It was through the cloud vector that cyber criminals breached ride-sharing service Uber to pilfer personal data for 50 million passengers and seven million drivers. The attackers did this by somehow obtaining, then using the AWS logon credentials of one of Uber’s software developers, who left those credentials accessible on GitHub.


Though we don’t know nitty gritty details, it seems pretty clear that these data thieves did similar research and found a similar path to take advantage of Uber’s reliance on cloud infrastructure and cloud software development. While hustling to be as productive as possible, the Uber programmer did not take into full consideration the dire security implications of routinely including AWS logon credentials in GitHub uploads — where hackers could find it, or finagle their way to it.

The attacker then found a path to the crown jewels, akin to the paths demoed by Lazarovitz and Hecht. More of these hacks are coming, folks. It’s going to be interesting to see how quickly and effectively companies jumping on board the digital transformation bandwagon respond.

(Editor’s note: Last Watchdog has provided consulting services to Cyber Ark.)

*** This is a Security Bloggers Network syndicated blog from The Last Watchdog authored by bacohido. Read the original post at:

Cloud Workload Resilience PulseMeter

Step 1 of 8

How do you define cloud resiliency for cloud workloads? (Select 3)(Required)