Information Technology

The average ransom payment paid by victims of ransomware attacks has risen as cyber criminals exploit vulnerabilities in software and remote desktop protocol (RDP) services as common means of infiltrating networks.According to analysis by cybersecurity company Coveware’s Quarterly Ransomware Report, the average ransom payment in the first three months of this year was $220,298 – up from $154,108 in the final three months of 2020.

One of the reasons the cost of ransom payments has grown so significantly is a rise in activity by some of the most notorious ransom groups, which demand millions of dollars in Bitcoin from victims in exchange for the decryption key.SEE: A winning strategy for cybersecurity (ZDNet special report) | Download the report as a PDF (TechRepublic)  This includes the Clop ransomware gang, which Coveware describes as “extremely active” in attacks targeting large victims and demanding very high ransom demands. It ranks at number four in the most common ransomware variants, accounting for 7% of all attacks even though it wasn’t in the top 10 at all during the previous quarter.The most common ransomware is Sodinokibi, which accounts for 14% of attacks, followed by Conti, which is behind 10% of ransomware attacks, and Lockbit, which is the third most common ransomware, with a 7.5% market share. Egregor is the fifth most common ransomware seen in the first quarter of 2020, accounting for 5.3% of attacks.Other ransomware variants commonly used in attacks at the moment include Avaddon, Ryuk, Darkside, Suncrypt, Netwalker, and Phobos.

One technique that is helping to make ransomware attacks more successful is for cyber criminals to publish data they’ve stolen while inside the network. The idea is that victims fear the consequences of potentially sensitive information being exposed online – so give in and pay the ransom. According to analysis by Coveware, 77% of ransomware attacks now involve a threat to leak exfiltrated data – up 10% compared with the final quarter of 2020.Almost half of ransomware attacks begin with cyber criminals compromising RDP services, either by using stolen credentials, guessing default or common passwords or by exploiting unpatched vulnerabilities. There’s also been a rise in software vulnerabilities being exploited as a means of infiltrating networks, particularly when it comes to those in VPN applications.SEE: Hackers are actively targeting flaws in these VPN devices. Here’s what you need to doAll of this has come together to result in an average of 23 days downtime following a ransomware attack – up by two days.Something that can help organisations successfully recover from a ransomware attack is regularly updating backups of the network – and storing them offline – so if the worst happens, restoring the network is possible without giving in to ransom demands, making the exercise a pointless waste of time for cyber criminals.But the best way to avoid damage from a ransomware attack is to avoid falling victim to one in the first place. Cybersecurity procedures that can help prevent this include avoiding the use of default usernames and passwords while also securing accounts with multi-factor authentication.Organisations should also ensure the latest security patches are applied to software across the network, preventing cyber criminals from being able to exploit known vulnerabilities to plant ransomware attacks. MORE ON CYBERSECURITY More

Adobe has released a “one-stop shop” project for data processing to the open source community. 

Adobe’s One-Stop Anomaly Shop (OSAS), now available on GitHub, has been developed to make the detection of abnormalities in datasets easier, as well as to improve the processing and format of security log data. According to Chris Parkerson, Adobe Corporate Security Team marketing lead, OSAS combines the vendor’s past security research and other open source projects to offer an ‘out of the box’ system for dataset experimentation, processing, and to allow developers to explore ways to “shorten the path to finding a balanced solution for detecting security threats.” This includes leveraging Hubble, an open source compliance monitoring tool. Security logs can be complicated and messy and may not fit well with machine learning (ML)-based analysis tools, creating data sparsity and problems in turning unstructured data into structured, usable sets.  The command-line interface (CLI) toolset applies two processes to datasets to try and make sense of security logs. The first is the tagging of raw data with field types such as “multinomial, text, and numeric values,” Parkerson says, and it is also possible to label content based on set rules.  During the second stage, the labels are used as input features for generic (unsupervised) or targeted (supervised) ML algorithms. At present there are three standard options, but more are planned for the future. 

Adobe has released the OSAS code in full and has also provided a Docker version.  Previous and related coverage Have a tip? Get in touch securely via WhatsApp | Signal at +447713 025 499, or over at Keybase: charlie0 More

UnitingCare Queensland has confirmed it has fallen victim to a cyber incident, rendering some of its systems inaccessible.The organisation, which provides aged care, disability supports, health care, and crisis response services throughout the state, said the incident occurred on Sunday 25 April 2021.”As a result of this incident, some of the organisation’s digital and technology systems are currently inaccessible,” it said in a statement.”As soon as we became aware of the incident, we engaged the support of lead external technical and forensic advisors.”UnitingCare also notified the Australian Cyber Security Centre (ACSC) of the incident and said it was continuing to work with them to investigate the incident.It said where necessary, manual back-up processes are in place to ensure continuity of most of UnitingCare’s services. “Where manual processes cannot be implemented, services are being redirected or rescheduled accordingly,” it added.

The organisation said that given the incident only occurred this week, it isn’t currently possible to provide a resolution timeframe. It said, however, its digital and technology team are working to resolve things as swiftly as possible.”We are committed to keeping our people, patients, clients, and residents informed and safe as we work to resolve this incident, and will provide further relevant updates as new information comes to hand,” the statement continued.Last year, the ACSC issued an alert to aged care and healthcare providers, notifying them of recent ransomware campaigns targeting the sector. “Cybercriminals view the aged care and healthcare sectors as lucrative targets for ransomware attacks,” the ACSC wrote. “This is because of the sensitive personal and medical information they hold, and how critical this information is to maintaining operations and patient care. A significant ransomware attack against a hospital or aged care facility would have a major impact.”Last month, a “cyber incident” suffered by Eastern Health facilities in Victoria resulted in the cancellation of some surgeries across the state.Eastern Health operates the Angliss, Box Hill, Healesville, and Maroondah hospitals, and has many more facilities under management.At the time, Eastern Health took many of its systems offline as a precaution response to the incident. By April 15, it reported the majority of its IT systems were restored.Swinburne University of Technology in early April also confirmed personal information on staff, students, and external parties had inadvertently made its way into the wild; and Transport for New South Wales (TfNSW) confirmed in February it was impacted by a cyber attack on a file transfer system owned by Accellion.  Need to disclose a breach? Read this: Notifiable Data Breaches scheme: Getting ready to disclose a data breach in AustraliaTELEHEALTH GETS BUDGET BOOSTElsewhere in the health sector, the Australian government on Monday confirmed telehealth services put in place as a response to COVID-19 would continue for another six months.As part of the 2021-22 Budget, the government said it would be investing more than AU$114 million to extend telehealth until the end of the year. The extension of telehealth includes services for general practitioners, medical practitioners, specialists, consultant physicians, nurse practitioners, participating midwives, allied health providers, and dental practitioners.”The extension will ensure that Australians can continue to see their GP, renew scripts, and seek mental health support from the safety of their own home,” Health Minister Greg Hunt said. “This allows vulnerable Australians to feel protected and supported during these unprecedented times.”From 13 March 2020 to 21 April 2021, Hunt said over 56 million COVID-19 Medicare Benefits Scheme telehealth services have been delivered to 13.6 million patients, with AU$2.9 billion in Medicare benefits paid. More than 83,540 providers have used telehealth services.Although content with the extension, Labor has asked for further permanency. “Greg Hunt said last November that telehealth will become a permanent feature of our Medicare system yet all he does is on a six month by six month basis is extend the uncertainty,” Shadow Minister for Health Mark Butler said.”It is time for the government finally to make a decision about what the permanent telehealth arrangements are going to be for Medicare.”RELATED COVERAGE More

Image: Getty Images/iStockphoto
Proofpoint has entered into an agreement with Thoma Bravo that will see the cybersecurity company become a wholly owned entity of the private equity firm.Thoma Bravo has agreed to spend around $12.3 billion on the acquisition.Under the terms of the all-cash agreement, Proofpoint shareholders will receive $176 per share. The company said this represents a premium of approximately 34% over Proofpoint’s closing share price on 23 April 2021.”Upon completion of the transaction, Proofpoint will become a private company with the flexibility and resources to continue providing the most effective cybersecurity and compliance solutions to protect people and organisations around the world,” the company said in a statement. “Additionally, Proofpoint will benefit from the operating capabilities, capital support, and deep sector expertise of Thoma Bravo — one of the most experienced and successful software investors in the world.”Thoma Bravo is no stranger to the tech market. The firm has acquired a sizable portfolio of technology brands, including Qlik, Flexera, Riverbed, Blue Coat, and Barracuda Networks. Thoma Bravo has also built a portfolio of security brands with the acquisitions of Sophos, Veracode, ConnectWise, and Imperva, as well as automotive software company Autodata. Last month, Thoma Bravo announced it was adding data integration provider Talend for $2.4 billion. Talend, which went public in 2016, said the deal will position the company for long-term growth and provide the necessary capital and resources to execute its market strategy. 

In 2020, Proofpoint generated more than $1 billion in annual revenue, a milestone the company’s chairman and CEO Gary Steele said made it the first SaaS-based cybersecurity and compliance company to do so.”We believe that as a private company, we can be even more agile with greater flexibility to continue investing in innovation, building on our leadership position, and staying ahead of threat actors,” Steele said. See also: Proofpoint sues Facebook to get permission to use lookalike domains for phishing testsProofpoint’s board of directors unanimously approved the agreement.The agreement includes a 45-day “go-shop” period expiring on 9 June 2021, which allows the board and its advisors to actively initiate, solicit, and consider alternative acquisition proposals from third parties, Proofpoint said. The transaction is expected to close in the third quarter of 2021, subject to customary closing conditions, including approval by Proofpoint shareholders and receipt of regulatory approvals. Proofpoint will also continue to be headquartered in Sunnyvale, California.The announcement was made on the same day the company’s first quarter results were released.Net loss for the three months to March 31 was $45.3 million. Total revenue for the first quarter of 2021 was $287.8 million, an increase of 15%, compared to the $249.8 million reported for the first quarter of 2020.GAAP gross profit for the first quarter of 2021 was $214.3 million, up from the $180.8 million reported a year prior. Non-GAAP gross profit was $232 million.  More

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