ლაბორატორიული სამუშაო - მეთოდური მითითებები Wireshark-სთვის:

Ursnif ინფექციების გამოკვლევა

Ursnif წარმოადგენს საბანკო მავნე პროგრამას, რომელსაც ზოგჯერ მოიხსენიებენ

როგორც Gozi-ს ან IFSB-ს. მავნე პროგრამების Ursnif ოჯახი აქტიურია წლების განმავლობაში,
თუმცა დღევანდელი ნიმუშები ქმნიან ტრაფიკის განსხვავებულ შაბლონებს.

ლაბორატორიულ სამუშაოში განხილულია Ursnif ინფექციის ტრაფიკის გამოჭერილი

პაკეტები (pcaps) Wireshark პროგრამის გამოყენებით. ტრაფიკის ამ ნიმუშების გააზრებას
შესაძლოა დიდი მნიშვნელობა ჰქონდეს უსაფრთხოების სპეციალისტებისთვის, Ursnif
ინფექციების გამოვლენისა და გამოკვლევის დროს.

ეს ლაბორატორიული სამუშაო მოიცავს შემდეგ თემებს:

• Ursnif-ის გავრცელების მეთოდები

• Ursnif ტრაფიკის კატეგორიები

• Ursnif ინფექციებიდან მიღებული pcap ფაილების ხუთი მაგალითი

შენიშვნა: ამ მეთოდურ მითითებებში ნაგულისხმევია, რომ თქვენ ფლობთ Wireshark

პროგრამის გამოყენების საბაზისო უნარებს. ინსტრუქციებში ასევე იგულისხმება, რომ თქვენ
უკვე მომართეთ Wireshark პროგრამის სვეტები, ისე როგორც ეს აღწერილი იყო წინა,
მეთოდური მითითებები Wireshark-სთვის - სვეტების ჩვენების შეცვლა, ლაბორატორიულ

Next-IT Academy შალვა სვანიშვილი გვერდი №1

სამუშაოში. თქვენ ასევე გამოცდილება უნდა გქონდეთ Wireshark პროგრამის ჩვენების
ფილტრებთან, როგორც ეს აღწერილია წინა, მეთოდური მითითებები Wireshark-სთვის -
ფილტრის ფორმულირებების ჩვენება ლაბორატორიულ სამუშაოში.

Ursnif-ის გავრცელების მეთოდები

Ursnif შესაძლოა გავრცელდეს ვებზე დაფუძნებული ინფიცირების ჯაჭვებისა და მავნე
სპამის (malspam) მეშვეობით. ზოგიერთ შემთხვევაში, Ursnif წარმოადგენს შემდგომ
ინფექციას, რომელიც გამოწვეულია მავნე პროგრამების სხვადასხვა ოჯახებით, მათ
შორისაა Hancitor, რომლის ანგარიშიც მოცემულია შემდეგ ბმულზე
https://isc.sans.edu/forums/diary/Hancitor+infection+with+Pony+Evil+Pony+Ursnif+and+Cobalt+St
rike/25532/.

ჩვენ ხშირად ვპულობთ Ursnif-ის მაგალითებს მავნე სპამის გავრცელების კამპანიებში,

რომლის მაგალითიც ნაჩვენებია პირველ სურათზე.

სურათი №1. ბლოკ-სქემა, რომელიც მიღებულია ერთ-ერთი ყველაზე ცნობილი Ursnif-ის გავრცელების
კამპანიიდან

Next-IT Academy შალვა სვანიშვილი გვერდი №2

Ursnif ტრაფიკის კატეგორიები
ეს ლაბორატორიული სამუშაო მოიცავს Ursnif ინფექციური ტრაფიკის ორ კატეგორიას:

• Ursnif, HTTPS ინფიცირების შემდგომი ტრაფიკის გარეშე

• Ursnif, HTTPS ინფიცირების შემდგომი ტრაფიკით

რომელიმე ამ კატეგორიიდან მიღებული მავნე პროგრამის ნიმუშები ქმნიან

არტეფაქტების იმავე ტიპს, ინფიცირებულ ვინდოუს ჰოსტზე. მაგალითად, ვინდოუსის
რეესტრის განახლებით, Ursnif-ის ორივე ტიპი სამუდამოდ რჩება ვინდოუს ჰოსტზე,
როგორც ნაჩვენებია მეორე სურათზე მოცემულ მაგალითზე.

სურათი №2. ვინდოუსის რეესტრის განახლებების მაგალითი, რომელიც გამოწვეულია Ursnif-ის ნიმუშებით,
HTTPS ინფექციის შემდგომი ტრაფიკით ან მის გარეშე.

პირველი მაგალითი: Ursnif-ი HTTPS-ის გარეშე

ამ ლაბორატორიული სამუშაოსთვის საჭირო პირველი pcap ფაილი, Ursnif-traffic-
example-1.pcap, ხელმისაწვდომია etesting.gtu.ge საიტზე, მიმდინარე კვირის სასწავლო
მასალებში. ტრაფიკის მიღმა არსებული მოვლენათა ჯაჭვი გამოქვეყნებულ იქნა ტვიტერზე
(https://twitter.com/malware_traffic/status/1203071348941246464). პირველ მაგალითში
მოცილებულია ყველა ის ტრაფიკი, რომელიც არ არის პირდაპირ დაკავშირებული Ursnif
ინფექციასთან.

გახსენით pcap ფაილი Wireshark პროგრამაში და ტრაფიკი გაფილტრეთ

http.request ჩანაწერით, როგორც ნაჩვენებია მესამე სურათზე.

Next-IT Academy შალვა სვანიშვილი გვერდი №3

 სურათი №3. პირველი მაგალითის pcap ფაილი, რომელიც გაფილტრულია Wireshark-ში

მოცემულ მაგალითში, Ursnif-ით ინფიცირებული ჰოსტი ქმნის ინფიცირების შემდგომ

ტრაფიკს 8.208.24[.]139 მისამართზე, სხვადასხვა დომენური სახელების გამოყენებით,
რომლებიც ბოლოვდებიან .at გაფართოებით. Ursnif-ის ეს კატეგორია იწვევს შემდეგ
ტრაფიკს:

• HTTP GET მოთხოვნები, რომელიც გამოწვეულია Ursnif-ის საწყისი ორობითი

ფაილით;

• HTTP GET მოთხოვნა .dat-ზე დაბოლოებული URL-ით, დამატებითი მონაცემების

მისაღებად;

• HTTP GET და POST მოთხოვნები, Ursnif-ის ვინდოუსის რეესტრში გამაგრების

შემდგომ;

ჩვენ პირველ მაგალითში, ქვემოთ მოცემული HTTP მონაცემები გამოიყენება ტრაფიკის

დროს:

• დომენი საწყისი GET მოთხოვნებისთვის: w8.wensa[.]at

• მოთხოვნა შემდგომი მონაცემების მისაღებად:

hxxp://api2.casys[.]at/jvassets/xI/t64.dat

• დომენი GET და POST მოთხოვნებისთვის, Ursnif-ის გამაგრების

შემდგომ: h1.wensa[.]at

Next-IT Academy შალვა სვანიშვილი გვერდი №4

 თვალყური ადევნეთ TCP ნაკადს, ყველაზე პირველი HTTP GET მოთხოვნისთვის,
რომელიც დაფიქსირდა 20:13:09 საათზე. TCP ნაკადის ფანჯარა უჩვენებს სრულ URL-ს.
მიაქციეთ ყურადღება იმას, რომ GET მოთხოვნა იწყება /api1/-ით, რომელსაც მოყვება ასო-
ციფრული (alpha-numeric) სიმბოლოების გრძელი სტრიქონი, უკან გადახრილი
სიმბოლოებითა (backslash - \ ) და ქვედა ტირეებით (underscore _ ). მეოთხე სურათზე
გამოყოფილადაა ნაჩვენები GET მოთხოვნა.

სურათი №4. HTTP GET მოთხოვნის მაგალითი, რომელიც გამოწვეულია ჩვენი პირველი Ursnif მაგალითით

იგივე ნიმუშის პოვნა შეგვიძლია Ursnif აქტივობიდან, რომელიც გამოწვეულია, 2019

წლის 10 დეკებრის Hancitor ინფექციით. pcap ფაილი ხელმისაწვდომია შემდეგ ბმულზე:
https://www.malware-traffic-analysis.net/2019/12/10/index.html. სხვა მავნე აქტივებებთან
ერთად, 10 დეკემბრის ეს მაგალითი მოიცავს Ursnif-ის შემდეგ ინდიკატორებს:

• დომენი საწყისი GET მოთხოვნებისთვის: foo.fulldin[.]at

• მოთხოვნა შემდგომი მონაცემების მისაღებად:

hxxp://one.ahah100[.]at/jvassets/o1/s64.dat

• დომენი GET და POST მოთხოვნებისთვის, Ursnif-ის გამაგრების

შემდგომ: api.ahah100[.]at

Next-IT Academy შალვა სვანიშვილი გვერდი №5

 მიაქციეთ ყურადღება იმას, რომ Ursnif ტრაფიკიდან მიღებული შაბლონები, 10
დეკემბრის მაგალითში არის იმ შაბლონების მსგავსი, რომელიც ჩვენ ვიპოვეთ პირველ
მაგალითში. ამ შაბლონების დანახვა, როგორც წესი, შესაძლებელია იმ Ursnif ნიმუშებიდან,
რომლებიც არ იყენებენ HTTPS ტრაფიკს.

მეორე მაგალითი: Ursnif-ი HTTPS-ის გამოყენებით

ამ ლაბორატორიულ სამუშაოში გამოყენებული მეორე pcap ფაილი, Ursnif-traffic-
example-2.pcap, ხელმისაწვდომია etesting.gtu.ge საიტზე, მიმდინარე კვირის სასწავლო
მასალებში. პირველი pcap ფაილის მსგავსად, აქაც ჩამოჭრილ იქნა ისეთი ტრაფიკი,
რომელსაც არანაირი კავშირი არ აქვს Ursnif ინფექციასთან.

გახსენით pcap ფაილი Wireshark პროგრამაში და გაფილტრეთ http.request or

ssl.handshake.type == 1 ჩანაწერით, როგორც ნაჩვენებია მეხუთე სურათზე. თუ იყენებთ
Wireshark პროგრამის 3.0 ან უფრო ახალ ვერსიას, სწორი შედეგის მისაღებად გამოიყენეთ
http.request or tls.handshake.type == 1 ფილტრი.

სურათი №5. pcap ფაილი, ჩვენი მეორე მაგალითისთვის, რომელიც გაფილტრულია Wireshark პროგრამაში

ამ მაგალითს აქვს მოვლენათა შემდეგი მიმდევრობა:

• HTTP GET მოთხოვნა, რომელიც აბრუნებს საწყის ორობით Ursnif ფაილს

• HTTP GET მოთხოვნები, რომლებიც გამოწვეულია Ursnif საწყისი ორობითი ფაილით

• HTTPS ტრაფიკი, მას შემდეგ რაც Ursnif გამაგრდა ვინდოუსის რეესტრში

Next-IT Academy შალვა სვანიშვილი გვერდი №6

 მიჰყევით ghinatronx[.]com-ზე პირველი HTTP GET მოთხოვნის TCP ნაკადს. ეს TCP
ნაკადი გამოავლენს ვინდოუსის შესრულებად ან DLL ფაილს, როგორც ნაჩვენებია მეექვსე
სურათზე. ჩვენ შეგვიძლია Ursnif ორობითი ფაილის ექსპორტირება pcap-დან ისე, როგორც
აღწერილია მეთოდური მითითებები Wireshark-სთვის - ობიექტების ექსპორტირება PCAP
ფაილიდან ლაბორატორიული სამუშაოში.

სურათი №6. პირველი HTTP GET მოთხოვნა პასუხად აბრუნებს ორობით ფაილს Ursnif-სთვის

მეოთხე სურათზე გამოყოფილადაა ნაჩვენები GET მოთხოვნა.

მომდევნო ოთხი HTTP მოთხოვნა bjanicki[.]com მისამართზე გამოწვეულია Ursnif

ორობითი კოდით. თვალყური ადევნეთ TCP ნაკადს, პირველი HTTP GET მოთხოვნას
bjanicki[.]com მისამართზე, რომელიც დაფიქსირდა 18:46:21 საათზე. TCP ნაკადი უჩვენებს
სრულ URL-ს. ყურადღება მიაქციეთ იმას, რომ GET მოთხოვნა იწყება /images/-ით, რომელსაც
.avi დაბოლოებამდე მოყვება ასო-ციფრული (alpha-numeric) სიმბოლოების გრძელი
სტრიქონი, უკან გადახრილი სიმბოლოებითა (backslash - \ ) და ქვედა ტირეებით (underscore
_ ). ეს URL შაბლონი გარკვეულწილად ჰგავს ჩვენი პირველი pcap ფაილიდან მიღებულ Ursnif
ტრაფიკს. მეშვიდე სურათზე გამოყოფილადაა ნაჩვენები GET მოთხოვნა, მეორე pcap-დან.

Next-IT Academy შალვა სვანიშვილი გვერდი №7

 სურათი №7. HTTP GET მოთხოვნის მაგალითი, ჩვენი მეორე Ursnif ნიმუშიდან.

ჩვენი პირველი მაგალითისაგან განსხვავებით, მეორე pcap ფაილში Ursnif ქმნის HTTPS
ტრაფიკს, მას შემდეგ რაც ის გამაგრდება ინფიცირებულ ვინდოუს ჰოსტში. HTTPS
ტრაფიკის სწრაფი დათვალიერებისთვის გამოიყენეთ basic ვებ ფილტრი, რომელიც
აღწერილია მეთოდური მითითებები Wireshark-სთვის - ფილტრის ფორმულირებების
ჩვენება - ლაბორატორიული სამუშაოში. ყურადღება მიაქციეთ HTTPS ტრაფიკს
prodrigo29lbkf20[.]com მისამართისკენ, როგორც ნაჩვენებია მერვე სურათზე.

Next-IT Academy შალვა სვანიშვილი გვერდი №8

 სურათი №8. ვებ ტრაფიკის გაფილტვრა Wireshark პროგრამაში, Ursnif-ის მიერ შექმნილი HTTPS ტრაფიკის
ჩვენება გამოკვეთილად

Ursnif-ის ამ ვარიანტის მიერ შექმნილი HTTPS ტრაფიკი ავლენს განსხვავებულ

მახასიათებლებს სერტიფიკატებში, რომლებიც გამოიყენებიან დაშიფრული
კომუნიკაციების დასამყარებლად. უფრო ახლოდან ნახვისთვის, გაფილტრეთ
ssl.handshake.type == 11 ჩანაწერით (ან tls.handshake.type == 11 ჩანაწერით, Wireshark 3.0-ის ან
უფრო ახალი ვერსიის შემთხვევაში). გამოსულ შედეგში აირჩიეთ პირველი ფრეიმი და
გადადით ფრეიმის დეტალების ფანჯარაში. აქ ჩვენ შეგვიძლია სტრიქონების ჩამოშლა და
სერტიფიკატის გამცემის მონაცემებზე გადასვლა. მეცხრე სურათზე ნაჩვენებია ინსტრუქცია
თუ როგორ დავიწყოთ მოქმედებები.

Next-IT Academy შალვა სვანიშვილი გვერდი №9

 სურათი №9. სერტიფიკატის გამცემის მონაცემებამდე მისასვლელი გზის ძიება

როგორც მეცხრე სურათზეა ნაჩვენები, ჩვენ ჩამოვშალეთ Secure Sockets Layer (დაცულ
მაერთებელთა შრე) სტრიქონი, ფრეიმის დეტალების ფანჯარაში. Wireshark 3.0 ან უფრო
ახალ ვერსიაში ეს სტრიქონი ნაჩვენებია, როგორც Transport Layer Security (ტრანსპორტის
შრის უსაფრთხოება). შემდეგ ჩვენ ჩამოვშალეთTLSv1.2 Record Layer: Handshake Protocol:
Certificate სახელით მარკირებული სტრიქონი. ამის შემდგომ ჩამოვშალეთ Handshake
Protocol: Certificate სახელით მარკირებული სტრიქონი.
სტრიქონების ჩამოშლას ვაგრძელებთ მანამდე, სანამ არ ვიპოვით გზას სერტიფიკატის
გამცემის მონაცემებამდე მისასვლელად, როგორც ნაჩვენებია მეათე სურათზე.

Next-IT Academy შალვა სვანიშვილი გვერდი №10

 სურათი №10. სერტიფიკატის გამცემის მონაცემები Ursnif-ის მიერ გამოწვეული HTTPS ტრაფიკიდან

მეათე სურათზე Handshake Protocol: Certificate სტრიქონის ქვეშ, ჩვენ ვმუშაობთ

ქვემოთ მოცემულ შემდეგ პუნქტებთან:

• Certificates (615 bytes)

• Certificate: 30820260308201c9a003020102020900c692c94106d77dfc...

• signedCertificate

• Issuer: rdnSequence (6)

• rdnSequence: 6 items (id-at-commonName=*,id-at-organizationalUnitN...

rdnSequence
სტრიქონის ქვეშ მოცემული ცალკეული ელემენტები აჩვენებს
სერტიფიკატის გამცემის თვისებებს (properties). ისინი ავლენენ შემდეგ მახასიათებლებს:

• countryName=XX

• stateOrProvinceName=1

• localityName=1

• organizationName=1

• organizationalUnitName=1

• commonName=*

Next-IT Academy შალვა სვანიშვილი გვერდი №11

 გამცემის ეს მონაცემები არ არის სწორი და ეს შაბლონები, როგორც წესი, გვხვდება
Ursnif ინფექციებში. მაგრამ, როგორც გამოიყურება ლეგიტიმური სერტიფიკატის
მონაცემები? მეთერთმეტე სურათზე ნაჩვენებია სწორი მონაცემები სერტიფიკატიდან,
რომელიც გამოშვებულია DigiCert-ის მიერ.

სურათი №11. სწორი სერტიფიკატის გამომშვების მონაცემები

ერთ-ერთი ბოლო საკითხი, რომელიც დაკავშირებულია Ursnif-თან არის IP

მისამართის შემოწმება Ursnif-ით ინფიცირებული ჰოსტის მიერ. ეს ხდება DNS-ის
მეშვეობით, opendns[.]com-ზე დამდგენის (resolver) გამოყენებით. IP მისამართის სხვა
იდენტიფიკატორების მსგავსად, ესეც არის ლეგიტიმური სერვისი. თუმცა, ეს სერვისები
ხშირად გამოიყენება მავნე პროგრამების მიერ.

ამ IP მისამართის შემოწმების სანახავად, გაფილტრეთ ტრაფიკი dns.qry.name contains

opendns.com ჩანაწერით და დაათვალიერეთ შედეგები, როგორც ნაჩვენებია მეთორმეტე
სურათზე.

Next-IT Academy შალვა სვანიშვილი გვერდი №12

 სურათი №12. IP მისამართის შემოწმება Ursnif-ით ინფიცირებული ვინდოუს ჰოსტის მიერ

როგორც მეთორმეტე სურათზეა ნაჩვენები, ვინდოუს ჰოსტმა შექმნა DNS მოთხოვნა

resolver1.opendns[.]com-სთვის, რომელსაც მოჰყვა DNS მოთხოვნა 208.67.222[.]222
მისამართზე myip.opendns[.]com-სთვის. myip.opendns[.]com-ზე გაშვებულმა DNS მოთხოვნამ
პასუხად დააბრუნა ინფიცირებული ვინდოუს ჰოსტის გარე IP მისამართი.

მესამე მაგალითი: Ursnif ინფიცირება მომდევნო მავნე პროგრამით

ამ მაგალითში გამოყენებულია მესამე pcap ფაილი, Ursnif-traffic-example-3.pcap,
რომელიც ხელმისაწვდომია etesting.gtu.ge საიტზე, მიმდინარე კვირის სასწავლო მასალებში.
ამ pcap ფაილში, ტრაფიკიდან ამოღებულია შეუსაბამო აქტივობები, თუმცა ის
დაფუძნებულია ჩვენ ბოლო მაგალითზე. ჩვენი მესამე pcap ფაილის მოიცავს ტრაფიკს,
რომელიც გამოიყურება, როგორც სატყუარა (decoy) ტრაფიკი, ის ასევე მოიცავს HTTP GET
მოთხოვნას მომდევნო მავნე პროგრამისთვის. მოვლენათა მიმდევრობა ასე გამოიყურება:

• HTTP GET მოთხოვნა, რომელიც აბრუნებს საწყის ორობით Ursnif ფაილს

• HTTP GET მოთხოვნები, რომლებიც გამოწვეულია Ursnif საწყისი ორობითი ფაილით,

მათ შორის სატყუარა (decoy) URL-ებით.

• HTTPS ტრაფიკი, მას შემდეგ რაც Ursnif გამაგრდა ვინდოუსის რეესტრში

• HTTP GET მოთხოვნა მომდევნო მავნე პროგრამისთვის

Next-IT Academy შალვა სვანიშვილი გვერდი №13
 ვებზე დაფუძნებული ტრაფიკის სწრაფი დათვალიერებისთვის გამოიყენეთ basic ვებ
ფილტრი, რომელიც აღწერილია მეთოდური მითითებები Wireshark-სთვის - ფილტრის
ფორმულირებების ჩვენება - ლაბორატორიული სამუშაოში, იხილეთ მეცამეტე სურათი.

სურათი №13. მესამე pcap ფაილის გაფილტვრა ვებ ტრაფიკისთვის Wireshark პროგრამაში

მეცამეტე სურათზე, sinicaleer[.]com-თან გაგზავნილმა თავდაპირველმა HTTP

მოთხოვნამ, პასუხად დააბრუნა ვინდოუსის შესრულებადი ფაილი Ursnif-სთვის. მეცამეტე
სურათზე ნაჩვენები დანარჩენი ტრაფიკი გამოწვეულია Ursnif შესრულებადი ფაილის მიერ,
სანამ ის გამაგრდებოდა სისტემაში.

google[.]com-ზე განხორციელებული სამი HTTP მოთხოვნა მიყვება იგივე URL

ნიმუშებს, როგორსაც Ursnif ტრაფიკი რეალურ მავნე ghdy656262oe[.]com დომენთან.
google[.]com-სკენ გაშვებული ეს HTTP GET მოთხოვნები ჰგვანან სატყუარა (decoy)
ტრაფიკებს, რადგან ისინი არ ეხმარებიან ინფექციას. gmail[.]com-ზე და www.google[.]com-
ზე გაშვებული HTTPS ტრაფიკი TCP პორტ 443-ზე ასევე არ ემსახურება ინფექციის
პირდაპირ მიზანს და ეს აქტივობა შესაძლოა კლასიფიცირებულ იქნას, როგორც მატყუარა
ტრაფიკი. მეთოთხმეტე სურათზე ნაჩვენებია google[.]com-ზე გაშვებული სატყუარა HTTP
GET მოთხოვნების მაგალითი.

Next-IT Academy შალვა სვანიშვილი გვერდი №14

 სურათი №14. Ursnif-ით ინფიცირებული ჰოსტის მიერ გაშვებული სატყუარა HTTP GET მოთხოვნა Google
დომენთან

ყურადღება მიაქციეთ HTTP ტრაფიკს ghdy656262oe[.]com დომენთან. პირველი ორი

GET მოთხოვნა ghdy656262oe[.]com დომენზე პასუხად აბრუნებს 404 Not Found შეცდომას,
როგორც ნაჩვენებია მეთხუთმეტე სურათზე. მესამე HTTP GET მოთხოვნა აბრუნებს 200
OK პასუხს და გრძელდება ინფიცირების პროცესი, როგორც ნაჩვენებია მეთექვსმეტე
სურათზე.

Next-IT Academy შალვა სვანიშვილი გვერდი №15

სურათი №15. პირველი ორი HTTP GET მოთხოვნა მავნე Ursnif დომენთან, პასუხად აბრუნებს 404 Not Found
შეცდომას

სურათი №16. ზოგიერთი ცრუ საწყისები, სანამ გაგრძელდება Ursnif ინფექცია

Next-IT Academy შალვა სვანიშვილი გვერდი №16

 ვინაიდან პირველი HTTP GET მოთხოვნა ghdy656262oe[.]com დომენთან არ იყო 200 OK,
ინფიცირებულმა ვინდოუს ჰოსტმა, ინფიცირების გასაგრძელებლად, გადაინაცვლა სხვა
მავნე დომენებში. ეს ორი დომენია: tnzf3380au[.]top და xijamaalj[.]com. თუმცა, ამ დომენებზე
განხორციელებულმა DNS მოთხოვნებმა პასუხად დააბრუნა “No such name” შეტყობინება,
ამიტომ ინფიცირებული ვინდოუს ჰოსტი დაბრუნდა უკან, ghdy656262oe[.]com
მცდელობასთან.

მოვლენათა ამ მიმდევრობის უკეთ დასანახად გამოიყენეთ ქვემოთ მოცემული

Wireshark ფილტრი:

((http.request or http.response) and ip.addr eq 194.1.236.191) or dns.qry.name contains

tnzf3380au or dns.qry.name contains xijamaalj
შედეგები უნდა გამოჩნდეს მეჩვიდმეტე სურათზე ასახული სვეტის მსგავსად.

სურათი №17. Wireshark პროგრამაში გამოყენებული ფილტრი, რომელიც უჩვენებს ინფიცირებული ვინდოუს
ჰოსტის მცდელობებს Ursnif-თან დაკავშირებულ დომენებთან, სანამ ის მიაღწევს 200 OK შეტყობინებას HTTP
ტრაფიკში.

ინფიცირების დანარჩენი პროცესის სანახავად, გამოიყენეთ წინა ლაბორატორიულ

სამუშაოებში შექმნილი basic ფილტრი და გადაადგილდით შედეგების ბოლოში.
მეთვრამეტე სურათზე ნაჩვენებია ინფიცირების შემდგომი ტრაფიკი, მას შემდეგ, რაც Ursnif
გამაგრდა სისტემაში.

Next-IT Academy შალვა სვანიშვილი გვერდი №17

 სურათი №18. ინფიცირების შემდგომი ტრაფიკი, მას შემდეგ, რაც Ursnif გამაგრდა მსხვერპლის ვინდოუს
ჰოსტზე

მეთვრამეტე სურათზე, ghdy656262oe[.]com დომენთან განხორციელებული ხუთი

HTTP GET მოთხოვნის შემდგომ, ჩვენ აღმოვაჩინეთ ინფიცირებული ვინდოუს ჰოსტის მიერ
შექმნილი ტრაფიკი მას შემდეგ, რაც Ursnif გამაგრდა სისტემაში. ეს მოიცავს HTTPS
ტრაფიკს google[.]com და gmail[.]com დომენებთან.

vnt69tnjacynthe[.]com დომენის ტრაფიკს უნდა ჰქონდეს სერტიფიკატის გამცემის იგივე

ტიპის მონაცემები, რომლის მტკიცებულებაც ჩვენ ვნახეთ მეორე pcap ფაილში. მაგრამ ეს
ტრაფიკი შეიცავს HTTP GET მოთხოვნას carresqautomotive[.]com დომენთან, რომელიც
ბოლოვდება .rar გაფართოებით.

.rar-ით დაბოლოებული ეს URL მისამართი დააბრუნა მომდევნო მავნე პროგრამამ.

თუმცა, ეს მომდევნო მავნე პროგრამა კოდირებულია ანდა დაშიფრული - ქსელში
გაგზავნისას. ორობითი ფაილი დეკოდირებულია ინფიცირებულ ვინდოუს ჰოსტზე,
რომელიც არ ჩანს ინფექციის ტრაფიკში. მიყევით TCP ნაკადს, carresqautomotive[.]com
დომენთან გაშვებული HTTP GET მოთხოვნისთვის და თქვენ დაინახავთ იგივე მონაცემებს,
რაც ნაჩვენებია მეცხრამეტე სურათზე.

Next-IT Academy შალვა სვანიშვილი გვერდი №18

 სურათი №19. Ursnif-ით ინფიცირებულ ვინდოუს ჰოსტთან გაგზავნილი მომდევნო მავნე პროგრამა

ეს მონაცემები დაშიფრულია, რის გამოც ჩვენ არ შეგვიძლია მომდევნო მავნე

პროგრამის ასლის ამოღება pcap ფაილიდან. ამიტომ, ჩვენ უნდა დავეყრდნოთ სხვა
პოსტინფექციურ ტრაფიკს, იმის განსასაზღვრად, თუ რა ტიპის მავნე პროგრამა იქნა
გაგზავნილი Ursnif-ით ინფიცირებულ ჰოსტზე.

Ursnif ინფექციებიდან ჩვენ დავინახეთ სხვადასხვა ტიპის მომდევნო მავნე პროგრამა,

მათ შორის: Dridex, IcedID, Nymain, Pushdo და Trickbot.

ჩვენ შემდგომ მაგალითა Ursnif ინფიცირება Dridex-ის დახმარებით, რომელიც

წარმოდგენილია მომდევნო მავნე პროგრამის სახით.

მეოთხე მაგალითი: Ursnif ინფიცირება Dridex-ის დახმარებით

ამ მაგალითში გამოყენებული მეოთხე pcap ფაილი, Ursnif-traffic-example-4.pcap,
ხელმისაწვდომია etesting.gtu.ge საიტზე, მიმდინარე კვირის სასწავლო მასალებში. წინა სამი
მაგალითისაგან განსხვავებით, ამ pcap ფაილის ტრაფიკებიდან არაა ამოღებული შეუსაბამო
აქტივობები.

Next-IT Academy შალვა სვანიშვილი გვერდი №19

 ტრაფიკის უკეთ გასააზრებლად გამოიყენეთ basic ვებ ფილტრი. თქვენი შედეგები
უნდა იყოს მეოცე სურათზე მოცემულის მსგავსი.

სურათი №20. მეოთხე pcap ფაილიდან ამოღებული ტრაფიკი, რომელიც გაფილტრულია Wireshark-ით

ამ pcap-ს აქვს მოვლენათა იგივე მიმდევრობა, როგორც მოცემული იყოს წინა

მაგალითში, თუმცა მას ემატება პოსტინფექციური აქტივობა მომდევნო მავნე პროგრამიდან.

• HTTP GET მოთხოვნა, რომელიც აბრუნებს საწყის ორობით Ursnif ფაილს

• HTTP GET მოთხოვნები, რომლებიც გამოწვეულია Ursnif საწყისი ორობითი ფაილით,

მათ შორის სატყუარა (decoy) URL-ებით.

• HTTPS ტრაფიკი, მას შემდეგ რაც Ursnif გამაგრდა ვინდოუსის რეესტრში

• HTTP GET მოთხოვნა მომდევნო მავნე პროგრამისთვის

• პოსტინფექციური აქტივობა მომდევნო მავნე პროგრამიდან

მოცემულ მეოთხე მაგალითში, oklogallem[.]com დომენზე იგზავნება HTTP GET

მოთხოვნა, საწყისი Ursnif ორობითი ფაილისთვის. Ursnif აგზავნის HTTP GET
მოთხოვნებს kh2714ldb[.]com დომენთან იქამდე, სანამ ინფექცია გახდება მუდმივი და
გამაგრდება სისტემაში.

ოცდამეერთე სურათზე ნაჩვენებია აქტივობა Ursnif-ის სისტემაში გამაგრების შემდგომ,

როცა Ursnif აგზავნის HTTPS ტრაფიკს s9971kbjjessie[.]com დომენზე. შემდგომ ჩვენ ვხედავთ
HTTP GET მოთხოვნას startuptshirt[.]my დომენთან, მომდევნო მავნე პროგრამისთვის.
Next-IT Academy შალვა სვანიშვილი გვერდი №20
ბოლოს ჩვენ ვპოულობთ პოსტინფექციურ ტრაფიკს, რომელიც გამოწვეულია მომდევნო
მავნე პროგრამის მიერ.

სურათი №21. აქტივობა ინფექციიდან მას შემდეგ, რაც Ursnif გამაგრდა სისტემაში

მეოთხე მაგალითი მიყვება ინფიცირების იგივე ნიმუშებს, როგორც ჩვენი მესამე pcap
ფაილი, თუმცა ახლა ასევე გვაქვს HTTPS/SSL/TLS ტრაფიკი
94.140.114[.]6 და 5.61.34[.]51 მისამართებზე, დომენურ სახელთან რაიმე კავშირის გარეშე.
მოცემული წარმოადგენს Dridex პოსტინფექციურ ტრაფიკს.

Dridex-ის სერტიფიკატის გამცემის მონაცემები განსხვავდება Ursnif-ის სერტიფიკატის

გამცემის მონაცემებისაგან. მეოთხე pcap ფაილში, Dridex-ის სერტიფიკატის მონაცემების
დასათვალიერებლად გამოიყენეთ ქვემოთ მოცემული ფილტრი:

(ip.addr eq 94.140.114.6 or ip.addr eq 5.61.34.51) and ssl.handshake.type eq 11

შენიშვნა: თუ დაინსტალირებული გაქვთ Wireshark პროგრამის 3.0 ან უფრო ახალი
ვერსია, ssl.handshake.type -ის ნაცვლად გამოიყენეთ tls.handshake.type ფილტრი.

გამოტანილ შედეგში აირჩიეთ პირველი ფრეიმი, გადადით ფრეიმის დეტალების

ფანჯარაში და ჩამოშალეთ სერტიფიკატთან დაკავშირებული სტრიქონები, როგორც
ნაჩვენებია ჩვენი მეორე მაგალითის მე-9 და მე-10 სურათზე. მეოთხე pcap ფაილიდან
მიღებული, სერტიფიკატის გამცემის მონაცემების გამოკვლევისას, შედეგები უნდა
გამოიყურებოდეს ოცდამეორე და ოცდამესამე სურათებზე მოცემულის მსგავსად.

Next-IT Academy შალვა სვანიშვილი გვერდი №21

 სურათი №22. სერტიფიკატის გამცემის მონაცემებთან მუშაობა Dridex ტრაფიკში

სურათი №23. სერტიფიკატის გამცემის მონაცემებთან მიღწევა, Dridex-ის ერთ-ერთი IP მისამართიდან

Next-IT Academy შალვა სვანიშვილი გვერდი №22

 rdnSequence სტრიქონის ქვეშ, ჩვენ ვიპოვეთ სერტიფიკატის გამცემის მახასიათებლები
(properties). სერტიფიკატის გამცემის მახასიათებლები, HTTPS/SSL/TLS ტრაფიკისთვის
(94.140.114[.]6 მისამართზე), გამოიყურება შემდეგნაირად:

• countryName=NP

• localityName=Kathmandu

• organizationName=Buvecoww Fftaites O.V.E.E.

• organizationalUnitName=Olfo Dusar Latha

• commonName=ndltman-dsamutb.spiegel

სერტიფიკატის გამცემის მონაცემები განსხვავებულია 5.61.34[.]51 მისამართისთვის,

თუმცა აქვს მსგავსი სტილი:

• countryName=MU

• localityName=Port Louis

• organizationName=Ppoffi Sourinop Cooperative

• organizationalUnitName=ipeepstha and thicioi

• commonName=plledsaprell.Byargt9wailen.voting

გამცემის მონაცემთა ასეთი ტიპი ჩვეულებრივ გვხვდება Dridex-ის პოსტინფექციურ

ტრაფიკში. ჩვენ მომდევნო მაგალითში, თქვენ დამატებით ივარჯიშებთ Dridex-ის
სერტიფიკატის გამცემის მონაცემთა განხილვაში.

Next-IT Academy შალვა სვანიშვილი გვერდი №23

მეხუთე მაგალითი: შეფასება
ამ ლაბორატორიულ სამუშაოში გამოყენებული მეხუთე pcap ფაილი, Ursnif-traffic-
example-5.pcap, ხელმისაწვდომია etesting.gtu.ge საიტზე, მიმდინარე კვირის სასწავლო
მასალებში. წინა მაგალითის მსგავსად, ეს pcap ფაილიც შეიცავს Ursnif ინფექციას, რომელსაც
მოყვება Dridex, ამიტომ ჩვენ შეგვიძლია გამოვიყენოთ ამ ლაბორატორიულ სამუშაოში
აქამდე აღწერილი მაგალითებიდან მიღებული პრაქტიკული უნარები.

გახსენით მეხუთე pcap ფაილი Wireshark პროგრამაში და აქამდე შესწავლილის

საფუძველზე უპასუხეთ შემდეგ კითხვებს:

• საწყისი Ursnif ორობითი ფაილისთვის, რომელმა URL-მა დააბრუნა პასუხად

ვინდოუსის შესრულებადი ფაილი?

• საწყისი Ursnif ორობითი ფაილის გაგზავნის შემდგომ, ინფიცირებული ვინდოუს

ჰოსტი დაუკავშირდა სხვადასხვა დომენებს HTTP GET მოთხოვნებისთვის. რომელი
დომენის ტრაფიკი იყო წარმატებული და დაუშვა ინფიცირების გაგრძელება?

• რომელი დომენი იქნა გამოყენებული HTTPS ტრაფიკში მას შემდეგ, რაც Ursnif
გამაგრდა ინფიცირებულ ვინდოუს ჰოსტზე?

• .rar-ზე დაბოლოებული რომელი URL იყო გამოყენებული მომდევნო მავნე პროგრამის

ინფიცირებულ ვინდოუს ჰოსტთან გასაგზავნად?

• რომელი IP მისამართები იქნა გამოყენებული Dridex-ის პოსტინფექციური

ტრაფიკისთვის?

კითხვებზე პასუხის გაცემა

კითხვა: საწყისი Ursnif ორობითი ფაილისთვის, რომელმა URL-მა დააბრუნა პასუხად

ვინდოუსის შესრულებადი ფაილი?

პასუხი: hxxp://ritalislum[.]com/obedle/zarref.php?l=sopopf8.cab

ამ pcap ფაილში, ერთადერთი ვინდოუს შესრულებადი ფაილი არის თავდაპირველი

ვინდოუს შესრულებადი ფაილი Ursnif-სთვის. ამ შესრულებადი ფაილის სწრაფად
მოსაძებნად, გამოიყენეთ ქვემოთ მოცემული Wireshark ფილტრი:

ip contains "This program"

ამ ფილტრმა შედეგად უნდა გამოიტანოს მხოლოდ ერთი ფრეიმი. მიყევით TCP ნაკადს
ამ ფრეიმისთვის, როგორც ნაჩვენებია ოცდამეოთხე სურათზე.

Next-IT Academy შალვა სვანიშვილი გვერდი №24

სურათი №24. ფილტრის ჩართვა ვინდოუსის შესრულებადი ფაილის შემცველი ფრეიმის მოსაძებნად და TCP
ნაკადზე მიდევნება.

TCP ნაკადის ფანჯარა მოიცავს დომენსა და URL-ს, GET მოთხოვნიდან. იხილეთ

ოცდამეხუთე სურათი.

სურათი №25. TCP ნაკადიდან მიღებული URL ინფორმაცია

Next-IT Academy შალვა სვანიშვილი გვერდი №25

კითხვა: საწყისი Ursnif ორობითი ფაილის გაგზავნის შემდგომ, ინფიცირებული ვინდოუს
ჰოსტი დაუკავშირდა სხვადასხვა დომენებს HTTP GET მოთხოვნებისთვის. რომელი
დომენის ტრაფიკი იყო წარმატებული და დაუშვა ინფიცირების გაგრძელება?

პასუხი: k55gaisi[.]com

ვებ ტრაფიკის ტრაფიკის დასათვალიერებლად გამოიყენეთ ადრე შექმნილი basic ვებ

ფილტრი. Ursnif-ის ამ ვარიანტით გამოწვეული HTTP მოთხოვნები იწყება GET /images/-ით
ისე, როგორც ეს ვნახეთ ამ ლაბორატორიული სამუშაოს მეორე, მესამე და მეოთხე
მაგალითებში. k55gaisi[.]com დომენთან 15:36 საათზე გაშვებული პირველი HTTP მოთხოვნა
მონიშნულია ოცდამეექვსე სურათზე. თუმცა, თუ გაყვებით TCP ნაკადს დავინახავთ, რომ
პასუხად დაბრუნებულია 404 Not Found შეტყობინება.

სურათი №26. ვებ ტრაფიკის მოძებნა, Ursnif-ის მიერ გაგზავნილი HTTP GET მოთხოვნებისთვის

ოცდამეექვსე სურათზე ასევე ნაჩვენებია, რომ მომდევნო HTTP GET მოთხოვნა, Ursnif-
სტილის URL-სთვის, გაგზავნილია bon11ljgarry[.]com დომენთან, 15:37 საათზე. ამ
მოთხოვნის HTTP ნაკადი ავლენს გადამისამართებას www.search-error[.]com URL-ზე.

გადაინაცვლეთ ქვემოთ, leinwqoa[.]com დომენთან განხორციელებულ ანალოგიურ

ტრაფიკზე, როგორც მონიშნულია ოცდამეშვიდე სურათზე.

Next-IT Academy შალვა სვანიშვილი გვერდი №26

სურათი №27. სხვა Ursnif სტილის URL-ის მოძებნა, რომელიც გადამისამართდება ძიების შეცდომის შესახებ
გვერდზე

გადაადგილდით ქვემოთ, რათა იპოვოთ k55gaisi[.]com დომენთან გაგზავნილი ის

ოთხი HTTP GET მოთხოვნა, რომლებიც შედეგად აბრუნებენ 200 OK პასუხებს. ამ
მომენტიდან გრძელდება Ursnif ინფიცირება და ჩვენ ვერ ვიპოვით Ursnif სტილის ვერცერთ
HTTP მოთხოვნას, რომელიც იწყება GET /images/-ით.

სურათი №28. Ursnif სტილის იმ HTTP GET მოთხოვნების მოძებნა, რომლებიც აბრუნებენ 200 OK პასუხებს

Next-IT Academy შალვა სვანიშვილი გვერდი №27

კითხვა: რომელი დომენი იქნა გამოყენებული HTTPS ტრაფიკში მას შემდეგ, რაც Ursnif
გამაგრდა ინფიცირებულ ვინდოუს ჰოსტზე?

პასუხი: n9maryjanef[.]com

როდესაც Ursnif გამაგრდება სისტემაში, ჩვენ ვეღარ დავინახავთ Ursnif სტილის HTTP
მოთხოვნებს, რომლებიც იწყებიან GET /images/-ით. ამის ნაცვლად, ჩვენ ვიპოვით Ursnif-თან
დაკავშირებულ HTTPS ტრაფიკს. Ursnif სტილის ბოლო HTTP GET მოთხოვნის გაშვებიდან
მალევე, იწყება HTTPS ტრაფიკი 185.118.165[.]109 მისამართის მქონე n9maryjanef[.]com
დომენზე. იხილეთ ოცდამეცხრე სურათი.

სურათი №29. Ursnif-ის მიერ გაგზავნილი HTTPS ტრაფიკი

ip.addr eq 185.118.165.109 and ssl.handshake.type == 11 ჩანაწერით გაფილტვრითა და

სერტიფიკატის გამცემის მონაცემთა დათვალიერებით, თქვენ შეგიძლიათ დაადასტუროთ,
რომ ეს არის Ursnif ტრაფიკი. სერტიფიკატის გამცემის მონაცემები უნდა გამოიყურებოდეს
ისე, როგორც მოცემული იყო ჩვენ მეორე მაგალითში, მეათე სურათზე.

კითხვა: .rar-ზე დაბოლოებული რომელი URL იყო გამოყენებული მომდევნო მავნე

პროგრამის ინფიცირებულ ვინდოუს ჰოსტთან გასაგზავნად?

პასუხი: hxxps://testedsolutionbe[.]com/wp-content/plugins/apikey/uaasdqweeeeqsd.rar

Ursnif-ის მიერ, მომდევნო მავნე პროგრამისთვის, გაგზავნილი HTTP GET მოთხოვნები

ბოლოვდება .rar გაფართოებით, ამიტომ ამ URL-ის მოსაძებნად, ჩვენ pcap ფაილში,
გამოიყენეთ ქვემოთ მოცემული ფილტრი:

http.request and ip contains .rar

Next-IT Academy შალვა სვანიშვილი გვერდი №28

შედეგები უნდა იყოს ოცდამეათე სურათზე ნაჩვენების მსგავსი.

სურათი №30. URL მისამართის ძებნა ამ Ursnif ინფექციიდან მიღებული მომდევნო მავნე პროგრამისთვის

ყურადღება მიაქციეთ ოცდამეათე სურათს, სადაც ხდება HTTP GET მოთხოვნის

გადამისამართება HTTPS URL-ზე.

კითხვა: რომელი IP მისამართები იქნა გამოყენებული Dridex-ის პოსტინფექციური

ტრაფიკისთვის?

პასუხი: 185.99.133[.]38 და 5.61.34[.]51

ამ IP მისამართებიდან ერთ-ერთი არის იგივე, რაც იყო Dridex-ში, ჩვენ მეოთხე pcap
ფაილში, მას აქვს სერტიფიკატის გამცემის იგივე მონაცემები. 185.99.133[.]38 მისამართთან
გაშვებულ Dridex ტრაფიკს აქვს სერტიფიკატის გამცემის იგივე სტილის მონაცემები,
როგორც ეს ნაჩვენებია მეოთხე მაგალითში. არცერთი IP მისამართის ტრაფიკი არ მოიცავს
დომენურ სახელს.

ამ მაგალითში ადვილად შევამჩნევთ Dridex-ის პოსტინფექციურ ტრაფიკს, თუ ძებნას

დავუწყებთ ნებისმიერ დომენგარეშე HTTPS/SSL/TLS ტრაფიკს HTTP GET მოთხოვნის
შემდგომ, რომელიც მთავრდება .rar გაფართოებით. იხილეთ ოცდამეთერთმეტე სურათი.

Next-IT Academy შალვა სვანიშვილი გვერდი №29

 სურათი №31. Dridex ტრაფიკის მოძებნა მეხუთე pcap ფაილში

დასკვნა
ამ ლაბორატორიულ სამუშაოში მოცემული იყო Ursnif მავნე პროგრამით ვინდოუსის
ინფიცირების გამოკვლევისთვის საჭირო რჩევები. Ursnif-ის აქტივობებთან დაკავშირებული
მეტი pcap ფაილების მისაღებად გადადით შემდეგ ბმულზე: malware-traffic-analysis.net.

Next-IT Academy შალვა სვანიშვილი გვერდი №30