EXPOSED: How These Scammers Tried To Use LinkedIn To Steal Our Client’s Passwords

Earlier this morning one of our more savvy customers received an email from [email protected]. The email contained a “New Message Received” notification allegedly sourced from CEO Tom Morgan. Contained in the email was a link that read, “Click here to sign in and read your messages”. Fortunately we had already provided training to this particular customer that covered Social Engineering and Phishing threats. So, rather than click on the link they forwarded the email to Netragard’s Special Project Team, which is like throwing meat to the wolves. The actual email is provided below in figure 1.
Figure 1
Figure1
The first step in learning about who was behind this threat was to follow the “click here” link. The link was shortened using the URL shortener ow.ly and so we used curl to expand it. While we were hopeful that the URL would deliver some sort of awesome zeroday or malware, it didn’t. Instead it served up a fake LinkedIn page (Figure 2) designed to steal login and password information.
Figure 2
figure2
The server hosting the phishing site was located in Lebanon and of course was not maintained or patched properly. Quick reconnaissance showed that directory listing was enabled, that the server was using an outdated and very exploitable version of cPanel, and that the server had been breached by at least four other parties (there were at least 4 backdoors installed). We used one of the backdoors to gain access to the system in the hopes of learning more (Figure 3).
Figure 3figure3
 
Our team quickly zeroed in on the “linkd.php” file that was used to generate the phishing page shown in Figure 2.   We explored the file looking for information related to where stolen passwords were being kept. Initially we expected to see the passwords logged to a text file but later found that they were being emailed to an external Gmail account. We also looked for anything that might provide us with information about who was being targeted with this attack but didn’t find much on the system.
We were able to identify the victims of the campaign by making hidden modifications to the attackers phishing platform. These modifications allowed us to track who submitted their credentials to the phishing site. When studying the submission data it quickly became apparent that the attackers were almost exclusively targeting Luxembourg based email addresses (.lu TLD’s) and were having a disturbingly high degree of success. Given that people often reuse passwords in multiple locations this campaign significantly increased the level of risk faced by organizations that employ the victims. More directly, chances are high that organizations will be breached using the stolen passwords.
The LinkedIn campaign was hardly the only campaign being launched from the server. Other campaigns were identified that included but may not be limited to DHL, Google, Yahoo and DropBox. The DropBox campaign was by far the most technically advanced. It leveraged blacklisting to avoid serving the phishing content to Netcraft, Kaspersky, BitDefender, Fortinet, Google, McAfee, AlienVault, Avira, AVG, ESET, Doctor Web, Panda, Symantec, and more. In addition to the blacklisting it used an external proxy checker to ensure page uptime.
Finally, we tracked the IP addresses that were connecting to the system’s various backdoor.  Those IP addresses all geolocated to Nigeria and are unfortunately dynamic.
Screenshot 2016-08-18 10.24.57
 
 
 
Summary
This phishing campaign highlights two specific issues that can both be countered with careful planning.  The first is that employees are easy to phish especially when they are outside of the office and not protected by spam filters.  This is problematic because employees often reuse the same passwords at work as they do outside of work.  So stealing a LinkedIn password often provides attackers with access to other more sensitive resources which can quickly result in a damaging breach and access to an organizations critical assets.   The solution to this issue is reasonably simple.  Employees should be required to undergo regular training for various aspects of security including but not limited Social Engineering and Phishing.  Second, Employers should require employees to use password management tools similar to 1Password.  Using password management tools properly will eliminate password reuse and significantly mitigate the potential damages associated with password theft.
As for our Nigerian friends, they won’t be operating much longer.

Hacking Case Study

How we tricked your HR lady into giving us access to every customers credit card number

free-guide
We recently completed the delivery of a Realistic Threat PCI focused Penetration Test for a large retail company. As is always the case, we don’t share customer identifiable information, so specific details about this engagement have been altered to protect the innocent. For the sake of this article we’ll call the customer Acme Corporation.

When we were first approached by the Acme Corporation we noticed that they seemed well versed with regards to penetration testing. As it turned out, they had been undergoing penetration testing for more than a decade with various different penetration testing vendors. When we asked them how confident they were about their security they told us that they were highly confident and that no vendor (or hacker to their knowledge) had ever breached their corporate domain let alone their Cardholder Data Environment (CDE). We were about to change that with our Realistic Threat Penetration Testing services.

Realistic Threat Penetration Tests have specific characteristics that make them very different from other penetration tests.

The minimum characteristics that must be included for a penetration test to be called Realistic Threat are:

  1. IT/Security Staff must not be aware of the test.
  2. Must include solid reconnaissance.
  3. Must not depend on automated vulnerability scanners.
  4. Must include realistic Social Engineering not just elementary phishing.
  5. Must include the use of undetectable (and non-malicious) malware.
  6. Must be covert as to enable propogation of compromise.
  7. Must allow legitimate incident response from the customer.

Lets begin…

As with all engagements Netragard’s team began with reconnaissance. Reconnaissance is the military term for the passive gathering of intelligence about an enemy prior to attacking the enemy. It is what enables our team to construct surgical plans of attack that allow for undetected penetration into targeted networks. During reconnaissance we focus on mapping out all in-scope network connected devices using truly passive techniques and without making direct network connections. We also focus on passive social reconnaissance using everything from Facebook to LinkedIn to Jigsaw.

When Netragard finished performing reconnaissance against Acme Corporation it became apparent that direct technological attacks would likely not succeed. Specifically, Acme Corporation’s externally facing systems were properly patched and properly configured. Their web applications were using a naturally secure framework, appeared to follow secure coding standards, and existed behind a web application firewall. Firing off technological attacks would do little more than alert their IT staff and we didn’t want that (their IT staff were deliberately unaware of the test).

Reconnaissance also identified a related job opportunity posted on LinkedIn for a Sr. IT Security Analyst. Interestingly the opportunity was not posted on Acme Corporation’s website. When Netragard reviewed the opportunity it contained a link that redirected Netragard to a job application portal that contained a resume builder web form. This form was problematic because it worked against our intention to submit a RADON infected resume to HR. We backtracked and began chatting on LinkedIn with the lady who posted the job opportunity. We told her that the form wasn’t loading for us but that we were interested in applying for the job. Then she asked us if we could email our resume to her directly, and of course we happily obliged.

Our resume contained a strand of RADON 2.0. RADON is Netragard’s zeroday malware generator designed specifically with customer well-being and integrity in mind. A strand is the actual malware that gets generated.   Every strand of RADON is configured with an expiration date. When the expiration date is reached the strand entirely removes itself from the infected system and it cannot be run again. RADON was created because other tools including but not limited to Metasploit’s Meterpreter are messy and leave files or even open backdoors behind. RADON is fully undetectable and uses multiple, non-disruptable covert channels for command and control. Most importantly when RADON expires it leaves systems in a clean, unaltered, pre-infection state.

Shortly after delivering our infected resume, RADON called home and had successfully infected the desktop belonging to the nice HR lady that we chatted with on LinkedIn. Our team covertly took control of her computer and began focusing on privilege escalation. RADON was running with the privileges of the HR employee that we infected. We quickly learned that those privileges were limited and would not allow our team to move laterally through the network. To elevate privileges we impersonated the HR employee that we compromised and forwarded our infected resume to an IT security manager.   The manager, trusting the source of the resume, opened the resume and was infected.

In short time RADON running on the IT security manager’s desktop called home. It was running with the privileges of the IT security manger who also happened to have domain administrative privileges.  Our team ran procdump on his desktop to dump the memory of the LSASS process.  This is important because the LSASS process contains copies of credentials that can be extracted from a dump.  The procdump command is “safe” because it is a Microsoft standard program and does not trigger security alerts.   However the process of extracting passwords from the dump often does trigger alerts.  To avoid this we transferred the dump to our test lab where we could safely run mimikatz to extract the credentials.

Then we used the credentials to access all three of Acme Corporation’s domains and extracted their respective password databases. We exfiltrated those databases back to our lab and successfully cracked 93% of all the current and historical passwords for all employees at Acme Corporation. The total elapsed time between initial point of entry and password database exfiltration was 28 minutes. At this point we’d reached an irrevocable foothold in Acme Corporation’s network. With that accomplished it was time to go after our main target, the CDE.

The process of identifying the CDE required aggressive reconnaissance. Our team searched key employee desktops for any information that might contain credentials, keys, vpn information, etc.   Our first search returned thousands of files that spanned over a decade. We then ordered the files based on date of modification and content and quickly found what we were looking for. The CDE environment could only be accessed by two users via VPN from within Acme Corporation. Making things more complex was that the VPN was configured with two-factor authentication was not tied into the domain.

Fortunately for us, this is not the first time we’ve run into this type of configuration. Our first step towards breaching the CDE was to breach the desktop of the CDE maintenance engineer. This engineer’s job was to maintain the systems contained with in the CDE from both a functionality and security perspective. To do this we placed a copy of RADON on his desktop and executed it as a domain administrator using RPC. The new RADON instance running on the CDE maintenance engineer’s desktop called home and we took control.

We quickly noticed that various VPN processes were already running on the CDE maintenance engineer’s desktop. So we checked the routing table looking for IP addresses that we knew to be CDE related (from the files that we gathered earlier) and sure enough they existed. This confirmed that an there was an active VPN session from our newly compromised desktop into the CDE. Now all we had to do was hijack this session, breach the CDE, and take what we came for.

We used the net shell command (netsh) and created a port forward rule from the infected desktop to the CDE. We then used a standard windows RDP client to connect to the CDE server but when we tried to authenticate, it failed. Rather than risking detection, we decided to take a step back and explore the CDE maintenance engineer’s desktop to see if we could find credentials related to the CDE.   Sure enough we found an xls document in a folder named “Encrypted” (which it wasn’t) that contained the credentials that we were looking for. Those credentials allowed us to to log into the CDE without issue.

When we breached the CDE we noticed that our user was a domain administrator for that environment. As a result not only did we have full control over the CDE but our activity would appear as if it were normal maintenance rather than hacker related. In short time we were able to locate customer credit card data, which was properly encrypted. Despite this we were confident that we’d be able to decrypt it by leveraging discoveries from our previous reconnaissance efforts (we did not make that effort at the customers request).

When we began exploring avenues for data exfiltration we found that the CDE had no outbound network controls. As a result, if we were bad actors we could have sent the credit card data to any arbitrary location on the Internet.

In summary, there were three points of failure that enabled our team to breach the CDE. The first point of failure is unfortunately common; network administrators tend to work from accounts that have domain administrative privileges. What network administrators should do instead is to use privileged accounts only when needed. This issue is something that we encounter in nearly every test that we do and it almost always allows us to achieve network dominance.

The second point of failure was the VPN that created a temporary bridge from the LAN to the CDE. That VPN was configured with split tunneling. It should have been configured in such a way that when the computer was connected to the CDE it was disconnected / unreachable from the corporate network. That configuration would have prevented our team from breaching the CDE with the described methodology.

The third point of failure was that the CDE did not contain any outbound network controls.   We were able to establish outbound connections on any port to any IP address of our choosing on the Internet. This means that we were in a position to extract all of Acme Corporation’s credit card data without detection and without issue. Clearly, the correct configuration would be one that is highly restrictive and that alarms on unexpected outbound connections.

Finally, the differences between compliance and security are vast. In the past decade we’ve seen countless businesses suffer damaging compromises at the hands of malicious hackers. These hackers get in because they test with more talent, more tenacity, and more aggression than nearly all of the penetration testing vendors operating today. For this reason we can’t stress how important it is that businesses select the right vendor and test at realistic threat levels. It is impossible to build effective defenses without first understanding how a real threat will align with your unique risks. At Netragard, we protect you from people like us.

