One of the most important parts of a penetration test is to take a step back afterwards and look at the big picture. What were the root causes that allowed the compromise to take place? How can the system be better protected against such attacks in the future? In closing this series, we will show you how to address the specific security issues that allowed our attack to succeed, divided into three main categories: initial exploit, escalation, and data security.

This is the last entry in a series of six blog posts; the previous post was Part 5: Data Exfiltration.

After expanding our access to include complete administrative control over the server and database, the last step was to look for interesting/valuable data and figure out stealthy exfiltration methods. However, since this was only a penetration test, not a real-world break-in, there are some important differences in how far to take this part of the attack.

This is Part 5 in a series of six blog posts; the previous post was Part 4: Expanding Access.

Having found a way into the server, we were ready to explore the system and find ways to expand our access. We started with some general reconnaissance of the server, followed by a more targeted analysis of the main web application. This eventually resulted in full access to the MySQL database as well as administrative access to the entire server via secure shell (SSH).

This is Part 4 in a series of six blog posts; the previous post was Part 3: Gaining Access.

General Server Reconnaissance

After gathering as much information as possible in the reconnaissance phase, it was now time to find a way of breaking into the target server. Typically, the most promising angle of attack is third-party toolkits that are often outdated and most likely have some published vulnerabilities available. In most cases, such vulnerable toolkits provide an easy way for an attacker to get in. This way, he doesn't have to spend a large amount of time and effort analyzing and reverse-engineering the custom-written code that often powers the main web application.

This is Part 3 in a series of six blog posts; the previous post was Part 2: Recon and Scanning.

Before an attacker can start trying to break into a system, he first needs a deep understanding of the system and its components. This reconnaissance phase can be divided into three main parts: basic server reconnaissance, service-specific scanning, and manual follow-up to scan results.

This is Part 2 in a series of six blog posts; the previous post was Part 1: Introduction. 

You’ve heard of countless website and database breaches—and you’ve probably asked yourself how the attackers were able to get in. In many cases, minor vulnerabilities can be exploited to extend the attacker’s foothold and eventually compromise the entire server.

In this six-part blog series, we will walk you through the process of completely compromising a target server on a recent web application penetration test. It all started with a single input validation flaw in a third-party toolkit and ended with us getting full administrator-level access to the server and database.

This post continues my 12-part series about the Software Assurance Maturity Model (SAMM). Today we will be talking about Design Review, the first security practice in the Verification function.

The Design Review (also called Architecture Review) is a crucial milestone in the software assurance lifecycle, providing an opportunity to spot major high-level issues early in the process when they are still relatively inexpensive to fix. It is typically conducted by security-savvy staff who are either on the project team (for large projects) or in conjunction with the project architect(s) on smaller teams.

First Maturity Level

This post continues my 12-part series about the Software Assurance Maturity Model (SAMM). Today we will be talking about Secure Architecture, the third and final security practice in the Construction function. Starting with this post, I am also changing the title naming convention to refer more generally to "software assurance" rather than "secure development." Software assurance is an industry-standard term and encompasses the full spectrum of software security activities across an organization.