Skip navigation
All Places > Products > RSA NetWitness Platform > Blog > 2015 > September

Cmstar is a custom downloader that was used in cyber espionage attacks. The name comes from one of the strings its author writes to a text file on an infected machine for debugging purposes. Cmstar network activity is close to Enfal; a malware family that has been used in targeted attacks for years.

Cmstar collects some information about the infected system like the Windows version, the CPU architecture and whether an antivirus is installed or not. It encodes all that info using a single byte XOR algorithm and sends them to its C2 server via an HTTP POST request. Cmstar uses the same XOR algorithm to build the URL and other HTTP request parameters from embedded encoded strings.

Event reconstruction of one of those sessions shows the encoded information being passed from the infected system to the C2 server:


Values for both directory and filename meta keys were the same in all samples analyzed by FirstWatch:


Assuming the appropriate meta keys are enabled, the following query can be used to detect Cmstar network activity:

          action = 'put' && directory = '/cgl-bin/' && extension = 'cgi' && client !exists

You can read more about Cmstar on Palo Alto unit 42 blog.

All of the IOCs from those HTTP sessions were added to RSA FirstWatch Live feeds.

In this blog post, we will discuss the beaconing activity of new Daserf variants that surfaced last week. The backdoor communicates with its C2 domain over HTTP using both GET and POST requests.

First, the malware issues a GET HTTP request to download a GIF file from its C2 server. The response is not a GIF file but an XOR encoded URL string. While the GIF filename varies from one Daserf sample to another, the directory name remains the same.



Daserf decodes the URL received from the server and concatenates it to an ASP filename. It uses the new URL for further communication with the C2 server using POST HTTP requests. The first of them contains encoded information about the infected system like its hostname, its IP address and its language.


The malware uses a hard coded list of pseudorandom ASP filenames. Every filename is exactly 5 characters long. In addition, all the analyzed samples use the same hardcoded user-agent string in their HTTP communication with the server.


Given all the network artifacts mentioned above and assuming the appropriate meta keys are enabled, an analyst can develop a couple of app rules on RSA Security Analytics to detect the malicious traffic. The following queries can be used:

          action = 'get' && directory = '/images/' && extension = 'gif' && filetype != 'gif' && client = 'Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; SV1) '

          action = 'post' && filename length 9 && extension = 'asp' && content = 'application/x-www-form-urlencoded' && client = 'Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; SV1)'

You can find VirusTotal scan results for one Daserf sample here.

All of the IOCs from those HTTP sessions were added to RSA FirstWatch Live feeds.

The RSA Content team is pleased to announce the addition of new and updated content to the RSA Live Content Library! 


During the month of August, we have made the following content available through RSA Live:


  • New Event Steaming Analysis (ESA) rules (4) that will help analyst detect RATS, and Suspicious AWS environment changes. We also released a rule that indicates a potential two-stage malware dropper


  • Updates to Event Streaming (ESA) rules (7) that will limit noise in customer ESA environments and ensure the most targeted and up to date intelligence in our rule library


  • 1 Addition to our Application rule set allows analysts to detect a domain controller or directory server engaged in port activity that is outside expected ports


  • Updated feeds from our RSA FirstWatch team that ensures the most targeted and up to date intelligence in our feed library


  • New Log parser support for Radiator Radius Server that allows visibility into security access control

  • 36 Updates to Log parsers that improves parsing accuracy and supports newer versions of event sources



For a full breakdown of new/updated content released to RSA Live, go here:


Content Announcement



Also, you can view our holistic content library and content request portals here:


RSA Live Content

Content Request Portals



In the future, the Content Team will continue to focus speeding the turn-around on content defects. Our primary focus is to increase parsing accuracy and eliminate parsing inconsistencies for our customers. We also are working on a meta dictionary output which will allow you to see what meta is generated on a per parser basis. Last but not least, we are working on categorizing content in Live by data source (Log, Packet, Log/Packet) so you can navigate to the content that is most important and valid for your environment.


We look forward to sharing some great updates with you next month!





The ASOC Content Team

Filter Blog

By date: By tag: