Netwitness Security LLC blog

Netwitness Platform Integration with AWS Application Load Balancer Access logs

RachanaSR — Tue, 23 Jul 2024 04:00:00 GMT

Load balancers sit Infront of the servers, distributes and balances the network and application traffic among many servers. Usually, the load balancer helps to increase the availability and redirect the requests across a few servers managing the load on each server.

AWS Application Load balancer balances HTTP and HTTPS traffic from clients to the target EC2 instance or container or the lambda function across different availability zones. ALB listeners checks the client requests based on the rules configured and target group routes the request to one of the registered target.

Netwitness Integrates the AWS Application load balancer access log via s3universal plugin.

Integration Model:

To take advantage of this new capability within RSA NetWitness, please visit the link below and search for the terms below in RSA Live.
Configuration Guide: Amazon S3 Universal Connector
Collector Package on RSA Live: "Log Collector configuration content for event source AWS S3"
Parser on RSA Live: aws

The Sky Is Crying: The Wake of the 19 JUL 2024 CrowdStrike Content Update for Microsoft Windows and We Should Take Away From It

Will_G — Sat, 20 Jul 2024 04:00:00 GMT

Introduction

Yesterday was a challenging day for many organizations, teams, and individuals worldwide. We can all agree that it was stressful, and the impacts are still being assessed. It will take some time for many organizations to fully understand the ramifications of what has been called the single-largest IT outage in history[i]. On a personal note, my own family was impacted, which brought the matter home for me and many others. The outage resulted from a content update pushed by CrowdStrike to its global customer base. The systems impacted by this content update were those running the Microsoft Windows operating system. The organization has acknowledged that neither Apple Mac nor Linux hosts were affected, and this was not the result of a cyberattack – a fact that led many to feel relieved, albeit for a brief time. Industry veteran and CrowdStrike CEO, George Kurtz, stated on the official CrowdStrike blog and through the media[ii] that, "The issue has been identified, isolated, and a fix has been deployed."

What We Should Focus on and Take Away from This Event

In my opinion, what we as an industry and organization should focus on as a result of this unfortunate situation boils down to the following:

Producing high-quality and consistent code – in addition to the products that leverage said code is difficult and warrants an unrelenting commitment to quality, process, procedure, and thoroughness (see SDLC+Security, The Rugged Software Movement, and many other sources on this topic). CrowdStrike and in this case Microsoft, are no strangers to producing high-quality, effective, and globally adopted and trusted products and my belief is this unfortunate event will further strengthen their resolve to delivering high-quality, and performant technology as they move on from this over time.

Resilience and fault tolerance in application, small systems, and Internetworking Infrastructure should be factored into design by vendors and consumers alike as we place high degrees of trust in these things on the vendor/provider side of the equation and the consumer (in this case business consumers and beyond). Looking at this from an IT/Internetworking perspective it is clear to me that though there is merit in the cloud and its use as an infrastructure option and alternative, it is just one such construct and should be scrutinized and reconsidered as the net effect observed in this incident was exacerbated by the use of cloud and its impact on systems in cloud and on premises, the latter of which required a significant amount of human intervention.

Resilience and fault tolerance in design influence and underscore confidence in business continuity planning and disaster recovery (BCP/DR). Historically, BCP/DR has been looked at as an adjunct element of cybersecurity (see the CIA model and domains associated with the ISC2 CISSP for more detail among many other sources). The reality is that a lapse in BCP/DR and subsequent availability can and may have an impact (time will tell and this will remain to be seen) risk posture and attack surface exposure and management, respectively.

Defense in depth is still – despite many novel and noteworthy attempts by marketing teams through the years to message to the contrary, a terribly important aspect of building solid security programs, managing those programs, in addition to designing, architecting, and managing highly secure networks that continue to deliver visibility, and cognizance of the state of the network (and those assets associated and attached to it). Thus, the risk posture and attack surface become defendable even in the wake of something being unavailable, evaded, or failing.

At NetWitness, many of us are personal friends and colleagues with individuals and teams at both CrowdStrike and Microsoft. Additionally, we are proud to share many joint customers with both organizations and will continue to do our best to be good stewards of those relationships while maintaining a dedicated stance in providing the highest quality products, services, and guidance we can to those customers, in addition to organizations that we are not yet operating within today. If you or your organization have been impacted by the events associated with this recent content push by CrowdStrike and would like to speak to anyone here at NetWitness in regard to what you can do beyond the measures laid out by CrowdStrike to date to ensure your organization has the most optimal and comprehensive visibility and network detection and response at your disposal, please do not hesitate to contact us.

[i] https://www.cnbc.com/2024/07/19/latest-live-updates-on-a-major-it-outage-spreading-worldwide.html

[i] https://www.tomsguide.com/news/live/microsoft-worldwide-outage-live

[i] https://www.yahoo.com/news/microsoft-outage-live-crowdstrike-boss-170429333.html

[ii] https://www.crowdstrike.com/blog/our-statement-on-todays-outage/

[ii] https://x.com/george_kurtz/status/1814235001745027317?s=46

[ii] https://www.crowdstrike.com/blog/statement-on-falcon-content-update-for-windows-hosts/

DDoS using BotNet Use Case

Admin — Tue, 07 May 2024 04:00:00 GMT

Introduction

The NetBot tool is a versatile command and control center (CCC) for DDoS Botnet Attack Simulation & Load Generation, created by that is publicly available via GitHub (https://github.com/skavngr/netbot). This tool is a prototype that uses Python 3 to configure bots, set a CCC server for the bots to be connected to, as well as loading target information for the server.

As this tool is a prototype, it is made to simulate a Client-Server botnet environment using Proof-of-Concept (PoC) code to demonstrate security flaws in software or during a PoC exploit. It is also assists in simulating DDoS attacks towards the target to understand how DDoS attacks disrupts traffic of servers, services, and networks. The tool is straightforward and easy to grasp, making it accessible for users of all levels.

NetBot CLI Banner

Botnet

Botnet is a group of bots and devices (known as zombie bots) linked together to perform the same task, for distribution and scaling. Botnet attacks are used by cybercriminals to carry out intense scraping, DDoS, and other large-scale cybercrime. (MITRE Framework, Resource Development — Compromise Infrastructure: Botnet https://attack.mitre.org/techniques/T1584/005/)

Botnet attacks are far more dangerous than single malware attacks because rather than infecting a single device, botnets infect hundreds, thousands, or even millions of connected devices at once. This poses an exponential threat that is much harder to stop. Making them even more evasive is the fact that the attacker can use incoming software updates from infected devices to redirect or scale up their attack on the fly. This helps attackers stay ahead of countermeasures employed by their victims. Armed with a large force of zombie bots, a single attacker can do more than compromise whole networks. They can quickly replicate and distribute their malware, hijacking growing numbers of devices.

Botnet Attack Diagram

What is a Botnet (IoT Botnet)? (https://www.a10networks.com/glossary/what-is-a-botnet-iot-botnet/.)

‌

Attack Walkthrough

We will start with a nmap scan on the network to find for an open port. The intent is to do a HTTP flood to the server by sending a lot of request packets to the HTTP website.

Take note, for this example, we hosted the webserver on port 8080 and will use port 8080. In normal circumstances, the port we want to monitor is HTTP or HTTPS.

nmap scan command

nmap scan results

Once the target has been found, we make sure that we have access to the HTTP website using the IP address found and port.

Accessing the Website

Next, we will check the response time of the server, record down on how fast the HTTP server will respond normally to requests when accessing the HTTP website. Use the root account and use the command to extract out the response time of the server.

for (( ; ; )); do - initiates a forever loop

curl -o /dev/null -s -w 'Response from Victim Server: %{time_total} seconds\n' http://192.168.1.45:8080 - send an HTTP request to a designated server, directing the output to /dev/null, muting the progress meter, and customizing the output format to display the total time taken for the request in seconds.

sleep 1 - after each request, the script pauses for 1 second before sending the next request.

done - marks the end of the loop

Retrieving Server Response Time

From the target machine, the current CPU is running at around 27% which is a normal rate when running processes, apps, and tasks in the background.

CPU Percentage in Task Manager

Graph of CPU

From kali, we will go to the netbot folder directory and edit the netbot_config.py file to set the target IP address and port 8080.

Edit nebot_config.py File

In this stage, we will start up the NetBot server which is the netbot_server.py python script as it will be where the botnets will connect to. We will be able to view how many bots are connected in the server.

netbot Server

1^st bot (Ubuntu)

The first bot is using Ubuntu. We will go to the netbot folder directory and edit the file netbot_client.py. For this file, we will set the host IP address which is the server and leave the port as default. This will allow the bot to be connected to the server.

Edit netbot_config.py Command

Edit Host IP Address

Once the python script has been edited, we will run the netbot_client.py python script. In Figure 3.4, we can see that currently the server sends a “HALT” response. This response means that the attack is stopped, will not send the attack to the target machine.

Response from NetBot Server

At the server side, we are able to see that the IP address and port number of the bot that is connected to the server.

First Bot Connected to Server

From here, we will be able start the DDoS attack. To start the attack, we will edit netbot_config.py python script and change the ATTACK_CODE to “LAUNCH”. This will start the DDoS HTTP flood attack to the server of the target.

Change ATTACK_CODE to “LAUNCH”

In the Ubuntu bot, we can see that the attack has started after the change of the ATTACK_CODE which the bot is now sending HTTP request to the targeted server.

Response Changed to “LAUNCH”

Looking at the response time of the server, we can see that the response time increased after the attack started. Before the attack, the average response time was about 0.34 seconds, but currently the response time has increased to about 0.64 seconds.

Current Response Time After Start of Attack

2^nd bot (CentOS 7)

The second bot is using CentOS 7. The steps are similar to the Ubuntu bot by editing the netbot_client.py python script, setting the host IP address.

Edit netbot_client.py Command

Edit Host IP Address

After editing the python script, will run it and from here, we can see that the server immediately sends the response to “LAUNCH” the attack since the first bot is already sending request packets to the target server.

Response from NetBot Server

From the server, the second bot has already been added into the list in the server with its IP address and port number.

Second Bot Connected to Server

With two bots attacking, the response time of the server increased again. where with first bot sending request packets, its respond time is 0.64 seconds and adding the second bot increased to about 1.10 seconds.

Increased Response Time with Two Bots

In the target machine, with the DDoS attack still running, we can see that the CPU increased all the way to 100%, where the server is running on the command prompt is at 88.5%. This affects the performance of the applications and servers running in the machine, might cause lag and overheating to it.

CPU Running at Full Capacity

Graph of CPU at 100%

Analysis

In the network traffic that has been captured, it shows the IP addresses that are connected to the HTTP website by sending GET requests packets to the HTTP website.

Network Traffic (Send Request Packets)

In one of the packets, it shows that the request was sent to the host with the IP address 192.168.1.45 to the server at port 8080. Once the request is sent, the server sends back a response which will allow the IP address 192.168.1.0 to have access to the HTTP website.

Network Traffic Information

The next set of network traffic shows that the two bots are connected to the server through the destination port 5555.

Network Traffic (Bots Connected)

In the packets, we can see that a command was sent to both bots, to do a HTTP flood on the target server IP address 192.168.1.45 at port 8080. The “HALT” command shows that the attack is paused, and the “LAUNCH” command shows that the attack will start immediately to flood the server. From the second bot, the “LAUNCH” command was sent immediately as it was connected to server after the attack has started.

Network Traffic Information (Bot 1)

Network Traffic Information (Bot 2)

Rule Creation

For the detection of the DDoS attack that was done, we will create an ESA rule that detects through the destination port, for the HTTP requests that was sent to the server. As there is a possibility that the DDoS traffic are encrypted, we will make use of the web server to detect on the number of HTTP request packets was sent within 1 minute and try track down the number of source IP addresses are sending these requests.

A post on Cloudflare's blog reports that over 60% of the attacks are under 500 Mbps, and almost 30% of the attacks are between 500 Mbps and 10 Gbps. The largest attack they have seen recently was about 550 Gbps. Source: https://blog.cloudflare.com/ddos-attacks-have-evolved-and-so-should-your-ddos-protection/

Take note that for a DDOS, the typical requests will be coming in at more than 1M requests per second, so in this case it is advisable to input in 60M requests (60000000) in the field "Occurs".

It is helpful to include the list of webservers IP address if known.

Also, the rule would need to be written to group by destination IP.

ESA Rule – DDoS Attack Detected

HYDRA Brute Force

Admin — Tue, 07 May 2024 04:00:00 GMT

INTRODUCTION

Hydra stands as a formidable tool in the arsenal of cybersecurity professionals and hackers alike, renowned for its prowess in brute-force attacks. Leveraging its versatile capabilities, Hydra can systematically probe login interfaces of various protocols and services, relentlessly attempting to crack passwords through exhaustive trial and error. Its adaptability extends across a wide spectrum, encompassing HTTP, HTTPS, FTP, SSH, Telnet, SMTP, and numerous other authentication mechanisms, making it a versatile option for penetrating diverse systems and applications.

Hydra traces its origins back to the early days of cybersecurity exploration and penetration testing, emerging as a vital tool in the arsenal of ethical hackers and security professionals. Developed by van Hauser, also known as Thorsten Schroeder, in the late 1990s, Hydra was conceived as an open-source project aimed at providing a robust and flexible solution for conducting brute-force attacks against various authentication systems. Originally designed to support a limited set of protocols, Hydra's capabilities rapidly expanded over the years, thanks to the contributions of an active community of developers and security enthusiasts. Its evolution mirrored the escalating sophistication of cybersecurity threats and the growing need for comprehensive testing tools to assess the resilience of digital defenses.

Today, Hydra stands as a testament to the collaborative spirit of the cybersecurity community, embodying years of refinement and innovation in the pursuit of enhancing digital security practices and fortifying systems against malicious intrusions.

This blog will also Cover AS-REP roasting where epitomizes a sophisticated attack vector within the realm of Active Directory environments, leveraging weaknesses in Kerberos authentication. This technique targets accounts configured with "Do not require Kerberos pre-authentication" enabled, allowing adversaries to request AS-REP (Authentication Service Response) tickets without presenting any valid credentials.

By exploiting this vulnerability, attackers can capture encrypted AS-REP tickets for targeted user accounts. When armed with a password list, attackers can then systematically decrypt these tickets offline, leveraging the captured hashes and the passwords contained within the list to compromise user accounts.

This method poses a significant threat, particularly in environments where weak or easily guessable passwords are prevalent. As organizations increasingly rely on Active Directory for authentication and access control, understanding and mitigating AS-REP Roasting attacks with password lists is paramount to maintaining robust cybersecurity defenses.

Brute Force

Brute forcing credentials represents a persistent and often effective method employed by attackers to gain unauthorized access to systems, accounts, or sensitive information. This technique involves systematically trying an exhaustive number of possible combinations of usernames and passwords until the correct credentials are discovered.

By leveraging automated tools like Hydra or specialized scripts, attackers can rapidly cycle through vast sets of potential passwords, exploiting weaknesses in authentication systems. Brute forcing is particularly potent against weak or commonly used passwords, highlighting the critical importance of robust password policies, multi-factor authentication, and other security measures to mitigate the risk of unauthorized access. Despite its simplicity, brute forcing remains a prevalent threat in the cybersecurity landscape, underscoring the ongoing need for vigilance and proactive defenses to safeguard against credential-based attacks.

Brute Force Attack

HYDRA Attack

A scan on the network will be to look for any ports or protocols that can be exploited and brute forced to gain initial access into the system.

NMAP Scan

In this case, we see that port 22 (SSH) is open. This is good news for attackers as this means that remote access to the device is enabled if the right credentials are entered.

Scan Result

The command entered below is to direct hydra to use a username list to run it against a password list (obtained from Rock You in Kali) and match each user to a password to find valid credentials which we can use to log in. In this case, hydra has discovered that we have a hit in one of the username and password list by the name of jack.

HYDRA brute-forcing

Command Entered:

hydra -L username_list.txt -P password_list.txt ssh://192.168.1.11

SSH into Compromised Account

We can see that we managed to gain Initial Access into the devices via the stolen credentials.

AS-REP Attack

An AS-REP attack with authentication to the Key Distribution Center (KDC) exploits vulnerabilities in the Kerberos authentication protocol used in Active Directory environments. Typically, when a user attempts to authenticate to a service, the client sends a request to the KDC for a Ticket Granting Ticket (TGT).

The KDC responds by encrypting a TGT using the user's password hash. However, certain accounts may be configured with the "Do not require Kerberos preauthentication" attribute enabled, meaning the KDC doesn't require the client to prove knowledge of the password before issuing the TGT.

In an AS-REP attack, an attacker can send a forged authentication request to the KDC for a TGT without providing valid credentials. The KDC, unaware of the absence of preauthentication, responds by encrypting a TGT using the user's password hash.

The attacker can then capture this encrypted TGT and attempt to crack it offline to retrieve the user's plaintext password, potentially gaining unauthorized access to the user's account. This attack underscores the importance of securing accounts and properly configuring authentication mechanisms within Active Directory environments to mitigate such vulnerabilities.

KDC Key Exchange

We will be using Impacket to carry out this attack. In an Impacket GETnpusers attack, adversaries exploit vulnerabilities in the way Active Directory handles certain types of Kerberos tickets. Specifically, this attack targets the Kerberos AS-REQ (Authentication Service Request) message sent by clients to the Key Distribution Center (KDC) to request service tickets.

By sending a forged AS-REQ message with specific flags, attackers can trick the KDC into providing a special type of ticket, known as a TGT (Ticket Granting Ticket), without presenting valid credentials. This TGT can then be used to request service tickets for any user in the domain, even without knowing their passwords. Impacket's GETnpusers tool automates this process, allowing attackers to quickly harvest TGTs and enumerate users within the domain.

AS-REP Attack

Analysis (Brute Force)

Brute Force SSH logs captured on NetWitness system.

From the 2 images above, we are able to see that there are a lot of SSH connection coming through in the form of “sshd.exe -y” and “sshd.exe -r”. The sshd.exe -y option is used to generate host keys for the OpenSSH server on Windows. When you run sshd.exe -y, it will create host key files if they don't already exist. The -R option is used with the sshd (OpenSSH server) to specify remote port forwarding.

Remote port forwarding allows a connection from the server to a remote client, creating a tunnel for the specified ports. In normal traffic, one or two ssh connections are normal, but, as we can see from the logs, there are hundreds of SSH connections coming in in a span of seconds.

Analysis (AS-REP)

In an AS-REP attack scenario with a username list, adversaries exploit vulnerabilities in Active Directory authentication to compromise user accounts. Armed with a list of usernames harvested through reconnaissance or other means, attackers systematically submit requests for AS-REP tickets for each user in the list. These tickets contain encrypted hashes of the user's password. Subsequently, attackers can offline decrypt these tickets using specialized tools and techniques, potentially uncovering weak or easily guessable passwords associated with the targeted user accounts.

AS-REP Roasting Enumeration

When a valid username is found to be part of the domain, the server will reply the client, which in this case is the attacker, with a AS-REP reply. This reply is then intercepted, and the hash of the user can be cracked offline giving the attacker an entry into the network.

Successful AS-REP from server

Possible Rules to Detect for SSH Brute Force

The rule created is to detect for SSH brute Force. Specific Meta keys are picked out to detect for anomalies within the network for a possible brute force attack on.

ESA Rule

Rule Syntax

Threshold set

@Name('Module_77b66f53_5fdc_4c8e_a05f_c926e780c3c4_Alert')

@Description('')

@RSAAlert(oneInSeconds=0)

SELECT * FROM Event(

/* Statement: SSH Brute Force */

(isOneOfIgnoreCase(filename_src,{ 'sshd.exe' }) AND isOneOfIgnoreCase(directory_dst,{ 'C:\\Windows\\System32:\\OpenSSH\\' }) AND isOneOfIgnoreCase(param_src,{ 'sshd.exe \"-R\"' }) AND isOneOfIgnoreCase(param_dst,{ 'sshd.exe \"-y\"' }))

)

;

Rule Test

Possible Rules to Detect for AS-REP Roasting

The meta keys chosen for this rule is specifically to pick up on behaviour associated with AS_REP Roasting with enumeration within the network.

Rule syntax

Rule Test

module Module_65b620a6e4b0c8e3c269fd3e;

@Name('Module_65b620a6e4b0c8e3c269fd3e_Alert')

@Description('')

@RSAAlert(oneInSeconds=0)

SELECT * FROM Event(

/* Statement: Suspected Domain Brute Force */

(isOneOfIgnoreCase(action,{ 'kerberos as request' }) AND error.toLowerCase() IN ( 'kdc err c principal unknown' ) AND ( 'kerberos as reply' != ALL( action ) ) AND ad_username_dst.toLowerCase() IN ( 'krbtgt' ) AND tcp_dstport IN ( 88 ))

/* Statement: Successful Login */

(( 'kerberos as reply' = ANY( action ) ) AND ( 'kerberos as reply' = ANY( action ) ))

).win:time(1 Minutes)

MATCH_RECOGNIZE (

PARTITION BY ip_src

MEASURES E1 as e1_data , E2 as e2_data

PATTERN (E1 E2* E1 E2* E1 E2* E1 E2* E1 E2* E1 E2* E1 E2* E1 E2* E1 E2* E1 E2* E1 E2* E1 E2* E1 E2* E1 E2* E1 E2* E1 E2* E1 E2* E1 E2* E1 E2* E1+ E2)

DEFINE

E1 as (isOneOfIgnoreCase(E1.action,{ 'kerberos as request' }) AND E1.error.toLowerCase() IN ( 'kdc err c principal unknown' ) AND ( 'kerberos as reply' != ALL( E1.action ) ) AND E1.ad_username_dst.toLowerCase() IN ( 'krbtgt' ) AND E1.tcp_dstport IN ( 88 )),

E2 as (( 'kerberos as reply' = ANY( E2.action ) ) AND ( 'kerberos as reply' = ANY( E2.action ) ))

);

A Closer Look at Advanced EPL (ESA) Through a Rule and its Components

DanielSpier — Wed, 13 Mar 2024 04:00:00 GMT

It is no secret that getting your head around the capabilities or syntax of Esper EPL can be difficult and that finding examples which fit your needs can be just as hard. Even then, you may still be left with more questions than answers. In this blog, we take a look at a rule from an educational perspective. With the information provided, you should be able to massage the rule into a variety of use cases or apply the concepts to brand new requirements.

A quick note about documentation: Google queries have often led me to old versions of the Esper documentation so double check the URL when you're following links. Here's a link to the latest documentation and I'd particularly suggest reading section 2. https://esper.espertech.com/release-8.9.0/reference-esper/html_single/

Context

Alerts based on the rate of traffic matching an arbitrary query can be useful for SOC monitoring suspicious activity or engineering teams ensuring proper data flow. This rule is meant to act similar to Health & Wellness alarms to avoid repetitive alerting:

A threshold condition (total event count) is met within a time period
The condition is sustained for a number of time periods
An alert fires and will not fire again until the condition resolves (count falls below the threshold)

Follow-up actions from this alert should include a manual query to better assess the situation causing the rule to fire. Alternatively, integration with SOAR could trigger queries or reports to obtain the relevant information.

Memory Management

This rule was specifically designed without the use of sliding or batch time windows due to their high memory overhead which traditionally require time windows to be short and without a large number of events. Given that only a count is being kept here, it should be suitable for high rates and long periods with little performance impact. However, as always, the rule should be deployed as a trial rule and monitored closely after the initial deployment.

At the time of this writing, I've observed that there are only specific situations where the Java engine is able to collect statistics from the rule. This might make more sense as you read further but imagine the following events in the window, where S is stat collection start, E is end, and F T T T is the search pattern.

            * * * *                 * * * * 
F F F T F T F T T T T T F T T F T T F T T T T T T F F
                  S     E                 S       E

I've talked to the engineering team about this and it appears to be a limitation of objects exposed from the Esper engine to the NetWitness integration while the search pattern is incomplete. Regardless, during the periods where statistics are available, I've found this rule is only using 25-100KB of memory and very little CPU, even when matching over 1,000,000 events per hour.

Future Enhancements

Future enhancements could include modifying the rule to alert when a rate is sustained below a threshold (easy), dynamically calculating the threshold based on standard deviation (complicated), or considering the pass/fail criteria based on followed-by or otherwise complex conditions. The rule could also be simplified by alerting on a total count within a time period or set of periods and then using @RSAAlert to suppress alerts for an acceptable period of time. Otherwise, for the purpose of alerting on a sustained rate above a threshold, the sample rule provided here is easily customizable to fit other use cases by modifying the event filter criteria.

Example

Consider an example where the rule is looking for time periods containing more than 700 events matching the selection criteria and sustained for two periods. Also requiring the two periods to be preceded by a period that failed to meet the threshold prevents the alert from firing again until the situation causing the elevated rate has ended.

The below example is looking for three 60-minute periods containing at least 500,000 events. The event criteria is inbound DNS with the error = "no name" meta. The error meta key is a multivalued meta key and, as such, will need to be defined in the correlation service. Don’t forget to sync the keys when this value is updated in the service config. https://community.netwitness.com/s/article/UpdateYourESARulesfortheRequiredMulti-ValueandSingle-ValueMetaKeys

Including direction IS NOT NULL may or may not be required. In the past, it was advised to ensure that at least one condition in a statement would match to avoid EPL errors. I will update the blog if I get clarification on this point.

WARNING: If you are deploying multiple versions of this rule, the named window, context, variable, and schema names must be unique because these are global structures shared by the ESA deployment. In a text editor, you can find/replace "Rule#" to avoid issues.

The comments in the rule below explain each component used, or should at least give you enough information to find the relevant sections in the Esper EPL documentation.

//If you are deploying multiple versions of this rule, the following must be unique because these are globally shared by the ESA deployment. Update all occurrences in the rule by replacing "rule#" with a unique rule number: //  window names //  context names //  variable names //  schema names //Modify the variables, the FROM clause in the statement with the event filter criteria, and the pattern match occurrences (numbers in {#} next to E1/E2). //This alert will NOT populate the Respond alert with actual session data. It will simply notify you that your criteria has been met which should then be followed up with a manual query. //If the rule is deployed when the matching traffic rate is already above the threshold, the rule will not begin tracking until the rate drops below the threshold again. //The time period must contain at least this many sessions in order to insert a "True" value into the history window. CREATE VARIABLE integer var_session_threshold_rule1 = 500000; //The length of time that must pass before the final comparison of the total number of sessions in the window against the threshold. CREATE VARIABLE integer var_window_minutes_rule1 = 60; //100 should be large enough to handle most use cases. This window's main purpose is to hold True/False values for the match_recognize statement. //It is intentionally not part of the context because we need to track results spanning multiple context instances. //@RSAPersist will keep the contents of the window stored on the ESA appliance at /var/netwitness/correlation-server/esa-windows/. When the service restarts, the window contents will be restored from the file. //When the stored events are written back into the window (oldest to newest), this will trigger the SELECT statement and may fire alerts. The @RSAAlert suppression would likely mean only one alert would fire. //It is not necessary to use @RSAPersist but it can be helpful for debugging through service restarts. @RSAPersist CREATE WINDOW thresholdHistoryWindow_rule1.win:length(100) (bool_exceeded bool, window_ending string, matched_count long); //Contexts are a way to segment event streams. In this case, we start a context as soon as the rule deploys, terminate it after the defined number of minutes, and start a new one after the defined number of minutes. CREATE CONTEXT contextTimePeriod_rule1 INITIATED @now AND PATTERN [every timer:at(*/var_window_minutes_rule1, *, *, *, *)] TERMINATED after var_window_minutes_rule1 minutes; //By including an operator (>=) in the SELECT clause, the result of the statement becomes a boolean value which is then inserted into the history window. //"Event(...)" means that only sessions matching the criteria in parentheses will be counted. //Esper EPL maintains a count of matching events via count(). It will not retain the events (thus reducing memory requirements) unless a batch or sliding window are created. //OUTPUT LAST WHEN TERMINATED prevents the SELECT clause result from being inserted until the context terminates. //Newlines/indentation are not necessary but help make the rule easier to read. Note that the statement begins at CONTEXT and ends with the semicolon after TERMINATED. CONTEXT contextTimePeriod_rule1 INSERT INTO thresholdHistoryWindow_rule1 SELECT count(*) >= var_session_threshold_rule1 as bool_exceeded, current_timestamp().toDate().toString() as window_ending, count(*) as matched_count FROM Event(direction IS NOT NULL AND isOneOfIgnoreCase(error,{ 'no name' }) AND direction.toLowerCase() IN ( 'inbound' ) AND service IN ( 53 )) OUTPUT LAST WHEN TERMINATED; //oneInSeconds=600 prevents alert spam in case the rule behaves unintentionally. //match_recognize is used to ensure that the pattern is matched explicitly in the order described without any intermediate events being considered for the match. //Modify the numbers in curly braces {#} in the pattern to set how many occurrences of each event are needed for the alert to fire. @RSAAlert(oneInSeconds=600) SELECT * FROM thresholdHistoryWindow_rule1 MATCH_RECOGNIZE( MEASURES E1 as e1_data, E2 as e2_data PATTERN ( E1{1} E2{3}) DEFINE E1 as (E1.bool_exceeded = false), E2 as (E2.bool_exceeded = true) );

Note: If you plan to use this rule in the online EPL tryout tool, EsperTech Esper EPL Online, you will need to use direction IN ( 'inbound' )because the toLowerCase() function is custom (but built into the ESA deployment). The @RSAAlert annotation should be removed as well. Sample input for the tryout tool is attached but is not maintained to exactly match the rule above so you may need to adjust it.

Also, you should understand how the @RSAPersist annotation behaves, especially if you use it in other ESA rules. ESA Annotations.

After deploying rules with named windows, you can use the Named Windows tool under the ESA Rules tab of the UI to view the window contents. In this screenshot, I have a field called "windowEnding" but later changed the script above to "window_ending" for consistency.

Summary

Hopefully you learned something from this dissection of an ESA rule and can see how its concepts could be applied to other use cases. I thought it was important to share not only what works, but why certain methods were chosen and which methods didn't work. The use of contexts here instead of sliding or batch windows, as well as the match_recognize syntax, should provide a good deal of flexibility. If you implement a version of this rule, please share your use case and experience!

FirstWatch Threat Spotlight – Remcos RAT

manojpilli — Tue, 22 Aug 2023 04:00:00 GMT

Summary:

Remcos is a closed-source tool that is marketed as a remote control and surveillance software by a Germany-based firm called Breaking Security. Remcos has been observed being used in malware campaigns with a wide array of functionalities.

On the Breaking Security website, Remcos or Remote Control and Surveillance tool, is marketed as a professional and legitimate tool for remotely managing Windows systems but it is now widely used in multiple malicious campaigns by threat actors. Remcos RAT is a sophisticated remote access Trojan (RAT) that can be used to fully control and monitor any Windows computer from XP and onwards. On this webpage, it provides two versions: professional edition (with all features included) and free edition (with restricted features).

Remcos RAT is recognized as a malware family because it has been abused by hackers to secretly control victims’ devices since its first version was published on July 21, 2016.

Remcos RAT is designed to be stealthy and evasive, making it difficult for antivirus software and other security measures to detect and remove it. It is typically delivered through social engineering techniques, such as phishing emails or malicious downloads.

Features / Capabilities:

Once installed on a victim's system, Remcos RAT provides the attacker with a wide range of capabilities, including:

System: Screen Capture, File Manager, File Search, Process Manager, etc.
Surveillance: Webcam, Microphone, Keylogger, Screenlogger, etc.
Network: Proxy, Downloader, Open Webpage, etc.
Others: Dll Loader, Logins Cleaner, Audio Player, etc.
Heartbeat packet: Provides an inter-nodal communication packet.
Unauthorized Access: Attackers can gain complete control of the victim's computer remotely, allowing them to access files, folders, and applications as if they were physically present at the machine.
Ransomware Deployment: In some cases, attackers may use Remcos RAT to deliver and install ransomware on the victim's system, encrypting their files and demanding a ransom for decryption.
Banking Fraud: Remcos RAT can be used to perform fraudulent transactions by gaining access to the victim's online banking accounts.
Network Scanning: Remcos RAT can scan the local network to identify other vulnerable devices.
DDoS Attacks: Some versions of Remcos RAT have been known to include DDoS capabilities, allowing attackers to use the compromised machines as part of a botnet to launch distributed denial-of-service attacks.
Spreading Malware: Attackers can use Remcos RAT as a gateway to drop additional malware onto the victim's system, infecting it with more harmful software.
Privilege Escalation: Remcos RAT may be used to escalate privileges on the compromised system, enabling the attacker to gain administrator or root access for more control over the device.
Keylogging: Remcos RAT can capture all keystrokes made by the victim, including login credentials, credit card numbers, and other sensitive information. This enables attackers to steal valuable data.
File Management: Attackers can access, download, and upload files on the compromised system, potentially stealing sensitive data or dropping additional malware.
Surveillance: Remcos RAT can remotely enable the victim's webcam and microphone, allowing attackers to spy on the victim's activities and conversations.
Screen Capture: Attackers can take screenshots of the victim's desktop, providing them with visual information about the victim's activities and potentially sensitive data.

Please refer to below images for more features/capabilities of Remcos RAT

Figure 1: Surveillance capabilities of Remcos RAT.

Figure 2: System capabilities of Remcos RAT.

Detection:

There are many articles on the internet covering how Remcos RAT can be delivered. Here in this article, I will be covering what happens when Remcos RAT is being run on the victim host and the ways attackers can use this RAT to get the system information, along with NetWitness detections covering several of it's typical activities.

Activities done by Remcos RAT during initial execution on the victim device:

Geo-location: Remcos RAT will try to get the victim machine geo location to register with attackers by sending a get request to geoplugin.net for location check by the infected Windows host.

Figure: Geo-location capabilities of Remcos RAT

NetWitness can detect this activity with the rule "Host traffic to external IP checker”.

Persistence: The malware adds a Startup registry key at “HKCU\Software\Microsoft\Windows\CurrentVersion\RunOnce” for it to become persistent when the device affected has been restarted. This path can be changed during the agent build process.

NetWitness can detect this activity with "Remcos RAT Persistence registry entry".

During the installation of this software a specific registry key is set in place related to the licensing of this software. The rule "Remcos rat creates run key" detects agent/client install at the compromised host. With custom monitoring of these registry entries, we can get to know if the host is compromised with remcos or not as shown in the below image.

Figure 3: Remcos RAT registry entry along with Netwitness detection.

Detecting sensitive information that, it could steal from a victim's machine.

DxDiag: DirectX Diagnostic Tool (DxDiag) is a diagnostics tool used to test DirectX functionality and troubleshoot video- or sound-related hardware problems. DirectX Diagnostic can save text files with the scan results which contains current DirectX version, the computer's hostname, the operating system's version, information on the system BIOS, and other data. AS it is legitimate tool to use on windows machine, Remcos RAT exploits Dxdiag to obtains the above-mentioned information.

Figure 4: Detection of the activity "Enumeration of System Information using Dxdiag"
Keylogging: This Remcos RAT has another feature for keylogging and grabbing the clipboard data that will be placed in the%appdata%\remcos folder named as logs.dat file. It also serves as a debug log for Remcos RAT for actions like clearing browser history and so on. Below is the snippet of logs.dat while testing this feature. [References [3]]

Figure 5: Remcos RAT keylogging capabilities

With the rule “Remcos RAT keylog File Creation” Netwitness can detect this activity.

Audio Recording: Remcos RAT can record the victim’s audio input from an input device ( microphone). This behavior was seen in multiple Remcos RAT malware samples where it put the audio recording in the appdata\audio folder as part of data collection. This recording can be sent to its C2 server as part of its exfiltration to the compromised machine. Creation of wav files in this folder path is not a usual place for the user to save an audio format file.

The rule “Suspicious audio file creation in temporary folders” can detect a suspicious creation of .wav file in appdata folder.

Screenshots: The attacker can capture a screenshot of the compromised machine and place it in the appdata folder, where it will be sent to its C2 server. This TTP is really a good indicator to check that process because it is in suspicious folder path and image files are not commonly created by a user in this folder path.

The rule “Suspicious image file creation in temp folders” can detect a suspicious creation of .wav file in appdata folder.

UAC Bypass: This RAT can Bypass UAC by modifying the "EnableLua" registry value to disable UAC on the compromised machine.

The rule “Silently accepting end user license” detects any application accepting end user license agreement on a Windows host.

Remcos C2 Console usage Detection:

DNS Query: A specific DNS query was also detected during the installation process, specifically directed towards p4-preview.runhosting.com. Some other products from the same vendor have also been observed in this domain as well.

Figure 6

Figure 7

NetWitness Detections

After analyzing samples from various sources and referring to research articles, following are existing NetWitness Detections that aid in identifying not just Remcos RAT’s malicious activity, but other adversaries as well that might be part of similar techniques.

Application Rules (Endpoint):

          boc = "Disables UAC"
          boc = "Potential Windows User Account Control Bypass"
          boc = "Creates Run Key"
          boc = "Windows Executable Runs Command Shell"
          boc = "Lists Directory Structure of a Path"
          boc = "Disables UAC Remote Restrictions"
          boc = "unsigned writes executable to appdatalocal directory"

boc = "Host Traffic to External IP Checker"

In addition to the existing content, we have also created new rules as mentioned above to better detect host and network activity related to Remcos RAT. All of the following are currently available from NetWitness Live. After deploying/importing these rules on to NetWitness stack, these can be seen under Investigate -> Navigate upon detecting any Remcos RAT related activity on the customer environment.

          boc = "enumeration_of_sys_info_using_dxdiag"                (App Rule - Endpoint)
          boc = "remcos_rat_c2_console_usage_detected"              (App Rule - Packet)
          boc = "remcos_rat_creates_run_key"                                 (App Rule - Endpoint)
          boc = "remcos_rat_keylog_file_creation"                            (App Rule - Endpoint)
          boc = "remcos_rat_persistence_registry_entry"                 (App Rule - Endpoint)
          boc = "suspicious_audio_file_creation_in_temp_folders"   (App Rule - Endpoint)
          boc = "suspicious_image_file_creation_in_temp_folders" (App Rule - Endpoint)
          [Community] Remcos RAT YARA Rules

MITRE ATT&CK Information:

Tactic	T. ID	Technique Name	Activity
Persistance	T1547.001	Boot or Logon Autostart Execution: Registry Run Keys / Startup Folder	Remcos can add itself to the Registry key HKCU\Software\Microsoft\Windows\CurrentVersion\Run for persistence.
Execution	T1059.003	Command and Scripting Interpreter: Windows Command Shell	Remcos can launch a remote command line to execute commands on the victim’s machine.
Execution	T1059.006	Command and Scripting Interpreter: Python	Remcos uses Python scripts.
Defence Evasion	T1112	Modify Registry	Remcos has full control of the Registry, including the ability to modify it.
	T1027	Obfuscated Files or Information	Remcos uses RC4 and base64 to obfuscate data, including Registry entries and file paths.
	T1548.002	Abuse Elevation Control Mechanism: Bypass User Account Control	Remcos has a command for UAC bypassing.
	T1055	Process Injection	Remcos has a command to hide itself through injecting into another process.
Discovery	T1083	File and Directory Discovery	Remcos can search for files on the infected machine.
Discovery	T1497.001	Virtualization/Sandbox Evasion: System Checks	Remcos searches for Sandboxie and VMware on the system.
Collection	T1123	Audio Capture	Remcos can capture data from the system’s microphone.
	T1115	Clipboard Data	Remcos steals and modifies data from the clipboard.
	T1056.001	Input Capture: Keylogging	Remcos has a command for keylogging.
	T1113	Screen Capture	Remcos takes automated screenshots of the infected machine.
	T1125	Video Capture	Remcos can access a system’s webcam and take pictures.
Command and Control	T1090	Proxy	Remcos uses the infected hosts as SOCKS5 proxies to allow for tunneling and proxying.
Command and Control	T1105	Ingress Tool Transfer	Remcos can upload and download files to and from the victim’s machine.

Conclusion:

Remcos or Remote Control and Surveillance, marketed as a legitimate software by Germany-based Breaking Security for remotely managing Windows systems is now widely used in multiple malicious campaigns by threat actors. Remcos RAT is a sophisticated remote access Trojan (RAT) that can be used to fully control and monitor any Windows computer from XP and onwards.

Currently many threat actors are utilizing social engineering techniques to deliver this payload. It is our responsibility to prevent and detect the activities done by threat actors using Remcos RAT.

In this blog, we examined Remcos RAT and how it can be used by threat actors to gain access to victim’s host. Next, we covered its features and capabilities in detail through activities done during installation and operation, and NetWitness detections for them as well as C2 console usage detection. Finally, we listed Mitre attack framework TTP's for Remcos RAT.

References:

[1] Remcos, Software S0332 | MITRE ATT&CK

[2] The Latest Remcos RAT Driven By Phishing Campaign | FortiGuard Labs

[3] Detecting Remcos Tool Used by FIN7 with Splunk | Splunk

[4] Remcos - Splunk Security Content

[5] Remcos | Remote Control & Surveillance Software

[6] Triage

[7] Remcos Malware Analysis, Overview by ANY.RUN

Content Hygiene – Application Rule Alert Mapping Updates

DarrenMccutchen — Tue, 11 Jul 2023 04:00:00 GMT

To help facilitate future content improvements such as new bundles and feeds, we have adjusted the alert meta mappings for several Application Rules. By more strictly adhering to the original intention for the alert detection categories, NetWitness users will gain more meaningful and accurate insights into activity within their environments. Rules were re-aligned with the Hunting Compromise and Analysis Keys:

Behavior of Compromise (boc): Designated for suspect or nefarious behavior outside the standard signature-based detection
Service Analysis (analysis.service): Core application protocols identification and inspection
Session Analysis (analysis.session): Client-server communication deviations
File Analysis (analysis.file): A large inspection library that highlights file characteristics and anomalies

Updated Application Rules:

Name	Previous Key	*New Key*
exe filetype but not exe extension*	boc	*analysis.file*
Small Executable	alert.id	*analysis.file*
Small Executable Extension Mismatch	alert.id	*analysis.file*
Small Executable No Directory	alert.id	*analysis.file*
Small Executable No Host	alert.id	*analysis.file*
Small Executable Root Directory	alert.id	*analysis.file*
DoH Usage*	boc	*analysis.service*
IRC File Transfer	alert.id	*analysis.service*
Passwords Over FTP	alert.id	*analysis.service*
Passwords Over HTTP	alert.id	*analysis.service*
Passwords Over Other Protocols	alert.id	*analysis.service*
Passwords Over Pop3	alert.id	*analysis.service*
Passwords Over SMTP	alert.id	*analysis.service*
Passwords Over Telnet	alert.id	*analysis.service*
Possible SMB Scanning Detected*	boc	*analysis.service*
BYOD Mobile Web Agent Detected	alert.id	*analysis.session*
Possible Port Scanning Detected*	boc	*analysis.session*
suspicious long filename get request	alert.id	*analysis.session*
suspicious PHP url-encoded put	alert.id	*analysis.session*
Unknown Service Over DNS Port	alert.id	*analysis.session*
Unknown Service Over FTP Port	alert.id	*analysis.session*
Unknown Service Over HTTP Port	alert.id	*analysis.session*
Unknown Service Over IRC Port	alert.id	*analysis.session*
Unknown Service Over NNTP Port	alert.id	*analysis.session*
Unknown Service Over POP3 Port	alert.id	*analysis.session*
Unknown Service Over SMB Port	alert.id	*analysis.session*
Unknown Service Over SMTP Port	alert.id	*analysis.session*
Unknown Service Over SSL Port	alert.id	*analysis.session*
Unknown Service Over Telnet Port	alert.id	*analysis.session*
Archive From IP Address	alert.id	*boc*
Attachment Overload	alert.id	*boc*
File Transport Over Unknown Protocol	alert.id	*boc*
Non-Standard Port Use - DHCP	alert.id	*boc*
Non-Standard Port Use - DNS	alert.id	*boc*
Non-Standard Port Use - FTP	alert.id	*boc*
Non-Standard Port Use - H323	alert.id	*boc*
Non-Standard Port Use - HTTP	alert.id	*boc*
Non-Standard Port Use - IRC	alert.id	*boc*
Non-Standard Port Use - NetBios	alert.id	*boc*
Non-Standard Port Use - NNTP	alert.id	*boc*
Non-Standard Port Use - POP3	alert.id	*boc*
Non-Standard Port Use - RDP	alert.id	*boc*
Non-Standard Port Use - RIP	alert.id	*boc*
Non-Standard Port Use - RPC	alert.id	*boc*
Non-Standard Port Use - RTP	alert.id	*boc*
Non-Standard Port Use - SIP	alert.id	*boc*
Non-Standard Port Use - SMB	alert.id	*boc*
Non-Standard Port Use - SMTP	alert.id	*boc*
Non-Standard Port Use - SNMP	alert.id	*boc*
Non-Standard Port Use - SSH	alert.id	*boc*
Non-Standard Port Use - SSL	alert.id	*boc*
Non-Standard Port Use - TDS	alert.id	*boc*
Non-Standard Port Use - Telnet	alert.id	*boc*
Non-Standard Port Use - TFTP	alert.id	*boc*
Non-Standard Port Use - TNS	alert.id	*boc*

* - Users subscribed to these alerts will have rules automatically updated

Note - Application Rules formerly keyed to ‘alert.id’ will need to be added from NetWitness Live.

Removed Content

As an additional content hygiene measure, the following outdated/discontinued content has been removed from NetWitness Live:

Advanced Analytics (Warehouse) / Data Science Model
- ETL for Mapr
- ETL
- ETL for Pivotal
- Host Profile for Mapr
- Host Profile for Pivotal
- Suspicious DNS Activity for Mapr
- Suspicious DNS Activity for Pivotal
- Suspicious Domains for Mapr
- Suspicious Domains for Pivotal
Application Rules
- HttpBrowser Malware
- NTP DDoS Attack 234-byte Request: Packets
- NTP DDoS Attack 50-byte Request: Packets
- NTP DDoS Attack 60-byte Request: Packets
- NTP DDoS Attack 234-byte Request: Netflow
- NTP DDoS Attack 50-byte Request: Netflow
- NTP DDoS Attack 60-byte Request: Netflow
- Large Outbound Encrypted session
- Large Outbound Session
Event Stream Analysis
- Cerber Ransomware
- Inbound Packet Followed by Recipient Outbound Encrypted Connection
- Internal Data Posting to 3rd party sites
- Malware Dropper
- Web DoS Alert
- BYOD Mobile Web Agent Detected
- Detection of Encrypted Traffic to Countries
- Multiple SYN packets from Same Source
- Potential HTTP Slow Post DoS
- Detect Port Knocking Packet
- Punycode Phishing Attempt
Investigation Column Group
- Email Analysis Column Group
- Endpoint Analysis Column Group
- Web Analysis Group Column
- Malware Analysis Column Group
- Threat Analysis Column Group
- User and Entity Behaviour Analysis Column Group
Lua Parsers
- Poison_Ivy
- plugx
- rekaf
- struts_exploit
- pvid
- MSU_rat
- CustomTCP
- supercmd
- china_chopper
- apt_artifacts
- cerber
- duqu_lua
- electricfish
- Evilgrab
NetWitness Reports
- Malware Activity Report
- Large Outbound Connections to 3rd Party Sites Sessions
- Large Outbound Encrypted Sessions
- Large Outbound Sessions
- Hunting Summary
- Hunting Detail
- Encrypted Traffic
NetWitness Rules
- Large Outbound Encrypted Sessions
- Large Outbound Sessions
- Malware Activity DNS
- Malware Activity Unidentified
- Malware Activity Web

Microsoft Azure Log Analytics workspace integration with Netwitness

Admin — Thu, 25 May 2023 04:00:00 GMT

Azure Log Analytics workspace is a unique environment for log data from Azure Monitor and other Azure services, such as Microsoft Sentinel, Microsoft Defender and Azure Kubernetes for Cloud. Each workspace has its own data repository and configuration but might combine data from multiple Azure services. Log Analytics can be used to edit and run log queries with the data in Azure monitor logs. With Azure Log Analytics you can easily sort, filter, and provide analysis to a simple query returning a set of records.

NetWitness Platform XDR enables log collection from Azure Log Analytics workspace through the log analytics API. The plugin module which is used to call the API, generates a query to fetch a specific type of log from a specific table. Log analytics workspace can contain logs from different sources and each source might have a different table name. For example, to collect Azure Kubernetes logs, customers should first forward Azure Kubernetes Service (AKS) logs to the Log Analytics workspace (follow the detailed instructions in the plugin documentation below). In NetWitness Platform XDR, the customer should enter the table name as “AzureDiagnostics” and the log types from the list, "kube-apiserver", "kube-audit","kube-audit-admin","kube-scheduler","guard". Make sure that you enter the logs types separated by a comma without any space, example: kube-apiserver,kube-audit. To know more information about Azure Log Analytics workspace integration, please refer to the documentation references provided at the end of this blog.

Integration model:

Events are collected in JSON format. Customers should enable azure parser in NetWitness log decoder to parse the collected events.

Documentation:

1. Log Analytics Plugin Documentation

2. About Log Analytics workspace

Log Collector Package on Netwitness Live: "Log Collector configuration content for event source MS Azure Loganalytics"

Log Parser on Netwitness Live: azure

File Activity Alert Optimization in Multi-EPS Deployment

Admin — Thu, 16 Mar 2023 04:00:00 GMT

In 12.1 and older versions, if a file present on a host such as Host 1 was found malicious or suspicious after performing a YARA scan or an OPSWAT scan, an alert was triggered with YARA alert match or OPSWAT alert match respectively only in that particular host. If the same file is present on multiple hosts such as Host 2, Host 3, and Host 4, the YARA alert match or OPSWAT alert match notifications were not triggered in these hosts.

Instead, the notifications Process with matched YARA rule or Process with OPSWAT reported suspicious/malicious were triggered respectively on multiple hosts every time when the YARA or OPSWAT matched file activities were detected on any Hosts such as Host1, Host2, Host 3, and Host 4. As a result, it was difficult for analysts working on multiple hosts to triage other important alerts as the notifications Process with matched YARA rule or Process with OPSWAT reported suspicious/malicious were frequently triggered and displayed in the UI whenever some YARA or OPSWAT matched file activities were detected on any Hosts such as Host1, Host2, Host 3, and Host 4.

The notifications Process with matched YARA rule or Process with OPSWAT reported suspicious/malicious were triggered even on the new Hosts such as Host 5 or Host 6 whenever some YARA or OPSWAT matched file activities were detected on any Hosts such as Host1, Host2, Host 3, and Host 4.

From 12.2 or later versions, the notifications across multiple hosts are optimized. The alert YARA alert match or OPSWAT alert match is triggered across multiple hosts such as Host 1, Host 2, Host 3, and Host 4 as soon as the file present on any host such as Host 1 is found to be malicious or suspicious after performing a YARA scan or an OPSWAT scan. Later, even if the YARA or OPSWAT matched file activities are detected on any host such as Host 1, the notifications Process with matched YARA rule or Process with OPSWAT reported suspicious/malicious are not triggered in any of the hosts. With this enhancement, the analysts can now triage the alerts appropriately with just one notification of YARA alert match or OPSWAT alert match.

If the malicious file is present in the new host such as Host 5, the alert YARA alert match or OPSWAT alert match is triggered even in the new host as soon as the Endpoint server detects the malicious file in the new host.

To avoid triggering Process with OPSWAT reported suspicious/malicious notifications in the multiple hosts whenever some OPSWAT matched file activities were detected on a particular host, the following Endpoint App rules are deleted.

process with opswat reported infected
process with opswat reported suspicious

To avoid triggering Process with matched YARA rule notifications in the multiple hosts whenever some YARA matched file activities were detected on a particular host, the following Endpoint App rule is deleted.

process with matched yara rule

Threat Profile Series: An Introduction to Royal Ransomware

DarrenMccutchen — Tue, 14 Mar 2023 04:00:00 GMT

Towards the end of 2022, researchers at SOCRadar recognized a relatively new cyber gang, Royal, as the most active ransomware threat. Attacks linked to Royal Ransomware have impacted a diverse pool of victims across many geographical regions and multiple industrial sectors, including healthcare and public healthcare , education, communications, and manufacturing, among others. Recently, the FBI and the Cybersecurity and Infrastructure Security Agency (CISA) released their second joint advisory focused on Royal. Due to increasing activity and the complexity seen in attacks, organizations must place added emphasis on understanding the threat presented by Royal Ransomware.

Over the next few weeks, the NetWitness Threat Research team will be doing a deep dive into the threat actor group. For our first blog post in the series, we will provide an overview of the group/ransomware and touch on some of the key TTPs associated with this cyber gang. In Part 2, we will use NetWitness to analyze several samples of Royal Ransomware and highlight detection opportunities using the platform.

Background and History

Royal Ransomware campaigns began in earnest in September 2022, although there is evidence of the group’s activity dating back as early as January 2022. There are two versions of the malware that have been spotted in attacks. The initial Royal Ransomware payloads were 64 bit Win32 executables written in C++(i). Recently, Royal Ransomware added a Linux encryptor targeting VMware ESXi virtual machines(ii). Artifacts discovered during post breach analysis, including use of specific encryptors and the form of previous ransom notes, suggest the Royal membership may be comprised of individuals with ties to the old Conti ransomware group(iii). The Royal Ransomware operators appear to be an unaffiliated financially motivated group, with ransom payment demands in the tens of millions USD.

Adding to their bona fides as a highly skilled cyber-crime operation, the Royal Ransomware group does not make use of the Ransomware-as-a-Service model, in which affiliates pay to distribute ransomware developed and maintained by another group. Instead, Royal functions as an independent group displaying a proficiency in targeting and penetrating large corporate environments without the use of Initial Access Brokers(i) (There are some indications that tracked group DEV-0569 has purchased access to networks to deliver Royal Ransomware(iv)). In most Royal Ransomware attacks, access was gained using callback phishing, a social-engineering technique where victims contact a phone number included in an email and, after direct interaction with the attacker, are ultimately convinced to install malware masquerading as legitimate software. Other methods used to drop Royal Ransomware on victim systems include exploiting vulnerabilities on public facing applications, weaponizing business contact forms to spam companies with malicious links, placing bogus install files on popular file download sites, and, increasingly, malvertising via Google Ads.

Prior to encryption, the Royal Ransomware gang exfiltrates sensitive data from victim networks. It then uses the potential release of this information to entice companies to pay the ransom (a technique called double extortion). To put additional pressure on its' targets, the Royal group will drum up media coverage by using compromised Twitter accounts to contact journalists and news organizations and alert them to newly successful attacks.

In the News

Nov-2022: Royal Ransomware operators posted evidence of breaching Silverstone Circuit, an English motor racing circuit and home of Formula One's British Grand Prix, to its leak site(v).
Dec-2022: In Travis County, Texas, the Travis County Appraisal District, responsible for assessing the appraisal values of all property in the county, attributed a successful ransomware attack to the Royal Ransomware threat group(vi). The attack shut down phone lines, email access, and network connectivity for multiple days.
Dec-2022: American telecommunications company Intrado was added to the Royal Ransomware threat actors leak site(vii). The post alluded to the gang taking "internal documents \ passports \ employee driver's licenses" from Intrado's network. It is believed that the ransomware was responsible for a large outage in early December.

Technical Summary

Windows Variant

As discussed earlier, Royal Ransom group employs an assortment of methods to obtain initial access to target infrastructure. To begin its infection chain, Royal Ransomware accepts the following command line arguments(viii):

-id: A 32-character alphanumeric value used to identify the compromised host. This argument is required and if omitted, prevents the ransomware from running.

-path: Allows the operator to specify a path to be encrypted. This argument is not required when initiating the malware.

-ep: A number from between 0 and 100 representing the percentage of the file to be encrypted. If not specified, Royal will default to 50% encryption for files larger than 5.245 MB (Files smaller than 5.245 MB will be 100% encrypted). This argument is also optional and not required for successful execution.

Royal Ransomware operators use numerous legit open-source tools and Windows utilities to further entrench themselves in victim networks. The group has been observed using remote management software like AnyDesk and Atera Agent to maintain persistence(ix). PowerSploit, a penetration testing framework made up of Powershell modules, allows Royal Ransomware threat actors to gain Administrator rights. Royal actors can achieve lateral movement via Microsoft Sysinternals' PsExec tool or discovered RDP credentials. The group can use NirCMD to stealthily run CMD commands directly on hosts machines. To discover domain members/groups, available network shares, and identify other network systems, Royal Ransomware attacks have utilized ADFind and Netscan from compromised domain controllers. As mentioned in the FBI/CISA Joint Cybersecurity Advisory, Royal operators have also used an SSH secured HTTP tunneling tool named Chisel to conduct C2 communication.

In addition to open-source tooling, groups distributing Royal have packaged the ransomware with other prominent malware families. In a few attacks, BATLOADER was used as the delivery mechanism Royal Ransomware payload(x). The FBI has seen Ursnif/Gozi used to facilitate data exfiltration during Royal Ransomware attacks. Qakbot has also been found on systems preceding Royal ransom infections(xi).

Prior to encrypting files and drives, Royal Ransomware takes several actions to hamper system defenses. If any encryption target files are in use by other processes, Royal will use Windows RestartManager to stop the desired applications/services. As is standard amongst many ransomware families, Royal attempts to prevent system recovery by using vssadmin Windows utility to silently delete all the available shadow copies. The malware can also disable antivirus using the system management tool Nsudo(xii).

Once the environment is staged and data has been retrieved, Royal Ransomware begins encryption. Royal uses multi-threaded encryption, a technique where the malicious payload accelerates time to encryption by launching multiple child processes(iv). This technique also makes stopping an ongoing ransomware attack more difficult. Earlier versions of Royal Ransomware borrowed its encryptors from BlackCat Ransomware. Over time, the threat group developed their own encryptor, Zeon, using the OpenSSL AES algorithm. A public key hardcoded in the malicious binary is used to encrypt both the private key and Initialization Vector. All encrypted files are appended with '.royal' and a copy of the ransom note 'README.TXT' is placed in every directory containing encrypted data. The Royal ransom note, somewhat uniquely, does not contain any ransom demands, instead directing the victims to a TOR hosted chat application interface for further instructions.

Linux Variant

Royal Ransomware's Linux variant seems to be early in its development. There are certain key differences from the Win32 version. For the Linux based version of Royal Ransomware targeting ESXi servers, the launch arguments are slightly different. While the -id argument is still required and the -ep can still be used to specify encryption percentage, the -path argument has been replaced by 4 other optional arguments(xiii): -stopvm terminates VMs running on the target system with ESXCLI tool, -fork tells the ransomware to fork itself and move processing to the newly created child process, -log shows the logs of encrypted files, and a presently unimplemented -vmonly option. The Linux variant must still be executed from the command line; however the attacker must specify a target folder to ensure full encryption. Linux Royal does not set an exclusion list before encryption, but a searching function does exist as the malware recursively works its way through target directories preventing "double encryption,", or encryption of some core VM files ('.sf', '.v00', and '.b00' extensions), encryption of the log file generated by the -log command line argument, and encryption of the ransom note. Based on Fortinet's analysis of a Linux based sample, this may indicate the "ransomware is executed either manually or by a dropper program that specifies which folders should be encrypted". Instead of '.royal' extension being appended to encrypted files, '.royal_u' ('u' potentially designates a Unix system) postfix is used.

Conclusion

The Royal Ransomware group seems well suited to continue growing its list of victims for the foreseeable future. With several approaches to gain access to victim systems, employment of various anti-analysis and defense evasion tactics, ability to deliver and use different open-source tooling, and their usage of partial encryption via a proprietary encryptor, Royal operators can adapt attacks to get around even the best cyber defenses. The NetWitness Threat Research team’s investigation into this threat is ongoing and we will continue monitoring for any new developments. In the meantime, several pieces of content are currently available in NetWitness Live related to Royal Ransomware operations:

Logs:

Nircmd for Command Execution (Logs)
Scheduled Tasks via schtasks.exe (Logs)
Stop/Kill Multiple Processes - NET.exe (Logs)
Stop/Kill Multiple Processes - SC.exe (Logs)
Stop/Kill Multiple Processes - TASKKILL.exe (Logs)

Endpoint:

Deletes shadow volume copies
Nircmd for Command Execution (Endpoint)
NSudo Trusted Installer from Command Line
Royal Ransomware Launch Arguments
Scheduled Tasks via schtasks.exe (Endpoint)
Stop/Kill Multiple Processes - NET.exe (Endpoint)
Stop/Kill Multiple Processes - SC.exe (Endpoint)
Stop/Kill Multiple Processes - TASKKILL.exe (Endpoint)

In upcoming weeks, please be on the lookout for our follow-up Royal Ransomware post where we’ll investigate an attack with NetWitness.

MITRE

Technique	Name	Technique	Name
T1190	Exploit Public Facing Application	T1083	File and Directory Discovery
T1566	Phishing	T1057	Process Discovery
T1133	External Remote Services	T1135	Network Share Discovery
T1105	Ingress Tool Transfer	T1021.001	Remote Desktop Protocol
T1059	Command and Scripting Interpreter	T1572	Protocol Tunneling
T1053.005	Scheduled Task	T1486	Data Encrypted for Impact
T1569.002	Service Execution	T1490	Inhibit System Recovery
T1562.001	Disable or Modify Tools	T1489	Service Stop

References

(i) - https://www.hhs.gov/sites/default/files/royal-ransomware-analyst-note.pdf

(ii) - https://twitter.com/BushidoToken/status/1621087221905514496?cxt=HHwWgIDTuamPof8sAAAA

(iii) - https://twitter.com/VK_Intel/status/1557003350541242369

(iv) - https://www.blackberry.com/us/en/solutions/endpoint-security/ransomware-protection/royal-ransomware

(v) - https://cybernews.com/news/silverstone-formula-one-ransomware/

(vi) - https://www.statesman.com/story/news/2022/12/05/travis-county-tx-home-appraisals-ransomware-attack/69703419007/

(vii) - https://www.bleepingcomputer.com/news/security/royal-ransomware-claims-attack-on-intrado-telecom-provider/

(viii) - https://www.cybereason.com/blog/royal-ransomware-analysis

(ix) - https://www.kroll.com/en/insights/publications/cyber/royal-ransomware-deep-dive

(x) - https://www.microsoft.com/en-us/security/blog/2022/11/17/dev-0569-finds-new-ways-to-deliver-royal-ransomware-various-payloads/

(xi) - https://www.trendmicro.com/en_us/research/22/l/conti-team-one-splinter-group-resurfaces-as-royal-ransomware-wit.html

(xii) - https://blog.polyswarm.io/royal-ransomware

(xiii) - https://www.trendmicro.com/en_us/research/23/b/royal-ransomware-expands-attacks-by-targeting-linux-esxi-servers.html

Netwitness Security LLC blog

Netwitness Platform Integration with AWS Application Load Balancer Access logs

The Sky Is Crying: The Wake of the 19 JUL 2024 CrowdStrike Content Update for Microsoft Windows and We Should Take Away From It

DDoS using BotNet Use Case

Introduction

Botnet

Attack Walkthrough

1st bot (Ubuntu)

2nd bot (CentOS 7)

Analysis

Rule Creation

HYDRA Brute Force

INTRODUCTION

Brute Force

HYDRA Attack

AS-REP Attack

Analysis (Brute Force)

Analysis (AS-REP)

Possible Rules to Detect for SSH Brute Force

ESA Rule

Rule Syntax

Rule Test

Rule syntax

Rule Test

A Closer Look at Advanced EPL (ESA) Through a Rule and its Components

Context

Memory Management

Future Enhancements

Example

Summary

FirstWatch Threat Spotlight – Remcos RAT

Content Hygiene – Application Rule Alert Mapping Updates

Updated Application Rules:

Removed Content

Microsoft Azure Log Analytics workspace integration with Netwitness

File Activity Alert Optimization in Multi-EPS Deployment

Threat Profile Series: An Introduction to Royal Ransomware

Background and History

In the News

Technical Summary

Windows Variant

Linux Variant

Conclusion

MITRE

References

1^st bot (Ubuntu)

2^nd bot (CentOS 7)