The remediation activities being discussed with Jim Aldridge here include massive password change, software patching, and building security posture overall.
– One of the most critical and difficult parts in remediation is universal password change. Do you have short advice to help organizations with that?
– In short, it is important to understand the purpose of each account. With this understanding, it is typically straightforward to plan for how you would change the password for that account. This doesn’t make it easy necessarily, it merely provides you the information that you need to plan the change.
This presents significant difficulties in large organizations, with dozens to hundreds of service and application accounts, that have never considered the prospect of a massive password change. I advise my clients to plan for how they would execute an enterprise-wide password change as a routine incident response preparation activity.
While gathering the information necessary to do so, it is also beneficial to consider deploying a password vault tool. In addition to making it easier to quickly change passwords, such tools can make it more difficult for an attacker to obtain credentials.
– What are the next most difficult steps, maybe patching / updating software?
– Patching, particularly patching third-party desktop applications, is difficult. In my experience, the main reason for this is that some software requires legacy versions of these desktop applications to function. For example, if the company’s time and expense system requires an old version of Java, that makes it difficult to upgrade users’ systems without impacting important functionality.
Another difficult step, that is typically a longer-term activity, is removing privileges from end users. What I mean by this is that users will not be “local administrators” on their workstations. This has tremendous benefits across multiple phases of the attack lifecycle. The exploit that causes the initial compromise may work, but the attacker may be unable to establish a foothold because the backdoor won’t install. Not all backdoors require privileges, though, so perhaps the backdoor installs. But without local administrator privileges, the attacker can’t easily run the password hash dumping tool. So then the attacker would need to find a local privilege escalation vulnerability to exploit, or look around the network for vulnerabilities while operating in the context of an unprivileged user account.– After a targeted intrusion, do most organizations start rethinking security and implementing strategic changes? Are there some organizations that stop just after eradicating the threat?
– I would say that most organizations do start rethinking their security posture, to various degrees. Some stop after eradication.
– How often do the same attackers come back? Do attackers follow the pattern after they have been eradicated and use the same tools, techniques, procedures; or do they start from scratch and try to act differently?
– That depends on the attackers’ motivations. Attackers that are motivated by espionage tend to return, using some combination of old and new tools. It’s not always possible for them to completely change things up; tools and command-and-control infrastructures take effort to maintain. The more sophisticated actors change more about their TTPs, the less sophisticated ones try what they know worked last time.
– How to define new indicators of intrusions if the attacker acts differently?
– By looking for the activities that are common to the various phases of the lifecycle, plus applying threat-specific intelligence, then following a solid investigative process to develop an understanding of the new indicators.
– What do you think of honeypots as a protection mechanism which gives good return on investment? Do you use them?
– Honeypots can be interesting in some research scenarios, for example tracking certain automated threats. If you’re worried about targeted threats, the time that you spend building a honeypot infrastructure is time that you could have spent on something more fundamental. Unless you have already implemented extensive countermeasures, I view most honeypot deployment scenarios as diversions.
Diversions that detract organizations from addressing the fundamentals of detecting, inhibiting, and responding to the attack lifecycle are one reason why organizations are generally unprepared for this type of threat.
– Could you please give an example and describe a specific success story of quick remediation after a deep intrusion?
– Here’s a typical example: an organization contacted us because they had identified signs of targeted threat activity. Our investigation revealed that the attacker had initially gained access to the environment around two years prior to the organization’s discovering the attack. Over the course of around 6 weeks, we investigated and worked with them to develop a remediation plan. During this posturing phase, they implemented enhancements like better security log settings, some log centralization and searching capabilities, and determined how they would change passwords.
The attacker had already stolen sensitive information, and was operating in a maintenance mode – he would connect to the environment around every month. He would then dump password hashes from a domain controller (the administrators reset their passwords monthly, so the attacker came back to get the new ones every month). Next he would double check that his backdoors were all installed and functioning. Finally he would check to make sure that he still had valid passwords for a couple of service accounts, which did not get new passwords monthly.
The organization initiated their “remediation event” plan on a Friday evening, disconnected certain networks from the Internet, and pulled the infected systems. Then they began to reset passwords. This went more quickly than they had hoped, due to their preparation, and they had completed the critical containment and eradication activities by around noon on Saturday morning.