Open Viss opened 9 years ago
I have faced this situation as well. The smb_version module output shows both the hostname/ip address and domain but hosts command don't. To overcome this limitation in the meantime, you can use notes -S
@Viss Sometimes, we can find one domain for serval ips, and one ip for serval domain. Hosts command can help us to target domains with -S,
msf > hosts -m "rapid7.com" 54.68.205.61
msf > hosts -m "rapid7.com" 54.213.55.196
msf > hosts -m "dev.rapid7.com" 208.118.227.34
msf > hosts -S rapid7.com -R
so in this context, the customer I'm working on has something like 7 domains. Sadly (for them), they have multiple domains scattered about through /24's. That means 10.0.0.0/24 will have 3 domains in it and 10.0.1.0/24 will have 2. It would be easy to pair up 'known good domain creds' to a subnet block if they did it consistently, but in this case, if I want to, for the sake of theatrics, exploit every host in a domain, or run the webcam_list module on every host in a domain, I need to use specific domain creds - and to do that I have to know what machines are in what domain. It seems you can't really do that 'after the fact', enmasse.
being able to search 'by user' and 'by domain' would be super super handy, if targeting a single user or targeting a specific domain.
I added a line to one of these domains login script - so upon user login I get shells, which is rad, but unless i look at 'sessions' while the sessions are live, I have no record of what users I was able to compromise (if I'm targeting a specific user, or group of users)
The host:domain relationship is either 1:N or N:N depending on how you structure it. The "notes -S
Despite running multiple aux modules that grab the domain name, none appeared in the notes (I ran MOSTLY smb_version, and some smb_login here and there)
@Viss Got it, I think we can improve things with a small PR.
Our scanner modules do not store the SMB domain (smb_version), once this is fixed, notes -S <domain> -R
should be a viable solution.
Actually, this seems to work fine today:
msf auxiliary(smb_version) > notes -S WORKGROUP -t smb.fingerprint -R
[*] Time: 2015-08-31 21:45:10 UTC Note: host=192.168.254.103 service=smb port=445 protocol=tcp type=smb.fingerprint data={:native_os=>"Windows 10 Enterprise 10240", :native_lm=>"Windows 10 Enterprise 6.3", :os_edition=>"Enterprise", :os_build=>"10240", :SMBName=>"BEHEMOTH", :SMBDomain=>"WORKGROUP"}
RHOSTS => 192.168.254.103
I just went back to my environment left over from this last pentest to check. doing 'notes -S DOMAIN' matches the hostname as well as the domain, so if the companys domain is ABC and the workstation names are ABC2389asdf, it matches - however if the domain is XYZ and the hostname is ABC234asdf it still matches - so things get a bit muddled.
Also, it looks like the vast majority of hosts I was able to find came from mass-shelling via GPO modifications and less so from scanning, and when a new shell comes in it looks like no entries land in the db for the domain that host came from (or the username that was associated with the shell - this was an excercise in finding a specific user who ended up using citrix to access the domain, not a desktop)
@Viss Would something like this work?
msf> notes -S BIGCORPDOM -F domain -t smb.fingerprint
The difference being that -F
would limit matches to a sub-field.
yeah, being able to specifically search the domain field would be SUPER helpful (same goes for 'the username that initially rode the shell in' :D)
In pentests where customers have multiple domains (this client has 8) it would be super handy to be able to group hosts by domain, so that credentials could be re-used more easily.
Coincidentally, (and this should probably be a separate ask), it would be really nice to 'assign creds to a domain', so that things like psexec and other auth-based attacks would "just know" what creds to use when doing authenticated code execution.