If the IP ID sequence is predictable and sequentially increasing, you can do a zombie / idle (port) scan with Server B.

You can also spoof your source port, as Server B, however if you want a reply, you need to send a packet with your IP in one of them as well.

If Server B is completely secure and you just want to use it as a tunnel to send data through but you don't have access to Server B, I'd say you're trying to use a functionality which isn't built into the TCP/IP protocol stack yet but also potentially for illegal purposes as in spoofing malicious traffic from one host to another.

I suggest you learn what spoofing does and how it works. There is a difference in spoofing and hijacking. When you spoof, you're pretending to be someone you're not.

You --> pretend to be 1.1.1.1 --> send traffic (easy to do)Recipient --> responds to 1.1.1.1 --> this response will NEVER get to you

But anyway, to make you understand why this won't work, I will now hurt your eyes with an explanation. If you can't understand based on the information I post here, I suggest you go read the RFCs on networking and SIP. Further, there is no absolute mechanism via the PSTN for someone to track an IP from a call. A carrier can, enduser can't. But here goes. So I decided to give you a breakdown of how the call would work and why it would fail.

The follow illustrates a call between extension_1000 (71.111.222.33) and extension_2000 (214.21.111.23) - the two addresses you used for your examples. You want to trick server C into thinking you are server B (214.21.111.23) So let's make this call:

In the midst of this, you need to insert yourself between this connection to see this going on. Not on the same network? Good luck, you now have to hijack *something* to get inside that stream. May I suggest you go read some RFCs now. Understanding SIP and VoIP help more than spoofing. Even if you COULD hijack a session, what will you do for NAT, SRTP, TLS, and if the PBX has any redirects or proxy-auths?

Not trying to sound smug, but you seem to not have understood what is involved. Anything is possible however, you're looking at it via the wrong approach. With the explanation I've given you, you should now look into what I meant by inserting yourself along the path. And that wraps up my response.

That obfuscation contains everything you need to know. The new problem/lesson for you would be how to un-obnfuscate it to get your answer. And I ask those here who may know how to solve this riddle keep the answer to themselves. I will throw an olive branch:

sil wrote:I suggest you learn what spoofing does and how it works. There is a difference in spoofing and hijacking. When you spoof, you're pretending to be someone you're not.

You --> pretend to be 1.1.1.1 --> send traffic (easy to do)Recipient --> responds to 1.1.1.1 --> this response will NEVER get to you

But anyway, to make you understand why this won't work, I will now hurt your eyes with an explanation. If you can't understand based on the information I post here, I suggest you go read the RFCs on networking and SIP. Further, there is no absolute mechanism via the PSTN for someone to track an IP from a call. A carrier can, enduser can't. But here goes. So I decided to give you a breakdown of how the call would work and why it would fail.

The follow illustrates a call between extension_1000 (71.111.222.33) and extension_2000 (214.21.111.23) - the two addresses you used for your examples. You want to trick server C into thinking you are server B (214.21.111.23) So let's make this call:

In the midst of this, you need to insert yourself between this connection to see this going on. Not on the same network? Good luck, you now have to hijack *something* to get inside that stream. May I suggest you go read some RFCs now. Understanding SIP and VoIP help more than spoofing. Even if you COULD hijack a session, what will you do for NAT, SRTP, TLS, and if the PBX has any redirects or proxy-auths?

H1t M0nk3y wrote:Sil, I can only imagine what you dream about at night...

Oddly, no matter how hard I try, I can never recall dreams unless they're vivid dreams. Most times I don't even know. Side note... So this 300GB disk went bonkers on me (bad sectors, etc.). Not a big deal, I'll just take a forensic image and retrieve it all. Popped open FTK 1.x (3.2 with Oracle is horrible!). Anyway... 48 hours later, nice forensic copy... Neat! Let me run it through FTK for data retrieval now.... 6 days 1 hour 22 minutes later? Still churning.

Frustrated with the timing, I whip open EnCase Enterprise Edition... No need to acquire image, just mount the darn drive:

New CaseAdd DriveSelect Drive

Oh, there are my folders. Right click copy folders.... Its now copying files with an elapsed time of 18 hours 22 minutes.

Lessons learned: Don't become too comfortable/reliant on tools. I love FTK (per 3.2) which made me lean on its use. I use EnCase to validate what I find with FTK and vice versa, but mainly rely on FTK for most forensics operations. I will now take a step back and swap between the two. EnCase for immediate viewing, FTK for large acquires, sorting post mounts.