University of Wisconsin–Madison

Cryptocurrency mining malware incident: Lessons learned

On January 3rd, 2018, the Cybersecurity Operations Center (CSOC) learned that several servers in the main Division of Information Technology (DoIT) data center were crashing due to excess loads placed on their CPUs by Cryptocurrency mining malware.

Said malware was likely installed on December 25, 2017, following a history of similar attacks dating back to February of 2017. The affected servers were those for two productions systems and a combined development/test/QA system. These servers provide access to number of business applications utilized by campus, e.g. Position Vacancy Listing, Housing Administration, Purchasing System, etc. 

The attacks were similar to others at UW–System schools and other higher education institutions. They exploited a vulnerability documented in an Oracle WebLogic alert, CVE-2015-4852.


Attempts to remediate the threat by patching WebLogic were unsuccessful, so the affected servers were eventually rebuilt. The rebuilt servers are now free of Cryptocurrency mining malware.

During their forensic examination CSOC found on one of the servers an archive of data from an old application that was no longer running. That archive contained names and Social Security Numbers for UW faculty, staff, and students. CSOC did not find any evidence that the data had been accessed, and so has no reason to believe data was exposed. CSOC did find evidence strongly suggesting that the attacks were carried out by an automated system intended only to install and run cryptocurrency mining software, not identify and steal sensitive data.

Near miss data breach

While no personally identifiable information appears to have been accessed, had another type of malware been delivered by the attacker, it easily could have. Such a breach could have had consequences far greater than the server downtime, and the costs could have been greater than those incurred by the remediation and forensic analysis. You can greatly decrease your chances that such a breach could happens to you by following three recommendations:

  1. Know what data resides on your servers, and protect it. Using Identity Finder is a good starting point.
  2. Review Configuration Management databases for examples to follow.
  3. Take the following 3 security steps:
    • Ensure that each application has a valid business contact and business need.  De-commission and remove any application that is not currently used, as well as its data.
    • Ensure all applications can be supported by the current version of Java. Any incompatibility should be reported to the business owner and the Office of Cybersecurity.
    • Determine if these applications need to be accessible outside of University or UW System network space and/or WiscVPN and place network access restrictions where applicable. (This includes https access to these systems, in addition to Oracle Forms and Reports access.)

While preventing such attacks of this kind, and the possible resulting data breaches that result has a cost in resources, but it is achievable, and preferable to the alternative. Such breaches have costs beyond lost productivity and remediation. They reflect badly on the schools, deans and the University. Preventing such breaches is not complicated, but it does require preparation and adherence to best practices.