Connect with us

NEWS

Canterbury’s Moodle Choice Blunted the Canvas Hack Fallout

Published

on

Canterbury’s Moodle choice kept the University of Canterbury outside the main Canvas hack blast radius because AKO | LEARN runs on Moodle, not the Instructure-hosted Canvas path hit in early May. For students, that procurement choice is the difference between a normal course doorway and a vendor outage that can freeze files, submissions and class messages.

The gain comes with a catch. Local or open source software can shrink a vendor-wide failure, but it also moves more responsibility back to the university: identity controls, patching, logs, backups and the staff budget to keep them alive.

A Local Moodle Path Put Distance Between Canterbury and Canvas

Canterbury’s advantage began with a boring platform fact. The university tells distance learners that course materials are accessed through its Learn learning management system, and University of Canterbury distance-learning guidance says Learn is powered by Moodle.

That separation matters more than product tribalism. A Canvas incident could not, by itself, take over a campus platform that did not sit in the same managed service path. In a week when other schools were waiting on one supplier’s containment work, Canterbury had already made the most important decision: it had chosen a different dependency.

The useful phrase here is procurement diversity. Universities often buy learning platforms for features, teaching workflows and price. The Canvas breach showed another buying criterion hiding in plain sight: whether one vendor’s compromise can interrupt the same classroom function across thousands of institutions at once.

The Canvas Incident Sat in the Vendor Layer

Instructure, the education technology company behind Canvas, said in Instructure’s incident timeline that it detected unauthorized activity in Canvas on April 29, 2026. The company said the same threat actor gained additional access on May 7 through a second Canvas vulnerability, changed pages seen by some logged-in users, and forced Canvas into maintenance mode while safeguards were applied.

The U.S. Department of Education’s Federal Student Aid office said the incident affected Canvas platforms used by K-12 schools and higher education institutions worldwide. Its Canvas security alert for schools listed unauthorized access to usernames, email addresses, course names, enrollment information and messages, while noting Instructure’s statement that there was no evidence passwords, dates of birth, government identifiers or financial information were exposed.

  • April 29: Instructure said it detected unauthorized activity in Canvas.
  • May 7: The same actor reached pages displayed to some logged-in users.
  • 10 minutes: Instructure said monitoring helped disable the second attack about that long after it began.

That is why the incident was bigger than a normal campus IT outage. The vulnerable layer sat above the individual university, in software many campuses shared. A university that had built course delivery around another path had fewer moving parts tied to Instructure’s emergency response.

Why Moodle Changed the Blast Radius

A learning management system (LMS, the software campus courses use for files, quizzes, submissions, grades and class messages) becomes critical infrastructure once assignments live there. Moodle’s difference starts with control. Moodle’s open-source model lets organizations download, modify and run the code, rather than treating the platform only as a remote service delivered by one global vendor.

That does not make Moodle immune to bugs or bad administration. It does change the blast radius. A locally supported Moodle installation can fail, but it will usually fail on its own terms: one campus, one hosting provider, one integration, one patching decision. That is a narrower problem than a shared cloud incident that knocks on many campuses at the same time.

The local support market is part of the story. Catalyst IT, a New Zealand open-source services firm, advertises Moodle services that include secure sovereign hosting and lists a University of Canterbury student-success project among its Moodle work on Catalyst’s Moodle services page. That is not the same as saying every campus should self-host. It means universities have more than one operating model.

Question Canvas-Dependent Campus Canterbury’s Moodle Path
Core platform Canvas, run by Instructure for affected institutions AKO | LEARN, powered by Moodle
Incident exposure Unauthorized access to Canvas data fields described by federal officials Outside the Canvas vendor path described in public alerts
Control model Vendor-led containment, patching and customer guidance Campus and support partners can shape hosting, customization and patch cadence
Student effect Some courses and submissions paused while Canvas was offline Course continuity depends on the local Moodle stack and its own controls

Read the table as a risk map. Product arguments come later; incident response starts with finding the shared dependency.

The Outage Cost Hit Teaching, Not Just IT

The harm was easy to measure in classroom time. The University of Canberra said the Canvas outage affected learning and teaching activities, with Canvas-based class activities unavailable, assessments that required Canvas submission blocked, and assignment extensions handled automatically during the disruption. Its Canvas outage updates also said the breach affected 25 Australian and New Zealand universities.

New Zealand authorities treated the issue as more than a foreign supplier problem. The National Cyber Security Centre said some universities and other tertiary and educational institutions in the country were affected, and it began working with the Ministry of Education, universities and tertiary providers.

For students, the fear was not abstract data governance. A learning platform holds the ordinary details that make phishing convincing: course names, teacher messages, student identifiers and assessment timing. If a malicious email knows which class you take and when work is due, it no longer feels random.

