AutoIT Exe trying to access the internet?

[DavidLago]

I have no idea how to even start to describe it...

I have an AutoIT script that works a "RunAsWait" with a different user (DOMAIN\ControlTeamUser) on a 7zip.exe with a parameter to extract a file and read its content to an array. Works perfectly.

But the networks team found a crazy behavior in the Firewall. 

When the button that triggers the RunAsWait line is pressed for the first time, lots of access requests from the computer's IP address appears shooting at random external IP Addresses (Some of them point to Akamai's IPs), the crazy thing is, it runs under the user DOMAIN\ControlTeamUser (yeah, like wtf!!??!!)

I thought it would be the 7Zip trying to look for updates or something, but there's more. If you uninstall 7zip and run the script again, it won't find the 7z.exe, and there will be an error, of course, but, some requests still come up at the firewall, and if you ping 8.8.8.8 from a mere CMD window, it hits the firewall as the user DOMAIN\ControlTeamUser.

Crazy, right?

Have ANY of you ever seen anything like this crazy behaviour? Maybe there is a known issue...

[iamtheky]

How are you authenticating that user?  Posting your script always helps, but I imagine you would see the same traffic if you tried to simply authenticate to a file share and that you are seeing an LDAP configuration moreso than an autoit configuration.

[DavidLago]

boththose, I'll post the lines that make the crazy things happen:
 

$Descompactador = IniRead("CONFIG.ini", "CONFIG", "Descompactador", "")

While 1
    Local $file = FileFindNextFile($search1)
    If @error Then ExitLoop
    $ultima_pasta = $file
WEnd

FileDelete(@UserProfileDir & "\" & $NomeArquivo)
$pass = decrypt("?????????????????????????????????????????ENCRYPTEDPASS??????????????????????????????")
RunAsWait("ControlUser", "DOMAIN", $pass, 2, @ComSpec & " /c " & "copy " & $Caminho & "\" & $ultima_pasta & "\" & $NomeArquivo & " " & @UserProfileDir & "\" & $NomeArquivo, @UserProfileDir, @SW_HIDE)
$pass = ""
RunWait($Descompactador & " " & @UserProfileDir & "\" & $NomeArquivo, @UserProfileDir, @SW_HIDE)

 

And, actually, the RunAsWait only does a file copy. The 7z.exe ($Descompactador) is only called at the RunWait.

[iamtheky]

And, actually, the RunAsWait only does a file copy

So....I win?   How about making a single line script that does nothing but authenticate this user and ping 127.0.0.1,  and then another that simply pings 127.0.0.1.

that way we can maybe isolate it to the authentication.

Im also going to take a not so wild guess that your enterprise is using Office 365.

Edited November 25, 2015 by boththose

[DavidLago]

So....I win?   How about making a single line script that does nothing but authenticate this user and ping 127.0.0.1,  and then another that simply pings 127.0.0.1.

that way we can maybe isolate it to the authentication.

Im also going to take a not so wild guess that your enterprise is using Office 365.

Well... I think we're looking through different angles. Let me explain again.

This file copy needs to happen, and needs to be done with that specific user, because it will reach a file that is in a specific app folder within a server, in which only this user has the permissions to access it.

What is troubling me is that after running that RunAsWait copying the file from the server to the local computer, all outside traffic (such as a ping request to 8.8.8.8) turns to be requested through the user from RunAsWait.

My guess is that, somehow, the RunAsWait invokes a User/Pass ticket within itself, or within the OS, that stays in memory and messes up or mixes up with the Windows ones, hence the ping 8.8.8.8 hitting the firewall as the Generic "ControlUser".

But I've never seen anything like it.

 

 

[iamtheky]

What account are you logged in as when you execute this script?

To confirm your suspicions, you should write a script that runs Dir.    What I imagine is happening is @UserProfileDir is eating your lunch, use literal paths or variables you acquire while in the shell.

[DavidLago]

Hey there.

Got it. It might be happening. I compiled a new version with some changes, and also, another one changing the auth method from 2 to 1 as below:

 

RunAsWait("ControlUser", "DOMAIN", $pass, 1, @ComSpec & " /c " & "copy " & $Caminho & "\" & $ultima_pasta & "\" & $NomeArquivo & " " & @UserProfileDir & "\" & $NomeArquivo, @UserProfileDir, @SW_HIDE)

Let's see how both tests will come out.

Thanks.

Edited November 26, 2015 by DavidLago

[iamtheky]

I would recommend consolewriting or msgboxing that command directly prior to its execution, so you are absolutely positive that all variables and macros have the expected value.  Then comment that biatch out when everything is all clean.

Edited November 26, 2015 by boththose

[DavidLago]

I think I've found where the problem was. I'll have to run some tests to confirm it first, but it seems that the problem sits within the Firewall config. Something user-cache related.

[DavidLago]

Just an update.

Still confirming...

[DavidLago]

OK. Firewall was the issue. Some specific setting displays the user that is running the request for the internet (any), and that's not reliable. For example. ping requests do not send username embedded, and the firewall was recognizing an username. I assume these are caused by a cache or something. Anyway, that's not an AutoIT bug.

Thanks for everyone (Iamtheky) that helped.

[iamtheky]

no worries, did you by chance get any PCAPs or events that popped?  I would be interested in the enterprise firewall trigger, we just dropped some new PaloAltos and I would want to see if the same traffic appears.

Thank you for the follow up, most users are not as helpful when having to research themselves.

Edited December 11, 2015 by iamtheky