RPC Filter? I Hardly Know Her! - Evan Perotti

the next speaker is Evan pate if you are a Defender this is awesome topic look at that uh the topic is RPC filters I hardly know her exclamation point let's welcome

Evans hey everyone hope you can hear me all right uh hi like you said I'm Evan uh my talk is RPC filter I hardly know her um just a few notes before I get into things uh if you're interested in the slides they'll be available on this GitHub link afterwards so you don't have to worry about taking pictures you can just grab the slides right off the internet uh there's a QR code and at the end of the talk I'll have a bigger version that's easier to see uh I also hope you appreciate my slides I put a lot of work into making them look like Windows related things um so kind of the impetus for

this talk there's this great series of tweets that I saw uh by Craig Kirby and Benjamin delpy about blocking petite patam which was a very popular Network coercion attack uh and the the Tweet chain basically mentions that you can use RPC filters to block this network coercion attack and so that's that's really the the motivating factor of this talk is understanding what these RPC filter are and how they can be used to block Network related RPC attacks before we get into things uh just a quick intro uh my name is Evan I work here in Philadelphia at a small consultancy called security risk advisors you may recognize the name uh we have a public free tool you can use

for your purple teams called Vector uh so check that out if you do purple teams my background is in uh offensive operations so I did a lot of pen testing and then a lot of purple teams uh nowadays I'm mainly focused on research and development velopment uh if you're interested in in contacting me uh you can obviously find me here at the talk later or at the con later uh also have my Twitter here if you're interested as well uh you can reach out to me with any questions or concerns about the talk or any other topic you might be interested in I'm around so the the general structure of the talk that we're going to go through

today is I'll give some background on General Windows RPC related information and that'll be the derrier part so bear with me uh then we'll talk about RPC filters what they are how you make them and Implement them we'll talk about how these can be used for defensive applications and security we'll talk about some implementation specific details so if you're looking to implement this in your environment some considerations that you should uh think of as well as some limitations of the technology and then some closing thoughts uh just quick thumbs up if you guys can hear me all right I'm coming through all right thanks all right uh so some backgrounds you've likely heard the term RPC before uh if

you're not aware it stands for remote procedure call uh remote NE necessarily mean between two systems uh can be within both a local system within Windows as well as Between Two Hosts over the network uh it's implemented as a client server mechanism and and it's typically used in Windows for different types of interprocess communication so if you're in writing in one program and you need to get information from another you can use our PC to pass information between those two different programs uh it's used extremely commonly in a lot of different uh legitimate Windows operations uh it can be used remotely like I said with with another Network host so over the network and it's

typically done over SMB name pipes or TCP as the most common ones are there are other there are other transport uh that RPC can use within windows for example uh hyperv some important Concepts within RPC if you're interested looking in this into this are interfaces and procedures so procedures are the individual method calls that your RPC client will make to run whatever function it needs to and then there are interfaces which you can think of as kind of overarching groups that are collections of these different procedures so to give a more concrete example we'll consider the service control manager within Windows which I'm going to use a lot uh for all the different examples within this talk

because the service control manager is a really nice simple um example that kind of exemplifies a lot of the topics we're going to discuss so an example of a procedure within the service control manner would you would be creating a window Service uh so something like an updator or something along those lines uh and the way you would create this service through RPC is by calling this RPC procedure R create service W which has every every RPC procedure has its own procedure number or an opum uh and that's how you identify it from your client and so if you take in aggregate all of the different uh service control manager operations like creating a service modifying a service starting and

stopping Services these in aggregate make up the interface that is the service control manager so to dig down a little bit uh this is what an RPC uh client server looks like on the left you have the definition of the RPC service so it's defined by a a unique identifier a uuid uh you define the interface as well as all of the different procedures that are involved with it in this case this test interface has a Fu and bar uh procedure and then you take this interface definition convert it to your programming language of choice and then you package it up in whatever application you're using and so then when you go to use this as an RPC client

on the right here uh you basically just call the RPC procedure and you pass it the input parameters and then the server handles it from there and so if we take a a deeper look into this right side here this is essentially the lifetime of your RPC connection where you have your your client make the RPC procedure call with all of its methods and then it essentially just says to Windows this is an RPC call and then the RPC runtime that's built into Windows handles pretty much everything else it Marshalls Andals all the data when passing between the client and server it handles things like authentication and authorization and access checks uh it handles mapping your

RPC server so it can listen without you have to worry about it explicitly uh and then once your client passes that data onto the RPC server the RPC server implements the business logic that's related to that RPC procedure uh so the windows RPC runtime handles a lot of the backend and abstracts it away from you so that from a client server perspective it's very simplified if you look at a lot of the different RPC interfaces within windows they're typically well documented in some capacity so you can go out to Microsoft's techet to view the documentation for these uh the descriptions of the RPC interfaces and the procedures that they Implement as well as the procedure number numbers uh

so for an example this is the service control manager documentation here and you can see the different procedures that the service control manager

implements however some RPC interfaces aren't necessarily going to be documented um so there's this great tool called RPC investigator um that's an open source tool provided by trail of bits and it can be used to uh investigate different RPC interfaces as well as the procedures they Implement and the details of those interfaces and procedures and so you can go out to GitHub and download this um so for an example using our service control manager example from previously we'll take the services.exe binary which comes in your Windows installation and load it into RPC investigator and we can see the different RPC interfaces that it implements here uh also keep in mind this 367 uu ID this is the service

control manager interface ID it'll come up a lot during the slides but then we can drill down into the specific RPC interface and look at the different RPC procedures that are implemented by the service control manager so here we see again our RP create service W which is what used uh over RPC to create a Windows service and you can see all the different um parameters that are taken by this RPC procedure as well as the procedure number and for creating a service it's 12 so again keep that in mind because it'll come up um but as you can imagine RPC because it is used so widely Within Windows it can it in some way relates or underpins

a lot of different attacks uh that you see commonly in different types of environments so some notable examples are things like DC sync and PS exec and there's this grape repository linked here U which you can check out later which Maps a lot of Windows RPC uh attacks to miter attack as well as provides information about the RPC interfaces and RPC filtering so definitely recommend checking that out but I've summarized it here uh in this table uh which is a big table of text but I'll go through some highlights uh so if you're familiar with some of these attacks they should stand out things like blood hound uh which is used for Windows domain uh enumeration it'll do

things like session collection about who's logged into different systems as well as get logged in users and it does this over RPC using the server service and workstation service RPC interfaces uh there are some other notable examples like a lot of the windows coercion attacks like um the print bug and like I mentioned petite patam they also o uh use RPC interfaces PTI baham uses the EFS RPC interface uh the print bug uses the print RPC interface there are some other notable examples like DC sync which you can use once you have privileged rights within the domain to extract users passwords and other information about the ad object by using the directly directory service replication RPC interface which is used

by domain controllers to replicate information uh so suffice to say um RPC is used by a lot of attacks whether you realize it or not uh to dig down into an example we'll look at PS exec which again uses the service control manager like I said it's a great example so PS exec if you aren't aware is a tool that's part of the system internal Suite it's used for remote code execution in Windows environments so you can use it to Target a Windows system and run a command on that of some kind uh it's typically used by Windows administrators as an alternative to something like SSH uh if you're looking at their Linux administrator counterparts and this is

because for a long while Windows administrators didn't have a great mechanism for remote code execution like this um nowadays they have things like winrm which which take the place of SSH and PS exec for Windows administrators but PS exec for a while has been used legitimately by administrators to run commands and configure Windows host but the way PS exec works is that uh on your client system the system you're running PS exec from the PS exec binary creates this PS exec service binary which it copies to the remote Target over SMB to the admin share and then it uses the service control manager RPC interface to create a window service that targets that PS exact service binary and then it

starts that uh new service also using the service control manager RPC interface to start the service uh gets the output of the command and then pipes it back to your local client so for example if you run uh a command like who am I with PS exzac against the remote Target uh the PS exec service will get created on the remote Target the humi command would run under the PS exec service binary and then on your local client you get the output of who am I another way we can look at RPC this is a great resource by akami as part of their RPC research but essentially you can take the windows etw to logs for RPC

to get logs of RPC connections that have happened in the environment uh and then you can map those in a graph database similar to how Blood Hound would map its relations so that you can visualize different uh relationships that are happening over RPC uh so to take our service control manager example I uh using a create service W which is like I mentioned procedure number 12 you can see here this 367 RPC interface ID that's the service control manager and you filter on that plus the operation number of 12 which is creating a remote service and we get the result here of the relationship of an unknown host creating a service against This Server 22 host and so we can visualize and map

these uh Network attacks that are happening over RPC and so in this case this would be something like a PS exx style lateral movement where you're moving from one host to another by using the service control

manager uh so we're going to talk about RPC filters next but before we do that there's two windows components we should understand that tie to RPC filters the first is the Windows filtering platform and the second is the base filtering engine so the Windows filtering platform is a mechanism within windows that abstracts away a lot of the capabilities that are used to implement your own type of uh networking base controls so for example if you're implementing something like a firewall application on your own rather than having to write all of the backend kernel logic to handle networking connections uh and blocking them windows provides this filtering mechanism for you to build on top of so

if you look at something like the native Windows Firewall it uses the Windows filtering platform to implement a lot of its control logic uh and so that's how you do it uh it's built into the kernel and then the base filtering engine is a component of the Windows filtering platform that allows you to uh manage and store your filtering rules for your different applications so if we take a look here at this diagram the bottom left is essentially where you start which is something like the Windows Firewall management guey um which is you as a user would interact with and that would talk with the the Windows Firewall service and then when you add your

different filtering rules those will go through the base filtering engine and then from there the kernel takes over and it can manage the network blocks for You Through the Windows filtering platform uh another diagram here which it's very big but really the only important thing you need to worry about is the right so this is the Windows filtering platform architecture and essentially what's important to note is that RPC connections are treated specifically so there's specific handling for RPC within the filtering platform that allows you to get more expressive controls as part of your network filtering so you can Beyond just the the you know Source destination IP Imports you can do things like trigger off characteristics of the RPC

connection itself and so that's where we start with our RPC filters and so RPC filters are a mechanism for you to get firewall like um blocking capabilities for RPC connections there are a lot of different characteristics you can trigger on as part of your filters uh but the thing to note with this is that when you're blocking RPC connections with RPC filters it's all or nothing so you either block the entire RPC interface or you don't block it at all uh and this is just a limitation of the platform so for example if you want to block Services uh service Creations you would have to do it by blocking the entire service control manager with an RPC filter

rather than specifically the service create procedure that's part of the service control manager interface uh so that's an important thing to keep in mind and we'll touch on it later here um but for now we'll talk about the kind of digging into the RPC filters themselves and if you're interested in this I definitely recommend this link here by James Forshaw he's a very established Windows security researcher but he provides a lot of background on RPC filters and how they're implemented within windows but the things you can filter on in an RPC filter are a lot there's a lot of useful things that are filterable and so I've I've listed some notable ones here uh things like the interface ID so

this would be those unique identifiers that are tied to each RPC interface another thing to note is that RPC interfaces can be versions so you can have different versions of the same interface and you can base filters on specific versions this doesn't really come up much for a lot of the default ones that we're interested in but just something to keep in mind especially if you're dealing with um third party RPC interfaces that have been installed uh post Windows installation you can also filter on the networking protocol that's in use as part of the RPC connection so like I mentioned uh when going over when RPC is going over the network it typically happens over things like SM SMB name

pipes or TCP and you can filter on those specifically so for example you could block a connection that occurs over S&B name pipes but allow ones that happen over TCP you can also filter based on the authentication information that's passed um because this happens in Windows a lot of these RPC interfaces are require some form of authentication um before their authorization checks as well and so you can filter on the different um authentication types that were used as part of the connection so for example you can block connections that are using maybe uh a weaker authentication like ntlm and allow connections that are still using ceros another thing you can filter on is the users token so for example if you

want to filter on users that are members of a group you can do that by allowing me that by allowing connections from users that are part of group versus disallowing us users that aren't part of that group uh lastly you can filter on the name pipe itself however the reason I've stricken it out here is because some from from some empirical testing that I I've done myself it doesn't look like this is actually the case I I've built some filters that uh filter based on the pipe name but they don't seem to actually take effect so I'm not sure exactly what's going on here but it is documented at least that RPC filters work on name

pipes so to create an RPC filter the way you'll typically do it is through netsh which is the the built-in Windows networking command line utility it also provides an interactive console shell if you're using it you can alternatively create the RPC filters uh by doing creating them programmatically uh an aami as part of the RPC research has some example code on how to do that but for the most part we're going to be looking at how to do this with netsh uh and so effectively the way you do it is by defining your rule whether it's like a block or allow and then the conditions of the rule one or more conditions of how the connection should be filtered uh

and then you add it and so breaking this down a little bit more uh the first step which is creating the rule this is where you define the action of the rule whether it's a block or allow I also note audit here audit isn't an action but it's tied to the action and we'll get into that when we discuss auditing uh and then there's a layer which isn't particularly relevant for us we're mainly interested in this user mode layer but there's some other different layers depending on how the RPC connection occurs and and in which parts you want to uh block the connection on I I recommend that James for our article because he discusses in

depth a bit more the layers but again they're outside the scope of our talk uh and then after you defin the action you would Define the conditions and conditions in RPC filters are made up of three different components the first is the field which is the filterable field the ones I just discussed things like the the interface ID the authentication information or the the user token uh and then the match type which is the uh way that it's going to compare the the field for the condition this could be things like uh less than or equal to uh different types of comparison operators uh and then the data component which is just the value that's being compared against whatever

your condition is so for example if you're blocking the cons service control manager you write condition that would look at the interface ID and compare it to the unique identifier of the service control manager this 367 uh ID so looking at some example conditions of some common scenarios that will come up what if you're looking to write RPC filters the first is like I mentioned writing one for uh blocking based on specific RPC interfaces uh so this would be for the service control manager you provide the uh RPC interface ID which is that U ID you can find this like I mentioned with RPC investigator you can alternatively find it uh by looking at TechNet it's typically documented there

as well um and so that's this is way you do uh interface based blocks another thing you can do is basing it on the authentication so for example if you want to filter RPC connections based on the authentication for Kerberos you'd look at the documentation for RPC filtering uh for the translation of how this authentication type is represented which is as this 16 uh and then you put comparison of the off type and then lastly if you want to write an RPC filter that looks at a user's group what effectively you do is find the the group you'd find the Sid of the group and then represent it as an stdl string here and compare it to the

user's token and and so this this filter here is checking that the user is part of this specific domain group and so when you create it with netsh uh the RPC filter gets it provides an ID every RPC filter has its own unique identifier and it's stored in the registry along with some binary data uh and when the the filter is created it gets that ID alternatively when you create the filter you can set the ID yourself which is an important component we'll talk about we talk about deployments um but the filters are stored in the registry as a parameter of the base filtering engines Service uh so that's what this current control set is

it's stored in the under the persistent key uh it can this is because the the RPC filters typically persist through a reboot however you can have RPC filters that do not they're more ephemeral uh and you can those are stored in a different location but for the most part we're concerned about persistent RPC filters that will L for as long as we need them to uh the binary format that these RPC filters are stored in isn't documented by Microsoft but there is this great article here that goes into our Versa engineering of the structures used by the base filtering engine so if you're interested in looking at that structure in more depth uh you can read

this however I'll note later that this isn't really a hurdle for us because we can work around it pretty easily

so this is end to end essentially of what it looks like uh under the hood if you're creating these RPC filters you have your client that is creating filter the netsh it implements the the apis you provided by the Windows filtering platform and it uses that to interact with the RPC interface of the Bas filtering engine so so to make these RPC filters you use RPC to interact with the base filtering engine an important note about this is that the RPC server that's implemented by the base filtering engine that you use to call to create these RPC filters is local only so it can't be called remotely I'm going to do a walk through now of what it essentially looks like