Ukrainian hacker admits stealing business press releases for $30M, What they’re NOT telling you -Netragard

The sensationalized stories about the hacking of PR Newswire Association, LLC., Business Wire, and Marketwired, L.P. (the Newswires) are interesting but not entirely complete.  The articles that we’ve read so far paint the Newswires as victims of some high-talent criminal hacking group.  This might be true if the Newswires actually maintained a strong security posture, but they didn’t.  Instead their security posture was insufficiently robust to protect the confidentiality, integrity or availability of the data contained within their networks.  We know this because enough telling details about the breach were made public (see the referenced document at the end of this article).
In this article we first provide a critical analysis of the breaches based on public information primarily from the published record.   We do make assumptions based on the information provide and our own experience with network penetration to fill in some of the gaps. We call out the issues that we believe allowed the hackers to achieve compromise and cause damage to the Newswires.   Later we provide solutions that could have been used (and can be used by others) to prevent this type of breach from happening again. If we miss something, or if we can add to the solutions that we provide please feel free to comment and we will update this article accordingly.
From the published record we know that Marketwired was hacked via the exploitation of SQL Injection vulnerabilities.  We know that the hacking was ongoing for a three-year period.  Additionally, according to the records the SQL Injection attacks happened on at least 390 different occasions over a three-month span (between April 24th 2012 and July 20th, 2012).  We assume that Marketwired was unaware of this activity because no responsive measures were taken until years after the initial breach and well after damage was apparently realized.
With regards to SQL Injection, an attacker usually needs build the attack through a process of trial and error, which generates an abundance of suspicious error logs.  In rare cases when an attacker doesn’t need to build the attack the actual attack will still generate a wealth of suspicious log events.  Moreover, SQL Injection made its debut 17 years ago in a 1998 release of phrack magazine, a popular hacking zine.   Today SQL Injection is a well-known issue and relatively easy to mitigate, detect, and/or defeat.  In fact almost all modern firewalls and security appliances have SQL Injection detection / prevention built in. When considering normally overt nature of SQL Injection, the extended timeframe of the activity, and the apparent lack of detection by Marketwired, it strongly suggests that Marketwired’s security was (and may still be) exceptionally deficient.
It is Netragard’s experience from delivering Platinum level (realistic threat) Penetration Tests that businesses have a 30-minute to 1-hour window in which to detect and respond to an initial breach. When Netragard’s team breaches a customer network, if the customer fails to detect and revoke Netragard’s access within the aforementioned timeframe then the customer will likely not be able to forcefully expel Netragard from its network. Within a 30-minute window of initial penetration Netragard is 89% likely to compromise its customers domain controller(s) and achieve total network dominance. Within a 1-hour window of initial penetration Netragard in 98% likely to compromise its customers domain controller(s) and achieve total network dominance.
We know that Marketwired’s failure to detect the initial breach (and subsequent attacks) provided the hackers with ample time to metastasize their penetration throughout the network. The published record states that the hackers “installed multiple reverse shells”. The record also states “in or about March 2012, the Hackers launched an intrusion into the networks of Marketwired whereby they obtained contact and log-in credential information for Marketwired’s employees, clients, and business partners.” We assume that the compromise of “log-in credential information” means that the hackers successfully compromised Marketwired’s domain controllers and exfiltrated / cracked their database of employee usernames and passwords. Given the fact that people tend to use the same passwords in multiple places (discussed later as well) the potential impact of this almost immeasurable.
While considerably less information about the breach into PRN’s network is available, the information that is public outlines significant security deficiencies existed. According to the published record PRN detected the intrusions into their network well after the network was breached which represents a failure at effective incident detection. Moreover, it appears that PRN’s response was largely ineffective because PRN ejected the hackers from the network but the hacker’s regained access. According to the record it appears that the dance of ejection and re-breach happened at least three times.
The third breach into PRN is very telling. This time the hackers purchased a list of logins taken from a compromised social networking website. The hackers then “reviewed and collected usernames and logins for PRN employees” from that list and used the collected information “to access the Virtual Private Network (“VPN”) or PRN”. Clearly PRN did not use two-factor authentication for its VPN, which would have prevented this method of penetration. It is also important to note that two-factor authentication is necessary to satisfy some regulatory requirements. Additionally, PRN’s policy around password usage and password security is seriously deficient or not being adhered to. Specifically, PRN employees were using the same passwords on social media websites (and possibly other places) as they were for PRN’s network.   As with Marketwired’s breach, PRN’s were very likely preventable.
Even less information is available about Business Wire’s breach. According to the records Business Wire’s network was initially breached via SQL Injection (like Marketwired) by another hacker at an earlier time. Iermolovych (the name of the hacker who hacked the Newswires) purchased access to Business Wire’s network from the other hacker. As with Marketwired and PRN, Business Wire’s own detection and response capabilities were (and may still be) lacking. It is unclear from the record as to how long the hackers were able to operate within Business Wire’s network but it is clear that the initial SQL Injection attack and subsequent breach was not detected or responded to in a timely manner.
Unfortunately, based on our own experience, most businesses are as vulnerable as the Newswires. The reasons for this are multifaceted we may cover them in another article at a later time. For now, we’ll focus on what could have been done to prevent the damages that resulted from this breach. It’s important to stress that every network will be breached at some point during its lifetime. The question is will the Incident Response be effective at detecting the breach and preventing it from becoming damaging.
To understand the solution we must first understand the problem. Damaging breaches have two common characteristics, which are poor network security and ineffective Incident Response. We know from studying historical breach data from the Verizon DBIR and OWASP that approximately 99.8% of all breaches are the product of the exploitation of known vulnerabilities for which CVE’s have already been published (may for over one year). This validates our first characteristic. The second characteristic is validated by the ever increasing number of damaging braches that are reported each year. The fact that these breaches are damaging shows that Incident Response has failed.
Most of the reported breaches in the past decade could have been avoided by proactively countering the two aforementioned points of failure. Countering these failure points requires actionable intelligence about how a threat will align with the unique risks of each associated network and how sensitive data will be accessed. The best method of assembling this intelligence is to become the victim of a breach not through malicious hacking but instead through high-quality, realistic-threat penetration testing.   Unfortunately this isn’t as easy as it sounds. The industry standard penetration test is a vetted vulnerability scan which is far from realistic and provides no real protective benefit. There are a few realistic threat penetration-testing vendors in operation but finding them can be a challenge.
Some of the characteristics of a realistic threat penetration test include but are not limited to social engineering with solid pretexts, undetectable malware, the non-automated identification and exploitation of network and web application vulnerabilities, exploit customizations, and stealth penetration. A realistic penetration testing team will never request that its IP addresses be whitelisted nor will they request credentials (unless perhaps for web application testing). The team will similarly not be dependent on (and may elect not to even use) automated tools like Nessus, Nexpose, The Metasploit Framwork, etc. Automated tools are useful for basic security & maintenance purposes but not for the production of realistic threats. Do you think the hackers that hacked Target, Sony, Hannaford, LinkedIn, The Homedepot, Ashley Madison, or The Newswires used those scanners?
The report generated by a realistic penetration test should cover the full spectrum of vulnerabilities as well as the Path to Compromise (PTC). The PTC represents the path(s) that an attacker must follow to compromise sensitive data from a defined source (Internet, LAN, etc.). Identifying the PTC is arguably more important from a defensive perspective than vulnerability identification. This is because it is technically impossible to identify every vulnerability that exists in a network (or in software) and so there will always exist some level of gap. Identifying the PTC allows a business mitigate this gap by creating an effective IR plan capable of detecting and responding to a breach before it becomes damaging. Netragard’s platinum level Network Penetration Testing services produce a high-detail PTC for exactly this reason.
The Newswires (and many other businesses) could likely have prevented their breach if they had done the following.

  1. Deployed a response-capable Web Application Firewall and configured the firewall specifically for the application(s) that it was protecting. This would have prevented the SQL Injection attacks from being successful.
  2. Deployed a Network Intrusion Detection / Prevention solution to monitor network traffic bidirectionally. This would likely have enabled them to detect the reverse-shells.
  3. Deployed a Data Loss Prevention solution. This would likely have prevented some if not all of the released from being exfiltrated.
  4. Deployed a SEIM capable of receiving, correlating and analyzing feeds from system logs, security appliances, firewalls, etc. This would likely have allowed the Newswires to detect and respond to the initial attacks before breach and well before damage.
  5. Purchased realistic-threat penetration testing that produced a report containing a detailed PTC and then implemented the suggested methods for mitigation, remediation, and hardening provided in the report. The test would enable them to measure the effectiveness of their existing security solutions and to close any gaps that might exist.
  6. To deploy an internal honeypot solution (like Netragard’s) that would detect lateral movement (Distributed Metastasis) inside of their networks and allow the Newswires to respond prior to experiencing any damage.

