COM Hijacking (Persistence)

[Music] hi i'm andy and in this video we'll be exploring how to attack detect and defend against component object model hijacking component object model or com for short is a framework which enables interactions between various software components it allows software a to access functionality from software b the entity which holds the desired functionality is referred to as the com server and the entity which is requesting the functionality is the com client even though these are two software components running on the same machine quick side note a related technology distributed com allows for comm interactions across the network but it's out of the scope of this video com components are identified by a class id which is a pseudo-randomly generated globally unique identifier com can be used to embed one application's functionality within another for example the ability to embed an excel sheet within a word document or a word document in an excel sheet if you really want to numerous aspects of system functionality exist as com components allowing various parts of the operating system to call them one of these is the audio related interfaces this allows the code to be written once but called anywhere the comm interface means that third-party software applications can also call these pieces of system functionality firefox is one such application which calls the imm device enumerator interface when it starts up in order to discover what sound devices are present on the system so that it knows where to send an audio stream if a user navigates to a website which has multimedia content parts of windows also define com interface standards which if a third party developer follows allows them to create components which extend the default behavior of the windows interface for example the right-click menu items provided by 7-zip or the sync status icons provided by cloud storage services in this scenario the third-party develop code is the com server and the windows explorer shell is the com client when a client wants to access a com component it makes a call to the windows api function cocreate instance including the class id desired windows checks the registry under hkey classes root to locate where the code for this component resides once it's located the path and file name of the dll file windows creates an instance of the dll and cause dll get class object to retrieve a pointer to the object this is passed back to the requested application which then calls a series of interface functions to actually perform the actions that it wants com is a deeply embedded part of the windows operating system and can provide a means of establishing persistence on a machine once it's been compromised by an attacker there's several different flavors of this attack and we'll walk through each in turn [Music] firstly an attacker may craft a malicious com component and register it in such a way that it's executed on startup or in response to a specific event a common method involves the creation of a shell extension for windows such as the right-click menu options or icon overlay which we saw in the introduction here's an example of a malicious shell extension which acts like a right-click menu extension once registered explorer will run the code inside it every time the user right-clicks a file in this example there's no obvious adverse behavior observed by the user but behind the scenes the malicious shell extension is exfiltrating a copy of every right-clicked file over to an attacker controlled machine although this could just as easily be doing any other malicious action such as crypto locking files or re-establishing a commander control connection to an attacker remember from the intro section that com components are identified by their class id and that the co-crea object api call looks up the mapping to the right dll file via the hkey classes root registry hive well hkey classes root is actually a merge of the entries in h key current user and hkey current machine most genuine com objects get installed in hkey local machine so that they are available system wide for any user however the entries in hkey current user take precedent so an attacker can place an entry to their own malicious dll here causing it to be run instead of the real com component as the name suggests adjustments to hkey current user are only effective for the current user but have an advantage for an attacker of being modifiable by a standard non-privileged user local admin rights are not required a simple test malicious payload can be created with metasploit's msf venom command this one will create a reverse shell back to the attacker's machine once on a victim's machine an attacker just needs to create a key under hkey current user software classes class id which has the same id as a commonly used component and point it towards the malicious dll this example is targeting the class id of imm device enumerator which we saw in the introduction this is called by many apps including firefox so if our victim tries to load firefox now it launches a reverse shell back to the attacker the problem with this example is that the malicious component doesn't do any of the functions expected of it so it effectively breaks firefox and prevents it from loading this makes it obvious that something is wrong leading to a higher chance of discovery a smarter solution involves a more elegant payload like this which is a combination of devfrog's c plus plus reverse shell and leolubeck's comproxy poc when a client tries to instantiate a com object the reverse shed is launched and at the same time it creates an instance of the original genuine com component and hands this back to the client once the registry entry under h current user is updated to point towards this new more refined payload if our victim launches firefox again everything looks like it's working normally but in fact has suddenly established that reverse shell back to the attacker as always this payload could do any one of a number of different nasties and is not limited to just a reverse shell some applications may not know the class id of the component that they want to call but instead know the more friendly looking prog id identifier an api call to class id from prog id fetches the class id but this too is vulnerable to hijack in a similar way by creating an entry under he current user to link the genuine prog id with the class id of a malicious component yet another com hijack method involves setting an object to trigger windows into treating any reference to one component as a reference to a different component here the malicious hijack observed in the previous attacks is being given a new class id this effectively undo's the hijack next a new key is created which matches the class id of the target component in this case it's for imm device numerator again but instead of specifying a dll a new key called treat as is created which in turn is assigned the value of the malicious class id if the victim tries to load up firefox again windows will follow the tritas request and load up the malicious payload again and if that wasn't enough another variant of com hijacking targets orphaned com references which may get left over after the installation and subsequent uninstallation of an application if the uninstall application fails to tidy up properly then an attacker can place a malicious dll in the location where the original genuine dll was located although this may not always be feasible due to file system permissions david tulis of ncc labs includes a function to search for orphaned class ids amongst a suite of powershell tools for com hijacking there's a link in the video description to the github page to grab a copy of this along with links to his 2019 dabicon talk on the subject registry entries for com components should change very infrequently and only in response to software installs or updates therefore registry monitoring can be an effective mechanism to detect the registration of a new malicious com component as i've covered in previous videos turning this on requires a policy configuration to activate object auditing and then specifying which keys and values you want to monitor in registry editor remember that most valid com components are installed for system-wide use and so it's rare to see registrations on a per-user basis so special attention should be given to monitoring for new items in hkey current user software classes class id as these could very well be hijack attempts once registry monitoring is configured altered values can be observed in the windows event log some threat intelligence sources cite specific malicious class ids associated with an attack or threat actor so monitoring for these in particular can be advantageous [Music] actually preventing com hijacking is impractical as com is such a fundamental system feature a better approach is to focus on the detection of potential hijack through monitoring as discussed in the previous section and ensure it's followed up by robust investigation it's also worth noting that com hijacking cannot stand alone an attacker will have to have used other techniques to gain an initial foothold or laterally move onto a device before undertaking com hijacking to gain persistence and similarly we'll use the persistence delivered by com hijacking to undertake further lateral movement or action on their objectives so adding defensive measures against other techniques can help slow or prevent an attack at a different stage of the attack chain even if it's not possible to prevent com hijacking itself it may also be worth undertaking an assessment for orphaned class ids using the powershell script mentioned in the attack section and conducting a tidy up especially if orphaned entries point to directories which are writable by users that about wraps up this video if you found it useful please do give it a like and consider subscribing if you want more of this sort of content drop a note in the comments if there's anything you think i've missed around attacking detecting and defending against the abuse of com hijacking or if you have a good idea of what topic i should cover next i'll see you next time

Channel: Attack Detect Defend

Views: 10,245

Keywords:

Id: svFundrBIiQ

Length: 12min 7sec (727 seconds)

Published: Tue Sep 15 2020