Detection Techniques and Scripting

When an attacker breaches an environment, their immediate problem is avoiding the defensive perimeter. Antivirus software and Endpoint Detection and Response (EDR) sensors are highly tuned to detect foreign, malicious executable files. To solve this, adversaries leverage native scripting interpreters to evade detection mechanisms looking for external executable malware files.

This doctrine is known as Living off the Land (LotL).

Living off the Land attacks use pre-installed, legitimate system administration tools to execute malicious operations. Because the tool itself is cryptographically signed and trusted by the operating system, the execution fundamentally looks like routine administrative overhead.

The Power and Peril of Native Interpreters

Attackers rely on various native tools to establish their foothold:

• Windows Script Host: Attackers abuse the Windows Script Host utilities cscript.exe and wscript.exe to execute malicious script files. These engines natively interpret VBScript and JScript, allowing adversaries to interact with the Windows API directly.
• Certutil: Consider certutil.exe, a legitimate Windows utility designed for handling certificate services. It is often abused by attackers to download malicious files from remote servers using its -urlcache or -f flags. To the operating system, it simply looks like a background process fetching a certificate update.
• WMI: For lateral movement and persistence, Windows Management Instrumentation (WMI) is the standard. Attackers frequently use WMI to execute administrative commands on remote Windows systems without needing traditional remote desktop protocols. Because WMI operations run under highly privileged system processes, Windows Management Instrumentation is actively abused by threat actors to establish persistent access on compromised hosts.

The Anomaly in the Process Tree

Because these tools are legitimate, detection relies on identifying abnormal behavior in the context of their execution. One of the most powerful detection techniques is process lineage analysis. For example, Microsoft Word spawning cmd.exe or powershell.exe is a highly suspicious parent-child process relationship. A word processor has no legitimate architectural need to invoke a command-line interpreter. When it does, it almost invariably indicates that an embedded payload is attempting to escape the document sandbox.

No native tool is more heavily weaponized than PowerShell. It is a fully-featured, object-oriented shell with direct access to the .NET framework and the Windows API.

The primary advantage for the adversary is that threat actors frequently use PowerShell to execute malicious payloads directly in the memory of a target system. By never writing a payload to the physical disk (fileless malware), the attacker bypasses traditional file-scanning antivirus engines entirely.

However, default Windows configurations place restrictions on script execution. To execute their tools, attackers must bypass these safeguards. Bypassing the Windows execution policy allows unauthorized scripts to run on a secured endpoint. They achieve this effortlessly by manipulating command-line parameters. Specifically, the ExecutionPolicy Bypass flag in PowerShell prevents the system from blocking the execution of unsigned scripts, rendering the administrative guardrail entirely ineffective.

Obfuscation and Encoding

To mask their intentions from security analysts and static analysis tools, adversaries utilize two primary mathematical and programmatic techniques:

1. Obfuscation: This involves deliberately muddying the syntax of the code without changing its logical output. Obfuscation techniques like string concatenation mask the true intent of malicious scripts from static analysis tools. If an EDR is looking for the exact string Net.WebClient, an attacker might write it as 'Net.Web' + 'Client', evading the rudimentary text match.
2. Base64 Encoding: To transmit complex payloads securely via the command line, the PowerShell -EncodedCommand parameter accepts Base64 encoded strings to bypass traditional pattern matching detections.

Base64 works by translating binary data into a 64-character ASCII alphabet. Because it maps every 3 bytes of data into 4 characters of text, uneven data lengths require mathematical padding. Consequently, Base64 encoding frequently pads the end of an encoded string with one or two equals signs (= or ==). This padding is an immediate visual indicator to an analyst that encoded data is present in the logs.

Once the payload is in memory, it must be unpacked and run. The Invoke-Expression cmdlet in PowerShell is frequently abused to evaluate and execute dynamically generated strings as commands. The attacker feeds the decoded, de-obfuscated string into Invoke-Expression, and the system executes it blindly.

The Defensive Response: Script Block Logging

How does a SOC analyst defend against a script that unpacks itself dynamically in memory? We rely on telemetry gathered after the de-obfuscation occurs.

Script block logging captures the full content of executing PowerShell scripts to facilitate post-incident forensic analysis. When Event ID 4104 is enabled, the PowerShell engine intercepts the script code right before execution—after all Base64 decoding and string concatenation has occurred—and writes the cleartext instructions to the Windows Event Log.

Whether operating in Windows or Linux, analyzing command-line arguments reveals the specific execution behaviors of potentially malicious binaries. We do not need to reverse-engineer a compiled binary if we can simply observe the arguments passed to it at runtime.

Automated Reconnaissance

When a human administrator logs into a server, they pause, orient themselves, and check specific configurations. When an automated script lands on a box, it operates at machine speed. The presence of [whoami](https://en.wikipedia.org/wiki/whoami), [netstat](https://en.wikipedia.org/wiki/netstat), and [ipconfig](https://en.wikipedia.org/wiki/ipconfig) executed in rapid succession often indicates automated reconnaissance activity. The malware is urgently profiling its current user privileges, active network connections, and network architecture to decide its next move.

Linux and the Reverse Shell

In Unix-like environments, adversaries require interactive control over the compromised machine. They frequently achieve this via a reverse shell.

A reverse shell command using Bash establishes an interactive command-line connection with an attacker. Instead of the attacker connecting to the victim (which would likely be blocked by a firewall), the victim server is forced to initiate an outbound connection back to the attacker's listening server.

To achieve this without compiling C code, Bash reverse shell commands frequently pipe input and output streams to the /dev/tcp device file. By redirecting [stdin](https://en.wikipedia.org/wiki/Standard_streams), [stdout](https://en.wikipedia.org/wiki/Standard_streams), and [stderr](https://en.wikipedia.org/wiki/Standard_streams) to a socket mapped at /dev/tcp/attacker_IP/port, Bash fundamentally transforms the compromised server into a remote-controlled node.

Before PowerShell is abused, before the reverse shell is established, the adversary must find a way into the environment. The primary vector remains electronic mail.

Payload Mechanics

The payloads hidden within emails are specifically designed to trigger the Living off the Land techniques we discussed earlier.

• Malicious Microsoft Office attachments frequently contain Visual Basic for Applications (VBA) macros.
• These embedded scripts are incredibly dangerous because Visual Basic for Applications macros in Office documents can be abused to download and execute arbitrary payloads on a victim machine.

As email security gateways have become highly proficient at stripping attachments containing macros, adversaries have pivoted. Now, attackers embed malicious URLs within HTML email bodies to evade attachment-based email security gateways. The email contains no malicious file—only a hyperlinked string of text.

Visual Deception in URLs

To trick users into clicking these links, attackers use typographical illusions.

• Punycode Domains: The domain name system (DNS) originally supported only ASCII characters. Punycode was invented to allow internationalized domain names (like those containing Cyrillic or Greek letters) to be translated into ASCII. However, Punycode domains are used in email phishing attacks to visually trick users into believing a malicious URL is legitimate.
• Homograph Attacks: This visual trickery is the core of a homograph attack. Homograph attacks utilize visually similar characters from different alphabets to spoof legitimate domain names in phishing emails. For example, replacing a Latin a with a Cyrillic а creates a visually identical, but mathematically distinct, URL.

Tracing the Origin: Email Headers

When an analyst receives a suspicious email, the visual rendering of the message is mostly useless. The cryptographic and routing truth of the email exists entirely in the raw headers. Email header analysis allows security analysts to trace the true origin of a suspicious message.

Three header fields are particularly vital during an investigation:

The Authentication Triad: SPF, DKIM, and DMARC

To combat domain spoofing, the internet relies on a triad of DNS-based authentication protocols. An analyst must be able to interpret their validation results in the email header.

1. Sender Policy Framework (SPF): The Sender Policy Framework validates whether an email originates from an IP address authorized by the domain owner. The domain owner publishes a DNS TXT record listing the IP addresses of their valid mail servers. If the sender's IP isn't on the list, SPF fails.

Source: Sender Policy Framework by Unknown author Unknown author, CC BY-SA 3.0.

2. DomainKeys Identified Mail (DKIM): While SPF validates the path, DKIM validates the content. DomainKeys Identified Mail adds a cryptographic signature to emails to verify message content integrity. It proves that the email was not tampered with in transit.
3. DMARC: SPF and DKIM are merely mechanisms. DMARC is the policy layer.
   • Domain-based Message Authentication, Reporting, and Conformance relies on the Sender Policy Framework to determine handling rules for unauthenticated emails.
   • Furthermore, Domain-based Message Authentication, Reporting, and Conformance utilizes DomainKeys Identified Mail to enforce policies against spoofed domains.

If DMARC fails, the recipient server checks the domain's DMARC DNS record to see if the domain owner wants the message quarantined or outright rejected.

We have discussed how adversaries use native scripts. Defenders must respond with equal programmatic rigor. The sheer volume of telemetry generated by a modern enterprise cannot be analyzed manually.

The Role of Python and Bash

In the modern Security Operations Center (SOC), Python is the universal language of defense.

• Log Parsing: Enterprise logs are messy, unstructured, and massive. Python is heavily utilized in Security Operations Centers to automate security log parsing, allowing analysts to extract actionable artifacts from terabytes of raw text.
• Threat Intelligence: Security analysts use Python scripts to programmatically interact with external threat intelligence application programming interfaces. Instead of manually searching a hash on VirusTotal, a Python script can query the API and append the reputation score directly to the internal ticket.
• Automation: Security Orchestration, Automation, and Response (SOAR) platforms utilize Python scripts to execute automated incident response playbooks. When an alert fires, Python scripts can automatically isolate the host, disable the user account, and email the administrator in milliseconds.

For system-level forensics on Unix networks, bash reigns supreme. Incident responders utilize Bash scripting to collect forensic data concurrently across multiple Linux systems, pulling memory dumps and process lists over SSH using looped array structures.

Recognizing the Attack: Rules and Expressions

How do we tell our defensive tools what to look for? We use highly specific syntax to define the shape of maliciousness.

• Regular Expressions (Regex): At the foundation of pattern matching is regex. Regular expressions are used in security tools to define complex search patterns for identifying malicious indicators within text. Whether you are looking for a credit card number or a perfectly formatted IP address, regex provides the mathematical syntax to match the exact string configuration.

• YARA: Moving from text strings to file analysis, we use YARA. YARA rules identify malware families based on textual or binary patterns within files. A YARA rule can scan a directory or active system memory and say, "Alert me if you find a file containing this specific hexadecimal sequence and this specific compressed string."
• Sigma: What YARA is to files, Sigma is to logs. Sigma rules provide a generic, vendor-agnostic signature format for describing suspicious log events. You write the logic of the attack once in Sigma, and the tool translates that logic into the specific query language of Splunk, Elastic, or Sentinel.

Ultimately, these tools feed into the central nervous system of the SOC: the SIEM. Isolated events are rarely malicious on their own. Someone running whoami is not an incident. A suspicious email is not an incident. But an inbound email from a newly registered domain, followed immediately by Word spawning PowerShell, followed by a Base64 string executing in memory, followed by whoami and an outbound connection over /dev/tcp?

That is an attack sequence. And pattern recognition in Security Information and Event Management (SIEM) platforms identifies anomalous sequences of events indicative of an attack.

Source: Basic SIEM Infrastructure by Jbuchanan 1, CC BY-SA 4.0.

By mastering the underlying mechanics of execution, network communication, and programmatic scripting, the modern analyst ceases to look at mere alerts, and begins to see the underlying geometry of the intrusion.