SecureState Blog

Read SecureState's award winning blog.

Why Old Tactics Still Work

Why Old Tactics Still Work

Read This. If you haven’t already, take a look at the recent Mandiant report on a specific APT group they have been tracking; it’s unprecedented, detailed, interesting, and probably shocking to most readers. After you’ve finished, continue reading below.

Introduction… An X-Files Moment

Dr. Carpenter: My first impression is it’s some kind of bacteria specimen. Can I ask you where you got it?

Scully: It was recovered at a crime scene.

Dr. Carpenter: We’ve come a long way from Colonel Mustard in the den with a rope, haven’t we?

Scully: I’m expecting it will turn out to be nothing.

Dr. Carpenter: No. You’ve definitely got something here…

…..The more we stay the same.But have we come a long way from Colonel Mustard in the den with a rope?  About eight years ago we investigated one of the first known APT compromises that used a WEBC2 backdoor for communication. Interestingly, however, when I describe the attack you might think it was analyzed two days ago and not eight years ago. The details of the bait, functionality, and command and control of the past APT investigation are applicable even today as described within Mandiant’s report. The same techniques used to social engineer victims, deliver malicious payloads, and communicate with attacker-controlled systems are eerily and technically similar from the earliest-known APT compromises to the most recent and well-documented attacks. Therefore, I thought it would be a perfect time to revisit this analysis to show how APT groups have been using fairly similar techniques the whole time – simply because they work. For this blog we’ll specifically look at the WEBC2 communication methods that have remained common and remarkably similar the past 8-years.  I will develop subsequent blogs in the “If it Ain’t Broke” series that will show how standard APT backdoors and initial attacks vectors have also remained constant and similar throughout the years.

APT: If It Ain’t Broke….Hmmm, this sounds familiar…


Within the Mandiant report they reference a timeline of APT registered zones throughout the years, starting from around 2004 to the present. Heading off the list we see, one of the first zones security analysts became aware of and by now one of the most infamous sites. You can go ahead and look up the registration information for the site and do plenty of searches for this domain; I did notice that within hours of issuing the report, the registration information for this zone has replaced most of the supplied information with “anonymous” details– so it’s obvious people have noticed the report.



Several pages before this timeline are a couple of interesting sentences within the section ‘Beachhead Backdoors’:

“From direct observation, we can confirm that APT1 was using WEBC2 backdoors as early as July 2006. However, the first compile time we have for WEBC2-KT3 is 2004-01-23, suggesting that APT1 has been crafting WEBC2 backdoors since early 2004. “

Indeed sirs! In fact, on 7 August, 2005, we identified one of the earliest WEBC2 backdoors -simply called WEB-C2 Backdoor or the !Steven Backdoor at the time- communicating with The investigation revealed an attacker was using a specially crafted comments field in a public website to provide command and control to what has been termed the WEB-C2 backdoor. These commands allowed an attacker to upload and download files and execute commands on a victim system. The attack vector was of course through social engineering; the Attacker sends an email with a hyperlink to a malicious .zip file. When the victim clicks on the link and then downloads the .zip file from the webpage, unzips the file, and then runs the file, the exploit begins. Doesn’t this all sound very familiar? Reread the paragraphs detailing the WEBC2-TABLE Spear Phishing Email.

The Bait…

A particular file, named house.gif, was downloaded and executed once a victim visits a website (sent in a well-disguised email) and downloads and runs malicious code. The malicious code instructed the victim system to connect to an attacker-controlled webpage and download an updated version of the backdoor. At the time of the initial analysis there were three known variants of the backdoor, the most full-featured of which was the house.gif:


Name: house.gif              (MZ header executable)

File Size:              14,368 bytes

MD5 hash:          4494237e92e7941c1d9feab807fb0ce4

Functions Exported:  start

Sections:                     Size                        Title

3000                      .bss

1000                      .data

1000                      .idata

3000                      .text

The Detection…

Within hours of the initial event and user-reports, alerts began to appear for victim IP’s connecting to IP XXX.182.176.42 via port 80 (HTTP). Most of the connections analyzed appeared to be normal web activity with the exception of the victim IP’s conducting a GET request for the web page housing.html.

The HTTP response from IP XXX.182.176.42 contained some abnormal HTML tags, such as <!henry>, <!steven>, etc.

Victim machines would beacon back to a controlling IP address and send a message with any of the commands discussed in Tables 1 or 2 of this blog. Such interaction with the controlling IP address would return something like the following HTML:

   <head><title>Webpage title</title></head>

   Some webpage content


