Tuesday, May 24, 2016

Swiss defense contractor RUAG: APT breach findings

A Swiss defense contractor agreed to share details of a very advanced persistent threat actor found operating within their systems.  The unabridged version of the report contain a great amount of information, including functional analysis of tools used withing the campaign.

The attackers infiltrated the environment, established covert internal communication, staged hidden information stores, and coordinated hierarchical data exfiltration.

The Reporting and Analysis Center for Information Assurance (MELANI) provides both a summary and detailed version of findings.

RAUG Compromise

Locating the target

“Vulnerable web servers on the Internet” were used as both watering holes and first-stage command-and-control.  Sometimes disguised as Google analytics JavaScript, browsers are redirected to a secondary infection site where victim IP addresses can be compared to the list of intended targets.  

Infection happens in two stages. First "a system is infected by a reconnaissance malware." If the system is sufficiently interesting, "stage 2 malware is added, and ultimately persistence is gained." 


Stage one infection: reconnaissance

“If the IP address matches a network range on the target list, the next step is a more sophisticated finger-printing script. The fingerprinting scripts gains as much information about the victim as possible by using JavaScript. It is taken from the BEEF framework (Browser Exploitation Framework BEEF, beefproject.com).”

Victims are marked with an evercookie.

Reconnaissance continues for "a few days or weeks."  Tools used in this stage are considered expendable.

Stage two infection: persistence

"If the fingerprinting suggests a high probability of a successful infection, a payload containing an exploit, or trying to trick the user into executing a seemingly legitimate binary, e.g. a JavaInstaller, is returned."

Stage two is "usually run under administrative privileges, so they require the additional step of a privilege escalation. [..] This usually requires the use of an exploit (privilege escalation) on the target system, or - more commonly - the knowledge of credentials."  At this point, the attacker already has a great deal of information about the target before - starting stage two.

"A common feature of recon tools, as well as of stage 2 trojans, is that they don’t run in dedicated processes, but inject themselves into already existing processes, where they live as additional threads. This way, no additional processes becomes visible in a running system."
  • They are started in more complex ways at boot up time, typically using a service, or - in the case of rootkits - kernel drivers.
  • They also allow the execution of batch scripts and binaries in their tasks, but often also support plugins like key loggers and activities like taking screenshots.
  • They are usually multi-threaded. Received tasks are not immediately executed, but queued and   later on executed via another thread, usually even running in a different process.
  • They use named pipes and mutexes to coordinate the different threads.
  • They do have a separate configuration file that allows incremental updates
  • They always install a unique trojan ID for every infected system
  • They support peer-to-peer functionality: tasks can be forwarded to other bots for execution.

“The malware sent HTTP requests to transfer the data to the outside, where several Command-and-Control (C&C) servers were located. These C&C servers provided new tasks to the infected devices. Such tasks may consist of new binaries, configuration files, or batch jobs.“

Setting up shop.

Once “inside the infiltrated network, the attackers used named pipes for the internal communication between infected devices, which is difficult to detect. This way, they constructed a hierarchical peer-to-peer network.” Some nodes were responsible for external communication.  This was achieved via thread injection into a running web browser.  Other nodes were delegated workers. “The latter ones never actually contacted any C&C servers, but instead received their tasks via named pipes from a communication drone, and also returned stolen data this way. Only communication [nodes] ever contacted C&C servers directly.”

“This peer-to-peer functionality is a very important additional feature of the stage 2 malware. This means that a bot is able to receive a task from it’s C&C server(s) and route it to another infected bot in the local network; results are sent back using the same path in the reverse direction. To facilitate this feature, every infected bot gets a unique trojan ID at infection time, and every task contains initial routing information, potentially even using several intermediate hops.”

“The kernel mode component tried to hide all activities from system monitoring, and in addition implemented an encrypted, virtual file store (VFS). The VFS was realized as 100 MB file (hidden by the rootkit) with an NTFS filesystem on it.”  This covert storage was also used to collect and queue files for exfiltration.

Looking around

“After they got into the network, they moved laterally by infecting other devices and by gaining higher privileges. One of their main targets was the active directory, as this gave them the opportunity to control other devices, and to access the interesting data by using the appropriate permissions and group memberships.”  Common tools were utilized, with a heavy reliance on Mimikatz.

Tools included:
  • mimikatz.exe 
  • pipelist.exe
  • psexec.exe
  • wmi.exe
  • dsquery.exe
  • dsget.exe
  • ShareEnum.exe

Exfiltration

"Total data exfiltrated: about 23GB. It is noteworthy that this data contains also beaconing requests to the C&C servers. Also, some data has been exfiltrated more than once, and exfiltrated data was usually compressed. However, the size of exfiltrated data gives no insight about the confidentiality and the value of the stolen data. It is not possible to find out what data actual ly was stolen using proxy logs.”  Although “the most active phases took place from September to December 2015,” investigators also acknowledged “log files at RUAG only go back until September 2014, where we still see C&C activity.”


Recommendations

The author’s first recommendation is to deploy application control.  This is also known as application whitelisting or trust modeling.

Additional recommendations include:
  • Two-factor authentication, at least for privileged accounts
  • Internal network segmentation to control or block internal communication
  • All outbound server communication, even proxied browsers, should be blocked by default
  • Collect netflow data, not only between networking zones, but internally as well.
  • Prevent external name resolution (DNS)
  • Centrally collect and retain logs for 2 years.
  • Continuous log analysis and matching the log files against known IOCs
  • Isolate management from business traffic.
  • Be able to have deploy emergency patches in 24hrs or less.

Finally, “accept that some risks cannot be dealt with in a preventative way and therefore invest in detection capabilities."  Likewise, "it is important to have good engineers that have a firm understanding of your infrastructure and your business.”


Source: Technical Report about the Malware used in the Cyberespionage against RUAG

No comments:

Post a Comment

Share your thoughts.