Based on provided information I suspect that the used method here is Dynamic forking of a process or as it also know process hollowing. The idea is to execute some arbitrary process in suspended state and replace its "guts" with the contents of another executable image. In general the idea could be implemented as following:

1. Use the CreateProcess API with the CREATE_SUSPENDED parameter to create a suspended process from any EXE file. (Call this the first EXE).
2. Call GetThreadContext API to obtain the register values (thread context) of the suspended process. The EBX register of the suspended process points to the process's PEB. The EAX register contains the entry point of the process (first EXE).
3. Obtain the base-address of the suspended process from its PEB, i.e. at [EBX+8]
4. Load the second EXE into memory (using ReadFile) and perform the neccessary alignment manually. This is required if the file alignment is different from the memory alignment
5. If the second EXE has the same base-address as the suspended process and its image-size is <= to the image-size of the suspended process, simply use the WriteProcessMemory function to write the image of the second EXE into the memory space of the suspended process, starting at the base-address.
6. Otherwise, unmap the image of the first EXE using ZwUnmapViewOfSection (exported by ntdll.dll) and use VirtualAllocEx to allocate enough memory for the second EXE within the memory space of the suspended process. The VirtualAllocEx API must be supplied with the base-address of the second EXE to ensure that Windows will give us memory in the required region. Next, copy the image of the second EXE into the memory space of the suspended process starting at the allocated address (using WriteProcessMemory).
7. If the unmap operation failed but the second EXE is relocatable (i.e. has a relocation table), then allocate enough memory for the second EXE within the suspended process at any location. Perform manual relocation of the second EXE based on the allocated memory address. Next, copy the relocated EXE into the memory space of the suspended process starting at the allocated address (using WriteProcessMemory).
8. Patch the base-address of the second EXE into the suspended process's PEB at [EBX+8].
9. Set EAX of the thread context to the entry point of the second EXE.
10. Use the SetThreadContext API to modify the thread context of the suspended process.
11. Use the ResumeThread API to resume execute of the suspended process.

So, to answer your question I firstly suggest to verify that this indeed happens. Secondly, if it does you can do the following to break on the new created thread entry point. The proposed way is not the only one, but IMHO will be easy done taking into account your relatively small experience in RE/executable analysis:

• Check the PoC to actually get the full understanding of the whole process.

1. Place BP on SetThreadContext. The second parameter is CTX variable which holds among various aspects of the thread context, also the address of the thread function.
2. In the nutshell, you need to examine CTX.eax to get the address of the thread function. For example 0x00402030 is the address you've found there.
3. Download and install ProcessHacker and with its help, examine the address space of the suspended process. Open the memory page to which the thread function belongs to - Right click on process -> Properties -> Memory. For example page 0x00400000.
4. ProcessHacker will show you the memory page with local offsets to the page. You will need to go to the offset 0x2030.
5. Patch the 0x2030 with 0xEBFE (remember the previous byte), this makes the thread loop indefinitely - jmp 0x00402030.
6. Now, resume the parent process and attache the new instance of Olly to the suspended process which now is already running. Go to the EP and patch back to the original bytes.
7. Good luck with the analysis.

I hope this is understandable otherwise ask and I'll clarify.

Credits for the Dynamic forking explanation goes to Tan Chew Keong.