Suspending Suspicious Domain Feed / Update to Researcher IP Feed

Published: 2020-06-04
Last Updated: 2020-06-04 11:57:07 UTC
by Johannes Ullrich (Version: 1)
2 comment(s)

Yesterday, Peter from DNSFilter send us a message noting that many of the domains in our "Suspicious Domain" feed no longer resolved, and some of the feeds we used as input were no longer maintained. After investigating, I have to agree with him. The remaining feeds don't make a valuable service at this point. The idea of the "Suspicious Domain" list was to aggregate different lists, but with essentially only 1 or 2 lists left, that doesn't make sense and I decided to no longer maintain the feed until we find new inputs. The respective files will still be offered by they are empty to not break any existing scripts that use them (they are quite popular).

Recently, I also talked about our API feature to retrieve IP addresses used by researchers scanning the Internet. I yesterday added about 150 IPs used by security.ipip.net. See https://isc.sans.edu/api/threatcategory/research

Please keep the feedback coming. I am always interested in improving the quality of our data.

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

Keywords:
2 comment(s)

Anti-Debugging Technique based on Memory Protection

Published: 2020-06-04
Last Updated: 2020-06-04 07:27:00 UTC
by Xavier Mertens (Version: 1)
0 comment(s)

Many modern malware samples implement defensive techniques. First of all, we have to distinguish sandbox-evasion and anti-debugging techniques. Today, sandboxes are an easy and quick way to categorize samples based on their behavior. Malware developers have plenty of tests to perform to detect the environment running their code. There are plenty of them, some examples: testing the disk size, the desktop icons, the uptime, processes, network interfaces MAC addresses, hostnames, etc.

On the opposite, anti-debugging techniques are implemented to make the life of malware analysts more difficult. That's the next step in the "malware analysis pyramid", executing the malicious code into a debugger. Here again, they are many techniques available from very easy ones provided by the Microsoft API like isDebuggerPresent()[1] which returns 1 or 0 depending on the process being attached to a debugger. Note that this API call just checks the flag 'isDebugged" located in the second byte of the PEB[2] or "Process Environment Block".

Another technique is to search for interesting programs via their window title and the API call FindWindow()[3]. Easy to spot a running "x32dbg". Usually, when a program is being debugged, its execution is very slow. Thanks to GetTickCount()[4], it is possible to detect a long time between two system calls.

Some techniques are less usual but used from time to time. I found one yesterday via my sandbox:

The Windows kernel allows allocating memory in different ways depending on the future usage. When the malware will perform process injection, the memory must be allocated with the flag PAGE_EXECUTE_READWRITE (0x40). It's the case in the sample (see above).

There exist many flags for memory allocation[5], one that is interesting is PAGE_GUARD (0x100). Here is the description from the Microsoft documentation:

"Pages in the region become guard pages. Any attempt to access a guard page causes the system to raise a STATUS_GUARD_PAGE_VIOLATION exception and turn off the guard page status. Guard pages thus act as a one-time access alarm."

From a malware perspective, this is very interesting! Guard pages can be used by packers to unpack memory pages "on-demand": they are allocated and protected by PAGE_GUARD then accessed. The generated exception is intercepted and, if it matches the memory page, the content is processed. But, more interesting, the technique of guard pages detection can help to detect the presence of a debugger with the creation of PAGE_GUARD memory page and accessing it. If the exception STATUS_GUARD_PAGE_VIOLATION occurs, it’s assumed no debugging is in place.

Here is an example of protected memory allocation from the sample:


If you are interested in this sample, its SHA256 is 4251133ebe04bf0de34a7a1972342c77442942a4c2417f28c56145b2ee9ad451[6]. It has a VT score of 17/73.

[1] https://docs.microsoft.com/en-us/windows/win32/api/debugapi/nf-debugapi-isdebuggerpresent
[2] https://docs.microsoft.com/en-us/windows/win32/api/winternl/ns-winternl-peb
[3] https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-findwindowa
[4] https://docs.microsoft.com/en-us/windows/win32/api/sysinfoapi/nf-sysinfoapi-gettickcount
[5] https://docs.microsoft.com/en-us/windows/win32/memory/memory-protection-constants
[6] https://www.virustotal.com/gui/file/4251133ebe04bf0de34a7a1972342c77442942a4c2417f28c56145b2ee9ad451/behavior/Dr.Web%20vxCube

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

0 comment(s)
ISC Stormcast For Thursday, June 4th 2020 https://isc.sans.edu/podcastdetail.html?id=7024

Polish malspam pushes ZLoader malware

Published: 2020-06-04
Last Updated: 2020-06-03 00:10:53 UTC
by Brad Duncan (Version: 1)
3 comment(s)

Introduction

Today's diary reviews Polish malicious spam (malspam) from Tuesday 2020-06-02 pushing ZLoader malware.  Also knowna s Terdot or DELoader, ZLoader is the latest variant from this family of malware that's been active for years.


Shown above:  Flow chart for this infection chain.

I was tipped off to this activity by the following posts on Twitter:

The malspam

Unfortunately, I was not able to get a copy of the emails to show what they look like.  However, the subject line I found was:

  • Subject: e-faktura  06.2020

The attachments

The attachments from this malspam have a template that uses Polish and English language encouraging recipients to enable macros.


Shown above:  Screenshot of an attachment from this malspam.

Infection traffic

Infection traffic caused by this example was all HTTPS.  I used the Any.Run sandbox with MITM for analysis on the spreadsheet to get a decryption key for the HTTPS traffic, and I was able to view the URLs and responses behind the encryption.


Shown above:  HTTPS traffic from the infection filtered in Wireshark with a decryption key.


Shown above:  HTTPS request and response for the ZLoader DLL.


Shown above:  HTTPS request and response for ZLoader command and control (C2) traffic.

Forensics on an infected Windows host

When enabling macros on the malicious Excel spreadsheet, the victim host retrieved the ZLoader DLL as shown in the previous section, saved the DLL to the victim's Documents folder, and ran it using rundll32.exe.


Shown above:  Infected host running the ZLoader DLL after enabling macros.

Shortly after the DLL is run, it's moved to a newly-created folder under the infected user's AppData\Roaming directory, where it's made persistent through a Windows registry update.  Several other decoy folders are created under the AppData\Roaming folder during the infection.  If the infection runs long enough, some decoy files are placed in these decoy folders.


Shown above:  The Windows registry update to keep ZLoader persistent.


Shown above:  ZLoader and decoy folders under the infected user's AppData\Roaming directory.

Indicators of Compromise (IoCs)

Date and subject of the emails:

  • Date: Tuesday, 2020-06-02
  • Subject: e-faktura  06.2020

Infection traffic:

  • 84.38.183[.]227 port 443 (HTTPS) - tlanddissipate[.]at - GET /3/rbs.dll
  • 84.38.183[.]227 port 443 (HTTPS) - militanttra[.]at - POST /owg.php

Certificate issuer data for HTTPS traffic on 84.38.183[.]227:

  • id-at-countryName=AU
  • id-at-stateOrProvinceName=Some State
  • id-at-localityName=City
  • id-at-organizationName=Some Country

Associated malware:

SHA256 hash: c0848753a51472209624f631955a9ad9ff39d5b9fc9686c6f0da0530239916e8

  • File size: 138,240 bytes
  • File name: faktura_296.xls
  • File description: Excel spreadsheet with macro for Zloader

SHA256 hash: 8e0238b207985132e60e6f5bc764a6756bce554f9c27b922f1d7e40950a3bbdc

  • File size: 662,528 bytes
  • File location: hxxps://tlanddissipate[.]at/3/rbs.dll
  • File location: C:\Users\[username]\Documents\lLlwqJs.dll
  • File location: C:\Users\[username]\AppData\Roaming\Ivrawa\rogyx.dll
  • Run method: rundll32.exe [filename],DllRegisterServer
  • File note: This DLL is different each time it's retreived from tlanddissipate[.]at

SHA256 hash: 26625bd8081701ab5a248b4f6e726cd5ef07b43c817e5499b766f89980532952
SHA256 hash: 79c2eadd88f3fb91479d982e6b36d5dc7c2d465ff9580a434241f7b353c33289
SHA256 hash: ad658b2da165f31ac7649cf909c5b3330f2e3efde15f0196edc0f90f462965ea
SHA256 hash: f9f231d7b4e601b8703218d6f72fb167472060ce3e42a351743c613e6447c3cc

  • File size: 662,528 bytes
  • File location: hxxps://tlanddissipate[.]at/3/rbs.dll
  • File description: More examples Zloader DLLs retrieved from tlanddissipate[.]at
  • Run method: rundll32.exe [filename],DllRegisterServer

Final words

As always, these types of infections target out-of-date systems.  They're not very effective against fully-patched and up-to-date computers running the latest version of Microsoft Windows.  The default virus & threat protection settings should stop these samples of ZLoader from infecting a Windows 10 host.  Real-time protection and Tamper Protection are designed to prevent such activity.

However, malware authors constantly adjust their malware in an attempt to escape detection.  With the low cost of distribution through email, and with poor security practices among potential victims, campaigns pushing ZLoader and other malware will remain cost-effective.  I expect we will continue to see ZLoader in the coming weeks and months.

---

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

Keywords:
3 comment(s)

Comments


Diary Archives