Get-DFSShares

[Meatballs1]

Something like:

function Get-DFSShares {
    process {
        $DFSSearcher = [adsisearcher]"(objectClass=fTDfs)"
        $DFSSearcher.FindAll() | ForEach-Object {
            $properties = $_.Properties
            $properties.name
            $properties.remoteservername
        } 
    }
}

Would be useful to integrate with stealthuserhunter...

[HarmJ0y]

Started here, is this what you're envisioning? https://github.com/PowerShellEmpire/PowerTools/commit/5b8f4acf1ec51da40e3ffda5599668dbc13b01a2

Haven't dealt with registered FTDFSes, so not familiar with them. Is the "name" or the "remoteservername" the target server you'd likely want to enumerate for StealthUserHunter?

[Meatballs1]

If you come across DFS shares you will see shares mapped as, or in the profilepath etc as:

\\domain.lab\sharename

StealthuserHunter will then basically query the DC instead of a fileshare.

The fTDfs.name = sharename, the remoteservername are the underlying servers which the DFS is mapped against.

remoteservername is an ldap string array afaik, and would actually need some string manipulation on the output for stealthuserhunter because they are listed as:

\\fileshare.lab\#{name}

rather than just fileshare.lab FQDN. e.g. you would want to replace name or split on \ etc.

The array also ends with the last entry as a * or at least in the last configuration I have seen.

[HarmJ0y]

Cool, good to know. Tried a second pass at implementation here. Without a test environment, test data, or sufficient examples online (haven't found much beyond this), I might have to leave the rest of the testing/implementation of this one to you if you have time at some point in the future.

[Meatballs1]

Cool, I think I have seen both Domainv1 and Domainv2 looking at that link, on different jobs. I may have to dig out what I did for v2.

[Meatballs1]

I think the following may cause some people confusion:

 $DFSshares | Sort-Object -Property "RemoteServerName" -Unique

If you had multiple shares, but used the same file servers to serve them then you wouldn't see some of them in the output? If this is intended for the Invoke-StealthUserHunter then it would be better for that method to uniquify its target hosts

[Meatballs1]

N.b. I managed to spin up a Dfs environment in a couple of mins by adding the 'File Server' role to win2k8 r2, and ticking DFS shares, and following wizard to set up a test DFS share. See https://github.com/PowerShellEmpire/PowerTools/pull/51

N.b. I'm not sure if exposing ADSPath is useful in this case as the objects should always sit under CN=Dfs-Configuration,CN=System,DC=domain,DC=com

The diagram explaining v2 on https://msdn.microsoft.com/en-us/library/cc227250.aspx explains things better. I think will need to target msDFS-Linkv2

[Meatballs1]

https://github.com/jeremyts/ActiveDirectoryDomainServices/blob/master/Audit/Get-DFSNameSpaceReport.ps1 does both versions

[Meatballs1]

That repo looks very interesting btw :)

[HarmJ0y]

Sweet, so cool to leave the uniqifying in the current state? Going to go ahead and close this.

That repo has a done of stuff, will have to check out soon :)

[HarmJ0y]

Thoughts on pulling down any drives.xml policy files from the primary DC and parsing them as well? Like https://github.com/nullbind/Powershellery/blob/master/Stable-ish/ADS/Get-FileServers.psm1#L206

[Meatballs1]

Could be an option, but recursing for GPP .xml can take a long time if lots of policy folders are there. The main reason for me looking at DFS shares was because all the profilepath directories were hosted on a DFS share so hunting didn't work by default :)

[nullbind]

I never got around to updating that script, but I found it’s a little faster to find GPP xml files by referencing their semi-static paths instead of doing a full recursive search. High level process below:

1. Get the DNS domain name of the target DC using standard methods.
2. Use the DNS domain name to generate a static path to the policies folders on the target DC. Perform a non-recursive directory listing of the policies folder to get a list of the group policy ids. (I'm pretty sure that list can also be grabbed from an ldap query)
   • dir /b \dns_domain_name\Sysvol\dns_domain_name\Policies\
   • get-childitem \dns_domain_name\Sysvol\dns_domain_name\Policies\ | select name
3. Use the list of group policy ids to generate paths to the xml files and then parse away. Pseudo code below:
   • gc \dns_domain_name\Sysvol\dns_domain_name\Policies[group_policy_id]\User\Preferences\Drives\Drives.xml | Parse-Things
   • gc \dns_domain_name\Sysvol\dns_domain_name\Policies[group_policy_id]\Machine\Preferences\Registry\Registry.xml | Parse-Things

I'm pretty sure the technique works for all of the GPP files, but I haven't spent the time to actually flesh it out. I feel I like came across the technique in someone's code, but can't remember who. Regardless, below are a few relevant links.

https://technet.microsoft.com/en-us/library/dn581924.aspx http://www.jaapbrasser.com/tag/ldap-query/

PS: Nice work on all the shiny new toys! :)