Intro

Red Teaming in the day and age of EDRs often involves finding niche and obscure ways, to perform actions usually under specific constraints, or as we call them internally, bypass primitives. While hunting for such primitives, an interesting small ecosystem became the center of attention for further research, that of XWizard. It should be noted at this point, that XWizard.exe itself, a Microsoft binary shipped with Windows installations is, and has been for quite some time, a known living-off-the-land binary. Detection-wise however, the spotlight falls on the following:

• XWizard.exe executed from a non-default location (i.e. this Sigma rule)
• XWizard.exe used to execute a COM object (i.e. this Sigma rule)

These approaches cover cases that abuse XWizard.exe to sideload DLLs or execute COM objects using RunWizard, one of the available subcommands. While only the related public rules are considered, and there obviously may exist private detection approaches that cover more use-cases of the LOLBin, these observations were enough to kickstart research efforts into other functionalities for more potential primitives.

The Ecosystem

The "Extensible Wizards" ecosystem, or XWizard for short, is comprised of the following three modules:

• The main functionality (defining, loading and presenting wizards), implemented in XWizards.dll.
• The executable, XWizard.exe, a thin command-line wrapper around the main functionality.
• A plethora of predefined wizards, implemented throughout various DLLs, which are declared appropriately in the registry.

Although the ecosystem is mostly undocumented, research observations on each of these modules will be further analyzed below in reverse order of appearence.

Wizards

Wizards in the ecosystem refer to a series of consecutive forms a user is expected to "fill" in order to achieve a specific result. Each step (usually form) triggers the next required step, often passing the necessary context to it, mostly containing data gathered from the user up until that point, or otherwise produced in prior steps.

An intuitive way to think of wizards is the typical "Next", "Next", "Install" dialogues presented during usual Windows software installations, although actual wizards present in default Windows installations may involve tasks like the following:

• Workspace Setup

• Wireless Connection Setup

Such wizards are declared by GUID in the registry, under the key
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\XWizards\Components:

The Executable

A quick analysis of the executable XWizards.exe reveals that it is only a thin command line wrapper around the main DLL which contains the actual functionality. First, it verifies that there was at least one argument provided by the user and loads XWizards.dll, behavior which introduces the DLL sideloading opportunity described in the introduction (under constraints which are out of scope of this article):

After verifying a successful DLL load and pushing its activation context structure, it attempts to resolve an export from the DLL, defined by the first user-provided argument:

Finally, it executes the recovered export, passing it a handle to its window, its module, the rest of the command line and its ShowCmd:

As a result, subcommands supported when executing XWizard.exe are exports in the DLL file. A caveat that should be mentioned is that, although not shown in the screenshots, the function GetAnsiProcName appends a W character at the end of the first argument, preferring the widechar versions of exports specified in the DLL. Running xwizard.exe RunWizard {GUID_HERE} essentially calls xwizards.dll!RunWizardW.

The DLL

The main DLL file of the ecosystem, XWizards.dll supports the following exports which can be called by XWizard.exe (due to receiving the appropriate parameters):

• ProcessXMLFileA/W
• ResetRegistrationA/W
• RunPropertySheetA/W
• RunWizardA/W

As discussed in the intro, RunWizardA/W is ecosystem functionality which has been explored previously and also been signatured. Educated guessing as to where interesting functionality may reside focuses attention on ProcessXMLFileA/W, which allows processing of an XML file to (un)register or invoke wizards. While (un)registering wizards essentially wraps editing the wizard components in the registry and thus requires modification of an entry in HKLM (essentially local administrator privileges), invoking wizards requires no special/elevated privileges.

The XML DTD

Microsoft was kind enough to provide the DTD schema for the XML that the ecosystem may process, which resides in C:\Windows\System32\xwizard.dtd. While discussing the complete specifics of the DTD schema is out of the scope of this blog post, a few minor details are presented below.

A valid XWizard XML file begins with an <xwizard> element, which may contain any number of <registry> or <run> elements. The first kind describes actions in regards to the XWizard components described in the registry, such as (un)registering wizards and as previously discussed requires elevation, but the latter allows defining "run" steps for wizards, which will be executed in the same way as running xwizard.exe RunWizard. An example <run> element is presented below:

<?xml version="1.0" standalone="no"?>
<xwizard version="1.0">
  <run>
    <wizard name="ExampleWizard" id="{116ABC1A-F7DB-45A7-ADDA-D5A57A08C6FF}"/>
  </run>
</xwizard>

When xwizard.exe ProcessXMLFile Example.xml is run with the above in Example.xml, the relevant wizard is invoked, exactly replicating the behavior of xwizard.exe RunWizard {116ABC1A-F7DB-45A7-ADDA-D5A57A08C6FF}. However, the DTD schema allows more control over how the wizard is invoked.

The Properties

As discussed above, wizards receive a context containing required information, either computed or fetched from the user in previous steps. This context is normally passed to each wizard "step" by its previous one, but when invoking wizards through XML this context may be directly specified in the XML itself. Each run element can also contain a list of properties, as seen below:

<?xml version="1.0"?>
<xwizard version="1.0">
  <run>
    <properties>
      <property name="ExampleProperty" id="{116ABC1A-F7DB-45A7-ADDA-D5A57A08C6FF}" type="wstr">
        Example property value of type 'wstr'!
      </property>
    </properties>
    <wizard name="ExampleWizard" id="{116ABC1A-F7DB-45A7-ADDA-D5A57A08C6FF}"/>
  </run>
</xwizard>

Properties are matched to their relevant wizard by the id attribute and the type attribute denotes the type of data that will be parsed from the XML value of the property. Lastly, wizards can reference properties by name. In a more pratical example, the wizard {7071ECF1-663B-4BC1-A1FA-B97F3B917C55} (registered as Message Page and implemented in connect.dll) reads a property named FatalErrorDetails to provide content to the error form it presents:

<?xml version="1.0" encoding="UTF-8"?>
<xwizard version="1.0">
  <run onerror="ignore">
    <properties>
      <property name="FatalErrorDetails" id="{7071ECF1-663B-4BC1-A1FA-B97F3B917C55}" type="wstr">Hello, World!</property>
    </properties>
    <wizard name="ExampleWizard" id="{7071ECF1-663B-4BC1-A1FA-B97F3B917C55}"/>
  </run>
</xwizard>

Processing this file presents the following wizard, demonstrating that values of properties can successfully be set in the XML file:

At this point, the focus was shifted towards identifying wizard components with interesting functionality, controllable (to an extent) by properties defined in the XML file.

The ISP Confirm Page

The ISP package registration wizard implemented in connect.dll, and more specifically the "ISP Confirm Page" component of the wizard ({7071EC32-663B-4BC1-A1FA-B97F3B917C55}) is one example of such interesting functionality. The method CISPConfirmPage::HrHandleNavigation which is called to handle the navigation to the next "step" (or form, or page, they are equivalent) of the wizard performs the following steps. First, it gets the value of the property ISPOfferData and places a pointer to it in offer.OfferData:

While the _ISP_OFFER_ELEMENT structure is not relevant, the definition of the _ISP_OFFER_DATA, which is the type of offer.OfferData is:

typedef struct {
    PWSTR OfferProviderName,
    PVOID Unused1,
    PVOID Unused2,
    PWSTR ShellExecuteTarget
} _ISP_OFFER_DATA;

The next step it does is check whether OfferData.ShellExecuteTarget is a GUID. In case it isn't, as you might have guessed, it calls ShellExecuteExW on OfferData.ShellExecuteTarget with the verb open:

While at first glance this seems optimal, it is important to understand that only the pointers within the struct are controllable from the XML provided value, not the data they point to. As a result, achieving controlled execution of ShellExecuteExW requires identifying valid (and ideally controllable) data to point to. Although most of the userspace is not a valid target due to ASLR, Microsoft was once again kind enough to provide predictable (but not controllable) data mapped at an also predictable location in the userspace.

User-Shared Data

The KUSER_SHARED_DATA structure is a read-only data structure provided by the kernel, mapped at 0x7FFE0000 for the userspace. It offers widechar string data at offset 0x30, which contains the field NtSystemRoot, containing the path to the root folder of the windows installation (i.e. C:\Windows). Although this string is not controllable, offsets into it could be used to form relative paths. More specifically, starting at 0x7ffe3600 is the widechar string L"Windows", an excellent target to control OfferData.OfferProviderName and/or OfferData.ShellExecuteTarget to.

Structuring the property values

The next step is formatting the XML property value data accordingly, so that they are parsed into the _ISP_OFFER_DATA structure. While the DTD allows for multiple types of property values to be defined, most of them do not cover the length of the target data structure.

Due to not being constrained by length, the following value types are interesting candidates:

• str (ASCII string)
• wstr (Widechar String)
• hexbinary

The options of bstr and variant where also considered, but were identified to not allow full control of the structure, again due to length constaints. The value type of hexbinary denotes a string of hex characters which will be parsed while fetching the property. Although it sounds promising, it unfortunately pads combined values, resulting in control of only one of each two consecutive bytes. The remaining string related options are valid candidates, but come with a very specific constraint, they do not support null-bytes. More specifically, plain ASCII strings cannot be utilized to denote pointers containing any null-bytes, and widechar strings cannot denote pointers containing any two consecutive null-bytes. The target pointer, 0x7ffe3600, or 0x000000007ffe3600 in x64 land violates both constraints. In x86 land, however...

The WoW Wizard

Processing the XML file with the Windows-on-Windows x86 version of XWizard, located in C:\Windows\Syswow64\XWizard.exe allows utilizing the pointer 0x7ffe3600, which is compatible with the previously described constraints for the wstr data type. As a result, the following XML can be constructed, encoding a pointer to KUSER_SHARED_DATA.NtSystemRoot in the property value for both the OfferProviderName and the ShellExecuteTarget fields of the _ISP_OFFER_DATA structure. The same happens for both the unused fields. Essentially, the bytes of the target pointer, in little endian, are encoded as widechar characters and properly escaped in XML.

<?xml version="1.0"?>
<xwizard version="1.0">
  <run>
    <properties>
      <property name="ISPOfferData" id="{7071EC32-663B-4BC1-A1FA-B97F3B917C55}" type="wstr" action="retrieve" allocation="LocalAlloc">
        &#x0030;&#x7ffe;&#x0030;&#x7ffe;&#x0030;&#x7ffe;&#x0030;&#x7ffe;
      </property>
    </properties>
    <wizard name="ExampleWizard" id="{7071EC32-663B-4BC1-A1FA-B97F3B917C55}"/>
  </run>
</xwizard>

Processing the above with the x86 version of XWizard.exe leads to the following dialogue:

Upon clicking "Set up", a controlled execution of ShellExecuteExW happens, "opening" the path C:\Windows (KUSER_SHARED_DATA.NtSystemRoot) in explorer.exe.

Execution of Binaries

While launching the Windows Explorer at the system root is an interesting proof-of-concept, execution of actual binaries requires (ab)using a quirk in ShellExecute(Ex)A/W. These variants of ShellExecute, when provided with the "open" verb and a relative path, will first verify that the relative path exists, and then utilize PATHEXT for the execution part. This in turn means that when a relative path example is attempted to be opened, if example.exe exists next to it, it will be executed instead. By adjusting the pointer to KUSER_SHARED_DATA.NtSystemRoot, essentially skipping bytes off its start, the absolute path can be turned into a relative path:

