
okay on to our next talk which is called get your head in the clouds by Sha Verity Sean take it away good afternoon can everybody hear me yep we sure can little rusty with the zoom here and there but okay very good thank you so hey everybody hope you're having a great besides Austin uh my name is Sean vity um a tester of Black Hills information security and uh I want to talk to you about some of the um fun things I've been discovering lately about applying cloud pen testing ttps to app testing whether that's um web Testing mobile app testing or even a little bit of uh desktop or thick client um testing so with that let's get
started there we go okay so topics to discuss uh I want to talk about why I think it's interesting uh we're going to talk about using selenium uh which is a quality insurance tool to automate your testing we'll talk about a a couple of different Technologies in AWS um to include Cognito uh I'll touch a little bit on the instance metadata service and how that uh comes into play with uh any cloud pen testing ttps or any sort of app testing that's hosted in the cloud uh we look at apps stream a little bit it's a pretty interesting technology um I'd never heard of until about six months ago but it's pretty cool if you
get to play with it um also touch on a little Azure scenario uh that turned out to be pretty interesting during a recent pen test and the last section will be kind of a couple uh things to look into uh it won't be necessarily any concrete ttps but it's certainly like a couple of things I'm thinking about you know are there potential attack factors and we'll talk about that as we get to that section of the presentation so why is this interesting um first and foremost uh personally I think pivoting is a lot of fun no matter what shape it's in uh shape or form whether it's pivoting within an active directory environment from one host to
another or if you're pivoting uh from a web app into like the underlying operating system or pivoting into whatever that environment is when you move from one environment to another I just find that really interesting another reason that I think it's interesting is there's a decent chance that the app that you're testing was recently migrated to the cloud as your AWS um as a result uh some of those defensive controls the traditional ones that we have been you know testing against for years they might not be as robust as the on Prem iteration of that app was so the first uh topic I want to touch on is um fighting automation with automation basically when um talking
about fighting automation so some of the we use this use case of recapture so a couple of the recapture flavers are essentially um solving JavaScript challenges which is a problem if you're using something like burp Intruder because Intruder doesn't have functionality to solve a JavaScript challenge for you and include that in the request um another good use case for using uh automation to fight automation is uh if you encounter Amazon Cognito uh for authentication and something that you're testing uh one of the default protocols that it uses is secure remote password protocol SRP which is really complicated uh we'll see that in just a second here um so the first use case recapture like I said it relies on
solving JavaScript and that's how it figures out if you're launching automated attacks um or not um it's you know it's it's kind of nice like these two particular flavors of recapture um because it's pure JavaScript it runs in the background it's minimal impact for the users um you know much better than having to click all the the traffic lights or boats that you see on the highway type thing um problem is as a tester though it it breaks typical Intruder attacks as I alluded to earlier so the workaround that I've used before is to automate the browser uh we'll jump to the next use case um so Amazon Cognito it's a it's a basically an identity uh provider
service that uh Amazon AWS provides and uh you could see this uh during a web app you could see this during a mobile app test I've seen it um during a it was a mobile app test that had a web app for the administration of that U mobile app service um yes driving on so as I said earlier Cognito uses this protocol called secure remote password protocol um if you look at the picture on the right that is a screenshot from Stand for University's website I did a little bit of cursory research on the history of this protocol and it looks like it it might have started at Sanford um but the takeaway is if you look at it
that's a breakdown of how SRP works and the key distinction or takeaway is the password is not transmitted across the wire so burp can't see the password you can't Mark the password payload and your Intruder attacks which is a problem if you're trying to do brute forcing um you can see some of those parameters there SRP uh and whatnot uh as far as testing and looking for clues that you're running into SRP in your burp logs you're going to see parameters uh that start with the name SRP um you know to be honest this protocol kind of reminds me of TLS it looks like uh there's like a session key generated and that's how the client and
server um authenticate each other without sending the password across the wire I'm not an SRP expert though but that's my very quick analysis of this protocol so again back to why are we talking about this this is a really hard thing to this would be very difficult if not impossible to implement in the burp um it goes back to my theme let's automate the browser for stuff like this so if you look at the picture on the left um that is a screenshot of a login form that I made for a demo app we'll do a demo in just a minute here um and then the screenshots on the right inside of that bubble is a couple screenshots from
burp that's what the request looks like when it goes across the wire you see it it's really complicated you got the srpa it's this huge hexad decimal thing uh there's and then in a a subsequent request there's a password claim secret block looks like a you know crypted something there's a signature so there might have to be like a signature matching looks like a lot of coding and math um I that's not my strong suit so I that's kind of what prompted me to look for an easier way forward with testing something like this and that's where selenium IDE um comes into the picture so it's really easy getting started with selenium IDE it's a browser plugin uh it's I think
it's available for pretty much every major browser I know chromer Firefox I've used it on that I think I've even used it on the the the Microsoft version of Chrome Edge I've used it in there uh works just fine it's usually pretty easy to get up and running with it uh you don't have to dig too far into it another nice benefit of using selenium IDE for um some of your test cases is you can save your attacks and reuse them so that's good if you're you know you test something and then you're asked to retest that thing like one two or even three months down the road you could start with your selenium script to kind
of refresh your memory and bootstrap how you need to retest the thing because you probably forgot after three months so I want to touch a little bit on some strategies uh when you're using selenium uh to automate some of your testing uh the first thing that you want to try is just try recording with selenium there's a a button or an icon in slum it looks like a record button uh go to your app click the record button do the thing log in whatever it is that you're testing and that usually works um interestingly enough uh it did not work when I was putting together the demo for this talk I had to dig a little bit um
uh through the Dom and you know basically tell selenium where to look for the elements that I wanted to uh mess around with and update and whatnot so that would be your second or backup strategy uh you would essentially start with Dev Tools in your web browser mock it up with JavaScript and then just copy the JavaScript over into selenium um selenium is pretty easy to get the JavaScript running in there so you can automate it all right with that we're going to see a real basic demo um this is really just going to log into that app uh this app that uh I made for the demo is just a simple node.js demo app it logs in if
you submit the correct password and it's using Amazon Cognito on the back end and uh I think it's in this demo it might be the next demo but you can kind of see how complicated the the thing looks um underneath the hood when you're looking at a login request with burp that being said let's go ahead and get this started all right so here's the logging in and you can see all the requests going by with burp there that's manually logging in you wouldn't want to do a Brute Force attack where you're guessing like hundreds or thousands of passwords or whatever you're doing or a password spray for that matter so this is just kind of
looking at the inputs and outputs just during a login request it's if you ever done any sort of web app testing this is obviously um much more complicated than most web
apps now we're going to take a look at that login automating it with selenium and basically a quick walk through here so we've got five steps or five commands first one just opens the the login page and then you see these little snip of JavaScript here here here and here U so the first one basically selects the username field and then it writes the username the next one selects the password field and writes the password and the last one uh there's a a JavaScript event that needs to be triggered in order to Kickstart the SRP process and the final step is clicking the signin button but we'll see what that looks like when you run it with
selenium
so there it is it's nothing too crazy at this point uh again just to give you an idea I don't know if you're like me but I like seeing things get automated I just have fun watching the browser do things uh without me clicking anything I just find that fascinating but uh all right so that's a basic selenium uh login there so where you'd want to use this uh more practically speaking is if you're you know doing web app testing like one of the things that you're probably going to have to test is uh brute forcing you know does the app have protections against brute forcing so uh you can can do that with selenium essentially you
would start with building that basic login script and then you can do loops um inside of selenium and the boxes that are here on the right kind of show what that would look like in selenium basically you would create an array uh of all your passwords right here uh and then the next step you'd Define your Loop and so uh password list will be the name of that Loop and then password will be your iterator uh I put in here the pause command that's something that can come in useful if you're running your selenium scripts and you're seeing that they're failing for some reason try to putting a pause statement in there you know for uh one second two seconds I got
3 second pauses it's in millisecond that's why it says 3,000 um but put some pauses in places where it looks like your script is breaking down and a lot of times that's enough to get you through uh whatever it is you're trying to automate and then finally you got to close the loop okay so this next demo will be a Brute Force demo um you know here we see that same JavaScript code there's an array of passwords we defined our Loop here um there's a pause statement there I got another pause statement towards the end I found that was necessary in this case in order to keep selenium running uh to do this automated password
guessing another uh side note with automating brute forcing the taxes you can easily Swap this you don't have to Brute Force you could do a password spray you know in that case you just put like an array of usernames and tweak your script and then put the single password in the password field with that let's see a quick demo there we
go all right this is just looking at the code inside of selenium password list is the array name and passwords our iterator pause statement and we run
it so you can kind of see in the upper leftand corner if you watch over here incorrect username or password which is a good response means there is no username enumeration probably nice and vague and then there in the final guess uh we see see that the password was
found so one thing that's really neat kind of uh this will tie into the next demo um going back to Amazon Cognito um Cognito is a pretty cool Service uh if your app talks to Cognito or it's tied into Amazon Cognito Cognito will give you creds uh when you authenticate um by default maybe spy design um I forget but yeah anyways you get creds which is really fun um you can kind of see that in the burp screenshots here so in the request I've logged in and then the response there's a few names that are highlighted the access key ID secret key and the session token well those values would go into a AWS credentials file and that
credentials file is used by the AWS AWS command line interface uh to start doing cloud pen testing essentially uh it's really easy to get started with the AWS CLI if you've got debn or buun or Cali uh it'd be just an app to install AWS CLI um yeah and then so once you get those creds your next steps are basically going to be to ver verify audit and escalate um verify is just a nice thing um that you want to do occasionally especially in this case because if you look here the session token that's a that's an indicator that these creds are going to expire some point so you can use the AWS STS get colar identity
subcommand uh to figure out if your creds are still good you know you do that occasionally like say you're testing something with AWS CLI and you find that wow why isn't this working anymore you know one of the first things you can do is just check like are the creds still good because they might have expired so the audit step um there's lots of different tools um there's the one that's in in this screenshot AWS service inom um there's weird AAL uh a whole bunch of tools out there pacu pacu Pac Rhino security Labs really cool tool lots of tools out there to audit AWS um essentially what these well I can tell you what this one basically
does it's automating AWS CLI commands and subcommands to figure out what can these credentials do um and so that's what you do here and you can kind of see those same um names the access key secret key and session token here are just command line parameters to the tool then finally escalate that's where say you do your auditing and you find out oh okay I can see well these credentials allow me to do fun stuff um in I like I can create access keys for other users that's uh basically what this SC screenshot is showing here I've created an access key for the AWS Cloud admin which in this particular case happens to be a highly
privileged user within the account and time for another demo
here we
go right so basically in this demo we're going to see picking up from The Brute forcing attack we'll see where um you get the a WS access key after you authenticate and then I I skipped the audit step in this demo just because it it takes a long time uh for demo purposes anyways uh to do that auditing where it's checking all the things that you have access to um and we skip straight to the escalate uh in the demo or regenerate an access key for the AWS Cloud admin account or user excuse me so here we've got that request you can see over here there's the
creds and we're just going to copy all that stuff into a credentials file and the credentials file would go in your home folder under uh AWS directory so AWS CLI can find it
and so the reason you have to use this file um is because we've got the session token you need the session token for this particular access key because it's a temporary access key u with AWS CLI you can configure um persistent access keys with a configure command but in this case because we need a session token you have to fill out the file or credentials file and so there's the final step there or we use those credentials and found out that the credentials from here that we got from logging into the web app uh could be used to generate an access key for an AWS Cloud admin now we can do all sorts of things within this AWS
account all right a little bit about the instance metadata service um this is definitely like a fundamental concept uh anytime you're doing any testing of anything that's in the cloud uh so you'll see the instance metadata service imds in uh AWS or a uh in AWS um the there's two versions you got version one and version two um version one is definitely uh older than version two obviously uh it it tends to be enabled uh within ads environments though uh even to this day so if you can uh see if you can get AWS access keys from the imds uh using the version one method which is just as it looks like on the slide it's just a simple curl request to
that non-routable IP address so this is an IP address obviously it's non- rotable this is something that needs to get executed on the AWS ec2 instance um so scenarios where you might be able to do this is if you know you've compromised that ec2 instance or if you've got a vulnerability that lets you do remote code execution or maybe there's a server side request forgery um that could help you get uh the access Keys using version one of the imds in ads so V2 is a little more secure it's it's going to make make it a lot more challenging uh to get access Keys through like an ssrf and the reason is because of the things that are
highlighted in yellow there um you've you got to use an unusual method the put method you have to send an atypical uh request header that X aw ec2 metadata um to get a token and then you have to use that token in a subsequent request uh again using another atypical request header xaws ec2 metadata token so usually like say you're exploiting like an ssrf A lot of times to to read the response it's as simple as injecting like an iframe and then which which will do a get request for you just fine um and that can work with imds version one with imds version two you can't really do the iframe thing and send a request with those unusual
headers so just something to be aware of um if you're trying to get access keys from something that's hosted in AWS Azure is a little bit different it it almost seems like Microsoft was a little more Forward Thinking I this actually presented a roadblock uh for me recently in a test uh they've I've highlighted there in yellow to get a an access token in Azure you need that atypical header metadata true to go out with your request to get an access token for an Azure instance um I had a situation a test a couple months ago where had uh JavaScript execution and like a PDF rendering thing on the server and it would render JavaScript
and so it did ssrf stuff um and I was injecting iframes and I put the Azure uh request to the metadata service and I got back a response as an error message saying you can't have yeah you're missing the right request headers so again something to be aware of you know if you're testing Azure or AWS you know even if the the attack fails like it did for me a couple months ago it's still good to see that failure and the response because then at least you know like what was it that stopped you and perhaps you could find a workaround or at the very least you can tell uh the customer like hey this is what happened
it looks like this prevented the attack etc etc all right Switching gears to another really interesting technology in AWS called appstream uh I first came across this uh while testing a desktop app or a thick client um before he started the project I thought okay cool we're going to get the going to get the the th Client app I'm going to you know build a VM I'm going to build a fuzzing engine and we're just going to fuzz this thing get you know crazy inputs and monitor it with one debug and see what happens and then we did the Roe call and found out this thing is hosted in AWS appstream I was like what is that I have no idea
what appstream and so uh I got to learn what AWS appstream was through that project and found this is pretty cool uh the long you know long long story short what do you do if you're testing something in AWS appstream um hack it like you would a Citrix virtual app you know look for uh restricted desktop escapes uh I've got a link down here which has like a ton I don't know maybe a couple dozen different methods of escaping a restricted desktop environment uh and I think I used this during the test and it it worked really well so the AWS appstream architecture this is a highle view this is a very basic um uh di diagram or architecture
of what AWS appstream could look like and it's got the the flow of how the user gets into using the app that's being streamed essentially they they log in I apologize for the small pictures in the in the slide here they'll log in which brings them to a portal and then in that portal here they get to select the app that's going to be streamed and after they're authenticated in the back end what's going on in AWS uh there's the streaming Gateway and there's ec2 hosts and they all live in a fleet there's a stack and it kind of does some access control stuff um image Builder is where the app is built and configured and all this gets you know
delivered to the user through a web browser so some some key concern considerations if you're testing something in appstream is uh these apps are hosted again on ec2 instance they're not persistent so and they have like a default expiration of 16 hours so once the session is over you know 16 hours is up uh whatever progress you've made with hacking the ec2 instance that's underneath that app it's gone um you know maybe you want to you want to do that because there's probably not as good of logging and if if you know you can compromise this AWS appstream thing like at will like yeah it might be a good way to go if you need to like
establish like more persistence though I'd recommend you know making an effort to get outside of that um underlying ec2 instance you know as soon as possible because it's going to expire so some terminology uh this is hopefully really helpful for you if you end up testing it or you're working with an appstream administrator you'll have uh at least a basic understanding of what they're talking about um three big terms here Stacks do shown it earlier uh I think of stacks as Access Control it's handled in the stack configuration of the app that's being streamed there's there's different ways that access to the streaming app is handled the administrator might uh distribute one-time URLs they might have
some federations set up with thirdparty Service uh there's also options to persist data like you know using S3 this is also where the copy Pace policies are established for the app uh the next one is fleets uh basically fleets where you uh you think of like vmw or virtual box this is where you're managing the hardware settings you know how much how much dis space is this thing going to get um CPUs uh active directory this is also something that I found to be really interesting when I was testing something in appstream um this might be familiar to some of you I didn't know you could do this but there's like an there was an
entire active directory environment hosted inside of AWS and that that whole thing supported this AWS appstream instance so it's it actually looks like it's reasonably simple to um hook an AWS appstream instance to an existing aw excuse me ad environment that's in AWS but just something to be aware of it's something that could be there you know ties into the earlier point of if you need to persist and you want to persist um outside of that ec2 instance there might be a whole active directory environment behind that app that you could compromise and live in um the next term images and a couple of terms to go with that so the term on the Right image Builder this is the the
tool that the appstream admin is going to use to build the image that gets streamed it's you know it's basically think of it like a golden image every time the app gets spun up this is the golden image you know it gets saved in the image registry and it gets deployed um to the user when they start using that streaming app so what does an appstream breakout look like uh this is a super basic one uh using you know in this case I I built something to stream calculator off of a Windows host so to break out of calculator because when you log in all you would see is calculator you could you know using this potential method you
could check the help menu uh which would open in this case Internet Explorer then you type the path to um cmd.exe which brings it to the download you select run it you're logged in who am I now you do stuff uh inside of the ec2 instance and then remember this thing's hosted in AWS and you've got that imds service that runs on the ec2 instance so make sure you take advantage of that and and get those ads access keys while you're in there like I said using version one it's just a simple curl request uh for that URL that you see there in the screenshot and now for a
demo okay so here you see on the the left this is what it would look like for the user there's the app that's getting streamed through the browser um you'll also see how do you do like copy paste um into and out of uh here because we need to uh copy the access Keys into our attacking system so we can do AWS pen testing uh from the attacking host unfortunately it's not as well it's probably a good idea um it's not as simple as just copying uh the strings out of your browser window and pasting it into this text file there's a kind of an intermediary step and you'll see that in the demo to copy the credentials
over so here this will start with a very basic breakout to get a shell on the ec2 system we're just navigating to cmd.exe
of course we want to run it okay then now we're going to get the AWS access keys from the imds here this demo of what it looks like to use that copy paste functionality just right click it in there boom you've got your access Keys we can start copying all that
out contrl V paste it into your credentials
file and then finally that access
toen so here do our SDS get color identity and boom we know that we've got good creds and you can use those with your favorite AWS Cloud auditing tool
all right Switching gears from AWS to Azure uh I wanted to build a demo for this um based off of something that I saw during a test recently but after thinking about it and looking at how to build it uh it would have been really hard to to replicate it so uh this is mostly true um the end State uh uh I didn't actually Global admin um but I did get a very there was an application that was assigned to the administrator that let me pivot and other stuff but anyways that would have been really hard to rebuild so that's why it's kind of it's faked the whole thing is fake but it it did happen but I didn't want to
share details about the customers so anyways with that being said the name of this story is my Azure profile was hacked so the I was testing a web app and I came across some clues that this thing was using Aid um you know there's a there are jwt's involved in decoding JWT I saw Azure in there like an Azure group name another hint was at the login page I would type in the username and as soon as I switched or clicked inside the password field it it boom it like put a domain name and a backslash before the username I was like wow that looks a lot like active directory and so that was another hint um you know as I was moving
forward in the test I thought about well the big hint was during the Roe call I'm pretty sure the customer told me that we moved to Azure recently um so neither here nor there but uh so with that being said I thought this thing's hosted in a I wonder if these accounts I wonder if these accounts would work like in Azure ad um so I messaged another tester at bhis and I said hey if you uh if you think you got you know credentials for something in Azure ID what how do you know what's the the Quick Check we'll log into the Azure portal like oh okay so he gave me the URL to the Azure
portal and so I I did that and logged in I was like ah okay cool I'm in the Azure portal this is fun um so I saw something really strange though when I was logging into the Azure portal I was looking at my user profile like my user profile I'm not looking at someone else's like my own um I couldn't edit my user profile but I saw that my scanner did like I you know I saw like a crossy skring payload or something for my name inside of azure ad I like that's weird why why' the scanner you know get to change my name but I can't and I'm logged into Azure ad so it got me to
thinking um you know I'd scan the app with admin creds it is fine is a QA environment I do not recommend doing that for production environment uh for obvious reasons but there was a feature in the app when you're logged in as an admin that allowed you to update user settings inside the app so it got me to thinking like well if you know there's a service account on the back end of this web app it's got privileges to update my you know settings inside of azure D I bet I really wonder if this thing can update other Azure ad0 accounts um and you can kind of see this is a mocked up uh request of
you know what that would look like like say changing the password in that web app here um you know with a the initial password change I've got my username I'm just nobody special in Azure ad you know what if I change that to somebody's special in Azure ad so the next logical step at this point was I need to go spelunking and Azure um spun and Azure is a lot of fun there's really lots of rabbit holes you can go down um but here's a few um areas that I would suggest starting with uh if you find yourself in this situation so take a look at the user's profile look at their group memberships uh look at any applications they've been
assigned any assigned roles and all of that can really be initially accessed through the Azure active directory uh icon over here on the side window so spelunking an Azure ad uh I see my profile um and I I find this user called somebody special in Azure like oh this is fun so I see assigned roles you know they're not a member of group or application or anything else but they they've been assigned a role and then so when you see assigned roles in aure ID think to yourself assigned administrative roles you can probably do administrative stuff so in this particular user happens to be the global admin which is like domain admin and Azure ad
essentially so this is a really good you know user to compromise great admin to compromise so I jump back to the web app change the password request you know instead of nobody special I Chang the username to somebody special and you can see his success so bada bing bada boom Global admin impres and that's the end of the Azure story uh so finally I mentioned earlier there's a couple items that are really just for your consideration I consider them occasionally myself um I came across this thing in a web app test called b2c azer business to Consumer um I didn't know what it was at first but I saw this domain b2c login.com and a subdomain off of that I
thought what is this b2c login.com so I started Googling it and I found out oh it's it's tied into Azure ad that's interesting um so you know how do you find it uh if you're uh if you got burp running you're going to see a request uh go out to subdomain of b2c login.com uh and that's your clue that there's some authentication that's being outsourced to Azure b2c with the thing that you're testing some other Clues you'll see URLs that have b2c onecore um within the URL so that b2c onecore gets prepended to the names of user flows that are configured inside of b2c uh some other hints uh that b2c is in play is you might see Azure you know
somewhere else in another URL or again within a a JWT So This falls under the something to consider category because you don't get a whole lot of access within the Azure ad portal as a BT b2c user I don't think you can even log in to the Azure ad portals a B2 SE user by default um but it'd certainly be interesting if you know somebody found a way to work around that um and there's a vulnerability that you know allowed a b2c user to I don't know get into the Azure portal and do stuff so anyways U hopefully somebody finds something cool with that you know I'm certainly going to look the next time I run into an app that's using
b2c uh next one uh awss 3 buckets as you're doing app testing so there's a few different ways to find it um that I've it's worked for me um the easiest is and this has become one of my favorite extensions is JS minor JS Miner will find lots of neat stuff buried inside of JavaScript for you um and it'll let you know if it sees hints of AWS S3 buckets other things you can do to look for S3 buckets is uh look just search your burp history for aws.amazon.com uh see if there's anything there or if you're uh testing something and you don't see either of those Clues maybe you're testing something and uh you see
the app calls out to this URL and uh you nav start navigating up to the root of that uh that URL and you see a request that looks similar to that well that's that's a hint that you've got an S3 bucket in play and I've highlighted there the name the name of the S3 bucket and this particular example is test to so there is a ton out there about hacking in the cloud um so I want to leave you with basically some some training ideas Some Cloud CL methodology ideas and some tools uh that would probably be useful for you for doing Cloud pin testing in case you come across any um uh cloud pen testing
attack vectors while you're doing any sort of app testing there's some really awesome training the bhis offers uh B has a really great breaching the cloud class um to to go with that you've got BB's awesome modern web app testing course those two would like go hand inand really well for for this kind of thing to come up with some uh interesting attack paths as far as Cloud uh pentest methodology there's a really nice you know collection of cheat sheets that Bo has put together and made available for free on GitHub i' highly recommend looking at that and then finally there's a list of a few tools that first on Ral security Labs I think
they've got several tools there like the pacu and some other stuff weird AAL is another nice one cloud n that final tool that's listed there Scout Suite so that's um that's a nice Tool uh for I I had a customer ask like hey can you tell us if there's any like you know misconfigurations basically nessus um for for like a cloud environment and I I said oh yeah okay and so I used the tool Scout suite and it would audit and check and presented really nice like dashboards uh type views and stuff like that and you would risk rate some potential misconfigurations for the customer to look into um but Scout Suite would be the tool for that kind of
thing that brings me to the end of the talk uh there's my Discord handle um so are there any questions at this time I don't see any questions in Zoom uh but there may be some waiting for you over in Discord on your channel um attendees to remind you that Sean has agreed to pop over in Discord and chat with you about this talk for a little while after he's done so uh take your questions there I guess um I can't I can't read any out to you though Sean thanks for the excellent content um and uh I don't I'm sorry I don't want to take away control from you but um I think we'll take a quick break and
transition at the bottom of the hour to our next talk so we have 11 minutes break everyone sounds good thank you thank you
everybody