Newsletter - Hackcraft

Microsoft SQL Server Hacking — TDS Downgrade Attack

14/01/2026/in Newsletter/by Nikos Karvounis

Hey there, fellow hackers! As we kick off this new year, it's the perfect time to dive into some research. That’s why we wanted to share an intriguing observation from a deep dive into Microsoft SQL Server hacking via its TDS protocol, conducted by our team member NeCro aka Giannis Christodoulakos. While exploring how SQL Server communicates with clients, he uncovered some weaknesses in the TDS protocol that can be exploited to capture MSSQL account credentials.

Intro

You might be asking, "What on earth is TDS?" And you're definitely not alone! TDS, or Tabular Data Stream, is the protocol Microsoft SQL Server uses to connect with clients, particularly thick-client applications. Through research, it was found that by manipulating the way TDS handles encryption, it’s possible to capture MSSQL account credentials.

In this blog, our team member breaks down how TDS works and examines some of its “features” that can be exploited to retrieve MSSQL account credentials. Our aim is to guide you step by step through this MSSQL Server hacking technique from an ethical perspective, while sharing remediation strategies to secure your assets.

The following article is researched and written by Giannis Christodoulakos.

Motivation

What prompted me to dive into this topic? Well, I kept encountering the TDS protocol during various security assessments, particularly during internal penetration testing. Each time, I couldn’t shake the nagging feeling that there was more to discover beneath the surface. So, I decided to dig a little deeper into the protocol, and what I found was eye-opening.

TDS has some security weaknesses (I’m not calling them vulnerabilities) that often fly under the radar. To put it simply, a classic Man-in-the-Middle hacking attack can easily hijack the connection, downgrade the TDS encryption, and snag MSSQL account credentials. It’s a reminder that even well-established protocols can harbor hidden dangers that we need to be aware of.

TDS Overview

What is TDS Protocol?

Tabular Data Stream (TDS) protocol is a communication protocol developed by Microsoft, primarily used to enable seamless interaction between Microsoft SQL Server and various clients, including applications and other SQL servers. Think of TDS as the middleman that ensures data flows smoothly between a SQL server and a client application, taking care of crucial tasks like authentication, data retrieval and query execution.

TDS Authentication

A vital part of the TDS protocol is TDS authentication. This process acts as the gatekeeper for Microsoft SQL Server, ensuring that clients are verified before any data exchange occurs. It also serves as a facilitator for these data exchanges. To kick off these interactions, the client needs to authenticate with the MSSQL server by entering the credentials for a configured MSSQL account.

Here’s a quick breakdown of TDS authentication flow:

PRELOGIN Packet: When a client (like a thick client application) wants to connect to an MSSQL server, it initiates a session with a PRELOGIN packet to establish protocol details like version, encryption preferences and other settings.
PRELOGIN Response Packet: The server replies with a PRELOGIN packet of its own, responding to the client’s settings and confirming parameters for the session. Key fields in the server’s response include version, encryption preferences, and other compatibility information.
SSL Handshake (Optional): If encryption is available on both ends, the client and server perform an SSL handshake to establish a secure connection. This step is wrapped within the TDS protocol and uses the settings established during the PRELOGIN exchange to determine encryption.
Authentication (LOGIN7 Packet): After the initial setup, the client sends a LOGIN7 packet with credentials, including the username and an obfuscated (but easily reversible) password, to authenticate with the server. Whether this packet is encrypted or sent in plain text depends on the encryption preferences agreed upon during the PRELOGIN exchange.

In a nutshell, these steps outline the initial connection flow of TDS authentication.

But wait, there’s more! In the upcoming sections, we’ll dive into ways to manipulate these encryption preferences. Spoiler alert: we might just find a way to trick the client into handing over those cleartext MSSQL account credentials, all while skipping that whole SSL handshake— rude, I know, but who has time for handshakes anyway? Let’s dig in!

How Encryption on TDS Protocol Works

Now, encryption in the TDS protocol is our main enemy to beat if we want those MSSQL account credentials. And, as they say, to defeat your enemy, you’ve got to know its weaknesses. So, let’s dig into how TDS encryption is established.

How to Understand Encryption Settings and Documentation for Hacking

By exploring Microsoft’s protocol documentation, we gain insight into how the client and server determine encryption settings.

When a client initiates a connection to an MSSQL server, both parties must agree on whether to use encryption. This agreement occurs during the PRELOGIN handshake, specifically in the Client and Server Prelogin Response Packet. During this phase, both the client and server share their preferred encryption settings by selecting one of the following four options:

With these options in mind, the client and server exchange their encryption settings through PRELOGIN packets. Based on these options, they decide how to proceed regarding encryption. Assuming the client supports encryption (which is almost always the case), the server expects the client to follow these rules:

As a result, based on the encryption settings outlined in the table above, both ends will determine the appropriate encryption preference for the connection.

It’s important to note that the default encryption settings for both the client application and the MSSQL server is ENCRYPT_OFF. By default, since both sides support encryption, they will establish an encrypted connection to securely exchange the Login packet data (Based on the table above).

TDS Authentication Flow

Now, let’s break down this process with a practical example. I’ve put together a dummy thick client application to vividly illustrate the connection flow in its default state:

1.When a client connects to the MSSQL server, it sends a TDS7 pre-login message with the default encryption setting, ENCRYPT_OFF (0x00).

2.In the server's Prelogin Response Packet, which has a similar structure to the client's packet, we also see the default encryption preference.

According to the encryption settings outlined in the table above, we expect the application to create an encrypted connection during the Login Packet. This expectation is validated by the subsequent packets (9–12), which demonstrate the establishment of an SSL session using TLSv1.2. The Login Packet is represented as packet 13 in the screenshots and contains the encrypted application data.

The Challenge and the Solution

Our primary challenge on our way to the MSSQL server hacking is determining how to bypass encryption to capture the Login packet containing the credentials we are seeking. As noted earlier, the application and server communicate their encryption preferences through the PRELOGIN packet. Based on this exchange, we can identify four potential scenarios that could allow us to downgrade the encryption on the Login packet and successfully capture the credentials.

Scenario 1 (Default State)

Client: ENCRYPT_OFF
MSSQL Server: ENCRYPT_OFF

This is the most common scenario where both the client and server are in their default configurations. In this state, while encryption is supported, it is not required. Typically, both parties will agree to encrypt the login packet. However, in the event of a man-in-the-middle (MITM) attack, we can intercept the server's PRELOGIN response and modify its encryption setting to ENCRYPT_NOT_SUP, which forces the connection to proceed without encryption.

When the client receives this altered PRELOGIN response, it checks the encryption setting. Seeing that encryption is reported as "not supported" (based on the modified value) and being configured with ENCRYPT_OFF, the client sends the login packet without encryption. This lack of encryption allows us to capture the login packet in plaintext.

It's important to note that the server initially recognizes the client's ENCRYPT_OFF setting and responds accordingly (with ENCRYPT_OFF). However, due to our MITM modification, the client believes that encryption is not supported (ENCRYPT_NOT_SUP). Nevertheless, the server still expects encrypted communication. As a result, when the client sends its credentials in clear text, the server will terminate the connection because it is waiting for encrypted data. Consequently, further communication cannot take place, and no additional packets can be captured through the MITM attack. Therefore, to sustain the attack or manipulate the connection further during this hacking process, we would need to modify the client’s PRELOGIN packet to align with the altered encryption setting (ENCRYPT_NOT_SUP).

Scenario 2

Client: ENCRYPT_ON
MSSQL Server: ENCRYPT_OFF

In this hacking use case, the client enforces encryption, meaning the connection is encrypted by default. If an attempt is made to downgrade encryption, the client will terminate the connection. To bypass this restriction, we would need to modify the client application’s configuration (connection string), changing its encryption setting to ENCRYPT_OFF. Once this change is made, we can proceed with the downgrade attack as described in Scenario 1.

Scenario 3

Client: ENCRYPT_OFF
MSSQL Server: ENCRYPT_ON

In our third hacking scenario, the server enforces encryption, meaning the connection will be encrypted unless tampered with. We can try hacking it with a MITM attack and modify the server's response to set encryption to ENCRYPT_OFF (similar to Scenario 1), which would force the client to send credentials in plaintext. However, there is a limitation: because the server enforces encryption, if we attempt to forward an unencrypted connection to the server, the client will disconnect, as the server will not accept it. Nevertheless, this still allows us to capture the credentials from the login attempt, as we can trick the client into believing that the server does not support encryption.

Scenario 4

Client: ENCRYPT_ON
MSSQL Server: ENCRYPT_ON

In this case, both the client and server enforce encryption, which may initially seem to make downgrading impossible. However, if we have access to modify the client configuration (as in Scenario 2), we can change the client’s setting to ENCRYPT_OFF and subsequently proceed with the downgrade using the approach from Scenario 3. This allows us to force a plaintext connection even when both ends initially enforce encryption.

Conclusion

In our exploration, we’ve delved into four intriguing scenarios for downgrading the TDS protocol's encryption, each offering a creative ethical hacking solution to sidestep its encryption requirements. The main hurdle we face? If the client adamantly enforces encryption, our success hinges on our ability to tweak either the client’s encryption settings or the source code.

Putting It All Together: A Hacking Review

In summary, by demystifying how TDS encryption operates and skillfully utilizing the PRELOGIN handshake, we can manipulate the encryption preferences to gain access to valuable MSSQL credentials. Here’s how the process unfolds:

Identify Encryption Settings: Start by checking the client’s encryption settings as outlined in the Prelogin packet.
Alter Client Encryption Setting (Optional): If the situation calls for it, modify the application's encryption setting. This allows you to send the Login packet unencrypted, even if the client has set it to ENCRYPT_ON.
Man-in-the-Middle Attack: Set the stage for a MITM attack between the client and the MSSQL server. Intercept the PRELOGIN packet and take the opportunity to adjust the server’s encryption response to ENCRYPT_NOT_SUP.
Capture the Credentials: With encryption now disabled, the LOGIN7 packet—containing those all-important credentials—will be transmitted in plaintext. Capture this packet to retrieve the MSSQL credentials.
Establishing Unencrypted Communication: If the server isn’t enforcing strict encryption policies (i.e., it does not require the ENCRYPT_ON option), an unencrypted connection can be established between the client and the server. This opens the door to passive sniffing of unencrypted data flowing between them without further interference.

Practical Attack: A Hands-On Hacking Approach

In this section, we'll walk you through how to address the scenarios we've discussed effectively. For this case, we've got a demo thick-client application at our disposal, along with a tailored Python exploit NeCro crafted to execute a downgrade on the TDS. This hacking script orchestrates a Man-in-the-Middle attack, exploiting the server’s Prelogin encryption options to compel an unencrypted connection. If you're curious to see the actual code in action, you can check it out in my GitHub repository here:

Client IP: 192.168.120.132
Kali Machine IP: 192.168.120.129
MSSQL Server IP: 192.168.120.131

Scenario 1

Client: ENCRYPT_OFF
MSSQL Server: ENCRYPT_OFF

In this hacking use case, we simulate a thick-client application that communicates with an MSSQL server. By inspecting the traffic through Wireshark, as we did in previous sections, we confirm that neither the client nor the server enforces encryption, as it is set to the default value ENCRYPT_OFF. To exploit this weakness, we use the Python script `tds_downgrade.py`.

Execute the script with sudo privileges, as elevated permissions are required for the iptables and arpspoof tools to redirect our traffic during the man-in-the-middle (MITM) attack.

While running the script, we wait to capture a connection to the MSSQL server. We then trigger a connection from the thick client application running on the client host, and voilà! We successfully captured the credentials for the MSSQL account, which belongs to the system administrator.

