Blog

Archive for March, 2020

Qakbot malspam sent from an infected Windows host, (Wed, Apr 1st)

Introduction

Every once in a while, I’ll see spambot-style traffic from the Windows hosts I infect in my lab environment.  On Tuesday 2020-03-31, this happened during a Qakbot infection.  I’ve covered examining Qakbot traffic before, but that didn’t include examples of spambot emails sent from an infected Windows computer.  Today’s diary provides a quick review of some email examples from spambot traffic by my Qakbot-infected lab host.

The traffic

A pcap of the traffic used for today’s diary can be found here.  It’s a short snippet of the malspam traffic sent from my Qakbot-infected lab host.  Use the Wireshark filter smtp.data.fragment as shown below to confirm there are emails we can export from the pcap.


Shown above:  Filtering on the pcap to see if any emails can be exported from the spambot traffic.

Once we’ve confirmed there are emails we can export from the pcap, use the menu path File –> Export Object –> IMF… to export these emails as shown below.


Shown above:  Exporting IMF (Internet Mail Format) objects from the pcap.

The exported emails

A quick review of the emails indicates the information was taken from an infected user’s mailbox.  However, the recipients appear to be spoofed or malicious email addresses from old malspam circa 2013.  See the images below for details.


Shown above:  The recipient of this malspam appears to be a sender from an old fake Vodafone message.


Shown above:  The recipient of this malspam appears to be from an old Viagra-themed spam message.


Shown above:  The recipient of this malspam appears to be from an old fake Royal Mail message.


Shown above:  The recipient of this malspam appears to be from an old mailbox-themed phishing message from 2013.


Shown above:  The recipient of this malspam appears to be from an old DHL phishing message from 2013.


Shown above:  The recipient of this malspam appears to be from an old malicious email impersonating someone from Baidu Antivirus.


Shown above:  The recipient of this malspam appears to be from an old fake Amazon email from 2013.

Final words

Reviewing these emails, you should notice patterns in how they are structured and the URLs used to deliver the initial malware, a zip archive downloaded from the web.  The URLs I found from this Qakbot-related spambot traffic have all been submitted to URLhaus.

A pcap covering this snippet of Qakbot-related spambot traffic and the extracted 11 emails can be found here.

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

 

(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) →

Kwampirs Targeted Attacks Involving Healthcare Sector, (Tue, Mar 31st)

There is no honor among thieves. Even after some ransomware gangs claimed to seize targeting the healthcare sector, attacks continue to happen. But ransomware isn’t alone. Last week, the FBI updated an advisory regarding the Kwampirs malware, pointing out the healthcare sector as one of its targets. Kwampirs isn’t picky in its targeting. It has been observed going after various sectors (financial, energy, software supply chain, and healthcare, among others). One differentiator of Kwampirs is its modular structure. After penetrating a particular target network, the malware will load appropriate modules based on the targets it encounters. In general terms, Kwampirs is a “Remote Admin Tool” (RAT). It provides access to the target and can be used to execute additional payloads at the attacker’s choosing.

The modular nature makes it difficult to enumerate the capabilities of the tool. Likely, addons are developed continuously as new capabilities are required to penetrate a particular network.

Kwampirs exhibits several behaviors that put it in the “Advanced Persistent Threat (APT)” category:

  • It is patient. Kwampirs does not launch fast “hit and run” attacks. Instead, it can infiltrate a network and only communicate daily, asking for updates. I took some networks three years to detect Kwampirs.
  • Kwampirs infiltrates software vendors and uses them to spread to customers. These supply chain attacks are well suited to target specific industries.
  • It does not have a clear financial motive, like stealing PII or payment card data. The malware has not been observed destroying or encrypting data for ransom.

Kwampirs will likely enter your network undetected as part of a software update from a trusted vendor. Anti-malware solutions will detect past versions. But do not put too much trust in anti-malware to detect the next version that is likely tailored to your organization.

There are a few indicators that have been observed in the past, and it is certainly important to verify your network that you are not already infected. See the prior FBI bulletins for more details and Yara signatures.

But of course, this behavior is going to change. For future versions of this (and other threats), it is useful to abstract these signatures:

Check for new services popping up in your network. Do not look just for specific names like “WmiApSrvEx”, but investigate any service that you haven’t see before
New processes. This is tricky and maybe too noisy.
New files being added to system folders. Again, don’t focus on the specific names.
Kwampirs will also propagate through administrative shares. Deception techniques are an excellent option to catch this type of behavior.

Of course, I always like network detection techniques to identify malicious behavior. For Kwampirs, this may be a bit tricky, but it depends on what exact version you encounter. Some versions apparently will connect to an IP address directly, skipping DNS. Outbound connections without a DNS lookup returning the target IP should be one of your standard signatures. In the past, Kwampirs used some odd domain names that may stick out. For example, it used the “tk” top-level domain, which has sadly become almost an indicator of compromise in itself. Declaring yourself authoritative for .tk and redirecting queries to a sensor is an excellent way of detecting these and many other exploits. I probably wouldn’t spend too much time looking for the specific hostnames listed in the FBI advisory. These hostnames tend to be very ephemeral, and they are not going to “last” very long. But a historical search of your DNS logs (did I mention Zeek?) may be appropriate.

If you find anything interesting, please let us know. Refer to the FBI advisories I uploaded here for more detailed IOCs. 

[1] https://isc.sans.edu/diaryimages/Kwampirs_PIN_20200330-001.pdf
[2]  https://isc.sans.edu/diaryimages/FLASH-CP-000111-MW_downgraded_version.pdf
[3] https://isc.sans.edu/diaryimages/FLASH-CP-000118-MW_downgraded_version.pdf


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) →

Crashing explorer.exe with(out) a click, (Mon, Mar 30th)

In a couple of my recent diaries, we discussed two small unpatched vulnerabilities/weaknesses in Windows. One, which allowed us to brute-force contents of folders without any permissions[1], and another, which enabled us to change names of files and folders without actually renaming them[2]. Today, we’ll add another vulnerability/weakness to the collection – this one will allow us to cause a temporary DoS condition for the Explorer process (i.e. we will crash it) and/or for other processes. It is interesting since all that is required for it to work is that a user opens a link or visits a folder with a specially crafted file.

The vulnerability lies in the way in which URL links (.URL files) and Shell Links (.LNK files) are handled by Windows when they are self-referential (i.e. they “link to themselves”). The principle behind the vulnerability is not new – a similar issue was supposedly present in the early versions of Windows 7 with self-referential symlinks – but since I didn’t find any write-up for the issue with URLs and LNKs, I thought I’d share this version of the vulnerability here. I should mention that I informed Microsoft of the issue and they decided not to patch it due to its limited impact.

With URL links, crafting a self-referential one is quite simple. URL shortcuts are basically just INI files and you may create one in the same way you would create a LNK shortcut (i.e. right click in a folder -> New -> Shortcut), you just have to input URL as the target. If we were to create a shortcut this way, which points to https://isc.sans.edu/, we would end up with following contents inside the resulting URL file.

The structure is quite simple, but we may simplify it further still, since for our purposes, we only need to specify the [InternetShortcut] section and a target for the link. A file with the following contents will work the same way as the previous one.

In order to create a self-referential URL file, we simply need to point the URL property to the path where our file is located.

If we try to open this file, the Explorer process will crash and after a while, it will be started again.

This is intriguing behavior and since the mechanism works for remote file shares as well (and since we may change the icon which is displayed for the URL file), a specially crafted URL link might be used quite easily to pull a prank on someone. Besides it being a potential tool for use during the April Fools’ day, however, there don’t seem to be many uses for a self-referential URL.

Self-referential Shell Links, on the other hand, could be quite handy in certain red teaming situations. This is because in case of LNK files, one doesn’t need to interact with them directly in any way in order to cause Explorer to crash, it is enough to open the folder in which they are located.

This is due to the interesting way in which Windows handles Shell Links. To demonstrate the behavior of Windows when a user opens a folder in which a LNK file is located, I created a shortcut, which points to calc.exe, and placed in in the folder C:PoC. As you may see from the output from Process Monitor bellow, which shows what happened when I opened the PoC folder, the Explorer process automatically found the target file (C:system32.calc.exe) and accessed it.

