Daily Archives: January 2, 2019

NRSMiner updates to newer version

More than a year after the world first saw the Eternal Blue exploit in action during the May 2017 WannaCry outbreak, we are still seeing unpatched machines in Asia being infected by malware that uses the exploit to spread. Starting in mid-November 2018, our telemetry reports indicate that the newest version of the NRSMiner cryptominer, which uses the Eternal Blue exploit to propagate to vulnerable systems within a local network, is actively spreading in Asia. Most of the infected systems seen are in Vietnam.


November-December 2018 telemetry statistics for NRSMiner, by country

In addition to downloading a cryptocurrency miner onto an infected machine, NRSMiner can download updated modules and delete the files and services installed by its own previous versions.

This post provides an analysis of how the latest version of NRSMiner infects a system and finds new vulnerable targets to infect. Recommendations for mitigation measures, IOCs and SHA1s are listed at the end of the post.


How NRSMiner spreads

There are 2 methods by which a system can be infected by the newest version of NRSMiner:

  • By downloading the updater module onto a system that is already infected with a previous version of NRSMiner, or:
  • If the system is unpatched (MS17-010) and another system within the intranet has been infected by NRSMiner.


Method 1: Infection via the Updater module

First, a system that has been infected with an older version of NRSMiner (and has the wmassrv service running) will connect to tecate[.]traduires[.]com to download an updater module to the %systemroot%\temp folder as tmp[xx].exe, where [xx] is the return value of the GetTickCount() API.

When this updater module is executed, it downloads another file to the same folder from one of a series of hard-coded IP addresses:


List of IP addresses found in different updater module files

The downloaded file, /x86 or /x64, is saved in the %systemroot%\temp folder as WUDHostUpgrade[xx].exe; again, [xx] is the return value of the GetTickCount() API.


The WUDHostUpgrade[xx].exe first checks the mutex {502CBAF5-55E5-F190-16321A4} to determine if the system has already been infected with the latest NRSMiner version. If the system is infected, the WUDHostUpgrade[xx].exe deletes itself. ­Otherwise, it will delete the files MarsTraceDiagnostics.xml, snmpstorsrv.dll, MgmtFilterShim.ini.

Next, the module extracts the following files from its resource section (BIN directory) to the %systemroot%\system32 or %systemroot%\sysWOW64 folder: MarsTraceDiagnostics.xml, snmpstorsrv.dll.

It then copies the values for the CreationTime, LastAccessTime and LastWritetime properties from svchost.exe and updates the same properties for the MarsTraceDiagnostics.xml and snmpstorsrv.dll files with the copied values.

Finally, the WUDHostUpgrade[xx].exe installs a service named snmpstorsrv, with snmpstorsrv.dll registered as servicedll. It then deletes itself.



Pseudo-code for WUDHostUpgradexx.exe’s actions


Snmpstorsrv service

The newly-created Snmpstorsrv service starts under “svchost.exe -k netsvcs” and loads the snmpstorsrv.dll file, which creates multiple threads to perform several malicious activities.


Snmpstorsrv service’s activities

The service first creates a file named MgmtFilterShim.ini in the %systemroot%\system32 folder, writes ‘+’ in it and modifies its CreationTime, LastAccessTime and LastWritetime properties to have the same values as svchost.exe.

Next, the Snmpstorsrv service extracts malicious URLs and the cryptocurrency miner’s configuration file from MarsTraceDiagnostics.xml.


Malicious URLs and miner configuration details in the MarsTraceDiagnostics.xml file

On a system that is already infected with an older version of NRSMiner, the malware will delete all components of its older version before infecting it with the newer one. To remove the prior version of itself, the newest version refers to a list of services, tasks and files to be deleted that can be found as strings in the snmpstorsrv.dll file;  to remove all older versions, it refers to a list that is found in the MarsTraceDiagnostics.xml file.


List of services, tasks, files and folders to be deleted

After all the artifacts of the old versions are deleted, the Snmpstorsrv service checks for any updates to the miner module by connecting to:

  • reader[.]pamphler[.]com/resource
  • handle[.]pamphler[.]com/modules.dat

If an updated miner module is available, it is downloaded and written into the MarsTraceDiagnostics.xml file. Once the new module is downloaded, the old miner file in %systemroot%\system32\TrustedHostex.exe is deleted. The new miner is decompressed in memory and the newly extracted miner configuration data is written into it.

This newly updated miner file is then injected into the svchost.exe to start crypto-mining. If the injection fails, the service instead writes the miner to %systemroot%\system32\TrustedHostex.exe and executes it.


