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

Service payloads #1850

Closed
wants to merge 17 commits into from
Closed

Service payloads #1850

wants to merge 17 commits into from

Conversation

@agix
Copy link
Contributor

@agix agix commented May 19, 2013

related to #903
as egyp7 suggested I modified to_win32pe_service instead of create all _service payloads.
Now services are created with any EXE::Template so AV evasion is much more better and psexec may reborn :D

agix added 8 commits May 19, 2013
as egyp7 suggested I modified to_win32pe_service instead of create all _service payloads.
Now services are created with any EXE::Template so AV evasion is much more better and psexec will reborn :D
…ate template_x86_windows_old.exe crash.

I just replace it by template_x86_windows.exe
…lt template template_x86_windows_old.exe crash."

to prevent conflict with another branch
This reverts commit bdd751e.
It's okay now to prevent a potential futur conflict.
@sempervictus
Copy link
Contributor

@sempervictus sempervictus commented May 26, 2013

Thank you very much, this can be very useful for psexec and persistence modules alike (nothing like turning someone's notepad into the malicious service).
We should probably have the system automatically call the old method if we can locate service info in the PE.
Additionally, if not passing a service name to the method, it blows up trying to call [] on nil. I've just added a Rex::Text::rand_text_alpha(16) assignment on nil to remedy that.

Any chance you have the x64 shellcode up your sleeve?
Thanks again

@agix
Copy link
Contributor Author

@agix agix commented May 27, 2013

I can make the shellcode for x64 too. As soon as I have a little time I will :)

I didn't understand what's the problem with the service name ? Can you pull request your change in my branch ?

Thx

@wvu-r7
Copy link
Member

@wvu-r7 wvu-r7 commented Jun 20, 2013

@agix: Is this good to go? I'd like to get more reviewers on it.

@agix
Copy link
Contributor Author

@agix agix commented Jun 20, 2013

I didn't make the 64bits shellcode yet, but I use the 32bits. Is the 32 bits version good to merge for you ?

@agix
Copy link
Contributor Author

@agix agix commented Jun 24, 2013

For information, I just test it on a WIN7 with MSE AV. And it totally bypass it...
As the AV try to run the exe just uploaded by psexec, and as the exe is a service, at the PE entry point, there is just service registration confirmation and exit. So emulation never run the encoded payload. While windows service manager run the payload. @wvu-r7 what do you want I add to this pull request to merge it ?

@wvu-r7
Copy link
Member

@wvu-r7 wvu-r7 commented Jun 26, 2013

This PR needs to be reviewed first.

pe = Rex::PeParsey::Pe.new_from_file(opts[:template], true)

exe = ''
File.open(opts[:template], 'rb') { |fd|

This comment has been minimized.

@limhoff-r7

limhoff-r7 Jun 26, 2013
Contributor

Whitespace difference between this line and the previous line.

}

sections_header = []
pe._file_header.v['NumberOfSections'].times { |i| sections_header << [(i*0x28)+pe.rva_to_file_offset(pe._dos_header.v['e_lfanew']+pe._file_header.v['SizeOfOptionalHeader']+0x18+0x24),exe[(i*0x28)+pe.rva_to_file_offset(pe._dos_header.v['e_lfanew']+pe._file_header.v['SizeOfOptionalHeader']+0x18),0x28]] }

This comment has been minimized.

@limhoff-r7

limhoff-r7 Jun 26, 2013
Contributor

Break this up into additional lines. This line is too long and has too many statements to reasonably grok.

This comment has been minimized.

@limhoff-r7

limhoff-r7 Jun 26, 2013
Contributor

Use named constants for offsets and sizes.


#look for section with entry point
sections_header.each do |sec|
virtualAddress = sec[1][0xc,0x4].unpack('L')[0]

This comment has been minimized.

@limhoff-r7

limhoff-r7 Jun 26, 2013
Contributor

Use named constants for offsets.

@agix
Copy link
Contributor Author

@agix agix commented Jun 27, 2013

@limhoff-r7 is it okay now ? I didn't break the big line too much, maybe you prefer I split it again ?

@limhoff-r7
Copy link
Contributor

@limhoff-r7 limhoff-r7 commented Jun 27, 2013

I'm working on a PR to break it up more.


sections_header = []
pe._file_header.v['NumberOfSections'].times { |i|
sections_header << [(i*section_size)+pe.rva_to_file_offset(secions_table_offset+characteristics_offset),exe[(i*section_size)+pe.rva_to_file_offset(secions_table_offset),section_size]]

This comment has been minimized.

@limhoff-r7

limhoff-r7 Jun 27, 2013
Contributor

exe[(i*section_size)+pe.rva_to_file_offset(secions_table_offset),section_size]

reads to me as calculate the nth section's offset, then find that section's section table offset, but then take the entire section from that offset, since the variable is called section_size. Is section_size actually the size of the section table? The variable names seem inconsistent.

This comment has been minimized.

@agix

agix Jun 27, 2013
Author Contributor

section_size is the size of one section (always 0x28) pe.rva_to_file_offset(secions_table_offset) give the section table offset that contains pe._file_header.v['NumberOfSections'] sections of 0x28 bytes.
the section table size is equal to the number of sections * section_size.

This comment has been minimized.

@limhoff-r7

limhoff-r7 Jun 27, 2013
Contributor

Ah, I see now, I was thinking of the two addends in the wrong order. I was picturing (i *section_size) as the base address and pe... as the offset for each iteration in that section, but it's actually that the pe... is the base address and the i * section_size is loop offset. I guess I'm used to the base address being first, or base + offset.

This comment has been minimized.

@limhoff-r7

limhoff-r7 Jun 27, 2013
Contributor

Since that's the case, pe.rva_to_file_offset(secions_table_offset+characteristics_offset) should be lifted out of the loop since it is invariant and so should pe.rva_to_file_offset(secions_table_offset)

@agix
Copy link
Contributor Author

@agix agix commented Jun 28, 2013

We are close now, aren't we ? :)

@wvu-r7
Copy link
Member

@wvu-r7 wvu-r7 commented Jul 2, 2013

Probably!

@agix
Copy link
Contributor Author

@agix agix commented Aug 27, 2013

Probably ? 2 months ago.
Can I do something more ?

push esp
push 0x726774c
call ebp ;load advapi32.dll
push 0x00454349

This comment has been minimized.

@agix

agix Sep 19, 2013
Author Contributor

Just noticed that service deletion is not working because my ServiceName is 7 bytes long (2 push with null byte). So 2 choices. Recode the whole shellcode with a 8 bytes ServiceName and all change that include :(.
Change psexec.rb rand_text_alpha(8) to rand_text_alpha(7) that sounds a better solution ! :D

This comment has been minimized.

@mubix

mubix Sep 19, 2013
Contributor

I vote for the 7 character change as it will probably throw some HIPS / AVs through a loop for a while ;-)

This comment has been minimized.

@agix

agix Sep 19, 2013
Author Contributor

Done :D

This comment has been minimized.

@mubix

mubix Sep 19, 2013
Contributor

As PSEXEC is now part of a mixin, will a change to the mixin also be required?

This comment has been minimized.

@agix

agix Sep 19, 2013
Author Contributor

No idea... where is servicename used ?

@mubix
Copy link
Contributor

@mubix mubix commented Nov 7, 2013

Whats left on the task list for this pull?

@agix
Copy link
Contributor Author

@agix agix commented Nov 7, 2013

I have no idea... I hope it could still merge.

@limhoff-r7
Copy link
Contributor

@limhoff-r7 limhoff-r7 commented Nov 7, 2013

Don't wait on my comment from #1850 (comment). I'm too busy working on the module cache.

@kernelsmith
Copy link
Contributor

@kernelsmith kernelsmith commented Nov 8, 2013

With OJ's extapi for meterpreter, which has native support for service manipulation, would you be able/want to take advantage of that? It would eliminate railgun calls.

-Josh

On Nov 7, 2013, at 9:00, agix notifications@github.com wrote:

I have no idea... I hope it could still merge.


Reply to this email directly or view it on GitHub.

@mubix
Copy link
Contributor

@mubix mubix commented Nov 8, 2013

@kernelsmith - there aren't any railgun calls, these are service valid payloads that respond to things like "status" that allows for payloads to survive the ~5 minute kill

@kernelsmith
Copy link
Contributor

@kernelsmith kernelsmith commented Nov 8, 2013

Oh, gotchya sorry. You're making the SCuM happy ;). Sorry I couldn't review the code b4 commenting. I was out of country

-Josh

On Nov 8, 2013, at 9:21, Rob Fuller notifications@github.com wrote:

@kernelsmith - there aren't any railgun calls, these are service valid payloads that respond to things like "status" that allows for payloads to survive the ~5 minute kill


Reply to this email directly or view it on GitHub.

@agix
Copy link
Contributor Author

@agix agix commented Nov 8, 2013

huhu, I have nothing to add to mubix explanation :D ! Still waiting for a merge... or a constructive comment.

@wvu-r7
Copy link
Member

@wvu-r7 wvu-r7 commented Nov 8, 2013

Hi.

@agix
Copy link
Contributor Author

@agix agix commented Nov 14, 2013

I will refresh this patch on a new branch, because some things has changed since 6 months...
But I hope, some day, it will merge...

@agix agix mentioned this pull request Nov 20, 2013
7 tasks done
@agix
Copy link
Contributor Author

@agix agix commented Nov 20, 2013

Okay, let's try again !
here is the new pull request with the new exe logic
#2657

You can close this one !

@OJ
Copy link
Contributor

@OJ OJ commented Nov 20, 2013

@agix It's your PR, you can close it dude :)

@agix agix closed this Nov 20, 2013
@agix agix deleted the agix:service_payloads branch Nov 20, 2013
@agix
Copy link
Contributor Author

@agix agix commented Nov 20, 2013

hehe, right :)

@agix agix restored the agix:service_payloads branch Jan 2, 2014
@agix agix deleted the agix:service_payloads branch Oct 6, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

8 participants