top of page
Search
ital597

Password Problems Part 3: Device Implants & Breaches

Welcome back to IT Audit Lab’s Series on Password Security. In part two, we talked about the common attack strategy known as phishing. Phishing is a way for attackers to be able to trick you into doing tasks or services that reveal your private information. Following, we will explain several more common techniques threat actors use to collect passwords and personal information.

Method 2: Device Implants or Pivoting from a Previous Breach

Threat actors may gain initial access into a system through various methods. One common method is to implant a physical device on the target network that can be controlled remotely to gain additional access, run tools, and perform internal reconnaissance. While implanting a device requires physical access to the building, a small amount of social engineering and a purpose-built raspberry pi or other microcomputer can achieve the goal of covert network access in many cases. Another route into the network for these types of attacks is to begin with a phishing/social engineering campaign to gain initial access and utilize the breached account to run these tools.

In part one of this series, we discussed password reuse as a major concern for corporations as end users will reuse personal and corporate passwords so as to remember fewer passwords. Due to this common practice users whose personal accounts are part of data breaches could pose a security threat to the organization. If a user uses the same password for their CandyCrush account as they do for their corporate email, a breach of their CandyCrush account details like username and password could lead to a breach of the corporate email account and systems. Attackers will always get a username and password combination from one source and try to use it to authenticate other services and portals. As threat actors gather more information about users' employment, names, email addresses, passwords, the threat grows.

Author’s Note: Most modern organizations run Microsoft Windows as the default operating system as part of an Active Directory domain. So many of these attacks will be specific to collecting credentials from a valid AD Domain. Once inside the network, threat actors have many options at their disposal to collect credentials from within a typical windows active directory environment.

Open SMB Shares

One of the first places a threat actor will look for passwords is on open/accessible SMB Shares. Networked computers in most modern businesses will have shared drives, directories, and file-shares from which users collaborate on files or share business-pertinent information with one another. Samba (SMB) is the protocol used by Windows to share folders, network drives, and other locations within the Microsoft AD environment. When there is a breached account and the threat actor has access to the same SMB shares that that victim user has access to, the threat actor runs searches through the SMB shares and may run tools like SMBMap to discover all shares that the compromised account can access.

The threat actor will search SMB shares and files for strings like “password”, “pw”, “pass”, “words”, “accounts”, and other common naming conventions for files that contain passwords to see if the shares contain any additional passwords or authentication details for other accounts in the environment. While it may seem silly to some to store passwords on a computer system, research done by PassCamp found that nearly 40% of all organizations stored passwords in spreadsheets in clear text. The payoff of finding a treasure trove of clear text credentials is that further password attacks are not necessary, and the attacker can pivot, retain persistence within the environment, and potentially escalate privileges without further effort. While in the SMB shares the threat actor will also hunt for other secret information that they could leverage for personal gain like PCI, HIPAA, or tax return documents.

Responder.py

One piece of software attackers use to collect credentials is called responder. Responder is a Link-Local Multicast Name Resolution (LLMNR), NetBIOS Name Service (NBT-NS), and Multicast DNS (mDNS) poisoner as well as a LDAP, HTTP, HTTPS, WPAD, DCE-RPC, DNS, Browser, and DHCP Proxy Auth server. In short, responder listens on all protocols and places itself as a man-in-the-middle to collect hashes silently during standard authentication sessions on the network.

For example: John the accountant is navigating to a shared file system to collect payroll information for an end-of-year audit. This folder is password protected, but John has implicit access with his named account and Microsoft Windows account password. When John clicks on the folder, the file share needs to check to ensure that John is the correct account and that his hashed password matches the hashed password on file. In the background, John’s Windows machine sends the hashed password to the server hosting the files to prove that he is John and has the valid password.

However, if a threat actor is running responder in the environment, responder will notice the traffic and password hash being sent to the file-share server, will impersonate that server to collect John’s hash, and then allow that authentication to continue to occur on the correct server. John is able to access the files, the attacker has a password hash of John’s valid password, and no loss of service or notable drop-in response time was noticed by anyone as part of the transaction. This type of password hash collection works with all other protocols listed on the responder GitHub page.

Kerberoasting

Another method attackers utilize inside the network to collect account password hashes is a method called Kerberoasting. Kerberos is the authentication protocol used in Windows environments to authenticate users and provide shared services running on servers within a Windows Active Directory environment. Without going into too much detail, many Windows Active Directory Environments will utilize service accounts to run and provide applications, processes, and files to end-users within the environment. Since these service accounts are providing access to a server or specific files and processes on that server, that service account must be active, valid, and have an active password. These hashed passwords are stored in a TGS Ticket within the Active Directory environment. Smart attackers can use tools like Powershell Empire or Rubeus to dump these hashed passwords for service accounts, save them locally, and use offline tools like Hashcat or John the Ripper to crack them.

A successful Kerberoast collection relies on service accounts with valid passwords existing and providing services within the environment. However, a successful Kerberoast attack that leads to additional privilege escalation or lateral movement requires a weak service account password being used and that the service account have a higher level of privilege than the user performing the Kerberoast attack. Attackers will be looking for accounts that move them up the ladder in terms of access and privilege. Many service accounts fit this description as they often have high levels of privilege to interact with numerous computers and servers across the domain. If that service account is running an easily crack able password, the threat actor will take the hash offline, crack it, and use the cracked password to impersonate the service account and move laterally using the privileges of the trusted service account.

For a great writeup and explanation of how Kerberos functions and how Kerberoast abuses the trusts configured by Kerberos check out this article by our friends over at RedTeam Security.

Passwords Stored Locally on Machines:

Linux machines store hashed passwords in the /etc/shadow and sometimes in the /etc/password files within the operating system. Attackers with prior access to Linux systems and the required permissions can pull the hashed password from these locations and crack them to move laterally or elevate themselves to a higher privilege level. Likewise, administrative users on a Windows Domain controller can dump the ntdis.dit database which stores a password hash of all the authenticated users within the domain. Threat actors will then download and work on cracking the passwords offline for future use.

Both local machine password methods require an elevated account to execute, making these attacks useful for persistence but less useful for escalation of privilege or additional lateral movement capabilities. One final method that threat actors will leverage is pulling passwords directly from memory. Attacks like PowerMemory can remotely access the memory of Windows computers and pull password hashes or cleartext passwords directly from memory.

These examples outline just a few of the many methods by which threat actors will gain unauthorized access to account credentials. However, in many cases, these methods of collection will only provide access to the password hash: an obfuscated mathematical representation of the cleartext password. While hashes are useful in certain cases, most attackers are looking for the cleartext password in order to elevate privileges, run commands, move laterally, and maintain persistence within the target network.


In the next section of our blog series, we will cover the basics of what a hash is, how threat actors attack and crack hashes, and what they do with them once they have the cleartext value. Finally, in the last entry of this blog series on password security, we will cover some useful defenses to protect your passwords, secure storage and creation methods, and ways to stay ahead of the threat actors in the cat-and-mouse game of online security. If you need help addressing your organization's protections, contact us.


By: Kyle Rozendaal

Comments


bottom of page