The miner decompressed in memory

Next, the Snmpstorsrv service decompresses the wininit.exe file and injects it into svchost.exe. If the injection fails, it writes wininit.exe to %systemroot%\AppDiagnostics\wininit.exe and executes it. The service also opens port 60153 and starts listening.

In two other threads, the service sends out details about the infected system to the following sites:

  • pluck[.]moisture[.]tk – MAC address, IP Address, System Name, Operating System information
  • jump[.]taucepan[.]com – processor and memory specific information
Click to view slideshow.

System information forwarded to remote sites

Based on the information sent, a new updater file will be downloaded and executed, which will perform the same activities as described in “Updater Module” section above. This updater module can be used to infect systems with any new upcoming version of NRSMiner.


Method 2: Infection via Wininit.exe and Exploit

In the latest NRSMiner version, wininit.exe is responsible for handling its exploitation and propagation activities. Wininit.exe decompresses the zipped data in %systemroot%\AppDiagnostics\blue.xml and unzips files to the AppDiagnostics folder. Among the unzipped files is one named svchost.exe, which is the Eternalblue – 2.2.0 exploit executable. It then deletes the blue.xml file and writes 2 new files named x86.dll and x64.dll in the AppDiagnostics folder.

Wininit.exe scans the local network on TCP port 445 to search for other accessible systems. After the scan, it executes the Eternalblue executable file to exploit any vulnerable systems found. Exploit information is logged in the process1.txt file.

If the vulnerable system is successfully exploited, Wininit.exe then executes spoolsv.exe, which is the DoublePulsar – 1.3.1 executable file. This file installs the DoublePulsar backdoor onto the exploited system. Depending on the operating system of the target, either the x86.dll or x64.dll file is then transferred by Wininit.exe and gets injected into the targeted system’s lsass.exe by the spoolsv.exe backdoor.


Propagation method


This file creates a socket connection and gets the MarsTraceDiagnostics.xml file in %systemroot%\system32 folder from the parent infected system. It extracts the snmpstorsrv.dll, then creates and starts the Snmpstorsrv service on the newly infected system, so that it repeats the whole infection cycle and finds other vulnerable machines.

Miner module

NRSMiner uses the XMRig Monero CPU miner to generate units of the Monero cryptocurrency. It runs with one of the following parameters:


Miner parameters

The following are the switches used in the parameters:

  • -o, –url=URL                  URL of mining server
  • -u, –user=USERNAME username for mining server
  • -p, –pass=PASSWORD  password for mining server
  • -t, –threads=N               number of miner threads
  • –donate-level=N           donate level, default 5% (5 minutes in 100 minutes)
  • –nicehash                      enable nicehash.com support



F-Secure products currently detect and block all variants of this malware, with a variety of detections.

Mitigation recommendations

The following measures can be taken to mitigate the exploitation of the vulnerability targeted by Eternal Blue and prevent an infection from spreading in your environment.

  • For F-Secure products:
    • Ensure that the F-Secure security program is using the latest available database updates.
    • Ensure DeepGuard is turned on in all your corporate endpoints, and F-Secure Security Cloud connection is enabled.
    • Ensure that F-Secure firewall is turned on in its default settings. Alternatively, configure your firewall to properly block 445 in- and outbound traffic within the organization to prevent it from spreading within the local network.
  • For Windows:
    • Use Software Updater or any other available tool to identify endpoints without the Microsoft-issued security fix (4013389) and patch them immediately.
    • Apply the relevant security patches for any Windows systems under your administration based on the guidance given in Microsoft’s Customer Guidance for WannaCrypt attacks.
    • If you are unable to patch it immediately, we recommend that you disable SMBv1 with the steps documented in Microsoft Knowledge Base Article 2696547 to reduce attack surface.


Indicator of compromise – IOC:


