Security → Collaborative Security: Invite 2 HASH PotLuck Dinr

As I alluded to last week, PSloss and I are hard at work on the next version of SecCheck (our Windows forensic scanner)...we've gotten the first phase done and are now looking to populate our SHA1 Hash database from the user community (so that we can know which files we can and can't be trusted).

Here's your chance to help by participating in what I'm calling a Hash PotLuck "Dinner" of sorts..you know, that's where everyone brings a small dish to make a larger meal (ok so my humor is super-dry). We need the SHA1 hashes from as many systems as possible in order to build a central store of trusted files.

We've totally automated the collection process into the new SecCheck Collector/Forensic scanner which you can get
here

After download:

Click: Do Check
(wait 30s - 1 minute while info is collected)
Click: Submit results to mNW
(wait 10-30s to upload)

After submission the app will pop a browser window to a SubmissionStatus window...the backend server will process your submission in 1-2 minutes...refresh the page after a while to see how the hashes collected on your system compare to those submitted to others.

Here's the report from my own system so you can see what it looks like:

»seccheckuploadv2.mynetwa ··· ionID=68

GREEN shows files where *multiple* users have submitted the same hash, so file is much more likely legit.

YELLOW shows files where you are the only one reporting that hash, so file can not be assumed to be legit. This doesn't mean it's malware, but may just be exotic stuff that not many are running. In the report from my system above you see Ethereal stuff all over the place.

The makeup of this report will change overtime as more and more folks submit hashes, so you may want to refresh the page a day or so later and you should see more GREEN and less YELLOW.

You can also see the entire hash database collected so far here:

»seccheckuploadv2.mynetwa ··· List.jsp

Right now we've got data from about 25 systems...we need hundreds in order to properly identify "legitimate" executables...so please take a few minutes to contribute.

The SecCheck .eXE contains can also be run in text mode vs. XML...feel free to use the 'Do Text Check' if you want to produce more human-readble output for your own use in cleaning systems.

As not everyone here knows about myNetwatchman, would appreciate if a few long-timers may drop a few kind words so everyone knows this whole effort is legit.

Thanks in advance for all your help.

Having been a myNetWatchman contributor for several years, I will state that it is quite legit. If you're concerned about the legions of botnets continually probing your firewall, but not interested in manually reporting them yourself, MNW is an excellent way of aggregating your observations with thousands of other MNW contributors.

Not too many ISPs will be interested in your solitary report of a handful of probes that you recorded, but a MNW intrusion report, aggregated from a dozen or so MNW members, might get their attention.

If Lawrence and Philip are now asking for software hashes of our systems, so they can generate a database of normals, and then work on Windows forensics, I'm happy to contribute. And you should do so too. All of us could benefit from this.

Well I contributed to the cause, a worthwhile effort.
When I was useing ZA I reported regularly, unfortunately I started useing Sygate and it wasn't supported.

Not sure what those yellow AVG files was all about but there ya have em. Personally I don't ever remember AVG catching any virus.

It doesn't work (it runs but doesn't collect data) on Win9x system, if at all matters. Otherwise i'll submit from other systems

edit: correction it doesn't display the data (in the box) but it does save it to xml and clipboard

Cudni

After ya wait a lil bit ya hit refresh and it will show the data.

If you have problems, please post what your SubmissionID was so I can look it up.

We're having some problems with character encoding when users are in foreign character sets...I'm assuming this was the case here...

UND-DESKTOP

If so, I manually deleted the offending character and then it was able to process.

SubmissionID's 78 & 79. Same results. Seccheck saved and executed fronm the Desktop.

Refresh after a couple minutes.

Tossed my bit in the pot. I received a browser could not start error after submission. IE shows xml file as text even if I allow active-x. Where in the file do I find the submission #?

Agent Sunday_Money reporting for duty.

Submission ID 88 & 89 no dice.

SubID 82 killed the parser Batchjob due to a file length problem...I fixed that and restarted...every through 89 is processed now.

We're up to 8869 Hashes (started the day with about 7000).

Keep it coming.
Once we get this encoding problem fixed it shouldn't get stuck anymore.

To Machine Name: KAI
SubmissionID 86

What is:
/windows/system32/XPupdate.exe ???

It's a relatively new file, you're the only submitted for this hash, and has a suspicious name.

Here's the startup key for it:

localaudit133443

You've also got a 'winupdate.exe' that looks questionable.

Suggest you virus scan each of these files manually with:

»virusscan.jotti.org/

They are both worms / Trojans, spreading through shares. Winupdate.exe is also a remote access Trojan allowing complete remote control over the system.
XPupdate

Could be, but you really can't go by the file names.

Eventually, we're going to enable seccheck to copy all the active files back to the central repository too...then we can do centralized virus scan on them and provde any detected signatures back in the report...thus enabling user virus scans without even having to download a scanner.

FileID:443
path: C:\WINDOWS\system32\xpupdate.exe
Size: 81100
SHA1: C08B434D5E8D1493C9DE402986828B5B3B316215

If we already have the hash in our database and it's scanned..then even the server doesn't have to scan it again...this should enable a partial virus scan *of just active files* within 1-2 minutes. Try that with a traditional AV scanner.

Thanks for the feedback; it's been a while since I've dealt with 16-bit USER heaps! The 9x edit control is probably punting on anything greater than 32K, though I haven't confirmed. On one system, I get a display; on another, it behaves just as you note.

Edit: correction, make that 64K for 16-bit edit controls.

But that error is noted; the user interface in this "demo" is too "busy" for a broad audience, so I don't know that we'd have all these intermediate steps in a practical submission UI. I'll look into displaying truncated text...

Thanks again,

Philip Sloss

What's this acronis thingy I see so many people running?

\program files\common files\acronis\schedule2

We haven't figured it out yet but this file name is what's breaking our XML encoding...which is odd as I don't see any foreign characters in the name.

Submission ID = 95, status page gives list length of 0 and no data...

I saved the XML to my local HD and can send again if need be. O/S is Win95SE if that makes any difference...

Some kind of disc imaging software.

»www.acronis.com/

Thanks for your work !!

Did you mean Win98 Second Edition?

If not, I don't think we'll be able to support anything earlier than the original Windows 98 release, at least not initially. Can't remember the functionality differences between Win95 OSR2 and Win98, but there were a couple of issues, I believe.

Philip Sloss

Strange: if I give us the benefit of the doubt and assume that we're collecting the information correctly, here's what we got:
...which would appear to be a strange variant on HTML encoding in a text string, roughly:

Oddly, there's no consistency in the way they are using different space characters. In that string, two are the "non-breaking" type and the third is not. In other strings, there are no non-breaking spaces.

At any rate, it's just an encoding issue for us.

Philip Sloss

Sub ID 99 sent, no display for me.

I do have Japanese language support...

Hi Lawrence and Philip,

Please allow me to make a little side-note, with all due respect.

There are security-programs that might not be so easily recognised.
I prefer not to name them in public.

example # 1
When a new version is published, it usely gets another name and installs by default in another directory.

example # 2
The .exe file is different for every user.
When installed in a non-default directory, it is not so easily recognised in your database.


Cheers, Jan.

Sub95 was our first Win9x submission and it broke the parser...I cleared it out and now 95-103 have been processed, plz. recheck your results.

Thanks for playing...we're now at 9961 hashes.

When a file is *scored* only it's hash is used...so if others have reported the same hash, the file will show Green regardless of what DIR it's in.

We only bothering to keep track of the directory path for our future plans to enable acquistion of the files themselves into the repository.

Curious if I could guess at one of those programs, I downloaded and ran the latest version of what I am thinking about.

Then I reran SecCheckUI, and submitted the results as #102.

And now I see why it was an hour before I saw any results. And it wasn't me.

This is an idea whose time is overdue!
I hope the variety of path names, file names, and flavors of windows, do not sink it. I would suggest that you should probably run more than one checksum on each file, to defeat the inevitable case where someone can engineer malware that produces the same checksum as a legit file.
You should also package the uploader to be smaller and more efficient so that people can leave it running - in return for it doing automatic alerts when it sees a checksum has moved from green to yellow or worse - they you'll get a more steady stream of data.

OK, I'll ask away. How many users are we talking about when we say "Multiple"? But more importantly what if multiple people are infected with the same worm? It's not uncommon to have thousands of people having the same worm. Is it going to turn green and be marked as legit?

Right now it seems like yellow is 1 and green is more than 1. Which means it is useless. But they are collecting data. I suppose after a while they can raise the standards to get a green on the assumption that "certified good" checksums will be in the vast majority.

That is precisely the plan for the "Pro" version. Basically something that'll run one or more times/day..can compare a prior state to the current state and give you a report of what's different, etc...

Say 1000 people submit hashes, say 500 are all running the same Windows OS and SP level..and more or less the same patch level. For the entire group of OS files you will have 500 of 1000 people all submitting the same hashes..or a 50% corroboration.

With malware the number of people infected with any given malware will be much smaller (even if ALL the people providing submissions are infected with at least one thing). So you might have 10 of 1000 infected with Sober.x, 5 with Sober.y, etc... You'll get some corroboration, but the % will be much lower than legit, so all it takes is setting using a reasonable high threshold.

Additionally, our next step will be to enable incremental collection of any file whose Hash we don't yet have in our File Repository. We will then virus scan all files in the repository, thus mapping Hashes to virual signatures. If a Hash has a viral sig then that will override the simple hash corroboration.

Lastly, you'll notice that the XML output captures the TCP table activity on the subject system...we'll be running this through an analysis process to identify executables which appear malicious *purely based on their behavior*...eg: foo.exe is generating outgoing TCP/445 SYN requests to 10,000 distinct target IP addresses..the Hash for foo.exe will then be flagged with that behavior which will then override hash corroboration and will suplement any viral sig. Of course the beauty is, even if there is no viral sig, we'll still have it flag as malicious based on it's behavior.

The bottom-line of all this is we should be able to analyze any system in 1-2 minutes and identify malware (even if no AV vendor knows about it). It will NOT identify malware anywhere on the system...only *ACTIVE* malware...or inactive malware that is in the startup path.

Yeah, this'll be fun.