Official GovCERT.ch Blog

When Gozi Lost its Head

Published on 2017-04-04 08:15:00 UTC by GovCERT.ch (permalink)
Last updated on 2017-04-04 08:15:17 UTC

After our automated unpacking procedure recently failed on a Gozi binary (MD5 c1a73ff8fb2836fe47bc095b622c6c50), we were forced to perform a manual analysis - and indeed we found some interesting new features in the first layer of the packer…

An initial challenge – not yet too unusual though – was the waiting loop in the packer near the start:

IDA debugger in action
Initial waiting loop (click to enlarge)

The code uses the MMX instruction set and basically increments MM7 (initialized with 0, while MM0 is initialized with 1) until it reaches MM2 (realized by the PXOR), which itself is set to a value set by the RDTSC instruction. This process can be pretty time-consuming, also due to the added junk instructions. To shorten the waiting time, the easiest way is to find and set a breakpoint on the PXOR instruction, e.g. by searching for the sequence “0F EF” in the code segment. There are usually only very few false matches (do not rely on the arguments, so don’t search for “0F EF D7”, as these vary in other samples). When the breakpoint is reached, just copy the value of MM2 over to MM7 (the counter). One could also change the JNZ instruction, but this way we’re sure later checks don’t mess things up.

The code will then perform a set of debugger and anti-RE checks. Most of them are handled well with standard OllyDbg anti-anti-RE plugins. One check though could not be neutralized, and we can study this by setting a breakpoint on GetTickCount. The calling code is in an additionally allocated buffer:

IDA debugger in action
Anti RE-Check (click to enlarge)

The code sleeps for 2 seconds (0x7d0 = 2000 ms) between two calls to GetTickCount. GetTickCount is often used for debugger detection, mainly to detect tracers, because code usually runs slower in a debugger if tracing is enabled. Anti-debugger checks with two GetTickCount calls are common; they usually assert that the elapsed time is not too large. Most anti-anti-RE plugins in OllyDbg catch these checks by making sure GetTickCount calls always return nearby or even subsequent values, in order to simulate fast running code. But in this case, the opposite detection approach is taken: the code makes sure the elapsed time – found in EAX after the SUB instruction – is larger than 1.5 seconds (0x5dc = 1500 ms). In other words, it asserts that at least 1.5 seconds passed. Bummer, the detection would not have been possible without the help of OllyDbg’s anti-anti-RE technique…

Fortunately, once analyzed, it is easy to fix: we just need to adjust the value returned by the second GetTickCount so it is at least 1500 above the first return value, which we find on the stack. Alternatively, toggling the carry flag before the JB works too.

Now we set a breakpoint on VirtualAllocEx and find that a pretty large buffer of 64MB (0x4000000) is allocated, so we keep an eye on it. The next breakpoint we set is GetCommandLineW (and VirtualAllocEx is removed). After reaching it, a look at the previously allocated buffer at an offset of around 0x6000 (you can just search for the string “This program”) reveals:

Anti PE-header
Anti PE-header (click to enlarge)

It is a PE file. Well, nearly… something is missing: there is no magic MZ at the start, which should occur in any standard PE file. It was obviously removed, and this was also the main reason our automated extraction process did not work. This is how it is supposed to look like, after manually patching in the MZ:

Anti PE-header
Final payload (click to enlarge)

Those who know Gozi will doubtlessly recognize its typical header towards the bottom of the screenshot. Dumping the data and applying the standard procedure does the job from here on.

Share on Twitter Share on Facebook

Taking a Look at Nymaim

Published on 2017-03-03 10:50:00 UTC by GovCERT.ch (permalink)
Last updated on 2017-03-03 10:58:48 UTC

Nymaim is active worldwide since at least 2013 and is also responsible for many infections in Switzerland. Sinkhole Data shows that Nymaim is responsible for about 2% of infected de- vices 1 in Switzerland that hit sinkholes the last few days.

When we looked at the Nymaim trojan in January, we were stunned by their powerful code obfuscation techniques and wrote an IDAPython script to deobfuscate the code using the debugger engine. Later we found similar tools already available in the public to do this using code emulation. Nevertheless, we decided to publish a paper about our approach, as it is a very nice case study to demonstrate how debugger orchestration works in IDAPython, and to explain different disassembly strategies that can be used. Instrumenting the debugger means to set breakpoints in scripts and to run the code in pieces, which has a very dynamic and fascinating impact on the IDA GUI:

IDA debugger in action
IDA debugger in actione (click to enlarge)

In addition, the Unicorn engine was applied as an alternative to the debugger. Finally, the deobfuscation of Windows API calls using the debugger approach is described - a problem where emulation techniques usually doesn't work due to the lack of a full operating system environment. Some generalizations of the deobfuscation algorithm are discussed to be prepared for potential further developments of the obfuscation, and a few unusual locations are depicted where the obfuscation was applied on non-constant input parameters.

Nymaim is active worldwide since at least 2013 and is also responsible for many infections in Switzerland. We recorded the IP addresses that one of the current C&C domains (olseneinfeis.com) revolved to over the past weeks. The domain name is hosted on a fast flux botnet; the IP addresses are encrypted, and one of them acts as a checksum for the other ones (more about this can be found here). We found nearly 5'000 valid and decrypted IP addresses, after having removed the checksum IP; These are mostly DSL lines, so we suspect a botnet behind them. The following picture shows the distribution of these IP addresses by country:

Nymaim's FastFlux botnet
Nymaim's FastFlux botnet (click to enlarge)

Our whitepaper can be downloaded here:



Share on Twitter Share on Facebook

The Rise of Dridex and the Role of ESPs

Published on 2017-02-20 10:53:00 UTC by GovCERT.ch (permalink)
Last updated on 2017-02-20 12:50:37 UTC

Last week, we have warned Swiss citizens about a new malspam run targeting exclusively Swiss internet users. The attack aimed to infect them with Dridex. Dridex is a sophisticated eBanking Trojan that emerged from the code base of Bugat / Cridex in 2014. Despite takedown attempts by the security industry and several arrests conducted by the FBI in 2015, the botnet is still very active. In 2016, MELANI / GovCERT.ch became aware of a handful of highly sophisticated attacks against small and medium businesses (SMB) in Switzerland aiming to steal large amounts of money by targeting offline payment software. During our incident response in 2016, we could identify Dridex to be the initial infection vector, which had arrived in the victim’s mailbox by malicious Office Word documents, and uncovered the installation of a sophisticated malware called Carbanak, used by the attacker for lateral movement and conducting the actual fraud. Between 2013 and 2015, the Carbanak malware was used to steal approximately 1 billion USD from banks worldwide.

The Traditional Dridex Spam Runs

Dridex’s main infection vector is malspam. But unlike most of the spam that arrives at internet users’ mailbox every day, spam mails distributing Dridex don’t originate from compromised machines – so called spambots –, but rather from infrastructure rented by the attackers themselves for the exclusive purpose of sending out their malspam mails. As the IP addresses and domain names used to distribute Dridex are under control of the attackers, all state-of-the-art methods are available to ensure the infrastructure as well as the distributed spam emails look legit and therefore bypass common spam filters. For example, Dridex spam usually originates from IP space of hosting companies with a valid rDNS record which matches the sender’s domain name (from and envelope-from). In addition, the sending domain names all have a valid SPF record (Sender Policy Framework) matching the senders IP address. Nevertheless, spam filter- and DNSBL provider did catch up in the recent weeks, doing a better job in detecting mails distributing Dridex, marking them as spam. Therefore, we have seen less Dridex malspam emails being delivered to the internet users’ mailboxes recently than we did before.

The Role of ESPs

In the past weeks, we could lean back a bit and watch common spam filters doing a good job identifying and blocking Dridex spam campaigns that are being sent to Swiss internet users every Tuesday – Thursday. However, on Wednesdays February 15, 2017, the game changed.

Shortly after noon, we have seen a huge spike in emails being delivered to our spamtraps. The emails looked like this:

Dridex spam mail sent to Swiss internet users on Feb 15, 2017
Dridex spam mail sent to Swiss internet users on Feb 15, 2017 (click to enlarge)

A first glance at the sender email doesn’t reveal it as spam. Even looking at the email’s header wrongly supports the same: The email has been sent out by SendGrid. SendGrid is a well-known Email Service Provider (ESP) offering email marketing and transactional email service. Many big companies and brands rely on ESPs to ensure that their emails are being delivered to their customer’s mailboxes smoothly. As many of the fortune 100 companies are using an ESP, IP addresses associated which such are often whitelisted at common email servers and DNSBL providers. The reason for this is simple: You can’t blacklist an IP address associated with an ESP as much as you can’t blacklist IP addresses associated with Google or Outlook.com. Otherwise you might end up blocking thousands of legitimate emails coming from Uber, Spotify, Airbnb and any other brands that are using the ESP’s infrastructure to send emails.

SendGrid Service description, highlighting by the vendor
SendGrid Service description highlighting by the vendor (source: SendGrid)

The Spam Email

The emails we have seen hitting our traps on February 15, 2017 pretended to come from Swisscom. Swisscom is Switzerland’s biggest telecommunication provider. It is a brand that is known to every Swiss citizen. The mails claim to be an e-bill (Rechnung), which isn’t uncommon as Swisscom is indeed sending out e-bills via email. But why would Swisscom send an e-bill to our spam traps? And why not just one, but rather thousands within just a couple of minutes? This made us suspicious, so we decided to take a closer look at these emails. The attackers have prepared the spam emails very well. Below is a screenshot of a legit e-bill that Swisscom usually sends out to their customers, and the fake one spammed out by the offenders:

Fake Swisscom e-bill compared to a real one
Fake Swisscom e-bill compared to a real one (click to enlarge)

The emails look very similar, but they aren’t identical. The reason for this is simple: The spam email on the left side pretends to be an e-bill from Swisscom to an enterprise customer (SME), while the one on the right side is a legit e-bill sent out by Swisscom to a home user (SOHO), because we don’t have a legitimate SME type e-bill available. The left (fake) one pretends to come from sme.contactcenter@bill.swisscom.com, while the right, legit one has been sent from contact.center@bill.swisscom.com. As the spam emails are apparently targeting enterprise customers (SME), the invoice total is much higher than what a home user expects to be billed.

Looking at one of these emails for a second time, it appears that the the diacritical characters ä/ö/ü, which are very common in German, are completely missing and replaced by a/o/u. Secondly, the hyperlink “Rechnung einsehen” that the user should click (which means “review bill”) does not point to a domain name owned by Swisscom, but to Microsoft’s Sharepoint service. Analyzing all of such emails we got, we were able to collect the following URLs:

https://jensenbowers-my.sharepoint.com/personal/leeanderson_jensenbowers_com_au/_layouts/15/download.aspx?docid=068187f5a930340c89e3b7c5c9b9c24f7&authkey=AarHUbAy66DSX08VzRPQ25w
https://talofinancial-my.sharepoint.com/personal/ashleigh_schipp_talofinancial_com_au/_layouts/15/guestaccess.aspx?docid=07697c8afb3e544808bf527394eb7154b&authkey=Adh6QVItbnSLOpXvxh_BfCs
https://yemposolutions-my.sharepoint.com/personal/amor_novicio_yempo-solu-tions_com/_layouts/15/guestaccess.aspx?docid=0ce03b9fd12d949cf91f56a7d1fbf4b93&authkey=ASOCPusN_QaBSXcCPxEkT9s

Following these links reveal them to serve a ZIP archive called Rechnung.zip containing a JavaScript file with the matching name Rechnung.js. So, is Swisscom sending out JavaScript files to their customers? Not really – we became suspicious.

The JavaScript

Having a look at the JavaScript confirms our suspicion that these emails can’t be legit: The JavaScript files are highly obfuscated:

Obfuscated JavaScript
Obfuscated JavaScript (click to enlarge)

After deobfuscation, the purpose of the script becomes clear:

Deobfuscated JavaScript
Deobfuscated JavaScript (click to enlarge)

Once executed, the script will download a windows binary from Sharepoint online and execute it:

https://talofinancial-my.sharepoint[.]com/personal/ashleigh_schipp_talofinancial_com_au/_layouts/15/guestaccess.aspx?docid=07697c8afb3e544808bf527394eb7154b&authkey=Adh6QVItbnSLOpXvxh_BfCs
https://yemposolutions-my.sharepoint.com/personal/amor_novicio_yempo-solu-tions_com/_layouts/15/guestaccess.aspx?docid=0ce03b9fd12d949cf91f56a7d1fbf4b93&authkey=ASOCPusN_QaBSXcCPxEkT9s

The Payload

The JavaScript drops the following windows executable from the said Sharepoint URLs:

Filename: line.registr
MD5 hash: 20e10d0c6828e6df0882c043113285d6
SHA256 hash: e01c0ba8b8e3ad5735bdd15bda5bf449ec9c6167badd7173fca04eb6b41570e2

Doing a quick analysis of the payload reveals the distributed malware as Dridex (version 4.23).

Dridex is using different botnets (botnetid). Each botnet has its own configuration file and is targeting a specific country or a set of countries. The Dridex payload we have observed in this campaign could be associated with botnetid 2144, which is known for attacking customers of financial institutions in Switzerland.

Once executed, an infected computer is going to call out to six different IP address that all act as botnet command&control server (C&C) for the Dridex malware. Each of these IP addresses belongs to a compromised server in the internet and is forwarding the botnet traffic from Dridex infected machines to a tier-2 infrastructure:

198.167.136.139:443
159.226.92.9:4431
136.243.209.34:443
109.235.76.95:1843
209.20.67.87:5353
194.150.118.25:3101

A Dridex bot will contact any of these IP address and will try to get an updated configuration from the botnet masters. An updated configuration file will contain a new set of botnet controllers, a list of financial institutions in Switzerland for which Dridex redirects the traffic (online fraud), as well as a list of offline payment software (offline fraud).

Dridex also sends out a list of installed software to the botnet C&C. If that list includes offline payment software or software that could potentially be used to transfer payment instructions (such as FTP clients), the infected machine (bot) will get flagged and the C&C might deliver Carbanak. Otherwise, a full-featured version of Dridex is installed.

The Dridex configuration files we received can be downloaded at the links below:

Summary of Infection Chain

The following graphic summarizes the events that lead up to the infection with Dridex and/or Carbanak:

Dridex / Carbanak infection chain
Dridex / Carbanak infection chain (click to enlarge)

Detection of Dridex

Dridex infections are hard to detect and to clean, as the malware usually only resides in memory. Dridex is only written to disk upon shutdown, which it knows about from hooking Window’s shutdown API calls. We learned about several cases where Dridex infections were allegedly cleaned up by professional IT services, because they did not find traces of Dridex on disk or startup entries related to Dridex. We recommend that infected systems are reimaged (reinstalled), or at least cleaned after booting from a rescue stick.

A promising way to detect current or former infections of Dridex is to look at the registry. Dridex stores its configuration in multiple registry keys of the format:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\CLSID\{GUID}\ShellFolder 

{GUID} is the textual representation of an id that varies between infected clients. The data is stored as binary data under a name which is also formatted like a GUID. The following screenshot shows the registry for an infected system:

Screenshot of the Registry on a Dridex infected computer
Screenshot of the Registry on a Dridex infected computer (click to enlarge)

A clean system, on the other hand, has fewer (usually one or two) entries that match the pattern. None of the keys should have a GUID-like name or contain binary data:

Screenshot of the Registry on a clean computer
Screenshot of the Registry on a clean computer (click to enlarge)

We wrote a small Powershell-Script (dridexregistry.ps1) that checks the registry for potential Dridex entries. The script also checks the Appdata/Local and Appdata/LocalLow for binaries that match the pattern of Dridex. As clarified above, these files do not usually exist even on infected systems.

Filename: carbanaktargets.ps1
MD5 hash: 04a98c92a8b943ee90b6bda921abe0f0
SHA256: a2b667ccb014ba732e1ad337a582f8aa464b5fa7913ebd8034fe8b6bc6d6009a

Filename: dridexregistry.ps1
MD5 hash: d155bf49b289f14047b97b16d9a2a207
SHA256: 8cdcad2546fd943fabe2e98de33f69ae6e8ea08eca5b5dadfc5f1a7cc90c3c1a

The script exports the registry key. You may send these exports along to incident response or law enforcement agencies. On an infected system, the output of the script might look as follows:

PS C:\Users\victim> dridexregistry.ps1
!!! Host is was/is almost certainly infected by Dridex
There are 14 config folders, of which 4 are filled.
Written hkcu:\Software\Microsoft\Windows\CurrentVersion\Explorer\CLSID to C:\Users\victim\_out\registry.reg
Found no Dridex binaries
Written Report to C:\Users\victim\_out

We also wrote a PowerShell script (carbanaktargets.ps1) that compares the list of installed applications against the 360 products that Dridex looks for to determine if it wants to deliver Carbanak:

PS C:\Users\victim> carbanaktargets.ps1
Your system has 'CuteFTP 9' installed, which could trigger Carbanak
Your system has 'SeaMonkey 2.46 (x86 en-US)' installed, which could trigger Carbanak
Your system has 'StarMoney' installed, which could trigger Carbanak
Your system has 'StarMoney 9.0 ' installed, which could trigger Carbanak
Your system could be the target of Carbanak

Disclaimer: The PowerShell scripts are provided with no guarantee and on best-effort. MELANI / GovCERT.ch can not be held liable for damages caused by the PowerShell script, false positives or false negatives.

Doing Incident Response

As a first reaction to the massive spam campaign, we have contacted SendGrid, kindly asking them to stop the associated email campaign. In addition, we have asked them to explain to us from whom they received the authorization to send on behalf of swisscom.com. We were very surprised not to receive any response from SendGrid for 24 hours. We therefore tried to reach them via a phone call (land line), but this turned out to be a dead end too (“you have reached us outside business ours”). Another 24 hours passed without any response from SendGrid, so we decided to reach out to them via Twitter. On Twitter, we finally managed to get a life sign from SendGrid. Unfortunately, it appears that SendGrid was having trouble to locate our abuse report.

Twitter conversation we had with SendGrid
Twitter conversation we had with SendGrid (click to enlarge)

Five more days passed since we have sent our initial abuse report to SendGrid. As of today, we are still waiting for official feedback from SendGrid.

Conclusion

Dridex is a sophisticated threat. While it has been around for more than two years, the detection rate by antivirus software is still quite low compared to other threats. The reason for this can be found in the local distribution of the malware – in our case, the focus was on Swiss internet users – and its absence on disk while the computer is running (file-less): Dridex operates exclusively in the memory when the computer is running. So there is no way for Antivirus programs to detect Dridex on disk.

We have also learned that Email Services Providers (ESPs) are representing an emerging risk: Many postmasters, spam filter vendors and DNSBL providers trust email traffic coming from ESPs, by either completely whitelisting them, or a applying a significant negative score (which reduces the chances that an email from an ESP is being classified as spam). Botnet operators know this and are abusing ESP’s infrastructure to send their malspam campaigns. This way, miscreants are able to bypass common spam filters and deliver their spam email directly to the victim’s mailbox. The following chart shows the success of abusing an ESP’s infrastructure by the fraudsters.

The chart below shows the number of user submissions on our phishing reporting platform antiphishing.ch over the past two months:

Number of submissions to antiphishing.ch
Number of submissions to antiphishing.ch (click to enlarge)

On Feb 15, 2017, we have received over 8 times more submissions from users than we usually did on average days. This impressively documents how efficient the use of SendGrid was for the miscreants to send out their emails. We believe that almost all emails passed spam filters and made it into the recipient’s inbox, resulting in a high infection rate with Dridex across the Swiss internet.

We believe that it is an ESP’s duty to detect and block such malspam campaigns on their infrastructure in a timely manner. We therefore recommend to postmasters, spam filter vendors and DNSBL providers to review their position with regards to ESPs, reevaluating their assessment and take action against ESPs failing to mitigate abuse from their service in time and/or ignoring abuse reports from 3rd parties.

Recommendations

Dridex might be more sophisticated than average malware. However, there are still a few things you can do to protect yourself.

In general:

  • You can spot many of these spam mails by simply watching out for Umlauts (äöü). If you receive an email that pretends to be from your bank or telecom provider and that contains no Umlauts, but rather the plain letters (aou), you should be careful.
  • Some of the spam mails contain ß instead of ss. Please consider that it is very unlikely that a native Swiss German speaker is using ß.
  • If you are unsure whether the email you have received is legit or not, call the sender or contact him via email to verify the purpose of the email.
  • Never execute macros in office documents you have received via email, even when the sender asks you to do so. Macros may harm your computer!
  • Use a dedicated computer for ebanking (no matter if you use traditional online banking or an offline payment solution) and do nothing else than ebanking on this computer.

For private users:

  • Always keep your Antivirus software up to date. If you use a non-free Antivirus, make sure that your Antivirus is licensed and if not, renew it or switch to a free Antivirus software to receive full protection. Otherwise the virus protection will expire and will no longer protect you against new threats.
  • Don’t rely on your Antivirus software alone – while it is indispensable, Antivirus can’t protect you from everything and does not free you from being careful.
  • Regularly make a backup of your data. The backup should be stored offline, i.e. on an external medium, such as an external hard disk. Make sure that the medium, where the backup is saved onto, is disconnected from the computer after the backup procedure is complete. Regularly test your backups.

