The Zero2Hero malware course continues with Daniel Bunce demonstrating how to write a custom tool to load, execute and debug malicious shellcode in memory.

Recently, FireEye posted a blog post detailing malware used by APT 41, specifically the DEADEYE initial first stage, capable of downloading, dropping or loading payloads on an infected system, and the LOWKEY backdoor. Additionally, they described an additional “RC4 Layer”, which is Position Independent Code (PIC) that RC4 decrypts an embedded payload and loads it into memory using it’s reflective DLL loader capabilities.

Unlike Windows executables, shellcode doesn’t have any headers, meaning the Windows loader cannot execute standalone shellcode. As a result, debugging is impossible without an external tool to load and execute shellcode for you. Therefore, in this blog post, we will cover how to write a tool in C to load shellcode into memory and wait until a debugger is attached before executing it. But first, why do we need to debug shellcode?

Why Debugging Position Independent Shellcode is Useful

Position Independent Code can be executed anywhere inside memory, without any issues. This means there are no hardcoded addresses and no calls to APIs such as GetProcAddress or LoadLibrary, not to mention a few other complications.

As a result, static analysis of the shellcode can take a while to fully understand as the shellcode is forced to manually lookup addresses that may not be known without debugging. Furthermore, plenty of malware utilizes hashing when looking up APIs, so a hash will be passed into a function that will hash each export of the DLL in question, until a matching pair is found. Whilst the hashing routine can be replicated so that the correct API is found without static analysis, there are many hashing algorithms out there, from CRC hashing up to custom hashing algorithms. This means there will be plenty of situations where you will have to update the script to include an additional algorithm, slowing down analysis further. So why not just load it into memory yourself and execute when a debugger is attached?

Well, you can. The guys at OALabs have created an extremely helpful tool called BlobRunner to do exactly that. However, rather than simply use a pre-existing tool, in this post we’re going to be focusing on writing our own, as it’s not too difficult to do so, and shellcode execution isn’t uncommon inside malware, so knowing the internals of how it works will help when it comes to recognizing it inside of a sample.

Overview of the ShellCode Analysis Tool’s Routine

So, the tool we’re writing needs to be able to read the shellcode from a file, allocate a region of memory large enough to accomodate the shellcode, write the shellcode into said region of memory, wait until a debugger has been attached, and then execute it. As it is for debugging and not behavioural analysis, we need to wait until a debugger has been attached, to prevent it running before attaching to it. The shellcode is also 64 bit, and as Visual C++ compiler does not support inline assembly for 64 bit applications, we’ll have to use CreateThread() to execute the shellcode, rather than using a jmp. Anyway, with that covered, let’s take a look at what the main() function will look like.

Writing the main() Function

This function is setup to accept two arguments: the filename, and the entry point offset.

In the case of the loader, without analyzing what executes it, the entry point seems to be at the offset 0x80. If we don’t pass in a second argument (the offset), the program will attempt to execute it from the offset 0x00. The offset is converted to an integer using strtol(), and then the function read_into_memory() is called, which, as the name suggests, reads the shellcode into process memory. This returns the base address of the shellcode, which is then passed into the function execution(), along with the entry point offset. As you can see, the layout is fairly simple – unlike loading an executable in process memory, we don’t need to map the sections of shellcode into memory, and can simply execute it once it has been copied into memory. With that said, let’s move on to the other functions that we need.

Writing the read_into_memory() Function

This function is responsible for loading the shellcode from a file into an allocated region of memory.

To do this, we first need the size of the shellcode, which we can get using fseek() and ftell(). This is then passed into VirtualAlloc(), along with PAGE_EXECUTE_READWRITE, allowing us to execute that region of memory without calling VirtualProtect(). The return address is put into the buffer variable, which is then passed into fread(), along with the handle to the open file. After the shellcode has been read into memory, we return the address in buffer back to the calling function, for use in the execution() function, which we will move onto now.

Writing the execution() Function

The execution() function is the most important part of the entire tool, as without it we’d still only have static shellcode.

