Showing posts with label malware analysis. Show all posts
Showing posts with label malware analysis. Show all posts

Friday, July 07, 2017

Toolsmith #126: Adversary hunting with SOF-ELK

As we celebrate Independence Day, I'm reminded that we honor what was, of course, an armed conflict. Today's realities, when we think about conflict, are quite different than the days of lining troops up across the field from each other, loading muskets, and flinging balls of lead into the fray.
We live in a world of asymmetrical battles, often conflicts that aren't always obvious in purpose and intent, and likely fought on multiple fronts. For one of the best reads on the topic, take the well spent time to read TJ O'Connor's The Jester Dynamic: A Lesson in Asymmetric Unmanaged Cyber Warfare. If you're reading this post, it's highly likely that your front is that of 1s and 0s, either as a blue team defender, or as a red team attacker. I live in this world every day of my life as a blue teamer at Microsoft, and as a joint forces cyber network operator. We are faced, each day, with overwhelming, excessive amounts of data, of varying quality, where the answers to questions are likely hidden, but available to those who can dig deeply enough.
New platforms continue to emerge to help us in this cause. At Microsoft we have a variety of platforms that make the process easier for us, but no less arduous, to dig through the data, and the commercial sector continues to expand its offerings. For those with limited budgets and resources, but a strong drive for discovery, that have been outstanding offerings as well. Security Onion has been forefront for years, and is under constant development and improvement in the care of Doug Burks.
Another emerging platform, to be discussed here, is SOF-ELK, part of the SANS Forensics community, created by SANS FOR572, Advanced Network Forensics and Analysis author and instructor Phil Hagen. Count SOF-ELK in the NFAT family for sure, a strong player in the Network Forensic Analysis Tool category.
SOF-ELK has a great README, don't be that person, read it. It's everything you need to get started, in one place. What!? :-)
Better yet, you can download a fully realized VM with almost no configuration requirements, so you can hit the ground running. I ran my SOF-ELK instance with VMWare Workstation 12 Pro and no issues other than needing to temporarily disable Device Guard and Credential Guard on Windows 10.
SOF-ELK offers some good test data to get you started with right out of the gate, in /home/elk_user/exercise_source_logs, including Syslog from a firewall, router, converted Windows events, a Squid proxy, and a server named muse. You can drop these on your SOF-ELK server in the /logstash/syslog/ ingestion point for syslog-formatted data. Additionally, utilize /logstash/nfarch/ for archived NetFlow output, /logstash/httpd/ for Apache logs, /logstash/passivedns/ for logs from the passivedns utility, /logstash/plaso/ for log2timeline, and  /logstash/bro/ for, yeah, you guessed it.
I mixed things up a bit and added my own Apache logs for the month of May to /logstash/httpd/. The muse log set in the exercise offering also included a DNS log (named_log), for grins I threw that in the /logstash/syslog/ as well just to see how it would play.
Run down a few data rabbit holes with me, I swear I can linger for hours on end once I latch on to something to chase. We'll begin with a couple of highlights from my Apache logs. The SOF-ELK VM comes with three pre-configured dashboards including Syslog, NetFlow, and HTTPD. You can learn more in the start page for the SOF-ELK UI, my instance is http://192.168.50.110:5601/app/kibana. There are three panels, or blocks, for each dashboard's details, at the bottom of the UI. I drilled through to the HTTPD Log Dashboard for this experiment, and immediately reset the time period for analysis (click the time marker in the upper right hand part of the UI). It defaults to the last 15 minutes, if you're reviewing older data it won't show until you adjust to match your time stamps. My data is from the month of May so I selected an absolute window from the beginning of May to its end. You can also select quick or relative time options, it's great to get comfortable here quickly and early. The resulting opening visualizations for me made me very happy, as seen in Figure 1.
Figure 1: HTTPD Log Dashboard
Nice! An event count summary, source ASNs by count (you can immediately see where I scanned myself from work), a fantastic Access Source map, a records graph by HTTP verbs, and one by response codes.
The beauty of these SOF-ELK dashboards is that they're immediately interactive and allow you to drill right in to interesting data points. The holisticinfosec.org website is intentionally flat and includes no active PHP or dynamic content. As a result, my favorite response code as a web application security tester, the 500 error, is notably missing. But, in both the timeline graphs we note a big traffic spike on 8 MAY 2017, which correlates nicely with my above mention scan from work, as noted in the ASN hit count, and seen here in Figure 2.

Figure 2: Traffic spike from scan
This visualizes well but isn't really all that interesting or uncommon, particularly given that I know I personally ran the scan, and scans from the Intarwebs are dime a dozen. What did jump out for me though, as seen back in Figure 1, was the presence of four PUT requests. That's usually a "bad thing" where some @$$h@t is trying to drop something on my server. Let's drill in a bit, shall we? After clicking the graph line with the four PUT requests, I quickly learned that two requests came from 204.12.194.234 AS32097: WholeSale Internet in Kansas City, MO and two came from 119.23.233.9 AS37963: Hangzhou Alibaba Advertising in Hangzhou, China. This is well represented in the HTTPD Access Source panel map (Figure 3).

Figure 3: Access Source
The PUT request from each included a txt file attempt, specifically dbhvf99151.txt and htjfx99555.txt, both were rejected, redirected (302), and sent to my landing page (200).
Research on the IPs found that 119.23.233.9 was on the "real time suspected malware list as detected by InterServer's intrusion systems" as seen 22 MAY, and 204.12.194.234 was found twice in the AbuseIPDB, flagged on 18 MAY 2017 for Cknife Webshell Detected. Now we're talking. It's common to attempt a remote file include attack or a PUT, with what is a web shell. I opened up SOF-ELK on that IP address and found eight total hits in my logs, all looking for common PHP opportunities with the likes of GET and POST for /plus/mytag_js.php, noted in PHP injection attack attempts.
SOF-ELK made it incredibly easy to hunt down these details, as seen in Figure 4 from the HTTPD Discovery panel.
Figure 4: Discovery
That's a groovy little hunting trip through HTTPD logs, but how about a bit of Syslog? I spotted I likely oddity that could be correlated across a number of the exercise logs, we'll see if the correlation is real. You'll notice tabs at the top of your SOF-ELK UI, we'll use Discover for this experiment. I started from the Syslog Dashboard with my time range set broadly on the last two months. 7606 records presented themselves, sliced neatly by hosts and programs, as seen in Figure 5.

Figure 5: Syslog Dashboard
Squid proxy logs showed the predominance of host entries (6778 or 57.95% of 11,696 to be specific), so I started there. Don' laugh, but I'll often do keyword queries just to see what comes up, sometimes you land a pointer to a good rabbit hole. Within the body of 6778 proxy events, I searched malware. Two hits came back for GET request via a JS redirector to bleepingcomputer.com for your basic how-to based on "random websites opening in Chrome". Ruh-roh.
Figure 6: Malware keyword
More importantly, we have an IP address to pivot on: 10.3.59.53. A search of that IP across the same 6778 Squid logs yielded 3896 entries specific to this IP, and lots to be curious about:
  • datingukrainewomen.com 
  • anastasiadate.com
  • YouTube videos for hair loss
  • crowdscience.com for "random pop-ups driving me nuts"
Do I need to build this user profile out for you, or are you with me? Proxy logs tell us so much, and are deeply worthy of your blue team efforts to collect and review.
I jumped over to the named_log from the muse host to see what else might reveal itself. Here's where I jumped to Discover, the Splunk-like query functionality inherent to SOF-ELK (and ELK implemetations). I did reductive query to see what other oddities might surface: 10.3.59.53 AND dns_query: (*.co.uk OR *.de OR *.eu OR *.info OR *.cc OR *.online OR *.website). I used these TLDs based on the premise that bots using Domain Generation Algorithms (DGA) will often use the TLDs. See The DGA of PadCrypt to learn more, as well as ISC Diary handler John Bambanek's OSINT logic. The query results were quite satisfying, 29 hits, including a number of clearly randomly generated domains. Those that were most interesting all included the .cc TLD, so I zoomed in further. Down to five hits with 10.3.59.53 AND dns_query: *.cc, as seen in Figure 7.
Figure 7:. CC TLD hits
Oh man, not good. I had a hunch now, and went back to the proxy logs with 10.3.59.53 AND squid_request:*.exe. And there you have it, ladies and gentlemen, hunch rewarded (Figure 8).

Figure 8: taxdocs.exe
It taxdocs.exe isn't malware, I'm a monkey's uncle. Unfortunately, I could find no online references to these .cc domains or the .exe sample or URL, but you get the point. Given that it's exercise data, Phil may have generated it to entice to dig deeper.
When we think about the IOC patterns for Petya, a hunt like this is pretty revealing. Petya's "initial infection appears to involve a software supply-chain threat involving the Ukrainian company M.E.Doc, which develops tax accounting software, MEDoc". This is not Petya (as far as I know) specifically but we see pattern similarities for sure, one can learn a great deal about the sheep and the wolves. Be the sheepdog!
Few tools better in the free and open source arsenal to help you train and enhance your inner digital sheepdog than SOF-ELK. "I'm a sheepdog. I live to protect the flock and confront the wolf." ~ LTC Dave Grossman, from On Combat.

Believe it or not, there's a ton more you can do with SOF-ELK, consider this a primer and a motivator.
I LOVE SOF-ELK. Phil, well done, thank you. Readers rejoice, this is really one of my favorites for toolsmith, hands down, out of the now 126 unique tools discussed over more than ten years. Download the VM, and get to work herding. :-)
Cheers...until next time.

Saturday, August 01, 2015

toolsmith: There Is No Privacy - Hook Analyser vs. Hacking Team



Prerequisites
Hook Analyser
Windows OS

Introduction
As we explore privacy in this month’s ISSA Journal, timing couldn’t be better. Since last we convened, the Hacking Team breach has informed us all that privacy literally is for sale. Hacking Team’s primary product is Remote Control System (RCS), “a solution designed to evade encryption by means of an agent directly installed on the device to monitor. Evidence collection on monitored devices is stealth and transmission of collected data from the device to the RCS server is encrypted and untraceable.” While Hacking Team initially claimed their products are not sold to “governments or to countries blacklisted by the U.S., E.U., U.N., NATO or ASEAN” the data dump made public as result of their breach indicated otherwise. In fact, their customers include major players in finance, energy, and telecommunications. Among all the 0-days and exploits in the Hacking Team dump, it was even discovered that they offered UEFI BIOS rootkit to ensure “that it silently reinstalls its surveillance tool even if the hard drive is wiped clean or replaced.” With industry giants willing to seemingly utilize the likes of RCS, we’re left to wonder where the line will be drawn. I long ago assumed there is no line and therefore assume there is no privacy. May I recommend you join me in this gloomy outlook?
Perhaps a little proof may help you come to terms with this simple rule: don’t store or transmit via digital media that what which you don’t want read by anyone and everyone.
To get to the heart of the matter, we’ll assess some Hacking Team “products”, pulled from the public dump, with Beenu Arora’s Hook Analyser. Beenu just celebrated the release of Hook Analyser 3.2 as of 19 JUL. You may recall that I mentioned Hook Analyser via the Internet Storm Center Diary for the Keeping The RATs Out series, we’ll put it through its paces here. Per Beenu, Hook Analyser is a freeware project which brings malware (static & dynamic) analysis and cyber threat intelligence capabilities together. It can perform analysis on suspicious or malware files and can analyze software for crash-points or security bugs. The malware analysis module can perform the following actions:
·         Spawn and Hook to Application
·         Hook to a specific running process
·         Static Malware Analysis
o   Scans PE/Windows executables to identify potential malware traces
·         Application crash analysis
o   Allows you to analyze memory content when an application crashes
·         Exe extractor
o   Extracts executables from running process/s
The Cyber Threat Intelligence module provides open source intelligence where you can search for IP addresses, hashes or keywords. It will collect relevant information from various sources, analyze the information to eliminate false-positives, correlate the various datasets, and visualize the results. 
What better to run Hacking Team binaries through. Let’s begin.
Hacking Team Samples

I pulled four random binaries out of the Hacking Team dump for analysis, sticking exclusively to EXEs. There are numerous weaponized document and media files, but I was most interested in getting to the heart of the matter with Hook Analyser. Details for the four samples follow:
1.       agent 222.exe
a.       MD5: fea2b67d59b0af196273fb204fd039a2
b.       VT: 36/55
2.       agent 1154.exe
a.       MD5: c1c99e0014c6d067a6b1092f2860df4a
b.       VT: 31/55
3.       Microsoft Word 2010 2.exe
a.       MD5: 1ea8826eeabfce348864f147e0a5648d
b.       VT: 0/55
4.       my_photo_holiday_my_ass_7786868767878 19.exe
a.       MD5: e36ff18f794ff51c15c08bac37d4c431
b.       VT: 48/55
I found it interesting that one of the four (Microsoft Word 2010 2.exe) exhibited no antimalware detection via Virus Total as this was written, so I started there.

Hook Analyser

Hook Analyser is stand-alone and runs in console mode on contemporary Windows systems. For this effort I ran it on Windows 7 x32 & x64 virtual machines. The initial UI as seen in Figure 1 is basic and straightforward.

Figure 1 – Hook Analyser UI
For Microsoft Word 2010 2.exe I opted to use Spawn and Hook to Application and provided the full path to the sample. Hook Analyser exited quickly but spawned C:\tools\Hook Analyser 3.2\QR7C8A.exe, with which I repeated the process. The result was a robust output log to a text file named by date and time of the analysis, and an XML report, named identically, of the high-level behaviors of the sample.  A few key items jumped right out in the reports. First, the sample is debug aware. Second, it spawns a new process. Third, Hook Analyser found one trace of a potential PDB/Project at offset 00007F0. When I ran strings against the sample I found c:\users\guido\documents\visual studio 2012\Projects\fake_office\Release\fake_office.pdb, confirming the project and even the developer. I’d have to err on the side of threat related in this scenario, just on project name alone. Further analysis by Microsoft’s Malware Protection Center revealed that it checks for the presence of a legitimate instance of winword.exe on C: or D:, then executes C:\a.exe. As a results, this sample has been classified “threat related”. Based on naming conventions followed by Hacking Team, one can reasonably conclude that C:\a.exe is likely an RCS agent. By the way, Guido, in this case, is probably Guido Landi, a former senior Hacking Team software developer.
You can see the overall output from both reports in a combined Figure 2.

Figure 2 – Hook Analyser results

I took a different approach with the next sample analysis, specifically agent 222.exe. I first executed the sample, then chose Hook to a specific running process. Hook Analyser then provides a listing of all active processes. Agent 222.exe showed itself with process ID 3376. I entered 3376 and Hook Analyser executed a quick run and spawned GVNTDQ.exe. I reran Hook Analyser, selected 3 for Perform Static Malware Analysis, and provided C:\tools\Hook Analyser 3.2\GVNTDQ.exe. GVNTDQ.exe is simply a new instance of Agent 222.exe. This time another slew of very interesting artifacts revealed themselves.  The “agent” process runs as TreeSizeFree.exe, an alleged hard disk space manager from JAM Software, and runs as trusted given that it is signed by a Certum/Unizeto cert. It also appears to be anti-debugging aware and packed using an unknown packer. The sample manipulates GDI32.dll, the OS’s graphic device interface and
WINHTTP.dll (mapped in memory) with a WinHttpGetIEProxyConfigForCurrentUser call, which provides the Internet Explorer proxy settings for the current active network connection. Remember that privacy you were so interested in maintaining?

Let’s say you’re asked to investigate a suspect system, and you have no prior knowledge or IOCs. You do discover a suspicious process running and you’d like to dump it. Choose Exe Extractor (from Process), reply no when it asks if you’d like to dump all processes, then provide the process ID you’d like extracted. It will write an EXE named for the process ID to your Hook Analyser working directory.
You can also run batch jobs against a directory of samples by choosing Batch Malware Analysis, then providing the path to the sample set.

I’d be remiss if I didn’t use the Threat Intelligence module with some of the indicators discovered with Hook Analyser. To use it, you really want to prep it first. The Threat Intelligence module includes:
·         IP Intelligence
·         Keyword Intelligence
·         Network file analysis
o   PCAP
·         Social Intelligence
o   Pulls data from Twitter for user-defined keywords, performs network analysis
Each of these is managed by a flat text file as described in Beenu’s recent post. One note, don’t get to extravagant with your keywords. Try to use unique terms that are tightly related to your investigation and avoid using broad terms such as agent in this case. I dropped a Hacking Team-related IP address in the intelligence-ipdb.txt file, the keywords Certum, Unizeto, Hacking Team, and RCS in keywords.txt, and Hacking Team in channels.txt. Tune these files to your liking and current relevance. As an example URL.txt has some extremely dated resources from which it pulls IP information, there’s no reason to waste cycles on all of the default list. I ran the Threat Intelligence module as a standalone feature as follows: ThreatIntel.exe -auto. Give it a bit of time, it checks against all the provided sources and against Twitter as well. Once complete it will pop a view open in your default browser. You’ll note general information under Global Threat Landscape including suspicious IPs and ASNs, recent vulnerability data, as well as country and geo-specific threat visualizations. More interesting and related to your investigation will be the likes of Keyword based Cyber Intelligence.  The resulting Co-relation (Bird Eye) view is pretty cool, as seen in Figure 3.

Figure 3 – A bird’s eye view to related Hacking Team keywords
Drill into the complete view for full keyword content results. I updated channels.txt to include only hackingteam and intelligence-ipdb.txt with related Hacking Team IP addresses. While I was unable to retrieve viable results for IP intelligence, the partial results under Social Intelligence (Recent Tweets) were relevant and timely as seen in Figure 4.

Figure 4 – Recent Hacking Team related Tweets per the Threat Intelligence module
There are a few bugs that remain in the Threat Intelligence module, but it definitely does show promise, I’m sure they’ll be worked out in later releases.

In Conclusion

The updates to the Threat Intelligence module are reasonable, potentially making for a useful aggregation of data related to your investigation, gleaned from your indicators and analysis. Couple that with good run-time and static analysis of malicious binaries and you have quite a combination for your arsenal. Use it in good health, to you and your network!
Ping me via email or Twitter if you have questions (russ at holisticinfosec dot org or @holisticinfosec).
Cheers…until next month.

ACK

Beenu Arora, @beenuar, Hook Analyser developer and project lead

Wednesday, July 01, 2015

toolsmith: Malware Analysis with REMnux Docker Containers

Prerequisites
Docker, runs on Ubuntu, Mac OS X, and Windows

Introduction
ISSA Journal’s theme of the month is “Malware and what to do with it”. This invites so many possible smart-alecky responses, including where you can stick it, means by which to smoke it, and a variety of other abuses for the plethora of malware authors whose handy work we so enjoy each and every day of our security professional lives. But alas, that won’t get us further than a few chuckles, so I’ll just share the best summary response I’ve read to date, courtesy of @infosecjerk, and move on.
“Security is easy:
1)      Don't install malicious software.
2)      Don't click bad stuff.
3)      Only trust pretty women you don't know.
4)      Do what Gartner says.”
Wait, now I’m not sure there’s even a reason to continue here. :-)

One of the true benefits of being a SANS Internet Storm Center Handler is working with top notch security industry experts, and one such person is Lenny Zeltser. I’ve enjoyed Lenny’s work for many years; if you’ve taken SANS training you’ve either heard of or attended his GIAC Reverse Engineering Malware course and likely learned a great deal. You’re hopefully also aware of Lenny’s Linux toolkit for reverse-engineering and analyzing malware, REMnux. I covered REMnux in September 2010, but it, and the landscape, have evolved so much in the five years since. Be sure to grab the latest OVA and revisit it, if you haven’t utilized it lately. Rather than revisit REMnux specifically this month, I’ll draw your attention to a really slick way to analyze malware with Docker and specific malware-analysis related REMnux project Docker containers that Lenny’s created. Lenny expressed that he is personally interested in packaging malware analysis apps as containers because it gives him the opportunity to learn about container technologies and understand how they might be related to his work, customers and hobbies. Lenny’s packaging tools that are “useful in a malware analysis lab, that like-minded security professionals who work with malware or forensics might also find an interesting starting point for experimenting with containers and assessing their applicability to other contexts.”
Docker can be utilized on Ubuntu, Mac OS X, and Windows, I ran it on the SANS SIFT 3.0 virtual machine distribution, as well as my Mac Mini. The advantage of Docker containers, per the What Is Docker page, is simple to understand. First, “Docker allows you to package an application with all of its dependencies into a standardized unit for software development.” Everything you need therefore resides in a container: “Containers have similar resource isolation and allocation benefits as virtual machines but a different architectural approach allows them to be much more portable and efficient.” The Docker Engine is just that, the source from whom all container blessings flow. It utilizes Linux-specific kernel features so to run it on Windows and Mac OS X, it will install VirtualBox and boot2docker to create a Linux VM for the containers to run on Windows and Mac OS X. Windows Server is soon adding direct support for Docker with Windows Server Containers. In the meantime, if you’re going to go this extent, rather than just run natively on Linux, you might as well treat yourself to Kitematic, the desktop GUI for Docker. Read up on Docker before proceeding if you aren’t already well informed. Most importantly, read Security Risks and Benefits of Docker Application Containers.
Lenny mentioned that he is not planning to use containers as the architecture for the REMnux distro, stating that “This distribution has lots of useful tools installed directly on the REMnux host alongside the OS. It's fine to run most tools this way. However, I like the idea of being able to run some applications as separate containers, which is certainly possible using Docker on top of a system running the REMnux distro.” As an example, he struggled to set up Maltrieve and JSDetox directly on REMnux without introducing dependencies and settings that might break other tools but “running these applications as Docker containers allows people to have access to these handy utilities without worrying about such issues.” Lenny started the Docker image repository under the REMnux project umbrella to provide people with “the opportunity to conveniently use the tools available via the REMnux Docker repository even if they are not running REMnux.”
Before we dig in to REMnux Docker containers, I wanted to treat you to a very cool idea I’ve implemented after reading it on the SANS Digital Forensics and Incident Response Blog as posted by Lenny. He describes methods to install REMnux on a SIFT workstation, or SIFT on a REMnux workstation. I opted for the former because Docker runs really cleanly and natively on SIFT as it is Ubuntu 14.04 x64 under the hood. Installing REMnux on SIFT is as easy as wget --quiet -O - https://remnux.org/get-remnux.sh | sudo bash, then wait a bit. The script will update APT repositories (yes, we’re talking about malware analysis but no, not that APT) and install all the REMnux packages. When finished you’ll have all the power of SIFT and REMnux on one glorious workstation. By the way, if you want to use the full REMnux distribution as your Docker host, Docker is already fully installed.

Docker setup

After you’ve squared away your preferred distribution, be sure to run sudo apt-get update && sudo apt-get upgrade, then run sudo apt-get install docker.io.

REMnux Docker Containers

Included in the REMnux container collection as of this writing you will find the V8 JavaScript engine, the Thug low-interaction honeyclient, the Viper binary analysis framework, Rekall and Volatility memory forensic frameworks, the JSDetox JavaScript analysis tool, the Radare2 reverse engineering framework, the Pescanner static malware analysis tool, the MASTIFF static analysis framework, and the Maltrieve malware samples downloader. This may well give you everything you possibly need as a great start for malware reverse engineering and analysis in one collection of Docker containers. I won’t discuss the Rekall or Volatility containers as toolsmith readers should already be intimately familiar with, and happily using, those tools. But it is mighty convenient to know you can spin them up via Docker.
The first time you run a Docker container it will be automatically pulled down from the Docker Hub if you don’t already have a local copy. All the REMnux containers reside there, you can, as I did, start with @kylemaxwell’s wicked good Maltrieve by executing sudo docker run --rm -it remnux/maltrieve bash. Once the container is downloaded and ready, exit and rerun it with sudo docker run --rm -it -v ~/samples:/home/sansforensics/samples remnux/maltrieve bash after you build a samples directory in your home directory. Important note: the -v parameter defines a shared directory that the container and the supporting host can both access and utilized. Liken it to Shared Folders in VMWare. Be sure to run sudo chmod a+xwr against it so it’s world readable/writeable. When all said and done you should be dropped to a nonroot prompt (a good thing), simply run maltrieve -d /home/sansforensics/samples/ -l /home/sansforensics/samples/maltieve.log and wait again as it populates malware samples to your sample directory, as seen in Figure 1, from the likes of Malc0de, Malware Domain List, Malware URLs, VX Vault, URLquery, CleanMX, and ZeusTracker.

Figure 1 – Maltrieve completes its downloads, 780 delicious samples ready for REMnux
So nice to have a current local collection. The above mentioned sources update regularly so you can keep your sample farm fresh. You can also define your preferred DUMPDIR and log directories in maltrieve.cfg for ease of use.

Next up, a look at the REMnux MASTIFF container. “MASTIFF is a static analysis framework that automates the process of extracting key characteristics from a number of different file formats” from @SecShoggoth.  I ran it as follows: sudo docker run --dns=my.dns.server.ip --rm -it -v ~/samples:/home/sansforensics/samples remnux/mastiff bash. You may want or need to replace --dns=my.dns.server.ip with your preferred DNS server if you don’t want to use the default 8.8.8.8. I found this ensured name resolution for me from inside the container. MASTIFF can call the VirusTotal API and submit malware if you configure it to do so with mastiff.conf, it will fail if DNS isn’t working properly. You need to edit mastiff.conf via vi with you API key and enable submit=yes. Also note that, when invoked with --rm parameters, the container will be ephemeral and all customization will disappear once the container exits. You can invoke the container differently to save the customization and the state.
You may want to also instruct the log_dir directive to point at your shared samples directory so the results are written outside the container.
You can then run mas.py /your/working/directory/samplename with your correct preferences and the result should resemble Figure 2.

Figure 2 – Successful REMnux MASTIFF run
All of the results can be found in /workdir/log under a folder named for each sample analyzed. Checking the Yara results in yara.txt will inform you that the while the payload is a PE32 it exhibits malicious document attributes per Didier Steven’s (another brilliant Internet Storm Center handler) maldoc rules as seen in Figure 3.

Figure 3 – Yara results indicating a malicious document attributes
The peinfo-full and peinfo-quick results will provide further details, indicators, and behaviors necessary to complete your analysis.

Our last example is the REMnux JSDetox container. Per its website, courtesy of @sven_t, JSDetox “is a tool to support the manual analysis of malicious Javascript code.” To run it is as simple as sudo docker run --rm -p 3000:3000 remnux/jsdetox, then point your browser to http://localhost:3000 on your container host system. One of my favorite obfuscated malicious JavaScipt examples comes courtesy of aw-snap.info and is seen in its raw, hidden ugliness in Figure 4.

Figure 4 – Obfuscated malicious JavaScript
Feed said script to JSDetox under the Code Analysis tab, run Analyze, choose the Execution tab, then Show Code and you’ll quickly learn that the obfuscated code serves up a malicious script from palwas.servehttp.com, flagged by major browsers and Sucuri.net as distributing malware and acting as a redirector. The results are evident in Figure 5.

Figure 5 – JSDetox results
All the malware analysis horsepower you can imagine in the convenience of Docker containers, running on top of SIFT with a full REMnux install too. Way to go, Lenny, my journey is complete. J

In Conclusion

Lenny’s plans for the future include maintaining and enhancing the REMnux distro with the help of the Debian package repository he set up for this purpose with Docker and containers part of his design. Independently, he will continue to build and catalog Docker containers for useful malware analysis tools, so they can be utilized with or without the REMnux distro. I am certain this is the best way possible for you readers to immerse yourself in both Docker technology and some of the best of the REMnux collection at the same time. Enjoy!
Ping me via email or Twitter if you have questions (russ at holisticinfosec dot org or @holisticinfosec).
Cheers…until next month.

ACK

Thanks again to Lenny Zeltser, @lennyzeltser, for years of REMnux, and these Docker containers.

Moving blog to HolisticInfoSec.io

toolsmith and HolisticInfoSec have moved. I've decided to consolidate all content on one platform, namely an R markdown blogdown sit...