For enterprises:

  • For payments or wire transfer issued via ebanking, make use of collective contracts. By using collective contracts, every wire transfer needs to be signed and authenticated by a second ebanking contract / login. Ask your bank about the use of collective ebanking contracts.
  • If you use a hardware token (e.g. SmartCard, USB-Dongle) for authentication or transaction signing, remove it from your device while you are not doing ebanking / payments.
  • Block the acceptance of dangerous email attachments on your email gateway. These include among others:
    • .js (JavaScript)
    • .jar (Java)
    • .bat (batch file)
    • .exe (Windows executable)
    • .cpl (Control Panel)
    • .scr (screen saver)
    • .com (COM file)
    • .pif (program information file)
    • .vbs (Visual Basic Script)
    • .ps1 (Windows PowerShell)
    • .wsf (Windows Script File)
    • .docm (Microsoft Word with macros)
    • .xlsm (Microsoft Excel with macros)
    • .pptm (Microsoft PowerPoint with macros)
  • In addition, all email attachments containing macros (e.g. Word, Excel or PowerPoint attachments) should be blocked on the email gateway as well.
  • Make sure that such dangerous email attachments are also blocked if they are sent to recipients in your company in archive files such as ZIP, RAR or even in encrypted archive files (e.g. by blocking password-protected ZIP files completely)
  • You can obtain additional protection against malware for your IT infrastructure by using the Windows AppLocker. This tool allows you to specify which programs are allowed to be run on the computers in your company
  • Block the download of archives (such as ZIP or RAR) that contain JavaScript code on your web gateway (Web-Proxy)
  • Evaluate the SPF record (Sender Policy Framework http://www.openspf.org/) for domain names that intend to send emails to your users. Reject emails whose sender IP address does not match the sending domains SPF record (inbound mail)
  • Implement an SPF record for your own domain name(s) to prevent miscreants from spoofing emails pretending to come from your domain (outbound mail)
  • Use DKIM (DomainKeys Identified Mail) and DMARC (Domain-based Message Authentication, Reporting & Conformance) for in-bound spam filtering (inbound mail)
  • Sign outgoing emails from your network to the internet with DKIM and DMARC (out-bound mail)

Further information and mitigation strategies can be found on our website.

Checklist on IT security for SMEs:
https://www.melani.admin.ch/melani/en/home/dokumentation/checklists-and-instructions/merkblatt-it-sicherheit-fuer-kmus.html

Indicators of Compromise (IOC)

Below is a list of indicators of compromise (IOC) that may help you to spot Dridex infected computers in your network. JS download:

https://jensenbowers-my.sharepoint.com/personal/leeanderson_jensenbowers_com_au/_layouts/15/download.aspx?docid=068187f5a930340c89e3b7c5c9b9c24f7&authkey=AarHUbAy66DSX08VzRPQ25w
https://jensenbowers-my.sharepoint.com/personal/leeanderson_jensenbowers_com_au/_layouts/15/guestaccess.aspx?docid=068187f5a930340c89e3b7c5c9b9c24f7&authkey=AarHUbAy66DSX08VzRPQ25w
https://yemposolutions-my.sharepoint[.]com/personal/amor_novicio_yempo-solu-tions_com/_layouts/15/guestaccess.aspx?docid=0ce03b9fd12d949cf91f56a7d1fbf4b93&authkey=ASOCPusN_QaBSXcCPxEkT9s

Dridex payload:

https://talofinancial-my.sharepoint.com/personal/ashleigh_schipp_talofinancial_com_au/_layouts/15/guestaccess.aspx?docid=07697c8afb3e544808bf527394eb7154b&authkey=Adh6QVItbnSLOpXvxh_BfCs
https://yemposolutions-my.sharepoint.com/personal/amor_novicio_yempo-solu-tions_com/_layouts/15/guestaccess.aspx?docid=0ce03b9fd12d949cf91f56a7d1fbf4b93&authkey=ASOCPusN_QaBSXcCPxEkT9s

Dridex botnet command&control servers (C&C):

109.235.76.95:1843
136.243.209.34:443
159.226.92.9:4431
173.196.157.250:443
178.195.0.12:8443
194.150.118.25:3101
194.150.118.25:3101
195.22.127.26:443
82.99.60.26:443
89.35.178.115:8443
179.177.114.30:8443
154.0.171.105:8443
95.208.65.134:8443
81.130.131.55:8443
77.236.97.60:4433
198.167.136.139:443
209.20.67.87:5353
213.222.56.155:443
216.51.232.176:4043
37.0.26.34:443
37.139.21.245:8343
46.17.3.237:443
81.155.55.211:8443
86.130.54.90:8443
Share on Twitter Share on Facebook

Back to top