<?xml version="1.0"?>
<xwizard version="1.0">
  <run>
    <properties>
      <property name="ISPOfferData" id="{7071EC32-663B-4BC1-A1FA-B97F3B917C55}" type="wstr" action="retrieve" allocation="LocalAlloc">        &#x0036;&#x7ffe;&#x0036;&#x7ffe;&#x0036;&#x7ffe;&#x0036;&#x7ffe;
      </property>
    </properties>
    <wizard name="ExampleWizard" id="{7071EC32-663B-4BC1-A1FA-B97F3B917C55}"/>
  </run>
</xwizard>

Processing this file leads to an attempt to "open" the relative path ./windows (KUSER_SHARED_DATA.NtSystemRoot + 6). Executing this from a directory which contains a windows directory and a windows.exe binary, will result in the following wizard:

As a proof-of-concept executable, C:\Windows\System32\calc.exe was copied to the current directory as windows.exe. Upon clicking "Set up", a hard-earned calculator pops up:

Outro

A rather appropriate TL;DR version of this article would be "Parsing of malicious XML files with the x86 variant of XWizard.exe from a controlled path may lead to command execution". Although the above statement on its own does not sound very exciting or useful in a Red Teaming context, the test system used for this research contains 177 potential wizard components defined in the registry which were analyzed, a subset of which was further analyzed manually to identify the ISPConfirmPage Wizard Component used in this proof-of-concept. The goal of this article is to shed some light on any previously unexplored attack surface on the XWizard ecosystem and spark ideas and research which may lead to the discovery of further primitives.

Thanks for reading, and happy hunting!

In today's fast-paced digital landscape, cyber threats are always evolving, rendering static security measures inadequate. Organizations that fail to take proactive steps in addressing security vulnerabilities often end up dedicating excessive resources to managing the aftermath of security incidents, rather than preventing issues from escalating in the first place. Many companies rely on one-off security assessments, commonly known as penetration tests, which can create a distorted sense of security.

Why One-Time Penetration Testing Is Not Enough

New vulnerabilities constantly emerge due to infrastructure and software updates, misconfigurations and the relentless creativity of cybercriminals aided by AI tools. A penetration test conducted months or even years ago does not reflect the current security landscape. It’s like relying on an old map in a rapidly changing terrain. Existing security measures might be outdated, ineffective, or poorly configured, leaving organizations vulnerable and unprepared.

How Recurring Penetration Testing Strengthens Cyber Resilience

It’s obvious that the cyber threat landscape is dynamic, making periodic testing essential. Businesses must not treat penetration testing as a one-time security checkbox but as a continuous security strategy. Transitioning from a one-time test to a recurring model ensures long-term protection and security posture enhancement.

Conducting regular penetration tests means you'll spot security gaps before the attackers do. This not only helps identify vulnerabilities before they can be exploited but also enhances compliance with critical frameworks like NIS 2 and ISO 27001, which stress the importance of ongoing security assessments. Plus, it fosters a security-first culture within your organization, reinforcing best practices and promoting robust security hygiene.

Best Practices for Implementing a Recurring Penetration Testing Strategy

Are there best practices for implementing an effective and proactive penetration testing strategy? First, determine the testing frequency based on your organization's risk level, industry standards and compliance requirements (e.g. quarterly, bi-annually). Moreover, it is essential to assess security risks every time there are significant modifications to your infrastructure, such as software or application updates, changes to network and system architecture, steps taken to meet compliance and regulatory requirements, exposure to security risks or third-party integrations.

Additionally, integrate testing with vulnerability management to create a continuous improvement cycle prioritizing high-risk assets while ensuring comprehensive security coverage across the organization. Finally, use various testing methodologies—such as vulnerability assessments, infrastructure and application penetration testing and red teaming—to address different attack scenarios and meet specific business needs and requirements.

Shield a Resilient Future for Your Business

Many organizations still take a reactive stance on security—only addressing vulnerabilities after a breach has already happened. This approach not only leads to soaring costs from data breaches but may also inflict lasting reputation damage. To stay ahead of the game, it’s time to rethink your cybersecurity strategy.

Imagine making cybersecurity a continuous journey rather than a one-off task. The regular validation of security measures through recurring penetration testing is crucial for building true resilience against cyber threats. By harnessing the power of tailored manual penetration testing together with the use of automated tools, organizations can do more than just meet compliance standards—they can actively shield themselves from ever-evolving threats.

Investing in regular penetration testing equips organizations with the preparedness needed to tackle future cyberattacks confidently. With a recurring engagement, Hackcraft can help you identify your evolving needs through review meetings, ensuring you’re always one step ahead. Whether the focus is on compliance, technical enhancements, or the resolution of specific challenges, our team is dedicated to supporting your journey toward a more secure future.

The Unique Advantages of Hackcraft Penetration Testing

Hackcraft Security Assessments are cybersecurity services designed to identify and address vulnerabilities within an organization's digital infrastructure before malicious actors exploit them. Our proactive approach goes beyond just identifying weaknesses; it's about transforming your security posture. We assess your systems, networks and applications through a blend of cutting-edge automated tools and expert manual techniques.

Our security assessments involve a multi-step process that starts with reconnaissance and vulnerability identification, then moves into exploitation, and finally culminates in detailed reporting and actionable recommendations. What sets Hackcraft apart is our commitment to manual penetration testing together with the use of automated tools. Our seasoned security experts customize their strategies to align with your organization’s unique risks and business context, allowing them to think like real attackers. This means uncovering vulnerabilities that automated solutions might overlook. Thus, this procedure ensures that business logic flaws, technical flaws, social engineering risks and advanced attack vectors are thoroughly evaluated.

Let Hackcraft empower your organization to stay one step ahead of cyber threats, ensuring your defenses are robust and your data remains safe.

Do you need more info about Hackcraft Security Assessments? Click here

Beyond Checkboxes: Red Teaming vs Traditional Security Assessments

In today's ever-evolving cyber threat landscape, organizations require a robust security posture to safeguard their critical assets. While traditional security assessments have long been a cornerstone of security strategy, they may not always provide a comprehensive view of an organization's true cyber resilience. This is where Red Teaming steps in.

Traditional security assessments: The Limitations of Checkboxes

Traditional security assessments, like penetration testing and vulnerability scanning, seem to be a necessary security foundation, as they play a vital role in identifying security weaknesses within your IT infrastructure. These assessments often follow a checklist approach, checking for specific vulnerabilities and configuration errors. While valuable, traditional assessments have limitations. They may miss zero-day vulnerabilities or novel attack vectors not yet included in existing vulnerability databases. Additionally, they often focus on technical aspects, potentially overlooking human factors contributing to security risks.

Red Teaming: Going Beyond the Checklist

Red Teaming takes security assessments to the next level, as it goes beyond the checkbox mentality of traditional security assessments. It involves adversarial attack simulation of real-world threats (Advanced Persistent Threats), where a team of ethical hackers (the Red Team) attempts to breach your defenses using the same techniques and tools as real attackers. Their aim is to test and measure the effectiveness and responsiveness of the people, processes and technology used to defend an organization digitally and physically.  Unlike traditional assessments, which focus on compliance and adherence to security standards, Red Teaming takes a holistic approach to security testing, mimicking the tactics, techniques and procedures (TTPs) of actual adversaries. The Hackcraft Red Teaming, notably, is based on tailor-made scenarios, without whitelisting and exceptions that evaluates overall security posture.​

Key Differences