The command being issued by the controlling IP address and being parsed/processed by the client backdoor software is highlighted in red above. Some of the earliest used Indicators of Compromise (IOC’s) were parsing filters to search for this activity (specifically the commands) in network traffic. IOC’s were chosen based on the significance and/or frequency they are seen on a network – some examples are as follows:

!davies                     !henry                    !steven                  !kisscat

!mary                       !again                     !keyy                      !bliss


The Analysis and WEB-C2 Operation…

WEBC2 backdoors are certainly the most well-known and deployed backdoor used for APT communications. Detailed next, and within Mandiant’s report, WEBC2 backdoors are designed to retrieve a webpage from a C2 server and parse attacker-controlled HTML tags. The backdoor will process and interpret the data between tags as commands used within the backdoor software.

Once a victim had downloaded and executed house.gif, the compromised system would perform an HTTP GET request for the file “interl.html” from news.hugesoft. The backdoor then parsed the response from and looked for one of the five initial commands from Table 1 below. The most interesting initial command is !steven which created communication channels between the victim and the website.

If !steven was received by the backdoor, it would POST an encoded form of the victim’s IP address and hostname to, and retrieved a combination of the secondary commands listed in Table 2 below.

The encoded hostname and IP addresses would be decoded by subtracting two from each encoded character (C becomes A, D becomes B, etc…). This key of two could be modified with the !key<number>!!! command.

The secondary commands are what allowed the attacker to spawn a shell on the victim system, upload, download, and execute files. All of the secondary commands that returned information to the attacker did so by POSTing the replies to I have provided some screen shots below that depict the packet captures of this process in action.

At the time of the analysis, little was known about how the attacker dynamically modifies the command tags in the websites. Subsequent investigations confirmed the use a backdoor controller page on the public website that listed the IP addresses and hostnames of victim systems under the attacker’s control. This page eventually was confirmed and allowed the attacker to:

  • Select a host and IP address to issue commands to
  • Dynamically create a webpage that would be sent to the victim
  • Parse replies to those commands and displays the results to the attacker


The following is a listing of known commands and functionality of the backdoor at the time of analysis:


APT: If It Ain’t Broke….

Table 1 – Backdoor Initial Commands


APT: If It Ain’t Broke….

Table 2 – Backdoor Secondary Commands


APT: If It Ain’t Broke….

Diagram 1 – Attacker Process Recreation


APT: If It Ain’t Broke….

Figure 1 – Encoded Information

 APT: If It Ain’t Broke….

Figure 2 – Command Parsing


More Familiar Indicators…

Let’s refer back to the Mandiant report, under the section ‘Standard Backdoors”.   Standard backdoors, the non-WEBC2 APT1 backdoors, provide the attacker more robust features to control victim systems.  Typically, these backdoors communicate over HTTP or a custom protocol the malware uses.  An interesting sentence within their report discusses the BISCUIT backdoor (so named for the command “bdkzt” which will launch a command shell).  The APT group being tracked inside this report have been using and updating BISCUIT since 2007.

Let’s now take a look at the backdoor commands inside Table 2, can you see anything familiar?  The WEBC2 communication for the !Steven backdoor use the instance of “bdkzt” primarily focusing on binding shells and spawning shells – hmmm, this is a precursor to the BISCUIT full-functional backdoor and at the very least an indicator that’s been available since 2005.

End Result:

Not much has changed. Yes, the encoding, payloads, encryption, and even sophistication of backdoors has changed, even significantly is some areas, but the general methodologies and techniques used for APT attacks and communications have remained effectively similar. Why fix what ain’t broken?

Social engineering works.
Using valid user-credentials works.
Taking advantage of relaxed egress filtering works.
Using valid networks, communication protocols, and applications works.
Stealing unprotected data works.
We can go on, and on, and on….

This blog simply showed that within 8-years, not a whole ton of things have changed with the approach to APT communication and initial attack vectors – why, because they work and we haven’t put enough effort in to stopping what works. Take a look at SecureState’s recent APT seminar slides posted at the following address for information of our latest intelligence and recommendations:

Additionally, you may want to reference the following 3-part blog about how SecureState identifies, investigates and validates APT activity, trends, and compromises:

Persistent Threat Modeling – Part 1

Persistent Threat Modeling – Part 2

Persistent Threat Modeling – Part 3

Network Products Guide Best Blog 2013

Network Products Guide Best Blog 2013 Winner