Scenario 2

Imagine you're trying to connect to an application that enforces encryption right from the start, specifically during the initial connection (the PRELOGIN packet). In this case, any attempt at a downgrade attack will hit a brick wall because the application simply won't allow connections that can't establish secure encryption. But don’t bother. There’s an exciting hacking workaround!

Before we roll up our sleeves, let’s pinpoint when an application mandates encryption versus when it doesn’t. It all boils down to the connection string! This string is crucial as it outlines the parameters we use to connect to the database. Here’s a quick peek into the structure of a connection string:

Server=myServerAddress;Database=myDataBase;User Id=myUsername;Password=myPassword;

Forcing an Encrypted Connection

To ensure your connection is secure, the connection string must include the Encrypt parameter set to True. This tells SQL Server to activate SSL/TLS, ensuring that all data transmission between the client and the database is encrypted.

Server=myServerAddress;Database=myDataBase;User Id=myUsername;Password=myPassword;Encrypt=True;

Leaving Encryption as Optional

To make encryption optional, you can either set Encrypt=False in the connection string or omit the Encrypt parameter altogether:

Server=myServerAddress;Database=myDataBase;User Id=myUsername;Password=myPassword;

Where to Find the Connection String

When you're on the hunt for that connection string, you’ll typically uncover it in one of two handy spots:

Hardcoded in the application’s source code
Stored in one of the application’s configuration files

If the connection string is found in a configuration file, you can easily edit it to remove or adjust the `Encrypt` parameter. However, if the connection string is embedded in the source code, you will need to use a decompilation tool to extract the code, find the connection string, and modify the encryption settings.

Patching Connection String with dnSpy

For this specific case, we will be using dnSpy. This tool is a popular open-source .NET debugger and assembly editor that allows users to decompile, edit, and debug .NET applications. You can find dnSpy available for download here:

Step 1: Open the Application in dnSpy

Launch dnSpy.
Go to File > Open and select the .exe or .dll file of the application you want to decompile. In our case, we select the BankApplication.exe.

Step 2: Locate the Connection String and Edit the Class

