Most of the time, if a web application gets compromised, we hear about vulnerabilities like cross site scripting or SQL injection being used to gain access. However, many high profile web application defacements don't need tools like sqlmap or BeEF. Instead, the attacker just logs in as an administrator. The log in may not necessarily use the web application at all, but it may affect the infrastructure the application relies on:

Operating System

It may be as easy as a default login to the system. A weak password, or a password collected via phishing. Your best defence in this case is to limit how many individuals have access to the system, to use non-password based authentication schemes (two-factor... ), and to restrict logins to trusted networks. Nobody should be able to log in to your server via ssh using nothing but a password from anywhere in the world. A missing patch apparently lead to the large OPM breach.

Cloud Admin Consoles (private or public)

Same as above. But sadly, also often overlooked. Many cloud providers will offer two factor authentication. And your backups should certainly not be hosted in the same "cloud" as the live systems. Private cloud admin interfaces are usually a bit easier to secure and isolate. But that doesn't mean it is actually done. I do see many papers about the latest Virtual Machine Escape technique. But the technique I see used in the wild the most is far less advanced: Log in to the admin console and download the server you are interested in compromising. "Secure" code hosting company Code Spaces no longer exists as a result of a breach of its Amazon cloud accounts.

Content Delivery Networks (CDNs)

Most large sites use CDNs to deal with traffic spikes, and to defend against common denial of service attacks. What else does an attacker need but credentials to log into the CDNs admin console to alter your site "at will". Did I mention two-factor authentication already? The Army.mil account has been attributed to a compromise of a CDN admin account.

Domain Name Registrars

This may be the most common route used to deface large, otherwise secure, web applications. But a defacement isn't what you should be scared about most. What about someone adding MX records and intercepting your e-mail? What about someone adding a record for "login.example.com" to use in a very plausible phishing attack? A lot has been written about DNS spoofing and cache poisoning. But why use a difficult technique like this if all you need to do is logging in. The list of recent attacks using this technique is rather long and includes household names like Craigslist, NY Times, Twitter and more.

---
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn