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

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.

  1. https://en.wikipedia.org/wiki/Microsoft_365
  2. https://www.cvedetails.com/vulnerability-list/vendor_id-26/product_id-80308/Microsoft-365-Apps.html
  3. https://docs.microsoft.com/en-gb/microsoft-365/admin/setup/customize-sign-in-page?view=o365-worldwide

New Vulnerabilities Affecting OpenSSL: What you Need to Know

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.


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.


  1. 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
  2. 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
  3. 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
  4. 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

Four Critical Areas for Planning a Penetration Test

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


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?


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.


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

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:


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:


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.


  1. https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-41082
  2. https://cve.mitre.org/cgi-bin/cvename.cgi?name=2022-41040
  3. https://gteltsc. vn/blog/warning-new-attack-campaign-utilized-a-new-0day-rce-vulnerability-on-microsoft-exchange-server (Deprecated)
  4. https://www.techtarget.com/whatis/feature/Everything-you-need-to-know-about-ProxyShell-vulnerabilities
  5. https://msrc-blog.microsoft.com/2022/09/29/customer-guidance-for-reported-zero-day-vulnerabilities-in-microsoft-exchange-server/
  6. https://github.com/antonioCoco/SharPyShell

Everything you Need to Know about Tracking GootLoader

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 1, with its developers also being responsible for the GootKit malware as first reported by Dr. Web in 2014 2. 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 3.
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:

  1. Like to identical initial access and exploit methodologies
  2. Like to identical command and control infrastructure and methodology
  3. Like to identical operations time-frame
  4. Like to identical first-stage “loader” malware, GootLoader
  5. 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 20224, 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.


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.


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


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


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


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

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


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.


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.


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


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 2nd 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
– https://adlumin.com
date: 2022/09/26
– attack.execution
– attack.t1059
author: Adlumin, Kyle Auer, Kevin O’Connor
condition: selection
level: medium
category: process_execution
product: windows
– ‘\powershell.exe’
– ‘\wscript.exe’
– ‘\wscript.exe’
– ‘*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!


  1. https://www.trendmicro.com/en_us/research/22/g/gootkit-loaders-updated-tactics-and-fileless-delivery-of-cobalt-strike.html
  2. https://securelist.com/gootkit-the-cautious-trojan/102731/
  3. https://www.zdnet.com/article/gootkit-malware-crew-left-their-database-exposed-online-without-a-password/
  4. https://blogs.blackberry.com/en/2022/07/gootloader-from-seo-poisoning-to-multi-stage-downloader
  5. https://malpedia.caad.fkie.fraunhofer.de/details/win.cobalt_strike
  6. https://threatpost.com/cobalt-strike-cybercrooks/167368/

Your Guide to Detecting Access Failure Incidents

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.