Jul 13
Sorry but…..I’ve been seeing a lot of Covid-19 / Pandemic related words being used as passwords on internal tests recently. As a result the wordlist that should never have been needed…is here! covid2021-final.txt 173 MB file (50 MB .zip)
The Torrent wasnt working too well, so migrated to here: https://github.com/attackdebris/wordlists
sha1: 33b78622298a2cf2f59363a61cf6f6a4cb887e8a
Nov 19
Earlier in the year I was assessing a network that contained a Parallels Remote Application Server (RAS). Parallels RAS is a remote working solution that provides access to virtual desktops and applications. It can run on both Windows and Linux and is typically seen on the standard HTTPS port.
The platform has previously been affected vulnerable by a directory traversal flaw. The issue allowing remote, unauthenticated attackers to exploit the flaw to read arbitrary files from vulnerable systems (CVE-2017-9447).
In this scenario testing revealed that the RAS service was no longer vulnerable to the directory traversal flaw, the issue having been mitigated in RAS version 15.5 Update 4, released in September 2017.
However, an issue that appears to be related to the fix for this previous flaw was identified. Whilst it was no longer possible to retrieve/read files via the directory traversal flaw. It was found to be possible to determine if a file or folder was present on the remote RAS server by leveraging the same payload. This could be achieved via the different server responses received:
A HTTP 403 (Forbidden) response being received when a folder/file is present
A HTTP 404 (Not Found) response received when a files does not exist
In relation to a Windows installation it is possible to leverage this issue from an unauthenticated perspective to enumerate valid local Windows usernames, assuming they have a home directory on the target system. Once account names have been enumerated, they can obviously be subjected to password guessing attacks.
The following request is used to enumerate the “administrator” user. A HTTP “403 Forbidden” response from the server confirms the directory/user is present:
On the flip side the following HTTP request returns a HTTP “404 Not Found” which reveals the queried directory/user does not exist:
As a result of the above HTTP response discrepancies it is obviously possible to fuzz the username field to quickly enumerate any Windows users that may be present on the system.
Versions affected:
The original file directory traversal flaw CVE-2017-9447 was fixed in RAS version 15.5 Update 4, released in September 2017.
The file presence/username enumeration flaw discussed here, was fixed in RAS Version 17.1.2 released in July 2020. Ultimately as a result of a non-optimal fix this issue has been present for nearly 3-years.
Despite being in communication with the vendor, unhelpfully they opted to report the fix for this new 2020 flaw under the original 2017 CVE, which ultimately relates to an issue with a different impact.
Parallels Remote Application Server version 17 Release Notes
Release Notes snip below:
Timeline:
2nd June 2020 – Parallels Informed about the issue
15th July 2020 – Parallels released a patch
19th November 2020 – File presence/Username enumeration flaw publicly disclosed
I have created the following metasploit module to leverage this flaw, which will be pushed to the metasploit project in the coming days.
Here is the module in progress:
Here are the final results from the current wordlist:
The msf module can be downloaded from the link below:
Nov 16
SSLurry – A quick and dirty .nessus file parser to extract hosts/services affected by SSL related issues.
I’ve been testing on a large number of heavily populated internal subnets recently. Accurately reporting SSL protocol/cipher and certificate related issues can be time consuming in such scenarios, time that can be utilised more effectively identifying issues not reported by automated scanners and/or assessing more significant issues.
Due to the sheer size of some target environments our testing remit may only extend to identifying services affected by common SSL related failings rather than detailing the more granular issue e.g. report the services affected by expired certificates but don’t detail the valid before/after dates.
To save some time and sanity in dealing with this problem the python3 script sslslurry.py was born.
sslurry usage:
sslurry truncated output:
Obviously making use of sslurry should be caveated by the fact that the usual potential false positives reported by Nessus may still be present e.g. certificates being reported as untrusted even when signed by a trusted internal certificate authority.
sslurry can be found on github:
Dec 17
I’ve experienced a bit of trouble of late with both Empire and PoshC2_Python payloads failing to call back to their corresponding Empire and/or PoshC2 listener/server. This brief post detailing the fixes/workarounds I’ve used may be helpful to someone else.
I understand the issues are a result of the OpenSSL configuration in Kali Linux (The Kali build used here is up-to-date as of December 2018)
I’ll discuss Empire first, the following figure details my setup:
Once our Empire listener is up and running we attempt to run our PowerShell launcher on the victim. It fails silently, we receive no indication of why. However, capturing the session with Wireshark does indicate the source of the problem, namely a Protocol Version issue:
Alert (Level: Fatal, Description: Protocol Version)
Performing a quick sslscan reveals our Empire Listener only supports TLS 1.2:
It turns out we need to downgrade the TLS protocol support we’re using on our Empire listener. We can tweak this via the following file:
~/Empire/lib/listeners/http.py
We now need to find the following lines in http.py (from line 1146 onward in my case):
pyversion = sys.version_info # support any version of tls pyversion = sys.version_info if pyversion[0] == 2 and pyversion[1] == 7 and pyversion[2] >= 13: proto = ssl.PROTOCOL_TLS elif pyversion[0] >= 3: proto = ssl.PROTOCOL_TLS else: proto = ssl.PROTOCOL_SSLv23
Basically, we need to comment out 8 lines and add a single new line:
#pyversion = sys.version_info #support any version of tls #pyversion = sys.version_info #if pyversion[0] == 2 and pyversion[1] == 7 and pyversion[2] >= 13: # proto = ssl.PROTOCOL_TLS #elif pyversion[0] >= 3: # proto = ssl.PROTOCOL_TLS #else: # proto = ssl.PROTOCOL_SSLv23 proto = ssl.PROTOCOL_TLSv1
Once we’ve made the change, we need to restart Empire (assuming its running).
As can be seen below, as a result of the change our listener is now accepting TLS 1.0 connections:
As a result of our tweak, once a payload is run on our target/victim, Agents are successfully checking in once again:
As our PoshC2_Python server is also running on Kali it effectively suffers from the same issue.
We’ve already discussed the problem, seen the associated packet capture and sslscan data, so we’ll jump straight into the fix.
The fix is actually provided by the main PoshC2 developer @benpturner and is referenced here (but still needs to be made manually):
https://github.com/nettitude/PoshC2_Python/issues/13
Essentially we need to comment out 3 lines (lines 311, 312 & 313) in the following file:
/opt/PoshC2_Python/C2Server.py
Original content:
if (os.path.isfile("%sposh.crt" % ROOTDIR)) and (os.path.isfile("%sposh.key" % ROOTDIR)):
try:
httpd.socket = ssl.wrap_socket (httpd.socket, keyfile="%sposh.key" % ROOTDIR, certfile="%sposh.crt" % ROOTDIR, server_side=True, ssl_version=ssl.PROTOCOL_TLS)
except Exception as e:
httpd.socket = ssl.wrap_socket (httpd.socket, keyfile="%sposh.key" % ROOTDIR, certfile="%sposh.crt" % ROOTDIR, server_side=True, ssl_version=ssl.PROTOCOL_TLSv1)
# add this if required - https://github.com/nettitude/PoshC2_Python/issues/13
# httpd.socket = ssl.wrap_socket (httpd.socket, keyfile="%sposh.key" % ROOTDIR, certfile="%sposh.crt" % ROOTDIR, server_side=True, ssl_version=ssl.PROTOCOL_TLSv1)
Tweaked/commented content:
if (os.path.isfile("%sposh.crt" % ROOTDIR)) and (os.path.isfile("%sposh.key" % ROOTDIR)):
#try:
#httpd.socket = ssl.wrap_socket (httpd.socket, keyfile="%sposh.key" % ROOTDIR, certfile="%sposh.crt" % ROOTDIR, server_side=True, ssl_version=ssl.PROTOCOL_TLS)
#except Exception as e:
httpd.socket = ssl.wrap_socket (httpd.socket, keyfile="%sposh.key" % ROOTDIR, certfile="%sposh.crt" % ROOTDIR, server_side=True, ssl_version=ssl.PROTOCOL_TLSv1)
# add this if required - https://github.com/nettitude/PoshC2_Python/issues/13
# httpd.socket = ssl.wrap_socket (httpd.socket, keyfile="%sposh.key" % ROOTDIR, certfile="%sposh.crt" % ROOTDIR, server_side=True, ssl_version=ssl.PROTOCOL_TLSv1)
As can be seen below, once the PoshC2 server is restarted we now have TLS 1.0 support:
We’re now able to successfully receive the agent connection from our target victim:
Feb 03
You have recovered Domain User credentials for a domain but have no privileged or interactive access to any targets i.e. no Domain Admin account or any account that is capable of establishing an RDP session.
On a recent engagement I was performing an internal assessment against several untrusted Windows domains. Using Kerberos Domain Username Enumeration and subsequently performing SMB password guessing it was possible to achieve access to a number of Domain accounts.
However, it transpired that none of the identified credential sets were privileged e.g. they were not Domain Admin and additionally, none of the accounts were members of the “Remote Desktop Users” group. As a result, no interactive access to any of the target hosts was possible.
A number of different techniques exist to query Active Directory using low privileged accounts (i.e. a domain user) from our non-domain joined pentest laptop and I will discuss a few options for doing this in this post.
The ultimate goal of this enumeration is to:
Once this enumeration is complete accounts can be subject to further password guessing attempts.
The domain user credentials used in the following examples are username = ops, password = Pa55word
The first of the tools I will discuss is windapsearch:
As the tool’s author describes: “windapsearch is a Python script to help enumerate users, groups and computers from a Windows domain through LDAP queries”
Using our prerequisite/previously guessed domain user account the following syntax can be used to query the remote domain for all users within the domain:
windapsearch --dc-ip [IP_ADDRESS] -u [DOMAIN]\\USERNAME -p [PASSWORD] -U
The following figure shows the tool enumerating all users in the domain (-U switch):
NOTE: Output has been cleaned up a little with grep & cut
windapsearch --dc-ip 192.168.5.1 -u mydomain\\ops -p Pa55word -U | grep cn: | cut -d " " -f 2
Using the --da switch we can also enumerate Domain Admins:
windapsearch –dc-ip 192.168.5.1 -u mydomain\\ops -p Pa55word --da | grep cn: | cut -d " " -f 2
Using the -m switch we can enumerate members of the “Remote Desktop Users” group:
windapsearch --dc-ip 192.168.5.1 -u mydomain\\ops -p Pa55word -m "Remote Desktop Users" | grep CN=
The excellent PowerView from harmj0y probably offers us the best options for AD enumeration in our Domain User / non-Domain joined context.
PowerView is thoroughly and eloquently discussed in harmj0y’s multiple blog posts (see references), but I’ll just discuss a couple of options that can be useful in our scenario.
Initially, we establish a PowerShell session on our non-domain joined Windows host using runas and /netonly i.e. credentials are specified for remote access only:
runas /netonly /user:mydomain\op powershell (we are subsequently prompted for the password):
Note: I’ve already installed PowerSploit (which provides PowerView) in the following path:
C:\Windows\System32\WindowsPowerShell\v1.0\Modules\PowerSploit-dev
Once we have imported PowerSploit via:
Import-module .\PowerSploit.psd1
We can query the domain for all domain users:
Get-DomainUser -Domain mydomain.test -DomainController 192.168.5.1 | findstr samaccountname
We can also query the domain for a list of Domain Admins:
Get-DomainGroupMember -identity "Domain Admins" -Domain mydomain.test -DomainController 192.168.5.1 | findstr MemberName
Next we query the domain for the members of the “Remote Desktop Users” group:
Get-DomainGroupMember -identity "Remote Desktop Users" -Domain mydomain.test -DomainController 192.168.5.1 | findstr MemberName
We can also query AD for a list of all available shares that our current user context is able to access:
Find-DomainShare -CheckShareAccess -Domain mydomain.test -DomainController 192.168.5.1
Microsoft RSAT is designed to allow administrators to manage Windows Servers from a remote computer. RSAT provides another option for us to enumerate domains from our low privileged, non-connected domain context:
Initially, RSAT proves useful for the enumeration of the remote Window Domain’s password policy. Again, we do this from a runas, /netonly initiated PowerShell session (see PowerView above for details):
Get-ADDefaultDomainPasswordPolicy -Server 192.1685.5.1
We are also able to utilise RSAT from a GUI perspective, again this is initiated via runas:
runas /netonly /user:mydomain\ops mmc
Next we add “Active Directory Users and Computers” via the new mmc console:
Changing the Domain Controller instance to our target:
We are then able to gain a graphical view of the Domain’s user community:
The whole purpose behind this Domain enumeration is to provide us with further and more privileged accounts to target from a password guessing perspective. The retrieval of the Domain’s password policy obviously also complements this exercise.
Jan 18
I haven’t seen too much detail around about how to crack Cisco ASA PBKDF2 (Password-Based Key Derivation Function 2) SHA-512 hashes, which I believe have been supported in some ASA versions from as early as March 2016.
As always the hashes can be recovered from the appropriate Cisco ASA config file.
Here are some examples of how the hashes can appear in the ASA config files. In the examples below all 3 sample hashes can be easily cracked using any respectable word-list:
enable password $sha512$5000$vlCP+V07DGEJ9TcSV/GpuA==$2S8SLoECmbtb/o17ZhXuKg== pbkdf2 username admin password $sha512$5000$SvZkzlRDO115YrLXsZuWCg==$Yu0w7sFjhLnbtZQJ/nyp+A== pbkdf2 privilege 15 username admin password $sha512$5000$OZ45Ro7002bnyFGXlIghqg==$T9oP1zKSTmv74Nizd8ku3A== pbkdf2 privilege 15
Some modification of the hashes is required before they can be imported into hashcat. Basically the first $ needs to be removed and all subsequent $’s need to be replaced with colons.
For example:
$sha512$5000$SvZkzlRDO115YrLXsZuWCg==$Yu0w7sFjhLnbtZQJ/nyp+A==
Becomes:
sha512:5000:SvZkzlRDO115YrLXsZuWCg==:Yu0w7sFjhLnbtZQJ/nyp+A==
This hash can now be fed into hashcat as a single:
hashcat64.exe -m 12100 sha512:5000:SvZkzlRDO115YrLXsZuWCg==:Yu0w7sFjhLnbtZQJ/nyp+A== c:\Tools\wordlists\pw_topten.txt
Or via a file:
hashcat64.exe -m 12100 sha512.txt c:\Tools\wordlists\pw_topten.txt
Cracked hashes:
sha512:5000:vlCP+V07DGEJ9TcSV/GpuA==:2S8SLoECmbtb/o17ZhXuKg==: (i.e. blank) sha512:5000:SvZkzlRDO115YrLXsZuWCg==:Yu0w7sFjhLnbtZQJ/nyp+A==:cisco
I leave the final hash (below) to be cracked as a challenge for the reader (it can be cracked with any respectable word-list):
$sha512$5000$OZ45Ro7002bnyFGXlIghqg==$T9oP1zKSTmv74Nizd8ku3A==
Thanks to my colleague Marius for the initial pointer on the hash type.
Jun 26
Kerberos Username Enumeration – Username Wordlists
I’ve been having a fair bit of joy with the auxiliary/gather/kerberos_enumusers metasploit module on internal engagements, however you do need to provide the module with a good quality username wordlist or wordlists.
On a recent engagement, using only the top 50 male and female userlists, I was able to guess 70 domain accounts from a possible 400, and of course several of them were found to be configured with the obligatory easily guessed password.
Most domains I see tend to leverage some form of firstname, surname combination for domain user usernames. For example:
[Firstname].[surname] e.g: JACK.SMITH
[Firstname, First Letter].[Surname] e.g. J.SMITH
To that end I have created some username lists that are likely to identify valid usernames when targeting large Windows domains. The lists are compiled from the top 500 most common firstname and surname as per the United Kingdom’s Office for National Statistics (ONS).
Initially, you will want to run a tool such as Responder which will help you determine the format for usernames within the target environment e.g. L.FOWLER or LIAM.FOWLER. Indeed, I typically conduct this username enumeration exercise whilst Responder is running in the background.
Once the format has been identified and assuming the format is used universally throughout the domain, Kerberos username enumeration can begin.
The username lists I have created can be seen in the table below. I have also included the raw firstnames and surnames lists should you need to create a custom format:
| Username List | Word Count | File Size | Example |
|---|---|---|---|
| Top 500 Female Firstnames | 500 | 4K | AMELIA |
| Top 500 Male First Names | 500 | 4K | JACK |
| Top 500 Surnames | 500 | 4K | SMITH |
| Top 50 Female Firstnames.Surnames | 25000 | 330K | AMELIA.SMITH |
| Top 50 Male Firstnames.Surnames | 31000 | 400K | JACK.SMITH |
| A-Z.Surnames | 13000 | 116K | A.SMITH to Z.LEONARD |
| A.Surnames | 500 | 5K | A.SMITH |
| B.Surnames | 500 | 5K | B.SMITH |
| C.Surnames etc. | 500 | 5K | C.SMITH |
| Z.Surnames | 500 | 5K | Z.WYATT |
Note: All of the username wordlists (A.Surname through to Z.Surname) can be downloaded from: https://github.com/attackdebris/kerberos_enum_userlists
Attack Walkthrough
I’ll now walk through the complete attack process:
Initially we configure msf module auxiliary/gather/kerberos_enumusers with our wordlist:
We subsequently run the module. We’re obviously going to have a lot of failures but with no account lockout to worry about it doesn’t matter:
Running “creds” displays all of the successfully enumerated usernames:
The final stage is to leverage the auxiliary/scanner/smb/smb_login msf module to determine if any of our identified accounts are configured with weak passwords:
Obviously, the domain’s account lockout policy should be taken into consideration when attempting to guess passwords. A sensible approach is to attempt a single password at a time, restricting yourself to 2 guesses (system set to lockout after 3 invalid attempts) or 4 guesses (system set to lockout after 5 invalid attempts) against a single account every 30-minutes. 30 minutes is a typical “lockout observation window“.
Handily the auxiliary/scanner/smb/smb_login msf module’s “ABORT_ON_LOCKOUT” option will prevent too much damage being done, as long as it is enabled.
Jun 23
Auto-sslscan
As I mentioned in the previous post whilst Nessus and Nmap do a reasonable job of enumerating SSL protocols and ciphers I often find myself utilising other 3rd party SSL scanning tools. One I find myself turning to on a regular basis is sslscan, I like the output it provides and issues become immediately apparent, although if you prefer using SSL scanning tool X or Y, the auto-sslscan code can be easily amended to cater for your tool of choice.
Auto-sslscan is a python script designed to automate the process of conducting ssl scanning via sslcan. The Auto-sslscan script parses an nmap.xml output file, extracts all SSL services and automatically performs an sslscan of them.
Step 1 – Create a valid nmap .xml file:
Note: Some form of Nmap version scanning must be utilised to create the XML ouput i.e. -sV or -A (In order to determine whether the service is SSL enabled)
Step 2 – Process the Nmap XML file with auto-sslscan.py:
SSL Services:
That’s effectively job done, we now have a list of SSL services if we wish to target them again with another tool:
SSL Scan Ouput:
The actual SSL scanning “sslscan” ouput is saved to a concatenated file (truncated image below):
The code and installation instructions can be found here: https://github.com/attackdebris/auto-sslscan
Also check out nmap-ssl-parser, which simply parses the nmap XML file and provides a list of SSL services: https://github.com/attackdebris/nmap-ssl-parser
Credit – The base code I used to create nmap-ssl-parser: https://github.com/DanMcInerney/nmap-parser/blob/master/nmap-parser.py
Jun 23
Nmap-ssl-parser
Nessus and Nmap both do a decent job of enumerating supported SSL protocols and ciphers from remote servers. However, I usually find myself also utilising other 3rd party SSL scanning tools. To that end I wanted an easy way to quickly parse out SSL services to an output file for input into other tools.
Nmap-ssl-parser is a python script designed to query nmap XML output and provide a list of usable ssl services in the format host:port
The nmap-ssl-parser script parses an nmap.xml output file, extracts all SSL services and writes them to a filename of your choice.
Step 1 – Create a valid nmap .xml file:
Note: Some form of Nmap version scanning must be utilised to create the XML ouput i.e. -sV or -A (In order to determine whether the service is SSL enabled)
Step 2 – Parse the nmap .xml file with nmap-ssl-parser.py:
That’s effectively job done, as can be seen below our output file “my_output_file.txt” contains our host:port formatted list ready for importing into any other tool of choice:
The code and installation instructions can be found here: https://github.com/attackdebris/nmap-ssl-parser
Also check out auto-sslscan, which takes this process a step further by automating sslscans from the parsed list of SSL services: https://github.com/attackdebris/auto-sslscan
Credit – The base code I used to create nmap-ssl-parser: https://github.com/DanMcInerney/nmap-parser/blob/master/nmap-parser.py
Nov 09
Kerberos Domain Username Enumeration
Over recent years enumerating valid operating system level user names from up-to-date and well-maintained Windows environments, even from an internal test perspective, has become increasingly unlikely. Where RID cycling once provided us with a full list of domain users from an unauthenticated perspective, this is generally no longer the case.
However, in relation to internal assessments the Kerberos service (88/tcp) still provides us with a happy hunting ground in relation to the ability to enumerate domain account names.
Essentially the username enumeration is leveraged via the following Kerberos error codes:
| User Status | Kerberos Error |
| Present / Enabled | KDC_ERR_PREAUTH_REQUIRED – Additional pre-authentication required |
| Locked / Disabled | KDC_ERR_CLIENT_REVOKED – Clients credentials have been revoked |
| Does not exist | KDC_ERR_C_PRINCIPAL_UNKNOWN – Client not found in Kerberos database |
Several good tools, which have been around for some time, have provided us with the ability to leverage these Kerberos responses to identify valid or invalid domain accounts.
Both of the tools I have been leveraging up until now have both been provided by Patrik Karlsson, the first is the standalone Java tool Krbguess, the second being the krb5-enum-users NSE script for nmap.
Krbguess
Usage:
Java –jar kerbguess.jar –r [domain] –d [user list] –s [DC IP]
Nmap krb5-enum-users NSE Script
Usage:
Nmap –p 88 –script-args krb5-enum-users.realm=’[domain]’,userdb=[user list] [DC IP]
Metasploit Module: auxiliary/gather/kerberos_enumusers
Like most penetration testers I’m a heavy user of the Metasploit Framework and for years have thought I would like to be able to leverage this functionality from within the framework. For whatever reason it never seems to have been implemented, thus I decided to have a go at implementing it.
Leaning heavily on the Kerberos support provided by other Metasploit contributors and using the auxiliary module for ms14_068_kerberos_checksum as a template the process was actually a lot simpler than I had anticipated.
The new Metasploit auxiliary module can be found in the following location:
auxiliary/gather/kerberos_enumusers
As with the previously discussed Kerberos enumeration tools, 3 values need to be provided:
The module can now be run to enumerate valid (and disabled/locked) domain accounts via the Kerberos service:
Finally, and thanks to an addition by bwatter-r7 at rapid7, any valid enumerated usernames are stored in the Metasploit database and can be retrieved via the ‘creds’ command:
References:
http://www.cqure.net/wp/tools/password-recovery/krbguess/
https://nmap.org/nsedoc/scripts/krb5-enum-users.html
https://www.rapid7.com/db/modules/auxiliary/admin/kerberos/ms14_068_kerberos_checksum