• [ Регистрация ]Открытая и бесплатная
  • Tg admin@ALPHV_Admin (обязательно подтверждение в ЛС форума)

Статья Remote windows credential dump with shadow snapshots: exploitation and detection

stihl

Moderator
Регистрация
09.02.2012
Сообщения
1,166
Розыгрыши
0
Реакции
508
Deposit
0.228 BTC
stihl не предоставил(а) никакой дополнительной информации.


INTRODUCTION

The purpose of this post is to describe a technique for remotely dumping Windows local credentials (SAM) by leveraging Shadow Snapshots. Using Shadow Snapshots makes it possible to access the required registry hives (SAM, SYSTEM, and/or SECURITY) directly over SMB, without executing code on the target machine.

From a defender’s perspective, the post also explains how this activity can be detected. To demonstrate this, we developed a proof-of-concept (PoC) tool that shows how Event Tracing for Windows (ETW) can be used to spot the malicious behaviour.

This technique was added to Impacket’s secretsdump and can be used with the option use-remoteSSMethod.

Detection via ETW is feasible with the WMI and SMB-SERVER providers. We built a PoC to illustrate this detection approach. Detecting this technique should be a priority because it allows attackers to steal Windows local credentials remotely, without any code execution on the victim host.

The theory

First of all, it has to be clear that one “problem” when accessing Windows local credentials is that the access to the necessary hives directly in disk is prohibited even when maximum privileges are used. This conduct is because these hives are mapped on the registry and thus they are in use by Windows internally.

Because of this, traditionally tools for dumping Windows Credentials have relayed on registry to dump that information. For example, backing up from registry with reg save or directly accessing SAM in the registry. Some other tools used File System Drivers to also access the hives directly on disk, pwdump7 for example (Для просмотра ссылки Войди или Зарегистрируйся).

image-1.png

These hives on disks contains the data mapped to the registry structure in REGF format that Windows parses and load into the Registry.

But, what happens when a Shadow Snapshot is created?

When a Shadow Snapshot is created all the files are accessible, including the registry hives on disk containing Windows credentials, but these files are not in use by Windows, as the “real” live files are used. A pinpoint about this, Shadow Snapshots are based on CoW (Copy-On-Write), so the files are the same unless modified in the “live” partition.

Manual approach

To simply test this:

  • Create a Shadow Snapshot
    • wmic shadowcopy call create Volume='C:\'
  • Get the path listing them
    • vssadmin list shadows
    • Код:
      [...]
      Contents of shadow copy set ID: {5590bae6-9edc-4012-b58a-5ff54e937cae}
      Contained 1 shadow copies at creation time: 03/06/2025 17:12:36
      Shadow Copy ID: {6efd3825-90a8-465e-8205-f445f2775769}
      Original Volume: (C:)\?\Volume{1d680c6d-69f7-4ad4-8177-b8240d0cf94c}\Shadow Copy Volume: \?\GLOBALROOT\Device\HarddiskVolumeShadowCopy2
      [...]
  • Access the Shadow Snapshot and navigate to Windows\System32\Config. One of the easiest methods was to use 7z, in latest versions it is not possible.
f7hfsakxkaaqheb.png

Nirsoft has a tool called ShadowCopyView that can also be used.

image-3.png

This way it is possible to access and exfiltrate these hives and dump the credentials.

SMB

The idea is, if it is possible to directly access security hives in disk using Shadow Snapshots, can it be accessed remotely via SMB?

And the response is yes, and it has been documented for long time ago.

SMB supports a format to specify access in the past. Using a timestamp with “GMT format” it is possible to access the file system remotely via SMB in a previous version.

Extracted from the proper Microsoft documentation:


So, using GMT format it is possible to access remotely SAM, SYSTEM, SECURITY and so on.

Impacket has implemented the SMB call to list access in the past available: FSCTL_SRV_ENUMERATE_SNAPSHOTS (Для просмотра ссылки Войди или Зарегистрируйся)

MANUAL EXAMPLE

The following is an example exploiting it manually.

