Tag: information security

strela-functions-in-x64dbg
Unpacking StrelaStealer

Unpacking StrelaStealer

By |

I was digging into a new version of StrelaStealer the other day and I figured it may help someone if I wrote a quick blog post about it. This post is not an in-depth analysis of the packer. It’s just one method of quickly getting to the Strela payload.

Here is the sample I am analysing (SHA256:3b1b5dfb8c3605227c131e388379ad19d2ad6d240e69beb858d5ea50a7d506f9). Before proceeding, make sure to disable ASLR for the Strela executable by setting its DLL characteristics. Ok, let’s dig in.

A quick assessment of the executable in PEStudio reveals a few interesting things that I’ve highlighted. Note the TLS storage (callbacks). When the sample first executes, it makes two TLS callbacks as we’ll see in a bit.

Viewing the strings in PEStudio reveals several large strings with high-entropy data. These strings are part of the packed payload.

Let’s open the file in a disassembler to investigate further. I’ll be using IDA Pro for this analysis. If we inspect the “histogram” at the top of the IDA Pro window, we can see a large olive green segment which indicates data or code that IDA can’t make sense of. IDA Pro calls this data blob unk_14012A010:

As we saw in the strings earlier, this is likely the packed payload. I’ll rename this blob in IDA Pro to obfuscated_payload_blob. If we view the cross-references to this blob (ctrl+x in IDA), we can see several references:

Double-click one of these (I’ll select the 2nd one from the bottom), and you’ll see the following:

It seems our blob is being loaded into register rdx (lea rdx, obfuscated_payload_blob), and a few instructions later there is a call instruction to the function sub_140096BA0. Inspecting the code of this function and you may notice there are quite a few mathematical instructions (such as add and sub), as well as lots of mov instructions and a loop. This all indicates that this is highly likely a deobfuscation routine. Let’s rename this function deobfuscate_data. We won’t be analysing the unpacking code in depth, but if you wished to do so, you should rename the functions you analyse in a similar manner to better help you make sense of the code.

If we then get the cross-references to the deobfuscate_data function, we’ll see similar output to the cross-references for the obfuscated payload blob:

Inspect these more closely and you’ll see that the obfuscated blob is almost always being loaded into a register followed by a call to the deobfuscate_data function. This malware is unpacking its payload in multiple stages.

If we walk backwards to identify the “parent” function of all this decryption code, we should eventually spot a call to a qword address (0x14008978D) followed by a return instruction. This call looks like a good place to put a breakpoint as this is likely the end of the deobfuscation routine (given that there is also a return instruction that will take us back to the main code):

Let’s test this theory by launching the malware in a debugger (I’ll be using x64dbg). When you run the malware, you’ll hit two TLS callbacks (remember I mentioned those earlier?), like the below:

Just run past these. TLS callbacks are normally worth investigating in malware but in this case, we are just trying to unpack the payload here and will not investigate these further. You’ll eventually get to the PE entry point:

Put a breakpoint on the call instruction at 0x14008978D (using the command bp 14008978D) and run the malware. You should break on that call instruction:

If we step into this call instruction, we’ll get to the OEP (original entry point) of the payload! Inspect the Memory Map and you’ll see a new region of memory with protection class ERW (Execute-Read-Write):

This new memory segment (highlighted in gray in the image above) contains our payload. Don’t believe me? Dump it from memory (right-click -> Dump to file) and take a look at the strings. You should see something like the following:

You’ll spot some interesting data like an IP address, a user agent string, registry keys, and so on. If you don’t see any cleartext strings, you likely dumped the payload too early (before the malware deobfuscated all the data in this memory region), or too late, after the malware cleared its memory. Start reading this blog post again and try again ☺

Let’s open this dump file in IDA. After opening the file in IDA, be sure to rebase it (Edit -> Segments -> Rebase Program) to match it to the memory address in x64dbg:

After opening this dumped payload in IDA, you’ll see some inconsistencies, however:

See the problem? Some call instructions are not resolved to function names. However, in x64dbg, these functions are labeled properly:

This is because in x64dbg, these function names are being resolved to addresses in memory. In our IDA dump, they are not mapped properly.

Normally, what I would do next is try get my IDA database as close as possible to the code in x64dbg. We could spend more time analysing the unpacking code to identify where the malware is resolving its imports and this may help us get a better dump of the payload. Or, we could automate this by writing a python script to export all function names from x64dbg and import them into IDA. But why spend 1 hour automating something when we can spend 2 hours doing it manually? 🙂

We can manually fix this up IDA by cross-referencing each unknown function with the function name in x64dbg. For example, at address 0x1B1042 there is a call to InternetOpenA (according to our x64dbg output) and address at 0x1B107B is a call to InternetConnectA.