Right-click on the method containing the connection string and select Edit Class(C#). This opens the class in dnSpy’s built-in editor.

Step 3: Edit the Connection String to Modify Encryption

Find the Encrypt=True portion within the connection string and change it to Encrypt=False to make encryption optional

Step 4: Compile and Save Changes

After editing, click Compile in the editor window to apply the changes. To save the modified assembly go to File > Save Module.
Choose to Save the modified assembly. This will overwrite the original file by default, or you can specify a new path to keep the original.

Now that the application has been patched to use the ENCRYPT_OFF setting, you can proceed as outlined in Scenario 1 to capture the credentials.

Scenario 3–4

Client: ENCRYPT_OFF | ENCRYPT_ON
MSSQL Server: ENCRYPT_ON

In scenarios where the server enforces encryption, downgrading the client's encryption settings will not suffice, as the server will reject any unencrypted connection. This means that while we may intercept and capture the initial login credentials, we will be unable to maintain a continuous connection to the actual MSSQL server to capture further queries, sensitive data, or any ongoing traffic.

Therefore, our primary focus is only on capturing the credentials. To achieve this, we need to replicate what we did in Scenario 1. However, if the client application is enforcing encryption, we’ll first need to modify the encryption settings as we did in Scenario 2 by patching the connection string to set it to ENCRYPT_OFF. Once that’s done, we’re ready to execute the hacking attack as we did.

With everything set up, trigger a connection attempt from the client application to the MSSQL server, and capture the plaintext credentials!

A Few Quick Tips

For demonstration purposes, we used an input field in the thick-client application to select the MSSQL server. In real-world penetration tests, this option may not always be available. If it is, you can skip the entire MITM setup. Just swap the MSSQL server’s IP address with that of the attacking host while running Responder to capture those valuable credentials.

If you encounter a client enforcing encryption, remember: patch that connection string to turn off encryption before you proceed to snatch the credentials.

Post-Attack Strategy

Once you’ve captured the MSSQL account credentials, it’s time to assess the privileges tied to that account. Connect to the database using those credentials to check if you’ve got admin rights or some high-level privileges. If it does, verify whether xp_cmdshell, a stored procedure that allows executing shell commands directly from SQL Server is enabled. If it’s disabled—don’t worry, you can work to enable it. Once xp_cmdshell is active, you can leverage it to execute commands on the underlying host, potentially gaining remote code execution and expanding your access within the target environment.

Recommended Remediation: Strengthening MSSQL Security

To keep MSSQL credentials secure and prevent potential attacks, consider implementing the following strategies:

Use Integrated (Windows) Authentication: Switch to Windows Authentication instead of SQL Server’s native authentication, which reduces the need to transmit SQL credentials over the network. Integrated Authentication relies on Windows credentials, adding a layer of security against credential interception.

If enforcing this option isn’t feasible, it’s crucial to implement all the following rules carefully to mitigate the impact of the issue:

Set Both Client and Server to Enforce Full Encryption (ENCRYPT_ON)

Ensure that both the MSSQL server and all client applications are configured with ENCRYPT_ON. This prevents any downgrading of encryption, securing the session from the initial connection through data exchange.

Restrict Access to Connection Configuration

Prevent unauthorized modifications to connection configuration settings. Limit permissions on configuration files or embedded connection strings within the application to reduce the risk of encryption settings being altered to ENCRYPT_OFF.
For compiled applications, obfuscate or encrypt connection strings within the source code to make tampering with settings more difficult.

Validate SSL Certificates on Both Ends

Enforce strict SSL certificate validation on both the client and server during the SSL handshake to prevent unauthorized systems from impersonating the MSSQL server.
Ensure that the SSL certificates used by the MSSQL server are signed by a trusted Certificate Authority (CA) and not self-signed, as this reduces the likelihood of MITM attacks with forged certificates.

Affected Versions

Be aware that the TDS downgrade attack predominantly targets versions of the Tabular Data Stream (TDS) protocol prior to TDS 8.0. These older versions, utilized by Microsoft SQL Server, allow optional encryption and don’t strictly enforce secure communication during the PRELOGIN handshake. Fortunately, Microsoft introduced TDS 8.0 in certain MSSQL versions, bringing enhanced encryption and security measures against hacking attempts. As a result, servers using TDS 8.0 or higher are resistant to these downgrade attacks.

TL;DR

Microsoft SQL Server’s TDS protocol allows optional encryption during the PRELOGIN handshake. By abusing this design through a Man-in-the-Middle attack, an attacker can downgrade or disable encryption and force the client to send the LOGIN7 packet in plaintext. This enables the capture of MSSQL credentials, even in environments that appear to support encryption. The attack is especially effective against legacy TDS versions and misconfigured clients that do not strictly enforce ENCRYPT_ON.

Conclusion: A Hacking Apocalypse

This research highlights a critical, often overlooked reality: supporting encryption is not the same as enforcing encryption. This TDS protocol’s flexibility, which is originally designed for compatibility, creates a fertile ground for downgrade attacks when encryption policies are misconfigured or loosely enforced.

By carefully manipulating the PRELOGIN handshake, an attacker positioned as a Man-in-the-Middle can force client applications into transmitting MSSQL credentials in plaintext. The attack does not rely on zero-day vulnerabilities or exotic exploitation techniques, but instead abuses expected protocol behavior, default settings and real-world operational shortcuts. This makes it both stealthy and highly practical during internal penetration tests and assumed-breach scenarios.

From an offensive perspective, the TDS downgrade hacking attack is a powerful reminder that credential exposure can occur before authentication even completes. Even when a database enforces encryption, credentials can still be harvested if the client is tricked into believing encryption is unavailable. In environments with hardcoded or poorly protected connection strings, this hacking risk increases significantly.

From a defensive standpoint, the takeaway is clear:

Optional encryption is a liability.
Client-side configuration matters just as much as server-side policy.
Legacy protocol versions silently undermine modern security expectations.

Organizations relying on SQL Server must treat database connectivity as part of their threat model, not just the database itself. Therefore:

Enforcing ENCRYPT_ON everywhere
Validating certificates
Protecting connection strings
Moving towards Integrated Authentication

are no longer “best practices”; they are baseline requirements.

Ultimately, the TDS Downgrade Attack serves as a case study in how design trade-offs made years ago can still shape today’s attack surface. For attackers, it expands the credential-harvesting playbook. For defenders, it’s a sharp reminder that security controls must be explicit, enforced, validated, and never assumed.

XWizard: From XML to ShellExec Using Wizardry

17/10/2025/in Newsletter/by Nick Aliferopoulos

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!

Red Teaming: Beyond Compliance to Real Cyber Resilience

24/09/2025/in Newsletter/by Villy Varsou

In today's ever-evolving cybersecurity landscape, organizations face an overwhelming array of threats that demand not just robust defenses but also a heightened state of readiness against potential attacks. Gone are the days when simply ticking off compliance boxes was enough to protect digital assets. Red Teaming offers a powerful approach that pushes beyond checkboxes to build true cyber resilience — the ability to prepare for, withstand and recover from cyber attacks. But how does Red Teaming transform cybersecurity strategies from compliance-driven to resilient defenses?

What Is Red Teaming?

Red Teaming is a comprehensive, adversary-focused security exercise where a group of cybersecurity professionals simulates real-world attacks on an organization’s infrastructure, people and processes. Unlike penetration testing, which typically focuses on technical vulnerabilities in isolation, Red Teaming emulates sophisticated threat actors by testing detection, response and recovery capabilities in realistic scenarios.

A Red Team utilizes tactics, techniques and procedures (TTPs) used by cybercriminals, as well as novel in-house research, enabling organizations to identify subtle weaknesses across the entire security posture. This holistic adversarial simulation helps organizations understand how an attacker might breach defenses and move laterally within their environment.

Compliance vs. Real Cyber Resilience

Many organizations invest heavily in compliance frameworks such as GDPR, NIST or NIS 2 standards to meet regulatory requirements. While compliance is critical, it often focuses on controls that are necessary but not always sufficient for strong cybersecurity. Especially when faced as a mere “check-the-box” procedure, it tends to be a static approach that may not reflect current or emerging threats.

Studies show that compliance-driven efforts do not guarantee protection against sophisticated attacks, as compliance primarily ensures minimum cybersecurity standards rather than readiness for complex threat scenarios. This creates a false sense of security, leaving critical gaps unaddressed.

How Hackcraft Red Teaming Builds Real Cyber Resilience

Hackcraft Red Teaming drives organizations beyond baseline compliance by continuously challenging defenses, simulating real-world adversarial tactics, techniques and procedures, with the objective of evaluating your organization's capability to prevent, identify and address both cyber and physical assaults. Our proactive approach and genuine, advanced, tailor-made exercises uncover weaknesses that audits and automated tools might miss, such as social engineering vulnerabilities, misconfigurations and gaps in incident response. Additionally, after each simulated attack, the Hackcraft Red Team provides valuable metrics to help organizations refine their incident response processes. Thorough documentation of findings and remediation actions drives organizational learning and compliance reporting. Integrating these findings into your incident response plans will test and improve your organization's ability to detect and respond to attacks.

For example, Hackcraft Red Team might simulate a phishing campaign combined with network infiltration, testing how quickly teams detect and respond to lateral movement. The findings help organizations improve monitoring, strengthen response playbooks and enhance employee training.

Iterative Red Teaming exercises promote a culture of continuous improvement, where lessons learned feed back into security controls, policies and technology investments, building resilience against evolving threats.

Key Benefits of Hackcraft Red Teaming Beyond Compliance

Enhanced threat awareness: Our Red Team reveals attack vectors previously unknown, increasing organizational understanding of real threats.
Improved incident response: Testing response plans under pressure helps teams sharpen detection and mitigation skills.
Stronger cybersecurity culture: Simulations engage all levels of the organization, reinforcing security awareness and accountability.
Informed investments: Concrete evidence from Red Team findings supports better decision-making in cybersecurity budgets.

Implementing Red Teaming Effectively

To maximize value, Red Teaming must be planned and integrated thoughtfully:

Define clear objectives: Align exercises with organizational risks and business priorities.
Collaborate with blue teams: Pipeline exercise results to defensive/security engineering teams to achieve holistic security operations.
Ensure executive support: Visibility and buy-in at the leadership level enable swift remediation efforts.
Leverage results continuously: Use Red Team insights to update policies, technologies and training iteratively.

Red Teaming represents a shift from simple compliance with regulations to proactive cyber resilience. By simulating realistic attacks, organizations gain insights that help close security gaps, enhance response capabilities and foster a security-first culture. As cyber threats grow more sophisticated, Red Teaming is essential to stay ahead, protect critical assets and maintain business continuity beyond regulatory checklists.

FAQ

Q: How does Red Teaming differ from Penetration Testing?
A: Penetration Testing focuses on finding specific vulnerabilities, often in isolation, while Red Teaming simulates full adversarial attacks to test detection, response and resilience across technical and human layers.

A useful analogy to understand how various (not just cyber) security models function is the Swiss cheese model. Penetration Testing typically examines just one layer of this model, while Red Teaming usually assesses all layers to identify −hopefully− potential bypasses throughout the entire system.

Q: Is Red Teaming necessary for small businesses?
A: While resource-intensive, smaller organizations can benefit from scaled Red Teaming exercises or third-party services to evaluate critical risks and improve defenses proactively.

Q: How often should Red Teaming be conducted?
A: It depends on the organization’s risk profile, but regular exercises (e.g. annually or biannually) combined with continuous monitoring provide the best resilience-building approach.

Q: Can Red Teaming help with regulatory compliance?
A: Yes, Red Teaming complements compliance efforts by verifying that controls are effective against real-world threats, often exceeding baseline requirements.

Offensive X: Why Offense Is the New Defense?

25/06/2025/in Newsletter/by Nikos Karvounis

The pulse of Offensive Cybersecurity was alive and thriving last week at the Athens Conservatoire during an incredible event, Offensive X! What about Offensive X? An electrifying journey into the heart of Offensive Cybersecurity that brought together some of the brightest minds in the field. Participants exchanged insights and explored the latest developments, fueling inspiration and reigniting the passion that drives every member of the Hackcraft team!

Inspirational ethical hackers from all over the world, thought-provoking presentations, coffee breaks to connect, catch up and exchange fresh ideas in the Offensive Cybersecurity landscape. And of course, drinks that sparked new insights! We are thrilled to be a platinum sponsor for such an amazing event, and it’s been fantastic to see so many bright minds gathering around our booth, mingling with the Hackcraft team.

Offensive X’s Conclusions: The Landscape

We find ourselves in a black swan world for the Offensive Cybersecurity, where new attack surfaces are popping up and the demand for innovation is skyrocketing. A major shift is already underway. Imagine brain-computer interfaces opening up direct neural attack vectors, quantum computing poised to shatter all existing cryptography, and the blend of digital and physical realms turning everything – yes, even your Tesla- into potential hacking targets.

The reality is crystal clear: attackers are evolving at lightning speed. This is where strategic thinking comes into play: The offensive landscape is a marathon, not a sprint; we need to anticipate threats rather than just react to them. This calls for us to continuously refine our techniques and explore innovative strategies. Bridging the gap between academic knowledge and real-world application is essential. And above all? We must embrace our passion for creativity and innovation as we craft fresh strategies!

Why Prioritize Offensive Cybersecurity?

Offensive services are not just tests. They are rehearsals. With Security Assessments and Red Teaming, you’ll uncover hidden vulnerabilities that traditional security tools often overlook. These assessments simulate real-world attack scenarios, giving you a clear picture of how well your defenses hold up, assessing your detection capabilities, and measuring your response readiness.

By embracing offensive services, you can:

Identify unknown weaknesses before attackers do
Validate the effectiveness of existing controls
Test your incident response under pressure
Prioritize remediation based on business risk
Build continuous improvement into your security strategy

In regulated industries and critical infrastructure especially, offensive cybersecurity is vital not only for security but also for compliance, resilience and long-term business continuity.

Why Hackcraft?

Because we are a top-notch Offensive Security Team that is constantly advancing its knowledge and training on the latest adversarial tactics, techniques and procedures (TTPs). We believe that crafting ethical attacks is a piece of art. Each attack is unique. Wearing the attacker’s mask, our two specialized teams dedicated to advanced Security Assessments and real-world Red Teaming exercises, operate with precision and discretion to uncover your blind spots. Backed by continuous research and development, we stay ahead of emerging threats and techniques. We also believe in giving back. Through open-source contributions on our Blog and GitHub, we share tools and insights to strengthen the global security community. As we forge ahead, we view offensive exercises not merely as a security measure, but as a readiness evaluation against the known and the unknown of the threat landscape.

Experience the art behind the attack. Contact us to discover how we can assist your organization.

Safeguarding Business Growth: A Successful Red Teaming Story

29/04/2025/in Newsletter/by Villy Varsou

An exciting conversation about Red Teaming with Aggelos Karonis, Head of Technology, Information Security at Kaizen.

The Challenges

“Kaizen’s DNA revolves around continuous progress, which requires a stable base to build on. As Kaizen experiences rapid growth, we sometimes prioritize speed over security, making some assumptions. The truth is, when you rely mainly on assumptions about your organization's security, it leaves you with a sense of uncertainty. You need to challenge and evaluate them to make sure you're on the right security track. Additionally, we wanted to evaluate the effectiveness of the new security measures we had introduced with the engineering team and create a roadmap based on the results. Moreover, armed with the tangible evidence of security gaps and potential breaches uncovered by a Red Teaming exercise, we aimed to gain commitment from Top Management, secure budget allocation and obtain the necessary support.”

The Solution

“While periodic checks provide some level of assurance, bringing in different external partners occasionally to assess your infrastructure adds an extra layer of confidence; that’s why we rotate partners. In this case, we chose a Red Teaming exercise by the Hackcraft Red Team to bring to light gaps that go beyond the usual shortcomings such as policy gaps, by simulating real-world scenarios. With a strong reputation, a solid track record, deep expertise and established cooperation with many other organizations, this team is the one we wanted to collaborate with to provide us with a fresh perspective on our infrastructure.

Hackcraft experts' immense enthusiasm for the project was exceptional: always ready to take advantage of all existing opportunities, agile towards any changes and prepared with backup plans to carry out alternative scenarios and attack paths. Their commitment to achieving goals that aligned seamlessly with ours was evident. Notably, each team member exhibited an ingrained attacker mindset, thinking from the perspective of the individual who may threaten our organization.

Moreover, the established relationship before the Red Teaming exercise started sets the Hackcraft Red Team apart. Thorough preparations, guidance on setting realistic goals and continuous communication during the exercise were instrumental. As an organization that provides 24/7 services, Kaizen prioritizes that our customers' experience is never compromised. Therefore, I deeply appreciate the team's practice of informing me before taking any action. This enabled me to maintain control throughout the exercise. In addition, it provided me with assurance that no mistakes, which could affect the quality of our services, would be made. Overall, it was an exceedingly positive experience for me.

Additionally, the detailed reporting we received after the Red Teaming exercise was outstanding. The report met the high standards we expect from top international groups. The technical superiority and expertise of the team also brought to light findings that we might have otherwise missed. The adept handling and finesse of the presentation process, coupled with the team's ability to tailor their approach in order to cater to the specific requirements of both executive and technical teams, were noteworthy. They also expertly handled challenging questions, demonstrating thorough preparation. Collaborating with Hackcraft experts was a game-changer for me and exceeded my expectations, providing the assurance I had been seeking.”

The Results

“Regarding the results, I'd like to highlight some important findings from this Red Teaming exercise. First, it's essential to regularly revisit, rethink and review the assumptions we make to drive each organization forward. We can't afford to let old assumptions persist without re-evaluating their validity and considering any necessary adjustments or additional controls. Second, it's not sufficient to just have the best security solution or product. Proper configuration is crucial to ensure its effectiveness. Without it, even top-notch products will have a minimal impact on your organization's security.

Two significant things have changed for us after Hackcraft Red Teaming. First, there has been a noticeable shift in our people's mindset towards security, especially among those who are new. We're making the most of it, leveraging opportunities, like Cyber Security Awareness Month in October, to incorporate insights from Hackcraft Red Teaming into our training sessions. The second change is that our technical teams have gained a deeper understanding of the impact of their actions on security. It's been particularly eye-opening for those involved in infrastructure setup who previously may not have had the blue teaming mindset to harden this setup. Overall, we identified valuable opportunities for improvement within our security plan, underscoring the imperative to comprehensively review our well-established procedures, policies and exceptions, as well as to reevaluate some decisions made based on assumptions.”

About Red Teaming

“In all my discussions about Hackcraft Red Teaming, I always highlight the same point: Utilize these services and expertise to make your organization aware of potential threats. At various security conferences, I always point out that it's not a matter of “if an incident will occur” but rather “when”. Therefore, it's crucial to be prepared, have countermeasures and strive to delay potential threats. It's important to remember that security professionals may hesitate to conduct large-scale exercises to identify weaknesses within an organization due to fear of exposure. This fear could lead them to downplay or embellish the findings. But here's the thing: if we're not honest about our findings during these exercises, we're only setting ourselves up for trouble in the event of an actual incident. The consequences of a fundamental security breach won't be sugar-coated, so it's essential to confront the truth, no matter how uncomfortable. Even if it's not a full Red Teaming engagement, any offensive security exercise that challenges their way of operating is essential. That's why I firmly believe every organization should conduct Red Teaming exercises to the extent permitted by their capabilities and guided by their risk assessments, regardless of size or perceived risk tolerance. Hackcraft Red Teaming is the most holistic service an organization can receive.”

From One-Time to Recurring: Why Businesses Must Rethink Penetration Testing

25/02/2025/in Newsletter/by Villy Varsou

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

From Compliance to Resilience: The Synergy between DORA, TIBER EU and Red Teaming for Enhanced Security in the Financial Sector

30/07/2024/in Newsletter/by Villy Varsou

The number of cyber-attacks has nearly doubled since the start of the COVID-19 pandemic. The IMF's Global Financial Stability Report highlights the high exposure of the financial sector to cyber risks, with almost one-fifth of all incidents affecting financial firms. While cyber incidents have not been systematic so far, severe incidents at major financial institutions could pose a significant threat to macrofinancial stability through a loss of confidence, disruption of critical services, and due to technological and financial interconnectedness. As a result, regulatory bodies have acknowledged the need for enhanced cybersecurity measures to protect critical infrastructure and consumer data. This has led to the development of frameworks such as the Digital Operational Resilience Act (DORA) and the Threat Intelligence-Based Ethical Red Teaming (TIBER EU) initiative. These regulatory frameworks emphasize the importance of not only complying with regulations, but also building a resilient organization capable of withstanding and recovering from cyber-attacks.

TIBER-EU: A Dedicated Red Teaming Framework

TIBER-EU (Threat Intelligence-Based Ethical Red Teaming) was developed by the European Central Bank (ECB) to enhance the resilience of entities that provide core financial infrastructure against cyber threats. However, it can be used for entities in all critical sectors, not just the financial sector. It mandates bespoke Red Teaming tests that simulate realistic cyberattacks on institutions' critical functions using threat intelligence.

Promotion of Red Teaming:

Targeted Exercises: Under TIBER-EU, financial institutions undergo Red Teaming exercises designed to replicate the specific threats they face. These exercises are orchestrated by external teams, ensuring an unbiased and thorough evaluation.
Risk Identification: By simulating sophisticated attacks, TIBER-EU helps institutions uncover hidden vulnerabilities and assess their ability to detect and respond to real threats.
Actionable Insights: The findings from these exercises are used to strengthen the institution's cybersecurity measures, enhancing their resilience against actual cyber threats.

DORA: Integrating Red Teaming into Comprehensive Resilience Testing

DORA (Digital Operational Resilience Act) aims to ensure the operational resilience of financial entities within the EU against digital disruptions. It establishes comprehensive requirements for ICT risk management, incident reporting and resilience testing.

Promotion of Red Teaming:

Broad Scope: While DORA covers all aspects of ICT risk management, it specifically includes Red Teaming as a key component of resilience testing.
Regulatory Compliance: Financial entities are required to conduct regular Red Teaming exercises to demonstrate their preparedness against cyber threats and ensure compliance with DORA's stringent standards.
Continuous Improvement: DORA emphasizes the need for ongoing resilience testing, including Red Teaming, to adapt to the evolving threat landscape and continuously enhance security measures.

The Synergy Between TIBER-EU and DORA

Enhanced Cyber Resilience:

Both TIBER-EU and DORA recognize Red Teaming as essential for enhancing the cyber resilience of financial institutions. These frameworks encourage the use of realistic attack simulations to identify and mitigate vulnerabilities.

Regulatory Alignment:

Conducting Red Teaming exercises helps financial institutions align with the regulatory requirements of both TIBER-EU and DORA. This proactive approach demonstrates a commitment to maintaining high security standards and protecting customer data.

Operational Continuity:

By integrating Red Teaming into their risk management strategies, institutions can better prepare for and respond to cyber incidents. This ensures operational continuity and minimizes the impact of potential disruptions.

Implementing Hackcraft Red Teaming: Best Practices

Hackcraft Red Teaming is a genuine, advanced and tailor-made exercise that entails simulating real-world adversarial tactics, techniques and procedures, with the objective of evaluating your organization's capability to prevent, identify and address both cyber and physical assaults. Our specialized experts use the latest threat intelligence to tailor for your organization Red Teaming exercises that reflect current and emerging threats.

Regular Red Teaming exercises are crucial for staying ahead of evolving threats and strengthening your defenses. After each simulated attack, the Hackcraft Red Team provides valuable metrics to help organizations enhance their incident response processes. Thorough documentation of findings and remediation actions will drive organizational learning and compliance reporting. Integrating these findings into your incident response plans will test and improve your organization's ability to detect and respond to attacks.

As cybersecurity threats continue to rise, it's crucial for financial institutions to stay a step ahead. Regulatory frameworks like TIBER-EU and DORA highlight the vital role of Red Teaming in keeping organizations safe. With Hackcraft Red Teaming, simulated real-world attacks provide invaluable insights into vulnerabilities and preparedness for cyber incidents. Embracing this approach doesn't just ensure regulatory compliance - it also boosts an organization's cyber resilience significantly.

Don't wait until it's too late - integrate Hackcraft Red Teaming into your risk management practices and build stronger defenses against cyber threats. Contact us!

Beyond Checkboxes: Red Teaming vs Traditional Security Assessments

14/05/2024/in Newsletter/by Villy Varsou

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!

Defending Against the Surge: Red Teaming in the Wake of Ransomware Attacks in Europe and Greece

23/02/2024/in Newsletter/by Villy Varsou

As we bid farewell to 2023, let us highlight some enlightening insights. The research conducted by Corvus Insurance has shown a significant increase of over 95% in ransomware attacks compared to the previous year. According to Statista, over 72% of businesses worldwide were affected by ransomware attacks during 2023. Education, local and state government, healthcare, distribution and transport were among the top targets.

Moreover, Statista mentions that 36% of the organizations suffered ransomware attacks because of exploited vulnerabilities in 2023, with leisure and entertainment industry to be the most vulnerable to ransomware attacks. Credential compromise was the second-most common cause of successful ransomware attacks, while malicious e-mail ranked third. Consequently, 51% of organizations are planning to increase security investments as a result of a breach, including incident response planning and testing, employee training, threat detection and response tools, as IBM points out.

Source: Corvus Insurance

Significant Ransomware attacks in Headlines

The International Battleground

In recent years, we have witnessed a surge in ransomware attacks targeting organizations across all sectors. From disrupting critical infrastructure to paralyzing healthcare systems, these attacks have not only caused financial losses but have also shaken the foundations of trust in our digital systems and in several organizations.

To start with one of the most far-reaching cyber-attacks of the year, the file-transferring software MOVEit was victim to a ransomware attack starting in May 2023, unknown SQL injection vulnerability (CVE-2023-34362) in the MOVEit Transfer software which led to the attack affecting hundreds of billion-dollar companies including the BBC, Zellis, British Airways, Ofcom, Ernst and Young, Transport for London and more. In April, financial services firm, NCR, was hit by a ransomware attack that disrupted payment processing systems. Last but not least, in November China's biggest lender, ICBC, U.S. arm, was a ransomware victim.

Greece's Wake-Up Call

Beyond Europe, ransomware has cast its dark shadow across Greece. Major corporations, government agencies and even critical infrastructure have fallen prey to sophisticated attacks. The ripple effects have been felt not only in financial terms but also in terms of the broader implications for national security and public trust.

To mention some noteworthy ransomware attacks, Papaki.gr, the well-known Greek domain registrar, reported on July 27th that their systems had been accessed without authorization. While the details of the cyber-attack have not been disclosed, Papaki has informed that it is likely that two clients were affected by data leak. Moreover, Hellenic Public Properties Company (HPPC) experienced such an attack last November with limited impact on the organization's service operations as backups were properly configured and regularly updated. Also in November, the University of the Aegean had important documents published into the dark web after refusing to pay the ransom to attackers.

Hackcraft: A Proactive Αrtful Defense Strategy

In the face of this escalating threat landscape, organizations must adopt a proactive stance in defending against ransomware attacks. Neurosoft’s powerful service is Hackcraft, a Red Team highly capable of delivering exceptional Adversary Simulation services (Red Teaming). Red Teaming involves an adversary attack simulation of real-world threats (Advanced Persistent Threats) based on realistic scenarios that evaluate the overall security posture in order to test and measure the effectiveness and responsiveness of the people, processes and technology used to defend an organization digitally and physically.

Understanding Ransomware Simulation Exercises

To empower organizations towards this ransomware surge Hackcraft members have designed Ransomware Simulation Exercises. These exercises simulate real-life attack scenarios to test the organizations’ ransomware prevention and detection capabilities. Based on threat intelligence, these Exercises are tailored to meet the specific needs and objectives of each organization, providing a comprehensive and customized solution to the unique challenges faced by different business sectors.

Benefits of Hackcraft Ransomware Simulation

Realistic Scenario Testing
Hackcraft Red Team creates tailor-made ransomware attacks based on real-life ransomware samples such as Cl0p and Lockbit. These ethical attacks help organizations better prepare and understand their team's response to the pressure of an actual ransomware attack.
Identifying Vulnerabilities
Hackcraft Ransomware Simulation allows organizations to evaluate the overall ransomware readiness, security posture and anti-ransomware controls. Identifying vulnerabilities and weaknesses in their current cybersecurity measures against ransomware threats helps in addressing potential gaps in security.
Testing Incident Response Plans
During a Ransomware Simulation, Hackcraft can help organizations assess the readiness of their incident response plans. This includes evaluating communication processes, decision-making, coordination among various teams, security controls, and in-place mechanisms, processes and policies.
Employee Training and Awareness
Hackcraft Ransomware Simulations offer a chance to train employees in identifying and responding to ransomware threats, raising awareness and improving overall security hygiene.
Meeting Compliance Requirements
In some industries conducting regular Red Team Exercises, including Ransomware Simulation Exercises, is a requirement for compliance. It helps organizations demonstrate their commitment to cybersecurity best practices.
Strategic Decision-Making
Insights gained from Hackcraft Ransomware Simulation debriefing enable informed strategic decision-making regarding cybersecurity investments and improvements. It supports a culture of continuous improvement, ensuring that defenses evolve to address emerging threats.

Hackcraft Ransomware Simulation vs Ransomware

The recent ransomware incidents that occurred in Greece and Europe should be a wake-up call for organizations to prioritize proactive cybersecurity measures. One such effective strategy is to adopt Ransomware Simulation, which allows organizations to foresee, detect and prevent potential threats before they escalate into crippling attacks. As we forge ahead, Hackcraft views Ransomware Simulation not merely as a security measure, but as a readiness evaluation against the known and the unknown of the ransomware threat landscape. It is a weapon of choice for safeguarding our digital future against the rising tide of ransomware.

Social Media

LinkedIn

Twitter

Github

Services

Contact

Intro

Motivation

TDS Overview

What is TDS Protocol?

TDS Authentication

How Encryption on TDS Protocol Works

How to Understand Encryption Settings and Documentation for Hacking

TDS Authentication Flow

The Challenge and the Solution

Scenario 1 (Default State)

Practical Attack: A Hands-On Hacking Approach

Scenario 2

Forcing an Encrypted Connection

Leaving Encryption as Optional

Where to Find the Connection String

Patching Connection String with dnSpy

Step 1: Open the Application in dnSpy

Step 2: Locate the Connection String and Edit the Class

Intro

The Ecosystem

Wizards

The Executable

The DLL

The XML DTD

The Properties

The ISP Confirm Page

User-Shared Data

Structuring the property values

The WoW Wizard

Execution of Binaries

Outro

What Is Red Teaming?

Compliance vs. Real Cyber Resilience

How Hackcraft Red Teaming Builds Real Cyber Resilience

Key Benefits of Hackcraft Red Teaming Beyond Compliance

Implementing Red Teaming Effectively

FAQ

Offensive X’s Conclusions: The Landscape

Why Prioritize Offensive Cybersecurity?

Why Hackcraft?

The Challenges

The Solution

The Results

Why One-Time Penetration Testing Is Not Enough

How Recurring Penetration Testing Strengthens Cyber Resilience

Best Practices for Implementing a Recurring Penetration Testing Strategy

Shield a Resilient Future for Your Business

The Unique Advantages of Hackcraft Penetration Testing

TIBER-EU: A Dedicated Red Teaming Framework

Promotion of Red Teaming:

DORA: Integrating Red Teaming into Comprehensive Resilience Testing

Promotion of Red Teaming:

The Synergy Between TIBER-EU and DORA

Enhanced Cyber Resilience:

Regulatory Alignment:

Operational Continuity:

Implementing Hackcraft Red Teaming: Best Practices

Beyond Checkboxes: Red Teaming vs Traditional Security Assessments

Traditional security assessments: The Limitations of Checkboxes

Red Teaming: Going Beyond the Checklist

Key Differences

Benefits of Red Teaming

Identifying Real Life Attacks Impact

Pinpointing weaknesses

Improving detection mechanisms

Enhanced Incident Response

Continuous Improvement

Awareness stimulation

Team of devoted experts

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

The International Battleground

Greece's Wake-Up Call

Hackcraft: A Proactive Αrtful Defense Strategy

Understanding Ransomware Simulation Exercises

Benefits of Hackcraft Ransomware Simulation

Hackcraft Ransomware Simulation vs Ransomware

Social Media

Services

Contact