Kicking in the Door - Analyzing Tactics to Establish a Foothold

Last time we examined the reconnaissance phase or as I like to describe it, the boring phase <yawn>. It’s time to put our 1337 skills to the test, throw some sploits, and pwn some noobs. Today we will be continuing our journey through the hacker methodology and examining the ‘establishing a foothold’ phase.



As with all of the tactical engagements we describe on this blog we are going to establish an end state. We intend to gain a foothold on adversary infrastructure that we can leverage to escalate privileges and gain dominance over the plebeians who couldn’t hack it, the blue team. This will build toward our end goal that we established with our customer, whether that be data compromise or denial of service effects.

Status of Forces

During our reconnaissance phase we established a solid baseline for the current status of forces. We took a look at our adversary’s defensive layout and have a good idea of where the defensive emplacements are. Our customer/adversary’s defense consists of a firewall, a proxy server, and for the sake of a realistic scenario we will say we found indicators of a host based anti-malware program on their forward facing web server. When I say ‘realistic’ what I mean is, what the customer should be doing, not what the customer usually does, which is install the network in the 1990s and slowly but surely fire any person with any competence over the years. The only soft targets we were able to pick up behind the defensive devices are a web server, a DNS server, and a mail server inside the DMZ. The rest of the customers IP space is in their internal network and is scanning is blocked by the firewall.

Initial Tactical Engagement

Our Initial tactical engagement will include examining the vulnerabilities of the soft targets we discovered during the reconnaissance phase. We will take a closer look at 3 vulnerabilities, a web application that has a command execution flaw, a mail server with which we can send phishing emails, and an unpatched DNS server.

We will start with the web application that has a command execution flaw. That seems like the easiest route, open a web browser, type in ‘net user pentest pentest /add’, jackpot, right? As it turns out, the reason the customer allowed this unpatched vulnerability to exist was that it requires a valid user log in to exploit. As with all bumps in the road we just need to try a little harder. We examined the customer employee LinkedIn profiles during the reconnaissance phase and we were able to get a good feel for the log in user names based on workplace emails we collected. Also, we will exploit a layer 8 vulnerability called the ‘user’ during this phase. Many ‘users’ have a crippling flaw where their memory stack gets exhausted and they reuse passwords. Some enterprising go getters have done a lot of the leg work and breached various companies through the years and posted usernames, emails, passwords, and password hashes throughout the internet. We can cross reference a few databases (Linkedin username

and password dump: and build a pretty solid list of username and passwords to try out against this web application. With this information we are able to intelligently brute force credentials and log into the web application, run the command execution, and add an unprivileged user to the server. Foothold established!

Next, we are going to move on to the mail server and send some phishing emails with tools like the Social Engineering framework. As detailed above, the reconnaissance phase netted us an email address format and some employee names we can jam into that format. From here, we are going to conduct a phishing campaign against our target company. We will start by sending a convincing link to a website to establish browser versions, no exploitation yet, we just want to know what we are dealing with. After our initial foray into phishing we established that the browser version specified in the user agent string of the http request is not vulnerable to any known exploits. Well, there goes the methodological approach. Time to use the hammers, emphasis on the plural. We generate a website with java applet execution, office documents with macro execution, and good old-fashioned zipped executables with lude filenames such as ben_swolo_xxx.exe or stormy_daniels_sex_tape.exe. Off they go to hundreds of users with a handful providing connections back to us under standard domain users on the internal network. Winning.

Lastly we will examine the DNS server with an unpatched vulnerability on it. This could give us all the access we need to own the network. Domain admins work on servers and this server could dump us a gold mine of admin credentials. We load up the module in metasploit and throw the bits across the network. A shell is returned, whoami returns system, and easy mode is engaged. We migrate our meterpreter process to lsass.exe with gusto and hashdump our way to victory. The results come back and we have credentials. Then, reality sets in, the credentials are not domain credentials, but only local ones. As fate would have it, the DNS server fell off the domain years ago, but since it was the external DNS server, it never really needed to be on the domain in the first place. The DNS service kept chugging along and admins logged in with local admin to fix any problems that popped up. All we have is a foothold in the DMZ.

Adversary Counter Tactics

During this episode of ‘That Damn Blue Team’ we will be exploring how our adversary counters or initial engagement and attempts to dislodge us from our footholds. During the reconnaissance phase, many of the adversary counter tactics were passive fire and forget tactics. When countering an attacker who has gained a foothold, the tactics will have to be much more active and will require more human interaction. We will examine how a defender reacts to brute force password attempts against a web application, spear phishing emails, and exploited legacy servers in this section.

In our first engagement we described how we intelligently brute forced a user account and password against a vulnerable web application. A sysadmin for the web application notices a spike in the number of failed log in attempts against his server and moves to counter the attack. Unbeknownst to us as attackers, the sysadmin had removed a rule from the server that locked out accounts after multiple failed attempts years ago. This prevented Gary, the office fuck up, from locking out his account once a week and putting in trouble tickets. Realizing his mistake, the sysadmin reinstates the rule to counter any further password guessing attacks against the web server. As a good sysadmin, he admits to his mistake takes his findings up to management and with the help of his CIO implements a password reset for everyone who used the web application. We’ve now lost access to our web application user account. However, the sysadmin and CIO did not put 2 and 2 together to figure out that we only used the web application user account to execute commands on the server. Our local user account is still active on the server.


To say that we were ‘loud’ in our phishing campaign is an understatement. We threw flashbangs through the windows and kicked down the door to this network. Everyone knows we are here and everyone knows they done goofed because the CIO is in front of the other C levels for the second time this week, this time shoving phishing training down employee’s throats instead of password resets. The incident response team is analyzing all the email payloads and actively scrubbing them off the network. Any computer where a payload was downloaded to the hard drive has been quarantined from the network and is loaded with a fresh operating system image. The daily debrief with our customer is outright hostile and we are on the verge of losing the job. Luckily for us, the customer paid upfront and our contract with them said phishing was on the table. We do not receive callbacks from any of our payloads after 24 hours.

Our DNS exploit seems to have hit the mark and we have a solid foothold in the DMZ. As we begin our standard post exploitation reconnaissance we trigger several logs that, if properly paid attention to, would result in loss of our foothold. While exploring the machine we kick off processes that any competent network defender would recognize as a compromise of the system. Instead of sending windows logs to a central logging server where they would be analyzed by an AI engine, data visualization tool, or machine learning algorithm, the DNS server quietly keeps them to itself because it fell off the domain years ago. Our foothold seems secure and we gain a false sense of security that certain commands do not raise the red flags that a modern network would have in place.


The ‘establishing a foothold’ phase was a resounding success. Not only did we accomplish all of our objectives, but in an optimistic view we gave our customer’s CIO the ammunition he needed to browbeat the other C-levels into paying attention to cyber security. When the budget comes due for the next year the CEO is going to remember the shit show he had to deal with and pay some big bucks for a sleek network device that claims to filter out phishing emails.

As far as a reflection on our own conduct we can probably find a less intense way of phishing a company that does not result in a week-long migraine for the CIO who champions paying for a red team to come in every year. Our password guessing attempts against the web app were noisy enough to deny us access to the application but we only maintained the foothold due to sysadmin incompetence. We will write into our standard operating procedures to space out and randomize user accounts for password guessing in the future. At this moment in time, we will not have the information to do any meaningful reflection on tripping logs in the DNS server. We will learn that lesson the hard way while we try to dominate the network in our next blog, Privilege Escalation.