Monday, August 21, 2017

Mandiant “Breach”: A High-Level Case Analysis & Understanding the Data Leak

Post is from my friend

What is Mandiant?

On July 31st, nameless attackers released a document claiming they breached the security of Mandiant, an American cyber security firm. In this document, attackers claimed that they had penetrated the Mandiant network infrastructure with remote access and monitoring capabilities to their analysts’ systems.

What happened?

On August 7th, FireEye, the parent company of Mandiant, released a statement denying the alleged breach within their network infrastructure. FireEye claims that the attackers had accessed one threat intelligence analyst’s online accounts through external pre-existing data leaks that included account credentials, specifically passwords. Through an internal investigation at Mandiant, the employee’s credentials were found in 8 external database breaches, many of which likely had the same login credentials as other online accounts where company data was stored. Presumably, the analyst’s accounts were accessed with stolen credentials, and the limited company data affecting two customers was stolen. Mandiant nor FireEye are at fault at all, it is a flaw of an employee’s account credential usage, which could happen anywhere.

Why do these breaches happen? Targeted attack, tarnishing brand name reputation, personal attack, etc.

I suspect this attack was executed for three likely reasons:

  1. Brand reputation: damage the companies’ reputation
  2. Personal vendetta: damage the analyst’s reputation through a dox-oriented effort
  3. Publicity: advertise the #LeakTheAnalyst hacking campaign

Brand reputation is easily tarnished through the media. Even if allegations are false, it will not look good on any company’s reputation. FireEye and Mandiant handled this particular situation well by offering public transparency in their investigations, explaining that their network infrastructure and customer data is safe.

Personal vendetta’s often lead to people being digitally attacked with the intent of negatively impacting the victim’s life through exposure of information via doxing or other tactics. The goal of a targeted attack like this could be to cause internal politics with a victim’s employer, future employer’s who search for their name on Google or even to simply just bother the victim.

Publicity for the attacker’s #LeakTheAnalyst campaign could have also been the goal of this targeted attack. By claiming responsibility for the attack through the hacking campaign, the media will do the rest of the work for them by spreading their message.

Regardless of the reason, we need to look at how these targeted attacks are happening. The answer is loud, clear and nothing new to the security industry: people are re-using passwords, and as a result, personal accounts are being accessed for data exfiltration.

What data is included?

It is important that we understand how exactly data is stored in databases. Every field included during the account registration process will also be included as a field in a database entry. Here is an example of what the database entries look like to hackers and administrators behind the scenes:     ,(37337, 'Cypher', '7274ed7f77a35fc8b090a36df4e8535c', '7NSymPAH', 'j7fFx7OGpz1F69mPi1NV8c65kCKi4mXrqVvOsbfd2ygZNWnypY', '', 0, 0, 0.00, NULL, NULL, NULL, 2, NULL, 0, NULL, 1296257475, 1296314097, 1296314097, 0, NULL, 0, NULL, NULL, NULL, '1-1-1992', 'all', NULL, NULL, 1, 0, 0, 0, 1, 2, 0, 'linear', 1, 1, 1, 1, 0, 0, 0, NULL, NULL, -8, 0, 0, NULL, NULL, 0, 0, 0, 0, NULL, NULL, NULL, 1, 0, 0, '', '', 1670000814, 1261327169, NULL, 2555, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, NULL)

In this fabricated sample using the SQL data format, we can see multiple things:
  • User ID: 37337
  • Username: Cypher
  • Password (MD5 hash): 7274ed7f77a35fc8b090a36df4e8535c (Decrypted: @cryptocypher)
  • Email:
  • Date of birth: January 1st, 1992 (1-1-1992)
  • Past IP addresses:,
  • Other random data

Naturally, people use the same passwords on multiple accounts. Once that hashed password that we obtained from a third-party database is cracked, that is when unauthorized access to social media, cloud storage, email accounts, government documentation, and whatever more could be accessed with similar account credentials.

There is a lot of information contained in these accounts; private messages, personally identifiable information, corporate documents, project source code, and more. As a result, doxes are created (ie. Mandiant employee), companies are attacked (ie. Mandiant), identities are stolen, competitors can steal project ideas, and reputation is tarnished all-around for all parties included upon attacks being carried out.

How can this data be obtained? LeakedSource, HIBP, etc.

Public services like HaveIBeenPwned (HIBP) are freely available to check to see if any of our information is in any known public data leaks. As of this time of writing, HIBP currently has data including:

·         228 hacked websites
·         3,999,249,352 account entries from leaked databases
·         53,121 pastes containing personally identifiable information
·         50,181,662 pastes containing account information

Among these breaches, data is included from LinkedIn, VK, DailyMotion, Brazzers, and even websites as old as Neopets. For an extensive list of websites who have experienced data leaks, you can either check this page on HIBP or visit “The Breached Database Directory” hosted by

The breached database directory data statistics.

There are also paid data search engine services that frequently come-and-go due to legality issues. These services operate similarly to HIBP, but they actually show the parsed data, based on account entries like the HackForums SQL entry example displayed above. A popular example would be LeakedSource, who sell data for any of their 3,109,103,084 accounts on record. There are also data trading rings where cyber criminals trade data among themselves.

How can I prevent an attack like this from happening?

Do not use the same password. But really, take advantage of two-factor authentication where possible, try to use different passwords if you can remember them, and use a password manager like KeePassX for the passwords that you cannot remember.

Inevitably, companies will be vulnerable to these types of attacks for as long as passwords are used to authenticate account ownership. Respective to this, the fault lays in human error. Tech folks should raise awareness in their offices by using examples like the Mandiant case to explain to directors and co-workers the dangers of poor password management hygiene. Penetration tests including phishing attempts on employees could also be considered.

Companies could also consider using these public data services to their advantage if they are legally capable of doing so. I propose that security departments start scanning these third-party database leaks to find information tied to their own domain and employees. This will ensure that our employees and clients are aware of the leaked data prior to an adversary having the chance to take advantage of this information. LeakedSource offers API services for this, but a lot could be done in-house if the data can be found in a public archive.

We can also setup Google Alerts to alert us whenever content is archived by Google containing specified pieces of personally identifiable information. There is also a HIBP email list that we can subscribe to so that we are alerted whenever our email is discovered in future data breaches. These are all preemptive steps that we can take to ensure our personal information’s security.


People everywhere are gaining unauthorized access to places that they should not be accessed due to the poor practice of password storage. We need to educate our users, actively test our own companies security, and search for company emails that are included in third-party data breaches. People are constantly accessing company and political data that they should not be accessing, and it is all preventable.

1 comment: