Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Threat Intelligence

05:30 PM
Connect Directly

FireEye's Mandia: 'Severity-Zero Alert' Led to Discovery of SolarWinds Attack

CEO Kevin Mandia shared some details on how his company rooted out the major cyberattack campaign affecting US government and corporate networks.

FireEye CEO Kevin Mandia today shared some insight on the cyberattack on the security firm that was the first clue to a massive and wide-ranging attack campaign against several major US government and commercial networks.

In a panel today hosted by the Aspen Institute, Mandia described how his company first recognized the serious attack it had suffered, describing how a newly registered phone using a FireEye user account was the first indication of malicious activity. "In this particular case, the event that got briefed to me and got us to escalate and declare this a full-blown incident was somebody was accessing our network just like we do, but they were doing it with a second registered device," he explained. The FireEye user whose account was associated with the flagged access was contacted and asked if he had registered a new phone, but he had not.

"Even though this was a severity-zero alert" at first, Mandia said, it was evidence of a major security event. "We had somebody bypassing our two-factor authentication by registering a new device and accessing our network just like our employees do, but it actually wasn't our employee" doing it, he said.

Details about the illicit phone used in the attack was first reported by Yahoo News last month, in an interview with Charles Carmakal, senior vice president and CTO of FireEye. "They had to provide credentials to authenticate [their device] to the [multifactor authentication system] in order to authenticate to the FireEye VPN," Carmakal told Yahoo News. "It was the process the attacker followed to enroll in the MFA solution, which is what generated the alert. But at this point, the attacker already had the employee's username and password."

Mandia said that method of attack was a big red flag. "The minute we saw that, we recognized that's the kind of tradecraft advanced groups would do," Mandia noted. No malware, and under the guise of a legitimate user, "doing exactly what your employees do when they go to work every day."

Related Content:

5 Key Takeaways From the SolarWinds Breach

How Data Breaches Affect the Enterprise

New From The Edge: How the Shady Zero-Day Sales Game Is Evolving

"There's no magical wand that ... finds backdoors in software that we all purchase and trust," he said. "What led us to do that [decompiling] work was, in fact, all of the forensics" we conducted beforehand, he says.FireEye had investigated packet captures and forensic software logs on its endpoints and found one common thread: "It kept backing into, the earliest evidence of compromise for us was the system that harbored the SolarWinds product," he said. So, the company went to work decompiling code and found 4,000 lines of malicious code.

The attackers planted malware in legitimate updates to SolarWinds' Orion network management software that was sent to some 18,000 public and private sector customers of the software. According to US intelligence assessments, a very small number of those organizations actually were targeted and compromised.

The Attack on FireEye
Stage one of the attack planted the backdoor onto FireEye's network via the SolarWinds platform, Mandia said. Stage two used the backdoor to access domain credentials, he said, such as user accounts and passphrases. "Stage three was to get the token signing-certs to access O365, likely for specific email accounts," Mandia said. The final stage of the FireEye attack was the theft of its red-team tools.

Mandia said he had not seen many ".com" breaches for this type of espionage, so the attack group behind this "smells different."

While the US intelligence community as well as several government officials and security experts have cited Russia as the perpetrator, FireEye has not done so. The company has attributed the attack to an unknown or unclassified group or nation-state. "We have not made any attribution beyond assigning this activity to UNC 2452. An UNC group, short for unclassified, is a cluster of cyber-intrusion activity — which includes observable artifacts such as adversary infrastructure, tools, and tradecraft — that we are not yet ready to give a classification such as APT or FIN," a FireEye spokesperson said. "As we collect additional intelligence, UNC group activity can be assigned to an existing group, graduated to a new group, or simply remain unclassified."

Kelly Jackson Higgins is the Executive Editor of Dark Reading. She is an award-winning veteran technology and business journalist with more than two decades of experience in reporting and editing for various publications, including Network Computing, Secure Enterprise ... View Full Bio

Recommended Reading:

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
Inside the Ransomware Campaigns Targeting Exchange Servers
Kelly Sheridan, Staff Editor, Dark Reading,  4/2/2021
Beyond MITRE ATT&CK: The Case for a New Cyber Kill Chain
Rik Turner, Principal Analyst, Infrastructure Solutions, Omdia,  3/30/2021
Register for Dark Reading Newsletters
White Papers
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
How Enterprises are Developing Secure Applications
How Enterprises are Developing Secure Applications
Recent breaches of third-party apps are driving many organizations to think harder about the security of their off-the-shelf software as they continue to move left in secure software development practices.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2021-04-15
An issue was discovered in Zulip Server before 3.4. A bug in the implementation of replies to messages sent by outgoing webhooks to private streams meant that an outgoing webhook bot could be used to send messages to private streams that the user was not intended to be able to send messages to.
PUBLISHED: 2021-04-15
An issue was discovered in Zulip Server before 3.4. A bug in the implementation of the can_forge_sender permission (previously is_api_super_user) resulted in users with this permission being able to send messages appearing as if sent by a system bot, including to other organizations hosted by the sa...
PUBLISHED: 2021-04-15
An issue was discovered in Zulip Server before 3.4. A bug in the implementation of the all_public_streams API feature resulted in guest users being able to receive message traffic to public streams that should have been only accessible to members of the organization.
PUBLISHED: 2021-04-15
In the topic moving API in Zulip Server 3.x before 3.4, organization administrators were able to move messages to streams in other organizations hosted by the same Zulip installation.
PUBLISHED: 2021-04-15
The issue navigation and search view in Jira Server and Data Center before version 8.5.12, from version 8.6.0 before version 8.13.4, and from version 8.14.0 before version 8.15.1 allows remote attackers to inject arbitrary HTML or JavaScript via a DOM Cross-Site Scripting (XSS) vulnerability caused ...