The timing made the pressure worse. The defacement landed during a heavy assessment period for many northern hemisphere campuses, a sequence covered in our earlier Canvas defacement timeline. Attackers did not need to encrypt every campus server to create leverage. They only needed to make the front door to coursework feel unsafe at the wrong week.

Local Control Still Carries a Security Bill

Moodle reduced one shared dependency for Canterbury, but open source does not run itself. The local burden includes boring work that never makes a procurement brochure: patch windows, plugin reviews, backup testing, privileged-account checks, forensic logging and a plan for assignments when the LMS is down.

Federal guidance after the Canvas incident pointed at the same basic controls universities should apply even when they do not use Canvas. The immediate security work is practical:

  • Enforce multi-factor authentication (MFA, a second login check such as an app prompt or hardware key) across administrator, staff and student accounts.
  • Review old teacher-created, free or unmanaged accounts that sit outside the institution’s normal identity controls.
  • Rotate application programming interface keys (API keys, software credentials used by connected tools) after a supplier incident.
  • Check single sign-on connectors (SSO connectors, the links that let one login work across services) for unusual access.
  • Keep assessment workarounds ready before the course platform falls over.

That list is where local control earns its keep. A university that chooses Moodle gains room to adapt and isolate. It also loses the excuse that a distant supplier owns every operational decision.

The Contract Test for University Learning Platforms

The Canvas breach should change the questions trustees and vice-chancellors ask before renewing an LMS contract. Uptime numbers are useful, but they are not enough. A platform can meet normal service levels for years and still create a hidden concentration risk.

The first contract question is about data boundaries. Which data lives with the supplier, which data stays with the university, and which integrations can move information out of both? The second is about emergency authority. Can the campus disable risky features, cut off a plugin, move assessments to another channel and notify students without waiting for a vendor webinar?

The third is about account sprawl. Instructure said the attacker used a Free-For-Teacher account path tied to Canvas. That detail should make every campus look for forgotten sandbox accounts, trial tools and instructor-created services that do useful work outside normal governance.

Canterbury’s Moodle path offers a cleaner answer to some of those questions, especially around customization and local support. It does not answer all of them. If a Moodle plugin is neglected, if admin accounts lack MFA, or if backups are untested, the local model can still fail in a very local way.

Students Need Breach Hygiene, Not Panic

Students at affected institutions should follow their own provider’s advice first. The New Zealand NCSC Canvas advisory gives a useful baseline: do not engage with anyone asking for money over the breach, report such contact to the place of learning and to Police at 105, and watch for phishing or extortion attempts.

The sensible student steps are narrow. Change any password reused on a learning platform. Treat emails about urgent submissions, new login pages or downloaded course files with suspicion. Report messages that quote real course details but push you toward a strange link. Check official campus notices before trusting screenshots on social media.

For universities, the cheapest outage is the one stopped by a vendor map drawn before the attackers arrive.

Logan Pierce is a writer and web publisher with over seven years of experience covering consumer technology. He has published work on independent tech blogs and freelance bylines covering Android devices, privacy focused software, and budget gadgets. Logan founded Oton Technology to publish clear, no nonsense tech news and reviews based on real hands on testing. He has personally tested and reviewed dozens of mid range and budget Android phones, written extensively about app privacy, and built and managed multiple WordPress publications over the past decade. Logan holds a bachelor's degree in English and studied digital marketing at a certificate level.

Continue Reading
Click to comment

Leave a Reply

Your email address will not be published. Required fields are marked *

NEWS

Public PoC Drops for 20-Year PostgreSQL pgcrypto RCE Flaw

Published

on

A working proof-of-concept exploit for CVE-2026-2005 is now public, and the flaw it targets is a heap-based buffer overflow in PostgreSQL’s pgcrypto extension built on code that shipped with the database unmodified since 2005. Every PostgreSQL instance running a version older than the February 12, 2026 patch release, with pgcrypto present and any authenticated user on the other side of a connection, is now reachable through a published attack chain.

Security researcher Varik Matevosyan, known publicly as var77, published the full exploitation code on the CVE-2026-2005 proof-of-concept repository on GitHub, demonstrating a complete path from a single crafted PGP message to operating system command execution under the PostgreSQL service account. The gap between the patch and the public exploit code was roughly three months. That window is now closed.

Two Decades in the Code

The vulnerable function is pgp_parse_pubenc_sesskey(), housed in contrib/pgcrypto/pgp-pubdec.c. When PostgreSQL’s pgcrypto extension decrypts a PGP public-key encrypted session key packet, it reads the RSA or ElGamal payload, calculates a session key length as msglen - 3, and copies that many bytes into ctx->sess_key. That destination buffer is capped at PGP_MAX_KEY, which evaluates to 32 bytes, with no bounds check between the calculated copy length and the buffer limit. An attacker who controls the incoming PGP message through the RSA or ElGamal modulus size can push the session key length into the hundreds of bytes, far past the 32-byte destination, overwriting adjacent heap memory structures in the process.

  • 8.8 CVSS 3.0 severity score assigned to CVE-2026-2005 by the PostgreSQL Global Development Group
  • 20 years the vulnerable pgcrypto code was present in the PostgreSQL codebase before discovery in December 2025
  • 32 bytes the destination buffer capped by PGP_MAX_KEY, with no bounds check on the session key copy
  • 5 supported PostgreSQL major versions patched simultaneously on February 12, 2026

Team Xint Code, using an AI-powered security analysis tool developed at Wiz, discovered the flaw during the ZeroDay.Cloud 2025 hacking event in London on December 10 and 11, 2025. The official CVE-2026-2005 advisory from the PostgreSQL Global Development Group credited the team and confirmed that all supported major versions were affected.

From Hacking Event to Patch Day

Three months separated discovery from public patch. The upstream fix was committed to the PostgreSQL source tree on February 8, 2026, and shipped across every supported major release four days later. Team Xint Code then published a detailed technical advisory through the ZeroDay.Cloud blog on May 4, 2026, describing the root cause and a reliable exploitation method. A working PoC followed roughly ten days after that, posted to GitHub by Matevosyan. The same February 12 update also addressed a companion flaw uncovered at the same event by a second competing team.

CVE-2026-2005 CVE-2026-2006
Discovering team Team Xint Code Team Bugz Bunnies
Bug class Heap buffer overflow in pgp_parse_pubenc_sesskey() Missing validation encoding bug in pgcrypto
CVSS 3.0 score 8.8 (High) 9.0 (Critical)
Public PoC available Yes, by var77 on GitHub Not confirmed as of publication
Fix committed upstream February 8, 2026 February 8, 2026
Fixed in versions 18.2, 17.8, 16.12, 15.16, 14.21 18.2, 17.8, 16.12, 15.16, 14.21

CVE-2026-2006, uncovered by Team Bugz Bunnies, carries a higher CVSS of 9.0 and targets a separate missing-validation path inside the same extension. Both were patched in the same February 12 release. No working public PoC for CVE-2026-2006 has been confirmed; the ZeroDay.Cloud technical advisory for CVE-2026-2005 published by Team Xint Code covers the root-cause analysis for the flaw now carrying live exploit code.

What shifted this week is the category the vulnerability sits in. A coordinated disclosure that stayed within the security research community for three months is now a patched flaw with a published recipe, accessible to anyone who can compile PostgreSQL from the vulnerable commit and run Python against a target host.

The timing also matters. PostgreSQL released a further maintenance update across all branches on May 14, 2026, bringing current users to 18.4, 17.10, 16.14, 15.18, and 14.23. Any instance that has not applied either the February or May update remains exposed.

The Exploit Chain var77 Built

Matevosyan’s PoC relies on two Python libraries: psycopg2, a PostgreSQL client adapter for Python, and pwntools, an exploit development and CTF library widely used in security research. The target PostgreSQL binary must be compiled from a specific vulnerable commit, because the attack resolves the address space layout randomization (ASLR) base by matching leaked memory pointers against ELF symbol offsets unique to that build. Variations in compilation settings or PostgreSQL version change those offsets and cause the chain to fail. That constraint limits automated mass scanning, but it does not protect a specific deployment once an attacker has fingerprinted the binary in use.

Stage One: Controlled Heap Leak

A crafted PGP message partially overwrites the dst->data pointer with two null bytes, redirecting it to a lower heap address. When decrypt_internal() returns and calls mbuf_steal_data(dst), PostgreSQL returns a window of heap contents spanning from the corrupted pointer to the original buffer end. That window contains position-independent executable (PIE) text pointers and heap addresses. A single call leaks both the PIE base address and a reference heap pointer, giving the attacker a working map of the process address space without triggering a crash that would alert defenders.

Stage Two: Arbitrary Write and ASLR Defeat

A second database connection, opened against the same PostgreSQL postmaster process, inherits an identical ASLR layout through PostgreSQL’s fork() model. Addresses recovered in stage one remain valid on the new connection. That second session triggers the overflow again, this time with a payload that forges all four MBuf header fields: data, data_end, read_pos, and buf_end. With those headers under attacker control, writes to any known memory address become achievable.

To validate the PIE base recovered in stage one before committing the destructive write, the exploit reads the CurrentUserId field at the computed offset and compares it against the session’s known database object identifier (OID, the internal numeric handle PostgreSQL assigns to each user). A match confirms the base address and allows the write stage to proceed without prematurely crashing the target process.

