Recently, I received a call from a former colleague. They were concerned about some odd alerts they repeatedly saw across the enterprise. These alerts suggested that an outside actor may have obtained a service account credential in hopes of gaining access to other accounts. They were having issues hunting down the offending origin of the account authentication requests due to some gaps in their auditing capabilities and asked for my view. I’m not sure how others spend their Saturdays, but this challenge is right up my alley!

Password fatigue and an unsigned script

After an NDA and approval, they provided access to the logs and eventually their environment for my review. Noting the originating systems, I found that one of the systems was an administrator’s workstation. Upon further review, I quickly located an unsigned script that the administrator was running via scheduled tasks with the service account credentials and with elevated privileges on the system. The script seemed to be the administrator’s effort to automate daily tasks.

A lot of incidents are born out of similar circumstances, as convenience is a huge driver of behavior. Change control processes are often subverted, documentation foregone, and poor implementations misconfigured in the name of convenience.

Unfortunately, this administrator’s actions led to more issues. In this instance, they would log onto the workstation with their privileged account and launch processes with their regular account. Further, after pulling the password hashes, I realized that the administrator was using the same password for both their regular and privileged accounts — a common response to password fatigue. The administrator was also accessing and using service and shared local accounts.

In this case, I noted a rogue process that was established on the workstation and was performing callbacks, network scans, and Active Directory reconnaissance while also attempting to gain access to enterprise servers and services. The process attached itself to the scheduled task mentioned above.

The solution

First, their team gathered all of the forensic and live data they could about the systems. Then, I quarantined the administrator workstation, disabled the account, and documented IOCs for the network team to track. All of these steps were performed from a forensic workstation with notes kept electronically. Being mindful of chain of custody, data integrity, and ensuring proper investigative techniques is incredibly important in any incident review.

To address the underlying issues, there are multiple steps and considerations to be taken.

Separation of duties

An administrator should not use a privileged account to log into a windows system and then perform non-privileged tasks such as web research — even when launching the process with a different account. Administrative escalation should be temporary and only as needed to perform a task.

MFA

Consider implementing MFA capabilities. PKI certificate-based authentication is common in Windows domains. Require all scripts to be signed with a valid certificate.

Service account management

Service accounts should not be utilized by human agents unless absolutely necessary. These accounts should be created with less-privileged principles:

• Create an account that has only the necessary privileges to perform required duties
• Follow a specified naming convention for account creation, i.e. “s-exchange” or “srv-exchange”
• Ensure service accounts are protected adequately in Active Directory
• Ensure service accounts are audited routinely
• Ensure the passwords for highly-privileged service accounts are protected
• Consider utilizing a service account password manager/vault. This will reduce administrative overhead in password changes and ensure accountability with the passwords being “checked out” by an administrator and therefore logged

Shared account management

Local accounts should not be shared, as shared accounts lack accountability. These accounts should be protected with their passwords, kept highly secured, and checked out only if required.

Network segmentation

Assess network layout to verify proper segmentation is in place with appropriate firewalls configured, ensuring desired traffic flow and protection between highly-secure and less-secure networks.

Password management

Ensure policies are conducive to avoiding password fatigue and poor password-hygiene tendencies, such as using a predictable pattern to set the password or using the same password across multiple accounts — i.e. FallSeason2022!! This is especially important for Windows systems given the lack of salt on password hashes.

Active Directory security

Review AD security. Authenticated user groups allow any authenticated entity to read from the entire AD database unless it is purposefully removed. This process can seem scary and immense but yields a lot of security benefits.

Task Scheduler

Consider the merits of retaining the task scheduler functionality. In most enterprises, the task scheduler can be disabled with little impact.

Audit

As always, ensure all new processes are brought under compliance audit review for routine assessment checks.

Administrative tasks

Review the current administrative tasks that the user was attempting to perform via the task scheduler. If there is a need for an automated capability to perform the task, architect it in a manner consistent with enterprise risk tolerance and security compliance.

Training

This is the most important piece! Even with all the technical controls above being implemented, the human element must be addressed. A highly-engaging security training routine is imperative to addressing the human risk of an environment.

Keeping service accounts secure

I’m still impressed with the security analyst that flagged the events as suspicious without even realizing why they stood out to them. It’s not uncommon for these types of events to exist for a long time on networks, whether malicious in nature or not. For example, there could be a service running on 20 different servers with only one server having a misconfigured password, meaning the login failures would be few and far between and would potentially seem like a user mistype.

Service accounts should be audited with a more suspicious eye than regular user accounts. These accounts should not be used by individuals and their passwords should be stored securely by anything leveraging them. Password failure logs should be considered highly suspicious, as they can indicate compromise attempts or failures in authentication services. Or maybe one of the domain controllers has a corrupted database and is not able to authenticate properly, so the return is a failure when that specific domain controller is utilized.

I’m not sure what the fate of the administrator was in this case. I don’t know if they were of high standing in the company or if their employment was continued. I do know that it is not uncommon to see administrators implementing mitigations that are not consistent with good cyber hygiene, especially in less cybersecurity-mature shops.

In this case, the change approval process for administrative tasks was one friend approving another friend’s request. They have worked in the same office for over 6 years. Before working at this company, they both worked together at another company. This is obviously worrisome for many reasons but is not uncommon. It’s a telling example of how good intentions (having an established change process) implemented with improper configurations (friends approving requests without fully questioning/investigating) can result in an adverse outcome.

Until next time, friends! Keep secure and carry on!