Elvis Wiki - User contributions [en]

Hyper-V Virtual Machine Hardening

2025-01-20T20:45:31Z

CHoerhan:

This article shows how a virtual machine(VM) can be modified to evade detection from malware. This process is also called VM hardening. In dynamic malware analysis, researchers use virtual machines to execute malware in a safe and isolated environment in order to monitor and investigate its behavior. This is why malware author started to use Anit-VM techniques to detect if their programs are running inside a virtual environment and subsequently evade the analysis process. In this article a virtual machine is set up and several open-source VM-detection tools are executed to see how the VM can be detected by malware. Afterwards countermeasures are implemented to mitigate the detection rate of the tools.

== Setup ==
Hyper-V is used for the virtualization. This is because it is a Type 1, bare-metal, Hypervisor, which runs directly on the host's hardware to control the hardware and to manage guest operating systems.

The specifications are:

* Host OS: Windows 11
* Hypervisor: Microsoft Hyper-V
* Guest OS (VM OS): Windows 10

Three tools are used for the VM detection. They are all open-source and can be found on GitHub:

* [https://github.com/a0rtega/pafish Pafish (Paranoid Fish)]
* [https://github.com/kernelwernel/VMAware VMAware]
* [https://github.com/ayoubfaouzi/al-khaser Al-Khaser]

===Initial Test Run===

After the virtual machine setup is complete and all the tools have been installed, a first test can be conducted.

In the unmodified, native machine the tools show a number of positive checks, that hint towards a VM.

Number of detections: Pafish 13 + VMAware 13 + Al-Khaser 31 = '''57 positive detections'''

These numbers are likely to vary between different setups and tool versions.

== Hardening Steps ==

This section contains system modifications that aim to lower the number of positive detections.

===Virtual Hardware Specifications===

Common checks aim at the system hardware. If the disk, memory or processor contain strange values, which typically cannot be found on normal machines, the malware might see this as a sign of a VM.

Very low or odd numbers are highly unlikely in a physical machine. Therefore, see that the VM has at least the following requirements:

* 60-80 GB disk size
* 4-8 GB memory size and no odd numbers
* At least 4 processor cores and no odd numbers

With Hyper-V, these values can be configured in the machine settings:

[[File:VM_specs.png| 600px]]

===Windows Registry===

The Windows registry is a central database in Microsoft Windows that stores configuration information and settings for the operating system, installed applications and hardware components.

The manufacturers of virtualisation software also store information for their products here. Malware checks whether known keys exist or whether they contain special strings such as "virtual" or the manufacturer's name.

Delete the following Key: '''HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Virtual Machine\Guest\Parameters'''

For this Key, delete the substring "virtual" from the values: '''HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Disk\Enum'''

[[File:registry.png| 600px]]

===Hyper-V EventLogs===

Content in the Windows Hyper-V EventLogs is apparently an indication of a virtual machine.

To delete the log, open the PowerShell as administrator and execute the following command:

<syntaxhighlight lang="cmd">
PS C:\Windows\system32> wevtutil cl "Microsoft-Windows-Kernel-PnP/Configuration"
</syntaxhighlight>

You can check that the logs are empty with:

<syntaxhighlight lang="cmd">
PS C:\Users\VMuser> Get-WinEvent -LogName "Microsoft-Windows-KernelPnP/Configuration"
</syntaxhighlight>

And to disable further logging use:

<syntaxhighlight lang="cmd">
PS C:\Windows\system32> Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\EventLog\Microsoft-Windows-Kernel-PnP\Configuration" -Name "Enabled" -Value 0
</syntaxhighlight>

===Windows Activation===

It is likely that your VM does not have a valid Windows product key. Most users, however, have a valid windows installed in order to use the system properly.

Instead of buying a key, for this purpose a windows activation script can be used. In this guide, [https://github.com/massgravel/Microsoft-Activation-Scripts/ this] one from GitHub is used.

Again, open the PowerShell and enter this command:

<syntaxhighlight lang="cmd">
irm https://get.activated.win | iex
</syntaxhighlight>

The tool is easy to use and afterwards the VM´s Windows should be activated.

[[File:Windows_activation.png|600px]]

===Other Changes===

Some checks can be fended off without really having to change anything on the system.

This includes, for example, how to start the tools. One tool checks whether Windows Explorer is its parent process.

Another check looks at the system uptime, i.e. how long the system has been running. If you do not have the option to manipulate the system time, it is sufficient to let the machine run a little beforehand.

The screen dimensions are also checked, as the VM window can be resized as required. If the dimensions are too small, it is clear that it is a VM, as there are only certain options for physical screens. E.g. a very small screen window or one that is taller than it is wide is very unlikely on a typical end user device.

== Test Run in modified VM ==

After implementing the described hardening measures the number of positive detections drops from '''57''' to '''41'''.

If the mouse is moved and clicked and keyboard inputs are entered during the execution of the tools, the number even drops to '''32'''. This is because of the Reverse-Turing-Tests(RTTs) of the tools. These test focus on detecting human interaction with the system, normally by mouse or keyboard.
These tests can only be countered by simulating human interaction, which is a complex task. In a typical analysis VM there is no human that is actually operating the system. For this example, it is sufficient if you are manually using mouse and keyboard.

A lot of the remaining positive detections could be countered by implementing hooks. With hooks you could interecpt the return values of many system function and instead return fake information that satisfy the checks of the tools.

However, hooking is a complex mechanism that is not covered in this article.

== Conclusion ==

There is a wide range of possible VM detection methods.

The most widespread include simply checking static system information. However, new techniques are on the rise that exploit other vulnerabilities. Monitoring system components and observing human interaction with RTTs are powerful methods and also hard to counter.

Malware researchers must constantly keep up with new detection and evasion methods in order to keep their analysis systems transparent. It is essential that malware can be analysed at runtime in order to keep up with increased cybercrime.

[[Category:Documentation]]

Hyper-V Virtual Machine Hardening

2025-01-20T20:34:40Z

CHoerhan:

Hyper-V Virtual Machine Hardening

2025-01-20T20:33:31Z

CHoerhan: /* Windows Activation */

Hyper-V Virtual Machine Hardening

2025-01-20T20:33:00Z

CHoerhan:

This article shows how a virtual machine(VM) can be modified to evade detection from malware. This process is also called VM hardening. In dynamic malware analysis, researchers use virtual machines to execute malware in a safe and isolated environment in order to monitor and investigate its behavior. This is why malware author started to use Anit-VM techniques to detect if their programs are running inside a virtual environment and subsequently evade the analysis process. In this article a virtual machine is set up and several open-source VM-detection tools are executed to see how the VM can be detected by malware. Afterwards countermeasures are implemented to mitigate the detection rate of the tools.

== Setup ==
Hyper-V is used for the virtualization. This is because it is a Type 1, bare-metal, Hypervisor, which runs directly on the host's hardware to control the hardware and to manage guest operating systems.

The specifications are:

* Host OS: Windows 11
* Hypervisor: Microsoft Hyper-V
* Guest OS (VM OS): Windows 10

Three tools are used for the VM detection. They are all open-source and can be found on GitHub:

* [https://github.com/a0rtega/pafish Pafish (Paranoid Fish)]
* [https://github.com/kernelwernel/VMAware VMAware]
* [https://github.com/ayoubfaouzi/al-khaser Al-Khaser]

===Initial Test Run===

After the virtual machine setup is complete and all the tools have been installed, a first test can be conducted.

In the unmodified, native machine the tools show a number of positive checks, that hint towards a VM.

Number of detections: Pafish 13 + VMAware 13 + Al-Khaser 31 = '''57 positive detections'''

These numbers are likely to vary between different setups and tool versions.

== Hardening Steps ==

This section contains system modifications that aim to lower the number of positive detections.

===Virtual Hardware Specifications===

Common checks aim at the system hardware. If the disk, memory or processor contain strange values, which typically cannot be found on normal machines, the malware might see this as a sign of a VM.

Very low or odd numbers are highly unlikely in a physical machine. Therefore, see that the VM has at least the following requirements:

* 60-80 GB disk size
* 4-8 GB memory size and no odd numbers
* At least 4 processor cores and no odd numbers

With Hyper-V, these values can be configured in the machine settings:

[[File:VM_specs.png| 600px]]

===Windows Registry===

The Windows registry is a central database in Microsoft Windows that stores configuration information and settings for the operating system, installed applications and hardware components.

The manufacturers of virtualisation software also store information for their products here. Malware checks whether known keys exist or whether they contain special strings such as "virtual" or the manufacturer's name.

Delete the following Key: '''HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Virtual Machine\Guest\Parameters'''

For this Key, delete the substring "virtual" from the values: '''HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Disk\Enum'''

[[File:registry.png| 600px]]

===Hyper-V EventLogs===

Content in the Windows Hyper-V EventLogs is apparently an indication of a virtual machine.

To delete the log, open the PowerShell as administrator and execute the following command:

<syntaxhighlight lang="cmd">
PS C:\Windows\system32> wevtutil cl "Microsoft-Windows-Kernel-PnP/Configuration"
</syntaxhighlight>

You can check that the logs are empty with:

<syntaxhighlight lang="cmd">
PS C:\Users\VMuser> Get-WinEvent -LogName "Microsoft-Windows-KernelPnP/Configuration"
</syntaxhighlight>

And to disable further logging use:

<syntaxhighlight lang="cmd">
PS C:\Windows\system32> Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\EventLog\Microsoft-Windows-Kernel-PnP\Configuration" -Name "Enabled" -Value 0
</syntaxhighlight>

===Windows Activation===

It is likely that your VM does not have a valid Windows product key. Most users, however, have a valid windows installed in order to use it properly.

Instead of buying a key, for this purpose a windows activation script can be used. In this guide, [https://github.com/massgravel/Microsoft-Activation-Scripts/ this] one from GitHub is used.

Again, open the PowerShell and enter this command:

<syntaxhighlight lang="cmd">
irm https://get.activated.win | iex
</syntaxhighlight>

The tool is easy to use and afterwards the VM´s Windows should be activated.

[[File:Windows_activation.png|600px]]

===Other Changes===

Some checks can be fended off without really having to change anything on the system.

This includes, for example, how to start the tools. One tool checks whether Windows Explorer is its parent process.

Another check looks at the system uptime, i.e. how long the system has been running. If you do not have the option to manipulate the system time, it is sufficient to let the machine run a little beforehand.

The screen dimensions are also checked, as the VM window can be resized as required. If the dimensions are too small, it is clear that it is a VM, as there are only certain options for physical screens. E.g. a very small screen window or one that is taller than it is wide is very unlikely on a typical end user device.

== Test Run in modified VM ==

After implementing the described hardening measures the number of positive detections drops from '''57''' to '''41'''.

If the mouse is moved and clicked and keyboard inputs are entered during the execution of the tools, the number even drops to '''32'''. This is because of the Reverse-Turing-Tests(RTTs) of the tools. These test focus on detecting human interaction with the system, normally by mouse or keyboard.
These tests can only be countered by simulating human interaction, which is a complex task. In a typical analysis VM there is no human that is actually operating the system. For this example, it is sufficient if you are manually using mouse and keyboard.

A lot of the remaining positive detections could be countered by implementing hooks. With hooks you could interecpt the return values of many system function and instead return fake information that satisfy the checks of the tools.

However, hooking is a complex mechanism that is not covered in this article.

== Conclusion ==

There is a wide range of possible VM detection methods.

The most widespread include simply checking static system information. However, new techniques are on the rise that exploit other vulnerabilities. Monitoring system components and observing human interaction with RTTs are powerful methods and also hard to counter.

Malware researchers must constantly keep up with new detection and evasion methods in order to keep their analysis systems transparent. It is essential that malware can be analysed at runtime in order to keep up with increased cybercrime.

Hyper-V Virtual Machine Hardening

2025-01-20T20:32:45Z

CHoerhan:

This article shows how a virtual machine(VM) can be modified to evade detection from malware. This process is also called VM hardening. In dynamic malware analysis, researchers use virtual machines to execute malware in a safe and isolated environment in order to monitor and investigate its behavior. This is why malware author started to use Anit-VM techniques to detect if their programs are running inside a virtual environment and subsequently evade the analysis process. In this article a virtual machine is set up and several open-source VM-detection tools are executed to see how the VM can be detected by malware. Afterwards countermeasures are implemented to mitigate the detection rate of the tools.

== Setup ==
Hyper-V is used for the virtualization. This is because it is a Type 1, bare-metal, Hypervisor, which runs directly on the host's hardware to control the hardware and to manage guest operating systems.

The specifications are:

* Host OS: Windows 11
* Hypervisor: Microsoft Hyper-V
* Guest OS (VM OS): Windows 10

Three tools are used for the VM detection. They are all open-source and can be found on GitHub:

* [https://github.com/a0rtega/pafish Pafish (Paranoid Fish)]
* [https://github.com/kernelwernel/VMAware VMAware]
* [https://github.com/ayoubfaouzi/al-khaser Al-Khaser]

===Initial Test Run===

After the virtual machine setup is complete and all the tools have been installed, a first test can be conducted.

In the unmodified, native machine the tools show a number of positive checks, that hint towards a VM.

Number of detections: Pafish 13 + VMAware 13 + Al-Khaser 31 = '''57 positive detections'''

These numbers are likely to vary between different setups and tool versions.

== Hardening Steps ==

This section contains system modifications that aim to lower the number of positive detections.

===Virtual Hardware Specifications===

Common checks aim at the system hardware. If the disk, memory or processor contain strange values, which typically cannot be found on normal machines, the malware might see this as a sign of a VM.

Very low or odd numbers are highly unlikely in a physical machine. Therefore, see that the VM has at least the following requirements:

* 60-80 GB disk size
* 4-8 GB memory size and no odd numbers
* At least 4 processor cores and no odd numbers

With Hyper-V, these values can be configured in the machine settings:

[[File:VM_specs.png| 600px]]

===Windows Registry===

The Windows registry is a central database in Microsoft Windows that stores configuration information and settings for the operating system, installed applications and hardware components.

The manufacturers of virtualisation software also store information for their products here. Malware checks whether known keys exist or whether they contain special strings such as "virtual" or the manufacturer's name.

Delete the following Key: '''HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Virtual Machine\Guest\Parameters'''

For this Key, delete the substring "virtual" from the values: '''HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Disk\Enum'''

[[File:registry.png| 600px]]

===Hyper-V EventLogs===

Content in the Windows Hyper-V EventLogs is apparently an indication of a virtual machine.

To delete the log, open the PowerShell as administrator and execute the following command:

<syntaxhighlight lang="cmd">
PS C:\Windows\system32> wevtutil cl "Microsoft-Windows-Kernel-PnP/Configuration"
</syntaxhighlight>

You can check that the logs are empty with:

<syntaxhighlight lang="cmd">
PS C:\Users\VMuser> Get-WinEvent -LogName "Microsoft-Windows-KernelPnP/Configuration"
</syntaxhighlight>

And to disable further logging use:

<syntaxhighlight lang="cmd">
PS C:\Windows\system32> Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\EventLog\Microsoft-Windows-Kernel-PnP\Configuration" -Name "Enabled" -Value 0
</syntaxhighlight>

===Windows Activation===

It is likely that your VM does not have a valid Windows product key. Most users, however, have a valid windows installed in order to use it properly.

Instead of buying a key, for this purpose a windows activation script can be used. In this guide, [https://github.com/massgravel/Microsoft-Activation-Scripts/ this] one from GitHub is used.

Again, open the PowerShell and enter this command:

<syntaxhighlight lang="cmd">
irm https://get.activated.win | iex
</syntaxhighlight>

The tool is easy to use and afterwards the VM´s Windows should be activated.

[[File:Windows_activation.png|600px]]

===Other Changes===

Some checks can be fended off without really having to change anything on the system.

This includes, for example, how to start the tools. One tool checks whether Windows Explorer is its parent process.

Another check looks at the system uptime, i.e. how long the system has been running. If you do not have the option to manipulate the system time, it is sufficient to let the machine run a little beforehand.

The screen dimensions are also checked, as the VM window can be resized as required. If the dimensions are too small, it is clear that it is a VM, as there are only certain options for physical screens. E.g. a very small screen window or one that is taller than it is wide is very unlikely on a typical end user device.

== Test Run in modified VM ==

After implementing the described hardening measures the number of positive detections drops from '''57''' to '''41'''.

If the mouse is moved and clicked and keyboard inputs are entered during the execution of the tools, the number even drops to '''32'''. This is because of the Reverse-Turing-Tests(RTTs) of the tools. These test focus on detecting human interaction with the system, normally by mouse or keyboard.
These tests can only be countered by simulating human interaction, which is a complex task. In a typical analysis VM there is no human that is actually operating the system. For this example, it is sufficient if you are manually using mouse and keyboard.

A lot of the remaining positive detections could be countered by implementing hooks. With hooks you could interecpt the return values of many system function and instead return fake information that satisfy the checks of the tools.

However, hooking is a complex mechanism that is not covered in this article.

== Conclusion ==

There is a wide range of possible VM detection methods.

The most widespread include simply checking static system information. However, new techniques are on the rise that exploit other vulnerabilities. Monitoring system components and observing human interaction with RTTs are powerful methods and also hard to counter.

Malware researchers must constantly keep up with new detection and evasion methods in order to keep their analysis systems transparent. It is essential that malware can be analysed at runtime in order to keep up with increased cybercrime.

Hyper-V Virtual Machine Hardening

2025-01-20T20:31:55Z

CHoerhan: /* Windows Registry */

This article shows how a virtual machine(VM) can be modified to evade detection from malware. This process is also called VM hardening. In dynamic malware analysis, researchers use virtual machines to execute malware in a safe and isolated environment in order to monitor and investigate its behavior. This is why malware author started to use Anit-VM techniques to detect if their programs are running inside a virtual environment and subsequently evade the analysis process. In this article a virtual machine is set up and several open-source VM-detection tools are executed to see how the VM can be detected by malware. Afterwards countermeasures are implemented to mitigate the detection rate of the tools.

== Setup ==
Hyper-V is used for the virtualization. This is because it is a Type 1, bare-metal, Hypervisor, which runs directly on the host's hardware to control the hardware and to manage guest operating systems.

The specifications are:

* Host OS: Windows 11
* Hypervisor: Microsoft Hyper-V
* Guest OS (VM OS): Windows 10

Three tools are used for the VM detection. They are all open-source and can be found on GitHub:

* [https://github.com/a0rtega/pafish Pafish (Paranoid Fish)]
* [https://github.com/kernelwernel/VMAware VMAware]
* [https://github.com/ayoubfaouzi/al-khaser Al-Khaser]

===Initial Test Run===

After the virtual machine setup is complete and all the tools have been installed, a first test can be conducted.

In the unmodified, native machine the tools show a number of positive checks, that hint towards a VM.

Number of detections: Pafish 13 + VMAware 13 + Al-Khaser 31 = '''57 positive detections'''

These numbers are likely to vary between different setups and tool versions.

== Hardening Steps ==

This section contains system modifications that aim to lower the number of positive detections.

===Virtual Hardware Specifications===

Common checks aim at the system hardware. If the disk, memory or processor contain strange values, which typically cannot be found on normal machines, the malware might see this as a sign of a VM.

Very low or odd numbers are highly unlikely in a physical machine. Therefore, see that the VM has at least the following requirements:

* 60-80 GB disk size
* 4-8 GB memory size and no odd numbers
* At least 4 processor cores and no odd numbers

With Hyper-V, these values can be configured in the machine settings:

[[File:VM_specs.png| 600px]]

===Windows Registry===

The Windows registry is a central database in Microsoft Windows that stores configuration information and settings for the operating system, installed applications and hardware components.

The manufacturers of virtualisation software also store information for their products here. Malware checks whether known keys exist or whether they contain special strings such as "virtual" or the manufacturer's name.

Delete the following Key: '''HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Virtual Machine\Guest\Parameters'''

For this Key, delete the substring "virtual" from the values: '''HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Disk\Enum'''

[[File:registry.png| 600px]]

===Hyper-V EventLogs===

Content in the Windows Hyper-V EventLogs is apparently an indication of a virtual machine.

To delete the log, open the PowerShell as administrator and execute the following command:

<syntaxhighlight lang="cmd">
PS C:\Windows\system32> wevtutil cl "Microsoft-Windows-Kernel-PnP/Configuration"
</syntaxhighlight>

You can check that the logs are empty with:

<syntaxhighlight lang="cmd">
PS C:\Users\VMuser> Get-WinEvent -LogName "Microsoft-Windows-KernelPnP/Configuration"
</syntaxhighlight>

And to disable further logging use:

<syntaxhighlight lang="cmd">
PS C:\Windows\system32> Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\EventLog\Microsoft-Windows-Kernel-PnP\Configuration" -Name "Enabled" -Value 0
</syntaxhighlight>

===Windows Activation===

It is likely that your VM does not have a valid Windows product key. Most users, however, have a valid windows installed in order to use it properly.

Instead of buying a key, for this purpose a windows activation script can be used. In this guide, [https://github.com/massgravel/Microsoft-Activation-Scripts/ this] one from GitHub is used.

Again, open the PowerShell and enter this command:

<syntaxhighlight lang="cmd">
irm https://get.activated.win | iex
</syntaxhighlight>

The tool is easy to use and afterwards the VM´s Windows should be activated.

[[File:Windows_activation.png|600px]]

===Other Changes===

Some checks can be fended off without really having to change anything on the system.

This includes, for example, how to start the tools. One tool checks whether Windows Explorer is its parent process.

Another check looks at the system uptime, i.e. how long the system has been running. If you do not have the option to manipulate the system time, it is sufficient to let the machine run a little beforehand.

The screen dimensions are also checked, as the VM window can be resized as required. If the dimensions are too small, it is clear that it is a VM, as there are only certain options for physical screens. E.g. a very small screen window or one that is taller than it is wide is very unlikely on a typical end user device.

== Test Run in modified VM ==

After implementing the described hardening measures the number of positive detections drops from '''57''' to '''41'''.

If the mouse is moved and clicked and keyboard inputs are entered during the execution of the tools, the number even drops to '''32'''. This is because of the Reverse-Turing-Tests(RTTs) of the tools. These test focus on detecting human interaction with the system, normally by mouse or keyboard.
These tests can only be countered by simulating human interaction, which is a complex task. In a typical analysis VM there is no human that is actually operating the system. For this example, it is sufficient if you are manually using mouse and keyboard.

A lot of the remaining positive detections could be countered by implementing hooks. With hooks you could interecpt the return values of many system function and instead return fake information that satisfy the checks of the tools.

However, hooking is a complex mechanism that is not covered in this article.

== Conclusion ==

There is a wide range of possible VM detection methods.

The most widespread include simply checking static system information. However, new techniques are on the rise that exploit other vulnerabilities. Monitoring system components and observing human interaction with RTTs are powerful methods and also hard to counter.

Malware researchers must constantly keep up with new detection and evasion methods in order to keep their analysis systems transparent. It is essential that malware can be analysed at runtime in order to keep up with increased cybercrime.

Hyper-V Virtual Machine Hardening

2025-01-20T20:30:37Z

CHoerhan:

This article shows how a virtual machine(VM) can be modified to evade detection from malware. This process is also called VM hardening. In dynamic malware analysis, researchers use virtual machines to execute malware in a safe and isolated environment in order to monitor and investigate its behavior. This is why malware author started to use Anit-VM techniques to detect if their programs are running inside a virtual environment and subsequently evade the analysis process. In this article a virtual machine is set up and several open-source VM-detection tools are executed to see how the VM can be detected by malware. Afterwards countermeasures are implemented to mitigate the detection rate of the tools.

== Setup ==
Hyper-V is used for the virtualization. This is because it is a Type 1, bare-metal, Hypervisor, which runs directly on the host's hardware to control the hardware and to manage guest operating systems.

The specifications are:

* Host OS: Windows 11
* Hypervisor: Microsoft Hyper-V
* Guest OS (VM OS): Windows 10

Three tools are used for the VM detection. They are all open-source and can be found on GitHub:

* [https://github.com/a0rtega/pafish Pafish (Paranoid Fish)]
* [https://github.com/kernelwernel/VMAware VMAware]
* [https://github.com/ayoubfaouzi/al-khaser Al-Khaser]

===Initial Test Run===

After the virtual machine setup is complete and all the tools have been installed, a first test can be conducted.

In the unmodified, native machine the tools show a number of positive checks, that hint towards a VM.

Number of detections: Pafish 13 + VMAware 13 + Al-Khaser 31 = '''57 positive detections'''

These numbers are likely to vary between different setups and tool versions.

== Hardening Steps ==

This section contains system modifications that aim to lower the number of positive detections.

===Virtual Hardware Specifications===

Common checks aim at the system hardware. If the disk, memory or processor contain strange values, which typically cannot be found on normal machines, the malware might see this as a sign of a VM.

Very low or odd numbers are highly unlikely in a physical machine. Therefore, see that the VM has at least the following requirements:

* 60-80 GB disk size
* 4-8 GB memory size and no odd numbers
* At least 4 processor cores and no odd numbers

With Hyper-V, these values can be configured in the machine settings:

[[File:VM_specs.png| 600px]]

===Windows Registry===

The Windows registry is a central database in Microsoft Windows that stores configuration information and settings for the operating system, installed applications and hardware components.

The manufacturers of virtualisation software also store information for their products here. Malware checks whether known keys exist or whether they contain special strings such as ‘virtual’ or the manufacturer's name.

Delete the following Key: '''HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Virtual Machine\Guest\Parameters'''

From this Key, delete the substring "virtual" from the values: '''HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Disk\Enum'''

[[File:registry.png| 600px]]

===Hyper-V EventLogs===

Content in the Windows Hyper-V EventLogs is apparently an indication of a virtual machine.

To delete the log, open the PowerShell as administrator and execute the following command:

<syntaxhighlight lang="cmd">
PS C:\Windows\system32> wevtutil cl "Microsoft-Windows-Kernel-PnP/Configuration"
</syntaxhighlight>

You can check that the logs are empty with:

<syntaxhighlight lang="cmd">
PS C:\Users\VMuser> Get-WinEvent -LogName "Microsoft-Windows-KernelPnP/Configuration"
</syntaxhighlight>

And to disable further logging use:

<syntaxhighlight lang="cmd">
PS C:\Windows\system32> Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\EventLog\Microsoft-Windows-Kernel-PnP\Configuration" -Name "Enabled" -Value 0
</syntaxhighlight>

===Windows Activation===

It is likely that your VM does not have a valid Windows product key. Most users, however, have a valid windows installed in order to use it properly.

Instead of buying a key, for this purpose a windows activation script can be used. In this guide, [https://github.com/massgravel/Microsoft-Activation-Scripts/ this] one from GitHub is used.

Again, open the PowerShell and enter this command:

<syntaxhighlight lang="cmd">
irm https://get.activated.win | iex
</syntaxhighlight>

The tool is easy to use and afterwards the VM´s Windows should be activated.

[[File:Windows_activation.png|600px]]

===Other Changes===

Some checks can be fended off without really having to change anything on the system.

This includes, for example, how to start the tools. One tool checks whether Windows Explorer is its parent process.

Another check looks at the system uptime, i.e. how long the system has been running. If you do not have the option to manipulate the system time, it is sufficient to let the machine run a little beforehand.

The screen dimensions are also checked, as the VM window can be resized as required. If the dimensions are too small, it is clear that it is a VM, as there are only certain options for physical screens. E.g. a very small screen window or one that is taller than it is wide is very unlikely on a typical end user device.

== Test Run in modified VM ==

After implementing the described hardening measures the number of positive detections drops from '''57''' to '''41'''.

If the mouse is moved and clicked and keyboard inputs are entered during the execution of the tools, the number even drops to '''32'''. This is because of the Reverse-Turing-Tests(RTTs) of the tools. These test focus on detecting human interaction with the system, normally by mouse or keyboard.
These tests can only be countered by simulating human interaction, which is a complex task. In a typical analysis VM there is no human that is actually operating the system. For this example, it is sufficient if you are manually using mouse and keyboard.

A lot of the remaining positive detections could be countered by implementing hooks. With hooks you could interecpt the return values of many system function and instead return fake information that satisfy the checks of the tools.

However, hooking is a complex mechanism that is not covered in this article.

== Conclusion ==

There is a wide range of possible VM detection methods.

The most widespread include simply checking static system information. However, new techniques are on the rise that exploit other vulnerabilities. Monitoring system components and observing human interaction with RTTs are powerful methods and also hard to counter.

Malware researchers must constantly keep up with new detection and evasion methods in order to keep their analysis systems transparent. It is essential that malware can be analysed at runtime in order to keep up with increased cybercrime.

Hyper-V Virtual Machine Hardening

2025-01-20T20:29:11Z

CHoerhan:

This article shows how a virtual machine(VM) can be modified to evade detection from malware. This process is also called VM hardening. In dynamic malware analysis, researchers use virtual machines to execute malware in a safe and isolated environment in order to monitor and investigate its behavior. This is why malware author started to use Anit-VM techniques to detect if their programs are running inside a virtual environment and subsequently evade the analysis process. In this article a virtual machine is set up and several open-source VM-detection tools are executed to see how the VM can be detected by malware. Afterwards countermeasures are implemented to mitigate the detection rate of the tools.

== Setup ==
Hyper-V is used for the virtualization. This is because it is a Type 1, bare-metal, Hypervisor, which runs directly on the host's hardware to control the hardware and to manage guest operating systems.

The specifications are:

* Host OS: Windows 11
* Hypervisor: Microsoft Hyper-V
* Guest OS (VM OS): Windows 10

Three tools are used for the VM detection. They are all open-source and can be found on GitHub:

* [https://github.com/a0rtega/pafish Pafish (Paranoid Fish)]
* [https://github.com/kernelwernel/VMAware VMAware]
* [https://github.com/ayoubfaouzi/al-khaser Al-Khaser]

===Initial Test Run===

After the virtual machine setup is complete and all the tools have been installed, a first test can be conducted.

In the unmodified, native machine the tools show a number of positive checks, that hint towards a VM:

Number of detections: Pafish 13 + VMAware 13 + Al-Khaser 31 = '''57 positive detections'''

These numbers are likely to vary between different setups and tool versions.

== Hardening Steps ==

This section contains system modifications that lower the number of positive detections.

===Virtual Hardware Specifications===

Common checks aim at the system hardware. If the disk, memory or processor contain strange values, which typically cannot be found on normal machines, the malware might see this as a sign of a VM.

Very low or odd numbers are highly unlikely in a physical machine. Therefore, see that the VM has at least the following requirements:

* 60-80 GB disk size
* 4-8 GB memory size and no odd numbers
* At least 4 processor cores and no odd numbers

With Hyper-V, these values can be configured in the machine settings:

[[File:VM_specs.png| 600px]]

===Windows Registry===

The Windows registry is a central database in Microsoft Windows that stores configuration information and settings for the operating system, installed applications and hardware components.

The manufacturers of virtualisation software also store information for their products here. Malware checks whether known keys exist or whether they contain special strings such as ‘virtual’ or the manufacturer's name.

Delete the following Key: '''HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Virtual Machine\Guest\Parameters'''

From this Key, delete the substring "virtual" from the values: '''HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Disk\Enum'''

[[File:registry.png| 600px]]

===Hyper-V EventLogs===

Content in the Windows Hyper-V EventLogs is apparently an indication of a virtual machine.

To delete the log, open the PowerShell as administrator and execute the following command:

<syntaxhighlight lang="cmd">
PS C:\Windows\system32> wevtutil cl "Microsoft-Windows-Kernel-PnP/Configuration"
</syntaxhighlight>

You can check that the logs are empty with:

<syntaxhighlight lang="cmd">
PS C:\Users\VMuser> Get-WinEvent -LogName "Microsoft-Windows-KernelPnP/Configuration"
</syntaxhighlight>

And to disable further logging use:

<syntaxhighlight lang="cmd">
PS C:\Windows\system32> Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\EventLog\Microsoft-Windows-Kernel-PnP\Configuration" -Name "Enabled" -Value 0
</syntaxhighlight>

===Windows Activation===

It is likely that your VM does not have a valid Windows product key. Most users, however, have a valid windows installed in order to use it properly.

Instead of buying a key, for this purpose a windows activation script can be used. In this guide, [https://github.com/massgravel/Microsoft-Activation-Scripts/ this] one from GitHub is used.

Again, open the PowerShell and enter this command:

<syntaxhighlight lang="cmd">
irm https://get.activated.win | iex
</syntaxhighlight>

The tool is easy to use and afterwards the VM´s Windows should be activated.

[[File:Windows_activation.png|600px]]

===Other Changes===

Some checks can be fended off without really having to change anything on the system.

This includes, for example, how to start the tools. One tool checks whether Windows Explorer is its parent process.

Another check looks at the system uptime, i.e. how long the system has been running. If you do not have the option to manipulate the system time, it is sufficient to let the machine run a little beforehand.

The screen dimensions are also checked, as the VM window can be resized as required. If the dimensions are too small, it is clear that it is a VM, as there are only certain options for physical screens. E.g. a very small screen window or one that is taller than it is wide is very unlikely on a typical end user device.

== Test Run in modified VM ==

After implementing the described hardening measures the number of positive detections drops from '''57''' to '''41'''.

If the mouse is moved and clicked and keyboard inputs are entered during the execution of the tools, the number even drops to '''32'''. This is because of the Reverse-Turing-Tests(RTTs) of the tools. These test focus on detecting human interaction with the system, normally by mouse or keyboard.
These tests can only be countered by simulating human interaction, which is a complex task. In a typical analysis VM there is no human that is actually operating the system. For this example, it is sufficient if you are manually using mouse and keyboard.

A lot of the remaining positive detections could be countered by implementing hooks. With hooks you could interecpt the return values of many system function and instead return fake information that satisfy the checks of the tools.

However, hooking is a complex mechanism that is not covered in this article.

== Conclusion ==

There is a wide range of possible VM detection methods.

The most widespread include simply checking static system information. However, new techniques are on the rise that exploit other vulnerabilities. Monitoring system components and observing human interaction with RTTs are powerful methods and also hard to counter.

Malware researchers must constantly keep up with new detection and evasion methods in order to keep their analysis systems transparent. It is essential that malware can be analysed at runtime in order to keep up with increased cybercrime.

Hyper-V Virtual Machine Hardening

2025-01-20T20:28:06Z

CHoerhan:

This article shows how a virtual machine(VM) can be modified to evade detection from malware. This process is also called VM hardening. In dynamic malware analysis, researchers use virtual machines to execute malware in a safe and isolated environment in order to monitor and investigate its behavior. This is why malware author started to use Anit-VM techniques to detect if their programs are running inside a virtual environment and subsequently evade the analysis process. In this article a virtual machine is set up and several open-source VM-detection tools are executed to see how the VM can be detected by malware. Afterwards countermeasures are implemented to mitigate the detection rate of the tools.

== Setup ==
Hyper-V is used for the virtualization. This is because it is a Type 1, bare-metal, Hypervisor, which runs directly on the host's hardware to control the hardware and to manage guest operating systems.

The specifications are:

* Host OS: Windows 11
* Hypervisor: Microsoft Hyper-V
* Guest OS (VM OS): Windows 10

Three tools are used for the VM detection. They are all open-source and can be found on GitHub:

* [https://github.com/a0rtega/pafish Pafish (Paranoid Fish)]
* [https://github.com/kernelwernel/VMAware VMAware]
* [https://github.com/ayoubfaouzi/al-khaser Al-Khaser]

===Initial Test Run===

After the virtual machine setup is complete and all the tools have been installed, a first test can be conducted.

In the unmodified, native machine the tools show a number of positive checks, that hint towards a VM:

Number of detections: Pafish 13 + VMAware 13 + Al-Khaser 31 = '''57 positive detections'''

These numbers are likely to vary between different setups and tool versions.

== Hardening Steps ==

This section contains system modifications that lower the number of positive detections.

===Virtual Hardware Specifications===

Common checks aim at the system hardware. If the disk, memory or processor contain strange values, which typically cannot be found on normal machines, the malware might see this as a sign of a VM.

Very low or odd numbers are highly unlikely in a physical machine. Therefore, see that the VM has at least the following requirements:

* 60-80 GB disk size
* 4-8 GB memory size and no odd numbers
* At least 4 processor cores and no odd numbers

With Hyper-V, these values can be configured in the machine settings:

[[File:VM_specs.png| 600px]]

===Windows Registry===

The Windows registry is a central database in Microsoft Windows that stores configuration information and settings for the operating system, installed applications and hardware components.

The manufacturers of virtualisation software also store information for their products here. Malware checks whether known keys exist or whether they contain special strings such as ‘virtual’ or the manufacturer's name.

Delete the following Key: '''HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Virtual Machine\Guest\Parameters'''

From this Key, delete the substring "virtual" from the values: '''HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Disk\Enum'''

[[File:registry.png| 600px]]

===Hyper-V EventLogs===

Content in the Windows Hyper-V EventLogs is apparently an indication of a virtual machine.

To delete the log, open the PowerShell as administrator and execute the following command:

<syntaxhighlight lang="cmd">
PS C:\Windows\system32> wevtutil cl "Microsoft-Windows-Kernel-PnP/Configuration"
</syntaxhighlight>

You can check that the logs are empty with:

<syntaxhighlight lang="cmd">
PS C:\Users\VMuser> Get-WinEvent -LogName "Microsoft-Windows-KernelPnP/Configuration"
</syntaxhighlight>

And to disable further logging use:

<syntaxhighlight lang="cmd">
PS C:\Windows\system32> Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\EventLog\Microsoft-Windows-Kernel-PnP\Configuration" -Name "Enabled" -Value 0
</syntaxhighlight>

===Windows Activation===

It is likely that your VM does not have a valid Windows product key. Most users, however, have a valid windows installed in order to use it properly.

Instead of buying a key, for this purpose a windows activation script can be used. In this guide, [https://github.com/massgravel/Microsoft-Activation-Scripts/ this] one from GitHub is used.

Again, open the PowerShell and enter this command:

<syntaxhighlight lang="cmd">
irm https://get.activated.win | iex
</syntaxhighlight>

The tool is easy to use and afterwards the VM´s Windows should be activated.

[[File:Windows_activation.png|600px]]

===Other Changes===

Some checks can be fended off without really having to change anything on the system.

This includes, for example, how to start the tools. One tool checks whether Windows Explorer is its parent process.

Another check looks at the system uptime, i.e. how long the system has been running. If you do not have the option to manipulate the system time, it is sufficient to let the machine run a little beforehand.

The screen dimensions are also checked, as the VM window can be resized as required. If the dimensions are too small, it is clear that it is a VM, as there are only certain options for physical screens. E.g. a very small screen window or one that is taller than it is wide is very unlikely on a typical end user device.

== Test Run in modified VM ==

After implementing the described hardening measures the number of positive detections drops from '''57''' to '''41'''.

If the mouse is moved and clicked and keyboard inputs are entered during the execution of the tools, the number even drops to '''32'''. This is because of the Reverse-Turing-Tests(RTTs) of the tools. These test focus on detecting human interaction with the system, normally by mouse or keyboard.
These tests can only be countered by simulating human interaction, which is a complex task. In a typical analysis VM there is no human that is actually operating the system. For this example, it is sufficient if you are manually using mouse and keyboard.

A lot of the remaining positive detections could be countered by implementing hooks. With hooks you could interecpt the return values of many system function and instead return fake information that satisfy the checks of the tools.

However, hooking is a complex mechanism that is not covered in this article.

== Conclusion ==

There is a wide range of possible VM detection methods.

The most widespread include simply checking static system information. However, new techniques are on the rise that exploit other vulnerabilities. Monitoring system components and observing human interaction with RTTs are powerful methods and also hard to counter.

Malware researchers have to constantly keep up with new detection and evasion methods in order to keep their analysis systems tranpartent. It is essential that malware can be analyzed at runtime in order to keep up with increased cybercrime.

Hyper-V Virtual Machine Hardening

2025-01-20T20:27:02Z

CHoerhan:

This article shows how a virtual machine(VM) can be modified to evade detection from malware. This process is also called VM hardening. In dynamic malware analysis, researchers use virtual machines to execute malware in a safe and isolated environment in order to monitor and investigate its behavior. This is why malware author started to use Anit-VM techniques to detect if their programs are running inside a virtual environment and subsequently evade the analysis process. In this article a virtual machine is set up and several open-source VM-detection tools are executed to see how the VM can be detected by malware. Afterwards countermeasures are implemented to mitigate the detection rate of the tools.

== Setup ==
Hyper-V is used for the virtualization. This is because it is a Type 1, bare-metal, Hypervisor, which runs directly on the host's hardware to control the hardware and to manage guest operating systems.

The specifications are:

* Host OS: Windows 11
* Hypervisor: Microsoft Hyper-V
* Guest OS (VM OS): Windows 10

Three tools are used for the VM detection. They are all open-source and can be found on GitHub:

* [https://github.com/a0rtega/pafish Pafish (Paranoid Fish)]
* [https://github.com/kernelwernel/VMAware VMAware]
* [https://github.com/ayoubfaouzi/al-khaser Al-Khaser]

===Initial Test Run===

After the virtual machine setup is complete and all the tools have been installed, a first test can be conducted.

In the unmodified, native machine the tools show a number of positive checks, that hint towards a VM:

Number of detections: Pafish 13 + VMAware 13 + Al-Khaser 31 = '''57 positive detections'''

These numbers are likely to vary between different setups and tool versions.

== Hardening Steps ==

This section contains system modifications that lower the number of positive detections.

===Virtual Hardware Specifications===

Common checks aim at the system hardware. If the disk, memory or processor contain strange values, which typically cannot be found on normal machines, the malware might see this as a sign of a VM.

Very low or odd numbers are highly unlikely in a physical machine. Therefore, see that the VM has at least the following requirements:

* 60-80 GB disk size
* 4-8 GB memory size and no odd numbers
* At least 4 processor cores and no odd numbers

With Hyper-V, these values can be configured in the machine settings:

[[File:VM_specs.png| 600px]]

===Windows Registry===

The Windows registry is a central database in Microsoft Windows that stores configuration information and settings for the operating system, installed applications and hardware components.

The manufacturers of virtualisation software also store information for their products here. Malware checks whether known keys exist or whether they contain special strings such as ‘virtual’ or the manufacturer's name.

Delete the following Key: '''HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Virtual Machine\Guest\Parameters'''

From this Key, delete the substring "virtual" from the values: '''HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Disk\Enum'''

[[File:registry.png| 600px]]

===Hyper-V EventLogs===

Content in the Windows Hyper-V EventLogs is apparently an indication of a virtual machine.

To delete the log, open the PowerShell as administrator and execute the following command:

<syntaxhighlight lang="cmd">
PS C:\Windows\system32> wevtutil cl "Microsoft-Windows-Kernel-PnP/Configuration"
</syntaxhighlight>

You can check that the logs are empty with:

<syntaxhighlight lang="cmd">
PS C:\Users\VMuser> Get-WinEvent -LogName "Microsoft-Windows-KernelPnP/Configuration"
</syntaxhighlight>

And to disable further logging use:

<syntaxhighlight lang="cmd">
PS C:\Windows\system32> Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\EventLog\Microsoft-Windows-Kernel-PnP\Configuration" -Name "Enabled" -Value 0
</syntaxhighlight>

===Windows Activation===

It is likely that your VM does not have a valid Windows product key. Most users, however, have a valid windows installed in order to use it properly.

Instead of buying a key, for this purpose a windows activation script can be used. In this guide, [https://github.com/massgravel/Microsoft-Activation-Scripts/ this] one from GitHub is used.

Again, open the PowerShell and enter this command:

<syntaxhighlight lang="cmd">
irm https://get.activated.win | iex
</syntaxhighlight>

The tool is easy to use and afterwards the VM´s Windows should be activated.

[[File:Windows_activation.png|600px]]

===Other Changes===

Some checks can be fended off without really having to change anything on the system.

This includes, for example, how to start the tools. One tool checks whether Windows Explorer is its parent process.

Another check looks at the system uptime, i.e. how long the system has been running. If you do not have the option to manipulate the system time, it is sufficient to let the machine run a little beforehand.

The screen dimensions are also checked, as the VM window can be resized as required. If the dimensions are too small, it is clear that it is a VM, as there are only certain options for physical screens. E.g. a very small screen window or one that is taller than it is wide is very unlikely on a typical end user device.

== Test Run in modified VM ==

After implementing the descirbed hardening measures the number of positive detections drops from '''57''' to '''41'''.

If the mouse is moved and clicked and keyboard inputs are entered during the execution of the tools, the number even drops to '''32'''. This is because of the Reverse-Turing-Tests(RTTs) of the tools. These test focus on detecting human interaction with the system, normally by mouse or keyboard.
These tests can only be counterd by simulating human interaction, which is a complex task. In a typical analysis VM there is no human that is actually operating the system. For this example, it is suffencient if you are manually using mouse and keyboard.

A lot of the remaining positive detections could be countered by implementing hooks. With hooks you could interecpt the return values of many system function and instead return fake information that satisfy the checks of the tools.

However, hooking is a complex mechanism that is not covered in this article.

== Conclusion ==

There is a wide range of possible VM detection methods.

The most widespread include simply checking static system information. However, new techniques are on the rise that exploit other vulnerabilities. Monitoring system components and observing human interaction with RTTs are powerful methods and also hard to counter.

Malware researchers have to constantly keep up with new detection and evasion methods in order to keep their analysis systems tranpartent. It is essential that malware can be analyzed at runtime in order to keep up with increased cybercrime.

Hyper-V Virtual Machine Hardening

2025-01-20T20:25:44Z

CHoerhan:

This article shows how a virtual machine(VM) can be modified to evade detection from malware. This process is also called VM hardening. In dynamic malware analysis, researchers use virtual machines to execute malware in a safe and isolated environment in order to monitor and investigate its behavior. This is why malware author started to use Anit-VM techniques to detect if their programs are running inside a virtual environment and subsequently evade the analysis process. In this article a virtual machine is set up and several open-source VM-detection tools are executed to see how the VM can be detected by malware. Afterwards countermeasures are implemented to mitigate the detection rate of the tools.

== Setup ==
Hyper-V is used for the virtualization. This is because it is a Type 1, bare-metal, Hypervisor, which runs directly on the host's hardware to control the hardware and to manage guest operating systems.

The specifications are:

* Host OS: Windows 11
* Hypervisor: Microsoft Hyper-V
* Guest OS (VM OS): Windows 10

Three tools are used for the VM detection. They are all open-source and can be found on GitHub:

* [https://github.com/a0rtega/pafish Pafish (Paranoid Fish)]
* [https://github.com/kernelwernel/VMAware VMAware]
* [https://github.com/ayoubfaouzi/al-khaser Al-Khaser]

===Initial Test Run===

After the virtual machine setup is complete and all the tools have been installed, a first test can be conducted.

In the unmodified, native machine the tools show a number of positive checks, that hint towards a VM:

Number of detections: Pafish 13 + VMAware 13 + Al-Khaser 31 = '''57 positive detections'''

These numbers are likely to vary between different setups and tool versions.

== Hardening Steps ==

This section contains system modifications that lower the number of positive detections.

===Virtual Hardware Specifications===

Common checks aim at the system hardware. If the disk, memory or processor contain strange values, which typically cannot be found on normal machines, the malware might see this as a sign of a VM.

Very low or odd numbers are highly unlikely in a physical machine. Therefore, see that the VM has at least the following requirements:

* 60-80 GB disk size
* 4-8 GB memory size and no odd numbers
* At least 4 processor cores and no odd numbers

With Hyper-V, these values can be configured in the machine settings:

[[File:VM_specs.png| 600px]]

===Windows Registry===

The Windows registry is a central database in Microsoft Windows that stores configuration information and settings for the operating system, installed applications and hardware components.

The manufacturers of virtualisation software also store information for their products here. Malware checks whether known keys exist or whether they contain special strings such as ‘virtual’ or the manufacturer's name.

Delete the following Key: '''HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Virtual Machine\Guest\Parameters'''

From this Key, delete the substring "virtual" from the values: '''HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Disk\Enum'''

[[File:registry.png| 600px]]

===Hyper-V EventLogs===

Content in the Windows Hyper-V EventLogs is apparently an indication of a virtual machine.

To delete the log, open the PowerShell as administrator and execute the following command:

<syntaxhighlight lang="cmd">
PS C:\Windows\system32> wevtutil cl "Microsoft-Windows-Kernel-PnP/Configuration"
</syntaxhighlight>

You can check that the logs are empty with:

<syntaxhighlight lang="cmd">
PS C:\Users\VMuser> Get-WinEvent -LogName "Microsoft-Windows-KernelPnP/Configuration"
</syntaxhighlight>

And to disable further logging use:

<syntaxhighlight lang="cmd">
PS C:\Windows\system32> Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\EventLog\Microsoft-Windows-Kernel-PnP\Configuration" -Name "Enabled" -Value 0
</syntaxhighlight>

===Windows Activation===

It is likely that your VM does not have a valid Windows product key. Most users, however, have a valid windows installed in order to use it properly.

Instead of buying a key, for this purpose a windows activation script can be used. In this guide, [https://github.com/massgravel/Microsoft-Activation-Scripts/ this] one from GitHub is used.

Again open the PowerShell and enter this command:

<syntaxhighlight lang="cmd">
irm https://get.activated.win | iex
</syntaxhighlight>

The tool is easy to use and afterwards the VM´s Windows should be activated.

[[File:Windows_activation.png|600px]]

===Other Changes===

Some checks can be fended off without really having to change anything on the system.

This includes, for example, how to start the tools. One tool checks whether Windows Explorer is its parent process.

Another check looks at the system uptime, i.e. how how long the system has been running. If you do not have the option to manipulate the system time, it is sufficient to let the machine run a little beforehand.

The screen dimensions are also checked, as the VM window can be resized as required. If the dimensions are too small, it is clear that it is a VM, as there are only certain options for physical screens. E.g. a very small screen window or one that is taller than it is wide is very unlikely on a typical end user device.

== Test Run in modified VM ==

After implementing the descirbed hardening measures the number of positive detections drops from '''57''' to '''41'''.

If the mouse is moved and clicked and keyboard inputs are entered during the execution of the tools, the number even drops to '''32'''. This is because of the Reverse-Turing-Tests(RTTs) of the tools. These test focus on detecting human interaction with the system, normally by mouse or keyboard.
These tests can only be counterd by simulating human interaction, which is a complex task. In a typical analysis VM there is no human that is actually operating the system. For this example, it is suffencient if you are manually using mouse and keyboard.

A lot of the remaining positive detections could be countered by implementing hooks. With hooks you could interecpt the return values of many system function and instead return fake information that satisfy the checks of the tools.

However, hooking is a complex mechanism that is not covered in this article.

== Conclusion ==

There is a wide range of possible VM detection methods.

The most widespread include simply checking static system information. However, new techniques are on the rise that exploit other vulnerabilities. Monitoring system components and observing human interaction with RTTs are powerful methods and also hard to counter.

Malware researchers have to constantly keep up with new detection and evasion methods in order to keep their analysis systems tranpartent. It is essential that malware can be analyzed at runtime in order to keep up with increased cybercrime.

Hyper-V Virtual Machine Hardening

2025-01-20T20:24:32Z

CHoerhan:

This article shows how a virtual machine(VM) can be modified to evade detection from malware. This process is also called VM hardening. In dynamic malware analysis, researchers use virtual machines to execute malware in a safe and isolated environment in order to monitor and investigate its behavior. This is why malware author started to use Anit-VM techniques to detect if their programs are running inside a virtual environment and subsequently evade the analysis process. In this article a virtual machine is set up and several open-source VM-detection tools are executed to see how the VM can be detected by malware. Afterwards countermeasures are implemented to mitigate the detection rate of the tools.

== Setup ==
Hyper-V is used for the virtualization. This is because it is a Type 1, bare-metal, Hypervisor, which runs directly on the host's hardware to control the hardware and to manage guest operating systems.

The specifications are:

* Host OS: Windows 11
* Hypervisor: Microsoft Hyper-V
* Guest OS (VM OS): Windows 10

Three tools are used for the VM detection. They are all open-source and can be found on GitHub:

* [https://github.com/a0rtega/pafish Pafish (Paranoid Fish)]
* [https://github.com/kernelwernel/VMAware VMAware]
* [https://github.com/ayoubfaouzi/al-khaser Al-Khaser]

===Initial Test Run===

After the virtual machine setup is complete and all the tools have been installed, a first test can be conducted.

In the unmodified, native machine the tools show a number of positive checks, that hint towards a VM:

Number of detections: Pafish 13 + VMAware 13 + Al-Khaser 31 = '''57 positive detections'''

These numbers are likely to vary between different setups and tool versions.

== Hardening Steps ==

This section contains system modifications that lower the number of positive detections.

===Virtual Hardware Specifications===

Common checks aim at the system hardware. If the disk, memory or processor contain strange values, which typically cannot be found on normal machines, the malware might see this as a sign of a VM.

Very low or odd numbers are highly unlikely in a physical machine. Therefore, see that the VM has at least the following requirements:

* 60-80 GB disk size
* 4-8 GB memory size and no odd numbers
* At least 4 processor cores and no odd numbers

With Hyper-V, these values can be configured in the machine settings:

[[File:VM_specs.png| 600px]]

===Windows Registry===

The Windows registry is a central database in Microsoft Windows that stores configuration information and settings for the operating system, installed applications and hardware components.

The manufacturers of virtualisation software also store information for their products here. Malware checks whether known keys exist or whether they contain special strings such as ‘virtual’ or the manufacturer's name.

Delete the following Key: '''HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Virtual Machine\Guest\Parameters'''

From this Key, delete the substring "virtual" from the values: '''HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Disk\Enum'''

[[File:registry.png| 600px]]

===Hyper-V EventLogs===

Content in the Windows Hyper-V EventLogs is apparently an indication of a virtual machine.

To delete the loge, open the PowerShell as administrator and execute the following command:

<syntaxhighlight lang="cmd">
PS C:\Windows\system32> wevtutil cl "Microsoft-Windows-Kernel-PnP/Configuration"
</syntaxhighlight>

You can check that the logs are empty with:

<syntaxhighlight lang="cmd">
PS C:\Users\VMuser> Get-WinEvent -LogName "Microsoft-Windows-KernelPnP/Configuration"
</syntaxhighlight>

And to disable further logging use:

<syntaxhighlight lang="cmd">
PS C:\Windows\system32> Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\EventLog\Microsoft-Windows-Kernel-PnP\Configuration" -Name "Enabled" -Value 0
</syntaxhighlight>

===Windows Activation===

It is likely that your VM does not have a valid Windows product key. Most users, however, have a valid windows installed in order to use it properly.

Instead of buying a key, for this purpose a windows activation script can be used. In this guide, [https://github.com/massgravel/Microsoft-Activation-Scripts/ this] one from GitHub is used.

Again open the PowerShell and enter this command:

<syntaxhighlight lang="cmd">
irm https://get.activated.win | iex
</syntaxhighlight>

The tool is easy to use and afterwards the VM´s Windows should be activated.

[[File:Windows_activation.png|600px]]

===Other Changes===

Some checks can be fended off without really having to change anything on the system.

This includes, for example, how to start the tools. One tool checks whether Windows Explorer is its parent process.

Another check looks at the system uptime, i.e. how how long the system has been running. If you do not have the option to manipulate the system time, it is sufficient to let the machine run a little beforehand.

The screen dimensions are also checked, as the VM window can be resized as required. If the dimensions are too small, it is clear that it is a VM, as there are only certain options for physical screens. E.g. a very small screen window or one that is taller than it is wide is very unlikely on a typical end user device.

== Test Run in modified VM ==

After implementing the descirbed hardening measures the number of positive detections drops from '''57''' to '''41'''.

If the mouse is moved and clicked and keyboard inputs are entered during the execution of the tools, the number even drops to '''32'''. This is because of the Reverse-Turing-Tests(RTTs) of the tools. These test focus on detecting human interaction with the system, normally by mouse or keyboard.
These tests can only be counterd by simulating human interaction, which is a complex task. In a typical analysis VM there is no human that is actually operating the system. For this example, it is suffencient if you are manually using mouse and keyboard.

A lot of the remaining positive detections could be countered by implementing hooks. With hooks you could interecpt the return values of many system function and instead return fake information that satisfy the checks of the tools.

However, hooking is a complex mechanism that is not covered in this article.

== Conclusion ==

There is a wide range of possible VM detection methods.

The most widespread include simply checking static system information. However, new techniques are on the rise that exploit other vulnerabilities. Monitoring system components and observing human interaction with RTTs are powerful methods and also hard to counter.

Malware researchers have to constantly keep up with new detection and evasion methods in order to keep their analysis systems tranpartent. It is essential that malware can be analyzed at runtime in order to keep up with increased cybercrime.

Hyper-V Virtual Machine Hardening

2025-01-20T20:22:58Z

CHoerhan:

This article shows how a virtual machine(VM) can be modified to evade detection from malware. This process is also called VM hardening. In dynamic malware analysis, researchers use virtual machines to execute malware in a safe and isolated environment in order to monitor and investigate its behavior. This is why malware author started to use Anit-VM techniques to detect if their programs are running inside a virtual environment and subsequently evade the analysis process. In this article a virtual machine is set up and several open-source VM-detection tools are executed to see how the VM can be detected by malware. Afterwards countermeasures are implemented to mitigate the detection rate of the tools.

== Setup ==
Hyper-V is used for the virtualization. This is because it is a Type 1, bare-metal, Hypervisor, which runs directly on the host's hardware to control the hardware and to manage guest operating systems.

The specifications are:

* Host OS: Windows 11
* Hypervisor: Microsoft Hyper-V
* Guest OS (VM OS): Windows 10

Three tools are used for the VM detection. They are all open-source and can be found on GitHub:

* [https://github.com/a0rtega/pafish Pafish (Paranoid Fish)]
* [https://github.com/kernelwernel/VMAware VMAware]
* [https://github.com/ayoubfaouzi/al-khaser Al-Khaser]

===Initial Test Run===

After the virtual machine setup is complete and all the tools have been installed, a first test can be conducted.

In the unmodified, native machine the tools show a number of positive checks, that hint towards a VM:

Number of detections: Pafish 13 + VMAware 13 + Al-Khaser 31 = '''57 positive detections'''

These numbers are likely to vary between different setups and tool versions.

== Hardening Steps ==

This section contains some system modifications that lower the number of positive detections.

===Virtual Hardware Specifications===

Common checks aim at the system hardware. If the disk, memory or processor contain strange values, which typcially cannot be found on normal machines, the malware might see this as a sign of a VM.

Very low or odd numbers are highly unlikey in a physical machine. Therefore, see that the VM has at least the following requirements:

* 60-80 GB disk size
* 4-8 GB memory size and no odd numbers
* At least 4 processor cores and no odd numbers

With Hyper-V, these values can be configured in the machine settings:

[[File:VM_specs.png| 600px]]

===Windows Registry===

The Windows registry is a central database in Microsoft Windows that stores configuration information and settings for the operating system, installed applications and hardware components.

The manufacturers of virtualisation software also store information for their products here. Malware checks whether known keys exist or whether they contain special strings such as ‘virtual’ or the manufacturer's name.

Delete the following Key: '''HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Virtual Machine\Guest\Parameters'''

From this Key, delete the substring "virtual" from the values: '''HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Disk\Enum'''

[[File:registry.png| 600px]]

===Hyper-V EventLogs===

Content in the Windows Hyper-V EventLogs is apparently an indication of a virtual machine.

To delete the loge, open the PowerShell as administrator and execute the following command:

<syntaxhighlight lang="cmd">
PS C:\Windows\system32> wevtutil cl "Microsoft-Windows-Kernel-PnP/Configuration"
</syntaxhighlight>

You can check that the logs are empty with:

<syntaxhighlight lang="cmd">
PS C:\Users\VMuser> Get-WinEvent -LogName "Microsoft-Windows-KernelPnP/Configuration"
</syntaxhighlight>

And to disable further logging use:

<syntaxhighlight lang="cmd">
PS C:\Windows\system32> Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\EventLog\Microsoft-Windows-Kernel-PnP\Configuration" -Name "Enabled" -Value 0
</syntaxhighlight>

===Windows Activation===

It is likely that your VM does not have a valid Windows product key. Most users, however, have a valid windows installed in order to use it properly.

Instead of buying a key, for this purpose a windows activation script can be used. In this guide, [https://github.com/massgravel/Microsoft-Activation-Scripts/ this] one from GitHub is used.

Again open the PowerShell and enter this command:

<syntaxhighlight lang="cmd">
irm https://get.activated.win | iex
</syntaxhighlight>

The tool is easy to use and afterwards the VM´s Windows should be activated.

[[File:Windows_activation.png|600px]]

===Other Changes===

Some checks can be fended off without really having to change anything on the system.

This includes, for example, how to start the tools. One tool checks whether Windows Explorer is its parent process.

Another check looks at the system uptime, i.e. how how long the system has been running. If you do not have the option to manipulate the system time, it is sufficient to let the machine run a little beforehand.

The screen dimensions are also checked, as the VM window can be resized as required. If the dimensions are too small, it is clear that it is a VM, as there are only certain options for physical screens. E.g. a very small screen window or one that is taller than it is wide is very unlikely on a typical end user device.

== Test Run in modified VM ==

After implementing the descirbed hardening measures the number of positive detections drops from '''57''' to '''41'''.

If the mouse is moved and clicked and keyboard inputs are entered during the execution of the tools, the number even drops to '''32'''. This is because of the Reverse-Turing-Tests(RTTs) of the tools. These test focus on detecting human interaction with the system, normally by mouse or keyboard.
These tests can only be counterd by simulating human interaction, which is a complex task. In a typical analysis VM there is no human that is actually operating the system. For this example, it is suffencient if you are manually using mouse and keyboard.

A lot of the remaining positive detections could be countered by implementing hooks. With hooks you could interecpt the return values of many system function and instead return fake information that satisfy the checks of the tools.

However, hooking is a complex mechanism that is not covered in this article.

== Conclusion ==

There is a wide range of possible VM detection methods.

The most widespread include simply checking static system information. However, new techniques are on the rise that exploit other vulnerabilities. Monitoring system components and observing human interaction with RTTs are powerful methods and also hard to counter.

Malware researchers have to constantly keep up with new detection and evasion methods in order to keep their analysis systems tranpartent. It is essential that malware can be analyzed at runtime in order to keep up with increased cybercrime.

Hyper-V Virtual Machine Hardening

2025-01-20T20:22:03Z

CHoerhan:

This article shows how a virtual machine(VM) can be modified to evade detection from malware. This process is also called VM hardening. In dynamic malware analysis, researchers use virtual machines to execute malware in a safe and isolated environment in order to monitor and investigate its behavior. This is why malware author started to use Anit-VM techniques to detect if their programs are running inside a virtual environment and subsequently evade the analysis process. In this article a virtual machine is set up and several open-source VM-detection tools are executed to see how the VM can be detected by malware. Afterwards countermeasures are implemented to mitigate the detection rate of the tools.

== Setup ==
Hyper-V is used for the virtualization. This is because it is a Type 1, bare-metal, Hypervisor, which runs directly on the host's hardware to control the hardware and to manage guest operating systems.

The specifications are:

* Host OS: Windows 11
* Hypervisor: Microsoft Hyper-V
* Guest OS (VM OS): Windows 10

Three tools are used for the VM detection. They are all open-source and can be found on GitHub:

* [https://github.com/a0rtega/pafish Pafish (Paranoid Fish)]
* [https://github.com/kernelwernel/VMAware VMAware]
* [https://github.com/ayoubfaouzi/al-khaser Al-Khaser]

===Initial Test Run===

After the virtual machine setup is complete and all the tools have been installed, a first test can be conducted.

In the unmodified, native machine the tools show a number of positive checks, that hint towards a VM:

Pafish 13 + VMAware 13 + Al-Khaser 31 = '''57 positive detections'''

These numbers are likely to vary between different setups and tool versions.

== Hardening Steps ==

This section contains some system modifications that lower the number of positive detections.

===Virtual Hardware Specifications===

Common checks aim at the system hardware. If the disk, memory or processor contain strange values, which typcially cannot be found on normal machines, the malware might see this as a sign of a VM.

Very low or odd numbers are highly unlikey in a physical machine. Therefore, see that the VM has at least the following requirements:

* 60-80 GB disk size
* 4-8 GB memory size and no odd numbers
* At least 4 processor cores and no odd numbers

With Hyper-V, these values can be configured in the machine settings:

[[File:VM_specs.png| 600px]]

===Windows Registry===

The Windows registry is a central database in Microsoft Windows that stores configuration information and settings for the operating system, installed applications and hardware components.

The manufacturers of virtualisation software also store information for their products here. Malware checks whether known keys exist or whether they contain special strings such as ‘virtual’ or the manufacturer's name.

Delete the following Key: '''HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Virtual Machine\Guest\Parameters'''

From this Key, delete the substring "virtual" from the values: '''HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Disk\Enum'''

[[File:registry.png| 600px]]

===Hyper-V EventLogs===

Content in the Windows Hyper-V EventLogs is apparently an indication of a virtual machine.

To delete the loge, open the PowerShell as administrator and execute the following command:

<syntaxhighlight lang="cmd">
PS C:\Windows\system32> wevtutil cl "Microsoft-Windows-Kernel-PnP/Configuration"
</syntaxhighlight>

You can check that the logs are empty with:

<syntaxhighlight lang="cmd">
PS C:\Users\VMuser> Get-WinEvent -LogName "Microsoft-Windows-KernelPnP/Configuration"
</syntaxhighlight>

And to disable further logging use:

<syntaxhighlight lang="cmd">
PS C:\Windows\system32> Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\EventLog\Microsoft-Windows-Kernel-PnP\Configuration" -Name "Enabled" -Value 0
</syntaxhighlight>

===Windows Activation===

It is likely that your VM does not have a valid Windows product key. Most users, however, have a valid windows installed in order to use it properly.

Instead of buying a key, for this purpose a windows activation script can be used. In this guide, [https://github.com/massgravel/Microsoft-Activation-Scripts/ this] one from GitHub is used.

Again open the PowerShell and enter this command:

<syntaxhighlight lang="cmd">
irm https://get.activated.win | iex
</syntaxhighlight>

The tool is easy to use and afterwards the VM´s Windows should be activated.

[[File:Windows_activation.png|600px]]

===Other Changes===

Some checks can be fended off without really having to change anything on the system.

This includes, for example, how to start the tools. One tool checks whether Windows Explorer is its parent process.

Another check looks at the system uptime, i.e. how how long the system has been running. If you do not have the option to manipulate the system time, it is sufficient to let the machine run a little beforehand.

The screen dimensions are also checked, as the VM window can be resized as required. If the dimensions are too small, it is clear that it is a VM, as there are only certain options for physical screens. E.g. a very small screen window or one that is taller than it is wide is very unlikely on a typical end user device.

== Test Run in modified VM ==

After implementing the descirbed hardening measures the number of positive detections drops from '''57''' to '''41'''.

If the mouse is moved and clicked and keyboard inputs are entered during the execution of the tools, the number even drops to '''32'''. This is because of the Reverse-Turing-Tests(RTTs) of the tools. These test focus on detecting human interaction with the system, normally by mouse or keyboard.
These tests can only be counterd by simulating human interaction, which is a complex task. In a typical analysis VM there is no human that is actually operating the system. For this example, it is suffencient if you are manually using mouse and keyboard.

A lot of the remaining positive detections could be countered by implementing hooks. With hooks you could interecpt the return values of many system function and instead return fake information that satisfy the checks of the tools.

However, hooking is a complex mechanism that is not covered in this article.

== Conclusion ==

There is a wide range of possible VM detection methods.

The most widespread include simply checking static system information. However, new techniques are on the rise that exploit other vulnerabilities. Monitoring system components and observing human interaction with RTTs are powerful methods and also hard to counter.

Malware researchers have to constantly keep up with new detection and evasion methods in order to keep their analysis systems tranpartent. It is essential that malware can be analyzed at runtime in order to keep up with increased cybercrime.

Hyper-V Virtual Machine Hardening

2025-01-20T20:21:08Z

CHoerhan:

This article shows how a virtual machine(VM) can be modified to evade detection from malware. This process is also called VM hardening. In dynamic malware analysis, researchers use virtual machines to execute malware in a safe and isolated environment in order to monitor and investigate its behavior. This is why malware author started to use Anit-VM techniques to detect if their programs are running inside a virtual environment and subsequently evade the analysis process. In this article a virtual machine is set up and several open-source VM-detection tools are executed to see how the VM can be detected by malware. Afterwards countermeasures are implemented to mitigate the detection rate of the tools.

== Setup ==
Hyper-V is used for the virtualization. This is because it is a Type 1, bare-metal, Hypervisor, which runs directly on the host's hardware to control the hardware and to manage guest operating systems.

Further specifications are:

* Host OS: Windows 11
* Hypervisor: Microsoft Hyper-V
* Guest OS (VM OS): Windows 10

Three tools are used for the VM detection. They are all open-source and can be found on GitHub:

* [https://github.com/a0rtega/pafish Pafish (Paranoid Fish)]
* [https://github.com/kernelwernel/VMAware VMAware]
* [https://github.com/ayoubfaouzi/al-khaser Al-Khaser]

===Initial Test Run===

After the virtual machine setup is complete and all the tools have been installed, a first test can be conducted.

In the unmodified, native machine the tools show a number of positive checks, that hint towards a VM:

Pafish 13 + VMAware 13 + Al-Khaser 31 = '''57 positive detections'''

These numbers are likely to vary between different setups and tool versions.

== Hardening Steps ==

This section contains some system modifications that lower the number of positive detections.

===Virtual Hardware Specifications===

Common checks aim at the system hardware. If the disk, memory or processor contain strange values, which typcially cannot be found on normal machines, the malware might see this as a sign of a VM.

Very low or odd numbers are highly unlikey in a physical machine. Therefore, see that the VM has at least the following requirements:

* 60-80 GB disk size
* 4-8 GB memory size and no odd numbers
* At least 4 processor cores and no odd numbers

With Hyper-V, these values can be configured in the machine settings:

[[File:VM_specs.png| 600px]]

===Windows Registry===

The Windows registry is a central database in Microsoft Windows that stores configuration information and settings for the operating system, installed applications and hardware components.

The manufacturers of virtualisation software also store information for their products here. Malware checks whether known keys exist or whether they contain special strings such as ‘virtual’ or the manufacturer's name.

Delete the following Key: '''HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Virtual Machine\Guest\Parameters'''

From this Key, delete the substring "virtual" from the values: '''HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Disk\Enum'''

[[File:registry.png| 600px]]

===Hyper-V EventLogs===

Content in the Windows Hyper-V EventLogs is apparently an indication of a virtual machine.

To delete the loge, open the PowerShell as administrator and execute the following command:

<syntaxhighlight lang="cmd">
PS C:\Windows\system32> wevtutil cl "Microsoft-Windows-Kernel-PnP/Configuration"
</syntaxhighlight>

You can check that the logs are empty with:

<syntaxhighlight lang="cmd">
PS C:\Users\VMuser> Get-WinEvent -LogName "Microsoft-Windows-KernelPnP/Configuration"
</syntaxhighlight>

And to disable further logging use:

<syntaxhighlight lang="cmd">
PS C:\Windows\system32> Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\EventLog\Microsoft-Windows-Kernel-PnP\Configuration" -Name "Enabled" -Value 0
</syntaxhighlight>

===Windows Activation===

It is likely that your VM does not have a valid Windows product key. Most users, however, have a valid windows installed in order to use it properly.

Instead of buying a key, for this purpose a windows activation script can be used. In this guide, [https://github.com/massgravel/Microsoft-Activation-Scripts/ this] one from GitHub is used.

Again open the PowerShell and enter this command:

<syntaxhighlight lang="cmd">
irm https://get.activated.win | iex
</syntaxhighlight>

The tool is easy to use and afterwards the VM´s Windows should be activated.

[[File:Windows_activation.png|600px]]

===Other Changes===

Some checks can be fended off without really having to change anything on the system.

This includes, for example, how to start the tools. One tool checks whether Windows Explorer is its parent process.

Another check looks at the system uptime, i.e. how how long the system has been running. If you do not have the option to manipulate the system time, it is sufficient to let the machine run a little beforehand.

The screen dimensions are also checked, as the VM window can be resized as required. If the dimensions are too small, it is clear that it is a VM, as there are only certain options for physical screens. E.g. a very small screen window or one that is taller than it is wide is very unlikely on a typical end user device.

== Test Run in modified VM ==

After implementing the descirbed hardening measures the number of positive detections drops from '''57''' to '''41'''.

If the mouse is moved and clicked and keyboard inputs are entered during the execution of the tools, the number even drops to '''32'''. This is because of the Reverse-Turing-Tests(RTTs) of the tools. These test focus on detecting human interaction with the system, normally by mouse or keyboard.
These tests can only be counterd by simulating human interaction, which is a complex task. In a typical analysis VM there is no human that is actually operating the system. For this example, it is suffencient if you are manually using mouse and keyboard.

A lot of the remaining positive detections could be countered by implementing hooks. With hooks you could interecpt the return values of many system function and instead return fake information that satisfy the checks of the tools.

However, hooking is a complex mechanism that is not covered in this article.

== Conclusion ==

There is a wide range of possible VM detection methods.

The most widespread include simply checking static system information. However, new techniques are on the rise that exploit other vulnerabilities. Monitoring system components and observing human interaction with RTTs are powerful methods and also hard to counter.

Malware researchers have to constantly keep up with new detection and evasion methods in order to keep their analysis systems tranpartent. It is essential that malware can be analyzed at runtime in order to keep up with increased cybercrime.

Hyper-V Virtual Machine Hardening

2025-01-20T16:41:02Z

CHoerhan:

This article shows how a virtual machin(VM) can be modified to evade detection from malware. This process is also called VM hardening. In dynamic malware analysis, researchers use virtual machines to execute malware in a safe and isolated environment in order to monitor and investigate its behavior. This is why malware author started to use Anit-VM techniques to detect if their programs are running inside a virtual environment and subsequently evade the analysis process. In this article a virtual machine is set up and a number of open-source VM-detection tools is executed to see how the VM can be detected by malware. Afterwards countermeasures are implemented to mitigate the detection rate of the tools.

== Setup ==
Hyper-V is used for the virtualization. This is because it is a Type 1, bare-metal, Hypervisor, which runs directly on the host's hardware to control the hardware and to manage guest operating systems.

Further specifications are:

* Host OS: Windows 11
* Hypervisor: Microsoft Hyper-V
* Guest OS (VM OS): Windows 10

Three tools are used for the VM detection. They are all open-source and can be found on GitHub:

* [https://github.com/a0rtega/pafish Pafish (Paranoid Fish)]
* [https://github.com/kernelwernel/VMAware VMAware]
* [https://github.com/ayoubfaouzi/al-khaser Al-Khaser]

===Initial Test Run===

After the virtual machine setup is complete and all the tools have been installed, a first test can be conducted.

In the unmodified, native machine the tools show a number of positive checks, that hint towards a VM:

Pafish 13 + VMAware 13 + Al-Khaser 31 = '''57 positive detections'''

These numbers are likely to vary between different setups and tool versions.

== Hardening Steps ==

This section contains some system modifications that lower the number of positive detections.

===Virtual Hardware Specifications===

Common checks aim at the system hardware. If the disk, memory or processor contain strange values, which typcially cannot be found on normal machines, the malware might see this as a sign of a VM.

Very low or odd numbers are highly unlikey in a physical machine. Therefore, see that the VM has at least the following requirements:

* 60-80 GB disk size
* 4-8 GB memory size and no odd numbers
* At least 4 processor cores and no odd numbers

With Hyper-V, these values can be configured in the machine settings:

[[File:VM_specs.png| 600px]]

===Windows Registry===

The Windows registry is a central database in Microsoft Windows that stores configuration information and settings for the operating system, installed applications and hardware components.

The manufacturers of virtualisation software also store information for their products here. Malware checks whether known keys exist or whether they contain special strings such as ‘virtual’ or the manufacturer's name.

Delete the following Key: '''HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Virtual Machine\Guest\Parameters'''

From this Key, delete the substring "virtual" from the values: '''HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Disk\Enum'''

[[File:registry.png| 600px]]

===Hyper-V EventLogs===

Content in the Windows Hyper-V EventLogs is apparently an indication of a virtual machine.

To delete the loge, open the PowerShell as administrator and execute the following command:

<syntaxhighlight lang="cmd">
PS C:\Windows\system32> wevtutil cl "Microsoft-Windows-Kernel-PnP/Configuration"
</syntaxhighlight>

You can check that the logs are empty with:

<syntaxhighlight lang="cmd">
PS C:\Users\VMuser> Get-WinEvent -LogName "Microsoft-Windows-KernelPnP/Configuration"
</syntaxhighlight>

And to disable further logging use:

<syntaxhighlight lang="cmd">
PS C:\Windows\system32> Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\EventLog\Microsoft-Windows-Kernel-PnP\Configuration" -Name "Enabled" -Value 0
</syntaxhighlight>

===Windows Activation===

It is likely that your VM does not have a valid Windows product key. Most users, however, have a valid windows installed in order to use it properly.

Instead of buying a key, for this purpose a windows activation script can be used. In this guide, [https://github.com/massgravel/Microsoft-Activation-Scripts/ this] one from GitHub is used.

Again open the PowerShell and enter this command:

<syntaxhighlight lang="cmd">
irm https://get.activated.win | iex
</syntaxhighlight>

The tool is easy to use and afterwards the VM´s Windows should be activated.

[[File:Windows_activation.png|600px]]

===Other Changes===

Some checks can be fended off without really having to change anything on the system.

This includes, for example, how to start the tools. One tool checks whether Windows Explorer is its parent process.

Another check looks at the system uptime, i.e. how how long the system has been running. If you do not have the option to manipulate the system time, it is sufficient to let the machine run a little beforehand.

The screen dimensions are also checked, as the VM window can be resized as required. If the dimensions are too small, it is clear that it is a VM, as there are only certain options for physical screens. E.g. a very small screen window or one that is taller than it is wide is very unlikely on a typical end user device.

== Test Run in modified VM ==

After implementing the descirbed hardening measures the number of positive detections drops from '''57''' to '''41'''.

If the mouse is moved and clicked and keyboard inputs are entered during the execution of the tools, the number even drops to '''32'''. This is because of the Reverse-Turing-Tests(RTTs) of the tools. These test focus on detecting human interaction with the system, normally by mouse or keyboard.
These tests can only be counterd by simulating human interaction, which is a complex task. In a typical analysis VM there is no human that is actually operating the system. For this example, it is suffencient if you are manually using mouse and keyboard.

A lot of the remaining positive detections could be countered by implementing hooks. With hooks you could interecpt the return values of many system function and instead return fake information that satisfy the checks of the tools.

However, hooking is a complex mechanism that is not covered in this article.

== Conclusion ==

There is a wide range of possible VM detection methods.

The most widespread include simply checking static system information. However, new techniques are on the rise that exploit other vulnerabilities. Monitoring system components and observing human interaction with RTTs are powerful methods and also hard to counter.

Malware researchers have to constantly keep up with new detection and evasion methods in order to keep their analysis systems tranpartent. It is essential that malware can be analyzed at runtime in order to keep up with increased cybercrime.

Hyper-V Virtual Machine Hardening

2025-01-20T16:34:43Z

CHoerhan:

This article shows how a virtual machin(VM) can be modified to evade detection from malware. This process is also called VM hardening. In dynamic malware analysis, researchers use virtual machines to execute malware in a safe and isolated environment in order to monitor and investigate its behavior. This is why malware author started to use Anit-VM techniques to detect if their programs are running inside a virtual environment and subsequently evade the analysis process. In this article a virtual machine is set up and a number of open-source VM-detection tools is executed to see how the VM can be detected by malware. Afterwards countermeasures are implemented to mitigate the detection rate of the tools.

== Setup ==
Hyper-V is used for the virtualization. This is because it is a Type 1, bare-metal, Hypervisor, which runs directly on the host's hardware to control the hardware and to manage guest operating systems.

Further specifications are:

* Host OS: Windows 11
* Hypervisor: Microsoft Hyper-V
* Guest OS (VM OS): Windows 10

Three tools are used for the VM detection. They are all open-source and can be found on GitHub:

* [https://github.com/a0rtega/pafish Pafish (Paranoid Fish)]
* [https://github.com/kernelwernel/VMAware VMAware]
* [https://github.com/ayoubfaouzi/al-khaser Al-Khaser]

===Initial Test Run===

After the virtual machine setup is complete and all the tools have been installed, a first test can be conducted.

In the unmodified, native machine the tools show a number of positive checks, that hint towards a VM:

Pafish 13 + VMAware 13 + Al-Khaser 31 = '''57 positive detections'''

These numbers are likely to vary between different setups and tool versions.

== Hardening Steps ==

This section contains some system modifications that lower the number of positive detections.

===Virtual Hardware Specifications===

Common checks aim at the system hardware. If the disk, memory or processor contain strange values, which typcially cannot be found on normal machines, the malware might see this as a sign of a VM.

Very low or odd numbers are highly unlikey in a physical machine. Therefore, see that the VM has at least the following requirements:

* 60-80 GB disk size
* 4-8 GB memory size and no odd numbers
* At least 4 processor cores and no odd numbers

With Hyper-V, these values can be configured in the machine settings:

[[File:VM_specs.png| 600px]]

===Windows Registry===

The Windows registry is a central database in Microsoft Windows that stores configuration information and settings for the operating system, installed applications and hardware components.

The manufacturers of virtualisation software also store information for their products here. Malware checks whether known keys exist or whether they contain special strings such as ‘virtual’ or the manufacturer's name.

Delete the following Key: '''HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Virtual Machine\Guest\Parameters'''

From this Key, delete the substring "virtual" from the values: '''HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Disk\Enum'''

[[File:registry.png| 600px]]

===Hyper-V EventLogs===

Content in the Windows Hyper-V EventLogs is apparently an indication of a virtual machine.

To delete the loge, open the PowerShell as administrator and execute the following command:

<syntaxhighlight lang="cmd">
PS C:\Windows\system32> wevtutil cl "Microsoft-Windows-Kernel-PnP/Configuration"
</syntaxhighlight>

You can check that the logs are empty with:

<syntaxhighlight lang="cmd">
PS C:\Users\VMuser> Get-WinEvent -LogName "Microsoft-Windows-KernelPnP/Configuration"
</syntaxhighlight>

And to disable further logging use:

<syntaxhighlight lang="cmd">
PS C:\Windows\system32> Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\EventLog\Microsoft-Windows-Kernel-PnP\Configuration" -Name "Enabled" -Value 0
</syntaxhighlight>

===Windows Activation===

It is likely that your VM does not have a valid Windows product key. Most users, however, have a valid windows installed in order to use it properly.

Instead of buying a key, for this purpose a windows activation script can be used. In this guide, [https://github.com/massgravel/Microsoft-Activation-Scripts/ this] one from GitHub is used.

Again open the PowerShell and enter this command:

<syntaxhighlight lang="cmd">
irm https://get.activated.win | iex
</syntaxhighlight>

The tool is easy to use and afterwards the VM´s Windows should be activated.

[[File:Windows_activation.png|600px]]

===Other Changes===

Some checks can be fended off without really having to change anything on the system.

This includes, for example, how to start the tools. One tool checks whether Windows Explorer is its parent process.

Another check looks at the system uptime, i.e. how how long the system has been running. If you do not have the option to manipulate the system time, it is sufficient to let the machine run a little beforehand.

The screen dimensions are also checked, as the VM window can be resized as required. If the dimensions are too small, it is clear that it is a VM, as there are only certain options for physical screens. E.g. a very small screen window or one that is taller than it is wide is very unlikely on a typical end user device.

== Test Run in modified VM ==

After implementing the descirbed hardening measures the number of positive detections drops from '''57''' to '''41'''.

If the mouse is moved and clicked and keyboard inputs are entered during the execution of the tools, the number even drops to '''32'''. This is because of the Reverse-Turing-Tests(RTTs) of the tools. These test focus on detecting human interaction with the system, normally by mouse or keyboard.
These tests can only be counterd by simulating human interaction, which is a complex task. In a typical analysis VM there is no human that is actually operating the system. For this example, it is suffencient if you are manually using mouse and keyboard.

== Conclusion ==

There is a wide range of possible VM detection methods.

The most widespread include simply checking static system information. However, new techniques are on the rise that exploit other vulnerabilities. Monitoring system components and observing human interaction with RTTs are powerful methods and also hard to counter.

Malware researchers have to constantly keep up with new detection and evasion methods in order to keep their analysis systems tranpartent. It is essential that malware can be analyzed at runtime in order to keep up with increased cybercrime.

Hyper-V Virtual Machine Hardening

2025-01-20T16:33:15Z

CHoerhan:

This article shows how a virtual machin(VM) can be modified to evade detection from malware. This process is also called VM hardening. In dynamic malware analysis, researchers use virtual machines to execute malware in a safe and isolated environment in order to monitor and investigate its behavior. This is why malware author started to use Anit-VM techniques to detect if their programs are running inside a virtual environment and subsequently evade the analysis process. In this article a virtual machine is set up and a number of open-source VM-detection tools is executed to see how the VM can be detected by malware. Afterwards countermeasures are implemented to mitigate the detection rate of the tools.

== Setup ==
Hyper-V is used for the virtualization. This is because it is a Type 1, bare-metal, Hypervisor, which runs directly on the host's hardware to control the hardware and to manage guest operating systems.

Further specifications are:

* Host OS: Windows 11
* Hypervisor: Microsoft Hyper-V
* Guest OS (VM OS): Windows 10

Three tools are used for the VM detection. They are all open-source and can be found on GitHub:

* [https://github.com/a0rtega/pafish Pafish (Paranoid Fish)]
* [https://github.com/kernelwernel/VMAware VMAware]
* [https://github.com/ayoubfaouzi/al-khaser Al-Khaser]

===Initial Test Run===

After the virtual machine setup is complete and all the tools have been installed, a first test can be conducted.

In the unmodified, native machine the tools show a number of positive checks, that hint towards a VM:

Pafish 13 + VMAware 13 + Al-Khaser 31 = '''57 positive detections'''

These numbers are likely to vary between different setups and tool versions.

== Hardening Steps ==

This section contains some system modifications that lower the number of positive detections.

===Virtual Hardware Specifications===

Common checks aim at the system hardware. If the disk, memory or processor contain strange values, which typcially cannot be found on normal machines, the malware might see this as a sign of a VM.

Very low or odd numbers are highly unlikey in a physical machine. Therefore, see that the VM has at least the following requirements:

* 60-80 GB disk size
* 4-8 GB memory size and no odd numbers
* At least 4 processor cores and no odd numbers

With Hyper-V, these values can be configured in the machine settings:

[[File:VM_specs.png| 600px]]

===Windows Registry===

The Windows registry is a central database in Microsoft Windows that stores configuration information and settings for the operating system, installed applications and hardware components.

The manufacturers of virtualisation software also store information for their products here. Malware checks whether known keys exist or whether they contain special strings such as ‘virtual’ or the manufacturer's name.

Delete the following Key: '''HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Virtual Machine\Guest\Parameters'''

From this Key, delete the substring "virtual" from the values: '''HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Disk\Enum'''

[[File:registry.png| 600px]]

===Hyper-V EventLogs===

Content in the Windows Hyper-V EventLogs is apparently an indication of a virtual machine.

To delete the loge, open the PowerShell as administrator and execute the following command:

<syntaxhighlight lang="cmd">
PS C:\Windows\system32> wevtutil cl "Microsoft-Windows-Kernel-PnP/Configuration"
</syntaxhighlight>

You can check that the logs are empty with:

<syntaxhighlight lang="cmd">
PS C:\Users\VMuser> Get-WinEvent -LogName "Microsoft-Windows-KernelPnP/Configuration"
</syntaxhighlight>

And to disable further logging use:

<syntaxhighlight lang="cmd">
PS C:\Windows\system32> Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\EventLog\Microsoft-Windows-Kernel-PnP\Configuration" -Name "Enabled" -Value 0
</syntaxhighlight>

===Windows Activation===

It is likely that your VM does not have a valid Windows product key. Most users, however, have a valid windows installed in order to use it properly.

Instead of buying a key, for this purpose a windows activation script can be used. In this guide, [https://github.com/massgravel/Microsoft-Activation-Scripts/ this] one from GitHub is used.

Again open the PowerShell and enter this command:

<syntaxhighlight lang="cmd">
irm https://get.activated.win | iex
</syntaxhighlight>

The tool is easy to use and afterwards the VM´s Windows should be activated.

[[File:Windows_activation.png|600px]]

===Other Changes===

Some checks can be fended off without really having to change anything on the system.

This includes, for example, how to start the tools. One tool checks whether Windows Explorer is its parent process.

Another check looks at the system uptime, i.e. how how long the system has been running. If you do not have the option to manipulate the system time, it is sufficient to let the machine run a little beforehand.

The screen dimensions are also checked, as the VM window can be resized as required. If the dimensions are too small, it is clear that it is a VM, as there are only certain options for physical screens. E.g. a very small screen window or one that is taller than it is wide is very unlikely on a typical end user device.

== Test Run in modified VM ==

After implementing the descirbed hardening measures the number of positive detections drops from '''57''' to '''41'''.

If the mouse is moved and clicked and keyboard inputs are entered during the execution of the tools, the number even drops to '''32'''. This is because of the Reverse-Turing-Tests(RTTs) of the tools. These test focus on detecting human interaction with the system, normally by mouse or keyboard.
These tests can only be counterd by simulating human interaction, which is a complex task. In a typical analysis VM there is no human that is actually operating the system. For this example, it is suffencient if you are manually using mouse and keyboard.

== Conclusion ==

There is a wide range of possible VM detection methods. The most widespread include simply checking static system information. However, new techniques are on the rise that exploit other vulnerabilities. Monitoring system components and observing human interaction with RTTs are powerful methods and also hard to counter.
Malware researchers have to constantly keep up with new detection and evasion methods in order to keep their analysis systems tranpartent. It is essential that malware can be analyzed at runtime in order to keep up with increased cybercrime.

Hyper-V Virtual Machine Hardening

2025-01-20T16:29:57Z

CHoerhan:

This article shows how a virtual machin(VM) can be modified to evade detection from malware. This process is also called VM hardening. In dynamic malware analysis, researchers use virtual machines to execute malware in a safe and isolated environment in order to monitor and investigate its behavior. This is why malware author started to use Anit-VM techniques to detect if their programs are running inside a virtual environment and subsequently evade the analysis process. In this article a virtual machine is set up and a number of open-source VM-detection tools is executed to see how the VM can be detected by malware. Afterwards countermeasures are implemented to mitigate the detection rate of the tools.

== Setup ==
Hyper-V is used for the virtualization. This is because it is a Type 1, bare-metal, Hypervisor, which runs directly on the host's hardware to control the hardware and to manage guest operating systems.

Further specifications are:

* Host OS: Windows 11
* Hypervisor: Microsoft Hyper-V
* Guest OS (VM OS): Windows 10

Three tools are used for the VM detection. They are all open-source and can be found on GitHub:

* [https://github.com/a0rtega/pafish Pafish (Paranoid Fish)]
* [https://github.com/kernelwernel/VMAware VMAware]
* [https://github.com/ayoubfaouzi/al-khaser Al-Khaser]

===Initial Test Run===

After the virtual machine setup is complete and all the tools have been installed, a first test can be conducted.

In the unmodified, native machine the tools show a number of positive checks, that hint towards a VM:

Pafish 13 + VMAware 13 + Al-Khaser 31 = '''57 positive detections'''

These numbers are likely to vary between different setups and tool versions.

== Hardening Steps ==

This section contains some system modifications that lower the number of positive detections.

===Virtual Hardware Specifications===

Common checks aim at the system hardware. If the disk, memory or processor contain strange values, which typcially cannot be found on normal machines, the malware might see this as a sign of a VM.

Very low or odd numbers are highly unlikey in a physical machine. Therefore, see that the VM has at least the following requirements:

* 60-80 GB disk size
* 4-8 GB memory size and no odd numbers
* At least 4 processor cores and no odd numbers

With Hyper-V, these values can be configured in the machine settings:

[[File:VM_specs.png|600px|center|thumb|VM Hardware Settings]]

===Windows Registry===

The Windows registry is a central database in Microsoft Windows that stores configuration information and settings for the operating system, installed applications and hardware components.

The manufacturers of virtualisation software also store information for their products here. Malware checks whether known keys exist or whether they contain special strings such as ‘virtual’ or the manufacturer's name.

Delete the following Key: '''HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Virtual Machine\Guest\Parameters'''

From this Key, delete the substring "virtual" from the values: '''HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Disk\Enum'''

[[File:registry.png|600px|thumb|center|Windows Activation]]

===Hyper-V EventLogs===

Content in the Windows Hyper-V EventLogs is apparently an indication of a virtual machine.

To delete the loge, open the PowerShell as administrator and execute the following command:

<syntaxhighlight lang="cmd">
PS C:\Windows\system32> wevtutil cl "Microsoft-Windows-Kernel-PnP/Configuration"
</syntaxhighlight>

You can check that the logs are empty with:

<syntaxhighlight lang="cmd">
PS C:\Users\VMuser> Get-WinEvent -LogName "Microsoft-Windows-KernelPnP/Configuration"
</syntaxhighlight>

And to disable further logging use:

<syntaxhighlight lang="cmd">
PS C:\Windows\system32> Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\EventLog\Microsoft-Windows-Kernel-PnP\Configuration" -Name "Enabled" -Value 0
</syntaxhighlight>

===Windows Activation===

It is likely that your VM does not have a valid Windows product key. Most users, however, have a valid windows installed in order to use it properly.

Instead of buying a key, for this purpose a windows activation script can be used. In this guide, [https://github.com/massgravel/Microsoft-Activation-Scripts/ this] one from GitHub is used.

Again open the PowerShell and enter this command:

<syntaxhighlight lang="cmd">
irm https://get.activated.win | iex
</syntaxhighlight>

The tool is easy to use and afterwards the VM´s Windows should be activated.

[[File:Windows_activation.png|600px|thumb|center|Windows Activation]]

===Other Changes===

Some checks can be fended off without really having to change anything on the system.

This includes, for example, how to start the tools. One tool checks whether Windows Explorer is its parent process.

Another check looks at the system uptime, i.e. how how long the system has been running. If you do not have the option to manipulate the system time, it is sufficient to let the machine run a little beforehand.

The screen dimensions are also checked, as the VM window can be resized as required. If the dimensions are too small, it is clear that it is a VM, as there are only certain options for physical screens. E.g. a very small screen window or one that is taller than it is wide is very unlikely on a typical end user device.

== Test Run in modified VM ==

After implementing the descirbed hardening measures the number of positive detections drops from '''57''' to '''41'''.

If the mouse is moved and clicked and keyboard inputs are entered during the execution of the tools, the number even drops to '''32'''. This is because of the Reverse-Turing-Tests(RTTs) of the tools. These test focus on detecting human interaction with the system, normally by mouse or keyboard.
These tests can only be counterd by simulating human interaction, which is a complex task. In a typical analysis VM there is no human that is actually operating the system. For this example, it is suffencient if you are manually using mouse and keyboard.

== Conclusion ==

There is a wide range of possible VM detection methods. The most widespread include simply checking static system information. However, new techniques are on the rise that exploit other vulnerabilities. Monitoring system components and observing human interaction with RTTs are powerful methods and also hard to counter.
Malware researchers have to constantly keep up with new detection and evasion methods in order to keep their analysis systems tranpartent. It is essential that malware can be analyzed at runtime in order to keep up with increased cybercrime.

File:Registry.png

2025-01-20T16:29:12Z

CHoerhan:

File:VM specs.png

2025-01-20T16:27:02Z

CHoerhan:

Hyper-V Virtual Machine Hardening

2025-01-20T16:22:12Z

CHoerhan:

This article shows how a virtual machin(VM) can be modified to evade detection from malware. This process is also called VM hardening. In dynamic malware analysis, researchers use virtual machines to execute malware in a safe and isolated environment in order to monitor and investigate its behavior. This is why malware author started to use Anit-VM techniques to detect if their programs are running inside a virtual environment and subsequently evade the analysis process. In this article a virtual machine is set up and a number of open-source VM-detection tools is executed to see how the VM can be detected by malware. Afterwards countermeasures are implemented to mitigate the detection rate of the tools.

== Setup ==
Hyper-V is used for the virtualization. This is because it is a Type 1, bare-metal, Hypervisor, which runs directly on the host's hardware to control the hardware and to manage guest operating systems.

Further specifications are:

* Host OS: Windows 11
* Hypervisor: Microsoft Hyper-V
* Guest OS (VM OS): Windows 10

Three tools are used for the VM detection. They are all open-source and can be found on GitHub:

* [https://github.com/a0rtega/pafish Pafish (Paranoid Fish)]
* [https://github.com/kernelwernel/VMAware VMAware]
* [https://github.com/ayoubfaouzi/al-khaser Al-Khaser]

===Initial Test Run===

After the virtual machine setup is complete and all the tools have been installed, a first test can be conducted.

In the unmodified, native machine the tools show a number of positive checks, that hint towards a VM:

Pafish 13 + VMAware 13 + Al-Khaser 31 = '''57 positive detections'''

These numbers are likely to vary between different setups and tool versions.

== Hardening Steps ==

This section contains some system modifications that lower the number of positive detections.

===Virtual Hardware Specifications===

Common checks aim at the system hardware. If the disk, memory or processor contain strange values, which typcially cannot be found on normal machines, the malware might see this as a sign of a VM.

Very low or odd numbers are highly unlikey in a physical machine. Therefore, see that the VM has at least the following requirements:

* 60-80 GB disk size
* 4-8 GB memory size and no odd numbers
* At least 4 processor cores and no odd numbers

With Hyper-V, these values can be configured in the machine settings:

===Windows Registry===

The Windows registry is a central database in Microsoft Windows that stores configuration information and settings for the operating system, installed applications and hardware components.

The manufacturers of virtualisation software also store information for their products here. Malware checks whether known keys exist or whether they contain special strings such as ‘virtual’ or the manufacturer's name.

Delete the following Key: '''HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Virtual Machine\Guest\Parameters'''

From this Key, delete the substring "virtual" from the values: '''HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Disk\Enum'''

===Hyper-V EventLogs===

Content in the Windows Hyper-V EventLogs is apparently an indication of a virtual machine.

To delete the loge, open the PowerShell as administrator and execute the following command:

<syntaxhighlight lang="cmd">
PS C:\Windows\system32> wevtutil cl "Microsoft-Windows-Kernel-PnP/Configuration"
</syntaxhighlight>

You can check that the logs are empty with:

<syntaxhighlight lang="cmd">
PS C:\Users\VMuser> Get-WinEvent -LogName "Microsoft-Windows-KernelPnP/Configuration"
</syntaxhighlight>

And to disable further logging use:

<syntaxhighlight lang="cmd">
PS C:\Windows\system32> Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\EventLog\Microsoft-Windows-Kernel-PnP\Configuration" -Name "Enabled" -Value 0
</syntaxhighlight>

===Windows Activation===

It is likely that your VM does not have a valid Windows product key. Most users, however, have a valid windows installed in order to use it properly.

Instead of buying a key, for this purpose a windows activation script can be used. In this guide, [https://github.com/massgravel/Microsoft-Activation-Scripts/ this] one from GitHub is used.

Again open the PowerShell and enter this command:

<syntaxhighlight lang="cmd">
irm https://get.activated.win | iex
</syntaxhighlight>

The tool is easy to use and afterwards the VM´s Windows should be activated.

[[File:Windows_activation.png|600px|left|thumb|Windows Activation]]

===Other Changes===

Some checks can be fended off without really having to change anything on the system.

This includes, for example, how to start the tools. One tool checks whether Windows Explorer is its parent process.

Another check looks at the system uptime, i.e. how how long the system has been running. If you do not have the option to manipulate the system time, it is sufficient to let the machine run a little beforehand.

The screen dimensions are also checked, as the VM window can be resized as required. If the dimensions are too small, it is clear that it is a VM, as there are only certain options for physical screens. E.g. a very small screen window or one that is taller than it is wide is very unlikely on a typical end user device.

== Test Run in modified VM ==

After implementing the descirbed hardening measures the number of positive detections drops from '''57''' to '''41'''.

If the mouse is moved and clicked and keyboard inputs are entered during the execution of the tools, the number even drops to '''32'''. This is because of the Reverse-Turing-Tests(RTTs) of the tools. These test focus on detecting human interaction with the system, normally by mouse or keyboard.
These tests can only be counterd by simulating human interaction, which is a complex task. In a typical analysis VM there is no human that is actually operating the system. For this example, it is suffencient if you are manually using mouse and keyboard.

== Conclusion ==

There is a wide range of possible VM detection methods. The most widespread include simply checking static system information. However, new techniques are on the rise that exploit other vulnerabilities. Monitoring system components and observing human interaction with RTTs are powerful methods and also hard to counter.
Malware researchers have to constantly keep up with new detection and evasion methods in order to keep their analysis systems tranpartent. It is essential that malware can be analyzed at runtime in order to keep up with increased cybercrime.

Hyper-V Virtual Machine Hardening

2025-01-20T16:15:40Z

CHoerhan:

This article shows how a virtual machin(VM) can be modified to evade detection from malware. This process is also called VM hardening. In dynamic malware analysis, researchers use virtual machines to execute malware in a safe and isolated environment in order to monitor and investigate its behavior. This is why malware author started to use Anit-VM techniques to detect if their programs are running inside a virtual environment and subsequently evade the analysis process. In this article a virtual machine is set up and a number of open-source VM-detection tools is executed to see how the VM can be detected by malware. Afterwards countermeasures are implemented to mitigate the detection rate of the tools.

== Setup ==
Hyper-V is used for the virtualization. This is because it is a Type 1, bare-metal, Hypervisor, which runs directly on the host's hardware to control the hardware and to manage guest operating systems.

Further specifications are:

* Host OS: Windows 11
* Hypervisor: Microsoft Hyper-V
* Guest OS (VM OS): Windows 10

Three tools are used for the VM detection. They are all open-source and can be found on GitHub:

* [https://github.com/a0rtega/pafish Pafish (Paranoid Fish)]
* [https://github.com/kernelwernel/VMAware VMAware]
* [https://github.com/ayoubfaouzi/al-khaser Al-Khaser]

===Initial Test Run===

After the virtual machine setup is complete and all the tools have been installed, a first test can be conducted.

In the unmodified, native machine the tools show a number of positive checks, that hint towards a VM:

Pafish 13 + VMAware 13 + Al-Khaser 31 = '''57 positive detections'''

These numbers are likely to vary between different setups and tool versions.

== Hardening Steps ==

This section contains some system modifications that lower the number of positive detections.

===Virtual Hardware Specifications===

Common checks aim at the system hardware. If the disk, memory or processor contain strange values, which typcially cannot be found on normal machines, the malware might see this as a sign of a VM.

Very low or odd numbers are highly unlikey in a physical machine. Therefore, see that the VM has at least the following requirements:

* 60-80 GB disk size
* 4-8 GB memory size and no odd numbers
* At least 4 processor cores and no odd numbers

With Hyper-V, these values can be configured in the machine settings:

===Windows Registry===

The Windows registry is a central database in Microsoft Windows that stores configuration information and settings for the operating system, installed applications and hardware components.

The manufacturers of virtualisation software also store information for their products here. Malware checks whether known keys exist or whether they contain special strings such as ‘virtual’ or the manufacturer's name.

Delete the following Key: '''HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Virtual Machine\Guest\Parameters'''

From this Key, delete the substring "virtual" from the values: '''HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Disk\Enum'''

===Hyper-V EventLogs===

Content in the Windows Hyper-V EventLogs is apparently an indication of a virtual machine.

To delete the loge, open the PowerShell as administrator and execute the following command:

<syntaxhighlight lang="cmd">
PS C:\Windows\system32> wevtutil cl "Microsoft-Windows-Kernel-PnP/Configuration"
</syntaxhighlight>

You can check that the logs are empty with:

<syntaxhighlight lang="cmd">
PS C:\Users\VMuser> Get-WinEvent -LogName "Microsoft-Windows-KernelPnP/Configuration"
</syntaxhighlight>

And to disable further logging use:

<syntaxhighlight lang="cmd">
PS C:\Windows\system32> Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\EventLog\Microsoft-Windows-Kernel-PnP\Configuration" -Name "Enabled" -Value 0
</syntaxhighlight>

===Windows Activation===

It is likely that your VM does not have a valid Windows product key. Most users, however, have a valid windows installed in order to use it properly.

Instead of buying a key, for this purpose a windows activation script can be used. In this guide, [https://github.com/massgravel/Microsoft-Activation-Scripts/ this] one from GitHub is used.

Again open the PowerShell and enter this command:

<syntaxhighlight lang="cmd">
irm https://get.activated.win | iex
</syntaxhighlight>

The tool is easy to use and afterwards the VM´s Windows should be activated.

[[File:Windows_activation.png|600px|left|thumb|Windows Activation]]

===Other Changes===

Some checks can be fended off without really having to change anything on the system.

This includes, for example, how to start the tools. One tool checks whether Windows Explorer is its parent process.

Another check looks at the system uptime, i.e. how how long the system has been running. If you do not have the option to manipulate the system time, it is sufficient to let the machine run a little beforehand.

The screen dimensions are also checked, as the VM window can be resized as required. If the dimensions are too small, it is clear that it is a VM, as there are only certain options for physical screens. E.g. a very small screen window or one that is taller than it is wide is very unlikely on a typical end user device.

== Test Run in modified VM ==

After implementing the descirbed hardening measures the number of positive detections drops from '''57''' to '''41'''.

If the mouse is moved and clicked and keyboard inputs are entered during the execution of the tools, the number even drops to '''32'''. This is because of the Reverse-Turing-Tests of the tools. These test focus on detecting human interaction with the system, normally by mouse or keyboard.
These tests can only be counterd by simulating human interaction, which is a complex task. In a typical analysis VM there is no human that is actually operating the system. For this example, it is suffencient if you are manually using mouse and keyboard.

Hyper-V Virtual Machine Hardening

2025-01-20T16:08:15Z

CHoerhan:

This article shows how a virtual machin(VM) can be modified to evade detection from malware. This process is also called VM hardening. In dynamic malware analysis, researchers use virtual machines to execute malware in a safe and isolated environment in order to monitor and investigate its behavior. This is why malware author started to use Anit-VM techniques to detect if their programs are running inside a virtual environment and subsequently evade the analysis process. In this article a virtual machine is set up and a number of open-source VM-detection tools is executed to see how the VM can be detected by malware. Afterwards countermeasures are implemented to mitigate the detection rate of the tools.

== Setup ==
Hyper-V is used for the virtualization. This is because it is a Type 1, bare-metal, Hypervisor, which runs directly on the host's hardware to control the hardware and to manage guest operating systems.

Further specifications are:

* Host OS: Windows 11
* Hypervisor: Microsoft Hyper-V
* Guest OS (VM OS): Windows 10

Three tools are used for the VM detection. They are all open-source and can be found on GitHub:

* [https://github.com/a0rtega/pafish Pafish (Paranoid Fish)]
* [https://github.com/kernelwernel/VMAware VMAware]
* [https://github.com/ayoubfaouzi/al-khaser Al-Khaser]

===Initial Test Run===

After the virtual machine setup is complete and all the tools have been installed, a first test can be conducted.

In the unmodified, native machine the tools show a number of positive checks, that hint towards a VM:

Pafish 13 + VMAware 13 + Al-Khaser 31 = '''57 positive detections'''

These numbers are likely to vary between different setups and tool versions.

== Hardening Steps ==

This section contains some system modifications that lower the number of positive detections.

===Virtual Hardware Specifications===

Common checks aim at the system hardware. If the disk, memory or processor contain strange values, which typcially cannot be found on normal machines, the malware might see this as a sign of a VM.

Very low or odd numbers are highly unlikey in a physical machine. Therefore, see that the VM has at least the following requirements:

* 60-80 GB disk size
* 4-8 GB memory size and no odd numbers
* At least 4 processor cores and no odd numbers

With Hyper-V, these values can be configured in the machine settings:

===Windows Registry===

The Windows registry is a central database in Microsoft Windows that stores configuration information and settings for the operating system, installed applications and hardware components.

The manufacturers of virtualisation software also store information for their products here. Malware checks whether known keys exist or whether they contain special strings such as ‘virtual’ or the manufacturer's name.

Delete the following Key: '''HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Virtual Machine\Guest\Parameters'''

From this Key, delete the substring "virtual" from the values: '''HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Disk\Enum'''

===Hyper-V EventLogs===

Content in the Windows Hyper-V EventLogs is apparently an indication of a virtual machine.

To delete the loge, open the PowerShell as administrator and execute the following command:

<syntaxhighlight lang="cmd">
PS C:\Windows\system32> wevtutil cl "Microsoft-Windows-Kernel-PnP/Configuration"
</syntaxhighlight>

You can check that the logs are empty with:

<syntaxhighlight lang="cmd">
PS C:\Users\VMuser> Get-WinEvent -LogName "Microsoft-Windows-KernelPnP/Configuration"
</syntaxhighlight>

And to disable further logging use:

<syntaxhighlight lang="cmd">
PS C:\Windows\system32> Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\EventLog\Microsoft-Windows-Kernel-PnP\Configuration" -Name "Enabled" -Value 0
</syntaxhighlight>

===Windows Activation===

It is likely that your VM does not have a valid Windows product key. Most users, however, have a valid windows installed in order to use it properly.

Instead of buying a key, for this purpose a windows activation script can be used. In this guide, [https://github.com/massgravel/Microsoft-Activation-Scripts/ this] one from GitHub is used.

Again open the PowerShell and enter this command:

<syntaxhighlight lang="cmd">
irm https://get.activated.win | iex
</syntaxhighlight>

The tool is easy to use and afterwards the VM´s Windows should be activated.

[[File:Windows_activation.png|600px|left|thumb|Windows Activation]]

===Other Changes===

Some checks can be fended off without really having to change anything on the system.

This includes, for example, how to start the tools. One tool checks whether Windows Explorer is its parent process.

Another check looks at the system uptime, i.e. how how long the system has been running. If you do not have the option to manipulate the system time, it is sufficient to let the machine run a little beforehand.

The screen dimensions are also checked, as the VM window can be resized as required. If the dimensions are too small, it is clear that it is a VM, as there are only certain options for physical screens. E.g. a very small screen window or one that is taller than it is wide is very unlikely on a typical end user device.

File:Windows activation.png

2025-01-20T15:45:00Z

CHoerhan:

Hyper-V Virtual Machine Hardening

2025-01-20T15:35:29Z

CHoerhan:

Hyper-V Virtual Machine Hardening

2025-01-20T15:35:07Z

CHoerhan:

File:VM specifications.png

2025-01-20T15:24:45Z

CHoerhan:

Hyper-V Virtual Machine Hardening

2025-01-20T15:21:32Z

CHoerhan:

Hyper-V Virtual Machine Hardening

2025-01-20T15:02:12Z

CHoerhan:

Hyper-V Virtual Machine Hardening

2025-01-20T15:01:23Z

CHoerhan:

Hyper-V Virtual Machine Hardening

2025-01-20T14:58:12Z

CHoerhan:

Hyper-V Virtual Machine Hardening

2025-01-20T14:55:20Z

CHoerhan:

Hyper-V Virtual Machine Hardening

2025-01-20T14:50:41Z

CHoerhan:

Hyper-V Virtual Machine Hardening

2025-01-20T14:50:32Z

CHoerhan:

Hyper-V Virtual Machine Hardening

2025-01-20T14:49:25Z

CHoerhan:

Hyper-V Virtual Machine Hardening

2025-01-20T14:48:27Z

CHoerhan:

Hyper-V Virtual Machine Hardening

2025-01-20T14:40:44Z

CHoerhan: Created page with "This article == Setup =="

This article

== Setup ==

The Trans2open Vulnerability

2024-12-18T16:46:11Z

CHoerhan:

The trans2open vulnerability, sometimes also referred to as ”trans2 vulnerability”, is a weakness that can be found in Samba versions 2.2.0 to 2.2.8. It was disclosed in 2003, at which time the Samba Port 139 was one of the most attacked ports worldwide. The vulnerability consists in a buffer overflow (BOF) that can be exploited remotely. Basically, this overflow provides an adversary with lots of attacking options. For once, it can be used to execute arbitrary code on the affected system and even open a reverse-shell with root privileges. Another exploitation includes implanting a backdoor. The trans2open vulnerability poses an extreme danger to any system that employs an effected Samba version and should be removed immediately.

Related CVEs include [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0196 CVE-2003-0196], [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2003-0201 CVE-2003-0201] and [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2003-0345 CVE-2003-0345].

== Samba ==

Samba is an open-source, cross-platform software that facilitates file and printer sharing across different operating systems within a network. Primarily, it enables seamless file sharing between Windows and Linux/Unix systems. With Samba, a Linux file server can function within a Windows network, allowing users to access directories and files as if they were on a Windows machine. Initially released in 1992, Samba has grown significantly in popularity over the years. According to its official website, it is recognized as the standard suite of programs for Windows interoperability on Linux and Unix systems.

== SMB ==

Samba implements the Server Message Block (SMB) protocol, which is a network protocol designed for sharing files, printers, and serial ports between nodes on a network. It operates over TCP/IP. Originally developed by IBM in 1983, SMB was later adapted by Microsoft in 1996 into the Common Internet File System (CIFS). While CIFS is sometimes used interchangeably with SMB, it only encompasses the features of SMB 1.0 and is largely outdated today. SMB has evolved over the years, with several versions, including SMB1, SMB2, and SMB3, each introducing improvements in performance, security, and functionality. Modern versions of SMB support interprocess communication and authentication methods such as Kerberos and NTLM (NT LAN Manager). Both Samba and SMB are widely used for communication and resource sharing across various IT systems.

== Exploitation ==

The vulnerability can be exploited in many different ways. However, they all rely on the remote command execution that is enabled through the buffer overflow.

A client-supplied string is copied into a fixed-size buffer. However, this is done without comparing the size of the buffer to the length of the string beforehand. The buffer is allocated on the stack during a function call. Therefore, the overflow can easily overwrite the copy of the instruction pointer that is saved on the stack.

===Metasploit===

The metasploit framework offers modules that target the vulnerability. One module is specifically designed to determine the version of Samba running on a specific port. It can be found in scanner/smb/smb_version.

For exploitation metasploit offers the following modules:

* exploit/freebsd/samba/trans2open
* exploit/linux/samba/trans2open
* exploit/osx/samba/trans2open
* exploit/solaris/samba/trans2open

Most of them open a TCP shell back to the attacker.

A lot of other exploits can be found on the internet. Many of them seem to have roots going back trans2root.pl and sambal.c, which where one of the first exploits.

== Prevention ==

The best defensive action is to remove the vulnerability before it can be exploited. The following nmap command be used to scan for servers running Samba:

<syntaxhighlight lang="cmd">
nmap -sT -p 137,139,445 -O TARGET_IP
</syntaxhighlight>

If a vulnerable Samba version is running on a server, the following countermeasures can be taken:

* Upgrade the software to higher safe version (2.2.9 or 3.X.X). This is the best solution.
* Block external access to TCP port 139 (and 445) from any network firewalls.
* "Misconfigure" Samba so that anonymous access does not work. At lot of exploits rely on this feature. Do this by setting the guest account user to a non-existent name in the smb.conf file.

[[Category:Documentation]]

== References ==

* https://www.giac.org/paper/gcih/484/exploiting-sambas-smbtrans2-vulnerability/105385
* https://www.samba.org/samba/history/samba-2.2.9.html
* https://seclists.org/bugtraq/2003/Apr/103
* https://www.rapid7.com/db/modules/exploit/linux/samba/trans2open/
* https://www.exploit-db.com/exploits/22468
* https://nvd.nist.gov/vuln/detail/CVE-2003-0201
* https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2003-0201

The Trans2open Vulnerability

2024-12-18T15:58:01Z

CHoerhan:

The trans2open vulnerability, sometimes also referred to as ”trans2 vulnerability”, is a weakness that can be found in Samba versions 2.2.0 to 2.2.8. It was disclosed in 2003, at which time the Samba Port 139 was one of the most attacked ports worldwide. The vulnerability consists in a buffer overflow (BOF) that can be exploited remotely. Basically, this overflow provides an adversary with lots of attacking options. For once, it can be used to execute arbitrary code on the affected system and even open a reverse-shell with root privileges. Another exploitation includes implanting a backdoor. The trans2open vulnerability poses an extreme danger to any system that employs an effected Samba version and should be removed immediately.

Related CVEs include [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0196 CVE-2003-0196], [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2003-0201 CVE-2003-0201] and [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2003-0345 CVE-2003-0345].

== Samba ==

Samba is an open-source, cross-platform software that facilitates file and printer sharing across different operating systems within a network. Primarily, it enables seamless file sharing between Windows and Linux/Unix systems. With Samba, a Linux file server can function within a Windows network, allowing users to access directories and files as if they were on a Windows machine. Initially released in 1992, Samba has grown significantly in popularity over the years. According to its official website, it is recognized as the standard suite of programs for Windows interoperability on Linux and Unix systems.

== SMB ==

Samba implements the Server Message Block (SMB) protocol, which is a network protocol designed for sharing files, printers, and serial ports between nodes on a network. It operates over TCP/IP. Originally developed by IBM in 1983, SMB was later adapted by Microsoft in 1996 into the Common Internet File System (CIFS). While CIFS is sometimes used interchangeably with SMB, it only encompasses the features of SMB 1.0 and is largely outdated today. SMB has evolved over the years, with several versions, including SMB1, SMB2, and SMB3, each introducing improvements in performance, security, and functionality. Modern versions of SMB support interprocess communication and authentication methods such as Kerberos and NTLM (NT LAN Manager). Both Samba and SMB are widely used for communication and resource sharing across various IT systems.

== Exploitation ==

The vulnerability can be exploited in many different ways. However, they all rely on the remote command execution that is enabled through the buffer overflow.

A client-supplied string is copied into a fixed-size buffer. However, this is done without comparing the size of the buffer to the length of the string beforehand. The buffer is allocated on the stack during a function call. Therefore, the overflow can easily overwrite the copy of the instruction pointer that is saved on the stack.

===Metasploit===

The metasploit framework offers modules that target the vulnerability. One module is specifically designed to determine the version of Samba running on a specific port. It can be found in scanner/smb/smb_version.

For exploitation metasploit offers the following modules:

* exploit/freebsd/samba/trans2open
* exploit/linux/samba/trans2open
* exploit/osx/samba/trans2open
* exploit/solaris/samba/trans2open

Most of them open a TCP shell back to the attacker.

A lot of other exploits can be found on the internet. Many of them seem to have roots going back trans2root.pl and sambal.c, which where one of the first exploits.

== Prevention ==

The best defensive action is to remove the vulnerability before it can be exploited. The following nmap command be used to scan for servers running Samba:

<syntaxhighlight lang="cmd">
nmap -sT -p 137,139,445 -O TARGET_IP
</syntaxhighlight>

If a vulnerable Samba version is running on a server, the following countermeasures can be taken:

* Upgrade the software to higher safe version (2.2.9 or 3.X.X). This is the best solution.
* Block external access to TCP port 139 (and 445) from any network firewalls.
* "Misconfigure" Samba so that anonymous access does not work. At lot of exploits rely on this feature. Do this by setting the guest account user to a non-existent name in the smb.conf file.

[[Category:Documentation]]

== References ==

* https://www.giac.org/paper/gcih/484/exploiting-sambas-smbtrans2-vulnerability/105385
* https://www.samba.org/samba/history/samba-2.2.9.html
* https://www.rapid7.com/db/modules/exploit/linux/samba/trans2open/
* https://www.exploit-db.com/exploits/22468
* https://nvd.nist.gov/vuln/detail/CVE-2003-0201
* https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2003-0201

VirtualBox: How to set up a Basic Pentesting Lab

2024-12-18T15:57:27Z

CHoerhan:

== Introduction ==

Training penetration testing typically occurs in a dedicated environment known as a pentesting lab, which is isolated from regular user applications and operating systems for security and convenience reasons. A pentesting lab can vary in complexity, with a minimalist setup involving a single computer running multiple virtual machines (VMs), often referred to as a virtual or basic pentesting lab. This variant uses virtualization software like VMware or VirtualBox to create an attacker VM with a specialized OS, such as Kali, Parrot or Arch, and allows for the addition of target machines. These machines are then consolidated in a virtual network. Users can log into the attacker machine to begin testing. More advanced labs may incorporate real hardware, such as real computers, routers, and firewalls, but this increases costs and electricity usage. However, these sophisticated environments enable more realistic scenarios and complex tasks.

This page explains how a basic pentesting lab that can be set up with VirtualBox. This environment will suffice for most people who want to try out or train pentesting and hacking at home. The system will consist of a base machine at performs the actual operations (the attacker machine) and arbitrary target machines, the user can add and remove at will.

The software used in this tutorial:

* Windows 10 or 11 (as the Host OS)
* [https://www.virtualbox.org/wiki/Downloads VirtualBox]
* [https://www.kali.org/get-kali/#kali-virtual-machines Kali Linux]

== Setup Steps ==

===Installation===

Download and install VirutalBox on your Windows machine. There is no need to manually configure anything in this installation process, you can just leave everything at default.

On the Kali Linux download-page, make sure you go to "Pre-built Virtual Machines" and select the VirtualBox option. Using a pre-built image will make the OS setup much easier than with traditional ISO-files. This download might take a while.

===Attacker Setup===

Downloading the Kali pre-built VM will get you a .ZIP-folder. Extract it to a directory of your choice. Inside you should find a .VBOX-file. Double-click it and the VM will be automatically imported to the VirtulBox Manager.

This machine can now be used out-of-the-box. The login credentials are "kali" and "kali". This is OK because, this is just a training environment. The password does not need to be strong or protected.

If the machine automatically boots up when imported, you can shut it down again. Do this by clicking "File" in the top bar of the machine window. Then "Close" and "Power off the machine" -> OK. Alternatively, you can login and shut it down from there normally.

Now you should have the Kali VM in your list, looking something like this:

[[File:VboxKali.png|600px|center|thumb|VirtualBox Kali VM]]

===Network Configuration===

The goal is to create a testing network that is separated from the host OS. The easiest way to do this is by creating a virtual network that only contains the attacker and target machines. This can be achieved by setting up a DHCP-service within VirtualBox, that automatically assigns IP-addresses to the VMs when booted up.

Open the windows command prompt and navigate to the VirtualBox installation directory. By default, this is ''C:\Program Files\Oracle\VirtualBox''. Now use the vboxmanage tool to create the DHCP server:

<syntaxhighlight lang="cmd">
vboxmanage dhcpserver add --network=vnet --server-ip=172.16.0.1 --lower-ip=172.16.0.2 --upper-id=172.16.0.100 --netmask=255.255.255.0 --enable
</syntaxhighlight>

You can also choose other settings for your network, but make sure to use private IP addresses. If you don´t know what values to pick, you can just copy this command.

For every machine you want to add to the pentesting network, go into the settings for the VM and go to Network. Enable one adapter and set it as attached to ''Internal Network''. Below, enter the same name that was used in the vboxmanage-command (''vnet'' in this example).

[[File:Vboxnwconf.png|600px|center|thumb|VirtualBox VM network settings]]

At the end, you can start the machine and verify the network configuration. If the machine has an IP from the defined pool, the DHCP service works correctly.

[[File:Kalinwconf.png|400px|center|thumb|VirtualBox VM network settings]]

===Add Target Machines===

Now your virtual pentesting lab is ready. You can add vulnerable target machines that you can hack from your Kali-Base-VM. A great source for such VMs is [https://www.vulnhub.com/ VulnHub.com]. This site offers a vast collection of virtual machines that are intentionally vulnerably. You can legally hack and break them inside your environment.

However, always make sure to '''add your machine to the testing network''', like we did with the attacker machine.

Once a target is added you can use nmap, fping, ping, netdiscover or some other tool to find it on the network. Now you can start hacking and exploring the machine for weaknesses.

===Optional: Host-to-VM Connection===

With the current network configuration there is no connection between the physical host machine, that is running the VMs, and the attacker machine. Therefore, the attacker also has no internet connection.

This is not necessary for such an environment. But if you want this, you can enable a second adapter in the VM settings and set it to ''NAT''. This way the VM will have host and internet connectivity. But this goes only in one direction, the host or the internet cannot reach the VM.

If you want the connection to go bidirectional, set the adapter to ''Bridged Adapter''.

[[Category:Pentesting]]

== References ==

* https://ieeexplore.ieee.org/document/10108187
* https://ia802202.us.archive.org/9/items/1.-the-pentester-blueprint/1.%20The%20Pentester%20Blueprint.pdf
* https://www.vulnhub.com/

The Trans2open Vulnerability

2024-12-18T15:55:24Z

CHoerhan:

The trans2open vulnerability, sometimes also referred to as ”trans2 vulnerability”, is a weakness that can be found in Samba versions 2.2.0 to 2.2.8. It was disclosed in 2003, at which time the Samba Port 139 was one of the most attacked ports worldwide. The vulnerability consists in a buffer overflow (BOF) that can be exploited remotely. Basically, this overflow provides an adversary with lots of attacking options. For once, it can be used to execute arbitrary code on the affected system and even open a reverse-shell with root privileges. Another exploitation includes implanting a backdoor. The trans2open vulnerability poses an extreme danger to any system that employs an effected Samba version and should be removed immediately.

Related CVEs include [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0196 CVE-2003-0196], [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2003-0201 CVE-2003-0201] and [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2003-0345 CVE-2003-0345].

== Samba ==

Samba is an open-source, cross-platform software that facilitates file and printer sharing across different operating systems within a network. Primarily, it enables seamless file sharing between Windows and Linux/Unix systems. With Samba, a Linux file server can function within a Windows network, allowing users to access directories and files as if they were on a Windows machine. Initially released in 1992, Samba has grown significantly in popularity over the years. According to its official website, it is recognized as the standard suite of programs for Windows interoperability on Linux and Unix systems.

== SMB ==

Samba implements the Server Message Block (SMB) protocol, which is a network protocol designed for sharing files, printers, and serial ports between nodes on a network. It operates over TCP/IP. Originally developed by IBM in 1983, SMB was later adapted by Microsoft in 1996 into the Common Internet File System (CIFS). While CIFS is sometimes used interchangeably with SMB, it only encompasses the features of SMB 1.0 and is largely outdated today. SMB has evolved over the years, with several versions, including SMB1, SMB2, and SMB3, each introducing improvements in performance, security, and functionality. Modern versions of SMB support interprocess communication and authentication methods such as Kerberos and NTLM (NT LAN Manager). Both Samba and SMB are widely used for communication and resource sharing across various IT systems.

== Exploitation ==

The vulnerability can be exploited in many different ways. However, they all rely on the remote command execution that is enabled through the buffer overflow.

A client-supplied string is copied into a fixed-size buffer. However, this is done without comparing the size of the buffer to the length of the string beforehand. The buffer is allocated on the stack during a function call. Therefore, the overflow can easily overwrite the copy of the instruction pointer that is saved on the stack.

===Metasploit===

The metasploit framework offers modules that target the vulnerability. One module is specifically designed to determine the version of Samba running on a specific port. It can be found in scanner/smb/smb_version.

For exploitation metasploit offers the following modules:

* exploit/freebsd/samba/trans2open
* exploit/linux/samba/trans2open
* exploit/osx/samba/trans2open
* exploit/solaris/samba/trans2open

Most of them open a TCP shell back to the attacker.

A lot of other exploits can be found on the internet. Many of them seem to have roots going back trans2root.pl and sambal.c, which where one of the first exploits.

== Prevention ==

The best defensive action is to remove the vulnerability before it can be exploited. The following nmap command be used to scan for servers running Samba:

<syntaxhighlight lang="cmd">
nmap -sT -p 137,139,445 -O TARGET_IP
</syntaxhighlight>

If a vulnerable Samba version is running on a server, the following countermeasures can be taken:

* Upgrade the software to higher safe version (2.2.9 or 3.X.X). This is the best solution.
* Block external access to TCP port 139 (and 445) from any network firewalls.
* "Misconfigure" Samba so that anonymous access does not work. At lot of exploits rely on this feature. Do this by setting the guest account user to a non-existent name in the smb.conf file.

== References ==

* https://www.giac.org/paper/gcih/484/exploiting-sambas-smbtrans2-vulnerability/105385
* https://www.samba.org/samba/history/samba-2.2.9.html
* https://www.rapid7.com/db/modules/exploit/linux/samba/trans2open/
* https://www.exploit-db.com/exploits/22468
* https://nvd.nist.gov/vuln/detail/CVE-2003-0201
* https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2003-0201

VirtualBox: How to set up a Basic Pentesting Lab

2024-12-18T15:43:33Z

CHoerhan:

== Introduction ==

Training penetration testing typically occurs in a dedicated environment known as a pentesting lab, which is isolated from regular user applications and operating systems for security and convenience reasons. A pentesting lab can vary in complexity, with a minimalist setup involving a single computer running multiple virtual machines (VMs), often referred to as a virtual or basic pentesting lab. This variant uses virtualization software like VMware or VirtualBox to create an attacker VM with a specialized OS, such as Kali, Parrot or Arch, and allows for the addition of target machines. These machines are then consolidated in a virtual network. Users can log into the attacker machine to begin testing. More advanced labs may incorporate real hardware, such as real computers, routers, and firewalls, but this increases costs and electricity usage. However, these sophisticated environments enable more realistic scenarios and complex tasks.

This page explains how a basic pentesting lab that can be set up with VirtualBox. This environment will suffice for most people who want to try out or train pentesting and hacking at home. The system will consist of a base machine at performs the actual operations (the attacker machine) and arbitrary target machines, the user can add and remove at will.

The software used in this tutorial:

* Windows 10 or 11 (as the Host OS)
* [https://www.virtualbox.org/wiki/Downloads VirtualBox]
* [https://www.kali.org/get-kali/#kali-virtual-machines Kali Linux]

== Setup Steps ==

===Installation===

Download and install VirutalBox on your Windows machine. There is no need to manually configure anything in this installation process, you can just leave everything at default.

On the Kali Linux download-page, make sure you go to "Pre-built Virtual Machines" and select the VirtualBox option. Using a pre-built image will make the OS setup much easier than with traditional ISO-files. This download might take a while.

===Attacker Setup===

Downloading the Kali pre-built VM will get you a .ZIP-folder. Extract it to a directory of your choice. Inside you should find a .VBOX-file. Double-click it and the VM will be automatically imported to the VirtulBox Manager.

This machine can now be used out-of-the-box. The login credentials are "kali" and "kali". This is OK because, this is just a training environment. The password does not need to be strong or protected.

If the machine automatically boots up when imported, you can shut it down again. Do this by clicking "File" in the top bar of the machine window. Then "Close" and "Power off the machine" -> OK. Alternatively, you can login and shut it down from there normally.

Now you should have the Kali VM in your list, looking something like this:

[[File:VboxKali.png|600px|center|thumb|VirtualBox Kali VM]]

===Network Configuration===

The goal is to create a testing network that is separated from the host OS. The easiest way to do this is by creating a virtual network that only contains the attacker and target machines. This can be achieved by setting up a DHCP-service within VirtualBox, that automatically assigns IP-addresses to the VMs when booted up.

Open the windows command prompt and navigate to the VirtualBox installation directory. By default, this is ''C:\Program Files\Oracle\VirtualBox''. Now use the vboxmanage tool to create the DHCP server:

<syntaxhighlight lang="cmd">
vboxmanage dhcpserver add --network=vnet --server-ip=172.16.0.1 --lower-ip=172.16.0.2 --upper-id=172.16.0.100 --netmask=255.255.255.0 --enable
</syntaxhighlight>

You can also choose other settings for your network, but make sure to use private IP addresses. If you don´t know what values to pick, you can just copy this command.

For every machine you want to add to the pentesting network, go into the settings for the VM and go to Network. Enable one adapter and set it as attached to ''Internal Network''. Below, enter the same name that was used in the vboxmanage-command (''vnet'' in this example).

[[File:Vboxnwconf.png|600px|center|thumb|VirtualBox VM network settings]]

At the end, you can start the machine and verify the network configuration. If the machine has an IP from the defined pool, the DHCP service works correctly.

[[File:Kalinwconf.png|400px|center|thumb|VirtualBox VM network settings]]

===Add Target Machines===

Now your virtual pentesting lab is ready. You can add vulnerable target machines that you can hack from your Kali-Base-VM. A great source for such VMs is [https://www.vulnhub.com/ VulnHub.com]. This site offers a vast collection of virtual machines that are intentionally vulnerably. You can legally hack and break them inside your environment.

However, always make sure to '''add your machine to the testing network''', like we did with the attacker machine.

Once a target is added you can use nmap, fping, ping, netdiscover or some other tool to find it on the network. Now you can start hacking and exploring the machine for weaknesses.

===Optional: Host-to-VM Connection===

With the current network configuration there is no connection between the physical host machine, that is running the VMs, and the attacker machine. Therefore, the attacker also has no internet connection.

This is not necessary for such an environment. But if you want this, you can enable a second adapter in the VM settings and set it to ''NAT''. This way the VM will have host and internet connectivity. But this goes only in one direction, the host or the internet cannot reach the VM.

If you want the connection to go bidirectional, set the adapter to ''Bridged Adapter''.

== References ==

* https://ieeexplore.ieee.org/document/10108187
* https://ia802202.us.archive.org/9/items/1.-the-pentester-blueprint/1.%20The%20Pentester%20Blueprint.pdf
* https://www.vulnhub.com/

VirtualBox: How to set up a Basic Pentesting Lab

2024-12-18T15:37:48Z

CHoerhan:

== Introduction ==

Training penetration testing typically occurs in a dedicated environment known as a pentesting lab, which is isolated from regular user applications and operating systems for security and convenience reasons. A pentesting lab can vary in complexity, with a minimalist setup involving a single computer running multiple virtual machines (VMs), often referred to as a virtual or basic pentesting lab. This variant uses virtualization software like VMware or VirtualBox to create an attacker VM with a specialized OS, such as Kali, Parrot or Arch, and allows for the addition of target machines. These machines are then consolidated in a virtual network. Users can log into the attacker machine to begin testing. More advanced labs may incorporate real hardware, such as real computers, routers, and firewalls, but this increases costs and electricity usage. However, these sophisticated environments enable more realistic scenarios and complex tasks.

This page explains how a basic pentesting lab that can be set up with VirtualBox. This environment will suffice for most people who want to try out or train pentesting and hacking at home. The system will consist of a base machine at performs the actual operations (the attacker machine) and arbitrary target machines, the user can add and remove at will.

The software used in this tutorial:

* Windows 10 or 11 (as the Host OS)
* [https://www.virtualbox.org/wiki/Downloads VirtualBox]
* [https://www.kali.org/get-kali/#kali-virtual-machines Kali Linux]

== Setup Steps ==

===Installation===

Download and install VirutalBox on your Windows machine. There is no need to manually configure anything in this installation process, you can just leave everything at default.

On the Kali Linux download-page, make sure you go to "Pre-built Virtual Machines" and select the VirtualBox option. Using a pre-built image will make the OS setup much easier than with traditional ISO-files. This download might take a while.

===Attacker Setup===

Downloading the Kali pre-built VM will get you a .ZIP-folder. Extract it to a directory of your choice. Inside you should find a .VBOX-file. Double-click it and the VM will be automatically imported to the VirtulBox Manager.

This machine can now be used out-of-the-box. The login credentials are "kali" and "kali". This is OK because, this is just a training environment. The password does not need to be strong or protected.

If the machine automatically boots up when imported, you can shut it down again. Do this by clicking "File" in the top bar of the machine window. Then "Close" and "Power off the machine" -> OK. Alternatively, you can login and shut it down from there normally.

Now you should have the Kali VM in your list, looking something like this:

[[File:VboxKali.png|600px|center|thumb|VirtualBox Kali VM]]

===Network Configuration===

The goal is to create a testing network that is separated from the host OS. The easiest way to do this is by creating a virtual network that only contains the attacker and target machines. This can be achieved by setting up a DHCP-service within VirtualBox, that automatically assigns IP-addresses to the VMs when booted up.

Open the windows command prompt and navigate to the VirtualBox installation directory. By default this is ''C:\Program Files\Oracle\VirtualBox''. Now use the vboxmanage tool to create the DHCP server:

<syntaxhighlight lang="cmd">
vboxmanage dhcpserver add --network=vnet --server-ip=172.16.0.1 --lower-ip=172.16.0.2 --upper-id=172.16.0.100 --netmask=255.255.255.0 --enable
</syntaxhighlight>

You can also choose other settings for you network, but make sure to use private IP addresses. If you don´t know what values to pick, you can just copy this command.

For every machine you want to add to the pentesting network, go into the settings for the VM and go to Network. Enable one adapter and set it as attachted to ''Internal Network''. Below, enter the same name that was used in the vboxmanage-command (''vnet'' in this example).

[[File:Vboxnwconf.png|600px|center|thumb|VirtualBox VM network settings]]

At the end, you can start the machine and verify the network configuration. If the machine has an IP from the defined pool, the DHCP service works correctly.

[[File:Kalinwconf.png|400px|center|thumb|VirtualBox VM network settings]]

===Add Target Machines===

Now your virtual pentesting lab is ready. You can add vulnerable target machines that you can hack from your Kali-Base-VM. A great source for such VMs is [https://www.vulnhub.com/ VulnHub.com]. This site offers a vast catalog of virtual machines that are intentionally vulnerably. You can legally hack and break them inside your environment.

However, always make sure to '''add your machine to the testing network''', like we did with that attacker machine.

Once a target is added you can use nmap, fping, ping, netdiscover or some other tool to find it on the network. Now you can start hacking and exploring the machine for weaknesses.

===Optional: Host-to-VM Connection===

With the current network configuration there is no connection between the physical host machine, that is running the VMs, and the attacker machine. Therefore the attacker also has no internet connection.

This is not necessary for such an environment. But if you want this, you can enable a second adapter in the VM settings and set it to ''NAT''. This way the VM will have host and internet connectivity. But this goes only in one direction, the host or the internet cannot reach the VM.

If you want the connection to go bidirectional, set the adapter to ''Birdged Adapter''.

== References ==

* https://ieeexplore.ieee.org/document/10108187
* https://ia802202.us.archive.org/9/items/1.-the-pentester-blueprint/1.%20The%20Pentester%20Blueprint.pdf
* https://www.vulnhub.com/

VirtualBox: How to set up a Basic Pentesting Lab

2024-12-18T15:36:51Z

CHoerhan:

== Introduction ==

Training penetration testing typically occurs in a dedicated environment known as a pentesting lab, which is isolated from regular user applications and operating systems for security and convenience reasons. A pentesting lab can vary in complexity, with a minimalist setup involving a single computer running multiple virtual machines (VMs), often referred to as a virtual or basic pentesting lab. This variant uses virtualization software like VMware or VirtualBox to create an attacker VM with a specialized OS, such as Kali, Parrot or Arch, and allows for the addition of target machines. These machines are then consolidated in a virtual network. Users can log into the attacker machine to begin testing. More advanced labs may incorporate real hardware, such as real computers, routers, and firewalls, but this increases costs and electricity usage. However, these sophisticated environments enable more realistic scenarios and complex tasks.

This page explains how a basic pentesting lab that can be set up with VirtualBox. This environment will suffice for most people who want to try out or train pentesting and hacking at home. The system will consist of a base machine at performs the actual operations (the attacker machine) and arbitrary target machines, the user can add and remove at will.

The software used in this tutorial:

* Windows 10 or 11 (as the Host OS)
* [https://www.virtualbox.org/wiki/Downloads VirtualBox]
* [https://www.kali.org/get-kali/#kali-virtual-machines Kali Linux]

== Setup Steps ==

===Installation===

Download and install VirutalBox on your Windows machine. There is no need to manually configure anything in this installation process, you can just leave everything at default.

On the Kali Linux download-page, make sure you go to "Pre-built Virtual Machines" and select the VirtualBox option. Using a pre-built image will make the OS setup much easier than with traditional ISO-files. This download might take a while.

===Attacker Setup===

Downloading the Kali pre-built VM will get you a .ZIP-folder. Extract it to a directory of your choice. Inside you should find a .VBOX-file. Double-click it and the VM will be automatically imported to the VirtulBox Manager.

This machine can now be used out-of-the-box. The login credentials are "kali" and "kali". This is OK because, this is just a training environment. The password does not need to be strong or protected.

If the machine automatically boots up when imported, you can shut it down again. Do this by click "File" in the top bar of the machine windows. Then "Close" and "Power off the machine" -> OK. Alternatively, you can login and shut it down from there normally.

Now you should have the Kali VM in your list, looking something like this:

[[File:VboxKali.png|600px|center|thumb|VirtualBox Kali VM]]

===Network Configuration===

The goal is to create a testing network that is separated from the host OS. The easiest way to do this is by creating a virtual network that only contains the attacker and target machines. This can be achieved by setting up a DHCP-service within VirtualBox, that automatically assigns IP-addresses to the VMs when booted up.

Open the windows command prompt and navigate to the VirtualBox installation directory. By default this is ''C:\Program Files\Oracle\VirtualBox''. Now use the vboxmanage tool to create the DHCP server:

<syntaxhighlight lang="cmd">
vboxmanage dhcpserver add --network=vnet --server-ip=172.16.0.1 --lower-ip=172.16.0.2 --upper-id=172.16.0.100 --netmask=255.255.255.0 --enable
</syntaxhighlight>

You can also choose other settings for you network, but make sure to use private IP addresses. If you don´t know what values to pick, you can just copy this command.

For every machine you want to add to the pentesting network, go into the settings for the VM and go to Network. Enable one adapter and set it as attachted to ''Internal Network''. Below, enter the same name that was used in the vboxmanage-command (''vnet'' in this example).

[[File:Vboxnwconf.png|600px|center|thumb|VirtualBox VM network settings]]

At the end, you can start the machine and verify the network configuration. If the machine has an IP from the defined pool, the DHCP service works correctly.

[[File:Kalinwconf.png|400px|center|thumb|VirtualBox VM network settings]]

===Add Target Machines===

Now your virtual pentesting lab is ready. You can add vulnerable target machines that you can hack from your Kali-Base-VM. A great source for such VMs is [https://www.vulnhub.com/ VulnHub.com]. This site offers a vast catalog of virtual machines that are intentionally vulnerably. You can legally hack and break them inside your environment.

However, always make sure to '''add your machine to the testing network''', like we did with that attacker machine.

Once a target is added you can use nmap, fping, ping, netdiscover or some other tool to find it on the network. Now you can start hacking and exploring the machine for weaknesses.

===Optional: Host-to-VM Connection===

With the current network configuration there is no connection between the physical host machine, that is running the VMs, and the attacker machine. Therefore the attacker also has no internet connection.

This is not necessary for such an environment. But if you want this, you can enable a second adapter in the VM settings and set it to ''NAT''. This way the VM will have host and internet connectivity. But this goes only in one direction, the host or the internet cannot reach the VM.

If you want the connection to go bidirectional, set the adapter to ''Birdged Adapter''.

== References ==

* https://ieeexplore.ieee.org/document/10108187
* https://ia802202.us.archive.org/9/items/1.-the-pentester-blueprint/1.%20The%20Pentester%20Blueprint.pdf
* https://www.vulnhub.com/

VirtualBox: How to set up a Basic Pentesting Lab

2024-12-18T15:34:50Z

CHoerhan:

== Introduction ==

Training penetration testing typically occurs in a dedicated environment known as a pentesting lab, which is isolated from regular user applications and operating systems for security and convenience reasons. A pentesting lab can vary in complexity, with a minimalist setup involving a single computer running multiple virtual machines (VMs), often referred to as a virtual or basic pentesting lab. This variant uses virtualization software like VMware or VirtualBox to create an attacker VM with a specialized OS, such as Kali, Parrot or Arch, and allows for the addition of target machines. These machines are then consolidated in a virtual network. Users can log into the attacker machine to begin testing. More advanced labs may incorporate real hardware, such as real computers, routers, and firewalls, but this increases costs and electricity usage. However, these sophisticated environments enable more realistic scenarios and complex tasks.

This page explains how a basic pentesting lab that can be set up with VirtualBox. This environment will suffice for most people who want to try out or train pentesting and hacking at home. The system will consist of a base machine at performs the actual operations (the attacker machine) and arbitrary target machines, the user can add and remove at will.

The software used in this tutorial:

* Windows 10 or 11 (as the Host OS)
* [https://www.virtualbox.org/wiki/Downloads VirtualBox]
* [https://www.kali.org/get-kali/#kali-virtual-machines Kali Linux]

== Setup Steps ==

===Installation===

Download and install VirutalBox on your Windows machine. There is no need to manually configure anything in this installation process, you can just leave everything at default.

On the Kali Linux download-page, make sure you go to "Pre-built Virtual Machines" and select the VirtualBox option. Using a pre-built image will make the OS setup much easier than with traditional ISO-files. This download might take a while.

===Attacker Setup===

Downloading the Kali pre-build VM will get you a .ZIP-folder. Extract it to a directory of your choice. Inside you should find a .VBOX-file. Double-click it and the VM will be automatically imported to the VirtulBox Manager.

This machine can now be used out-of-the-box. The login credentials are "kali" and "kali". This is OK because, this is just a training environment, the password does not need to be strong or protected.

If the machine automatically boots up when imported, you can shut it down again. Do this by click "File" in the top bar of the machine windows. Then "Close" and "Power off the machine" -> OK. Alternatively, you can login and shut it down from there normally.

Now you should have the Kali VM in your list, looking something like this:

[[File:VboxKali.png|600px|center|thumb|VirtualBox Kali VM]]

===Network Configuration===

The goal is to create a testing network that is separated from the host OS. The easiest way to do this is by creating a virtual network that only contains the attacker and target machines. This can be achieved by setting up a DHCP-service within VirtualBox, that automatically assigns IP-addresses to the VMs when booted up.

Open the windows command prompt and navigate to the VirtualBox installation directory. By default this is ''C:\Program Files\Oracle\VirtualBox''. Now use the vboxmanage tool to create the DHCP server:

<syntaxhighlight lang="cmd">
vboxmanage dhcpserver add --network=vnet --server-ip=172.16.0.1 --lower-ip=172.16.0.2 --upper-id=172.16.0.100 --netmask=255.255.255.0 --enable
</syntaxhighlight>

You can also choose other settings for you network, but make sure to use private IP addresses. If you don´t know what values to pick, you can just copy this command.

For every machine you want to add to the pentesting network, go into the settings for the VM and go to Network. Enable one adapter and set it as attachted to ''Internal Network''. Below, enter the same name that was used in the vboxmanage-command (''vnet'' in this example).

[[File:Vboxnwconf.png|600px|center|thumb|VirtualBox VM network settings]]

At the end, you can start the machine and verify the network configuration. If the machine has an IP from the defined pool, the DHCP service works correctly.

[[File:Kalinwconf.png|400px|center|thumb|VirtualBox VM network settings]]

===Add Target Machines===

Now your virtual pentesting lab is ready. You can add vulnerable target machines that you can hack from your Kali-Base-VM. A great source for such VMs is [https://www.vulnhub.com/ VulnHub.com]. This site offers a vast catalog of virtual machines that are intentionally vulnerably. You can legally hack and break them inside your environment.

However, always make sure to '''add your machine to the testing network''', like we did with that attacker machine.

Once a target is added you can use nmap, fping, ping, netdiscover or some other tool to find it on the network. Now you can start hacking and exploring the machine for weaknesses.

===Optional: Host-to-VM Connection===

With the current network configuration there is no connection between the physical host machine, that is running the VMs, and the attacker machine. Therefore the attacker also has no internet connection.

This is not necessary for such an environment. But if you want this, you can enable a second adapter in the VM settings and set it to ''NAT''. This way the VM will have host and internet connectivity. But this goes only in one direction, the host or the internet cannot reach the VM.

If you want the connection to go bidirectional, set the adapter to ''Birdged Adapter''.

== References ==

* https://ieeexplore.ieee.org/document/10108187
* https://ia802202.us.archive.org/9/items/1.-the-pentester-blueprint/1.%20The%20Pentester%20Blueprint.pdf
* https://www.vulnhub.com/

VirtualBox: How to set up a Basic Pentesting Lab

2024-12-18T15:32:40Z

CHoerhan:

== Introduction ==

Training penetration testing typically occurs in a dedicated environment known as a pentesting lab, which is isolated from regular user applications and operating systems for security and convenience reasons. A pentesting lab can vary in complexity, with a minimalist setup involving a single computer running multiple virtual machines (VMs), often referred to as a virtual or basic pentesting lab. This variant uses virtualization software like VMware or VirtualBox to create an attacker VM with a specialized OS, such as Kali, Parrot or Arch, and allows for the addition of target machines. These machines are then consolidated in a virtual network. Users can log into the attacker machine to begin testing. More advanced labs may incorporate real hardware, such as real computers, routers, and firewalls, but this increases costs and electricity usage. However, these sophisticated environments enable more realistic scenarios and complex tasks.

This page explains how a basic pentesting lab that can be set up with VirtualBox. This environment will suffice for most people who want to try out or train pentesting and hacking at home. The system will consist of a base machine at performs the actual operations (the attacker machine) and arbitrary target machines, the user can add and remove at will.

The software used in this tutorial:

* Windows 10 or 11 (as the Host OS)
* [https://www.virtualbox.org/wiki/Downloads VirtualBox]
* [https://www.kali.org/get-kali/#kali-virtual-machines Kali Linux]

== Setup Steps ==

===Installation===

Download and install VirutalBox on your Windows machine. There is no need to manually configure anything in this installation process, you can just leave everything at default.

On the Kali Linux download-page, make sure you go to "Pre-built Virtual Machines" and select the VirtualBox option. Using a pre-built image will make the OS setup much more easy than with traditional ISO-files. This download might take a while.

===Attacker Setup===

Downloading the Kali pre-build VM will get you a .ZIP-folder. Extract it to a directory of your choice. Inside you should find a .VBOX-file. Double-click it and the VM will be automatically imported to the VirtulBox Manager.

This machine can now be used out-of-the-box. The login credentials are "kali" and "kali". This is OK because, this is just a training environment, the password does not need to be strong or protected.

If the machine automatically boots up when imported, you can shut it down again. Do this by click "File" in the top bar of the machine windows. Then "Close" and "Power off the machine" -> OK. Alternatively, you can login and shut it down from there normally.

Now you should have the Kali VM in your list, looking something like this:

[[File:VboxKali.png|600px|center|thumb|VirtualBox Kali VM]]

===Network Configuration===

The goal is to create a testing network that is separated from the host OS. The easiest way to do this is by creating a virtual network that only contains the attacker and target machines. This can be achieved by setting up a DHCP-service within VirtualBox, that automatically assigns IP-addresses to the VMs when booted up.

Open the windows command prompt and navigate to the VirtualBox installation directory. By default this is ''C:\Program Files\Oracle\VirtualBox''. Now use the vboxmanage tool to create the DHCP server:

<syntaxhighlight lang="cmd">
vboxmanage dhcpserver add --network=vnet --server-ip=172.16.0.1 --lower-ip=172.16.0.2 --upper-id=172.16.0.100 --netmask=255.255.255.0 --enable
</syntaxhighlight>

You can also choose other settings for you network, but make sure to use private IP addresses. If you don´t know what values to pick, you can just copy this command.

For every machine you want to add to the pentesting network, go into the settings for the VM and go to Network. Enable one adapter and set it as attachted to ''Internal Network''. Below, enter the same name that was used in the vboxmanage-command (''vnet'' in this example).

[[File:Vboxnwconf.png|600px|center|thumb|VirtualBox VM network settings]]

At the end, you can start the machine and verify the network configuration. If the machine has an IP from the defined pool, the DHCP service works correctly.

[[File:Kalinwconf.png|400px|center|thumb|VirtualBox VM network settings]]

===Add Target Machines===

Now your virtual pentesting lab is ready. You can add vulnerable target machines that you can hack from your Kali-Base-VM. A great source for such VMs is [https://www.vulnhub.com/ VulnHub.com]. This site offers a vast catalog of virtual machines that are intentionally vulnerably. You can legally hack and break them inside your environment.

However, always make sure to '''add your machine to the testing network''', like we did with that attacker machine.

Once a target is added you can use nmap, fping, ping, netdiscover or some other tool to find it on the network. Now you can start hacking and exploring the machine for weaknesses.

===Optional: Host-to-VM Connection===

With the current network configuration there is no connection between the physical host machine, that is running the VMs, and the attacker machine. Therefore the attacker also has no internet connection.

This is not necessary for such an environment. But if you want this, you can enable a second adapter in the VM settings and set it to ''NAT''. This way the VM will have host and internet connectivity. But this goes only in one direction, the host or the internet cannot reach the VM.

If you want the connection to go bidirectional, set the adapter to ''Birdged Adapter''.

== References ==

* https://ieeexplore.ieee.org/document/10108187
* https://ia802202.us.archive.org/9/items/1.-the-pentester-blueprint/1.%20The%20Pentester%20Blueprint.pdf
* https://www.vulnhub.com/

VirtualBox: How to set up a Basic Pentesting Lab

2024-12-18T15:20:43Z

CHoerhan:

== Introduction ==

Training penetration testing typically occurs in a dedicated environment known as a pentesting lab, which is isolated from regular user applications and operating systems for security and convenience. A pentesting lab can vary in complexity, with a minimalist setup involving a single computer running multiple virtual machines (VMs), often referred to as a virtual or basic pentesting lab. This variant uses virtualization software like VMware or VirtualBox to create an attacker VM with a specialized OS, such as Kali, Parrot or Arch, and allows for the addition of target machines. These machines are then consolidated in a virtual network. Users can log into the attacker machine to begin testing. More advanced labs may incorporate real hardware, such as real computers, routers, and firewalls, but this increases costs and electricity usage. However, these sophisticated environments enable more realistic scenarios and complex tasks.

This page explains how a basic pentesting lab that can be set up with VirtualBox. This environment will suffice for most people who want to try out or train pentesting and hacking at home. The system will consist of a base machine at performs the actual operations (the attacker machine) and arbitrary target machines, the user can add and remove at will.

The software used in this tutorial:

* Windows 10 or 11 (as the Host OS)
* [https://www.virtualbox.org/wiki/Downloads VirtualBox]
* [https://www.kali.org/get-kali/#kali-virtual-machines Kali Linux]

== Setup Steps ==

===Installation===

Download and install VirutalBox on your Windows machine. There is no need to manually configure anything in this installation process, you can just leave everything at default.

On the Kali Linux download-page, make sure you go to "Pre-built Virtual Machines" and select the VirtualBox option. Using a pre-built image will make the OS setup much more easy than with traditional ISO-files. This download might take a while.

===Attacker Setup===

Downloading the Kali pre-build VM will get you a .ZIP-folder. Extract it to a directory of your choice. Inside you should find a .VBOX-file. Double-click it and the VM will be automatically imported to the VirtulBox Manager.

This machine can now be used out-of-the-box. The login credentials are "kali" and "kali". This is OK because, this is just a training environment, the password does not need to be strong or protected.

If the machine automatically boots up when imported, you can shut it down again. Do this by click "File" in the top bar of the machine windows. Then "Close" and "Power off the machine" -> OK. Alternatively, you can login and shut it down from there normally.

Now you should have the Kali VM in your list, looking something like this:

[[File:VboxKali.png|600px|center|thumb|VirtualBox Kali VM]]

===Network Configuration===

The goal is to create a testing network that is separated from the host OS. The easiest way to do this is by creating a virtual network that only contains the attacker and target machines. This can be achieved by setting up a DHCP-service within VirtualBox, that automatically assigns IP-addresses to the VMs when booted up.

Open the windows command prompt and navigate to the VirtualBox installation directory. By default this is ''C:\Program Files\Oracle\VirtualBox''. Now use the vboxmanage tool to create the DHCP server:

<syntaxhighlight lang="cmd">
vboxmanage dhcpserver add --network=vnet --server-ip=172.16.0.1 --lower-ip=172.16.0.2 --upper-id=172.16.0.100 --netmask=255.255.255.0 --enable
</syntaxhighlight>

You can also choose other settings for you network, but make sure to use private IP addresses. If you don´t know what values to pick, you can just copy this command.

For every machine you want to add to the pentesting network, go into the settings for the VM and go to Network. Enable one adapter and set it as attachted to ''Internal Network''. Below, enter the same name that was used in the vboxmanage-command (''vnet'' in this example).

[[File:Vboxnwconf.png|600px|center|thumb|VirtualBox VM network settings]]

At the end, you can start the machine and verify the network configuration. If the machine has an IP from the defined pool, the DHCP service works correctly.

[[File:Kalinwconf.png|400px|center|thumb|VirtualBox VM network settings]]

===Add Target Machines===

Now your virtual pentesting lab is ready. You can add vulnerable target machines that you can hack from your Kali-Base-VM. A great source for such VMs is [https://www.vulnhub.com/ VulnHub.com]. This site offers a vast catalog of virtual machines that are intentionally vulnerably. You can legally hack and break them inside your environment.

However, always make sure to '''add your machine to the testing network''', like we did with that attacker machine.

Once a target is added you can use nmap, fping, ping, netdiscover or some other tool to find it on the network. Now you can start hacking and exploring the machine for weaknesses.

===Optional: Host-to-VM Connection===

With the current network configuration there is no connection between the physical host machine, that is running the VMs, and the attacker machine. Therefore the attacker also has no internet connection.

This is not necessary for such an environment. But if you want this, you can enable a second adapter in the VM settings and set it to ''NAT''. This way the VM will have host and internet connectivity. But this goes only in one direction, the host or the internet cannot reach the VM.

If you want the connection to go bidirectional, set the adapter to ''Birdged Adapter''.

== References ==

* https://ieeexplore.ieee.org/document/10108187
* https://ia802202.us.archive.org/9/items/1.-the-pentester-blueprint/1.%20The%20Pentester%20Blueprint.pdf
* https://www.vulnhub.com/

File:VboxKali.png

2024-12-18T15:20:20Z

CHoerhan:

The Trans2open Vulnerability

2024-12-18T15:17:14Z

CHoerhan:

The trans2open vulnerability, sometimes also referred to as ”trans2 vulnerability”, is a weakness that can be found in Samba versions 2.2.0 to 2.2.8. It was disclosed in 2003, at which time the Samba Port 139 was one of the most attacked ports worldwide. The vulnerability consists in a buffer overflow (BOF) that can be exploited remotely. Basically, this overflow provides an advasery with lots of attacking options. For once, it can be used to execute arbitrary code on the affected system and even open a reverse-shell with root privilidges. Another exploitation include implanting a backdoor. The trans2open vulnerability poses an extreme danger to any system that employs an effected Samba version and should be removed immediately.

Related CVE include [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0196 CVE-2003-0196], [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2003-0201 CVE-2003-0201] and [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2003-0345 CVE-2003-0345].

== Samba ==

Samba is an open-source, cross-platform software that facilitates file and printer sharing across various operating systems within a network. Primarily, it enables seamless file sharing between Windows and Linux/Unix systems. With Samba, a Linux file server can function within a Windows network, allowing users to access directories and files as if they were on a Windows machine. Initially released in 1992, Samba has grown significantly in popularity over the years. According to its official website, it is recognized as the standard suite of programs for Windows interoperability on Linux and Unix systems.

== SMB ==

Samba implements the Server Message Block (SMB) protocol, which is a network protocol designed for sharing files, printers, and serial ports between nodes on a network. It operates over TCP/IP. Originally developed by IBM in 1983, SMB was later adapted by Microsoft in 1996 into the Common Internet File System (CIFS). While CIFS is sometimes used interchangeably with SMB, it only encompasses the features of SMB 1.0 and is largely outdated today. SMB has evolved over the years, with several versions, including SMB1, SMB2, and SMB3, each introducing improvements in performance, security, and functionality. Modern versions of SMB also support interprocess communication and authentication methods such as Kerberos and NTLM (NT LAN Manager). Both Samba and SMB are widely used for communication and resource sharing across various IT systems.

== Exploitation ==

The vulnerability can be exploited in many different ways. However, they all relie on the remote command execution that is enabled through the buffer overflow.

A client-supplied string is copied into a fixed-size buffer. However, this is done without comparing the size of the buffer to the length of the string beforehand. The buffer is allocated on the stack during a function call. Therefore, the overflow can easily overwrite the copy of the instruction pointer that is saved on the stack.

===Metasploit===

The metasploit framework offers modules that target the vulnerability. One module is specifically desinged to determine the version of Samba running on a specific port. It can be found in scanner/smb/smb_version.

For exploitation metasploit offers the following modules:

* exploit/freebsd/samba/trans2open
* exploit/linux/samba/trans2open
* exploit/osx/samba/trans2open
* exploit/solaris/samba/trans2open

Most of them open a TCP shell back to the attacker.

A lot of other exploits can be found on the internet. Many of them seem to have roots going back trans2root.pl and sambal.c, which where one of the first exploits.

== Prevention ==

The best defensive action is to remove the vulnerability before it can be exploited. The following nmap command be used to scan for servers running Samba:

<syntaxhighlight lang="cmd">
nmap -sT -p 137,139,445 -O TARGET_IP
</syntaxhighlight>

If a vulnerable Samba version is actually running on a server, the following countermeasures can be taken:

* Upgrade the software to higher safe version (2.2.9 or 3.X.X). This is the best solution.
* Block external access to TCP port 139 (or 445) from any network firewalls.
* "Misconfigure" Samba so that anonymous access does not work. At lot of exploits rely on feature. Do this by setting the guest account user to a nonexistent name in the smb.conf file.

== References ==

* https://www.giac.org/paper/gcih/484/exploiting-sambas-smbtrans2-vulnerability/105385
* https://www.samba.org/samba/history/samba-2.2.9.html
* https://www.rapid7.com/db/modules/exploit/linux/samba/trans2open/
* https://www.exploit-db.com/exploits/22468
* https://nvd.nist.gov/vuln/detail/CVE-2003-0201
* https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2003-0201