Analysing a malicious Word document like prod.docx that exploits %%cve:2021-40444%% is not difficult.

We need to find the malicious URL in this document. As I've shown before, this is quite simple: extract all XML files from the ZIP container (.docx files are OOXML files, that's a ZIP container with (mostly) XML files) and use a regular expression to search for URLs.

This can be done with my tools zipdump.py and re-search.py:

OOXML files contain a lot of legitimate URLs. Like schemas.microsoft.com. These can be filtered out with my tool re-search.py:

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com

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

Did this threat really disappear? This isn’t a brand new technique to deliver malicious content to mobile devices but it seems that attackers started new waves of spam campaigns based on malicious calendar subscriptions. Being a dad, you can imagine that I always performed security awareness with my daughters. Since they use computers and the Internet, my message was always the same: “Don’t be afraid to ask me, there are no stupid questions or shame if you think you did something wrong”.

A few days ago, my youngest one came to me and told me she had the impression that her iPhone was hacked. After a quick check and reassuring her, I switched my dad's cap to the handler one and had a deeper look.

She told me that a pop-up was displayed on the screen and clicked on “Ok” too quickly. It was an unwanted calendar invitation and she subscribed to a spam feed. Her calendar became quickly flooded with events:

They are in French but easy to understand. They pretend to notify you about viruses found on the device and, using reminders, they keep the pressure on the victim:

If you visit the proposed link, you'll get more annoying ads pages, etc. This time hopefully, nothing very malicious but, seeing the latest iOS vulnerabilities[1], this technique could be used to deliver exploits. To get rid of all those messages, you just need to unsubscribe from the calendar.

In conclusion, already read carefully all popups displayed on your mobile phones (obviously on any type of device!).

[1] https://support.apple.com/en-us/HT212807

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.

There are many e-mail subjects that people tend to associate with phishing due to their overuse in this area. Among the more traditional and common phishing subjects, that most people have probably seen at some point, are variations on the “Your account was hacked”, “Your mailbox is full”, “You have a postal package waiting”, “Here are urgent payment instructions” and “Important COVID-19 information” themes.

Since security awareness courses often explicitly cover these, and e-mail messages with similar subjects are therefore usually classified by users as prima facie phishing attempts, one would reasonably expect that when a threat actor decides to use any such subject line, they would at least try to make the body of the e-mail a little more believable… However, as it turns out, this is not always the case.

We’ve recently received a phishing on our Handler e-mail address, which I found interesting, since its authors obviously decided to go the “all in” route when came to the use of multiple obviously suspicious message subjects, rather than try to make their creation more believable.

“But how could a single phishing e-mail have multiple subjects”, I hear you ask, dear reader.

Well, in this case, the phishing was a variation on the “You have undelivered e-mail messages waiting” theme, but instead of a list of urgent looking, yet believable subject lines, it contained pretty much the whole aforementioned set of suspicious-at-first-glance subjects, as you may see for yourself in the following image…

Apart from this rather interesting (and slightly funny) approach on the side of its authors, the e-mail was rather a low-quality example of a phishing, its less than professional origins showing – among other places – in the fact that multiple links pointed to URLs that were obviously intended for previous recipients/recipients from other domains.

The only link that did lead to a phishing page pointed to an HTML document hosted on the Google Firebase Storage that, when accessed, displayed a dynamically generated login prompt and tried to load a web page hosted on the domain to which the e-mail address belonged to in an iframe bellow this prompt in an attempt to make the login request look more believable (a technique that is fairly common[1], which provides another good reason why it’s advisable to use CSP/X-Frame-Options headers on ones webservers).

IoC
hxxps://firebasestorage[.]googleapis[.]com/v0/b/g656-6f582.appspot.com/o/hghhg.html?alt=media&token=3a94d041-9a90-4428-85ca-41779f9605a1#address@domain.tld

[1] https://isc.sans.edu/forums/diary/Slightly+broken+overlay+phishing/26586/

———–
Jan Kopriva
@jk0pr
Alef Nula

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

Introduction

Malicious spam (malspam) pushing Hancitor malware (AKA: Chanitor, MAN1, Moskalvzapoe, or TA551) sometimes changes tactics when delivering malware .  Since June 2021, this campaign stopped using docs.google.com links in their malspam and began using feedproxy.google.com to kick off an infection chain.  Criminals behind Hancitor have been abusing Google services since October 2020.

These Google links redirect to a URL from another domain.  This new "redirect URL" delivers a Hancitor Word document.  These "redirect URLs" return a web page with script using base64 text to generate a Hancitor Word document as described here.  The base64 text is converted to a malicious Word document and shows up in the web browser as a file to save.

But in September of 2021, this campaign stopped using script with base64 text.  Instead, Hancitor Word docs are now hosted on Microsoft OneDrive URLs.  The Hancitor campaign is currently abusing both Google and Microsoft services.

Shown above:  Change in tactics for Hancitor malware distribution seen in September 2021.

Previous method: script with base64 text

See below for images of traffic from a "redirect URL" that returned script with base64 text to generate a Hancitor Word document.

Shown above:  Script with base64 text used to generate Hancitor Word doc (part 1 of 2).

Shown above:  Script with base64 text used to generate Hancitor Word doc (part 2 of 2).

New method: OneDrive URLs

Instead of script using base64 text to generate a Hancitor Word doc, these "redirect URLs" now present script with OneDrive URLs to deliver a Word doc.  See the images below from Tuesday 2021-09-14.

Shown above:  Script from "redirect URLs" now have OneDrive links.

Shown above:  Manually using the OneDrive URL to download a Hancitor Word doc.

Final words

A packet capture of the infection traffic, 18 email examples, some malware samples, and a list of IOCs from a Hancitor infection on Tuesday 2021-09-14 are available here.  Another Hancitor run has also occurred today on Wednesday 2021-09-15.

We continue to see criminals abusing services offered by companies like Google, Microsoft, and other big names.  While the malicious links can be quickly reported and taken off-line, criminals merely return to establish new URLs using the same services.

This is a cycle we see over and over again.  As long as it remains cost-effective for criminals to operate this way, they will continue to abuse these services.

Hancitor is just one of many campaigns that routinely engage in such abuse.

—

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.

This month we got patches for <> vulnerabilities. Of these, <> are critical, <> were previously disclosed and <> is being exploited according to Microsoft.

As expected, Microsoft released the patch for the zero-day affecting MSHTML that could allow an attacker to execute remote code on an affected system. According to the advisory, an attacker could craft a malicious ActiveX control to be used by a Microsoft Office document that hosts the browser rendering engine. The attacker would then have to convince the user to open the malicious document. The CVSS for this vulnerability is 8.80 (out of 10).

See my dashboard for a more detailed breakout: https://patchtuesdaydashboard.com/

September Early Security Releases

—
Renato Marinho
Morphus Labs| LinkedIn|Twitter

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

This parser takes the logs from a Windows 2012R2 and/or 2019 server (C:DNSLogswindns.log) and parses them into usable metatada which can be monitored and queried via an ELK dashboard. The logs have been mapped using DNS ECS field meta here [1].

→ First step is to load the Microsoft DNS templates [3][4] via Kibana Dev Tools to create the microsoft.dns Index Management and Index Lifecycle Policy. Follow the instructions at the top of each template.

→ Second step is to install Logstash (if not already done) and add to Logstash [2] this configuration file (i.e. /etc/logstash/conf.d/logstash-filter-ms-dns.conf) and start the logstash service.

This configuration file also contains the option of resolving the IP addresses to hostname and should be adjusted to reflect the local internal network. Edit logstash-filter-ms-dns.conf and change 192.168.25 to reflect the local network:

# This filter drop internal domain and internal IP range with in-addr.arpa
# This reduce the amount of noise
filter {
  if [log][file][path] =~ "windns.log" {
    if [dns.question.name] =~ /168.192.in-addr.arpa/ {
      drop {}
    }
    if [dns.question.name] =~ /erin.ca/ {
      drop {}
    }
  }
}

# DNS lookup for dns.resolved_ip that start with 192.168.25

filter {
  if [log][file][path] =~ "windns.log" and [dns.resolved_ip] =~ /192.168.25/ {
    mutate {
      copy => { "dns.resolved_ip" => "source.registered_domain" }
      convert   => { "geoip.postal_code" => "string" }
      # copy dns.question.name to related.host
      copy => { "dns.question.name" => "related.hosts" }
    }
    dns {
      reverse => [ "source.registered_domain" ]
      action => "replace"
    }
  }
}

→ Third step, Login Windows server and setup file-based DNS debug logging

Windows DNS Debug Logging is used to collect the logs. Queries are logged one per line. Enable DNS debug logging using these steps:

• Create directory: C:DNSLogs
• Open the DNS Management console (dnsmgmt.msc).
• Right-click on the DNS Server name and choose Properties from the context menu.
• Under the Debug Logging tab, enable Log packets for debugging and configure as per picture below.
• File path and name: C:DNSLogswindns.log
• Maximum size (bytes): 5000000
• Apply the changes
• Verify the file C:DNSLogswindns.log is now receiving data

→ Forth step is to install filebeat on the Windows server (C:Program Filesfilebeat), configured as a service and change the filebeat.yml configuration to only contain the following information. Change the IP address in this file to the IP address (192.168.25.23) of the logstash service and install the filebeat service:

# This filebeat shipper is used for
# Microsoft DNS logs

# 9 Jan 2021
# Version: 1.0

filebeat.inputs:

# Filebeat input for Windows DNS logs

– type: log
  paths:
    – "C:/DNSLogs/windns.log"
  include_lines: ["^[0-9]{4}-"]
  fields_under_root: true

#==================== Queued Event ====================
#queue.mem:
#  events: 4096
#  flush.min_events: 512
#  flush.timeout: 5s

#queue.disk:
#  path: "/op/filebeat/diskqueue"
#  max_size: 10GB

#==================== Output Event ====================
output.logstash:
  hosts: ["192.168.25.23:5044"]

At this point, the logs should start going to ELK. From the Windows server, verify the connection has been established to logstash by running at the command line: netstat -an | findstr 5044

In the Elasticsearch server, under Stack Management → Index Management, look for an new instance with microsoft.dns-* (something like this: microsoft.dns-2021.09.10-000001) which should start collecting Microsoft DNS metadata.

→ Last step is to load the dashboard [5] to Elasticsearch under Stack Management → Saved Objects and Import the file Microsoft_DNS_7.14_v1.ndjson, this will load the new dashboard and the Index Pattern.

Look under the Dashboard tab for Microsoft DNS Server [Microsoft DNS Tag]. This is a sample of the top part of the dashboard:

[1] https://www.elastic.co/guide/en/ecs/current/ecs-dns.html
[2] https://handlers.sans.edu/gbruneau/elk/logstash-filter-ms-dns.conf
[3] https://handlers.sans.edu/gbruneau/elk/Windows_DNS_ilm_policy.txt
[4] https://handlers.sans.edu/gbruneau/elk/Windows_DNS_template.txt
[5] https://handlers.sans.edu/gbruneau/elk/Microsoft_DNS_7.14_v1.ndjson
[6] https://isc.sans.edu/forums/diary/Secure+Communication+using+TLS+in+Elasticsearch/26902/
[7] https://www.elastic.co/guide/en/ecs/master/ecs-field-reference.html
[8] https://handlers.sans.edu/gbruneau/elastic.htm

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

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