Operation Power Off

Abhishek Singh

Lead - Policy & Advocacy

PUBLISHED ON

Dec 24, 2022

Introduction

DDoS – Distributed Denial of Service Attack is one of the cyber-attacks which has been evolving at the fastest pace, the new technologies have created a blanket of vulnerability for the victim which allows the cyber criminals to stay under the radar and keep launching small scale high intensity cyber attacks. A distributed denial-of-service (DDoS) attack is a malicious attempt to disrupt the normal traffic of a targeted server, service, or network by overwhelming the target or its surrounding infrastructure with a flood of Internet traffic. DDoS attacks achieve effectiveness by utilizing multiple compromised computer systems as sources of attack traffic. Exploited machines can include computers and other networked resources such as IoT devices. From a high level, a DDoS attack is like an unexpected traffic jam clogging up the highway, preventing regular traffic from arriving at its destination.

Op Power Off

In a recent Operation by Law enforcement agencies known as Op Power Off, LEAs from United Kingdom, United States of America, Netherlands, Poland, and Germany joined hands to target the cybergroups committing such large-scale attacks which can paralyse the Internet become inaccessible for a large faction of netizens. The services collectively seized were by far the most popular DDoS booter services on the market, receiving top billing on search engines. One such service taken down had been used to carry out over 30 million attacks. As part of this action, seven administrators have been arrested so far in the United States and the United Kingdom, with further actions planned against the users of these illegal services. International police cooperation was central to the success of this operation as the administrators, users, critical infrastructure, and victims were scattered across the world. Europol’s European Cybercrime Centre coordinated the activities in Europe through its Joint Cybercrime Action Taskforce (J-CAT).

Participating Authorities

United States: US Department of Justice (US DOJ), Federal Bureau of Investigation (FBI)
United Kingdom: National Crime Agency (NCA)
The Netherlands: National High Tech Crime Unit Landelijke Eenheid, Cybercrime team Midden-Nederland, Cybercrime team Noord-Holland and Cybercrime team Den Haag
Germany: Federal Criminal Police Office (Bundeskriminalamt), Hanover Police Department (Polizeidirektion Hannover), Public Prosecutor’s Office Verden (Staatsanwaltschaft Verden)
Poland: National Police Cybercrime Bureau (Biuro do Walki z Cyber-przestępczością)

Issue related to DDoS Attacks

DDoS booter services have effectively lowered the entry barrier into cybercrime: for a fee as low as EUR 10, any low-skilled individual can launch DDoS attacks with the click of a button, knocking offline whole websites and networks by barraging them with traffic. The damage they can do to victims can be considerable, crippling businesses financially and depriving people of essential services offered by banks, government institutions, and police forces. Emboldened by perceived anonymity, many young IT enthusiasts get involved in this seemingly low-level crime, unaware of the consequences that such online activities can carry. The influence of toolkits available on the dark net has made it easier for criminals to commit such crimes and at times even get away with it as well.

‍Recent examples of DDoS Attacks

In February 2020, Amazon Web Services (AWS) suffered a DDoS attack sophisticated enough to keep its incident response teams occupied for several days also affecting customers worldwide.
In February 2021, the EXMO Cryptocurrency exchange fell victim to a DDoS attack that rendered the organization inoperable for almost five hours.
Recently, Australia experienced a significant, sustained, state-sponsored DDoS attack.
Belgium also became a victim of a DDoS attack that targeted the country’s parliament, police services, and universities.

DDoS vs. DoS Attacks: What’s the Difference?

It’s important to avoid confusing a DDoS (distributed denial of service) attack with a DoS (denial of service) attack. Although only one word separates the two, these attacks vary significantly in nature.

Strictly defined, a typical DDoS attack manipulates many distributed network devices between the attacker and the victim into waging an unwitting attack, exploiting legitimate behavior.
A traditional DoS attack doesn’t use multiple, distributed devices, nor does it focus on devices between the attacker and the organization. These attacks also tend not to use multiple internet devices.

Conclusion

In this era of cyberspace, it is of paramount importance to maintain digital safety and security equivalent to physical safety, the cybercriminals will not stop at anything and can stoop to any level to target netizens and critical infrastructures in order to commit ransomware and malware attacks. As we can see DDoS-ing is taken seriously by law enforcement, at all levels of users, and are on the radar of law enforcement, be it a gamer booting out the competition out of a video game, or a high-level hacker carrying out DDoS attacks against commercial targets for financial gain.

PUBLISHED ON

Dec 24, 2022

Related Blogs

#FactCheck: Video of Taiwan’s New N700ST High-Speed Train Falsely Shared as Bullet Train Engines Arriving in India

November 10, 2026

India's Pursuit for Regulatory Control in the Crypto Landscape

January 15, 2024

Introduction

In the labyrinthine world of digital currencies, a new chapter unfolds as India intensifies its scrutiny over the ethereal realm of offshore cryptocurrency exchanges. With nuance and determination that virtually mirrors the Byzantine complexities of the very currencies they seek to regulate, Indian authorities embark on a course of stringent oversight, bringing to the fore an ever-evolving narrative of control and compliance in the fintech sector. The government's latest manoeuvre—a directive to Apple Inc. to excise the apps of certain platforms, including the colossus Binance, from its App Store in India—signals a crescendo in the nation's efforts to rein in the unbridled digital bazaar that had hitherto thrived in a semi-autonomous expanse of cyberspace.

The directive, with ramifications as significant and intricate as the cryptographic algorithms that underpin the blockchain, stems from the Ministry of Electronics and Information Technology, which has cast eight exchanges, including Bitfinex, HTX, and Kucoin, into the shadows, rendering their apps as elusive as the Higgs boson in the vast App Store universe. The movement of these exchanges from visibility to obscurity in the digital storefront is cloaked in secrecy, with sources privy to this development remaining cloaked in anonymity, their identities as guarded as the cryptographic keys that secure blockchain transactions.

The Contention

This escalation, however, did not manifest from the vacuum of the ether; it is the culmination of a series of precipitating actions that began unfolding on December 28th, when the Indian authorities unfurled a net over nine exchanges, ensnaring them with suspicions of malfeasance. The spectre of inaccessible funds, a byproduct of this entanglement, has since haunted Indian crypto traders, prompting a migration of deposits to local exchanges that operate within the nation's regulatory framework—a fortress against the uncertainties of the offshore crypto tempest.

The extent of the authorities' reach manifests further, beckoning Alphabet Inc.'s Google to follow in Apple's footsteps. Yet, in a display of the unpredictable nature of enforcement, the Google Play Store in India still played host to the very apps that Apple's digital Eden had forsaken as of a nondescript Wednesday afternoon, marked by the relentless march of time. The triad of power-brokers—Apple, Google, and India's technology ministry—has maintained a stance as enigmatic as the Sphinx, their communications as impenetrable as the vaults that secure the nation's precious monetary reserves.

Compounding the tightening of this digital noose, the Financial Intelligence Unit of India, a sentinel ever vigilant at the gates of financial propriety, unfurled a compliance show-cause notice to the nine offshore platforms, an ultimatum demanding they justify their elusive presence in Indian cyberspace. The FIU's decree echoed with clarity amidst the cacophony of regulatory overtures: these digital entities were tethered to operations sequestered in the shadows, skirting the reach of India's anti-money laundering edicts, their websites lingering in cyberspace like forbidden fruit, tantalisingly within reach yet potentially laced with the cyanide of non-compliance.

In this chaotic tableau of constraint and control, a glimmer of presence remains—only Bitstamp has managed to brave the regulatory storm, maintaining its presence on the Indian App Store, a lone beacon amid the turbulent sea of regimentation. Kraken, another leviathan of crypto depths, presented only its Pro version to the Indian connoisseurs of the digital marketplace. An aura of silence envelops industry giants such as Binance, Bitfinex, and KuCoin, their absence forming a void as profound as the dark side of the moon in the consciousness of Indian users. HTX, formerly known as Huobi, has announced a departure from Indian operations with the detached finality of a distant celestial body, cold and indifferent to the gravitational pull of India's regulatory orbit.

Compliances

In compliance with the provisions of the Money Laundering Act (PMLA) 2002 and the recent uproar on crypto assessment apps, Apple store finally removed these apps namely Binance and Kucoin from the store after receiving show cause notice. The alleged illegal operation and failure to comply with existing money laundering laws are major reasons for their removal.

The Indian Narrative

The overarching narrative of India's embrace of rigid oversight aligns with a broader global paradigm shift, where digital financial assets are increasingly subjected to the same degree of scrutiny as their physical analogues. The persistence in imposing anti-money laundering provisions upon the crypto sector reflects this shift, with India positioning its regulatory lens in alignment with the stars of international accountability. The preceding year bore witness to seismic shifts as Indian authorities imposed a tax upon crypto transactions, a move that precipitated a downfall in trading volumes, reminiscent of Icarus's fateful flight—hubris personified as his waxen appendages succumbed to the unrelenting kiss of the sun.

On a local scale, trading powerhouses lament the imposition of a 1% levy, colloquially known as Tax Deducted at Source. This fiscal shackle drove an exodus of Indian crypto traders into the waiting, seemingly benevolent arms of offshore financial Edens, absolved of such taxational rites. As Sumit Gupta, CEO of CoinDCX, recounted, this fiscal migration witnessed the haemorrhaging of revenue. His estimation that a staggering 95% of trading volume abandoned local shores for the tranquil harbours of offshore havens punctuates the magnitude of this phenomenon.

Conclusion

Ultimately, the story of India's proactive clampdown on offshore crypto exchanges resembles a meticulously woven tapestry of regulatory ardour, financial prudence, and the inexorable progression towards a future where digital incarnations mirror the scrutinised tangibility of physical assets. It is a saga delineating a nation's valiant navigation through the tempestuous, cryptic waters of cryptocurrency, helming its ship with unwavering determination, with eyes keenly trained on the farthest reaches of the horizon. Here, amidst the fusion of digital and corporeal realms, India charts its destiny, setting its sails towards an inextricably linked future that promises to shape the contour of the global financial landscape.

References

From Compliance to Forensic Readiness | What DPDP and GRC Mean for Proving Cyber Readiness

September 19, 2026

Introduction

For years, Indian companies could get away with vague privacy promises. That window closed on 13 November 2025, when the government notified the Digital Personal Data Protection Rules, giving teeth to the broad principles Parliament had passed back in 2023 under the DPDP Act. The Rules turned soft commitments into specific, auditable duties, and a lot of organisations are only now realising how much that actually changes.

Start with Section 8(4). It requires every Data Fiduciary to put "appropriate technical and organisational measures" in place. Most readers skim past "organisational" and focus on the technical half, but that's a mistake, because the word is doing real work. It's asking for defined roles, written policies, staff training, and someone actually watching whether any of it holds up over time, not just firewalls and encryption keys. Section 8(5) goes further, demanding reasonable security safeguards against breaches, and Rule 6 spells out exactly what that phrase means in practice: encrypt data at rest and in transit, restrict access on a need to know basis, require multi factor authentication, log and monitor activity, run regular vulnerability checks, bind your data processors contractually to the same standard, and keep relevant logs for at least a year.

Then there's Rule 7, and this is where the clock starts running. Once a Data Fiduciary becomes aware of a breach, the Data Protection Board must be told without delay, and a full report has to follow within 72 hours covering what happened, when, why, what's being done about it, and confirmation that affected individuals were notified. Unlike GDPR, there's no minimum severity threshold here. A breach affecting ten people triggers the same obligation as one affecting ten million. And CERT-In's existing six hour reporting window under its 2022 Directions still applies separately, which means a serious incident can trigger two overlapping regulatory clocks running side by side.

Put all of this together and a pattern emerges. The law assumes an organisation already knows what it's protecting, has actually protected it, kept usable records the whole way through, and can explain clearly what happened the moment something breaks. That coordination job belongs to Governance, Risk and Compliance, or GRC for short. GRC decides who's accountable, which risks actually matter, which controls address them, and how anyone checks whether compliance is real rather than assumed. Skip that structure and security work tends to splinter into a pile of disconnected tasks nobody truly owns.

GRC gives a legal duty somewhere to live. Forensic readiness is what lets an organisation prove, months or years later, that the duty was actually being met.

The Role of Governance, Risk and Compliance

On paper, most cybersecurity programmes look fine. There's an incident response plan somewhere, access control rules exist, logging is "in place," and someone has a title that says they're responsible for security. None of that gets tested until something actually breaks. A phishing compromise, a ransomware infection, a leaked database, a hijacked admin account, whatever the trigger, the questions that follow are always the same, and they're not comfortable ones. What happened, exactly, and when did it start? Which systems, which data, were actually touched? Were the controls the organisation claims to run genuinely functioning at that moment, or just described in a slide deck somewhere? And can anyone produce records solid enough to answer those questions with confidence rather than a shrug?

This is the exact seam where GRC and digital forensics meet. GRC lays out what's expected, who's responsible, and what evidence a control should be generating in the background. Digital forensics is the craft of taking whatever technical traces actually exist and turning them into an account of events that will hold up to scrutiny. Passing an audit was never really the point. Being able to stand in front of a regulator, mid incident, and show that the processes described on paper were real, active, and generating trustworthy evidence, that's the actual bar.

Why Compliance Alone Falls Short

Compliance, in the narrow sense, just means meeting whatever legal, contractual, or internal requirement applies. But a policy sitting in a document repository proves nothing about what actually happens on a Tuesday afternoon when someone requests admin access. A written incident response plan says nothing about whether the team can actually execute it under real pressure, at 2am, with a ransomware note on every screen. A logging policy is close to worthless if the logs it promises were switched off somewhere along the way, or overwritten, or scattered across systems that were never synchronised to the same clock.

NIST's Cybersecurity Framework 2.0 essentially built this concern into its core structure, placing "Govern" alongside Identify, Protect, Detect, Respond, and Recover as one of five equal functions rather than background paperwork sitting off to the side. India's own regulatory posture pushes in the same direction. CERT-In's 2022 Directions require certain incidents to be reported within six hours of discovery, and its guidance for government entities leans heavily on documented incident handling and disciplined evidence practices. The underlying message from both is identical: figure out, before anything goes wrong, whether the evidence you'll eventually need is actually going to exist when someone asks for it.

Where GRC and Forensics Actually Connect

A good GRC programme spells out what's supposed to happen. Forensic readiness is what lets you later prove what actually did.

Access control is a useful example here. On the GRC side, an organisation might require least privilege access, multi factor authentication, periodic reviews of who holds privileged accounts, and prompt removal of access once someone leaves or changes roles. On the forensic side, none of that means anything without the underlying records that let investigators actually test it, authentication logs, MFA usage history, privilege change records, and account activity trails. The table below lines up a few common GRC controls against the specific evidence needed to show they were genuinely operating.

‍

A Practical Scenario: After a Ransomware Incident

Picture a mid-sized company waking up to find half its file servers encrypted. There's an incident response plan somewhere in the shared drive, technically, but nobody's actually run through it in over a year. The security team isolates the obviously compromised endpoint and starts escalating. Now the forensic side of the house has to reconstruct what happened, working backward through endpoint telemetry, authentication logs, firewall events, email traffic, and file activity, hunting for the original point of entry, how the attacker escalated privileges, how they moved sideways through the network, what data they actually touched, and finally how the ransomware got deployed.

This is where the quality of everything collected beforehand suddenly matters a great deal. If server clocks were never properly synchronised, the timeline investigators build might not line up cleanly enough to trust. If logs only ever lived locally on individual machines rather than being pulled centrally, some of them are probably gone by now. If nobody ever bothered logging administrator actions, there are going to be real, unexplained gaps in the story. And if whatever evidence does exist wasn't collected the right way, its integrity can be challenged later, sometimes fatally, in a legal or regulatory proceeding. CERT-In actually ran a programme on exactly this in July 2026, "Inside the Breach," covering system artefacts, investigative technique, and chain of custody requirements, precisely because this is where real investigations tend to succeed or quietly fall apart.

Building a Forensic Ready GRC Programme

For an organisation starting more or less from scratch, forensic readiness doesn't need to be bolted on as some separate initiative. It can be built straight into the GRC programme that already exists. Start by identifying the systems, applications, cloud services, and privileged accounts that actually matter. Map the real risks and regulatory requirements onto the controls meant to address them. Then get specific about what evidence each control should be generating, and how that evidence gets protected and kept over time. Time synchronisation, centralised logging, tightly controlled access to security records, and clear ownership of preservation, escalation, and investigation all need to exist well before an incident, not be improvised during one. And none of it means much until it's actually been tested, through tabletop exercises and simulated incidents rather than assumed to work because it's written down somewhere. NIST SP 800-61 Revision 3 frames incident response as one continuous loop of preparation, detection, response, recovery, and improvement, rather than a series of separate boxes to check.

There's one question worth asking of every important control an organisation runs: could you actually prove this was working at the moment an incident happened? If the honest answer is no, what you have is a compliance process on paper, and a forensic readiness gap sitting quietly underneath it.

Conclusion

Cyber readiness was never really about how many policies sit in a binder or how many boxes get ticked in an audit. It shows up, or doesn't, in the hours right after something breaks, when an organisation has to move fast, preserve evidence that can actually stand up to scrutiny, explain clearly what happened, and prove that governance and technical controls were genuinely working together rather than just coexisting on paper. GRC sets the direction, the accountability, the risk priorities, and the compliance expectations. Digital forensics does the work of preserving and interpreting the technical evidence once something actually happens. Forensic readiness sits in between the two, making sure they're actually talking to each other long before an incident forces the conversation. The practical task for most organisations comes down to something simple to say, if not always simple to build: design controls that hold up under real incident response, not just an auditor's checklist. The strongest compliance posture was never the one with the thickest binder. It's the one that can back every document up with evidence, on the day it actually matters.

References

Digital Personal Data Protection Act, 2023, Sections 8(4), 8(5), 8(6). https://www.meity.gov.in/writereaddata/files/Digital%20Personal%20Data%20Protection%20Act%202023.pdf
Digital Personal Data Protection Rules, 2025, Rules 6 and 7, notified 13 November 2025. https://www.meity.gov.in
National Institute of Standards and Technology, The NIST Cybersecurity Framework (CSF) 2.0, CSWP 29, 2024. https://csrc.nist.gov/pubs/cswp/29/the-nist-cybersecurity-framework-csf-20/final
Indian Computer Emergency Response Team (CERT-In), Directions under Section 70B of the Information Technology Act, 2000, dated 28 April 2022. https://www.cert-in.org.in/Directions70B.jsp
Indian Computer Emergency Response Team (CERT-In), Guidelines on Information Security Practices for Government Entities. https://www.cert-in.org.in/Downloader?fileName=CIPS-2026-0014.pdf&pageid=5&type=2
National Institute of Standards and Technology, SP 800-86: Guide to Integrating Forensic Techniques into Incident Response, 2006. https://csrc.nist.gov/pubs/sp/800/86/final
International Organization for Standardization, ISO/IEC 27037:2012, Guidelines for identification, collection, acquisition and preservation of digital evidence. CERT-In, "Inside the Breach: Advanced Cyber Forensics & Incident Investigation," 31 July 2026. https://www.cert-in.org.in/s2cMainServlet?pageid=PRSTNVIEW03&reCode=CIWS-2026-3569
National Institute of Standards and Technology, SP 800-61 Rev. 3: Incident Response Recommendations and Considerations for Cybersecurity Risk Management, 2025. https://csrc.nist.gov/pubs/sp/800/61/r3/final
Matters.ai, "DPDP Breach Notification: 72-Hour Rule & ₹200 Cr Penalty." https://www.matters.ai/article/dpdp-breach-notification MediaNama, "Data Breach Reporting Timeline of DPDP Rules 2025 Explained." https://www.medianama.com/2025/11/223-data-breach-reporting-timeline-of-dpdp-rules-2025-explained/

‍

Operation Power Off

Introduction

Op Power Off

Participating Authorities

Issue related to DDoS Attacks

‍Recent examples of DDoS Attacks

DDoS vs. DoS Attacks: What’s the Difference?

Conclusion

Related Blogs

Executive Summary

Claim:

Fact Check

‍

Conclusion

Introduction

The Contention

Compliances

The Indian Narrative

Conclusion

References

Introduction

The Role of Governance, Risk and Compliance

Why Compliance Alone Falls Short

Where GRC and Forensics Actually Connect

A Practical Scenario: After a Ransomware Incident

Building a Forensic Ready GRC Programme

Conclusion

References

Become a part of our vision to make the digital world safe for all!

Awareness

Engagement

Play your part for CyberPeace