enumerating hosts

[wantafanta]

hello, i'm not sure where the issue with this lies - it may be me expecting somthing i shouldn't be.

i have the latest git (as of yesterday), installed in pipenv.

with CME, when doing cme smb 192.168.0.0/24 without providing credentials, it will connect to live hosts on that range and provide information.

SMB 192.168.0.3 445 HOSTNAME [*] Windows 6.3 Build 9600 x64 (name:CONSOTO) (domain:CONSOTO) (signing:False) (SMBv1:False)

if i try the same thing with ar3, ar3 enum 192.168.0.0/24 i only get the below

[] Lockout Tracker Using default lockout threshold: 3 [] Enum Authentication \ (Password: ****) (Hash: False)

unless i provide valid credentials for that host, then it does provide a similar output.

is this the expected behaviour? i also don't seem to be able to get --gen-relay-list to work no matter where i put the comand or if i provide a filename or not.

this app looks really good, giving a good test to see if i can integrate it into my workflow, so i'm hoping it is just me!

[m8sec]

Hi @wantafanta,

Thanks for the feedback and doing such extensive testing! As of now credentials are required for the most accurate results during network enumeration. This has to do with the setup of the SMB connection and when the host_info() method is called in smb.py. I agree, requiring credentials is not the best approach and I will put some time into make this more accurate.

As for the --gen-relay-list, this list is stored at ~/.ar3/workspaces/[workspace]/relay_list.txt. However, when going back and verifying this, I noticed a .csv extension on the file. I will correct this in the next push and allow users to define the file path + name: --gen-relay-list ar3_relaylist.txt.

Thanks again for your help and I will keep the issue open until some of these are addressed, - m8r0wn

[wantafanta]

thank you. ah i see, i didn't think to check in there for the output of the relay list. everything else i've tried seems to work as you would expect.

is there an equivilent to --lsa? i may have missed it.

[m8sec]

Okay, just did a pretty big push that will definitely need some q/a & refactoring but I was able to address:

• The --gen-relay-list issue which now requires users to specify the output file
• Made modifications to the SMB connection method to be more accurate w/o credentials
• & Added an LSA secrets dump feature to the enum operation.

Thanks again for your help! - m8r0wn

[wantafanta]

wow that was quick! i can see it now works without credentials, only its returning all ip addresses in a subnet that dont exist. so for a /24, i now get all 256 (includes .0 and .255) returned (albeit blank).

a redacted example below:

.. [] 192.168.0.79 192.168.0.79 ENUM (Domain: ) (Signing: False) (SMBv1: True)
[] CONSOTO 192.168.0.70 ENUM Windows 10.0 Build 18362 (Domain: ) (Signing: False) (SMBv1: False)
[] 192.168.0.0 192.168.0.0 ENUM (Domain: ) (Signing: False) (SMBv1: False)
[] 192.168.0.249 192.168.0.249 ENUM (Domain: ) (Signing: False) (SMBv1: False) ..

the --gen-relay-list is working to a file now, but i do wonder how it decides if it is relayable? the same command in CME returns different ips.

for example cme smb 192.168.0.3 --gen-relay-list ~/Desktop/cme-relay.txt returns that ip as relayable (it is) but ar3 enum 192.168.0.3 --gen-relay-list ~/Desktop/ar3-relay.txt is blank.

lsa secrets are dumping perfectly, i can see these are stored in ~/.ar3/workspaces/default/.secrets, where are the .sam creds stored? i see them in the database, but can't see them in a text file, is it possible to store them seperatly in a .sam alongside .secrets? unless they already are, i just can't see them!

forgive me, i am used them being stored in seperate files, with the host/time/date as the file name. makes it easier to know where its come from. it may be better to do it like this as its likely not to cause issues in the future with conflicting scans etc. not saying this is the only way, i'm sure there would be a better way to do it.

[m8sec]

@wantafanta,

Oh man thats not good! Just released some code to fix the enumeration issue and adjust output formatting a bit.

As for the relay issue, I wasn't able to recreate the blank file. This could've had something to do with the enumeration problem that was just corrected. I ran a quick test with the latest code and got the following results: AR3 and CME rely on the Impacket library to determine if SMB signing is enabled, this indicates if the host can be relayed, or not. Keep me posted if the issue continues and ill look into it further.

The sam files were not logged, just added to the database. However, I agree about logging and adding the host/timestamp to the filename. I have just added those features to the latest push. For those testing large environments regularly, I can see this being a bit log heavy, and defeating the purpose of the db, but we'll keep it for now and see what kinda feedback we get :)

- m8r0wn

[m8sec]

Correction on the --gen-relay-list blank file: The relay list output file, & log files for that matter, are initiated at run time to not cause errors when writing to a file that doesn't exist during enumeration. If no relay IP's are found the file will remain blank, otherwise, the IP collected during the SMB connection will be written. - m8r0wn

[wantafanta]

thats good, the terminal is only listing the devices that exist now 👍

the --gen-relay-list is still not being filled with the correct hosts - so i'm not sure about that. the hosts i'm testing it against are 100% vulnerable so it should really be listing them. i understand why it leaves a blank file regardless if there are any or not (now that you've said why), but i just can't get it to write the ip of the hosts that it should be writing. the only ip it lists on my network is the gateway ip - which isn't vulnerable.

the log files from both --sam and --lsa are spot on now 👍

[wantafanta]

it actually might be CME at fault here. hold fire. let me take a look and confirm it!

[wantafanta]

so i tried to figure out the best way determining where the issue lies.

i ran sudo nmap --script smb-security-mode.nse -p 445 <ip> to determine if the service has smb signing.

PORT STATE SERVICE 445/tcp open microsoft-ds

Host script results: | smb-security-mode: | account_used: guest | authentication_level: user | challengeresponse: supported | message_signing: disabled (dangerous, but default)

the output from nmap, cme and nessus agree, but the output from ar3 doesn't. i'm not sure whats going on. the terminal output from ar3 does list it as (signing: false), so i'm not sure why its not writing to the output file.

i have noticed that the domain that the device is on isn't always listed too. just returns blank unlike cme etc.

(Domain: )

[m8sec]

Ah okay, I may have found the issue with --gen-relay-list. It was too far down the chain and required authentication before execution. I added this into the host_info() method, which is executed before the authentication. Should be okay now but keep me posted!

As for the blank domain, I just checked CME, if no domain is found it reverts back to displaying the hostname. I though I had this setup for AR3 as well but it wasn't implemented correctly, should be fixed now though :)

Appreciate all the Q/A!

[wantafanta]

looks like its working now 👍

hostname is showing as the domain if it isn't found too - however, a side effect of this is on the left hand side where the hostname is shown its now showing up as [hostname].[hostname] - looks a bit weird. would it be better to just list it as (Domain: < none >) or something. not sure how this would effect workgroups etc. i guess if you can't enumerate its domain (local or not) it doesn't really impact anything.

[m8sec]

Okay I see what happened there, during commit "Issue #4 pt.4" we modified the get_hostname() method. Just corrected this now in pt.5.

I appreciate all your work on this! - m8r0wn