PrintNightmare is causing quite a stir. This writeup from Kevin Beaumont is a great overview and intro if somehow you aren’t familiar with the issue. And the Huntress blog is also a good resource. From being patched in June, but not really that was another thing, to an OOB July patch that didn’t fully remediate, it’s been quite the adventure in infosec. There has been great work by cube0x0 and gentilkiwi to provide POC code to test systems and validate the July patch as well as a PowerShell implementation from Caleb Stewart and John Hammond. All kinds of fun. These are all exploit code, which is awesome, but maybe not something you want to run in your org. Enter byt3bl33d3r’s ItWasAllADream scanner. It works well and checks for the vulnerability without exploiting the hosts. Much better for testing. The ReadMe is great, but I know in my current state of dumpster fire, there were some brain farts. So writing up a quick guide to not forget. If you want to get some experience with containers, this is good practice with low overhead.
You may need to verify you are running WSL 2 if you want to route this through a WSL distro. Follow the documentation to get up and running with Docker and WSL 2. You may need restarts and to convert WSL 1 distros. Running WSL 1 and docker will make things cranky, so update before getting started. If you’ve installed Docker via apt, you will need to remove it (and remember it’s docker.io not just docker) to use the WSL 2 integration. Verify you have the right Docker by confirming the version. Setting up WSL2 wasn’t difficult, but it can be a little fidgety.
Windows recommends using Windows Terminal for the WSL 2 Docker integration. That may just be to push Terminal, but it’s got some advantages. So at least consider it.
Once you’ve got whatever you will be using for Docker functional, install and as directed. Super simple.
git clone https://github.com/byt3bl33d3r/ItWasAllADream
cd ItWasAllADream #This and next can be combined if desired, make sure you clone it where you want it
docker build -t itwasalladream
docker run -it itwasalladream -u <user> -p <password> -d <domain> <targetinCIDRnotation>
The output is a little verbose by default and is very clear what is found. This is great work by byt3bl33d3r.
The CSV output is dropped in the working directory in the CONTAINER. This was where I had a total brain fart. I do feel a little better that I’m not the only one based on the issues on Github. So, getting the report out of the container requires using
docker cp. See the Docker documentation for details.
docker copy <containername>:<reportname> .
If you don’t know the container name, get it by listing the containers available.
docker ps -a
And clean up your scans when you are done.
docker system prune
As much as I enjoy the generated container names Docker creates, they were a bit long to deal with effectively when using this to really check things. So name your container something useful and copy where you need it.
What is really great about the infosec community is from when the issue/question was posted, it took about 12 hours for details to be provided to the original poster with links and sample commands.
docker run --name <shortname> -ti itwasalladream -u <user> -p <password> -d <domain> <targetinCIDR> # Get the report name from the output, adjust path to fit your needs docker cp <shortname>:<reportname> /mnt/c/Users/<username>/<path>
So that’s ItWasAllADream in a nutshell. Easy to use scanner that in my testing has not caused issues and has returned accurate info. I suspect we’ll have a lot of people trying to scan systems who may not use Docker or WSL regularly, and hopefully this will help if they get stuck. And yes, this will probably be me here in a few months when I decided to re-check some things. Thus the writing it down.
I’m seeing a ton of questions about how to implement mitigations, and this testing is really helpful. Right now, it looks like the best option is shutting off the print spooler where that’s an option. Since that’s really unpractical in a lot of cases, the GPO disabling inbound remote printing also seems to be effective. Either way, I bet we’re going to be dealing with the fallout for some time.