start to finish of creating an RPC filter and how it presents so the first thing I did here is uh the target is this2 address but the first thing I wanted to do is check the firewall status of this system to see if the Windows Firewall is enabled in this case all the different firewall profiles are disabled and so the important note here is that you don't necessarily need to have the Windows Firewall enabled or on to make use of these RPC filters they can work without necessarily having to rely on the Windows Firewall I know that's a big concern for a lot of folks who turn it off by default or Implement some type of

other uh firewall solution uh next you use RP uh netsh to drop into the RPC filter subcomponent you provide the block type and then you provide the condition again we're just blocking the service control manager interface ID here on this2 target uh and then when you are on a separate system attempting to interact with this this system that has an RPC filter applied um say you're using sc.exe to query all of the installed services on the system it would be blocked and you get an access denied because the RPC filter has in this case blocked connections to the service control

manager um so RPC filters aren't all all that commonly discussed however there have been some past defensive applications of them um one I thought was interesting was that Microsoft themselves as part of their remediation guidance for ms08 which is a very uh prolific SMB vulnerability similar to the more recent ms710 um but they essentially state that if you're not able to apply the patch that they provide one of the workaround solutions you can do is to apply an RPC filter for the server service RPC interface and that effectively blocks the ms8 attack uh so thought that was interesting to note um some other previous works like I mentioned the msrpc to attack repo which Maps a lot of RPC based attacks to miter

attack as well as provides RPC filtering notes for them wildly useful resource that I definitely recommend as well as acemiz security research they've done a lot of recent work around RPC Security in general uh and then lastly the RPC firewall which is something I want to touch on now uh so the RPC firewall uh is an open source tool provided by zero networks and it implements RPC based network security filtering similar to RPC filters uh but it does it as an agent based uh solution but the nice thing about it is that it solves the All or Nothing problem of RPC filters so here's the comparison between them uh the important one is the the first one

which is that RPC firewall allows you to filter on specific RPC procedures for RPC interfaces um so this is wildly useful if you're looking to take a more granular and surgical approach to RPC filtering because you can filter on just the procedures that are used by the attack rather than the entire interface itself uh so to go back to our service control manager example with an RPC filter you'd have to block the entire service control manager interface but with RPC firewall you can block specifically the create service W procedure and so that way you block just the minimal amount of procedures required to perform the attack uh the downside is that you need to deploy their RPC agent but um it is

at least open source you can get it on their

GitHub all right so the real uh reason I wanted to give this talk was that I wanted I had the goal in mind that I want to prevent different types of network attacks and lateral movement attacks by using RPC filtering it filtering and deploying it into the into my environment um and so I figured if you're going to go this route there are likely going to be some common hurdles you'll run into uh and I wanted to address those and propose solutions for them and so that's what we're going to talk about now are the implementation specific details of applying these RPC filters and making the most out of them that you can and so the first hurtle is how do

you track these RPC filters right it's a blocking control so how do I get effective auditing of them uh and so the solution here is that you can use the auditing trick which is something that I haven't found documented anywhere to the best of my knowledge um I'm the only one who who's documented it at this point um but we're going to talk about auditing of RPC filtering so the issue with any type of blocking control not specifically RPC filtering but any type say it's anywhere from like an EDR uh blocking execution or a firewall is that how do you keep track of what's being blocked right you you always run the risk with blocking controls of blocking legitimate

business processes and in some way affecting production negatively uh and so if you're going to go the route of blocking these RPC connections which are used under the hood by a lot of legitimate Windows processes how do you actually make use of them can you even audit these RPC filters and these RPC connections effectively and so the first place I looked was was the windows event logs definitions and I came across this 5712 event uh which is documented as having been a log of when an RPC connection was attempted and so this sounds great this sounds like the type of things You' use to audit your RPC connection unfortunately if you read the tech knite

documentation for this Windows Event Microsoft themselves say that this event is never cut it doesn't right to the event log and so you think this is the end of the road right how do I get Windows events for RPC um however if we look first at the netsh documentation for RPC filters one thing it notes is it has a section on auditing RPC filters and it notes that when you enable auditing as part of the RPC filter it should write an event for the RPC filter and so theoretically filters can be audited and logged somewhere and if I'm a betting man I'm probably thinking it's going to be either the Windows Event log or it's being ritten

into some etw Channel somewhere um alongside the normal RPC etw events that get cut normally the next piece of documentation I looked at was the advanced audit settings for group policy and so one of the detailed tracking subsections for advanced audit is that it can audit RPC events and it notes that it should cut an event audit an event when the RPC connections are attempted so presumably if you have this Advanced audit setting enabled you'll get some type of log and again if I'm betting man because it's Advanced audit it's probably in the event long alongside all the other Advanced audit settings like 46 88s uh 4769 and so what happens when we merge the advanced audit settings for RPC

auditing and we enable auditing on our RPC filtering well what we get is this 5712 event which is supposedly never occurs uh and it has a lot of relevant information for our RPC connection it has the user that initiated the Connection in this case it's a domain user uh called Puffin uh it tells us the process that was related to this it says it's an RPC event 5712 and then it has all of the RPC related interface information that's relevant to us it has the interface ID it has the protocol that went over in this case TCP it has the authentication related information in this case I believe was ntlm and it also has the source information of where

the network connection occurred and so this is hugely useful for any type of tracking unfortun fortunately if you try to make an RPC filter that is a blocking filter and you set auditing to enable you'll get an error and this is because fundamentally RPC filters do not allow the audit to be enabled for any type of blocking filter when you set audit equals enable your action type must be permitted so realistically if you're going to audit RPC filters it seems like you can only audit permitted connections and not blocked connections but then I had the idea well what if I make my rule the way I want to make my rule it blocks the connection and then I duplicate the

rule I make an exact duplicate but I set the type to be permitted and I set auditing to be true because that's the only way you can do auditing and so I have a duplicate that essentially does the same thing what happens well what happens is that the connection is blocked by the RPC filter but then the event is still written to the event log so you get all of the benefits of the auditing and all of the benefits of The Blocking by just duplicating the rules and so this doesn't seem to be documented anywhere I think I'm the one who discovered it hopefully uh that'd be nice but uh hopefully you can make use

of this to get proper auditing of your RPC filters the order doesn't seem to matter it doesn't matter if you put the block first or the audit first um it seems to work the same way uh the second hurdle I wanted to consider was how do I deploy these RPC filters right from all the examples we've shown the way we're doing this is what we just have a local CMD open and we're using netsh to create these filters so how do I deploy this at scale in a corporate environment and so there are a few different ways you can approach it uh like I mentioned when you create the RPC filter it gets written to

the registry as part of the base filtering uh engines service parameters and so presumably you can just write these registry values directly using something like a group policy preference uh another way you can do it is by using netsh uh running netsh commands through some type of GP startup script uh or you can use one of those two options with some type of configuration management tool like InTune or fcm to run those commands uh through that interface uh and then lastly another way you could do it is if you have some type of golden image process for deploying your endpoint images you can bake the RPC filters into your golden image such that they're already there when the

system is deployed so for example if you have uh you know your Windows Server golden image that gets deployed for all your windows systems in your data center as part of your build process for your golden image you would apply your RPC filters and then when instances of that golden image are deployed into the data center RPC filters are already applied however there's some con things to consider with with these deployment methods the first is with netsh if you go this route um one handy feature of netsh is that you can effectively take all the commands that you would run in an interactive netsh console and drop them into a text file and then Target it

with netsh so I can put all my filter rules in a text file and then Target it with netsh and netsh will run through all those rules and apply them for you and so uh this gives you the ability to put all of your rules in a text file put them on a right restricted chair like your domain CIS fall or some something else that you might use for deployments and then as part of your uh go you just have netsh run against that share with the registry method assuming you want to write directly to the registry because you don't want to be running commands or maybe you don't have that kind of capability um the thing to

consider is that you need to restart the system after you write to the registry otherwise the base filtering engine won't see the rules that had been written directly to the registry it needs some other component to refresh it uh and so that just limits your your the usability of the registry method because you need the restart uh another thing I mentioned when you create the rules they're given a unique identifier for every rule you make however you can set the rule yourself uh during the creation process you can set the unique identifier of your rules and so this allows you to get better consistency of management of rules across your environment so for example if you define all your rules and

