 Hey, what's up DevCon? This is Cedric Owens. I'm super humbled and excited to be here, and I'll be talking about basically giving a perspective of what red teaming looks like in macOS environments here in the year 2021. Some background information on myself. I'm a full-time offensive security engineer on the red team side, and I've been dedicated red teamer now for the past four or most five years. Prior to that, vast majority of my career has been on the blue team side, doing incident response, threat detection, threat hunting, both in the Intel community and in the private sector, and so even as a full-time red teamer now, I highly value collaborating with blue team just to help uplift each other's tradecraft and move the needle forward in our organizations. I personally enjoy macOS post-exploitation as an interest area of mine, that in infrastructure automation. So whenever I do have free time, I'm typically working on projects that fit into one of those two buckets. Also as an early 80s baby, I do enjoy 80s and 90s nostalgia, such as what you see here in the picture. Just reminds me a lot of my childhood, and it's even cooler now to see my kids playing with a lot of these same toys or watching these same shows, and it's just kind of cool to see the legacy of these things live on. I am on Twitter, handle etset owns, where occasionally I'll post blog posts or tools that may be of interest, so check that out if that's of interest to you. So what I plan to talk about today, first one being, why do we even care about macOS, especially in a window-centric world? Why are we even here for this talk? Overviews of common tech environments and what the tech stacks look like in organizations that are heavy Mac users. Options for macOS payloads and post exploitation and a look at how the different options you pick usually will have a pro and a con associated with it. We'll also look at other attack vectors. So things in macOS environment that become attack targets that may not themselves necessarily be macOS, but you'll find them often in macOS environments, and then we'll end off talking about detection opportunities to look at from a blue team perspective. So again, first question is macOS, why do we care? And to your point, if you're asking that question, most Fortune 500 companies today are still window shops, and you may find there that maybe 90% of their endpoints are windows, maybe five Mac, five Linux or Chromebooks. But there's a sliver of companies in the San Francisco Bay Area, your Silicon Valley companies that are basically the opposite, where you may find 80 to 90% of the endpoints being Mac, may find five to 10% or somewhere around there being windows endpoints and you may have Chromebook and Linux mixed in. So essentially it's the flip of what you'll see in your Fortune 500 environments. It makes it for an interesting environment to assess from an attacker's perspective because there's often a mentality, well, if we're not an enterprise window shop, then we're more secure. And I can understand the line of thinking there, but it really depends on how you implement your Mac slash cloud environment. In other words, if you have keys laying around that are in code rebos or other easy places for an attacker to find, you may find that even though you've migrated off of a Windows Enterprise environment, your environment can still be easily compromised. So we'll talk about that a little bit more as we go. It is a slowly growing trend that at least that I've been seeing where newer companies are adopting more of a not quote unquote, non Windows Enterprise environment. And what I've noticed is that Active Directory is typically going to be there because it usually is the best LDAP solution for enterprises. So even in these environments, you will have Active Directory, which will be used to back your authentication, but just your typical end to end enterprise rollout of Windows will be different here. And I like it too, because it allows, as a red teamer, it allows you to point out different vectors that really have nothing to do with Active Directory and compromising domain controllers, but other very interesting vectors that can still be impactful and in some cases devastating to your organization. So I think it's a very interesting environment from a red team perspective. So first, we're going to look at common tech stacks and what you might encounter in a common tech company in Silicon Valley area. First thing is there's a concept of realms or environments. And so you may have a corporate environment, a dev or stage environment, production environment. And so here's an example. We'll walk from left to right where you may have employees that remote in using an identity as a service solution. Two common I'd ask solutions are octa and one login where the employee authenticates with their username, password and a two FA token, which is usually going to be like an octa verify push or duo push to their mobile devices. Once they log in, they're now inside of their identity as a service portal and have access to a lot of different productivity applications, like email, you may have Atlassian products like JIRA, you may have Salesforce, internal Git, even custom application servers all accessible to the user based on their roles in Active Directory. Then you also on the production side, you may find a combination of cloud based production hosts and on-prem. And you may find a lot of different things there, but typically in production, you're going to find like your customer ready code and maybe even customer data that's stored here. And you're going to find things like your build hosts, your CICD pipeline. You may find some cloud hosted services and servers there. You may find HashiCorp for managing application secrets. And of course, you may have some on-prem stuff. You may have Jenkins on-prem or even in the cloud. We have some Windows servers, segment environment of Windows servers there. So a lot of different things going on here and it makes it interesting because of course, there's a lot of complexities and sometimes with more complexities comes more opportunities from an attacker perspective. Another thing to point out is on the bottom left, I have rough percentages over the different endpoints. So like I'm showing Mac OS being 80% and Windows being 15 and Google Chromebooks being 5%. It's just a rough, rough numbers there. Some organizations, you may actually find Mac being higher or closer to 90%. And the Windows population being even smaller. So it's interesting because with Mac being such a high, high percentage of endpoints in tech environments and engineers using their Macs often to either do dev work locally on a Mac or log into like a cloud hosted server or an application server or a jump box from other places that they can do their development work from there. You typically may find that there are sensitive keys, tokens, credentials, things like that that are stored on the endpoint. So really end to end this makes for a very interesting environment to assess from an attacker's perspective. Next I'm going to talk quickly about some different ways that Mac OS is deployed from an enterprise perspective. One option is like custom deployment where you hire your own team and they build out some custom solution to manage and hook into Macs and control them and push policies etc. And basically loop back into your LDAP solution. Organizations that do that custom tend to be maybe like your big five in tech. So something like your Apple or your Facebook, Google may all be custom where they have the money to resources to throw at that. But typically what I find is outside of the big five, most organizations in the Silicon Valley area, most companies there tend to use a solution that they purchase such as Jamf Pro, which is really the most common that I've encountered. But I also noticed products other products that are up and coming like Kangey. And so we're going to take a look at those. Also wanted to point out Kalem Hall and Luke Roberts and their Black Hat Black Hat talk this year did a really good talk on abusing Jamf for remote management and how an attacker can leverage that to control and compromise manage Macs and enterprise environments. So highly recommend checking that out. So there's a very high level overview of common Jamf deployments that you may see. You have typically have an admin server. If you're in an environment that uses Jamf, you can run Jamf, check JSS connection from terminal and that will return the URL to your Jamf admin server. You also have your endpoints which have the Jamf agent on them that receives the configurations for the admin server. You also have self service that runs on the endpoints and allows users to install software versions that their IT department has already vetted. So essentially they don't have to open tickets for these. They can just install them from self service. Really nifty way of doing things. Also Jamf does include the ability to have remote management where admins can remote into the screen sharing or other troubleshooting on the endpoints. And typically that is through an admin account that has SSH access into the endpoints. Oftentimes from what I've seen in enterprise macOS environments, SSH is enabled on the endpoints and the IT team will use an account that can SSH in and it has pseudo rights on the macOS host where they can perform administration. So that's a very common thing that I've seen in environments. And of course one thing to be aware of is if that is how your environment is set up, it becomes very similar to the problem on a Windows side years ago about dealing with SMB and local admin passwords and laps coming out being a solution to randomize those passwords. Well the same thing would apply here if remote management is being used. Is it a static password or is there a random password being used? And of course if it's static password then that means if you get that password you can now access any mac in the environment over SSH with pseudo rights and SSH has full disk access so it bypasses privacy protection so that could be really bad for the environment. So just something to think about there. Another thing, another aspect to look at here is if you run as a red team or you run a phishing exercise and you target Jamf admins which is usually a active directory group in your environment that limited people have access to that the organization has identified to administer Jamf and you fish them, you gain access to their active directory credentials and then you use those credentials to log into the Jamf management server, Jamf admin server. And depending on the environment like that that admin server may be behind Okta where 2FA push is required or it may not, maybe just be locally in your environment without 2FA and you can get access that way and then from there you can start to push policies and scripts to run on the endpoints and really there you almost, you essentially do have full control over your macOS environment so this is something an attack path to think about as well if you're in an enterprise mac environment. But now even when it comes to Jamf there's really so many different ways to implement Jamf there's really no one way to do it. So we're just going to look at a few examples. First example is probably the simplest where macOS hosts are bound directly to AD and in that case you can run a different DSCL or LDAP search commands to pull AD information directly from the domain controllers just as you can on the windows side like for example with net user commands like that. You can do the same here and tools such as MacHound which is a macOS port of Bloodhound or Cody Thomas's Bifrost which does curve roast manipulation those tools would work and apply in this environment since the host the macOS hosts are bound directly to Active Directory and Conquerium directly. Another example is via access via a tool called Nomad where in this case macOS hosts are not bound directly to AD so if you try to query Active Directory from these hosts you won't be able to reach it directly that way and essentially the user logs in locally with a local account and then they do network authentication for access to resources which is where Nomad comes in and that Nomad then performs curve roast authentication on their behalf and so and this if this setup is how your environment is configured then there are files that you can read from that you might find interesting on an assessment such as like different P lists that I have mentioned here also things like K-List, KCC, Cody Thomas's Bifrost tool that does curve roast manipulation those tools would still work since curve roast is still happening from your end point so something to think about there. Another example same setup or similar setup here where your macOS end points do not have direct access to Active Directory to query domain controllers directly in this case they have Jamf Connect on them and Jamf Connect is synced through Akta and Akta does the syncing with Active Directory when it comes to authentication and so like a federated model there and what's interesting here is like just in this example Active Directory controllers are domain controllers are walled off by like firewall rules or VPN access maybe a specific VPN profile that you need so again if you try to query directly this would not work but if this were how your environment is set up there still are some interesting P lists and files on the system that you could pull from to learn more about the host and the environment that you're in such as what's here the two files highlighted above. So as I mentioned AD is still present in macOS environments but it just looks a little bit different from what you see in your enterprise windows environments and I enjoy because it gives me a chance to focus on something else outside of Active Directory and of course when you're and these types of environments are heavy Mac and cloud implementations so a lot of interesting things to look at so let's talk about that. First we can talk about initial access in this case targeting our targeting our identity as a service portal so the two most common are octa and one login tool that that is pretty popular here is Evil Jinx 2 by Kubogretzky and what it does is you point it to a target login portal it clones that portal and as you basically send out a link to the fake portal and as people log into the fake octa or fake one login portal it captures the username password and then authenticates it to the actual site and does the same thing for your 2FA token so then the attacker is able to grab the token for octa or from one login and port it into their browser using a plugin like edit this cookie and now you're the compromised user and what's so interesting about this attack path is once you're inside of someone's identity as a service portal you have access to a ton of different productivity apps so you got slack think about the credentials configuration files secrets things that people have shared in the slack that may be pinned in different channels think about gmail or google drive people may email themselves passwords so they don't forget or or sensitive information you can you have access to search all of that imagine like your confluence your JIRA tickets things that that may have interesting data there or wiki all sorts of juicy information there and as a red teamer you may opt to take this path and essentially meet your objectives without ever even needing to land access on a macOS endpoint so this is definitely worth running in your environment from both a red and a blue team perspective and one of the big wins for from the blue team side is allowing basically running through your procedures to see if you have this ability into this attack path and if you do do you have the ability to revoke compromised tokens because in this case password resets are great but if you don't revoke the compromised token you're not going to be able to boot out the attacker so a good way to test your detection and response procedures so I mentioned a lot of interesting data in your productivity portals and there are some tools that people have written to actually automate this if you're using this from a red team attack perspective one being a colleague of mine Antonio Piazza he wrote a few different what I call thief tools of gd gder and conf thief to simulate or speed up downloading sensitive files from those platforms also a colleague of mine Brad Richardson over at credit karma wrote a tool called slackhound that does a similar thing if you find a slack token on a host you just feed it and it uses api calls and things that are nature to pull down data as well as a slack pirate so a lot of different and interesting attack paths on this vector so now we talked about identity as a service briefly I'm going to pivot over to the macOS side of the house and talk about some of the basics around macOS from a security perspective I'd like to break it into three different areas prevention detection and removal gatekeeper on the prevention side is essentially the engine that or already the I guess you say service with this policy D is behind it as the engine that evaluates certain file types like application bundles star packages macos etc it looks for files that have a calm dot apple dot quarantine attribute appended to them which the operating operating system appends for any files downloaded from the internet so if a file is of the of the types that gatekeeper evaluates such as macos apps install packages etc and it has that quarantine attribute and gatekeeper enforcement kicks in it checks to see if it's signed and if it's notarized and if not it will block it from running if it does it still does a pop up but what's what's of interest here is that even for non signed non notarized like app packages and stars maco monaries etc the user can still right click open and click through one other prompt to run it despite gatekeeper on the detection side you have x protect which is also part of gatekeeper and it's really more of the malware definitions and blacklisting that I guess you can say comes from like apple intel from where we're real world malware resources or malware sources that they have analyzed and then you have the malware removal tool MRT dot app and that does the remediation from a red team perspective the prevention side of it really is the hardest hurdle to overcome x protect and MRT dot app usually are not much fact usually not big factors for red teamers because we tend to write our own stuff for macOS since it's kind of a niche space and since x protect and MRT dot app tend to look at existing samples for their intel usually when you write your own stuff those those two aspects become less of a factor it's just really gatekeeper that becomes the the pain and headache from a red team perspective other things to think about is the concept of TCC or privacy protection so and that essentially you have certain folders or certain places on disk that TCC protects so you have things like the user's desktop documents downloads all sorts of other places on the system that TCC protects what's of interest though are things that are not protected so the home directory itself and within the home directory certain other sub directories like a dot ssh or dot aws directory both of those would contain credentials and the ability if they're captured to to provide lateral movement a temp directory is also not protected which is why malware typically is dropped there so just something to think about because again if TCC is enforced a pop-up will show to the user what they can allow or deny if like that directories requested before not protected folders there's no notification to the user and access is not prevented at all by TCC if it's not protected by TCC the evil bit and regi did an excellent black hat talk this year around 20 different ways to bypass TCC so definitely check that out they'll dig way more into what TCC is and different methods for bypassing so check that out from an initial access perspective on mac a lot of different options here and they all have different pros and cons you have your maco binaries which are checked by gatekeeper but you typically need a delivery method because most of the time your macos are not going to be double click friendly i mean there are some tricks you can do but just generally speaking you'll you'll use your maco as a second stage payload apps are checked by gatekeeper they're pretty remote friendly because again they're they're packages and they're double clicked usually and so um they are remote friendly but they are checked by gatekeeper star packages are also checked and remote friendly uh that allow users to double click you got a weaponized pdfs uh shell script trickeration which we'll talk about later uh essentially that is a bug that i found in gatekeeper this year and reported to apple and work with them to get it fixed um you also have your scripting languages that are not checked by gatekeeper things like such as jxa which is javascript for automation kody thomas did an excellent job a couple years back of highlighting how powerful jxa is on mac and how it's essentially like an apple script alternative um and some it's kind of interesting because sometimes i'll view jxa as like the replacement for apple script but they're both still around and they're probably both be around for a while of course python is not checked by gatekeeper however mac or apple will remove python from base macOS installs at some point in the future we don't know when but from an attacker's perspective it's just something to keep in mind if you're heavily relying on python uh office macros are not checked by gatekeeper but it is sandbox meaning uh it will be if you gain access remotely via office macro you only have access to certain parts of the disk and certain binaries etc so a lot of different options here got apple script browser browser extensions uh one thing i wanted to point out was that on mac os a dunefist leopid wrote a really neat tool called mystical that is a payload generator for several of these types of payloads where you can provide information that would generate the payload for you i also wanted to point out mythic by kody thomas at specker ops is what i consider at this stage to be the king of mac os command and control because of its innovative use of jxa and has a lot of other cool features with how it's built and how it's managed so definitely check that out from a red and blue perspective quickly going to jump into some different examples so the first example being installer packages and i'm going to briefly talk about script only because they're the most common and pretty simple example here but you have a pre install and a post install script and both require the shebang at the top and exit at the end in order to run successfully they run as child processes of the installer packages so whatever scripts you have running and it runs elevated as root from an attacker's perspective which is a nice plus because any install package that a user detonates and to install they end up authenticating and usually in macOS environments the user is local admin so when they authenticate that installs with elevated or root access on a host as i mentioned before it is checked install packages are checked by gatekeeper but they can right click and open and that's a common technique that's used in the in the wild with real world malware samples so patrick wortel and objective c have a lot of good examples of like real world malware samples for mac os and you can look through their mac malware reports of 2020 and 2019 etc and look for different examples for how these types of things are done like an images included and the user is instructed to right click and press open in order to run a non signed non notarized installer package here's an example a pre install script so we talked about pre install and post install this is example on a pre install site that essentially just pulls down a unsigned a non notarized maco binary writes it to the temp folder and sets the executable bit on the bottom is an example with us being remote these days and so many employees being from home this is an example of how you could add a guard row in there to check for the host name to ensure that it's not running on someone's personal machine but on a corporate machine if it's found to be running on a personal machine it will exit if not then it will perform the the pull down of the payload and set the executable bit and here's an example of a post install script where it just runs the maco binary background it so once you have that set up you can just run this package build command here to generate the package hosted get it to the user they detonated they authenticate basically double click and authenticate through the installation and it detonates in the background and as you can see at the bottom here this is my mythic a screenshot of my mythic c2 server and the payload detonated as root level access another example you have app bundles or app packages where you have the app the name of it with content slash macOS and then a maco binary at the bottom and so to do this a very simple way you could go into xcode create a new project my example i'm using swift here and then you would design a window with buttons icons text etc for a user to interact with once you have that designed and ready to go you go into info.plist for any app transport security so app transport security are restrictions on apple to limit the types of outbound connections that app packages can make so if you're trying to talk out to like a non-https server so just playing at http there's a certain entries you have to put in there to allow that and even if you're talking to an ssl server it does not like self sign certificates so you actually have to get a valid sign certificate for that to work and then of course you set your sandbox accordingly or the settings there that you need and you can add code like here below that uses a dispatcher and again this is swift as a background task to execute a jxa payload that's hosted on a server and here's an example of the window that you could design for the user to interact with and as you can see it can be very convincing and the user clicks update now then the mythic command and control server receives a callback from the user so again app packages are checked by gatekeeper but as you can see here as i mentioned same with install packages same with here you can right click and open so here's an example from the slayer which is a common mac os malware family that's been around for a while of a simple image to social engineer the user into right clicking and opening to run an unsigned unsigned non-notarized app package of course you have Microsoft Office macros they still work they've been around for a while and even today when you i like to do tests with macros where i just will attach it and see let the the email systems antivirus filter scan it and see if it detects it as malicious and one thing i've noticed is that simple strain concatenation is usually enough to get it around those filters so if you're taking like the word exec doing e plus x plus e plus c for example that will get around a lot of the filters we'll look an example a little bit later for that no gatekeeper concerns but as i mentioned earlier it is sandbox meaning you have limited disk access and limited functions or or binaries that are available to you you can still access things such as like osa script curl screen capture python so still a lot of potential there and adam chester who's currently at trusted sec did a blog post a couple years back where he looked at entitlements that office products had and he found that they had one entitlement to drive to drop files outside of the sandbox if the file name was propended with a till day dollar sign so really good research and that technique still works where you can drop files on disk outside of the macula sandbox using that technique a colleague of mine met off bat who's also the credit karma he recently published a sandbox escape where essentially you create a z s h e d v file that executes a payload you zip it in for that zip file you prepend the till day dollar sign in front of it you drop it to the user's home directory you add it as a login item and then on reboot when the user restarts the login item extracts the zip file drops the z s h e d file to the user's home directory and then when the user opens a terminal you have non sandbox call back to your server so definitely check it out a very informative blog post and does still work some example office macro generators from mac os mac fish has been around for a while and honestly that's where I learned I took a lot of my cues of how to write macro generators from mac fish it's got a lot of cool options where you can generate office macros that use python or curl or osa script or combinations of them I also wrote a couple macro generators as well for mythic that uses curl and osa script and I did my own for maxi 2 which is a command and control tool that I wrote for mac os that leverages python I did highlight python and red because again python will be eventually taken off of base mac os install so just I like to highlight it in red so you can be prepared when that happens which is why things like switching to jxa for example is a good option because that that will be around for a while also when it comes to office macros auto open um subroutine is is useful so that when the document is double clicked the uh the office macro can be executed and here's an example here of how I concatenated like the word python and word exec and you see long strings of base 64 characters or I guess in this case hex characters excuse me long strings of hex characters and what those do is in this payload that I've written I basically read from a I read the actual payload from a file read it into a long hex string and now it's just breaking that hex string into smaller chunks so now I'm going to quickly talk about cve 2021 30657 this was the bug I reported to apple this year that was a gatekeeper bypass around the march time frame and where the kind of where the idea for this came from was started thinking about well here's the typical structure of app bundles on mac os you have the app name you have the content directory mac os directory and then there's a maco inside of that so when you double click an app bundle the maco inside of it is what executes and it just has all these other wrappers around it like info.plist etc so I started thinking like what if we put something else here something that's not checked by gatekeeper because macos are checked which is why when you download an app from the internet and try to try to execute a gatekeeper will pop up like if you just try to normally normally run it but in this case what if we put something like bash or python in place of the maco binary since neither of those scripting languages are checked by gatekeeper so I did that that's kind of what led to the bug I found that it worked and it did bypass gatekeeper and I reported this to apple march I believe of this year and they fixed it in short order in big sir 11.3 and in catalina updates from the apple security bounty website they have a section there for user installed applications and access to sensitive data hundred thousand dollars are a really big bounty payment but they have a very you see the two asterisks there next to the first line I wanted to highlight that because apple has a very narrow definition of what they consider sensitive data and in my opinion it's much more consumer focused versus enterprise focused because they they only consider contacts mail messages notes photos or location data to be sensitive sensitive information which makes sense from an individual consumer perspective but when you're starting to look at max in an enterprise like what we're talking about here macos environments where organizations have thousands of users that are using max and they're doing development and engineering work sensitive data on the host this definition certainly should be expanded and in my case my app detonated got remote access and then I was able to access sensitive data which is things like ssh keys aws keys uh azure gcp keys uh other files and the user's home directory the user's uh shell history that contains sensitive information depending on like what they've done so a lot of different pieces of sensitive information that this payload had access to but because of apple's very restricted and limited definition kind of consumer individual consumer focused definition of sensitive data are seeded tiny bounty payment in this case nowhere near that hundred thousand there so just wanted to point that out for researchers if you're submitting things to apple to just be aware of that and the reality is apple may say that this is the the small breadth of sensitive data we care about but from an attacker's perspective like you may have a bypass and you're able to get things that are outside of that window of of apple in terms of like their definition of sensitive data but it's of it's still sensitive data and so that can happen in your case as well where you receive a small bounty payment so just wanted to give you a heads up with that some interesting things about this payload so I mentioned it does bypass gatekeeper and app transport security that we talked about earlier where the system restricts like what websites an app can talk to or what types of protocols you can talk over those things don't apply also you'll have access to non-tcc folders so you'll have the ability to grab things like ssh and aws keys etc off the host and it's very convincing so as you can see here just by copying icons over to my fake app and it's got the one drive logo and it looks looks pretty close and so it serves as a really good payload that the user can just simply double click a dmg or zip and double click the app inside of it and that's it so it's not no need to right click and do all these other things which made this a very powerful bypass and I in my tests I did both with trying a shell script at the bottom of the app bundle as well as having python at the bottom of the app bundle and in both cases they work because neither python or bash scripts are checked by gatekeeper so I was able to get a call back in both cases and here's an example just kind of walking you through what the payload looks like and I'm just showing you here that that terminal does not have full disk access it did not have any folder access as well and gatekeeper set to app store which is the most restrictive level so just wanted to show that that there's no trickeration going on in the background here is the payload that pulls down curl or uses curl to pull down the payload and runs it background it and then there's an osa script message there which is a fake prompt to the user saying thank you for installing this app so you'll see what that looks like a little bit later next I'm using this masquerade script it's a slightly modified version of a tool called apify that's been out for for years that basically took shell scripts and put them in the bottom of an app bundle structure and so that's what I did here is just ran that masquerade script and created a fake app that has the structure of an app but instead of a mako it has the shell script downloader at the bottom of the bundle now what I'm doing is taking the icon from one drive and I'm copying it over to remove the default logo in my fake app to make it look a little bit more realistic and notice that the operating system labels both of them as apps even though in my case I don't even have an info.plist there it just kind of follows the app bundle structure so now that I have my fake app with the logo what I'm doing now is copying it over to a folder and then I'm going to go into disc utility and essentially create a dmg file to host the app so that's kind of what I'm doing here I just moved the fake app over to a folder called hosting and now I'm saving it there and I'm going to give it a new name called real app so it would be saved as real app dot dmg so that's what's happening here so now that that's done you'll see real app dot dmg was dropped there so the next step will be to show that when a user basically to simulate a user downloading it from the web so I'm going to host the real app dot dmg to a local web server here using simple http server and that way I can click it download it and when I download it it will have the same quarantine attribute that a user would have if they had to download it like as part of a fishing exercise for example so I just hosted it here's me accessing it here locally and you can see there's real app dot dmg so just single click it downloads to the downloads folder and now we'll just confirm that the dmg file does have the quarantine attribute that gatekeeper checks we'll take a look at that now and as you can see it does have the com apple quarantine attribute appended to it so now we're ready to take that file that we just downloaded and detonate it and see what happens so you detonate the dmg and inside the dmg is the fake app that we created here in the demo double click that notice no gatekeeper pop-ups anywhere and as you can see you got the fake pop-up there that says thank you for installing this provisioner the fakes to be from the it team and in the background I get a callback from my mythic command and control server so again apple has fixed this but I just wanted to show you what the bypass look like when I submitted it to them other things to keep in mind from tcc a lot of this we've already talked about of what's not protected another thing to mention is ssh is often kind of touched on it earlier but in enterprise macOS environments ssh is usually running by default on the endpoints and ssh daemon it was recently pointed out in the in the um mac security community that the ssh daemon actually has full disk access so if a machine if you're on a machine and you have credentials of the user and you ssh and locally um using those that set of credentials you now can have full disk access bypass tcc so something to point out there the quarantine attribute uh using curl does not append the quarantine attribute just downloading through browsers or through um like bluetooth like sharing files one machine to the next which is airdrop things like that will append it but using curl does not so that's something to keep in mind because I use that in my gatekeeper bypass and from signing a notarization perspective you could totally sign and notarize your payload if you want in order to get around some of the controls but at my personal experience I found that it was pretty pretty painful process and when I did sign and notarize my red team payload I had about a week before uh apple retroactively found it and like um deactivated the developer account and revoked the certificate so it's just something to think about my personally believes probably not worth the time since real malware real world malware samples are you often using unsigned non notarized payloads and social engineering the right click open execution of the payload uh once you're on a host um lots of different things you can do you can again you can grab these system credentials from the host so like aws credentials gcp azure credentials you can look through uh users bash history you look for maybe sensitive files on the system sometimes users might save tokens or uh passwords file mango pdf uh did a really good blog post on cookie crimes things you can do there with um for google chrome so definitely check that out i have a link in the in the uh resources section later to that blog post um of course you can prompt the user for credentials you can do it via osa script or you can do it programmatically to not leave any command line um artifacts you can also search for other interesting files on the host and even this file here on the bottom this login data uh chrome database contains a stats table and that stats table contains the username and the login url for various sites and it's of course it's it's unencrypted and you do not need root to read it and it's not protected by tcc meaning any non sandbox payload can now read from that table which means if you already have the user's password considering oftentimes passwords are reused that table now provides usernames to try that password against for different sites also if you have root access uh you can grab a keychain database and take it offline using forensic tools like chain breaker and so you can gain root access via either install or package which we talked about that gives you root access because the user authenticates or if you get normal user access you can use you can basically prompt the user for credentials and once you get those credentials you can then uh through tools like mythic you can run elevated commands since the user if you have the username and password that user is usually root on their mac so then you can use that to run elevated commands and pull off the keychain so something to look at as well when it comes to persistence lots of different options beyond just launch agents and launch daemons which are probably the most popular for mac os the evil bit did a really good long running blog post on titled beyond good old launch agents which goes like the mac version of beyond good old run key on the window side and looks at all sorts of interesting um persistence options on mac os uh leo pit or doomfist also has a persistent jxa repo looking at jxa implementations of a lot of the techniques that the evil bit talks about in his blog post i also then took a subset of doomfist persistent jxa and did some swift implementations so i have a repo now called persistent switch so you have a lot of different resources there to play with different uh to to look into different uh persistence options and different implementations for mac os uh lots of other options here like vm vm plugin persistence sshrc persistence uh profile persistence zoria chris ross he has a really cool authorization plugin um that like he did a lot of research there so a lot of different options to look into for persistence so some other attack vectors beyond mac that you'll typically will see in a mac os environment one being the build pipeline or also known as the cicd pipeline and the way i like to describe it is this is the process that like an initial concept for code goes through from like the initial draft uh thought our concept all the way through to being customer ready and it hits various stages and checks along the way and what makes this so interesting is there's a lot of interconnections here across different hosts so if you can access one of these hosts chances are you'll get a lot of access and sometimes your build environment your your cicd process will traverse environments depending on what you have implemented in your organization and as i mentioned a lot of integrations like there may be some internal git integration and of course internal git becomes a target internally because there's 10 there tends to be more trust for your internal git and your external git meaning that since it's internal people may feel like posting or committing secrets in your code is not as damaging but ironically that's going to be one of the first places an attacker will look and attack environment is looking through git repos jinkens is often common commonly part of the build process and is usually misconfigured in some way that will allow easy access and oftentimes jinkens will contain a lot of different secrets on it given that given its role in the environment and then of course you have workstations where engineers may be doing development from their max and they have local keys stored there as well quick look at jinkens two common misconfigurations this is the first one allowing unauthenticated build jobs to be executed so if this is present in your environment you can hit the view default new job url and your jinkens host and it will bring you to a page that will allow you to run a new build job where then you can add a single step to execute a shell and you put whatever shell command you want in there could be like running a remote shell or reverse shell payload it could be catting out files on a system that are sensitive it could be querying for metadata service iam credentials if your jinkens host is in a cloud environment and so you execute it and you can see the console output there so essentially this will allow compromise and access to secrets which can then be used to pivot to other parts of the environment another misconfiguration for jinkens that's pretty common is the script console page allowing unauthenticated access so if you if this is configuring your environment you can just hit the script page of your jinkens console jinkens host you'll be brought to the console and then here you can run groovy script and essentially get like reverse shell access you can cat local files query for iam metadata credentials and the metadata service so all sorts of different things you can do here as well a few other juicy targets of course internal wiki so thinking about like all the organizational information system environment information credentials that are there that can be leveraged by an attacker thinking about your internal ticketing system like imagine the environment information that can be learned there or processes and architecture information slack of course we mentioned that earlier credentials keys bpm profiles all that stuff can be found oftentimes in slack another one if you have docker in your environment if dockers configured with unauthenticated api sockets then those hosts can be hit on port 2375 or 2376 usually default ports but those hosts can be hit and shell commands can be run unauthenticated on those and potentially extract secrets out from your containers there of course we talked about internal git so a lot of different juicy targets once you're in a macOS environment outside of just macOS of course you have cloud hosted usually if you're in a macOS environment there's going to be a good amount of cloud there as well and so the entry points for cloud keys oftentimes can be phishing payloads like grabbing cloud cloud keys off a compromise endpoint maybe code internal repos for your internal git so like finding secrets that have been committed there of course your build hosts like your Jenkins as an example sometimes even build logs will write the cloud keys that it used during the build so that's a misconfiguration to check for as well and it's good I think to also test from a blue team perspective to see what your cloud visibility and detection posture is so can blue team see things like accessing secrets in the environment and using those secrets to pivot like different post exploitation examples like on the awsi like looking at secrets manager or parameter store for additional credentials which may provide access to like another environment or a higher level of access assuming into other roles so maybe like an attack I say red team has access to an aws role that role has the ability to assume into another role the role that they can assume into has higher privileges so that would be a form of privilege escalation or lateral movement to see if like blue team can see that attaching policies to users or roles all sorts of different things here that can be done and I think it's worth like running through these types of scenarios proactively or even looking at the mitre attack matrix for the cloud that they have and looking at some common like privilege escalation and lateral movement techniques for different cloud environments so other recommendations on the blue team side is definitely recommend leveraging the apple endpoint security framework it's good both from a personal standpoint so let's say you have a payload a red team or a real malware sample payload you want to understand what it does you can take Patrick Wardle's process monitor or file monitor that that he wrote and you can take it on a sandbox macOS system detonated and then you can look at the endpoint security framework logs it's almost almost like the equivalent of a sysmon for for apple or for macOS so definitely check that out and then you can look for things like suspicious command line executions persistence methodologies we talked about repos that you can use their parent child relationships so things like an office document spawning then sh for example that will be something to key in our course network detection so looking for one host accessing one or many ports on multiple hosts over a short period of time might indicate like scanning or sweeping activity course identity as a service abuse we talked about octet one login so being able to see if you have the ability to see compromised tokens and if so do you have the ability and procedures in place to revoke those tokens of course jinkens abuse so getting visibility into script console abuse or build jobs running suspicious shell commands and then within cloud itself like aws or gcp for example looking at your common post exploitation and privilege escalation methods and auditing you can even proactively audit your roles and see what like you can work with them i guess if you have a cloud security team you all can work together to see what the state of your current im roles are what roles they can assume into and look for like easy privilege escalation paths and see what can be done to reduce those paths lots of different resources here lots of cool people have done a lot of awesome work in the macOS space so this is not all inclusive but just wanted to shout out some good resources for people who are interested in delving more into these topics definitely check those out so thank you all for listening appreciated and if you have any questions feel free to reach out