Jump to content
  • Create New...

Search the Community

Showing results for tags 'pentest'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • HOME
    • Shell_Meet
    • Shell_Talk
    • Board Meet
    • Announcements and Updates
    • Shell_Update
    • Pending Approvals
    • Member Introductions
    • Shell_Crew Support
    • Ctf Updates & Walkthroughs
    • Latest CVE-Info
    • Android/IOS Pentesting
    • Reverse Engineering
    • IoT Exploitation
    • Malware Analysis
    • API Pentesting
    • Cloud Security
    • Off-topic Lounge
    • Internships
    • Career Discussion
    • Mentorship
    • Career Guidance
    • P5 (Informational Bugs)
    • P4 (Low-Level Bugs)
    • P3-P2 (High-Level Bugs)
    • P2-P1 (Critical Bugs)
    • Vulnerability Chaining
    • Report Writing
    • Personal Hunting Methodology
    • Front-End Development
    • Scripting
    • Backend-Development
    • Application Development
    • Linux Kernel and OS Developers
    • Hardware Programming
    • DevOps
    • Queries Assessment
    • Penetration Testing (Risk Assessment)
    • Red Teaming (Risk Assessment)
    • Blue Teaming (Risk Assessment)
    • Exploit Development (Risk Assessment)
    • OSINT-External and Internal (Threat Intelligence)
    • IOC (Threat Intelligence)
    • Awareness (Reinforcement)
    • Digital Forensics (Security Operations)
    • SOC & SIEM
  • Bug-Hunters's Resources
  • Open Source Contribution's Topics
  • Pentesting's Resources
  • SDR & AutoMobile Pentesting's Topics
  • Networking's Topics
  • Networking's Network Resources


  • Open Source Contribution's Blogs


  • Bug-Hunt
  • Penetration Testing
  • Blue-Teaming

Product Groups

There are no results to display.


  • Pentesting
  • Bug-POC Videos
  • CTF-Walkthrough
  • Scripting
  • Bug-Hunters's Videos
  • SDR & AutoMobile Pentesting's Videos
  • Networking's Videos


  • Pentesting
  • Bug-Hunting
  • SDR & AutoMobile Pentesting's Tutorials

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start



About Me

Found 10 results

  1. Hello Researchers, Let's Just Quickly Talk About our Topic What is Recon ? Recon or Reconnaissance is the technique or a procedure used in information security to determine about our target, Generally during a pen test or during any boot-to-root style capture the flag, reconnaissance is the basic thing to do. Now in this post I'll be sharing some of my own techniques I use during a recon. PORT SCANNING Port scanning is the basic thing to do during reconnaissance but we are not going to talk about some basic tools and techniques for scanning ports, if you want really quick results and you don't have to waste time on your initial step even with very low specs do this (by the way I'm nmap user) cool kids using rust and mass these days but yeah NMAP is better overall according to me. Now, what I generally do, I just do a basic scan with simple argument [email protected]:~ nmap 192.168.xx.xx now it'll result us back basic result of open ports but here to work on, but here's a catch that nmap only look for initial 10,000 ports by default, after getting few ports to look back we can do one more step to get things done quickly [email protected]:~ nmap -p- -v 192.168.xx.xx "-p-" argument let us have full port scan over 65,535 ports and "-v" argument stands for verbose so it will display ports as it finds them. Most of people do a mistake that they use "min-rate" argument to get results fast but sometimes it could skip some ports and that leads to a massive lost as a pen tester. Now after you've this result displayed on your screen and if you need proper scan for your report or for your notes you can do one thing [email protected]:~ nmap -sC -sV -pxx,xx,xxxx,xxx, 192.168.xx.xx by using "-p" argument it will only scan for given ports. Directory Enumeration and Fuzzing Let's Suppose we've a http server running on our target machine or server and we've a website to test on, For Directory Busting I use Gobuster and with SecLists it become very dangerous because SecLists is the thing which have collection of massive wordlists specific for directory enumeration, I use my some common sense and webapplizer to expose technology used for the website like php, So let's have a example [email protected]:~ gobuster dir -w /opt/SecLists/Discovery/Web-Content/raft-small-words-lowercase.txt -u http://normalweb.net -x php Now why do i use "raft-small-words" is just because it contain .git and big.txt doesn't have that, now if i found .git I could use Git Dumper and so much interesting depends on how you use your approach to test your target. this was just a basic approach but mostly people skip a really important step they enumerate that parent directory they working on for example if you got something like "sources" they'll just left it behind and I really did this mistake million times and I regret most of the time so in my opinion don't skip anything [email protected]:~ gobuster dir -w /opt/SecLists/Discovery/Web-Content/raft-small-words.txt -u http://normalweb.net/sources Now's let's talk about fuzzing little bit, Fuzzing is the really important step that most of people skip but whenever if you lands on some kind of dead end like 404 not found and 301 forbidden make sure to fuzz the path once before making a regret because it happened to me mostly during ctfs, when I skip fuzzing. I really like wfuzz for the fuzzing also I'll advice to use wfuzz it is really easy to use. [email protected]:~ wfuzz -c -z file,/usr/share/wfuzz/wordlist/general/common.txt --hc 404 http://192.168.x.xx/FUZZ So don't do these mistake or bang your head on the wall. Looking For Basic Vulnerabilities Now this is very common mistake and this mistake can make us distracted, whenever you find a website always to try to connect things like check the web socket requests that used for chat (they mostly vulnerable to blind sql injection) and also look for some kind of input field to do some kind cross site scripting and try all kind of Injection like ssti and xxe. If i look for web i mostly check all the owasp top 10 and also sans top 25, also don't forget to check the url because we can have some type lfi or IDOR. Heyy this is not the end just enough for part 1, we'll be back and start our topic from where we've left today. Catch me on my socials :- YouTube , Instagram
  2. 🔰Penetration Testing🔰 Penetration Testing is a method that many companies follow in order to minimize their security breaches. This is a controlled way of hiring a professional who will try to hack your system and show you the loopholes that you should fix. Before doing a penetration test, it is mandatory to have an agreement that will explicitly mention the following parameters − >what will be the time of penetration test, >where will be the IP source of the attack, and >what will be the penetration fields of the system. Penetration testing is conducted by professional ethical hackers who mainly use commercial, open-source tools, automate tools and manual checks. There are no restrictions; the most important objective here is to uncover as many security flaws as possible. ⭕️Types of Penetration Testing 1️⃣Black Box − Here, the ethical hacker doesn’t have any information regarding the infrastructure or the network of the organization that he is trying to penetrate. In black-box penetration testing, the hacker tries to find the information by his own means. 2️⃣Grey Box − It is a type of penetration testing where the ethical hacker has a partial knowledge of the infrastructure, like its domain name server. 3️⃣White Box − In white-box penetration testing, the ethical hacker is provided with all the necessary information about the infrastructure and the network of the organization that he needs to penetrate. 4️⃣External Penetration Testing − This type of penetration testing mainly focuses on network infrastructure or servers and their software operating under the infrastructure. In this case, the ethical hacker tries the attack using public networks through the Internet. The hacker attempts to hack the company infrastructure by attacking their webpages, webservers, public DNS servers, etc. 5️⃣Internal Penetration Testing − In this type of penetration testing, the ethical hacker is inside the network of the company and conducts his tests from there. Penetration testing can also cause problems such as system malfunctioning, system crashing, or data loss. Therefore, a company should take calculated risks before going ahead with penetration testing. The risk is calculated as follows and it is a management risk. ‼️ Share and support us ‼️
  3. CTF(Capture The Flag) - Hack the Box 👩‍💻♥️💫✨ If you are looking for opportunities to expand your horizons and learn more about digital security. Then CTF is probably the Stuff you should give it a Try & HTB(Hack the Box) is one such example. Here I'm going to Share the Top Pentesting Labs you should Venture and Aim for if You are having an higher level of Appetite. ~ With Best Regards MR.MIME ✌️💫 Happy Learning
  4. I Rohit aka Pentest With Rohit is currently working as a Accountant and Manager in a Private Firm Goyal Impex, I have nearly 4+ years experience in Information security field. I Am CyberSecurity Consultant,Programmer,Automation Lover,Ncc Cadet,Accountant and also Manager.I started my career as a CyberSec Teacher and moved to the Cyber Security field after a year and also contributing to the open source community as a developer. Literally To Nobody:-Girls after seeing my Intro(Reaction)
  5. Hii guys I m Venom!. So today we will see a short python3 script for a web-fuzzer. I hope u will learn something new out of it. So let's roll. # importing libraries import requests # for making request to website import os # for checking wordlist path url = input('Enter the url: ') # taking url as user input wordlist = input('Enter the wordlist path: ') # taking wordlist as user input # checking if wordlist exists or not if os.path.exists(wordlist) is False: # if wordlist does not exists then print that wordlist not found print("Wordlist not found! Please try again!") else: # if wordlist do exists then run this thing print("Wordlist Found: True!") op = open(wordlist, 'r') # opening the wordlist file read = op.readlines() # reading the content inside the file for path in read: # we are using a for loop to grab each and everyline finalurl = url + "/" + path # apending the which is targeturl + path response = requests.get(finalurl) # making a get request to get the status code of the website if response.status_code == 200 or response.status_code == 403: # checking if status is 200 or 403 print(finalurl + " [" + str(response.status_code) + "]") # if status code is 200 or 403 print the finalurl else: # else pass the response pass fuzzer_2-Veed.mp4
  6. Android Penetration Testing is a process of testing and finding security issues in an android application. ... This training covers real-time testing of android applications and some security issues like insecure logging, leaking content providers, insecure data storage and access control issues. Learning about the basics of android pentesting. Throughout the lectures you will be covering how to start analysing android application and cover different vulnerabilities in the vulnerable application DIVA : Damn Insecure and Vulnerable Application. Lets take a look at some important areas we are going to cover in our series - 1. We will reverse the application to get the source code. 2. We will be analysing the application code and finding the vulnerability. 3. We will understand the difference between unzipping and decompiling an apk. 4. We will capture the browser requests of our mobile on the kali vm and analyse the traffic. 5. The vulnerabilities we are going to cover are : Insecure Logging Hardcoding Issues Insecure Data Storage Input Validation Issue Access Control Issue In the end of of the series we will complete all the 13 exercises of DIVA application and learn the basics of android penetration testing. Who should go through this series those who are: Beginner in Ethical Hacking Beginner in Android Pentesting Android Hacking Beginners Beginner in Mobile Security
  7. Mobile applications often process sensitive data, which is the key target of many cybercriminals. When working with such data, developers must do their best to ensure its protection. One way to improve the security of a mobile app is to perform mobile application penetration testing. To find flaws in their application code, developers need at least basic skills in reverse engineering and pentesting Android applications. In this article, we discuss different methods an attacker might use to hack your apps. We also explain how challenges from the Open Web Application Security Project (OWASP) Mobile Security Testing Guide (MSTG) can help you in Android application security testing and what tools you can use to solve them. Strengthen your app’s security with reverse engineering Android is quite a developer-friendly operating system (OS). Unlike other mobile OSs, Android is an open-source platform on which you can activate Developer Options and sideload applications without jumping through too many hoops. Furthermore, Android allows developers to explore its source code at the Android Open Source Project and to modify operating system functionality however they like. However, working with Android applications also means you’ll need to deal with Java bytecode and Java native code. Some developers may see this as a disadvantage. Android developers use the Java Native Interface to improve application performance, support legacy code, and, of course, confuse those who try to look inside their apps. When building mobile applications, one of the top priorities for a development team is to ensure a high level of data security. Developers should do their best to prevent cybercriminals from getting access to a user’s sensitive information. Some try improving the security of their mobile apps with the help of third-party solutions. However, when working with third-party products, it’s critical to configure them properly. A misconfigured or improperly used solution will be of no help, no matter how expensive it is. Others try to hide the application’s functionality and data in the native layer. In some cases, they build Android applications in such a way that execution jumps between the native layer and the runtime layer. There are also developers who use more sophisticated methods, such as reverse engineering. This technique is quite helpful when it comes to ensuring proper protection of an application’s sensitive data. That’s why it’s best for a developer to have at least some basic skills in reverse engineering: Unpacking APK files Patching .smali files Patching .so libraries Using debugging tools Working with frameworks for dynamic code analysis With these skills and expertise, mobile app developers will have a better chance of detecting code flaws that might be used by attackers. For instance, in order to break into your application, hackers may use the same techniques that quality assurance (QA) specialists use when they test an application’s security and performance: Dynamic analysis is used to find possible ways to manipulate application data when the application is running. For example, hackers may try to crack your app by skipping the multi-factor code check during login. Static analysis is used for studying an already packaged application and detecting code weaknesses without having direct access to the source code. With static analysis, we don’t look at the application’s behavior at runtime, as we do during dynamic analysis. Hackers may use static analysis to detect the use of a weak encryption algorithm, for instance. A basic toolset for Android reverse engineering Before you start solving the OWASP CrackMe challenges for Android developers, you need to make sure you have two things: Knowledge of Android environments. You need to have some experience working with Java and Linux environments as well as with Android kernels. The right set of tools. Working with bytecode and native code running on a Java virtual machine (JVM) requires specific tools. In this section, we list and briefly describe tools that you can use to solve the OWASP CrackMe challenges and upgrade your reverse engineering skills. Note: For the purposes of this article, we’ve chosen only tools and frameworks that are either free or have free trial versions. Android Studio — The official integrated development environment (IDE) for Android. This is the primary IDE for building native Android apps; it includes an APK analyzer, code editor, visual layout editor, and more. In particular, we’ll use the command-line Android Debug Bridge (adb) tool. Apktool — This is a popular free tool for reverse engineering closed, third-party, and binary Android applications. It can disassemble Java bytecode to the .smali format as well as extract and disassemble resources from APK archives. Also, you can use Apktool for patching and changing the manifest file. Note: Application code is stored in the APK file, which contains the .dex file with Dalvik binary bytecode. Dalvik is a data format understandable by the Android platform but completely unreadable for humans. So for a developer to be able to work with .dex files, they need to be converted to (and from) a readable format, such as .smali. Cutter — An open-source cross-platform framework that provides a customizable, easy-to-use reverse engineering platform. This framework is powered by radare2 and is supported by a large community of professional reverse engineers. Hex Workshop Editor — A popular set of Windows hexadecimal development tools. This toolset makes editing binary data nearly as simple as working with regular text documents. Hex Workshop Editor is commercial but has a free trial version. Note: Hex Workshop Editor can only be used on Windows. If you’re working with a Linux-based virtual machine, you can choose any Linux hex editor. dex2jar — A free tool for converting bytecode from the .dex format into Java class files. JD-GUI — One of the tools created by the Java Decompiler project. This graphical utility makes Java source code readable, displaying it as Java class files. Mobexler — An Elementary-based virtual machine for iOS and Android pentesting. Mobexler comes with a set of preinstalled tools and scripts for testing the security of a mobile app, including some of the tools from this list. Java Debugger (jdb) — A free command-line tool for debugging Java classes. Note: In Android applications, debugging can be performed on two layers: Runtime layer — Java runtime debugging can be performed with the help of the Java Debug Wire Protocol (JDWP). Native layer — Linux/Unix-style debugging can be performed based on ptrace. JDWP is a standard debugging protocol that helps the debugger communicate with the target JVM. This protocol is supported by all popular command-line tools and Java IDEs, including Eclipse, JEB, IntelliJ, and, of course, jbd. The JDWP debugger allows you to explore Java code, set breakpoints in Java methods, and check and modify both local and instance variables. It’s often used for debugging regular Android apps that doesn’t make many calls to native libraries. GNU Debugger (gdb) — A useful tool for analyzing an application’s code. We used these tools to solve two reverse engineering challenges for Android apps. In the next section, we’ll give you a basic Android pentesting tutorial based on the standard OWASP challenges. Solving UnCrackable Apps challenges We'll show you how to solve two OWASP MSTG CrackMe challenges: UnCrackable App for Android Level 1 and UnCrackable App for Android Level 2. These apps were specifically designed as reverse engineering challenges with secrets hidden in the code. Our task is to find these secrets. While solving these challenges, we’ll use static analysis for analyzing the decompiled code and dynamic analysis for modifying some of the application parameters. Solving UnCrackable App for Android Level 1 First, we need to look inside our training application. A regular Android application is, in fact, a properly packaged APK file containing all the data the application needs to operate normally. To look at the application from the inside and solve this challenge, we’ll need: adb for communicating with our mobile device and the training application Apktool for disassembling the APK files of our training app into separate .smali classes jdb for debugging our training app dex2jar for converting APK files to the JAR format JD-GUI for working with the JAR files Now let’s move on to solving the first challenge. We’ll begin by installing UnCrackable-Level1.apk on our device or emulator with the following command: $ adb install UnCrackable-Level1.apk We’ll solve this challenge and debug the Release Android app with the help of the jdb tool. Follow along to find the hidden secret. 1. Unpack the application and decode the manifest file using Apktool: $ apktool d -s UnCrackable-Level1.apk -o temp 2. Using a text editor, put the app into debugging mode by changing the manifest file and setting android:debuggable to "true": <application android:allowBackup="true" android:debuggable="true" android:icon="@mipmap/ic_launcher" android:label="@string/app_name" android:theme="@style/AppTheme"> 3. Use Apktool to repack the APK file: $ apktool b temp -o UnCrackable-Level1-Repackage.apk 4. Resign the newly created APK file. You can do this using a bash script for resigning Android apps. 5. Install the new APK file on your device or emulator with the following command: $ adb install UnCrackable-Level1-Repackage-Resigned.apk At this point, we face the first big challenge. The UnCrackable App is designed to resist debugging mode. So when we enable it, the app simply shuts down. You’ll see a modal dialog with a warning. The dialog can be closed by tapping OK, but this will be your last action before the app is terminated. Fortunately enough, there’s a way to fix this. 6. Launch the application on your device or emulator in Wait For Debugger mode. This mode allows you to connect the debugger to the target application before the application runs its detection mechanism. As a result, the app won’t deactivate the debugging mode. Run the application in Wait For Debugger mode with this command: $ adb shell am start -D -n "owasp.mstg.uncrackable1/sg.vantagepoint.uncrackable1.MainActivity" 7. Now display the process IDs (PIDs) of all processes that run on the connected device: $ adb shell ps 8. And list only debuggable processes: $ adb jdwp 9. Open a listening socket on your host machine and forward its incoming TCP connections to the JDWP transport of a chosen debuggable process: $ adb forward tcp:4321 jdwp:PID 10. Note that attaching the debugger (in our case, jdb) will cause the application to resume from the suspended state, and we don’t want that. We need to keep the app suspended for a while to explore it in detail. To prevent the process from resuming, pipe the suspend command into jdb: < "%JAVA_HOME%\bin\jdb" -connect com.sun.jdi.SocketAttach:hostname=localhost,port=4321 Set uncaught java.lang.Throwable Set deferred uncaught java.lang.Throwable Initializing jdb ... < suspend All threads suspended. < 11. Now we need to bypass that moment when the application crashes in the runtime after you tap OK. Decompile the APK file to review the application code using dex2jar and JD-GUI: 1) Use the dex2jar tool to convert the original APK file to a JAR file: $ d2j-dex2jar.bat -f UnCrackable-Level1.apk 2) Using the JD-GUI tool, open the newly created JAR file: public class MainActivity extends Activity { private void a(String str) { AlertDialog create = new Builder(this).create(); create.setTitle(str); create.setMessage(“This is unacceptable. The app is now going to exit.”); create.setButton(-3, “OK”, new OnClickListener() { public void onClick(DialogInterface dialogInterface, int i) { System.exit(0); } }}; create,setCancelable(false); create.show(); } After reviewing the code, you’ll see that the MainActivity.a method displays the message: "This is unacceptable..." The MainActivity.a method creates an alert dialog and sets a listener class for the onClick event. The listener class has a callback method that shuts down the application when the user taps the OK button. To prevent a user from canceling the dialog, the system calls the setCancelable method. At this point, our best-case scenario is to suspend the application in a state where the secret string we’re looking for is stored in a plaintext variable. Unfortunately, that’s impossible unless you can figure out how the application detects root and tampering. 12. Try tampering with the runtime a little bit to bypass application termination. Set a method breakpoint on android.app.Dialog.setCancelable when the application is still suspended, then resume the app: All threads suspended. < stop in android.app.Dialog.setCancelable Set breakpoint android.app.Dialog.setCancelable < resume All threads resumed. < Breakpoint hit: “thread-main”, android.app.Dialog.setCancelable(), line-1, 205 bci-0 main[1] _ 13. The application is suspended at the first setCancelable method instruction. You can use the locals command to print the arguments passed to the setCancelable method: main[1] locals Method arguments: flag = true Local variables: main[1] _ As you can see in the code above, the system called the setCancelable(true) method, so that’s not the call we need. Let’s resume the process with the resume command: main[1] resume All threads resumed. < Breakpoint hit: “thread-main”, android.app.Dialog.setCancelable(), line-1, 205 bci-0 main[1] locals Method arguments: flag = false Local variables: main[1] _ We’ve reached a call to the setCancelable method with the false argument. At this point, we need to use the set command to change the variable to true and resume the app: main[1] set flag = true flag = true = true main[1] resume All threads resumed. < Breakpoint hit: “thread-main”, android.app.Dialog.setCancelable(), line-1, 205 bci-0 main[1] _ Continue setting flag to true each time you reach a breakpoint until the alert window is finally displayed. It may take about five or six attempts before you see this window. At this point, you should be able to cancel the app without causing the application to terminate — just tap the screen next to the dialog window and it will close. 14. Finally, it’s time to extract the secret string. Look at the application code once more. You’ll notice that the string we’re looking for is decrypted with the Advanced Encryption Standard and is compared with the string the user enters into the message box. The application uses the equals method of the java.lang.String class to determine if the string input matches the secret string. Now set a method breakpoint on java.lang.String.equals, enter random text in the edit field, and tap VERIFY. You can read the method argument with the locals command once you reach the breakpoint: <> stop in java.lang.String.equals Set breakpoint java.lang.String.equals < Breakpoint hit: “thread-main”, java.lang.String.equals(), line=944 bc1=2 main[1] locals Method arguments: anObject = “b” Local variables: main[1] cont < Breakpoint hit: “thread-main”, java.lang.String.equals(), line=944 bci=2 main[1] locals Method arguments: anObject = “i” Local variables: main[1] _ ……… main[1] locals Method arguments: anObject = “I want to believe” Local variables: main[1] _ Bingo! Our secret string is “I want to believe.” You can easily check if that’s right by entering this phrase into the message box and clicking the VERIFY button. Ok Next Part Soon Uploading Thanks U My Friends
  8. Here is a list for free Penetration Testing & Red Teaming Labs you can build locally and use it to practice & upgrade your skills. https://lnkd.in/dyTx2GCZ https://lnkd.in/dZPRibiM https://lnkd.in/du8d2wJ7 https://lnkd.in/dhTtxMgp https://lnkd.in/dS9wDk9G https://lnkd.in/dXdBuVWX https://lnkd.in/d3zQGkvu https://lnkd.in/d2hWRUex https://lnkd.in/dY6TewhF https://lnkd.in/d448tvkn https://lnkd.in/dux7FfiC https://lnkd.in/d-fWN6uf https://lnkd.in/dy7AqdJw Have a funny Offensive Time. 🤑😁🆒
  9. First what is SSL Unpinning? If you need to intercept the traffic from an app which uses certificate pinning, with a tool like Burp Proxy, the SSLUnpinning will help you with this hard work! The SSLUnpinning through Xposed Framework, makes several hooks in SSL classes to bypass the certificate verifications for one specific app, then you can intercept all your traffic. STEPS TO DO IT- Setup any android/ios emulator of your choice with respect of the os you are using. Start Your Emulator and install a famework known as Xposed Framework can be downloaded its apk according to your android version from here https://repo.xposed.info/module/de.robv.android.xposed.installer , https://magiskroot.net/install-systemless-xposed-framework-nougat/ &nbsp; Once your Xposed Framework apk gets installed in your emulator open it initially you will find under Xposed Status Xposed Framework version not active. Then below you will see INSTALL/UPDATE do that according to your emulator build. Then click on right hand top three dots and perform a cold reboot. Your status will change to active. Then in left hand top go to download section and serach for SSLUNPINNING 2.0 , TrustMeAlready Frameworks and install them As you install them go to Modules and you will find both the installed frameworks check the boxes and make them active. Navigate out to the main screen of your emulator you will find SSLUNPINNING 2.0 application ready open it and you will find all the apps listed there select your desired app that you wanna pentest click on it a message will popup "BYPASS APPLIED". This mechanism is for applying ssl bypass in Android Enviroment because I am an Android user sed lyfe. 😅😅 For performing SSL Bypass in IOS most prominent application that does is called KillSwitch2. Now as the bypass have been applied on the desired application that you wanna pentest now you can easily add/configure yoour proxy with your emulator and now this time each time you intercept a traffic from your application it will be a clean and unencrypted traffic just as you do while performing web pentesting. Hope you guys understood the things explained here. So follow these steps and try out without trying you will not gonna learn. So try try but don't cry 😉😉 . If you don't undertsand something feel free to ping me up in personal.
  10. Covered:- 1.From Where to Learn OWASP TOP 10 Fastly _ Unknown Components with Known Vulnerabilities 2.SQL injection Theory and Practical Both_ Owasp Top 10 3.XML External Entity XXE Processing Vulnerability With Theory and Practical Both _ Owasp Top 10 4.HTTP Host header attacks With Theory and Practical Both _ Owasp Top 10 5.Session Token in URL _ Owasp Top 10 6.Session Fixation Vulnerability Theory and Practical Both _ Owasp Top 10 7.Left Over Debug Code Vulnerability Theory and Practical Both _ Owasp Top 10 8.Cross site scripting XSS Reflected_Stored and Dom With Theory and Practical Both _ Owasp Top 10 9.Privilege Escalation Theory and Practical Both _ Owasp Top 10 10.SSRF Vulnerability With Theory and Practical Both _ Owasp Top 10 Do not Forget To Follow.So That you can get pop msg for updates in future Post. I hope you like and love the same this course as you liked the previous one.I have given hint of upcoming course in one video watch that too.