post/windows/gather/checkvm returns a bad result on java meterpreter

[jvazquez-r7]

• Running the module over java meterpreter, returns the target as Physical Machine, even when it's a VMware virtual machine (Windows XP SP3).

Target: Windows XPSP3, default administrator privileges session

msf > use post/windows/gather/checkvm
msf post(checkvm) > set session 1
session => 1
msf post(checkvm) > run
[*] [2015.10.29-13:02:06] Checking if juan-3e8dd40891 is a Virtual Machine .....
[*] [2015.10.29-13:02:09] juan-3e8dd40891 appears to be a Physical Machine
[*] Post module execution completed

[bcook-r7]

I think we need to implement the rest of the registry meterpreter commands in PHP for this to work properly.

[github-actions]

Hi!

This issue has been left open with no activity for a while now.

We get a lot of issues, so we currently close issues after 60 days of inactivity. It’s been at least 30 days since the last update here.
If we missed this issue or if you want to keep it open, please reply here. You can also add the label "not stale" to keep this issue open!

As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request.

[github-actions]

Hi again!

It’s been 60 days since anything happened on this issue, so we are going to close it.
Please keep in mind that I’m only a robot, so if I’ve closed this issue in error please feel free to reopen this issue or create a new one if you need anything else.

As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request.

[bcoles]

FWIW; this issue still exists with java/meterpreter/reverse_tcp Java Meterpreter on Windows 10:

msf6 post(windows/gather/checkvm) > set session 5 
session => 5
msf6 post(windows/gather/checkvm) > run

[*] Checking if WinDev1710Eval is a Virtual Machine ...
[*] WinDev1710Eval appears to be a Physical Machine
[*] Post module execution completed
msf6 post(windows/gather/checkvm) > sessions -i 5 
[*] Starting interaction with 5...

meterpreter > sysinfo
Computer    : WinDev1710Eval
OS          : Windows 10 10.0 (amd64)
Meterpreter : java/windows
meterpreter > 

Compared with compiled windows/x64/meterpreter/reverse_tcp exe Meterpreter on Windows 10:

msf6 post(windows/gather/checkvm) > set session 1
session => 1
msf6 post(windows/gather/checkvm) > run

[*] Checking if WINDEV1710EVAL is a Virtual Machine ...
[+] This is a VMware Virtual Machine
[*] Post module execution completed
msf6 post(windows/gather/checkvm) > sessions -i 1
[*] Starting interaction with 1...

meterpreter > sysinfo
Computer        : WINDEV1710EVAL
OS              : Windows 10 (10.0 Build 16299).
Architecture    : x64
System Language : en_US
Domain          : WORKGROUP
Logged On Users : 2
Meterpreter     : x64/windows
meterpreter > 

[sjanusz-r7]

Ive tested this on a Windows 10 1709 VM. Changes to Metasploit Framework made since this issue has been reported result in the VM being correctly identified however two warnings are shown:

The output is the same for OpenJDK 8 and OpenJDK 9:

msf6 post(windows/gather/checkvm) > run session=-1

[!] SESSION may not be compatible with this module:
[!]  * missing Meterpreter features: stdapi_fs_chmod, stdapi_registry_check_key_exists, stdapi_registry_create_key, stdapi_registry_delete_key, stdapi_registry_enum_key_direct, stdapi_registry_enum_value_direct, stdapi_registry_load_key, stdapi_registry_open_key, stdapi_registry_query_value_direct, stdapi_registry_set_value_direct, stdapi_registry_unload_key, stdapi_sys_config_getprivs, stdapi_sys_process_attach, stdapi_sys_process_kill, stdapi_sys_process_memory_allocate, stdapi_sys_process_memory_protect, stdapi_sys_process_memory_write, stdapi_sys_process_thread_create
[*] Checking if the target is a Virtual Machine ...
[+] This is a Hyper-V Virtual Machine
[*] Post module execution completed

msf6 payload(java/meterpreter/reverse_tcp) > version
Framework: 6.3.33-dev-90cf371376
Console  : 6.3.33-dev-90cf371376

[adfoster-r7]

I haven't debugged fully, but I think this was fixed by #18210 - which added better command detection of Registry manipulation. Now we much more granularly detect which Registry functions are available and fall back to using the command shell when the Meterpreter doesn't support the functionality natively

The warnings are caused by the mixin's requirements:

metasploit-framework/lib/msf/core/post/windows/registry.rb

Lines 58 to 70 in 90cf371

	'Commands' => %w[
	stdapi_registry_check_key_exists
	stdapi_registry_create_key
	stdapi_registry_delete_key
	stdapi_registry_enum_key_direct
	stdapi_registry_enum_value_direct
	stdapi_registry_load_key
	stdapi_registry_open_key
	stdapi_registry_query_value_direct
	stdapi_registry_set_value_direct
	stdapi_registry_unload_key
	stdapi_sys_config_getprivs
	]

Completely out of scope: I'm guessing technically we could remove those Meterpreter command requirements - or maybe mark them as hard/soft requirements for modules