1β£ Brute mode: can be used with a user and password/hash to test (or list of those).
2β£ Smart mode: given a valid AD account credentials, it fetches the users list and lockout policies to bruteforce wihtout locking accounts.
Authentication attempts can be operated over NTLM (over SMB or LDAP) or Kerberos πΆ (pre-authentication attacks).
Kerberos pre-authentication attempts can be operated through UDP (faster π ) or TCP.
In the 1β£ brute mode, the first valid auth triggers a basic AD enum to find out if bruteforced accounts are members or privileged groups (can be disabled).
When attempting auths over NTLM over SMB (brute & smart modes), a test is made to assert if the account is local admin
The AD enum triggered in 1β£ brute mode is made right from the start in the 2β£ smart mode.
1β£ brute mode: when supplying user and password/hash lists, attempts can be made line per line instead of trying every password for each user (--line-per-line flag).
2β£ smart mode: user list or lockout policies can be printed without bruteforcing (--users, --policy flags)
1β£ brute and 2β£ smart modes: a --delay can be set between each attempt. There is a --user-as-password flag, which is self-explainatory imho.
When attempting auths, passwords can be tried, but hashes too (NT hashes for NTLM (PtH), RC4 keys for Kerberos(OPtH)). Reminder: RC4 key == NT hash.
When using the 2β£ smart mode, valid AD account's credentials are needed for the initial AD enums. That intial auth supports cleartext auth (NTLM, Kerberos) pass-the-hash (NTLM), pass-the-key/overpass-the-hash (Kerberos), pass-the-cache (type of pass-the-ticket) (Kerberos)
πΆ Kerberos pre-authentication attacks can be tailored to the user's desires. The etype to use in the AS_REQ can be chosen (RC4, AES128 or AES256) and the transport protocol too (UDP or TCP)
Bruteforced accounts can be set as owned in a neo4j database to be used with BloodHound. Users that are on a path to Domain Admin will be highlighted.
The tool supports multi-level verbosity (verbose, debug, and more...)
Smartbrute has been inspired by existing tools that partially do the work (sprayhound, kerbrute, pykerbrute, crackmapexec, impacket). There are blobs of code that have been heavily inspired (sometimes copy/pasta even) from those, so huge thanks to their contributors !
Impacket does most of the heavy lifting behind it. We merely adapted a few things to go deeper or faster.
β οΈ This tool is currently in an alpha state. In order to become more and more reliable, it needs to go through some more IRL testing and debugging, expect the unexpected for now π
The tool may be tedious to use at first (the tool is pretty complete, hence complex to use. Not complicated though, complex.). The following picture may help understand how to use it. Basically, the tool is built around a parsers and multiple subparsers.
β’ β’ β’
Missing some Tweet in this thread? You can try to
force a refresh
[thread] A lot of people since this finding are looking for a bit knowledge around that bug. Below is list of links that will help better understand this (attackers-side)
(infosec thread) one of my latest tweets was followed by some questions in my DMs. So let's answer those here and remind some conceptsπ
I'll talk about pass-the-hash, pass-the-ticket, pass-the-key, overpass-the-hash, pass-the-cache, silver and golden tickets π
Pass-the-Hash (1/4) : NTLM (LM, LMv2, NTLM or NTLMv2 depending on the version) is an authentication protocol used by Windows and AD-DS. Users have passwords, which are stored in a hashed format (LM or NT hash depending on the security settings and version).
Pass-the-Hash (2/4) : when authenticating to a remote service, the password hash is used to compute a ChallengeResponse. The LM hash is used for the LM version of the protocol while the NT hash is used for LMv2, NTLM and NTLMv2.
@podalirius_ and I made GPP Passwords great again. We wrote a Python script, using Impacket, to find and decrypt passwords in Group Policy Preferences, without having to mount the remote share π[a thread]