First of all you must create the Shadow Snapshot remotely. This can be done using wmic.

Код:
C:\Users\peter>wmic /node:192.168.24.153 /user:peter /password:[***] shadowcopy call create Volume='C:\'
Executing (Win32_ShadowCopy)->create()
Method execution successful.
Out Parameters:
instance of __PARAMETERS
{
        ReturnValue = 0;
        ShadowID = "{037BE7D1-2915-422A-B961-13065D469BE7}";
};


C:\Users\peter>

In the remote system you will see that the Shadow Snapshot was created.

image-4.png


Now, it can be accessed remotely. As this one was created 6/3/2025 9:02:45 AM (16:02:45 in UTC), the remote GMT path will be @GMT-2025.06.03-16.02.45. Please take into account that it is necessary to use the date in UTC.

image-5.png


And from here it is possible to download SAM, SYSTEM and so on.

image-6.png

AUTOMATION

In order to automate this, a new option was added to Impacket’s secretsdump. The changes were merged on May 2024.

Basically, the same procedure is performed from Python thanks to Impacket. WMI Shadow Snapshot is opened remotely, the create method is then executed, after that SAM/SYSTEM/SECURITY are downloaded via SMB and the Shadow Snapshot is deleted via WMI.

In order to use this method, simply add –use-remoteSSMethod to secretsdump. For example:

Also the remote volume being used can be modified using –remoteSS-remote-volume (it defaults to ‘C:\’). And also the path were SAM/SYSTEM/SECURITY are downloaded locally can be modified using –remoteSS-local-path (it defaults to ‘.’).

We have been using this option in offensive exercises since it was merged into secretsdump wihtout generating any alert in top products and top tier EDRs.

Test it vs your security products and share with us your results.

snapshots_2024-12-27-13_54_40-kali-linux-2024.4-vmware-amd64-vmware-workstation.png

DETECtion

Now the question is, how can it be detected?

For such thing a PoC tool was developed using ETW to demostrate how it is possible to detect this malicious behaviour. Maybe other approaches are possible, but after testing others (like Windows Events) we decided to use ETW.

IOA​

One thing to have clear before developing a defensive tool is the indicators of the malicious behaviour that we want to detect. In this case, we have the following actions that are cleear indicator of this type of attack:

  • A Shadow Snapshot is created via WMI (Win32_ShadowCopy::Create method is called)
  • Suddenly via SMB SAM/SYSTEM/SECURITY are read
  • Also the Shadow gets deleted. Optional indicator, with the other two would be sufficient.
In order to get that logs it is possible to use the following ETW providers:

  • Microsoft-Windows-WMI-Activity {1418EF04-B0B4-4623-BF7E-D74AB47BBDAA}
  • Microsoft-Windows-SMBServer {D48CE617-33A2-4BC3-A5C7-11AA4F29619E}
These two ETW providers gives sufficient information in order to be able to detect the indicators mentioned above.

The key point is to detect the operations described after parsing the consumed events from these two ETW providers.

Код:
if (wcscmp(propertyName, L"Operation") == 0 && wcscmp(value, L"Start IWbemServices::ExecMethod - root\\cimv2 : Win32_ShadowCopy::Create") == 0) {
                std::wcout << "WARNING!!! POSSIBLE REMOTE DUMP USING SHADOW SNAPSHOT. A SHADOW SNAPSHOT HAS BEEN CREATED VIA WMI" << std::endl;
                possible_dumping_detected = true;
            }

            if (wcscmp(propertyName, L"FileName") == 0 && (wcscmp(value, L"System32\\config\\SAM") == 0 || wcscmp(value, L"System32\\config\\SYSTEM") == 0 || wcscmp(value, L"System32\\config\\SECURITY") == 0) && possible_dumping_detected) {
                std::wcout << "CRITICAL WARNING!!! REMOTE DUMP USING SHADOW SNAPSHOT IOA DETECTED. " << value << " DOWNLOADED REMOTELY VIA SMB" << std::endl;
                dumping_detected = true;
            }

            if (wcscmp(propertyName, L"Operation") == 0 && wcsstr(value, L"Start IWbemServices::DeleteInstance - root\\cimv2 : Win32_ShadowCopy.ID=") != nullptr && dumping_detected) {
                std::wcout << "CRITICAL WARNING!!! REMOTE DUMP USING SHADOW SNAPSHOT IOA DETECTED. THE SHADOW SNAPSHOT HAS BEEN DELETED" << std::endl;
                dumping_detected = false;
            }

Read the full source code here: Для просмотра ссылки Войди или Зарегистрируйся

snapshots_2025-01-17-14-24-08-1.gif


Now, when this method is used, the tool detects the indicators described and alert about it.

snapshots_2024-12-27-13_54_40-kali-linux-2024.4-vmware-amd64-vmware-workstation-1.png
snapshots_2024-12-27-04_56_28-.png

Below some full example events parsed after capture are shown.

Код:
WMI Method Invoked Event Captured! Event ID: 11
Provider ID: 337178372-45236-17955
Event Properties:
Property: CorrelationId Value: {00000000-0000-0000-0000-000000000000}
Property: GroupOperationId Value: 1492
Property: OperationId Value: 1495
Property: Operation Value: Start IWbemServices::ExecMethod - root\cimv2 : Win32_ShadowCopy::Create
Property: ClientMachine Value: Local
Property: ClientMachineFQDN Value:
Property: User Value: DESKTOP-81G2RNN\peter
Property: ClientProcessId Value: 2640
Property: ClientProcessCreationTime Value: 0
Property: NamespaceName Value: \\.\root\cimv2
Property: IsLocal Value: 1



WMI Method Invoked Event Captured! Event ID: 11
Provider ID: 337178372-45236-17955
Event Properties:
Property: CorrelationId Value: {00000000-0000-0000-0000-000000000000}
Property: GroupOperationId Value: 1500
Property: OperationId Value: 1501
Property: Operation Value: Start IWbemServices::DeleteInstance - root\cimv2 : Win32_ShadowCopy.ID="{745EBABB-2D5F-486D-89A3-FC1BCCB93121}"
Property: ClientMachine Value: Local
Property: ClientMachineFQDN Value:
Property: User Value: DESKTOP-81G2RNN\peter
Property: ClientProcessId Value: 2640
Property: ClientProcessCreationTime Value: 0
Property: NamespaceName Value: \\.\root\cimv2
Property: IsLocal Value: 1


SMB SERVER Provider Event Captured! Event ID: 8
Event Properties:
Property: SessionId Value: 2c000000001d
Property: ProcessId Value: 0
Property: TreeId Value: 1
Property: MessageId Value: 9
Property: MasterMessageId Value: ffffffffffffffff
Property: Command Value: [Unsupported Type]
Property: CreditsRequested Value: [Unsupported Type]
Property: Flags Value: 0
Property: SecurityFlags Value: [Unsupported Type]
Property: RequestedOplockLevel Value: [Unsupported Type]
Property: ImpersonationLevel Value: 2
Property: CreateFlags Value: 0
Property: RootDirectoryFid Value: 0
Property: DesiredAccess Value: 1
Property: FileAttributes Value: 0
Property: ShareAccess Value: 1
Property: CreateDisposition Value: 1
Property: CreateOptions Value: 40
Property: NameLength Value: [Unsupported Type]
Property: FileName Value: System32\config\SAM
Property: CreateContextsCount Value: 1
Property: LeaseKey Value: {0-0-0-00-000000}
Property: LeaseLevel Value: 0
Property: ConnectionGUID Value: {a33e9acb-584e-0-144e-3fa34e58db1}
Property: SessionGUID Value: {a33e9acb-584e-0-184e-3fa34e58db1}
Property: TreeConnectGUID Value: {a33e9acb-584e-1-7c4e-3fa34e58db1}

Conclusion

We have been using this technique in so many offensive exercises during the last year and a half. We encourage to test this vs your security products and share the results.

REFerences


Для просмотра ссылки Войди или Зарегистрируйся
 
Activity
So far there's no one here
Сверху Снизу