Expert Talk: Hack Like a Pro: Bug Bounties, Web Vulnerabilities & More!

Join us for an engaging conversation between Ben Sadeghipour, VP of Research at Hadrian Security, and Julian Wood, Developer Advocate at AWS. In this conversation, we will explore a range of captivating topics, such as: Bug bounties, ethical hacking, Skills, Resources, tips and much more.

Whether you're an aspiring ethical hacker or simply interested in the fascinating world of cybersecurity, this video is packed with knowledge and practical advice. Get ready to hack like a pro, learn how you can convert bug bounty hunting into a passive income while you sleep and join us on this exciting journey to make the online world a safer place!

Intro

Julian Wood: Welcome to another episode of GOTO Unscripted. We're here at GOTO Copenhagen in lovely Denmark, and certainly in Copenhagen. And I'm super happy to be joined by, well, I know it's the amazing Ben Sadeghipour. Ben, how are you doing today?

Ben Sadeghipour: Good, thank you for asking. How about you?

Julian Wood: No, I'm very good. Thank you very much. You've come all the way from California. So is this your first time in Denmark or have you been before?

Ben Sadeghipour: First time in Denmark. It's one of those countries that I wanted to visit, but I just never got to. So being here gave me the reason to both visit and come also to the conference and speak.

Julian Wood: Well, I hope at least you've had a Danish when you've been here.

Ben Sadeghipour: That was the first thing I did.

Julian Wood: Exactly. Scout those bakeries and get a Danish.

Ben Sadeghipour: There's a few of them behind those menus, so I became a regular already.

Julian Wood: I'm glad to hear it. So you are VP of research at Hadrian Security. Is it Hadrian Security?

Ben Sadeghipour: Yes.

Julian Wood: So I live in England, at Hadrian's wall, is that connected with security being something that you break through, or?

Ben Sadeghipour: It's pretty much what we do, we break through things. It's more of an attack software management meets red team automation. So a lot of like testing, security testing, but also like mapping out what an organization has online, their presence, their websites, their assets. We identify 'em and then find ways to break into them through automation, by working with our platform.
Bug Bounties: Exploring Opportunities & Best Practices in Ethical Hacking

Julian Wood: So are you sort of the pen testers in the real world? I mean, your background as an ethical hacker, how did that sort of start and was there a non-ethical before then, or you've just always been interested in security research?

Ben Sadeghipour: So I was, how do I say this? I've always done hacking, but I didn't know I was hacking. So the story goes, I wanted to play video games. This is something I've always talked about. Like, I was a kid, I wanted to play video games. I had an older brother, and it was his computer. And he always had a password on it, some sort of protection, so I can't go on it. And that was my first victim. Learned what brute-forcing was at a young age. Didn't know it was brute-forcing at the time, but, I wanted just go on the computer. And then I found default passwords from Windows, you know, how do I bypass authentication on a Windows? Just never thought it was hacking. Eventually, I got into hacking at a young age, but there wasn't any future in it.

Being a 16-year-old, you don't think anyone's gonna want to hire you or anything like that. But then later on I heard about Bug Bounties. I have a friend of mine who came up to me and was like, "Hey, man, you should make money from hacking." And I'm like, "No, I don't want to go to jail. I don't want you to do anything illegal." He's like, "No, look up Bug Bounty." Just go type in Yahoo, and the word "Bug Bounty." And I guess Yahoo was one of the first companies alongside Google and Facebook that were doing Bug Bounties. And I kind of heard about Bug Bounty. And you know, if people aren't familiar with Bug Bounty, if you find a vulnerability, you exploit and report it to this company, and they pay you for it. And nowadays, almost every big tech company has a Bug Bounty program or a way to work with them.

Julian Wood: There must be some intense competition for finding bugs in those kinds of things. Are you a competitive bug hunter yourself?

Ben Sadeghipour: I used to be very competitive but I don't have that drive anymore. But early on there was a gap...for both HackerOne, who I ended up working with full-time. Eventually, I got hired by the...bar crowd, one of their competitors always in the top 10. I had to stay in the top 10 for a...actually, I learned like, it doesn't mean anything, it doesn't accomplish anything. It's a good bragging right. It makes you more credible, it gives you more opportunities but doesn't mean much in the real world other than just gamifying it and making it competitive.

Julian Wood: Any particular sort of Bug Bounty programs that you think work really well or... And I suppose on the other side of it, if companies are wanting to set up Bug Bounty programs, what are the good things they should be doing, and what are the bad things that are sort of the wrong incentives or...? How would you explain that?

Ben Sadeghipour: I think there is a ton of good Bug Bounty programs out there. Apple is a big one. Yahoo's a good one. Google has a really, really good one. My favorite ones are, I hacked on Airbnb a lot for a while. I haven't done that in a long time. I enjoyed working with them a lot. But I mean, at the end of the day, I think the way I say it is if you have an online presence, hackers...well, I don't wanna say hackers it's cyber criminals and adversaries are always going to hack into your network or your applications, so you might as well just invite good ethical hackers to work with you. And the first step is always, what we call... Well, when it's called Everyone Library Disclosure Program, that's when it's okay, to see something, say something.

So you see a vulnerability, you report it, but you don't get paid for it. I know people are gonna in the comments and gonna come and say, "Hey, don't do free work." The point isn't to do free work. It's more of establishing a channel for hackers to work with companies that are not ready yet to pay Bug Bounty. And I think that's a great place to start because it opens up a place where people, if I'm browsing your website, for example. I'm shopping online on your website, I find something critical, I wanna report to you, where do I go? Having that established is a very good step.

Julian Wood: So is this literally even having an email address on your webpage, or security team, or something like that people...?

Ben Sadeghipour: And also a couple of other things that I would recommend is having an inventory of your assets so you know what's owned by you, what's a priority for you, what applications have PIIs or private information for users. Having that understanding is a good one. Also, do some pen tests. Get rid of some of those low-hanging foods. It's good for Bug Bounty hunters if you don't, they're gonna make money, but you wanna make sure you have an understanding of security, but you also have some sort of an internal process to receive vulnerabilities, get 'em fixed in an appropriate time, because hackers are gonna ask you, "Is this fixed? Is this fixed?" So having the two of those would be very, very good. Inventory of assets, some testing, and some internal process to handle reports.

Julian Wood: When people, I will say sometimes inevitably do get hacked, there are gonna be sort of good responses and bad responses. How should companies, when they have been hacked, disclose what's been going on? What are the good things you would like to see, and what are the really bad things you hope not to see?

Ben Sadeghipour: I can't give you examples, unfortunately, but there's been a lot of recent breaches that happened to bigger corporations, huge ones that have been breached. And the first step is just the transparency of it. Be transparent that this did happen. Don't let the news come out and say this happened. It's always better when you explain, and also investigate what happened. I think the biggest thing for an outsider, like myself the perspective is, it's good when companies are willing to share what went wrong and why did this breach happen. It's gonna come out eventually, it's gonna come out in the news. But when they disclose that information, it gives other organizations a sense of understanding of what went wrong or what could have gone wrong, for them to prevent this from happening. So they can put the right process in place, or they can put the right training for their employees in place. I think that's the biggest thing. It's just the transparency and also doing an analysis of what happened, and also disclosing it for other organizations to understand so they could prevent it from happening in the future.

Recommended talk: A Personal Story about Ethical Hacking • Ben Sadeghipour @NahamSec • GOTO 2022

Unveiling Web Vulnerabilities: From Cross-Site Scripting to SSRF & IDOR

Julian Wood: Okay. And even sort of technology, what are the, I suppose, most common kind of vulnerabilities websites? I mean, we hear about you cross-site scripting and SQL injections and all these kind of things. Is that mostly a solved problem now or you still find those kind of things? And then what sort of security vulnerabilities should people be looking at, or open doors should people be looking at?

Ben Sadeghipour: Cross-site scripting is still a thing. Unfortunately, I don't think it's ever going to go away. Unless we find a way to not take, like, user input and user data, I don't think it's going to go away. I think it's more common with legacy sites. A lot of the bigger organizations that have been around for years, I think they're more prone to have them. I don't want to say it's completely fixed, but the more modern stack technologies are, they use libraries and they use other third-party things to prevent cross-site scripting, but it still happens. I'd be surprised to say it never happens, honestly. That's a really big one. But depending, I think with today's technology it's harder to exploit. You have, you know, things that are in place that could prevent it. People have other ways of handling cookies and things like that.

The other two big ones are something that I did a lot of research on and really enjoy is a vulnerability called, Server-Side Request Forgery. Which pretty much allows you to use your application as an internal resource to talk to things that are behind a VPN, for example. So it's gated in another network. But because this application speaks to it, if they hack into this application, they can also speak to these other services. So I would give an example for AWS. If you have an SSRF on AWS, you can query metadata where your keys are stored, for example, that gives you access to other applications. Or it could be that you can talk to some other microservices behind it or stuff that is supposed to be internal. And you can find those in anything, any of the integrations, any web hooks. PDF generators are a big one and a fun one.

I did a year of research on those, which was really, really cool. And it's just the possibilities of things you can do with an SSRF is just unlimited. You can either command execute, you can query data, you can speak to services. It's just incredible what you can do with it. To name a few companies, I think Snapchat, Lyft, Verizon Media were some of the recent ones that I found these vulnerabilities in. And then the third one is an Insecure Direct Object Reference, IDOR. If you go to the API, so when you query your profile, it's gonna go to an API, it's gonna say, "Hey, here's my user ID." Unfortunately, in a lot of cases that is an integer, that's incremented by one for every user.

So I'm user 1, you're user 2, 3, 4, 5, 6, and all the way to like a million. And if you change that ID and the API call from one to two, in most cases I've seen actually, the user information for the other user. That alone isn't a vulnerability. But in some cases that API call could be,user ID/address that gives you an entire address. It could be, let's say for example, a shopping site, it could be everything you have bought. It could be a receipt, it could be an invoice. It's invoice/12345. I go through and I say, 12346. And that gives me your address, what you have bought, your last for your credit card number, and all those like PIIs. So that's a really big one that I still see to this day. It's more of an authentication authorization issue, but it's still very, very common nowadays in modern day's applications.

Recommended talk: Think like a Hacker • Matt Brunt • GOTO 2019

API Security Unveiled: From Authentication to Cloud Complexity

Julian Wood: So, is there any API design stuff that people should be thinking about? Because one is authorization authentication once you're in, but people are wanting their APIs to be simple to consume. But then it maybe does make it even easier to be able to traverse these paths and guess, /invoice, /details or that kind of thing?

Ben Sadeghipour: There's a lot. I mean, the big one is just authentication authorization. Don't assume that you're handling things. It gets even messier when it's like organizations, because in other organizations you have different user roles, and different users. There always the assumption is because they're gated they can't speak to each other. That's not the case really. You just have to traverse other organizations and then brute-force for the next user ID. Other than that, there's a ton of different things. I think one would be, not assuming just because their functionality is invisible in the user interface it is not accessible or discoverable.

Julian Wood: Security by obscurity.

Ben Sadeghipour: Just because you're not visibly showing the users' functionality, it doesn't mean that I can't find it through your JavaScript files, for example. Or that I can't just brute-force for, I guess the folder file name for it. Those are the two big ones. And also how you parse data when the user's sending you data and how you're sanitizing that data.

Julian Wood: User sanitization in the function of the code as soon as it's arriving or even on the APIs. I know a lot of API products have hopefully robust user sanitization or use at least a mapping template that you need to go through, to check that you're not sending some strange stuff.

Ben Sadeghipour: And then just not assuming things. Just not assuming that, already been checked, already been secured, whatever that is. The assumption is the biggest one.

Julian Wood: Does the cloud make any of this security simpler or does it make it complicated? I presume it's also more nuanced that it can be both.

Ben Sadeghipour: I think it can be both. I think it makes it secure because they give you more tools to, make these things secure. When you're, for example, using AWS, you have all these different things that could help you protect your application and user's data. But at the same time, if they're not gated properly, one application gets hacked, if you haven't separated 'em by the keys, by the user rules and the IMs, then everything you'll pretty much give 'em the keys of the kingdom. And you'd be surprised how many times that's happened. When I hack into a company, I get some sort of keys for 'em, I have access to everything because whoops, they forgot to, uncheck that one box. But it's a bit of both. They give you the resources, but it's also very complicated. There are so many resources and all these different micro apps that you can use, but then the users confuse about how do you use every single one of them. How do you make 'em talk to each other? So I think it does a little bit of both.

Julian Wood: And I suppose that comes back to what you're saying before, having an inventory of all your resources and what you have, so at least you know what you need to protect rather than just flying blind. Just protecting your API, you need to step back from that and have protection mechanisms for your data, whether that's at risk or in flight, and how it's stored, and how it's accessed as well.

Ben Sadeghipour: Absolutely. I think having that inventory helps you know what's at risk and having the way of prioritizing it also helps to know these are the applications that could be either very vulnerable, it could be, very important to an adversary. It's just having an overview map of things to take a look at is also very, very important.

Recommended talk: Live Hacking: Breaking into Your Web App • Brian Vermeer • GOTO 2022

How to start and learn Ethical Hacking 

Julian Wood: So if somebody is keen on getting into the ethical hacking business, I know you've got a workshop and you help people to do that, what are the sort of things they should start? Or should they just be opening the US Department of Defense's webpage and just, going straight in there and seeing how they can get in?

Ben Sadeghipour: I think that depends on the person's knowledge. It's where are you in your studies, for example, where are you in your career. I think it's easier to make that jump from a development perspective to ethical hacking, because you kind of know how things work, you know how to build these things. It's not, "How do I break them?" So if I throw terms at you, it's easier for you to understand because you understand as a developer, not as a hacker. So that's a big one. There are a ton of online resources nowadays. Some of my favorites are TryHackMe, Hack The Box, PentesterLab, CTF Challenge at code.uk is a really good one, bugbountyhunter.com. It's all these different resources. Depends on your style of learning. I would say, enroll in those, I think it's like 10, 12 bucks a month, in some cases are free.

Burp Suite, it's a tool everyone uses by PortSwigger, they have a free version, Website Academy. Go through those and learn the basics. But you're absolutely right, once you learn the basics, the best way to do these is just to get your hands on the keyboard and actually start to hack and learn. And, I think the best way to do it is, I personally recommend for new people to go look at vulnerability programs, the programs that don't pay you, but it gives you an idea of how things work. So you can build your methodology on how to hack. And there's a why I say that a lot of the top hackers are going after Bug Bounty programs that pay, and there is a lower chance for you to find things in your early days because you're still learning. So I'll always recommend starting with a disclosure program and then making your way up.

Julian Wood: And I suppose you were saying that there's gotta be an interest and a passion to find and discover things. People say that 80% of programming is putting bugs in and then the other 80% is taking bugs out. So, I mean, as people are developing and the IDEs or in the cloud or, JavaScript, Python, Node, whatever language they're using, the whole handling of bugs is part of the development life cycle. And I suppose this is just now taking it another step, instead of troubleshooting and, finding your own bugs, you're finding other people's bugs. But that takes time. I mean, programming is not just sitting in front of a keyboard and just learning how to type or something. There's a lot of skills required in programming. So what kind of skills should people be thinking of if hacking and finding bugs is of interest, how can people get better in their programming skills in the beginning?

Ben Sadeghipour: I think the big one is just...programming is a portion of it. I don't like code, but I understand 10% of most languages. I can kind of understand what's happening behind the scenes. The other one is, I think learning how to Google is a big one. I think 90% of my job is Googling things, even some various, basic things. I've learned that knowing everything by heart isn't gonna get me far, I just have to know how to Google for it. And knowing how to look things up efficiently to be able to find the answer within three or four Google queries, I think it's a very good skill, to be honest.

Julian Wood: Time saver too.

Ben Sadeghipour: And it saves you a lot of time, absolutely. And the biggest thing is understanding that no matter what you're, a developer, you're a hacker, whatever it is that you're doing, that it's a never-ending learning journey. You're never going to stop learning. It's not that, "Okay, today I know cross-site scripting, as a sort of IDOR. I'm done, I can go make money." No, those things become harder to find, new techniques come out, and you're everyday challenged and pushed to learn new things, and being open to that is a big game changer. It's the same thing with development. PH was a big one and still is, but you have all these new languages that came out recently that are more prominent that people use, that you have to learn and keep up with. It's the same thing, you have to make sure you're open to learning every day.

Recommended talk: Hacking the Internet of Things for Fun & Profit • Ruben van Vreeland • GOTO 2017

Hacking: Red vs Blue - Ethical Boundaries and Personal Security

Julian Wood: I suppose there are two sides we talk about, we've been talking about sort of red team kind of stuff where you are, finding the vulnerabilities, but there's a whole other sort of blue team kind of stuff where you're defending against the vulnerabilities. I mean, is that two sides of the same coin, just different kind of skills, or how do you think about that?

Ben Sadeghipour: I would say, blue teams are more...exact opposite of each other, blue team and red team. Red team, you are breaking in. Blue team's job is to catch you and mitigate things. It's pretty much, there are two different sides of it. I think as a blue teamer, you're more on the defensive side. How do I quickly catch these folks that are hacking in? How do I prevent it? And if you have a red team background, it helps you a lot more because you can think like an adversary. But red teaming with the stuff that I do, at least I'm not a red teamer, really. I wish I was a red teamer, I'm not there yet, at least. But with a lot of things that I do to break into a company, I'm not too worried about what the blue team is doing.

Ben Sadeghipour: I mean, especially with Bug Bounties, because I don't care if I get caught. With the red team, they don't want to get caught. They wanna stay and they want to like, elevate their access and go through the entire process. But for someone like me, I don't really have to worry about the defensive side, but it helps when I know how a developer thinks. Can I guess what the thought process was when they were writing this piece of code? So if they're writing an uploader for you can upload your images, what are some things they thought about to put in place or prevent it that I could break out of or exploit for my own good?

Julian Wood: How should people think about, if they are hacking something or connecting to something, there obviously are ethical concerns and moral concerns, and I'm not just talking about, a company losing money because you've managed to stop their payment gateway or whatever. But I mean, there's personal information out there, there's private information out there. There are hacks where power stations and power grids are being shut down. Is there a line that can be crossed or is it just people being inquisitive? We've got nation-states, pouring billions into hacking. I mean, this is big, big, big business, which as it gets more prevalent is just gonna get even bigger.

Ben Sadeghipour: I think there's always a line you should not cross. So the example with my case, I can't talk about stuff like SCADA power grids because that's a complete f-ing ball game. When you have access to like an electrical thing that could bring the whole grid down, you shouldn't cross that line. Like say, "Oh, can I flip this switch?" That's a completely different thing. But when it comes down to like, your PIs or information, there is a line. Proof of exportability. If I wanna prove that this is a vulnerability, do I query three or four users or do I query the entire database of users that this company has? That's the line you decide to cross. If I'm already in an internal server if I've already breached into the internal network, there is a line, do I go and dump the database or do I just prove that I can dump the database?

I don't have to actually do it, but I can say, "Hey, I have access to this thing that could potentially dump the database." I think ethically it's just knowing...I think at our core, we all know what is right or what is wrong, and it's just choosing to go with your gut-feeling of, if there is a question of should I be doing this, the answer is always no. If you're questioning it, you know the answer is no but it's just more of a, "How do I justify that I want to do this?"

Julian Wood: And it can be exciting, I'm sure. If you're getting further deeper into something, it can be exciting, you've got access to more data, you wanna keep going, but you sort of made your point and you sometimes take a break, have a coffee, and then think about what you're doing.

Ben Sadeghipour: There's been a few times when I've been in an internal network of a big retailer in the U.S., and almost anything that I wanted to access was unauthenticated. It was very tempting to go, "I wonder to know how much more damage I could do with this?" And there's been times that I've asked companies like, "Hey, I have this assumption that I could do X, Y, and Z. Could you let me try 'em?" And some companies are open to it. In a lot of cases they're not open to it. This company was like, "No, our sock team is already very unhappy about what you're doing, can you just drop it?" But I mean, there is always that, "I wonder what else I could have done." Or "I wonder how bad this breach could have been." Especially when it's like a big, big organization. When it's like a...I use Lyft as an example, it's a company I've publicly worked with. There's been a few times I'm like, "I wonder what else I could have done with this." But I will never know.

Julian Wood: Sort of flipping it around, what can people do to protect their private information and to... As more of our lives become online our addresses and children's information, and school things and everything, and work information and medical information are all out there. What can people do other than just battening down the hatches and not posting anything online, or is that what you should be doing?

Ben Sadeghipour: I mean, realistically that's probably the solution, but also not realistic because...

Julian Wood: You need to live online.

Recommended talk: A Practical Guide to Cyber Crime • Richard Clayton • GOTO 2017

Password Management: Tips for Creating Unique and Strong Passwords

Ben Sadeghipour: We all live online in today's age. I think it just comes down to, do you really need this website? Do you have to give them your information? If you're shopping online, obviously you have to give 'em your address because then how are they gonna deliver something to you. You don't have to always give them your real address. In a lot of cases, I just go, "123, Test Street." They don't need to have my address if they ask for it, you're not gonna send me anything. You're not sending me a mail. We don't need to talk. So you don't have to give 'em information. That's a big one. But also I think the majority of people, that's the biggest issue is just the security hygiene. For a lot of, especially the older generation the internet's new to them, they're still not familiar with how to do it.

It's just educating people, even at a young age when they get into computers, like how do we educate them so they protect themselves online? But also showing the older generation how to do these things as well. The biggest one is password management is a big one. I joke with my friends, and they're like, "Oh, don't look. I'm gonna type in my password." I'm like, "Let me guess. It's like your dog's name plus a number."

Julian Wood: "How did you know? How do you know?"

Ben Sadeghipour: And that's the reaction. It's like, "Oh my God, did you know my password?" And I'm like, "No, but thank you for that reaction because it shows me that you are just like everybody else, you're human. You're gonna put your wife's name and the year you guys met, that's the password for most people." Educating them, like, "Hey, make it something else. Make it a sentence. Instead of, 'I love my wife.' Make it, 'I love my wife because X, Y, and Z.'" So it's something a lot more random than just knowing their name and their, birth because that information is always online. And not using that data that could be scraped online about you in, security questions or passwords and that kind of thing.

Julian Wood: So how do people put enough variety in their passwords that ultimately want a unique password for every site? You know, I know, you know, plenty of people who would find that very difficult to do it. So is it a long password, using a sentence, how would you add some variety in to make it unique for sites? What sort of...

Ben Sadeghipour: I would choose a password manager. Password managers do that for you. All you have to do is remember one password. There's a company called 1Password. You sign up for them, they manage your passwords. People are like, "What if they get hacked?" It's a lot harder to hack it. It's a company that's invested in protecting your data than a lot of corporations use then, so hacking you is a lot easier. So use something like that. And then you have to remember that one password, you just have to remember. It's gotta be hard, it's something that you are always gonna remember. And they create passwords for you based on every site. And it's very easy to use on your laptop, on your computer. It's very easy to use on your phone.

It's like your regular phone. It has a Face ID for an iPhone. It asks you what app you want to use. You click on your password management and it logs you in automatically. There's two steps you have to take. But those two clicks protect you from getting your account hacked. So if the next big breach happens and your password was in that breach, and you use that password for your bank, for your social media, for your email, I have access to everything. All I have to know is what is your email address and what banks you bank with. And it's not hard to guess those banks, because let's be real, in every country there are five or six banks that are major. And it becomes easier. Two-factor authentication is a big one. People tell me like, "Don't say two-factor you should do multifactor." You know, like, "Don't do the SMS one, do apps."

Ben Sadeghipour: I'm like, someone that's like, my mom's age or my dad's age, their threat model is different than you and I. No one's gonna go and SIM swap my mom to get to their bank account like, they're gonna give up. But for me, it's a different profile, but having that, I'd rather have someone like, my parents or my elders, I would rather have them use a text message two-factor authentication than not use one at all. I get the argument on why you should do one or the other, but it's just more of having that in place that they could place because it protects them like an extra layer of protection. You shouldn't be using the same password, but if you're using the same password over and over, at least you have that layer of protection when they text you your two-factor authentication to log into your account.

Julian Wood: As you know, people that go to are, developers and IT professionals, are there better things that they should be doing? Because a lot of IT people have full admin access to a lot of systems when they're developing code. Maybe they've got protections in CI/CD pipelines that have separate accounts, or separate usernames and passwords, or access keys. But a tip or two for IT professionals to improve the security posture of their companies.

Ben Sadeghipour: I mean, one is an obvious one, personal passwords and work passwords should be different. I think that training is a big one. Training people not to click on links. It always starts with the more entry-level positions at the company and they can always elevate up. It's just the security hygiene of the things you do personally, but also doing at a bigger scale with the company. I think education is a big part. I don't think we spend enough time educating people on why security is important. Always the question is, "Who's gonna hack me?" You would be surprised. You're not the primary, you are a part of a bigger grand scheme of like plans. Those are probably the biggest ones.

Phishing and whatever 'ishing you wanna say, vishing, phishing, there's a bunch of different variations of it. Training for those, it's a big one. You get a phone call, and I've gone as far as like when my bank calls, I ask them, "Confirm you're my bank. How do I know that you just call me from a number? It's a 1-800 number. How do I know that's a real number?" Training for those things is a big one. Someone calls you and says, "Hey, I'm calling from your IT department," how do you verify? Hang up and call them back or have some sort of two-layer protection where they can confirm that this is in fact who they say they are.

Julian Wood: I suppose also taking control of yourself. I mean, I know you get scam calls and it's from the tax office saying, "Oh, you owe us lots of money and it's a heavily accented English recorded message, and that's just obvious that it's somebody else. But I know other people who have been called and that they have got the right bank and they do assume it is the right bank, and to never be rushed into making a decision, or transferring money, or doing anything like that.

Ben Sadeghipour: And they're getting better and better, they're getting very much but more accurate. The background noise sounds so real when it's like a YouTube video in the background playing. But, it's the biggest one is just not assuming...the zero trust. It's just having zero trust that whoever's on the other side isn't telling you the truth. I'll give you an example. A hotel called me recently, and like, "Hey, we wanna give you this deal. It's a very good deal for like a six-day vacation for very cheap." And I go, "Okay, this is a scam." And they're like, "No, it's not." Like, "I don't believe you. Can you confirm?" I made this lady go out, and gimme her phone number to call. And I was like, "Hey, I need you to tell me to go on this website. What is your website, so I can go on it?" It was like a big hotel brand.

And she's like, "Go to our website, click on the link down below, go to this number that's on the screen in the website, I need you to call them and confirm that my name so-and-so works at this company. Here's my extension number." Put her on pause, call on the other side. I was like, "Hey, I'm looking for so-and-so, can you confirm?" The lady was like, "Yep, I'm the manager. I confirm that this person works for us." I went back I was like, "I apologize, but I'm just getting on too many scam calls and you're asking me to not only give you x amount of dollars, but you want my credit card number and you have my phone number and like, I have to confirm you are who you say you are." I wouldn't shy away from it. If you're spending money, you're spending a thousand dollars to go to this vacation, the least you can do is put 'em through that process of proving they are who they say they are for your own protection.

Julian Wood: And I suppose turning that around, companies must set themselves up that they can be contacted and without giving private information about all the employees, there must be a way in that somebody can verify who works there and what's legitimate.

Ben Sadeghipour: Even you can't even trust the fact that says like, you know, you work for the company because how you gonna confirm that? Like, can you give my address...

Ben Sadeghipour: The thing is like, can you tell me my address? They can find that information on you in some cases. So just verifying the data on your own is always the best bet.

Exploring Ethical Hacking: Insights & Bug Bounty Tips

Julian Wood: So just coming back around to what we started about sort of career and hacking. I know you run a course. I mean, I'm sure that's a really great way that people can at least get interested in ethical hacking. What are the details of that? How do people find it online?

Ben Sadeghipour: First of all, like if you want to learn things, the course isn't always the way. The reason why I say that is, I think today's age, almost everything you want to learn is found online. The reason why I've created courses is more of a people ask, like, "We wanna learn from you, how do you approach this thing?" So if you want to learn my approach to hacking and Bug Bounties, their course is very valuable. But I highly recommend doing some research, at first before you purchase the course. Their course is called, Intro to Bug Bounty and Web Hacking. Right now it's hosted on Udemy. It's just easier to host than anywhere else, then I go to conferences and present it. And we could always look for it. It's online, it's not that expensive. You can look for on Udemy, it will pop up. And there's also, if people wanna look for Bug Bounty resources, if we're typing Bug Bounty resources, literally the three words, the first thing should be a get hot report that belongs to me to have all these different resources, including my course, some other free applications, website, books, all those things that they can use as well.

Julian Wood: Excellent. How else could people contact you? Are you on social media or how would people get in touch if they have any questions?

Ben Sadeghipour: I am on all social media except Snapchat. I make it a point to say this.

Julian Wood: Is there a reason for that?

Ben Sadeghipour: Not really. It's just funny to say it because a lot of of kids use it. So I just go, "I'm on every platform except Snapchat." It's always the same thing. I go by Nahamsec, N-A-H-A-M-S-E-C. So I'm NahamSec, I'm on Instagram, Twitter, I'm very active on Twitter. I have a YouTube channel, Twitch Channel, people can, tune into and hear from me.

Julian Wood: Excellent. Well, Ben, thanks so much for joining us. Thanks for joining us on GOTO Unscripted here in Copenhagen. It's amazing to be able to talk to some of these amazing speakers who've got such super interesting information in beautiful Copenhagen. So until next time, thank you very much.