File-Unpumper - Tool That Can Be Used To Trim Useless Things From A PE File Such As The Things A File Pumper Would Add

file-unpumper is a powerful command-line utility designed to clean and analyze Portable Executable (PE) files. It provides a range of features to help developers and security professionals work with PE files more effectively.

Features

• PE Header Fixing: file-unpumper can fix and align the PE headers of a given executable file. This is particularly useful for resolving issues caused by packers or obfuscators that modify the headers.

• Resource Extraction: The tool can extract embedded resources from a PE file, such as icons, bitmaps, or other data resources. This can be helpful for reverse engineering or analyzing the contents of an executable.

• Metadata Analysis: file-unpumper provides a comprehensive analysis of the PE file's metadata, including information about the machine architecture, number of sections, timestamp, subsystem, image base, and section details.

• File Cleaning: The core functionality of file-unpumper is to remove any "pumped" or padded data from a PE file, resulting in a cleaned version of the executable. This can aid in malware analysis, reverse engineering, or simply reducing the file size.

• Parallel Processing: To ensure efficient performance, file-unpumper leverages the power of parallel processing using the rayon crate, allowing it to handle large files with ease.

• Progress Tracking: During the file cleaning process, a progress bar is displayed, providing a visual indication of the operation's progress and estimated time remaining.

Installation

file-unpumper is written in Rust and can be easily installed using the Cargo package manager:

cargo install file-unpumper

Usage

• <INPUT>: The path to the input PE file.

Options

• --fix-headers: Fix and align the PE headers of the input file.
• --extract-resources: Extract embedded resources from the input file.
• --analyze-metadata: Analyze and display the PE file's metadata.
• -h, --help: Print help information.
• -V, --version: Print version information.

Examples

1. Clean a PE file and remove any "pumped" data:

bash file-unpumper path/to/input.exe

1. Fix the PE headers and analyze the metadata of a file:

bash file-unpumper --fix-headers --analyze-metadata path/to/input.exe

1. Extract resources from a PE file:

bash file-unpumper --extract-resources path/to/input.exe

1. Perform all available operations on a file:

bash file-unpumper --fix-headers --extract-resources --analyze-metadata path/to/input.exe

Contributing

Contributions to file-unpumper are welcome! If you encounter any issues or have suggestions for improvements, please open an issue or submit a pull request on the GitHub repository.

Changelog

The latest changelogs can be found in CHANGELOG.md

License

file-unpumper is released under the MIT License.

Drs-Malware-Scan - Perform File-Based Malware Scan On Your On-Prem Servers With AWS

Perform malware scan analysis of on-prem servers using AWS services

Challenges with on-premises malware detection

It can be difficult for security teams to continuously monitor all on-premises servers due to budget and resource constraints. Signature-based antivirus alone is insufficient as modern malware uses various obfuscation techniques. Server admins may lack visibility into security events across all servers historically. Determining compromised systems and safe backups to restore from during incidents is challenging without centralized monitoring and alerting. It is onerous for server admins to setup and maintain additional security tools for advanced threat detection. The rapid mean time to detect and remediate infections is critical but difficult to achieve without the right automated solution.

Determining which backup image is safe to restore from during incidents without comprehensive threat intelligence is another hard problem. Even if backups are available, without knowing when exactly a system got compromised, it is risky to blindly restore from backups. This increases the chance of restoring malware and losing even more valuable data and systems during incident response. There is a need for an automated solution that can pinpoint the timeline of infiltration and recommend safe backups for restoration.

How to use AWS services to address these challenges

The solution leverages AWS Elastic Disaster Recovery (AWS DRS), Amazon GuardDuty and AWS Security Hub to address the challenges of malware detection for on-premises servers.

This combo of services provides a cost-effective way to continuously monitor on-premises servers for malware without impacting performance. It also helps determine safe recovery point in time backups for restoration by identifying timeline of compromises through centralized threat analytics.

• AWS Elastic Disaster Recovery (AWS DRS) minimizes downtime and data loss with fast, reliable recovery of on-premises and cloud-based applications using affordable storage, minimal compute, and point-in-time recovery.

• Amazon GuardDuty is a threat detection service that continuously monitors your AWS accounts and workloads for malicious activity and delivers detailed security findings for visibility and remediation.

• AWS Security Hub is a cloud security posture management (CSPM) service that performs security best practice checks, aggregates alerts, and enables automated remediation.

Architecture

Solution description

The Malware Scan solution assumes on-premises servers are already being replicated with AWS DRS, and Amazon GuardDuty & AWS Security Hub are enabled. The cdk stack in this repository will only deploy the boxes labelled as DRS Malware Scan in the architecture diagram.

