Information Technology

To say that Linux kernel developers are livid about a pair of University of Minnesota (UMN) graduate students playing at inserting security vulnerabilities into the Linux kernel for the purposes of a research paper “On the Feasibility of Stealthily Introducing Vulnerabilities in Open-Source Software via Hypocrite Commits” is a gross understatement. Greg Kroah-Hartman, the Linux kernel maintainer for the stable branch and well-known for being the most generous and easy-going of the Linux kernel maintainers, exploded and banned UMN developers from working on the Linux kernel. That was because their patches had been “obviously submitted in bad faith with the intent to cause problems.” The researchers, Qiushi Wu and Aditya Pakki, and their graduate advisor, Kangjie Lu, an assistant professor in the UMN Computer Science & Engineering Department of the UMN then apologized for their Linux kernel blunders. That’s not enough. The Linux kernel developers and the Linux Foundation’s Technical Advisory Board via the Linux Foundation have asked UMN to take specific actions before their people will be allowed to contribute to Linux again. We now know what these demands are.

Open Source

The letter, from Mike Dolan, the Linux Foundation’s senior VP and general manager of projects, begins: It has come to our attention that some University of Minnesota (U of MN) researchers appear to have been experimenting on people, specifically the Linux kernel developers, without those developers’ prior knowledge or consent. This was done by proposing known-vulnerable code into the widely-used Linux kernel as part of the work “On the Feasibility of Stealthily Introducing Vulnerabilities in Open-Source Software via Hypocrite Commits”; other papers and projects may be involved as well. It appears these experiments were performed without prior review or approval by an Institutional Review Board (IRB), which is not acceptable, and an after-the-fact IRB review approved this experimentation on those who did not consent. This is correct. Wu and Lu opened their note to the UMN IRB by stating: “We recently finished a work that studies the patching process of OSS.” They only asked the IRB’s permission after they’d shared the paper’s abstract of the paper on Twitter.  Then after they admitted the abstract’s publication had caused “heated discussion and pushback,” they removed the abstract and apologized to the IRB for causing “many confusions and misunderstandings.”  While the IRB appears to have approved this research after the fact, the Linux kernel community was not kept in the loop. The researchers claim that they spoke to people in the Linux community, but they are never identified. Hence, Kroah-Hartman’s reaction when, once more, he was presented with “nonsense patches” except to think it was yet another attempt to waste the Linux kernel maintainers’ time by “continuing to experiment on the kernel community developers.”

Dolan continued: We encourage and welcome research to improve security and security review processes. The Linux kernel development process takes steps to review code to prevent defects. However, we believe experiments on people without their consent is unethical, and likely involves many legal issues. People are an integral part of the software review and development process. The Linux kernel developers are not test subjects, and must not be treated as such. This is a major point. The researchers first claim in their IRB FAQ that: “This is not considered human research. This project studies some issues with the patching process instead of individual behaviors, and we did not collect any personal information.”  In the next paragraph, though, the UMN researchers back off from this claim.”Throughout the study, we honestly did not think this is human research, so we did not apply for an IRB approval in the beginning. We apologize for the raised concerns. This is an important lesson we learned — Do not trust ourselves on determining human research; always refer to IRB whenever a study might be involving any human subjects in any form.” Dolan went on:  This also wasted their valuable time and put at risk the billions of people around the world who depend on their results. While the U of MN researchers claimed to take steps to prevent inclusion of vulnerabilities in the final software, their failure to gain consent suggests a lack of care. There are also amplified consequences because Linux kernel changes are picked up by many other downstream projects that build off of the kernel codebase. Then we get the heart of the matter. While Dolan said the UMN researchers’ apology was promising, the Linux community needs more. Or, as Kroah-Harman bluntly stated: As you know, the Linux Foundation and the Linux Foundation’s Technical Advisory Board submitted a letter on Friday to your University outlining the specific actions which need to happen in order for your group, and your University, to be able to work to regain the trust of the Linux kernel community. Until those actions are taken, we do not have anything further to discuss about this issue. These “requests” are: Please provide to the public, in an expedited manner, all information necessary to identify all proposals of known-vulnerable code from any U of MN experiment. The information should include the name of each targeted software, the commit information, purported name of the proposer, email address, date/time, subject, and/or code, so that all software developers can quickly identify such proposals and potentially take remedial action for such experiments. Finding all this code is a real problem. Senior Linux kernel developer, Al Viro, who spotted the first April bogus patch, noted: “The lack of data is a part of what’s blowing the whole thing out of proportion — if they bothered to attach the list (or link to such) of SHA1 of commits that had come out of their experiment, or, better yet, maintained and provided the list of message-ids of all submissions, successful and not, this mess with blanket revert requests, etc. would’ve been far smaller (if happened at all).” As it is, the Linux developers and committers are now burning time reviewing several hundred UMN Linux kernel patches. They are not amused. Dolan moved on to ask that the paper be withdrawn “from formal publication and formal presentation all research work based on this or similar research where people appear to have been experimented on without their prior consent. Leaving archival information posted on the Internet is fine, as they are mostly already public, but there should be no research credit for such works.”Thanks to the paper’s FAQ, we already know that it has been accepted for publication by the IEEE Symposium on Security and Privacy (IEEE S&P) 2021. This is a top forum for computer security researchers. The 2021 virtual meeting will be happening shortly between May 23 to May 27. The UMN has not said yet whether it will be withdrawn.Dolan pressed to ensure further UMN experiments on people have IRB review prior to the experiment commencing. “Ensure that all future IRB reviews of proposed experiments on people will normally ensure the consent of those being experimented on, per usual research norms and laws,” he said.At this time, the UMN has not responded to our request for information on what the school plans to do. The point of all this, Dolan said, is “to eliminate all potential and perception of damage from these activities, eliminate any perceived benefit from such activities, and prevent their recurrence. We would hope to see productive, appropriate open-source contributions in the future from your students and faculty as we have seen in prior years from your institution.” The Linux Foundation wants the school to respond to these requests as soon as possible. The Linux maintainers also want to know what’s what with the UMN patches, so they can find move on. They would much rather be working on improving Linux than chasing down possible deliberately seeded errors.   So far, they’re not finding any. But when you’re charged with maintaining the most important operating system on the planet, it’s better to be safe than sorry. Related Stories: More

Last week, some University of Minnesota (UMN) security researchers kicked a hornet nest, when it was revealed that they’d tried to insert deliberately buggy patches into Linux. Greg Kroah-Hartman, the well-respected Linux kernel maintainer for the Linux stable branch, responded by banning not only them but any UMN-connected developers from contributing to the Linux kernel. Now, the researchers have sort of, kind of, apologized for their mistakes: “We sincerely apologize for any harm our research group did to the Linux kernel community.” 

Open Source

The apology started well enough. But, Kangjie Lu,  the assistant professor in the Computer Science & Engineering Department of the UMN in charge of the product, and graduate student researchers, Qiushi Wu, and Aditya Pakki continued: Our goal was to identify issues with the patching process and ways to address them, and we are very sorry that the method used in the “hypocrite commits” paper was inappropriate. As many observers have pointed out to us, we made a mistake by not finding a way to consult with the community and obtain permission before running this study; we did that because we knew we could not ask the maintainers of Linux for permission, or they would be on the lookout for the hypocrite patches. While our goal was to improve the security of Linux, we now understand that it was hurtful to the community to make it a subject of our research and to waste its effort reviewing these patches without its knowledge or permission. You think? This is simply not how Red Team testing is done. At least some of the leaders of the targeted “ethical hacking attack” are made aware that an attack is coming. Otherwise, there’s no real difference between what these researchers did and ordinary, run-of-the-mill criminal hacking.  They continued, “We just want you to know that we would never intentionally hurt the Linux kernel community and never introduce security vulnerabilities. Our work was conducted with the best of intentions and is all about finding and fixing security vulnerabilities.” They then explained, “The “hypocrite commits” work was carried out in August 2020; it aimed to improve the security of the patching process in Linux. As part of the project, we studied potential issues with the patching process of Linux, including causes of the issues and suggestions for addressing them.”  And, in any case, “This work did not introduce vulnerabilities into the Linux code. The three incorrect patches were discussed and stopped during exchanges in a Linux message board, and never committed to the code. We reported the findings and our conclusions (excluding the incorrect patches) of the work to the Linux community before paper submission, collected their feedback, and included them in the paper. [“On the Feasibility of Stealthily Introducing Vulnerabilities in Open-Source Software via Hypocrite Commits”]. The researchers continued that: * All the other 190 patches being reverted and re-evaluated were submitted as part of other projects and as a service to the community; they are not related to the “hypocrite commits” paper. * These 190 patches were in response to real bugs in the code and all correct–as far as we can discern–when we submitted them. * We understand the desire of the community to gain access to and examine the three incorrect patches. Doing so would reveal the identity of members of the community who responded to these patches on the message board. Therefore, we are working to obtain their consent before revealing these patches.

What is this message board? We don’t know. It appears to not be one of the many official Linux developer mailing lists, nor the main Linux mailing list: The Linux kernel mailing list (LKML). Their apology went awry though in their last point:  * Our recent patches in April 2021 are not part of the “hypocrite commits” paper either. We had been conducting a new project that aims to automatically identify bugs introduced by other patches (not from us). Our patches were prepared and submitted to fix the identified bugs to follow the rules of Responsible Disclosure, and we are happy to share details of this newer project with the Linux community. Kroah-Hartman didn’t see these recent patches as being in the least bit valuable or even trustworthy. As he wrote about those April 2021 patches: You, and your group, have publicly admitted to sending known-buggy patches to see how the kernel community would react to them and published a paper based on that work. Now you submit a new series of obviously incorrect patches again, so what am I supposed to think of such a thing? They obviously were _NOT_ created by a static analysis tool that is of any intelligence, as they all are the result of totally different patterns and all of which are obviously not even fixing anything at all. So what am I supposed to think here, other than that you and your group are continuing to experiment on the kernel community developers by sending such nonsense patches? When submitting patches created by a tool, everyone who does so submits them with wording like “found by tool XXX, we are not sure if this is correct or not, please advise.” which is NOT what you did here at all. You were not asking for help, you were claiming that these were legitimate fixes, which you KNEW to be incorrect. A few minutes with anyone with the semblance of knowledge of C can see that your submissions do NOT do anything at all, so to think that a tool created them, and then that you thought they were a valid “fix” is totally negligent on your part, not ours.  You are the one at fault, it is not our job to be the test subjects of a tool you create. Our community welcomes developers who wish to help and enhance Linux. That is NOT what you are attempting to do here, so please do not try to frame it that way. Our community does not appreciate being experimented on, and being “tested” by submitting known patches that are either do nothing on purpose or introduce bugs on purpose.  If you wish to do work like this, I suggest you find a different community to run your experiments on, you are not welcome here. As for their apology and request to “rebuild the relationship with the Linux Foundation and the Linux community from a place of humility to create a foundation from which, we hope, we can once again contribute to our shared goal of improving the quality and security of Linux software.” Kroah-Hartman simply stated:  As you know, the Linux Foundation and the Linux Foundation’s Technical Advisory Board submitted a letter on Friday to your University outlining the specific actions which need to happen in order for your group, and your University, to be able to work to regain the trust of the Linux kernel community. Until those actions are taken, we do not have anything further to discuss about this issue.What are these actions? We don’t know. I’ve asked the appropriate people to comment on the Linux community’s demands. In the meantime, as for the code itself, Kroah-Hartman declared: “Because of this [issue], all submissions from this group must be reverted from the kernel tree and will need to be re-reviewed again to determine if they actually are a valid fix. Until that work is complete, remove this change to ensure that no problems are being introduced into the codebase.” Kees Cook, Google Linux Kernel Engineer and member of The Technical Advisory Board wrote the “Board is taking a look at the history of UMN’s contributions and their associated research projects. At present, it seems the vast majority of patches have been in good faith, but we’re continuing to review the work.” On Twitter, Cook added, “I spent a fair bit of time today going through each of the recent UMN research papers and mapping them to commits. They appear to all be in good faith. There are a small handful of mistakes that got later fixes, but given the volume of commits, that’s expected.” As for UMN, Department of Computer Science and Engineering Mats Heimdahl, Department Head, and Loren Terveen, Associate Department Head, issued a statement in which they stated they’d learned on April 21st, only after Kroah-Hartman brought the matter to the developer world’s attention. They added that they’d learned “about the details of research being conducted by one of its faculty members and graduate students into the security of the Linux Kernel. The research method used raised serious concerns in the Linux Kernel community and, as of today, this has resulted in the University being banned from contributing to the Linux Kernel.”The leaders continued, “We take this situation extremely seriously. We have immediately suspended this line of research. We will investigate the research method and the process by which this research method was approved, determine appropriate remedial action, and safeguard against future issues if needed. We will report our findings back to the community as soon as practical.”Looking from above, Linux creator Linus Torvalds is reported to have said, “I don’t think it has been a huge deal _technically_, but people are pissed off, and it’s obviously a breach of trust.” Stay tuned. While there appear to be no serious security problems as a result of the UMN blunders, trust lost is not easily regained. And, in the Linux kernel community, where trust is everything, that’s no small matter. Related Stories: More

A malware campaign with the aim of stealing passwords, bank details and other sensitive information is spreading quickly through Android devices. Known as FluBot, the malware is installed via text messages claiming to be from a delivery company that asks users to click a link to track a package delivery. This phishing link asks users to install an application to follow the fake delivery – but the app is actually malware for stealing information from infected Android smartphones.

Once installed, FluBot also gains access to the victim’s address book, allowing it to send the infected text message to all their contacts, further spreading the malware. SEE: Cybersecurity: Let’s get tactical (ZDNet/TechRepublic special feature) | Download the free PDF version (TechRepublic) The UK’s National Cyber Security Centre (NCSC) has issued security guidance about how to identify and remove FluBot malware, while network providers including Three and Vodafone have also issued warnings to users over the text message attacks. Attacks begin with messages that most commonly claim to come from delivery service DHL – although the names of other brands including Asda, Amazon and Argos are also being leveraged. If an Android user clicks on the link, they’re taken to a website that will take the user to a third-party site to download a malicious APK file (Android Package File). These files are usually blocked by default in order to help protect Android users from attacks, but the fake websites provide information on how to bypass these protections and allow FluBot to be installed.

Once installed, FluBot obtains all the permissions necessary to access and steal sensitive information including passwords, online bank details and other personal information, as well as the ability to spread itself to others. It’s this mechanism of using contact information that is allowing FluBot to spread so quickly. While the malware can only infect Android devices, Apple users are also urged to be cautious about text messages urging them to click links about a delivery as the malicious websites could still be used to steal personal information. The NCSC has warned users who receive a scam text message not to click the link in the message and not to install any apps if prompted. Instead, they’re urged to forward the message to 7726, a free spam-reporting service provided by phone operators – then to delete the message. Meanwhile, the NCSC has warned people who’ve already clicked the link and downloaded the application to not login to any additional online accounts to stop attackers harvesting more personal information – then to perform a factory reset of the device as soon as possible. SEE: Remote work makes cybersecurity a top worry for CEOs While users should be able to restore the data on their device via a backup, it’s important to avoid restoring from any backups made after FluBot malware was installed – because they will still be infected. The NCSC also recommends that users should change the passwords of any accounts they’ve logged in to since downloading the app – as well as any other accounts that use the same password – in order to prevent attackers from continuing to have access. In order to avoid falling victim to similar attacks, it’s recommended that users only install applications from official app stores.

MORE ON CYBERSECURITY More

Darktrace has reportedly slashed its valuation estimate ahead of a planned Initial Public Offering (IPO). 

The cybersecurity firm, which offers artificial intelligence (AI)-based threat detection and response solutions, will seek a valuation of between £2.4 billion ($3.3bn) and £2.7 billion ($3.7bn), according to Sky News. The valuation, believed to be far lower than previous valuation hopes of roughly £3.6 billion ($5bn), is expected to be announced to the London Stock Exchange (LSE) on Monday.  Founded in 2013 and based in Cambridge, UK, Darktrace has previously raised $230.5 million. The firm’s last funding round took place in 2018. Darktrace considers the public offering as a potential avenue for setting up long-term investment opportunities. The company is confident in the strength of the IPO for London’s market.According to people close to the matter, the cybersecurity firm’s latest valuation range has been altered due to how Deliveroo performed on its debut to the stock market.  The London-based delivery service launched its IPO on March 31. Shares slumped by over 25% on the day, proving the IPO to be one of the biggest recent tech flops on the stock market and causing steep losses for retail investors who chose to participate ahead of the IPO launch.  

The publication also cites links to Mike Lynch as a reason for caution. Former Autonomy CEO and British entrepreneur Mike Lynch is fighting an extradition bid from the US after being accused of fraud linked to the $11 billion sale of Autonomy to HP.  Lynch has denied any wrongdoing.  As reported by the Financial Times, there appears to be a close relationship between Lynch’s Invoke Capital, a technology advisory and investment firm, and Darktrace — and it may be feared that such ties could spook investors. Lynch previously acted as a Darktrace director and served on the firm’s advisory council.  The publication says that Invoke has been paid for support services but the IPO will lead to the closure of this deal, with a termination fee of £1.2 million ($1.6m) set to go to Invoke.  Darktrace declined to comment.  Previous and related coverage Have a tip? Get in touch securely via WhatsApp | Signal at +447713 025 499, or over at Keybase: charlie0 More

Security expert Dan Kaminsky has passed away at the age of 42. 

The news was made public over the weekend. In a statement issued by Kaminsky’s niece, Sarah, it was said that the prominent security researcher died due to diabetic ketoacidosis, a serious diabetic complication.  Kaminsky’s passing was not related to COVID-19 or vaccination efforts. On April 12, the researcher tweeted that he had received his vaccination, and on news of his death, some individuals on Twitter speculated there was a link.  To directly dismiss these claims, the family said that “while his passing was sudden and unexpected for us, Dan struggled for years with diabetes and was even recently hospitalized because of it.”  “I think Dan would laugh at the idea of conspiracy theorists promoting anti-vax propaganda through his death, but as his family, it hurts us to see his death being used to spread lies about a vaccine that he had full faith in,” the statement reads.  In 2008, Kaminsky revealed a fundamental flaw in the Domain Name System (DNS) at the Black Hat security conference in Las Vegas, leading to a multi-vendor, coordinated patch release.  While well-known for his work on DNS, Kaminsky has worked in the cybersecurity field for decades and also acted as an advisor for a number of Fortune 500 companies.  

The infosec community has responded on social media, describing him as generous, kind, and both a “hero” and a “force of nature” in the cybersecurity field.  A video of Kaminsky and Sarah explaining DNS — “Sarah on DNS” — has been uploaded to Twitter.  “My family and I appreciate your kind words, stories and memories of Dan,” Sarah said in a tweet dated April 25. “It has been remarkable to see the number of people he has impacted. He was such a light in this world.” The family has asked for privacy at this time. 

Previous and related coverage Have a tip? Get in touch securely via WhatsApp | Signal at +447713 025 499, or over at Keybase: charlie0 More

A specially crafted update created by law enforcement has triggered the process of removing the Emotet botnet malware from 1.6 million infected computers around the world. Emotet was thought to be the world’s largest botnet, known for spewing millions of malware-laden spam emails each day. Law enforcement in the US, Canada and Europe conducted a coordinated takedown of Emotet infrastructure in January to rid the web of one of its worst menaces, which was used to spread banking trojans, remote access tools, and ransomware.  

Part of the action involved law enforcement commandeering Emotet’s command and control (C2) infrastructure to prevent its operators from using the botnet to spread more malware. As reported by ZDNet in January, law enforcement in the Netherlands took control of two of Emotet’s three-tier C2 servers.  SEE: Network security policy (TechRepublic Premium) Law enforcement that month delivered an Emotet update that was set to remove the malware from all infected computers on April 25. According to BleepingComputer, Germany’s Bundeskriminalamt (BKA) federal police agency created and pushed the uninstall update.   “Law enforcement officials will deliver an Emotet update, “EmotetLoader.dll” file, which will remove the malware from all infected devices. The run key in the Windows registry of infected devices will be removed to ensure that Emotet modules are no longer started automatically and all servers running Emotet processes are terminated,” said security company Redscan. “However, it is important to note that the switch-off does not remove other malware installed on infected devices via Emotet, nor malware from other sources,” it added.

And cybersecurity firm Malwarebytes has now analyzed the law enforcement Emotet uninstaller. Essentially, law enforcement used Emotet’s botnet infrastructure to dismantle the malware.  “The uninstall routine itself is very simple. It deletes the service associated with Emotet, deletes the run key, attempts (but fails) to move the file to %temp% and then exits the process,” note the researchers.  Despite the error in the law enforcement code, they add that the Emotet malware “has been neutered and is harmless since it won’t run as its persistence mechanisms have been removed.” According to an FBI press release in January, an FBI investigator’s affidavit stated that: “foreign law enforcement agents, working in coordination with the FBI, gained lawful access to Emotet servers located overseas and identified the Internet Protocol addresses of approximately 1.6 million computers worldwide that appear to have been infected with Emotet malware between April 1, 2020, and Jan. 17, 2021.”  Over 45,000 of the infected computers appeared to have been located in the United States. “Foreign law enforcement, working in collaboration with the FBI, replaced Emotet malware on servers located in their jurisdiction with a file created by law enforcement,” the FBI said.  SEE: Remote work makes cybersecurity a top worry for CEOs “This was done with the intent that computers in the United States and elsewhere that were infected by the Emotet malware would download the law enforcement file during an already-programmed Emotet update.  “The law enforcement file prevents the administrators of the Emotet botnet from further communicating with infected computers. The law enforcement file does not remediate other malware that was already installed on the infected computer through Emotet; instead, it is designed to prevent additional malware from being installed on the infected computer by untethering the victim computer from the botnet.” More

The founder of a Turkish cryptocurrency exchange has reportedly fled the country with billions of dollars in user assets. 

According to local media reports, Turkey has issued an international arrest warrant for Faruk Fatih Özer, who has allegedly been spotted leaving Turkey via Istanbul airport in order to enter Albania. Özer, the CEO and founder of the Thodex cryptocurrency exchange platform, has allegedly taken approximately $2 billion in funds with him which belongs to 391,000 investors.  On Thursday, Istanbul-based Thodex posted a notice on its website informing users that the exchange would be closed for several days in order to handle a “sales” process.  However, suddenly unable to access their cryptocurrency accounts or withdraw funds, users began to voice concerns that they had been scammed.  Thousands of Turkish citizens have now filed criminal complaints against the company, alleging that they have been victims of an exit scheme. A lawyer acting for the complainants said the allegedly stolen funds were “irretrievable.” Bloomberg reports that the Justice Ministry has issued a red notice for the former CEO, which are used by Interpol to warn “police in all our member countries about internationally wanted fugitives,” although it is up to each country whether or not to act on them and potentially launch extradition proceedings. 

Last week, law enforcement issued arrest warrants for 80 individuals suspected of being linked to the platform and 68 suspects have, so far, been apprehended, according to the Anadolu Agency (AA).  The local media outlet says Özer is being sought for alleged fraud and “founding a criminal organization.” However, in a statement on its website (translated), Thodex called the claims “baseless” and a “smear campaign.” The organization claims that an “abnormality” was found in company accounts and Thodex temporarily closed to get to the bottom of the matter — and at the same time, Özer left Turkey to meet with “foreign investors.”  Thodex added that a previously undisclosed “cyberattack” impacted roughly 30,000 users causing a “suspicious situation.” According to the statement, Özer will be returning to Turkey in order to cooperate with local authorities. “As a result of the perception of victimization created in the public [space], our company is prevented from continuing its commercial life,” the statement reads. Özer’s original Twitter profile has since been closed down. A new profile, apparently belonging to the executive, shared the latest Thodex statement on April 22 and has since claimed the company is creating an “interface” to allow users to request their funds. Furthermore, Thodex says that no user will be “victimized.”  Turkey intends to impose a ban on the use of cryptocurrency to purchase goods and to make payments by the end of April. While this does not mean there is an outright ban on holding cryptocurrency as an asset, Turkey’s central bank says the payment restrictions are necessary due to a lack of a regulatory, “central” authority.  Previous and related coverage Have a tip? Get in touch securely via WhatsApp | Signal at +447713 025 499, or over at Keybase: charlie0 More

Image: Getty Images
An investigation into stolen subscription service credentials by the Australian Federal Police (AFP) has resulted in a two years and two months’ sentence for a man from Sydney.The 23-year-old was handed the sentence, to be served by way of an intensive corrections order, for his involvement as the creator, administrator, and primary financial beneficiary of a number of online subscription services which relied on stolen credentials. He has also been ordered by the court to serve 200 hours of community service.The sentencing follows the execution of a search warrant in March at a Dee Why residence, which resulted in the seizure of a laptop that was used to run the operation and around AU$35,000 in cryptocurrency.The combined assets of the restrained property has a current value of approximately AU$1.65 million.The investigation began after the Federal Bureau of Investigation (FBI) referred information to the AFP in May 2018.The information, AFP said, was regarding an account generator website called WickedGen.com. WickedGen operated for approximately two years selling stolen account details for online subscription services, including Netflix, Spotify, and Hulu.

The AFP said it further identified the Sydney man to be the creator, administrator, and primary financial beneficiary of a further three “account generator” websites: HyperGen, Autoflix, and AccountBot.The account details of users in Australia and abroad were confirmed through credential stuffing — which allows a list of previously stolen or leaked usernames, email addresses, and corresponding passwords to be re-used — and sold for unauthorised access.According to the AFP, across the four subscription services, the offender had at least 152,863 registered users and provided at least 85,925 subscriptions to illegally access legitimate streaming services.The man received at least AU$680,000 through PayPal, the AFP said, by selling subscriptions through these sites. “The harvesting and selling of personal details online was not a ‘victimless crime’ — these were the personal details of everyday people being used for someone’s greed,” AFP cybercrime operations commander Chris Goldsmid said.”These types of offences can often be a precursor to more insidious forms of data theft and manipulation, which can have greater consequences for the victims involved.”The operation was undertaken by the AFP-led Criminal Assets Confiscation Taskforce (CACT).The CACT was formed in 2011 as part of a multi-agency crackdown on criminal assets, and comprises of the AFP, Australian Criminal Intelligence Commission, Australian Taxation Office, Australian Transaction Reports and Analysis Centre, and Australian Border Force.The man was charged with “unauthorised access to (or modification of) restricted data, dealing in proceeds of crime etc.” — money or property worth $100,000 or more, providing a circumvention service for a technological protection measure, and dealing in identification information and false or misleading information.MORE FROM THE AFP More