There is so much emphasis in the cybersecurity market space on after-the-fact visibility into what bad things just happened. So much energy, time, money, strategy, and dialogue about it. The trouble is, it comes at a cost. For every moment we spend reacting, tracking down root cause analysis, examining forensics, peering at visibility, offsetting risks, running playbooks, and all the rest, we lose a moment to get ahead.

Some argue that prevention has failed us, and hence, we should retreat into reactive after-the-fact strategy and tooling. How many times must the bells of resilience and acceptable risk ring in our ears? Those concepts serve the business, and they are needed for us to message internally to other C-suite, directors, investors and customers alike. But these are not the concepts that should form the premise of our security strategy as CISOs and SECOPs.

Do we not realize the starkest of outcomes?  Even were we are able to have perfect visibility, perfect forensics, perfect root cause, perfect cyber insurance, and perfect human expertise and perfect cloud-based intelligence and visibility, we still would not have solved the one thing that will always overwhelm and outpace those controls?

Visibility After The Fact Means We Lost

Here we all are…on our heels, drowning in alert data, analysis paralysis, and burnout of even the greatest minds we have in our industry.

Here we are as an industry that continues to pour money and investments, time and strategy, into a massive security stack that strains SECOPs to the brink. We are digging ourselves into a hole that we may not be able to dig ourselves back out of if we don’t rapidly shift strategic focus.

Here we are thinking that hunting for threats already running in the environment is somehow proactive, empowering or worse, sexy.

If you are hunting around in an after-the-fact universe of events, you are not the Hunter…You are by definition, the Prey.
Here we are still chatting about breaches… because those are easy to tally the per-unit impact for, and subsequently offset via insurance. A 2013 story that we are still wrapping our heads around… as if tomorrow’s breaches will be the same low and slow TTP’s we fancy we might hunt for and get ahead of…by days? Weeks? Hours even?

Why would tomorrow’s breach need take any longer than today’s destructive worms?

Why would the same threat actors not employ both data theft and destruction into the same campaign? Oh wait, they already have been for the better part of 2019…

The Cloud Is No Place for Threat Hunting

Here we are, caught up in the Herculean move to the cloud. Yet, are we stopping to assess some of the most fundamentally basic weaknesses it will always have? For all of its virtues, the cloud will always be latent when it comes to addressing run-time threats on traditional IT endpoints. Even all the workloads we are moving to the cloud still have run-time security challenges that can outpace a cloud-to-cloud connection.

The cloud will always be a tethered affair. The cloud will always be on someone else’s steel, upon which there are up to a hundred sub operating systems, half of them Linux, and a large percentage of which have full access to the bus the OS is forced to entrust. The cloud will never be where your users are… the humans you are striving to protect. The cloud is homogeneously strong, and yet homogeneously weak. (See the latest OnApp discovery made by SkyLight!)  Most importantly, the cloud is a temptation… a temptation to build out intelligence platforms. And while it will always exceed in this capacity, it can never guarantee that the intelligence needed to make decisions and take actions faster than an adversary will be computed and delivered in time to actually make a difference in stopping today’s automated threats.

The key challenge for all security going forward can be reduced to this: can you make a high-enough confidence decision, or allow a high-enough confidence automated action, fast enough to matter, and without reliance upon a tether to the cloud?

By the year 2021, over 95% of all new vehicles will have autonomous automatic braking. Ask why this is so. Of course, the answer is because machines react faster than humans, never lose attention, never get tired. Now consider whether you would buy a car where this life-saving technology was being farmed out to a cloud server rather than being done locally on the machine. The point is we use the cloud where it makes sense to do so, and not where it doesn’t.

Why would anyone think it makes sense to try and beat malware anywhere else but on the machine right where the malware is located? The cloud has an underbelly exposed to many swords, chief among them is the time-penalty itself.

We Win On the Device

As this industry heads into 2021, let’s make sure we are lucid in this one critical regard.

We know that attacks have entropy… that they devolve into a fog of war, that they expand, that they cause exponential impact to an organization as every minute, every moment, goes by. 

And yet here we still are, heading into the year 2020, and we still haven’t solved the single most important challenge of our era; the process-level microsecond runtime universe the adversary has always had the upper hand in. They’ve been ahead of us there, and they’ve enjoyed it for far too long. The moment an unauthorized process completes tasks in memory… that very moment, is when we lose security control and are on our heels. Never mind zero days, call this moment zero, after which the pain begins.

What exasperates this even further is that this type of fast-moving threat is now found in both nation-state APT campaigns as well as commodity criminal/underground campaigns, making the sheer volume and diversity of the ‘speed” problem more profound than ever.

An Emotet-weaponized Word document is clicked, and in under three minutes, over 230 file events happen, 12 network connections to 9 malicious hosts are made, 46 new malicious processes spin up and 12 files are manipulated. And that is just on the patient zero host… before the same thing begins to play out host after host in the network, and before any secondary payloads or actions by a human attacker are commenced. This is a code on code battle being fought in the time domain of seconds and microseconds. And yet we see breach reports like 2019 IBM Cost of a Data Breach Report exclaim that the average time to identify a breach is 279 DAYS… a far cry from the 171 seconds (22s for Emotet and 149s for its payload) it takes Emotet to cause a severe impact. The same report offers hope, reminding us that hey, you can save $1.2M on average, if you simply contain the breach in under 200 days. Great…it will only cost you $2.7M at that point! 

All of this is orthogonal to the core challenge at hand: We need to get ahead of threats whether we are talking about ransomware or worm incidents that cost us $75B/year, or we are talking about after-the-fact breaches that cost us another $16B/year, or both. 

Let’s Remember This

The age of the slow-moving breach story has come and gone. Now, we must shift our strategies towards the current and future threat landscape, and realize that every minute we spend tooling for the after-the-fact past, is a minute lost in getting ahead of the adversary in ways that actually move the needle. In our quest to become merely “resilient”, we’ve exhausted the traditional means of risk offset, hindsight due-diligence and after-the-fact busy-ness. We are all collectively at the ultimate precipice, and it is time to leap off, and do so out of sheer necessity…because we cannot look forward and prepare, if we are constantly steeped in the past.

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

Read more about Cyber Security

• Zero2Hero (Free) Malware Course Pt 11: Here We GO: Crimeware & APT Journey
• Privilege Escalation | macOS Malware & The Path to Root Part 1
• Meet the Client Workshop | What Can We Learn From A Security Executive?
• What is Mimikatz? (And Why Is It So Dangerous?)
• Zero2Hero (Free) Malware Course Pt 10: Building A Custom Tool For Shellcode Analysis
• Ransomware Attacks: To Pay or Not To Pay? Let’s Discuss
• How AdLoad macOS Malware Continues to Adapt & Evade

The Zero2Hero course continues with Vitali Kremez exploring Golang malware through a comparison of Robbinhood ransomware and Zebrocy loader samples.

We continue to observe both crimeware and advanced persistent threat (APT) malware variants found in the wild and during active targeted campaigns that are compiled in more non-traditional languages including Golang (Go) and Delphi programming languages. 

The goal of this lesson is to investigate and obtain necessary malware analysis and valuable intelligence from two specific Golang compiled binaries that we increasingly see leveraged by various adversaries.

The compiled executables of both of these languages are to an extent a kind of “kryptonite” to malware analysts. Historically, malware analysis and reverse engineering practitioners have focused mainly on C compiled malware; therefore, the majority of custom and commercial malware analysis tools have aimed to assist with such C compiled binaries.

Golang executable malware introduces some challenges for the traditional anti-virus detection model, which has mainly focused on more traditional C-programmed malware. These kind of engines tend to have lower static detections for samples written in this language. As an additional benefit to attackers, Golang binaries are fast and efficient and have a high operational performance due to Golang’s concurrency features and garbage collection. 

Such features allow various malware operators to achieve the desired malware state of “fully undetectable” (FUD). On the general cybercrime underground, such FUD malware means the malware developer can market and sell their wares more effectively; as a result, they make more profit when they can demonstrate that their malware samples really are FUD.

In addition, various nation-state APT actors have also began adopting the Golang programming language for their payloads. This has been seen, for example, with the Russian state-sponsored group known as APT28, Sofacy, Fancy Bear, STRONTIUM, Pawn Storm, and Sednit. Such changes in threat actor methodology necessitate that we examine the internals of the Golang binaries closely in order to derive both more malware analysis and greater intelligence value.

Introduction to Golang Journey

Initially developed at Google, Golang is an open source programming language with extensive community support. Golang might be thought of as analogous to a healthy mix of the high-programming ease-of-use Pythonic syntactic “sugar”, with a dose of lower-level C++ compiled features. The standout feature of this language is concurrency with its “goroutines.”

When analyzed, some of the quirks of the compiled Golang executables include more complicated control flow graph (CFG) calls as well as garbage collection.

The positive side for analysts is that Golang binaries include a plethora of metadata and compilation artifacts. These can often be used to derive additional intelligence about the possible source path.

Golang Binaries: From RobbinHood Ransomware to APT28 Zebrocy

For the purpose of reviewing Golang binaries, we will focus on two prominent Golang malware variants:

1. Crimeware: RobbinHood Ransomware
2. APT: APT28 Zebrocy loader

Both of these binaries were linked to the major outbreaks that made media headlines. RobbinHood ransomware is widely known for holding hostage the City of Greenville and more recently disrupting major local government operations in the City of Baltimore. The APT28 Zebrocy loader is a malware tool widely deployed by the purported Russian-based intelligence agencies in targeting various government and political entities to deliver another malware of choice as needed.

Golang Malware Executables Share Common Features

1. The RobbinHood ransomware is a Golang executable consisting of 2.8 MB (2855424 bytes) with 2724 functions.
2. The APT28 Zebrocy loader is a Golang executable consisting of 4.5 MB (4508672 bytes) with 5459 functions.

We are assessing the similarities and differences of the two using the popular Diaphora binary diffing IDA plugin tool and CFF Explorer.

The Diaphora plugin showed the following results between the two Golang binaries:

• Best Matches: 1158 functions
• Partial Matches: 1091 functions
• Unreliable Matches: 109 functions
• Unmatched in APT28 Loader: 396 functions
• Unmatched in RobbinHood Ransomware: 3077 

It demonstrates that the separate Golang binaries share at least some similarities and best matches by either the same function hash, bytes hash, equal assembly and others. 

Another similarity between the two Golang samples are the sections as follows:

• .rdata
• .text
• .idata
• .symtab 

Both of the Golang binaries share the exact same import table with three static Windows dynamically linked libraries (DLL):

• winmm.dll
• ws2_32.dll
• kernel32.dll

Main Functions of Golang Malware

Leveraging IDA Golang Helpers tool, we assess and parse the Golang binaries trying to rename them. Then, based on the version, we try to add standard Go types and parse types by module data.

We make various attempts to parse the Golang section called “gopclntab”, which contains a function table routinely starting with the { FF FF FF FB 00 00 } bytes and containing the size of the table and offsets to the location of the first function, through which we can resolve the names of the functions.

The code from the helper functions demonstrates the parsing of the “gopclntab” table for module data and function renaming as well as version find.

The relevant parser code is as follows: 

 def getGopcln(self):
    gopcln_addr = self.getVal("gopcln")
    if gopcln_addr is None:
      gopcln_addr = Gopclntab.findGoPcLn()
      self.setVal("gopcln", gopcln_addr)
    return gopcln_addr

  def findModuleData(self):
    gopcln_addr = self.getGopcln()
    fmd = Firstmoduledata.findFirstModuleData(gopcln_addr, self.bt_obj)
    self.setVal("firstModData", fmd)
    return

  def renameFunctions(self):
    gopcln_tab = self.getGopcln()
    Gopclntab.rename(gopcln_tab, self.bt_obj)

The possible output reveals the oftentimes necessary structure definition and type assignment as follows, for example: 

According to moduleData struct it should be go1.8 or go1.9 or go1.10

Creating structure string
Creating structure slice
Creating structure __iface
Creating structure type
Creating structure arrayType
Creating structure chanType
Creating structure ptrType
Creating structure sliceType
Creating structure uncommonType
Creating structure method__
Creating structure structField
Creating structure structType
Creating structure imethod
Creating structure interfaceType
Creating structure funcType
Creating structure mapType
539d60 53ad6c 4df000
Processing: 4e9d00
PTR

1. The RobbinHood ransomware contains, for example, 2754 functions with only 26 main functions that affect the malware operation beyond static linking. Notably, Golang executables often preserve the original function names as developed by the developer.

The function names are descriptive of the ransomware encryption processes (for example, “main_RsaEncrypt”) and help navigate the malware analysis to locate the functions of interest. 

2. The APT28 Zebrocy loader contains, for example, 5459 functions with only 16 main functions that affect the malware operation beyond static linking. Again, we see that the Golang executable likewise preserves the original function names as developed by the developer.

One of the key interesting analysis insights is the APT28 Golang executable relies heavily on various Golang open source code templates from GitHub including iamacarpet/go_win64api (ProcessList, InstalledSoftwareList, ListLoggedInUsers,SessionDetails/FullUser), shirou_gopsutil (host_Info), and kbinani/screenshot (NumActiveDisplays, GetDisplayBounds, CaptureRect) for its processes as noted with the function parsed prefixes “github_com” and the source paths above. 

Golang Metadata Artifacts

1. The RobbinHood ransomware contained the original source “main.go” path data stored in “.rdata” section as follows:

• C:/Users/valery/go/src/oldboy/config.go
• C:/Users/valery/go/src/oldboy/functions.go
• C:/Users/valery/go/src/oldboy/main.go

2. The APT28 Zebrocy loader contained the original source “main.go” data stored in “.rdata” section as follows:

C:/!Project/C1/ProjectC1Dec/main.go

Conclusion

The Golang programming language has become a language of choice and adoption for some of the most notable crimeware and APT groups. Being able to recognize the primary features of Golang executables is increasingly important for malware analysis and reverse engineering. Some of the key elements of malware analysis of Golang executables involve locating “main” functions within the binary that affect the flow of the program as well as understanding the importance of “gopclntab”.

Additionally, developing good RE habits through coding in Golang assists with gaining malware analysis. Programming in Golang allows the analyst to understand and identify patterns, types, and module data that would assist in future during Golang malware analysis and reverse engineering. 

Referenced Malware Samples

APT28 Zebrocy UPX Packed Sample
SHA-256: 93680d34d798a22c618c96dec724517829ec3aad71215213a2dcb1eb190ff9fa

RobbinHood Ransomware Sample
SHA-256: 3bc78141ff3f742c5e942993adfbef39c2127f9682a303b5e786ed7f9a8d184b  

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

Read more about Cyber Security

• Zero2Hero Previous: Building A Custom Tool For Shellcode Analysis
• Privilege Escalation | macOS Malware & The Path to Root Part 1
• Meet the Client Workshop | What Can We Learn From A Security Executive?
• What is Mimikatz? (And Why Is It So Dangerous?)
• Zero2Hero (Free) Malware Course Pt 10: Building A Custom Tool For Shellcode Analysis
• Ransomware Attacks: To Pay or Not To Pay? Let’s Discuss
• How AdLoad macOS Malware Continues to Adapt & Evade