Records for reference

Enemy of the state

A case study in Penetration Testing
We haven’t been blogging as much as usual largely because we’ve been busy hacking things.   So, we figured that we’d make it up to our readers by posting an article about one of our recent engagements. This is a story about how we covertly breached a highly sensitive network during the delivery of a Platinum level Penetration Test.

First, we should make clear that while this story is technically accurate certain aspects have been altered to protect our customer’s identity and security. In this case we can’t even tell you if this was for a private or public sector customer. At no point will ever write an article that would put any of our customers at risk. For the sake of intrigue lets call this customer Group X.

The engagement was designed to produce a level of threat that would exceeded that which Group X was likely to face in reality. In this case Group X was worried about specific foreign countries breaching their networks. Their concern was not based on any particular threat but instead based on trends and what we agreed was reasonable threat intelligence.   They were concerned with issues such as watering holes, spear phishing, 0-day malware, etc. They had reason for concern given that their data was and still is critically sensitive.

We began work like any experienced hacker would, by performing social reconnaissance. Social reconnaissance should always be used before technical reconnaissance because it’s passive by design. Social reconnaissance when done right will provide solid intelligence that can be used to help facilitate a breach. In many cases social reconnaissance can eliminate the need for active technical reconnaissance.

Just for the sake of explanation, technical reconnaissance includes active tasks like port scanning, web server scanning, DNS enumeration, etc. Technical reconnaissance is easier to detect because of its active methods. Social reconnaissance, when done right, is almost impossible to detect because it is almost entirely passive. It leverages tools like Google, Maltego, Censys, etc. to gather actionable intelligence about a target prior to attack.