Stage Three: Superuser Takeover and Shell Access

With a confirmed base address and arbitrary write capability, the exploit overwrites CurrentUserId in PostgreSQL’s .data section, setting it to 10, the value of BOOTSTRAP_SUPERUSERID, PostgreSQL’s internal identifier for the bootstrap superuser. From that elevated position, the attacker calls COPY FROM PROGRAM, a standard PostgreSQL feature that passes a shell command directly to the operating system. The command executes under the PostgreSQL service account, completing the path from a crafted database query to arbitrary host command execution with database-daemon privileges over every database on the instance.

The Trusted Extension Problem

Most PostgreSQL extensions require superuser access to install. pgcrypto is marked as “trusted,” meaning any authenticated database user with CREATE privilege on a database can enable it with a single statement, no elevated role required. That designation extends the reachable attack surface well beyond what a superuser-restricted extension would allow, and it is why the vulnerability’s CVSS 3.0 vector reads AV:N/AC:L/PR:L: Network access, Low complexity, Low privilege requirements. For a bug that terminates in full OS command execution, that combination places this in a different risk tier than most database vulnerabilities.

The initial foothold does not require a privileged account. Stolen application credentials pulled from an environment variable file or CI/CD pipeline secrets store, a SQL injection flaw in a web application’s query layer, and lateral movement from an already-compromised internal host each provide sufficient authenticated SQL access to load the extension and begin the chain. Wiz Research data cited in the ZeroDay.Cloud advisory found that 80% of cloud environments run PostgreSQL, and that 45% of those cloud environments directly expose port 5432 to the internet, placing a substantial share of the deployed base within network reach of attackers who hold valid database credentials.

Cloud-managed PostgreSQL services carry an additional wrinkle. The patched engine version must be running in production, not simply listed as available in the provider’s console. Managed services apply minor version upgrades on their own maintenance schedules, and customers relying on automatic updates need to confirm the patched version landed before treating their exposure as resolved.

Organizations running pgcrypto because a framework installed it years ago and it was never audited face the same risk as those actively using it in application logic. The extension does not need to appear in current queries to be callable through an authenticated session by an attacker who knows to look for it in pg_extension.

Mitigation and Patch Coverage

Patching is the definitive action. The PostgreSQL Global Development Group shipped fixes across all supported branches on February 12, 2026, and a further maintenance update on May 14, 2026 carries the fix through to current minor versions. Any instance running an older minor release on any of the following branches, with the extension present, remains vulnerable regardless of other controls:

  • Branch 18: upgrade to 18.2 or later
  • Branch 17: upgrade to 17.8 or later
  • Branch 16: upgrade to 16.12 or later
  • Branch 15: upgrade to 15.16 or later
  • Branch 14: upgrade to 14.21 or later

PostgreSQL 13 and earlier are past the project’s end-of-life support window and received no patch. Running an unsupported branch with the extension present is an unmitigated exposure with no vendor-supplied fix path. While patching is arranged, remove pgcrypto using DROP EXTENSION pgcrypto; on any instance where the extension is not actively required. Restrict the CREATE privilege on databases so untrusted roles cannot reinstall it. Block direct network access to port 5432 and limit PostgreSQL connectivity to trusted application subnets. Revoke COPY FROM PROGRAM permissions from any role that has no operational need for that feature. Rotate database credentials stored in configuration files, environment variables, and CI/CD pipeline secrets, since those credentials form the most common authenticated path to the vulnerable function. Anomalous PGP decryption calls in database logs and extensions appearing in pg_extension without a matching deployment record are both worth configuring alerts against.

The PoC’s binary-specific constraint limits automated scanning against random targets right now. Targeted intrusions against a known PostgreSQL deployment, where the build can be fingerprinted through prior reconnaissance, do not share that limitation. If the chain matures to handle a broader range of compiled builds, the current window of limited opportunistic exploitation narrows further still. Operators who apply the patch before that question becomes relevant do not need to answer it.

Disclaimer: This article is intended for informational and security awareness purposes only. Details of the CVE-2026-2005 exploitation chain are described for defensive and educational value. Figures are accurate as of the date of publication and reflect data from primary sources including the PostgreSQL Global Development Group, ZeroDay.Cloud, and the public GitHub repository. Organizations should consult qualified security professionals before making changes to production database configurations.

Continue Reading

NEWS

South Korea SIM Fraud Ring Targeted Prisoners, Soldiers, and the Dead

Published

on

South Korean police on Thursday announced the arrest of the second and final suspected ringleader of a hacking syndicate that stole 48.4 billion won ($31.9 million) from 28 people while targeting 271 in total, closing an investigation that mobilized 55 detectives across nearly four years. The suspect, a 40-year-old Chinese national, was extradited from Bangkok to Incheon International Airport on May 13 and faces 18 charges, including computer fraud and violations of South Korea’s communications privacy law. He is expected to be formally referred to prosecutors by May 22.

The BTS vocalist Jungkook’s name attached to this case early, and that is where most reporting landed. His brokerage account was frozen before any transfer cleared, and he lost nothing. The victims who actually lost money were chosen for a very different reason: corporate executives with large, illiquid positions; prisoners who could not check a banking app; soldiers locked into mandatory military service; and, confirmed by investigators, people who had already died.

Two Phases, Four Years, 48 Billion Won

The syndicate operated in two distinct technical phases, each abandoned only when its predecessor became too costly to sustain. Police described the evolution as a direct response to carrier security countermeasures, not an unplanned pivot.

The first phase, SIM cloning, began in May 2022. Investigators found that the group had copied the unique authentication credentials of 13 victims from their subscriber identity module (SIM) cards onto blank replacements, producing what police call “twin SIMs.” With a duplicate card, any one-time password or SMS verification text sent to the legitimate account holder arrives instead on the fraudulent copy. Four victims lost 8.9 billion won in cryptocurrency before telecom providers updated their authentication logic enough to make cloning impractical.

So the operation changed course. From July 2023 onward, overlapping the final months of the cloning phase, the group pivoted to hacking the online activation portals of budget mobile carriers directly. That shift was far more productive, and the losses in the second phase are more than four times those of the first.

  • 48.4 billion won ($31.9M) stolen from 28 confirmed victims out of 271 targeted
  • 271 individuals in the crosshairs; fewer than one in nine was successfully defrauded
  • 8.9 billion won in Phase 1 cryptocurrency losses across four victims
  • 39.5 billion won extracted in Phase 2 via fraudulent SIM activations; a further 25 billion won theft attempt was blocked

The Silence-First Target List

The syndicate’s victim selection was organized around a single practical question: how long before this person notices? Investigators at the Seoul Metropolitan Police Agency’s Cyber Investigation Unit described the group as deliberately choosing individuals whose losses were unlikely to be detected or addressed promptly. Celebrities and executives appeared on the list not because of notoriety but because their accounts held large balances that could be moved in single transactions.

The less-discussed categories were the more deliberate ones. Prisoners cannot access a smartphone. Soldiers serving mandatory conscription have limited time with personal devices. Deceased individuals leave accounts that surviving family members may not actively monitor. Police confirmed all three as intentional targeting categories alongside the executives and influencers, not incidental additions to the victim roster.

Among the 28 confirmed victims, investigators identified 10 high-ranking corporate executives, three celebrities and influencers, and three cryptocurrency investors. Three more were connected to companies within South Korea’s top 100 conglomerates. The losses fell sharply unequal: one victim alone accounted for 21.3 billion won, nearly half the total confirmed losses, in what prosecutors described as the case’s most destructive single incident.

That distribution reveals the scheme’s internal logic. Scale comes from targets with large accounts. Operational safety comes from targets who cannot fight back fast. The syndicate optimized for both simultaneously, which is why the confirmed victim list includes conglomerate executives alongside prisoners and the deceased.

  • 10 senior corporate executives at major Korean companies
  • 3 celebrities and social media influencers
  • 3 cryptocurrency investors
  • Individuals linked to 3 companies within South Korea’s top 100 conglomerates
  • Active-duty military service members under mandatory conscription
  • Incarcerated individuals and, in confirmed cases, deceased persons

Budget Carriers as the Weak Link

Phase One: Copying the SIM

SIM cloning did not require physical access to a victim’s handset. The group harvested authentication credentials through breaches of public and private digital platforms, then transferred those credentials to blank SIM cards obtained separately. From a carrier’s perspective, the cloned card is indistinguishable from the original; it presents identical authentication data and passes the same network identity checks.

Thirteen victims had their SIM credentials compromised this way. When carriers eventually tightened their protocols and cloning became unworkable, the group did not stop. It looked for the next exploitable gap in the same identity infrastructure, and the budget carrier activation portals were it.

Phase Two: Hacking the Portal

Mobile virtual network operators (MVNOs, carriers that lease network capacity from South Korea’s three major telecoms rather than operating their own towers) had built non-face-to-face activation systems as a customer convenience feature. A new subscriber could sign up entirely online by uploading a copy of an identity document, with no in-person appearance or biometric check required. The syndicate treated those portals as an entry point, not a friction point.

Investigators found that the group breached more than ten such portals between July 2023 and April 2025. Using identity data already exfiltrated from government agencies and financial platforms, they registered 122 SIM cards under the names of 92 real people. Those authenticated phone numbers cleared two-factor authentication at banks, brokerage accounts, and cryptocurrency exchanges. The group also breached more than ten separate public and private platforms to access the financial records of 195 individuals, feeding the pipeline with a continuous supply of fresh credentials.

The scale of the underlying structural failure became clear months after the arrests. Per National Police Agency data on ghost-phone cases, MVNOs accounted for 92.3 percent of all fraudulent phone registrations detected nationwide in 2024, totaling 89,927 of 97,399 reported incidents. The syndicate’s fraudulent activations were one criminal operation inside a much broader sector-wide vulnerability.

Metric Phase 1: SIM Cloning Phase 2: Fraudulent Activations
Active period May 2022 to June 2024 July 2023 to April 2025
Core method Copying SIM authentication credentials to blank cards Hacking MVNO non-face-to-face online activation portals
Victims affected 13 SIM credentials stolen; 4 financial losses 122 SIM cards opened under 92 identities; 24 financial victims
Confirmed losses 8.9 billion won (cryptocurrency) 39.5 billion won (financial and crypto accounts)
What ended it Carriers tightened SIM authentication protocols Investigation, arrests, and extraditions

A School-Day Partnership Behind 32 Suspects

The two ringleaders had known each other since their school days, according to police. The first, a 36-year-old Chinese national, was operating out of Thailand when South Korean authorities obtained an emergency provisional arrest measure and extradited him to Seoul in August 2025; he was indicted the following month and remains on trial. The second, the 40-year-old now in custody after arriving at Incheon Airport on May 13, faces 18 charges. Both Chinese nationals ran their hacking operations from overseas bases, with the network spanning China and Thailand, before coordination with Interpol’s cybercrime division helped bring both extraditions to completion.

Below those two, 55 investigators tracked a 30-member support structure whose roles were deliberately compartmentalized: managers who processed stolen identity data, field operatives who executed SIM activations and financial transactions, and money-laundering specialists who moved funds across jurisdictions. The 30 additional members reportedly included unemployed individuals, self-employed workers, and university students. Police worked the case for three years and eleven months. Detection did not prevent Phase 2 from running; it only accelerated its end.

The ₩8.4 Billion HYBE Attempt, and the ₩21.3 Billion That Wasn’t Stopped

In January 2024, while Jungkook was completing mandatory military service, the syndicate accessed a securities account in his name and attempted to transfer 33,500 shares of HYBE, the entertainment company behind BTS. The shares were worth approximately 8.4 billion won at the time. BigHit Music, HYBE’s subsidiary label for Jungkook’s management, moved to freeze the account after authorities flagged the irregularity. No funds transferred.

The same investigation produced a very different result for the unnamed victim who lost 21.3 billion won in a single incident, the case’s largest individual loss. Police separately report recovering approximately an equivalent amount through suspicious-transaction detection systems at financial institutions, though whether that recovery was fully realized is not confirmed in publicly available filings. Investigators also froze accounts containing 12.8 billion won as the case developed.

This incident of bypassing the non-face-to-face authentication system is ‘unprecedented,’ and the vast sums accessed ‘could have easily led to an even bigger crime.’

Oh Gyu-sik, head of the Seoul Metropolitan Police Agency’s 2nd Cyber Investigation Unit, made that statement when an earlier phase of arrests was announced. The framing reflects how investigators read the case: not as a finished chapter, but as a demonstration of what becomes possible when authentication gaps exist at scale and credentials are already in circulation.

South Korea Closes the Loophole, for Now

South Korea’s Ministry of Science and ICT piloted a facial recognition requirement for new SIM registrations from December 23, 2025, and moved to full mandatory implementation on March 23, 2026. The policy now applies to all three major mobile carriers and every MVNO operating in the country. Under the system, a biometric match between a subscriber’s government-issued ID photo and a real-time facial scan must clear before any SIM is activated, whether the transaction is in-person or through an online portal.

The MVNO sector, responsible for 92.3 percent of all ghost-phone activations caught in 2024, faces the sharpest compliance obligations. Per the Ministry of Science and ICT’s December 2025 policy announcement, carriers that fail to apply the biometric check face accountability measures for repeated illegal activations. A separate investigation uncovered 11,000 ghost SIM cards registered through stolen foreign passport copies, causing an estimated 96 billion won in damages, confirming that the problem extended well beyond this one syndicate.

Police closed their statement on the case with an unusual admission: this was “a new type of crime that is difficult to find precedents globally.” The underlying mechanism is less novel. If identity credentials are already compromised at the database level and SIM activation requires no biometric gate, the combination is a ready-made account-takeover pipeline. The facial verification mandate closes the activation end of that pipeline, and has been in force since late March.

If the biometric rollout holds without new workarounds and MVNO operators apply the checks consistently, the non-face-to-face activation gap this syndicate exploited for nearly two years will be closed for good. But the government agencies and financial platforms that surrendered the identity credentials of 195 individuals to the group remain the open variable. The Ministry’s policy addresses one gate. The upstream breach problem that stocked the syndicate’s pipeline is still an unsettled question for Korean regulators.

Continue Reading

CRYPTO

Macquarie Cuts Bitcoin and Ether ETF Stakes While Buying BitMine

Published

on

Macquarie Group, the Sydney-based financial services and investment banking firm, disclosed in a first-quarter 2026 13F filing with the U.S. Securities and Exchange Commission that it cut its position in BlackRock’s spot Bitcoin exchange-traded fund, the iShares Bitcoin Trust (IBIT), by about 19.3%, reducing its stake from 5.126 million shares to 4.139 million. The Australian institution also trimmed its holding in BlackRock’s spot Ether ETF (ETHA) by roughly 9.5%, and simultaneously opened a fresh equity position in BitMine Immersion Technologies (NYSE: BMNR), the world’s largest Ethereum treasury company, valued at approximately $41.53 million as of March 31.

Two passive wrapper positions cut, one new operating-company stake built. Taken together, the disclosure sketches a deliberate portfolio decision to reduce index-style crypto access while adding equity with considerably higher leverage to Ethereum’s next price move.

Two ETF Cuts, One New Equity Bet

The mechanics of the repositioning are legible in three line items from the 13F. Macquarie’s IBIT stake fell from 5.126 million shares in Q4 2025 to 4.139 million in Q1 2026. The dollar value of that holding dropped to $159 million from $255 million, a combined result of deliberate selling and Bitcoin’s steep price decline through the period.

The Ether ETF followed a similar path. Holdings contracted from 3.634 million shares to 3.289 million, and the stake’s value fell from $81.5 million to about $52.1 million. BlackRock launched its iShares Bitcoin Trust spot ETF product in January 2024 and added ETHA that July; Macquarie built positions in both products as the spot ETF market attracted institutional capital through 2024 and into 2025.

The new entry is BMNR. Macquarie carried no prior position in the Ethereum treasury operator. The March 31 valuation placed the fresh stake at $41.53 million, making it a net addition to the book rather than a direct substitution within an existing line item.

Position Q4 2025 Shares Q1 2026 Shares Change Q1 2026 Value
IBIT (BlackRock Bitcoin ETF) 5.126 million 4.139 million -19.3% $159 million
ETHA (BlackRock Ether ETF) 3.634 million 3.289 million -9.5% $52.1 million
BMNR (BitMine Immersion Technologies) None New position N/A $41.53 million

Bitcoin’s Worst Quarter in Several Years

The market backdrop for Q1 2026 was punishing for passive crypto holders. Bitcoin fell from approximately $87,000 at the start of January to roughly $66,000 by the end of March, its steepest quarterly decline in several years. Oil prices pushed above $100 per barrel on Strait of Hormuz tensions, the Federal Reserve shelved any prospect of near-term rate cuts, and crypto ETFs bled capital through January and February before a partial March recovery returned approximately $1.3 billion in industry-wide inflows to the Bitcoin ETF complex.

The Bitcoin fund absorbed those swings while maintaining roughly $54 billion in assets under management and commanding close to 49% of the U.S. spot Bitcoin ETF market by assets through the quarter. The broader institutional bid held even as prices fell, though Macquarie was clearly among those reducing rather than adding to their exposure during the downturn.

The spot Ether fund had a steeper run. The product declined about 20% through the first quarter, consistent with Ethereum’s heightened sensitivity to macro risk-off conditions relative to Bitcoin. Some of the dollar-value contraction in Macquarie’s two ETF stakes was therefore automatic, a direct function of lower asset prices applied to unchanged share counts. The deliberate reductions in share count on top of that price effect represent the active portfolio decision that shows up in the filing.

BitMine’s Ethereum Treasury Machine

BitMine Immersion Technologies operates as a corporate Ethereum treasury, with a stated business purpose of acquiring the token, holding it on its balance sheet, staking it for network yield, and accumulating more through ongoing capital raises. The company targets ownership of 5% of Ethereum’s total circulating supply, a goal it has been approaching rapidly.

BitMine’s April 9, 2026 NYSE uplisting 8-K filed with the SEC confirmed the company’s transition from NYSE American to the main exchange, marking a significant shift in institutional profile. Thomas Lee, Chairman of BitMine Immersion Technologies, described the move as a milestone for the company. The uplisting came after a period of rapid ETH accumulation that established the firm as the largest single corporate holder of the token globally.

Today, Bitmine achieved a major milestone by being uplisted to the Big Board NYSE.

Thomas Lee, Chairman of BitMine Immersion Technologies, in an April 9, 2026 announcement filed with the U.S. Securities and Exchange Commission.

As of May 17, 2026, per BitMine’s May 2026 8-K with the SEC, the company held 5.278 million ETH at $2,191 per token, a position representing 4.37% of the 120.7 million token circulating supply. Its MAVAN infrastructure, the Made in America Validator Network, had 4.71 million of those tokens staked with annualized revenues of $289 million at a 2.8% yield.

Key metrics from the company’s most recent SEC filing:

  • 5.278 million ETH held in treasury as of May 17, 2026
  • 4.37% of the total Ethereum circulating supply controlled by a single corporate entity
  • $289 million in annualized staking revenues via the MAVAN platform at 2.8% annual yield
  • $12.6 billion in combined crypto holdings, cash, and equity stakes including positions in Beast Industries and Eightco Holdings

Institutional backers listed in BitMine’s SEC filings include ARK Investment Management, Founders Fund, Pantera Capital, Kraken, Digital Currency Group, and Galaxy Digital.

ETF Wrapper Versus Operating Equity: The Risk Calculus

Holding a spot crypto ETF is a clean transaction. At 0.25% in annual fees, IBIT and its Ether counterpart deliver Bitcoin and Ethereum price performance with minimal operational friction. There is no management team whose decisions affect returns, no net-asset-value premium or discount to worry about, and exit works precisely the same way as entry.

Holding an Ethereum treasury company is structurally different. The share price reflects supply and demand for the equity rather than the underlying token value in any mechanical way. When institutional optimism is high, treasury-company stocks frequently trade at a sustained premium to net asset value. Strategy Inc. (NASDAQ: MSTR) ran this playbook with Bitcoin for much of the past two years, and its equity returns substantially outpaced Bitcoin in rising markets precisely because the NAV premium compounded on top of the asset appreciation. BitMine is running the same model for Ethereum, with the added dimension of MAVAN staking yield generating ongoing cash flows alongside the treasury appreciation thesis.

That operating leverage cuts both ways. The treasury stock’s 52-week share range of $3.20 to $161.00 illustrates what the downside of that structure looks like. A spot Ether fund tracks Ethereum lower in a transparent, proportional way. A treasury operating company in a prolonged crypto correction can reprice below net asset value, adding execution risk and structural discount on top of the underlying decline. Ongoing equity raises to fund fresh token purchases also dilute existing shareholders, introducing a headwind that passive ETF holders never face.

Macquarie’s $41.53 million stake in the treasury operator sits alongside a $159 million position in the Bitcoin fund that remains the largest line item in its crypto book. The construction is additive and calibrated: broad Bitcoin ETF exposure at scale, a trimmed Ether ETF position, and a treasury-company bet that amplifies returns if Ethereum moves higher. The relative sizing reflects deliberate risk management rather than wholesale conviction in the treasury-company format.

The Payoff If Ethereum Moves, Scored Two Ways

Scenario one: Ethereum re-rates above $3,000 through the remainder of 2026. The company’s treasury grows in absolute dollar terms, the 2.8% MAVAN staking yield applies to a larger base, and any NAV premium the equity market assigns to the treasury stock amplifies the equity gain above what the spot Ether fund alone would deliver. In that scenario, trimming the Ether fund and buying the treasury equity looks like the correct call, and the Q1 repositioning earns a favorable reading on the Q2 filing.

Scenario two: crypto extends its first-quarter slide or grinds sideways. The Ether fund tracks Ethereum lower in a clean, proportional way. The treasury stock potentially drops faster, because the market discounts not just the token decline but the execution risk and dilution drag from a company continuing to raise equity capital to purchase more of a falling asset. The $41.53 million position would shrink by more per dollar than an equivalent spot Ether ETF stake would.

The MAVAN staking yield provides a limited buffer in the flat scenario. At 2.8% annualized on 4.71 million ETH staked, it generates cash flows tied to Ethereum’s network utilization rather than its spot price. That yield does not protect against a serious correction, but it converts part of the position from pure price speculation into a yield-generating operation, changing the cost-of-carry calculus for a long-term holder willing to ride out volatility.

Macquarie’s Q2 2026 13F filing is due 45 days after June 30. If the Ethereum treasury stake grew as a share of the crypto book in the second quarter, the conviction call is deepening. If it shrank, the Q1 trade looks more like a tactical experiment than a structural shift in how one of Australia’s largest financial institutions thinks about crypto equity versus crypto wrappers.

Disclaimer: This article is for informational purposes only and does not constitute investment advice. Holdings in IBIT, ETHA, and BMNR involve significant financial risk, including the potential for total loss of invested capital. Consult a qualified financial professional before making any investment decisions. Figures cited are accurate as of publication on May 21, 2026.

Continue Reading

Trending