welcome to extracting all the azure
passwords i'm carl fawson if we're
watching this right now it means that
i've either had some catastrophic issues
with my laptop and wasn't able to join
the live stream to do this presentation
live
but all of the information and slides
will be here
we'll still be able to do the
presentation and i will join for the q a
at the end so uh please save any of your
questions for the questions section that
we have at the end but a little bit of
background on myself here i'm a practice
director at a company called netspy i
currently lead up our pacific northwest
team out of portland oregon along with
that i lead up our cloud pen testing
services where i primarily focus on
azure pen testing as this whole talk is
going to be about azure and how we can
get passwords from it
kind of makes sense that i'd spend a lot
of time doing research there but i also
dabble in other cloud platforms that are
out there as well
spent a little bit of time in aws gcp
handful of other cloud providers out
there so i consider myself a bit of a
cloud enthusiast
in my spare time also a cloud enthusiast
as a private pilot i like to fly and
try to avoid the clouds myself but uh
spent some time up in the sky as well
the last thing on my list here is author
this is a recent edition for me over the
last year or so here i've been
co-authoring the penetration testing
azure for ethical hackers book with
david okioti we will have that book out
in mid-october with packed publishing
but if anybody's interested in
pre-ordering it is out on amazon right
now so feel free to check it out there
otherwise you can find me on the netspy
github where we'll be talking about some
tools that i've released through the
netsby github
and uh i blog on the netspy blog you can
find me on twitter where i'm usually
talking about things that i've
contributed to the netspy blog or to the
github
and that's at kfossen for twitter
so uh this is a cloud village talk so i
would hope that most folks here
understand what azure is but for those
that are not as familiar with it it's
the cloud provider from microsoft and
from i guess my perspective and netspy's
perspective we're seeing lots of our
clients move to the azure cloud for a
number of different reasons the primary
driver really being office 365 services
the integration between on-premise
active directory where lots of clients
we work with are currently in and moving
over to azure active directory which
we'll talk about the structure of that
in a few slides here
and then utilizing some of these
services that we'll talk about in the
talk here to either replicate existing
services that they have on an on-premise
environment or build cloud native up in
azure as a new application or service
that they want to have up in the cloud
so an important thing that we want to
think about here is that at certain iam
rbac role levels within an azure tenant
be it at azure active directory the
subscription
there are passwords in multiple
different areas so typically with
contributor rights
we have multiple different services with
an azure subscription that we're able to
pull out credentials from and we'll be
talking about those different services
today
so uh before we get too far into the
services themselves here just wanna make
sure everybody's using kind of the same
terminology and understanding the
structure of an azure tenant
so from an azure active directory tenant
standpoint
this is kind of the top of the
organization for an azure environment so
the tenant is really that core identity
provider within azure so for role-based
access control and identity and access
management the identities that are
stored in azure active directory will
have roles applied and those roles allow
for access to different subscriptions
services
tenant level roles that will be applied
as well
and in order to apply a role you have to
have a security principle so principles
are made up of a number of different
identities within azure active directory
these could be users and or guest users
primary users being
users that would either be part of the
synced active directory environment or
just direct on microsoft managed
accounts and those are accounts that
only live in azure active directory
they're not synced down with an ad sync
down to an on-premise domain controller
there's some subtle differences between
the two but in general they're users
they're in azure active directory we can
apply roles to them likewise with guest
users those are users that are part of a
different tenant for the core of their
identity those can be added to your
tenant as a guest user and provided
access to different services through
application roles or custom roles
anything like that
for managed identities we have system
assigned and user assigned where system
assigned is really more of
the resource itself having an identity
tied to it versus a user assigned
identity which is more of a subscription
level identity that can then be applied
to individual resources they're kind of
inverses of each other but the core of
it is you can assign a specific identity
to a service so something like a virtual
machine if we want that virtual machine
to be able to have rights within either
azure active directory or the
subscription to access data or make
changes we would assign an identity to
that virtual machine that vm would get
the token for that identity
and then be able to authenticate to
azure id or
to the subscription itself and access
data or make changes so the last one on
here is service principles these are
more of application accounts within an
active directory tenant
you might be familiar with app
registrations within the azure active
directory tenant
these are
kind of more service type credentials
that are utilized by either applications
or services as a long-term or
potentially long-term credential with a
static certificate or password that you
could rotate or change over
typically these are just used for
services that are not used for daily
interaction the user and utilized for
individual services
so to reiterate with all of these things
these security principles are assigned
roles and those roles assign access
within the azure active directory tenant
so going one step down here from the
tenant down to the individual
subscriptions subscriptions can be
housed within management groups
management groups can have child
management groups there's subscriptions
underneath that
within the subscription itself there's
resource groups and resources and the
application of the roles we're going to
talk about here can be applied at any of
those levels that we see down here on
the bottom so typically in a normal
subscription i would say for the most
part we're seeing roles that are applied
at the subscription level or the
management group level
if somebody's really
really interested in setting our back
and im controls around their environment
they'll scope things all the way down to
individual resources but from a
practical day-to-day perspective we're
usually just seeing things scoped to the
subscription or management group for
specific users that are either cloud
engineers or developers within that
subscription or management group that
we're working with
so uh primary roles that we're working
with here are owner contributor and
reader from our perspective as a pen
tester we're often granted reader level
access to a subscription as it doesn't
allow us to make any changes in the
subscription which could potentially
cause an issue
modify existing resources anything like
that so oftentimes we're initially
granted reader level access and try to
escalate up to say owner of the
subscription or up into azure active
directory
so contributors on the subscription
allow
the user to make changes to the
resources themselves in the subscription
contributors really what we're seeing
for the day-to-day users across the
board
people like developers or cloud
engineers that are making changes in the
environment
typically it's a subscription level
contributor permission that's set so
that that user can access everything
that is in that subscription
and the only difference between owner
and contributor is that owners are
allowed to make role assignments within
that subscription so if i'm an owner in
the subscription and want to assign
another user
contributor or reader or another role
within that subscription i have rights
to do that now roles can be applied at
multiple different levels we talked
about the
kind of different subscription or
management group levels there's also
azure active directory tenant level
roles that we're not really going to
talk about today because
they don't necessarily apply to the
subscriptions that's probably a whole
other talk but
for the subscription level roles that
are applied typically service or
application specific roles that we'll
see we'll talk about a couple of ones
that are important for us to use for
gathering passwords in a couple of
slides here
so uh
for all of the
examples that we're going to talk about
in the presentation today just assume
that we have contributor on the
subscription that we're working with
here again typically developers and
engineers are going to have this role
and it's a very common
role that we're going to work with in a
subscription now some folks are going to
say oh that's basically admin and you
can do everything there
yeah it's kind of true i would say it's
on par with say a local admin on a
workstation in a traditional active
directory environment you've got some
power with the
specific environment that you're in say
the subscription
but overall you don't have tenant level
management you're not you know global
admin on the azure active directory
tenant
you don't have rights to add or remove
users anything like that it's really
just yeah i can create a virtual machine
or a key vault or anything like that
and that's typically what we're seeing
in a lot of subscriptions that we work
with
alternatively there are other roles that
you might gain access to during the part
of a pen test so look out for things
like website contributor storage account
contributor we're gonna have a very
specific log analytics contributor
example at the end of the presentation
here but there's multiple different
service specific roles that you might be
able to make use of to gather
credentials from an azure subscription
and we'll cover how we can do that in a
minute
so how do we manually access individual
credentials so let's say that we have
rights to read credentials for a
specific
service that we're utilizing in an azure
subscription
most of the time i would recommend just
using the azure portal
you probably have other options via the
cli or powershell to just manually grab
individual keys or credentials for kind
of one-off collection we'll go through
those for each of the different
subscriptions and sorry subscriptions
resources
and services and uh for each of those
services we'll talk about manual
collection and then how we would
automate that within get a z passwords
which we'll talk about next
so uh from a manual collection
perspective this is fine if you only
have just kind of one-off access to the
portal or the cli or an active session
but from a practical pen tester's
perspective we want something that can
automate all of this collection
so we wrote git azpasswords to automate
the collection of passwords out of an
azure subscription it really wraps the
az powershell functions to automate that
collection and just actively and
passively gather
passwords from different services within
a subscription more the active stuff
we'll talk about with things like
automation accounts where we have to
upload a malicious run book but the
passive configuration gathering is
usually just one or two lines of
powershell to say grab a publishing
profile from app services
so if you're interested in microburst we
have a number of different functions
within the toolset i've got the link out
to the netspy github here for microburst
we talked about all the different
functions uh some other time
but
there's a lot of different tools within
the tool set for enumeration and
attacking different services that are in
azure subscriptions
so the first of these services we'll
talk about today is key vaults now you
may be thinking okay
let's talk about passwords
key vault store passwords this makes
sense uh service is pretty
straightforward it stores credentials
and it's used in an azure subscription
to hold you know secrets keys
certificates anything that you would
want to protect and you know keep in a
password vault or a key vault
so it's pretty simple service uh
manually dumping credentials from this
service is also pretty straightforward
you can go into the keys and secrets if
you have access to read those and then
just manually show the secret value or
download a backup copy of the
certificate
the portal actually makes it pretty easy
to do but this also requires you to have
rights to read
and list any of those keys or secrets in
the access policy so you can see in the
bottom right hand corner here the add
access policy button here
with the key vaults there are individual
access policies for the vaults where you
can configure individual security
principles
and set permissions for the key vault
via the access policy so instead of just
saying hey all of the contributors have
access to list and read
the credentials are stored in the key
vault there's an extra step within azure
key vaults where you have to add an
access policy in order to access those
keys and secrets
just by default when you create a key
vault it's not one of those oh hey
everybody has that it's tied into azure
our back it's one of those things where
you have to add the access policy for
that
during a pen test we may want to
modify that access policy temporarily so
that we can access the credentials that
are in that vault and we definitely want
to revert those changes after we're done
with that that is something that you can
do we have functions and we'll talk
about that in the next slide here that
allow you to do that
but you know it's it's not a huge impact
it is something that
could potentially be logged in uh
the subscription logs themselves and
potentially noted as malicious activity
so something to watch out for there
uh additionally access can be restricted
by source iop and network so things like
private endpoint connections would
restrict where you can actually access
the key vault from this is something
that we do not have automation built in
to get easy passwords for it's not that
i recommend changing something from a
private endpoint to a public endpoint is
definitely a major state change i would
not recommend doing that
but it may be something to keep in mind
as you're trying to get credentials out
of those key vaults
so from an automation perspective it's
pretty straightforward with get ac
passwords we're utilizing the getaz
keyvault function from azpowershell to
list out all the key vaults then for
each vault we want to see what that
access policy is up front if we need to
modify it to add git and list
permissions for our user we can do that
we'll just make a backup of the existing
access policies that we can restore to
at the very end and then modify the
access policy to give ourselves access
then we get the keys and secrets
return those out to the user through the
get a z passwords
powershell function and then return
everything back to its original state
after we're done
pretty straightforward
definitely very handy for dumping out
key vault contents we can also also
export certificates to individual files
as well so if you want to get a pfx
file for a certificate
get a z password support that as well
so the next service that we'll cover is
app services
for those that are not familiar with app
services
at its core it's really
application services that you can use to
host web applications and apis within
azure so in general what we're seeing
app service is used for primarily
function logic apps api endpoints and
more of your traditional application
servers so from a more traditional
on-premise environment let's say you've
got an ias server and want to ship all
of your asp code up to the cloud you can
make use of azure app services to
basically be your web server and
run all of your application code up in
azure super handy from a pentest
perspective we are
potentially getting into app service
applications through traditional web
application vulnerabilities some of the
most impactful ones being code execution
which is extremely impactful in the
first place anyways regardless of where
the application is being hosted but from
a cloud perspective it potentially
allows us to pivot within the cloud
environment
so uh for the app services themselves
there's frequently passwords stored in
configuration files potentially
hard-coded in application configurations
or the application files themselves
there's connection strings are
associated with the app service which
we'll see in a moment here
additionally function app files were
frequently seen configurations there
one of the kind of common things that we
run into from a reader perspective is
being able to read those function app
files and parsed out any hard-coded
credentials there i've quite frequently
seen service principal credentials
stored there and we can pull those out
to get access to whatever that service
principle
needs uh you know say from a key vault
perspective anything like that so those
are definitely handy
and then
there's also app services configuration
service which can then apply down some
of those configurations onto multiple
app services and kind of set standard
deployments things like that that's also
an interesting service to dive into
so i'm manually dumping these
credentials from an app service
application
we just navigate to the application in
the portal go over to the get published
profile link over on the top right there
and get the publish settings file that
we can see here now i've redacted all of
our user passwords here but you can see
all of the usernames are dollar sign
netspy it's for the netspy app service
application
and uh you know all of the creds here
are a bit of an eye chart to look at
here but
we've got web credentials we've got ftp
credentials we've got a number of
different credentials that we might be
able to utilize as an attacker
so uh these credentials that we're going
to get out of the published profile
would allow us to access the application
from an ftp perspective which would give
us access to application code any
configuration files that might be living
in the web directory
and potentially pull sensitive
information out of there much less
getting access to the source code which
could be useful in its own way in
addition to that we have access to web
management credentials
that would allow us to authenticate to
this kudu environment that we have up on
the screen here now typically you would
access that through the azure portal if
you actually go to the scm link so in
this case we see
netspy.stm.azurewebsites.net
if you specify forward slash basic auth
on the end of that
it's kind of a neat workaround trick so
you can use those credentials we
identified in that published profile
to access the kudu interface here
now this interface is super handy for
just getting access to the application
itself the files that are in there we
can see debug console process explorer
you get a powershell shell so you can
run commands on the app service itself
and
super handy so from a persistence
perspective i would recommend pulling
down published profiles for any apps
that you're able to compromise and use
that for persistence to keep a presence
within that app services application
finally the last thing in here is
connection string so by default if you
set a standard
connection string for the application to
use at the app services
resource level that connection string
also gets pulled down with that
published profile
so uh one of the things i want to touch
on here if we're able to use that kudu
interface is potentially using app
services managed identities so an app
service application that has a managed
identity tied to it to access key vaults
so
our potential scenario here is let's say
we're doing an application pen test
against an app services application
we get command execution or some way to
pull a token out of the application
and then utilizing that token we can
potentially collect key vault contents
as that managed identity so by hitting
the metadata service for that app
services application we're able to pull
back a token we have to get token scoped
for the management level and the key
vault level we'll talk about some
specifics later here as we go through uh
some of the other content here but
basically you scope out tokens for this
and you can use the get ac key vault
keys rest or secrets rest to use the
rest apis to collect those out of the
application
so it is super handy because we do
frequently see app services being
configured with managed identities those
identities have rights in an access poll
policy and key vault and key vaults
potentially storing sensitive
information for the application
so
again this is pretty simple to dump all
of this information
we just list out all of the available
app services apps and then for each app
we just pull down the publishing profile
we then parse the profiles for any
credentials and return those back to the
users forget az passwords it's pretty
simple
so next up is automation accounts it's
one of my personal favorites within
azure here but for automation accounts
you've got a service that basically runs
serverless code for you
to automate management and other certain
tasks that you would want to handle
within an azure subscription we're
seeing automation accounts do all sorts
of different things in subscriptions
that we're dealing with but primarily
we see things like virtual machines
being spun up or spun down in the azure
environment for things like cost
management or for update management
applying updates to any machines that
need updates in that azure virtual
machine infrastructure
so there's a lot of other things that
you can integrate uh automation accounts
to do but
in order to utilize the automation
accounts to do things in the
subscription frequently we'll run into
credentials that are tied to the
automation account itself so these can
either be clear text credentials that
end up hard coded in a run book
this is bad not a good practice but we
do frequently run into it as a reader we
can potentially read those run books
with read-only access and get those
credentials out of there
platform level story credentials these
are stored credentials that
are in the automation account itself at
the cloud platform level there's a
section called credentials where you can
store credentials in the automation
account
and then run as accounts that are
tied to the automation account itself
so as an owner of a subscription we can
set an
app registration that is tied to the
automation account itself
now
this application or
i guess service principle uh is then
used as a run as account
and that authenticates within the azure
runbook itself with a certificate we can
actually access and extract that
credential using a runbook we'll show
how we can do that in just a minute here
that's super handy as the run as
accounts are typically set up as a
contributor or at least as a default
configuration the run as account is a
contributor on the subscription
and then from a key vaults perspective
if any key vaults are being called from
the automation account typically being
used with run as accounts we can
potentially use that run as account to
access the key vaults we'll talk about
that in the slide here
so uh doing the password
dumping manually here we can utilize run
books themselves we can view the run
books very simply by hitting the view
button and reviewing the source for the
runs runbooks uh
very very simple here
then actually pulling out the stored
credentials we have to get a little bit
more complicated with our powershell
code here so we can see in the
screenshot here that we have two
different sections for pulling out
credentials the top one is for the
stored credentials at the platform level
the bottom is for the run as
certificates now we don't need to go
line by line but the core of it is the
top section here we get the credential
we cast that out to a username and
password variable and then write that
out to the output of the run book from a
kind of manual perspective i
definitely recommend just running this
in the test pane itself if you've got
contributor rights and the ability to
write a run book i would just write a
temporary run book run that in the test
test pane which we'll see in the next
slide here
and
look at the output there
some of that will be logged within the
logs itself but it won't be run as a job
so the output won't be stored in jobs so
it's a little bit more stealthy there
with the run as certificate extraction
here that's something we really don't
need to dive too deep into here but
essentially we get the certificate
associated with the run as account we
export that to a pfx file
go base64 and then you can take that
base64 and write that back out to a file
on your end and then later use that for
authentication as the app registration
tied to that run as account
so in the test pane here we can see up
at the top we had test test as a
credential and we can see the mii or the
start of the base 64 certificate there
out in the test pane now from a
practicality standpoint you're probably
looking at this oh i don't have to
manually put in a runbook like this
and deal with all of this so we've
automated this within get ac passwords
and also protected those credentials as
we'll see in a moment
so uh as i mentioned
protecting the credentials here if we
were to run an automation account
run book and export
usernames passwords anything sensitive
from that automation account that could
potentially be dumped out in clear text
in the output for the automation account
job so we run that run book you got
clear text credentials in the output
someone with reader permissions could
read that jobs output
and potentially get access to
credentials they shouldn't have access
to so as a pen tester we don't want to
leave an environment worse than we
showed up to it so we want to make sure
that we're protecting that data in the
output
doesn't necessarily apply for the test
pane as we talked about earlier so what
we're going to do is encrypt that output
with a certificate so that we don't have
to worry about leaving clear text
credentials in the output
so from a microburst perspective we just
generate assert locally upload that with
malicious run books and then decrypt
everything when it comes back down
client side
so uh
one of the things i wanted to kind of
touch on here that's kind of similar to
what we talked about in the app services
section is utilizing the run as accounts
to get access to key vault so
in a very similar method to what we
talked about manage identities with app
services we can use the run as accounts
that may have key vault permissions to
read keys and secrets out of a key vault
we've written automation into microburst
with the get ac key vaults automation
to upload a malicious
automation account run book that then
lists all of the key vaults and pulls
out any available keys certificates
anything like that from the key vaults
this was technically addressed by
microsoft by a cde there were some
default configurations associated with
that
we put out a blog post
related to that that
kind of goes into more detail it
explains all of that stuff but we don't
need to cover that here so something to
keep in mind as you get access to
automation accounts is you may be able
to hit key vaults from that automation
account
so uh doing this with azpowershell
certainly easier but this is one of
those more active gatherings of
credentials it's not like we're pulling
down a single configuration here
we're actually actively running run
books in the automation account to pull
out credentials
so for each of the automation accounts
we're just going to list out the
available credentials the connections or
run as accounts and then upload
malicious run books typically with the
get a z passwords we have everything
randomly named for the runbooks so it'll
be pretty easy to identify
which runbooks are ours and that way we
don't have to worry about conflicts with
naming or getting confused with which
runbook we're running
in the subscription itself
get the output from the job output
delete the runbooks from the automation
account
and then create a local authentication
script to utilize the run as
certificates which we'll kind of see at
the end of the demo here one quick note
about running get ac passwords for
automation accounts is
avoid hitting control c to stop the
powershell function midway through
dumping credentials for automation
accounts as we're uploading these run
books to the automation account if we
stop the function before we're able to
delete the run book you end up having
kind of orphaned run books up in the
automation account that we need to go
back and clean up after the fact again
we don't want to leave the environment
worse than we started so i want to make
sure that we're cleaning up after
ourselves in the automation accounts
if your computer crashes or something
else happens uh you know there's nothing
that you can really do about that at
that point otherwise go in and manually
delete the runbooks at that point
but something to look out for because
i've definitely had that problem in the
past when i thought this this runbook's
never going to end and i've spent plenty
of time waiting for those run books to
complete so some to look out for there
so moving on to storage accounts storage
accounts are pretty simply named as for
what they do but they're a file storage
service in the azure cloud there's
multiple different types of files and
kind of areas that we have within the
storage accounts themselves but at a
high level we've got storage account
keys that gain or allow us to gain
access to the storage accounts
themselves through things like the azure
storage explorer and underneath that we
can access other things like files cues
tables blob storage anything like that
in addition to that files themselves
that are stored within the storage
accounts may potentially contain
credentials so with access to a storage
account you may be able to pull out
configuration files or read other
sensitive information that might be in
that storage account now this isn't
really easy to automate and pull
credentials out of so we'd recommend
manually doing that just anyways uh
typically requires contributor access to
actually get access to the files
themselves this kind of breaks down to
the data plane management plane
permissions and
accessing the storage account keys but
we don't need to dive too deep into that
in terms of getting access to the
storage account keys to actually load up
something like azure storage explorer to
gain access to the storage account
they're available in the portal they're
also really easy to rotate so if they're
ever compromised or you just want to
regularly rotate the key
it's just that simple recycle button
down there to rotate the key
so one thing to note about storage
accounts is that they are used by cloud
shell and we've got a blog post linked
down on the bottom here that really
talks about all of the specifics about
this attack but
if you're utilizing cloud shell within
azure there is potential that anyone
with contributor access to the storage
account associated with the cloud shell
could potentially overwrite the image
files that are mounted up in cloud shell
to potentially run commands
and gain access to another account
within the subscription
so if we have a global admin that's
utilizing cloud shell and another user
who is a contributor on that same
subscription where the cloud shell files
are being stored for that global admin
that other contributor could potentially
get access to the cloud shell for a
global administrator now there's
restrictions you can put in place to
help protect those cloud shell files
microsoft has some good recommendations
as to how you can lock those down but in
general we kind of recommend against
using privileged accounts with cloud
shell as that could potentially allow
for privilege escalation so the process
for that's pretty straightforward you
get access to the img file for the cloud
shell itself modify both bash and
powershell startup files uh
i would recommend doing both because you
don't know necessarily which cloud shell
a user is going to be using
and once those startup files are
modified you re-upload that to the file
shared that hosts the cloud cloud shell
files and then the next time that cloud
shell is opened up commands are executed
as that victim user
so it's not necessarily the most
practical attack in the book it does
take a lot of time to download that five
gigabyte file to modify that img file
it's not a guarantee that that
privileged account is going to log in
with cloud shell you can potentially
phish somebody with a link for the cloud
shell
url and get them to go visit the cloud
shell it is a legitimate link and the
second that they open that up that
starts kicking off those startup scripts
so you might have some look there but
mileage may vary uh other recommendation
there is those uh
img files potentially can't contain
sensitive files that you know maybe
there's a setup script that's stored
within cloud shell for that user
definitely take a look at those files as
well as you might be able to pull out
credentials there
so back to actually pulling passwords
out of the service itself it's
basically 10 lines and get a z password
that's even being generous uh
if i got rid of some extra line spaces
anything like that we could probably cut
it down to like three or four lines but
you get the list of storage accounts and
then for each account get the key
two commands very simple
it's really easy to take a look at and
get ac passwords
so the next thing that we want to cover
is azure container registries so this
service specifically stores container
images for container related services in
azure
technically you could use the container
registry outside of azure itself for
storing container images for anything
that you might utilize images for but in
general we mostly see azure registries
tied into things like aks or individual
container instances up in azure
from a passwords perspective you could
find credentials in the container images
themselves as a reader on the
subscription you should be able to pull
down any of the container images and
then parse those for credentials
it seems like a weird ability to have as
a reader you're actually able to connect
with docker up to the registry list out
pull down any of the available images
and we frequently see images containing
credentials service principle
passwords or certificates all sorts of
different things that could be utilized
by the container itself to act in the
active directory tenant or within the
subscription itself so definitely look
at those images if you've at a minimum
got reader access to an acr
additionally there are acr admin
credentials that can be exported for
more of a kind of persistence
perspective or
for just you know being an admin of the
container registry so we can see in the
screenshot here we've got a registry
named netspy we've enabled the admin
user we set the username to netspy and
we have passwords for that those are
long gone so don't worry about trying to
authenticate to those anybody
trying that
but
you know in terms of trying to automate
this it's not super easy to automate the
pulling down containers and manually or
i guess automatically parsing those
container images for any available
credentials but as we talked about that
only requires reader from an automation
standpoint for the acr credentials there
are specific commands to do that and
it's very simple alternatively these are
available in the portal
so
much like storage accounts here it's a
very straightforward get the list and
for each of the registries in the list
get the credentials for it
so one of the
supported services i guess through the
container registries is aks or azure
kubernetes services and this can contain
passwords in a couple of different spots
that we'll go over today
so the services itself runs container
container images within azure in a
kubernetes cluster that gets spun up
underneath the aks service
passwords could be in the virtual
machines that support the clusters
themselves we'll talk about how we can
extract those out of the clusters in a
minute here
because that's a a fairly active process
it's just not a manual grab something
and get the credentials we can either
get service prevent service principal
credentials with that in clear text
or a managed identity token that we can
utilize elsewhere with the rest apis
additionally aks admin credentials can
be exported for persistence from say a
cube ctl type perspective so that we can
run commands on the
clusters after the fact
be able to manage the aks clusters
with that as well
so doing this manually is kind of a pain
uh either for
uh
trying to get the
credentials out of the cluster itself or
the kube config files uh one kind of
handy trick for this uh that i wanted to
make mention of since we talked about
cloud shell previously
is if you do have access to either
the cloud shell files for another user
or access to a cloud shell itself and
contributor level access
you can actually use the get credentials
command with the azcli to get that kube
config file here
and then just cut that out from the
cloud shell and then copy that off to
another system to utilize for accessing
the cluster there if use the dash admin
flag for that command that we see in the
screenshot at the top you can get the
cluster admin credentials
it's not
the easiest thing to do it's
kind of a pain and it takes a couple
extra steps i honestly just recommend
using get ac passwords if the coupe
config files are what you're going after
here
but
it is an option if that's something you
want to do
so from an automation perspective we can
utilize the getaz aks aks cluster
command to list out all of the clusters
and then for each of those clusters
we actually need to use the rest apis
themselves to get the kube config files
that we just talked about
there's not really good support within
the az powershell commandlets to pull
out those configuration files
uh the easiest way that i found was
actually just to use the getaz access
token
from the az powershell commandlets to
pull down a rest api token to then just
reach out to the rest apis and grab
those cubeconfig files
so it's kind of branching out of our our
standard practice with the getaz
passwords where we're not strictly just
using the az powershell commandlets but
we're kind of using them and using the
rest apis as well
so if the cluster itself is configured
with a service principle
we can actually access those clear text
credentials in the azure.json file under
the etsy kubernetes folder
and uh
that one's really interesting so with
the cluster itself there are virtual
machine scale sets that support that
cluster those are created into a special
resource group that's named after
the cluster itself and the resource
group that the cluster is deployed into
but it's pretty easy to identify that
from
the
az powershell commandlets and identify
where that virtual machine scale set is
so by using the
run command feature for the virtual
machine scale set we can just issue a
cat command for the azure.json file read
out those clear text credentials in the
output of that and then get access to
the service principal credentials
alternatively if that cluster is
utilizing a managed identity instead we
can use the metadata service from the
cluster and using that same
azvm ss vm run command
we can
ping the metadata service get back a
managed identity token and then start
going from there
so a quick demo here we have a recording
for a recording but we can see at the
top here we've imported the microburst
modules that include the get az
passwords function
we recommend using the verbose flag here
and we're also using modify policies and
export certificates so that we'll modify
any
key vault policies that we need to
modify to gain access to a key vault and
then any certificates that are in the
key vault will write out two pfx files
in the directory that we're running
the
function from so we can see that we're
getting key vault items here app
services configuration some container
registry credentials storage account
keys
automation accounts are running the run
as certificate gathering
let's see here what else
cosmos db which we didn't really talk
about but that one's super basic we
don't need to dive too far in depth we
can see here we've got a pfx file along
with the azure run as connection ps1
file that we can use to authenticate as
that run as account
and we exported all of this to out grid
view i do recommend using this or
outputting everything to an exported csv
within powershell so that you have a
little bit more persistent file storage
of those credentials if you need that
but outputting them out to grid view
here is also pretty handy for just kind
of quick review of all of the
credentials we have access to
so we're going to scroll through the top
ones pretty quick here but we've got all
of the credentials that we talked about
during the slides here and
as we're starting up the demo here
important things down here at the bottom
we've got the aks cluster service
principle where we can see the client
secret it's a little truncated here but
we have the client id that's tied to
that as well so you can authenticate as
that service principle
and a handful of other credentials so
this entire
entire environment has been burned down
so uh none of these credentials should
work
so
no need trying them but after i recorded
this uh recording here
immediately deleted everything in that
subscription and changed any existing or
deleted any existing credentials like
the service principle
so a final note here uh now that we
understand how to utilize get ac
passwords wanted to talk about a
privilege escalation opportunity that's
in one of the azure default roles
so the log analytics contributor role is
something that we frequently see for
users that need access to the log
analytics workspaces i need to say
modify
any
parsing of those log analytics
items it allows you to read monitoring
data edit monitoring senate settings
anything like that
so
as part of that the
role itself has automation account star
permissions
for the actions on wherever it's applied
we typically see this applied at the
subscription level
so uh one thing to keep in mind with the
automation accounts is by default those
run as accounts are contributors on the
subscription and as a log analytics
contributor it's a slightly limited
uh contributor role so it's really more
focused on the log analytics services we
see here things like virtual machine
extensions you have
some options there you can list keys for
storage accounts but it's not
necessarily full
contributor rights that you would
typically see for a contributor
so uh
using that log analytics contributor
role we can use the automation account
functionality that we talked about
earlier to get access to that
contributor run as account now it's kind
of a minor escalation here
but it does allow you to move from log
analytics contributor up to full
subscription level contributor microsoft
actually recently addressed this in
their documentation they intend on
removing the automation account rights
for the log analytics contributor role i
actually recommend utilizing a custom
role to basically apply any permissions
that you might need to for specific
users in that subscription
so uh once we do have that run as a
certificate we can then authenticate as
that
full contributor as the run as account
and that can be super handy to
potentially escalate privileges here
so uh given that it's not fully
addressed in the role yet i assume that
it might be viable for a little bit
longer here but i'm guessing that
microsoft's going to fully remove those
rights relatively soon here so something
to keep an eye out for
so uh well we do questions here this is
uh a recording but uh we'll leave
the information slide up at the end here
before we get to the questions here i
just wanted to do a couple of thanks
here uh for the microburst contributors
jake josh thomas we've had a handful of
people that have contributed to the
microburst toolset i want to say thanks
to all of those folks and their
contributions we've talked about several
of the functions they've all helped on
earlier here and uh slide design
assistance from sofia and that's by
thank you for the microburst with a
knife i really like that
and then uh for that basic auth kind of
login hack for app services uh mcomy on
twitter same person that does storm
spotter definitely go check that out
and uh yeah thanks everybody
so here's some additional information
here we'll leave that up during the
questions hopefully and
if you want to access microburst we've
got the link here the netspy blogs also
available and some specific get a z
passwords blogs these slides themselves
will be linked out for my twitter i'll
most likely host those up in azure as
pdf
thanks