Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[plugin] Add dirty state IoC detection to malfind #1300

Open
wants to merge 1 commit into
base: develop
Choose a base branch
from

Conversation

Abyss-W4tcher
Copy link
Contributor

Hi,

The current windows.malfind implementation does not leverage the dirty state indicator to identify potential threats, and filters out non writable VADs. However, some evasion techniques use an elevated WriteProcessMemory call to inject data inside remote processes PAGE_EXECUTE_READ regions :

As expected, we invoked WriteProcessMemory, specifying 0x00007FF7519BOECO as
target address (address of entry point in our example), and successfully changed the
read-only region.

When using WriteProcessMemory to write to Read-only memory addresses we have
observed that associated errors and exceptions are not raised within the OS if we have
sufficient privileges on the target process. The question is, why?

If the page is read-only, Write­Process­Memory temporarily changes the permission to read-write, updates the memory, and then restores the original permission.

To identify this behaviour, I edited the malfind code to scan each VAD page with (R)-X protection for any dirty state marker.

If necessary, I can develop a PoC + sample (which might come handy for unit tests).

Inspired from Linux #995.

@atcuno
Copy link
Contributor

atcuno commented Oct 8, 2024

Do you have some Windows 10 samples with the default Defender enabled state to test this? If not, we can run it over some of them soon.

@Abyss-W4tcher
Copy link
Contributor Author

I don't possess any sample infected by this technique, or by malware performing an RWX allocation, shellcode injection and then changing protection back to RX.

Sure, it'd be great to have this feature ran over many samples !

@atcuno
Copy link
Contributor

atcuno commented Oct 8, 2024

Ok we will run it across our sample set (a couple hundred Windows samples) and report back before/after this patch.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants