In early October, a story was published by the Wall Street Journal alleging Kaspersky Lab software was used to siphon classified data from an NSA employee’s home computer system.
Given that Kaspersky Lab has been at the forefront of fighting cyberespionage and cybercriminal activities on the Internet for over 20 years now, these allegations were treated very seriously. To assist any independent investigators and all the people who have been asking us questions whether those allegations were true, we decided to conduct an internal investigation to attempt to answer a few questions we had related to the article and some others that followed it:
- Was our software used outside of its intended functionality to pull classified information from a person’s computer?
- When did this incident occur?
- Who was this person?
- Was there actually classified information found on the system inadvertently?
- If classified information was pulled back, what happened to said data after? Was it handled appropriately?
- Why was the data pulled back in the first place? Is the evidence this information was passed on to “Russian Hackers” or Russian intelligence?
- What types of files were gathered from the supposed system?
- Do we have any indication the user was subsequently “hacked” by Russian hackers and data exfiltrated?
- Could Kaspersky Lab products be secretly used to intentionally siphon sensitive data unrelated to malware from customers’ computers?
- Assuming cyberspies were able to see the screens of our analysts, what could they find on it and how could that be interpreted?
Answering these questions with factual information would allow us to provide reasonable materials to the media, as well as show hard evidence on what exactly did or did not occur, which may serve as a food for thought to everyone else. To further support the objectivity of the internal investigation we ran our investigation using multiple analysts of non-Russian origin and working outside of Russia to avoid even potential accusations of influence.
The Wall Street Journal Article
The article published in October laid out some specifics that need to be documented and fact checked. Important bullet points from the article include:
- The information “stolen” provides details on how the U.S. penetrates foreign computer networks and defends against cyberattacks.
- A National Security Agency contractor removed the highly classified material and put it on his home computer.
- The data ended up in the hands of so called “Russian hackers” after the files were detected using Kaspersky Lab software.
- The incident occurred in 2015 but wasn’t discovered until spring of last year .
- The Kaspersky Lab linked incident predates the arrest last year of another NSA contractor, Harold Martin.
- “Hackers” homed in on the machine and stole a large amount of data after seeing what files were detected using Kaspersky data.
Beginning of Search
Having all of the data above, the first step in trying to answer these questions was to attempt to identify the supposed incident. Since events such as what is outlined above only occur very rarely, and we diligently keep the history of all operations, it should be possible to find them in our telemetry archive given the right search parameters.
The first assumption we made during the search is that whatever data was allegedly taken, most likely had to do with the so-called Equation Group, since this was the major research in active stage during the time of alleged incident as well as many existing links between Equation Group and NSA highlighted by the media and some security researchers. Our Equation signatures are clearly identifiable based on the malware family names, which contain words including “Equestre”, “Equation”, “Grayfish”, “Fanny”, “DoubleFantasy” given to different tools inside the intrusion set. Taking this into account, we began running searches in our databases dating back to June 2014 (6 months prior to the year the incident allegedly happened) for all alerts triggered containing wildcards such as “HEUR:Trojan.Win32.Equestre.*”. Results showed quickly: we had a few test (silent) signatures in place that produced a LARGE amount of false positives. This is not something unusual in the process of creating quality signatures for a rare piece of malware. To alleviate this, we sorted results by count of unique hits and quickly were able to zoom in on some activity that happened in September 2014. It should be noted that this date is technically not within the year that the incident supposedly happened, but we wanted to be sure to cover all bases, as journalists and sources sometimes don’t have all the details.
Below is a list of all hits in September for an “Equestre” signature, sorted by least amount to most. You can quickly identify the problem signature(s) mentioned above.
|Detection name (silent)||Count|
Taking this list of alerts, we started at the top and worked our way down, investigating each hit as we went trying to see if there were any indications it may be related to the incident. Most hits were what you would think: victims of Equation or false positives. Eventually we arrived at a signature that fired a large number of times in a short time span on one system, specifically the signature “HEUR:Trojan.Win32.Equestre.m” and a 7zip archive (referred below as “[undisclosed].7z”). Given limited understanding of Equation at the time of research it could have told our analysts that an archive file firing on these signatures was an anomaly, so we decided to dig further into the alerts on this system to see what might be going on. After analyzing the alerts, it was quickly realized that this system contained not only this archive, but many files both common and unknown that indicated this was probably a person related to the malware development. Below is a list of Equation specific signatures that fired on this system over a period of approximately three months:
In total we detected 37 unique files and 218 detected objects, including executables and archives containing malware associated with the Equation Group. Looking at this metadata during current investigation we were tempted to include the full list of detected files and file paths into current report, however, according to our ethical standards, as well as internal policies, we cannot violate our users’ privacy. This was a hard decision, but should we make an exception once, even for the sake of protecting our own company’s reputation, that would be a step on the route of giving up privacy and freedom of all people who rely on our products. Unless we receive a legitimate request originating from the owner of that system or a higher legal authority, we cannot release such information.
The file paths observed from these detections indicated that a developer of Equation had plugged in one or more removable drives, AV signatures fired on some of executables as well as archives containing them, and any files detected (including archives they were contained within) were automatically pulled back. At this point in time, we felt confident we had found the source of the story fed to Wall Street Journal and others. Since this type of event clearly does not happen often, we believe some dates were mixed up or not clear from the original source of the leak to the media.
Our next task was to try and answer what may have happened to the data that was pulled back. Clearly an archive does not contain only those files that triggered, and more than likely contained a possible treasure trove of data pertaining to the intrusion set. It was soon discovered that the actual archive files themselves appear to have been removed from our storage of samples, while the individual files that triggered the alerts remained.
Upon further inquiring about this event and missing files, it was later discovered that at the direction of the CEO, the archive file, named “[undisclosed].7z” was removed from storage. Based on description from the analyst working on that archive, it contained a collection of executable modules, four documents bearing classification markings, and other files related to the same project. The reason we deleted those files and will delete similar ones in the future is two-fold; We don’t need anything other than malware binaries to improve protection of our customers and secondly, because of concerns regarding the handling of potential classified materials. Assuming that the markings were real, such information cannot and will not consumed even to produce detection signatures based on descriptions.
This concern was later translated into a policy for all malware analysts which are required to delete any potential classified materials that have been accidentally collected during anti-malware research or received from a third party. Again to restate: to the best of our knowledge, it appears the archive files and documents were removed from our storage, and only individual executable files (malware) that were already detected by our signatures were left in storage. Also, it is very apparent that no documents were actively “detected on” during this process. In other words, the only files that fired on specific Equation signatures were binaries, contained within an archive or outside of it. The documents were inadvertently pulled back because they were contained within the larger archive file that alerted on many Equation signatures. According to security software industry standards, requesting a copy of an archive containing malware is a legitimate request, which often helps security companies locate data containers used by malware droppers (i.e. they can be self-extracting archives or even infected ISO files).
An Interesting Twist
During the investigation, we also discovered a very interesting twist to the story that has not been discussed publicly to our knowledge. Since we were attempting to be as thorough as possible, we analyzed EVERY alert ever triggered for the specific system in question and came to a very interesting conclusion. It appears the system was actually compromised by a malicious actor on October 4, 2014 at 23:38 local time, specifically by a piece of malware hidden inside a malicious MS Office ISO, specifically the “setup.exe” file (md5: a82c0575f214bdc7c8ef5a06116cd2a4 – for detection coverage, see this VirusTotal link) .
Looking at the sequence of events and detections on this system, we quickly noticed that the user in question ran the above file with a folder name of “Office-2013-PPVL-x64-en-US-Oct2013.iso”. What is interesting is that this ISO file is malicious and was mounted and subsequently installed on the system along with files such as “kms.exe” (a name of a popular pirated software activation tool), and “kms.activator.for.microsoft.windows.8.server.2012.and.office.2013.all.editions”. Kaspersky Lab products detected the malware with the verdict Backdoor.Win32.Mokes.hvl.
At a later time after installation of the supposed MS Office 2013, the antivirus began blocking connections out on a regular basis to the URL “http://xvidmovies[.]in/dir/index.php”. Looking into this domain, we can quickly find other malicious files that beacon to the same URL. It’s important to note that the reason we know the system was beaconing to this URL is because we were actively blocking it as it was a known bad site. This does however indicate the user actively downloaded / installed malware on the same system around the same time frame as our detections on the Equation files.
To install and run this malware, the user must have disabled Kaspersky Lab products on his machine. Our telemetry does not allow us to say when the antivirus was disabled, however, the fact that the malware was later detected as running in the system suggests the antivirus had been disabled or was not running when the malware was run. Executing the malware would not have been possible with the antivirus enabled.