The OPM Breach Is Not Unique; Standard TTPs Can Get You the Crown Jewels
Wednesday’s report about the 2014 and 2015 Office of Personnel Management (OPM) breaches showed us that unsophisticated attackers can gain access to sensitive information. The highly detailed report by the House Committee on Oversight and Government Reform lists the known evidence of how two groups conducted their CNE (computer network exploitation) operations inside the OPM network.
While the IT staff at the OPM thinks that the attack was a state-of-the-art operation, it is well within the reach of most penetration testers and even more accessible for a well-motivated nation-state attacker. While the 2014 attack isn’t very detailed due to lack of forensics tools deployed during that period, the 2015 attack is documented and lists how the attacker got his first foothold and then scanned and moved laterally across the network.
During the 2015 operation, the attacker gained access to a contractor’s VPN username and password. This is either from the older operation, because according to appendix D of the US-CERT June 2014 report, username lists of contractors were exfiltrated, attacking the contractor, or another unknown method, such as a brute force attack.
Once inside the network, the attacker used RDP (Remote Desktop Protocol), which is usually a last resort for skilled attackers, and installed a persistent PlugX malware. (a tool that is attributed to chinese attack groups) Most sophisticated attackers use command line tools such as PsExec, or Windows Management Instrumentation (WMI) rather than remote desktop tools as they leave less traces on the host if operated correctly.
The attacker most likely used Windows Credentials Editor (wce.exe), which was identified by forensics, to gain a network administrator username and password, and from there the attacker scanned file shares using the SMB (Server Message Block) protocol and used the xcmd.exe application (an alternative to PsExec) or RDP to move laterally to other computers.
According to Appendix D of the US-CERT’s June 2014 Incident Report, “The attackers primarily focused on utilizing SMB [Server Message Block] commands to map network file shares of OPM users who had administrator access or were knowledgeable of OPM’s PIPs system. The attacker would create a shopping list of the available documents contained on the network file shares. After reviewing the shopping list of available documents, the attacker would return to copy, compress and exfiltrate the documents of interest from a compromised OPM system to a C2 server.”
Jeffrey Wagner, OPM director of security operations, described the attackers use of SMB protocols during the 2014 attack:
If you do some form of traversal or communications, you run over a normal communications protocol. It’s not uncommon to change the protocol language or change the protocols ports on which you do traffic. And essentially, what they did is they tried to hide their activity and the things they were doing in a very highly utilized protocol port. So they basically hid their communications in the fuzz of the [network] traffic.
The OPM attackers hid their communications in ordinary file sharing traffic. By using the SMB protocol, the attackers easily found and moved sensitive files while flying under the radar of existing security tools. And the attackers repeatedly accessed sensitive files without raising alarms. Scanning file shares and using administrative tools like wce.exe, xcmd.exe are the well-known tools, tactics and procedures of the trade. While the attackers’ network activities might seem hard to detect, the OPM did use DPI (deep packet inspection)… to gain insight into the shares and files accessed. If they had taken this deep packet inspection further and analyzed which files users typically accessed, the volume of files they usually accessed and built a profile of file share activity, they might have spotted the lateral movement sooner.
Likewise, if the OPM had monitored the network for administrative behavior, the security team might have seen unusual RPC calls generated by an xcmd.exe executable when the attacker tried to run a command on a remote machine.
Because RPC calls allow administrators as well as attackers to run remote commands on machines, organizations like the OPM should always investigate unusual RPC traffic. If the OPM had baselined RPC usage, determining expected sources and destinations of RPC traffic, they might have been able to detect anomalies indicative of an attack. They also could have baselined remote desktop protocols such as RDP. Furthermore, they could have created triggers to alert on RDP access to sensitive assets, such as IT administrators’ machines or valuable servers.
By profiling file sharing, RPC, remote desktop, and other “highly utilized protocols”, the OPM could have detected attacks earlier—when the reconnaissance and lateral movement happened and not only as part of an incident response process, when it’s too late.
Notice how you can actually see the exact command that the attacker used.
The OPM’s plan to secure the perimeter was well in motion during the response phase of the first attack, but admittedly the OPM’s IT security personnel said that their internal network visibility was their Achilles heel. Wagner testified in February 2016 that OPM had gaps in its security visibility during the initial attack.
Q. Did you have total visibility over OPM’s environment during the 2014 incident?
A. I would not say 100 percent. We had a great deal of visibility. Actually, at the time, we had full visibility on the perimeter. Internal visibility is where we had some gaps.
Q. Why is that?
A. As I said, it was an issue in which there was a longstanding project to have long entries loaded into the logger. Post the 2014 incident, that became a major priority and now we have 100 percent visibility.
During the time of the 2014 incident, the OPM security team was focused on catching malware and attacks at the network perimeter, but they did not having the right visibility tools to see the bigger picture and detect the later stages of the attack, like lateral movement and data exfiltration.
While deploying preventive technology and securing the perimeter might have mitigated the initial intrusion, the attackers would have invested in circumventing those measures using a different malware toolkit or continuing without any malware at all by exploiting vulnerable applications or networking devices. We have seen that the attacker could deploy specially-crafted scripts, showing his investment in this operation, but his other TTPs were straight off the pentesting bookshelf, so perhaps the attacker would have used more conventional methods, such as using well-known administrative tools to maintain persistence.
The detailed report by the Oversight and Government Reform Committee revealed embarrassing lapses in security at the OPM. However, the improvements made by OPM after the breach and the recommendations provided in the report would not have necessarily stopped the attack. Even with every planned protective measure deployed, the attackers would probably have invested the time and brainpower to gain access to a compromised device and then locate and steal sensitive data in databases and file servers.
While increased security visibility would have enabled OPM to improve their post-incident investigation, it would not have alerted them to unusual activity, such as abnormal file share and remote desktop access. As always, it is a game of attrition and no single tool can win the war, but using the right tools and acting quickly will limit the attackers in such ways that it will be unproductive for them to gain the information they want from a protected network.