Viry a Červi

The idea of creating Web 3.0 has been around since the end of 2000s. The new version of the world wide web should repair the weak points of Web 2.0., some of which are: featureless content, prevalence of proprietary solutions, and lack of safety in a centralized user data storage environment, where a massive leak is likely should just one server be compromised. Web 3.0 is described as a decentralized and open internet — some of its features already implemented in today’s digital world.

Unfortunately, the “new internet” will still remain a playground for criminals who will employ cutting-edge technologies for their old sport of data theft, financial machinations and the like. In this article, I will dwell on how they use one of the WEB 3.0 technologies — the distributed file system IPFS — for email phishing attacks.

What is IPFS?

IPFS (InterPlanetary File System) is a peer-to-peer distributed file system enabling users around the world to exchange files. Unlike centralized systems, IPFS uses addressing performed according to unique content identifiers (CID), and not file paths. CID is generated based on the file’s hash value and then recorded to a distributed hash table, which also contains information on the file owner. The file itself resides on the computer of the user who had “uploaded” it to IPFS, and is downloaded directly from that computer. The structure of IPFS is somewhat similar to the BitTorrent protocol which, too, is a distributed network where file exchange takes place directly between the users’ devices.

By default, uploading a file to IPFS or downloading it requires special software (IPFS client). For users to view the files residing in IPFS freely without installing any software, the so-called gateways are provided. A gateway is in fact a server with access to IPFS. To open a file via a gateway, a URL is required normally containing a gateway address, reference to IPFS, and the file’s CID. URL formats can be quite different, for example:

• https://gateway_address/ipfs/CID
• https://CID.ipfs.gateway_address

Phishing and IPFS

In 2022, scammers began actively using IPFS for email phishing attacks. They would place HTML files containing a phishing form in IPFS and use gateways as proxies, so that victims could open the file, whether or not running an IPFS client on their devices. The scammers would include file access links via a gateway into phishing letters dispatched to would-be victims.

The use of a distributed file system allows attackers to cut back on phishing page hosting costs. Besides, you cannot delete files uploaded by third parties from IPFS. If somebody wants a file to disappear from the system completely, they can urge its owners to delete it, but the method will probably never work with cybercriminals anyway.

IPFS gateway providers attempt to combat IPFS phishing by regularly deleting links to fraudulent files.

Phishing page deletion notification

Yet detection and deletion of links at gateway level does not always happen as quickly as the blocking of a phishing website, cloud form, or document. We have observed URL addresses of IPFS files that first appeared in October 2022 and remain operational at the time of this writing.

Phishing letters containing IPFS links are hardly ever too original — they contain the typical phishing content the purpose of which is to obtain the victim’s account login and password.

Phishing letter with an IPFS link

It is a bit more interesting to examine the HTML pages the links lead to.

HTML page used for phishing

As can be seen on the screenshot above, the URL parameter contains the recipient’s e-mail address. Once it is modified, the page content will change too: the corporate logo on top of the phishing form and the email address entered into the login field. In this way, one link can be used in several phishing campaigns targeting different users — sometimes even in dozens of campaigns.

Phishing page modification

The logo replacement effect is achieved using a simple JavaScript code. The script obtains domain info from the page URL parameter and substitutes it into the URL of the Google resource, from which a logo icon is then sourced.

Company logo substitution

Use of IPFS in targeted phishing attacks

The use of IPFS is not limited to mass mailing campaigns: it is used for complex targeted attacks too. Unlike the ordinary ones, targeted phishing campaigns are much better prepared, normally focusing on specific persons within the company, not just random users.

Targeted phishing with an IPFS link

In the two examples above, the attacks were leveled at corporate procurement departments, the letters coming from sales managers of existing organizations. The phishing page itself lacks in originality.

Phishing page used in a targeted attack

Statistics

In late 2022, we were observing 2–15 thousand IPFS phishing letters a day for most of the time. But there were quieter days too. Thus, our systems registered only 637 such letters on December 1, and 937 on December 23. Starting this year, IPFS phishing began to grow in scale. We observed a few upsurges in January and February with over 24,000 letters a day — with peaks reaching 34–37 thousand/day. However, the flurry has died down little by little by mid-February, the number of attacks mostly returning to November and December levels.

Dynamics of the number of IPFS phishing attacks, November 2022 — February 2023 (download)

Yet it is worth noting that February turned out the busiest month in terms of IPFS phishing activity. In that month alone, we observed almost 400,000 letters — more than 20,000 above the January figure, and over 100,000 more than in November and December 2022.

IPFS phishing letters distribution by month, November 2022 — February 2023 (download)

Conclusion

Attackers have used and will continue to use cutting-edge technologies to reap profits. Of late, we observe an increase in the number of IPFS phishing attacks — both mass and targeted. The distributed file system allows scammers to save money on domain purchase. Plus, it is not easy to completely delete a file, although, there are attempts to combat fraud at IPFS gateway level. The good news is that anti-spam solutions detect and block links to phishing files in IPFS, just like any other phishing links. In particular, Kaspersky products employ a number of heuristics to detect IPFS phishing.

Admin-level holes in websites are always a bad thing... and for "bad", read "worse" if it's an e-commerce site.

Not a headline we expected to write today

American cybersecurity officials have released an early-warning system to protect Microsoft cloud users.…

Getting connection failures? Don't panic. Get new keys

GitHub has updated its SSH keys after accidentally publishing the private part to the world. Whoops.…

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.

Principles of success

Apart from revenue and profits, there are two key principles that drive business success:

• Maintaining business operations to achieve the desired outcomes
• Continually improving by bringing in new ideas or initiatives that support the overall goals of the business

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.

Measuring routine operations

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.

Measuring improvement

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:

• In the IT world the principle of “if it’s not broken, don’t fix it” is well known, and this mentality extends to operational units as well. Similarly, many SOCs prioritize current operations and only implement changes in response to issues rather than adopting a continuous improvement approach. This reluctance to change acts as a bottleneck for achieving continuous improvement.
• Absence of a structured process to gather ideas for potential improvements results in only a fraction of these ideas being presented to the SOC management, and thus, only a fraction of them being implemented.
• Absence of progress tracking for improvements – it’s not sufficient to simply generate and discuss ideas. Implementing ideas requires diligent monitoring of their progress and measuring their actual impact.

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.

Metric identification and prioritization

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:

• Metrics must be aligned with the primary goals and operational objectives
• Metrics should assist in the decision-making process
• Metrics must demonstrate their purpose and value to both internal operations and external stakeholders.
• Metrics should be realistically achievable in terms of data collection, data accuracy, and reporting.
• Metrics must also meet the criteria of the SMART (Specific, Measurable, Actionable, Realistic, Time-based) model.
• Ideally, metrics should be automated to receive and analyze current values in order to visualize them as quickly as possible.

Liberté, égalité, reconnaissance faciale for all

Despite the opposition of 38 civil society groups, the French National Assembly has approved the use of algorithmic video surveillance during the 2024 Paris Olympics.…

'Hunt forward' teams of this sort aid with defense and learn how attackers like Tehran operate

US Cyber Command operators have confirmed they carried out an online defensive mission in Albania, in response to last year's cyber attacks against the local government.…

Security researchers find bugs, big and small, in every industrial box probed

Devices used in critical infrastructure are riddled with vulnerabilities that can cause denial of service, allow configuration manipulation, and achieve remote code execution, according to security researchers.…

Listen now - latest episode. Full transcript inside.

Protection from business email compromise

Webinar  In the distant past, a master forger with a quill could fake a signature on the end of a letter but at least then you had time to consider the potential for fraud before any damage could be done. In the digital age of email, it's increasingly hard to spot a scam's threat to your security and react in time.…

Terminal maker General Bytes shutters its cloud business after second breach in seven months

Unidentified miscreants have siphoned cryptocurrency valued at more than $1.5 million from Bitcoin ATMs by exploiting an unknown flaw in digicash delivery systems.…

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.

Why defining your workflow is a vital prestage of playbook development

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:

• preparation,
• detection and analysis,
• containment, eradication, and recovery,
• post-incident activity.

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

1. Be prepared to process incidents

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.

2. Create a comfortable track for investigation

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

3. Containment is one of the most important phases to minimize incident consequences

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

4. Lessons learned, or required post-incident actions

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:

• How well did the incident response team manage the incident?
• What information was the first to be required?
• Could the team have done a better job sharing the information with other organizations/departments?
• What could the team do differently next time if the same incident occurred?
• What additional tools or resources are needed to help prevent or mitigate similar incidents?
• Were there any wrong actions that had caused damage or inhibited recovery?

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.

Summary: components of a good playbook

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:

• logging;
• enriching the inventory information or telemetry of affected assets or reputation of external resources;
• incident containment through host isolation, preventing malicious file execution, URL blocking, termination of active sessions, or disabling of accounts;
• cleaning up the traces of intrusion by deleting remote files, deleting suspicious services, or scheduled tasks;
• recovering the system’s operational state by revoking changes;
• formalizing lessons learned by creating a new article in the local knowledge base for later reference.

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.

All aboard the chatbot hype train! Next stop: Fraud

Google has removed a ChatGPT extension from the Chrome store that steals Facebook session cookies – but not before more than 9,000 users installed the account-compromising bot.…

Didn't disclose payments as mastermind pumped up value of tokens with fake trades

Eight very B-list celebrities have agreed to cough up fines after being accused of shilling a cryptocurrency without disclosing they were paid to do so, while the chap who apparently paid them has been charged with fraud.…

British American Tobacco, Samsung, also burgered up their infosec

South Korea's Personal Information Protection Commission has fined McDonald's, British American Tobacco, and Samsung for privacy breaches.…

Maybe this is deserved given the problem's in a hidden telnet service

Public proof-of-concept exploits have landed for bugs in Netgear Orbi routers – including one critical command execution vulnerability. …

Now that's a flash bang

Police in Ecuador are investigating attacks on media organizations across the country after a journalist was injured by an exploding USB flash drive.…

Turns out that the Windows 11 Snipping Tool has the same "aCropalypse" data leakage bug as Pixel phones. Here's how to work around the problem...

Country's super strong data rights under magnifying glass after half a dozen complaints filed

Remember the Who Targets Me browser extension from privacy activists at Noyb? The group yesterday filed explosive complaints based on log records from the extension that claim six of Germany's political parties broke European data law when they targeted voters on Facebook's adtech platform.…

If this is Kyiv's work, Russia can Crimea river

A cyber espionage campaign targeting organizations in Russian-occupied regions of Ukraine is using novel malware to steal data, according to Russia-based infosec software vendor Kaspersky.…