Trustwave SpiderLabs Uncovers Ov3r_Stealer Malware Spread via Phishing and Facebook Advertising. Learn More

Trustwave SpiderLabs Uncovers Ov3r_Stealer Malware Spread via Phishing and Facebook Advertising. Learn More

Managed Detection & Response

Eliminate active threats with 24/7 threat detection, investigation, and response.

Co-Managed SOC (SIEM)

Maximize your SIEM investment, stop alert fatigue, and enhance your team with hybrid security operations support.

Advisory & Diagnostics

Advance your cybersecurity program and get expert guidance where you need it most.

Penetration Testing

Test your physical locations and IT infrastructure to shore up weaknesses before exploitation.

Database Security

Prevent unauthorized access and exceed compliance requirements.

Email Security

Stop email threats others miss and secure your organization against the #1 ransomware attack vector.

Digital Forensics & Incident Response

Prepare for the inevitable with 24/7 global breach response in-region and available on-site.

Firewall & Technology Management

Mitigate risk of a cyberattack with 24/7 incident and health monitoring and the latest threat intelligence.

Microsoft Exchange Server Attacks
Stay protected against emerging threats
Rapidly Secure New Environments
Security for rapid response situations
Securing the Cloud
Safely navigate and stay protected
Securing the IoT Landscape
Test, monitor and secure network objects
Why Trustwave
About Us
Awards and Accolades
Trustwave SpiderLabs Team
Trustwave Fusion Security Operations Platform
Trustwave Security Colony
Technology Alliance Partners
Key alliances who align and support our ecosystem of security offerings
Trustwave PartnerOne Program
Join forces with Trustwave to protect against the most advance cybersecurity threats
SpiderLabs Blog

To Obfuscate, or not to Obfuscate


Malware's goal is to bypass computer defenses, infect a target, and often remain on the system as long as possible. A variety of techniques are used to accomplish these goals. Deciding which of these techniques to use depends on a mix between the skill of the author and the defenses of the intended victim. One of the most widely used tactics in malware is obfuscation. Obfuscation comes in the form of packers, crypters, and string manipulation and when used effectively, it can greatly increase the time and resources needed to analyze a sample.

Trustwave encounters a number of samples that vary in complexity. Typically, the easiest of these are written in scripting languages and compiled with the runtime into an executable. There are many programs and scripts written that can retrieve the original source code from the binary, which, often just leaves reading the source to discover all the juicy bits. Recently, the Spiderlabs Malware Research team encountered a suspicious binary during an investigation that challenged this assumption that all compiled scripts are easy to analyze. The sample was an AutoIT script compiled into a binary that employs string obfuscation, anti-analysis, and anti-security techniques to decode shellcode and a binary obfuscated with ConfuserEx. The shellcode injects the final payload, which is a "Remote Administration Tool" called LuminosityLink. What is interesting about this case is the combination of several fairly simple techniques in a scripting language that greatly increase the difficulty in retrieving the final payload.

The "Quick" Win

It is fairly obvious from the first look at this sample that it is an AutoIT script compiled into a binary. Both the icon and the AutoIT version information identify the sample as such. After extracting the original script from the binary, it was obvious that this script was much more sophisticated then what we typically encouter in scripted malware. The script turned out to be 1400+ lines of heavily obfuscated code and used three different obfuscation techniques. Here are the following techniques that we will highlight in this blog:

  1. String obfuscation
  2. Flow of execution obfuscation
  3. Shellcode/Binary obfuscation

The final payload was also obfuscated with a commerical grade product called ConfuserEx, which is a topic for another blog. We will take a look at the three techniques individually, but it is important to note that these techniques are used in tandem, making the other techniques more effective.

String Theory

This script uses a very simple method to obfuscate strings. Really, the obfuscation occurs when the script is written. A function is used to return the strings to their intended content during execution. The decoding function accepts an integer as an argument, subtracts 2 from it, and returns the value. The return value is passed to the Chr() function, which returns the ASCII representation of the integer. That's it! Here is what the decoding function looks like:

Func _2pdqycz2($string)
Return $string - 2

and here is a call to the function:


The 67 becomes a 65 after the decoding function, which the Chr function tells us is the ASCII character 'A'. Simple and easy… except there are over 6,000 calls to this function and many of the strings are built after looping through hundreds of lines of code. This won't do. What better way to circumvent their attempts to make analysis difficult then by writing our own script to deobfuscate the code into something more readable. The answer was this regex:

searchStr = 'Chr\(_2pdqycz2\(\d{1,3}\)\)[^\S\r\n]?\&*[^\S\r\n]?'

I can feel you judging me, but luckily this is a blog about getting answers and not writing solid regex expressions! Essentially, the python script reads each line of the script and looks for matches to the regex. The matches that are found are parsed, and the corresponding decoded character is written in place of the function calls. After running the decoding script, the result changes this code:

Global $_v32qyr038 = Chr(_2pdqycz2(104)) & Chr(_2pdqycz2(107)) & Chr(_2pdqycz2(110)) & Chr(_2pdqycz2(103)) & Chr(_2pdqycz2(112)) & Chr(_2pdqycz2(99)) & Chr(_2pdqycz2(111)) & Chr(_2pdqycz2(103)) & Chr(_2pdqycz2(48)) & Chr(_2pdqycz2(103)) & Chr(_2pdqycz2(122)) & Chr(_2pdqycz2(103))

Into this:

Global $_v32qyr038 = "filename.exe"

Justin Case

The easiest thing about analyzing source code is you get to see exactly what is going on. To those that program, it is like reading a book. Choose your own adventures, anyone? The author of this script decided to use case statements wrapped in while loops to obfuscate the order of execution. A global variable is set with a large number and the case statement determines what code is executed before resetting the global variable to another large number. Inside some of these loops lives code that checks for a sandbox environment, security tools, and sleeps for long periods of time. Some of the case statements don't contain code at all and instead simply contain the next jump in the case statement. The case statements contained several hundred lines of code making analysis solutions such as adding print statements to the script or deleting code a dicey prospect at best.

Luckily, AutoIT provides a debugger for their language.


The decoding script left the output with a lot of syntax errors that would have required too much manual fixing to be worthwhile. However, it did make it obvious where the anti-security and anti-analysis checks were. A couple of code deletions and a breakpoint later and we made it to the payload stage of the script.

Bit by Bit

The final stage of this script is really a combination of the first two obfuscation stages, but there is a reason it is listed as the third stage. If anything fails or the malware detects it as an analyst's environment, it is still unknown what the purpose of the malware is. Even running the string decoding script doesn't give much more than a hint that some type of injection is occurring.

The script is now ready to decode the shellcode that will perform the final step. The same string decoding function is used here, except the characters that are deobfuscated are only hexadecimals. Case statements wrapped in while loops continue to obfuscate the control flow while kernel DLLs are loaded and system API's are called. Like many other families of malware, the shellcode allocates memory and maps the payload into the space. A target executable is launched in a suspended state, the memory is removed, the new malicious code is inserted, and the execution begins. This technique is known as Process Hollowing. Once the new code is executing, the script will terminate.


This malware did not perform any groundbreaking new techniques that will forever change the face of security as we know it. It was produced by combining several effective yet simple techniques, an easy to use scripting language, and compiled into an easy to deliver executable. The time and effort required to get the final payload of the malware was significantly higher than what is typically required when access to the source code is available. Malicious scripts compiled into binaries are often on the low end of the sophistication spectrum, but they can still make effective use of known techniques to bypass defenses and perform the task they were set out to do.

Latest SpiderLabs Blogs

Welcome to Adventures in Cybersecurity: The Defender Series

I’m happy to say I’m done chasing Microsoft certifications (AZ104/AZ500/SC100), and as a result, I’ve had the time to put some effort into a blog series that hopefully will entertain and inform you...

Read More

Trustwave SpiderLabs: Insights and Solutions to Defend Educational Institutions Against Cyber Threats

Security teams responsible for defending educational institutions at higher education and primary school levels often find themselves facing harsh lessons from threat actors who exploit the numerous...

Read More

Breakdown of Tycoon Phishing-as-a-Service System

Just weeks after Trustwave SpiderLabs reported on the Greatness phishing-as-a-service (PaaS) framework, SpiderLabs’ Email Security team is tracking another PaaS called Tycoon Group.

Read More