Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support -Credential option for Invoke-FileFinder #55

Closed
maaaaz opened this issue Sep 29, 2015 · 7 comments
Closed

Support -Credential option for Invoke-FileFinder #55

maaaaz opened this issue Sep 29, 2015 · 7 comments

Comments

@maaaaz
Copy link

maaaaz commented Sep 29, 2015

Hello there,

Thank you for this awesome framework.
To me, it would be even more awesome if you would add a -Credential option for (ideally) every function, especially Invoke-FileFinder and its threaded version as it is useful to easily know which sensitive files one can access with different collected credentials.
Plus, it is convenient to be able to launch such functions from off-domain workstations (i.e the attacker one)

Again, thank you.
Cheers.

@maaaaz maaaaz changed the title Support -Credential for Invoke-FileFinder Support -Credential for Invoke-FileFinder Sep 29, 2015
@maaaaz maaaaz changed the title Support -Credential for Invoke-FileFinder Support -Credential option for Invoke-FileFinder Sep 29, 2015
@HarmJ0y
Copy link
Contributor

HarmJ0y commented Sep 29, 2015

So the functions that utilize API calls (Get-NetShare, Get-NetSession, Get-NetLoggedOn) and the meta functions that wrap them (ShareFinder, FileFinder, UserHunter, etc.) don't accept additional credentials from what I can tell. For example, the NetShareEnum function used by Share/FileFinder.

WMI or WinRM based methods will accept a -Credential option, but those are fewer in PowerView (Get-NetProcess/Invoke-ProcessHunter already accept alternate credentials, I suppose Get-LastLoggedOn could be amended but we rarely really use that function). The other part of FileFinder, the wrapped Get-ChildItem call, doesn't accept alternative credentials either. One option might be to create ps drives for each share we're examining, but repeated modifications to the pivot host tend to make us uncomfortable.

Instead, I recommend using @sixdub's runas /netonly method described here. This will allow you to execute prompts with different credentials, even if you're on a non-domain joined system.

@HarmJ0y HarmJ0y closed this as completed Sep 29, 2015
@maaaaz
Copy link
Author

maaaaz commented Sep 29, 2015

I do understand the limitations, but the runas /netonly might fulfill my needs.
Maybe except when we don't have cleartext creds but only hashes: in that case I already tried to load a cmd with the mimikatz /pth module, unsuccessfully.

@HarmJ0y
Copy link
Contributor

HarmJ0y commented Oct 4, 2015

You do need to be local administrator on the machine to utilize Mimikatz' PTH functionality, I believe.

I checked into PSDrive a bit, and there's apparently a bug in PowerShell version 2.0 when using specified credentials to map a PSDrive. A workaround from that post (if you choose to use it) would be to do something like:

$net = new-object -ComObject WScript.Network
$net.MapNetworkDrive("u:", "\server\share", $false, "domain\user", "password")

And then run Invoke-SearchFiles on the local drive path. Since we definitely don't want mass numbers of drive mountings by default in the script, we'll likely leave it in its current state.

@maaaaz
Copy link
Author

maaaaz commented Oct 5, 2015

Thank you for that insight.
ps: I was local admin while using mimikatz' pth feature, I don't know why it failed.

@Meatballs1
Copy link
Contributor

UAC?

@maaaaz
Copy link
Author

maaaaz commented Oct 5, 2015

Obviously granted, as it was on my own laptop.

@HarmJ0y
Copy link
Contributor

HarmJ0y commented Oct 13, 2015

The version_2.0 branch just got a commit to support this. Find-InterestingFile and Invoke-FileFinder both now support a -Credential option. I wasn't able to test in the field (just in a lab), so let me know if this works and I'll re-close the issue.

@HarmJ0y HarmJ0y reopened this Oct 13, 2015
@HarmJ0y HarmJ0y closed this as completed Oct 15, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants