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

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 bleepingcomputer.com 

 

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 'coin-hive.com' 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 coin-hive.com 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: coin-hive.com" 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 Coin-Hive.com Enabled Sites Mining for Monero - Pastebin.com.

  

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.

 

Module_Hash_to_MachineName

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

select mn.machinename, mo.HashSHA256

from

    [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])

where

    --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.

 

      ip.dst=216.126.225.148,216.126.225.163

 

 

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 "alias.host", 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.

 

Chris

 

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 RSA.com

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

 

References:

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

Malspam activity was noted on September 19th 2017 delivering a Cobalt Strike payload. The malicious RTF document leverages the newly disclosed CVE-2017-8759 [1]. Microsoft already released a patch to address the vulnerability in the affected products [2]. RSA FirstWatch blogged last week about it [3][4]. However, we noticed a different network behavior that was worth sharing with the community.

 

The malicious document is spreading as 'resume.rtf'. Upon opening the document in Microsoft Word, the infected system communicated with an external server over FTP to retrieve a file (readme.txt):

 

 

RSA NetWitness Packets shows the file transfer taking place in a separate session (service=0):

 

 

Due to the vulnerability, an HTTP request was made to the same server to get 'favicon.ico' which is actually an HTA script:

 

 

 

Following the execution of the downloaded script, an SSL session was established to download an executable:

 

 

RSA NetWitness Packets indicates that the SSL session uses a self-signed certificate. In fact most of the fields were left blank and that's why you don't see values for SSL CA and an SSL subject in the screenshot below:

 

 

The final payload is a DLL; looks to be a hacking tool and a part of the offensive framework Cobalt Strike. You can find its VirusTotal scan results here.

 

RTF document (SHA256):

  • cdf6e2e928a89cbb857e688055a25e37a8d8b8b90530bd52c8548fb544f66f1f

 

Final payload (SHA256):

  • 5860ddc428ffa900258207e9c385f843a3472f2fbf252d2f6357d458646cf362

 

References:

  1. FireEye Uncovers CVE-2017-8759: Zero-Day Used in the Wild to Distribute FINSPY « Threat Research Blog | FireEye Inc 
  2. https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2017-8759 
  3. Malspam and CVE-2017-8759
  4. Malspam delivers MoonWind 9-20-2017 

UPDATE: The functionality from the custom Lua parser described below is now available within the standard HTTP_lua parser provided from RSA Live.  If you are using this parser in your environment, the custom version attached here (including the app rule) is unnecessary.

 

Many of you may already be aware of a recent vulnerability known as "Options Bleed".  This vulnerability affects Apache web servers and allows access to the contents of memory via the HTTP Options request method.  This HTTP method is supposed to return the available methods (i.e. GET, POST, PUT, etc) to the browser.  For mis-configured web hosts with this un-patched vulnerability, some of the contents of memory are returned along with the available methods.

 

See the following post for a good write-up on the details of Options Bleed:

Apache “Optionsbleed” vulnerability – what you need to know – Naked Security 

 

Attached you will find a custom Lua parser and accompanying Application Rule to detect when this vulnerability is exploited.  The parser detects the response string provided by web server given an OPTIONS request method.  It then will identify whether or not the response is valid.  If not, it will register the following meta key/value:

 

analysis.service = 'garbled http options allow string'

 

In addition, I have provided an application rule which will tie in the presence of this garbled string with some other information about the session:

 

App rule name: 'optoins bleed exploit'

App rule logic:  (analysis.session='garbled http options allow string' && service = 80 && action = 'options')

Alert on:  ioc

 

NOTE: This is custom content created by RSA Professional Services.  It is not officially supported by the RSA Content Team, so please use at your own risk.

CVE-2017-8759 remains popular this week in malspam world with more malicious documents trying to exploit non patched systems to deliver their payload [1][2]. This time the payload is a MoonWind variant. MoonWind is a Remote Access Trojan. It was first uncovered by security researchers at PaloAlto Networks Unit 42 in their blog post about targeted attacks against organizations in Thailand [3].

 

In this threat advisory we will go over the network and host behavior in RSA NetWitness Packets and Endpoint.

 

Upon opening the malicious readme.rtf in Microsoft Word, there was the request for the SOAP payload:

 

 

 

Next comes the request to download the HTA script:

 

 

 

The script is executed and a binary is downloaded:

 

 

 

 

The binary is executed and it downloads a dropper:

 

 

 

For the downloader process (httpx.exe), NetWitness Endpoint has more information about its strings, its tracking data, its path and its network connectivity:

 

 

 

 

 

NetWitness Endpoint generates the following IIOC for httpx.exe:

  • Direct IP request from unsigned module
  • Direct IP request from unsigned process
  • Unsigned writes executable
  • Renames file to executable
  • Unsigned writes executable to Windows directory
  • Compiled in last month
  • In temporary directory
  • Process accesses network

 

The dropper (invo.exe) drops a MoonWind variant (svcohos.exe) to the infected machine. It runs a batch file to delete itself:

 

The new process (svcohos.exe) copies itself to a new location, gains persistency on the system and starts to communicate with its command and control server:

 

 

 

 

NetWitness Endpoint generates the following IIOC for svcohos.exe:

  • Autorun unsigned hidden
  • Autorun unsigned uncommon registry startup method
  • Autorun unsigned only executable in directory
  • Suspicious AutoStart profile #1
  • Unsigned copyitself autorun
  • In hidden directory
  • Unsigned writes executable
  • Unsigned opens phiscal drive
  • Unsigned writes executable and create process on same file
  • Modifies run key
  • Unsigned copy itself
  • Autorun
  • Network access
  • In temporary directory
  • In ProgramData directory
  • In uncommon directory
  • DNS traffic from process
  • Process access network
  • Runs command shell

 

However, the infected system failed to establish a connection with the C2 server. Here is a recap of the network traffic:

 

 

and here is another look at the process tree:

 

 

readme.rtf (SHA256):

  • 0d5ec16b1affc1d85b335291aa9b89d1679865d913ccd5aa5f6093a6a4797d51

 

httpx.exe (SHA256):

  • 72bf1b9136654fd34f469065c086d91634c10ea612e56da6b64a04317f697802

 

svcohos.exe (SHA256):

  • 2175007a69be40a99f78fc565ec5ccda0d681a3c47b4bcb835c6682d72f7f6b0

 

 

References:

  1. FireEye Uncovers CVE-2017-8759: Zero-Day Used in the Wild to Distribute FINSPY « Threat Research Blog | FireEye Inc 
  2. https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2017-8759 
  3. https://researchcenter.paloaltonetworks.com/2017/03/unit42-trochilus-rat-new-moonwind-rat-used-attack-thai-utility-organ… 
Ahmed Sonbol

Malspam and CVE-2017-8759

Posted by Ahmed Sonbol Employee Sep 18, 2017

On September 12th FireEye security researchers disclosed information about CVE-2017-8759, a SOAP WSDL parser code injection vulnerability [1]. Microsoft already released patch to address the vulnerability in affected products [2]. It didn't take a lot of time to start seeing a significant increase in the number of malicious files trying to exploit the vulnerability. A day or two after the disclosure there was a handful of samples submitted to VirusTotal. A week later more than a hundred samples were submitted. It indicates that exploiting the vulnerability is shifting from targeted attacks to mass distribution.

 

In this blog post we will discuss the host and network behavior of one of those samples and see how the activities look in RSA NetWitness Packets and NetWitness Endpoint.

 

The delivery document under investigation is spreading as Quote.doc. Upon opening the RTF in Microsoft Word, an HTTP request was noticed:

 

 

For this session, NetWitness Packets registered the following meta under Service Analysis suggesting suspicious network traffic:

 

  

The WSDL parser handles the SOAP response. The following events took place on the infected host:

  • A .cs source code file (Logo.cs in this case) was generated in C:\Windows\System32\com\SOAPAssembly
  • csc.exe compiled the generated source code into a DLL file (http100googlegtv4com0pppp0office4png.dll in this case).
  • Microsoft Word loaded the generated DLL file,
  • An HTTP request was sent (to the same server) to retrieve a script.
  • mshta.exe was called to run the downloaded script.

 

The next screenshot shows the machine scandata on NetWitness Endpoint:

 

 

Here is an event reconstruction of the second payload delivery:

 

 

 

The screenshot below shows the files created in C:\Windows\System32\com\SOAPAssembly

 

 

Here is a better look at the content of the newly created source code file Logo.cs:

 

 

When the second payload ran, it issued an HTTP request to a direct IP address in order to download an obfuscated powershell script:

 

 

 

When powershell.exe ran, it dropped an executable on the victim machine: 

 

 

The dropped executable is a LaZagne variant. LaZagne is a publicly available open source application to retrieve passwords stored on a local computer. VirusTotal analysis results can be found here. Here is the report from hybrid-analysis.com. On NetWitness Endpoint the following module IIOC were generated:

  • In root of AppDataRoaming directory
  • Unsigned writes executable
  • Unsigned writes executable to users directory
  • Unsigned writes executable to AppDataLocal directory
  • Self delete
  • In AppData directory

 

 

Following the execution of LaZagne.exe, you can notice a newly created process AZAaPaAA.exe which is also a LaZagne variant according to VirusTotal analysis results. Analysis report from hybrid-analysis.com is available here. NetWitness Endpoint generated even more IIOC for this module:

  • In root of Program directory
  • In root of AppDataRoaming directory
  • In hidden directory
  • Unsigned opens OS process
  • Unsigned writes executable
  • Unsigned writes executable to Windows directory
  • Unsigned writes executable to users directory
  • Unsigned writes executable to AppDataLocal directory
  • Self delete
  • Unsigned copy itself
  • Runs powershell with long arguments
  • In AppData directory
  • In ProgramData directory
  • Unsigned opens process
  • Runs command shell
  • Runs powershell

 
A quick look at the embedded strings of those binaries confirm what kind of data they are targeting:

 

 

 

Finally, below is a recap of the HTTP traffic in NetWitness Packets:

 

 

Delivery document (SHA256):

  • 640b9b789efe66bca20812af4f4e017bb7524ee8a6a4ec5e153a73af9bd0a007

 

LaZagne binaries (SHA256):

  • 3f6e8dea07b6e87182b3068868746e5054123a7c86e04d775292af7ffd1ce9b4
  • 9485a1630d9283d7efee3828fca32d72cfcb3fb1e91015a9753df09a21f14da2

 

References:

  1. FireEye Uncovers CVE-2017-8759: Zero-Day Used in the Wild to Distribute FINSPY « Threat Research Blog | FireEye Inc 
  2. https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/CVE-2017-8759  

In our introductory post to Cryptocurrency, we mentioned that one of the threats to organizations these days is malware distributing cryptocurrency mining software. In this blog post we will discuss the host and network behavior of two malware samples used to drop or download Monero mining software. According to its website, Monero is an open source, secure, private and untraceable cryptocurrency. At the time of this writing, one monero is valued a little above $98 [1].

 

Before we delve into the topic of this threat advisory, it is worth mentioning that mining software itself is not malicious. Guaranteed it has a major impact on system resources but that's the "price" you pay for running such software. However, if you have no idea it is running on your system then it is a different story. An attacker infecting systems left and right to enroll them in a botnet to mine coins and enrich his wallet, that's certainly malicious.

 

First, let's take a look at a Smoke Loader variant. Smoke Loader first appeared on the black market in 2011. It is used to download malware to an infected system [2]. Upon infecting a system, the following network events take place.

 

 

Initially was a POST request to 21072206[.]ru

 

 

In response to that request, the server is sending a 404 Error. However, it is not you average 404 page. Session reconstruction shows an obfuscated payload. It was quickly followed by another POST request to download an executable.

 

 

 

Here is the populated meta under Service Analysis and File Analysis for those HTTP sessions in NetWitness Packets:

 

 

According to VirusTotal analysis results, the binary is a coin miner. Embedded strings suggest that it is an XMRig variant. XMRig is a high performance Monero CPU miner.

 

 

When the miner runs, it starts communicating with a pooled mining server at 91.121.87.10

 

 

Pooled mining allows machines with limited resources to join others in contributing to generate a block. The reward for the block generation is then split among the clients based on their processing power contribution [3]. The clients communicate with the server using a protocol called Stratum [4]. It is basically JSON-RPC over TCP as shown in the screenshot above. After authenticating to the server, the client waits for new mining jobs.

 

Next, let's take a look at an XMRig dropper. When it infects a system, the process (sample.exe in this case) starts the following chain of events on the host:

 

 

  • It drops an executable lasse.exe in C:\Windows\System32 (SHA256: 8acdb1fae3a564d1e1145e37e1933dea18bd9722f0889b4bf00a2bbb441a9a25)
  • It uses sc.exe and net.exe to start a new service using the dropped file above
  • It modifies the registry in order for lasse.exe to gain persistency on the system
  • lasse.exe drops another executable kernel.exe in C:\Windows\Temp and starts it in the background passing the username and password to connect to the pooled mining server.

 

kernel.exe (sha256: 9e5b3da1e5ece578ff99525d1ea565df458cdd62b305404336303ca8ca97f562) is another XMRig variant. You can find its VirusTotal analysis results here

 

The following screenshots from NetWitness Endpoint give us even more information:

 

 

 

 

 

 

Here is another look at the process tree:

 

 

XMRig comes with a help switch making it easier to understand the command line arguments:

 

 

 

Smoke Loader (SHA256):

  • 9770669d4b864a167dd0a4b684126d6b077889b8cb903dd969b5c5929e565584

 

XMRig dropper (SHA256):

  • da21bef9cb9721e632b7deebfdf6190169be7fe2fa7fd574f741dc3272a594e9

 

XMRig miners (SHA256):

  • 954e8e88740fd3e659fd4ad0502982dd173db2d90cfca0718bfc739bf886d51c
  • 9e5b3da1e5ece578ff99525d1ea565df458cdd62b305404336303ca8ca97f562

 

References:

  1. https://www.worldcoinindex.com/coin/monero 
  2. https://blog.malwarebytes.com/threat-analysis/2016/08/smoke-loader-downloader-with-a-smokescreen-still-alive/ 
  3. https://en.bitcoin.it/wiki/Pooled_mining 
  4. https://en.bitcoin.it/wiki/Stratum_mining_protocol 

When time is of the essence and every second counts, organizations know that they can depend on the RSA NetWitness Suite to help accelerate their capabilities to detect and respond to the threats that matter the most.  That’s because our product teams, our services teams, and our threat research teams are the best in the business – practitioners who have been and continue to fight on the cybersecurity front lines each and every day. 

 

RSA Charge 2017 offers a fantastic opportunity for our customers to get face-to-face with our RSA experts and engage with them in our “Detecting and Responding to the Threats that Matter” track at the event.  This track is loaded with specialists and experts who are chomping at the bit to share knowledge and insights from the world of advanced threat detection and response with the rest of the RSA Community.

 

Here is just a handful of the sessions you’ll be able to attend in Dallas:

  • From Discovery to Remediation in 9 Days – This session dives into a real-life case study of an incident response engagement with a sophisticated and nuanced attacker to present lessons learned and insights.
  • Hunting APTs with RSA NetWitness Endpoint and Packets – How do you find those threats that go beyond “just malware”?  We’ll show you how.  This session will show how to identify an attack with both RSA NetWitness Endpoint and RSA NetWitness Packets.
  • Analyzing and Understanding Criminal Ecosystems – There is a vast capitalist ecosystem where stolen data is the product.  To fight this enemy more completely, we must understand them.  This session will dive into today’s crimeware communities.
  • Threat Hunting for Everyone – Think you need decades of experience to be an effective threat hunter?  Think again.  Learn how to quickly carve through all the data and be an effective threat hunter with two of RSA's premier threat hunters!

 

But that’s not all.  The track will also feature a number of case studies and technical content designed to deliver real world insights that RSA Charge attendees can take back home and immediately leverage in their organizations.  Click here to review the sessions in the “Detecting and Responding to the Threats that Matter” track or click here to review the complete listing of all sessions.

 

RSA Charge 2017 in Dallas is going to be bigger and better than last year, so what are you waiting for?  Register now by clicking here and carve out your own agenda.  We’ll see you in Dallas!

___

 

RSA Charge 2017, the premier event on RSA® Business-Driven Security™ solutions, unites an elite community of customers, partners and industry experts dedicated to tackling the most pressing issues across cybersecurity and business risk management. Through a powerful combination of keynote speeches, break-out sessions and hands-on demos, you’ll discover how to implement a Business-Driven Security strategy to help your organization thrive in an increasingly uncertain, high-risk world. Join us October 17 – 19 at the Hilton Anatole in Dallas, Texas.

RSA Charge 2017: Time is Running Out; Take Advantage of Several Registration Discounts That Expire EOD Friday, September 15

 

This year’s RSA Charge event is definitely one not to miss. If you have not yet registered please do so today to secure the Discount Rate of $745, saving you $200 through September 15. Registration on the RSA Charge 2017 website couldn’t be easier.

 

Still on the fence? Check out the Full Agenda with over 90 sessions, 35 hands-on labs, and 140+ thought leader industry experts you’ll agree this is the premier event on RSA Business-Driven Security™ solutions. You can also take this opportunity to build your own personal business-driven security experience for Charge.

  

Another way to save: Friends with Benefits! They say sharing is caring, so ‘already registered’ RSA Charge attendees can now share the love by forwarding this code to a peer or colleague and he/she will receive $100 off the current $745 registration fee by using this code from you: FRIENDS17. This code too expires on Sept. 15, so share the love today!

 

And, finally, in case there are still some doubters amongst you, watch these two RSA Charge videos – you’ll be convinced that RSA Charge 2017 is the place to be seen and heard, Oct. 17-19 @ Hilton Hotel Anatole, Dallas. See you soon!

 

RSA President Rohit Ghai

RSA NetWitness Amy Blackshaw

 

RSA Charge 2017, the premier event on RSA® Business-Driven Security™ solutions, unites an elite community of customers, partners and industry experts dedicated to tackling the most pressing issues across cybersecurity and business risk management. Through a powerful combination of keynote speeches, break-out sessions and hands-on demos, you’ll discover how to implement a Business-Driven Security strategy to help your organization thrive in an increasingly uncertain, high-risk world. Join us October 17 – 19 at the Hilton Anatole in Dallas, Texas.

On September 6th, malspam delivered a malicious RTF document that tries to exploit Microsoft Office/WordPad via a remote code execution (RCE) Vulnerability in the Windows API, CVE-2017-0199 [1][2]. This document has been spotted in-the-wild travelling as an email attachment with different names; one of which is “Remittance details.doc” (VirusTotal analysis).  

 

 

 

Opening the document in a vulnerable Microsoft Word application led to the following network events:

 

Below is a breakdown of the network activity.  First "blabla.hta" (VirusTotal and Hybrid-Analysis) was downloaded; this file contains an obfuscated script with a powershell command.  

  

Next the powershell command runs and downloaded an executable, “halizeuskins.exe” (VirusTotal and Hybrid-Analysis). 

 

Once the download is complete, the binary is executed and post-infection traffic started.

 

Current RSA NetWitness detection populates following meta for the download sessions:

 

For communication with the C2 domain, the following meta was populated for those sessions in NetWitness Packets:

 

Pivoting off the registration information of the C2 domain "reedling.com[.]ng", FirstWatch found a group of domains registered using the same e-mail address (see appendix).

 

Some of those domains are associated with different malware samples (see appendix). The post-infection network behavior of one of them (SHA256:e078e842c1006c972a65dcb71cf6ae5b38ba5074ea19f999f9879e8ec73a65f2) is similar to the one under our investigation. VirusTotal analysis results for that sample suggest it is a Zbot variant.

 


  

More information about Zbot variants and their detection using RSA NetWitness Suite:

 

You can also check FirstWatch recent threat advisory on the recent uptick in malspam attempting to exploit CVE-2017-0199,
Malspam and CVE-2017-0199 

 

Thanks go to Ahmed Sonbol and Kevin Stear for contributing to this threat advisory.

 

 

References:

Microsoft Office 365 is a Web-based version of Microsoft's Office suite of enterprise-grade productivity applications. Office 365 is delivered to users through the cloud and includes Exchange Online for email, SharePoint Online for collaboration, Lync Online for unified communications, and a suite of Office Web Apps (web-based versions of the traditional Microsoft Office suite of applications).

 


The Office 365 integration consumes activity logs using the Office 365 Management Activity API. The Office 365 Management Activity API aggregates actions and events into tenant-specific content blobs, which are classified by the type and source of the content they contain. Currently, the following content types are supported by this API:

 

  • Audit.AzureActiveDirectory
  • Audit.Exchange
  • Audit.SharePoint
  • Audit.General (includes all other workloads not included in the previous content types)
  • DLP.All (DLP events only for all workloads)

 

Please note that only the Common schema and Exchange Mailbox schema is supported by default. All other schemas can be added manually as needed. 

 

Configuration GuideMicrosoft Office 365 Event Source Configuration Guide 

Collector Package on RSA Live: "MS Office 365 Log Collector Configuration"

Parser on RSA Live: CEF

Filter Blog

By date: By tag: