Login
Last week, I wrote about The State of Data Breaches and got loads of feedback. It was predominantly sympathetic to the position I find myself in running HIBP, and that post was mostly one of frustration: lack of disclosure, standoffish organisations, downplaying breaches and the individual breach victims themselves making it worse by going to town on the corporate victims. But the other angle that's been milling around in my brain is the one represented by the image here:
Running HIBP has become a constant balancing act between a trilogy of three parties: hackers, corporate victims and law enforcement. Let me explain:
This is where most data breaches begin, with someone illegally accessing a protected system and snagging the data. That's a high-level generalisation, of course, but whether it's exploiting software vulnerabilities, downloading exposed database backups or phishing admin credentials and then grabbing the data, it's all in the same realm of taking something that isn't theirs. And sometimes, they contact me.
This is a hard position to find myself in, primarily because I need to weigh the potentially competing objectives of notifying impacted HIBP subscribers whilst simultaneously not pandering to the perverse incentives of likely criminals. Sometimes, it's easy: when someone reports exposed data or a security vulnerability, the advice is to contact the company involved and not turn it into a data breach. But when they already have the data, by definition it's now a breach and inevitably a bunch of my subscribers are in there. It's awkward, talking to the first party responsible for the breach.
There are all sorts of circumstances that may make it even more awkward, for example if the hacker is actively trying to shake the company down for money. Perhaps they're selling the data on the breach market. Maybe they also still have access to the corporate system. Having a discussion with someone in that position is delicate, and throughout it all, I'm conscious that they may very well end up in custody and every discussion we've had will be seen by law enforcement. Every single word I write is predicated on that assumption. And eventually, being caught is a very likely outcome; just as we say that as defenders we need to get it right every single time and the hacker only needs to get it right once, as hackers, they need to get their opsec right every single time and it only takes that one little mistake to bring them undone. A dropped VPN connection. An email address, handle or password used somewhere else that links to their identity. An incorrect assumption about the anonymity of cryptocurrency. One. Little. Mistake.
However, I also need to treat these discussions as confidential. The expectation when people reach out is that they can confide in me, and that's due to the trust I've built over more than a decade of running this service. Relaying those conversations without their permission could destroy that reputation in a heartbeat. So, I often find myself brokering conversations between the three parties mentioned here, providing contact details back and forth or relaying messages with the consent of each party.
This sort of communication gets messy: you've got the hacker (who's often suspicious of big corp) trying to draw attention to an issue, but they're trying to communicate with a party who's also naturally suspicious of anonymous characters who've accessed their data! And law enforcement is, of course, interested in the hacker because that's their job, but they're also respectful of the role I play and the confidence with which data is shared with me. Meanwhile, law enforcement is also often engaged by the corporate victim and now we've got all players conversing with each other and me in the middle.
I say this not to be grandiose about what I do, but to explain the delicate balance with which many of these data breaches need to be handled. Then, that's all wrapped in with the observations from the previous post about lack of urgency etc.
I choose to use this term because it's all too easy for people to point at a company that's suffered a data breach and level blame at them. Depending on the circumstances, some blame is likely warranted, but make no mistake: breached companies are usually the target of intentional, malicious, criminal activity. And when I say "companies", we're ultimately talking about individuals who are usually doing the best they can at their jobs and, during a period of incident response, are often having the worst time of their careers. I've heard the pain in their voices and seen the stress on their faces on so many prior occasions, and I want to make sure that the human element of this isn't lost amidst the chants of angry customers.
The way in which corporate victims engage with hackers is particularly delicate. They're understandably angry, but they're also walking the tightrope of trying to learn as much as they can about the incident (the vector by which data was obtained often isn't known in the early stages), whilst listening to often exorbitant demands and not losing their cool. It's very easy for the party who has always worked on the basis of anonymity to simply "go dark" and disappear altogether, and then what? We can see this balancing act in many of the communications later released by hackers, often after they've failed to secure the expected ransom payment; you have extremely polite corporations... who you know want nothing more than to have the guy thrown into prison!
The law enforcement angle, or perhaps, to put it more broadly, the interactions with government authorities in general, is an interesting one. Beyond the obvious engagements around the criminal activity of hackers, the corporate victims themselves have legal responsibilities. This is obviously highly dependent on jurisdiction and regulatory controls, but it may mean reporting the breach to the appropriate government entity, for example. It may even mean reporting to many government entities (i.e. state-based) depending on where they are in the world. Then there's the question of their own culpability and whether the actions they took (or didn't take) both pre and post-breach may result in punitive measures being taken. I had a headline in the previous post that included the term "covering their arses" and this doesn't just mean from customer or shareholder backlash, but increasingly, from massive corporate fines.
I suspect, based on many previous experiences, that corporations have a love-hate relationship with law enforcement. They obviously want their support when it comes to dealing with the criminals, but they're extraordinarily cautious about what they disclose lest it later contribute to the basis on which penalties are levelled against them. Imagine the balancing act involved when the corporate victims suspects the breach occurred due to some massive oversights on their behalf and they approach law enforcement for support: "So, how do you think they got in? Uh..."
Like I've already said so many times in this post: "delicate".
This is the most multidimensional player in the trilogy, interfacing backwards and forwards with each party in various ways. Most obviously, they're there to bring criminals to justice, and that clearly puts hackers well within their remit. I've often referred to "the FBI and friends" or similar terms that illustrate how much of a partnership international law enforcement efforts are, as is regularly evidenced by the takedown notices on cybercrime initiatives:
The hackers themselves are often all too eager to engage with law enforcement too. Sometimes to taunt, other times to outright target, often at a very individual level such as naming specific agents. It should be said also that "hacker" is a very broad term that, at its worst, is outright criminal activity intended to be destructive for their own financial gain. But at the other end of the scale is a much more nuanced space where folks who may be labelled with this title aren't necessarily malicious in their intent but to paraphrase: "I was poking around and I found something, can you help me report it to the authorities".
The engagement between law enforcement and corporate victims often begins with the latter reporting an incident. We see this all the time in disclosure statements "we've notified the authorities", and that's a very natural outcome following a criminal act. It's not just the hacking itself, this is often accompanied by a ransom demand which piles on yet another criminal activity that needs to be referred to the authorities. Conversely, law enforcement regularly sees early indications of compromise before the corporate victim does and is able to communicate that directly. Increasingly, we're seeing formal government entities issue much broader infosec advice, for example, as our Australian Signals Directorate regularly does.
I often end up finding myself in a variety of different roles with law enforcement agencies. For example, providing a pipeline for the FBI to feed breached passwords into, supporting the Estonian Central Criminal Police by making data impacting their citizens searchable, spending time with the Dutch police on victim notification, and even testifying in front of US Congress. And, of course, supporting three dozen national CERTs around the world with open access to exposure of their federal domains in HIBP. Many of these agencies also have a natural interest in the folks who contact me, especially from that first category listed above. That said, I've always found law enforcement to be respectful of the confidence with which hackers share information with me; they understand the importance of the trust I mentioned earlier on, and it's significance in playing the role I do.
A decade on, I still find this to be an odd space to occupy, sitting on the fringe and sometimes right in the middle of the interactions between these three parties. It's unpredictable, fascinating, exciting, stressful, and I hope you found this interesting reading 🙂
With a record-breaking number of Americans set to travel over the July 4th holiday, most of them by car, scammers have adjusted their plans accordingly. New research reveals the top 10 U.S. destinations where scammers plant the bulk of their online travel scams.
Our McAfee Labs team kicked off this research by analyzing TripAdvisor’s Popular Domestic Destinations for US Travelers and Fastest Growing Domestic Destinations for US Travelers lists. From there, they identified the locales that generated the highest volume of risky search results.
For people researching and booking travel online, those results could lead to all manner of sketchy sites. Some host malware, others steal personal info, and yet more lead to phony booking sites that take their money and leave them with nowhere to stay.
Paired with that research, we also polled 1,000 Americans on their travel plans, including how they’re researching and booking online and the travel scams they’ve encountered over the years.
Together, they offer a view of what travel scams look like today — and insights into how you can avoid them.
Of the Americans we surveyed, 85% said they’ll travel this year. Within that mix, you’ll find both splurging and bargain-hunting as travelers do their planning and booking online.
As far as splurging goes, 65% said they’ll spend more on wining and dining, 53% on experiences like tours and sightseeing, and 48% on shopping for themselves and others.
Not so surprisingly on the bargain-hunting side, people said they’re looking for the cheapest airfare (48%), cheapest accommodations (46%), and deals on activities and excursions (34%).
To plan their travels, many Americans said they’ve turned to AI. Or that they would at least consider it.
When asked, “Have you or would you use an Artificial Intelligence (AI) tool like WhereTo, ChatGPT, or Vaca Chatbot to help you plan your next vacation?” we uncovered the following:
Overall, online resources lead the way when it comes time to plan and book travel. More than half of Americans say they use online reviews as a primary resource, with online travel sites close behind at just under half.
Still, traditional sources of travel research remain popular. Recommendations from family and friends weighed in at 40%, with another 36% saying they flip through travel books and guides.
As far as Americans’ concerns about travel scams, those remain high. Nearly four out of five people (79%) said they research and pay attention to travel scams as part of their planning. Which is wise, as many people said they’ve gotten burned by one.
When asked if they’d ever fallen for a scam while booking travel, 28% said yes. The top three booking scams they reported include:
Yet another 28% said they’d fallen prey to a scam while traveling. The top three scams for those Americans included:
How’d all these scams add up? In all, we found that 32% of victims said they lost between $501–1000 in a single scam. Another 24% of victims said they lost more than $1,000. Only a relatively small percentage of people – just 15% — said they lost nothing, a figure that shows just how successful travel scams can be.
This falls in line with reports from the Federal Trade Commission (FTC). As published in their 2023 Data Book, more than 55,000 Americans reported a travel scam with a median loss of nearly $1,200 per case.[i] As always with FTC statistics, this only includes reported cases of fraud. The number of actual scams more than likely climbs higher than that.
And now, our list.
Once again, these destinations return the highest volume of potential scam results in search. As always, booking any travel online calls for care (and we’ll cover that next). Yet when it comes to researching and booking travel in the U.S., scammers appear to favor the following destinations the most:
Our recommendations for U.S. travel fall in line with the ones we offered earlier this year when we shared the results of the top ten riskiest international destinations. Our list begins with a cornerstone piece of advice: Trust a trusted platform.
That’s your best place to start. Book your vacation rental through a reputable outlet. Vacation rental platforms like Airbnb and VRBO have policies and processes in place that protect travelers from scammers. The same goes for booking other travel needs above and beyond renting. Travel platforms such as Expedia, Priceline, Orbitz, and others also have protections in place.
From there, you have several other ways you can avoid booking scams…
Look for signs of rental scams.
Do a reverse image search on the photos used in the property’s listing and see what comes up. It might be a piece of stock photography designed to trick you into thinking it was taken at an actual property for rent. (Scammers sometimes highjack photos of actual properties not for rent too. Some now use AI-generated images as well.) Also, read the reviews for the property. Listings with no reviews are a red flag.
Only communicate and pay on the platform
The moment a host asks to communicate outside of the platform is another red flag. Scammers will try to lure you off the platform where they can request payment in forms that are difficult to recover or trace after you realize you’ve been scammed.
Moreover, paying for your rental outside the platform might also go against the terms of service, as in the case of Airbnb. Or, as with VRBO, paying outside the platform voids their “Book with Confidence Guarantee,” which offers you certain protections. Use the platform to pay and use a credit card when you do. In the U.S., the Fair Credit Billing Act allows you to dispute charges. Additionally, some credit cards offer their own anti-fraud protections that can help you dispute a billing.
Never pay with cryptocurrency, wire transfers, or gift cards
If someone asks you to pay for your trip one of these ways, it’s a scam. Travel scammers prefer these payment methods because they’re exceptionally tough to track. Once that money gets sent, it’s likewise exceptionally tough to get back.
Keep an eye out for phishing attacks
Scammers use phishing emails and messages to trick travelers into revealing sensitive info or downloading malware onto their devices. As you book, look for unsolicited messages claiming to be from airlines, hotels, or financial institutions. Particularly if they ask for personal info or prompt you to click on suspicious links. When in question, contact the sender directly using official contact info from their official website.
Also, look into McAfee Scam Protection, included with our McAfee+ plans. It blocks links to scam sites that crop up in emails, messages, and texts. AI technology automatically scans the links and alerts you if it might send you to a scam site.
Let your bank and credit card companies know you’re traveling
Give your bank and credit card companies a call before you head out. They have anti-fraud measures in place that look for unusual activity, such as when your card is used in a location other than somewhere relatively near your home. This can trigger a freeze, which can put you in a lurch if you’re looking to withdraw cash or make a payment. Contacting your bank and credit card companies before you travel can help prevent this.
Have an easy way to keep tabs on your accounts and credit
Fraud can happen at any time, even when you’re out of town. A couple of things can help you nip it quickly before it takes a big bite out of your credit card or bank accounts. Transaction monitoring notifies you of any questionable activity in your credit cards or bank accounts. It can further alert you to any other questionable activity in your 401(k) plans, investments, and loans.
So say that your debit card info got skimmed in a sketchy ATM or point-of-sale machine — you’ll get an alert if thieves try to make a purchase with it. From there, you can contact your bank and take the extra step of putting a security freeze in place to prevent further fraud. You can security freeze and transaction monitoring features in our McAfee+ plans as well.
Protect your identity
Before you hop on a plane, train, or automobile, consider investing in identity protection. This way, you can head off any issues that might crop up when you should be enjoying yourself. For example, imagine losing your wallet. Immediately, a dark cloud of “what ifs” rolls in. What if someone’s running up charges on your cards? What if someone used your ID or insurance cards to impersonate you online? Not a great feeling any time, especially on vacation.
With identity theft coverage and restoration in place, you can recoup your losses and restore your identity if a thief damaged it in any way. Ours provides up to $2 million in coverage, along with lost wallet protection that cancels and replaces lost cards with little effort from you.
[i] https://www.ftc.gov/system/files/ftc_gov/pdf/CSN-Annual-Data-Book-2023.pdf
The post The Top 10 Online Booking Scam Hotspots in the U.S. Revealed appeared first on McAfee Blog.
What is our real job as parents? Is it to ensure our kids get good grades? – Maybe. Or is it ensuring we can give them the latest and greatest clothing and devices? Mmmm, not really. When all is said and done, I believe our real job is to keep our kids safe, teach them to be independent, and set them up for success – both online and offline.
As first-generation digital parents, many of us are learning on the job. While we can still glean advice from our own parents on dealing with our teenager’s hormones and driving challenges, there’s no intergenerational wisdom for anything digital. So, it is inevitable that many of us parents feel unsure about how and why to be proactive about online safety.
With four grown boys, 12 nieces and nephews, and almost 13 years in this job talking to families about online safety, I’ve developed a pretty good understanding of how families want to live their lives online, their biggest concerns, and how they value safety and security. Here’s what I’ve learnt:
I’ve often dreamt about wrapping my boys in cotton wool and keeping them away from the real world. But unfortunately, that’s not how it works. The internet definitely has some hugely positive features for teens and tweens but there are some challenges too. Here is what parents are most concerned about:
1. Social Media
Without a doubt, tween and teen social media usage would currently be the biggest concern for most parents. In Australia, there is currently a move to delay children using social media to 16. The Prime Minister is a fan as are many state and territory leaders. There’s no doubt parents are concerned about the impact social media is having on their children’s mental health. Whether dealing with followers, friends, or FOMO (fear of missing out), harassment, or exposure to unhelpful, or even dangerous influencers, parents are worried and often feel helpless about how best to help their kids.
2. Bullying
Parents have every right to be concerned. Cyberbullying does happen. In fact, 1 child in 3 reports being the victim of cyberbullying according to a UNICEF study. And in a study conducted by McAfee in 2022 that does a deep dive into the various types of bullying, there’s no doubt that the problem is still very much a reality.
3. Inappropriate Content
There really isn’t anything you can’t find online. And therein lies the problem. With just a few clicks, a curious, unsupervised 10-year-old could access images and information that would be wildly inappropriate and potentially traumatic. And yes, I’m talking sex, drugs and rock and roll themes! There are things online that little, inexperienced eyes are just not ready for – I am not even sure I am either, to be honest!
4. Screen Time
While I think many parents still find the word screen time a little triggering, I think some parents now realise that not all screen time ‘was created equally’. It’s more about the quality and potential benefit of screen time as opposed to the actual time spent on the screen. For example, playing an interactive, good quality science game as opposed to scrolling on Instagram – clearly the game wins!
However, parents are still very concerned that screen time doesn’t dominate their kids’ lives and adversely affects their kids’ levels of physical activity, face-to-face time with family and friends, and their ability to sleep.
While there is no silver bullet here, being proactive about your family’s online security is THE best way of protecting your family members, minimising the risk of unpleasant interactions, and setting them up for a positive online experience. And it will also reduce your stress big time – so it’s a complete no-brainer!!
Here are 5 things you can kick off today that will have a profound impact on your family’s online security:
1. Talk, talk, talk!!
Yes, that’s right – simply talk! Engaging with your kids about their online lives – what they like to do, sites and apps they use and any concerns they have is one of the best ways to keep them safe. As is sharing your own stories. If your kids know that you understand the digital world, they will be far more likely to come to you if they experience any issues at all. And that’s exactly what we want!!
2. Parental Controls and Monitoring
Parental controls can work really well alongside a proactive educational approach to online safety. As well as teaching kids healthy digital habits, they can also help parents monitor usage, set limits, and even keep tabs on their kids’ whereabouts. Gold!! Check out more details here.
3. Social Media Safety
Undertake an audit of all family member’s privacy settings to ensure that are set to the highest level. This will ensure only trusted people can view and interact with your kids’ profiles. Also, remind your kids not to overshare as it could lead to their identities being stolen. And check out McAfee’s Social Privacy Manager which can help you manage more than 100 privacy settings on social media accounts in seconds.
4. Make a Plan In Case of Aggressive Behaviour
As a cup-half-full type, I’m not a fan of negativity but I am a fan of plans. So, I do recommend creating an action plan for your kids in case they encounter something tricky online, in particular bullying or aggressive behaviour. I recommend you tell them to take screenshots, disengage, tell someone they trust (ideally you), and report the behaviour to the relevant social media platform or app. In some cases, you could involve your child’s school however this obviously depends on the perpetrator.
5. Passwords please!
I know you have probably heard it before, but password management is such a powerful way of staying safe online. In an ideal world, every online account should have its own unique password. Why? Well, if your logins get stolen in a data breach then the cybercriminals will not be able to reuse them to log into any of your other accounts.
And while you’re at it, ensure all passwords are at least 8-10 characters long, and contain random symbols, numbers and both upper and lowercase letters. If all is too hard, simply engage a password manager that will both generate and remember all the passwords for you. What a relief!
And of course, it goes without saying that a big part of being safe online is having super-duper internet protection software that will give you (and your family members) the best chance of a safe and secure online experience. McAfee+’s family plans not only give you a secure VPN, 24/7 identity and financial monitoring and alerts but AI-powered scam protection and advanced anti-virus that will protect each of your family members from fake texts, risky links, viruses, malware and more. Sounds like a plan to me!!
Till next time
Stay safe everyone!
Alex
The post What Security Means to Families appeared first on McAfee Blog.
Reconnaissance is the first phase of penetration testing which means gathering information before any real attacks are planned So Ashok is an Incredible fast recon tool for penetration tester which is specially designed for Reconnaissance" title="Reconnaissance">Reconnaissance phase. And in Ashok-v1.1 you can find the advanced google dorker and wayback crawling machine.
FreshRSS 
- Wayback Crawler Machine
- Google Dorking without limits
- Github Information Grabbing
- Subdomain Identifier
- Cms/Technology Detector With Custom Headers
~> git clone https://github.com/ankitdobhal/Ashok
~> cd Ashok
~> python3.7 -m pip3 install -r requirements.txt
A detailed usage guide is available on Usage section of the Wiki.
But Some index of options is given below:
Ashok can be launched using a lightweight Python3.8-Alpine Docker image.
$ docker pull powerexploit/ashok-v1.2
$ docker container run -it powerexploit/ashok-v1.2 --help
“Vishing” occurs when criminals cold-call victims and attempt to persuade them to divulge personal information over the phone. These scammers are generally after credit card numbers and personal identifying information, which can then be used to commit financial theft. Vishing can occur both on your landline phone or via your cell phone.
The term is a combination of “voice,” and “phishing,” which is the use of spoofed emails to trick targets into clicking malicious links. Rather than email, vishing generally relies on automated phone calls that instruct targets to provide account numbers. Techniques scammers use to get your phone numbers include:
Once vishers have phone numbers, they employ various strategies to deceive their targets and obtain valuable personal information:
To protect yourself from vishing scams, you should:
Staying vigilant and informed is your best defense against vishing scams. By verifying caller identities, being skeptical of unsolicited requests for personal information, and using call-blocking tools, you can significantly reduce your risk of falling victim to these deceptive practices. Additionally, investing in identity theft protection services can provide an extra layer of security. These services monitor your personal information for suspicious activity and offer assistance in recovering from identity theft, giving you peace of mind in an increasingly digital world. Remember, proactive measures and awareness are key to safeguarding your personal information against vishing threats.
The post How to Protect Yourself from Vishing appeared first on McAfee Blog.
A tool to find a company (target) infrastructure, files, and apps on the top cloud providers (Amazon, Google, Microsoft, DigitalOcean, Alibaba, Vultr, Linode). The outcome is useful for bug bounty hunters, red teamers, and penetration testers alike.
The complete writeup is available. here
we are always thinking of something we can automate to make black-box security testing easier. We discussed this idea of creating a multiple platform cloud brute-force hunter.mainly to find open buckets, apps, and databases hosted on the clouds and possibly app behind proxy servers.
Here is the list issues on previous approaches we tried to fix:
Microsoft: - Storage - Apps
Amazon: - Storage - Apps
Google: - Storage - Apps
DigitalOcean: - storage
Vultr: - Storage
Linode: - Storage
Alibaba: - Storage
1.0.0
Just download the latest release for your operation system and follow the usage.
To make the best use of this tool, you have to understand how to configure it correctly. When you open your downloaded version, there is a config folder, and there is a config.YAML file in there.
It looks like this
providers: ["amazon","alibaba","amazon","microsoft","digitalocean","linode","vultr","google"] # supported providers
environments: [ "test", "dev", "prod", "stage" , "staging" , "bak" ] # used for mutations
proxytype: "http" # socks5 / http
ipinfo: "" # IPINFO.io API KEY
For IPINFO API, you can register and get a free key at IPINFO, the environments used to generate URLs, such as test-keyword.target.region and test.keyword.target.region, etc.
We provided some wordlist out of the box, but it's better to customize and minimize your wordlists (based on your recon) before executing the tool.
After setting up your API key, you are ready to use CloudBrute.
██████╗██╗ ██████╗ ██╗ ██╗██████╗ ██████╗ ██████╗ ██╗ ██╗████████╗███████╗
██╔════╝██║ ██╔═══██╗██║ ██║██╔══██╗██╔══██╗██╔══██╗██║ ██║╚══██╔══╝██╔════╝
██║ ██║ ██║ ██║██║ ██║██║ ██║██████╔╝██████╔╝██║ ██║ ██║ █████╗
██║ ██║ ██║ ██║██║ ██║██║ ██║██╔══██╗██╔══██╗██║ ██║ ██║ ██╔══╝
╚██████╗███████╗╚██████╔╝╚██████╔╝██████╔╝██████╔╝██║ ██║╚██████╔╝ ██║ ███████╗
╚═════╝╚══════╝ ╚═════╝ ╚═════╝ ╚═════╝ ╚═════╝ ╚═╝ ╚═╝ ╚═════╝ ╚═╝ ╚══════╝
V 1.0.7
usage: CloudBrute [-h|--help] -d|--domain "<value>" -k|--keyword "<value>"
-w|--wordlist "<value>" [-c|--cloud "<value>"] [-t|--threads
<integer>] [-T|--timeout <integer>] [-p|--proxy "<value>"]
[-a|--randomagent "<value>"] [-D|--debug] [-q|--quite]
[-m|--mode "<value>"] [-o|--output "<value>"]
[-C|--configFolder "<value>"]
Awesome Cloud Enumerator
Arguments:
-h --help Print help information
-d --domain domain
-k --keyword keyword used to generator urls
-w --wordlist path to wordlist
-c --cloud force a search, check config.yaml providers list
-t --threads number of threads. Default: 80
-T --timeout timeout per request in seconds. Default: 10
-p --proxy use proxy list
-a --randomagent user agent randomization
-D --debug show debug logs. Default: false
-q --quite suppress all output. Default: false
-m --mode storage or app. Default: storage
-o --output Output file. Default: out.txt
-C --configFolder Config path. Default: config
for example
CloudBrute -d target.com -k target -m storage -t 80 -T 10 -w "./data/storage_small.txt"
please note -k keyword used to generate URLs, so if you want the full domain to be part of mutation, you have used it for both domain (-d) and keyword (-k) arguments
If a cloud provider not detected or want force searching on a specific provider, you can use -c option.
CloudBrute -d target.com -k keyword -m storage -t 80 -T 10 -w -c amazon -o target_output.txt
Read the usage.
Make sure you read the usage correctly, and if you think you found a bug open an issue.
It's because you use public proxies, use private and higher quality proxies. You can use ProxyFor to verify the good proxies with your chosen provider.
change -T (timeout) option to get best results for your run.
Inspired by every single repo listed here .
Citing national security concerns, the U.S. Department of Commerce has issued a ban on the sale of all Kaspersky online protection software in the U.S. This ban takes effect immediately.
Of major importance to current customers of Kaspersky online protection, the ban also extends to security updates that keep its protection current. Soon, Kaspersky users will find themselves unprotected from the latest threats.
Current Kaspersky users have until September 29, 2024 to switch to new online protection software. On that date, updates will cease. In fact, the Department of Commerce shared this message with Kaspersky customers:
“I would encourage you, in as strong as possible terms, to immediately stop using that [Kaspersky] software and switch to an alternative in order to protect yourself and your data and your family.”
As providers of online protection ourselves, we believe every person has the right to be protected online. Of course, we (and many industry experts!) believe McAfee online protection to be second to none, but we encourage every single person to take proactive steps in securing their digital lives, whether with McAfee or a different provider. There is simply too much at stake to take your chances. The nature of life online today means we are living in a time of rising cases of online identity theft, data breaches, scam texts, and data mining.
If you’re a current Kaspersky US customer, we hope you’ll strongly consider McAfee as you look for a safe and secure replacement. For a limited time, you can get a $10 discount to switch to McAfee using code MCAFEEKASUS10 at checkout.
With that, we put together a quick Q&A for current Kaspersky users who need to switch their online protection software quickly. And as you’ll see, the Department of Commerce urges you to switch immediately.
Yes. The Department of Commerce has issued what’s called a “Final Determination.” In the document, the government asserts that:
“The Department finds that Kaspersky’s provision of cybersecurity and anti-virus software to U.S. persons, including through third-party entities that integrate Kaspersky cybersecurity or anti-virus software into commercial hardware or software, poses undue and unacceptable risks to U.S. national security and to the security and safety of U.S. persons.”
(i) This news follows the 2017 ban on using Kaspersky software on government devices. (ii) That ban alleged that Russian hackers used the software to steal classified materials from a device that had Kaspersky software installed. (iii) Kaspersky has denied such allegations.
Yes. In addition to barring new sales or agreements with U.S. persons from July 20, the ban also applies to software updates. Like all online protection software, updates keep people safe from the latest threats. Without updates, the software leaves people more and more vulnerable over time. The update piece of the ban takes hold on September 29. With that, current users have roughly three months to get new online protection that will keep them protected online.
The answer depends on your device. The links to the following support pages can walk you through the process:
Today, you need more than anti-virus to keep you safe against the sophisticated threats of today’s digital age. You need comprehensive online protection. By “comprehensive” we mean software that protects your devices, identity, and privacy. Comprehensive online protection software from McAfee covers all three — because hackers, scammers, and thieves target all three.
“Comprehensive” also means that your software continues to grow and evolve just as the internet does. It proactively rolls out new features as new threats appear, such as:
Scam Protection that helps protect you against the latest scams via text, email, QR codes, and on social media. Also, should you accidentally click, web protection blocks sketchy links that crop up in searches and sites.
Social Privacy Manager that helps you adjust more than 100 privacy settings across your social media accounts in only a few clicks. It also protects privacy on TikTok, making ours the first privacy service to protect people on that platform. For families, that means we now cover the top two platforms that teens use, TikTok and YouTube.
AI-powered protection that doesn’t slow you down. For more than a decade, our award-winning protection has used AI to block the latest threats — and today it provides 3x faster scans with 75% fewer processes running on the PC. Independent tests from labs like AV-Comparatives have consistently awarded McAfee with the highest marks for both protection and for performance.
What should I do about the Kaspersky ban?
As the Department of Commerce urges, switch now.
Yet, make a considered choice. Comprehensive online protection software that looks out for your devices, identity, and privacy is a must — something you are likely aware of already as a Kaspersky user.
We hope this rundown of the Kaspersky news helps as you seek new protection. And we also hope you’ll give us a close look. Our decades-long track record of award-winning protection and the highest marks from independent labs speaks to how strongly we feel about protecting you and everyone online. Kaspersky US customers can get a discount to switch to McAfee for a limited time, using code MCAFEEKASUS10 at checkout.
The post The Kaspersky Software Ban—What You Need to Know to Stay Safe Online appeared first on McAfee Blog.
As the summer sun beckons us to explore new destinations, many of us rely on public Wi-Fi to stay connected while on the go. Whether checking emails, browsing social media, or planning our next adventure, access to Wi-Fi has become an essential part of our travel experiences. However, amidst the convenience lies a lurking threat to our cybersecurity. Public Wi-Fi networks are typically unencrypted, meaning data transmitted over these networks can be intercepted by hackers.
A study found that 40% of respondents have had their information compromised while using public Wi-Fi. In one notorious incident, a hacker accessed a journalist’s confidential work emails through in-flight Wi-Fi and then confronted him at baggage claim to reveal the breach. Often, individuals remain unaware of such compromises until well after the fact.
Since public Wi-Fi networks are often unsecure and used by many people, they are prime targets for cybercriminals looking to steal personal information such as passwords, credit card numbers, and other sensitive data. But fear not! With the right precautions, you can enjoy your summer travels while keeping your data safe and secure.
1. Understanding the Risks: Before delving into the world of public Wi-Fi, it’s crucial to understand the risks involved. Public networks, such as those found in cafes, airports, and hotels, are often unencrypted, meaning that cybercriminals can intercept data transmitted over these networks. This puts your sensitive information, including passwords, credit card details, and private messages, at risk of being compromised.
2. Utilize a Virtual Private Network: One of the most effective ways to safeguard your data while using public Wi-Fi is by using a Virtual Private Network (VPN). A VPN encrypts your internet connection, creating a secure tunnel between your device and the internet. This encryption prevents hackers from intercepting your data, ensuring your online activities remain private and secure. Invest in a reputable VPN service and install it on your devices before embarking on your summer adventures for added protection. Check out our step-by-step tutorial if it’s your first time setting up a VPN.
3. Keep Software Updated: Another essential aspect of cybersecurity is keeping your devices and software up-to-date. Updates often include security patches that address vulnerabilities and protect against emerging threats. Before setting off on your summer travels, install any available updates for your operating system, web browser, and security software. This simple step can significantly reduce the risk of falling victim to cyberattacks while connected to public Wi-Fi networks.
4. Enable Multi-Factor Authentication: Adding an extra layer of security to your online accounts can help prevent unauthorized access, even if your passwords are compromised. Multi-factor authentication (MFA) requires you to provide two or more forms of verification before accessing your accounts, such as a password, a fingerprint scan, or a one-time code sent to your mobile device. Enable MFA on your email, social media, and banking accounts before your travels to enhance your cybersecurity defenses.
5. Exercise Caution: Avoid accessing sensitive information while connected to public Wi-Fi. Refrain from logging into banking or shopping accounts and accessing confidential work documents while connected to unsecured networks. Instead, save these tasks for when you’re connected to a trusted network or using your mobile data.
6. Practice Good Password Hygiene: While connected to public Wi-Fi, it’s crucial to use strong, unique passwords for all your accounts. Avoid using easily guessable passwords or reusing the same password across multiple accounts, as this increases the risk of unauthorized access to your sensitive information. Consider using a reputable password manager to generate and store complex passwords securely.
7. Consider a Personal Hotspot: Using a personal hotspot instead of public Wi-Fi networks can often be a safer choice. Many mobile devices allow you to create a secure Wi-Fi network using your cellular data connection. Check your phone provider’s data plan beforehand to ensure this option doesn’t incur additional data charges.
Connecting to public Wi-Fi safely during your summer travels requires awareness and preparation. By taking steps like utilizing a VPN, keeping your software updated, and enabling MFA, you can enjoy the convenience of staying connected while protecting your personal information from cyber threats.
To further safeguard your digital devices, explore McAfee’s array of software solutions to discover the perfect fit for your security requirements. With the right cybersecurity tools, it’s easy to surf the web securely while exploring new destinations during your summer adventures.
The post How to Safely Connecting to Public Wi-Fi While Traveling appeared first on McAfee Blog.
I've been harbouring some thoughts about the state of data breaches over recent months, and I feel they've finally manifested themselves into a cohesive enough story to write down. Parts of this story relate to very sensitive incidents and parts to criminal activity, not just on behalf of those executing data breaches but also very likely on behalf of some organisations handling them. As such, I'm not going to refer to any specific incidents or company names, rather I'm going to speak more generally to what I'm seeing in the industry.
Generally, when I disclose a breach to an impacted company, it's already out there in circulation and for all I know, the company is already aware of it. Or not. And that's the problem: a data breach circulating broadly on a popular clear web hacking forum doesn't mean the incident is known by the corporate victim. Now, if I can find press about the incident, then I have a pretty high degree of confidence that someone has at least tried to notify the company involved (journos generally reach out for comment when writing about a breach), but often that's non-existent. So, too, are any public statements from the company, and I very often haven't seen any breach notifications sent to impacted individuals either (I usually have a slew of these forwarded to me after they're sent out). So, I attempt to get in touch, and this is where the pain begins.
I've written before on many occasions about how hard it can be to contact a company and disclose a breach to them. Often, contact details aren't easily discoverable; if they are, they may be for sales, customer support, or some other capacity that's used to getting bombarded with spam. Is it any wonder, then, that so many breach disclosures that I (and others) attempt to make end up going to the spam folder? I've heard this so many times before after a breach ends up in the headlines - "we did have someone try to reach out to us, but we thought it was junk" - which then often results in news of the incident going public before the company has had an opportunity to respond. That's not good for anyone; the breached firm is caught off-guard, they may very well direct their ire at the reporter, and it may also be that the underlying flaw remains unpatched, and now you've got a bunch more people looking for it.
An approach like security.txt is meant to fix this, and I'm enormously supportive of this, but in my experience, there are usually two problems:
That one instance was so exceptional that, honestly, I hadn't even looked for the file before asking the public for a security contact at the firm. Shame on me for that, but is it any wonder?
Once I do manage to make contact, I'd say about half the time, the organisation is good to deal with. They often already know of HIBP and are already using it themselves for domain searches. We've joked before (the company and I) that they're grateful for the service but never wanted to hear from me!
The other half of the time, the response borders on open hostility. In one case that comes to mind, I got an email from their lawyer after finally tracking down a C-suite tech exec via LinkedIn and sending them a message. It wasn't threatening, but I had to go through a series of to-and-fro explaining what HIBP was, why I had their data and how the process usually unfolded. When in these positions, I find myself having to try and talk up the legitimacy of my service without sounding conceited, especially as it relates to publicly documented relationships with law enforcement agencies. It's laborious.
My approach during disclosure usually involves laying out the facts, pointing out where data has been published, and offering to provide the data to the impacted organisation if they can't obtain it themselves. I then ask about their timelines for notifying impacted customers and welcome their commentary to be included in the HIBP notifications sent to our subscribers. This last point is where things get more interesting, so let's talk about breach notifications.
This is perhaps one of my greatest bugbears right now and whilst the title will give you a pretty good sense of where I'm going, the nuances make this particularly interesting.
I suggest that most of us believe that if your personal information is compromised in a data breach, you'll be notified following this discovery by the organisation responsible for the service. Whether it's one day, one week, or even a month later isn't really the issue; frankly, any of these time frames would be a good step forward from where we frequently find ourselves. But constantly, I'm finding that companies are taking the position of consciously not notifying individuals at all. Let me give you a handful of examples:
During the disclosure process of a recent breach, it turned out the organisation was already aware of the incident and had taken "appropriate measures" (their term was something akin to that being vague enough to avoid saying what had been done, but, uh, "something" had been done). When pressed for a breach notice that would go to their customers, they advised they wouldn't be sending one as the incident had occurred more than 6 months ago. That stunned me - the outright admission that they wouldn't be communicating this incident - and in case you're thinking "this would never be allowed under GDPR", the company was HQ'd well within that scope being based in a major European city.
Another one that I need to be especially vague about (for reasons that will soon become obvious), involved a sizeable breach of customer data with the folks exposed inhabiting every corner of the globe. During my disclosure to them, I pushed them on a timeline for notifying victims and found their responses to be indirect but almost certainly indicating they'd never speak publicly about it. Statements to the effect of "we'll send notifications where we deem we're legally obligated to", which clearly left it up to them to make the determination. I later learned from a contact close to the incident that this particular organisation had an impending earnings call and didn't want the market to react negatively to news of a breach. "Uh, you know that's a whole different thing if they deliberately cover that up, right?"
An important point to make here, though, is that when it comes to companies themselves disclosing they've been breached, disclosure to individuals is often not what people think it is. In the various regulatory regimes we have across the globe, the legal requirement often stops at notifying the regulator and does not extend to notifying the individual victims. This surprises many people, and I constantly hear the rant of "But I'm in [insert your country here], and we have laws that demand I'm notified!" No, you almost certainly don't... but you should. We all should.
You can see further evidence by looking at recent Form 8-K SEC filings in the US. There are many examples of filings from companies that never notified the individuals themselves, yet here, you'll clearly see disclosure to the regulator. The breach is known, it's been reported in the public domain, but good luck ever getting an email about it yourself.
During one disclosure, I had the good fortune of a very close friend of mine working for the company involved in an infosec capacity. They were clearly stalling, being well over a week from my disclosure yet no public statements or notices to impacted individuals. I had a quiet chat with my contact, who explained it as follows:
Mate, it's a room full of lawyers working out how to spin this
Meanwhile, millions of records of customer data were in the hands of criminals, and every hour that went by was another hour victims went without any knowledge whatsoever that their personal info had been exposed. And as much as it pains me to say this, I get it: the company's priority is the company or, more specifically, the shareholders. That's who the board is accountable to, and maintaining the corporate reputation and profitability of the firm is their number one priority.
I see this all the time in post-breach communication too. One incident that comes to mind was the result of some egregiously stupid technical decisions. Once that breach hit the press, the CEO immediately went on the offence. Blame was laid firstly at those who obtained the data, then at me for my reporting of the incident (my own disclosure was absolutely "by the book").
I'm talking about class actions. I wrote about my views on this a few years ago and nothing has changed, other than it getting worse. I regularly hear from data breach victims about them wanting compensation for the impact a breach has had on them yet when pushed, most struggle to explain why. We've had multiple recent incidents in Australia where drivers' licences have been exposed and required reissuing, which is usually a process of going to a local transport office and waiting in a queue. "Are you looking for your time to be compensated for?", I asked one person. We have to rotate our licenses every 5 years anyway, so would you pro-rata that time based on the hourly value of your time and when you were due to be back in there anyway? And if there has been identity theft, was it from the breach you're now seeking compensation for? Or the other ones (both known and unknown) from which your data was taken?
Lawyers are a big part of the problem, and I still regularly hear from them seeking product placement on HIBP. What a time and a place to cash in if you could get your class action pitch right there in front of people at the moment they learn they were in a breach!
Frankly, I don't care too much about individuals getting a few bucks in compensation (and it's only ever a few), and I also don't even care about lawyers doing lawyer things. But I do care about the adverse consequences it has on the corporate victims, as it makes my job a hell of a lot harder when I'm talking to a company that's getting ready to get sued because of the information I've just disclosed to them.
These are all intertwined problems without single answers. But there are some clear paths forward:
Firstly, and this seems so obvious that it's frankly ridiculous I need to write it, but there should always be disclosure to individual victims. This may not need to be with the same degree of expeditiousness as disclosure to the regulator, but it has to happen. It is a harder problem for businesses; submitting a form to a gov body can be infinitely easier than emailing potentially hundreds of millions of breached customers. However, it is, without any doubt, the right thing to do and there should be legal constructs that mandate it.
Simultaneously providing protection from frivolous lawsuits where no material harm can be demonstrated and throwing the book at firms who deliberately conceal breaches also seems reasonable. No company is ever immune from a breach, and so frequently, it occurs not due to malicious behaviour by the organisation but a series of often unfortunate events. Ambitious lawyers shouldn't be in a position where they can make hell for a company at their worst possible hour unless there there is significant harm and negligence that can be clearly attributed back to the incident.
And then there's all the periphery stuff that pours fuel on the current dumpster fire. The aforementioned beg bounties that cause companies to be suspicious of even the most genuine disclosures, for example. On the other hand, the standoff-ish behaviour of many organisations receiving reports from folks who just want to see incidents disclosed. Flip side again is the number of people occupying that periphery of "security researcher / extortionist" who cause the aforementioned behaviours described in this paragraph. It's a mess, and writing it down like this makes it so abundantly apparent how many competing objectives there are.
I don't see anything changing any time soon, and anecdotally, it's worse now than it was 5 or 10 years ago. In part, I suspect that's due to how all those undesirable behaviours I described above have evolved over time, and in part I also believe the increasingly complexity of external dependencies is driving this. How many breaches have we seen in just the last year that can be attributed to "a third party"? I quote that term because it's often used by organisations who've been breached as though it somehow absolves them of some responsibility; "it wasn't us who was breached, it was those guys over there". Of course, it doesn't work that way, and more external dependencies leads to more points of failure, all of which you're still accountable for even if you've done everything else right.
Ah well, as I often end up lamenting, it's a fascinating time to be in the industry 🤷♂️
Tool for Fingerprinting HTTP requests of malware. Based on Tshark and written in Python3. Working prototype stage :-)
Its main objective is to provide unique representations (fingerprints) of malware requests, which help in their identification. Unique means here that each fingerprint should be seen only in one particular malware family, yet one family can have multiple fingerprints. Hfinger represents the request in a shorter form than printing the whole request, but still human interpretable.
Hfinger can be used in manual malware analysis but also in sandbox systems or SIEMs. The generated fingerprints are useful for grouping requests, pinpointing requests to particular malware families, identifying different operations of one family, or discovering unknown malicious requests omitted by other security systems but which share fingerprint.
An academic paper accompanies work on this tool, describing, for example, the motivation of design choices, and the evaluation of the tool compared to p0f, FATT, and Mercury.
The basic assumption of this project is that HTTP requests of different malware families are more or less unique, so they can be fingerprinted to provide some sort of identification. Hfinger retains information about the structure and values of some headers to provide means for further analysis. For example, grouping of similar requests - at this moment, it is still a work in progress.
After analysis of malware's HTTP requests and headers, we have identified some parts of requests as being most distinctive. These include: * Request method * Protocol version * Header order * Popular headers' values * Payload length, entropy, and presence of non-ASCII characters
Additionally, some standard features of the request URL were also considered. All these parts were translated into a set of features, described in details here.
The above features are translated into varying length representation, which is the actual fingerprint. Depending on report mode, different features are used to fingerprint requests. More information on these modes is presented below. The feature selection process will be described in the forthcoming academic paper.
Minimum requirements needed before installation: * Python >= 3.3, * Tshark >= 2.2.0.
Installation available from PyPI:
pip install hfinger
Hfinger has been tested on Xubuntu 22.04 LTS with tshark package in version 3.6.2, but should work with older versions like 2.6.10 on Xubuntu 18.04 or 3.2.3 on Xubuntu 20.04.
Please note that as with any PoC, you should run Hfinger in a separated environment, at least with Python virtual environment. Its setup is not covered here, but you can try this tutorial.
After installation, you can call the tool directly from a command line with hfinger or as a Python module with python -m hfinger.
For example:
foo@bar:~$ hfinger -f /tmp/test.pcap
[{"epoch_time": "1614098832.205385000", "ip_src": "127.0.0.1", "ip_dst": "127.0.0.1", "port_src": "53664", "port_dst": "8080", "fingerprint": "2|3|1|php|0.6|PO|1|us-ag,ac,ac-en,ho,co,co-ty,co-le|us-ag:f452d7a9/ac:as-as/ac-en:id/co:Ke-Al/co-ty:te-pl|A|4|1.4"}]
Help can be displayed with short -h or long --help switches:
usage: hfinger [-h] (-f FILE | -d DIR) [-o output_path] [-m {0,1,2,3,4}] [-v]
[-l LOGFILE]
Hfinger - fingerprinting malware HTTP requests stored in pcap files
optional arguments:
-h, --help show this help message and exit
-f FILE, --file FILE Read a single pcap file
-d DIR, --directory DIR
Read pcap files from the directory DIR
-o output_path, --output-path output_path
Path to the output directory
-m {0,1,2,3,4}, --mode {0,1,2,3,4}
Fingerprint report mode.
0 - similar number of collisions and fingerprints as mode 2, but using fewer features,
1 - representation of all designed features, but a little more collisions than modes 0, 2, and 4,
2 - optimal (the default mode),
3 - the lowest number of generated fingerprints, but the highest number of collisions,
4 - the highest fingerprint entropy, but slightly more fingerprints than modes 0-2
-v, --verbose Report information about non-standard values in the request
(e.g., non-ASCII characters, no CRLF tags, values not present in the configuration list).
Without --logfile (-l) will print to the standard error.
-l LOGFILE, --logfile LOGFILE
Output logfile in the verbose mode. Implies -v or --verbose switch.
You must provide a path to a pcap file (-f), or a directory (-d) with pcap files. The output is in JSON format. It will be printed to standard output or to the provided directory (-o) using the name of the source file. For example, output of the command:
hfinger -f example.pcap -o /tmp/pcap
will be saved to:
/tmp/pcap/example.pcap.json
Report mode -m/--mode can be used to change the default report mode by providing an integer in the range 0-4. The modes differ on represented request features or rounding modes. The default mode (2) was chosen by us to represent all features that are usually used during requests' analysis, but it also offers low number of collisions and generated fingerprints. With other modes, you can achieve different goals. For example, in mode 3 you get a lower number of generated fingerprints but a higher chance of a collision between malware families. If you are unsure, you don't have to change anything. More information on report modes is here.
Beginning with version 0.2.1 Hfinger is less verbose. You should use -v/--verbose if you want to receive information about encountered non-standard values of headers, non-ASCII characters in the non-payload part of the request, lack of CRLF tags (\r\n\r\n), and other problems with analyzed requests that are not application errors. When any such issues are encountered in the verbose mode, they will be printed to the standard error output. You can also save the log to a defined location using -l/--log switch (it implies -v/--verbose). The log data will be appended to the log file.
Beginning with version 0.2.0, Hfinger supports importing to other Python applications. To use it in your app simply import hfinger_analyze function from hfinger.analysis and call it with a path to the pcap file and reporting mode. The returned result is a list of dicts with fingerprinting results.
For example:
from hfinger.analysis import hfinger_analyze
pcap_path = "SPECIFY_PCAP_PATH_HERE"
reporting_mode = 4
print(hfinger_analyze(pcap_path, reporting_mode))
Beginning with version 0.2.1 Hfinger uses logging module for logging information about encountered non-standard values of headers, non-ASCII characters in the non-payload part of the request, lack of CRLF tags (\r\n\r\n), and other problems with analyzed requests that are not application errors. Hfinger creates its own logger using name hfinger, but without prior configuration log information in practice is discarded. If you want to receive this log information, before calling hfinger_analyze, you should configure hfinger logger, set log level to logging.INFO, configure log handler up to your needs, add it to the logger. More information is available in the hfinger_analyze function docstring.
A fingerprint is based on features extracted from a request. Usage of particular features from the full list depends on the chosen report mode from a predefined list (more information on report modes is here). The figure below represents the creation of an exemplary fingerprint in the default report mode.
Three parts of the request are analyzed to extract information: URI, headers' structure (including method and protocol version), and payload. Particular features of the fingerprint are separated using | (pipe). The final fingerprint generated for the POST request from the example is:
2|3|1|php|0.6|PO|1|us-ag,ac,ac-en,ho,co,co-ty,co-le|us-ag:f452d7a9/ac:as-as/ac-en:id/co:Ke-Al/co-ty:te-pl|A|4|1.4
The creation of features is described below in the order of appearance in the fingerprint.
Firstly, URI features are extracted: * URI length represented as a logarithm base 10 of the length, rounded to an integer, (in the example URI is 43 characters long, so log10(43)≈2), * number of directories, (in the example there are 3 directories), * average directory length, represented as a logarithm with base 10 of the actual average length of the directory, rounded to an integer, (in the example there are three directories with total length of 20 characters (6+6+8), so log10(20/3)≈1), * extension of the requested file, but only if it is on a list of known extensions in hfinger/configs/extensions.txt, * average value length represented as a logarithm with base 10 of the actual average value length, rounded to one decimal point, (in the example two values have the same length of 4 characters, what is obviously equal to 4 characters, and log10(4)≈0.6).
Secondly, header structure features are analyzed: * request method encoded as first two letters of the method (PO), * protocol version encoded as an integer (1 for version 1.1, 0 for version 1.0, and 9 for version 0.9), * order of the headers, * and popular headers and their values.
To represent order of the headers in the request, each header's name is encoded according to the schema in hfinger/configs/headerslow.json, for example, User-Agent header is encoded as us-ag. Encoded names are separated by ,. If the header name does not start with an upper case letter (or any of its parts when analyzing compound headers such as Accept-Encoding), then encoded representation is prefixed with !. If the header name is not on the list of the known headers, it is hashed using FNV1a hash, and the hash is used as encoding.
When analyzing popular headers, the request is checked if they appear in it. These headers are: * Connection * Accept-Encoding * Content-Encoding * Cache-Control * TE * Accept-Charset * Content-Type * Accept * Accept-Language * User-Agent
When the header is found in the request, its value is checked against a table of typical values to create pairs of header_name_representation:value_representation. The name of the header is encoded according to the schema in hfinger/configs/headerslow.json (as presented before), and the value is encoded according to schema stored in hfinger/configs directory or configs.py file, depending on the header. In the above example Accept is encoded as ac and its value */* as as-as (asterisk-asterisk), giving ac:as-as. The pairs are inserted into fingerprint in order of appearance in the request and are delimited using /. If the header value cannot be found in the encoding table, it is hashed using the FNV1a hash.
If the header value is composed of multiple values, they are tokenized to provide a list of values delimited with ,, for example, Accept: */*, text/* would give ac:as-as,te-as. However, at this point of development, if the header value contains a "quality value" tag (q=), then the whole value is encoded with its FNV1a hash. Finally, values of User-Agent and Accept-Language headers are directly encoded using their FNV1a hashes.
Finally, in the payload features: * presence of non-ASCII characters, represented with the letter N, and with A otherwise, * payload's Shannon entropy, rounded to an integer, * and payload length, represented as a logarithm with base 10 of the actual payload length, rounded to one decimal point.
Hfinger operates in five report modes, which differ in features represented in the fingerprint, thus information extracted from requests. These are (with the number used in the tool configuration): * mode 0 - producing a similar number of collisions and fingerprints as mode 2, but using fewer features, * mode 1 - representing all designed features, but producing a little more collisions than modes 0, 2, and 4, * mode 2 - optimal (the default mode), representing all features which are usually used during requests' analysis, but also offering a low number of collisions and generated fingerprints, * mode 3 - producing the lowest number of generated fingerprints from all modes, but achieving the highest number of collisions, * mode 4 - offering the highest fingerprint entropy, but also generating slightly more fingerprints than modes 0-2.
The modes were chosen in order to optimize Hfinger's capabilities to uniquely identify malware families versus the number of generated fingerprints. Modes 0, 2, and 4 offer a similar number of collisions between malware families, however, mode 4 generates a little more fingerprints than the other two. Mode 2 represents more request features than mode 0 with a comparable number of generated fingerprints and collisions. Mode 1 is the only one representing all designed features, but it increases the number of collisions by almost two times comparing to modes 0, 1, and 4. Mode 3 produces at least two times fewer fingerprints than other modes, but it introduces about nine times more collisions. Description of all designed features is here.
The modes consist of features (in the order of appearance in the fingerprint): * mode 0: * number of directories, * average directory length represented as an integer, * extension of the requested file, * average value length represented as a float, * order of headers, * popular headers and their values, * payload length represented as a float. * mode 1: * URI length represented as an integer, * number of directories, * average directory length represented as an integer, * extension of the requested file, * variable length represented as an integer, * number of variables, * average value length represented as an integer, * request method, * version of protocol, * order of headers, * popular headers and their values, * presence of non-ASCII characters, * payload entropy represented as an integer, * payload length represented as an integer. * mode 2: * URI length represented as an integer, * number of directories, * average directory length represented as an integer, * extension of the requested file, * average value length represented as a float, * request method, * version of protocol, * order of headers, * popular headers and their values, * presence of non-ASCII characters, * payload entropy represented as an integer, * payload length represented as a float. * mode 3: * URI length represented as an integer, * average directory length represented as an integer, * extension of the requested file, * average value length represented as an integer, * order of headers. * mode 4: * URI length represented as a float, * number of directories, * average directory length represented as a float, * extension of the requested file, * variable length represented as a float, * average value length represented as a float, * request method, * version of protocol, * order of headers, * popular headers and their values, * presence of non-ASCII characters, * payload entropy represented as a float, * payload length represented as a float.
A vulnerable application made using node.js, express server and ejs template engine. This application is meant for educational purposes only.
git clone https://github.com/4auvar/VulnNodeApp.git
npm install
CREATE USER 'vulnnodeapp'@'localhost' IDENTIFIED BY 'password';
create database vuln_node_app_db;
GRANT ALL PRIVILEGES ON vuln_node_app_db.* TO 'vulnnodeapp'@'localhost';
USE vuln_node_app_db;
create table users (id int AUTO_INCREMENT PRIMARY KEY, fullname varchar(255), username varchar(255),password varchar(255), email varchar(255), phone varchar(255), profilepic varchar(255));
insert into users(fullname,username,password,email,phone) values("test1","test1","test1","test1@test.com","976543210");
insert into users(fullname,username,password,email,phone) values("test2","test2","test2","test2@test.com","9887987541");
insert into users(fullname,username,password,email,phone) values("test3","test3","test3","test3@test.com","9876987611");
insert into users(fullname,username,password,email,phone) values("test4","test4","test4","test4@test.com","9123459876");
insert into users(fullname,username,password,email,phone) values("test5","test5","test 5","test5@test.com","7893451230");
npm start
You can reach me out at @4auvar
This has to be a first. Something from our blogs got made into a movie.
We’re talking about voice scams, the soundalike calls that rip people off. One such call sets the action in motion for a film released this weekend, “Thelma.”
The synopsis of the comedy reads like this …
“When 93-year-old Thelma Post gets duped by a phone scammer pretending to be her grandson, she sets out on a treacherous quest across the city to reclaim what was taken from her.”
Voice scams have been around for some time. They play out like an email phishing attack, where scammers try to trick people into forking over sensitive info or money — just in voice form over the phone. The scammer poses as someone the victim knows, like a close family member.
Yet the arrival of AI has made voice scams far more convincing. Cheap and freely available AI voice cloning tools have flooded the online marketplace in the past couple of years. They’re all completely legal as well.
Some cloning tools come in the form of an app. Others offer cloning as a service, where people can create a clone on demand by uploading audio to a website. The point is, practically anyone can create a voice clone. They sound uncanny too. Practically like the real thing, and certainly real enough over the phone. And it only takes a small sample of the target’s voice to create one.
Our own labs found that just a few seconds of audio was enough to produce a clone with an 85% voice match to the original. That number bounced up to 95% when they trained the clone further on a small batch of audio pulled from videos.
As to how scammers get a hold of the files they need, they have a ready source. Social media. With videos harvested from public accounts on YouTube, Instagram, TikTok, and other platforms, scammers have little trouble creating clones — clones that say whatever a scammer wants. All it takes is a script.
That’s where the attack comes in. It typically starts with a distress call, just like in the movie.
For example, a grandparent gets an urgent message on the phone from their grandchild. They’re stuck in the middle of nowhere with a broken-down car. They’re in a hospital across the country with a major injury. Or they’re in jail overseas and need to get bailed out. In every case, the solution to the problem is simple. They need money. Fast.
Sure, it’s a scam. Yet in the heat of the moment, it all sounds terribly real. Real enough to act right away.
Fearing the worst and unable to confirm the situation with another family member, the grandparent shoots the money off as instructed. Right into the hands of a scammer. More often than not, that money is gone for good because the payment was made with a wire transfer or through gift cards. Sometimes, victims pay out in cash.
Enter the premise for the movie. Thelma gets voice-scammed for thousands, then zips across Los Angeles on her friend’s mobility scooter to get her money back from the voice scammers.
The reality is of course more chilling. According to the U.S. Federal Trade Commission (FTC), nearly a million people reported a case of imposter fraud in 2023. Total reported losses reached close to $2.7 billion. Although not tracked and reported themselves, voice clone attacks certainly figure into this overall mix.
Even as we focus on the character of Thelma, voice clone attacks target people of all ages. Parents have reported cases involving their children. And married couples have told of scams that impersonate their older in-laws.
Common to each of these attacks is one thing: fear. Something horrible has happened. Or is happening. Here, scammers look to pull an immediate emotional trigger. Put plainly, they want to scare their victim. And in that fear, they hope that the victim immediately pays up.
It’s an odds game. Plenty of attacks fail. A parent might be sitting at the dinner table with their child when a voice clone call strikes. Or a grandchild might indeed be out of town, yet traveling with their grandmother when the scammer gives her a ring.
Yet if even a handful of these attacks succeed, a scammer can quickly cash in. Consider one attack for hundreds, if not thousands, or dollars. Multiply that by five, ten, or a dozen or so times over, a few successful voice clone scams can rack up big returns.
Yet you can protect yourself from these attacks. A few steps can make it more difficult for scammers to target you. A few others can prevent you from getting scammed if a voice clone pops up on the other end of the phone.
Make it tougher for scammers to target you by:
Clear your name from data broker sites. How’d that scammer get your phone number anyway? Chances are, they pulled that info off a data broker site. Data brokers buy, collect, and sell detailed personal info, which they compile from several public and private sources, such as local, state, and federal records, in addition to third parties. Our Personal Data Cleanup scans some of the riskiest data broker sites, shows you which ones are selling your personal info, and helps you remove your data.
Set your social media accounts to private. Scammers sift through public social media profiles in search of info on their targets. In some cases, an account can provide them with everything they need to launch an attack. Family names, family interests, where the family goes for vacation, where family members work — and videos that they can use for cloning. By making your accounts private, you deny scammers the resources they require. Our Social Privacy Manager can do this for you across all your accounts in only a few clicks.
Prevent getting scammed by:
Recognize that voice clone attacks are a possibility. As we’re still in the relatively early days of AI tools, not everyone is aware that this kind of attack is possible. Keeping up to date on what AI can do and sharing that info with your family and friends can help them spot an attack. As we’ve reported here before, voice clones are only the start. Other imposter scams run on video calls where a scammer takes on someone else’s voice and looks. All in real-time.
Always question the source. In addition to voice cloning tools, scammers have other tools that can spoof phone numbers so that they look legitimate. Even if it’s a voicemail or text from a number you recognize, stop, pause, and think. Does that really sound like the person you think it is? Hang up and call the person directly or try to verify the info before responding.
Set a verbal codeword with kids, family members, or trusted close friends. Even in the most high-tech of attacks, a low-tech precaution can keep everyone safe. Have a codeword. Save it for emergencies. Make sure everyone uses it in messages and calls when they ask for help. Further, ensure that only you and those closest to you know what the codeword is. This is much like the codewords that banks and alarm companies use to help ensure that they’re speaking to the proper account holder. It’s a simple, powerful step. And a free one at that.
The post Thelma – The Real-Life Voice Scam That Made It into the Movies appeared first on McAfee Blog.
