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
base: master
from

Conversation

Projects
None yet
8 participants
@agix
Copy link
Contributor

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 some commits 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 will reborn :D
with exe-only technique (use in to_win32pe_service) the default templ…
…ate template_x86_windows_old.exe crash.

I just replace it by template_x86_windows.exe
Revert "with exe-only technique (use in to_win32pe_service) the defau…
…lt template template_x86_windows_old.exe crash."

to prevent conflict with another branch
This reverts commit bdd751e.
Fiouf, I have to improve my git skill huhu
It's okay now to prevent a potential futur conflict.
@sempervictus

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link
Contributor Author

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

This comment has been minimized.

Copy link
Contributor

wvu-r7 commented Jun 20, 2013

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

@agix

This comment has been minimized.

Copy link
Contributor Author

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

This comment has been minimized.

Copy link
Contributor Author

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

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link
Contributor Author

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

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link
Contributor Author

agix commented Jun 28, 2013

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

@wvu-r7

This comment has been minimized.

Copy link
Contributor

wvu-r7 commented Jul 2, 2013

Probably!

@agix

This comment has been minimized.

Copy link
Contributor Author

agix commented Aug 27, 2013

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

@todb-r7 todb-r7 referenced this pull request Sep 5, 2013

Merged

Retab/pr/1850 #4

agix added some commits Sep 10, 2013

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

This comment has been minimized.

Copy link
Contributor

mubix commented Nov 7, 2013

Whats left on the task list for this pull?

@agix

This comment has been minimized.

Copy link
Contributor Author

agix commented Nov 7, 2013

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

@limhoff-r7

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link
Contributor Author

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

This comment has been minimized.

Copy link
Contributor

wvu-r7 commented Nov 8, 2013

Hi.

@agix

This comment has been minimized.

Copy link
Contributor Author

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 referenced this pull request Nov 20, 2013

Merged

Refreshed service payloads #2657

7 of 7 tasks complete
@agix

This comment has been minimized.

Copy link
Contributor Author

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

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link
Contributor Author

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
You can’t perform that action at this time.