[BUG] Unable to get WMI working #331

gooseleggs · 2025-02-12T03:50:20Z

Using the 25.01.01 container, and trying to perform a WMI scan against a known machine, I get

Description (Knowledge base entry)                                                              : Value/Content
--------------------------------------------------------------------------------------------------------------------------------
Access to the registry possible (SMB/registry_access)                                           : TRUE
Access via WMI possible (WMI/access_successful)                                                 : FALSE

under the Authenticated Scan / LSC Info Consolidation (Windows SMB Login) report for a scan. Jumping into the container and running the wmic command, or the impacket-wmic command works as expected (I can get a response). However, there is nothing in the scanning logs, other than WMI access is denied or not available.

For comparison, I spun up the Greenbone community containers (that was a mission!!) and did a comparison scan. That scan was successful, and I received

Description (Knowledge base entry)                                                              : Value/Content
--------------------------------------------------------------------------------------------------------------------------------
Access to the registry possible (SMB/registry_access)                                           : TRUE
Access via WMI possible (WMI/access_successful)                                                 : TRUE

So, how would I go about trying to troubleshoot this to provide some valid feedback??

The text was updated successfully, but these errors were encountered:

immauss · 2025-02-12T05:56:00Z

@gooseleggs
Thanks. I'll have to take a look at this.
Do you know if this worked in prior versions? (Can you test a few versions back? )

-Scott

gooseleggs · 2025-02-13T02:09:38Z

Scott

So today, I enabled Audit logging for all WMI created processes. I ran the Greenbone scanner, and then put the line openvas wmi from here in the audit log file, and then run the Immauss container. Both containers ran the same scan (separate databases between the two). Greenbone succeeded, Immauss did not. Attached is the outputs of the audit log to pour over. The Greenbone scanner seems to start python3 as arg0, and Immauss is /bin/sh. If I go into the container, and try /bin/sh /usr/bin/impacket... it succeeds. However, in the audit log it fails with a -2 error.

As per when did we think it broke - not sure. 22.4.47 had the fault.

wmi.log

immauss · 2025-02-13T10:09:03Z

OK ...
odd but decipherable.

"-2" means the file was not found.

The audit logs, (Thank you btw) show the failure trying to execute "impacket-wmiexe" .
Which is not on the image.
instead, what is being built is "impacket-wmiexec"

I'm relatively certain this is the binary needed, but no idea why it would be named differently.

Could you try linking it in the container and re-running the scan?

docker exec -it openvas bash -c "ln /usr/bin/impacket-wmiexec /usr/bin/impacket-wmiexe"

If that works, I just need to figure out "why" its different, and either fix the why or add the linking to the startup.

Thanks,
Scott

gooseleggs · 2025-02-14T04:20:59Z

Interesting...but no success.

So I did what you asked. However /usr/bin/impacket-wmiexec points to a script, which basically gets back what is after the - and calls that using python. So, to set up the impacket-wmiexec file meant that I just needed to copy the script file and hard code the wmiexec.py call. Unfortunately, this does not work. Also make impacket-wmiexe point to the hard coded script as well. No dice.
The error of name from impacket-wmiexec -> impacket-wmiexe seems to occur after a call to basename by the looks of the output.

I thought that it might be because the linking was relative, ie ls -l /usr/bin/impacket-wmiexec --> ../share/impacket/script. So, I changed that to be full path and not relative = no dice.

So, don't have an answer yet

gooseleggs · 2025-02-19T23:45:24Z

Scott

Done a few more hours into this. Gone down the wrong rabbit hole, and back up. Haven't got an answer, but it must be in the building of the image, as WMI is not an external call.

So, changes to the base image:

First the wrong rabbit hole....
The version of impacket-wmiexec in your image must be the version from the repo. This version is old.

root@3dd467b556a3:/# impacket-wmiexec
Impacket v0.10.0 - Copyright 2022 SecureAuth Corporation

Doing this in the Greenbone container results in:

root@ospd-openvas:/ospd-openvas# impacket-wmiexec
Impacket v0.12.0 - Copyright Fortra, LLC and its affiliated companies

