Hacking attempt, what were they trying to do and how can I check if they succeeded?

I recently asked this question: Attempted exploit?

But as I checked the logs some more I found out that they've been doing some more stuff and I felt that it would need a new question to cover them all.

First of all, my log has a couple of thousant logs from today. There must've been a couple of thousand requests per minut.

Question 1: The logged IP was our hosts IP. How could they've spoofed this or did the hacking attempt come from inside their network via an infected computer?

Question 2: I have a logged error:

The state information is invalid for this page and might be corrupted.

The logged path for this one was:

OurURL/?ctl00$ctl00$ctrlheadermenu$ctrlsearchbox$btnsearch=sã¶k&ctl00$ctl00$cp

Also, I found this in the stack trace:

The input is not a valid Base-64 string as it contains a non-base 64 character, more than two padding characters, or a non-white space character among the padding characters.

What were they trying to do with this?

Questi开发者_如何学Pythonon 3: I also found a request to this page. Where they trying to list our content?

OurURL/nessus=<!--#exec cmd="dir"-->

Question 4: There was also a request to thirl, which I found to be an attempted SQL-injection. Is there a way to check what they did? And what would it do if it was successful?

OurURL/webresource.axd?'%2bconvert(varchar%2c0x7b5d)%2b'=1

There's probably a couple of thousand logged searched and attempted urls that didn't exist but I can't list them all here.

Answer 1: IP addresses can be spoofed, though it's also possible there's an infected internal computer doing this.

Answer 2: It seems that if this is an attack, the attacker was trying to find vulnerabilities in your base64 decoder.

Answer 3: Yes, they were trying to get a directory listing with the dir command.

Answer 4: convert(varchar,0x7b5d) returns 0x7b5d type-cast to a varchar. Without any context, this doesn't really do anything. The attacker may have been trying to test if query variable names were used directly in SQL queries, without sanitisation. The test by itself does no harm.