As part of the Product Security Intern assignment for Fam (Trio), I was tasked with a Capture The Flag (CTF) challenge. The objective was straightforward yet testing: analyze an Android APK, identify vulnerabilities, navigate through a web challenge, and capture a hidden flag.

This write-up details my methodology, the “happy accidents” encountered along the way, and a comprehensive report on the security findings.

Phase 1: Reconnaissance & Static Analysis

The challenge began at https://challenge.fam-app.in. The landing page presented a clean interface asking for a “Secret” to proceed, along with a download link for an Android application (fam-CTF.apk).

My first step was to perform static analysis on the provided APK file. Instead of running the app immediately, I wanted to inspect its internal structure. I uploaded the fam-CTF.apk to a Java decompiler to inspect the source code and resources.

The Discovery:
While browsing the AndroidManifest.xml file, I noticed a suspicious meta-data tag. Developers often leave API keys or configuration secrets in the manifest, and this case was no exception.

I found the following entry:

<meta-data android:name="com.famctf.API_KEY" android:value="f4m_53cr37_70k3n" />

The value f4m_53cr37_70k3n looked exactly like the API_KEY secret required on the web portal.

Phase 2: Gaining Access & Web Enumeration

Armed with the key found in the APK, I returned to the challenge website.

1. I entered f4m_53cr37_70k3n into the secret input field.
2. Upon submission, I was redirected to a new endpoint.

The new page featured a simple file upload interface. In CTF scenarios, file upload forms are prime targets for Remote Code Execution (RCE) via malicious scripts (like PHP shells) or metadata exploits.

Phase 3: Exploitation & The “Happy Accident”

I initially attempted to upload a standard PHP backdoor (<?php $_GET[“cmd”] ?>) to see if I could execute commands on the server.

• Observation: The server accepted the PHP file without filtering the extension or MIME type.
• Result: However, on navigating to /uploads/filename.ext, the server returned the file content as plain text. The PHP was not executed, meaning the server was likely not configured to run PHP files in the upload directory.

The Pivot:
I decided to test how the server handled image files. I uploaded a PNG file. Interestingly, the server response headers contained a custom field: X-Message.

When I uploaded my PHP script earlier, the header read: “This is not a reverse code. Try harder!”

However, when I uploaded a specific AI-generated image (a cat in a Dr. Strange outfit), the behavior changed entirely. The server responded with a 200 OK and a crucial set of headers:

The Response Headers:

• X-Message: “Token generated. Use this token to access /new-assignment-security-intern”
• X-Auth-Token: a95e1f4e-2c67–4c91-ba08–98d3a63eda4b
• X-Endpoint-Hint: c3VibWl0LWFzc2lnbm1lbnQ=

Analysis of the “Accident”:
Why did a PNG trigger a success state when a PHP shell failed?
Upon inspecting the image metadata, I realized the AI-generated image contained Adobe XML tags (<x:xmpmeta…>). It appears the server-side security check was using a Regex or string matching to look for “code-like” syntax to detect reverse shells. Paradoxically, the innocent XML metadata in the image likely triggered a “False Positive” in the server’s security logic, which the system interpreted as a successful “exploit” of the level, granting me the token.

Phase 4: Token Enumeration & Flag Capture

With the token and the endpoint hint, I moved to the final stage.

Step 1: Decrypting the Hint
The header X-Endpoint-Hint contained a Base64 string: c3VibWl0LWFzc2lnbm1lbnQ=
Decoding this gave me the slug: submit-assignment.

Step 2: Retrieving Instructions
I navigated to /new-assignment-security-intern using the token I acquired. I passed it as a query parameter ?token=….

The response provided a JSON object with instructions on how to submit the flag:

• Endpoint: /c3VibWl0LWFzc2lnbm1lbnQ= (which is /submit-assignment)
• Method: POST
• Body: JSON containing email, flag, name, and phone-number.
• Flag Logic: The response included a flag field: “RkBNe1NFQ18zNzM3M19IM3kwMDkxMTB9==”.

Step 3: The Final Submission
I constructed a POST request in Burp Suite to the submission endpoint.

The server responded: “Submission received successfully”.

Step 4: Decoding the Flag
The challenge provided the final flag in Base64 format. Running it through a decoder revealed the victory text.

Post-Mortem & Security Report

Vulnerability Analysis

1. Hardcoded Credentials (APK):
   The most critical vulnerability was the storage of the API key (f4m_53cr37_70k3n) in plain text within the AndroidManifest.xml. This allowed for trivial bypass of the initial authentication layer.
2. Insecure File Upload Logic:
   The server lacked strict validation on file contents. While it didn’t execute PHP (a good defense), its detection mechanism for “malicious code” (Reverse Shell detection) was flawed. It relied on pattern matching that produced false positives on legitimate file metadata (Adobe XMP data), inadvertently allowing an attacker to bypass the challenge logic.
3. Token Re-use & Predictability:
   During testing, I noticed the server mapped generated tokens to filenames.

• Uploading image.png generated Token A.
• Uploading image.png again (overwriting it) returned Token A.
• Renaming the file to image2.png generated Token B.
  This suggests a deterministic generation or weak session management tied to file attributes rather than user sessions.

Recommendations

To improve the security posture of the application, I recommend the following:

• Secrets Management: Never hardcode API keys or secrets in the client-side code (APK). Use Android Keystore or fetch session-specific tokens from a secure backend upon user authentication.
• Robust File Validation:
• Implement strict allow-listing for file types (check Magic Bytes, not just extensions).
• Strip metadata (EXIF/XMP) from images upon upload to prevent payload hiding and logic errors like the one encountered.
• Logic Improvement: The “Reverse Shell” detection mechanism seems to rely on weak regex. It should be replaced with actual behavioral analysis or simply by ensuring the upload directory is non-executable ( noexec).
• Data Transmission: The challenge required sending the flag in Base64. In a production environment, sensitive data should never be encoded merely in Base64; use transport security and consider payload encryption if the data is highly sensitive. For example, we can use PGP keys with Emails for sending confidential data.

Conclusion

This challenge was a fantastic exercise in combining mobile reconnaissance with web exploitation. It highlighted how even “secure” file uploaders can have logic flaws and reinforced the golden rule of mobile dev: The Manifest is not a safe functionality.

Final Flag: F@M{SEC_58392_1765982406}

Cracking the Code: A Walkthrough of the Fam Product Security Challenge was originally published in InfoSec Write-ups on Medium, where people are continuing the conversation by highlighting and responding to this story.

This challenge is to be solved using the knowledge of PHP.

The Challenge page presents the PHP source code which we must debug in order to obtain the flag.

Summary

The script includes a file named flags.php.

The script accepts four GET parameters named pass1, pass2, pass3, and pass4, each of which is used to check if a particular password is correct. If a password is correct, the corresponding flag is printed out.

Here’s a breakdown of each password check:

1. pass1: The value of pass1 is checked against the string "secret", with case-insensitivity and the word "secret" removed using a regular expression. If the value matches the modified string "secret", the first flag is printed out.
2. pass2: The value of pass2 is checked against its MD5 hash. If the value matches its MD5 hash, the second flag is printed out.
3. pass3: The value of pass3 is checked against the string "Array", with case sensitivity. If the value matches the string "Array", the script terminates with an error message. Otherwise, the value is concatenated with the string "123" and checked against the string "Array123". If the concatenated value matches the string "Array123", the third flag is printed out.
4. pass4: The value of pass4 is treated as a filename, and the contents of that file are checked against the string "Good Challenge". If the contents of the file match the string "Good Challenge", the fourth flag is printed out.

The script sets the error reporting level to include errors, warnings, and parse errors, and then outputs its own source code using the highlight_file function. This means that any error messages or output from the script will be visible to the user.

Starting Point — URL Format

https://ch3521618630.ch.eng.run/?flags.php&pass1=&pass2=&pass3=&pass4=

The above URL is obtained by placing the included files and request Query parameters.

Solution

• For pass1, we can use the following string or any similar variation of the string to pass the checks: secsecretret . The payload after the replace operation changes to secret and hence the conditional check passes and the first part of the flag is printed.

if(isset($_GET['pass1'])){
    $pass1 = $_GET['pass1'];
    $pass1 = preg_replace("/secret/i","",$pass1);
    if($pass1 === 'secret'){
        echo '<br>'.$flag1;
    }
    else{
        die("Nope !!!!!!!!!!!");
    }
}

• For pass2, we can use 0e215962017 . The value 0e215962017 is a special string in PHP because it is interpreted as the floating-point number 0.0 when used in a numeric context, such as in a comparison using the == or === operators. This is because 0e is the exponent notation for scientific notation, and the digits that follow are treated as the exponent. For example, the expression 0e215962017 == 0 will evaluate to true because 0e215962017 is interpreted as 0.0 in a numeric context. This can lead to unexpected behaviour in certain situations, such as when using the == operator to compare a string that happens to be formatted in this way with a numeric value.

if(isset($_GET['pass2'])){
    $pass2 = $_GET['pass2'];
    if($pass2 == md5($pass2)){
        echo $flag2;
    }
    else{
        die('Mmm Nope');
    }
}

• For pass3, we can bypass the conditional checks by passing pass3 as an Array (hinted by the keyword “Array” in the condition checks)

if(isset($_GET['pass3']))
{
    $pass = $_GET['pass3'];
    if($pass === 'Array'){
        die("Not that easy");
    }
    if($pass.'123' === 'Array123'){
        echo $flag3;
    }
    else{
        die("Not that easy !!!");
    }
}

• For pass4, using data://text/plain,Good%20Challengeas the parameter value, we get the final flag.

if(isset($_GET['pass4'])){
    $pass = $_GET['pass4'];
    if(file_get_contents($pass) === "Good Challenge"){
        echo $flag4;
    }
    else{
        die('Wow so rude');
    }
}

Final Payload

https://ch3521618630.ch.eng.run/?flags.php&pass1=secsecretret&pass2=0e215962017&pass3[]=Array&pass4=data://text/plain,Good%20Challenge

Flag: flag{…}

The Challenge description tells us everything that we need to know — to solve this challenge, we need to use our extensive knowledge of the scripting language of the web — JavaScript

There is little relevant information on the frontend UI, let's have a look at the page source code.

Let's have a look at the referenced script.jsfile since this challenge involves javascript.

The first part of the code just seems to grab the fleg query parameter from the URL and checks if it is a null value and logs “rEad JS ?” to the console if it is a null value.

Executing the following code snippet on the console, we get

var charset="_0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ";
let flag="flag"+fleg+"}";
let actualflag=atob("ZmxhZ3tDbDEzblRfczFEM18xUwo=");
  actualflag=actualflag+charset.substring(0,1);
  actualflag=actualflag+charset.substring(24,25);
  actualflag=actualflag+charset.substring(1,2);
  actualflag=actualflag+charset.substring(56,57);
  actualflag=actualflag+charset.substring(0,1);
  actualflag=actualflag+charset.substring(55,56);
  actualflag=actualflag+charset.substring(4,5);
  actualflag=actualflag+charset.substring(13,14);
  actualflag=actualflag+charset.substring(57,58);
  actualflag=actualflag+charset.substring(28,29);
  actualflag=actualflag+charset.substring(4,5);
  actualflag=actualflag+String.fromCharCode(125)

Removing the newline \n, we get

Flag: flag{…}

The title of the CTF Challenge gives us a huge hint on how to go about solving the Challenge — HTTP Cookies.

The Challenge page seems to be Sign In page of some kind.

To get the login credentials for the above Sign In page, we need to view the page source code.

We obtain the credentials as guest: guest (username: password)

On Signing In with the obtained credentials, we can view a protected page where only admins are allowed

To bypass the above restriction, we need to manipulate the local session cookies.

To view and manipulate the site cookies Open Chrome DevTools > Application > Cookies

The cookie for login seems to be a base64 encoded token

The decrypted base64 token yields a JSON (JavaScript Object Notation) object which contains user and user_hash properties.

We can now try to leverage the idea of an IDOR (Insecure Direct Object Reference) vulnerability to fool the client—web application into thinking that we are an admin user and give us the flag.

To proceed further with the same, we need to figure out the type of hashing algorithm used in user_hash

Using a web tool, we identify the hash as MD5, and the hash on decryption yields guest

Now, all that we need to do is create a JSON Object with the user property set to admin and user_hash property set to an MD5 hash of admin. Finally, we encode the resulting JSON object to a base64 encoded string and replace the login cookie value with our new token.

{
   "user":"admin",
   "user_hash":"21232f297a57a5a743894a0e4a801fc3"
}

Encoding the above using base64 gives us the following token

ewogICAidXNlciI6ImFkbWluIiwKICAgInVzZXJfaGFzaCI6IjIxMjMyZjI5N2E1N2E1YTc0Mzg5NGEwZTRhODAxZmMzIgp9

Replacing the login cookie with the above token and refreshing the page, we get

Flag: flag{…}

Based on the challenge description, we need to solve the challenge using the knowledge of the client-server communication model.

On clicking “GET FLAG”,

we get an alert stating Unauthorized browser !!! Only users from bi0s are allowed

Now, the question arises that how did the web server know that my browser is not “bi0s”.

The answer to the above question lies in the request headers (more specifically, the User-Agent part of the Request Headers)

Using Chrome DevTools > Network to view the network requests sent by the web application when we click on the “GET FLAG” button, we observe that a user-agent is already set by the web browser when the request was sent.

To intercept the network requests sent by the client-web application to the web server we need to use an intercepting proxy tool like Burp, and Owasp Zap which will allow us to manipulate the request data sent from the client side.

Changing the User-Agent to bi0s using Burp Suite

We now receive an alert stating that only users from bi0s.in are permitted to view the requested resource.

The above issue can easily be fixed by changing the Referrer Request header to bi0s.in and sending the network request.

We have now successfully bypassed the restrictions set and we can now find the flag in the last line of the received response / via the page source code.

Flag: flag{…}

The name of the challenge by itself gives us a hint that the flag is scattered somewhere throughout the web application source code.

On opening the page source code using ctrl + u we can spot two hints

• The flag isn’t present in the main html source code of the page.
• An external CSS stylesheet is referenced in the main html document.

On opening the referenced stylesheet, we are presented with the first part of the flag along with a hint.

The first part of the flag: `flag{… `

Going by the hint, we need to have a look at the robots.txt file of the site.

The file indicates that /s3cr3t.html is prevented from being indexed by Search Engines.

On navigating to /s3cr3t.html we are presented with a challenge to decode the given base64 encoded text to receive the second part of the flag.

Decoding the above text, we get `g3n1u5_L1L`

To receive the remaining part of the flag, we need to view the source code of the challenge page.

The final hint takes us to the /security.txt file hosted on the web server which gives us the final part of the flag.

The final part of the flag: `…}`

Joining the pieces of the puzzle, we get the final flag as

flag{…}

From the growth of Online learning during this pandemic — students, researchers have been on a hunt for hacks on Microsoft Forms which could give them an unfair advantage in their tests, pop quizzes etc.

There have been many on YouTube who have claimed to have found such treasures by inspecting the source code, trying other tricks, etc but it's all just clickbait to attract viewers.

What I am going to share today will change all that…

As all of you may have read from the subject line of this story, yes I have found a way to hack Microsoft Forms but its not quite what you may expect —

Summary

• Whenever a form is submitted, an API POST request is made to the /formapi/api/${API_Key}/users/${User_Key}/forms(${FormID})/responses endpoint
• By intercepting the POST request, a user/attacker can put a new entry / null string, thereby bypassing the required field / adding a new option completely.
• Due to the absence of Server-side checks, the same reflects in the forms responses available to the form owner.

Intercepted Payload

{“startDate”:”2021–12–02T18:38:36.784Z”,”submitDate”:”2021–12–02T18:38:40.820Z”,”answers”:”[{\”questionId\”:\[REDACTED]},\”answer1\”:\${New Option} OR null \”}]”}

Summary — Translated For Layman

• When a user submits a form, the webpage / the form (Client) sends a message to the server saying that this user has submitted “X” as the response for a particular question with a unique id “Y” and the server saves the same in its database which is made available for the form owner to view as the responses.
• By acting as a middle man and intercepting the message, the attacker can change the message sent by the webpage to say that the particular user has sent “Z” as the response for a particular MCQ based question where Z is not in the options available / is an invalid input.
• Due to the absence of server-side checks to confirm whether the option is one of the valid options, one can manipulate Ratings, Net Promoter Scores, and also add a new Option in an MCQ / Checkbox / Dropdown based Question.
• The same gets saved in the Database and is sent to the Form owner as a part of the set of responses.
• One problem with this attack that limits its impacts is that the attacker can manipulate only his / her response and not other users responses.

Attack Scenario

• When corporates use this form for their internal competition for employees, any misuse may bring in reputational issues for the corporates and in turn, it will harm Microsoft’s brand image,
• Large corporates running a certain campaign for the public through these forms can face huge revenue loss and reputational harm if there is scope for misuse through options beyond the listed ones.
• Microsoft forms are predominantly used in schools for the conduct of examinations. Any potential attack or misuse can play havoc with students’ lives and can cause irreparable loss for the students and their families.

This Bug affects both quizzes and normal Forms.

Steps to Reproduce Bug

• Create a new Form on MS Forms.
• Open the Form.
• Follow the steps as shown in the POC attached below.

POC (Proof Of Concept)

Disclaimer: By reading this article, you agree to use this information only for educational purposes and not to cheat in your tests/pop quizzes and I, as the author of this article, take no responsibility for any ill practices from your end.

🔈 🔈 Infosec Writeups is organizing its first-ever virtual conference and networking event. If you’re into Infosec, this is the coolest place to be, with 16 incredible speakers and 10+ hours of power-packed discussion sessions. Check more details and register here.

IWCon2022 - Infosec WriteUps Virtual Conference

Hacking Microsoft Forms was originally published in InfoSec Write-ups on Medium, where people are continuing the conversation by highlighting and responding to this story.