getsystem and lsass dumping

[kildonan5]

Is your feature request related to a problem? Please describe. Hello, I have a few points after taking sliver for a test run

• There is not a clear distinction between spawning a new session as an elevated process vs a new session as system. What would an example of elevated process (thats not running as system) be?
• Running elevate as a user with admin privileges on windows does not work for UAC bypass (the victim user is shown a UAC prompt and asked to enter their credentials). Running elevate when the user has explicitly launched the beacon under a high integrity process (launching the beacon 'as administrator') results in the 'elevation' apparently working, but it still pops up a powershell window for a second or two in the victims session that isnt great 'opsec'.
• Running getsystem as administrative user in a non high integrity process results in 'access is denied'
• Sliver appears to be missing any tools/integration-with-mimikatz/kiwi for dumping lsass (unless I somehow missed it). Is this planned for the future?
• Stopping a command from running (e.g. exiting an interactive shell) with ctrl-c often causes the entire server (or client) to stop entirely (instead of just exiting the currently running command/module). On review, this is simlar to issue #122 although its not just on interactive powershell, its on most actions (such as interactive command prompt, and when trying to stop a payload from being created)
• Running the latest v.0.0.6 release, no log files are generated (regardless of whether i am using the client or the server... there is no logs folder generated, nor any log files generated). Furthermore, instructions for executing the GUI appear to rely on files that are not included in these release versions/archives.

[kildonan5]

Regarding dumping creds, I'm guessing there is some way to do it by using procdump on lsass, but its unclear to me what to do with the dump file. I try loading it within mimikatz, but am getting this error when i attempt to load it as a minidump "ERROR kuhl_m_sekurlsa_acquireLSA ; Key import" so I'm guessing thats not how im supposed to read it?

[moloch--]

Thanks for the feedback @kildonan5 ! Please keep in mind Sliver is in alpha right now and a few of these are planned features, but we develop this in our spare time so I can't commit to dates :)

1. Currently there is no distinction between the two, because we actually do spawn a new session each time you run elevate. It's on our roadmap to eventually stop doing this but in the short-term it was just a lot easier to spawn a new session each time.

2. & 3. These seem like a bugs @rkervella

3. Yes! We're planning on having more integration with mimikatz and other toolsets like SharpSploit and Bloodhound but we've not had time to write the code yet.

4. Yes this is a current limitation of our shell binding shenanigans and will take some effort to correct but it's a known issue (if you have ideas on how to fix please let me know!) --we're working on general improvements to the console experience too outside of shell.

5. Logs should be generated as outlined here. The GUI is in a separate gui branch but not currently usable, still in active development, but we're open to contributions.

[kildonan5]

Thanks for the quick feedback. Re the 3rd item (lsass dump), do you know if its possible to extract creds from lsass using the procdump feature? I tried with mimikatz but it doesnt seem to recognize the dump file (or at least, i couldnt get it to parse it).

[rkervella]

@kildonan5 thanks for the feedback, as @moloch-- said, we're aware of most of these issues and there's currently open issues for some of these.

2. Elevate might go away in a future release. This command started as a PoC to see how convenient it was, but it turns out it's a lot of troubles to maintain: Microsoft silently patches UAC bypasses every now and then, so keeping up to date to every windows update would be a PITA (as @moloch-- said, we mainly maintain this on our spare time). However, once we'll find a way to sideload arbitrary code as modules, we might think bringing that back.

3. Sounds like a bug to me, could you provide an explicit test case so I can work on it?

4. You should be able to use the output of procdump as input to mimikatz. If that fails, there may have been a change in the MiniDump format, that may require a more recent version of mimikatz. I just tested this on Windows 10 build 18362 (as a target) and the latest mimikatz version and it works properly.

As a side note, in the future, if you find an issue that is not referenced on GitHub, could you please create a new issue for each? That helps keep track of things, and also helps to assign issues to either @moloch-- or myself.

[kildonan5]

Re 3. Windows 10 v1809 build 17763

1. Using mtls windows x64 implant (generate --os windows --arch 64bit --mtls [IP] --skip-symbols), user in Local Administrators group executes implant by double clicking the exe (as opposed to right clicking and clicking run as administrator)
2. In Sliver server a connection is established, and the getsystem command is run, resulting in... " ⠼ Attempting to create a new sliver session as 'NT AUTHORITY\SYSTEM'..." followed shortly by: "[!] Error: Access is denied."

Re 4. I was able to get a procdump to work. I was migrating to lsass to do the dump, to bypass some endpoint protections. Im guessing that messes up memory such that mimikatz cant get a handle or something of the like.

[rkervella]

~Alright, looks like getsystem is broken. The current way it's working is by enabling SE_DEBUG (which was available but disabled in the past on Windows 10 for the sliver process), and then inject into a SYSTEM process (spoolsv.exe by default). From what I just observed, it looks like we don't have the SE_DEBUG priv on the elevated sliver process anymore. I'll need to run more tests to be sure of that, but that's definitely an issue and I'm looking into it.~

Edit: I just re-read your comment, and the command behaves as expected: you need to be in an elevated context to run getsystem. Otherwise, you won't have the required privileges to enable the SE_DEBUG privilege required for the command to work.

When running a sliver binary as an elevated process, the getsystem command will properly spawn a new session running as NT AUTHORITY\SYSTEM.

[rkervella]

Since this is working as expected, I'm closing this one. Feel free to reopen if there's a bug.

[kildonan5]

@rkervella Dumb question then. If I need to be in an elevated context to run getsystem, that means if I have a session as an administrator, in a non elevated context, in order to 'getsystem' I need to first run the "elevate" command (which currently doesnt work, and may be going away soon anyways) to then be able to run getsystem? I'm pretty sure when and if i run getsystem in a non elevated context in meterpreter, I get system, so are they doing something differently, or am i making stuff up?

[rkervella]

That's basically it: you need to be running in a High Integrity level process for sliver's getsystem to work. Meterpreter getsystem command (without args) attempts 3 different things to retrieve a SYSTEM token:

• named pipe impersonation (in-memory, and the most reliable)
• token impersonation (in-memory)
• named pipe impersonation by dropping a DLL to disk

Sliver's getsystem implementation differs in that we:

• enable the SE_DEBUG privilege on the current process (if it's present and disabled)
• inject a Sliver shellcode into a SYSTEM owned process (spoolsv.exe by default)

I wrote it that way because I didn't managed to get the named pipe impersonation to work (due to some edge cases regarding native threads).

In any case, the prerequisites are the same as meterpreter's getsystem, as illustrated below:

meterpreter > getsystem -h
Usage: getsystem [options]

Attempt to elevate your privilege to that of local system.

OPTIONS:

    -h        Help Banner.
    -t <opt>  The technique to use. (Default to '0').
        0 : All techniques available
        1 : Named Pipe Impersonation (In Memory/Admin)
        2 : Named Pipe Impersonation (Dropper/Admin)
        3 : Token Duplication (In Memory/Admin)

meterpreter > getsystem -t 1
[-] priv_elevate_getsystem: Operation failed: Access is denied. The following was attempted:
[-] Named Pipe Impersonation (In Memory/Admin)
meterpreter > getsystem -t 3
[-] priv_elevate_getsystem: Operation failed: The environment is incorrect. The following was attempted:
[-] Token Duplication (In Memory/Admin)

The above session is ran with a user in the local administrator group, but not from a high integrity process (just double clicked on the executable).

TL;DR: you need to be in an elevated context for this to work the way you want it to. I hope this will help make things clearer.