DEV Community: MRxO1

Getting Started with Bug Bounties: Core Vulnerabilities and Basic Testing

MRxO1 — Wed, 18 Feb 2026 15:26:39 +0000

If you are starting in bug bounties, the most important thing is recon.

Also, one more tip is to master one vulnerability first. Do not try to master every vulnerability at once.

Recon is the Main Skill

Reconnaissance is the foundation of bug bounty hunting. There are many ways to do recon, and it is a very broad topic. Good recon helps you expand your scope and discover more assets, endpoints, and hidden functionality.

Recon is what makes your scope bigger. If your recon is strong, you will find more attack surfaces. If your recon is weak, you will miss most of the bugs.

When you start bug bounties, you must focus on recon first. It is the main skill that separates beginners from experienced hunters. A full article can be written only on recon techniques.

Open Redirect

Open redirect happens when a web application takes untrusted input and redirects the user to another site without proper validation.

This usually occurs when:

A parameter controls the redirect destination
The application does not verify the destination domain

Example:
https://example.com/?page=evil.com

Try combining domains:
https://example.com/?page=evil.com/?google.com

Using the @ trick:
www.google.com@evil.com

Testing with curl:
curl -I "https://example.com/?page=https://evil.com"

Look for:
HTTP/1.1 302 Found

Location: https://evil.com

Impact:

Phishing attacks
Token leakage
Bypass of security checks

Cross Site Scripting (XSS)

Cross Site Scripting allows attackers to execute arbitrary client side code inside the victim’s browser. This happens when a web application takes user input and sends it back to the browser without proper sanitization or encoding.

With XSS, an attacker can:

Read or modify page content
Steal session cookies
Perform actions as the victim
Redirect users to phishing pages
Capture keystrokes
Inject malicious scripts into trusted sites

XSS is one of the most common vulnerabilities in bug bounty programs.

Types of XSS

Reflected XSS
Stored XSS
DOM based XSS

Reflected XSS

Reflected XSS occurs when the payload is sent in the request and immediately reflected in the server response.

This usually happens in:

Search fields
Error messages
URL parameters
Headers

Example:
site.com/page?name=John

If the site returns:
Hello John

It means HTML is being rendered.

Test:
site.com/page?name=alert(1)

If the script executes, the site is vulnerable.

Basic payloads:

alert(1)

">alert(1)
'>alert(1)

Stored XSS

Stored XSS occurs when the payload is saved in the database and executed whenever the page is viewed.

Common locations:

Comment sections
Profile fields
Messages
Review forms
File upload names

Example payload:

alert(1)

DOM Based XSS

DOM XSS occurs entirely on the client side when JavaScript reads attacker-controlled data and passes it to dangerous functions.

Common sources:
document.URL

document.referrer

location

location.href

location.search

Dangerous sinks:
eval

setTimeout

setInterval

document.write

innerHTML

outerHTML

Impact:

Session hijacking
Account takeover
Phishing attacks
Keylogging
Admin account compromise

CSRF (Cross-Site Request Forgery)

CSRF allows attackers to perform actions on behalf of an authenticated user without their knowledge.

Conditions:

Victim must be logged in
Victim must interact with attacker content
Application must lack CSRF protection

Possible impacts:

Email change
Password reset
Account takeover
Financial transactions

Example:
POST /change-email

email=attacker@mail.com

Try:
GET /change-email?email=attacker@mail.com

IDOR (Insecure Direct Object Reference)

IDOR occurs when applications expose direct references to objects without proper authorization checks.

Example:
/api/user?id=1001

Test:
/api/user?id=1002

/api/user?id=1003

Look for:

Numeric IDs
Sequential values
Base64-encoded identifiers

Example:
echo "1001" | base64

IDOR is often one of the easiest bugs for beginners.

Local File Disclosure and Path Traversal

This vulnerability allows attackers to read files from the server by manipulating file paths.

Basic payload:
../../../etc/passwd

Bypass techniques:
..//..//..//

%00

%2e%2e%2f

Look for parameters:
file=

path=

page=

include=

Impact:

Reading configuration files
Accessing credentials
Sensitive data exposure
Possible path to remote code execution

SQL Injection (SQLi)

SQL injection allows attackers to interact directly with the database.

Possible actions:

Read data
Modify data
Delete data
Create new records

Types:

Error-based SQLi
Blind SQLi

Basic tests:
?id=1' AND 1=1--

?id=1' AND 1=2--

If responses differ, it may be injectable.

Time-based test:
?id=1' AND SLEEP(5)--

SSRF (Server-Side Request Forgery)

SSRF allows attackers to make the server send requests to internal or restricted resources.

Possible impacts:

Access internal admin panels
Scan internal network ports
Read internal services
Access cloud metadata
Remote code execution in some cases

Example:
https://example.com/proxy?url=http://127.0.0.1

Internal targets:
http://127.0.0.1

http://localhost

http://10.0.0.1

http://172.16.0.1

http://192.168.0.1

http://169.254.169.254/latest/meta-data/

Rate Limiting Bypass

Rate limiting is used to prevent brute force attacks and abuse.

Common bypass methods:

IP rotation
Race conditions
Parameter manipulation

Examples:
email@site.com%00

email@site.com%0d

email@site.com%0a

email@site.com%09

Headers to test:
X-Originating-IP

X-Forwarded-For

X-Remote-IP

X-Remote-Addr

X-Client-IP

X-Host

Check:

OTP systems
Login attempts
Signup flows
Token granting systems

CORS Misconfiguration

CORS issues occur when the server trusts untrusted origins.

Test request:
Origin: https://evil.com

Look for:
Access-Control-Allow-Origin: *

Access-Control-Allow-Credentials: true

Access-Control-Allow-Origin: null

Impact:

Data theft from authenticated users
Cross-origin account compromise

Other Vulnerabilities to Learn

Clickjacking
Broken link hijacking
HTML injection
XXE
RCE
File upload vulnerabilities

Conclusion

If you are starting with bug bounties:

Focus on recon first
Learn core web vulnerabilities
Understand how web applications work and languages like JavaScript and SQL
Practice consistently

Recon will always be the most important skill in bug bounty hunting.

Focus on one vulnerability at a time. Do not try to learn everything at once.

When starting out, begin with IDOR since it is usually easier to find.

How Hackers Hide Malware Inside Android Apps

MRxO1 — Fri, 06 Feb 2026 10:40:17 +0000

How Android Malware Gets Hidden Inside Legit Apps

Ever wondered how some Android malware manages to hide inside legitimate apps and avoid detection and bypass AV?

In this article, we’ll look at a high level overview of how attackers bind malicious payloads to legitimate applications, and more importantly, what defenders should watch for.

This article is for educational and defensive awareness only.

Research Reference

For those interested in the full research notes and demonstration material, you can check my GitHub repository:

GitHub:
https://github.com/MRxO11/How_Attacker_Make_FUD_Android_Malware

What is Android Payload Binding?

Payload binding is a technique where attackers:

Take a legitimate Android application.
Inject malicious code into it.
Repackage and distribute the modified app.

To the user, the app looks normal.
In the background, it may:

Open a reverse shell
Steal SMS messages
Exfiltrate data
Give remote access to the attacker

This technique is commonly used in Android RATs (Remote Access Trojans).

High Level Attack Flow

A typical payload binding attack follows these stages:

1. Malicious Payload Creation

Attackers generate a malicious Android payload designed to:

Connect back to a command and control server
Execute remote commands
Maintain persistence

2. Decompiling the Legitimate App

The attacker takes a trusted or popular APK and decompiles it to:

Access its internal structure
Modify its code
Inject malicious components

3. Injecting Malicious Code

The payload’s code is inserted into the legitimate app’s structure.

This allows the malware to:

Run silently in the background
Use the app’s permissions
Blend in with normal app behavior

4. Modifying Permissions

Attackers often modify the app’s manifest to request additional permissions, such as:

Internet access
SMS access
Storage access

These permissions allow data exfiltration or remote control.

5. Repackaging and Signing

The modified app is rebuilt and signed so it can be installed on Android devices.

This final APK is then distributed through:

Phishing links
Fake app stores
Social engineering campaigns

Indicators of a Bound Malicious APK

Security analysts should look for:

Suspicious Permissions

SMS access for a non messaging app
Contact or storage access without reason

Package Name Changes

Generic or suspicious names like:
- com.google.services
- com.android.update

Unusual Network Activity

Connections to unknown IPs or domains
Persistent background traffic

Repackaged App Signs

Different developer signature
Slightly altered UI or behavior

Final Thoughts

Payload binding is a common technique used in Android malware campaigns.
Understanding how it works helps defenders:

Recognize suspicious apps
Detect repackaged malware
Improve mobile security posture

Cybersecurity knowledge should always be used to defend systems, not compromise them.

WannaCry Ransomware Malware Analysis

MRxO1 — Fri, 06 Feb 2026 10:29:09 +0000

WannaCry Ransomware Malware Analysis

The WannaCry sample used for this analysis was obtained from the following repository, specifically prepared for educational and research purposes.

Sample Source:
https://github.com/HuskyHacks/PMAT-labs/tree/main/labs/4-1.Bossfight-wannacry.exe

Analysis Approach

To understand the behavior of the malware, both static and dynamic analysis techniques were used.

Static Analysis

Static analysis involves examining the malware without executing it. This helps identify:

Embedded strings
Suspicious imports
Hardcoded domains
Encryption routines
Indicators of compromise

This stage provides an initial understanding of what the malware is capable of doing.

Dynamic Analysis

Dynamic analysis involves executing the malware inside a controlled and isolated environment (such as a virtual machine or sandbox). This allows us to observe:

File system changes
Network activity
Process creation
Persistence mechanisms

This step confirms whether the behaviors seen in static analysis actually occur during execution.

Executive Summary

SHA256:
A6AA84358130078F9455773AF1E9EF2C7710934F72DF8514C9A62ABEB83D2E81

The analyzed sample behaves as a ransomware dropper that executes multiple payloads after initial infection. Once executed, it encrypts files on the system and attempts to spread laterally across the network.

Symptoms of Infection

Encrypted files with the .wncry extension
Desktop wallpaper replaced with a ransom note
Presence of:
- @Please_Read_Me@.txt
- @WanaDecryptor@.exe
Suspicious executable appearing in %APPDATA%

Indicators of Infection and System Modifications

After successful execution:

Files are encrypted and renamed with the .wncry extension.
Desktop wallpaper is replaced with a ransom message.
Two files appear on the desktop:
- @Please_Read_Me@.txt – contains ransom instructions.
- @WanaDecryptor@.exe – ransomware interface for payment.

These are clear signs of a successful ransomware detonation.

Static Analysis – String Examination

Static string analysis was performed using FLOSS.

Execution Indicator

One of the common PE indicators:

This program cannot be run in DOS mode.

Kill Switch Domain

A hardcoded domain was discovered:

hxxp://www[.]iuqerfsodp9ifjaposdfjhgosurijfaewrwergwea[.]com

This domain acts as a kill switch, which determines whether the malware continues execution.

Cryptographic Functions

Strings showed usage of Windows CryptoAPI:

Microsoft Enhanced RSA and AES Cryptographic Provider
CryptGenKey
CryptDecrypt
CryptEncrypt
CryptDestroyKey
CryptImportKey
CryptAcquireContextA

These indicate that the malware performs file encryption using built-in Windows cryptographic functions.

Multilingual Ransom Notes

The malware contains multiple language files:

msg/m_italian.wnry
msg/m_japanese.wnry
msg/m_korean.wnry
msg/m_latvian.wnry

This suggests the malware was intended for global distribution.

Other Notable Strings

tasksche.exe
icacls . /grant Everyone:F /T /C /Q
attrib +h .
WNcry@2ol7
\\192.168.56.20\IPC$

These strings indicate:

File permission changes
Hidden directory creation
Network propagation behavior

Import Analysis Using PEStudio

PEStudio was used to examine imported Win32 APIs.

This revealed functionality related to:

Encryption
File operations
Network communication
Command execution

This confirms that the malware is capable of:

Encrypting files
Spreading across the network
Establishing persistence

Detonation Conditions (Kill Switch Logic)

Before executing its payload, WannaCry attempts to contact the kill switch domain.

Behavior Logic

Malware sends HTTP request to the domain.
If the domain responds:

Malware terminates.
1. If no response:
Malware continues execution.

Lab Consideration

To allow detonation during analysis:

DNS simulation tools (like INetSim) must be disabled.
Otherwise, the malware may terminate early.

Network-Based Indicators

Kill Switch Communication

The malware attempts to reach:

hxxp://www[.]iuqerfsodp9ifjaposdfjhgosurijfaewrwergwea[.]com

A successful connection stops execution.

Local Listener on Port 9050

Observed process:

taskhsvc.exe

Port 9050 is commonly associated with Tor, suggesting:

Anonymous communication
Possible payment verification via Tor network

SMB Propagation Behavior

WannaCry generates large numbers of SMB requests over port 445.

Observed actions:

Accessing \\<IP>\IPC$
Using named pipes
Attempting null or brute-force authentication

This behavior aligns with exploitation of:

EternalBlue (MS17-010)

This allows the ransomware to spread across vulnerable machines.

Host-Based Indicators

Using Procmon, a suspicious process was identified:

tasksche.exe

Observed actions:

Writing files to disk
Modifying file attributes
Creating scheduled tasks

This confirms its role in persistence.

File System Activity

The malware creates a hidden directory:

C:\ProgramData\<random_folder>\

This directory contains:

Encrypted payloads
Configuration files
Executables

It acts as a staging area for the ransomware.

now this Image showing the new created directory

Persistence Mechanism

A new Windows service is created using the same name as the random folder.

Purpose:

Execute malware on every reboot
Maintain persistence even after process termination

Kill Switch Mechanism – Debugger Analysis

During debugging, the following execution flow was observed:

Kill switch URL loaded into ESI.
Value transferred to EAX.
Passed into InternetUrlA API.
Result stored in EDI.

The main function of Wannacry

Decision Logic

If EDI == 0

Connection failed
Malware continues execution

If EDI != 0

Connection successful
Malware terminates

Payload Execution

If kill switch fails:

fcn.00408090

is executed, initiating:

File encryption
Network propagation

Manipulating the Kill Switch in the Debugger

By manually modifying the value of the EDI register:

Simulated a successful kill switch response.
Malware exited immediately.
Encryption and propagation were prevented.

This confirms the kill switch is hardcoded into the execution logic.

Tools Used

Cutter (Radare2) – Static analysis
x32dbg – Dynamic debugging
Procmon – Process and file activity
PEStudio – Import analysis
FLOSS – String extraction

YARA Detection Rule

rule WannaCry_Simple_PMAT
{
    meta:
        description = "Detects WannaCry ransomware - based on PMAT by TCM"
        author = "MRxO1"
        reference = "PMAT - Practical Malware Analysis & Triage"
        date = "2025-04-25"
        malware_family = "WannaCry"

    strings:
        $s1 = "http://www.iuqerfsodp9ifjaposdfjhgosurijfaewrwergwea.com" ascii
        $s2 = "tasksche.exe" ascii
        $s3 = "WNcry@2ol7" ascii
        $s4 = "Ooops, your files have been encrypted!" ascii nocase
        $s5 = "icacls . /grant Everyone:F /T /C /Q" ascii
        $s6 = "msg/m" ascii

    condition:
        uint16(0) == 0x5A4D and
        4 of ($s*)
}

References

PMAT – Practical Malware Analysis & Triage
Microsoft MS17-010 Security Bulletin