There is a wonderful web site, despair.com, who specializes in selling posters which parody those tacky ‘fly like an eagle' motivational prints that were once very popular. My personal favorite has a picture of a sinking ship with the caption ‘Mistakes – It could be that the purpose of your life is only to serve as a warning to others.'
Well, this year there have certainly been some mistakes. Let's just toll the bell and remember…
- The huge shipping company paralyzed for days after a malware attack took out almost their entire infrastructure. They were not alone; at least five or six other organizations were similarly affected. Their mistake; leaving an obsolete file access protocol enabled and sharing a common local account and password with admin privileges across their estate, allowing the malware to pivot with ease and blast everything to smithereens like Hurricane Irma.
- The accounting and consulting organization who had sensitive customer data exfiltrated on an industrial scale. Their mistake; not using two-factor authentication to secure critical administrator accounts.
- The credit reference organization that exposed nearly 150 million sensitive user details to unauthorised access. Their mistake; not patching a critical subsystem in their public-facing corporate internet infrastructure.
Cyberattacks represent a classic example of what the military call ‘asymmetrical warfare.' After the Brighton Hotel bombing, which very nearly succeeded in assassinating Margaret Thatcher, the IRA stated “Today we were unlucky but remember we only have to be lucky once.”
This is, of course, the nightmare that keeps CISOs awake at night. The unpatched vulnerability, the overlooked protocol enabled unnecessarily, the stolen mobile device with sensitive credentials, the employee who opens a malicious attachment – how do you defend against these?
Fortunately there are answers. Answers which – hopefully – will ensure you don't get to stare ruefully at a copy of ‘Mistakes' while creatively rewriting your CV.
Firstly, assume you WILL be successfully attacked. Your defenses WILL be breached. Many organizations have what I call ‘raw egg' perimeter defenses. That is, there's a relatively tough (yet fragile) shell but if you breach this, all is lost.
By assuming you will be breached, your focus should move to what the attacker can then do. Assume an attacker WILL gain full administrator access to a target device. Realistically, this isn't (hopefully) a critical infrastructure device such as a domain controller. These devices need an additional layer of security around them. But you can't fortify all your endpoints. So assume it'll be a public-facing web server, or perhaps an employee's computer, compromised by a phishing attack. These are realistic scenarios you should plan for.
At this point you need to understand the assets that your attacker has gained control of. There are two vulnerabilities intrinsic to Windows devices that reside in the system registry (and thus, cannot be protected – they are obfuscated, but this is no defense)
- The domain account names and hashes of the last ten people to log in to the device, using a domain login. These hashes can be cracked surprisingly easily to obtain plaintext credentials, which can then be used to attack other devices.
- For any service running on the device using domain credentials, the account name and plaintext password of the domain account that service is using.
Now the first of these is a consequence of domain account caching. On permanently-installed servers, you might want to consider whether you need this enabled – it's only necessary if you need to log on to the device using a domain account and the device has lost network connectivity. But if you use a secure mechanism for managing local accounts with administrator access (such as Microsoft LAPS) you can still regain control of the device even after a network card failure. So you could disable caching to eliminate this vulnerability entirely.
The second vulnerability can't be defended against directly. Even if you run services using local accounts, these local accounts reach out across the network in the context of the domain computer account and an attacker can recover the password for this account from the device registry.
What you need to do is think about what an attacker can do with these credentials. They can probably read (and write) critical databases that the service legitimately accesses, for example, if they can connect to these databases. So make it harder for them by ensuring all connection strings in configuration files are fully encrypted using the DPAPI subsystem.
This isn't a perfect defense; DPAPI can be cracked by a really sophisticated attacker, but you are putting barriers up. The attacker has credentials but they don't know the target devices on which those credentials are valid. If they attempt to use them elsewhere, your perimeter defenses should pick this up; accounts used by services should NEVER have interactive login privileges, for example.
Consider the use of Group Managed Service Accounts for service logins. These have a complex password which changes regularly. Yes, this password is in the registry but the actual account name itself isn't directly available to an attacker, making reuse of these credentials just that bit harder.
Of course, you're using trusted connections for everything, right – no accounts and passwords in plain text anywhere? Or if you are reaching out to a subsystem where this can't be done, you're storing sensitive credentials in the Windows Credential Store, I hope. These are then protected by DPAPI – not totally secure but much harder to crack.
Can your applications impose an extra layer of protection? Use HTTPS for all internal API communication, not HTTP. And use ‘shared secrets' to establish that the caller is a legitimate consumer. This ensures an attacker can't just use those stolen credentials directly.
Are you leaving yourself open to cyberattacks by not staying current with OS and application updates across your enterprise?
Finally, do you have tripwires set so that an attacker who DOES compromise an endpoint will be detected quickly? When anomalous access patterns are detected on an endpoint,
can you act quickly to ‘quarantine' the endpoint and ensure it cannot be the vector for further compromise, as well as preventing the exfiltration of sensitive information?
Ask your pentesters to pursue a scenario where they have, say, full admin access to a corporate web server that is publicly facing. Your defenses should be strong enough that even in this situation, it's difficult or impossible for an attacker to break out of that endpoint and do further damage.
What's more, you should be able to detect any attempt to exfiltrate data from that endpoint, or intercept traffic; public-facing endpoints should have locked-down whitelists for all allowable software and permanent monitoring using memory forensic tools to look for sneaky attacks via buffer overflows, dynamic DLL injection etc. Needless to say, they should run the most up-to-date version of Windows available and you should implement Credential Guard, Device Guard and of course Secure Boot.
For internal endpoints, the obvious attack vector is via a phishing attack. Apart from training staff never to open an attachment if they are in any way suspicious, you should also be very careful to ensure that account credentials gleaned by an attacker can't be exploited either. You might not be able to lock down these endpoints as securely as those which are public-facing, but you shouldn't be blasé about them either.
Have your pentesters explore a scenario where an attacker has full admin control of the endpoint and ensure that there's no easy mechanism for an attacker to “break out” of that endpoint and compromise other devices. Ensure that endpoints don't hold sensitive data; if this year's business plan is stored securely inside a cloud-based document retrieval system, then there isn't a locally-stored Word document for the attacker to sneak off with.
So plan for mistakes. Why not buy that poster and put it on the wall? Every morning, plan to ensure the purpose of your life is NOT to serve as a warning to others. That way, you'll be able to sleep at night, knowing your defenses have been battle-hardened, rather than hoping for the best.