32ffc268b7db4e43d661c8b8e14005b3d9abd306 - MarsTraceDiagnostics.xml
07fab65174a54df87c4bc6090594d17be6609a5e - snmpstorsrv.dll
abd64831ad85345962d1e0525de75a12c91c9e55 - AppDiagnostics folder (zip)
4971e6eb72c3738e19c6491a473b6c420dde2b57 - Wininit.exe
e43c51aea1fefb3a05e63ba6e452ef0249e71dd9 – tmpxx.exe
327d908430f27515df96c3dcd180bda14ff47fda – tmpxx.exe
37e51ac73b2205785c24045bc46b69f776586421 - WUDHostUpgradexx.exe
da673eda0757650fdd6ab35dbf9789ba8128f460 - WUDHostUpgradexx.exe
ace69a35fea67d32348fc07e491080fa635cc859 - WUDHostUpgradexx.exe
890377356f1d41d2816372e094b4e4687659a96f - WUDHostUpgradexx.exe
7f1f63feaf79c5f0a4caa5bbc1b9d76b8641181a - WUDHostUpgradexx.exe
9d4d574a01aaab5688b3b9eb4f3df2bd98e9790c - WUDHostUpgradexx.exe
9d7d20e834b2651036fb44774c5f645363d4e051 – x64.dll
641603020238a059739ab4cd50199b76b70304e1 – x86.dll

IP addresses:




I found a GCP service account token…now what?

Google Cloud Platform (GCP) is rapidly growing in popularity and i haven't seen too many posts on  f**king it up so I'm going to do at least one :-)

Google has several ways to do authentication but most likely what you are going to come across shoved into code somewhere or in a dotfiles is a service account json file.

It's going to look similar to this:

These service account files are similar to AWS tokens in that it can be difficult to determine what they have access to if you don't already have console and/or IAM access. However with a little bit of scripting we can brute force at least some of the token's functionality pretty quickly. The issue being service accounts for something like GCP compute looks the same as one you made to manage your calendar or one of the 100's of other Google services.

You'll need to install the gcloud tools for you OS. Info here:  https://cloud.google.com/sdk/

Once you have the gcloud suite of tools installed you can auth with the json file with the following command:

gcloud auth activate-service-account --key-file=KEY_FILE

If they key is invalid you'll see something like the below:

gcloud auth activate-service-account --key-file=21.json
ERROR: (gcloud.auth.activate-service-account) There was a problem refreshing your current auth tokens: invalid_grant: Not a valid email or user ID.

Otherwise it will look similar to below:

gcloud auth activate-service-account --key-file=/Users/CG/Documents/pentest/gcp-weirdaal/gcp.json
Activated service account credentials for: [python@removed.iam.gserviceaccount.com]

you can validate it worked by issuing gcloud auth list command:

gcloud auth list
                  Credentialed Accounts

*       python@removed.iam.gserviceaccount.com

I put together a shell script that runs though a bunch of command to enumerate information. They only you info need to provide is the project name. This can be found in the json file in the project_id  field or by issuing the  gcloud project list command.  Sometimes there are multiple projects associated with an account and you'd need to run the shell script with for each project.

The first time you run these api calls you might need to pass a "Y" to the cli to enable it. you can get around this manual shenanigans by doing a:

yes | ./gcp_enum.sh 

This will answer Yes for you each time :-)

NCC Group also has two tools you could check out:






Hackers seize dormant Twitter accounts to push terrorist propaganda

As much progress as Twitter has made kicking terrorists off its platform, it still has a long way to go. TechCrunch has learned that ISIS supporters are hijacking long-dormant Twitter accounts to promote their ideology. Security researcher WauchulaGhost found that the extremists were using a years-old trick to get in. Many of these idle accounts used email addresses that either expired or never existed, often with names identical to their Twitter handles -- the social site didn't confirm email addresses for roughly a decade, making it possible to use the service without a valid inbox. As Twitter only partly masks those addresses, it's easy to create those missing addresses and reset those passwords.

Source: TechCrunch

What do La Croix, octonions, and Second Life have in common?

This year for CSAW CTF, Trail of Bits contributed two cryptography problems. In the first problem, you could combine two bugs to break DSA much like the Playstation 3 firmware hackers. The other challenge–-weirder and mathier–-was split into two parts: one for the qualifiers, one in finals. This challenge, “Holywater,” was some of the most fun I’ve ever had making a CTF problem.

The qualifier challenge was a pretty textbook CTF cryptography challenge. Contestants began with a script and a text file of past outputs (preserved on Github), and had to recover a secret passphrase. Spoilers follow below the (extremely relevant) image, if you’d like to try it yourself.

Before diving into my own solution, I first want to commend Galhacktic Trendsetters for their excellent writeup (if any of you Trendsetters are reading this, get in touch, I’d love to mail you some swag). They covered the mathematical foundations of the attack with eloquence, a topic which I won’t get into in quite as much depth here. It’s also an excellent walkthrough of the thought process that lets a team start with nothing but a python file and a few hex strings and develop a working attack in less than 48 hours.

The challenge’s python file didn’t make that easy. It was called “lattice.py,” which might immediately suggest it has something to do with lattice cryptography. The method names included, among other things “isogeny,” “gaussian,” and “wobble.” Even the above writeup acknowledges some confusion about the terms’ meanings.

In reality, more or less every name in that file is a red herring. It implements HK17 key exchange, a proposed new post-quantum key exchange mechanism that was proven totally unworkable by Li, Liu, Pan, and Xie. The mathematical construction underlying HK17 is not lattices or isogenies, but octonions! Octonions are eight-dimensional hypercomplex numbers used in theoretical physics with a number of counterintuitive properties.

Perhaps the easiest way to understand octonions is by constructing them from scratch. Most readers will already be familiar with complex numbers, a two-dimensional superset of real numbers that is algebraically closed, a property that makes many kinds of math much easier. We construct the complex numbers using the Cayley-Dickson construction. Effectively, we double the number of dimensions and define multiplication much as we would in a direct sum (though not in exactly the same way).

We can repeat this process on complex numbers to yield a four-dimensional set of numbers known as the quaternions. Readers with graphics programming experience may be familiar, as quaternions allow for efficient computation of rotations in three-dimensional space, and are thus used by many graphics libraries. One more application of the Cayley-Dickson process takes us to eight dimensions; the octonions we use for our cryptosystem.

However, the Cayley-Dickson process cannot preserve every property of a number system we might want. Complex numbers, unlike their real counterparts, are not orderable (they can’t just be laid out end to end on a line). Quaternions are also unorderable, but unlike reals or complex numbers, have noncommutative multiplication! If a and b are quaternions, a * b and b * a can yield different numbers. This gradual loss of invariants continues with octonions, which aren’t even associative; if d, e, and f are octonions, (d * e) * f may well not equal d * (e * f).

“The real numbers are the dependable breadwinner of the family, the complete ordered field we all rely on. The complex numbers are a slightly flashier but still respectable younger brother: not ordered, but algebraically complete. The quaternions, being noncommutative, are the eccentric cousin who is shunned at important family gatherings. But the octonions are the crazy old uncle nobody lets out of the attic: they are nonassociative.” – John Baez

This is fairly gnarly, by the standards of numbers we choose to use, and explains to a degree why octonions aren’t used frequently (keep the attic door shut!). However, it also appears to allow for exactly the kind of hard problem we want when building a key exchange system! By working with polynomials over the octonions, the HK17 authors create a Diffie-Hellman style key exchange system they claim is quantum-hard.

However, in real life this system can be reliably broken by college students over the course of a weekend (nine teams solved it). Octonions’ odd multiplication rules end up making factoring far easier! With a few octonion identities and a high schooler’s knowledge of linear algebra, the cryptosystem reduces to four variables in four linear equations, and can be solved in O(1) by a python script that runs almost instantaneously.

An astute reader may pause here, with complete knowledge of the problem, and wonder “why was this challenge called Holywater?” The answer has nothing to do with octonion key exchange, and everything to do with my plans for the second half of the problem. The HK17 draft defined systems not just on octonions, but on unit quaternions (quaternions of magnitude one) as well! And, since quaternions are used by so many more programmers (as mentioned above, for graphics) that opens some interesting doors.

Specifically, it means we can now define our system in Linden Scripting Language, the official scripting language of Second Life. I’ve always been a bit of a programming language snob. For a while, I thought PHP was the absolute bottom of the barrel. Nothing could possibly be worse than that fractal of bad design, created largely by accident. Later in life I began working on blockchain security, and learned about the language Solidity. Suffice to say, my mind has since changed. Neither language, however, compares to the absolute tire fire that is Linden Scripting Language. Seriously, just read how you parse JSON.

LSL has a built-in quaternion type, and, while the “Differences Between Math’s Quaternions and LSL’s [Quaternions]” might seem foreboding, they are completely workable for our purposes. And, writing the whole challenge in LSL meant the competitors could have even more fun reverse engineering. However, I needed help to develop the Second Life scripts, design objects for them to be attached to, lease space in Second Life, and generally do the non-mathy parts of the whole project.

This is where the name comes in. The final part was called “Holywater 2: La Croix” specifically to entice Dan “Pamplemousse” Hlavenka, a friend of mine who loves both LSL and La Croix more than any other person I know of. He was willing to help with every part of the Second Life portion, but only if we made the challenge La Croix themed in every way we could, to spread the gospel to the next generation.
Competitors were greeted by the below acrostic, which, when the blanks are filled in, describes both a location in Second Life and half-dozen La Croix flavors.

                                P    P
                                E  M A
                               PA  AOM
                               UC BNRP
     M                         E PRONE
     O                          PRR GM
     K                          EIY EO
     E                          AC   U
                                RO   S
     W                           T   S
     E                               E

