Black Cat Security

Google Workspace Updates Weekly Recap – December 30, 2022

New updates 

There are no new updates to share this week. Please see below for a recap of published announcements. 

Previous announcements

The announcements below were published on the Workspace Updates blog earlier this week. Please refer to the original blog posts for complete details.

Get enhanced spam protection through automatic labeling of suspected spam calls in Google Voice
To help protect you from unwanted calls and potentially harmful scams, Google Voice will now show a “suspected spam caller” label on all calls that Google believes to be spam. | Available to all Google Voice customers | Learn more

Completed rollouts


The features below completed their rollouts to Rapid Release domainsScheduled Release domains, or both. Please refer to the original blog post for additional details.


Scheduled Release Domains:

Rapid and Scheduled Release Domains:

For a recap of announcements in the past six months, check out What’s new in Google Workspace (recent releases).


Security Update Guide Improvement – Representing Hotpatch Updates

Today we are updating the way Microsoft Security Update Guide (SUG) represents the Windows Hotpatch feature to make it easier for users to identify the hotpatch and security updates. Hotpatching was introduced a year ago as a new way to install updates on supported Windows Server Azure Edition virtual machines (VMs) without requiring a reboot …

Security Update Guide Improvement – Representing Hotpatch Updates Read More »

Get enhanced spam protection through automatic labeling of suspected spam calls in Google Voice

What’s changing 

To help protect you from unwanted calls and potentially harmful scams, Google Voice shows a “suspected spam caller” label on all calls that Google believes to be spam. Google makes this determination using the same advanced artificial intelligence that identifies billions of spam calls each month across Google’s calling ecosystem. 
The new labels appear on the incoming call screen and in the user’s call history. Users can either: 
  • Confirm a suspected spam call, which causes future calls from that number to go directly to voicemail and call history entries to be put in the spam folder 
  • Mark a labeled call as not spam, after which the suspected spam label is never displayed for that number again 
Get an alert that an incoming call is suspected spam

Getting started 

  • Admins: There is no admin control for this feature. 
  • End users: Suspected spam labeling appears automatically when the Voice spam filter setting (Settings > Security > Filter spam) is OFF. When spam filtering is ON, all calls that Google identifies as spam are automatically sent to voicemail, and the call entry is put into the spam folder. Visit the Help Center to learn more about blocking calls and messages or marking them as spam

Rollout pace 

Availability 

  • Available to all Google Voice customers

Resources 

Security Update Guide Improvement – Representing Hotpatch Updates

Today we are updating the way Microsoft Security Update Guide (SUG) represents the Windows Hotpatch feature to make it easier for users to identify the hotpatch and security updates. Hotpatching was introduced a year ago as a new way to install updates on supported Windows Server Azure Edition virtual machines (VMs) without requiring a reboot after installation.

Detecting Apache Text4Shell (CVE-2022-42889) with Wazuh

A vulnerability in the Apache Commons Text library called Text4Shell was discovered in October 2022. This vulnerability exists in versions 1.5 through 1.9 of the popular Java library. It allows remote code execution and other malicious actions through the exploitation of the StringSubstitutor API. The vulnerability is identified as CVE-2022-42889 and has a CVSSv3 score of 9.8 out of 10. 

The Apache Commons Text library includes a mechanism for interpolating variables, allowing users to replace certain bits of text with another according to a template. The default template for this library is ${prefix:[options]:data}, where the prefix defines the algorithm for processing data from options.

In this blog post, we use Wazuh to detect vulnerable versions of Apache Commons Text Library and monitor the endpoints for attempts to exploit this vulnerability.

Exploitation conditions for Text4Shell

The following conditions must be met for Text4Shell to be exploitable:

  • Apache Commons Text version 1.5 through 1.9 installed on the victim endpoint.
  • The application using the vulnerable library must use org.apache.commons.text.StringSubstitutor and one of the following prefixes with the default configuration (dns, script, url). 
  • The application must accept and process untrusted data input.

Exploitation examples

If an attacker has the ability to modify a template, he can carry out the following types of attacks:

Attack Prefix Examples
Remote code execution script ${script:javascript:java.lang.Runtime.getRuntime().exec(‘touch /tmp/foo’)}
${script:JEXL:”.getClass().forName(‘java.lang.Runtime’).getRuntime().exec(‘touch /tmp/pwned’)}
Sending information through DNS queries to malicious domains. dns ${dns:address|commons.apache.org}
Disclosure of internal network information via HTTP (HTTPS) requests url ${url:UTF-8:https://nvd.nist.gov/vuln/detail/CVE-2022-42889}

Detection with Wazuh

Requirements

1. A pre-built ready-to-use Wazuh OVA 4.3.10 Follow this guide to download the virtual machine.

2. An Ubuntu 22.04 endpoint with a Wazuh agent installed and enrolled to the Wazuh server. A Wazuh agent can be installed by following the Deploying Wazuh agents guide.

Ubuntu 22.04 endpoint

In order to test the Text4shell vulnerability, we used the vulnerable application in this Proof of Concept.

1. Install OpenJDK and Maven:

$ sudo apt update && sudo apt install openjdk-11-jdk
$ cd /tmp
$ sudo wget https://mirrors.estointernet.in/apache/maven/maven-3/3.6.3/binaries/apache-maven-3.6.3-bin.tar.gz
$ sudo tar -xvf apache-maven-3.6.3-bin.tar.gz
$ sudo mv apache-maven-3.6.3 /opt/

2. Set the environment parameters for Maven:

$ M2_HOME='/opt/apache-maven-3.6.3'
$ PATH="$M2_HOME/bin:$PATH"
$ export PATH

3. Download and build the vulnerable application:

$ sudo apt install git
$ sudo git clone https://github.com/securekomodo/text4shell-poc.git
$ cd text4shell-poc
$ sudo ./mvnw clean install

This creates the ./target folder in the current working directory. Within that folder is the JAR file text4shell-poc-0.0.1-SNAPSHOT.jar

4. Deploy the vulnerable application and enable logging:

$ sudo java -jar -Dserver.tomcat.basedir=tomcat -Dserver.tomcat.accesslog.enabled=true ./target/text4shell-poc-0.0.1-SNAPSHOT.jar

5. In a new terminal, forward the application logs to the Wazuh server by editing the agent /var/ossec/etc/ossec.conf configuration file and specifying the path to the log file:

<localfile>
  <log_format>syslog</log_format>
  <location>/path/to/tomcat/access_log.x-x-x.log</location>
</localfile>

This file is under tomcat/logs in the current working directory for this use case.

Detecting vulnerable versions of Apache Commons Text library with Wazuh SCA

The Wazuh SCA module performs scans to discover misconfigurations in monitored endpoints. Policy files are written in YAML and contain rules to be tested against the actual configuration of the endpoint.

Ubuntu endpoint

1. Create a directory on the endpoint to hold local SCA policies:

$ sudo mkdir /home/local_sca_policies/

The custom SCA policies in the Wazuh default ruleset folders are not kept across updates. This is why we create the /home/local_sca_policies/ directory outside the Wazuh agent installation folder.

2. Create the text4shell_policy.yml file in the local SCA policy directory on the endpoint:

$ sudo touch /home/local_sca_policies/text4shell_policy.yml

3. Change the owner and group of the policy file to wazuh:wazuh so that it can be used by the Wazuh user:

$ sudo chown wazuh:wazuh /home/local_sca_policies/text4shell_policy.yml

4. Enable the policy in the Wazuh agent configuration file /var/ossec/etc/ossec.conf by specifying the location of the policy file in the <SCA> block:

<policies>
   <policy>/home/local_sca_policies/text4shell_policy.yml</policy>
</policies>

5. Add the following content in your /home/local_sca_policies/text4shell_policy.yml policy file:

policy:
 id: "text4shell_check"
 file: "text4shell_check.yml"
 name: "Text4Shell dependency check"
 description: "This document provides prescriptive guidance for identifying Text4shell vulnerability"
 references:
   - https://nvd.nist.gov/vuln/detail/CVE-2022-42889
   - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-42889
requirements:
 title: "Check if Java is present on the machine"
 description: "Requirements for running the SCA scan against machines with Java on them."
 condition: none
 Rules:
   - 'c:sh -c "java -version" -> r: not found'
checks:
 - id: 10000
   title: "Ensure Apache Commons Text earlier than v1.10 is not on the system"
   description: "The Apache Commons Text library is vulnerable to RCE on versions between 1.5 to 1.9."
   remediation: "Update the Apache Commons Text library to version 1.10."
   condition: none
   rules:
     - 'c:find / -regex ".*commons-text.*.jar" -type f -exec sh -c "unzip -p {} META-INF/MANIFEST.MF | grep Implementation-Version" ; -> r: 1.5| 1.6| 1.7| 1.8| 1.9'

The check 10000 searches for vulnerable versions of  Apache Commons Text library on the endpoint. This SCA check will fail if a vulnerable version is found.

6. Restart the Wazuh agent to apply the changes:

$ sudo systemctl restart wazuh-agent

Detection results

We can confirm from the SCA dashboard that the endpoint currently has a vulnerable version of the Apache Commons Text Library installed.

text4shell
Figure 1: Text4Shell SCA detection results

Note

To implement this SCA policy across a group of agents, refer to the SCA section of Wazuh documentation.

Detecting Apache Text4Shell exploitation attempts

In order to detect the exploitation of this vulnerability, we write a rule that can match different exploit strings encoded in web requests.

Wazuh server

1. Edit the /var/ossec/etc/rules/local_rules.xml file and add the following custom rules: 

<group name="accesslog,text4shell,">

<!-- This rule matches arbitrary controlled input for exploitation using script, dns or url prefixes -->

  <rule id="100002" level="12">
     <if_sid>31100</if_sid>
     <url type="pcre2">%24%7B(script%3A(javascript|JEXL)%3A|url%3AUTF-8%3A|dns%3A(address|canonical-name|name)%7C)</url>
     <description>Possible Text4Shell (CVE-2022-42889) exploitation attempt detected from $(srcip)</description>
     <mitre>
      <id>T1190</id>
      <id>T1203</id>
     <id>T1210</id>
   </mitre>
  </rule>

</group>

2. Restart the Wazuh manager to apply the changes:

# systemctl restart wazuh-manager

Attack Emulation

To test the detection, send the following web requests to the vulnerable application from any device that has network connectivity with the endpoint:

1. Using the script prefix:

$ curl http://<UBUNTU_IP>:8080/reflected?poc=%24%7Bscript%3Ajavascript%3Ajava.lang.Runtime.getRuntime%28%29.exec%28%27touch%20%2Ftmp%2Ffoo%27%29%7D

This request allows the supplied JavaScript code to be executed. This example creates a file named foo in the /tmp directory of the monitored endpoint.

2. Using the DNS prefix:

$ curl http://<UBUNTU_IP>:8080/reflected?poc=%24%7Bdns%3Aaddress%7Cwww.google.com%7D

This request performs a DNS query, or a reverse lookup to identify internal resources. 

3. Using the URL prefix:

$ curl http://<UBUNTU_IP>:8080/reflected?poc=%24%7Burl%3AUTF-8%3Ahttps%3A%2F%2Fnvd.nist.gov%2Fvuln%2Fdetail%2FCVE-2022-42889%7D

This lookup calls the specified URL to perform basic GET requests to internal resources.

Replace <UBUNTU_IP> with the IP address of the monitored endpoint running the vulnerable application.

Detection results

text4shell with wazuh
Figure 2: Text4Shell exploitation alerts on Wazuh dashboard
detecting apache text4shell
Figure 3: Text4Shell exploitation details on Wazuh dashboard

Mitigations

Apache has released a patch for this vulnerability. Upgrading the Apache Commons Text Library version to 1.10 mitigates the vulnerability. Additionally, check the usage of org.apache.commons.text.StringSubstitutor closely across your codebase and ensure untrusted user input isn’t being passed to vulnerable functions.

Conclusion

In this article, we demonstrate how to detect Text4shell vulnerability by monitoring an endpoint for vulnerable versions of Apache Commons Text Library. To achieve this, we used the Wazuh SCA module and wrote custom rules to detect exploitation attempts on the monitored endpoint.

Wazuh is open source and free to use. It also has a fast-growing community. You can deploy Wazuh on-premises or as a cloud solution using the Wazuh cloud.

References

The post Detecting Apache Text4Shell (CVE-2022-42889) with Wazuh appeared first on Wazuh.

Google Workspace Updates Weekly Recap – December 23, 2022

New updates 


There are no new updates to share this week. Please see below for a recap of published announcements. 

Previous announcements


The announcements below were published on the Workspace Updates blog earlier this week. Please refer to the original blog posts for complete details.


Updated experience for exporting your organization’s data
We’re introducing new capabilities for exporting your organization’s data, giving our customers greater flexibility over managing their organization’s data export needs. | Available to Google Workspace Enterprise Plus, Education Standard, and Education Plus customers only. | Learn more

Google Voice Standard customers can assign phone numbers in other Voice countries in their region 
Google Voice customers on the Standard subscription in Canada, Europe and the US can assign phone numbers to any supported country in their region:
  • Customers in Europe can assign phone numbers in supported European countries
  • Customers in Canada and the US can assign phone numbers in both countries

This change gives our customers on the Standard SKU the flexibility to deploy Voice across the different countries they operate in within the same region. | Available for Google Voice Standard customers only. | Learn more.

More filter effects available for Google Meet
Google Workspace users can now access a variety of new filter effects on Google Meet on the web and mobile. These filters, such as loghead, strawberry, and working bunny, can help bring an element of fun to meetings. | Learn more
Quickly refine search results in Google Chat with search chips
We’re expanding an existing mobile feature to the web that helps you find exactly what you’re looking for much faster using search chips that filter your search results. | Learn more

Completed rollouts


The features below completed their rollouts to Rapid Release domainsScheduled Release domains, or both. Please refer to the original blog post for additional details.


Rapid Release Domains:


Rapid and Scheduled Release Domains:


For a recap of announcements in the past six months, check out What’s new in Google Workspace (recent releases).


STRRAT detection with Wazuh

STRRAT is a Java-based remote access trojan (RAT) that provides threat actors with full remote control of infected Windows endpoints. STRRAT focuses on stealing credentials from browsers and email clients like Microsoft Edge, Google Chrome, Mozilla Firefox, Microsoft Outlook, Mozilla Thunderbird, and Foxmail. It also steals credentials by recording keystrokes of infected endpoints.

Previous versions of STRRAT relied on Java Runtime Environment (JRE) installed on infected endpoints. Recently, this trojan has acquired the ability to deploy its own JRE on infected endpoints.

STRRAT is usually delivered by phishing emails, and it allows attackers to run a plethora of commands on infected endpoints.

In this blog post, we use Wazuh to detect the malicious activities of STRRAT.

STRRAT behavior

  • STRRAT poses as ransomware by adding a .crimson extension to the files on the victim endpoint, although it does not encrypt the files.
  • STRRAT collects basic information like system architecture, the presence of antivirus software, and the operating system of the victim endpoint.
  • STRRAT creates a <digits>lock.file file in the C:Users<USER_NAME> folder. The <digits> represents the port used by the trojan to connect to its command and control (C2) server.
  • STRRAT downloads a system-hook Jar file and uses this file to record the keystrokes of the victim endpoint. This Jar file is located in the C:Users<USER_NAME>lib folder.
  • STRRAT downloads sqlite-jdbc and jna-platform Jar files into the C:Users<USER_NAME>lib folder. The trojan uses these files to perform malicious activities on the victim endpoint.
  • STRRAT maintains persistence by using the task scheduler to create a Windows scheduled task called Skype. This scheduled task runs the malware every 30 minutes.
  • STRRAT attempts to connect to a C2 server to exfiltrate data. It creates a C:Users<USER_NAME>AppDataRoamingstrlogs folder before attempting to connect to its C2 server.

Infrastructure

To demonstrate the detection of STRRAT with Wazuh, we use the following infrastructure:

1. A pre-built ready-to-use Wazuh OVA 4.3.10. Follow this guide to download the virtual machine. 

2. A Windows 10 victim endpoint with Java and Wazuh agent 4.3.10 installed. To install the Wazuh agent, refer to the following guide.

Detection with Wazuh

STRRAT is delivered in stages and uses obfuscation to evade detection on a victim endpoint. In this blog post, we use the following techniques to detect the presence of STRRAT:

  • File integrity monitoring: To detect files created, modified, and downloaded by STRRAT.
  • Command monitoring: To detect a scheduled task created by STRRAT.

File integrity monitoring

Wazuh uses its File Integrity Monitoring (FIM) module to detect and trigger alerts when files are created, modified, or deleted on monitored folders.

Follow the steps below to detect the presence of STRRAT on the victim endpoint.

Victim endpoint

Perform the following steps to configure FIM on the monitored endpoint.

1. Edit the Wazuh agent C:Program Files (x86)ossec-agentossec.conf file and include the following configuration within the <syscheck> block:

<!-- This configuration monitors the malicious activities of STRRAT on the victim endpoint-->
<directories realtime="yes" recursion_level="2">C:Users</directories>

2. Launch Powershell with administrative privilege and restart the Wazuh agent for the changes to take effect:

> Restart-Service -Name wazuh

Wazuh server

Perform the following steps to configure detection rules on the Wazuh server.

1. Edit the /var/ossec/etc/rules/local_rules.xml file on the Wazuh server and include the following rules:

<group name="syscheck,strrat_detection_rule,">
<!-- STRRAT downloads a system-hook Java file for recording keystrokes -->
  <rule id="100050" level="12">
    <if_sid>554</if_sid>
    <field name="file" type="pcre2">(?i)^c:\users.+lib\system-hook.+jar$</field>
    <description>Possible STRRAT malware detected. $(file) was downloaded on the endpoint</description>
    <mitre>
      <id>T1056.001</id>
    </mitre>
  </rule>
<!-- STRRAT poses as ransomware -->
  <rule id="100051" level="8">
    <if_sid>550,554</if_sid>
    <field name="file" type="pcre2">(?i)c:\users.+(documents|desktop|downloads).+crimson</field>
    <description>Possible STRRAT malware detected. The .crimson extension has been appended to $(file)</description>
    <mitre>
      <id>T1486</id>
    </mitre>
  </rule>
<!-- STRRAT creates a lock file -->
  <rule id="100052" level="12">
    <if_sid>554</if_sid>
    <field name="file" type="pcre2">(?i)^c:\users.+\d{1,}lock.file$</field>
    <description>Possible STRRAT malware detected. $(file) was created on the endpoint</description>
  </rule>
<!-- STRRAT downloads Java files -->
  <rule id="100053" level="12">
    <if_sid>554</if_sid>
    <field name="file" type="pcre2">(?i)^c:\users.+lib\(jna-platform|sqlite).+jar$</field>
    <description>Possible STRRAT malware detected. $(file) was downloaded on the endpoint</description>
    <mitre>
      <id>T1407</id>
    </mitre>
  </rule>
</group>

Where:

  • Rule id 100050 is triggered when the STRRAT malware downloads a system-hook jar file.
  • Rule id 100051 is triggered when .crimson extension is appended to files in Documents, Desktop or Downloads folder.
  • Rule id 100052 is triggered when STRRAT creates a <digits>lock.file file in C:Users<USER_NAME> folder.
  • Rule id 100053 is triggered when STRRAT downloads a jna-platform or sqlite-jdbc jar file.

2. Restart the Wazuh manager for the changes to take effect:

# systemctl restart wazuh-manager

The alerts below are generated on the Wazuh dashboard when STRRAT is run on the victim endpoint.

Command monitoring

Wazuh has a command monitoring module to run commands and monitor the output of these commands on monitored endpoints. We use the command monitoring module to detect a Windows-scheduled task called Skype, created by STRRAT.

Victim endpoint

Perform the steps below to configure the Wazuh agent to monitor the scheduled task created by STRRAT on the victim endpoint.

1. Edit the C:Program Files (x86)ossec-agentossec.conf file and include the following configuration within the <ossec_config> block:

<localfile>
  <log_format>full_command</log_format>
  <command>schtasks /query /nh | findstr /c:"Skype"</command>
  <alias>finding_skype</alias>
  <frequency>300</frequency>
</localfile>

Note

The above command runs every 300 seconds, and this is defined by the <frequency> tag.

2. Launch Powershell with administrative privilege and restart the Wazuh agent for the changes to take effect:

> Restart-Service -Name wazuh

Wazuh server

Perform the steps below to configure the Wazuh server to detect the scheduled task created by STRRAT on the victim endpoint.

1. Edit the /var/ossec/etc/rules/local_rules.xml file on the Wazuh server and include the following rules:

<group name="syscheck,strrat_detection_rule,">
<!-- STRRAT creates a scheduled task called Skype -->
  <rule id="100054" level="0">
    <if_sid>530</if_sid>
    <match>^ossec: output: 'finding_skype'</match>
    <description>A scheduled task called Skype is created</description>
  </rule>
<!-- STRRAT maintains persistence -->
  <rule id="100055" level="12" ignore="720">
    <if_sid>100054</if_sid>
    <match type="pcre2">(?i)Skype.+running</match>
    <description>Possible STRRAT malware detected. Malware has achieved persistence</description>
    <mitre>
      <id>T1547.001</id>
    </mitre>
  </rule>
</group>

Where:

  • Rule id 100054 is triggered when a scheduled task named Skype is created.
  • Rule id 100055 is triggered when a scheduled task named Skype is in a running state.

2. Restart the Wazuh manager for the changes to take effect:

# systemctl restart wazuh-manager

The alert below is generated on the Wazuh dashboard when STRRAT malware is run on the victim endpoint.

Note

The below alert takes approximately 30 minutes before it is generated on the Wazuh dashboard.

Conclusion

In this blog post, we have successfully used Wazuh to detect the behavior of STRRAT malware. Specifically, we used file integrity monitoring and command monitoring techniques to detect STRRAT malware on a Windows 10 endpoint.

Wazuh is a free and open source enterprise-ready security solution for threat detection and response. Wazuh integrates seamlessly with third-party solutions and technologies. Wazuh also has an ever growing community where users are supported. To learn more about Wazuh, please check out our documentation and blog posts.

References 

1. Threat Thursday: STRRat Malware

2. New STRRAT RAT Phishing Campaign

The post STRRAT detection with Wazuh appeared first on Wazuh.