you set the idea for every rule when you go to interact with the rules on any individual host they'll all be consistently uh named by the rule ID across all the different systems so if you're looking at the rule on one system based on the ID it'll be the same on every other system because you can predefine the rule IDs ahead of time and it also allows you to better manage them when you're making updates to rules it'll be tied to that specific rule

ID uh so I'm going to do some walkthroughs of what these deployment look or methods look like in practice the first is how to do it with the registry method um so like I mentioned when you create the rules uh the limitation is that the rules get stored in the registry in some weird binary format however what we can do is just make the rules in a test system and then export them from our own registry with something like reg.exe and then apply them anywhere else because from my testing it seems that the rules are portable it doesn't matter the system that they're made on they work the same regardless of what system they're applied to and so here we have just a

test system it's stock domain joined it's just a local VM uh we create our RPC filter that blocks the service control manager you can see at the bottom the 367 uh interface ID uh and you can see it has a rule ID this third underline here of a34 then we can go into our domain controller to our group policy editor into the group policy preferences uh we can take the rule ID and that translates to the registry key value and we set the the value of this key to be the binary data that we exported from our local test system and then we'd apply this in a GP and restart the system after the GPO takes effect and now here we see

we're on a domain joint system uh and we have the same rule ID that a34 applied that applies the block against the service control manager interface ID and so you can see that the rules are portable uh regardless of being written in some weird binary format uh the next walk through is deploying the RPC filters via a GP mechanism like a GPO startup script uh so like I said you can put all of your rules effectively all the commands you would run via the netsh console in a text file that we have on the right here is the first rule deletes a rule of the ID 72f and then the bottom one adds a filter

rule for blocking the service control manager the 367 ID and it's given an ID here of dd0 and I've just dropped it on the CIS wall as well as a bat file that just tells netsh to run this RPC filter rule file and so when that once that's deployed via GPO and it takes effect on the system so here is our startup script uh targeting the bat file that will run netsh and apply the rules uh you can also use any other type of execution primitive that that's provided through GOP something like a schedule task you could create as well that would that would do effectively the same thing uh but once it applies now we're back on

our domain system and we can see that the rule ID that gets applied for blocking the service control manager interface Z matches the one that was uh provided on CIS

wall all right so the third Hur I wanted to discuss is what about legitimate use right uh presumably some of these RPC interfaces are going to be used by normal legitimate business processes so for example if you have say like a monitoring tool that's polling service configurations against hosts in your environment it would realistically need to access the service control manager RPC interface to do so and so how do you work around that while still blocking these attacks by the large majority of users and so the solution here is that you can use the user token filtering of RPC filters to allow specific users to access those interfaces while blocking everyone else and so I'm going to go through a

walkthrough of doing that by fil making an RPC filter that allows members of a domain group to access that filter while blocking other ones so the first thing you do is you define your Active Directory Group so right here we have on the top an active directory group called uh RPC allowed uh and then you'll grab the sit of that and then we'll take a look at the members of our our RPC allow domain group and we have one member named tcan and so this is a user that you would set to be allowed to access the RPC interface then what you do is you would create a permit RPC filter that allows uh members of that domain Group by the

Sid so the Sid here in this sddl string is the same one from our previous slide for the RPC allowed group and so that's given a permit action in our RPC filter and then we apply effectively the same um condition without the match and block it so in both cases we're filtering on the service control manager interface the 367 uuid uh the first is the allow for the group member the bottom is the block for everyone else and so then if we try to use sc. XT to query a Target that has this RPC filter applied in this case we're using the domain user vulture which is not part of the RPC allowed group and they're blocked from access

you can see at the bottom sc.exe is given an access Deni the top part is just uh during the Cy fall to show that the credentials are working and valid for this user however if we then run it again as our domain user 2an which is the one that it is a member of the RPC allowed group and part of the allowed RPC filter we can see that we get back the installed Services uh from sc.exe by running against our remote Target and now this all sounds great RPC filters sound great but there are some limitations to be aware of it's not a Panacea um so I wanted to cover some of the more pressing limitations of RPC

filters the first is like I mentioned if you're looking to deploy RPC filters via the registry method you need to restart the system after the changes to the registry have been applied um and this can be a nonstarter for a lot of different systems some systems have very strict uptime requirements so they can't necessarily be restarted for this to take effect or maybe you don't have a great method of forcing reboots on your systems maybe your end user workstations don't have a great way to do that and so this can be a non-starter for some folks uh the second is the All or Nothing issue uh you can't filter on the specific procedure numbers of the RPC

interface you have to either block the RPC interface entirely or not um so that's where RPC firewall makes for a great utility is it allows that granularity however in some cases these RPC filters realistically aren't used in a lot of scenarios like with petite patam the EFS RPC interface isn't particularly used all that much so it can be safe to block them however it's hard to know uh the entire impact of what the block is going to be because like I said these are used by legitimate Windows processes so it's not necessarily easy to know especially if you aren't performing the RPC filter auditing for these you don't necessarily know which things in windows are going

to be blocked and that can cause issues um so you really have to do a good job of running an audit pilot to understand what RPC traffic looks like in your environment ahead of time another consideration is that uh RPC filters only apply for remote connections uh so these RPC filters assuming like I said you can interact with these RPC interfaces both locally within the system as well as remotely against a a system on the network networ uh but RPC filters only affect the network case so for example with our service control manager if we write a filter to block service control manager it'll only apply to users interacting with that remotely if I'm logged in

locally to a system and I'm issuing std. exe commands from a local terminal the RPC filters will in no way affect that those

activities the other is like I mentioned with the base filtering engine RPC interface the one that's used to ultimately implement the RPC filters is that it's a local only RPC interface what this effectively means is that if you're looking to deploy RPC filters you can't do it from a centralized location in a push based method because the RPC interface can only be interacted with uh from the local system you can't do a RPC connection for that base filtering engine RPC interface and this is why from the deploy methods we've used methods like netsh because those operate from a local context when deployed through G so when you run netsh through your GP startup script it's netsh

running in the local context not remotely against that Target uh lastly is that um because auditing is so important for this type of deployment you need to have good auditing so you know the extent of what the blocking is going to be you're very heavily dependent on your ability to collect Windows logs from your endpoints and this can be a non-starter for a lot of folks because uh they have a lot of maybe nomatic clients maybe their user workstations aren't on an always on VPN or they don't have a w or W collection mechanism set up or some other way to collect Windows logs from their disparate end points and so it can be a

non-starter for that those scenarios because you need to have those strong auditing capabilities otherwise you're going to be in a scenario where you're blocking things and you don't know why they're being blocked or why these mechanisms aren't working um but they're realistically being blocked by your RPC filters um this is less of a concern if say you're implementing this in a data center where you just have a lot of Windows servers and you can strictly control them you have a good way to uh pull Windows logs from them uh it's less of an issue but it's definitely a strong consideration to make when you're deploying RPC filters is it's heavily tied to your ability to collect Windows

event logs and so that's my talk about RPC filters if you're interested in the slides you can go to this GitHub security risk advisors I'll upload them later tonight uh you can also again hit me up on Twitter here's my handle uh and this QR code will take you to the link so just keep it in mind but thanks everyone if you have questions let me know or if you want to come up talk to me uh later during the day feel free uh but thanks for [Applause] attending

thanks thanks sure

um I don't think it says either of those but you would know because they're both yeah it doesn't say it doesn't say that it was here can pull up the event log uh yeah this is the entire event so you don't get the yeah it's something yeah yeah yeah thanks hey

yeah

yeah yeah see here I'll pull up the slide um yeah so this uh this is the Microsoft link if you're interested but it's the comprehensive guidance for blocking ms08 and as part of the workarounds if you can't apply the fix they mention this uh you might I'm not sure how commonly this s what yeah yeah I came out forever ago it's

patched yeah I mean this for for this it's a very nuclear essentially just blocking all of the RPC traffic entirely for ms8 um so it might be a bit much but it's it's definitely an option that Microsoft provides yeah

yeah