Once teams arrive, they find themselves inside a giant can of La Croix, underwater (and with particle effects for carbonation). The location in Second Life was renamed “Mud City” after LaCrosse Wisconsin, home of the beverage. They are then presented with two glowing orbs, reading “Click here for everything you need” and “Click here to die instantly.”

These labels are accurate. That did not stop many people from repeatedly clicking the “die instantly” orb however, perhaps in an attempt at some sort of reincarnation-based cryptanalysis. The “everything you need” orb in contrast, gives the player an IBM Selectric typeball. Since unit quaternions describe rotations, we elected to encode the message by physically rotating one such typeball (as in normal Selectric operation), agreeing on rotations via HK17 key exchange in Second Life’s chat box. Users could see a script attached to the type ball that outlined the whole process, though again, some attempted other strategies (see below).

Nonetheless, the math was much the same, if harder to apply. This time only two teams (MIT and CMU) found the final flag (another clever La Croix reference), with the first blood winning a case of La Croix for each team member as a bonus on top of the (unusually high) 600 points (typically, challenges are 100 points if extremely easy, 500 points if extremely hard). By reversing the script and scraping the chat, the same process that worked for quals can work here. All that’s left is rotating your typeball and watching which letter is on the bottom.

Dan’s lease on the land in Second Life is now up, so the challenge is unfortunately closed to the public. Dan’s La Croix contributions ended up far more popular than I expected though, so perhaps this challenge won’t be the last to feature the beverage. This challenge is perhaps less applicable than the qualifier, but its lesson remains valid: if you’re securing a remote-control typewriter sending La Croix secrets in Second Life, don’t use HK17.

P.S.: While the last minute removal of csaw.tv meant this never saw the light of competition, you can enjoy this La Croix themed playlist Dan and I made for a special csaw.tv only accessible from Second Life.

Cyber Security Predictions for 2019

A guest article authored by Jim Ducharme, Vice President of Engineering and Product Management at RSA

1. Prepare for IOT, the “Identity of Things”
From personal assistants, to wearables, smartphones, tablets and more, there is no shortage of connected devices. The explosion of IOT has finally reached a tipping point where the conversation of identity will start to take on a whole new meaning. The billions of new digital identities being created don’t come without risk – including new privacy and cybersecurity vulnerabilities. With businesses and consumers all in on IOT, how do we protect and securely manage the “identity” of the things? 

2. Biometrics vs. the Four-Digit Pin
Biometrics are under a lot of pressure these days to be the silver bullet of authentication. So how could a simple 4-digit pin, which has at most 10,000 possible combinations, give biometrics like FaceID with a 1 in 50 million entropy a run for its money? The industry will come to realize when 4-digit pins are combined with AI and machine learning, the four-digit pin, similar to what has been used for decades to protect access to our bank accounts, can provide a very high level of security. The ultimate goal for identity and access management is not to find the unbreakable or “unhackable” code for authentication, but rather, to layer security to create a much stronger identity assurance posture. AI and machine learning will be a game changer, allowing for intelligence-driven authentication that will open up additional options of security layers for organizations.  

3. Death of the Password?
We have long seen predictions that passwords are in their final days. But it’s time to come to grips that passwords will be here for a long time. But perhaps there is still hope that while we may be living with passwords for generations to come, they may be a lot less scary than the monster we have created. It’s time to reverse the trend of how complex passwords have become (MyKitsH8Me!) and how hard they are to manage (having to change them every 60 days) in an attempt to improve password strength. We can uncomplicate the password and unburden it from having the ultimate responsibility of security. A much more simple password coupled with additional layers of risk-based authentication, especially those factors invisible to the user like behavioral, location and device context, and even transparent biometrics can help businesses better secure access to critical resources.

4. A New Generation of Risk-based Authentication
With a seemingly endless stream of high-profile data breaches and malicious cyberattacks, the need to ramp up security and manage identities is evident. 2019 will see the beginning of a new generation of risk-based authentication, powered by machine learning and user behavior analytics. Organizations will start to uncover their own unique context and identity insights to gain a more comprehensive view of user identities including locations, behavior patterns, frequency of use and more. This new generation of risk-based authentication will allow organizations to reduce the friction on end users when accessing applications and information while strengthening the assurance that the user is who they claim to be.

Jim Ducharme, Vice President of Engineering and Product Management at RSA