Messages posted by: PXMMRF

mv1098 wrote:

@anh PXMMRF, conmale, bolzano_1989

Trong Windows XP đăng nhập bằng account limited

khi 1 ứng dụng thay đổi trong Registry liên quan đến HKEY_LOCAL_MACHINE hoặc liên quan đến các system folder thì nó sẽ bị limited và yêu cầu chạy trên tài khoản Administrator

Nhưng nếu những ứng dụng thay đổi trong Registry chỉ liên quan đến HKEY_CURRENT_USER thì nó vẫn có thể thực hiện được.

( ở đây là các ứng dụng chưa được setup trên Windows trước đó )

Khi dùng tài khoản limited trong WinXP (SP2 hoặc SP3)và không điều chỉnh "Security Options" trong computer management (để ở chế đô default) thì có thể cài và chạy một soft hay application trong các trường hợp sau:
- Portable soft.
- Stand-alone soft., application
- Application đươc soạn thảo dùng cho all users (thí dụ các trình duyệt)

Soft hay application không cài đươc và/hoăc không chạy khi trong quá trình cài đặt hay chạy nó phải access vào các folder/file mà account limited không có quyền mở, kích hoạt các service mà nó không có quyền, cũng như tạo một số loại registry không đươc phép....

Quay lai trường hợp cụ thể của STL virus AcrobatUpdater.exe thì:

- Khi cài vào XP với quyền Admin 1 hoăc Admin 2 (Admin1 có khác Admin2 đấy nhé) thì AcrobatUpdater.exe được cài vào thư muc C/Program files/, như anh conmale đã viết.

- Khi cài vào XP với quyền Limited thì nó tự đông được cài vào một thư muc khác: thư muc của chính user ấy trong C/Documents and settings/ và vẫn tao ra registry, đủ để active. Xin minh hoạ bằng hình cụ thể (các bạn xem cho sướng con mắt mình. Hì hì)

conmale wrote:

bolzano_1989 wrote:

Em thì vừa thấy máy tính sử dụng tài khoản limited dành cho sinh viên một trường bị nhiễm virus STL .
Có lẽ anh format ổ đĩa với NTFS format ?

Đúng rồi. Máy anh chạy XP có ổ đĩa NTFS. Mọi thứ default, chưa hề set cái gì trong policies hết. Anh vừa thử lại, chắc chắn không thực hiện được các công đoạn lan nhiễm của stl malware.

Khi format ổ đĩa với file system FAT 32 hay với cà NTFS, cài Win XP và không config. lai "local policies" (trong Computer Management----> Local policies---->Security Options) thì dù chạy máy với account limited, có thể vẫn bị nhiễm STL virus.

Cái khái niệm "limited right" trong XP khá mơ hồ và chẳng có user thông thường nào biết chuyện config. lại "local policies". Ngay cả chúng ta, muốn config kỹ và toàn bộ khoảng trên dưới 50 mục trong Security Options cho thật chuẩn, thì cũng không dễ dàng gì. Hì hì.

Tính bảo mật cao của NTFS dường như chỉ phát huy trong Win 2K và Win 2K3 (Win 2k8 thì đương nhiên rồi). Ngay việc phân chia account và xác đinh quyền cho từng loại account trong Win 2K Pro, Win 2K3 cũng kỹ và hay hơn Win XP nhiều. Điều này tôi cũng đã viết trong một post trong topic này

bolzano_1989 wrote:

Em thì vừa thấy máy tính sử dụng tài khoản limited dành cho sinh viên một trường bị nhiễm virus STL .

Đoạn viết trên của tôi mà bolzano_1989 trích ra, có thể gây hiểu nhầm.
Vì sau khi anh conmale có ý kiến nhận đinh. Ý kiến này cũng đã được bolzano_1989 trích ra sau đó (như thấy ở trên), thì tôi đã có ý kiến giải thích ngay, như sau:

PXMMRF tai trang 7 topic nay wrote:

Hì hì, câu này mình nói với ý khác. Vì axasin thông báo là cài cái Malicious Unikey mà bạn ấy download về chỉ tạo các file virus MSHelpCenter.* trong Windows 7 thôi , còn trong Win XP thì không được (nghĩa là Win XP thì không bị nhiễm virus khi cài malicious Unikey nói trên). Vì số người ở VN dùng Win 7 còn ít, nên tôi suy diễn tiếp theo ý axasin như vậy (cũng có ý giỡn vui với rang0 chút chút)

Đây là suy diễn theo nhận định của axasin. Chứ tôi đương nhiên là không nghĩ như vậy. Tôi nghĩ máy trên mạng VN hầu hết là cài Win XP và tỷ lệ máy cài Win XP bị nhiễm STL virus-trojan là rất cao.
Cần nói thêm là hiện đang có nhiều loại (version) malicious Unikey và Vietkey trên mạng. Malicious Unikey mà axasin cài khác với của lequi đã cài. Còn có nhiều malicious Unikey khác trên mang nũa. Kinh!

Các bác STL đẻ ra nhiều đứa con hoang quá, nay chúng thất tán khắp nơi, từ Nam chí Bắc Việt nam, đến tận Mỹ, Đại hàn, Châu Phi, Lào.... Mới đây lại thấy chúng ở Sing nữa. Nhiều con quá, nên chẳng còn nhớ hết tên chúng, cũng không biết đứa nào ở đâu, để goi chúng về nhà.

Nhiều đứa con nay thấy bơ vơ, không biết tìm bố mẹ nơi nào. Có lúc bố chỉ đường về nhà, nhưng về đến nơi thì nhà đã dọn đi chỗ khác mất rồi. Không ít đứa cả mấy tháng nay chẳng thấy ai gọi tới, không đươc cung cấp "thưc phẩm", tiền bạc, nên sắp chết đói hết rồi. Tình thế quả là rối bời bời. Hì hì!

lequi wrote:

@Anh PXMMRF: Bot của STL sử dụng các browser có sẵn trên máy để DDOS hở a ?

Các header trong các gói tin của STL DDoS đến muc tiêu như vừa qua thì không thể nào tạo nên hiệu quả crawling các link hiện hiện trên URL bị DDoS vào. Muốn crawling thì phải có thêm những command cần thiết kèm với header.

Theo em nghĩ, crawl cũng chỉ là 1 quá trình duyệt 1 website, parse nội dung HTML của trang đó, và lấy hết những href link trong trang, rồi tiếp tục request đến các href link đó thôi mà ?

@texudo: Hình như việc thay đổi User-Agent không liên quan đến việc server tạo ra thread khác đâu bạn.

Đúng như vậy, hay chính xác là tôi nghĩ như vậy. Các scenarios DDoS trước đây và ngay cả trong trường hơp Flash DDoS (hay còn gọi là X-Flash DDoS) vào HVA các năm trước đây, đều thông qua trình duyệt. Sự sử dụng các User Agent string trong các header của các gói tin DDoS vào mục tiêu và nhắm vào cổng HTTP 80 TCP là chứng cớ điển hình của quá trình DDoS thông qua trình duyệt Web. Khi đó trình duyệt sẽ liên tục kết nối với cổng 80 của webserver, đông thời mở rất nhiều thread (trên may client) khi kết nối

Quá trình crawling trên một URL mục tiêu thì đúng như bạn nói. Chỉ có điều quá trình crawling không thưc hiện bằng manual (user click vao các link hiện diện trên URL) mà là tự động, khi check bảo mật một webserver hay khi DDoS với tốc độ chậm, châm mà sâu mà dễ gây quá tải (như anh conmale đã từng nói)

Khi crawling tự đông thì máy của user cũng chiu tải năng và đăc biệt webserver cũng chịu tải rất nặng nên dễ crash. Vì sao? Vì trình duyệt của user phải mở liên tiếp nhiều URL khác nhau cùng một lúc. Còn webserver phai liên tục trong cùng một lúc chuyển nhiều URL lên cho trình quản lý web (Apache) để cho "hiện" ra tại máy user.. Việc đó làm tốn rất nhiều năng lưc (tài nguyên) của hệ thống trong một thời gian ngắn, hệ thống rất dễ quá tải hay buffer overflow.
Cần phân biệt giữa file (hay process) download các file malicious image để update STL virus, như file Acrobatupdater.exe và file sẽ kich hoạt trình duyệt DDoS vào HVA. Khi RCE anh TQN cũng chưa nói rõ về file kích hoạt này.

Còn trên máy thí nghiệm của tôi, như tôi đã nói, Acrobatupdater.exe không thể nào kết nối được với một master webserver nào của STL. Vì vậy tôi chưa có thông tin thưc tế về một process nào đó chịu trach nhiệm về việc kích hoạt trình duyệt DDoS vào HVA ((hoăc giả nó tự kết nối -DDoS vào HVA mà không thông qua trình duyệt). Mấy hôm nay con Acrobatupdater.exe lai chẳng chịu "active" nữa. Hì hì. Hôm trước có lúc Acrobatupdater.exe mở đến 50-60 thread kết nối với master.

Đúng như em đã nói, User Agent string không có liên hệ gì với việc trình duyệt mở thread kết nối hay mở bao nhiêu thread.

Như chúng ta đã thấy qua quá trình RCE của anh TQN, STL có khá nhiều webserver,, trên 10 webserver, chuyên dùng làm master-webserver,, chỉ huy và điều khiển các cuộc tân công DDoS vào các trang mang VN. Nạn nhân mới đây chính là HVA. Nạn nhân mới nhất là Vietnamnet.net. Hôm nay trên báo SGGP, Vietnamnet đã xác nhân thông tin website này bị DDoS. Việc bị DDoS đã làm cho website này luôn bị quá tải. Việc truy cập đến các trang của website khá chậm, đăc biệt là các trang đăng tải các hình ảnh.

Tuy có nhiều master webserver như vây, nhưng thưc tế gần đây STL chỉ sử dung thường xuyên một số master website-webserver. Chúng là:

- second.dinest.net
- map.priper.info
- speed.cyline.org
- net.iadze.com
- một, hai website-webserver khác

STL thường chuyển nhiệm vụ thường trực chỉ huy điều khiển mang bot (in-charge) từ webserver này sang webserver khác, nhằm làm chúng ta bối rối trong việc theo dõi. Ngoài ra chúng còn thay đổi cổng truy cập, thí dụ từ 80 TCP sang 8080 TCP hoăc sang 443 TCP HTTPS.... Gần đây STL cũng đã dời webserver second.dinest.net từ một địa chỉ IP tĩnh cũ sang một đia chỉ IP tĩnh mới, để đánh lạc hướng người theo dõi.

Các webserver nói trên hầu hết hay tất cả chỉ hosting (đặt) một website duy nhất làm nhiệm vụ master webserver cho mang bot. Các webserver nói trên đa phần là các dedicated server (server thuê riêng), chỉ một hai cái có thể là virtual server ( Hai hay vài virtural server cùng trên một máy chủ).

Để theo dõi, điều chỉnh, bảo dưỡng, giải quyết các trục trăc về KT và hành chính từ xa (remote management) tất cà các master webserver nói trên thường xuyên, hàng giờ thì chắc chắn STL phải cần ít nhất là từ 3-4 người có trình độ KT khá và tương đối thông thao ngoai ngữ (English). Thông thao đươc hiểu là trao đổi đươc qua phone, khi khẩn cấp và qua email. Chứ không phải là người có trình độ tiêng Anh ngớ ngẩn như một thành viên non nớt của STL viết một câu tiếng Anh dớ dẩn như vừa qua.
Ai đã từng đặt một webserver ở nước ngoài đều biết rõ và trải nghiệm điều này.
Chi phí thuê nhiều webserver đặt ở nước ngoài như STL đang làm, không hề nhỏ chút nào. Ai đã thuê dedicated server nước ngoài cũng biết rõ điều này. Các chi phí phụ, cần cho webserver hoạt động ổn định thường lai khá cao.

Để làm được rất nhiều việc như ta đã thấy hiện nay (không chỉ theo dõi quản lý các webserver, mà còn nhiều việc khác, như viết, sưu tầm các mã virus, trojan, tổ chưc và thưc hiện việc gây nhiễm hàng trăm ngàn máy zombies ở VN và nước ngoài với virus tạo ra, theo dõi hiệu quả của quá trình....) STL cần nhiều nhân lực. STL cũng còn phải có một nhóm chuyên đọc, theo dõi nôi dung và các bài viết trên rất nhiều website, blog trên mạng, để quyết định hay xin chỉ thị cấp trên là đánh (DDoS hay khui thông tin cá nhân nói xấu người chủ trì trang mạng) ai? Đánh như thế nào (đánh cảnh cáo- có thể như với vietnamnet.net, hay đánh cho sụp hẳn -như với HVA)? Đánh thật hay đánh giả? (Đánh giả để che giấu mục đích thật, sâu xa của STL)..... Các bạn thử đoán xem cần bao nhiêu người để làm cho đạt yêu cầu (của cấp trên) việc này?.

Nếu ai đó nói về một vài công việc khác mà có thể STL đang làm, chúng ta có thể phải kinh ngạc về khôi lương công việc họ phải làm và thán phục về ý tưởng sâu xa, thâm hiểm của họ.

Tôi nghĩ rằng STL là một tổ chức khá chặt chẽ, với biên chế hàng chục người, có thể lên đến 40-50 người, kể cả cấp trên trực tiếp. Tất nhiên STL gồm nhiều thành phần trong đó có vài bạn nhỏ VN biết ít nhiều về virus, nhưng dại dột trong cuộc sống. Nhưng cũng có những những người có trình độ khá, hay rất khá về virus, IT hoặc có những ý tưởng độc đáo, thông minh. Vì vậy không nên đánh giá STL quá thấp, như một số bạn đã viết. Cũng không nên đánh giá quá cao, để sợ.

Quay trở lai các master webser-website của STL, tôi upload lên đây một số hình ảnh. Qua đó các bạn sẽ biết nhiều thông tin về chúng, trong đó có các vị trí đia lý đặt các webserver này

conmale wrote:

Chào anh PXMMRF,

Botnet của stl sử dụng một file chứa một đống User-Agents và hiệu lệnh để tấn công. Zombies có thể được gán random User-Agents hoặc một User-Agent cố định nào đó. Botnet của stl không tuân thủ các ấn định chung cho "crawler" thông thường. Chúng không hề thăm dò "robots.txt" mà chỉ đập thẳng vô các URI nào đó và từ đó tiếp tục crawl sâu vô trong. Bởi vậy mới tạo tác hại lớn.

Với bots của stl, cho dù các zombies có check "robots.txt", việc áp dụng ACAP cũng không có tác dụng gì cả bởi vì zombies sử dụng low-level socket API để tạo requests đến mục tiêu. Ở level này, những ấn định và ứng dụng có trên trình duyệt hẳn hòi (như IE, FF, Chrome....) hoặc ở các crawlers thật thụ đều không có ý nghĩa đối với zombies stl.

@ TQN: thật ra các websites và blogs bị stl "dán bùa" lên thì ít nhất 70% là của người Việt trong nước chớ chẳng phải của người Việt ở nước ngoài. Ở Việt Nam, từ năm 2007 đã có những bài báo có tiêu đề "An ninh mạng và pháp lý sẽ được củng cố" và từ đó tới giờ đã hơn 4 năm, vẫn chưa thấy củng cố gì hết. Việt Nam vẫn chưa có một cái khung pháp lý cụ thể về an ninh mạng và cách xử lý với những vi phạm.
.................................................................................

Cám ơn bài viết làm rõ vấn đề của anh conmale

File liệt kê các User Agents đươc bot mới (ta còn chưa biết) của STL sử dụng để update User Agent chắc cũng tương tự (tương tự thôi) như file User_Agent.txt trong Malzilla. (Khi cài Malzilla trên các OS Windows server , như Win 2K3 thì việc lưa chọn User Agent theo ý người sử dụng soft. mới thưc hiện được. Còn cài Malzilla trên các OS khác như Win XP thì dường như tiện ích này không thưc hiện được)

Tuy nhiên, theo tôi cho dù STL virus-trojan có một file User Agent.txt như nói ở trên, thì nó vẫn phải có một tool hay codes để change user agent string default trong các trình duyệt IE, FF....
Vì nếu không customize (tức là change) User agent string trong IE, FF thì các trình duyệt này vẫn gửi các gói tin DDoS đên mục tiêu với User Agent string măc định của trình duyệt, thí dụ:

Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20100101 Firefox/5.0 Firefox/5.0
Mozilla/5.0 (Windows NT 5.1; U; rv:5.0) Gecko/20100101 Firefox/5.0 ............

Trên nền Windows, tool nói trên,nếu có, chắc phải thưc hiện các bước công việc trình tư đại thể như sau:

Command Prompt---->GPEDIT.MSC -->User Configuration -> Windows Settings -> Internet Explorer Maintenance -> Connection--->User Agent String--->Customize string --->insert new User Agent string (chọn cố định hay chọn random một User Agent string trong file "User Agent.txt" nói trên)-->OK

texudo wrote:

Như anh conmale đề cập bài trên, thì STL chọc vào 1 page rồi từ page đó sẽ có các link tới pages khác của site hiện tại, crawl tiếp vào các links này...mức độ thiệt hại của website sẽ càng nặng nề hơn.

Các header trong các gói tin của STL DDoS đến muc tiêu như vừa qua thì không thể nào tạo nên hiệu quả crawling các link hiện hiện trên URL bị DDoS vào. Muốn crawling thì phải có thêm những command cần thiết kèm với header.

TQN wrote:

Tới ngày hôm nay, 16-08-2011, host map.priper.info không còn trả về flower.bmp và aqua.bmp nữa, nginx trả về "404 Not Found".
Kiểm tra trên robtex.com, thấy có điều lạ là host: E9tn.com lại có cùng IP với map.priper.info. Cái này thì em không hiểu, các bác rành về network giải thích giùm em.
...................................

Website-webserver map.priper.info sử dụng IP tĩnh là 208.115.200.206, đặt tại Dalas, TX, USA
Hostname (resolved) là 206-200-115-208.static.reverse.lstn.net. Webserver này hiện chỉ hosting 1 website là
map.priper.info. Chú y vào lúc này webserver chỉ mở cổng 8080 TCP (Nghĩa là web server NGINX version 1.10 đươc config. tai cổng nói trên)

Còn E9tn.com sử dụng IP tĩnh 184.22.201.232, webserver cũng đặt tại USA. Hiện webserver inactive (offline).
Ngoài E9tn.com, còn có khoảng 8 đến 9 website khác cũng hosting trên webserver này, như mantean-enfants.com, pp3x.info...

Người (hay tổ chức) sở hữu domain E9tn.com đúng là "DAHAI HUANG". Ngoài domai này "DAHAI HUANG" còn quản lý khoảng 3939 domain khác.

conmale wrote:

Vừa phát hiện một botnet khác sử dụng User-Agent "Accoona-AI-Agent/1.1.2 (aicrawler at accoonabot dot com)". Sau đây là danh sách 300 IP dữ dằn nhất (chủ yếu là từ VN). Nếu anh chị em nào thấy có IP của mình nằm trong danh sách này, xin vui lòng liên hệ trực tiếp với tôi qua PM. Cám ơn.

113.160.101.152
113.160.110.89
113.160.111.68
.............................
58.187.96.164
66.110.121.148
71.21.15.74

Cám ơn thông tin của anh conmale.
Tôi có vài ý kiến sau:

1- Chắc là STL đang áp dụng kỹ thuật "User agent spoofing" cho mạng botnet mới này.

2- Như vậy trong virus -trojan của STL phải có một tool (hay codes) thay đổi (change) IE' User agent string hay FireFox' User agent string, áp dung cho mọi version của IE hay FF.
(Xin TQN và acc chú ý điều này khi RCE các virus của STL)

3- Việc "User agent spoofing" có lẽ để vượt qua một vài rule nào đó của bác conmale config. trong Robot Exclusion standard (robots.txt), tai web root. Ngoài ra việc spoofing User agent cũng làm cho các tiện ích quản lý user của website như Sitemap, Weblog... sẽ mất tác dụng hay giảm tác dụng

4- Tôi chưa hỏi anh comale về sự có hay không việc áp dụng ACAP (Automated Content Access Protocol) plug-in với robots.txt ?

5- Về riêng cái user agent khá đăc biệt trên đây của STL "Accoona-AI-Agent/1.1.2 (aicrawler at accoonabot dot com)", thì aicrawler at accoonabot dot com là một email: aicrawler@accoonabot.com và Accona là tên 1 công ty có website là www.accona.com (chuyên về web search engine, có chi nhánh tai Thương Hải TQ). Công ty này đã đóng cửa từ lâu và một công ty khác đã mua lai. Tôi đang tìm hiểu về mối liên quan đến một web crawler nào đó, có hay không?

6- Trong các đia chỉ IP nói trên thì đa phần của VN (ở cả 3 miền Bắc, Trung Nam do các ISP VNPT, Viettel, FPT quản lý). Có một số đia chỉ IP ở Lào, châu Phi, Nam Triều tiên...

TQN wrote:

Hì hì, angel_of_devil nhầm to rồi: CK = Cơ Khí đó anh Hai !
Làm em tự hỏi: quái, tại sao lại có Skype với Chứng Khoán gì ở đây. Em có biết chứng khoán là gì đâu ?

Vậy là danh sách bot, "mèo què" mới của stl đã có thêm các em sau, theo thứ tự từ mới đến cũ:

1. SbieSvc.exe
2. SbieMgm.dll
3. TeamViewer_Desktop.exe
4. themeui.manifest
5. uxtheme.manifest
6. TeamViewer.exe

Bà con tìm từng Exe process trên = TaskManager hay dùng tool: Process Explorer của SysInternals, Process Hacker ( http://sourceforge.net/projects/processhacker) trên máy mình. Nếu có, kill process, sau đó xóa các file kể trên đi.

Khi download Teamviewer 6 (version6) từ trang chủ của Teamviewer (Teamviewer.com) thì sau khi cài đặt trong may của ta có các file chạy là:

- TeamViewer.exe (7.816KB)
- TeamViewer_.exe (3.963KB)
- TeamViewer_Desktop.exe (2.071KB)
- TeamViewer_Service.exe (2.283KB)
- tv_w32.exe
- tv_x64.exe

Các file này nằm ở thư muc \Program files\TeamViewer\Version6\ khi cài TeamViewer6 theo chế độ "install" (nghĩa là cài vào OS) hay nằm ở C:\Documents and Settings\User\Local Settings\Temp\TeamViewer\Version6\ khi cài ở chế độ "run" (nghĩa là không cài TeamViewer vào OS mà sử dụng nó như một stand-alone program)
Vì vậy ý anh TQN nhắc xoá các file TeamViewer_Desktop.exe hay TeamViewer.exe trong máy các bạn là khi chúng đã bị STL nhúng virus vào hay chúng là virus nhưng mạo nhận tên các file chính thức của TeamViewer.
Một cách phân biệt đơn giản, nhanh chóng là so sánh dung lượng giữa file nghi ngờ và file nguyên thuỷ của TeamViewer (dung lương chuẩn trên XP tôi đã ghi chú ở trên)

Chú ý là khi ta khởi động Teamviewer trên may ở cả chế độ run hay install thì máy ta sẽ kết nối với các máy chủ của Teamviewer và sau đó máy chủ của Teamviewer mới kết nối đến máy của partener (máy ta muốn truy cập đến và theo rõi màn hình)
Thí dụ

Action:Monitored
Application:TeamViewer.exe
Access:Outbound TCP access
Object:1359 -> 87.230.74.43 (master4.teamviewer.com):5938
Time:8/10/2011 11:06:10 AM

Application:TeamViewer.exe
Access:Outbound TCP access
Object:1360 -> 95.211.37.198 (server3310.teamviewer.com):5938
Time:8/10/2011 11:06:11 AM

Chú ý teamviewer có nhiều server sử dụng các subdomain khác nhau của Teamviewer.com (thí dụ master4....). Vì vậy tên các subdomain có thể thay đổi khi ta kết nối lại. Như vậy rõ ràng là Teamviewer group có thể xem và vào máy của ta nếu họ muốn như vậy (đặc biệt khi ta sử dụng máy với quyền admin). Thế là ta cảm thấy có điều gì... lăn tăn rồi đấy. Phải không các bạn?

Vì vậy đối với các webserver, muốn remote control nó, thì không nên dùng Teamviewer. Tôt nhất là dùng card remote control trên máy (hardware) và kết nối thông qua IP, có thể dùng SSH hay Real VNC enterprise (shareware).

TIẾP TỤC THÔNG BÁO KẾT QUẢ KIỂM TRA THỰC TẾ CÁC
MẪU VIRUS-TROJAN CỦA STL

Kiểm tra và phân tích file Unikey do bạn axasin cung cấp, chúng ta có thể tóm tắt những kết luận sau:

1- Trên mạng hiện đang có rất nhiều version Unikey. Có loại không bị nhúng virus vào (như Unikey download trực tiếp từ unikey.org), nhiều loại bị nhúng virus, trong đó đa phần là virus của STL.
Việc RCE các version Unikey giúp xác định khá chính xác những version nào là malicious Unikey, version nào là origin-clean Unikey. Tuy nhiên RCE là kỹ thuật advanced, chỉ có rất ít người có thể thưc hiện. Các người sử dụng thông thương cần những khuyến cáo đơn giản, dễ áp dụng, để tránh cài nhầm vào máy các malicious Unikey (Unikey độc, có virus). Vả lại kỹ thuật RCE đơn thuần có thể không phát hiện hay chỉ ra đầy đủ quá trình virus thâm nhập và khởi phát thưc tế trong máy.
Unikey (do bạn axasin phát hiện và cung cấp) là loai Stand-alone program. Nghĩa là bản Unikey này không cần cài đặt (vào HDH) mà chỉ cần copy và paste nó lên màn hình (desktop) để chạy nó (hoăc copy folder chứa Unikey vào một thư muc trong Program Files và send một shortcut ra desktop). Dung lượng của file Unikey.exe này là 666 KB (khá lớn). Đây là điểm chúng ta cần đặc biệt chú ý
Xem hình 1

2- Khi nhấp chuột vao Unikey.exe thì trong máy xuất hiện (ngay tức khắc) một số file chính như sau:

- MsHelpCenter.exe
- MsHelpCenter.idx
- _desktop.ini (phân biệt với file gốc desktop.ini của Windows, dung lương chỉ là khoảng 1KB)
- RCX38C.tmp
- thumbcache.db

Cả 5 file này nằm trong một folder có tên là Microsoft Help, tai thư mục C;/WINDOWS/ (trên WinXP, Win2K3...). Đây là folder mới chứa 5 file mới nói trên mà virus tạo lập ngay sau khi nó vừa được kích hoat.
Chúng (5 file trên) không phải là các file sẽ đươc virus của STL download trên mang về sau này, dù dung lượng của các file MsHelpCenter,* khá lớn (8-10 MB)
Thưc ra dung lượng của từng file trong 2 file MsHelpCenter.* thay đổi theo các lần thử nghiêm. Thử nghiệm lần 2, tôi thấy dung lượng của chúng giảm hẳn, chỉ còn từ 2-3 MB.
Theo tôi lý do của vấn đề dung lương các file MsHelpCenter.* khá lớn và thay đổi có lẽ do sau khi được virus tạo lập trong hệ thống, chúng map một số file khác trong hệ thống và thu gom về một số dữ liệu , cần thiết và không cần thiết (để cho dung lương lớn hơn, người dùng không nghi ngờ)
Trong 5 file trên Avira antivirus chỉ phát hiện ra 2 file nhiễm virus là MsHelpCenter.idx và RCX38C.tmp. Avira phát hiện ngay khi files vừa đươc virus tạo lập ra.
Xem hình 2.

3- Một điều theo tôi rất đáng lưu ý là: Sau khi STL virus được kích hoạt trong hệ thống (máy), thì chúng xoá ngay (delete) thành phần virus nhúng trong file Unikey.exe, làm cho dung lương của nó giảm hẳn, từ 666 KB xuống còn 256 KB. Điều đó cũng giúp cho Unikey.exe (nay đã sạch virus) chạy nhanh và ổn định hơn, thoả mãn yêu câu người dùng (họ sẽ không thắc mắc gì).
Xem hình 3

4- Virus hay chính xác hơn là Windows cũng tạo lập các file liên quan đến MsHelpCenter.* (đuôi .pf) trong thư mục "Prefetch" tại C:/WINDOWS/. Mục đích của việc tạo lập các file .df này là: Các file MsHelpCenter.* khi khởi đông (start) trong hệ thống chúng trước hết access vào nhiều file hay một phần của các file và load các file hay các phần của files lên bộ nhớ (memory), để hoàn tất quá trình khởi động. Windows thiết lập các file .df nói trên để giúp cho quá trình khởi đông MsHelpCenter,* nhanh hơn. Các file và các phần trong files cần load lên bộ nhớ nói trên, sẽ đươc lưu trong các file .df và chúng được Windows load nhanh lên bộ nhớ ngay khi MsHelpCenter,* được kích hoạt và giúp cho quá trình khởi đông MsHelpCenter.* nhanh hơn.
Xem hình 4.

5- Process MsHelpCenter.exe đóng một vai trò quan trọng, nhưng nó là một hiden process nên khó phát hiện là nó đang chạy thường trực trong hệ thống và được load lên bộ nhớ, vì vậy việc delete nó một cách bình thường, sẽ khó khăn.
Xem hình 5

6- Khi chạy trong hệ thống, MsHelpCenter.exe tạo lập một kết nôi Internet đến một webserver. Chắc đây là một master-website. MsHelpCenter.exe mở rất nhiều thread (cổng TCP) gửi các gói tin cỡ 60B để kết nối đến cổng 80 TCP của webserver nói trên.
Đia chỉ IP của webserver nay là: 178.162.225.253, webserver này có domain là mtiw253.westhomesite.info. Tại thời điểm tôi thử nghiệm webserver này không hoạt đông (inactive-offline). Vì vậy chưa xác định được là MsHelpCenter.exe sẽ download file gì (file image gì?) về máy.
Quá trình thử nghiêm cần được tiếp tục theo dõi. Tôi nghĩ sẽ có lúc webserver này sẽ active.
Xem hình 6a và 6b

Hinh 1- Các file nguyên thuỷ của Unikey do axasin cung cấp

Hình 2- Các file mới được vírus tao lập tại Microsoft Help Folder

Hình 3- Sau khi Unikey đươc cài, phần virus nhúng trong Unikey.exe bị xoá

Hình 4- File MshelpCenter.exe....pf trong Prefetch folder

Hình 5- Hiden process MsHelpCenter.exe

Hình 6a- Kết nối Internet tạo lập bởi MsHelpCenter.exe

Hình 6b- Các packet và connection tao lập bởi MsHelpCenter.exe

TQN wrote:

Hu hu bà con ơi !
Ai giúp giùm em cái, mẫu mới của tụi stl mà em âm thầm RCE nó mấy ngày nay thì tới giờ, sau khi có kết quả, không lòi ra bằng chứng nào là mẫu đó là bot đang DDOS HVA ta ! Nó cứ đè danlambao.blogspot mà phang !

Không lý thằng AcrobatUpdater.exe vẫn còn sống ? Hay có 1 bot mới, server mới của tụi stl ????????????

Mong bà con tình nguyện tiếp tục dùng SmartSniffs, WireShark monitor xem thằng .exe nào đang connect tới HVA ta: www.hvaonline.net (74.63.219.12, 88.198.119.5, 49.212.30.177).

PS: Tội nghiệp danlambao.blogspot.com: đang trong mục tiêu nhắm DDOS và phá hoại của tụi stl xấu xa này. Bà con nào cảnh báo chủ blog danlambao giùm !

Bạn Here I am up lại file java update của bạn giúp, có thể là mẫu mới của stl ! Gấp nhé !
Cảm ơn bạn !

Nếu chúng ta không xác định, tìm được con nằm vùng trên máy victim, con bot mới được down ở đâu về, và server mới nào của tụi nó ra lệnh DDOS, thì HVA chúng ta sẽ phải chịu DDOS dài dài, và mạng bot net mà tụi nó xây dựng ở VN ta sẽ ngày càng phình to ! Tới lúc nào đó mọi máy tính của VN đều là Zombie của tụi chó stl này hết ! (sorry anh em nhé, em bực quá rồi, tụi này mặt dày lắm, chửi vậy cũng chưa ăn thua đâu. Tụi nó còn tiếp tục chơi cái trò dơ bẩn, hèn hạ này hoài.)

Theo như anh conmale thông báo thì những ngày gần đây mạng zombies tấn công vào HVA chủ yếu là đặt ở nước ngoài.

Như vậy là các user ở nước ngoài đã từng download về máy họ các software hay tool nào đó phổ biến, thông dụng và cần dùng ở nước đó, nhưng bị nhiễm virus của cấp trên của STL. Chúng sử dụng các Master webserver-website cũng đặt ở nước ngoài để update các bot, cho tấn công vào HVA.

Chỉ có một số nhỏ zombies đặt ở VN. Nhưng có lẽ những zombie này đã nhiễm STL virus từ lâu. Sau đó chúng được update để tấn công vào HVA cũng đã từ lâu và hiện nay chúng không được newly updated, nên cứ giữ configuration để tấn công vào HVA.

Vì vậy việc tìm ra Master- webserver hiện nay sẽ trở nên rất khó. Thôi thì ta phải mầy mò, cố gắng tìm hiểu, phân tích thêm vây.

Qua sự việc này chúng ta thấy người thiết lập và điều khiển mang bot ở nước ngoài (và đang cho tấn công vào HVA) rõ ràng không phải là các chú nhỏ VN, làm thuê cho STL hay các thành phần người VN trong nhóm STL. Chúng phải là các thành viên "quốc tế" của một tổ chức là cấp trên của STL, lãnh đạo STL. Nhiều khả năng là các bác người Hoa sống ở nước ngoài.

sourcefire wrote:

hic hôm nay đọc được bài này, kiểm tra lại file unikey của mình và download lại từ trên trang chủ về thì thấy dung lượng khác nhau, kiểm tra trên virustotal thì được report thế này, không biết có phải của STL không nữa:
http://www.virustotal.com/file-scan/report.html?id=9852b3c19f9cca4aa35c16f2cc54911a54c0aa7d13d232fa5adb6a62918260dc-1312720738

Đây là nguyên mẫu file unikey, nhờ các bạn kiểm tra xem phải của STL không?
http://www.megaupload.com/?d=FLM02K3G
File này mình nhớ là trước đây cũng down từ trang chủ unikey, nhưng không biết là có phải thực sự bị dính STL không nữa.

Tôi đã download bản Unikey từ link trên và mở ra xem qua. Tôi chưa có thời gian thử nghiệm thưc tế và phân tích version của Unikey này. Tuy nhiên xét về "hình thức' các file, thì dường như nó giống như bản Unikey mà bạn axasin trước đây đã cung cấp, mà tôi đã kiểm tra và phân tích. Vì vậy nó có khả năng cũng bị nhiễm virus của STL.

Chiêu nay (nếu HVA forum không bị DDoS) tôi sẽ post lên chi tiết kiểm tra thưc tế Malicious Unikey mà bạn axasin đã gửi trước đây. Có nhiều điểm lý thú và kết quả kiểm tra thưc tế giúp ta trả lời được nhiều điểm còn thắc mắc, như vấn đề liên quan đến các file MsHelpCenter.* chẳng hạn.

Xin các bạn đón đọc

THÔNG BÁO KẾT QUẢ KIỂM TRA THỰC TẾ CÁC MẪU VIRUS-TROJAN CỦA STL

Như viết ở post trên, tôi đã thiết lập một server (loại nhỏ) riêng, chuyên dùng để kiểm tra các virus-trojan của STL. Server cài hai OS: WinXPSP3 và Win2K3SP2. Cách thức kiểm tra như sau:

- Cài các mẫu virus mà bạn lequi, axasin, TQN và các bạn khác cung cấp vào server.
- Disable on-access scan hay guard của các trình antivirus để virus không bị delete hay bị vô hiệu hoá khi khởi chạy.
- Theo rõi Activities của virus thông qua firewall và sau đó áp dụng chế độ "Allow" hay "Trust this process", để không ngăn trở quá trình virus thâm nhập vào hệ thống
- Kiểm tra việc virus thiết lập các file mới, tạo lập các directory mới trong hệ thống, xoá các registry cũ và tạo lập các registry mới hay thay đổi value của registry....
- Kiểm tra kỹ quá trình kết nối trên mạngdo virus tạo lập, các thông số của quá trình kết nối (port , TCP/UDP protocol, RX-TX....) , địa chỉ IP và host name-domain của destination (mục tiêu kết nối)...
- Phân tích các gói tin (packet) của quá trình kết nối này
- Check thẳng vào các master webserver-website để có thêm thông tin....

Kết quả thì nhiều và cần được sắp xếp lại một cách hệ thống. Vì vậy tôi chỉ thông báo tóm tắt các kết quả sau.

1- File Unikey mà bạn lequi cung cấp (bạn cũng cho đó là malicios Unikey- nó có nhiệm vụ download từ mạng các malicious file MsHelpcenter.exe và MSHelpCenter.idx... về máy zombies) thưc ra không phải là một virus-trojan. Khi cho nhiễm vào máy, ngoài những file liên quan, không thấy xuất hiện các file lạ-nghi ngờ, các registry lạ và không tạo ra bất cứ kết nốimang nào (theo rõi trong 2 ngày). Tôi nhớ dường như bạn range0 cũng đã có ý kiến ờ 1 post trong topic nay, xác định đây không phải là virus-trojan.

Vậy thì thưc tế Unikey nào khác trên mạnghay một file khác mới là virus trojan của STL khi nhiễm vào máy sẽ khởi phát quá trình download các file MSHelpCenter.* hay các malicious khác về máy?

2- File AdobeUpdater.exe (do TQN cung cấp ngày 28-7-2011) đúng là một virus-trojan của STL. Khi cho nhiễm vào máy, virus này tạo lập một số file mới và directory trong hệ thống. Đồng thời AdobeUpdater.exe xoá môt số registry của hệ thống và thiết lập các registry mới, cần cho việc khởi chạy sau khi hệ thống được restart. Xem hình ảnh đính kèm. Ngay sau khi được kích hoạt AdobeUpdater.exe đã tạo một kết nối Internet đến đia chỉ IP: 193.106.175.68:80, đây chính là IP tĩnh của webserver second.dinest.net của STL, mà tôi đã kiểm tra và phân tích kỹ ở post trên. Điều này hoàn toàn phù hợp với kết luận của TQN và bạn acoustics89, công bố ở các post trên, trong topic này.

Có hai điểm cần lưu ý thêm:

- Khi đươc kích hoạt (click chuột vào AdobeUpdater.exe) thì lập tức AdobeUpdater.exe tạo ra một kết nôi đến second.dinest.net, như nói ở trên. Nhưng sau đó kết nối ngừng và không có file (data file hay image file) nào được download về máy. Có lẽ lúc này second.dinest.net tạm thời không cỏn đươc giao nhiêm vụ làm một master webserver-website nữa?
Sau một lần kết nôi như vậy, trong liên tục 1 ngày sau đó, AdobeUpdater.exe không tự đông khởi tao một lần kết nối mạng nào khác nũa.

- Thưc ra AdobeUpdater.exe đã bị Avira antivirus phát hiện ra ngay khi nó đươc copy từ một USB vào testing server của tôi hoặc khi giải nén nó trên server. Vì vậy nếu một user nào cài Avira antivirus (free edition) và up to date, thì AdobeUpdater.exe không thể nhiễm vào máy hay kích hoạt trong máy. McAfee Antivirus version 8.8 thì không phát hiện ra AdobeUpdater.exe, kể cả khi scan trực tiếp vào file
Xin xem hình ảnh

Avira antivirus (guard enabled) phát hiện ra AdobeUpdater.exe ngay khi nó đang được copy vào máy

Be noted: Bác conmale ơi. Tôi đã resize các file ảnh upload để đạt chiều ngang nhỏ hơn 500pixels, như yêu cầu. Nhưng như vậy chữ trên hình quá nhỏ, rất khó đọc. Theo kinh nghiệm thưc tế của tôi, có thể upload file hình ảnh có chiều ngang lên tới 750, thậm chí 800 pixels vẫn không có vấn đề gì, khung hình forum không hề bị phá vỡ. vÌ vậy nên hạn chế max là 800 pixels, thay vì 500 pixels. Mong bác xem lại. Cam ơn

Tìm mãi không biết từ đâu mà mình có cái domain "map.ripper.info" thay vì phải là "map.priper.info" mới đúng.
Nay đã thấy. Hì hì

TQN on 03/08/2011 14:36:37 wrote:

Xin hỏi rang0 đường link map.ripper.info được lấy từ đâu và thằng virus nằm vùng nào lên đấy down về ?

rang0 wrote:

TQN wrote:

Xin hỏi rang0 đường link map.ripper.info được lấy từ đâu và thằng virus nằm vùng nào lên đấy down về ?

Em quên mất rồi

rang0 wrote:

PXMMRF wrote:

Vì vậy vào ngày 1-8-2011 tôi phát hiện ra domain ripper.info bị suspended, thì có thể trong một hai ngay sau đó STL vẫn còn tận dụng đươc domain nay để active website map.ripper.info.

Tuy nhiên đến ngày 3-8 (hôm qua) thì domain này đã trỏ đến một trang của website của công ty SEDO

Trang chủ của website của công ty SEDO:
http://www.sedo.com/uk/home/welcome/?tracked=1&partnerid=20293&language=e

Đây là trang của SEDO thông báo bán ripper.info:
http://www.sedo.com/search/details.php4?domain=ripper.info&trackingRequestId=16343907&tracked=1&partnerid=20293&language=e

Anh ơi "ripper.info" với "pripper.info" là nó khác nhau đấy ạ.

Hôm nay cái subdomain này lại được trỏ sang con server khác rồi. Hôm trước

Code:
Trước: map.priper.info [91.121.221.222]
Hôm nay : map.priper.info [208.115.200.206]
Và malware vẫn đang được cập nhật đều :(.

Ừ khác nhau, nhiều là khác. Như là PHAM XUAN MAI với ĐẶNG THÁI MAI. Người sau là một danh nhân nước Việt, bố vợ của Đại tướng huyền thoại VÕ NGUYÊN GIÁP. Còn kẻ trước chỉ là một người dân bình thường, không tên tuổi, tuy được học hành bài bản đến nơi đến chốn (bằng cấp thật 100%), nhưng khả năng có hạn. HÌ hì.
Đùa một chút. Thôi trở lại vấn đề.

Xem lai bài của rang0 (trang 9 topic này) thì domain đúng là map.priper.info thật. Nhưng vào đia chỉ này http://map.priper.info:8080 (webserver mở cổng 8080-chắc cài Apache) thì cũng lại thấy domain này cũng bị suspended. Thôi để tôi kiểm tra kỹ hơn.
Nếu http://map.priper.info cũng đang bị suspended thật, thì những nôi dung tôi viết ở post trên liên quan đến vấn đề "suspended" vẫn hoàn toàn có thể áp dụng được với map.priper.info(trừ đoan sau nói về ripper.info domain)
Nôi dung liênquan đến suspended domain là:

"Có một số lý do khiến tên miền bị treo, trong đó lý do chính, phổ biến là người dùng (registrant) không, chưa trả tiền đúng thời hạn cho công ty quản lý domain (registrar)
...................
Domain và website mang tên domain gắn chặt với nhau, nhưng không phải là một. Vì vậy khi domain bị treo, website có thể vẫn active, nhưng nói chung chỉ được vài ngày. Lý do là việc create host hay thay đổi create host mất công và tốn thời gian (khoảng tối thiểu 2 ngày), nên registrar cân nhắc trong việc này: Họ cảnh báo tình trạng suspended để người dùng mau chóng trả tiền, như thế họ không cần phải create host lại. Đồng thời họ cũng đợi có khách hàng mới mua lại domain này thì create host lai luôn thể."

rang0 wrote:

PXMMRF wrote:
rang0 wrote:
Cùng chào đón 1 server mới của STL nào :

Code:
http://map.priper.info:8080
Đây sẽ là địa chỉ để file uxtheme.manifest_29072011 connect và cập nhật (có lẽ là để thay thế cho cái speed.cyline.org)
Domain này (map.priper.info) đã bị suspended

This Account Has Been Suspended

Domain-website này: "speed.cyline.org", vẫn đang active. Nhưng nhiều lúc kết nôi đến website này rất châm (slow connection)
Em không biết anh check cái "map.ripper.info" thế nào nhưng hôm nay em vẫn download được malware từ cái host đó :

Code:
http://www.mediafire.com/?bdk5fvj8bf8k6nr

Domain map.ripper.info là tên miền con (subdomain) của domain ripper.info. Tên miền ripper.info bị suspended (treo). Có một số lý do khiến tên miền bị treo, trong đó lý do chính, phổ biến là người dùng (registrant) không, chưa trả tiền đúng thời hạn cho công ty quản lý domain (registrar).
Domain chính ripper.info bị treo thì các subdomain của nó dĩ nhiên cũng bị treo trong sử dụng.
Công ty quản lý domain này (ripper.info) là SEDO, (Anh quốc).

Domain và website mang tên domain gắn chặt với nhau, nhưng không phải là một. Vì vậy khi domain bị treo, website vẫn có thể vẫn active, nhưng nói chung chỉ được vài ngày. Lý do là việc create host hay thay đổi create host mất công và tốn thời gian (khoảng tối thiểu 2 ngày), nên registrar cân nhắc trong việc này: Họ cảnh báo tình trạng suspended để người dùng mau chóng trả tiền, như thế họ không cần phải create host lại. Đồng thời họ cũng đợi có khách hàng mới mua lại
domain này thì create host lai luôn thể.

Vì vậy vào ngày 1-8-2011 tôi phát hiện ra domain ripper.info bị suspended, thì có thể trong một hai ngày sau đó, STL vẫn còn tận dụng đươc domain nay để active website map.ripper.info.

Tuy nhiên đến ngày 3-8 (hôm qua) thì domain này đã trỏ đến một trang của website của công ty SEDO

Trang chủ của website của công ty SEDO:
http://www.sedo.com/uk/home/welcome/?tracked=1&partnerid=20293&language=e

Đây là trang của SEDO thông báo bán ripper.info:
http://www.sedo.com/search/details.php4?domain=ripper.info&trackingRequestId=16343907&tracked=1&partnerid=20293&language=e

Note:

1- Từ ngày 2-8 tôi đã hoàn tất việc thiết lập một sever (loai nhỏ nhưng có 2 CPU) riêng, chuyên dùng để kiểm tra các virus-trojạn của STL, xác định chính xác các kết nối trên mạng của các virus-trojan này. Server được cài nhiều chương trình theo rõi mạng, antivirus, firewall tiên tiến.
Tôi đang thử file Unikey của bạn lequi trước đây đã cung cấp. Sẽ thông báo kết quả cụ thể sau.

2- Tôi đã có đủ thông tin về webserver-website "speed.cyline.org" của STL. Cũng sẽ thông báo hầu các bạn

rang0 wrote:

Cùng chào đón 1 server mới của STL nào :

Code:
http://map.priper.info:8080
Đây sẽ là địa chỉ để file uxtheme.manifest_29072011 connect và cập nhật (có lẽ là để thay thế cho cái speed.cyline.org)

Domain này (map.priper.info) đã bị suspended

This Account Has Been Suspended

Domain-website này: "speed.cyline.org", vẫn đang active. Nhưng nhiều lúc kết nôi đến website này rất châm (slow connection)

TQN wrote:

.....................
Debug, trace, capture packet của nó, ra thông tin thằng host mới của STL:

Host: second.dinest.net
IP: 193.106.175.68
User-Agent: An0nym0453
xv.jpg: 2011-07-28 09:46:58
xc.jpg: <targets><item enabled="1" threads="5" delay="5" method="GET" protocol="http" host="www.hvaonline.net" port="80" uri="/" keepCookies="1" crawling="1" referer=""/></targets>

.....................................
PS: Chỉ sơ ý bỏ qua một host trong MsHelpCenter.exe mà tụi nó nhanh chân dùng host kia liền. MsHelpCenter.exe, BackupSvc.exe mang trong người nó 2-4 địa chỉ host để download file exe bot về. Host này down không được thì nhảy tới host khác.
Cái này cũng chính là cái chủ quan của em và accxxx89 (thông cảm, tên khó nhớ quá)

Đây là master webserver mới đang điều khiển cuộc tấn công DDoS vào HVA.Từ 9h sáng đến khoảng 6.30 chiều nay, HVA bị tấn công nặng nề. Sử dung cả 2 đường cáp quang của VNPT và một kết nối 3G, mà tôi không thể nào vao đươc HVA post bài.

Sự phát hiện kịp thời các master website đang in-charge (đang làm nhiệm vụ điều khiền mang bot) là một điều rất quan trong, để có biện pháp ứng phó kịp thời.
Đúng là webserver có tên miền second.dinest.net cho đến giờ này còn đang điều khiển mạng STL bot. Mang bot đang tập trung tấn công vào HVA. Tuy nhiên khoảng sau 6.30 chiều nay master webserver này thỉnh thoảng có lúc ngừng một thời gian.

Webserver second.dinest.net này có một số đăc điểm cần lưu ý:

1-Có rất it file trong hdocs (bình thường chỉ có 1 file index.html trống rỗng dung lượng chỉ khoảng 1KB và 1,2 file ảnh .jpg. Đây là các file ảnh nhúng vào các lệnh điều khiển mang bot , được mã hoá. Dung lương các file này cũng nhỏ, chỉ vài chục KB.) Nhưng webserver này sử dụng hẳn một IP tĩnh riêng cho nó (193.106.175.168). Trên webserver, như tôi đã viết, chỉ hosting 1 website duy nhất là master website, điều khiển mang bot. Quả thật là nhóm STL lắm tiền nhiều của. STL thường thiết lập các webserver chỉ chứa một website. trong đó cũng rất ít dữ liệu (file), chỉ dùng với mục đích điều khiển mang bot hay thu thập, lấy cắp thông tin cá nhân của người dung thông qua mang bot

2- Webserver second.dinest.net này cài Linux Debian, web server là Apache 2.2.9 (Note: version Apache mới nhất là 2.2.17, như đang cài trên các webserver tôi quản lý). Webserver này chỉ thường xuyên mở 2 cổng là 80 TCP HTTP và công 22 SSH TCP (service SSH-2.0 OPENSSH_5.1p1 Debian-5). Rất khó mới tìm ra được các service tại các cổng. Service SSH thỉ STL dùng để remote control webserver này từ xa (từ xa là từ VN hay TQ chẳng hạn)

3-Có một điều đặc biệt là webserver này mở rất nhiều cổng UDP mà tôi không hiểu lý do từ đâu. Có lúc tôi thấy webserver mở tới 22 cổng UDP (có cả công 53 UDP dùng config. DNS). Tôi chắc là họ chưa có kinh nghiệm trong việc bảo mật webserver và config. nó. Việc này sẽ mang đến những hậu quả không ngờ cho các bác STL. Như thế nào thì không tiện nói, hay không nên nói.

4- Đúng như anh conmale đã viết, webserver này đặt tai Nga (Russian). Vị trí địa lý của nó là ở gần giữa nước Nga, gần Mông cổ hơn cưc bắc Nga và ở phía Đông Bắc tỉnh Krasnoiac. Xin em bản đồ.

Thêm một bằng chứng về sự liên hệ của STL với một số thành phần Nga. Nhưng mối liên hệ này không có gì đáng nói so với một môi liên hệ khác với Nga, mà tôi đã nói ở trên.

Tuy nhiên dải IP 193.106.175.0-193.106.175.255 lai có thể do một công ty Pháp sở hữu. Có thể công ty Pháp này đầu tư vào miền trung nước Nga, một vùng còn chậm phát triển. Có thể TQ cũng tham đầu tư liên doanh với Pháp, xây dựng các kết cấu hạ tâng IT tai đây.

5- Domain second.dinest.net là subdomain của domain dinest.net. Nhưng không chỉ có subdomain này,
mà còn những subdomain khác. Chúng là:

- fpt.dinest.net
IP 67.19.72.202
- irc.dinest.net
IP 67.19.72.202
- mail.dinest.net
IP 67.19.72.202
- www.dinest.net
IP 67.19.72.202
- blog.dinest.net
Ip 98.124.253.253

Các subdomain này có thể là do các chiến hữu của STL quản lý, chính xác hơn là của các cấp lãnh đạo. Dễ dàng nhận thấy subdomain mail.dinest.net là quan trong nhất. Tại đây một mailserver được thiết lâp, dùng cho việc liên hệ trong khối.

6- Webserver second.dinest.net được cấu hình để các kết nối từ trình duyệt của các user-nạn nhân từ các máy zombie của họ đến webserver là các persistent connection (hay còn gọi keep-alive connection). Điều này giup cho các bot trong zombie dễ dàng, nhanh chóng liên hệ với webserver và nhận lệnh lấy cắp thông tin cá nhân, tấn công DDoS các muc tiêu trên mang. Điều này anh conmale cũng đã đề câp trong một post phía trên.

7- Trước webserver second.dinest.net STL còn đặt một server cài phần mềm "NGINX"(đọc là en-din-x), nhằm phòng và hạn chế tác hại của quá trình phản công DDoS vào webserver (second.dinest.net). Biện pháp này vừa qua Vietnamnet.net cũng đã áp dụng khi bị tán công DDoS dồn dâp trên mạng. (Chắc cũng là do STL tấn công thôi. Ở Việt nam, ngoài STL thì không ai có đủ tìền bạc, nhân lực, thời gian và trình độ kiến thức tạo lập được 1 mạng zombies-bot với hàng trăm ngàn máy, đặt trong nước ngoài nước, tấn công DDoS liên tục, năng nề vào Vietnamnet. Lý do Vietnamnet bị STL tấn công là do đây là tờ báo lề phải duy nhất dám chửi, phê phán khá mạnh mẽ hành động, ngang ngược bá quyền của TQ mà thôi. Các báo khác luôn tìm cách né tránh)
"NGINX" do một chuyên viên IT người Nga soạn thảo ra. Hiêu quả thưc tế của phần mềm-application này trong việc chống DDoS còn đang đươc bàn cãi. Chưa có công ty Mỹ nào dùng "NGINX" cả. Thưc tế "NGINX" cũng đã gây ra một vài trục trặc trên mang. Tôi cũng đã có một bài viết phân tích cụ thể hơn về "NGINX" tai topic " Sinh tử lênh.......", trong box "Những thảo luận khác"

Chúng ta đã nắm đươc các thông tin cần thiết về master webserver second.dinest.net và nhiều webserver khác của STL. Chúng vẫn có những điểm yếu. Chúng ta cần và hoàn toàn có thể phát hiện ra các master webserver của STL sớm, ngay từ khi chúng khởi đông các cuộc tấn công DDoS trên mạng, nhằm phá hủy kết cấu hạ tầng và hoạt đông thông tin mang của cộng đồng, đất nước. Bằng các cách thức từ đơn giản nhất, ai cũng có thể làm, đến các phương thức tinh vi nhất (nhiều hàm lượng trí tuệ), trong một tâp thể HVA đồng tâm hiệp lực vì công đồng, đất nước, chúng ta có thể sẽ bẻ gẫy hay hạn chế tối đa tác hai của các cuộc tấn công DDoS trên mang của STL. Không thể để STL tự tung tự tác, như ở chỗ không người, muốn hạ nhục ai thì hạ, muốn cho website nào ngừng thì phải ngừng.

Tôi sẽ gừi anh conmale một số biện pháp cần thiết, mang tính sáng tạo của người VN-"nghèo nhưng không ngu và hèn", để bàn bạc thưc hiện cùng với các bạn.(Không thể bàn công khai trên forum)

Như vậy là cho đến nay chúng ta đã phát hiện ra khoảng 10 domain STL sử dung cho 10 master website-webserver khác nhau.

Một số website-webserver đã tạm thời ngưng hoăc mất domain.

Vấn đề chúng ta chưa xác định thật rõ là website-webserver nào đang in-charge (đang làm nhiệm vụ DDoS), như đang DDoS vào HVA chẳng hạn, cái nào đã thôi dùng.?

Chúng ta cũng chưa phân tích và tổng hơp các thông tin về nguồn (website, webserver) mà STL hay người khác (bị STL lơi dung) dùng để phát tán virus, thí dụ http://nethoabinh.com/ mà lequi đã xác nhận.

Về virus-trojan chúng ta cũng còn chưa rõ là ngoài nhóm file MShelpcenter.*... tạo ra từ malicious Unikey mà lequi download về từ đường dẫn của http://nethoabinh.com/, có còn có các nhóm file loại khác, tên khác nhưng công dung tương tự không?. MShelpcenter.* files có là những file mới nhất của STL không.?

STL cũng nhúng virus-Trojan vào các file Vietkey (2000-2002-2007) đang được upload rất nhiêu trên mạng. Chúng đươc STL nhúng vào các virus-trojan loai gì, có giống như ở Unikey không?
Còn phải kể những file Adobe flash Player dễ dàng download trên mạng, cũng thường bị STL nhúng virus-trojan vào.

Rõ ràng đang còn rất nhiều vấn đề cần phải nghiên cứu, tìm hiểu và giải quyết.

conmale wrote:

PXMMRF wrote:

Ở Việt nam hiện nay, theo tôi, chỉ khoảng 5-8 % người cài win 7, còn lại hầu hết là Win XP. Trong số người cài Win 7, có lẽ tối đa là 30-40% người có thể nhiễm STL trojan thôi. Như thế khó mà tạo lập được mang STL bot với hàng trăm ngàn máy ở VN.

Hì hì, câu này anh Mai nói ngược rồi. Bởi vì hầu hết dùng Windows XP và chỉ có 5-8% dùng Windows 7 (trong số người dùng Windows 7 thỉ chỉ có 30-40% bị nhiễm) cho nên dễ tạo lập được mạng STL bot với hàng trăm ngàn máy ở VN.

Sau kết quả điều tra sơ khởi, em thấy cả hệ thống máy của một trường đại học đều ấn định người dùng có chủ quyền "Administrator" và hàng chục doanh nghiệp lớn/vừa cũng không tránh khỏi lỗ hổng này. Trong con số 20 người dùng máy bình mà em hỏi thăm thì 100% là chạy dưới chủ quyền "Administrator". Bởi vậy, dễ tạo lập được mạng STL bot với hàng trăm ngàn máy ở VN chớ không phải "khó" .

Hì hì, câu này mình nói với ý khác. Vì axasin thông báo là cài cái Malicious Unikey mà bạn ấy download về chỉ tạo các file virus MSHelpCenter.* trong Windows 7 thôi , còn trong Win XP thì không được (nghĩa là Win XP thì không bị nhiễm virus khi cài malicious Unikey nói trên). Vì số người ở VN dùng Win 7 còn ít, nên tôi suy diễn tiếp theo ý axasin như vậy (cũng có ý rỡn vui với rang0 chút chút)

Đây là suy diễn theo nhận định của axasin. Chứ tôi đương nhiên là không nghĩ như vậy. Tôi nghĩ máy trên mạng VN hầu hết là cài Win XP và tỷ lệ máy cài Win XP bị nhiễm STL virus-trojan là rất cao.
Cần nói thêm là hiện đang có nhiều loại (version) malicious Unikey và Vietkey trên mạng. Malicious Unikey mà axasin cài khác với của lequi đã cài. Còn có nhiều malicious Unikey khác trên mang nũa. Kinh!

[Hì hì các bác đừng gọi là "fake Unikey", vì nó vẫn dùng được để đánh chữ Việt mà. Nên gọi là malicious Unikey (Unikey độc). Giả thì không dùng đươc. Nhưng Unikey nhiễm độc (malicious) thì vẫn dùng được, nhưng lai nguy hiểm cho ta hơn ngàn lần. Hì hì. Nhưng đây chỉ là khuyến cáo vui thôi!]

Đúng là hầu hết máy tính cá nhân ở Việt nam (tai tư gia, cơ quan) đều cài đặt cho user dưới quyến admin.. Win XP rõ ràng là cũng hỗ trợ việc này thưc hiện dễ dàng trong quá trình cài đặt nó. Việc phân quyên cho user trên Win XP còn đơn giản và thiếu bảo mật hơn Win 2000.
Nhưng nghĩ lai thì lại thấy khó: máy riêng của nó, hay phân cho mình nó dùng tại cơ quan, thì hà cớ gì bắt nó chỉ đươc dùng account restricted hay account limited. Khó thật.

Chuyên vui (có thưc): Vừa qua công ty tôi các máy tính bị nhiễm virus nặng nề, lây lan lung tung, mất dữ liêu, do anh em có quyền admin. tự động cài nhiều chương trình game, nghe nhạc nhiễm virus. Tôi nổi điên lên, yêu cầu tất cả công ty mang máy lên văn phòng để phân quyên lại: không cho dùng quyên admin, chỉ cho dùng quyền restricted hay limited. Gần trăm máy mang lên, xếp hàng, trông hết hồn. Lệnh đã ra phải làm, không kỳ. Tôi và 2 lão Kỹ sư IT phải mất gần 3 ngày để phân quyền, dọn dep rác rưởi, update antivirus và cài lai các máy in, máy scan, nâng cấp RAM.... Mệt quá. Nhưng rõ ràng sau đó tình hình đỡ hơn nhiều. Gần đây lai phải tổ chức 1 lớp hoc sử dung máy tính trong nôi bộ cơ quan.....

To "TQN". Ucraina có một mối quan hệ rất sâu sắc với TQ, đăc biệt trong thời kỳ tổng thống cũ, khi mà môi quan hệ giữa Nga và Ukrain xấu, rạn nứt. TQ trơ giúp Ucrain rất nhiều về Ktế và đầu tư một số vốn khá lơn vào nước này

rang0 wrote:

asaxin wrote:

Chuẩn bị đi làm rồi, nhưng thấy còn nhiều thắc mắc của mọi người nên đã test thử.

Bên dưới là link download unikey, đây chính là file đã sinh ra 2 các file mà chú nói.
http://www.mediafire.com/?fee5d3428euao0k

Đây là bản unikey cháu download lâu lắm rồi không nhớ là download link. Sau khi cháu đã xóa đi các file virus MSHelpCenter.*, tắt Avira, Firewall, thử chạy lại thằng Unikey này để test thì nó là sinh các file virus MSHelpCenter. Như vậy đây chính là thằng đã tạo ra. Ah, mà hình như thằng này chỉ sinh ra trong Windows 7, máy khác dùng windows xp sp3 không sinh ra.

Vậy là đã giải đáp hoàn toàn thắc mắc của anh PXMMRF về việc MSHelpCenter.exe và MSHelpCenter.idx được sinh ra từ đâu rồi

Ờ cảm ơn rang0 và đăc biệt là asaxin (tên em giống tên một cầu thủ Nga chơi cho Arsenal quá. Hì hì)
Nhưng mà chưa hết đâu rang0 ạ. Chưa hết ờ câu này của axasin:

Ah, mà hình như thằng này chỉ sinh ra trong Windows 7, máy khác dùng windows xp sp3 không sinh ra

Ở Việt nam hiện nay, theo tôi, chỉ khoảng 5-8 % người cài win 7, còn lại hầu hết là Win XP. Trong số người cài Win 7, có lẽ tối đa là 30-40% người có thể nhiễm STL trojan thôi. Như thế khó mà tạo lập được mang STL bot với hàng trăm ngàn máy ở VN.

Note.
-Cái STL Master website-server mà tôi check từ thông tin của axasin chính là cái có quy mô khá hoành tráng, như tôi nói ở trên.
- Tôi bắt đầu "hy sinh' 2 máy cài Win7 và Win XP cho nhiễm STL virus vào xem nó thế nào. Hơi mất công và thời gian đây.

TQN wrote:

PS: À mà còn việc này nữa, MSHelpCenter.exe chính là virus. Nhưng nếu nó chỉ có một mình, thì có thể xem như nó clean, sạch sẽ. Nhưng nếu để nó nằm trong ổ của nó gồm MSHelpCenter.idx, thumbcache.db, _desktop.ini, thì tụi nó kết hợp lại thành ổ virus.

Vậy thì có phải là virus -trojạn "BackDoor.Generic 12.APEB" nằm trong file MSHelpCenter.idx sẽ inject các malicious code vào trong file MSHelpCenter.exe, như tôi đã từng dự đoán à? Phải như thế không TQN?

Mải kiểm tra các master websites của STL (mong là đúng của STL) mất thời gian nhiều, nay kiểm lai xem có file nào là MSHelpCenter.exe trong các máy mình không? Kết quả là kiểm 3 máy cài WinXPSP3, 1may Windows7, 2 máy Win2K3 SP2 do chính mình quản lý, nhưng không thấy máy nào có cái file MSHelpCenter.exe cả. Lạ nhỉ? Các bạn thử kiểm máy mình có nó không?

Vậy thì cái file MSHelpCenter.exe này trên máy axasin lấy từ đâu ra?
Và nếu "khó" có nó như vậy, thì làm sao STL có thể dễ dàng tạo lập một mang lớn zombies tại VN với hàng trăm ngàn chiếc được? Càng lạ quá!

Ấy lequi đừng quét virus vôi. Cứ để thế mới điều nghiên được chứ.
Xong việc thì quét theo hướng dẫn trợ giúp của bolzano_1989

lequi wrote:

acoustics89 wrote:

@lequi: chắc anh em lại cùng với bạn phối hợp lấy mẫu như hôm qua. xong bạn up mẫu lên đây nhé, mọi người phân tích cũng nhanh thôi

Mình rất sẵn lòng.

Mớ packet và các nghi ngờ của mình bắt đầu xuất hiện từ sau khi chạy setup unikey này http://nethoabinh.com/showthread.php?t=315). Mình vẫn chưa lần mò ra được gì , có thể máy mình vẫn đang có trojian, nhưng có thể đây là 1 phiên bản trước đây khá lâu (tháng 11/2009), các user-agent và url đều khác, mặc dù cấu trúc là giống nhau (Gozilla và ?cpn).

Không biết mình phải làm gì tiếp đây?

Cám ơn nhiệt tình đáng quí của em. Mình làm việc này không chỉ cho HVA, mà còn có lơi cho công đồng, đất nước. Tôi sẽ phân tích các lý do của những hành động mà STL (tay sai cho Tầu) đã làm vừa qua. Việc phát hiện thông qua kỹ thuật mạng để biết STL liên quan chặt chẽ với chính quyền TQ đã khó rồi, nhưng việc sau đó lý giải một cách hơp lý lý do của các hành động của STL thời gian qua lai khó hơn rất nhiều.

Quay trở lai vấn đề của topic. Với các thông tin của các bạn trong đó có lequi tôi đã tìm thấy ít nhất 5 master website-server của STL và đã check kỹ vào chúng để có các thông tin. Chúng đặt ở nhiều nơi trên TG. Điều ngạc nhiên là trong số 5 website-webserver nói trên có một cái khá hoành tráng về quy mô và cấu hình. Không hiểu có phải webserver này đã bị STL thâm nhập chiếm quyền admin.hay không?
Chỉ mong các thông tin các bạn đưa ra là chính xác. Virus-Trojan liên hệ với các master-website này đúng là của STL, chứ không phải các hacker khác.

Một điều mà tôi thấy chúng ta làm chưa thật tốt là chưa xác định được chính xác các process, service.. nào thưc sự kết nối đến các master website nói trên.
Thưc ra để xác định chính xác điều này không dễ như tôi đã từng nhận định một cách chủ quan ở 1 bài viết trong topic này. Với tôi thì như vậy. Với các bạn khác có thể không như vậy.

Các soft mà các bạn dùng như Wireshark và Process Monitoring... thưc ra không đáp ứng yêu cầu của ta, cũng không hẳn là đồ chuyên nghiệp của dân chơi mạng. Trên wireshark ta chỉ thấy các IP kết nôi (trừ khi phân tích kỹ bên trong packet thì có thể thêm vài thông tin) nhưng không thể biết các process kích hoạt kết nối. Còn trong Process Monitoring thì thấy tên các process (nhiều là khác) nhưng không hề biết các connection...vân vân.
Theo tôi trong trường hợp này các bạn nên sử dung các Advanced firewall (loại mới-tiên tiến). Với firewall loai này, cùng lúc, các ban biết tên, vị trí trên directory các process kích hoạt các kết nối, đia chỉ IP và computer name của mục tiêu và kể cả RX -TX....
Firewall cũng cho phép ta ngăn sư thâm nhập sâu vào máy của virus 1 cách rất hiệu quả vì một malicious process nào của virus khởi chạy là firewall chặn lại chờ sự cho phép của ta.

Vì vậy nếu ban lequi cần một firewall như vậy, thì tôi sẽ gửi đến bạn qua email. Hoăc bạn tự tìm cái tốt hơn. Có công cụ này việc ban giúp, làm sẽ dễ hơn

acoustics89 wrote:

là người viết các kết quả phân tích; Em tự tin vào cái mà em lần ra, em tự tin và khẳng định nó là virus ạ. Cho dù các phần mềm khác có đưa kết quả clean đi nữa, em vẫn chỉ tin vào Olly và IDA.

trong MSHelpCenter.exe

File Offset 000136B0h: G4GD7ND0CDL4DB7CB0CD3ED6KD9YC2FDYN7BD0OCP4JD7QD0ED3FD6HDO0TC3OC6CD

địa chỉ của hàm decode :401B30h

Hàm download : 4015B0h

Ngoài ra còn hàm này để ghi key trong registry:4017F0h
Cái xâu bị cắt vụn ra, tránh emulator, dò string của các av, liệu có coder nào rảnh đến mức cắt như thế không ạ

Cám ơn các thông tin của em và anh rất tin vào những dòng code em post lên, nó đã rõ ràng như em nhận định.
Nhưng chỉ hỏi thêm điều này, nêu thấy không tiện thì không trả lời cũng được: Em có chắc chắn máy em dùng dể desassembling các file ấy có "clean" 100% hay không?

Note. Anh đã cẩn thận check file MSHelpCenter.exe không chỉ trên virustotal mà còn trên ít nhất 8 filechecking website khác nữa, của các hảng antivirus nổi tiếng nhất. Hì hì

rang0 wrote:

Em cũng không biết có file MSHelpCenter nào của MS mà nó có hành vi như trên không nữa ạ ?

Tôi ghi nhân ý kiến của bạn và tôi sẽ nghiên cứu kỹ để làm rõ 1 vài vấn đề đến nay
tôi vẫn còn thắc mắc. Thanks (Tôi cũng sẽ kiểm tra lai code của file này lần nữa, dù kinh nghiêm khả năng về mặt này thưc ra không bằng TQN)

Đó là:

1 -Service, process nào download các file MSHelpCenter.exe về máy hoăc process nào inject malicious code vào file này?? ( Ngay từ lúc đầu file MSHelpCenter.exe có bị nhúng virus hay không?)

2- Virus-Trojạn nằm trong file MSHelpCenter.idx có quan hệ tác động gì đến file MSHelpCenter.exe, khi nào, tiến trình xảy ra theo trình tự thế nào khi máy bị nhiễm virus?

3- File đầu tiên gây nhiễm cho máy user mà user download về trên mạng (thí dụ Vietkey, Unikey....) là file nào trong trường hợp này.? Dĩ nhiên không phải là chính các file MSHelpCenter.exe hay MSHelpCenter.idx, vì dung lượng của chúng quá lơn, mà cũng chẳng ai lai cần download chúng về làm gì cả

Vậy bạn có ý kiến thế nào về những vấn đề tôi đang thắc mắc, để tôi có thể giải toả và có kết luận cuối cùng cho mình??

ptv_vbhp wrote:

Em dùng Bkav pro . Hôm trước down mấy mẫu về thấy nó nhai ngon lành . Hic hic ... Cả file fake kia lẫn cái file *.dix

BKAV pro đã phát hiện ra virus-trojạn trong file MSHelpCenter.idx rồi à? .Rất hoan nghênh.
Nhưng Virus DAT file update vào ngày nảo? Tháng 6, tháng 7/2011?

rang0 wrote:

PXMMRF wrote:

Tuy nhiên tôi chỉ xác nhân là cái file MSHelpCenter.exe (nằm trong một folder có tên là "MSHelpCenter"- being zipped) mà bạn asaxin upload lên Mediafire vừa qua là không có virus thôi (nhưng file MSHelpCenter.idx, cũng trong folder nói trên, là có virus rõ ràng).
Tôi không biết và không đề cập đến tất cả các file MSHelpCenter.exe khác

Gửi anh PXMMRF,

Em không biết anh có đọc mấy bài trước của anh TQN và bạn acoustics89 phân tích hay không mà anh lại khẳng định như thế ạ ? File MSHelpCenter (MD5: 915E9432CA9414A771071EE0CC115930) được zip cùng file MSHelpCenter.idx mà bạn asaxin đã upload rõ ràng là malware. Chính nó là con download AcrobatUpdater.exe về đấy ạ.

Theo như hình kết quả từ virustotal, chưa có chương trình AV nào detect em nó không có nghĩa là em nó clean, và mấy cái thông tin internal name, orginal name, ... hoàn toàn có thể fake được mà anh.

Rang0 !

Tôi đọc kỹ, rất kỹ là khác. Nhưng chính TQN cũng đang thấy cần phải kiểm tra lai mà. Xem những post cuối cùng của TQN (xem kỹ nhé- Thanks)

bolzano_1989 wrote:

Gửi chú PXMMRF,
Những kết quả sigcheck sau có được là do đám STL làm giả để đánh lừa advanced user:

sigcheck:
publisher....: Microsoft Corporation
copyright....: (c) Microsoft Corporation. All rights reserved.
product......: Microsoft_ Windows_ Operating System
description..: Microsoft Help Center
original name: MsHelpCenter.exe
internal name: MsHelpCenter.exe
file version.: 6.1.7600.16385

Quan trọng nhất khi sigcheck MsHelpCenter.exe là các dòng sau:
Verified: Unsigned
File date: 9:34 AM 12/31/2010
Vào thời điểm này, Microsoft USA không thể có người làm việc liên quan đến file MsHelpCenter.exe này .
Đồng thời file này không được digitally signed bởi Microsoft Windows.

Trước hết cám ơn bolzano_1989 vì đã quote lai các file hình ảnh trên bài tôi viết. Tôi thường bổ sung hình ảnh để bài viết khỏi nhàm chán, các bạn đỡ mất công phải click nhiều lần và xem cho sướng mắt. Cũng còn có đôi lý do khác, hay hay đấy.
Sau nữa cảm ơn về những đóng góp của bạn, thể hiện việc bạn luôn không ngai khó, tìm hiểu đến cùng những vấn đề mình chưa biết hay chưa đồng ý. Đó là đức tinh quý và cần của người làm bảo mật. Trước đây Triệu trần Đức cũng có đức tính này.

Quay trở lại vấn đề file MSHelpCenter.exe, tôi có thêm ý kiến sau:

1- Đây là file nguyên thuỷ (originally made) của MS. Hầu hết các OS của MS đều sử dụng file này.

2- Nhưng cũng vì vậy có rất nhiều phiên bản (version) của file nói trên. MS lọc -cắt bớt- bổ sung file nguyên thuỷ cho phù hợp với từng OS. Vì vậy nói về file MSHelpCenter.exe là phải nói chính xác là nó ở OS nào, đã được update chưa?
Đã có một công ty chuyên làm về File Database thống kê hiên nay có tới gần 60 loại file MSHelpCenter.exe với nôi dung có các điểm khác nhau, dung lượng khác nhau (tất nhiên MD5 cũng khác nhau)
Tham khảo tại:
http://systemexplorer.net/db/mshelpcenter.exe.html

3- Có lẽ chính vì vậy mà MS khó hay không thể áp dụng việc Digitally signed cho tất cả các file MSHelpCenter.exe trong thưc tế. Tất nhiên các file khác chỉ có 1 version hay một vài version thì có thể.

4- Như tôi đã nói ở post trên, các hacker hay đặt tên các service, process, file của virus trùng đúng với tên service, process, file nguyên thuỷ của các HDH, nhằm làm cho user không nghi ngờ hay nếu nghi ngờ thì lại bối rối ....
Do vậy không loại trừ khả năng có một hacker nào đó trên TG đã đặt tên file của virus là MSHelpCenter.exe, hay nhúng virus vào trong file này (Thưc tế điều này đã có- Xin xem hình cho đỡ mỏi tay click)

5- Trong trường hợp nghi ngờ một file loại này có virus mà không thể kiểm bằng digitally signed thì đành phải kiểm bằng cách khác, như tôi đã nói: kiểm vị trí đúng (right location) của file trong directory. Hacker không có thể đặt các file trùng tên trong một folder, nhưng trong 2 folder khác nhau thì lại được. Tuy nhiên ở các OS khác nhau thì vị trí đúng của file có thể khác nhau. Đó là điều khó.

Và cách đáng tin nhất nhất là check nó trên mạng để kiểm tra có nhiễm virus hay không, như tôi đã làm với file MSHelpCenter.exe và post hình lên.

Tuy nhiên tôi chỉ xác nhân là cái file MSHelpCenter.exe (nằm trong một folder có tên là "MSHelpCenter"- being zipped) mà bạn asaxin upload lên Mediafire vừa qua là không có virus thôi (nhưng file MSHelpCenter.idx, cũng trong folder nói trên, là có virus rõ ràng).
Tôi không biết và không đề cập đến tất cả các file MSHelpCenter.exe khác ngoài file nói trên