• Scope and Methodology: Traditional security assessments typically follow a predefined scope and methodology, focusing on specific areas such as network security, application security, or compliance requirements. In contrast, Red Teaming adopts a more adversarial mindset, using tactics such as social engineering, penetration testing and reconnaissance to emulate the tactics of real attackers.
• Realism and Immersion: Red Teaming strives to create a realistic and immersive testing environment that closely mirrors the tactics and techniques used by real adversaries. This approach allows organizations to identify blind spots, weak points and hidden vulnerabilities that may not be uncovered through traditional security assessments.
• Focus on Detection and Response: While traditional security assessments primarily focus on identifying vulnerabilities and weaknesses, Red Teaming also emphasizes detection and response capabilities. By simulating realistic attack scenarios, Red Teams help organizations evaluate their ability to detect, respond to and mitigate cyber threats in real-time.

 Benefits of Red Teaming

• Comprehensive Risk Assessment: Red Teaming provides a more comprehensive and realistic assessment of an organization's security posture, uncovering hidden vulnerabilities and weaknesses that may go undetected by traditional assessments.
• Enhanced Preparedness: By simulating real-world cyberattacks, Red Teaming helps organizations better understand their adversaries' tactics and develop proactive strategies to mitigate risks and strengthen defenses.
• Improved Detection and Response: Red Teaming helps organizations test and refine their detection and response capabilities, enabling them to identify and mitigate cyber threats more effectively.
• Provides Actionable Insights: Red Teaming delivers specific recommendations to address vulnerabilities and strengthen your overall security posture.
• Cultural Shift: Red Teaming encourages a cultural shift towards a proactive and security-aware mindset, fostering collaboration, innovation and continuous improvement across the organization.

Benefits of Hackcraft Red Teaming

• Identifying Real Life Attacks Impact

Hackcraft Red Team replicates real-world attack scenarios, providing organizations with a comprehensive view of their preparedness. The exercise's realism produces results identical to an actual incident, which cannot be ignored or disputed.

• Pinpointing weaknesses

By conducting simulated attacks, Hackcraft Red Team identifies vulnerabilities in an organization that may not be uncovered during routine security assessments.

• Improving detection mechanisms 

After the simulated attack, Hackcraft experts provide a detailed timeline and IOCs to help organizations create strict and proactive detection rules.

• Enhanced Incident Response

The ethical simulated attacks offered by Hackcraft help organizations refine their incident response strategies and prepare them to respond swiftly and effectively when faced with a real threat. After each simulated attack, the Hackcraft Red Team provides detailed metrics, including Time to Detect, Time to Respond and other useful data, to assist organizations enhance their incident response process and procedures.

• Continuous Improvement

Red Teaming is not an one-time exercise for Hackcraft. It is an ongoing process that enables organizations to adapt and evolve their defenses based on emerging threats.

• Awareness stimulation 

Tailored awareness training can be provided to the organization's personnel based on attack statistics resulting from the scenarios created and used by Hackcraft Red Team.

• Team of devoted experts 

If you're looking for a reliable and efficient way to enhance your organization's cybersecurity, then Hackcraft is an excellent option to consider. Hackcraft Red Team uses their unmatched expertise to create and conduct tailored ethical attacks that meet the specific needs of each organization.

Red Teaming and Traditional Security Assessments: Two peas in a pod

Red Teaming and traditional assessments are not mutually exclusive. Traditional assessments provide a foundational understanding of your security posture, while Red Teaming adds depth by simulating a real-world attack. Together, they offer a more complete picture of your organization's security resilience. Moving beyond the limitations of checkboxes, Hackcraft Red Team offers a valuable tool for organizations seeking proactive and dynamic approaches to strengthen their cyber defenses. With Red Teaming organizations can identify, assess and mitigate cyber risks, gain valuable insights into their security posture and improve their readiness to defend against real-world threats. By embracing both Red Teaming and traditional security assessments, organizations can enhance their resilience, agility and preparedness to defend against evolving cyber threats and safeguard their critical assets and data.

Ready to take your security posture to the next level? Consider incorporating Hackcraft Red Teaming into your security strategy!