I'm not even sure how I ended up down this rabbit hole but I strayed off the path for a talk that I'm giving next month.  I'm trying to show how to leverage PowerShell into doing the many things we do with various tools.  To some degree, you don't really need those tools. 

So this doesn't pluck the credentials out of memory or from the file system, we're going the old fashioned way -- we're tricking the user.  Imagine this -- a user is trying to work and Windows continues to prompt them for their credentials.  Will they ignore it?  No, they will enter their credentials. 

If you're on the local machine performing this trick, you don't need to specify domain\username.  However, if you end up on this machine through other means -- say Responder, you'll want to use the domain\username because it will throw an error prior to spawning the credential prompt.  Maybe that's not a bad thing but I'd rather do without it. 

Disclosure date: 01/07/20

CVE-2020-6583

Online Invoicing System (OIS) version 2.6 and possibly before are affected by a cross site scripting vulnerability that can be leveraged for session hijacking.  An attacker can exploit the XSS vulnerability, retrieve the session cookie from the administrator login, and take over the administrator account.

I've written a few scripts in PowerShell to perform various tasks for clients and I usually end up with a batch file or some instructions on how to overcome the problem with "execution of scripts" or the various signing errors.  Regardless of whether it's opened with an elevated prompt or not, when you attempt to execute a PowerShell script, you get the following: