information security – Kyle Cucci's Cyber Ramblings

Deceiving the Deceivers: A Review of Deception Pro

By d4rksystem | January 13, 2026

TL;DR: This is my personal experience and a quick review of the Decepton Pro sandbox. Deception Pro is a specialized sandbox for long-duration analysis of malware and threat actor behavior. Overall, it is a promising product and fills a niche gap in the malware sandbox market.

One challenge facing malware analysts, reverse engineers, and threat intelligence analysts is understanding how malware behaves over a longer period of time. Capturing behaviour in a traditional sandbox for 3, 5, or even 20 minutes is possible, and analysts can also run samples in custom virtual machines or a baremetal analysis system to watch what they do. But there are still key challenges, such as:

It’s difficult to make the environment realistic enough to “convince” malware to continue execution, and even more difficult to capture follow-on actions such as commands issued to a bot or hands-on-keyboard events. Advanced malware and actors are looking for active directory environments or corporate networks, for example, and this can be difficult to simulate or maintain.
Even if an analyst can create a realistic enough environment to capture meaningful actor activity, it’s difficult to randomize the environment enough to not be fingerprinted. If an actor sees the same hostname, IP, or environment configurations over and over again, the analysis machine can easily be tracked and/or blocklisted.
Scalability, especially in baremetal setups, is always an issue. In my baremetal analysis workstation, I can’t detonate multiple malware samples at a time (while preventing cross-contamination), for example, and I can’t easily add snapshots for reverting after detonation.

Introducing Deception Pro

I was introduced to Deception Pro by a colleague who spoke highly of Paul Burbage’s team and the work they’ve done on other products (like Malbeacon). After reaching out to Paul, he was kind enough to offer me a demo account to help me understand the product and how it could fit into my threat research workflow. So without further ado, here’s my disclaimer:

Disclaimer: Paul and the Deception Pro team provided me with a free demo license to evaluate the product and see if it meets my needs. I’m not being paid for this review, and Paul and the team did not ask me to write one. This review is entirely my own doing.

In this post, I’ll be covering what Deception Pro is, how it can fit into a malware analysis and reverse engineering workflow, and some of its features.

Overview

Deception Pro is what I’d call a “long-term observability sandbox.” Essentially, it’s a malware sandbox designed to run malware for extended periods – several hours or even days – while also fooling the malware into thinking it’s running in a legitimate corporate environment. Long-term observation can be beneficial for a couple reasons, most notably:

Advanced malware often “sleeps” for long periods, waiting for an elapsed period of time before continuing execution or downloading additional payloads.
When the analyst wants to observe additional payload drops (for example, in a loader scenario) or hopes to catch hands-on-keyboard actions or follow-up objectives the attackers are trying to execute.

Pretend for a moment I’m a malware analyst (which I am, so there’s not much stretch of the imagination here). I detonated an unknown malware sample in my own virtual machines as well as several commercial sandboxes. Using publicly available commercial and free sandboxes, I determined that the malware belongs to a popular loader family. (Loaders are a class of malware that download additional payloads. They typically perform sandbox detection and other evasion techniques to ensure the target system is “clean” before executing the payload.)

I know this malware is a loader, but I want to understand what payload it ultimately drops. This behavior isn’t observable in the other sandboxes I’ve tried. I suspect that’s because the malware only communicates with its C2 and deploys its payload after a long period of time. I then submit the malware sample to Deception Pro.

When starting a new Deception Pro session, you’re greeted by an “Initiate Deception Operation” menu, which is a cool, spy-like way of saying, “start a new sandbox run.” James Bond would approve.

In this menu, we can choose from one of three randomly generated profiles, or “replicas,” for the user account in your sandbox – essentially, your “target.” This person works for one of the randomly generated company names and is even assigned a fancy title. Deception Pro then generates fake data to populate the sandbox environment, and this replica acts as a starting point or seed. I chose Mr. Markus Watts, a Supply Chain Data Scientist at the company Pixel Growth. Looks legit to me.

In the next menu, we’re prompted to upload our malware sample and choose additional details about the runtime environment. The two primary options are “Detonate Payload” and “Stage Environment Only.” Detonate Payload does what you’d expect and immediately detonates the payload once the environment spins up. Stage Environment Only allows the operator (you) to manually interact with the analysis environment. I haven’t experimented with this option.The final menu before the sandbox starts is the Settings menu. Here, we can select the detonation runtime (days, hours, minutes), the egress VPN country, some additional settings, and most importantly, the desktop wallpaper of the user environment. I’ll choose a relaxing beach wallpaper for Mr. Watts. He probably needs a nice beach vacation after all the work he does at Pixel Growth.

As Deception Pro is designed for long-term observation, it’s best to set a longer duration for the run. Typically, I set it to 5–8 hours, depending on my goals, and I’ve had good results with this.

After clicking the Submit button, the analysis environment is set up and populated with random dummy data, such as fake files, documents, and other artifacts, as well as an entire fake domain network. This creates a realistic and believable environment for the malware to detonate in.

Behavioral and Network Analysis

Fast-forward eight hours, and our analysis is complete. I’m excited to see what behaviors were captured. We’ll start with the Reports → Detections menu.

The Detections menu shows key events that occurred during malware detonation. There are a few interesting entries here, including suspicious usage of Invoke-WebRequest and other PowerShell activity. Clicking on these events provides additional details:

In the Network tab, we can view network connections such as HTTP and DNS traffic, along with related alerts:

In the screenshot above, you may notice several web requests as well as a network traffic alert for a “FormBook C2 Check-in.” This run was indeed a FormBook sample, and I was able to capture eight hours of FormBook traffic during this specific run.

I was also able to capture payload downloads in another run:

In this run (which was a loader), a 336 KB payload was delivered roughly five hours into execution. This highlights the fact that some loaders delay payload delivery for long periods of time.

The Artifacts menu allows analysts to download artifacts from the analysis, such as PCAPs, dropped files, and additional downloaded payloads:

Regarding PCAPs, there is currently no TLS decryption available, which is a drawback, so let’s touch on this now.

Conclusions

It’s important to remember that Deception Pro is a specialized sandbox. I don’t believe it needs to have all the features of a traditional malware sandbox, as that could cause it to become too generalized and lose its primary strength: creating believable target users and lightweight environments while enabling long-term observation of malware and follow-on actions. Here are some of the benefits I noticed when using Deception Pro, and some potential room for improvement:

Benefits

Generates operating environments that simulate very realistic enterprise networks. This can expose additional malware and threat actor activities that other sandboxes may miss, like pivoting or network reconnaissance.
Allows users to specify long detonation runtimes (hours to days) for observance of full attack chains (from initial infection to command and control, data exfiltation, and additional module and payload drops.
Captures key events, behaviors, and network traffic of interest for investigators and researchers
Allows interaction with the running sample and environment

Room for Improvement

PCAP decryption is currently missing (though this is reportedly coming)
Behavioural output is somewhat limited in its current state. This wasn’t too detrimental for my use case, as I primarily used Deception Pro as a long-term detonation environment rather than a full-fledged analysis sandbox. I rely on other tools and sandboxes for deeper analysis.
Currently no memory dump capabilities or configuration extraction

Also, note that the operating system environment is randomly generated, which limits customization (such as usernames, company names, etc.). This will rarely be an issue, but could matter when attempting to detonating highly targeted malware.

Overall though, I think the team behind Deception Pro is well on its way to creating a solid specialty sandbox, and I’m excited to see where it goes. Big thanks to Paul and the team for letting me spam their servers with malware.

Go Big or Go Home (and Other Terrible Go Puns): Tips for Analyzing GoLang Malware

By d4rksystem | July 14, 2025

A few days ago, Dr. Josh Stroschein invited me on his livesteam channel to talk about Golang malware. I wanted to get a quick blog post up before I forget everything we talked about. So, here is a summary of the key points we discussed in the livestream. You can also just watch the livestream here if you’re feeling lazy. Ok, let’s get on with it.

Go (or Golang) has gained some traction over the past few years, not just among developers, but increasingly among malware authors also looking for flexibility and portability. As reverse engineers and malware analysts, that means we need to get more comfortable navigating Go binaries, understanding how they’re structured, and knowing what makes them different from traditional malware written in C, C++, or Delphi (vomit face).

What Is Go, and Why Does It Matter?

Go is a statically typed, compiled programming language developed by Google. It’s designed to be simple, fast to compile, and efficient. Some of the things Go does well:

Cross-compilation: Go makes it easy to build binaries for different OS’s and architectures.
Static linking: Most Go binaries are self-contained, meaning no external dependencies.
Built-in concurrency: Go’s goroutines make it easy to write efficient networked applications.

From a developer’s perspective, it’s efficient and practical. From a malware analyst’s perspective, it presents some interesting challenges.

Why Use Go for Malware?

Go offers several advantages that make it appealing to malware authors:

Portability: Malware authors can compile a single codebase for multiple platforms (Windows, Linux, macOS, ARM, etc.).
Self-contained binaries: Go binaries include everything they need to run, which results in some seriously HUGE executable file sizes, but more on that later.
Less tooling: Traditional reverse engineering tools aren’t as well-optimized for Go binaries, especially compared to C/C++ (but this is changing quickly).
Rapid development: Go is relatively easy to write and maintain, which makes it efficient for malware development.
Evasion by obscurity: Go binaries look different from typical malware, especially in static analysis, which may help them avoid basic detections (this is also changing rapidly).

Common Pitfalls in Analyzing Go Malware

1. Large Binary Sizes

Even a simple Go program can compile into a binary tens of megabytes in size, which you’ll see in a moment. This is due to static linking of the Go runtime and standard libraries. For analysts, this means more to sift through as it’s often not immediately obvious where the actual malicious code begins or ends.

2. Excess of Legitimate Code

Go’s standard library is extensive, and malware often makes use of common packages like net, os, crypto, and io. Most of the code in the binary is likely benign. The challenge is identifying the small percentage of custom or malicious logic within all the legitimate functionality. Your classic needle-in-a-pile-of-needles problem.

3. Obfuscation (Garble and Others)

Go malware is increasingly using obfuscation tools like Garble, which strip or randomize symbol names, re-order packages, and break common static analysis workflows. These techniques don’t necessarily make the malware more sophisticated, but they do add complexity to the reversing process.

Other common obfuscation techniques may include:

Encrypted or encoded strings
Control flow obfuscation
Packing or compression

Let’s analyze a very basic Go binary. The best way to do this is to write our own code.

Analyzing a Basic Go Program

Go code is fairly straightforward and simple to write. Here is literally the most basic Go application you can write, printing our favorite “Hello World” (in this case, “Hello Earth”) string:

When compiled (using the go build command), the binary is a fairly large executable (2MB+). Since Go ships a lot of library code into each compiled executable, even this simple Hello World binary is substantial.

Let’s open this up in IDA, my dissasembler of choice for Golang. Newer versions of IDA (I think version 8+) are good at identifying Go standard library code. IDA nicely groups these libraries in “folders”, as you can see in the screenshot below:

Each of these folders represent a library. For example, “internal”, “runtime”, and “math” are all libraries being imported into this Go program. IDA is able to recognize these libraries and functions and name them appropriately. If your dissasembler is not designed for Golang use, you’ll see a bunch of generic names for these functions which makes analysis of Go binaries a lot more difficult. One tool (GoReSim) can help identify these functions, and the output of this tool can then be re-imported into some disassemblers like Ghidra.

Most of the time in un-obuscated Golang binaries, the main functionality of the program will reside in the function main.main or, main_main), which IDA identified for us:

Tip: Whenever I’m analyzing a Go binary, I first always look for main_main or other functions that contain the name “main_*”.

Inside main_main we can see our Hello World code. You may be able to spot the “Hello Earth!” string in the code below:

This “Hello Earth!” string also contains a bunch of other junk. These are also strings in the binary. One challenge when analyzing Golang code is that strings are not null-terminated like they are in C programs. Each string is actually a structure that contains the string itself and an integer representing the string’s length. I provided some terrible pseudocode for visualization of this:

struct string ( value = "Hello Earth!" length = 12 )

In this case, IDA didn’t know that “Hello Earth!” is a separate string from “152587…” and the others. This is one thing you’ll need to take into account when analyzing Golang.

Ok, Hello World apps are cool and all, but let’s take it up a notch. Many malware binaries written in Go will be obfuscated. Garble is one such obfuscator. Garble… well… garbles the metadata of the Go binary. It does this by stripping symbols, function names, module and build information, and other metadata from the binary during compile-time.

If we open the same Hello World binary in IDA, but “Garbled” during compilation, it looks a lot different:

All our nice, beautiful Golang function names have been replaced with ugly, generic IDA function names (“sub_xxxxxx”). So how do we find our main function code now? We can’t – Golang won. Time to pack up and Go home.

No, just kidding. We just have to work a bit harder. I’ve found that Golang requires several critical libraries to correctly function, and one of those is the “runtime” library, which contains a lot of Go’s runtime code. Oftentimes, the runtime library names are not obfuscated, like in this case of my binary compiled with Garble (Note: I think Garble can also strip the module names from “runtime” as well, but I didn’t test this. In any case, the “runtime” module names are often not obfuscated). This means we can find cross-references to runtime functions in the code, and trace those back to the program’s main function! Let’s try this.

If we search the function list in IDA for “runtime”, we get the following:

One common runtime function is runtime_unlockOSThread. We can double-click on this function and select CTRL+X to see cross-references to it. Taking a look through all the cross-referenced functions will lead you to a block of code that looks like this:

When you spot functionality that contains a lot of “runtime” functions, you may be near the location of the program’s main code. In this case, our main code is not far away, in sub_49A9E0. You may be wondering: “Kyle, how are you so smart that you found that so fast?”. Well, intelligence aside, it was a lot of hunting around the code. No crazy tricks here.

And here we have our main code at sub_49A9E0:

Tip: Garble and other obfuscators can also obfuscate strings, not just the function names. I used the default Garble settings for this binary. The analysis methodology is the same, however.

Additional Resources

A few more resources on Golang I find extremely helpful:

Ivan Kwiatkowski’s YouTube videos on GoLang analysis.
Josh Stroschein’s PluralSight course on GoLang malware analysis. In this course, Josh covers the OT malware FrostyGoop.

Key Takeaways

Go malware is becoming more common, and it’s likely here to stay. While it presents some unique challenges, many of the same principles from other forms of reverse engineering still apply. You just need to adjust your approach and tools.

5 Tips for Reversing Go Malware

Start with main.main (main_main) – This is (nearly) always the entry point for a Go binary and can give you a foothold into the rest of the logic.
Use the right tooling – IDA, Ghidra with GoReSym (other disassemblers probably worked, but I haven’t tested them), and de-obfuscators like the appropriately named UnGarbler.
Ignore the noise – Skip most of the standard library code unless it’s directly involved in malicious behavior.
Look for key APIs – Even with obfuscation, patterns like “net.Dial”, “os/exec”, or “http.Get” can help narrow down suspicious areas.
Combine static and dynamic analysis – Especially with obfuscated binaries, dynamic tracing or debugging can be the fastest way to understand real behavior. Ivan Kwiatkowski has some great tips on debugging Golang in this video.

Unpacking StrelaStealer

By d4rksystem | March 14, 2024

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 2^nd 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

Extracting Malware from Memory with Hollows_Hunter

By d4rksystem | January 13, 2020

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:

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:

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:

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:

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.

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.

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

By d4rksystem | February 2, 2018

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

By d4rksystem | September 26, 2017

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:

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

By d4rksystem | August 8, 2017

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:

Sublist3r – https://github.com/aboul3la/Sublist3r
Subbrute – https://github.com/TheRook/subbrute
Recon-ng – https://bitbucket.org/LaNMaSteR53/recon-ng

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!

Tag: information security