Forums
New posts
Search forums
News
Security News
Technology News
Giveaways
Giveaways, Promotions and Contests
Discounts & Deals
Reviews
Users Reviews
Video Reviews
Support
Windows Malware Removal Help & Support
Inactive Support Threads
Mac Malware Removal Help & Support
Mobile Malware Removal Help & Support
Blog
Log in
Register
What's new
Search
Search titles only
By:
Search titles only
By:
Reply to thread
Menu
Install the app
Install
JavaScript is disabled. For a better experience, please enable JavaScript in your browser before proceeding.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an
alternative browser
.
Forums
Software
Security Apps
Other security for Windows, Mac, Linux
NoVirusThanks OSArmor
Message
<blockquote data-quote="Deleted member 65228" data-source="post: 717879"><p>Okay I did some reverse engineering and have identified how NtQueryInformationProcess really gets the file path image name...</p><p></p><p>1. User-mode process calls NtQueryInformationProcess (NTDLL) with the ProcessImageFileName class (27)</p><p>2. System call transition to invoke NtQueryInformationProcess (NTOSKRNL)</p><p>3. NtQueryInformationProcess checks if the ProcessInformationClass (PROCESSINFOCLASS) parameter is 27</p><p>4. If it is 27 (which represents the ProcessImageFileName class in the PROCESSINFOCLASS enum) then it will:</p><p>- Invoke ObpReferenceObjectByHandleWithTag to get a pointer to the _EPROCESS structure for the targeted process using the process handle given to the routine</p><p>- If the NTSTATUS result is STATUS_SUCCESS then PsQueryFullProcessImageName is invoked</p><p></p><p>PsQueryFullProcessImageName works by accessing the fields of the _EPROCESS structure for the process.</p><p></p><p>1. Base address of the _EPROCESS structure for the target process + an offset (offset = different on different OS versions/updates)</p><p>2. The address of the calculation will be the field in the _EPROCESS structure for that process for SeAuditProcessCreationInfo (_SE_AUDIT_PROCESS_CREATION_INFO)</p><p>3. Access the _SE_AUDIT_PROCESS_CREATION_INFO structure field ImageFileName</p><p>4. The ImageFileName field = _OBJECT_NAME_INFORMATION structure</p><p>5. Access the _OBJECT_NAME_INFORMATION structure using the ImageFileName field which has only one field to it which is named "Name" (UNICODE_STRING)</p><p>6. Provides back the Buffer contents of that UNICODE_STRING</p><p></p><p>The same value in that Buffer is also given to the PRTL_PROCESS_PARAMETERS ImageFileName entry in the PEB but patching the PEB locally won't stop others from locating the image file name with NtQueryInformationProcess because the Windows Kernel doesn't rely on the PEB data, it has its own storage in kernel-structures. The PEB does use communication with the Windows Kernel for some things because the point of it is so user-mode processes can access data without actually touching kernel memory so that info is given back down, and some software might rely on data in the PEB (you can also read PEB of other processes), like how people used to patch the Ldr linked list to hide non-manually mapped modules until Microsoft blocked it off with memory protection techniques.</p><p></p><p>So that is how the ImageFileName is retrieved...</p><p></p><p>RunPE detector tool -> gets the image file name and reads the PE on-disk and compares if it matches or not. The reason this is done is because process hollowing works by starting a process with a suspended state so you can un-map the image from the process (it won't have executed any of its own code yet either) -> replace it with the malicious image -> now the process still points to the genuine file path but the contents are malicious because the image in memory was replaced.</p><p></p><p>Due to how it works and due to how most malware deploys process hollowing, it'll catch 99.9% of malware in the wild using process hollowing.</p><p></p><p>--</p><p></p><p>Sorry for hijacking the thread, I'll shut up and stop talking about this now. <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite109" alt=":)" title="Smile :)" loading="lazy" data-shortname=":)" /></p></blockquote><p></p>
[QUOTE="Deleted member 65228, post: 717879"] Okay I did some reverse engineering and have identified how NtQueryInformationProcess really gets the file path image name... 1. User-mode process calls NtQueryInformationProcess (NTDLL) with the ProcessImageFileName class (27) 2. System call transition to invoke NtQueryInformationProcess (NTOSKRNL) 3. NtQueryInformationProcess checks if the ProcessInformationClass (PROCESSINFOCLASS) parameter is 27 4. If it is 27 (which represents the ProcessImageFileName class in the PROCESSINFOCLASS enum) then it will: - Invoke ObpReferenceObjectByHandleWithTag to get a pointer to the _EPROCESS structure for the targeted process using the process handle given to the routine - If the NTSTATUS result is STATUS_SUCCESS then PsQueryFullProcessImageName is invoked PsQueryFullProcessImageName works by accessing the fields of the _EPROCESS structure for the process. 1. Base address of the _EPROCESS structure for the target process + an offset (offset = different on different OS versions/updates) 2. The address of the calculation will be the field in the _EPROCESS structure for that process for SeAuditProcessCreationInfo (_SE_AUDIT_PROCESS_CREATION_INFO) 3. Access the _SE_AUDIT_PROCESS_CREATION_INFO structure field ImageFileName 4. The ImageFileName field = _OBJECT_NAME_INFORMATION structure 5. Access the _OBJECT_NAME_INFORMATION structure using the ImageFileName field which has only one field to it which is named "Name" (UNICODE_STRING) 6. Provides back the Buffer contents of that UNICODE_STRING The same value in that Buffer is also given to the PRTL_PROCESS_PARAMETERS ImageFileName entry in the PEB but patching the PEB locally won't stop others from locating the image file name with NtQueryInformationProcess because the Windows Kernel doesn't rely on the PEB data, it has its own storage in kernel-structures. The PEB does use communication with the Windows Kernel for some things because the point of it is so user-mode processes can access data without actually touching kernel memory so that info is given back down, and some software might rely on data in the PEB (you can also read PEB of other processes), like how people used to patch the Ldr linked list to hide non-manually mapped modules until Microsoft blocked it off with memory protection techniques. So that is how the ImageFileName is retrieved... RunPE detector tool -> gets the image file name and reads the PE on-disk and compares if it matches or not. The reason this is done is because process hollowing works by starting a process with a suspended state so you can un-map the image from the process (it won't have executed any of its own code yet either) -> replace it with the malicious image -> now the process still points to the genuine file path but the contents are malicious because the image in memory was replaced. Due to how it works and due to how most malware deploys process hollowing, it'll catch 99.9% of malware in the wild using process hollowing. -- Sorry for hijacking the thread, I'll shut up and stop talking about this now. :) [/QUOTE]
Insert quotes…
Verification
Post reply
Top
