{
	"id": "f8ac9b1b-cf73-45c5-8ca6-02d08f66725f",
	"created_at": "2026-04-06T00:08:59.991614Z",
	"updated_at": "2026-04-10T13:12:15.661284Z",
	"deleted_at": null,
	"sha1_hash": "9d5e04b0150b1185c6bff20facad0ad59e47e6b5",
	"title": "Wireshark Tutorial: Examining Ursnif Infections",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 49960903,
	"plain_text": "Wireshark Tutorial: Examining Ursnif Infections\r\nBy Brad Duncan\r\nPublished: 2019-12-23 · Archived: 2026-04-05 17:37:07 UTC\r\nUrsnif is banking malware sometimes referred to as Gozi or IFSB. The Ursnif family of malware has been active\r\nfor years, and current samples generate distinct traffic patterns.\r\nThis tutorial reviews packet captures (pcaps) of infection Ursnif traffic using Wireshark. Understanding these\r\ntraffic patterns can be critical for security professionals when detecting and investigating Ursnif infections.\r\nThis tutorial covers the following:\r\nUrsnif distribution methods\r\nCategories of Ursnif traffic\r\nFive examples of pcaps from Ursnif infections\r\nNote: This tutorial assumes you have a basic knowledge of Wireshark, and it uses a customized column display\r\nshown in this tutorial. You should also have experience with Wireshark display filters as described in this\r\nadditional tutorial.\r\nUrsnif Distribution Methods\r\nUrsnif can be distributed through web-based infection chains and malicious spam (malspam). In some cases,\r\nUrsnif is a follow-up infection caused by different malware families like Hancitor, as reported in this recent\r\nexample.\r\nWe frequently find examples of Ursnif from malspam-based distribution campaigns, such as the example in Figure\r\n1.\r\nhttps://unit42.paloaltonetworks.com/wireshark-tutorial-examining-ursnif-infections/\r\nPage 1 of 28\n\nFigure 1. Flowchart from one of the more common Ursnif distribution campaigns.\r\nCategories of Ursnif Traffic\r\nThis tutorial covers two categories of Ursnif infection traffic:\r\nUrsnif without HTTPS post-infection traffic\r\nUrsnif with HTTPS post-infection traffic\r\nMalware samples from either of these categories create the same type of artifacts on an infected Windows host.\r\nFor example, both types of Ursnif remain persistent on a Windows host by updating the Windows registry, such as\r\nthe example shown in Figure 2.\r\nhttps://unit42.paloaltonetworks.com/wireshark-tutorial-examining-ursnif-infections/\r\nPage 2 of 28\n\nFigure 2. Example of Windows registry updates caused by samples of Ursnif, either with or without HTTPS post-infection traffic.\r\nExample 1: Ursnif without HTTPS\r\nThe first pcap for this tutorial, Ursnif-traffic-example-1.pcap, is available here. The chain of events behind this\r\ntraffic was tweeted here. Example 1 has been stripped of all traffic not directly related to the Ursnif infection.\r\nOpen the pcap in Wireshark and filter on http.request as shown in Figure 3.\r\nFigure 3. The pcap for example 1 filtered in Wireshark.\r\nhttps://unit42.paloaltonetworks.com/wireshark-tutorial-examining-ursnif-infections/\r\nPage 3 of 28\n\nIn this example, the Ursnif-infected host generates post-infection traffic to 8.208.24[.]139 using various domain\r\nnames ending with .at. This category of Ursnif causes the following traffic:\r\nHTTP GET requests caused by the initial Ursnif binary\r\nHTTP GET request for follow-up data, with the URL ending in .dat\r\nHTTP GET and POST requests after Ursnif is persistent in the Windows registry\r\nThe following HTTP data is used during the traffic in our first example:\r\nDomain for initial GET requests: w8.wensa[.]at\r\nRequest for follow-up data: hxxp://api2.casys[.]at/jvassets/xI/t64.dat\r\nDomain for GET and POST requests after Ursnif is persistent: h1.wensa[.]at\r\nFollow the TCP stream for the very first HTTP GET request at 20:13:09 UTC. The TCP stream window shows the\r\nfull URL. Note how the GET request starts with /api1/ and is followed by a long string of alpha-numeric\r\ncharacters with backslashes and underscores. Figure 4 highlights the GET request.\r\nFigure 4. Example of an HTTP GET request caused by our first Ursnif example.\r\nWe can find the same pattern from Ursnif activity caused by a Hancitor infection on December 10,2019. The pcap\r\nis available here. Mixed with the other malware activity, this December 10th example contains the following\r\nindicators for Ursnif:\r\nhttps://unit42.paloaltonetworks.com/wireshark-tutorial-examining-ursnif-infections/\r\nPage 4 of 28\n\nDomain for initial GET requests: foo.fulldin[.]at\r\nRequest for follow-up data: hxxp://one.ahah100[.]at/jvassets/o1/s64.dat\r\nDomain for GET and POST requests after Ursnif is persistent: api.ahah100[.]at\r\nNote how patterns from Ursnif traffic in the December 10th example are similar to the patterns we find in example\r\n1. These patterns are commonly seen from Ursnif samples that do not use HTTPS traffic.\r\nExample 2: Ursnif with HTTPS\r\nThe second pcap for this tutorial, Ursnif-traffic-example-2.pcap, is available here. Like our first pcap, this one\r\nhas also been stripped of any traffic not related to the Ursnif infection.\r\nOpen the pcap in Wireshark and filter on http.request or ssl.handshake.type == 1 as shown in Figure 5. If you are\r\nusing Wireshark 3.0 or newer, filter on http.request or tls.handshake.type == 1 for the correct results.\r\nFigure 5. The pcap for our second example filtered in Wireshark.\r\nThis example has the following sequence of events:\r\nHTTP GET request that returns an initial Ursnif binary\r\nHTTP GET requests caused by the initial Ursnif binary\r\nHTTPS traffic after Ursnif is persistent in the Windows registry\r\nFollow the TCP stream for the first HTTP GET request to ghinatronx[.]com. This TCP stream reveals a Windows\r\nexecutable or DLL file as shown in Figure 6. We can export the Ursnif binary from the pcap as described in this\r\nprevious tutorial.\r\nhttps://unit42.paloaltonetworks.com/wireshark-tutorial-examining-ursnif-infections/\r\nPage 5 of 28\n\nFigure 6. The first HTTP GET request returning a binary for Ursnif.\r\nThe next four HTTP requests to bjanicki[.]com were caused by the Ursnif binary. Follow the TCP stream for the\r\nfirst HTTP GET request to bjanicki[.]com at 18:46:21 UTC. This TCP stream shows the full URL. Note how the\r\nGET request starts with /images/ and is followed by a long string of alpha-numeric characters with backslashes\r\nand underscores before ending with .avi. This URL pattern is somewhat similar to Ursnif traffic from our first\r\npcap. Figure 7 highlights a GET request from our second pcap.\r\nhttps://unit42.paloaltonetworks.com/wireshark-tutorial-examining-ursnif-infections/\r\nPage 6 of 28\n\nFigure 7. Example of an HTTP GET request from our second Ursnif example.\r\nUnlike our first example, Ursnif in this second pcap generates HTTPS traffic after it becomes persistent on an\r\ninfected Windows host. Use your basic web filter as described in this previous tutorial for a quick review of the\r\nHTTPS traffic. Note the HTTPS traffic to prodrigo29lbkf20[.]com as shown in Figure 8.\r\nhttps://unit42.paloaltonetworks.com/wireshark-tutorial-examining-ursnif-infections/\r\nPage 7 of 28\n\nFigure 8. Filtering on web traffic in Wireshark, highlighting the HTTPS traffic generated by Ursnif.\r\nHTTPS traffic generated by this Ursnif variant reveals distinct characteristics in certificates used to establish\r\nencrypted communications. To get a closer look, filter on ssl.handshake.type == 11 (or tls.handshake.type == 11\r\nin Wireshark 3.0 or newer). Select the first frame in the results and go to the frame details window. There we can\r\nexpand lines and work our way to the certificate issuer data. Figure 9 shows how to begin.\r\nhttps://unit42.paloaltonetworks.com/wireshark-tutorial-examining-ursnif-infections/\r\nPage 8 of 28\n\nFigure 9. Finding our way to the certificate issuer data.\r\nAs shown in Figure 9, we expand the line for Secure Sockets Layer in the frame details window. For Wireshark\r\n3.0, this line shows as Transport Layer Security. Then we expand the line labeled TLSv1.2 Record Layer:\r\nHandshake Protocol: Certificate. Then we expand the line labeled Handshake Protocol: Certificate.\r\nWe keep expanding, until we find our way to the certificate issuer data as shown in Figure 10.\r\nFigure 10. Certificate issuer data from HTTPS traffic caused by Ursnif.\r\nIn Figure 10 shown under the Handshake Protocol: Certificate line, we work our way down through the\r\nfollowing items:\r\nCertificates (615 bytes)\r\nCertificate: 30820260308201c9a003020102020900c692c94106d77dfc...\r\nsignedCertificate\r\nIssuer: rdnSequence (6)\r\nrdnSequence: 6 items (id-at-commonName=*,id-at-organizationalUnitN...\r\nIndividual items under the rdnSequence line show properties of the certificate issuer. These reveal the following\r\ncharacteristics:\r\ncountryName=XX\r\nstateOrProvinceName=1\r\nlocalityName=1\r\nhttps://unit42.paloaltonetworks.com/wireshark-tutorial-examining-ursnif-infections/\r\nPage 9 of 28\n\norganizationName=1\r\norganizationalUnitName=1\r\ncommonName=*\r\nThis issuer data is not valid, and these patterns are commonly seen in Ursnif infections. But what does legitimate\r\ncertificate data look like? Figure 11 shows valid data from a certificate issued by DigiCert.\r\nFigure 11. Valid certificate issuer data.\r\nOne last thing about Ursnif is the IP address check by an Ursnif-infected host. This happens over DNS using a\r\nresolver at opendns[.]com. Like other IP address identifiers, this is a legitimate service. However, these services\r\nare commonly used by malware.\r\nTo see this IP address check, filter on dns.qry.name contains opendns.com and review the results as shown in\r\nFigure 12.\r\nhttps://unit42.paloaltonetworks.com/wireshark-tutorial-examining-ursnif-infections/\r\nPage 10 of 28\n\nFigure 12. IP address check by an Ursnif-infected Windows host.\r\nAs shown in Figure 12, the Window host generated a dns query for resolver1.opendns[.]com followed by a DNS\r\nquery to 208.67.222[.]222 for myip.opendns[.]com. The DNS query to myip.opendns[.]com returned the public IP\r\naddress of the infected Windows host.\r\nExample 3: Ursnif with Follow-up Malware\r\nOur third pcap, Ursnif-traffic-example-3.pcap, is available here. This pcap also has unrelated activity stripped\r\nfrom the traffic, but it builds on our last example. Our third pcap includes what appears to be decoy traffic, and it\r\nalso includes an HTTP GET request for follow-up malware. The sequence of events is:\r\nHTTP GET request that returns an initial Ursnif binary\r\nHTTP GET requests caused by the initial Ursnif binary, including decoy URLs\r\nHTTPS traffic after Ursnif is persistent in the Windows registry\r\nHTTP GET request for follow-up malware\r\nUse your basic web filter as described in this previous tutorial for a quick review of the web-based traffic as\r\nshown in Figure 13.\r\nhttps://unit42.paloaltonetworks.com/wireshark-tutorial-examining-ursnif-infections/\r\nPage 11 of 28\n\nFigure 13. Filtering our third pcap for web traffic in Wireshark.\r\nIn Figure 13, the initial HTTP request to sinicaleer[.]com returned a Windows executable for Ursnif. The\r\nremaining traffic visible Figure 13 was caused by the Ursnif executable until it became persistent.\r\nThree HTTP requests to google[.]com follow similar URL patterns as Ursnif traffic to an actual malicious domain\r\nof ghdy656262oe[.]com. These HTTP GET requests to google[.]com appear to be decoy traffic, because they do\r\nnot assist the infection. HTTPS traffic over TCP port 443 to gmail[.]com and www.google[.]com also serves no\r\ndirect purpose for the infection, and that activity could also be classified as decoy traffic. Figure 14 shows an\r\nexample of the decoy HTTP GET requests to google[.]com.\r\nhttps://unit42.paloaltonetworks.com/wireshark-tutorial-examining-ursnif-infections/\r\nPage 12 of 28\n\nFigure 14. Decoy HTTP GET request by the Ursnif-infected host to a Google domain.\r\nNote the HTTP traffic to ghdy656262oe[.]com. The first two GET requests to ghdy656262oe[.]com return a 404\r\nNot Found response as shown in Figure 15. The third HTTP GET request returns a 200 OK response, and the\r\ninfection continues as shown in Figure 16.\r\nhttps://unit42.paloaltonetworks.com/wireshark-tutorial-examining-ursnif-infections/\r\nPage 13 of 28\n\nFigure 15. First two HTTP GET requests to malicious Ursnif domain return a 404 Not Found response.\r\nFigure 16. Some false starts before the Ursnif infection continues.\r\nhttps://unit42.paloaltonetworks.com/wireshark-tutorial-examining-ursnif-infections/\r\nPage 14 of 28\n\nSince the first HTTP GET request to ghdy656262oe[.]com was not a 200 OK, the infected Windows host cycled\r\nthrough other malicious domains to continue the infection. These two domains are tnzf3380au[.]top and\r\nxijamaalj[.]com. However, the DNS queries for these domains returned a “No such name” in response, so the\r\ninfected Windows host went back to trying ghdy656262oe[.]com.\r\nUse the following Wireshark filter to better see this sequence of events:\r\n((http.request or http.response) and ip.addr eq 194.1.236.191) or dns.qry.name contains tnzf3380au or\r\ndns.qry.name contains xijamaalj\r\nThe results should appear similar to the column display in Figure 17.\r\nFigure 17. Filtering to show how the infected Windows host tries Ursnif-related domains before it hits a 200 OK\r\nin HTTP traffic.\r\nTo review the rest of the infection, use your basic web filter and scroll to the end of the results. Figure 18 shows\r\nthe post-infection traffic after Ursnif becomes persistent.\r\nhttps://unit42.paloaltonetworks.com/wireshark-tutorial-examining-ursnif-infections/\r\nPage 15 of 28\n\nFigure 18. Post-infection traffic after Ursnif becomes persistent on the victim’s Windows host.\r\nIn Figure 18, after five HTTP GET requests to ghdy656262oe[.]com, we find traffic generated by the infected\r\nWindows host after Ursnif becomes persistent. This includes HTTPS traffic to google[.]com and gmail[.]com.\r\nTraffic to vnt69tnjacynthe[.]com should have the same type of certificate issuer data we witnessed in our second\r\npcap. But this traffic includes an HTTP GET request to carresqautomotive[.]com ending with .rar.\r\nThis URL ending in .rar returned follow-up malware. However, this follow-up malware is encoded or otherwise\r\nencrypted when sent over the network. The binary decoded on the infected Windows host, which is not seen in the\r\ninfection traffic. Follow the TCP stream for the HTTP GET request to carresqautomotive[.]com, and you should\r\nsee the same data as shown in Figure 19.\r\nhttps://unit42.paloaltonetworks.com/wireshark-tutorial-examining-ursnif-infections/\r\nPage 16 of 28\n\nFigure 19. Follow-up malware sent to an Ursnif-infected Windows host.\r\nThis data is encrypted, so we cannot export a copy of the follow-up malware from the pcap. Therefore, we must\r\nrely on other post-infection traffic to determine what type of malware was sent to the Ursnif-infected host.\r\nWe have seen various types of follow-up malware from Ursnif infections, including Dridex, IcedID, Nymain,\r\nPushdo, and Trickbot.\r\nOur next example is an Ursnif infection with Dridex as the follow-up malware.\r\nExample 4: Ursnif Infection with Dridex\r\nOur fourth pcap, Ursnif-traffic-example-4.pcap, is available here. Unlike our first three examples, this pcap does\r\nnot have unrelated activity stripped from the traffic.\r\nUse your basic web filter to get a better idea of the traffic. Your results should appear similar to Figure 20.\r\nhttps://unit42.paloaltonetworks.com/wireshark-tutorial-examining-ursnif-infections/\r\nPage 17 of 28\n\nFigure 20. Traffic from our fourth pcap filtered in Wireshark.\r\nThis pcap has the same sequence of events as our previous example, but it adds post-infection activity from the\r\nfollow-up malware:\r\nHTTP GET request that returns an initial Ursnif binary\r\nHTTP GET requests caused by the initial Ursnif binary, including decoy URLs\r\nHTTPS traffic after Ursnif is persistent in the Windows registry\r\nHTTP GET request for follow-up malware\r\nPost-infection activity from the follow-up malware\r\nIn this fourth example, the HTTP GET request for an initial Ursnif binary is to oklogallem[.]com. Ursnif causes\r\nHTTP GET requests to kh2714ldb[.]com before the infection becomes persistent.\r\nFigure 21 shows activity after Ursnif is persistent, where Ursnif causes HTTPS traffic to s9971kbjjessie[.]com.\r\nWe then see an HTTP GET request to startuptshirt[.]my for the follow-up malware. Finally we find post-infection\r\ntraffic caused by the follow-up malware.\r\nhttps://unit42.paloaltonetworks.com/wireshark-tutorial-examining-ursnif-infections/\r\nPage 18 of 28\n\nFigure 21. Activity from the infection after Ursnif is persistent.\r\nOur fourth example follows the same infection patterns as our third pcap, but now we also have HTTPS/SSL/TLS\r\ntraffic to 94.140.114[.]6 and 5.61.34[.]51 without any associated domain name. This is Dridex post-infection\r\ntraffic.\r\nCertificate issuer data for Dridex is different than certificate issuer data for Ursnif. Use the following filter to\r\nreview the Dridex certificate data in our fourth pcap:\r\n(ip.addr eq 94.140.114.6 or ip.addr eq 5.61.34.51) and ssl.handshake.type eq 11\r\nNote: if you are using Wireshark 3.0 or newer, use tls.handshake.type instead of ssl.handshake.type.\r\nSelect the first frame in the results, go to the frame details window, and expand the certificate-related lines as\r\nshown by our second example in Figures 9 and 10. Examining certificate issuer data from our fourth pcap should\r\nlook similar to Figures 22 and 23.\r\nhttps://unit42.paloaltonetworks.com/wireshark-tutorial-examining-ursnif-infections/\r\nPage 19 of 28\n\nFigure 22. Working our way to the certificate issuer data in the Dridex traffic.\r\nFigure 23. Reaching the certificate issuer data from one of the Dridex IP addresses.\r\nhttps://unit42.paloaltonetworks.com/wireshark-tutorial-examining-ursnif-infections/\r\nPage 20 of 28\n\nUnder the rdnSequence line, we find properties of the certificate issuer. Certificate issuer characteristics for\r\nHTTPS/SSL/TLS traffic at 94.140.114[.]6 follows:\r\ncountryName=NP\r\nlocalityName=Kathmandu\r\norganizationName=Buvecoww Fftaites O.V.E.E.\r\norganizationalUnitName=Olfo Dusar Latha\r\ncommonName=ndltman-dsamutb.spiegel\r\nCertificate issuer data is different for 5.61.34[.]51, but it follows a similar style:\r\ncountryName=MU\r\nlocalityName=Port Louis\r\norganizationName=Ppoffi Sourinop Cooperative\r\norganizationalUnitName=ipeepstha and thicioi\r\ncommonName=plledsaprell.Byargt9wailen.voting\r\nThis type of issuer data is commonly seen for Dridex post-infection traffic. In our next example, you can further\r\npractice reviewing certificate issuer data for Dridex.\r\nExample 5: Evaluation\r\nThe fifth pcap for this tutorial, Ursnif-traffic-example-5.pcap, is available here. Like our previous example, this\r\npcap has an Ursnif infection followed by Dridex, so we can practice the skills described so far in this tutorial.\r\nBased on what we have learned so far, open the fifth pcap in Wireshark, and answer the following questions:\r\nFor the initial Ursnif binary, which URL returned a Windows executable file?\r\nAfter the initial Ursnif binary was sent, the infected Windows host contacted different domains for the\r\nHTTP GET requests. Which domain was the traffic successful and allowed the infection to proceed?\r\nWhat domain was used in HTTPS traffic after Ursnif became persistent on the infected Windows host?\r\nWhat URL ending in .rar was used to send follow-up malware to the infected Windows host?\r\nWhat IP addresses were used for the Dridex post-infection traffic?\r\nAnswers follow.\r\nQ: For the initial Ursnif binary, which URL returned a Windows executable file?\r\nA: hxxp://ritalislum[.]com/obedle/zarref.php?l=sopopf8.cab\r\nThe only Windows executable file in this pcap is the initial Windows executable file for Ursnif. Use the following\r\nWireshark search filter to quickly find this executable:\r\nip contains \"This program\"\r\nThis filter should provide only one frame in the results. Follow the TCP stream for this frame as shown in Figure\r\n24.\r\nhttps://unit42.paloaltonetworks.com/wireshark-tutorial-examining-ursnif-infections/\r\nPage 21 of 28\n\nFigure 24. Filtering to find a frame with the Windows executable file and following the TCP stream.\r\nThe TCP stream window contains the domain and URL from the GET request as shown in Figure 25.\r\nhttps://unit42.paloaltonetworks.com/wireshark-tutorial-examining-ursnif-infections/\r\nPage 22 of 28\n\nFigure 25. URL info from the TCP stream.\r\nQ: After the initial Ursnif binary was sent, the infected Windows host contacted different domains for the HTTP\r\nGET requests. Which domain was the traffic successful and allowed the infection to proceed?\r\nA: k55gaisi[.]com\r\nUse your basic web filter for an overview of the web traffic. HTTP requests caused by this variant of Ursnif start\r\nwith GET /images/ as already seen in examples two, three, and four of this tutorial. The first HTTP request to\r\nk55gaisi[.]com at 15:36 UTC is noted in Figure 26. But if you follow the TCP stream, it shows a 404 Not Found\r\nas the response.\r\nhttps://unit42.paloaltonetworks.com/wireshark-tutorial-examining-ursnif-infections/\r\nPage 23 of 28\n\nFigure 26. Searching web traffic for HTTP GET requests caused by Ursnif.\r\nAlso shown in Figure 26, the next HTTP GET request for an Ursnif-style URL is to bon11ljgarry[.]com at 15:37\r\nUTC. The HTTP stream for that request reveals a redirect to a URL at www.search-error[.]com.\r\nScroll down further, and for similar traffic to leinwqoa[.]com as noted in Figure 27.\r\nhttps://unit42.paloaltonetworks.com/wireshark-tutorial-examining-ursnif-infections/\r\nPage 24 of 28\n\nFigure 27. Finding another Ursnif-style URL that redirects to a search error page.\r\nScroll down further to find four HTTP GET requests to k55gaisi[.]com that return 200 OK responses. From this\r\npoint, the Ursnif infection proceeds, and we find no further Ursnif-style HTTP requests that start with GET\r\n/images/.\r\nFigure 28. Finding the Ursnif-style HTTP GET requests that return a 200 OK.\r\nhttps://unit42.paloaltonetworks.com/wireshark-tutorial-examining-ursnif-infections/\r\nPage 25 of 28\n\nQ: What domain was used in HTTPS traffic after Ursnif became persistent on the infected Windows host?\r\nA: n9maryjanef[.]com\r\nWhen Ursnif is persistent, we no longer see Ursnif-style HTTP requests starting with GET /images/. Instead, we\r\nfind Ursnif-related HTTPS traffic. Shortly after the final Ursnif-style HTTP GET request, HTTPS traffic to\r\nn9maryjanef[.]com begins on 185.118.165[.]109 as highlighted in Figure 29. This is Ursnif traffic.\r\nFigure 29. HTTPS traffic caused by Ursnif.\r\nYou can confirm this is Ursnif traffic by filtering on ip.addr eq 185.118.165.109 and ssl.handshake.type == 11\r\nand reviewing the certificate issuer data. The certificate issuer data should look the same as our second example in\r\nFigure 10.\r\nQ: What URL ending in .rar was used to send follow-up malware to the infected Windows host?\r\nA: hxxps://testedsolutionbe[.]com/wp-content/plugins/apikey/uaasdqweeeeqsd.rar\r\nHTTP GET requests caused by Ursnif for follow-up malware end in .rar, so use the following filter to find this\r\nURL in our pcap:\r\nhttp.request and ip contains .rar\r\nThe results should be similar to what we see in Figure 30.\r\nhttps://unit42.paloaltonetworks.com/wireshark-tutorial-examining-ursnif-infections/\r\nPage 26 of 28\n\nFigure 30. Finding the URL for follow-up malware from this Ursnif infection.\r\nNotice in Figure 30 how the HTTP GET request in Figure 30 redirects to an HTTPS URL.\r\nQ: What IP addresses were used for the Dridex post-infection traffic?\r\nA: 185.99.133[.]38 and 5.61.34[.]51\r\nOne of these IP addresses is the same as Dridex in our fourth pcap, and it has the same certificate issuer data.\r\nDridex traffic to 185.99.133[.]38 has the same style of certificate issuer data as seen in example 4. Traffic to both\r\nIP addresses does not involve a domain name.\r\nThe Dridex post-infection traffic is easy to spot in this example if we look for any HTTPS/SSL/TLS traffic\r\nwithout a domain after the HTTP GET request ending in .rar as shown in Figure 31.\r\nhttps://unit42.paloaltonetworks.com/wireshark-tutorial-examining-ursnif-infections/\r\nPage 27 of 28\n\nFigure 31. Finding the Dridex traffic in our fifth pcap.\r\nConclusion\r\nThis tutorial provided tips for examining Windows infections with Ursnif malware. More pcaps with examples of\r\nUrsnif activity can be found at malware-traffic-analysis.net.\r\nFor more help with Wireshark, see our previous tutorials:\r\nCustomizing Wireshark – Changing Your Column Display\r\nUsing Wireshark – Display Filter Expressions\r\nUsing Wireshark: Identifying Hosts and Users\r\nUsing Wireshark: Exporting Objects from a Pcap\r\nWireshark Tutorial: Examining Trickbot Infections\r\nSource: https://unit42.paloaltonetworks.com/wireshark-tutorial-examining-ursnif-infections/\r\nhttps://unit42.paloaltonetworks.com/wireshark-tutorial-examining-ursnif-infections/\r\nPage 28 of 28\n\n https://unit42.paloaltonetworks.com/wireshark-tutorial-examining-ursnif-infections/   \nFigure 22. Working our way to the certificate issuer data in the Dridex traffic.\nFigure 23. Reaching the certificate issuer data from one of the Dridex IP addresses.\n   Page 20 of 28",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://unit42.paloaltonetworks.com/wireshark-tutorial-examining-ursnif-infections/"
	],
	"report_names": [
		"wireshark-tutorial-examining-ursnif-infections"
	],
	"threat_actors": [],
	"ts_created_at": 1775434139,
	"ts_updated_at": 1775826735,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/9d5e04b0150b1185c6bff20facad0ad59e47e6b5.pdf",
		"text": "https://archive.orkl.eu/9d5e04b0150b1185c6bff20facad0ad59e47e6b5.txt",
		"img": "https://archive.orkl.eu/9d5e04b0150b1185c6bff20facad0ad59e47e6b5.jpg"
	}
}