Impact of Ukraine-Russia war: Cybersecurity has improved for all

Comment

Gift Article

SAN FRANCISCO — Russia’s cyberspace attacks on Ukraine during the past year have erased data, degraded communication and stolen information, but they have fallen far short of the destruction that many predicted after the invasion a year ago.

In fact, the campaign may have helped inoculate Ukraine against more devastating attacks, experts say, by revealing Russian tactics when the stakes were highest, proving the value of faster collaboration and other defensive measures, and destroying the myth of Russia as an unstoppable cyber superpower.

“We are not only better prepared, we are able to share our lessons learned,” said George Dubynskyi, deputy minister for security in Ukraine’s Ministry of Digital Transformation.

That is resonating in Europe and the United States, which have worked closely to protect Ukraine and now are importing strategy and intelligence in defense of their own cyber networks.

“The Russian invasion did prompt greater cyber cooperation between the U.S. and key allies, particularly in Eastern Europe,” said Brandon Wales, executive director of the U.S. Cybersecurity and Infrastructure Security Agency (CISA) and coordinator of the American interagency defensive response. “When it comes to work across domestic critical infrastructure sectors, the war turbocharged the operational collaboration that we had kicked off.”

Ukraine had good reason to expect the worst. Russia had used innovative attacks on specialized software controls to cut power to swaths of the country during the winters of 2015 and 2016, and it had continued to use its rival as a proving ground with the release of NotPetya, a wildly destructive software that spread through a Ukrainian tax program and caused $1 billion in damages. The United States has indicted six Russian intelligence officers in those attacks.

That heightened sense of danger helped. U.S. intelligence agencies and multiple big American tech companies worked closely with Ukraine for years, sharing information on new threats and working through a list of best practices inside critical facilities, such as two-factor authentication, good offline backups and the use of multiple cloud vendors accessible from anywhere.

Ukrainian authorities installed better hardware and software, and passed legislation to give its regulators more power and increased flexibility to protect the data it keeps on citizens, Dubynskyi told The Washington Post.

“One week before the invasion, we were able to store copies in the cloud. It was a breakthrough,” Dubynskyi said. “We were able to move our critical data abroad to Amazon AWS, Microsoft Azure, Oracle and other vendors, without any formalities.”

The result wasn’t an airtight architecture, and some attacks got through. Russia beefed up its phishing attacks via social media and used stolen accounts of associates to better target individuals inside the government. But restricting access to a limited number of users who had physical tokens as a second authentication factor helped avoid disaster.

Russia deployed a variety of destructive programs known as data wipers through other means, and it stole passport data from border stations that it could use to track Ukrainians. It also hacked the satellite communication system Viasat, which the military used, and sidelined the Turkish-made Bayraktar drones whose successes against the invaders in the early months of the war were celebrated in widely circulated videos. Google disclosed the hack this month but did not specify what stolen information the Russians used to defeat the drones.

It also combined cyberattacks and physical explosions to force internet traffic through infrastructure it controlled.

“They cut optical fibers and they destroyed cell towers to deprive people of access to Ukraine’s digital space, to switch them to Russian digital space,” Dubynskyi said. “When you have no digital space, cybersecurity is useless.”

A direct appeal to Elon Musk brought Starlink terminals into the country and helped preserve internet access for most of the country, he said.

Russian government and allied criminal hackers have tried to break into most Ukrainian ministries, and in some cases succeeded, most recently through back doors that were set up before the war.

Russia and its allied groups, some posing as patriotic hacktivists, have claimed all manner of leaks of government documents. Most are fakes or exaggerations, but not all. Its other propaganda campaigns, also waged online, have been extensive and continue around the world.

Some propaganda has been boosted by networks of automated social media accounts for hire, which have helped propel #ZelenskyWarCriminal briefly into Twitter Trending lists in the United States, France, Italy and other countries. Some of the same accounts also touted cryptocurrencies and, more recently, Nigerian presidential candidate Peter Obi, according to researchers at the nonprofit group Reset.

But Russia’s biggest attempt to knock out Ukraine’s power again, with a version of the specialized software used against industry targets in 2016, was caught by security software because it reused too much of the earlier code.

Other private software caught more intrusions, in part by checking for unusual behavior. Dubynskyi praised Microsoft, Google and Cloudflare for their help, stemming partly from their analysis of vast activity by users. He noted it was in their interest to see what was happening in Ukraine and apply that to protect customers worldwide.

Microsoft set up a 24-hour secure hotline so that when it detected an attack in progress, its corporate vice president for security, Tom Burt, could call top Ukraine defenders immediately.

Burt said the company’s practice was to notify all targets of state-backed hacking attempts but that the hotline and personal touch “is kind of a white-glove notification” for war-related attacks that now has been extended to NATO and some NATO governments.

Like Dubynskyi, Burt warned that Russia is continuing to try new techniques. But they are doing so under a microscope: “We are learning more about how these actors operate and how they evolve their response.”

The U.S. government has helped by bringing the fight to criminal ransomware groups, some of which had turned their attention to Ukrainian targets. Arrests, takedowns and seizures disconcerted some in that shadow economy, and sanctions cut off some of their income, sending total collections down.

“The sanctions have made it hard to actually pay these guys,” said Billy Leonard, Google’s head of analysis for government threats.

Officials in the United States are applying what worked in Ukraine to their own cybersecurity efforts. Wales said the two-year-old Joint Cyber Defense Collaborative (JCDC), which includes big cloud, communications and security providers, is sharing more intelligence, including some that gets declassified within a day.

“We were able to get information within hours from initial infections in Ukraine, where JCDC members were sharing and using it inside of their systems, to protect hundreds of thousands of critical infrastructure operations around the United States,” Wales said.

Like Ukraine’s wider outreach efforts, CISA is now focusing on what it calls “target rich, cyber poor” sectors of the economy, protecting the hospitals, schools and local governments that have been battered by ransomware in the past few years.

Perhaps most importantly, CISA has seized on the lesson from Ukraine’s resiliency that proved doing the basics is much better than doing nothing, Wales said.

“Slow and steady, they made improvements in their security architecture, and they benefited from Western support, including the private sector,” he said. “Nation-states do have a lot of cyber capability, but you can make it harder.”

One year of Russia’s war in Ukraine

Portraits of Ukraine: Every Ukrainian’s life has changed since Russia launched its full-scale invasion one year ago — in ways both big and small. They have learned to survive and support each other under extreme circumstances, in bomb shelters and hospitals, destroyed apartment complexes and ruined marketplaces. Scroll through portraits of Ukrainians reflecting on a year of loss, resilience and fear.

Battle of attrition: Over the past year, the war has morphed from a multi-front invasion that included Kyiv in the north to a conflict of attrition largely concentrated along an expanse of territory in the east and south. Follow the 600-mile front line between Ukrainian and Russian forces and take a look at where the fighting has been concentrated.

A year of living apart: Russia’s invasion, coupled with Ukraine’s martial law preventing fighting-age men from leaving the country, has forced agonizing decisions for millions of Ukrainian families about how to balance safety, duty and love, with once-intertwined lives having become unrecognizable. Here’s what a train station full of goodbyes looked like last year.

Deepening global divides: President Biden has trumpeted the reinvigorated Western alliance forged during the war as a “global coalition,” but a closer look suggests the world is far from united on issues raised by the Ukraine war. Evidence abounds that the effort to isolate Putin has failed and that sanctions haven’t stopped Russia, thanks to its oil and gas exports.

Loading…

Move over, Jamtara. Most fake customer care numbers registered in Bengal, says cyber firm study

Move over, Jamtara. Most fake customer care numbers registered in Bengal, says cyber firm study

New Delhi: Any discussion about the notoriety of cyber criminals in India is incomplete without the mention of Jharkhand’s Jamtara. So much so that the district has an OTT series named after it. But a fresh analysis of an estimated 20,000 fake customer care numbers suggests West Bengal may be gradually emerging as a hub of fake call centres.

Published on 24 February, the report by Bengaluru-based cybersecurity firm CloudSEK shows that the “top three” fake numbers operational roughly for a period of more than 600 days were traced to West Bengal.

“Kolkata served as the centre for many large-scale operations,” read the report, adding that around 23 per cent of the total fake customer care numbers analysed were registered in West Bengal.

Delhi and Uttar Pradesh tied for the state with the second most registered fake numbers, together accounting for about 19 per cent of the total. Clubbed together in the report, Bihar and Jharkhand accounted for about 7.3 per cent of fake numbers analysed.

Illustration: Ramandeep Kaur | ThePrint
Illustration: Ramandeep Kaur | ThePrint

However, the report added, “while the numbers are registered in these regions, they may be used from different locations to target victims across India”.

The report comes amid renewed efforts by the Telecom Regulatory Authority of India (TRAI) to curb spam calls and messages or unsolicited commercial communications (UCC).

According to a press release dated 17 February, TRAI in a meeting with representatives of major telecom companies (telcos) directed them to review the “menace” of UCC and “curb the misuse” of messages and calls from “unauthorised or unregistered telemarketers”.

The regulator also asked major telcos to get registered telemarketers to join the DLT-based (distributed ledger technology) platform, allowing both to monitor the telemarketers’ activity better. Though TRAI has been trying since 2018 to get telemarketers and any business owners who wish to send commercial messages, to register themselves on the DLT-based platform, its efforts haven’t fully succeeded so far.

The analysis by CloudSEK found that, of the “top three fake customer care numbers detected”, “+918116494943” was used to impersonate fashion outlets and financial businesses. According to the caller ID app Truecaller, the number belongs to one “Avinash Kumar”.

The other two numbers are “+917001088584” and “+918697355745” — which belong to “Sipahi Sahni” and “Mitra Pvt Ltd”, respectively. These have been used in the past to impersonate representatives offering banking services.

Fake customer care numbers, says the report, are an “apt modern-day phishing technique” because people instinctively feel they can trust an agent trying to help them solve problems and also because “people tend to be ignorant while engaging with customer care numbers”.

Of the 31,179 fraudulent numbers found by CloudSEK, some were active for more than two years, which is unusual given that most fraudsters tend to change their numbers regularly to avoid detection. Of these numbers, at least 17,285 were of Indian origin.

The report also said that of all the numbers of Indian origin, 80 per cent are still operational and that the period between 10 am and 5 pm was the “preferred calling time for scammers” targeting Indian customers. It also found that a single fake number is used to make an average of 30 calls each day.

For the analysis, CloudSEK also analysed 8,41,486 calls (both standard calling and calls via internet) linked to 470 fake numbers. Around 47 per cent of the over 8 lakh calls were answered.


Also Read: Mewat is India’s latest Jamtara. And sextortion is the new kill


Fraudsters rely on ‘social engineering’

A typical fake customer care scam is conceived when a fraudster uses a fake identity to purchase ‘burner’ sim cards that are untraceable and easy to dispose of. The fake numbers are then promoted on social media, websites, and “advertisements to get a wider reach” on search engines.

Unwitting customers searching for a customer care number online may stumble across one of these fake numbers and dial it in search of help. 

For the next part of this scam, fraudsters rely on “social engineering” — building a relationship with the target by citing seemingly valid reasons to gain access to the target’s financial information and OTPs.

“Generally, scammers try to leverage impersonation and the fear factor to collect money from the victims,” said the report by CloudSEK.

Advertisement for fake sim card on dark web | Courtesy: CloudSEK report
Advertisement for fake sim card on dark web | Courtesy: CloudSEK report

It added that fraudsters use similar names, logos, and website domain names to impersonate a real business. They then access the target’s bank account and purchase gift cards or transfer money to their own accounts.

Businesses most impersonated were those in the banking and finance sector, followed by healthcare and telecommunications.

Fraudsters rely largely on social media, mostly Facebook, to propagate their fake numbers, links to their phishing website, or to fraudulent WhatsApp or Telegram accounts created to lure victims. “88% (15,271) of the fake customer care numbers were distributed via Facebook advertisements, posts, profiles, and pages… Despite Facebook claiming to have taken down close to 2 billion fake accounts per quarter, scammers continue to flood Facebook with fake profiles and pages,” the report said.

Twitter and Google were other channels used by fraudsters to promote fake numbers.

Fake customer care number advertised on Google | Courtesy: CloudSEK report
Fake customer care number advertised on Google | Courtesy: CloudSEK report

The report also found that at least 6,118 of the fake numbers analysed were active for less than 30 days and around 881 were active for 485-623 days. The fraudsters, it added, were using “sophisticated tactics to evade detection” such as changing the domain name of their website or where the phone number was posted for targets to see.

It also found that apart from targeting customers in India, fake numbers were also used to make 214 calls to potential targets in Dubai.

(Edited by Amrtansh Arora)


Also Read: Why are cybercrime convictions low in India? ‘Weak forensics, dark net & cross-border attacks’


XSS (Cross-Site Scripting)- Explained In Layman’s Term

XSS (Cross-Site Scripting)- Explained In Layman’s Term


In this blog, you will learn

  • What is XSS?
  • How does XSS works?
  • What are the types of XSS?
  • How to find and test for XSS?
  • Impact of XSS
  • How to prevent XSS attacks?
  • References

  • Cross-site scripting (also commonly known as XSS) is a web application vulnerability that allows an attacker to compromise the interaction that users have with a vulnerable web application. It allows attackers to bypass the security measures put in by the developers to avoid the XSS attack.

  • XSS vulnerabilities enable malicious actors( or attackers) to inject malicious code (client-side scripts) into web pages viewed by users. Once executed on the user’s browser, this code could then perform actions such as changing the behavior or appearance of the website, stealing sensitive data, performing actions on behalf of the user, and more.

  • The root cause of XSS vulnerability arises from the failure to properly validate user input before processing, allowing the client-side script (commonly JavaScript) to be injected in a manner that will enable it to execute. Therefore, your application is at risk of XSS vulnerability wherever it handles user input.


Cross-site scripting works by manipulating a vulnerable website so that it returns malicious JavaScript to users. When the malicious code executes inside a victim’s browser, the attacker can fully compromise their interaction with the application.

When a web application is vulnerable to this type of attack, it will pass unvalidated input; sent through requests, back to the client(or user). The common methodology of the attack includes a design step in which the attacker creates and tests the malicious URL, a social engineering step in which the attacker convinces the victims to load the URL on their browsers, and then the execution of the malicious code using the victim’s browser.

Commonly the attacker’s code is written in the JavaScript language, but other scripting languages are also used, e.g., ActionScript, VBScript, and XSS. Attackers typically leverage these vulnerabilities to install key loggers, steal victim cookies, perform clipboard theft, and change the content of the page (e.g., download links).


There are three main types of XSS attacks. These are:

  1. Reflected XSS
  2. Stored XSS
  3. DOM-based XSS

Reflected cross-site scripting

Non-persistent (reflected) XSS is the most common type of cross-site scripting. Just as the name implies, reflected XSS occurs when the injected malicious script results show up or are immediately reflected by the user without adequately sanitizing the content.

  • Here is a simple example of a reflected XSS vulnerability:
  • The application doesn’t perform any other processing of the data, so an attacker can easily construct an attack like this:

If the user visits the URL constructed by the attacker, then the attacker’s script executes in the user’s browser, in the context of that user’s session with the application. At that point, the script can carry out any action, and retrieve any data, to which the user has access.

Stored cross-site scripting

Stored XSS is also known as persistent or second-order XSS. This is a more devastating variant of a cross-site scripting flaw. It occurs when the data provided by the attacker is saved by the server at the database and then permanently displayed on “normal” pages to the other users in the course of regular browsing, without proper HTML escaping.

The data in question might be submitted to the application via HTTP requests; for example, comments on a blog post, user nicknames in a chat room, or user details on a user profile. In other cases, the data might arrive from other untrusted sources; for example, a webmail application displaying messages received over SMTP, or a marketing application displaying social media posts.

  • Here is a simple example of a stored XSS vulnerability. A message board application lets users submit messages, which are displayed to other users:

<p>Hello, this is my message!</p>

  • The application doesn’t perform any other processing or sanitizing of the data before displaying it to the user, so an attacker can easily send a message that attacks other users:

<p><script>/* Bad stuff here… */</script></p>

DOM cross-site scripting

DOM XSS occurs when the injected malicious code does not get to the web server. Instead, it is reflected by client-side JavaScript code on the client-side.

DOM-based XSS vulnerabilities usually arise when JavaScript takes data from an attacker-controllable source, such as the URL, and passes it to a sink that supports dynamic code execution, such as eval() or innerHTML. This enables attackers to execute malicious JavaScript, which typically allows them to hijack other users’ accounts.

To deliver a DOM-based XSS attack, you need to place data into a source so that it is propagated to a sink and causes the execution of arbitrary JavaScript.

In the following example, an application uses some JavaScript to read the value from an input field and write that value to an element within the HTML:

var search = document.getElementById(‘search’).value;
var results = document.getElementById(‘results’);
results.innerHTML = ‘You searched for: ‘ + search;

If the attacker can control the value of the input field, they can easily construct a malicious value that causes their own script to execute:

In a typical case, the input field would be populated from part of the HTTP request, such as a URL query string parameter, allowing the attacker to deliver an attack using a malicious URL, in the same manner as reflected XSS.

  • To summarize all three types:
    • Reflected XSS, where the malicious script comes from the current HTTP request.
    • Stored XSS, where the malicious script comes from the website’s database.
    • DOM-based XSS, where the vulnerability exists in client-side code rather than server-side code.

There are many process for finding and testing XSS but the most grounded method (according to me) is manual testing and the best way to do manual testing is reviewing/ understanding the code, So in this blog we will be looking at the manual testing for reflected, stored and Dom based XSS.

Manually testing for reflected and stored XSS normally involves submitting some simple unique input (such as a short alphanumeric string) into every entry point in the application, identifying every location where the submitted input is returned in HTTP responses, and testing each location individually to determine whether suitably crafted input can be used to execute arbitrary JavaScript. In this way, you can determine the context in which the XSS occurs and select a suitable payload to exploit it.

Manually testing for DOM-based XSS arising from URL parameters involves a similar process; placing some simple unique input in the parameter, using the browser’s developer tools to search the DOM for this input, and testing each location to determine whether it is exploitable. However, other types of DOM XSS are harder to detect. To find DOM-based vulnerabilities in non-URL-based input (such as document.cookie) or non-HTML-based sinks (like setTimeout), there is no substitute for reviewing JavaScript code.

(Refer this to find more about sinks)

You can refer this to know more about Reflected XSS testing and this for practicing.

You can refer this to know more about Stored XSS testing and this for practicing.

You can refer this to know more about Dom XSS testing and this for practicing.


The actual impact of an XSS attack generally depends on the nature of the application, its functionality, how it process it’s data, and the status of the compromised user. For example:

  • In an application where all users are anonymous and all information is public, the impact will often be minimal.
    In an application holding sensitive data, such as banking transactions, emails, or healthcare records, the impact will usually be serious.

  • If the compromised user has elevated privileges within the application and gained the admin or root access, then the impact will generally be critical, allowing the attacker to take full control of the vulnerable application and compromise all users and their data.

  • If successful, a cross site scripting attack can severely impact websites and web applications, damage their reputation and relationships with customers. XXS can deface websites, can result in compromised user accounts, and can run malicious code on web pages, which can lead to a compromise of the user’s device.

  • The consequence of an XSS attack is the same regardless of whether it is reflected, stored or DOM Based. The difference is in how the payload arrives/ processed at the server. Do not be fooled into thinking that a “read-only” or “brochure ware” site is not vulnerable to serious reflected XSS attacks. XSS can cause a variety of problems for the end user that range in severity from an annoyance to complete account compromise.

  • The most severe XSS attacks involve disclosure of the user’s session cookie, allowing an attacker to hijack the user’s session and take over the account. Other damaging attacks include the disclosure of end user files, installation of Trojan horse programs or keyloggers, redirecting the user to some other page or site, or modifying presentation of content and even do a phishing attack. An XSS vulnerability on a pharmaceutical site could allow an attacker to modify dosage information resulting in an overdose, this is just an example and the outcomes are infinite and can be more evil and severe.


Preventing cross-site scripting is trivial in some cases but can be much harder depending on the complexity of the application and the ways it handles user-controllable data.

Commonly used main prevention methods include:

  1. Data validation
  2. Filtering
  3. Escaping
  • The first step in the prevention of this attack is Input/Data validation. Everything, that is entered by the user should be precisely validated. Data validation can be named as the basis for ensuring the system’s security. I would remind, you that the idea of validation is not to allow inappropriate input.
    Therefore it just helps to reduce the risks, but may not be enough to prevent the possible XSS vulnerability.

  • Another good prevention method is user input filtering. The idea of the filtering is to search for risky keywords in the user’s input and remove them or replace them with empty strings.
    Those keywords may be:

  • Input filtering is quite easy to practice. It can be performed in different ways too.
    Like:

    • By developers who have written server-side code.
    • An appropriate programming language library is being used.
      In this case, some developers write their own code to search for appropriate keywords and remove them. However, the easier way would be to select an appropriate programming languages library to filter the user’s input.
  • Another possible prevention method is characters escaping. In this practice, appropriate characters are being changed by special codes. For Example, ‘<’ escaped character may look like ‘&#60’. It is important to know, that we can find appropriate libraries to escape the characters.

  • Meanwhile, good testing should not be forgotten as well. It should be invested in good software testers’ knowledge and reliable software testing tools. This way good software quality will be better assured.