Security picked up DISKPART.EXE /S DISKPARTSC.TXT

[LEWISF]

Hello all -

Veeam Support - Case # 07545635

I am seeing a number of WinEventLogs coming from our security monitoring, with the source type being XLMWinEventLog, reporting that a destination host is using its computer account to run a parent process C:\Windows\SysWOW64\MSIEXEC.EXE, which in turn runs C:\Windows\SysWOW64\DISKPART.EXE.

For example, SERVER1 is the destination, SERVER1$ is the user and then the parent process, and then the new process.

DISKPART is running a script using the following command: DISKPART /S "C:\ProgramData\Veeam\Setup\Temp\DISKPARTSC.TXT.


I put in a ticket with Veeam to find out why and how Veeam would use DISKPART .

They stated

While DISKPART is a Windows Operating System utility, Veeam may use this utility to request information about components that are being backed up, as well as during specific restore processes:

• Veeam may use diskpart in a few different situations, including:
  
  Restoring a MBR disk to a UEFI system
  
  Checking the SAN policy. You can use the SAN command in diskpart to check the SAN policy of a Windows OS
  
  Checking for a logically locked disk. You can use diskpart.exe to check if a disk is logically locked in the Veeam proxy
  
  Checking the disk status. You can use diskpart to check the disk status if you are having trouble restoring VMs via SAN

When the process finishes the script file is no longer in the TEMP folder, so I do not know what it is doing. It is very concerning that the log states the script originates in the Veeam folder. In the follow up with their engineer he stated that "Veeam Agent for Windows does not utilize diskpart in any way during backup".

I don't feel comfortable with this process or the explanation. Has anyone ever seen this before?

TIA.

Lewis

[david.domask]

Hi Lewis,

Thank you for the report and for sharing your case number.

I'm not immediately familiar with this behavior and I'm checking internally to get more information, and will update this thread once I have more information. I appreciate the research thus far, though additional question if I may:

1. How was this detected by the security team? I'm guessing some monitoring app saw the executable and/or path and flagged it, but would be great to just confirm how this was being detected.

[LEWISF]

Splunk and Crowdstrike.

[david.domask]

Hi LEWISF,

Thank you for the details and please excuse the delayed response.

Can I ask you to add some information to the case for further review?

1. Confirm if the detection is visible just in general or only when performing a specific operation (backup, restore, etc)
2. Please export logs for a job backing up the servers where this was detected and upload them to the case
3. Was this specifically during backup or even when no backups are running Crowdstrike/Splunk are detecting it?

Thanks!

[LEWISF]

Dave -

I will upload the logs on Monday.

I'll have to match the log entries against our backup jobs so I have to talk to our InfoSec Team.

Lewis

[LEWISF]

Dave -

I uploaded the logs for the servers that are being backed up to the case. This only happened on 12/11 and 12/16.

Looking at the times for the logs, this activity would have taken place during backups. Backups start at 1800.

Lewis

[david.domask]

Hi Lewis,

Thank you for the update and for the logs -- I was able to find references to diskpart in the logs like you're suggesting, and I'm discussing this with my colleagues from our RND team. Will update when we have more information.

[LEWISF]

Thanks David.

[david.domask]

Hi LEWISF,

Thanks for your patience -- after review of the logs, we can confirm this is normal. Specific services in Veeam will utilize diskpart to set the following commands for diskpart to ensure no problems with backup when specific Veeam services are installed.

The commands that diskpart will utilize: "san policy=OfflineShared", "automount scrub" or "automount disable"

I've asked Support to please update the case as well with more detailed information, but in short it's expected and can be ignored.

[LEWISF]

David -

Thanks for your help. We received an in-depth explanation from support which allowed us to close the ticket.

After further research, we were able to find and confirm the following by our QA team:
During the installation of TransportSvc, TapeSvc, or GateSvc, the commands might be executed:
diskpart /s "san policy=OfflineShared"
diskpart /s "automount scrub"
diskpart /s "automount disable" (for Windows older than Vista or WS 2008)
The diskpartsc.txt file contains only the respective commands: "san policy=OfflineShared", "automount scrub" or "automount disable"
This can be observed in the logs here:
Line 6825: ***Veeam*** Executing diskpart command: 'san policy=OfflineShared'...
Line 6826: ***Veeam*** Executing diskpart command...
Line 6827: ***Veeam*** Script file: C:\ProgramData\Veeam\Setup\Temp\diskpartsc.txt.
Line 6829: ***Veeam*** Creating diskpart process (diskpart /s "C:\ProgramData\Veeam\Setup\Temp\diskpartsc.txt")...
Line 6831: Microsoft DiskPart version 10.0.17763.1911
Line 6836: DiskPart successfully changed the SAN policy for the current operating system.
Line 6838: ***Veeam*** Diskpart error code: 0x00000000.
Line 6860: ***Veeam*** Executing diskpart command: 'automount scrub'...
Line 6861: ***Veeam*** Executing diskpart command...
Line 6862: ***Veeam*** Script file: C:\ProgramData\Veeam\Setup\Temp\diskpartsc.txt.
Line 6864: ***Veeam*** Creating diskpart process (diskpart /s "C:\ProgramData\Veeam\Setup\Temp\diskpartsc.txt")...
Line 6866: Microsoft DiskPart version 10.0.17763.1911
Line 6871: DiskPart successfully scrubbed the mount point settings in the system.
Line 6875: ***Veeam*** Diskpart error code: 0x00000000.

This is performed to prevent issues when using Direct SAN Access. While it's not specific to Veeam Agent for Windows, it is executed regardless, as it's part of the general logic for installing the transport service.