Our social reconnaissance efforts identified Group X’s entire network range, a misconfigured public facing document repository (that did not belong to Group X but was used by them and their partners/vendors), and a series of news articles that were ironically focused on how secure Group X was. One of the articles went so far as to call Group X the “poster child of good security”.

We began by exploring the contents of the aforementioned document repository. The repository appeared to be a central dumping ground for materials Group X wanted to share with third parties, including vendors. While digging through the information all of it appeared to be non-sensitive and mostly intended for public consumption. As we dug further we uncovered a folder called WebServerSupport and contained within that folder was a file called “encyrypted.zip”. Needless to say we downloaded the file.

We were able to use a dictionary attack to guess the password for the zip file and extract its contents. The extracted files included a series of web server administration guides complete with usernames, passwords, and URL’s. One of the username, password and URL combinations was for Group X’s main website (https://www.xyxyxyxyxy.com/wp-admin,username,password). When we browsed to https://www.xyxyxyxyxy.com/wp-admin we were able to login using the credentials. With this level of access we knew that it was time to poison the watering hole. (https://en.wikipedia.org/wiki/Watering_Hole)

To accomplish this we deployed our malware framework into the webserver (www.xyxyxyxyxy.com). Our framework is specifically designed to allow us to control who is infected. We are able to select targets based on their source IP address and other information identifying information. When a desired target connects to the watering hole (infected website) our framework deploys our 0-day pseudo-malware (RADON) into the victim’s computer system.   RADON then establishes persistence and connects back to our command and control server. From there we are able take complete control of the newly infected computer.
Netragard RADON v2.0 Strand Generator
radon_gen
RADON is not the same RADON used by the National Security Agency (NSA) as was speculated by the InfoSec institute. RADON does appear similar in some respects. It relies on side channel communications that cannot be disrupted without breaking core network protocols. It was designed to be far safer than other tools that tend to leave files behind (like Metasploit’s meterpreter). All strands of RADON are built with an expiration date that when reached trigger a clean uninstall and render the original source inert. We designed RADON specifically because we needed a save, clean and reliable method to test our customers at high levels of threat.

After the malware framework was deployed and tested, we scheduled it to activate the next business day. The framework was designed to infect one target then sleep until we instructed it to infect the next. This controlled infection methodology helps to maintain stealth. By 9:30 AM EST our first RADON strand called home. When we reviewed the connection we learned that we had successfully infected a desktop belonging Group X’s CIO’s assistant. We confirmed control and were ready to begin taking the domain (which as it turns out was ridiculously easy).

One of the first things we do after infecting a host is to explore network shares. During this test we quickly located the “scripts” share, which contained all of the login scripts for domain users. What we didn’t expect was that we’d be able to read, write, and otherwise modify every single one of those startup scripts. We were also able to create new scripts, new files and directories within the scripts directory. So uploaded RADON to the share and added a line to every login script that would run RADON every time a user logged into a computer. We quickly infected everything on the network.

After parsing through the onslaught of new inbound RADON connections we were able to identify personal user accounts belonging to network administrators. As it turned out most of the administrators personal accounts also had domain admin privileges. We leveraged those accounts to download the username and password database (ntds.dit) from the domain controller. Then we used RADON to exfiltrate the password database and dump it on one of our GPU password-cracking machines. We were able to crack all of the current and historical passwords in less than 2 hours time. What really surprised us was that 90% of the passwords were exactly identical.

Initially we thought that this was due to an error.   But after further investigation we realized that this common password could be used to login using all of the different domain accounts. It became even more interesting when we began to explore the last password change dates. We found that nearly 100% of the passwords had never been changed and that some of the accounts were over a decade old, still active, but no longer being used by anyone. We later found out that employees that had been terminated never had their accounts deactivated. When we confronted the customer with this they told us that it was their policy to not change passwords. When we asked them why they pointed to an article written by Bruce Schneier. (Sorry Bruce, but this isn’t the first time you’ve made us question you.)

At this point in the engagement we had more control over our customer’s infrastructure than they did. We were able to control all of their critical devices including but not limited to antivirus solutions, firewalls, intrusion detection and prevention systems, log correlation systems, switches, routers and of-course their domain. We accomplished this without triggering a single event and without any suspicion.

The last two tasks that remained were trophy gathering and vulnerability scanning. Trophy gathering was easy given the level of access that we had. We simply searched the network for .pdf, .doc,.docx,.xlsx, etc. and harvested files that looked interesting. We did find about a dozen reports from other penetration testing vendors as well. When we looked at those reports they presented Group X’s network as well managed and well protected. The only vulnerabilities that were identified were low and medium level vulnerabilities, none of which were exploitable.

When we completed our final task which was vulnerability scanning and vetting, our scanners produced results that were nearly identical to the other penetration testing vendor reports that we exfiltrated. Things like deprecated SSL, open ports, etc. were reported but nothing that could realistically lead to a network compromise. When we scanned Group X’s network from the perspective of an Internet based threat no vulnerabilities were reported. Our scans resulted in their security team becoming excited and proud because they “caught” and “prevented our intrusion attempt. When we told them to check their domain for a Netragard domain admin account, their excitement was over.