[00:01.010 --> 00:03.890]  Thank you for listening to our DEF CON Demo Labo.
[00:03.890 --> 00:06.350]  I'm Shusei Tomuraga from JPSAT.
[00:06.350 --> 00:09.330]  Our Demo Labo presentation today is about
[00:09.330 --> 00:12.670]  MarconScan with KUKU, a tool that automatically
[00:12.670 --> 00:15.310]  dumps malware configuration data.
[00:17.470 --> 00:21.930]  First, let's talk about why we want to create such a tool
[00:21.930 --> 00:23.970]  and its motivation.
[00:24.430 --> 00:27.430]  Sandbox is a great tool for malware analysts.
[00:27.430 --> 00:29.870]  However, we, the malware analysts,
[00:29.870 --> 00:33.130]  cannot get what we want using the sandbox.
[00:35.680 --> 00:38.050]  We want configuration data.
[00:38.050 --> 00:42.270]  We need to get configuration data for static analysis.
[00:44.600 --> 00:48.030]  Why do we need malware configuration data?
[00:48.030 --> 00:51.610]  Many barriers of malware code are almost unchanged
[00:51.610 --> 00:55.530]  and only configuration data is defined.
[00:55.530 --> 00:57.770]  If the configuration data is known,
[00:57.770 --> 01:00.570]  there is no need for static analysis.
[01:01.130 --> 01:04.130]  Configuration data contains important information
[01:04.130 --> 01:08.830]  that cannot be obtained by sandbox analysis,
[01:08.830 --> 01:11.990]  such as campaign ID, encryption key,
[01:11.990 --> 01:13.990]  C2 server, and so on.
[01:16.170 --> 01:18.570]  Let me introduce how malware analysts
[01:18.570 --> 01:21.350]  extract malware configuration.
[01:23.090 --> 01:27.510]  This is very simple, so everyone should remember this.
[01:30.310 --> 01:32.890]  First step, we analyze the malware
[01:32.890 --> 01:37.770]  to understand how to encrypt the configuration data.
[01:37.770 --> 01:41.850]  Then we understand the structure of the configuration data.
[01:45.060 --> 01:48.580]  Step two, we create our tools
[01:48.580 --> 01:51.880]  for extracting configuration data.
[01:52.600 --> 01:55.000]  That's all, it's very simple.
[01:57.600 --> 02:01.180]  For example, in the case of PlugX,
[02:01.180 --> 02:05.200]  in PlugX data, PlugX main module and configuration
[02:05.200 --> 02:10.240]  are encoded for original algorithm and LZNT1.
[02:11.120 --> 02:19.080]  All decoded data is injected into one process and running.
[02:20.060 --> 02:23.320]  PlugX custom encoding algorithm
[02:23.320 --> 02:26.000]  depending on the version of it.
[02:27.140 --> 02:28.840]  This custom encoding algorithm
[02:28.840 --> 02:32.840]  is used to encode key log file modules
[02:32.840 --> 02:35.190]  and configuration data.
[02:37.700 --> 02:40.880]  Configuration structure also differs
[02:40.880 --> 02:43.180]  depending on the version.
[02:43.180 --> 02:45.820]  PlugX has a maximum configuration data
[02:45.820 --> 02:49.390]  of 0x36A4 size.
[02:50.140 --> 02:54.050]  It has such large configuration data is running.
[02:56.900 --> 02:59.820]  Other example is ts-cookie.
[02:59.820 --> 03:01.580]  ts-cookie is very simple,
[03:01.580 --> 03:04.960]  use only RC4 for encryption.
[03:05.080 --> 03:09.180]  This pattern has not changed for about five years.
[03:11.280 --> 03:17.400]  The size of ts-cookie configuration data is 0x8D0,
[03:17.400 --> 03:20.780]  which is the same as another normal malware.
[03:22.280 --> 03:26.340]  So it is difficult to analyze a lot of malware
[03:26.340 --> 03:28.100]  in the same way.
[03:28.100 --> 03:29.900]  From this slide,
[03:29.900 --> 03:34.800]  I will introduce a tool we created named MarukonScan.
[03:35.220 --> 03:37.200]  MarukonScan is a ValTT plugin
[03:37.200 --> 03:40.760]  that extracts the configuration data of known malware.
[03:40.760 --> 03:44.080]  ValTT is an open source memory forensic framework
[03:44.080 --> 03:47.640]  for incident response and malware analysis.
[03:48.040 --> 03:50.980]  This tool search for malware in memory image
[03:50.980 --> 03:53.370]  and dumps configuration data.
[03:54.990 --> 03:57.340]  This is an example of MarukonScan
[03:57.340 --> 04:00.260]  dumping RedRibs malware configuration.
[04:00.260 --> 04:03.360]  You can see C2 server, encryption key,
[04:03.360 --> 04:05.620]  mutex, and user agent.
[04:06.420 --> 04:10.060]  This tool dumps different configuration data
[04:10.060 --> 04:11.980]  depending on malware.
[04:14.940 --> 04:19.200]  Now, MarukonScan support over 28 malware.
[04:20.840 --> 04:23.880]  MarukonScan support most of the malware families
[04:23.880 --> 04:27.420]  reported in any run's top 10 threat report.
[04:31.040 --> 04:35.680]  So, I think you have a question here.
[04:35.680 --> 04:37.140]  Why use ValTT?
[04:40.620 --> 04:44.060]  It is effective to analyze the memory dump.
[04:44.060 --> 04:46.440]  There are two advantages.
[04:46.500 --> 04:49.380]  First, no need to unpack.
[04:49.380 --> 04:51.760]  When extracting configuration data,
[04:51.760 --> 04:54.800]  it is not necessary to unpack malware.
[04:54.800 --> 04:57.380]  Second, no need to decode
[04:57.380 --> 05:00.480]  because encoded configuration data
[05:00.480 --> 05:03.990]  may be already decoded on memory.
[05:04.720 --> 05:06.680]  You may be able to skip running
[05:06.680 --> 05:09.170]  how to decrypt configuration data.
[05:12.180 --> 05:15.400]  In addition, this tool also dumps
[05:15.400 --> 05:18.560]  more than configuration data if needed.
[05:18.880 --> 05:21.160]  In addition to configuration data,
[05:21.160 --> 05:25.640]  it dumps decoded strings and DGA domains.
[05:27.850 --> 05:30.240]  This is an example of MarukonScan
[05:31.010 --> 05:33.820]  dumping web of malware configuration.
[05:33.820 --> 05:38.370]  You can see RSA key, bot ID, and DGA domains.
[05:41.000 --> 05:43.660]  Here is another example of MarukonScan
[05:43.660 --> 05:47.160]  dumping phone book malware configuration.
[05:47.160 --> 05:52.330]  You can see C2 server and decoded strings.
[05:54.680 --> 05:59.540]  MarukonScan have another feature called MariaSTL scan.
[05:59.540 --> 06:02.060]  MariaSTL scan function can list the strings
[06:02.060 --> 06:04.480]  the following process refers.
[06:04.820 --> 06:08.520]  Configuration data is usually encoded by malware.
[06:08.520 --> 06:10.740]  However, most of malware writes
[06:10.740 --> 06:13.800]  decoded configuration data on memory.
[06:13.800 --> 06:16.980]  This function lists decoded configuration data
[06:16.980 --> 06:18.180]  when possible.
[06:20.100 --> 06:24.260]  The strings command may list unreferred strings,
[06:24.260 --> 06:27.720]  but this tool only displays the strings
[06:27.720 --> 06:30.200]  referred to in the code.
[06:30.200 --> 06:34.180]  And this function can also display the heap area.
[06:34.260 --> 06:38.840]  If decoded configuration data is in the heap area,
[06:38.840 --> 06:40.420]  it will be displayed.
[06:42.620 --> 06:46.700]  MarukonScan also support Linux-based memory image.
[06:46.700 --> 06:49.500]  However, there are still few Linux malware
[06:49.500 --> 06:51.520]  that can be scanned.
[06:53.920 --> 06:56.020]  So it's the time.
[07:04.320 --> 07:08.340]  You can use MarukonScan from command line.
[07:08.340 --> 07:11.860]  Set primary name and pass to memory dump file
[07:11.860 --> 07:15.380]  and OS profile of memory dump.
[07:22.270 --> 07:27.070]  Here is a sample of Red Ribs Maria used by FPT10.
[07:27.070 --> 07:34.190]  You can find C2 server address, campaign ID, user agent,
[07:35.010 --> 07:36.390]  and so on.
[07:45.720 --> 07:48.920]  So let's move on the next sample.
[07:48.920 --> 07:53.430]  This sample is TS cookie, Maria used by BlackTek.
[07:59.960 --> 08:02.870]  You can find the C2 server address,
[08:07.150 --> 08:13.390]  and encryption key, campaign ID, and so on.
[08:27.650 --> 08:31.570]  If you want to know more detail about the MarukonScan,
[08:31.570 --> 08:34.530]  you can check out our wiki on GitHub.
[08:34.530 --> 08:37.510]  In this wiki, you can learn how to install
[08:37.510 --> 08:39.740]  and use MarukonScan.
[08:45.150 --> 08:47.140]  Hello guys, I'm Tomoki Tani,
[08:47.140 --> 08:50.620]  the developer of MarukonScan and MarukonScan with Google.
[08:50.620 --> 08:52.360]  From here, I would like to show
[08:52.360 --> 08:55.380]  how to automate the MarukonScan analysis.
[08:55.940 --> 08:57.960]  MarukonScan alone cannot dump
[08:57.960 --> 09:00.260]  configuration data automatically.
[09:00.260 --> 09:03.780]  To automate the extraction of malware configuration,
[09:03.780 --> 09:07.240]  we've developed a tool that executes MarukonScan
[09:07.240 --> 09:09.120]  in Cuckoo Sandbox.
[09:11.920 --> 09:14.940]  MarukonScan with Cuckoo is Cuckoo Sandbox plugin
[09:14.940 --> 09:16.980]  for MarukonScan.
[09:16.980 --> 09:20.000]  The plugin adds the function to extract
[09:20.000 --> 09:23.440]  novel malware's configuration data from memory dump,
[09:23.440 --> 09:27.980]  and then add MarukonScan report to Cuckoo Sandbox.
[09:30.470 --> 09:32.570]  And how it works.
[09:32.610 --> 09:36.030]  This tool uses Cuckoo's memory dump function
[09:36.030 --> 09:39.390]  to extract configuration data of executed malware
[09:39.390 --> 09:40.690]  from memory dumps.
[09:44.500 --> 09:47.620]  Here's a video we make to give you an idea
[09:47.620 --> 09:50.400]  how MarukonScan with Cuckoo works.
[10:02.600 --> 10:05.520]  MarukonScan with Cuckoo integrates MarukonScan
[10:05.520 --> 10:07.500]  into Cuckoo Sandbox.
[10:07.640 --> 10:10.500]  It enables extracting malware configuration
[10:10.500 --> 10:12.380]  in Cuckoo Sandbox.
[10:14.240 --> 10:17.180]  And let's see how MarukonScan with Cuckoo works.
[10:21.660 --> 10:25.300]  All you need to do is upload malware to Cuckoo.
[10:27.140 --> 10:30.120]  Cuckoo sends the malware into the virtual machine
[10:32.500 --> 10:35.480]  and executes it on the host.
[10:38.720 --> 10:40.340]  Cuckoo acquires the memory dump
[10:40.340 --> 10:43.320]  and send it to MarukonScan.
[10:45.300 --> 10:47.600]  MarukonScan analyzes the memory dump
[10:47.600 --> 10:50.820]  and extracts the malware's configuration data.
[10:51.840 --> 10:53.860]  Finally, the malware's configuration
[10:53.860 --> 10:56.080]  will be reported to Cuckoo.
[11:02.470 --> 11:06.570]  This UI shows the Cuckoo's report of MarukonScan.
[11:06.590 --> 11:08.770]  In here, you can find the same result
[11:08.770 --> 11:12.150]  as we saw in the MarukonScan CLI interface.
[11:13.030 --> 11:17.070]  This case shows the report of Red Leaves,
[11:17.070 --> 11:19.650]  the malware used by APT10.
[11:19.790 --> 11:22.730]  You can find the C2 address, campaign ID,
[11:22.730 --> 11:24.830]  and traffic encryption key.
[11:24.970 --> 11:29.330]  Of course, this report is saved into the database.
[11:29.330 --> 11:33.650]  You could search and do some statistic analysis with it.
[11:36.500 --> 11:39.420]  However, we have to overcome some obstacles
[11:39.420 --> 11:42.520]  in order to make a better auto-analysis system.
[11:42.740 --> 11:45.740]  I think most of malware reversers have struggled
[11:45.740 --> 11:47.780]  with the anti-analysis techniques
[11:48.540 --> 11:51.200]  implemented by the malware author.
[11:51.560 --> 11:54.540]  This is same for auto-analysis system.
[11:55.080 --> 11:58.380]  For example, Earthsniff, used to attack Japan,
[11:58.380 --> 12:01.100]  has many kinds of anti-analysis functions.
[12:01.100 --> 12:03.800]  If you have experience to analyze it,
[12:03.800 --> 12:06.740]  you have seen this pop-up.
[12:10.340 --> 12:12.440]  As you know, there are several types
[12:12.440 --> 12:14.280]  of anti-analysis techniques,
[12:14.280 --> 12:17.040]  and it is not easy to bypass all of them.
[12:17.600 --> 12:21.960]  Checking language systems, system running time,
[12:21.960 --> 12:24.140]  total size of physical memory,
[12:24.140 --> 12:26.700]  is generally used for these techniques.
[12:27.120 --> 12:30.780]  Also, checking virtualization is well-known techniques.
[12:30.780 --> 12:34.200]  In these techniques, malware calls CPU ID instruction
[12:34.600 --> 12:37.540]  and checks the specific return value,
[12:37.540 --> 12:42.660]  or checks registry keys, which hypervisor set up.
[12:43.600 --> 12:46.240]  And some malware checks the process names,
[12:46.240 --> 12:50.260]  like Wireshark, or ODDebug, or ProcMon.
[12:50.520 --> 12:52.860]  So, how can we bypass them?
[12:52.860 --> 12:57.400]  Do we need to use physical Windows host for sandbox?
[13:00.090 --> 13:02.090]  The answer is no.
[13:02.090 --> 13:05.030]  Let's bypass them by configuring our virtual machine.
[13:05.030 --> 13:09.210]  It's much more easier than preparing a physical machine.
[13:12.370 --> 13:14.690]  Okay, let's check some samples.
[13:14.810 --> 13:16.850]  This control flow graph shows
[13:16.850 --> 13:20.430]  an anti-analysis function embedded in EarthNift backer.
[13:20.670 --> 13:24.190]  Here, you can find four anti-analysis techniques.
[13:24.330 --> 13:26.630]  It checks CPU brand name,
[13:26.630 --> 13:30.290]  SCSI device name, boot time, and debugger.
[13:30.870 --> 13:33.930]  Let's check some of these anti-analysis techniques
[13:33.930 --> 13:36.770]  and how to bypass them.
[13:38.870 --> 13:41.070]  CPU brand name detection.
[13:41.690 --> 13:44.030]  Malware calls the CPU ID instruction
[13:44.030 --> 13:46.530]  with specified value on EAX register
[13:47.290 --> 13:50.490]  and get the CPU brand name as a return value.
[13:50.890 --> 13:54.450]  In this case, it is checking if Xeon
[13:54.450 --> 13:57.870]  is included in the CPU brand name.
[13:58.090 --> 14:01.170]  In many cases, sandbox is running on the server
[14:01.670 --> 14:03.870]  and the server uses Xeon processor.
[14:06.320 --> 14:09.100]  It is calling CPU instruction direct
[14:09.100 --> 14:11.940]  and it is not easy to hook this call.
[14:12.040 --> 14:14.260]  So how can we bypass it?
[14:14.400 --> 14:18.040]  The answer is modify the virtual machine configuration.
[14:20.260 --> 14:23.160]  Here is a sample virtual machine configuration.
[14:23.280 --> 14:24.680]  In this slide, it is showing
[14:24.680 --> 14:27.120]  the sample configuration of VMware.
[14:27.980 --> 14:29.660]  It is not well known,
[14:29.660 --> 14:33.860]  but VMware allows you to modify the CPU ID response.
[14:34.780 --> 14:38.080]  Also, VirtualBox allows you to modify it.
[14:42.200 --> 14:44.620]  After setting this configuration,
[14:44.620 --> 14:47.280]  you can find that the OS is showing
[14:47.280 --> 14:49.100]  the different CPU brand name.
[14:50.800 --> 14:52.420]  With this technique,
[14:52.420 --> 14:55.060]  you can bypass most of the anti-analysis techniques
[14:55.060 --> 14:57.900]  using CPU ID instruction.
[15:01.850 --> 15:05.330]  Let's check another anti-analysis techniques.
[15:05.470 --> 15:08.650]  In here, Malware is calling Windows API
[15:08.650 --> 15:10.470]  to check the device name.
[15:11.170 --> 15:16.590]  If device name includes VBox or VMware,
[15:16.590 --> 15:19.090]  Malware will kill itself.
[15:19.750 --> 15:23.170]  It is possible to bypass with Hooks API,
[15:23.170 --> 15:26.830]  but it is more easy to modify the virtual machine settings.
[15:30.530 --> 15:32.990]  Here is a sample configuration.
[15:33.210 --> 15:36.170]  As you can see, you could also change the device name
[15:36.170 --> 15:39.950]  just writing few lines into the configuration file.
[15:40.210 --> 15:42.410]  You could do the same things for MAC address
[15:42.410 --> 15:47.210]  or CD drive name or BIOS setting, et cetera, et cetera.
[15:51.240 --> 15:55.820]  Here is our recommended setting for anti-anti-analysis.
[15:56.080 --> 15:59.580]  First, do not install VMware tools
[15:59.580 --> 16:02.300]  or VirtualBox guest additions.
[16:02.680 --> 16:04.680]  These tools modify so many settings
[16:04.680 --> 16:08.360]  and it makes it easy to detect the sandbox environment.
[16:08.840 --> 16:12.100]  Second is use local language operating system
[16:12.100 --> 16:13.860]  for virtual machine.
[16:14.160 --> 16:18.020]  Some malware is specified for regions,
[16:18.020 --> 16:20.680]  and if you want to analyze these malware,
[16:20.680 --> 16:22.980]  use local languages always.
[16:23.700 --> 16:27.460]  Third is modify the virtual machine configuration.
[16:27.460 --> 16:31.440]  Especially, we recommend to modify CPU ID response,
[16:31.440 --> 16:34.620]  device name, and NIC setting.
[16:35.440 --> 16:39.020]  In most case, we are able to bypass anti-analysis techniques
[16:39.020 --> 16:40.680]  with these settings.
[16:43.390 --> 16:46.520]  Okay, let's move on to the demonstration
[16:46.520 --> 16:48.900]  of Malcom scan with Cuckoo.
[16:58.920 --> 17:02.480]  Okay, here is the web GUI of Cuckoo.
[17:02.540 --> 17:08.020]  All things you need to do is submit malware and do analysis.
[17:15.730 --> 17:21.350]  Each analysis takes two to three minutes per sample.
[17:24.390 --> 17:27.150]  Okay, let's check the report.
[17:30.960 --> 17:34.940]  You could find the report in VM memory dump menu.
[17:37.710 --> 17:42.170]  And click Malcom scan tab, and the result will display.
[17:43.010 --> 17:45.870]  Here is showing some sample reports.
[17:45.870 --> 17:48.870]  This is Himari, the variant of Red Leaves.
[17:53.940 --> 17:59.020]  And this is ts-cookie, the malware used by Blacktech.
[18:05.040 --> 18:09.220]  And Ersniff, as known as DreamBot,
[18:09.420 --> 18:12.480]  a very numerous banking Trojan.
[18:15.580 --> 18:18.360]  And yes, that's all for the demonstration.
[18:22.360 --> 18:24.180]  If you want to know more detail
[18:24.180 --> 18:26.280]  about the Malcom scan with Cuckoo,
[18:26.280 --> 18:29.480]  you can check it out our wiki on GitHub.
[18:29.580 --> 18:32.140]  In this wiki, you can learn how to install
[18:32.140 --> 18:34.860]  and how to use Malcom scan with Cuckoo.
[18:34.860 --> 18:38.580]  And if you want to know more detail about anti-analysis,
[18:38.580 --> 18:39.700]  we have written some articles
[18:39.700 --> 18:43.180]  and some sample configuration on this wiki.
[18:46.480 --> 18:49.380]  And now, we are developing Malcom scan
[18:49.380 --> 18:53.280]  which supports Bolt ET3.
[18:53.280 --> 18:57.360]  We have released the beta version on our GitHub repository.
[18:57.760 --> 19:02.420]  You could find this code in the Bolt ET3 branch.
[19:02.740 --> 19:06.320]  We will finish the conversion as soon as possible.
[19:06.940 --> 19:10.200]  In Bolt ET3, you don't need to set the memory profile
[19:10.200 --> 19:13.660]  and also has a better support to Windows 10.
[19:13.660 --> 19:18.900]  So we recommend you to use Bolt ET3 rather than Bolt ET2.
[19:20.820 --> 19:22.360]  Okay, that's all.
[19:22.360 --> 19:23.920]  And thank you for watching.
[19:23.920 --> 19:26.320]  And any feedback is welcome.
[19:26.440 --> 19:27.420]  Thank you.