1. AWS DRS is replicating source servers from the on-premises environment to AWS (or from any cloud provider for that matter). For further details about setting up AWS DRS please follow the Quick Start Guide.
2. Amazon GuardDuty is already enabled.
3. AWS Security Hub is already enabled.
4. The Malware Scan solution is triggered by a Schedule Rule in Amazon EventBridge (with prefix DrsMalwareScanStack-ScheduleScanRule). You can adjust the scan frequency as needed (i.e. once a day, a week, etc).
5. The Schedule Rule in Amazon EventBridge triggers the Submit Orders lambda function (with prefix DrsMalwareScanStack-SubmitOrders) which gathers the source servers to scan from the Source Servers DynamoDB table.
6. Orders are placed on the SQS FIFO queue named Scan Orders (with prefix DrsMalwareScanStack-ScanOrdersfifo). The queue is used to serialize scan requests mapped to the same DRS instance, preventing a race condition.
7. The Process Order lambda picks a malware scan order from the queue and enriches it, preparing the upcoming malware scan operation. For instance, it inserts the id of the replicating DRS instance associated to the DRS source server provided in the order. The output of Process Order are malware scan commands containing all the necessary information to invoke GuardDuty malware scan.
8. Malware scan operations are tracked using the DRSVolumeAnnotationsDDBTable at the volume-level, providing reporting capabilities.
9. Malware scan commands are inserted in the Scan Commands SQS FIFO queue (with prefix DrsMalwareScanStack-ScanCommandsfifo) to increase resiliency.
10. The Process Commands function submits queued scan commands at a maximum rate of 1 command per second to avoid API throttling. It triggers the on-demand malware scan function provided by Amazon GuardDuty.
11. The execution of the on-demand Amazon GuardDuty Malware job can be monitored from the Amazon GuardDuty service.
12. The outcome of malware scan job is routed to Amazon Cloudwath Logs.
13. The Subscription Filter lambda function receives the outcome of the scan and tracks the result using DynamoDB (step #14).
14. The DRS Instance Annotations DynamoDB Table tracks the status of the malware scan job at the instance level.
15. The CDK stack named ScanReportStack deploys the Scan Report lambda function (with prefix ScanReportStack-ScanReport) to populate the Amazon S3 bucket with prefix scanreportstack-scanreportbucket.
16. AWS Security Hub aggregates and correlates findings from Amazon GuardDuty.
17. The Security Hub finding event is caught by an EventBridge Rule (with prefix DrsMalwareScanStack-SecurityHubAnnotationsRule)
18. The Security Hub Annotations lambda function (with prefix DrsMalwareScanStack-SecurityHubAnnotation) generates additional Notes (Annotations) to the Finding with contextualized information about the source server being affected. This additional information can be seen in the Notes section within the Security Hub Finding.
19. The follow-up activities will depend on the incident response process being adopted. For example based on the date of the infection, AWS DRS can be used to perform a point in time recovery using a snapshot previous to the date of the malware infection.
20. In a Multi-Account scenario, this solution can be deployed directly on the AWS account hosting the AWS DRS solution. The Amazon GuardDuty findings will be automatically sent to the centralized Security Account.

Usage

Pre-requisites

• An AWS Account.
• Amazon Elastic Disaster Recovery (DRS) configured, with at least 1 server source in sync. If not, please check this documentation. The Replication Configuration must consider EBS encryption using Custom Managed Key (CMK) from AWS Key Management Service (AWS KMS). Amazon GuardDuty Malware Protection does not support default AWS managed key for EBS.
• IAM Privileges to deploy the components of this solution.
• Amazon GuardDuty enabled. If not, please check this documentation

• Amazon Security Hub enabled. If not, please check this documentation

  Warning
  Currently, Amazon GuardDuty Malware scan does not support EBS volumes encrypted with EBS-managed keys. If you want to use this solution to scan your on-prem (or other-cloud) servers replicated with DRS, you need to setup DRS replication with your own encryption key in KMS. If you are currently using EBS-managed keys with your replicating servers, you can change encryption settings to use your own KMS key in the DRS console.

Deploy

1. Create a Cloud9 environment with Ubuntu image (at least t3.small for better performance) in your AWS account. Open your Cloud9 environment and clone the code in this repository. Note: Amazon Linux 2 has node v16 which is not longer supported since 2023-09-11 git clone https://github.com/aws-samples/drs-malware-scan

   cd drs-malware-scan

   sh check_loggroup.sh

2. Deploy the CDK stack by running the following command in the Cloud9 terminal and confirm the deployment

   npm install cdk bootstrap cdk deploy --all Note
   The solution is made of 2 stacks: * DrsMalwareScanStack: it deploys all resources needed for malware scanning feature. This stack is mandatory. If you want to deploy only this stack you can run cdk deploy DrsMalwareScanStack
   * ScanReportStack: it deploys the resources needed for reporting (Amazon Lambda and Amazon S3). This stack is optional. If you want to deploy only this stack you can run cdk deploy ScanReportStack

   If you want to deploy both stacks you can run cdk deploy --all

Troubleshooting

All lambda functions route logs to Amazon CloudWatch. You can verify the execution of each function by inspecting the proper CloudWatch log groups for each function, look for the /aws/lambda/DrsMalwareScanStack-* pattern.

The duration of the malware scan operation will depend on the number of servers/volumes to scan (and their size). When Amazon GuardDuty finds malware, it generates a SecurityHub finding: the solution intercepts this event and runs the $StackName-SecurityHubAnnotations lambda to augment the SecurityHub finding with a note containing the name(s) of the DRS source server(s) with malware.

The SQS FIFO queues can be monitored using the Messages available and Message in flight metrics from the AWS SQS console

The DRS Volume Annotations DynamoDB tables keeps track of the status of each Malware scan operation.

Amazon GuardDuty has documented reasons to skip scan operations. For further information please check Reasons for skipping resource during malware scan

In order to analize logs from Amazon GuardDuty Malware scan operations, you can check /aws/guardduty/malware-scan-events Amazon Cloudwatch LogGroup. The default log retention period for this log group is 90 days, after which the log events are deleted automatically.

Cleanup

1. Run the following commands in your terminal:

   cdk destroy --all

2. (Optional) Delete the CloudWatch log groups associated with Lambda Functions.

AWS Cost Estimation Analysis

For the purpose of this analysis, we have assumed a fictitious scenario to take as an example. The following cost estimates are based on services located in the North Virginia (us-east-1) region.

Estimated scenario:

• 2 Source Servers to replicate (DR) (Total Storage: 100GB - 4 disks)
• 3 TB Malware Scanned/Month
• 30 days of EBS snapshot Retention period
• Daily Malware scans

Service Breakdown:

Note The figures presented here are estimates based on the assumptions described above, derived from the AWS Pricing Calculator. For further details please check this pricing calculator as a reference. You can adjust the services configuration in the referenced calculator to make your own estimation. This estimation does not include potential taxes or additional charges that might be applicable. It's crucial to remember that actual fees can vary based on usage and any additional services not covered in this analysis. For critical environments is advisable to include Business Support Plan (not considered in the estimation)

Security

See CONTRIBUTING for more information.

Authors

• Rodrigo Monge
• Thierry Francois
• Diego Pérez Holguín
• Leandro Santi

Gftrace - A Command Line Windows API Tracing Tool For Golang Binaries

A command line Windows API tracing tool for Golang binaries.

Note: This tool is a PoC and a work-in-progress prototype so please treat it as such. Feedbacks are always welcome!

How it works?

Although Golang programs contains a lot of nuances regarding the way they are built and their behavior in runtime they still need to interact with the OS layer and that means at some point they do need to call functions from the Windows API.

The Go runtime package contains a function called asmstdcall and this function is a kind of "gateway" used to interact with the Windows API. Since it's expected this function to call the Windows API functions we can assume it needs to have access to information such as the address of the function and it's parameters, and this is where things start to get more interesting.

Asmstdcall receives a single parameter which is pointer to something similar to the following structure:

struct LIBCALL {
    DWORD_PTR Addr;
    DWORD Argc;
    DWORD_PTR Argv;
    DWORD_PTR ReturnValue;

    [...]
}

Some of these fields are filled after the API function is called, like the return value, others are received by asmstdcall, like the function address, the number of arguments and the list of arguments. Regardless when those are set it's clear that the asmstdcall function manipulates a lot of interesting information regarding the execution of programs compiled in Golang.

The gftrace leverages asmstdcall and the way it works to monitor specific fields of the mentioned struct and log it to the user. The tool is capable of log the function name, it's parameters and also the return value of each Windows function called by a Golang application. All of it with no need to hook a single API function or have a signature for it.

The tool also tries to ignore all the noise from the Go runtime initialization and only log functions called after it (i.e. functions from the main package).

If you want to know more about this project and research check the blogpost.

Installation

Download the latest release.

Usage

1. Make sure gftrace.exe, gftrace.dll and gftrace.cfg are in the same directory.
2. Specify which API functions you want to trace in the gftrace.cfg file (the tool does not work without API filters applied).
3. Run gftrace.exe passing the target Golang program path as a parameter.

gftrace.exe <filepath> <params>

Configuration

All you need to do is specify which functions you want to trace in the gftrace.cfg file, separating it by comma with no spaces:

CreateFileW,ReadFile,CreateProcessW

The exact Windows API functions a Golang method X of a package Y would call in a specific scenario can only be determined either by analysis of the method itself or trying to guess it. There's some interesting characteristics that can be used to determine it, for example, Golang applications seems to always prefer to call functions from the "Wide" and "Ex" set (e.g. CreateFileW, CreateProcessW, GetComputerNameExW, etc) so you can consider it during your analysis.

The default config file contains multiple functions in which I tested already (at least most part of them) and can say for sure they can be called by a Golang application at some point. I'll try to update it eventually.

Examples

Tracing CreateFileW() and ReadFile() in a simple Golang file that calls "os.ReadFile" twice:

- CreateFileW("C:\Users\user\Desktop\doc.txt", 0x80000000, 0x3, 0x0, 0x3, 0x1, 0x0) = 0x168 (360)
- ReadFile(0x168, 0xc000108000, 0x200, 0xc000075d64, 0x0) = 0x1 (1)
- CreateFileW("C:\Users\user\Desktop\doc2.txt", 0x80000000, 0x3, 0x0, 0x3, 0x1, 0x0) = 0x168 (360)
- ReadFile(0x168, 0xc000108200, 0x200, 0xc000075d64, 0x0) = 0x1 (1)

Tracing CreateProcessW() in the TunnelFish malware:

- CreateProcessW("C:\WINDOWS\System32\WindowsPowerShell\v1.0\powershell.exe", "powershell /c "Add-PSSnapin Microsoft.Exchange.Management.PowerShell.SnapIn; Get-Recipient | Select Name -ExpandProperty EmailAddresses -first 1 | Select SmtpAddress |  ft -hidetableheaders"", 0x0, 0x0, 0x1, 0x80400, "=C:=C:\Users\user\Desktop", 0x0, 0xc0000ace98, 0xc0000acd68) = 0x1 (1)
- CreateProcessW("C:\WINDOWS\System32\WindowsPowerShell\v1.0\powershell.exe", "powershell /c "Add-PSSnapin Microsoft.Exchange.Management.PowerShell.SnapIn; Get-Recipient | Select Name -ExpandProperty EmailAddresses -first 1 | Select SmtpAddress |  ft -hidetableheaders"", 0x0, 0x0, 0x1, 0x80400, "=C:=C:\Users\user\Desktop", 0x0, 0xc0000c4ec8, 0xc0000c4d98) = 0x1 (1)
- CreateProcessW("C:\WINDOWS\System32\WindowsPowerShell\v1.0\powershell.exe", "powershell /c "Add-PSSnapin Microsoft.Exchange.Management.PowerShell.SnapIn; Get-Recipient | Select Name -ExpandProperty EmailAddresses -first 1 | Select SmtpAddres   s |  ft -hidetableheaders"", 0x0, 0x0, 0x1, 0x80400, "=C:=C:\Users\user\Desktop", 0x0, 0xc00005eec8, 0xc00005ed98) = 0x1 (1)
- CreateProcessW("C:\WINDOWS\System32\WindowsPowerShell\v1.0\powershell.exe", "powershell /c "Add-PSSnapin Microsoft.Exchange.Management.PowerShell.SnapIn; Get-Recipient | Select Name -ExpandProperty EmailAddresses -first 1 | Select SmtpAddress |  ft -hidetableheaders"", 0x0, 0x0, 0x1, 0x80400, "=C:=C:\Users\user\Desktop", 0x0, 0xc0000bce98, 0xc0000bcd68) = 0x1 (1)
- CreateProcessW("C:\WINDOWS\system32\cmd.exe", "cmd /c "wmic computersystem get domain"", 0x0, 0x0, 0x1, 0x80400, "=C:=C:\Users\user\Desktop", 0x0, 0xc0000c4ef0, 0xc0000c4dc0) = 0x1 (1)
- CreateProcessW("C:\WINDOWS\system32\cmd.exe", "cmd /c "wmic computersystem get domain"", 0x0, 0x0, 0x1, 0x80400, "=C:=C:\Users\user\Desktop", 0x0, 0xc0000acec0, 0xc0000acd90) = 0x1 (1)
- CreateProcessW("C:\WINDOWS\system32\cmd.exe", "cmd /c "wmic computersystem get domain"", 0x0, 0x0, 0x1, 0x80400,    "=C:=C:\Users\user\Desktop", 0x0, 0xc0000bcec0, 0xc0000bcd90) = 0x1 (1)

[...]

Tracing multiple functions in the Sunshuttle malware:

- CreateFileW("config.dat.tmp", 0x80000000, 0x3, 0x0, 0x3, 0x1, 0x0) = 0xffffffffffffffff (-1)
- CreateFileW("config.dat.tmp", 0xc0000000, 0x3, 0x0, 0x2, 0x80, 0x0) = 0x198 (408)
- CreateFileW("config.dat.tmp", 0xc0000000, 0x3, 0x0, 0x3, 0x80, 0x0) = 0x1a4 (420)
- WriteFile(0x1a4, 0xc000112780, 0xeb, 0xc0000c79d4, 0x0) = 0x1 (1)
- GetAddrInfoW("reyweb.com", 0x0, 0xc000031f18, 0xc000031e88) = 0x0 (0)
- WSASocketW(0x2, 0x1, 0x0, 0x0, 0x0, 0x81) = 0x1f0 (496)
- WSASend(0x1f0, 0xc00004f038, 0x1, 0xc00004f020, 0x0, 0xc00004eff0, 0x0) = 0x0 (0)
- WSARecv(0x1f0, 0xc00004ef60, 0x1, 0xc00004ef48, 0xc00004efd0, 0xc00004ef18, 0x0) = 0xffffffff (-1)
- GetAddrInfoW("reyweb.com", 0x0, 0xc000031f18, 0xc000031e88) = 0x0 (0)
- WSASocketW(0x2, 0x1, 0x0, 0x0, 0x0, 0x81) = 0x200 (512)
- WSASend(0x200, 0xc00004f2b8, 0x1, 0xc00004f2a0, 0x0, 0xc00004f270, 0x0) = 0x0 (0)
- WSARecv(0x200, 0xc00004f1e0, 0x1, 0xc00004f1c8, 0xc00004f250, 0xc00004f198, 0x0)    = 0xffffffff (-1)

[...]

Tracing multiple functions in the DeimosC2 framework agent:

- WSASocketW(0x2, 0x1, 0x0, 0x0, 0x0, 0x81) = 0x130 (304)
- setsockopt(0x130, 0xffff, 0x20, 0xc0000b7838, 0x4) = 0xffffffff (-1)
- socket(0x2, 0x1, 0x6) = 0x138 (312)
- WSAIoctl(0x138, 0xc8000006, 0xaf0870, 0x10, 0xb38730, 0x8, 0xc0000b746c, 0x0, 0x0) = 0x0 (0)
- GetModuleFileNameW(0x0, "C:\Users\user\Desktop\samples\deimos.exe", 0x400) = 0x2f (47)
- GetUserProfileDirectoryW(0x140, "C:\Users\user", 0xc0000b7a08) = 0x1 (1)
- LookupAccountSidw(0x0, 0xc00000e250, "user", 0xc0000b796c, "DESKTOP-TEST", 0xc0000b7970, 0xc0000b79f0) = 0x1 (1)
- NetUserGetInfo("DESKTOP-TEST", "user", 0xa, 0xc0000b7930) = 0x0 (0)
- GetComputerNameExW(0x5, "DESKTOP-TEST", 0xc0000b7b78) = 0x1 (1)
- GetAdaptersAddresses(0x0, 0x10, 0x0, 0xc000120000, 0xc0000b79d0) = 0x0 (0)
- CreateToolhelp32Snapshot(0x2, 0x0) = 0x1b8 (440)
- GetCurrentProcessId() = 0x2584 (9604)
- GetCurrentDirectoryW(0x12c, "C:\Users\user\AppData\Local\Programs\retoolkit\bin") = 0x39 (57   )

[...]

Future features:

• [x] Support inspection of 32 bits files.
• [x] Add support to files calling functions via the "IAT jmp table" instead of the API call directly in asmstdcall.
• [x] Add support to cmdline parameters for the target process
• [ ] Send the tracing log output to a file by default to make it better to filter. Currently there's no separation between the target file and gftrace output. An alternative is redirect gftrace output to a file using the command line.

:warning: Warning

• The tool inspects the target binary dynamically and it means the file being traced is executed. If you're inspecting a malware or an unknown software please make sure you do it in a controlled environment.
• Golang programs can be very noisy depending the file and/or function being traced (e.g. VirtualAlloc is always called multiple times by the runtime package, CreateFileW is called multiple times before a call to CreateProcessW, etc). The tool ignores the Golang runtime initialization noise but after that it's up to the user to decide what functions are better to filter in each scenario.

License

The gftrace is published under the GPL v3 License. Please refer to the file named LICENSE for more information.

CrimsonEDR - Simulate The Behavior Of AV/EDR For Malware Development Training

CrimsonEDR is an open-source project engineered to identify specific malware patterns, offering a tool for honing skills in circumventing Endpoint Detection and Response (EDR). By leveraging diverse detection methods, it empowers users to deepen their understanding of security evasion tactics.

Features

Installation

To get started with CrimsonEDR, follow these steps:

1. Install dependancy: bash sudo apt-get install gcc-mingw-w64-x86-64
2. Clone the repository: bash git clone https://github.com/Helixo32/CrimsonEDR
3. Compile the project: bash cd CrimsonEDR; chmod +x compile.sh; ./compile.sh

⚠️ Warning

Windows Defender and other antivirus programs may flag the DLL as malicious due to its content containing bytes used to verify if the AMSI has been patched. Please ensure to whitelist the DLL or disable your antivirus temporarily when using CrimsonEDR to avoid any interruptions.

Usage

To use CrimsonEDR, follow these steps:

1. Make sure the ioc.json file is placed in the current directory from which the executable being monitored is launched. For example, if you launch your executable to monitor from C:\Users\admin\, the DLL will look for ioc.json in C:\Users\admin\ioc.json. Currently, ioc.json contains patterns related to msfvenom. You can easily add your own in the following format:

{
  "IOC": [
    ["0x03", "0x4c", "0x24", "0x08", "0x45", "0x39", "0xd1", "0x75"],
    ["0xf1", "0x4c", "0x03", "0x4c", "0x24", "0x08", "0x45", "0x39"],
    ["0x58", "0x44", "0x8b", "0x40", "0x24", "0x49", "0x01", "0xd0"],
    ["0x66", "0x41", "0x8b", "0x0c", "0x48", "0x44", "0x8b", "0x40"],
    ["0x8b", "0x0c", "0x48", "0x44", "0x8b", "0x40", "0x1c", "0x49"],
    ["0x01", "0xc1", "0x38", "0xe0", "0x75", "0xf1", "0x4c", "0x03"],
    ["0x24", "0x49", "0x01", "0xd0", "0x66", "0x41", "0x8b", "0x0c"],
    ["0xe8", "0xcc", "0x00", "0x00", "0x00", "0x41", "0x51", "0x41"]
  ]
}

1. Execute CrimsonEDRPanel.exe with the following arguments:

   • -d <path_to_dll>: Specifies the path to the CrimsonEDR.dll file.

   • -p <process_id>: Specifies the Process ID (PID) of the target process where you want to inject the DLL.

For example:

.\CrimsonEDRPanel.exe -d C:\Temp\CrimsonEDR.dll -p 1234

Useful Links

Here are some useful resources that helped in the development of this project:

• Windows Processes, Nefarious Anomalies, and You
• MalDev Academy

Contact

For questions, feedback, or support, please reach out to me via:

• Discord : helixo32
• LinkedIn : Matthias Ossard

Toolkit - The Essential Toolkit For Reversing, Malware Analysis, And Cracking

This tool compilation is carefully crafted with the purpose of being useful both for the beginners and veterans from the malware analysis world. It has also proven useful for people trying their luck at the cracking underworld.

It's the ideal complement to be used with the manuals from the site, and to play with the numbered theories mirror.

Advantages

To be clear, this pack is thought to be the most complete and robust in existence. Some of the pros are:

1. It contains all the basic (and not so basic) tools that you might need in a real life scenario, be it a simple or a complex one.

2. The pack is integrated with an Universal Updater made by us from scratch. Thanks to that, we get to mantain all the tools in an automated fashion.

3. It's really easy to expand and modify: you just have to update the file bin\updater\tools.ini to integrate the tools you use to the updater, and then add the links for your tools to bin\sendto\sendto, so they appear in the context menus.

4. The installer sets up everything we might need automatically - everything, from the dependencies to the environment variables, and it can even add a scheduled task to update the whole pack of tools weekly.

Installation

1. You can simply download the stable versions from the release section, where you can also find the installer.

2. Once downloaded, you can update the tools with the Universal Updater that we specifically developed for that sole purpose.
   You will find the binary in the folder bin\updater\updater.exe.

Tool set

This toolkit is composed by 98 apps that cover everything we might need to perform reverse engineering and binary/malware analysis.
Every tool has been downloaded from their original/official websites, but we still recommend you to use them with caution, specially those tools whose official pages are forum threads. Always exercise common sense.
You can check the complete list of tools here.

About contributions

Pull Requests are welcome. If you'd want to propose big changes, you should first create an Issue about it, so we all can analyze and discuss it. The tools are compressed with 7-zip, and the format used for nomenclature is {name} - {version}.7z

Drozer - The Leading Security Assessment Framework For Android

drozer (formerly Mercury) is the leading security testing framework for Android.

drozer allows you to search for security vulnerabilities in apps and devices by assuming the role of an app and interacting with the Dalvik VM, other apps' IPC endpoints and the underlying OS.

drozer provides tools to help you use, share and understand public Android exploits. It helps you to deploy a drozer Agent to a device through exploitation or social engineering. Using weasel (WithSecure's advanced exploitation payload) drozer is able to maximise the permissions available to it by installing a full agent, injecting a limited agent into a running process, or connecting a reverse shell to act as a Remote Access Tool (RAT).

drozer is a good tool for simulating a rogue application. A penetration tester does not have to develop an app with custom code to interface with a specific content provider. Instead, drozer can be used with little to no programming experience required to show the impact of letting certain components be exported on a device.

drozer is open source software, maintained by WithSecure, and can be downloaded from: https://labs.withsecure.com/tools/drozer/

Docker Container

To help with making sure drozer can be run on modern systems, a Docker container was created that has a working build of Drozer. This is currently the recommended method of using Drozer on modern systems.

• The Docker container and basic setup instructions can be found here.
• Instructions on building your own Docker container can be found here.

Manual Building and Installation

Prerequisites

1. Python2.7

Note: On Windows please ensure that the path to the Python installation and the Scripts folder under the Python installation are added to the PATH environment variable.

1. Protobuf 2.6 or greater

2. Pyopenssl 16.2 or greater

3. Twisted 10.2 or greater

4. Java Development Kit 1.7

Note: On Windows please ensure that the path to javac.exe is added to the PATH environment variable.

1. Android Debug Bridge

Building Python wheel

git clone https://github.com/WithSecureLabs/drozer.git
cd drozer
python setup.py bdist_wheel

Installing Python wheel

sudo pip install dist/drozer-2.x.x-py2-none-any.whl

Building for Debian/Ubuntu/Mint

git clone https://github.com/WithSecureLabs/drozer.git
cd drozer
make deb

Installing .deb (Debian/Ubuntu/Mint)

sudo dpkg -i drozer-2.x.x.deb

Building for Redhat/Fedora/CentOS

git clone https://github.com/WithSecureLabs/drozer.git
cd drozer
make rpm

Installing .rpm (Redhat/Fedora/CentOS)

sudo rpm -I drozer-2.x.x-1.noarch.rpm

Building for Windows

NOTE: Windows Defender and other Antivirus software will flag drozer as malware (an exploitation tool without exploit code wouldn't be much fun!). In order to run drozer you would have to add an exception to Windows Defender and any antivirus software. Alternatively, we recommend running drozer in a Windows/Linux VM.

git clone https://github.com/WithSecureLabs/drozer.git
cd drozer
python.exe setup.py bdist_msi

Installing .msi (Windows)

Run dist/drozer-2.x.x.win-x.msi 

Usage

Installing the Agent

Drozer can be installed using Android Debug Bridge (adb).

Download the latest Drozer Agent here.

$ adb install drozer-agent-2.x.x.apk

Starting a Session

You should now have the drozer Console installed on your PC, and the Agent running on your test device. Now, you need to connect the two and you're ready to start exploring.

We will use the server embedded in the drozer Agent to do this.

If using the Android emulator, you need to set up a suitable port forward so that your PC can connect to a TCP socket opened by the Agent inside the emulator, or on the device. By default, drozer uses port 31415:

$ adb forward tcp:31415 tcp:31415

Now, launch the Agent, select the "Embedded Server" option and tap "Enable" to start the server. You should see a notification that the server has started.

Then, on your PC, connect using the drozer Console:

On Linux:

$ drozer console connect

On Windows:

> drozer.bat console connect

If using a real device, the IP address of the device on the network must be specified:

On Linux:

$ drozer console connect --server 192.168.0.10

On Windows:

> drozer.bat console connect --server 192.168.0.10

You should be presented with a drozer command prompt:

selecting f75640f67144d9a3 (unknown sdk 4.1.1)  
dz>

The prompt confirms the Android ID of the device you have connected to, along with the manufacturer, model and Android software version.

You are now ready to start exploring the device.

Command Reference

License

drozer is released under a 3-clause BSD License. See LICENSE for full details.

Contacting the Project

drozer is Open Source software, made great by contributions from the community.

Bug reports, feature requests, comments and questions can be submitted here.

C2-Search-Netlas - Search For C2 Servers Based On Netlas

C2 Search Netlas is a Java utility designed to detect Command and Control (C2) servers using the Netlas API. It provides a straightforward and user-friendly CLI interface for searching C2 servers, leveraging the Netlas API to gather data and process it locally.

Usage

To utilize this terminal utility, you'll need a Netlas API key. Obtain your key from the Netlas website.

After acquiring your API key, execute the following command to search servers:

c2detect -t <TARGET_DOMAIN> -p <TARGET_PORT> -s <API_KEY> [-v]

Replace <TARGET_DOMAIN> with the desired IP address or domain, <TARGET_PORT> with the port you wish to scan, and <API_KEY> with your Netlas API key. Use the optional -v flag for verbose output. For example, to search at the google.com IP address on port 443 using the Netlas API key 1234567890abcdef, enter:

c2detect -t google.com -p 443 -s 1234567890abcdef

Release

To download a release of the utility, follow these steps:

• Visit the repository's releases page on GitHub.
• Download the latest release file (typically a JAR file) to your local machine.
• In a terminal, navigate to the directory containing the JAR file.
• Execute the following command to initiate the utility:

java -jar c2-search-netlas-<version>.jar -t <ip-or-domain> -p <port> -s <your-netlas-api-key>

Docker

To build and start the Docker container for this project, run the following commands:

docker build -t c2detect .
docker run -it --rm \
  c2detect \
  -s "your_api_key" \
  -t "your_target_domain" \
  -p "your_target_port" \
  -v

Source

To use this utility, you need to have a Netlas API key. You can get the key from the Netlas website. Now you can build the project and run it using the following commands:

./gradlew build
java -jar app/build/libs/c2-search-netlas-1.0-SNAPSHOT.jar --help

This will display the help message with available options. To search for C2 servers, run the following command:

java -jar app/build/libs/c2-search-netlas-1.0-SNAPSHOT.jar -t <ip-or-domain> -p <port> -s <your-netlas-api-key>

This will display a list of C2 servers found in the given IP address or domain.

Support

Legend:

• ✅ - Accept/good support
• ❓ - Support unknown/unclear
• ❌ - No support/poor support

Contributing

If you'd like to contribute to this project, please feel free to create a pull request.

License

This project is licensed under the License - see the LICENSE file for details.

Crawlector - Threat Hunting Framework Designed For Scanning Websites For Malicious Objects

Crawlector (the name Crawlector is a combination of Crawler & Detector) is a threat hunting framework designed for scanning websites for malicious objects.

Note-1: The framework was first presented at the No Hat conference in Bergamo, Italy on October 22nd, 2022 (Slides, YouTube Recording). Also, it was presented for the second time at the AVAR conference, in Singapore, on December 2nd, 2022.

Note-2: The accompanying tool EKFiddle2Yara (is a tool that takes EKFiddle rules and converts them into Yara rules) mentioned in the talk, was also released at both conferences.

Features

• Supports spidering websites for findings additional links for scanning (up to 2 levels only)
• Integrates Yara as a backend engine for rule scanning
• Supports online and offline scanning
• Supports crawling for domains/sites digital certificate
• Supports querying URLhaus for finding malicious URLs on the page
• Supports hashing the page's content with TLSH (Trend Micro Locality Sensitive Hash), and other standard cryptographic hash functions such as md5, sha1, sha256, and ripemd128, among others
  • TLSH won't return a value if the page size is less than 50 bytes or not "enough amount of randomness" is present in the data
• Supports querying the rating and category of every URL
• Supports expanding on a given site, by attempting to find all available TLDs and/or subdomains for the same domain
  • This feature uses the Omnisint Labs API (this site is down as of March 10, 2023) and RapidAPI APIs
  • TLD expansion implementation is native
  • This feature along with the rating and categorization, provides the capability to find scam/phishing/malicious domains for the original domain
• Supports domain resolution (IPv4 and IPv6)
• Saves scanned websites pages for later scanning (can be saved as a zip compressed)
• The entirety of the framework’s settings is controlled via a single customizable configuration file
• All scanning sessions are saved into a well-structured CSV file with a plethora of information about the website being scanned, in addition to information about the Yara rules that have triggered
• All HTTP(S) communications are proxy-aware
• One executable
• Written in C++

URLHaus Scanning & API Integration

This is for checking for malicious urls against every page being scanned. The framework could either query the list of malicious URLs from URLHaus server (configuration: url_list_web), or from a file on disk (configuration: url_list_file), and if the latter is specified, then, it takes precedence over the former.

It works by searching the content of every page against all URL entries in url_list_web or url_list_file, checking for all occurrences. Additionally, upon a match, and if the configuration option check_url_api is set to true, Crawlector will send a POST request to the API URL set in the url_api configuration option, which returns a JSON object with extra information about a matching URL. Such information includes urlh_status (ex., online, offline, unknown), urlh_threat (ex., malware_download), urlh_tags (ex., elf, Mozi), and urlh_reference (ex., https://urlhaus.abuse.ch/url/1116455/). This information will be included in the log file cl_mlog_<current_date><current_time><(pm|am)>.csv (check below), only if check_url_api is set to true. Otherwise, the log file will include the columns urlh_url (list o f matching malicious URLs) and urlh_hit (number of occurrences for every matching malicious URL), conditional on whether check_url is set to true.

URLHaus feature could be disabled in its entirety by setting the configuration option check_url to false.

It is important to note that this feature could slow scanning considering the huge number of malicious urls (~ 130 million entries at the time of this writing) that need to be checked, and the time it takes to get extra information from the URLHaus server (if the option check_url_api is set to true).

Files and Folders Structures

1. \cl_sites
   • this is where the list of sites to be visited or crawled is stored.
   • supports multiple files and directories.
2. \crawled
   • where all crawled/spidered URLs are saved to a text file.
3. \certs
   • where all domains/sites digital certificates are stored (in .der format).
4. \results
   • where visited websites are saved.
5. \pg_cache
   • program cache for sites that are not part of the spider functionality.
6. \cl_cache
   • crawler cache for sites that are part of the spider functionality.
7. \yara_rules
   • this is where all Yara rules are stored. All rules that exist in this directory will be loaded by the engine, parsed, validated, and evaluated before execution.
8. cl_config.ini
   • this file contains all the configuration parameters that can be adjusted to influence the behavior of the framework.
9. cl_mlog_<current_date><current_time><(pm|am)>.csv
   • log file that contains a plethora of information about visited websites
   • date, time, the status of Yara scanning, list of fired Yara rules with the offsets and lengths of each of the matches, id, URL, HTTP status code, connection status, HTTP headers, page size, the path to a saved page on disk, and other columns related to URLHaus results.
   • file name is unique per session.
10. cl_offl_mlog_<current_date><current_time><(pm|am)>.csv
    • log file that contains information about files scanned offline.
    • list of fired Yara rules with the offsets and lengths of the matches, and path to a saved page on disk.
    • file name is unique per session.
11. cl_certs_<current_date><current_time><(pm|am)>.csv
    • log file that contains a plethora of information about found digital certificates
12. \expanded\exp_subdomain_<pm|am>.txt
    • contains discovered subdomains (part of the [site] section)
13. \expanded\exp_tld_<pm|am>.txt
    • contains discovered domains (part of the [site] section)

Configuration File (cl_config.ini)

It is very important that you familiarize yourself with the configuration file cl_config.ini before running any session. All of the sections and parameters are documented in the configuration file itself.

The Yara offline scanning feature is a standalone option, meaning, if enabled, Crawlector will execute this feature only irrespective of other enabled features. And, the same is true for the crawling for domains/sites digital certificate feature. Either way, it is recommended that you disable all non-used features in the configuration file.

• Depending on the configuration settings (log_to_file or log_to_cons), if a Yara rule references only a module's attributes (ex., PE, ELF, Hash, etc...), then Crawlector will display only the rule's name upon a match, excluding offset and length data.

Sites Format Pattern

To visit/scan a website, the list of URLs must be stored in text files, in the directory “cl_sites”.

Crawlector accepts three types of URLs:

1. Type 1: one URL per line
   • Crawlector will assign a unique name to every URL, derived from the URL hostname
2. Type 2: one URL per line, with a unique name [a-zA-Z0-9_-]{1,128} = <url>
3. Type 3: for the spider functionality, a unique format is used. One URL per line is as follows:

<id>[depth:<0|1>-><\d+>,total:<\d+>,sleep:<\d+>] = <url>

For example,

mfmokbel[depth:1->3,total:10,sleep:0] = https://www.mfmokbel.com

which is equivalent to: mfmokbel[d:1->3,t:10,s:0] = https://www.mfmokbel.com

where, <id> := [a-zA-Z0-9_-]{1,128}

depth, total and sleep, can also be replaced with their shortened versions d, t and s, respectively.

• depth: the spider supports going two levels deep for finding additional URLs (this is a design decision).
• A value of 0 indicates a depth of level 1, with the value that comes after the “->” ignored.
• A depth of level-1 is controlled by the total parameter. So, first, the spider tries to find that many additional URLs off of the specified URL.
• The value after the “->” represents the maximum number of URLs to spider for each of the URLs found (as per the total parameter value).
• A value of 1, indicates a depth of level 2, with the value that comes after the “->” representing the maximum number of URLs to find, for every URL found per the total parameter. For clarification, and as shown in the example above, first, the spider will look for 10 URLs (as specified in the total parameter), and then, each of those found URLs will be spidered up to a max of 3 URLs; therefore, and in the best-case scenario, we would end up with 40 (10 + (10*3)) URLs.
• The sleep parameter takes an integer value representing the number of milliseconds to sleep between every HTTP request.

Note 1: Type 3 URL could be turned into type 1 URL by setting the configuration parameter live_crawler to false, in the configuration file, in the spider section.

Note 2: Empty lines and lines that start with “;” or “//” are ignored.

The Spider Functionality

The spider functionality is what gives Crawlector the capability to find additional links on the targeted page. The Spider supports the following featuers:

• The domain has to be of Type 3, for the Spider functionality to work
• You may specify a list of wildcarded patterns (pipe delimited) to prevent spidering matching urls via the exclude_url config. option. For example, *.zip|*.exe|*.rar|*.zip|*.7z|*.pdf|.*bat|*.db
• You may specify a list of wildcarded patterns (pipe delimited) to spider only urls that match the pattern via the include_url config. option. For example, */checkout/*|*/products/*
• You may exclude HTTPS urls via the config. option exclude_https
• You may account for outbound/external links as well, for the main page only, via the config. option add_ext_links. This feature honours the exclude_url and include_url config. option.
• You may account for outbound/external links of the main page only, excluding all other urls, via the config. option ext_links_only. This feature honours the exclude_url and include_url config. option.

Site Ranking Functionality

• This is for checking the ranking of the website
• You give it a file with a list of websites, with their ranking, in a csv file format
• Services that provide lists of websites ranking include, Alexa top-1m (discontinued as of May 2022), Cisco Umbrella, Majestic, Quantcast, Farsight and Tranco, among others
• CSV file format (2 columns only): first column holds the ranking, and the second column holds the domain name
• If a cell to contain quoted data, it'll be automatically dequoted
• Line breaks aren't allowed in quoted text
• Leading and trailing spaces are trimmed from cells read
• Empty and comment lines are skipped
• The section site_ranking in the configuration file provides some options to alter how the CSV file is to be read
• The performance of this query is dependent on the number of records in the CSV file
• Crawlector compares every entry in the CSV file against the domain being investigated, and not the other way around
• Only the registered/pay-level domain is compared

Finding TLDs and Subdomains - [site] Section

• The site section provides the capability to expand on a given site, by attempting to find all available top-level domains (TLDs) and/or subdomains for the same domain. If found, new tlds/subdomains will be checked like any other domain
• This feature uses the Omnisint Labs (https://omnisint.io/) and RapidAPI APIs
• Omnisint Labs API returns subdomains and tlds, whereas RapidAPI returns only subdomains (the Omnisint Labs API is down as of March 10, 2023, however, the implementation is still available in case the site is back up)
• For RapidAPI, you need a valid "Domains records" API key that you can request from RapidAPI, and plug it into the key rapid_api_key in the configuration file
• With find_tlds enabled, in addition to Omnisint Labs API tlds results, the framework attempts to find other active/registered domains by going through every tld entry, either, in the tlds_file or tlds_url
• If tlds_url is set, it should point to a url that hosts tlds, each one on a new line (lines that start with either of the characters ';', '#' or '//' are ignored)
• tlds_file, holds the filename that contains the list of tlds (same as for tlds_url; only the tld is present, excluding the '.', for ex., "com", "org")
• If tlds_file is set, it takes precedence over tlds_url
• tld_dl_time_out, this is for setting the maximum timeout for the dnslookup function when attempting to check if the domain in question resolves or not
• tld_use_connect, this option enables the functionality to connect to the domain in question over a list of ports, defined in the option tlds_connect_ports
• The option tlds_connect_ports accepts a list of ports, comma separated, or a list of ranges, such as 25-40,90-100,80,443,8443 (range start and end are inclusive)
  • tld_con_time_out, this is for setting the maximum timeout for the connect function
• tld_con_use_ssl, enable/disable the use of ssl when attempting to connect to the domain
• If save_to_file_subd is set to true, discovered subdomains will be saved to "\expanded\exp_subdomain_<pm|am>.txt"
• If save_to_file_tld is set to true, discovered domains will be saved to "\expanded\exp_tld_<pm|am>.txt"
• If exit_here is set to true, then Crawlector bails out after executing this [site] function, irrespective of other enabled options. It means found sites won't be crawled/spidered

Design Considerations

• A URL page is retrieved by sending a GET request to the server, reading the server response body, and passing it to Yara engine for detection.
• Some of the GET request attributes are defined in the [default] section in the configuration file, including, the User-Agent and Referer headers, and connection timeout, among other options.
• Although Crawlector logs a session's data to a CSV file, converting it to an SQL file is recommended for better performance, manipulation and retrieval of the data. This becomes evident when you’re crawling thousands of domains.
• Repeated domains/urls in the cl_sites are allowed.

Limitations

• Single threaded
• Static detection (no dynamic evaluation of a given page's content)
• No headless browser support, yet!

Third-party libraries used

• Chilkat: library for website spidering, HTTP communications, hashing, JSON parsing and file compression (ZIP), among others
• Yara: for rule scanning (v4.2.3)
• CrossGuid: for generating GUID/UUID
• Inih: for parsing configuration file
• Rapidcsv: for parsing CSV files
• Color Console: for console coloring
• TLSH (Trend Micro Locality Sensitive Hash) (v4.8.2)

Contributing

Open for pull requests and issues. Comments and suggestions are greatly appreciated.

Author

Mohamad Mokbel (@MFMokbel)

Tiny_Tracer - A Pin Tool For Tracing API Calls Etc

A Pin Tool for tracing:

• API calls, including parameters of selected functions
• selected instructions: RDTSC, CPUID, INT
• inline system calls, including parameters of selected syscalls
• transition between sections of the traced module (helpful in finding OEP of the packed module)

Bypasses the anti-tracing check based on RDTSC.

Generates a report in a .tag format (which can be loaded into other analysis tools):

RVA;traced event

i.e.

345c2;section: .text
58069;called: C:\Windows\SysWOW64\kernel32.dll.IsProcessorFeaturePresent
3976d;called: C:\Windows\SysWOW64\kernel32.dll.LoadLibraryExW
3983c;called: C:\Windows\SysWOW64\kernel32.dll.GetProcAddress
3999d;called: C:\Windows\SysWOW64\KernelBase.dll.InitializeCriticalSectionEx
398ac;called: C:\Windows\SysWOW64\KernelBase.dll.FlsAlloc
3995d;called: C:\Windows\SysWOW64\KernelBase.dll.FlsSetValue
49275;called: C:\Windows\SysWOW64\kernel32.dll.LoadLibraryExW
4934b;called: C:\Windows\SysWOW64\kernel32.dll.GetProcAddress
...

How to build

On Windows

To compile the prepared project you need to use Visual Studio >= 2012. It was tested with Intel Pin 3.28.
Clone this repo into \source\tools that is inside your Pin root directory. Open the project in Visual Studio and build. Detailed description available here.
To build with Intel Pin < 3.26 on Windows, use the appropriate legacy Visual Studio project.

On Linux

For now the support for Linux is experimental. Yet it is possible to build and use Tiny Tracer on Linux as well. Please refer tiny_runner.sh for more information. Detailed description available here.

Usage

 Details about the usage you will find on the project's Wiki.

WARNINGS

• In order for Pin to work correctly, Kernel Debugging must be DISABLED.
• In install32_64 you can find a utility that checks if Kernel Debugger is disabled (kdb_check.exe, source), and it is used by the Tiny Tracer's .bat scripts. This utilty sometimes gets flagged as a malware by Windows Defender (it is a known false positive). If you encounter this issue, you may need to exclude the installation directory from Windows Defender scans.
• Since the version 3.20 Pin has dropped a support for old versions of Windows. If you need to use the tool on Windows < 8, try to compile it with Pin 3.19.

Questions? Ideas? Join Discussions!

Trawler - PowerShell Script To Help Incident Responders Discover Adversary Persistence Mechanisms

Dredging Windows for Persistence

What is it?

Trawler is a PowerShell script designed to help Incident Responders discover potential indicators of compromise on Windows hosts, primarily focused on persistence mechanisms including Scheduled Tasks, Services, Registry Modifications, Startup Items, Binary Modifications and more.

Currently, trawler can detect most of the persistence techniques specifically called out by MITRE and Atomic Red Team with more detections being added on a regular basis.

Main Features

• Scanning Windows OS for a variety of persistence techniques (Listed below)
• CSV Output with MITRE Technique and Investigation Jumpstart Metadata
• Analysis and Remediation Guidance Documentation (https://github.com/joeavanzato/Trawler/wiki/Analysis-and-Remediation-Guidance)
• Dynamic Risk Assignment for each detection
• Built-in Allow Lists for common Windows configurations spanning Windows 10/Server 2012|2016|2019|2022 to reduce noise
• Capture persistence metadata from 'golden' enterprise image for use as a dynamic allow-list at runtime
• Analyze mounted disk images via drive re-targeting

How do I use it?

Just download and run trawler.ps1 from an Administrative PowerShell/cmd prompt - any detections will be displayed in the console as well as written to a CSV ('detections.csv') in the current working directory. The generated CSV will contain Detection Name, Source, Risk, Metadata and the relevant MITRE Technique.

Or use this one-liner from an Administrative PowerShell terminal:

iex ((New-Object System.Net.WebClient).DownloadString('https://raw.githubusercontent.com/joeavanzato/Trawler/main/trawler.ps1'))

Certain detections have allow-lists built-in to help remove noise from default Windows configurations (10/2016/2019/2022) - expected Scheduled Tasks, Services, etc. Of course, it is always possible for attackers to hijack these directly and masquerade with great detail as a default OS process - take care to use multiple forms of analysis and detection when dealing with skillful adversaries.

If you have examples or ideas for additional detections, please feel free to submit an Issue or PR with relevant technical details/references - the code-base is a little messy right now and will be cleaned up over time.

Additionally, if you identify obvious false positives, please let me know by opening an issue or PR on GitHub! The obvious culprits for this will be non-standard COMs, Services or Tasks.

CLI Parameters

-scanoptions : Tab-through possible detections and select a sub-set using comma-delimited terms (eg. .\trawler.ps1 -scanoptions Services,Processes)
-hide : Suppress Detection output to console
-snapshot : Capture a "persistence snapshot" of the current system, defaulting to "$PSScriptRoot\snapshot.csv"
-snapshotpath : Define a custom file-path for saving snapshot output to.
-outpath : Define a custom file-path for saving detection output to (defaults to "$PSScriptRoot\detections.csv")
-loadsnapshot : Define the path for an existing snapshot file to load as an allow-list reference
-drivetarget : Define the variable for a mounted target drive (eg. .\trawler.ps1 -targetdrive "D:") - using this alone leads to an 'assumed homedrive' variable of C: for analysis purposes

What separates this from PersistenceSniper?

PersistenceSniper is an awesome tool - I've used it heavily in the past - but there are a few key points that differentiate these utilities

• trawler is (currently) a local utility - it would be pretty straight-forward to wrap it in a loop and use WinRM/PowerShell Sessions to execute it on remote hosts though
• trawler implements allow-listing for many 'noisy' detections to help remove expected detections from default configurations of Windows (10/2016/2019/2022) and these are constantly being updated
  • PersistenceSniper (for the most part) does not contain any type of allow-listing - therefore, there is more noise generated when considering items such as Services, Scheduled Tasks, general COM DLL scanning, etc.
• trawler's output is much more simplified - Name, Risk, Source, MITRE Technique and Metadata are the only items provided for each detection to help analysts jump-start their persistence hunting efforts
• Regex is used in many checks to help detect 'suspicious' keywords or patterns in various critical areas including scanned file contents, registry values, etc.
• trawler supports 'snapshotting' a system (for example, an enterprise golden image) then using the generated snapshot as an allow-list to reduce noise.
• trawler supports 'drive-retargeting' to check dead-boxes mounted to an analysis machine.

Overall, these tools are extremely similar but approach the problem from slightly different angles - PersistenceSniper provides all information back to the analyst for review while Trawler tries to limit what is returned to only results that are likely to be potential adversary persistence mechanisms. As such, there is a possibility for false-negatives with trawler if an adversary completely mimics an allow-listed item.

Tuning to your environment

Trawler supports loading an allow-list from a 'snapshot' - to do this requires two steps.

1. Run '.\trawler.ps1 -snapshot' on a "Golden Image" representing the servers in your environment - once complete, in addition to the standard 'detections.csv' a file named 'snapshots.csv' will be generated
2. This file can then be used as input to trawler when running on other hosts and the data will be loaded dynamically as an allow-list for each appropriate detection
   1. '.\trawler.ps1' -loadsnapshot "path\to\snapshot.csv"

That's it - all relevant detections will then draw from the snapshot file as an allow-list to reduce noise and identify any potential changes to the base image that may have occurred.

(Allow-listing is implemented for most of the checks but not all - still being actively implemented)

Drive ReTargeting

Often during an investigation, analysts may end up mounting a new drive that represents an imaged Windows device - Trawler now partially supports scanning these mounted drives through the use of the '-drivetarget' parameter.

At runtime, Trawler will re-target temporary script-level variables for use in checking file-based artifacts and also will attempt to load relevant Registry Hives (HKLM\SOFTWARE, HKLM\SYSTEM, NTUSER.DATs, USRCLASS.DATs) underneath HKLM/HKU and prefixed by 'ANALYSIS_'. Trawler will also attempt to unload these temporarily loaded hives upon script completion.

As an example, if you have an image mounted at a location such as 'F:\Test' which contains the NTFS file system ('F:\Test\Windows', 'F:\Test\User', etc) then you can invoke trawler like below;

.\trawler.ps1 -drivetarget "F:\Test"

Please note that since trawler attempts to load the registry hive files from the drive in question, mapping a UNC path to a live remote device will NOT work as those files will not be accessible due to system locks. I am working on an approach which will handle live remote devices, stay tuned.

What is not inspected when drive retargeting?

• Running Processes
• Network Connections
• 'Phantom' DLLs
• WMI Consumers (Being worked on)
• BITS Jobs (Being worked on)
• Certificate Parsing (Being worked on)

Most other checks will function fine because they are based entirely on reading registry hives or file-based artifacts (or can be converted to do so, such as directly reading Task XML as opposed to using built-in command-lets.)

Any limitations in checks when doing drive-retargeting will be discussed more fully in the GitHub Wiki.

Example Images 

What is inspected?

• Scheduled Tasks
• Users
• Services
• Running Processes
• Network Connections
• WMI Event Consumers (CommandLine/Script)
• Startup Item Discovery
• BITS Jobs Discovery
• Windows Accessibility Feature Modifications
• PowerShell Profile Existence
• Office Addins from Trusted Locations
• SilentProcessExit Monitoring
• Winlogon Helper DLL Hijacking
• Image File Execution Option Hijacking
• RDP Shadowing
• UAC Setting for Remote Sessions
• Print Monitor DLLs
• LSA Security and Authentication Package Hijacking
• Time Provider DLLs
• Print Processor DLLs
• Boot/Logon Active Setup
• User Initialization Logon Script Hijacking
• ScreenSaver Executable Hijacking
• Netsh DLLs
• AppCert DLLs
• AppInit DLLs
• Application Shimming
• COM Object Hijacking
• LSA Notification Hijacking
• 'Office test' Usage
• Office GlobalDotName Usage
• Terminal Services DLL Hijacking
• Autodial DLL Hijacking
• Command AutoRun Processor Abuse
• Outlook OTM Hijacking
• Trust Provider Hijacking
• LNK Target Scanning (Suspicious Terms, Multiple Extensions, Multiple EXEs)
• 'Phantom' Windows DLL Names loaded into running process (eg. un-signed WptsExtensions.dll)
• Scanning Critical OS Directories for Unsigned EXEs/DLLs
• Un-Quoted Service Path Hijacking
• PATH Binary Hijacking
• Common File Association Hijacks and Suspicious Keywords
• Suspicious Certificate Hunting
• GPO Script Discovery/Scanning
• NLP Development Platform DLL Overrides
• AeDebug/.NET/Script/Process/WER Debug Replacements
• Explorer 'Load'
• Windows Terminal startOnUserLogin Hijacks
• App Path Mismatches
• Service DLL/ImagePath Mismatches
• GPO Extension DLLs
• Potential COM Hijacks
• Non-Standard LSA Extensions
• DNSServerLevelPluginDll Presence
• Explorer\MyComputer Utility Hijack
• Terminal Services InitialProgram Check
• RDP Startup Programs
• Microsoft Telemetry Commands
• Non-Standard AMSI Providers
• Internet Settings LUI Error DLL
• PeerDist\Extension DLL
• ErrorHandler.CMD Checks
• Built-In Diagnostics DLL
• MiniDumpAuxiliary DLLs
• KnownManagedDebugger DLLs
• WOW64 Compatibility Layer DLLs
• EventViewer MSC Hijack
• Uninstall Strings Scan
• PolicyManager DLLs
• SEMgr Wallet DLL
• WER Runtime Exception Handlers
• HTML Help (.CHM)
• Remote Access Tool Artifacts (Files, Directories, Registry Keys)
• ContextMenuHandler DLL Checks
• Office AI.exe Presence
• Notepad++ Plugins
• MSDTC Registry Hijacks
• Narrator DLL Hijack (MSTTSLocEnUS.DLL)
• Suspicious File Location Checks

TODO

• Add Analysis/Remediation Guidance to each detection in the GitHub Wiki (In-Progress)
• Browser Extension Analysis (?)
• RID Hijacking [https://www.ired.team/offensive-security/persistence/rid-hijacking][https://pentestlab.blog/2020/02/12/persistence-rid-hijacking/]
• PowerAutomate Checks
• ShadowPad Indicators [https://www.secureworks.com/research/shadowpad-malware-analysis, https://www.hexacorn.com/blog/2023/02/25/beyond-good-ol-run-key-part-141/]
• OBS Startup Script Scanning [https://www.hexacorn.com/blog/2023/04/14/beyond-good-ol-run-key-part-142/]
• SQL Server Management Addins [https://www.hexacorn.com/blog/2019/09/28/beyond-good-ol-run-key-part-117/]
• AutoPlay Handler Inspection [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\AutoplayHandlers\Handlers]
• HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Setup\Pending\SPReviewEnabler
• OCSetup [https://www.hexacorn.com/blog/2019/11/09/beyond-good-ol-run-key-part-122/]
• Review https://hijacklibs.net/# for additional opportunities
• Review https://www.wietzebeukema.nl/blog/hijacking-dlls-in-windows for additional opportunities
• Review https://silentrunners.org/launchpoints.html for additional opportunities

MITRE Techniques Evaluated

Please be aware that some of these are (of course) more detected than others - for example, we are not detecting all possible registry modifications but rather inspecting certain keys for obvious changes and using the generic MITRE technique "Modify Registry" where no other technique is applicable. For other items such as COM hijacking, we are inspecting all entries in the relevant registry section, checking against 'known-good' patterns and bubbling up unknown or mismatched values, resulting in a much more complete detection surface for that particular technique.

• T1037: Boot or Logon Initialization Scripts
• T1037.001: Boot or Logon Initialization Scripts: Logon Script (Windows)
• T1037.005: Boot or Logon Initialization Scripts: Startup Items
• T1055.001: Process Injection: Dynamic-link Library Injection
• T1059: Command and Scripting Interpreter
• T1071: Application Layer Protocol
• T1098: Account Manipulation
• T1112: Modify Registry
• T1053: Scheduled Task/Job
• T1136: Create Account
• T1137.001: Office Application Office Template Macros
• T1137.002: Office Application Startup: Office Test
• T1137.006: Office Application Startup: Add-ins
• T1197: BITS Jobs
• T1505.005: Server Software Component: Terminal Services DLL
• T1543.003: Create or Modify System Process: Windows Service
• T1546: Event Triggered Execution
• T1546.001: Event Triggered Execution: Change Default File Association
• T1546.002: Event Triggered Execution: Screensaver
• T1546.003: Event Triggered Execution: Windows Management Instrumentation Event Subscription
• T1546.007: Event Triggered Execution: Netsh Helper DLL
• T1546.008: Event Triggered Execution: Accessibility Features
• T1546.009: Event Triggered Execution: AppCert DLLs
• T1546.010: Event Triggered Execution: AppInit DLLs
• T1546.011: Event Triggered Execution: Application Shimming
• T1546.012: Event Triggered Execution: Image File Execution Options Injection
• T1546.013: Event Triggered Execution: PowerShell Profile
• T1546.015: Event Triggered Execution: Component Object Model Hijacking
• T1547.002: Boot or Logon Autostart Execution: Authentication Packages
• T1547.003: Boot or Logon Autostart Execution: Time Providers
• T1547.004: Boot or Logon Autostart Execution: Winlogon Helper DLL
• T1547.005: Boot or Logon Autostart Execution: Security Support Provider
• T1547.009: Boot or Logon Autostart Execution: Shortcut Modification
• T1547.012: Boot or Logon Autostart Execution: Print Processors
• T1547.014: Boot or Logon Autostart Execution: Active Setup
• T1553: Subvert Trust Controls
• T1553.004: Subvert Trust Controls: Install Root Certificate
• T1556.002: Modify Authentication Process: Password Filter DLL
• T1574: Hijack Execution Flow
• T1574.007: Hijack Execution Flow: Path Interception by PATH Environment Variable
• T1574.009: Hijack Execution Flow: Path Interception by Unquoted Path

References

This tool would not exist without the amazing InfoSec community - the most notable references I used are provided below.

• PersistenceSniper
• MITRE ATT&CK
• Persistence Info GitHub
• Hexacorn - Persistence Series
• IRED
• PayloadsAllTheThings

More References

• https://twitter.com/Laughing_Mantis/status/1645268114966470662
• https://shellz.club/posts/a-novel-method-for-bypass-ETW/
• https://pentestlab.blog/2023/03/20/persistence-service-control-manager/
• https://ristbs.github.io/2023/02/15/hijack-explorer-context-menu-for-persistence-and-fun.html
• https://pentestlab.blog/2022/02/14/persistence-notepad-plugins/

NixImports - A .NET Malware Loader, Using API-Hashing To Evade Static Analysis

A .NET malware loader, using API-Hashing and dynamic invoking to evade static analysis

How does it work?

NixImports uses my managed API-Hashing implementation HInvoke, to dynamically resolve most of it's called functions at runtime. To resolve the functions HInvoke requires two hashes the typeHash and the methodHash. These hashes represent the type name and the methods FullName, on runtime HInvoke parses the entire mscorlib to find the matching type and method. Due to this process, HInvoke does not leave any import references to the methods called trough it.

Another interesting feature of NixImports is that it avoids calling known methods as much as possible, whenever applicable NixImports uses internal methods instead of their wrappers. By using internal methods only we can evade basic hooks and monitoring employed by some security tools.

For a more detailed explanation checkout my blog post.

You can generate hashes for HInvoke using this tool

How to use

NixImports only requires a filepath to the .NET binary you want to pack with it.

NixImports.exe <filepath>

It will automatically generate a new executable called Loader.exe in it's root folder. The loader executable will contain your encoded payload and the stub code required to run it.

Tips for Defenders

If youre interested in detection engineering and possible detection of NixImports, checkout the last section of my blog post

Or click here for a basic yara rule covering NixImports.

VX-API - Collection Of Various Malicious Functionality To Aid In Malware Development

The VX-API is a collection of malicious functionality to aid in malware development. It is recommended you clone and/or download this entire repo then open the Visual Studio solution file to easily explore functionality and concepts.

Some functions may be dependent on other functions present within the solution file. Using the solution file provided here will make it easier to identify which other functionality and/or header data is required.

You're free to use this in any manner you please. You do not need to use this entire solution for your malware proof-of-concepts or Red Team engagements. Strip, copy, paste, delete, or edit this projects contents as much as you'd like.

List of features

Anti-debug

Cryptography Related

Error Handling

Evasion

Fingerprinting

Helper Functions

Library Loading

Lsass Dumping

Network Connectivity

Other

Process Creation

Process Injection

Proxied Functions

Shellcode Execution

String Manipulation

UAC Bypass

Rad98 Hooking Engine

Generic Shellcode

Hidden - Windows Driver With Usermode Interface Which Can Hide Processes, File-System And Registry Objects, Protect Processes And Etc

Hidden has been developed like a solution for reverse engineering and researching tasks. This is a windows driver with a usermode interface which is used for hiding specific environment on your windows machine, like installed RCE programs (ex. procmon, wireshark), vm infrastructure (ex. vmware tools) and etc.

Features

• hide registry keys and values
• hide files and directories
• hide processes (experimental, might be not stable)
• protect specific processes
• exclude specific processes from hiding and protection features
• usermode interface (lib and cli) for working with a driver

and so on

System requirements

Windows Vista and above, x86 and x64

Recommended build environment

• Visual Studio 2019
• Windows Driver Kit 10

Building

Following guide explains how to make a release win32 build

1. Open Hidden.sln using Visual Studio
2. Build Hidden Package project with configurations Release, Win32
3. Open build results folder <ProjectDir>\Release

Installing

1. Disable a digital signature enforcement on a test machine (bcdedit /set TESTSIGNING ON) and reboot it
2. Copy files from <ProjectDir>\Release\Hidden Package to a test machine
3. Right mouse click on Hidden.inf and choose Install
4. Start a driver (sc start hidden)
5. Make sure service is running (sc query hidden)

Important: Keep in mind that the driver bitness have to be the same to an OS bitness

Hiding

A command line tool hiddencli is used for managing a driver. You are able to use it for hiding and unhiding objects, changing a driver state and so on.

To hide a file try the command

hiddencli /hide file c:\Windows\System32\calc.exe

Want to hide a directory? No problems

hiddencli /hide dir "c:\Program Files\VMWare"

Registry key?

hiddencli /hide regkey "HKCU\Software\VMware, Inc."

Maybe a process?

hiddencli /hide pid 2340

By a process image name?

hiddencli /hide image apply:forall c:\Windows\Explorer.EXE

To get a full help just type

hiddencli /help

yaraQA - YARA Rule Analyzer To Improve Rule Quality And Performance

YARA rule Analyzer to improve rule quality and performance

Why?

YARA rules can be syntactically correct but still dysfunctional. yaraQA tries to find and report these issues to the author or maintainer of a YARA rule set.

The issues yaraQA tries to detect are e.g.:

• rules that are syntactically correct but never match due to errors in the condition (e.g. rule with one string and 2 of them in the condition)
• rules that use string and modifier combinations that are probably wrong (e.g. $ = "\\Debug\\" fullword)
• performance issues caused by short atoms, repeating characters or loops (e.g. $ = "AA"; can be excluded from the analysis using --ignore-performance)

I'm going to extend the test set over time. Each minor version will include new features or new tests.

Install requirements

pip install -r requirements.txt

Usage

usage: yaraQA.py [-h] [-f yara files [yara files ...]] [-d yara files [yara files ...]] [-o outfile] [-b baseline] [-l level]
                 [--ignore-performance] [--debug]

YARA RULE ANALYZER

optional arguments:
  -h, --help            show this help message and exit
  -f yara files [yara files ...]
                        Path to input files (one or more YARA rules, separated by space)
  -d yara files [yara files ...]
                        Path to input directory (YARA rules folders, separated by space)
  -o outfile            Output file that lists the issues (JSON, default: 'yaraQA-issues.json') 
  -b baseline           Use a issues baseline (issues found and reviewed before) to filter issues
  -l level              Minium level to show (1=informational, 2=warning, 3=critical)
  --ignore-performance  Suppress performance-related rule issues
  --debug                  Debug output

Try it out

python3 yaraQA.py -d ./test/

Suppress all performance issues and only show detection / logic issues.

python3 yaraQA.py -d ./test/ --ignore-performance

Suppress all issues of informational character

python3 yaraQA.py -d ./test/ -level 2

Use a baseline to only see new issues (not the ones that you've already reviewed). The baseline file is an old JSON output of a reviewed state.

python3 yaraQA.py -d ./test/ -b yaraQA-reviewed-issues.json

Example Rules with Issues

Example rules with issues can be found in the ./test folder.

Output

yaraQA writes the detected issues to a file named yaraQA-issues.json by default.

This listing shows an example of the output generated by yaraQA in JSON format:

[
    {
        "rule": "Demo_Rule_1_Fullword_PDB",
        "id": "SM1",
        "issue": "The rule uses a PDB string with the modifier 'wide'. PDB strings are always included as ASCII strings. The 'wide' keyword is unneeded.",
        "element": {
            "name": "$s1",
            "value": "\\\\i386\\\\mimidrv.pdb",
            "type": "text",
            "modifiers": [
                "ascii",
                "wide",
                "fullword"
            ]
        },
        "level": "info",
        "type": "logic",
        "recommendation": "Remove the 'wide' modifier"
    },
    {
        "rule": "Demo_Rule_1_Fullword_PDB",
        "id": "SM2",
        "issue": "The rule uses a PDB string with the modifier 'fullword' but it starts with two backslashes and thus the modifier could lead to a dysfunctional rule.",
        "element": {
            "name": "   $s1",
            "value": "\\\\i386\\\\mimidrv.pdb",
            "type": "text",
            "modifiers": [
                "ascii",
                "wide",
                "fullword"
            ]
        },
        "level": "warning",
        "type": "logic",
        "recommendation": "Remove the 'fullword' modifier"
    },
    {
        "rule": "Demo_Rule_2_Short_Atom",
        "id": "PA2",
        "issue": "The rule contains a string that turns out to be a very short atom, which could cause a reduced performance of the complete rule set or increased memory usage.",
        "element": {
            "name": "$s1",
            "value": "{ 01 02 03 }",
            "type": "byte"
        },
        "level": "warning",
        "type": "performance",
        "recommendation": "Try to avoid using such short atoms, by e.g. adding a few more bytes to the beginning or the end (e.g. add a binary    0 in front or a space after the string). Every additional byte helps."
    },
    {
        "rule": "Demo_Rule_3_Fullword_FilePath_Section",
        "id": "SM3",
        "issue": "The rule uses a string with the modifier 'fullword' but it starts and ends with two backslashes and thus the modifier could lead to a dysfunctional rule.",
        "element": {
            "name": "$s1",
            "value": "\\\\ZombieBoy\\\\",
            "type": "text",
            "modifiers": [
                "ascii",
                "fullword"
            ]
        },
        "level": "warning",
        "type": "logic",
        "recommendation": "Remove the 'fullword' modifier"
    },
    {
        "rule": "Demo_Rule_4_Condition_Never_Matches",
        "id": "CE1",
        "issue": "The rule uses a condition that will never match",
        "element": {
            "condition_segment": "2 of",
               "num_of_strings": 1
        },
        "level": "error",
        "type": "logic",
        "recommendation": "Fix the condition"
    },
    {
        "rule": "Demo_Rule_5_Condition_Short_String_At_Pos",
        "id": "PA1",
        "issue": "This rule looks for a short string at a particular position. A short string represents a short atom and could be rewritten to an expression using uint(x) at position.",
        "element": {
            "condition_segment": "$mz at 0",
            "string": "$mz",
            "value": "MZ"
        },
        "level": "warning",
        "type": "performance",
        "recommendation": ""
    },
    {
        "rule": "Demo_Rule_5_Condition_Short_String_At_Pos",
        "id": "PA2",
        "issue": "The rule contains a string that turns out to be a very short atom, which could cause a reduced performance of the complete rule set or increased memory usage.",<   br/>        "element": {
            "name": "$mz",
            "value": "MZ",
            "type": "text",
            "modifiers": [
                "ascii"
            ]
        },
        "level": "warning",
        "type": "performance",
        "recommendation": "Try to avoid using such short atoms, by e.g. adding a few more bytes to the beginning or the end (e.g. add a binary 0 in front or a space after the string). Every additional byte helps."
    },
    {
        "rule": "Demo_Rule_6_Condition_Short_Byte_At_Pos",
        "id": "PA1",
        "issue": "This rule looks for a short string at a particular position. A short string represents a short atom and could be rewritten to an expression using uint(x) at position.",
        "element": {
            "condition_segment": "$mz at 0",
            "string": "$mz",
            "value": "{ 4d 5a }"
        },
        "level": "warning",
           "type": "performance",
        "recommendation": ""
    },
    {
        "rule": "Demo_Rule_6_Condition_Short_Byte_At_Pos",
        "id": "PA2",
        "issue": "The rule contains a string that turns out to be a very short atom, which could cause a reduced performance of the complete rule set or increased memory usage.",
        "element": {
            "name": "$mz",
            "value": "{ 4d 5a }",
            "type": "byte"
        },
        "level": "warning",
        "type": "performance",
        "recommendation": "Try to avoid using such short atoms, by e.g. adding a few more bytes to the beginning or the end (e.g. add a binary 0 in front or a space after the string). Every additional byte helps."
    },
    {
        "rule": "Demo_Rule_6_Condition_Short_Byte_At_Pos",
        "id": "SM3",
        "issue": "The rule uses a string with the modifier 'fullword' but it starts and ends with two backsla   shes and thus the modifier could lead to a dysfunctional rule.",
        "element": {
            "name": "$s1",
            "value": "\\\\Section\\\\in\\\\Path\\\\",
            "type": "text",
            "modifiers": [
                "ascii",
                "fullword"
            ]
        },
        "level": "warning",
        "type": "logic",
        "recommendation": "Remove the 'fullword' modifier"
    }
]

Screenshots

Handle-Ripper - Windows Handle Hijacker

• Handle hijacking is a technique used in Windows operating systems to gain access to resources and resources of a system without permission. It is a type of privilege escalation attack in which a malicious user takes control of an object handle, which is an identifier that is used to reference a system object, such as a file, a directory, a process, or an event. This allows the malicious user to gain access to resources that should be inaccessible to them.

• Handle hijacking is a serious threat to system security as it allows a malicious user to access resources and data that should otherwise be protected. It can also be used to inject code into a vulnerable system, allowing the attacker to gain access to information and resources.

• Handle hijacking techniques are becoming increasingly prevalent as hackers develop more sophisticated methods of exploiting vulnerabilities in Windows systems. As such, it is important that system administrators understand the risks associated with handle hijacking and take proactive measures to protect their systems.

DETAILS

• To perform a handle hijacking attack, an attacker must first identify a handle that is being used by a legitimate process and that they want to access. This can be done using various techniques, such as scanning the handle table of a process, monitoring handle creation events, or using a tool that can enumerate handles on the system ,Once the attacker has identified the handle they want to access, they can use the DuplicateHandle function to create a copy of the handle with their own process. This function takes the following parameters:

  • hSourceProcessHandle: A handle to the process that contains the source handle.
  • hSourceHandle: A handle to the object to duplicate.
  • hTargetProcessHandle: A handle to the process that is to receive the duplicated handle.
  • lpTargetHandle: A pointer to a variable that receives the handle value.
  • dwDesiredAccess: The access rights for the duplicated handle.
  • bInheritHandle: A value that specifies whether the handle is inheritable.
  • dwOptions: Additional options for the handle duplication.

• The DuplicateHandle function will create a new handle with the specified access rights and options, and return it in the lpTargetHandle parameter. The attacker can then use this handle to access the resource that it represents, allowing them to perform actions on the resource that they would not normally be able to do.

C2-Hunter - Extract C2 Traffic

C2-Hunter

• C2-Hunter is a program designed for malware analysts to extract Command and Control (C2) traffic from malwares in real-time. The program uses a unique approach by hooking into win32 connections APIs.

• With C2-Hunter, malware analysts can now intercept and analyze communication in real-time, gaining valuable insights into the inner workings of cyber threats. Its ability to track C2 elements of malware makes it an essential tool for any cyber security team.

Features

• Real-time extraction of C2 traffic
• Bypasses malware time delays to speed up the extraction process (SOON)

Requirements

• Windows Operating System
• Administrator Privileges

Bypass-Sandbox-Evasion - Bypass Malware Sandbox Evasion Ram Check

Sandboxes are commonly used to analyze malware. They provide a temporary, isolated, and secure environment in which to observe whether a suspicious file exhibits any malicious behavior. However, malware developers have also developed methods to evade sandboxes and analysis environments. One such method is to perform checks to determine whether the machine the malware is being executed on is being operated by a real user. One such check is the RAM size. If the RAM size is unrealistically small (e.g., 1GB), it may indicate that the machine is a sandbox. If the malware detects a sandbox, it will not execute its true malicious behavior and may appear to be a benign file

Details

• The GetPhysicallyInstalledSystemMemory API retrieves the amount of RAM that is physically installed on the computer from the SMBIOS firmware tables. It takes a PULONGLONG parameter and returns TRUE if the function succeeds, setting the TotalMemoryInKilobytes to a nonzero value. If the function fails, it returns FALSE.

     

• The amount of physical memory retrieved by the GetPhysicallyInstalledSystemMemory function must be equal to or greater than the amount reported by the GlobalMemoryStatusEx function; if it is less, the SMBIOS data is malformed and the function fails with ERROR_INVALID_DATA, Malformed SMBIOS data may indicate a problem with the user's computer .

  

• The register rcx holds the parameter TotalMemoryInKilobytes. To overwrite the jump address of GetPhysicallyInstalledSystemMemory, I use the following opcodes: mov qword ptr ss:[rcx],4193B840. This moves the value 4193B840 (or 1.1 TB) to rcx. Then, the ret instruction is used to pop the return address off the stack and jump to it, Therefore, whenever GetPhysicallyInstalledSystemMemory is called, it will set rcx to the custom value."

  

KoodousFinder - A Simple Tool To Allows Users To Search For And Analyze Android Apps For Potential Security Threats And Vulnerabilities

A simple tool to allows users to search for and analyze android apps for potential security threats and vulnerabilities

Account and API Key

Create a Koodous account and get your api key https://koodous.com/settings/developers

Install

$ pip install koodousfinder

Arguments

Examples

koodous.py --package-name "app: Brata AND package: com.brata"
koodous.py --package-name "package: com.google.android.videos AND trusted: true"
koodous.py --package-name "com.metasploit"
python3 koodous.py --app-name "WhatsApp MOD"

Modifiers for advanced search

More information: https://docs.koodous.com/apks.html.
#TODO

• Discord Integration
• Rulesets view

PortexAnalyzerGUI - Graphical Interface For PortEx, A Portable Executable And Malware Analysis Library