Hi, DEF CON. So my name is Neil Sikka and today I'm going to be talking about EMET 4.0
PKI mitigation. So EMET is a tool from Microsoft and it's a free tool to mitigate various attack
techniques. So a little bit about me. So I'm a security engineer on MSRC, the Microsoft
Security Response Center. I look at zero days that have been like in the wild or privately
responsibly reported vulnerabilities. I'm an EMET developer. I like blogging after work
and on my free time about technology and security at Neil's Computer Blog and I'm on Twitter
if you want to talk to me or something. So an overview about what I'm going to be
talking about today. So first I'll be going into what EMET is followed by new features
in EMET 4.0.
The architecture of EMET and then I'll be taking a deep dive in the PKI feature of EMET
which was our first non‑memory corruption mitigation and then I'll be giving a demo
that hopefully works live. Okay. So first of all, what is EMET? EMET is a tool that
mitigates different exploitation techniques. So it's been historically mostly for memory
corruptions and stopping exploits.
It's not signature‑based. Rather it's behavior‑based. So, for example, you don't need signatures
for it or anything like that because it just looks for behaviors, common shell code behaviors,
for example. So it can stop things that people don't know about also or even Microsoft doesn't
know about. So, for example, zero days. We've actually used it to ‑‑ recommended it
to mitigate some advisories in the past. And because it's dynamically loaded at run time,
it's like a DLL that gets loaded into your process's address space. So it doesn't require
like recompiling or redeploying an application. And so if you have like a million computers
or whatever, you don't have to go and do that for all of them.
And it works on all supported platforms so far. So right now it's ‑‑ XP is still
supported. So as far back as XP. And it's a way of giving back to the security community.
And it's a free tool. So what applications does it work on? Like, these are some of them.
So, as you can see, like IE, Skype, Office, Chrome. It's basically Microsoft and third
party applications. So some changes between Emmet 3.0 and 4.0.
First of all, we added the certificate trust PKI mitigation. So a lot of talks this year
at DEF CON have been about man in the middle and like abusing PKI and stuff like that.
I'm not saying that PKI is a bad thing. I'm just saying that it's not a bad thing. But
PKI itself is bad or something. But I'm saying that sometimes it can be weakly implemented
or badly implemented, like if you use short keys and stuff for your routes.
So that was a mitigation we added for that. We added a mitigation for ROP exploits and
some hardening for those ROP mitigations and a new user interface so you can have skins
and cool stuff like that. Okay. So I'm going to first go into the memory
corruption mitigation. So I'm going to go into the memory corruption
mitigations that we've had. So we have the basically forcing DEP on, which is dead execution
prevention. And it's basically by calling set process DEP policy on the process that
we're trying to protect with the DEP protection. So this is basically so that you're not executing
code on pages that are not supposed to be executable, like on the heap or something
like that, that are supposed to be read and write. We have the heap spray mitigation which
reserves not commits virtual addresses that are commonly used by heap sprays. So, yeah,
so it reserves it using those APIs. We have the mandatory ASLR, which does something
where it reserves the preferred module loading base address so that the module cannot end
up loading there. It reserves it so that it's not able to load there, so it has to
load somewhere else, which is effectively ASLR, but obviously newer techniques of ASLR
on newer versions of Windows is safer and has higher entropy and stuff. We have the null page mitigation, where we have a lot of
bugs. We reserve the page zero, page address zero, so that you can't abuse null pointer
dereferences or null pointer bugs. The EAF mitigation, which is export address
table filtering. So that's basically the ‑‑ if shellcode, for example, is trying to read
the export address table, and it ‑‑ we set a hardware read break point on the export
address table to make sure that EIP, which is an x86 instruction pointer, EIP doesn't
have some random place, like in the heap, for example, because that's kind of creepy.
And then we also do bottom‑up randomization, where we randomize different data structures
in the process's address space. So as I mentioned earlier, these are all memory corruption mitigations.
And some more memory corruption mitigations are the C-HOP mitigation, which is structured
exception handler overwrite protection. This is basically where we traverse the exception
registration structures.
The chain of them looking for one whose previous pointer is negative one, because that's what
we expect to see. And if we don't see that, then we know that something has been corrupted,
and that's bad. And finally, our ROP mitigation, which is new in EMET 4.0. This ‑‑ we have
some hardening for this. For example, deep hooks, where we protect things like virtual
protect and virtual protect EX, so like an API and an API that it would call, so you
can't bypass it.
We have anti‑detours, which is basically preventing an attacker from jumping over
the detoured part of a function, so basically jumping over our hook, kind of. And banned
functions where we disallow ‑‑ specifically in this release, it's disallowing calling
NTDL's LDR hot patch routine, and that's thanks to Yang Yu of NSFocus from CanSec West
this year.
Our ROP mitigation ‑‑ I'm going to try to explain ROP in one slide, so we'll see
if it works. So it stands for return‑oriented programming, and it's basically the shiny
technique for bypassing depth. So basically what happens is the attacker injects an attacker‑controlled
call stack, and as you all know, a call stack has return pointers to where the execution
is supposed to return after you get out of a function. So what the attacker does is,
they return ‑‑ they set these return pointers to a few ‑‑ to always point
to loaded modules that are valid to be executed and a few instructions before a ret instruction,
so you can basically chain these together, and then you can try to ‑‑ what the
hell? Okay. So you can basically try to achieve the attacker's intention without actually
injecting code. They're just reusing code that's already valid to be executed. So things
like virtual protect, for example, are kind of interesting. What we've done is we've done
commonly ROP to to change memory protection on pages. That's used by a lot of exploits.
Stack pivot, for example, is a pivotal technique inside the ROP exploits to basically switch
the ESP, which is the stack pointer on x86, from where it's currently pointing to, which
is on a regular stack, to the attacker controlled call stack.
And I have more information about this in the presentation I did at NullCon about ROP.
That was in greater detail. This is just one slide, like I said. Hopefully you all got
what I'm talking about. Okay. So some of the ROP mitigations, these
are new in 4.0 from 3.0, include the load library mitigation, which is basically to
make sure you're not loading DLLs from network shares. That's kind of creepy. The memory
protection.
Where we basically make sure you're not making stack pages executable because, as you guys
know, stack pages are supposed to be data, so read and write, not execute. The caller
mitigation where we basically make sure that the return address where this current frame's
return address points to a location that's preceded by a call address, which calls this
function. So that's basically so that you're not returning to this function. The SIM exec
flow.
There we make sure that we don't ret to ROP gadgets after this function returns. And the
stack pivot, which is basically where we check the ESP X86 register to make sure that it's
between the stack pivot and the stack base that's identified by the tab for a process.
And my coworker alias did a good presentation about the ROP mitigation in his Recon presentation
from this year.
Okay.
Okay.
Okay.
Okay. So this is the architecture of Emmet. So basically we have the protected processes
like you can see on the bottom, the IE process and Acrobat and whatever else you want to
protect and you see Emmet.dll loaded into there. Emmet.dll implements the memory corruption
mitigations and as you can see on IE, you see the Emmet CE on the bottom also. That's
where we have the PKI mitigation ‑‑ a part of the PKI mitigation. I'll go into more
detail about that later. And basically all these DLLs use interprocess communication
to communicate with the Emmet agent which you would see running on your machine if you're
running Emmet. And that's basically the one that ‑‑ Emmet agent is the one that implements
the tray icon and the logging and the PKI logic. The Emmet CE.dll is basically loaded
into the ‑‑ into browsers or programs that use CAPI.
What's this called? Shot the noob. What's he going to do? Louder. There we go. Thank
you. We need someone from the audience. First time DEF CON attendee.
No, no, no. There we go. Come on up. I'm usually going for the first hand I see
up which is a good try, though. Good try. I have a question. Do you guys walk around
to five tracks every hour taking shots? That's a good question. The first speaker
is actually asked the question. So the speaker goons, are we doing shots with everyone? Yes.
That's exactly what we're doing. That's epic, man.
That's epic.
You got one? All right. To InfoSec.
All right. All right. Thank you. Good luck for the rest of the day.
Paul's having a rough morning. You can be up here with me. This is cool.
Okay. So let's try to pick up right where I left off. Yeah. So basically anything that
uses CAPI is protected, including other browsers, so like Chrome or whatever could be protected
by this, this PKI mitigation. Okay. So now I'm going to be talking the rest of the time
about PKI and the new mitigation. So PKI stands for public key infrastructure, which is, as
Wikipedia puts it, basically about dealing with digital certificates. Excuse me.
Did he just say at DEF CON I'm going to talk about PKI, which stands for public key infrastructure?
Evidently we're in the advanced track. Continue.
I'm trying to make sure everybody gets my talk. So this is basically used to ensure confidentiality, integrity, and security.
integrity and attribution online and it's like the basis of like HTTPS and dealing with
your bank website or whatever else or other secure websites that you want to keep secure.
So here's an example. This is what PKI looks like. So you can see at the root you have
the root certificate, obviously. And it basically ‑‑ so every parent signs the certificates
for every certificate underneath it. So, for example, in this case, the root certificate
would sign the intermediate certificates and the intermediate certificates would sign
in turn the end certificates. So the end certificate would be like whichever site you're
trying to log into over HTTPS. And it's basically a chain of trust rooted by the root.
So there have been some recent TLS and SSL incidents that you all might have seen in
the news and stuff. So starting back as far as 2008 when Soderov and Stevens proved that
MD5 was the best.
And then in 2011 we saw three different attacks on CAs. So basically fraudulent certificates
being issued. And then in January of this year we saw Turtrust get compromised. So in
a nutshell, PKI is under attack. I heard a yay from the audience. So PKI certificate
pinning is enforcing certain assumptions or expectations about certificates from the
Internet. That's a broad definition. And there's already been some pretty good work
in this space as well. Moxie, and they made TAG and convergence and a few others. But
as you can see, all of these require changes to existing protocols. So, for example, in
the TAG case you
convergence has a new protocol. Dane TLS has DNS changes and HSTS and what they implemented
in Chrome had a new ‑‑ had to change HTTP. So history has told the industry again
and again that requiring changes to protocols or new protocols takes forever to actually
be adopted by everybody. Like look at IPv4 and IPv6, for example. Not everybody is using
it all the time. So our design goals, we had three main design
goals. One is to give control to users. So like you can ‑‑ you can pick the exact
certificate you want to pin to or not pin to. You can pick domain names and other heuristics
that I'll go into later. Another thing we wanted to do was not require changes to preexisting
or new protocols because, as I mentioned, that takes forever to get adopted. And finally
we wanted to keep Emmet as a stand‑alone ‑‑ a standalone protocol.
It wouldn't depend on any other services on the Internet or anything. It's its own
self‑contained tool. So this required us to have ‑‑ to make design decisions and
tradeoffs that a lot of other implementations couldn't make for PKI for pinning because
we had to conform with what was already out there, and we had to still try to protect
stuff. So our approach was to not require any protocol changes. And we pinned to root.
root certificates, not intermediate certificates. So in that tree that I showed you earlier,
there could be some certificates in the middle, like the intermediate certificates. We don't
check those. And we also are pinning to only certificates in the Windows trusted root certificate
authorities store. That's like if you go to MMC, you'll see that.
And we also had to identify certificates. This was a bigger discussion in our team to
figure out how to do this. We were trying to figure out whether to pin to issuer and
serial number tuples or to subject key identifier. I'm going to go into more details about this
because this was a big deal, a big decision for us.
So as the RFC for X509, which is RFC 5280, says, the issuer name and serial number identify
a unique certificate. It's pretty blatant and obvious.
But that's the way it works. So it's a very simple way of doing it. It's pretty simple.
That's like really rigid because if you're trying ‑‑ so it is a valid case that
two root certificates could have the same public private key pair.
So although, yeah, you would be identifying a unique certificate, you would still have
false positives because you are identifying a certificate, not a key.
So we decided to also add an option to pin to a public key.
So in this case, this would be the SPKI, the subject key identifier of the root certificate.
And this is thanks to feedback from the community.
Thank you for your feedback.
And this is also from other people giving us feedback like Google and stuff.
So shout out to everybody that gave us feedback.
So this is what our architecture looks like for the PKI subsystem.
Basically we have a bunch of pinned sites.
So in this example, I'm taking the Skype example.
So we have a bunch of pinned sites at the bottom.
So, for example, login.Skype.com and secure.Skype.com.
And they're obviously both Skype services.
So they would share the same pin rule, which would be the MS Skype CA.
And those services are expected ‑‑ the expectations that we're forcing via the definition
of pinning are pinned to things that we expect to see like Baltimore, Cybertrust, VeriSign,
GlobalSign and GTE Cybertrust.
So in general.
So basically different services under the same organization or whatever share certificates
that they pin to.
So we implemented a crypto API CAPI extension.
This is what I said was in the MHCE or the MHCE64.dll.
And this basically communicates with the EMET agent.
And so we're passing ‑‑ so we're inside the process that uses CAPI and we're passing
the full certificate chain.
So the end certificate, all the intermediate certificates and the root certificate to
the EMET agent that I mentioned earlier.
And then the EMET agent makes a decision about whether or not the certificate is okay
or not.
And we ‑‑ as you can see on the bottom, we have the little crypto ‑‑ the crypt
register OID function.
That's a code snippet, kind of.
And you can see that we specifically target SSL over there.
So this is specifically for SSL checks.
Okay.
All right.
So we have ‑‑ here are some checks that we do on the certificates.
So we basically check the end certificate and different properties of it, like the subject
name, the DNS name or other things in there.
And we basically make sure that it matches a pinned site that I mentioned earlier that's
configured for EMET.
And basically a root certificate is what I showed you earlier as the root of the tree.
And the end certificate is the certificate that the EMET agent is using.
And then we check if the pin rule is expired or not because that expires.
And either depending on the configuration of that decision that I mentioned earlier
that we had to make about pinning to individual certificates or pinning to public keys of
certificates, in all cases root certificates, we either check if the public key is a match
or the serial number and the subject name.
Okay.
And so here's some more ‑‑ here's some what we call exceptions where we are doing
heuristics on the certificates.
So we check the public modulus bit length, which is the size of the length, which is
basically a measure ‑‑ it's a measure of the key strength.
So if you have, like, a 512‑bit key, that could be considered small.
And if you have a bigger key, like ‑‑ like a bigger key than that, that could be
considered stronger.
So it's, like I said, a measure of the strength of the key.
Okay.
So we have, like, a minimum bound on it so that the user can also check that.
They can also check the digest algorithm.
So if it's, like, MD5, which was proven harmful in the past, they can disallow that or they
can disallow routes from certain countries if they don't ‑‑ like, for example, if
they don't think VeriSign should be in a different country than the U.S. or something, they can
check that and mark that as weird.
So in general here, we're basically trying to give a lot of control to the users so they
can decide what they want to and don't want to do.
That was one of the design goals.
So here are some of the default protected domains that ship with Emmet.
So this is in the certrust.xml.
And these are the third ‑‑ both third party and Microsoft domains and sites.
So these are basically, like, you can see, like, Twitter, Facebook, Yahoo.
Those are basically other companies that wanted to cooperate and be in this with us.
So shout out to them.
And so this is basically various domains that we're pinning to.
And this is all ‑‑ this can be configured by the wizard in Emmet.
So I believe it's just best to be up front and straight up about what the limitations
are and not try to hide it.
So some of the limitations are that we mitigate specifically for SSL and TLS, not other crypto
protocols.
And our pinning to just ‑‑ we're just checking the end and the root certificates,
like I mentioned earlier.
We're not checking the intermediate certificates.
So that's a possible limitation.
The pin configuration is statically shipped with Emmet.
So we don't ‑‑ it's not like in Windows update or something where we're, like, pushing
down new configuration or something like that.
It's basically whatever comes with it is what we have for that release.
So they could be outdated if tomorrow, like, some company decides to change a ‑‑ change
the root that they chain their certificates to.
And in general, like, Emmet's mitigations are not 100% bulletproof.
They try to raise the bar for the attackers, but there's a way to get around it.
So yeah.
So okay.
Demo time.
So do you all want to see a live demo or a prerecorded demo?
Live?
Live?
Raise your hand if you want to see live.
Okay.
Do it live.
Do it live.
All right.
We'll do it live.
Hopefully this works.
Given the DEF CON network, I don't know.
Okay.
I have a VM here.
Please work.
Unidentified.
Okay.
Hopefully.
No.
Apparently not.
Okay.
All right.
All right.
So apparently the DEF CON network is not serving us today.
So okay.
I'll just show you guys a video.
Yeah, I know.
Okay.
Who's jostling the network?
Okay.
So okay.
I can't see this, but I think you can.
Let me guys ‑‑ let me ‑‑ okay.
Okay.
You see lovely flowers?
Yeah.
That's to make your day brighter.
Thanks, Microsoft.
For Emmet or for the picture?
Oh, okay.
Okay.
I have no idea what's happening because I can't see the screen.
Hold on.
It would probably be a better idea if I could see the screen.
Let's see if I duplicate my screen.
No, nothing?
I heard a bunch of random yelling.
I didn't really hear anything.
Resolution.
Resolution.
Awesome.
Okay.
Okay.
Let's see.
I really wanted to do it live.
But whatever.
So okay.
As you can see here, this is the configuration for Emmet.
So can you all see the text?
Oh, man.
Okay.
Let me increase the resolution then.
HD.
Smaller.
Okay.
Cool.
Can you all see that?
Yeah.
Please.
That works?
Is that good?
I hear a bunch of groaning.
Okay.
Okay.
So I'm just going to explain what's happening.
I'm going to try to change it once more to make it even smaller.
1024768.
Old school.
I don't have the Zoom tool.
Okay.
You all can see it.
Okay.
Okay.
Can you see that?
Okay.
Whatever.
So I'll just explain what's happening then.
So basically you see the configuration and that was that Emmet configuration.
And now login.live.com is working and the certificate is good and stuff like that.
So I'm going to fast forward.
So the point here is that we see that the certificate changed to the VeriSign route which
is in our trusted store.
And that's the MMC that I was mentioning earlier.
Okay.
So now on this VM I was running a web server.
I was serving up an HTTPS page.
But that HTTPS page was encrypted with certificates key who chained to another route in my root
store.
But it wasn't the same VeriSign route.
So this could represent like if you're getting manned in the middle or something by a certificate
that chains to another route in your root store.
Like for example this year the Turk trust, if they got compromised and they're in your
root store and you would chain to them and then you would trust them because the ‑‑
the certificate chains to them and they're in your root store.
So I manually added a certificate to my root store and I'm changing the host's file here
to point login.live.com to local host, the web server.
So as you can see here, you see that this is obviously not login.live.com.
This is my IS, my page.
And on the bar on top you don't see it red or anything and you see a little padlock there
which would fool you into thinking that it's good.
That's because I have a certificate with login.live.com.
That's good.
It's a domain name listed there that chains to a route in my root store.
But it's obviously not good and it's not login.live.com.
So this is just to prove to you guys I'm not lying.
Here.
Okay.
So you see the MMC that's open ‑‑ see or might not be able to see, I don't know.
The MMC that's open, that is a certificate that I generated and there was a route that
I generated.
So it was not correct.
Okay.
So that's the cool part.
So now when we enable the login.live.com rule, as you can see there, login.live.com works
as expected.
But when I change the host's file to point to my local web server and then I run IE ‑‑ there.
You see that little icon there?
Okay.
So Emmet detected that there was an SSL ‑‑ there was a problem with the SSL certificate.
So it said that ‑‑ it's basically a warning.
So although IE doesn't show that the bar is red or anything, it ‑‑ that certificate ‑‑
sorry, that icon pops up saying that there's something weird going on here.
Okay.
So now to switch back.
Okay.
Okay.
So that was the demo and I guess we had to do it recorded.
Sorry, guys.
So yeah, so that's basically it.
Some references.
So you can download Emmet 4.0 here if you need it or if you want it.
And this is a lot of good work, references to a lot of good work that I used when I was
making this presentation and when we were making the design decisions for Emmet.
So any questions or anything?
Also, I want to say that this was a team effort.
So thanks to the whole team, the whole Emmet team for making this possible.
Do you want to ask a question?
We have over here a mic.
So the mic wasn't on, but the question, I think I heard it.
Okay.
All right.
So the question was, can you pin a site to multiple root certificates?
Yeah.
So that's what we're doing.
So in that example that I gave about Skype, you see, like, the login.Skype.com, I think
it was.
So that had multiple ‑‑ it had Baltimore cyber trust root and GTE.
Is there a way to tie that into GPOs or otherwise push down settings to users in a corporate
environment that does, like, SSL decryption or would want to do that to multiple users
or does that have to be done on an individual basis on individual machines to change those
settings?
Emmet supports GPOs.
So that's why I was saying if you have, like, a million computers or whatever, you can set
it through GPO to propagate down to everybody so that you don't have to go into every computer.
Hi.
I have two questions.
The first one is there was recent research that showed that most SSL applications that
are not browser‑based are actually incorrectly implementing SSL.
So and Emmet is, as far as I understand, protects a specific application.
Okay.
Emmet what?
Emmet protects a specific application that you predefined.
Is there a way to make Emmet work on all applications on the ‑‑
No.
So ‑‑ well, are you talking ‑‑ okay, so you're talking specifically about SSL?
Yeah, because this is a problem that would be relevant not just to browsers but to other
SSL applications.
Yeah.
So in that case, yeah, so I saw, like, Outlook, when I was using Outlook, it had the EmmetCE.dll
loaded.
It's looking for a cappy.
So in that case, yes.
I meant no for if you have, like, memory corruption, like, rot mitigation or whatever.
That would be, like, for Acrobat or for IE or something.
But yeah, if you want to do the crypto API, if you're using crypto API in your application,
this would protect you.
It loads it into anything ‑‑ it registers the DLL.
So it would be loaded to anything that uses crypto API.
So that's why it works for, like, other browsers also.
So for, like, Chrome or IE or Outlook, which is not a browser, obviously.
Okay.
And thank you.
And another question is why don't you integrate this notification with the regular announcements
or notifications about fraudulent or incorrect certificates?
So why is it a separate notification?
Separate than what?
Then if I had a fraudulent or incorrect certificate coming to my browser, I would have to do a
different thing.
I would be notified in another way, right?
You mean with a red bar, for example?
Right.
Yeah.
So changing ‑‑ so IE is, like, a lot of code and it's huge.
And changing, like, the behavior of IE would be, like, really difficult.
And so, like I said, we wanted to be standalone.
So we just wanted to display this notification just like we display all the other notifications.
Like, the one that people are used to, like, to see the Emmet in the little tray icon.
We didn't want to be changing the behavior because you have to go through, like, a bunch
of other stuff to change the behavior.
Do you have support for iOS and Android?
No.
So first, thank you for having the guts to come before this august group of users to
try your hand at explaining this.
But the question is, is this intended to replace other certificate validation tools?
Does this provide ‑‑ would it be fair to say this provides a baseline of certificate
validation through Windows?
Before, previously, it was an external application suite or tool set you had to use to check to
see if certs are valid for OCSP and other things.
In other words, is this OCSP‑based?
Is it krill‑based?
No, it's not.
So basically when you're asking about replacing other tools or something, when you're asking
about replacing other tools and stuff like that, each tool has its own strengths and
weaknesses.
So, for example, our strength, I think, was that we didn't try to change any protocols.
So you can use other stuff also that might not have the same weaknesses as Emet.
But then the strengths also change.
So what I'm trying to say is that it's not a replacement.
It seems like there's many different solutions out there right now.
So this is just another one that I think that has some pretty good strengths with not too
bad weaknesses.
Do you have plans for providing ‑‑
Do you think Emet protection is an API for third parties?
Not that I know of yet.
Why?
Well, we just released it a few months ago.
No, Emet has been there for two years.
No, the PKI mitigation.
I understand.
I'm not ‑‑ I'm talking about in general is an Emet.
Oh, okay.
So you're talking about the memory corruption mitigations, for example?
Yes.
Yes.
So I talked about that to my coworker.
But, I mean, we have ‑‑
Yeah.
We're thinking about that still.
But we have to still have time to, like, outweigh the benefits and the costs of it.
So, I mean, for example, would it, like, break everybody that's using it or, you know,
would it break some really popularly widely used applications?
So because, like, when you ‑‑ if you have a lot of users, for example, you have
to be very mindful about not breaking them with ‑‑ because sometimes they rely on
your software through undocumented methods and that are not according to the software
contract.
So you are using undocumented constructs?
No, we're not.
But I'm saying, like, we're just doing our own, like, our ‑‑ we're basically just,
like, doing all of our stuff is looking at memory corruptions inside of our own DLL.
So we're not using any undocumented stuff that I'm aware of.
Like, basically, we're ‑‑ so what I'm trying to say is when you change, like, the
operating system, you've got to be very mindful about who you're going to affect.
I mean, this is no different than asking third‑party vendors to drive ‑‑ to write
software device drivers.
To write what device drivers?
Device drivers.
So anyone who writes device drivers altering the kernel, right?
So why don't you expose these APIs for third parties?
So what I'm saying is this is not a part of the operating system right now.
So, like, you ‑‑ there's no ‑‑ I mean, we can't, like, expose Windows APIs that
do this because it's not a part of Windows.
This is a separate standalone tool, like I was saying.
So ‑‑ There are many libraries you are exposing.
Right.
So, like, we have these DLLs.
It's loaded into processes and stuff.
But we haven't made the decision yet or even talked about, I guess, like, putting it in,
like, so that everybody can use it.
So, yeah, I can take that as a feedback.
So I'll bring that up.
Thank you.
You said pinning rules expire.
Could an attacker with local access, like, modify the date or something to avoid Emmet
and fall back to standard PKI?
So that ‑‑ all that stuff is stored in the registry.
So they would have to have registry access to access the configuration.
Oh, and the question ‑‑ sorry for those people that can't hear.
So he was saying that can an attacker modify the configuration?
And I was saying, no, you can't, because that ‑‑ it's ‑‑ the configuration
is stored in a privileged location.
Anything else?
Questions?
Okay.
Thank you.