Hidden folders in unix?

Hi,

At my place of work, we were hit by some crackers, and they placed movies, copywrite material, and all that good stuff that we can get in trouble for. We finally found out because someone told our ISP that we were distributing their material, and we quickly found it and took it off. The thing is, they kept doing other stuff to our system like uploading more files and sending out spam. We kept getting rid of these files, and finally today we came accross a hidden .config directory which contained a ssh. What I am wondering is how were they able to hide it from Root? We were able to see everything else in this directory but that .config directory. Also, any advice on how to set up a honeypot to find out where they are connecting from?

Thanks ahead of time.

Hi Madseel,

I'd guess you're using some sort of GUI to browse your filesystem? AFAIK, most GUI's in Unix don't display hidden directory's by defualt, much the same way Explorer doesn't by default in Windows. If you're using the CLI, then just a simple ls wouldn't display it. You'd have to use ls -a. The -a is for all, it doesn't hide directories with a '.' in front of them. I would be a little hesitant about deleting a hidden config folder unless you know for sure it was the hackers/crackers who put it there. You might inadvertnely delete some files you need.

As for the honeypot, I have no experience setting them up, but I'm sure someone else here can help you with that. Try googling for it.

Thanks,
The thing is that I wasn't using a GUI, I was using a shell and it still didn't find it. ls -a and also ls -R still won't find any of it. How in the world can you get it to do that?

Thanks again and ahead of time.

Two words answer:

rootkit: reinstall


Ammo

I don't understand why this post hasn't generated more interest.

Although I have more questions then answers, maybe answering them will get things rolling a bit more ( although I think ammo hit the nail on the head ).

How did you find the hidden directory?

What permissions and ownership did it have?

Do you have a baseline to compare the box to? ( Do you have checksums of the system files when originally installed, maybe tripwire files stored on write-once media, etc. ?)

What type monitoring and/or IDS do they have in place? How are the logs stored, and where?

What is your company's position concerning pursuing prosecution?

What is your position/responsibility in the discovery/remediation?

Does the company have an Incident Response Team ( or any Incident Response Procedure? )

What has been done already?

( And BTW, where in the network is this box located ? )

Setting up a Honeypot is useless to “ find out where they are connecting from? “ That is not what they are designed for. Even if you get a hit there is no way of knowing if they are the same ones that compromised the system in the first place.

If your company is looking to prosecute the offenders they should have called in professional help before now ( but better late then never ..... at least you may learn something for the next time. )

Even if all the company wants to do is stop it ( are you subject to any laws concerning disclosure of breaches, accounting, etc.? ) I would not recommend ( my preference ) reinstalling at this point. I would replace with an up-to-date box ( all security patches, possibly updated OS, etc. ) which was locked down, then use the rooted box to try and find out what was exploited and how, and did the new box fix the holes? ( Remember, this may preclude prosecution. )

Any CISSP people out there want to jump in?

Maybe these links will help you learn how to respond:

CERT® Security Improvement Modules

First Responders Guide to Computer Forensics

Although root operates outside of the security policy, root still uses whatever applications you have on the system to perform its tasks. Consequently, while it will have access to the hidden files, if (to be simplistic here) the application "ls" has been modified by the attacker to not display their files... all the rights in the world are not going to make ls show those files.

Understand?

Take care that the config file isn't genuine... odds are if your standard ls will not display it, even with the -a flag applied, it is not to be trusted. However this may just be there to throw you off track. Your best bet is to boot with a live CD, an use trusted utilities to verify the system. If you cannot do this (you never made a checksum map of the system when in a trusted state) your best bet is to do a complete reinstall.

A reinstall may sound dramatic, but it sounds like you've already tampered with the system since the compromise, so the system is of no use to law enforcement, so really no point in seeing where the traffic goes (although you can do this with an external router/firewall/IDS) and really no point in trying to track down exactly what has been corrupted. Clearly, no offense intended by this it is a complicated task, you are not up to the job (else you wouldn't be asking here). Just burn any data to CD/tape, format the drive (sanitize the cache on the NIC if you are feeling extra paranoid) and load from a trusted source.

Sanitize the data before putting it back on the system.

Lastly a bit of advice... if you can't secure what you've got... don't tinker with honeypots.. you'd just be asking for trouble.

cheers,

catch (CISSP per iknownot's request ;) )

Quote:

---

Originally posted here by ammo
Two words answer:

rootkit: reinstall


Ammo

---

All about Rootkits: http://en.wikipedia.org/wiki/Rootkit :D
It sounds like a kernel rootkit in this case. The Wiki link above has some links to Rootkit detectors for Unix but I don't know if they will also remove the rootkits.

I am not that familiar with Unix but I do know one golden rule: avoid being 'root' on those systems, like you should avoid being an 'administrator' on a Windows system, basically because these are super-user accounts that have (almost) free access to everything. Thus, if you execute malicious code, that code will have full access too. But I don't think I have to tell you that since you already know that. Right? :D

Ok. The way we discovered it was through a virus scan we ran off another machine. We have contacted the FBI and they have been helping us through this. The file's permission was root, and the box was in a DMZ. We have no baseline to compare it to, and we are now barley starting to secure our network and computers a lot more tighter. The things they did when they were accessing our server was sending out spam,scanning other systems inside and outside our network, and uploading copyright material so others could access it.

anyone else wanna bet that you have more than one infect machine on that network now? Id start scanning if I were you.

After an obvious reinstall, consider using tripwire next time and monitor it. Tripwire will alert you to any file changes that occur, tipping you off that something is happening to your system before you have legal issues that you have to address.

The honeypot idea. Like it was said before it won't help you find out where they are attacking from. Also there can be some legal issues with setting one up to trap someone. It is much the same as entrapment by law enforcement. I will say I like honeypots but there has been a lot of legal controversy over this.

Quote:

---

The honeypot idea. Like it was said before it won't help you find out where they are attacking from. Also there can be some legal issues with setting one up to trap someone. It is much the same as entrapment by law enforcement. I will say I like honeypots but there has been a lot of legal controversy over this.

---

Honeypots are nothing like entrapment. Entrapment would be if a law enforcement officer was telling you to hack the system. Sine a honeypot is a private endeavor and is a passive system... clearly this does not apply.

People need to seriously stop giving legal advice when they haven't got a clue.

cheers,

catch

Quote:

---

Thanks,
The thing is that I wasn't using a GUI, I was using a shell and it still didn't find it. ls -a and also ls -R still won't find any of it. How in the world can you get it to do that?

---

Then how did you find the files?

catch - if Iwere to setup a honeypot in my environment, someone could use it as a legal defense of entrapment.

Quote:

---

People need to seriously stop giving legal advice when they haven't got a clue.

---

I in no way was giving legal advice. What I was saying is that there are in fact some legal issues with honeypots. If it is a private endeavor then go for it, but for corporations and especially government entities then there are legal issues.

cashmoney,

Like catch said, entrapment IS like an officer telling you to steal. A honeypot is like a bait car - that is, a car the police leave on the street with the keys inside and visible, then wait for someone to steal it. Legally, I believe they are two completely different concepts.

IANAL, however.

-ik

ik - i'll buy that. sorry if I offended anyone, by the looks of my only antipoints now gone I must have.

Just an obvious question.

Was the distro you were using kept up to date with security patches etc.

Most distros have tools for that.

Doing so, along with other sensible measures (see many tutorials on this site), will keep your vunerabilities down to a minumum.

I know if my home server wasn't kept up to date it would have been compormised long ago.

Steve

As stated earlier, the trouble your experiencing is most likely being caused by a kernel mode rootkit... If it is a desperatley mission critical machine, there is one thing you could 'try' to remediate the problem. Since rootkits typically patch the system call table, to redirect or 'hook' calls, you could try to backup an un-patched/infected table. Obviously, the most reliable solution is to completely reinstall... i just thought i would input my 2 cents. Hope it helped.

- shell

Ok, An update to this whole situation. We were able to determine how they got in and all the files that they loaded. We have cleaned up most of the mess. Thank you everyone for your help.