Skip navigation
All Places > Products > RSA NetWitness Platform > Blog > 2017 > September > 26

Over the past several months, RSA FirstWatch has been avidly tracking the rise of crypto-currency mining.  Most of our early research here focused on the malicious delivery of mining software to victim machines, e.g. our recent work against Monero mining.  However, the recent introduction of javascript-based miners has fundamentally shifted the role mining may play across the Internet.


"Coinhive offers a JavaScript (node.js) miner for the Monero Blockchain that you can embed in your website. Your users run the miner directly in their Browser and mine XMR for you in turn for an ad-free experience, in-game currency or whatever incentives you can come up with".  This is a legitimate capability that we expect to see gain significant traction (over ads in many cases) across all types of verticals that rely on web-presence.  Take for example Showtime's recent use of Monero miners, the exact intent of which still remains a bit unclear


courtesy of 


Unfortunately, it has also become very clear that a number of less reputable sites intend to leverage coinhive for the purposes of "drive-by mining", a term coined by Jerome Segura (@Malwarebytes) in a recent post entitled 'Drive-by mining and ads: The Wild Wild West'.


The NetWitness screenshot below provides a clear example of drive-by mining in the response during the initial connection to a streaming video site, sledujserialy[.]sk (hosted at 104.31.74[.]41).



Near the bottom of this screenshot, note the tell-tale 'coinhive.min.js' representative of Monero mining activity.



The challenge from a NetWitness visibility perspective comes after this initial connection, where SSL encryption takes over.  While we do not believe this to be a ever-present indicator, we did note '' in the SSL Subject meta data field.



Our sample domain wasn't the only service demonstrated activity of this type though; Bad Packets report on Twitter led us to a quick Censys search for 'coinhive.min.js', which reveals more than 1,000 services currently using this javascript library.  



To further understand the scope of drive-by mining abuse, let's take a look at related SSL certificates in Censys, and please note the warning that many of the thousands of results could be potentially fake.



When we limit the search Censys for "parsed.names:" as suggested, there is a dramatic drop in the number of SSL certificates returned.  This seems like a rather large delta, which speaks to the potential volume of other coin-hive centric projects being developed and deployed across the Internet.



FirstWatch anticipates that customers will likely see a significant increase in mining and specifically in-browser mining activity such as coin-hive in the months to come.  A preliminary list of sites using coinhive javascript to actively mine monero can be found at Enabled Sites Mining for Monero -


Thanks to Ahmed Sonbol for his contributions to this research.


By now the InfoSec community had a chance to digest the recent findings around the popular software "CCleaner" and a compromised version.  Great research was provided by the TALOS Intelligence group here and here.  The question on the minds of senior leadership becomes what the impact could be to the organization.  The ability to query the systems in the enterprise for such threats is essential to answering that business impact question.  Avast posted additional findings in their own blog and this is where our post begins.


Avast provided several indicators of compromise (IOC's) that would allow security teams to quickly scan their environment to identify known or suspicious files or communications.  Let's start with the first stage indicators.


There were twenty (20) SHA256 hashes of files in the list.  Since the list was not in a particular format (STIX, TAXI, CSV, etc) we can scrape them from the page and paste them into our old friend "vi".



Essentially what we need to do is get the provided indicator into a form that our tools can use.  Our first attempt is to just show the hash itself.


      awk -F' - ' '{print $1}' ccleaner



We can then go over to NetWitness Endpoint looking for these hashes.  One could be looking for all instances of 'ccleaner' in the Global Modules and looking at the SHA256 hash value.  Sometimes looking at Compile Time is also helpful.


You can also go into the Filter Editor and enter the hashes here as well.  


Another option is performing the query directly against the SQL database.  Similar to using the Filter Editor method above, we simply need to get the query built in a way that works.  Since it will be a large OR statement, we just need the right syntax and the location where the values are stored.  The hashes are stored in the database in dbo.Modules.HashSHA256.  Knowing this, we can get the necessary syntax with our other good friend 'awk'.


      awk -F" - " '{print "OR mo.HashSHA256 = 0x"$1}' ccleaner


NOTE:  "OR mo.HashSHA256 = 0x" was prepended to query that column.  0x was also prepended to the hash as the data is stored in that way.


This returns the values in a form that I can easily query.  Now, I just need the query.



--Search for a machinename based on the hash of a module

select mn.machinename, mo.HashSHA256


    [dbo].[MachineModulePaths] AS mp

    INNER JOIN [dbo].[Machines] AS [mn] WITH(NOLOCK) ON ([mn].[PK_Machines] = [mp].[FK_Machines])

    INNER JOIN [dbo].[Modules] AS [mo] WITH(NOLOCK) ON ([mo].[PK_Modules] = [mp].[FK_Modules])


    --mo.HashMD5 = 0xCEDC22719DE1B1316BDC556FED989335

    --mo.HashSHA256 = 0x069F24378A0A6EEA078D30D971542741D0F51E1F933EEEB23FDB559763FF0ACD

    --mo.HashSHA1 = 0x39E0F0F2F64B50FB9783A49B7940BF326D7B6B65


-- First Stage

mo.HashSHA256 = 0x04bed8e35483d50a25ad8cf203e6f157e0f2fe39a762f5fbacd672a3495d6a11

OR mo.HashSHA256 = 0x0564718b3778d91efd7a9972e11852e29f88103a10cb8862c285b924bc412013

OR mo.HashSHA256 = 0x1a4a5123d7b2c534cb3e3168f7032cf9ebf38b9a2a97226d0fdb7933cf6030ff

OR mo.HashSHA256 = 0x276936c38bd8ae2f26aab14abff115ea04f33f262a04609d77b0874965ef7012

OR mo.HashSHA256 = 0x2fe8cfeeb601f779209925f83c6248fb4f3bfb3113ac43a3b2633ec9494dcee0

OR mo.HashSHA256 = 0x3c0bc541ec149e29afb24720abc4916906f6a0fa89a83f5cb23aed8f7f1146c3

OR mo.HashSHA256 = 0x4f8f49e4fc71142036f5788219595308266f06a6a737ac942048b15d8880364a

OR mo.HashSHA256 = 0x7bc0eaf33627b1a9e4ff9f6dd1fa9ca655a98363b69441efd3d4ed503317804d

OR mo.HashSHA256 = 0xa013538e96cd5d71dd5642d7fdce053bb63d3134962e2305f47ce4932a0e54af

OR mo.HashSHA256 = 0xbd1c9d48c3d8a199a33d0b11795ff7346edf9d0305a666caa5323d7f43bdcfe9

OR mo.HashSHA256 = 0xc92acb88d618c55e865ab29caafb991e0a131a676773ef2da71dc03cc6b8953e

OR mo.HashSHA256 = 0xe338c420d9edc219b45a81fe0ccf077ef8d62a4ba8330a327c183e4069954ce1

OR mo.HashSHA256 = 0x36b36ee9515e0a60629d2c722b006b33e543dce1c8c2611053e0651a0bfdb2e9

OR mo.HashSHA256 = 0x6f7840c77f99049d788155c1351e1560b62b8ad18ad0e9adda8218b9f432f0a9

OR mo.HashSHA256 = 0xa3e619cd619ab8e557c7d1c18fc7ea56ec3dfd13889e3a9919345b78336efdb2

OR mo.HashSHA256 = 0x0d4f12f4790d2dfef2d6f3b3be74062aad3214cb619071306e98a813a334d7b8

OR mo.HashSHA256 = 0x9c205ec7da1ff84d5aa0a96a0a77b092239c2bb94bcb05db41680a9a718a01eb

OR mo.HashSHA256 = 0xbea487b2b0370189677850a9d3f41ba308d0dbd2504ced1e8957308c43ae4913

OR mo.HashSHA256 = 0x3a34207ba2368e41c051a9c075465b1966118058f9b8cdedd80c19ef1b5709fe

OR mo.HashSHA256 = 0x19865df98aba6838dcc192fbb85e5e0d705ade04a371f2ac4853460456a02ee3


-- Second Stage


OR mo.HashSHA256 = 0xdc9b5e8aa6ec86db8af0a7aa897ca61db3e5f3d2e0942e319074db1aaccfdc83

OR mo.HashSHA256 = 0xa414815b5898ee1aa67e5b2487a11c11378948fcd3c099198e0f9c6203120b15

OR mo.HashSHA256 = 0x7ac3c87e27b16f85618da876926b3b23151975af569c2c5e4b0ee13619ab2538

OR mo.HashSHA256 = 0x4ae8f4b41dcc5e8e931c432aa603eae3b39e9df36bf71c767edb630406566b17

OR mo.HashSHA256 = 0xb3badc7f2b89fe08fdee9b1ea78b3906c89338ed5f4033f21f7406e60b98709e

OR mo.HashSHA256 = 0xa6c36335e764b5aae0e56a79f5d438ca5c42421cae49672b79dbd111f884ecb5


I added the second stage hashes as well.  This query returns some results that would need additional checking.  



Next, we can move over to NetWitness for Packets and Logs and see if we have any hits.





No hits here, thankfully.  


There were also some domain generated algorithms (DGA's) used and provided in the listing of IOC's.  Using "vi" again, we copied the contents into a file like before.



Then, using a similar "awk" statement we generate the query for use in the NetWitness suite.


      awk -F" - " '{print "\x27"$1"\x27,"}' c2 | sed 's/ //g' | tr -d '\n'


NOTE: \x27 prints a single quote

sed 's/ //g' removes some trailing whitespace as a result of the copy/paste.

tr -d '\n' removes the new line so they all appear on the same line.


Armed with this syntax, I can copy and paste into NetWitness.  Since we are querying the same key for multiple values, we can separate using a comma.  However, since we are using "", which is a Text formatted meta key, we need to ensure the values are enclosed in quotes for our query.



Again, no findings.


The presence of compromised files might mean the declaration of an incident and the launching of larger forensic investigation depending on the organization.  At this point, we know the files were here, but we might not have been a target based on currently available research.   


In summary, searching for indicators of compromise using the NetWitness suite is a great first step in identifying potential problems in your environment.  Sometimes the data isn't provided in an easy to use format, however with some quick command line techniques, you can have that data massaged into a format ready to query.  This whole exercise took a few moments to complete and we can begin to answer what the impact is to the business.


As always, know your data and happy hunting.




If you did identify the presence of these or other suspicious or compromised files in your organization, our RSA Incident Response team is here to assist with the triage.  If you have an IR Retainer in place with RSA then you already have rapid access to our analysts who can get engaged and rapidly identify the scope of the incident.  If you don’t have an IR Retainer or are interested in learning more about our Incident Response services, please visit our Incident Response Services page on

Malspam activity was noted on September 23rd 2017 delivering a Jacksbot variant to infected machines. Jacksbot is a backdoor family that can run on any platform that supports Java Runtime Environment [1]. In this blog post we will discuss the delivery mechanism and the behavior on the infected machine.


Submitting the delivery document to RSA pre-release What's This File service shows the maximum threat score.




The VBA code writes data to a local VBS file (J4n.vbs). Here is the activity in NetWitness Endpoint:



Next wscript.exe is called to execute the newly created J4n.vbs. A JAR file is downloaded and saved to a temp directory as HELP202.JAR. After a timeout, javaw.exe is called to execute the JAR:



Here is the download session in NetWitness Packets:




The following meta values were registered for the download session including watchlist file extension, tld not com net org, http not good mozilla, http no referer, http long user-agent and http get no post. For more information about those meta values, please check the hunting guide [2]:



According to VirusTotal scan results, the payload is a Jacksbot variant. However, it looks like it failed to run on a victim machine:



The delivery domain a[.]pomf[.]cat has been active delivering all kinds of payloads to infected machines not only over HTTP but also over SSL:




Here is another look at the process tree:



Delivery document (SHA256):

  • 1459ec6788f4ecd1dd8d2b55dd931c245304c3fd0cae410d2c0df93170c13ee8

Jacksbot variant (SHA256):

  • 090c02c428cc42b55772055e8c26232e2fd8f51c9c28e6041d503abcd82cb695



  1. TrendLabs Security Intelligence BlogJACKSBOT Has Some Dirty Tricks up Its Sleeves - TrendLabs Security Intelligence Blog 
  2. RSA NetWitness Hunting Guide 

Filter Blog

By date: By tag: