Login
Hi all,
Has anybody managed to create a functioning hacking lab on Apple silicon?
Im trying to create a hacking lab so I could practice hacking vulnhub machines.
To my understanding, there are 2 alternatives to Virtual Box: 1. Using parallels 2. Using UTM
I’m okay with buying these software, I just cant get them to work.
Things I’ve tried: 1. Following this tutorial:
I was able to create a kali vm with 2 network interfaces (one internal for contacting the target and one external for contacting the www) But when I follow the process of converting the .ova to .qcow2 and creating the machines, a lot of machines boot up with out a network interface (even though I have defined one) I will note that some machines work fine, making the problem harder to debug. (Ive tried deleting the network adapter and creating a new one, as well as changing the “host only” to “bridged” and it didn’t work)
I was able to create a working kali vm but couldn’t find a guide that explains how to open vulnhub’s machines in parallel. (They are usually a .ova files or .vmdk)
My main question is if anyone was able to create a lab that works with vulnhub machines on apple silicon.
My side questions are: 1. Does anyone knows how to debug my problem with UTM? (That some machines don’t recognize the network adapter) 2. Has anyone know a guide that explains how to import vulnhub machines to parallels? 3. Is there a third alternative I’m missing?
Will appreciate any help, Thanks in advance!
Domain searches in HIBP - that's the story this week - and I'm grateful for all the feedback I've received. I've had a few messages in particular since this live stream where people gave me some really excellent feedback to the point where I've now got a much clearer plan in head as to what this will look like. I need to keep writing code, revising the draft blog post to announce it then sometime in hopefully about a month, push it all live. What I'm zero'ing in on now is a free tier that covers most domains, a very low entry fee for almost every personal or small business case you can think of and then a few tiers above that to cover the rest. Do keep that feedback coming, it's all read, it's all taken onboard and I'm responding to absolutely everyone that sends it to me. If you're one of those people, thank you 😊
Progress Software on Friday issued a fix for a third critical bug in its MOVEit file transfer suite, a vulnerability that had just been disclosed the day earlier.…
FBI agents have arrested a Russian man suspected of being part of the Lockbit ransomware gang. An unsealed complaint alleges the 20-year-old was an Apple fanboy, an online gambler, and scored 80 percent of at least one ransom payment given to the criminals.…
Could your Android phone be home to a remote access tool (RAT) that steals WhatsApp backups or performs other shenanigans?
The post Is a RAT stealing your files? – Week in security with Tony Anscombe appeared first on WeLiveSecurity
Capita is facing its first legal claim over the high profile digital burglary in late March that exposed some customer data to intruders and will cost the outsourcing biz around £20 million ($26 million) to clean up.…
Strategies for stopping and responding to cyberbullying require a concerted, community-wide effort involving parents, educators and children themselves
The post Stop Cyberbullying Day: Prevention is everyone’s responsibility appeared first on WeLiveSecurity
Here's a curious tale about a highly destructive yet flaky Kremlin-backed crew that was active during the early days of Russia's invasion of Ukraine, then went relatively quiet – until this year.…
Apparently it wasn't a requirement to use an HSM until just a couple weeks ago. I was surprised to read this but now some of those code signing breaches from the past make more sense.
European commissioner Thierry Breton wants Huawei and ZTE barred throughout the EU, and revealed plans to remove kit made by the Chinese telecom vendors from the Commission's internal networks.…
The US Department of Energy and other federal bodies are among a growing list of organizations hit by Russians exploiting the MOVEit file-transfer vulnerability.…
mi-1200
Chinese spies are behind the data-stealing malware injected into Barracuda's Email Security Gateway (ESG) devices globally as far back as October 2022, according to Mandiant.…
The U.S. government agency in charge of improving the nation’s cybersecurity posture is ordering all federal agencies to take new measures to restrict access to Internet-exposed networking equipment. The directive comes amid a surge in attacks targeting previously unknown vulnerabilities in widely used security and networking appliances.
Under a new order from the Cybersecurity and Infrastructure Security Agency (CISA), federal agencies will have 14 days to respond to any reports from CISA about misconfigured or Internet-exposed networking equipment. The directive applies to any networking devices — such as firewalls, routers and load balancers — that allow remote authentication or administration.
The order requires federal departments to limit access so that only authorized users on an agency’s local or internal network can reach the management interfaces of these devices. CISA’s mandate follows a slew of recent incidents wherein attackers exploited zero-day flaws in popular networking products to conduct ransomware and cyber espionage attacks on victim organizations.
Earlier today, incident response firm Mandiant revealed that since at least October 2022, Chinese cyber spies have been exploiting a zero-day vulnerability in many email security gateway (ESG) appliances sold by California-based Barracuda Networks to hoover up email from organizations using these devices.
Barracuda was alerted to the exploitation of a zero-day in its products in mid-May, and two days later the company pushed a security update to address the flaw in all affected devices. But last week, Barracuda took the highly unusual step of offering to replace compromised ESGs, evidently in response to malware that altered the systems in such a fundamental way that they could no longer be secured remotely with software updates.
According to Mandiant, a previously unidentified Chinese hacking group was responsible for exploiting the Barracuda flaw, and appeared to be searching through victim organization email records for accounts “belonging to individuals working for a government with political or strategic interest to [China] while this victim government was participating in high-level, diplomatic meetings with other countries.”
When security experts began raising the alarm about a possible zero-day in Barracuda’s products, the Chinese hacking group altered their tactics, techniques and procedures (TTPs) in response to Barracuda’s efforts to contain and remediate the incident, Mandiant found.
Mandiant said the attackers will continue to change their tactics and malware, “especially as network defenders continue to take action against this adversary and their activity is further exposed by the infosec community.”
Meanwhile, this week we learned more details about the ongoing exploitation of a zero-day flaw in a broad range of virtual private networking (VPN) products made by Fortinet — devices many organizations rely on to facilitate remote network access for employees.
On June 11, Fortinet released a half-dozen security updates for its FortiOS firmware, including a weakness that researchers said allows an attacker to run malware on virtually any Fortinet SSL VPN appliance. The researchers found that just being able to reach the management interface for a vulnerable Fortinet SSL VPN appliance was enough to completely compromise the devices.
“This is reachable pre-authentication, on every SSL VPN appliance,” French vulnerability researcher Charles Fol tweeted. “Patch your #Fortigate.”
In details published on June 12, Fortinet confirmed that one of the vulnerabilities (CVE-2023-27997) is being actively exploited. The company said it discovered the weakness in an internal code audit that began in January 2023 — when it learned that Chinese hackers were exploiting a different zero-day flaw in its products.
Shodan.io, the search engine made for finding Internet of Things devices, reports that there are currently more than a half-million vulnerable Fortinet devices reachable via the public Internet.
The new cybersecurity directive from CISA orders agencies to remove any networking device management interfaces from the internet by making them only accessible from an internal enterprise network (CISA recommends an isolated management network). CISA also says agencies should “deploy capabilities, as part of a Zero Trust Architecture, that enforce access control to the interface through a policy enforcement point separate from the interface itself (preferred action).”
Security experts say CISA’s directive highlights the reality that cyberspies and ransomware gangs are making it increasingly risky for organizations to expose any devices to the public Internet, because these groups have strong incentives to probe such devices for previously unknown security vulnerabilities.
The most glaring example of this dynamic can be seen in the frequency with which ransomware groups have discovered and pounced on zero-day flaws in widely-used file transfer applications. One ransomware gang in particular — Cl0p — has repeatedly exploited zero day bugs in various file transfer appliances to extort tens of millions of dollars from hundreds of ransomware victims.
On February 2, KrebsOnSecurity broke the news that attackers were exploiting a zero-day vulnerability in the GoAnywhere file transfer appliance by Fortra. By the time security updates were available to fix the vulnerability, Cl0p had already used it to steal data from more than a hundred organizations running Fortra’s appliance.
According to CISA, on May 27, Cl0p began exploiting a previously unknown flaw in MOVEit Transfer, a popular Internet-facing file transfer application. MOVEit parent Progress Software has since released security updates to address the weakness, but Cl0p claims to have already used it to compromise hundreds of victim organizations. TechCrunch has been tracking the fallout from victim organizations, which range from banks and insurance providers to universities and healthcare entities.
The always on-point weekly security news podcast Risky Business has recently been urging organizations to jettison any and all FTP appliances, noting that Cl0p (or another crime gang) is likely to visit the same treatment on other FTP appliance vendors.
But that sound advice doesn’t exactly scale for mid-tier networking devices like Barracuda ESGs or Fortinet SSL VPNs, which are particularly prominent in small to mid-sized organizations.
“It’s not like FTP services, you can’t tell an enterprise [to] turn off the VPN [because] the productivity hit of disconnecting the VPN is terminal, it’s a non-starter,” Risky Business co-host Adam Boileau said on this week’s show. “So how to mitigate the impact of having to use a domain-joined network appliance at the edge of your network that is going to get zero-day in it? There’s no good answer.”
Risky Business founder Patrick Gray said the COVID-19 pandemic breathed new life into entire classes of networking appliances that rely on code which was never designed with today’s threat models in mind.
“In the years leading up to the pandemic, the push towards identity-aware proxies and zero trust everything and moving away from this type of equipment was gradual, but it was happening,” Gray said. “And then COVID-19 hit and everybody had to go work from home, and there really was one option to get going quickly — which was to deploy VPN concentrators with enterprise features.”
Gray said the security industry had been focused on building the next generation of remote access tools that are more security-hardened, but when the pandemic hit organizations scrambled to cobble together whatever they could.
“The only stuff available in the market was all this old crap that is not QA’d properly, and every time you shake them CVEs fall out,” Gray remarked, calling the pandemic, “a shot in the arm” to companies like Fortinet and Barracuda.
“They sold so many VPNs through the pandemic and this is the hangover,” Gray said. “COVID-19 extended the life of these companies and technologies, and that’s unfortunate.”
ESET researchers analyzed an updated version of Android GravityRAT spyware that steals WhatsApp backup files and can receive commands to delete files
The post Android GravityRAT goes after WhatsApp backups appeared first on WeLiveSecurity
There are presently 201k people monitoring domains in Have I Been Pwned (HIBP). That's massive! That's 201k people that have searched for a domain, left their email address for future notifications when the domain appears in a new breach and successfully verified that they control the domain. But that's only a subset of all the domains searched, which totals 231k. In many instances, multiple people have searched for the same domain (most likely from the same company given they've successfully verified control), and also in many instances, people are obviously searching for and monitoring multiple domains. Companies have different brands, mergers and acquisitions happen and so on and so forth. Larger numbers of domains also means larger numbers of notifications; HIBP has now sent out 2.7M emails to those monitoring domains after a breach has occurred. And the largest number of the lot: all those domains being monitored encompass an eye watering 273M breached email addresses 😲
The point is, just as HIBP itself has escalated into something far bigger than I ever expected, so too has the domain search feature. Today, I'm launching an all new domain search experience and 5 announcements about major changes surrounding it. Let's jump into it!
Every time I look at numbers related to domain searches, they stagger me. One of the stats I found particularly interesting was that of those 200k people monitoring domains, 23k of them were monitoring 2 or more domains. 8.5k were monitoring 3 or more. 4.6k were 4 or more and so on and so forth. The point being that there are a very large number of people monitoring multiple domains. In fact, 1k people are monitoring 9 or more and hundreds have gone through the manual verification process at least 2 dozen times.
To make life much, much easier on those folks monitoring multiple domains, they're now all bundled up into a centralised dashboard accessible from the existing Domain search link on the website. Because I already know who is monitoring which domains and the email address they're using for notifications, that same email address can be used to verify your identity and drop you straight into the dashboard. Here's mine:
One of the problems the dashboard approach helps tackle is unsubscribing on an individual domain basis. In the past, the only way to unsubscribe from domain notifications was to wait until one landed in your inbox then unsubscribe from every single monitored domain in one go. It was an all or nothing affair that nuked the lot of them whereas now, it's a domain-by-domain exercise.
Another problem this solves is how I respond to an often-received question: "Hey, can you tell me which domains I'm currently subscribed to". Uh, the ones you verified? Like, possibly almost a decade ag... ah, yeah, that's a poor answer! The dashboard now makes the answer crystal clear.
And finally, another massive problem it helps tackle is verification, and that brings me to the second big announcement:
I originally introduced domain searches to HIBP only 6 weeks after the project first launched. Up until this week, it functioned exactly the same way for almost a decade: plug in a domain name, verify control of it then see the results. Each and every time. What it meant is that if you wanted to search a domain, you successfully demonstrated control then you came back later and tried to search it again, you had to go back through the same process:
You'd be surprised at how many emails I get about the difficulty this poses. We don't have any of those 4 aliases on our domain. We can't add a meta tag. We can't upload a file. We can't touch DNS. It leaves me prone to asking "well do you really have control of the domain?" Thing is, "control" is a bit of a nuanced term; there are many people in roles where they don't have access to any of the above means of verification but they're legitimately responsible for infosec and responding to precisely the sorts of notifications HIBP sends out after a breach. Usually in these cases they can get support to go through the verification process, but it involves formal internal processes, ticketing, documentation and having to explain to some IT ops person why a data breach website with a funny name needs one of the above things to happen. This doesn't fix the pain of doing it once, but it does mean that it's now a one-off pain.
As the popularity of HIBP and domain searches has grown over the years, another challenge has emerged. Let me illustrate by example: in January this year, I loaded a rather large breach into HIBP:
New scraped data: Twitter had over 200M accounts scraped from a vulnerable API in 2021. Email addresses were passed in and Twitter profiles returned. 98% were already in @haveibeenpwned. Read more: https://t.co/FRBDFk3nkp
— Have I Been Pwned (@haveibeenpwned) January 5, 2023
That's a sizeable whack of data, in fact it was the 14th largest in HIBP out of the existing 644 in there at the time. It also had a massive impact on HIBP subscribers; I sent over 1 million emails to individuals using the notification service which made it the single largest corpus of notification emails we'd ever sent by a significant margin. But further, I also sent 60,851 emails to people monitoring domains. And that's when this started happening:
6 minutes later...
And so on and so forth until my inbox looked like this:
This was Azure auto-scale doing its thing and it was one of the early attractions for me building HIBP on Microsoft's PaaS offering way back in 2013. Need more resources? Just add more cloud! Job done, next problem. Except there are 2 major drawbacks with this:
Domain searches were actually one of the last remaining remnants of a resource intensive process still running on PaaS; most of the other important bits (namely email address searches and Pwned Password's k-anonymity searches) had been on Azure Functions for ages. Functions are awesome as they're "serverless" (except for the servers they run on, but don't let me get in the marketing team's way here), in that you're never deploying large logical containers of compute like with auto-scale so that solves problem 1 above.
As of now, all domain searches run on Azure Functions. There's literally no domain search logic remaining in the Azure App Service PaaS model, it's all gone. That moves things over to much more scalable infrastructure and massively reduces the likelihood of a timeout when searching a larger domain.
I didn't just want to ship a model from years ago and reproduce all the assumptions of the day, so I made a bunch of tweaks to further optimise things. These are all things that benefit both those searching domains and me running the platform as they reduce overhead on everyone.
For example, there was no point searching for a domain then listing every alias on it "@domain.com" so now you'll just see "alias@" instead. Doesn't sound like a lot, but imagine a domain with tens of thousands of results and then a heap of orgs running searches on them. More data equals more processing equals more egress bandwidth equals more latency and more cost. (Sidenote: if you're wondering "how costly can a bit of bandwidth really be", read my post from last year on How I Got Pwned by My Cloud Costs.)
The same logic extended to exporting the domain search results in Excel or JSON format - strip out the redundant data. I went even harder on the JSON front as this format is primarily used for ingestion into other apps where there's a large amount of programmatic control. So, rather than returning a heap of redundant breach metadata over and over again, now each alias just lists the name of the breach and you can match that up to the data from the breaches API. To be clear, the domain search JSON format itself was never an "API"; it wasn't designed for programmatic consumption, it required manual verification first and I set no expectation of stability. That's something that will change soon - there'll be a proper API - but I'll come back to that at the end of this post.
Something else I've been working away on in the background is to better leverage Cloudflare's WAF to minimise the impact on the origin services. For example, last week I did a thread on blocking 401 and excessive 428 responses at the edge rather than having to process them (and pay to process them) at the origin. I've been using similar logic to keep some, well, let's just call it "very excessive" domain queries under control. For example, one particular domain was searched 140 times after a breach was loaded in April, followed by another 40 times immediately after a breach the following month:
Clearly, this is just unnecessary. Remember how domain searches are a resource intensive process that hits my bottom line pretty hard? Yeah, well, not any more!
And finally on the performance front, if you were previously monitoring multiple domains and you got a breach alert, you could run a single search that bundled all the results in together. You reckon searching for one domain can be resource intensive? Try throwing a bunch of them into the one search! As the system grew and grew, this model became increasingly hard to sustain and equally, it became increasingly noisy. So now, exactly the same domains can be searched one by one which breaks the processing down into smaller, more manageable units. Hey, wouldn't it be great to have an API around that so you could just automate the entire thing? Read on!
All these tweaks along with the move to Azure Functions has made a massive difference to the performance problem mentioned earlier, but another problem remains: I'm still paying for your domain searches. Azure Functions are charged based on a combination of how long they run for and how many resources they consume. Both those factors are extraordinarily small for individual email address searches, but they're not for domain searches. That's why soon, the largest users of the service are going to see a small fee.
Pick a brand. A big brand. If I was to bet you that either the brand directly or its parent company has used the HIBP domain search feature in the past, I'd win. I wouldn't win every bet, but I'd come out on top over a bunch of them and I know this because I have the data to be confident of my odds 🙂
Knowing which big brands use which domains for their email is actually a hard metric to define:
Anyone know where I can find a list of the Fortune 500’s domains used for email accounts? There may be more than 1 per company and it may be different to their primary website.
— Troy Hunt (@troyhunt) January 15, 2023
But by cobbling enough OSINT data together, I was able to confidently demonstrate that more than half the Fortune 500 have used this service and the vast majority of those continue to do so via ongoing domain monitoring. That's awesome! And that pattern extends all the way down to much more localised brands too; My bank. My telco. My supermarket. All sorts of commercial organisations running businesses and using data sourced from HIBP to help them do so.
I started analysing the metrics back at that tweet in Jan, just the week after all the domain searches following the scraped Twitter data going into HIBP. For the last 5 months, I've been trawling through the usage patterns and watching how organisations are using the service. I also paid a lot of attention to the reactions following the change in rate limits and annual billing for the public API that enables email address searches last Nov. That's now given me a pretty good sense of how to structure a commercial domain search model. It's not final yet, but I do hope to put the finishing touches on it next month and in the interim, welcome feedback on the high-level overview of how it'll work that I'll list here in point form:
That last point in particular is hotly requested and as of a couple of months ago, already under development:
UserVoice suggestion for @haveibeenpwned to add domain search capability to the API now started! Follow along, vote and subscribe to updates here: https://t.co/Z32eC0d9nb
— Troy Hunt (@troyhunt) April 20, 2023
I'm still working through the mechanics of all this, both technically and commercially. One part of that is looking at raw numbers, for example about half of all the domains being monitored have 10 or less breached accounts on them. These aren't commercial entities of any scale and whilst I'm not saying "10 is the free tier number", clearly there are a massive number of domains that are tiny and shouldn't be at all impacted by this.
To be honest, the experience with the public API keys has taught me that it's usually not money that's the barrier to using commercial services, it's corporate procurement bureaucracy. Onboarding documentation. Vendor assessments. Tax forms. All sorts of things that demand hours of our time, often for the sake of only $3.50 per month. So we politely decline 😊 I know that will be an issue, in fact I suspect it will be the issue and a lot of the work we've been doing this year is to try and ease that pain to the fullest extent possible. I'll talk more about that once things finally launch but for now, that's the direction we're heading and the sorts of issues we're tackling in preparation.
As we approach the 10th birthday of HIBP later this year, it's hard not to look back and reflect. So much has changed in that time, yet the service still feels very much like what it was on day 1. The challenge for me over this time has been to work out how to adapt to the changes whilst keeping true to the original intent of service. Nothing has happened quickly in that regard, and the transparent fashion in which I've chosen to run HIBP has made the rationale for any change very clear to everyone. Even this blog post has been 5 months in the making, gradually evolving to reflect my thinking on the issues until I was confident enough in the path forward.
Go and use the new dashboard. Give it a good run and let me know what you think as I'm sure there are many things we can do better. And do provide your feedback on the both the changes announced here and those to come regarding the commercial tiers too, the more input we get on this the better equipped we are to make good decisions.
North Korea has created a fake version of South Korea's largest internet portal, Naver, in a large scale phishing attempt, Seoul's National Intelligence Service (NIS) said on Wednesday.…
Global nonprofit Women in Cybersecurity (WiCyS), despite months of controversy over the cities named to host its 2024 and 2025 conferences, says it will move forward as planned with the events in Nashville, Tennessee, and Dallas, Texas, respectively.…
Seven nations today issued an alert, plus protection tips, about LockBit, the prolific ransomware-as-a-service gang.…
Webinar The cloud is floating around everywhere and with the rapid expansion of IT always comes new complexities that alter the threat landscape.…
Capita, which is still dealing with a digital break-in that exposed customers' data to criminals, has scored a £50 million contract with the City of London police to run contact and engagement services for the force's fraud reporting service.…
While not a 'get out of jail free card' for your business, cyber insurance can help insulate it from the financial impact of a cyber-incident
The post Cyber insurance: What is it and does my company need it? appeared first on WeLiveSecurity
FreshRSS 