Looking at the Dockerfile from Greenbone (https://github.com/greenbone/ospd-openvas/blob/main/.docker/prod.Dockerfile), the following lines are used:

# produces the bug ` ‘/usr/share/doc/python3-impacket/examples/wmiexec.py’: [Errno 2] No such file or directory`
RUN apt-get remove -y python3-impacket || true
RUN apt-get autoremove -y
...
# install impacket via pip and not apt-get to get the latest version
RUN python3 -m pip install --break-system-packages impacket 
# openvas is expecting impacket-wmiexec to be in the path although it got renamed
# until openvas is fixed we create a symlink
RUN ln -s /usr/local/bin/wmiexec.py /usr/local/bin/impacket-wmiexec

Next testing WMI...
So, I created a NASL test script to validate the WMI. It is attached. Running this in Immauss container...

test.nasl.txt

root@3dd467b556a3:/# openvas-nasl test.nasl -X -t 10.1.101.243 -i /data/var-lib/openvas/plugins/
lib  nasl-Message: 23:40:27.556: Starting
lib  nasl-Message: 23:40:27.556: 10.1.101.243
lib  nasl-Message: 23:40:27.556: JC-S25\Administrator
lib  nasl-Message: 23:40:27.556: BadPassword123
lib  nasl-Message: 23:40:27.556: Username is not blank
lib  nasl-Message: 23:40:27.556: About to WMI Connect
[/build/openvas-smb-22.5.6/samba/librpc/rpc/dcerpc_connect.c:798:dcerpc_pipe_connect_b_recv()] failed NT status (c00000b5) in dcerpc_pipe_connect_b_recv
lib  nasl-Message: 23:41:27.558: nasl_wmi_connect: WMI Connect failed or missing WMI support for the scanner
lib  nasl-Message: 23:41:27.558: Finished connecting

Looking at the audit log file, nothing is called, so this wmi_connect must be an internal function to openvas.

When run inside the Greenbone opsd container

root@ospd-openvas:/ospd-openvas# openvas-nasl test.nasl -X -t 10.1.101.243 -i /var/lib/openvas/plugins
lib  nasl-Message: 23:22:47.620: Starting
lib  nasl-Message: 23:22:47.620: 10.1.101.243
lib  nasl-Message: 23:22:47.620: JC-S25\Administrator
lib  nasl-Message: 23:22:47.620: BadPassword123
lib  nasl-Message: 23:22:47.620: Username is not blank
lib  nasl-Message: 23:22:47.621: About to WMI Connect
lib  nasl-Message: 23:22:47.642: Finished connecting
lib  nasl-Message: 23:22:47.642: Yeeha - we connected

test.nasl.txt

immauss · 2025-02-20T22:47:32Z

that triggered a memory.
I had moved the install of impacket to pip vs apt sometime ago ...
But somehow, impacket was added back into the list of packages to install in the base image. The command I was using for the pip install was the same as GB:

python3 -m pip install --break-system-packages impacket

I'm thinking it took that option seriously and broke the system packages. :)

I'm rebuilding again now without the impacket by apt.

the tag will be 25.02.goose

-Scott

gooseleggs · 2025-02-21T21:39:21Z

Scott

That image still has the 10.0 version of impacket in it. Manually removing the system version and installing the python version is not resolving it either.

I think the openvas-smb needs to be looked at as well as this seems to do the wmi stuff.

gooseleggs · 2025-03-12T22:02:17Z

Any update on another build for WMI? I am hoping to get it sorted before another engagement next week :-)

immauss · 2025-03-15T08:29:53Z

@gooseleggs

Sorry ... it's been crazy days around here ...

From 25.03.03 pushed just moments ago:

root@b2ff4f715c5f:/# dpkg -l | grep packet 
ii  libnet1:amd64               1.1.6+dfsg-3.2                      amd64        library for the construction and handling of network packets
ii  libpcap0.8:amd64            1.10.3-1                            amd64        system interface for user-level packet capture
root@b2ff4f715c5f:/# 
root@b2ff4f715c5f:/# dpkg -l | grep wmi
root@b2ff4f715c5f:/# wmiquery.py --version
Impacket v0.12.0 - Copyright Fortra, LLC and its affiliated companies 

usage: wmiquery.py [-h] [-namespace NAMESPACE] [-file FILE] [-debug] [-com-version MAJOR_VERSION:MINOR_VERSION] [-hashes LMHASH:NTHASH] [-no-pass] [-k] [-aesKey hex key]
                   [-dc-ip ip address] [-rpc-auth-level [{integrity,privacy,default}]]
                   target
wmiquery.py: error: the following arguments are required: target
root@b2ff4f715c5f:/# impacket-wmiexec --version 
Impacket v0.12.0 - Copyright Fortra, LLC and its affiliated companies 

usage: impacket-wmiexec [-h] [-share SHARE] [-nooutput] [-ts] [-silentcommand] [-debug] [-codec CODEC] [-shell-type {cmd,powershell}] [-com-version MAJOR_VERSION:MINOR_VERSION]
                        [-hashes LMHASH:NTHASH] [-no-pass] [-k] [-aesKey hex key] [-dc-ip ip address] [-target-ip ip address] [-A authfile] [-keytab KEYTAB]
                        target [command ...]
impacket-wmiexec: error: the following arguments are required: target

So I'm pretty sure it has the right version it now.

Can you test and let me know.

-Scott

gooseleggs · 2025-03-15T20:45:37Z

Yes - can confirm it is now using v12 impacket. Unfortunately, there is still something note quite right - probably with the compilation of the WMI components in openvas-smb.

OK - there is a workaround. If I manually build OpenVAS SMB and install in the container, it seems to work. So, steps from the standard 25.03.03 container:

apt update && apt install -y build-essential cmake  gcc-mingw-w64 libbsd-dev libcurl4-openssl-dev libcjson-dev libgcrypt20-dev libglib2.0-dev libgnutls28-dev libgpgme-dev libhiredis-dev  libical-dev libjson-glib-dev libksba-dev libldap2-dev libmicrohttpd-dev libnet1-dev libpaho-mqtt-dev libpcap-dev libpopt-dev  libpq-dev libradcli-dev libsnmp-dev libssh-gcrypt-dev libunistring-dev libxml2-dev postgresql-server-dev-15 uuid-dev  heimdal-dev
wget https://github.com/greenbone/openvas-smb/archive/refs/tags/v22.5.7.tar.gz
tar xvzf v22.5.7.tar.gz
cd openvas-smb-22.5.7
cmake .
make 
make install

I then run the test.nasl script that I wrote and all OK.

So, it appears that you may need to look at this component of the build.

immauss · 2025-03-16T06:19:02Z

:/
OK .. I'll take look this morning

Thanks!

-Scott

immauss · 2025-03-16T07:50:00Z

OK ... the only thing missing was heimdal I've added it to the base image and to the build, which is running now.

-Scott

immauss · 2025-03-16T10:06:26Z

Curiously ....

I was installing the heimdal-dev in the build script. So it would build, but was missing some of the heimdal pieces in the base image.

There should a beta tag in docker hub shortly.
If you could give that a try and let me know if resolves....

Thanks,
Scott

immauss · 2025-03-16T10:08:56Z

Now that I think about it ... that was intentional. At some point in the past, installing the heimdal bits conflicted with some other kerberos bits that had to be installed too. But now the build is completing with no conflicts ... so ... Hopefully this will take care of it.

Thanks,
Scott

gooseleggs · 2025-03-16T11:16:04Z

Thanks Scott

Just to be clear, what tag is the new build?

immauss · 2025-03-16T11:33:07Z

The tag should be: beta Let me know if you don’t see it, or if the beta tag is more than a few hours older than this email.

…

-Scott

On Mar 16, 2025 at 12:16 +0100, gooseleggs ***@***.***>, wrote: Thanks Scott Just to be clear, what tag is the new build? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were assigned.Message ID: ***@***.***> gooseleggs left a comment (immauss/openvas#331) Thanks Scott Just to be clear, what tag is the new build? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were assigned.Message ID: ***@***.***>

gooseleggs · 2025-03-16T20:32:59Z

Don't see it. The one I see is 5 months old

immauss · 2025-03-16T20:43:24Z

😒
odd ...
ok I pushed it manually ...

-Scott

gooseleggs · 2025-03-16T22:37:01Z

Thanks Scott. Still no dice. Still working through it. When I compile and install, it works. When I just compile it does not work. When I check the files in the container before and after, they appear the same. Wierd.

OK - so doing some md5 sums there is a difference between the container, and the compiled version of the libraries...

md5sum /usr/local/lib/pkgconfig/libopenvas_wmiclient.pc /usr/local/bin/wmic  /usr/local/lib/libopenvas_wmiclient.so.22.5.7 /usr/local/lib/libopenvas_wmiclient.so.22 /usr/local/lib/libopenvas_wmiclient.so /usr/local/include/openvas/smb/openvas_smb_interface.h /usr/local/include/openvas/smb/openvas_wmi_interface.h /usr/local/share/man/man1/wmic.1

Before

root@dfe810102ede:/# md5sum /usr/local/lib/pkgconfig/libopenvas_wmiclient.pc /usr/local/bin/wmic  /usr/local/lib/libopenvas_wmiclient.so.22.5.7 /usr/local/lib/libopenvas_wmiclient.so.22 /usr/local/lib/libopenvas_wmiclient.so /usr/local/include/openvas/smb/openvas_smb_interface.h /usr/local/include/openvas/smb/openvas_wmi_interface.h /usr/local/share/man/man1/wmic.1
478f387082cd66f5679934420b14cb45  /usr/local/lib/pkgconfig/libopenvas_wmiclient.pc
9227aab1e7c0c2958230145d89c654e1  /usr/local/bin/wmic
06cbcb748794fbcc0495fc2bb36f6f6e  /usr/local/lib/libopenvas_wmiclient.so.22.5.7
06cbcb748794fbcc0495fc2bb36f6f6e  /usr/local/lib/libopenvas_wmiclient.so.22
06cbcb748794fbcc0495fc2bb36f6f6e  /usr/local/lib/libopenvas_wmiclient.so
1f9c62b53fb4c415fb0d62ae40f45b4b  /usr/local/include/openvas/smb/openvas_smb_interface.h
9d7dd9d1dcc2a2bfb1b258799ecc98e9  /usr/local/include/openvas/smb/openvas_wmi_interface.h
ca25785882a05282cb2a64ed6fdd5c3a  /usr/local/share/man/man1/wmic.1

After compiled

478f387082cd66f5679934420b14cb45  /usr/local/lib/pkgconfig/libopenvas_wmiclient.pc
133c18a0580644e058337f900f2236d7  /usr/local/bin/wmic
8d4f1c2c1ebca2bd38eb826abb5aecad  /usr/local/lib/libopenvas_wmiclient.so.22.5.7
8d4f1c2c1ebca2bd38eb826abb5aecad  /usr/local/lib/libopenvas_wmiclient.so.22
8d4f1c2c1ebca2bd38eb826abb5aecad  /usr/local/lib/libopenvas_wmiclient.so
1f9c62b53fb4c415fb0d62ae40f45b4b  /usr/local/include/openvas/smb/openvas_smb_interface.h
9d7dd9d1dcc2a2bfb1b258799ecc98e9  /usr/local/include/openvas/smb/openvas_wmi_interface.h
ca25785882a05282cb2a64ed6fdd5c3a  /usr/local/share/man/man1/wmic.1

immauss · 2025-03-17T05:51:00Z

are you using the same compiler version? if anything in the build tools is a little different, then the it could change the hash.

And it's just the wmi pieces that are different .... well except that first one (the ".pc"), which I'm fairly certain is part of the source? The package config file....

Can you expand on this statement:
"Thanks Scott. Still no dice. Still working through it. When I compile and install, it works. When I just compile it does not work."

Were are you building and how for each scenario?

Thanks,
-Scott

gooseleggs · 2025-03-17T06:10:51Z

Scott So starting the container up and running md5sum as per above. Then running the steps to reinstall the version over top of itself from within the running container using the steps in the previous post. It could be a different compiler. I am using the same pre-reqs that you are. That is the only differences that I can come up with. It is not being overwritten by any of the xz’d directories thereby rolling it back? Otherwise I am at a loss at the moment of what to check next.

gooseleggs assigned immauss Feb 12, 2025

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[BUG] Unable to get WMI working #331

[BUG] Unable to get WMI working #331

[BUG] Unable to get WMI working #331

[BUG] Unable to get WMI working #331

Comments