Can you guys hear me now?
Alright, so hello everyone. I'm 800XL. As already mentioned, I'm with DEF CON group 619858, San Diego.
And just a few quick fun facts about me.
The first ever hacking movie they ever saw in the mid-80s was WarGames. If you haven't seen it, you should watch it.
My first computer, and also inspiration for my handle, was Atari 800XL, which I received at the age of 15.
And that was quite a life-changing event for me that shaped my interests and passions going forward.
Just a quick note about Atari 800XL, just to put things into perspective, it was an 8-bit computer with 64K of memory.
And that's how I learned how to program.
My first DEF CON, and it's been quite a while since then, was DEF CON 14, and that was at the Riviera Hotel and Casino.
I believe the casino is no longer around, it's been demolished. And that was back in 2006.
Now, the thing about DEF CON, the first DEF CON, I clearly remember driving back home with a bit of sadness that the event was over.
And dreading, you know, how many months it will be before I can come back to Las Vegas and attend the next DEF CON conference the following year.
And, you know, as it turned out, DEF CON Groups was a perfect remedy for that. And we'll get to that in a bit.
So, a little bit about San Diego.
For those of you who don't know much about San Diego, it's located in Southland, California, on the border of Mexico.
And it is the 8th largest city in the United States, with population approaching 1.5 million.
We are known for great microclimates, and it's, you know, beautiful beaches.
But, you know, to be honest, I only go to the beach like 5 times a year, even though it's close.
And, as you know, DEF CON Group names are designated by dialing area codes.
And in San Diego, the original dialing code was 619, and we also have 858 and 760, which is like a North County.
And another fun fact is that we are 534 kilometers from Las Vegas, which means that, you know, when DEF CON conference is on, it takes about 5 hours, you know, drive to get there.
Or you can fly, and that takes like 30 minutes.
Group history.
The DEF CON Group 858 was originally founded by Techlord.
I've actually never met him in person, but I did read about the group on DEF CON forums after I went to DEF CON first time in 2006.
And I was involved in DEF CON Group 619, which was founded by Renan01, Carl.
He founded the group in 2007. Unfortunately, that group fell apart.
In 2009 and 2012, there was no activity from DEF CON Groups, and I decided in December of 2013 that it was time to revive it from an activity.
And, you know, we've been going very strong since then. We are approaching our 7-year anniversary.
Our DEF CON Group leadership, you know, the responsibilities include organizing and running the meetings, organizing various events, a DEF CON party that we have annually, solicit people for talks, which is probably the hardest part, manage social media presence, order pizza for the meetings, etc.
The three key people and other organizers for our group is Mr. Bill. He specializes in our social media and Twitter and Twitch, Braxis, and Tokso. Shout out to you guys.
There was a pandemic... which is in the North County of San Diego.
And on average, we had approximately 30 attendees at each meeting, sometimes even approaching as many as 40.
Currently, because of social distancing guidelines, which we follow, we conduct our meetings on Zoom.
We also stream the meetings to Twitch.
Every week, Mr. Bill also organizes virtual happy hours. In between meetings, we collaborate on Slack. Our Slack has approximately 190 members.
Our team at VaporSec competes in various CTFs, and that's pretty much on a weekly basis. It's a very active group.
We have had occasional workshops. At least twice a year, we have Lockpicking Village. We also have done a wireless workshop in the past.
Now, one other fun thing to do for us is, usually around December, we have a crap meet.
This is when members bring books, electronics, any kind of cool unwanted items for exchange or just give away.
Usually, we come with more stuff than members.
It's a fun event, I recommend for other groups to also have it.
Once a year, we organize a party at DEF CON for group members and friends.
Hopefully, next year, when we have an in-person DEF CON, ping me, I'll get an invite.
Speaking of things that we do, I should mention that two years ago, we had our DC858 electronic badge.
The project was led by Elwood and Ager.
Thanks to the badge sale process, it was possible to fund the pizza for our monthly group meetings for the entire year.
I should also mention that Elwood and Ager made a significant donation on behalf of DC858 to the Women in Security and Privacy organization, which is very cool.
I should mention some of the cool talks that we've had in the last 12 months.
As you can see, talks cover a variety of topics.
We are lucky to have many active contributors in subject matters as members.
I should also point out that when we had the meetings in person, we had two to three talks at the same meeting, which is quite busy.
Thanks for starting and growing your DEF CON group. I think we are very successful and very active.
I recommend advertising on DEF CON forums, which is a good way.
However, the activity on DEF CON forums is cyclical. Usually, it's more active, more people visited right before DEF CON and not so much afterwards.
But it's a good place to start.
And obviously, utilizing social media and Twitter and hoping for DEF CON groups' retweets is a great way to get members to attend your meetings.
I also recommend to be very specific and have a topic for the meeting rather than just meet and greet or have beers.
I recommend to have a topic of some sort.
Don't be afraid to host introductory one-on-one talks. Your talks don't have to be advanced.
It's also okay to have a short lightning talk. Maybe bring an idea or a topic to your group or a project that you want to work on.
Invite guest speakers. I think now that we have all the groups engaged, it is possible for somebody from a different group to jump in on your Zoom and give a talk as a guest speaker.
So you should reach out.
You can get an invite to the unofficial DEF CON groups' Discord that we have and ask for guest speakers there.
I've already mentioned that having workshops such as lockpicking is a good way to get people interested in your meeting.
And also having a craft meet or something like a war driving contest. Simple things that get people interested.
Where to meet?
We've chosen a local pizzeria which has a private room and a couple TVs where we can project presentations, which is very convenient and also gives us a little bit of privacy.
Because we have our own room and I think that particular Wednesday of the month would probably be the biggest revenue for that pizza place.
Obviously, that's not possible now since we are following social distancing guidelines and we are doing virtual talks.
But when things get back to normal, most likely we'll go back there.
Frequency of your meetings. I guess it depends on how much content you have.
If you are in a really large group with a lot of talks and a lot of volunteers to give talks, you may want to do it twice a month.
But if you have fewer people, maybe quarterly, doing those meetings quarterly is more appropriate.
It's very important to keep the momentum going, so definitely set up a chat, Discord or Slack, so your team members can communicate and collaborate in between meetings.
Also, don't go at it alone. That will most likely lead to a burnout. Build your leadership team. Distribute responsibilities. Delegate tasks as much as you can.
Sometimes real life will take over. You may not be able to participate and you want to keep your group going. It's important that you have other people to fall back on.
If you'd like to connect with DEF CON San Diego, you can reach out to us on Twitter, Facebook, watch our Twitch streams, or email us.
And that covers the introduction to DEF CON San Diego. Up next, we have a DC-858 member, Smoochie, who will give his talk, so let's welcome him.
Hey, Dr. Axelsen. I'm from the San Diego DEF CON group and I'll be giving a presentation on Microsoft, how to save yourself from their Active Directory and Identity and Access Management design.
So, with most of my talks, I always like to remind everybody that we are definitely in a privileged group that may get a little numb to the phishing campaigns and the jokes out there.
For example, the Nigerian Prince and the IRS calling you. Those are stuff that we make fun of, but people fall victim to it.
I personally had to deal with that with my in-laws. Microsoft called them directly and wanted to fix a problem of theirs, and that ultimately caused an issue that I had to help resolve.
These things that we're aware of, just speak out about obvious things. Make sure your in-laws, your family that are non-technical, that this isn't something that happens in the real world.
Microsoft is not going to reach out to you because you're a valued member. And the IRS is not going to call you and tell you that they're going to sue you if you don't send $100 this very instant.
And of course, no main business does any type of commerce in Apple gift cards, so that should be a dead giveaway.
In broad strokes, what we're going to talk about is what's wrong with Microsoft, good or bad, and how you can design a system, secure your system, protect your system against these by default settings and design decisions by Microsoft.
One of the biggest ones that you need to take into account as you design any system is to always assume a breach.
There are no safe zones anymore. With the rapid change of software and hardware that's out there, there are going to be bugs.
There are going to be unintended backdoors, there are going to be unintended consequences that no person is going to be able to keep track of.
So as you design any system or as you upgrade any system or as you review any system, always assume compromise.
Assume that at some point, the thing that you're touching is going to have somebody on it that you don't want to have on it.
So how can you help mitigate that concern when it does happen and limit the impact and success that that attacker or anybody who's just making mistakes could have on your environment?
And again, it's not an if but a when of when you're going to have some issues.
You know, the old adage that script kitties are just out there poking around having fun. That's still the case, right?
It doesn't take much to go find tools that are out there. Cali Linux is well advertised.
You do a couple of keyword searches into Google and you can find yourself going down a rabbit hole and identifying tools that will just do this for you, right?
People are out there unaware of the ethical challenges of banging on the front door of someone's network, right?
You can look at the Twitter compromise that just happened. This 17-year-old kid, right?
How many years before that was he just playing around before he actually got deep into the SE and the actual phishing aspect?
And then separation of duties. So, I know it's very easy to just say, hey, I'm your admin. I need full God rights on everything.
Well, that's not how things should be operating, right? You should have very specific controls.
You should have separation of those responsibilities.
You know, for example, your exchange or email administrator probably shouldn't be the same person as your domain administrator, right?
Because the impact that person could have is significant.
Now, in smaller shops that you're unable to do this, you can start to separate those duties with accounts.
So, you can have an exchange administrator account, your domain administrator account, and your user account just to make sure that any one account or any one person can be audited and does not have that wide blast radius if something does go bad.
And when installing anything on your network at home or at work, take into account the install permissions.
It's far too easy to say, hey, I need root rights or hey, I need domain admin rights and the installs just go great.
But there are unintended consequences with service accounts being created or permissions on files being set up in that process that may cause harm in the future.
So, on average, it takes about 24 to 48 hours from the first hour being compromised before someone's able to escalate their privilege to domain administrator or root rights.
Now, once that person has domain administrator rights on your network, your network is essentially theirs.
For those that are not used to Microsoft and Active Directory, that's full God rights.
That's modifying accounts, that's changing passwords, that's removing computers from the domain, that's modifying files, that's anything and everything that they would want to do within the kingdom.
And the persistence of a user once they have those... notified or able to identify them normally with tools that are out there in network land today.
So, a lot of these things have to have outside help to come identify those.
FBI has been reaching out when they've identified traffic from the nation state actors, Russia, Iran, all of those guys.
So, a lot of these companies don't even know that they're there.
And it's these third parties that come in and say, hey, we've seen this traffic, can you validate that this is valid for your company?
Or they confirm that they have actually been compromised.
And once those credentials are compromised, they're exfilling data, they're modifying data.
So, it's very important that we get a tight rein on those elevated permissions.
So, the way that Microsoft does password hashing is not unique to every domain.
So, you have a user, the username is user, their password is password1.
Well, Microsoft will take that combination of username and password, create a hash based on their algorithm.
Either for Landman, which is the old way of authenticating, or NTLM, which is the new land manager.
And you get a hash.
Now, the great thing is that no matter what domain you're on, that combination will always have the same hash.
So, if you're at alt space domain and you put in user1, password1, that hash that you get in NTLM will be the exact same when you go to Microsoft and put in user and password1.
Which is an issue in itself, right, because you can start to build this domain knowledge of standard usernames and start to create those passwords.
And because Microsoft doesn't solve the passwords, does not create that blank data in it, again, it's not unique across people's domains.
So, what can be done and what is available is you can start to calculate these hashes, right?
So, for username administrator, password1, that creates a unique hash, password2, password3, password4.
And then you can also pull hashes and start to look up within that database or the rainbow table and know what the password is.
So, it's not a lot of effort. And again, there are tools out there that do this for you.
And basic process for a lot of people, you know, they use the administrator account with the administrator name.
They don't change the name itself, right? There's still the guest account.
There's still a lot of built-in stuff that they don't change that are pretty consistent across the board.
And we're actually going to get into that with one specific account and why that's important.
So, taking the passwords and the hashes. So, where can you find outside of having those hashes?
So, within group policy objects, people hard code in username and passwords for ease of use, for installation of capabilities, or just out of pure laziness.
So, map network drives within those group policy objects.
Creating local users, right?
Create a local service account on the box that's running a specific application.
Well, that password is in clear text most of the time for those accounts.
Data sources, printer configurations, update services, schedule tasks.
All those require authentication and that password and username have to be stored somewhere.
And nine times out of ten, it's going to be stored in clear text within group policy objects.
SysVol for batch files. So, if you're able to create a custom batch file to delete a file on logon or to create a folder structure on logoff, that's going to take some credentials.
Those passwords are probably within that batch file itself to run.
On the domain controller, so you can use volume shadow copy and create a copy of the actual domain database itself, the ntds.dip.
And on that same domain controller that you pull that dip file off, the decrypt key is actually in the registry.
Now, the good thing is that the decrypt key is tied to the actual machine itself.
So, it's not one universal decrypt key for every domain. It's for domain controller one has one decrypt key, domain controller two has a separate one, and they are unique in that regard.
And then you can run tools out there. So, hopefully you all are aware of these ones.
So, Mimikatz is one of the holy grail tools out there. It kind of does everything. It's a Swiss Army knife for how to take over a domain.
That's created and deployed by a general way.
There's Cryptman, a powerful script that's pulled by Microsoft.
And DCSync, which is a capability for you to basically synchronize data from a domain.
So, authentication within Active Directory is pretty straightforward. Kerberos has been around for quite some time.
But in broad strokes, you have a view here that says, hey, I need access to something.
Here is who I am. The domain controller validates that and says, yep, here's a ticket. You are who you say you are.
Workstation says, cool, I want to go do this, get access to this server, go check out this website, whatever is Kerberos enabled.
Server says, cool, yep, you are authorized to do that based off your groups and your rights.
Send this over to the server, your application server, and you just have that back and forth like TCP packets.
Sounds good, right? You have separation of duties within the authentication.
You don't have one machine saying who they are or who they say they are.
Everybody validates who they are. It's a circle of trust. Everything is great.
But those tickets that are created by the domain controller are assigned by a specific account.
And that account is the Kerberos ticket granting ticket account.
And the hash that it uses for encryption is the hash of that username and password just like Microsoft does for every single account that I talked about before.
So, using tools like Mimikatz, you are able to impersonate whoever you want to impersonate once you have that hash of the Kerberos ticket granting ticket.
So essentially, you use Mimikatz, you read the domain, which is read-only to every single account on the domain.
So as long as you are on the domain, you can read that information.
You use Mimikatz. It's a very simple command to pull that hash.
Once you have that hash, you use Mimikatz to create that golden ticket.
At that point, you are able to sign and create any ticket that you want.
So the ticket that would normally go from user station to domain controller saying, hey, I'm an admin. Here's my hash. Give me a ticket that says I can do what I want.
That's essentially gone.
As the user, you're passing that ticket that says, I'm already authenticated as an administrator. Let me do what I want to do.
So, how would this kind of all work in the grand scheme of things?
So, starting on the left as patient zero, we'll go through the black.
Patient zero is infected. You've clicked on a bad link. You've installed some malware.
You're subject to a phishing campaign, whatever the case may be.
What are the ramifications of that happening?
So, starting in black on the left, they have access to that machine.
Well, any good attacker is going to set up a C2.
So, they're going to beacon back using some type of remote console, most likely Netcat.
But essentially, the traffic is going to initiate from that host out to your command and control center.
Once they have that foothold within the machine, on the machine itself, again, it can read all of Active Directory because it's read-only by default.
They can start to install keyloggers and look what data is on that local machine.
They can also grab the credentials with the LSAT service, which is the service that stores the hashes on every machine.
So, what I was saying was, as I talked about in the beginning slides, we're going to design for compromise.
We're going to understand that the endpoint is going to be compromised at some point because of zero days, because of phishing, because of all of the multitude of vulnerabilities that are out there that could be used to take over that host.
At the very least, somebody shares their username and password, or they put it underneath their keyboard.
Whatever the case may be, there's a patient zero.
Now, that patient zero machine on your network, that person, any attacker, is going to try and set up a command and control setup.
And it's going to be a remote console.
So, the communication is going to initiate from that host out to the command and control system, out into the internet.
So, most firewalls out there are ports and protocol firewalls, and it's saying, hey, anything initiating from the internet, do not come into my network.
Anybody that's saying, hey, I'm 443, going out on 443, 9 times out of 10, that's already permitted.
And you're not going to know the difference between them going to Google HTTPS or some other server HTTPS, because there's no break-and-inspect.
We're not looking at the traffic, any encryption that happens between the host and server.
Once we have that foothold within that host, you're able to pull all of the Active Directory credentials.
Sorry, you're able to pull all of the Active Directory information, because Active Directory is read-only.
So, you can pull those GPOs, you can pull the usernames, you can understand structures, you can pull your organizational units, your OU structure,
and start to build that greater recon on that domain that you're on.
And then, of course, actually on the hosts themselves, you can put on key loggers, you can look at the data that's stored on there, and you can pull those credentials.
Now, using any type of privilege escalation path, so a vulnerability or an exploit, or that user's already logged in as an administrator, you're able to get admin rights on that box.
And so, from there, you're able to pull hashes, you're able to look at active credentials, you can change passwords on the host, you can do anything you want to do on that single host.
Now, the money's where you're able to reach out and gain access as a privileged user within the domain.
And so, everything that's within the yellow at this point is assumed local user or non-privileged user.
When you pass the hash on the host out to another server or system, again, that hash is your username and your password in a single string.
And so, the other servers can adjust that and say, yep, give me that hash, great. Pass the hash attacks are well documented out there, and you're able to get access as impersonating that user.
Now, the trick for escalation is really nuts and bolts in the separation of duties, right?
So, we don't want people logging into their daily driver machines, the machines that they check their email with, the machines that they go to the internet on as a domain admin.
Sad to say, that's still very much happening, and I understand why, good or bad, as a domain admin, you can do whatever you want.
There's nothing restricting you. You don't have to act for access. Everything's presented to you.
From there, you can use tools like Mimikatz to grab credentials, to grab the hashes, and then you can start to create your golden ticket.
And at that point, you can impersonate anybody that you want, and your persistence is pretty much guaranteed.
So, what do you do about this, right? This is built-in Microsoft capability. They're all about collaboration and integration.
So, these are the trade-offs that they've made as a solution to say, we want this to move fast, and we want things to work together quickly, over security.
So, as an individual, you can implement break-and-select to get the ability that, say, when you go to https.google.com, you're swapping certificates with that server that says,
I am google.com, here's my public key, send me data, we will encrypt this communication.
When you pass that through any of your next-generation firewalls, they can't see anything but encrypted HTTPS.
This allows for that communication from a host that uses an F5 device to essentially terminate the encryption, so your F5 device essentially impersonates Google.
You can see that HTTPS traffic and then move on to encrypting that with the end server that you're communicating with.
And that way, you can look at the payload.
Now, this is different. Break-and-inspect and TLS offload is different from your normal load balancing, where your load balancing, your host comes in and makes a connection with the F5 device, and then traffic isn't cleared back to your server.
So, it's really about what you're looking to protect. Are you protecting your data, users connecting to your stuff, or are you trying to connect your users connecting out to other servers?
It's a trade-off that you're going to have to make. There's obviously implications on speed and throughput, and devices like F5 are notoriously expensive.
The other thing that can be implemented if you are Windows 8 or above is Credential Guard.
And Credential Guard is taking that LSAS capability that stores those hashes and virtualizing it.
So, if they take over that host, they're unable to pull any hashes that have been used on that machine.
And that's very, very important because if a domain administrator has logged into that machine, that may not be the user that's currently logged in.
The hash is still stored in LSAS.
And that's very important because a lot of times domain admins or people with escalated privilege log into machines to fix a problem or to install software.
Using Credential Guard allows you to virtualize that and keep that isolated from somebody who has compromised that local machine.
And this fundamentally breaks Mimikatz.
And like I said before, Mimikatz is the bread and butter for taking over Active Directory.
You can also do AD segmentation.
So, partitioning out where that information is going to live.
Having domain controllers live within a completely separate domain, this completely separate force from where the data lives.
So that way, when a user is ultimately compromised, what they're able to access and what they're able to view and what they're able to pull is extremely limited.
Because again, designed for compromise, with all the threats that are out there and the change in the software, it's very hard, if not impossible, to keep up on everything and have everything patched.
To a level that accounts for all of the new stuff that's out there.
And so, what you effectively do is that you take your privileged accounts, your enterprise admins, your domain admins, and they live in a completely separate domain.
Meaning that isolated domain controllers, isolated servers, isolated virtual environments.
Because you can backdoor into Windows domain through, if you're using VMware, you can use VMware capability to get escalated rights within your domain control if it's virtualized and then take over the domain itself.
So, you're really trying to draw a clear line between what your users can access and what can be accessed in a nefarious manner.
And then, using Microsoft's suggested terminology, so they have their tiers where Tier 0 is your highest level, your forest domains, your enterprise domains.
And those live separate and they can communicate within, but you don't talk down, right? So, you don't log in as a forest domain into a resource within a Tier 0.
You can always escalate up, you never escalate down. And that's to keep those credentials isolated from any of those hosts that ultimately may become compromised, right?
So, again, that idea that an enterprise domain or domain controller wouldn't log into an endpoint because that's going to be the first line of attack.
And what are some of the standard stuff that ultimately lead to compromise is your access control list.
So, users out there, your group membership, your help desk persons, never going to need to take over accounts, right?
They may need to reset the password. Best practice would be to put something in between that, right?
A service account that you would have heavily monitored that whenever it's used, it needs to be tied to a help desk ticket.
Something that you can start to draw those parallels in your logging so you can understand anomalies that are happening.
This one happens a lot where you have good isolation, you have a domain admin account, you have your exchange account, you have your user account.
And there may be joe.admin, joe.exchange, joe.user, but the password's all password1.
So, that one's going to get you. And again, it's all about not salting, so it's the same hash.
So, if they have an administrator account with password1, it's going to be easily found because every other domain that has the same username and same password has the same exact hash.
Service accounts. So, service accounts are meant to be targeted quote-unquote user accounts that you would create that execute a specific purpose.
And that specific purpose needs to be locked down.
Service accounts are created for a specific capability and it's just set it, forget it.
And sometimes those passwords are shared among other service accounts, sometimes those passwords are written down, sometimes those passwords are default from the vendor.
And elevated permissions on the workstation.
So, again, that user logging into the machine with the elevated permissions, that goes to the internet, that checks their email.
If they go to a nefariously crafted link or they download a bad file, that file is being ran under that user's permission.
So, you really want to isolate that account to just what it should be doing, meaning that if it's a user, it's user rights.
They have enough rights to log into the machine, to boot up whatever applications they need to boot up and nothing more.
Anything that they need to do on top of that, say developers or whatnot, they should be elevating to another account to do that specific capability.
And then application-wide listing. So, most of the time, your secretary's machine, never going to need to run PowerShell.
You see PowerShell running on that box, it's a dead giveaway that something's wrong.
Maybe on your developers, you have a little bit of leeway because they're doing other things.
But you really need to understand who's out there, what are they doing on their machines, and only allowing the specific applications that you want them to allow.
And in that instance, if they do download an application, let's just say they think they're downloading Spotify or Zoom and it's not what it's supposed to be.
They execute that, it's not authorized to run, that binary never kicks off.
And LAN hash. So, like I spoke to earlier in the presentation, LAN manager is an old way of hashing username and passwords.
And it's very, very easy to crack. It takes really no processing time at all.
It's only in place today for legacy applications.
So, if you do have a legacy application out on your network, that thing probably has some issues as well.
So, you really should identify why you need that enabled.
If you do, identify why that thing still needs to be on the network, why that application still needs to be on the network.
And probably look at some type of deployment plan to getting that on to a newer operating system or a different capability.
Or maybe even a software as a service solution, so that way you really start to lower your risk to your network.
And enumeration is understanding what's out there.
If somebody who stood up that network put every single user in the domain admin rights group because that was the easiest thing to do, your risk is off the charts.
So, you need to look at your groups, you need to look at your users on a pretty regular basis to make sure that nothing's changing.
If you're in a position to be able to deploy new solutions or maybe even procure stuff, there's a lot of products out there that you could download open source or buy that can heavily monitor group membership and notify you of any changes.
In some instances, they can even block it based on business rules.
Volume shadow copy on domain controllers.
You know, domain controllers themselves replicate within themselves.
You don't need to do volume shadow copies of a file structure on your domain controller to another server.
You just need to disable that.
And if you do have a scenario which you need volume shadow copy, please reach out to me.
I would love to understand that problem.
What you're supposed to do with this whole file is essentially a shared member product that has your path files on it, that has some of your computer files on it.
Understand who's reading that, who's pulling the information, and who has access.
And monitor that with any type of logging capability and send you alerts as soon as something's out of the norm is done on that.
If you can block peer-to-peer communication.
End-user machine to end-user machine, you should.
I understand that there's a lot of solutions out there that would require peer-to-peer capability.
But if you can block the adversary from leapfrogging to other hosts, your peers that are generally less secure, you should do that.
And then, of course, log, whitelist, and block if you can PowerShell.
PowerShell is extremely powerful.
You can do a lot of things with that.
And again, I don't think the secretary would ever need to run a PowerShell script.
And any of your developers that might, you would look to see what access they truly need and give them an account to do that in a very specific scenario.
Alright, with that, that is my presentation. Thank you very much.