To begin with, we add the entry point offset to the base address of the shellcode, so if the allocated region of memory was at 0x20000, the actual entry point would be 0x20080 for our LOWKEY reflective DLL loader. We then pass this into a call to CreateThread(), along with the value 0x4, which indicates we want to create the thread in a suspended state. This is done to prevent execution of the shellcode whatsoever, and we only resume the thread once a debugger is attached. This is done through a pretty simple while() loop that constantly calls IsDebuggerPresent() until one is detected. From there, the thread is resumed with a call to ResumeThread(), and then we enter another loop that will call WaitForSingleObject() every second to check if the thread has exited. If so, we close the handle and return from the function!

Compile Time!

That pretty much wraps up the tool, so let’s go ahead and compile it to test it out!

As you can see, everything runs smoothly and we’re able to see which API each hash represents, a lot faster than if we were writing a script to calculate it!

So, now we know how to read and execute shellcode in memory, recognizing it in malware should be fairly easy! In this case, the DEADEYE payload that executes the shellcode is packed and protected with VMProtect, making it very difficult to locate the function responsible for loading and executing the payload; however, the unpacked payloads can be found on Malpedia here for those that have an account.

---

Like this article? Follow us on LinkedIn, Twitter, YouTube or Facebook to see the content we post.

Read more about Cyber Security

• Zero2Hero Previous: How TrickBot Malware Hooking Engine Targets Windows 10 Browsers
• Ransomware Attacks: To Pay or Not To Pay? Let’s Discuss
• How AdLoad macOS Malware Continues to Adapt & Evade
• How TrickBot Hooking Engine Targets Windows 10 Browsers
• 7 Lessons Every CISO Can Learn From the ANU Cyber Attack
• Behind Enemy Lines | Looking into Ransomware as a Service (Project Root)
• APT and the Enterprise – FUD or Real Threat?

This year has seen an escalation in the number of ransomware attacks striking organizations, with both private and public sector agencies like local government and education firmly in the firing line of threats such as Ryuk and Robinhood ransomware. Often understaffed and under resourced, those responsible for delivering critical public services are at the sharp end of the dilemma: to pay or not to pay? It’s a quandary that has technical, ethical, legal, safety and, of course, financial dimensions. In this post, we explore the arguments both for and against. Our aim here is to describe the implications and rationale from both angles across a number of different considerations. 

Is Paying a Ransom to Stop a Ransomware Attack Illegal?

It may seem odd to some, but it isn’t illegal to pay a ransomware demand, even though the forced encryption of someone else’s data and demand for payment is itself a federal crime under at least the Computer Fraud and Abuse Act and the Electronic Communications Privacy Act, as well as many laws passed by State legislatures.

One might argue that the best way to solve the ransomware epidemic would be to make it illegal for organizations to pay. Criminals are naturally only interested in the pay off, and if that route to the payday was simply prescribed by law, it would very quickly lead both to companies exploring other options to deal with ransomware and, at least in theory, criminals moving toward some other endeavour with an easier payout.

In sum, one could argue that it is the ease with which criminals can be paid and the perceived anonymity of crypto payment that helps foster the continuance of the ransomware threat. 

The idea of outlawing the payment of ransomware demands might seem appealing at first, until you unpack the idea to think how it would work in practice. Publicly traded companies have a legal duty to shareholders; public service companies have legally binding commitments to serve their communities. A law that threatened to fine organizations, or perhaps imprison staff, would be hugely controversial in principle and likely difficult to enforce in practice, quite aside from the ethics of criminalizing the victim of a crime whose sole intent is to coerce that victim into making a payment.

Imagine a prosecutor attempting to convince a court that an employee – whose actions, say, restored a critical public service and saved the taxpayer millions of dollars after authorizing a five figure ransomware payment – should be jailed. How would that, in principle, be different from prosecuting a parent for securing the safety of a child by paying off kidnappers? It doesn’t look like an easy case to win, particularly when the employee (or organization) might cite legitimate extenuating circumstances such as preserving life or other legal obligations. 

Is It Ethical To Pay a Ransomware Demand?

If it’s not illegal to pay a ransomware demand, that still leaves open the separate question as to whether it’s ethical. There’s a couple of different angles that can be taken on this one. According to some interpretations of ethics, something is a “good” or “right” decision if it leads to an overall benefit for the community.

On this pragmatic conception of ethics, one might argue that paying a ransomware demand that restores some vital service or unlocks some irreplaceable data outweighs the ‘harm’ of rewarding and encouraging those engaged in criminal behavior. 

On the other hand, it could be argued that what is right, or ethical, is distinct from what is a pragmatic or merely expedient solution. Indulging in a fantastical thought-experiment for a moment, would we consider it ethical if a ransomware author demanded the life of a person, instead of money, to release data that would save the lives of thousands of others? Many would have a strong intuition that it would always be unethical to murder one innocent to protect the lives of others. And that suggests that what is “right” and “wrong” might not revolve around a simple calculation of perceived benefits. 

The real problem with the pragmatic approach, however, is that there’s no agreement on how to objectively calculate the outcome of different ethical choices. More often than not, the weight we give to different ethical choices merely reflect our bias for the choice that we are naturally predisposed to.

If pragmatism can’t help inform us of whether it’s ethical or not to pay ransomware, we could look to a different view of ethics that suggest we should consider actions as “right” or “wrong” insofar as they reflect the values of the kind of society we want to live in. This view is sometimes expressed more simply as a version of the “do unto others as you would have them do unto you” maxim. A more accurate way to parse it might be to ask: Do we want to live in a society where we think it’s right (ethical) to pay those who engage in criminal behavior? Is this a maxim that we would want to teach our children? Put in those terms, many would perhaps say not.

Is It Prudent To Pay a Ransomware Demand?

Even if we might have a clear idea of the legal situation and a particular take on our own ethical stance, the question of whether to pay or not to pay raises other issues. We are not entirely done with the pragmatics of the ransomware dilemma. We may still feel inclined to make an unethical choice in light of other, seemingly more pressing concerns. 

There is a real, tangible pressure on making a choice that could save your organization or your city millions of dollars, or which might spare weeks of downtime of a critical service.

Even if they believe it would be technically unethical to do so, sometimes, some people may judge that today’s hard reality just takes imminent precedence over loftier principles.

A case in point: recently, three Alabama hospitals paid a ransom in order to resume operations. The hospitals’ spokesperson said: 

“We worked with law enforcement and IT security experts to assess all options in executing the solution we felt was in the best interests of our patients and in alignment with our health system’s mission. This included purchasing a decryption key from the attackers to expedite system recovery and help ensure patient safety.”

This “hard reality” perspective is reflected in recent changes made to the FBI’s official guidance on ransomware threats. 

“…the FBI understands that when businesses are faced with an inability to function, executives will evaluate all options to protect their shareholders, employees, and customers.”

However, the possibility that the criminals will not hold up their side of the bargain must be factored into any decision about paying a ransomware demand. In some cases, decryption keys are not even available, and in others, the ransomware authors simply didn’t respond once they were paid. We saw this to some degree with WannaCry. In the flurry of the WannaCry outbreak, some victims paid and got keys, yet a large amount either never heard from the authors, or the key pairs between victim and server were unmatched, making per-user decryption impossible.

A further point to consider when weighing up the prudence of acquiescing to the demand for payment is how this will affect your organization beyond the present attack itself. Will paying harm your reputation or earn you plaudits? Will other – or even the same – attackers now see you as a soft target and look to strike you again? Will your financial support for the criminals’ enterprise lead to further attacks against other companies, or services, that you yourself rely on? In other words, will giving in to the ransomware demand produce worse long-term effects than the immediate ones it seems – if the attackers deliver on their promise – to solve? 

What Happens If I Don’t Pay A Ransom for Ransomware Attacks?

If you choose not to pay the ransom, then of course you are in the very same position the ransomware attacker first put you in by encrypting all your files in order to “twist your arm” into paying. 

Depending on what kind of ransomware infection you have, there is some possibility that a decryptor already exists for that strain; less likely, but not unheard of, is the possibility that an expert analysis team may discover a way to decrypt your files. A lot of ransomware is poorly written and poorly implemented, and it may be that all is not lost as it might at first seem.

The NoMoreRansom Project is the culmination of effort from global law enforcement agencies and private security industry partners. They host a large repository of stand-alone decryption tools which are constantly updated by industry partners.

This can be a very valuable resource when evaluating your course of action when facing a ransomware attack.

Also consider whether you have inventoried all possible backup and recovery options. Many look no further than the Maersk shipping story during the NotPetya attack to emphasize the importance of being able to rapidly restore one’s entire infrastructure from backup. The most eye-opening realization for Maersk (and indeed the entire industry) was that recovery depended on a happy accident: a sole unaffected domain controller did not become infected due to a local power outage where it was residing. Without that fortunate, coincidental event, it would have taken exponentially longer to rebuild their entire infrastructure after 50,000 devices and thousands of apps were destroyed all at once. 

Some hail this as a success story for backups, but shareholders and operators on board the thousands of ships worldwide are quick to remind us that this incident still cost the company well over a half billion dollars in the 6 months following the incident. While backup and restoration are indeed critical, they are by no means the primary basis for a strategy to address the threat of ransomware.

Finally, there is the worst case scenario, where you have no backups and no recovery software, and you will have to dig yourself out by re-building data, services and, perhaps your reputation, from the ground up. Transparency is undoubtedly your best bet in that kind of scenario. Admit to past mistakes, commit to learning those lessons, and stand tall on your ethical decision not to reward criminal behavior. 

What Happens If I Pay A Ransom for Ransomware Attacks?

There is perhaps more uncertainty in paying than there is in not paying. At least when you choose not to pay a ransomware demand, what happens next is in your hands. In handing over whatever sum the ransomware attacker demands, you remain in their clutches until or unless they provide a working decryption key. 

Before going down the road of paying, look for experienced advisors and consultants to help negotiate with the extortionists. Despite the often taunting ransomware notes, some ransomware groups will engage in negotiating terms if they think it will improve their chances of a payday.

Tactics like asking for ‘proof of life’ to decrypt a portion of the environment up front prior to payment, or to negotiate payment terms like 50% up front, and 50% only after the environment has been decrypted, can work with some groups, albeit not with others.

The vast majority of ransom is still being paid in bitcoin, which is not an anonymous or untraceable currency. If you do feel forced to pay, you can work with the FBI and share wallet and payment details. Global Law Enforcement is keen to track where the money moves.

And where do you go beyond that? Any sensible organization must realize the need for urgent investment in determining not only the vector of that attack but all other vulnerabilities, as well as rolling out a complete cybersecurity solution that can block and rollback ransomware attacks in future. While these are all costs that need to be borne regardless of whether you pay or do not pay, the temptation to take the quick, easy way out rather than working through the entire problem risks leaving holes that may be exploited in the future. Balance the need for speed of recovery against several risks:

1. Unknown back doors the attackers leave on systems
2. Partial data recovery (note some systems will not be recovered at all)
3. Zero recovery after payment (it is rare, but in some cases the decryption key provided is 100% useless, or worse, one is never sent)</span

Finally, note that some organizations that get hit successively by the same actors might have actually only been hit once, but encryption payloads may have been triggered in subsequent waves. Experience pays off tremendously in all of these scenarios, and ‘knowing thy enemy’ can make all the difference.

Conclusion

Pay or don’t pay, make sure you notify the proper law enforcement agency:

“Regardless of whether you or your organization have decided to pay the ransom, the FBI urges you to report ransomware incidents to law enforcement. Doing so provides investigators with the critical information they need to track ransomware attackers, hold them accountable under U.S. law, and prevent future attacks”.

At SentinelOne, we concur with the FBI that paying criminals for criminal activity is no way to put an end to criminal behavior. We understand the technical, ethical, and financial impacts that ransomware has on a business. It’s why we offer a ransomware guarantee with a trusted security solution that can both block known and unknown ransomware activity and also rollback your protected devices to a healthful state without recourse to backups or lengthy reinstallation. If you’d like to find out more, contact us today or request a free demo. 

---

Like this article? Follow us on LinkedIn, Twitter, YouTube or Facebook to see the content we post.

Read more about Cyber Security

• How AdLoad macOS Malware Continues to Adapt & Evade
• How TrickBot Hooking Engine Targets Windows 10 Browsers
• 7 Lessons Every CISO Can Learn From the ANU Cyber Attack
• Behind Enemy Lines | Looking into Ransomware as a Service (Project Root)
• APT and the Enterprise – FUD or Real Threat?
• Cyber Insurance Is No Substitute For Robust Cybersecurity Systems