A security research article led me down a rabbit hole: How can making a web server run out of memory possibly allow someone to execute code on it?

I understood that servers have RAM and applications can crash. What I didn’t understand was the connection between an ordinary out-of-memory error and remote code execution (RCE). So I started at the beginning. I ran a few harmless PHP snippets in a browser-based sandbox, observed memory usage, simulated interrupted operations, and then mapped those concepts back to the PHP2Shell research. Later, a security advisory circulated at work and made the topic feel much less theoretical.

This post is a learning case study, not an original vulnerability discovery or penetration test. I did not attempt the PHP2Shell exploit or probe any employer or third-party infrastructure. The shopping scenario below is fictional, and the PHP sandbox experiments demonstrate concepts rather than the vulnerabilities themselves.

First question: What actually happens when I visit a PHP website?

Imagine buying a T-shirt from a fictional online clothing store that uses PHP on the backend. Starting from the moment I open my laptop:

1. Open the laptop and browser. That alone doesn’t necessarily contact the store.
2. Enter the store’s URL. The browser sends an HTTP GET request for the homepage. The returned HTML may cause additional requests for images, CSS, fonts, JavaScript and APIs.
3. Open a product page. This may generate another GET request.
4. Select a size. This might happen entirely in JavaScript or trigger an API request to check inventory.
5. Add the product to cart. The browser might send a POST request containing the product ID, size and quantity.
6. Open checkout. Another request may fetch a checkout view.
7. Place the order. A POST request typically submits the order; the backend validates it, works with storage and may contact a payment processor.
8. See confirmation. The response may render confirmation directly or redirect the browser to another page.

Not every click or keystroke makes an HTTP request. Some interactions are entirely local to the browser. A real website may also issue many more background requests than this simple walkthrough.

Where does PHP run? On the company’s server, VM or container — not in the shopper’s browser. PHP executes the server-side application logic and can generate HTML or JSON. The browser renders HTML, runs JavaScript, and uses my laptop’s RAM. The PHP worker separately uses the server’s RAM. HTML does not execute PHP.

If the customer submits name=Sam, PHP might read that data via $_POST['name']. PHP variables use memory, and PHP arrays use internal hash-table structures. But not every variable is a hash-table entry, and a customer's purchase record is not the same thing as PHP's temporary internal memory entry.

The sandbox: I wanted to see PHP use memory

I used an online PHP sandbox because I wasn’t going to install tools or run security experiments on a company-managed laptop.

First, I generated a webpage:

<?php
$name = "Sam";
echo "<h1>Welcome, $name!</h1>";
?>

That established the basic boundary: PHP generates output on the server; the browser displays it.

Next, I measured memory while creating arrays:

<?php
$before = memory_get_usage();
$numbers = range(1, 10000);
$after = memory_get_usage();
echo "Extra memory: " . round(($after - $before) / 1024) . " KB";
unset($numbers);
?>

Here are the real measurements I observed in my sandbox:

ExperimentBeforeAfterAfter unset()10,000 numbers393 KB653 KB393 KB20,000 numbers393 KB909 KB393 KB

The larger array used more memory. The unset() released the reference to the array; the reported usage returned to the starting value in this run. This did not mean all process memory was returned to the operating system. PHP's memory allocator can retain memory for reuse.

I then checked the sandbox configuration with ini_get('memory_limit'): 32 MB. That was a limit inside the remote sandbox's PHP environment, not on my laptop.

“If I set a 1 MB limit, why did it reach 1,422 KB?”

This was my first big misunderstanding. I created a variable called $practiceLimit and checked it after every array allocation. That did not change PHP’s actual 32 MB limit.

$practiceLimit = 1024 * 1024; // just our threshold
$numbers = range(1, $i);    // allocate first
$memory = memory_get_usage(); // measure second
if ($memory >= $practiceLimit) {
    break;                   // stop third
}

My output climbed to 1,422 KB at 35,000 numbers; the sandbox also reported a 1,938 KB peak during the run. Why did it exceed 1,024 KB? Because the program checked after allocating. It then stopped by running break.

No genuine out-of-memory fatal error occurred in this experiment. Our program stopped voluntarily; PHP’s real configured limit remained 32 MB.

This matters because a code-level threshold check and PHP’s runtime-enforced memory limit are two different things.

What if PHP is interrupted halfway through a task?

Next, I used a handled exception, not a genuine memory failure:

$record = ["status" => "in_progress"];
try {
    throw new Exception("Interrupted!");
    $record["status"] = "complete";
} catch (Exception $e) {
    echo $record["status"]; // in_progress
} finally {
    unset($record);
}

The record never became complete because the exception interrupted the normal path. The finally block still cleaned up our variable. In a second experiment I intentionally omitted unset() and observed that the variable remained available to later code within that same execution. It was not proof of a memory leak or of data surviving into another web request.

We also simulated an unfinished $1,000 order. One branch of our toy code printed a payment message without checking order status; the other blocked processing because the order wasn’t complete. No payment was actually made. That was a demonstration of an application logic mistake, not the underlying PHP2Shell bug.

A critical caution: A catchable PHP exception is not the same as an out-of-memory fatal bailout inside the PHP interpreter. The experiments helped me think about interrupted work, but the real vulnerability lives inside PHP’s engine.

Where PHP2Shell actually enters the picture

The October 2026 research from Calif, with OpenAI and Wiz, describes two distinct core PHP vulnerabilities:

• CVE-2026–109618: Memory exhaustion can interrupt internal request-data creation after PHP has counted an entry but before the entry is fully initialized.
• CVE-2026–109619: Request-owned internal state can continue pointing at memory that has already been freed, enabling unsafe use by later operations or requests.

The PHP project rated both issues critical, and issued fixed releases on October 21, 2026. The researchers demonstrated unauthenticated RCE in affected configurations. Exploitability depends on the PHP runtime and deployment path; this does not mean every PHP application was compromised.

Vulnerability one: “Count Jake before creating Jake”

My easiest mental model was a fictional list of customers: Sam, Alex and Jake. But the actual records aren’t people or orders — they are internal PHP hash-table entries called buckets.

Imagine an internal table with two valid buckets. PHP begins adding a third:

1. It increments counters indicating that the third slot is in use.
2. It tries to allocate the memory needed to finish that bucket’s key and value.
3. The allocation fails at the memory limit, and the operation is interrupted.
4. Cleanup later sees the incremented count and tries to process the unfinished third slot as if it were a valid bucket.

This is not PHP thinking “Jake is a real customer.” It is PHP’s native cleanup code interpreting uninitialized or stale bytes as legitimate internal type information or pointers. An invalid pointer could crash the process; with sufficient attacker control over the memory layout, researchers demonstrated paths toward RCE.

For some affected Apache mod_php setups, this could be triggered while PHP parsed the incoming HTTP request — before the application’s PHP script had run. In the specific early-startup path described by the researchers, PHP-FPM could instead exit its worker, which is why the server execution model matters.

Vulnerability two: “The paper was thrown away, but the address was kept”

This one answered my repeated question: Does the broken information get carried to the next page refresh?

In some vulnerable paths, request-specific memory was freed, but PHP worker state still contained a reference to it. If the same worker processed a subsequent request before that state had been correctly reset, PHP could follow the invalid reference. That is a use-after-free, also called a dangling-pointer problem.

A refresh could create another HTTP request, but it is not inherently the trigger; a different visitor’s request could also be the next one handled by that worker. The broken customer order is not copied into the next order. The issue is retained interpreter state, not persistent shopping-cart data.

Why would an attacker do this? How does an error turn into RCE?

The researchers investigated specially structured HTTP form and upload input that could make PHP allocate far more internal memory than the incoming request’s size suggests. They didn’t need visitors to type PHP source code into a website. The request parser itself could build large nested data structures.

However, forcing a fatal error is only stage one. Usually a crash is just a crash.

A possible exploitation chain is:

1. Trigger a vulnerable interruption.
2. Cause PHP to process a partially initialized bucket or stale memory reference.
3. Influence the memory contents PHP sees when it follows that invalid state.
4. Turn the resulting unsafe read/write or object handling into control over program execution.
5. Execute attacker-chosen behavior in the context of the PHP worker, if the exploit succeeds.

That final step is remote code execution (RCE). RCE is not automatically root access. It initially provides the privileges of the compromised PHP/web-server process, and further access depends on system permissions and other weaknesses.

How did the researchers discover the issue?

The discovery had a history. Calif’s write-up traces its motivation through a 2004 PHP memory-limit RCE associated with Stefan Esser, a 2020 bug report about out-of-memory failures and temporary-file cleanup, and a 2024 OSTIF/Quarkslab audit that identified related behavior without proving exploitation.

In 2026, researchers revisited the hypothesis with AI-assisted source-code review. They looked at how PHP’s memory allocator, fatal-error handling, and request shutdown interact. One especially revealing code sequence incremented a hash-table entry count before an allocation that could fail. From there, they investigated additional “publish state → perform fallible work → skip cleanup/rollback” patterns, including session and deserialization paths.

According to the original timeline, initial discoveries were made in August 2026, the first issue was reported to PHP on August 11, a working RCE proof of concept was confirmed by PHP on August 15, the second issue was reported on August 21, and fixes were released on October 21.

I found the research approach more interesting than a generic “AI found a bug” headline: historical domain knowledge shaped the question; AI assisted the investigation; researchers validated the actual exploit and coordinated disclosure.

How did PHP patch it?

The fix was not simply “kill the server whenever something goes wrong.” That was one of my questions too.

In the patched versions, PHP’s configured memory_limit becomes a soft limit for many allocations: an allocation may complete so that internal state is left consistent, and PHP raises the fatal error later at a safer execution point. A separate hard limit bounds how far memory may grow; if it would be exceeded, the process is terminated immediately rather than running potentially unsafe cleanup.

A request can still fail. The security improvement is that failure should not provide the original memory-corruption path. The release also addresses the stale-state vulnerability.

Fixed upstream releases issued October 21, 2026:

PHP branchFixed release8.28.2.358.38.3.368.48.4.278.58.5.12

An additional nuance for readers following the story in real time: on October 23, 2026, PHP published a separate informational advisory about a rare session-upload-progress configuration and recommended disabling that feature temporarily in affected setups. That follow-up should not be conflated with the two CVEs discussed here; it is another reason to check current vendor advisories rather than treat a version number as the end of a security review.

PHP 8.1 and earlier are end-of-life upstream. Enterprise Linux and long-term-support vendors may backport security fixes, so administrators must check their distributor’s advisories rather than conclude that an older version string necessarily means unpatched.

Did patching RCE eliminate DoS and DDoS?

No — and it doesn’t have to for the RCE patch to be real. This was another question I had.

Memory-intensive or high-volume requests can still create availability problems if enough workers, CPU time, RAM or connections are exhausted. A DoS is a loss of service availability; DDoS involves distributed attack sources. One expensive request might fail in isolation, while many expensive requests could degrade a service.

Defense in depth includes vendor patching, reverse-proxy request limits, rate limiting, limits on input nesting and count, PHP worker limits, resource isolation, monitoring and capacity planning. A small request body may expand into a much larger in-memory representation, so capping only raw HTTP body size is not enough.

Importantly, temporarily removing PHP’s memory limit was documented as a partial pre-patch mitigation for one attack path, not as a safe universal anti-DoS recommendation; it can increase resource-exhaustion risk. The supported fix is patching.

Where do organizations patch PHP — and can an ordinary user check?

On the servers or containers where PHP runs, not on a customer’s browser. An authorized administrator may inspect a PHP CLI version with php -v, but a web server can run a different PHP version; package provenance and backported vendor fixes also matter.

A browser user cannot reliably verify a remote website’s PHP patch level. Some sites reveal a version header, but that can be absent, outdated or insufficient. Real confirmation comes from the system owner: their inventory, package advisories, deployment records and verification.

A related question came up when I saw an advisory circulated to service providers at work. Why did I receive a PHP warning if PHP is server-side? Because provider organizations may manage their own web applications and infrastructure. The advisory asked their IT teams to check affected installations. Receiving that message does not prove the sender’s platform or my employer was vulnerable or compromised.

The questions that changed my understanding

Does HTML execute PHP? No. PHP runs on the backend and may generate HTML; the browser renders it.

Does PHP use my laptop’s RAM? Server-side PHP uses server RAM. The browser uses my device RAM for its own work.

Did my 1 MB sandbox experiment produce a real PHP fatal error? No. I set an artificial threshold and stopped the loop myself.

Was an unfinished purchase treated as another customer? No. The real bug involved PHP-internal hash-table buckets, not a database of orders.

Was cleanup skipped, or did it actually happen? Both patterns appeared in different bugs: unsafe cleanup of a partial bucket in one, and skipped state reset / dangling references in another.

Does a later HTTP request always inherit the previous request’s memory? No. The cross-request issue required vulnerable worker state surviving in the same process.

Does invalid memory automatically grant RCE? No. Exploitation requires additional control; many invalid accesses simply crash.

Will an attacker see the fatal error in their browser? The failure occurs on the server. The browser might receive an HTTP error or a dropped connection.

Can a patched server still suffer DoS? Yes. Preventing the particular RCE and preventing resource exhaustion are different security objectives.

Can I tell from a website visit whether PHP is patched? Not reliably; confirmation generally requires authorized server-side evidence.

My takeaway

The bug wasn’t simply “PHP ran out of RAM.” It was what PHP believed about its own state after an error. Counting an entry before finishing it, or keeping a pointer after freeing its target, can turn ordinary error handling into a security boundary failure.

The most useful lesson I took from this case is about failure paths: safe software needs correct behavior not only when requests succeed, but also when allocations, initialization, callbacks and cleanup fail halfway through.

And for defenders, the practical conclusion is clear: patch the affected PHP runtime, verify the deployed web-facing version, and separately maintain resource-exhaustion protections.

Sources and attribution

• Original research and technical discovery: Calif — PHP2Shell: A tale of two PHP remote vulnerabilities (research by Ryan Austin, with OpenAI and Wiz referenced by the project).
• Official PHP security advisory and October 21, 2026 release information.
• Official PHP manual: memory_limit and memory_hard_limit_percent.
• PHP October 23, 2026 informational advisory about session upload progress.

Diagrams are original educational illustrations. They simplify implementation details; consult the original research for the actual source-code paths. No live systems were tested for this article.

PHP2Shell Explained: How a PHP Memory Error Became Remote Code Execution was originally published in System Weakness on Medium, where people are continuing the conversation by highlighting and responding to this story.

How to identify and respond to AMSI evasion techniques in production environments

Executive Summary

In my previous article, I explored AMSI bypass techniques from an offensive perspective. Now, let’s flip the script. As defenders, understanding these bypasses isn’t enough — we need actionable detection strategies.

This article presents production-ready detection methods for AMSI tampering, complete with:

• PowerShell logging configurations
• Event correlation patterns
• YARA rules for memory scanning
• Sysmon detection logic
• Real-world response workflows

Target Audience: SOC analysts, threat hunters, security engineers, and anyone responsible for endpoint security.

Understanding the Threat Landscape

Common AMSI Bypass Categories

1. Memory Patching — Modifying amsi.dll in process memory
2. API Hooking — Redirecting AMSI function calls
3. Context Manipulation — Corrupting AMSI scan buffers
4. Force Failures — Making AMSI always return “clean”

Real-World Impact

• 95% of PowerShell-based attacks attempt AMSI bypass
• Median dwell time reduced from 24 hours to 4 hours when AMSI is functional
• Detection gap: Most organizations log AMSI events but don’t act on anomalies

Detection Strategy 1: PowerShell Script Block Logging

Configuration

Enable aggressive PowerShell logging via GPO:

# Enable Script Block Logging
Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" `
    -Name "EnableScriptBlockLogging" -Value 1

# Enable Module Logging
Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ModuleLogging" `
    -Name "EnableModuleLogging" -Value 1

# Enable Transcription
Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\Transcription" `
    -Name "EnableTranscripting" -Value 1
Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\Transcription" `
    -Name "OutputDirectory" -Value "C:\PSTranscripts"

Detection Patterns

Event ID 4104 indicators:

