Given at BSides Seattle 2017, February 4, 2017 You know the ins and outs of pivoting through your client’s or your employer’s domains. You know where to find those unprotected creds that unlock the mysteries of the LAN. You know which hashes grant DA and root to the infrastructure. All the bases belong to you, but do you know how to follow once the path leads into the clouds? As more and more companies move part or all of their operations into the cloud, penetration testers need to think beyond the traditional network boundaries and follow the data and services they are after. The intent of this talk is to provide penetration testers as well as defenders a foundation on cloud services from an attacker’s point of view. This talk is cloud-agnostic and focuses on the general topics and attack patterns necessary to assess cloud-based services rather than specific implementations or vulnerabilities. Do you know the differences between IaaS, PaaS, and SaaS and which vulnerabilities are applicable to each? Am I even allowed to assess my company’s cloud resources? Do you know what credentials you need to move from the corporate network into cloud based services? Do you know where to find them? What dependencies can you compromise to complete your objectives? What kinds of recommendations can I make to improve the security of my client’s cloud deployments? Companies trust key portions of their operations, services, and data to public and private clouds and unless their internal and third-party testers must assess these deployments.

1. Cloud basics for pen testers, and red
teamers (and defenders)
Gerald Steere – Microsoft C+E Red Team (@Darkpawh)

2. You may ask yourself, why am I here?
Introductory stuff, ice breaking, and other things introverts hate
Cloud terminology from the attacker mindset
Wait, what? Can I really do that?
Taking off – moving from the premises to the cloud
That’s cool and all, but what about fixing it?
Were you paying attention? There may be a test.
PregameShow

3. Introductory stuff, ice breaking, and
other things introverts hate

4. Why should I listen to this guy?
10+ years experience as a penetration tester and red team operator
Member of C+E Red Team since 2014
Spends work days happily smashing atoms in Azure
IntroductoryStuff

5. What is this talk about?
Who are we helping?
Applying the attacker mindset to a
cloud world
What is the same?
What is different?
Cloud agnostic – principles that apply
regardless of which particular cloud
provider is used
What do I recommend to my client?
IntroductoryStuff
Cloudpost -
Martina Pilcerova © Wizards of the Coast

6. What this talk isn’t
Not a step-by-step guide for pwning Azure (Sorry, I love my job)
In-depth walkthrough of performing any specific attacks
The end of the path
IntroductoryStuff
Fork in the Road -
Jung Park © Wizards of the Coast

7. Why should I even care about the cloud?
Your client probably uses it, whether you (or
they) realize it or not
Many traditional techniques do not work
Requires new thought patterns for attackers
and defenders
The cloud isn’t going away
The cloud is continual change
The business impact and risk is real, is large,
and is still mostly ignored
IntroductoryStuff

8. Key terms for the cloud
And what makes them different from a red team prospective

9. Basic cloud terms and where to find them
Accessibility modifiers
Public cloud – big cloud services (Azure, AWS, etc.)
available to all payers
Can also come in a variety limited to specific customers
like government clouds
Private cloud – implementation of cloud
technology or services within an organization with
limited access
May be shared across business partners but not the
public at large
Hybrid cloud – contains portions that full under
public and private
Keyterms
Nimbus Maze -
Jason Chan © Wizards of the Coast

10. Basic cloud terms and where to find them
All the aaS
IaaS – Infrastructure as a Service
Cloud provides the network layer, server, and OS (or some portion thereof)
All applications, configuration, patching, management is done by the client
Susceptible to most attack vectors which work against traditional internet facing hosts
• Brute forcing exposed management ports
• Exploit unpatched applications
• Services missing auth or with weak auth
Keyterms

11. Basic cloud terms and where to find them
All the aaS
PaaS – Platform as a Service
Cloud provides all services except the application itself
Patching and OS configuration are (mostly) done by cloud provider
Very typical for websites and similar workloads
Can also include smaller code snippets
Think about application layer attacks
• Common injection techniques
• Weak and or no auth
• Encryption design and implementation failures
• May provide remote access or debugging capabilities for troubleshooting
Keyterms

12. Basic cloud terms and where to find them
All the aaS
SaaS – Software as a Service
All the resources are managed by the cloud provider
Typically does not run any client application code
Data is primary client asset
Most limiting to the attacker
Can be the most rewarding though
Lines are not always so clear
Keyterms

13. Where is the data?
Cloud services rely on data storage
for nearly everything
How is data stored in the cloud?
Do I need to attack the service or is
the data my real goal?
Keyterms

14. Considerations and limitations in
assessing cloud environments
The cloud is just someone else’s computer after all

15. Can I really go after my client’s cloud
deployments?
I am not a lawyer, if you’re a professional
you need one of those to talk to ALWAYS.
What is and isn’t authorized should be
defined in your rules of engagement with
your client and legal approval
Policies vary depending on cloud provider
May require preapproval or notification
of the cloud provider
You did talk to your lawyer right?
Considerations

16. Limited access to testing cloud resources
Understand that access to test your client’s deployments will be more
limited than on premises systems
This is often limited to the specific systems and services deployed by
your client
Cloud infrastructure itself is typically off limits, how do you account
for this?
Cloud providers may have a separate bug bounty or similar program though
You need to spell out enforced limitations in your reporting. Be clear
on what was and wasn’t allowed
Considerations

17. Limits are acceptable, but…
If your client’s cloud provider does not
allow even limited testing of the client’s
assets
Work with client, provider, and legal to
address if possible
Get a new cloud provider
These limitations also apply to
defenders.
You must still be able to monitor and
assess your cloud deployments.
Do you have a plan and system in place to
do it?
Considerations
Ceremonious Rejection -
Chris Rahn © Wizards of the Coast

18. Taking off
Moving from the premises to the cloud

19. Knocking on heaven’s door
I’ve got all these hashes and no where to go
Cloud authentication and authorization is typically independent from the on-
premises domain
No matter how many times you’ve popped the KRBTGT account, your cloud provider
really doesn’t care
You may be able to use those hashes to get what you need though
Humans are still human and cracking passwords is fun
How you authenticate will depend on the specific cloud provider
Takingoff

20. Knocking on heaven’s door
What do the keys look like?
Certificates, certificates, certificates!
Popping dev boxes has never been more productive
You do know mimikatz can also export certificates, right?
Takingoff

21. Knocking on heaven’s door
What do the keys look like?
DevOps probably has what you are looking for
API keys and shared secrets for the win
Source code access for fun and profit
How are these deployments done anyways?
Takingoff
DevOps

22. Knocking on heaven’s door
What do the keys look like?
What portal or management interface does the cloud provider support?
Does it set cookies? Cookies are great
Consider how auth is done in multiple scenarios
What scenarios do your client use?
What scenarios do the provider support that your client doesn’t consider?
Takingoff

23. Think locally, act globally
Cloud assets are managed under an account
or subscription
Getting access to that layer is often
equivalent to DA
Who has that level of access in your target
org?
How can you get that access from them?
What do you do once you have account
management access?
Takingoff

24. Think locally, act globally
Takingoff

25. The circle of access
Access between on-premises and
cloud deployments often a two
way street
Moving from on-premises to cloud
is typically a matter of finding the
correct credentials, but is there a
way back?
Consider shared authentication
methods if available
Takingoff

26. The circle of access
What is the likelihood this cloud
service need to access resources
from on-premises?
Does this cloud service talk to an
internal database?
Are processed files being pushed back
to local storage?
Think in terms of relationships
between systems. Hacking is often an
abuse of trust relationships.
Virtual private networks are fun,
complicated, and easy to mess up
Takingoff
Rogue’s Passage-
Christine Choi © Wizards of the Coast

27. The circle of access
This is a large risk area which attackers and defenders must consider
It is often easy for DevOps to setup a connection between on-premises and
cloud
If you are defending the networking would you know?
If you know, do you have a way to monitor it?
What data is being pushed out to the cloud and what is the risk factor?
Sure a copy of the DC running on a cloud host in a VPN is great for
redundancy, but did you know anyone who can manage that cloud account is
now a DA?
You do know who can manage that account, right?
Takingoff

28. Now what?
Closing my eyes and hoping it goes away isn’t going to
work, is it?

29. Giving useful advice
Telling your client to close up shop and moving back into the
basement is probably a non-starter
Clouds do provide real business benefits and can improve security
when done right
Nowwhat?

30. Giving useful advice
Many of the basics remain the same
Properly handle, store, and mange
credentials and secrets
You aren’t storing those access keys in GIT
are you?
Clouds do provide managed secret stores
Make it easy for DevOps to do the right thing
Enforce MFA on all accounts
If it can’t have MFA, limit it as much as
possible and monitor it
Nowwhat?

31. Giving useful advice
Many of the basics remain the same
Least privilege is key and poorly understood in many cloud implementations
Think of your account managers like DA in a traditional environment
Role based access control can be applied to most resources (but often isn’t)
Control implementations are cloud specific and you need to be familiar with the options
available from your client’s provider
Least access, use the security features provided by the cloud.
Many times the cloud storage model makes write-only and read-only easy to implement
Clear your mind and visualize the flow of data, then choke it
Does that VPN need to provide access to your entire on-premises network or only a
specific host?
Nowwhat?

32. Monitoring and alerting
It’s not just for your network any more
Defenders need to work with DevOps to make sure that cloud
resources and data are considered in defensive designs
Different cloud providers provide different tools for managing security
Defenders must be familiar with the tools from cloud providers used
by their client
Log collection and management needs to include cloud assets
You do know what your assets are, right?
Nowwhat?

33. And that’s the way it is
You’re just ready for lunch, aren’t you?

34. The cloud is not going away
You need to be able to help your client defend their assets, whether
they are on-premises or in the cloud
If you are leaving the cloud out of your assessments or defensive
plans, you are failing your client
The cloud is a different world, especially when it comes to identity
and authorization
As an attacker or defender, you must think about how data flows
between these environments. How will you subvert or protect this
flow?
Endoftheroad(fornow)

35. Coming soon
C+E Red Team presenting on cloud post exploitation techniques at
Infiltrate 2017
April 7th, 2017
Sacha Faust and Andrew Johnson will blow your mind
Will be available online after conference
Endoftheroad(fornow)

36. FIN