SSJ like alternative setup's

Haha, sounds good mate. But are you saying that you're using Sandboxie + LUA + SRP, as well as Malware Defender? If so, your setup will involve much more computer "house-work" than mine, and it certainly will not be "set and forget".

In terms of preventing malware infestation (assuming you have a good "security approach"), it will be just as secure at blocking/containing ALL malware threat-gates and attack vectors as my setup - in fact, arguably you'll have an even stronger setup, since you'll have another layer of defense in using Malware Defender haha. I hope you know what you're getting yourself into mate!

And you gotta love that "automagic" stuff!

 

MD is running only on my VBox guest, although I also have SuRun+LUA+SRP on it as well, so maybe it can be considered overkill with a bit more housework, but I like it because if I ever want to venture into dark territory such as playing with malware or in evil sites, I should be more than adequately covered Alerts are not all that frequent any more with MD, but of course occasionaly it complains.

On Host system: Sandboxie+SuRun+LUA+SRP, so I guess our security platforms are fairly similar.

For extrteme playing, yes, I'd say my VBox guest system is pretty robust

Absolutely!

 

The only reason for using MD in a Vbox would be to analyse the file's installation and running behaviour. MD does not make your VM any more secure than it already is (particularly if you're running it sandboxed haha).

Also, why are you wanting so much security in a VM?

And yes, all classical HIPS always become fairly silent after a while. And then you update an application...and the "house-work" begins again haha.

 

May be Sully or TLU can comment on this, as far as I know

- Sudown = Run AS with current user profile
(so it would make scanlog in USERS\LUA username\

- Surun = taking an admin and stripping it from admin rights, while providing
ad hoc elevation (more like UAC) therefore creates scanlog in USERS\LUA username\

- Run as = default OS, would use the admins profile, so it would create
the scanlog in USERS\ADM username\

- Advanced run = same as run-as with the difference that it facilitates
short cuts, scripts, file command and can start an admin with different
priveledges (e.g. not allowed to load driver) profiles

With advanced run you will stay a real LUA, f.i. you can't access the control
panel, but yu can access individual options through the default scripts.

I have ditched the image allready so can't check for you.

Regards Kees

 

Tommorrow I will make a script that gather the SID and compile it so that everyone can test thier implementation out to see just what hive is loading for what runas implemenation. It will be an enlightening experience I am quite sure. Good thought Kees.

Sul.

 

Interesting you say that, and I note that's how the SuRun tutorial instructs to install it here:
http://www.dedoimedo.com/computers/surun.html

However, that's not how I implemented SuRun myself. Instead, I followed tlu's instructions (at least I think that's what he instructed) of creating a fresh LUA, installing SuRun in my admin account, adding my LUA to the "Surunners group" and simply using SuRun as required after logging back into my LUA. As you can see, this doesn't involve taking an admin and stripping it from admin rights at all. Or have I missed something here?

 

Okay,

I see that is good practise (off course TLU ), start with a LUA.

You have not missed something, that is the way to go.

Cheers

 

Wow, fast reply, and thanks for the confirmation Kees.

 

Not the only reason but a valid one for sure, and that's one area where it excels. A good example is a quick test of apparently rogue software discussed here. Not only could I see what the software was trying to do system-wise during install, but MD alerted on the domains it tried to connect to; Russian Federation, U.S., China in particular. Of course a software firewall could have helped here on the latter area as well, but MD's network control is sufficient for this purpose.

I'm not so interested in making the VM more secure as I am about checking on a program's behaviour which I'm doing, admittedly, mainly for interest sake. MD gives one a sort of “looking glass” into what, exactly, a program is doing within the system, not only during installation but afterwards as well. All behaviour – whether suspicious or not – is revealed to the user. And as I've stated many times before regarding HIPS, they make a great learning tool for this very reason as well.

Good to know, because that's also how I'm using Surun

 

Whatever takes your fancy haha. For me, realistically and honestly, I'd struggle to see where I'd actually use a classical HIPS to analyse a program's behaviour in a VM before I trusted it - I just couldn't be bothered! For example, here's how I picked out a DVD burner program:
https://www.wilderssecurity.com/showthread.php?t=254925

All I did before installing ImgBurn on my real system was scan it with Avira with highest heuristics, upload it to Virustotal (it scored 0/41), and use my common sense when looking at their web-site. I did test it in a VM first, but it wasn't really to analyse its behaviour (I don't have the expertise to know exactly what's going on anyway, and even if I did, I don't think I could pick out EVERY malicious event). Anyway, since Wilders recommended it, I felt safe enough to use it. It all comes down to that "milk analogy" I've made a few times before. How far are you going to go before feeling safe enough to drink the milk you bought from the supermarket?

As for knowing which domains it connects to, here's where I'm lacking knowledge. How do you know for sure if the domains are malicious/fake or not? For example, what domains does Avira connect to? Thanks.

Yes indeed, but that's not what you were implying when you said you were using LUA + SRP + Malware Defender in a Virtual Machine haha. On your real system, it sounds like we have the same setups. Don't forget to enable maximum hardware DEP also, and there's no harm in applying KAfU in your LUA!

 

Your reasons are understandable and valid, but I like the fact I'm at least somewhat enlightened to common - or uncommon - program behaviour, especially during the install process. Knowledge is, after all, power. Using av like you do is fine but I don't see where anything of even remote value is learned by the procedure.

It's not important, really, as to knowing whether or not they're malicious, it's the fact that only a few seconds (it installs almost immediately) into the installation the program is already attempting network access to not one, but several ip's, especially ones spanning the entire globe! This is not normal behaviour, in my books anyways, for a typical installer. Not only that, Malware Defender will alert to other unusual behaviour such as accessing physical disk, physical memory or low level registry - to name only a few. Granted, some of this could legitimately occur, such as with disk backup software (direct disk) but but most of it is suspicious behaviour for the majority of installers.

Well, my reasons already stated above

Yes, similar at least. I think we somehow indirectly bounced a lot of ideas off each other and when the dust settled, we landed in almost exactly the same spot. But for some reason I don't think either one of us is quite finished yet

 

Yes indeed. I used to test applications and analyse behaviour with classical HIPS too, and I found it interesting for a while. Now I guess I'm over it haha.

Yes, that's the problem I have. I can't know 100% for sure whether it's legitimate behaviour or not. A lot of malware won't behave so obviously that it's clearly malware etc. As I said, it's just how far you want to go before gaining "peace of mind" to use a piece of software. After all, we do far more risky things in our lives than using software haha. When you think about it, it's amazing how much trust we put in our local food stores, restaurants, traffic lights, doctors/surgeons etc.

Similar? I can't see how it's any different haha. And you're the one that seems to be experimenting still. I finished about 3-4 weeks ago - haven't changed anything since. It's all working perfectly, so there's just no need to! Glad you discovered how good SuRun is.

 

I have been playing with SSM in a vmbox in report mode only, just so I can do a quick review of what a new program did. Not always can you trust every executable, and you often find great little tools in the strangest places. It is easy to see if a program installs drivers or services, or tries to phone home, but some of the more subtle things it might do a HIPS will tell you. I don't want to stop it from doing its thing, I just want to see what happened so I can make my own decisions. It is not overkill for an unknown program, but yes for things that are widely acceptible like imgburn, it is not really needed if the trust level is high.

Sul.

 

Sounds like a good "security approach"! Well, if I ever discovered a "great little tool" in a strange place, I'll just PM you to test it for me haha. Rarely does anything extra make it on to my real system nowadays anyway. I know exactly which software I need/prefer, and they are all trusted stuff.

 

It is true we trust the milk man, but we also have many advocates on our behalf to try and ensure there is a standard for cleanliness or business practice. Do you think the same type of protection exists for software? LOL.

Having a 'piece of mind' for programs with great user base reputations is easy. If you are willing to limit yourself to use only those programs, then you don't have an issue really.

However, if you like to try out new programs, always looking for something really neat, you have a problem. You can google it, find reviews etc, but you will not always find what you need. For example, I found a little program called Qdir the other day. It is a pretty nice tool. I also found a program called Pismo File Mount. I did not even bother to google them, I loaded them up in vm and tried them, with some logging. I also tried out TeraCopy. That program is recommended by many here, and it is a gem. But I used my vm again. Not that others here are not to be trusted, contraire I believe most here to be astute at spotting lame software and they voice it. But I don't really want something isntalling until I know what it does. My system is clean and runs well, poorly coded software that is sluggish etc I don't like to use. So I test.

I guess I also don't trust the milkman either. When I open milk, I smell it first, drink second. Paronoia exists in real life too. But I don't smell my beer before I drink it, I just make sure its ice cold.

Sul.

 

Good points mate haha. And gotta love ice cold beer!

But it's not just about milk mate. What about our beloved McDonald's? Who's to say some kid in the background isn't spitting into your burger etc haha.

With regards to advocates, well, you can be my personal advocate for software haha.

Yes, I still test software in a VM too - I tested peguard just a few days ago. The point I was making is that for me, rarely do I need to install software on my REAL system. This is simply because I'd only use it once...see it's pretty cool, and say bye bye to it haha.

Regardless, I guess everyone (especially those who don't use a VM to do testing) should be using some sort of rollback system like CTM or EAZ-fix. That way, you can test all you like on your real system and be fairly confident of rolling back cleanly.

 

I like regfromapp http://www.nirsoft.net/utils/reg_file_from_application.html also

You can even run it and have the registry changes saved in a old and a new reg file.

available for x64 and x32

 

Thank you Sul. You explained it better than I could

Good for you, buddy For me the learning process marches on. As for SuRun, awesome little utility

 

A fun little project Kees has me started on, comparing the loaded hives to the contextual creator of a process, then comparing the groups that particular SID is belonging to. It will take a few different executables to work in all the options you mentioned Kees, but it will shed some light on the whole aspect of what profile is really loaded when doing elevations, as well as how SuRun operates, or the others. Profile elevation is way different that spawning with different credentials, as will be exposed. If I have time tonight I might have it finished. I have to look up some return values I have never used before, but good clean fun

Sul.

 

Thx Sul, really appreciate you are putting time in it.

In the mean time I have set up my wife's pc as limited user. With DefenseWall V3 there is no need for another security program (just ad hoc a2Free, Hitman Pro and Autorun). So I created a 'console' folder with short cuts, simply using XP's run as for maintenance and backups.

When you think of it, simple set of short cuts and XP's run aswith your Pretty Good Security (this is an XP Pro rig), would be suffcient for average user.

 

Well, it would seem what I thought would be an easy do is not so easy at all. I was thinking to pull the SID (that is the registry hive really) of the creator of a process, pull thier name, group(s) they belong to and whether the account SID is an admin or user, or surunner or sodoer, etc. It would have made for a nice little learning tool. Instead, I am the one learning about how hard it is to actually enumerate such things LOL.

So my test ended up as a very simple one, check for the username of the user starting a process and grab thier SID and simply check for IsAdmin(). Not too fancy, but I suppose it works.

I will just tell you what I found.

In a LUA account, using standard RunAs -- the account you are using to start the program is loaded and that account is active. If the account is admin, then the program starts as admin.

In LUA, using Advanced RunAs -- the same thing, whichever account you use for credentials its registry hive is loaded, and all parameters within it are used.

In LUA, using SuRun -- this time the user account is the account being used, the logged in LUA one, but it is 'promoted' to admin status to start the program. This keeps all the hive info current and correct.

In LUA, using SuDown -- this is the same as SuRun, where the account (LUA) is promoted to admin, thus keeping the hive setttings.

Some may ask, what is this about. I will explain what I know, others probably know more.

When a user is logged in, thier registry HIVE is put in place as the 'current config' or 'current user' or even referred to as 'user'. When you load a HIVE it has a SID, a type of GUID. Your users HIVE means that when you refer to desktop, the registry HIVE loaded knows it is different from others.

When you use a common RunAs, the account you are using has its HIVE loaded. What this means is basically for a very brief period, the 'logged on user' is this other account. Whatever rights or ownership this other account has is active and current. So for example, if you are running a program from your desktop as an admin, say it is called ProgramA.exe. Now you want to RunAs this ProgramA.exe, and you want to run it as a user account you have. (Normally you may not want to run it as a user, but this is an explanation, so bear with me).

Anyway, when you try to RunAs a user, the user does not have rights to peer inside of the admins desktop, so you fail to start ProgramA.exe. Because when the user HIVE is loaded, the process and environment are temporarily at the RunAs users level. If that makes sense.

Moving on, when SuRun or SuDown 'RunsAs', it is not loading a different HIVE, but mereley quickly and temporarily chaning your current users rights from limited to administrative. This has the advantage of still keeping all the users environment the same so there are no issues.

So Kees you are correct in your explanation. What I did not find out is what happens to a user in SuRun/SuDown as far as which group they belong to, and what is happening on that end. I will wait until I sort out enumerating SID/Groups and then do something more indepth. Actually a person might learn a lot by examining what SuRun and SuDown actually do when they are installed. That will be next on the list

Sul.

 

Hi Sul,

thanks for the research and explanation. It sort of makes sense to me although it's a bit difficult for me to grasp it all as a whole; Parts of it kinda skim over my head but I think I got the gist of it

Oh, on the quote, I have Malware Defender in my VBox setup to start automatically with elevated rights in my User account and never ask for password (so I don't have to enter it every login), and also to start Automagically (LOL!) with elevated rights. Now I assume this means only Malware Defender is elevated to admin status, and not any part of the user account, correct? Thanks!

 

Thx very much Kees and Sully for the detailed explanation. Confirmed what i imagined and added alot more of information.

I wish in some future the default scheme of Microsoft accounts works like this.

Surun is a little jewell.

 

A couple things.

First, when you use the 'automagic' part of SuRun, you provide it with an admin username and password so that it elevates some .exe to admin. This is handy, but you do run the risk of the .exe in question being able to do what it pleases and leaves you no recourse to 'stop' it. The idea of prompting is to let the user say 'yes or no'. The convenience of this feature is immense I understand. It is highly likely that one will never encounter an instance where some program that is 'automagically' allowed will be rogue, but you understand that giving carte` blanche admin rights should be selective.

And regarding the elevation, once a process is elevated via alternate credentials or a temporary promotion of rights, it is only that process that stays elevated. Anything the elevated process itself starts (child processes) will inherit the promoted rights. The rest of the environment shifts back to the normal logged in users rights. In the case of SuRun and MD, your account is elevated to admin to start MD, then demoted back to Luser, so anything started 'normally' is still Luser. Anything MD then starts will inherit the rights of the admin group, unless otherwise specially handled.

Sul.

 

Up till now MS figures there are normally admins and users for most people. The domain introduces much more complex groups and rights, but most people don't need that. Indeed the whole aspect of SuRun is not itself a great thing in terms of security. It is a convenience for those that must do admin things often from LUA.

Think it through, if you are LUA, and you use RunAs to start some program, you have just given the program root. If you are LUA and you use SuRun to start some program, you have just given the program root. If you are admin, and you start some program, you don't need to do anything else, and you have just given the program root.

So when you elevate to admin, there is no difference than being admin for all practical purposes. Of course, before anyone fumes, we are not talking about chaning the system time, but of executables or files that you don't really know for sure what they will do.

SuRun is a great convenience tool for those people who do a lot of admin stuff while in LUA but don't want to be admin all the time. It sure beats right-clicking the RunAs all the time. But I think everyone should understand it is not necessarily more 'secure' depending on the circumstances.

Sul.