Although this behavior is quite interesting by itself, the fact that Explorer tries to access target of a LNK file when a folder, inside which it is placed, is opened is sufficient for our purposes.

At this point, we may try to create a self-referential LNK. However, if we simply try to point existing Shell Link file back on itself (or point it to any other LNK), Windows will stop us, because creating a shortcut to another shortcut is not allowed.

Since Shell Links have a binary format, making them point to themselves “manually” isn’t as straightforward as in the case of URL files. With a hex editor and with a little help from the official documentation[3], it still isn’t too difficult though.

The only potential snag is that Shell Link files really aren’t meant to point to other LNKs and to enable this behavior, we need to set a special flag in the header of the Shell Link called “AllowLinkToLink“ (i.e. add 0x80 to byte at offset 0x16)[4].

If we try to access a folder, inside which the LNK is placed, Explorer will indeed crash and then start up again.

If you’d like to try this out on your own system, I prepared a sample Shell Link file to make it easier. You may download it from https://untrustednetwork.net/files/ISC/2020/infinilink.zip (password is “infected”) and unzip the “infinilink” directory to your C drive. It works from certain other locations as well, but I would caution against putting the downloaded LNK directly on a Desktop.

Although it should be harmless (besides causing the Explorer process to crash, that is), I would also recommend that you only try it in a backed up virtual environment.

For completeness sake, I should mention that explorer.exe isn’t the only process we may crash this way. Any application, which uses one of the standard Windows file dialogs (i.e. Open File dialog, Save File dialog, etc.) is susceptible and will crash if the dialog window is used to open a folder containing a self-referential LNK.

[1] https://isc.sans.edu/diary/25816
[2] https://isc.sans.edu/diary/25912
[3] https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-shllink/16cb4ca1-9339-4d0c-a68d-bf1d6cc0f943
[4] https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-shllink/ae350202-3ba9-4790-9e9e-98935f4ee5af

———–
Jan Kopriva
@jk0pr
Alef Nula

(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) →

Obfuscated Excel 4 Macros, (Sun, Mar 29th)

2 readers (anonymous and Robert) submitted very similar malicious spreadsheets with almost no detections on VT: c1394e8743f0d8e59a4c7123e6cd5298 and a03ae50077bf6fad3b562241444481c1.

These files contain Excel 4 macros (checking with oledump.py here):

There are a lot of cells in this spreadsheet with a call to the CHAR function:

These CHAR formulas evaluate to ASCII characters, that are then concatenated together and evaluated as formulas:

I can extract the integer argument of each CHAR function like this with my tool re-search.py:

That can then be converted to characters using my tool numbers-to-string.py:

The string above is build-up of all the cells with function CHAR in the spreadsheet. That’s why the produced string looks promising, but the characters don’t seem to be in the right order.

Selecting characters on the same row doesn’t help:

But selecting by column does reveal the formulas:

Analyzing obfuscated Excel 4 macros with a command-line tool like this can be difficult, and it can be easier to view the Excel 4 macro sheet inside a VM (this sheet was very hidden):

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.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

Covid19 Domain Classifier, (Sat, Mar 28th)

Johannes started a Covid19 Domain Classifier here on our Internet Storm Center site.

From SANS NewsBites Vol. 22 Num. 025:

Help Us Classify COVID-19 Related Domains

These last couple of weeks, criminals have been using COVID-19 for everything from selling fake cures to phishing. Every day, several thousand domains are registered for COVID-19 related keywords. We are trying to identify the worst, and classify the domains into different risk categories. If you have some time this weekend, please help us out by checking out some of these domains. To participate, see https://isc.sans.edu/covidclassifier.html. The domain data is based on a feed provided by Domaintools and we will make the results of this effort public for download as soon as we have a “critical mass” of responses.

When you log in with your account to the SANS ISC site, you’ll get a list of 10 domains to classify, like this:

 

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.

Reposted from SANS. View original.

Posted in: SANS

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