What the DLL is happening? A practical approach to identifying SOH.

so today we're going to talk about search order hijacking or soh first a little about me i spent several years doing digital forensics and incident response consulting and moved from there to corporate in financial services where i ran our security operations team for several years i have been on red canary's detection engineering team since early in 2016 and i lead our certs internal training program for detection engineering now we're not going to go very far into dll search order itself but i wanted to set out at least some basic information dols are shared code libraries on windows and based on references within the binary will get loaded into memory upon execution or as needed to perform that

shared function they can be leveraged by multiple processes and aside from having each dll's fully qualified path hard-coded into the binary or a manifest file the system will search for dlls following a preset order and that preset order is where search order hijacking or soh comes into play if you know the name of a legitimate dll that will be loaded by a legitimate and presumably trusted but not frequently executed binary you can set up soh by placing a copy of that binary along with a malicious dll that has a legitimate name together in a path that you control which is commonly under the user profile then when that legitimate binary executes the malicious dll gets loaded

into memory thus running its code in the context of a trusted process it kind of sounds confusing but we'll show some real world examples later and it will make more sense then if it is confusing now why is soh important well every year like many companies we put out a threat report this past year soh was in eighth place overall from an adversary technique perspective and it impacted 16 percent of our customers the numbers increased over the course of the year as we developed new ways to identify related activity and as we continue to improve our detection i expect that those numbers will also increase it's not just about the usage but about the visibility into that usage

now there will be a link to our report later in the prezo for those interested in the nitty-gritty details and yes with the roll out of mitre's attack sub techniques this summer soh is now 1574.001 instead of 1083 and there will be a link to that also just to save you the the searching around for it now we see soh applied by various adversaries both commodity and advanced and it provides a means of persistence potential privilege escalation and bypassing various security controls for prevention detection and and so on now if you watch the full disclosure email list at all you'll quickly realize that a lot of legitimate signed binaries for operating systems and trusted third parties

such as security software are vulnerable to soh a lot on the good side from the security software perspective even though it shows up on that list a lot we don't see it leveraged very commonly so that's a plus of course it usually just gets disabled which makes it easier i guess now there are a lot of talks and articles about soh from different aspects but very few address early identification based on ongoing activity instead they focus on after the fact forensics reverse engineering dlls or executables and so on now where i work we leverage endpoint detection and response or edr telemetry to identify and alert on active threats within our customer environments now the concept of using edr telemetry

is what i'm going to focus on today but not from the perspective of any given platform nor how we use it specifically i've tried to keep this generic from that angle and just provide you with methods and concepts that you can use to extract information from whatever data sources you have at your disposal now the most accurate way to identify soh is based on knowing every legitimate binary every single legitimate binary on every single system and the paths that they are expected to launch from and check every single one of those then you combine that with knowing every single legitimate dll that they are supposed to load by name and path and check the unexpected binary launch

paths to see if any of those dlls are being loaded as well now you back that up a little bit further earlier in the chain and you can identify the activity based on the file rights of those legitimate executables and illegitimate dlls to those unexpected paths now you might think it would be as easy as watching for any file rights of xs or dlls to those paths but not so much all right so if the best way isn't all that feasible and if you didn't gather from what i just said that the best way isn't all that feasible then i did a terrible job of explaining it but it's not that feasible okay so if the best way isn't at least keep

it in the back of your mind and while you're doing that focus on the behaviors that may help point to soh at various levels of the technique

okay so let's say that you have a scenario which looks like it might be related to soh how can you confirm it check out the xes to see if they're legitimate and remember they might be windows system binaries but often ones that are not commonly used or other legitimate binaries for other software once you've done that check the dlls in the same directory do any exist that are named the same as known legitimate ones but don't contain the appropriate signatures or metadata or maybe even if you get lucky they've already been flagged by antivirus engines as malicious again the key aspect here is that the malicious dll gets loaded from the same path as the xe

if the legitimate dll of that name is likely to already be in memory that will get checked first and then the technique fails okay so i've talked at a very high level about some methods that you might be able to use to identify and validate soh activity next i'm going to provide some sample logic that you might be able to get used might be able to use to get started and as i mentioned already detecting soh isn't necessarily straightforward and some of the concepts are fairly broad and may be prone to noise in order to raise up activity a lot of it depends on the individual environment now these are some these are some rough

ideas of generic query logic that i pulled together based on some of the things that we look for to identify soh hopefully the logic construct is something that you can use to create queries within your own environment if you aren't already looking for these again this is not any specific query language it's just designed to kind of capture the concepts of what we're looking for now be be forewarned they may be noisy depending on your environment so don't go full production right from the start also two of these will only work if you can reliably collect signature information on binaries and depending on your data source this might be challenging especially if the information is stored

in a manifest instead of being embedded in the binary all of them will probably require further tuning uh depending on the individual results you get in your you know specific scenario and environment now as alluded to before detecting actual search order hijacking can be challenging and we continue working on ways to do that better one of the other ways we've approached it is by building detector logic that's focused on other behavior which can potentially lead us to or point to soh and as a result we've seen soh associated with scheduled tasks process injection masquerading use of admin shares and domain trust discovery to name just a few now we're going to look at a couple of

examples from real world activity not just something that was set up in a lab not from reversing malicious dlls or researching specific malware and so seeing it in this way should provide some clues that we can then watch for as activity unfolds on systems now here we have the creation of a scheduled task to launch a legitimate windows binary one that's part of bitlocker from a path under the user profile in app data roaming so not only do we have a legitimate binary where it shouldn't be but there's also the persistence mechanism from scheduled task okay and it's important to note that most of the binaries that we see used this way are not commonly observed executing

right they pick something that's unusual less common but still trusted the reason is as previously mentioned it's less likely to cause conflicts with dlls that might already be loaded into memory by another process remember that if that legitimate dll is already in memory the soh won't work it's going to fail because it's going to check memory first before it looks for path so shortly before or excuse me shortly following the creation of the schedule task the executable is written to disk in the reference path the windows command processor did this file right and if i recall correctly it copied the bdui srv xc from system32 and wrote it here to this path so that's also a possible detector

concept and we can leverage all these observables in a lather rinse repeat sort of scenario to continue improving detection methodologies now at this point we definitely know that we're looking at soh being set up the dll being written here has a legitimate name but it's not the actual api 32 dll nor is it in the proper and expected path now this one did not succeed in going through all the way so we didn't see execution but it is a classic setup for soh it's all right on to another detection in this one we have the windows script host writing a binary under the user profile metadata indicates that it's the gnu diffutils binary cmp.exe but the size is wrong and

osen says that it's emitted it actually kicks off other activity which goes into the soh side of things and we're right back into a situation that's very similar to the previous detection a copy of the windows fax and scan binary is written to disk under the user profile in app data roaming getting ready here folks a confirmation received a legitimately named but completely malicious dll is written to the same path it's ready to load we've got it it's going the binary and the dll are prepped and now the scheduled task gets set up for execution and persistence our wfs binary will be live and in living color in 60 minutes and here we go execution

of wfs pexi and sure enough immediately following that execution the malicious dll is loaded into memory by wfs we have once again soh for the win but it's not all doom and gloom all we need to do to prevent this is to have all compiled binaries have explicit fully qualified path references for all dlls that will be used including dependent dlls that's all simple right okay maybe not at any rate good security hygiene can help microsoft has some resources that can be leveraged to help mitigate some of that risk and having solid detection methodologies that balance out signal to noise and catch activity as early as possible can help as well and so here are some links to more

information if there's time for questions here that's great otherwise i'll be available in the discord channel and happy to talk more on the topic thank you very much