CODE LINK:-

https://www.dropbox.com/scl/fi/vy80obp7ucw1kh34tn87q/30-April-2025-Facebook-Scam-Alert-CA-Rachana-Ranade.txt?rlkey=twju9uux2vt02ozvbowu28j79&st=7yv60gjn&dl=0

🔍 Deobfuscating and Analyzing Obfuscated JavaScript in Web Pages: A Case Study

Introduction

Modern web pages—especially those of large platforms like Facebook—frequently employ dynamic JavaScript loading and obfuscation techniques. While many of these mechanisms are legitimate and performance-driven, they also present an opportunity for obfuscation and potential misuse in spoofed or cloned environments.

This article analyzes a base64-encoded JavaScript snippet discovered in a suspicious HTML dump. We decode and interpret its functionality to highlight what it does, how it works, and its implications in both secure and compromised contexts.

Discovery

During static analysis of a web page, the following base64-encoded JavaScript was identified:

cmVxdWlyZUxhenkoWyJTZXJ2ZXJKU1BheWxvYWRMaXN0ZW5lciJdLGZ1bmN0aW9uKG0pe20ucHJvY2VzcygpO30sbnVsbCwweDEwMCk=

Step 1: Base64 Decoding

Decoding this string yields the following JavaScript:

requireLazy(["ServerJSPayloadListener"], function(m) {
    m.process();
}, null, 0x100);

Step 2: Code Analysis

`requireLazy([...], function(m) {...})`

This is part of Facebook’s internal JavaScript module system used to defer the loading of scripts. It waits to load certain features until the page reaches a particular state.

Module Name: "ServerJSPayloadListener"
Callback Function: Once loaded, the module is passed to a function where m.process() is invoked.

`m.process()`

This likely processes server-sent JavaScript payloads, enabling:

Hydration of SSR (server-side rendered) content
DOM updates based on user session or real-time data
Potential code execution received from the server

`0x100`

This is a hexadecimal representation of the number 256. It may indicate a queue depth, priority level, or execution order within Facebook’s module loader.

Step 3: Security Considerations

While this specific script does not exhibit malicious behavior, it represents a pattern that is important to analyze in security audits:

Legitimate Use Case: This script is a normal part of Facebook's modular JS architecture.
Potential for Abuse: In cloned or spoofed environments, similar patterns may be abused to load malicious content silently, as the actual logic is deferred and abstracted behind requireLazy.

Recommendations for Security Analysts

Decode and inspect any base64-encoded inline scripts during static analysis.
Trace dynamic module loading, especially when tied to user interaction or server-triggered content.
Flag deferred execution patterns when auditing cloned or repackaged websites, as attackers use them to evade detection.

Conclusion

This case highlights the importance of analyzing obfuscated or encoded JavaScript found in HTML dumps. While not all obfuscation is malicious, it's a common technique in modern malware and phishing pages to hide payloads and evade static analysis.

By deconstructing this script, we demonstrated how even benign-looking deferred modules can become vectors for more complex attacks in the hands of threat actors.

Would you like this formatted as a downloadable PDF or Markdown file?

-----------------

Based on the analysis of the uploaded file “30-4-25 rr fb.txt”, here is a detailed breakdown of potentially suspicious or malicious behaviors according to your checklist:

✅ Detected Issues:

Obfuscated JavaScript / Minified & Encoded Code:
- Multiple <script src="data:text/javascript;base64,..."> entries are present, indicating embedded base64-encoded scripts.
- The code cmVxdWlyZUxhenkoWyJTZXJ2ZXJKU1BheWxvYWRMaXN0ZW5lciJd... decodes to obfuscated requireLazy(...) functions.
Encoded URL Decoding:
- Use of linkshim_enc_param, linkshim_url_param indicates cloaked redirection and encoded tracking.
Hidden Redirects:
- Paths like /l.php, /r.php, /mr/, /redirect/ strongly suggest usage of redirectors, which are commonly abused for phishing or malicious redirection.
Tracking Beacons or Pixels:
- The presence of /fbs/pixel/, /sem_campaigns/sem_pixel_test/, and /zero/balance/pixel/ implies tracking pixel use.
External Script Calls:
- References to scripts hosted on static.xx.fbcdn.net, possibly dynamic scripts being loaded based on config values.
Suspicious Form/Interaction Patterns:
- Repeated usage of inline JSON with require or SSR-related code suggests hidden/injected functionality that could alter DOM or behavior based on user session states (see CometSSRMergedContentInjector).
Device Fingerprinting or Storage Access:
- Mention of local/session storage access patterns (e.g., deviceLevel, yearClass, cookie, localStorage) and cookie logging configurations.

