Cybersecurity Q&A
Browse concise answers derived from our published, source-linked cybersecurity coverage.
What steps are needed to load a PE file (like Mimikatz) from memory using MSBuild?
To load a PE file from memory using MSBuild, you write C# code within an Inline Task to read the PE bytes and execute them, similar to loading a .NET assembly reflectively. The XML file must specify `TaskFactory="CodeTaskFactory"` and the correct path to `Microsoft.Build.Tasks.v4.0.dll`. A crucial detail is that on 64-bit systems, you must use the 64-bit MSBuild executable at `C:\Windows\Microsoft.NET\Framework64\v4.0.30319\msbuild.exe` to avoid errors. The article [Use MSBuild To Do More](/news/use-msbuild-to-do-more) provides a working example and points to related research on [Loading PE files into memory via .NET](/news/loading-pe-files-into-memory-via-net).
How can I execute PowerShell commands using MSBuild?
You can execute PowerShell commands via MSBuild by leveraging the 'Inline Tasks' feature in .NET Framework 4.0. The trick is to craft an XML file that defines a task using the `CodeTaskFactory` and includes C# code that calls PowerShell. Casey Smith provided a public POC that converts C# invocations into an XML format executable by `msbuild.exe`, as detailed in the article [Use MSBuild To Do More](/news/use-msbuild-to-do-more). This technique bypasses application whitelisting because MSBuild is a trusted Microsoft binary.
Why might the crawler need to simulate browser access, and how is it done?
If expireddomains.net implements anti-crawling measures, the script can add HTTP headers like `User-Agent` to mimic a real browser. The [article](/news/penetration-basics-choosing-a-suitable-c2-domain) demonstrates adding `req.add_header("User-Agent", "Mozilla/5.0...")` to bypass such restrictions, though currently the site does not block automated queries.
What is the maximum number of results returned by expireddomains.net for non-logged-in users, and how does the script handle that?
expireddomains.net returns a maximum of 550 results (21 pages) for non-logged-in users. The script checks if the total exceeds 550; if so, it only iterates through 21 pages; otherwise, it uses the actual page count derived from the total.
How does the Python crawler handle pagination on expireddomains.net?
The crawler first extracts the total number of results from a `<strong>` tag, then divides by 25 to determine the number of pages. It constructs URLs with a `start` parameter (e.g., `?start=25&q=keyword`) for subsequent pages, looping until all pages are retrieved but limited to 550 results (21 pages) for non-logged-in users, as described in the [article](/news/penetration-basics-choosing-a-suitable-c2-domain).
What is the purpose of using expired domains for C2 servers in penetration testing?
In penetration testing, expired domains that were previously categorized as legitimate by services like Symantec BlueCoat are often chosen as [C2 domains](/news/penetration-basics-choosing-a-suitable-c2-domain) because they are less likely to be flagged. Tools like CatMyFish automate searching for such domains on expireddomains.net and checking their reputation via sitereview.bluecoat.com.
What detection methods can defenders use to identify password brute-force attacks on domain users?
Query the user attributes `badPwdCount` (number of bad password attempts) and `lastbadpasswordattempt` (time of last failed login). On a domain controller, use PowerShell: `Get-ADUser -Filter * -Properties * | select name,lastbadpasswordattempt,badpwdcount`. On a domain-joined host, use PowerView's `Get-NetUser | select name,badpasswordtime,badpwdcount` or a custom C++ tool using the NetUserGetInfo API. For more detection approaches, see the detection section in [Penetration Basics - Obtaining Domain User Password Policies](/news/penetration-basics-obtaining-domain-user-password-policies) and [Penetration Basics - Bypassing SSH Logs](/news/penetration-basics-bypassing-ssh-logs) for log evasion techniques.
How can an attacker outside the domain obtain the domain password policy using LDAP and valid domain credentials?
If port 389 (LDAP) on the domain controller is accessible, use a tool like ldapsearch on Kali with a known domain user's credentials. The command is: `ldapsearch -x -H ldap://DC_IP:389 -D "CN=username,CN=Users,DC=domain,DC=com" -w password -b "DC=domain,DC=com" | grep replUpToDateVector -A 13`. The output contains the raw password policy values (e.g., maxPwdAge, lockoutDuration) which you then convert. This method is covered in detail in [Penetration Basics - Obtaining Domain User Password Policies](/news/penetration-basics-obtaining-domain-user-password-policies).
What are the key password policy attributes obtained from Active Directory, and how are their raw values converted to human-readable time?
Key attributes include maxPwdAge (maximum password age), minPwdLength (minimum password length), lockoutDuration (account lockout duration), lockoutThreshold (failed attempts before lockout), and lockOutObservationWindow (reset counter time). The raw values are in 100-nanosecond intervals; to convert to seconds, divide by 10,000,000. For example, maxPwdAge of -36288000000000 equals 3628800 seconds, or 42 days. Full conversion details are in the article [Penetration Basics - Obtaining Domain User Password Policies](/news/penetration-basics-obtaining-domain-user-password-policies).
Why is it important to obtain the domain user password policy before performing a password brute-force attack?
To avoid locking out user accounts during the attack, you must first know the account lockout threshold and lockout duration. If you brute-force without this knowledge, you could exceed the threshold and lock accounts, which not only fails the attack but also alerts defenders. For more details, see [Penetration Basics - Obtaining Domain User Password Policies](/news/penetration-basics-obtaining-domain-user-password-policies) and the follow-up [Penetration Basics - Brute-Forcing Domain User Passwords via LDAP Protocol](/news/penetration-basics-brute-forcing-domain-user-passwords-via-ldap-protocol).
What alternative method does the article offer for querying Security logs besides EventLogSession, and how does it work?
The article describes using [WMI](/news/penetration-basics-obtaining-domain-user-login-information#0x03-implementation-via-wmi) via `wbemtest` or the `wmic` command to filter Event ID 4624 logs. For example, `Select * from Win32_NTLogEvent Where Logfile = 'Security' AND EventCode = 4624`. This method also supports filtering by record number and can be automated in scripts, though it requires administrative privileges.
How does the article enable remote querying of domain controller logs for user login information?
Remote log querying is achieved by creating an `EventLogSession` object with the target server name, domain, username, and password, using `SessionAuthentication.Negotiate`. This leverages RPC to read Security logs on the remote domain controller, extracting Event ID 4624 entries. The complete code is provided in the [EventLogSession remote section](/news/penetration-basics-obtaining-domain-user-login-information#5-support-remote-login).
How can you extract specific fields like TargetUserName or IpAddress from Event ID 4624 logs using EventLogSession?
The article recommends converting log entries to XML format using `eventData.ToXml()`, then parsing the XML to extract fields by fixed offset positions. For example, `data[4]` gives TargetUserSid and `data[18]` gives IpAddress. Filtering criteria include a minimum length check on these fields to isolate valid login events. This approach is detailed in the [EventLogSession implementation section](/news/penetration-basics-obtaining-domain-user-login-information#0x02-implementation-via-eventlogsession).
Why is manually filtering domain user login information from Windows Security logs inefficient, and what solution does the article propose?
Manually filtering logs for Event ID 4624 is time-consuming due to excessive irrelevant data and repeated judgments. The article automates this by developing a program using [EventLogSession](/news/penetration-basics-obtaining-domain-user-login-information) to parse logs locally or remotely via RPC, extracting key fields like IP address and timestamp.
What are the recommended methods to detect an IIS module backdoor?
Detection focuses on inspecting the list of installed modules. Using `APPCMD.EXE list module` from the command line or checking Modules in IIS Manager (inetmgr.exe) will reveal any suspicious entries. Since module DLLs reside in the w3wp.exe process, memory analysis can also identify abnormal loaded modules. Regular audits of module configurations and file integrity checks on the DLLs are effective defenses. For more on bypassing controls, see [Testing and Analysis of Bypassing AppLocker Using LUA Scripts](/news/testing-and-analysis-of-bypassing-applocker-using-lua-scripts).
How is an IIS module registered and installed on a server, and what privileges are required?
An IIS module can be registered via the APPCMD.EXE command-line tool (e.g., `APPCMD.EXE install module /name:test /image:"c:\test\IIS-Backdoor.dll" /add:true`), through the IIS Manager GUI by navigating to Modules -> Configure Native Modules -> Register, or by manually editing `applicationHost.config` or `web.config`. Administrator privileges are required for installation, as the module must be loaded into the IIS worker process. Once registered, the backdoor becomes persistent and active after an IIS restart.
What are the two primary methods for developing custom IIS modules, and what are their key characteristics?
Custom IIS modules can be developed as Native Modules using C++ and the IIS native server extensibility API, or as Managed Modules using C# (or other .NET languages) and ASP.NET server extensibility APIs. Both result in a DLL that must export the `RegisterModule` function (for C++) or implement `System.Web.IHttpModule` (for C#). Native modules offer lower-level access and are loaded directly by IIS, while managed modules run within the .NET framework and can be configured via `web.config`. The article [Bypassing Firewalls Using IIS Module Functionality](/news/bypassing-firewalls-using-iis-module-functionality) provides detailed setup steps for both approaches.
How can IIS module functionality be used to bypass firewalls and achieve remote server management?
IIS module functionality, available from IIS7 onward, allows developers to extend IIS by creating custom modules that run within the w3wp.exe process. By reading HTTP request content and controlling HTTP response content, an attacker can implement a backdoor that communicates over allowed ports (80/443) without triggering firewall rules. Tools like [IIS-Raid](https://github.com/0x09AL/IIS-Raid) demonstrate this by registering event handlers for request/response processing, enabling remote command execution and shellcode injection. This technique was previously discussed in our article on [bypassing firewalls using IIS port sharing](/news/bypassing-firewall-using-iis-port-sharing-feature).
How does avet handle shellcode encryption and remote retrieval?
avet supports self-implemented XOR-based encryption via the `-E` flag, which decodes encrypted shellcode at runtime using a `decode_shellcode` function. Additionally, it offers multiple remote retrieval methods: fetching shellcode via HTTP request to iexplore.exe, using WinAPI socket calls to pull from port 80, downloading via certutil, or via PowerShell. These techniques help evade network-based detection and allow the payload to be fetched only when needed. The tool also allows reading shellcode from a local file or using service registration for remote deployment via psexec.
What are the different shellcode execution methods used by avet?
avet provides three core shellcode execution functions: `exec_shellcode` for standard x86 shellcode using a function pointer, `exec_shellcode_ASCIIMSF` for alphanumeric shellcode using inline assembly with EAX register, and `exec_shellcode64` for 64-bit shellcode with `VirtualProtect` to set memory permissions. Each corresponds to specific `msfvenom` payload generators, such as using `x86/xor` or `x64/xor` encoders. The flexibility allows testers to choose the appropriate method for their target environment. For more on executing .NET assemblies from memory, see [Assembly.Load exploitation analysis](/news/analysis-of-exploitation-techniques-for-loading-net-assemblies-from-memory-assembly-load).