In today's episode of All Software Sucks:
If you add a disk to a Windows 11 VM in VMware Workstation, do stuff, power the VM down, and remove the VMDK file, you have painted yourself into a corner.
You will not be able to revert to a snapshot prior to that disk existing because
checks notes
VMware needs for the disk to be there and have the correct encryption key before it will allow you to revert to another snapshot where the disk doesn't exist.
Workaround: Add a disk of the path name to the VM, and then restore your snapshot. š¤¦āāļø
There's a powerful (and dangerous) runtime that's been overlooked by the bad guys, but you need to know about it. This is an introduction to Deno and its offensive capabilities.
Mini Pen Test Diaries Story:
During the open source enumeration phase of an external footprint test, I found a virtual machine that bore the name of the client in its NetBIOS response in Shodan.
Connecting to the machine over HTTP, I found a web app that was very relevant to the industry of the client - so I knew it was likely related.
The strange thing, however, was that Shodan was telling me NetBIOS and SMB were open (thatās how I found the machine in the first place), but I was unable to connect to it over SMB. Port scan showed closed.
I needed to figure out why Shodan was telling me one thing, but my reality was different.
The machine was hosted in Azure, so I figured Iād try rerunning my port scan from a source IP in my own Azure account, to see if Iād get a different result.
Sure enough, SMB was open when scanned from an Azure machine. Theyād opened it up to any IP in Azure. No auth. Just an open file share accessible to anyone who was connecting to it from an Azure public source IP.
I reported it, and it turned out that the machine was hosted by a vendor on behalf of the client.
The vendor was insistent that my description of āpublic access to SMB shareā was wrong, since technically it wasnāt open to the internet - just to Azure.
I then pointed out that hey, Azure is a famous example of a āpublicā cloud for a reason.
They fixed it.
Lesson: always try from different perspectives - such as from within the same providers IP space, you might find what I found.
For more, slightly less mini stories like this ones check out https://infosecdiaries.com
Since @wdormann is quoted in this piece and I can't find Dan Wade's handle, I'm tagging him in.
Is this suggesting that the RDP cred cache never gets updated? Ever ever?
Also what's up with this?
Old credentials continue working for RDPāeven from brand-new machines.
That makes no sense at all.