And now, we have something a lot more readable in IDA:

After you spend a bit of time manually renaming the unknown functions in your IDA database file, you should have some fairly readable code. Congrats! You unpacked Strela’s payload. Spend some time analysing the payload and see what you can learn about this sample.

Happy reversing! 🙂

— d4rksystem

hollowshunter-scanning
Extracting Malware from Memory with Hollows_Hunter

Extracting Malware from Memory with Hollows_Hunter

By |

Sometimes I come across a tool that makes me stop and think what I have been doing all my life life without it. This is how I feel about hollows_hunter. Hollows_hunter is essentially a tool for automatic extraction of evil objects and malicious code from memory. The tool is able to hunt for things such as process injection and replacement, process hollowing, DLL injection, malicious shellcode, and has a host of other uses. Hollows_hunter is based on pe-sieve, written by the same author, hasherezade.

Once a malicious object is found in memory (for example, malicious code in a running process), the tool will auto-magically extract the process from memory, and attempt to rebuild the headers and Import Address Table (IAT). In many cases, the tool is able to completely fix up the dumped file and rebuild the IAT so I could load it into IDA for further analysis. This is great because some of the malware samples I attempt to unpack and extract end up as warped shells of their once-glorious selves, un-analyzable in IDA. Hollows_hunter has saved me a lot of time recently, and seems to not get as much attention as it deserves. This drove me to write a quick tutorial post for it.

Let’s dive into hollows_hunter to see why it is so useful. Hollows_hunter gives a wealth of options that we can enable to help us better extract the data we are looking for:

hollows_hunter command line parameters.

For the following post, I’ll be using the sample with the SHA256 hash:

f8d281ee13bd7bde9b236a21966e7868836c452f1b2b10ad7c6dd1c395fbf149

You can find this file on VirusTotal or elsewhere online, in case you want to follow along.

First, I’m going to run the sample in a Windows 7 VM sandbox. Immediately after executing the sample, I run hollows_hunter:

Running hollows_hunter.

The command line options I used above are “hooks”, “shellc”, “data”, and “imp”.

  • “hooks” essentially tells hollows_hunter to look for malicious hooks and patches in memory.
  • “shellc” instructs the tool to look for shellcode (this sometimes produces false-positives, so handle with care.)
  • “data” tells hollows_hunter to inspect non-executable memory segments. This is sometimes important because malware may write data to non-executable areas of memory. This data may be useful strings, or it may be code that the malware will later try to execute.
  • Finally, “imp 1” instructs hollows_hunter to attempt an automated rebuild of the Import Address Table (IAT). This is super helpful, as we will see in a minute.

I ran hollows_hunter as Administrator so that it can scan system processes. I could have also ran the sample with the parameter “loop”. This parameter instructs hollows_hunter to continually run on repeat, constantly looking for malicious activity.

After running hollows_hunter, we can see that it scanned all running processes, found some malicious activity in memory, and dumped those memory regions:

hollows_hunter summary.

PID 2892 and 2944 are, in my case, false positives. I know that because hollows_hunter seems to always detect malicious activity in svchost.exe and wmpnetwk.exe when running as an Administration. Powershell.exe (PID 2520) is the PowerShell process I am running hollows_hunter in, so this is also a false positive.

EDIT: After messing around with the latest version of HollowsHunter (HollowsHunter Portable 0.2.4), I have confirmed that the issues with most of these false positives have been fixed . Obviously, there will always be false positives with any tool, but @hasherezade did a great job at identifying the common FP’s.

We can see that the malware sample has spawned two strange processes (WhatsAppWeb.exe, PID 2480/2088), and hollows_hunter was able to dump those processes from memory.

If we navigate to the hollows_hunter directory that we ran the tool from, we can see new directories that match the name of the PID that was dumped. In my case, the directories I am interested in are “process_2480” and “process_2088”. Let’s see what hollows_hunter dumped for us in the “process_2480” directory:

hollows_hunter dumped process.

Here we can see the dumped executable from memory, the list of imports that the sample is likely utilizing, and a report of the findings in JSON format. Now let’s inspect the “WhatsAppWeb.exe” here. I will open this file in IDA, my disassembler of choice.

Interesting strings in "WhatsAppWeb.exe".

Looking at the strings, we can immediately see some of the capabilities of this malware sample. This sample seems to be utilizing keylogging functionalities, and possibly attempting to disable anti-virus software.

"WhatsAppWeb.exe" imports.

If we look at the Imports section, we can see all of the imports are listed here. This means that the IAT was successfully rebuilt! Rebuilding the IAT is always a huge pain in my %@$, so hollows_hunter really helped here!

Because the sample has been unpacked, the IAT and PE structure have been rebuilt, and the strings appear readable, this malware should be easy to analyze further in IDA. Whoot.

Analyzing "WhatsAppWeb.exe" in IDA.

Well, that’s all for now. I hope you learned a bit about the usefulness of hollows_hunter. Thanks to hasherezade for putting in the work to create such a useful tool!

If you enjoyed this post, follow me on Twitter (@d4rksystem) 🙂
Hunting for SAP

Hunting for SAP

By |

SAP systems, especially Internet-facing ones, are often an overlooked attack surface for many organizations. SAP systems can contain several misconfigurations such as:

  • Outdated software
  • Sensitive information set to “Public”
  • Weak and/or default login credentials
  • Other good stuff

When analyzing the attack surface of your organization, or during a penetration test, it is important to look for these SAP systems. Generally, a web-facing SAP system will run on port 80, 443, 8080, or other common web ports. Internal SAP systems may use ports 3200-3399, 3600, 8000, 8100, or 50013-59914. To find these systems, simply run an Nmap scan such as the below. (DISCLAIMER: Only run the suggested tools on systems you have permission to scan!)

Example: “nmap -sV -p 80,443,3200-3299,3600,8000,8080,8100,50013-59914 “.

Be on the lookout for services that have “SAP” or “Netweaver” in the name.

Once some potential SAP systems have been identified, boot up Metasploit and look for the “sap_icm_urlscan” module. This module is very useful for “scanning” an SAP web server for directories that potentially should not be publicly accessible.

The above outputs show several SAP directories discovered. Some of these directories look pretty juicy (admin, soap_management, etc.)!

Now, open up a browser and take a look at a few of those directories. You may find some information that should not be Internet accessible. A few examples of what should not be on the Internet:

Some of the information that can be gathered from the above pages is:

  • System monitoring and status
  • Internal network hostnames and IP addresses
  • Detailed SAP software version information
  • SAP system logs
  • Host operating system versions and information

Attackers can use this information to launch other attacks on the SAP system, or potentially use this information to exploit a flaw in a connected system.

Well, that’s it for now. Hopefully this has motivated you to look into your Internet-facing SAP infrastructure. Good luck!

 

Subdomain Attack Surface Discovery – Part 2

Subdomain Attack Surface Discovery – Part 2

By |

Welcome to Part 2 of Subdomain Attack Surface Discovery! If you haven’t read Part 1, I would do that first… Otherwise confusion may follow. Assuming you are continuing after Part 1, let’s get back to our list of subdomains.

But first, a much-needed disclaimer.

DISCLAIMER: The tools and techniques in this post should only be run against hosts that you have permission to scan!

Ok, back to business.

In order to start taking a deeper look at the Internet attack surface to see what’s out there, we need to perform some light enumeration of the targets. My chosen tool for this is Nmap. Some have suggested the use of masscan for this instead of Nmap. I like masscan for extremely large quantities of hosts, but Nmap tends to work for me just fine for a “normal” number of hosts.

Generally, I only scan for the top 20 ports (nmap Top 20) to keep the scan quick and not to attract unwanted attention, but you can tailor this to fit your recon style.

Command: “nmap -vvv -sS –open –top-ports 20 –max-retries 2 -iL import_filename.txt -oA export_filename”

Let’s quickly dissect this nmap command. The “-vvv” puts Nmap in “very verbose” mode, meaning that there will be a lot of output and feedback. The “-sS” tells Nmap to run a more stealthy SYN scan. “–open” tells Nmap to only show open ports. “–top-ports 20” tells Nmap to only scan for the most common 20 ports – these are generally all we need for this initial reconnaissance. The “–max-retries 2” tells Nmap to stop probing a target port if a certain number of “retries” occurs. In a nutshell, this will speed up the scan. “-iL import_filename.tx” is the list of IP addresses and hostnames that you want to scan. From Part 1, this is the list of subdomains we discovered. Finally, “-oA export_filename” is the export file name. This will send the output of Nmap to 3 different file formats that can later be used.

Here is some of the information returned from the Nmap scan:

Here we see some standard web ports such as 80 and 443. These ports are hosting web services. Sometimes you will find more peculiar ports open, such as the below output:

Hosts such as this should be looked at more closely to ensure the open ports have a good reason for being open (e.g., providing services to the end-user).

Next, I run my favorite recon tool – Eyewitness. Eyewitness was written in Python and it simply takes screenshots of websites, and RDP and VNC login screens, and is a GREAT tool for quickly figuring out which hosts and subdomains look interesting and warrant further “review”. Let’s run an Eyewitness “scan”.

Since Eyewitness will navigate to all the subdomains and attempt to screenshot them, this tool can take quite a while to complete. Usually I will start an Eyewitness enumeration and go do something else for a few hours (or the day).

Command: “python EyeWitness.py –all-protocols -x nmap_file –timeout 15 -d output_file”

The Nmap input file should be the output of our Nmap scan from above. The output file name can be named anything.

Eyewitness reports output in HTML format, so you can open the result files in a web browser. After open the results in Firefox, I can see that various types of web pages were discovered. What we want to look for here are login portals, misconfigured web pages or applications, weird errors, or obvious potential issues such directory indexing and SQL errors.

Let’s take a look at our results. This is the type of stuff to look for:

Login portals, such as these:

Error Messages / Strange Output, such as these:

Misconfigured Web Pages, such as the below:

Or, Information about the backend infrastructure, such as the below:

These are only examples – Anything that looks out of the ordinary or peculiar should be inspected further. Usually this combination of tools and techniques can help you get a quick overview of the Internet attack surface of your organization, and can also be used in bughunting.

Please leave comments if anything is incorrect or if you have a better idea for the execution of these techniques!

I am currently working on a Python script that automates this tool chain and will write about it in the another post.. I know there are many tools and scripts out there that do similar recon, but I always find it safer to rely on a tool chain instead of a single tool that does it all – you never know when the developer stops supporting the “do-it-all” tool. With a tool chain, you can also include new tools and scripts (or take them out) in the chain any time you need!
Subdomain Attack Surface Discovery – Part 1

Subdomain Attack Surface Discovery – Part 1

By |

Analyzing your Internet attack surface is an important step in an overall security program for any organization. If you are a network defender or attacker and haven’t analyzed the Internet attack surface of your organization, you are doing security wrong. But that’s ok – I am here to give you a few simple tips on how to discover the subdomains your organization owns, and how to enumerate these subdomains and find potential attack surface that the bad guys can use to infiltrate the network.

Ok, let’s get started.

DISCLAIMER: The tools and techniques in this post should only be run against hosts that you have permission to scan!

Subdomain Discovery

There are many great tools for subdomain discovery, but for the purpose of simplicity, I chose to focus on a few of my favorites. These are:

The first step in discovering your Internet attack surface is identifying your organization’s subdomains. These pesky subdomains can pop up all over the place (shadow IT, developers bringing “test” and “development” systems online, etc.) and need to be wrangled in order to discover what’s out on the Internet Wild Wild West that attackers can target.

Sublist3r is a great Python script that performs various recon techniques to gather subdomains from the web. It utilizes search engine reconnaissance, various domain information sites like Netcraft, and threat research repositories such as Threatcrowd and Virustotal. Download it and try it out now:

Command: “sublist3r.py -d example.com -o sublist3r.out“

Make sure to replace “example.com” with your target domain.

Next, I bring in the big guns – subdomain brute-forcing. This technique will attempt to resolve a list of subdomains for the target domain. I generally use Subbrute.py as my go-to tool for this technique, but there are many other options. (Hint: Do a Google search and find some more tools!).

Command: “subbrute.py -v -s names_small.txt -o subbrute.out example.com”

Subbrute found a number of additional domains that you can now add to your ongoing subdomains list. Subbrute supports the ability for you to choose the list of subdomains to brute force – in my case, I used “names_small.txt”, which comes prepackaged with Subbrute. This is a smaller list that takes roughly 15 – 20 minutes to complete (your mileage may vary), but you can use a larger list as well, such as the default “names.txt”. The larger your list, the more subdomains you will potentially discover.

After subdomain brute forcing, I sometimes use various Recon-ng modules to catch the subdomains that may have slipped through the cracks. Recon-ng is an awesome suite of tools for performing all kinds of reconnaissance and OSINT. I will not be covering Recon-ng in depth here, but there are a lot of great resources on the net.

My favorite Recon-ng module is the Shodan module, which queries Shodan for target subdomains. This module will require a Shodan API key, which you can get for free when you register for a free Shodan account. Let’s use the Recon-ng CLI to run a Shodan search for other subdomains.

Command: “recon-cli -m recon/domains-hosts/shodan_hostname -o source=example.com -x”

As you can see, Recon-ng and Shodan picked up some additional subdomains! Recon-ng has a ton of additional modules so make sure to research this a bit more.

Now we need to output the list of subdomains from recon-ng into a useable format. The following command will export the results to a nice text file:

Command: “recon-cli -m reporting/list -o column=host -x”

Finally, I combine the output from Sublist3r, Subbrute, and Recon-ng into a single text file, ensure there are no duplicate subdomains, and I now have a nice list of subdomains!

And that wraps up Part 1 of Subdomain Attack Surface Discovery. In Part 2, I will discuss how to weed out the invalid subdomains, enumerate these subdomains, and find potential vulnerabilities to look at more closely. Stay tuned for Part 2!