Suspicious strings in ScriptBlock:
- [Ref].Assembly.GetType
- System.Management.Automation.AmsiUtils
- amsiInitFailed
- [Runtime.InteropServices.Marshal]::Copy
- 0x5f,0x52,0x54 (XOR'd "amsi")
- VirtualProtect
- WriteProcessMemory

Splunk Detection Query

index=windows EventCode=4104
| regex ScriptBlockText="(?i)(amsi|System\.Management\.Automation\.AmsiUtils|amsiInitFailed|0x5f.*0x52.*0x54)"
| eval severity=case(
    match(ScriptBlockText, "(?i)amsiInitFailed"), "CRITICAL",
    match(ScriptBlockText, "(?i)VirtualProtect.*amsi"), "CRITICAL",
    match(ScriptBlockText, "(?i)System\.Management\.Automation\.AmsiUtils"), "HIGH",
    1=1, "MEDIUM"
  )
| stats count by Computer, User, severity, ScriptBlockText
| where count > 0

Detection Strategy 2: Sysmon Configuration

Critical Event IDs

Event IDDescriptionAMSI Bypass Indicator7Image Loadedamsi.dll loaded by unusual processes10Process AccessMemory reads targeting PowerShell/CLR8CreateRemoteThreadInjection into PowerShell process1Process CreateSuspicious PowerShell invocation patterns

Sysmon Rule Configuration

<Sysmon schemaversion="4.82">
  <EventFiltering>
    <!-- Detect AMSI.dll memory tampering -->
    <ProcessAccess onmatch="include">
      <TargetImage condition="end with">powershell.exe</TargetImage>
      <TargetImage condition="end with">powershell_ise.exe</TargetImage>
      <GrantedAccess condition="is">0x1F3FFF</GrantedAccess>
    </ProcessAccess>
    
    <!-- Detect reflection-based AMSI bypass -->
    <ImageLoad onmatch="include">
      <Image condition="end with">powershell.exe</Image>
      <ImageLoaded condition="contains">amsi.dll</ImageLoaded>
    </ImageLoad>
    
    <!-- Detect suspicious PowerShell execution -->
    <ProcessCreate onmatch="include">
      <CommandLine condition="contains all">-enc;-nop;-w hidden</CommandLine>
      <CommandLine condition="contains">amsi</CommandLine>
    </ProcessCreate>
  </EventFiltering>
</Sysmon>

Correlation Rule

# Pseudocode for SIEM correlation
def detect_amsi_bypass_chain(events):
    """
    Correlate multiple events within 60-second window
    """
    window = 60  # seconds
    
    # Stage 1: PowerShell process creation
    ps_create = events.filter(EventID=1, Image="powershell.exe")
    
    # Stage 2: AMSI.dll load
    amsi_load = events.filter(EventID=7, ImageLoaded="amsi.dll")
    
    # Stage 3: Memory tampering
    memory_access = events.filter(EventID=10, GrantedAccess="0x1F3FFF")
    
    # Stage 4: Script block with bypass
    script_block = events.filter(EventID=4104, ScriptBlock~="amsi")
    
    if all_within_window([ps_create, amsi_load, memory_access, script_block], window):
        return ALERT(severity="CRITICAL", technique="AMSI Bypass Chain")

Detection Strategy 3: Memory Analysis with YARA

YARA Rule for In-Memory Detection

rule AMSI_Bypass_Memory_Patch
{
    meta:
        description = "Detects AMSI bypass via memory patching"
        author = "Your Name"
        date = "2026-10-15"
        severity = "high"
        
    strings:
        // Common AMSI bypass strings
        $amsi1 = "amsiInitFailed" ascii wide
        $amsi2 = "AmsiScanBuffer" ascii wide
        $amsi3 = { 57 00 69 00 6E 00 33 00 32 00 5F 00 41 00 6D 00 73 00 69 }  // Win32_Amsi (wide)
        
        // Memory patch patterns
        $patch1 = { B8 57 00 07 80 C3 }  // mov eax, 0x80070057; ret (E_INVALIDARG)
        $patch2 = { 31 C0 C3 }  // xor eax, eax; ret
        $patch3 = { B8 01 00 00 00 C3 }  // mov eax, 1; ret (AMSI_RESULT_CLEAN)
        
        // VirtualProtect + AMSI
        $combo1 = { 56 69 72 74 75 61 6C 50 72 6F 74 65 63 74 }  // VirtualProtect
        
    condition:
        uint16(0) == 0x5A4D and  // MZ header
        (
            (2 of ($amsi*) and 1 of ($patch*)) or
            ($combo1 and 1 of ($amsi*))
        )
}

rule AMSI_Context_Bypass
{
    meta:
        description = "Detects AMSI context manipulation"
        
    strings:
        $ctx1 = "amsiContext" ascii wide nocase
        $ctx2 = "amsiSession" ascii wide nocase
        $ctx3 = { 00 00 00 00 00 00 00 00 00 00 00 00 }  // Null buffer
        $reflection = "[Ref].Assembly.GetType" ascii wide
        
    condition:
        2 of them
}

Scanning PowerShell Process Memory

# Scan running PowerShell processes with YARA
function Scan-AMSIBypass {
    $yaraPath = "C:\Tools\yara64.exe"
    $rulesPath = "C:\Rules\amsi_bypass.yar"
    
    Get-Process powershell* | ForEach-Object {
        $pid = $_.Id
        Write-Host "[*] Scanning PID $pid"
        
        & $yaraPath $rulesPath $pid | Out-File "C:\Scans\amsi_scan_$pid.txt"
        
        if ($LASTEXITCODE -eq 0) {
            Write-Warning "[!] AMSI bypass detected in PID $pid"
            # Trigger incident response
            Invoke-IncidentResponse -PID $pid -Type "AMSI_BYPASS"
        }
    }
}

Detection Strategy 4: EDR Behavioral Analytics

Behavioral Indicators

{
  "detection_rule": "AMSI Bypass Behavior Chain",
  "severity": "high",
  "conditions": [
    {
      "event": "process_create",
      "image": "powershell.exe",
      "command_line_contains": ["-enc", "-nop", "-w hidden"]
    },
    {
      "event": "module_load",
      "module": "amsi.dll",
      "followed_by": "memory_protect_change"
    },
    {
      "event": "api_call",
      "api": "VirtualProtect",
      "target_module": "amsi.dll",
      "protection": "PAGE_EXECUTE_READWRITE"
    },
    {
      "event": "registry_read",
      "key": "HKLM\\SOFTWARE\\Microsoft\\AMSI\\Providers"
    }
  ],
  "time_window_seconds": 10,
  "action": "alert_and_suspend_process"
}

Detection Strategy 5: Network-Based Detection

C2 Beaconing Post-AMSI Bypass

# Detect suspicious outbound connections after AMSI bypass
def detect_post_bypass_c2(flow_data):
    """
    Network indicators following AMSI bypass
    """
    indicators = {
        'high_frequency_dns': flow_data.dns_queries > 100 / minute,
        'uncommon_ports': flow_data.dst_port in [8080, 4444, 443, 53],
        'base64_in_headers': re.search(r'[A-Za-z0-9+/]{50,}', flow_data.http_headers),
        'dns_tunneling': len(flow_data.dns_query) > 63,
        'jarm_fingerprint': flow_data.jarm in KNOWN_C2_JARMS
    }
    
    if sum(indicators.values()) >= 3:
        return ALERT("Potential C2 after AMSI bypass")

Incident Response Workflow

Phase 1: Detection & Triage (0–5 minutes)

1. Alert fires from SIEM/EDR
2. Verify: Check Event ID 4104 + Sysmon Event 10
3. Classify: AMSI bypass confirmed?
   ├─ YES → Proceed to Phase 2
   └─ NO → False positive, tune detection

Phase 2: Containment (5–15 minutes)

# Automated containment script
$targetPID = 1234  # From alert

# 1. Suspend process
Suspend-Process -Id $targetPID

# 2. Capture memory dump
procdump64.exe -ma $targetPID "C:\IR\memory_$targetPID.dmp"

# 3. Network isolation
New-NetFirewallRule -DisplayName "Block-PID-$targetPID" `
    -Direction Outbound -Action Block -Program "C:\Path\To\Process.exe"

# 4. Kill process
Stop-Process -Id $targetPID -Force

Phase 3: Investigation (15–60 minutes)

# Analyze memory dump
volatility3 -f memory_1234.dmp windows.malfind
volatility3 -f memory_1234.dmp windows.cmdline
volatility3 -f memory_1234.dmp windows.netscan

# Extract PowerShell history
volatility3 -f memory_1234.dmp windows.pstree

Phase 4: Remediation

1. Validate AMSI health: Re-enable and test
2. Hunt for persistence: Scheduled tasks, registry autoruns
3. Threat intelligence: IOC extraction and sharing
4. Patch gaps: Update detection rules

Key Performance Indicators (KPIs)

Measuring Detection Effectiveness

# Detection effectiveness metrics
metrics = {
    'Mean Time To Detect (MTTD)': '< 5 minutes',
    'Mean Time To Respond (MTTR)': '< 15 minutes',
    'False Positive Rate': '< 5%',
    'Coverage': '100% of known AMSI bypass techniques',
    'Detection Rate': '> 95% in lab environment'
}

Testing Your Detections

# Safe AMSI bypass test (in isolated lab)
[Ref].Assembly.GetType('System.Management.Automation.AmsiUtils').GetField('amsiInitFailed','NonPublic,Static').SetValue($null,$true)

# Expected detections:
# - Event ID 4104 with "amsiInitFailed"
# - Sysmon Event 10 (ProcessAccess)
# - EDR alert for reflection abuse

Advanced: Machine Learning-Based Detection

Feature Engineering

import pandas as pd
from sklearn.ensemble import RandomForestClassifier

# Feature extraction from PowerShell logs
features = {
    'script_length': len(script),
    'base64_ratio': count_base64(script) / len(script),
    'obfuscation_entropy': calculate_entropy(script),
    'reflection_count': script.count('[Ref]'),
    'amsi_string_count': script.lower().count('amsi'),
    'virtualprotect_present': 'virtualprotect' in script.lower(),
    'marshal_copy_present': 'marshal' in script.lower() and 'copy' in script.lower(),
    'bypass_pattern_score': calculate_bypass_score(script)
}

# Train model on labeled dataset
model = RandomForestClassifier(n_estimators=100)
model.fit(X_train, y_train)

# Predict AMSI bypass attempts
prediction = model.predict([features])
confidence = model.predict_proba([features])[0][1]

if prediction == 1 and confidence > 0.85:
    trigger_alert("ML-Detected AMSI Bypass", confidence)

Real-World Case Study

Incident: Ransomware with AMSI Bypass

Timeline:

• T+0m: PowerShell execution with base64-encoded payload
• T+2m: AMSI bypass via memory patching
• T+5m: Credential dumping (Mimikatz)
• T+10m: Lateral movement initiated
• T+15m: DETECTION via correlated Sysmon events
• T+18m: Containment and process termination

Lessons Learned:

1. Script Block Logging saved us — captured the full attack chain
2. Correlation was key — single events would’ve been noise
3. Response playbook reduced MTTR from 2 hours to 18 minutes

Detection Logic That Worked:

IF (EventID=4104 AND ScriptBlock CONTAINS "amsiInitFailed")
AND (EventID=10 AND TargetImage="powershell.exe" WITHIN 60s)
AND (EventID=1 AND CommandLine CONTAINS "mimikatz" WITHIN 120s)
THEN ALERT(severity=CRITICAL, technique="Ransomware with AMSI Bypass")

Defensive Recommendations

Short-Term (0–30 days)

• ✅ Enable PowerShell Script Block Logging
• ✅ Deploy Sysmon with AMSI-focused config
• ✅ Create SIEM correlation rules
• ✅ Test detections with safe bypass samples

Medium-Term (30–90 days)

• ✅ Implement YARA memory scanning
• ✅ Deploy EDR behavioral rules
• ✅ Build incident response runbooks
• ✅ Conduct purple team exercises

Long-Term (90+ days)

• ✅ Machine learning model deployment
• ✅ Threat hunting program
• ✅ Automated response orchestration (SOAR)
• ✅ Continuous rule optimization

Conclusion

AMSI bypass detection isn’t about a single silver bullet — it’s about defense in depth:

1. Logging captures the evidence
2. Correlation connects the dots
3. Automation ensures speed
4. Human analysis validates and improves

Key Takeaway: Every offensive technique has a defensive counter. The question isn’t if you’ll be targeted, but how quickly you’ll detect it.

Resources

• Microsoft AMSI Documentation
• Sysmon Configuration Examples
• SIGMA Rules for AMSI Bypass
• My Previous Article: AMSI Bypass Techniques

About the Author

Security researcher focusing on adversary simulation and detection engineering. Writing about both offensive techniques and their defensive countermeasures.

Next Article: ETW for Threat Detection: The Ultimate Windows Telemetry Deep Dive

Follow for more blue team content. Questions? Drop them in the comments.

Tags: #BlueTeam #ThreatDetection #AMSI #PowerShell #SOC #ThreatHunting #SecurityEngineering #EDR

Detecting AMSI Bypass Attempts: A Blue Team Guide was originally published in System Weakness on Medium, where people are continuing the conversation by highlighting and responding to this story.

Greetings, everyone!

Today, we’re going to discuss three important terms in cybersecurity: Threat, Vulnerability, and Risk.

If you’re new to cybersecurity, you’ve probably come across these terms while studying security concepts, reading vulnerability reports, or learning about risk assessments.

At first, they might sound almost the same. But they actually describe different parts of a security problem.

For example, imagine an online store that has an admin account without multi-factor authentication (MFA).

Would we call this a threat, a vulnerability, or a risk?

Interesting question, right?

To understand the difference, let’s take a simple example and explore how these three terms work together.

Meet BrightCart, Our Example Company

Imagine a small online shopping company called BrightCart.

BrightCart sells products online and uses an admin dashboard to manage daily business activities.

Through this dashboard, employees can:

• View and manage customer orders.
• Access customer information.
• Update product details.
• Manage important store settings.

Now think about what would happen if someone gained unauthorized access to this dashboard.

They might be able to view customer information, change orders, or interfere with normal business operations.

This is why the dashboard and the information it provides access to are important to BrightCart.

In cybersecurity, we call valuable things that need protection assets.

An asset doesn’t always have to be a physical device like a laptop or server. Customer data, business applications, user accounts, and important services can also be assets.

For our example, we’ll focus on BrightCart’s admin dashboard and the customer information it provides access to.

1. What Is a Threat?

Let’s imagine that an attacker has obtained the password of one of BrightCart’s admin accounts.

The attacker now attempts to use that password to log in to the admin dashboard.

This situation introduces our first term: Threat.

A threat is something that has the potential to cause harm to a system, organization, or its information.

In this example:

• Threat actor: The attacker trying to access the dashboard.
• Threat event: The attempted unauthorized login using a stolen password.

Notice one important thing here.

We are not saying that the attacker has successfully logged in or that any customer information has been stolen.

We are only identifying an event that could potentially cause harm.

Also, threats don’t always involve hackers.

A fire in a server room, an accidental deletion of important files, or an unexpected system outage can also threaten an organization’s operations.

So whenever you’re trying to identify a threat, ask yourself:

What could happen that might harm this system or business?

2. What Is a Vulnerability?

Now let’s move a little further into our BrightCart example.

Suppose we discover that the admin dashboard only requires a username and password to log in.

There is no multi-factor authentication (MFA) enabled.

This means that if someone obtains a valid admin password, there may be no additional verification step to stop them from accessing the account.

Here, the missing MFA protection is our vulnerability.

A vulnerability is a weakness in a system, configuration, process, or security control that could be exploited by a threat.

Vulnerabilities aren’t always programming bugs.

For example:

• An admin account without MFA.
• Weak or reused passwords.
• Incorrectly configured access permissions.
• Old employee accounts that still have access.
• Software that hasn’t received important security updates.

All these situations can introduce weaknesses that make a system easier to compromise.

Coming back to BrightCart, the attacker with a stolen password represents our threat scenario, while the lack of MFA represents the weakness that could make unauthorized access possible.

But remember, identifying a vulnerability doesn’t automatically mean someone has already exploited it.

This brings us to the next term.

3. What Is Risk?

So far, we have identified two things:

An attacker may attempt to use a stolen password, and BrightCart’s admin account doesn’t have MFA enabled.

Now, what happens if the attacker successfully logs in?

They might access customer information, modify orders, or disrupt the store’s normal operations.

This possible harmful outcome is what we need to consider when discussing risk.

In simple terms, cybersecurity risk is about what could go wrong, how likely it is to happen, and how much harm it could cause.

Let’s write a risk statement for BrightCart:

An attacker using a stolen admin password could gain unauthorized access to BrightCart’s dashboard because MFA is not enabled, potentially exposing customer information or disrupting order processing.

See how this statement connects everything?

We have identified the possible attack, the weakness that makes it possible, and the consequences for the business.

That’s much more useful than simply writing, “The company has a hacking risk.”

How Do We Know Whether a Risk Is High or Low?

This is where two more terms become important: Likelihood and Impact.

Likelihood helps us understand how likely a harmful event or outcome is, while impact describes how serious the consequences could be.

For BrightCart, we would need to ask a few questions.

Is the admin dashboard accessible from the internet?

Have there been any suspicious login attempts?

What information can the admin account access?

Are there other security controls already protecting the account?

And how badly could the business be affected if customer information was exposed or orders were changed?

The answers help us assess the risk.

We shouldn’t immediately label the risk as “High” just because MFA is missing. We need to understand the situation and the existing controls first.

4. Let’s Compare All Three Terms

Now that we’ve explored the example, let’s put everything together

Here’s a simple way to remember the difference.

Threat: What could cause harm?

Vulnerability: What weakness could allow it?

Risk: What could go wrong, how likely is it, and how serious could the consequences be?

Once you understand these three questions, identifying security risks becomes much easier.

5. What Happens If BrightCart Enables MFA?

Now suppose BrightCart decides to improve its admin account security.

The company enables multi-factor authentication for its admin users.

Previously, the account only required a password. Now, logging in also requires an additional authentication factor.

This makes it more difficult for an attacker to access the account using only a stolen password.

However, enabling MFA doesn’t mean the company can forget about account security completely.

BrightCart still needs to make sure MFA is enabled for all relevant admin accounts, account recovery is secure, and the chosen authentication method is effective.

Other threats may still exist.

The important point is that a security control helps reduce risk, but the remaining risk still needs to be understood and managed.

6. Let’s Try One More Example

Before we finish, let’s apply the same idea to something we use almost every day: an email account.

Imagine an email account protected by a weak password.

An attacker might try to guess that password or use credentials obtained from another data breach.

Now let’s identify the terms.

Asset: Email account and the information stored inside it.

Threat: Someone attempting unauthorized access.

Vulnerability: Weak or reused password.

Risk: The possibility of an attacker gaining access and exposing private emails or misusing the account.

Simple, right?

You can use the same approach for a university portal, business application, personal website, or any other system.

Start by identifying what you’re protecting, what could cause harm, which weaknesses exist, and what the consequences might be.

Final Thoughts

So, that’s how threats, vulnerabilities, and risks are connected.

A threat describes a potential source or event of harm. A vulnerability is a weakness that could be exploited. Risk helps us understand the possibility and consequences of something going wrong.

The BrightCart example shows why these terms shouldn’t be used interchangeably.

When we identify a security problem, we need to understand more than just the weakness. We also need to consider the possible threat, business impact, and controls already in place.

That’s where cybersecurity risk analysis begins.

In the next article, we’ll take this example one step further and explore how to start a cybersecurity risk assessment.

Until then, keep learning and exploring cybersecurity!

Cybersecurity Risk Register & Dashboard

If you’re learning cybersecurity risk analysis and want a structured way to practice recording risks, I’ve also created a Cybersecurity Risk Register & Dashboard.

It provides a place to document identified risks, assess likelihood and impact, assign risk owners, and track response actions.

References

• NIST SP 800–30 Rev. 1 — Guide for Conducting Risk Assessments
• NIST Computer Security Resource Center — Vulnerability and Likelihood Definitions
• CISA — Implementing Phishing-Resistant Multifactor Authentication

Threat, Vulnerability, and Risk: Understanding the Difference with a Real-World Example was originally published in System Weakness on Medium, where people are continuing the conversation by highlighting and responding to this story.

What a finance worker in Hong Kong can teach every small business owner about the scam nobody’s checklist covers yet

In February 2024, a finance employee at the engineering firm Arup got a message that looked like it came from the company’s UK-based CFO. It asked for a confidential transaction. Understandably cautious, the employee hesitated — until they were invited onto a video call.

On that call: the CFO. And several other colleagues they recognized. Talking, moving, sounding exactly like themselves.

Every person on that call was a deepfake. The employee ended up authorizing 15 transfers totaling $25.6 million before anyone realized what had happened.

I think about this case a lot, because it’s usually told as a story about a giant multinational firm getting outsmarted by cutting-edge AI. What gets lost is the more uncomfortable version of the story: the attack didn’t work because Arup lacked resources. It worked because it exploited something every business has, regardless of size — a human being trained to trust what looks and sounds like their boss.

And if it worked on a company with an actual security team, it’s not exactly reassuring for the rest of us running things without one.

This isn’t a “big company” problem anymore

Here’s what’s changed in the last two years: making a convincing fake voice or video used to require real technical skill. Now it doesn’t. The tools got good, and they got easy, and they got everywhere.

The numbers reflect that shift. Deepfake-related fraud attempts have risen more than 2,000% over the past three years, according to identity verification firm Sumsub — going from a rounding error to roughly 1 in 15 fraud attempts overall. Separately, Pindrop’s analysis of contact center calls found deepfake fraud attempts jumped over 1,300% in a single year, moving from about one incident a month to roughly seven a day.

Most striking to me: research from Keepnet found that 80% of companies have no plan at all for what to do if a deepfake attack happens to them. Not a weak plan. No plan.

That gap isn’t because business owners don’t care about security. It’s because almost every piece of security advice out there was written for a different threat. Ransomware. Weak passwords. Suspicious attachments. All still real, all still worth defending against — but none of it prepares anyone for a scammer who sounds exactly like their business partner asking them to move money today.

Why small businesses are actually more exposed, not less

There’s a reason this keeps happening to smaller operations even though the Arup case made headlines: scale works against the small business owner here, not for them.

A large company might have a dedicated finance team, a formal sign-off chain, and a policy that no wire transfer above a certain amount happens without three people involved. A small e-commerce brand, an agency, a boutique studio — usually has the owner. Maybe one other person. Decisions get made fast, because they have to.

Fast decision-making is exactly what this kind of fraud is built to exploit. The urgency, the “don’t loop anyone else in,” the sense that hesitating might damage a relationship or lose a deal — all of it hits harder when there’s no second or third person in the loop to say “wait.”

You don’t need to be targeted by a nation-state to lose money this way. You just need one moment where something felt slightly off, and you moved forward anyway because you were busy and it sounded exactly like the person you trust.

The fix isn’t more technology. It’s one habit.

Every source I read while researching this pushed some kind of detection software, AI to catch the AI. Useful, eventually, for companies with the budget and the team to run it. Not the actual answer for a small business trying to close this gap this week.

The actual answer is boring, and that’s exactly why it works: never approve a financial request based on a single channel of communication.

If a request to move money, change a payment detail, or share access arrives by video, voice note, email, or chat, verify it through a second, independent channel before acting. Call the person back on a number you already had saved, not one included in the message. If it’s urgent, that’s a reason to verify faster, not skip verification entirely.

This single habit — sometimes called a callback rule, would have stopped the Arup fraud, the wave of CEO-voice scams currently hitting small businesses (researchers estimate roughly 400 attempts a day target companies with this exact method), and most of the deepfake-driven fraud making headlines this year. It costs nothing. It takes one conversation with your team to put in place. And almost nobody has it written down anywhere.

What I’d actually do this week if I were you

You don’t need to become a security expert. You need three things in place, in this order:

1. Write the rule down. One sentence: “No payment, wire, or account change is approved without a callback to a known number.” Put it somewhere your team will actually see it.
2. Say it out loud to whoever touches money. Not as a memo nobody reads a real conversation. Make sure everyone knows they’re allowed to pause a request that feels off, even if it claims to be from you.
3. Decide what “verify” means in advance. Who do they call? What number? What happens if that person’s unreachable? Five minutes of planning now saves a very bad hour later.

That’s genuinely most of it. The rest phishing habits, backup hygiene, access reviews matters too, but none of it addresses the specific thing that’s now targeting small businesses hundreds of times a day.

How Would We Record This in a Cybersecurity Risk Register?

Now let’s look at this incident from a risk management perspective.

We’ve discussed how a convincing video call can be used to trick someone into approving a payment. But what if we want to make sure our business doesn’t overlook this kind of threat?

This is where a cybersecurity risk register becomes useful.

A risk register is a place where we document identified risks, assess their possible impact, assign responsibility, and keep track of the actions we’re taking to manage them.

For example, imagine a small online business where one employee can approve payments after receiving instructions from the owner.

What if a scammer impersonates that owner using an AI-generated voice or video?

Let’s break this down.

Asset: The company’s funds and payment approval process.

Threat: A fraudster impersonating a trusted business executive.

Vulnerability: Payment requests can be approved without independent identity verification.

Risk: An employee could approve a fraudulent transaction after receiving convincing instructions from someone pretending to be the business owner.

Potential impact: Financial loss and disruption to business operations.

Security controls: Independent callback verification, approval limits, and additional authorization for high-value payments.

Now we have something more useful than simply saying, “Deepfakes are dangerous.”

We’ve identified a specific risk, understood what could make it possible, and listed controls that could help reduce it.

The next step would be to assess the likelihood and impact, assign someone to manage the risk, and review whether the controls are actually working.

That’s the purpose of documenting risks instead of leaving them as general security concerns.

Example: A fictional deepfake payment fraud scenario recorded in a cybersecurity risk register. Scores and control decisions are illustrative.

Want to Try This Yourself?

If you’re learning cybersecurity risk assessment or want a structured way to document business security risks, my Cybersecurity Risk Register & Dashboard provides an editable Excel and Google Sheets template.

You can record identified risks, assess likelihood and impact, document existing controls, assign risk owners, and track treatment actions through the dashboard.

It also includes fictional worked examples to help you understand how the process works.

View the Cybersecurity Risk Register & Dashboard

And remember, you don’t need a complicated system to begin. Start by identifying one important business process, what could go wrong, and how you would reduce that risk.

If this was useful, I write about practical, no-jargon security for people who don’t have a security team, follow for more. (●'◡'●)

The $25 Million Video Call That Wasn’t Real was originally published in System Weakness on Medium, where people are continuing the conversation by highlighting and responding to this story.

In this room, we will learn the basics of traffic analysis with Wireshark and how to find anomalies on your network!

Link: https://tryhackme.com/room/wiresharktrafficanalysis

This is the 2nd part in a 2 part series on this room due to its length. To view the first part click here!

Let’s finish it!

Task 6: Cleartext Protocol Analysis: FTP

Investigating cleartext protocol traces sounds easy, but when the time comes to investigate a big network trace for incident analysis and response, the game changes. Proper analysis is more than following the stream and reading the cleartext data. For a security analyst, it is important to create statistics and key results from the investigation process. As mentioned earlier at the beginning of the Wireshark room series, the analyst should have the required network knowledge and tool skills to accomplish this. Let’s simulate a cleartext protocol investigation with Wireshark!

FTP Analysis

File Transfer Protocol (FTP) is designed to transfer files with ease, so it focuses on simplicity rather than security. As a result of this, using this protocol in unsecured environments could create security issues like:

• MITM attacks
• Credential stealing and unauthorised access
• Phishing
• Malware planting
• Data exfiltration

FTP analysis in a nutshell:

Detecting suspicious activities in chunked files is easy and a great way to learn how to focus on the details. Now use the exercise files to put your skills into practice against a single capture file and answer the questions below!

Answer the questions below:

Use the “Desktop/exercise-pcaps/ftp/ftp.pcap” file.
6.1 How many incorrect login attempts are there?

This one was a quick win, we know the codes from the task and we know the syntax from all three wireshark rooms we’ve been doing:

Press enter or click to view image in full size

ftp.response.code in {430 530}

Answer: 737

6.2 What is the size of the file accessed by the “ftp” account?

Per the task text, we can check file status with code 213:

Let’s do it:

ftp.response.code == 213

You’ll get 2 packets that respond to this filter, if you Right Click and follow the TCP Streams for either of those packets, you will find your answer:

Answer: 39424

6.3 The adversary uploaded a document to the FTP server. What is the filename?

We know this from the previous question, if you followed the stream:

Answer: resume.doc

6.4 The adversary tried to assign special flags to change the executing permissions of the uploaded file. What is the command used by the adversary?

We also know the answer to this one, located in the stream data, scroll down near the end:

Answer: chmod 777

Task 7: Cleartext Protocol Analysis: HTTP

Hypertext Transfer Protocol (HTTP) is a cleartext-based, request-response and client-server protocol. It is the standard type of network activity to request/serve web pages, and by default, it is not blocked by any network perimeter. As a result of being unencrypted and the backbone of web traffic, HTTP is one of the must-to-know protocols in traffic analysis. Following attacks could be detected with the help of HTTP analysis:

• Phishing pages
• Web attacks
• Data exfiltration
• Command and control traffic (C2)

HTTP analysis in a nutshell:

User Agent Analysis

As the adversaries use sophisticated technics to accomplish attacks, they try to leave traces similar to natural traffic through the known and trusted protocols. For a security analyst, it is important to spot the anomaly signs on the bits and pieces of the packets. The “user-agent” field is one of the great resources for spotting anomalies in HTTP traffic. In some cases, adversaries successfully modify the user-agent data, which could look super natural. A security analyst cannot rely only on the user-agent field to spot an anomaly. Never whitelist a user agent, even if it looks natural. User agent-based anomaly/threat detection/hunting is an additional data source to check and is useful when there is an obvious anomaly. If you are unsure about a value, you can conduct a web search to validate your findings with the default and normal user-agent info (example site).

User Agent analysis in a nutshell:

Log4j Analysis

A proper investigation starts with prior research on threats and anomalies going to be hunted. Let’s review the knowns on the “Log4j” attack before launching Wireshark.

Log4j vulnerability analysis in a nutshell:

Detecting suspicious activities in chunked files is easy and a great way to learn how to focus on the details. Now use the exercise files to put your skills into practice against a single capture file and answer the questions below!

Answer the questions below:

Use the “Desktop/exercise-pcaps/http/user-agent.cap” file.

7.1 Investigate the user agents. What is the number of anomalous “user-agent” types?

To get this I first filtered by:

http.user_agent

This didn’t do much for me, it narrows the count down by 1… k. Next I expanded the HTTP tree of a packet, right click the “User-Agent” field and applied it as a column, then sorted by that column. This allowed me to easily count up the different types of user agents:

Answer: 6

7.2 What is the packet number with a subtle spelling difference in the user agent field?

I couldn’t find a way to do this super cleanly where you just input a single filter and you get a single result with the identifying packet number, but for this task, it’s very easy to figure out if you have applied the User-Agent as a column as directed in the previous questions:

Answer: 52

Use the “Desktop/exercise-pcaps/http/http.pcapng” file.
7.3 Locate the “Log4j” attack starting phase. What is the packet number?

This one would be hard had they not given us the filter query:

I put it all into one filter:

http.request.method=="POST" and ((ip contains "jndi") or (ip contains 
"Exploit")) and ((frame contains "jndi") or (frame contains "Exploit")) and 
((http.user_agent contains "$") or (http.user_agent contains "=="))

We get just 1 result:

Answer: 444

7.4 Locate the “Log4j” attack starting phase and decode the base64 command. What is the IP address contacted by the adversary? (Enter the address in defanged format and exclude “{}”.)

On that same packet, expand HTTP and the Base64 code is in the user-agent field, it’s everything after the “Base64/” and before the closing curly bracket:

Let’s copy this and decode it in CyberChef:

Very interesting, so we can see that this Base64 code is using “wget” to download, set permissions and run a script. Once you’ve got the IP address, change your recipe from “Decode Base64” to “Defang IP”:

Answer: 62[.]210[.]130[.]250

Task 8: Encrypted Protocol Analysis: Decrypting HTTPS

When investigating web traffic, analysts often run across encrypted traffic. This is caused by using the Hypertext Transfer Protocol Secure (HTTPS) protocol for enhanced security against spoofing, sniffing and intercepting attacks. HTTPS uses TLS protocol to encrypt communications, so it is impossible to decrypt the traffic and view the transferred data without having the encryption/decryption key pairs. As this protocol provides a good level of security for transmitting sensitive data, attackers and malicious websites also use HTTPS. Therefore, a security analyst should know how to use key files to decrypt encrypted traffic and investigate the traffic activity.

The packets will appear in different colours as the HTTP traffic is encrypted. Also, protocol and info details (actual URL address and data returned from the server) will not be fully visible. The first image below shows the HTTP packets encrypted with the TLS protocol. The second and third images demonstrate filtering HTTP packets without using a key log file.

Additional information for HTTPS :

Similar to the TCP three-way handshake process, the TLS protocol has its handshake process. The first two steps contain “Client Hello” and “Server Hello” messages. The given filters show the initial hello packets in a capture file. These filters are helpful to spot which IP addresses are involved in the TLS handshake.

• Client Hello: (http.request or tls.handshake.type == 1) and !(ssdp)
• Server Hello: (http.request or tls.handshake.type == 2) and !(ssdp)

An encryption key log file is a text file that contains unique key pairs to decrypt the encrypted traffic session. These key pairs are automatically created (per session) when a connection is established with an SSL/TLS-enabled webpage. As these processes are all accomplished in the browser, you need to configure your system and use a suitable browser (Chrome and Firefox support this) to save these values as a key log file. To do this, you will need to set up an environment variable and create the SSLKEYLOGFILE, and the browser will dump the keys to this file as you browse the web. SSL/TLS key pairs are created per session at the connection time, so it is important to dump the keys during the traffic capture. Otherwise, it is not possible to create/generate a suitable key log file to decrypt captured traffic. You can use the “right-click” menu or “Edit → Preferences → Protocols → TLS” menu to add/remove key log files.

Adding key log files with the “right-click” menu:

Adding key log files with the “Edit → Preferences → Protocols → TLS” menu:

Viewing the traffic with/without the key log files:

The above image shows that the traffic details are visible after using the key log file. Note that the packet details and bytes pane provides the data in different formats for investigation. Decompressed header info and HTTP2 packet details are available after decrypting the traffic. Depending on the packet details, you can also have the following data formats:

• Frame
• Decrypted TLS
• Decompressed Header
• Reassembled TCP
• Reassembled SSL

Detecting suspicious activities in chunked files is easy and a great way to learn how to focus on the details. Now use the exercise files to put your skills into practice against a single capture file and answer the questions below!

Answer the questions below:

Use the “Desktop/exercise-pcaps/https/Exercise.pcap” file.

8.1 What is the frame number of the “Client Hello” message sent to “accounts.google.com”?

We know part of this from the task text, the other part I looked up, there may be a different solution for this. If you know of one, let me know!

tls.handshake.type==1 and tls.handshake.extensions_server_name contains 
"accounts.google.com"

We only get one result:

Answer: 16

8.2 Decrypt the traffic with the “KeysLogFile.txt” file. What is the number of HTTP2 packets?

Per the task text, we need to apply an encryption key log file to view encrypted data. We can do that by going to Edit > Preferences > Protocols > TLS > “(Pre)-Master-Secret log filename”:

Now if you filter by “HTTP2” you’ll see the data:

In theory the number using this filter would be accurate but it’s not? Not sure why. However it’s easy enough to subtract the few that should not be counted, just filter by Protocol and there are 3 TLSv1.3 entries to subtract:

Answer: 115

8.3 Go to Frame 322. What is the authority header of the HTTP2 packet? (Enter the address in defanged format.)

Easy enough, find the packet, Expand the HTTP2 > Stream: Headers > Header: authority tree, answer is there:

Now go to CyberChef with the Defang URL recipe loaded:

Answer: safebrowsing[.]googleapis[.]com

8.4 Investigate the decrypted packets and find the flag! What is the flag?

This is very similar to what we did in a previous room so we already know how to do this (the answer is very similar as well!):

Go to File > Export Objects > HTTP > Select the text file (packet 1644) and export it to your desktop:

Read the file:

Answer: FLAG{THM-PACKETMASTER}

Task 9: Bonus: Hunt Cleartext Credentials!

Up to here, we discussed how to inspect the packets for specific conditions and spot anomalies. As mentioned in the first room, Wireshark is not an IDS, but it provides suggestions for some cases under the expert info. However, sometimes anomalies replicate the legitimate traffic, so the detection becomes harder. For example, in a cleartext credential hunting case, it is not easy to spot the multiple credential inputs and decide if there is a brute-force attack or if it is a standard user who mistyped their credentials.

As everything is presented at the packet level, it is hard to spot the multiple username/password entries at first glance. The detection time will decrease when an analyst can view the credential entries as a list. Wireshark has such a feature to help analysts who want to hunt cleartext credential entries.

Some Wireshark dissectors (FTP, HTTP, IMAP, pop and SMTP) are programmed to extract cleartext passwords from the capture file. You can view detected credentials using the “Tools → Credentials” menu. This feature works only after specific versions of Wireshark (v3.1 and later). Since the feature works only with particular protocols, it is suggested to have manual checks and not entirely rely on this feature to decide if there is a cleartext credential in the traffic.

Once you use the feature, it will open a new window and provide detected credentials. It will show the packet number, protocol, username and additional information. This window is clickable; clicking on the packet number will select the packet containing the password, and clicking on the username will select the packet containing the username info. The additional part prompts the packet number that contains the username.

Press enter or click to view image in full size

Answer the questions below:

Use the “Desktop/exercise-pcaps/bonus/Bonus-exercise.pcap” file.

9.1 What is the packet number of the credentials using “HTTP Basic Auth”?

This one was pretty easy as there aren’t many HTTP packets and it’s described in the task:

Per the task, you can just go to Tools > Credentials

You can also just filter:

http

The answer was the first packet:

Answer: 237

9.2 What is the packet number where “empty password” was submitted?

Ok, not sure how we were supposed to get there but I reverse engineered the thing to get my answer. From the credentials window that we had open for the previous question, we can deduce that the protocol is going to be FTP, since there is only one HTTP packet with auth and we know it has a password, this gives us our first filter:

ftp

Simple right? Ok now we can manually click on the packets to find out what it is that we’re looking for in the fields. We come upon our answer here:

You’ll quickly find that those packets that do have a password have this “Request arg” field and the one that does not have a password does not have this field at all:

The filter for this field is:

ftp.request.arg

But we also need to filter by getting a request for a password and this filter is:

ftp.request.command

So putting this all together, we’re going to throw a “NOT” qualifier in front of the request.arg field since we want packets that don’t have this option:

ftp and !ftp.request.arg and ftp.request.comman

We get exactly one packet:

Answer: 170

Task 10: Bonus: Actionable Results!

Bonus: Actionable Results!

You have investigated the traffic, detected anomalies and created notes for further investigation. What is next? Not every case investigation is carried out by a crowd team. As a security analyst, there will be some cases you need to spot the anomaly, identify the source and take action. Wireshark is not all about packet details; it can help you to create firewall rules ready to implement with a couple of clicks. You can create firewall rules by using the “Tools → Firewall ACL Rules” menu. Once you use this feature, it will open a new window and provide a combination of rules (IP, port and MAC address-based) for different purposes. Note that these rules are generated for implementation on an outside firewall interface.

Currently, Wireshark can create rules for:

• Netfilter (iptables)
• Cisco IOS (standard/extended)
• IP Filter (ipfilter)
• IPFirewall (ipfw)
• Packet filter (pf)
• Windows Firewall (netsh new/old format)

Answer the questions below

Use the “Desktop/exercise-pcaps/bonus/Bonus-exercise.pcap” file.

10.1 Select packet number 99. Create a rule for “IPFirewall (ipfw)”. What is the rule for “denying source IPv4 address”?

This one is pretty simple, go to Tools > Firewall ACL Rules > IPFirewall (ipfw):

Answer: add deny ip from 10.121.70.151 to any in

10.2 Select packet number 231. Create “IPFirewall” rules. What is the rule for “allowing destination MAC address”?

This one is almost as easy, just gotta switch a deny to an allow:

Answer: add allow MAC 00:d0:59:aa:af:80 any in

Task 11: Conclusion

Congratulations! You just finished the “Wireshark: The Traffic Analysis” room.

In this room, we covered how to use the Wireshark to detect anomalies and investigate events of interest at the packet level. Now, we invite you to complete the Wireshark challenge room: Carnage, Warzone 1 and Warzone 2.

Wireshark is a good tool for starting a network security investigation. However, it is not enough to stop the threats. A security analyst should have IDS/IPS knowledge and extended tool skills to detect and prevent anomalies and threats. As the attacks are getting more sophisticated consistently, the use of multiple tools and detection strategies becomes a requirement. The following rooms will help you step forward in network traffic analysis and anomaly/threat detection.

• NetworkMiner
• Snort
• Snort Challenge — The Basics
• Snort Challenge — Live Attacks
• Zeek
• Zeek Exercises
• Brim

This concludes the Network Security and Traffic Analysis module, the third of seven modules in this SOC Level 1 Path and it also ends the Wireshark: Traffic Analysis room on TryHackMe. This was a loooooooooooong room and man was it action packed. I learned a ton and I hope that you did too. After learning everything we did over these past three rooms about Wireshark I think it may have edged out Zeek for me, not sure, but both are incredible tools to know and have their own strengths and weaknesses.

Wireshark: Traffic Analysis| TryHackMe — Walkthrough — Part 2 was originally published in System Weakness on Medium, where people are continuing the conversation by highlighting and responding to this story.

The moment you hand an agent the ability to run shell commands, query SQL databases, interface with cloud APIs, or execute dynamic Python code, a harsh reality sets in: we are granting root-level capabilities to a non-deterministic black box.

For the past couple of years, the collective response from much of the AI ecosystem has been dangerously naive:

• “We’ll just instruct the model in the system prompt not to touch sensitive files.”
• “We put a lightweight LLM guardrail in front of the input pipeline.”
• “We told the agent to ask for human approval before doing anything dangerous.”

As anyone who has spent ten minutes testing indirect prompt injections knows, relying on an LLM to enforce its own safety rules is like putting a “Do Not Steal” sticker on an unattended vault and calling it enterprise security. Prompts exist inside the model’s context window. Context windows can be manipulated, confused, overflowed, and jailbroken.

That is precisely why NVIDIA OpenShell represents such a massive architectural shift. Instead of trying to coax the LLM into behaving properly, OpenShell steps back and adopts a strict engineering posture: The agent workload is entirely untrusted, and we will enforce security boundaries at the Linux kernel and network proxy layers.

Let’s pop the hood on OpenShell, analyze its underlying technical mechanisms, walk through real-world attack vectors, and examine how you can operationally deploy these zero-trust boundaries in high-stakes environments.

1. The Architectural Flaw of Application-Level AI Guardrails

To understand why OpenShell is necessary, we first need to dissect why conventional application-layer defenses fail when applied to autonomous agents.

Traditional Guardrail Architecture (Fragile):
[ User / External Input ] ---> [ LLM Guardrail / System Prompt ] ---> [ Agent LLM ] ---> [ Full Host Access ]
                                 (Bypassed via Injection)                                (System Compromised)

In traditional web applications, input validation is deterministic. If a string contains invalid SQL characters, a parameterized query neutralizes the attack before it touches the database engine.

With AI agents, the boundary between data and code is completely blurred. When an agent reads an untrusted PDF, parses a web page, or scans an incoming email, that unstructured text becomes part of the prompt context. If that text contains malicious instructions (an Indirect Prompt Injection), the model processes those instructions with the exact same priority as the original developer prompt.

Application-layer filters (like regex matchers or secondary LLM evaluators) fail for three primary reasons:

• Semantic Encoding Obfuscation: Attackers can encode payloads in Base64, ROT13, custom hexadecimal encodings, or foreign languages that bypass input scanners but are easily deciphered by advanced models.
• Multi-Turn Context Manipulation: An attacker can fragment a payload across multiple conversational turns, assembling the malicious command only when the full context window is evaluated.
• Data Exfiltration via Legitimate Tools: Even if an agent is prevented from generating explicit curl commands, an attacker can trick the model into using legitimate internal tools (like an API integration or file reader) to exfiltrate sensitive data.

The takeaway is simple: Security cannot be enforced within the same layer that is subject to compromise. Security must sit outside the execution context entirely.

2. Core Philosophy: Zero Trust for AI Workloads

OpenShell shifts security down to the infrastructure layer, operating under a strict Zero Trust Execution Model.

OpenShell Zero-Trust Boundary (Deterministic):
[ Untrusted LLM / Agent ] ---> [ OpenShell Runtime Boundaries ] ---> [ Infrastructure / APIs ]
                                   |---> Kernel Syscall Filters (Seccomp-BPF)
                                   |---> Mount & PID Namespaces (OverlayFS)
                                   |---> Supervisor Egress Proxy (Credential Abstraction)
                                   |---> Declarative Policy Engine (YAML-as-Code)

Under OpenShell, the agent starts with zero privileges. It cannot access the host filesystem, it cannot invoke arbitrary system calls, it cannot open raw network sockets, and it cannot inspect host processes. Every single action must be explicitly permitted by a declarative policy file enforced by the underlying OS kernel.

3. Deep Technical Architecture: Inside the OpenShell Engine

OpenShell constructs its security perimeter by integrating four core subsystem mechanics:

A. Kernel-Level Isolation (seccomp-bpf & Linux Namespaces)

Rather than spawning agents directly on the host or inside vanilla containers, OpenShell provisions ephemeral, heavily locked-down sandboxes backed by core Linux kernel security primitives:

• System Call Filtering via seccomp-bpf: OpenShell attaches custom Secure Computing Mode (seccomp) filters using Berkeley Packet Filter bytecode directly to the agent process tree. Dangerous system calls—such as execveat, ptrace, kexec_load, unshare, or dynamic kernel module loading—are intercepted and rejected at the kernel level. Even if an attacker achieves arbitrary code execution inside the agent runtime, they cannot invoke exploit payloads against the host kernel.
• Filesystem Isolation via Mount Namespaces & overlayfs: The root filesystem presented to the agent is mounted read-only (ro) by default using overlayfs. The agent is provided with an isolated, temporary workspace directory (/tmp/workspace). Critical system paths (/etc, /var/run, /proc/sys, ~/.ssh, ~/.aws) are entirely unmounted or omitted from the mount namespace.
• Process & PID Namespaces: OpenShell executes the agent within an isolated PID namespace. The agent process cannot view, interact with, debug (gdb/strace), or signal (kill) any host processes or sibling agent sandboxes.

B. The Supervisor Proxy & Credential Abstraction

One of the most elegant design features of OpenShell is how it handles authentication tokens and API keys.

In traditional agent setups, developer credentials (e.g., OPENAI_API_KEY, GITHUB_TOKEN, AWS_ACCESS_KEY_ID) are passed as environment variables into the agent container. If an agent is jailbroken, an attacker simply instructs the model to execute env or read /proc/self/environ to exfiltrate those production secrets.

OpenShell completely eliminates secret exposure through Out-of-Band Credential Injection:

[ Agent inside Sandbox ]  ---> Attempts GET https://api.github.com/user
                                 |
                                 v  (Forced through Unix Domain Socket)
[ OpenShell Supervisor Proxy ] --| Checks YAML Policy -> Authorized?
                                 | Inject Header: "Authorization: Bearer ghp_SECRET..."
                                 v
[ External API / Internet ]  <---| Request Sent with Real Key

• Secret Isolation: Production API keys never enter the sandbox container or the agent’s context window.
• Forced Egress Interception: All outbound TCP/UDP traffic generated inside the sandbox is forcibly routed through a non-bypassable local Unix domain socket connected to the OpenShell Supervisor Proxy.
• Dynamic Injection: When the agent calls an approved external endpoint (e.g., api.github.com), the proxy inspects the request headers. If the target host matches the whitelisted policy, the Supervisor injects the actual authorization header outside the agent's sandbox boundary before forwarding the packet to the public internet.

C. Declarative Policy Engine (Policy-as-Code)

OpenShell decouples security administration from application logic by utilizing declarative YAML policy definitions. Security engineering teams can audit and manage these specs independently of the AI development team:

YAML

# openshell-enterprise-policy.yaml
version: "1.0"
agent_id: "financial-reporting-agent"
runtime:
  max_memory_mb: 2048
  cpu_quota_pct: 50
  max_execution_time_sec: 300

filesystem:
  read_only_paths:
    - "/app/templates"
    - "/app/datasets/public"
  read_write_paths:
    - "/tmp/workspace"
  denied_paths:
    - "/etc"
    - "/root"
    - "~/.ssh"

syscalls:
  allow:
    - "read"
    - "write"
    - "openat"
    - "close"
    - "exit_group"
  action_on_deny: "KILL_PROCESS"

network:
  default_egress: "DENY"
  allowed_endpoints:
    - host: "api.github.com"
      port: 443
      proto: "https"

credentials:
  inject:
    - header: "Authorization"
      secret_env: "PROD_GITHUB_TOKEN"
      match_host: "api.github.com"

4. Real-World Walkthrough: Neutralizing Indirect Prompt Injection

To visualize how OpenShell operates during an active security incident, let’s walk through a classic Indirect Prompt Injection exploit scenario:

[ Malicious PDF ] ---> [ Agent Reads File ] ---> [ Executes Injected Command ] ---> [ Exfiltration Attempt ]

• Phase 1: Reading the Target Document
• The agent reads an uploaded customer PDF located within /tmp/workspace.
• Status: ALLOWED (Matches read_write_paths in the YAML policy).
• Phase 2: Execution of Malicious Instruction
• The PDF contains hidden text ordering the LLM to read local system keys and send an HTTP POST request to [https://exfil.attacker-site.com](https://exfil.attacker-site.com).
• Phase 3: Network Interception at Proxy Layer
• The outbound TCP connection request is trapped by OpenShell’s socket redirection and routed to the Supervisor Proxy.
• The Supervisor checks exfil.attacker-site.com against the allowed_endpoints rule.
• Status: DENIED (Destination host is not whitelisted).
• Phase 4: Containment & Immediate Process Termination
• The Supervisor drops the connection attempt and logs an audit event (NET_EGRESS_VIOLATION).
• Because the policy specifies action_on_deny: KILL_PROCESS, OpenShell issues a kernel-level SIGKILL to the sandbox process tree, instantly killing rogue execution.

5. Taking OpenShell to Production in Critical Infrastructure & Enterprise Environments

While OpenShell provides the runtime sandbox mechanics, deploying autonomous AI agents in high-stakes environments — such as energy grids, OT/ICS networks, financial networks, and critical infrastructure — requires more than just running a sandbox daemon.

You must be able to answer critical audit and governance questions:

• How do you translate NIST CSF 2.0, ISO 27001, and NIS2 compliance requirements into concrete AI agent policies?
• What is your threat model for agentic workflow integration into SCADA/OT systems or internal cloud infrastructure?
• Where are your standardized YAML policy templates, risk matrix spreadsheets, and red-teaming verification playbooks?

Building these security governance frameworks and hardening templates from scratch usually takes engineering teams months of drafting and compliance alignment.

Accelerated Field Resource

If you are currently designing or auditing AI agent deployments for enterprise networks or critical infrastructure, check out the AI Governance & Security Toolkit for Critical Infrastructure developed by TechSavant Security Lab.

It provides a complete, battle-tested implementation pack including:

• Production-Ready Policy Blueprints: Pre-configured YAML policy templates for OpenShell, seccomp-bpf profiles, and egress whitelist specs.
• Enterprise Risk & Threat Matrix: Comprehensive threat modeling frameworks covering Indirect Prompt Injection, Credential Exfiltration, and Agent Privilege Escalation.
• OT/ICS & Critical Infrastructure Playbooks: Specific guidelines for integrating AI tools into SCADA, energy management systems, and high-availability operational technology without violating NERC CIP or IEC 62443 standards.
• Audit-Ready Compliance Checklists: Step-by-step verification templates to satisfy enterprise risk assessment boards and regulatory audits.

6. Hardware-Enforced Isolation: NVIDIA BlueField DPU Integration

For organizations operating in ultra-sensitive environments where software-level kernel sandboxes might still trigger compliance concerns regarding kernel zero-day escapes, the OpenShell Reference Architecture introduces hardware-enforced isolation via NVIDIA BlueField DPUs and NVIDIA Sentry (powered by DOCA).

+--------------------------------------------------------------------------+
| HOST SYSTEM (CPU & GPU)                                                  |
|   [ Untrusted Agent Workload ] ---> [ User Space Sandbox Container ]     |
+--------------------------------------------------------------------------+
                                  |
            PCIe Out-of-Band Telemetry & Network Monitoring
                                  |
                                  v
+--------------------------------------------------------------------------+
| HARDWARE BOUNDARY: NVIDIA BlueField DPU (Running NVIDIA Sentry / DOCA)   |
|   [ Hardware-Isolated Enclave ] ---> [ Real-time Telemetry & Net-Kill ]  |
+--------------------------------------------------------------------------+

• Air-Gapped Control Plane: The security policy engine and telemetry monitors run on the BlueField DPU’s dedicated ARM cores — completely separate from the host CPU running the LLM agent.
• Tamper-Proof Audit Logging: Even if an attacker achieves root access and escapes the host OS kernel, they cannot modify or delete audit logs stored inside the physically isolated DPU enclave.
• Out-of-Band Physical Termination: If the DPU detects anomalous egress traffic or unexpected system call patterns, it can sever the host’s physical network interface or issue an out-of-band hardware reset directly over the PCIe bus.

Conclusion

We need to stop treating AI agent security as a prompt engineering problem. Prompts are designed to guide behavior; infrastructure is designed to enforce boundaries.

NVIDIA OpenShell provides a robust blueprint for placing deterministic security perimeters around non-deterministic AI models. By combining seccomp-bpf kernel filtering, proxy credential abstraction, hardware-backed monitoring, and comprehensive governance frameworks like the AI Governance Toolkit for Critical Infrastructure, security teams can safely unlock the power of autonomous AI agents without sacrificing operational integrity.

Keep reading

• Build a Harmless Canary MCP Server to Test Your AI Agent for Tool Poisoning
• MCP Is the New Attack Surface: What the 2025–2026 Incidents Teach
• AI Agents Need Identity, Not Just Guardrails

I write one practical, test-it-yourself article a week on AI agent and OT/ICS security. Follow if that’s useful to you.

Stop Trusting System Prompts: A Deep Technical Analysis of NVIDIA OpenShell for AI Agent Security was originally published in System Weakness on Medium, where people are continuing the conversation by highlighting and responding to this story.