Possible Sandboxie breach

You're not the only one. I've managed to get a couple of, albeit older, Gapz samples and they do nothing in the sandbox as far as I can see (admittedly not very far!).

Sorry, I know I'm a fanboy but I'm beginning to think this is a bit of red herring. No one other than the 'trustable' source is seeing this. Anyone else notice even Buster is now calling this a POC rather than malware? Could it be it only runs in SBIE with BSA? (this is not meant ad as a challenge just a genuine wish to understand what the issue is here)

Thanks

 

I could see it running inside the v3.76 sandboxed environment on our old XP machine for a few seconds, then disappear. After reboot and a virus scan nothing seems amiss. Maybe the attack vector that uses the dropper and shellcode injection is more successful?? Oh well. Will probably test later on the machine with the latest beta.

EDIT

actually it installed fine in the XP Pro VM unsandboxed. Of course I had to Run as... Administrator from the LUA. After initial installation MBAM detected 2 files, then after a reboot it found 6.

Code:

Memory Processes Detected: 0
(No malicious items detected)

Memory Modules Detected: 0
(No malicious items detected)

Registry Keys Detected: 0
(No malicious items detected)

Registry Values Detected: 1
HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run|SOPAgent (Backdoor.Bot) -> Data: C:\Documents and Settings\All Users\Application Data\SOPAgent\sopag_jcxejjs.exe -> No action taken.

Registry Data Items Detected: 3
HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Advanced|Start_ShowHelp (PUM.Hijack.StartMenu) -> Bad: (0) Good: (1) -> No action taken.
HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Advanced|Start_ShowMyDocs (PUM.Hijack.StartMenu) -> Bad: (0) Good: (1) -> No action taken.
HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Explorer|NoSMHelp (PUM.Hijack.Help) -> Bad: (1) Good: (0) -> No action taken.

Folders Detected: 0
(No malicious items detected)

Files Detected: 2
C:\Documents and Settings\All Users\Application Data\SOPAgent\sopag_jcxejjs.exe (Backdoor.Bot) -> No action taken.
C:\Documents and Settings\username\Local Settings\Temp\VMwareDnD\d7d332b9\sbie malware.exe (Backdoor.Bot) -> No action taken.

(end)

This just goes to show how malware, at least some of it no doubt, utilizes user space (non protected) directories to its advantage, which is why I've taken steps to lock them down as much as possible with anti-executable technology.

 

tzuk allready got this POC i expect news very soon

 

Agreed. And I think it's a bit naive to believe that personal bias & grudges don't come into play in such matters, no matter how reputable the person may have been up to that point/and still may be for that matter.

I'll believe it when I see it with my own 2 eyes.

 

Common ground and clarity

Cheers

 

Great news Installed .04 and all is well.

(formerly LWS)

 

My Facial expression is just this No other words needed.Ok maybe one --- BRAVO

 

According to Buster, this story isn't over yet. Tzuk says it is.

Anyone knowledgeable enough to test it out? Where are you daredevil? Appear.

 

Come on m00nbl00d, go for it

 

The response has been kind of hilarious on all sides other than Busters.

And then people telling Buster that it's *his* responsibility, of ALL people, to provide a POC to test Tzuk's product.

I'd be laughing but... eh. I'll just resist saying anything other than that this is one of the funnier disclosures I've seen.

 

Two conditions are required:

1) I'd need the executable already compiled.
2) A spare machine

If someone kindly gives me 2), maybe Tzuk would give me 1). Otherwise, me's eating some cooked chicken while the story evolves.

 

If this is the quote you are referring to, I can't see where it's referring directly to Buster or where you'd have an argument with asking the person alleging the breach to prove his claim:

 

The responsibility should always be on the guy trying to sell you something. Not the guy trying to help out by reporting an issue, not the users of the product, not anyone else. It's that simple.

 

Then you don't disagree since the post is clearly asking for that very party to come forward and furnish the alleged proof rather than have Tzuk (and others) jumping through hoops needlessly.

A standard of proof is always required whether in a court of law or pursuing an inquiry via scientific method.

 

I think you misunderstand what I mean by sell - I don't mean that the burden here is the guy trying to help the project by showing a flaw. Tzuk has the product, so the responsibility is on him, in my opinion.

But that's just my opinion. I've got **** to do, and defending it isn't on my list of things to get done.

 

Well, I certainly wouldn't want to keep you from your busy schedule.

I'll close by saying that I believe Tzuk will make a good faith effort (as he always has over the years) to determine if there is a breach which needs to be closed. That said, it's the responsibility of the party making the allegation (if he is acting in good faith) to ensure that Tzuk has the material and data required to replicate and identify the issue.

Out.

 

Absolutely the person originally making the POC claim should come forward with it. No one should have to act as the intermediary for this person.

 

This is as clear, concise and correct a statement on this topic that could possibly be made.

 

The guy/gal in question, who no one knows who he/she is, already provided the source code for the PoC in question. What more do you folks what, really? Those with the skills to compile it and fix any possible bugs in it (if any), then do the testing. I don't think this is about taking sides (IMHO).

I'd do it on my own, if I had enough skills to do it (especially to fix bugs). I'm just waiting for a result, as a user.

The person is unknown, but the PoC is known. The PoC is what really matters, no? Not if who found this is known/unknown.

 

Hmm. The whole things seems pretty simple to me. Tzuk has no responsibility to fix a problem that doesn't exist. The POC author has no responsibility to give a POC that works unless he wants to see a fix for it.

Maybe I am missing something, but it seems pretty clear cut.

Sul.

 

He who alleges must prove -- Immanuel Kant (1724-1804, German philosopher).
Science cannot prove the non-existence of absolutes. Neither can Tzuk or anyone else for that matter. Thus, putting the burden on Tzuk would tantamount to gross injustice.

 

Did you miss the bit where the POC was given to him?

1) POC given to Tzuk
2) Tzuk states it's fixed in 4.0
3) Developer of POC tells Tzuk via user that it is not fixed

Users then state that Tzuk has no responsibility to provide proof or some such nonsense and that... it's up to the guy who already provided the POC.

...

Are we all reading the same topic?

 

No, I did not. They are a response to your comments at posts 38 & 40. The matter is actually quite simply this: Trust Tzuk, and continue using SB, or trust developer of POC and stop using SB. I do not believe in demanding a security product developer to prove beyond all doubt that his product works perfectly, all the time and anytime. Btw, i did buy a lifetime license of SB. I have already got my money's value way back.

 

lol, if you are speaking to me, no I didn't miss the topic. To me it seems pretty clear. As I said, if there is a legitimate issue, it should be fixed. It doesn't matter who made the POC or why, or who is stating it isn't. If "they" want the author to fix an issue, "they" should give him a way to recreate it. If he cannot, and "they" won't give him a POC, then thats thier decision. If they do provide him with it, then one would think he "should" fix it, which I am sure he would/will.

I certainly don't understand a lot of the "other" stuff going on here. Its all tertiary to the real issue.

Sul.