TorLocker
You know, all the online analysis I've seen of malware samples is very in-depth and quite good, but it's all assuming a level of expertise with application security and reverse engineering that I just don't have. I need something focused on network intrusion analysis, but usually that's just a subset of the RE. So, I've decided to start my own analyses, which I will store here for now. I'll start with an interesting series of events that led my analysts in the SOC (where I am shift supervisor) to write a number of tickets for malware remediation.
On 10/16/2014 15:52:35 PDT, our firewall showed some Tor traffic from internal hosts, so I filtered for that and found about a dozen internal hosts that were being flagged for it. The Palo Alto firewall was using its deep packing inspection capability to classify the traffic according to its Applipedia database. The most active host was sending traffic to 81.7.14.246, so I searched for that and found the Malwr sample linked below. Lo and behold, the activity generated by this sample included installing Tor on infected machines and opening up traffic to:
We checked these destinations for our multiple customers, and found about a dozen hosts needing trouble tickets. Some were going to just one of the IPs, a few were going to half of them, and a couple to all four! The autonomous systems hosting these IPs are interesting because most malicious traffic can be traced to a few of the most compromised networks, such as AS 4134 (China Telecom) or AS 16276 (OVH). These are not among them, in fact I've never seen any of them before. Since the malware is using Tor, though, I shouldn't be surprised since the Tor network uses random hosts in the network to communicate with. However, with that, any one Tor client just happening to use the same few nodes as another Tor client is extremely unlikely unless it's told to. The file name in the Malwr sample is torlocker.exe. Be careful, there is something else out there with a similar name but it's for TorrentLocker, which uses BitTorrent as the command and control channel.
With the way our customers are set up, often the only information we get is the IP addresses and ports involved, and nothing else. This is an endless source of frustration because most malware command and control servers are hosted on dynamic IP addresses, so we need the domain names in order to definitely say that the hosts are compromised. Only we don't get those. Then our customers complain that we don't find enough compromised systems! With Target, Home Depot, Dairy Queen, Saks Fifth Avenue, and JP Morgan Chase all in the news recently for losing customer data to hackers, you would think people would start taking their information security more seriously, including budgeting for it.
References:
https://malwr.com/analysis/NzU3YjE5MjVkMWNmNDYwMDhhODdkNWJmOTViYWM5MzU/
On 10/16/2014 15:52:35 PDT, our firewall showed some Tor traffic from internal hosts, so I filtered for that and found about a dozen internal hosts that were being flagged for it. The Palo Alto firewall was using its deep packing inspection capability to classify the traffic according to its Applipedia database. The most active host was sending traffic to 81.7.14.246, so I searched for that and found the Malwr sample linked below. Lo and behold, the activity generated by this sample included installing Tor on infected machines and opening up traffic to:
| 171.25.193.9 | No site | AS198093 Foreningen for digitala fri-och rattigheter, Sweden |
| 128.31.0.39 | No site | AS3 MIT Massachusetts Institute of Technology |
| 176.28.53.79 | nsa.saugt.penen.de | AS20773 Host Europe GmbH, Germany |
| 81.7.14.246 | zwiebel.pixelminers.net | AS35366 ISPpro Internet KG, Germany |
We checked these destinations for our multiple customers, and found about a dozen hosts needing trouble tickets. Some were going to just one of the IPs, a few were going to half of them, and a couple to all four! The autonomous systems hosting these IPs are interesting because most malicious traffic can be traced to a few of the most compromised networks, such as AS 4134 (China Telecom) or AS 16276 (OVH). These are not among them, in fact I've never seen any of them before. Since the malware is using Tor, though, I shouldn't be surprised since the Tor network uses random hosts in the network to communicate with. However, with that, any one Tor client just happening to use the same few nodes as another Tor client is extremely unlikely unless it's told to. The file name in the Malwr sample is torlocker.exe. Be careful, there is something else out there with a similar name but it's for TorrentLocker, which uses BitTorrent as the command and control channel.
With the way our customers are set up, often the only information we get is the IP addresses and ports involved, and nothing else. This is an endless source of frustration because most malware command and control servers are hosted on dynamic IP addresses, so we need the domain names in order to definitely say that the hosts are compromised. Only we don't get those. Then our customers complain that we don't find enough compromised systems! With Target, Home Depot, Dairy Queen, Saks Fifth Avenue, and JP Morgan Chase all in the news recently for losing customer data to hackers, you would think people would start taking their information security more seriously, including budgeting for it.
References:
https://malwr.com/analysis/NzU3YjE5MjVkMWNmNDYwMDhhODdkNWJmOTViYWM5MzU/
Comments
Post a Comment