Summary of recent Anti-Sandbox Tricks

    Regardless of the technology being used maintaining an efficient sandbox requires to continuously monitor new malware samples in order to effectively cope with new evasion techniques. Today we want to share some of the techniques that we have spotted during the last couple of months. We mentioned some of these already briefly on our Twitter feed.

    COM/DirectShow Audio device checks

    One of the TeslaCrypt variants utilize the COM-based DirectShow audio related piece of code shown below to avoid sandboxes and emulators:

    The code above is intended  not only to check the presence of an audio device, but it also verifies if the API is fully operational (probably in order to filter out poor API emulation). Let's go through the code to see what exactly it does:

    CoCreateInstance(CLSID_FilterGraph, IID_IGraphBuilder)
    Standard DirectShow initialization, error code is not checked
    E_POINTER != pGraph->AddFilter(NULL, filterName)
    First anti-emulation check: If AddFilter is called with NULL as a first argument it should return the E_POINTER error code. Some emulators may implement unknown COM interfaces in a generic way, so they will probably fail here.
    CoCreateInstance(CLSID_AudioRender, IID_IBaseFilter)
    Initializes a simple Audio Renderer, error code is not checked, but pBaseFilter will be set to NULL upon failure and the code will eventually fail later.
    pGraph->AddFilter(pBaseFilter, filterName)

    Adds the previously created Audio Renderer to the Filter Graph, no error checks
    pGraph->FindFilterByName(filterName, &pBaseFilter2)
    Tries to find the filter that was just added; in case of any previously not checked error (or wrong emulation) this function won't find the filter and the sandbox/emulator will be successfully detected.
    Checks if info.achName is equal to the previously added filterName, if not - poor API emulation
    Checks if the API sets a proper IReferenceClock pointer
    Checks if CLSID is different from 0
    Just checks if the call was successful
    The reference count returned by AddRef has to be higher than 0

    These are just some random checks to ensure that the malware is executed on a real system. A sandbox here would be considered a real system only if it has an audio device installed. Most emulators will fail since it is close to impossible to implement proper support for every COM interface that is present in modern operating systems.

    Office Recent Files & GeoIP checks

    A recent batch of Dridex embedded in MS Office documents utilizes two different tricks to avoid execution in sandboxed environments. At first, it checks for the number of Recent Files opened by one of the Office apps on the target machine:

    If the number is lower than 3 malware simply stops execution. The second method checks if the ISP/Organization that the machine IP belongs to is on the list below:

    To get this information, this particular malware family abuses the MaxMind GeoIP online database:

    The above snippets are a deobfuscated version of the VBA script that is embedded in the original Office documents. More detailed analysis can be found on the Zscaler blog.

    OS Locale check

    It is a common technique to check the system locale and execute (or not) payload only in some countries. Usually the check is made with GetSystemDefaultLangID Win32 API, which returns a 16-bit value that identifies the OS language (Language Identifiers). Since it is a numerical ID, it is very easy to feed the malware with the correct ID value, so it will believe that it is being executed in the language region of its choice. Recently we came across a sample that uses VerLanguageNameW in addition to the GetSystemDefaultLangID API to get the textual version of the language identifier:

    The results are then compared to the string that is hard-coded in the executable:

    The trick here is that if the OS locale was artificially changed the returned string will be in the language of the original Windows installation. So in case of an English OS it will be Portuguese (Brazil) instead of Portugu√™s (Brasil). Game over.

    Command line switches

    Sometimes it happens that we need to replicate some file, but the original dropper is missing and the sample does not really do anything meaningful. In some cases, the solution is as simple as a missing command line argument. Recently we have added a new signature that detects command line switches and shows them in the final report, so that the user has the ability to re-run the analysis with a proper argument set through a cookbook (The example cookbook is called "Execute binary with arguments"). In such cases the analysis report contains results similar to the one below:

    Expiration date

    This trick is not new, but due to recent Nymaim activity we are getting many queries regarding it. We have already described best practices for such samples in the post describing API hammering, so we will just quote it here to have everything in one place:

    "It is always good to re-run the analysis with different dates to verify if the sample does not expire or if it is not activating in the near future. Usually it is safe to assume the day when the sample was received as the initial date, timestamp from the PE header should work as well. (...) We can easily handle such cases in Joe Sandbox through our Cookbooks technology, whole operation boils down to adding below line to the Cookbook: _SetDate(06, 04, 2016)"

    Final words

    Thanks to the agility and flexibility of Joe Sandbox we can very quickly react to new evasion techniques. This is what we call Agile Malware Analysis. We continuously monitor the latest threats for evasions. Once we find an evasion we write a signature to detect it, and create Anti-Evasions. The concept of Agile Malware Analysis is also adopted by many of our customers. Many of our technologies such as Cookbooks, Hybrid Code Analysis and Execution Graph analysis are extremely helpful for this process. When compared to other approaches Agile Malware Analysis has proven to be by far the most successful concept in the long term.

    Black Hat USA 2016

    Good news! Joe Security will be at Black Hat USA 2016. Meet the Joe Security team at booth IC32 - Innovation City from August 3-4 and get a personal presentation of the Joe Sandbox 15!

    Adaptive Internet Simulation

    Nearly any malware today uses the Internet for communication. Often to download second stage malware, to register at its command and control server, or to spread and propagate. By capturing and analyzing suspicious Internet traffic during the execution, a malware analysis system can detect various interesting artifacts such as domains or IPs used to host malicious content. However allowing Internet access for a malware analysis sandbox also has a big drawback: fingerprinting.

    How does fingerprinting work? Check out the chart below:

    The bad guys start by submitting an info collector program to the target sandboxes. The info collector will enumerate all system settings, hardware ids, serial, tokens, etc., and will report back all the data via Internet.
    A new malware is then created which embeds the previously collected unique hardware ids and checks for them early during its execution. If some of the ids match, the malware sample will not exhibit any malicious behavior. This approach is very simple to implement and does not require many resources. Even if the bad guys do not have direct access to a particular sandbox, the fingerprinting can still succeed due to the global sharing of malware samples. 

    Today fingerprinting is used a lot and poses a big problem for malware analysis systems. There was even a public online tracking page ( showing IP addresses, user names, etc., of online sandboxes:

    We also found various info collectors (e.g. 26b79a7370720b0822bb786043b86448) over the last months:


    Adaptive Internet Simulation

    To solve the problem of fingerprinting, sandbox vendors lately introduced randomization. Randomization will generate random values for all ids and serial numbers. However randomization has several shortcomings. First not all serials and ids can be randomized. Many ids are used by the license verification of the operating system, and changing them will trigger the verification check. Next the number of unique ids, names and settings is enormous, and various tokens influence the system.  Finally randomization today is done during the installation of the sandbox. This means that a system is randomized once and then will stay the same for months: more than enough time to do fingerprinting.

    We have come up with a different idea to solve the problem which we call Adaptive Internet Simulation (AIS). AIS is a full network proxy which sits between the sandbox and the Internet:

    The networks proxy has two main goals:

    1. Prevent leaks such as hardware ids and serials.
    2. Simulate where appropriate. 
    To achieve both goals, we developed a port independent protocol identification engine, a flexible configuration syntax to define what traffic is considered a leak, and a generic simulation framework.

    An info collector running on Joe Sandbox with AIS will not be able to leak the collected sensitive data anymore, however it still runs as if it were connected directly to the Internet. So AIS is nearly transparent.

    Extensive tests have shown that AIS works very well without any impact on the behavior of the malware.

    Besides preventing fingerprinting, AIS has a number of additional nice features:

    • Block "noise traffic" from the OS, such as updates or notifications.
    • Simulation in cases where an IP or a domain is not available anymore.
    • Simulation in cases where resources (e.g. files) are no longer available.
    AIS is currently available as a plugin for various Joe Sandbox products.

    Example reports (sample source Threatwave):

    Nymaim - evading Sandboxes with API hammering

    Recently we were investigating interesting piece of malware that was generating quite huge workload in the sandboxed environment. To introduce proper countermeasures we had to fully reverse it. It turned out that the file belongs to the Nymaim family, which is active at least since 2013 [1]. This particular file consists of few layers, first one is meant to slowdown / timeout various sandboxes / replicators / emulators, the last layer hinders static analysis and debugging, layers in the middle are just responsible for decompression and decryption.

    There are many different methods of introducing slowdowns in sandboxed environments, some of them are more effective some of them are not effective at all. Nymaim uses Win32 API hammering, which means that it constantly calls benign Win32 API functions in the loop. It's clearly visible on the WinMain function graph (glued side by side, since the function is way too big):

    Readers familiar with IDA function graphs should notice unusual length of the code.There is a lot of loops and a lot of various API calls:

    API NameNumber of calls

    Without any monitoring tools, execution of WinMain takes around 46 seconds. Now if any of the above APIs triggers some event that is (or should be) monitored in the sandboxed environment you can imagine what would happen to those 46 seconds. So far we have not seen any sandbox able to analyze the malware successfully. During the analysis we were able to identify one unwelcome side effect of the USER32.dll.EnumDisplaySettingsA function call, namely it loads and unloads the vga.dll kernel library during the call:

    ChildEBP RetAddr
    890136f8 828563ef nt!DbgLoadImageSymbols+0x47
    89013714 82a05b21 nt!DbgLoadImageSymbolsUnicode+0x23
    89013750 82a02531 nt!MiDriverLoadSucceeded+0x183
    890137d0 82a8ccf8 nt!MmLoadSystemImage+0x720
    8901391c 8287a8c6 nt!NtSetSystemInformation+0x967
    8901391c 82879969 nt!KiSystemServicePostCall
    890139a0 907a895a nt!ZwSetSystemInformation+0x11
    89013b1c 907a858b win32k!ldevLoadImage+0x215
    89013b54 907a2b9a win32k!ldevLoadDriver+0x78
    89013b70 907aaec4 win32k!ldevGetDriverModes+0x1c
    89013b9c 90806eb6 win32k!DrvBuildDevmodeList+0x134
    89013bfc 90806aea win32k!DrvEnumDisplaySettings+0x3b9
    89013c1c 8287a8c6 win32k!NtUserEnumDisplaySettings+0x27
    89013c1c 772270f4 nt!KiSystemServicePostCall
    001241d0 762f13c4 ntdll!KiFastSystemCallRet
    001241d4 763065c1 USER32!NtUserEnumDisplaySettings+0xc
    00124214 76306502 USER32!EnumDisplaySettingsExA+0xbc
    0012422c 004023d4 USER32!EnumDisplaySettingsA+0x23
    0012fef8 0040698f 885+0x23d4
    0012ff88 760eee1c 885+0x698f
    0012ff94 772437eb kernel32!BaseThreadInitThunk+0xe
    0012ffd4 772437be ntdll!__RtlUserThreadStart+0x70
    0012ffec 00000000 ntdll!_RtlUserThreadStart+0x1b

    This of course triggers driver analysis (in case the sandbox offers it)... 7652 times and the only thing that separates good analysis and total failure is a proper filtering of collected data.

    Second stage of the malware is executed through the callback from EnumResourceTypesA, it decompress and decrypts the final stage, which is heavily obfuscated. Entry point of the final stage suggests that it can be run from within both x86 and x64 processes. It uses simple trick to detect bitness of the process [2] and it contains both x86 and x64 payloads.

    After deobfuscation we were able to identify another simple check to evade analysis, mentioned sample uses GetSystemTime API to verify expiration date, and does not execute after 8th of April 2016. We can easily handle such cases in Joe Sandbox through our Cookbooks system [3], whole operation boils down to adding below line to the Cookbook:

    _SetDate(06, 04, 2016)

    It's always good to re-run the analysis with the different dates to verify if the sample doesn't expire or if it isn't activating in the near future. Usually it's safe to assume the day when the sample was received as the initial date, timestamp from the PE header should work as well (in this case it is GMT Tue Apr 05 22:31:47 2016).

    Last but not least, link to the full Joe Sandbox report (click the picture to open):

     Joe Sandbox Report

    Nymaim proves that it is very important to have a flexible malware analysis system which enables analysts to easily change settings on the analysis machine. Joe Sandbox features an extensive technology called cookbooks. Cookbooks enable to completely define the analysis and allow to change OS settings, simulate user behavior and more. Further Joe Sandbox analyzes malware on physical machines (bare metal) defeating any VM evasions.


    HydraCrypt the badass Ransomware

    2015 was definitely the year of ransomwares and it seems 2016 is no different. Yesterday we came across a new ransomware called HydraCrypt:

    Hydra is no different than other ransomware like Cryptowall or Teslascrpy. However there is one big exception. So far seen ransomware will encrypt your documents (PDF and Office) and pictures. Hydra instead will also encrypt your application settings and database. In detail, Hydra encrypts a huge number of additional files:

     .3dm .3ds .3g2 .3gp .7z .ab4 .accdb .accde .accdr .accdt .ach .act .adb .ads .ai .ait .al .apj .arw .asf .asm .asp .asx .avi .back .bank .bay .bgt .bik .bkf .bk .blend .bpw .c .cdb .cdf .cdr .cdx .ce1 .ce2 .cer .cfp .cgm .class .cls .cmt .cnv .cpi .cpp .cr2 .craw .crt .crw .cs .csh .csl .csv .dac .db .db3 .dbf .dbr .dbs .c2 .dcr .dcs .dcx .ddd .ddoc .dds .der .des .design .dgc .djvu .dng .doc .docm .docx .dot .dotm .dotx .drf .drw .dtd .dwg .dxb .dxf .dxg .ebd .edb .eml .eps .er .exf .fdb .ffd .fff .fh .fhd .fla .flac .flv .fm .fp7 .fpx .fxg .gdb .gray .grey .grw .gry .h .hbk .hpp .ibd .idx .iif .indd .java .jpe .jpeg .jpg .kdbx .kdc .ke .laccdb .lua .m .m4v .maf .mam .maq .mar .maw .max .mdb .mdc .mde .mdf .mdt .mef .mfw .mmw .mos .mov .mp3 .mp4 .mpg .mpp .mrw .mso .myd .ndd .nef .nk2 .nrw .ns2 .s3 .ns4 .nsd .nsf .nsg .nsh .nwb .nx1 .nx2 .nyf .obj .odb .odc . .odf .odg .odm .odp .ods .odt .oil .one .orf .otg .oth .otp .ots .ott .p12 .p7b .p7c .pages .pas .at .pbo .pcd .pct .pdd .pdf .pef .pem .pfx .php .pip .pl .plc .pot .potm .potx .ppam .pps .ppsm .ppsx .ppt .pptm .pptx .prf .ps .psafe3 .psd .pspimage .ptx .pu .puz .py .qba .qbw .r3d .raf .rar .rat .raw .rdb .rm .rtf .rwz .sas7bdat .say .sd0 .sda .sdf .snp .sql .sr2 .srf .srt .srw .st4 .st5 .st6 .st7 .st8 .stc .std .st .stw .stx .svg .swf .sxc .sxd .sxg .sxi .sxm .sxw .tex .tga .thm .txt .vob .vsd .vsx .vtx .wav .wb2 .wdb .wll .wmv .wpd .wps .x11 .x3f .xla .xlam .xlb .xlc .xll .lm .xlr .xls .xlsb .xlsm .xlsx .xlt .xltm .xltx .m4a .wma .d3dbsp .xlw .xpp .xsn .yuv .zip .zip .sie .unrec .scan .sum .t13 .t12 .qdf .tax .pkpass .bc6 .bc7 .sdn .sidd .mddata .itl .itdb .icxs .hvpl .hplg .hkdb .mdbackup .syncdb .gho .cas .map .wmo .itm .sb .fos .mov .vdf .ztmp .sis .sid .ncf .menu .layout .dmp .blb .esm .vcf .vtf .dazip .fpk .mlx .kf .iwd .vpk .tor .psk .rim .w3x .fsh .ntl .arch00 .lvl .snx .cfr .ff .vpp_pc .lrf .m2 .mcmeta .vfs0 .mpqge .kdb .db0 .dba .rfl .hkx .bar .upk .das .iwi .litemod .asset .forge .ltx .bsa .apk .re4 .lbf .slm .epk .rgss3a .pak .big .wallet .wotreplay .xxx .desc .m3u .js .css .rb .png .w2 .rwl .mrwref .3fr .xf .pst .dx .tiff .bd .tar .gz .mkv .bmp .dot .xml .xmlx .dat .html .gif .mcl .ini .mte .cfg .mp3 .qbi .qbr .cnt .v30 .qbo .lgb .qwc .qbp .af .qby .1pa .qpd .set .nd .rtp .qbwin .log .qbbackup .tmp .temp1234 .qbt .qbsdk .syncmanagerlogger .ecml .qsm .qss .qst .fx0 .fx1 .mx0 .fpx .fxr .fim .3DM .3DS .3G2 .3GP .7Z .AB4 .ACCDB .ACCDE .ACCDR .ACCDT .ACH .ACT .ADB .ADS .AI .AIT .AL .APJ .ARW .ASF .ASM .ASP .ASX .AVI .BACK .BANK .BAY .BGT .BIK .BKF .BK .BLEND .BPW .C .CDB .CDF .CDR .CDX .CE1 .CE2 .CER .CFP .CGM .CLASS .CLS .CMT .CNV .CPI .CPP .CR2 .CRAW .CRT .CRW .CS .CSH .CSL .CSV .DAC .DB .DB3 .DBF .DBR .DBS .C2 .DCR .DCS .DCX .DDD .DDOC .DDS .DER .DES .DESIGN .DGC .DJVU .DNG .DOC .DOCM .DOCX .DOT .DOTM .DOTX .DRF .DRW .DTD .DWG .DXB .DXF .DXG .EBD .EDB .EML .EPS .ER .EXF .FDB .FFD .FFF .FH .FHD .FLA .FLAC .FLV .FM .FP7 .FPX .FXG .GDB .GRAY .GREY .GRW .GRY .H .HBK .HPP .IBD .IDX .IIF .INDD .JAVA .JPE .JPEG .JPG .KDBX .KDC .KE .LACCDB .LUA .M .M4V .MAF .MAM .MAQ .MAR .MAW .MAX .MDB .MDC .MDE .MDF .MDT .MEF .MFW .MMW .MOS .MOV .MP3 .MP4 .MPG .MPP .MRW .MSO .MYD .NDD .NEF .NK2 .NRW .NS2 .S3 .NS4 .NSD .NSF .NSG .NSH .NWB .NX1 .NX2 .NYF .OBJ .ODB .ODC . .ODF .ODG .ODM .ODP .ODS .ODT .OIL .ONE .ORF .OTG .OTH .OTP .OTS .OTT .P12 .P7B .P7C .PAGES .PAS .AT .PBO .PCD .PCT .PDD .PDF .PEF .PEM .PFX .PHP .PIP .PL .PLC .POT .POTM .POTX .PPAM .PPS .PPSM .PPSX .PPT .PPTM .PPTX .PRF .PS .PSAFE3 .PSD .PSPIMAGE .PTX .PU .PUZ .PY .QBA .QBW .R3D .RAF .RAR .RAT .RAW .RDB .RM .RTF .RWZ .SAS7BDAT .SAY .SD0 .SDA .SDF .SNP .SQL .SR2 .SRF .SRT .SRW .ST4 .ST5 .ST6 .ST7 .ST8 .STC .STD .ST .STW .STX .SVG .SWF .SXC .SXD .SXG .SXI .SXM .SXW .TEX .TGA .THM .TXT .VOB .VSD .VSX .VTX .WAV .WB2 .WDB .WLL .WMV .WPD .WPS .X11 .X3F .XLA .XLAM .XLB .XLC .XLL .LM .XLR .XLS .XLSB .XLSM .XLSX .XLT .XLTM .XLTX .M4A .WMA .D3DBSP .XLW .XPP .XSN .YUV .ZIP .ZIP .SIE .UNREC .SCAN .SUM .T13 .T12 .QDF .TAX .PKPASS .BC6 .BC7 .SDN .SIDD .MDDATA .ITL .ITDB .ICXS .HVPL .HPLG .HKDB .MDBACKUP .SYNCDB .GHO .CAS .MAP .WMO .ITM .SB .FOS .MOV .VDF .ZTMP .SIS .SID .NCF .MENU .LAYOUT .DMP .BLB .ESM .VCF .VTF .DAZIP .FPK .MLX .KF .IWD .VPK .TOR .PSK .RIM .W3X .FSH .NTL .ARCH00 .LVL .SNX .CFR .FF .VPP_PC .LRF .M2 .MCMETA .VFS0 .MPQGE .KDB .DB0 .DBA .RFL .HKX .BAR .UPK .DAS .IWI .LITEMOD .ASSET .FORGE .LTX .BSA .APK .RE4 .LBF .SLM .EPK .RGSS3A .PAK .BIG .WALLET .WOTREPLAY .XXX .DESC .M3U .JS .CSS .RB .PNG .W2 .RWL .MRWREF .3FR .XF .PST .DX .TIFF .BD .TAR .GZ .MKV .BMP .DOT .XML .XMLX .DAT .HTML .GIF .MCL .INI .MTE .CFG .MP3 .QBI .QBR .CNT .V30 .QBO .LGB .QWC .QBP .AF .QBY .1PA .QPD .SET .ND .RTP .QBWIN .LOG .QBBACKUP .TMP .TEMP1234 .QBT .QBSDK .SYNCMANAGERLOGGER .ECML .QSM .QSS .QST .FX0 .FX1 .MX0 .FPX .FXR .FIM .$$$ .$DB .001 .002 .003 .113 .73B .__A .__B .AB .ABA .ABBU .ABF .ABK .ACP .ACR .ADI .AEA .AFI .ARC .AS4 .ASD .ASHBAK .ASV .ASVX .ATE .ATI .BAC .BACKUP .BACKUPB .BAK2 .BAK3 .BAKX .BAK~ .BBB .BBZ .BCK .BCKP .BCM .BDB .BFF .BIF .BIFX .BK1 .BKC .BKUP .BKZ .BLEND1 .BLEND2 .BM3 .BMK .BPA .BPB .BPM .BPN .BPS .BUP .CAA .CBKCBS .CBU .CK9 .CMF .CRDS .CSD .CSM .DA0 .DASH .DBK .DIM .DIY .DNA .DOV .DPB .DSB .FBC .FBF .FBK .FBU .FBW .FH .FHF .FLKA .FLKB .FPSX .FTMB .FUL .FWBACKUP .FZAFZB .GB1 .GB2 .GBP .GHS .IBK .ICBU .ICF .INPROGRESS .IPD .IV2I .JBK .JDC .KB2 .LCB .LLX .MBF .MBK .MBW .MDINFO .MEM .MIG .MPB .MV_ .NB7 .NBA .NBAK .NBD .NBF .NI .NBK .NBS .NBU .NCO .NDA .NFB .NFC .NPF .NPS .NRBAK .NRS .NWBAK .OBK .OEB .OLD .ONEPKG .ORI .ORIG .OYX .PAQ .PBA .PBB .PBD .PBF .PBJ .PBX5SCRIPT .PBXSCRIPTPDB .PQB .PQB-BACKUP .PRV .PSA .PTB .PVC .PVHD .QBB .QBK .QBM .QBMB .QBMD .QBX .QIC .QSF .QUALSOFTCODE .QUICKEN2015BACKUP .QUICKENBACKUP .QV~ .RBC .RBFRBK .RBS .RDB .RGMB .RMBAK .RRR .SAV .SBB .SBS .SBU .SDC .SIM .SKB .SME .SN1 .SN2 .SNA .SNS .SPF .SPG .SPI .SPS .SQB .SRR .STG .SV$ .SV2I .TBK .TDB .TIBKP .TIG .IS .TLG .TMP .TMR .TRN .TTBK .UCI .V2I .VBK .VBM .VBOX-PREV .VPCBACKUP .VRB .WBB .WBCAT .WBK .WIN .WJF .WPB .WSPAK .XBK .XLK .YRCBCK .~CW .QBI .QBR .CNT .DESv30 .QBO .LGB .QWC .QBP .AIF .QBA .TLG .QBY .1PA .QPD .SET .IIF .ND .RTP .TLG .WAV .Qbwin .log .QBBackup .tmp .Temp1234 .qbt .QBSDK .log .QWC .log .SyncManagrLogger .log .ECML .QSM .QSS .QST .Fx0 .Fx1 .Mx0 .FPx .FXR .FIM .$$$ .$db .001 .002 .003 .113 .73b .__a .__b .ab .aba .abbu .abf .abk .acp .acr .adi .aea .afi .arc .as4 .asd .ashbak .asv .asvx .ate .ati .bac .backup .backupb .bak2 .bak3 .bakx .bak~ .bbb .bbz .bck .bckp .bcm .bdb .bff .bif .bifx .bk1 .bkc .bkup .bkz .blend1 .blend2 .bm3 .bmk .bpa .bpb .bpm .bpn .bps .bup .caa .cbkcbs .cbu .ck9 .cmf .crds .csd .csm .da0 .dash .dbk .dim .diy .dna .dov .dpb .dsb .fbc .fbf .fbk .fbu .fbw .fh .fhf .flka .flkb .fpsx .ftmb .ful .fwbackup .fzafzb .gb1 .gb2 .gbp .ghs .ibk .icbu .icf .inprogress .ipd .iv2i .jbk .jdc .kb2 .lcb .llx .mbf .mbk .mbw .mdinfo .mem .mig .mpb .mv_ .nb7 .nba .nbak .nbd .nbf .ni .nbk .nbs .nbu .nco .nda .nfb .nfc .npf .nps .nrbak .nrs .nwbak .obk .oeb .old .onepkg .ori .orig .oyx .paq .pba .pbb .pbd .pbf .pbj .pbx5script .pbxscriptpdb .pqb .pqb-backup .prv .psa .ptb .pvc .pvhd .qbb .qbk .qbm .qbmb .qbmd .qbx .qic .qsf .qualsoftcode .quicken2015backup .quickenbackup .qv~ .rbc .rbfrbk .rbs .rdb .rgmb .rmbak .rrr .sav .sbb .sbs .sbu .sdc .sim .skb .sme .sn1 .sn2 .sna .sns .spf .spg .spi .sps .sqb .srr .stg .sv$ .sv2i .tbk .tdb .tibkp .tig .is .tlg .tmp .tmr .trn .ttbk .uci .v2i .vbk .vbm .vbox-prev .vpcbackup .vrb .wbb .wbcat .wbk .win .wjf .wpb .wspak .xbk .xlk .yrcbck .~cw

      The list includes e.g. *.db, *.ini or *.dat. So what does that mean? It means that all your application settings are gone. Same for. stored password and login for e.g. Firefox:

      Besides it will also encrypt files in your Recycle Bin and your System Restore folder. This is bad ass and makes your computer nearly useless. Of course it also comes with all the other functionality of traditional ransomware:

      Full Joe Sandbox 13 analysis:

      Update 1:

      Malware Traffic Analysis is a nice analysis of the threat from a network level: kudos,

      Spider charts, Deep OLE, 950+ and more

      Over the last couple of weeks, we have been very busy and have added new features to Joe Sandbox. In this post, we are going to show you our favorites. These features cross the complete space of malware analysis analysis and include new visualizations, analysis and more.

      Generic Classification

      In order to quickly determine the malicious payload we have added a spider chart visualization to the analysis report:

      Joe Sandbox also generates a new classification label:

      All classification figures are available in the Joe Sandbox reports (XML, JSON) as raw formats.  The complete classification algorithm is open and therefore enables customized tuning. Our spider charts help to quickly determine the type of the malware without requiring any in-depth technical understanding of the malware. By clicking on the malware icons you can get a detailed description. Besides the spider chart, we also introduced new pie charts for many analysis data as well as for the famous behavior graphs:

      Example report:

      Deep Static Analysis of OLE files

      The static analysis includes code analysis and deobfuscation for VB macros. Documents with VB macros have become a common way to deliver payload to the end user system. With the new static code analysis deep analysis and detection of such malware is possible. 

      WMI Analysis

      WMI is an extensive interface on Windows to query information about the system. It is also difficult to intercept and analysis. Therefore, it is often used by malware to detect and fingerprint the analysis system. With the latest release of Joe Sandbox all WMI activity is captured.

      Inspection of HTTPS Traffic

      Full HTTPS traffic inspection has been added to Joe Sandbox Cloud. HTTPS analysis is also possible for URL analysis with IE.

      950+ Behavior Signatures 

      We have developed many new behavior signatures. Our complete set has currently over 950 signatures. Many of the new signatures are highly advanced:

      USB Fake Drive

      Want to see if malware infects USB drives? Want to see if malware spreads via network shares? No problem! We have functionality to create a USB fake drive:

      Network shares are simulated with our Adaptive Internet Simulation Technology:

      The features outlined are just a selection. There are various other extensions and improvements which were developed. We have also planned some great new features for 2016! So watch out!

      Happy New Year!

      The Joe Security team wishes you success, satisfaction and many pleasant moments in 2016!