⚠️ Potential Concerns (Require further runtime or dynamic analysis):

Fake Login Forms: While there is evidence of /login.php, /contactpoint/login/, and autologin.php references, there's no HTML form in the static dump to confirm if they are clones or phishing UIs.
Keylogging / Inline Event Abuse: No direct evidence of onkeypress, oninput, etc., but obfuscated JS could hide this behavior.
Auto-download Triggers: No automatic download behavior is directly visible but should be tested in runtime with tools like browser sandboxing.
Browser Exploit Code: No deprecated or known exploit APIs were found in the static code.
Permission Abuse (mic, camera, geolocation): No navigator.mediaDevices or geolocation.getCurrentPosition type calls were detected.

✅ Benign or Legitimate Findings:

Usage of known Facebook domains and CDNs (like fbcdn.net, facebook.com, fbsbx.com) seems mostly aligned with standard scripts and not clearly misused in this sample.
The inclusion of accessibility features, language toggles, and analytics scripts matches normal Facebook session behavior.

🔍 Summary:

This file contains clear signs of obfuscation, base64 embedded scripts, and suspicious redirection and pixel tracking behaviors, all of which warrant dynamic sandbox testing for further insights. It appears to be either a heavily stripped-down or tampered snapshot of Facebook's interface, possibly altered or repacked for unintended purposes.

Let's deobfuscate and analyze this base64-encoded JavaScript snippet found in the file:

cmVxdWlyZUxhenkoWyJTZXJ2ZXJKU1BheWxvYWRMaXN0ZW5lciJdLGZ1bmN0aW9uKG0pe20ucHJvY2VzcygpO30sbnVsbCwweDEwMCk=

Decoded JavaScript

requireLazy(["ServerJSPayloadListener"], function(m) {

m.process();

}, null, 0x100);

What This Code Does

requireLazy(...) is a Facebook-specific JavaScript loading mechanism for deferring code execution until needed.
"ServerJSPayloadListener" is likely a module responsible for handling server-sent JavaScript payloads.
m.process() invokes that module's process() function — typically this would:
- Parse and apply server-provided data embedded in the HTML (e.g., personalization, metrics).
- Possibly hydrate SSR content or process queued messages.
The use of 0x100 (hexadecimal for 256) might indicate a priority or queue depth in their lazy loader system.

⚠️ Security/Behavioral Considerations

This script by itself is not malicious. However:

Because it loads content dynamically via a named module (ServerJSPayloadListener), the actual behavior is deferred and not visible statically.
It opens the door for injecting content from server to client, which can be exploited if an attacker can control server responses or override requireLazy.

✅ Conclusion

The decoded base64 script is a legitimate Facebook script used to delay execution of a module until necessary. However, in untrusted clones, spoofed pages, or repacked environments, this mechanism can be abused to hide or delay malicious logic.

---------

यह रहा ऊपर दिए गए विश्लेषण का हिंदी संस्करण, एक लेख के रूप में:

🔍 वेब पेज में छिपे हुए या एन्कोडेड JavaScript का विश्लेषण: एक केस स्टडी

परिचय

आधुनिक वेब पेज—विशेष रूप से फेसबुक जैसे बड़े प्लेटफार्म—अक्सर JavaScript को डिफर्ड (deferred) तरीके से लोड करने और उसे जटिल (obfuscated) बनाने की तकनीकें अपनाते हैं। हालांकि इनमें से अधिकांश तकनीकें वैध और परफॉर्मेंस उन्मुख होती हैं, लेकिन इन्हीं के माध्यम से छिपा हुआ या दुर्भावनापूर्ण कोड भी उपयोगकर्ता से छुपाया जा सकता है, विशेषकर नकली (spoofed) या क्लोन किए गए पृष्ठों में।

इस लेख में हम एक ऐसे base64 एन्कोडेड JavaScript स्निपेट का विश्लेषण करेंगे जो एक संदिग्ध HTML फ़ाइल में पाया गया। हम इसे डिकोड करके समझेंगे कि यह क्या करता है, इसका उपयोग कैसे होता है, और इसके सुरक्षा पहलुओं पर क्या प्रभाव पड़ सकते हैं।

चरण 1: कोड की खोज

हमारे विश्लेषण के दौरान हमें यह base64 एन्कोडेड स्ट्रिंग मिली:

cmVxdWlyZUxhenkoWyJTZXJ2ZXJKU1BheWxvYWRMaXN0ZW5lciJdLGZ1bmN0aW9uKG0pe20ucHJvY2VzcygpO30sbnVsbCwweDEwMCk=

चरण 2: Base64 डिकोडिंग

डिकोड करने के बाद, हमें यह JavaScript कोड प्राप्त हुआ:

requireLazy(["ServerJSPayloadListener"], function(m) {
    m.process();
}, null, 0x100);

चरण 3: कोड विश्लेषण

`requireLazy([...], function(m) {...})`

यह Facebook का एक आंतरिक मॉड्यूल लोडर सिस्टम है जो आवश्यकतानुसार कोड को लोड करता है, जिससे पेज की लोडिंग तेज होती है।

मॉड्यूल नाम: "ServerJSPayloadListener"
फंक्शन कॉल: मॉड्यूल लोड होने पर, m.process() को कॉल किया जाता है।

`m.process()`

यह संभवतः सर्वर से भेजे गए JavaScript payloads को प्रोसेस करता है, जिससे:

Server-Side Rendered (SSR) सामग्री को activate किया जा सकता है।
DOM को उपयोगकर्ता के सेशन या डेटा के अनुसार अपडेट किया जा सकता है।
JavaScript को रनटाइम में सर्वर से प्राप्त किया जा सकता है।

`0x100`

यह 256 का hexadecimal रूप है। यह संभवतः execution priority या queue level को दर्शाता है।

चरण 4: सुरक्षा विचार

हालांकि यह स्क्रिप्ट स्वयं में दुर्भावनापूर्ण नहीं है, यह एक ऐसी संरचना दिखाती है जो सुरक्षा ऑडिट के लिए महत्वपूर्ण होती है:

वैध उपयोग: Facebook द्वारा मॉड्यूल आधारित कोड लोडिंग के लिए उपयोग में लाया गया।
संभावित दुरुपयोग: नकली या क्लोन किए गए साइट्स में ऐसे deferred execution patterns का उपयोग करके दुर्भावनापूर्ण स्क्रिप्ट लोड की जा सकती हैं।

सुरक्षा विश्लेषकों के लिए सुझाव

HTML और स्क्रिप्ट में मौजूद सभी base64 एन्कोडेड कोड को डिकोड करें।
डायनामिक मॉड्यूल लोडिंग को ट्रेस करें, विशेषकर जो सर्वर या यूज़र इनपुट पर निर्भर हों।
requireLazy जैसे deferred execution patterns को चिह्नित करें जब भी वे अज्ञात या संदिग्ध स्रोतों से जुड़ें हों।

निष्कर्ष

यह केस स्टडी दिखाती है कि कैसे एन्कोडेड या जटिल JavaScript कोड, भले ही वैध प्रतीत हो, सुरक्षा विश्लेषण में विशेष ध्यान देने योग्य होता है। ऐसे स्क्रिप्ट्स को अगर spoofed वातावरण में उपयोग किया जाए, तो यह डेटा चोरी, ट्रैकिंग, या अन्य हमलों का माध्यम बन सकते हैं।

इसलिए सुरक्षा ऑडिट में ऐसे कोड्स का विश्लेषण करना अनिवार्य है।

क्या आप इस लेख को PDF या Markdown फ़ॉर्मेट में डाउनलोड करने योग्य बनाना चाहेंगे?

Search This Blog

Sameer Naik